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: [xliff] RE: Proposal: XLIFF used as an embedded schema (namespace) forcontent and software data


Title: Message
Tony, I will. THanks for letting me know where the posting should have occurred.
 
To all: I submitted the proposal below yesterday but sent it to the individuals on the list for which I had a name since I did not know where to submit the proposal, but here it is.

-Gérard

-----Original Message-----
From: Tony Jewtushenko [mailto:Tony.Jewtushenko@oracle.com]
Sent: Wednesday, May 01, 2002 10:47 AM
To: Gerard Cattin des Bois
Subject: Re: Proposal: XLIFF used as an embedded schema (namespace) for content and software data

Hi Gerard:   you shoiuld submit this to the xliff@lists.oasis-open.org email group,  so it appears in the XLIFF archives with all the other proposals and mails.

Do you want for me to forward?  or will you send it.

Regards,
Tony
 
 
 

Gerard Cattin des Bois wrote:

Microsoft recommended proposal for Xliff 1.1: make xliff tags a namespace that can also be used in software and content data files. This proposal is an add-on to Eric's proposal.

The idea is to make XLIFF an open model XML schema so that it can carry localization data and also the complete xml-based source file as context. <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

Think of an xml based help file or webpage that has its own schema that the localization process has no knowledge about. We call it the user domain schema. After the source authoring is done, the xml file is handed over to localization engineers/process to add localization directives.

Currently, most processes need to extract resources into a canonical form, such as a resource table. Xliff is the export format of that form. The problem with this is that the context information for the resources is lost. It is especially the case for content localization.

Imagine that we keep the source file as the main vehicle for transforming data. We insert localization directives directly into the source file but in xliff namespace. (It is technically possible to make the same document be valid for both the user schema and xliff schema.) Then, we can transfer the VERY SAME SOURCE FILE to the localizer without losing any context information. This way, a localizer can view the resources in two views. The original source file view and the table view for all trans units.

This way, content localization and software localization can be the same as long as they both are xml based files.

I rewrite the sample-xliff.xml file to illustrate the idea. The first file is dialog.xml, which is an imagined windows resource xml based format. Think of it as the XML based RC file. The second file is the mixed content from both the user schema and xliff schema.

You can see the clear separation of information from two schemas. An xliff element is mostly a child element to a user domain element to add localization directives. It can have references to the user domain data such as to tell xliff where the source text is located in the string table.

Regard,
-GérardGérard Cattin des Bois
Lead Program Manager, LocStudio Services
Windows Productivity Tools Team
gcatt@microsoft.com (425) 706-1592
Symptom and sign of Inner Peace: An unmistakable ability to enjoy each moment...

--
Tony Jewtushenko    mailto:tony.jewtushenko@oracle.com
Sr. Tools Program Manager   direct tel: +353.1.8039080
Product Management - Tools Technology Team
Oracle Corporation, Ireland
 



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


Powered by eList eXpress LLC