Re: prefer-language tag

[Mark Crispin <MRC@CAC.Washington.EDU>]

On Mon, 23 Feb 1998 14:10:46 -0500, John D. Burger wrote:
> Hmm, we disagree somewhat about whether RFC 1766 applies to this issue of
> specifying language preferences, but I think we can agree that it does =not=
> sufficiently cover the issue - we certainly need to specify additional or
> new semantics for this problem.

I think that we are violently agreeing here, albeit using different
nomenclature ("does not apply" vs. "does not sufficiently cover").  I've never
advocated that RFC 1766 be callously disregarded in defining the semantics for
language preferences; rather that these semantics are not defined by RFC 1766
and should not be inferred by a reading of RFC 1766 that is outside of its
scope.

I'm not sure if the new document should replace 1766, or if it should augment
it.  I vote for the latter.

> > Chinese dialects are not mutually intelligible; Mandarin and Cantonese are
> > more different than, say, Swedish and Norwegian or Spanish and Italian.
> As you suggest, this is true for the =spoken= forms of these languages, but
> not the written languages - Mandarin and Cantonese do indeed share the same
> orthographic representation (modulo character set and font preference
> issues).

Uh, actually, not quite.

There is a written Cantonese representation that is different from written
Mandarin.  I believe (a native Chinese can/should correct me on this) that
written Mandarin appears to be a form of "shorthand" to a Cantonese speaker
and can be read in Cantonese.  However, the reverse is not true for written
Cantonese.

> > My concern has to do with interoperability.  How should a French Canadian
> > user configure his client so that it works with an arbitrary server that
> > speaks French?
> If you mean "a FR-CA user" and "a server that speaks FR", then:
>   Prefer-Language:  FR-CA, FR
> should work, shouldn't it?

This is exactly my point!

The question is, is it the responsibility of the client to specify the
fallback from FR-CA to FR?  Is it the responsibility of the server to fallback
automatically?  Is it the responsibility of both?

I seem to be reading that you are saying "it should never be the
responsibility of the server to fallback automatically, because in some cases
the fallback may be wrong."

I *agree* with this position!!  I want to see that explicitly specified!

But we can not stop here.  There is a server responsibility as well.  Suppose
our Quebec user requests "FR-CA,FR,EN" to a server which has "FR-FR,EN".  Does
he get EN, or does he get FR-FR masquerading as FR due to fallback?

If we don't have fallback (because it may be wrong), then in the case of
French there is a requirement that both client and server explicitly support
FR.

I want to see that explicited specified too!

> My suggestion for reserving the "default" subtag, and explicitly labeling
> alternatives with, say, "FR-default", is analogous to the ultimate fallback
> being discussed in another thread, "i-default".  Namely, messages in
> "FR-default" should be designed to be at least decodable by all speakers of
> "FR-dd", for any dialect dd of French.  This allows server implementors to
> write the "FR" alternative under the assumption that it will be read by
> native speakers of whatever "main" dialect of the language the "FR" tag
> corresponds to.  Then, if nothing else is available, clients preferring
> "FR-foo" get the (decodable) "FR-default" version.

OK, I understand this now.

I think that this is a bad idea because it gets us down the slippery slope of
deciding a "main dialect".  You will have significant, and ultimately
unanswerable, controvery over what dialect is that "main dialect".

For example, an argument can be made that American English dialect is in some
ways truer to the English of Shakespeare than modern British English.  Such
arguments are best left to those academics and nationalists who enjoy such
frivolity.  We should not do so.  It is a waste of our time.

We should just stipulate that languages have dialects; that none are "better"
or "worse" than others; and that, if a language is specified without
indicating a dialect, this indicates that a form which is intelligible (or at
least decodable) by all speakers of that language regardless of dialect.

> Your approach seems to be to let "FR-foo" fall back to "FR".

Actually, it isn't; that is just a possibility.

I agree that automatic fallback is probably a bad idea.

The reason why I mentioned fallback is that users will expect fallback, and
implementors will find themselves obliged to provide it, unless there is an
explicit specification of the rules to make fallback unnecessary.

We should, by now, understand these rules, and the surprising consequences to
users if those rules are violated.