Subject: RE: [Ltru] [psg.com #1096] "nb" versus "no"

From: "Addison Phillips" <[email-masked]>
Date: Mon, 15 Aug 2005 15:39:46 -0700

... in RFC 3066ter.

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Peter Constable
> Sent: 2005?8?15? 15:35
> To: LTRU Working Group
> Subject: RE: [Ltru] [psg.com #1096] "nb" versus "no"
> 
> > From: [email-masked] [mailto:[email-masked]]
> On Behalf Of
> > Randy Presuhn
> 
> 
> > > From: "Kent Karlsson" <[email-masked]>
> 
> > > 1. 'no' should be deprecated in favor of 'nb'. That is,
> > > one should assume 'nb' if 'no' is used.
> > >
> > > 'no' is is (now) in theory a language group code, but all
> > > languages in that group have individual codes (nb and nn);
> > > not counting dialects. But effectively, in practice, 'nb'
> > > *replaces* 'no' ('nn' is much rarer than 'nb').
> 
> In ISO 639-3, nor (the alpha-3 equivalent to no) is considered a
> macrolanguage encompassing both nob and nno (equivalents to nb and nn).
> In theory, that *might* suggest that in 3066ter that we could recommend
> no-nob / no-nno be used. This is a special case, though, in two
> respects: the macrolanguage categories pre-exist ISO 639-3, and the
> macrolanguage categories have their own alpha-2 IDs. Thus, it seems
> reasonably to me that this set of categories might have exceptional
> handling.
> 
> 
> 
> Peter Constable
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: r&d afrac <[email-masked]>
Date: Tue, 16 Aug 2005 01:22:19 +0200

>... in RFC 3066ter.

By 3066 AD?

So interested in restricting the 3066 ABNF that you cannot think how to 
support this without needing another RFC ... Why not just to foresee it now 
(at three years at least the Draft)? I do not see your problem?

Obviously I am biaised: I want to favor the best interests of the users. 
There is an obvious COI.
Take care.
jfc