[L10N] How to conribute / organize country-based validators?

[jausions]

Hello,

How do you suggest we contribute validators that are specific to a country, region, or other localized data? Social security numbers, company registration identifiers, states/regions/provinces come to mind.

Although convenient, having it centralized in this very package does not seem flexible enough or maintainable to me. If you're up for it, sure, but it could become a big burden. A documentation on the topic would be useful, as well a suggested naming convention (packages, namespaces, and/or classes).

I know, PostalCode and SubdivisionCode are already taking an ISO country code. But as the same time, there are NIF (Spain) and PortugueseNif, so this already shows a lack of coordination on the localization topic.

In my opinion, a bunch of country-specific acronyms in the global namespace is not a good direction to follow either, there will obviously be naming conflicts. First come, first served does not sound efficient and using English-first to name such country-specific validators might be confusing to the users of the package (the developers 😉).

Not an easy subject to get right. Let's discuss.

[alganet]

Honestly, this rabbit hole is very deep.

For example, country recognition is an issue. A typical example is Kosovo, so even something as simple as a list of country codes is not exact science. Different users might want different geopolitcal interpretations of this kind of stuff for various reasons (compliance, government requirements, and so on).

Ideally, we would reuse some library that handles those for us, but it's hard to find one that encompasses it all (phone, documents, etc), and using different libraries for each kind of thing might require further work in integrating them holistically into our code.

In that sense, maybe the some assembly required approach is the best way to go (not trying to put all this knowledge into the code itself, but instead leave good options for the users to choose for themselves).

I think @henriquemoody is currently working on the 3.0 launch, which is more of an architectural change. We should probably wait for that to then tackle these localization problems.

We can discuss them though! What kinds of contributions are you talking about regarding L10N?