|
27
January 2003 � Vote will take place at 27 January 2003 meeting.� Voting will be limited to these 6
options:
Option
1: Siblings
Option
2: Restructure
Option
3: Embedded
Option
4: Combined
Option
5: Extended
Option
6: Do nothing - defer to future release
Chair
recommends Option 5
24
Jan 2003� - Option 5, submitted by
Doug
Extend
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'.
�
So
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
coord-x
coord-y
coord-cx
coord-cy
font = all 3 font values
font-name
font-size
font-weight
css-style
style
exstyle
�
Example,
�
<trans-unit
coord="#;#;183;272" font="Arial;2;normal"
reformat="coord-cx;font-name" ...>
�� <source>...</source>
�� <target
coord="#;#;181;272"
font="System;2;normal">...</target>
�� <alt-trans
coord="#;#;183;272" font="Arial;2;normal">
������ <target coord="#;#;180;272"
font="Arial Bold;2;normal">...</target>
������ <target
coord="#;#;185;272" font="Arial,
Helvetica;2;normal">...</target>
�� </alt-tran>
</trans-unit>
�
Parsing
the reformat list is fairly easy, even with XSLT, which has a limited set
of string functions.
�
This
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.
21
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.
14
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
in concept.
7
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
translatable
Proposals
1) A closed list of XLIFF standard attributes and
elements that may be modified during translation. E.G state, target
text
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
|