If it helps, so far with testing this the cases where I'm not on the first page of results and it works an offset value is sent in the payload, and where it fails the offset value is missing

In T411843#11447480, @Samwilson wrote:

That sounds like a bug. Surely we don't want it showing if the feature flag is off?

(have assumed that given the "Labels" toolbar item appears regardless of the feature flag being enabled that the help button linking to Special:WatchlistLabels is fine appearing too)

Current patch:

• sets wgEnableWatchlistLabels as default false for prod (no change from config var's default
• sets wgEnableWatchlistLabels as true for enwiki on the beta cluster

At the moment, I have just the label names being returned via

$wl = [];
foreach ( $labels as $label ) {
    $wl[] = $label->getName();
}

giving:

{
  "batchcomplete": true,
  "query": {
    "userinfo": {
      "id": 1,
      "name": "Admin",
      "watchlistlabels": [
        "fox",
        "label1",
        "label2",
        "label3",
        "label4"
      ]
    }
  },

coincides with my backport for https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/1196061 finishing, but that change is unrelated..

In T401575#11075781, @JWheeler-WMF wrote:

@TheresNoTime this looks good. Ideally in the target article/page we are also able to track any of the links on the row. That way, we can identify not only the CTR, but the CTR on certain elements of the page.

Is this doable? I think the spec as defined only tracks the diff or article links.

(will just grab this for now while I work on it :D)

Some quick poking at this found another "non-Vue" hacky way of dealing with this :3

T388567: "[Vue warn]: Attempting to mutate prop "inputValue". Props are readonly." when using NamespacesControl seems related

In T397861#10964875, @Andrew wrote:

In T397861#10962913, @TheresNoTime wrote:

• the concerns raised here suggest that it does increase NFS load, though perhaps not to a disruptive level, given how 'infrequently' new torrents would need to be generated?

Bursts are the main concern here, and it sounds like you're describing something bursty! Is this something with a throttle you can configure?

In T392827#10963790, @TheresNoTime wrote:

nb. from Slack: also query how many users have 5+ favourite templates

nb. from Slack: also query how many users have 5+ favourite templates

Thanks for the comments @Andrew

Will happen this Thursday once 1.45.0-wmf.8 is stable on all projects

In T396556#10907511, @Samwilson wrote:

I think it might be when a template is redirected but also is categorised, e.g. Template:CN:

#REDIRECT [[Template:Citation needed]]
[[Category:Template shortcuts]]

I think the fix might be in DataStore.getItemData(), where we look for the returned data with if ( responses[ 0 ].pages[ pageId ] !== undefined ) …

It should actually be looking instead for the *first* (well, and only) returned page (and also then returning the ID of that page, which will be different in the case of redirects).

Quick question (which very much could be from my own misunderstanding) — I tested the patch and found that language variants were being included:

Same here (in Chrome fwiw)

Is there a better way of setting an explicit title on tabs?

In T396556#10907511, @Samwilson wrote:

I think it might be when a template is redirected but also is categorised

hm, info doesn't have templatedata for some of these templates, but most (all?) of the required info is available in categories — I can't replicate this locally on the same commit/latest commit...