Yes ! This is the kind of thing I had in mind! Also what do you guys think of integrating a feature like this one into local flavor ? https://github.com/ulule/django-countries
It would be easier to maintain an accurate list. I think. The same goes with Cities and Zip codes. It's always a burden to have to build them and check on their accuracy. Is it something that fits into localflavor or is it out of scope ? Thx. On 31 oct, 03:27, Sergiy Kuzmenko <[email protected]> wrote: > 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 tickethttps://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.
