Subject: RE: [Ltru] Private Use Tags

From: "Peter Constable" <[email-masked]>
Date: Tue, 5 Jul 2005 23:53:28 -0700

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Dylan N. Pierce

> The solution is simply to define an organizational namespace. We take
a
> random tag--we'll say "P" for private--and then allow companies and
> organizations to register their own namespace. Everything that follows
> their namespace tag is then interpreted according to their standard,
> whatever that may be. For example, the ALA would register "ala," the
AP
> would register "ap," Microsoft would register "mcrsoft," Adobe would
> register "adobe" and so on.

This reminds me a bit of an idea Gary Simons and I came up with in 2000,
though we were thinking about alternate naming agencies for the primary
language subtag, not private-use subtags.

The particular benefit of your proposal is realized if extensions are
defined by agencies rather than for particular functions. It's clear
that there are far more than 35 agencies that could potentially want
their own variant extensions, but not clear that there are that many
functions. Up to now, I don't think anyone has mentioned the possibility
that extensions could be defined for use within single agencies.

I'd be open to seeing your idea considered further. It doesn't have to
go into this document, however: it's an extension, and this doc provides
the framework needed for creating extensions. Given the late date and
the delays this doc has seen, I recommend that we not pursue adding this
into *this* document, but that you consider preparing an internet draft
for your proposed extension and present it for discussion once this is
approved (i.e. waiting until there is an approved framework on which to
propose extensions).

Peter Constable

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

---

From: "L.Gillam" <[email-masked]>
Date: Wed, 6 Jul 2005 09:45:48 +0100

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of r&d afrac
> Sent: 06 July 2005 00:19
> To: Dylan N. Pierce; [email-masked]
> Subject: Re: [Ltru] Private Use Tags

[snip]

> This obviously creates a 
> classification 
> problem with StarWars, what is H2D2 speaking? and Yoda who is 
> not a human 
> being? 

Others refer to "Yodish" and write it in various places for yet others
to read. Klingon is in 639-2. When does it become a human language?

---

From: Misha Wolf <[email-masked]>
Date: Wed, 06 Jul 2005 20:04:24 +0100

Hi Dylan,

As you mentioned the ALA and educational levels in one of your 
postings, I will briefly note that Dublin Core [1] uses distinct 
elements for:

-  language: A language of the intellectual content of the 
   resource.

-  educationLevel: A general statement describing the education 
   or training context. Alternatively, a more specific statement 
   of the location of the audience in terms of its progression 
   through an education or training context.

educationLevel is defined to be a refinement of ...

-  audience: A class of entity for whom the resource is intended 
   or useful.

I think they got it right :-)

[1] http://www.dublincore.org/

Regards,
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.

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 7 Jul 2005 10:00:04 -0700

Note that these IDs do not appear outside of Java, e.g. in Accept-Language headers and the like. They are limited to Java internal usage (which creates problems when negotiating the locale over the Internet--there is work underway at W3C I18N Core Working Group on this problem, which is a separate problem from the language tag problem).

Addison

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

Internationalization is not a feature.
It is an architecture. 

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Peter Constable
> Sent: 2005?7?7? 9:36
> To: [email-masked]
> Subject: RE: [Ltru] Private Use Tags
> 
> On Behalf Of
> > Dylan N. Pierce
> > It is, in fact, the locale ID. But it would be disingenuous to present
> > that distinction as a significant difference. Effectively, the locale
> ID
> > /is/ a language ID "plus."
> 
> True, insofar as every locale has language as one of its constituent
> properties. But I believe (as others here have heard me say) that there
> is a definite difference. A language tag is a metadata element used to
> declare attributes of content wrt language variety and written form, or
> to request content according to those attributes; a locale ID is an API
> parameter used to tailor software processes, or to tag resources used to
> tailor those processes, wrt a variety of cultural parameters, some of
> which pertain to language but others of which do not. Very often, the
> information in a language tag is sufficient for use as a locale ID, but
> not in the general case.
> 
> 
> > According to Sun's own documentation, "The language argument is a
> valid
> > ISO Language Code. These codes are the lower-case, two-letter codes as
> > defined by ISO-639....  The country argument is a valid ISO Country
> > Code. These codes are the upper-case, two-letter codes as defined by
> > ISO-3166." And its purpose is so that applications can decide in what
> > language to serve the documents (in this case, UI output).
> 
> I haven't reviewed their implementation or documentation, but something
> doesn't make sense here: if the purpose of these IDs is only to select
> UI strings, then I wouldn't expect these IDs would ever need to include
> a component for currency.
> 
> Peter Constable
>

