Re: [Ltru] Re: extlang

Peter Constable wrote:
>  These are the cases that relate to the
> way language-range works.
> 

Not exactly. Language-ranges are the expression of the preference. While 
HTTP 1.1 and others didn't put a lot of structure around language 
negotiation, we spent some time doing so in RFC 4647.

HTTP 1.1 and other, similar, items defined what we now call "basic 
filtering". That's what Peter means by the above. There is also 
"lookup", which is widely implemented (not well that I do not say "more 
widely").

In fact, we have different mechanisms for working with language tagged 
materials and these mechanisms each have their own uses and practical 
usage scenarios.

As for extlangs... I'm not sure we can solve this by arguing either 
case. Both the pro- and anti-extlang parties have valid points and in 
some cases the extlang tags *are* more useful and in some cases they 
*are* more harmful.

For a long time I supported extlangs because they were the direction we 
had laid down, in particular for Chinese languages. However, some things 
bother me about this approach:

1. If the languages in question really are distinct languages, why does 
subordinating the language make sense? Yes, you couldn't tag this or 
that language yesterday via the less distinct macrolanguage tag. Is that 
appropriate?

Thus, if I were to support extlang, it would be based solely on John 
Cowan's argument that we need extlang to prevent a "retagging crisis" 
for languages formerly enclosed by a macrolanguage.

2. Randy suggested (a long while ago now) that cherry-picking from the 
macrolanguage list would be a bad idea. Yet tag stability provisions 
prevent us from taking the list wholesale. And I have some concern that 
the macrolanguage "collections" (if you'll pardon this inaccurate term) 
have yet to be thoroughly tested. They may not be stable or suitable in 
the short-to-medium term. This is not a critique of ISO 639-3's work 
here. It is merely a note of caution.

If I were to support doing extlangs, it would consider each 
macrolanguage separately, as a one-time-event, and, again, solely as a 
compatibility item.

Note that we also face our own exception--I assume future sign languages 
would be treated as extlangs for compatibility reasons. Note that sign 
languages are NOT macrolanguages in the first place--they are already 
exceptional. I would favor eliminating this use of extlang too.

3. Mark's arguments about "better matching choices" really don't fit 
with matching as described in RFC 4647. Applications really do need to 
do more than the trivial matching in BCP 47 in many cases, but these 
depend on application specific needs. "Pure" BCP 47 matching has its 
place and cannot do many of the things that Mark suggests (as with 
Breton -> French fallback).

Mark's arguments about losing subsidiary subtags when matching extlangs 
*do* concern me. I had to modify my implementation of filtering to make 
it work in an extlang world. The modifications were not difficult and 
were reasonably successful. I *could* support a very limited application 
of extlang...

... but I feel that we're doing a disservice to the various languages 
involved by making them extlangs. Shouldn't Cantonese, Wu, or Hakka be 
treated fully as languages? Yes, it saves some retagging in the short 
term, but it is cleaner and clearer to tag languages directly. Users can 
still use the macrolanguage tag instead (I doubt we'll see much 'cmn-*' 
when 'zh-*' is available). It eliminates a complexity in tagging and 
language negotiation/selection who's purpose is served by compatibility 
alone. And content will need to be retagged in either case to take 
advantage of the distinction. Content that is not retagged won't be 
distinct.

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru