W3C home > Mailing lists > Public > public-i18n-core@w3.org > July to September 2006

Summary of LTLI discussion

From: Felix Sasaki <fsasaki@w3.org>
Date: Wed, 05 Jul 2006 16:24:40 +0900
Message-ID: <44AB6938.3080406@w3.org>
To: "public-i18n-core@w3.org" <public-i18n-core@w3.org>
Hi all,

this is a summary of the LTLI discussion from last week, see
http://www.w3.org/2006/06/27-i18ncore-minutes#item01 , and general
questions on LTLI. Please regard it also as an input to the meeting in
two weeks, where we will discuss LTLI again.

- Mark proposed to decide on the general notion of language versus
locale, see
http://lists.w3.org/Archives/Public/public-i18n-core/2006AprJun/0073.html  :
A) protocols should have two different fields: one for language and one
for locale)
B) the same field in a protocol can be and is typically used for
conveying language *and* locale information) as a "best practice" decision.

Currently there is no consensus what view should be preferred.

- An issue is whether xml:lang is appropriate for expressing locale
information. There is currently no consensus whether xml:lang should be
recommended as a means for conveying locale information, or rather only
for expressing the language of content. Limiting the first usage for
scenarios where a process of information is involved (e.g. constructing
web pages via AJAX) might be a solution.

- Locale can be described as language information plus  "something".
That "something" could be e.g. a default currency or time zone
information. There might be a consensus (?) that extensions of RFC
3066bis should be limited to areas which are related to language (e.g.
for sorting). It is not clear, however, whether LTLI should cover the
definition of such extensions.

- There are other ways of conveying locale information than via
xml:lang, e.g. via programming language identifiers. These use e.g. the
underscore instead of the (RFC3066bis) hyphen. Currently there is no
consensus whether such variations are acceptable.

- LTLI does not necessarily need to specify normative statements on all
these issues. Best practices might be enough.

- We need more detailed use cases. Mark will provide further input.

- A question which has been raised before, but not during our meeting:
How should LTLI deal with the matching part of RFC 3066bis? There have
been opinions from former WG members that the (again non-normative)
explanation of matching could be a main goal for LTLI.

Regards, Felix.

Received on Wednesday, 5 July 2006 07:25:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:23:01 UTC