【问题标题】:Website localization, Title Capitalization and avoiding duplicates网站本地化、标题大写和避免重复
【发布时间】:2015-08-06 10:35:18
【问题描述】:

我正在为基于 Python/Django 的网站开发 i18n/l10n。

如果可能的话,我希望尽量减少字符串的数量,并避免只有大小写不同的相同文本。 IE。我不想保留“你的追随者”、“你的追随者”和“你的追随者”——这违反了 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 }} 模板过滤器。

但是翻译人员说在某些语言中将代词大写是不好的。即使用英语,它们看起来也不好看。因此,该网站应该说“服务条款”和“Política de Privacidade”,而不是“服务条款”或“Política De Privacidade”。在法语中——我们现在不针对,但我相信有一天我们会的——大写规则看起来比仅仅列出“不要碰那些”单词(那些“l'”等等)。

所以我想知道这种东西的建议方法是什么,这样可以尽可能少地减少头痛。

看来我的选择是:

  1. 找到一种不将介词大写的语言感知字符串大写解决方案。那里有什么现成的东西吗?鉴于我不精通我们所针对的某些语言,我不确定我是否想自己写一个。
  2. 忽略 Django 的规则并将字符串的大写版本存储在翻译数据库中,然后根据需要将它们小写。不过,这会对专有名词和名字产生影响。
  3. 在翻译文件中存储相同文本的多个版本(大小写不同)。我真的希望避免这种情况。
  4. 还有什么我没想到的?

我想这应该是相当普遍的情况,并且有很多程序员同行已经遇到过这样的事情。对于如何处理此事的任何建议,将不胜感激。

【问题讨论】:

    标签: python django internationalization translation dry


    【解决方案1】:

    对于您的问题,我可能没有完美的解决方案,但这里有一些我认为值得分享的想法:

    • “鉴于 Django 喜欢在模型字段标题中使用小写字母,所以我的很多字符串都是小写的,除了专有名词”
      我想你在这里很困惑。 Django 不喜欢或不喜欢任何类型的大写,这完全取决于你。 Django 唯一做的事情是,每当你省略 verbose_name 参数时,it auto-generates field's verbose names based on the field name。当这些是自动生成的(即您没有明确提供自己的 verbose_name 以及将其包装在 gettext() 调用中)时,它们不可本地化

      李>
    • 不要想当然地认为你的设计师所说的 - 他们通常会考虑英文用户界面。

    • 一般而言,将大写留给本地化人员:他们是最值得信赖的人,可以根据上下文了解大写的工作方式。当你说“找到一种语言感知字符串大写的解决方案不会大写介词时,你对目标语言做了太多假设:他们很可能有自己的自己的语言和样式规则,但更重要的是,它们甚至可能没有介词!

    • 为定位器提供尽可能多的 cmets 和上下文。本地化按钮、标题、工具提示消息等是不一样的。
      在 Django 中,您可以使用 comments starting with Translators:pgettext() for providing context markers 来实现此目的。

    • 不要试图太聪明,将常规编程技术应用于源文本。 DRY 在这里可能不是正确的做法。
      让我解释一下我的观点:即使您设法合并所有大小写不同的源代码字符串,但这并不意味着您可以愉快地休息,因为您可能会引入比以前更多的问题。 举个例子,假设你有 viewView,如果你盲目地合并它们,本地化器会得到一个单独的字符串来翻译,但你猜怎么着,你可能会产生问题因为根据上下文和语法情况,view 可以不同地翻译成其他语言:它可以是动词、名词等。前一点在这里适用。

    • 总的来说,我相信这个问题可以在您的 i18n/l10n 工作流程的其他地方得到解决。
      您可以预先翻译您的 PO 文件 (one example here, there are probably more),从而重新使用已经存在的翻译并将空翻译预填充为模糊。最终决定权留给本地化人员:如果他们对模糊标记感到满意,他们可以简单地删除它,或者相应地调整文本。

    【讨论】:

    • 谢谢,这些提示很有帮助!只有两件事:1)我仍然相信 Django 更喜欢小写 verbose_name,因为这些值是如何在 django.contrib.auth 和 admin 中使用的(文本如“Edit %(model_name)s”,权限等),自动生成ModelForms和相关的东西; 2)是的,我理解你的例子中同音词之间的区别 - 我没有合并它们,但是统一具有相同语义并且实际上只与样式不同的相同文本是不明智的 - 字符大小写 - 和让|title filter 或 CSS text-transform 之类的东西来完成这项工作?
    • 1) 我要说的是 django-admin 应用程序的缺点。在本地化的 django-admin 中,是什么让您认为 %(model_name)s 不是第一位的? ;) 2) 作为一般规则,不要依赖|title(取决于您的服务器区域设置github.com/django/django/blob/…)、text-transform(它在某些语言中无法正常工作(例如土耳其语)developer.mozilla.org/en-US/docs/Web/CSS/…)和之类的,尽管取决于您的目标语言环境,它可能是可以接受的。
    • 1) 只要翻译字符串是完整的并且不是由块组成,单词顺序就不是问题。例如,Django admin 在土耳其语中用“%(name)s ekle”翻译“Add %(name)s”。但是,由于某种未知原因,它不适用于capfirst,从而导致奇怪的“eposta adresi ekle”。所以,我想,即使在成熟的项目中,事情仍然很混乱...... 2)是的,我知道那些资本化问题。这就是为什么我寻找一个比我自己编写代码做得更好的库的原因。我想我会坚持使用不同大小写的多个字符串。
    • julen 是对的,你会引入比你解决的更多的问题。即使对于相同的含义,某些语言也需要不同的翻译。例如,法语(和所有拉丁语)翻译“描述”(标题、标签)与“命令”(按钮)不同。 “打印”在标题中将是“印象”,但在按钮中将是“印象”。然后你需要考虑性别和数量。西班牙语中的“新”将是“Nuovo”(sing.masc.)、“Nuova”(sing.fem.)、“Nuevo”(pl. masc)、“Nuevas”(pl.fem)。你有案件,请参阅masterrussian.com/aa071600a.shtml。和更多。所以,就这样吧!
    猜你喜欢
    • 2016-06-30
    • 2013-04-01
    • 1970-01-01
    • 1970-01-01
    • 2017-01-03
    • 1970-01-01
    • 2019-08-05
    • 2015-03-25
    • 2014-03-20
    相关资源
    最近更新 更多