55800 - Accept-Language: Including "quality factors" in language preferences

Status: VERIFIED FIXED

(Core :: Internationalization, enhancement, P3)

Description

[Kjetil Kjernsmo]

From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; OSF1 V4.0 alpha) (well, not quite... :-))
BuildID:    2000080712

I really came here to report bug 52925 and bug 54093 that I noted on the install
I did on my parent's box, but they had been reported. The latter is annoying,
because my native written language is registered as no-bok. However, I would
really like to see quality factors being implemented, as it is described in the
HTTP1.1 spec. In my NN4.75 on the DEC alpha, I have successfully included them
by using the add feature, writing the code and ;q=some number. I suspect few
will do that, however, but it is potentially very useful. Here's my idea how to
do it:

Reproducible: Didn't try

Actual Results:                              

Expected Results:  In the "Add" dialogue box, have a question "How well do you
read this language?" and a slidebar ruler type thing that people can use to
indicate how well they know it, and Mozilla will add quality factor for this
language, along  with the language code.

Additionally, there should be a checkbox in the Lang/preferences box that says
"Accept any language", and if checked, *;q=0.001 will be appended to the
"Accept-languages" string. This will solve the problem reported in bug 52925. It
should probably be enabled by default.

I'm not that much of a hacker I can fix it myself, but I thought you'd might
like to hear the ideas.

Comment 1

[nhottanscp]

Does anybody know if there is already a bug filed for this?

Comment 2

[nhottanscp]

Reassign to tao.

Comment 3

[Karl Ove Hufthammer]

If I've understood everything correctly, *;q=0.001 *needs* to be added, even if 
the rest of this bug isn't fixed. If not, you will loose access to all web 
pages supporting content negotiation and written in a language not on your list.

Comment 4

[Katsuhiko Momoi]

I'm confirming this bug.

The proposal for Q values was put forth in the original
bug which asked for implementing Accept-Language.
Basically what we should do is assign automatically
generated Q values based on the ordering of languages on the
list by the user. This is what IE does.
There is a pre-determined algorithm to assign
random number. There is no need to have UI for this.
It should be done all in the backend. At least that is
is the easiest thing to do and that is what I suggested.

Please see:

http://bugzilla.mozilla.org/show_bug.cgi?id=13380

If we had paid attention to the original request,
we didn't have to re-visit this issue. So this bug is
essentially re-opening a portion of that bug.

BTW, not having a Q value is going to break
web pages. Most servers currently don't pay attention
to the Q value but parses the order in which language
codes are sent from a client. This is not as precise
as the Q value but since in the absence of Q values, we
can interpret each lang code to carry value of "1".
Then servers should be able to implement some default
preference in such a case, i.e. pay attention to the
order.

Comment 5

[Katsuhiko Momoi]

Correction.

> BTW, not having a Q value is going to break
> web pages.

should read instead:

BTW, not having a Q value is NOT going to break
web pages.

Comment 6

[Katsuhiko Momoi]

I'm cc'ing gagan because this is probably his bug.

Comment 7

[Kjetil Kjernsmo]

>Basically what we should do is assign automatically
>generated Q values based on the ordering of languages on the
>list by the user.

I agree that this is a possible way to do it, and a good function is
exp(-(n-1)/5) ,
where exp is the exponential function and n is number of the language in the
user's list.
This function starts at 1 and goes only assumptotically to 0, so it makes 34
languages possible (if you need more, replace 5 with some higher number, eh,
well, how many digits was accepted?).

However, I don't agree that this is the way it should be implemented, ideally.
My language string is now
nb;q=1, no;q=0.99, nn;q=0.98, da;q=0.7, en;q=0.68, sv;q=0.65, de;q=0.4,
is;q=0.25, nl;q=0.1, fr;q=0.05, eo;q=0.03; *;q=0.001
and that's hard to model, not to speak of that others will have more weird
strings. I think the ability to quantify how well you read a language is a very
important feature, generating q-values will certainly be suboptimal. Also,
instead of the user ordering languages, languages should be ordered in the box
based on their q-values (that doesn't matter that much, of course, but it's nice
to have).

>Then servers should be able to implement some default
>preference in such a case, i.e. pay attention to the
>order.

Indeed, but it _is_ suboptimal, and not having *;q=0.001 would break pages (I
share Karl Ove's understanding. One could of course argue that it is the user's
fault not having entered all the languages the user knows how to read, but
then..... :-) ). I'd rather see q-values based on an exponential function than
no q-values at all, with *;q=0.001 added at the end, but the best is to have GUI
with a scrollbar (OK, I _have_ been looking at XUL and been into the code, but I
really should resist the temptation to start hacking and focus on my thesis....
:-)).

Comment 8

[Katsuhiko Momoi]

Modified the summary line so that thisb ug can be found easily.

This bug probably should be made a duplicate of
Bug 58034 where a patch has been proposed to generate
Q values. My point is that the values themselves are
not important, they just need to reflect the order
of the languages chosen by the user through the
existing UI.

Comment 9

[Katsuhiko Momoi]

Let's send this to gagan also.

Comment 10

[Katsuhiko Momoi]

CC'ed adrian.

Comment 11

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 12

[Andreas Becker]

Changing QA contact back to [e-mail].

Comment 13

[Gagan]

->0.9.2

Comment 14

[Adrian Havill]

Gagan, my patches to nsHTTPHanbdler.cpp that add Q values to both
Accept-Languages and Accept-Charset have been accepted. This bug has been fixed.
Instead of bumping the milestone to 0.9.2, please change this to RESOLVED FIXED.

Comment 15

[Ben Bucksch (:BenB)]

if you fixed it, you should own it.

Comment 16

[Adrian Havill]

This was fixed in bug 58034.

It was decided in bug 54093 that q values don't need to be manually input as the
UI allows one to imply the language priority well enough for most users.

Q values are assigned based on the language order.

Comment 17

[Teruko Kobayashi]

Verified as fixed in 5-14 build.