RE: Summary of I18N discussion in HTML WG today

Hi Richard,

I agree with most of your argument, but am not sure I'm totally sold yet. Let me explain.

As we discussed at TPAC, the problem you're trying to get at is that @lang has historically be declarative: it is metadata about the content of an element (and its contained hierarchy). 

The question is whether that "declaration" extends to presentation generated by the browser. The date input is presented to the user as an implementation-defined date control (which might take the form of a calendar page or some other date-related form input field, although it might not). Page authors want to influence the appearance of that control to the extent the user-agent allows and generally want the presentation to be consistent with the language of the page itself (which, heretofore, has been the problem). So using @lang to determine at least the locale of the presentation seems reasonable.

I'm not opposed to adding @calendar to date. I'm not entirely sure that this should be a full language tag. UTS#35 defines keywords for calendars. It might be a better design for a calendar attribute to just take the values from UTS#35 without the overhead of a full language tag:

<input type="date" lang="de-u-ca-gregori" calendar="islamic"> <!-- presents an islamic calendar with German labels, ignoring the conflicting value in @lang -->

As opposed to:

<input type=date lang=de calendar=th-TH-t-ja-u-co-phonebk-x-private><!-- not sure what that does -->

I am somewhat opposed to the idea of adding a 'locale' attribute as a general way of controlling presentation generated by the user-agent because there is almost never a case where you want to the language the page and the language of agent-generated presentation (that is, a "date picker" control) to be different---it's confusing to people for there to be two declaration mechanisms. So for a general mechanism, I would prefer, I think for @lang to be both a declaration of the content language as well as controlling the presentation. Consider:

<input type="date" name="date2" lang="de" title="Erscheinungsdatum" /><!-- date picker wants to be in German, no? -->

What I wouldn't want to see is something like:

<!-- note that islamicc and Islamic are different calendars -->
<input type="date" lang="de-u-ca-islamicc" locale="ar-u-ca-gregori" calendar="islamic" title="..."> <!-- confusing -->

So I think this might be a desirable overloading. If you look at the following link (using Opera, since that browser actually implements a date control), shouldn't you get a date picker that has German labels? Arabic labels? I think I know which calendar should be used, but I can't be sure of the appearance. 

http://www.inter-locale.com/demos/iuc35/DateDemo.html


In most cases, the "page locale" can be used:

<html lang="de"><!-- lang can be declared anywhere, on html for illustration -->
...
    <input type=date><!-- German Gregorian calendar -->

And if a page author needs more control, they can have it:

<html lang=de>
...
    <input type=date lang=de-u-ca-islamic>

Or:

<html lang="de">
..
    <input type=date calendar=islamic><!-- german labels, Islamic rules -->

What's more, using @lang means I can do this:

<form lang=de-u-ca-islamic-co-phonebk><!-- all my controls use the same language, calendar and sort order! -->

Thoughts?

Addison


> -----Original Message-----
> From: Richard Ishida [mailto:ishida@w3.org]
> Sent: Friday, November 09, 2012 7:37 AM
> To: Mark Davis ☕
> Cc: Robin Berjon; HTML WG (public-html@w3.org); www-international@w3.org
> Subject: Re: Summary of I18N discussion in HTML WG today
> 
> On 02/11/2012 19:22, Mark Davis ☕ wrote:
> >  > with a caveat from Cameron that BCP47 does not have way of
> > indicating the Islamic calendar. He'll figure that out with Richard.
> 
> If I recall correctly, I got the impression that Cameron thought that
> BCP47 values could not be used with the calendar attribute - rather than that
> BCP didn't allow for calendar identification. Cameron please set me straight on
> that, if I'm wrong.
> 
> For the record, let me also mention why I was recommending a separate
> attribute rather than the lang attribute to give the locale of the date format for
> an input method.
> 
> One reason is that the lang attribute is always used to identify the language of
> the text within an element, and I feel that specifying a locale for a calendar is
> not the same thing.
> 
> A build on this reason would be where you have additional content which is not
> in the same language - let's say, for example, that the element that points to a
> calendar locale such as, say, ar-u-ca-islam has a title attribute also, and that
> the language of that attribute text is German - not common, but possible.  If
> you used lang to identify the calendar locale you would be (incorrectly)
> declaring the content of the title attribute to be arabic. If you have a lang=de
> calendar=ar-u-ca-islam you would be fine. This example illustrates the need to
> not overload the lang attribute, to my mind.
> 
> That said, I would happily agree that, if information from a calendar attribute
> was unavailable, the browser could *guess* the locale from information
> provided by a lang attribute.  But that would just be a fallback.
> 
> RI

Received on Friday, 9 November 2012 16:52:53 UTC