Thanks, Uwe, for the reply. That probably means that I as single translator for Slovenian will not translate those strings with added 6 and 9 spaces that were introduced since m56 as that would make my work redundant - I would have to again go through them. I wonder if other smaller localization teams will do the same. This probably means that many localized versions just won't be fully localized for 3.2 and that would not be the responsibility of localizers.
As for added "MAC" space - in all those places that it was introduced since m56 it was not necessary in my opinion (it would have been, if in the displayed text there would be a space missing between the shortcut word and another word). Here is an example from m56->m59: m56: To insert a new paragraph immediately before or after a section, click in front or behind the section, and then press <switchinline select=\"sys\"><caseinline select=\"MAC\">Option</caseinline><defaultinline>Alt</defaultinline></switchinline>+Enter. m59: To insert a new paragraph immediately before or after a section, click in front or behind the section, and then press <switchinline select=\"sys\"><caseinline select=\"MAC\">Option </caseinline><defaultinline>Alt</defaultinline></switchinline>+Enter. Uwe, do you think this addition of space after "Option" in this case is necessary? Does this mean that besides added 6 and 9 spaces and the tags change there is another "automatic" change problem, the added unnecessary spaces after "Option" and "Command" in MAC shortcuts? Also, what should we the localizers do with the emph -> menuitem change? Do you expect us to translate/localize these manually or will you revert them back after 3.2 and make this change automatically in the localization teams' SDF files as was discussed in this thread? If I have to manually edit those strings in time for 3.2 - well, I just probably won't, - I wonder what other localization teams' opinion is on this matter? What about all the errors introduced with this change, like the one I reported in my previous post (with the emph-menuitem replacement some emph closing tags remaining etc.)? Thanks, m. 2009/9/17 Uwe Fischer <uwe.fisc...@sun.com>: > Hi Martin, > > first we must apologize for some unintended changes that appeared in the > *.xhp help source files in the last few months. Be assured that we do not > want to make the life of translators uncomfortable in any way, just the > opposite. > > The unnecessary blank spaces were introduced by using some "pretty xml > formatting" plug-in or add-on or option in jEdit. This should have worked > only at places where whitespace is not important, but obviously that > assumption was false. And I was quite sure, additionally, that the pretty > formatting works only for the view and never expected that it saves those > indents as spaces to the files. Sure, some testing would have revealed this > in time, but then ... who will run the tests, who has the time ... > > The changes from <emph> tags to menuitem tags, although very useful to use > xml structure instead of visual attribution for tagging, just came in at the > wrong moment. > > We tried to roll back those changes from cws hcshared22 to hcshared23. > However, a tight deadline demanded that we could not roll back the changes > in all those files that already got edited in hcshared23. Also other feature > CWSs with edited help files were merged in automatically, and those other > files are based on whatever version the feature CWS was based on. This may > have resulted in even more conflicts in the new master help files. > > By now, Help contents for OOo 3.2 are delivered. We have some months until > OOo 3.3. So we can now take care of all unwanted pecularities that mess up > the Help contents. Of course we will do this by creating script based tests > and/or improved import and export filters so that those issues will not > happen again. > > > Uwe > > btw, the "single space inside inline switches" problem can be resolved by > looking at the whole sentence where it appears. Normally, a single space > should follow the switch construct and inside the switch tags there should > be no space before or after the text contents. Take care that at the end, > following the switch for every condition, there is one space between words. > > > > > On 09/17/09 01:44, Martin Srebotnjak wrote: >> >> Hello again, >> >> I just updated to m59, hoping not to see unwanted spaces and >> unnecessary tags changes, introduced by m57. But m59 (hcshared23?) >> doesn't seem much different to m57 (although there seem to be like 500 >> changes less). >> >> Namely, I have updated my m56 translation with only 13 fuzzy strings >> and no untranslated ones. After the direct update to m59 I have 1773 >> fuzzy strings and 163 untranslated ones. >> >> Among fuzzy strings (besides probably needed changes in English text, >> as you explained) many changes as well as errors like this still >> appear: >> m56: >> In the <emph>Level </emph>box, select the number of heading levels to >> include in the chapter number. >> m59: >> In the <item type=\"menuitem\">Level</item> <emph/>box, >> select the number of heading levels to include in the chapter number. >> >> This string in m57 looked like this: >> In the <item type=\"menuitem\">Level</item> <emph/>box, >> select the number of heading levels to include in the chapter number. >> >> That is, the same. >> >> So the "helpcontent2/source/text/swriter/guide..." files still include >> many changes from <emph> to <menuitem> tags, as well as unwanted >> spaces. >> >> Example (many bookmark stings have this problem): >> m56: >> <bookmark_value>objects;anchoring >> options</bookmark_value><bookmark_value>positioning;objects >> >> (guide)</bookmark_value><bookmark_value>anchors;options</bookmark_value><bookmark_value>frames;anchoring >> options</bookmark_value><bookmark_value>pictures;anchoring >> options</bookmark_value><bookmark_value>centering;images on HTML >> pages</bookmark_value> >> >> m59 (empty spaces are probably displayed before the wrap of the >> following lines, so highlight the following text to see them): >> <bookmark_value>objects;anchoring options</bookmark_value> >> <bookmark_value>positioning;objects (guide)</bookmark_value> >> <bookmark_value>anchors;options</bookmark_value> >> <bookmark_value>frames;anchoring options</bookmark_value> >> <bookmark_value>pictures;anchoring options</bookmark_value> >> <bookmark_value>centering;images on HTML pages</bookmark_value> >> >> These strings remained same as in m57. >> >> Does this mean that the major rollback of unwanted changes in m57 will >> be included with the m60 or later and we should wait until then with >> the translation process (string freeze should be around September 21st >> which is 4 days from now ...)? Or am I doing something wrong updating >> the translation files? Or the unwanted changes will not be rolled back >> at all? >> >> Please advise; other translation teams please report if you see same >> or different behaviour in m59. >> >> Also, advise please of changes in strings or parts of strings of MAC >> shortcuts like: >> <switchinline select=\"sys\"><caseinline >> >> select=\"MAC\">Option</caseinline><defaultinline>Alt</defaultinline></switchinline> >> - there is massive addition of a single space behind "Option" or >> "Command" in both m57 and m59 or other recent milestones. Is this a >> desired change or an error of the editor software? I would like to >> know if the Slovenian translation should remain the same or this >> single space must be added for parsing/appearance purposes. >> >> Good night, >> m. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@l10n.openoffice.org >> For additional commands, e-mail: dev-h...@l10n.openoffice.org >> >> > > > > -- > uwe.fisc...@sun.com - Technical Writer > StarOffice - Sun Microsystems, Inc. - Hamburg, Germany > http://documentation.openoffice.org/ > http://wiki.services.openoffice.org/wiki/Documentation > http://blogs.sun.com/oootnt > http://user.services.openoffice.org/en/forum > > --------------------------------------------------------------------- > 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
