ID
|
Status
|
Spec
|
Topic
|
Class
|
Title
|
Summary
|
Proposed by
|
Original Proposal
|
Discussion History
|
|
1
|
Unassigned
|
1.1 Spec
|
Extensibility
|
Design
|
Extending
Attribute Values
|
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
|
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.
3 Dec - unanimous vote to remove from the spec.
Further action requried: remove from the spec.
|
John Reid
|
John
Reid's Proposal
|
Mark
Levins' Suggestion
|
|
3
|
Unassigned
|
1.1 Spec
|
Interoperability
|
Design
|
New elements "default" and
"defaults"
|
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
|
Unassigned
|
1.1 Spec
|
Interoperability
|
Design
|
Phase names in Alt Trans
|
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"
|
|
6
|
Unassigned
|
1.1 Spec
|
Interoperability
|
Design
|
reformat Element revisited
|
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
|
Unassigned
|
1.1 Spec
|
Interoperability
|
Design
|
Context-group "purpose"
recommended values
|
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
|
Unassigned
|
1.1 Spec
|
Interoperability
|
Design
|
phase-name as optional <alt-trans>
attribute
|
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
|
|