某天,社长突然下令:"咱们网站要多语言化。听说有个 Google Cloud Translation API,能在构建时自动翻译呢!"
我们的网站是用 Astro 构建的静态网站 (SSG)。我们决定在研究 Google Cloud Translation API 的同时进行实现。
前期准备:启用 API 密钥和创建服务账户
启用 Cloud Translation API
从 Google Cloud Console 的"API 和服务"中启用"Cloud Translation API"。
创建服务账户和密钥
要使用 API,需要创建服务账户并下载 JSON 密钥。
此 JSON 密钥包含私密密钥,绝对不要公开,务必格外谨慎。
为服务账户授予访问权限
前往 IAM,添加服务账号的电子邮件地址作为主体,并将角色设置为"Cloud Translation API 用户"。
如何生成多语言页面
最初尝试的方法是"复制 Astro 文件,即时调用翻译 API,自动生成多语言 Astro 文件"。
页面可以生成,但代码围栏部分损坏、导入的组件无法处理、属性内书写标签时出现问题等各种情况,导致多处无法正常运行,因此决定改变方案。
最终,我们采用了一个简单的 postbuild 处理方案——"对构建后生成的静态 HTML 进行翻译处理"。
语言设置与 Astro 的 i18n 配置文件相关联
为了管理网站的多语言结构,我们将原有的Astro i18n配置文件(LOCALES_SETTING)作为翻译脚本的"配置文件"来使用。
如果想要添加语言,只需在这里追加即可。
export const LOCALES_SETTING: LocaleSetting = {
ja: {
label: '日本語',
lang: 'ja',
oglocale: 'ja_JP',
path: 'ja',
},
en: {
label: 'English',
lang: 'en',
oglocale: 'en_US',
path: 'en',
},
de: {
label: 'Deutsch',
lang: 'de',
oglocale: 'de_DE',
path: 'de',
},
es: {
label: 'Español',
lang: 'es',
oglocale: 'es_ES',
path: 'es',
},
cn: {
label: '简体中文',
lang: 'zh-CN',
oglocale: 'zh_CN',
path: 'zh-cn',
},
tw: {
label: '繁體中文',
lang: 'zh-TW',
oglocale: 'zh_TW',
path: 'zh-tw',
},
};语言切换的实现
语言选择下拉菜单也从之前的 i18n 配置文件生成。label 是选择项名称,所以我不想翻译它。因此,我添加了用 label 的值覆盖的处理。(translate="no" 在 Cloud Translation API 中似乎不起作用)
顺便说一下,有人建议在下拉菜单中加入国旗,我本来想加的,但似乎在语言切换中加入国旗是一个反模式。比如,德语使用者可能是奥地利用户,看到德国国旗可能会感到困惑,这说明国家和语言并不总是一致的。现在想想确实如此。在某些情况下,这可能会成为一个敏感问题。
缓存化以最小化 API 使用
到这里为止,多语言生成的机制基本完成。但问题是成本。
在各种试错中多次构建的过程中,API 使用费很快就超过了 10,000日元。
因此,在构建时将 API 处理的日语和翻译的组合作为缓存保存到名为 translate-cache.json 的文件中,下次构建时从该 JSON 应用。仅对不存在的内容调用 API,并将结果添加到 JSON 的规格中。
大致是这样保存的。
{
"en:UIデザイン": "UI Design",
"en:私たちについて": "About Us",
"en:サービス": "Service",
...
}通过这种方式大幅降低成本!取决于更新频率,运营成本每月只需几百日元。
运营注意事项
当在 CMS 中添加文章并通过部署钩子进行构建时,服务器只能引用 Git 上的旧缓存文件。因此,在添加内容时,我们制定了严格的运营规则:在本地进行构建,然后将更新的缓存文件推送到 Git。
控制异常翻译
确实是机器翻译。到处都出现了奇怪的翻译。
我们的公司名称"Liberogic"被翻译成了"Liberlogic"或"Libelogic",法人格标记(Inc.、Ltd. 等)也没有统一,专有名词的表记摇晃得特别明显。
Cloud Translation API 虽然有术语表功能,但这只是用来辅助机器翻译的,无法进行完整的细致控制。此外,不仅需要上传 CSV 文件,每次还需要执行命令重新创建资源,这对不熟悉网络技术的运维人员来说比较困难。
通过电子表格集成实现可靠的控制
为此,我们将语言和正误信息汇总到电子表格中,在构建时以 CSV 格式获取此电子表格,并通过文本替换处理将内容覆盖修正为正确的表述方式。
这样一来,运维人员只需更新电子表格,无需编写代码就能在一定程度上控制翻译内容。
总结
我们使用 Google Cloud Translation API 进行自动翻译,经过多次试验,最终打造出了一个比预期更加实用的系统。我认为这是一个成本高效、便捷的简易多语言化解决方案。
(总裁说想要支持RTL阿拉伯语,这可是个大工程啊)
从DTP跨越到Web世界,不知不觉中已掌握标签、前端开发、创意指导、无障碍设计等各项技能的"技术高手"。从Liberogic创业初期就活跃至今,如今是公司内部的"活百科"。最近沉迷于"能否在无障碍适配上更多依赖AI?"这样的思考,正在探索借助AI提示词提高效率的方法。技术实力和思维方式都还在不断进化中
Futa
IAAP 认证网络无障碍专家 (WAS) / 标记语言工程师 / 前端工程师 / 网络总监