Hi Russell! > 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 > withlocalize=True -- as "6,105", rather than "6105".
I think a bit more about this case. Wouldn't it be better to have a generic case (the integer field) working as expected and the specific case (the postcode) extending the functionality where it is needed? Anyway, the form field for an Australian postcode is a RegexField, according to the localflavor ;) > 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. I agree that the user must have a way to activate/deactivate localization. The subject I choose to the topic is the worst. The question is too much related with decimal fields when compared to datetime fields: The datetime field does not care about localize the output data because this is done on the datetime widget. The widget calls get_format and the get_format relies only on the USE_L10N variable. Even the input data isn't controlled by the localize keyword on the datetime field. On the other hand, the decimal field controls the input data with the localize keyword (that defaults to false) and do not touch the output data. > I'm interested in any proposal that will: > * make it easier to turn on form localization Maybe we can change from an opt-in (localize defaults to false) to an opt-out (localize defaults to true) in such cases. This way, a generic integer field would be rendered as "6,105" and the postcode field could just turn off the localization by extend the __init__ method of the field class. I will fix the 14101 ticket [1] following the current standard and, as you suggested me, I will clarify my ideas on how to make it easier to deal with form localization on a new thread. ok? Thanks! [1] http://code.djangoproject.com/ticket/14101 -- 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.
