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: **tecnico@linguaserve.com <mailto: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 
> <mailto: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 
> <mailto:clients@linguaserve.com>. Your request will be processed 
> immediately.”*
>
> *__________________________________*
>
> *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.
>
> <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
> 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.
>
>     (Seehttp://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
>
>       
>
>       
>