> > - some legacy systems (CLDR, for example) have inherent
> > structural/design reliance on the language portion being somewhat
> atomic
>
> Then let them use the non-canonical form, as Google uses non-
> canonical 'iw' with no intention of changing.
Architectural alignment is typically better, when it can be achieved.
>
> > - the Lookup algorithm (i.e. locale-style negotiation) seems to
> be
> > adversely affected by extlangs. Lookup produces better results
> when
> > the language and extlang are "atomic". Having a canonical mapping
> to a
> > primary subtag makes exactly that distinction. If I'm using
> Lookup, all
> > I have to do is canonicalize the tags and then run lookup
> normally. The
> > other way I have to change code (and would probably push hard for
> a
> > 4647bis as a result).
>
> You just need something different from canonicalization as
> currently written. I admit I am splitting hairs here.
Yes, but it is extremely convenient (not to mention somewhat compelling) when the existing algorithm works out-of-the-box one way but has to be modified the other.
Ultimately, this all circles back to the Ur-argument: do we want to say "tag anything Chinese as zh-something" or say "avoid tagging things zh-something".
>
> I continue to think local filtering per RFC 2616 the most important
> use
> case, more important than either mass filtering a la search engine
> or resource lookup.
You have your applications and I have mine. ;-)
Local filtering is generally more important. It is, or will be, more common an operation to apply processing, styling, selection, etc. to items and text based on language than it is to select or filter from a collection of documents.
However, RFC 2616 lays out a case for resource lookup, as status code 300 just isn't that desirable. For that matter, 2616 dips its toe into Lookup when it says:
Note: When making the choice of linguistic preference available to
the user, we remind implementors of the fact that users are not
familiar with the details of language matching as described above,
and should provide appropriate guidance. As an example, users
might assume that on selecting "en-gb", they will be served any
kind of English document if British English is not available. A
user agent might suggest in such a case to add "en" to get the
best matching behavior.
Best Regards,
Addison
Addison Phillips
Globalization Architect -- Lab126
Internationalization is not a feature.
It is an architecture.
_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.