Subject: [Ltru] a modest proposal...

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 29 May 2008 12:38:26 -0700

Since:

1. We appear to be stuck.
2. We (most of us, anyway) would like to see this work completed.
3. We haven't a compelling-enough technical argument that resolves the issue.

I would like to submit a "modest proposal" for addressing the impasse:

1. Restore a *single* extlang to the ABNF.
2. Keep the Macrolanguage field in the registry for all encompassed languages, which information may be use by implementations however makes the most sense.
3. Cherry pick *only* the 'zh' (and possibly the 'ar') encompassed languages for registration as extlangs. This is done in the name of compatibility alone. 4. Permit implementations to treat the 'language' production as atomic (that is, the sequence "zh-yue" MAY be treated as if it were a single subtag but MAY be treated as separate subtags, notably by existing implementations). Note that the 'language' production is the one that includes both the primary and extended language subtags.

Thoughts?

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

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

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 29 May 2008 12:49:25 -0700

(laughing) Well, one is put in mind of Lilliputian disputes over eggs.

Addison

Addison Phillips

> -----Original Message-----
> From: Misha Wolf [mailto:[email-masked]]
> Sent: Thursday, May 29, 2008 12:43 PM
> To: Phillips, Addison; LTRU Working Group
> Subject: RE: [Ltru] a modest proposal...
>
> I'm relieved to see that you are not asking us to eat our children.
>
> Misha
>

---

From: Shawn Steele <[email-masked]>
Date: Thu, 29 May 2008 12:53:49 -0700

I would either like that, or the same thing, except where cmn and yue are allowed as aliases of zh-cmn & zh-yue

- Shawn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillips, Addison
Sent: Thursday, May 29, 2008 12:38 PM
To: LTRU Working Group
Subject: [Ltru] a modest proposal...

Since:

Thoughts?

Addison

Addison Phillips

---

From: Misha Wolf <[email-masked]>
Date: Thu, 29 May 2008 20:42:39 +0100

Misha

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 29 May 2008 13:05:38 -0700

Hi -

As a technical contributor...

> From: "Phillips, Addison" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>

> 2. Keep the Macrolanguage field in the registry for all encompassed
> languages, which information may be use by implementations however makes the most sense.
> 3. Cherry pick *only* the 'zh' (and possibly the 'ar') encompassed
> languages for registration as extlangs. This is done in the name of
> compatibility alone.

So far, this seems very reasonable.

> 4. Permit implementations to treat the 'language'
> production as atomic (that is, the sequence "zh-yue" MAY be treated as
> if it were a single subtag but MAY be treated as separate subtags,
> notably by existing implementations). Note that the 'language' production
> is the one that includes both the primary and extended language subtags.

I'd rather not put this in 4646bis.  If it's necessary to talk about this
kind of thing at all, it would belong in an update to the matching RFC.

Randy

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 29 May 2008 13:13:59 -0700

> kind of thing at all, it would belong in an update to the matching RFC.

I tend to agree. The main thing I'm doing here is pointing out the ramifications of doing this. I would assume that some text in the "Choice" and "extlang" sections would spell out why these languages were treated specially and what using the extended language subtag would mean.

Addison

---

From: John Cowan <[email-masked]>
Date: Thu, 29 May 2008 16:17:50 -0400

Shawn Steele scripsit:

> I would either like that, or the same thing, except where cmn and yue
> are allowed as aliases of zh-cmn & zh-yue

We have a long-standing rule of reason that says no two subtags mean
the same thing unless at least one of them is deprecated.  I'd be
reluctant to break that for the sake of supposed processing advantages,
since part of the Tao of the Internet is that the publisher never quite
knows how the reader will use the published text (or metadata).

-- 
John Cowan  [email-masked]   http://ccil.org/~cowan
Assent may be registered by a signature, a handshake, or a click of a computer
mouse transmitted across the invisible ether of the Internet. Formality
is not a requisite; any sign, symbol or action, or even willful inaction,
as long as it is unequivocally referable to the promise, may create a contract.
       --Specht v. Netscape
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Peter Constable <[email-masked]>
Date: Thu, 29 May 2008 13:24:40 -0700

Two of Jonathan Swift's works cited back to back on this list. It's good for us a satirist of his stature isn't observing. (Or maybe there is one waiting with work in progress that will leave us all terribly embarrassed.)

Peter

> Sent: Thursday, May 29, 2008 12:49 PM
> To: Misha Wolf; LTRU Working Group
> Subject: Re: [Ltru] a modest proposal...
>

