We've struggled with how to handle the titlecasing of language names. Here's a proposal.
There are three main ways to present languages in a menu or list. Here are examples, presuming that the native language of the user is French.
For example, the Self approach is used on http://translate.google.com/?hl=fr#. http://fr.wikipedia.org/wiki/ (titlecase) and on http://www.facebook.com. The Native approach is used on http://www.google.com/language_tools?hl=fr.
One of the problems with the Self approach is that the casing gives a ransom-note effect, so we see wikipedia and facebook both using titlecase consistently.
However, we have not wanted to ask all translators to supply both a normal and titlecased variant of language names. What I suggest we do is ask the translators in the ST to supply an alt=titlecase version of languages names in just some restricted cases, when the normal language name:
1. is the name of itself. (Français, Deutsch, Suomi)
2. is cased. (excluding Japanese, Chinese, etc.)
Once we have this, people who want to use the Self approach can do so with consistent case, as in the following:
BTW, in the above lists, the Self lists are sorted with a neutral sort (UCA-CLDR), while the others use the user's language. It is, of course, possible to use the user's language for sorting the Self list; but typically the Self list is constant across languages, so the neutral sort is better...
Trac Comment 9 by —2015-02-20T17:29:14.515Z
Moving all design bugs to the design status and component = "unknown". Please update the component as appropriate.
Trac Comment 8 by —2014-02-03T16:49:56.760Z
Merging future and UNSCH
Trac Comment 1 by kent.karlsson14@0885cc00c95d6cd9—2011-01-03T15:10:32.000Z
Or... Programmatically apply the "toupper" function on the first letter of the string retrieved for the language name... This is how casing normally works when getting dictionary-style data and using it at the beginning of a sentence. I see no reason why normal case mapping for beginning-of-sentence (or menu item) would not work just fine. That would not involve any additional data at all.