We need a way to show localized net error messages (e.g. "Server not found") to the user, for instance in the Browser app. If I understand correctly, these messages are currently displayed directly by Gecko and Gaia's Browser app doesn't know about the fact that a network error has occurred. See http://mxr.mozilla.org/mozilla-central/source/b2g/locales/en-US/chrome/overrides/netError for examples of error messages. Possible solutions include: a) Run Gecko in a certain locale (via -UILocale?) and bundle all toolkit localization with b2g. All errors will be displayed localized, but the restartless locale change will no longer be possible. We will also need to choose a version of Gecko to base on (or a release train or channel) and bundle corresponding translations with b2g. b) Have Gecko bubble up error events and Gaia intercept them and show custom error messages. All errors would need to be reimplemented in Gaia. For localization, ideally we would reuse the existing translations, although that might mean, again, choosing a specific version of Gecko to base on. b1) We could use DTDs (like we currently do in toolkit) and reuse exactly the same files in Gaia. Restartless locale change will not be possible then. b2) We could reimplement (or convert) toolkit's netError.dtd to .properties and use standard Gaia localization library. c) other ideas?

FWIW, these error pages are actually quite complex. There are 25 different error codes handled in [1], and that's likely not all of the errors we care about. I don't want us to fall down a rat-hole here. [1] http://hg.mozilla.org/mozilla-central/file/5b3bf49ce3cf/docshell/base/nsDocShell.cpp#l3930

Would be good to keep under a radar for "all messages" that Gecko creates ( or events ) that could eventually receive a UX treat ( = be part of UX review discussion .) As an example, we have the discussion (https://groups.google.com/forum/#!topic/mozilla.dev.b2g/FB-hspd-ekg/discussion) that talks about Window trust level. I feel that a way to move UX discussion is first to keep all in a meta bug perhaps or a wiki page. Do you guys know of such a documentation and/or is this important?

No longer blocking browser-api because we decided to do this without the browser API's help. But I think this is an obvious basecamp blocker.

Justin, how is the browser app working around this? Can we use the same workaround from the system app?

(In reply to Chris Jones [:cjones] [:warhammer] from comment #4) > Justin, how is the browser app working around this? > > Can we use the same workaround from the system app? I don't know if the browser app currently works around this, but the plan was for someone who understands l10n to set the correct env vars (or whatever) so that we showed localized Gecko error messages. We could use the same workaround for the system app, although of course that would mean showing Gecko error messages for apps, we might not want to do.

Chris Lee, we'd love your input on whether or not this should be a Basecamp blocker.

(In reply to Andrew Overholt [:overholt] from comment #6) > Chris Lee, we'd love your input on whether or not this should be a Basecamp > blocker. If this is not a basecamp blocker, that means we're willing to ship a device with English "server not found", "network not available" etc. error messages in all locales.

Chris Jones, could you repeat your comments here regarding app localization vs. browser localization (that's what you alluded to during triage IIRC). Thanks.

... when apps fail to load from the network. Part of the input data is what's currently in the marketplace: if the apps are mostly "link apps" (which is the case last I heard), meaning network errors will be common, then I think this should block. But it sounds like the workaround for browser will apply here out of the box. Justin, is this the bug for the l10n magic env var or whatever?

Sorry, mid-aired: the "... " in comment 9 was continuing on from comment 7.

> But it sounds like the workaround for browser will apply here out of the box. Yes, that's my understanding. You get localized Gecko error messages in apps for free, if you have them in the browser. > Justin, is this the bug for the l10n magic env var or whatever? That's what I thought; maybe stas knows better.

Let's add more questions: Do we need to deal with multi-process/e10s? What does the settings app do when you select a language? Right now, and "should"?

> Do we need to deal with multi-process/e10s? Yes. Many of our apps are currently OOP, and we're working towards making more of them run out-of-process.

(In reply to Axel Hecht [:Pike] from comment #12) > Let's add more questions: > > Do we need to deal with multi-process/e10s? Gaia application are run OOP. Web content is run OOP. so I would say yes :) > > What does the settings app do when you select a language? It change the value of a mozSetting that itself update the value of the preference used by navigator.language. See http://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/settings.js#60

OK, the current behaviour is bad for the web. Rephrasing: When changing the selected locale in gaia settings, all gecko process should change their prefs to either - LOCALE set to lang, or it's POSIX variant (TBD) - or general.useragent.locale is set to lang The accept-lang pref should remain to be a localized pref in the gecko backend, yielding navigator.language to pick up the first of those. Setting accept-lang directly breaks language fallback when surfing the web from the device, and that's bad. I don't think it matters much if we're using process variables or pref values inside the process, whichever is easier. But we do need to communicate this across all processes, and verify if we need to flush xul cashes for stuff or not.

Should this bug be also about restarting Gecko with -UILocale to complete the locale change?

no restart required

Staś, I though -UILocale does only set general.useragent.locale anyhow (and trigger the locale switch/setting this implies)? We can probably do that all dynamically at runtime, esp. when changing L10n of displayed XUL isn't a problem, as it was in the past with dynamic UI locale switching.

I think that the road from gaia settings to gecko is covered by bug 796079. I don't know if that would work the other way around, ie, make UILocale work. There's a dedicated bug 796335 for that way. Whether we need that or not depends a bit on where the settings app is actually getting the list of langauges from in the end, right now that's hardcoded. Is there a bug on that?

Stealing.

Should have been resolved by bug 768939.

(In reply to Vivien Nicolas (:vingtetun) from comment #21) > Should have been resolved by bug 768939. Going to guess you meant bug 796079.