- From: Pablo Nieto Caride <pablo.nieto@linguaserve.com>
- Date: Wed, 20 Mar 2013 17:11:57 +0100
- To: Karl Fritsche <karl.fritsche@cocomore.com>
- Cc: Yves Savourel <ysavourel@enlaso.com>, <public-multilingualweb-lt@w3.org>
- Message-Id: <E681C2FF-16A1-4DBA-8520-4343668A3308@linguaserve.com>
Hi Karl, Comments inline! Cheers, Pablo. On Mar 20, 2013, at 4:13 PM, Karl Fritsche <karl.fritsche@cocomore.com> wrote: > Hi all, > > I added the new HTML5 declaration of the translate attribute to the wiki page. Where is this section exactly on the wiki? > 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. > > 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. It's weird because script and style are rarely translatable, perhaps it's like you say. > > 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. > > 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. > > 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. > > 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. > 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. > The good thing about having the defaults as normative section would be, that its easier to use and maybe many pages don't have to change their content, to use ITS. If the translator add these rules automatically, its way hard for the content producer to override special rules, specially if he is not aware of it. > > 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. > I agree, I think that having a good set of defaults is the way to go, I don't quite see the new attributes on the other hand. > Cheers, > Karl > > PS: Should we add www-international or html5 to the loop? > > On 27.02.2013 18:07, Yves Savourel wrote: >>> For the withinTextRule I would add everything which >>> HTML5 declares as Phrasing content [1]. >>> This would add to your list: area, audio, bdi, br, button, canvas, >>> command, datalist, embed, iframe, input, keygen, label, map, mark, >>> math, meter, noscript, object, output, progress, ruby, script, >>> select, svg, textarea, time, video, wbr >> Good point. >> feel free to update the wiki :) >> >> >>> Maybe even Flow content [2] which also includes ul, ol, li and h*. >>> This is complicated because, what is the starting point for the >>> text? If you choose div, then everything allowed in a div >>> should be in here, which is also a div. >> Not too warm about those. I think they are usually better when processed as not-within-text >> But maybe there are pople with more input on that. >> >> >>> What about a rulyRule for the ruby element? >>> <its:rubyRule selector="//h:ruby"> >> Okapi doesn't support Ruby, so we didn't have one. >> >> >>> What about a domainRule which points to the meta keywords >>> or dcterms.subject? >>> <its:domainRule selector="/h:html/h:body" >>> domainPointer="/h:html/h:head/h:meta[@name='dcterms.subject' or @name='keywords']/@content" /> >> There has been discussion on this several time. >> I'm still not sure what we decided as the BP. >> >> >>> I'm not sure about the following translateRule: >>> <its:translateRule selector="//h:del" translate="no"/> >>> <its:translateRule selector="//h:del/descendant-or-self::*/@*" translate="no"/> >>> Why this shoudln't be translated? The text has be deleted, but if >>> it is still there, it was intended and should be translated in my mind. >> I think it really depends on what you do with the content. >> In general localization is done after changes have been applied, so we don't see such tag deleted often. It's true they could need to be translated. but in general I would expect deleted text to be ignored by MT and translators: each word cost to translate: you want to avoid translating too much. >> >> >> Thanks for getting the ball rolling. >> -yves >> >> >> > > > -- > Karl Fritsche, Junior Software Developer > Tel.: +49 69 972 69 2604; Mob.: +49 1520 206 30 93; Fax: +49 69 972 69 199; Email: Karl.Fritsche@cocomore.com > Cocomore AG, Gutleutstraße 30, D-60329 Frankfurt > Internet: http://www.cocomore.de Facebook: http://www.facebook.com/cocomore Google+: http://plus.cocomore.de > Cocomore is active member of the World Wide Web Consortium (W3C) > Vorstand: Dr. Hans-Ulrich von Freyberg (Vors.), Dr. Jens Fricke, Marc Kutschera, Vors. des Aufsichtsrates: Martin Velasco, Sitz: Frankfurt/Main, Amtsgericht Frankfurt am Main, HRB 51114
Received on Wednesday, 20 March 2013 16:12:31 UTC