I18n似乎不能工作，而模型转换可以(一点点)

Question

我需要在我的项目中实现国际化，所以我想对静态内容使用i18n，而对模型使用django-modeltranslation应用程序。我支持以下语言：

en-us (默认) nl-nl de-de fr-fr es-es

虽然我是荷兰人，但django不会将语言更改为荷兰语。我有一个英文的windows，但是chrome是用荷兰语设置的，用来测试国际化。这不是唯一的问题，只有模型在默认语言更改时会自动转换。当我将默认语言设置为荷兰语时，所有模型都将显示荷兰语翻译，但静态内容仍为英语。

注意:我确实使用了编译消息并重新启动了服务器

Settings.py

USE_I18N = True

LANGUAGE_CODE = 'en-us'

gettext = lambda s: s
LANGUAGES = (
    ('en-us', gettext('English')),
    ('nl-nl', gettext('Dutch')),
    ('fr-fr', gettext('French')),
    ('de-de', gettext('German')),
    ('es-es', gettext('Spain')),
)

LOCALE_PATHS = ('/vagrant/locale', )

/vagrant/locale/en-us/LC_MESSAGES/django.po (为显示错误而缩短的文件)

# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2013-05-17 23:14+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Language: en-us\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: PyDiving/settings.py:170
msgid "English"
msgstr ""

#: PyDiving/settings.py:171
msgid "Dutch"
msgstr ""

#: PyDiving/settings.py:172
msgid "French"
msgstr ""

#: PyDiving/settings.py:173
msgid "German"
msgstr ""

#: PyDiving/settings.py:174
msgid "Spain"
msgstr ""

#: company/templates/company/company_detail.html:22
msgid "City"
msgstr ""

/vagrant/locale/nl-nl/LC_MESSAGES/django.po (仅显示差异以缩短post)

"Language: nl-nl\n"

#: company/templates/company/company_detail.html:28
msgid "Postal Code"
msgstr "Postcode"

#: company/templates/company/company_detail.html:34
msgid "City"
msgstr "Stad"

模板公司/模板/公司/公司_详细.html

{% load i18n %}
{{ company.text }} # this is the model translation, this will change when i change the default language
{% trans "City" %} # this always says "City"

默认语言为en-us时的结果

EnglishCity

其中'English‘是模型的内容’

默认语言nl-nl

NederlandsCity

Answer 1

我偶然发现了这篇文章：Django internationalization language codes。显然，django只支持iso 639-1语言代码，这在文档中找不到，更糟糕的是，它说你必须使用像en-us这样的代码。一旦我将语言更改为en-us > en，nl-nl > nl等，它立即起作用。

不管怎样，谢谢你的关注。

Answer 2

我发现不同的平台允许/首选不同的语言文件夹名称。我在我的开发系统(Mac )上绞尽脑汁，因为'/pt-br/LC_ messages /‘不起作用，尽管makemessages以这种方式创建了文件夹，编译消息也很好。当我将语言重命名为'/pt_br/LC_MESSAGES/‘(注意下划线)时，它终于活跃了起来。注设置中的语言元组使用aa-bb形式，就像您在这里使用的一样。

将相同的项目迁移到生产环境(Ubuntu)，它再次停止工作，我尝试了Sun下的所有东西，我认为文件夹名称一定已经正确，因为它们在我的开发中起作用。机器。最后，我迫不及待地尝试上标country组件，比如“/pt_BR/LC_MESSAGES/”，然后，突然，它又开始工作了。我发现使用aa_BB表单可以在全球范围内工作。

因此，我认为您正在寻找的解决方案是更改locale文件夹中的locale目录的名称。你应该有：

[project]
    locale
        de_DE
        en_US
        es_ES
        fr_FR
        nl_NL
    ...
    settings.py

在每一个里面，你都会像平常一样拥有LC_MESSAGES等。您的Django配置不应该更改，这是gettext在您的平台上接受的配置。同样，我认为如果您使用aa_BB表单，在大多数系统上都会很好。

如果您出于某种原因需要将语言环境文件夹放在其他位置，只需确保相应地设置了属性settings.LOCALE_PATHS即可。此外，Django文档清楚地说明了如何找到这个文件夹：https://docs.djangoproject.com/en/dev/topics/i18n/translation/#how-django-discovers-translations。

Answer 3

我知道这个问题已经有一年多了，但我也遇到了类似的问题，经过几个小时的努力，我终于找到了一个确定性的答案。

免责声明:我使用pt-br是因为它是我的母语，但您可以将它派生为您想要的任何语言

首先，我在django应用程序上做了什么(假设您已经创建了项目和应用程序，当前目录是项目目录)：

django设置创建的语言环境目录：mkdir locale

• created a django locale：django-admin.py makemessages -l pt_BR

• changed将创建的file

• compiled all messages：django-admin.py compilemessages

• added中的文本设置为django

• ：LOCALE_PATHS =('/path/to/locale_foder',)

LOCALE_PATHS变量

从那以后，我的Django应用程序就再也没有翻译过了。不管我做了什么。

根据django文档(https://docs.djangoproject.com/en/dev/topics/i18n/translation/#how-django-discovers-language-preference)，django有一种预定义的方法来查找语言首选项，它的工作原理如下：

1. django搜索url中的语言前缀，为此，您必须在django url中使用i18n_patterns。
2. 如果上述操作失败，请在user session
3. 中搜索变量如果以上操作失败，则搜索一个url。如果以上操作失败，请使用Accept-Language HTTP HTTP url。

我突出显示了数字4，因为在我的例子中，这就是我正在使用的数字。这意味着我的应用程序依赖于HTTP浏览器数据。

现在，因为我们依赖于HTTP数据，所以让我们检查一下浏览器的行为。我主要使用chrome和firefox。我的chrome在我的笔记本上有以下语言设置：

• pt
• en-us
• en

这就是问题所在，我的Accept-Language HTTP头发送的是pt，但我没有pt locale，我只有pt-br locale。如果它是另一种方式，这是可行的。我的结论是，人们应该始终拥有iso 639-1代码，并从那里使用专门化。例如:我现在使用pt作为pt-br的默认值，使用pt-pt作为葡萄牙特定翻译的默认值。