Tips for Creating Localization Kits

For a successful localization project, it is important to start off with a thorough and well-designed localization kit.

A localization kit contains the files to be localized, instructions for project team members, and tools to assist with the localization efforts (such as translation memory files, customized compilers, and automated test scripts).

Despite the importance of localization kits to project success, these are often thrown together carelessly or overlooked altogether. This article provides a list of components suggested to include in creating a comprehensive localization kit.

By providing a complete set of files and requirements when requesting a proposal from a localization partner, a company is able to ensure that the scope of work resulting from the analysis will be correct and that the cost and turnaround time estimates will be accurate. The kit can then be easily used to kick-off the project with a clear understanding of the scope and requirements.

Not all projects have all components, so not every project will have every component on the list. Often some components may not be available at the time an initial kit is prepared for analysis and proposal requests, but will be available when the project begins. If you are not able to include some components in the first kit but expect them to be a part of your project, it is a good idea to include whatever information you have about them, even if it is somewhat vague.

Traditional Software

• Compiled, Executable application (.exe)
• Resource files (.rc)
• Header files (.h)
• Dynamic Link Library files containing resources (.dll) 
• Installation scripts and related resources 
• Test scripts 
• Customized or proprietary tools used for compilation and testing

Internet Software

• Compiled, Executable application accessible via Internet
• Uncompiled server-side files (Java, JSP, ASP, ColdFusion, PHP, etc.) 
• Text files and message catalogs containing UI strings (XML, HTML, text, etc.) 
• Back-end databases (SQL, Oracle, Access, etc.) 
• Graphics in layered, editable format

Help

• Compiled help system (.hlp, HTML, AppleGuide, etc.)
• Rich-text format source (.rtf, .doc, RoboHelp, etc.) 
• Help project files (.hpj) 
• Bitmap files (.bmp) 
• Segmented hyper graphics files (.shg)

Documentation

• Hard-copy of all documents requiring translation (remember reference cards and box copy)
• Electronic files for publishing application (FrameMaker, Word, QuarkXPress, InDesign, Interleaf, etc., but not solely Acrobat .pdf or PostScript files)
• Graphics source files containing text (layered Photoshop, Illustrator, Fireworks, etc.)
• Unusual typefaces

Reference Material

• Glossaries of terms in source language
• Translated glossaries
• Product reference and overview information (though it may not be translated)
• Files of previously-translated versions and source files for the same previous versions
• Translation memory which can be leveraged for this project
• Style guide which addresses writing and design issues
• Information about target audience
• Desired project schedule and final delivery date
• Decision about approach for dealing with text expansion (often text is up to 30% longer when translated)
• Word counts for all components
• Engineering and publishing contacts to whom SimulTrans should address questions
• Summary of engineering expectations, including SimulTrans' involvement in build process
• Summary of testing expectations, detailing if SimulTrans should do localization, internationalization, compatibility, and/or functionality testing

Each localization kit differs depending on project requirements, but it is a universal reality that projects with localization kits are far more successful than those without them. The more information you can provide at the outset of a project, the more problems you will avoid later.