Feature request: add nationality to the territory

[devcovato]

@Schultzer @kipcole9

First of all, thanks for the hard work on i18n and l10n.

Can the territory extend with nationality? I already looked at the project CLDR, but I didn't find it.

[Schultzer]

Thanks, can you tell me a bit more about your use case?

[devcovato]

Sure thing.

It's about identity verification. During the data collection, a person must specify their nationality as reported on their ID document.

As an alternative, do you know where I can download up-to-date data and combine it with territories?

[kipcole9]

You might find cldr_html helpful, especially Cldr.HTML.Territory.select/4 which supports selecting territories by name and returning the territory code. It uses cldr_territories under the covers.

[devcovato]

@kipcole9, thanks for your suggestion, but the front end is React, and I need an API for it.

I already implemented an API following your usage of cldr_territories in the cldr_html library. But still, it doesn't cover the nationality use case. Do you know where I can grab the info and combine the usage of the territory_code to look it up?

Thanks.

[kipcole9]

I'm not quite understanding what you're after, any chance you would consider an api example of what the request would look like, and what the data returned would be?

[devcovato]

Sure thing.

For the country, I have an endpoint like /api/lookup/countries that returns the following JSON:

{
  "data":
    [
      { "code": "AF", "flag": "🇦🇫", "name": "Afghanistan" },
      { "code": "AL", "flag": "🇦🇱", "name": "Albania" },
      { "code": "DZ", "flag": "🇩🇿", "name": "Algeria" },
      { "code": "AS", "flag": "🇦🇸", "name": "American Samoa" },
      { "code": "AD", "flag": "🇦🇩", "name": "Andorra" },
      ...
    ]
}

For the nationalities, I'll have an endpoint like /api/lookup/nationalities that should return the following JSON:

{
  "data":
    [
      { "code": "AF", "name": "Afghan" },
      { "code": "AL", "name": "Albanian" },
      { "code": "DZ", "name": "Algerian" },
      { "code": "AR", "name": "Argentinian" },
      { "code": "AU", "name": "Australian" },
      ...
    ]
}

I hope the endpoints and responses help.

[Schultzer]

Sure thing.

For the country, I have an endpoint like /api/lookup/countries that returns the following JSON:

{

  "data":

    [

      { "code": "AF", "flag": "🇦🇫", "name": "Afghanistan" },

      { "code": "AL", "flag": "🇦🇱", "name": "Albania" },

      { "code": "DZ", "flag": "🇩🇿", "name": "Algeria" },

      { "code": "AS", "flag": "🇦🇸", "name": "American Samoa" },

      { "code": "AD", "flag": "🇦🇩", "name": "Andorra" },

      ...

    ]

}

For the nationalities, I'll have an endpoint like /api/lookup/nationalities that should return the following JSON:

{

  "data":

    [

      { "code": "AF", "name": "Afghan" },

      { "code": "AL", "name": "Albanian" },

      { "code": "DZ", "name": "Algerian" },

      { "code": "AR", "name": "Argentinian" },

      { "code": "AU", "name": "Australian" },

      ...

    ]

}

I hope the endpoints and responses help.

If the nationality is for user consumption then I would recommend to use gettext.

Since there currently is no data like that in CLDR if I remember correctly.

[devcovato]

@Schultzer, you're right about CLDR, as I mentioned in the first message.

Which advantages I will get from using gettext over trans. I mean, I need the nationality localisable and a list of it. I would see gettext for a single entry.

By any chance, do you know any source of reference to grab the nationality? Searching on Google, I found https://www.vocabulary.cl/Basic/Nationalities.htm for reporting the example, but I cannot say if it's reliable.

[Schultzer]

By any chance, do you know any source of reference to grab the nationality? Searching on Google, I found https://www.vocabulary.cl/Basic/Nationalities.htm for reporting the example, but I cannot say if it's reliable.

No I don't, nationality is hard to translate since there can be a lot of synonyms, a good example is Danish, it's a language, pastry and nationality.

Which advantages I will get from using gettext over trans. I mean, I need the nationality localisable and a list of it. I would see gettext for a single entry.

I've never used trans, but I'm sure that would work as well, my main point is, if the nationality is for user consumption then a better tool like gettext would provide more context for the translator to translate, since you would tend to provide the whole sentence, and there can be a lot of pitfalls when dealing with nationality vs territory.

One piece of advise, if this data is mostly used internally to either identify the user origin, locale and etc. then use territory.

[devcovato]

No I don't, nationality is hard to translate since there can be a lot of synonyms, a good example is Danish, it's a language, pastry and nationality.

I didn't know that. Good to know 🙂

I've never used trans, but I'm sure that would work as well, my main point is, if the nationality is for user consumption then a better tool like gettext would provide more context for the translator to translate, since you would tend to provide the whole sentence, and there can be a lot of pitfalls when dealing with nationality vs territory.

I mentioned trans because of this open (at the time of writing) issue by @kipcole9. I need a list of nationalities that provide the same experience as the country list.

One piece of advise, if this data is mostly used internally to either identify the user origin, locale and etc. then use territory.

Thanks for the advice, but the data is not only for internal usage.

[Schultzer]

For this library to support nationalities, changes must be made to the underlying data in CLDR.

[devcovato]

For this library to support nationalities, changes must be made to the underlying data in CLDR.

Are you suggesting opening an issue under CLDR project?

[kipcole9]

He is referring to the https://cldr.Unicode.org data. Which today does not include nationalities. As such it means there is no practical way to implement what you ask.

[kipcole9]

Just to further explain why this is not a straight forward as you might think:

1. Nationality is a political concept and CLDR seeks to avoid political nomenclature. For example, if you are from the territory of Taiwan, are you Taiwanese or Chinese? That simple question has a lot of difficult context. If you're from the Basque region of Spain its very likely you would not wish to be called Spanish but there is no ISO 3166 territory code for the Basque region.
2. Languages have differing numbers of grammatical genders. In English there is only one. So Australian. But French has two so is it going to be australien or australienne? And there are many more complex grammatical genders. There isn't a comprehensive way to know how to automatically determine that.

Therefore I would not be expecting nationalities to be part of the CLDR data collection (but that's an opinion, not a fact).

[devcovato]

@kipcole9, thanks for the clarification and the additional details I wasn't completely aware of.

Anyway, I was referring to https://cldr.unicode.org/. Now I got the confirmation from you.