Top 15 Software Localization Myths

“Why bother translating – doesn’t everyone on the Internet speak English?”

Opening our list is the widely held opinion that ‘most’ users and buyers of modern technology products are likely to be proficient enough in English to make a purchase – even if English is their second (or third) language. This line of reasoning quickly leads to a decision to either postpone or completely dispense with translation efforts, viewing product adaptation into other languages as a nice-to-have, not necessary for meaningful top-line impact.

So, how does this achieve ‘myth’ status on our list – most people do speak pretty good English, right?

The problem starts with simple numbers – just 5% of the global population are native English speakers, while English accounts for over 50% of online content. Chinese, by contrast, represents 16% of speakers as the world’s most-spoken language, with fewer than 2% of the world’s top ten million websites written in Chinese. Spanish, with nearly half a billion native speakers, has just 5% of global web content.

The problem extends from online content to products themselves, with companies across the map opting to stick with English-only
content in user interfaces, marketing, user help, and support. This strategy risks making products inaccessible to vast swathes
of potential global buyers, founded on a flawed understanding of global language use and the lack of turning to the comprehensive software localization solutions.

And, when it comes to buying persuasion and product adoption, nobody captured the value of native-language communication better than Nelson Mandela: “If you talk to a man in a language he understands, that goes to his head. If you talk to him in his language, that goes to his heart.”

Thousands of new tech start-ups launch around the world each month, and of these only a tiny handful take the step to internationalize their customer acquisition efforts early.

It’s easy to see why – refining and commercializing a promising tech concept is hard at the best of times. Layer on trying to take it globally at the same time, and you’re asking for trouble, surely? Best to wait until a solid, loyal domestic customer base is established first?

In fact, plenty of successful start-ups take steps towards localizing their products earlier than many might think – and reap huge rewards. True, wholesale localization into thirty languages before developing a secure revenue stream might be a jump too far!

But making moves to capture overseas users early can help companies in competitive markets gain vital early brand awareness
and traction, shutting out rivals and being faster to identify demand.

This can involve tracking global web and advertising traffic to spot unexpected potential markets, implementing multilingual SEO strategies, translating key marketing assets (such as landing pages and product pages), or using tentative early product localization efforts to shape content and code creation best practices that ensure a smooth multilingual rollout later down the line.

However, companies choose to approach the topic – it’s rarely too early to be thinking global.

Although globally ambitious software companies typically categorize localization as an ‘investment’ (and revenue enabler) rather than
a ‘cost’ in the traditional sense, a key part of the ROI calculation remains the expense of engaging a third-party supplier to deliver services.

What’s less widely recognized, however, is how much control over cost the company itself has from the outset. Of course, vendor rates and service levels vary, and choosing the right partner is essential to the success of the project.

But the cost of a software localization project doesn’t just sit with the language service provider and their rates – it’s also significantly influenced by the ‘localization readiness’ of the product, content and internal team involved.

Businesses who consult with their vendors early to help prepare for localization stand to reduce their overall expenditure substantially compared with those who contact language partners with a finished product built without localization in mind.

Tech-focused agencies can also help customers reduce their costs massively by automating the export/import process of text for translation, using technology to build smooth systems, integrations, and workflows which accelerate delivery while minimizing expensive error-prone human steps.

By designing products for global audiences from the beginning and with the right support, software companies can make major savings in localization costs - before the project kicks off.

Understanding the place software localization process occupies in the development and release cycle is the key to building a successful global strategy. Often engineering teams focus purely on functionality and native-language UX, trusting that someone else will happily grab their work and wave their magic translation wand to get it ready for international shipment.

If only it were that simple!

Instead, localization is better viewed as an extension of product development – relating to a wide range of design and coding
decisions that will affect everything from release to maintenance and updates.
Effectively translating software (as we’ll see below) involves language teams rolling up their sleeves and diving deep into product code – and adherence to design best practices makes this process smoother, faster and cheaper.

The outcome doesn’t just make life easier for translators – it saves development teams huge amounts of time and stress if they build localization-friendly products the first time around.

Ask 100 developers for best practice tips concerning coding and you might well get 100 different answers. For every developer who’s meticulous about careful, standardized future-proofing of their code structures, there are just as many who value pace and functionality over tidiness.

