retry if the i18n json request fails

[ara4n]

rather than having ugly Missing Internationalisation warnings eeeeeeeeeverywhere

[bwindels]

I think this is and old copy of Riot (cached by the browser, but not present on the server any more after deploying the new copy) trying to request the languages file with an old content hash, and hence 404-ing.

#8710 added cache busting for language files, to make sure they aren't cached, but this comes with the downside that the filename changes across versions, causing this to happen. Not 100% sure why the app would be a cached version while the languages file isn't cached, but I'd guess because it's requested with XHR.

[bwindels]

This was reported with this screenshot, which seems to indicate some translations are available, so the above theory might be off.

[aaronraimist]

Related: #9422

[bwindels]

One way to prevent this would be to make all of the assets available offline through our service worker. This would also preload icons, etc. The hardest part probably being creating a list of all of our assets (during build) without causing a maintenance headache, although we might be able to get rid of the content hashes with this approach.

[ara4n]

the service worker would still need content hashes to know reliably when content is stale, i think.

Why can't we retry the i18n request if it fails?

[bwindels]

the service worker would still need content hashes to know reliably when content is stale, i think.

there is indeed an edge case there, also discussing with Michael on the linked ticket #12591

Why can't we retry the i18n request if it fails?

At least on /develop, we remove the old version when deploying a new one, so the languages file with the old content hash isn't there anymore.