Subject: RE: [Ltru] Re: Proposed Text for Moving Forward

From: "Addison Phillips" <[email-masked]>
Date: Fri, 15 Apr 2005 12:26:43 -0700

One more thought.

Maybe we're trying to fix this the wrong way. Solutions that rely on counting the number of script fields produce problems because what you do is unstable and based on how many times a language has had a script registered.

Instead, we should create fields that exactly match what you do with them.

Subtag: en
Suppress_Script: Latn

Subtag: sr
Require_Script: Cyrl, Latn

Subtag: got
Suppress_Script: Latn, Goth
Comment: only an example

With these rules:

1. Script subtags listed in the 'Suppress_Script' field SHOULD NOT be used to form language tags unless they add specific information to the language tag required by an application.

2. Script subtags listed in the 'Require_Script' field SHOULD always be used to form language tags when the script used by the content being identified matches the script unless there is a specific reason to omit the script subtag in the application.

3. If the script of the content matches neither field (or the fields are both unpopulated), the script subtag SHOULD NOT be used to form language tags for that language unless it adds specific information to the language tag which is required by the application.

Suppress_Script is NOT guaranteed to be stable (values may be removed). Require_Script IS guaranteed to be stable (values can be added only). The two fields are mutually exclusive.

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Addison Phillips
> Sent: vendredi 15 avril 2005 10:11
> To: Randy Presuhn; [email-masked]
> Subject: RE: [Ltru] Re: Proposed Text for Moving Forward
> 
> I agree that the Gothic example might not be obvious, this would be a good
> place to put a comment into the registry.
> 
> It might be useful to actually distinguish between processing language and
> content language (metadata). For example, one might use "got-Latn" and
> "got-Goth" on <p> elements in an XHMTL document so that appropriate fonts
> can by applied to each in a stylesheet and still use "got" (meaning "got-
> Latn") in the <meta> element or in external references to the document.
> See: http://www.w3.org/TR/i18n-html-tech-lang/#ri20030510.102829377, which
> helped form my thinking about this.
> 
> I don't think that script associations need to pass an obviousness test.
> But the temptation to register every script a language has ever been
> written in should be guarded against since it will cause a lot of texts to
> pick up "SHOULD" when they really should not. Perhaps having separate
> fields (default and associated/expected) would help this, allowing
> promiscuous registration of associated scripts.
> 
> In that case, it is:
> 
> 0*1[default_script] = SHOULD NOT
> 2*[default_script] = SHOULD always
> [associated_script] = informational list of additional scripts???
> 
> Comments?
> 
> Addison
> 
> Addison P. Phillips
> Globalization Architect, Quest Software
> Chair, W3C Internationalization Core Working Group
> 
> Internationalization is not a feature.
> It is an architecture.
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Randy Presuhn
> > Sent: jeudi 14 avril 2005 19:32
> > To: [email-masked]
> > Subject: Re: [Ltru] Re: Proposed Text for Moving Forward
> >
> > Hi -
> >
> > > From: "Addison Phillips" <[email-masked]>
> > > To: "Frank Ellermann" <[email-masked]>; <[email-masked]>
> > > Sent: Thursday, April 14, 2005 4:48 PM
> > > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward
> > ...
> > > Perhaps the rules should be:
> > >
> > > 1. If the primary language has no associated script,
> > > you SHOULD NOT use a script subtag
> > > unless it adds distinguishing information for that context.
> > >
> > > 2. If the primary language has a single associated script
> > >  and the content uses that script,
> > > you SHOULD NOT use the script subtag (unless etc.).
> > >
> > > 3. If the primary language has two or more associated scripts
> > > and the content uses one of them,
> > > you SHOULD use the script subtag (unless it is harmful to do so).
> > >
> > > 4. If the primary language has any number of associated scripts,
> > > but the content uses a different script,
> > > you SHOULD use the script subtag (unless it is harmful to do so).
> >
> > To get the desired results for Gothic, (no subtag for Gothic transcribed
> > into latin alphabet, subtag required if using the historical Gothic
> > alphabet)
> > I think this would mean that the entry for Gothic could not identify
> > Gothic
> > as an associated script, and that the associated script (if any) would
> be
> > latin.  I guess this works, but I'd classify it as "obvious only if
> > previously
> > understood."
> >
> > Randy
> >
> >
> >
> >
> > _______________________________________________
> > Ltru mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ltru
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 15 Apr 2005 13:18:52 -0700

Hi -

> To: "Addison Phillips" <[email-masked]>; "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Friday, April 15, 2005 12:26 PM
...
> Instead, we should create fields that exactly match what you do with them.

Sounds like a good principle.

...
> Suppress_Script: Latn, Goth

If the desired behaviour is for transcribed Gothic to be "got" and
for Gothic in its historic alphabet to be "got-Goth", then I
think this should have been:

+ Subtag: got
+ Supress_Script: Latn
+ Require_Script: Goth

(It's been nearly a quarter century since I worked with Gothic, so
I'm *not* making any claims that this would indeed be the desired
behaviour now, though it would have been correct then.)

Randy

---

From: John Cowan <[email-masked]>
Date: Fri, 15 Apr 2005 16:47:34 -0400

> behaviour now, though it would have been correct then.)

