Definition
A localisation kit (LocKit) should provide all the information that translators require for localisation. It is target-oriented and includes, besides the files to be localised, a description of the workflow, the resources (glossaries, style guides for user interface, etc.) and sometimes also tools (L10N tools, translation memories, editors, etc., very often in form of free translator versions, which only allow the translator to process the corresponding project and do not allow the creation of own new projects) to be used during localisation (Müller, 2005).
Of course, software localisation projects involve many organisational details, which are generally taken care of by the project manager. A way to avoid communication problems in a localisation team is, for example, to give all participants in the project an overview of all phases of the project: this is the localisation kit.
This section summarises step-by-step tips given by Zerfaß (2005a) on how to create a LocKit.
Localisation Plan
This gives an overview of all phases of the project:
- Product description: product name, use, website, previous versions, word count
- Previous versions: in which languages are previous localised versions available, who was responsible for localisation
- Team: name and area of responsibility of team members; organisation chart
- Project scope (see also eCoLoTrain PM Course 1)
- Timeline
Overview of Files to be Translated and File Structure
This overview allows every team member to know who was responsible for creating, modifying, translating each file in case there are changes to be made or questions regarding terminology, etc.
- Information on file naming conventions and folder structures
- Type of file formats to be translated: original source formats and final target formats to be delivered
- Languages in which files have to be translated
- Person in charge of translating, editing or converting files
- Communication medium for sending files: via email, FTP, etc.
Selection of Tools
It is known that a software localisation project can involve several types of files, such as for example: software files, online help files (e.g. RTF), websites (e.g. HTML), documentation (FrameMaker, XML, etc.), marketing and packaging material (QuarkXPress and InDesign), readme files (TTX), etc.
Depending on the file types, the tools to be used in a specific project will be selected. When doing this, project managers and/or localisers have to consider the versions and settings for the tools to be used. This is important since, for example, using different versions of the same tools can cause problems – files created by an author using a tool version X may not be able to be opened after translation because a previous version is being used. An example list of possible issues to regard is the following:
- Tool name, version number: who in the team will offer technical support regarding the use of the tool? How many licences for the tool are available and what are the restrictions?
- Tool description: what does the tool do? Who will use it? Do other tools have to be previously installed on the computer? Is there training material available? And if yes, where?
- Tool usage: what functionalities are going to be used? which settings are going to be used?
Important information for localisation teams is given in the following sections:
Preparation/conversion/localisation of files
These processes may involve:
- Installation of templates or fonts that might be needed for the files (e.g. when DTP files have to be opened in a DTP application for extracting translatable text)
- Preparation of translation memories (TM) for the language pairs. If there is no TM available, but there are previous translations, texts can be aligned to create a new TM
- Word count
- Checklist for translators, proofreaders, layout specialists, software testers, etc.
Reference Material
Among the reference materials that should be delivered to translators, are:
- Informative materials on the product, such as product overview, marketing brochures, website, etc.
- Complete source language software to be installed by the translator, in order to see the effects of certain options and commands
- Information on previous versions of the product (in the source language or in different languages) and even previously-localised versions to be installed by the translator
- Bilingual glossaries
- Monolingual glossaries (for the source or target language with definitions and context)
- A PDF version of the original file for translators working with layout files
- Information on the target user group
- Style guides: company specific terminology, terms that should not be translated, etc.
The localisation team should know:
- Who will be contacted in case of terminological questions, technical issues, etc.
- Which team member is responsible for making decisions on specific issues?
- Which templates are going to be used for bug reports, status reports, request forms, etc.
Process Description
Processes should be at least briefly described for all localisation team members:
- Conversions, text to be translated or protected (so that it is not changed during translation), insertion of comments for translators, developers, etc.
- Terminology approval process
- Quality assurance: usage of external or internal resources (proofreaders, layout specialists, etc.), implementation of changes in terminology, in translation memories, etc.
- Exchange of translation memory and terminology data between the different tools used (TM systems, software localisation tools, authoring tools, etc.)
- Information on issues such as text expansion, terminological inconsistency, etc.