Monday May 23, 2005

Myth #14 - CEOs, something you should know (last of the series)

This is, in fact, the final myth of the series, and it's huge:

"Internationalization is only needed in the software development department."

I have sent Jonathan Schwartz exactly one email. I have no idea if he read it, but in it I wrote:

1. Internationalization is not a solved problem.
2. Internationalization cannot be accomplished by engineering alone.
3. Internationalization must be an integral part of everyone's job; it cannot be accomplished by separate people labeled "internationalization specialists".

Today's myth is really #2 in the email, but the other 2 items are related. What do I mean by saying that "internationalization cannot be accomplished by engineering alone"? After all, doesn't software internationalization mean development work? Well, yes it does, but not in a vacuum.

Imagine designing, architecting, and implementing a software product with no specification, no customer requirements, no input from marketing, no data from market research companies - would you do that? Doesn't make sense, does it? And yet that's exactly how we internationalization folks work. There is no-one in marketing to gather international market or customer data; very little international market research is available for the areas that internationalization needs to know; and we don't do much in the way of gathering input from our existing international customers. And yet amazingly, people ask me all the time what languages, writing systems, and locales we should support. Sure, I can use my judgement, just as any other development architect could make her best guess on what to do. But that's not a very good way to do business.

Software internationalization engineers are expected to not only know their specialty, but to know everything about how it is applied everywhere. Just yesterday I had an email exchange with a manager in user interface engineering (UIE). We have been talking about putting together training to help the UIE folks better understand internationalization issues in the user interface. But the word is that their director is not interested. Huh? Sooooo, what does that mean, that UIE designs interfaces that only serve 40% of our market, and that's OK? Maybe this director is a firm believer in Myth #13. I'm not a UIE expert and have no plans to become one. Nor do I plan to move into int'l marketing, nor int'l financial reporting, nor int'l product distribution, nor manufacturing, nor software release, nor any other aspect of getting an international software product out in the marketplace. But all of these areas need to understand how international affects what they do. In other words, everyone needs to internationalize.

Let me give you another example. The globalization team is always trying to report numbers illustrating the value we add. We would like to show sales figures based on the localizations we have completed. The problem is that we have no way of knowing what customers are using which language versions of our products. This is not something that can be discerned from part numbers, because we include many localizations with each product. What needs to happen is that we need to get feedback from customers on what language they use as the primary one for the product they purchased. Globalization is an engineering organization; we are not positioned to garner this kind of information. Other groups could do it by simply internationalizing what they already do.

Or we could just keep guessing.

( May 23 2005, 09:31:48 AM PDT ) Permalink Comments [1]

Tuesday May 10, 2005

Myth #13 - Software engineering managers and triskaidekaphobics, take care!

I am nearing the end of the myth series, but I won't end on 13!

"Internationalization is implemented after the base product is written by a separate group of engineers."

This one really hurts. And it does take a lot of explaining, but I'll do what I can to condense it. An internationalized product is one that processes data from all over the world. Whatever the product is supposed to do with data, for example, receive and send emails, it can do it with data from lots of different places in lots of different languages using lots of different locale formats. In order for software to be able to do that, every place in the code where the data is touched needs to be internationalized. If the internationalization takes place after the "base" code is written, then that means that a developer is going over the code twice (at least). From a logical standpoint, would you pay development engineers to write the same code twice? That's a very expensive way to develop software. Moreover, would you let engineers who don't have a very thorough knowledge of your code work on the core functionality of your product? That would likely introduce a number of new bugs, some of them quite serious. Yet if you are writing a "base" product and then paying a 3rd party internationalization group to internationalize your code, that's exactly what's happening. And if that internationalized code isn't incorporated into the source tree for the next revision, then you're paying even more to have the same code reworked each time you put out a new version.

