Address Formatting for International Mailing?

linuxbaby asks: "Anyone have any advice or wisdom from experience about address formatting for international shipping? I'm starting to doubt the process of asking individual questions of 'name, company, address, city, state, postalcode, country' because of complaints or misunderstandings from places like Ireland (no postalcodes), Germany (postalcode goes before city), Japan and England (many lines of address info needed). Maybe the best approach is to just get the country as a option-select list of 2-character country codes, but leave the other lines wide open ('address1', 'address2', 'address3', 'address4') for the person to fill in as they see fit. The point here is not data mining, but shipping packages as accurately as possible, anywhere in the world. Thoughts?"

wrong place to ask

[datazone]

you need to speak with your shipping company.
They do this for a living. They should be able to give you all the information you need.

ZIP codes

[Dark$ide]

Here in the UK we have a mishmash of numbers and letters for our post codes. So whatever you do, don't try to validate it. RG21 7EJ WC1P 1AA E22 3NL EH22 3NL are all valid. There is nothing that pisses me off more than when an internet site tries to validate post code as 5digits or 5digits hyphen 4dgits. Give me a freeform text box, I'll give you my address in the form that MY post office will understand.

The more general question

[Ankh]

I see this question as a special case of, how should I constrain data supplied by a user?

Other good examples are telephone numbers (not all countries use ten digits, and sometimes you need to add a note like ask for extension 36914 or ask the receptionist to page me, I don't have a direct line), gender (it may surprise you to know that not everyone identifies as male or female, and not everyone is happy with saying which label they want to apply, so make it optional) and even country (is Taiwan a country? It depends who you ask).

You need always to be aware that when a computer model of the external physical world disagrees with the external physical world, it's the model that's inaccurate or wrong, not the external physical world. This sounds pretty obvious, but look at the replies to this article and you'll see suggestions that might make me unable to give me my address.

I've had Web forms ask for my Canadian postal code (by the way, spaces are significant in UK postal codes, and are not in Canadian ones), and then tell me (because they re-used some JacaScript) that a postal code must be five digits. When I tried 00000, the server-side software tried matching that to the billing address of my credit card. As a result I was unable to buy an airline ticket!

In that case I used the 'phone. It took an hour on hold on an 800 number to place the order, because they had to process my credit card by hand, since their computer system didn't allow Canadian customers to fly from US destinations; I wonder how many millions of dollars they had lost before someone took the time to fight this? In the end I got a letter from support saying I should have used the Canadian and not the US Web page, and when I wrote back saying that's what I had done in fact, and please forward this to the programmers, I got a reply saying the bug was fixed.

It's still pretty common to find Web sites whose programmers don't have the concept Some people live outside the US. let alone Some people live in the US but have foreign credit cards, as they are temporary residents.

So when you use the billing address as a "checksum" against the credit card, and find they are different, the right thing to do is to ask the customer for confirmation and then believe the customer.

Keep a record of the information, so that if they complain later you can work out where they asked things to be shipped, and maybe recover. Obviously, your goal is to deliver the package, so you want clear text that is written to be easily understood, not a legal disclaimer in all-caps that's there so you can slither out of the clutches of a disgruntled customer!

The principles are

early quality

It's cheaper and more effective to get good data early on than to correct data later. Using input fields like house number, street name, postal region, county and so forth can help, as can parsing what they type, identifying the various parts, and asking the uer if they are correct.

allow the user to insist

If the user says their postal code is BEWARE OF THE DOG, the Post Office might not agree, but maybe it's the only way they can work out how to get an extra line of text onto the address label. It's probably better to let them do this than to lose them as a customer.

Don't over-model

If you are not going to need the individual address fields later, why are you making the customer type them in a form? Identify the mininum you know you'll need and ask yourself if it's really enough. Large forms aer intimidating, and people may be discouraged or complete them incorrectly because they are overwhelemed. Your database may only have twenty customers today, but when it has half a million addresses, consider the cost of storing an extra dozen fields per customer when you don't need them.

The Real World is Right

Foreign Characters

[packrat0x]

What if it is easier (for the customer and local Post Office) to use foreign characters in the address label? If you are adding free form text fields, you might want to be prepared for Unicode support of various languages.