Re: [Ltru] Issue 181, was: Issue 113 (language tag matching (Accept-Language) vs RFC4647), was: Proposed resolution for Issue 13 (language tags)

["Phillips, Addison" <[e-mail]>]

Hello Julian,
> 
> so I had a look at RFC 4647 and I'm totally open to allow more than
> Basic Filtering; but I'm not sure about what exactly we want to
> say...
> 
> - require to try Basic Filtering First, but allow to fall back to
> Lookup when nothing is returned?

I think this would actually be a Bad Thing. Filtering and Lookup work very differently.

> 
> - just stay point to Section 3.1 and leave it to the implementer?

I think that's probably a the best choice. There are different purposes to the matching schemes. 

I tend to think that HTTP's requirements are most like what the Lookup algorithm provides. That is, you can (and must) return exactly one result for a given request. It also works most like the resource-and-localization mechanisms in programming languages and (some) Web infrastructure. While filtering can return "exactly one" result, it isn't always clear what you will get and it works less well when a wide variety of content is available with closely related language tags.

On the other hand, there are implementations based on filtering (Basic Filtering *is* the algorithm in 2616) and these can be made to work. There are many applications where filtering is a good choice (this is especially true, for example, when aggregating content). So, although my personal preference would be to require Lookup, I don't think that choice can be the only one permitted.

I would suggest some text, but want to see other's reactions first.

Best Regards,

Addison

Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationalization WG

Internationalization is not a feature.
It is an architecture.