This issue was also raised in #5204 which I closed as other aspects of it have already been addressed by #5340

I forgot to put labels to this... Can someone please fix? Sorry and thanks!

@smanzi Can you try commenting out line 247 in plugins/finder/content/content.php (it should be the line that says $item->setLanguage();), then re-index. Does that cure the problem for articles?

If yes, then I'll need to make a similar change in other parts of the code, so I'll submit a PR and you can test it more thoroughly.

ehmmm.. 247 is a blank line, maybe you mean 246?? $item->setLanguage();

sorry seen...
ok trying

Sorry, yes, I need new glasses.

Actually, you might need to do a purge before re-indexing.

seems to work!!!!

That's great new for me, Chris...

Chris, I can't understand how you did it (the flow of this thing is overwhelming for me), but I want to confirm you also this:

Before in com_finder "Content map", under "Language" I had just 2 branches: en-GB and it-IT. Now I have 3: "All" is there too.

BTW, can someone explain the reason of the message that is displayed by the "Language" branch: Note: Language filter system plugin has been enabled, so this branch will not be used.? It doesn't seems to be true... we have evidence that it is used!

Thanks again, Chris! great job: with your 2 PRs and the ones by @dgt41 for suggestions "Smart Search" seems to be ready for prime time...

It's coming back to me now. The consequence of having "All" as a possible language in Smart Search is the effect it has on the language filter drop-down on the search forms. Because, you'll get "All" listed there too. But searching for "All" languages doesn't do what it sounds like it should. That's why it was disabled in the first release of Smart Search. We need to think about how to deal with that.

I had proposed a patch which was not good enough:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=33725

I'd like to re-activate the language filters that were disabled when we first migrated Finder into core. But for testing it's important to know what the correct, expected behaviour should be.

Suppose I have a site with 3 articles set up as follows:

• Article-All is an article with language set to "All" (that is, "*").
• Article-English is an article with language set to "en-GB".
• Article-Italian is an article with language set to "it-IT".

In the language drop-down in the search form (it will be under Advanced Search but you won't see it at the moment because it's disabled), you will see 3 options:

• Search All (this is the default)
• en-GB
• it-IT

Note that there is no "All" ("*") option in the drop-down because it's meaning is ambiguous and it probably isn't going to be useful to the average user.

Then, regardless of what language the site visitor is currently using:

• Selecting en-GB will give the results: Article-All and Article-English.
• Selecting it-IT will give the results: Article-All and Article-Italian.

However, selecting "Search All" (which is the default anyway) will give different results depending on the site visitor's current language:

• If the site visitor is using en-GB then the results will be: Article-All and Article-English.
• If the site visitor is using it-IT then the results will be: Article-All and Article-Italian.

Is that right? If so, then I'll put together a PR that provides that behaviour.

Beware:
Let's say you want to enable search per lang, whatever it is;
2 content languages as you define above:
If we are in it-IT and search for items tagged to en-GB, the results of the search should provide correct urls (which are lang dependent).
If you search for items set to language ALL and an item is in a category which is itself set to en-GB, what would happen?
Also, should be reminded that aliases/titles can be the same if present in 2 different content languages.

I knew there was a reason we disabled this functionality, it gets really complicated really fast! I think the way forward is to define exactly what the correct behaviour should be so we can test possible solutions. Then, if we can't figure out how to make it work, we'll just leave cross-language searching disabled (but we can still fix the issue reported by @smanzi ).

So, for the first scenario, if the site visitor is in it-IT and searches for items tagged en-GB then the link in the search results should be the same as if the site visitor was in en-GB. In other words, the item should have a URL which is the same regardless of the site visitor's language. Is that right?

For the second scenario, you won't be able to search for items set to language All because I'll remove that option from the drop-down. You can only search for a specific language, or not specify a language at all (which is the default). If you don't specify a language then the search results will depend on the site visitor's current language.

I think the category language is probably irrelevant when searching.

