W3C home > Mailing lists > Public > www-international@w3.org > October to December 2004

Language Identifiers in IDNA tables and 3066bis

From: Tex Texin <tex@xencraft.com>
Date: Sun, 26 Dec 2004 21:37:36 -0800
Message-ID: <41CF9FA0.3A8447D1@xencraft.com>
To: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
CC: John Cowan <jcowan@reutershealth.com>, WWW International <www-international@w3.org>, IETF Languages <ietf-languages@iana.org>

JFC,

hi. I can certainly agree that language tags are used in multiple ways, causing
confusion.

However, restricing their use to language tags identifying IDNA tables is going
too far in the other direction.
Language tags are mentioned in several RFCs for other purposes, such as
content-language in headers,
the RFCs for HTML, etc.

So it seems fair to say that RFCs should serve the purposes of IETF network
interoperability, but that should include more than IDNA tables, unless I
misunderstand the meaning of "IDNA tables".

(I changed the subject since your comments were not really about the list I
published, but about 3066bis.)

tex


"JFC (Jefsey) Morfin" wrote:
> 
> I gave some thinking to all this and reviewed the documents that W3C also
> prepare. I am afraid we want to put too many unrelated things into the same
> debate, due to a confusion between the three internationalization,
> multilingualization and vernacularization layers wich are not identifed and
> documented yet, while some attempt to discuss what belongs to lingual
> authoritative sources.
> 
> This is only an IETF document, talking only about network interoperablity.
> It must be consistent with other RFCs. Other RFCs have defined the Internet
> language/country authorities: RFC 3066bis cannot say otherwise. As for
> naming, languages are chosen and documented by the local internet
> communities, represented by their Trustees, the ccTLD Managers (the SLD
> Manager for privately defined tags). The same as IANA is not in the
> business of defining countries (RFC 1591), IANA is not in the business of
> defining the languages of the countries.
> 
> All what an _RFC_ can say is that language tags identify the IDNA Tables
> published by the ccTLD Manager, as the Trustee of his local internet
> community (we talk of the language used by network/protocol related
> issues). Or by the SLD Managers for their domain. I certainly favor
> Unicode, locales, contexts, etc. converge, but that rises first many many
> more multilingual Internet related issues, the RFC 3066bis does not want to
> discuss.
> 
> I fully understand that most of the ccTLD Managers have not published
> language tables and that other applications than DNS call for an immediate
> support, alaso that SLD Manager may need off-the-shelves tables. However
> this support by non-ccTLD Managers can only be temporary and MUST be
> eventually consistent with the ccTLD Manager tables such an RFC should call
> for. Otherwise we have a real layer and autority violation, all the more
> than this is not only by RFC 1591, ICANN ICP-1 but also by the WSIS 2003
> Resolutions underlinging the sovereignty of Govs over ccTLDs. There is no
> problem in documenting the duties of a ccTLD Manager in this area and in
> discussing it with ccTLDs Managers, as an addition to the ccTLD Manager BPs.
> 
> I would therefore review the ABNF in four areas:
> - favoring the three letter codes for the language to make this entry time
> independent and consistent (this does not change anything in the currenet
> applications)
> - introduce the quted language icon URL
> - the URL of the corresponding table
> - a possible comment on the orientation of the table.
> 
> I would add a paragraph indicating that languages tags actually designate
> the language tables decided by the local internet communities through they
> ccTLD Manager. Underlining that there is as many language tags in use as
> supported, requested or prepared tables.
> jfc.
> 
> At 11:32 26/12/2004, Tex Texin wrote:
> 
> >I have updated the page with a new format for the tables.
> >There is now just one table which lists all of the 3166 region codes, and for
> >each code (some of) the languages that are spoken in the region. As you know
> >John Cowan provided the original data which was based on official languages.
> >I have found a number of additions of official languages, and in some cases
> >added languages that are not official but used in the region.
> >
> >Unfortunately, I have had to rely on a few different sources and there isn't a
> >consistent rule as to percentage of people speaking the language in a
> >region to
> >qualify it for listing. In some cases, the choices were based on the time
> >I had
> >available to invest in this effort.
> >
> >The goal of the list is still to identify language codes that should be
> >language tag alone, vs. language-region tag
> >and/or a meaningful criteria for making the distinction.
> >
> >Informed and constructive comments are welcomed.
> >
> >The first row of the table represents languages that I have not yet identified
> >as belonging to a region.
> >
> >Some of the languages are "constructed" (interlingua, esperanto, ido) and do
> >not belong to any region.
> >I might move them to a separate row for "constructed" languages.
> >
> >The 3166 codes may not be fully up to date. I noted the YU entry, which should
> >be deprecated. The list needs checking for other errors or problems.
> >
> >The page is:
> >http://www.i18nguy.com/unicode/language-identifiers.html
> >
> >tex
> >
> >_______________________________________________
> >Ietf-languages mailing list
> >Ietf-languages@alvestrand.no
> >http://www.alvestrand.no/mailman/listinfo/ietf-languages
> 
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages

-- 
-------------------------------------------------------------
Tex Texin   cell: +1 781 789 1898   mailto:Tex@XenCraft.com
Xen Master                          http://www.i18nGuy.com
                         
XenCraft		            http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
Received on Monday, 27 December 2004 05:37:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 19:17:04 GMT