• Introduction
• The underlying principle
• The content structure of a localization kit
• The users of a localization kit
• The creation of a localization kit
• The 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 deal with a characteristic common problem that afflicts localization managers, localization vendors, and project managers.

This document is intended both for readers with years of experience in the localization industry, and for newcomers. However, it is by no means intended to be a complete guide.

The aim of this document is to provide a useful reference for the target audience and to offer a few guidelines to help the readers in the creation and maintenance of a localization kit for a product, making their job easier.

Finally, you can remove or ignore the sections that deal specifically with localization to get the instructions for building a translator?s kit instead.

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

GENERAL

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

For a localization project to be carried out properly, a thorough and well-designed localization kit must be provided to localizers, engineers and testers.

Given that the prompt release of localized software requires that translators begin work early, and developers can have a considerable impact on translation, a localization kit allows translators to work more independently, as they can check their work during the process.

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

• the capability of the vendor to provide an accurate quote and establish the correct schedule for the localization project;
• the time spent by the project engineers and managers;
• the accuracy of the project output and deliverables.

An effective localization kit provides a relatively easy solution to these challenges, and is one of the best ways to make sure that the localization vendors have all they need to perform the job efficiently.

Although assembling a localization kit and writing the localization guide of a product can be demanding, it is only a one-time assignment that certainly pays off.

THE UNDERLYING PRINCIPLE

A localization-friendly code allows developers to get service providers engaged in the process more easily, quickly and conveniently.

The localization kit provides the elements that enable performing two functions in the localization process:

• preparing the proposal (price, plan and schedule) for localizing a product;
• carrying out the localization.

A good localization kit is:

• complete, and contains everything that the development team must provide over and above the product itself;
• usable, and includes clear and full documentation about the structure of the kit and how to use it.

Ideally, clear corporate guidelines and a list of tasks for the development of a localization kit should be created, to ensure that the kit remains consistent regardless of the manager, project or product. This will guarantee a high quality kit, eliminate the time spent on reworking, and increase the efficiency and scalability of localization processes. In addition, when a long-term relationship with a localization partner is established, turn-around time on the generation of localization plans and proposals should become shorter and projects should start sooner.

Ideally, a localization kit should be created after the primary version of the software has been code released, including all up-to-date resources and code, and should stand on its own. But, when the requirement is to ship simultaneously the localized and primary versions, the localization kit will be required before the primary version is code released.

If a company provides a complete set of files and requirements when requesting a proposal from a localization partner, it can ensure that the scope of work derived from the analysis will be correct and that the turnaround time and cost estimates will be accurate. The localization kit can then be used to begin the project with a clear understanding of its scope and requirements.

The kit can also be used to make sure that the materials returned are as complete as possible and can be used right away. The completeness of the materials is crucial to the success of the localization effort.

The localization kit helps you to organize yourself. It documents the project requirements preventing them from getting lost as information is transferred to the vendor, in a well-organized document tree with files that are fully functional , and serves as a central storage place for the information required to localize a product enabling all the members of the organization to easily take responsibility for managing a project and be immediately in command of the information necessary to request an analysis or begin the project.

THE CONTENT STRUCTURE OF A LOCALIZATION KIT

The localization kit must be prepared in the pre-localization design and implementation stages, to allow project evaluation and analysis, for a very simple reason: no one likes surprises, i.e., missed deadlines and budget overruns. Furthermore, given that most software localization projects include a considerable number of target languages, getting the translation kit right from the beginning can prevent many similar or identical questions from different translators.

Localization kits differ according to the requirements of the project, but, in all cases, the more information is provided in the beginning of a project, the more likely it is that problems will be avoided later.

Normally, the localized version of a product  only contains translatables and configurations for the locale and not the binaries or libraries of the product.

A well-structured localization kit must contain all the final resources required by the localization vendor to produce a localized version of the software without help from the original development team. The vendors must be able to use the kit to translate, integrate and test the resources without assistance from the development team, and if the software code is localization-friendly, it is most likely that the source code will not be needed to produce the localized versions.

Thus, a localization kit must contain the files to be localized, identified and ready for translation (the binary files and the resource files), together with instructions, indications, guidelines and notes from the developers to the members of the project team on how to handle the various files and file types. It must also provide background and contextual information concerning what is being localized. Regardless of the product involved, an entirely functional version (at least a beta version) of the running software must be included. Finally, a localization kit must contain all the tools necessary to work with the files.

ORGANIZATION OF A LOCALIZATION KIT

Generally, it is a good practice to arrange the files centrally, since all the operations that need to be performed with them must be done as many times as the number of languages into which these files need to be localized. Consequently, a well-organized file tree is most helpful when a vendor has to fix broken cross-references, missing files, and broken graphics; and can do it in a different way for each language!

The reorganization of files to make them ready for localization can be expedited to some extent, generating a list-of-references file in which the location and properties of every file are detailed when the first ?build? is made. A CASE (Computer Aided Software Engineering) tool can be of assistance, and the list-of-references file can become the foundation of the localization kit?s Bill of Materials.

