Extension:ChessBrowser/PGN schema

Description of standard

PHP parser

 * Proof of concept parser should be converted to it's own class.
 * Existing "else if" blocks can be made into sub parsers.
 * Import format for parser deviates from 8.2.1. The standard implies that moves can be directly adjacent, e.g. Re5Qd6Kc3. Import format for this parser requires at least one space between adjacent symbol tokens.

Developer notes

 * PHP should take import format and deliver export format.
 * JavaScript can be simplified by only accepting export format PGN. As the JavaScript is delivered by the extension, it should only take input that the PHP places on the page.
 * Parsing output can probably be done token by token without regexes
 * If extension is later expanded to resolve T239438, additional PHP function can take the export format and translate data for JavaScript

HTML
The html for the display is currently built by the front-end (javascript), and somewhat controlled by the "config", e.g., if the config stipulates "delay", front end does not display "faster/slower" buttons.

Discuss:


 * Should the back-end (php) provide the html?
 * Is the current html produced by the script good UX?
 * Is it possible to get UX feedback?

CSS
ideally, it should be project override-able, and provided by the extension.

JavaScript parser
Written by Kipod, but will need modified as heavy parsing is moved to PHP. Parsing in JS may eventually be made obsolete (See T239438).

RFC: Proposal for export format from server to front-end script
This is loosely based on the artifacts generated by calling "analyzePgn" on the javascript viewer. server-side of extension will create an element,  or some other element, with (at least) one data attribute called "config". The content of this attribute is a stringified JSON used to pass parameters to the client-side part. This config will be passed directly from a similar attribute in the invocation of the the extension, e.g.

The php can pass a second data attribute, containing configuration parameters produced by the server-side of the extension (i.e., not passed directly from the wikicode) The content of this div is a json structure, either an array or a single instance of something like so: So, the pieces provide enough data to draw each piece, i.e., type and color.

The "board", i.e. one entry of the "boards" array, is somewhat like a FEN, but not really: if a square is occupied by pawn #3, and let say pawn #3 happens to be entry 19 in "pieces", then the corresponding "piece" for this pawn will not say merely "I Am A Pawn" (indistinguishable from any other pawn of same color), but instead it will say "I Am Piece #19", i.e., an individual pawn, not a generic one. think of this string as "FEN on steroids" - carries a bit more information, but still maintain the same "run-length- encoding for empty squares, and one character per piece. we can refine it a bit, such as not using line breaks at all, and describe a single long line of 64 entries. Of course, this is but one option. the important thing is that each "board" will carry enough information to know which pieces (indexes in the "pieces" array) are in the game, and which square each of them occupies. Annotations are self-explained. As an alternative to annotations-data-as-json, drawn by the script, the server can generate the whole "annotations" html directly.

This makes the "game machinery" extremely simple: there is pretty much on 12-line function that is told " By using consistent individual pieces, very little logic is required to draw the board (tell all the pieces in this board to be in their intended places, and all those which are not in this board, to hide. this logic is identical or similar to existing script).

multiple-game support is available in the original javascript viewer. If this is to be implemented by the extension, the json can contain an array of "games" instead of a single game

Note: Full pgn standard allows foc "comments" interspersed among the notation. Current javascript does not supports nesting, and does not support alternatives (i.e., the user can not see the actual positions for algebraic notations in comments). This limitation is mainly because of the parsing. If the php-based pgn parser supports nesting and alternatives, it should be fairly straightforward to augment the data structure, and write a contract which will make it fairly easy for the front-end to show alternatives too.

i18n
The server can preload the different strings used by the front-end as mw.messages entries.

This will allow projects to stuff the translations "manually" for languages whose translations are not yet integrated with the extension, or to override specific strings.

strings that can be translated:


 * hints ("title=") for all the buttons
 * ui components. ATM, the script displays 3 textual titles, for the tabs (FEN, Notation, Metadata)
 * (optional) transformation for file and row legends
 * (optional) transformation for piece designation (RNBQK), possibly for move numbering (e.g., for ar, ۱۲۳۴۵۶۷۸۹۰)