The workbench generates readable labels for four preserved identifiers: en-US, es, fr-CA, zh-Hant. Canadian French starts selected. Switch from dialect to standard naming and the visible labels rebuild while selected code remains fr-CA. The page uses the runtime's actual Intl.DisplayNames output; it does not translate site content or establish that any configured language page exists.
Start with configured options
Treat the four codes as an authored site's supported-option list, not a discovery service for every possible language. Display each code next to its generated name so a reviewer can distinguish fr-CA from fr or zh-Hant from an unspecified Chinese option. Keep the exact identifiers in the state model. A visible name has a presentation job; the code has an identity job. Replacing the code with its English label would make later formatting choices change what the program stores.
Construct the formatter with display locale en-US, type language, long style and fallback none. The display locale names the language of the interface words; the input code names the language being described. Here en-US generates English labels while fr-CA remains one choice. DisplayNames also handles other name types, but a region code is not a language identifier. This exercise stays with language names and avoids flags, which would introduce an unrelated geographic symbol and another naming assumption.
Compare naming policies without resetting state
Dialect naming can use a familiar regional phrase such as American English, while standard can use English (United States). The actual returned wording depends on the runtime's locale data, so keep the formatter options visible for review. Changing languageDisplay rebuilds all four labels from their codes, then retains selectedCode. A style preference is not an instruction to choose the first language. The example uses native buttons for the four configured choices and separate style buttons to make this preservation easy to inspect.
Choose fr-CA, switch styles, then choose zh-Hant and switch again. The selected-code result should follow only the language-choice control. Labels may differ while the identifier stays fixed. Record the selected display name separately so the reviewer sees both. If a future selector submits a value, it should submit the original configured code, not a translated label or a row index. Keep actual content availability as a separate site configuration check before exposing a language menu to users.
Handle unavailable names explicitly
With fallback none, an unavailable name can return undefined. Retain its code and show Name unavailable rather than removing an option silently. The workbench includes an independent qaa inspection to demonstrate that fallback boundary without adding qaa to the supported-option list. If the API itself is missing, preserve code-only choices and report formatting unavailable. Do not insert hardcoded names and present them as if they came from the missing runtime method.
Finish by checking label policy and stored identity independently. Review actual names with the content editor, preserving the four configured codes and selected value. The task ends with a readable menu policy, not automatic translation, new language versions or rewritten content links. Keep the maintained selector and content inventory authoritative, and recheck labels when locale data or formatter settings change instead of assuming every runtime necessarily uses identical wording.
Make your own working example
Build an original language-label workbench with exactly configured codes en-US, es, fr-CA, zh-Hant. Use actual Intl.DisplayNames display locale en-US,type language,style long,fallback none,languageDisplay dialect initially. Start selected fr-CA. Show four native language buttons and a readable code/name inspection list; keep program state as the original codes.
Provide Dialect names, Standard names and Reset. Rebuild actual runtime labels when languageDisplay changes without altering selectedCode. Display selected code, generated name and formatter options separately. Select zh-Hant and retain that code through subsequent naming changes. Do not hardcode translated names as API output or claim the site has translated pages.
Add Inspect unavailable name qaa as a separate diagnostic, not a fifth configured language. If of returns undefined, retain code and show Name unavailable. If API unsupported, retain code-only choices with formatting-unavailable explanation. Reset restores dialect/fr-CA and clears diagnostics. Handle formatter exceptions honestly. Use text language names without flags, no content translation, external services or persistence. Keep current code and output early enough to inspect on mobile.
Use one self-contained HTML file with no remote dependency. Keep the initial sample, output, and labeled controls near the top. Use at least 16px text, strong contrast, visible focus, and a stacked layout at 360px without horizontal overflow. Use explicit type=button click handlers and explicit DOM selectors; do not depend on native form submission. Clear stale feedback when task inputs change. Render entered text safely. Keep practice data local to the current page; do not imply saving, sending, or production integration. Return only the finished HTML.
Agree on the menu wording
Keep supported language codes in the maintained selector. For an HTML label review, NOS lets you revise eligible static instructions visually without AI regeneration. Clarify the chosen naming policy there, then carry it back without changing the configured identifiers or claiming missing content was translated.