It is possible that not all projects will have all components, so not every project will have all the component on the list. Frequently some components are not available when an initial kit is prepared for analysis and proposal needs, but will be available when the project begins. If it is not possible to include some of the components in the first kit, but they are expected to be part of the project, it is a good idea to include any information that is available about them, even if the information is vague to some extent.

Ideally, to guarantee effective production, all the professionals occupied in the localization process must provide their input.

THE USERS OF A LOCALIZATION KIT

Localizers, translators, testers, engineers, and project managers or leaders are all potential users of the localization kit.

Testers and engineers also require information about what to do with the files. Providing test cases to the tester in addition to an overview of the project will guarantee that the project is checked thoroughly.

PROJECT MANAGERS

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

Project managers that work for localization vendors need the following information:

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

LOCALIZERS

Localizers will be interested to know what are the files that need to be localized, what is the target audience for which they localize and, in most cases, what must not be changed in each file. Rather obviously, they will also be interested in the total word count and the number of words in every file. They will value information, instructions, and comments regarding the strings that need to be localized and their features.

ENGINEERS

Engineers will be interested in getting instructions for modifying the code, in order to check functionality in the target locale. Engineers will be interested as well in hardware and software necessary for building, and in compilation and testing instructions and procedures. For adjusting the layout of dialog boxes, instructions about testing must include the operating system version and the configuration settings required.

If complete software engineering and layout testing is required from the localization vendor, batch files must be provided to the localization engineers, that allow automatic configuration of required system parameters and compilation in all languages. The files must be located in a special folder. It is imperative that all code is stable enough for testing.

CREATING A LOCALIZATION KIT

A localization kit helps complying with client deadlines and with quality and service requirements by establishing better communication, and clarifying expectations. Internationalization readiness of products to be localized must be verified prior to localization, to facilitate the leverage of this work across multiple language versions.

Before localization begins, localizers must take into account various issues such as:

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

When creating a localization kit, stick to the basics:

1.        Set standards for the types of information that need to be included, what level of detail is correct, general presentation instructions and guidelines regarding what to include, and what is important;

2.        Provide separate sections for each component of the product, to have discrete expectations on web sites, software deliverables, and marketing collaterals;

3.        Reference all external documents with the exact version, together with information about how to access them;

4.        Always request client approval of the kit and all the deliverables listed in it prior to the delivery to the localization vendors;

5.        Make sure that the localization vendors review draft versions of the kit to provide the opportunity for questions and feedback before the final project delivery;

6.        After the project is completed, conduct a post-mortem review, for future projects.

When content is added afterward, arrange it in a small localization kit to complement the main one, with its own set of resources, documentation, tools, and code to avoid having to rearrange the original localization kit in order to include the new content.

Nevertheless, even though a localization kit can help avoid the frustration, cost, and delays derived from not stating the expectations clearly, it cannot be a substitute for normal communication between clients and vendors.

THE CONTENTS OF A LOCALIZATION KIT

Nowadays, a software product is composed of various types of objects that must be archived for re-releases, ported to diverse platforms, and created exclusively for OEM?s (Original Equipment Manufacturers.) Software products can be pre-installed on computers or bundled with other hardware.

These archives will be used as well to produce all the necessary patches, which should subsequently be added to the archives, after they have been completed.

The localization kit is what the localization vendor needs. Each client has different requirements, timetables, constituencies and deliverables. Consequently, localization kits will differ from company to company, and sometimes from project to project. However, some components should be included in nearly all kits.

A localization kit generally consists of hundreds of files, some of these files are translatable and many are not.

To develop a software application, all the resource files and code files are necessary, these files are then compiled into a binary or executable file that can be run on a computer. Therefore, a complete localization kit must have build environments for software applications and/or the associated on-line help files.

Examples of resources are the bitmaps used in toolbars, for example the printer icon that executes the print command. In a good number of cases, it is not necessary to change these resources for the localized versions of the product. The information to be translated, such as menu options, dialog box text, and error messages, is stored in resource files. A software product that has been correctly internationalized stores all translatable text in one or more resource files, helping to make the localization job relatively simple. Nevertheless, in numerous cases, files containing text that needs to be translated are found all throughout the build environment.

The localization engineer is responsible to locate and identify all the translatable files and make them ready them for translation. Localization engineers should make certain that translators know exactly what they have to do, so they can start quickly.

To assemble a complete localization kit some general steps can be followed:

1.        prepare the project;

2.        research the possible obstacles in a specification;

3.        identify the audience;

4.        identify the scope;

5.        write instructions for all the specific groups of people that work on the project;

6.        organize and assemble all the necessary resources, documents and tools;

7.       to test the localization kit, run a pilot project.

To help the project manager in the compilation of the instructions for the members of the localization team, the localization kit should include:

• a UI (and probably error messages) flow chart that describes how the overall UI works as a whole, and defines the context of terms; UML use case, activity and sequence diagrams can often be adequate enough;
• software and hardware specifications that describe any proprietary software that is necessary for localization, with instructions regarding how to acquire, install, run and use it;
• on-line help (in source and compiled version), user documentation, and project documentation;
• specialized tools needed for localization;
• all text, art, packaging, multimedia, and any other material that needs to be translated, in the source language.

