[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XLIFF Inline Markup Subcommittee Teleconference - Jan-10-2012 - Summary
XLIFF Inline Markup Subcommittee Teleconference - Summary
Present: Arle, Yves, DavidW, Fredrik, Christian, AndrewP
The summary of our main items is here:
http://wiki.oasis-open.org/xliff/OneContentModel/Requirements
Draft is under SVN, here:
http://tools.oasis-open.org/version-control/svn/xliff/trunk/inline-markup/
(this will be replaced by DocBook version)
=== Farewell to Andrew
Andrew is leaving SDL and won't be in the TC/SC any more.
Many thanks for his participation and work.
Hopefully we'll get another representative from SDL soon.
=== Type of codes
Decision on what set of codes to use:
http://lists.oasis-open.org/archives/xliff-inline/201112/msg00015.html
Yves had the action item to create a ballot.
Ballot is here:
http://www.oasis-open.org/apps/org/workgroup/xliff-inline/ballot.php?id=2156
Result was to use ph,pc,sc,ec
Fredrik: Then we need a standard way to split and merge pc into sc/ec and back.
Issue to solve: for non-clonable pc.
Arle: I tend to agree with Fredrik, but I didn’t vote since I’m not a developer/implementer of this.
This is a serious issue.
Fredrik to start thread on this issue (how to split non-clonable pc?)
=== 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>
--- Overlapping mrk:
-> split them and merge them as needed.
May require an attribute to make the distinction between lone consecutive annotations and split annotations.
Yves had the action item to try implementation.
-> Not much progress.
--- annotation with only translate attribute.
What type value to use?
-> 'generic' with only translate attribute allowed in that case.
-> To implement
Yves: anyone else doing implementation tries?
Arle: Yves, can you supply some examples of what your implementation does so we can see it?
Yves: snapshot of Okapi has an output to xliff. See:
http://www.opentag.com/okapi/wiki/index.php?title=Rainbow_TKit_-_XLIFF_2.0
Christian: Someone at SAP looked at it from implementation viewpoint.
See also comment in the ballot.
Example of possible issue:
Java string: "There {0,choice,0#are no files|1#is one file|1"
And PO, Android, TS plural.
Arle: This is very similar to the variable text case I brought up in the general XLIFF list a while back.
Fredrik: may need to duplicate the segment
Yves: Need to look at representation guide for PO
(http://docs.oasis-open.org/xliff/v1.2/xliff-profile-po/xliff-profile-po-1.2-cd02.html#s.detailed_mapping.tu)
Action item: Yves to escalated the issue to TC.
Arle: It seems there would be multiple legitimate ways to handle cases like this. In some cases a technically minded translator could treat this as a segment and deal with the structure without escaping it. In others it would confuse a translator.
Fredrik: maybe if I find some time I could try <mrk> implementation.
--- Mrk and splitting:
Issue: This <mrk>is </mrk><pc><mrk>a </mrk><pc><mrk>broken</mrk>span </pc> with spans</pc> of text.
Solution 1: This <smrk/>is <pc>a <pc>broken<emrk/>span </pc> with spans</pc> of text.
Solution 2: This <mrk>is <sc id=1 />a <sc id=2/ >broken</mrk>span <ec id=2 /> with spans<ec id=2 /> of text.
Could convert type of tags if working directly with xliff.
Many tools can't do this. They expect exactly the same codes even if different one are equivalent)
One question: are those code representation interchangeable per specification?
Another question: can original data be represented different ways in the same segment?
--- Validation/compliance
Yves was to bring the question of schema version 1.1 vs 1.0 to the TC.
-> Done here:
http://lists.oasis-open.org/archives/xliff/201111/msg00044.html
One answer:
http://lists.oasis-open.org/archives/xliff/201111/msg00046.html
Yves had the action item to bring the question of the schema back to the TC.
-> Done. Seems the decision is XSD 1.0 + special validation tool
Fredrik: spec should use XSD 1.0, and extra tool used for compliance tests, not validation.
Yves: so conditional validation is not possible.
Fredrik: maybe 1.1 could be provided too for when it's approved.
Final 1.1 probably for this year.
Arle: No need for discussion here, but is there a good comparison anywhere of 1.1 vs. RNG + Schematron?
Fredrik: could try to add example of those constraints in the current schema.
Christian: not sure TC decided to have an extra tool for compliance.
Should we ask this to TC?
Fredrik: something like TMX validation (input + gold output)
AndrewP: think it's a good idea, but ambitious
Christian: +1, and also contentious
Maybe start to collect example of input/output
Arle: I agree with Andrew as well. The TMX tool created problems in many ways.
ACTION ITEM: Christian to bring back the validation tool question to the TC.
=== What about crc and assoc?
Those are not needed was last meeting consensus.
Yves had the action item to ask to TC if anyone is using crc or assoc and report on current status for those.
-> Done here:
http://lists.oasis-open.org/archives/xliff/201111/msg00051.html
Consensus would be to just drop then in 2.0.
Yves had the action item to double check presence of assoc.
-> Done did not find any examples.
=== Uniqueness of attribute names (added)
See:
http://lists.oasis-open.org/archives/xliff-inline/201112/msg00001.html
Yves had the action item to escalate the question to TC.
-> Done. Was decided to re-use names by context when needed.
Christian: on topic of easy of doc: should we follow example of ITS: one doc does it all.
Arle: But Oxygen now has ODD support.
=== Representation of editing hints
Need to have notation for 'permissions'
Current permission we thought about:
1: a code can be deleted
2: a code can be replicated
3: a code can be moved out of its original order
4 (possibly): a code can be moved outside its original parent span
All were to think about representation for hints.
See: http://lists.oasis-open.org/archives/xliff-inline/201111/msg00008.html
-> seems one attribute per "hint" would be the choice for most.
What defaults to use?
Skipped.
=== 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
Skipped.
=== 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: not thought about it yet.
Case of segmentation from the XLIFF more complex.
Maybe make the code as 'skippable' (can be ignored) or 'boundry'.
Christian: this is about info we keep on the element, or we keep on a central section (e.g. all mrk are sentence line boundries -> global vs local rules). Also this is about what we segment.
=== 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)
Skipped.
=== Any other business
None.
-end
---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-inline-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-inline-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]