English is just another language

If you’re developing, selling, or marketing web-based software, standard desktop software, or mobile apps, you’ve probably already heard about internationalization, and you know why it’s important. If not (or if you’d like a quick refresher), read on.

Internationalization is the process through which you enable your software to handle the language and conventions of your target global markets. Internationalization wipes your product’s slate clean of language bias and removes the assumptions of a “default” culture.

Why is it so important to internationalize your product?

Well, all software is developed with a bias, at least in the early stages. When your developers and software engineers are hard at work on making their idea a reality, they’re thinking narrowly of your primary, local market. They create their product in a way that only supports the language and the conventions of your domestic buyers.

Your engineers might be the best out there, but they are more than likely not reciting the internationalization mantra as they develop the product: “English is just another language; the U.S., just another country”. They’re not thinking about the day a couple of years down the road when you might want to take your best-selling app, service, or software to new global markets

When you dig down into the details of how languages, cultures, and conventions differ from country to country, you start to see how important it is to prime your software or web app to accept a wide array of diverse new conditions.

The first and most critical issue is language. Users will abandon your product if it does not adequately support their language in a way they are accustomed. This is where the fun and challenges begin.

Language

You probably already know that written scripts such as Cyrillic, Greek, Farsi, and Hindi have completely different alphabets versus Latin-based languages (i.e., English, German, Spanish, French, etc.). But did you know that there’s no such thing as an alphabet in most Asian languages? Characters indicate words, not letters. So now imagine that you have a list of Chinese data that has to be sorted without any “A-Z” to rely on, and you get the idea. This seemingly magical feat is entirely possible, but the point is to be aware that your users will utilize their language in a variety of ways that you may have never imagined and they will expect the data to conform to local “dictionary-like” usage.

User interface (UI)

It’s also important to think about how UI strings and display will work when once everything is translated. Localization typically expands text by 20% to 50% in the target language. Will everything fit? Will everything be visible? Will the layout and display of screens remain intact? Again, remember – English is just another language when it comes to internationalizing your product. Make sure you leave enough space in your UI to fit any language.

Locale & cultural conventions

Locale is also an important consideration. If you’re targeting Switzerland as a market, you’ll need your product translated into French, German, and possibly Italian they are all united under one set of local conventions. Going into Canada? The conventions of French Canadians are quite different from French-speaking users in France…or Switzerland for that matter.

What do I mean by conventions? Let’s consider date formatting as an example. In the United States, short form dates are written month/day/year (MM/DD/YYYY). In most of Europe and Latin America (not to mention many other places), they are written day/month/year (DD/MM/YYYY). In East Asia, it is year/month/day (YYYY/MM/DD). Your product must be prepared to be “locale –aware” and adapt to all three date conventions automatically, otherwise, users can get frustrated. The same goes for time, calendar, numbers, measurements, currency conventions and currency symbols. Icons and graphics can also be tricky. Will one of your images, logos, or graphics lead to offense or confusion in other cultures?

Conclusion & best practices

While it’s ideal to think about preparing your product for global markets during initial development, it’s only natural that very few companies gear up that way. People in your primary market want and need your product right now, so of course your teams are focused on getting it out the door immediately.

We’ve identified a few best practices to help you avoid the pitfalls:

1. Know your target languages and locales before you continue development.
2. Train your teams to be conscious of potential internationalization issues and use an “international” mindset to approaching new features and upgrading old ones.
3. Take advantage of the international backgrounds of your team and the capabilities of your development architecture.
4. Once you decide to tackle internationalization full-force use a phased approach, don’t try to do everything at once.
5. Follow up with copious testing, using test cases that mimic the actions of an international user utilizing the feature.

Once you’ve internationalized your product, the translation process will proceed quickly, efficiently, and predictably – which is important for controlling your costs. It’s a lot harder to retool your software after the fact than to get it right the first time, especially once you’ve multiplied your problems by 3, 5 or even 10 new international builds.

If you want to learn more about the benefits of internationalization, or need help preparing your software for translation, contact us.