Frank Peters wrote: > We have multiple options to avoid this in future: > > 1) introduce a normalization step that is triggered > when the helpcontent is built and that makes sure that > the content follows certain formatting rules
Building a source shouldn't modify it. But perhaps it's enough to stop the build in case superfluous blanks have been found and ask to apply a tool to the sources in question. > 2) introduce and use a status flag that marks content > as to be (re)localized and has to be set explicitly Manual steps will fail sooner or later. > 3) introduce a filter on pootle that ensures that > insignificant changes are not reported Perhaps a precommit hook in Mercurial can help? > The best option would probably be 1). But this would mean > that when introducing the normalization step, all content > had to be normalized once initially which would bring > l10n relevant changes. If you want to keep the white spaces in the existing code base, you could check the diffs instead of the source: a valid diff should be identical with a diff ignoring white space changes. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@l10n.openoffice.org For additional commands, e-mail: dev-h...@l10n.openoffice.org
