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

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 ✨ Convert Country code to ISO 3166-1 alpha-3 RTBC 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:

📌 Remove country setting from the installer Fixed
📌 Remove country support from DateFormatter Active

@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

@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.

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 🌱 Consider adopting the core country.default schema Active 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#comment-15544880]:

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.