如何本地化 AI 生成的应用

本文讲解如何先国际化、再本地化一个 AI 生成的应用：翻译键、语言文件、字符串提取、术语表，以及能经受界面频繁变动的自动化。globalize.now 是 AI 驱动的本地化基础设施，每次推送都让这些词条与 Git 保持一致：一次配置，每次推送自动同步，省去手动文件往返。想了解 AI 优先的代码库为何常常跳过 i18n 层，请读AI 代码搞砸了本地化，却没人来修。想了解不同工具时代的行业背景，请看本地化开发的 3 个阶段（以及 AI 为何改变一切）。仓库还很混乱时如何选择供应商，请读 globalize.now vs Lokalise vs Crowdin，实操版的全球化流程见如何用 globalize.now 让你的应用走向全球。

---

“本地化 AI 生成的应用”到底指什么？

**本地化（l10n）**是用户看到的结果：符合其 locale 的语言、复数、日期、货币和布局。

**国际化（i18n）**是工程师要先做的事：让用户可见的文本可寻址、可复用，并能安全地大规模翻译。

大多数“我们还没法本地化”的阻碍，其实都是 i18n 的阻碍。把架构理顺一次，本地化就从一场考古变成日常运营。

---

选工具之前，i18n 架构清单上应该有什么？

在选择翻译协作软件或翻译供应商之前，先确认以下基础设施已经具备，或计划按这个顺序引入：

• 运行时 i18n 库：适配你的技术栈（React、Next.js、Rails 等），界面字符串只用一种受支持的写法。
• 稳定的翻译键：带命名空间、分层级，而不是拿英文句子当 ID。
• 语言文件（JSON、PO、YAML）：提交到仓库，或在 CI 中生成。
• ICU 风格的复数和变量：用于 "{count} items" 这类动态短语，让译者可以安全地调整语法语序。
• 字符串提取流水线：确保新增界面不会悄悄绕过词条。

---

如何在不拖慢开发速度的前提下提取字符串？

AI 生成的仓库常常在几十个文件里重复同样的标签（“保存”“取消”“了解更多”）。你的提取流程应该：

1. 检测用户可见的字面量：覆盖组件、路由和共享 UI 基础组件，同时忽略技术性字符串（CSS 类名、埋点 ID，以及非面向用户的 URL）。
2. 合并重复项：归并为带引用的单个翻译键，让译者看到的是唯一的语义单元。
3. 生成源语言词条：通常是英文，作为每个新翻译键的标准值。
4. 改写调用处：统一改用团队约定的 i18n API，并且是机械式改写，保证 diff 便于审查。

React 风格代码的最简前后对比如下：

<button>Submit order</button>

提取并生成翻译键之后：

<button>{t("checkout.submit_order")}</button>

// locales/en.json
{
  "checkout.submit_order": "Submit order"
}

---

为什么在扩展语言之前，术语表和风格指南很重要？

机器翻译很快，但如果不事先定好约束，很容易让每个页面听起来像出自不同的产品。扩展到多种语言之前，先写下：

• 不得翻译的品牌词（产品名、功能名）。
• 高风险词汇的首选译法（“contact”“trial”“billing”“workspace”）。
• 语气：正式还是口语化，称呼用第二人称还是中性表达。

把这份术语表接入你的协作工具或 MT 配置，让自动生成的初稿与团队已有的决定保持一致。

---

翻译 QA 循环应如何以自动化检查为基础？

键进入语言文件之后，现代的工作循环是：机器翻译（MT）初稿 → linter 检查（长度、占位符、禁用术语）→ 对高影响界面做自动化回归检查 → 发布 → 度量。自动化节省时间，linter 则帮你避免把损坏的占位符发上线。

CLI 类工具可以让你快速了解仓库里还剩多少工作量，类似这样：

✔ Scanned 312 files
✔ Found 1,284 user-visible literals
✔ Proposed 920 translation keys (364 duplicates merged)
✔ Wrote locales/en.json

Next: sync translation-ready keys to your coordination tool or run an MT batch with glossary v1

---

哪些 Agent 提示词能让本地化重构保持可审查？

这些提示词默认你在一个有测试和代码审查的仓库里工作。它们的目标是产出你可以信任的 diff，而不是悄无声息的大范围重构。

重构之前，如何盘点界面字符串？

You are analyzing a TypeScript React codebase for localization readiness.

Task: List every pattern where user-visible English might appear (JSX text, string props that render to the DOM, template literals interpolated into UI, aria-label/title/placeholder, toasts, empty states). Exclude className values, internal IDs, and URLs that are not shown to users.

Output: a table with columns: file path, line range, example string, recommended next step (extract key / ignore / needs product decision).

如何安全地引入最小化的类型化 t() API？

Add a minimal i18n helper used across the app: a typed t(key, vars?) function backed by JSON locale files in /locales. Do not translate yet—only wire English as the source locale.

Constraints:
- Keys use dot namespaces: "section.component.purpose"
- Support ICU-style pluralization for keys that need counts
- Add a dev-only warning when t() is called with a missing key

Show the file tree you created and example usage in two existing components.

如何机械地把字面量提取为带命名空间的键？

Refactor the following files to replace user-visible string literals with t("…") keys.

Rules:
- Prefer stable semantic keys, not English sentences as keys
- Deduplicate identical UI strings to one key
- Keep string interpolation correct using ICU message patterns
- Do not change layout/styling except where required by the refactor

After edits, print a JSON object mapping each new key to its English source string for translators.

如何起草一份译者可以信赖的术语表 CSV？

From locales/en.json and the product marketing pages in this repo, propose a glossary CSV with columns: term_en, part_of_speech, definition_for_translators, do_not_translate (true/false), allowed_synonyms, notes_for_de.

Flag terms that are legally sensitive (pricing, trials, refunds) and terms that are ambiguous in software ("session", "organization", "member").

哪种 CI 防护措施能阻止新的硬编码英文字符串合入？

Add a CI script that fails if new user-visible English literals appear in JSX outside of tests/fixtures.

Implementation guidance:
- Use the repo's existing package manager and test runner
- Provide a small allowlist file for exceptions (brand strings, intentional English)
- Print actionable file/line references on failure

Include README notes for how engineers should add exceptions responsibly.

---

你还需要手动粘贴这些提示词吗？

越来越不需要了。这篇指南刚写成时，把提示词复制粘贴给 Agent 是跑通这个循环的实用办法。如今工具已经内置进 Agent：编码 Agent 可以通过 MCP 服务器直接调用本地化能力，提取、生成键和翻译同步都变成 Agent 发起的工具调用，而不再是你手动粘贴的提示词。配置方法见globalize.now MCP 发布说明，这一转变在架构上的意义见本地化正在成为 Agent skill，而不是 SDK。

上面的提示词仍然可以当作审查清单来用：无论是人手动粘贴，还是由 Agent skill 内置，它们描述的都是一次合格的 Agent 驱动 i18n 重构应当做到的事。评判任何自动化重构，都用同一条标准：diff 可审查、键稳定、插值兼容 ICU，并且有 CI 防护措施阻止回归。

---

本地化 AI 构建的产品时，需要记住哪条长期约束？

本地化不是一个冲刺就能做完的事，而是你与未来的自己之间的约定。只要在键、语言目录和自动化上投入一次，之后每个 AI 生成的新页面发往全球的成本都会更低。