Display language names in their own language

What it is

An autonym language label writes a language option in the name and script used by its own speakers, allowing someone who cannot read the current interface to find it. Add a script or region qualifier only when the product actually delivers distinct translations or regional variants. An autonym is not a raw language code exposed to users, nor a reason to flatten every possible label into an unscannably long list.

Why it happens

If every language name is translated into the current UI language, someone placed in the wrong initial language may not recognize their own. A flag denotes a country and cannot reliably stand for languages that cross borders, multilingual countries, or shared scripts. Yet one unqualified name can be insufficient when the product offers distinct scripts, transliterations, or regional content. A robust language registry relates a stable BCP 47 tag to a native-reviewed autonym, direction, font coverage, optional script/region qualifier, and content availability. The switcher groups, searches, or progressively discloses only supported choices rather than generating a theoretical language universe.

Studying it

Start participants without explaining the current UI and ask them to find the target language or variant in a mixed-script list. Measure discovery, time, wrong selection, scrolling, and search queries. Compare autonyms, autonyms plus current-language glosses, flat lists, and hierarchical language→script/region selection. Include multiscript languages, regional variants of shared languages, different literacy, screen readers, and small screens. Ask people what they actually call the language instead of translating it internally. Engineering checks cover bidi isolation, font fallback, sorting, aliases, and agreement with shipped language bundles.

Where it stops holding

An autonym may have more than one accepted form, and naming can involve script, locality, community, and political choices; one native reviewer cannot represent every speaker indefinitely. Script and region qualifiers should correspond to delivered differences, not invent variants merely to expose technical tags, and they do not reveal a user's nationality. Learners and cross-language users may benefit from a gloss in the current UI language, but the autonym should remain. Optimization must not hide every less-used option: personalized ordering should be explainable and retain search plus a complete list of supported languages.

Applying it

• Maintain a native-reviewed autonym, direction, font, search aliases, and necessary qualifier for every supported language tag. Use the stable tag as the key, never the display name or a flag. In a mixed-language list, emit the correct language metadata on each option and apply bidi isolation and direction handling so assistive technology pronounces it in that language.
• Show the autonym by default. Where disambiguation is needed, use “autonym (script/region qualifier),” optionally with a current-language gloss. Split options only when shipped language resources, terminology, or content genuinely differ.
• Show the full list when support is small. At larger scale, use search, recent choices, and progressive language→script/region disclosure while retaining an all-languages path instead of one enormous flat menu.
• Test native fonts, bidi text, pronunciation, keyboard search, and zoom on real devices. Ask users of every target language to find their option from a wrong initial language, feeding clustered errors back into names, aliases, and hierarchy.

Related

• Same group: S4.01.1 Automatic language detection must be overrideable · S4.01.2 The language switcher must be reachable before sign-in · S4.01.4 Preserve page and state after switching
• Adjacent: S1.02 Mirroring for right-to-left languages · S1.03 Character sets, font coverage, and missing glyphs
• Search terms: language autonym · BCP 47 script subtag · language selector design