This would be quite hard given the limitations explained in the subtask, and it isn't so valuable

I try to understand why case insensitive search would be such a large problem? E.g. all WikiMedia applications, including Wikidata, support "ignorecase" search?

In T312229#10326548, @Geertivp wrote:

I try to understand why case insensitive search would be such a large problem? E.g. all WikiMedia applications, including Wikidata, support "ignorecase" search?

I assume you're talking about Special:Search. In Wikimedia wikis, Special:Search is backed by Elasticsearch via the CirrusSearch extension. However, the search on Special:AllEvents and MyEvents is backed by the MariaDB database directly. MediaWiki stores all strings as binary (for reasons that I don't fully grasp; presumably to avoid dealing with encodings), and for a raw binary string there's no concept of character case. To achieve case-insensitive searches with the current layout, we would have to convert all event names to lowercase, and doing so requires converting the string to a non-binary type first. The problem is that MediaWiki doesn't support any of that, and the feature request in the subtask (T310558) was declined.

This leaves us with more complex options such as separately storing a lowercased version of the event name to use for case-insensitive searches. It's not a large problem, but it's not trivial either. We would have to make a schema change, apply it in production, backfill values for the existing events and generally go through the schema migration process. It's doable, but not as easy as a small code change.

Sorry to insist; is there any technical or operational reason why Special:MyEvents and Special:AllEvents (that are part of MediaWiki) can't use the general CirrusSearch and Elasticsearch logic, that is used to index lemmas (article names) and article Wiki text (article content)? As a user I don't see the difference between an article title and an event title. As I understand it, Elasticsearch is used for all namespaces, but not for the Event namespace?

In T312229#10329035, @Geertivp wrote:

Sorry to insist; is there any technical or operational reason why Special:MyEvents and Special:AllEvents (that are part of MediaWiki) can't use the general CirrusSearch and Elasticsearch logic, that is used to index lemmas (article names) and article Wiki text (article content)?

We haven't looked into this, or considered this option. It might be feasible, but I would not expect it to be easy -- in fact, it would likely be a major change. As a case in point, Elasticsearch support in Wikibase is provided by WikibaseCirrusSearch, which is a separate extension.

It would likely be much easier to do something like I wrote above where we separately store a lowercased version of the event name for case-insensitive searches.

As a user I don't see the difference between an article title and an event title. As I understand it, Elasticsearch is used for all namespaces, but not for the Event namespace?

This is not correct. You can search event pages using the normal Special:Search frontend, which uses Elasticsearch and provides all the things we're used to like case-insensitivity and search operators (example). The thing is, when using the search field on Special:AllEvents / Special:MyEvents you're not simply searching event pages: you're searching events with registration enabled, and with additional metadata that you can also use in your search query (e.g., "in-person events in November 2024"). These entities are associated with, but are not the same as, event pages, and cannot be searched via elasticsearch.

I advocate for this being an important thing to fix. Today I was very confused about why I couldn't find many results for "call", and I had started to draft a request for people to add all the other regional calls until I stumbled upon an example of a "Call" that already had an event, whereupon I realized this was a bug, and there are actually many "Call" events already listed.

I kinda agree, it's just not an easy fix as it might appear at first glance, because we would need an abstraction that doesn't exist and for which the feature request (T310558, subtask) was declined. It's still doable, but requires some database changes. Perhaps also a good time to reconsider whether we need an event_name column in addition to the event page title (and to the canonicalized version for search proposed in this task).

As an urgent workaround, please add a search-label "Case sensitive search keyword" instead of just "Search keyword"-- this way users will be aware of the bug/restriction. Now users don't find events, but they are not aware why. Just adding to the label "Case sensitive" is peanuts, and costs nothing.

In T312229#11929040, @Geertivp wrote:

As an urgent workaround, please add a search-label "Case sensitive search keyword" instead of just "Search keyword"-- this way users will be aware of the bug/restriction. Now users don't find events, but they are not aware why. Just adding to the label "Case sensitive" is peanuts, and costs nothing.

I think this makes sense. @ifried @JFernandez-WMF thoughts on the copy to use here? (Also, note that we're talking about two different fields, one in Special:MyEvents, another in Special:AllEvents)

@Daimona, I agree that the workaround makes sense. In terms of placement, it would be replace "Search keyword" in Special:AllEvents and "Search" in Special:MyEvents? If yes, then perhaps:

• Search keyword (case sensitive)
• Search (case sensitive)

In T312229#11938689, @ifried wrote:

@Daimona, I agree that the workaround makes sense. In terms of placement, it would be replace "Search keyword" in Special:AllEvents and "Search" in Special:MyEvents? If yes, then perhaps:

• Search keyword (case sensitive)
• Search (case sensitive)

Thank you, makes sense to me! On second thought, that's probably better as a separate task that we can quickly get done. --> T426797

Yup, sounds good. Thanks! Great ticket for the small items backlog.