Monday, September 18, 2006

Myth #2 - Just when you thought it was safe...

And so on to Myth #2 (for some background see my previous blog, "Republishing the Myths")
"Translators choose the best phrase in the target language."
Uh-huh. I can hear the translators rolling on the floor laughing (or ROTFL, for those who just love initialisms). Note, I am not disparaging the work of translators - they are professionals and most do a great job considering the limited context they are given. But bear in mind that:
1. They only have the context that you give them.
2. They get paid by the word, or sometimes by the project.
Therefore, given a word to translate, they don't sit there and ponder the literary nuances ... "Hmm, break, what could the programmer mean by this? Is it a break in the text? A break in the execution of the program? Something to cause the program to crash? Or could it refer to the programmer's innermost desire to break free from the shackles of structured code, moving on to more creative and fluid expressions of the starving software engineering soul?" ... No, this doesn't happen, translators would starve if they did this. Why should you care? Well, if you write any text that may possibly be seen by an external user, that is, error messages, help messages, and the like, then think carefully about the text you use. If your product has a glossary (hey, it could happen), use it. Make a comment in the resource file to give the translator some context. Keep like messages together. Use standard English (or German or Japanese or whatever language you're writing in) and stay away from jargon, slang, and local terms and phrases. The translators want to do a good job; give them that opportunity.

Next blog, Myth #3!

Sunday, September 17, 2006

Beginning again with Myth #1

And so, here it is, and still believed, Myth #1:
"Internationalization means externalizing the user interface so the software can be translated."
I've been in i18n* for over 25 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).

* see Norbert's blog

Republishing the internationalization myths - or - Humor for internationalization engineers

My old blog at Sun is long gone, so my Internationalization Myths series is now here, where I can keep an eye on them. I've even published a new one recently (2015), and have a couple more up my sleeve when I can find the time.

For those of you who want to see the original intro to the Myths series, I have decided to re-post it here:

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, you can find out or you can guess - 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 25 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 (then CEO of Sun Microsystems, Inc.) 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.