A typical software UI string is short, ambiguous, and may have length restrictions. For example, a term like ‘application’ could have different meanings such as for example ‘software application’, ‘job application’, or ‘to apply’. Translators can only provide a correct translation if the context is clear. If not, they’ll guess or query. Therefore, besides an ID-based localization process, visual context is one of the key requirements to efficiently localize software applications.

Translation editor

Translators receive translation tasks from project managers in the form of physical files, or a task in an online translation editor. Once opened in the translation editor, the translator sees a table with source texts and translations. The translation environment provides additional information about the selected text, such as its software string ID or a comment that the translator entered. Connectors to translation memories (TM) and machine translations (MT) provide suggestions for untranslated texts.

SDL Trados Studio translation editor

UI texts are short, ambiguous, may contain variables, and can have length restrictions. The order these strings are presented in an editor can be in a random order. Without context, it is very hard for a translator to provide the right translation.

To query or not to query…

In many cases, translators ask the translation project manager for more information about specific texts to be translated. The project manager on his turn then may need to request information at the developers. Use-cases from our customers revealed that an average query takes about two hours to handle. This time could be acceptable for a smaller application that must be translated in a few languages, but it may result in significant costs and delays for larger applications with many target languages.

Translators usually get paid per translated word. Without a monetary incentive to spend time on research how a specific term is used, translators tend to keep the amount of queries to a minimum. This process results in more errors that are detected later in the process by other stakeholders, such as language testers who test the live application.

Queries result in productivity losses and costs, whereas a lack of queries from translators results in more work to fix issues later in the process. The later in the process the issues are found, the higher the costs to fix those issues.

Context types

Context is basically any information that helps a translator to provide a correct translation. Examples are a description and a screenshot. In particular cases, the developers may provide a description with particular source texts, but such a description is usually not sufficient for translators.

Ideally, when a translator selects a text in the editor, he would like to see a preview, containing the current translations in the editor and the selected text highlighted. When he adapts the text, the preview will be updated automatically.

The Rigi extension for SDL Trados Studio provides software translators with an interactive HTML Preview

Our customers revealed that that context reduces the amount of queries by translators over 50%.

How to create context?

Domain experts have knowledge where software texts appear in the user interface of a software application.

Many texts types like error messages, may be hard to show on the UI. In those cases, it would probably be the easiest to provide a contextual comment.

Another challenge are variables in UI texts. For example, variable {0} in ‘{0} plays.’ will be substituted with the full name run-time. Without that information, the translator has no clue how to translate the string.

Each text in a software application has a unique string identifier. Ideally, we need a preview for each of those string identifiers. An approach could be that developers capture screenshots and (manually) associate screenshots with a string identifier. A translation tool could then show that information to the translators. This approach has significant drawbacks. First of all, the previews are static (not interactive), which means that translators cannot see how their translation would look like on the user interface. An even bigger problem is the required efforts of developers to create and to maintain the previews, especially if screens in the UI change. The amount of work will increase when the application grows.

Context for translators should be independent of development processes. It should be accessible, even if the application is not operable. We need a system that can capture previews, recognize which strings (by identifier) it contains and store those previews.

Automation

In most cases, developers have automated test environments in place, where scripts execute the application. During those tests, most pages of an application are visited. Ideally, we would like to capture contextual information during that process that results in a set of previews where we know exactly which strings are shown on it. Extending this process shall not impact the existing scripts, nor should it significantly slow down the testing time.

The right tool to translate UI texts

The right tool must at least support visual localization of UI texts. When a translator selects a text, he should immediately see in interactive preview with the current translations. The variables in that preview shall be resolved with the value at the moment the preview was created.
In this interactive preview, the translator should also be able to select texts. If he spots another issue in the preview, he should be able to select that text within the interactive preview. When the translator selects a string a preview, the translation editor will select that string, so that the translator can immediately adapt the translation.

In some cases, such as translating languages from scratch, an interactive translation preview for a live web-application works as well. Translators can immediately start and navigate the live site. This approach requires that translators have access to the live system, the right permissions to access particular areas, and knowledge on how to operate the application. This approach may be suited in case of in-house translators. Typically, developers are not fond of providing translators access to a live application.

Related articles

Embracing an agile localization approach

Software localization teams face increasing pressure with agile development processes. In a continuous release cycle, new software features can be released daily, sometimes even multiple times per day. However, traditional localization workflows struggle to keep up with this accelerated pace if the goal is to only ship localized versions that…

Read more >

Improve your UI Localization using Rigi with LDX hub

Advantages of Localizing UI’s While Confirming Screens Guest contribution of Kozo Moriguchi, President and CEO of our liaison Kawamura International in Tokyo, Japan Software localization typically involves translating a variety of materials such as online help pages, training materials, marketing content, usage statements, labels, and user interface (UI)…

Read more >

Internationalization testing with your Figma design

Use your Figma designs to test if your user interface is ready for a global rollout.

Read more >