When it comes to the translation process, what comes first – translating the UI or translating the documentation?

For many organizations, it is common to translate the user interface strings prior to documentation. Because UI strings are typically available well before the documentation, they are usually sent off for translation before documentation. Oftentimes, text is entered into a spreadsheet, along with screenshots or comments elaborating on the nature of the string. While this may provide some detail, the translator still lacks understanding behind how UI strings work in context of the software.

There are some disadvantages that come with translating the UI strings prior to documentation. A lack of understanding behind the UI string can lead to improper translations, adding more cost and time downstream. In an ideal world, every translator, SME, and technical writer would be active users of the software, minimizing the chance of error. However, this is usually not the case.

Why Context is Important

For any translation project, context is essential. The translator may not have a chance to interact with the software directly, especially if the software is under development. Most likely, the only reference he or she has is a spreadsheet of text, along with any screenshots or comments that may have been included.

However, text alone is sometimes not enough to provide an accurate translation. The following are examples of terms that are difficult to accurately translate solely based on a UI file or spreadsheet:

Solid. The word “solid” can be used to refer to a variety of terms, depending on the context. For example, it could be used to refer to a “solid line”.

Start. Is this being used as a verb or a noun? Or as an imperative, prompting the user to take an action?

Add New. Depending on the language, the translator needs to know what is added, because the translation of the word “new” must be grammatically adapted to the gender of the noun that’s added. In German, the translation of the word “new” changes with the examples “Neue hinzufügen”, “Neues hinzufügen”, “Neuen hinzufügen”, etc.

Opening {1} will close {2}. The translator must know the words that could be filled in for {1} and {2} in order to correctly adjust the gender of the translation.

Proofing. Is this a noun, or the present participle of the verb? In most languages, both versions of the word needs to be translated differently depending on the context.

Load Error. Does this mean an error happened while loading, or is this a command to load an error message?

In addition, the differences in text length in languages also play a role in facilitating translation. For example, text in English may vary in length compared to other languages, such as German, Danish, or Greek. Depending on the translated language, this may have an effect on how it displays on the user’s screen. With context, the translator can provide recommendations that better fits the desired action.

The Benefits of Translating Documentation Before UI

A key advantage of tackling UI string translation once the documentation is finalized is that it provides much-needed context for the project. For example, the translator can translate documentation and simultaneously enter UI-related strings that appear in the documentation into a termbase. After the documentation has been translated, the remaining UI strings are translated, which in many cases, is facilitated with the context provided by the documentation.

With context, the translator is able to have a deeper understanding of the software, leading to the following benefits:

Streamlined workflow between teams. Having translated the documentation, the translator most likely has knowledge of the software. This reduces the number of questions from the translator, and consequently leads to:

Increased accuracy and consistency. Understanding of the context lets the translator provide translations that read naturally, improving user experience.

In the end, the translated documentation serves as a valuable resource for the translator. It provides a reference for ambiguous text, or words that may have multiple meanings in different languages. Handling documentation prior to UI enhances the benefits of in-context translation, allowing UI strings to be interpreted as intended by the end user.  

Tip for MadCap Flare Users

Using MadCap Flare in your translation workflow? One option for MadCap Flare users is to identify UI references to use and create a defined span tag with a certain class which is only used for flagging UI strings (e.g. <span class=”UI”>. Apart from making UI strings more visible to the reader, translators can more easily extract those terms from the Flare XML files for various reasons, like term checks and so on.


All projects are different and carry their own nuances. However, the case to translate UI strings after documentation introduces additional benefits to the translation process, such as context, increased accuracy, and reduced effort. 

About The Author

Mike McDermott

About Mike McDermott

Mike McDermott, Director of Language Services for MadTranslations - a division of MadCap Software - leads the localization production teams. Mike’s experience in the technology and language services industry includes working on US federal government technology initiatives and growing private commercial business units. In his spare time, Mike enjoys spending time at the beach, reading, and outdoor activities.

Last Modified: February 28, 2018

This entry was posted in MadTranslations, Translation. Bookmark the permalink.

Have Something to Say?

Your email address will not be published. Required fields are marked *