And what is exactly wrong with language names in the current UI language?

(In reply to comment #1)
> And what is exactly wrong with language names in the current UI language?

I think the reporter would say that the current UI language selector has English languages names... We should have a list like this: https://nl.libreoffice.org/internationale-sites/ (both English and local language name) or a list like Wikipedia (= all languages in local language name).

I mark this bug as NEW and as an enhancement.

(In reply to comment #2)
> (In reply to comment #1)
> > And what is exactly wrong with language names in the current UI language?
> 
> I think the reporter would say that the current UI language selector has
> English languages names... We should have a list like this:
> https://nl.libreoffice.org/internationale-sites/ (both English and local
> language name) or a list like Wikipedia (= all languages in local language
> name).
> 
> I mark this bug as NEW and as an enhancement.

I agree with Joren De Cuyper.

The localized name of each language should appear, for example,
http://www.libreoffice.org/download/?type=deb-x86

Users should be able to figure out their localized names of language easily.

Such lists are usually looking dirty. Any plausible use case for this? User is unlikely to change the application UI language as it defaults to the user-configurable system setting.

(In reply to comment #4)
> Such lists are usually looking dirty. Any plausible use case for this? User
> is unlikely to change the application UI language as it defaults to the
> user-configurable system setting.

Perhaps, add an option like this:

[unchecked] Show localized names of language

If this option is checked, the localized names of language will be shown.

If the user receives a file containing the language which is not the default one, the user has to change the language settings to view or edit the file.

This option is also useful when many users use the same default settings but they speak different kinds of language.

Regards,
C. H. D.

> If the user receives a file containing the language which is not the default one, the user has to change the language settings to view or edit the file.

What do you mean?

(In reply to comment #6)
> > If the user receives a file containing the language which is not the default one, the user has to change the language settings to view or edit the file.
> 
> What do you mean?

LibreOffice marks the target language correctly very often. Sometimes, not really. (for whatever reasons, e.g. the problem in the file itself)

When LibreOffice does not detect the target language correctly, the remedy is that the user needs to manually choose the language.

By manually changing the language settings, the user can use the preferred language to edit certain documents.

Perhaps, the following fields should let the user optionally see the localized names of language:

Tools -> Options -> Language settings -> Languages 
1) User interface
2) Locale setting
3) Default currency
4) Western
5) Asian
6) CTL

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.

And how they should be sorted? By ISO code? They are often nothing like the language name? By Unicode order? It is culturally insulting, moving such important world languages like Greek and Russian after c..p on XYZ.

There can be clarity problems. Ordering the names of language may not be efficient.

How about having a toggle switch?

Before pressing the toggle switch, we have:

Chinese (Hong Kong)
Chinese (Macau)

After pressing the toggle switch, we have:

中文 (香港)
中文 (澳門)

The order of the names of language follows that of the previous selection of the user interface. 

I think LibreOffice can be user-friendlier in this way.

At this moment the most translated website is jw.org. This website solved the problem of having translation also in english, and also in local languages.