dsh-language-guard

LIMITATIONS

Known limitations

- **The constraint wording is fixed Simplified Chinese.** Only the language name and code are substituted, so with `targetLanguage: "en"` the injected text reads "…一律使用English（语言代码 en）". Models handle this fine, but the prose is not localized. Localizing the templates is a future change. - **The Periodic reminder is visible in the chat UI**, collapsed into one line reading "上下文注入 · language-guard · 语言自检". The English identifier `language-guard` **cannot be hidden** — the client renders `source.kind` verbatim as the injection label, exactly as it does for the official `agent-instructions` and `skill-invocation`. Localizing it would require a custom `conversation.chat.node` renderer for the context node; the first release does not do that. - **The Client half has no turn counter**, so the panel cannot show "the next injection lands on turn X". - **The quick switch menu lists five presets plus one "Custom" entry.** Custom BCP-47 tags must be typed into the settings field; in Manual mode with a value outside the presets, the menu gains a checked "Custom: <language>" entry so that six unchecked rows no longer look like "nothing was ever set". The menu cannot enumerate arbitrary tags — switching to another custom value still goes through the settings field. - **Absolute locking, no per-turn escape hatch.** A deliberate trade-off: the plugin is "set once, applies throughout", so a turn-level instruction such as "answer in English *this once*" does **not** switch it away — change the setting or use `/language` instead. That is the opposite stance from "switch per turn"; if you need per-turn switching, this plugin is the wrong tool. - **It cannot detect whether `dsh-context` is installed**, so the hint is permanent (see above). - **Periodic never wakes an idle session.** `agent/pre-step` only fires while a turn is running, so no message means no reminder — a language guard should not generate conversation on its own. - **The `mid` position could be squeezed by future plugins.** If another plugin inserts a section between order `5000` and `9000`, the "after the tool docs" semantics get diluted. The fix then is to raise `mid` to `8900` (still before deliverable references at `9000`); failing that, fall back to Basic, which does not depend on `mid`. - **It cannot tell Simplified from Traditional Chinese.** DSH ships exactly two built-in interface languages, `zh` and `en` (`dsh-client-locale/lib/index.js:11`, `LOCALE_IDS = ["zh", "en"]`), and `zh` does not distinguish the two scripts — while the Host side cannot see the system language. So when the interface language is Chinese, auto mode always resolves to `zh-CN`. Users who need Traditional output should switch the language mode to Manual and pick `zh-TW`. The same holds for Japanese and Korean: on a standard install auto mode can only resolve to `zh-CN` or `en`, so pick 日本語 / 한국어 manually — if you installed the matching external language pack, its tag is passed through as-is. - **It does not cover the API `tools` parameter itself.** The real tool schema sent to the model lives in the request's `tools` parameter, not in the system prompt; this plugin only asks the model, on the prompt side, to write the `description` parameter in the target language. It cannot rewrite the English wording in the schema. If the model does not comply, tool card titles stay English — an inherent limit of a prompt-level constraint, not a configuration problem. - **It does not follow the operating-system language.** The plugin reads the interface language you selected in DSH settings, not the OS language. DSH's Host process runs with `ELECTRON_RUN_AS_NODE=1`, so Electron's `app.getLocale()` is out of reach; Node's `Intl` in that process always reports `en-US`, which would misclassify Chinese users as English — so we chose not to use it. - **Auto mode follows the interface language, not the language you type in.** With a Simplified Chinese UI, asking in English still gets a Simplified Chinese constraint — that