Building a Localization Kit

By Luigi Muzii,
Team Leader,
Gruppo L10N,
Rome, Italy

info[at]gruppol10n.it
www.gruppol10n.it

Get the List of 4,400+ Translation Agencies Now!
No Recurring Membership Fees!

• Introduction
• Rationale
• The content structure of a localization kit
• Users of a localization kit
• Creating a localization kit
• Contents of a localization kit
  • Software
  • Documentation and on-line help
  • Graphics
  • Multimedia
  • Collaterals
• Writing the localization guide
• Terms and definitions
• Bibliography
• Warranty

INTRODUCTION

TARGET AUDIENCE

This document was created to address a typical common problem afflicting localization managers, localization vendors, and project managers.

This document is intended for readers with years of experience in the localization industry, as well as for newcomers. However, it is not intended to be comprehensive.

The goal of this document is to be a useful reference for the target readers and provide a few guidelines to help them set up and maintain a localization kit for a product that make their job easier.

Finally, just remove or ignore the sections specifically devoted to localization to have the instructions for building a translator’s kit instead.

This document is the result of eightee nonths of research, retrieval, and collection of information: comments, feedback and suggestions from target readers would be appreciated.

GENERAL NOTES

A localization kit is a subset of tools, instructions and resources necessary to produce a localized version of a software product.

For a localization project to be executed properly, localizers, testers, and engineers are to be provided with a thorough and well-designed localization kit.

Since the quick release of localized software requires that translators begin work early, and developers can have a significant impact on translation, a localization kit will allow translators to work more independently because they can check their work as they go.

The final quality and the success of a localization project depends on the amount of knowledge that is transferred to the localization vendor. This knowledge affects:

An effective localization kit offers a relatively easy solution to these challenges, and is one of the best things to do to ensure that the localization vendors have everything they need to get the job done efficiently.

Although demanding, assembling the localization kit and writing the localization guide of a product is a one-time task that always pays off.

RATIONALE

Localization-friendly code allows developers to involve service providers in the process more quickly, easily and conveniently.

A localization kit provides the material that serves two functions in the localization process:

A good localization kit is:

Ideally, corporate guidelines and a checklist for the development of a localization kit should be created, so that the kit remains consistent regardless of the manager or product. This will help ensure a high quality kit, eliminate time spent on reworking, and enhance the efficiency and scalability of localization processes. In addition, in the case of a long-term relationship with a localization partner, turn-around time on the generation of localization proposals/plans should shorten and projects can commence sooner.

Ideally, a localization kit should be created after the primary version of the software has been code released to include all up-to-date resources and code, included, and should stand on its own. But, when sim-ship (simultaneous shipping of localized and primary versions) is required, a localization kit will be needed before the primary version is code released.

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 localization kit can then be easily used to kick-off the project with a clear understanding of the scope and requirements.

The kit can also be used to ensure that the materials returned are as complete as possible and useable right away. This completeness is vital to the success of the localization effort.

The localization kit helps you get organized. It documents the project requirements that otherwise may be lost during the transfer of information to the vendor, in a well-organized document tree with fully functional files, and serves as a central repository for the information needed to localize a product and enables anyone in an organization to easily assume responsibility for managing a project and immediately having the necessary information to request an analysis or start the project.

THE CONTENT STRUCTURE OF A LOCALIZATION KIT

The localization kit should be arranged during the pre-localization design and implementation stages for project evaluation and analysis with a very simple point: no one likes surprises, that is, missed deadlines and budget overruns. Moreover, since most software localization projects involve a large number of target languages, getting the translation kit right from the start would prevent many similar or identical questions from the various translators.

Each localization kit differs depending on project requirements, but, in all cases, the more information is provided at the outset of a project, the more problems will be avoided later.

Typically the localized version of a product should only contain translatables and configurations for the locale and not the binaries or libraries of the product.

A well-assembled localization kit should contain all the final resources needed by localization vendors to create a localized version of the software without assistance from the original development team. The vendors should be able to use the kit to get the resources translated, integrated, and tested without assistance from the development team, and if the software code is localization-friendly, it is unlikely the source code will be needed to create the localized versions.

