Open GoogleCodeExporter opened 9 years ago
hi. good idea. you are right. we should send the browser's language when
available. however, this is already avaiable in user-agent string, so it might
be redundant to send it twice.
Original comment by willards...@gmail.com
on 20 Jul 2011 at 7:00
Correction: Patrik is right, this should be in there, since it needs to be
pulled from the Accept-Language headers.
for example (from my firefox browser):
Accept-Language: en-us,en;q=0.7,es;q=0.3
Original comment by willards...@gmail.com
on 21 Jul 2011 at 12:21
If the language isn't available in the user-agent string there's really no
definitive way for an SSP to determine the user's language anyway.
Original comment by mark.mce...@gmail.com
on 21 Jul 2011 at 7:52
Thought I posted this earlier but looks like it only went to mail list...:
The lang could be in User Agent but it's rarely there.
It is common (but not strict) to see for for Safari, AndroidWB and unusual for
the most other browsers.
HTTP does have a special header for this - Accept-Language. It is most likely
that a browser will send this header then in UA-string.
Ideally the value can be taken from there and put into the open RTB request
field by the SSP server.
Original comment by mich...@strikead.com
on 21 Jul 2011 at 8:07
We might want to step back on this. There are probably 2 values that are
useful, which can be determined in a couple of ways, I'd be leery about
constraining supply-sources approaches:
1. language of the page/environment
In CONTEXTWEB's case we do real-time using our RTC service to do analysis of
the page to determine language at the same time we classify it into the IAB
taxonomy
2. language(s) the user can accept/read
This could be determined by looking at the Accept header, or indexing user
behavior, or some other metric
Original comment by jays...@gmail.com
on 22 Jul 2011 at 12:16
Original issue reported on code.google.com by
patrik.o...@gmail.com
on 20 Jul 2011 at 8:09