If any of the objects  that a localization kit is missing or is insufficiently detailed, the localization kit might be difficult to use, and the time to answer questions and supply missing information or resources will not be included in the budget, and therefore, will turn into intolerable costs.

PROJECT MANAGEMENT

The localization kit must be divided into sections specifically created for the team working on the project, resulting from a well-organized folder structure, although future versions of the common operating systems will have deeply integrated indexing features, which will make a folder system almost obsolete.

The prime responsibility of the project manager is to complete the localization kit with a section that is specific to  the project.

All localization kits should include a letter of assignment to be signed and returned by all the members of the localization team, to serve also as a contract between the parties, if necessary. The letter of assignment should contain all the quotations, grouped by component, the change management agreement, the milestones of the project , and the ?freezing points? of the development cycle.

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

STATEMENT OF WORK

The objective of a statement of work (SoW) is to describe the work requirements, i.e. ?what needs to be done?, for the project. A SoW will be the basis for prospective offerers to make their bid for the contract, and when the SoW becomes contractual, it will serve as a standard for determining whether the supplier meets the stated performance requirements or not. The SoW will also support the localization project manager to outline the required work effort by means of a WBS (Work Breakdown Structure) diagram and to establish a timetable of delivery.

The SoW must include, but is not restricted to, all the following items:

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

To prevent any disputes about word counts, it is necessary to provide indications regarding the counting tools and methods, in addition to the resulting analysis log files. Each log file must 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, maximum number of hits, minimum match value, penalties, etc.) must be specified to allow the members of the team to properly apply the translation memories and reproduce all statistics.

These same settings must also be used to generate statistics for progress reports and graphic projections of delivery dates.

BILL OF MATERIALS

Each SoW must be indicated with a version number to allow traceability of updates and be associated with a detailed bill of materials (BoM). The BoM must include:

• a list of the files to be localized, grouped by type;
• an image of the directory structure of resource files, compiled files, build 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 source files and build environments;
• a list of documentation files.

Excerpt of a list of files to localize from a bill of materials

REFERENCE MATERIAL

The responsibilities of the project manager include the arrangement of reference materials for the project, which should normally include:

• all relevant background information concerning the product;
• the latest localized version of the product in the requested language(s);
• documentation files;
• product reference and overview information;
• style guides for each target language addressing writing and design issues;
• 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.

SOFTWARE

During the development of the in localization kit, the localization project manager must identify elements that may perhaps 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 for the appropriate information in the resource file. If isolation is necessary, the localization project manager must send the code back to the software engineers with appropriate instructions for correction.

Example of a terminology correction report
Terminology correction report: < product name > GUI Italian

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

Example of a progress report

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

Before actually beginning the localization process, the localization project manager must make sure that the original text is clear and concise, grammatically correct and free from technical expressions and slang that may lead to mistranslations. The localization project manager should also verify language and references consistency and translation memory integrity and correctness.

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

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

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

TRADITIONAL SOFTWARE

"Traditional" here to mean desktop or handheld static software in contrast to Internet software. A traditional software section must include:

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

INTERNET SOFTWARE

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

Thus, the first concern of a web localization project manager must be protecting the code from accidental changes and assembling a language pack. If the product has been properly internationalized, all localizable text should have been extracted from code and a language pack should be made up mostly of the string tables and the language-specific image files. All translators will have to do, is to translate the relevant column of the string table.

In a properly internationalized product, translatable text is usually located in a text file that is included in server-side scripting files with an <!-- # include file/virtual=?...?--> statement. Each module of the site must contain a folder where these include files are kept, distinct from the main web site folders.

A standard language pack for an Internet software section must include:

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

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

DOCUMENTATION AND ON-LINE HELP

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

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

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

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

All files must be included in the localization kit according to a correct directory structure. The creation of a folder called Documentation is recommended, with subfolders labeled Project Documentation and Product Documentation.

The Product Documentation folder may contain a User Documentation and an On-Line Help subfolder.

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

Lastly, the User Documentation folder of a localization kit must contain a bill of materials in the form of a spreadsheet listing:

• the files that require localization and their location, with indications regarding the text that needs to remain in the original language;
• the fonts used in the source files and the fonts to be used for the localized version.
• the format of source files and the validation and authoring tools and versions used to create them;
• the formats required for output files and the validation and authoring tools and versions needed to produce them; 

The On-Line Help folder should contain the following items:

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

If a compiled version is necessary, the On-Line Help folder should also contain a copy of the compiler.

The on-line help associated graphics can also be stored in a specific Graphics subfolder under 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 can contain project guidelines and project templates, the project style guide stipulating all style conventions, naming conventions and typography. Where possible, the folder should also contain the style guide that was 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, the guidelines and instructions for text expansion, and information about the printer driver version and the printer description file to be used. If any special fonts are used, the localization guide must also specify the font requirements. Finally, the localization guide must provide instructions for help testing, including required platforms, operating systems, browsers, and relevant versions, and for DTP compilation, including the compiler version.

