Moving Content that is Already Translated into Localization Manager

There are two processes you can consider for moving content that has already been translated into the Localization Manager, with each process depending largely on where the translated content is currently stored. You also need to consider who does the translation, and whether you have access to Translation Memory (TM) Tools.

Let's look at two scenarios:

Scenario 1 - All content (including that already translated) is stored in Author-it

You have one library containing all your documentation. Until now, you have managed the process by having a Book for each language variant, and storing each language variant in corresponding folders. In this example, we'll say that English is your source language, and you also have content in your library that has already been translated into French and German.

To transfer the translated content from Source to Target Libraries:

1. Create a backup of your library. If working with a SQL Server Library, export to JET
2. Delete all non-english (translated) content from your main library
3. Create the relevant Localizations, making sure the necessary release states have been created in the main library first, and create the target libraries for each language variant.
4. Open the backup library created in step 1
5. Export the objects that have already been translated to French as XML. This is best done in small batches to make the process more manageable.
6. Open the French target library created in step 3
7. Import the XML, changing the mapping where necessary for each object so as to overwrite the English equivalent. By deleting the already translated content before you began, the translated objects won't map to themselves.
8. Repeat steps 5-7 for each language/localization.

For this process to work well, you should have kept the same folder structure for each language variant. For example, something like:

-or-

If the topics aren't in the same sort of folder structure, it can make it difficult to identify and select the correct topic that should be overwritten when importing from XML. This may not be an issue if you're familiar with all the objects in your library, but could be very difficult for someone who isn't. Likewise, if the Description of the topics has been translated (and not just the headings) it will make it difficult to identify which English topic they should replace.

If your folder structure is not consistent, or if the object descriptions have also been translated, it may be more cost effective (and certainly less daunting) to simply export the English content from the Target library as a Translation Job, and send it to your translation company and have them run it through Translation Memory. Unless there have been changes to the English content since it was translated, it should come up as an exact match and so cost significantly less than the initial translation.

Scenario 2 - Translated Content has been stored and maintained outside of Author-it

Your library only contains your English documentation. Until now, you have simply published the English version, and had that translated externally.

To transfer the translated content from an external location directly into Target Libraries:

1. Create the relevant Localizations, making sure the necessary release states have been created in the main library first, and create the target libraries for each language variant.
2. Export the English content to XML as a Translation Job.
3. Send it to your translation company and have them run it through translation memory.
4. Import the Translation Job (the translated XML)

Most translation agencies use translation memory (TM) tools which help reduce the effort involved in retranslating a document. Translation memory tools work by storing previously translated segments (strings of text) in a database, then when translating a new or updated document, the TM tool finds and retrieves identical or similar matches of these segments for reuse. Results are returned with a rank or score according to the percentage of similarity between the text being translated and the match found.

• An exact match (100%) is returned where there is no difference or variation between the two strings.
• A fuzzy match is returned where the strings are very similar but not identical.

Translators generally charge different rates when text is found as an exact match, as a fuzzy match (with the match falling between a certain percentage), or is a new translation.