Not to mention updated strings like: "Click <item type=\"menuitem\">Find</item> <emph/>or<emph/> <item type=\"menuitem\">Find All</item>." or "Choose <item type=\"menuitem\">Format - Page</item> <emph/>and select the <item type=\"menuitem\">Header</item> <emph/>or <item type=\"menuitem\">Footer</item> <emph/>tab."
I wonder how help module will display code with such tag errors. Was "Find & Replace" used for these help edits? :) Lp, m. 2009/9/6 Ain Vagula <avag...@gmail.com>: > And that is not all... > in m57: > <paveljanik> there are zillions of TAB changes "=9 > <paveljanik> :-( > <paveljanik> image/icon changes :-( > > ain > > > On Sun, Sep 6, 2009 at 17:58, Martin Srebotnjak<mi...@filmsi.net> wrote: >> Hello, >> >> 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. >> >> 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. >> >> 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. >> >> Sorry, but I just could not beat around the bush. I guess other >> translators must feel about the same (or there is something very much >> wrong with me). >> >> Lp, m. >> >> --------------------------------------------------------------------- >> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@l10n.openoffice.org For additional commands, e-mail: dev-h...@l10n.openoffice.org
