国际化(多语言)支持 RFC
Opened this issue · 14 comments
- 管理后台支持多语言切换。
- 文章内容是否也支持多语言？同一篇文章可以存在多个不同语言的版本
我提个我的思路，可行性未验证：
预期目标：同一文章链接，中文朋友看的是中文，英文朋友看的是英文版本的，日语朋友看的是日语版本的。用户可以在后台编辑器通过按钮切换编辑的语言版本，选择对应的版本编辑。
存储的几种方案：
- 直接给文章存内容的表加上对应的字段，这是按文章维度
- 分多张表，按语言维度，中文文章内容表，日文文章内容表，英文文章内容表。
两种方式各有优劣
可以考虑下国际化也通过插件的方式来实现 @ruibaby
- Halo Admin 中将所有文本统一到一个对象中，并暴露出扩展点，通过不同语言的插件对其进行翻译；
- 文章本身的国际化，通过插件 +
文章翻译自定义对象的方式来实现，可以为每个已经存在的文章添加不同语言的翻译版本。
可以考虑下国际化也通过插件的方式来实现
我认为是可行的，专门为多语言的场景设计好扩展点即可。
/cc @halo-dev/sig-halo
直接给文章存内容的表加上对应的字段，这是按文章维度
倾向于这种方式，目前 1.5 就已经有了 contents 表，专门用于存储内容，也许只需要改动这张表即可。最终 2.0 在设计这块的时候也可能按照这种方式。
直接给文章存内容的表加上对应的字段，这是按文章维度
倾向于这种方式，目前 1.5 就已经有了 contents 表，专门用于存储内容，也许只需要改动这张表即可。最终 2.0 在设计这块的时候也可能按照这种方式。
这种方式的缺点是：在文章数量比较多的情况下，查询的性能可能有些低，而且在只需要一个语言版本的文章内容时，直接查出了所有的语言版本，大概有部分冗余，可以考虑放到缓存里，但是如果放到缓存，内存占用可能又比较大。
这种方式的缺点是：在文章数量比较多的情况下，查询的性能可能有些低，而且在只需要一个语言版本的文章内容时，直接查出了所有的语言版本，大概有部分冗余，可以考虑放到缓存里，但是如果放到缓存，内存占用可能又比较大。
那我理解错了。我的意思是加一个 locale 字段，每个语言一条数据。而不是加 zh en jp 字段。
这种方式的缺点是：在文章数量比较多的情况下，查询的性能可能有些低，而且在只需要一个语言版本的文章内容时，直接查出了所有的语言版本，大概有部分冗余，可以考虑放到缓存里，但是如果放到缓存，内存占用可能又比较大。
那我理解错了。我的意思是加一个 locale 字段，每个语言一条数据。而不是加 zh en jp 字段。
明白了，一篇文章对应内容表多条记录，要哪个查哪个。
还需要考虑每个语种的内容（主题、页面、文章）的排版布局都是不一样的，并不是说将中文的“一二三四"翻译成英语的“abcd”就解决了国际化问题。 国际化实际上是拥有同一标识的多个不同内容之间的切换，所以单单为翻译增加扩展点可能并不够灵活。
文章多语言，请问有实现了么
期待！
翻译区分前台和后台，我不懂代码和相关技术，但是用过WP和WP翻译插件建站，有些思路可以借鉴，简单说说自己的看法。
前台：前台也就是网站内容翻译，不限定只有文章，前台站点所有能看到的都可以翻译，文章标题、图像、字符块等等。并且根据翻译的内容语言设定相应的二级目录/fr、/en、/jp，这种二级目录对于用户和搜索引擎比较友好。通过相应的标签例如hreflang来指示页面的语言和地区，至于让用户看到什么语言的网站，可以根据用户的设备语言和IP来自动判定和跳转（这个会影响性能），亦或者不做条件判定让用户自己选择。
后台：halo后台的翻译，不止是halo自己自身，还有主题和插件的翻译，因为有些主题和插件的相关字段也会显示在前台网站内容上。
前台和后台的翻译由专门的插件来进行，前台和后台可以选择不同语言（后台中文，前台站点默认语言是英文这种），官方提供相应的API接口和方案，然后站长可以自行翻译halo、主题、插件，可以将相关语言文件提交给相应的作者以供审核内装，来实现翻译文件随着halo、主题、插件的更新而更新并自动切换。前台后台的翻译区分开，后台官方可以先出个插件，前台的翻译可以由第三方插件来实现。毕竟现在生态刚起步，什么插件功能的扩展和实现都靠官方不现实，保证halo自身的简洁很重要，halo保证核心功能即可。
或许我可以试试课题？
国际化可能涉及到翻译不了的情况，比如同一个页面，中文是 你好**，日文是你好日本等
可以参考下hugo，不同的文章后缀不一样，现在从hugo往这边转，还不知道怎么把多语言文章转过来呢