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] XLIFF Inline Markup Subcommittee Teleconference - Sep-11-2012 - Summary


Big apology for being so late.

Here is my first draft. There are several ways of categorising tags, but I tried to reduce as much as possible to have only a list of items meaningful to translation. Examples include tags from HTML5, which is expected to be in more matured status when XLIFF 2.0 is released. I did not give much attention to the types in grey.

We cannot have a definite classification for all tags. <address> by its nature, is not a formatting tag for example, but practically acts as a non-critical formatting tag at rendering moment. "type" is more to give a hint to translators/translation tools than defining grouping.

Type
SubType
Description Example
fmt
[Formatting] Majority of embedded elements would belong to here.
Generally loss of these in-line elements is not critical to translation. But some may be.
font, code, br, em, strong, small, big, i,b,u, dfn, samp, var, mark, span, ins, del, kbd, sub, sup, address, bdi, bdo, meter, br, center, strike, wbr
quot
In-line quotation. These should be translated as an independent group. Also a good hint to MT. q, cite (title of a work)
link
Link (Anchor). Loss of tags is critical to the quality of translated material. a, xlink, ulink
annot
Annotation. Providing additional information. abbr, ruby, time, acronym
bidi
Bi-Di related bdi, bdo
struct
List, Bullet point. Tables etc..
option, td, li, dt, dd, optgroup
section
Document Structure, Block h1, h2, h3, div, footer, header, div, p, pre, blockquote
embed
Embedded objects img, embed, video, object, audio, iframe
script
Dynamic scripts script
form
Form elements input, button
gen
Generic purpose or Uncategorized

Jung


On 11/09/2012 15:31, Yves Savourel wrote:
XLIFF Inline Markup Subcommittee Teleconference - Summary

Every second Tuesday of every month at 14:00 UTC 7:00am PT, 8:00am MT, 10:00am ET 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, Jungwoo, Fredrik, 
Regrets: Christian


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


=== Implementing F2F main changes

-- composite values for the type attribute Something like this:

type ::= <category>['/'<subcategory>]
<subcategory> ::= <authority>':'<value>

Or two attributes:

Like type and subType (or custType, or xType, or extType), with same values.

Need to define the values for the main category.

F: single attribute feels best solution to me.
Y: tend to agree.
J: single was what we agree in F2F

J will try to come up with an initial list
Y, F to try to do the same.



=== Bi-directionality details

Done in schema, specifications and test implementation
(only dir in data is missing in test implementation).

Y: Nothing new. Will work on getting the missing dir in data
F: Had a quick look at current draft and it looked ok



=== Annotations representation

ACTION ITEM: yves to work on implementation.
-> in progress

ACTION ITEM: Yves to edit the draft to reflect the sm/em change
-> Done.

Also: <note> has an id now, so it can be used with comment annotation.



=== Elements and Attributes Names

Time to start choosing final names for the inline markup.

See spreadsheet here:
https://docs.google.com/spreadsheet/pub?key=0Av8I1YVQlYmsdEwtZ0VEVmo5Y0ZLTndEcUlFMzZnZmc&output=html

Either enter suggestion in your column (add one if needed) (ask for the link to the editable table if you don't have it any more, or post an email with the suggestions)

ACTION ITEM: Yves to remind everyone.



=== Namespace?

We need to decide to which namespace the content markup should belong.

a- same as the core namespace
b- one separate namespace (but still belong to the core)
c- several separate namespaces (e.g. codes still belong to the core, but not annotations, etc.)

Y: prefer option a
F: like concept of separate ns in core, but see advantage of having it in the core ns.
Feel separate ns would make it easier for separate use. Using several namespaces for inline would not bring anything.
J: option a looks best 


=== Any other business

TMX has looked at our model a bit.

Y: max size feature?
F: working on it. It would add an additional attribute in inline markup, as separate module.

-end





---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-inline-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-inline-help@lists.oasis-open.org




--
Jung Nicholas Ryoo | Principal Software Engineer
Phone: +35318031918 | | Fax: +35318031918 |
Oracle WPTG Infrastructure

ORACLE Ireland | Block P5, Eastpoint Business Park Dublin 3

Oracle is committed to developing practices and products that help protect the environment


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