Hi Yves and Christian,
Thank you very much.
Yes, I checked HTML5 categorisation before having the initial
list. section was one example I borrowed name from it. What I
have found here and there was all major types of mark-up language
instances such as HTML, DITA and DocBook ( Categories
of Elements in DocBook ) have their own categories.
I thought It would not be too realistic for XLIFF to follow all
such categories. And the purpose of having type attribute in
XLIFF wouldn't be exactly same as having category in each
doctype's specification.
IMHO, type in XLIFF should be a useful hint to translators and
to CATs. So, the question I had was, what can translators/CATs do
according to the type value. I thought the tools (people) could
apply different level of QA priority/task and different quality
expectation depending whether the type of the in-line element is
for formatting or for linking to external/internal resources.
Example cases)
fmt type was to target formatting
elements. Missing or incorrect positions of these elements may
not have large impact on overall quality.
quot (or 'island' in Oracle's
terminology) type was to target elements with a floating text
or a long book title that must be translated as a group.
link : Anchors. Usually its position and
value are very critical
...
jung
On 01/10/2012 13:49, Yves Savourel
wrote:
Hi Christian,
Good pointers.
Looking at those, do you have a
list of possible values that would complement what Jung came
up with?
Cheers,
-yves
From:
[ mailto: ] On Behalf
Of Lieske, Christian
Sent: Monday, October 01, 2012 5:58 AM
To: Jung Nicholas Ryoo;
Subject: RE: [xliff-inline] XLIFF Inline Markup
Subcommittee Teleconference - Sep-11-2012 - Summary
Hi,
This
reminds me of categorizations that I have seen elsewhere …
1.
List
we compiled for ITS 1.0 (see http://www.w3.org/International/its/requirements/Overview.html#mapping );
example: elements associated with specific text styles
2.
Categories
used in the Darwin Information Typing Architecture (DTIA;
see http://docs.oasis-open.org/dita/v1.2/os/spec/DITA1.2-spec.html );
examples: basic, body, related links, typographic elements
3.
Categories
used in HTML5 (see http://dev.w3.org/html5/spec/single-page.html );
examples: sections, grouping content, text-level semantics
I
am always in favour of being knowledgable about what already
exists.
Cheers,
Christian
From:
[ mailto: ]
On Behalf Of Jung Nicholas Ryoo
Sent: Montag, 1. Oktober 2012 11:59
To:
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:
For additional commands, e-mail:
--
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
--
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
