- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
I think you're missing the point of the HTTP_ACCEPT header for mobile devices. (Obviously, apart from the example in the original post, in the context I am about to provide...)
Mobile application developers can use the mime types specific in the http_accept header as aprt of their CGI scripts to determine what kind of content to send to a device about which they may or may not know any details of its specification. Which one of many possible ring tone formats to send. Whether it can read XHTML or needs WML. Whether it can display JPGs or needs ye olden stylee .WBMP files. Whether it can use that Java game you're about to charge them a fiver for the pleasure of downloading.
For every new shiny mobile handset with all the bells and whistles that sends a very long list of mime types that it can accept, there are handsets which send a very short list because it is all they can handle. You'd be far more peeved about forking out £2.50 for a ringtone or £5 for a java game to discover it won't work on your phone, than for paying an extra penny in the first place (even if mostly because you're not conscious of the latter [;)]) It's far from dishonest, and specifying a long list of almost everything future proofs against the adoption of .mp5 or .mp6 ringtones and .advancedxhtml or .superdooperxml in the future; when these handsets will still be around, and won't be getting patched every time there's a software update, unlike your PCs.
Although there are arguments for it, none of what I've said stops the orignal post being a fine example of "WTF?" [8-)]
Admin
If a news story (for example) is written in French, but translated copies are available in English, Spanish, etc., then the server should consider the French copy to be superior and the translations to have a quality proportional to the skills of the particular translator.
So story.html, on the server side, would have q= factors of:
French: 1
English: 0.8
Spanish: 0.6
If a user has
Accept-Language: es, en;q=0.7, fr;q=0.5
then the server should, for this request, multiply the q= values on the client and the server:
French: 1 * 0.5 = 0.5
English: 0.8 * 0.7 = 0.56
Spanish: 0.6 * 1.0 = 0.6
So in this case the Spanish version of the article should be served. Although it is the most poorly translated version, the transation is not so poor as the user's understanding of French.
Admin
Admin
Admin