10 Rules for Painless Software Localization
Your team built a killer app in English. High-fives all around. Your user-base is growing, reviews are all positive, you even caught TechCrunch’s eye. Life is good.
Then your 15 minutes are up. Sales flatten out. You start losing market share to a new competitor.
The technology sector has the memory of a goldfish. New players rise and fall every day. You stand a cold thing’s chance in a hot place of riding your initial success through a career-full of revenue. Unless you localize.
You just groaned. Software localization is not your favorite thing. You love to build things, and translating is much less fun. Few developers are eager to localize until they hear about all of the business they’re missing out on. Try this on for size:
- Global SaaS and cloud-based business application services revenue will grow from $13.5B in 2011 to $32.8B in 2016.
- By 2017, Gartner projects that there will be 268 billion mobile app downloads annually, amounting to $77 billion in revenue.
- More than half of the world’s mobile subscribers (52.1%) are located in Asia Pacific.
- Global games revenues will grow at a 5.7 percent Compounded Annual Growth Rate, reaching an annual haul of $93.18 billion by 2019.
Consider the social networking site, LinkedIn, a company that’s seen much success such their inception in 2003. A few years ago, LinkedIn headed the Forbes list of 25 Fastest Growing Tech Companies. At the time, LinkedIn was a relatively young company, only available in two languages, English and Spanish. The site now displays content and offers customer services in 19 different languages and the number continues to grow. The same goes for the other 24 companies that were listed on that year’s Fastest Growing Tech companies, and rings true for featured companies year after year. Coincidence? We don’t believe in coincidence.
Bottom line — there’s a lot of money to be made in software development right now, but most of it is global money. You need to localize your software.
Table of Contents
Getting Started with Software Localization
Here are a few things to keep in mind:
1. Use a Continuous Localization Platform
This might sound a little self-serving coming from us, a company whose product is a Continuous Localization Platform (CLP), but seriously, you need one. Before the CLP, you had only two options: Human (great final product, but slow and expensive) or robot (fast and cheap and terrible in terms of quality). A CLP allows you to remain in control, access real-time analytics, protect your intellectual property and get your software translated efficiently. It’s really a no brainer.
2. Always Use a Full Locale
Be as precise as possible when you localize. Different regions may speak and write a shared language with nuanced differences. Lionbridge explains the nuances of languages perfectly, using the words screen and monitor as examples. “Both describe a device that provides visual output from a computer. However, in the Life Sciences industry, “screen” means to check a patient for a particular symptom and “monitor” means to watch something over a period of time.” Your software should reflect an understanding of those differences.
3. Make Room for Strings to Grow & Shrink
Design should already be part of your most precious intellectual property. You should invest as much energy on how your software looks as you do on how it works. As you design, keep in mind the reality that text will vary in size as you translate it into different languages.
Here’s an example. “Repeat password” is 50% longer in German than in English; if you haven’t left enough space, localization will break your design. You will need a 2-pronged approach to this problem. You want to create enough elasticity to accommodate a 40% variance. This will take care of most strings in most languages. That said, you’ll also need to test early and often. Let your designers be involved in the process at every phase, so they don’t experience a bottleneck of updates once the translations are complete.
4. Start with your Product Page and Description
If you’re really nervous about localization as a whole — not sure your product will have global appeal, or remain unconvinced of the business logic — then start small. Many companies have seen great sales gains resulting from the launch of a localized product page even without making changes to their software. If you decide to use your product page as a test, be sure you do it right. Comb over every single pixel of your product’s LP and every syllable in your app store description. Adjust the username in your screenshots (“Carlos” instead of “John”) change any references to location (maps, pictures, timezones). You don’t want to fail because of poor execution and come to the (incorrect) conclusion that localization doesn’t work.
5. Never Concatenate Strings
Sloppy amendments in CSS or HTML, qualifying one string with another as can often happen in redactive search, is a shortcut that nobody will notice until your software is localized. When you do, you will have bugs out your ears. Even the Romance languages, which are very close to one another, have subtle syntactical differences. Sometimes modifiers come before nouns, sometimes after, sometimes they become a suffix.
Instead, code the entire string together and allow your translators to put the words in the correct order for each linguistic context.
6. Include Punctuation
It’s tempting to omit punctuation while you are coding, and plan to add it later. Maybe you hope to re-use the string in different contexts where it will need to be punctuated differently. Don’t.
Include punctuation in context, and create unique strings for each line of text. Even the same sequence of words may translate differently with different punctuation. In French, for example, a colon is surrounded by spaces. If you omit the colon in your string, and try to add it later, your French interface will have a typo that your translators could have helped you avoid.
7. Pay Special Attention to Proper Names
Some languages alter the spelling and pronunciation of proper names in different contexts. Others alternate the placement of given and family names. Pay special attention to your treatment of names. It’s best to offer all three fields – first, last and username.
8. Never Hard-Code Date, Time, or Currency
Time and date formats vary wildly around the world. Currency too. Java can help. Code in a universal format like ISO time and then tap an open-source library like Date.js to format for your specific location.
This can be especially in date selection tools. Estonia marks Saturday as the first day of the week, the US starts on Sunday, the UK on Monday, the Maldives on Friday. Use the jQuery UI date picker to overcome this challenge.
9. Plan for Languages that Read in Both Directions
Most languages read from left to right, but Arabic and Hebrew read from right to left. CSS and HTML provide a directional property, but they will not override a CSS element coded as “float: left” or “float: right”. If you have fixed positioning layouts, you might need to build an entirely new set of style sheets for your left-to-right products.
10. Never Trust the Browser
Yes, the browser can translate. But you shouldn’t trust it. Any extra work the browser has to execute on your app will make it slower, and nobody likes to wait. Let the browser do what it does: browse. Let the people coo about your speed. Localize. Don’t trust the browser.
Ready to Go Global?
Software localization can be a painful process, but it doesn’t have to be. Follow these simple rules and you can launch your software into a global marketplace without more than a little pinch. We promise. And if you want to see how easy it can be, just reach out to us and request a demo. One of our team members would be happy to show you around the platform.
*Editors Note: We’re all about simplifying the localization process! A recent increase in requests for how to properly localize software gave us the idea to re-share a post that was previously featured on our blog, written by our CEO, Dimitris Glezos. We made a few updates and hope you enjoyed it!