Wednesday March 09, 2005

Humor for internationalization engineers (and others, too)

Allow me to introduce myself. I am I18n G.A.L., and rather than just tell you what that stands for, I challenge you to come up with what that stands for. Creative responses get extra credit. I'm a big fan of creativity, as it's pretty much a requirement for anyone trying to incorporate internationalization into a software organization.

I myself have been in this industry specialty for over 15 years (hey, who knew internationalization has been around that long, and longer?) and in software development for longer than that. But enough of my resume ... or résumé ... or CV, on to the topic at hand. If you're really interested in finding out more about me, there'll be a little of me in everything I write.

What prompted this, my very first blog, is twofold. One, Jonathan Schwartz is a fan of blogs and blogging, and so encourages it. Two, I actually thought of something to write. Recently, a group of us internationalization folks at Sun were preparing a presentation for a conference. The presentation is "Architecting Products for the Global Market" (titled so as to keep the word internationalization out and maybe attract non-internationalization folk, ha ha, but I digress). At the end of the presentation, we have a series of myths. We were reviewing the presentation draft and making corrections when we got to the Myths section. As we read each myth, invariably all of us would chuckle. We can't help it. We've all encountered these myths in some form or another, often stated almost verbatim by some developer or executive.

Hence the subject of my blog. I like to make people laugh, and if by publishing these myths even one more person laughs, well, the world is a better place. But of course I must explain why each one is considered a myth, and since there are quite a few, I thought I'd better make it a series of blogs. And so, without further ado, and in no particular order, here is one of the myths:

"Internationalization means externalizing the user interface so the software can be translated."

Any guffaws? As I said, I've been in i18n* for over 15 years, and I haven't seen this assumption change in that time. So why is it a myth? Think about why people or companies buy software. Do they buy it for the user interface? If someone in Japan sees email software with a Japanese user interface which can only send and receive email in English (US-ASCII), do you think they'd buy it? Of course not. People buy software to do something to their data. If the software doesn't do to their data what they want/expected, then they're not going to buy it. Seems pretty straightforward, but what does this have to do with internationalization? The answer is, internationalization is, first and foremost, adapting the data processing to handle data from all over the world. This is far more essential than enabling the user interface to be translated, and a good deal more difficult. The difficulty lies mostly in the planning and design, or rather, getting it into the planning and design. The implementation is only difficult in getting implementers to learn a few things and then execute with those things in mind. Externalizing messages is a piece of cake (don't forget images and sounds).

Next blog - another myth...
* see Norbert's blog

( Mar 09 2005, 01:00:08 PM PST ) Permalink Comments [5]