老实说，

前言

前端国际化经常被理解成“把中文翻译成英文”。但在真实项目里它更像一项长期工程治理工作：文案分散在组件、接口提示、表单校验、图表说明和运营配置中；同一句话可能被多处重复定义；新增语言时还要考虑变量占位、复数、日期、金额、RTL 布局和兜底策略。

使用者痛点：硬编码中文遍布代码，导致维护成本高；每次新增语言都要手动查找、复制粘贴，容易漏翻或产生冲突。

AI 在这个场景里的价值，不是替我们一次性完成所有翻译。而是帮助团队更快梳理文案、生成资源草案、发现重复和缺失，并把国际化从“临时替换字符串”推进到“可维护的资源治理”。

这篇文章以一个常见的 Vue 或 React 前端项目为例，介绍如何用 AI 辅助完成国际化改造：从文案扫描、Key 命名、资源生成、组件接入到检查清单。

主要概念的观点是。国际化不只是翻译

前端国际化通常包含几个层次：

• 文案资源的观点是，按钮、标题、提示、错误信息、空状态等文本。
• 说到格式化规则，日期、时间、数字、金额、百分比、文件大小。
• 至于运行时切换，根据使用者设置或浏览器语言切换 locale。说起来，
• 至于布局适配。长文本换行、按钮宽度、部分语言从右到左显示。
• 说到资源治理，Key 命名、重复文案、缺失翻译、版本更新和评审流程。

使用者痛点：缺乏统一的资源结构导致同一文案出现多份。修改时必须同步多个位置，且难以追踪哪些语言缺失对应键值。

AI 适合参与的是“整理、生成、检查和迁移”，而不是跳过产品、设计和业务评审直接决定所有翻译。

说到实践步骤一，让 AI 帮你梳理文案清单

如果项目已经存在大量硬编码中文。可以先扫描源代码，把候选文案整理出来再交给 AI 分类。

