Problem
The i18n translation pipeline (translate-i18n.ts) relies on the translation model to translate each English term, but there's no mechanism to keep a given English term mapped to a consistent target-language translation. As a result, the same English term can be rendered differently across pages.
A concrete example I ran into while working on the Korean docs: "custom node" was translated as both 맞춤형 노드 and 커스텀 노드 in different files (roughly 340 vs 90 occurrences). I've opened #1123 to unify this one, but the underlying issue is general — any term the model translates by judgment can drift, and re-translation when the English source changes can reintroduce the inconsistency.
This isn't Korean-specific. Since zh/ja go through the same path (the only term control today is preserve_terms, which keeps terms in English rather than mapping them to a chosen translation), the same drift can happen in any language.
Possible direction (open to maintainer's call)
One option would be an optional per-language term map in translation-config.json, alongside preserve_terms — e.g. something like:
"term_mappings": {
"ko": { "custom node": "커스텀 노드" }
injected into the translation prompt so the model uses the agreed term, the same way preserve_terms works today.
I want to be clear that I'm raising this as a technical consistency issue, not to push particular word choices. What the "right" term is for each language should be up to the maintainers and each language community, not decided unilaterally — I'm just flagging that there's currently no place to record such a decision once it's made.
Happy to leave it if it's not a priority.
Problem
The i18n translation pipeline (
translate-i18n.ts) relies on the translation model to translate each English term, but there's no mechanism to keep a given English term mapped to a consistent target-language translation. As a result, the same English term can be rendered differently across pages.A concrete example I ran into while working on the Korean docs: "custom node" was translated as both 맞춤형 노드 and 커스텀 노드 in different files (roughly 340 vs 90 occurrences). I've opened #1123 to unify this one, but the underlying issue is general — any term the model translates by judgment can drift, and re-translation when the English source changes can reintroduce the inconsistency.
This isn't Korean-specific. Since zh/ja go through the same path (the only term control today is
preserve_terms, which keeps terms in English rather than mapping them to a chosen translation), the same drift can happen in any language.Possible direction (open to maintainer's call)
One option would be an optional per-language term map in
translation-config.json, alongsidepreserve_terms— e.g. something like:
injected into the translation prompt so the model uses the agreed term, the same way
preserve_termsworks today.I want to be clear that I'm raising this as a technical consistency issue, not to push particular word choices. What the "right" term is for each language should be up to the maintainers and each language community, not decided unilaterally — I'm just flagging that there's currently no place to record such a decision once it's made.
Happy to leave it if it's not a priority.