Removal of USE_L10N setting

164 views
Skip to first unread message

Claude Paroz

unread,
Jun 11, 2021, 12:51:09 PMJun 11
to django-d...@googlegroups.com
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

unread,
Jun 12, 2021, 7:09:26 PMJun 12
to django-d...@googlegroups.com
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

unread,
Jun 12, 2021, 7:12:56 PMJun 12
to django-d...@googlegroups.com
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

unread,
Jun 13, 2021, 2:34:41 PMJun 13
to Django developers (Contributions to Django itself)
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

unread,
Jun 15, 2021, 6:25:18 AMJun 15
to Django developers (Contributions to Django itself)
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

unread,
Jun 16, 2021, 8:12:07 AMJun 16
to django-d...@googlegroups.com
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

unread,
Jun 16, 2021, 8:31:13 AMJun 16
to Django developers (Contributions to Django itself)
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

unread,
Aug 11, 2021, 8:59:04 AMAug 11
to django-d...@googlegroups.com
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

unread,
Aug 13, 2021, 9:46:46 AMAug 13
to Django developers (Contributions to Django itself)
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

אורי

unread,
Aug 13, 2021, 9:55:29 AMAug 13
to Django developers (Contributions to Django itself)
In my project USE_L10N = True and USE_I18N = True since the beginning (2016).


--
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.
Reply all
Reply to author
Forward
0 new messages