[META] Locale settings in Drupal make little (UX) sense

Not sure 'Server settings' is the best title for the fieldset either.

"Sunrise Sanity Cruise" lol :D.

These settings have been in the installer forever, so we never really questioned them I guess. I don't really get the significance of the country setting, it is not used for anything in core. I think it would be safe to remove(?).

For timezone, that is a bit different. Assuming your site would receive anonymous traffic, Drupal needs to take a timezone in that case and display dates in that timezone. I cannot just be "no timezone". Unless you mean UTC by no timezone that is. That would likely be more confusing for most people though than just assuming the local timezone of the developer setting up the site. I get that you mean developers could easily set up sites on behalf of others in other timezones, but outside of international providers, it is more likely that you'd set up a site for someone in the same timezone (especially in Europe). So I think this is the easiest to assume.

So my recommendation would be to remove country and leave timezone as-is.

+! to remove country that does not used. Commerce sites have own settings for default country in fields

@sun: your site would be hardly indexable with googlebot / cacheable in whatever cache if all visitors would have the times display in their own timezone. If it would default to UTC for anonymous users, I'm sure we'd get fired with regular bug reports about mistaken dates/times on posts. When people post something and check from their tablet and see it displays a totally different time, its a bug. The default timezone is also used to configure new users. After all a timezone setting on the user registration form would be a much bigger WTF, than seeing it in the installer.

I am not really convinced this belongs in the installer either, loads of webapps/CMS's get around not having this in the installer.

I think what is that timezone going to be used for applies. On a default standard install, these are the default settings for user timezone:

That is, users could set their own timezone, NOT on the registration form, so those who do not go and proactively edit their own timezone will get the site timezone. That makes the initially set / picked timezone pretty significant for the site. All users inherit time timezone.

What about taking server time as default time, instead from browser?

What about taking server time as default time, instead from browser?

That's what Drupal used to do. But it was considered poor UX because the location of the server does not correlate with the location of the website audience. The location of the user installing it seemed to correlate closer to the website audience location.

I'm in favor of removing the Default country list entirely given that a.) we don't use it in core and b.) #1938892: Switch from ISO-3166-1 country data to CLDR unicode data

No, we certainly shouldn't remove the country list from core!
We're on a good way to making Drupal core an awesome base for multilingual, international websites.
However, compare with your favorite operating system. Even with the huge D8MI agenda getting finished, there will be a few pieces missing, including:

1. decimal delimiter / thousands separator (by country)
2. numeral systems (by country)
3. timezone suggestions (by country)
4. calendar system (by country)
5. date and time formats (by country)
6. first day of week (by country)

And possibly:

7. first / last working day (by country)
8. secondary language suggestions (per country)
9. telephone number validation and formatting (by country)
10. metric / imperial measures (by country)
11. currency (by country)
12. ...

All of these features, UI-improvements and then possible bug fixes go by country, not by language.
With CLDR, we just switched to a database that gives us great data for all of these future improvements.

Some of them are already doable in D8:
See the 'Default country' select box. It could default to the most probable country for the given primary language and list the other probable options first. For many languages this default country would make sense, and it would decouple it from the admin's browser locale. The data we need is in CLDR.
Or the 'Default timezone' select box sun was complaining about. It could simply default to the most probable timezone for the chosen 'Default country'. For most countries this default would perfectly make sense. All data is in CLDR.
Or see the date and time formats and the 'First day of the week'. This always bugs me that I have to manually set them up, even though the system knows the default country.

What I agree with is that we actually should make use of the 'Default country' in core.
So let's keep this issue a UI improvement request and let's leverage the CLDR dataset for more than just the 'Default country' and the 'Default country' for more than decoration.

Could the country list be in contrib?
Sure it could. However, then there won't be the UI improvements in the installer. And probably the basic setup of "Regional settings" and "Date and Time" formats should be handled by core, too. And for decimal delimiter / thousands separator we'd need to create an API.
And then we'd need an contrib API module to avoid isolated one-off modules. Would changes in country data be taken care of correctly enough, so contrib can build on it?
No, IMHO the country list really belongs in core. It has always been (at least for a long time). And if we threw it out now, and a good contrib API successor would emerge, then it would be the next candidate for re-inclusion in D9. I think we don't want this kind of hopping between core and contrib. Let's keep and improve, maybe extend a bit the basis that we have, so contrib and custom code can continue building on it.

Oh, that's probably been too many unnecessary words and paragraphs...

DrupalDateTime uses the Default country, so it can provide DateTimePlus with the country code needed to leverage PHP's IntlDateFormatter class.
See also #1345758: META: Provide locale (regional) formats framework for automated translation of non textual data .

If the country select list stays, we could as a UX improvement use the country to filter (or for smaller countries - select) the right time zone(s), assuming we have a mapping of countries -> timezones

Sounds to me like the timzone still makes more sense to detect from the browser. We also do that for language on the first installer step.

