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,
Nikolai
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'>
from
<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.