---

From: Peter Constable <[email-masked]>
Date: Thu, 29 May 2008 13:28:34 -0700

It's a proposal that (whether with or without Shawn's variation) might be just the right compromise. (See my comments in another mail I just posted.)

We would still need to have text giving clear guidance on how to tag for Chinese.

Peter

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Shawn Steele
> Sent: Thursday, May 29, 2008 12:54 PM
> compatibility alone. 4. Permit implementations to treat the 'language'
> notably by existing implementations). Note that the 'language'
> production is the one that includes both the primary and extended
> language subtags.
>
> Thoughts?
>
> Addison
>
> Addison Phillips

---

From: John Cowan <[email-masked]>
Date: Thu, 29 May 2008 16:37:43 -0400

Phillips, Addison scripsit:

> 1. Restore a *single* [level of] extlang to the ABNF.

+1 to both.

> languages for registration as extlangs. This is done in the name of

I'd cherry-pick 'zh' and 'sgn' but not 'ar'.

> production is the one that includes both the primary and extended

I'd be okay with a motherhood note, but if this is to affect matching
it needs to go into 4647bis, and would cause 4647 to diverge from 2616.

-- 
"Well, I'm back."  --Sam        John Cowan <[email-masked]>
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Broome, Karen" <[email-masked]>
Date: Thu, 29 May 2008 13:39:29 -0700

I think this proposal may make the guidance task worse.

Karen

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Peter Constable
>Sent: Thursday, May 29, 2008 1:29 PM
>To: LTRU Working Group
>It's a proposal that (whether with or without Shawn's variation)
>might be just the right compromise. (See my comments in another mail
>I just posted.)
>
>> Phillips, Addison
>> 3. We haven't a compelling-enough technical argument that resolves
>the
>> issue.
>>

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 29 May 2008 13:52:53 -0700

> I'd cherry-pick 'zh' and 'sgn' but not 'ar'.

Really? 'sgn'?

> it needs to go into 4647bis, and would cause 4647 to diverge from 2616.

That's what I had in mind. Note that 4647 would not necessarily diverge from 2616. It could be done as a note in Lookup, for example and 2616 doesn't do Lookup.

Addison

---

From: John Cowan <[email-masked]>
Date: Thu, 29 May 2008 17:02:29 -0400

> Really? 'sgn'?

See my post responding to Peter.  I"d rather deprecate "sgn-US" to
"sgn-ase" rather than just "ase".

> That's what I had in mind. Note that 4647 would not necessarily diverge
> from 2616. It could be done as a note in Lookup, for example and 2616
> doesn't do Lookup.

True, but then it would deviate from how lookup is actually implemented
in various places, like JVM resource bundles and Apache (when filtering
fails).

-- 
Go, and never darken my towels again!           John Cowan
        --Rufus T. Firefly                      http://ccil.org/~cowan
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 29 May 2008 14:09:56 -0700

> "sgn-ase" rather than just "ase".

Noted.

