[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

re: prefer-language tag



I have read draft-blanchet-preflang-00.txt.

The real meat of the proposal is a single paragraph:

<Begin quote>
6. Placement of the tag

This new tag will be normally placed in the headers of the protocols
that use them.  This memo do not attend to list protocols and
specify where to place them.
<End quote>

Unfortunately, this is also its flaw.

In the SMTP or NNTP context, this constitutes a layering violation.  Email
message headers are a different layer (RFC 822) from SMTP.  It is *extremely*
unlikely that the email protocol guys are going to accept this.

SMTP/NNTP are more likely to get some sort of command to set the preferred
language(s), e.g.
	LANG ja, de, en
along with some sort of mechanism so that it is carried in the mail relay
case.

I suspect that the use of headers in draft-blanchet-preflang-00.txt in spite
of the layering violation, was as a means to avoid the mail relay requirement.
The problem is, that layering violation is quite serious and you're not going
to get support for putting MTA functions in the RFC 822 headers.


In other protocols, "headers" is a meaningless context.  Consider FTP, POP3,
or IMAP; there is no "header" that is transmitted from client to server to be
used to convey the "preferred language" concept.  Nor is there anything like a
"tag".

However, a LANG command is itself a complicated issue.  In particular, many
people tend to confuse "setting the language" with "setting the locale".
These are two entirely different things which must not be mixed.  On the other
hand, it is often desirable to set both language and locale, and it is equally
desirable to avoid multiple RTTs in "session initialization".

Another question has to do with the ability to query the list of supported
languages and the interaction between requests for dialects.  "FR" means "any
French", but "FR-fr" and "FR-qc" refer to two different dialects.

Consider, for example, a preference of "FR-qc, EN".  Does this mean "prefer
English over a non-Quebec dialect of French"?  Or does it mean "prefer Quebec
dialect of French, then any French, then English"?  It becomes obvious if we
see something like "FR-qc, FR, EN" or "FR-qc, EN, FR".

But if we don't have an obvious intent, then we need non-ambiguous rules for
its interpretation.  Otherwise, we will have many unhappy users.

My own belief is that "FR-qc" means *only* "Quebec dialect of French", and
that if the user's intent is "Quebec dialect of French, then any dialect of
French" he must use "FR-qc, FR".  Similarly, "EN-US, EN" to prefer US English
than any English.

This is because we have, in some languages, cases where dialects are
considered to be "wrong" to the point that a person would prefer a foreign
language than to receive the "wrong" dialect.

But, the important thing is not how this question is decided, but that there
be a decision that everyone adheres to.


Anyway...

The bottom line is that draft-blanchet-preflang-00.txt is probably not going
to be the method that is eventually adopted.  It omits some important details
(such as exactly how the preference rules act) and it relies upon a vague use
of "headers" which is not valid in most protocol concepts.

***HOWEVER***, the concept of a client/server negotiated list of languages, in
user preferred order, is the right fundamental idea.  It is what several of us
have been working on for some time.  The fact that a particular expression of
the idea has problems doesn't mean that the idea itself is wrong.

The fact that it hasn't been settled yet should suggest that there is not an
easy solution.