Therefore, a localization kit should contain the files to be localized, identified and prepared for translation (the binary files and the resource files), along with instructions, guidelines, indications, and notes from the developers to project team members on how to deal with the various files and file types. It should also provide background and contextual information about what is being localized. Whatever the product, a fully functional version (at least a beta version) of the running software should be included. Finally, a localization kit should contain all the tools required to work with the files.

ORGANIZATION OF A LOCALIZATION KIT

Generally, a good practice to organize the files centrally, as everything to do with them is to be done as many times as the number of languages into which these files are to be localized. Therefore, a well-organized file tree pays off when the vendors have to fix all the broken cross-references, missing files, and broken graphics; and they will do it differently for each language!

The reorganization of files in preparation for localization can partially be expedited by creating a list-of-references file where the location and properties of each file are reported when the first “build” is made. A CASE (Computer Aided Software Engineering) tool can help, and the list-of-references file can then become the foundation of the localization kit’s BoM (Bill of Materials).

Not all projects may 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 starts. If some components cannot be included in the first kit but are expected to be part of a project, it is a good idea to include whatever information is available about them, even if it is somewhat vague.

Ideally, to ensure efficient production, all the professionals involved in the localization process should provide their input.

USERS OF A LOCALIZATION KIT

Localizers, testers, engineers, and project leaders/managers are all potential users of a localization kit.

Testers and engineers also need information on what to do with the files. Providing test cases to the tester as well as an overview of the project will ensure the project is checked thoroughly.

PROJECT MANAGERS

To properly arrange an effective project plan, localization project managers must be provided with estimates on the amount of text, art, video and audio to be localized before the software is assembled.

Project managers working for localization vendors would need the following information:

• required tasks and services;
• project scope overview;
• project languages;
• components;
• number of files;
• files lo localize;
• number of words to localize (per file);
• files to engineer;
• number of pages for DTP;
• number of updates that can be expected;
• project release schedule;
  • milestones;
  • hand-offs;
  • review cycles;
  • deliverables;
  • deliveries;
• quality steps;
  • software testing scope and validation;
  • number of language reviews;
  • number of test cases;
  • platforms and operating systems.

LOCALIZERS

Localizers will be interested in knowing which files need to be localized, for which audience they localize and, in most cases, what not to change in each file. Quite obviously, they will also be interested in the overall word count and the number of words in each file. They will appreciate information, instructions, and comments about the strings to localize and their features.

All text must be finalized.

ENGINEERS

Engineers will be interested in instructions for modifying code to verify functionality in the target locale. Engineers will also be interested in hardware and software required for building, and in compilation and testing procedures and instructions. For cosmetic adjustments of dialog boxes, instructions on testing will include operating system version and configuration (resolution) settings required.

Should full software engineering and cosmetic testing be expected from the localization vendor, the localization engineers should be provided with batch files allowing automatic configuration of any required system parameters and compilation in all languages. These files should be placed in a special folder. All code must be stable enough for testing.

CREATING A LOCALIZATION KIT

A localization kit helps meet client deadlines as well as quality and service goals by clarifying expectations, establishing better communication and organizing the localization project drop. Products to be localized should be reviewed for internationalization readiness prior to localization in order to leverage this work across multiple language versions.

Before localization starts, localizers should be aware of a series of issues such as:

• expectations (from the audience and the company);
• competitors in the target market;
• cultural, religious or sociological issues;
• technical requirements (e.g. bandwidth requirements, fees - if any - for Internet use and domain names provisions for Web sites/applications);
• legal requirements (e.g. data protection legislation and copyright issues).

When creating a localization kit, stick to the basics:

