I'll just add my 2 cents as partial copy/paste from the (now closed) ticket page:
I agree w/ Serge that USE_L10N should be the default value for localize. * I think the case Russel mentions is the exception, not the rule. "Usually" a number is just a number, not a year. Postal codes and phone numbers are often not numbers at all but a string. * We (Django) have made the opposite decision for template rendering: Indicating USE_L10N in settings makes localized rendering the default throughout the application, and the developer is left to find the exceptions and note them whenever they occur. This is inconsistent with the way we deal with forms. * If blank/help_text/verbose_name are considered undesirable elements of Model Fields I'd love to know what the new canonical pattern for DRY between models and corresponding forms is. I _do_ think there is value in not repeating yourself between forms & models. On Jun 23, 2:22 am, "Serge G. Spaolonzi" <[email protected]> wrote: > I have opened a ticked for this same issue, it was rejected because the > core team didn't liked the idea of including FormField options in > ModelField. Decision i think was correct, I wasnt aware the other > FormFields options in ModelFields like help_text were there for historical > reasons.https://github.com/cobalys/django/blob/ticket_18471/django/db/models/... > > If this is not the correct way to do it, we need to find another way to do > it respecting the DRY principle. > imao the ModelFields must localize according to settings.USE_L10N, then if > it is specified in the option localize as false that field must not > localize. > > From the official Django Documentation: > > USE_L10N > Default: False > A boolean that specifies if localized formatting of data will be enabled by > default or not. If this is set to True, e.g. Django will display numbers > and dates using the format of the current locale. > > As I understand USE_L10N sets the default behavior application wise for the > localization. > > Regards > Serge G. Spaolonzi > > > > > > > > On Fri, Jun 22, 2012 at 9:16 AM, Karen Tracey <[email protected]> wrote: > > On Fri, Jun 22, 2012 at 7:23 AM, Klaas van Schelven < > > [email protected]> wrote: > > >> I've created a ticket, but have always understood that calling > >> attention to tickets should be done separately on the Django- > >> developers mailinglist > > > It's not necessary nor encouraged to call attention to newly-opened > > tickets on the -developers list. People are asked to post to the list in > > preference to "contesting" a resolution the don't agree with (e.g. > > wontfix). Newly-opened tickets on the other hand don't need to be announced > > on the list, plenty of people monitor the flow of incoming tickets. > > > Karen > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > >http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
