[Django] #35306: Localisation of dates very confusing - why can't it be turned off anymore?

[Django]

#35306: Localisation of dates very confusing - why can't it be turned off anymore?
-------------------------------------+-------------------------------------
Reporter: | Owner: nobody
richardthegit |
Type: Bug | Status: new
Component: | Version: 5.0
Internationalization | Keywords: LANGUAGE_CODE,
Severity: Normal | DATE_FORMAT
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
The doc:

https://docs.djangoproject.com/en/5.0/ref/settings/#language-code

specifically states:

"USE_I18N must be active for this setting to have any effect."

This is not true. If `USE_I18N` is `False` and a language can not be
determined (e.g. the locale middleware is not active), the `date` template
filter will use the value of `LANGUAGE_CODE`.

I think the handling of date formatting is now very confusing, and the doc
for `DATE_FORMAT`, `DATETIME_FORMAT`, etc is at best incomplete because
it's very difficult to understand when (if ever) these settings are
actually used now that the `USE_L10N` setting has been fully deprecated.

I'm not raising this as a doc issue because I think this system is now
somewhat broken. Personally I think that `USE_L10N` should be brought
back; there needs to be a way to turn off localisation of dates (and
numbers) separately to translations - they're not the same thing.

I know I can force a particular locale to be used via `LANGUAGE_CODE`, but
I specifically want my format to be used, and the existing `DATE_FORMAT`,
etc settings seems like the right way to do that. I just need a way to
force their use, which used to be simply setting `USE_L10N = True`.
--
Ticket URL: <https://code.djangoproject.com/ticket/35306>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#35306: Localisation of dates very confusing - why can't it be turned off anymore?
-------------------------------------+-------------------------------------

Reporter: Richard | Owner: nobody

Type: Bug | Status: new
Component: | Version: 5.0
Internationalization |

Severity: Normal | Resolution:
Keywords: LANGUAGE_CODE, | Triage Stage:
DATE_FORMAT | Unreviewed
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Michael):

I agree and also miss the `USE_L10N` setting. Removing it feels like a
large tech company that believes they know better than you, and force
various changes without asking you to opt in. Unlike linux where it's the
same, unless you wish to opt in.

Anyways if `USE_L10N` is never coming back, we need to deprecate it
properly, its still lurking in the code base, grepping to see where its
used, with Django 5.0.3 shows:

