Subject: [Ltru] Re: [psg.com #882] registry should copy non-English fields from ISO documents

From: "Doug Ewell" <[email-masked]>
Date: Tue, 12 Apr 2005 23:06:19 -0700

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

> Currently, here's where I think we are:
>
> Those in opposition are Randy, Addison, Mark, Peter, and Robin.
> Those in support are Jefsey, John, Ned, and Doug.

I prefer to be counted as "neutral" rather than "in support."  I meant
it when I said 51-49: definitely not a decisive margin.  I see both
sides of this one.

> Both John and Doug, as well as several of those who are neutral,
> are opposed to Jefsey's provisos.

Correct there.

I note that if the inclusion of French continues to be portrayed as a
first step toward adding more translations, I will change my vote on the
French question to a clear "no."

-Doug Ewell
 Fullerton, California
 http://users.adelphia.net/~dewell/

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

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 12 Apr 2005 23:23:55 -0700

Mark Davis <mark dot davis at jtcsv dot com> wrote:

> 1. We add one field to the language records:
>
> Associated_Script:
>
> This field is optional; if present, it will occur 2 or more times.
> This field is used to indicate languages commonly written in two or
> more scripts. Languages that have this field SHOULD use a script
> subtag. Other languages SHOULD NOT use a script subtag unless it adds
> some useful information (for example, the Brai subtag for a Braille
> text) or in the context of certain types of matching operations.

That's a bit more palatable than some previous approaches.

Would the recommendation against using a script subtag with a
non-associated-script language subtag be on roughly the same level as
the recommendation against using a variant subtag without its
recommended prefix?  (Tough sentence; read it again until it makes
sense.)  In other words, not forbidden, but sort of an eye-roller?

> It is expected that it would be populated over time, with the
> registration process. We add this to the registration form, so that
> associated scripts can be added. We can put in values for the high-
> runner cases, since those are well-known. For example:
>
> %%
> Type: lang
> Subtag: sr
> Description: Serbian
> Associated_Script: Cyrl
> Associated_Script: Latn
> %%

I guess we got rid of multiple values separated by semicolons, since
that became confusing with the language descriptions.

*sigh*

All right, I guess I can live with the multiple Associated_Script
subtags.  Please, let's try to keep this to a minimum as long as we're
using record-jar and not XML.  I'm still trying to figure out how to
implement this.

> We describe (informatively) in the LT doc that these fields can be
> useful in matching, and note that in many kinds of matching the script
> code should be omitted to maximize compatibility unless there is more
> than one associated-script value present. We leave any further text to
> be worked out in the matching document, since that is the scope of
> that document, and beyond the scope of the LT document.

So normal tag generation works the same as always, but there might be a
red flag (or in my case, a yellow light) telling the user who generates
"ru-Cyrl" that the script tag is not recommended.  That's not too bad.
My only lingering concern is that the user who generates "ru-Brai" gets
the same message, and clearly that second user knows what she is doing,
and is doing it on purpose.

> 2. We leave the script in the current position, since it follows the
> "most-significant-field-first" rule. While there may be cases where
> current implementations won't find the region code where one exists,
> they will be no worse off than if there is no region code at all. And
> with #1, this will be few cases. We have to have script; that is one
> of the main reasons for 3066bis.

I am 100% in agreement with Mark on this, and to that end I oppose the
Bruce Lilly draft, which attempts to pre-empt RFC 3066bis by duplicating
one of its key functionalities.

> 3. We arrange for a telecon either at the end of this week or the
> first part of next week. We can have a common room for people in the
> S. San Francisco area to meet in person, and others can call in. By
> having an "in person" meeting, I think we might be able to make more
> progress than we seem to be doing in email.

No puedo.  Better to keep it on the list, and try to impose a little
more order.

-Doug Ewell
 Fullerton, California

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 13 Apr 2005 09:09:01 +0200

Doug Ewell wrote:
 
> Tough sentence; read it again until it makes sense.

It's okay, can I use Latn or Brai with en ?  Of course,
without a default script Brai could be useful, or Latn
could be useful.  Mark's proposal doesn't answer this
question, implementors have to invent default scripts.

They'll invent different things for languages without
"Associated_Script", some of these ad hoc inventions
will be wrong.

For en-Brai one hint would be "Brai is nowhere in the
Associated-Script, it must be sound".  For Latn, Cyrl,
and anything else in any Associated_Script it's not
clear for the _other_ (unassociated) languages.

> I guess we got rid of multiple values separated by
> semicolons, since that became confusing with the
> language descriptions.

Semicolon is fine, it only didn't work for the union
of English and French descriptions, because you need
it already to separate descriptions in the same group.
 
> I can live with the multiple Associated_Script subtags

Unnecessary, semicolon is okay.  But the concept of the
Associated_Script list (two or more) doesn't help with
obscure languages without any Associated_Script.

Just look in your alpha-3 list, I can guess the script
in less than half of it.  Would I need Latn for got ?
Or is Goth the script for got ?
      
> I oppose the Bruce Lilly draft, which attempts to pre-empt
> RFC 3066bis by duplicating one of its key functionalities.

With Bruce's draft I'd know how to implement got-Latn in an
Accept-Script and HTTP.  It could even work for content with
a Content-Script.  Dito MIME (mail and news) excl. RfC 2231.

I'd know how to declare a Content-Script in XHTML 1 or HTML.
Okay, I don't know a HTTP server extracting this from the
document, and I've no idea how to do it in arbitrary XML.

                           Bye, Frank

---

From: Tex Texin <[email-masked]>
Date: Wed, 13 Apr 2005 04:13:45 -0700

fwiw, I wouldn't favor adding the French at this time.

As for Latin-1, if we move out of the ASCII realm, I would prefer
Unicode. We might not use chars out of the latin-1 set, but we shouldn't
hem ourselves into a limited architecture.

My 2 cents.
tex

-- 
-------------------------------------------------------------
Tex Texin   cell: +1 781 789 1898   mailto:[email-masked]
Xen Master                          http://www.i18nGuy.com
                         
XenCraft		            http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 13 Apr 2005 15:37:51 +0200

If I am correct there is on the issue,

1. consensus among French culture Members having expressed an opinion.

2. mixed feelings among English culture Members, where confusion results 
from the bundling of various questions in a single one "do you support 
Jefsey's non detailed provision".

3. a complete confusion between the use of English or autonym reference names.

4. consideration of the particulars of a non yet otherwise discussed (but 
by me) registration procedure.

May be could we start in having #882-variants? As implied in the process I 
probably have not the neutrality to make a correct analysis. But I will 
certainly help in indicating if the proposed variants are adequate.

jfc

---

From: John Cowan <[email-masked]>
Date: Wed, 13 Apr 2005 10:12:18 -0400

> obscure languages without any Associated_Script.

Obscure languages are probably only written in one script, and don't
need Associated_Script.  Note that the purpose of Associated_Script is
not to tell an implementer the usual script used with a language, but
simply to serve notice which script *subtags*, if any, should normally
be used with this language subtag.  This difference is fundamental.

Thus en has no Associated_Script, because English is almost always
written in the Latin script, so no script subtag should be employed
exceptis excipiendis.

But az should have "Associated_Script: Latn; Cyrl; Arab" (in whatever
syntax) to indicate that tags should normally appear with script
information.

A language tag generator UI, therefore, should have two modes, normal
script mode and unusual script mode.  In normal script mode, only the
scripts in Associated_Script should be offered to the user (and if there
is no such header, then no scripts should be offered).  In unusual script
mode, every script should be offered.

(Hint, hint, Doug.)

Note that this does not apply to a language *range* generator, which
needs different rules.

> Or is Goth the script for got ?

The specific answer is that for centuries Gothic has been written solely
in the Latin script.  (This may start to change with the presence of
Gothic in Unicode and the ready availability of Gothic fonts, or it
may not.)  Therefore, no Associated_Script header should be present,
and the tag got-Latn should be avoided (though got-Goth would be in
order as an unusual script).

-- 
John Cowan  www.ccil.org/~cowan  www.reutershealth.com  [email-masked]
SAXParserFactory [is] a hideous, evil monstrosity of a class that should
be hung, shot, beheaded, drawn and quartered, burned at the stake,
buried in unconsecrated ground, dug up, cremated, and the ashes tossed
in the Tiber while the complete cast of Wicked sings "Ding dong, the
witch is dead."  --Elliotte Rusty Harold on xml-dev

---

From: John Cowan <[email-masked]>
Date: Wed, 13 Apr 2005 10:19:37 -0400

Scripsi:

> Obscure languages are probably only written in one script, 

This should of course have read "Obscure languages are probably written,
*if at all*, in only one script."  Most of the world's languages are
unwritten.

-- 
Values of beeta will give rise to dom!          John Cowan
(5th/6th edition 'mv' said this if you tried    http://www.ccil.org/~cowan
to rename '.' or '..' entries; see              [email-masked]
http://cm.bell-labs.com/cm/cs/who/dmr/odd.html)

---

From: Tex Texin <[email-masked]>
Date: Wed, 13 Apr 2005 04:00:12 -0700

My 2 cents.
tex

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 13 Apr 2005 10:16:54 -0700

Hi -

> From: "Tex Texin" <[email-masked]>
> To: "Doug Ewell" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Wednesday, April 13, 2005 4:00 AM
> Subject: Re: [Ltru] Re: [psg.com #882] registry should copy non-English fieldsfrom ISO documents

 Those now in opposition are Randy, Addison, Mark, Peter, Robin and Tex.
Those now in support are Jefsey, John, and Ned.

Inclusion of Jeffsey's provisos clearly weakens rather than strengthens support.

At this point I think there's enough of a rough consensus that we can
mark this issue "rejected".

Randy, ltru co-chair

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 14 Apr 2005 02:13:46 +0200

John Cowan wrote:

> and don't need Associated_Script.

Yes, that was my point, Associated_Script doesn't help to find
the default script for any language I don't know.  The absence
of Associated_Scripts (plural) only means "there is a default
script, but we don't tell you what it is" => FUBAR, I need
exactly the opposite info.

A way to have both, either a default or more associations, in
a list Associated_Script with either one or more entries, is of
course fine, but the important case is "one" => SHOULD NOT.

> English is almost always written in the Latin script, so no
> script subtag should be employed exceptis excipiendis.

English is a bad example, beause we all know it.  The other
examples (Vietnamese, tr, got, fy, ...) are better, because an
implementor of software trying to match scripts might not know
them.  The implementor is in a bad position.  For a tagger and
even for a user it's better, they should know what they want.

But that will change, in some years users might not know that
there once was a 1766/3066 and that 3066bis desperately tried
to be compatible with an incompatible scheme.  And invented the
ugly kludge "default_script", because the only alternative was
to close this WG.

> the tag got-Latn should be avoided

Okay.  I didn't know this.  If some implementors of apache /
mozilla / IE / safari / opera / Java / ... also don't know it
it cannot work.
                        Bye, Frank

---

From: John Cowan <[email-masked]>
Date: Wed, 13 Apr 2005 23:26:24 -0400

> exactly the opposite info.

For what purpose?  The registry isn't supposed to be a general
compendium of information on languages (and I repeat, most languages
have no script because they aren't written).

> course fine, but the important case is "one" => SHOULD NOT.

No, it's zero scripts that means SHOULD NOT.

-- 
John Cowan                              [email-masked]
http://www.reutershealth.com            http://www.ccil.org/~cowan
Humpty Dump Dublin squeaks through his norse
                Humpty Dump Dublin hath a horrible vorse
But for all his kinks English / And his irismanx brogues
                Humpty Dump Dublin's grandada of all rogues.  --Cousin James

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 14 Apr 2005 05:40:49 +0200

> No, it's zero scripts that means SHOULD NOT.

Let's close the WG.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 14 Apr 2005 16:05:51 +0200

At 05:26 14/04/2005, John Cowan wrote:
>compendium of information on languages

The registry to be of use and to stay is to be a root file on languages. 
This can be achieved in two ways:
- either the discussed IANA file is the Internet language root file. I do 
not push for that because this makes the cost to be beared by TLDs and the 
financial and political stability of the project is not warranted.
- or the discussed registry is an RFC that can be used as a language root 
file by language compendia. I favor that approach because this means that 
the work is assumed by an IETF WG, can be taken back/completed by any 
specialised international body, etc. and has an operational cost extremely 
limited.

Any other way brings not enough added value over ISO existing langtag, 
scriptag, countrytag, that non one will really pay attention to it. The XML 
patch will be carried otherwise (there will be the W3C XML, the M$ XML, 
etc. if needed - do not forget that the W3C is not an open structure as is 
IETF).

>(and I repeat, most languages have no script because they aren't written).

We are talking of a standard, not of news paper. As soon as a language is 
in the list, this becomes accidental because anyone you do not know may 
decide to make it written or may already have.
jfc

ps. I thank you for having reduced the risks of harm for my organization in 
changing your mail.