2
votes

For the Django project I am working on I created a translation named en-ORGNAME that reflects the specific English jargon at use at the target organization. I use multiple instances of this application for multiple organizations and want to be able to customize the jargon according to the client organization.

It started of pretty nice, after running django makemessages -l en_ORGNAME I ended up with a .po file that I could translate. Running compilemessages made sure I have to .mo file as well.

The application only uses the LANGUAGE_CODE setting to determine language (no context processor or URLs). The locale path is set to

LOCALE_PATHS = (
    os.path.join(BASE_DIR, 'locale'),)

When I run the application (using docker-compose and the development server) all works well and my translations show up as expected. However, when I deploy the application (using the same docker image) using Rancher the custom translation stops working. I have used an environment variable to set the language at container level and all other languages work fine.

I have tested the same stack in development (NGINX, Gunicorn, Django) and my custom translation works. I have tried adding the custom translation to the django.conf.locale dictionary (as per Add custom language for localization in Django app). Made no difference what so ever. With or without the adjusted locale dictionary the custom translations work on development but don't work on production.

Any ideas are more than welcome.

1
Can you verify in your production container that the *.mo files generated by compilemessages are indeed present and accessible (file permissions). At which point are you running compilemessages (in docker-entrypoint.sh e.g.?). Can you make it so that there is more verbose output from compilemessages during startup so that you can verify that it is indeed generating the files as expected.Risadinha
Hi @Risadinha, in order to make sure the files get compiled on the server I have added the compilemessages command to the entrypoint script. I can verify the .mo files exist on the server and I can inspect the startup log of the container to make sure the message files are compiled. No success so far. I noticed that another translation nl-NL in which I made an entry for testing purposes works fine on both development AND production. Still puzzels me how there can be a difference while I am using docker in both dev and prod.Bart
If you have access to the Django shell inside your container, you could test the language selection there. Select your custom language explicitly and check that a known text indeed gets translated correctly. If this is the case then this might indicate that the Django in your container does not select the correct language. If it does not translate correctly you would have to find out why it falls back to a different language.Risadinha
@Risadinha thanks a lot for your help. I have tried to load the translations explicitly using the shell. I can see that for other languages this works but for my custom language it does not. It seems that the custom translation falls back to 'en'. I am really starting to think that for some reason it does not accept a custom variant for the organization on production (e.g. en-ORG). I do not want to mess with Django's own files (they are and should be out of my control).Bart

1 Answers

2
votes

After thorough analysis and discussion with my dear friend and colleague @sandertuit we found that en-ORG is simply too many characters. The language variant extension can only have 2 characters according to standard formatting, so I now use en-OR. Everything works fine now. Why it did work on development still puzzels me. Also many thanks to @Risadinha for your help.