Subject: RE: [Ltru] Re: Moving Forward

From: "Peter Constable" <[email-masked]>
Date: Thu, 14 Apr 2005 08:18:56 -0700

> From: McDonald, Ira [mailto:[email-masked]]

> Peter - your proposal appears to be wobbling between
> (1) One new field
>     - ExpectedScript (complete list)
> (2) Two new fields
>     - DefaultScript (do NOT use a script subtag)
>     - ExpectedScript (not including DefaultScript value??)

No. Last week I proposed that there be one field along the lines of
DefaultScript. Various people objected, promoting AssociatedScript
instead, so I asked that that be changed to ExpectedScriptSubtags. Then
yesterday Frank pointed out a problem with that approach, pushing for
having a DefaultScript field, and I agreed with his argument.

So, either way, I support one new field; I favour having that be
DefaultScript, but if it's to be the other approach, I think it should
be called ExpectedScriptSubtags.

> If this registry (and RFC3066bis) don't make VERY clear
> when script subtags MUST NOT be used, then we're making
> no headway.

I'm in general agreement. I would not be so restrictive as to say MUST
NOT, however: I think there are exceptional scenarios in which it may be
appropriate to use en-Latn-GB. But it definitely should be made clear
that such tags should not be used in general.

Peter Constable

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

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 14 Apr 2005 08:56:43 -0700

I think part of the problem is that it was not set out clearly, until your
message Peter, exactly what data would be expected for the 3 cases:

A. We know the language is customarily used with more than one script
B. We know the language is customarily used with one script
C. The information for A or B is not available in the registry: either just
not entered yet, or hard to find out.

So we could have any of the following strategies, with XX, or YY, or ZZ
chosen to be the least misleading label for whatever the situation is.

A.
XX: Cyrl
XX: Latn
B.
XX: Latn
C.
<blank>

or

A.
<blank>
B.
YY: Latn
C.
<blank>

or

A.
ZZ: Cyrl
ZZ: Latn
B.
<blank>
C.
<blank>

As I said before, I have not yet seen an implementation scenario where we
need the infomation in B, and both the strategies that use it require
entering in much more data than the ZZ scenario. So I'd like to see a
scenario that drives B clearly stated. But frankly, I don't care much about
whichever approach is chosen as long as

1. it is documented so that C behaves reasonably, because it is reasonably
easy to fill out the values for A and B for either approach for the
high-runner languages, but we don't want the absence of information to be
misread.
2. As Peter says, we mustn't say MUST NOT, however: there are scenarios in
which it may be appropriate to use en-Latn or ko-Latn.

‎Mark

----- Original Message ----- 
From: "Peter Constable" <[email-masked]>
To: "LTRU Working Group" <[email-masked]>
Sent: Thursday, April 14, 2005 08:18
Subject: RE: [Ltru] Re: Moving Forward

Peter Constable

---

From: John Cowan <[email-masked]>
Date: Thu, 14 Apr 2005 14:34:08 -0400

> not entered yet, or hard to find out.

You omit:

  D. The language is not customarily used with any script.  (Any language may
  be transcribed in writing, as any language may be spoken over the radio;
  but just the same, Chinese is written and Burushaski is not, as Navajo is
  regularly broadcast and Akkadian is not.)  This does not apply to current
  639-2 languages but will apply to 639-3 languages.

> scenario that drives B clearly stated. 

>From what I can understand, which is by no means sure, the advocates
for B information want it so that they can vet tags like en-Latn(-GB)
and warn against or reject them.  Without B information we cannot
distinguish between en-Brai (anomalous, so correct) and en-Latn (undesirable).

> which it may be appropriate to use en-Latn or ko-Latn.

I believe the desire of this part of the WG is to reject en-Latn
absolutely (because it is the default) while still retaining the
possibility of ko-Latn.

-- 
All Gaul is divided into three parts: the part          John Cowan
that cooks with lard and goose fat, the part            www.ccil.org/~cowan
that cooks with olive oil, and the part that            www.reutershealth.com
cooks with butter. -- David Chessler                    [email-masked]

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 14 Apr 2005 12:47:21 -0700

1. I don't see that separating out D from C adds anything. But if you have a
use-case, that would be interesting.

> for B information want it so that they can vet tags like en-Latn(-GB)
But for that, for the NC, they don't need the information that the default
script is Latn. All they need to know is that if there are two scripts in
the registry, then in that situation put no script in the tag.

> absolutely (because it is the default) while still retaining the
*Requiring* the default to be rejected is absolutely the wrong thing to do.
Suppose that I am querying a database of phrase books for Thai. They contain
a mixture of those using Latin and those using Thai script. I can issue 3
queries:

1. th-Thai - give me only the ones in Thai, and written in the Thai script
2. th-Latn - give me only the ones in Thai, using a Latin transcription
3. th - give me anything.

This is a perfectly sensible thing to do. But if #1 is illegal, it does not
let users make a perfectly useful discrimination between #1 and #3.

The right thing to do is to indicate, as others have indicated, is that in
the normal case (NC) for stuff like webpage selection, you should not use
the script unless there are two scripts listed in the registry.

‎Mark

---

From: John Cowan <[email-masked]>
Date: Thu, 14 Apr 2005 16:09:55 -0400

> the registry, then in that situation put no script in the tag.

I don't understand that sentence at all.  To reiterate:

If I present the tag "en-Brai-YY" to a tag validator, it should reject the
tag as invalid, because region YY does not exist.  If I present the tag
en-Latn, it should at least warn me that using Latn with en is undesirable.
If I present the tag en-Brai, it should accept it.  This can only be done
if it's known that the default script for en is Latn.

You may not consider this use case worth supporting, but it *is* a use case.

> 3. th - give me anything.

Ah, but that's a constraint on language *ranges*, which are not semantically
the same as language *tags*.   Language ranges are a concept belonging to
the matching draft, which may want to end up supporting things like "th-*"
or "th-*-*" that aren't tags at all.

We are talking here about a constraint on tags and only on tags.

> let users make a perfectly useful discrimination between #1 and #3.

What would be illegal on this view (not necessarily mine, I'm just trying to
be a mediator) is a document or other object being tagged th-Thai, not a
request for th-Thai.

> use-case, that would be interesting.

I was thinking that if you know there is no script, then you should reject
any attempt to add one except in "unusual script" mode.  But perhaps that
is the same treatment that should be given to script-unknown languages.

-- 
Is not a patron, my Lord [Chesterfield],        John Cowan
one who looks with unconcern on a man           http://www.ccil.org/~cowan
struggling for life in the water, and when      http://www.reutershealth.com
he has reached ground encumbers him with help?          [email-masked]
        --Samuel Johnson

---

From: "Debbie Garside" <[email-masked]>
Date: Thu, 14 Apr 2005 22:53:12 +0100

> the script unless there are two scripts listed in the registry.

I agree with this, it seems perfectly logical... but... 

If the tag for Sirenik is ysr-RU how do you know what the default script is?

Have I missed something here? 

Debbie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Mark Davis
> Sent: 14 April 2005 20:47
> To: John Cowan
> Cc: [email-masked]
> >   D. The language is not customarily used with any script.  (Any
> language
> may
> > > 2. As Peter says, we mustn't say MUST NOT, however: there are
> scenarios
> in