feat(locale): ship Dutch (nl) as a first-party language (zh/en/nl) - branch ready

[vkpeter]

DeepSeek Harness: Dutch locale contribution (klaar om in te dienen)

Repo: deepseek-ai/deepseek-harness · branch: dsh-i18n-nl op fork vkpeter/deepseek-harness (commit c6a359c)
Compare: master...vkpeter:dsh-i18n-nl

Status 2 sep 2026: PR's van forks, issues en (waarschijnlijk) discussions zijn
door de repo-eigenaars uitgeschakeld. Deze tekst kan dienen als issue,
discussion of PR-beschrijving zodra dat weer kan (of via een maintainer).

Titel

feat(locale): ship Dutch (nl) as a first-party language (zh/en/nl)

Body

Dutch joins zh/en as a selectable GUI language for DeepSeek Harness. The
change is complete and ready to merge: branch dsh-i18n-nl on fork
vkpeter/deepseek-harness (commit c6a359c). PRs from forks are disabled on
this repo, hence this note.

What the branch does (packages/client/locale only):

• nl registered through the existing language-pack path: addLanguage({ id:
  'nl', label: 'Nederlands', fallback: 'en' }) at apply time; resolved from
  the browser (nl, nl-BE, ...) and the stored preference; selectable in the
  Language row; document lang becomes nl.
• Typed nl dictionaries for the common namespace (39 keys, complete against
  the zh key set) and the settings.locale row.
• NL_OVERLAY: full Dutch dictionaries for every feature namespace (28
  namespaces, 701 keys), registered via the untyped single-locale register()
  path. Feature packages can later move their nl copy into their own typed
  register() call.
• Lookup keeps the nl to en fallback chain, so untranslated keys resolve in
  English, never as raw keys or Chinese.
• Tests: apply + document-language specs updated for the three-locale
  catalog; new cases cover nl-BE browser detection, the Language row entry,
  and Dutch common/settings/feature copy resolution.

Motivation: Dutch-speaking users (nl/nl-BE browsers) currently fall back to
English. The same mechanism (addLanguage + single-locale register) is the
documented extension point for further community languages.

[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