RE: [xliff-inline] XLIFF Inline Markup Subcommittee Teleconference - Summary (amended)

[Yves Savourel <ysavourel@enlaso.com>]

XLIFF Inline Markup Subcommittee Teleconference - Summary

Present: Yves, Fredrik, DavidW, Christian
Regrets: Arle


The summary of our main items is here:
http://wiki.oasis-open.org/xliff/OneContentModel/Requirements

Latest draft is here:
See http://tools.oasis-open.org/version-control/svn/xliff/trunk/xliff-20/xliff-core.pdf

ACTION ITEM: All to start looking at draft spec part for the inline parts: the draft text is there now, still under construction and incomplete, but initial feedback would be good.


=== Annotations representation
(req 1.5: Must allow to associate spans of content with metadata)

Current proposed representation:
http://lists.oasis-open.org/archives/xliff-inline/201110/msg00013.html

<mrk [id='id'] type='type' [value='some value'] [ref='someId'] [translate='yes|no']>...</mrk>


--- Splitting mrk:

Solution currently: use several <mrk> elements.

Yves had the action item to try implementation.
-> Some progress and a first remark:
Using duplicated well-formed elements instead of the same start+end markers as with <sc/>/<ec/> forces the implementer to do more work. Using start+end markers would allow the implementer to just re-use the same code as for <sc/>/<ec/>/<pc> with a few changes.

David: no thoughts yet
Fredrik: using s/e may use less markers (not against allowing both notations) How to indicate several mrk are the "same"? using same id may be dangerous?
Doesn't feel intuitive
David: same as for cloned inline codes
Fredrik don't think so, it's a bit different
David: but same as far as rebuilding original code
Fredrik: added code may have same nid but different ids Maybe this need to be different when within segment or not. Two mrk in the case of different segments, but s/e for when within same segment.
-> Yves to rework the draft for this.

=== splitting non-clonable

See Fredrik's notes:
http://lists.oasis-open.org/archives/xliff-inline/201202/msg00001.html

Fredrik: any notation, but with a way to undo it, so you can fall back to original notation.
Some tools don't handle well tags if not the same as they created.
Way: an optional attribute transformed='y/n' yes meaning it's not the original yes meaning it was changed.
-> Yves to try the implementation

For non-clonable:
Case of "cats eat mice"
Just not possible. May be the spec could recommend to avoid using spanning non-clonable?


=== Validation/compliance

Christian had the action item to bring back the validation tool question to the TC.
-> still pending


=== Representation of editing hints

Need to have notation for 'permissions'

See latest email:
http://lists.oasis-open.org/archives/xliff-inline/201202/msg00000.html

proposed:
- canDelete="yes/no" default is "yes"
- canCopy="yes/no" default is "yes"
- canReorder="yes/no" default is "yes"

Christian: 1. I would switch to a different naming like "deletable". "canDelete" sounds more like the capability of a tool, not feature of markup.

Christian: 2. I wonder if the default for all should be "no". This would make things harder to break :-)
Fredrik: permissive default is "safer", force the developers to thing about why it's forbidden.

About a more general top-level default?
Fredrik: add complexity. If we have one, should be file and group with inheritance.

Christian:  As for general, file-level default, we may want to take up the ITS discussion again (not in the sense of having XPath expresssion in general rules), but rather having a central and a local notation mechanism.

Fredrik: nice to have feature.

Fredrik: maybe default could be set depending on the type of inline codes. Like <ph> may be deletable='no'.
David: default at the file-level may be useful

-> Yves to add section for this in spec.


=== Bi-direction markers

Several tools use Unicode characters in 1.2.
Goes against W3C recommendation but seems common practice.
-> need to know about other tools
-> ask for info to W3C
Sent (but not passed the W3C check yet).

Some reference material:
- http://www.w3.org/International/questions/qa-bidi-controls
- http://www.w3.org/International/wiki/BidiProposal

Fredrik: starting to understand motivation of W3C. Unicode markers are simple. But it means they are part of the text and that is 'wrong' text should translate into text not text + special chars.
May need to be able to specify dir of a tag.
Didn't change my mind yet, but see the reasons.

Christian: If I understand correctly, the motivation is that the Unicode bidi algorithm needs help from time to time (see http://www.w3.org/International/articles/inline-bidi-markup/Overview.en)

-> Yves to ping w3c again.


=== Codes and effect on segmentation
(req 1.16: Inline codes should have a way to store information about the effect on the segmentation)

Related email:
http://lists.oasis-open.org/archives/xliff-inline/201109/msg00005.html

Fredrik: don't see need to add anything to the inline codes for this.
But may want to add metadata about what rules were applies.

Christian: Is this different from ITS elementsWithinText?
Yves: think it's different, xliff is more like the result of elementsWithinText.

-> Yves to make sure we address this in specs.

Fredrik: any ITS-based tools?
Christian: Basic demo: http://fabday.fh-potsdam.de/~sasaki/its/
Yves: Okapi does it, SDL Studio, XTM, and others.
See also online early implementation: http://okapi.translate.com/Utilities/ITSTest.aspx


=== Representation of added codes

Need to clarify use of duplicated code.
e.g. why not re-use same code?
(See http://lists.oasis-open.org/archives/xliff-inline/201110/msg00021.html)

- by duplicating existing code
- by creating new code

Fredrik: a tools can't handle all types of existing codes. So merging new codes should be just for tools that are of the same family.
We could have list of 'addable' codes, but may make things much too complex.
Merger needs to know about the original format.
'addable' codes may be possible, but should probably be a module then.

Fredrik: started some doc on this.
ACTION ITEM: Fredrik to try to post his document about different cases for adding inline codes.


=== Plural form example:

Example of possible issue:
Java string: "There {0,choice,0#are no files|1#is one file|1"
And PO, Android, TS plural.

Action item: Yves to escalated the issue to TC.
-> See http://lists.oasis-open.org/archives/xliff/201201/msg00024.html
And its associated thread.
-> Conclusion seems to be: nothing specific needed at the inline markup level.



=== Any other business

--- maximum length issue.

None.

-end