Subject: Re: [Ltru] Addition to ISO 639-3: [lyg]

From: "Debbie Garside" <[email-masked]>
Date: Thu, 1 May 2008 10:16:07 +0100

Hi Doug

I do see the points you have made and can see that quite a lot of extra work
would be involved - although I am sure that the ISO 639-3 MA/RA would
facilitate a better change page if required.  I still think that for
backward compatibility as well as assistance to the end user that this
should be done.  However, as there has been no supporting discussion on this
and as Randy is hoping for a last call pretty soon I won't labour the points
for doing this.

Best

Debbie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Doug Ewell
> Sent: 01 May 2008 06:39
> To: LTRU Working Group
> Subject: Re: [Ltru] Addition to ISO 639-3: [lyg]
>
> Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:
>
> > Although I think that this should form part of the formal
> process. I
> > think it should be written into the RFC as a "Should" for
> this type of
> > situation.
>
> I'm concerned about using the word "should" (with or without RFC 2119
> uppercasing) for anything relating to Comments fields.  If
> the content absolutely has to be there, or else the Registry
> can't be used properly, then they shouldn't be comments;
> there should be a new field (i.e. "See
> Also") for this sort of must-have information.  And I say
> this knowing how Randy feels about finishing off this work,
> and not adding new things to it, and I say this 99.9%
> agreeing with him.
>
> > With a comment field within 'lyg' directing Joe to 'kha' he
> can do a
> > secondary match.  With no comment he has no chance of finding the
> > documents unless he knows enough about the LSR to do a search for
> > comments regarding 'lyg' (which would bring up my proposed comment
> > within 'kha' but only in this particular instance).
>
> Not only that, but this use case expands our -- somebody's --
> task of digging beneath the surface of ISO 639-3 changes even
> more than I anticipated.  This is because of the four
> different paths that ISO 639-3/RA can take when splitting a
> language, as outlined by Joan Spanne.
>
> Suppose Joe, on his second week with Company A (luckily not
> having been sacked over the Lyngngam headache), receives a
> new request to find documents relating to Rangpuri, one of
> two languages split off from what used to be called Rajbanshi
> (the other "new" language is also called Rajbanshi).  This
> was another of the 2007 changes, one that follows the first
> of Joan's four cases.  Joe can find 'rkt' for Rangpuri, but
> is unlikely to find any correlation to either the old
> Rajbanshi ('rjb') or the new Rajbanshi ('rjs').  The subtag
> 'rjb' would have been deprecated, either with no
> Preferred-Value or with a P-V of 'rjs', but probably not with
> a P-V of 'rkt'.
>
> Thus we would need to supply comments not only for the
> narrowing cases, which Joan expects to be comparatively rare,
> but also for what she called the "simple splits" like
> Rajbanshi, which constitute a significant percentage of the
> churn in ISO 639-3.  The "merge" cases would probably have to
> be commented as well, for similar reasons.  In essence this
> is a reverse Preferred-Value, telling the user how the
> language *used to be* tagged, whereas Preferred-Value leads
> the user from the old subtag to the new one.
>
> And while I would love to think the rate of churn in ISO
> 639-3 is dwindling to a trickle, the Change Request Index
> page suggests
> otherwise: 45 proposed language changes already since the
> publication of the 2007 changes four months ago.
>
> > At the moment these comments may or may not be there
> according to the
> > rules of the current RFC.  I don't think this is good
> enough.  We can
> > do better and I don't think it will cost a lot to do it.  A simple
> > rule that states "where the meaning of a subtag is narrowed
> and a new
> > subtag is issued as a result both subtags should have
> comment fields
> > denoting the change history".  A simple "watch this page"
> scenario on
> > the ISO 639-3 change notification page would assist in the process.
>
> They don't post their changes on an incremental basis, with
> explanation, as ISO 639-2/RA does.  Rather, they make entire
> new files available for download, with the changes in place
> but not annotated, and only once a year do they publish a
> Summary of Outcomes document which explains the nature of the
> change.  It is then for us -- by which I assume is meant the
> Designated Experts, Michael and Doug -- to do the exegesis on
> the downloadable files, deciding which changes in ISO 639-3
> require this type of "obligatory" comment.  The downloadable
> files are wonderful, don't get me wrong, but a list of
> changes posted on a Web page, in date order, would be
> necessary to make good use of WatchThatPage.
>
> I do use WatchThatPage to find out about the new 639-3 files,
> and I had expected to do some exegesis on them already, such
> as identifying deprecated language subtags and their
> Preferred-Values.  These suggestions add an unknown amount of
> exegesis to what I was already going to do.  It's unlikely
> anyone else would volunteer to do it, to be honest.
>
> We could extend this concept even further, by adding Comments
> fields to the region subtags for all of the former Soviet
> republics, pointing them back to 'SU', so that Joe could find
> documents related to "Kurdish as used in Armenia" that were
> tagged before Armenia was independent.  This is not meant to
> be sarcastic, but is a logical outgrowth of adding comments
> to language subtags pointing them back to "previously coded as"
> values.  I don't know where it would end.
>
> --
> Doug Ewell  *  Arvada, 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  ^
>
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru
>

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