GitLab

There were two issues:

1. The new language::GetApplicationLocale() function that was
introduced as part of M71 changes to variations service did not
match the previous behavior - it had an early return when the
locale pref didn't exist - which would be hit when the user didn't
explicitly set their language in Chrome. But that's not sufficient
since l10n_util::GetApplicationLocale() actually does logic beyond
what's provided to it via the pref. On Mac, it gets the language
from the system. The changes to components/language were sufficient
to fix things on Mac.

2. On non-Mac platforms, the call to l10n_util::GetApplicationLocale()
also had a dependency on ResourceBundle being initialized, so this part
did not work correctly either. IsLocaleAvailable() was returning false
when there was no ResourceBundle. There was also a TODO to make the
LocaleDataPakExists() API static - which then could be used without
ResourceBundle being initialized. This was mostly straight-forward
except for use of delegate_->GetPathForLocalePack(). This delegate
API was only overridden (outside of tests) by CastResourceDelegate.
Given cast doesn't use the code path in question (variations), the
code is changed to only use that delegate if the resource bundle has
been initialized.

Also adds a check that the locale determined after resource bundle
has been loaded matches what was used to initialize variations.

Bug: 908114
Change-Id: Ief6bf3e370bf2773187387c1fd12fc4517b31a69
Reviewed-on: https://chromium-review.googlesource.com/c/1349770
Commit-Queue: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Reviewed-by: anthonyvd <anthonyvd@chromium.org>
Reviewed-by: Xi Han <hanxi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#610954}