[xliff] XLIFF and Windows Resources

[Yves Savourel <ysavourel@translate.com>]

Hi everyone,

At the Unicode conference last month, several of us (John R, Enda, Jaime,
etc.) decided start working on defining a common way to represent Windows
resources in XLIFF, since we were all producing XLIFF documents from RC
and/or Compiled files. This way any tool will be able to rely on the same
representation regardless who did the extraction.

Since this may be of interest to more people, we thought it would be good to
have that discussion in a thread of the mailing list.

John will soon (if not before this message) post a first document with some
examples and descriptions, etc. The attached HTML file contains my notes
after reading his document, as well as some additional concerns/notes/etc.

cheers
-yves

Notes about XLIFF and Windows Resources (The ones with "Re JR Example" refer to John's document).

1. Dialog Resources and numchildren

Re JR Example: numchildren attribute: Why would we need such information? Wouldn't a simple count of the children nodes of the group can give the information?

2. Grouping by restype

Re JR Example: The examples shows all resources of the same type grouped in a single <group>. I don't think we want to force this: when extracted from an RC file the resources can be in any order, in separate sections, grouping them will cause a lot of additional work in extract and merge. On the other hand, once in XLIFF you can easily use XPath to get all resource of a same type if needed.

3. IDs Text vs. Numbers

I think we will need to have some description about how to handle ID: in documents extracted from RC file it may be more interesting to have the mnemonic ID rather than the numeric value (IDS_MYSTRING vs. 1001). The problem then is that the same file could generate different IDs depending whether it comes from the RC or the compiled version. I guess someone who wants to do some comparison would have to resolve the IDs based on the header file (could be a nice utility).

4. IDs Values in stringtable

Re JR Example: Wouldn't it make more sense to have the resname for each string to be the actual ID of that string, and not id?

5. Language Identifiers

We will need to provide a mapping between Windows Languague IDs and RFC 3066 values (for xml:lang, source-language, etc.). I've started that but several are difficult to map.

I've looked at the CultureInfo identifier in XP where the mapping would be logically done since they are using RFC 3066 values there, but there have non-conformant values in some cases, and even no mapping in some cases. Not a pretty picture.

6. Scope

We will need to specify the scope of the data we are working with here. I assume: not including Windows XP, for now.

7. Levels

Some tools may want to extract only a small part of the resources (ID and text for example). Maybe(?) we should make provision for this. Maybe we could have two types of extracted resources: complete (you can create a runtime output of the dialog from them), or partial (only some data are available).

8. restype Values for Controls

Using the control class name (or number) as the restype value is probably not enough, at least for the pre-defined control classes:

When working from RC files, there are a lot of controls that are "Button" but are, depending of their style, very different: check boxes, radio buttons, icon, etc. I think it may be useful to have such distinction in the restype value otherwise it's almost impossible to easily know what kind of control the "Button" is (you would have to look at the value of the style: rather impossible for humans).

Also, we probably need to enforce either lowercase or uppercase values since Windows class name are non case sensitive, but resname is.

9. Styles Values

Re JR Example: I'm still nervous about having negative values for styles. Maybe a better solution would be to use hexadecimal values rather than signed decimal. It would also be easier to 'read' it compared to the actual values in Windows header file.

Example: style="0x80C80080" (instead of style="-2134376320").

10. Text Itself

We should have some recommendation (or explicitly said we don't have any recommendation) about how to represent the resource text itself: Should \n, \a, etc. be represented as inline codes? Should it be un-escaped? etc.

Also how to represent accelerators? Should we have a common way for this ("Alt+c", "^C", etc.) or should it be handled through the style?