While UI localization is almost always tied directly to the software development process, documentation localization processes are much more varied.

At one extreme, there is "100% Readiness". This approach that mandates that the source documentation be completely ready before localization commences. This greatly simplifies the management process. There are no updates to account for, and the entire documentation set can be sent to the vendor in one go. The vendor then translates the entire documentation set in one go. What this means, however, is that the translated documentation set may be ready for publication only weeks or even months after the English version has been released.

At the other extreme there is a concept known as SimShip - the simultaneous shipment of the English and the translated versions. With SimShip you need to implement a system of Continuous Translation, whereby material that is completed by the authors on one day, arrives at the desk of the translators on the following day.

In the classic authoring tools like Adobe FrameMaker or Microsoft Word, where a single file usually represents a piece of work no smaller than a chapter, Continuous Translation is very difficult, because even small changes in a single part of a chapter mean that the entire chapter has to be resent for analysis, estimation and translation. Nowadays there are authoring tools and methodologies, called Content Management Systems (CMS), in which the smallest unit is the topic, and the use of CMS is essential to achieving Simship.

Between SimShip at one extreme, and 100% Readiness at the other, it is possible to find a middle ground, but without CMS, the number of cycles needs to be kept small.

A typical cycle for documentation localization is thus:

1. The technical writers approve a piece (chapter or topic) for localization. You need to establish a tracking system to know the precise status of each piece that is to be translated: for example: approved for translation; in translation; delivered; in linguistic testing; in bug fix; in linguistic review.

 

2. You collate a "job" consisting of a grouping of pieces and send to the vendor for estimation. You may want to make your own estimation to keep track of the vendor's process.

 

3. The estimate comes back from the vendor. Examine it carefully. It is hard to think of a vendor that would blatantly cheat you (but it has been known) but they do make mistakes. Sometimes they will use the wrong per-word rate by mistake. Sometimes there will be charges of whose origin you cannot be sure. Make sure you are happy with every part. Your company will have its own approval process. As soon as the spending is approved, tell the vendor to start work.

 

4. The vendor translates the material. The vendor has their own process which is discussed in Vendor Processes.

 

5. The translated material is delivered to you by the vendor.

 

6. You send the material to the linguistic tester who tests it for linguistic quality. You may want to  send them the material in its published form - say, .pdf or .chm files. If this is the case then you are going to want those outputs from the vendor even at this stage. Note that this requirement could raise the price, as some vendors charge time for each publication cycle. Alternatively, you could send your testers the source material. Whichever, your testers will need to collate bugs in a bug-tracking system.

 

7. The vendor has the bugs fixed. The corrected files are sent to you.

 

8. You send the repaired material to your testers for verification and regression testing.

 

9. When all the material has been approved, you give a publication instruction to your vendor (in those cases where your vendor publishes your localized material). The vendor will then produce the final material, be it Context Sensitive Help files, or printable .pdf files.