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] Reformat Suggestion for XLIFF 2.0


Mat & Mark & all:
 
In principle I'm opposed to adding requirements to the 1.1 spec or revisiting previously actioned upon recommendations.  However,  if implementation is truly is as straight forward as Mat indicates in his mail,  then perhaps we should consider it, since we originally removed the requirement from consideration due to reasons of complexity.
 
Hence,  I've added the item to the issues list for discussion at tomorrow's meeting. Mat can make his pitch at the meeting,  but the item can subsequently be quickly and easily moved out of consideration for 1.1 by a motion from the floor.
 
Regards,
Tony
 
 
 
----- Original Message -----
Sent: Friday, November 29, 2002 1:04 PM
Subject: Re: [xliff] Reformat Suggestion for XLIFF 2.0


Hi Matt,

Is the mechanism whereby the formatting attributes in <trans-unit> can be specified as the original values and overridden in the <target> not sufficient?

I think also that your proposal would also require moving all formattable-type information into dedicated elements to work, for example we would have to deprecate attributes such as 'coord' and create a coordinate element to fit within a <reformat> element. While I consider this to be in no means out of the question, I don't think we can use this approach for 1.1.

Regards,
Mark

Mark Levins
IBM Software Group | Dublin Software Laboratory | Airways Industrial Estate | Cloghran | Dublin 17 | Ireland
Phone: +353 1 7046676 | IBM Tie Line 166676




"Matthew.Lovatt" <Matthew.Lovatt@oracle.com>

29/11/2002 13:00

To
XLIFF list <xliff@lists.oasis-open.org>
cc
Subject
[xliff] Reformat Suggestion for XLIFF 2.0







All,
Despite the suggestion to postpone the reformat  element in 1.1, I have still been thinking about the issue
I have been doing more work with an xliff 1.0  implementation for Oracle, and the issue has required numerous untidy  workarounds.
 
This is therefore a new simpler suggestion for  2.0.
 
If it as simple as I think it may be, I have no  objections to reinserting into 1.1
----------------------------------------------------------------------------------------------------------------------
Problem
 
One problem overlooked in reformattable elements or  attributes, is that any structure that is changed during translation has no  placeholder to store the original value
 
Say we have some structure that is to be modified  during translation
 
For example
    x-value="xxx"
 
During translation this becomes
 
    x-value="zzz"
 
But we have lost the original value of  xxx
 
New Solution
The idea is that any  structure that may be translated is enclosed within a reformat  element
 
<reformat>
    <sourceval>
         x-value="xxx"
    <\sourceval>
<\reformat>
 
is translated to
 
<reformat>
    <sourceval>
         x-value="xxx"
    <\sourceval>
      <transval>
         x-value="zzz"
    <\transval>
<\reformat>
 
Any structure not enclosed within a reformat  element may not be changed during translation, except state etc.
 
If concerned about  wordiness
 
<rfmt>   
    <sval> x-value="xxx"<\sval>
      <tval> x-value="zzz" <\tval>
<\rfmt>
 
If a transunit has five reformattable elements, then we need five  <rfmt> elements. If we tried to put all into one element, we will have  problems matching up like with like.
 
An advantage is that any structure can be controlled in this way,  regardless of being XLIFF standard or an extension
 
This is just an Idea. I have not checked to see if  it is workable within the schema
 
Mat
 



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


Powered by eList eXpress LLC