Den*_*rdy 17 ruby localization internationalization sinatra padrino
对于Ruby来说有些新东西我正在探索现有的库来执行我通常在其他脚本语言中所做的事情,而且我对可能用于构建在Sinatra/Sequel(Rails之上)的东西的本地化库感到有点困惑/ AR根据我的口味有点过于自以为是.
现在,我通过这个wiki页面遇到了一对(i18n,r18n,GetText),显然在Padrino中使用了一个额外的库(基于来自Rails的i18n的东西？); 而且显然还有更多.
除了显而易见的(即GetText mo/po样式与yml文件)之外,我对这些选项如何不同感到困惑.除了说它们存在之外,维基在这方面并没有太多指出; 不是他们如何不同.
更令人困惑的是,基本上每一篇文档似乎都涵盖了其中的一篇(通常在RoR上下文中).而且,这些选项在仔细检查时看起来并不完全不相容 - 从某种意义上说,如果我理解这一点,他们可以在很大程度上理解彼此的文件.
这里的任何人都可以对这些库进行快速和简要的解释/概述,并概述它们之间的区别吗？关于性能的一些指示也是受欢迎的,如果你知道任何(除了来自fast_gettext文档的那些,考虑到我对这些选项之间的差异缺乏理解,这没什么意义).
sve*_*chs 30
如果不了解Ruby中i18n/l10n库的一些历史,我可以看到这种情况如何令人困惑.我应该就此写几句话,但是现在我将尝试从我的角度给出一个概述:
Gettext显然是这个游戏中最年长的玩家,它继承了其祖先的优势和劣势,这是为C主导的世界发明的.它具有一个需要的大多数功能,带有一些其他人缺乏的工具支持(如桌面po文件编辑器),并在所谓的企业世界中被广泛接受.
Gettext本身定义了一个API,基本上有两个库在Ruby世界中实现它,Masao Mutoh的传统Ruby Gettext包和Michael Grosser的fast_gettext gem .
Ruby Gettext非常强大,并且提供了许多您可能需要或不需要的功能.另一方面,fast_gettext gem专注于原始速度,并作为一个闪亮的,现代的代码风格的Ruby库实现,很容易被破解,作者是一个非常聪明和支持的人.在这两个中,我个人强烈推荐fast_gettext.
该的I18n宝石是前几年存在的各种红宝石国际化/本地化解决方案的共同努力的结果,所有的努力,以取代的Gettext在那个时间点有多种原因.由此产生的I18n API基本上涵盖了当时涉及的所有i18n/l10n解决方案的要求和用例,包括Gettext的API.因此,今天的Ruby I18n API是90年代初期Gettext API的超集.
今天,I18n gem是Ruby on Rails附带的官方解决方案,但它也是Ruby世界中最受欢迎的一个.
I18n gem还可以非常轻松地扩展功能集并添加缓存,其他存储机制(如Gettext po文件,数据库表,键值存储;存储默认为纯Ruby文件和YAML等)等内容.一数量的模块为(但外部或自定义模块可以容易地制作,测试和集成的).
对于由社区维护的Ruby on Rails使用的字符串(在其他项目中也很有用),有70多种语言(语言环境)的翻译文件.
我不能说R18n,除了它是在I18n首次发布之后发明的,据我记得它起源于Merb社区.它似乎在俄罗斯的Ruby世界中相当强大,但我可能错误的所有这些断言.
因此,除非您有充分的理由选择任何其他解决方案,否则我强烈建议您使用I18n.
另一方面,这意味着什么,因为自从它被发明以来,我或多或少地领导了这个项目.
我希望这有帮助.
[编辑]添加了各种参考文献的链接
I18n是主流.
R18n是一种替代方案,具有一些额外的功能(模型翻译,语法糖)以及意识形态和架构的一些差异(强大的过滤器的灵活扩展性).
G18n需要向I18n添加模型转换.
Padrino不是一个i18n库,它只是带有内置I18n的Sinatra框架.
Gettext是恕我直言的旧概念,具有非常难看的格式和多元化的问题.无论如何,它在Ruby社区中并不流行.
第一：
正如svenfuchs所写，这I18n是一个为许多翻译和国际化方法提供模块的框架。
“ gettext”只是许多模块之一。
因此，确实没有问题可以使用I18n。
Rails应用程序的默认设置是I18n与YAML后端一起使用，我理解您的问题的一部分，以便将该后端与其他后端进行比较。
恕我直言，gettext和YAML方法之间有两个主要区别：
文字
一个想法gettext是，翻译应用程序不是单个事件，而是生命周期过程。
它是为支持此实时周期而构建的。
gettext被设计为使用简单的英语作为翻译的键。因此，我们的想法是用英语编写该应用程序，并标记所有要翻译的文本，通常是使用来包装它_()。
因此，该应用程序源代码易于用英语阅读。
然后，程序将扫描所有源代码并提取要翻译的文本，并建立这些文本的存储库（.pot文件）。
下一步，即实时循环，存储库与现有翻译（.po文件，每种目标语言一个）合并，并标记了新的或更改的项目。
成熟的编辑通过专注于新的和更改的项目来支持翻译。另外，针对项目的词典可以支持部分自动翻译。
gettext为flat，表示每个关键短语在翻译文件中仅翻译一次。没有层次结构。但是有上下文。在翻译文件中，列出了关键字的所有源代码位置。有权访问源代码的编辑者可以将源代码与翻译一起显示（有些也可以）。
最后，.po文件被转换为机器可读的快速访问形式（可以是.mo，经典标准或数据库或json或…）
YAML
另一方面，YAML是分层的，因此很容易在不同的上下文中进行翻译。当使用以点开头的键时，
I18n使用此结构来支持scopes并使用当前文件路径作为作用域。
没有信息，项目中使用了密钥（除非自动调整范围，否则密钥可以在其他地方使用）。
没有任何信息，是否有任何更改。
除非您的IDE支持，否则开发人员必须找到正确的位置将密钥放入YAML中，并且搜索用法可能很麻烦。在其他答案中还说了很多。
I18n
我故意说YAML而不是I18n，因为I18n是国际化的框架（不仅是翻译），而YAML只是一个可能的后端。
I18n中的复数支持不同于香草gettext的复数支持。我没有经验，他们如何合作。
例子
带有位置参数的gettext：
sprintf(
_('Do you really want to delete tour %1$s_%2$s? Only empty tours can be deleted!'),
tag, idx)
翻译是文本文件，但PO编辑器提供GUI：
#: js/addDelRow.js:15
msgid "" "Do you really want to delete tour %1$s_%2$s? Only empty tours can be deleted!"
msgstr "" "Wollen sie die Spalte %1$s_%2$s wirklich löschen? Nur leere Spalten können "
"gelöscht werden."
具有参数的YAML：
资源
<%= t('.checked_at', ts: l(checked_at), user: full_name) %>
翻译
自
en:
hotels:
form:
checked_at: „set to checked by %{user} on %{ts}“
至
de:
hotels:
form:
checked_at: "geprüft gesetzt am %{ts} von %{user}“
结论
开始使用YAML更加容易，特别是如果您有IDE支持。
Vanilla RAILS具有内置功能。
这不是母语。第一翻译可以是任何语言。随着项目的增长和多种语言的使用，我的YAML文件趋向于重复（相同的翻译分散在整个层次结构中）并跟踪更改，因此新的翻译很麻烦。
gettext需要额外的工具链，因此设置起来更加困难。
它支持开发应用程序的连续翻译的整个生命周期。
它基于英语源代码。
我通常都使用这两者的最好的部分，使用YAML进行国际化（数字和日期格式，也许是模型名称？）和使用gettext进行翻译。