Re: [Ltru] Macrolanguage usage

Kent Karlsson 2008-05-26 10.30:

> Leif Halvard Silli wrote:
>> >  a) See above quote, which I see as saying that extlangs will
>> >     not provide the benefits claimed by the extlang proponents.
>> 
>> The benefits are for the minority language users, in contexts of
>> negotiation between majority and minority encompassed language.
>> Would be interesting to hear more why you don't see any benefits.
> 
> As others have said already:
> 
> 1) Fallback to language tag prefix does not apply to content
>    negotiation (except as an extraordinary measure for misconfigured
>    web browsers).

This misunderstanding has been stated by both sides. I have 
accepted the facts here.

> 2) Even when fallback to language tag prefix does apply, it is more
>    often than not inappropriate to fall back to a macrolanguage. In
>    many cases it would be *akin to* letting Norwegian fall back to
>    German (or any other Germanic language), just because both languages
>    are Germanic (and German is "larger" than Norwegian; English is even
>    "larger", but using that in this example would cloud my point since
>    most (not very old) people that know Norwegian also know English).
>    That would be bad, not only for language understandability reasons,
>    but in some cases it can also be politically sensitive. Both of
>    which we should stay out of.

1. If the user has stated a preference of "zh-yum, fr", then "fr" 
  will be preferred before the server starts looking for 
"zh-whatever". Hardly a problem.

2. If, however, neither "fr" nor "zh-yum" nor "zh-whatever" is 
found, causing the web server to try the extraordinary fallback 
that you mention in your first point, then the user will get 'zh', 
if available. Hardly politically problematic.

3. I will tell you (repeat, or perhaps I said it on another list) 
one problem that I see: You might have problems getting Apache's 
ForceLanguagePriority settings to work as you wish. Imagine that 
you offer 'sv' and 'zh-cmn' on your web server, and if you have 
set up 'sv' to be the ForcedLanguagePriority when the user neither 
prefers 'zh-cmn' nor 'sv'. Then a user who prefers "zh-yum, fr" 
will still get "zh-cmn"  (and even 'zh', if you offer it, via the 
"extraordinary fallback") instead of 'sv'. This could be a problem.

However, even if Apach considers "en-GB" a misconfigured browser 
and performs the "extraordinary fallback" to "en", it should  not 
treat "zh-yum" the same way and fallback to "zh". That is one 
issue solved. I don't know if the "normal fallback" can be solved.

As I see it, extlang is supposed to handle the issues dealing with 
negotiation between encompassed languages. It is supposed to 
handle teh problems of minority language users inside a sea of 
dominant encompassed language resources. And it handles such cases 
very well, I think.

But outside that "sea", in the diaspora and such things, the 
extlang solution has the above mentioned problem. However, even 
then, the problem could be rather small, because, it is likely 
that a user visiting a page which is offered in "sv" and "zh-cmn" 
will have a browser that is set up to prefer "sv" or "zh-cmn".

Some would say that if you are in macrolanguage situation where 
ther is close to zero intelligibility between the encompassed 
languges, then this problem would cause problems. Well, no. If we 
have a situation where each encompassed language web site only 
offers one language, then being served the available encompassed 
language equals a "Forced Fallback" situation. If, however, we are 
in a situation - as we often are - were Spanish or another 
language outside the Macrolanguage is used as linguage franca, 
then the browsers will include Spanish in its preferences, and 
then Spanish will always be preferred over the encompassed 
language (unless the user has used the Macrolanguage tag - but 
that would be a problem both with and without extlang).

> 3) Language preference lists, for content negotiation and similar, is
>    a more general approach, and is easier to apply in a non-extlang
>    model than in an extlang model (as examples from others have shown),
>    avoiding numerous "q=0" entries to rule out some languages.

The political problems are exaggerated. See above. And there are 
also political advantages.

>> >  b) The exceptions to extlang application, for various reasons,
>> >     like for nn/nb and other instances, are already numerous.
>> 
>> 
>> nn/nb is a situation where the the mutual command of all the (two)
>> encompassed languages by all native speakers is fostered. Wheras
> 
> Even so, and even though 'no' ('nor') is a macrolanguage code for nn/nb
> (or nno/nob), extlang does not apply to nn/nb for backwards compatibility
> reasons.

The Norwegian case is still valid as an example of what extlang 
can/cannot do for a Macrolanguage situation.

>> >  c) No extlangs is a simpler model, both syntactically and
>> >     use-wise, and often have advantages over extlangs.
>> > 
>> > So a no-extlang model is simpler to explain and apply, an	d
>> 
>> For whom?
> 
> Everyone. Users, software developers, you and me, this WG, IETF, IANA, ...
> A language code can then always be in the first position, not sometimes
> mostly arbitrarily forced to be in the second position (as an extlang).
> It will not introduce new false fallback to prefix, not introduce new
> politically sensitive fallbacks/prefixes, leave users with more easily
> managed language preference lists, etc.

I answered the claim about "false fallback" and the political 
"dimenson" above.
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www.ietf.org/mailman/listinfo/ltru