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"
<> 

29/11/2002 13:00

To

XLIFF list <>

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

 

Attachment:
Matthew Lovatt.vcf

Description: Binary data