Documentation Localization: Background and Methodology

Welcome to the latest in the series of “Localization: The Definitive Guide”, a complete step by step guide to the localization of websites, software and it’s components. In this article we will deal with the translation of documentation associated with software. We have already dealt with the localization of software and Online Help. Again, the localization of software documentation ties in with the localization of the software or User Interface and the Online Help. The documentation of software may include User Guides, Quick User Guides, CD-ROM covers and Box text and any other marketing material. Just to refresh a SIM ship release is where the language versions of the product are released to their respective markets on the same date as the original version. As one can imagine cross referencing with other localization components is crucial ensuring that all components are consistent with each other. It’s also important to bear in mind how astronomical the cost of localization can become now, bearing in mind the amount of languages we need to deliver and the volume of words we have to translate. In many cases, companies often combat these astronomical localization costs by tying the Online Help in with the User Guides and Quick start Guides by having just one guide for all three and in some cases not even printing the User Guides. As already discussed we translate the user interface first, populate the translation memory and Glossary with the translated text and then run it against the Online Help and User manuals. However with a SIM ship version and the time constraint we need to translate the OLH and User manuals in parallel with the User Interface. The process for the translation of the documentation is very similar to the translation of a website, OLH or the User interface itself so, as mentioned previously in the OLH localization article please bear in mind that there will be some overlap between this article and the others in this series. We have already discussed the use of translation memories, resources and infrastructure and their respective influences on the localization work flow but in this article we will focus more on the formats of User Guides and an extra resource called Desktop publishing. In most cases the overlap between the Online Help and the User Guides is substantial if not the same however, the extra dimension of publishing introduced into the localization work flow causes costly and substantial changes.

1. Pseudo Localization of Manuals

As opposed to the UI and OLH the User manuals are not pseudo translated.

2. Pilot Language for Online Help Localization

We immediately begin the documentation localization process based on the language/s already chosen for the OLH and user interface. This language will define the localization process and weed out the majority of the localization bugs.

3. Translation Memory and Glossary input during Online Help localization.

The documentation localization process is similar to the Online Help and UI translation process in that the translatable text is isolated, translated and dumped back into the original format, however, there is an extra degree of complexity if there are translation Memories involved in the process and an even greater degree of complexity if the translation memory is not centralized. Please refer to translation memory input during OLH localization for more information. Also, all the engineering localization tasks for the OLH and UI involved localization engineers. For these tasks during the localization of the documentation we call on a different resource called a desk top publisher. The desk top publisher tasks include preparing the original files for translation within a compatible format for the TM environment, bug fixing and formatting, rebuilding/compiling the translated manuals, functional testing and updating the translation memories with functional and linguistic fixes. In the previous article on the localization of Online Help we took into account two types of translation memory models, Centralized and non-centralized translation memory work flows. It is here that the localization process of the manuals can vary greatly depending on the translation memory, the infrastructure and resources chosen by the translation services company.

The main formats of User Guide files are quark and frameMaker and a lot of translation memory environments can work directly with these formats.

4. Translation and Revision of Documentation

Ok, so we send the translator the translation memory compatible files to translate or access to the centralized translation memory system portal , the most up to date Translation Memory (as they need to update it with their work) reference material such as Glossaries, previous User Guides…etc.. and the translator begins translation. As discussed in the previous paragraph one must bear in mind that the process can vary in many ways when we take into consideration that the translator may be in-house or external or the translation memory system we are using. What is key is that each resource always has a reasonably up to date TM to work with to avoid duplication of work. During this stage the translator’s job remit may overlap with the publishers in that he/she may be responsible for typical localization bugs such as resizing of strings as he translates or it may be the publisher’s job after translation. The end product is an 80 to 90% localized pilot version. What adds even more to the complications of the project is whether the documentation is revised by the translation company, the client or a third party. What if the client wants to revise the User Guides? What if the client does not wish to use the translation memory process

5. Translated User Guides

During the next stage the pilot version is rebuilt for testing.

6. Localization QA - Testing of localized Documentation

