Surely you’re smart enough to know that people outside the United States attempt to use Microsoft software every day. I mean, Nadine Kano first published Developing International Software for Windows 95 and Windows NT back in 1995. By now you must be aware, but how can anyone tell? You could try using our software outside the U.S. Doing so would lead you to an inescapable conclusion: Microsoft engineers are clueless.
Ignorant idiots implore, “But we’ve got localization teams! We translate our strings! We even leave extra space for those long German words! We care!” Oh my goodness, it’s worse than I thought. Translating strings and leaving space to display them are the least you can do, so thanks for doing your least.
To give our non-U.S. customers a great experience, you have to consider their world. How do they pay for things? What kind of Internet connectivity do they have? What online services do they use? What are their legal and cultural norms? What’s valued (or distasteful) in their culture? After all, if you got those things wrong in the U.S., you’d feel pretty stupid. “But that’s hard!” Yeah, it is—good thing you get paid.
We can’t tell U.S. people how to work and think, let alone the rest of the world. Yet when we impose a U.S.-centric experience on our software, we dictate that experience to everyone beyond U.S. borders. How do you avoid being an international idiot? Here are a few steps:
Let’s break it down.
The starting point has to be quality code that is readily localizable. Developing International Software provides all the details you need to know. Many of the guidelines date back to the 1995 edition. Here are a few key reminders:
UNICODE is tricky because characters are tricky. They can have accent marks and a whole host of other decorations and combinations. You can’t just count bytes and think you are counting characters. That’s where the Char and StringInfo .NET classes can help.
To go beyond the least you can do and create a compelling product for non-U.S. customers, you need to remove your U.S. biases during high-level product design. That’s right—at the beginning of the project.
Get your design team together with representatives from all engineering disciplines, and brainstorm what could be different about your primary scenarios outside the U.S. The most common differences are with the three Cs: connectivity, credentials, and content.
For example, you may think it’s fine to grab some info online every time you need it, but some people pay by the byte. You may think your prices should always be in local currency, but sometimes the preferred currency is from another country. (Ecuador uses U.S. dollars.) You may think people everywhere love Twitter and Facebook, but those sites are blocked in some countries. (China has its own Facebook-like social network.)
Another bit of bias comes from believing people stay put. In fact, folks often travel across borders. There are incidents of people buying phones in the U.S. and not being able to use them in France; incidents of people trying Azure with a U.S. test account, and then being denied an account in Australia. If you’re not careful about your assumptions, you can easily keep customers from enjoying our products (and prevent them from paying for the privilege).
Connectivity, credentials, and content are always in flux in every country. You need a strategy to stay flexible and current. Two approaches that have proven to work well are downloadable content and componentization of experiences.
Some products, like Xbox, have their content programmed daily and downloaded dynamically. This includes changes to menus and layout. However, that content is cached so it doesn’t incur excessive bandwidth charges and still functions when disconnected from the network. Other products only download their content via software updates. Of course, services download their content each time they’re used, though most use edge-node caching through a content delivery network (CDN).
In the automotive world, cars are heavily componentized so that they can sell into a wide variety of markets. Need the steering wheel on the right instead of the left? Swap in the right-hand parts. This strategy only works if you integrate the flexibility from the start— you can’t easily retrofit a right-side steering wheel. When you review your U.S. biases, consider what software components need to be swappable for the markets you engage. This kind of planning is another reason to involve all disciplines, including your international team and business team, in early, high-level design discussions.
Once you’ve built your components, you’ll want to validate your key end-to-end scenarios. Some of that can be done locally using settings and configuration, but the only way to know if scenarios really work properly is to run through them in the customer’s country (aka in-country).
There are vendors available all over the world to help validate new software products and services. Many product groups already have relationships and pricing arranged, including logistics for running scenarios and entering bugs. Don’t reinvent the wheel.
However, in-country testing can be expensive. To minimize your costs and maximize your benefits, only validate your most important scenarios, and only focus on validating the three Cs. In-country testing isn’t about checking translation and UI (aka loc testing)—you can do loc testing far more cheaply elsewhere. In-country testing is about validating connectivity, credentials, and content for your key scenarios.
The world has become smaller as people connect with each other beyond sovereign boundaries. Technology and services spread quickly around the globe. For people to love the experiences they have with Microsoft software, those experiences—as well as the strings—must translate around the world.
Providing compelling customer experiences worldwide requires world readiness (bias-free experiences that can be translated and tailored to different locales), localization (translation, including speech), and in-country testing to validate real-world use across product and geographical boundaries. This necessitates extra work, but compelling experiences change lives and dominate markets. We can provide them, or we can leave them to our competitors. It’s up to you to make the smart choice.