Internationalization (a.k.a. i18n) is the process of making software readily adaptable for use in other countries and languages. It involves more than just putting menus and dialog labels into string tables. The differences in how people of other cultures interact with computers can be surprising. Something as subtle as where text is placed on the screen may be important in some locales. I18n, then, is also a mindset: an awareness, perhaps even an appreciation, for the diversity of human communication.
By all indications, the world continues to shrink (metaphorically) at an ever faster rate, and i18n will become extremely important to any software company that competes in the global marketplace — which might be your company, whether it wants to play or not. And yet, if you scanned the software trade press, you'd never guess anyone had heard of i18n. For example, a search through Dr. Dobb's Journal reveals a total of one i18n article over the past year ("The Java Internationization API," January 1998). And if it weren't for P.J. Plauger's exhaustive treatment of the C++ Standard Library (which includes i18n features) CUJ would net about the same paucity of i18n articles. Kinda makes you wonder what's going on — or isn't.
Well, I doubt this means no one in our industry cares about i18n. If it does, we could all be in deep trouble. What it probably means is that good i18n articles are pretty hard to write. As a software problem, i18n is similar to cross-platform development: messy, fragmented, ever-changing. If you read Amal Shah and Hong Xiao's "Using Shared Libraries Across Platforms" in this issue, you'll see what kind of jungle the cross-platform developer wanders into. The same sorts of hardships await the poor bloke assigned to internationalize a chunk of code.
Which brings me to a question: when should i18n be included in the software development process? The easy answer is, from the very beginning. But wait: how much "stuff" can a software developer reasonably be expected to incorporate in his code on the first pass? Already there is pressure on the developer to make his code portable, thread-safe, exception-safe — how many more -safes can we pile on top before coding grinds to a halt?
I don't know, but I believe the vast majority of shops take the "just get it working first" approach. If that's you, there are a handful of tools that can help you identify i18n trouble spots in your code. Some tools are occasionally listed in our magazine (see Uniscape's and Accent's in this month's issue) and in our website's Developer Tools section (http://www.cuj.com/tool). Those are definitely worth checking into, but we're always interested in "homebrew" tools as well. Anyone who can help unravel the i18n knot, please send me an email at mbriand@mfi.com.
Peut-être vous?
Marc Briand
Editor-in-Chief