Changed Accept-Language header to start with the locale with country code (with more tests)

[patcheng]

a re-implementaiton of #2746

in order to make it easier to test, I added a new method:

/**
 Sets the "Accept-Languages" HTTP header in request objects made by the HTTP client.

 @param languages an array of NSLocale objects or NSString objects, where each string is a language ID.
 */
- (void)setAcceptLanguageHeader:(NSArray*)languages;

I added the tests based on what [NSLocale currentLocale] and [NSLocale preferredLanguages] returned on my environment.

Let me know if you want an explicit test for the default Accept-Language.

[kcharwood]

cc @cnoon and @kylef for some input here.

[cnoon]

You make a great point @kcharwood in #2746 that this doesn't take into account the languages available in the app. I think that is the first question that needs to be solved. Should it be grabbing?

NSBundle.mainBundle().preferredLocalizations

That would certainly give you consistency between the app and the server.

As for whether the NSLocaleScriptCode should be included, I'm not really sure. I would assume it would be more consistent with RFC-2616 3.10 to not include it, but I can't say for sure.

Thoughts @kylef?

[patcheng]

I did a quick test using Simulator

My test application has 'English' localized resource. And my computer is set to English US.

Application Language	Application Region	NSBundle mainBundle preferredLocalizations	NSLocale preferredLanguages	NSLocale currentLocale
System Language	System Region	en	en-US	en_US
English	United State	en	en	en_EN_US_POSIX
English	United Kingdom	en	en	en_GB

[kcharwood]

@patcheng I think the more interesting tests would be what happens when your app doesn't support the localization the user has requested. That's where things get tricky, and it's important to understand what is going to be shown to the user.

For example, lets say your app supports English and Spanish, and your user has French as the system language. The language your app will load in actually isn't deterministic. It chooses the last valid language the OS was set to that your application does support. For example, if they changed their system to Spanish, then to French, the app would load in Spanish. If they never changed their system to Spanish, then it will most likely load in English.

In my experience, NSBundle mainBundle preferredLocalizations always returns the language the app is loaded in, which IMO is the correct language to use for the web requests, since you would want the content retrieved from the web server to match the language loaded in the app, while the NSLocale API's return the system setting, which may or may not match the actual language showing in the current foreground app.

[kcharwood]

cc @kylef for thoughts

[jshier]

Thanks for the PR! However, due to its age it will not be merged. If the issue is still occurring feel free to open a new PR.