“If it’s not broken, don’t fix it” (or, more accurately, don’t touch it!) is a mantra that’s enabled plenty of beta products to see the light of day. But designing software for global users is a whole new ball game. Text embedded in source code needs to be accessible for localization teams, and a world of pitfalls opens up if best practices aren’t followed.

Concatenated strings (a common time-saving developer trick of sticking two strings together in a hardcoded sequence) are a notorious stumbling block, for example, creating nightmarish complications when translators attempt to re-word code for languages which don’t follow the same syntax or grammar structure as the original source code thanks to the software strings localization interface, for example.

Localization-savvy developers will focus on internationalizing their work from the outset, creating separate resource files to help
translation teams work with carefully designed code that can bend, flex and pivot to accommodate a range of new user languages – ideally localizing relevant strings without touching product source code.

Translation technology has made huge advances in recent years, helping software localization teams achieve new levels of efficiency, consistency, and collaboration.

There are some important differences, however, between the main tools in the toolbox, and knowing each platform’s function is vital to ensure technology is playing the most effective role possible in the overall process.

Often CAT tools (Computer Assisted Translation) and MT (Machine Translation) get muddled up, when in fact they serve quite separate purposes.

Machine Translation is what it says – text that is automatically translated by a computer algorithm with no human involvement. MT has advanced impressively over the last few decades, but rarely delivers an output that is comparable to the accuracy and readability of a professional human translator. As such, MT ‘hybrid’ models may be used, where computer-processed translations are reviewed and corrected by a human being.

CAT tools, on the other hand, refer to a range of software applications that enhance a human translator’s ability to translate quickly and accurately. The group includes tools like Translation Memory (technology which stores previous translations of words and phrases to accelerate the translation of repeat content) and terminology databases (helping translators maintain consistent use of language and approved translations within complex texts).

Investing in the development of TM databases can create big efficiencies in the long term – as companies build a repository of translation data with their agency, they receive bigger and bigger discounts with each subsequent project for the phrases and words already translated and consolidated in the database.

Think of it as a translation dividend!

Both MT and CAT tools have their roles to play in large commercial localization efforts, but each solves a different piece of the overall puzzle.

User language is only one element of localization, and customers who technically have the same native tongue can have very different needs and buying behaviors.

Spanish-speaking customers from Madrid inhabit a very different social and economic reality from those in Uruguay or Costa Rica, while English-speakers from London may differ hugely from their counterparts in Los Angeles.

“Locale” includes factors such as currencies, alternate spellings, images, references, punctuation, and grammatical differences, and ensures a truly native experience where basic language translation would leave noticeable gaps.

Without a carefully planned localization strategy that keeps multilingual product use in sight from the beginning, errors caused by embedding translatable text in source code can multiply with the number of target languages for translation.

While in traditional monolingual software development and testing, one bug means (hopefully!) one issue to fix, in multilingual product engineering the game changes altogether.

A poorly localized product may throw up a glitch at the test stage, affecting every one of the translated product versions (and often in different ways).

One bug no longer means one issue to fix – it can mean ten, twenty or thirty!

The right approach to software development for a global audience helps eliminate this risk, ensuring that issues in the original design can be fixed to rectify all versions smoothly.

User language is only one element of software localization, and customers who technically have the same native tongue can have very different needs and buying behaviors.

Spanish-speaking customers from Madrid inhabit a very different social and economic reality from those in Uruguay or Costa Rica, while English-speakers from London may differ hugely from their counterparts in Los Angeles.

“Locale” includes factors such as currencies, alternate spellings, images, references, punctuation, and grammatical differences, and ensures a truly native experience where basic language translation would leave noticeable gaps.

Using icons to replace text can look like a crafty shortcut to keep translation costs down and create products and materials which communicate universally.

When it works, it’s great – simple symbols that are recognized around the world make a big impact on usability and help customers from any language or region get to grips with new product interfaces.

But there is a catch – it’s not always as easy as it looks.

Plenty of icons from buses to mailboxes to traffic symbols may seem self-evident to local-market development teams but be unrecognizable to users in another country.

