It would be useful to have a consistent interface between localflavor modules. Something in the line of the following:
SUBDIVISION_NAME - top level subdivision name, e.g., "state", "province", "county", "parish" etc. or None if there are no subdivisions. POSTAL_CODE_NAME - "zip", "postal code", "pin", "index" etc. or None if country has no postal codes. NEED_POSTAL_CODE - True or False (tells us whether or not postal code is required for this country). SUBDIVISION_CHOICE - List of lelel 1 subdivisions or None if country has no subdivisions, This can be aliased (e.g., US_STATES) to please local users as well as for compatibility purposes. FULL_SUBDIVISION_CHOISES - Optional nested tuple for countries with multiple subdivisions. By default same as SUBDIVISION_CHOICE POSTAL_CODE_VALIDATOR - Postal code validator or None if postal code is not required. PHONE_NUMBER_VALIDATOR - Phone number validator or None if not applicable. On top of this: model field and form field shortcuts (e.g., SubdivisionField, PhoneNumberField) and other country specific goodies (e.g., social security number validator). All localflavor modules must pass a minimal interface compatibility test. Thanks On Sun, Oct 30, 2011 at 4:33 PM, Jli <[email protected]> wrote: > Hi, > > According to this ticket https://code.djangoproject.com/ticket/17136, > I found the localflavor module being a very neat idea but was a bit > disappointed with the actual consistency between the different locales > and their implementation. > > Also, the difference in implementation makes the documentation > inaccurate and a bit confusing. > > I would like to propose the following improvements: > > - Widget should be abstracted by the api and fields should always be > implemented. I think that's it's more 'natural' to expect a field > instead of having to mess with regular field, widget and class > attributes. Look at the actual implementation of the BE locale against > the CA locale and it should make my point clear ( CA is the way to > follow ;-) ) > > - Another point is that I often find myself having to deal with City > and Postal codes database, I think it would be nice to have them > available too but the number of items is quite huge for each country > and I don't know if it's really something that should come included in > Django. Also I have no clue how we can avoid to impact the general > memory usage and performances. > > Depending on the outcome of this thread and your opinions, I'd be > happy to help to improve the Be locale and to provide a general > guidelines along with documentation on this matter. > > Waiting for your ideas and comments. > > > > -- > You received this message because you are subscribed to the Google Groups > "Django internationalization and localization" 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-i18n?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django internationalization and localization" 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-i18n?hl=en.
