Skip to content
This repository has been archived by the owner on Nov 3, 2021. It is now read-only.

[l10n] Sometimes, l10n does not get loaded properly #5071

Closed
wants to merge 1 commit into from

Conversation

lissyx
Copy link
Contributor

@lissyx lissyx commented Sep 23, 2012

When the system app starts, in its early days, it sometimes seems not
being able to find the correct navigator.language value. Hence it
defaults to 'en-US' while the rest of the system will be correctly
localized. This has been hit on both Nexus S and Otoro. This patch
mitigates the issue by forcing re-reading the 'language.current'
settings and when receiveing the value, relocalizing the document.

When the system app starts, in its early days, it sometimes seems not
being able to find the correct navigator.language value. Hence it
defaults to 'en-US' while the rest of the system will be correctly
localized. This has been hit on both Nexus S and Otoro. This patch
mitigates the issue by forcing re-reading the 'language.current'
settings and when receiveing the value, relocalizing the document.
@lissyx
Copy link
Contributor Author

lissyx commented Sep 23, 2012

@fabi1cazenave @vingtetun Not sure if it's a correct fix, but it somehow mitigates the issue for me.

@fabi1cazenave
Copy link
Contributor

Reviewing. Your PR makes sense, I have to check it’s enough (i.e. I have to check nothing more is required on the Gecko front).

@timdream
Copy link
Contributor

@lissyx The problem you are trying to fix is #3928. Thank you for finding the root cause but I am not sure this is the correct fix. We should fix this on Gecko side instead. The code in question is here:

  SettingsListener.observe('language.current', 'en-US', function(value) {
    Services.prefs.setCharPref('intl.accept_languages', value);
  });

I wonder why the new locale value set in Services.prefs.setCharPref doesn't survive reboot? Do anyone know that?

@timdream
Copy link
Contributor

Also console.log in this pull request should be removed.

@vingtetun
Copy link
Contributor

@lissyx Hey! I think this patch should make it but in order to land something we need a bugzilla # now. Can you open a bug on bugzilla and reformat your commit message so it contains it? Closing until then.


For the v1 release and to help tracking it has been decided that all Gaia issues should be first opened on Bugzilla (https://bugzilla.mozilla.org/enter_bug.cgi?product=Boot2Gecko) with a blocking-basecamp? and/or the approval-gaia-master? flags set.

There is a lot of Pull Requests to the master branch that does not have an attached bugzilla and this make it harder to know what exactly is a priority or not for this release. If you believe your PR is important enough to be part of the v1 release please open a new one with a bugzilla bug attached and referring to the one that has been closed for history.

Theorically all PRs should not target v1. But I don't know of a way to filter PRs on GitHub and having 71 PRs opened feels like something is wrong somewhere. So the goal of this clean up is to make it clearer which PRs needs something to be done right now.

@vingtetun vingtetun closed this Oct 15, 2012
@lissyx
Copy link
Contributor Author

lissyx commented Oct 16, 2012

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
4 participants