> in various places, like JVM resource bundles and Apache (when filtering

Mmm.... maybe. But JVMs don't even do the current BCP 47 (well, most people's don't... they can be made to, at least with the most modern JVMs :-) ). Note too that I said originally that they MAY treat the primary-extlang sequence as atomic, not that it is required. Creating a new algorithm ("Extended Lookup"?) might be preferable to altering an exiting algorithm.

Addison

Addison Phillips

> From: John Cowan [mailto:[email-masked]]
> Sent: Thursday, May 29, 2008 2:02 PM
> To: Phillips, Addison
> Cc: John Cowan; LTRU Working Group

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 29 May 2008 14:21:31 -0700

> I think this proposal may make the guidance task worse.

Are you really saying that Quechua, Cree, Zapotec, Konkani, Malay, Swahili and the rest somehow make Chinese tagging guidance *easier*? I'm totally mystified now about what you think would work.

Guidance under this plan for tagging Chinese could be very straightforward. Perhaps:

--
When selecting a tag for a Chinese language, that tag SHOULD always use the specific extended language subtag. For example, tag Mandarin Chinese content with a tag starting with "zh-cmn", adding any necessary additional subtags for script, region, or variant as appropriate. If the specific variety of Chinese is not known or is not important to the content, the primary language subtag 'zh' MAY be used without an extended language subtag to form the complete tag.
--

Addison

Addison Phillips

> Broome, Karen
> Sent: Thursday, May 29, 2008 1:39 PM
> To: Peter Constable; LTRU Working Group

---

From: Leif Halvard Silli <[email-masked]>
Date: Fri, 30 May 2008 02:01:06 +0200

Phillips, Addison 2008-05-29 21.38:

> 2. Keep the Macrolanguage field in the registry for all [...]

Will encompassed Chinese languages have the macrolanguage field?

It is good if all macro and encompassed languages are treated the 
same way. But then it is perhaps also questionable if there are 
two such important exceptions.  Chinese is a classic example of 
what "macrolanguage" is or means.

 > 3. Cherry pick *only* the 'zh' (and possibly the 'ar')
 > encompassed languages for registration as extlangs. This is
 > done in the name of compatibility alone.

I support including 'sgn'. But what does "in the name of 
compatibility alone" mean? That it isn't linked to macrolangauge? 
If it *is* linked to macrolanguage, then you can't explain it as a 
compatibility issue and vice-versa.

 > 4. Permit implementations to treat the 'language' production as
 > atomic (that is, the sequence "zh-yue" MAY be treated as if it
 > were a single subtag but MAY be treated as separate subtags,
 > production is the one that includes both the primary and
 > extended language subtags.

Might all these exceptions to 'zh' only hamper Chinese and Sign 
languages (and in the end perhaps make this tagging style unstable?)?

ALTERNATIVE PROPOSAL: Let's cherry pick in some way or another. 
But let's have extlang as a macrolanguage thing, and thus explain 
it not as an exception for compatibility reasons, but as one of 
two method for handeling the macrolanguage identification.
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 29 May 2008 17:18:23 -0700

> Will encompassed Chinese languages have the macrolanguage field?

Perhaps you should read the current draft?

> what "macrolanguage" is or means.

See: "elephant in the room"

> compatibility issue and vice-versa.

It means: it is not linked to "macrolanguage", a feature of ISO 639-3. It is strictly recognition that past tagging practice has used "zh-*" and "sgn-*". It has nothing to do with anything else.

> languages (and in the end perhaps make this tagging style unstable?)?

Uh...

1. "sgn" is not a macrolanguage and should not be.

2. The above should not hamper Chinese or sign languages. Why would you think so? You seem to support extlang. This is extlang for those languages solely.

> ALTERNATIVE PROPOSAL: Let's cherry pick in some way or another.

You are welcome to suggest another cherry picking device.

> two method for handeling the macrolanguage identification.

Well, no. The point of the "modest proposal" was to try and break the logjam in which some of us insist that we'd be better off without extlangs and others insist we'd be better off with them.

You are proposing having TWO methods tagging the same language variety, an idea that is antithetical to language tagging and which presents more problems than it solves.

Addison

---

From: "Debbie Garside" <[email-masked]>
Date: Fri, 30 May 2008 01:43:12 +0100

Never mind elephants... I feel like a goldfish... in a bowl... going
round... and round... and round... and round...

Debbie

> Sent: 30 May 2008 01:18
> To: Leif Halvard Silli; LTRU Working Group
> > It is good if all macro and encompassed languages are
> treated the same
> > way. But then it is perhaps also questionable if there are two such
> > important exceptions.  Chinese is a classic example of what
> > "macrolanguage" is or means.
>
> >  > 3. Cherry pick *only* the 'zh' (and possibly the 'ar')  >
> compatibility
> > alone" mean? That it isn't linked to macrolangauge?
> It means: it is not linked to "macrolanguage", a feature of
> ISO 639-3. It is strictly recognition that past tagging
> practice has used "zh-*" and "sgn-*". It has nothing to do
> with anything else.
>
> >
> production as  >
> > atomic (that is, the sequence "zh-yue" MAY be treated as if
> it  > were
> > a single subtag but MAY be treated as separate subtags,  >
> notably by
> > existing implementations). Note that the 'language'
> >  > production is the one that includes both the primary and  >
> 2. The above should not hamper Chinese or sign languages. Why
> would you think so? You seem to support extlang. This is
> extlang for those languages solely.
>
> >
> > But let's have extlang as a macrolanguage thing, and thus
> explain it
> > not as an exception for compatibility reasons, but as one of two
> > method for handeling the macrolanguage identification.
>
> Well, no. The point of the "modest proposal" was to try and
> break the logjam in which some of us insist that we'd be
> better off without extlangs and others insist we'd be better
> off with them.
>
> You are proposing having TWO methods tagging the same
> language variety, an idea that is antithetical to language
> tagging and which presents more problems than it solves.
>
> Addison
>
>

---

From: John Cowan <[email-masked]>
Date: Fri, 30 May 2008 00:44:49 -0400

> round... and round... and round... and round...

The only way out is down.  Or is it up?  It doesn't matter: the way up
and the way down are one and the same.  You *can* step into the same
goldfish bowl twice.

-- 
Overhead, without any fuss, the stars were going out.
        --Arthur C. Clarke, "The Nine Billion Names of God"
                John Cowan <[email-masked]>
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Leif Halvard Silli <[email-masked]>
Date: Fri, 30 May 2008 15:07:57 +0200

Phillips, Addison 2008-05-30 02.18:

> It means: it is not linked to "macrolanguage", a feature of ISO
> 639-3. It is strictly recognition that past tagging practice
> has used "zh-*" and "sgn-*". It has nothing to do with anything
> else.

So the currently grandfathered "zh-cmn" etc will remain 
grandfatherd. The tagger will find "zh" and "cmn"  separately, in 
order to construct "zh-cmn". But when something has been tagged 
"zh-cmn", then it may be treated either as 'zh' with an extlang, 
or as an atomic tag. When treated as atomic, it is in reality 
treated as one of the grandfathered tags -- as long as it is a 
grandfathered tag.

> You are proposing having TWO methods tagging the same language
> variety, an idea that is antithetical to language tagging and
> which presents more problems than it solves

I meant that zh-* should be allowed not for strict compatibility 
reasons, as you said, but in order to tag macrolanguage 
relationship. Still one method, though. Of course, this means that 
sgn-* would  have to be allowed for another reason -- for the 
compatibility reason.

The text below serves as background for the following question: Is 
your proposal, that the language production might be read as 
atomic, only relevant for the Chinese tags? Or did you also have 
'ar-*' and 'sgn-*' in mind?

Background:

The macrolangauge field came up, as I understood it, because there 
were no extlang. In Doug's draft, all encompassed language subtags 
have that field. Except the grandfathered tags "zh-cmn" etc.

But my question is: What macrolanguge information comes with 
'zh-cmn' when it is read as an atomic? The answer should be, that 
when read as an atomic --- grandfathered zh-cmn -- the registry 
says that it is a synonym of 'cmn'. The 'cmn' then has a 
Macrolanguaga field which might be used by the application in 
order to find 'zh' etc.

However, if you read 'ar-*' or 'sgn-*' as an atomic, then there is 
no grandfathered tags that they match. And thus no place to find 
the macrolanguage information (for 'ar-*' -- unrelevant to 'sgn-*').
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 30 May 2008 09:38:45 -0700

I've been thinking a bit about Addison's proposal; I've been at a
conference, and haven't had time to discuss it internally. I'll answer more
later, but one note on Shawn's approach:
We do already have a mechanism in the standard for dealing with
equivalences, one that people already have to handle.

That is to make one of them the Preferred-Value of the other. That is, we
could mandate that for all the extlang cases that we permit, like
"zh-yue..." and "yue...", both forms would be valid, and one would be the
Preferred-Value. That may actually be workable.

Mark

-- 
Mark

---

From: "Phillips, Addison" <[email-masked]>
Date: Fri, 30 May 2008 09:49:35 -0700

Leif opined:
> grandfatherd.

No. It will be reclassified as redundant under this proposal.

> The tagger will find "zh" and "cmn"  separately, in
> order to construct "zh-cmn".

Yes.

> But when something has been tagged

No. It isn't "in reality treated as one of the grandfathered tags".

What I meant by atomic is that a sequence such as "zh-cmn" could be treated as if it were a single subtag. It is not required to be treated this way. But it is permitted. Thus the tag "zh-cmn-Hans-CN" contains four subtags (zh, cmn, Hans, CN), but some operations (notably the Lookup algorithm in RFC 4647) could treat the "zh-cmn" sequence as if it were a single subtag meaning "Mandarin Chinese".

> sgn-* would  have to be allowed for another reason -- for the

I know that's what *you* mean, but in my proposal we are cherry-picking 'zh' and the cherry-picking has nothing to do with its status as a macrolanguage. We are picking it purely because people have a long-standing association between the subtag 'zh' and the various Chinese languages and because those same people think that maintaining this tag-level relationship is of some value.

I think you might be ascribing too much meaning to the concept of macrolanguage. Macrolanguage records a particular relationship that exists between language *codes* assigned by ISO 639, which is that some language codes assigned by ISO 639-3 are encompassed by codes assigned previously to a broader range of languages. The macrolanguage has little  to do with the *actual* linguistic relationship between the encompassed languages (save that the association tends to exist because the languages are related somehow). Many languages that do not have a macrolanguage mapping are actually more closely related or mutually intelligible than some pairs of macrolanguage related languages.

> 'ar-*' and 'sgn-*' in mind?

:: sigh ::

My proposal was to allow/permit *some* processes to treat the primary-extlang combination as if it were atomic in *some* circumstances. In particular, I had in mind the lookup algorithm, where the fallback would be permitted to go like this:

zh-yue-Hans-CN
zh-yue-Hans
zh-yue
(default)

Or like this:

zh-yue-Hans-CN
zh-yue-Hans
zh-yue
zh-Hans-CN
zh-Hans
zh
(default)

Whereas the current behavior (which applies even to grandfathered tags) is:

zh-yue-Hans-CN
zh-yue-Hans
zh-yue
zh
(default)

> have that field. Except the grandfathered tags "zh-cmn" etc.

The macrolanguage field in the registry is an informational field determined solely by the ISO 639-3 standard. All encompassed subtags have it, regardless of whether they would be permitted as extlang. *IF* we restore extlang, the grandfathered items that match extlang would become redundant. However, under the current draft (no-extlang), these are just grandfathered tags, similar to "no-nyn" and "i-enochian". In all cases, these tags would be deprecated in favor of non-atomic subtag sequences.

> 'zh-cmn' when it is read as an atomic?

You are confusing processing the tag and the meaning of specific subtags.

> The answer should be, that

I think you are making a series of possibly-erroneous assumptions here.

First, any extlangs will have a field called "Prefix" that indicates what subtag they are required to follow. Thus, 'cmn' and its extlang kin will have a Prefix field with the value 'zh'. There is no need to use the Macrolanguage field to find this out, nor any dependency on any grandfathered tag. Similarly a subtag such as 'ase' (American Sign Language) could have a prefix of 'sgn'.

Some non-extlangs will have a Macrolanguage field. For example, 'nn' (Nynorsk) would have one, even though it is not an extlang and has no Prefix.

Secondly, the registry will NOT say that "zh-cmn" (considered as a redundant tag) is a synonym for 'cmn'. Redundant tags in the registry can be ignored because their meaning is otherwise assigned by individual subtags. If we were to keep the current setup (no extlang), the tag "zh-cmn" would remain grandfathered and would be deprecated in favor of 'cmn'. But this is *not* the same thing as being a synonym for it.

> the macrolanguage information (for 'ar-*' -- unrelevant to 'sgn-*').

Grandfathered tags have nothing to do with this proposal. The fact that some would become redundant is a Good Thing. In any event, many more grandfathered tags would be either redundant or deprecated with any of the proposals on the table at present. Being valid (which these tags will remain forever) is not the same as being a good tagging choice (which most of the affected grandfathered tags will cease to be; redundant tags, of course, could be removed from the registry as they are merely historical curiosities).

Addison

---

From: Peter Constable <[email-masked]>
Date: Fri, 30 May 2008 14:52:26 -0700

> I think you might be ascribing too much meaning to the concept of
> macrolanguage. Macrolanguage records a particular relationship that
> exists between language *codes* assigned by ISO 639, which is that some
> language codes assigned by ISO 639-3 are encompassed by codes assigned
> previously to a broader range of languages. The macrolanguage has
> little  to do with the *actual* linguistic relationship between the
> encompassed languages (save that the association tends to exist because
> the languages are related somehow).

Well, a bit more than that: they have to be closely related. English and Hindi are related; many linguists consider Mandarin and Tibetan to be related. But these would never have been combined in a macrolanguage

But as for what can be assumed in terms of intelligibility between encompassed languages, your follow-on statement is certainly valid:

> Many languages that do not have a
> macrolanguage mapping are actually more closely related or mutually
> intelligible than some pairs of macrolanguage related languages.

Peter

---

From: Leif Halvard Silli <[email-masked]>
Date: Sat, 31 May 2008 03:12:11 +0200

Peter Constable 2008-05-30 23.52:
 >> From:  Phillips, Addison

>> [...] little to do with the *actual* linguistic relationship

 >
 > Well, a bit more than that: they have to be closely related.

 > But [...] your follow-on statement is certainly valid:
 >
 >> Many languages that do not have a macrolanguage mapping are
 >> actually more closely related or mutually intelligible than
 >> some pairs of macrolanguage related languages.

Since a request for macrolanguage A can be a request for language 
C even if it statistically more often is a request for language B, 
a macrolanguage situation *requires* fallbacks between defined -- 
but different -- languages, whether they are inteligible or not.
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Martin Duerst <[email-masked]>
Date: Sat, 31 May 2008 15:32:40 +0900

I don't expect this to contribute to the solution of the current
main discussion, so I have marked this off topic.

At 06:52 08/05/31, Peter Constable wrote:
>Well, a bit more than that: they have to be closely related. English and 
>Hindi are related; many linguists consider Mandarin and Tibetan to be 
>related. But these would never have been combined in a macrolanguage
>
>But as for what can be assumed in terms of intelligibility between 
>encompassed languages, your follow-on statement is certainly valid:
>

The term "mutually intellegible" has been used a lot, in my understanding
implicitly always with a binary yes/no implication.

In my experience, I understand "mutally intellegible" more in terms
of time. It may take me a few seconds to adapt to somebody's English
accent e.g. from California, slightly longer for somebody from Boston,
ever longer for New York or Texas, several minutes or close to an hour
to feel confident with an Australian or Indian accent, and so on. In
each case, it's not only accent, it's also some vocabulary shift.

It may then take me several days to start to understand some Duch,
and maybe several weeks for some of the Scandinavian languages,
although on the scale of days or weeks, I have more experience
with Romance languages.

Was/is there any consideration about such a scale when defining
languages e.g. for ISO-639-3?

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: John Cowan <[email-masked]>
Date: Sat, 31 May 2008 14:08:37 -0400

> languages e.g. for ISO-639-3?

See http://www.sil.org/iso639-3/scope.asp#I .  Of course a great deal
of individual judgement is required.

-- 
John Cowan   <[email-masked]>   http://www.ccil.org/~cowan
One time I called in to the central system and started working on a big
thick 'sed' and 'awk' heavy duty data bashing script.  One of the geologists
came by, looked over my shoulder and said 'Oh, that happens to me too.
Try hanging up and phoning in again.'  --Beverly Erlebacher
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Peter Constable <[email-masked]>
Date: Sat, 31 May 2008 13:09:07 -0700

> From: Martin Duerst [mailto:[email-masked]]

> of time...

> languages e.g. for ISO-639-3?

Any language variety can be learned, given sufficient time and a sufficient level of interest and desire. There is, indeed, a gray scale here: it takes limited effort for a machinist from Maine to learn to communicate with his floor manager from South Carolina, and he's probably fairly motivated to do so; he's far less likely to learn to communicate with a Frisian (in Frisian) that asks him for directions on a street corner.

Somewhat correlated to the amount of time and ease in learning (though not necessarily motivations) variety A by a native speaker of variety B is the feasibility at devising an orthography and being able to produce literature that can be understood *readily and effectively* by speakers from both A and B. Of course, the skill of reading involves its own learning process, but depending on the distance between A and B there will be some additional learning cost on the part of A or B (or both) to learn to read a common literature.

(Of course, with audio publications, there is a direct correlation between time/ease of learning and how readily and effectively a publication intended for both can be understood.)

Now, obviously when talking about decisions that impacted ISO 639-3, it is relevant to consider decisions made in preparation of Ethnologue. Here, we should distinguish between developed languages with established literary traditions and undeveloped languages with no literary tradition (or traditions that died out some generations ago).

For the latter, an ideal development methodology strikes a balance between (a) clumping together many varieties to reduce the number of separate development projects involved, and (b) ensuring that literature really is effectively understood without costly and de-motivating barriers in literacy instruction. There are also other factors: e.g. speakers of B may understand A quite well, but also have very negative attitudes; and other social, political or economic factors may be significant. These are the kinds of considerations that have often been involved when input has been provided into Ethnologue, though I can't speak to how well and appropriately they have been evaluated in individual cases or how consistently across cases.

For the former, the language identities are generally a given, and when changes do occur, they are very often driven by socio-linguistic factors rather than purely linguistic ones (the analogy would be how motivated B would be to learn A rather than how long would it take).

Btw, an implication of the above is that it is mutual *non*-intelligibility that is generally most interesting. (If A is intelligible to speakers of B, they can potentially use resources prepared for A, whether or not B is intelligible to speakers of A. But if neither can understand resources prepared for the other, then separate resources are likely required.)

Peter