The Project Documentation folder can contain as well a bill of materials in the form of a spreadsheet listing file names, types, and a concise explanation of the purpose of each file, as well as any other necessary notes, including any special fonts required.

GRAPHICS

The User Documentation and the On-Line Help folders can contain a specific Graphics subfolder each; alternatively, a generic Graphics folder can be created in the root folder of the localization kit.

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

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

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

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

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

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

MULTIMEDIA

In view of the fact that more and more localization projects now include an audio/video component, it is important to demonstrate both comprehensive studio talent and technical capability.

Multimedia comprises a vast range of document types that may contain two or more of text, graphics, video, sound, and animation; consequently, a very basic principle in making multimedia files states that digital localizable elements must be separated from one another on different tracks on the timeline.

The ideal situation is to provide to the localizers the project files and project settings from which the presentation was created. In properly encoded AVI movies and MPEG video, audio and video streams can be extracted and separated in order to save them back after localizing or editing.

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, voiceover tracks, and sound effects) and video streams;
• separate sound effects and voice tracks;
• a copy of uncompressed videos with the text to be localized.
• any specific codecs and movie viewers used to create and play compressed versions of videos;

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

Once more, it is necessary to provide a print-out of all documents requiring translation.

Then, a spreadsheet must be created with all the information available for the multimedia files. This spreadsheet can be stored in the Project Documentation subfolder under the Documentation folder of the localization kit, and must include:

• a list of the applications used with a special reference for combination or dedicated multimedia environment;
• specifications for additional space on CD-DVD?s for distribution;
• voiceover technical specifications;
  
  • format of the voiceover files in the source language;
  • format of the localized voiceover files.

The multimedia section of the localization guide, must include:

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

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

COLLATERALS

Peripheral documents are generally referred to as ?collaterals?.

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

The localization kit must include a Collaterals folder containing:

• the compiled versions of the graphic or the DTP 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 the version for printing (usually EPS);
• the compiled versions of the graphic or the DTP 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 fonts used in the source files and those that must be used for the localized version.
• the license agreement, in plain text or rich-text format;
• the ReadMe file, in plain text or rich text format;

Again, a print-out of the all material that requires translation must be provided.

Then, a spreadsheet must be created with all the information available for collaterals. This spreadsheet can be added to the specification worksheet stored in the Project Documentation subfolder under the Documentation folder of the localization kit, and must include:

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

In addition, the collaterals section of the localization guide must include guidelines and instructions for text expansion, instructions for DTP compilation, including the compiler version, and special instructions about how to deal with tax, financial, or legal issues.

DELIVERY

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

Before issuing, a third party must verify the content of the localization, making sure that there are no key tools or information necessary for localization, that are missing:

1.        all files must be checked for corruption;

2.        all files must be scanned for virus;

3.        there should be no missing files;

4.        no extra files must be included;

5.        all files must be the most current.

Finally, the localization kit must be stored on a CD or DVD with a label that includes:

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

If the localization kit is updated to include additional content or patches after the product is released, it is necessary to create a mini localization kit with the key objects stored on a separate disk with a label that contains the same information of the main localization kit and an additional tag stating it is an addendum.

WRITING THE LOCALIZATION GUIDE

The localization guide must be created before the actual work on the project begins, in conjunction with the project work plan.

The localization guide contains the instructions for localizing a product. The policies contained in the localization guide may differ according to the product or company.

Although it may seem time-consuming to develop, a good quality guide can be adequate for different projects; therefore, in most cases, it is created once, but can be used on subsequent projects with little modifications.

In order to make sure that the localization of the project runs smoothly, better instructions guarantee fewer problems. Therefore, the development of a good localization guide involves:

• establishing who will use the kit and what their needs are;
• explaining what are the contents of the kit and how to use it;
• ensuring that the kit is usable and complete.

Instructions must be provided regarding how the localized material being returned must be formatted and organized.

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

The localization guide in the localization kit must accurately record and clear all issues and closely track changes. All lists must be kept updated to function as valid and trusted tracking tools. The localization guide must as well be updated without delay with answers to issues and questions raised. The localization guide must therefore include:

• localization guidelines and timetable information;
• special instructions for file handling, including the applications that must be used with their version, platform, etc., and any manual or special processes; 
• instructions about how to handle concatenated strings;
• guidelines for dealing with text expansion;
• instructions for the resizing of dialog boxes and other cosmetic changes;
• guidelines for the localization of keyboard shortcuts;
• naming conventions (whether long filenames or names including special characters or spaces can be used, or it is necessary to use 8.3 filenames);
• file types expected to be delivered.

The localization guide must ultimately provide for project logging and detailed communication procedures.

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

INTRODUCTION

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

PROJECT ORGANIZATION

Mention the most important project roles and the actual people involved, perhaps including an organigram. A correct project organization structure is illustrated in the following list:

