* 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";
}
```
This is a workaround that shaves off some edge cases around wrongfully done camera reconnections and outbound cameras getting stuck in the UI even though they arent being shared anymore
Problem: setReconnectionTimeout was being called in the first candidate generation to set the negotiation/reconnection timeout up. That caused some browsers or specific scenarios (mainly envs without STUN) to establish the negotiation (playStart) before generating any useful out-of-band candidates (relay). That would cause the timeout to be set AFTER it is supposed to be cleared due to success (playStart), making the webcam drop after a while
So I moved the setReconnectionTimeout call to a safer spot: right after the first negotiation requisition goes out to bbb-webrtc-sfu
There's some scenarios that video errors triggers multiple toast notifications
that don't have any mapped defined message feedback so they all drop to the default
permission error. This leaves the impression that something is broken at the toast
container.
Since those messages don't bring up much information about the problem we can avoid sending
them until we don't have a more informative one to notify the user.
Moderators are able to send a message to the meeting's guest lobby. This new
event reaches bbb-web and is sent to the guest user with her/his status response
while polling. All guest users that are waiting for acceptance will be able to
read this message.
enableGuestLobbyMessage is disabled by default.
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