Ok, one way or another, for UX it might make sense to link timezone and country. If I choose Europe/Amsterdam as 'timezone', I might assume that the default country would be 'the Netherlands', and if I choose 'Europe/Brussels', the default country will be 'Belgium'. People now have to choose in two select boxes a location, and it doesn't seem related. The wrong combination can cause unexpected offsets as the daylight savings are country specific (http://en.wikipedia.org/wiki/Daylight_saving_time_by_country).

@Hanno, #15:

...assuming we have a mapping of countries -> timezones

For starters, thanx for pointing me here from #2072489: Preselect proper timezone depending on selected country (or limit the list to only valid timezones) where I explain that there already exists such a list/mapping:

http://en.wikipedia.org/wiki/List_of_time_zones_by_country

@Gábor Hojtsy, #16:

It does make sense to detect timezone from the browser/OS when we deal with the site visitors (especially anonymous). We could also do that as a fallback if a registered user has opted out of specifying a country (for privacy reasons) or even perhaps detect based on visiting IP. But for the installer, IMO it makes more sense to evaluate the fact that we can use the php.ini date.timezone parameter. I understand the reasoning behind the logic of "server might be located elsewhere", but it could as well be a VPS server where the admin actually has access to these settings and indeed sets the preferred timezone (that is precisely my use case btw).

So basically ideally we could have something like this:

1. Detect timezone and country on the server side for the installer.
2. Detect the timezone and/or country from the admin (site builder) browser/OS/IP.
3. Offer both options detected from steps 1 & 2 in the form of a radio set. Preselect either one of these options (we can bikeshed over which one).
4. Offer a third "other..." option that presents the whole list of countries/timezones but keep the drop-down hidden unless this radio is actually selected. This will keep the UI to a minimum (no long drop-down menus) unless we did not do a good job "guessing" what the user intended. The admin (site builder) can still specify a different set as they see fit.

They can do so by either selecting country or timezone since if they have a one-to-one mapping, then they are interchangeable. If their preferred country spans over multiple timezones, we limit the respective drop-down to only those applicable (that's where #2072489: Preselect proper timezone depending on selected country (or limit the list to only valid timezones) comes into play).

5. Whatever the choice from step 4 above sets the site default country/timezone pair.
6. Anonymous users see things adjusted to the site default country/timezone from step 5 (behavior can also be augmented by contrib with IP detection).
7. Now, for registered users:

- We check to see if site policy allows them to set their preferred country/timezone (if not, we do nothing special and simply use the site default from step 5).
- If site policy allows them to override the country/timezone setting, we then make another check to see if they are allowed to have empty values (for privacy reasons). If they are allowed and they have not specified a preferred set in their profile form (or if the site is configured to use the default set for new users), we again simply fall back to the site default.
- If they are allowed to override the site's default country/timezone with their preference, we use a similar logic as with the installer:

a) detect things from browser/OS (or IP with contrib) and offer it as an option.
b) offer the site's default as an option
c) offer a "other..." option (and hide the huge drop-downs form the UI) - again employ #2072489: Preselect proper timezone depending on selected country (or limit the list to only valid timezones) for better UX.

This time we preselect none of the above options in order to honor the empty country/timezone possibility.

How does that seem to you?

PS: we should definitely not kill the country - we'll need it if we are to implement #1345758: META: Provide locale (regional) formats framework for automated translation of non textual data

@klonos the wikipedia page isn't the mapping we can use.
But this works:

a. If the country is selected, this gives an array of all the timezones in that country:

$timezones = DateTimeZone::listIdentifiers(DateTimeZone::PER_COUNTRY, $countrycode);

b. If the timezone is selected, you'll get the country code of that timezone with:

$tz = new DateTimeZone("Europe/Amsterdam");
$countrycode = $tz->getLocation()['country_code'];

Note that there is also the initiative for a visual timezone picker: #1787540: Improve the Timezone Picker
Awesome if we can integrate that one.

If we used an autocomplete (or better an autocomplete + drop-down combo) instead of the simple drop-down we have in place now, that would be a small (but rather quickly implementable) step towards better UX.

Great idea klonos! I will work it since I will add the timezone picker

Well, it does deserve its own issue I guess. So, let's make this a meta where the possible solutions are discussed but split off in various separate issues. Work can be done in parallel in these separate issues (and thus progress faster) and even if one proposed method fails to move, then perhaps we go with the simplest one and keep the other(s) in mind as improvements/additions for later on. At this point let me take the chance to say that I really like the idea of #1787540: Improve the Timezone Picker, but I expect it to take way longer than simply using jQuery UI (it does feel that #675446: Use jQuery UI Autocomplete is getting really close).

Edit: here's the separate issue: #2083575: Provide better UX when selecting Country/timezone.

Updated issue summary.

I didn't go through the whole issue in order to provide a proper issue summary, but I've added the previously mentioned issues plus #2072489: Preselect proper timezone depending on selected country (or limit the list to only valid timezones) to it as a "Proposed solutions/Related issues" section.

...this does not refer to the installer alone plus it is already assigned to the language system component. Besides, we do have the "installer" tag in place.

...adding some proposed solutions/related issues

