适用于 JavaScript 的轻量、简单、灵活、自动翻译的国际化工具

[eyelly]

适用于 JavaScript 的轻量、简单、灵活、自动翻译的国际化工具

在做国际化时，是否遇到了如下问题？

1. 为了定义一个 key ，而绞尽脑汁，还要担心会不会重复
2. 人工手动翻译文案，翻译费时、费力
3. 人工手动编写语言包文件费时、费力
4. 文案变更（移除、调整）维护困难
5. 对新增语言的支持工作量会很大（跟文案的多少成正比）
6. 可能仅仅需要简单的翻译功能，却引入了庞大的国际化库

​i18n-pro 就是为了帮助解决上述问题的

1. 翻译文案即 key ，无需手动定义
2. 自动翻译，省时省力（支持多个翻译平台，对翻译质量担忧的，可以选择自己信赖的平台，听说 ChartGPT 翻译质量不错？内部已支持）
3. 自动翻译后会生成对应语言的语言包
4. 自动翻译时，只会翻译新增文案，智能移除未使用文案
5. 新增语言只需简单调整命令行配置（添加新的目标语言），然后执行翻译命令即可
6. 该库提供了一个轻量的运行时（极简的 API ，核心逻辑只关注翻译本身）可以满足绝大部分场景，对于数字、货币、日期（时间）、复数的支持也提供了解决方案，具体实现由使用者本身决定

​后续规划​

i18n-pro 目前是一个纯粹的 JS 库，因此使用上不限制平台、框架；可以用来支持 前端开发、服务端开发、桌面端开发、脚本开发 等一系列基于 JavaScript 构建项目且需要国际化-多语言的场景​

后续会推出一些 UI 库的版本，例如 React、Vue、SolidJS、Svelte 等；结合他们的各自更新机制，实现更好切换语言的体验

最后

​该库所有的文档都在仓库中，想了解更多请访问 https://github.com/i18n-pro/core ，如果觉得对你有帮助，希望可以点个⭐️支持下哟

[lisxour]

稍微看了一下，文案即 key 的方案很多问题的，说个以后必然很常规遇到的问题，假设：

1. t('你好，${0}，欢迎登陆后台', getUserName())
2. 自动生成各国翻译之后，我后续还人工优化了翻译（全机翻是不现实的，总会需要人工优化的）
3. 此时我觉得文案不好改了，t('你好，${0}，欢迎使用后台', getUserName())，那我之前的翻译怎么办？你怎么对应回去？

[lisxour]

我以前用 sphinx 写文档做 i18n 也是使用了一样的无 key 方案，即文案即 key ，后续对翻译的维护简直噩梦。

[eyelly]

@lisxour 对于第二点表示认同，机器翻译肯定不能做到 100%满意的，但是对于绝大部分（不是所有哟）开发人员的话，外语水平可能都不太好，但这样至少可以应对，如果翻译不佳，后期在语言包中调整也不是什么大问题

基于第一点的文案生成的语言包是这样的
{
"你好，${0}，欢迎登陆后台": "假如这里是翻译后的内容"
}
如果文案调整了第 3 点的，会重新生成下面的语音包：
{
"你好，${0}，欢迎使用后台": "这里会是新翻译的内容"
}

[eyelly]

@lisxour #2 比较好奇是什么样的维护问题？可以展开说说吗

[lisxour]

@eyelly #4 就是涉及人为改动的情况下，怎么对应回去原来的东西，假设以下情况：

1. 刚开发的时候，我代码中某条文案是：t('欢迎')，此时第一次跑出来的机翻结果，即 langs.json ，大致内容就是：{"en": {"欢迎": "Welcome"}}，对吧

2. 在后续开发中，自己或者其他母语者觉得翻译不够味，那此时直接把 langs.json 内容改了，假设改成{"en": {"欢迎": "Welcomeeeee"}}（还是库有提供别的更优雅的翻译优化方法，我没把整个项目看完，不太清楚这个细节），现在假设是直接改 langs.json 文件

3. 现在就出现了两个问题：
3.1. 我此时再次运行机翻命令，我之前人工优化的"Welcomeeeee"会不会被机翻覆盖掉？
3.2. 我代码里改成了，t('你好，欢迎！')，再次运行机翻命令，按照你的描述，此时旧的那条{"欢迎": "Welcomeeeee"}是不是被智能优化掉了，是不是也就意味着以前人工优化的那些翻译丢失了。即使没有被优化掉，那对应的内容应该大致是这样的，{"en": {"欢迎": "Welcomeeeee", "你好，欢迎！": "Hello, Welcome!"}}，即使是保留了，因为文案即 key 的问题，一旦代码改动了，以前的那条优化过的文案是不是就没法取出来了，除非代码里一旦写了，就不能去改。

[awesomes]

想法很好，比传统方式更直观

[eyelly]

@lisxour #5
感谢大佬耐心且详细的回复

针对上述的的问题：
3.1 如果语言包中已经存在该文案的翻译，就不会再次翻译该文案了，只要文案本身不变，就不用担心翻译好的内容（不管是机翻的，还是人工手动的）丢失

3.2 如果文案发生了变化
例如：`欢迎` -> `你好，欢迎！`，那么以前针对 `欢迎` 翻译内容是会被移除掉，又会基于 `你好，欢迎！` 重新翻译。

因为 文案即 key ，代码中改了文案，语言包中的文案也会被同步改掉，当然人工手动翻译的是会丢失。虽然可以做到在语言包中保留不再使用的文案，但是这样没有意义。

针对上述场景可以有这样的解决方案：

例如：针对 `欢迎` 文案，对于机翻的 `Welcome` 不满意，然后人工维护成了 `Welcomeeeee`，但是后续文案显示上要变成 `你好，欢迎!`

如果要保留人工维护的翻译内容，新的文案写法这样调整可以满足需求：
以前：t('欢迎')
现在：t('你好，{0}!', t('欢迎'))

相当于某些文案已经有固定的翻译内容了，可以理解为抽成一个变量，在文案中基于`变量插值`的特性与其他文案进行组合来生成新的文案

[eyelly]

@awesomes 谢谢，希望可以真正帮助到广大开发者朋友们

我们的愿景是：为了让接入国际化成为轻松且愉快的事😄💪🏻

[K120]

到最后会发现这个东西并没有什么用，多语言是要定制化的，并不是随便翻译就能搞定。

大陆 “吃饭”， 在香港 "食饭"， 你能翻译台湾 澳门 香港这些吗。

"Hello"， 在英文，我想叫 "Hi" 。。。 只能说是玩具。

[eyelly]

@K120 如果觉得翻译不到位话，还是可以人工在调整语言包的啊（源语言与目标语言是一对一的，很方便调整），就像你程序代码写好了，就不管改 bug 了吗？