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
2014.04.14 15:03, Eike Rathke wrote:
On Thursday, 2014-04-10 18:26:44 +0800, 锁琨珑 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:
(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
* 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
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
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
I'll add the same comment there.
I hope your stance is not too strict about this.
To unsubscribe e-mail to: email@example.com
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy