Page MenuHomePhabricator

Search keywords (e.g. insource, intitle) should be case insensitive
Closed, ResolvedPublicFeature

Description

Feature summary
MediaWiki search allows keywords like insource: and intitle: however these are case sensitive - intitle:banana returns pages that contain the word "banana" in the title, however Intitle:banana returns pages that have the words "intitle", "intles", or "intitled", etc anywhere in the page text and everything after the colon is apparently ignored. This should be changed so that either the whole keyword or at least the first character is case insensitive.

Use case(s) and benefits
Mobile phones frequently autocapitalise the first letter of an input and it can be fiddly to change, frustrating that you need to remember to do that and a waste of time (and potentially data) if you don't know or forget.

See also
Original request at enwiki, which contains more examples: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(idea_lab)#insource_and_similar_search_terms_allowed_to_be_capitalized?

Details

Related Changes in Gerrit:

Event Timeline

The main search input has indeed set autocapitalize="sentences" which explains the behaviour on mobile devices.

Change #1227365 had a related patch set uploaded (by Peter Fischer; author: Peter Fischer):

[mediawiki/core@master] Special:Search: Disable autocapitalize

https://gerrit.wikimedia.org/r/1227365

Change #1227365 merged by jenkins-bot:

[mediawiki/core@master] Special:Search: Disable autocapitalize

https://gerrit.wikimedia.org/r/1227365

pfischer claimed this task.

Thanks for flagging this. This turned out to be a mobile input issue rather than search parsing.

On some wikis, the search input had autocapitalize="sentence", which causes mobile keyboards to capitalize the first character. That makes operators like insource: awkward to use, since Insource: is treated as plain text.

This has now been fixed by setting autocapitalize="none" on the search input, so mobile keyboards no longer auto-capitalize and search operators can be entered as intended. The change is live.

If you still run into cases where operators behave inconsistently, please report them separately.

This isn't actually resolved - the task intentionally asks for the keywords to be be case insensitive, not just for mobile input to stop autocapitalising. Although the issue is reduced now on mobile, there is no good reason (that I know of or has been articulated) for the keywords to be case sensitive, and there is no indication at the point of use that the keywords are case sensitive.

@Thryduulf, thanks for following up — you’re right that search operators themselves remain case sensitive.

We addressed the concrete usability issue that triggered this report, but after reviewing the broader request, we don’t plan to change the parsing rules for search operators. These keywords are part of a defined query syntax, and making them case-insensitive would be a semantic change with wider implications for predictability and compatibility.

We understand that this may not fully address the original use case you described. With the input issue resolved, however, we consider this task complete from the Search team’s perspective. If there are separate, concrete cases where operators behave unexpectedly, please feel free to file them individually.

Thanks for taking the time to raise this and for the discussion.