Re: Anomaly in upcoming registry

[Mark Davis ⌛ <[e-mail]>]

I agree, except for the sentence:

> since the RFC already deprecates the use of most macrolanguages (including
'sh') in favor of encompassed language subtags.

Macrolanguages are *not* deprecated; only 'sh' is; that's why it is an
anomaly.

%%
Type: language
Subtag: zh
Description: Chinese
Added: 2005-10-16
Scope: macrolanguage
%%

I think what you meant to say is that the RFC *favors* the use of
encompassed languages over the use of their macrolanguages.

Mark


On Mon, Jun 29, 2009 at 08:59, Phillips, Addison <[e-mail]> wrote:

> I think my opinion on what should happen would depend on the record Mark
> wants to register.
>
> One change that the new RFC makes to record 'sh' is that it will include
> the field "Macrolanguage". There is specific guidance about macrolanguage
> usage in the RFC, notably in section 4.1.1---where the encompassed languages
> of 'sh' appear in an example. It shouldn't, in theory, be necessary to
> deprecate 'sh', since the RFC already deprecates the use of most
> macrolanguages (including 'sh') in favor of encompassed language subtags.
>
> One problem with deprecating 'sh' is that we do not include a "Deprecated"
> field in the other macrolanguage subtag records. Presumably one would
> deprecate a macrolanguage if it were withdrawn or replaced with another code
> by ISO 639-3 or if the macrolanguage relationship were dissolved... that is,
> deprecation happens when something happens to the status of 'sh' as a
> macrolanguage or happens to other peer subtags.
>
> On the other hand, Mark has a point. Language tagging in the Balkans is
> freighted with enough different socio-political and historical nuances as it
> is. 'sh' and its encompassed languages serve mainly as an exception to the
> normal rules of tag meaning and stability. Although "macrolanguage-hood" is
> a different form of deprecation, I think preserving the current explicit
> deprecation of the subtag might benefit everyone more than strictly hewing
> to the RFC's apparent intentions.
>
> So right now I think I'd wait for Mark's request, since the nuances are
> likely to be what matters.
>
> Addison
>
> Addison Phillips
> Globalization Architect -- Lab126
>
> Internationalization is not a feature.
> It is an architecture.
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:ietf-languages-
> > [e-mail]] On Behalf Of Doug Ewell
> > Sent: Monday, June 29, 2009 6:05 AM
> > To: [e-mail]
> > Subject: Re: Anomaly in upcoming registry
> >
> > Randy Presuhn <randy underscore presuhn at mindspring dot com>
> > wrote:
> >
> > >> ... It certainly isn't patently obvious to me that this is a bug
> > in
> > >> the draft-4645bis Registry that needs to be fixed.
> > >
> > > I think no one is suggesting that anything be done to draft-
> > 4645bis. I
> > > think re-opening 4645bis to make a change of this nature would be
> > > inappropriate.
> >
> > No, I agree that Mark was not calling to change anything in
> > draft-4645bis, but rather in the "draft-4645bis Registry" -- the
> > Registry to be supplied to IANA by draft-4645bis, whose method of
> > construction is described in draft-4645bis.
> >
> > My position is that the change Mark suggests may not be appropriate,
> > and
> > is certainly not a <span lang="en-US">slam dunk</span>.  It depends
> > on
> > our interpretation of draft-4646bis and any priorities it does or
> > doesn't give to ISO 639-3 over other parts of ISO 639, and it
> > depends on
> > whether the relevant RA or JAC decides to correct the inconsistency
> > in
> > 639 by either (a) reviving "sh" in 639-1 and adding "hbs" to 639-2,
> > or
> > (b) withdrawing "hbs" from 639-3.
> >
> > I don't see why the philosophical discussion necessarily must wait
> > until
> > the new Registry is in force, but if others want to wait, that's
> > fine
> > with me.
> >
> > --
> > Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
> > http://www.ewellic.org
> > http://www1.ietf.org/html.charters/ltru-charter.html
> > http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ
> >
> > _______________________________________________
> > Ietf-languages mailing list
> > [e-mail]
> > http://www.alvestrand.no/mailman/listinfo/ietf-languages
> _______________________________________________
> Ietf-languages mailing list
> [e-mail]
> http://www.alvestrand.no/mailman/listinfo/ietf-languages
>