Language codes & translatable languages

Authoritative page: how to write supported_langs / target_langs, how the host consumes them, and how third-party plugins should verify them. An MT plugin's target languages are driven entirely by its own target_langs capability catalog — the host no longer ships a fixed language list.

Don't mix the two fields

Field	Scope	Where the host consumes it	When omitted
`supported_langs`	Source language capability / informational display	Source-language clamping (`inboundSupportedLangs`), plugin cards	`[]` = unrestricted
`target_langs`	Translation target capability	Caption "translate to" dropdown, language activation dialog	Falls back to `supported_langs`; if both are empty = generic 33-language capability

Common mistake: declaring only supported_langs. When an MT plugin describes "which languages it can translate into", it must use target_langs. Otherwise the host treats supported_langs as the target ceiling too — a cloud model with 10 source languages would unexpectedly expose only 10 target languages.

How an MT plugin declares it

json

{
  "id": "myteam.mt.deepl",
  "name": "DeepL 翻译",
  "type": "mt",
  "entrypoint": "deepl_mt.py:DeepLProvider",
  "target_app_version": "0.2",
  "supported_langs": ["en", "zh", "ja", "de", "fr", "es"],
  "target_langs": ["en", "zh", "ja", "de", "fr", "es", "it", "nl", "pl", "pt-BR"]
}

Always include zh and en if the model supports them: captions keep them by default; if missing, the host falls back to the first two catalog entries.
Write an array in the manifest; strings such as "zh, en; ja" are also tolerated and split at load time.
target_langs only applies to type: "mt"; other types ignore it.

What it looks like at runtime

With no extra languages activated, the dropdown only has the default Chinese/English pair:
- Inbound track: zh → en
- Outbound track: en → zh
In Settings, "View all N languages" lets users activate any language inside the model's capability catalog; activated entries appear in both tracks' translate-language dropdowns.
The activation list is stored globally, but each model only shows entries from its own target_langs: activating ja on a 33-language model does not make ja appear after switching to MT-Flash (zh/en only).
When switching models or deactivating a language, a currently selected but unavailable target automatically falls back to the default Chinese/English pair.

The host renders the activation entry uniformly for all MT plugins (cloud / third-party local); third-party plugins do not need to build their own UI. Plugins with a custom settings_view can also use the runtime API below.

Code format & normalization rules

Primary code: 2–3 letters (zh / en / yue / haw).
Optional script: 4 letters (zh-Hans / sr-Latn).
Optional region: 2 letters or 3 digits (zh-TW / pt-BR / es-419).
Optional variants: 5–8 alphanumeric characters, multiple allowed.
Case-insensitive; known languages are normalized to the host's canonical form:
- zh-tw / zh_hant / zh-HK → zh-TW
- ZH → zh
- pt-br → pt-BR
- zh-CN / zh-Hans / cmn → zh
- iw → he, in → id, ji → yi
Invalid codes (spaces, one-letter subtags, non-letter primary codes, etc.) are silently dropped and never block plugin loading.

Unknown but well-formed codes are preserved as-is; the dropdown shows the code itself, while common languages display a localized name.

Hunyuan MT2 / MT-Plus full 33-language set

Code	Name	Code	Name
`zh`	Chinese (Simplified)	`en`	English
`ja`	Japanese	`ko`	Korean
`yue`	Cantonese	`zh-TW`	Chinese (Traditional)
`fr`	French	`de`	German
`es`	Spanish	`ru`	Russian
`it`	Italian	`nl`	Dutch
`pl`	Polish	`cs`	Czech
`uk`	Ukrainian	`vi`	Vietnamese
`th`	Thai	`id`	Indonesian
`ms`	Malay	`tl`	Filipino
`hi`	Hindi	`bn`	Bengali
`ur`	Urdu	`km`	Khmer
`my`	Burmese	`ar`	Arabic
`tr`	Turkish	`fa`	Persian
`he`	Hebrew	`bo`	Tibetan
`kk`	Kazakh	`mn`	Mongolian
`ug`	Uyghur

Reuse this list to declare a full-language model; trim it to the actual capability for partial models.

Runtime API (custom settings view / QML)

Standard plugins don't need this; the host settings page already provides the language entry. Plugins that draw their own UI can read:

bridge member	Return value	Purpose
`bridge.getMtTargetLangCatalog(providerId)`	`[{name, en, code}]`	Capability catalog for the given MT plugin (already filtered by the model's enabled state)
`bridge.mtActiveLangs`	`["ja", "fr", ...]`	Extra languages activated by the user (excluding Chinese/English)
`bridge.setMtActiveLangs(list)`	`bool`	Persist the activation list; the host converges the current target language automatically
`bridge.inboundTargetLangs` / `bridge.outboundTargetLangs`	`["zh", "en", ...]`	Target languages actually selectable on the current track

Pass the plugin's full id as providerId; for the built-in local MT you may also pass the short settings name local.

Self-check list

[ ] type is mt and target_app_version is present
[ ] target_langs is an array containing zh and en (when supported by the model)
[ ] Target languages are not declared only inside supported_langs
[ ] Codes follow the format above; case/aliases may be left to the host
[ ] Switching to the model in Settings → "View all N languages" shows the expected catalog

Language codes & translatable languages ​

Don't mix the two fields ​

How an MT plugin declares it ​

What it looks like at runtime ​

Code format & normalization rules ​

Hunyuan MT2 / MT-Plus full 33-language set ​

Runtime API (custom settings view / QML) ​

Self-check list ​

Related ​