Subject: Re: [Ltru] Questions before submitting draft-4645bis-05

From: "Doug Ewell" <[email-masked]>
Date: Sun, 4 May 2008 19:23:18 -0600

Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:

> Is it Lynghgam or Lyngngam?

It's Lyngngam if you copy the name correctly from the ISO 639-3, and 
Lynghgam if you copy from an e-mail posting without cross-checking. 
Good catch; it's fixed now.

> Though I don't feel strongly about the comment as such, I do think 
> Stephane's rationale regarding FX applies here: from the history 
> recounted on the ietf-languages list, it sounds like no one is known 
> to have ever actually *used* kha for Lyngngam when tagging material. 
> If that is correct, the comment doesn't seem to have much point.

I'm not opposed to this line of thinking.  Debbie had proposed the 
comment and I didn't recall anyone disagreeing.  I'll send out the draft 
with the comment, and we can see what sort of Rough Consensus™ emerges.

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

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 4 May 2008 19:36:25 -0600

Leif Halvard Silli <lhs at malform dot no> wrote:

> Hence, I propose this text, to follow immediately after Nicolas' text 
> above:
>
> An application which tries to match a macrolanguage of a primary 
> language subtag, as specified above, SHOULD, on the condition that the 
> macrolanguage covers only 2 languages, also lookup the alternative 
> representation of that macrolanguage.
>
> Examples:
> 1 nn  -> no -> nb
> 2 nb  -> no -> nn
> 3 tw  -> ak -> fat
> 4 fat -> ak -> tw

This is starting to become too detailed and too dependent on special 
cases.  Matching at this level is too much an individual decision -- see 
Mark's comment about Breton falling back to French -- and the condition 
that the macrolanguage encompasses exactly two languages seems unrelated 
to whether there is any mutual intelligibility between the two.  I don't 
favor this.

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 4 May 2008 19:43:53 -0600

Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:

> If there's any question, then the discussion and subsequent decision 
> should be left to [email-masked] and the LSR.  We're supposed 
> to be focused on the process here, and the content of the "bulk 
> update" we hand off to IANA should not in general require item-by-item 
> discussion.  If we are going to get bogged down in the details of any 
> *specific* subtags, I suggest we consider removing each such subtag 
> from 4645-bis, and request that their proponents submit them as 
> individual requests to [email-masked].

The item in question is explicitly a special-case exception: it's one of 
the handful of ISO 3166-1 exceptionally reserved code elements that 
we're turning into region subtags, and it's the only one that already 
exists in the Registry.  Contributors to ietf-languages aren't allowed 
to individually request any two-letter region subtag; by rule those must 
be included or excluded by the governing RFC.  Consequently, I believe 
this thread (which should be short) belongs here.

---

From: Leif Halvard Silli <[email-masked]>
Date: Mon, 05 May 2008 05:07:11 +0200

> to whether there is any mutual intelligibility between the two.  I don't 

Firstly, I interpreted Nicolas' - and thus mine - proposal as a "backup 
mechanism" for server/user applications if the language list does not 
give a match. Having said that, then,

   1. how does my proposal take avay the individual's ability to decide
      on his/her own? (Usecase, please.)
   2. Only taking place if the MAY-lookup-macrolanguage rule that
      Nicolas proposed, is followed,  how is it then, for the affected
      languages, really any different from his proposal?
   3. Yes, I understand Breton/French can be a good fallback for breton
      speakers and even more so Romanian for Moldovan speakers. But what
      relevance does that have to this proposal?

And as for Mark's reply to my message, he said that, quote:

    "Moreover, focusing on macrolanguages can overshadow other better
    fallback".

You have just teached me about the uselessness of using RFCs to send 
messages. So let's forget that and look at things calmly. Doing what I 
propose is a discrete and spesific use of the macrolanguage consept. We 
should not avoid doing a logical thing just to send a message.
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 4 May 2008 21:59:15 -0600

Leif Halvard Silli <lhs at malform dot no> wrote:

> Firstly, I interpreted Nicolas' - and thus mine - proposal as a 
> "backup mechanism" for server/user applications if the language list 
> does not give a match.

Nicolas' proposal is very consistent with what Section 4.1 of 
draft-4646bis already says about using macrolanguages for matching.  It 
presumes only that there may be some useful relationship between the 
macrolanguage and its encompassed languages, which is generally true 
although the nature of the relationship is undefined.  It uses the word 
MAY carefully to reflect this.

Your addendum goes beyond this, presuming a useful relationship between 
languages which are encompassed by the same macrolanguage.  That is a 
considerably more tenuous presumption, and has nothing really to do with 
whether there are only two encompassed languages.  It appears to be 
tailored to the specific cases (Norwegian and Akan) where the 
encompassed languages are more like dialects.  It does not necessarily 
apply to other cases like Northern Uzbek and Southern Uzbek, which are 
also the only two languages encompassed by a single macrolanguage 
(Uzbek) but which do not appear to share a large degree of mutual 
intelligibility.

