But it should be possible to set it to false to make it simpler for users of smaller wikis who probably don't need this feature.

This is what I have strong reservations about. One of the big problems we have with MediaWiki is the proliferation of feature flags and how much complexity that adds for testing and code maintenance. Unless small wikis really need to be able to turn this off then we should get rid of the flag

Re-opening, because feature flags are basically tech debt. Can we run this by the MW stakeholders group?

I don't know - @tstarling do you know?

I meant inside the select - so like this

In T368423#11389014, @bmartinezcalvo wrote:

Either "results" or "items" could work, but in order to be aligned with the Table's pagination, the "results" word should be included within the Select, not outside.

Ok ... so is it ok to change the message to "X results" for all codex table pagination everywhere? Or maybe "X results per page"?

@bmartinezcalvo I see that in the dropdown for results per page you have "X results" rather than "X rows" which is what's in Codex right now. I think that makes sense (or maybe something like this image below)

Actually now I think of it - we also don't know where we are in the resultset (we kinda do for search, but it's hacky), so we can't even say "Showing results 250-300 of many"

I guess we can add it if/when we know it, and not otherwise? @tstarling thoughts?

That number for search results is kind of a weird one - it shows you the total number of results, but you can't actually page through them all (you can only get the first 10k) - here's an example. Maybe that doesn't matter, because it's v unlikely anyone will page that far? If it doesn't then I guess we can show the total

@bmartinezcalvo right now we don't display "Showing results 1–10 of 999,999" and we can't commit to doing this in general - for search we retrieve a maximum of 10k results, and for database queries they're structured (for efficiency) in such a way that it's not possible to know the size of the resultset the user is paging through

We already have pager/CodexTablePager.php ... could we extract getNavigationBar() (and some of its associated methods) out into a trait, and then try deleting getNavigationBar() from other Pager classes and useing the trait instead?

Will adding the the Commons sitemap to robots.txt mean that other search engines will also pick it up? duckduckgo seems not to have many File pages indexed, for example - commons site image search for "dog" on duckduckgo compared to google

@GPSLeo @Jmabel I just want to make sure of something ... right now {{Permission_pending}} gets transcluded under "Licensing" - is the intention that whichever license the user choose will also get transcluded?

Nope! That's just how I read the designs, probably got it wrong - let's just do it however we normally do it.

Nice work @tstarling !

Like more-or-less everything on the wikis the page size defaults to 50, but you can change it (standard values are 20, 50, 100, 500 iirc)

Oops yeah, not a story, just a subtask of T406214

Here's a draft

Deployment of the full feature is scheduled for Monday Nov 3 at 2pm UTC https://wikitech.wikimedia.org/wiki/Deployments#Monday,_November_3

Also fyi we did some work on figuring out the relationship between the size of the labelled data set and precision@25 which suggested that you don't need a great deal of labelled data to get a fairly accurate search, see T280368

Yeah, it was for images though. The tool is here https://media-search-signal-test.toolforge.org/

@tstarling just want to make sure I understand - the main argument for "copy" instead of "cross-join" is to build the label into the indices to make filtering faster, is that correct?

Just one other thing to consider here - we have a wish to allow people to add a note when they're adding something to a watchlist. No need for it to be searchable or anything, just a note that gets displayed as part of the row in Special:Watchlist

Another approach could be - you could mark users as "trusted", and edits by trusted users do not show up in your watchlist. I think this gets around the concerns around stalking, and still makes the watchlist more usable for vandalism detection? Especially once T404391 is implemented

Do we need a ticket for the A/B test?

@dom_walden I've seen behaviour like this when I was writing the code, but I don't seem to be able to reproduce it now on beta

@Ladsgroup the train hasn't rolled yet I don't think