refactor: Review and update country reference data

[jpye-finch]

Description

Our country list is out of date. Having last been updated 5 years ago.

This ticket is to review and update. Plus to consider having a list of:

• Nationalities > Nationality
• Countries > Addresses

https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/664133/CH_Nationality_List_20171130_v1.csv/preview

Link to Slack thread: https://opencrvsworkspace.slack.com/archives/GHCFF9M6X/p1678881179834889

[rikukissa]

Labeling as medium priority. Keeping these reference data up to date should be routine maintenance

[naftis]

https://github.com/OpenBookPrices/country-data
The country-data package we're using is outdated, currencies and countries have changed during the years. Needs to be replaced altogether.

[Siyasanga]

Hi @jpye-finch @naftis & @rikukissa I found these alternatives to the country-data package that we are currently using, since country-data was kind of a all in one package with all the info about a country including currency and name I wasn't sure if the new package we go with must have those(currency, Internationalised name, languages ... etc) or we just need to be able to map their iso-codes(ISO 3166-1 alpha 2 & ISO 3166-1 alpha 3) to the country's English name?

For instance, the convertToMSISDN() and countryAlpha3toAlpha2() use both iso-codes in their logic

I've asked chatGpt to write a quick comparison of the different alternatives that we can use and here is what I got:

Country-data package alts:

• i18n-iso-countries
  • Content: Provides standardised country codes (ISO 3166-1) and localised country names in multiple languages.
  • Similarity to country-data: It has a similar structure to country-data but is limited to ISO codes and names without extra data like calling codes or currency info.
  • Use Case: Great for projects needing ISO codes and multilingual support.
  • Maintenance: Actively maintained with a simple API.
• countries-and-timezones
  • Content: Provides country information with timezone data, including UTC offsets and daylight saving time (DST) support. It also includes limited extra data, like country codes.
  • Similarity to country-data: If timezones are a key aspect of your project, this is a close match, though it lacks more general data like currencies.
  • Use Case: Best if time zones are essential, and only basic country data is needed.
  • Maintenance: Actively maintained and useful for timezone-centric projects.
• world-countries
  • Content: Offers a rich dataset, including ISO codes, calling codes, currency codes, and geographical details.
  • Similarity to country-data: The closest match, as it includes a broader array of country data similar to country-data, such as calling codes and currency.
  • Use Case: Good for projects requiring multiple types of country data beyond just codes and names.
  • Maintenance: Actively maintained, with a JSON format that’s straightforward to use.

Do you guys a preference from this list? I personally think going with the world-countries package is the best solution since it's the one that is very similar to the country-data package we are trying to replace by providing extensive information about a country even though we might not use all the info provided.

[Zangetsu101]

@Siyasanga Thanks for looking into these packages, I agree with you on this. Let's go with the world-countries

[naftis]

The bundle sizes:

• world-countries 625KB minified (114KB gzip)
• i18n-iso-countries 19KB minified (6.6KB gzip)
• countries-and-timezones 35KB minified (11KB gzip)

Be mindful not to have this as a frontend dependency (at least in the case of world-countries) but rather pass the minimum set to the client.

[rikukissa]

Even with the smallest of those,

...and localised country names in multiple languages

Sounds quite redundant as we will still have to have all of those names in our translation files