Topics

使用 Google 翻译 API 实现 Astro SSG 网站多语言化

  • column

某天,社长突然下令:"咱们网站要多语言化。听说有个 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) / 标记语言工程师 / 前端工程师 / 网络总监

查看本员工的文章

安心的团队体制和迅速的反应能力是我们的优势

Liberogic 拥有经验丰富的员工团队,积极推进项目,因此获得了客户的高度评价。
我们会妥善分配项目经理和总监,确保整个项目顺利进行。 通过避免不必要的全职投入导致的成本增加,并采用适当配置人力资源的方式,从把握业务内容到估价的制作和提交速度都赢得了良好的口碑。

* 本公司不积极开展SES驻场工作等业务,敬请谅解。

Slack、Teams、Redmine、Backlog、Asana、Jira、Notion、Google Workspace、Zoom、Webex 等,您可以使用几乎所有主要的项目管理工具和沟通协作工具。

在使用 SES 或离岸外包的大规模项目中,您是否在技术挑战或解决方案方面需要帮助?

案例分析