Ensure ISO3166 list is up to date and ordered by country name not code [#91581]

Comment	File	Size	Author
#17	location.mf_.inc_.txt	91 bytes	Pomliane
#17	location.patch	3.72 KB	Pomliane

#7	location_iso3166update_0.patch	18.93 KB	geodaniel

#3	location_iso3166update.patch	16.72 KB	geodaniel

Comment #1

geodaniel CreditAttribution: geodaniel commented 27 October 2006 at 14:29

Title:

Ensure ISO3166 list is up to date

» Ensure ISO3166 list is up to date and ordered by country name not code

Hmm, whilst doing that, perhaps we should order those countries alphabetically by name instead of by country code. That should make them appear in the right order to users, for whom the current list causes constant confusion. Think, for example, about 'Germany' between Czech Republic and Djibouti (due to its 'de' code) instead of between Georgia and Ghana where it should fit naturally.

Log in or register to post comments

Comment #2

geodaniel CreditAttribution: geodaniel commented 26 January 2007 at 14:59

Version:

4.7.x-1.x-dev

» 6.x-3.x-dev

Log in or register to post comments

Comment #3

geodaniel CreditAttribution: geodaniel commented 1 February 2007 at 13:59

Assigned:	Unassigned	» geodaniel
Status:	Active	» Needs review

File	Size
location_iso3166update.patch	16.72 KB

I've attached a patch with a new country list based on the data at http://download.geonames.org/export/dump/countryInfo.txt (CC attribution license), sorted by country name.

There are a number of new additions (Guernsey (gg), Isle of Man (im), Jersey (je), Montenegro (me), Serbia (rs)), some codes that differ from the existing setup (Sweden (sw vs. se), United Kingdom (changed to uk)) and some that just seem to be missing .inc files (Lebanon (lb), Niger (ne)). We still need to add .inc files where necessary.

Log in or register to post comments

Comment #4

Tobias Maier CreditAttribution: Tobias Maier commented 13 February 2007 at 00:35

Status:

Needs review

» Reviewed & tested by the community

what speaks against committing this?

Log in or register to post comments

Comment #5

geodaniel CreditAttribution: geodaniel commented 13 February 2007 at 08:42

Status:

Reviewed & tested by the community

» Needs review

I'm not completely happy committing this as there is still an outstanding issue with the likes of Sweden. What should we do with data that had already been entered as sw. Should that be changed to se? What if people have written code based on that in their local system?

There were no comments on the original sw vs. se issue I opened a year ago, so perhaps we don't need to worry so much, but I think we should weigh up some options.

Log in or register to post comments

Comment #6

ankur CreditAttribution: ankur commented 13 February 2007 at 21:18

I think the appropriate way to deal w/ this would be to have, in the same revision, an extra function in the location.install file that does an 'UPDATE {location} SET country = 'sw' WHERE country = 'se'

As for people possibly having written code dependent on the hard-coding of a country code -- Ideally, I should be making this thing maintain a changelog for that kinda thing, with a drupal set message in the _update() function describing what changed.

Also, another reason the function is a little off is that I explicity decided to go w/ the ICANN domain letters for a country instead of the ISO but never changed the name of the function. I just couldn't imagine have 'gb' in place of 'uk' for the United Kingdom just because I'm used to seeing ".uk" on the end of a UK domain... I know; it sounds silly.

-Ankur

Log in or register to post comments

Comment #7

geodaniel CreditAttribution: geodaniel commented 16 March 2007 at 15:19

File	Size
location_iso3166update_0.patch	18.93 KB

Updated version of the patch attached, with the sw -> sw database update included (update 6). I've also renamed the sw file to se, leaving a comment for now in the old one in case anyone's wondering what happened. In addition, I've created stub files for gg, im, je, me, rs, lb and ne (Geonames doesn't list any administrative regions for any of these at the moment).

If there are no issues that anybody spots, I'll go ahead and commit this.

Log in or register to post comments

Comment #8

geodaniel CreditAttribution: geodaniel commented 26 March 2007 at 15:18

Status:

Needs review

» Reviewed & tested by the community

I've committed the changes to location.inc, location.install and location.sw.inc on HEAD, DRUPAL-4-7, DRUPAL-5.

I've also added the stub location includes to HEAD and DRUPAL-5, and am trying to figure out how to add them to DRUPAL-4-7 too (I think CVS is choking because I messed up the original commit of the files on DRUPAL-4-7 branch).

Log in or register to post comments

Comment #9

stormsweeper CreditAttribution: stormsweeper commented 2 April 2007 at 16:56

ankur: Also, another reason the function is a little off is that I explicity decided to go w/ the ICANN domain letters for a country instead of the ISO but never changed the name of the function. I just couldn't imagine have 'gb' in place of 'uk' for the United Kingdom just because I'm used to seeing ".uk" on the end of a UK domain... I know; it sounds silly.

You may want to add this to the README or somewhere else prominently. The gb code is in very common use, and this can cause a hiccup for integrating other systems that use ISO3166-1 (e.g. the "Accept-Language" HTTP header).

Log in or register to post comments

Comment #10

geodaniel CreditAttribution: geodaniel commented 21 August 2007 at 09:07

Status:

Reviewed & tested by the community

» Needs review

Just noticed that the ordering of the countries in location.inc seems to have reverted to the list sorted by country code instead of country name as of 1.45.2.5... is it intentional, or is it ok if I go in and fix it up again?

Log in or register to post comments

Comment #11

berenddeboer CreditAttribution: berenddeboer commented 18 October 2007 at 21:44

geodaniel, your original patch worked great. I'm guessing no one uses the location module, sorting countries by iso code is extremely confusing for ordinary users.