Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Building a Localization Kit


Published on

Guidelines to set up and maintain a localization kit for a (software) product.

Published in: Education
  • Be the first to comment

Building a Localization Kit

  1. 1. Building a localization kit Luigi Muzii
  2. 2. Building a localization kit WarrantyThe information contained herein is supplied without representation or warranty of any kind, and does notrepresent a commitment on the part of Luigi Muzii. Therefore, Luigi Muzii assumes no responsibility and shall haveno liability, consequential or otherwise, of any kind arising from this material or any part thereof, or anysupplementary materials subsequently issued by Luigi Muzii. Luigi Muzii has made every effort to ensure theaccuracy of this material and intends the information contained in this document to be accurate and reliable, arenot responsible for typographic errors or other inaccuracies in the content provided, and reserve the right to modifythis document and the information contained herewith without notifying current or prospective users. If you haveany questions or comments, please contact:All the products mentioned in this document to describe firms and their products are registered trademarks ortrademarks of their respective proprietors.Copyright © 2005-2011 Luigi Muzii. All rights reserved. Printed in Italy.This document is the property of Luigi Muzii. Any modification, copy, transcription, distribution, republishing,translation, or upload for electronic, mechanical, optical, chemical, manual or whatsoever archiving for commercialexploitation of any kind is prohibited without the prior written consent of Luigi Muzii.Copyright © 2005-2011 Luigi Muzii 1
  3. 3. Building a localization kit Introduction The discipline of writing something down is the first step toward making it happen. Lee IacoccaTarget audienceThis document was created to address a typical common problem afflicting localization managers, localizationvendors, and project managers.This document is intended for readers with years of experience in the localization industry, as well as fornewcomers. 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 helpthem 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 atranslator’s kit instead.This document is the result of a eighteen-month work of research, retrieval, and collection of information:comments, feedback and suggestions from target readers are invaluable.General notesThe more LSP’s understand about the client’s requirements and expectations, the better able they are to meetthem. A localization kit is a subset of tools, instructions and resources necessary to produce a localized version of asoftware product.For localization project to be executed properly, localizers, testers, and engineers are to be provided with athorough and well-designed localization kit.Since quick release of localized software requires that translators begin work early, and developers can have asignificant impact on translators’ job, a localization kit will allow translators to work more independently becausethey can check their work out as they do it.The final quality and the success of a localization project depends on the amount of knowledge that is transferred tothe localization vendor. This knowledge affects:  the accuracy of the vendor’s quoting and scheduling process;  the time spent by project managers and engineers;  the accuracy of project deliverables.An effective localization kit offers a relatively easy solution to these challenges, and is one of the best things to do toensure 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 once-onlytask that always pays off. It is a huge help to all the stakeholders in a project, as it consolidates all projectinformation into one place and concisely explain expectations for the project.Copyright © 2005-2011 Luigi Muzii 2
  4. 4. Building a localization kit RationaleLocalization-friendly code allows developers to involve service providers in the process more quickly, easily andconveniently.A localization kit provides the material that serves two functions in the localization process: 1. preparing a proposal (plan, price, and schedule) for localizing a product; 2. performing the localization.A good localization kit is:  complete, containing everything that the development team must supply over and above the product itself;  usable, including clear and complete documentation on how the kit is made and how to use its contents.Ideally, corporate guidelines and a checklist for the development of a localization kit should be created, so that thekit remains consistent regardless of manager or product. This will help ensure a high quality kit, eliminate time spenton rework it, 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/plansshould 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 haveall up-to-date resources and code included, and should stand on its own. But, when sim-ship (simultaneous shippingof localized and primary versions) is required, a localization kit will be needed before the primary version is codereleased.By providing a complete set of files and requirements when requesting a proposal from a localization partner, acompany is able to ensure that the scope of work resulting from the analysis will be correct and that the cost andturnaround time estimates will be accurate. The localization kit can then be easily used to kick-off the project with aclear 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 get organized. It documents the project requirements that otherwise may be lost duringthe transfer of information to the vendor, in a well-organized document tree with fully functional files, and serves asa central repository for the information needed to localize a product and enables anyone in an organization to easilyassume responsibility for managing a project and immediately having the necessary information to request ananalysis or start the project.The content structure of a localization kitThe localization kit should be arranged during the pre-localization design and implementation stages for projectevaluation and analysis with a very simple point: no one likes surprises, that is missed deadlines and budgetoverruns. Moreover, since most software localization projects involve a large number of target languages, gettingthe translation kit right from the start would prevent many similar or identical questions from the varioustranslators.Each localization kit differs depending on project requirements, but, in all cases, the more information is provided atthe 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 andnot the binaries or libraries of the product.A well-assembled localization kit should contain all the final resources needed by localization vendors to create alocalized version of the software without assistance from the original development team. The vendors should beable to use the kit to get the resources translated, integrated, and tested without assistance from the developmentteam, and if the software code is localization-friendly, it is unlikely the source code will be needed to create thelocalized versions.Therefore, a localization kit should contain the files to be localized, identified and prepared for translation (thebinary files and the resource files), along with instructions, guidelines, indications, and notes from the developers toproject team members on how to deal with the various files and file types. It should also provide background andcontextual information about what is being localized. Whatever the product, a fully functional version (at least abeta version) of the running software should be included. Finally, a localization kit should contain all the toolsrequired to work with the files.Copyright © 2005-2011 Luigi Muzii 3
  5. 5. Building a localization kitOrganization of a localization kitGenerally, a good practice consists in organizing the files centrally, as everything to do with them is to be done asmany times as the number of languages into which these files are to be localized. Therefore, a well-organized filetree pays off when the vendors have to fix all the broken cross-references, missing files, and broken graphics; andthey will make it differently for each language!The reorganization of files in preparation for localization can partially be expedited by creating a list-of-referencesfile where the location and properties of each file are reported when the first "build" is made. A CASE (ComputerAided Software Engineering) tool can help and the list-of-references file can then become the foundation of thelocalization 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 somecomponents may not be available at the time an initial kit is prepared for analysis and proposal requests, but will beavailable when the project starts. If some components cannot be included in the first kit but are expected to be partof a project, it is a good idea to include whatever information available about them, even if it is somewhat vague.Ideally, to ensure efficient production, all the professionals involved in the localization process should provide theirinput.Users of a localization kitMany actors play a role in the localization process: localization manager, testers, localizers, and developers. Thelocalization manager monitors the project and coordinates activities; testers and engineers run testing and arrangethe source code for localizability and interact with the localization manager and the programmers; localizersperform the translation of resources.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 asan overview of the project will ensure the project be checked thoroughly.Project managersTo properly arrange an effective project plan, localization project managers must be provided with estimates on theamount 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; o project languages; o components; o number of files; o files lo localize; o number of words lo localize (per file); o files to engineer; o number of pages for DTP; o number of updates that can be expected;  project release schedule; o milestones; o hand-offs; o review cycles; o deliverables; o deliveries;  quality steps; o software testing scope and validation; o number of language reviews; o number of test cases;Copyright © 2005-2011 Luigi Muzii 4
  6. 6. Building a localization kit o platforms and operating systems.LocalizersLocalizers will be interested in knowing which files need to be localized, for which audience they localize and, inmost cases, what not to change in each file. Quite obviously, they will also be interested in the overall word countand the number of words in each file. They will appreciate information, instructions, and comments about thestrings to localize and their features.All text must be finalized.EngineersEngineers will be interested in instructions for modifying code to have it work fine in the target locale. Engineers willalso be interested in hardware and software required for building, and in compilation and testing procedures andinstructions. For cosmetic adjustments of dialog boxes, instructions on testing will include operating system versionand configuration (resolution) settings required.Should full software engineering and cosmetic testing be expected from the localization vendor, the localizationengineers should be provided with batch files allowing automatic configuration of any required system parametersand compilation in all languages. These files should be placed in a special folder.All code must be stable enough for testing.Copyright © 2005-2011 Luigi Muzii 5
  7. 7. Building a localization kit Creating a localization kitA localization kit helps meet client deadlines, quality and service goals by clarifying expectations, establishing bettercommunication and organizing the localization project drop. Products to be localized should be reviewed forinternationalization 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. 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 for 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 ofresources, 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 clearlystating expectations, it is no substitute for regular communication between clients and vendors. This starts from thevery beginning of a project. Therefore, when a localization kit is ready create a booklet and hand it out during thekick-off meeting. Also, possibly create a small website for kit to allow online access to project material, and addpost-mortem information about the unsolved issues and the issues solved and the workarounds.Contents of a localization kitToday, a software product consists of several types of objects that must be archived for re-releases, ports ofdifferent platforms, and to create specialized versions for OEM’s (Original Equipment Manufacturers), which can bepre-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 oncecompleted.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 projectto 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 are not.However, providing files is only the first step. Instructions for them are critical to the understanding of the client’sexpectations and the true scope of the project.To build a software application, all the resource files and code files are needed, which are then compiled into abinary or executable file which can be run on a computer. Therefore, a comprehensive localization kit has buildenvironments 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 translatableinformation, such as the menu text, dialog box options, and error messages, is stored in resource files. A softwareCopyright © 2005-2011 Luigi Muzii 6
  8. 8. Building a localization kitproduct which has been well-internationalized stores all translatable text in resource files, which makes thelocalization job relatively simple. However, in many cases, files containing translatable text are found all throughoutthe build environment.It is the localization engineer’s responsibility to locate and identify all the translatable files and prepare them fortranslation. Localization engineers should ensure that translators know exactly what they need to do, so they canget 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 kitshould 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 stuff to translate, in source language.For hardware projects, the localization team also needs the dimensions of the product labeling areas, a key for theproduct button and lever names, and information about any safety requirements. If possible, a prototype of theproduct is helpful for gaining contextual understanding.If any of the objects making a localization kit is lacking or is insufficiently detailed, the localization kit could provedifficult to use, and the time to answer questions and provide any missing information or resources will turn inunbudgeted - and then intolerable - costs.Project managementThe localization kit should be divided into sections specifically built for the team working on the project following awell-organized folder structure, even though future versions of common operating systems will have deeplyintegrated 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 teammembers to function also as a contract between the parties if necessary. The letter of assignment should carry allquotations grouped by component, the change management agreement, the project milestones, and thedevelopment cycle "freezing points".This should contain a statement of work, listing all expected services and deliverables, and all the relevant referencematerials.Statement of workThe purpose of a statement of work (SoW) is to detail the work requirements, i.e. "what is to be done", for theproject. A SoW will be the basis for potential offerers to compete for the contract and when it becomes contractualit shall be used as a standard for determining if the supplier meets the stated performance requirements. The SoWwill also support the localization project manager in outlining the required work effort through a WBS (WorkBreakdown Structure) diagram and establish a delivery schedule.Copyright © 2005-2011 Luigi Muzii 7
  9. 9. Building a localization kitThe SoW should include, but is not limited to, all of the following:  project scope; o product name; o project name or code; o overview of the product and the target audience; o description of the product’s basic architecture; o list of localization kit contents; o services required, tasks and deliverables; o languages; o project components; o word counts;  delivery requirements; o period of performance (the start and end date for the entire project);  delivery dates;  interim milestones by deliverable; o physical location where the work will be performed; o performance standards; o supplies and equipment that will be used; o delivery method;  e-mail;  CD/DVD (with specification of courier type if necessary);  FTP;  update cycle; o number of updates; o size of updates; o expected schedule for updates;  quality expectations (the acceptable quality for the product);  payment terms; o total amount of the purchase order; o overall amount computed for each job/task/deliverable; o payment rate; o non-disclosure agreement; o liability agreement;  contact information; o 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 resultinganalysis 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. Whenever possible, mappingshould provided for any components that can be leveraged from one another.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 thetranslation memories.These settings should also be used to produce statistics for progress reports and a graphic projection of deliverydates.Bill of materialsEach SoW should be marked with a version number for traceability of updates and accompanied with a detailed billof materials (BoM). This should include:  a list of the files to localize grouped by type;Copyright © 2005-2011 Luigi Muzii 8
  10. 10. Building a localization kit  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 Word File name File type Purpose Location Notes and instructions count default.asp Server-side Default page 30 root Line 37: the variable script for browsing strRedirect should not exceed (VBScript) inception 75 characters Line 271: do not localize the variable strLang content.asp Server-side Container 1,830 root Line 58: Spanish localizers: use script page different terminology for Spanish (VBScript) and Mexican markets style.css Style sheet Managing Style Line 10: change font from Times (CSS2) display of New Roman to SimSun for contents Simplified Chinese (2052), PMingLiu for Traditional Chinese (1028), MS Mincho for Japanese (1041), and Batang for Korean (1042) plain text Include file 10,000 IncludesEnMessages Text strings displayed on screen in message boxes to report an error.Reference materialThe project manager’s responsibilities include the arrangement of any reference materials for the project, whichshould 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.Copyright © 2005-2011 Luigi Muzii 9
  11. 11. Building a localization kit Example of bug fix report Bug fix report: < product name > GUI Italian Issue File Location Issue Comment Other Name solved main.rc Main Linguistic After a close review, it would be more suitable to menu change some of the items to plural as it sounds better in Italian: Contatto > Contatti, Fornitore > Fornitori, Preventivo > Preventivi, Cliente > Clienti, Strumento > Strumenti, Progetto > Progetti Example of a query sheet Query sheet: < project name > Terminology Italian Urgent (Y/N) Filename Page Term/Issue Context Target term Answer Example of progress report Word Words to Progress 2 3 Running Filename 1 Resources Productivity 4 Start date End date count translate % days rc1_en_olh.rtf 32,914 3,724 88.7% 6 333 1,9 10/3/2005 1/7/2005 1. 100-[(words translated)*100/(words to translate)] 2. people involved 3. (number or words per day)/(resources) 4. (words to translate)/[(resources)*(productivity)]SoftwareIn developing the localization kit, the localization project manager should identify elements that may be culturallydependent, and decide whether to generalize them for all cultures or isolate them for localization. Isolation isperformed by removing the cultural information to a resource file and replacing it with a routine, which looks up theappropriate information in the resource file. If isolation is required, the localization project manager will send thecode back to the software engineers with proper instructions for correction.The translation of software resources must come before that of on-line help and documentation to have thesoftware terminology be available to guarantee crosswise terminology consistency. Therefore, when assembling thereference material, the localization project manager, together with the client’s software experts, will also arrangethe 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 textis clear and concise, grammatically correct and free from slang or technical expressions that may lead tomistranslations. The localization project manager should also check for language and references consistency and fortranslation memory integrity and correctness.In addition to the converted software resources, the localization kit should further contain an executable version ofthe software (for reference purposes and to help translators get acquainted with the product), as well as the entirebuild 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 fortraditional and Internet software if necessary.When available, the results of pilot project(s) should be made accessible to localizers to allow them to find somespecific issues that may have been overlooked in the internationalization stage. A list of any knowninternationalization issues should also be provided.Copyright © 2005-2011 Luigi Muzii 10
  12. 12. Building a localization kitTraditional software"Traditional" is used here to mean desktop or handheld static software as opposite to Internet software. Atraditional 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 softwareA Web site or application is quite different from a "traditional" static software application, and can hardly belocalized in "safe mode", i.e. working on binaries, resource scripts, or string files only. In most cases localizers shouldbe able to access source files to replicate the site or the application, and possibly setup a test bed.Therefore, a web localization project manager’s first worry should be protecting the code from accidental changesand assemble a language pack. If the product has been internationalized correctly, all localizable text should havebeen extracted from code and a language pack should consist mainly of the string tables and the language-specificimage 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-sidescripting files with an <!-- # include file/virtual="relativepath/filename"--> statement. Each module ofthe 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 Accessfor .mdb files, and Macromedia ColdFusion for .cfm files).Documentation and on-line helpOnce the localized version of the software is edited, the localization engineers should re-import it into a CAT tool tocreate 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. Thestatement 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 ofall 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 Documentationcould 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 versionmust be provided in the User documentation folder for processing with translation tools. If a DTP version isrequired, 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 thenaming conventions a rule must be provided for fonts names to be consistent with the names given in the targetlocale.Copyright © 2005-2011 Luigi Muzii 11
  13. 13. Building a localization kitFinally, the User documentation folder of a localization kit should contain a bill of material in the form of aspreadsheet 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 helpfolder 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 guidespecifying all style conventions, typography, and naming conventions.The template files allow the vendor to identify any potential localization issues and correct them before localizationbegins by making the necessary changes to styles to accommodate language differences.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 for the naming rules, the guidelinesfor document setup if separate copies have to be created for each language/locale, information on the printer driverversion and the printer description file to be used, and the guidelines and instructions for text expansion. If anyspecial fonts are used, the localization guide will also detail the font requirements. Finally, the localization guide willprovide for instructions for DTP compilation, including the compiler version, and for help testing, including requiredplatforms, 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 aspreadsheet listing file names, types, and a brief explanation of each file’s purpose, as well as any other notes,including any special fonts required.GraphicsThe 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 bearranged to store non-editable files.When graphics is created using multi-layered image authoring systems text should be placed in specific discretelayers.For artwork available only in non-editable formats, all text should be extracted and a spreadsheet should be createdin 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 sortedby 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; o fonts; o color palette; o screen and print resolution;Copyright © 2005-2011 Luigi Muzii 12
  14. 14. Building a localization kit  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 dealwith "restricted" symbols must be provided together with any information on alternative forms. Excerpt of a graphics list from a bill of materials Text to be Word Notes and File name File type Purpose Location translated Count instructions intro.bmp BMP, 8-bit, Splash Press any 5 GraphicsFinalMain Use Arial 24 no screen at key to bold for text; compression program continue... text color start #FF9900 back_off.jpg JPEG, 25% Background GraphicsFinalMain Linked to from compression image for default.asp. welcome This is a very page of complex Internet image to site (back recreate. If it office) proves unsuitable for your locale, please fill the associated space with a blank image. scr01_en.gif Standard Screen shot GraphicsFinalScreenshots Each GIF, 256 of main screenshot of color menu the user interface must be reproduced after localization. Be sure to have a few valid entries in the database to produce a significant image. Please use a Windows XP, a Red Hat Fedora or a Mac OS X platform to take the screenshots.Copyright © 2005-2011 Luigi Muzii 13
  15. 15. Building a localization kit Excerpt of a graphics list from a bill of materials Text to be Word Notes and File name File type Purpose Location translated Count instructions workflow.gif Standard Flow chart See the 155 GraphicsFinalArtwork Linked to from GIF, 256 giving a text labels workflow.asp. color general in the The source for picture of source file this image is the workflow.psd production (see below) process made with The source for this image is workflow.psd (see below) made with the GIMP (the GNU Image Manipulation Program). workflow.xcf GIMP image Flow chart 155 GraphicsSourceArtwork Source file for giving a workflow.gif general (see above). picture of Localize the the text layer in production the file using process the GIMP (the GNU Image Manipulation Program) and then save it as GIF. The GIMP is a freely distributed piece of software for photo retouching, image composition and image authoring.MultimediaSince more and more localization projects now include an audio/video component, it is important to demonstrateboth technical capability and comprehensive studio talent.Multimedia embraces a vast range of "documents" that may have two or more of text, graphics, sound, video, andanimation; therefore, a very basic principle in making multimedia files states that digital localizable elements shouldbe 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 wasconstructed. In properly encoded MPEG video and AVI movies, audio and video streams can be extracted andseparated to be saved back after editing or localizing.In brief, 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;Copyright © 2005-2011 Luigi Muzii 14
  16. 16. Building a localization kit  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 theproject, so that the resulting files can be managed individually in a more comfortable way with the same code forboth the original and the target languages. Each element of a script should then be listed in the bill of materials withthe associated file name.Again, a print-out of all documents requiring translation should possibly be provided.Then, a spreadsheet should be created with all the available information for the multimedia files. This spreadsheetcould be stored in the Project documentation subfolder of the Documentation folder of the localization kit, andshould 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; o format of the original voiceover files; o 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, voice-over 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. Excerpt of a multimedia list from a bill of materials File Bits Sample Notes and File name Purpose Platform Location type Depth Rate instructions welcome.wav WAV - 8 bits 44 kHz PC MultimediaAudioMain Associated with Mono main menu. It is a welcome sound. intro.wma WMA Presentation 24 22 kHz Windows MultimediaAudioWeb Linked to from - of the Web bits default.asp. No Stereo application source file is available. The script is in intro_en.rtf. Please use Windows Media to recreate the audio file. sample.mpeg MPEG- Sample 16 bit 44 kHz Cross MultimediaVideoWeb Linked to from 1 video stereo platform training.asp. The script is in intro_en.rtf. If possible, for support reasons, please use Adobe Premiere, Ulead Video Studio or Pinnacle LiquidCopyright © 2005-2011 Luigi Muzii 15
  17. 17. Building a localization kit Excerpt of a multimedia list from a bill of materials File Bits Sample Notes and File name Purpose Platform Location type Depth Rate instructions Edition to recreate the audio file.For MPEG files, a fully standard-compliant version with time code and subtitling information could be extremelyuseful.CollateralsPeripheral documents are usually referred to as "collaterals". These are usually made of graphics file, sometimes ofDTP 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 possibly be provided.Then, a spreadsheet should be created with all the available information for collaterals. This spreadsheet could beadded to the specification worksheet stored in the Project documentation subfolder of the Documentation folderof 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; o fonts; o color palette; o 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, instructionsfor DTP compilation, including the compiler version, and special instructions on how to deal with legal, tax orfinancial issues must be provided.DeliveryAn overview of folder contents should be provided together with instructions for creating a language pack from thelocalized 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 informationmissing 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 labeled with:Copyright © 2005-2011 Luigi Muzii 16
  18. 18. Building a localization kit  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 minilocalization kit should be created with the critical objects stored on a separate disk labeled with the sameinformation of the main localization kit and an additional tag stating it is an addendum.Copyright © 2005-2011 Luigi Muzii 17
  19. 19. Building a localization kit Writing the localization guideThe localization guide should be created before the actual work on the project begins, together with the projectwork plan.The localization guide contains the instructions for localizing a product. The policies contained with localizationguide are product- or company-dependent.Although it may seem time-consuming to develop, a good guide can work well with many projects; therefore, inmost 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 localizationguide should be clear and precise enough to have the files repackaged so they can be properly put back in theproduct.The localization guide in the localization kit should accurately lists and clear all issues and closely track changes. Alllists should be kept updated to work as trusted and valid tracking tools. The localization guide should also beimmediately updated with answers to questions and issues raised. The localization guide should therefore providefor:  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 scheme for authoring a localization guide. A very brief - and not exhaustive - sample canbe in the appendix.IntroductionProvide an overview of the entire document: describe all data, functional and behavioral requirements. Describe thecontents of the kit.Project organizationList the major project roles and the actual people involved, possibly including an organization chart. An appropriateproject 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.Copyright © 2005-2011 Luigi Muzii 18
  20. 20. Building a localization kitProject issuesDescribe the overall project goals with an overview of the overall project plan stating cost estimates and a top-levelschedule for the project.Statement of scopeDefine the breadth and limitations of the work to be done, not how to do it. Give a description of the project andthe software with major functionalities and constraints. Place the software in a business or product line context andoutline the major strategic issues so that the reader can understand the "big picture". If possible, provide a usagescenario for the software with a description of the software interface(s) to the outside world and the control flowfor the system.Contents of the kitProvide instructions for pick-up. Explain how the kit is organized; provide instructions to unpack and install the kit.Resource requirementsProvide an overall description of all hardware, software, documentation, personnel, and data requirements with acontext-level model of the system architecture.Resource requirements should specifically detail:  hardware items;  interfacing equipment (IME);  special equipment;  operating systems;  computer setup (hardware, platform, path settings, memory);  specifications of any database back-end, should this apply, and the data required by the application to be extracted for the localized version to be built.Tools, techniques and methodologiesToolsA Tools folder should be created with a subfolder for each tool labeled following the name of the tool.Specify the programming language(s), scripts, compilers and tools used to develop the software, and provide a list ofany specific tools, techniques, and methodologies that are to be used when performing localization and testingactivities.TechniquesExplain the procedure for localizing each type of file and how to use any proprietary tools included in the kit. Specifywhether the deliverable of translation memory is required, and if so, in what format.Provide instructions on how to deal with error messages, composite strings, word order, gender, articles, plurals,and with text expansion.When the software can only be localized by translating string resource files out of context, include a description ofthe syntax of the string resource files and how to deal with control characters, and provide screen captures in thesource language to ease the interpretation of context-less strings.Provide instructions on how to deal with legal, tax or financial issues.MethodologiesList the specific work tasks to meet project requirements to permit the acquirer and offerer(s) to estimate theprobable cost and the offerer(s) to determine the levels of expertise, manpower, and other resources needed toaccomplish the task. If a Work Breakdown Structure (WBS) is being used in the project, organize tasks in accordancewith the WBS.Copyright © 2005-2011 Luigi Muzii 19
  21. 21. Building a localization kitStates specific duties of the vendor in such a way that the vendor knows what is required and completes all tasks tothe satisfaction of the contract.DeliverablesList and describe project deliverables. Provide enough explanations and details so that the reader will be able tounderstand what is being produced. Include a chart showing deliverables according to the project major milestones.RisksList and describe circumstances or events that are out of control of the project team and that could have an adverseimpact on the project if they occur, so that all project stakeholders can anticipate and manage them, therebyreducing the probability that they will occur.Risks should be listed with their probability of occurrence and negative impact. For each risk listed, identify activitiesto perform to eliminate or mitigate the risk.CommunicationsProject managers should communicate regularly to stakeholders, informing them of the current status of the projectand managing future expectations. If these key people are not kept well informed of the project progress, there is agreater likelihood of problems stemming from differing levels of expectations. In fact, in many cases where conflictsarise, it is not because of the actual problem, but because a customer or stakeholder has been taken by surprise.Establish a communication plan to determine communication needs of all people involved with the project or thatwill be affected by the project and provide consistent and timely information to all project stakeholders.Provide a project status report scheme for all project team members to fill in regularly.What follows is a suggested project status report template to be, possibly, combined with a progress report as thatin Reference material. Project status report template <Project Name> Status Report No. <X> <Date> Project Manager <Name> Project Scope A brief description of the scope of the project. Project Summary A brief statement of project performance not covered in the remainder of the report. Milestones scheduled for Milestone Baseline Date Target Date Achievement achievement since last report and performance against those Description of dd/mmm/yyyy dd/mmm/yyyy dd/mmm/yyyy milestones milestone Milestones scheduled for Previous Target Current Target achievement over the next Milestone Baseline Date Date Date reporting period and changes in those milestones with respect Description of dd/mmm/yyyy dd/mmm/yyyy dd/mmm/yyyy to the previous plan milestoneCopyright © 2005-2011 Luigi Muzii 20
  22. 22. Building a localization kit Project status report template <Project Name> Status Report No. <X> <Date> Impact of achievement/non- Milestone Impact achievement of milestones for the remaining period of the Description of affected milestone Briefly describe any changes to the project project schedule required as a result of the amended milestone(s). General Information Include any general comments that may support/enhance/add to the above sections. Budget Planned Actual Date Deficit/Surplus Expenditure Expenditure dd/mmm/yyyy Project risk management Risk Likelihood Seriousness Grade Change statement (as compared to previous reports) Brief description of major Low Low A Increase risks. Medium Medium B Decrease High High C New Issues Brief description of any business issues associated with the project that have arisen since the previous report and need to be addressed. Recommendations Brief statement(s) to consider and/or endorse.Quality assurance planDescribe the various quality assurance tasks that will be carried out for the project and indicate how they will besynchronized with project milestones. Reference any standards and guidelines that are expected to be used on theproject, and address how compliance with these standards and guidelines shall be determined. Enclose or referenceany relevant artifacts.Quality goals, control, tools and metricsOutline the quality expectations for the product and the quality considered acceptable for each deliverable.Describe the tasks associated with the creation of project deliverables to verify that deliverables are of acceptablequality and that they meet the completeness and correctness criteria established.List any quality-related tools that this project will utilize.Describe the product, project, and process metrics that are to be captured and monitored for the project. Providedescriptions of the various quality records that will be maintained during the project, including how and where eachtype of record will be stored and for how long.In a localization context, there are basically two types of metrics: production metrics and business metrics.Production metrics focus on measuring efficiency. Business metrics focus on measuring value.Any metrics requires as much data as possible, and, to be collected, data should be defined and tracked.Copyright © 2005-2011 Luigi Muzii 21
  23. 23. Building a localization kit List of sample metrics Balance Category Sample Metrics Business value  avail of the cost/benefit analysis created on project approval Cost  actual cost vs. budget (variance) for project, for phase, for activity, etc.  total labor costs vs. non labor (vs. budget)  total cost of employees vs. contract vs. consultant (vs. budget)  cost associated with building components for reuse  ideas for cost reductions implemented, and cost savings realized Customer satisfaction  availability of deliverables  defects of deliverables  reliability of deliverables  responsiveness of project team  competence of project team  courtesy of project team  communication  credibility of project team  reliability on commitments of project team  professionalism of project team  turnaround time required to respond to queries and problems  average time required to resolve issues  number of change requests satisfied within original project budget and duration Duration  actual duration vs. budget (variance) Effort  actual effort vs. budget (variance)  amount of project manager time vs. overall effort hours Productivity  effort hours per unit of work  work units produced per effort hour  effort hours reduced from standard project processes  effort hours saved through reuse of previous components  number of ideas for process improvement implemented  number of hours saved from process improvements Quality of  percentage of deliverables going through quality reviews deliverables  percentage of deliverable reviews resulting in acceptance the first time  number of defects discovered after initial acceptance  percentage of deliverables that comply 100% with organization standards  number of customer change requests  number of hours of rework to previously completed deliverables  number of best practices identified and applied on the project  number of risks that were successfully mitigatedCopyright © 2005-2011 Luigi Muzii 22
  24. 24. Building a localization kitTest plan and validation criteriaWhen working on a localization project, bug detection and diagnosis is pivotal while the lack of localizability testingduring the initial phase of software localization could be fatal, and even though testing will eventually be left tolocalization engineers only, all members in the localization team should be capable of building and running thelocalized application and find, when not remove, any errors.Therefore, the localization environment must contain any tools for finding the translations that have caused anybugs.Describe the approach to functional testing issues for validation with the types of tests to be conducted, including asmuch detail as possible. Specify the hardware and software resources, setup settings, and performancerequirements and the expected results from testing. Indicate responsibilities for bug fixing.Should a script suite be used for automated testing to reproduce expected usage of the product provide instructionson how to run each script.Further, it is essential that the functional flow of the software user interface is outlined, so that testers don’t need togo through all of the functionality for each segment.For the vendor to setup and run a project-specific testing platform, provide the following information:  names of platforms on which the product runs;  any special hardware or software required for setup and testing;  name of the compiler and version;  compilers;  test drivers;  test data generators;  test documentation, technical references;  size, type, and composition of data to support acceptance tests;  list of known bugs;  level of internationalization testing done;  instructions to build the product on a clean machine;  a list of platforms, viewers, browsers with which the localized software should be tested.Finally, to properly assess the avail of the tests performed, provide instructions to access the bug tracking database.Web localization issuesWeb localization presents a few specific issues requiring consideration.Since the localization of HTML documents is relatively easy, especially with translation tools that allow the "locking"of tags, instructions must be given to identify and access localizable content within scripts, which is not easilyparseable by mechanical means. Provide instructions to separate UI, content and code elements, and to identify thecode for back-end functionality and the code that governs the UI, since the back-end functionality of the siteproduces the items visible to the user and should be identical for all languages.Give code adaptation guidelines to accord to the new directory structure, charset, etc. Arrange strict namingconventions to avoid behavioral differences between Unix/Unix-like (case-sensitive) and Windows platforms, as wellas the Web server approach to extensions.Provide information for the site/application structural analysis as per:  platform;  operating system;  Internet server;  application server;  technologies.Provide instructions on how to deal with dynamic content, that is the part of the Web site/application frequentlyupdated or event-driven often stored in a database in different formats.Finally, provide instructions on how to deal with keywords, taxonomies, stop word lists and profanity filters.Copyright © 2005-2011 Luigi Muzii 23
  25. 25. Building a localization kitMac localization issuesA typical Mac OS application is not shipped as a single executable file. Applications are generally shipped as adirectory (bundle) in the system that contains, in a hierarchical organization, the application executable and theresources to support that code.Resource files specific to a particular language are grouped together in a subdirectory of the bundle directory. Thissubdirectory is named after the ISO language code followed by a .lproj extension.The bundle structure makes it easy to add localizations to an application, provided that all the necessary UIresources are stored in the Resources directory.The internal structure of bundles is quite similar. From the standpoint of localization, executables that haveassociated UI need to be bundled. Similarly, certain types of content cannot be packaged in the bundle structure.Each .lproj subdirectory in a bundle has the same set of files; all versions of a resource file must have the samename. If a resource doesn’t need to be localized at all, it should be stored in the bundle’s Resources directory, not inthe .lproj subdirectories. The .lproj should have only localizable resources.In general, the following types of files should be marked localizable:  InfoPlist.strings containing keys for the information property list that might need to be localized, and is associated with the Info.plist file;  Localizable.strings containing "key" = "value" pairs;  .nib containing UI layouts;  Localized.rsrc containing the localizable resources only.Linux localization issuesTechnically, localizing FOSS (Free/Open Source Software) is not different from localizing commercial software.The open source development process uses a user-driven, just-in-time approach, driven by a global developercommunity, and by demand for the product within this community; new features are implemented as a result ofrequests from the user base. In this perspective, software is released early and often, the process is open andtransparent and work is delegated as much as possible. Therefore, localization of open source software is anongoing process, and it is driven primarily by voluntary efforts, in response to constantly changing source code.GNU/Linux desktop is composed of layers of subsystems working on top of one another. Every layer has its ownlocale-dependent operations. Therefore, to enable a language completely, it is necessary to work on all layers. Thelayers, from the bottom up, are as follow: 1. The C Library; 2. The X Window, the graphical environment; 3. Toolkits, middle layer libraries to work with the low-level graphical environment libraries and provide GUI components; 4. Desktop environments.As specified in the "OpenI18N Globalization Specification", in most open source projects localization of softwaremessages is handled by the Gettext library, which is based around two file formats:  the Portable Object (PO) file format: a simple string table for storing translation units in the localization process;  the Machine Object (MO) file format: a binary representation of a string table —used by an application to retrieve translated strings at runtime..po filesThe translation framework most commonly used in FOSS is GNU gettext, which covers more than 90 percent ofGNU/Linux desktops.By default, the original software messages are not externalized to resource files, but stored in source code, therebyallowing the application to run in the default language without needing any resource files. The Gettext toolkit is thenused to extract strings marked for localization from source code.Message-storing files are in plain-text format and are designated with the extension .po; they are usually handed offto localizers for translation. Normally, a Unicode editor is needed as UTF-8 is now used as standard text encoding.Copyright © 2005-2011 Luigi Muzii 24
  26. 26. Building a localization kitThe original string in these files are represented by the keyword msgid and strings are kept between a pair of "". Thecorresponding translations are represented by the keyword msgstr with translated strings in between a pair of "".The general structure of a .po file is as follows: white-space # translator-comments #. automatic-comments #: reference... #, flag... msgid "untranslated-string" msgstr "translated-string" #: reference... #, flag... msgid "untranslated-string" msgstr "translated-string"Comments begin with a #. Where the character # is followed by some other special character such as . and ;,comments are inserted automatically during the extraction process.Gettext tools first extract localizable strings from source code into a PO string table. Next, the newly extracted POstring table is merged with an existing PO string table containing translations. In addition, new entries are matchedagainst entries of a PO Compendium —a string table acting as a translation memory, holding translations combinedfrom multiple .po files. Translators then translate and review changes in the updated PO string table before the .pofile is converted to mo for use at runtime.In the PO format, the source string (msgid) is used as the primary identifier. This is different from other commonresource formats such as Java Resource Bundles and .NET Resources, which use some sort of logical key to map tothe actual source string. Therefore, several projects do not rely on the Gettext library, and use custom resourceformats or rely on the platform support provided by Java.CVS’sDevelopment could go in parallel with translation, and message-storing files could continuously be updated withnew strings. To have new strings merged seamlessly with the same .po files as those the translators are workingCVS’s (Concurrent Versions System) are used. A CVS is a repository where all source code, the documentation and allthe other program-related material is stored and maintained, with a version control system for ASCII files whichmaybe changed by multiple users across the network. A CVS is kept online: the files can usually be downloadedfreely, but only a few authorized people can commit the changes back.CVS’s organize files in a tree structure, with a root, branches and sub-branches down to the desired level of nesting.The root is the place where the development of next major release is being carried out. The maintenance and bug-fixes of older versions are carried out on the branches from the root where the regular updates are being carried outin parallel.A sample CVS structure is depicted in the figure below.When using a CVS localizers must have their local clients corresponding to the CVS server. The CVS server mirrorsthe source tree on the remote machine and the local clients allow localizers to merge their work back to the remotesource tree system as and when required.Copyright © 2005-2011 Luigi Muzii 25
  27. 27. Building a localization kitWhen using a CVS strict and accurate guidelines must be written and maintained, starting from the folders wherethe .po files are stored and the CVS account for the localizers to finish with the tools to use and the rules forchecking and committing a translation.Hand-held software localization issuesEven though software for hand-held devices is not merely a scaled-down version, localization is similar to that forother devices and problems mostly come from their small screens.Smaller screens impose many limitations and constraints in software design, screen layout, translation style, use oficons, etc., and to provide users with enough information this must be brief and to the point. Therefore, the userinterface usually contains strings that in many situations cannot be rephrased for translation.Operating systems for hand-held devices all have Unicode support facilitating software localization.The rules for internationalization are roughly the same as for "traditional" software: localizable strings are isolatedand stored in separate resources.Java is ideal for hand-held devices because Java files can be very small, and Java offers excellent localization support.WML (Wireless Markup Language) is used for WAP-based services while XHTML and XML are extensively used forcontent development. Problems arise when dealing with platform-specific development languages and file formats.Palm OSOverlays are used to localize Palm OS resource databases. Localization overlays provide a way of localizing asoftware module without requiring a recompile or modification of the software. Each overlay database is a separateresource database that provides an appropriately localized set of resources for a single software module (the .prcfile, or base database) and a single target locale.Smaller screen size invites text-truncation and dialog-resizing problems. Unfortunately, taking screenshots from theactual device can prove very hard, and emulators are used for development and testing.A localizable Palm OS application (.prc file) is created from a base .prc that is not locale-specific, which is thencombined with an "overlay" .prc containing locale-specific information. Therefore, to make a .prc file localizable, itmust be split into multiple, separate .prc files: one that is not locale-specific and several locale-specific .prc’s foreach desired locale.The application resources must be organized into multiple .xrd files containing locale-specific resources such asforms. Each .xrd file must then be compiled (using PalmRC) into .trc files, which will then be linked (usingPRCMerge) to create the .prc files.Alternatively, a non-localized .prc and localized .prc files can be created from a single .xrd file where resourcesthat pertain to a specific locale are uniquely identified. In this case the .xrd file must be filtered to create multiple,separate .trc files (a non-localized .trc and one or more overlay .trc files).The source code for resources is stored in a platform-independent .xrd (XML Resource Description) file. The PalmOS Resource Editor can be used to edit XML tags directly or through a graphical form tool, which allows for draggingand dropping user interface controls from a catalog of user interface elements.Testing can be done with the actual hand-held device or with an emulator that comes with the relevant softwaredevelopment kit. Unfortunately, emulators are run on larger monitors and may not show the actual screen that willdisplayed by the hand-held device; also icons and other indicators (e.g. the battery indicator) may not be shownproperly on emulators. Also, some tests cannot be run with emulators, such as those for the parts of an applicationinvolving accessories and external hardware (e.g. storage cards, memory cards, external keyboards etc.) or third-party software and plug-ins.EPOC/SymbianThe Symbian operating system is designed specifically for mobile, ROM-based and is widely used for Nokia, Sony,and Ericsson mobile devices. The original name for the Symbian platform was EPOC. Starting from version 6.0, theplatform is Unicode and several important components, such as locale tables and fonts, are already in the system.Resource files are developed as text files written in a Symbian-specific resource language and are defined with theextension .rss. These files are then compiled into a binary file format that can be loaded and read by programs.Resource files can be localized without recompiling the main program.Resource source files include resource header (.rh) files defining the information required by the applicationlauncher or system shell such as the application’s caption, an optional short version of the caption, the name of theCopyright © 2005-2011 Luigi Muzii 26
  28. 28. Building a localization kiticon file, optional information about the views, for view-based applications, including view-specific captions andicons.Localizable strings should not be defined within a resource file, but in separate files with the extension .rlscontaining new-line separated entries. Each entry contains the keyword rls_string, a symbolic identifier, and thestring itself.For ease of localization, all user interface text is usually separated out in to a separate header file (by conventionwith a .loc extension) that is included into the main resource file. These .loc files are then sent out for translation.Copyright © 2005-2011 Luigi Muzii 27