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


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-inline message

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

Subject: RE: [xliff-inline] Teleconference - Tuesday Oct-11-2011 - Summary

XLIFF Inline Markup Subcommittee Teleconference

Every second Tuesday of every month at 14:00 UTC
7:00am PDT, 8:00am MDT, 10:00am EDT, 11:00 Montevideo,
3:00pm London, 4:00pm Berlin.

Teleconference meeting place:
Meeting ID: 408-998-929
You can use the following US phone number, or the VOIP option provided by GoToMeeting:
Dial 630-869-1010
Access Code: 408-998-929

Present: Yves, Andrew, Fredrik, Bryan
Regrets: Arle

The summary of our main items is here:

Draft is under SVN, here:

=== 1.5. Must allow to associate spans of content with metadata

We had the action item to propose some representation for the same example.
The original post is here:

ACTION ITEM: Yves to provide new representation tries based on the discussion.
-> Done during the meeting.

Andrew: Distinction: Metadata (comment) vs content properties (e.g. tem, trans/notrans)
Andrew: Not sure if we need different markup.

Fredrik: Distinct element may be useful at time.

--- Comments: at segment-level or at span-level?
Andrew: Metadata for comments: who/when/etc. -> more difficult with general pattern.
Fredrik: Maybe tools need to follow a pointer anyway?
Fredrik: Both segment-level and span-level would be useful

Andrew: Maybe say comments are 1st class citizen. And then even define the info set.
Then ref would work.

Bryan: Is this a question of two competing guiding principles: need to not allow 
more that one way to do something vs. a need for clarity?

Andrew: comment outside <source>/<target> with pointer.
Fredrik: elegant.
Yves: Allow for graceful degradation.

--- Translate:
We want to use the same pattern/terminology at the unit level too.

Andrew: What about overlapping info?
e.g. Term that is no-trans?
2 elements, or one with two attributes?

Fredrik: 2 I think
Andrew: Maybe <mrk> with a translate attribute (optional, and set to yes by default)

Is translate important enough info to be in <mrk>?
Seem yes and it fits the pattern.

--- Term:
All think generic mrk seems fine.

Fredrik: We need to make sure attributes are define clearly for each function.
Not easy to do with schema.

How about where that info goes? Source, target, both?
For example terms, trans: should go to both: -> allows to validate.
Comments: may be on one of them.

Maybe sometime for implementation notes, or profile for different usage of XLIFF.
-> Processing expectations.

Andrew: Do we need link between <mrk> in source and target? (e.g. term)
An optional id then, just used for linking.

Resulting element:

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

--- bidi as one of the pre-defined inline markers (like no-trans, term, comment)?

Maybe Unicode characters.
May also need defaults at para-level.
Andrew, Fredrik: currently we use base para-direction and Unicode chars.

YS: Need to get more info on bidi best practices

Fredrik: one drawback with Unicode char: the editor must know about them otherwise it looks weird.
Maybe use <cp> to store bidi control? (Yves: reserved for invalid char) Or NCR?
Using elements may lead to many of them.

Yves: Need to add bidi feature in TC list too.

=== Type of inline codes:

Should we keep or simplify the current 4 elements we have?

- merge <sc>/<ec> into <ph> with attribute?
- eliminate <pc> or not? (this would cancel requirement #17)

Fredrik: Removing <pc> would simplify things.
Andrew:  In general we need a lossless mapping with 1.2. Specifically for <pc>: need to try. Using a single code looks enticing, but not sure.
Yves: Not sure either, see pros/cons in both.
We'll have to decide soon with a ballot.

Fredrik asked for clarification on Bryan's example here:

Bryan: I was not proposing <pc> as an alternative to pairs, but to illustrate what I said above.

=== 1.16. Inline codes should have a way to store information about the effect on the segmentation

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

Skipped for lack of time.

=== Any other business



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