1. 1. set standards for the types of information to include, what level of detail is appropriate, general presentation guidelines and instructions as to what to include, what is important, and how to communicate information to the vendor;
2. provide separate sections for every product component to have discrete expectations on software deliverables, web sites, and marketing collaterals;
3. reference all external documents with the correct version, along with information on how to access them;
4. always ask for client approval of the kit and all deliverables listed in it prior to hand-off to the localization vendors;
5. have the localization vendors review draft versions of the kit for questions and feedback before the final project hand-off;
6. when the project is over, run a post-mortem review for future projects. >

When content is added later, organize it in a “mini” localization kit to supplement the main one, with its own set of resources, tools, documentation, and code to avoid rearranging the initial localization kit to include the updates.

However, even though a localization kit can help avoid the cost, frustration, and delays that result from not clearly stating expectations, it is no substitute for regular communication between clients and vendors.

CONTENTS OF A LOCALIZATION KIT

Today, a software product consists of several types of objects that must be archived for re-releases, ported to different platforms, and created specifially for OEM’s (Original Equipment Manufacturers.) These can be pre-installed on computers or bundled with other hardware.

These archives will also be used to create any necessary patches, which should then be added to the archives, once completed.

The localization kit is what the localization vendor needs. Every client has unique requirements, timetables, deliverables, and constituencies. As a result, localization kits will vary from company to company, if not from project to project. Nonetheless, a number of components should be included in most kits.

A localization kit normally consists of hundreds of files, some of which are translatable and many which are not.

To build a software application, all the resource files and code files are needed, which are then compiled into a binary or executable file which can be run on a computer. Therefore, a comprehensive localization kit has build environments for software applications and/or the accompanying on-line help files.

Examples of resources are the bitmaps used in toolbars, such as the printer icon which executes the print command. In most cases, these resources do not have to be changed for any localized versions of the product. The translatable information, such as the menu text, dialog box options, and error messages, is stored in resource files. A software product which has been well-internationalized stores all translatable text in resource files, which makes the localization job relatively simple. However, in many cases, files containing translatable text are found all throughout the build environment.

It is the localization engineer’s responsibility to locate and identify all the translatable files and prepare them for translation. Localization engineers should ensure that translators know exactly what they need to do, so they can get started quickly.

To assemble a comprehensive localization kit a few general steps can be followed:

1. prepare the project;
2. research the hurdles in a specification;
3. identify the scope;
4. identify the audience;
5. write instructions for each specific group of people working on the project;
6. assemble and organize all the necessary resources, tools and documents;
7. run a pilot project to test the localization kit.

To help the project manager compile the instructions for the members of a localization team, a localization kit should come with:

• a UI (and possibly error messages) flow chart describing how the overall UI fits together, and defining the context of terms; UML use case, activity and sequence diagrams could often be sufficient;
• software and hardware specifications describing any proprietary software that is needed for localization, with instructions on how to procure, install, run and use it;
• documentation user documentation, on-line help (in source and compiled version), and project documentation;
• specialized tools needed for localization;
• translatables all text, art, multimedia, packaging, and other materials to translate, in source language.

If any of the objects making a localization kit is lacking or is insufficiently detailed, the localization kit could prove difficult to use, and the time to answer questions and provide any missing information or resources will turn into unbudgeted, therefore, intolerable costs.

PROJECT MANAGEMENT

The localization kit should be divided into sections specifically built for the team working on the project following a well-organized folder structure, even though future versions of common operating systems will have deeply integrated indexing features, making a folder system almost obsolete.

The project manager’s prime responsibility is to complete the localization kit with a project-specific section.

Any localization kit should include a letter of assignment to be signed and returned by all the localization team members to function also as a contract between the parties if necessary. The letter of assignment should carry all quotations grouped by component, the change management agreement, the project milestones, and the development cycle “freezing points”.

This should contain a statement of work, listing all expected services and deliverables, and all the relevant reference materials.

STATEMENT OF WORK

The purpose of a statement of work (SoW) is to detail the work requirements, i.e. “what is to be done”, for the project. A SoW will be the basis for potential offerers to compete for the contract and when it becomes contractual it shall be used as a standard for determining if the supplier meets the stated performance requirements. The SoW will also support the localization project manager in outlining the required work effort through a WBS (Work Breakdown Structure) diagram and establish a delivery schedule.

