Re: Translation control in HTML5

Hi Doug, all,

see two additional comments marked with >FS below.

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.
>FS see another argumentation against the overlap of lang and Translate at
http://lists.w3.org/Archives/Public/www-international/2008JulSep/0030.html
giving some data & perspective from localization.


I do note that ITS [1] uses XPath selectors, for which Ian Hickson has a 
stated dislike.
>FS: ITS has the global (with XPath) and the local (with the "its:translate" attribute) part.
If people want to use the latter, we would have no problem and an HTML "translate" attribute could easily
be mapped to ITS, via XPath
http://www.w3.org/TR/its/#associating-its-with-existing-markup
or some other means.
Felix

 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 Sunday, 3 August 2008 06:10:44 UTC