Heroku部署Django应用时翻译功能生产环境失效问题咨询

核心问题梳理 #

本地环境静态文本翻译正常，部署到Heroku后失效；已配置app.json和Procfile的release脚本编译消息，添加了gettext buildpack，但目标locale/fr/LC_MESSAGES目录下未生成.mo文件，怀疑自动化编译脚本未正常执行。

问题解答 #

1. 是否只需从.gitignore中移除.mo即可解决问题？ #

直接移除.gitignore中的.mo规则，将本地编译好的.mo文件提交到Git仓库，确实能快速解决问题——Heroku部署时会直接使用仓库内的文件，无需在服务器端编译。但这种方式存在明显弊端：

• 每次更新.po翻译文件后，必须手动在本地执行python manage.py compilemessages，再提交.mo文件，流程繁琐易遗漏；
• .mo是二进制编译产物，提交到仓库会增加仓库体积，且Git对二进制文件的版本追踪远不如文本文件友好。

若项目规模小、翻译更新频率低，这种方法可临时救急，但绝非最优实践。

2. 是否应继续当前路径，寻找不移除.mo的解决方案？ #

建议坚持自动化编译的路线，这是更规范的工程化做法。当前问题的核心是compilemessages脚本未正确执行，可从以下方向排查：

• 清理重复配置：Heroku的release阶段脚本只需在Procfile或app.json中定义其一，无需重复配置。建议保留Procfile中的release指令，避免冲突导致脚本不触发；
• 调整buildpack顺序：确保gettext buildpack优先级高于Python buildpack——编译messages依赖gettext工具，必须先完成安装。可通过以下命令检查和调整：

  # 查看当前buildpack顺序
  heroku buildpacks
  # 将gettext buildpack移到第一位
  heroku buildpacks:add --index 1 https://github.com/heroku/heroku-buildpack-gettext.git
  

• 查看release阶段日志：通过heroku logs --release命令查看脚本执行日志，排查是否存在报错（如locale目录找不到、权限问题、gettext未安装等）；
• 指定编译参数：若locale目录不在默认路径，执行compilemessages时需明确指定参数，比如针对法语编译：

  python manage.py compilemessages -l fr
  

• 临时验证编译逻辑：可临时修改Procfile，在web服务启动前强制编译messages（仅用于验证，不建议长期使用）：

  web: python manage.py compilemessages && daphne mysite.asgi:application --port $PORT --bind 0.0.0.0 -v2
  

总结 #

若追求快速修复，移除.gitignore中的.mo并提交文件是可行方案；但从长期维护角度，建议排查自动化编译的问题，保留.gitignore规则，通过Heroku release阶段自动生成.mo文件，这更符合Django的最佳实践。

内容的提问来源于stack exchange，提问作者PhilM