Re: Translations

On Wed, 15 Jan 1997, Koen Holtman wrote:

> M.T. Carrasco Benitez:
> >
> >1) Defining a nomenclature that allows for translation cost little to 
> >HTTP and could be very useful in translation.  Example:
> >
> > it-ht   (Italian, human translation)
> > it-mt   (Italian, machine translation)
> 
> You seem to be working from the assumption that HTTP can be changed easily
> at this point.  It cannot be changed easily: people do not want to touch 1.1
> anymore, and work on a successor version has not really started yet.  You
> could also get these tags into HTTP by revising the language tags RFC, but I
> think that is even more difficult.

I agree: changing HTTP and language tags is hard.
 
> So if you want to define translation mechanisms, you should define them _on
> top of_ HTTP/1.1.  You cannot put new stuff _in_ HTTP/1.1.

I agree, much easier if the HTTP support some basic mechanisms.
 
> >5) The Accept-Language should be a ordered "preference list".  There is no 
> >need to quantify the preference of the user.
> 
> There is a great need for q values in all Accept-* headers, including
> Accept-Language.  Without these values, there is not way for the user to
> express a ranking between the preferences sent in different Accept-*
> headers.  I talked about this earlier on this list.  See 

I agree: it is just the semantic of q; there has been talks in this 
list and before this list.

"q" should be used for *one* of the following:
 - Quality of the linguistic version
 - Ordered preference list of languages

if it is acceptable to express the "orderered preference" by the order in 
the Accept-Language, "q" shoul have the meaning of "quality of the 
linguistic version".

Tomas

Received on Wednesday, 15 January 1997 05:06:57 UTC