michaelwittig / node-i18n-iso-countries

i18n for ISO 3166-1 country codes
MIT License
816 stars 262 forks source link

Proposal: make conversion with toAlpha2 in getName() optional #322

Closed fatchan closed 1 year ago

fatchan commented 1 year ago

Hi, I am using i18n-iso-countries and had a problem with the call to toAlpha2 in getName here: https://github.com/michaelwittig/node-i18n-iso-countries/blob/1591b772ffd32566ce2bb0eff33fb585c316e019/index.js#L224

To explain, I am registering locales, but rather an register a new locale I am actually loading the existing locales and adding some additional non-standard country codes. For reference, here is what I am doing: https://gitgud.io/fatchan/jschan/-/blob/master/lib/misc/countries.js

There are some non-standard "country codes", for example "EU" for "Europe" and "T1" for "Tor Exit Node" (Cloudflare assigns T1 for Tor exits). However, I am also adding a few that are 3 and even 4 letter (I don't need them to be any official/standard or recognised code). This causes a problem because when I call getName with a 3 letter code, toAlpha2 checks if the length === 3 and will try and convert the code from alpha3->alpha2 here: https://github.com/michaelwittig/node-i18n-iso-countries/blob/1591b772ffd32566ce2bb0eff33fb585c316e019/index.js#L202 ...and obviously there is no 3->2 mapping for my non-standard codes, so the return is undefined.

(This is also incongruent with getNames because it will return the list with the 3 letter codes, but you cannot call getName on them)

Therfore, would you be open to accepting a PR (I will write) to add a new option to GetNameOptions perhaps named "toAlpha2" that defaults to true, but when set to false would not call toAlpha2 in getName?

Kind regards.

michaelwittig commented 1 year ago

This lib is about ISO-3166-1 which clearly defines alpha2, alpha3 and numeric codes "The country codes can be represented either as a two-letter code (alpha-2) which is recommended as the general-purpose code, a three-letter code (alpha-3) which is more closely related to the country name and a three-digit numeric code (numeric-3) which can be useful if you need to avoid using Latin script."

If your alpha 2 code is not a two-letter-code I suggest to do something against it :)

fatchan commented 1 year ago

Are you suggesting I can add extra non-standard codes, but I should at least make them 2 letters to be "compatible"?

If so, should there not be an error when trying to register my locale with these "invalid" 3-4 character custom codes?

Should they be returned in getNames, but not be accessible through getName?

You are rejecting a suggestion to allow the library to be more flexible for more custom use cases without affecting existing functionality, and the offer to make this (very minor, simple) change for you.

Anyway, I just added extra codes to the alpha3 map to bypass this behaviour. Not what I wanted, but I'd rather not maintain a fork. e.g.

countries.getAlpha3Codes()['ABC'] = 'Something custom';
//Now you can call getName() with a non-standard country code in a custom registered locale.