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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

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


Subject: [xliff] XLIFF Profiles


Hi all,

Just a note about the profile for Win32 Resources: Several people have
sent some comments and notes about it since during the past year. We
want to make sure to re-read throught them.
Here are some:
http://lists.oasis-open.org/archives/xliff-comment/200309/msg00018.html
http://lists.oasis-open.org/archives/xliff-comment/200301/msg00000.html
And I think there are a few more.

I'm also attaching below a note from Florian (Passolo) with additional
comments:

Cheers,
-yves



===================================================================

Hi all together,

please let me know who should get my comments about XLIFF in the future.

While reading the profile some comments came up I wuld like to share with
you:

1. I would recomment to make resname a required attribute for XLIFF-WinRes.
This information is available an necessary for for certain operations.

2. The first group level in a body should contain resources. Groups are used
to combine elements that should be processed equally (by adding
context-groups for example), to define resources and to define a hirarchical
structure (like in menus). Having resource definitions on a defined level
makes it easy for example to retrieve a list of resources in a file-element
without having to completely parse the XLIFF file. Context-groups could
still be placed in the resource groups.

3. StringTable should be handled equally for RC-Files and binaries. The more
abstract approach would be to have one String table per file (as you have it
in the rc file) and not to support the StringTable blocks which is just a
coding detail of complied string tables. resname should contain either the
'Symbol' or the 'String ID' (1-65536).

4. Message File. Does it make sense to support RC script case which just
gives a reference to the binary representation of the message file, but the
handling of the content is out of the scope of XLIFF. In this case the MC
file should be added to the XLIFF file perhaps as a separate file-element.
The sample of the compiled Message File makes sense.

5. GROUP_CURSOR, GROUP_ICON are resources only used in binaries. They are
used together with CURSOR and ICON resources. which are different in source
and binary form. In source form icons and cursors are the file forms of the
data types. In binary form the groups contain information about the diferent
resolutions and the compete icon/cursor data structure has to be calcualted
both from the group- and the cursor/icon resources. This is a very specific
format only of internal interest. GROUP_CURSOR, GROUP_ICON should be
ignored. If cursors and icons occur in a XLIFF file it should be in the
'normal' file form.

And here may be some corrections:
The XLIFF sample for accelerators (section 3.1) contains the id='3' two
times.
The mime type for cursor should be image/cur
In section 3.6.2 the XLIFF examples uses restype for resname.
DLGINIT Resources do also exist in binary files.
In section 3.1.6 Menu resources XLIFF representation the tast two
trans-Units should have id 5 and 6

I hope you find this feedback useful.

Best regards,
Florian



Florian Sachse

Managing Director
PASS Engineering GmbH
Remigiusstr. 1
53111 Bonn
Germany

phone: +49-228-697242
fax: +49-228-697104
email: fsachse@pass-engineering.com
web: www.passolo.com
egroup: www.egroups.com/group/passolo




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