我有一个基于Django的API层,它在内部使用Django的i18n工具(ugettext等)来为某些输出提供翻译.

API提供单页
Javascript应用程序,该应用程序通过CLDN /消息文件等使用jQuery的Globalize及其自己的消息传递工具.

目前,我以全球化消息模块的JSON文件的形式为UI创建了自己生成的语言文件.
理想情况下,我想从一个位置驱动所有可翻译的文本.我希望使用Django作为可翻译语言的单一真实来源(因为我可以使用Rosetta作为促进翻译的一种方式).但是,如何使两者协同工作并不是那么简单,我试图避免发明我们自己的惯例,以防止未来与其他开发人员混淆.

首先,一些文本块大于几个单词.使用Django的ugettext我希望提供要翻译或显示为参数的文本 – 提供一个密钥并要求翻译存在(或者只是密钥会显示)是一个很好的惯例吗？

第二,这种用例是否有既定的惯例？
如果规范对于这种情况有意义,我不想重新发明轮子或偏离常规.

第三天 – 我希望在两者之间做出选择？或者翻译是否存在于Django / API世界中,然后在UI请求时输出为Globalize / messages格式？或者我应该使用Django提供的Javascript gettext实现？

谢谢

最佳答案
Django’s JS internationalization是非常强大的,并伴随着所有的良好实践.

你说过,最好不要重新发明轮子.

如果你的同事习惯使用Django,我认为他们会很感激这一举动.

我不是专家,但Django的i18n每个块可以管理多个单词,它可以提供段落,.po文件将是这样的：

msgid ""                                                                                                                                                                  
"Lorem ipsum dolor sit amet, consectetur adipiscing elit."
" Duis ut lacus nec lacus rhoncus luctus."
" Donec luctus fringilla massa, eu accumsan odio vestibulum fermentum."
" Fusce arcu urna, tincidunt id turpis sed, rutrum lobortis sem." 
msgstr ""
"Translation goes here, and it can be on multiple lines"