Internationalization is the process of designing and developing a software product to function in multiple locales. This process involves identifying the locales that must be supported, designing features which support those locales, and writing the code needed.

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160408004012
Steps to reproduce:
Select the language name
Actual results:
I observe only the language code and not the name
Expected results:
should have seen Maya' Kaqchikel (cak)

(In reply to Francesco Lodolo [:flod] from comment #7)
> Should we also look at Fennec? I've just realized that we have several small
> languages there, more than Firefox (trs, tsz, zam are the first examples
> coming to mind)
> https://hg.mozilla.org/releases/mozilla-aurora/raw-file/default/mobile/
> android/locales/all-locales
>
> They're not all shipping in the multilocale build yet, but they will at some
> point (currently in single locale builds).
Sebastian, could you answer it?

Seems like the ball was dropped here. Actually, "cak" is not the only locale affected (ex: "son", "zam", and more).
This is an important thing to fix if we want our users to be able to switch to their language (most of them are not familiar with locale codes).
With the permission of :rnewman, I'm copy/pasting here his comments from an email thread from a year ago: ""son" and "cak" show like that because your device's Android version doesn't know what they are. We turn "en_US" into "English (United States)" by calling Java's Locale.getDisplayName; esoteric locales like cak aren't in the OS's lookup table, so we fall back to the locale code.
Fixing this is expensive from a localization perspective: every locale would have to localize every locale's name, so we'd be adding about 6,000 strings, and there'd be a bit of coding pain, too."
However, talking with Flod this weekend, we realized that we have translations for shipping locales in mercurial, so we should be able to leverage this.

> Fixing this is expensive from a localization perspective: every locale would have to localize every locale's name, so we'd be adding about 6,000 strings, and there'd be a bit of coding pain, too."
I wonder if we need those translations. The languages in the preference are not translated to the currently selected language (e.g. German is always "Deutsch" - no matter what language is currently selected).
We recently added "cak" etc. support to Focus for Android and the only thing we had to add is the name for "cak" in cak itself. Not sure if there are other places in Fennec that would need translations of the language name though.

I believe the issue Fennec should be moved into a different bug (in Firefox for Android).
As far as I can tell, the language switcher menu changes depending on the phone, which means we're getting translation from the OS.