I like the idea of having a management command for checking whether the translations are up-to-date. I know that many people use workarounds in their CI which essentially does that (like re-extracting messages and comparing it with existing files). Note that I already developed a pytest check for myself that captures missing translations and outdated compiled files (see https://github.com/logikal-io/pytest-logikal/blob/main/pytest_logikal/translations.py), so I'm only really missing a check for outdated extractions.
Now, the only challenge is that I usually use Babel for managing translation files, so I'm not sure if a management command that builds on top of Django's makemessages would be all that useful. I'm still thinking that it should be possible for Django to wrap gettext in a way that allows us to raise exceptions. It seems silly to me that we could not control this core aspect of the process. On Fri, Jun 16, 2023 at 4:13 PM אורי <u...@speedy.net> wrote: > Hi, > > There is a command to check which texts are not translated. If my code is > under directory speedy, I can run this command to see all the texts which > are not translated, not including English (because English can use the > default): > > for k in speedy/*/locale/*/LC_MESSAGES/django.po; do echo $(msgattrib > --untranslated $k | fgrep msgstr | wc -l) $k; done | grep -v '^0 ' | fgrep > -v "/locale/en/LC_MESSAGES/django.po" | sort -nr > > And this is with English included: > for k in speedy/*/locale/*/LC_MESSAGES/django.po; do echo $(msgattrib > --untranslated $k | fgrep msgstr | wc -l) $k; done | grep -v '^0 ' | sort > -nr > > Thanks, > Uri. > אורי > u...@speedy.net > > > On Fri, Jun 16, 2023 at 3:55 PM Matthew Pava <matthew.p...@iss.com> wrote: > >> I personally like the current behavior. If I don't have a translation >> prepared for a certain text, I want it to fall back on the default text. >> Saying that, how about Django incorporate a management command of some sort >> that can be used to examine the translation files and return the texts that >> are not translated? >> >> -----Original Message----- >> From: django-developers@googlegroups.com < >> django-developers@googlegroups.com> On Behalf Of Michiel Beijen >> Sent: Friday, June 16, 2023 1:44 AM >> To: django-developers@googlegroups.com >> Subject: Re: Feature request: making gettext more robust >> >> > On 15 Jun 2023, at 16:15, Tobias Kunze <r...@cutebit.de> wrote: >> > >> > On 23-06-15 04:29:59, Gergely Kalmár wrote: >> >> It seems that gettext is currently quite permissive – it falls back >> >> to the default language whenever a translation file is missing or if >> >> the requested message ID is missing from the translation file. This >> >> can lead to errors slipping through easily. >> >> >> >> I think it would be great if there was a way to make gettext raise an >> >> error when the translation file is missing or when the msgid is >> missing. >> > >> > Agreed that this is annoying behaviour, but as far as I can tell, >> > there's not much that Django can do. IIRC we only wrap Python's gettext >> module¹. >> > >> > The relevant method, GNUTranslations.gettext, returns the original >> > message if no translation has been found, and it does so without >> > indicating that this is a fallback response². >> > >> > AIUI this behaviour is rooted in GNU's gettext, which (just like the >> > Python >> > version) allows you to set a priority list of languages to fall back >> to³. >> >> In ‘runtime’ indeed it is difficult to get a warning for an untranslated >> string; the best way to go about it is to generate the translation file and >> check for untranslated string in your translation file via some automated >> check such as a Github Action. >> >> The added benefit this has is that if there is a translation string >> hiding in a lesser used part of your app such as the password reset form or >> so, it will still be spotted by the translation file generation, whereas >> you might otherwise miss this if you’re just clicking around in the app. >> >> — >> Michiel >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/4FE0664B-5E88-460C-826F-F0A85FC09D5B%40x14.nl >> . >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/DS7PR15MB59105F07249DA9F12BC11F098258A%40DS7PR15MB5910.namprd15.prod.outlook.com >> . >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/ACiRPy-TN_U/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CABD5YeGSHmg%2B5O4ZSNkmyNschH9Ba52GHa2bs4oY8mG_%2ByiAHw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CABD5YeGSHmg%2B5O4ZSNkmyNschH9Ba52GHa2bs4oY8mG_%2ByiAHw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFoHBO3BRi3sXJp-S1%2BYMFyoKrGr2CMxd2EhDFCAUaRkvw_ocQ%40mail.gmail.com.