type TextMatch = {
file这方面，string;line: number;text: string;}，怎么说呢，const chinesePattern = /*/g;export function collectChineseText: TextMatch {
return source.split
.flatMap => {
const matches = lineText.match?，;return matches
.map)
.filter
.map(text => ({
file。line: index + 1,text
}));})，}

拿到清单后用下面的提示词让 AI 按业务维度进行分类，而不是直接翻译：

你是一名前端国际化工程助手。请根据下面的中文文案清单进行分类。再看要求，1. 按页面标题、按钮、表单校验、接口错误、空状态、提示说明分类。2. 合并语义相同的重复文案。3. 给出建议的 i18n key，使用模块前缀和 camelCase。4. 对存在变量的文案标记 params，例如 “{total} 条记录”。5. 不要直接删除不确定文案，放到 needConfirm 中。

使用者痛点：手动筛选重复与变量非常耗时AI 能一次性输出结构化清单并标记潜在冲突，让后续评审更聚焦。怎么说呢，

实践步骤二这方面。设计资源结构

一个可维护的国际化结构，应该让业务模块和公共文案都有清晰边界。

export type Locale = 'zh-CN' | 'en-US';export type MessageSchema = {
common这方面， {
confirm: string;cancel: string;不过，search: string;reset: string;}，order: {
从title来看，string;createButton: string;statusPending: string;statusPaid: string;emptyText: string;}，};export const zhCN: MessageSchema = {
至于common，{
confirm: '确定',cancel: '取消',search: '搜索',reset: '重置'
}。order: {
title的观点是，'订单管理',createButton: '新建订单',statusPending: '待支付',statusPaid: '已支付',emptyText: '暂无订单数据'
}
};

If project contains many modules。split files by module:

src/i18n/
│─ index.ts
│─ locales/
│─ zh-CN/
│ │─ common.ts
│ │─ order.ts
│ │─ user.ts
│─ en-US/
│─ common.ts
│─ order.ts
│─ user.ts

使用者痛点：没有统一目录导致不同开发者各自创建 “common” 或 “utils” 文件，最终形成难以定位的资源碎片。通过明确的文件划分与命名规范，可大幅降低查找成本。

AI 辅助生成初始文件

将步骤一得到的分类结果喂给 AI，让它输出对应模块的 TypeScript 文件。怎么说呢，团队只需对生成的 Key 命名规则进行统一审查。即可快速落地基础资源库，

从实践步骤三来看，在组件中替换硬编码文案

国际化改造要尽量小步推进。 先从高复用组件和主要页面开始，不建议一次性修改全项目。

React 示例

type Messages = Record;老实说，type I18nContextValue = {
说到locale。string，messages: Messages;t: =>string，};function formatMessage {
if return template;return Object.entries.reduce =>
result.replace,String)
template);}
export function createTranslator{
return function t {
const template = messages?，key;return formatMessage;}，}

组件中只保留语义化 Key：

function OrderHeader {
const t = useI18n;return (

{t}
{t}
);老实说，}

使用者痛点：直接在 JSX/模板里写中文会导致后期切换语言几乎不可能。使用统一的 t 接口后只需补齐对应语言文件。就可以完成切换，无需再改动业务代码。

从实践步骤四来看，让 AI 生成翻译草案。但保留人工评审

AI 很适合生成翻译初稿，特别是后台程序或开发工具这类语义相对稳定的文案。关键是提供足够上下文与变量规则，让模型不会误删占位符。

请将下面的 zh-CN 国际化资源翻译为 en-US。要求的观点是，1. 保持 key 完全不变。2. 保留 {total} 、{name} 等变量占位符。说起来，3. 用简洁正式的公司后台语气。4. 不确定的业务名词不要意译，放到 comments 中说明。5. 输出 TypeScript 对象形式。

使用者痛点：仅凭机器翻译上线会出现专业术语错误或 UI 超出预期，需要人工复核才能确保质量。老实说，把 AI 当作“草稿生成器”。再交给本地化负责人做二次校对，是最安全且效率最高的方式。

三类必做检查

• 变量占位符是否完整保留。
• 业务术语是否符合团队词汇表。
• 长文本是否会影响按钮宽度或弹窗布局。

实践步骤五的观点是，检查缺失 Key 和多余 Key

The most frequent issue after internationalization is missing keys in some locales or leftover keys that are no longer used.

type FlatMessages = Record;function flattenMessages(
data : Record,prefix = ''
): FlatMessages {
return Object.entries.reduce=>{
const nextKey = prefix?`${prefix}.${key}` : key;if {
result = value;return result;}
if ) {
return { ...result,...flattenMessages };}
return result;},{})，}
export function compareLocaleKeys{
const baseKeys = new Set);const targetKeys = new Set);return {
missing : .filter),extra : .filter)
};怎么说呢，}

This script can be added to CI pipelines so that any PR that introduces a new page will automatically fail if a key is missing in any locale.

使用者痛点：Lack of automated checks leads to production pages showing raw keys like “order.title”. CI‑integrated verification guarantees every locale stays in sync.

说到实践步骤六。建立 AI 参与的国际化流程

A stable workflow that leverages AI at right moments can keep team from falling back into ad‑hoc translations.

1. 需求阶段：使用 AI 根据需求稿自动抽取所有待展示文字并输出初步 Key 列表与分类报告。
2. 约定所有 UI 文本必须通过 调用；按理说，若有新需求，仅向 i18n 仓库提交 JSON/TS 文件，不允许硬编码中文。
3. Linter + 上一步中的脚本自动检测硬编码中文残留还有缺失/冗余 Key。话说回来，
4. Ai 提供多语言草稿 → 本地化负责人审校 → 合并进仓库主分支。
5. L10n QA 包括长文本布局测试、多币种格式检查还有 RTL 页面预览。

The prompt templates and validation scripts should be version‑controlled alongside codebase so that every new feature inherits same standards.

注意事项 ⚠️

1. Ai 翻译只能作为初稿；品牌语气、法律条款还有关键业务术语必须人工确认后才能上线。老实说，
2. Avoid dumping all strings into a single ;overly large公共资源会削弱模块边界，使得维护成本上升。
3. The naming convention of Keys 必须保持稳定。一旦决定就不应随意因中文表达变化而改动，否则历史翻译会失效。不过，
4. Date / currency / number formatting 应优先使用 Intl API 或成熟 i18n 库。而不是手工拼接字符串，以保证不同地区表现一致。
5. SPECIAL attention to placeholder consistency – ensure every translation retains placeholders like {name},{count}.
6. If possible。preview long‑text languages on real UI components to catch overflow or layout breakage early.

🎯

。

---