January 2003 – Vote will take place at 27 January 2003 meeting. Voting will be limited to these 6
6: Do nothing - defer to future release
recommends Option 5
Jan 2003 - Option 5, submitted by
the possible values for the 'reformat' attribute to provide sufficient
control. XLIFF 1.0 presently uses ";"-delimited lists within
attribute values to store multiple values. The 'coord' attribute is an
example. It's value is actually four: "x;y;cx;cy", where
"#" can be used for 'don't care'.
let's extend 'reformat' the same way. Of course, we keep "yes"
and "no" for compatibility.
"yes" = all
format attributes may be changed
"no" = no
format attributes may be changed
...or a semicolon-delimited list of the following in
any order. If an attribute is listed, it means it may be reformatted.
coord = all 4 coords
font = all 3 font values
the reformat list is fairly easy, even with XSLT, which has a limited set
of string functions.
option is 100% compatible, both forward and backward. It does not affect
the structure at all. The only problem I can foresee an XLIFF 1.0 tool
having is if an invalid value for reformat is assumed to be "yes"
instead of "no" and allows some values to be changed that should.
That is, an XLIFF 1.0 tool could interpret a value of
"coord-cx;font-name" as "no" and not allow any of the
format value to change. Of course, if it assumed "no" instead of
"yes" it would not allow any changes. Since the default value for
'reformat' is "yes", I don't see either of the possibilities as
being too harmful.
Jan 2003 More discussion regarding the 4 options, but with informal “straw
poll” indicating overwhelming support for “Option 2 – Restructure”. However, it was noted that this option does not preserve backwards
compatibility with 1.0.
Jan 2003 There was much discussion over the benefits of each of Matt's
proposals (in essence, sibling elements to <source> and
<target>, or child elements to <source> and <target>)
with various advantages of each option pointed out, from backwards compatibility
to neatness, to shortcomings with <alt-trans> and workarounds for
these. We will discuss this for one
more week and vote at the next meeting on whether to accept this proposal
Jan 2003 Mat outlined his proposal (see discussion history) This will be
discussed on 14 Jan 2003
17 Dec 02: Mat to rewrite proposal in full as it would appear in the
specification, and group to respond with any questions or
issues. This will be done before the next meeting.
10 Dec 02: Matt tabled new suggestions for reformatting based on
previously sent email. Mark raised objections to instruction-based reformat
element that would require similar functionality to XPath and suggested
adding new specific elements for content that can be changed as part of the
translation process (e.g. font, coord, style etc) where these elements
could contain a boolean attribute to indicate whether they could be
altered. Matt agreed to further investigate this approach and create some
examples for the next meeting. Enda then raised the question of how this
would affect the 'default' discussion and Matt brought up the ability to
default a translation or translatable content. Matt agreed to try to factor
these two points into his investigation for the next meeting.
Simple, non-verbose, mechanisms to:
1. Indicate the translatability of any attribute/element, or XLIFF
standard values or extensions.
2. Store source and translated values for any structure marked as
1) A closed list of XLIFF standard attributes and
elements that may be modified during translation. E.G state, target
2) Each member of the list will either have before/after
placeholders or will be simply updated without keeping previous values
3) No other attribute/element may be translated unless
specifically marked as translatable
4) Provide place holders for any modified element