Friday, April 27, 2007

Myth #7 - IT depts., are you feeling lucky?

In this, the next installment (or instalment, if you prefer) of the
series, we explore something nearer to our hearts^H^H^H^H^H^Hselves:

"All company employees speak English, so only English needs to be supported by internal tools."

Seems pretty straightforward, huh? But the question is, what are internal tools used for? Even if all employees speak and read English, their data may not be in English. If they live in Beijing, it might make sense to store their Chinese addresses, for example.

Much of the data that internal tools process is not employee data, however. Many companies have bug tracking and reporting tools. These tools are used to log and report on bugs found in company products. Not only can those bugs originate from people outside the company who may not be able to write in English, but the problems can be regarding the processing of data other than English. If the products are internationalized, customers use them to process data from all over the world. If they encounter a problem, they're going to want to put in the data they were using when the problem occurred (if you're lucky). Without that data, you may not be able to reproduce the problem. Worse, if you don't allow that data, the customer may not bother to tell you about the bug at all!

Think about your internal customer databases - can they handle customer data in the local languages? This can be extremely important for customer relations and communications. What about Web based feedback? Could a Greek customer who doesn't write English send you some feedback? Wouldn't you want to know? Getting the feedback translated is a simple matter; getting the customer back after they left in frustration from not being able to communicate with your company is a lot harder and more expensive.

There are many other examples of internal tools that need internationalization: survey tools, forum discussion software, employee benefits tools (if you have worldwide employees), product registration tools, financial tracking tools (does all your revenue arrive in US dollars?), etc. The trick, and I know this is really tricky, is to carefully look at the tool requirements and all the data that the tool will be processing in the foreseeable future. Then design, architect, and implement to cover it. Piece of pie. Easy as cake.