Localize the Desktop shell copy (menu bar is English-only outside zh)

[Spelvi]

Hi — first, thanks for the harness. The Web UI is fully translatable through the locale registry, and with the community Spanish pack applied the whole app reads in Spanish. The one part that stays English is the Desktop shell: the application menu bar (Application, Edit → Undo / Redo / Cut / Copy / Paste / Delete / Select All) and its entries (About DeepSeek Harness, Check for Updates…, Manage dsh Command…, Exit).

Why it happens (from the shipped 0.2.0-rc.2 build): the Electron main process ships exactly two shell dictionaries, and anything else resolves to English:

// app.asar/lib/main.js — @deepseek-ai/dsh-desktop-host
/** Resolve Electron's locale to one shipped Desktop dictionary. */
function resolveDesktopLocale(locale) {
  return locale.toLowerCase().startsWith("zh")
    ? { id: "zh-CN", messages: zh }
    : { id: "en", messages: en }
}
/** Choose a built-in dictionary from the shared preference, then ordered OS languages. */
function resolveDesktopStartupLocale(preference, languages) {
  const selected = preference?.toLowerCase()
  if (selected === "zh" || selected === "en") return resolveDesktopLocale(selected)
  for (const language of languages) {
    const primary = language.toLowerCase().split("-")[0]
    if (primary === "zh" || primary === "en") return resolveDesktopLocale(primary)
  }
  return resolveDesktopLocale("en") // ← es / fr / de / … land here
}

So with locale.preference: es (or a Spanish OS) the shell silently falls back to English. This is separate from the client-side registry discussed in #4558, because the menu lives in the main process.

Request

1. Extend the shell dictionary beyond en/zh. Ideally reuse the same extensibility Feature request: let community plugins register new UI languages (i18n) #4558 asks for (a locale pack registering shell copy as well as UI copy), so the community can carry the translation; adding es to the built-in table would already fix the gap for a large user base.
2. Native Electron roles (Undo/Redo/Cut/Copy/Paste/Select All) render in English on Windows even when the OS language is Spanish. If the roles are kept, explicit labels from the shell dictionary would localize them too.

Context: the community pack dsh-locale-pack covers 2528/2528 Web UI strings for 0.2.0-rc.2, and documents the menu bar, the right-click menu and the update dialog as out of scope precisely because they belong to the desktop shell. Same for dsh-locale-es.

Environment: DeepSeek Harness Desktop 0.2.0-rc.2, Windows x64, Node 24, UI language es.

Happy to test a Spanish shell dictionary if you want it validated before release.

[Spelvi]

Confirming this is still the case in 0.2.1-rc.5, and adding the right-click menu to the list.

With the community locale pack (dsh-locale-pack) the Web UI is fully Spanish, which makes what is left in English stand out more:

• Application menu: Application, Edit, About DeepSeek Harness, Check for Updates…, Manage dsh Command…, Exit.
• Right-click menu in any text field: Undo, Redo, Cut, Copy, Paste, Select All.

The second one comes from the context-menu handler in lib/main.js: it builds Electron roles and only relabels them when the role exists in the shell dictionary. Since the shell falls back to English for es, those labels stay English too.

The result is a mixed-language app. Everything inside the window is Spanish except the two menus owned by the shell, which reads as a bug rather than a limitation.

A shell dictionary with just those labels would fix the visible part; exposing the shell copy to locale packs would let the community carry it, the same way the UI strings are carried today.

Happy to test it, or to send the Spanish strings, if a shell dictionary lands.