Small note: The country *is* used, for some reason that I don't full understand yet, we only use the native php intl date formatter if we have a configured country. That tests don't is the only reason they're not exploding everywhere we edit nodes because that is right now broken if you are using intl and don't have the datetime module enabled: https://drupal.org/node/2031183

The country is also needed for the date format, because the e.g the month names may differ between countries with the same language:

January in German German is Januar, but in Austrian German it is Jänner

Rediscovered this following #3435850: Convert Country code to ISO 3166-1 alpha-3 and wondering why core needs to know about countries at all. Since #2276183: Date intl support is broken, remove it the default country setting is unused, so I opened some new child issues here:

#3439439: Remove country setting from the installer
#3439440: Remove country support from DateFormatter

@sleitner that is a property of the language rather than the country though - you should set up a different language for Austrian German rather than do anything with country codes.

Both children committed, looks it needs one more to remove settings country.default

@andypost, we would also need to remove it from RegionForm, I'm not sure if it's intended to remove it completely, that involves a contrib module too first I think.

I created the deprecation removal followup here: #3439711: Remove deprecated country call from 11.x

Yeah removing it completely means moving it to a contrib module, which would either need to go direct to address module if the maintainers are OK, or a new module in core which we move to contrib.

I think we should check how many contrib modules depend on default country before doing that - the original idea here was to centralize the config so that core could use it (that never happened) but also so contrib could use a consistent source (may or may not have happened).

Gitlab doesn't do a great job of removing false positives: here is the search: https://git.drupalcode.org/search?group_id=2&scope=blobs&search=country....

Let me create an issue on the address module to see if they'd be willing to adopt that setting as a first step.

I created an issue asking here #3439726: Consider adopting the core country.default schema I'm combing through the search above to catalog contrib that uses the setting.

There's only a few usages in contrib, and commerce is the one of them http://codcontrib.hank.vps-private.net/search?text=country.default&filen...

Oh that's an interesting site, I also combed through the gitlab search and found a few things:
These modules seem to use the default setting:

address
address_suggestion
apigee_m10n
arch
cforge
commerce
commerce_currency_resolver
config_overlay
contacts_events
contest
core
core_performance_testbed
currency
datalayer
dropsolid_rocketship_profile
farm
gitlab_cit_testbed_for_drupal_core
gmap_store_locator
href_lang_exchange
murmurations
mutual_credit
nodehive_core
postoffice_commerce
presto
price
rocketship_florista_demo_profile
siteinfo
sms_ui
twitter_trends
worldplay_corporate_gateway

These modules have a reference, but the references seem to be because they have committed core:

adoption_navbar
biolog
canvas_chronicles
confectionary
contest
distributions_recipes
drucloudaws
drupal_dev
drupalladder
facsite
featuresdev
flattern
git_branch
global_gateway
hiphopdrop
hunter
hunter_shop
intercept_base
justice
lgms
newspublish
openapplication
opensaas
powerful_surveys
razoreye_biz
sportsleague
timber
virtualcare
will_nice
will_nice_shop

Also a bunch of the modules are no longer supported: such as https://www.drupal.org/project/href_lang_exchange

Here is a sorted list by install:

address: 100558
commerce: 44209
datalayer: 9984
currency: 3219
commerce_currency_resolver: 1193
farm: 764
gmap_store_locator: 143
address_suggestion: 128
apigee_m10n: 114
dropsolid_rocketship_profile: 108
mutual_credit: 29
config_overlay: 15
intercept_base: 15
flattern: 12
contest: 11
rocketship_florista_demo_profile: 8
sports_league: 6
will_nice_shop: 6
cforge: 4
postoffice_commerce: 2
virtualcare: 2
justice: 1
murmurations: 1
siteinfo: 1
sms_ui: 1
distributions_recipes: 0

The rest are not supported or have no reported installs.

I wonder if the recommendation is to use address (if they adopt) or create your own setting. Most of the modules using it are already using their own schema and just using the site default as the starting point then using their own setting for reading. So for those sites, they would just change the default to their own config.

Quoting myself from the Address issue #3439726: Consider adopting the core country.default schema:

I am fine with not having or using this setting at all. We only introduced it in the 2.0 release ~4 months ago, to have a fallback when the field has no default value configured, and it was community requested.

Similarly, Commerce uses the site country as a last fallback simply because it's there, the main source of the default country is the Store entity.

We could perhaps just drop the config setting if nobody is really using it. We also have to decide what to do with CountryManager though - should we point people to use Address module and the CountryRepository or something else?

I don't know about the Country repository question, but after reviewing almost all of those modules, I think all of them only used it to set a default on their own country setting, so it would be a matter of just updating mostly one place in the module.

I think the main exception was href_lang_exchange which no longer has a supported release.

Address would be a heavy dependency just to get a default.

Should I create separate tickets to track the country manager question and the country.default schema?

I guess another question is there a world where we deprecate and remove country.default and remove it from regional settings but keep countryManager?

I do see some contrib modules use countryManager, and the issue that brought this back to life was a request to extend the countryManager.