• If you have a category language set to All which contains an article set to en-GB then a search for en-GB should find it, but a search for it-IT should not.
• If you have a category language set to en-GB which contains an article set to All then a search for either en-GB or it-IT should find it.
• If you have a category language set to en-GB which contains an article set to it-IT then a search for it-IT should find it, but a search for en-GB should not.

Does that make sense?

We'll also have to include a post-update message because anyone using Smart Search will need to do a purge and re-index for any of this stuff to work properly. And therein lies another problem. If they have any search filters set up then at the moment that can only be done from CLI otherwise they will lose the filter definitions. Anyway, let's take it one step at a time and we'll cross that bridge when we come to it.

@chrisdavenport and @infograf768
I think that historically (If this can help) the introduction of this bug/feature can be tracked down to commit 49dc8c5 by elinw (old tracker number 29824) whose description is "Smart search saves * in language field".

At this time I don't see "Language" being proposed as a search criteria, nor in the back-end (Search Filters), nor in the front-end (Advanced search), and this even after applying Chris's patch (actually I did something different and more radical: I gelded the FinderIndexerResult::setLanguage() function by adding a return; at the very beginning of it). Unless you're talking about the possibility of using, as a search criteria, a category that is flagged for the wrong language...

In which cases and where do you see "Language" being proposed as a search criteria?

In any cases I 100% agree with Chris about what should be the behavior (his "Does that make sense?" question...)

In case, instead, that a "Language" criteria is introduced and it does returns results also for "other" languages, JM's warning about consistency of the language code returned in URLs must be taken into account (absoloutely!), but I'm wondering if (by any chance) this his not automatically resolved by recent @Hackwar modifications to the language filter and the router.

That is indeed fixed if the ContentHelperRoute class is properly used. Let me take a look.

In general, I agree that searching for all, should return all languages. Searching for a specific language should show that language and the "*" language.

@chrisdavenport
after reading your comment a second time (and after a second good cup of coffee), I now understand that the two things, searching also far "all" (that does fix my issue) and introducing cross-language searches, are two separate concerns.

For me it would be enough to have the first concern addressed: I see the two (or three, or four...) "site languages" as different and separate sites, each with his content. But this is just an opinion and a very personal point of view...

Ok, I looked through this and it seems as if this is in part fixed by changing line 424 of /administrator/components/com_finder/helpers/indexer/result.php to read the following:

    public function setLanguage()
    {
        if ($this->language == '')
        {
            $this->language = $this->defaultLanguage;
        }
    }

As @infograf768 correctly stated, this fix failed earlier, since line 270 of /plugins/finder/content/content.php did not correctly apply the language to the ContentHelperRoute class. However, with the change that I introduced a few months ago that fixed this, it should work now. That at least properly indexes the content. The search query also does search properly already for the current language and "*", too, but for searching for other languages, there might be further issues. I didn't look further for now.

@infograf768 will you do the PR or should I?

I confirm that @Hackwar patch is working.
To whomever will do the PR: can we get rid of the Note: Language filter system plugin has been enabled, so this branch will not be used. message? Does it have any sense that I'm missing?

I would prepare a PR, but that message would have to be fixed separately.

See #5364

I would prepare a PR, but that message would have to be fixed separately.

I can do that if there is a consensus that the message is actually wrong/misleading... opinions?

Can we leave this open as a "starting point" in case @chrisdavenport decides to introduce cross-language searches?

Cross-language searching is a separate issue. When I first commented about it above, I'd forgotten that it had been disabled in Smart Search (it was a feature in Finder, but it can't have worked properly). I'll open a new issue/PR when I have that done.

The bug originally reported is entirely down to us not allowing "*" as a language code and has been fixed in #5364 . The message on the content map screen should stay because that basically explains that cross-language searching won't work. The Language taxonomy branch is only there to support cross-language searches, regular searches don't use the taxonomy branches anyway.

Thanks @chrisdavenport
Closing as we have a solution for this in #5364