Behind the scenes: an insight into website localization and software translation

Translation Management


There is a saying in English: “practice what you preach”.

With the rebranding, we have moved to a new home website Moving over to an existing website is not as simple as it may sound. The change involved producing a lot of new content, and also plenty of translating, as Finnish, Swedish and Danish website versions had to be created. 

Have you ever considered that almost every single piece of text in the apps, programs and websites that you see on your devices has been translated into at least one other language, or been localized for another market? This basically means all of the text you see on the screens of your various devices, plus all the menus, drop-down lists, buttons, windows and settings.

And you can add to that the typically gigantic help texts and huge amounts of legal information you find in software, in applications and on websites. For example, the enactment of the GDPR legislation has led to companies adding thousands of words of compliance text to their websites, often in multiple languages.

Translation and localization projects for software and websites are often grand in scope, with material generally being translated into many languages at the same time. Expert services from specialized language service providers can help ensure you reap the greatest benefit from this type of investment.

Website localization for an average website can vary between 5,000 and 10,000 words. For e-commerce websites, translation projects with millions of words are not unusual, and the content frequently changes as products are introduced or withdrawn.

For our website project, we also had to be very systematic in terms of versioning, documenting every post-translation edit we made to the text as we squeezed it into the new layout, and making sure we had native reviewers proofread the finished website for errors in each language. Minor errors often result when copying and pasting text from one content management system to another, especially with rich text format.

As for software translation projects, these often encompass a million words or more, and typically include many repeated terms that can be recycled within the project. Due to the massive volume of words and frequently tight deadlines, many translators need to work simultaneously on the same project. It’s not unusual to have 10–20 translators working on the same material, which means effective project coordination is critical.

Website localization and software translation are perhaps the most technically demanding form of specialized translation service that we provide. Clients hand over text strings and manuals in a multitude of formats, such as XML files or plain text exported from a database, Excel files containing plain text mixed with HTML entities and HTM files – and many of them cannot be converted into the standard formats used by most translation tools. This means the language service provider sometimes needs to install the client’s proprietary tools and learn how to use them.

On top of that, we also need to ensure that the terminology in every manual corresponds to the terminology in the software’s user interface.


It is important to have the right translators: experts who are accustomed to website localization and software translation, who can handle demanding projects with potentially meager instructions and who can interpret the difficult language and terminology associated with these projects. They also need to be able to make educated decisions quickly and appropriately.

In the best cases, the client sends reference material and provides a contact person who can answer questions about unclear strings, for instance. Having access to this type of contact person, however, is not always an option.

In any project, there are often vast numbers of strings that may lack context or explanation, and the source text may have been written by programmers who are not native speakers of the source text language. Both of these factors can make the text difficult to interpret. Here is an example:

“Connstring missing” – this could potentially mean “Connection string”, but the translator cannot be entirely certain.

In some cases, help texts, manuals, user guides or user assistance texts have already been translated by someone else. This means the actual software application needs to be adapted to the existing translations, instead of the other way around, which is normally the case.

Even when there are existing translations and termbases available for reference, the terminology can still be challenging. Different parts of the software or application may have been translated by different translators at different times. This can lead to two source terms being translated as the same word. It usually only becomes a problem when the two source terms show up in the same sentence.

In one customer project, elevation and height had both previously been translated as the Swedish word höjd. When the translators ran into a source text that read “The map can show either the elevation or the height,” they quickly realized that they were not actually synonyms.

Within 15 minutes, the client’s project manager was able to tell us that “elevation” specifically meant “elevation above sea level”, whereas “height” meant “height above ground level”.

If there had no project manager at the client’s end, it would have taken many emails back and forth between the translator, the client and our project manager to explain the issue and find the right person to correct it. We’re firm believers in always having a direct client contact person.

For translations from English, one common challenge is that compound terms can often be written as separate words in English. So, when faced with just a string of text and no context, it can be difficult to know if a word is a verb, adjective or noun. Here is an example:

“Process variables” – is this a noun, as in "these are the process variables", or a verb plus noun, as in “you must process the variables”?

And how exactly should the following string be broken down?

“decision point item type property dialog”


For security reasons, some clients cannot include more reference material than is absolutely necessary when ordering translation services. This means, for instance, that when a client wants four new lines in their manual to be translated, they may not be able send the rest of the manual where several of the terms in the four lines are found.

In other cases, the reverse scenario presents itself: the translation agency receives all of the files, sometimes up to a thousand, and therefore has to search for the few updated strings in a vast amount of material.

For example, in a list of one or two-word strings sorted alphabetically without context, it may be difficult to see that “We” means “Wednesday” and not “you and me”.

Text in XML files has internal tags (in purple below) containing words that need to be translated. The tags indicate software (UI) terms, bold text, etc. There may also be index terms (marked in red below) in the middle of sentences that are not a part of the actual sentence, but which should still be translated.

You can see an example of the red index terms below and how these elements are impractical since they chop up sentences and impact word order in a non-idiomatic way.


Translators must be aware of how these elements are to be handled. They need to know how to use the right settings to identify problematic elements, and be aware of issues such as word order that should not be changed, for instance. In the example above, the index terms (in red) should preferably have been placed before or after the sentence to reduce the risk of misunderstanding during translation.

In software and manuals created in XML, sentences can sometimes be divided by external tags that work as paragraph markers in Word, making it impossible to merge the segments into sentences for translation purposes. Here is an example:

<para>This is a sentence</para>

<para>that continues into a new segment</para>

Many proprietary translation tools are great for project managers, programmers and engineers, but unfortunately they can be difficult and inflexible to work in for translators.

Some old tools do not allow the use of translation memories, so translators have to make notes and search for terms manually.

Last but not least, there is frequently a great deal of time pressure involved in the software translation and website localization process. For many software companies, “sim-ship” is very important, which means simultaneous release of a product and supporting material in several languages.


Many translators might need to work on the material simultaneously. To avoid inconsistencies, the translation service provider needs to have good quality assurance procedures in place to ensure questions are handled appropriately and linguistic reviews of the translations are performed.

In the past, each individual translator had a local translation memory which needed to be exported frequently (generally daily), and then be sent to the translation agency coordinating the whole project. The individual translation memories would then be compiled in an updated memory and redistributed to everyone involved.

Since so many translators typically work at the same time on a project, keeping track of all the new software terms and making sure that all of the translators used the same terms for buttons, menus, etc. was a demanding task.

Nowadays a large group of translators can work simultaneously using the same translation memory – and get instant access to shared terminology. This is naturally a great advantage since the number of inconsistencies is significantly reduced.

It is important that the source text uses consistent terminology to avoid confusion at the translation stage, and to avoid situations where there are two or more source terms for a single target term.

It cannot be emphasized enough how important it is to use termbases and glossaries. Many glossaries in Excel can quickly and easily be converted into a format that the translation tool can process, which can save the translator a lot of time. The termbases can be used to perform automatic searches for incorrect translations as a quality assurance step, which is a very helpful feature.


Translation agencies also use the QA (quality assurance) tools and processes that are built into their translation tools and programs. Examples include terminology and formatting checks. Translators still need to use their very best judgement since many QA tools cannot cope with inflected or compound words, and many assume that the grammar of every language is constructed in a manner similar to English. As guidance, however, QA tools can be invaluable.

A few words from one of Acolad’s experienced localization engineers:

“Our translators have many years of software translation experience in a vast number of specialist areas, and they are extremely accustomed to searching for new terms as well as establishing new terminology together with clients. They are also used to learning new tools. We may not know everything, but we certainly know how to find out”.

And finally, don’t forget to check out our website!

Find out more about our localisation services