- From: Doug Schepers <schepers@w3.org>
- Date: Sat, 02 Aug 2008 16:19:18 -0400
- To: public-html@w3.org
Hi, David- Nice summary, thanks. One quick note, inline... David Muschiol wrote (on 8/2/08 10:44 AM): > > – Thus, several people raised the question whether there are some > elements such as <code> and <kbd> that should not be translated by > default. [9] Whether such a convention makes sense depends on how > often these elements are misused on the Web, as Simon pointed out. > [10] Possibly, some statistic data could help us out? If it does not > break too much legacy content, I would strongly suggest defining clear > rules here. This would save authors of technical documents from > always having to specify <meta name="notranslate" content="code, kbd, > …"> (see below) or even <code translate="no">. [...] > – For page-wide translation rules, Simon suggested <meta > name="notranslate"> [11]. In its @content, CSS selectors specify > which elements are not to be translated. Not universal enough to > solve all our problems elegantly, I guess, but quite a useful idea > anyway. (I do not consider specifying <meta name="notranslate" > content=".notranslate"> on every page elegant.) [...] > To conclude, I think that @translate, language tag extensions, <meta > name="notranslate"> and defaulting <code>, <kbd> etc. to > translate="no" could all make sense parallely. Do you think it is > possible to reconcile all these solutions in HTML 5? Probabely too > many redundancies, hm? What do you think, which solutions should we > finally pick? (You see, I am of the opinion that careful authors > should definitely have the possibility to mark up content that should > not be translated.) ITS already addresses almost all these requirements: * discrete 'translate' attributes for per-element control of translation * default rules for a language, such that <code>, <kbd>, etc. are automatically not translated * the ability to link to a per-document set of rules that establishes custom rules (which could easily be used site-wide, so an organization would only have to write these rules once); this means that the <meta> tag isn't needed. The 'lang' attribute proposal overrides the existing functionality in a way that bears to much risk to breaking content, and doesn't offer any advantage I can see over the 'translate' attribute. I do note that ITS [1] uses XPath selectors, for which Ian Hickson has a stated dislike. Ian, is it possible that that is the reason you are reluctant to merely adopt the ITS syntax, despite its obvious suitability to the purpose? If it were to use CSS selectors, would you have any other objections to that proposal? It's important to be clear what we're really arguing about. [1] http://www.w3.org/TR/its/ Regards- -Doug Schepers W3C Team Contact, WebApps, SVG, and CDF
Received on Saturday, 2 August 2008 20:19:52 UTC