Myth #4 - Are we having fun yet?

And so the myths go on, and internationalization folks keep chuckling with a look of irony on their faces. Here is Myth #4:

"My product supports Unicode and therefore it's internationalized."

Interesting. Of course, being a myth, it isn't true. Why isn't it true? Doesn't Unicode cover all languages worldwide? Would that it were that easy. In brief, Unicode is a coded character set (see RFC 2130 The Report of the IAB Character Set Workshop), that is, a set of characters associated with a sequence of integers. It defines some character encoding schemes (and forms, but we won't get into that) which take the values associated with the characters and translate them into bytecodes that computers can understand. OK, so what's all this got to do with the myth? The point is that only characters, or parts of characters, are encoded. There is no language information, no locale information, no font information, very little rendering information. What's more, the requirements for supporting Unicode are very lenient. In other words, your product can "support Unicode" and yet only recognize a single character. So, if a product only supports Unicode for its internationalization, not only are you missing information vital to internationalization, but you might not even handle the languages that Unicode covers.

And therein lies the myth. By all means, support Unicode. Support all the currently assigned characters. Unicode is a handy tool for supporting languages around the world. But it is not an internationalization silver bullet panacea elixir cure-all.

Myth #3 - For all Java programmers and their managers

Another couple of days (well, maybe more), another myth:

"The code is in Java and therefore it's internationalized."

C'mon, admit it. How many of you think that? How many of you have actually said that?

Well, it's not true, I'm sorry to say. You see, long, long ago, before there was Java, or even any of the internationalization libraries currently available in C, there was internationalized code. "How could that possibly be?" one wonders, scratching the head in puzzlement. Amazingly enough, even back then, there were people who understood the requirements and designed and coded for them. They had to write a lot more code and make their own custom libraries and tools, but they did it.

It is true that it is much easier to write internationalized code in Java because it provides the tools. But you have to use those tools correctly, or you'll have problems. Use the locale-sensitive functionality available in many classes and methods in java.text and java.util. Make sure you're using i18n friendly classes and methods whatever the package. Take a look at the Java Internationalization site to find out more.

And don't forget to tell the others...

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!

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.