## First, a Typical Failure

First, a Typical Failure

Adding multilingual support to a browser extension sounds like exactly the kind of task AI excels at: toss the strings from manifest.json and the _locales directory at the model, have it translate into a dozen languages, and get results in minutes.

That's exactly how I did it the first time. I pasted a Chinese language pack with over two hundred key-value pairs straight into the chat, along with "Translate into English, Japanese, Korean, Spanish, and 12 other languages; keep the JSON format." The model indeed returned 12 complete, well-formatted JSON files. Everything looked great.

Until user feedback started coming in:

• In the Turkish version, "Clear cache" was translated into a word with a slang meaning in the local dialect;
• In Japanese, the same "Settings" button had two keys translated as 「設定」 and 「セッティング」 respectively, creating an inconsistent UI style;
• The Russian translations were 40% longer than the English, causing button text to overflow;
• Several keys had their placeholder {count} translated as 「{カウント}」, causing runtime errors.

The problem wasn't the model's capability—it was that I treated it as a "translation vending machine": one-time input, one-time output, with no quality control steps in between.

Three Common Traits of the Failed Approach

In retrospect, this kind of failure usually stems from the same pitfalls:

Pitfall 1: No glossary, so the model has to guess. UI strings aren't isolated sentences. Terms like "Tab," "Clip," and "Focus Mode" need consistency across the product, but if you don't say so, the model will produce its own best answer each time—and its best answers may contradict each other.

Pitfall 2: No length constraints. UI copy isn't documentation; buttons can't fit long sentences. The four-character Chinese “重新检测” (re-detect), translated literally into German, might become an entire subordinate clause.

Pitfall 3: Generating all languages at once multiplies errors. A flaw in one prompt gets copied verbatim into 12 languages, and you have to fix it 12 times during rework.

The Right Approach: Split One Translation into Three Phases

Later, I restructured the process into "glossary first → batch translation → back-translation verification," with AI playing three different roles.

Step 1: Have AI Act as a "Terminology Consultant" First

Don't rush to translate. First, give the model the source strings and product context, and have it produce a multilingual glossary:

你是一个软件本地化专家。我正在为一个浏览器插件做多语言支持。
请先阅读以下源文案(中文),完成术语整理任务:

1. 从文案中提取所有产品核心术语(功能名、按钮名、专有名词);
2. 为每个术语确定英文标准译法,注意这是浏览器插件语境,
   参考Chrome官方界面用语习惯;
3. 标注哪些术语需要保持英文不译(如产品名);
4. 对每个术语给出简短的理由说明。

源文案如下:
{粘贴你的locales JSON或文案列表}

Manually review this once—ten minutes. It lays the foundation for consistency across all subsequent languages.

Step 2: Batch Translation with Constraints

Once the glossary is confirmed, start translating—batched by language, chunked by batch, processing one language at a time. Here's the prompt template, ready to copy and use:

你是一个专业的软件界面本地化译者。

## 任务
将下面的浏览器插件界面文案从{源语言}翻译为{目标语言}。

## 必须遵守的术语表
{粘贴第一步产出的该语言术语对照表,格式:原文=译文}

## 硬性规则
1. 保持JSON结构完全不变,只翻译value,不改动key;
2. 保留所有占位符原样输出,如 {count}、{name}、%s 不得翻译;
3. 每条译文长度尽量不超过原文的1.3倍,这是界面按钮文案,
   过长会被截断;如无法缩短,请在末尾加 [LONG] 标记;
4. 按钮文案使用祈使句,不用敬语除非该语言界面惯例要求
   (如日语需使用です・ます体);
5. 不确定的俚语敏感词,不要自行发挥,加 [CHECK] 标记;
6. 只输出JSON,不要任何解释。

## 待翻译文案
{粘贴本次批次的JSON,建议每次不超过50条}

Two details are worth emphasizing: the [LONG] and [CHECK] markers force the model to explicitly surface "low-confidence" items instead of blindly making things up. This is far more reliable than pursuing "fully automated with zero intervention"—AI is best at flagging suspicious spots, so humans only review the marked items, and review costs plummet.

Step 3: Back-Translation Verification

Finally, run one more round: have the model back-translate the translations into Chinese and compare the semantics with the original. This step catches most "fluent but wrong" translation issues—especially in that Turkish failure, back-translation would have exposed it immediately.

Before and After

The real-world feel: after switching the process, adding a new language went from a "pray-and-release" operation to a routine of "run the template, scan the flags." When subsequent extension iterations add new copy, you just reuse the same glossary and templates for incremental translation—the marginal cost is minimal.

One Step Further

If your extension has a large volume of copy and many languages, you can take this further: use an API to chain the three phases into a script, store the glossary in a database, run translation tasks in a queue, and aggregate flagged items into a review checklist. Route model calls through a unified OpenAI-compatible gateway—use cheap models for text work like Chinese and Japanese strings, and stronger models for back-translation verification, and your cost structure immediately becomes much healthier. For specific model pricing, check the official pricing page; it's usually token-based, and short-text batch tasks like these don't cost much.

If you want to try this workflow, start by registering an API account and running the Step 2 prompt template directly as a system prompt: https://api.thistoken.ai/register

Multilingual support isn't a one-time translation task—it's a production line with quality control. Put AI in the right position, and it's far more reliable than you'd expect.

---

Tired of juggling provider integrations? Register at https://api.thistoken.ai/register and call every model through one base_url.