Localization testing of Documentation is the same as for the software in that once recompiled the pilot version is tested for functional bugs by the Localization QA team and linguistically tested, with the UI in context, by the translators or in some cases by third party linguists. The bugs are usually documented via post-its on the pdf and sent to desktop Publishing in the case of functional and formatting bugs , or translation, in the case of linguistic bugs, to be fixed. This cycle continues until the translated software is bug free. The set-up of the phase can differ from company to company depending on the circumstances but in all cases it’s important to update the TMs with the linguistic fixes. There is an extra degree of complexity during this phase compared to the software localization QA in that the cross referencing and linking to the software is fully functional

7.

Translation of other Language Versions of Manuals

Now that we have our pilot version localized and bug free, the process is in place to translate the other language versions of the User Guides. I mentioned at the start of this article that in an ideal world the localized versions should be released on the same date as the master version however it’s usually impossible to achieve this and what usually happens is that certain languages are given priority depending on their market importance. The more important languages are called tier one languages and the less important languages for secondary markets are generally referred to as Tier 2 languages.
To summarize, I think this article gives us an idea of how close the software localization process, the Online Help localization process and the documentation process are intertwined in that every UI reference must be exactly the same in the Online Help and the user Guides and marketing materials. This article is part of a series, "Localization: The definitive Guide" from One Stop Shop Translations, which deals with the localization of each component of software, the others include:

- Software Localization: Background and Methodology
- Online Help Localization: Background and Methodology
- End User License Agreements Localization: Background and Methodology
- Software Documentation Localization(Quick User Guides and User Guides): Background and Methodology
- Website Localization: Background and Methodology

NOTE: Please note that translation and localization are used interchangeably in this article.
NOTE: Please note that documentation and User Guides are used interchangeably in this article.
DEF: Translation is the communication of the meaning of a source-language text by means of an equivalent target-language text.
DEF: Language localization is the process of adapting a product that has been previously translated into different languages to a specific country or region. Source: Wikipedia

If you like this post please "like" or "share" for more content

Mark Kieran, CEO, One Stop Shop Translations

For our latest User manual translation rates click on this link or get an economically unbeatable User Manual localization quote here.

Remember that translation of software is not just simple straight forward translation but a complicated process that involves many stages and specialized expertise!

Translation Mistakes

A production from One Stop Shop translations, Spain, displaying some horrendous translation mistakes in the commercial world that cost some companies a lot of money and embarrassment!

Online Help Localization: Background and Methodology

Welcome to the latest in the series of “Localization: The Definitive Guide”, a complete step by step guide to the localization of websites, software and it’s components. In this article we will deal with the translation of Online Help for software. Again this component ties in with the localization of the software or the User Interface (UI) and the race to release a SIM ship version of the localized product. Just to refresh a SIM ship release is where the language versions of the product are released to their respective markets on the same date as the original version. As one can imagine the cross referencing between the Online Help and the User Interface is very important. It is important to ensure that both are consistent with each other. In an ideal world we translate the user interface first, populate the translation memory and Glossary with the translated text and then run it against the Online Help. However with a SIM ship version and the time constraint we need to translate the OLH in parallel with the User Interface. The process for the translation of the OLH is very similar to the translation of a website or the User interface itself, in fact some Help systems are web based so please bear in mind that there will be some overlap between this article and the others in this series. For this article we will take the worst case scenario of a SIM ship release where both the software and the Online Help are translated at the same time. One thing in our favor is that the User interface word count is usually substantially lower than the online help word count which gives us time to ensure during revision that the references and links from the Online Help to the software reference correctly.

1. Pseudo Localization of Online Help

As with the software, one of the first steps is to pseudo-translate the online help pilot language/s. Just to refresh our memories, the pilot languages are a small cross section of languages to represent all the target languages to be translated. Please refer to pseudo translation of software here to refresh your memory on its purpose and benefits.

2. Pilot Language for Online Help Localization

Now we begin the Online Help localization process in earnest by starting its localization based on the pilot language/s already chosen for the software. This language will define the localization process and weed out the majority of the localization bugs.