• project director;
• localization manager;
• project managers (on the client?s and the vendor?s side);
• project leader(s);
• project team members.

PROJECT ISSUES

Describe the overall objectives of the project, including an overview of the overall project plan, stating cost estimates and a top-level timetable for the project.

STATEMENT OF SCOPE

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

Place the software in a product or business line context and outline the main strategic issues in order that the reader can understand the ?big picture?. If possible, provide a usage scenario for the software, including the control flow for the system and a description of the software interface(s) to the outside world.

CONTENTS OF THE KIT

Give instructions for pick-up. Explain how the kit is organized; give instructions for unpacking and installing the kit.

RESOURCE REQUIREMENTS

Provide a general description of all software, hardware, personnel, documentation, and data requirements, including a context-level model of the system architecture.

Resource requirements should specifically describe:

• hardware items;
• interfacing equipment (IME);
• operating systems;
• special equipment;
• computer setup (hardware, platform, memory, path settings);
• specifications of any database back-end, if this applies, and the data required by the application to be extracted to allow the localized version to be built.

TOOLS, TECHNIQUES AND METHODOLOGIES

TOOLS

It is necessary to create a Tools folder that includes a subfolder for each tool, labeled according to the name of the tool.

Specify the programming language(s), compilers, tools and scripts, used to develop the software, and provide a list of the specific tools, techniques, and methodologies that is necessary to use when performing the testing and localization activities.

TECHNIQUES

Describe the procedure for localizing each type of file and how to use proprietary tools included in the kit. Specify whether it is necessary to deliver translation memory, and if so, in what format.

Give instructions about how to deal with composite strings, gender, word order, articles, plurals, error messages, and text expansion.

When the software can only be localized by translating string resource files out of context, provide screen captures in the source language to better understand the context-less strings and include a description of the syntax of the string resource files and how to deal with control characters.

Give instructions about how to deal with tax, financial or legal issues.

METHODOLOGIES

List the specific work tasks that need to be performed in order to comply with the project requirements, to allow the acquirer and the offerer(s) to estimate the probable cost and the offerer(s) to establish the levels of manpower, expertise,  and other resources necessary to accomplish the task. If a Work Breakdown Structure (WBS) is used in the project, arrange tasks according to the WBS.

State the specific obligations of the vendor in such a way that the vendor knows what is required and accomplishes all tasks to the satisfaction of the client.

DELIVERABLES

List and describe the deliverables of the project. Provide adequate explanations and details to allow the reader to understand what is being produced. Include a chart showing deliverables according to the project main milestones.

RISKS

List and describe events or circumstances that are beyond the control of the project team and that can have an adverse impact on the project, so that all the project stakeholders can anticipate and manage them, thus reducing the possibility that they will occur.

Risks must be listed with their probability of occurrence and possible negative impact. For each risk listed, identify the activities that can be performed in order to eliminate or mitigate the risk.

COMMUNICATIONS

Project managers must be in contact on a regular basis with stakeholders, to inform them about the current status of the project and to manage future expectations. If these key people are not kept properly informed about the progress of the project, it is more likely that problems will stem from differing levels of expectations. As a matter of fact, in many cases where conflicts arise, it is not because of the actual problem, but because a stakeholder or customer was taken by surprise.

Establish a communication plan in order to determine what are the communication needs of all the people involved with the project or that will be affected by the project and provide timely and consistent information to all project stakeholders.

Provide a project status report for all project team members to fill in on a regular basis.

Following is a recommended project status report template to be combined with a progress report like the one in the reference material. See the Project status report template on the next page.

QUALITY ASSURANCE PLAN

Describe the different quality assurance tasks that will be performed for the project and indicate how they will be synchronized with the project milestones. Provide references to any guidelines and standards that are expected to be used on the project, and explain how compliance with these guidelines and standards shall be determined. Attach or provide references to any relevant artifacts.

QUALITY OBJECTIVES, CONTROL, TOOLS AND METRICS

Outline the quality expectations for the product and the quality level considered to be acceptable for each deliverable.

Describe the tasks involved in the creation of the project deliverables, to verify that deliverables are of suitable quality and that they comply with the correctness and completeness criteria established.

List any quality-related tools that the project will use.

Describe the project, product, and process metrics that must be captured and monitored for the project. Provide descriptions of the different quality records that will be kept during the project, including where and how each type of record will be stored and for how long.

In a localization context, there are mainly two types of metrics: business metrics and production metrics. Business metrics focus on measuring value. Production metrics focus on measuring efficiency. 

Any metrics requires as much data as possible, and, to be collected, data must be defined and tracked. See the List of sample metrics below.

TEST PLAN AND VALIDATION CRITERIA

Describe the approach to functional testing issues for validation as well as the types of tests to be performed, including as much detail as possible. Specify the software and hardware resources, setup settings, and performance requirements and the results expected from the testing. Indicate who is responsible for bug fixing.

If it is necessary to use a script suite for automated testing to reproduce the expected usage of the product, provide instructions about how to run each script.

