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
- From: Mark Levins <mark_levins@ie.ibm.com>
- To: Matthew.Lovatt@oracle.com
- Date: Fri, 29 Nov 2002 13:04:35 +0000
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
Attachment:
Matthew Lovatt.vcf
Description: Binary data
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC