Tuesday March 22, 2005

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.

( Mar 22 2005, 03:30:59 PM PST ) Permalink

Friday March 18, 2005

Currency revaluations, revelations, reflections

Another quick break from the "Internationalization Myths" series to talk about 2 currency revaluations: the Turkish lira and the Azerbaijani manat.

Naoto Sato has discussed the Turkish lira revaluation, providing the facts and Java support information. But I'd just like to express my disappointment. I mean, the Turkish lira was my poster child for expansion in a currency field. After all, not too long ago it was about 1,500,000 lira to 1 US dollar. Once I showed that example, it was more than clear to the folks I presented to that they need to allow some space. Now, ho-hum, the best example I could find was the Vietnamese dong, currently a paltry 15,812 to the ever-dropping US dollar. Oh sure, it's an additional 4 digit positions, plus an extra separator or two. And yes, it does have the bonus of not needing a decimal value, showing the need for a flexible decimal area that can disappear.
But it's just not the same. }sigh{

On a more pratical note, the Azerbaijani manat will be re-denominated as of January 1, 2006. The new value is: 1 new manat = 5000 old manats. Looks like both currencies will remain valid until December 31, 2006, at which point the old manat will no longer be accepted as legal tender. The new manat will retain the old subdivision of 100 qapik (which will now, of course, mean something).

This begs the question - what of the Turkish lira subdivision? I mean, now they need one, and so they have one. 1 new Turkish lira = 100 new Turkish kurus. Were there old kurus? How long ago were they used? I mean, even the 5000 (old) Turkish lira coin is pretty much out of circulation!

Ah, numismatics!

( Mar 18 2005, 11:20:44 AM PST ) Permalink

Thursday March 17, 2005

Myth #3 - For all Java programmers and their managers

Another couple of days, 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 Swing and logical fonts. Take a look at the Java Internationalization site to find out more.

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

( Mar 17 2005, 03:58:31 PM PST ) Permalink Comments [1]

Tuesday March 15, 2005

It's all Geek to me...

I was putting Notes into the architecture presentation today, and got to the title page for the "Myths" section (see my original blog to know more about this). Sometimes I'll put Notes into title pages if there's introductory information relevant to the entire section. In this case I couldn't resist the punny "It's all Greek to me" (in case you haven't had enough coffee yet, Greeks have a famous mythology which I and many other children in the USA had to study once early in high school and then again later on in high school). Which then brought up another pun, the title of this blog.
Is "It's all Geek to me" too far from the original for anyone to get it? Hmmmmmmmm ...
Internationalization geek stuff. Obscure. More on this topic in another blog.

( Mar 15 2005, 11:27:28 AM PST ) Permalink

Monday March 14, 2005

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

And so on to Myth #2 (for some background see my previous blog, "Humor for internationalization engineers (and others too)")

"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.

Next blog, Myth #3!

( Mar 14 2005, 05:43:18 PM PST ) Permalink Comments [1]

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]