Official optional Russian language pack (built-in locales are closed; a complete external pack exists)

[apopov-app]

Hi! Thanks for the harness — and for the explicit locale design.

Context. LOCALE_IDS is intentionally ['zh', 'en'], and the 2026-07-30 decision note says "the built-in locale set is closed; the language catalog is extensible", with additional languages added by client plugins through ctx.locale.addLanguage. That mechanism works well, so this is not a request to reopen LOCALE_IDS.

What already exists. I built a complete Russian language pack as an external bundle:

• registers ru (Русский, fallback en) and one Russian dictionary per client namespace — 66 namespaces / 2918 strings across sidebar, conversation, chat, settings, plugin manager, theme, schedule, terminal, browser and the experimental surfaces;
• generated from the client sources at dsh-v0.2.1-rc.5; every key falls back to English when a future client adds copy;
• ships the few layout rules Russian copy needs (longer labels than English), scoped to html[lang="ru"];
• self-heals the language registration when another plugin that added ru first is unloaded;
• MIT, package @apopov-app/dsh-locale-ru, source: https://github.com/apopov-app/dsh-plugins/tree/main/locale-ru (also installable straight from the git repository).

Question. Would you consider shipping such a pack as an official, optional, off-by-default bundle in this repository, so users get Russian without a third-party install? Or is the intended product policy that non-zh/en locales stay community/plugin-only?

[unera]

Related proposal, may matter for how this one ships: make the UI locale an ordered preference list (e.g. ru → en → zh) instead of a single choice, so a partly translated UI falls back to a language the user actually reads rather than to untranslated islands and Chinese source keys. It also keeps the shipped-locale set from being a closed enum.

Details and a link list of the other language threads: #11699