ID
|
Status
|
Spec
|
Topic
|
Class
|
Title
|
Summary
|
Proposed by
|
Original Proposal
|
Discussion History
|
|
1
|
Assigned to
Editor
|
1.1 Spec
|
Extensibility
|
Design
|
Extending
Attribute Values
|
10 December 2002 = Unanimous vote to use the 'x-'
mechanism for attribute value extension. .
Proposal for validation mechanism for
XLIFF files that have been customized. Three proposed alternatives are
proposed for the schema:
1. From Yves uses the 'union'mechanism
2. a new proposal from Christian which uses the 'redefine' mechanism. The
argument in favor of the 'redefine' mechanism is that it provides a way of
validating customized values and is more flexible, The argument for the
'union' mechanism is that it is simple and more easily implemented.
3. Shigemichi's "x-" proposal: to use a TMX style prefix for
any custom attribute. Danger here is that custom extensions for commonly
named attributes ie, "x-button", could result in ambiguity or
worse - invalid identification. Sugestion to extend with additional namespace
identifier was not met with some resistance.
|
Christian Lieske
|
Christian's
Proposal
|
sec 2.4
in WIP 1.1 spec
|
|
2
|
Assigned to
Editor
|
1.1 Spec
|
Interoperability
|
Design
|
Context Group
|
3 Dec - unanimous vote to remove from the
spec.
Original:
Further action requried: remove
from the spec.
XLIFF 1.1 Working Draft, Section 2.3,
paragraph 2 talks about the context-group element. In that section it talks
about the different purposes for the context information, i.e. TMs,
translators, etc. The final sentence refers to using PIs to indicate the
different purposes. However, we are no longer specifying the use of PIs and
we have never enumerated the purposes of context information.
|
John Reid
|
John
Reid's Proposal
|
Mark
Levins' Suggestion
|
|
3
|
Assigned to John Reid
|
1.1 Spec
|
Interoperability
|
Design
|
New elements "default" and
"defaults"
|
10 Dec 2002 : Mark
raised John Reid's suggestion of using <group> to store defaulted
values and adding the defaultable attributes to the group element. Tony
suggested closing out on the original proposal and not using XPath by
replacing the default strategy with <group>. John Reid volunteered to
redefine the proposal around new attributes of <group> for the next
meeting.
Original:
Amended Requirements:
R.1 a mechanism to allow defaulting for
XLIFF data categories
R.2 formal representation of data category
is secondary (i.e. the mechanism should
be applicable to attributes and elements)
R.3 mechanism should work for all XLIFF
data categories
R.4 location for defaulting information
is secondary (i.e. default in central
location, default at specific attributes or
elements, and default at all attributes
and elements is acceptable)
R.5 XPath should not be used to relate
default settings to the elements or
attributes to which they pertain
(let's call this 'target') These requirements boil down to 3 questions:
Q.1 What is defaulted?
Q.2 How is it defaulted?
Q.3 Where is it defaulted? Originally submitted proposal (which did
not meet R.5), answered the questions
as follows:
P1.A1 allow defaulting for any XLIFF
data category
P1.A2 use XPath to designate the targets
for default settings
P1.A3 use a new central element 'defaults'
Amended proposals which take into account
R.5 :
P1': like P1 but without XPath
The idea here is that each target
explicitly names the defaults which should
be used for it. From my understanding,
this is not really kosher, since for
example the way to identify relationships
(or 'targets')is a proprietary and not
very efficient one. XPath is the standard
for this. Accordingly, I would ask the
TC members to reconsider my
original proposal. P2: defaults are encoded at the level of
the 'group' element (John's proposal)
P3: defaults are encoded 'in the vicinity'
of the XLIFF element to which they
pertain (Mark's proposal)
todo:
a)define defaultable data categories Q.1
b)design a representation for default
settings (Q.2); this has include a way to
identify to which XLIFF data category a
setting pertains
|
Christian Lieske
|
Christian's
Proposal
|
Christian's
Amended
Proposal without XPATH
|
|
4
|
Assigned to John Reid
|
1.1 Spec
|
Interoperability
|
Design
|
Phase names in Alt Trans
|
10 Dec 2002: John outlined his most recent
proposal which required very little changes to the XLIFF specification on the
basis that it already provided enough support for tracking phases and
histories. Tony motioned for voting on John's proposal at the next meeting,
giving everyone enough time to digest the proposal and be happy with the
suggested additional attribute values.
Proposal:
Since the current phase information can be retrieved from the <target>
attribute I think we don't need phase-name attribute in the
<trans-unit> element and my proposal is to remove it from there.
Mark's additional suggestion for "reason" attribute:
Provide another required attribute in <alt-trans> "reason" to indicate the
reason why a given <alt-trans> is an alternate translation. A few
suggested values for such an attribute are 'TM Suggestion', 'MT Suggestion',
'Rejected-Inaccurate', 'Rejected-Spelling', 'Rejected-Grammar' and
'Rejected-Length'. List would remain open, but with a list of
suggeted values.
|
Mirek Driml
|
Mirek's
proposal
|
05
Dec- Mirek's Clarification
05 Dec - Mark's suggestion
adding "reason"
John
Reid's Proposal (10 Dec)
|
6 |
Assigned to Mat Lovatt
|
1.1 Spec
|
Interoperability
|
Design
|
reformat Element revisited
|
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
|
Mat Lovatt
|
Mat's
Initial Proposal
Mat's
Revised Proposal
|
Mark's
Comment
|
|
7
|
Assigned to Editor
|
1.1 Spec
|
Interoperability
|
Design
|
Context-group "purpose"
recommended values
|
10 Dec 02 : The proposal was unanimously approved. Original Proposal: Propose adding the following "purpose"
attribute values:
- location, The context-group is used to
specify where the term was found in
the translatable source. Thus, it
is not displayed.
- match, Specifies that the context
information should be used during
translation memory lookups. Thus, it
is not displayed.
- information, Specifies that the context
is informational in nature, indicating
for example, how a term should be
translated. Thus, should be displayed
to anyone editing the XLIFF.
Combinations of these values can be made
via the standard mechanism of XLIFF. Thus,
purpose="location;match" would provide both
location and TM matching contextual
information. The schemas for this are
detailed in the original suggestion URL
|
John Reid
|
John's
Proposal
|
|
|
8
|
Closed
|
1.1 Spec
|
Interoperability
|
Design
|
phase-name as optional <alt-trans>
attribute
|
10 Dec 02: After the discussion on issue 4, this item was deemed to be obsolete. Original Proposal: This was originally part of issue 4, but was split out as its
own issue on 3 Dec. meeting.
It was observed by Yves that we had no
naming convention for phase-name. Phase name
would have at least 3 distict uses within alt trans:
1. to identify a different suggestion from a TM,
2. to capture the evolution of translation during the
translation process, and
3. identify rejected translations.
There is no way of distinguishing these elements.
It was agreed that we look at phase-name attribute in
relation to this observation.
Proposal:
Add the phase-name attribute to the alt-trans as an
optional attribute. Following along with Yves's original
thoughts on this, the phase-name could be placed at the
<alt-trans> level for any <alt-trans> that has a <source>.
It would be placed in the target of any <alt-trans> that
does not have a <source>.
Example:
<trans-unit id="1" phase-name="5final">
<source>Cancel Report</source>
<target phase-name="4review">Annuler le Rapport</target>
<alt-trans reason="Rejected-Inaccurate">
<target phase-name="3trans">Annuler le rapport</target>
</alt-trans>
<alt-trans match-quality="50%" reason="TM-Suggestion" phase-name="2pretrans">
<source>Cancel All</target>
<target>Annuler tout</target>
</alt-trans>
</trans-unit> |
Yves / John Reid
|
Yves
observation
John
Reid's Proposal
|
|
|
9
|
Unassigned
|
1.1 Spec
|
Interoperability
|
Design
|
Attribute Enumerated Values
|
17 Dec 02: Discussion on listing all enumerated values for attributes in the specification (or not). At issue is whether these values are part of the specification or part of an external schema. |
Mark Levins
|
Mark's
proposal
|
|
|
10
|
Unassigned
|
1.1 Spec
|
Interoperability
|
Design
|
Whitespace / List item delimiters
|
17 Dec 02: Multiple attribute values (lists) and valid separators – not certain if legal to use “;” or other delimiters, appears that “ “ whitespace is recommended by W3C, but this does not Preclude using “;” or “,”. |
Mark Levins
|
Mark's
Initial Observation
Doug's
Suggestion
|
|
|
11
|
Unassigned
|
1.1 Spec
|
Interoperability
|
Design
|
TextContent Extensibility
|
17 Dec 02: Extensibility of the TextContent to allow non-XLIFF tags, for example XHTML tags |
Doug
|
Doug's
Proposal
|
|