W3C

i18n core working group

27 Jun 2006

Agenda

See also: IRC log

Attendees

Present
Felix, Francois, Karunesh, Mark (for the LTLI discussion), Mary, Richard, Vijay
Regrets
Chair
Francois
Scribe
Felix

Contents


LTLI progress

input mail from Mark: http://lists.w3.org/Archives/Public/public-i18n-core/2006AprJun/0073.html

Mark: document is doing good progress. But there is a big choice necessary
... there are two possible views on language versus locale: option A) and B), described in the mail
... currently, the document does not distingush cleanly between these two
... some other comments in the mail:
... there are two paragraphs which should be combined
... replace "Locale Values" with "Locale Identifiers" in general
... a proposal for a change from the scope section to a different section
... these are all smaller issues, the main issue is A) versus B)

Francois: we discussed A) versus B) briefly two weeks ago
... B) would be my preference

Mark: Mine as well
... it reflects reality

Richard: are there other reasons?

Mark: it is general practice for people to do that
... RFC 3066bis helps you to distinguish linguistic information, which is important
... but what a locale is depends very much on the application(s)
... e.g. for pay pale other things are important than on airline flights
... that is: saying RFC 3066bis is the core, with additional information as necessary

Felix: what would be the value of saying "RFC 3066bis in the core"?

Mark: there is a lot of value
... there is no standard meaning for locale

Felix: I am wondering how we should use "musts" or "shoulds"?

Mark: We could phrase it as best practices

Richard: Some questions:
... we have xml:lang, that people should use to identify the language. Correct?

Mark: yes.

Richard: so if we specify a locale, we would not use xml:lang?

Mark: I disagree. B) would say "you can also interpret that as a locale"
... the same thing for "accept-language" in HTTP
... or in other circumstances with RFC 3066bis identifiers
... that is: use this as a locale, and supplement it with other information

Richard: I would be happier if we would say:
... "In the absence of locale information, you make statements relying on xml:lang"
... the background: we already have problems convincing people using xml:lang

Mark: People take the information they have
... we could say: If you have other locale information
... e.g. an xml element which has "country ???" as a seperate element in an XML document
... if we had also had country of prinicipal residents: we would have two fields, which would contribute what the users locale is
... both going beyond what xml:lang states

Francois: xml:lang and the users locale are orthogonal
... xml:lang designates the language (perhaps by extension the locale) of the content
... but not the users locale

Mark: right

Francois: so xml:lang should not be used for the users locale

Richard: we had discussion with the voice browser wg
... we concluded: xml:lang indicates indicates the language of the document
... the language of the voice browser processer is different
... Addison said similar things in an article a while ago

Mark: The document represents information from or to a user
... the language is the language you want to communicate
... the users locale is a slight abstraction

Richard: Given a french page, for a user from the UK, the page is still in French

Mark: the users locale in common computer practice is:
... what is the preferrred locale to communicate some information to the user
... there is a little reliable way to do that
... you can use a best guess (heuristics) and let the other person correct

Felix: that is: if there is a process, I have to think about the locale?

Mark: yes
... e.g. if I construct AJAX
... it is directly directed with a process
... if I have a static document, it uses a language identifier
... we could say: a language identifier can be interpreted as a locale identifier where it makes sense
... people need to be prepared to supplement the information in other fields
... you could give the country examples given above

Francois: as for the "additional information": Mark, have you any ideas what it should be?

Mark: Trying to extend with the examples I have choosen above
... that would be a mistake, it would overload the mechanism too much
... extensions would be more natural "extensions"
... in CLDR we have such extensions
... there is a gray area what is meant by a language if you go into e.g. sorting
... I would recommend to have RFC 3066bis extensions limited
... related to language

Francois: that matches the philosophy of RFC 3066bis
... but what if we invent a mechanism for locale specific stuff?

Mark: we actually do that in CLDR
... there are two pieces of information: the default currency and default timezone
... whose are not language related
... other fields are possible, but we don't really encourage that
... you may have a mechanism for encapsulating RFC 3066bis
... one problem is that: RFC 3066bis cannot be truncated
... if you pack too much information into locale, that is not an issue e.g. in XML, but maybe in other protocols

Richard: another clarification question:
... if people want to have their own way of conveining locale information
... e.g. a Java identifier
... should we tell them to use RFC 3066bis?

Mark: We tell people to ignore the difference between "hyphen" and "underscore" in such cases
... that is: you accept a slightly wider range than RFC 3066bis
... but we should discuss this with Addison
... but I also think: We should *not* differ in the general role of language identifiers

Felix: question: who is convinced about A or B?

Richard: not yet convinced

Felix: we could publish a new draft and allow for public feedback?

Mark: I will think about further steps

Richard: It might be helpful to have some usecases outlined
... it helps to ground the discussion

Felix: we will continue discussion on this in three weeks

WCAG 2.0 review

Richard: main thing: I am saying to them: Why are you talking about text direction at all?
... this is not accessibility specific
... they have a lot of material about text direction, not in the guidelines themselves
... but in the two other documents
... I don't see why they need to comment about that
... if they keep text direction, I will make double of comments

Felix: how abou Ruby?

Richard: That has accessibility aspects in some circumstances
... as for directionality: I can't see why that is an accessibility issue

Felix: I am fine with the proposal to take directionality out of the document

Mary: Did they say why it is specific to accessibility?

<r12a> "The intent of this success criterion is to enable a user agent to provide an alternative presentation of content while preserving the reading order needed to perceive meaning. It is important that it be possible to programmatically determine at least one sequence of the content that makes sense."

<r12a> "User agents, including speech-enabled as well as graphical applications, may be unable to present text correctly unless the language and direction of the text are identified; while these may be minor problems for most users, they can be enormous barriers for users with disabilities"

Richard: that is the clearest justification I could found
... but that is not adequate for me
... let me make the comments and see how they react

Mary: o.k.

Richard: I saw Felix's comments on my comments, thanks. Any other comments?

Francois: I scanned through the comments, I'm fine with them
... looks like a very good review
... so Richard can send out the comments

other business?

Mary: next meeting I'll be away - 4th of July

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/06/27 15:14:27 $