Monday, October 28, 2013

Translation Errors

Second in the series of translation errors from around the world

Thursday, October 24, 2013

Documentation Localization: Background and Methodology

User manual translation

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!

Monday, October 21, 2013

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!

Thursday, October 17, 2013

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.
Centralized Translation Memory
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!

Monday, October 7, 2013

Localization: The Definitive Guide

localization
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!