python-babel / flask-babel

i18n and l10n support for Flask based on Babel and pytz
https://python-babel.github.io/flask-babel/
Other
432 stars 159 forks source link

Translations not happening in production on Heroku/gunicorn #185

Closed robcowen closed 1 year ago

robcowen commented 3 years ago

I have flask-babel running correctly on my development localhost (on Windows), but the translations do not happen on the production app (gunicorn on Heroku).

I've detailed the issue more fully in this unresolved StackOverflow post.

kingkong-cmd commented 2 years ago

I believe this is due to Heroku having “ephemeral” storage, meaning that you can perform the compilation and create the files, but those files will not persist. You should therefore compile your files locally and upload them to Heroku as you would normally with your "git commit heroku".

robcowen commented 2 years ago

I believe this is due to Heroku having “ephemeral” storage, meaning that you can perform the compilation and create the files, but those files will not persist. You should therefore compile your files locally and upload them to Heroku as you would normally with your "git commit heroku".

Thank you for replying to this. It's been quite a while since I last tried to tackle this, so my memory is sketchy. What files should I be compiling locally and uploading? The messages.mo and messages.po files are both compiled locally and included in the git commits.

thilojaeggi commented 1 year ago

While I'm not using heroku I'm also using gunicorn within a Docker image on Google Cloud run and facing the same issue. No error messages either. Could this be an issue with gunicorn itself?

TkTech commented 1 year ago

This is almost always due to have incorrect paths to your translations.

thilojaeggi commented 1 year ago

I've tested multiple combinations. Putting the translations in the app folder or outside it doesn't matter. I also don't see any reason why it works locally but nt within a Docker container.

TkTech commented 1 year ago

Is your project public?

And there's many reasons it may not work in docker, like not having your working directory set properly.

TkTech commented 1 year ago

Closing until more information is provided. In general, this has always turned out to be a configuration issue.

robcowen commented 1 year ago

@TkTech I'm the OP on this and am having another attempt at getting this working, two years on. Both the messages.mo and messages.po files are being deployed to Heroku via git. In addition to this, I have followed some guidance on Miguel Gringberg's blog to include flask translate compile in the Procfile.

Using the code below, running both locally and on Heroku, I have verified that the translation language is set correctly in both places and that the contents of the messages.mo files are identical in both places:

print(app.config['BABEL_TRANSLATION_DIRECTORIES'])

f = open(app.config['BABEL_TRANSLATION_DIRECTORIES']+"/en_us/LC_MESSAGES/messages.mo", "rb")
print(f)
print(get_locale())
print(f.read()) 

I can't for the life of me figure out what I (and others with the same issue) are doing wrong here.

Edit: I should add, I am using v2.0.0 (which was the latest when I raised this issue). I am upgrading now to 3.0.0 and will update when tested.

Edit 2: Upgraded to v3.0.0 and the problem persists. :(

thilojaeggi commented 1 year ago

Just wanted to come back here to state that my issue has since been resolved. For some reason in my .gitignore the po files were ignored, I'm assuming because the creator of the .gitignore that I used wants me to compile the files during the creation of the Docker container (Which kind of makes sense).

robcowen commented 1 year ago

I have finally figured this out. The issue for me is related to case sensitive paths. Windows paths are case insensitive, whereas Linux are case sensitive.

The translations path had been en_us/LC_MESSAGES/messages.mo but the locale was set to en_US. On Windows, this was not a problem and Babel was able to load the file. Remotely on Heroku, it was presumably quietly failing to find the file.

After deleting the directory from the repository, then pushing it again as en_US/LC_MESSAGES/messages.mo, the problem is resolved.