5

我有一个基于 Django 的 API 层，它在内部使用 Django 的 i18n 工具（ugettext 等）来提供对某些输出的翻译。API 提供一个单页 Javascript 应用程序，该应用程序利用 jQuery 的 Globalize 和它自己的消息传递工具，通过 CLDN/messages 文件等。

目前，我有自己为 UI 生成的语言文件，格式为 Globalize 消息模块的 JSON 文件。
理想情况下，我想从一个位置驱动所有可翻译的文本。我希望使用 Django 作为可翻译语言的唯一真实来源（因为我可以使用 Rosetta 作为促进翻译的一种方式）。然而，如何让两者一起工作并不是那么简单，我试图避免在它们可能已经存在的地方发明自己的约定，以防止将来与其他开发人员混淆。

首先，一些文本块大于几个单词。使用 Django 的 ugettext 我应该提供要翻译或显示为参数的文本 - 只提供一个键并要求翻译存在（否则，只显示键）是一个好的约定吗？

其次，这种用例是否有既定惯例？
如果规范对这种情况有意义，我不想重新发明轮子或偏离规范。

第三- 我应该在两者之间做出选择吗？或者翻译可以存在于 Django/API 世界中，然后在 UI 请求时输出为 Globalize/messages 格式？或者我应该使用 Django 为 Javascript 提供的 gettext 实现？

谢谢

4

1 回答 1

2

Django 的 JS 国际化功能非常强大，并附带了所有好的实践。你说了算，最好不要重新发明轮子。

在我看来，如果你的同事习惯使用 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"
于 2016-05-06T21:06:14.600 回答