Subject: RE: [Ltru] Re: Great Script Debate Part II: Formats...

From: "Addison Phillips" <[email-masked]>
Date: Mon, 11 Apr 2005 12:51:26 -0700

I didn't want to demonstrate anything necessarily. What I'm trying to do is frame the debate so we quit going around and around in circles. My personal analysis of the potential problems and benefits of various formats is what I tried to put into that message. The question of which actually is the right choice is the substance of the debate.

This is similar, in my mind, in spirit to my NH/VU example. We can have a useful discussion only if we are comparing the alternatives. As long as the debate consists solely of "lang-script-region is bad", we are not making progress.

So my personal opinion, reflected in two years of work on the current design, is that lang-script-region will ultimately be better for the vast majority of users than lang-region-script or lang-region-s-script. But now we can have *that* debate (in terms of balancing relative benefit and relative harm).

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 Frank Ellermann
> Sent: lundi 11 avril 2005 12:32
> To: [email-masked]
> Subject: [Ltru] Re: Great Script Debate Part II: Formats...
> 
> Addison Phillips wrote:
> 
> > Any I missed?
> 
> Add script to the charset ;-)  Joke off, you probably wanted
> to demonstrate that de-CH-s-Latn is worse than de-Latn-CH, but
> I don't see it immediately.
>                             Bye, Frank
> 
> 
> 
> _______________________________________________
> 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: "Peter Constable" <[email-masked]>
Date: Mon, 11 Apr 2005 13:59:34 -0700

> From: [email-masked] [mailto:[email-masked]]
On Behalf Of
> Addison Phillips

> 3. Script after language
> 
> de-Latn-CH-1901-x-gleep
> de-CH-1901-x-gleep
> 
> This is RFC 3066bis, of course. The issue here is the script vs.
region code that we're
> discussing. The advantage to this design is that script is at the
right level in the tag in
> most cases. RFR processors can remove the script (unlike in 2) during
matching. RFR
> matching works as long as users are consistent about using or not
using script for a
> particular prefix. "Smart" 3066 matching can't find the region code
with this design.

Clarification: "smart" 3066 matching can't find the region ID **in those
cases** in which a script ID is included. We must keep in mind that our
expectation is and has always been that, for all those existing use
cases in which a script ID has never been used because it isn't needed,
we expect no script ID would be used in the future.

> 6. Script as an attribute
> 
> de-CH-1901-x-gleep; script=Latn; q=1.0
> de-CH-1901-x-gleep; q=1.0
> 
> This has the advantage of not mucking with the tags at all, but can't
be used in
> contexts such as XML :-(. Who knows how matching works.

It has other problems as well, both for XML and non-XML applications.
Ned Freed identified problems that make it quite problematic for several
IETF applications.

> 7. Script inferred from the tag
> 
> de-CH-1901-x-gleep
> 
> This is what we have today. If you see "zh-TW", that must mean Hant.
Good luck if
> you live in HK.

Clearly inadequate.

Peter Constable

---

From: "Peter Constable" <[email-masked]>
Date: Wed, 13 Apr 2005 08:41:20 -0700

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of JFC (Jefsey) Morfin

> What I oppose in "your" position, is four things: dominance, lack of
QA,
> complexity, inconsistency, decency. Since you certainly do not see
where
> let me explain again.
> 
> - dominance is not good because it is not appropriate to the network
> architecture.

*Prominance* of certain languages within international standards is an
accepted reality. In limiting names to a single form, we are using a
practice considered at least acceptable within ISO; and if we compare
with the common ISO practice of using two languages, relative to the
6900+ living languages in the world today, we're talking about a 0.0145%
difference.

> - lack of QA results from abandon of cross culture control and
protection.

This is a preposterous claim. Limiting names to one language does not
imply in any way that there is a lack of QA. The two are completely
independent. Moreover, since the registry will use names taken from ISO
source standards, we have little control over QA in most cases.

> - complexity. The hook of a language is not an easy thing because
> printf("$stringNN") is not a programer reflex. In permitting to have a
> single reference name, you do not oblige programers to support several
> languages (when there are two, there are hooks for all).

This is another preposterous claim. If we included names in 1000
languages, we would not be obliging programmers to support more than one
language. It is not the documentation within this registry that causes
programmers to support multiple languages; it is the market in which
they wish to sell their products. The fact that they are even looking at
this registry, by virtue of the different languages for which there are
tags, reflects that they already *are* supporting multiple languages,
regardless of how many languages we use to document each entry.

> - inconsistency. We know that the reference names are just because
France
> accepted not to delay ISO 639-3 (I concurred) in having not the
> budget/people to carry the work.

Bingo! This is a question of resources, IMO. We should not burden the
Language Tag Reviewer, IANA or anyone else by requiring names in
multiple languages to be maintained. There is nothing inconsistent in
this.

> - decency...

Everything you said does not even pertain to the issue of whether to
include more than one language, hence is irrelevant to that discussion.

Peter Constable