Language names should be in the target language chars

l10n
#1

Hi all,

So far, the language names shown in "Tools - Options - Language
Settings" are in the localed language name strings. For example, if you
are using English UI, the language listed are "English (USA), English
(United Kingdom), Chinese (Simplified), Chinese (Tranditional)..."; When
you are using Chinese (Simplified) UI, the list shows like "英语 (美国),
英语 (英国), 中文 (简体), 中文 (繁体)..."; when using Japanese UI then
the names are expressed in Japanese.

I believe those language names should be changed to the target names
chars for all UIs, like the language listed here:
http://zh-cn.libreoffice.org/international-sites/
(see the second column)

I am thinking about this because of the following reason:

  * It's a waste of time for localizers to translate every foreign
    language names to their own locale. Even translated, it may not be
    correct.
  * In case the users are trying to switch between languages, there may
    be confusion (for example, if I want to test something in Franch UI,
    and after that I want to change back to Chinese UI it's really
    difficult to find the right one in the list box.

And there is a corrensponding bug report here:
Bug 59901 - UI: Name of each language in target language
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=59901

Currently the language stings are translatable in pootle. My idea is that:

  * The language stings should be made un-translatable, just maitain a
    language list in the source codes with target chars; or
  * there be guidelines in the l10n wiki page to tell localizers to
    translate the language list strings to the target language chars.

Best regard,

Kevin Suo

#2

Hi :slight_smile:
+1
That would be brilliant!

I do have a lot of trouble switching between different languages. Luckily
for me one of the English ones has (us) after it so i switch back to that
and then try to figure out which language is really needed. It might be
even better if there were 2 columns rather than just one to get the best of
both worlds.

Does the list really need to be translated afresh for each release?!!?
Surely once done the list stays much the same except for 'new' languages
that have been added?
Regards from
Tom :slight_smile:

#3

Does the list really need to be translated afresh for each release?!!?
Surely once done the list stays much the same except for 'new'
languages
that have been added?

Usually it's not needed for each release to translate the strings, but for each locale the localers are translating the language strings to their own languages, which is a waste of our time and meaningless but adding trouble.

However, there may be unusual cases that the old strings need retranslating? For zh-cn I am sure that it was 100% complete translation in 3.x, but when 4.1 was released there become many untranslated strings. And even worse, in 4.2 there are even more, even if that string was already translated in 4.1. (Maybe it's because of the .src to .ui change? Or because "~ABC" to "_ABC"? )

Concerning the language names issue, what I am doing recently is revising the language names to english-and-target strings in zh-cn UI. I believe when finished it would look "professional", "fresh", and meaningful.

#4

Some more info, I think the language names on the wiki should also be revised. I have already changed ZH-HANS and ZH-TW to "target" names. Only few people would know ZH-HANS stands for simplified Chinese.

I even dont know most of the others "AN AR AST BE BG BN BRX CA CA-VAL
CS DA DE EL EO ES FA FI FR GD GL
HE HI HU ID IS IT JA JV KO LO-LA LT
MR NL NO OC OM PA PT PT-BR RO RU
SAH SK SL SV TE TH TR VI" mean.

#5

Þann fim 10.apr 2014 13:35, skrifaði Tom Davies:

Hi :slight_smile:
+1
That would be brilliant!

I do have a lot of trouble switching between different languages. Luckily
for me one of the English ones has (us) after it so i switch back to that
and then try to figure out which language is really needed. It might be
even better if there were 2 columns rather than just one to get the best of
both worlds.

+1 - could make life easier in many situations...

Or a list with only localized language-names:

Deutsch
Español
Français
Íslenska
日本語
Nederlands
русский

etc..

Does the list really need to be translated afresh for each release?!!?
  Surely once done the list stays much the same except for 'new' languages
that have been added?
Regards from
Tom :slight_smile:

Translators (and coders as well!) can use the ISO-639-files from translationproject.org to get translated languages and names. Very conservative and quite precise (though not very complete for some languages), these are surprisingly widely used; any error or omission there will stick around for ages in things like website drop-downs, various apps and interfaces and so on.

But I guess LO-devs will want to use the onboard solution for these.

Regards,
Sveinn í Felli

#6

These are ISO 639-1/ISO 639-2 language codes. In case you need it,
their equivalences are here:
https://en.wikipedia.org/wiki/List_of_ISO_639-2_codes

BTW, can't we use CLDR libraries to get language names in local and/or
foreign format as needed? I'm not a developer, that's just a blind
guess.

Best regards.

#7

Hi :slight_smile:
I like the look of their "Acknowledgements" page. It lists individuals as
well as companies.
http://cldr.unicode.org/index/acknowledgments

OpenOffice is listed along with many OpenSource projects in the "who uses"
section
http://cldr.unicode.org/#TOC-Who-uses-CLDR-

So i wonder if there is a good reason why LibreOffice didn't use it because
at first glance it looks fairly fantastic to me. Is there some politics or
licensing that makes it difficult for LibreOffice to be involved or was it
just not as useful as it's looks at first glance or some other good reason
for not being involved?

Getting back to the initial question, would it be difficult to list the
languages each in their own language?
Regards from
Tom :slight_smile:

#8

Hi :slight_smile:
Sorry to say but i've had a couple of messages off-list from people who
have had trouble dealing with the CLDR people. Not all community projects
are as open and welcoming as they like to believe. It's a shame but it
happens [shrugs]

We thought about having 2 columns, one entirely in whichever language and
the other with each item in a different language was considered and
rejected by the Ubuntu project for their installer. It's a LOT of work and
difficult to keep track of all the different parts of the jigsaw puzzle.
So, although it might be a nice idea i think we should drop that idea too
and just have the 1 column, as originally suggested;

"
I believe those language names should be changed to the target names
chars for all UIs, like the language listed here:
http://zh-cn.libreoffice.org/international-sites/
(see the second column)

I am thinking about this because of the following reason:

  * It's a waste of time for localizers to translate every foreign
    language names to their own locale. Even translated, it may not be
    correct.
  * In case the users are trying to switch between languages, there may
    be confusion (for example, if I want to test something in Franch UI,
    and after that I want to change back to Chinese UI it's really
    difficult to find the right one in the list box.
"

Sorry my opinions have turned out to be a bit rubbish so far!
Apols and regards from
Tom :slight_smile:

#9

Hi 锁琨珑,

So far, the language names shown in "Tools - Options - Language
Settings" are in the localed language name strings.

I believe those language names should be changed to the target names
chars for all UIs, like the language listed here:
http://zh-cn.libreoffice.org/international-sites/
(see the second column)

While having language names in their native language is fine for
interfaces where a user only wants to pick his/her own language, it is
not desirable for interfaces where several languages can be chosen for
different purposes that are not native to the user. Let me explain some
disadvantages:

* a document containing language attribution the user doesn't know the
  native name of, s/he will see a meaningless entry in the language list
* seeing the language list, a user will not know what languages are
  offered except those s/he can somehow deduce
* wanting to prepare a document with different locale settings (e.g.
  using different currencies or formatting) the user would have to know
  the native names
* a developer adding a language to the language listbox would have to
  know that name in the native language; yes, CLDR in the mean time
  provides native names of most frequently used languages, but not for
  the not so frequently used that now are occasionally requested; s/he'd
  have to take the word of the one requesting that language
* for developers this gets even more cumbersome for languages that can
  be written in different scripts, or scripts the developer doesn't know
  at all; would you know how to correctly write Arabic and enter it on
  your native keyboard? Or Mongolian in the Mongolian script? You'd have
  to rely on copy&paste and pray that your editor handles all Unicode
  characters, RTL writing direction and so forth.

I am thinking about this because of the following reason:

  * It's a waste of time for localizers to translate every foreign
    language names to their own locale. Even translated, it may not be
    correct.

That's about 350 language names we currently have, of an overall of some
hundred thousand words to translate (including help), doesn't really
look significant to me. Plus, once translated the names almost never
change.

  * In case the users are trying to switch between languages, there may
    be confusion (for example, if I want to test something in Franch UI,
    and after that I want to change back to Chinese UI it's really
    difficult to find the right one in the list box.

There's an easy trick for that: assign the language to a portion of text
and reload the document in the other UI language.

And there is a corrensponding bug report here:
Bug 59901 - UI: Name of each language in target language
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=59901

I'll add the same comment there.

  Eike

#10

Hi Tom,

OpenOffice is listed along with many OpenSource projects in the "who uses"
section
http://cldr.unicode.org/#TOC-Who-uses-CLDR-

So i wonder if there is a good reason why LibreOffice didn't use it because
at first glance it looks fairly fantastic to me. Is there some politics or
licensing that makes it difficult for LibreOffice to be involved or was it
just not as useful as it's looks at first glance or some other good reason
for not being involved?

LibreOffice uses CLDR to the same extent (or more) as OpenOffice.org
did. Just that it is not listed there (care to change that? :wink: In fact
OOo contributed its locale data to the CLDR back when CLDR was created.
However, CLDR does not provide all locale data LibreOffice needs, or
differently, and is not a global cure for all locale problems.

Getting back to the initial question, would it be difficult to list the
languages each in their own language?

See my reply there, for me as a developer adding language entries it
would be at least more difficult.

  Eike

#11

Hi Eike,

let me disagree with you. The points you mentioned are valid, but to me they look more like a bunch of selected edge cases than common real-life scenarios.

2014.04.14 15:03, Eike Rathke wrote:

So far, the language names shown in "Tools - Options - Language
Settings" are in the localed language name strings.

I believe those language names should be changed to the target names
chars for all UIs, like the language listed here:
http://zh-cn.libreoffice.org/international-sites/
(see the second column)

While having language names in their native language is fine for
interfaces where a user only wants to pick his/her own language, it is
not desirable for interfaces where several languages can be chosen for
different purposes that are not native to the user. Let me explain some
disadvantages:

* a document containing language attribution the user doesn't know the
   native name of, s/he will see a meaningless entry in the language list

If the user doesn't know the language in question, knowing the name of that particular language in their own language will hardly help. In other words, I doubt that actually knowing that the language is Whateverian (something you've never heard of) will help you understand the doc any better than knowing that the language is Gibberishian (the name you can't even read).

* seeing the language list, a user will not know what languages are
   offered except those s/he can somehow deduce

The user doesn't really care about "what languages are offered". What they care about is whether or not the language they need *at the moment* is offered. Assuming that they will know the native name of that language, it will often be much easier for them to find that name than guess it. Would you know or guess that German in Lithuanian is Vokiečių? I doubt that.

* wanting to prepare a document with different locale settings (e.g.
   using different currencies or formatting) the user would have to know
   the native names

I doubt one could prepare a document in any language they don't know to such extent. Setting metadata would be my least concern in such case...

* a developer adding a language to the language listbox would have to
   know that name in the native language; yes, CLDR in the mean time
   provides native names of most frequently used languages, but not for
   the not so frequently used that now are occasionally requested; s/he'd
   have to take the word of the one requesting that language

How's that a problem? If somebody makes a request, you can always ask the requester what the native language name is.

* for developers this gets even more cumbersome for languages that can
   be written in different scripts, or scripts the developer doesn't know
   at all; would you know how to correctly write Arabic and enter it on
   your native keyboard? Or Mongolian in the Mongolian script? You'd have
   to rely on copy&paste and pray that your editor handles all Unicode
   characters, RTL writing direction and so forth.

I agree that this might be a bit inconvenient for developers, but I'm pretty sure there must be an acceptable solution to that inconvenience. For example, non-latin language names could probably be stored in escaped fashion where appropriate (in the source code). I really don't think "X is inconvenient for developers" is a good excuse to keep something at a state less convenient for the end-user.

I am thinking about this because of the following reason:

   * It's a waste of time for localizers to translate every foreign
     language names to their own locale. Even translated, it may not be
     correct.

That's about 350 language names we currently have, of an overall of some
hundred thousand words to translate (including help), doesn't really
look significant to me. Plus, once translated the names almost never
change.

It's still useless and – most importantly – inconvenient to most users (=those who know the native name of language they want to pick).

   * In case the users are trying to switch between languages, there may
     be confusion (for example, if I want to test something in Franch UI,
     and after that I want to change back to Chinese UI it's really
     difficult to find the right one in the list box.

There's an easy trick for that: assign the language to a portion of text
and reload the document in the other UI language.

I'm pretty sure that developers can find easy tricks to solve their inconveniences as well. E.g. copy-paste.

And there is a corrensponding bug report here:
Bug 59901 - UI: Name of each language in target language
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=59901

I'll add the same comment there.

I hope your stance is not too strict about this.

Regards,
Rimas

#12

A suggestion to the first point of Eike discussion: what if a centralized page like http://zh-cn.libreoffice.org/international-sites/ would expose a square matrix of names (actually 49 x (1+49):
- each row will expose the link to the localized-site + the name of all languages written in the localized language?

The work will need to be updated each time that a new localized-siet will be added; not very often.

diego

#13

2014.04.16 12:10, Maniacco, Diego rašė:

A suggestion to the first point of Eike discussion: what if a centralized page like http://zh-cn.libreoffice.org/international-sites/ would expose a square matrix of names (actually 49 x (1+49):
- each row will expose the link to the localized-site + the name of all languages written in the localized language?

The work will need to be updated each time that a new localized-siet will be added; not very often.

The page would look very crowded. And more importantly, what's the point?

Rimas

#14

Hi :slight_smile:
I really like that link and it works well for just English. I thought
LibreOffice got translated into many more languages? Do other languages
happen to have a similar page already or is that only on the English site?

I suspect that not all teams have enough people or time to get all that
website done too and have been heroic enough. Getting the whole of
LibreOffice translated is an immense amount of work and i think many people
appreciate it but never get around to saying so. Good work all and many
thanks from a lurker! :smiley:

Even 49 x (49 + 1) seems like quite a lot but if it needed to go to a
couple of hundred that might be really difficult, even though it mostly
only needs to be done once. Is it worth it? Of course i would say yes but
then i am not one of the people doing the work and i have no idea just how
much work it would be. From what at least 1 more experienced person has
said i think it sounds like it might be too much work.

Regards from
Tom :slight_smile: