RFC3066bis: looking ahead
Addison Phillips [wM]
aphillips at webmethods.com
Tue Jan 20 18:37:15 CET 2004
The language subtags would be confused with alpha-2 or alpha-3 country
I must admit that I'm a bit dubious about ISO639-3. You could view
RFC1766/3066 as a reaction to the inadequacies of ISO639-1/-2 in identifying
languages. Will ISO639-3 really solve these problems? RFC3066bis, like its
forebears, is based on ISO639-1/-2, plus some other fields that help
identify particular written, regional, or other (miscellaneous)
If ISO639-3 identifies more variations within languages, then it would be,
in my view, a candidate for inclusion in the generative standard in the slot
Mark and I call "variant". Perhaps we could reserve a marker for such
inclusion, such as the formerly reserved subtag 'i-'.
Your example would then be:
zh-i-yue (ISO639-3 flavored)
zh-Hant-CN-i-yue (ditto, with other slots filled in)
Alternatively, if ISO639-3 provides tags that actually identify langauges as
an amalgum of ISO639-1/-2, then why not:
i-yue-Hant-CN (to be distinct from the still legal ISO639-1/-2 codes)
These thoughts of mine really are stream of conciousness. Part of my feeling
here is that ISO639-3 should do its work and offer a genuine improvement
over using the existing ISO639-x standards before RFC3066 gets revised to
include that work.
PS> I'm not ignoring your posts of last week or so: I've been too busy to
write the kind of response merited.
Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
Internationalization is an architecture.
It is not a feature.
> -----Original Message-----
> From: ietf-languages-bounces at alvestrand.no
> [mailto:ietf-languages-bounces at alvestrand.no]On Behalf Of Peter
> Sent: mardi 20 janvier 2004 08:35
> To: ietf-languages at alvestrand.no
> Subject: RE: RFC3066bis: looking ahead
> > From: Mark Davis [mailto:mark.davis at jtcsv.com]
> > No, it would be an issue. 3066bis is designed so that one can parse
> the tags and
> > decide without lookup which are language, which are script, and which
> are region
> > codes. Adding possibly dual language codes would break this. Have to
> think about
> > it a bit.
> The language subtags from ISO 639 could only be 2 or 3 characters long,
> and nothing else could have that length (assuming your proposed syntax).
> Thus, it shouldn't be at all hard to parse.
> Peter Constable
> Globalization Infrastructure and Font Technologies
> Microsoft Windows Division
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
More information about the Ietf-languages