2011-03-08 21 views
5

在(新)Rails Ivy中有一件事:国际化支持(Django也有一个,但我更喜欢Rails的风格)。在Django中提供Rails-way i18n支持的好方法

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

解决此问题的任何想法/第三方应用程序/技术?


旁注:延长artibrary语言的国际化支持将使有趣的机会:

// slang translation file 

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

...或者你可以生成一个英文的.po文件... – 2011-03-08 22:24:29

+0

@Ignacio Vazquez-Abrams:我不确定我是否理解。你能更详细一点吗?生成.po文件解决了哪个问题?也许在我的问题中有些事情不清楚 - 如果是的话,引导我,我会编辑它。 – gorsky 2011-03-08 22:34:24

+0

英文语言的.po文件,与法文,德文等相同 – 2011-03-08 22:43:55

回答

3

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

你想做的是一些荒谬的狗屎兄弟!除了笑话之外,原因gettext i18n和l10n API是最流行和广泛使用的原因,因为每条消息都会从其内容中分配唯一的消息目录ID,并且经证明,与翻译相比,您可以更好地翻译消息对于ID,让人联想到每个人都试图制作自己的键值>国际化框架,因为这是最直接的设计。

您最终会得出结论,以不符合想法的方式使用gettext是一个坏主意,您可以通过忘记整个想法来节省自己。

+0

在Django 1.3中(希望如此),将会有方法通过关于翻译上下文的一些注释(http://docs.djangoproject.com/en/dev/topics/i18n/internationalization /#comments-for-translators),这将解决这些问题。我不想摆脱gettext(这太棒了),而是使用不可变键来完成翻译工作(想想已经发布的应用程序,贡献者翻译成多种语言,需要更改“main”language = translations broken )。看看Ignazio评论/回答,似乎解决了我的情况。 – gorsky 2011-03-08 23:08:05

+0

gettext可以很好地处理目录中的所有“msgid”更改。你也忽略了这里的开发者。他们真的错过了'SAVE_QUIT_MESSAGE'在处理该代码块时应该表示的内容,除了.po文件中的翻译之外,它没有文档。 – 2011-03-08 23:15:03

+0

翻译评论将在代码和翻译文件中都可见。但我不知道gettext更改处理能力(我猜应该更仔细地阅读docs),这似乎是对我的问题的真实答案。 – gorsky 2011-03-08 23:56:31

2

如果你坚持这样做,那么可以通过生成一个包含源字符串英文翻译的.po文件来完成。

+0

+1这解决了我的问题,但Filip(接受的答案)让我不要使用这种技术并提供适当的解决方案。 – gorsky 2011-03-09 00:02:36