[Django] #34602: Fail gettext when no translation file is found or when no msgid is found in the given translation file
Django
the given translation file
------------------------------------------------+------------------------
Reporter: Gergely Kalmár | Owner: nobody
Type: Uncategorized | Status: new
Component: Internationalization | Version: 4.2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------------+------------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/34602>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
the given translation file
Reporter: Gergely Kalmár | Owner: nobody
Component: | Version: 4.2
Internationalization |
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Natalia Bidart):
* status: new => closed
* resolution: => needsinfo
Comment:
Replying to [ticket:34602 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
[https://docs.djangoproject.com/en/stable/internals/contributing/bugs-and-
features/#requesting-features 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!
--
Ticket URL: <https://code.djangoproject.com/ticket/34602#comment:1>
Django
the given translation file
-------------------------------------+-------------------------------------
Reporter: Gergely Kalmár | Owner: nobody
Type: Uncategorized | Status: closed
Component: | Version: 4.2
Internationalization |
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/34602#comment:2>
Django
the given translation file
-------------------------------------+-------------------------------------
Reporter: Gergely Kalmár | Owner: nobody
Type: Uncategorized | Status: closed
Component: | Version: 4.2
Internationalization |
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/34602#comment:3>