Fail gettext when no translation file is found or when no msgid is found in the given translation file

[Gergely Kalmár]

Currently gettext simply falls back to inserting its argument when there is no appropriate translation file or when the translation file does not contain an appropriate msgid. This can lead to untranslated messages appearing when developers change a text but forget to run makemessages (or extract/update their translation files when using Babel).

For this reason it would be preferable if we had the option to fail gettext and its variants instead of using a fallback. The only exception is if the current language is the same as the LANGUAGE_CODE setting, in which case it should be fine to display the argument of gettext as a fallback.

[Natalia Bidart]

Replying to Gergely Kalmár:

Currently gettext simply falls back to inserting its argument when there is no appropriate translation file or when the translation file does not contain an appropriate msgid.

Could you please expand this explanation a bit? I'm not completely sure what you mean. If you could provide concrete examples, commands run, etc, that will certainly help us triage this ticket report.

For this reason it would be preferable if we had the option to fail gettext and its variants instead of using a fallback. The only exception is if the current language is the same as the LANGUAGE_CODE setting, in which case it should be fine to display the argument of gettext as a fallback.

Where would this option be added? as a setting? what would the failure look like?

Without a complete understanding of this report, it may look like this is a new feature request? If so, would you mind following ​the documented guidelines for requesting features?

If this is not a feature request, could you provide a minimal django app and instructions to reproduce the issue? Closing as needsinfo until we get a clearer understanding of the report.

Thank you!

[Gergely Kalmár]

Sure, the case is very simple. Create a view like the one in the documentation (see ​https://docs.djangoproject.com/en/4.2/topics/i18n/translation/#standard-translation):

from django.http import HttpResponse
from django.utils.translation import gettext as _


def my_view(request):
    output = _("Welcome to my site.")
    return HttpResponse(output)

Make sure that you use more than one language (e.g. set LANGUAGES = [('en', 'English'), ('de', 'German')]) and configure translations like described in the documentation. Note that even if you display the view with the German language, you will see "Welcome to my site." and will not receive any error or warning about the fact that the German translation file doesn't even exist yet.

Then create a translation catalog file and translate the sentence. Notice that the translated sentence appears now properly. Now change the output line to output = _("Welcome to my updated site."). Notice how the translated sentence turns back into English even when using German as a language and you don't get any warning or error again.

I'd much prefer if we received an exception (or at least a warning) in both cases. I understand that this would be a backwards-incompatible change, which is why I suggested to perhaps use a setting to control this (e.g. RAISE_TRANSLATION_ERRORS). Currently the translation system is really error-prone, it is totally possible for a developer to change a text in a view or a template and forget to update the translation files and thus break translation for the end users.

[Natalia Bidart]

Thank you Gergely for the clarification!

Your request definitely qualifies as a new feature, so I would suggest that you follow the link I mentioned above to propose new features in the Django Forum.

For what is worth, what we did at my previous job was having a task in our CI that would run makemessages before merging any PR and if there are new messages, the landing would be aborted for the author to follow a specific procedure for new strings needing translations.