Any HTTP Experts? Need help with Accept-Language header
-
So I'm having to implement multiple language support on our server by handling the Accept-Language header, and have some questions that aren't really addressed in the RFC: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
So, a client can not only specify multiple languages, but can assign a quality value to each one to denote an order of preference. i.e. from the spec,
Accept-Language: da, en-gb;q=0.8, en;q=0.7
would mean: "I prefer Danish, but will accept British English and other types of English."First, it seems WTFy to me that you're assigning quality values instead of just a comma-separated ordered list. Makes parsing the thing that much harder because now I have to sort it. And I really don't care whether you like british english .2 more, or .1 more. I only care about the order.
But on to my question: How do I handle (or do I need to handle) languages that have the same quality? i.e.
Accept-Language: da, en
Both would default to a quality of 1. Should they go into an arbitrary order, or the order they were recieved in, or can I just consider that an invalid use case and handle it in the most convenient way for me (ignoring the second one)?
-
A more elaborate example is
Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-cVerbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then send the text/x-dvi entity, and if that does not exist, send the text/plain entity."
@vt_mruhlin said:
Both would default to a quality of 1.
Fuck 'em.
Manually add a value of >1 to inqualified entries, in the the order they appear, so that text/html gets 1.2, and text/x-c gets 1.1. Then sort.
The result is utterly predictable to a user, and compliant with the example result => therefore good.
-
Ah thanks. I was only looking at the Accept-Language section, and ignoring the Accept section. Didn't see that example.
-
Welcome.
