1093667 - Display hint, that search is case sensitive

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: Search, defect)

Description

[André Jaenisch]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36

Steps to reproduce:

I was looking for Node.insertBefore and entered insertbefore into the search.
Yields https://developer.mozilla.org/de/search?q=insertbefore


Actual results:

The result (Node.insertBefore) wasn't shown.


Expected results:

Case insensitive results should have been shown as well or, alternatively, a hint should be placed somewhere, that some results maybe weren't displayed due to case sensitivity of search engine.

Compare above result page with https://developer.mozilla.org/de/search?q=insertBefore

Comment 1

[Māris Fogels [:mars] (please needinfo)]

Sheppy and I can confirm this. :jezdez may know what's happening.

Is this by design?

Comment 2

[Eric Shepherd [:sheppy]]

I hope this isn't by design, because requiring case-sensitive matches is going to really hamper good search results. It also explains many things about past search results I've seen. :)

Comment 3

[Jannis Leidel [:jezdez]]

This is an interesting combination of things,

1) Since the OP searched on the German locale the search scoring takes it into account. It ranks all documents not in that language a tiny bit lower which means that English-only documents like the Node.insertBefore() are ranked lower. This is intended to make sure that the relatively small number of translated documents get enough attention in the search results.

2) As a result of 1) you'll find the Node.insertBefore() document on the 2nd search result page as the first item (for me, at the date of this comment, https://developer.mozilla.org/de/search?q=insertbefore&page=2).

3) The document https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/insertbefore is ranked highest because it's an exact match for the search query, also intended behaviour.

4) Looking at the English results (https://developer.mozilla.org/en-US/search?q=insertbefore) you'll see that the Node.insertBefore() page is ranked higher because it misses the negative boost from 1). Again the Tech/XUL/Attribute/insertbefore document is on result position 1 due to an exact match.

To answer the actual question, no the search is not case sensitive, but it's content sensitive and looks at various data to do the scoring. That includes (I may miss something) the following with the amount of how much it affects a base score of 1.0:

- the title: 1.2
- an exact match in the title: 6.0
- an exact match in the summary: 2.0
- an exact match in the content: 1.0 (no-op basically, I think we changed that post-launch)
- an exact phrase match in the title: 10.0
- an exact phrase match in the content: 6.0
- if the document is a zone: 8.0
- if the document is a first level document: 4.0
- any document not with the current requests language: -0.5

All of these conditions are used when calculating the score for each document in the search result.

Comment 4

[Māris Fogels [:mars] (please needinfo)]

Given that the algorithm is working as-designed, I'm bumping this down to minor.

Comment 5

[Geoff Lankow (:darktrojan)]

I was searching for window.matchMedia and discovered that this page

> https://developer.mozilla.org/en-US/search?q=matchmedia

returns 2 results, but this one

> https://developer.mozilla.org/en-US/search?q=matchMedia

has 2332. So I think this is a pretty big problem.

Comment 6

[Peter Bengtsson [:peterbe]]

Geoff's comment is basically the same as mine:

https://developer.mozilla.org/en-US/search?q=scrollintoview
vs
https://developer.mozilla.org/en-US/search?q=scrollIntoView

I think it's a mistake to be case sensitive. What search engine is case sensitive these days?

To be honest, I didn't read Jannis's comments #3 above because I think it's moot. Case should not matter. Especially in a new era of mobile where the keyboards often make it hard to type in anything but "Titlized".

Comment 7

[BMO Automation]

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.