MultiLingual | Volume 87 | 3 / 2007 | Page 5
Change your encoding, change your company
by Adam Asnes
It’s a mark of greatness when a company can effectively develop products and compete worldwide. Yet software
internationalization is often one of life’s painful forgotten labors that suddenly grabs intense and panicked attention as it
leaps out and grinds globalization plans to a halt. You’d think that enabling technology so that it’s easily leveraged for any
market opportunity would be a pretty glamorous and exciting pursuit. With rare exception, the first, second or twentieth-
plus time a company does this is still a painful effort that holds back global top-line revenue opportunities.
Of course, it doesn’t have to be this way — but when you look at the nature of how software is actually developed and
comes to market, unless internationalization is a very firm requirement at the project’s outset, it shouldn’t be a surprise
that it gets overlooked until it’s an ugly problem. This is not one of those “if only everyone always internationalized”
diatribes. I hope to describe the business issues around internationalization, including the fundamentals of what it does
for a company, the competitive implications, funding the effort, and managing and maintaining global market
requirements.
One point I want to get beyond quickly is the belief that you can just force your translations without internationalizing
software first. I get asked about this a few times per month, often by managers who are even in the localization business.
Incidentally, developers never ask this.
In the case of some limited products, it may be possible not to internationalize, but it’s a bad idea anyway. You risk having
a product that doesn’t work or works poorly. In the best scenario, your software can’t be leveraged across markets or
even maintained from release to release. Not internationalizing is like throwing lots of money and resources away for an
inferior result which has no future. For complex applications, it’s simply not going to work.