`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.
On Thursday, 11 August 2022 at 18:30:36 UTC+2 Michael wrote:
>
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
In my project USE_L10N = True and USE_I18N = True since the
beginning (2016).
אורי
u...@speedy.net
On Fri, Aug 13, 2021 at 4:47 PM Claude Paroz wrote:
> 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
>
> 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
--
You received this message because you are subscribed to the
On Tue, 15 Jun 2021 at 12:25, Carlton Gibson 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 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.
--
You received this message because you are subscribed to the Google Groups
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
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
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
>
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é
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)"
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
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
12 matches
Mail list logo
