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