Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

django.forms.fields.Field.localize to default to settings.USE_L10N

115 views
Skip to first unread message

Simon Charette

unread,
Feb 14, 2011, 8:37:21 PM2/14/11
to django-d...@googlegroups.com
Hi, I encountered a problem with DecimalField and DECIMAL_SEPARATOR in the admin which lead me
to a ticket [1] which was marked as worksforme.

Well it wasn't quite workingforme so I tried to come up with a testcase since the ticket has none.

I realised that the actual implementation of DecimalField was working perfecly when it was initialized
with the "localize=True" kwarg. Which lead me to a larger issue concerning admin not considering
settings.USE_L10N: ModelAdmin.formfield_for_dbfield should pass the localize=True kwarg if
settings.USE_L10N=True. IMHO it's an expected behavior.

I'm also wondering if the issue shouldn't be tackled at the forms.fields.Field API level instead.
What about defaulting Field.__init__ localize kwarg to settings.USE_L10N?

Simon

[1] http://code.djangoproject.com/ticket/14101

Russell Keith-Magee

unread,
Feb 15, 2011, 8:06:20 AM2/15/11
to django-d...@googlegroups.com

The decision to make localize=False the default value for all widgets
was quite deliberate. There are plenty of edge cases where
localization *isn't* acceptable, even when USE_L10N is enabled. For
example, if you have stored a year as an integer, it shouldn't be
localized -- this year is 2011, not 2,011. Similar problems exist with
postcodes, phone numbers, and so on.

contrib.admin is an autogenerated interface, and as such, needs to
"work by default" -- turning on a single setting shouldn't cause
widgets to suddenly display broken values for some (but not all)
widgets. Hence, the admin doesn't do anything with the USE_L10N
setting, and localization is treated as a completely opt-in behavior.

Now -- there is certainly room for improvement here. It should be a
lot easier to turn on localization for specific widgets (or,
alternatively, to turn it on for all widgets, and off for specific
widgets). I don't believe there is a specific ticket describing this
problem, but it is a known problem, and one that I'm not opposed to
fixing. However, the fix *isn't* to use USE_L10N as the behavior
switch.

Yours,
Russ Magee %-)

Simon Charette

unread,
Feb 16, 2011, 2:38:50 PM2/16/11
to django-d...@googlegroups.com
Thank you very much for your feedback, I was wondering
what were the edge cases that motivated such a decision.

Do you believe it makes sense to have such a switch at
the Form level, say a localize keyword which it's fields
would default to? The same could apply to ModelAdmin
localize_forms. If so i'll file a feature request whith a patch
and tests. I might need some help on doc however.

Simon
Reply all
Reply to author
Forward
0 new messages