用 Chrome 内置翻译 API 辅助网页国际化
这个演示关注的不是单句翻译，而是网页国际化（i18n）场景：当站点没有某种语言的人工译文时，尝试用浏览器内置翻译能力生成临时版本。它可以降低小型工具验证多语言需求的成本，但不应替代正式的词条管理、人工审校和无障碍测试。导航、支付、隐私与错误提示尤其需要稳定、可追踪的人工译文。
推荐的国际化流程
- 先为原始文案分配稳定的键，例如
settings.language，不要直接把整段中文当作键。 - 根据用户主动选择或浏览器语言决定目标语言，同时保留切回原文的入口。
- 调用前检查语言组合和模型状态；不支持时显示原文，不要留下空白按钮或半翻译页面。
- 对产品名、快捷键、代码、URL 和变量占位符做保护，翻译后再恢复并校验。
- 缓存同一版本的译文，避免每次渲染都重新生成；原文改变时使旧缓存失效。
- 把高频页面的机器译文交给人工审校，最终沉淀到正常语言包中。
Chrome大模型翻译：批量本地化
上线前要检查什么
译文长度变化会造成按钮溢出、卡片高度跳动和移动端遮挡，因此要测试长语言文本、从右到左语言和键盘导航。还要确认数字、日期、货币与复数规则是否由本地化格式化工具处理；翻译 API 只负责语言转换，不能替代这些规则。
生成式或自动翻译也可能改变语气、漏掉否定词或误译行业术语。应建立术语表，并允许用户报告问题。涉及同意、价格、账户删除和法律权利的文案，不要在没有复核时动态生成。
常见问题
这会改善多语言 SEO 吗？
仅在客户端临时生成的译文通常不是稳定、可独立抓取的语言页面。要做搜索收录，仍应提供独立 URL、服务端可见正文、正确的语言标记与一致的 canonical/hreflang 关系。
可以自动翻译用户提交的内容吗？
技术上需要先评估长度、内容安全和隐私。应让用户明确触发翻译，并说明数据处理边界，不能把私密内容默认批量送入任意页面脚本。