OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: FW: [xliff-comment] XLIFF and resizing information

Hi all,
Here are a few more comments from Nikolai that may be useful for the discussion on font, coord, etc.
-----Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com]
Sent: Thu, January 09, 2003 3:34 PM
To: Nikolai Tsepalov
Subject: RE: [xliff-comment] XLIFF and resizing information

Hi Nikolai,
Thanks for your comments. They will be useful for the discussion the group is currently having. Is it Ok if I post them on the XLIFF list so other can see them as well?
I've tried to answer some questions. Please, see below:
-----Original Message-----
From: Nikolai Tsepalov [mailto:nikolait@earthlink.net]
Sent: Tue, January 07, 2003 3:11 PM
To: ysavourel@translate.com
Subject: RE: [xliff-comment] XLIFF and resizing information

Hi Yves,

My phone line was broken for a few days so I could not answer.

Thank you for respond. It answers my main question about group coordinates localization.

As I understood, if any changes need to be made to a locale version, they should go in to <translation unit> and then <source> of this group.  I believe this is rule not only for Windows resources but it is general.


Here some questions and thought I have after reading attached document. I don‘t need answers to them to continue my work, therefore if you are busy skip them.


Take care,




2.2.2. Non-Unique Identifiers


In my opinion converter definitely should warn user and recommend making these IDs unique.

If user insists to use file with non-unique ID, the best way is to generate pseudo IDs based on controls original text if control has is. For instance take first ten chars of the text, capitalize them and remove ampersands and other symbols. 

This way better than order or type based approach, because text is that we care about the most, secondary, restype is not reliable information (usually dialogs with large amount of text have a lot of labels with exactly the same restype). Controls order in dialog also very unreliable; it can be changed not only by controls deletion-addition but by changing a tab order as well.

Same approach works for menu’s POPUPs as well. It should not be based only on POPUP order; if new POPUP was inserted in main menu all XLIFF IDs will be broken.


Numeric XLIFF IDs.


As I see in document XLIFF’s IDs are just a numbers. If leveraging algorithm should use only IDs and this is the only they to go, because algorithm should not be particular format aware, IDs should be much more informative.


How you can leverage


<trans-unit id='2' resname='ID_FILE_NEW' restype='menuitem'>

<trans-unit id='3' resname='ID_SOME_NEW_ITEM' restype='menuitem'>

<trans-unit id='4' resname='ID_FILE_OPEN' restype='menuitem'>

<trans-unit id='5' resname='ID_FILE_SAVE' restype='menuitem'>

<trans-unit id='6' restype='separator' translate='no'>

<trans-unit id='7' resname='ID_APP_EXIT'>




<trans-unit id='2' resname='ID_FILE_NEW' restype='menuitem'>

<trans-unit id='3' resname='ID_FILE_OPEN' restype='menuitem'>

<trans-unit id='4' resname='ID_FILE_SAVE' restype='menuitem'>

<trans-unit id='5' restype='separator' translate='no'>

<trans-unit id='6' resname='ID_APP_EXIT'>


without digging to resname level?
[YS] resname is the resource-ID of the item. the 'id' attribute has a meaning only within the XLIFF file for the tool that does the extraction or transformation. The names are not very clear I agree... it's a long story of different opinions and compromises.


RC resource file itself, with exception of not unique dialog IDs and Popups, allows generating a file scope unique IDs based on simple schema:


String table IDs are unique by themselves.

Menu ID plus menu Item ID is unique.

Dialog ID plus control ID is unique.


So it will be something like <trans-unit id=' 'IDR_MAINFRAME__ID_FILE_NEW ' resname='ID_FILE_NEW' restype='menuitem'>

This approach I’ve used for my leveraging programs at Siebel Systems.  



Basic UI layout specification.


As I understand with Windows resource (winres) representation in XLIFF format you are trying to make XLIFF document sufficient to regenerate locale version of resources without original ENU source. This is not only difficult tack, but it also makes XLIFF editor tool 100% winres aware tool. This is fine with winres, as well as with any other current and incoming Microsoft standards. Almost every single company will use it.

My question is: How do you plan to handle zillions of single company specific formats?
[YS] Good question. the answer is two fold: First we have looked at RC file more closely because the overwhelming majority of the XLIFF users we know of are Windows users. Second, Most of the non-Windows users are Java users (Sun is an XLIFF founder and contributor for example) and they work with properties files that can be mapped easily to XLIFF. However, in my opinion, we need "profiles" similar to the document I sent you for many formats. My hope is that we can arrive at a set of properties that can be use across formats. XLIFF 1.1 also allow the use of different namespaces and there is a possibility to develop format-specific sub set of information for whatever is not covered by the default attributes.

This is definitely not easy, and a working solution will have to go through a lot of tries.


Let’s say some Software Development Company (SDC) has application with localizable information in standard winres and in some special repository. SDC needs to send localization kit to Software Localization Company (SLC). With winres it’s fine. Both companies have some commercial XLIFF editor (CATALYST 6.6J for instance), so SDC convert RC in to XLIFF send it to SLC, done.
But, what to do with unique SDC repository format? Obviously only SDC can quickly and with good quality make converter from repository to XLIFF. How currently SDC can make it?

Obviously coordinates and sizes are not enough for UI representation, label control can hold much longer text than equal size check box, and therefore we need styles.

For first look current XLIFF has everything  (coord, font, css-style, style, exstyle, extype, maxbytes, minbytes, size-unit, maxheight, minheight, maxwidth, minwidth, charclass), but if every SDC going to use its own styles names, nobody will understand them. SDC_ComboBox will be unknown for CATALYST.


I can see two ways to solve this problem.

1. XLIFF may have some set of basic UI components XLIFF_COMBOBOX, XLIFF_LABEL or something like it; let's call it Basic UI (BUI). Each of these BUI elements should have set of attributes which allows developer to describe company specific UI element as much as possible closer to reality. For instance, for check box it should be not only size of check box itself but also size and position of internal frame where text actually locales.

So SDC can represent its repository as BUI and CATALYST will understand it.
[YS] That is the idea the group is trying to follow. See for example the work on defining attribute values for datatype and restype.


2. Apparently SDC can try to represent repository layout in Windows Resource format, but usually this is very difficult, for instance Siebel Applets components looks way far from Windows resource.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC