compound strings

l10n
#1

Hi,

I have in the new Header/Footer feature of 3.5 for the first time
noticed compound strings consisting of two separately translated
strings. For example, "Format Header" is composed of strings Format
(KeyId _XDs) and Header (b4n3).

Slovak (and other languages) have cases - the Header word must be in the
accusative case here. Are we sure that the b4n3 Header string is used
only in such context and not in other, where for example, the nominative
case should be used?

I would prefer to not to compound strings of other strings. What do you
think about that? Can we send this message to the developers?

Milos

#2

Hi, I haven't noticed that, this should be marked, explained in notes, if
sdf had those...
Will check, but why is this not a single string?
Does that mean that also "Format Footer" is formed from two strings?
This is unacceptable and anglo-saxon-centric, really does not work well for
other languages.

Lp, m.

#3

OMG, now I saw it, this is horrible - each context menu command must be a
separate string, you cannot format context menu commands in the same manner
for 100+ languages!
Thanks, Milos, for noticing this.

Lp, m.

#4

Hi Milos, Martin, *,

Hi,

I have in the new Header/Footer feature of 3.5 for the first time
noticed compound strings consisting of two separately translated
strings. For example, "Format Header" is composed of strings Format
(KeyId _XDs) and Header (b4n3).

Slovak (and other languages) have cases - the Header word must be in the
accusative case here. Are we sure that the b4n3 Header string is used
only in such context and not in other, where for example, the nominative
case should be used?

I would prefer to not to compound strings of other strings. What do you
think about that? Can we send this message to the developers?

Hi, I haven't noticed that, this should be marked, explained in notes, if
sdf had those...
Will check, but why is this not a single string?
Does that mean that also "Format Footer" is formed from two strings?
This is unacceptable and anglo-saxon-centric, really does not work well
for other languages.

OMG, now I saw it, this is horrible - each context menu command must be a
separate string, you cannot format context menu commands in the same manner
for 100+ languages!
Thanks, Milos, for noticing this.

See also this thread:
http://listarchives.libreoffice.org/global/l10n/msg03406.html

I agree that composing strings in such a manner is not okay, and
should it become a habit with the devs, it's a disaster waiting to
strike.
Another such case:
7yKt + btRK = "Insert" + " Rows"
7yKt + xGzB = "Insert" + " Columns"
(make a table in Writer, right-click in it, choose Row - Insert or
Column - Insert, and behold the dialog title.)

I'm not sure if there are more.

Greetings,
Mihkel
The Estonian team

#5

Yes, the same happens in the Esperanto version. It does not even put a space between the two words, and the case of the second is wrong (naturally).

On the other hand, is this a mechanism for developers to save us lots of work, retranslating the same strings over and over, e.g. OK, Cancel?

Donald

#6

Hi Donald et. al.,

On the other hand, is this a mechanism for developers to save us lots of
work, retranslating the same strings over and over, e.g. OK, Cancel?

this is not a proper reason to compound strings this way. There are tons of
Cancels and OKs in the string pool, and they should be kept separate. The
point is that the number of strings actually gets higher: if you compound
three strings with same beginning, you have 4 strings to translate instead
of 3. Yes, they are shorter, but in languages with cases, such as all
Slavic ones, you get incorrect translations. So 10 languages are ok and all
the rest not ...

I guess the conservatism of OOo team when designing UI with those UI spec
documents was a good thing and this should be in a way incorporated in the
LO development process, even if with a lower administration impact on
developers - but there should be some l10n representative checking ALL the
proposed changes of UI strings - that they are logical and that they are
localizable in all 100+ languages. Only then they could be checked in.

So, Andras, will you take care of these two string-formations in the code
for 3.5, the one reported by Milos and the one by Mihkel? Or do we have to
adapt our translations according to "what the author of code wanted to
say"? Time for 3.5 is running out I guess.

Last but not least - all best in the upcoming year to every single LO-l10n
contributor!

m.

#7

Quite. Even the little compounding we have leads to problems in highly inflected languages. Yes/No is another of those, which is unfortunately one that the OO team forgot, because a great many languages don't have a single word for yes and no and rely on the repetition of the verb.

