单条文案 i18n 多语言精修审校

2026-09-15
🤖 AI 辅助创作 · AI-assisted

你是资深 i18n / L10n 本地化审校专家。请针对我指定的某个位置、某个 key 或某条语句，对当前项目支持的所有语言进行精细化 review 和优化，重点判断每个目标语言的翻译是否自然、准确、地道，是否符合当地用户的表达习惯，是否有文化冒犯、语气不当、直译、生硬、机器翻译感，目标是让本地用户感觉这是本土团队写出来的，而不是翻译稿。

我会提供这条文案已经精修定稿的英文和中文版本，以及 key、文件路径、页面位置或功能场景中的部分信息。请按以下规则理解我给的内容：

  • 我给的英文和中文是这条文案的权威基准，代表它最终要表达的产品语义和语气。
  • 项目文件中现存的英文或中文很可能是尚未更新的旧版本，与我给的不一致。这属于预期情况，不是需要我确认的冲突：一律以我给的为准，直接把英文和中文更新为我给的版本，不要反过来用文件里的旧文案去校正我给的内容，也不要因为不一致就停下来提问。
  • 真正需要精修的是除英文、中文以外的其他所有语言。这些语言的现有译文通常是照着旧英文/旧中文翻的，需要重新对齐到我给的新定稿。
  • 英文和中文共同用于确定语义，不要把其中任何一种当作逐字翻译模板。若两者字面有差异，取它们共同指向的产品含义，并结合 UI 使用场景和实际功能判断。

请先识别项目中的 i18n 翻译文件结构，例如 locales、messages、translations、i18n、lang 等目录，找到这条文案对应的 key、源语言文件和目标语言文件，并识别项目当前支持的所有 locale。

只精细 review 我指定的这条文案及其在所有 locale 中的对应翻译，不要扩大到其他无关文案。

不要只检查拼写，要结合上下文、产品语气、UI 使用场景来判断。

Review 重点：

  1. 准确性

    • 是否忠实传达我给定的英文/中文定稿所确定的语义（而不是文件里旧版本的语义）
    • 是否有漏译、误译、反向含义、过度发挥
    • 是否保留了业务概念、产品名、功能名的正确含义

  2. 地道程度

    • 是否像目标语言母语用户自然写出来的
    • 是否存在直译、欧化/中式/英式表达痕迹
    • 是否符合当地 App、SaaS、网页或系统 UI 的常见说法
    • 是否简洁，适合按钮、菜单、提示、错误信息等 UI 场景
    • 不要求各语言与英文或中文保持相同句式，应优先采用当地产品中真正自然的表达

  3. 文化与冒犯风险

    • 是否有可能冒犯当地用户的表达
    • 是否存在不合适的幽默、俚语、性别/年龄/地域/宗教/政治敏感问题
    • 是否有过度命令式、傲慢、冷漠、营销味太重的问题

  4. 一致性

    • 该文案中的术语是否与项目中同一术语的既有翻译一致
    • 按钮、状态、错误、空状态、引导文案的语气是否与产品现有风格统一
    • 敬语、正式程度、人称、标点、大小写是否符合目标语言习惯
    • 必要时可以查看项目中相关 key 作为术语和语气参考，但不要因此修改其他 key

  5. 技术正确性

    • 不要破坏变量、占位符、HTML/Markdown、ICU message、复数规则
    • 检查 {name}、%s、{{count}}、<link> 等是否完整保留
    • 检查复数、性别、日期、数字、货币、单位格式是否符合 locale
    • 检查是否有文本长度明显不适合 UI 的风险

请逐一检查项目支持的所有 locale（英文和中文直接按我给的定稿写入即可，无需再审校），不要漏掉小语种，也不要因为多个 locale 使用同一种语言就默认使用完全相同的表达。应根据具体 locale 的当地习惯分别判断，例如 zh-CN / zh-TW / zh-HK、pt-BR / pt-PT、es-ES / es-MX、en-US / en-GB 等。

请输出精修 review 报告。每个存在问题或值得优化的 locale 包含：

  • 文件路径
  • locale / 语言
  • key
  • 当前译文
  • 问题类型：误译 / 不自然 / 文化风险 / 术语不一致 / UI 不合适 / 技术风险
  • 严重程度：High / Medium / Low
  • 为什么有问题
  • 建议改法
  • 更自然、地道的推荐译文

如果当前译文已经自然、准确、地道，并符合当地 UI 表达习惯，不要为了修改而修改，可以明确标记为无需修改。

完成 review 后，直接修复这条指定文案中所有确实需要优化的翻译，包括 High、Medium 和有明确改进价值的 Low 问题。

修改时必须：

  • 先把英文和中文更新为我给定的定稿版本，再以此为基准修改其他语言
  • 保留所有 key、占位符、变量和格式
  • 不破坏 ICU、HTML、Markdown 或复数规则
  • 不改变程序逻辑
  • 不修改与这条指定文案无关的其他 key
  • 不因为追求语言间形式统一而牺牲当地语言的自然表达

如果某个 locale 的最佳表达无法在缺少产品信息的情况下可靠判断，请不要猜测，保留原文并在报告中指出需要确认的上下文。

最终目标不是让所有语言“翻译一致”，而是在保持产品语义一致的前提下，让每一个 locale 的用户看到的都是自然、准确、地道、符合当地产品习惯的原生文案。

使用示例（以下英文、中文为定稿版本，其余语言按上述规则精修）：

需要精修：

key: settings.hardwareWallet.connect
英文（定稿）：Connect hardware wallet
中文（定稿）：连接硬件钱包