You can minimize the challenges of supporting different localizations by following a few practical guidelines.
Even the simplest tasks can be complicated by the need to support multiple localizations (languages). Here are several tips for anyone who suddenly finds they need to support additional localizations.
1: Make sure that IT has the necessary resources
This one probably sounds obvious, but it is critical to make sure that IT has what it needs to support users who speak a different language. Otherwise, simple jobs can take a lot longer than they should.
When I was with the military in the late 90s, I was asked to look at a system that was having trouble running a certain application. But the system was using German — and I don't speak German.
The problem was actually something very simple. The Messenger Service (which was required by the application) had been disabled. Not knowing German, however, I could not read the error message. I called a friend who spoke German and asked him to translate the error message for me. He told me that the error message didn't make any sense because it said that the paperboy had stopped. I had no clue that "the paperboy" referred to the Messenger Service.
It took me a full day to extract enough information from the event logs to figure out what was going on. Had the same problem occurred on a system that was based in English, I could have fixed the problem in a couple of minutes. A lot of time was wasted simply because IT did not have anyone who spoke German.
2: Be aware of product-specific requirements
Some products support multiple localizations but use one language as the primary language. If you aren't careful, you can accidentally overwrite the primary language.
Exchange Server 2010 is an example of such a product. It lets you create custom MailTips by using the Set-Mailbox cmdlet. So if you wanted to create a MailTip for a specific mailbox, you could use this command:
Set-Mailbox -Identity <mailbox name> -MailTip "<mail tip text>"
You can create localized MailTips, but if you try to use the cmdlet shown above you will overwrite the English MailTip you have already created. Instead, you have to import the existing MailTip into a variable, add the new localized MailTip to that variable, and then use the variable to create a new MailTip.
Suppose that you wanted to add a Spanish localization to an existing MailTip. You could do so by using these commands:
$CustomMailTipVar = Get-Mailbox <mailbox name>
$CustomMailTip.MailTipTranslations+="ES:<Spanish MailTip text>"Set-Mailbox -Identity <Mailbox name> -MailTipTranslations $CustomMailTipVar.MailTipTranslations
I don't expect those who are not well versed in Exchange Server 2010 to understand what these commands do. I simply wanted to illustrate the point that sometimes you have to jump through a few hoops to add localization support.
3: Segment your Active Directory by language
Active Directory environments are often set up so that domains and organizational units map directly to geographical locations. However, if you have multiple localizations in use within a single location, it may be helpful to map either your domain or your OU structure to the localizations. For example, you might put all the Japanese-speaking users (and their computers) into a common domain or OU.
The reason for this is that often times, patches are language specific. The patch management process will be far easier if your users and computers are already grouped by localization.
4: Be flexible with your product selection
IT pros know all too well that there is something to be said for consistency. It is advantageous (from a support standpoint) to have all users using a common set of applications. When it comes to supporting multiple localizations, however, you may have to be more flexible. Not every application is released in every language. Even big companies like Microsoft sometimes release products in a limited number of languages. Occasionally (as was the case with Windows Phone 7), additional languages are added after the initial release. If a product does not offer the required localization, you must be prepared to look for a substitute product.
5: Be aware of regional differences in languages
If you're responsible for deploying various localizations, be aware of the fact that even a common language can differ significantly by region. American English is different from British English and Australian English, but the three flavors are similar enough that people from the U.S., the UK, and Australia can usually understand each other without too much trouble. The same does not necessarily hold true for other languages.
I've spent a lot of time in Spain and am relatively fluent in Spanish. But earlier this year, I spent some time in the lower part of South America (Argentina, Uruguay, and Chile). For about the first week, I felt like a fish out of water. South American Spanish is quite different from European Spanish. There were enough similarities that I was able to figure out what most of the signs meant, but I had a lot of trouble with simple tasks, such as checking into a hotel. If you're responsible for deploying localizations, check to see whether you'll be dealing with significant regional variations of the language.