Subject: RE: [Ltru] STD (was: Last Call: 'Tags for Identifying Languages' toBCP)

From: "Peter Constable" <[email-masked]>
Date: Sun, 28 Aug 2005 09:10:17 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Addison Phillips

> ISO 639-6 codes are easily dealt with: there is a slot reserved for
them
> in the ABNF that implementers ignore at their peril and the only
change is
> the management of registrations.
> 
> ISO 639-3 is slightly more complicated.

Actually, I think it could well be the other way around. 

Yes, from a purely syntactic perspective 639-6 would be straightforward.
But the same would be true for 639-3: any alpha-4 from 639-6 can go into
the initial subtag position, and any alpha-3 from 639-3 can go into
initial or extlang subtags. But 639-3 won't be quite that simple because
we want to avoid certain things:

- e.g. don't use 639-3 alpha-3 in initial subtag when there's an
equivalent alpha-2

- there must be some constraint on the relationship between lang and
extlang subtags to avoid uninterpretable anomalies like en-fre, or
arb-ar (ar = generic Arabic, arb = specifically Standard Arabic) --
assuming the second subtag qualifies the first subtag

- we want to avoid the wrong matching behaviour that would arise from
tags like arb-ar

> Rules for
> deciding what is an extlang and what is not may need to be worked
through
> (although I expect that ISO 639-3 itself will provide the rationale
there).

We will likely be able to define constraints in terms of the
macrolanguage mappings to be defined in 639-3.

It's not obvious what we would do in 639-6, but it appears to me that
there will be issues. For instance, consider a hypothetical alpha-4 abcd
that means some dialect X of Tajik written in Latin script using some
specific orthographic conventions defined in 2010 (say) by the
government of Kazakhstan. So, what do we do about

abcd-KZ
abcd-TJ
abcd-Latn
abcd-Cyrl
abcd-dialectx
abcd-dialecty
abcd-2010
abcd-1996
abcd-tgk
abcd-eng

etc. The issue is that he alpha-4 IDs can already be quite specific --
fully qualified -- and hence questions arise if they are combined with
other qualifiers. Do we add permitted_subtags fields to some 25000
registry entries for these things?

Note, though, that not all 639-6 IDs would be fully qualified. Thus,
returning to the hypothetical example, there'd be a related alpha-4,
call it abcc, that represented dialect X of Tajik in Latin script, but
not the specific orthographic conventions. What do we do about the
synonymity of abcd and abcc-2010?

And, as I understand it, the idea for 639-6 would be that all levels of
granularity would be coded, from the most specific to the most generic.
This means that engl (say) -- the equivalent to en -- is available. Of
course, using the shortest-first rule, en would take priority over engl.
But the generality wouldn't stop at that level. There would be alpha-4
IDs for several more levels of generality all the way up to
Indo-European. (For half the worlds languages, more or less, the top
level would be a language phylum like I-E; for the other half, it would
be a geographic grouping, such as Eurasian.) So, consider I-E with an
alpha-4 ID (say) of ineu. So what of tags like

ineu-DE
ineu-Cyrl
ineu-dialectx
ineu-tgk

These are all issues that can be resolved, though it's by no means
obvious that they could be resolved easily -- not unless we do something
like revising the syntax so that initial alpha-4 subtags cannot co-occur
with any other subtags (except perhaps extensions), and even then we'd
have the issue of synonymity between pairs like en / engl and
tgk-Latn-KZ-dialectx-2010 / abcd.

Peter Constable

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

---

From: "Debbie Garside" <[email-masked]>
Date: Sun, 28 Aug 2005 18:31:20 +0100

Hi Peter

Please correct me if I am wrong, but I thought the whole idea of the primary
language sub tag is that you use the shortest available ISO 639 code.  My
perception of its possible use within this particular RFC is that if there
is a requirement for a level of granularity lower than language use ISO
639-6; you can design the RFC to stop at any level within the hierarchy.
However, that surely does not stop you from using any of the other
qualifying tags in the ABNF e.g. ISO 3166 or 15924 if you need them.  I
would not envisage this RFC using an alpha-4 representation for
Indo-European.  However, I do foresee other applications for it and I see no
point in creating half a hierarchical system when the whole is available. 

With regard to your examples, I can't really see a problem other than you

> abcd-1996

In your example abcd (1996) would be annotated and a new code abce (2010)
created with the original staying in the registry as a historical language
code so it would still be valid.

Kind Regards

Debbie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Peter Constable
> Sent: 28 August 2005 17:10
> To: [email-masked]
> Subject: RE: [Ltru] STD (was: Last Call: 'Tags for Identifying
> Languages'toBCP)
>