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

From: "Addison Phillips" <[email-masked]>
Date: Thu, 7 Apr 2005 13:01:34 -0700

> Maybe it's better than this obscure "don't use script tags
> unless you must, but we don't tell you when you must and when
> you shouldn't" (= no default script) rule.

How about a useful compromise? We seem to be going around in circles with no way out. It seems to me that our options are limited if we need scripts (and we do). 

In thinking about how you might move scripts down towards the end of the tag, one of the thoughts I had was: gee, if scripts were just variants, then we could put a Recommended Prefix on them.

Hmm... a recommended prefix...

What if we put Recommended Prefix fields onto script subtags in the registry? 

This solves the default script problem because we are recommending when to use the subtag (when your language is in the list for that subtag). 

We don't have to identify them all on Day One, since we can add prefixes for those we don't know over time using registration. Guidance can be provided that script recommended prefixes should usually be added in groups of two or more (that is, you don't want a prefix for a specific language unless the language is commonly written in more than on script). 

It doesn't break 3066 processing (still), but does help these implementations by having users avoid creating tags such as "en-Latn-US" that don't have much additional utility.

It doesn't break implementations that choose, wisely or unwisely, to implement those tags either. For example, if using the Brai/Latn subtag pair with "en-*-US" is sensible for a certain application, then it isn't forbidden and works with 3066-like implementations as long as users realize that they must be consistent in the body of work.

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: jeudi 7 avril 2005 12:14
> To: [email-masked]
> Subject: [Ltru] Re: Compatibility with existing use (LDAP)
> 
> John Cowan wrote:
> 
> > The only way to ensure 100% backward compatibility is to
> > change nothing.
> 
> IMHO that's wrong, MIME is ingenious (excl. 2231).
> 
> > Putting the script subtag after the region subtag exchanges
> > one incompatibility for another, as Doug points out.
> 
> If it makes no big difference for 3066bis implementations and
> helps 3066 implementations I'd like it.
> 
> Or if it's better for the interoperability of "old" (all) and
> "new" (future) implementations.
> 
> > What is more, we already have some language-script-region
> > tags registered under RFC 3066 (IANA hasn't posted them yet),
> > so it's a fait accompli.
> 
> That's no argument, "not-yet-posted" grandfathered tags could
> be deprecated and replaced by a better solution, there won't
> be millions of say iu-Cans pages.
> 
> > We are not breaking compatibility.
> 
> Maybe we're not breaking it radically enough - pretending that
> all is fine where in fact the new scheme has problems with the
> old scheme.  I'd be interested to see different schemes like
> Debbie's 639-4.
> 
> Maybe it's better than this obscure "don't use script tags
> unless you must, but we don't tell you when you must and when
> you shouldn't" (= no default script) rule.
> 
>                              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: John Cowan <[email-masked]>
Date: Thu, 7 Apr 2005 16:23:20 -0400

Addison Phillips scripsit:

> This solves the default script problem because we are recommending when
> to use the subtag (when your language is in the list for that subtag).

Excellent!  So Latn would have a Recommended Prefix of az (among others) but
not en.

We might want Brai to have a recommended prefix of *, since brai could be
attached to almost any language, or at least any language that is written.

-- 
Mark Twain on Cecil Rhodes:                     John Cowan
I admire him, I freely admit it,               http://www.ccil.org/~cowan
and when his time comes I shall                http://www.reutershealth.com
buy a piece of the rope for a keepsake.        [email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 08 Apr 2005 00:15:25 +0200

Addison Phillips wrote:

> This solves the default script problem because we are
> recommending when to use the subtag (when your language
> is in the list for that subtag).

Not completely.  For something like "fy" implementations still
don't know what the undocumented default (Latn in this case)
is.  And you'd get a rather long list of prefixes for scripts
like Latn or Cyrl (all languages using both), don't you ?  Bye.

---

From: [email-masked]
Date: Thu, 07 Apr 2005 15:25:26 -0700 (PDT)

> How about a useful compromise? We seem to be going around in circles with no
> way out. It seems to me that our options are limited if we need scripts (and
> we do).

I agree 100%.

> In thinking about how you might move scripts down towards the end of the tag,
> one of the thoughts I had was: gee, if scripts were just variants, then we
> could put a Recommended Prefix on them.

> Hmm... a recommended prefix...

Clever!

> This solves the default script problem because we are recommending when to
> use the subtag (when your language is in the list for that subtag).

> We don't have to identify them all on Day One, since we can add prefixes for
> those we don't know over time using registration. Guidance can be provided that
> script recommended prefixes should usually be added in groups of two or more
> (that is, you don't want a prefix for a specific language unless the language
> is commonly written in more than on script).

Which in turn would minimize, if not outright prevent, overuse of script codes.

> It doesn't break 3066 processing (still), but does help these implementations
> by having users avoid creating tags such as "en-Latn-US" that don't have much
> additional utility.

Anything that would avoid such nonsense would help considerably. Indeed,
superfluous use of script tags is one of my main worries here. At one point I
considered suggesting wording to the effect that unnecessary script codes be
avoided, but past experience with such directives has been mixed at best. Your
idea of encoding it into the script registry is much, much better. It even has
the added advantage of helping implementations avoid silly states.

> It doesn't break implementations that choose, wisely or unwisely, to
> implement those tags either. For example, if using the Brai/Latn subtag pair
> with "en-*-US" is sensible for a certain application, then it isn't forbidden
> and works with 3066-like implementations as long as users realize that they
> must be consistent in the body of work.

Cases where both script and country code tagging are useful as part of the same
tag are tolerable as long as they are rare enough, I think, that the resulting
breakage is, while not exactly welcome, livable.

				Ned

---

From: John Cowan <[email-masked]>
Date: Thu, 7 Apr 2005 23:50:29 -0400

> like Latn or Cyrl (all languages using both), don't you ?  Bye.

Actually not.  There aren't that many languages that use both Latin
*and* some other script in practice (excluding special-purpose scripts
like Braille).  Languages that only use Latin, like en, de, or fy,
aren't going to be listed.

It occurs to me that if "ipa" becomes a variant signifying "IPA
transcription", it would be sensible not to give it a recommended prefix.

-- 
John Cowan        http://www.ccil.org/~cowan          [email-masked]
Please leave your values                Check your assumptions.  In fact,
   at the front desk.                      check your assumptions at the door.
     --sign in Paris hotel                   --Cordelia Vorkosigan