Re: Translations

> > 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)
> 
> This may be nice in some cases. But it should not be mandatory.

The nomenclature should be clearly defined and if it is used it must have 
the meaning as defined.  This would allow for a single model.

> > 2) The response to a translation request by machine or human would not be 
> > instantaneous.  Further work would be needed for longer transactions, 
> > probably applicable to other fields.
> 
> Does HTTP have something like a delay? Can a server/proxy send back
> "not available, but possibily available in 2 weeks"?

There are a some solutions:

 - The translation will go to a default URI, particularly if a data 
structure is defined.

 - The server suplies a URI where the translation will go.

 - The URI will arrive via email.

 - The translation itself could arrive via email.

But I wonder if there are people around working on longer translations 
that could be apply to translation.

> > 3) "q" should be the "quality of the linguistic version" and not the 
> > "user's preference for the language" (HTTP/1.1).  Example
> > 
> >   q=1    Translated by a human   Master Translator
> >   q=0.5  Translated by a human   Novice Translator
> >   q=0.49 Translated by a machine Master Translator
> 
> The q for the documents is quality of the documents. The q on
> the Accept-Language is the preference of the user.

OK.
 
> > 4) A standard nomenclature for "q" is need.  For example, less than 0.5 
> > is machined translations.
> 
> > 5) The Accept-Language should be a ordered "preference list".  There is no 
> > need to quantify the preference of the user.

I accept that the q is for creating the "preference list" as long as 
there is a "non quantifing mode"; i.e.,

 Spanish 0.9
 English 0.8
 French  0.7

means that I prefererence list is Spanish, English, French without 
quantification.
 
> The problem with q on Accept-Language is privacy. One part of this
> problem is the identification with some language minority, which
> may be done independently of q factors. The other is click tracing.
> For this, in certain cases even just the set of languages provides
> enough information. To alleviate the problem of click-tracing and
> privacy, in addition to the provisions in the http specs, it might
> be a good idea to agree to restrict the q values set by browsers
> to a limited set (e.g. 1.0, 0.8, 0.6, 0.4, 0.2, 0.0). This will
> allow a wide expression of relative preferences, while it will
> avoid click-tracing on something like "the guy that has Japanese
> at 0.4586794".

There should be at least to modes of transmiting the languages preference 
list:

 - Get the best doc.    (list communicated)
 - Get the default doc. (list not communicated)

A further refinement could be to request the best doc only from friendly 
servers.

Tomas

Received on Thursday, 16 January 1997 19:34:33 UTC