Let language packs supply plugin display text (titles and descriptions)

[sayho-pm]

Motivation

The harness UI ships English and Simplified Chinese, and dsh-client-locale exists so that language packs can add more languages. That works for screen strings: a plugin registers its dictionaries through ctx.locale.register(ns, ...), and any language pack can fill that namespace. As one measurement, our language pack covers both experimental client plugins completely, agent-team at 25 of 25 keys and voice-input at 101 of 101, so those panels already read in Korean and Japanese.

Plugin display text does not work that way. readPluginMeta(specifier, parentURL) in dsh-app-boot builds the title and description from the package's own files only:

Step	Code	What it reads
anchor	optionalResourcePath(specifier + '/locale/en.json')	the package's own locale/ directory
siblings	dictionariesOf() takes every *.json next to it	that directory only
fallback	localizedText('description', …, manifest.description)	package.json

On the client side, resolveText(text) returns a plain string unchanged and walks the locale fallback chain for a map. It never consults registered dictionaries.

The consequence is visible on 0.2.0-rc.2. With the UI set to Korean or Japanese, the rows for the plugins bundled with the app stay English, because those packages ship locale/en.json and locale/zh.json only:

• dsh-experimental-agent-team-profile: "Agent Teams"
• dsh-experimental-auto-review: "Auto Authorization Review"
• dsh-experimental-schedule-bundle: "Automation tasks"
• dsh-experimental-voice-input-bundle: "Voice input"

A reader cannot work around this. Those packages live inside the signed desktop app.asar, and adding a locale file breaks the seal (codesign --verify --deep --strict reports a sealed resource is missing or invalid). This repository also does not accept external pull requests at the moment, so there is no way for the community to contribute the missing files either.

Behavior

When a plugin's display text is resolved and the package has no entry for the active language, consult a language-pack-provided source before falling back to English.

One shape to consider, though any equivalent would help:

• keep the package's own locale/*.json as the primary source, so authors stay in control of their own text
• add a secondary lookup, for example <profile>/plugin-locale/<package-name>/<lang>.json, or a namespace a language pack registers through ctx.locale
• fill only what the package does not define, so an override can never replace the author's own title or description
• optionally mark the row when its text came from a pack

That keeps the trust model intact while making display text localizable the same way screen text already is.

Scope

This is not only about the four bundled experimental packages. The ecosystem has thousands of plugins and most authors will ship English only, so a language pack is the only realistic way for a reader of another language to get a localized plugin list. It also removes the need to touch signed application bundles.

To be explicit about what this does not change: a plugin's own screens. Screen strings are localizable only when the plugin registers them through ctx.locale.register. A plugin that hardcodes its text stays as it is. Display text is different, because it lives in the manifest and in the package's locale/ files rather than in the plugin's code. That makes it the one part of every plugin that a pack can fill without touching the plugin at all.

The Korean, Japanese, and Traditional Chinese text for the packages above already exists on our side and could be carried by a pack under this mechanism, if that is useful.

[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