Fix CHECK failure in l10n_util::IsLocaleAvailable().

Fix CHECK failure in l10n_util::IsLocaleAvailable().

If the ResourceBundle is not yet initialized, l10n_util::IsLocaleAvailable() should
return false to avoid the CHECK failure in ResourceBundle::GetSharedInstance().

BUG=230432
TEST=CQ

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=194463

[hshi1, 2013-04-16 18:17:32]

Junshik, can you please review this?

This failure came up after I landed my previous fix for bug 230432. Sample
crash: https://crash.corp.google.com/reportdetail?reportid=8a2d767ec481a44a

[hshi1, 2013-04-16 19:34:42]

FWIW - I still don't have a Windows machine to test this, but on a Chrome OS if
I attempt to call l10n_util::GetApplicationLocale with the proposed fix, then I
will just get an empty string. But if I don't put in this fix, then I'll fail in
the CHECK.

[jungshik at Google, 2013-04-16 20:04:55]

https://codereview.chromium.org/14230008/diff/1/ui/base/l10n/l10n_util.cc
File ui/base/l10n/l10n_util.cc (right):

https://codereview.chromium.org/14230008/diff/1/ui/base/l10n/l10n_util.cc#new...
ui/base/l10n/l10n_util.cc:252: return false;
With this, in https://codereview.chromium.org/13825003/ , we'll always fall back
to en-US

I wonder if we can make LocaleDataPakExists() static
in chromium/src/ui/base/resource/resource_bundle.cc

[hshi1, 2013-04-16 20:36:39]

https://codereview.chromium.org/14230008/diff/1/ui/base/l10n/l10n_util.cc
File ui/base/l10n/l10n_util.cc (right):

https://codereview.chromium.org/14230008/diff/1/ui/base/l10n/l10n_util.cc#new...
ui/base/l10n/l10n_util.cc:252: return false;
It seems very difficult to make LocaleDataPakExists() static because it calls
GetLocaleFilePath() which depends on the class member |delegate_| to function
properly.

On 2013/04/16 20:04:55, Jungshik Shin wrote:
> With this, in https://codereview.chromium.org/13825003/ , we'll always fall
back
> to en-US
> 
> I wonder if we can make LocaleDataPakExists() static
> in chromium/src/ui/base/resource/resource_bundle.cc

[hshi1, 2013-04-16 20:46:29]

Would it be ok to land this first to fix the CHECK failure and track the
refactor of resource bundle in a separate work item?

I'm afraid it is far from trivial to make that function static under the current
design. It would require someone more familiar with resource bundles.

While I agree that "falling back to en-US" is not ideal user experience, please
note that this is a very isolated case that only happens when due to improper
installation, user's default data dir is inaccessible. After chrome restarts
with the correct data dir, the locale can be properly loaded.

[jungshik at Google, 2013-04-16 20:53:24]

On 2013/04/16 20:46:29, hshi1 wrote:
> Would it be ok to land this first to fix the CHECK failure and track the
> refactor of resource bundle in a separate work item?

Ok. Let's go ahead then. Could you add a TODO comment referring to a place where
this can be a problem (i.e. the caller you added in
https://codereview.chromium.org/13825003/  )? 

With that TODO, LGTM


> 
> I'm afraid it is far from trivial to make that function static under the
current
> design. It would require someone more familiar with resource bundles.
> 
> While I agree that "falling back to en-US" is not ideal user experience,
please
> note that this is a very isolated case that only happens when due to improper
> installation, user's default data dir is inaccessible. After chrome restarts
> with the correct data dir, the locale can be properly loaded.

[hshi1, 2013-04-16 22:13:22]

Committed patchset #2 manually as r194463 (presubmit successful).