Opened 9 years ago
Last modified 8 years ago
#26337 closed Cleanup/optimization
Translations - No fallback used if requesting english variant — at Version 1
Reported by: | Cristiano Coelho | Owned by: | nobody |
---|---|---|---|
Component: | Documentation | Version: | 1.9 |
Severity: | Normal | Keywords: | i18n translations english |
Cc: | cristianocca@…, Claude Paroz | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
This a new ticket raised by an issue noticed while reporting #26328.
The issue is exactly at this line https://github.com/django/django/blob/master/django/utils/translation/trans_real.py#L190
And it is currently done this way because django translations does not define values for english variants (see issue #24413 ) because message ids are enough, and such, if fallback language was to be used, all english translations from django would fail when the default language is not english resulting in incorrect translations all over the place.
Now the ticket above fixed the issue for django english translations, but actually creates a new issue (the one reported in this ticket).
The issue is then that if you are using an non english default language and expect it to be used when an english translation is requested (ie you don't have any english translation at all at your app or parts of it are missing), all your translated text will then fallback to the message id rather than the actual default language translation (which may be different than the message id).
How to fix this? Well, no idea! The best bet would be to make sure all translations values are always added rather than relying on message ids as defaults and remove the english check, but that would mean going through all translations for english variants implemented by django and django apps, plus there might be people relying on the same special english treatment.
Another fix that involves no code changes is to at least have it documented that you should have always a translation (and with values) file for english for all your apps otherwise you may get unexpected results when using non english as default.
The last idea but quite complicated, is to mark translation po files in a way that the compiler would then compile it setting the translation value the same as the message id and such the english check can be removed and django translations would still work (however django translation files should be marked)
Final note: This might not be really important, since most of the time if you are using translations, english will be one of them, and you will always have translation values if the default language is not the default, so this issue would not exist as long as this is always true.