Not every aspect of this is easy, true, but that's no reason not to tackle the ones that are. It's trivial to simply not require a state or a postcode or try to verify a phone no if the user selects a country other than the US.

There should be a library for this. We have libraries that can handle the insanely capricious details of DST for all countries and subnational entities on the planet; we should have no problem providing one list of states and two regular expressions per nation.

(I know it's more or less impossible to reliably catch (e.g.) invalid UK postcodes, but we wouldn't have to. We'd mainly want to catch obvious typos without making things needlessly hard for customers overseas.)

Wufoo is pretty good for pre-made forms. And they advertise that they can do US and International phone, mail and currency fields.

If I wanted to write a blog post which elaborated on all possible internationalization issues, it would become a PhD dissertation and take a year to write.

And then it wouldn't even touch on all the issues.

You have to start somewhere — and let's face it, dealing with the two silly problems I mentioned would get us 80% of the way there.

I gave it a shot of my own. I didn't do all the permutations, and surely left out big swaths that I've never even thought of, but it's a start...

http://hicks-wright.net/blog/stupid-american-website-owners/

This post made me laugh. And I think it is exactly at what I trying to get at when I said that internationalization isn't easy. Nice!

I wrote about Credit Card forms a while back as well.

http://www.jasonlotito.com/programming/what-i-know-about-des...

Anyways, you mention in your post:

"Making something a simple form that is fully internationalized and has useful validation is no where near as easy as they would like us to believe."

It's not easy, but it's not as time consuming and as difficult as you think it is. Getting the phone numbers right doesn't take years. A week is all you need from design to testing, and you are done.

Postal Codes are easy as well, considering their are numerous services that allow you to verify the Postal Code to the address. However, even taking something as simple as the common case, a user from the US entering a 6 digit code has probably made an error, and that solves a common problem.

House numbers and other addresses never presented a significant problem. I've seen more problems with not accepting different encodings then with the actual input.

And why is this important, even if you just want to serve an American audience? Because not every American lives in the US. Consider just the Armed Services, stationed all over the world.

No.

If you don't want to do it, that's fine. But don't complain that it's too much work or not worth it.

Of course I exaggerate in the post, you're right that it'll probably take just a week to get coded up. (Which means three weeks, the way development often goes.)

The question is whether or not that time is well spent, or if I would be better off using that time to improve whatever product/service the form is attached to. Especially when you're on a lean (i.e. startup) budget, the decision becomes pretty clear.

You are throwing a lot of ifs.

If you are providing a service that needs to be programmed. If you are short on funds. If you are only focusing on the US.

The problem isn't that. The problem is this:

When you are providing a service that relies on processing international orders... When you are no longer a startup and earning money... When you want to accept orders from the international community...

If you don't want to support the international market, don't. But if you do, do it right. I've seen it happen: "Launching in Canada!" and they still have a restriction of 5 characters for their Zip Code, or require all numbers.

It's silly. That's what the article is referring to. Wanting to accept international customers but doing it poorly. You'd be better off not offering the service and doing it right then offering it up poorly.

I had to deal with International phone numbers before. Obviously, I had to deal with other issues, too, but the phone number was the important piece. Early on, before PayPal or other services caught on, we created a system to verify credit card users with their telephone. They would enter their telephone number and we'd call them. It was simple.

The problem was with international users. The system was simple: it would call the exact phone number the user entered. This meant we really wanted to get it right the first time. The other problem was that we had a single call center setup out in New York. This meant international callers needed to be called with special country codes and what not.

Now, I feel it's safe to say if you ask someone in Europe to give their phone number, they are going to give their phone number like they would to any of their friends. They aren't going to enter in the country code, and they aren't going to know to prefix it with a special code so that an automated system from the US can call them.

The thing is, it's not fair for me to simply provide them with the requirement "Give us your phone number so we can call you from New York, USA." It really isn't professional.

So, I spent some time (lots of time) reading up and learning about international phone numbers, and coding together a system that went a long way toward fixing this problem. A user could enter in their phone number, and if they didn't enter in a country code, we'd be intelligent about it and add it for them. How did we know where they lived? Two sources: CC Info and the IP address. We could be intelligent and assume the two should mostly match up. Obviously, if the CC address was the US, and the IP was somewhere off in Asia, red flags beyond just the errors for phone numbers would popup (but, even then, you had to be careful!).

I spent a lot of time fine tuning the system, working hard to make sure that a phone number would get through however the user entered it, and we could call. We had a really good success rate with numbers outside the North American norm. Enough that the cases that did fail I couldn't even figure out manually.

I was a bit saddened that it was all for nothing when we eventually removed the 'feature.' and the requirement for a phone number. I understand the reasons, but from a problem solving point of view, it was a lot of fun.

I don't think your assumption is right — if you tell a European to give you his phone number 'just as for SMS messaging', you'll always get the right thing, with the country code, beginning with a '+'.

To send a text message you have to use a full international phone number, so everyone uses them. You can't deliver an SMS message without a full number.

Couple things to consider. First, this was written up in 2003, and expanded on in 2004. I don't know if text messaging is as big then as it is now. Secondly, we weren't sending them a text message. While asking them might not hurt, we didn't want a cell phone. Asking for a phone number "just as for SMS messaging" might be more confusing. I'd rather just ask for the phone number, and fix it myself.

At least, that were my thoughts at the time.

That sounds like a really awesome bit of code to look at. Can you share it?