3. Translation Memory and Glossary input during Online Help localization.

The online Help localization process is similar to the pseudo translation process in that the translatable text is isolated, translated and dumped back into the Online Help, however, there is an extra degree of complexity if there are translation Memories involved in the process and an even greater degree of complexity if the translation memory is not centralized. Please refer to translation memory input during software localization for additional information. Lets take a step forward and assume that our Help system has been pseudo translated, bug fixed and prepared for the TM environment. It is here that the localization process of the online Help can vary greatly depending on the translation memory, the infrastructure and the resources chosen by the translation services company. Lets take a couple of scenarios I hope will cover the majority of localization process cases.

Centralized Translation memory Model

A centralized translation Memory is a central repository of previously translated segments and Glossary terminology. The system is interactive and allows the translator to access a “live” translation memory and glossary. It means that all translation resources both internal and external work from the same TM and the translated text is updated on the “fly”. It ensures that all translators are up to date with the most current terminology and translations. Centralized translation memories are often complex and expensive to implement resulting in higher costs but worth it in the long run by cutting time, long term costs and enhancing quality and consistency.

Let’s take a quick run through the centralized translation memory process. Let’s assume we have started the user interface and online Help translation in unison. This may result in different translations for User Interface commands and options in both components. In this case the reviewer of the User interface will have final sign-off on all the UI text. If there are any issues he will discuss this with the translator of the User Interface and translator and reviewer of the online Help to reach a general consensus on the best translation and be responsible for updating the central TM. The translator and reviewer of the OLH will receive notifications of TM updates and can update their target texts accordingly on the fly. In a lot of cases if a translator is external they will need access to the centralized translation memory system by means of a portal.

Translation Memory Model (Not centralized)

The second model is more cumbersome and complicates the process as the translation memory is not centralized. It means that the translator cannot update his text while he is working. It complicates the parallel translation in that at the end of the day for instance, both translation memories differ i.e. the UI reviewer TM and the OLH reviewer TM, or may even involve syncing many more TMs for instance, UI reviewer TM, the OLH reviewer TM, UI translator TM and OLH translator TM, depending on the amount of resources working concurrently on the same text. There are workarounds but they involve extra management and process bottlenecks. For instance we could devise a process where at the end of the day a central resource takes the UI translators TM and updates it with his changes. The most up to date TM is then sent to the OLH translator and UI translator at the beginning of each day to begin their work. As one can imagine its not an ideal situation! For a demonstration on a Translation memory environment please refer to the following link.

4. Translation and Revision of the Online Help

Ok, so we send the translator the translation memory compatible files to translate or access to the centralized translation memory system portal , the most up to date Translation Memory (as they need to update it with their work) reference material such as Glossaries, previous User Guides…etc.. and the translator begins translation. As discussed in the previous paragraph one must bear in mind that the process can vary in many ways when we take into consideration that the translator may be in-house or external or the translation memory system we are using. What is key is that each resource always has a reasonably up to date TM to work with to avoid duplication of work. We also discussed in the localization of software that the translator may be responsible for typical localization bugs such as resizing of dialogues and menus and duplicate hot keys or this may be the role of the localization engineers after translation. The end product is an 80 to 90% localized pilot version. What adds even more to the complications of the project is whether the Online help is revised by the translation company, the client or a third party. What if the client wants to revise the OLH? What if the client does not wish to use the translation memory process instigated by the translation company?

5. Translated Online Help Build

During the next stage the pilot version is rebuilt for testing on various platforms.

6. Localization QA - Testing of localized Online Help

Localization testing of Online Help is the same as for the software in that once rebuilt the pilot version is tested for functional bugs by the Localization QA team and linguistically tested, with the UI in context, by the translators or in some cases by third party linguists. The bugs are documented and sent to engineering in the case of functional bugs, or translation, in the case of linguistic bugs, to be fixed. This cycle continues until the translated software is bug free. The set-up of the phase can differ from company to company depending on the circumstances but in all cases it’s important to update the TMs with the linguistic fixes. There is an extra degree of complexity during this phase compared to the software localization QA in that the cross referencing and linking to the software is fully functional and corresponds linguistically

