So, the first question I asked myself is: what are the topics we should be using? This is already answered in the AC: we want to use the same list that Growth is using. That's consistent with recommendations in T368422#10104429 (and other comments in the same task). As I mentioned in my previous comment (T362259#10333981), as well as in the task description, the list used by Growth is https://www.mediawiki.org/wiki/MediaWiki:NewcomerTopicsOres.json.

Now waiting for the patch above to reach production (wmf.5, next train) before we can remove the flag from WMF config.

The relevant component is HTMLTimezoneField in MediaWiki core, which is also used by Special:Preferences.

Discussed 2024-11-21: this is no longer a priority, and will be reconsidered as part of T318412.

The CampaignEvents extension already uses Codex in a few places.

In T380135#10341483, @hashar wrote:

So that is the subject of Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030335 , the reporter complains they can't use pip install -e. The proposed fix was to add a patch to the Debian package which implemented --break-system-packages option https://salsa.debian.org/python-team/packages/python-pip/-/commit/68673ebd85db676cded1fc8a8f34f46bfc4e14d4 . The patch has been upstreamed to pip with pip 23.0.1 / pip 23.1.

In T362639#10341627, @vaughnwalters wrote:

One question though @Daimona and @ifried , when I do not specify my timezone, it shows in preferences that it should default to the wiki default, in this case UTC. But then with this patch we have it overriding that to display event timezone in the browser default. Just checking to make sure this is correct behavior and if we should make some sort of note in the https://meta.wikimedia.org/wiki/Special:Preferences#mw-prefsection-rendering that the default behavior for timezone offset will not apply to the Campaign Events?

@hashar Thank you for the detailed explanation, as always :) I had read a bit about the reason behind the debian package being marked as externally managed, and I think they're sensible. I was looking for a quick way to get it up and working, without messing with my python installation. As I mentioned in the task description, pipx seems to work nicely, and it's essentially just a wrapper for virtualenvs. To me that's ideal because it allows me to keep a single python version, not mess up with system packages, and the only thing I need to remember is to add "x" after "pip". Obviously this is partly motivated by the fact that I don't need python for many other things; else I probably would have taken the pyenv route.

Discussed 2024-11-20: we think that the technical difficulty is too high, while the product value is low/medium importance, at least for now.

@ifried What should the field label and placeholder be? They're not specified in the AC, and I see them in the various designs only. Also, specifically about the design in the task description, can we avoid the parenthetical plural?

Fixed now, as verified in https://test.wikipedia.org/wiki/Event:T347608 and https://test.wikipedia.org/wiki/Special:EventDetails/1.

In T379294#10337024, @Aklapper wrote:

Thanks! That's T380288: Uncaught Wikimedia\Rdbms\DBQueryError: "Table 'testwiki.ce_event_wikis' doesn't exist" on event pages and CampaignEvents special pages, for the papertrail.

In T367226#10336809, @gonyeahialam wrote:

In T367226#10336404, @Daimona wrote:

The current implementation is based on OOUI's MenuTagMultiselect. Based on what we've seen for wikis, this is the only field we have available for dropdown-based multiselection.

Does it have the feature where as you type the dropdown list updates?

In T379294#10334944, @Aklapper wrote:

Is that an intentional and ignorable side effect as we proceed with the train (as the task description has "Create the table everywhere" not yet checked)?

In T367226#10336135, @gonyeahialam wrote:

@Daimona What type of input field is being implemented for this, I want to see if it is useful for topics?

Update: the MR above fixes the buster-backports issue. The next issue is that these images are buster-based and are using sury-php, but buster packages have been dropped from sury on July 1st, when buster became EOL. See for example T369146 for quibble images. So, we'd have to migrate to bookworm-based images (or bullseye if we really have to, but since this is for development environments only, it might be better to just do the big jump now while at it).

A couple random thoughts from a quick look at this:

• GrowthExperiments seems to source topics from a static list: https://www.mediawiki.org/wiki/MediaWiki:NewcomerTopicsOres.json. Even before looking at GE, I thought that we should do the same, as it helps with performance, and removes risks such as a topic being removed (then what do we do with events using it) or liftwing not being reachable.
• GrowthExperiments has messages for topic names (growthexperiments-homepage-suggestededits-topic-name-*), example. It would be nice to reuse these somehow, to avoid having translators translate the same things twice. I'm not sure how doable this would be for now though (need to move messages to another repo, make sure that topic keys remain consistent, and that it's fine to reuse the same message in both places).

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)?

Set $wgCampaignEventsEnableEventWikis = true; in LocalSettings.php to test this.

In T379276#10322606, @Daimona wrote:

Can't be tested directly, hence resolving.

I really wish I didn't have to spend a whole sunday afternoon figuring this out and unbreaking our official development environment that's been broken for 8 months now. But such is life sometimes, and at least I learned something along the way.

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?

Ah, there's also the following error in the browser console:

Uncaught RangeError: Maximum call stack size exceeded
    at String.replace (<anonymous>)
    at find (jquery.js:939:26)
    at find.matchesSelector (jquery.js:1444:9)
    at jQuery.filter (jquery.js:2795:22)
    at winnow (jquery.js:2784:16)
    at jQuery.fn.init.is (jquery.js:2834:12)
    at keypress (jquery.suggestions.js:427:46)
    at HTMLInputElement.eval (jquery.suggestions.js:739:7)
    at HTMLInputElement.dispatch (jquery.js:5145:27)
    at elemData.handle (jquery.js:4949:28)

Thank you for looking into this!

Caused by r1086560, I believe.

In T375412#10324614, @vaughnwalters wrote:

The icon does now appear and is functioning correctly, but I am wondering if this size of icon should be smaller still to match the size of the same icon that is in wikidata?