Re: ISSUE-118: HTML ITS default behaviour - starting point, ACTION-452

Hi all,

I have put Ankit, Philip and Thomas into the loop, since I think they 
have been silent on this topic, but are HTML "Translate" implementers. 
What are you thoughts on this?

Best,

Felix

Am 20.03.13 18:25, schrieb Phil Ritchie:
> I think we should align as much as possible with HTML and use the 
> power of ITS to override or modify that behaviour if required.
>
> Phil.
>
>
>
>
>
> From: Jirka Kosek <jirka@kosek.cz>
> To: Karl Fritsche <karl.fritsche@cocomore.com>,
> Cc: Yves Savourel <ysavourel@enlaso.com>, 
> public-multilingualweb-lt@w3.org
> Date: 20/03/2013 16:15
> Subject: Re: ISSUE-118: HTML ITS default behaviour - starting point, 
> ACTION-452
> ------------------------------------------------------------------------
>
>
>
> On 20.3.2013 16:13, Karl Fritsche wrote:
>
> > I couldn't find the discussion on the HTML5 list about the changes,
> > because I wanted to lookup, why the added the style attribute as
> > translatable. The other attributes would be fine with me and are mor or
> > less the same, we had in our list too.
>
> It's sometimes hard to track source of changes as not everything happens
> on mailing list or bugzilla. In this case I think that reason could be
> CSS content property which can contain natural language text.
>
> > The major mismatch between what we had in the wiki before and what is
> > the HTML5 default, is that script, style and del are translatable
> > elements by default. While there was some discussion about having del
> > element translatable, no one in our group disagreed about having script
> > and style elements not translatable. Maybe the HTML group didn't wanted
> > to have to many exceptions.
>
> As for Javascript there is no standard way how to deal with
> localization, source code usually contains text strings. This might be
> reason why <script> is translateable.
>
> > But I think we should have the same defaults like the HTML, otherwise
> > you could parse the translate attribute as ITS or as HTML attribute, but
> > than it would be more clearer to use its-translate.
>
> Yes, for HTML part of ITS we should align with HTML5 spec or if they are
> wrong convince them to fix HTML5 spec.
>
> > While for these defaults could be generated rules, there is still the
> > different behavior of the translate attribute. All translatable
> > attributes are translate="yes" by default in HTML, while in ITS its
> > "no". Also the only possibility in HTML5 to change translatable
> > attributes to "no", would be to at the element or parent element the
> > attribute translate="no". In ITS we say that the translate attribute
> > only influence elements, not attributes.
>
> We say this about general translate data category. But we can change
> rules for HTML binding of translate category.
>
> > Even with all these "problems", we should first decide how we want to go
> > forward with the HTML5 Defaults. If we want to use this only to generate
> > a global ruleset for a best practice document, then we could ignore all
> > these problems and say that you can parse a document in the ITS way or
> > in the HTML way. For this case I'm in favor to use another attribute
> > like its-translate to make this clear for everybody.
>
> We shouldn't introduce its-translate if there is translate already in
> HTML. If we think that HTML translate attribute is broken, we should ask
> for fixing. But having two almost same attributes doesn't makes any sense.
>
> > If we want to add these defaults as a normative section, we need to
> > think about how to deal with the different behavior, because otherwise a
> > translator don't know if he should use the ITS or the HTML way. One
> > possibility would be to use the HTML way, but then the behavior for only
> > this attribute only on HTML would be completely different to the rest of
> > the ITS. Which is even more confusing, I think.
>
> I don't think it's confusing. Current HTML5 behaviour can be easily
> described by rules so I think that HTML5 model fits ITS.
>
> > A possible solution would be to add a its-translate-mode attribute for
> > the <html>-element, where the content creator can select if he wants to
> > use the HTML or the ITS behavior. This would have a major impact on all
> > implementors, because they have to implement both ways. With this every
> > body can choose their way, how to handle this.
>
> Please lets not make this more complex then it has to be.
>
> > That said, I'm still in favor of having these defaults as a normative
> > section, even with the cutback to handle ITS in HTML differently than in
> > XML.
>
> It wouldn't be wise to have rules normative as HTML5.1 is still moving
> target.
>
>                  Jirka
>
> -- 
> ------------------------------------------------------------------
>  Jirka Kosek      e-mail: jirka@kosek.cz http://xmlguru.cz 
> <http://xmlguru.cz/>
> ------------------------------------------------------------------
>       Professional XML consulting and training services
>  DocBook customization, custom XSLT/XSL-FO document processing
> ------------------------------------------------------------------
> OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
> ------------------------------------------------------------------
>    Bringing you XML Prague conference http://xmlprague.cz 
> <http://xmlprague.cz/>
> ------------------------------------------------------------------
>
> [attachment "signature.asc" deleted by Phil Ritchie/VISTATEC]
>
>
> ************************************************************
> VistaTEC Ltd. Registered in Ireland 268483.
> Registered Office, VistaTEC House, 700, South Circular Road,
> Kilmainham. Dublin 8. Ireland.
>
> The information contained in this message, including any accompanying
> documents, is confidential and is intended only for the addressee(s).
> The unauthorized use, disclosure, copying, or alteration of this
> message is strictly forbidden. If you have received this message in
> error please notify the sender immediately.
> ************************************************************
>

Received on Wednesday, 20 March 2013 20:29:33 UTC