7. Translation of other Online Help language versions

Now that we have our pilot version localized and bug free, the process is in place to translate the other Online Help language versions. I mentioned at the start of this article that in an ideal world the localized versions should be released on the same date as the master version however it’s usually impossible to achieve this and what usually happens is that certain languages are given priority depending on their market importance. The more important languages are called tier one languages and the less important languages for secondary markets are generally referred to as Tier 2 languages.
To summarize, I think this article gives us an idea of how closely the software localization process and the Online Help localization process are intertwined in that, every UI reference must be exactly the same in the Online Help. This article is part of a series, "Localization: The definitive Guide" from One Stop Shop Translations, which deals with the localization of each component of software, the others include:

- Software Localization: Background and Methodology
- End User License Agreements Localization: Background and Methodology
- Software Documentation Localization(Quick User Guides and User Guides): Background and Methodology
- Website Localization: Background and Methodology

NOTE: Please note that translation and localization are used interchangeably in this article.
DEF: Translation is the communication of the meaning of a source-language text by means of an equivalent target-language text.
DEF: Language localization is the process of adapting a product that has been previously translated into different languages to a specific country or region. Source: Wikipedia

If you like this post please "like" or "share" for more content

Mark Kieran, CEO, One Stop Shop Translations

For our latest online Help localization rates click on this link or get an economically unbeatable Online Help localization quote here.

Remember that translation of software is not just simple straight forward translation but a complicated process that involves many stages and specialized expertise!

Localization: The Definitive Guide

During the month of October One Stop Shop translations is releasing "Localization: The definitive guide". A user guide for students and localization professionals, the guide contains a series of articles with each one dealing in detail with the localization process for each component of software. The articles are written from a component point of view as opposed to a process point of view in that it details the process of each component individually. Please note that this is may lead to some overlapping between the articles. The links to each article are as follows:

- Software Localization: Background and Methodology
- Online Help Localization: Background and Methodology
- End User License Agreements Localization: Background and Methodology
- Software Documentation Localization(Quick User Guides and User Guides): Background and Methodology
- Website Localization: Background and Methodology

Please note that the best order to read this series is as follows, Software, Online Help, Documentation, End User Licence and Websites!

If you like this post please "like" or "share" for more content

Mark Kieran, CEO, One Stop Shop Translations

For more information on our localization services click on this link or get an economically unbeatable software localization quote here.

Remember that translation of software is not just simple straight forward translation but a complicated process that involves many stages and specialized expertise called software localization!

Software Localization: Background and Methodology

One of the major headaches for software development companies is Software Localization and the release of a SIM ship version of their software to market. In an ideal world the localized or translated versions of the software should be released to market on the same date as the original version which is usually English, a concept known as SIM ship software. With this in mind it is important to run the localization process in parallel with the initial development process. If we delay the localization cycle until the end of the development process this will incur extra costs and also delay the SIM ship version of the software due source code changes caused by the localization process. To overcome these difficulties there are a number of preemptive localization steps that we can take in parallel with software development.

1. Pseudo Localization of Software

Our first step is to pseudo-translate the software pilot languages. If we have many languages to localize (translate) we choose a small cross section of languages to represent all the target languages to be translated. During pseudo localization the target text is pseudo translated as follows:
- The translatable text is isolated
- The translatable text is pseudo translated
- The pseudo translated text it is dumped back into the software code
The pseudo translated text represents the target language and can uncover various functionality and UI bugs during initial development that can be fixed at this stage as opposed to during the software localization/translation phase when it may be too difficult or expensive to fix! Some of the typical bugs uncovered during the pseudo translation phase include:
- Rendering of the target text on the UI. The target text is more often than not longer than the source text especially in the case of English making the text appear cut or overlap other UI components. For instance in the case of English, the other main European FIGS (French, Italian, German and Spanish) languages can be up to 30% longer than English. This allows us to set character limits for menus and dialogues before translation begins.
- Glyphs such as the accent or acute not found in the source language may be cut off in the target language. - Languages such as Arabic that read right to left may cause serious input issues
- The original character set may not accommodate all the source characters
- Identifying hard coded text where the localizable text is embedded in the code
Catching these bugs during pseudo translation of the software ensures a seamless translation phase! The pseudo translation generally identifies all the most common problems of the target versions. Its best to run the pseudo translation when the original version is fully functional.

