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
--
+---
| Diego Maniacco (Südtiroler Informatik AG - Informatica Alto Adige SpA)
| Autonome Provinz Bozen - Südtirol - Provincia autonoma di Bolzano - Alto Adige
| Tel +39 0471 566 159
+---
On 15/04/2014 20:54, Rimas Kudelis wrote:
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:
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:
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-lati
