Re: [Ietf-languages] First cut at a BCP 47 extension structure for ISO TR 21636 (was: Language subtag registration form)

[Mark Davis ☕️ <[e-mail]>]

> 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.

Your impression is right, sorry that I was unclear. Bcp47 does not impose
structure; they were just examples of how we ended up adding structure so
as to provide for clear semantics when parsing multiple values.


BTW, for a new email group there are far easier and more functional
mechanisms available in this millennium ...

On Sat, Nov 28, 2020, 19:53 Doug Ewell <[e-mail]> wrote:

> Sebastian Drude wrote:
>
> >> Maybe a custom mailing list could be formed. Everyone here would need
> >> to be eligible to join the discussion if they choose to.
> >
> > Yes, that would be great.  I am not connected any more to any service
> > where I could do so, whom could we ask?  The LinguistList?
>
> 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.
>
> >>> -- can more than one value in the SAME dimension be indicated? (I
> >>> would argue yes, if that is syntactically okay)
> >
> > That is fine.  One could need it for at least two cases:
> >
> > - more general and more specific indications (dialects, sociolects...)
> >
> > - idiolects belonging to intersections of varieties (e.g., showing all
> > the defining criteria for more than one dialect, in border areas)
>
> 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.
>
> > 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.
>
> I suspect I am not reading this comment carefully enough, and taking it
> out of context.
>
> >>> -- 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.
>
> >>> -- default values
> >
> > I understand.  A common objection to the 8-dimension-approach is that
> > it is very cumbersome to indicate values for each dimension for each
> > resource, and I could not agree more.
> >
> > One obvious solution is to imply default values and code only
> > 'deviant' varieties.  The default values could be: (1) the respective
> > "standard varieties" in the case of the space dimension, (2) "current
> > period" for time, (3) "middle-class" or "socially neutral" for social
> > group, (5) "neutral" for register, (7) "full" proficiency, and (8)
> > "regular functioning" (no 'anomaly') for the commun. funct. dimension.
> > (We leave (6), the person dimension, out, as discussed.)
> >
> > For (3) the medium dimension, the default value would perhaps depend
> > on (a) the media carrier ("oral" for an audio recording, "written" for
> > a text document or PDF, although one may want to indicate the specific
> > writing system etc. -- that is currently also the case), and (b) the
> > language (sign languages would have the signed modality as default for
> > videos, other languages the multimodal modality; Latin would have the
> > written modality as default independent of the media carrier, and so
> > forth).
>
> 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.
>
> > 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.
>
> > Still, that is what I mean: while not changing the current setting for
> > the URLs, Wikipedia at some time recognized that the Glottocodes
> > exist, and are important enough to be now a standard information given
> > for each language.
>
> 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.
>
> > Instead, one could think of introducing an extension, say, with subtag
> > "g" (if that is not already assigned -- where can I find the list of
> > existing extensions?),
>
> https://www.iana.org/assignments/language-tag-extensions-registry
>
> > to be followed by a glottocode, in order to allow for a user to
> > indicate some variety that is well defined by its Glottolog entry.
> > Especially in cases where ISO does not have an appropriate language
> > code (yet), a user could use, for instance, mis-g-adha1238, where the
> > g-extension subtag adha1238 is the Glottocode for the extinct Adhari
> > language, which is not (yet) in ISO 639.  Perhaps even a better
> > solution can be imagined than using the special purpose ISO 639
> > identifier "mis" -- miscellaneous language (no ISO 639 code element is
> > assigned for this language or included in the part of ISO 639 used by
> > a given application).
>
> ISO 639-3/RA does have a well-established process to add (and modify, and
> delete) code elements to reflect linguistic realities. The reviewers may
> simply have not seen the documentation for Adhari (Old Azeri) that they
> were looking for. 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.
>
> --
> Doug Ewell, CC, ALB | Thornton, CO, US | ewellic.org
>
>
>
>