Re: Summary of I18N discussion in HTML WG today

On Mon, Nov 19, 2012 at 8:08 PM, Phillips, Addison <addison@lab126.com>wrote:

> Hello Cameron,****
>
> **
>

Hi Addison,


> **
>
>
> 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.****
>
> ** **
>
> AP> You’re correct. However, you probably want the other information in
> the language tag when formatting a date control anyway. Setting the
> calendar to (for example) the Islamic calendar is just one bit of
> information you need to achieve correct formatting. You also need the
> language to use, the specific regional customs (first day of week,
> abbreviation formatting, week numbering, etc.) to use.****
>
> **
>


CJ> I understand the scope of @lang with regards to the whole element
consisting of attributes and any content model, but i wonder if there is
actually a need for intra-element localization? The element seems like a
suitable level of granularity, otherwise each attribute or attribute set
would require another localization option.


**
>
> AP> Perhaps this would be a reason to change from calling it @calendar to
> something slightly more generic, like, say, @format?
>

CJ> I'm interested in maintaining the @lang attribute for structural markup
and deferring formatting as a presentational customization through CSS. The
:lang pseudo class is already available which is a nice intersection rather
than introducing new structural markup, and i can see some simple CSS
properties being capable of controlling the formatting based on the CLDR.


> ****
>
> ** **
>
> 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.****
>
> ** **
>
> AP> Richard’s point is that @lang is supposed to declare the language of
> the content and it applies to the whole of the element. What we are doing
> here is using an attribute to cause the user-agent to format some content
> for us and this might apply only to the one specific thing (the
> presentation of the calendar itself).
>


CJ> Yes, but i think looking at this specific case of an <input
type="date">, the calendar should be included within the scope of the whole
element and its declaration.

CJ> The multi-language use of elements can be see to be a more divergent
use case than the use of @lang for acquiring inherent localization
information.


> ****
>
> ** **
>
> AP> When Mark and I started our work on the current BCP 47, one of our
> precepts was that a language tag and a locale identifier are the same thing
> and want to be interchangeable. The addition of the Unicode Locale
> extension allows language tags full expressiveness in this regard and, when
> this issue was first raised, my reaction was along the lines of: “the
> language attribute is a perfectly effective vehicle for conveying both the
> language of static text in an HTML document and for conveying the locale to
> use when formatting content inserted into that document.”****
>
> ** **
>
> AP> When we discussed this in the WG call, though, Richard made the point
> that he is making in this thread: that there may be times when you want to
> separate a particular static text declaration from the locale formatting
> used in the control.****
>
> ** **
>
> AP> Richard goes on to make the point that, in the absence of an @calendar
> value, the @lang ought to control the format of the calendar. That is, each
> of these three fragments has the same result for the calendar (assuming no
> intervening @lang values):****
>
> ** **
>
> <html lang=”de-u-ca-islamic”>****
>
> …****
>
> <input>****
>
> ** **
>
> ---****
>
> <html>****
>
> …****
>
> <input lang=”de-u-ca-islamic">****
>
> ---****
>
> ** **
>
> <html>****
>
> …****
>
> <input calendar=”de-u-ca-islamic”>****
>
> ** **
>
> AP> … and, as Richard points out, that allows for the @lang to have one
> value while the @calendar does something else:****
>
> ** **
>
> <input type=date lang=de calendar=ar-u-ca-islamic title=”Abfahrtsdatum“><!--
> Arabic calendar with German title -->****
>
> ** **
>
> AP> A good analogy for what Richard, I think, is looking for is the
> proposal we had about being able to have an ‘attrdir’ to set the base
> direction of an attribute separately from that of the element. In that
> case, you want to be able to do something like:****
>
> ** **
>
> <p dir=rtl alt=”english explanation here” attrdir=ltr>HEBREW TEXT HERE IS
> RTL.</p>****
>
> ** **
>
> AP> … in which the direction of the attribute is different from the
> direction of the element’s contents. It is a rare case, but equivalent.
> (It’s such a rare case that we didn’t end up adding @attrdir to HTML).
> Question is whether it is appropriate for language/locale.****
>
> **
>


CJ> I see the example but i'm unsure of the approach.

CJ> If this didn't pass for @attrdir, i'm not sure it should pass here
where it would introduce more complexity only for a speculative edge case.

Thanks,
Cameron Jones

Received on Wednesday, 21 November 2012 12:42:08 UTC