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
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
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
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
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
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
> 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
