Re: Summary of I18N discussion in HTML WG today

On Fri, Nov 9, 2012 at 4:36 PM, Richard Ishida <ishida@w3.org> wrote:

> 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.
>
>
The point i was making during the F2F is that valid BCP-47 requires the
preceeding language identifier before any extension attributes. Using just
an extension attribute is not valid BCP-47, it would not conform to the
parsing rules.



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


BCP-47 does not limit calendars to certain languages, so you can use
islamic calendar with any lanugage set. In that regard BCP-47 has complete
flexibility with regard to all localization identification.

I do not regard using the BCP-47 extensions as overloading, it is
utilization.


>
> 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
>
>
The most useful aspect of using the standard @lang attribute is that the
resolution process is defined within context of the elements, pragma, and
HTTP header. This allows for localization information such as calendar to
be set once on the most suitable level and with customary defaults.


Thanks,
Cameron Jones