Hello,

We've not yet upgraded to the latest build, but reading this makes me think it would be looking for trouble.

We have a lot of users that are using browsers set to French but have their webmail in English, because if they try to change it, it will reject the language change because of folder names conflicts.

So basically they stay with webmail in english. Will that mean they'll then always have this toaster showing ?

That's a bit out of topic but not that much: with 15k mailbox, we still haven't found a solution to batch switch the users to their native language without having to deal with this conflicting folder name issues.

I also would like to mention that being admin of multiple mail systems, incl. Exchange, SmarterMail is the only system complaining about folder names when you try to change the webmail language, and it's a pain.

I don't really understand why other systems can handle this interface language change without any issue

On the other systems The "special" folders Inbox, Drafts, Sent, are handled gracefully whatever the webmail or client language is.

AFAIK most mail servers keep these folder names in english and the clients (including webmail) should identify the special folders using the SPECIAL-USE flag attached to the folders.

Then the client display these special folder names according to their selected client language (the client is doing the translation).

If someone has a solution to batch fix this for all users without having to manually handle each mailbox... I would love to hear it :)

Kind regards

@Sébastien Riccio : I completely agree with you...

Many users have noted that date and time input fields aren't formatted according to the language they have specified in SmarterMail. This is because the formatting of those fields is entirely handled by the browser and there is no way for SmarterMail to modify the formatting based to match the user's saved language.

In the past several months, we have received several support tickets regarding this behavior. This toast was added in an effort to reduce the number of those tickets by warning users ahead of time of the potential issue. It seems that when we were deciding on how to implement the toast, we underestimated the number of users that would be impacted by it.

With that in mind, we will be modifying the toast to work more like the warning toast about browser notifications. Specifically, we will be adding a Dismiss button to the toast. Clicking the X on the toast will dismiss the toast until the user's next session, and clicking the Dismiss button will dismiss the toast until they change to another device or browser, or they clear their cached data.