Software Localisation - 3 things too important to ignore

· 4 min read

See what I did there? I wrote localisation instead of localization. Does that make any difference? Search engines will tolerate some insufficient en_US - en_UK distinctions in the texts of your application, but in terms of grammar, semantic indexing and user experience, the tolerance sinks. Your SEO team will be especially adamant about ensuring that any outward-facing text be optimized for both of the major "Englishes" out there. Software localisation isn't witchcraft, as long as you respect its importance in your product strategy. The following are three things that come up all the time with clients, so I felt they needed emphasis once again.

1. English isn't English

Not only will US-American users find it slightly weird to constantly stumble upon distinctly British terms or spelling conventions, it might even cause confusion. There is a reason the first Harry Potter book has a different title on the other side of the Atlantic ocean. English is not the only language however, where disregarding the finer linguistic differences can make you look bad. The same goes for Spanish (Latin-American versus European Spanish, or more distinctly, taking into account local varieties on both continents), Chinese (simple, traditional, Taiwanese...), Portuguese (Portal, Brazil, former colonies) or even German (Germany, Austria, Switzerland, we've covered some examples previously) and a few others. You'd be surprised how sensitive consumers are in our globalized world when it comes to "micro-patriotism" and cultural pride.

2. What's mobile?


In most cases, you will develop software for a variety of devices, or have versions for most other devices. Sometimes you have one application and it is meant to work on all of them. Convergence is all the rage, and will become more important, as the bigger oligopolies are seeing new competition arise and separate development for multiple platforms becomes increasingly burdensome. Have a strategy ready in the early stages of your product on how you will accomplish two things: a) reach all platforms with little additional cost of (re)development and b) streamline internationalization and localization across all of them. If you don't think about this at the beginning, you will end up localizing completely separate products at a later stage, multiplying your overhead costs to the unbearable - even though the product is basically the same.

3. Consider the human factor

Yes "the crowd" is all the rage, but let's not play buzzword bingo. Language is complicated, translation requires experience, cultural awareness, human understanding and context. In a professional context, translation as a language service provided to localize a product, requires a high degree of quality, and most of all trust. There is a reason for language associations, certificate programs and industry standards. Your product belongs in trustworthy hands that deliver the maximum in quality so  your product will speak to new customers in their language. Quality has a price, yet localization is an investment, small in comparison to the potential benefits of reaching additional markets all around the globe. It is an endeavor that takes a considerable amount of planning and importance in your product strategy, and should not be rushed last minute or outsourced to anonymous services at dumping prices. You wouldn't want your software developed like that, either.

Software localisation / localization is really painless if your team took early preparation for it. Proper internationalization of your code, adjusted roadmap and quality testing, coordination with marketing and sales, and so forth, will determine success. Talk to a localization specialist early in you product cycle. These things will be too important to ignore.

Extra: Watch this interesting talk on global market trends for start-up companies

Clock calendar notifications in harmony

Start your 14-day free trial