Russian Dolls

How not to translate an Android app

Uomo con tablet

Recently, we came across a striking example of the disconnect between translators and programmers, or at least, between people who translate and people who need multilingual apps.

In fact, we received a consultation request from a fellow translator who had to translate the strings of an Android app, whose name we cannot mention here for confidentiality reasons.

The software house needed the app translated into ten languages and asked this translator to translate it into their native language.

As previously explained in our article “New language wanted: how to ask for translation services”, most are not familiar with the translation industry, and misunderstandings or problems caused by lack of familiarity with best practices abound. In this article, we want to help give a clearer picture of the inner workings of the translation industry.

Whoever was responsible for managing this app’s translation had an idea (which they probably thought was brilliant): insert all text strings meant for translation into an Excel file.

This is a rather common practice among those who manage multilingual development projects. They think they are making work easier for the translator. Unfortunately however, pasting strings for translation into an Excel is almost never the right choice.

To see what this looks like, just look at the screenshot below.

Excel file with XML content

The strings inserted into the Excel file were in turn already contained in an “Android Resource”-type XML file.

When the translator opened the Excel file with their usual computer-assisted translation tool, what they were actually confronted with was a large amount of code that should then have been ignored (kept), as the translated app would not work without it.

Screenshot of translation in OmegaT

At this point, we need to make a quick digression for those who are unfamiliar with how translators normally work.

How technical translators work

Most technical translators use special software that bring several tools together into one interface:

  • a database of previous translations
  • one or more glossaries
  • a spellchecker
  • a grammar checker
  • and many more functions.

These programs are called “CAT tools” (from Computer-Assisted Translation) or “translation memories”, as they save all the work done in a real digital “memory” so it can be reused later.

These tools should not be confused with automatic translators like Google Translate, which do not involve any human input. CAT tools may also contain a window displaying the results of an automatic translation, but this function is just one of may available to (human) translators.

Additionally, CAT tools can open and recognise many file formats, which gives the translator a “tidy” view of the content that needs translating. They therefore hide all elements that translators should ignore, like programming code, HTML tags, comments, etc.

Let’s come back to our project.

In the case at hand, opening the Excel file sent by the client sort of causes the assisted translation tool to “short-circuit”. The programme thinks it is reading a standard spreadsheet, and displays all the content contained in the cells.

However, this content includes the tags and code from the XML which, as seen in the previous screenshot, should not be translated.

How did we solve the problem?

First, let’s remind ourselves of where the problem lay.

“Android Resource” is one of the formats that can be read by translation programs. Pasting the content into an Excel file is completely pointless, as the programme would be able to open .xml files directly.

Rather than making this kind of “Russian doll” file with an XML within an Excel, the person in charge of managing the translation project could simply have sent this XML to the translator directly and clarified that this was an “Android Resource” file.

To resolve this issue, just save the Excel file as a basic text file, make sure to use UTF-8 encoding and the right file extension: .xml.

With that, the file can be opened by the translation software and the translator will only see the parts meant for translation. This is how the same file looks in OmegaT, a free and open-source assisted translation tool which we talk about often on this blog:

Screenshot of a translation of an app string in OmegaT

Unlike the preceding image, the strings appear separately from the tags and code. The translator can focus on the content without fear of damaging the source code.

Some advice for when you need an app translated

Before sending the content, those developing apps for Android or iPhone should get in touch with their translation provider and ask whether strings for translation can be translated directly from their native format. Given how sophisticated modern assisted translation tools have become, it is highly likely that the translator will be able to work directly from the file.

Even in cases where the source file cannot be opened directly, there are methods (as we have discussed in other articles like “How to Translate a Moodle Course” and “Translating XML Files Painlessly: Mission Impossible?”) for extracting the translatable content, making it available to the translator, and then reinserting it into the source file, which also save a lot of time for those needing translation.

We can help you translate your Android app. Contact us for a non-binding quote.

Technical translator, project manager, entrepreneur. Languages graduate with an MA in Design and Multimedia Production. He founded Qabiria in 2008.

Further Reading

Chat to one of us

Let us know what you need by sending an email to hola@qabiria.com or by filling in the contact form. We guarantee a response within 24 hours, but usually we’re much faster.

Contact us