Russian language pack for DeepSeek Harness

[tenkrol]

Hi — first, thanks for Harness. I use it daily for a long-running personal agent (Telegram/VK
front-end, home automation, documents), and the plugin model made it practical to extend
without forking anything.

What I built. The web GUI ships en and zh. Since the locale service accepts languages
from client plugins, I wrote an external pack that registers ru with real dictionaries:

• 65 namespaces, 2,914 strings, complete for the 0.2.1-rc.5 build;
• per-namespace JSON sources, a generated client bundle, and a checker that verifies key
  parity and {placeholder} preservation against the English source;
• install/uninstall tooling that wires the package into a profile as a bundle;
• MIT, no dependencies, no patches inside the app:
  https://github.com/tenkrol/dsh_locale_ru

To keep it honest I wrote a small extractor that pulls the English dictionaries out of the
installed build, so a release bump turns into a diff instead of a guess. On 0.2.1-rc.5 it found 137 new strings (mostly pluginManager and settings.models),
8 new namespaces (pluginMarket 78, session-inspector 52, cotTranslation 32, …), and
3 placeholder drifts — all fixed in v0.2.0, which is exactly the loop the check exists for.

The mount is just a bundle row, which is why I assumed this is the intended extension point:

- insert:
    - id: locale-ru
      name: dsh-locale-ru

What I ran into (in case it is useful for the roadmap):

1. A small number of strings sit outside the dictionaries and stay English regardless of the
   selected language. I have not compiled a full list yet — happy to do it if that helps.
2. Dictionaries return ready-made strings, so pluralization has to be encoded in separate
   keys («1 задача» / «2 задачи»). Is ICU plurals or message formatting on the roadmap for the
   locale API, or is the key-splitting approach the expected one?
3. The spreadsheet engine registers only the English locale, so I had to keep
   sidebarExcel.language = "en" even in the Russian UI — "ru" there breaks number and date
   formatting. Might be worth a note in the docs for other pack authors.

Three questions.

1. Is the client-plugin addLanguage(...) path the supported way to add a language, or do you
   plan a first-class/community language-pack mechanism? If the API changes, I would rather
   adapt early than ship something that silently breaks.
2. In-tree dictionaries are type-checked against LocaleNamespaceMap, but an external pack has
   no such contract: the only way to learn the key set is to pull the English dictionaries out
   of an installed build. Would you publish the namespace key unions (or a generated JSON
   schema) as an artifact? That would let pack authors validate at build time instead of
   reverse-engineering the bundle.
3. Would you consider pointing users to community packs (a docs page, or just the dsh-plugin
   topic)? Right now a non-English user has no way to discover that a complete translation
   exists.

I know the repo is not accepting external PRs at the moment, so I am not sending code. If a
short docs page about adding a language pack would be useful, I can write the draft here in
the discussion and you can take whatever is worth taking.

Either way — the pack keeps itself honest: tools/check.mjs --reference fails if a new
release changes any key or placeholder, which makes it cheap to keep up with version bumps.
Thanks!