OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xliff] Updated XLIFF Open Issues


All:

I've attached the open issues report that we'll discuss at tomorrow's meeting.

Regards,
Tony
 
 
Tony Jewtushenko                   mailto:tony.jewtushenko@oracle.com
Sr. Tools Program Manager   direct tel: +353.1.8039080
Product Management - Tools Technology Team
Oracle Corporation, Ireland
Title: ID

XLIFF Open Issues Report Updated 16 Dec 02

 

Key:

Open Unassigned

Assigned - further action required

Assigned to Editor

Closed no further action required

 

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

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC