language pack lost after update
When using the automatic updater to go from TB 4.0-alpha-2 to 4.0-alpha-3 the language pack extension seems to be lost.
Tested with the 4.0-alpha-2 es-ES build and MAR files from https://people.torproject.org/~mikeperry/builds/4.0-alpha-3/
My guess is that the MAR file was not created correctly. I will investigate.
Activity
The problem is not in the MAR file. What is happening is that the update URL contains en-US instead of es-ES. Apparently, setting the general.useragent.locale pref to es-ES is not enough to cause the %LOCALE% pattern in app.update.url to be replaced with es-ES (this makes sense for Firefox but not for Tor Browser). brade and I will work on a fix.
-
Replying to mcs:
The problem is not in the MAR file. What is happening is that the update URL contains en-US instead of es-ES.
Which (I meant to explain) causes the en-US MAR file to be downloaded and applied instead of the Spanish one.
-
The fix is to re-populate the contents of a file named update.locale (located within the top-level omni.ja file). This needs to be done during the locale packaging that is done within gitian/descriptors/*/gitian-bundle.yml I have a patch that I am testing now.
The code in nsUpdateService.js reads the contents of this file and uses that when replacing %LOCALE% within the update URL. We can fix this for 4.0-alpha-3 but I am not sure what to do about 4.0-alpha-2 (non en-US bundles will be "upgraded" to en-US bundles). One that happens, users will have to download a new non-English copy of TB.
Well, it sounds like 4.0a2 users will already be bitten by this, and there is nothing we can do about that, short of disabling the updater. We just have to warn people on the blog (which is rough, because that will only reach English speakers already).
I am thinking that if we can get a fix together by tonight, then we can hold 4.0a3 another day.. but otherwise, we'll just have to warn people twice instead of once..
-
Trac:
bug13245-patch.txt -
Replying to mikeperry:
I am thinking that if we can get a fix together by tonight, then we can hold 4.0a3 another day.. but otherwise, we'll just have to warn people twice instead of once..
I attached a possible fix. But it is untested because: (1) I don't have a partial 4.0-alpha-3 build to start from so I am starting from scratch and (2) I had to step out for a while and of course the build I started before I left failed early.
It might be faster for you or gk to apply this patch and re-package the build by re-running the bundle step. The biggest danger is that my untested code is wrong.
Once anyone has some builds, brade and/or I can do some testing, although anyone can do the following with a non en-US build to verify that this fix is correct: a) use about:config to set set app.update.log = true b) open the browser console (Shift+Ctrl+J) and clear it c) open the about box and click "Check for Updates" Then look on the console and see if the update URL that was accessed includes the language, e.g., es-ES.
My build just failed again so I will have to try to debug it (I am not remotely close to the bundle step yet).
-
Ok, it looks like the request was sent to https://www.torproject.org/dist/torbrowser/update_2/alpha/Linux_x86_64-gcc3/4.0-alpha-3/es-ES?force=1.
I think this means we're good! Thanks a lot for the quick work here!
-
Mike fixed this via: https://gitweb.torproject.org/builders/tor-browser-bundle.git/commit/a92ec3e06a17f1a19c35590c8ad93081b180ef4e
Trac:
Status: new to closed
Resolution: N/A to fixed
Keywords: N/A deleted, TorBrowserTeam201409 added
