In this article, we take a look at the pros and cons of one of the most popular formats for storing and handling localized strings to help you decide if it’s a good fit for you.

When you’re just starting to develop your app, localization might not seem like something you have to think about much. But this comes at a cost later: As you grow and eventually decide to translate your software to other languages, you might find yourself with a plethora of strings that you have no idea how to deal with in other languages.

As a result, you have to invest extra time thinking about what to do, you cannot make quick changes to the localized versions of your app, and end up with low-quality translations because you haven’t provided the translators with the right context to get the job done.

To avoid these pains in the future, it’s important to think about localization, or at least internationalization, in the very first phases of development. And the main question is: What localization format should you choose?

Below, we take a look at XLIFF, one of the most sophisticated formats for software localization. Unlike JSON and YAML, it is not well-known among software engineers and developers. So, should you still consider using it? Let’s find out.

What does XLIFF look like?

An OASIS standard, XLIFF — XML Localization Interchange File Format — is the de-facto language industry standard for exchanging localized strings between applications. As such, it has the highest level of support in most translation tools and has the most comprehensive solutions for the most common localization issues. Companies such as Apple and Microsoft choose XLIFF as the basis for their internationalization frameworks.

As the name suggests, XLIFF is an XML-based format, meaning that any parser that works with XML will work with XLIFF as well. This makes it easier to use for both translation platforms and for localization libraries.

Here’s what a typical XLIFF looks like:

The main parts of an XLIFF file are <segment> and <unit> elements, with the former containing the smallest indivisible “atoms” of text — say, sentences, — and the latter grouping them into bigger, “molecular” elements — say, paragraphs.
Each <segment> contains the <source> and <target> elements, containing the segment text in the source and target languages, respectively. (Note that, unlike translation memories, an XLIFF file can contain only one target language, so there is no such thing as a “multilingual XLIFF”.)

Another important element is <note>, which allows you to add comments that might help translators understand the context. For example, the text “Sign in” can refer to a button title or a window caption, which, in some languages, will mean a different grammatical form should be used in each case.

Finally, there’s the id attribute, which allows you to uniquely identify each string in case you’re using key-based internationalization. (The alternative is default language-based internationalization, which has its pros and cons but is generally less popular.)

Integrating XLIFF into your code

Now that you know what an XLIFF file looks like and are familiar with its basic elements, it’s time to integrate it into your code. Here’s a list of popular development environments with their level of XLIFF support:

  1. Objective C and Swift — used for developing iOS and Mac apps — support XLIFF 1.2 specification via Xcode. XLIFF 2.0 is not supported.
  2. Angular also natively supports XLIFF 1.2 but not 2.0.
  3. React has a converter between its native format and XLIFF.
  4. So does Polymer.
  5. Vue does not support XLIFF, and we weren’t able to find any trustworthy libraries that allow conversion between XLIFF and Vue’s i18n plugin.
  6. Node.js has plenty of XLIFF packages to choose from.
  7. Ruby has a few gems for XLIFF conversion and/or import, too.
  8. C#: The XlfParser library can convert XLIFF files to C# resource files.
  9. Java and Android both use different approaches to localization but can utilize the OpenXLIFF set of filters to process XLIFF files.
  10. Python has very few XLIFF packages, and it is not clear if they are well-maintained.

So what are your options if your development platform does not support XLIFF?
The first one is obvious: Don’t use XLIFF. Although it is indeed the most standardized and well-thought-out localization format, modern translation tools such as Smartcat can easily work with other file formats, be it Android XML, JSON or even YAML.

The second option is to use a standalone converter such as the already mentioned OpenXLIFF — or write one yourself. After all, XLIFF is nothing but an XML, and there are plenty of libraries that support working with XML files for any language and environment out there.

Finally, you can use different formats for different environments while synchronizing their translations during localization using translation memories.

XLIFF localization process

Now that we have our internationalization framework built around XLIFF, you probably want to translate these strings. To have an XLIFF file translated, you first need to open it with an XLIFF editor or translation tool.

Below, we show you how this is done in Smartcat. So, first you upload your XLIFF file:

You can then invite and assign people to translate your strings to the target languages. (Smartcat has no limits on the number of users.) These can be your own in-house specialists, your community members, or freelancers you invite from Smartcat’s marketplace.

Each translator will see the document in a bilingual editor, with source elements on the left and target elements on the right:

Once they have entered all the translated text, you can download the XLIFF file again and push it to your repository.

“What if we are Agile developers?”

Now, if your company has adopted an Agile development process you might not want to waste time manually pulling your XLIFFs, having them translated, and pushing them back to the repository.

You can configure a continuous localization process, where strings are synced automatically between your repo and the translation tool of your choice. In the case of Smartcat, this is done through a Serge+Smartcat bundle. What sort of results can you expect? Well, Kaspersky was able to cut their hours of localization by six, so you decide.

Long story short

Though verbose and sometimes obscure compared to, say, JSON or YAML, XLIFF can boast the biggest support among translation tools. So if you want to approach software localization systematically and consistently, spending the extra time setting up an effective XLIFF localization process can pay back and produce faster and higher-quality translations in the long run.

What do you use? Are you going to give XLIFF a go? Let us know in the comments!