Re: Deploying Django under a sub-path
I found https://code.djangoproject.com/ticket/7930 seems like `FORCE_SCRIPT_NAME` just isn't meant to work. Maybe the docs should reflect that. Arthur Pemberton On Fri, Jun 16, 2023 at 5:18 PM Arthur Pemberton wrote: > Even with `FORCE_SCRIPT_NAME` `MEDIA_URL` is being prefixed properly, but > not `STATIC_URL` . > > Was `FORCE_SCRIPT_NAME` just not meant to be used with the `runserver` ? > > Arthur Pemberton > > On Fri, Jun 16, 2023 at 5:01 PM Arthur Pemberton > wrote: > >> The docs reference `FORCE_SCRIPT_NAME` but say very little of how to use >> it. >> >> Reading through the code, I see very little use of `SCRIPT_NAME` itself, >> however as far as I can tell, use of `SCRIPT_NAME` is supposed to be how >> one deploys Django at a sub-path. >> >> I had to modify wsgi.py per >> https://ruddra.com/deploy-django-subpath-openshift/ to get things to >> work. >> >> Shouldn't this be a complete feature? >> >> I've re-checked https://docs.djangoproject.com/en/4.2/howto/deployment/ >> and there's no information on the topic (that I could find). >> >> Arthur Pemberton >> > -- 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/CA%2BX4dQSQDcaApgWFmEE8MRERKbdHBBPh4KXa12pTi9FHO7zx1g%40mail.gmail.com.
Re: Deploying Django under a sub-path
Even with `FORCE_SCRIPT_NAME` `MEDIA_URL` is being prefixed properly, but not `STATIC_URL` . Was `FORCE_SCRIPT_NAME` just not meant to be used with the `runserver` ? Arthur Pemberton On Fri, Jun 16, 2023 at 5:01 PM Arthur Pemberton wrote: > The docs reference `FORCE_SCRIPT_NAME` but say very little of how to use > it. > > Reading through the code, I see very little use of `SCRIPT_NAME` itself, > however as far as I can tell, use of `SCRIPT_NAME` is supposed to be how > one deploys Django at a sub-path. > > I had to modify wsgi.py per > https://ruddra.com/deploy-django-subpath-openshift/ to get things to work. > > Shouldn't this be a complete feature? > > I've re-checked https://docs.djangoproject.com/en/4.2/howto/deployment/ > and there's no information on the topic (that I could find). > > Arthur Pemberton > -- 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/CA%2BX4dQRYbJ4NnKD89ptsJHGx2EUxO4vqZH0oepHVAN%2Bf%3D7S_Ag%40mail.gmail.com.
Deploying Django under a sub-path
The docs reference `FORCE_SCRIPT_NAME` but say very little of how to use it. Reading through the code, I see very little use of `SCRIPT_NAME` itself, however as far as I can tell, use of `SCRIPT_NAME` is supposed to be how one deploys Django at a sub-path. I had to modify wsgi.py per https://ruddra.com/deploy-django-subpath-openshift/ to get things to work. Shouldn't this be a complete feature? I've re-checked https://docs.djangoproject.com/en/4.2/howto/deployment/ and there's no information on the topic (that I could find). Arthur Pemberton -- 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/CA%2BX4dQRiRkPKQVik9aRQ1z07-j_jOVK9fHQAtt2r_v%3Dajrd0uQ%40mail.gmail.com.
Re: Feature request: making gettext more robust
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 אורי 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 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 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 >
Re: Feature request: making gettext more robust
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 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 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 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/CABD5YeGSHmg%2B5O4ZSNkmyNschH9Ba52GHa2bs4oY8mG_%2ByiAHw%40mail.gmail.com.
RE: Feature request: making gettext more robust
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 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 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.
Re: Feature request: making gettext more robust
> On 15 Jun 2023, at 16:15, Tobias Kunze 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.
