Feature request: let community plugins register new UI languages (i18n)

[dealerrrr]

Hi! First of all, thanks for the harness — and for the locale system, which already works nicely for zh/en.

I'd like to ask for a small change that would let the community contribute unofficial, partial UI translations through normal dsh-plugin packages: make the list of selectable locales extensible at runtime, instead of the closed TypeScript tuple it is today.

Why: the Web UI is English-only outside of zh/en. A partial community translation (say, Spanish) would help a lot of users who don't read English, and the machinery already tolerates partial coverage: the lookup chain (ns → common → en → key) falls back to English per key, and even the official zh side leaves some inline copy in English today. So an incomplete translation already works "as well as" the shipped Chinese one in that respect.

What blocks a plugin today: the locale ids live in the core package:

// packages/client/locale/src/locale-settings.ts
export const LOCALE_IDS = ['zh', 'en'] as const

and the selectable list is a frozen array in packages/client/locale/src/client/index.ts:

const LOCALES: readonly LocaleDefinition[] = Object.freeze([
  { id: 'zh', label: '中文' },
  { id: 'en', label: 'English' },
])

setLocale('es') throws locale "es" is not registered, and the settings schema (z.union([...LOCALE_IDS])) rejects persisting anything else. Meanwhile the untyped registration form already exists — ctx.locale.register(ns, locale, dict) — so a plugin can already publish dictionaries in an arbitrary locale; it just can't make that locale selectable or persistable.

Proposed API (sketch): expose something like

 ctx.locale.registerLocale({ id: 'es', label: 'Español', documentLanguage: 'es' })

which adds the locale to the snapshot, with the settings schema deriving its allowed values from the registry at runtime rather than from the static tuple. The fallback chain, the LocaleFace revision, and the sync would all keep working unchanged.

Evidence this is real demand: I built exactly this for Spanish in an unofficial fork — full es dictionaries for every locale-registered namespace plus a README.es.md, passing the repo's own typecheck — and the only thing keeping it from being a plugin is the closed LOCALE_IDS. Fork (unofficial, for reference only):
https://github.com/dealerrrr/deepseek-harness/tree/i18n-es

If maintainers are open to it, I'd be glad to turn the Spanish dictionaries into a community dsh-plugin-i18n-es package the day the API lands — labeled clearly as unofficial, per the community rules.

Thanks for reading!

[sayho-pm]

A working case of this: dsh-locale-pack registers 26 UI languages for the DSH desktop app as a community plugin, with no core changes.

• 26 languages x 2,322 keys = 60,375 entries
• Strings without a translation fall back to English, so partial coverage stays readable
• A quality gate checks placeholder parity, product and protocol names kept in English, and script integrity
• Bundled against 0.2.0-rc.2
• A subset build flag keeps the bundle small when only a few languages are needed

Language registration works as a bundle patch that inserts a row into the web profile roster, so it stays a plugin concern. Happy to reshape this into whatever form works best for the project.

https://github.com/sayho-pm/dsh-locale-pack

[furkancak1r]

For what it's worth, this already works from a plugin today without a core change: dsh-composer-plus registers 11 extra UI languages (Türkçe, Español, Português (Brasil), Français, Deutsch, Русский, 日本語, 한국어, Bahasa Indonesia, Tiếng Việt, हिन्दी) through ctx.locale; you pick one in Settings → Composer Plus → Application language, which writes dsh's own saved locale.preference. Each pack covers all UI strings of 0.2.0-rc.2 / 0.2.1-alpha.2. A first-class, documented extension point would still be much better than what the plugin has to do now, so +1 to this request.

Install: Settings → Plugins → Add plugin → dsh-composer-plus → Enable now (web profile: dsh plugin --profile web add dsh-composer-plus). Disclosure: I'm the author; it's an unofficial community plugin (MIT), and every feature can be switched off in Settings → Composer Plus. If it helps you, a ⭐ on https://github.com/furkancak1r/dsh-composer-plus is appreciated.

[Dreftian]

For Spanish speakers looking specifically for Latin American Spanish (es-419), I've published a dedicated community plugin with regional terminology (such as archivo, computadora, configuración, guardar, detener, etc.):

🔗 Repository: https://github.com/Dreftian/dsh-locale-es-419
Announcement: #10078

It registers es-419 via ctx.locale.addLanguage and bundles 58 translated namespaces covering Web and Desktop settings and core screens. Contributions and feedback are welcome!

[unera]

Filed a cross-cutting proposal that may change the shape of this: make the UI locale an ordered preference list (e.g. ru → en → zh, the way browsers do Accept-Language) instead of a single value, so a partial translation stops surfacing Chinese (or English) islands and a pack is useful the day it lands rather than at 100%.

If that lands, requests like this one become mostly "add a dictionary and one config entry". Would value your input on the trade-offs there: #11699