AI 辅助前端国际化实践：从文案梳理到多语言资源治理

前言

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

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

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

核心概念：国际化不只是翻译

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

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

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

实践步骤一：让 AI 帮你梳理文案清单

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

ts 复制代码

type TextMatch = {
  file: string;
  line: number;
  text: string;
};

const chinesePattern = /[一-龥][一-龥，。！？、：；（）《》""ws-]*/g;

export function collectChineseText(source: string, file: string): TextMatch[] {
  return source.split('
').flatMap((lineText, index) => {
    const matches = lineText.match(chinesePattern) ?? [];

    return matches
      .map((text) => text.trim())
      .filter((text) => text.length >= 2)
      .map((text) => ({
        file,
        line: index + 1,
        text
      }));
  });
}

拿到清单后，可以用这样的提示词让 AI 先分类，而不是马上翻译：

md 复制代码

你是一名前端国际化工程助手。请根据下面的中文文案清单进行分类。

要求：
1. 按页面标题、按钮、表单校验、接口错误、空状态、提示说明分类。
2. 合并语义相同的重复文案。
3. 给出建议的 i18n key，使用模块前缀和 camelCase。
4. 对存在变量的文案标记 params。
5. 不要直接删除不确定文案，放到 needConfirm 中。

这样可以先得到可评审的资源草案，避免一边改代码一边随意起名。

实践步骤二：设计资源结构

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

ts 复制代码

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: '暂无订单数据'
  }
};

如果项目模块很多，可以按模块拆文件：

text 复制代码

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

AI 可以根据模块清单生成初始文件，但团队需要统一 Key 命名规则，否则后续会出现大量重复资源。

实践步骤三：在组件中替换硬编码文案

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

下面是一个简化的 React 示例：

tsx 复制代码

type Messages = Record<string, string>;

type I18nContextValue = {
  locale: string;
  messages: Messages;
  t: (key: string, params?: Record<string, string | number>) => string;
};

function formatMessage(template: string, params?: Record<string, string | number>) {
  if (!params) return template;

  return Object.entries(params).reduce((result, [key, value]) => {
    return result.replace(new RegExp('{' + key + '}', 'g'), String(value));
  }, template);
}

export function createTranslator(messages: Messages) {
  return function t(key: string, params?: Record<string, string | number>) {
    const template = messages[key] ?? key;
    return formatMessage(template, params);
  };
}

组件中只保留语义化 Key：

tsx 复制代码

function OrderHeader({ total }: { total: number }) {
  const t = useI18n();

  return (
    <header>
      <h1>{t('order.title')}</h1>
      <p>{t('order.totalText', { total })}</p>
      <button>{t('order.createButton')}</button>
    </header>
  );
}

这样新增语言时，不需要修改组件结构，只需要补齐资源。

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

AI 很适合生成翻译初稿，尤其是后台系统、开发工具、表单提示这类语义相对稳定的文案。推荐把上下文、语气和变量规则写清楚。

md 复制代码

请将下面的 zh-CN 国际化资源翻译为 en-US。

要求：
1. 保持 key 完全不变。
2. 保留 {total}、{name} 这类变量占位符。
3. 语气简洁，适合企业后台系统。
4. 不确定的业务名词不要意译，放到 comments 中说明。
5. 输出 TypeScript 对象。

翻译完成后，至少要做三类检查：

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

实践步骤五：检查缺失 Key 和多余 Key

国际化资源最容易出现的问题是某个语言缺 Key，或者旧 Key 已经不用但还留在资源里。可以写一个简单脚本进行检查。

ts 复制代码

type FlatMessages = Record<string, string>;

function flattenMessages(data: Record<string, unknown>, prefix = ''): FlatMessages {
  return Object.entries(data).reduce<FlatMessages>((result, [key, value]) => {
    const nextKey = prefix ? prefix + '.' + key : key;

    if (typeof value === 'string') {
      result[nextKey] = value;
      return result;
    }

    if (value && typeof value === 'object' && !Array.isArray(value)) {
      return {
        ...result,
        ...flattenMessages(value as Record<string, unknown>, nextKey)
      };
    }

    return result;
  }, {});
}

export function compareLocaleKeys(base: FlatMessages, target: FlatMessages) {
  const baseKeys = new Set(Object.keys(base));
  const targetKeys = new Set(Object.keys(target));

  return {
    missing: [...baseKeys].filter((key) => !targetKeys.has(key)),
    extra: [...targetKeys].filter((key) => !baseKeys.has(key))
  };
}

这个检查可以放到 CI 中，避免新页面上线后某个语言显示 Key 本身。

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

比较稳妥的流程可以是：

开发前：用 AI 根据需求文档整理文案清单和资源 Key 草案。
开发中：组件只使用 t(key)，避免新增硬编码文案。
提交前：脚本检查中文硬编码、缺失 Key 和多余 Key。
翻译时：AI 生成多语言草案，业务或本地化负责人评审。
发布前：重点检查长文本、日期金额格式、空状态和错误提示。

可以把提示词和检查脚本沉淀到工程模板中，让每次新增页面都遵循同一套流程。

注意事项

AI 翻译只能作为初稿，品牌语气、法律条款和关键业务术语必须人工确认。
不要把所有文案都放到 common，公共资源过大反而会失去边界。
Key 命名要稳定，不要频繁根据中文含义改名，否则会影响历史翻译。
日期、金额、数字格式不要用字符串拼接，优先使用 Intl API 或成熟 i18n 库。
对变量占位符要做检查，避免翻译时漏掉 {name}、{count} 等参数。
多语言布局要真实预览，英文、德文等长文本可能撑开按钮或表格。

总结

AI 辅助前端国际化的核心价值，是把分散文案整理成可治理的资源体系，并在翻译、检查、迁移过程中减少重复劳动。它不能替代业务评审和本地化质量控制，但可以显著降低文案梳理、资源生成和缺失检查的成本。

当团队把国际化从"翻译几个字符串"升级为"资源结构、Key 规则、脚本校验和评审流程"时，多语言维护会变得更稳定。AI 在其中最适合扮演工程助手：帮助我们更快发现问题、更快生成草案，但最终质量仍由团队规范和人工审查来保证。