@test success
Thanks to @chrisdavenport, @infograf768 and @Hackwar !

Travis crying: there seems to be issues with the test results

fixed

For testers: You have to re-index the content to see the articles!

Tested successfully, thank you @Hackwar!

2 tests -> RTC

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5364.

@Kubik-Rubik You're right... and as @infograf768 (if I remember correctly) said, we should (at least in theory...) advise end-users about the fact. Can be a notice in the "release notes"/announcement be enough?

fixed.

@Hackwar @smanzi @chrisdavenport @Kubik-Rubik can you please test #5099 to get finder in good shape for 3.4? Thanks

@dgt41: will surely do. I'm going out now, but count on that!

@test Success. Thanks @Hackwar

There are no B/C issues. All sites will continue to behave as before when this patch is applied. To get the corrected behaviour users will need to purge and re-index their sites.

Tested this in multilanguage site where the search plugin is displayed on all pages for all content languages.
Test Instructions:
Create an article set to All languages in a Category set to one of the content languages (in my test site, that category (Poètes français, child of ROOT category Catégorie en français) is tagged to fr-FR. Other content languages include it-IT.)

Then display any page tagged to it-IT and search for the title of that article:
The article is found allright, but look at the link:

Link is: http://localhost:8888/testwindows/trunkgitnew/it/7-catégories-en-français/poètes-français/189-articlepourall-dans-poetes-français.html

i.e. including the lang prefix /it/

Now click on the article title: the article will display:

Look at the breacrumb.

1. This is the url obtained when hovering on the Catégories en français Parent category link. i.e. : http://localhost:8888/testwindows/trunkgitnew/it/inizio/9-catégories-en-français.html Clicking on it gives:

Useless to say that clicking on these categories title links give weird results:
Poètes français (link is http://localhost:8888/testwindows/trunkgitnew/it/inizio/7-catégories-en-français/poètes-français.html displays:

the others display( for example link is http://localhost:8888/testwindows/trunkgitnew/it/inizio/11-catégories-en-français/joomla-multilangue.html :

1. The url obtained for the article category Poètes français is http://localhost:8888/testwindows/trunkgitnew/it/inizio/9-catégories-en-français/poètes-français.html and gives

===>Therefore, the patch only works when looking for an article tagged to All, in a category itself tagged to All and parent category tagged to All. Otherwise, we may not get 404 but weird results using parents.

This is partially an issue of the user and partially an issue of our routing. Unfortunately, I don't see a way to fix that.

@infograf768 I'm not sure I understand and I'm unable to replicate...

I have 3 categories:

• Uncategorized (All)
• English Articles (en-GB)
• Articoli in Italiano (it-IT)

In each category I have 8 articles (all have been set to the language corresponding to the containing category). There are no associations between articles.

I have published "Smart Search Module " in all pages (it is set for language = "All")

Whatever "side" of the site I'm in, searching for a common word returns 16 articles: 8 for current language + 8 for All

Each returned URL is of the kind: /language_code/category/article and I don't see any wrong URL. Same goes for breadcrumbs: home page -> category -> article

I also get the same results from com_finder component ("Search" menu item)

Now I did something more... "extreme":

I created another category "Mixed articles" (language = All) and moved 4 articles from each of the above mentioned categories to this latter category. So "Mixed articles" contains:

• 4 articles for language = "All"
• 4 articles for language = "en-GB"
• 4 articles for language = "it-IT"

Same results as above: 16 articles returned per search with correct URLs and Breadcrumbs

... one more (unrelated) thing: I added menu entries for "List all categories" to both my languages menus and each of the two has been set for the corresponding language. Now, if I go to that menu item, I get the following (this is for English, but the same happens for Italiano):

I had expected:

• to not see the "Articoli in italiano" category listed (I'm in English and category flagged as Italian)
• to have 8 articles counted for "Mixed Articles" and not 12 (as matter of fact only 8 are displayed if i click on that category...)

Is this considered normal behavior or is this an issue I should open?

@smanzi

In each category I have 8 articles (all have been set to the language corresponding to the containing category)

These are NOT the conditions of my test. Please read again.

@infograf768 You're right: I didn't got the meaning of your comment. Now I think I have and I prepared a simplified but exhaustive set-up:

• 3 categories: one assigned to each language (counting "All" as a language)
• 3 articles in each category: one assigned to each language (counting "All" as a language)

This gives all the combination of 3 languages in 3 categories. I didn't create 2nd level (child) categories as you did, but I think is irrelevant. If you think that instead it is, I'll modify my set-up.

• For each search I get 6 articles as result (expected)
• In each category I can "see" two articles at the time: the one for the "current" language and the one for "All" (expected)
• Language code in URLs is always the one of the current language (expected)
• URLs and Breadcrumbs are "well formed"
• Displaying an article that has been put in a "wrong" category and clicking the category name in breadcrumbs brings to the list of articles in that category satisfying the current language criterion, i.e. 2 articles. (expected)

In other words it seems that Joomla! (as it is now) doesn't give crap about to which language categories are associated. In any case the correct articles are always displayed and I don't see how this can generate 404...

As stated above, anyway I think there is an error in the count of articles when listing all categories: the count says 3, while it should say 2 (and in fact, as stated above, only 2 are displayd):

P.S.: Of course this also means that for each article assigned to the "All" language we can have 2 valid URLs, like, e.g.:

• /en/8-articoli-in-italiano/226-all-in-italiano
• /it/8-articoli-in-italiano/226-all-in-italiano

differing only for the language code

But I think this is OK: pages will anyway look different and will probably have different associated modules.

... and after a second (and third) thought, I think it is OK the way it is now: only "current language" and "item language" must be the discriminating factors: taking into account the language associated to anything in between (i.e. containers, i.e. categories) will only complicate things and lead to unexpected results.

If the above is correct, assigning languages to categories doesn't make any sense and its possibility should be removed.

Edit: I think my first consideration is correct, but as @infograf768 correctly explained here below "language tagging" of categories is essential for the possibility to create associations and use the language switcher

Sorry, I am lost... Categories should have language tags and should be able to be associated. The fact that we have issues when using finder/smart search is not a sufficient reason for taking off that functionnality. Most multilingual sites anyway do NOT use finder, but com_search.

For what reason categories should have an associated language (when then you can put items of a different language inside them)? I don't see any reason... can you explain why you think this is important?

ah... OK, for association: right! That's correct...

But this is just an "operational" thing... in fact assigning a language to a category does not limit what you can put inside it.

Because we can use the switcher to display associated categories AND keep the good urls when site set correctly.
The real issue is that we can add items not correctly tagged to the same language as the one used by the category (its parent and siblings), not the fact that the categories can be tagged.

Forget the finder... there is no problem with the finder... It is an "ab initio" thing (and maybe we are OT here now...)

Yes, as I said you're right about the association (and hence switcher) thing: so I was wrong and we MUST maintain "language tagging" of categories, but I don't see a problem in the behavior you first described as problematic...

Merging now. Thanks for testing