'But,' you may wonder, 'my development engineers aren't internationalization experts. How can they write internationalized code?' The answer is training. Internationalization is an aspect of good coding practice. That it isn't yet taught in universities is a real problem, and those of us in the industry are keenly aware of the issue. So you may need to make up for it in house. Set up internationalization training for all development engineers, test engineers, and engineering managers. There are a couple of vendors who provide these services (I don't have firsthand experience with any particular vendor). Furthermore, there is a tremendous amount of documentation in books and online, talking about the concepts as well as the implementation details involved in internationalization. Take a look at the Sun Globalization Resources, and the Java Internationalization site to start with. There are a couple of links on my blog page that have good information on internationalization. Have a look at my article, Internationalization in Software Design, Architecture, and Implementation, and take advantage of some of the mailing lists. In the end, it's much cheaper to train your own engineers than to pay for some other company to rewrite your code. And your engineers may be a little bit more content in their jobs when they're learning new things and have more control over their own code.

Try it out, and let me know how it works.

( May 10 2005, 09:00:48 AM PDT ) Permalink

Monday May 09, 2005

Big picture, criticism, and an apology

Another brief departure from the world of internationalization myths to make some brief observations.

First, the apology. I apologize to folks for using industry abbreviations and jargon that you may not understand. I have tried to limit it, but it is faster to use the abbreviations, so I still do it. I will try to put an obvious explanation of the abbreviation i18n somewhere prominent in the static text.

Second, an observation on criticism. Before criticizing someone directly, it might make sense to figure out what you want to achieve. Are you just venting? Do you want to sound superior, boost your own ego? Or do you really want that person to do better the next time? If your answer is the latter (the last choice of those previously prevented), then consider the way you have phrased the criticism. Does it provide enough information for the recipient to understand what they need to change and why? Is the tone helpful? If you were to receive the very same criticism, how would you react?
I've recently received what I would call hostile criticism. It looks like the person didn't really want to help me improve, but somehow wanted to make me look ignorant. Since my goal with this blog is to help improve internationalization knowledge, I really don't understand why someone would do this. Maybe he was just having a bad day. Maybe he has no clue how he comes across. Maybe he doesn't understand what constructive criticism is. Who knows? But I don't understand this style of language as a first point of entry. Certainly I didn't do anything to provoke this person - I just write a blog; I don't see my blog as overly controversial. I don't write things perfectly, but I do review and think carefully about my choice of words. I just don't see the need for hostility. Perhaps it's part of the aggressive language I've seen on mailing lists. People tend to say things online that they would never say face to face.

And last but definitely not least is the Big Picture. As I said, my goal with this blog is to improve general understanding of internationalization (abbreviated i18n because there are 18 letters between the i and the n and so done because typing out internationalization over and over again gets a little tiresome and makes paragraph alignment messy), and to make a few folks chuckle a little. There are not many of us who work in i18n or have an interest in it, and so it stands to reason that we should work together to increase understanding. That means that we need to overlook small differences in order to move towards the common goal. In other words, when you have senior vice presidents (VPs) in software companies saying that "Internationalization is done" when the product in question continues to be revised, calling out a colleague's occasional phraseology* is pretty pointless. Obviously this principle is not limited to the wild and woolly world of internationalisation (alternate spelling of internationalization). Big Picture.

* It is difficult to reconcile my conversational voice with an international English. I like to use all the words and expressions available to me in the language, but have tried to limit it to a minimum. Occasionally, though, expressions like "wild and woolly" will be written - I don't want to bore the natives.

( May 09 2005, 02:28:08 PM PDT ) Permalink

Tuesday May 03, 2005

Myth #12 - More quality by the dozen

Continuing in the myth series, we address the scope of internationalization:

"My product works in Japanese, therefore it's internationalized."

Seems sort of logical doesn't it? I mean, if Japanese data gets processed and displayed correctly, surely that means the internationalization is correct? Alas, no. In fact, for a long time there was (and to some extent still is) a specialty called "Japanization". So many companies in the U.S. wanted to take advantage of the lucrative Japanese market that firms sprang up, offering this service. They would take the software and alter it to enable Japanese data processing and display on Japanese-capable machines. Sounds pretty good, huh? Except that it was expensive, time-consuming, and had to be repeated for each release. But we'll get into that myth later.

But let's say you didn't send it to a third party "Japanizer", and you really tried to do proper internationalization over the course of design and development. If you test using Japanese, then that must indicate everything is OK, right? Well, no. It's true that testing with Japanese can uncover some real internationalization problems, but not all of them. Arabic, Hindi, and French have different i18n issues from Japanese - even Chinese is different. What are these differences? These other languages often use different charsets, and in the case of Arabic and Hindi, different rendering capabilities. Beyond language, the Japan locale has its own data formats, which are not the same as France, or Brazil, or Russia, etc. And as a further area to test, Japan is within a single time zone, so you haven't tested a multiple time zone situation (a genuine problem for the U.S. with its 7 time zones).

But wait, there's more! Most customers require multilingual capabilities in their software, and that needs to be tested. For example, if you're working on server software, consider that companies will run the software on a server which is set to one language and locale (with the admin possibly using a different language for the console), but clients will be using lots of different languages and locales as they contact the server. This is a very common configuration nowadays. And it's not limited to servers. Just because someone is running the Italian localization of your email client doesn't mean that all their emails will be in Italian, or even Latin script. They may be emailing in Thai, and you need to verify that your product can handle these sorts of multilingual requirements.

For more information on testing the internationalization of software, see my article, Internationalizing Testing. And keep reading the myths!

( May 03 2005, 09:16:55 AM PDT ) Permalink Comments [2]