It returns an error ;) ain
On Thu, Sep 17, 2009 at 12:23, Uwe Fischer <uwe.fisc...@sun.com> wrote: > Hi Martin, > > I trust that Slovenians can make it happen! Don't give up, just re-use the > old translations wherever only spaces got added or removed. > > I will try to find the cause of the additional space characters inside long > xml constructs later today. > > You may translate or neglect the <emph>-->menuitem changes as you like. In > the final Help page that the user gets to see, there is no difference > between the two tags. Don't know what the translation syntax checker will > return, however. > > Uwe > > > On 09/17/09 10:47, Martin Srebotnjak wrote: >> >> 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 >> >> >> > > > > -- > 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
