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

Re: required radio buttons and checkboxes

From: Weston Ruter <westonruter@gmail.com>
Date: Wed, 23 Apr 2008 14:34:10 -0700
Message-ID: <fb8299e10804231434l4915cbebla387a92109cec523@mail.gmail.com>
To: "Olivier GENDRIN" <olivier.gendrin@gmail.com>
Cc: "HTML WG" <public-html@w3.org>
These are all good points, and I understand the difficulty of getting all of
the browsers to include translated labels for every language. It would be
the ideal, though, wouldn't it?

What if the HTML5 Forms specification defined named entities (or some other
key-value mechanism) for all of the button labels and error messages with
their default English values? There could then be a public repository of
translated default labels that browsers could download and cache if they
didn't already have translations for the necessary language. So if I have a
browser localized for Argentina, and I come to a page that is @lang=ar, and
if the browser doesn't already have translations for Arabic, then the
browser would download the translations from the public repository of
language translation files for HTML5 and use the downloaded translation
strings in the Arabic document.

Another idea is to define the translation strings in a new DOM interface
which could be inherited by HTMLInputElement and the like:

interface Localizations {
>       attribute DOMString submitLabel = "Submit";
>       attribute DOMString buttonLabel = "Button";
>       attribute DOMString msgRequired = "You must provide a value.";
>       ...
> }

These values could be overridden via scripting for the entire page by
something like HTMLInputElement.prototype.submitLabel = "Proponer"

Or error messages could be customized for any element by setting the
property directly: email.msgRequired = "El email es necessario."

I am not exactly sure how an element's Localizations interface would be
overridden with another Localizations interface for elements within the
context @lang being supplied, or how to globally define with scripting what
the localizations should be, unless there was some kind of global Language
interface exposed.


(Yes, could also be Localisations)

On Wed, Apr 23, 2008 at 12:27 PM, Olivier GENDRIN <olivier.gendrin@gmail.com>

> On Wed, Apr 23, 2008 at 4:57 PM, Weston Ruter <westonruter@gmail.com>
> wrote:
> > On Wed, Apr 23, 2008 at 7:34 AM, Olivier GENDRIN <
> olivier.gendrin@gmail.com>
> > wrote:
> >
> > > What about internationalisation/localisation of these error messages ?
> >
> > What if the spec recommended that the browser display internationalized
> > error messages based upon the @lang or @xml:lang of the INPUT element's
> > context? Similarly, what if the default labels for Submit and Reset
> buttons
> > were also localized based off of the language context?
> Imagine that I have a website build to learn a foreign language : the
> items of the forms will be in language A, but I wish to have error
> messages in language B, with a correct @lang attribute and a custom
> error message (a help message)...
> > I know this would require browsers to have a large language translation
> > table.
> And what if I want to build a website for a rare langage ? I have to
> submit tickets to the browsers makers to hope them to implement a
> language with perhaps 10.000 people speaking it ?
> --
> Olivier G.
> http://www.lespacedunmatin.info/blog/
Received on Wednesday, 23 April 2008 21:34:54 UTC

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