The SoW should include, but is not limited to, all of the following:

• project scope;
  • product name;
  • project name or code;
  • overview of the product and the target audience;
  • description of the product’s basic architecture;
  • list of localization kit contents;
  • services required, tasks and deliverables;
  • languages;
  • project components;
  • word counts;
• delivery requirements;
  • period of performance (the start and end date for the entire project);
    • delivery dates;
    • interim milestones by deliverable;
  • physical location where the work will be performed;
  • performance standards;
  • supplies and equipment that will be used;
  • delivery method;
• e-mail;
• CD/DVD (with specification of courier type if necessary);
• FTP;
• update cycle;
  • number of updates;
  • size of updates;
  • expected schedule for updates;
• quality expectations (the acceptable quality for the product);
• payment terms;
  • total amount of the purchase order;
  • overall amount computed for each job/task/deliverable;
  • payment rate;
  • non-disclosure agreement;
  • liability agreement;
• contact information;
  • name(s), e-mail(s) and phone number(s) of project manager(s);

To prevent any disputes on word counts, indications on counting tools and methods together with the resulting analysis log files should be provided. Each log file should contain the number of replicated and untranslated words, translation memory (if any) full and fuzzy matches, and frequently occurring segments.

All settings for the translation tools (e.g. segmentation rules, minimum match value, maximum number of hits, penalties, etc.) should be specified to allow the team members to reproduce all statistics and properly apply the translation memories.

These settings should also be used to produce statistics for progress reports and a graphic projection of delivery dates.

BILL OF MATERIALS

Each SoW should be marked with a version number for traceability of updates and accompanied with a detailed bill of materials (BoM). This should include:

• a list of the files to localize grouped by type;
• an image of the directory structure of resource files, build files, compiled files and documentation files by locale;
• directory structure requirements for deliverables;
• a list of expected deliverables;
• a list of drivers for creating deliverables;
• a list of build environments and source files;
• a list of documentation files.

Excerpt of a localizable file list from a bill of materials

REFERENCE MATERIAL

The project manager’s responsibilities include the arrangement of any reference materials for the project, which should typically include:

• all relevant background information about the product;
• product reference and overview information;
• the most recent localized version of the product in the requested language(s);
• style guides for each target language addressing writing and design issues;
• documentation files;
• complete and up-to-date translation memories for all components with the specification of the relevant format for each language;
• an up-to-date project glossary;
• templates for query handling;
• compiled and fully functional tested help and software files.

1. 100-[(words translated)*100/(words to translate)]
2. people involved
3. (number or words per day)/(resources)
4. (words to translate)/[(resources)*(productivity)]

SOFTWARE

In developing the localization kit, the localization project manager should identify elements that may be culturally dependent, and decide whether to generalize them for all cultures or isolate them for localization. Isolation is performed by removing the cultural information to a resource file and replacing it with a routine, which looks up the appropriate information in the resource file. If isolation is required, the localization project manager will send the code back to the software engineers with proper instructions for correction.

Example of bug fix report
Bug fix report: < product name > GUI Italian

Example of a query sheet
Query sheet: < project name > Terminology Italian

Example of progress report

The translation of software resources must come before that of on-line help and documentation to have the software terminology be available to guarantee crosswise terminology consistency. Therefore, when assembling the reference material, the localization project manager, together with the client’s software experts, will also arrange the software resources for translation, possibly converting the data for processing with a translation editor.

Before actually starting the localization process, the localization project manager should ensure that the original text is clear and concise, grammatically correct and free from slang or technical expressions that may lead to mistranslations. The localization project manager should also check for language and references consistency and for translation memory integrity and correctness.

In addition to the converted software resources, the localization kit should further contain an executable version of the software (for reference purposes and to help translators get acquainted with the product), as well as the entire build environment if final compilation and testing is required.

A localization kit should be arranged according to the scope of the project, and include a separate section for traditional and Internet software if necessary.

