I was shown a case just now where `CreateNewPresentationPodEvtMsg` can happen prior to the full add of a meeting. This log line becomes relevant once again
Disabled `'Backend meeting queue had not been initialized'` which was added to pinpoint an issue with handling of meeting create events, but the issue seems to be unrelated (and has not been hit after resolving a memory leak)
* moving locales folder to /public and applying changes needed to serve locales as static files
* better dev/prod check
* transifex pull script changes to match new locales directory + ignore locales with less than 100 lines
* fix local/prod locales path
* merge fallback messages
* applies new locale changes to legacy client
`bbb-html5.nginx` file content should also be changed to the following:
```
location /html5client/locales {
alias /usr/share/meteor/bundle/programs/web.browser/app/locales;
}
location /html5client/compatibility {
alias /usr/share/meteor/bundle/programs/web.browser/app/compatibility;
}
location /html5client/resources {
alias /usr/share/meteor/bundle/programs/web.browser/app/resources;
}
location /html5client/svgs {
alias /usr/share/meteor/bundle/programs/web.browser/app/svgs;
}
location /html5client/fonts {
alias /usr/share/meteor/bundle/programs/web.browser/app/fonts;
}
location /html5client {
# proxy_pass http://127.0.0.1:4100; # use for development
proxy_pass http://poolhtml5servers; # use for production
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
}
```
It is safer to look at subscriptions's state to users instead of depending
on the initial state of the collection at mounting time. Although
i couldn't force any race conditions on this, there's a chance it could
happen. The fix avoid this problem.
This complements #11533
When validating tokens, the dummyUser created at the beginning is set
with validated=true. This means there won't be the state change that used
to occur from validated:false to validated:true (which detects the moment
joined the meeting) , therefore the alert code that expects for this change
won't run.
To fix this for audio alerts, we now detect when user join by observing
additions in Users's collection. This is actually good because we start
observing this only once (in componentDidMount), differently we used to do,
by calling this every time the tracker was activated.
To distinguish between the user addition that initially populates user's
collection from those that happens after user join (which are the ones we
want), we store the initial state (at componentDidMount) and compare it
with new additions. If the user added is present at the initial state,
then it is an addition to populates the collection, otherwise this is a real
user addition (happened after user joined the meeting)
Partially fixes#11399
Locales would be fetched even if you simply open and save settings window (without changing any setting)
We now test it similarly we do on 2.2
Closes#11318
