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.

The latest patch set implements very rudimentary variation and comment display. The JS doesn't yet handle the display of variation board states, and even if it did, it's not clear how to handle the branches with the < and > buttons. Regardless, I still need to fix the tests now that it's somewhat stable so that the builds succeed, and then will submit for review. Further refinement can be done in later patches, and I'll write more about my ideas in the coming days.

I've looked into this and there seem to be three main problems

1. The validation regex doesn't (yet) allow variations and comments because
2. The codebase doesn't (yet) translate the PHP parser's comment notation into something the JS module can read, but even if it could
3. The given example uses numerical annotation glyphs (NAGs; see the standard) which are, in my experience, uncommon in the unicode era. I'm not sure the parser understands NAGs, and even if it did, I'm wondering whether we should support them at all.

I still need to look into a lot of what @Kipod suggested, but it looks like the button images are already implemented in CSS. This means that users and wikis can override them as they want using their local CSS pages, and I've tested that on the beta cluster. I also added documentation on the extension page on how users can do that.

The process for hooking an extension into VE looks to be documented at this MediaWiki page alongside the API documentation

This seems to be a result of slow javascript loading. The HTML loads before the JS module giving a flash of unstyled content to the user. Any solution will need to keep in mind T239446. As for how to fix this, I think redesigning the plaintext fallback would be best. Currently the underlying HTML is the fallback text seen, and the JS modifies it. A better method might be to have a failed JS load throw an error that we catch at the end and then add the fallback text so that it doesn't get displayed if the JS is loading slowly.

Thanks @Aklapper! I think the icon does a good job of indicating what the button does (and it looks good too!). A slider is also a nice idea as it sidesteps some of the icon choice issues. Fitting it into the UI might take a bit of reorganization to make visually appealing. My first idea was something like below where the play button and slider were below the board and the next, last, etc buttons were between the board and move list.

First, @Kipod I believe I merged the change since @ori had other changes that depended on it with the understanding that we could easily revert it if need be. But yes I agree with Ori that consolidating discussion here would have saved a lot of headaches.

Thanks for your work on this @ori! I opened the link on my phone and it did not work well. I think mobile behavior (see T239446) is among the stuff to fix before spreading the news.

This sounds like the best long-term solution. How should we coordinate moving forward with the first stages of refactoring?

I use FlaggedRevs on enWiki and would like to see it retained as a protection option, so I plan to lend a hand to make that happen. I won't be able to fix much of the high-level stuff, but hopefully working on some of the smaller tasks will free up more experienced developers for the critical tasks.