Localisation is vitally important to take a digital product into any new market. If you’re marketing your application to a new audience, it’s vital that it’s adapted to meet their specific needs. This means changing the language but also adapting other elements of your product to ensure a better cultural fit.
Ambitious marketing managers won’t restrict their ambitions to a single secondary market. This means that the localisation process may need to happen several times as the product is scaled.
For major markets such as India or the EU, it may even be appropriate to create several versions of the product so that it suits the different language and cultural groups within that territory.
One way to rationalise the costs of localisation for several new markets is to take an internationalised approach to building it in the first place.
Internationalisation is a way to structure a piece of software so that it can be adjusted for different markets with relative ease. If you’re building a product that you have ambitions to take to several new markets, internationalisation is a way to help manage the costs of localising that product into new markets.
It’s a building approach that ensures your product is ‘localisation-ready’ and doesn’t need to be rebuilt from scratch when it’s localised for new languages and needs.
Internationalising your product
Internationalisation means designing and building software with as few barriers to localisation as possible.
For instance, this might include the navigation design is flexible enough to be translated into another language and moved into a new environment without needing major redesign or redevelopment to happen first. It’s essentially a way of building with flexible possibilities for future adaptation.
In practical terms, this means the original development of the product will have Unicode enabled or the ability to handle legacy character encodings so it’s flexible to use other alphabets.
If developers are really thinking ahead, they may even factor in for features that won’t even be activated before the product is localised.
Maybe they’ll give the product the ability to support bidirectional text even before it needs to do that, or building a CSS that can accommodate vertical text. Decisions like this help future-proof the product against whatever is later asked of it.
Localisation includes much more than accommodating other languages. It also includes things such as measurements or clothing sizes on product pages, date and time formatting, local holidays and calendars, address and postcode formats, and how personal names are given.
By separating the localisable factors from the source code, the different international factors can be applied to the site without significant rebuilds.
For instance, a shoe retailer can easily switch from using UK shoe sizes to using European ones without having to rebuild the dropdown list or filters navigation.
Even better, internationalised websites can be built to adapt to the user’s location or pre-determined preferences for which site they use.
This means that a person could visit the Farfetch site from the UK, where the UK version of the website with prices in sterling would automatically be served to them based on their location. If they then choose to view the French version, this preference would be saved.
If internationalisation practices haven’t been applied to the master site, it’s common for the localisation to perform poorly.
It’s fairly common for retailers to slip up and fail to adapt their clothing sizes when they enter new markets. It was one of the reasons Banana Republic floundered when it entered the UK, and also a factor cited in Marks and Spencer’s exit from China.
In both markets, customers couldn’t easily understand the unfamiliar sizing. It’s exactly the same when sizing is presented digitally – customers won’t feel comfortable unless the size format is familiar to them.
Your internationalised product will ultimately support localisation into a wide number of markets. Perhaps the key considerations are ease of adaptation and cost-effectiveness.
A well-built digital product is one that scales easily and quickly into new markets. Rather than focusing on development costs and rebuild considerations, it enables your localisation team to focus on cultural and language factors that can help the product perform well in its destination market.
If well-built, an internationalised product will also help smooth the product’s path into the new market by minimising the number of bugs that need resolving before launch.
Localisation teams can focus on cultural and language considerations, rather than QA-ing the product for the new audience.
If there are any future updates to be made, these only need to be made to the code once rather than duplicated across localised versions of the product. In the long-term, this may significantly reduce your costs.
Of course, the disadvantage of building an internationalised product is that a wider set of factors need to be considered in the initial build stage.
Often the hardest part of the project is getting the product launched with MVP, and building with multiple future localisation projects in mind may extend the initial build period.
It’s perhaps not something to be undertaken lightly. But if you have any real international ambitions for your product, you should start considering its eventual localisation at build stage by factoring internationalisation into the initial development.