如何在ActiveAdmin中保持UI和内容本地化

Posted 2021-04-17

我们需要开始使用不同的应用程序以多种语言提供动态内容。

应该考虑两种类型的本地化：UI本地化和内容本地化。 UI本地化是接口交付的语言（静态文本），而内容本地化是查看/编辑语言内容（Rails模型）

我们基本上有3种类型的应用程序

1. 移动应用程序 - 为CRUD操作命中API端点
2. 客户端Web应用程序 - 使用backbone.js构建，因此也通过骨干模型/集合使用API​​端点进行CRUD操作
3. 管理员网络应用程序 - 使用activeadmin（https://github.com/activeadmin/activeadmin）构建

我应该注意到我们正在使用Rails 3.2，ActiveAdmin 0.6.6（需要升级但不是优先级:)）

为了本地化内容，我们正在寻找全球化的宝石（https://github.com/globalize/globalize）

在与API端点连接时，使用globalize似乎没有任何问题。我们可以使用Accept-Language标头并在before_filter中设置I18n.locale属性，一切似乎都能正常工作。这意味着应该涵盖移动应用和客户端Web应用。

对于ActiveAdmin，这变得有点困难。对于ActiveAdmin应用程序，我们希望以用户首选语言提供UI静态文本，同时允许它们在内容的语言之间切换。

globalize gem利用I18n.locale属性来确定更新/读取内容翻译的区域设置。由于ActiveAdmin不使用AJAX，因此设置I18n.locale也会影响UI静态文本。

目前，这不是什么大问题，因为我们只有一个UI的区域设置（config / locales只包含en yml文件）。这意味着我们可以使用https://github.com/activeadmin/activeadmin/wiki/Specifying-locale中描述的方法并设置I18n.locale属性以通过globalize更新正确的动态内容，同时UI界面将继续以英语提供

但是，考虑到未来，我们可能会为UI添加其他语言，我正在寻找如何保持UI区域设置和内容区域设置分离的想法。其他语言，例如Java和C＃，在它们的I18n等效库上使用不同的属性执行此操作，但Rails似乎不接受这个

思考？

提前致谢

答案

经过进一步调查，我最终使用了activeadmin-globalize gem。最初，我并不认为它与基于文档的globalize gem兼容，但确实如此