See also: IRC log
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
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
Mary: next meeting I'll be away - 4th of July