At the least, it's not the kind of thing that should be slipped in at 
the 11th hour without some serious discussion, which I realize is what 
you are trying to initiate.

> Having said that, then,

The word SHOULD really doesn't belong in something like this, even when 
dovetailed onto Nicolas' MAY.  Nicolas' wording:

"If no tag matches the language priority list, application MAY try to 
match the macrolanguage (if exist in the registry) of the remaining 
primary language subtag."

seems more appropriate.

>      languages, really any different from his proposal?

Going from Twi "up to" Akan is not at all the same as going "back down 
the hill" to Fanti, from a tag-matching standpoint.

>      speakers and even more so Romanian for Moldovan speakers. But
>      what relevance does that have to this proposal?

I believe Mark's point is that, when the "macrolanguage" connection 
between languages becomes this tenuous and ill-defined, it's best to let 
users defined their preferred fallback instead of using SHOULD in this 
way.

> propose is a discrete and spesific use of the macrolanguage consept.
> We should not avoid doing a logical thing just to send a message.

I don't think anyone here is trying to "send a message," as I said 
earlier.  We want to define the best matching strategies, and to 
recognize when we should stop defining because the individual user has 
better information than we do.

---

From: Leif Halvard Silli <[email-masked]>
Date: Mon, 05 May 2008 11:45:39 +0200

Doug Ewell 2008-05-05 05.59:
>>> > Hence, I propose this text, to follow immediately after Nicolas' > 
>>> text
>>> > above:
>>> >
> draft-4646bis already says about using macrolanguages for matching.  
> It presumes only that there may be some useful relationship between 
> the macrolanguage and its encompassed languages, which is generally 
> true although the nature of the relationship is undefined.  It uses 
> the word MAY carefully to reflect this.

It uses MAY to indicate that the implementor should evaluate before 
implementing this behaviour.

> Your addendum goes beyond this, presuming a useful relationship 
> between languages which are encompassed by the same macrolanguage.  
> That is a considerably more tenuous presumption, and has nothing 
> really to do with whether there are only two encompassed languages.  
> It appears to be tailored to the specific cases (Norwegian and Akan) 
> where the encompassed languages are more like dialects.  It does not 
> necessarily apply to other cases like Northern Uzbek and Southern 
> Uzbek, which are also the only two languages encompassed by a single 
> macrolanguage (Uzbek) but which do not appear to share a large degree 
> of mutual intelligibility.

I see only one possibly problematic situation: Given macrolangauge A 
with microlangauge B and C, and if the tag for macrolanguage A in 
reality only were used for resources from microlanguage B and no 
association from C to A genererally were assumed, then, firstly it would 
be a strange macrolangauge tag, and secondly, in that strange situation 
to have a request for B ending up as a request for C, could be 
problematic, provided the server were offering C, but not B. 

As workaround, the server could then link A to a third default language D.

Or, if there were no other options than C, then I see no problem with 
serving it.

> The word SHOULD really doesn't belong in something like this, even 
> when dovetailed onto Nicolas' MAY.  Nicolas' wording:
>

Given the situation I mentioned above, I will change the wording from 
SHOULD to MAY. Does that make it better, do you feel?

> the hill" to Fanti, from a tag-matching standpoint.

If both actively share the macrolangague tag, then I see no problem. 
Then there would allready be a condidition in which users of both 
languages meet each others languages. And then it would be better to 
formalize that relationship, so to speak. It is easier to break out of a 
relationship that is aknowledged, than having to break out, somehow, 
from a relationship that the parties and the thirdparties do not 
aknowledge as existing, but which is still very evident. I think I speak 
from experience.

> between languages becomes this tenuous and ill-defined, it's best to 
> let users defined their preferred fallback instead of using SHOULD in 
> this way.

I will change the proposal to say MAY.

I felt that Mark's comments were quite general. More spesificly, he 
compared Language Preference Lists which the user or the 
developer/localizer defines, with Nicola's MAY-fallback-mechanism, which 
only steps in *after* that choices of the Language Preference List.

My addendum will not prevent users from adding their preferrered 
languages. The languages that they add will come before the effect of 
mine and Nicolas' proposal.

The thing is also that a users might not understand what he does - or 
rather the consequences thereof - if he for instance excludes Nynorsk 
from his preferred languages. And the possible burdon the user suffer 
really is minuscle and seldom and easily worked around.

Trying to save the user from the consequenes of making affectious and 
pointless "I say no" choices of the kind "oh, I hate Nynorsk so I don't 
include that" is good. The language preference list of a browser is not 
a voting machine.

> better information than we do.

Then I hope that my proposal can be let in or let out based on a 
concrete evaluation, rather  than being based on general points about 
the concept of macrolanguage.
-- 
leif halvard silli