As per dloeng@atlassian.com comments, the issues relating to stemming and the use of wildcards were fixed in 5.2 when we moved to using KStem with the limitation that wildcards on the end of a full word will not match the root of the word. So authentication* will not match authenticate. However authent* and authenticate* will be stemmed and match authentication, authenticator, authenticate and this addresses the original ticket and most of the comments.

If there are other issues with search these are probably best addressed in a separate ticket to this one.

"Case sensitivity in wildcard searches" was apparently fixed in 5.2 (CONF-20115)

+1

We've recently started with Confluence and I have users complaining about this.

e.g. If you search for "repos" you get results for pages with "repository", whereas "reposi" returns nothing at all. From reading the above I suspect it is because "repos" is being treated as a valid word, whereas "reposi" is not. Very confusing.

A large number of the issues in this ticket are caused by our choice of an overly aggressive stemming algorithm in versions of Confluence prior to 5.2.

Examples of porter stemming (used peior to 5.2):

management ----> manag
authenticator --> authent

managemen* won't find anything because:

• there are no terms that managemen* will expand to (if it was man* then it can expand to the word manag, but that's not the case)
• lucene, by design, does not stem query terms that contain a wildcard. That is, management* won't stem to manag* – see here

Confluence version 5.2 and onwards

The issue raised here is still possible but less likely. I encourage all watchers of this ticket to upgrade to 5.2 or later and provide us with any new feedback.

As of 5.2, Confluence uses KStem instead of Porter.

Examples of KStem:

management ----> management
authenticator --> authenticate

KStem is far less aggressive and importantly, it doesn't stem down to word roots but valid english words (like authenticate).

This means that blizzard's query for authenticat* will succeed as it will be expanded to authenticate. However, authentication* still won't work. I admit the results are confusing for this query still. But there's a question mark in my mind how realistic and common that query is. It doesn't make sense to wildcard a full word.

Making the search more compliant to user expectations should really be highest prior ity. It's an integral part of every confluence instance.

2 more issues with wildcards:
1) ? and * do not match white spaces, so for example "this?word" will not match to "this word". Neither does "this*word" match.
2) ? does not match any character with an ascii value of > 127. The reason apparently is that UTF-8 codes these characters internally with 2 or even 4 characters. This affects french/spanish/... accents, German Umlaute, and many more characters.
For example, Bär is found by B??r but not by B?r as you might expect.
From a user's perspective, he should not worry about the internal representation. a ? should match one visible character, what-ever the internal code is.

I've confirmed a another issue with wildcard.

If you use wildcard in your search, the search becomes case-sensitive. i.e.
the result for "C?nfluence" and "c?nfluence" are not the same.

Han

Piotr,

Although in this case your comment is applicable to confluence you are probably talking about jira. Confluence also has the same setting for indexing language.

Anatoli.

I've similar problem.

Go to Administration | Global settings | edit configuration
Try to change Jira indexing language from "english" to "other". And repeat you tests.

Here is some description with screens : http://www.atlassian.com/software/jira/docs/v3.13/configure.html

I've search it for a while, and it is probably connected with Lucene search mechanism which has some special searching functions when searching in English language, but not necessary great when you need exact results with wild cards characters.

In my testing, the word "commit" is a great example:

1. "commit" (no wildcard) matches the literal word "commit" as well as the variations.
2. The search term "commits" (no wildcard) returns all variations on "commit" and the same number of resutls
3. "commit*" matches the literal word "commit" as well as the variations.
4. The search term "commits*" returns a single match for the literal "commits".

So: stemming works, reverse stemming works, stemming with a wildcard works, reverse stemming with a wildcard doesn't.