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

（新）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"

and

// 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"

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

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

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