RE: [Ltru] RE: duel(ing) tags

["Debbie Garside" <[e-mail]>]

Hi Addison

Comments in line...


>  > why not include a way to catch the "illegal" tags that  >
> is easy for applications to implement?
>
> Ur... that's what the registry does. I can catch the fact
> that "cmn-HK"
> is not valid and it's really easy to implement. What you mean
> is that I should be able to infer that the user really means
> "zh-cmn-HK", which I might be able to do in my software (but
> which I am free *not* to do at present).

That is exactly what I mean.

>
> After all, plenty of content is labeled with the language tag
> "english".
> Implementations are free to infer that this really means
> "en". However, they are not obliged to do so.
>
>  > I see more use than harm in using
>  > extended language subtags and deprecating the individual
> > 639-3 codes to  > facilitate matching.  This can be
> documented within 4646bis.
>
> I sense perhaps some confusion here?

I don't think I am confused at all... Having read your email :-)

> We are not talking about deprecated any ISO 639-3 codes. We
> are talking about how ISO 639-3 codes are incorporated into
> the registry.

That is exactly what I am talking about.

>'cmn' is a perfectly valid ISO 639-3 code.

Agreed

> We
> have several choices for how to include it in the registry:
>
> - as a primary language subtag (making tags like "cmn-Hant-HK" valid)
> - as an extlang of 'zh' (making tags like "zh-cmn-Hant-HK" valid)
>    // note: notice that I chose an un-grandfathered tag there
> - as a primary language subtag that is deprecated (making
> tags like "cmn-Hant-HK" valid, but deprecated)
> - not at all (none of the tags in this example would be valid then)

Indeed.  I understood this perfectly well.  I was attempting to show how cmn
could be incorporated within the registry as an extlang of 'zh' whilst also
covering the back door by registering 'cmn' and then immediately deprecating
'cmn' in favour of 'zh-cmn'.  You already have several deprecated subtags
what is the problem  with a few more to deal with the macrolanguage
scenario?


> Let me note that "special case" handling and mapping in
> matching algorithms is incredibly painful to build and
> maintain. If you choose to canonicalize tags and ranges
> before processing, this isn't so bad. But if you are a "good
> citizen" and preserve the original form of the tags/ranges
> for later consumption, one must implement quite complex logic
> for doing what's supposed to be quite simple matching.

What I have proposed is fairly simple logic for matching purposes.

> Furthermore, this requires, absolutely, access to information
> above and beyond that embodied in the tags/ranges themselves.
> That is a wholesale departure from current practice in
> matching. While my own implementations might very well use
> such information (and more) to "do the right thing", that is
> *my* application and you might not care for my particular
> implementation choices (they may not be right for your
> application). To the extent that we can describe behaviors
> that do not require registry access, I am content with either
> primary language subtags or extlangs (but NOT both for the
> same language).

I am not proposing both for the same language as such.  I am proposing to
deprecate one in favour of the other.

>
> Remember: a deprecated subtag is still a valid subtag.

Yes, I know.  Perhaps you would like to call it something else?  Retired as
part of macrolanguage?  Replaced by?

The whole point is to have both within the registry; one current, one not
current but both valid for matching.  By deprecating cmn to zh-cmn matching
is facilitated.  Text within RFC4646bis can be quite simply written to
explain this.

Now I am going to shut up about it as I am obviously banging my head against
a brick wall.  But I really cannot see what the problem is; other than
people will tag with both zh-cmn and cmn whether we like it or not and I
think it is far better to deal with that scenario within the registry rather
than leave it to application designers who may not be as conversant with
RFC4646bis as you (and maybe) me :-)

Best regards

Debbie



> Addison
>
> PS> Note that the word "valid" in the foregoing refers
> explicitly to the
> terminology defined in Section 2.2.9 "Classes of Conformance"
> in the current draft of RFC 4646bis (and by intention to the
> same section in RFC 4646).
>
> Debbie Garside wrote:
> > Shawn wrote:
> >
> > Its just my experience
> >> that people don't really always pay that much attention, so they
> >> might use both.  I was merely suggesting that robust applications
> >> might want to recognize both forms, even if one was "illegal".
> >
> > But if we already know that is what people will do (which
> is the case)
> > and if we are to use extended language subtags with the
> inclusion of
> > 639-3 within the registry why not include a way to catch
> the "illegal" tags that
> > is easy for applications to implement?   I see more use
> than harm in using
> > extended language subtags and deprecating the individual
> 639-3 codes
> > to facilitate matching.  This can be documented within 4646bis.
> >
> > Best regards
> >
> > Debbie
> >
> >
> >> -----Original Message-----
> >> From: Shawn Steele [mailto:[e-mail]]
> >> Sent: 10 October 2007 21:30
> >> To: [e-mail]; [e-mail]
> >> Cc: [e-mail]
> >> Subject: RE: [Ltru] RE: duel(ing) tags
> >>
> >>>> I definitely am against providing both tagging options.
> >>> But where is the harm in including cmn in the registry and then
> >>> deprecating in favour of zh-cmn?  As stated previously,
> this would
> >>> catch those who unwittingly tag with any 639-3 code and are
> >> unaware of
> >>> macrolanguages and 4646bis.
> >> I wasn't suggesting registering both.  Its just my experience that
> >> people don't really always pay that much attention, so
> they might use
> >> both.  I was merely suggesting that robust applications
> might want to
> >> recognize both forms, even if one was "illegal".
> >>
> >> - Shawn
> >>
> >>
> >>
> >
> >
> >
> >
>
> --
> Addison Phillips
> Globalization Architect -- Yahoo! Inc.
> Chair -- W3C Internationalization Core WG
>
> Internationalization is an architecture.
> It is not a feature.
>
>
>






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