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

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

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

I have sent Jonathan Schwartz (Sun Microsystems' CEO) 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.

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

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!