2. Pilot Language for Software Localization

Now we begin the software localization process in earnest by choosing a pilot language which is a language version of the software translated before the other languages. This language will define the localization process and weed out the majority of the localization bugs.

3. Translation Memory Input during software localization.

The actual software localization process is similar to the pseudo translation process in that the translatable text is isolated, translated and dumped back into the software, however, there is an extra degree of complexity if there are translation Memories involved in the process, as follows. A translation memory is in essence a memory bank of previously translated target text. It is also an environment in which the translator works and has other advantages such as Glossaries to enhance quality and consistency and speed up the translation process. However, once the source text has been isolated we need to ensure that its format is compatible with the TM environment and that all translators are capable of working within the TM environment. Once this has been established we recuperate the previously translated text with the end result being that the translator receives a Translation Memory compatible file with all the previously translated text integrated. This is especially the case for software updates where large sections of the software remain the same which has an obvious saving on costs and time and ensures consistency and quality. The most obvious software translator environment of this type is alchemy catalyst. For a demonstration on a Translation memory environment please refer to the following link.

4. Translation and Revision of the software

Ok, so we send the translator the translation memory compatible files to translate, the most up to date Translation Memory (as they need to update it with their work) reference material such as Glossaries, previous User Guides…etc.. and the translator begins translation. During this stage one must bear in mind that the process can vary in many ways when we take into consideration that the translator may be in-house or external. Also, the translator may be responsible for typical localization bugs such as resizing of dialogues and menus and duplicate hot keys or this may be the role of the localization engineers after translation. The end product is an 80 to 90% localized pilot version. It is then revised by the translation company, the client or a third party depending on the software localization process defined at the start of the project?

5. Translated Software Build

During the next stage the pilot version is rebuilt for testing on various platforms.

6. Localization QA - Testing of localized software

Once rebuilt the pilot version is tested for functional bugs by the Localization QA team and linguistically tested, with the UI in context, by the translators or in some cases by third party linguists. The bugs are documented and sent to engineering in the case of functional bugs, or translation, in the case of linguistic bugs, to be fixed. This cycle continues until the translated software is bug free. The set-up of the phase can differ from company to company depending on the circumstances but in all cases it’s important to update the TMs with the linguistic fixes.

7.

Translation of other software language versions

Now that we have our pilot version localized and bug free, the process is in place to translate the other software language versions. I mentioned at the start of this article that in an ideal world the localized versions should be released on the same date as the master version however it’s usually impossible to achieve this and what usually happens is that certain languages are given priority depending on their market importance. The more important languages are called tier one languages and the less important languages for secondary markets are generally referred to as Tier 2 languages.
So there you have it in a nutshell, the software localization process but we must also bear in mind the additional components of the software such as the Online Help and documentation need to be localized in parallel with the software. Below are additional links for an insight into how these additional components are localized, the articles below belong to the series, "Localization: The definitive Guide" from One Stop Shop Translations:

- Online Help Localization: Background and Methodology
- End User License Agreements Localization: Background and Methodology
- Software Documentation Localization(Quick User Guides and User Guides): Background and Methodology
- Website Localization: Background and Methodology

NOTE: Please note that translation and localization are used interchangeably in this article.
DEF: Translation is the communication of the meaning of a source-language text by means of an equivalent target-language text.
DEF: Language localization is the process of adapting a product that has been previously translated into different languages to a specific country or region. Source: Wikipedia

If you like this post please "like" or "share" for more content

Mark Kieran, CEO, One Stop Shop Translations

For our latest software localization rates click on this link or get an economically unbeatable software localization quote here.

Remember that translation of software is not just simple straight forward translation but a complicated process that involves many stages and specialized expertise!