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
|