W3C home > Mailing lists > Public > public-html@w3.org > August 2008

Re: Translation control in HTML5

From: David Muschiol <david@david-muschiol.de>
Date: Sun, 3 Aug 2008 14:02:23 +0200
Message-ID: <a7150d730808030502n631695bbo78a37fbba5b5351a@mail.gmail.com>
To: "Doug Schepers" <schepers@w3.org>
Cc: public-html@w3.org

On Sat, Aug 2, 2008 at 10:19 PM, Doug Schepers <schepers@w3.org> wrote:
> 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

Hmm, that is true, indeed.  But we should not forget that ITS is an
XML technology, and mixing XML and HTML seems to end up in a
never-ending story of compatibility problems every time – I am just
thinking of SVG in HTML.  I do not want to spread FUD, but that was my
first thought…

But, way more important:  Some of the proposals suggested here in
public-html are incredibly simple.  I am sure that if you just tell
developers to put a <meta name="notranslate" content=".asdf, .foo">
into their <head> or to add a translate="no" to specific tags, many of
them would make use of these techniques and the quality of translation
results could improve significantly in a short time, provided the
implementors are diligent; whereas – if we are realistic – learning
ITS plus XPath is not an option for the masses.

Yes, I know, introducing yet another technique for i18n control
somehow means reinventing the wheel.  But I really think it is worth
the trouble in this case.

> * 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.

Indeed, that sounds interesting…

> 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.

Concerning this issue, I think I go along with you :-)

> 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.

I am not Ian – may I put my two cents in anyway?  As mentioned above,
I do not consider XPath an option for the masses of developers either.
 If I understand aright, what you are thinking of now is a flavor of
ITS with CSS selectors instead of XPath?  Well, that seems way more
practical to me than regular ITS with XPath, but I still think the
notation is pretty verbose, compared to the concise <meta
name="notranslate">.  And if we do not want our plans to fail,
simplicity has to be our primary goal.

In conclusion, I would still prefer simply introducing @translate and
<meta name="notranslate"> as this seems to be the solution that would
be accepted by most developers.

Received on Sunday, 3 August 2008 12:02:59 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:36 UTC