mt — machine translation

Wire up DeepL / an LLM / a local translation model. Engines are currently mutually exclusive: only one MT is active at a time.

---

Declaration

{
  "id": "myteam.mt.deepl",
  "name": "DeepL 翻译",
  "version": "1.0.0",
  "target_app_version": "0.2",
  "type": "mt",
  "entrypoint": "deepl_mt.py:DeepLProvider",
  "tags": ["cloud"],
  "requires_hf": false,
  "supports_glossary": true,
  "supported_langs": ["en", "zh", "ja", "de", "fr", "es"],
  "target_langs": ["en", "zh", "ja", "de", "fr", "es", "it", "nl", "pl", "pt-BR"],
  "config_schema": [
    { "key": "api_key", "label": "DeepL API Key", "type": "password", "is_secret": true }
  ]
}

After enabling it, go to Settings → Machine Translation and select it as the active engine.

supports_glossary: true means your engine natively consumes the glossary / hot words (if omitted, the host infers it from type/tags/id: DashScope/Qwen as well as mt / assistant / middleware default to true).

---

Translatable languages (target_langs)

target_langs defines the full set of languages that users can activate in the caption "translate to" dropdown:

• Chinese and English are always present; languages activated via "View all N languages" enter the dropdown;
• The activation list is stored globally, but each model only shows entries inside its own capability catalog;
• After switching models, unavailable target languages automatically fall back to Chinese/English;
• When omitted, it falls back to supported_langs; if both are empty, the generic 33-language capability applies.

"target_langs": ["zh", "en", "ja", "ko", "yue", "zh-TW", "fr", "de", "es", "ru"]

⚠️ Do not declare target languages only in supported_langs: the latter constrains source languages. For the complete rules, code format (zh-TW / pt-BR / sr-Latn), alias normalization and the 33-language table, see Language codes & translatable languages.

The host renders the activation entry automatically for cloud and third-party local MT, so you do not need to build language UI yourself; plugins with a custom settings_view may call bridge.getMtTargetLangCatalog(providerId) to read the catalog.

---

Minimal implementation

from transbox.plugins.base import BaseMTEngineProvider
from transbox.mt.engine import Translation


class CustomMTProvider(BaseMTEngineProvider):
    def translate(self, text, source_lang="en", target_lang="zh",
                  glossary_context=None, target=None, source=None) -> Translation:
        return Translation(text=f"[译] {text}", complete=True)

Hard signature constraints:

• Callers are only allowed to pass base-class parameters (glossary_context / target / source are all base-class parameters).
• If the underlying SDK takes fewer parameters, adapt inside your implementation; passing source= / glossary_context= straight through to the underlying client is forbidden.
• On failure return an empty text, do not raise (the host treats it as "this sentence was not translated").

---

Incremental streaming translation (optional)

Override this when you use an LLM for translation and want the translation to appear as it is generated:

def translate_partial(self, text, source_lang="en", target_lang="zh",
                      committed_prefix="", glossary_context=None,
                      target=None, source=None) -> Translation:
    """committed_prefix = the prefix already committed to the display; you only need to translate the remainder."""
    ...

The default implementation falls back to translating the whole sentence.

---

Glossary integration

The host injects the glossary for the current language direction into glossary_context (a string) and performs replacement / restoration around translation. All you need to do is:

• concatenate glossary_context into your system prompt / request body in translate (LLM type), or
• use the engine's own glossary parameter for engines that support term bases (DeepL etc.).

Declaring supports_glossary: true tells the host to use your context (instead of only doing pre/post replacement).

---

Local offline MT

Same setup as local ASR: declare tags: ["local"] + model_artifacts and the host automatically takes over download and readiness checks (see asr § Local offline and Model artifacts).

Those that start their own local service (llama-server / Ollama / a custom HTTP service) must read the Local-service engine contract.

Want to hook up someone else's llama-server / Ollama / LM Studio? Just use the ready-made OpenAI-compatible plugin extensions/workshop_openai_mt — no need to write your own (it supports a custom endpoint / request template / response path).

---

Reference implementations

Directory	Type
extensions/community_cloud_hunyuan_mt/	Cloud API
extensions/community_hy_mt_7b/	Local service (llama.cpp; minimal model_artifacts + complete contract example)
extensions/workshop_openai_mt/	OpenAI-compatible (optional custom protocol)

---

Related

• Language codes & translatable languages — authoritative target_langs rules and the 33-language table
• Provider signatures & data types
• Local-service engine contract
• Model artifacts
• glossary — term base