Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index

Hi :)
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! :D

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 :)

On 16 April 2014 10:10, Maniacco, Diego <>wrote:

A suggestion to the first point of Eike discussion: what if a centralized
page like  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 Maniacco (Südtiroler Informatik AG - Informatica Alto Adige SpA)
| Autonome Provinz Bozen - Südtirol - Provincia autonoma di Bolzano - Alto
| 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:
                        (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

                * 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

        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

                           * 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

                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

                I'll add the same comment there.

        I hope your stance is not too strict about this.


To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: 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.