Issue 692769  has been merged into this issue.

This will likely block new OOBE. It doesn't looks like P3.

#2, discussing it out-of-band

unrelated to #2, It looks like the only place where this real-time change of language/locale occurs is on the language selection page in oobe. Just as a brainstorming idea: that page may be able to be special cased.

In all other cases of changing the language/locale that I've found, a restart is required (and the user is prompted to restart within the language selection UI).

Re #3:

> It looks like the only place where this real-time change of language/locale
>  occurs is on the language selection page in oobe.

That's not completely true. Public session also allows to select locale for each signin.

The tricky thing is that most of ChromeOS UI (actually everything before user session starts) is one large HTML page, so that we can control transitions and animations between screens.

> Public session also allows to select locale for each signin.
Good to know. What's a good way to see the Public session UI?

You need enterprise device.
I usually do this by patching code (to mimic that public sessions are enabled), but I cannot give you a working patch right now. I'll look into it later.

You can also use the public session UI on Linux-on-Chrome-OS by running a local test policy server.

See  issue 688471  (comments 2 & 3). It should be painless, so LMK if you hit a snag.

What came out of the priority discussion from #3?

> What came out of the priority discussion from #3?
We got caught on a blocking issue with oobe on ToT that prevented reviewing the UI. The next step is to review the areas that need switching to see if they are a small number of points where this kind of switch happens or whether we need large portions of the UI where this switch occurs.

If there are a small number of places:
Something we didn't discuss, but that I'm thinking about, is whether there are < 5 pages that could do well with JS function binding (or similar) to change the text. (so that the i18n-content system and the large i18n JSON transfer can be reduced or removed). This may also make the transition snappier on low end hardware because the number of strings transferred on change would be rather small and the replacements would be done at targeted locations (rather than needing to crawl the DOM as i18n-content does now).

Re #8:
> If there are a small number of places:

Formally, there are only 2 pages that support that:

chrome://oobe/oobe
chrome://oobe/login

But if you look at the mechanics behind that, you'll find that:
1) These two pages are actually the whole ChromeOS UI (well, we have a few more, but they are too small to mention).

2) We are using shared components with chrome://md-settings .

So this means that the language switching should be supported by all ChromeOS (and probably Chrome) components, as they could be used in OOBE.

CL at https://codereview.chromium.org/2886843005/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/27b6f79ce778bb7f2bc9a15a27e0d86d6f1656e8

commit 27b6f79ce778bb7f2bc9a15a27e0d86d6f1656e8
Author: dschuyler <dschuyler@chromium.org>
Date: Thu Jun 01 18:20:53 2017

[i18n] login UI i18n-content and values to $i18n{}

This CL changes the old i18n-content/i18n-values to the new (faster)
$i18n{}. There should be no functionality changes apparent to the
user.

BUG=692763

Review-Url: https://codereview.chromium.org/2918743002
Cr-Commit-Position: refs/heads/master@{#476356}

[modify] https://crrev.com/27b6f79ce778bb7f2bc9a15a27e0d86d6f1656e8/ui/login/account_picker/md_screen_account_picker.html
[modify] https://crrev.com/27b6f79ce778bb7f2bc9a15a27e0d86d6f1656e8/ui/login/account_picker/md_user_pod_template.html
[modify] https://crrev.com/27b6f79ce778bb7f2bc9a15a27e0d86d6f1656e8/ui/login/account_picker/screen_account_picker.html
[modify] https://crrev.com/27b6f79ce778bb7f2bc9a15a27e0d86d6f1656e8/ui/login/account_picker/user_pod_template.html

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cd00499d569a693685c81d4042b3cfe3219edd61

commit cd00499d569a693685c81d4042b3cfe3219edd61
Author: dschuyler <dschuyler@chromium.org>
Date: Thu Jun 01 18:22:18 2017

[i18n] use Polymer data binding to change locale strings

This CL uses Polymer variable binding to swap out i18n strings rather
than using i18n-content.

BUG=692763
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2886843005
Cr-Commit-Position: refs/heads/master@{#476358}

[modify] https://crrev.com/cd00499d569a693685c81d4042b3cfe3219edd61/chrome/browser/resources/chromeos/login/oobe_welcome.html
[modify] https://crrev.com/cd00499d569a693685c81d4042b3cfe3219edd61/chrome/browser/resources/chromeos/login/oobe_welcome.js
[modify] https://crrev.com/cd00499d569a693685c81d4042b3cfe3219edd61/chrome/test/data/webui/i18n_behavior_test.html
[modify] https://crrev.com/cd00499d569a693685c81d4042b3cfe3219edd61/ui/webui/resources/js/i18n_behavior.js

Using i18nDynamic as used in #15 above a workable solution, but it still needs to be done (so that all the i18n-content and i18n-values are removed).