Ruby本地化：i18n，g18n，gettext，padrino ... - 有什麼區別？

Question

對Ruby有些新鮮我正在探索現有的庫來完成我通常在其他腳本語言中所做的工作，而且我可能會對可能用於構建在Sinatra/Sequel之上的某些東西的本地化庫感到困惑（Rails/AR對我的口味有點太自以爲是）。

現在，我遇到了一對（i18n，r18n，GetText），雖然this wiki page，並且顯然Padrino中使用了額外的庫（基於Rails的i18n事物？）;顯然還有更多。

除了顯而易見的（即GetText mo/po風格vs yml文件）之外，我對這些選項如何可能會有所不同有些困惑。維基在這方面並沒有多少指出，除非說它們存在;不是他們有什麼不同。

此外，基本上每一個文檔似乎都包含其中的一個文檔（通常在RoR環境中）。而且，這些選項在仔細檢查時看起來並不完全相互矛盾 - 從某種意義上說，如果我能夠正確理解這一點，他們就可以在很大程度上理解對方的文件。

在這裏，任何人都可以快速地對這些庫進行點解釋/概述，並概述它們之間的區別？如果您知道任何（除fast_gettext文檔以外的其他文檔，考慮到我對這些選項之間的差異缺乏瞭解），那麼對性能的某些指示也會受到歡迎。

Answer 1

我可以看到這種情況如果不知道Ruby中i18n/l10n庫的一些歷史記錄是如何混淆的。我應該寫幾個字，但現在我試着從我的角度給出一個概述：

Gettext顯然是這個遊戲中最古老的玩家，它繼承了它的祖先的優點和缺點正在爲一個以C爲主的世界而發明。它擁有大多數人所需要的功能，並附帶了其他人缺乏的工具支持（如桌面po文件編輯器），並在所謂的企業世界中被廣泛接受。

的Gettext這樣定義API和基本上有兩個庫實現它在Ruby世界中，傳統的Ruby Gettext包由Masao Mutoh和fast_gettext寶石的Michael Grosser。

Ruby Gettext功能非常強大，並提供了許多您可能需要或可能不需要的功能。另一方面，fast_gettext gem專注於原始速度，並被實現爲一個閃亮的現代代碼風格的Ruby庫，它很容易被破解，作者是一個非常聰明和支持的人。在這兩個我個人強烈建議fast_gettext。

I18n gem是幾年前存在的各種Ruby i18n/l10n解決方案的共同努力的結果，並且在當時各種原因都努力取代Gettext。由此產生的I18n API基本涵蓋了當時涉及的所有i18n/l10n解決方案的需求和使用情況，包括Gettext的API。因此，今天的Ruby I18n API是90年代初Gettext API的超集。

今天I18n的寶石是shipped with Ruby on Rails的官方解決方案，但它也可能是一般在Ruby世界中的most popular。

I18n gem也使它具有very easy to extend的功能集並添加諸如緩存，其他存儲機制（如Gettext po文件，數據庫表，鍵值存儲;存儲默認爲普通的Ruby文件和YAML）等等，其中number of modules（但外部或自定義模塊可以很容易地製作，測試和集成）。

社區維護的Ruby on Rails使用的字符串（在其他項目中也很有用）有一些用於70+ languages（語言環境）的翻譯文件。

我不能講太多關於R18n，只是它是在I18n第一次發佈後發明的，並且據我記得它起源於Merb社區。這在俄羅斯紅寶石世界似乎相當強大，但我可能對所有這些斷言都是錯誤的。

所以，除非你有很好的理由選擇其他解決方案，否則我強烈建議使用I18n。

然後另一方面，這意味着什麼都沒有，因爲I've been leading this project自發明以來或多或少。

我希望這會有所幫助。

[編輯]添加鏈接到各種參考

Answer 2

安德烈的是指向我回r18n docs，基本上打破它單行響應：

R18n採用分層次的，不是英語爲中心，YAML默認情況下爲翻譯格式。

從Andrey找到了這張slideshare。它在俄羅斯，但它（在國際化和r18n之間特別鮮明的差異幻燈片7〜9），使得很多更有意義現在：

http://www.slideshare.net/iskin/r18n

Answer 3

的I18n是主流。 R18n是一個具有一些額外功能（模型翻譯，語法糖）以及意識形態和體系結構（通過強大的過濾器實現靈活擴展）的一些不同的替代方案。

G18n需要將模型轉換添加到I18n。

Padrino不是i18n庫，它只是帶有內置I18n的Sinatra框架。

Gettext是恕我直言舊概念與非常醜陋的格式和複雜性的問題。無論如何，它在Ruby社區中並不流行。

Answer 4

第一：
爲svenfuchs寫道：I18n是提供模塊許多翻譯和國際化的方法框架。
'gettext'只是衆多模塊中的一個。

所以真的沒有問題可以使用I18n。

Rails應用程序的默認設置是使用I18n與YAML後端，我理解你的問題的一部分，以比較與其他的後端。

---

恕我直言有是gettext和YAML基礎的方法之間有兩個主要區別：

• 生命週期支持
• 層次

gettext的

gettext的一個想法是，翻譯應用程序不是一個單一的事件，而是一個生命週期過程。
它支持這個生命週期。

gettext旨在使用純英文作爲翻譯的關鍵。所以這個想法是用英文編寫應用程序，並且標記所有要翻譯的文本，通常是用_()包裝它。
因此，應用程序源代碼易於用英語閱讀。

然後，程序掃描所有源代碼並提取待翻譯的文本，並構建這些文本的存儲庫（.pot文件）。

在接下來的步驟，和來這裏的現場循環，該倉庫是合併與現有的翻譯（的.po文件，每一個目標語言）和新的或變更的項目標記。

成熟的編輯通過關注新的和已更改的項目來支持譯員。此外，項目特定的字典可以支持部分自動翻譯。

gettext是flat，這意味着每個關鍵短語在翻譯文件中只翻譯一次。沒有層次結構。但有上下文。在翻譯文件中，列出了關鍵短語的所有源代碼位置。可以訪問源代碼的編輯器可以顯示源代碼以及翻譯（還有一些）。

最後，.po文件被翻譯成機器可讀的快速訪問形式（可的.mo，經典的標準，或數據庫或JSON或......）

YAML

YAML的一個另一方面是分層的，所以很容易在不同的上下文中有不同的翻譯。
I18n使用此結構來支持scopes，並使用當前文件路徑作爲使用以點開頭的鍵的範圍。
沒有任何信息，在項目中使用密鑰的地方（除非自動作用域，但密鑰可以在其他地方明確使用）。
沒有信息，是否有任何更改。
除非您的IDE支持您，否則開發人員必須找到放置YAML密鑰的正確位置，並且搜索用法可能非常麻煩。 在其他答案中說了很多。

的I18n

我故意說：YAML而不是的I18n，因爲的I18n是國際化的一個框架（不僅是翻譯），和YAML只是一種可能的後端。
I18n中的複數支持與vanilla 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進行翻譯。