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 Gérard,

> 1. We have already defined an XML internal representation of all
> winres format, which we hope to move to XLIFF at some point.
> That is one of our longterm goal thru our involvement with XLIFF.
> This includes all the formats currently used by NT, Office,
> Visual Studio, and so forth. But it is not XLIFF compliant,
> although it is XML-compliant. It is currently proprietary, and
> has internal support in rc and mc compilers for it. No current
> plans to make it available to the general public. If the XLIFF
> standard committee or Unicode will create a winre xml standard
> representation, that could change things. What is the intent and
> direction there Yves?

The intent: very basic, 'we' (Novell, AlchemySoftware, RWS, and I think a
few others) are developing in-house filters for Windows resources, and we
want to make sure we create 100% interoperable XLIFF documents.

The direction: I would hope that if this 'XLIFF profile for Windows
Resources' proves to be a good solution, at some point it would become a
recommendation of the TC.
[btw: Defining this common representation is not a new idea, it was
mentionned long time ago. We simply didn't have resources and incentive to
do it before (but now at least a few of us need it done)].

I guess, the TC needs to decide whether this effort should be 'official'. I
would think it should because there is no clear definition currently on how
to use all those winres-related attributes in the current specification, and
we have now developers creating XLIFF files with winres data. It's an
interoperability issue.



> 2. The winres.htm file you submitted does not account for embedded
> mc data, where typically you #include your .mc files with their
> messages (for win32 apps running as a service to others).

Definitely. This is just very early notes. There is a lot of things to look
at.



> 3. You recommend excluding XP. This is not a good idea since XP
> supports .net resources and now replaces the win9x home version
> of the os. By the time tools and businesses come to use any such
> xliff-formatted winres data, a great deal of the pc out there will
> be already running XP, which is an NT-light, rather than 9.x fatter
> and is a much better supported platform for Unicode application which
> can run natively on that platform.

Only "for now". But yes, you may be correct and we should possibly tackle
both at the same time. I'm simply don't have enough experience with .NET
resources to be able to say anything about how to represent them in XLIFF,
and whether it would be possible share a representation with win32-type
resources. But obviously other can help here.
It was a selfish statement of priority reflecting only RWS' most urgent need
:)

cheers,
-yves




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


Powered by eList eXpress LLC