dsh-espanol

Spanish (es) locale for the DeepSeek Harness web GUI.

This is a community plugin: it registers Spanish dictionaries for the 29 UI namespaces and adds Español to the language selector. It is opt-in — it never forces Spanish on anyone. A user whose browser asks for Spanish (and who has not stored an English/Chinese preference) starts on Español automatically; everyone else keeps the language they had.

• Plugin (bundle): dsh-espanol
• Topic: dsh-plugin
• Scope: 29 namespaces, 718 strings (src/dictionaries.json)

Install

DeepSeek Harness ships plugin distribution through installable profile bundles (dsh plugin --profile <name> add <package-or-git-spec>). This package is both the plugin and its bundle: installing it mounts the espanol-ui row into the web composition.

From npm

dsh plugin --profile web add dsh-espanol

From Git (no npm publish needed)

dsh plugin --profile web add github:<your-user>/dsh-espanol#v0.1.0

> Which profile? The web GUI is served by the web profile (dsh web is dsh --profile web). Installing into default (the shared base template) works but does not mount the plugin into the running UI — install into web (or the profile your dsh web actually uses). Verify with dsh plugin --profile web list.

Restart the web session (or reload the page) and open Settings → Language: you will see 中文 / English / Español — the interface was 中文 first and English second; Español is appended.

> Profile installation requires pnpm on the host PATH (the dsh plugin command is a pnpm forwarder).

How it behaves

• Registers the es dictionary for every namespace the shipped UI already localizes (common, conversation, workspace, cordis, settings.*, subagent, trajectory, workflowRun, job, goal, plan, feedback, question, permission.access, skill, sidebar, deliverables, slash.menu, command, session-log-download, model, settings.theme, directory-browser, …).
• Never changes the active language on mount: English and Chinese users are untouched. Only a browser whose primary language is Spanish — with no stored zh/en preference — auto-selects Español, mirroring the built-in browser detection.
• Switching to English or Chinese persists exactly as before (the plugin delegates those writes to the built-in runtime).
• Placeholders ({count}, {name}, {command}, {labels}, …) are preserved; technical terms stay untranslated (token, TTFT, LLM, API, Cmd/Ctrl, plugin, Cordis, HMR).

Known limitations and deferred work

1. The Spanish preference is not persisted across restarts (v1). The host locale settings schema only accepts preference ∈ ['zh', 'en'], so a client-only plugin cannot store es. The workaround shipped here is browser auto-detection: a Spanish-speaking browser lands on Español on every boot without persisting anything. Making the choice durable requires a host half that extends the locale settings schema — tracked as deferred work. 2. Two string groups remain in English by design: command descriptions in the / menu and the permission-preset names (Read Only, Workspace Write, Full access) come from host composition data, not client locale dictionaries, so this plugin cannot translate them. Editing those requires changing the host cordis.yml configuration.

Development

The artifact is generated, not hand-written:

node scripts/build-client.mjs   # reads src/dictionaries.json -> writes lib/client.js

• src/dictionaries.json — the editable Spanish dictionaries (one object per namespace).
• lib/client.js — the browser bundle in the Loader shape (window.__ModuleLoader__.load({ id: 'dsh-espanol', factory })), committed so Git/npm installs need no build step.

Key sets mirror the current upstream zh dictionaries; a key the active runtime does not have is ignored, and a key it has but this plugin does not falls back to the English text.

License

MIT — see [LICENSE](LICENSE).