gettext 翻译不适用于生产系统
我在使用 django 的 gettext 翻译字符串（在管理中）时遇到了一个奇怪的问题：本地运行开发服务器，所有翻译都在管理中正确显示，但是当项目部署在生产服务器上时一些字符串根本没有被翻译。我无法确定哪些系统背后的字符串受到影响，哪些不受影响！
给你一个印象，例如。模型的定义如下：
class Company(models.Model):
....
class Meta:
verbose_name = _('Company Profile')
verbose_name_plural = _('Company Profiles')
使用开发服务器，模型的名称在管理中以不同语言正确显示，但在生产服务器上则不然！这会影响某些模型，而其他模型则不会...这让我非常抓狂，因为我几乎不知道如何调试它...
I've encountered a strange problem when translating strings (in the admin) using django's gettext: Locally running the dev server all translations are displayed correctly in the admin, but when the project is deployed on the production server some strings are not translated at all. I cannot determine any system behind which strings are affected and which not!
To give you an impression, eg. a model is defined like:
class Company(models.Model):
....
class Meta:
verbose_name = _('Company Profile')
verbose_name_plural = _('Company Profiles')
Using dev server the model's name shows up correctly in different languages in the admin, on the production server not! This affects some models, others not... This is driving me really nuts, since I hardly have a idea on how to debug this...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
一些可能性：
模糊ugettext而不是ugettext_lazyA few possibilities:
fuzzyugettextinstead ofugettext_lazy我遇到了类似的问题，除了 Tomasz Zielinski 指出的之外，我还必须进行以下更改：
在 settings.py 中
记住尾随斜杠并确保目录结构如下所示：
I had a similar problem and apart from what Tomasz Zielinski pointed out I had to make the following changes:
in settings.py
Remember the trailing slash and make sure that the directory structure looks something like:
如果您在 Windows 上进行开发并且生产实例是 Linux，那么问题可能是：在文件路径命名方面，Windows 不区分大小写，而 Linux 区分大小写。
例如，区域设置文件夹名称应为：
zh_Hans而不是zh_hanspt_BR而不是pt_brIf you are developing on Windows and the production instance is Linux, then the problem might be: Windows is not case sensitive while Linux is case sensitive, in terms of naming of file paths.
For example, a locale folder name should be:
zh_Hansinstead ofzh_hanspt_BRinstead ofpt_br