Monday April 25, 2005

Myth #11 - Ahhhh, elevenses, where everyone is literate in English™

Now we enter the land of fantasy, where eating pizza and ice cream causes weight loss and lowers blood cholesterol, and everyone is able to read and write English. Here we have a new myth in the series:

"If something is wrong, our customers will tell us."

The question is, what venues do you give them to tell you? And how do you know that the reason they didn't buy your product is because of certain internationalization (or other) problems? those are the two main stumbling blocks to overcome, but there are undertones as well.

Starting with the venues, have you provided your customer with easy ways to tell you about problems? That is:

• Do they know what URL to go to, what email address to mail to, and what number to call?
• Is the text at the URL translated into their language?
• Does the form at the URL accept text in their language?
• Is the person who answers the phone the person who helps them throughout the problem reporting process (regardless of who has the correct solution for the problem)?
• Does the person on the phone speak their language?
• Are emails in their language?
• Is there a discussion forum in their language, and is someone from your company monitoring it?
• Can your bug tracking system handle data in other languages (which your software processes)?
• Do you conduct seminars and conferences on your products in different parts of the world, and are there interpreters and translations of slides and papers into the local language(s)?

I'm sure there are loads more things that can be done, but this is what I mean by venue. Some of the above points are more general; making sure your customers (or potential customers) know exactly where to go to ask questions and report problems (they should be the same place, one contact point to your company, regardless of the communication) is basic customer service. Providing them different channels (Web, telephone, email) gives them the flexibility to choose what they are most comfortable with. Providing these venues in the customers' languages is also essential; it shows you care about them and you will listen to them. Even more fundamentally it enables them to communicate! Not all customers are comfortable enough with English to report a problem. And there are cultural issues to consider: many people don't want to embarrass themselves by using their so-so English, potentially creating a misunderstanding. In some cultures, pointing out a problem is an incredibly rude thing to do, even if it's a product they've paid good money for. They may be more inclined to quietly return the product or eat the cost and move to a competitor's product. In those cases you will never learn of the problem which lost you that customer, and maybe others, too.

This brings me to the second point, do you ever find out exactly why a potential customer never became an actual customer? Does your company do follow-up? Have you listened carefully to your potential customer's requirements - in their language, using their cultural conventions - and verified that your product fulfills them? Are you approaching potential customers in a culturally appropriate way? Are you advertising in the right fora (forums)?

It may sound like a lot of work, but the payback is huge. If you think your company does OK in this area, take a closer look. Talk to the people who live and work in other countries and get the real story. Most recently I heard from someone who worked in the support area in China. He knew of several cases where customers reported problems with the product running in the Chinese environment. Because the people trying to reproduce the problem didn't try it in a Chinese environment, they couldn't reproduce the problem, and closed the bug report! (Yes, this happened in 2004.) Do you think those customers ever reported another bug? They may not even be customers anymore. This actually points to a future myth, that is, that internationalization is only necessary for software development.  Until then.

( Apr 25 2005, 09:15:59 AM PDT ) Permalink

Monday April 18, 2005

Myth #10 - For Senior VPs, the power of 10

What I wouldn't give for VPs to read this blog! Actually, it'd be great if they read all the myths, but you can't have everything (where would you put it?)

"We added internationalization in the last release, so we're done."

I find it almost unfathomable that any exec would believe this, and yet I have heard it from more than one. Saying this is like saying "We wrote the code in the last release, so we're done." I hope that there isn't a software VP out there who would say that. Internationalization is inherent in the architecture, design, and implementation of a product. In reality it is part of the entire process of creating, distributing, and selling a product, but I'll just stick to the software development portion. When designing a product, international requirements must be considered in the design and architecture, otherwise you may have to redesign and rewrite the product to enable support of other language and locale data. I have seen it happen, and most recently, a product was scrapped because it wasn't worth rewriting it. What sort of things can trip you on design? Take a look at my article on this very topic: Internationalization in Software Design, Architecture and Implementation

Every time there is a change in design, the addition of functionality, new code written, there is internationalization. It, too, like all aspects of a changing product, needs to change. It is part and parcel of the entire software development process, from requirements gathering, to design specification, to implementation, to testing, to release. Unless the product itself is done, internationalization work needs to continue.

And the myths go on (they go to 11) ...

( Apr 18 2005, 09:15:03 AM PDT ) Permalink Comments [1]

Wednesday April 13, 2005

Myth #9 - Number 9, number 9, number 9, number 9

(Play this blog backwards for the hidden messages.) As for the more overt message, I continue with the myths, series:

"We've never localized this product/module/component/blidget, so it doesn't need internationalization."

It's a good thing that nothing ever changes in products, nor in markets. Oh, they do? Yes, even though your product has never been localized before, and this may be a real shock, it might be localized in the future. Whoa! And, another shock, localization is a business decision, not a technical decision. In other words, if a customer says, "We'll buy 2 million licenses for your product if you localize it into Cloqrat," you don't want to have to say, "Gee, sorry, it'll take a massive reworking of the code, say, 12 months to get that to you" since your customer will respond "That's OK, we'll just buy Microbrain's version" and then your problem will be solved because you won't ever see that customer again.

But there's more to it than that. Internationalization is a lot more than making the product localizable. It's primarily about data processing (see Myth #1). That is, even folks in the USA have to process data that is not US data. Was that another shock? I'm sorry, try some rooibos tea.

( Apr 13 2005, 09:18:06 AM PDT ) Permalink

Wednesday April 06, 2005

Oh no! Not Myth #8! Anything but Myth #8! ...Anything? ...OK, Myth #8

And now, we examine our heads, no, navels, no no, myths, we examine our myths (OK, can you tell I'm getting a little punchy here?):

"Administration interfaces don't need internationalization."

'Cause all sys admins everywhere speak, read, and write English fluently, don't they? You know, the funniest thing about this myth is that it's so often repeated, but I have yet to find any data, study, customer interview, or even efforts to obtain such, to support this myth. Maybe it's a mantra. In any case, the hard facts are that many admins are not that comfortable with English, or in some cases they don't know any at all. If you're charged with keeping a company's systems up and running, how keen are you to do that in an interface that is a second language? I thought so. Nothing like a message popping up on the screen with "Floozid iyarkaba panic gotrios piwec shutdown worqas!!" and there you are, madly flipping through your Cloqrat => English dictionary, trying to remember the conjugation of the verb gotrasco. And then more messages come flying across the screen...

The point being that admins are humans, just like you, and language has meaning for them too. They're going to function a lot better in a native language than in a second language, just like you. Here at Sun, we translate our admin interfaces (if you're at Sun and you're surprised, well, check it out). And this actually leads into another myth, which I'll post at a later date, namely "We've never localized this before."

}sigh{

( Apr 06 2005, 09:00:10 AM PDT ) Permalink Comments [2]

Friday April 01, 2005

New encodings for Unicode!!! UTF-9 and UTF-18

I hope you all have seen the new encodings for Unicode, UTF-9 and UTF-18. Better get this implemented into your software or competitors will leave you in the dust!

( Apr 01 2005, 03:59:44 PM PST ) Permalink