利用 ChatGPT 进行高效的国际化

在当今的全球市场中，产品的国际化（即 i18n）是必不可少的。通过支持多种语言，产品可以吸引和服务全球的用户群，增强用户体验，提高用户忠诚度，增加市场份额。然而，国际化支持往往伴随高昂的成本和复杂的维护:

• 建立语言支持需要专业的团队和选择合适的合作伙伴，这需要时间和精力。
• 传统的翻译流程速度慢且需要手动干预，使其难以跟上产品的迭代。

在本文中，我们将分享 Logto 团队利用 ChatGPT 及其 API 高效支持我们产品国际化同时尽量降低成本的经验。

我们如何处理国际化#

在集成了 ChatGPT API 之前，我们遵循一个传统的翻译流程来支持我们产品的国际化。这个流程是这样的:

1. 对于每种语言，我们创建一个包含多个 TypeScript 文件的翻译文件夹。每个文件包含一个 TypeScript 对象，对象中的键值对表示短语键和它们的翻译。
2. 要添加一个新的短语，我们手动为每种语言的翻译文件添加一个新的键值对。
3. 在每种语言的根目录中，我们创建了一个 index.ts 文件，该文件导出了该语言的所有翻译文件。

下面是 zh-HK 语言的 index.ts 文件的一个例子:

为在 UI 中显示一个短语，我们使用了一个函数，该函数基于当前的环境获取翻译。我们使用点注释方式访问嵌套的对象或键。

例如，如果用户正在使用英文浏览器:

面临的挑战#

我们在这个方法中遇到了两个主要的挑战:

1. 随着语言和短语的数量增加，维护翻译文件变得困难。手动将新的短语添加到每种语言都耗时并且容易出错。
2. 翻译过程不可靠。没有专门的翻译团队，我们依赖社区用户进行大部分翻译。他们做得非常好，但难免会出现翻译不完整和不一致的情况。

引入 ChatGPT#

随着 ChatGPT 的流行，我们发现了一个有趣的用例。无意中，我们将一个 TypeScript 短语对象复制到 ChatGPT 中，发现它能够在保持代码结构的同时翻译代码段。这个发现让我们很兴奋。

例如:

然后的结果:

这是非常了不起的。在现实世界中，我们也有历史文件中包含一些用 // UNTRANSLATED 标记的未翻译的短语:

ChatGPT 甚至能够“部分地”翻译代码段，消除了最后的障碍。然而，它还远远不够完美。让我们来看看我们遇到的问题。

提示工程#

随机响应的问题#

关于 ChatGPT 一件众所周知的事实是它的不可预测性。有时，结果是准确的，而有时，它们可能是奇怪的或者不是我们意图的结果。虽然在聊天机器人的上下文中这是可以接受的，但在生成翻译代码片段时就变得有问题了。

让我们重新看一下 zh-HK 的例子:

预期的 Nice to meet you. 在 zh-HK 的翻译是 很高興見到你。。然而，有时，代码段被翻译成 zh-CN:

很高兴见到你。 不同于 很高興見到你。。

有时，提示"请翻译..."也被翻译了:

偶尔，结果包含不必要的内容:

第一行"这是翻译："对我们的需求是不必要的。

根据上述结果，我们可以发现 ChatGPT 和我们在对话中的几个差距:

• 有时，它只推断出语言（zh），而没有考虑到地区差异（zh-HK）。
• 它未能准确地识别出需要翻译的内容。
• 响应格式与我们的期望不匹配。

填写清晰且具体的提示#

为了解决上述问题，我们完善了我们的提示:

这个新提示证明是有效的。我们指导 ChatGPT:

• 根据提供的语言码推断出地区语言。
• 翻译用三个反引号分隔的代码段。
• 确保输出保持原格式，没有任何额外的内容。

让模型有时间思考#

如前所述，对于现有的短语，我们需要翻译那些带有 // UNTRANSLATED 标记的短语。这给提示引入了另一层复杂性。例如:

我们得到的一个结果:

它也翻译了（或者说转换了）短语 success ，并添加了两个 // TRANSLATED 评论，这都是我们预料之外的。

尽管前面的提示清晰且具体，但它相当长，即使对于人类来说也很难遵循。为了改善这种情况，我们给模型更多的时间来思考。我们提供了一个逐步的提示:

结果有了显著的改进。然而，有时 ChatGPT 会显示"思考过程"，因为我们明确提供了步骤。

对话中的角色#

尽管没有直接的用户界面，我们可以通过为每条消息分配不同的"角色"，向 ChatGPT 发送一个交互式且动态的对话。角色可以是以下之一:

• "system"：负责引导对话的流程和行为，确保连续性和目标导向。
• "assistant"：代表 ChatGPT 模型本身，提供答案和响应。
• "user"：代表用户提出问题和与模型交互。

通过使用角色，我们可以和 ChatGPT 创建一个更具互动性的对话。每条消息在引导对话中都扮演特定的角色。

这里，我们可以使用 "system" 角色来引导 ChatGPT 完成我们的任务:

使用 "user" 角色向 ChatGPT 要求翻译代码段:

使用 "assistant" 角色表示 "标准答案":

最后，结合我们想要翻译的代码段，和上面的三条消息，将它们作为单个请求发送到 聊天补全 API 。下面是一个例子:

我们将 languageCode 替换为目标码，将 code 替换为要翻译的代码段，我们看到了我们期望的准确结果。太好了！

集成到我们的 CLI#

虽然结果正确且稳定，但使用 ChatGPT API 的过程仍然不是很方便。我们必须手动复制代码段，将其粘贴到请求中，并替换 languageCode 和 code 变量。考虑到需要翻译10多种语言和100多个代码段，这并不是一种理想的体验。

为了解决这个问题，我们决定将 ChatGPT API 集成到我们的命令行接口（CLI）中。我们为我们的 CLI 添加了两个命令:

• logto translate sync：这个命令集合所有语言的代码段，其中包含 // UNTRANSLATED 评论，翻译它们，并用翻译后的版本替换原始的代码段。
• logto translate create [languageCode]：这个命令创建了一个新的语言，使用指定的 [languageCode]，并将所有代码段从默认语言(英语)翻译成新的语言。

虽然翻译可能不完美，但它仍然是一个巨大的进步。我们现在可以专注于验证和改进翻译结果，而不是用于实际的翻译过程。

结论#

将 ChatGPT API 集成到我们的产品国际化工作流程中可以是一种强大的工具，但是需要仔细的规划和清晰的指示才能获得最好的结果。

如果你正在开发 AI 应用，用户身份验证是必不可少的。Logto 提供了一种简单而安全的方式来验证你的用户，并在你所有的应用中提供统一的用户身份系统，还为 ChatGPT 插件提供开箱即用的支持。欲了解更多信息，请查看我们的博客文章:

使用 Logto 实现 ChatGPT 插件的用户身份验证