[Mac] Localize app shims with the OS preferred language.

chrome/browser/web_applications/web_app_mac.mm

Index: chrome/browser/web_applications/web_app_mac.mm
diff --git a/chrome/browser/web_applications/web_app_mac.mm b/chrome/browser/web_applications/web_app_mac.mm
index aaa84468fc4000a01a92bcbb37aec064e106ef7b..abb9cfa5d9aca32e30075eb000fc6970a2ed5b24 100644
--- a/chrome/browser/web_applications/web_app_mac.mm
+++ b/chrome/browser/web_applications/web_app_mac.mm
@@ -897,9 +897,13 @@ bool WebAppShortcutCreator::UpdatePlist(const base::FilePath& app_path) const {
 
 bool WebAppShortcutCreator::UpdateDisplayName(
     const base::FilePath& app_path) const {
-  // OSX searches for the best language in the order of preferred languages.
-  // Since we only have one localization directory, it will choose this one.
-  base::FilePath localized_dir = GetResourcesPath(app_path).Append("en.lproj");
+  // Localization is used to display the app name (rather than the bundle
+  // filename). OSX searches for the best language in the order of preferred
+  // languages, but one of them must be found otherwise it will default to
+  // the filename.
+  NSString* language = [[NSLocale preferredLanguages] objectAtIndex:0];

[tapted, 2015/05/14 07:53:14]

should it use
l10n_util::NormalizeLocale(l10n_util::GetApplicationLocale(std::string())); ?
This is what UpdateAppShortcutsSubdirLocalizedName is doing.

i.e. the first preferredLanguage might not be supported by Chrome, and so a
different localization might be getting used for info_->title, and we should aim
to ensure that these match.

(Also are there any implications for this bug for
UpdateAppShortcutsSubdirLocalizedName()?)

And, I'm _pretty_ sure we don't need to worry about UpdateDisplayName being
called for an app that already has a locale folder due to an upgrade (i.e.
because the folder is deleted recursively first) - but that might be something
to check.

Also is there a plan to do a batch upgrade, e.g. a once-off thing if "en"
doesn't appear in [NSLocale preferredLanguages]?

[jackhou1, 2015/05/15 00:41:08]

With the app shim, we don't actually care what language the folder says, we
always write strings for the best available language. I.e. the shim pretends to
support the OS preferred language, but always displays Chrome's language. For
the most part they are the same. If Chrome defaults to "en" because none of the
OS preferred languages are supported, we want the shim to show the english app
name and not "Default <extension-id>".

For the Chrome Apps folder, it makes more sense for the localization folder to
actually match the language of the strings. If Chrome's language changes, we end
up writing multiple localization folders, and they'll all be correct. If none of
them are in the OS preferred languages, the display name defaults to "Chrome
Apps", which is fine.
That's right. But creating shortcuts while one exists will merge the
directories. I don't think it matters much, it'll either overwrite the
InfoPlist.strings or there'll be two localization folders.
If we want to batch upgrade, I think it's better to use the upgrade-all
mechanism. I'd prefer not to add code for once-off behavior.

+  base::FilePath localized_dir = GetResourcesPath(app_path).Append(
+      base::SysNSStringToUTF8(language) + ".lproj");
   if (!base::CreateDirectory(localized_dir))
     return false;