---

From: "Peter Constable" <[email-masked]>
Date: Thu, 7 Jul 2005 11:14:11 -0700

On Behalf Of

>  > [I]f the purpose of these IDs is only to select
>  > UI strings, then I wouldn't expect these IDs would ever need to
>  > include a component for currency.
> 
> If the UI string includes a currency, a percent, a number with a
decimal
> point or thousands separators, or regionally ambiguous language--any
of
> the things that knowing what language something is written in helps us
> navigate--then it would need that information.

All that is saying is that knowing the language helps pick a locale that
is likely to be appropriate, which I don't question. But you described
the API as selecting UI language, which should not be the same as
selecting a locale. I'm not aware of any scenario in which selecting the
UI language should require specifying a currency.

> > A language tag is a metadata element...

> If this is true--and I believe that it is--then it speaks well to the
> topic under discussion. After all, if two things serve pretty much the
> same purpose, but one of them does /more/, then basically, you have a
> subclass.

No disagreement.

> And that's exactly what we're looking at here: using a
> universal tag, and being able to have a section of it for your own
> private subclass.

But I wouldn't suggest that that should be done for locale IDs. At
least, there are valid scenarios, particularly in relation to Web
services, in which there is a need to interchange locale IDs publicly.

>  > They are limited to Java internal usage (which creates problems
when
>  > negotiating the locale over the Internet--there is work underway at
>  > W3C I18N Core Working Group on this problem, which is a separate
>  > problem from the language tag problem).
> 
> So then tags with defined extensibility could additionally solve the
> problem of negotiating the locale over the Internet? That doesn't
sound
> like a separate problem.

The key factor that creates a difference is the purpose: extensions for
locale IDs needed in public interchange versus extensions for
private-use.

> It sounds like (and please forgive me; I'm not
> trying to make enemies) perhaps some organizational notions of
> conceptual purity--"This is language and this is not, this is our
> jurisdiction and this is not!"--is causing us to divide essentially
one
> practical problem into several provincial miniproblems that are not
> being solved in terms of each other, as they should be.

I can't speak for others; for my part, I think that RFC 3066bis needs to
be designed for a primary set of applications, which include many for
which RFC 3066 is already used, and those applications involve
*language* identification, not *locale* identification. While it would
be appropriate in some Web application to pass locale information, e.g.

www.localtrains.com/schedule.asp?date=2005-07-07&loc=en-us_24hr

it would *not* be appropriate to put locale information (i.e.
information that goes beyond strictly language identification) in the
xml:lang attribute of some XML entity as in

<body xml:lang="en-us_24hr">

Thus, I very much think we should limit RFC 3066bis to *language* tags,
and look to some derivative specification or protocols (possibly an RFC
3066bis extension) to use 3066bis tags as one building block in creating
locale IDs.

Peter Constable

---

From: "Peter Constable" <[email-masked]>
Date: Fri, 8 Jul 2005 06:42:43 -0700

On

> But if it's doing "Just this," then let's put our money where our
mouths
> are and say, "Just this." We don't need private use tags at all

We cannot eliminate private-use tags completely: we must at least retain

x *("-" 1*8Alpha)

to remain backward compatible with existing implementations of 3066. I
don't think we want current users' tags to break on new parsers.

Peter Constable