Scottish English

Mark Davis mark.davis at
Wed Aug 22 19:57:00 CEST 2007

Add to that list the fundamental reason: there is some reason to use
countries in defining language variants, because the governments are often
associated with particular policies regarding orthography and other language
variant features. However, that relationship becomes very tenuous when we
look at sub-country boundaries, which are far less commonly associated
strongly with a particular language variant. Moreover, where there is such a
relationship, it far less likely to be unique; the same features will be
shared among a large set of subregions.

While the language tag does form the basis for locale codes (in one sense of
locale!), and so we make some minor accommodations for that, adding
subregions is far beyond the scope of the language tag.


On 8/21/07, Doug Ewell <dewell at> wrote:
> <Karen underscore Broome at spe dot sony dot com> wrote:
> > I share Addison's concerns with using the 3166-2 codes. Many of these
> > will be redundant with the ISO 639-3 codes, though this one is not.
> In fact, I've been carrying around a summary of "Why ISO 3166-2 won't
> work with RFC 4646" for some time, ready to be invoked the next time
> this topic came up:
> 1.  The ISO 3166-2 code list is not freely available, unlike other code
>     lists used to create subtags.
> 2.  The ISO 3166-2 code list is not stable.  ISO 3166/MA can change the
>     assignment of code elements at any time to reflect changes in
>     subdivisions or names as reported by governments.  This is similar
>     to the situation with ISO 3166-1, but country subdivisions and
>     coding systems change much more frequently than countries.
> 3.  ISO 3166-2 code elements may be from 1 to 3 letters and/or digits.
>     This puts them into conflict with the RFC 4646 syntax, since they
>     could not be distinguished from other types of subtags or from
>     singletons used to introduce extension or private-use subtags.
>     Examples of countries that have different ISO 3166-2 formats
>     (A = alpha, N = numeric):
>         A   - Argentina
>         AA  - United States
>         AAA - Mexico (this format is used when ISO 3166/MA assigns
>         the codes)
>         N   - Austria
>         NN  - Japan
>         NNN - Slovenia
>     Code elements with mixed letters and digits:
>         FR-2A (Corse-du-Sud)
>         FR-2B (Haute-Corse)
>         GR-A1 (Attiki)
>     Code elements consisting of the letter "X" (thus conflicting with
>     private-use subtags):
>         AR-X (Córdoba)
>         EC-X (Cotopaxi)
>         SE-X (Gävleborgs län)
>         VE-X (Vargas)
> (One of my first involvement with this list was when I made a totally
> false, newbie assumption that ISO 3166-2 codes could be tacked onto the
> end of RFC 1766 tags, like "en-US-NY".  John Cowan quickly and
> diplomatically divested me of that idea, and I vowed to learn more about
> how language tags really worked.)
> Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:
> > On another note, when I spoke to the 3166 MA on this very subject
> > about 18 months ago he assured me that the codes could not be
> > allocated as the trio make up a geopolitical entity in its own right -
> > UK (along with NI).  We then get on to the codes for Guernsey, Jersey
> > etc. and the Falklands.  It would seem that if there is water between
> > the geopolitical/devolved entities they can have their own code and if
> > there isn't they can't.  Strange but true I fear!
> But UNSD apparently doesn't have the same policy; they still have 830
> for Channel Islands despite the new codes for Guernsey and Jersey.
> > As to Scottish English.  Bad move in my humble opinion.  I can
> > understand Edinburgh Standard and not Glaswegian Standard.  Where is
> > the use in such a code?  Better would be: en-standard_glasgow,
> > en-standard_edinburgh etc.
> Unfortunately, that would introduce a great deal much more subjectivity
> than "Scottish."  If there are any "in-between" variations of note, how
> would they be indicated?
> --
> Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Ietf-languages mailing list