{{{
utils/cache.py|340 col 17| if settings.USE_I18N:
utils/cache.py|420 col 49| is_accept_language_redundant =
settings.USE_I18N
utils/translation/trans_null.py|3 col 12| # settings.USE_I18N = False can
use this module rather than trans_real.py.
utils/translation/reloader.py|13 col 17| if settings.USE_I18N:
utils/translation/__init__.py|43 col 12| # settings.USE_I18N, as late as
possible, so that modules can be imported
utils/translation/__init__.py|54 col 5| USE_I18N will have no effect to
which function is served upon request. If
utils/translation/__init__.py|55 col 33| your tests rely on changing
USE_I18N, you can delete all the functions
utils/translation/__init__.py|66 col 21| if settings.USE_I18N:
conf/global_settings.py|158 col 1| USE_I18N = True
conf/project_template/project_name/settings.py-tpl|110 col 1| USE_I18N =
True
conf/urls/i18n.py|13 col 21| if not settings.USE_I18N:
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/35306#comment:1>

[Django]

#35306: Localisation of dates very confusing - why can't it be turned off anymore?
-------------------------------------+-------------------------------------
Reporter: Richard | Owner: nobody
Type: Bug | Status: new
Component: | Version: 5.0
Internationalization |
Severity: Normal | Resolution:
Keywords: LANGUAGE_CODE, | Triage Stage:
DATE_FORMAT | 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 for your comment Michael, though it seems that your may be
mixing `USE_L10N` with `USE_I18N`?
--
Ticket URL: <https://code.djangoproject.com/ticket/35306#comment:2>

[Django]

#35306: Localisation of dates very confusing - why can't it be turned off anymore?
-------------------------------------+-------------------------------------
Reporter: Richard | Owner: nobody
Type: Bug | Status: new
Component: | Version: 5.0
Internationalization |
Severity: Normal | Resolution:
Keywords: LANGUAGE_CODE, | Triage Stage:
DATE_FORMAT | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Natalia Bidart):

Hello Richard, thank you for your report. I've been debugging your issue
for a few days now. I think we may need to make some docs adjustments as
you imply, but I do not think the code is broken. See as a references
[https://stackoverflow.com/questions/77654801/use-l10n-deprecated-but-it-
disables-datetime-input-formats-when-removed this post in stackoverflow].

Have you tried using the `formats.py` approach to solve your need?
--
Ticket URL: <https://code.djangoproject.com/ticket/35306#comment:3>

[Django]

#35306: Localisation of dates very confusing - why can't it be turned off anymore?
-------------------------------------+-------------------------------------
Reporter: Richard | Owner: nobody
Type: Bug | Status: new
Component: | Version: 5.0
Internationalization |
Severity: Normal | Resolution:
Keywords: LANGUAGE_CODE, | Triage Stage:
DATE_FORMAT | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Michael):

Replying to [comment:2 Natalia Bidart]:

> Thank you for your comment Michael, though it seems that your may be
mixing `USE_L10N` with `USE_I18N`?

Hi Natalia, oh apologies, thank you for clearing that up, cheers!
--
Ticket URL: <https://code.djangoproject.com/ticket/35306#comment:4>

[Django]

#35306: Localisation of dates very confusing - why can't it be turned off anymore?
-------------------------------------+-------------------------------------
Reporter: Richard | Owner: nobody
Type: Bug | Status: new
Component: | Version: 5.0
Internationalization |
Severity: Normal | Resolution:
Keywords: LANGUAGE_CODE, | Triage Stage:
DATE_FORMAT | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Richard):

Replying to [comment:3 Natalia Bidart]:

> Have you tried using the `formats.py` approach to solve your need?

Hi Natalia - I've just tried this and it has worked - thanks! I guess
you're right and this can be solved with doc updates.

Personally I would still like the option to just turn this off, i.e.
reinstate USE_L10N. You can turn translation off so why not allow
localisation to be turned off too? I really don't understand the rationale
for removing this setting in the first place.

Best wishes.
--
Ticket URL: <https://code.djangoproject.com/ticket/35306#comment:5>

[Django]

#35306: Localisation of dates very confusing - why can't it be turned off anymore?
-------------------------------------+-------------------------------------
Reporter: Richard | Owner: nobody
Type: Bug | Status: new
Component: | Version: 5.0
Internationalization |
Severity: Normal | Resolution:
Keywords: LANGUAGE_CODE, | Triage Stage:
DATE_FORMAT | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Natalia Bidart):

* cc: Claude Paroz (added)

Comment:

(Adding Claude as cc.) Claude, do you have any pointers on how to make use
of the `DATE_FORMAT` and related settings? Specifically, how to have them
honored in templates.
As an example, I tried using the `date` template tag, and the settings
seem ignored, having the format from LANGUAGE_CODE taking precedence. I
know this is mentioned in the docs:

> Note that the corresponding locale-dictated format has higher precedence
and will be applied instead.

But since LANGUAGE_CODE can not be unset (afaik), it seems unclear when
the `DATE_FORMAT` and related settings are used (outside of the
`formats.py` approach). Just for clarity's sake, I don't think there is a
bug in Django, I think we could add some clarifications to the docs to be
more explicit about this particular usage.

(Another data point: even using `{% localize off %}` does not honor the
settings values. This feels unexpected to me...)
--
Ticket URL: <https://code.djangoproject.com/ticket/35306#comment:6>