Removal of USE_L10N setting

[Claude Paroz]

Hi,

I eventually took some time to try implementing an idea I had since some
time: remove the USE_L10N setting.
The draft PR is here:
https://github.com/django/django/pull/14519

My motivations are:
- one less setting
- simplication of the code and logic regarding USE_18N/USE_L10N/USE_TZ
settings
- a user-friendly default behavior

As usual, the main drawback is backwards compatibility. The possibly
affected projects are those having USE_L10N = False, along with multiple
LANGUAGES.

Is this a good idea?
I would also like to get opinions here about the compatibility issues.
Are they acceptable?
Is there a possible deprecation path?

Regards,

Claude
--
www.2xlibre.net

[René Fleschenberg]

Hi,

On 6/11/21 6:50 PM, Claude Paroz wrote:
> As usual, the main drawback is backwards compatibility. The possibly
> affected projects are those having USE_L10N = False, along with multiple
> LANGUAGES.
>
> Is this a good idea?
> I would also like to get opinions here about the compatibility issues.
> Are they acceptable?
> Is there a possible deprecation path?

I have run into bugs because template authors forgot to unlocalize
values, in particular database IDs. These bugs often go unnoticed for
quite a while because they only show up once you reach 1000 database
rows. Forgetting to localize a value would typically be a much more
obvious bug.

So far, I have always fixed these issues by adding the unlocalize
filter, though I did ponder using USE_L10N = False in the past. I don't
know how many projects there are in the wild that go with USE_L10N = False.

Personally, I believe removing the setting and **not** localizing values
unless explicitly requested would be the best option in the long run.
But I guess that would create much bigger compatibility issues.

Overall, I'm +0 on this.

--
René

[René Fleschenberg]

Hi,

On 6/11/21 6:50 PM, Claude Paroz wrote:

> Is there a possible deprecation path?

Maybe add a system check that warns if the setting is still present?

--
René

[Claude Paroz]

Le dimanche 13 juin 2021 à 01:09:26 UTC+2, re...@fleschenberg.net a écrit :

I have run into bugs because template authors forgot to unlocalize
values, in particular database IDs. These bugs often go unnoticed for
quite a while because they only show up once you reach 1000 database
rows. Forgetting to localize a value would typically be a much more
obvious bug.

I understand this concern. I wonder if that could be solved separately, for example by:

 - returning int subclasses from AutoField's to_python (a bit like str/SafeString for handling escaping)

 - not localizing those integers, unless use_l10n is forced (True)

Does this look like a plan (even without touching USE_L10N)?

On 6/11/21 6:50 PM, Claude Paroz wrote:
> > Is there a possible deprecation path?

> Maybe add a system check that warns if the setting is still present?

Sure, the warning could suggest some tips or redirect to some part of the docs.

Thanks for the input.

Claude

[Carlton Gibson]

Hey Claude, thanks for this. 

This seems like a win to me... a nice clean-up. 

I have to say, I never once set `USE_L10N = False` — I don't imagine many

people do, but my only concern would be whole swaths of folks that depend on

this… — do such exist in numbers? 🤔

This comments seemed pertinent: 

> Le dimanche 13 juin 2021 à 01:09:26 UTC+2, re...@....net a écrit :

> > I have run into bugs because template authors forgot to unlocalize 

> > values, in particular database IDs. These bugs often go unnoticed for 

> > quite a while because they only show up once you reach 1000 database 

> > rows. Forgetting to localize a value would typically be a much more 

> > obvious bug. 

> 

> I understand this concern. I wonder if that could be solved separately, for example by:

>  - returning int subclasses from AutoField's to_python (a bit like str/SafeString for handling escaping)

>  - not localizing those integers, unless use_l10n is forced (True)

> Does this look like a plan (even without touching USE_L10N)?

So we escape HTML by default, because that's the right thing to do. 

Same here, we already localize by default (in reality, because the project 

template has been that way ≈forever), again because it's the right behaviour. 

We `unlocalize` where that's not helpful. (But maybe there could be nicer API 

there.) 

Here we're just removing a whole load of codepaths for handling a unusual 

use-case. (Again, assuming it's as minority as we think). 

From the PR: 

> ...if needed, you can simulate the

> old ``USE_L10N = False`` behavior by defining those format settings in your

> settings file. 

> - docs/releases/4.0.txt

Maybe we could give an example there (🤔) but there's a fallback. 

So I think +1. 

Kind Regards,

Carlton

[René Fleschenberg]

Hi Claude,

> I understand this concern. I wonder if that could be solved separately,
> for example by:
>  - returning int subclasses from AutoField's to_python (a bit like
> str/SafeString for handling escaping)
>  - not localizing those integers, unless use_l10n is forced (True)
> Does this look like a plan (even without touching USE_L10N)?

Sounds good to me!

--
René

[Jacob Rief]

I in favor with René Fleschenberg's proposal to enforce localization using a template filter.

It happened too often, that someone forgot to unlocalize a primary key in their templates

causing unwanted results.

[Hanne Moa]

On Tue, 15 Jun 2021 at 12:25, Carlton Gibson <carlton...@gmail.com> wrote:
> I have to say, I never once set `USE_L10N = False` — I don't imagine many
> people do, but my only concern would be whole swaths of folks that depend on
> this… — do such exist in numbers? 🤔

I don't think I've ever set USE_L10N to True, and I've been using
Django in production since 0.96.


HM

[Claude Paroz]

I don't think I've ever set USE_L10N to True, and I've been using
Django in production since 0.96.

What would be most interesting to know is whether setting USE_L10N to True would cause issues in your projects.

Claude

[אורי‎]

In my project USE_L10N = True and USE_I18N = True since the beginning (2016).

אורי

u...@speedy.net

--
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-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7da3ed2b-8d31-4c9e-9423-c8eac33f93cfn%40googlegroups.com.

[Michael]

Starting with version Django 5.0, with USE_L10N setting being removed, will there be any way to control how date times look in the Admin site? Removing this setting makes scientific/engineering applications lose a lot of control in the admin interface. Say I have a field created_utc and it needs to be shown in ISO format in the admin interface, how would one do that with this change?

[Michael]

`USE_L10N = True` breaks all my forms that have Datetime fields. The `value` attribute of the date inputs no longer are in the right format, and the POSTing the data fails. Might be worth alerting other as part of the release.