Hi Jan,
janI schrieb:
On 24 August 2013 14:59, Andrea Pescetti <[email protected]> wrote:
Dick Groskamp wrote:
"<link href=\"text/swriter/01/**02120000.xhp\"
name=\"AutoText\">AutoText</**link>"
"<link href=\"text/swriter/01/**02120000.xhp\"
name=\"AutoTekst\">AutoTekst</**link>"
As far as I know the part after "name=" is the only part inside <link
... /link> to be translated
Yes, this is correct. So: the word "name" itself stays in English, the
value of "name" is translated, everything else stays in English.
That said, I'm curious to know if we have languages where all the
"name=..." are untranslated. Jan, is this the case for Danish? Does it work
too? Anyway, for the accessibility reasons Regina mentioned, Italian,
German and most other languages do translate the name, and this is the
recommended practice. But if the only problems coming from not translating
the name are with accessibility applications (which will still work but use
English words) then most users won't be affected.
3.4.1 danish (I was in charge) and we did not translate a single extra
<...> in the UI. But since you have chosen to overrule the way I want to
build a danish translation community, you build the danish community and I
refrain from saying anything about how it works in 4.0.1.
You cannot speak about name= so generally, there is a big difference
between UI strings and help strings. UI strings are solely string (unless
AOO does something which I have not found), these strings are NOT
interrelated, and you can change all name= to "whatanicename" if you like.
This is not about the UI, but only about the help. Do you ever see an
attribue name= in Pootle for the UI?
For help its a different matter, there name= is used to generate an index
(happened last time in 2009, so actually quite outdated, have a look at the
tree files in svn),
Do you mean the Index, which is shown to the user, when he calls the
help? That index is generated from the bookmark element, if it has the
attribute branch="index". Or what "index" do you mean?
but I have seen multiple script that use c_str (no
multi byte) and not utf8, so it will be interesting to see translations
that have 0x00 as the first byte of name=. My recommendation (I am just a
developer) stays the same, dont translate it for 2 good reasons:
1) Is seems nobody runs the correct scripts to update the tree files for NL.
2) It is likely to break outside the western world where double characters
is needed (utf8)
German has the values of the name= attributes always translated and at
least in the OOo340 version the Danish localize.sdf has translated
strings too, and in the version currently on Pootle they are translated
for Danish as well. Example
https://translate.apache.org/da/aoo40help/helpcontent2/source/text/translate.html#unit=12992461
In OOo340 I see it translated in Japanese too, so there is no problem
with character code.
But if you prefer to make it more difficult for our newcomers, its up to
you (translate some <...> but not others), I would prefer to have stable
releases of the new languages, and then concentrate of these really minor
details (dont forget we have chosen to release a language as soon as the UI
is translated).
Sorry to sound negative, but I prefer quality to volume, meaning I would
like our excellent and highly motivated new (and old) to transalators to
concentrate on getting the bulk translations done, before caring about
small details, which in no way (ref. community decision UI==100% ==
release) hinders a release in their language.
This question come up on the German mailing list, and has nothing to do
with new translators, which work on the UI.
Since it seems I am a minority in here, I will refrain from promoting what
correspond to the sources we actually use.
It seems that we are talking past each other somehow.
Kind regards
Regina
rgds
jan I.
Regards,
Andrea.
------------------------------**------------------------------**---------
To unsubscribe, e-mail:
l10n-unsubscribe@openoffice.**apache.org<[email protected]>
For additional commands, e-mail:
[email protected].**org<[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
