在Django中提供Rails-way i18n支持的好方法

Question

在(新)Rails中有一件事我羡慕:国际化支持(Django也有一个,但我更喜欢Rails的味道).

Rails'和Django的方法之间的关键区别在于什么类型的字符串在键值转换映射中表现得像键,即

Django版本(键 - "主要"语言的字符串,例如英语):

msgid "Save and quit"
msgstr "Zapisz i wyjd?"

Rails版本等价(键 - 抽象字符串;独立不可用 - 需要提供至少1个"翻译") - 实际上,Rails使用YAML格式,但下面的示例提出了这个想法:

// english translation file

msgid "SAVE_QUIT_MESSAGE"
msgstr "Save and quit"

和

// polish translation file

msgid "SAVE_QUIT_MESSAGE"
msgstr "Zapisz i wyjd?"

Rails支持i18n的方式是恕我直言更好(想想关键不变性 - 抗语法/拼写纠正;语言不可知论等).

在Django中使用这种模式的一种方法是使用一些抽象语言,仅用于翻译(该语言中的字符串将生成不可变密钥),但Django仅支持固定的语言集.另一个解决方案 - 牺牲一种支持的(未使用的)语言来扮演这个角色 - 但这很糟糕:P

任何想法/第三方应用程序/技术来解决这个问题？

---

旁注:扩展i18n对artibrary语言的支持会带来有趣的机会:

// slang translation file

msgid "SAVE_QUIT_MESSAGE"
msgstr "Save shit 'n' quit, bro"

Answer 1

后退一两分钟。你在这里做三重工作。首先，你必须想出一个UNIQUE_ID，然后你强迫人们从代码或其他语言文件中查找上下文，以找出正确的消息是什么，AMBIGUOUS_ARGUMENT_PROVIDED直到你开始提供实际的翻译。谁曾说过创建能够有意义地传达上下文并提供良好消息提示的 ID 是一件容易的事？

你想做的是一些荒谬的事情，兄弟！抛开笑话不谈，gettext是最流行和最广泛使用的 i18n 和 l10n API 的原因是因为每条消息都会从其内容中分配一个唯一的消息目录 ID，而且事实证明，与提供 ID 的翻译相比，您翻译消息的时间会更好，让人想起当时每个人都尝试制作自己的 key->value i18n 框架，因为它是最简单的设计。

您最终会得出结论，以不恰当的方式使用 gettext 是一个坏主意，您现在可以通过忘记整个想法来拯救自己。