We have the hooks and the knowledge, so adding this to the @todo list.

Comments

webflo’s picture

webflo commented

I think the most fields does not care about referential integrity. e.g. Delete or disable a country and your other entity with country field is broken.

alan d.’s picture

alan d. commented

I'm thinking of Kosovo (XK is used by some organisations). It could end up as KO, but is for now unassigned.

This is planning ahead for a big event that happens, like two countries consolidating or something like that. It would have to be a single one-off query and not a bulk update script, but it should be doable fairly easily.

However, if it it looks too hard or too complicated, then it is off the cards!

johnv’s picture

johnv
Primary language Dutch
commented

I would just add the new code to the list, and leave the conversion of adresses, countries to the user/admin.
E.g. Netherlands Antillen (AN) does not exist anymore, and is now split up into: BES-eilanden (BQ: Bonaire, Sint Eustatius en Saba), Curaçao (CW), Sint Maarten (SX), Aruba (AW).
However, for practical reasons, my client still uses the old code AN.

alan d.’s picture

alan d. commented
Title: Update fields when a ISO alpha-2 code changes » Handling ISO alpha-2 code changes

Related:

http://en.wikipedia.org/wiki/ISO_3166-3
#1436754: Handle countries that have been removed from the CLDR standard
#2036219: [policy] Inclusion criteria for CLDR territories in CountryManager::getStandardList()