On Sat, Oct 9, 2010 at 2:25 AM, Michel Thadeu Sabchuk <miche...@gmail.com> wrote: > Hi guys, how are you? > > I had problems with DecimalField and localize input/output. I found > the bug and I'm working on it: > > http://code.djangoproject.com/ticket/14101 > > While I digging to find the bug, I see that the DecimalField (and even > the Field class) uses a "localize" attribute. I think this localize > attribute is useless and I not alone:
Well, no - it isn't useless. It was introduced for a very specific reason. Even if you are using L10N, there are occasions when localized widgets *aren't* the right thing to do. Consider as an example: Australian postcodes are 4 digit numbers. It's entirely reasonable that they might be stored as an IntegerField. But it would be completely inappropriate to display an Australian postcode with localize=True -- as "6,105", rather than "6105". The argument is slightly weaker when it comes to dates and decimals, but because L10N formatting has a profound effect on the way data is entered (and thus on the UX of your site), and because L10N can be used in ways other than form processing (e.g., automated formatting of dates variables in templates), we made the decision prior to 1.2 to make form localization an opt-in behavior. That said, I will completely agree that it's inconvenient to need to manually turn on localization everywhere. To that end, I'm interested in any proposal that will: * make it easier to turn on form localization * turn on form localization in admin. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
