1. Load https://marketplace.firefox.com/?lang=fr 2. Load the network tab and watch the scripts that get loaded. 3. Notice https://marketplace.firefox.com/media/fireplace/locales/fr.js?b=1395207431756 gets loaded 4. Refresh the page 5. Notice now https://marketplace.firefox.com/media/fireplace/locales/fr.js?b=1395207440214 gets loaded There are two bugs here: 1. https://github.com/mozilla/fireplace/blob/bfedac3/hearth/media/js/l10n.js#L47 looks up `document.body.getAttribute('data-buildIdJs')` but that should be ` document.body.getAttribute('data-build-id-js')` or `document.body.dataset.buildIdJs` (but use the former because IE), which means we're falling back to a unique numeric timestamp, so that URL never gets cached and you end up loading it every synchronous page load/fresh Marketplace app launch. 2. We should either rely entirely on ETags or cache fingerprint. I'd prefer the latter since the user won't have to wait on the network at all. So, let's keep a content hash for each locale's JS file, and reference that from `l10n.js`. This should programmatically be generated from probably commonplace and injected into some settings file or JS file whose module gets included and minified into our `main.js` bundle.

Not needed for tarako v0 as this should be included in the package.

Now that bug 1079894 is fixed, the locale files are served from the CDN with a far future expires and obey Last-Modified/If-Modified-Since. I also fixed the data-build-id-js error in that bug, so the cachebusting string doesn't change every refresh. Now that they are cached properly and using the build ID correctly, I don't think we should bother changing the cachebusting mechanism for those files. We'll probably change at least one string every deploy anyway.

See comment 2.