Load locale files from the CDN

VERIFIED FIXED in 2014-10-21

Status

P2
normal
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: mat, Assigned: mat)

Tracking

({perf})

2014-10-21
Points:
---

Details

(Assignee)

Description

4 years ago
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.
(Assignee)

Comment 1

4 years ago
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.
(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.
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
(Assignee)

Comment 4

4 years ago
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.
(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). :-/
(Assignee)

Comment 6

4 years ago
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.
Status: NEW → ASSIGNED
Target Milestone: --- → 2014-10-14
(Assignee)

Comment 7

4 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: 2014-10-14 → 2014-10-21

Comment 8

4 years ago
Verified as fixed in https://marketplace.allizom.org/ on FF36 (Win 7).
Postfix screencast http://screencast.com/t/totZW4NQwM
Closing bug.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.