updating to m57 added about 2000 fuzzy strings to help :( a lot of image/icon string changes. Is this all really necessary? Can these actions to be reverted? I can return my own translation cvs repository to any healthy point, but what to do with people/languages who have already translated this and who dont have version management environment? This is a major issue and very urgent! Things are gone to dogs starting from m51 and I suggest you to review all diffs made since this milestone and revert unnecesary changes.
ain On Sun, Sep 6, 2009 at 19:45, Frank Peters<f...@sun.com> wrote: > Martin Srebotnjak schrieb: > >> I am new to this list (I am the lead translator of OOo into Slovenian >> language), I hope I am posting to the right group. > > in future you should copy d...@documentation.oo.o as well on > documentation issues. > >> I am currently very pissed off so I did not bother checking if someone >> alredy asked this question. And taking in a breath or two will not >> help calming me down. So, here are the questios. And I do apologize if >> this venting is too much for this list in advance. > > This and other lists are not for venting. While I understand your > frustration, it would be better to shout at your room mate > if you want to vent. > >> Who is the genius who has completely revamped the English OOo Help >> content in one of the past milestones and now again (repeating the >> mistakes while eliminating some from previous CWS!) in the m57 >> introducing tons and tons of " " (unnecessary, unwanted 6 empty >> spaces) in otherwise unchanged English strings? >> >> Who is the genius changing tags from "<item>" to "<item >> type=\"menuitem\">" (where applicable) in several files? Although that >> might be useful and logical and a decision, agreed on by OOo >> developers, 100 translators to other languages must replicate the >> manual work in each and every string (and there are more than 500 >> strings changed in this way in m57)! Are you nuts? Can't you offer an >> automatic tool for that? Do we have to retranslate or retype/repaste >> all the help all the time? >> >> And then English strings like this one appear: >> Click the <item type=\"menuitem\">Outline & Numbering</item> >> <emph/>tab. >> >> Not to mention the fact that the gettext tools fuzzy-match more or >> less the <type=\"menuitem\"> part of the string and not what's inside, >> so fuzzy matching in most of these cases does not help translators. >> Here is schematic example: >> Choose <emph>SOMETHING</emph>. >> gets a fuzzy translation like: >> Choose <item type=\"menuitem\">SOMETHING-ELSE</item>. >> So almost all of these must be manually edited, and you must know (or >> look up) the translation of all those menu entries or buttons. And >> mistakes might happen ... >> >> Please, instruct me, what do I do with strings like: >> "Choose <emph>Tools - Language - Thesaurus</emph> " >> changed from >> "Choose <emph>Tools - Language - Thesaurus</emph>" >> Do I have to add 6 spaces at the end in Slovenian version? Or will >> there be an update on September 21 where all these mistakes will be >> erradicated and I will have to go through all the wrong strings with >> spaces (there must be 400 or more of them) and use my through-out ok >> Slovenian translations, marking them ok from being fuzzied again? >> >> How do such changes pass QA? Do you really not care for (mostly) >> open-source translators around the world giving up their spare time to >> this project? Not to mention that sdf for this massive change got >> available just two days ago, only two weeks before feature freeze, >> when testing and finishing up of translations starts ... If all >> translators would be paid by Sun by the hour, the developers & QA >> would really think about such massive changes before approving them. > > Mind your tone, please. > > Apparently, those changes came in by error. So we need to evaluate > how that happened and how it can be prevented in the future. Accusing > co-contributors of being malicious or inconsiderate will certainly > not facilitate this effort. > > Back to the problem: we seem to require some sort of normalization > process for the help files to compensate for stupid actions some > XML editors might take, like introducing spaces. I'll have a look > at this with Uwe and Sun Release Engineering. > > Frank > > XPost to d...@doc.oo.o > > -- > Frank Peters > Documentation Project Co-Lead > > 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...@documentation.openoffice.org For additional commands, e-mail: dev-h...@documentation.openoffice.org
