Reopen and reassign Countries project

the other project didn't have any code, so I unpublished it.

Automatically closed -- issue fixed for 2 weeks with no activity.

Two requests:

1) Assess if there is room in DO for a simple generic Countries widget for Drupal 7+

My personal reason for this was:

We've used one of these on about 20% of the projects that we have developed, and on half of these, one of the more complex regional modules were used, and on the other half, a custom FAPI select element was used. From Drupal 7, most of these will require Country widgets instead, which is no longer just a simple 5 line idiom that an average programmer could do in their sleep.

2) It is possible to reactivate this project and have ownership transferred to myself?

After deciding yes to #1 myself, I checked CVS for a namespace conflict and programmed up a module to do this. It was only after committing that I discovered the dead project conflict.

I do not know what the original module attempted to do. My new version provides four country related tasks / goals.

• A countries database with an administrative interface.
• A way to alter Drupals core country list via hook_countries_alter().
• A country FAPI element.
• A countries field.

The only outstanding thing is i18n, but way too early to consider starting this as i18n port is not yet started.

Full details and a partial module comparison (the comparison is a bit rough) can be found in the projects readme.

http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/countries/R...

The module should be functional against HEAD.

Thanks

@Alan D.: You are not the maintainer of the project anymore (and you don't have access to the project CVS too); why should the ownership be transferred to you?

@Alan D: sounds like your widget would make a great feature request for the countries_api module. I'm unclear why you consider it was not a good idea.

@KiamLaLuno - I never was. The namespace was free on CVS and I committed there thinking that it was free. It was not. The original maintainer never committed to CVS so there were no locks in place from preventing my commit. Look at the $Id$ headers

$Id: README.txt,v 1.2 2009/10/11 08:12:09 aland Exp $

@Damien - The purpose of the countries_api is to convert between the various codes. To quote from the countries api project page

This is a utility module for converting country code data from one format to another.

I think that the main use of the countries api is a duplicate, like its usage with country flags, etc. As soon as the data is editable, the countries api core functionality would be void. Many lookups are name > iso2.

The main purpose of mine would be to provide an editable countries database, with the additional widgets, and the control of the internal countries list. The main reason that I made the names editable here to prevent crazy long country names upsetting many themes, like "Congo, the Democratic Republic of the" when I prefer the Drupal 7 "Congo (Kinshasa)" naming.

I'm hoping that more developers use the core internal system, as at least 10 modules provide an internal countries database, something that can be replaced using:

Personally I don't really care one way or the other what happens, the community can decide if this is worth it. Trying to take ownership of this abandoned one forces the question into the community, which is a good thing IMHO. A stronger argument was put forward here, #597748: Integration with new core Drupal 7 features & simple field elements? but I think that I may have pushed to hard.

It is a useful module that we be using a lot internally, I just thought that I would share ;)

@Alan D.: as you describe it yourself, there are two parts in the code you have been working on:

- an UI around D7 countries list: the country list and the UI deprecates most of what Countries API is doing right now. That means that your UI could fit perfectly in a refactored Countries API for Drupal 7
- a D7 field and widget for a country. This could be a great addition to the Countries API (as a feature request). The idea could probably be backported to D6 as a CCK field, as (at least from your list) no such thing exists in Drupal 6 yet.

In a nutshell: (1) there is no need for two overlapping countries module for Drupal 7 and (2) Countries API will need a upgrade path anyway. Please collaborate with the maintainer of Countries API.

I contacted them directly, but I have had no response.

I don't really have the time to much around with this that much, and I do not want to install 3 or 4 modules to do what this does. Too many modules is such a performance drag. I'm closing this ticket and leave it to them to consider implementing these features. There will be an issue if there is an interface for the countries api; using the core functionality to map countries with external APIs, as per the reason for the countries_api, will mean that users either break the relationships with these external services or that they are forced to maintain the unwanted existing names.

If anyone is interested, we will be running with this internally and I'll try to remember to keep the CVS up to date even though there will be no project.

Thanks to everyone that took the time to give feedback.

We don't close the issue reports; then I would leave the task to change status (it could be marked as won't fix) to a webmaster.

Alan D. I know we spoke about the overlap of these two modules recently, but I don't have any time to commit to this currently. You are more than welcome to commit access to the countries_api module if you feel it would be a good idea to merge projects in some way.

Hi Tom

This would be a significant shift in the way that the countries api works, but it would also open up a large potential user base. At our work we would use a single country element about 10% of the time, which scaled up would translate to a potential usage of 20,000 based on the current Drupal stats. This is likely to increase if profiles become fieldable.

The module that I wrote is about 3 times larger (ignoring regions and services) and only has two getters for country data, get_country(iso2) & get_countries(iso2, return_property). Everything is based on iso2, as everything else is editable. If you are interested, I can look at back porting this to Drupal 6. After some free time over the last couple of weeks, things have gotten crazy at work, so this would be at least a couple of weeks away.

Also with these additional features, it would not just be an API anymore, maybe you could ask for the country namespace ownership if you run with this. This would provide a great way to isolate and develop without risking the current project

Also, I forgot to mention this and didn't get time to create a patch, but the ISO data should be complete in countries.csv file in cvs. (For the iso3 / num3 codes). Have you ever checked the legality of maintaining a database of these extended codes? These are so common on the web but they are not publicly available from the ISO site.

Right, must get onto some work. Major release on Wednesday...

Cheers Alan

Sadly, I am not going to have the time to port this backwards to D6, but feel free to use any bits you want. It would be a damn shame if none of these features get into the community!