i18n 在 heroku 的生产环境中不起作用答案

【问题标题】：i18n doesn't work at production environment on herokui18n 在 heroku 的生产环境中不起作用
【发布时间】：2012-10-26 03:23:07
【问题描述】：

我已经看过一百多篇关于 i18n 问题的帖子，但似乎没有任何解决方案可以解决我的问题。

我有一个运行 Django 1.3.1 的应用程序，它在我的开发机器上运行良好。但是当我带到 heroku 时，什么也没有发生。这些文件根本没有翻译。我的项目中似乎找不到 locale 文件夹。

Locale 文件夹位于我的项目级别，这是我的设置：

BASE_PATH = os.path.dirname(os.path.abspath(__file__))

LANGUAGE_CODE = 'pt-br'

USE_I18N = True

USE_L10N = True

ugettext = lambda s: s
LANGUAGES = (
    ('en-us', ugettext('English')),
    ('pt-br', ugettext('Portuguese')),
)

LOCALE_PATHS = (
       os.path.join(BASE_PATH, "locale"),
)

Locale 文件夹遵循以下结构：

locale
    pt_BR
        LC_MESAGES
            django.mo
            django.po

【问题讨论】：

你可以使用一个迷你中间件来快速设置你选择的语言，我做到了，证明我的文件没问题，而且是别的东西：language middleware
我取消了英语，只设置了葡萄牙语。我的整个应用程序都是英文的，但 Django Administration 运行良好！
Django 文档说，如果我只使用我的母语并将其设置为 LANGUAGE_CODE，则不需要中间件。那么，这不是证明文件没有被找到吗？另外，我检查了服务器，文件在那里。

标签： django heroku internationalization

【解决方案1】：

我发现不同的平台喜欢不同的语言文件夹名称。我在我的开发系统（Mac OS X）上大发雷霆，因为 '/pt-br/LC_MESSAGES/' 不起作用，即使 makemessages 以这种方式创建文件夹并且编译消息也可以正常工作。当我将语言重命名为“/pt_br/LC_MESSAGES/”（注意下划线）后，它终于焕然一新。

将同一个项目迁移到生产（Ubuntu），它再次停止工作，我在 Sun 下尝试了一切，认为文件夹名称必须已经正确，因为它们在我的开发中工作。机器。最后，出于绝望，我尝试将“/pt_BR/LC_MESSAGES/”之类的国家组件大写，然后，它又开始工作了。

即使我认为我的 Python 和 Django 以及我所有的各种 Python/Django 库和应用程序都是（按设计）相同的版本，我怀疑每个系统在它们下面都有不同的 gettext 版本/构建，这可能是造成差异的原因.

【讨论】：

谢谢老兄，这救了我的命！
如果你在 2018 年还在为这个而奋斗（特别是 zh_Hans / zh_Hant），还有更多。如果您在 mac 上开发（不区分大小写），一切都会正常工作。一旦你在我的例子 Heroku / docker running linux 的其他地方部署它），如果你的路径被命名为 zh_Hans 或它的任何变体，将找不到翻译。确保使用 zh_hans/zh_hant 作为文件夹名称。您可能需要使用 git mv 以便获取更改；）

【解决方案2】：

默认情况下，编译的翻译文件 (*.mo) 会被 git 忽略。确认您已从 .gitignore 文件中删除了此异常。

如果是这种情况，请删除此异常，将这些文件添加到 git，提交并推送到 Heroku 以使它们可用于 Heroku 中的应用程序。

【讨论】：

.mo 文件不是源文件。它们不应该是存储库的一部分。
那么有什么替代方案呢？是否应该在服务器端编译？
@JOANNM：你在 git 中拥有什么是你的决定。因此，如果您使用 git push/pull 部署一些简单的 Web，请从 .gitignore 中删除 .mo。或者您可以使用不同的部署工具。或者您可以在生产中使用compilemessages，但我认为这不是一个好主意。

【解决方案3】：

在上面的示例中，您写的是 LC_MESAGES 而不是 LC_MESSAGES（注意双 S），我相信这很可能是您的问题。

如果没有，请继续阅读！

我最近遇到了这个问题（又一次！），答案在this part of the django documentation中找到

我怀疑你有同样的问题，因为你的“管理”应用程序被翻译了，但不是你自己的（项目）应用程序。

似乎 Django 正在像这样寻找您的翻译：

LOCALE_PATHS 中列出的目录具有最高优先级，首先出现的优先级高于稍后出现。

然后，它查找并使用是否存在语言环境 INSTALLED_APPS 中列出的每个已安装应用程序中的目录。这首先出现的优先级高于出现的优先级稍后。

最后，Django 提供的基础翻译在 django/conf/locale 用作后备。

使用您上面描述的设置，您必须确保您的树看起来像这样（最重要的是 settings.py 位于“locale”目录上方的目录中）：

+-project_top/
  |
  +-project_app/
  | |
  | +-locale/
  | | |
  | | +-pt_BR/
  | |   |
  | |   +-LC_MESSAGES/
  | |     |
  | |     +-django.po
  | |  
  | +-settings.py
  |
  +-manage.py

【讨论】：

在我的情况下，解决方案是 最重要的是 settings.py 位于 'locale' 目录上方的目录中，并将其路径添加到 LOCALE_PATHS。这是我能够在 Heroku 上工作的唯一配置。不知道其他服务器是不是也一样。

【解决方案4】：

首先，你的语言设置有误。

应该是这样的：

LANGUAGES = (
    ('zh', 'China'),
    ('en', 'English'),
    ('ja', 'Japanese'),
)

接下来，检查 cookie 设置中的域是否正确。

我遇到了同样的问题，以为 Heroku 的虚拟环境永远不会支持 i18n，但最后发现我的会话 cookie 中的 'django-language' 值属于我的本地测试服务器 '0.0.0.0:5000'。

更改设置后，我在本地服务器上完成的翻译开箱即用。

【讨论】：

'zh' 不被接受为语言代码。您需要使用 'zh-cn' 或此处列出的其他别名：github.com/django/django/blob/master/django/conf/…

【解决方案5】：

我想突出显示上面@msaad 的评论。如果您在 Mac OS X 上开发并且您的翻译目录都是小写的，那么将其从 es_es -> es_ES 更改并重新部署。这为我解决了这个问题。在 OS X 上，系统不区分大小写，但在 linux 系统上则不区分大小写。

【讨论】：

【解决方案6】：

在某些情况下，名称中带有“-”或“_”的目录未正确寻址。我解决了将 url 自定义为 2 字符代码的问题。这可以通过创建别名来完成：

from django.conf import global_settings, locale
EXTRA_LANG_INFO = {
    'pt': {
        'fallback': ['pt-br'],
    },
}
LANG_INFO = dict(locale.LANG_INFO, **EXTRA_LANG_INFO)
locale.LANG_INFO = LANG_INFO

【讨论】：

【解决方案7】：

我不回答与 Heroku 相关的问题，只是为了收集大多数可能性：

我有 Debian 10 开发和 Debian 10 虚拟服务器在生产中。开发中一切正常，i18n 生产失败。

原因：我需要 apt install gettext。

此外，请确保 .mo 文件在 git 中并且没有被 .gitignore 禁用（这个答案已经在这里），

【讨论】：