What is software localization? Top 5 questions (and answers) to get it right

When you’re just starting to develop a software product, you might not give a second thought to providing it in multiple languages. But the bigger you grow, the more critical it becomes. After all, only 20 to 30% of Internet users speak English — and ones that don’t are pickier than ever. Today, they expect high-quality local-language versions of the websites they visit and the apps they use.

So what are the things you need to know to get started with software localization, or even figure out if you need it? Read on to find out!

What is software localization and do I really need it?

Software localization — often abbreviated as “L10n” — is the process of adapting software to a specific culture. Unlike translation, it involves things such as:

  • Writing directions (e.g. right-to-left for Arabic or Hebrew),

  • Date and time formats (e.g. “23/01/2020” vs “01.23.2020”),

  • Currency formatting conventions (e.g. “50 euro” vs “€50”),

  • Address formats, input methods, decimal separators, etc.

In another sense, localization considers culturally sensitive aspects that go beyond translation. For example, the emoji 👌, which stands for “Okay” in the Westen world, is considered a vulgar offensive sign in some Arabic countries. There are also many other examples with images, symbols, or even unexpected brand name connotations.

As for the second part of the question, you might not need to localize your software right now, depending on where your business is. But think of Facebook, which initially started as a lighthearted app for Harvard students and is now one of the biggest social media platforms on the web and localized into 100+ languages. Could Mark Zuckerberg see it coming? Maybe, maybe not.

Ask yourself: “Can my app be potentially beneficial for users outside the English-speaking world?” If the answer is yes, this means localizing your software, when the time is right, could become a huge growth booster. But to make the process as painless as possible when you do localize your software, you first have to internationalize it. We write about it below.

What is internationalization?

Whereas “localization” means making a piece of content of software suitable for a specific foreign audience, “internationalization” means thinking ahead to make this content or software easier to localize in the first place. For example, you could write your mobile app with all the strings hard-coded and rebuild it with different strings for every language. But this represents a very poor internationalization system.
(From the Translation Industry Glossary.)

Some things to consider during internationalization are:

  • Support of foreign characters sets,
  • Externalizing all displayable text in string variables,
  • Agreeing on the file formats that will be used for strings,
  • Adopting a single-source publishing approach,
  • Avoiding code whose execution depends on a specific locale,

You might also want to consider the following:

  • How will the user select the locales?
  • Is there a fallback if there are no strings in a specific locale?
  • Do you need to change your database architecture?

But internationalization is not just a one-off endeavor. It should permeate your whole development process, and even mindset. Consider an example of showing the number of items in a user’s cart. A “non-internationalization-aware” coder might concatenate the message as:

"You have" + number + "item(s) in your cart"

In this case, the “You have” and “item(s) in your cart” parts will go into different strings, causing all kinds of problems when translating this to other languages. In some languages, the natural way of expressing it would be “Your cart has … items”, so the order of the strings must be switched, — but this is just impossible with strings set up this way!

Thus, an “internationalization-aware” coder will go with something like:

"You have %d item(s) in your cart" % number

The whole phrase now goes into the same string, and translators can modify it to suit the target language’s structure. (This leaves a question of pluralization and placeholders, but that’s a story for another day.)

Do I need a dedicated localization team?

Probably. While it might be tempting to assign the internationalization and localization as a part-time task to some of your existing engineers, the amount of work might turn out to be more than you or they expected. Software localization concerns a broad range of issues, from UI to helpdesk to customer support, all of which must be handled in a coherent and organized way.

Ideally, the localization team should consist of at least three people:

  • Localization engineer, who builds all the workflows needed to enable smooth and quick localization.
  • Project manager, who monitors daily activities related to the translation of strings.
  • QA manager, who makes sure that the localized strings meet the desired quality standards.

If you can’t afford the full set, you can also consider outstaffing some of these functions — Smartcat’s marketplace is a good place to start your search.

How do I actually translate the strings from my software?

You don’t have to, there are people trained to do just that. First, there are translation agencies; second, there are freelance translators. There are also platforms that take the organizational load off your shoulders, so you don’t have to send files back and forth to/from each of them. Smartcat is one such platform, and we suggest that you take a look at it if you still haven’t. For some other options, you can check out this blog article.

Wondering which languages to translate to? You should probably start with 5–10 “short-tail” languages, i.e. languages that are most spoken in the world and on the web — for example, Chinese, Japanese, Spanish, German, French, Portuguese, Italian, Russian, Korean, and Arabic. Sometimes, though, depending on your product and audience, you might want to exclude some of the European languages in favor of more Asian ones, such as Hindi, Malay, Vietnamese, Indonesian, or Thai. This is especially useful for video games and game-like software, the usage of which is noticeably skewed “eastward”.

One thing that will definitely help the quality of your localized content is having a style guide for your translators. It should spell out what your product and brand is about, who your main audience is, what tone of voice you want, which terms you want to translate, transliterate, or kept as is, and so on. This will require some upfront investments but can save you from some embarrassing faux pas in the long run.

What does the actual software localization process look like?

The possibilities are many, but there are two major approaches: manual and continuous localization.

With manual localization, the localization project manager downloads strings from your software every once in a while. Usually they also need to issue a “string freeze” call to the software engineers at the same time, to make sure that no new strings make it to the release untranslated.

After downloading the strings, the PM either uploads them to the translation platform or sends them out to your language service provider (LSP), aka translation agency. The former case usually takes less time, as the uploading and assignment process is automated. Once the translation is done, the PM downloads the translated strings and pushes the content to your string repository, where you can merge and ultimately publish it.

The other option is continuous localization, a process in which any new software strings get pushed to the localization platform and, once translated, pulled back to the string repo. This saves hours of manual work and reduces the risk of human error. The drawback is that setting up a proper continuous process might require experienced localization engineers. Smartcat offers localization engineering assistance under some of its subscription plans, so you might want to check those out.

Then again, not all software companies need continuous localization. If you follow traditional development practices, with waterfall milestones and regular N-monthly release cycles, you could do just fine pulling and pushing strings manually. But if you are closer to the Agile end of the spectrum, continuous localization is definitely something you should consider.

So, we hope this was enough to get you started with software localization. You can also read more about some related terms in our industry glossary, but don’t hesitate to ask us for more. Drop us a line in the comments section or email us if you have a specific request.