Useful comments from the ticket this was spun out from

The only task run by this tool is defunct, so I've removed the crontab entry that generated the jsub calls.

This should be running on Kubernetes now, let me know if there are still issues

This should be running on Kubernetes now, let me know if there are still issues

This would need to be implemented as its own page because Special:Contact is already reserved for a default form. While WMF wikis don't use this default form, other wikis might, and it would be disruptive to change that behavior suddenly.

See T224059 where Stewards encountered this exact problem

Patch merged, taavi asked if this was a problem more than a year ago and no one raised anything. Closing as resolved, but re-open if there's still something to do here

It looks like the patch has been merged, are there outstanding issues or can this task be closed?

In T324064#8431192, @Reedy wrote:

Which messages are they?

@Aklapper apologies, I've been busy with EnWiki arbitration work and have missed a lot of Phab emails. I've updated two of the TODO items which are resolved; the keyboard accessibility concern is still outstanding.

Deployed, tested, resolved. I created a page and it wasn't reviewed, so everything seems to be working as intended. Thanks everyone for the teamwork!

@Kipod the change was intentional. The final board state isn't any more helpful than the starting position, and the cases where it could be are better served by ply= or <fen></fen>. If an article is talking about the middle game, showing the checkmate position is not any more helpful than the starting position. If a reader isn't going to interact with it, then it's always going to be noise unless an editor sets the ply= parameter. In situations where that doesn't happen, defaulting to the start of the game is generally better. Chess games go forward, so having the game start at the beginning saves readers from having to click back to the beginning. The final board position might be a useful default for game fragments, but having editors specify the most useful ply is better than having a default that encourages them to cut the ends off of games.

Yes there were two issues. Around move 20 there was a period and unmatched close-brace that were messing with the validation. Those were fixed, but the remaining problem is nested variations. This is partly a UI/UX issue touched on at T239440.

1. Displaying nested variations inline is not user friendly and makes the game hard to read. It should be avoided if possible, and the hierarchical nature of the variations conveyed visually (and structurally in the HTML for accessibility)
2. The problem of navigating to and from the variation is amplified. As it is, readers cannot navigate to moves within a variation because we don't have an interface for moving in and out of these lines other than clicking on them. With nested variations this is still a problem that will need resolved.

I think I managed to isolate the problems in the test PGN and can confirm the issues @TheDJ pointed out in T284034. Additionally there were also some errors in the PGN that I identified using lichess.org and fixed, but all the other parts with NAGs render fine so I'm going to close this as resolved.

@Juan90264 I just submitted a patch, but don't have +2 on that branch so I'd need someone to merge and deploy if everything checks out

Thanks @matmarex for clearing this up for me and for the additional example (I had only seen Score and Math). I can confirm that your solution works. Updating the documentation would be very helpful to avoid this confusion. I've update the task to that effect.

Thanks for letting us know about this! It should be fixed soon, and please file more bug reports if other messages can be improved

Oh I see now why this wasn't closed. Hmm, I'll need to look into the example further, but I'm not sure the problem is NAGs, or at least not them specifically. I think there's some interaction between them and all the comments and variations that's causing some problems. I'll look into the example and create a subtask when I figure out what the issue is

@TheDJ I think this was really two tickets in one. The first issue was valid PGN triggering errors with no obvious cause, and that was largely resolved by fixing the PGN validation and moving some try-catch blocks around. The second issue, still unresolved I think, is that the user-facing error reporting isn't very useful. I'm not sure how to fix that; I'd imagine it would involve a literal PGN linter in order to check for and provide various syntax warnings and errors. That feels too ambitious for where we're at in development.

After some more searching and code examples, I'm getting the bare bones of VE support. Will be documenting the process on mediawiki to try and consolidate whatever information I find

In T284034#7332510, @Kipod wrote:

@Wugapodes : can you see why 3rd game in https://en.wikipedia.beta.wmflabs.org/wiki/User:%D7%A7%D7%99%D7%A4%D7%95%D7%93%D7%A0%D7%97%D7%A91/ChessBrowser_test_cases still fails to parse?
i copied it from one of the test cases in the repo.

In T239446#7326415, @TheDJ wrote:

• The playboard announces the legend, but without a sensible order and it ignores the pieces (turn whole thing into a table?)

In T289800#7319625, @TheDJ wrote:

And what about the game details, the steps and the table ? what should their directionality be ?

The two column format is used by both lichess.org (which this is based on) and chess.com, and it's the predominant format for chess score sheets in over the board play. I'm not opposed to you consulting communities if you'd like, but almost everyone who's played chess will have seen this format before.

@TheDJ Objects on the board are positioned using classes which define rows and columns. When the language is RTL, the CSS seems to index the "left" attribute from the right. This should explain why the pieces and labels are flipped because both of those are on the grid. Feel free to assign this to yourself if you'd like to handle it. The problematic classes are .pgn-pfile-n in modules/ext.chessViewer.css

You can see an example of the redesign in the attached screenshot

Fixed by gerrit patch 705193

One idea I had was some something similar to the bad image list but specifically for templates. A file used in the most recent vandalism has a very legitimate purpose on multiple articles and templates, and so adding it to the BIL would cause a lot of problems. Similarly, adding it to the AbuseFilter would be a lot of overhead for each edit and as it scales up would just duplicate the BIL. Having a by-namespace restricted image list, we could prevent the addition of particular images to templates without impacting the ability to add those templates to proper pages. It's not a perfect solution to the original task, but it does succeed in reducing the attack surface caused by templates.