（新）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"
答案 0 :(得分：3)
退后一两分钟。你在这里做三重工作。首先你必须提出一个UNIQUE_ID，然后你强迫人们从代码或另一个语言文件中查找上下文，以确定AMBIGUOUS_ARGUMENT_PROVIDED的正确消息是什么，直到你得到下来提供实际的翻译。曾经说过，创建可以有意义地传达上下文并提供良好消息提示的ID非常简单？
你想要做的是一些荒谬的狗屎兄弟！除了笑话之外，gettext 是最常用且最广泛使用的i18n和l10n API的原因是因为每条消息都获得了从其内容分配的唯一消息目录ID，并且因为它证明了你将有更好的时间翻译消息而不是提供ID的翻译，让人联想到每个人都尝试制作自己的关键词＆gt;重视i18n框架，因为它是最直接的设计。
你最终会得出结论，以不应该的方式使用gettext是一个坏主意，你现在可以通过忘记整个想法来拯救自己。
答案 1 :(得分：2)
如果你坚持这样做，那么可以通过生成一个包含源字符串英文翻译的.po文件来完成。