[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]