Official name for Hong Kong - HK about node-i18n-iso-countries

[koenig-dominik]

We have fixed our particular issue by just replacing Hong Kong with China.

As it seems that the official names of most countries are not correct, it would probably be better to tackle that problem in a different issue.

[michaelwittig]

According to https://www.iso.org/obp/ui/#iso:code:3166:HK
the full name is: the Hong Kong Special Administrative Region of China
and the short name is: Hong Kong

So in the en.json file we could add:

"HK": ["the Hong Kong Special Administrative Region of China", "Hong Kong"],

To me, the official name seems to be quiet long as well. I personally never saw this name in use.

The name types are somewhat random. For me, official is what ISO says. Alias is what "western people" use.

I wonder if your issue is related to the fact that this lib is used by "non western" people as well and not everyone agrees on the same names for all countries. My idea (and it might not make sense in your case) is that we could add a new type to reflect the need for names used in China (and possible other areas in the future). My only concern here is that we quickly end up in a lot of discussions around country names.

[koenig-dominik]

We have that issue mainly because we have plants all over the world, also in China and there the government doesn't want to see "misleading" terms about their territory.

From my experience the Chinese government doesn't want to see just "Hong Kong" anywhere.
As I am from Germany I also don't know whats actually correct and can only refer to wikipedia.
As i see it Hong Kong was independent before and there were protests to have it independent again and china wants to make it clear that it is part of china.

My chinese colleagues want this to be changed to "China Hong Kong", they say it can be "misinterpreted in China" (even though we labelled the field "Country / Region" to prevent other issues with more contested parts of the world)

If you don't want your library to be in that confusing mess of territorial naming conflicts, I can also just implement a workaround :)

[michaelwittig]

I see. We get this request often. So I guess we could also implement it here to solve the issue.
Would you be happy with a new types china_official and china_alias or something?
For countries where china_official is not defined, we fall back to official.
For countries where china_alias is not defined, we fallback to alias.

I can open a PR to implement this. I Also want to get rid of the array structure in the JSON files.
From:

"HK": ["the Hong Kong Special Administrative Region of China", "Hong Kong"],

to

"HK": [{
  "official": "the Hong Kong Special Administrative Region of China",
  "alias": "Hong Kong",
  "china_alias": "China Hong Kong"
}],

[koenig-dominik]

Somewhat off-topic:

Then what would you do for GB?
It has also 3 names defined but only 2 are actually "named"
"GB": ["United Kingdom", "UK", "Great Britain"],

For me this seems also a bit wrong as the official name for GB is "the United Kingdom of Great Britain and Northern Ireland"

That's why i proposed a "common" country name by which a normal person would call it.

For the China problem: maybe add another field like "parentCountryCode": "CN" like this you could implement a method to get the combined name of the parent and the normal name.
This would make it possible for anyone to choose whether they want to show the parent country or not.

Just a note to your plan to move away from arrays: this would probably bloat the bundle size for use in client side builds.
Maybe create a js file instead of json, this could theoretically be optimized by a bundler. (This would probably be a breaking change). There is a json minimizer for webpack, but that is probably not included in 99% of projects.

[koenig-dominik]

Just another tought: The parent country stuff could actually also be handled in a different package as the data does not really have anything to do with the names itself.

[michaelwittig]

The 3rd entry of GB is only accessible if you ask for all names (see https://github.com/michaelwittig/node-i18n-iso-countries/blob/master/index.js#L68-L90). I guess it's kind of a data bug. There shouldn't be more than 2 entries.

I agree that the array approach leads to smaller JSON files compared to objects.

We don't really have very strong definitions and names are changing from time to time until someone discovers that they are too long etc. I still believe that adding the type common is not related to the fact that people from China use different names for countries like Hong Kong and Taiwan.

We might need an official (aka ISO official), common, and alias name. But this might lead to a 4th, 5th type in the future. Not sure if we all can agree on the same name for a country :)
When we started this lib it seemed to be a simple problem: Translate country names. But as we learned, it is not as simple :D

The whole package size is a problem. This lib was created in with two languages (de, en) and npm was used for backend stuff only. There was some work from contributors to tackle this issue. E.g., You need to register languages before you can use them today. But it still seems to be a problem to properly use the lib in the frontend (aka with only the files bundled that are needed). If I would create this library today, it would look different. Maybe each language could be a package. But I'm also no longer in the game of JS development. I still happily maintain the lib (merge PR, releases) because it is used by so many people. But I'm not up-to-date to the latest frontend/backend/JS/TS/webpack/esbuild/... discussions in the community.

[lvl99]

FWIW I work at a company which is part of a global conglomerate that recommends using "Hong Kong SAR" instead of "Hong Kong". Same goes for Macao ("Macao SAR"). We're also advised to say "Country/Region" instead of just "Country". Some other affiliated companies part of the group have been criticised for not acknowledging certain Chinese territories as being territories/regions rather than countries.