Browser language setting is already tracked for every visitor.
That data should also be available within the frontend.
I agree that this is interesting. Right now though, we don't even store the data in the 1st normal form (e.g. de-de,de,en-us,en).
Sometimes we have multiple occurences of the same language, e.g. de-de,de,en-us,en - which one is important here? de-de or de? Are they the same? What about en, en-gb and en-us?
What is important here? Should we just count the first language or all in the list? Should we build multiple statistics like "First Browser Language", "Second Browser Language"?
I guess the main language should be enough for most users.
Btw. I'm already on that. Guess I'll finish that by the end of the week...
Ah nice! Good to know, almost started with it myself :)
Only first language of the list, to keep things simple I think.
We could alternatively look at secondary languages if the first one is en-us for example, because I know lots of browsers ship by default with en-us settings and users don't necessarily change it.
In 3f49038: refs #3726 adding reports for browser language of visitors
In d1546c5: refs #3726 small test for method to get language from browser setting
In abce17a: refs #3726 fixing test
In b2aeb6a: refs #3726 added language names to translations
In 74ff8ea: refs #3726 small improvements to detection method
In e29d059: refs #3726 fixing some integration tests
Thanks! :-) I was scratching my head for the last 5 minutes and wondered why tests were suddenly failing on Travis..
In 952dbcd: refs #3726 fixing integration test files
Very nice changes!
In 2826710: small refactor refs #3726
In 09bdded: fixes #3726 use Piwik_Common::extractLanguageCodeFromBrowserLanguage instead of new method to get language code