dsh-think-translate
Display-layer translation for the DSH web app: thinking chain, task cards, and optional answer text, in 8 target languages (local Ollama / any OpenAI-compatible or Anthropic endpoint / Google / Bing, fail-open)
The plugin will be installed here. Keep web if you are unsure.
npx -y @deepseek-ai/dsh plugin --profile web add dsh-think-translate@1.2.4
Think Translate is published as dsh-think-translate and currently resolves to version 1.2.4. The Hub verifies its manifest and preserves the exact installation source for reproducible installs.
Translate the reasoning / thinking chain (chain-of-thought), task cards and answers of the DeepSeek Harness Web UI into one of 8 target languages — in real time, on the display layer only. The originals stay untouched in the transcript, and the translated text never enters the model context.
DeepSeek-class models often reason in Chinese — or in whatever language they happen to think in. dsh-think-translate renders the Think row, task cards and answer in your language while you watch, like subtitles for the model's thinking.
/v1/chat/completions gateway) or native Anthropic Messages API endpoints (Claude) from the settings panel: name, type, base URL, API key, modelsettings.yaml (llm-pi-ai.providers, e.g. linuxdo-hub, coding-hub) are auto-discovered and appear in the chain as read-only "DSH" entries, and one button in settings rescans and adds them all at once; keys are resolved from .credentials.yaml at runtime and never written to the plugin's config. The harness's own default route counts too: when agent-default-model points at deepseek-official, DeepSeek's API is offered as one more DSH entry# Option 1: npm (recommended)
dsh plugin --profile web add dsh-think-translate
# then restart web
# Option 2: GitHub
dsh plugin --profile web add github:UncleK/dsh-think-translate
# Option 3: manual (junction + patch)
# 1. link the package into the profile's node_modules
New-Item -ItemType Junction -Path "$HOME\.dsh\profiles\node_modules\dsh-think-translate" `
-Target "<repo path>"
# 2. add to "$HOME\.dsh\profiles\web\cordis.patch.yml":
# - insert:
# - id: dsh-think-translate
# name: dsh-think-translate
# 3. restart web
Third-party client plugins load through DSH's client module graph, and that graph is composed once per process — a composition that failed is remembered in memory until the process restarts. So these three things commonly bite right after an upgrade:
client bundles not found; run \pnpm run build` before launch— the new client packages ship unbuilt: runpnpm run buildin the harness checkout, then startdsh web` again.dsh web; refreshing the page alone is sometimes not enough.ollama service is not serving that model directory: check ollama list (or GET /api/tags) and the OLLAMA_MODELS the running service actually uses. When the model files live on another drive, a directory junction can point the service's default directory at them.Nothing to configure on the plugin side: it declares no ordering dependency on DSH internals (it binds only to the slots service, plus an optional @deepseek-ai/dsh-client-ui-primitives), so it runs on both older DSH (≤ 0.1.1-rc) and the current line (≥ 0.1.2-alpha.1, 0.1.5-rc.1 included).
llm-pi-ai.providers) appear automatically as read-only entries (badge "DSH"); their checkbox adds/removes them from the chain. The Import from DSH config button right below the list rescans on click and adds all of them in one go — there is no base URL and no key to retype, because the key is resolved from DSH's own credentials at request timeapiKeyEnv) instead of carrying the key: presets fill that in, and a DSH row brings its own. The key is resolved per request and never written to config.json, and such a row shows an env:NAME badge. The edit form has no env field (the value survives an edit untouched), but emptying a field really removes it — the field is sent as an explicit deletefallback still exists in config.json for anyone who wants it (off by default)browser → POST /_xlate/translate (same-origin, no CORS)
→ host provider chain (fail-open, user-ordered):
chain: [provider1, provider2, ...] ← drag-reordered in settings
each provider is one of:
google (gtx via Node CONNECT tunnel / curl through system proxy)
bing (ttranslatev3 via curl)
openai (OpenAI-compatible /chat/completions — Ollama local or any gateway)
anthropic(Anthropic Messages API /v1/messages)
fallback chain (config-only, off by default) tried when the primary chain fails entirely
→ browser-direct fallback
config.json (runtime, gitignored): chain (ordered ids), fallback (enabled + chain, config-only), providers (per-provider type/enabled/baseURL/apiKey/apiKeyEnv/model). Old priority-based configs auto-migrate. A provider that declares apiKeyEnv resolves its key from that environment variable at request time (the literal apiKey stays as the fallback), and no env-resolved key is ever written back to config.json. A null field in a config patch deletes that field, which is how the UI clears one.settings.yaml (llm-pi-ai.providers) and .credentials.yaml (refs) on load; discovered providers are marked source: "dsh", resolved keys stay in memory (never written to config.json), and a /_xlate/dsh-scan route re-reads them on demand.lib/index.js): provider adapters, ordered chain + fallback execution, LRU cache (600), per-provider override for tests, /_xlate/models listing, /_xlate/model/pull + pull-status model download management (auto-configures on completion)lib/client.js): 8-language UI, drag-reorderable provider list, add/edit/delete custom providers, per-provider test buttons, sentence/paragraph-batched translation, streaming Think rows, localStorage persistence (settings + translation cache)lib/client.js is the browser bundle (source = artifact), lib/index.js is the host ESMUI_TEXT dictionary in lib/client.jsMIT