Just before the headline System Information

Then configure the browser to have German as the preferred language to display pages.

Insert here: Quit and restart the browser

Again note which URLs work and which do not.

Regarding the setting to remove the language code you misunderstood something: The setting does not mean the language code is removed from URLs for ALL languages. That would technically not be possible. It only removes the language code from URLs of the site‘s default language. So your expected result is wrong. I am pretty sure the inline help or the help docs clearly tell that.

This is the expected behaviour when you have configured the plugin to remove the language prefix. If you think of the slash DE being invisible but still present that will explain why directly typing the URL without the language will produce a 404 for the language that is not your default.

In your case the site default language is German, the German URLs have no language code and the English URLs still have it, and that’s how it is intended to work.

@richard67 Why German lang is different here?

System settings > Server > Languages

• Default ( based on $SERV_LANG )
• Default ( based on geoloc )
• Append manually

@richard67 Why German lang is different here?

Because it is set in the site languages as the default language in backend. If that is changed to English, then the English language prefix would be removed from the URLs, and the German one would remain.

See the online help for the "System - Language Filter" plugin's settings here: https://help.joomla.org/proxy?keyref=Chunk4x:Extensions_Plugin_Manager_Edit_System_Group/en#System_-_Language_Filter

Remove URL Language Code. Whether to remove or not the defined URL Language Code (eg. your_domain_name/en) of your Content Language that corresponds to the default site language when SEF URL is set to "Yes".

Note the "your Content Language that corresponds to the default site language".

What's not clear with that?

Closing as expected behaviour. See previous comments for explanation. Feel free to re-open this issue if you think this is wrong, but in this case you should provide additional information on what does not work as described in our documentation.

The mentioned configuration is the configuration which is set up right now, for someone to guess what is going wrong.

I tried all kinds of combining the settings to find a configuration to have both links accessing a contact page:

https://bogenparadies.de/contact -> English contact page
https://bogenparadies.de/kontakt -> German contact page

AND

have a assossiation between the German and the English contact page

Same thing with

https://bogenparadies.de/hilfe -> German help article
https://bogenparadies.de/help -> English help article

again both pages having an assossiation.

I did NOT find any way that works.

Each language has to be accessible since I have no way to predict which language link is used by visitors and I have no way to predict what settings the visitor is using in his browser.

I did NOT find any documatation, nor did I get any help on forum.joomla.org

Please guide me to the documentation on how to set up Joomla that these two core features work together.

Thank you

You expect something which is not possible, joomla can't map a menu entry in one language to an other language menu entry without knowing the language of the menu entry language.

If you want to do this then you can use the redirect component to redirect the /en/hilfe to /de/hilfe

I reopen it for now but it's not a bug but expected behavior because joomla can't guess whats url maps to which menu entry.

joomla can't map a menu entry in one language to an other language menu entry without knowing the language of the menu entry language.

Just add another lang var as a URL param. Thats it.

Joomla can't guess whats url maps to which menu entry.

Ever heard of URL mapping?

How should this work?

Think about if you have 10 languages and half of them uses help for hilfe what would you expect happens then?

Thanks for reopening.

@ wojtekxtx: I do not understand your comment. Can you please give links to read what you are talking about?

To clarify the problem

I changed the settings for system/language filter plugin. Now the settings are:

x-default Language: German (DE)
Remove URL Language Code: No

Steps to reproduce the issue

1 Set browser settings to prefer English content.
2 Clear all browser cache (content and cookies)
3 Follow this link https://bogenparadies.de/hilfe
4 Follow this link https://bogenparadies.de/de/hilfe

Expected result

See the help page of the site. Preferable in English (because of the browser setting), or if there is no English version of the help page, see the German help page of the site (because that is what the link is pointing at).

Actual result

See a 404 Error page.

Additional comments

It seems to me, that the system/language filter (like its name might suggest) simply blocks all content which does have a different language setting than the state of the plugin.

This would be an incorrect behavior, because the browser settings say: English should be preferred and not that only English should be displayed.

The expected behavior would be, if an assosiated English version of the URL exists: Show the English version (this is what the browser setting wants). If no English version is assosiated with the URL, show the German article.

And we did not jet talk about multiple prefered languages in a specific order in the end users browser settings.

Also. when the URL is given without language code, the corresponding article should be displayed. That means when the URL path part matches the alias of the Menu-Item the article can be found and displayed (maybe through a redirect).

If it is possible to obtain the expected results by configuration, all the better

Just someone tell how to achieve or where to read.

Thanks alot

There is no way to achieve what you describe and I know of no other web application that will do that.

As @HLeithner explained already you need to think it through a bit more and then you will understand why not.