Further, it is vital to outline the functional flow of the software user interface, so that testers do not need to go through all of the functionality for each segment.

To allow the vendor to set up and run a project-specific testing platform, provide the following information:

• names of the platforms on which the product runs;
• any special software or hardware required for testing and setup;
• name of the compiler and its version;
• compilers;
• test documentation, technical references;
• test drivers;
• test data generators;
• list of known bugs;
• type, size, and composition of the data to support the acceptance tests;
• instructions to build the product on a clean machine;
• level of internationalization testing done;
• a list of platforms, browsers, viewers with which the localized software must be tested.

Finally, to correctly assess the advantage of the tests performed, provide instructions for accessing the bug tracking database.

WEB LOCALIZATION ISSUES

Web localization presents a few specific issues that require consideration.

Given that the localization of HTML documents is relatively easy, particularly with translation tools that allow the ?locking? of tags, instructions must be provided to identify and access localizable content within scripts that is not easily parseable by mechanical means. Provide instructions to separate UI, code and content elements, and to identify the code that governs the UI and the code for back-end functionality, since the back-end functionality of the site produces the items visible to the user and must be identical for all languages.

Provide code adaptation guidelines according to the new directory structure, charset, etc. Set up strict naming conventions to prevent behavioral differences between Windows and Unix/Unix-like (case-sensitive) platforms, in addition to the Web server approach to extensions.

Provide information for the application/site structural analysis as per:

• platform;
• operating system;
• application server; 
• Internet server;
• technologies.

Provide instructions about how to handle dynamic content, that is the part of the application/Web site frequently updated or event-driven often stored in a database in various formats.

Lastly, provide instructions about how to handle keywords, taxonomies, profanity filters and stop word lists.

TERMS AND DEFINITIONS

ACCELERATOR/SHORTCUT (KEY)

A keyboard key combination used to access functions in menus and sub-menus. It is typically represented by a mnemonic which is shown as an underline on the menu line; the mnemonic usually refers to the initial letter of the function.

BUG

A persistent error in the routine or code of a program originating malfunction.

BUILD

The compilation of several software resource files into a single, final product that can be executed by a computer.

BUILD ENVIRONMENT

The methods, tools and procedures used for compiling software.

CASE

Computer-Aided Software Engineering; software tools used in software development for design, programming, analysis and maintenance that provide automated methods for designing and documenting traditionally structured programming techniques, and a symbolic language for describing all the software or parts of it, and generating the necessary code.

CHARSET OR  CHARACTER SET

1.        A definite set of characters used by a specific computer system, in which no coded representation is assumed.

2.        The mapping of characters from a writing system into a set of binary codes.

COLLATERAL

All the document(s) planned for publication and the media used by a company for communication.

COMPILING

The conversion of a source code program into an executable program.

DELIVERABLE

The measurable, tangible and verifiable output or result of a process to be produced to complete a project or a part of it.

DTP

Desktop Publishing; the techniques and software used to format and lay out text on pages and to produce high quality camera-ready or printed materials such as software manuals for commercial printing.

GUI

Graphical User Interface, the combination of screen design, menus, keyboard commands, command language and online help, which creates the means by which a user interacts with a computer.

INTERNATIONALIZATION

The procedure of creating source material that is locale independent, where all market-specific and language-specific content resides outside the core application and all the information is presented in a format to which the end user is familiar; internalization also implies making a product localizable.

LEVERAGE

The portion of translated material from an earlier version that can be reused, regularly expressed as a percentage.

LOCALE

1.        An international language and geographic region which also embodies common language and cultural information. Locale is different from language in that the same language may be spoken in more than one country.

2.        The features of the computing environment of a user, that are dependant on language, geographic locations, and cultural information determining conventions such as date, time, and currency formats, sort order rules, keyboard layouts AND OTHER CULTURAL CONVENTIONS.

METRICS

System of methods or parameters for the quantitative assessment of a process that is to be measured, together with the processes to perform such measurement.

MILESTONE

A critical and identifiable phase in the completion of a project whose failure can produce significant problems; in project management, a milestone is an activity that has no duration, generally indicating the end of a period and corresponding to the completion of a major deliverable.

QUALITY ASSURANCE

The process of assuring that the target application or document resembles the source application or document as closely as possible through successive checks.

RESOURCE FILES

Source files that include information to be compiled into the program as well as the parts of the application that is seen by the user.

REBUILD

Recompilation of the software after translation and resizing, construction of the localized version of an application.

SCREENSHOT

An electronic image depicting a particular on-screen state of a software product used in documentation and  online help to explain or illustrate a specific software product function to the user.

SIM-SHIP

Simultaneous shipment; the release of all language versions (original source and localized ) of a particular product at the same time.

SOURCE CODE

The human readable code that is compiled to make a program.

SOURCE FILE

A file that contains the source code which is used to compile an executable program.

STRING

Grouping of characters (letters, punctuation marks, and/or numbers) that needs to be translated since it contains text used in programs for button labels, names of dialog boxes, menu options, error messages, etc. that will be seen by the user. Strings are frequently enclosed in single or double quotes.

