Stupid in any language

 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.

When in Rome

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:

• Get the basics right (sometimes called “world readiness”).
• Question your U.S. bias during high-level design.
• Design for flexibility and agility.
• Validate end-to-end scenarios in-country.

Let’s break it down.

Back to basics

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:

• Don’t hard code localizable elements. Duh! Yet people working on Windows Web Apps (WWAs) still hard code strings in HTML and JavaScript. Embrace semantic HTML and keep strings out of code. Take extra care to make domain names and URLs appropriate worldwide.
• Use String.Format and FormatMessage for constructing strings. Using string concatenation or functions that associate parameter order with string order is like hard coding strings, only in a far more technically deviant way. Not all languages order strings the way U.S. English does.
• Make buffers (C++) and UI elements large enough to hold translated text. It’s not just German. Often strings contain descriptions that are difficult to translate succinctly in other languages.
• Apply pseudo-localization to catch where you’ve made careless mistakes. Generating pseudo-loc builds early and often can make goofs obvious immediately.
• Use culture-aware string functions for any displayed strings (like String.Compare and StringCompare). Also remember to use the right parameters for SQL sorting.
• Avoid images or layouts that assume left-to-right direction. Heck, avoid images in general unless they are universal (like logos or icons). The whole world doesn’t read left to right.
• Use UNICODE, and don’t assume characters are always proportional to bytes. That is, unless you want to be bitten yourself.

Eric Aside

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.

Maybe I’m biased

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.

• Connectivity: lower bandwidth, paying for bandwidth, and slow communication to U.S. datacenters.
• Credentials: common credit cards, banking regulations, licensing, age gates, preferred currency, and privacy concerns.
• Content: pop culture, taboos, connotations of words and colors, rating and value systems, preferred services, and available services.

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

Piecing it all together

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.

Been there, done that

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.

Flatland

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.