Subject: RE: [Ltru] Compatibility with existing use (LDAP)

From: Misha Wolf <[email-masked]>
Date: Sat, 09 Apr 2005 22:05:00 +0100

Ira McDonald wrote:

> If script tags SHOULD be rare in use, then it's no burden for
> them to occupy the third position, rather than the second.

I cannot imagine what mental model you have of *why* a 
script or a country should be included in a language tag.

Consider "zh".  And consider the *very* large number of 
people wanting to tag their text as, or look for text in, 
either Traditional or Simplified Chinese.  Are you serious 
in arguing that they should have to inject a country code 
between "zh" and the "Hant" or "Hans"?

Let's see: The person requesting a resource will have to 
specify a list of languages, of the form zh-C1-Hant, 
zh-C2-Hant, zh-C3-Hant, in order to obtain all resources in 
Traditional Chinese.

And what do you expect the person tagging a resource to do?
In general, they don't have the possibility of using multiple 
tags (zh-C1-Hant, zh-C2-Hant, zh-C3-Hant) to describe their 
resource.  So what should they do?  If they choose just one, 
eg zh-C2-Hant, then requestors specifying either zh-C1-Hant 
or zh-C3-Hant will not get the resource.

I feel that those who advocate the ll-CC-Scipt approach are 
simply sticking their heads in the sand and refusing to 
engage with reality.

> Semi-OT - the inclusion of script tags in language tags breaks
> utterly the utility of presenting language choices to users in
> GUIs as country-flag icons - the script differences would be
> invisible.

I can't imagine how you can seek to portray something so 
daft as being a reasonable practice.

Misha

-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

To find out more about Reuters Products and Services visit http://www.reuters.com/productinfo 

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 9 Apr 2005 14:52:24 -0700

Hi -

As a technical contributor, the longer this thread goes on
the more consideration I think we should give to alternatives like
http://www.ietf.org/internet-drafts/draft-lilly-content-script-01.txt

If we were to treat the identification of the language(variant),
the script, and the orthography of a text as three distinct
attributes, rather than trying to structure them into a single string
called a "language tag" would it ultimately make things simpler
or more complicated?

I find this approach intuitively appealing in the case where there are
multiple orthographic alternatives in the same script for a
given language, yet it has no impact at all on texts in languages
where identification of the script or orthography in use is of
no particular interest.  Even transcriptions and transliterations can
be handled nicely into this kind of approach, since they just become
orthographic alternatives.

It would, however, require a re-thinking of how we've handled
German and Chinese.

Randy

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 10 Apr 2005 01:33:55 +0200

Dear Randy,
what you propose here has a name: flexibility. And flexibility is a 
requirement for scalability. Why I disagree with the initial approach of 
this WG is because we did not start in considering the Charter, what it 
wanted and what it permited to discuss to provide the best and most 
generalized response.

I think that what you suggest is exactly what the Charter should lead us to.
1. to help users to use ISO standards and any other one or private 
proposition they may have to best understand each others
2. to propose a framework for every alternative - including APMD format - 
to be precisely documented, adequately supported, used as required and 
fully understood.

Cheers!
jfc

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 10 Apr 2005 01:01:26 +0200

Misha,
I think you should be clearer. With real ISO 3166 codes.
What you really discuss is for an LDAP meta-database on Chinese speaking 
web sites to enter:
zh-Hant-tw or zh-tw-Hant
zh-Hant-cn or zn-cn-Hant
zh-Hant-sg or zn-sh-Hant
etc... ?
And CN people to querry that database??
jfc

---

From: [email-masked]
Date: Sat, 09 Apr 2005 18:44:30 -0700 (PDT)

> It would, however, require a re-thinking of how we've handled

No doubt there's some appeal to this idea, but I don't think it's practical.

The single biggest implementation problem I see right off is that language tags
are used in lots of places, at least one of which is not amenable to the
addition of separate script field. I'm referring, of course, to XML. I believe
adding an xml:script field to go along with xml:lang could only be done with a
major revision to the XML base specification. And even if such a change could
be made, getting it deployed would be a real challenge.

Other cases, like email, would be able to add a content-script: field much more
easily, of course. Even so, a vast amount of code would have to be changed to
actually make use of this new field.

LDAP is another interesting case. Language tags in LDAP are actually a specific
case of a more general mechanism. But AFAIK little use is made of attribute
tags for purposes other than language tagging. This calls into question how
general the mechanism actually implemented by various clients and servers
actually is.

And even if you were to get the field defined in every place where there's a
field for language tags, you still have to actually make use of the field.
Having two separate fields certainly makes it easy to recognize script tags and
prevents them from causing problems in the language tag space, but you lose
information relating language to scripts. For example, suppose you have:

    content-language: az, ru, en
    content-script: latn, cryl

It stands to reason the Russian is written in cyrillic and the English in
latin, but what script is the Azerbaijani text written in?

Of course you could require a 1:1 correspondence between the entries in the two
fields, but that would then require a way to indicate when the script is
unknown. And tags would have to be repeated since a single script can apply to
multiple languages or vice versa. Ick. This is _seriously_ ugly. And even if
you ignore the ugly, the repetition of tags in language fields is certain to
cause problems to existing software.

So, much as I would like to eliminate the interop problems the current
proposal for adding script codes causes, I really don't think this is
a viable way to do it.

				Ned

P.S. My linguistic skills are rudimentary at best, but my recollection is that 
Azerbaijani is a language that can be written in either cyrillic or latin
script. If that's not the case please substitute a language where this is
actually true in the above example.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 10 Apr 2005 04:55:31 +0200

Ned,
you are most probably right about LDAP and Addison about XML. But this is 
not the case for _new_ services like OPES (open pluggable edge services: 
intelligence on the edge of the network, able to change the langtag of an 
XML page at will before it receives it) or my own long delayed ONES (open 
network extended services: intelligence (virtually in an end to end 
architecture) within the network we see coming back. This not true about 
the architectural solutions to support multilingualism. Even SMTP can be 
dramatically affected through the charter of the WG-OPES on SMTP support 
(even if we are quite delayed by the same problem as this WG: to understand 
how to support at the same time the past, the present and the future).

jfc

---

From: John Cowan <[email-masked]>
Date: Sun, 10 Apr 2005 03:02:28 -0400

> http://www.ietf.org/internet-drafts/draft-lilly-content-script-01.txt

I have no difficulty with the use of this header in MIME and HTTP
contexts.  But it does not satisfy the general requirement for tagging
documents outside any particular transport protocol or sub-protocol.
Like it or not, langtags have a context wider than the IETF's core
concerns with Internet protocols.

Nor do I wish to see an environment in which some language tags are
valid only in certain contexts whereas others are valid in other
contexts.

In general, assuming that out-of-band metadata will be correctly
preserved in a heterogeneous environment is an idea that history
has shown not to work very well.

> called a "language tag" would it ultimately make things simpler

Things should be as simple as possible, but no more so.

-- 
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: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 10 Apr 2005 11:29:13 +0200

>concerns with Internet protocols.

We are in agreement. This is why it is not adequate to specify them through 
an IETF WG and to try to impose them through the IANA without working on a 
global consensus.
jfc

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 10 Apr 2005 18:08:23 +0200

> It would, however, require a re-thinking of how we've handled

AFAIK no problem with the grandfathered German tags, bye, Frank