|
|
Resource Localization Manager User's GuideVersion 1.7205/03/94 09:51 AMCopyright � 1992-1994 Microsoft Corporation
Table of ContentsTable of Contents 2Introduction 3Usage: 4Languages IDs 6Localization Process 8One-Shot Process 8Parallel Process 9Project Creation 9Maintaining the Master Project 9Maintaining Each Locale Project 9Data Files and Formats 10Master Project Files (MPJ) 10Project Files (PRJ) 10Master Token Files (MTK) 11Language Token Files (TOK) 12Resource Description Files (RDF) 13
IntroductionIn the past, localization of a software product required the localizer to edit strings and controls embedded in source code and then rebuild the product in order to test the localized version. Such a process requires at least a rudimentary knowledge of computer programming and is often prone to human error. The Resource Localization Manager (hereafter referred to as RLMan) was designed to automate localization of products that make use of the Windows resource model by allowing the localizer to extract localizable resources directly from the applications that use them, modify the resources, and use the modified resources to create localized versions of the original applications. All this can be achieved without rebuilding the product and with minimal knowledge of computer operations.RLMan was designed with several goals in mind. Some of these goals were:* Allow the product to be localized without re-compilation.* Allow localization to proceed concurrent with development (provide update capability).* Allow localizers to share glossaries of common terms among applications.The localization model followed by the RLMan is very simple. Localizable resources are extracted from a source resource file and put into special text file called a token file. Each localizable resource may generate one or more tokens. Each token is contained on a single line of text and consists of a unique identifier followed by the localizable data associated with that particular resource. These tokens can then be localized by using a standard text editor.The localized tokens are then used in conjunction with the source resource file to generate a new localized resource file. The term "resource file" in this document means "any Windows executable format file (.EXE, .DLL, .CPL, etc.) or .RES file". The target resource file will contain exactly the same resources as the source resource file, the only difference is that the data will be localized.This model has been expanded a little to allow for update tracking. When localization is done in conjunction with development a target resource file may change after the localizer has tokenized the file and begun translation. Update tracking allows the localizer to update the localized token file without losing any work that might have been done. Any resources that may have changed since the most recent update are marked "dirty" and the change is tracked in the token file so the localizer may see exactly what changed and exactly how it changed.To allow for update tracking, the source resource file is used to generate a "master token file" which tracks changes. The master token file is then used to update any number of "language token files" (one for each target language). These language token files are then localized and used to generate the target resource files.
Usage:Any file name can include a UNC (Unified Naming Convention) share name or drive letter, and a directory path.The syntax of the 'RLMan' command is as follows:rlman [-c RDFile] [ -p CodePage ] [ -f ResType ] [-{n|o} PriLang SubLang] [-w] -{e|t|m|l|r|a} files-e InputExeFile OutputResFileExtract localizable resources from the resource file (.exe, .dll, .cpl, .etc.) InputExeFile and create a Win32 resource file OutputResFile. This output file can then be used, for example, by the dialog box editor or the bit map editors that come with the SDK.-t InputResOrExeFile OuputTokenFileThis option will extract the localizable resources from the executable or resource format file InputResOrExeFile and create a project token file OuputTokenFile. Using this option will circumvent the history-keeping mechanism of RLMan. It is made available for those times when the user wants to simply see what localizable resources are in the input file or when the history mechanism is not needed. Using the -o option and the -p option with the -t option will allow one to extract and tokenize resources of a specific language. The resulting token file will contain only those resources that have the specified locale and the text will be in the given code page.-m MasterProjectFile [ InputResOrExeFile MasterTokenFile ]When the history mechanism is wanted, the first step when creating a new master project or updating an existing master project is to use this option. If the MasterProjectFile does not exist, the optional InputResOrExeFile and MasterTokenFile arguments must be provided. These last two arguments will be ignored if the MasterProjectFile exists.-l LanguageProjectFile [ MasterProjectFile LanguageTokenFile ]This option is used, when the history mechanism is wanted, to create a new localization project or to update an existing project. If the LanguageProjectFile does not exist, the optional MasterProjectFile (the one created via the -m option) and LanguageTokenFile arguments must be provided. These last two arguments will be ignored if the LanguageProjectFile exists.-r InputResOrExeFile LanguageTokenFile_or_ResFile OutputResOrExeFile This option is used to create a localized version of the InputResOrExeFile. The resources in that InputResOrExeFile will be replaced with the localized resources in LanguageTokenFile_or_ResFile. OutputResOrExeFile is the localized version. . If the LanguageTokenFile_or_ResFile is a Token file, use the -o option to specifiy what the old language to be replaced is and use the -n option to specifiy what the new language is.-a InputResOrExeFile LanguageTokenFile_or_ResFile OutputResOrExeFile This option is used to create a localized version of the InputResOrExeFile. The resources in the resulting OutputResOrExeFile will include the original resources from InputResOrExeFile plus the localized resources in LanguageTokenFile_or_ResFile. If the LanguageTokenFile_or_ResFile is a Token file, use the -n option to specifiy what the new language is.-n PriLang SubLangSpecifies what the language the tokens in the token file are in and consequently what language the new resources are in. Used when setting up a new Language Project (-l) and with the -r and -a options. Can also be used with the -m option when the resources in the original resource file are not in U.S. English. PriLang SubLang are decimal values from the list of allowed values in the SDK.-o PriLangID SubIDSpecifies what the language the resources being replaced in, or extracted from, the source resource file are in.Used with the -r and -a options when the resources being replaced, or added to, in the original resource file are not in U.S. English. PriLang SubLang are decimal values from the list of allowed values in the SDK. For example, if the U.S. English resources had been replaced with German resources and now you wanted to add French resources to that German file, use the -o option (with arguments 7 1) to indicate that the original resources are in German not U.S English together with the -a option. Or, if you had created a file with U.S. English plus German resources in it, and now you wanted to replace the German resources with French (thus making a U.S English plus French file), you would use the -r option with the -o option (with arguments 7 1) and the -n option ( with arguments 12 1) to indicate that the old German resources are to be replaced with the new ones in the given French token file.Used with the -t option, this identifies the language of the resources that are to be tokenized. You should also use the -p option to specifiy the code page the text in the token file is to be written in.-c RDFileUse custom resources defined in the resource description file RDFile.-p CodePageThe default code page used in converting between the Unicode resources and the text in the token files is the Windows ANSI code page. To change the code page, use this option and use the IBM code page number as the CodePage argument. For example; -p 932.-f ResourceTypeBy default, all localizable resources are extracted. To extract a single resource type, use this option with ResourceType set to the resource type's numeric value (1-16 for Windows resources).-wPrint warnings about unknown custom resource types (-c option not given or resource type is not in the RDFFile), and about resources that are not tokenized because their language is not the language requested (-o option, or US English by default). It will also warn of any zero-length resources found.
Languages IDsPrimary Language ID's
Sub language IDs.
Neutral0x00Neutral0x00
Albanian0x1cDefault0x01
Arabic0x01System Default0x02
Bahasa0x21Arabic (Saudia Arabia)0x04
Bulgarian0x02Arabic (Iraq)0x08
Byelorussian0x23Arabic (Egypt)0x0C
Catalan 0x03Arabic (Libya)0x10
Chinese0x04Arabic (Algeria)0x14
Czech0x05Arabic (Morocco)0x18
Danish0x06Arabic (Tuinisa)0x1C
Dutch0x13Arabic (Oman)0x20
English 0x09Arabic (Yemen)0x24
Estonian0x25Arabic (Syria)0x28
Farsi0x29Arabic (Jordan)0x2C
Finnish0x0bArabic (Lebanon)0x30
French0x0cArabic (Kuwait)0x34
German0x07Arabic (U.A.E.)0x38
Greek0x08Arabic (Bahrain)0x3C
Hebrew0x0dArabic (Qatar)0x40
Hungarian0x0eChinese (Traditional)0x01
Icelandic0x0fChinese (Simplified)0x02
Italian 0x10Chinese (Taiwan)0x04
Japanese0x11Chinese (PRC)0x08
Kampuchean0x2cChinese (Hong Kong)0x0C
Korean0x12Chinese (Singapore)0x10
Laotian0x2bDutch0x01
Latvian0x26Dutch (Belgian) 0x02
Lithuanian0x27English (US)0x01
Maori0x28English (UK)0x02
Norwegian0x14English (Australian)0x03
Polish0x15English (Canadian)0x04
Portuguese0x16English (New Zealand)0x05
Rhaeto Roman0x17English (Ireland)0x06
Romanian0x18French0x01
Russian0x19French (Belgian)0x02
Serbo Croatian0x1aFrench (Canadian)0x03
Slovak0x1bFrench (Swiss)0x04
Spanish 0x0aGerman0x01
Swedish 0x1dGerman (Swiss)0x02
Thai0x1eGerman (Austrian)0x03
Turkish 0x1fHebrew (Israel)0x04
Ukrainian0x22Italian0x01
Urdu0x20Italian (Swiss)0x02
Vietnamese0x2aJapanese (Japan)0x04
Sub language IDs. (cont.)
Korean (Korea)0x04
Norwegian (Bokmal)0x01
Norwegian (Nynorsk)0x02
Portuguese (Brazilian)0x01
Portuguese0x02
Serbo Croatian (Latin)0x01
Serbo Croatian (Cyrillic)0x02
Spanish (Traditional Sort)0x01
Spanish (Mexican)0x02
Spanish (Modern Sort)0x03
Thai (Thailand)0x04
Localization ProcessThere are two basic types of localization. The first is when a product is correctly enabled for localization ("globalized"), the product development is finished, and all that is needed is to modify the localizable resources. We'll call this the "one-shot process". The second is when a product is being localized in parallel with the development process and the localization work is to be preserved across new builds of the original (typically English) file. We'll call this the "parallel process". It is done in parallel with product development so the localized versions are ready as soon as possible after the domestic version is.The next two sections describe, in a step-by-step list, the procedure to use for the two processes. In the sample command lines, the executable is called "prog.exe". A GUI version of RLMan is being developed. That version will make the various steps invisible to the user and will incorporate an editor that hides the token ID part of the lines in the token file.One-Shot ProcessTo simplify the file names on the command line, change directories to the place where the localized files are to be kept. Leave the source executable (typically the English version) in some other directory * anywhere on the network or on the local machine.If you have a localized .RES file, simply skip to step 4 and use the .RES file in place of the .TOK file name shown in that step�s example.1. Create the project token file "prog.tok".
rlman -t prog.exe prog.tok2. Translate the text in the "prog.tok" file with your favorite text editor. Assume German in this example.3. If dialog boxes are to be resized, create the file "tmpprog.exe" which will contain the translated text.
rlman -n 7 1 -r prog.exe prog.tok tmpprog.exeCreate the .RES file, in German, needed by the dialog editor in the SDK.
rlman -e tmpprog.exe prog.resResize the dialog boxes as appropriate to account for the different lengths of the translated text.
dlgedit prog.resUpdate the project token file with the revised dialog box coordinates and sizes.
rlman -t prog.res prog.tok4. Create the final, localized, executable.
rlman -n 7 1 -r prog.exe prog.tok newprog.exeThis completes the process. The German file "newprog.exe" is now ready to be tested.
Parallel ProcessThis process maintains the localization work from one build of the source executable (typically the English version) to the next. With this version of RLMan there is one caveat * if the developers change the ID number of a localizable item, the previous translation will be lost. This is being addressed and a solution will be available in a future release of RLMan. New items can be added or old ones deleted but an item with a changed ID will show up as a new item.Project Creation1. Create a directory for the master files and a separate directory for the project files. These directories may be anywhere on the net. The master project directory may contain any number of master projects, one need not create a new directory for each project as long as the base name for each master project in unique. There should be a separate directory for each localized version of the executable file. Typically this means one directory for each language.2. Move to the master directory.3. Copy the source executable to the master directory.4. Create the master project file and the master token file.
rlman -m prog.mpj prog.exe prog.mtk5. Move to the project directory (for German in this example).6. Create the project file and the project token file.
rlman -n 7 1 -l prog.prj prog.mpj prog.tok7. Steps 5 and 6 need to be repeated for each project directory (language). The resulting prog.tok files can then be translated to the appropriate language.Maintaining the Master Project1. Copy the newly built source executable to the master directory.2. Move to the master directory, then update the master project file and the master token file.
rlman -m prog.mpjMaintaining Each Locale Project1. Follow steps 2 and 3 of the "one-shot process" (previous page) as often as desired until the resources are localized satisfactorily.2. Every time the master project is been updated (step 2 in the "Maintaining the Master Project" section), update the project file and project token file.
rlman -l prog.prjRepeat step 1 as needed to catch new or changed resource items.
Data Files and FormatsRLMan uses a variety of special file types. All of the file formats described below are a special form of text file. Each file is human-readable and can be edited with any standard text file editor (such as Notepad).As a general rule, all text in these files follows the C escape convention when dealing with non-displayable characters. This convention uses escape characters to represent non-displayable characters. For example, \n is newline and \t is tab.Master Project Files (MPJ)Master project files consist of four lines of text:* The first line contains the path to the source resource file. This may be either a .RES file, or an .EXE format file.* The second line contains the path to the master token file (MTK).* The third line contains zero, one or more paths to resource description files (RDFs) separated by spaces.* The fourth line contains a date stamp indicating the date of the source resource file as of the last update.* The fifth line contains a date stamp indicating the date of the master token file as of the last update of the master project.* The sixth line contains the Language ID of the resources in the master token file (.MTK).Project Files (PRJ)Project files consist of five lines of text:* The first line contains the path to the master project file (MPJ).* The second line contains the path to the language token file (TOK).* The third line contains the path to the target resource file. This may be either a .RES file or (if the source resource in the MTK is an .EXE file) an .EXE format file.* The fourth line contains a date stamp indicating the date of the master token file (MTK) as of the last update of the project.* The fifth line may be left blank or it may contain the path to a glossary file. (Not used in this release.)* The sixth line contains the code page used when reading/writing the project token file. A zero (0) means the system's Windows ANSI code page. A one (1) means the syetem's default OEM code page.* The seventh line contains the Language ID of the resources in the language token file (.TOK).
Master Token Files (MTK)Master token files are text files which contain tokenized resources taken from some source resource file. Each token consists of a unique identifier followed by the text form of the resource data. Tokens are delimited by end-of-line characters.Master token files are used for update tracking. They contain no localized resource data and should not be changed except by RLMan.An example of what one token might look like is shown below: [[5|255|1|32|5|"FOO"]]=Localizable string containing text in C format.The token ID is surrounded by double square brackets and divided into 6 fields delimited by the vertical pipe '|' symbol:* The first field indicates the type of the resource* The second field is the resource name in the case of an enumerated resource, or it is 65535 if the name is a label (string) in which case the label itself is stored in the sixth field.* The third field is the internal resource id number taken from the resource header.* The fourth field is made up of a combination of data taken from the resource header and generated by the tools. This value is used in conjunction with the other values in the token ID to uniquely identify the resource.* The fifth field is a status field used by the update tools to determine the status of the current token.* The sixth field contains the name of the resource if the resource is identified by a label. Otherwise it contains a null string.A token ID is followed by an equal sign which is in turn followed by the resource data. The data extends from after the equal sign to the end of the line (exclusive). Non printing characters (such as new-line and control characters) are represented using C escape sequences. Two of the most common are \n for new-line and \t for tab. Some characters are shown in the form '\nnn' where nnn is the decimal value of that character.A token's status field is made up of combinations (bitwise OR'ing) of three basic flags:* CHANGED 4 indicates that the token has changed since the last update* READONLY 2 indicates that the token should not be localized.* NEW 1 used in conjunction with the CHANGED flag to indicate that this is the new version of the token.For example, if a token has changed during an update, the current text would be stored in a token with a status of CHANGED+NEW (4 + 1) = 5. The previous text is also stored in the token file using the same token ID but the status field would contain a 4 (CHANGED). This way both the current and the previous text are retained.
Language Token Files (TOK)Language token files are similar to master token files; the only difference being the meaning of the status fields found in the token identifiers.Language token files are used during localization. They contain localized resource data.A token's status field is made up by combinations of four flags:* TRANSLATED 4 indicates that the token contains text that should be put in the target resource. If a token is not marked as TRANSLATED then it contains unlocalized text from the master token file which is maintained for update tracking purposes.* READONLY 2 indicates that the token should not be localized.* NEW 1 used only for tokens that are not marked with the TRANSLATED flag to indicate that this is the new version of the unlocalized token.* DIRTY 1 used only for tokens that are marked with the TRANSLATED flag to indicate that the token is in need of attention (either the original translation has changed or the token has never been localized).For example, a clean, localized token is marked only with the TRANSLATED flag and therefore has a status value of 4.As in the Master token files, non printing characters (such as new-line and control characters) are represented (and entered by the localizer) using C escape sequences. Two of the most common are \n for new-line and \t for tab. Some characters are shown or entered in the form '\nnn' where nnn is the decimal value of that character. The localizer may enter any character it's '\nnn' form.
Resource Description Files (RDF)Custom resources are described in resource description files (RDFs) using c-like structure definitions. Each definition is identified with a specific resource type and the definition is applied to every resource of that given type.An identifier is declared by the following syntax:<type>Types are numbers or quoted names unless they are normal windows types in which case the standard Windows type name may be used in place of a number or name. (CURSOR, BITMAP, ICON, MENU, DIALOG, STRING, FONTDIR, FONT, ACCELERATORS, RCDATA, ERRTABLE, GROUP_CURSOR, GROUP_ICON, NAMETABLE, and VERSION).A structure definition follows normal 'C' syntax with the following limitations and differences:* Each definition must be fully enclosed in braces { }.* The standard 'C' types: char (single-byte OEM characters), int, float, long, short, unsigned, and near and far pointers are accepted. Additionaly, the types wchar (Unicode character) and tchar (Unicode in the NT version, OEM otherwise) are accepted. (Labels and macros are not legal.)* Nested structures, arrays and arrays of structures are legal. All arrays must have a fixed count except for strings which are described below. int[10] is legal int[] is not.* Null terminated strings (sz's) are the only variable length structures allowed. They are represented as an array of characters with no length: char[]* Fixed length strings are represented as arrays of characters with a fixed length: char[10]* Comments may be included in the file using standard c comment delimiters (/* */ and //) or by placing them after the pound symbol #.* Localizable types (types that need to be placed in token files) are indicated by all caps. Hence INT would generate a token while int would not.
The following is a sample RDF file:# This is a sample Resource Description File<"type">{ int, // no token will be generated for this integer CHAR // this single-byte character will be placed in a token}<RCDATA>{ WCHAR[] // a null terminated Unicode string that requires a token wchar[] // no token will be generated for this Unicode string}<1000>{ TCHAR[], // a null terminated Unicode or OEM string that requires // a token (Unicode if running NT version, else OEM). { int, FLOAT, // localizable floating point value far *, CHAR[20] // localizable 20 character single-byte string }[3], // an array of three structures (NOT IMPLEMENTED YET) int}END // Optional Throughout this document, the term localization refers to the process of preparing a product for an international market. This process involves (among other things) translating text and resizing controls such as dialogs and buttons. A person performing localization is referred to as a localizer. This document refers to a resource file as being any file that contains Windows resources. This can be a .EXE file (or a .DLL, a .CPL, etc.), as well as a .RES file. RLMan can use any of these files as resource files.The Resource Localization Manager Page 14
|
