RE: issue-118 HTML ITS default behaviour from Mauricio del Olmo on 2013-02-22 (public-multilingualweb-lt@w3.org from February 2013)

From: Mauricio del Olmo <mauricio.delolmo@linguaserve.com>
Date: Fri, 22 Feb 2013 15:59:02 +0100
To: "'Felix Sasaki'" <fsasaki@w3.org>, <public-multilingualweb-lt@w3.org>
Message-ID: <00c701ce110d$26a57df0$73f079d0$@linguaserve.com>

Hi Felix.

>>We can modify the CAT tool filter

>I understand, but that modification is unrelated to ITS metadata, no?

No, the modification is for establishing the defaults only. The CAT tool filter rules are described with properties and regular expressions and are not modified “on the fly”.

>What I still don't understand: obviously the CAT tool cannot process ITS files, correct? So if somebody writes a rule like this

><its:translateRule selector="//@h:title" translate="no"/>

>It will always be overriden in a "non ITS processing step" by the CAT tool, right?

>So what are then the value of the ITS rules at all, if the CAT tool has ITS unspecific defaults ?

This type of situations are addressed in the preproduction (pre-translation) step. The Drupal XHTML + ITS to CAT-tool oriented XML engine is the component that reads the ITS rules and acts in consequence (extracts the content of the translatable nodes, adds the marks to block the inline parts that are specified as not translatable an so on).

I am preparing several Captivate presentations for Rome that will explain the whole process and I think will make it more understandable.

Best.

__________________________________

Mauricio del Olmo Martínez

Dpto. Técnico/I+D+i

Linguaserve Internacionalización de Servicios, S.A.

Tel.: +34 91 761 64 60 ext. 0421
Fax: +34 91 542 89 28

E-mail: <mailto:tecnico@linguaserve.com> tecnico@linguaserve.com

www.linguaserve.com <http://www.linguaserve.com/>

«En cumplimiento con lo previsto con los artículos 21 y 22 de la Ley 34/2002, de 11 de julio, de Servicios de la Sociedad de Información y Comercio Electrónico, le informamos que procederemos al archivo y tratamiento de sus datos exclusivamente con fines de promoción de los productos y servicios ofrecidos por LINGUASERVE INTERNACIONALIZACIÓN DE SERVICIOS, S.A. En caso de que Vdes. no deseen que procedamos al archivo y tratamiento de los datos proporcionados, o no deseen recibir comunicaciones comerciales sobre los productos y servicios ofrecidos, comuníquenoslo a clients@linguaserve.com, y su petición será inmediatamente cumplida.»

"According to the provisions set forth in articles 21 and 22 of Law 34/2002 of July 11 regarding Information Society and eCommerce Services, we will store and use your personal data with the sole purpose of marketing the products and services offered by LINGUASERVE INTERNACIONALIZACIÓN DE SERVICIOS, S.A. If you do not wish your personal data to be stored and handled, or you do not wish to receive further information regarding products and services offered by our company, please e-mail us to clients@linguaserve.com. Your request will be processed immediately.”

__________________________________

De: Felix Sasaki [mailto:fsasaki@w3.org]
Enviado el: viernes, 22 de febrero de 2013 14:18
Para: public-multilingualweb-lt@w3.org
Asunto: issue-118 HTML ITS default behaviour

Hi Mauricio, all,

this is now
https://www.w3.org/International/multilingualweb/lt/track/issues/118

Am 22.02.13 14:06, schrieb Mauricio del Olmo:

Yes, of course.

We can modify the CAT tool filter

I understand, but that modification is unrelated to ITS metadata, no?

to adapt it to this defaults. The CAT tool filter is specific for this project, part of the solution and will be documented.

What I still don't understand: obviously the CAT tool cannot process ITS files, correct? So if somebody writes a rule like this

<its:translateRule selector="//@h:title" translate="no"/>

It will always be overriden in a "non ITS processing step" by the CAT tool, right?

So what are then the value of the ITS rules at all, if the CAT tool has ITS unspecific defaults ?

Best,

Felix

Best,

__________________________________

Mauricio del Olmo Martínez

Dpto. Técnico/I+D+i

Linguaserve Internacionalización de Servicios, S.A.

Tel.: +34 91 761 64 60 ext. 0421
Fax: +34 91 542 89 28

E-mail: <mailto:tecnico@linguaserve.com> tecnico@linguaserve.com

www.linguaserve.com <http://www.linguaserve.com/>

__________________________________

De: Felix Sasaki [mailto:fsasaki@w3.org]
Enviado el: viernes, 22 de febrero de 2013 14:01
Para: Mauricio del Olmo
CC: public-multilingualweb-lt@w3.org
Asunto: Re: ACTION-447: Make a batch transformation of the test suite to xliff

