W3C home > Mailing lists > Public > public-multilingualweb-lt@w3.org > April 2013

Re: [ACTION-487][ISSUE-97][ISSUE--118] HTML5 Defaults

From: Felix Sasaki <fsasaki@w3.org>
Date: Wed, 17 Apr 2013 11:10:56 +0200
Message-ID: <516E6720.4020401@w3.org>
To: Jirka Kosek <jirka@kosek.cz>
CC: Yves Savourel <ysavourel@enlaso.com>, public-multilingualweb-lt@w3.org
+ 1 for this proposal.

It has three drawbacks:

1) Global rules are different than "real" defaults in terms of precedence.
2) If we go this way we won't be able to speficy "how to work with 
translate in HTML5" for "local only" implementations.
3) we will have a disalignment with the behaviour of HTML5 "translate" 
implementations in browsers.

Nevertheless the proposal has the advantages that there is a clear 
separation between how ITS "translate" behaves, that is, as it does 
currently, and how it should behave then applied to HTML content. And 
also that we don't need to introduce new concepts like "indirectly 
translatable". In the case of HTML processing you will need the rules 
file, and we can say, to accomodate for 3), that a global HTML 
implementation MUST process that rules file.

Another advantage would be for ITS2 that above approach keeps the door 
open to re-think the HTML processing, once we have gained implementation 
experience with ITS2, and once the HTML5 "translate" definition is stable.


Am 17.04.13 08:54, schrieb Jirka Kosek:
> On 16.4.2013 23:48, Yves Savourel wrote:
>> For example, a tool using just the defaults should be able to know that, both @value and @onclick become "translatable" again in the following code when p has translate='yes' (and @type remains un-affected).
>> <!doctype html>
>> <html lang="en" translate="no">
>> <head>
>>    <meta charset="utf-8">
>>    <title>Example</title>
>> </head>
>> <body>
>>   <p translate="yes">Text with <input type="button" onclick="alert('Hello Felix!')" value="a button"></p>
>>   </body>
>> </html>
>> I guess, the question is also how the ITS processors are suppose to work with HTML5+translate vs the normal ITS translate. If it doesn't take things like @onclick into account it's not really working.
> Hi,
> probably I'm missing something fundamental, but what's the real problem
> here? IMHO it's possible to create ITS rules which will mimick HTML5
> defaults in the same way as ITS processing is defined for many other
> formats. For example if value on input attribute should be translateable
> then following rules will do the trick:
> <!-- By default value is translateable -->
> <its:translateRule
> selector="//h:input[not(ancestor-or-self::*[@translate])]/@value"
> translate="yes"/>
> <!-- If the closest @translate attribute is yes then it is translateable -->
> <its:translateRule
> selector="//h:input[ancestor-or-self::*[@translate][1]/@translate='yes']/@value"
> translate="yes"/>
> <!-- If the closest @translate attribute is no then it is not
> translateable -->
> <its:translateRule
> selector="//h:input[ancestor-or-self::*[@translate][1]/@translate='no']/@value"
> translate="no"/>
> Yes, similar rules for HTML5 will take some length but they can easily
> cover behaviour described in HTML5.
> 					Jirka
Received on Wednesday, 17 April 2013 09:11:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:32:07 UTC