PFP copyright Luis García, CC-By-SA 3
Feb 7 2022
@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.
Dec 16 2021
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!
Dec 9 2021
@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.
- 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)
- 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.
Dec 5 2021
@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
Oct 25 2021
Oct 3 2021
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.
Oct 2 2021
Sep 28 2021
Thanks for letting us know about this! It should be fixed soon, and please file more bug reports if other messages can be improved
Sep 27 2021
Sep 26 2021
Sep 22 2021
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.
Sep 21 2021
Sep 20 2021
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
Sep 9 2021
Sep 8 2021
Sep 3 2021
Sep 1 2021
Aug 31 2021
Aug 30 2021
Aug 29 2021
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
Aug 21 2021
You can see an example of the redesign in the attached screenshot
Fixed by gerrit patch 705193
Aug 16 2021
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.
Aug 3 2021
Aug 2 2021
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.
Aug 1 2021
Jul 26 2021
Jul 19 2021
I've looked into this and there seem to be three main problems
- The validation regex doesn't (yet) allow variations and comments because
- The codebase doesn't (yet) translate the PHP parser's comment notation into something the JS module can read, but even if it could
- 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.
Jul 18 2021
May 27 2021
May 16 2021
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.The slider might need labeled so that viewers don't confuse it with something like a timeline.
May 13 2021
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.
May 12 2021
Mar 17 2021
This sounds like the best long-term solution. How should we coordinate moving forward with the first stages of refactoring?
Mar 16 2021
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.
Seems related to the request at T218090
Possibly related to T275181?
@Majavah I can't find documentation for Special:Stabilization, and it doesn't seem to exist on enwiki or mediawiki. On what wiki are you encountering this error? What specific steps do I need to take to reproduce the error?
Main issue of the task is resolved, will open new ticket with the additional request
Having action=parse return something other than the most recent revision is a bad idea. There might be value in creating a flag that allows the user to signal their preference for stable revisions like parsestable=true, but I agree with Aklapper that this should not be the default behavior.