chore(README): add the supported locales for various validators

[profnandaa]

e.g. isPassportNumber, etc.

[tux-tn]

@profnandaa i was thinking about fixing it the other day and i had a little concern, should we rename countryCode to locale to have consistent naming across the lib?

[profnandaa]

@tux-tn -- sure, standardization will be great. However, we will have backward compatibility to deal with.

[tux-tn]

@profnandaa can i work on a PR where we can accept a string and an array as a parameter and rename it to locale in the documentation?

[profnandaa]

@tux-tn -- can give an example?

[jmartin4563]

@profnandaa: It looks like the documentation side of things has already been handled from looking at the README, so is this issue now for removing instances of countryCode as parameter names and replacing them with locale?

From doing a quick search through the code base, it looks like we could rename the remaining parameters without causing backwards compatibility issues, and I'll be happy to submit a PR if this is true

[profnandaa]

@jmartin4563 -- sure, the issue will be mainly dealing with backward compatibility. I'm more of the idea that we go for CC for stuff that's territorial, and I know this contradicts with what we've done already with stuff like PostalCode, PhoneNumber, etc... what would be your suggestion?

[firlus]

@profnandaa Started work on adding 'DE' locale for isTaxID.

[boonya]

I realised that you use a combination of ISO 639-1 + ISO 3166-1 alpha-2 to identify locale. And I think it's weird because in the majority of validators you do not need to identify language + country. Country code is enough imo. So, yes, it would be good to use just a country code instead of language + country.

For example in a isTaxID validator I have implemented validation for Canadian SIN. Canada is bilingual country so I have added the same validation for two different locales -> fr_CA & en_CA. Thats weird.

My suggestion is to use ISO 3166-1 alpha-2. And one more thing... I believe that would be really useful to combine every supported country code in an enum like object.

e.g.

export default {
    CA: 'CA',
    PL: 'PL',
    UA: 'UA',
    US: 'US',
    TS: 'TS',
};

Later, the enumeration can be reused in each validator, which depends on the country code. Like below:

import isTaxID from 'validator/lib/isTaxID';
import COUNTRIES from 'validator/lib/COUNTRIES';

isTaxID('value to validate', COUNTRIES.CA)

I could start to work on PoC to show a vision

[l4b4r4b4b4]

Would like to pick up on that topic. Would be great to have it set for all countries in major economic regions. Would be especially great to have EU set complete. Would start with adding Germany to isIdentityCard. Any concerns on standardizing for country code only? This seems to be a good collection of Regular Expressions for European Personal Identity.

[boonya]

I would like to see any thoughts on my comment above.

[WikiRik]

I agree that we should choose either ISO 639-1 or ISO 3166-1 alpha-2 to be consistent throughout the project. I would however say that because some validators benefit from having language + country defined I would use ISO 639-1.

What we could add is a helper function that parses the country for the validators that do not need the language. So some validators would use fr_CA and en_CA and others can use CA. The helper function will then allow both fr_CA and en_CA to be treated as CA (and maybe we can even allow both ISO 3166-1 alpha-2 and ISO 639-1 to be used interchangably for backwards compatibility).

So in short; prefer ISO 639-1 but also allow ISO 3166-1 alpha-2 as fallback and make a helper function to parse ISO 639-1 to ISO 3166-1 alpha-2 to make validators shorter that do not require the language

I do not really have any opinions on the enum like object but a PoC would be nice. Did you start on that already?

[boonya]

but a PoC would be nice. Did you start on that already?

No I didn't. I want to know opinions on that to not work on something that is not needed

[DanneelsSophie]

Is the subject still in progress? or is it closed?

[WikiRik]

As far as I know no work on this has been done since my previous comment. I still agree with what I said there