Subject: [Ltru] Re: Extended language tags

From: "Doug Ewell" <[email-masked]>
Date: Mon, 8 Oct 2007 17:51:33 -0700

Shawn Steele <Shawn dot Steele at microsoft dot com> wrote:

> * Even for the current tags, many of the people in the teleconference 
> seem to extend RFC 4647 in ways that are best for them.  Strict use of 
> 4647 behavior seems rare.  It seems reasonable to me to expect that in 
> the future people may continue to do so and that RFC 4647 and the 
> registry can only provide guidelines.

I agree with the part about RFC 4647, but not the Registry, at least not 
in blanket terms.

The Registry contains some fields that are normative and some that are 
informative.  For the informative stuff, say Suppress-Script, it's very 
reasonable to expect that some people will ignore the warnings and write 
"en-Latn", and all we can do is tell them they shouldn't.  But anyone 
who uses the normative data in a "non-strict" way is tagging 
incorrectly.  This might include things like using "eng" for English 
(ISO 639-2 code) or "jp" for Japanese (by false analogy with 'JP" for 
Japan).

Shawn probably did not mean what I took his comment to mean.

--
Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 9 Oct 2007 10:51:12 +0200

Doug Ewell wrote:
 
> "en-Latn", and all we can do is tell them they shouldn't.

No, Suppress-Script is not only "informative", it got some normative
SHOULD rules in BCP 47.  These rules aren't mandatory / required
MUSTard, but still normative.

ITYM that the Suppress-Script field isn't guaranteed to be "stable", 
but it's not "informative" like say Comment or Added.

 Frank

---

From: Shawn Steele <[email-masked]>
Date: Tue, 9 Oct 2007 12:25:25 -0700

> informative.

Tagging and lookup however are different.  Many of the uses I'm involved with presume that tags are correctly defined:  ie: only installed locales are allowed to be used for resource names, or for marking documents.  Presumably the locales were created correctly when they were installed, so I don't have to worry about "eng" being valid.

Making a matching dependency on the registry would require a new data source, which could be problematic, which is why I prefer the information be in the tags.  If the tags are invalid I won't match correctly, but I won't have to look up an on-line dependency.  Obviously this is less of a problem for some applications, but I don't see there being any downside and it does help to have the ext lang tag in this case.

- Shawn

---

From: "Debbie Garside" <[email-masked]>
Date: Wed, 10 Oct 2007 10:46:18 +0100

Hi

I may have missed the answer to this question, apologies if I have, but why
not include cwm within the registry and then deprecate in favour of zh-cwm?
This way both are in the registry and the fallback, as described by Mark, is
facilitated. The same could be done for zh-yue and yue and no-nb etc.  Thus
if people tag "incorrectly", with, for example, cwm or yue, applications
would come up with the correct match anyway.

I cannot pretend that I understand the entirety of the current conversations
wrt extended language tags but I do think their inclusion would be useful
for matching purposes.

Best regards

Debbie Garside

> -----Original Message-----
> From: Shawn Steele [mailto:[email-masked]]
> Sent: 09 October 2007 20:25
> To: Doug Ewell; LTRU Working Group
> Subject: RE: [Ltru] Re: Extended language tags
>
>
> > > * Even for the current tags, many of the people in the
> > > teleconference seem to extend RFC 4647 in ways that are best for
> > > them.  Strict use of
> > > 4647 behavior seems rare.  It seems reasonable to me to
> expect that
> > > in the future people may continue to do so and that RFC
> 4647 and the
> > I agree with the part about RFC 4647, but not the Registry,
> at least
> > not in blanket terms.
>
> Tagging and lookup however are different.  Many of the uses
> I'm involved with presume that tags are correctly defined:
> ie: only installed locales are allowed to be used for
> resource names, or for marking documents.  Presumably the
> locales were created correctly when they were installed, so I
> don't have to worry about "eng" being valid.
>
> Making a matching dependency on the registry would require a
> new data source, which could be problematic, which is why I
> prefer the information be in the tags.  If the tags are
> invalid I won't match correctly, but I won't have to look up
> an on-line dependency.  Obviously this is less of a problem
> for some applications, but I don't see there being any
> downside and it does help to have the ext lang tag in this case.
>
> - Shawn
>
>

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 12 Oct 2007 00:06:02 -0700

Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:

> I may have missed the answer to this question, apologies if I have, 
> but why not include cwm within the registry and then deprecate in 
> favour of zh-cwm? This way both are in the registry and the fallback, 
> as described by Mark, is facilitated. The same could be done for 
> zh-yue and yue and no-nb etc.  Thus if people tag "incorrectly", with, 
> for example, cwm or yue, applications would come up with the correct 
> match anyway.
>
> I cannot pretend that I understand the entirety of the current 
> conversations wrt extended language tags but I do think their 
> inclusion would be useful for matching purposes.

I would not be in favor of creating 482 new deprecated-at-birth subtags. 
I think "deprecated" is a necessary evil that is needed when an ISO code 
element is withdrawn or a mistake is found.  It should not be a 
mechanism for implementing fallback.

---

From: "Debbie Garside" <[email-masked]>
Date: Fri, 12 Oct 2007 11:06:15 +0100

Hi Doug

> I think "deprecated" is a necessary evil that is needed when
> an ISO code element is withdrawn or a mistake is found.  It
> should not be a mechanism for implementing fallback.

To be honest, the whole macrolanguage scenario has been developed to deal
with historical coding errors and the great extlang debate is the result.  I
really cannot see the harm in this proposal.  I know it is not what this
function was originally designed for but it would be using the RFC to its
optimum. I would imagine that good application designers will incorporate
something like this anyway so to standardize such a hack (as Frank calls it)
is sensible.  It is what standardization is all about.

Best regards

Debbie