Localflavor Improvements.

6 views
Skip to first unread message

Jli

unread,
Oct 30, 2011, 4:33:48 PM10/30/11
to Django internationalization and localization
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.



Sergiy Kuzmenko

unread,
Oct 30, 2011, 10:27:39 PM10/30/11
to djang...@googlegroups.com
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




--
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 djang...@googlegroups.com.
To unsubscribe from this group, send email to django-i18n...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-i18n?hl=en.


Jli

unread,
Nov 7, 2011, 5:55:11 PM11/7/11
to Django internationalization and localization
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 <s.kuzme...@gmail.com> 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 <liuti.j...@gmail.com> wrote:
> > Hi,
>
> > According to this tickethttps://code.djangoproject.com/ticket/17136,

Finn Gruwier Larsen

unread,
Nov 8, 2011, 2:19:36 AM11/8/11
to djang...@googlegroups.com
I agree to both.
Reply all
Reply to author
Forward
0 new messages