1079894 - Load locale files from the CDN

Status: VERIFIED FIXED

(Marketplace Graveyard :: Consumer Pages, defect, P2)

Description

[Mathieu Pillard [:mat]]

When Marketplace loads, it loads l10n.js, which does some detection and figures out which locale file to include dynamically. This locale file is a js file generated at build-time.

However, we load the local files from https://marketplace.firefox.com/ instead of the CDN. This is fine in the true packaged app, where the js files are going to be in the package, but for any other situation, we should load the locale file from the CDN instead, to gain performance.

Comment 1

[Mathieu Pillard [:mat]]

bonus: we probably shouldn't bother to load en-US.js for english, as that's the language we write the original strings into anyway. There might be a good reason to do this, need to investigate.

Comment 2

[Christopher Van Wiemeersch [:cvan]]

(In reply to Mathieu Pillard [:mat] from comment #1)
> bonus: we probably shouldn't bother to load en-US.js for english, as that's
> the language we write the original strings into anyway. There might be a
> good reason to do this, need to investigate.

It looks like we do load `en-US.js` by default. Odd, I thought we never did this.

Comment 3

[Christopher Van Wiemeersch [:cvan]]

Also, worth noting that because our locale files load from Zamboni, and all pages are still *not* gzip'd by default, the locale `.js` files are not gzip'd.

https://marketplace.firefox.com/media/fireplace/locales/en-US.js?b=1412797722291

Comment 4

[Mathieu Pillard [:mat]]

Oh, nice catch. I thought static assets were always served gzipped. Looks like our CDN does it on the fly if necessary (returning non-gzipped the first time we ask, and then gzipping everytime). If that's the case then fixing this bug will have the nice side-effect of taking care of gzip, but we might want to open a bug to make sure all *static* assets are gzipped, even over https.

Comment 5

[Wil Clouser [:clouserw]]

(In reply to Christopher Van Wiemeersch [:cvan] from comment #2)
> (In reply to Mathieu Pillard [:mat] from comment #1)
> > bonus: we probably shouldn't bother to load en-US.js for english, as that's
> > the language we write the original strings into anyway. There might be a
> > good reason to do this, need to investigate.
> 
> It looks like we do load `en-US.js` by default. Odd, I thought we never did
> this.

We didn't used to.  We added it back pretty recently because the English strings we wanted in the Feed aren't the same as the fallback (the msgid != msgstr). :-/

Comment 6

[Mathieu Pillard [:mat]]

Ok well, too bad, that's a nice performance boost for English. We should at least try to figure out which strings are concerned so that we don't generate a big file when we actually only need a couple strings. But that'll be for another bug.

https://github.com/mozilla/fireplace/pull/710 makes us use the CDN if we are in a website context (actually, if our index.html was served by commonplace). The CDN then does gzip for us, killing 2 birds with one stone.

Comment 7

[Mathieu Pillard [:mat]]

Fixed in https://github.com/mozilla/fireplace/commit/bfe7e47a02ddec135590aa46fabeadc80d95147b

STR:
- Load https://marketplace-dev.allizom.org/ with developer tools network tab opened
- Check the JS files it loads. It should load a file corresponding to your browser locale (if supported, else en-US.js)
- Verify that this file is served from our CDN (for -dev, that's https://marketplace-dev.mozflare.net/)
- Verify that this file exists and that translations work.

Comment 8

[Iulian Timis]

Verified as fixed in https://marketplace.allizom.org/ on FF36 (Win 7).
Postfix screencast http://screencast.com/t/totZW4NQwM
Closing bug.