Bundle translation worked, but the UI still showed Chinese. The visible text
does not come from plugin bundles at all: plugin descriptors, model and
provider names, and settings descriptions reach the browser as JSON over /api.
Measured in the Plugins view, all 76 distinct Chinese characters came from
/api/pluginManager/listBundles, which the bundle seam cannot see.
Add a second seam on the typert gateway. It resolves its own dispatchRpc per
request, so overriding that instance method intercepts every /api call without
claiming the interceptor slot the gateway already owns.
Rewriting JSON is deliberately narrow. An allowlist covers the six endpoints
that return server-authored copy; everything else, notably /api/session/list,
carries the operator's own prompts and transcripts and is left alone.
Three shapes needed handling, each found by testing against the live server:
- Locale maps ({ zh, en }) resolve to the English sibling, because the author's
own English beats a dictionary pass.
- Bilingual descriptors joined by " · " keep their English half, which covers
every such descriptor without a dictionary entry.
- Keys are not always trustworthy: dshmarket publishes its bilingual string
under `en` and a short English one under `zh`, and one plugin repeats the same
string under both. A locale map is therefore detected by shape, and an English
sibling is only used when it is itself free of Chinese.
Also harvest author-written { zh, en } pairs from plugin locale maps (331
entries) as the highest-precedence dictionary source, and extend the curated
supplement with the vocabulary that unlocks whole families at once: "免费" alone
covers about twenty model names.
Measured on a live server: 107 -> 0 visible Chinese characters across the home,
Plugins, and Automation tasks views, 0 residual Chinese across all six
allowlisted endpoints, no page errors, and both bundle combos still compile.
The plugin never translated anything. Its client half monkey-patched locale
internals that do not mutate the locale snapshot, and its DOM walker was
disabled after it crashed the marketplace UI. Nothing else was left.
Move translation to the bundle transport instead. Every third-party bundle is
served through /plugins/ by the clientModules service, so wrapping
bundleResource reaches all of them before any code runs, with no client-side
ordering race and no React tree mutation.
Two bugs surfaced while verifying against the live server:
- The script check tested the path before the query string, but combo requests
are /plugins/??a/client.js,b/client.js&rev=... where the path is just
/plugins/. Every request was rejected.
- bundleResource yields a Buffer, not a string, so the string guard rejected
every request a second time.
Rewriting is all-or-nothing per literal: Chinese has no word boundaries, so
replacing known keys wherever they appear corrupts larger words (当前工作区
became "Saat IniWorkspace"). A literal is translated only when every Chinese
character is covered by a dictionary entry. Two upstream entries were Malay
rather than English and are now corrected.
Each rewritten bundle is parsed with new Function before being served; if that
fails the original bytes are returned, so a bad dictionary entry cannot break
the UI. Verified against the live bundles: both combos compile, and a browser
A/B shows 105 Chinese characters in the Plugins view without the plugin and 0
with it.
The dictionary grows to 1,195 entries (45% of literals, zero partial rewrites)
via a curated supplement merged last so it overrides harvested sources.
