[0.2.1-rc.3] "Application" and "Edit" stay English with a language pack while 中文 translates them

[fllsilva]

Environment**

• dsh Desktop 0.2.1-rc.3, Windows, profile desktop
• Client language pack installed as a plugin: pt-BR, 59 namespaces / ~2,540 keys, registered through ctx.locale.addLanguage + ctx.locale.register(ns, "pt-BR", dict)
• Preference persisted in the profile (cordis.patch.yml, - id: locale → preference: pt-BR)

Observation
The whole web UI follows the language pack, except the top native menus (Application, Edit). Switching the same setting to 中文 translates those menus, so they are localizable — just not through the client locale service.

Evidence
app.asar/lib/main.js (desktop shell, 516 KB) contains its own flat menu dictionary:

application: "Application",
edit: "Edit",
menuBar: "Application menu",
...
function resolveDesktopLocale(locale) {
  return locale.toLowerCase().startsWith("zh")
    ? { id: "zh-CN", messages: zh }
    : { id: "en", messages: en };
}

So the shell ships exactly two dictionaries (en, zh) and maps every other preference to en. resolveDesktopStartupLocale does read the shared locale.preference, but the result is collapsed to those two.

Why this matters for the "everything is a plugin" model
The client half of the harness is fully plugin-composed, and third-party language packs work well there. The native window chrome is the exception: it is built by the Electron shell (not a Cordis plugin), and it exposes no locale contribution point. A plugin that translates all 59 client namespaces still cannot touch two menu labels.

Request
One of:

1. expose a contribution point for shell chrome strings (e.g. a dsh.desktop.locale export in a bundle's package.json, or a locale resource the shell resolves via the same locale.preference with en fallback); or
2. document explicitly that the native shell is outside the plugin locale system, so language-pack authors do not promise full coverage.

A sketch that would be enough: the shell keeps en as fallback, and for any registered preference id with a matching exported menu dictionary, uses it.

Related
platformWireLocale() in the same bundle collapses every non-zh language to en_US for Platform request bodies — probably intentional, but worth stating if server-side locale ever becomes user-visible.

[fllsilva]

Independent corroboration (other language-pack authors)

Two public projects hit the same limit, through different paths:

1. jonascarv/dsh-plugins · locale-pt-br — 62 namespaces / 2,799 strings. Its client.js is generated only from dicts/*.json (build-client.cjs emits nothing but addLanguage + register), the host half is export function apply() {}, and there is no menu/shell dictionary at all. In short: the native menus are not handled.
2. sayho-pm/dsh-locale-pack — 29 languages / 88,337 entries. Its README states explicitly: "The menu bar, the right-click menu, and the update dialog belong to the desktop shell, so this pack does not change them."

Conclusion: the limit is not a lack of namespace coverage; it is the desktop shell sitting outside the plugin locale system. Citing both projects in the report shows the case is not isolated.