I’m testing jitsi-meet-torture with a Jitsi instance which has german configured as default language:
// Default language for the user interface.
and in interface_config.js:
LANG_DETECTION: true, // Allow i18n to detect the system language
With these settings I get many errors like:
org.openqa.selenium.NoSuchElementException: No element found for:[aria-label="More actions"]
For documentation on this error, please visit: https://www.seleniumhq.org/exceptions/no_such_element.html
I found the workaround to revert commit feat: Forces en-us as chrome language. · jitsi/jitsi-meet-torture@6274e4c · GitHub which resolves these errors.
Is there a better way to make torture work with a non-english Jitsi instance?
All the tests are written to find elements in English, if you revert that commit things would fail, wouldn’t they?
I don’t fully understand what the commit changes; but as a matter of fact reverting the commit works for me; language related test errors are gone.
When looking into the issue just now I found an interesting behaviour (the Jitsi Meet instance: https://treffen.vtirol.gv.at; my system language and browser language is english):
- non-incognito mode (all browser data cleared): Jitsi Meet is displayed in english
- incognito mode: Jitsi Meet is displayed in german (initially shown in english, then quickly changed to german)
- both in private and non-private mode: Jitsi Meet is displayed in english
So what I see is: the default language from config.js is not applied, only when connecting from Chrome incognito mode or when using Jitsi Torture.
When is the default-language applied? Maybe it is overridden by browser-language detection, which maybe has no effect in incognito mode and torture?
Once you have loaded a default language, that is stored in localstorage till you change it in local storage on client change, any change in default language on backend will not take affect to those already load the previous default.
Incognito and torture start with clean profile for every new session.
I have cleared local storage for Chrome and Firefox; still it does not apply the configured defaultLanguage. Same with Firefox private mode.
Do you see it being applied in the local storage?
How are you cleaning it, while being in the page? If you open the page and clear it from there, sometimes it stores what’s in the memory of the page on close, overriding.
I tried different methods:
- Clearing local storage from DevTools when page is shown
- Clearing all browser data while page is closed
Edit: In method 1. I saw that local storage is emptied until next reload.
I think this is because LANG_DETECTION: true from interface_config, kicks in before the default language. If you disable that and clear again, it should work.
Yes that’s true. When setting LANG_DETECTION: false, all browsers display Jitsi Meet in german, regardless of the configured browser language.
Inversely, when setting browser language ‘de’, LANG_DETECTION: true and no defaultLanguage in config.js, all browsers display Jitse Meet in german.
So coming back to my first post, there seems to be case, with LANGUAGE_DETECTION: true, defaultLanguage: ‘de’, where language selection from commit feat: Forces en-us as chrome language. · jitsi/jitsi-meet-torture@6274e4c · GitHub doesn’t work and jitsi torture does not override the default language and/or browser language detection does not kick in. Does that make sense?
Coming back to that topic (probably lost in the backlog): Do you consider the observed behaviour (see above) a bug? Should I open a issue in GitHub for Jitsi Meet?
This is in jitsi-meet-torture, probably the code should force LANGUAGE_DETECTION to true and default language to be en. You can open an issue there and any PRs are welcome.