windows-nt/Source/XPSP1/NT/sdktools/restools/rltools/doc/rlman.txt

Resource Localization Manager User's Guide
Version 1.72
05/03/94 09:51 AM
Copyright © 1992-1994 Microsoft Corporation


Table of Contents
Table of Contents	2
Introduction	3
Usage:	4
Languages IDs	6
Localization Process	8
One-Shot Process	8
Parallel Process	9
Project Creation	9
Maintaining the Master Project	9
Maintaining Each Locale Project	9
Data Files and Formats	10
Master Project Files (MPJ)	10
Project Files (PRJ)	10
Master Token Files (MTK)	11
Language Token Files (TOK)	12
Resource Description Files (RDF)	13



Introduction
In 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  OutputResFile
Extract 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  OuputTokenFile
This 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  SubLang
Specifies 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  SubID
Specifies 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  RDFile
Use custom resources defined in the resource description file RDFile.
-p  CodePage
The 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  ResourceType
By 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).
-w
Print 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 IDs
Primary Language ID's

Sub language IDs.


Neutral
0x00
Neutral
0x00

Albanian
0x1c
Default
0x01

Arabic
0x01
System Default
0x02

Bahasa
0x21
Arabic (Saudia Arabia)
0x04

Bulgarian
0x02
Arabic (Iraq)
0x08

Byelorussian
0x23
Arabic (Egypt)
0x0C

Catalan 
0x03
Arabic (Libya)
0x10

Chinese
0x04
Arabic (Algeria)
0x14

Czech
0x05
Arabic (Morocco)
0x18

Danish
0x06
Arabic (Tuinisa)
0x1C

Dutch
0x13
Arabic (Oman)
0x20

English 
0x09
Arabic (Yemen)
0x24

Estonian
0x25
Arabic (Syria)
0x28

Farsi
0x29
Arabic (Jordan)
0x2C

Finnish
0x0b
Arabic (Lebanon)
0x30

French
0x0c
Arabic (Kuwait)
0x34

German
0x07
Arabic (U.A.E.)
0x38

Greek
0x08
Arabic (Bahrain)
0x3C

Hebrew
0x0d
Arabic (Qatar)
0x40

Hungarian
0x0e
Chinese (Traditional)
0x01

Icelandic
0x0f
Chinese (Simplified)
0x02

Italian 
0x10
Chinese (Taiwan)
0x04

Japanese
0x11
Chinese (PRC)
0x08

Kampuchean
0x2c
Chinese (Hong Kong)
0x0C

Korean
0x12
Chinese (Singapore)
0x10

Laotian
0x2b
Dutch
0x01

Latvian
0x26
Dutch (Belgian) 
0x02

Lithuanian
0x27
English (US)
0x01

Maori
0x28
English (UK)
0x02

Norwegian
0x14
English (Australian)
0x03

Polish
0x15
English (Canadian)
0x04

Portuguese
0x16
English (New Zealand)
0x05

Rhaeto Roman
0x17
English (Ireland)
0x06

Romanian
0x18
French
0x01

Russian
0x19
French (Belgian)
0x02

Serbo Croatian
0x1a
French (Canadian)
0x03

Slovak
0x1b
French (Swiss)
0x04

Spanish 
0x0a
German
0x01

Swedish 
0x1d
German (Swiss)
0x02

Thai
0x1e
German (Austrian)
0x03

Turkish 
0x1f
Hebrew (Israel)
0x04

Ukrainian
0x22
Italian
0x01

Urdu
0x20
Italian (Swiss)
0x02

Vietnamese
0x2a
Japanese (Japan)
0x04






Sub language IDs. (cont.)




Korean (Korea)
0x04



Norwegian (Bokmal)
0x01



Norwegian (Nynorsk)
0x02



Portuguese (Brazilian)
0x01



Portuguese
0x02



Serbo Croatian (Latin)
0x01



Serbo Croatian 
(Cyrillic)
0x02



Spanish (Traditional 
Sort)
0x01



Spanish (Mexican)
0x02



Spanish (Modern Sort)
0x03



Thai (Thailand)
0x04




Localization Process
There 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 Process
To 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.tok
2.	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.exe
Create the .RES file, in German, needed by the dialog editor in the SDK.

rlman -e tmpprog.exe  prog.res
Resize the dialog boxes as appropriate to account for the different lengths of the translated text.

dlgedit prog.res
Update the project token file with the revised dialog box coordinates and sizes.

rlman -t prog.res  prog.tok
4.	Create the final, localized, executable.

rlman -n 7 1 -r prog.exe  prog.tok  newprog.exe
This completes the process. The German file "newprog.exe" is now ready to be tested.


Parallel Process
This 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 Creation
1.	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.mtk
5.	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.tok
7.	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 Project
1.	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.mpj
Maintaining Each Locale Project
1.	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.prj
Repeat step 1 as needed to catch new or changed resource items.


Data Files and Formats
RLMan 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