- From: Felix Sasaki <fsasaki@w3.org>
- Date: Fri, 22 Feb 2013 13:08:44 +0100
- To: Yves Savourel <ysavourel@enlaso.com>
- CC: public-multilingualweb-lt@w3.org
- Message-ID: <51275FCC.90808@w3.org>
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. > (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 12:09:13 UTC