When available, the results of pilot project(s) should be made accessible to localizers to allow them to find some specific issues that may have been overlooked in the internationalization stage.

TRADITIONAL SOFTWARE

"Traditional" is used here to mean desktop or handheld static software as opposed to Internet software. A traditional software section should include:

• a copy of the full application;
• the resource files (.rc) containing all translatable strings of text;
• header files (.h);
• dynamic link library files containing resources (.dll);
• installation files and scripts and related resources;
• a full build environment for testing;
• test scripts;
• customized or proprietary tools used for compilation and testing;

INTERNET SOFTWARE

A Web site or application is quite different from a "traditional" static software application, and can hardly be localized in "safe mode", i.e. working on binaries, resource scripts, or string files only. In most cases localizers should be able to access source files to replicate the site or the application, and possibly set up a test environment.

Therefore, a web localization project manager’s first concern should be protecting the code from accidental changes and assembling a language pack. If the product has been internationalized correctly, all localizable text should have been extracted from code and a language pack should consist mainly of the string tables and the language-specific image files. Translators will “only” have to translate the relevant column of the string table.

In a well-internationalized product, translatable text is usually placed in a text file that is included in server-side scripting files with an <!-- # include file/virtual=”...”--> statement. Each module of the site should have a folder where these include files are kept, separate from the main web site folders.

A typical language pack for an Internet software section should include:

• resource files for binary and script files;
• text files and message catalogs containing UI strings;
• graphics source files in layered, editable format and Internet format (GIF, JPEG, PNG);
• Internet-accessible binary files (executables, libraries, components, servlets, etc.);
• uncompiled server-side files;
• Java and Flash applets;
• back-end databases.

For each object, the associated application must be specified (e.g. Adobe Photoshop for .psd files, Microsoft Access for .mdb files, and Macromedia ColdFusion for .cfm files).

DOCUMENTATION AND ON-LINE HELP

Once the localized version of the software is edited, the localization engineers should re-import it into a CAT tool to create a software glossary containing all dialog items in source and target language.

The localization kit should then be updated with the documentation, the on-line help files and the new glossary.

The statement of work should also be updated with the new project schedule details.

The software documentation is needed both as source files and as fully formatted DTP files. Possibly, a print-out of all documents requiring translation should be provided as well.

All files must be included in the localization kit following a proper directory structure. A folder called Documentation could be created with subfolders labeled Product documentation and Project documentation.

The Product documentation folder could contain a User documentation and an On-line help folder.

The compiled versions of DTP documentation, together with the original source files and a tagged-format version must be provided in the User documentation folder for processing with translation tools. If a DTP version is required, the User documentation folder should also contain a copy of the compiler.

Fonts and font types to be used must be clearly specified and provided if unusual or proprietary. When giving the naming conventions a rule must be provided for fonts names to be consistent with the names given in the target locale.

Finally, the User documentation folder of a localization kit should contain a bill of material in the form of a spreadsheet listing:

• the files requiring localization and their location with the indication of the text to remain in the original language;
• the format of source files and the authoring and validation tools and versions used to create them;
• the formats required for output files and the authoring and validation tools and versions needed to produce them;
• the fonts used in the source files and those to use for the localized version.

The On-line help folder should contain the following:

• compiled help system (.hlp, HTML, AppleGuide, etc.);
• rich-text format source (.rtf, .doc, etc.);
• help project files (.hpj);
• templates and style sheets for HTML/XML-based help;
• bitmap files (.bmp);
• segmented hyper graphics files (.shg);

If a compiled version is required, the On-line help folder should also contain a copy of the compiler.

The on-line help associated graphics could also be stored in a specific Graphics subfolder of the On-line help folder or in a On-line help subfolder of a more generic Graphics folder of the localization kit.

The Project documentation folder could contain project guidelines and projects templates, the project style guide specifying all style conventions, typography, and naming conventions. Where possible, the folder should also contain the style guide used by the technical writers of the source files.

