A few first remarks.

the system just after the login will try to switch automatically the front end language to Italian in order to follow the user profile preference, but the redirection configured in the User Profile option will not work anymore

A bit confusing: A login redirection is done in the login menu item or the login module (i.e. redirect URL), not in the User Profile. I guess you mean the user preferred language redirection? In this case your patch does not solve this.

My test:
I did not associate the login menu items in all languages but tested with one login menu item on the Italian part of site, entering an url in the redirect.

Quite restrictive in the sense that using a login module instead of a menu item has no effect at all.

Also, the formatting of the redirect link in the menu item is quite special as it has to be something like (redirect to a Spanish item on a 7 languages site where the user default preferred language is English and general default language is French.):
http:// mydomain.tld/es/index.php?option=com_content&view=article&id=151&catid=21&Itemid=131
where the URL language code es HAS TO BE in the link.

Therefore a user which preferred site language is English logging in the Italian part of the site by this login menu item is redirected to an item in the Spanish part of the site.

It is logical as all depends on the url redirect entered in the Login menu item, not any more on the user preferred language.

Last, we get a Notice:

PHP Notice: Undefined offset: 0 in ROOT/plugins/system/languagefilter/languagefilter.php on line 560

i.e. for $active = $items[0];

Yes, sorry for the confusion, as per the screenshots and the first point of the testing instruction is the Login Redirect URL in the Option of the Login Form menu item.

The problem happens when the user do the login in a language different from the one he has set in his profile preferences. For example he configured the italian language in his profile but when he visits as a guest the website the default english language is proposed. He does not change the language before logging in, as the 90% of the users do, since he knows that the system will recall his preferred language after the login and he can easily and quickly login in any case without switching to his mother language.

During the login the system will automatically changes the front end language and try to find if there is an associated menu to the user preferred language. If the association exists the URL redirection set in the users.login.form.return variable is overwritten and the data coming from the hidden input named "return", that is set in the login form to reflect the "Login Redirect" URL configured in the menu, is lost. I think that if there is an option to decide a redirect URL, this choice has to be respected in any circumstances.
If you don't need or just don't want a redirection you can always clear the field in the menu.

I understand that you see useless and illogical to redirect someone to a spanish page when he is english, but this happen only if you hard code the language code in the url, that as you tell me should be mandatory. But I am using a different approach to redirect the users to the right page in their preferred language.
Using the Joomla Blog sample content for instance I have an home page that is set to index.php?option=com_content&view=category&layout=blog&id=9. I redirect the user to this URL after the login without any language code in the url or domain name. Apparently the routing system put the language code before processing the redirect so at the end I am redirected to the link I want in the right language.
Maybe I am missing something but I don't see why putting the language code in the url should be mandatory.

For the PHP Notice I need to check why you get this, there must be a case that generate this error that I do not have.

I understand that you see useless and illogical to redirect someone to a spanish page when he is english, but this happen only if you hard code the language code in the url, that as you tell me should be mandatory.

Apparently the routing system put the language code before processing the redirect so at the end I am redirected to the link I want in the right language.

I doubt it.

index.php?option=com_content&view=category&layout=blog&id=9

This would redirect to the item, whatever its language, with the URL Language Code of the page where the login menu item is used, if the language is not set to "All". if the item is set to a different language, 404.

In any case, the user preferred language is not used at all.

Ok, I may have solution, using part of your code (no more Notice):

Whatever the item entered as redirect url (including items set to a different language than the page on which the user logs), it would let redirect to the correct item, including when using the login module, with no possible 404 (as long as the item exists).
The resulting url will be SEF is SEF is on for the site.

Basically, if there is a redirect url (in the login menu item as well as in the login module) the solution will anyway override the user preferred site language setting.

It implies the correct formatting of the url entered for the redirect url in the login menu item: , should always be an internal url and should include &lang=xx-XX in it in non SEF although a SEF url may work but not advised if moving site.

Example: index.php?option=com_content&view=article&id=151&catid=21&lang=es-ES&Itemid=131

For the module and the logout menu item, the solution takes automatically care of the language.

Will make a PR.

Please test: #9724

Many thanks Jean-Marie for your kindly interest. I am sorry but being in a trip I am a bit slow to react.
I will check your work as soon as I can. In the meanwhile, if you found it still useful, I had published a testing site to show you how I use the auto redirect to the correct language as described in my last post.
A bientôt.

Never add pass/names in a post. Please immediately delete these from that site.
You can send me some if you like at
infografjms (at) gmail.com

I tested your site. It is not really set as a multilingual site as the content categories and articles are all set to ALL languages. This explains the results you get.
A real multingual site would have at least a root category set to each content language (if subcategories, they should also be tagged this way) and articles belonging to this category and sub categories also tagged to the same content language.
You can also have separate stuff tagged to ALL.
If a category is tagged to ALL, it may contains items tagged to different content languages and ALL.

Hi Jean-Marie. Your code is good but I still have a problem with it.
When I started trying to fix this MultiLanguage issue was just because of the problem of the Login/Logout menu becoming alternatively available for Guest and Registered users. I would not have needed any redirect if it were not to quit the user from the login menu to avoid the access error after the login. So I chose to make a redirect to the menu item pointing to my home page. So far no more error due to access violation.

I configured the respective login menu items for both languages to point to the home page in the right language and everything was fine. But now I had a new problem. If the user saved a language preference (and I wanted to let the site change language automatically based on his preference) and he did not login within the corresponding language, obviously the redirection will 404.

You solved this problem now, but we are in the illogical situation you described some posts ago, of having a user with a preferred language be transferred to a total different one.
I think your patch is anyway interesting because it adds some freedom to the admin that was not available before, but we should make everything a bit more smarter in order to let the plugin find the association if available and then redirect to the correct item and language.
We have item associations, why not using them to make Joomla choose the corresponding resource and only redirect to the hardcoded language of com_users url only as a fallback?

With my previous dirty patch I am for sure not able to avoid 404 as you can with yours, but in some way I was able to redirect a user always to the same address that was "index.php?option=com_content&view=featured", assigned every time to a menu item for every languages and let the CMS redirect correctly after the login to the user preferred language. This is not a global solution, but resolve my case scenario.

So to resume, before any patches in a MultiLanguage environment if I use a redirect I will raise 404, if I don't use it I will have error messages about the access denied trying to access the login item no more accessible and with your patch I will redirect the user to the wrong language.

In any case thank you for your precious time and help. I know how much time people who develop for the community spent and subtract to their life, because I am the first having hard time to find some spare time to trying to help.

as i said, on multilingual site, redirecting to a menu item set to all languages that would have the same url path for all content languages, is rather weird.
with my patch, you can choose the specific redirect per language. it is the admin choice to implement or not the redirect at the same time as the auto change. I will look more into your specific setting to see if it can be included in my patch (if a menu item set to All could be used as a redirection to the user preferred language when no itemId).
Now, to solve your login/logout, make the login menu item set to guests, and create a logout menu item set to registered. if that does not work, try to use the login module in conjunction with a logout menu item as it will redirect to the user preffred language in the associated page without the issue of guest.

this can be closed as we have a patch. see #9724

Closing in favor of #9724