RE: ACTION-447: Make a batch transformation of the test suite to xliff

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.




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:  <> <> 


«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, 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 Your request will be processed immediately.”



De: Felix Sasaki [] 
Enviado el: viernes, 22 de febrero de 2013 13:09
Para: Yves Savourel
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
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.

<span its-within-text="no"><span> ...</span></span>

the inner span would be overriden by the 

 <its:withinTextRule withinText="yes"
  selector="//h:abbr | //h:acronym | //h:br | //h:cite | //h:code | //h:dfn
  | //h:kbd | //h:q | //h:samp | //h:span | //h:strong | //h:var | //h:b | //h:em
  | //h:big | //h:hr | //h:i | //h:small | //h:sub | //h:sup | //h:tt | //h:del
  | //h:ins | //h:bdo | //h:img | //h:a | //h:font | //h:center | //h:s | //h:strike
  | //h:u | //h:isindex" />

Taken from



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 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.
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
("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.


Received on Friday, 22 February 2013 12:33:11 UTC