This is inconsistent as https://www.whattodo.com/en/what-to-do-mote-o-events would be a Schwedisch link, not an english one. 

On our testhost (also multilanguage) the association works without any issues.

I will check on your server directly.

The multilanguage configuration on your site is not working correctly.

The language filter plugin configuration was wrong (autochange language switched to on) and you created 2 menu-items for everything already covered in the toolbar module (not necessary) and additionally 2 un-associated toolbar modules, 1 for every language.

I need some time to unravel that.

I found out what happens on your site. 

Look at that: you have two same-language menu-items both mapped to the same view but with different parent menus and different access levels. So when the Social router looks for the "one" canonical menu item for this view, it has two valid candidates and no tiebreaker beyond whatever order MySQL happens to return them in. So it's not something in our code that "picks" wrong, it's the data that gives it two right answers. 

And the same happens for all other entities across your site, for example pages:

I deactivated pages/groups/users duplicated menu items for Schwedisch and english and let the component do its work, and everything checks out (you can reactivate them and see that it will again stop to work then).

You urgently need to revise your menu structure. Like that it cannot work.

There is no error in our code, but your menu-structure/-design messed sef-url generation up by always giving multiple choices for the same. 

Remember, you don't need menu-items at all to load these views in CRE8 Social 😉

Best regards, Pascal

Have a look here for example https://young4vintage.ch/community

For 4 languages in total which associate perfectly out of the box and never error 404 I have only 1 single menu-item per language, associated in the other 3.

Nothing more is needed.

Regards, Pascal

All the view-/access-rights and the whole rest is defined in the ACL of the Social Component and doesn't need to be re-coverd through separate menu-items/-views in the Joomla menu-structure.

No, I have tested it on your site and it works as soon as you don't assign duplicate menu-items in different sub-menus for the same view in the same language. 

I must say it is an extraordinary setup but as explained, it will generate 2 different sef-urls without any indication on which should be taken when. And as it is not indicated, it falls back to the en-GB.

It has nothing to do with .ini-files being not taken (correctly) into account.

I have set it up now on your site. Please test. It works now. 

Problem is really when you assign multiple times the same view to different menus.

ACL is entirely controlled by the component itself. You don't have to do that.
Example: If your users want to create a new group, which is not visible to others, they do it themselves by chosing "Invite only group":

So you as an admin don't have to create a menu-item for that "All Groups" and then assign it the Access Level "Registered".

You don't have to fine-grain/control that as the Users do a huge part of it by themselves, in using the inbuilt ACL

I hope to have clarified that for you 😊

Best regards, Pascal

And if you as admin want to restrict group creation access for example for one category, you do that in the group category settings (Group Creation Access): 

You don't need a "Registered" menu item for this purpose.

Regards, Pascal

No, that's not the case. The toolbar module doesn't need an "associated" second module as it covers all installed languages through the 34 lang. toolbar .ini-files. There is no need to have a second instance and to restrict display via Advanced Module Manager to a certain language nor to associate in others.

The languages are handled by the joomla native language filter plugin. If that outputs /sv/ strings from the sv-SE.mod_stackideas_toolbar.ini are taken, if you have /en/ then en-GB.mod_stackideas_toolbar.ini strings are displaying.

If you then associate additionally 2 similar views in 2 different menus and with 2 different user levels, the system has too many valid options and no directive to decide which one is adequate. that means you confuse sef-url generation through such a setup, the one hit first will generate, the subsequent will 404.

To be honest: the intended purpose of a social network should be to let your users decide through their sharing-settings whether they want to show a video for everyone or to only share it with their friends. In that sense, your attempt to admin-control the general video view in the menu can contradict user settings. You can restrict video categories and fine-tune ACL there, or give certain users/profiles the ability to publish in a certain cat. or restrict that.

That said, I think the best would be to send me an email and explain in detail how you want this to work. I have the impression that you intend to override users controlling by themselves what they want to share with whom. It is not logical to restrict a public video administratively by setting a menu item to registered when the user decided to share it with everyone 🤔

As soon as I have your plan, I will help you to bring it to life. Maybe we just need the id in your setup/urls to make it work or a small tweak. 

Once I clearly understand your intention of that huge menu-setup, I'll be glad to sort it out and try to help you achieve what you want, as long as it doesn't conflict with the user acl or the main component logic.

Have a nice day.

Best regards, Pascal