Teleconference - Jan-11-2011 - Summary

[Yves Savourel <ysavourel@translate.com>]

XLIFF Inline Markup Subcommittee Teleconference
Jan-11-2011 (1/11/11)

=== 1) Admin

Minutes of previous meeting:
http://lists.oasis-open.org/archives/xliff-inline/201012/msg00006.html

Attendees: Yves, Andrew, Christian, Milan
Regrets: Lucia


=== 2) Discussion

--- Definition to add

- Action Item: Yves to add the definition in the wiki.
-> Done

- Action item: All non-present to look at it and comment if necessary.
No comments were made.
The definition is therefore done. And the item closed.


--- Invalid XML character representation

- ACTION ITEM: Andrew to research invalid XML chars representation in other formats (not necessarily translation-related).
Andrew did his action item.
Didn't find anything in the different standards. In the XML specification: it appears that XML 1.1 does supports those characters. So the solution could be to make XLIFF XML 1.1 based instead of 1.0.
Yves noted that 1.1 was possibly a dead standard rarely implemented.
Andrew noted that .NET: handled it.

Action item: Yves to research 1.1 status



--- Native data representation in inline

- ACTION ITEM: All to work on ideas for how to represent native data (inline or not, etc.)

Some start of discussion on the native data representation:
http://lists.oasis-open.org/archives/xliff-inline/201011/msg00001.html

- ACTION ITEM: Yves will try to get the list started.
Done: See http://wiki.oasis-open.org/xliff/OneContentModel/Comparison#SummaryofthePossibleOptionsforRepresentingNativeData for a start of a list.

Discussion:

Additional pros/cons where brought up.
And various representation for the 3rd option (native data outside the segment) were discussed.

<genericC>
 <text id='1'>text in bold</text>
 <nativeCode><b>%</b></nativeCode>
</genericC>

<source>
 <text><code id='1'>text in bold</code></text>
 <native><nativeCode><b>%</b></nativeCode></native>
</source>

<source>/<nativeSource> and <target>/<nativeTarget> at the same level.

Another possibility would be to use two options:
- simple case could use the attribute mechanism, while more complex ones would use the "outside" mechanism.

The outside mechanism has two possibilities:

- store locally (in trans-unit or in source/target)
- store globally (in the file)

Benefits in both cases (less if outside is local)

For outside ref: local or global?
- Andrew: global (easier to parse the file as a whole, re-use possible)
- Yves: local (more self-contained)
- Milan: local: (Splitting file, global make that difficult)
- Christian: local

Can at least share code between source/target when possible:

<trans-unit>
 <nativeCodes>
  <native id='1'>xxx</native>
  <native id='2'>yyy</native>
 </nativeCodes>
 <source><code id='1' ref='1'/></source>
 <target><code id='1' ref='2'/></target>
</trans-unit>

- ACTION ITEM: Yves to summarize the new options in the wiki and others to add/correct afterward.

Christian noted that looking at RDFa (RDF+attribute) could give us ideas.
Look also at http://www.slideshare.net/BenjaminAdrian/rdfa1



=== 5) Any Other Business?

- Anyone going to the Localization Word in June (Barcelona)?
(for possibly a face to face)
-> nothing sure for now.

- time change now that we have no one in Australia? -> 8am? 9am?
Yves asked if we could move to 8am. All attending were OK.

- ACTION ITEM: Yves to ask the rest of the group by email.


- Next meeting will be Feb-08.
-end