As @HLeithner, @brianteeman and @richard67 wrote, what you are expecting is not possible. You are expecting the system to automatically detect a language, which might even work in a hand-made system for your specific site, but not for a framework like Joomla. You are making it easy for yourself by using the example "help" and "hilfe" since those are simply different words. But replace that with product names, for example "iphone". How should Joomla know which language to select if you use domain.tld/iphone? That could be any language actually. So when you enable the languagefilter plugin, you have to either select a language as default for prefix-less URLs or all URLs will have prefixes. And most importantly: If a URL doesn't have a language prefix, Joomla will try to deduce the right language by either the browser configuration or (if set) by a cookie/session value from a previous visit. So, yes, if you visited the site in german and then use a prefix-less URL with an english alias, you will get a 404.

Since this is expected behavior and we all 4 have told you the same thing, I'm going to close this issue again.

Sorry, it took some time to get a new environment and a clean Joomla! J4 installation runnung.

@Hackwar I have to disagree with you. I do NOT expect Jommla! to automatically detect the language of a keyword. However, I do expect Joomla! to respect the browser settings and use the preferred language if the end user has configured it.

Further, I do not do anything "easy" for me. Rather, I carefully choose terms that are different in the languages but still short and concise. The terms "hilfe" and "help" are just examples to explain the problem in a comprehensible way.

Furthermore, it is not about providing all key words in multiple languages, but only those explicitly configured as such. The assignment is simple! It is done via the alias and the language setting of the corresponding component (menu or article).

I understand that fixing this issue is not a simple matter, as it is not a typo in a program file. Rather, to fix it a general rework of the routing component is needed.

As I explained earlier, the routing engine must interpret the path from the URL as an alias, then check if the language setting of the component matches the language preferences of the browser. Then, in case of doubt, it would have to check if the corresponding article has an association with an article in the language requested by the end user and output it. Of course, a filter that simply filters out everything is easier to implement.

Furthermore, there are examples that a corresponding solution is feasible. On the website https://debian.org are several internal links e.g. People, Why Debian, Our Philosophy ... which all honor the browser settings perfectly and transparently for the end user.

Last but not least, it is questionable to store such a setting in a cookie without first asking the end user for permission. This may make sense for a user who has registered on the website and in the course of this accepts the use of cookies. For anonymous guest visitors, this is legally questionable and often even prohibited.

To round everything off, I have found a workaround that can get around most of the problems. I will write a corresponding tutorial on docs.joomla.org.

So it seems the great workaround doesn't work, at least that's how I understand this issue: #39151 .

I was not talking about a GREAT workaround.

I wrote that I found a workaround that can get around MOST of the problems.

And Yes the workaround discovered more problems.

But I do not want to start arguing. I am just following the call to the Joomla! community to help the development by finding and reporting problems.

Last but not least, it is questionable to store such a setting in a cookie without first asking the end user for permission. This may make sense for a user who has registered on the website and in the course of this accepts the use of cookies. For anonymous guest visitors, this is legally questionable and often even prohibited.

it is absolutely legitimate and legal to use a cookie for this purpose. just because it is called a cookie does not make it illegal.

Interesting, this comment is not in the issue, but in the GitHub protocol only.

Yes it is not illegal to use a cookie for that, but it is (in some countries illegal to use such cookies without informing the user.

I think a future way could be that there is an option which disables any cookies for access by users in the group public. Actually I see no reason that cookies are needed when just surfing the content without interaction.

I think a future way could be that there is an option which disables any cookies for access by users in the group public. Actually I see no reason that cookies are needed when just surfing the content without interaction.

per default we don't have a language cookie anymore

Yes it is not illegal to use a cookie for that, but it is (in some countries illegal to use such cookies without informing the user.

within the gdpr you have to inform the user anyway about the session cookie, adding the language cookie as technical cookie isn't much extra effort. (only valid for countries and companies implementing this rule).

One thing which could be possible is to extend the redirect component to support browser language but for this we need a proper concept which is technical possible and with a user interface that's understandable and maintainable (for the user).

a user interface that's understandable and maintainable (for the user).

@HLeithner You do not need proper UI for user cookie ( cookie message in form of banner is not considered to be proper form of UI ).

Besides, its highly not desireable that user ( other than admin ) have any way of modifying elements of UI.

a user interface that's understandable and maintainable (for the user).

You do not need proper UI for user cookie ( cookie message in form of banner is not considered to be proper form of UI ).

Besides, its highly not desireable that user ( other than admin ) have any way of modifying elements of UI.

??? I think you missed the point
We have a language cookie switch in the backend and I'm not talking about the user chaning any elements.
The user in this case is the site owner or integrator.

@HLeithner they're just trolling - none of their comments on any issue are remotely relevant

@brianteeman you dont have clue how wrong youy are. All my comments are relevant. Whats not, however, is your mindset, which clearly proves you (as well as most others with powers in this project) are power hungry, attention seeking, people.

@RichardZimmerEschborn the nice thing about joomla is, that you can replace almost anything with your own code. Especially the router provides at least 5 different mechanisms how to override it's behavior, starting with your own router class, custom rules to be registered in the router, custom component routers to replace the current ones and custom rules for the core component routers. Joomla will not provide the behavior you are requesting, but you do have the possibility to implement it for your site yourself.

@wojtekxtx personal attacts are not what we want to accept here, so I use my power to give you a 7 day break.