How Unified Localization works

CCMS Web localization creates a separate translated object for each revision of the corresponding source object.

CCMS Desktop localization offered two models: sequential and concurrent. In the sequential model, each new translation of an object replaced the previous translation, so that there could never be more than one copy of any object for a given language.

In the concurrent model, each revision of an object created a new object in localization. For example, revision 5 of TopicA was a completely separate file from revision 7 of TopicA. In this way, you could send multiple revisions of an object for translation at once and retain each of them after translation.

Unified Localization is similar to concurrent localization. The process retains each revision, using a sequential numbering system appended to the filename to track each one.

Overview of the process

The following is very high-level and simplified. Each step is covered in full detail in the following topics.

For this simple example, let's say in your source language (English) you have MapX (abc1234567890987.ditamap) at revision 2. It references TopicA (def3456789098765.xml) at revision 5 and TopicB (ghi6789012345678.xml) at revision 7.

You localize the map to French. CCMS Web creates a Translation Manifest for the source language map and a related Language Manifest for French. Unlike in CCMS Desktop, no actual objects are created in the Translation cycle. The Language Manifest contains pointers to "virtual" objects.

You then generate a localization kit, which is a zip file containing the map and the two topics. Although everything is still in the source language, the language code has been changed to fr-fr to reflect that you are translating to French. The files in the kit have the following filenames:

  • abc1234567890987_00002.ditamap
  • def3456789098765_00005.xml
  • ghi6789012345678_00007.xml

Where the revision number is appended to the filename.

At this point, you send the localization kit to the LSP through whatever means you usually use. The LSP translates the content, re-zips it, and sends it back to you.

You import the zip file and CCMS Web automatically matches the imported objects to the virtual objects in the Language Manifest. At this point, the virtual objects become real objects.

If you were able to look into the French sub-collection of the translation collection in the Content Store at this point, you would see these three filenames there.

You review the translated content, approve it, and move it to its final status.

A few months later, you've made multiple edits to the map and two topics. MapX is now at revision 9, TopicA is now at revision 6, and TopicB is now at revision 12.

You localize the map again to French. CCMS Web creates another Translation Manifest and another Language Manifest.

You generate another localization kit. This kit contains these three files:

  • abc1234567890987_00009.ditamap
  • def3456789098765_00006.xml
  • ghi6789012345678_00012.xml

Again, you send the kit to the LSP, receive the translated content back, and import it. Again, the virtual objects in the Language Manifest become real objects.

If you were able to look into the French sub-collection of the translation collection in the Content Store at this point, you would now see six filenames there. The two translated revisions of MapX are distinct files, as are the two translated revisions of TopicA and TopicB.

You can generate French output from either of the Language Manifests associated with MapX, ensuring that you can always return to the translation version that you need.

Here is a more visual representation of the process:

Figure: Localization process diagram
Localization process diagram