RE: [Ltru] Extended language tags (long reply)

Your 1) & 2) don't have the same functionality.  If you don't change the lookup for 2), then you don't get the behavior that your changed lookup in 1) provided.

Changing a language priority list in 2) does count as a change.  This doesn't help a "new" web app talking to an "old" client that hasn't been updated, for example.  In order to solve that you have to infer the matching suggested, which I think is simpler with 1).

Note that your solution in 2) could be used if you felt it was simpler:  zh-yue-Hant-HK;zh-Hant-HK could be used to solve 1) as well, but with 1) you have more options.

- Shawn

-----Original Message-----
From: Addison Phillips [mailto:addison@yahoo-inc.com]
Sent: Sunday, October 07, 2007 8:30 PM
To: Mark Davis
Cc: ltru@ietf.org
Subject: Re: [Ltru] Extended language tags (long reply)

I would say:

1. With Extlangs.

- change to filtering: none, but you probably want to use extended
filtering instead of basic filtering (i.e. "zh-Hant-HK" matches
"zh-yue-Hant-HK" and "zh-cmn-Hant-HK")

- change to lookup: treat extlang as atomic with the primary language
subtag; potentially loop-back through the subtags. That is, given the
range "zh-yue-Hant-HK", the fallback pattern is this:

  zh-yue-Hant-HK
  zh-yue-Hant
  zh-yue
  zh-Hant-HK
  zh-Hant
  zh
  (default)

Or this:

  zh-yue-Hant-HK
  zh-yue-Hant
  zh-yue
  (default)

2. Without extlangs.

- change to filtering: none

- change to lookup: none

BUT... you want to include the macro language in your ranges in some
cases. Alternatively, we would have to define new filtering and lookup
options that include mapping to macrolanguages. For example, with the
range "yue-Hant-HK", you would want the fallback to be:

  yue-Hant-HK
  yue-Hant
  yue
  zh-Hant-HK
  zh-Hant
  zh
  (default)

This can be achieved either by having the language priority list
"yue-Hant-HK;zh-Hant-HK" or by inferring it using registry data about
macro languages.

A similar case can be made for filtering.

Addison