## A Hurdle No One Can Avoid

A Hurdle No One Can Avoid

Indie developers building browser extensions almost inevitably hit the same milestone: the product gains a few hundred overseas users in the Chrome Web Store, English, Japanese, and Portuguese comments start appearing in the reviews, and only then do you realize—your extension's messages.json contains nothing but Chinese.

That's exactly where I was stuck last month. A productivity extension with UI copy scattered across 40+ keys, including buttons, tooltips, settings page descriptions, and error messages. To support 12 languages, that theoretically meant 480 pieces of copy to translate. I got quotes from translation platforms and considered outsourcing, but quickly realized the problem went beyond just "translation":

• Lost context. The same word for "open" is "Open" on a button but might be "Enable" in a settings item—feeding it directly to machine translation produces a pile of awkward results.
• Placeholders easily broken. Copy contains variables like {count} and {url}, and careless translation often corrupts the placeholders, causing the extension to throw errors outright.
• Length constraints. Browser extension buttons have limited space; German and Finnish translations often run twice as long as the source text, blowing up the UI.

Handling these details by hand, I estimated: careful proofreading of each language would take half a day, and with 12 languages plus back-and-forth revisions, we're looking at three weeks minimum. For a solo product builder, those three weeks mean all new feature development grinds to a halt.

A Different Approach: Let AI Be a "Localization Engineer Who Understands Extensions"

Large language models happen to excel at exactly this kind of hybrid task: "translation + context understanding + format preservation." My approach wasn't to dump all the copy in at once, but to build a small workflow that pins down the AI's role.

Step 1: Organize the Source Copy with Usage Scenarios

First, I added a "scenario description" to every key in zh-CN/messages.json, for example:

"btn_open_panel": {
  "value": "打开面板",
  "desc": "工具栏按钮文案，空间受限，目标长度不超过12字符"
}

This step took me 40 minutes, but it's the source of all subsequent quality—with context, the AI no longer has to guess.

Step 2: Batch Generation with a Structured Prompt

Here's the core prompt template, ready to copy and adapt:

你是一名资深的浏览器插件本地化工程师。请将下面的界面文案从简体中文翻译成 {目标语言}。

要求：
1. 保留 JSON 的 key 和结构，只翻译 value 字段，原样返回完整 JSON。
2. 严格保留 {占位符}，例如 {count}、{url}，不得翻译或改动。
3. 每条文案后附有 desc 字段，说明其使用场景（按钮/提示/设置说明/错误信息），
   请根据场景选择该语言中最地道的表达，而不是字面直译。
4. 按钮类文案控制在 12 个字符以内；如原文很短，译文也应简短有力。
5. 错误信息需完整可读，可适当加长，但语气保持克制、不恐吓用户。
6. 对技术术语（如 token、API、cookie）保留英文原文，除非该语言有通行的译法。
7. 输出前自检：占位符是否完整、JSON 是否合法、是否有多余的逗号。

以下是源文案：
{粘贴整理好的 JSON}

For 12 languages, I ran them in three batches of 4, spot-checking placeholders and button lengths after each batch. The AI proactively distinguished scenarios for short phrases like "打开面板": "Open" on the button, "Show panel" in the menu—something I never got from machine translation when doing it myself.

Step 3: Write a Five-Minute Validation Script

I wrote a 20-line Node script to check three things: JSON parses correctly, placeholders match the source file one-to-one, and translated button keys meet the character limit. The run caught 3 missing placeholders and 2 oversized German buttons; I pasted the error output back to the AI for fixes, and it passed in one round.

Before and After: Time and Money

On cost, the token consumption for the entire workflow's API calls is tiny—480 short pieces of copy plus context is far less than processing a single long document. Actual costs depend on your chosen model's pricing page, but I can say this: at this scale it barely registers on your bill, especially since calling through an aggregation gateway lets you switch to cheaper models on the fly for these "short text + low risk" tasks.

The more important hidden benefit is iteration speed. After launch, I changed 6 pieces of copy, and regenerating all 12 languages took only 10 minutes. In the past, a single copy change meant another three-week cycle—which is exactly why many extensions' multilingual versions stay frozen at v1.0 forever.

Three Pitfalls I Hit

1. Don't stuff all 12 languages in at once. Having the model output every language in one go degrades quality noticeably later on, and the JSON gets truncated easily. Batching is the stable approach.
2. The desc field is the quality lever. I compared: without scenario descriptions, roughly 30% of button copy needed rework; with them, the rework rate dropped to single digits.
3. Validation must be done by a program, not a person. Placeholder issues are practically invisible to the naked eye. The script takes 5 minutes to write and pays off forever.

Final Thoughts

Multilingual support used to be a classic "know I should do it but keep putting it off" item for indie developers, because it's expensive, slow, and tedious. This workflow turned it into an afternoon's work—what you save isn't just three weeks, but the psychological barrier of pushing your product into the global market.

If you're working on something similar, you can start by registering an API relay account and running this prompt template once: https://api.thistoken.ai/register

---

Ready to try it yourself? Sign up at https://api.thistoken.ai/register to get your API key and start building.