我正在为一个基于Python/django的网站编写i18n/l10n。
我的愿望是尽量减少字符串的数量，并避免只有大小写差异的相同文本，如果可能的话。也就是说，我不想保留"你的追随者"，"你的追随者"one_answers"你的追随者"——这违反了DRY，我担心事情会很快失去同步。。
考虑到Django喜欢在模型字段标题中使用小写字母，我有很多字符串都是小写的，除了作为专有名词。例如:
class User(models.Model):
...
# In my understanding, Django wants me to use "registration date",
# not "Registration date" or "Registration Date" here.
registration_date = models.DateField(_("registration date"), ...)
# But "Skype" is a proper noun and we want it capitalized.
# Note, in some languages it won't be the first word,
# e.g. "nome de usuário Skype" in Portuguese.
skype_username = models.CharField(_("Skype username"), ...)
...
然而，设计师的愿望是在大多数页面和表格标题/页眉中每个单词的首字母大写。所以，我想，我将保留非大写的文本，但使用{{ ...|title }}模板过滤器。
但是翻译说，在某些语言中，把代词大写是不好的。即使在英语中，它们看起来也不太好。因此，网站应该写"服务条款"one_answers"Política de Privacidade"，而不是"服务条款"或"Política de Privacidade"。而在法语中——我们现在还没有针对它，但我相信总有一天我们会针对它——大写规则看起来比"不要碰那些"单词(那些"l"等等)的列表要复杂得多。
所以我想知道建议的方法是什么，这将使头痛的数量尽可能少。
看来我的选择是:
- 找到一个不大写介词的语言感知字符串大写的解决方案。那里有现成的东西吗?我不确定我是否想自己写一个，因为我不精通我们的目标语言。
- 忽略Django的规则，在翻译数据库中存储字符串的大写版本，然后根据需要小写。但是，这可能会导致专有名词和名字的问题。
- 在翻译文件中存储同一文本的多个版本(不同的大小写)。我真的希望避免这种情况。 还有什么我没想到的吗?
我想这应该是相当常见的情况，有很多程序员已经遇到过类似的情况。如能就如何处理此事提供任何建议，我将不胜感激。
我可能没有完美的解决方案，但这里有一些我认为值得分享的想法:
-
"考虑到Django喜欢在模型字段标题中使用小写字母，我有很多字符串都是小写的，除了专有名词"。
我想你是糊涂了。Django不喜欢或不喜欢任何类型的大写，这完全取决于你。Django做的唯一一件事是，当你省略verbose_name参数时，它会根据字段名自动生成字段的详细名称。当这些是自动生成的(即您没有明确地提供自己的verbose_name以及在gettext()调用中包装它)，它们是不可本地化的。 -
不要认为你的设计师说的是理所当然的-他们通常会考虑英语ui
-
一般来说，把大写留给本地化人员:他们是最值得信任的人，根据上下文，他们知道大写应该如何工作。当你说"找到一个不大写介词的语言感知字符串大写的解决方案"时，你对目标语言做了太多的假设:它们很可能有自己的语言和样式规则，但更重要的是，它们甚至可能没有介词!
-
为本地化人员提供尽可能多的注释和上下文。本地化按钮、标题、工具提示等就不一样了。
在Django中，你可以使用以Translators:开头的注释来实现这一点，也可以使用pgettext()来提供上下文标记。 -
不要太聪明地在源文本中应用常规的编程技术。DRY在这里可能不是正确的做法。
让我解释一下我的观点:即使您设法合并了大小写不同的源代码字符串，这并不意味着您可以愉快地休息，因为您可能会引入比以前更多的问题。
举个例子，假设你有view和view，如果你盲目地合并它们，本地化器将得到一个单一的字符串来翻译，但是你猜怎么着，你可能会产生一个问题，因为根据上下文和语法情况view可以被不同地翻译成其他语言:它可以是动词，名词等。 -
总的来说，我相信这个问题可以在你的i18n/l10n工作流程的其他地方解决。
您可以预先翻译您的PO文件(这里有一个例子，可能还有更多)，从而重用已经存在的翻译并将空翻译预先填充为模糊的。最终决定权在本地化人员:如果他们满意，他们可以简单地删除模糊标记，或者相应地调整文本。