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

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

我通常会提供对应的英文和中文文案，以及 key、文件路径、页面位置或功能场景中的部分信息。英文和中文用于共同帮助理解这条文案真正想表达的产品语义，不要机械地将其中某一种语言作为逐字翻译模板。如果英文和中文表达存在差异，应结合产品上下文、UI 使用场景和实际功能判断准确含义。

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

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

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

Review 重点：

准确性

是否忠实传达源文含义

是否有漏译、误译、反向含义、过度发挥

是否保留了业务概念、产品名、功能名的正确含义

地道程度

是否像目标语言母语用户自然写出来的

是否存在直译、欧化/中式/英式表达痕迹

是否符合当地 App、SaaS、网页或系统 UI 的常见说法

是否简洁，适合按钮、菜单、提示、错误信息等 UI 场景

不要求各语言与英文或中文保持相同句式，应优先采用当地产品中真正自然的表达

文化与冒犯风险

是否有可能冒犯当地用户的表达

是否存在不合适的幽默、俚语、性别/年龄/地域/宗教/政治敏感问题

是否有过度命令式、傲慢、冷漠、营销味太重的问题

一致性

该文案中的术语是否与项目中同一术语的既有翻译一致

按钮、状态、错误、空状态、引导文案的语气是否与产品现有风格统一

敬语、正式程度、人称、标点、大小写是否符合目标语言习惯

必要时可以查看项目中相关 key 作为术语和语气参考，但不要因此修改其他 key

技术正确性

不要破坏变量、占位符、HTML/Markdown、ICU message、复数规则

检查 {name}、%s、{{count}}、 等是否完整保留

检查复数、性别、日期、数字、货币、单位格式是否符合 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
中文：连接硬件钱包