New model fields for languages and countries at least

[Raphaël Hertzog <raphael@…>]

I think that many applications have to deal either with language specific content and/or countries. It would be nice if Django provided ready to use fields for languages and countries instead of asking every user to handle the list and its full translation by himself (it could be a contrib package though). IMO this is best done by creating some glue on one of the available open-source reference lists. At Debian, we use a package called iso-codes that is very well-translated and kept up-to-date as it's used by our installer.

​http://svn.debian.org/wsvn/pkg-isocodes/trunk/iso-codes/?rev=0&sc=0

I can also mention the django-countries project created by Chris Moffitt (who created Satchmo, a Django-powered e-commerce framework). Its extent is somewhat more limited but it's already developed specifically for Django.

​http://code.google.com/p/django-countries/

And then, of course, there's Babel:
​http://babel.edgewall.org

The idea is to have something like:

country = models.CountryField()
language = models.LanguageField()

Instead of:

COUNTRIES = (
    ('fr', _('France')),
    ('de', _('Germany')),
    ...
)
country = models.CharField(max_length=10, choices=COUNTRIES)

which requires redoing the translation work and which is tedious to manually maintain.

[Malcolm Tredinnick]

Generally a good idea. The only requirement is that the list has to be something we can ship in Django. The standard Django installation should have essentially no external dependencies, apart from the db wrapper.

Definitely agree about the idea of creating a list for this.

[chris@…]

I think it would be possible to include the Satchmo models and intial_data.xml as something like django.contrib.iso_codes

All of the info is BSD licensed through Satchmo so I have no issue including in Django.

You can see the models here-
​http://www.satchmoproject.com/trac/browser/satchmo/trunk/satchmo/l10n/models.py

It uses the initial_data from here-
​http://www.satchmoproject.com/trac/browser/satchmo/trunk/satchmo/l10n/fixtures

Let me know if you'd be interested in using this.

Also, just for the record, I did not create django-countries ;)

[Michael Radziej]

The positive reaction of Malcolm looks like it should be Accepted (though the solution isn't clear).

Raphaël or Chris: Can you please bring this up on the developer list? It would be nice to introduce this to more people and see what they think.

[chris.moffitt@…]

Developer thread here - ​http://groups.google.com/group/django-developers/browse_thread/thread/498854003accaae1

[zeke]

Django-countries is based in another project, ​WebDa. And looks that Chris Moffitt was not accomplishing with the ​license of its author. And it's very possible than django-countries is being a derivated work of WebDa (but it isn't beind credited), because the definition of ​AREAS is exactly equal than the one original.

I'll try to contact with its original author.

[chris.moffitt@…]

Originally satchmo was using Webda. There were some licensing concerns about the data but not the models. The current satchmo implementation is fully BSD licensed. As I mentioned on the developer thread, I'm willing to help someone get this into Django but I don't have the bandwidth to spin this off into another project.

[Marinho Brandão]

I wrote the following snippets who does exactly what you want.

​http://www.djangosnippets.org/snippets/493/
​http://www.djangosnippets.org/snippets/494/

Can I wrote these as patch fix for this task?

[Marinho Brandão]

Fixings. I did it at db wrapper componente because was I understood of following Malcolm's sentence:

"The standard Django installation should have essentially no external dependencies, apart from the db wrapper."

[Jacob]

I really don't like sticking all the countries in global settings; that's the wrong place for it. I think that the right place would be in django.contrib.localflavor.generic. Otherwise, though, a very good patch.

[Marinho Brandão]

fixed

[Marinho Brandão]

Patch updated with validators and COUNTRIES settings moved to localflavor.generic package.

[Martin Conte Mac Donell <Reflejo@…>]

Just changed maxlength (deprecated) to max_length

[Martin Conte Mac Donell <Reflejo@…>]

Just changed maxlength (deprecated) to max_length (Sorry about the last patch, it was merged with other one, please delete it.)

[lcordier]

The source of the country_codes, http://xml.coverpages.org/country3166.html, is a bit outdated,

• Yugoslavia and Zaire should be removed
• Ivory Coast should be renamed to Côte d'Ivoire (some ascii codec have problems with the ô) so use Cote d'Ivoire instead.
• Add ('CD', _('Democratic Republic of the Congo')),.

I would also suggest that the country list be sorted alphabetically by the country name as to appear
more sensible in the select box (widget).

​http://www.iso.org/iso/iso3166_en_code_lists.txt, ​http://en.wikipedia.org/wiki/ISO_3166-1

[lcordier]

Example program to maintain & sort counties.

[Martín Conte Mac Donell <Reflejo@…>]

Patch against trunk

[Martín Conte Mac Donell <Reflejo@…>]

This ticket is cursed. There is the patch against trunk

[lcordier]

Make it patch against the latest trunk, some things moved around, and validator_list seems to be gone.

[lcordier]

You'll have to create django/tests/modeltests/countries/__init__.py (empty file) since it appears patch -p0 < patchfile does not create it.

[lcordier]

Patch with form-presentation improvements, countries are now sorted.

[Gonzalo Saavedra]

Is this ticket ready for check in? Patch looks good.

[Alex Gaynor]

No, it's not. If for no other reason than this ticket violates the, "contrib should be rm -rf able".

[idris]

I suggest adding a slug to the COUNTRIES list, as it would be nice to be able to use pretty url's based on a CountryField, like /afghanistan/ or /brazil/

[Gregor Müllegger]

I like the COUNTRIES choices in the django/contrib/localflavor/generic/init.py file of the patch. It would be nice if there would be something like prefered countries that appear first in the choicelist - because Afghanistan is a quite bad default in most cases. Here is a possible implementation that uses a PREFERED_COUNTRIES setting:

def prefer_countries(countries, prefer=(), separator='-' * 5):
    prefered_countries = []
    for country in countries:
        if country[0] in prefer:
            prefered_countries.append(country)
    countries = list(countries)
    countries = prefered_countries + [('', separator)] + countries
    return tuple(countries)

COUNTRIES = prefer_countries(COUNTRIES, settings.PREFERED_COUNTRIES)

What do you think?

[Hector Lecuanda]

Apply against latest trunk, moved field definitions to localflavor so as to keep contrib as 'rm -rf -able', added working tests

[Mitar]

Why LanguageField is not fixed with choices:

kwargs.setdefault('choices', settings.LANGUAGES)

And isValid functions are probably unnecessary as form validation is not done anymore with validator_list.

[Mitar]

I am attaching a new version of geo fields. I over all data and I corrected it according to Wikipedia values (some values were missing or were invalid or not best possible). I also extended them also to a city field for which I added necessary data with major (not necessary capital in all cases) city for every country.

I also extended initial values to be a callable which takes a request as a parameter so that it is possible to do GeoIP based initial values. I explained this and how it is possible to make this work in #13972. If request is not specified it falls back to values from settings so it is also backwards compatible. (Only loading of GeoIP could probably also be made optional.)

[Mitar]

Geo fields with initial values based on GeoIP

[patchhammer]

country_and_language_fields_trunk.20100409.patch fails to apply cleanly on to trunk

[Claude Paroz]

Now that contrib.localflavor is gone, I don't see why we would include this. ​django-countries seems to be a well-maintained external app.