- From: Felix Sasaki <fsasaki@w3.org>
- Date: Wed, 17 Apr 2013 11:10:56 +0200
- 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.
Felix
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