A Project documentation folder could contain the localization guide providing the naming rules, the guidelines for document setup if separate copies have to be created for each language/locale, information on the printer driver version and the printer description file to be used, and the guidelines and instructions for text expansion. If any special fonts are used, the localization guide will also detail the font requirements. Finally, the localization guide will provide for instructions for DTP compilation, including the compiler version, and for help testing, including required platforms, operating systems, browsers, and relevant versions.

The Project documentation folder as well could contain a bill of material in the form of a worksheet with a spreadsheet listing file names, types, and a brief explanation of each file’s purpose, as well as any other notes, including any special fonts required.

GRAPHICS

The User documentation and the On-line help folders could contain a specific Graphics subfolder each; alternatively, a more generic Graphics folder can be created in the root folder of the localization kit.

In any case, a Source folder could be created to store all artwork in source formats while a Final folder could be arranged to store non-editable files.

When graphics are created using multi-layered image authoring systems text should be placed in specific discrete layers.

For artwork available only in non-editable formats, all text should be extracted and a spreadsheet should be created in the same worksheet as for documentation with the strings to be translated and re-imported after localization. This worksheet could be stored in the Project documentation subfolder of the Documentation folder.

The same worksheet could contain a spreadsheet with all the available information for the required images sorted by area:

• the names of source and target format files;
• graphics tool and version used to create the source file;
• image creation specifications for the final output format;
  • fonts;
  • color palette;
  • screen and print resolution;
• keystroke or menu information about each screen for screen captures.

Also, in the graphics section of the localization guide, guidelines for text expansion and instructions on how to deal with “restricted” symbols must be provided together with any information on alternative forms.

MULTIMEDIA

Since more and more localization projects now include an audio/video component, it is important to demonstrate both technical capability and comprehensive studio talent.

Multimedia embraces a vast range of “documents” that may have two or more of text, graphics, sound, video, and animation; therefore, a very basic principle in making multimedia files states that digital localizable elements should be separated from one another on different tracks on the timeline.

The ideal situation is to present localizers with the project files and project settings from which the presentation was constructed. In properly encoded MPEG video and AVI movies, audio and video streams can be extracted and separated to be saved back after editing or localizing.

In summary, the multimedia section of a localization kit should contain:

• a copy of scripts in both the source and target languages organized in chronological order;
• separate, uncompressed audio (music, sound effects, and voiceover tracks) and video streams;
• separate sound effects and voice tracks;
• any specific codecs and movie viewers used to create and play compressed versions of videos;
• a copy of uncompressed videos with the text to be localized.

Some projects may require the script(s) to be divided into individual paragraphs, depending on the size of the project, so that the resulting files can be managed individually in a more comfortable way with the same code for both the original and the target languages. Each element of a script should then be listed in the bill of materials with the associated file name.

Again, a print-out of all documents requiring translation should be provided.

Then, a spreadsheet should be created with all the available information for the multimedia files. This spreadsheet could be stored in the Project documentation subfolder of the Documentation folder of the localization kit, and should provide for:

• a list of applications used with a special reference for combination or dedicated multimedia environment;
• specifications for additional room on CD-DVD’s for distribution;
• voiceover technical specifications;
  • format of the original voiceover files;
  • format of the localized voiceover files.

The multimedia section of the localization guide, must provide for:

• guidelines for replacing source language voiceover files with the localized voiceover track;
• guidelines for text expansion, overlay and synchronization;
• instructions as to correct accents, pronunciations, tone and rhythm of the dialog;
• instructions as to noise elimination;
• instructions as to volume level and consistency;
• instructions as to silences.

For MPEG files, a fully standard-compliant version with time code and subtitling information could be extremely useful.

COLLATERALS

Peripheral documents are usually referred to as “collaterals”.

These are usually made of graphics file, sometimes of DTP documents.

The localization kit should be provided with a Collaterals folder containing:

• the compiled versions of the DTP or the graphic file of the box;
• the source files or a tagged-format version of the DTP file of the box;
• the graphic file of the CD labels and printing (usually EPS) version;
• the compiled versions of the DTP or the graphic file of the brochures and the other marketing material;
• the source files or a tagged-format version of the DTP of the brochures and the other marketing material;
• the ReadMe file, in plain text or rich text format;
• the license agreement, in plain text or rich-text format;
• the fonts used in the source files and those to use for the localized version.