Am 22.02.13 13:32, schrieb Mauricio del Olmo:

Hi Felix.

In our case, the final behavior for the standard HTML attributes (alt, title, summary) is given by the rules defined in the CAT tool XML-HTML compatible filter.

This filter has defined that, by default, the attributes that are expected to have translatable content will be unblocked and therefore editable by the translators/reviewers.

Hope this clarifies this case in our localization workflow.

It clarifies things - but it's a bit strange: you implement ITS metadata, but when assume ITS unrelated defaults later in the workflow.

I think the minimun we should do is to align the various "default" behaviours - ideally with HTML5

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21085

Best,

Felix

Cheers.

__________________________________

Mauricio del Olmo Martínez

Dpto. Técnico/I+D+i

Linguaserve Internacionalización de Servicios, S.A.

Tel.: +34 91 761 64 60 ext. 0421
Fax: +34 91 542 89 28

E-mail: <mailto:tecnico@linguaserve.com> tecnico@linguaserve.com

www.linguaserve.com <http://www.linguaserve.com/>

__________________________________

De: Felix Sasaki [mailto:fsasaki@w3.org]
Enviado el: viernes, 22 de febrero de 2013 13:09
Para: Yves Savourel
CC: public-multilingualweb-lt@w3.org
Asunto: Re: ACTION-447: Make a batch transformation of the test suite to xliff

Thanks a lot for your replies, Yves and Fredrik. You nearly convinced me. Also, we should probably make sure that the outcome of
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21085
with the rule set.

Why I wrote "nearly": in the below you write about HTML5 (and its successor, I assume) - but what about XHTML and the other HTML flavours? I am having here again the Linguaserve workflow in mind. Do we then require (or suggest via SHOULD) Linguaserve to process against the default rule set in the XHTML workflow?

Also, a detail: the rules would have no influence on precedence and overriding, etc. right? - they are kind of assuming that each HTML element has an "invisible linked or external rules file" - which has the lowest precedence compared to other rules, but a higher one than inheritance? E.g.

the inner span would be overriden by the

Taken from
http://www.w3.org/TR/xml-i18n-bp/#relating-its-plus-xhtml

Best,

Felix

Am 22.02.13 03:13, schrieb Yves Savourel:

All good points Felix,

see inline...

OK ... but in the example below Fredrik said that Okapi specifies
keywords to be translatable as a default. Can we expect that this is a default
for all HTML filters?

That's what we have in our default currently (after all keywords are translatable...)
But it should be whatever the WG decide should be the default rules.

And related: Fredrik wrote "One of the default global html5 rules (in Okapi)
specifies <meta name="keywords"…’s content to be translatable".
Is this really a global rule (which somebody who knows where it is stored
could modify), or a default, non ITS rules based processing?

In our case it's a real rule.
(See http://goo.gl/GRIk3 we have actually 2 sets: the 'strict' one is used for running the test cases)

But does it matter? The bottom line is that the behavior of a processor that says "I support the HTML5 default rules" is the same, whether it is realized by internal rules or hard-coded statements.

Also, would the link be to a rules file in the spec or in the wiki
(so that more easily it could be updated)? For the need to do that see e.g.
here: HTML5.1 will have new elements, e.g.
https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html
and we state we are covering HTML5 or its sucessor with ITS2.

Mmm... I guess it should be in the BP which can be updated.

Also ... in the example below two data categories are processed by
Okapi: Translate and Domain. What do we expect from a tool that
only implements domain, with regards to the defaults of data
categories not being implemented?

They just ignore the rules they don't implement, just like for any other rules file.

And asking again (I may have missed the answer, in that case sorry
for that): why was this not needed for ITS 1.0? See
http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2013Feb/0159.html
("what I still don't get" part).

My (current) 2 cents:

We never dealt with HTML in the ITS 1.0 specification.
The reference to the XHTML rules is just an 'example', like for DITA, TEI, DocBook, etc.

In 2.0 an ITS processor that support HTML5 is currently only having a very limited expected behavior (id, lang, etc.) but there is nothing in the specification saying for example that title attributes are translatable.

Sure we can say each filter has to complement the 'raw' behavior with its own set of pre-defined rules. But such rules affect how local markup will be processed. So we would end up with a single HTML5 document marked up with ITS info that will have two different outputs with two different tools as each tools would set its own defaults.
By providing at least a default set of rules to complement the 'raw' behavior, we provide the authors with at least a base for their local markup.

cheers,
-yves

Received on Friday, 22 February 2013 14:59:39 UTC