cell phones with different languagesWhen most of us think of translation, we immediately picture the translation of documents—legal papers, brochures, flyers—where all the text to be translated is presented in context. Modern day source texts, however, come in various forms, such as HTML-coded websites, marketing designs, and user interface (UI) strings from all kinds of mobile and online apps. The latter can be especially challenging for translators. Think about an online survey. Each part of the survey is a separate component from a development perspective. Each drop-down list must be translated individually. Many of the strings have blanks that must be filled in with variable text that could depend on the previous response. Without any context, a translator may not understand the relationship between one component and the next.

The same issue arises when we look at localizing an e-learning module or translating any online or mobile app or video game. Often, the translator is handed a list of strings with little or no context. The translator may not be able to interact with the actual app, module, or game if it is still in development.

Providing context with comments

Customers who produce this kind of data can reduce a translator’s stress and speed up the translation process by including some information about the individual strings. Often, these UI source strings come to us in the form of an Excel spreadsheet. If possible, it is ideal if the customer can send screen shots of all UI screens. The customer can also simply insert a “Comments” column into the sheet where they can elaborate and give context. Remember: the shorter the string, the more difficult the translation, so it is important to give as much detail as possible. Below are some helpful suggestions and guidelines on what to include in such a “Comments” column:

  • which element of the interface it is: button, title, error message, list item, etc.
  • whether it is a placeholder or a variable (List all the different values that variables may take at runtime. Gender and number apply to all nouns and adjectives in many languages and may affect the translation!)
  • specification of gender, name, and thumbnail image, if available, when referring to a person or character
  • explanation of idiomatic expressions
  • explanation of ambiguous terms appearing alone or without context
  • part of speech
  • character limit

Here is an example of a source string for which the client provided helpful and necessary context:

err_InvldEmail Enter a valid [&1]. This message displays if an email address is not entered. The following information will populate for this message: [&1] = email address.

Without this additional detail, the translator would be clueless. They would ask the client, “Enter a valid what?” In English, this is not a problematic string because the adjective “valid” does not need to agree in gender and number with the noun. However, in a Romance language like Spanish, French, or Italian, the adjective must match the verb.

Let’s take Spanish as an example. In Spanish, the adjective “valid” can take the following forms:

Masculine Feminine
Singular válido válida
Plural válidos válidas

In this case, we know from the comments provided by the client that the missing word in the string “Enter a valid [&1]” is “email address.” “Email address” translates into Spanish as “dirección de correo electrónico.” “Dirección” is singular and feminine. Thus, we can appropriately translate the string, leaving the placeholder, and be assured that the article and adjective agree with the noun that will be dropped into the string later.

Translation: Introduzca una [&1] válida.

Had there been multiple possible alternatives to drop into the blank space, the task would be more complex, as the translator might have to provide various alternative translations to accommodate different gender and number combinations.

Of course, Excel files are not the only way to provide strings for translation. Android’s localization checklist for developers recommends keeping all of your default strings in a strings.xml file which can be easily translated. Comments in the XML file should provide any necessary context for the translator, for example:

Localization Testing

While providing context is very useful, we also recommend localization testing on all user interface translations by native-speakers. Even when context is provided, linguistic errors can slip through the cracks. And there may be other types of errors introduced: visual (truncated text, incorrect line breaks) or functional (menu functionality, string manipulation). A competent linguist must interact with the dynamic interface in order to discover these potential flaws.

Related Posts: