Ok, this one is a pet peeve of mine, I’ll admit it. First a quick bit a definition:

Internationalization (I18N in some geeky circles): This is the design of software to be able to operate in a global context. This includes things like:

• Not hard coding text strings into functions. Better yet, storing them in an external file at least at the source level.
• Ensuring that other character code pages will work. Unicode has complexity tradeoffs sometimes but at least support all of the normal western ‘funky’ characters like umlauts and tildes etc.
• Allowing numbers and dates to be stored and calculated independently from the display format. Quick, how much is “342.098” in Germany? (It is three hundred thousand something) When is 5.12.08 in much of the world? (It isn’t last May)

Localiation (L10N in the same cirles): This is actually doing the hard (i.e. costly) work of making the software look local to the user.

• Translating the text strings to another language
• Translating help files and documents
• Changing or adding features to represent the use models in another country (i.e. VAT taxes instead of sales taxes)

Now the simple advice: Just do it now. You can leave the more expensive localization work for later but design for internationalization from the beginning.

In my opinion, not internationalizing software from the get go is a dumb, amateurish, mistake with very few exceptions. Sure, if you are writing software to sell only to Wisconsin farmers, you might not ever have a reason to need it. But for nearly all enterprise and consumer software and even most consumer web sites, eventually you will want to sell it in some other country (even neighborly Canada expects French and English for public apps) or even to an ESL market here in the US.

“Well, I can just take care of it then” No, you don’t want to do that.

1. It will forever be the ‘fourth thing’ on your priority list where only the top three get done.
2. Doing it later costs WAY more in time and resources. If you try to do it years down the road, the developers who hard coded the obscure bits of functionality are long gone and the new guys will spend forever debugging it and eventually re-writing huge portions. We aren’t talking about XP programming revs here but reworked whole releases for no visible gain to the customers. Yikes.
3. It will seem too expensive and not seem like a good bet. Beyond the cost issues in #2 above, you will often find a chicken and egg problem. It’s so expensive to do, management needs to see revenue to justify it. But, because it doesn’t work in that market you don’t have any market growth to point at as a clear justification. Use as an educated guess that it will cost you an extra 5% to do it up front. But it could burn an entire release cycle to ‘fix’ things later.

Are you convinced yet? No? Ok, let me throw the last pitch: If you don’t, you’ll look like a dummy.

• When your competitor launches in 10 new markets and your colleagues want to know why you aren’t doing it, do you want to tell them that it will cost 6 months of pain to enable it?
• Take a look at nearly all software written outside the USA. Rarely will you see mono-location designs. This will make it hard for you to get a foothold even with the bleeding edge customers who will tolerate English language software for a while to get the cool features you have.