States seed data: Use Carmen "state" type

[ridem]

Note: This is a tiny suggestion for which I can make a PR.

The states seed data is often irrelevant for most countries. It loads "states" that are not states for most countries, and then sets a states_required flag that doesn't make sense.

E.g.: I'm from France, and the abbreviations have no meaning whatsoever (because we don't have any), it's just been alphabetical order. A, B, C,... On top of it, our regions have never been used for shipping/billing and are outdated in Carmen's database.

I've been looking at the Carmen data, and discovered they were making a distinction between states and other types of geographical divisions. All you have to do is to explicitly require the subregions labeled "state" for a given country, and not all the subregions.
The US and a few other countries (around 10) would end up with states.

So my 2 cents question is:
Why not using carmen_country.subregions.typed('state') instead of carmen_country.subregions? (Solidus seed code here and there)

I know most storefronts end up tweaking and putting their own data, but in Solidus' effort to be more international-friendly, I think this would make sense. On top of it, our spree_states table would be then filled with... well states.

[mamhoff]

I've seen the need for subregions in Italy (where shipping depends on the region) as well as the Netherlands (where Paypal obscurely needs subregion data).

In Italy the states are typed "region" in Carmen, but they're still necessary. I wouldn't go this route, especially as even a large states table is not a big performance issue.

Lastly, the typed method in Carmen is not released yet.

The states_required boolean is used for displaying the state select in address forms, so quite necessary.

[ridem]

Thanks @mamhoff for the feedback.

You're right, I didn't go into the nitty gritty of the countries that were not states but for which the subregion was needed for shipping. And typed is not released, yes.
Are you aware of any database stating whether subregions are needed in address forms for a given country?

[alepore]

A correction about Italy: there are regions but they are not used for shipping. There's another sub-level, provinces, and that's what we need to use for Italy.

[kennyadsl]

Just as a reference, this seems interesting as well: https://github.com/hexorx/countries

[aldesantis]

The subdivisions there seem to make sense for Italy and the US, not sure about other countries. I don't know if there's an easy way to figure out if a data source has the right information for (most of) the entire world...

[elia]

I don't know if there's an easy way to figure out if a data source has the right information for (most of) the entire world...

This looks more or less like the issue with first/last names, reading through https://en.wikipedia.org/wiki/Address it's not easy to cover the whole world.

A better solution would probably be to have an external service like google maps, melissa.com, or one of the many others to correct/normalize the address, than it can at least be consistent within the same store.

At that point we'd probably need to also change a bunch of things within Spree::Address to make it more adaptable to different formats. And Solidus should provide a simple offline adapter and maybe one for google…

cc @seand7565 / #3670

[seand7565]

Unless we go with an external service, I think the only way to handle this accurately is going to be to go through each of the "problem" countries and fix them by hand. I've attempted to do that with Italy with this PR: #3722 - but it does take a lot of effort if you're not already familiar with address requirements for a particular area. The typed Carmen method would help a lot when it's released... Or maybe we can define our own typed method on the state seed.

[kennyadsl]

Closing this in favor of having all the info in a single place: #3842