@mollekopf Ready for the final review.

• Add wording for the invitation email

Fix

• Don't process csv if any email address is invalid
• Cleanup

Configurable token expiry, minor test adjustments

• Small css improvements to the page menu

• Store user language in a cookie, always load English
• Small code cleanup
• Update tests
• Small linting fixes
• Browser test for the language selector

Looks good in general.

• Rebase
• Improve language selector
• Store UI localization in php file
• Remove unused Laravel localization files

Rebase

Just code review. I didn't look closer to this yet.

I think all tests that pass for me on master pass here, but not all tests pass for me. I'll investigate this further, but feel free to point out failing tests.

I don't like that output format. How did you get to the problem? Maybe you should use Carbon objects instead.

• Use ALTER TABLE .. MODIFY

Instead of CHANGE you could also just use MODIFY I think (since we're not renaming columns):

For your consideration; this seems like a simple approach: https://stackoverflow.com/questions/58239220/inject-build-timestamp-into-vue-cli-build-output-files-to-verify-deployments-wit

• Fix tests
• Small color improvements

Of course I wan't to implement this only for the roundcubemail login page when it starts to work... not for every kolab service.
I looked into http_authentication and krb_authentication plugins but cannot figure out howto replace the "standard" login page.
I think that the http_authentication is what I want but I'm not sure.
Sadly I could not find any example or documentation how to do that.

• Manu localization
• FAQ localization

• Hide the lang selector if there's only a single language available

• Upgrade to laravel-mix v6 (webpack v5) and other js dependencies
• Don't preload English
• Localization engine for theme files
• Rebase
• Improve language selector

• Don't use app.company.name in copyright footer

Close in favor of D2476

The main cause for the issue is the chat element that uses width: 30%, which causes the screen to be split not evenly (sometimes with 0.5px difference). offsetWidth is always rounded up to full pixels. So, when you divide that (0.5px bigger than in reality) width by the number of columns the sum of widthts of the participant boxes will be bigger than the real width of the container.

I couldn't find any references to any rounding going on. Given that the values are all in pixels (right?) I would be interested to what these values are rounded to (for my understanding, you can ship it if it works).

Could it be that the problem is not the precision but that offsetWidth does not take any transformations into account? See https://developer.mozilla.org/en-US/docs/Web/API/CSS_Object_Model/Determining_the_dimensions_of_elements