Continuing the discussion from Human Readable interface language selection:
We could debate whether it is “pointless busywork”, or “valuable but gruelling”, to translate the names of each locale Discourse supports, both into the form used in that locale, and into the form used in any other locale which Discourse supports.
Personally, I think it’s valuable. I think that if Discourse is running in a German locale, and a user wants to switch it to a Chinese Traditional locale, then a menu entry “Chinesisch (中文)” is much more helpful than a menu entry “zh”.
It certainly would be a lot of work to translate the name of each locale into its form used in each other locale. That’s an n-squared translation matrix. Fortunately, someone has done that work.
The Common Locale Data Repository (CLDR) includes many such translations and formatting strings. This includes a fairly well-populated nxn matrix of locale names translated to locales, for n in the dozens, if not hundreds, of locales. See, for example, the A-D segment of this data at http://www.unicode.org/cldr/charts/30/by_type/locale_display_names.languages__a-d_.html . (That’s where I got my example of the locale name “Chinese” in German and in Chinese.)
The CLDR data is available for use free of charge. The CLDR is now a project of the Unicode Consortium. Using this data in Discourse would probably require writing an extraction/conversion tool to map from the CLDR data format to a format Discourse uses. We could choose to use the CLDR directly, or via a library such as the Internationalization Class for Unicode (ICU). The CLDR data gets updated twice a year, so Discourse should plan on updating its copy from time to time also. Once Discourse has access to the CLDR data, then people could consider using other CLDR data in other parts of Discourse.
So, legible language names in the Discourse locale selection menu are not ready for a pull request. But the work to implement such a feature is a tooling and integration task, not a translation task.
FYI.
Cheers,
–Jim DeLaHunt