Michael Everson believes it's still true.

-- 
John Cowan  [email-masked]  www.reutershealth.com  www.ccil.org/~cowan
Consider the matter of Analytic Philosophy.  Dennett and Bennett are well-known.
Dennett rarely or never cites Bennett, so Bennett rarely or never cites Dennett.
There is also one Dummett.  By their works shall ye know them.  However, just as
no trinities have fourth persons (Zeppo Marx notwithstanding), Bummett is hardly
known by his works.  Indeed, Bummett does not exist.  It is part of the function
of this and other e-mail messages, therefore, to do what they can to create him.

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 15 Apr 2005 15:40:27 -0700

This is a real improvement. But in terms of results, it appears that there
is no real difference in guidance in having the Suppress_Script field, and
having nothing. So it is unclear why the 'Suppress_Script' is needed.
>1. Script subtags listed in the 'Suppress_Script' field SHOULD NOT be used
to form language tags unless they add specific information to the language
tag required by an application.
>3. If the script of the content matches neither field (or the fields are
both unpopulated), the script subtag SHOULD NOT be used to form language
tags for that language unless it adds specific information to the language
tag which is required by the application.

>If the script of the content matches neither field...
This doesn't seem right. Take:
Subtag: sr
Require_Script: Cyrl, Latn

If I have data in sr-Kana, I really should tag it as such -- I don't want it
matching sr-Maya, etc.

=====

So, based on the results you describe, this could be simplified down to one
field, Suppress_Script, and two rules.

1. Script subtags listed in the 'Suppress_Script' field SHOULD NOT be used
to form language tags unless they add specific information to the language
tag required by an application.

2. Script subtags not listed in the 'Suppress_Script' field SHOULD always be
used to form language tags when the script used by the content being
identified matches the script unless there is a specific reason to omit the
script subtag in the application.

So
A. If the Suppress_Script is Latn, then en-Latn becomes en, while en-Cyrl
stays as is
B. If there is no Suppress_Script (say for zh), then zh-Hant, zh-Hans,
zh-Cyrl, (and everything else) stay as is.

‎Mark

----- Original Message ----- 
From: "Addison Phillips" <[email-masked]>
To: "Addison Phillips" <[email-masked]>; "Randy Presuhn"
<[email-masked]>; <[email-masked]>
Sent: Friday, April 15, 2005 12:26
Subject: RE: [Ltru] Re: Proposed Text for Moving Forward

One more thought.

Maybe we're trying to fix this the wrong way. Solutions that rely on
counting the number of script fields produce problems because what you do is
unstable and based on how many times a language has had a script registered.

Subtag: en
Suppress_Script: Latn

Subtag: sr

Subtag: got

With these rules:

1. Script subtags listed in the 'Suppress_Script' field SHOULD NOT be used
to form language tags unless they add specific information to the language
tag required by an application.

2. Script subtags listed in the 'Require_Script' field SHOULD always be used
to form language tags when the script used by the content being identified
matches the script unless there is a specific reason to omit the script
subtag in the application.

3. If the script of the content matches neither field (or the fields are
both unpopulated), the script subtag SHOULD NOT be used to form language
tags for that language unless it adds specific information to the language
tag which is required by the application.

Suppress_Script is NOT guaranteed to be stable (values may be removed).
Require_Script IS guaranteed to be stable (values can be added only). The
two fields are mutually exclusive.

Addison P. Phillips