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 <[email protected]>:
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: [email protected]
For additional commands, e-mail: [email protected]
--
[email protected] - 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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
[email protected] - 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: [email protected]
For additional commands, e-mail: [email protected]
