Add ability to configure site default country

Well, I would really much like that we rework the date and time page into a full featured "regional settings" page, including country, default time zone, number formats and currency. This is a first step in that direction, but we should think about it a little bit more.

Damien's plan seems like a good one, at least long term, will take a proper look at this patch later.

So while this patch looks like a lot of code due to the include (which is only loaded on one settings form), it just adds two forms - one to the installer, one to a settings page for default country. There's a @TODO for drupal_alter() in there - we should add that, and also hook documentation now that system.api.php is available to patch against.

Would it be too much to change 'date and time' to regional settings, and add the form as a fieldset there? We could still mention date/timezone settings in the description on the admin index.

I tested the patch in #7. Improving drupal's intelligence in this area is a great idea.

On the install, could we choose the country a bit more intelligently like we do the time zone, at least choose a country in the timezone chosen?

It seems to have worked in the regional settings menu.

I would prefer to see this connected to the 5-character so that you have more information (country and language).

There's no way to choose a country in the timezone unless we have some code that maps countries to timezones, and I don't know of any easy way to do that. But we can map continents to timezones, since the continent name is in the timezone name.

I'm wondering if the country list should be in the db instead of an array so we can add additional information to it. For instance we could add a column for 'continent' to each country relatively easy, then use the continent of the selected country to reduce the size of the available timezone list, or use the continent of the timezone to reduce the size of the country list.

We could also later add columns for the official languages for each country to reduce the size of a language list, or limit the country list to only countries that support a given language.

All of those things are only feasible if we store this info in the db instead of a hard-coded array.

Slightly off-topic. For the language codes (not country codes!), I think we need to move from ISO 639-1 to ISO 639-2. On Mollom.com, we could not use Drupal's built-in language list, but had to use our own ISO-639-2 list because it is more complete. I know this isn't the same as the country list proposed in this patch, but I figured I'd bring this up because there might be interplay between these different ISO standards. Anyway, might be useful to create an iso.inc instead of a country.inc which includes both.

PS: I'm OK to go with hard-coded lists for now.

Patch works well, a few questions though:

Why are the countries using $t() but the languages not?

While I like the 'regional settings' page, I'm now wondering wether we want the actual date presentation settings on there - since they're not really tied to localisation at all. It might possibly make them hard to find for people who just want to change whether their site uses Wednesday or We. Short of a separate admin/settings/date page with just those settings on, I'm not sure where else they can go though.

+  $items['admin/settings/regional-settings'] = array(
+    'title' => 'Regional settings',
     'description' => "Settings for how Drupal displays date and time, as well as the system's default time zone.",
     'page callback' => 'drupal_get_form',
     'page arguments' => array('system_date_time_settings'),

I suggest you rename system_date_time_settings() to system_regional_settings() to match the menu patch.

-    '#description' => t('Select the default site time zone.')
+    '#description' => t('Your time zone setting will be automatically detected if possible. Please confirm the selection and click save.'),
+    '#attributes' => array('class' => 'country-timezone-detect'),

What's the purpose of that class? There is currently no magic connected with country-timezone-detect. There is with timezone-detect, though, but that will make the auto-detection overwrite the previous value, every time the page is loaded. The timezone is set during the install and when upgrading from D6 (I think), so there is usuallly no reason to do auto-detection here.

iso.inc seems like a very general name. ISO standardized lots of stuff. On the other hand, iso.inc may be a good place for any kind of list that is derived from an ISO standard.

+ * in ISO 3166-1 alpha-2 with the exception that on the ISO standard
+ * country codes are uppercased.

Why not use upper-case like in the official standard?

The list misses two country codes that were assigned in 2007 (mentioned in the Wikipedia article on ISO 3166-1):

• BL: Saint Barthélemy
• MF: Saint Martin (French part)

Let's go with the generic iso.inc for now. We can decide to rename or split it up later when it becomes a problem.

The comments in #22 need to be tackled.

-    '#description' => t('Select the default site time zone.')
+    '#description' => t('Your time zone setting will be automatically detected if possible. Please confirm the selection and click save.'),

This looks like a left-over from the earlier version of the patch. AFAICT there is no auto-detection on admin/settings/regional-settings. You may wish to change either the country or the timezone description, though, so they use the same phrasing, either “Select the default XXX for the site” or “Select the default site XXX”. I suggest you add a brief mention of what the default country is used for (for sites with an international audience it may not be obvious what the “default country” is).

If the user does not select a country but just clicks Save configuration, site_default_country is set to AF (Afghanistan), because it is the first country in the list. This seems like an odd default. I wonder whether there should be a dummy “no country” option at the top of the list. If the country is to be used for date formatting etc. there need to be some default, so perhaps it is better to add a default, e.g. US to match that the default UI language is American English.

"No default country" is different than "Please select a country". In some cases, it might not make sense to have a default. Drupal.org would be a good example of where it might be better not to have a default.

I’ve installed this patch and tried to see it’s benefit. I live in Canada where we have many time zones, two official languages, too many ways to write the dates and numbers, etc.

Although I was able to set the Default country, I do not see any interaction between the Country selection and any other Drupal site configuration. Are there other configurations and patches to be added later?

This patch works well though and can be comitted, but I don't see why we need this patch.

For example, Drupal ships with a single language, so setting the country would not change the language of the installation, but only set a flag for the user to download the language file later. Also selecting a country could offer default languages from a smaller selection, but what about country communities in other languages? A language affects the date format, so setting a Drupal site to a particular language should set the proper date format. But what if the user want to display the ISO date format?

There are some benefits, though, to set the Default country in Drupal:

• Show only the time zones for this country.
• Offer a choice of the default languages of the country, which would need to be downloaded (or automatically downloaded) later.
• Set the various default date formats, based one the languages selected or use the ISO date format.
• Set the number format, based on the country language.

Setting defaults is fine. But how far can we go and still let the user override settings?

As I stated earlier, this patch works, so RTBC.

However, on a larger view, all defaults must be over-ridable by the site administrator. Let's say that by default we setup a Canadian web site:

1. By default, the Canada setting sets the language to English. No need to add French since the default value is valid. The admin would be able to add French later. And for that matter, an Italian community in Canada would be able to set it's site in Italian.
2. By default, the Canada setting set the date format to Canadian English. No need to add French date format since the default value is valid. The administrator would be able to configure another date format later, and even configure it to use the international ISO date format.
3. By default, the Canada setting sets the time zone to Ottawa, which is the capital. No need to add any other time zone since the default value is valid. The admin would be able to change the time zone later and still let user adjust their own time zone.
4. By default, the Canada setting sets the number format to "$x,xxx.xx". No need to add the French Canadian number format since the first one is valid for Canada. The admin would later be able to change the number format to "x xxx,xx $" to make it French Canadian compliant.
5. For e-commerce modules (if we want to extrapolate), the Canada settings sets the tax tables to GST and PST by default. The admin then need to choose which province to set for the PST.

So like I said, even if we try to set as much default values as possible, each setting must be over-ridable. So, in my opinion, all these default setting are of no use.

The only setting that I think are important are:
1. language setting (and auto import), complete with 5 characters language code (fr-CA, en-CA, etc.).
2. time zone, which should default to the capital city of any country.

I'll be available to check on other issues related to this patch and see what comes of it.

Thanks stella! Good input from xmacinfo in the latest comment -- certainly something to work on. I went ahead and committed this patch to CVS HEAD. Let's address the other issues in follow-up patches. :)