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


Subject: RE: [xliff] XLIFF and Windows Resources


Hi Yves,

the first comment on the doc:

Identifiers - Symbol Versus Value
As you mentioned, the symbolic identifier is more descriptive and useful for
localizer so I would prefer either to force symbol or allow both but not to
force only value.

Regards,
Mirek

-----Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com]
Sent: Monday, July 08, 2002 4:09 PM
To: XLIFF list
Subject: [xliff] XLIFF and Windows Resources


Hi all,

John: As I was going through my EXE and RC extractors and writing down
notes, I thought it would be easier to simply merged that with your
document. The result is attached.

I've replaced the original Novell's example by generic ones [so we could
ultimately provide both source and compiled files with the document].
I've remove the 'boilerplate' examples thinking they were redundant with the
real ones, and the file was getting big and a little bit cluttered (but we
could certainly put them back). I've added all the types of resources I
could think of, following the same approach you took with of the original
ones.

The text highlighted in yellow are comments, questions, unresolved issues,
etc. You'll see that they are many.

I'm wondering whether having a specialized namespace for all those
winres-specific attributes may be better? Some attributes are needed
regardless of the format, like restype or resname, but menu-option,
extradata, etc. may be not generic enough or too much. For example: MENUEX
requires 3 values not just menu-option, then if we use style and exstyle for
the two left, that changes the semantic of style and exstyle, therefore they
become more generic and maybe should be named to reflect that?

I'm not sure how we can reconcile this line of effort with Gérard's thoughts
on the topic. It would make sense to have a unique way of representing
winres data. But where is the boundary between representation of 'extracted'
data and representation of the data themselves? Is it even necessary to make
a distinction in the case of winres? But if not, then the same could be said
of any extractable format.
...Just thinking aloud.

Cheers,
-yves




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


Powered by eList eXpress LLC