Frank Ellermann | 2 Sep 16:38
Picon
Picon

variant Suppress-Script (was: Request for variant subtags "scouse" and "boont")

Doug Ewell wrote on the other list:

> I wonder, however, if we (LTRU) might have a need in the
> future to revise those rules and allow a Suppress-Script
> for a language-variant combination.  I don't have a real
> example, but close your eyes and pretend for a moment that
> we are faced with a dialect of Mongolian that warrants a
> variant on proper linguistic grounds, and coincidentally
> happens to be written overwhelmingly in Cyrillic script
> and virtually never in Mongolian script. In that hypothetical
> case, it might be appropriate to consider that the
> language-variant combination "mn-whatever" should have a
> Suppress-Script of "Cyrl" even though "mn" by itself has
> none.  Just a thought.

It's certainly an interesting fact.  IMO Suppress-Script is
a kludge for naive applications, and situations like right
to left truncation or left to right matching.  They'd end up
with "I can see an mn and whatever and no script, and there
is no Suppress-Script for mn" (for new 3066bis applications).

To confuse "old" 3066-applications (= all existing browsers
and Web servers) add a region code as in mn-RU-whatever vs.
mn-Cyrl-RU-whatever.  At the moment we have four cases:  both
sides new, both old, old client + new server, or vice versa.

With a new Suppress-Script rule we'd get nine cases.  I can't
tell immediately if that could fail miserably in some cases.

Frank
(Continue reading)

Misha Wolf | 3 Sep 21:33
Picon

FW: Generic variants and Armenian dialects

For the LTRU to consider ...

Misha

-----Original Message-----
From: Doug Ewell [mailto:dewell <at> adelphia.net] 
Sent: 03 September 2006 19:43
To: ietf-languages <at> iana.org
Cc: Misha Wolf
Subject: Re: Generic variants and Armenian dialects

Misha Wolf <Misha dot Wolf at reuters dot com> wrote:

> The only bit of your message that worries me is the discussion of 
> "en-1901".  Yes, I know you were commenting on a mail of John's.
>
> It's one thing to argue that we should use the Armenian word for East 
> or West to ensure the variants are not used in an arbitrary manner 
> elsewhere.  It's quite another to assign a year number to one language

> only.  What if two languages underwent spelling reform in 2007?  Would

> one of them not be allowed to use "2007"?  This seems wrong to me.

Given that we have implemented "spelling reform" variant subtags for 
only one language, and the practical need for those has been called into

question, this scenario seems quite remote.  Still, anything is 
possible.

(Continue reading)

Doug Ewell | 3 Sep 22:08
Picon

Re: Test suite for language tags? (Frank Ellermann)

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

>> additions are of course very welcome
>
>  For well-formed:
>
> abcd-Latn
> AaBbCcDd-x-y-any-x
>
>  For broken:
>
> abcd-efg
> aabbccddE

Thanks for bringing up the abcd-efg case.  I'd forgotten that extlangs 
can only follow a 2- or 3-letter primary language subtag, not only 
semantically (because of their genesis) but also syntactically:

language      = (2*3ALPHA [ extlang ]) ; shortest ISO 639 code
              / 4ALPHA                 ; reserved for future use
              / 5*8ALPHA               ; registered language subtag

extlang       = *3("-" 3ALPHA)         ; reserved for future use

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
Editor, draft-ietf-ltru-initial

(Continue reading)

Peter Constable | 4 Sep 17:21
Picon
Favicon

prefixes for date variants (was Re: Generic variants and Armenian dialects)

(moving to LTRU)

-----Original Message-----
From: ietf-languages-bounces <at> alvestrand.no [mailto:ietf-languages-bounces <at> alvestrand.no] On
Behalf Of Peter Constable
Sent: Monday, September 04, 2006 7:11 AM
To: ietf-languages <at> iana.org
Subject: RE: Generic variants and Armenian dialects

> From: ietf-languages-bounces <at> alvestrand.no [mailto:ietf-languages-
> bounces <at> alvestrand.no] On Behalf Of Doug Ewell


> > The only bit of your message that worries me is the discussion of
> > "en-1901"...


> Perhaps LTRU
> should consider defining a distinction between this type of "date"
> variant, which could in theory apply to more than one language (even
> though the reforms themselves would be different), and the "usual" type
> such as Resianic or Boontling or Scouse or Eastern [Armenian], which in
> theory could not ("Eastern Quinqui" would not have the same relative
> meaning as "Eastern Armenian," except geographically).

The portion you quoted doesn't appear to prevent us from specifying multiple prefixes for a date variant;
it merely suggests (wrongly, I think we can agree) that a new prefix for e.g. 1996 unrelated to DE would
probably be rejected. We could revise to make clear that we allow dates to be used with unrelated prefixes
-- probably a simple change would do:

(Continue reading)

Doug Ewell | 4 Sep 19:50
Picon