The only way in which you could increase compounding without forcing crap translations in a lot of languages would be using something like Pology (http://websvn.kde.org/trunk/l10n-support/pology/doc/user/) but I suspect that's not going to happen in a hurry.

That aside, Bliadhna Mhath Ùr/Happy New Year to y' all!

Michael

31/12/2011 12:08, sgrìobh Martin Srebotnjak:

#8

I guess the conservatism of OOo team when designing UI with those UI spec
documents was a good thing and this should be in a way incorporated in the
LO development process, even if with a lower administration impact on
developers - but there should be some l10n representative checking ALL the
proposed changes of UI strings - that they are logical and that they are
localizable in all 100+ languages. Only then they could be checked in.

No, that would effectively kill productivity. It is better to catch
issues in beta phase. Not to mention that the UI approved by a
comittee in the Sun era still resulted crap. See the history of
http://opengrok.libreoffice.org/history/core/cui/source/dialogs/insrc.src,
it is Mihkels example. This file has not been touched by LibreOffice
developers.

So, Andras, will you take care of these two string-formations in the code
for 3.5, the one reported by Milos and the one by Mihkel? Or do we have to
adapt our translations according to "what the author of code wanted to
say"? Time for 3.5 is running out I guess.

I don't understand why anyone needs to adapt translations for Milos' example.

We have "Delete $1" and "Format $1" where $1 can be "Header" or
"Footer". Those are STR_HEADER and STR_FOOTER from
sw/source/ui/docvw/docvw.src and are not used anywhere else, so you
can translate them as you need to fit into the "Delete $1" context. I
hope the translation for "Header" or "Footer" is not different
depending on if you delete it or if format it.

As for the Insert Rows/Columns modal dialog, it was a good catch that
needs to be fixed. But if it have been good enough for the last couple
of years, then I don't think we need to urgently fix it in 3.5 and
break the string freeze. Let's fix it in master. What do you think?

Best regards,
Andras

#9

http://cgit.freedesktop.org/libreoffice/core/commit/?id=005844765e38b8147ff2468036cc5c229680a1bb

Please escalate the issue to libreoffice@lists.freedesktop.org, if you
want this in 3-5.

Happy New Year!
Andras

#10

>

> So, Andras, will you take care of these two string-formations in the code

> for 3.5, the one reported by Milos and the one by Mihkel? Or do we have
to
> adapt our translations according to "what the author of code wanted to
> say"? Time for 3.5 is running out I guess.

I don't understand why anyone needs to adapt translations for Milos'
example.

Well, for one, in the case of languages that don't use Title Case for menu
commands, it's not obvious that words for "Header" and "Footer" should
start with a lowercase letter there.

We have "Delete $1" and "Format $1" where $1 can be "Header" or

"Footer". Those are STR_HEADER and STR_FOOTER from
sw/source/ui/docvw/docvw.src and are not used anywhere else, so you
can translate them as you need to fit into the "Delete $1" context. I
hope the translation for "Header" or "Footer" is not different
depending on if you delete it or if format it.

I wouldn't be so sure. In Estonian, "Delete header/footer" is "Kustuta
päis/jalus", but "Format header/footer" could be "Vorminda päis/jalus" or
"Vorminda päist/jalust" depending on entirety vs. partialness [1]. These
words just so happen to both take only 't' at the end in partitive form, so
"Vorminda $1t" would work, but there may be languages where the words
change differently.

[1] See e.g. http://en.wikipedia.org/wiki/Partitive_case

As for the Insert Rows/Columns modal dialog, it was a good catch that

needs to be fixed. But if it have been good enough for the last couple
of years, then I don't think we need to urgently fix it in 3.5 and
break the string freeze. Let's fix it in master. What do you think?

OK by me.

Happy new year!
Mihkel

#11

Hi Mihkel,

We have "Delete $1" and "Format $1" where $1 can be "Header" or

"Footer". Those are STR_HEADER and STR_FOOTER from
sw/source/ui/docvw/docvw.src and are not used anywhere else, so you
can translate them as you need to fit into the "Delete $1" context. I
hope the translation for "Header" or "Footer" is not different
depending on if you delete it or if format it.

I wouldn't be so sure. In Estonian, "Delete header/footer" is "Kustuta
päis/jalus", but "Format header/footer" could be "Vorminda päis/jalus" or
"Vorminda päist/jalust" depending on entirety vs. partialness [1]. These
words just so happen to both take only 't' at the end in partitive form, so
"Vorminda $1t" would work, but there may be languages where the words
change differently.

Thanks for this great example. Now we have the proof that it can cause
problem. I'll kill this composition from master, too. Please report,
if you find more.

Best regards,
Andras

#12

Dňa 31.12.2011 13:56, Andras Timar wrote / napísal(a):

I guess the conservatism of OOo team when designing UI with those UI spec
documents was a good thing and this should be in a way incorporated in the
LO development process, even if with a lower administration impact on
developers - but there should be some l10n representative checking ALL the
proposed changes of UI strings - that they are logical and that they are
localizable in all 100+ languages. Only then they could be checked in.

No, that would effectively kill productivity. It is better to catch
issues in beta phase. Not to mention that the UI approved by a
comittee in the Sun era still resulted crap. See the history of
http://opengrok.libreoffice.org/history/core/cui/source/dialogs/insrc.src,
it is Mihkels example. This file has not been touched by LibreOffice
developers.

So, Andras, will you take care of these two string-formations in the code
for 3.5, the one reported by Milos and the one by Mihkel? Or do we have to
adapt our translations according to "what the author of code wanted to
say"? Time for 3.5 is running out I guess.

I don't understand why anyone needs to adapt translations for Milos' example.

We have "Delete $1" and "Format $1" where $1 can be "Header" or
"Footer". Those are STR_HEADER and STR_FOOTER from
sw/source/ui/docvw/docvw.src and are not used anywhere else, so you
can translate them as you need to fit into the "Delete $1" context. I
hope the translation for "Header" or "Footer" is not different
depending on if you delete it or if format it.

No, it is not different.

So, I corrected the translation to the accusative case without the
capital letter. I could have done that also earlier (thanks to KeyId),
but I was not sure if these string were used elsewhere in a different
context (say, in nominative) or not. Now I know :slight_smile:
Thanks

Milos

#13

Hi Andras, in Your commit You removed "Insert" keyid 7yKt but if its
meant to use like:

7yKt + btRK = "Insert" + " Rows"
7yKt + xGzB = "Insert" + " Columns"

Shouldn´t btRK and xGzB also be removed? Or are these used for something
else?

Regards

#14

Hi Andras,

ignore my message. I didn´t notice that "Row" and "Columns" were changed to
"Insert Row" and "Insert Columns"

Regards