Slashdot Mirror
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?"
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.
Its spelt "L-I-N-U-X", but pronunced as "Free Beer"
Use a multiline input box and don't try to manually split it up into various fields. Let the user do that. Maybe stick with a dropdown box for Country is all.
ciao
FRANK'S COMPULSIVE GUIDE TO POSTAL ADDRESSES is probably the best resource you're going to find on the topic - it covers every continent and most countries, with details on postcodes, street addresses and more. Very geeky, but also highly useful.
There's nothing more annoying than forms that require you to enter your address in a specific way that doesn't fit for that particular company. If you're shipping to only one country, that's fine, but otherwise:
What's wrong with just letting the user enter the address in a freeform text field? The user probably knows what his own address is, and can write it in a form that the local post office can deliver to. Just include a dropdown box for the country, and that should be all there's to it.
Google is your friend. I found a good example quickly, about the fourth entry (one of the first three is the result of the submitter having asked this exact question on oreillynet.com):
g i/up
There's an example of what looks like a good solution used at https://www.theperlreview.com/cgi-bin/subscribe.c
They make some fields required (name and country would make sense) and others (such as state) are marked "required for some countries", with a big freeform text area marked "Mailing label" with the text "International subscribers: You can tell us what your mailing label should be, following your country's address format".
This seems a fair way of doing so, and that which fails your parser's ability to determine (ie, countries for which you don't know the convention) can be checked manually, with an additional contact-the-customer-and-verify step if you are really unsure.
As you contact customers and learn more about their specific formatting needs, update your parser -- use it to check the freeform address format, and perhaps warn the user if it doesn't seem to be valid (but allow them to continue anyways).
Somebody get that guy an ambulance!
Try the Universal Postal Union, specifically documents they have on properly addressing international addresses.
Also, this looks interesting: International Address Standard UPU S42-1
(BTW, I know nothing about this stuff, but I found it via Wikipedia, which these days is proving itself more useful than Google.)
_______
2B1ASK1
Try a UPS Store if you have one near you. The have software that takes the guesswork out of shipping Internationally. Also, you're not necessarily limited to shipping with UPS. Some stores also ship DHL and FedEx.
Co-founder and designer at Music Nearby: http://musicnearby.com
You can get the addressing standard and the worldwide database from the Universal Postal Union.
Zip codes, in countries that use them, are checksums. You need them in a separate field because you should check with the post office of that country to make sure it matches with the city. If the zip code and city/state do not match up you should make me verify the address. If the two match up odds are the address is good enough to get things to the right person.
If you can get someone's mail to the right zip code the post office doesn't really need the rest of the address, just the name. (Though it is much easier to deal with full addresses, so only try this when other options fail) This doesn't work so well if you name is common, but if you name is slightly obscure (which is most names, since obscure only means nobody else in town shares it) you are probably the only one in town with that name, and they can figure out where you live.
In short, the name and street address are checksums to each other, the local post office will notice a mismatch and try to correct them if they can. City/state, and zip are checksums to each other, and you should check them to be sure you get to the right town.
Now of course each country is different, but for most there is some variation of the above that you should use to verify the address is likely to be correct.
Of course checksum isn't the right term. There is math involved. However the concept is the same.
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.
Sigs. We don't need no steenking sigs.
The Universal Postal Union has been around since 1874, ensuring that post can be mailed around the world without issue.
The UPU has 190 member countries, and those countries submit mailing information to the UPU, making it the most extensive repository of postal information on earth.
If you are looking for information on addresses, I would start (and probably stop) with the UPU.
Actually while it's customary to have many lines of address in England, all that is actually required is the house number, and the post-code. Everything else can be derived from those two. Having all the extra info just makes sure if you get the post-code wrong, it will still get to the destination.
"When I grow up, I want to be a weirdo"
This has to be the most worthless topic I have every seen.
"Hey, I'm too much of a moron to go to the UPS, Fedex, or USPS (etc) to figure this out..."
I ask them to send me an email with their name and address formatted exactly as is their custom.
"Eve of Destruction", it's not just for old hippies anymore...
How about localized input pages? No one says you have to use the same input page for every country (and it's unlikely you send to more than a 6 or 8 that use different formats), you know that is is possible to tell where visitors come from. How you combine that data into one table is up to you, but shouldn't be a problem.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
Hey, it's the CDBaby dude! Rock on.
I ship CDs and other things overseas, not a LOT but maybe 2-3 pieces per week.
I've discovered that the foreign post offices don't really care that much. Not as much as the foreign buyers would have you believe (I've never had a problem shipping to Germany for instance using the "american" address layout). The mail goes through as long as all the info is there, somewhere. Some Asian post offices like to see the address in both English and the native language though (good luck with that one).
Just have a country pull-down then 3 address lines (folks with more lines can combine). At least one address line should be filled out. Also have City, State, Postal Code, and make them all optional. Yeah, what does city/state mean for some folks, but they can manage.
I know, you're a business and you don't want to have people complaining all the time, or force people to jam their address into the wrong box. But honestly I don't know how you could please everybody without customizing the address form for different countries (and adding a "please choose your country" step or using dynamic HTML or otherwise cluttering up the checkout process).
I think just having free-form address fields will actually confuse people, who are used to having labeled fields.
I ordered a Firefox T-shirt from the Mozilla Store with international shipping to China. I filled out the shipping address in Chinese characters, but a few days later they sent me an email that said the address just showed up as a bunch of question marks in their software. Thankfully they agreed to let me email them the address as a gif image and they printed out the gif and stuck it on the package. I received the shipment about ten days later.
If you provide the option of international shipping you should really make sure your software works with international character sets.
Manufacture in China
England (many lines of address info needed).
What? You need:
Name
House number
Post code
To get something to somebody. It's usually a good idea to include a bit of redundancy, most people use:
Name
House number Road Name
City
Post Code
I think frankly your best bet here is to be freeform. They know best how their addresses are written. So long as the country goes last, to get the parcel from your country out to the appropriate country, the rest of the address should be written to their custom so that their postal service will be most likely to deliver it.
I've seen all the things you describe - stuff like "90167 Bucharest" where the postcode precedes the city - and you're just not going to cope with all that if you try and enforce a complex system of validation.
Our database just has Address1-Address5 (use as many or as few as you want), Postcode (this can be blank), Country (this can't be).
When we tried entering a lot of addresses into the address book software of a certain well-known courier company, we ran into all sorts of problems. It would keep insisting on postcodes where they weren't appropriate, and so on. It's just more hassle than it's worth, and creates more problems (with literally not being able to enter what you know is correct) than it solves (stopping accidental bad data entry).
I can't wait until we just give our coordinates as an address.
beam pkg via UPS to 42.3750 N, 71.1060 W -THX
As someone that born/lives in Ireland its extremnely annoying when I order stuff on-line and even when I select Ireland I am still prompted to enter a postcode.
This generally ends up being N/A or 12345, surely forms should forgo the postcode once Ireland is selected?
The nearest thing Ireland has to a postcode is Dublin 4 or Dublin 1.
"WebTV: bringing the Internet into the shallow end of the gene pool since 1995" - Martin Bishop
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
Live barefoot!
free engravings/woodcuts
One table keeps track of countries (3-Digit/2-Digit/2-Character ISO 3166 code, country name) along with a code for address format. I tend to set up a 1 address format per country even if multiple countries use the same format.
The address format is displayed as a series of rows in a grid and lets you build an ordered list of fields that make up the address. Here are the choices:
Address
Postal (Zip) Code
City
County
State
Country
Street Name
Once you've selected you can select a separator and a newline (flag). Here's the format for a US address:
Address[Newline=Y]
City[Newline=N][Separator=", "]
State[Newline=N][Separator=" "]
Zip[ ][NewLine=Y]
Country[NewLine=N]
What I like about this setup is that the data model is consistent. What I don't expecially like but can live with is that you need a supporting code routine to read/write addresses - you can't just grab them from the table and expect them to look perfect.
From the UI, the application lets you enter the first two lines of the address then tab to the zip field and enter a postal code. There's a supporting postal code that has the city/state/county/country info that will populate the rest of the fields (so it's less typing) along with a textarea that displays the entire address as it will print.
(I'm happy to be of any help later too :-)
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.
227-3517
They got the region (state) wrong. Barcelona is not just a city, its also a region (equivalent to a state in Spain). Someone decided that it must be my city (It's not). They seem to have no way of handling the neighborhood (subset of a city but bigger than a street) and of course they didn't put the zip in the right place (before the city).
It took two and a half weeks and several calls to FedEx to sort this out. Travelocity's customer service absolutely refused to take ownership of the problem. They seem to think that they know my address better than I do. Kudos to those of you that recoginize that the US doesn't set the standard for international addressing.
Needless to say, I tell most of the expats I meet to avoid Travelocity like the plague . . .
Which you are discussion is very difficult to do using relational databases. The whole theory of associative databases is to allow data usually in a particular form but to allow for exceptions. Its an entirely different theory of datamodeling and needs to be introduced at the earliest stages of design.
That's a lot to ask for a small percentage of the market. It may not be the case for most business that, "'better to let them do this than to lose them as a customer" it might just be better to lose them as a customer in terms of profits.
OTOH for people who just need to have flexability associative rather than relational models give one most of the advantages of a rigid relational system with requiring rigidity.
I'm working outside the US at the moment, and my offical address is (in the local language) something along the lines of "In this district of this town, take the road to the Monistary, turn left when you see a sign saying such and such, and look for so and so; it's building #1."
--MarkusQ
No, we will be checking that your billing address
matches the shipping address. Sorry. Shipping to
Romania or Nigeria is also a no-go.
[Company Name]
[c/o] First & LastName
StreetName Number[-Appartment/Suite]
COUNTRYCODE PostalCode, City
Country
AFAIK the internationally accepted way of putting a country code in is as part of, ie preceding, the postalcode. I just append country for the casual reader, such as the postman.
Which means my PC in Switzerland is:
CH [pc], Zurich
and my PC in The Netherlands is:
NL [pc], Amsterdam
'I am become Shiva, destroyer of worlds'
Free-form text entry box.
The user knows how to write an address that will end up at their doorstep. You don't need to hold their hands (or step on them) with City, State, Zip, etc. fields.
Also, will a human being review the label before shipment anyway? Will you get a phone number or e-mail address so you can catch mistakes that slip through? That remains the best way to make sure you get it right.
I find it extremely irritating to pick a country out of a list of all the countries in the world. Instead of a drop-down list, it would be better to let them type the country name and correct the typos and common misspellings. (When you do so, you might want to give the user another chance to check for other problems.) Are your customers really equally likely to be in any of the world's countries?
Finally, the USPS didn't like the format of many of the addresses in my Palm Pilot when I tried out Endicia a few months ago. I am actually pretty careful about these things, and have done bulk mail encoding before. But the post office wants addresses to look as ugly and institutional as possible. So if you used the USPS's pretty extensive checks, you would be irritating your customers who like to get their mail addressed to "One Broadway" instead of 1 BROADWAY ST or "451 Second St., Apartment #31" instead of 451 2ND ST UNIT 31. I would rather address mail to my customers using the way they want to see their addresses, not how the post office computers say they should look.