[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: https://www1.gotomeeting.com/join/408998929 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: 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/ === 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: http://lists.oasis-open.org/archives/xliff-inline/201108/msg00027.html 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: http://lists.oasis-open.org/archives/xliff/201110/msg00043.html 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 None. -end
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]