As repeated multiple times in #20391, we do not approve adding the stemmers in the language packs, which makes this PR here unacceptable.

Please change we to I - you do not speak for everyone

I am not alone as you know well but let's have a joke: Never heard of "We the King" ?

I believe you mean the "Royal We" https://en.wikipedia.org/wiki/Royal_we

Specially to this part though as I switched recently to a North Indian status :

in Hindustani and other North Indian languages, the majestic plural is a common way for elder speakers to refer to themselves when addressing those younger than them.

I've now extended this PR to set the right language for tokenisation. Still waiting for the stemmer PR to be merged. That would clean up this one here a lot...

Ok, so merging the stemmer PR in here did not clean up the number of commits... ?‍♂️ But it did clean up the change-delta, so it should be pretty obvious what I'm doing here. This is ready to test and to commit. ?

I have tested this item ✅ successfully on fb32ca0

COM_FINDER_CONFIG_LANGUAGE_DEFAULT_DEFAULT_LANGUAGE="Default installed language"

In fact it is "Default Site Language" if I do not mistake.

Also (unhappily), the description does not display (grrr)
String exists:
COM_FINDER_CONFIG_LANGUAGE_DEFAULT_DESC="Set the language to be used for non-multilingual sites or content marked as \"All\". (Depends on available languages.)"
but it is not added in the field and, if I add it, it does not display.
The label is quite insufficient to understand what this parameter is about...
(If solved, I would anyway take out (Depends on available languages.) as it is quite obvious.

In any case, the field type should NOT be contentlanguage as these can be deleted on a monolanguage site, but simply language.

I have tested this item ? unsuccessfully on fb32ca0

Just because of the field type. Otherwise it works fine afaics

Changed and fixed.

I have tested this item ✅ successfully on fb32ca0

OK for me. People fighting against Tips in 4.0 should really think better.

Such a parameter does need explanations and not through a possible doc in a unique language. The description of the field should display here.

The fight isn’t against tips, full stop. The fight is against tips by
default on all the things and tips in an inaccessible manner. I don’t
think it’s too much to ask to let people figure out a solution to that
instead of retaining the status quo because it’s easy…

On Thu, Jun 21, 2018 at 8:17 AM infograf768 notifications@github.com
wrote:

I have tested this item ✅ successfully on fb32ca0
fb32ca0

OK for me. People fighting against Tips in 4.0 should really think better.

Such a parameter does need explanations and not through a possible doc in
a unique language. The description of the field should display here.

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at
issues.joomla.org/tracker/joomla-cms/20562.

—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
#20562 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoW6JF9F4iPRd7WO0m2Qlpbw8PTVuks5t-5z-gaJpZM4ULTfZ
.

--

• Michael Please pardon any errors, this message was sent from my iPhone.

@infograf768 wasn't the answer from @mbabker here: joomla-projects/gsoc17_helpscreens_on_jdocs#7 (comment) explanatory enough? Why are you keep crying over the freaking tooltips?

Why are you keep crying over the freaking tooltips?

Cool, my friend... Maybe just because nothing is done about it for the moment (that I have seen) and you proposed Note as a solution...

@Hackwar
I may have found an issue here and it is weird.
I have set the stemmer to use French on a monolanguage site. In my site is a phrase containing the word française. I can't get the suggestion. I checked that it is among the terms in db and it is.
If I set the stemmer to use English, I do get the suggestion OK, although the word is not highlighted in the result.

Stemmer set to english

result

Did not test this yet on a multingual site.

@infograf768 is not from this PR. As I comment to @Hackwar on #20384 (comment) i think is some wrong JS.

There is an issue with the stemmer setting. I'm going to fix that this evening. That it doesn't highlight the words is an issue with JS indeed. There are several issues with the JS and right now I would be happy if someone else could have a look and find solutions to those. My JS is not so strong...

Will be better open an issue, with all the JS problem you have found. In this way, others can have a look

@carlitorweb
the highlighting as well as the loss of focus on the field are indeed js related, but not the fact that a suggestion is found with English stemmer and not French stemmer. :)

@infograf768 that is true, sorry.

@Hackwar
No change versus #20562 (comment)

Ok, so I found a few issues in the code. It works right for me now. But please make sure that you re-index before testing.

What I mean is, that you have to recreate the index after you applied this patch.

OK, this time it works better. I obtain suggestions. ?

Non ascii terms (forêt, française) are not highlighted in the results as we already know. Therefore I looked a bit further.

I dumped $this->query->highlight and this is what I get.

In this specific case, I solved the issue by modifying the highlighter method in /libraries/cms/html/behavior.php

I commented line 489 to 492

		//foreach ($terms as $i => $term)
		//{
		//	$terms[$i] = JFilterOutput::stringJSSafe($term);
		//}

Therefore it looks like using JFilterOutput::stringJSSafe on non ascii creates this issue.
This is only used in the highlighter method in core.
That method loads the legacy/highligter.js. Could it be that that js does not interprete UTF8 correctly?

This issue is ALSO present in 3.x for com_finder. I guess it was never solved because the component is not much used.
The problem is NOT present when using com_search on 3.x.

@dgrammatiko

Ok, so @infograf768 you have a successfull test, right? The JS issues are not related to this PR and they are a separate issue. (Which we indeed do have to fix for 4.0)

I have tested this item ✅ successfully on fb32ca0

Needs another tester to set RTC.

I have tested this item ✅ successfully on fb32ca0

Ready to Commit after two successful tests.

@Hackwar
Any way to show the name="language_default" field only when multilang is disabled?

That field is especially necessary for non-multilang sites. So... No.Am 29.06.2018 16:14 schrieb infograf768 notifications@github.com:@Hackwar
Any way to show the name="language_default" field only when multilang is disabled?

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

That field is especially necessary for non-multilang sites.

Sure that is why I asked if we could hide it when multilang is enabled. Could not find a way.

You also need it for multilang for those texts that are marked *.Am 29.06.2018 16:34 schrieb infograf768 notifications@github.com:
That field is especially necessary for non-multilang sites.

Sure that is why I asked if we could hide it when multilang is enabled. Could not find a way.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

You also need it for multilang for those texts that are marked *

Correct. Thanks.

Looks good to me! Thanks!