isLocale doesn't work anymore (returns true on wrong locals)

[sbatezat]

Describe the bug
I was using isLocale to check locale string like "en-US" or "fr-CA" and so on.
Everything was working fine on 13.9.0, but today I'm trying to upgrade to validator 13.11.0 and my unit tests are failing.

Examples
validator.isLocale("french"), validator.isLocale("frenchy") returns true in validator 13.11.0, returns false on validator 13.9.0

[WikiRik]

This is due to #2189
With that, can you figure out why it accepts those strings and what we need to change to fix it if that behaviour is incorrect?

[sbatezat]

I'm not an expert on regexp.
But your 'language' rule seems way too permissive :

const language = (([a-zA-Z]{2,3}(-${extlang})?)|([a-zA-Z]{5,8}));

I admire the fact you want to manage these locales with regexp, but I've got the feeling rules are too complex to handle it like that. Result is that isLocale returns true for many strings that are not locale at all...

Storing all locales (at least some part to build them) in an array could seem ugly and absurd at first, but well, it handles every specific rules and edge cases... that you don't manage with regexp.

[manojmula]

as mentioned by @WikiRik , it seems that the #2189 changes seem to have included language with generic language acceptance, as you mentioned, so if this need to be changed, will be happy to help regarding this. @sbatezat

[sbatezat]

Obviously it needs to be changed.
To fix the fact isLocal() calls was not working with every good string (#2100) you made it working for almost every bad string...

[efbgirotto]

Language tags are described in RFC4647 and locale tags are described in RFC5646. I don't think they can coexist in same isLocale validation function.