Re: [Ietf-languages] First cut at a BCP 47 extension structure for ISO TR 21636

[Sebastian Drude <[e-mail]>]

Thanks again, dear Doug,

and again my comments below.

Hava a nice (rest of) 1st advent sunday,

Sebastian

-- 

Museu P.E. Goeldi, CCH, Linguistica ▪ Av. Perimetral, 1901
Terra Firme, CEP: 66077-530 ▪ Belém do Pará – PA ▪ Brazil
[e-mail] ▪ [phone] ▪ [phone]
Priv: Tv. Juvenal Cordeiro, 184, Apt 104 ▪ 66070-300 Belém

On 29/11/2020 00:53, Doug Ewell wrote:
> That shouldn’t be necessary. Many folks have access to Mailman and can 
> spin up an ad-hoc mailing list. I know Michael Everson has done so on 
> several occasions, including one for a Unicode encoding proposal I’ve 
> been involved with that really couldn’t have succeeded without it. But 
> Michael doesn’t run a mailing-list business, and I hesitate to pester 
> him for this. 
Right. If things where normal, I could ask my department, but people are 
working from home etc....

> I need to read Mark’s response about this, and the issues surrounding it, a bit more thoroughly. I was under the impression that a given extension could quite happily allow you to string together “fr-v-xx-abcdef-ghijk”, or not, depending on how the spec is written. Mark seems to imply some inherent limitations on this in BCP 47. Fortunately we have plenty of time to figure out what can and cannot, or should not, be done here.
Yes, let's go on this with care.  I understood that there are 
possibilities of several values for the same key, which would mostly 
depend on how we set that up. I am confident we figure that out.

>> For the first case, several ever more specific indications would only
>> be admissible if each is relevant for some appliaction, and one cannot
>> presume that the language-tag-consumer knows of logical implications
>> (South Tirol German implies Bavarian which implies High German, for
>> instance).
> Nothing about BCP 47 tagging is ever intended to presume that the user (at either end) knows anything about language family hierarchies, about which there is much disagreement anyway.

This is what I would expect.


> I suspect I am not reading this comment carefully enough, and taking it out of context.
No need to rush.

>>>> -- the 'certainty' and similar "adjectives" (yes, that is how I
>>>> would see them; -- e.g. primary vs. secondary modality, genuine vs.
>>>> imitated, ...)
>>> I knew I had missed some in reading quickly through the NP document.
>>> If there are many, this would require some thought.
>> At this point, I do not foresee this to be heavily used, but what do I
>> know about possible needs in 20 years?  I would need to compile a list
>> of such "adjectives", perhaps there is one more case besides the three
>> we have identified here.  Again (see below, next comment), there are
>> default values, and only exceptions would need coding.
> No, I literally meant I did not even know there were three at present. I thought only "certainty" fell into this category. That's why I need to read through that part of the NP document again.
>
> But yes, the mechanism does need to allow for future modifiers of this type, just like the 'u' extension allows for additional keys, as well as additional values within each key.

Looking at the latest version of the document, there are indeed a number 
of such 'modifying' statements.

Certainty (values: documented, confirmed, certain, inferred, assumed, 
possible, unclear, ...).

Dialects being influenced by another language (Example: Urdu as spoken 
in London, influenced by: English).  Dialectal varieties that emerge if 
the father speaks one and the mother another dialect, or the parents 
speak one dialect, but the person in question grows up speaking another 
dialect with peers -- sometimes not dialectal bi-'lingualism' emerges, 
but mixed forms.

Primary modality and secondary modality.  This may actually be relevant 
in many situations.

Proficiency: framework of rating, or theory of language acquisicion applied

Communicative functioning: degree of (informally said:) anomaly

I guess that this can all be easily solved by adding further two-letter 
keys to provide these indications in their values as if they were 
additional dimensions.  The rules then would have to state that they are 
only allowed if the major dimension is present.

> I have to confess that it never occurred to me that users of this extension, or indeed users of the TR in any form, would always be expected to provide values for all eight (or seven) dimensions, and that a defaulting mechanism would be necessary to permit eliding some of them.

Indeed, that was never the intention, but as soon as people understand 
that in principle each and every speech event or resource inevitably has 
some value on each of the eight dimensions, people could feel obliged, 
for the sake of coherence or completeness or whatever, to indicate all 8 
of them every time.  Absolutely not feasible, and not what anybody would 
want, let alone require.  Still, it came up as an argument for rejecting 
the whole framework.

Of course, if one indicates only one value for one dimension (which is 
perfectly fine), or no variation value at all, as will be the case of 
the vast majority of all language tags, the status of the (other) 
dimensions of linguistic variation can usually be inferred by assuming 
something like default values, and that could be made explicit 
somewhere.  That is what I meant.  That does not necessarily imply that 
default values are a formal part of the extension.

>> I agree.  I was not at all proposing to complement, let alone replace,
>> the ISO 639 identifiers in the main language subtags or any other
>> crucial area of BCP 47 by glottocodes.
> Thank you very much. I am glad in this case that I simply misread this and panicked for no reason.
No, I expressed myself badly here I guess.  Sorry for that.

> Well, I mean, we also know that Glottocodes exist. For that matter, we also know the Linguasphere coding system exists. Whether we consider these to be “standards,” whether on a par with ISO 639 or not, can be debated.

Sure.  This depends a lot of the community, of course.  In diversity 
linguistics, people accept Glottocodes as a valid alternative, if not 
superior, to ISO 639-3.  And I have to agree that the scholar soundness 
is impressive, certainly very different from the idiosyncratic 
Linguasphere (despite "a resourceful conception, many valid insights and 
much knowledge", as I wrote elsewhere <http://hdl.handle.net/10125/24814>).

> https://www.iana.org/assignments/language-tag-extensions-registry
I see, only two, "t" and "u", are registered.  Plenty of room to 
register "g" and "v".

> The reviewers may simply have not seen the documentation for Adhari (Old Azeri) that they were looking for.

This was just a fictious case, taking one of the first languages with a 
Glottocode that apparently does not have any ISO 639 entry.  There are 
no real "reviewers" (reviewing what?).

> Submitting a proposal to add a language like this to 639-3, and thus to the Registry, might be more productive than building a mechanism to swap in another coding system, ISO 2022-like. This is especially true if the Adhari example isn’t intended to represent hundreds or thousands of language missing from 639-3.

There are not too many languages in the Glottolog which are not in the 
Ethnologue, certainly not thousands, perhaps a couple of hundreds.  
Still, certain communities may be content to just take the existing 
Glottocode instead of taking up the burden of starting a process to add 
the language to ISO 639.  (There may be little overlap with the 
communities using BCP 47 language tags, but that may change.)

In addition to languages not (yet) in ISO, there are certainly several 
thousands varieties (mainly, but not only dialects) of languages which 
already do have a Glottocode, which *may* be interesting to allow as 
subtags or at least an extension.  I don't understand this deeply enough 
at this point to advocate for or against anything, I mainly want to draw 
your attention to this.


>
> --
> Doug Ewell, CC, ALB | Thornton, CO, US | ewellic.org
>
>
>