element-web: Missing translation: en| - Unable to set language on Firefox

Recently I’ve seen lots of people reporting that they are seeing missing strings for languages that are properly translated. I’ve also gotten bit by this a few times. The console error that looks relavent is

Unable to set language 
Object { err: null, response: XMLHttpRequest }
rageshake.js:61:8

Screen Shot 2019-04-10 at 10 34 12 AM

I got it on /develop, other people on /app have reported the same issue.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 6
  • Comments: 121 (90 by maintainers)

Commits related to this issue

Most upvoted comments

I just applied some tuned cache settings for develop.element.io. If you use develop, please watch out for these issues over the next days / weeks, and let me know if there’s any change (positive or negative) here.

Clear your browser cache.

Unfortunately, most end users know nothing about the cache, so we need a better solution.

It’s unclear what this was blocked on, but it’s certainly worthy of picking up.

I believe at this point we know what causes it, we just need to figure out how to fix it.

the rageshake is really helpful, thanks. it looks like the out of date app is being detected correctly, but the forced reload isn’t happening still.

relevant lines

2022-03-24T21:03:23.873Z I startUpdater, current version is e638abf7c253-react-3bb0dc08e81e-js-6192325fe0b6 2022-03-24T21:03:23.924Z I Update available to e638abf7c253-react-f229ad640714-js-c541b3f1ce0f, will notify user 2022-03-24T21:03:23.924Z I reloadPage to [redacted] <-- reload should happen here, but appears to not

I will try to unpick that when I get some time next week.

This is being reported fairly regularly on Firefox so bumping the frequency.

At this point, if someone gets this not on Firefox, we might want a different issue.

Apparently it’s a very old Firefox bug that restoring sessions relies on disk cache and disregards HTTP headers: https://bugzilla.mozilla.org/show_bug.cgi?id=706970

So I guess we will need a more aggressive workaround for Firefox users.

Got the error again (same versions as last time), I rageshook: https://github.com/matrix-org/element-web-rageshakes/issues/10498

Also as @Yoric points out it also seems to be only happening when I restore a session when opening up Firefox.

Okay, good to know. Unfortunately, rageshakes don’t help too much for this issue at the moment, as all they show is:

E Unable to set language null

Let’s at least record the actual error to the logs…

For the moment though, the next time someone does see this on develop, please capture the actual missing file from the error, as I’d like to trace down why it’s been removed.

I haven’t seen it for ages. Closing. If it re-occurs please re-open. (Thanks Rich for pointing this out.)

Yeah, this is still present. I got it and pressed “send feedback”. Hope that’s equivalent to rage shaking. I tried rage shaking my laptop, but nothing happened…

Element 1.10.11 was created on April 19, so doesn’t have the most recent attempt to fix the issue

I’ve seen it happen again yesterday and today, have rageshaken ^

There’s another PR up at https://github.com/vector-im/element-web/pull/21410, please wait for that one

I see it this morning, rageshake above ^.

The location bar in my browser does not include ?updated=1.

I did clear my cache yesterday, so this is an up-to-date version of develop.element.io

I’ve seen it again just now, have rageshaken ^

Cache invalidation is not occurring if people reload Element from a url containing a question mark, and so may encounter this issue in that case. See #20033 (comment)

hopefully resolved by https://github.com/vector-im/element-web/issues/20033

Cache invalidation is not occurring if people reload Element from a url containing a question mark, and so may encounter this issue in that case. See https://github.com/vector-im/element-web/issues/20033#issuecomment-986656638

when restarting Firefox with an element.io tab in it

For the record, I’ve gotten this same issue around crashing and restarting my chromium browser, but it always seemed to happen to develop, so I chalked it up to non-prod cache settings, a refresh seemed to always fix it.

If this is still happening since Sept 10, it shouldn’t be, even on develop, so a rageshake would be useful next time it occurs

In web, on load, and refreshing made it go away (I don’t think I’ve had it happen any other way before)

Hmm, okay. 😕 At this point, I am back to not really following quite what is happening here, so I think someone else should take a look instead.

Just got this error (for the first time in a few weeks) on develop

image

After a bit of investigation, I found that our CDN treats all .json files (which includes the translations) as dynamic (uncacheable) content, so I believe that’s part of the problem here.

We’ll work on updating the cache settings, and then we can retest here.

By the way, since you’re on develop, is the typical workflow that you get the new version toast -> what’s new -> update?

Yep (though sometimes I dismiss it because it’s on top of something and refresh later which I assume has the same effect)

@babolivier @Yoric Okay, develop should now be logging at least the path and status code for these errors, so please capture again next time you see it.

By the way, since you’re on develop, is the typical workflow that you get the new version toast -> what’s new -> update?

I’m getting this almost every time I load Element Web now. For what it’s worth, it goes away with a simple refresh of the page, but it’s still pretty annoying.

Clear your browser cache.

I keep being bitten by it several times per week, so I’d be happy if we could fix this 👍

Relevant console message seems to have changed:

Using WebAssembly Olm
Unable to set language null KeyboardShortcuts.tsx:272:21
    n KeyboardShortcuts.tsx:272
    Z init.tsx:114
Skin loaded

Could we possibly init an auto-reload when we detect the issue?

This is happening for me and other people using the Riot that I host since I upgraded. The thing is, reload doesn’t help. The error message is the same. Is there a header I can set with nginx to kill the caching?

Looks like we might be eagerly deleting files which causes 404s later on. Might need a different cache strategy