Even worse, some icons (such a hand signals and gestures) can be unintentionally offensive or have a local resonance that is unknown and unintended.

Where icons form a core part of product design, localizing this art then falls outside the parameters of linguistic adaptation, forcing a re-think of interface graphics which can delay progress and inflate costs.

A big part of the value external localization agencies deliver is their access to world-class translators who can convert source content seamlessly into what feels like a native language experience for foreign customers.

But even the elite of the elite can’t operate without the proper context, and positioning translators to do their best work is an integral part of a successful localization program.

Does ‘exit’ in English mean ‘to exit’, ‘an exit’, or the command ‘exit!’?

Without context, it’s impossible to know!

These and other problems scale in complexity when translating complex technology products, where translators can’t typically view.

Adding comments and notes to localizable files helps solve the issue, ideally delivering them directly inside source files or as code comments, depending on the file type.

Combining notes with glossaries and style guides preps translators to produce faultless work first time around.

Choosing a vendor with the right sector experience is also critical – many companies waste important time and budget on ‘training’ their agencies to understand their business, market, and vocabulary.

A language provider with prior experience handling projects in the same commercial domain hugely reduces this obstacle, both during project launch and during delivery.

One of the hardest parts of getting software localization right is deciding where dividing up workload help and where it hinders.

When it comes to reviewing translated files and products, sharing the burden across a team of internal linguists can often cause more problems than it solves.

While it may seem as though splitting up tasks helps accelerate completion, monitoring language accuracy, style and consistency is
a difficult challenge to spread across a group of experts who may all have a slightly different take on what ‘good’ looks like.

While linguistic and functional testing can usually be safely assigned to teams of expert testers, it usually works best to dedicate a single senior reviewer to each language and ensure they’re involved from the outset – owning style guides, glossaries, and translation memories.

There’s a heavy weighting in most localization guides (this one included) on the need to design workflows and processes right in order to achieve effective, scalable localization process without breaking the bank.

And for good reason – the wrong tech, the wrong sequence, and the wrong underlying code architecture can send well-intentioned
software localization programs spiraling off course, missing release deadlines and blasting past assigned budgets.

But the source content itself plays an important role and adhering to some core rules to keep content simple pays big returns in the language adaptation process.

A few examples include:

• avoidance of noun/verb confusion (many English words can either be ouns or verbs, such as ‘file’ or ‘design’)
• steering clear of ‘noun strings’ (groups f nouns strung together as modifiers, e.g. ‘National Computer Security Association’s consumer data opt-in usage policy’)
• focusing on consistency of noun use (avoiding multiple synonyms for the same thing)

With these guiding principles, many of the time-consuming translation conundrums that slow down localization projects can be safely dodged.

As with single-language product releases, testing is a fundamental part of the localization cycle. Before a product, version update or new add-on can be rolled out to international users, it must first be exhaustively tested to ensure that it looks, feels and behaves as though it had been designed and created in the target user’s own native locale.

The good news, however, is that product teams don’t need to wait until the final hour before testing the outcome of their localization efforts.

‘Pseudo-localization’ is a process that allows developers and linguists to conduct a trial run and see how a product’s UI will look after localization, without the need to engage any translators or perform any actual translation.

It works by simulating translated context with an altered version of the source language, giving engineering teams the chance to test the ‘localizability’ of their build process as they code. This helps flag up bugs or incompatibilities (such as character display, text expansion, string truncation, etc.), ensuring a product and UI are developed that will fit smoothly into the live software localization process when complete.

Last but not least, no myth-busting guide would be complete without debunking the belief that all software localization companies fundamentally offer the same thing.

Language Service Providers (or LSPs) vary enormously in how well matched they may be to a particular client project and vetting and selecting the right vendor is a core part of getting software localization process right.

When settling on a language partner, software companies should evaluate prospective agencies for experience and competency, looking at:

• Technology – do they have the tools and expertise to leverage best-in-class language platforms to accelerate workflows, save costs and ensure consistent outcomes?
• People – do they have the depth of experience across their team to deliver, across sales, project management, engineering, and QA?
• Experience – do they have a demonstrable track record completing similar projects, backed up by case studies and customer references?
• Harmony – will they adapt their processes and culture to fit in seamlessly with the customer team?