This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document describes how Windows resources data, up to Windows 2000, should be coded when extracted to an XLIFF document. This document does not cover Windows XP resources. [Gerard: we should cover XP too]
This document is a Preliminary Working Draft of the committee. It is an OASIS draft document for review by OASIS members and other interested parties. Comments may be sent to xliff-comment@lists.oasis-open.org.
This document may be updated, replaced, or rendered obsolete by other documents at any time. It may also be discarded without further follow up. It is inappropriate to use this document as reference material other than "work in progress".
<file>
ElementACCELERATORS
ResourceANICURSOR
ResourceANIICON
ResourceBITMAP
ResourceCURSOR
ResourceDIALOG
and DIALOGEX
ResourcesDLGINCLUDE
ResourceDLGINIT
ResourceFONT
ResourceFONTDIR
ResourceGROUP_CURSOR
ResourceGROUP_ICON
ResourceHTML
ResourceICON
ResourceMANIFEST
ResourceMENU
, MENUEX
and POPUP
ResourcesMESSAGETABLE
ResourcePLUGPLAY
ResourceRCDATA
ResourceSTRINGTABLE
ResourceVERSIONINFO
ResourceVXD
ResourceWindows defines a number of resources used in the user interface. These are authored in RC and MC files and compiled into the executable files (DLL or EXE files). As different tools may provide different filters to extract such resources from RC, MC, EXE or DLL files it is important for interoperability that they represent the extracted data in identical manner in the XLIFF document.
The aim of this document is to describe a unique way to represent Windows resources in an XLIFF document. The scope is limited to resources before Windows XP [Should we include XP at this point?] (basically resources created from RC scripts).
To help reading the source code examples, each type of resource is in a distinct colored, the same in the RC script and the XLIFF representation:
In addition, text and parameters for the target language are indicated with the same color scheme as for the source language, but are underlined.
The XLIFF profile to represent extracted Windows resources should address the following requirements:
This section discusses the general considerations to take in account when extracting Windows resources.
[Need to specify exactly what are the rules for extracting: can we extract only partial data (some tools will care about only translating text). Could/should we have a way of flagging the difference?]
Some filters will extract only basic information, other will extract every data needed to re-create an RC file or a compiled resource.
The minimum data a tool should extract are text items and their corresponding
ID (for the resname
attribute).
An XLIFF document with complete Windows resources should have all the data necessary to display a dialog box, including its coordinates, styles, and so forth.
[General question: how do we handle VERSION, CHARACTERISTICS statement? They don't seem to be in the compiled file. Also what about the general resource style MOVABLE, PURE, etc.]
The identifier used for matching, leveraging, and other ID-related
functions is stored in the resname
attribute. The required attribute id
is an
identifier allowing extraction tools to merge back the data. Its value is
determined by the filter.
One of the difference between the resources in an RC script and a
compiled file is how the identifiers are represented: while they are often
defined as symbols in the scripts (i.e. IDD_ABOUTBOX
),
they are the actual corresponding numeric values in the compiled file.
The symbolic identifier brings some advantages as its name is usually meaningful and may sometimes offers useful context information to the localizer.
<group restype='dialog' resname='IDD_ABOUTBOX'>
<group restype='dialog' resname='#100'>
[So, what should be the rule? allow both to coexist?, force value, force symbol?]
Windows allow non-unique identifiers within a resource. An example of this
is the often used IDC_STATIC
(or -1) identifier used when for
controls not associated with any action (icons, labels, etc.).
First, the best approach is to have different identifiers for every single control. Windows does not enforce this, but nothing prevent the developers to implement their resources this way.
[Now, how to handle IDC_STATIC or
other duplicate IDs in winres?
group_resname + trans-unit_resname + restype (+ order if trans-unit_resname is
not unique) should be unique (?)]
[Warn about not creating pseudo-unique ID when extracting (with sequence counter for example)?]
[Need also to address cases where an ID exists in the compiled file, but not in the resource script: for example STRINGTABLE]
XLIFF provides two attributes to store Windows resources style and extended
style information: style
and exstyle
.
The values for styles and extended styles must be in the same form, a number, regardless whether the original format is an RC script or a compiled file. In other words, any combination of symbols should be converted to a single numeric value.
The notation for both the style
and the exstyle
attribute is always 0xhhhh
, where hhhh
is the
hexadecimal value of the given style or extended style.
Example of style for a dialog box:
STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU
Corresponding XLIFF representation:
style="0x80c800c0"
In an RC script, the language of Windows resources is generally set using the
LANGUAGE
statement. It appears anywhere between resource declarations,
defining sections of the file to be in a given language. Resources are not
necessarily grouped by language.
The language identifier of the resource is carried into the
XLIFF document through the standard mean of representing language in XLIFF: the
source-language
, target-language
and xml:lang
attributes.
The mapping between Windows language identifiers and RFC 3066 [RFC 3066] values is described in the Language Identifiers Mapping section.
Note that Windows resources may be multilingual, while a <file>
element in XLIFF is only bilingual.
[What is the recommended way of
dealing with text itself? Text in menu (The content of a menu item text in Windows may have indicators for a hot
key (the & sign), or text separators such as '\t
' and '\a
'.),
Text with escaped character, etc.]
The notation for a text of a given resource in it compiled form may be different from the same text in the source RC script. Some characters such as Line-Feed, Backslash, etc. are escaped in the RC file, while they are represented in raw form in the compiled file.
Because using text comparison is often used in localization-related tasks, it is important to use a unique representation of the text in XLIFF, regardless of the one used in the different original files.
[Also: how to treat text from messagetable entry (special escapes)?]
[We should say something about segmentation: whether allow it or not in the recommended representation.]
[How about a note about white spaces? default should be xml:space='preserve' (then we should add it at the top of the XLF file)]
[to do]
Character | Escaped Representation |
U+0007 (Bell) | \a [Conflict
\a=0x08 in menu? (that's \b normally)] |
U+0009 (Tab) | \t |
U+000A (Line-Feed) | \n |
U+000D (Carriage Return) | \r |
U+0022 (Double Quote) | "" |
U+005C (Backslash) | \\ |
Any other character with a code-point below U+0020 (Space) should be
represented in octal form: \ooo
, where ooo
is the
octal value of the code-point (padded with zeros to be always 3 digits long).
Null terminators are not represented.
In some case text content is composed of a binary data that can include
control characters and even null bytes. Such text is represented in XLIFF as a string
with any byte value below 0x20 (including any null byte) in octal form: \ooo
,
where ooo
is the octal value of the byte (padded with zeros to
be always 3 digits long). Null bytes are represented.
Windows resources use the same coordinate representation system as XLIFF: x
and y for the top-left corner position of the object, followed by cx and cy,
its width and height. Therefore, there is not need to do any conversion when
representing Windows resource coordinates in the XLIFF coord
attribute.
Example of coordinates for a control:
DEFPUSHBUTTON "OK", IDOK, 129,7,50,14
Corresponding XLIFF representation:
coord="129;7;50;14"
Windows uses two types of identifiers for resource names and types.
Since, in some cases, such string may need to be represented in an XLIFF
document, for instance as the value for a restype
attribute of a
control, its representation should be standardized.
Ordinal: Use #ddd
where ddd
is the decimal value for the
ordinal.
[Correct or should ordinals simply be the value? (discrepancy RC /exe: RC 128 = '128', Exe 128 = '#128')]
<file>
ElementIn an XLIFF document, Windows resources extracted from source or compiled
files are stored in a <file>
element with the datatype
set to winres
. [YS: Could we
use 'winres'
rather than 'win32 resource'?
winres is listed in
xliff
1.0 spec]
The different types of resources can be listed in any order in the XLIFF document, this order may be different from the order in which the resources are in the original file. The resources of a same type are not necessarily grouped together. [No grouping is required in RC scripts]
Within each resource (i.e. within each dialog box, each menu, each string
table, etc.) the <trans-unit>
element should be listed in the
same order as they are in the original file. This is important because the
closest way to come to a unique identifier for some items is to look at its
order within the resource it belongs to (for example: the IDC_STATIC
(-1) controls in a dialog box).
This section describe in detail how each type of resource should be mapped
to XLIFF constructs. The list is ordered alphabetically by resource type. Controls are addressed in the part discussing the DIALOG
and DIALOGEX
resources.
ACCELERATORS
Resource The ACCELERATOR
resource (value=9, RT_ACCELARATOR
) describes a set of binding between keys
and commands).
In XLIFF, this resource is represented as follow:
ACCELERATOR
resource is stored in its own <group>
with the restype
set to accelarator
.<trans-unit>
element.resname
attribute of the <trans-unit>
element.<source>
element. The flags and key value must be converted according the syntax
described below.Example of conversion from accelerator flag and key to text:
// Given fFlags that contains the flags
// and wAnsi the key or letter code
if ( fFlags & FCONTROL ) sText += "Ctrl+";
if ( fFlags & FALT ) sText += "Alt+";
if ( fFlags & FVIRTKEY )
{
if ( fFlags & FSHIFT ) sText += "Shift+";
if (( wAnsi >= 0x30 ) && ( wAnsi <= 0x39 ))
sText += (char)wAnsi;
else if (( wAnsi >= 0x41 ) && ( wAnsi <= 0x5A ))
sText += (char)wAnsi;
else
sText += GetVirtualKeyName(wAnsi);
}
else
{
if ( wAnsi < 32 ) sText += (char)(wAnsi+0x40);
else sText += (char)wAnsi;
}
// The GetVirtualKeyName()
function is any function that returns
// the virtual key name symbol (e.g. "VK_ESCAPE") for a given key.
[Double check this algorithm!]
Note that some key codes have several corresponding names: 0x15 can be
VK_KANA
, VK_HANGEUL
, or VK_HANGUL
. And
0x19 can be VK_HANJA
, or VK_KANJI
.
[Should we recommend to use a specific
name in those cases?]
In an RC script, some keys (such as Control + a) could be represented
either as ANSI text (i.e. "^a"
) or has virtual key. To
allow better interoperability, it is recommended to always use the "non-ANSI"
representation in XLIFF (here: Ctrl+a
). [Should
we recommend this?]
[What about the NOINVERT flag?]
Example of an ACCELERATORS
resource:
IDR_MAINFRAME ACCELERATORS
BEGIN
[to do]
END
Corresponding XLIFF representation:
<group restype='accelerator'> <trans-unit id='1' resname='ID1"> <source>Ctrl+C</source> </trans-unit> <trans-unit id='2' resname='IDCLEAR"> <source>K</source> </trans-unit> <trans-unit id='3' resname='IDELLIPSE"> <source>Alt+k</source> </trans-unit> <trans-unit id='3' resname='IDRECT"> <source>b</source> </trans-unit> [to do ....] </group>
ANICURSOR
Resource (value=21, RT_ANICURSOR
)
[Need information for this resource]
ANIICON
Resource(value=22, RT_ANIICON
)
[Need information for this resource]
BITMAP
ResourceThe BITMAP
resource (value=2, RT_BITMAP
)
describes a bitmap image.
In XLIFF, this resource is represented as follow:
<bin-unit>
element with its
mime-type
attribute set to image/bitmap
and its
restype
attribute set to bitmap
.
[Need to get the proper MIME value
for mime-type]resname
attribute of the
<bin-unit>
element.<bin-source>
element, inside
either:<external-file>
element with the href
attribute set to the path of the bitmap file.<internal-file>
element with the bitmap encoded in
Base64. Example of a BITMAP
resource:
IDR_MAINFRAME BITMAP MOVEABLE PURE "Res\\Toolbar.bmp"
First possible corresponding XLIFF representation:
<bin-unit id='1' resname='IDR_MAINFRAME' mime-type='image/bitmap' restype='bitmap'> <bin-source> <external-file href='Res\\Toolbar.bmp'/> </bin-unit> </bin-unit>
Second possible corresponding XLIFF representation:
<bin-unit id='1' resname='IDR_MAINFRAME' mime-type='image/bitmap' restype='bitmap'> <bin-source> <internal-file form='base64'> Qk02BAAAAAAAAHYAAAAoAAAAgAAAAA8AAAABAAQAAAAAAMADAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A /wD//wAA////AHd3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3 d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3dwAAAAAAAAd3d3RHd3d3d3d3 d3d3d3d3d3d3dERERER3AAAAAAAHd3d3d3AAd3d3d3AAAAAAAHdwAAAAAAB3d3AzAAAAdwMH d3dHdHdEd3d3d3d0RERERHcAAAT////0cHd3d3dwcHd3d3cLsAd3d3dw//////B3cAMzMzMz B3dwMwAAAHcDB3d3R3R0d0d3d3d3dP////RwODg09ERE9AAAAAAAAAcHd3d3C7AHd3d3cP// ///wd3DwMzMzMzB3cDMAAAB3Awd3d0d0dHdHd3d3d3TwAAD0cIODhP////QHd3d7u3cAB3d3 d3AHd3d3d3D/////8HdwvwMzMzMzB3AzAAAAAAMHd3d0RHR3R3dwAAAE////9HA4ODT0RPRE B3d3eIh3Bwd3d3cLAHd3d3dw//////B3cPvwMzMzMzBwMzMzMzMzB3d3d3R0RHd3cP//9PAA APRwg4OE///09AAAAAAAAAdwd3d3CwB3d3d3cP/////wd3C/vwAAAAAAcDMAAAAAMwd3d3d0 BHd3d3DwAAT////0cDg4NP//9EcHd3d3d3BwcHd3dwsAd3d3d3D/////8Hdw+/v7+/B3d3Aw d3d3dwMHd3d3dwd3d3dw///08A9ERHCDg4REREQHcAAAAAAHBwB3d3cLsAd3d3dw//////B3 cL+/v7+wd3dwMHd3d3cDB3d3d3AAd3d3cPAABP//T0dwODg4ODg4B3cP////8HBwd3cAcLsA d3d3cP/////wd3D78AAAAHd3cDB3d3d3Awd3d3dwcHd3d3D///T//0R3cIMAAAAAgwd3cPAA APAAB3dwsAcLsAd3d3D///8AAHd3AAd3d3dwAHAwd3d3dwMHd3d3AHAHd3dw8A8ERERHd3A4 B3d3cDgHd3D/////B3d3cLAHcLAHd3dw////Dwd3d3d3d3d3dwBwMHd3d3cAB3d3dwd3B3d3 cP//Dwd3d3dwg4CwCwODB3d3DwAADwd3d3C7AAuwB3d3cP///wB3d3d3d3dwd3BwcDB3d3d3 Bwd3d3cHdwd3d3D//wB3d3d3dwAAC7AAAHd3dw/////wd3d3C7u7AHd3d3AAAAAHd3d3d3d3 dwAHd3AAAAAAAAAHd3d3B3cHd3dwAAAHd3d3d3d3dwAAd3d3d3dwAAAAAHd3d3AAAAd3dw== </internal-file> </bin-unit> </bin-unit>
CURSOR
ResourceThe CURSOR
resource (value=1, RT_CURSOR
)
describes a cursor image.
In XLIFF, this resource is represented as follow:
<bin-unit>
element with its
mime-type
attribute set to image/cursor
. and its
restype
attribute set to cursor
.
[Need to get the proper MIME value
for mime-type]resname
attribute of the
<bin-unit>
element.<bin-source>
element, inside
either:<external-file>
element with the href
attribute set to the path of the bitmap file.<internal-file>
element with the bitmap encoded in
Base64. Example of a CURSOR
resource:
IDC_POINTER_COPY CURSOR DISCARDABLE "arrowcop.cur"
First possible corresponding XLIFF representation:
<bin-unit id='1' resname='IDC_POINTER_COPY' mime-type='image/cursor' restype='cursor'> <bin-source> <external-file href='arrowcop.cur'/> </bin-unit> </bin-unit>
Second possible corresponding XLIFF representation:
<bin-unit id='1' resname='IDC_POINTER_COPY' mime-type='image/cursor' restype='cursor'> <bin-source> <internal-file form='base64'> AAACAAEAICAAAAEAAQAwAQAAFgAAACgAAAAgAAAAQAAAAAEAAQAAAAAAgAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAMAAAADAAAABgAAAAYAAAAMAAAAjAAAANgAAAD4AAAA/wAAA P4AAAD8AAAA+CAAAPBQAADg2AAAwQQAAIDYAAAAUAAAACAAA//////////////////////// //////////////////////////////////////////////8////+H////h////w///+8P/// mH///4h///+A////gA///4Af//+AP///gH///4D3//+B4///g8H//4eA//+Pwf//n+P////3 //8=</internal-file> </bin-unit> </bin-unit>
DIALOG
and DIALOGEX
ResourcesThe DIALOG
and DIALOGEX
resources (value=5, RT_DIALOG
(for both)) define dialog boxes. The DIALOGEX
resource is the same as the
DIALOG
resource with the following additions:
EXSTYLE
statement for the dialog.
BEDIT
, IEDIT
and HEDIT
predefined system class names.There are two types of information for a dialog box: the one applying to the dialog box itself, and the one for each control within the dialog box.
The dialog box-level data are represented as follow:
DIALOG
or DIALOGEX
resource is stored in a <group>
element with the restype
attribute set to dialog
.
[Should we have a different type for
dialogex?]resname
attribute.numchildren
attribute value of the container group.
[YS:
Disagree. not needed, it's exe implementation specific. Nb of children can be
calculated easily from the group]coord
attribute.STYLE
statement)
is stored in the style
attribute.EXSTYLE
statement)
is stored in the exstyle
attribute (DIALOGEX
resources).FONT
statement) is
stored in the font
attribute.help-id
attribute (DIALOGEX
resources).menu
attribute.<trans-unit>
element is created (always). It can be used to override any attributes
necessary for the target language. The restype
attribute for this <trans-unit>
is set to caption
.<source>
element of this first <trans-unit>
. The resname
for the caption is the same as the one for the
dialog box.Example of a DIALOG
resource:
IDD_DIALOG1 DIALOG DISCARDABLE 0, 0, 235, 55 STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU MENU ID_MAIN CAPTION "Caption Text" FONT 8, "MS Sans Serif" BEGIN ... END
Corresponding XLIFF representation:
<group restype='dialog' resname='IDD_DIALOG1' font='MS Sans Serif;8' coord='0;0;235;55' style='0x80c800c0' menu='ID_MAIN'> <trans-unit id='0' restype='caption'> <source>Caption Text</source> </trans-unit> ... </group>
All parameter of the dialog box modified for the target language
are stored in the <target>
element of the first
<trans-unit>
of the group, as shown below:
<group restype='dialog' resname='IDD_DIALOG1' font='MS Sans Serif;8' coord='0;0;235;55' style='0x80c800c0' menu='ID_MAIN'> <trans-unit id='0' restype='caption'> <source xml:lang='en-us'>Caption Text</source> <target xml:lang='ja-jp' font='MS Mincho;10' coord='0;0;300;60' >キャプション テキスト</target> </trans-unit> ... </group>
Example of a DIALOGEX
resource:
IDD_DIALOG1 DIALOGEX 0, 0, 260, 159 STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU EXSTYLE WS_EX_CONTEXTHELP CAPTION "Caption Text" MENU IDR_MAIN FONT 8, "MS Sans Serif" BEGIN ... END
Corresponding XLIFF representation:
<group restype='dialog' resname='IDD_DIALOG1' font='MS Sans Serif;8;0;256' coord='0;0;260;159' style='0x80c800c0' exstyle='0x400' menu='ID_MAIN'> <trans-unit id='0' restype='caption'> <source>Caption Text</source> </trans-unit> ... </group>
The controls defined within a dialog box are also extractable. Note that some controls do not have translatable text (e.g. the EDITTEXT
control). They still may need to be extracted if the localization process is
expect to do any transformation such as resizing.
In an RC script, Windows controls can be written different ways, either as
a generic CONTROL
control, or as specific controls such as CTEXT
,
DEFPUSHBUTTON
, LISTBOX
, etc. The representation in
XLIFF is the same regardless of the original form in the RC script.
<trans-unit>
element. The order of the <trans-unit>
element in the
dialog box group must be the same as in the compiled resource or the script.resname
attribute of the <trans-unit>
.<source>
element of the <trans-unit>
.restype
attribute
of the <trans-unit>
. If the class is one of the standard
predefined Windows class the resname
is mapped as defined in
the Table 1. Otherwise the class name is
directly used as the resname
value (in lowercase).coord
attribute.style
attribute of the <trans-unit>
.
Note that any default style should also be stored.
[Should it?]exstyle
attribute of the <trans-unit>
.help-id
attribute of the <trans-unit>
.extradata
attribute of the <trans-unit>
, as a binary
string.[Add: Note about forcing attribute values in each <trans-unit> for any attribute already declared in the <group>? Reason: value of dialog box may be used by accident for control (inherited). Should we make all necessary attributes mandatory (for Winres)?]
Example of controls:
... ICON IDR_MAINFRAME,IDC_STATIC,11,17,20,20 LTEXT "Application Version 1.0",IDC_STATIC,40,10,119,8,SS_NOPREFIX LTEXT "RTL-reading text",IDC_STATIC,40,25,119,8,0,WS_EX_RTLREADING DEFPUSHBUTTON "OK",IDOK,178,7,50,14,WS_GROUP,0,HIDOK ...
Corresponding XLIFF representation:
... <trans-unit id='1' restype='IDC_STATIC' restype='icon' coord='11;17;20;20' style=''> <source/> </trans-unit> <trans-unit id='2' restype='IDC_STATIC' restype='label' coord='40;10;119;8' style='0x80'> <source>Application Version 1.0</source> </trans-unit> <trans-unit id='3' restype='IDC_STATIC' restype='label' coord='40;25;119;8' style='0x0' exstyle='0x2000'> <source>RTL-reading text</source> </trans-unit> <trans-unit id='4' restype='IDOK' restype='button' coord='178;7;50;14' style='0x20000' exstyle='0x0' help-id='HIDOK'> <source>OK</source> </trans-unit> ...
Table 1 - Mapping of control class to restype
attribute:
Class names in Windows resources are case-insensitive, but the resname
attribute is not: always use lowercase for the value of resname
.
[Should we force to lowercase?]
Control | Default Style | Class | restype Value |
AUTO3STATE |
BS_AUTO3STATE | WS_TABSTOP |
Button |
checkbox |
AUTOCHECKBOX |
BS_AUTOCHECKBOX | WS_TABSTOP |
Button |
checkbox |
AUTORADIOBUTTON |
BS_AUTORADIOBUTTON | WS_TABSTOP |
Button |
radio |
BEDIT |
[???] |
Edit |
edit |
CHECKBOX |
BS_CHECKBOX | WS_TABSTOP |
Button |
checkbox |
COMBOBOX |
CBS_SIMPLE | WS_TABSTOP |
ComboBox |
combobox |
CTEXT |
SS_CENTER | WS_GROUP |
Static |
label |
DEFPUSHBUTTON |
BS_DEFPUSHBUTTON | WS_TABSTOP |
Button |
button |
EDITTEXT |
ES_LEFT | WS_BORDER
| WS_TABSTOP |
Edit |
edit |
GROUPBOX |
BS_GROUPBOX |
Button |
groupbox |
HEDIT |
[???] |
Edit |
edit |
ICON |
SS_ICON |
Static |
icon |
IEDIT |
[???] |
Edit |
edit |
LISTBOX |
LBS_NOTIFY | WS_BORDER |
ListBox |
listbox |
LTEXT |
SS_LEFT | WS_GROUP |
Static |
label |
PUSHBOX |
BS_PUSHBOX | WS_TABSTOP |
Button |
pushbox |
PUSHBUTTON |
BS_PUSHBUTTON | WS_TABSTOP |
Button |
button |
RADIOBUTTON |
BS_RADIOBUTTON | WS_TABSTOP |
Button |
radio |
RTEXT |
SS_RIGHT | WS_GROUP |
Static |
label |
SCROLLBAR |
SBS_HORZ |
ScrollBar |
scrollbar |
STATE3 |
BS_3STATE | WS_TABSTOP |
Button |
checkbox |
USERBUTTON |
[???] |
Button |
button |
The CONTROL
controls are mapped depending on their
style. The restype
attribute for user-defined controls is the
name of the control class (in lowercase).
The following C++ source code illustrates how to get the correct
restype
value from a control class and style:
[Needed?]
// Given szClass the class data // And dwStyle the style data bTranslate = true; if ( wsClass[0] == 0xFFFF ) { switch ( szClass[1] ) { case 0x0080: // Button switch ( dwStyle & 0x0F ) { case BS_CHECKBOX: case BS_AUTOCHECKBOX: case BS_3STATE: case BS_AUTO3STATE: sRestype = "checkbox"; break; case BS_RADIOBUTTON: case BS_AUTORADIOBUTTON: sRestype = "radio"; break; case BS_GROUPBOX: sRestype = "groupbox"; break; default: sRestype = "button"; break; } break; case 0x0081: // Edit sRestype = "edit"; bTranslate = false; break; case 0x0082: // Static switch ( dwStyle & 0x1F ) { case ES_LEFT: case ES_RIGHT: case ES_CENTER: case SS_SIMPLE: sRestype = "label"; break; case SS_ICON: sRestype = "icon"; break; case SS_BLACKRECT: case SS_GRAYRECT: case SS_WHITERECT: case SS_BLACKFRAME: case SS_GRAYFRAME: case SS_WHITEFRAME: case SS_BITMAP: case SS_ENHMETAFILE: case SS_ETCHEDHORZ: case SS_ETCHEDVERT: case SS_ETCHEDFRAME: sRestyep = "static"; bTranslate = false; break; default: sRestype = "static"; break; } break; case 0x0083: // Listbox szRestype = "listbox"; bTranslate = false; break; case 0x0084: // Scrollbar sRestype = "scrollbar"; bTranslate = false; break; case 0x0085: // Combobox sRestype = "combobox"; bTranslate = false; break; default: // Unknown char szBuf[20]; sprintf(szBuf, "#%d", wsClass[1]); sRestype = szBuf; break; } } else sRestype = ConvertToLowerCase(szClass)
DLGINCLUDE
Resource(value=17, RT_DLGINCLUDE
)
[to do]
[Exists in compiled file?]
DLGINIT
ResourceThe DLGINIT
resource (value=240) is used to describe
additional data to specific controls in a given dialog box.
In XLIFF, this resource is represented as follow:
DLGINIT
resource is stored in a <group>
element with the restype
attribute set to dlginit
.resname
attribute. It
corresponds to the resource name of the associated dialog box.<trans-unit>
element with
the restype
attribute set to entry
.resname
attribute.style
element.<source>
element.
Not all entry are translatable text, it depends on the value of the message
associated with the entry. The following values denote translatable text:
0x0401, 0x0403, and 0x1234.translate
attribute set to no
. Example of DLGINIT
resource:
IDD_TESTDLG DLGINIT BEGIN IDC_COMBO_1000, 0x403, 37, 0 0x6e45, 0x7274, 0x2079, 0x2031, 0x666f, 0x4320, 0x6d6f, 0x6f62, 0x3120, 0x3030, 0x2030, 0x6e69, 0x4420, 0x6169, 0x6f6c, 0x2067, 0x3123, 0x3033, "\000" IDC_COMBO_1000, 0x403, 37, 0 0x6e45, 0x7274, 0x2079, 0x2032, 0x666f, 0x4320, 0x6d6f, 0x6f62, 0x3120, 0x3030, 0x2030, 0x6e69, 0x4420, 0x6169, 0x6f6c, 0x2067, 0x3123, 0x3033, "\000" IDC_COMBO_1000, 0x403, 37, 0 0x6e45, 0x7274, 0x2079, 0x6977, 0x6874, 0x6520, 0x7478, 0x6e65, 0x6564, 0x2064, 0x6863, 0x7261, 0x6361, 0x6574, 0x7372, 0x203a, 0xe9e8, 0x2eea, "\000" 0 END
Corresponding XLIFF
representation:
<group restype="dlginit" resname="IDD_TESTDLG"> <trans-unit id="1" resname="IDC_COMBO_1000" restype="entry" style="0x403"> <source>Entry 1 of Combo 1000 in Dialog #130</source> </trans-unit> <trans-unit id="2" resname="IDC_COMBO_1000" restype="entry" style="0x403"> <source>Entry 2 of Combo 1000 in Dialog #130</source> </trans-unit> <trans-unit id="3" resname="IDC_COMBO_1000" restype="entry" style="0x403"> <source>Entry with extended characters: èéê.</source> </trans-unit> </group>
Note that in both the RC script and the compiled file the text of a
DLGINIT
resource is in Windows encoding, not in Unicode. It must be
converted to Unicode in XLIFF.
FONT
Resource(value=8, RT_FONT
)
[Need information for this resource]
FONTDIR
Resource(value=7, RT_FONTDIR
)
[Need information for this resource]
GROUP_CURSOR
Resource(value=12, RT_GROUP_CURSOR
)
[Need information for this resource]
GROUP_ICON
Resource(value=14, RT_GROUP_ICON
)
[Need information for this resource]
HTML
Resource(value=23, RT_HTML
)
[to do]
ICON
ResourceThe ICON
resource (value=3, RT_ICON
) describes an
icon image.
In XLIFF, this resource is represented as follow:
<bin-unit>
element with its
mime-type
attribute set to image/icon
and its
restype
attribute set to icon
.
[Need to get the proper MIME value
for mime-type]resname
attribute of the
<bin-unit>
element.<bin-source>
element, inside
either:<external-file>
element with the href
attribute set to the path of the bitmap file.<internal-file>
element with the bitmap encoded in
Base64. Example of an ICON
resource:
IDR_MAINFRAME ICON DISCARDABLE "Res\\MyApp.ico"
First possible corresponding XLIFF representation:
<bin-unit id='1' resname='IDR_MAINFRAME' mime-type='image/icon' restype='icon'> <bin-source> <external-file href='Res\\MyApp.ico'/> </bin-unit> </bin-unit>
Second possible corresponding XLIFF representation:
<bin-unit id='1' resname='IDR_MAINFRAME' mime-type='image/icon' restype='icon'> <bin-source> <internal-file form='base64'> AAABAAIAICAQAAAAAADoAgAAJgAAABAQEAAAAAAAKAEAAA4DAAAoAAAAIAAAAEAAAAABAAQA AAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDA wACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AP////////////////////////// ///////////////////4AAj///////+AAI/////4AAAACP////+AAAAAj//4AAAAAAAI//+I 7oAAAACP7gAAAAAAAAiI7u7oAAAAAO4AAAAAAAAADugA7gAAAADuAO4AAAAAAI6AAAAAAAAA 7u7uAAAAAADuAAAAAAAAAO7uAAAAAAAA7gAA7gAAAADuAADuAAAAAO4ACOgAAAAA7gDu7gAA AADuAI7gAAAAAO7u7o+AAAAA7u7uiPgAAADu7o///4AAAA7uiP//+AAA7o//////gAAACP// ///4AI////////+ICP////////jMj/////+A7gAI//////jMzMyP//+AAO4AAAj///jMzMzM zI+OAADuAAAACPjMzMzMzMzM7gAA7gAAAATMzMTEzEzMTO4O4O4AAAAETMRMTMTMRMTuDuDu AAAABMRMxMRMRMxE7u7u7gAAAARMxExMxMxExO7uDu4AAAAERERMTEREREzu4ADuAAAABExM RERMRMRE7oAAj4AAAATEREzExExExO4Aj///gAAERMRERExETETuj/////+ABExERERERERE j////////4RERERERERERESP/////4RERERERERERERERI///4REREREREREREREREREj4RE REREREREAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAAAEAAAACAAAAABAAQAAAAAAIAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/ AAAA//8A/wAAAP8A/wD//wAA////AP8AAP//AAD/AAAAAA7gAADgAAAA4AAAAO7gAADgAAAA 4A4AAOAOAADu7/AA7u/wAO////AP///wwA/wDgAP8AzMwAAOAAAMzMzM4A4AAMzEzMzg7gAA zEzEzO4OAADEzExE4A/wAMzEREQP///wREREREAP8AREREREREAEREREAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== </internal-file> </bin-unit> </bin-unit>
MANIFEST
Resource(value=??, RT_MANIFEST
)
[Whistler only?]
[Need information for this resource]
MENU
, MENUEX
and POPUP
ResourcesThe MENU
and MENUEX
resources (value=4, RT_MENU
(for both)) describe menus. The POPUP
resource is a special
sub-resource included in a MENU
or MENUEX
resource.
In XLIFF, these resources are represented as followed:
MENU
and MENUEX
resource is stored in a <group>
element
with a restype
set to menu
. [Do
we need to have a different restype for MENUEX?]id
attribute value of the menu container group is given
the menu ID, which is the parent ID when retrieving the menu from a compiled
resource. [id should not be
determined by profile, it's a tool-level attribute: RC and EXE may need to
use it differently too.]<trans-unit>
element.id
attribute
of the <trans-unit>
. This is applied consistently
throughout the menu. When reading the menu from a compiled resource that
serial number can be assigned in the order as retrieved. The retrieval order
is the first menu item followed by any pop-up menu items followed by the
next menu item. [id should not be
determined by profile, it's a tool-level attribute: RC and EXE may need to
use it differently too.]menu-option
attribute value of the menu item indicates
that menu items location in the menu and provides structure of the menu. The
value and meaning of menu-options is in the table below. These menu-options
are additive so that a menu-option of 145 is a grayed (1) parent of a pop-up
menu (16) and the last menu-item (128) in the current menu (145 = 1 + 16 +
128). [Use style instead?, since
extended menu will need more than menu-option anyway]resname
attribute of the <trans-unit>
.<source>
element of the <trans-unit>
.resname
set to 0, a menu-option
set to 0, and no text. The translate
attribute value for such <trans-unit>
is set to no
, and the restype
is set to separator
.
[need menu-option?, why not style to
be consistent?]<trans-unit>
with a menu-option
attribute value that includes MF_POPUP (0x10), or 0x01 is a <group>
containing the menu-items
of the popu-menu.<group>
has its restype
set to popup-menu
.[To resolve: menu has a simple menu-option, but each item in menuex has a type, a state and a resinfo flag (should we use style, exstyle, menu-option?]
Example of a MENU
resource:
IDR_MAINFRAME MENU PRELOAD DISCARDABLE BEGIN POPUP "&File" BEGIN MENUITEM "&New\tCtrl+N", ID_FILE_NEW MENUITEM "&Open...\tCtrl+O", ID_FILE_OPEN MENUITEM "&Save\tCtrl+S", ID_FILE_SAVE MENUITEM SEPARATOR MENUITEM "E&xit", ID_APP_EXIT END POPUP "&Test" BEGIN MENUITEM "&Menu Level 1 Item 1", ID_TEST_L1I1 POPUP "&Popup Menu" BEGIN MENUITEM "&Menu Level 2 Item 1", ID_TEST_L2I1 END MENUITEM "&Menu Level 1 Item 2", ID_TEST_L1I2, CHECKED, HELP END END
Corresponding XLIFF representation:
<group restype='menu' resname='IDR_MAINFRAME'>
<trans-unit id='1' restype='popup'>
<source>&File</source>
</trans-unit>
<group restype='popup'>
<trans-unit id='2' resname='ID_FILE_NEW' restype='menuitem'>
<source>&New\tCtrl+N</source>
</trans-unit>
<trans-unit id='3' resname='ID_FILE_OPEN' restype='menuitem'>
<source>&Open...\tCtrl+O</source>
</trans-unit>
<trans-unit id='4' resname='ID_FILE_SAVE' restype='menuitem'>
<source>&Save\tCtrl+S</source>
</trans-unit>
<trans-unit id='5' restype='separator' translate='no'>
<source/>
</trans-unit>
<trans-unit id='4' resname='ID_APP_EXIT'>
<source>E&xit</source>
</trans-unit>
</group>
<trans-unit id='5'>
<source>&Test</source>
</trans-unit>
[to do]
</group>
[Need MENUEX examples too]
MESSAGETABLE
Resource The MESSAGETABLE
resource (value=11, RT_MESSAGETABLE
)
has two distinct representation depending whether
the original file it was extracted from was an RC script or a compiled file.
The first one is a simple reference, while the second is the actual content of
the MESSAGETABLE
data.
In XLIFF, the MESSAGETABLE
resource extracted from an RC script is represented as followed:
MESSAGETABLE
resource is stored in a separate
<group>
element with the restype
set to
messagetableref
.resname
attribute.<bin-unit>
element contains the reference to the compiled
message table file. Example of a MESSAGETABLE
resource in an RC script:
ID_MSGTBL1 MESSAGETABLE MSG0409.BIN
Corresponding XLIFF representation:
<group resname="ID_MSGTBL1" restype="messagetableref"> <bin-unit id="0" mime-type="binary/messagetable"> <bin-source> <external-file href="MSG0409.BIN"/> </bin-source> </bin-unit> </group>
[Or should we force to get the BIN and parse it? (but it would make more sense to parse the MC file then...)]
[Note that we need to find the correct mime-type for a <bin-unit> representation or register one, or create a user-defined one.]
The MESSAGETABLE
resource extracted from a compiled file has
the same representation as the data extracted from a message source file (the
.mc file that was used to create the binary data used in the RC script). In
XLIFF, this resource is represented as followed:
MESSAGETABLE
resource is stored in its own
<group>
element with the restype
attribute set to
messagetable
(this is optional for data extracted from the message
file).resname
attribute
of the group (this does not apply for data extracted from the message file).<trans-unit>
element
with the restype
attribute set to message
.MessageId
, the Severity
, and the Facility
values. This identifier is stored in the resname
attribute of
the <trans-unit>
, as an an hexadecimal value. When extracting
from the message file, you can use the value of SymbolicName
rather than the composite identifier for the value of resname
.
[Should we allowed this?]<source>
element of
the <trans-unit>
.Example of a message file:
MessageIdTypedef=DWORD SeverityNames=(Success=0x0:STATUS_SEVERITY_SUCCESS Informational=0x1:STATUS_SEVERITY_INFORMATIONAL Warning=0x2:STATUS_SEVERITY_WARNING Error=0x3:STATUS_SEVERITY_ERROR ) FacilityNames=(System=0x0:FACILITY_SYSTEM Runtime=0x2:FACILITY_RUNTIME Stubs=0x3:FACILITY_STUBS Io=0x4:FACILITY_IO_ERROR_CODE ) LanguageNames=(English=0x409:MSG00409) MessageId=0x1 Severity=Error Facility=Runtime SymbolicName=MSG_BAD_COMMAND Language=English You have chosen an incorrect command. . MessageId=0x2 Severity=Warning Facility=Io SymbolicName=MSG_BAD_PARM1 Language=English Cannot reconnect to the server. .
Corresponding XLIFF representation extracted from the compiled resource:
<group restype="messagetable" resname="#1"> <trans-unit id="1" resname="0x80040002" restype="message"> <source>Cannot reconnect to the server.\r\n</source> </trans-unit> <trans-unit id="2" resname="0xc0020001" restype="message"> <source>You have chosen an incorrect command.\r\n</source> </trans-unit> </group>
Corresponding XLIFF representation extracted from the source message file:
<file original="Messages.mc" source-language="en-us", datatype="binary/messagetable"> <header> <skl><external-file href="Messages.mc.skl"/></skl> </header> <body> <group restype="message"> <trans-unit id="1" resname="MSG_BAD_COMMAND" restype="message"> <source>You have chosen an incorrect command.\r\n</source> </trans-unit> <trans-unit id="2" resname="MSG_BAD_PARM1" restype="message"> <source>Cannot reconnect to the server.\r\n</source> </trans-unit> </group> </body> </file>
Note that the order of the messages in the compiled resource is the one of the composite identifier value, which does not necessarily follow the order in which the entries appear in the source message file.
[Need note about special escaping %0 for noLB, %., etc.?]
PLUGPLAY
Resource(value=19, RT_PLUGPLAY
)
[Need information for this resource]
RCDATA
ResourceThe RCDATA
resource (value=10, RT_RCDATA
) defines
user data.
In XLIFF, this resource is represented as follow:
RCDATA
resource is stored in its own <group>
element with the restype
set to rcdata
.resname
attribute of the
group.[Need to define a way to map RCDATA content to XLIFF. Maybe normal content for strings and binary strings for anything else?]
[Do we need to create some kind of standard format for describing RCDATA?]
Example of an RCDATA
resource:
IDR_MYDATA RCDATA BEGIN "Here is an ANSI string\0", L"Here is a Unicode string\0", 1024, 7L, 0x029a, 0o733 END
Corresponding XLIFF representation:
<group restype='rcdata' resname='IDR_MYDATA'> </group>
STRINGTABLE
Resource The STRINGTABLE
resource (value=6, RT_STRING
)
describes a set of string entries.
In XLIFF, this resource is represented as follow:
STRINGTABLE
resource is stored in a <group>
element with a restype
set to string
.
[or should we use 'stringtable'?
(no real reason, but consistancy with message table would be good one way or
the other]resname
attribute of the group is set to the resource
name (from compiled files only) [How
RC vs
compiled should be handled here?]<trans-unit>
element with a restype
set to string
.resname
attribute.id
attribute value is serially assigned according the
retrieval order to maintain consistency and uniqueness of the
<trans-unit>
id
attribute value.
[YS: disagree. The id attribute should not be
defined by the profile. RC and EXE may need different way to use it.] In
compiled resources strings are grouped by sections of 16 strings. It is
important to make sure the resname
for each string matches the
identifier used in the
original RC file, at least, as its numeric value. The relationships between
string identifier (stringID), string table resource identifier (tableID) and
index starting at zero in the string table (indexID) are as follow:
To calculate the stringID:
stringID = (tableID-1)*16)+indexID) For example, the stringID for the 5th entry of the table with resname='#7' is: ((7-1)*16)+4 = 100
To calculate the tableID and the indexID:
tableID = (stringID div 16)+1 For example, the table resname for stringID 100 is: (100 div 16)+1 = 7 indexID = ((tableID-1)*16)-stringID For example the indexID for the stringID 100 is: ((100 div 16)*16)-100 = 4 (fifth entry of the table)
Example of a STRINGTABLE
resource:
#define IDS_STRING1 100 #define IDS_STRING2 123 ... STRINGTABLE BEGIN IDS_STRING1 "Text of the first string." IDS_STRING2 "Text of the second string." END
Corresponding XLIFF representation extracted from the RC script:
<group restype='string'> <trans-unit id='1' resname='IDS_STRING1'> <source>Text of the first string.</source> </trans-unit> <trans-unit id='2' resname='IDS_STRING2'> <source>Text of the second string.</source> </trans-unit> </group>
Corresponding XLIFF representation extracted from the compiled file:
<group restype='string' resname='#7'> <trans-unit id='1' resname='100'> <!-- 5th item in that table --> <source>Text of the first string.</source> </trans-unit> </group> <group restype='string' resname='#21'> <trans-unit id='2' resname='123'> <!-- 6th item in that table --> <source>Text of the second string.</source> </trans-unit> </group>
[Should RC output be broken down by table like the compiled file output? If so: Could make merging back difficult for RC scripts]
[to do]
[Any difference between RC and compiled file?]
VERSIONINFO
ResourceThe VERSIONINFO
resource (value=16, RT_VERSION
)
describes a set of key/value pairs corresponding to various version
information.
In XLIFF, this resource is represented as follow:
VERSIONINFO
resource is stored in its own <group>
element with the restype
set to versioninfo
.VALUE
entry in the StringFileInfo
block is
stored in its own <trans-unit>
with the attribute restype
set to value
.style
attribute. [Is it necessary? (if
yes: how do you determine this in the RC script?]VALUE
entry is stored (in lowercase) in the resname
attribute. Some entries are not translatable, for example: fileversion
, internalname
, privatebuild
,
and specialbuild
.[What about the VS_FIXEDFILEINFO data at the top of the block?]
Example of a VERSIONINFO
resource:
VS_VERSION_INFO VERSIONINFO FILEVERSION 1,0,0,1 PRODUCTVERSION 1,0,0,1 FILEFLAGSMASK 0x3fL #ifdef _DEBUG FILEFLAGS 0x29L #else FILEFLAGS 0x28L #endif FILEOS 0x4L FILETYPE 0x1L FILESUBTYPE 0x0L BEGIN BLOCK "StringFileInfo" BEGIN BLOCK "040904b0" BEGIN VALUE "Comments", "Comments in the version block\0" VALUE "CompanyName", "Company XYZ\0" VALUE "FileDescription", "TestApp MFC Application\0" VALUE "FileVersion", "1, 0, 0, 1\0" VALUE "InternalName", "TestApp\0" VALUE "LegalCopyright", "Copyright (C) 2002\0" VALUE "LegalTrademarks", "Legal trademarks in the version block\0" VALUE "OriginalFilename", "TestApp.EXE\0" VALUE "PrivateBuild", "Private build info (no translation)\0" VALUE "ProductName", "TestApp Application\0" VALUE "ProductVersion", "1, 0, 0, 1\0" VALUE "SpecialBuild", "Special build info (no translation)\0" END END BLOCK "VarFileInfo" BEGIN VALUE "Translation", 0x409, 1200 END END
Corresponding XLIFF representation:
<group restype='versioninfo'>
<trans-unit id='1' restype='value' resname='comments' style='0x1'>
<source>Comments in the version block\0</source>
</trans-unit>
[to do]
</group>
[What about the 'VarFileInfo' block?]
[Need to specify exactly how to deal with language/encoding identifier]
[Do we need a note about \0 endings? (to keep or not in extracted file?)]
VXD
Resource(value=20, RT_VXD
)
[Need information for this resource]
[to do]
Windows resources are labeled with language identifier. This language identifier must be mapped to a language value for the attribute xml:lang, source-language and target-language. The mapped value must respect the definition of RFC 3066 [RFC 3066].
There are a number of inconsistencies in the way language identifiers are
defined in Windows that leads to various challenges in the mapping to RFC 3066
values. For example, Spanish modern sort is considered as a language
identifier. In other cases the Windows language identifier does not have any
evident correspondence to an RFC 3066 value, such as LANG_INVARIANT
,
or English Caribbean. Lastly, some of the language identifiers indicate script
differences rather than regions, for instance, Azeri in Latin or Cyrillic.
[The yellow marks indicate mapping that are problematic: none exists, are illogical, or the values used by XP are not valid RFC 3066 values.]
The table is ordered first by identifier of the main language (rows with gray background), then, by the identifier of the sub-language.
Identifier | Predefined Symbol | Language | RFC 3066 Value |
0x0000 | LANG_NEUTRAL |
Windows: Neutral | [? (xp=none)] |
+0x01 (0x0400) | + SUBLANG_DEFAULT |
Neutral, Default | [? (xp=none)] |
+0x02 (0x0800) | + SUBLANG_SYS_DEFAULT |
Neutral, System Default | [? (xp=none)] |
0x0001 | LANG_ARABIC |
Arabic | ar |
+0x01 (0x0401) | + SUBLANG_DEFAULT |
Arabic, Saudi Arabia | ar-SA |
+0x01 (0x0401) | + SUBLANG_ARABIC_SAUDI_ARABIA |
Arabic, Saudi Arabia | ar-SA |
+0x02 (0x0801) | + SUBLANG_ARABIC_IRAQ |
Arabic, Iraq | ar-IQ |
+0x03 (0x0c01) | + SUBLANG_ARABIC_EGYPT |
Arabic, Egypt | ar-EG |
+0x04 (0x1001) | + SUBLANG_ARABIC_LIBYA |
Arabic, Libya | ar-LY |
+0x05 (0x1401) | + SUBLANG_ARABIC_ALGERIA |
Arabic, Algeria | ar-DZ |
+0x06 (0x1801) | + SUBLANG_ARABIC_MOROCCO |
Arabic, Morocco | ar-MA |
+0x07 (0x1c01) | + SUBLANG_ARABIC_TUNISIA |
Arabic, Tunisia | ar-TN |
+0x08 (0x2001) | + SUBLANG_ARABIC_OMAN |
Arabic, Oman | ar-OM |
+0x09 (0x2401) | + SUBLANG_ARABIC_YEMEN |
Arabic, Yemen | ar-YE |
+0x0a (0x2801) | + SUBLANG_ARABIC_SYRIA |
Arabic, Syria | ar-SY |
+0x0b (0x2c01) | + SUBLANG_ARABIC_JORDAN |
Arabic, Jordan | ar-JO |
+0x0c (0x3001) | + SUBLANG_ARABIC_LEBANON |
Arabic, Libanon | ar-LB |
+0x0d (0x3401) | + SUBLANG_ARABIC_KUWAIT |
Arabic, Kuwait | ar-KW |
+0x0e (0x3801) | + SUBLANG_ARABIC_UAE |
Arabic, UAE | ar-EA |
+0x0f (0x3c01) | + SUBLANG_ARABIC_BAHRAIN |
Arabic, Bahrain | ar-BH |
+0x10 (0x4001) | + SUBLANG_ARABIC_QATAR |
Arabic, Qatar | ar-QA |
0x0002 | LANG_BULGARIAN |
Bulgarian | bg |
+0x01 (0x0402) | + SUBLANG_DEFAULT |
Bulgarian (Bulgaria) | bg-BG |
0x0003 | LANG_CATALAN |
Catalan | ca |
+0x01 (0x0403) | + SUBLANG_DEFAULT |
Catalan (Spain) | ca-ES |
0x0004 | LANG_CHINESE |
Chinese | zh |
+0x01 (0x0404) | + SUBLANG_DEFAULT |
Chinese, Taiwan (Traditional) | zh-TW |
+0x01 (0x0404) | + SUBLANG_CHINESE_TRADITIONAL |
Chinese, Taiwan (Traditional) | zh-TW |
+0x02 (0x0804) | + SUBLANG_CHINESE_SIMPLIFIED |
Chinese, China (Simplified) | zh-CN |
+0x03 (0x0c04) | + SUBLANG_CHINESE_HONGKONG |
Chinese, Hong-Kong | zh-HK |
+0x04 (0x1004) | + SUBLANG_CHINESE_SINGAPORE |
Chinese, Singapore | zh-SG |
+0x05 (0x1404) | + SUBLANG_CHINESE_MACAU |
Chinese, Macau | zh-MO |
0x0005 | LANG_CZECH |
Czech | cs |
+0x01 (0x0405) | + SUBLANG_DEFAULT |
Czech, Czech Republic | cs-CZ |
0x0006 | LANG_DANISH |
Danish | da |
+0x01 (0x0406) | + SUBLANG_DEFAULT |
Danish, Denmark | da-DN |
0x0007 | LANG_GERMAN |
German | de |
+0x01 (0x0407) | + SUBLANG_DEFAULT |
German, Germany | de-DE |
+0x01 (0x0407) | + SUBLANG_GERMAN |
German, Germany | de-DE |
+0x02 (0x0807) | + SUBLANG_GERMAN_SWISS |
German, Switzerland | de-CH |
+0x03 (0x0c07) | + SUBLANG_GERMAN_AUSTRIAN |
German, Austria | de-AT |
+0x04 (0x1007) | + SUBLANG_GERMAN_LUXEMBOURG |
German, Luxembourg | de-LU |
+0x05 (0x1407) | + SUBLANG_GERMAN_LIECHTENSTEIN |
German, Liechtenstein | de-LI |
0x0008 | LANG_GREEK |
Greek | el |
+0x01 (0x0408) | + SUBLANG_DEFAULT |
Greek, Greece | el-GR |
0x0009 | LANG_ENGLISH |
English | en |
+0x01 (0x0409) | + SUBLANG_DEFAULT |
English, US | en-US |
+0x01 (0x0409) | + SUBLANG_ENGLISH_US |
English, US | en-US |
+0x02 (0x0809) | + SUBLANG_ENGLISH_UK |
English, UK | en-GB |
+0x03 (0x0c09) | + SUBLANG_ENGLISH_AUS |
English, Australia | en-AU |
+0x04 (0x1009) | + SUBLANG_ENGLISH_CAN |
English, Canada | en-CA |
+0x05 (0x1409) | + SUBLANG_ENGLISH_NZ |
English, New Zealand | en-NZ |
+0x06 (0x1809) | + SUBLANG_ENGLISH_EIRE |
English, Ireland | en-IE |
+0x07 (0x1c09) | + SUBLANG_ENGLISH_SOUTH_AFRICA |
English, South Africa | en-ZA |
+0x08 (0x2009) | + SUBLANG_ENGLISH_JAMAICA |
English, Jamaica | en-JM |
+0x09 (0x2409) | + SUBLANG_ENGLISH_CARIBBEAN |
English, Caribbean | [? (xp=en-CB)] |
+0x0a (0x2809) | + SUBLANG_ENGLISH_BELIZE |
English, Belize | en-BZ |
+0x0b (0x2c09) | + SUBLANG_ENGLISH_TRINIDAD |
English, Trinidad & Tobago | en-TT |
+0x0c (0x3009) | + SUBLANG_ENGLISH_ZIMBABWE |
English, Zimbabwe | en-ZW |
+0x0d (0x3409) | + SUBLANG_ENGLISH_PHILIPPINES |
English, Philippines | en-PH |
0x000a | LANG_SPANISH |
Spanish | es |
+0x01 (0x040a) | + SUBLANG_DEFAULT |
Spanish, Spain (Castilian) | es-ES |
+0x01 (0x040a) | + SUBLANG_SPANISH |
Spanish, Spain (Castilian) | es-ES |
+0x02 (0x080a) | + SUBLANG_SPANISH_MEXICAN |
Spanish, Mexico | es-MX |
+0x03 (0x0c0a) | + SUBLANG_SPANISH_MODERN |
Spanish, Modern Sort | [? (xp=none)] |
+0x04 (0x100a) | + SUBLANG_SPANISH_GUATEMALA |
Spanish, Guatemala | es-GT |
+0x05 (0x140a) | + SUBLANG_SPANISH_COSTA_RICA |
Spanish, Costa Rica | es-CR |
+0x06 (0x180a) | + SUBLANG_SPANISH_PANAMA |
Spanish, Panama | es-PA |
+0x07 (0x1c0a) | + SUBLANG_SPANISH_DOMINICAN_REPUBLIC |
Spanish, Dominican Republic | es-DO |
+0x08 (0x200a) | + SUBLANG_SPANISH_VENEZUELA |
Spanish, Venezuela | es-VE |
+0x09 (0x240a) | + SUBLANG_SPANISH_COLOMBIA |
Spanish, Columbia | es-CO |
+0x0a (0x280a) | + SUBLANG_SPANISH_PERU |
Spanish, Peru | es-PE |
+0x0b (0x2c0a) | + SUBLANG_SPANISH_ARGENTINA |
Spanish, Argentina | es-AR |
+0x0c (0x300a) | + SUBLANG_SPANISH_ECUADOR |
Spanish, Ecuador | es-EC |
+0x0d (0x340a) | + SUBLANG_SPANISH_CHILE |
Spanish, Chile | es-CL |
+0x0e (0x380a) | + SUBLANG_SPANISH_URUGUAY |
Spanish, Uruguay | es-UY |
+0x0f (0x3c0a) | + SUBLANG_SPANISH_PARAGUAY |
Spanish, Paraguay | es-PY |
+0x10 (0x400a) | + SUBLANG_SPANISH_BOLIVIA |
Spanish, Bolivia | es-BO |
+0x11 (0x440a) | + SUBLANG_SPANISH_EL_SALVADOR |
Spanish, El Salvador | es-SV |
+0x12 (0x480a) | + SUBLANG_SPANISH_HONDURAS |
Spanish, Honduras | es-HN |
+0x13 (0x4c0a) | + SUBLANG_SPANISH_NICARAGUA |
Spanish, Nicaragua | es-NI |
+0x14 (0x500a) | + SUBLANG_SPANISH_PUERTO_RICO |
Spanish, Puerto Rico | es-PR |
0x000b | LANG_FINNISH |
Finnish | fi |
+0x01 (0x040b) | + SUBLANG_DEFAULT |
Finnish, Finland | fi-FI |
0x000c | LANG_FRENCH |
French | fr |
+0x01 (0x040c) | + SUBLANG_DEFAULT |
French, France | fr-FR |
+0x01 (0x040c) | + SUBLANG_FRENCH |
French, France | fr-FR |
+0x02 (0x080c) | + SUBLANG_FRENCH_BELGIAN |
French, Belgium | fr-BE |
+0x03 (0x0c0c) | + SUBLANG_FRENCH_CANADIAN |
French, Canada | fr-CA |
+0x04 (0x100c) | + SUBLANG_FRENCH_SWISS |
French, Switzerland | fr-CH |
+0x05 (0x140c) | + SUBLANG_FRENCH_LUXEMBOURG |
French, Luxembourg | fr-LU |
+0x05 (0x180c) | + SUBLANG_FRENCH_MONACO |
French, Monaco | fr-MC |
0x000d | LANG_HEBREW |
Hebrew | he |
+0x01 (0x040d) | + SUBLANG_DEFAULT |
Hebrew, Israel | he-IL |
0x000e | LANG_HUNGARIAN |
Hungarian | hu |
+0x01 (0x040e) | + SUBLANG_DEFAULT |
Hungarian, Hungary | hu-HU |
0x000f | LANG_ICELANDIC |
Icelandic | is |
+0x01 (0x040f) | + SUBLANG_DEFAULT |
Icelandic, Iceland | is-IS |
0x0010 | LANG_ITALIAN |
Italian | it |
+0x01 (0x0410) | + SUBLANG_DEFAULT |
Italian, Italy | it-IT |
+0x01 (0x0410) | + SUBLANG_ITALIAN |
Italian, Italy | it-IT |
+0x02 (0x0810) | + SUBLANG_ITALIAN_SWISS |
Italian, Switzerland | it-CH |
0x0011 | LANG_JAPANESE |
Japanese | ja |
+0x01 (0x0411) | + SUBLANG_DEFAULT |
Japanese, Japan | ja-JP |
0x0012 | LANG_KOREAN |
Korean | ko |
+0x01 (0x0412) | + SUBLANG_DEFAULT |
Korean, Extended Wansung | [? ko (xp=ko-KR)] |
+0x01 (0x0412) | + SUBLANG_KOREAN |
Korean, Extended Wansung | [? ko (xp=ko-KR)] |
0x0013 |
|
Dutch | nl |
+0x01 (0x413) | + SUBLANG_DEFAULT |
Dutch, Netherlands | nl-NL |
+0x01 (0x413) | + SUBLANG_DUTCH |
Dutch, Netherlands | nl-NL |
+0x02 (0x813) | + SUBLANG_DUTCH_BELGIAN |
Dutch, Belgium (Flemish) | nl-BE |
0x0014 |
|
Norwegian | no |
+0x01 (0x414) | + SUBLANG_DEFAULT |
Norwegian, Bokmål | [? (xp=nb-NO)] |
+0x01 (0x414) | + SUBLANG_NORWEGIAN_BOKMAL |
Norwegian, Bokmål | [? (xp=nb-NO)] |
+0x02 (0x814) | + SUBLANG_NORWEGIAN_NYNORSK |
Norwegian, Nynorsk | [? (xp=nn-NO)] |
0x0015 | LANG_POLISH |
Polish | pl |
+0x01 (0x415) | + SUBLANG_DEFAULT |
Polish, Poland | pl-PL |
0x0016 | LANG_PORTUGUESE |
Portuguese | pt |
+0x01 (0x416) | + SUBLANG_DEFAULT |
Portuguese, Brazil | pt-BR |
+0x01 (0x416) | + SUBLANG_PORTUGUESE_BRAZILIAN |
Portuguese, Brazil | pt-BR |
+0x02 (0x816) | + SUBLANG_PORTUGUESE |
Portuguese, Portugal | pt-PT |
0x0018 | LANG_ROMANIAN |
Romanian | ro |
+0x01 (0x418) | + SUBLANG_DEFAULT |
Romanian, Romania | ro-RO |
0x0019 | LANG_RUSSIAN |
Russian | ru |
+0x01 (0x419) | + SUBLANG_DEFAULT |
Russian, Russia | ru-RU |
0x001a | LANG_CROATIAN |
Croatian | hr |
+0x01 (0x41a) | + SUBLANG_DEFAULT |
Croatian, Croatia | hr-HR |
0x001a | LANG_SERBIAN |
Serbian | sr |
+0x01 (0x41b) | + SUBLANG_DEFAULT |
Serbian ??? | [? (xp=none)] |
+0x02 (0x41a) | + SUBLANG_SERBIAN_LATIN |
Serbian, Latin Script | [? (xp=Lt-sr-SP)] |
+0x03 (0x81b) | + SUBLANG_SERBIAN_CYRILLIC |
Serbian, Cyrillic Script | [? (xp=Cy-sr-SP)] |
0x001b | LANG_SLOVAK |
Slovak | sk |
+0x01 (0x41b) | + SUBLANG_DEFAULT |
Slovak, Slovakia | sk-SK |
0x001c | LANG_ALBANIAN |
Albanian | sq |
+0x01 (0x041c) | + SUBLANG_DEFAULT |
Albanian, Albania | sq-AL |
0x001d | LANG_SWEDISH |
Swedish | sv |
+0x01 (0x041d) | + SUBLANG_DEFAULT |
Swedish, Sweden | sv-SE |
+0x01 (0x041d) | + SUBLANG_SWEDISH |
Swedish, Sweden | sv-SE |
+0x02 (0x081d) | + SUBLANG_SWEDISH_FINLAND |
Swedish, Finland | sv-FI |
0x001e | LANG_THAI |
Thai | th |
+0x01 (0x041e) | + SUBLANG_DEFAULT |
Thai, Thailand | th-TH |
0x001f | LANG_TURKISH |
Turkish | tr |
+0x01 (0x041f) | + SUBLANG_DEFAULT |
Turkish, Turkey | tr-TR |
0x0020 | LANG_URDU |
Urdu | ur |
+0x01 (0x0420) | + SUBLANG_DEFAULT |
Urdu, Pakistan | ur-PK |
+0x01 (0x0420) | + SUBLANG_URDU_PAKISTAN |
Urdu, Pakistan | ur-PK |
+0x02 (0x0820) | + SUBLANG_URDU_INDIA |
Urdu, India | ur-IN |
0x0021 | LANG_INDONESIAN |
Indonesian | id |
+0x01 (0x0421) | + SUBLANG_DEFAULT |
Indonesian, Indonesia | id-ID |
0x0022 | LANG_UKRANIAN |
Ukrainian | uk |
+0x01 (0x0422) | + SUBLANG_DEFAULT |
Ukrainian, Ukraine | uk-UA |
0x0023 | LANG_BELARUSIAN |
Belarusian | be |
+0x01 (0x0423) | + SUBLANG_DEFAULT |
Belarusian, Belarus | be-BY |
0x0024 | LANG_SLOVENIAN |
Slovenian | sl |
+0x01 (0x0424) | + SUBLANG_DEFAULT |
Slovenian, Slovenia | sl-SI |
0x0025 | LANG_ESTONIAN |
Estonian | et |
+0x01 (0x0425) | + SUBLANG_DEFAULT |
Estonian, Estonia | et-EE |
0x0026 | LANG_LATVIAN |
Latvian | lv |
+0x01 (0x0426) | + SUBLANG_DEFAULT |
Latvian, Latvia | lv-LV |
0x0027 | LANG_LITHUANIAN |
Lithuanian | lt |
+0x01 (0x0427) | + SUBLANG_DEFAULT |
Lithuanian, Lithuania | lt-LT |
+0x01 (0x0427) | + SUBLANG_LITHUANIAN |
Lithuanian, Lithuania | lt-LT |
+0x02 (0x0827) | + SUBLANG_LITHUANIAN_CLASSIC |
Lithuanian, Classical | [? (xp=none)] |
0x0029 | LANG_FARSI |
Farsi | fa |
+0x01 (0x0429) | + SUBLANG_DEFAULT |
Farsi, Iran | fa-IR |
0x002a | LANG_VIETNAMESE |
Vietnamese | vi |
+0x01 (0x042a) | + SUBLANG_DEFAULT |
Vietnamese, Vietnam | vi-VN |
0x002b | LANG_ARMENIAN |
Armenian | hy |
+0x01 (0x042b) | + SUBLANG_DEFAULT |
Armenian, Armenia | hy-AM |
0x002c | LANG_AZERI |
Azeri | az |
+0x01 (0x042c) | + SUBLANG_DEFAULT |
Azeri, Latin Script | [? (xp=Lt-az-AZ)] |
+0x01 (0x042c) | + SUBLANG_AZERI_LATIN |
Azeri, Latin Script | [? (xp=Lt-az-AZ)] |
+0x02 (0x082c) | + SUBLANG_SERBIAN_CYRILLIC |
Azeri, Cyrillic Script | [? (xp=Cy-az-AZ)] |
0x002d | LANG_BASQUE |
Basque | eu |
+0x01 (0x042d) | + SUBLANG_DEFAULT |
Basque, Spain | eu-ES |
0x002f | LANG_MACEDONIAN |
Macedonian | mk |
+0x01 (0x042f) | + SUBLANG_DEFAULT |
Macedonian, Macedonia | mk-MK |
0x0036 | LANG_AFRIKAANS |
Afrikaans | af |
+0x01 (0x0436) | + SUBLANG_DEFAULT |
Afrikaans, South Africa | af-ZA |
0x0037 | LANG_GEORGIAN |
Georgian | ka |
+0x01 (0x0437) | + SUBLANG_DEFAULT |
Georgian, Georgian | ka-GE |
0x0038 | LANG_FAEROESE |
Faeroese | fo |
+0x01 (0x0438) | + SUBLANG_DEFAULT |
Faeroese, Faeroe Islands | fo-FO |
0x0039 | LANG_HINDI |
Hindi | hi |
+0x01 (0x0439) | + SUBLANG_DEFAULT |
Hindi, India | hi-IN |
0x003e | LANG_MALAY |
Malay | ms |
+0x01 (0x043e) | + SUBLANG_DEFAULT |
Malay, Malaysia | ms-MY |
+0x01 (0x043e) | + SUBLANG_MALAY_MALAYSIA |
Malay, Malaysia | ms-MY |
+0x02 (0x083e) | + SUBLANG_MALAY_BRUNEI_DARUSSALAM |
Malay, Brunei | ms-BN |
0x003f | LANG_KAZAK |
Kazakh | kk |
+0x01 (0x043f) | + SUBLANG_DEFAULT |
Kazakh, Kazakhstan | kk-KZ |
0x0040 | LANG_KYRGYZ |
Kyrgyz | ky |
+0x01 (0x0440) | + SUBLANG_DEFAULT |
Kyrgyz, Kyrgyzstan | ky-KG |
0x0041 | LANG_SWAHILI |
Swahili | sw |
+0x01 (0x0441) | + SUBLANG_DEFAULT |
Swahili, Kenya | sw-KE |
0x0043 | LANG_UZBEK |
Uzbek | uz |
+0x01 (0x0443) | + SUBLANG_DEFAULT |
Uzbek, Latin Script | [? xp=Lt-uz-UZ] |
+0x01 (0x0443) | + SUBLANG_UZBEK_LATIN |
Uzbek, Latin Script | [? xp=Lt-uz-UZ] |
+0x02 (0x0843) | + SUBLANG_UZBEK_CYRILLIC |
Uzbek, Cyrillic Script | [? xp=Cy-uz-UZ] |
0x0044 | LANG_TATAR |
Tatar | tt |
+0x01 (0x0444) | + SUBLANG_DEFAULT |
Tatar, Russia | tt-RU |
0x0045 | LANG_BENGALI |
Bengali | bn |
+0x01 (0x0445) | + SUBLANG_DEFAULT |
Bengali, Bengladesh | bn-BD |
0x0046 | LANG_PUNJABI |
Punjabi | pa |
+0x01 (0x0446) | + SUBLANG_DEFAULT |
Punjabi, India | pa-IN |
0x0047 | LANG_GUJARATI |
Gujarati | gu |
+0x01 (0x0447) | + SUBLANG_DEFAULT |
Gujarati, India | gu-IN |
0x0048 | LANG_ORIYA |
Oriya | or |
+0x01 (0x0448) | + SUBLANG_DEFAULT |
Oriya, India | or-IN |
0x0049 | LANG_TAMIL |
Tamil | ta |
+0x01 (0x0449) | + SUBLANG_DEFAULT |
Tamil, India | ta-IN |
0x004a | LANG_TELUGU |
Telugu | te |
+0x01 (0x044a) | + SUBLANG_DEFAULT |
Telugu, India | te-IN |
0x004b | LANG_KANNADA |
Kannada | kn |
+0x01 (0x044b) | + SUBLANG_DEFAULT |
Kannada, India | kn-IN |
0x004c | LANG_MALAYALAM |
Malayalam | ml |
+0x01 (0x044c) | + SUBLANG_DEFAULT |
Malayalam, | ml-IN |
0x004d | LANG_ASSAMESE |
Assamese | as |
+0x01 (0x044d) | + SUBLANG_DEFAULT |
Assamese, India | as-IN |
0x004e | LANG_MARATHI |
Marathi | mr |
+0x01 (0x044e) | + SUBLANG_DEFAULT |
Marathi, India | mr-IN |
0x004f | LANG_SANSKRIT |
Sanskrit | sa |
+0x01 (0x044f) | + SUBLANG_DEFAULT |
Sanskrit, India | sa-IN |
0x0050 | LANG_MONGOLIAN |
Mongolian | mn |
+0x01 (0x0450) | + SUBLANG_DEFAULT |
Mongolian, Mongolia | mn-MN |
0x0056 | LANG_GALICIAN |
Galician | gl |
+0x01 (0x0456) | + SUBLANG_DEFAULT |
Galician, Spain | gl-ES |
0x0057 | LANG_KONKANI |
Konkani | kok |
+0x01 (0x0457) | + SUBLANG_DEFAULT |
Konkani, India | kok-IN |
0x0058 | LANG_MANIPURI |
Manipuri | mni |
+0x01 (0x0458) | + SUBLANG_DEFAULT |
Manipuri, India | mni-IN |
0x0059 | LANG_SINDHI |
Sindhi | sd |
+0x01 (0x0459) | + SUBLANG_DEFAULT |
Sindhi, India | sd-IN |
0x005a | LANG_SYRIAC |
Syriac | syr |
+0x01 (0x045a) | + SUBLANG_DEFAULT |
Syriac, Syria | syr-SY |
0x0060 | LANG_KASHMIRI |
Kashmiri | ks |
+0x01 (0x0461) | + SUBLANG_DEFAULT |
Kashmiri, [locale? PK?] | [? ks-PK] |
+0x02 (0x0861) | + SUBLANG_KASHMIRI_INDIA |
Kashmiri, India | ks-IN |
0x0061 | LANG_NEPALI |
Nepali | ne |
+0x01 (0x0461) | + SUBLANG_DEFAULT |
Nepali, Nepal | ne-NP |
+0x02 (0x0861) | + SUBLANG_NEPALI_INDIA |
Nepali, India | ne-IN |
0x0065 | LANG_DIVEHI |
Divehi | div |
+0x01 (0x0465) | + SUBLANG_DEFAULT |
Divehi, Maldives | div-MV |
0x007f | LANG_INVARIANT |
Windows: Invariant | [? (xp=empty)] |
+0x01 (0x047f) | + SUBLANG_DEFAULT |
Invariant, Default | [? (xp=none)] |
+0x02 (0x087f) | + SUBLANG_SYS_DEFAULT |
Invariant, System Default | [? (xp=none)] |
[Additional appendix? Do we need a table of the virtual key names for 'accelerator to text' convertion???]
The following people have contributed to this document: