[DITA Loc Wire series]

Localization kits provide vital information to your Linguistic Services Provider about the project. When provided at the RFP stage, they help ensure accurate scoping and estimating.  Some obvious elements, such as the deadline and the list of languages, are easy to remember. Valuable background information, on the other hand, is often omitted. This leads to translation errors and delays. In this post, we outline the ideal localization kit, which we hope will spare you time and frustration in your localization projects. The kit is made of three layers of information: the localization requirements, which contain perennial content and process information, the localization package, which contains the files and their specifications, and the localization request, which states the scope and time frame of the project.

Localization requirements

The requirements cover the longer term information and are specified per project type: business line, product, content type – or by a combination of these: e.g. user interface of product A, or DITA content for business line B. The localization requirements consist of several components:

• Team Contact information: Identify the primary point of contact for the related projects, as well as the backup contacts. It’s also useful to list the technical experts and in-country reviewers.
• Specifications: Give detailed instructions per project type: deliverables, screenshots, DTP, online help engineering, DITA OT publishing, XSLT or DTDs, software build requirements, character limits, part numbers for each language, naming conventions, unit conversion, logo usage, software application and build versions, character encoding, and so on.
• Regulatory: Make sure the localization vendor knows your specific regulatory requirements.
• Style Guides: Provide the corporate branding and style guides.
• Glossaries, termbases, metadata, and taxonomies: To ensure consistency, you need to communicate the approved terms in each language that map to your English glossaries, metadata, taxonomies, and so on. Identify which metadata needs translation and which does not.
• Reference information, such as legacy content and product information.

Localization package

The package contains the files that need to be translated, as well as reference files. In many instances, the localization package is a zip file created automatically by a CMS.

• List of source files: This list acts as a verification check to be sure that all files are delivered correctly.
• Actual source files: You need to provide the actual resource files, native application files, native DITA files, editable graphics files,  and so on. If you are not using a CMS, be sure to maintain the file structure and relationships. Clearly identify non-translatable items.
• Other reference files: Providing reference files, such as conref files for UI and insets for documents, is recommended for final publishing or context information.

Localization Request

The localization request contains the project-specific information and specifies which of the requirements listed above apply. The request can in some cases override the requirements.

• Project reference identifying the project type and the corresponding localization requirements.
• Specific exceptions or complements to the localization requirements. Eg. the project-specific point of contact.
• Link to the localization package (zip filename). Providing the list of files or the breakdown per file type enables the localization vendor to crosscheck this link.
• List of languages. These might be implicitly given in the localization package, which often lists the files to be translated for each language.
• Deadlines.
• Purchase Order information when working with open P.O.s.

The localization request is usually filled by the Localization Manager using a standard form.

Special DITA considerations

The architecture of DITA results in a proliferation of files and resources that can create challenges if the localization vendor is not prepared. It is better to work with native DITA source files than with XLIFF because each transform can introduce problems, such as broken links.
Here are some tips for a successful DITA localization project:

• Use the attribute to identify the language.
• Externalize keyrefs, conrefs, conkeyrefs, and software UI strings.
• Apply the translate attribute to protect non-translatable content
• Externalize the metadata that needs translation.
• Include the map files for each output needed.
• Include DITA OT modifications, or other XSLTs.
• Ensure that administrative metadata is applied correctly (e.g., part numbers, outputs, conditional tags, etc.).
• Identify any specialization to the base DITA architecture.
• You can refer to our DITA Loc Wire Series to learn about DITA content and process best practices.

Handoffs

During handoffs to the localization vendor, it is vital to maintain regular communication and close the loop. Make sure that the vendor received the files and knows the schedule. For big projects with multiple drops, consider scheduling a regular check-in with the vendor to answer questions and ensure that everything is working smoothly.

Handoff Checklist

Before sending the files to the localization vendor, the Localization Manager should verify these things:

• The vendor PM’s contact information is correct.
• The localization requirements, and in particular the contact information, are up-to-date.
• The localization package is complete.
• Deadlines are identified and marked.
• Deliverables and languages are identified and marked.

CCMS integration/uploads

Many CCMS’s have workflow and integration options that enable to automate some of the handoff and management tasks associated with localization. Check with your vendor that the integrations work with both his and your processes.

Preparing a localization kit can save you time and money by ensuring that the vendor has all the instructions and components needed for a complete translation into all the languages you need. Besides, the kits provide a verification check that helps you be consistent and complete when handing off to the vendor.