STYLE GUIDE

A guide developed in order to define the translation style for a target language. The style guide can include guidelines regarding the writing style, grammar, punctuation, usage, font and typeface, capitalization, etc.

TEST SCRIPT

Written procedure and instructions for testing a software product (either source product or localized product).

USER INTERFACE

The combination of menus, screen design, command language, keyboard commands and online help, which creates the means and ways a user interacts with a computer.

VOICEOVER

Adding audio to a video, in which the speaker?s lip movements cannot be seen.

APPENDIX

LOCALIZATION GUIDE FOR <PRODUCT NAME>

NOTICE

Please note that all work that is delivered back to us must comply exactly with the specifications below. Non-compliance may bring about payment deductions and quality actions up to and including deactivation from our contractor database.

INTRODUCTION

<product name> is made-up of many elements that need localizing:

1. User interface;
2. Microsoft Access local database;
3. Microsoft SQL Server database scripts;
4. Screenshots;
5. User guide;
6. Online Help.

To correctly localize all elements, they must be translated in this order. The attached CD contains all the necessary files. They are all included in the Source folder.

REQUIREMENTS

To perform the localization of <product name>, the following hardware and software is necessary:

• <product name> ;
• the <product name> dongle;
• Microsoft Access 97 or above;
• Crystal Report 9 or above;
• Microsoft Word;
• a CAT tool such as Trados;
• a graphics tool to take screenshots such as GIMP.

Before starting, please go through the following steps:

1. Install a local version of <product name> with its dongle;

2. Spend a few hours training on the operation of the software.

USER INTERFACE

The user interface is possibly the most difficult element to localize, but unfortunately it must be the first.

TOOL

To localize the user interface <tool name> must be used. <tool name> can be found in the Tool\<tool name>\Program folder of the CD. Refer to the <tool name> user manual in the Tool\<product name>\Manual folder of the CD for instructions about how to install, launch and configure the tool and on how to work with files.

RESOURCES

The resources for the user interface are located in the <tool name> Source\Resources\<lang> folder of the CD, where <lang> is the two-character ISO 639 code for the language. Copy the folder with the files you will have to process to your local hard drive. Right-click on the folder on your hard drive, select Properties and remove the read-only attributes for the folder, subfolders and files.

FORMS LOCALIZATION

Forms must be localized first. Please refer to the <tool name> user manual in the Tool\<product name>\Manual folder of the CD for instructions about how to use <tool name>.

GUI DESIGN

If strings appear truncated in the translated form, try moving or resizing elements directly from within the translated form.

RULES

Not every property and window must be translated.

Do not translate

[The list of elements/values not to be translated follows]

SHORTCUT LETTERS

The character & must be move to the appropriate letter. It designates the shortcut letter. For example, &Save indicates that the user can press Alt+S to activate this menu. Check that there are no two items in the same menu with the same activation letter.

RECOMMENDATION

Save before activating another form/window.

RESOURCE SCRIPTS

After completing the localization of forms, please localize the resources strings. Some of them do not come from themselves but from the components they make use of. Please localize the strings from <product name> only. They can be identified by the label ?<label name>?.

VARIABLES

Some strings contain variables such as %s, %0:s, %1:s, etc. These variables will be replaced by text during the execution of the program. For the proper execution of the program, these variables must be included in the translation.

However, the order can be changed to reformulate the sentence and make it grammatically correct in the target language.

RECOMMENDATION

Make sure that all translations are enclosed in single quotes.

Do not forget to save every once in a while.

DELIVERY

After completing the translation of the user interface, zip the <lang> folder on the local drive along with all the sub-folders and send the file to <customer name>. Make certain that the folder structure is kept unaltered.

REBUILDING

The rebuilding will be carried out at <customer name> with the translated resources to produce a localized version. In addition, few tests will be performed

to verify the software run.

Once these tests have been completed, it is possible to download a new version of the for further testing.

MICROSOFT ACCESS LOCAL DATABASE

CREATING

Copy the Microsoft Access local database from the Source\Database\Access\<lang> folder of the CD to the local drive. Remove the read-only attribute from this file.

OPENING

Launch <product name> in the target language in order to open the Microsoft Access local database and translate its content. When opening the database with any version of Microsoft Access, the program requests a password. The password for the database appears in the dbpwd.dat file in the \Source\Database\Access\<lang> folder of the CD. When opening the database with Microsoft Access 2000 or higher, please do not convert the database, because the software can eventually not work properly.

LINGUISTIC TEST

Starting with the setup module, launch each module one by one and verify that there is no data in a language other than the target language. If there is any, please translate it before submitting the software for functionality testing.

During the translation of the database, check each module for the accommodation and correctness of the text. Please use the terminology query sheet to report any changes that are needed in the user interface.

DELIVERY

After completion of the translation of the Microsoft Access local database, zip the Source\Database\Access\<lang> folder on the local drive and submit the file to <customer name>.

MICROSOFT SQL SERVER DATABASE SCRIPTS