Re: prefixes for date variants (was Re: Generic variants and Armenian dialects

Peter Constable <petercon at microsoft dot com> wrote:

> The portion you quoted doesn't appear to prevent us from specifying 
> multiple prefixes for a date variant; it merely suggests (wrongly, I 
> think we can agree) that a new prefix for e.g. 1996 unrelated to DE 
> would probably be rejected. We could revise to make clear that we 
> allow dates to be used with unrelated prefixes -- probably a simple 
> change would do:
>
> "Requests to add a prefix to a non-date variant subtag that imply a 
> different semantic meaning will probably be rejected. (This would be 
> permitted when appropriate for four-digit variant subtags representing 
> dates.) ... "

That's pretty much what I had in mind.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/

Addison Phillips | 5 Sep 20:04
Picon
Favicon

Re: prefixes for date variants (was Re: Generic variants and Armenian dialects)

> 
>> Perhaps LTRU
>> should consider defining a distinction between this type of "date"
>> variant, which could in theory apply to more than one language (even
>> though the reforms themselves would be different), and the "usual" type
>> such as Resianic or Boontling or Scouse or Eastern [Armenian], which in
>> theory could not ("Eastern Quinqui" would not have the same relative
>> meaning as "Eastern Armenian," except geographically).
> 
> The portion you quoted doesn't appear to prevent us from specifying 
 > multiple prefixes for a date variant; it merely suggests (wrongly,
 > I think we can agree) that a new prefix for e.g. 1996 unrelated
 > to DE would probably be rejected. We could revise to make clear
 > that we allow dates to be used with unrelated prefixes --
 > probably a simple change would do:
> 
> "Requests to add a prefix to a non-date variant subtag that 
 > imply a different semantic meaning will probably be
 > rejected. (This would be permitted when appropriate for
 > four-digit variant subtags representing dates.) ... "

-1

"Date variants" are not defined anywhere and I don't believe we should 
get into the business of defining them. We need to deal with the problem 
of adding a prefix to a variant.

I think the correct response to our problems here, as Mark pointed out, 
is to REMOVE the validation requirement of checking the variant prefix. 
Checking the prefix fundamentally means that no prefix can be added to a 
(Continue reading)

John Cowan | 6 Sep 16:18

Re: prefixes for date variants (was Re: Generic variants and Armenian dialects)

Addison Phillips scripsit:

> I think the correct response to our problems here, as Mark pointed out, 
> is to REMOVE the validation requirement of checking the variant prefix. 

+1

--

-- 
No,  John.  I want formats that are actually       John Cowan
useful, rather than over-featured megaliths that   http://www.ccil.org/~cowan
address all questions by piling on ridiculous      cowan <at> ccil.org
internal links in forms which are hideously
over-complex. --Simon St. Laurent on xml-dev

McDonald, Ira | 6 Sep 18:44
Favicon

RE: prefixes for date variants (was Re: Generic variants a nd Armenian dialects)

+1

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald <at> sharplabs.com

> -----Original Message-----
> From: John Cowan [mailto:cowan <at> ccil.org]
> Sent: Wednesday, September 06, 2006 10:18 AM
> To: Addison Phillips
> Cc: LTRU Working Group
> Subject: Re: [Ltru] prefixes for date variants (was Re: 
> Generic variants
> and Armenian dialects)
> 
> 
> Addison Phillips scripsit:
> 
> > I think the correct response to our problems here, as Mark 
> pointed out, 
> > is to REMOVE the validation requirement of checking the 
> variant prefix. 
> 
> +1
> 
> -- 
> No,  John.  I want formats that are actually       John Cowan
> useful, rather than over-featured megaliths that   
(Continue reading)

IESG Secretary | 6 Sep 21:50
Picon
Favicon

WG Action: RECHARTER: Language Tag Registry Update (ltru)

The Language Tag Registry Update (ltru) working group in the 
Applications Area of the IETF has been rechartered. For additional 
information, please contact the Area Directors or the working group 
Chairs.

+++

Language Tag Registry Update (ltru)
===================================

Current Status: Active Working Group

Chair(s):
Randy Presuhn <randy_presuhn <at> mindspring.com> 
Martin Duerst <duerst <at> it.aoyama.ac.jp> 

Applications Area Director(s):
Ted Hardie <hardie <at> qualcomm.com> 
Lisa Dusseault <lisa <at> osafoundation.org> 

Applications Area Advisor:
Ted Hardie <hardie <at> qualcomm.com> 

Mailing Lists:
General Discussion: ltru <at> ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/ltru
Archive: http://www.ietf.org/mail-archive/web/ltru/index.html

Description of Working Group:

(Continue reading)

Kent Karlsson | 6 Sep 20:19
Picon

RE: prefixes for date variants (was Re: Generic variants andArmenian dialects)

> Addison Phillips scripsit:
> 
> > I think the correct response to our problems here, as Mark 
> pointed out, 
> > is to REMOVE the validation requirement of checking the 
> variant prefix. 

I don't understand.

ANY new subtag will be "flagged" by a validating language tag processor
that has not been updated to include the new subtag. The same would
go for newly registered prefix(es) for already existing variant
subtag(s)
and a validating language tag processor that has not been updated
to include the new prefix(es).

If the "validation requirement of checking the variant prefix"
is removed, why not remove also the "validation requirement
of checking the subtag registration". (Which would make validation
rather pointless, since there would be no validation...)

I may have missed something, but did anyone (e.g. Mark) actually
suggest removing the prefix validation (for validating language
tag processors)?

	/kent k


Gmane