Internationalization Core Working Group Teleconference

Minutes and Agenda review

Action Items

close ACTION-46

<trackbot> ACTION-46 Dump charmod-norm and add disclaimer paragraph, dates, etc. so that we can publish an interim working draft closed

close ACTION-45

<trackbot> ACTION-45 Publish qa-personal-names for wide review closed

reopen ACTION-46

<trackbot> ACTION-46 Dump charmod-norm and add disclaimer paragraph, dates, etc. so that we can publish an interim working draft re-opened

so close on action 56

Change 512 to 1024 in the charset declaration article

Figure out how to keep alive open bugs for the html5 LC

Info Share

<scribe> ACTION: richard: send addison pisa conference materials as draft for IUC presentation [recorded in http://www.w3.org/2011/07/27-i18n-minutes.html#action01]

<trackbot> Created ACTION-60 - Send addison pisa conference materials as draft for IUC presentation [on Richard Ishida - due 2011-08-03].

Media Resources

http://lists.w3.org/Archives/Public/public-i18n-core/2011JulSep/0022.html

http://www.w3.org/TR/2011/WD-mediaont-api-1.0-20110712/

<scribe> ACTION: addison: raise MediaResources issues in tracker and forward to relevant WG [recorded in http://www.w3.org/2011/07/27-i18n-minutes.html#action02]

<trackbot> Created ACTION-61 - Raise MediaResources issues in tracker and forward to relevant WG [on Addison Phillips - due 2011-08-03].

HTML5 REVIEW

richard: polyglot
...

<r12a> http://www.w3.org/International/track/products/4

<r12a> http://www.w3.org/International/track/issues/58

<r12a> ISSUE-58

since UTF-16 is no longer allowed in polyglot documents, should close

close ISSUE-58

<trackbot> ISSUE-58 In-document declarations always useful closed

http://www.w3.org/International/track/issues/60

ISSUE-60

<r12a> ISSUE-60: Omit the either/or list

<trackbot> ISSUE-60 Omit the either/or list notes added

rewritten, so no longer issue

close ISSUE-60

<trackbot> ISSUE-60 Omit the either/or list closed

Mention lang and xml:lang

ISSUE-61

richard: done now. <meta> content language now non-conforming

close ISSUE-61

<trackbot> ISSUE-61 Mention lang and xml:lang closed

Case requirements

ISSUE-62

richard: done, considerably rewritten

close ISSUE-62

<trackbot> ISSUE-62 Case requirements closed

richard: went through the bidi list
... three remaining ones

http://www.w3.org/International/track/products/5

ISSUE-26

Please add support for rb

ISSUE-29

ruby code samples

addison: added to prep?

richard: no, reopened

ISSUE-30

Allow utf-16 meta encoding declarations

richard: on-going
... resolved "wontfix" by hixie
... good idea to reopen

addison: UTF-16 allowed in HTML documents but can't declare it

richard: BOM used to declare

addison: reopen it!

richard to open bug

ISSUE-32

rlo and lro attribute values

richard: "punt"

matial: don't see a lot of use for it; nice to have

close it

close ISSUE-32

<trackbot> ISSUE-32 rlo and lro attribute values closed

ISSUE-34

bdo element doesn't leave rendering up to presentation layer

close in favor of new issue

<r12a> http://www.w3.org/International/track/issues/34

close ISSUE-34

<trackbot> ISSUE-34 bdo element doesn't leave rendering up to presentation layer closed

http://www.w3.org/International/track/products/10

http://www.w3.org/International/track/products/12

ISSUE-76

Clarify 'preferred name' for encodings

http://www.w3.org/International/track/issues/76

richard: when ian says "preferred name" means preferred name in registry if it exists or name at top of entry
... the former is only 22 items
... link is missing here

comment accepted

ISSUE-76: comment accepted for HTML5 LC

<trackbot> ISSUE-76 Clarify 'preferred name' for encodings notes added

http://www.w3.org/International/track/products/11

ISSUE-72

BOM as preferred encoding declaration

richard: section that says how to identify encoding
... one option is BOM and it says "preferred"
... later there is a note that says we (our WG) recommends the <meta> element
... (and I started editing our article recommending against BOM)

addison: BOM is evil :-)

ISSUE-72: accepted for Polyglot LC

<trackbot> ISSUE-72 BOM as preferred encoding declaration notes added

ISSUE-73

Case sensitivity of lang

richard: lang in list of attributes that must be lowercase only
... becuase attributes handled case insensitive?

<r12a> http://www.w3.org/International/track/issues/73

addison: language tags themselves are case insensitive

richard: it's xml:lang that matters to xml processors

ISSUE-73: accepted for Polyglot LC

<trackbot> ISSUE-73 Case sensitivity of lang notes added

ISSUE-74

Remove Content-Language meta from polyglot

http://www.w3.org/International/track/issues/74

richard: all this wording about fallbacks
... so content-language is non-conforming in HTML5 and thus can't be used in polyglot
... so need to remove from polyglot
... 1. can't use C-L meta in polyglot documents (since non-conforming)
... 2. therefore remove mention of it from fallback description because irrelevant

ISSUE-74: accepted for Polyglot LC

<trackbot> ISSUE-74 Remove Content-Language meta from polyglot notes added

ISSUE-75

Section 11 is blank

non-I18N

personal/editorial comment

<r12a> http://www.w3.org/International/track/issues/75

<r12a> ISSUE-137

<r12a> http://www.w3.org/International/track/issues/137

html5 bidi support should be normative

richard: ian to add normative section on bidi rendering

http://www.w3.org/International/track/products/10

ISSUE-77

HTTP and defaulting to UTF-16LE

<r12a> http://www.w3.org/International/track/issues/77

If the HTTP header declares the file to be UTF-16BE, which I believe it can, and in which case a BOM should *not* be used, then I think that this would not be true. If the HTTP header declares the file to be UTF-16, then there must be a BOM, so I assume that this is a recovery mechanism if someone does declare UTF-16 in HTTP but omits the BOM. I'd think that some kind of error message would be in order though.

addison: seems straightforward

ISSUE-77: accepted for HTML5 LC

<trackbot> ISSUE-77 HTTP and defaulting to UTF-16LE notes added

http://www.w3.org/International/track/issues/78

ISSUE-78

The spellcheck attribute currently is limited to user-edited text. It would be useful to have some way of identifying content that should not be spellchecked in an editor or by an automated spellchecking service. It would seem most intuitive to use the same attribute for this, but more carefully distinguish between the case where the user agent is dealing with user editable text and non-user-editable text, if necessary.

addison: so a processing instruction for editing tools??
... i18n issue? or general?

felix: borderline between ITS and I18N and general
... think it's important

ISSUE-78: accepted for HTML5 LC

<trackbot> ISSUE-78 Spellcheck should work in editors notes added

ISSUE-79

Multilingual q quote rendering

http://www.w3.org/International/track/issues/79

It would be useful to add a note to this section to remind readers that the default characters used for quotation marks are set in the default stylesheet[1], and will vary depending on the user's locale and language preferences. But that users may need to override the defaults for text in a particular language, and that they can do so using the quotes property in CSS (http://www.w3.org/TR/CSS21/generate.html#quotes-specify).

addison: think this is a good comment

richard: there is a note that UA's should take language into account
... language of the UA

addison: but that's wrong... should be language of content

gwyneth: does it take into account spacing (such as french use of NBSP)
... CSS page doesn't indicate spaces

ISSUE-79: accepted for HTML5 LC

<trackbot> ISSUE-79 Multilingual q quote rendering notes added

ISSUE-80

Default rules for the quotes property

http://www.w3.org/International/track/issues/80

<r12a> http://www.w3.org/TR/html5/rendering.html#punctuation-and-decorations

"Rules setting the 'quotes' property appropriately for the locales and languages understood by the user are expected to be present." How are the locales and languages understood by the user determined? Is this related to the Accept-Language settings of the browser? I'm assuming that the requirement here is to provide a single default only per browser installation, rather than to provide defaults for text in various languages (which would be a nice plus). If

ISSUE-80: accepted for HTML5 LC

<trackbot> ISSUE-80 Default rules for the quotes property notes added

ISSUE-80: should apply rules based on the language of document

<trackbot> ISSUE-80 Default rules for the quotes property notes added

quote shapes based on language of document except potentially using browser language or A-L as an ultimate fallback

ISSUE-80: quote shapes based on language of document except potentially using browser language or A-L as an ultimate fallback

<trackbot> ISSUE-80 Default rules for the quotes property notes added

<r12a> http://www.w3.org/International/track/issues/80

ISSUE-81

Strip other line-terminators?

http://www.w3.org/International/track/issues/81

Where it says: -- When a user agent is to strip line breaks from a string, the user agent must remove any U+000A LINE FEED (LF) and U+000D CARRIAGE RETURN (CR) characters from that string. -- Should other line-terminators also be included here?

ISSUE-81: accepted for HTML5 LC

<trackbot> ISSUE-81 Strip other line-terminators? notes added

<r12a> http://www.w3.org/International/track/issues/81

ISSUE-82

Non-ASCII enumerated values

http://www.w3.org/International/track/issues/82

I realize that the set of "enumerated values" in HTML5 consists strictly of ASCII strings. However, there is no syntactical requirement that this be true. Non-ASCII values could be included into an enumerated value set, in which case, the "ACSII case-insensitive" match may be incomplete. Instead of using "ASCII case-insensitive", could Unicode case-folded matching be defined instead? This is stable, well-defined, and a strict superset of the ASCII case?

addison: somewhat pedantic, may not be worth raising?

ISSUE-82: rejected for LC

<trackbot> ISSUE-82 Non-ASCII enumerated values notes added

close ISSUE-82

<trackbot> ISSUE-82 Non-ASCII enumerated values closed

ISSUE-83

Note about why Gregorian only used

http://www.w3.org/International/track/issues/83

The section describes date values using strictly the Gregorian calendar. As long as the values are strictly internal (as a means of representing incremental or floating time values, cf. our note Working With Time Zones), this doesn't represent a barrier to the use of other calendric systems. Please include a note indicating this so that international users understand why Gregorian is used here.

ISSUE-83: accepted for HTML5 LC

<trackbot> ISSUE-83 Note about why Gregorian only used notes added

ISSUE-84

Representing BCE months

http://www.w3.org/International/track/issues/84

The 'months' definition only handles dates from the (proleptic) Gregorian year 0 in the common era going forwards. There is no way to represent BCE dates. Should there be?

month="1903-10"

gwyneth: need an "era" field?
... need to explain this comment more

ISSUE-84: accepted for HTML5 LC

<trackbot> ISSUE-84 Representing BCE months notes added

ISSUE-85

Health warning about converting date to/from incremental time

The 'date' definition contains no time zone information. It is thus a floating date value and a health warning should be included about converting it to/from incremental time values.

date="2011-06-28T14:34:55.007"

ISSUE-85: accepted for HTML5 LC

<trackbot> ISSUE-85 Health warning about converting date to/from incremental time notes added

ISSUE-86

Option for 1 digit hour

ISSUE-85: mention efforts on JavaScript inclusion of zone info

<trackbot> ISSUE-85 Health warning about converting date to/from incremental time notes added

http://www.w3.org/International/track/issues/86

In parsing a 'time' value, the rule for the hours section is: "Two digits, representing hour, in the range 0 ≤ hour ≤ 23". Should this optionally allow only one digit?

richard: actually tripped over this

time="0:00:00"

ISSUE-86: accepted for HTML5 LC

<trackbot> ISSUE-86 Option for 1 digit hour notes added

ISSUE-86: many users will make this error and the result will be an error rather than a time

<trackbot> ISSUE-86 Option for 1 digit hour notes added

ISSUE-87

Leap seconds

http://www.w3.org/International/track/issues/87

There is a note disallowing the representation of leap seconds. This poses a potential problem for applications sensitive to leap seconds. Should the values be allowed, even if later processing does not deal with it?

<Gwyneth> The International Earth Rotation And Reference Systems Service (IERS) Earth Orientation Center is taking comments on whether to get rid of leap seconds. http://hpiers.obspm.fr/eop-pc/index.php?index=questionnaire

datetime="1980-01-01T00:00:60"

ISSUE-87: accepted for HTML5 LC

<trackbot> ISSUE-87 Leap seconds notes added

ISSUE-88

Local/floating date and time

This defines a 'global date and time', which is the same as a 'local date and time', only with a time zone representation. I propose changing the 'local' value to use the term 'floating' (since it is not truly local). The term 'global' could remain. I would also suggest adding a reference to w3.org/TR/timezone (our note) to help users understand when to use which type.

ISSUE-88: accepted for HTML5 LC

<trackbot> ISSUE-88 Local/floating date and time notes added

ISSUE-89

Time zones and local dates and times

<Gwyneth> I need to head out to another meeting. Sorry.

http://www.w3.org/International/track/issues/89

This section defines 'local dates and times', which is a date-and-time value *without* a time zone. This type seems problematic because it does not deal with the time zone problem. Its relationship to either floating or incremental times is completely arbitrary. See also Issue 88.

addison: so have more understanding... modeling JS Date(). There are use cases like airline schedules where useful. Question is about giving good guidance to authors.
... call for a health warning related to time zones?

ISSUE-89: update to call for health warning on use of local dates and times

<trackbot> ISSUE-89 Time zones and local dates and times notes added

ISSUE-89: accepted for HTML5 LC

<trackbot> ISSUE-89 Time zones and local dates and times notes added

ISSUE-91

15 minute time zones

http://www.w3.org/International/track/issues/91

The note on time zone offsets says in part: "...and the minutes component of offsets of actual time zones is always either 00, 30, or 45." Really this is arbitrary and prone to change. The total range of time zones also changes from time to time. I would suggest inserting a "at the time this document was published" caveat such that innocent readers are not caught by surprise by a new 15 mintue time zone offset or by more monkey business surrounding the IDL.

ISSUE-91: accepted for HTML5 LC

<trackbot> ISSUE-91 15 minute time zones notes added

ISSUE-92

Time zone offset vs. time zone

http://www.w3.org/International/track/issues/92

This section gives a number of examples that equate time zone offset with an actual time zone. For example: -- "1979-10-14T12:00:00.001-04:00" One millisecond after noon on October 14th 1979, in the time zone in use on the east coast of the USA during daylight saving time. -- It should be made clear that a zone offset is not the same thing as a time zone. Mention should be made of the need for separate time zone information when working with real date and t

ISSUE-92: accepted for HTML5 LC

<trackbot> ISSUE-92 Time zone offset vs. time zone notes added

ISSUE-93

http://www.w3.org/International/track/issues/93

implicit conversion to incremental time

Rule 9 in the parsing of a valid global date and time is: "Let time be the moment in time at year year, month month, day day, hours hour, minute minute, second second, subtracting timezonehours hours and timezoneminutes minutes. That moment in time is a moment in the UTC time zone.". It is not clear what type 'time' is. It appears to be a field-based time value, but it this intended as an implicit conversion to incremental time?

ISSUE-93: accepted for HTML5 LC

<trackbot> ISSUE-93 Implicit conversion to incremental time? notes added

ISSUE-94

http://www.w3.org/International/track/issues/94

Allowing culturally specific week rules

This section defines 'weeks'. The rules for weeks and week counting are culturally linked, but these rules define week start as always Monday. The rule for determining the "first week" that it includes the first Thursday (again, a culturally variant value). Shouldn't there be provision for allowing culturally specific week rules be applied?

<matial> definitely

ISSUE-94: accepted for HTML5 LC

<trackbot> ISSUE-94 Allowing culturally specific week rules notes added

ISSUE-95

http://www.w3.org/International/track/issues/95

Limitations and defaults for accept-charset

The "accept-charset" field is said to "gives the character encodings that are to be used for the submission". Is this a real limitation on the encodings used? Is there a default value (presumably the page encoding)?

http://www.w3.org/TR/html5/forms.html#the-form-element

present for backward compatibility?

ISSUE-95: accepted for HTML5 LC

<trackbot> ISSUE-95 Limitations and defaults for accept-charset notes added

ISSUE-96

Allowing for EAI

The email address validation scheme quotes ABNF from RFC 5322 and doesn't appear to allow addresses that are IDNA. While EAI is kinda slow moving, shouldn't HTML5 allow for it?

<r12a> http://www.w3.org/Bugs/Public/show_bug.cgi?id=11579

<r12a> Support for internationalized e-mail addresses

ISSUE-96: add this issue to HTML5 bug 11579

<trackbot> ISSUE-96 Allowing for EAI notes added

ISSUE-97

Allowing a page to request a given locale

http://www.w3.org/International/track/issues/97

-- The format shown to the user is independent of the format used for form submission. Browsers are encouraged to use user interfaces that present dates and times according to the conventions of the user's preferred locale. -- Should we encourage the use of the *page's* preferred locale? It would be best if we could provide a way for page authors to create a consistent user experience. Work on the ECMAScript I18N extension may eventually help here, but only

matial: provide authors ability to override user's preferences, but user's preferences should work in absense of an override

ISSUE-97: accepted for HTML5 LC

<trackbot> ISSUE-97 Allowing a page to request a given locale notes added

<scribe> ACTION: addison: write to HTML5 chairs and ask for extension to complete our comments targetting mid-August (??) [recorded in http://www.w3.org/2011/07/27-i18n-minutes.html#action03]

<trackbot> Created ACTION-62 - Write to HTML5 chairs and ask for extension to complete our comments targetting mid-August (??) [on Addison Phillips - due 2011-08-03].

close ISSUE-128

<trackbot> ISSUE-128 Why is content-language non-conforming? closed

<scribe> ACTION: addison: file accepted as accepted and unreviewed comments as provisional [recorded in http://www.w3.org/2011/07/27-i18n-minutes.html#action04]

<trackbot> Created ACTION-63 - File accepted as accepted and unreviewed comments as provisional [on Addison Phillips - due 2011-08-03].