Again, a print-out of all material requiring translation should be provided.

Then, a spreadsheet should be created with all the available information for collaterals. This spreadsheet could be added to the specification worksheet stored in the Project documentation subfolder of the Documentation folder of the localization kit, and should provide for:

• the names of source and target format files;
• graphics or DTP tools and version used to create the source file;
• any additional font requirements;
• image creation specifications for the final output format;
  • fonts;
  • color palette;
  • screen and print resolution;
• information on the printer driver version and the printer description file to be used.

Also, in the collaterals section of the localization guide, guidelines and instructions for text expansion, instructions for DTP compilation, including the compiler version, and special instructions on how to deal with legal, tax or financial issues must be provided.

DELIVERY

An overview of folder contents should be provided together with instructions for creating a language pack from the localized files for a language and for returning it.

Before issuing, the content of the localization kit should be verified by a third party for key tools and information missing that are necessary for localization:

1. all files should be checked for corruption;
2. all files should be scanned for virus;
3. no extra files should be included;
4. no files should be missing;
5. all files should be the most current.

Finally, the localization kit should be stored on a CD or DVD and labelled with:

• product name;
• version and build number;
• platform;
• date of creation;
• summary of contents.

If the localization kit is updated to include patches or additional content after the product is released, a mini localization kit should be created with the critical objects stored on a separate disk labeled with the same information of the main localization kit and an additional tag stating it is an addendum.

WRITING THE LOCALIZATION GUIDE

The localization guide should be created before the actual work on the project begins, together with the project work plan.

The localization guide contains the instructions for localizing a product. The policies contained with localization guide are product- or company-dependent.

Although it may seem time-consuming to develop, a good guide can work well with many projects; therefore, in most cases, it could only be created once and reused on subsequent projects with little modifications.

For the localization of the project to run smoothly, the better the instructions, the fewer the problems. Therefore, developing a good localization guide involves:

• determining who will use the kit and what their needs are;
• explaining what’s in the kit and how to use it;
• ensuring that the kit is complete and usable.

Instructions must be provided on how localized material being returned will have to be organized and formatted.

Any duplication must be mapped and the correlation of files explained. The instructions contained in the localization guide should be clear and precise enough to have the files repackaged so they can be properly put back in the product.

The localization guide in the localization kit should accurately list and clear all issues and closely track changes. All lists should be kept updated to work as trusted and valid tracking tools. The localization guide should also be immediately updated with answers to questions and issues raised. The localization guide should therefore provide for:

• localization guidelines and schedule information;
• instructions on how to handle concatenated strings;
• special instructions for file handling, including applications to use with version, platform, etc., and any special or manual processes;
• guidelines to dealing with text expansion;
• instructions for dialog resizing and other cosmetics;
• guidelines for keyboard accelerators localization;
• naming conventions (whether long filenames or names including spaces or special characters can be used, or 8.3 filenames are to be used);
• expected delivery file types.

The localization guide should finally provide for detailed communication and project logging procedures.

What follows is a suggested strategy for authoring a localization guide. A very brief - and not exhaustive - sample can be found in the Appendix.

INTRODUCTION

Provide an overview of the entire document: describe all data, functional and behavioral requirements. Describe the contents of the kit.

PROJECT ORGANIZATION

List the major project roles and the actual people involved, possibly including an organization chart. An appropriate project organization structure can be depicted in the following list:

• project director (the manager of the project manager);
• localization manager;
• project managers (on the client’s and the vendor’s side);
• project lead(s);
• project team members.

PROJECT ISSUES

Describe the overall project goals with an overview of the overall project plan stating cost estimates and a top-level schedule for the project.

STATEMENT OF SCOPE

Define the breadth and limitations of the work to be done, not how to do it. Give a description of the project and the software with major functionalities and constraints.

Place the software in a business or product line context