Just my 2 cents: A simple comparison of changed strings (and there are up to 2000 changed strings, like in m57) in sdf file would show the QA representative what is going on in the milestone; it would take 10 minutes to browse through the comparison file to see what kind of changes appear and if they look suspicious;
Should there be a limit put on how many strings can get changed by a single "normal" CWS or milestone? Like 500 strings? This would force documentation writers not to wait to the last milestone before the string freeze with almost all changes, and would be more translators friendly. The period of translation checking after string freeze is eroded also by translating instead of mostly testing, at least in the first week of so, because so many strings always changed in the last milestone just before string freeze. And changes to help could get checked throughout the development cycle by non-English users in native languages as well (like from Pavel's builds), if translators can work more gradually. Lp, m. 2009/9/10 Frank Peters <f...@sun.com>: > Dick Groskamp wrote: >> >> Dick Groskamp schreef: >>> >>> Started translating on the Helpcontent in Pootle. (DEV300_M54) >>> Seems that at least OO.o PO Help / scalc / 01.po is suffering from >>> superfluous spaces. >> >> EXAMPLE: >> >> <bookmark_value>GCD function</bookmark_value> >> #########<bookmark_value>greatest common divisor</bookmark_value> >> >> from: OO.o PO Help / scalc / 01.po / 04060106.xhp#bm_id3147356.help.text >> >> (where # stands for 1 space) >> >> There are strings with 6 and with 9 extra spaces and they all seem to be >> in strings where there are several >> tags <bookmark_value> Extra spaces starting with the second >> <bookmark_value>-tag > > For various reasons, insignificant space chars made it to > help files in m54. With m57, some of these were reverted, > while in some places new were created. In addition, mass changes > of elements were performed in m57. > > With the next CWS hcshared23 which is in QA currently, we tried > to revert the mass element changes and space changes *relative > to m54*. > > All changes present in m54 were not touched since some groups > have already localized that milestone. > > I understand that introduction or removal of insignificant > spaces in help files are annoying for l10n. > > The root cause is that versioning systems like svn are not > really suited to store or process semantic information. Hence > the system reports a change in the source code that has no > effect on the semantics of a content piece. > > 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 > > 2) introduce and use a status flag that marks content > as to be (re)localized and has to be set explicitly > > 3) introduce a filter on pootle that ensures that > insignificant changes are not reported > > 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. > > This could happen in the course of some help content > cleanup process that could also be used to get rid of > other annoyances like image dimension attributes > (currently unused). > > This cleanup process would require a quiet period of > some time in which no localization can take place. > > Frank > > -- > Frank Peters > > The OOo Documentation Project: > SIGN UP - PARTICIPATE - CONTRIBUTE > IT'S FREE! NO OBLIGATIONS! > http://documentation.openoffice.org > http://wiki.services.openoffice.org/wiki/Documentation > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@l10n.openoffice.org > For additional commands, e-mail: dev-h...@l10n.openoffice.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@l10n.openoffice.org For additional commands, e-mail: dev-h...@l10n.openoffice.org