All scripts are contained in RTF files in the Source\Database\SQL_Server\<lang> folder of the CD. Copy this folder to the local drive. Remove the read-only attribute from all the files.

Open these files with Microsoft Word and, if possible, translate them with TRADOS displaying only the text to be translated. This is appears in black, while the text that must not be translated appears in grey.

DELIVERY

After completion of the translation of the Microsoft SQL Server database scripts, zip the \Source\Database\SQL_Server\<lang> folder on the local drive and submit the file to <customer name>.

SCREENSHOTS

The manuals of the product contain many references to the software through screenshots. Please take all the screenshots before starting the translation of the manuals. All screenshots (about 400 pictures) are stored in the \Source\Documentation\Screenshots folder of the CD. Each screenshot must be taken in the target language after the completion of the user interface localization. The new pictures must be exactly the same size as the original, with the color depth of the workstation limited to 16 bit (65K). Store the new localized pictures in a \Source\Documentation\Screenshots\<lang> folder on the local drive.

DELIVERY

After completion, zip the \Source\DocumentationScreenshots\<lang> folder on the local drive and submit the file to <customer name>.

USER MANUAL

The user guide is located in the \Source\Documentation\User_manual\<lang> folder of the CD. Copy this folder to the local drive. Remove the read-only attribute from the usrman<lang>.doc file and open it using Microsoft Word. Activate the field code visualization option and search ?D://<product_code_name>//<version>//User_manual//Graphics//? to replace it with the path of the new screenshots.

De-activate the field code visualization option to verify that the new screenshots appear in the manual.

Start translating the document with a translation tool to save it in a memory for future versions of the product and respect the style and formatting of the original document. Save the translation memory in the same folder as the manual.

A compiled version (in PDF format) of the user manual is available in the \Source\Documentation\User_manual\En folder of the CD.

DELIVERY

After completion, zip the \Source\Documentation\User_manual\<lang> folder on the local drive and submit the file to <customer name>.

ONLINE HELP

The source files for the online help are located in the \Source\Documentation\Online_help\<lang> folder of the CD. Please translate both files with a translation tool that uses the same database as the user manual.

The online help files are both standard Windows help files. A compiled version can be found in the \Source\Documentation\Online_help\En folder of the CD.

FOOTNOTES

An online help source file has three kinds of footnotes:

• K, keyword (To be translated)
• $, title (Not to be translated)
• #, topic ID (Not be translated)

The keyword footnote can be extended or reduced.

GRAPHIC LINKS

Graphic links such as {bmc graphics\floating_menu.bmp} must not be translated. The help compiler interprets them during rebuilding and attaches the corresponding graphic .

TOPIC JUMP

Topic jump allows the reader to click on a link and be directed to the chapter explaining this topic. A topic jump is made-up of two parts. The first part in green double underlined is displayed to the reader and must be translated. The second part is hidden text and must not be translated. Never introduce spaces between the first and second parts of a topic jump.

TABLE OF CONTENTS

Upon opening a help file, the reader is prompted with the table of contents of the help file. This is stored in a separate file with the extension .cnt. This is a plain text file that can be translated with a translation tool.

The first line of a .cnt file must be modified to show the name of the help file; in the second line only the text after ?Title? has to be translated. In the following lines do not change the initial number, translate the text before the = sign, and keep the second part unchanged.

DELIVERY

After completion, zip the \Source\Documentation\Online_help\<lang> folder on the local drive and submit the file to <customer name>.

DELIVERY SCHEDULE

DIRECTIVES FOR DOWNLOADING/UPLOADING FILES FROM/TO THE L21NCO. FTP SERVER

To download or upload project files from or to our FTP server through a standard ftp client use the following parameters:

Note: once in the download directory (from_l21nco) you will be able to see filenames. However, in the upload (to_l21nco) directory you will not be able to see filenames.

SUPPORT

Please note that all project messages must be written in English, so that they can be forwarded to any team member as necessary.

*******

WSL can help you convert your product (software, documentation, online help, multimedia, etc.) into other languages.

WSL - Weizman Software Localization specializes in Hebrew and Arabic, as well as FIGS (French, Italian, German, Spanish) and CJK (Chinese, Japanese, Korean). We also handle Russian, Dutch, Portuguese, Swedish, Turkish, and other European and Asian languages.

For more information on our translation services, please download our profile HERE,

or contact:

Sagi Adiv
WSL - Weizman Software Localization Ltd.
www.WSL.co.il

Kibbutz Giv?at Ha-Shlosha, P.O.Box 379,

48800 ISRAEL

Tel: 972-3-9018890

Mobile: 972-54-3286565
Fax: 972-3-9018897
wsl-info@wsl.co.il

Copyright - 2009 Weizman Group, All rights reserved.

Tags:
WSL | Technical translation | Content | Development | DTP | Translations | Software Localization | Multimedia | Product | Project and Localization Managers | Publishing | Services | Software | Software internationalization | Technical | Translation | Vendor | Webmasters, Development and QA personnel | Weizman  | Building a localization kit