Thanks for your patience @Anujagrawal, I didn't have much time to volunteer last week.

The chessViewer module was written in ES5, so the linter is set up for ES5 not ES6. See [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/ChessBrowser/+/refs/heads/master/.eslintrc.json | line 4 of .eslintrc.json ]]

I left some comments on the patch. Fixing those comments should resolve the current test failures.

In T370482#10009449, @Anujagrawal wrote:

should i also add sinon sandbox and jquery?

Yes, that's a good idea. I forgot it wasn't listed as a dependency in the extension. You can use npm install qunit --save-dev

I've uploaded a patch which should mostly resolve this task. A comparison of the Original and New style are given in the file below. Some notes:

• Width: currently not full width because it made my math easier, but presumably it could be? I think this is better chosen on a case-by-case basis since what Wikipedia needs might not be what Wikibooks needs, for example. So I'm not too worried about defining the width out-of-the-box
• Board and Notation: the notation is now in two-column format and the board is to the left and equal height. The two-column notation format makes it easier to display comments and variations, aligns with reader experiences on other sites like Lichess and Chess.com, and limits the amount of information displayed to readers who are not interested in the specific moves or comments.
• Narrow view: doesn't work yet, but that's high priority since mobile devices are so popular for content
• Comments: Appear as a break in the notation, and have a border whose color indicates which player the comment applies to.
• Variants: I have ideas for this based on Lichess but not yet implemented. Medium priority since variants are an important feature.
• Raw PGN Download: not implemented and low priority. Workaround is to just view page source and copy the text.
• Colors: I made them up based on EnWiki's template scheme. I think they're good enough, but I'm open to other ideas.

Thank you for tagging this task with good first task for Wikimedia newcomers!

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.