Ok, Frank, 2009/9/7 Frank Peters <f...@sun.com>: >> Mostly affected files are (as far as I can tell) three, but in a different >> way: >> >> mostly added blanks: >> helpcontent2/source/text/scalc/01.po (around 280 changed strings) >> >> mostly changed tags, like "<emph>" -> "<item type=\"menuitem\">" >> helpcontent2/source/text/scalc/guide.po (around 230 changed strings) >> >> changed tags, like "<emph>" -> "<item type=\"menuitem\">" with some added >> blanks >> helpcontent2/source/text/swriter/guide.po (around 1000 changed strings) >> (this file obviously has also some or many textual changes, I would say) >> >> shared/00.po has around 100 changed/new strings, but they are mostly >> img tags, so not a lot of work for translator, this can remain as is. >> >> So the first three listed files represent around 1500 changes out of >> 1950 or so of the m57. If you can clean those three files of unwanted >> blanks and undo the tag change, with old po files of the same name >> updating them to new pot's the translators will get a true picture >> what content was edited and needs to be changed/translated. > > I don't know about PO files. Uwe can try to roll back those changes > in the sources so that the next po files get updated accordingly.
Well, by giving you the names of those three files I gave all the needed info, I hope. The path and name of generated .po file from SDF corresponds (AFAIK) to the first two strings of a SDF entry. Example: the line with English text in SDF: helpcontent2 source\text\shared\guide\insert_bitmap.xhp ends up in a po file with this path and name: helpcontent2/source/text/shared/guide.po So, actually you need to check all changes made by m57 in SDF en-US entries starting with: helpcontent2 source\text\scalc\01\* helpcontent2 source\text\scalc\guide\* helpcontent2 source\text\swriter\guide\* where * is a wildcard for anything that follows. >> OT: with all these icon (img tags) changes or additions, and I do not >> want to start a flaming war here, I see mostly inches are still used, >> although inches are officially used in only three countries today - >> the U.S.A., Myanmar and Liberia, I think. Is there any particular >> reason for this? I guess changing that to metric system would cause >> same massive help changes, so, no, I do not propose to change all >> inches to centimeters :) > > This, too, is a side-effect of the implementation of the help > authoring environment. The value written depends on what language > version of OOo you work on. I think, ultimately, we could just > leave that out entirely since it's currently not used (no, not > retroactively, just for new images) > This puzzles me and adds another type of error or unnecessary changes m57 introduced. Namely, changes in m57 include also (regarding to m56): From: <image id=\"img_id7261268\" src=\"res/helpimg/border_ca_5.png\" width=\"1.1354inch\" height=\"0.25inch\"><alt id=\"alt_id7261268\">default icon row of Borders tab page</alt></image> To: <image id=\"img_id7261268\" src=\"res/helpimg/border_ca_5.png\" width=\"1.0937in\" height=\"0.2189in\"><alt id=\"alt_id7261268\">default icon row of Borders tab page</alt></image> If inches and the measures contained here are not relevant at all, how come this changed in m57. If it already changed and needed to change, then it should change to cm-s :) But again, this change should not affect translators. Also, what worries me, the 6-blanks are starting to appear also in the non-help strings, and I do not know, if it is meant to be or should be ignored. See in SDF: migrationanalysis src\wizard\wizard.ulf 0 LngText %ERROR_MACRO_SECURITY_SET% My posts might be extensive, but I really want to lay out all different things that happened here so they won't happen again. Lp, m. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@l10n.openoffice.org For additional commands, e-mail: dev-h...@l10n.openoffice.org
