Mac language/locale cleanup

- Effectively revert revision 28193 (http://codereview.chromium.org/258037), this makes Mac match the other platform for what at it's core is used for the chrome concept of locale.
- For the ApplicationLanguage, the browser will end up with what Cocoa picks (same as before)
- All other process types will honor the language they got on the command line when starting up.
- When asked the apps language, have the same side effect as Windows and Linux has of pushing the language through to ICU also (so dates format right, etc.)
- During browser startup, if someone passed a language, bail because Mac can't support that.

TEST=The tips on the NTP and the dates on the history page are in the same language at the UI.
BUG=26856
BUG=22727
Review URL: http://codereview.chromium.org/399086

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32515 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 48 insertions, 5 deletions

diff --git a/app/l10n_util_mac.mm b/app/l10n_util_mac.mm
index fe09826..9861f14 100644
--- a/app/l10n_util_mac.mm
+++ b/app/l10n_util_mac.mm
@@ -5,14 +5,57 @@
 #import <Foundation/Foundation.h>
 #include "app/l10n_util_mac.h"
 #include "base/sys_string_conversions.h"
+#include "base/lazy_instance.h"
+
+namespace {
+
+class OverrideLocaleHolder {
+ public:
+  OverrideLocaleHolder() {}
+  const std::string& value() const { return value_; }
+  void set_value(const std::string override_value) { value_ = override_value; }
+ private:
+  DISALLOW_COPY_AND_ASSIGN(OverrideLocaleHolder);
+  std::string value_;
+};
+
+base::LazyInstance<OverrideLocaleHolder>
+    override_locale_holder(base::LINKER_INITIALIZED);
+
+}  // namespace
 
 namespace l10n_util {
 
-std::string GetApplicationLocale(const std::wstring& pref_locale) {
-  // NOTE: The Win/Linux version of this calls out to CheckAndResolveLocale
-  // to do some remapping. Since Mac is using real locales that Cocoa has
-  // to be able to load, that shouldn't be needed.
-  return [[[NSLocale currentLocale] localeIdentifier] UTF8String];
+const std::string& GetLocaleOverride() {
+  return override_locale_holder.Get().value();
+}
+
+void OverrideLocaleWithCocoaLocale() {
+  // NSBundle really should only be called on the main thread.
+  DCHECK([NSThread isMainThread]);
+
+  // Chrome really only has one concept of locale, but Mac OS X has locale and
+  // language that can be set independently.  After talking with Chrome UX folks
+  // (Cole), the best path from an experience point of view is to map the Mac OS
+  // X language into the Chrome locale.  This way strings like "Yesterday" and
+  // "Today" are in the same language as raw dates like "March 20, 1999" (Chrome
+  // strings resources vs ICU generated strings).  This also makes the Mac acts
+  // like other Chrome platforms.
+  NSArray* languageList = [[NSBundle mainBundle] preferredLocalizations];
+  NSString* firstLocale = [languageList objectAtIndex:0];
+  // Mac OS X uses "_" instead of "-", so swap to get a real locale value.
+  std::string locale_value =
+      [[firstLocale stringByReplacingOccurrencesOfString:@"_"
+                                              withString:@"-"] UTF8String];
+
+  // On disk the "en-US" resources are just "en" (http://crbug.com/25578), so
+  // the reverse mapping is done here to continue to feed Chrome the same values
+  // in all cases on all platforms.  (l10n_util maps en to en-US if it gets
+  // passed this on the command line)
+  if (locale_value == "en")
+    locale_value = "en-US";
+
+  override_locale_holder.Get().set_value(locale_value);
 }
 
 // Remove the Windows-style accelerator marker and change "..." into an