In T363053#9732636, @thiemowmde wrote:

Unfortunately not, sorry. At the moment the ticket explains neither a solution nor a problem. What is the user story? How should the new syntax look like? How should it be presented and explained in the interactive TemplateData editor? How should it be documented? How should consumers like VisualEditor, the MediaWiki-extensions-TemplateWizard, Citoid, or the ContentTranslation workflow behave? Should this really block the user's edit from being saved? How would this look like in the UI? What does the error message say? What if the template already contains an unknown value that wasn't entered by the current user? Should we still block the user from continuing what they wanted to do? Why? How do we explain it to the user? How do we help the user to get unstuck? How do we measure the success rate to make sure the change was worth it and we don't loose meaningful edits due to users getting frustrated and giving up?

This is very similar to what I said in T197634#9712254 just a few days ago: I think what we are discussing here is called "programming" and requires an actual programming language. Which we have: Lua. It's the job of the template to decide if it wants to accept unlisted values, ignore them, or trigger an error. Why would we need to duplicate this logic in a different place an entirely different format?

i am asking for minimal change, in TD validation only.
the other stories may be viewed as asking for some behavior change (mainly VE support), all i'm asking here is to allow two specific "parameter" attributes when validating. code (and doc) changes should be minimal.
unfortunately i am not able to submit pull request myself, but i imagine such change should not be more than a dozen or so lines of code (most of which as comments)

T54582 asks a bit more,=, it asks for VE to behave in a certain way. this request is more modest: all i ask is to allow 2 more attributes.
there's strict validation code that doesn't let you save a page which contains invalid TD, and this request is to allow two more attributes, with suggested names.
it should be straightforward and short to implement, maybe even simpler than documenting it.

In T354383#9437737, @Esanders wrote:

I get a warning in both Firefox and Chrome when I press back. The only way I can get no warning is if I press back very quickly after the preview loads.

In T354383#9436556, @Aklapper wrote:

Which source editor? See https://www.mediawiki.org/wiki/Editor

this is not wikidata specific, and already hit the "early upgrade" wikipedias such as cawiki and hewiki. for details and links, see T338405

this is an old, practically abandoned story.

In T315639#8204471, @Jdlrobson wrote:

We simply wouldn't be able to change anything if we had to retain all existing CSS selectors and IDs. I don't know if you do development yourself, but if you do I'd urge you to take a moment to think
about how a constraint of not being able to change any ID would impede you with developing a MediaWiki interface.

In T315639#8175177, @Jdlrobson wrote:

....
Impact doesn't seem quite so bad. I'm only seeing 1408 cases across all wikis for JS files (I don't think it's worth focusing on CSS here).

In T315539#8166643, @MusikAnimal wrote:

They should instead file a Wikimedia-Site-requests to change the thresholds for semi-protection.

IMO, the exploit should not be exposed, to avoid causing more pain to sites running vulnerable versions.

just to clarify: the issue is that this was allowed until last version, which means there are already "live" templates which violate the assertion.
this caused significant disruption: specifically, one of these templates was the hewiki equivalent of "Cite journal" - as a result, editors could not create automatic citations of articles using DOI, and could not even create manual such citations using VE (and thanks to mediawiki devs, many editors don't even know how to use source editor - kudos!).
we went and amended those templates on hewiki (can't be sure we found them all - see below :) ), but it's more than likely similar issue still exists on other projects.

we should distinguish between visualeditor and templatedata.
templatedata provides a syntax to describe the template behavior, and is used not just by visualeditor, but other tools too.

just realized that this error does not add the template to any tracking category. make it 2 demerits.

beg to differ.
when ply is not defined, the final state of the game may or may not be useful to readers not using the interactivity, but the opening board is guaranteed to have zero value.
if you are 100% against showing the last ply, it would be better to declare ply= "mandatory" parameter, and show error when not defined, rather than defaulting to absolutely useless real estate on the page.

no need, thanks.
your explanation clarified it, and the comment is junk.

@4nn1l2 - please see update to story and consensus, and my comment on gerrit.

speaking of the algebraic notation, i would like to suggest some css tweaks to make it clearer that the plys are clickable.
cursor:pointer comes to mind.
another css change i request: please replace the bike and ped icons for fast/slow with dear/snail, as in the prototype. turtle would be even better.

description should be expanded to cover ply and swap.

i think you should obtain a simpler PGN with NAGs and test it with it.
the game on my user page was copied from one of the test cases in the extension's repo, but i do not know that it's valid.

@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.

(critique based on the screenshot only)

@Wugapodes
now it seems that it does not like the question mark in the doc, and complains about

@param array? $fenParts The ....

on lines 149 and 214 of includes/ChessParser.php

@Wugapodes :
it says

looked at the beta.
saw for the first time how "flip" also rotates the board itself, not just the button. super cute.

In T281649#7084227, @Wugapodes wrote:

....
suggest we make these optional features that each wiki can configure as-needed.
.....
Thoughts?

In T281649#7084227, @Wugapodes wrote:

....
suggest we make these optional features that each wiki can configure as-needed.
.....
Thoughts?

interestingly, the first implementation of the standalone introducing speed control used slider.
never got it to be satisfactory.
if i may, i think it will be better and more useful to have a single "speed control" button, which will allow the reader to enter the delay numerically.

lichess is not the model.
look for any site which holds large library of games in PGN format, and look at the interactive game interface. first i stumbled on (from enwiki article) https://www.chessgames.com/perl/chessgame?gid=1129672
autoplay is useful feature. talk with chess aficionados. at the very least we should consult the authors. i asked on their talk page. (see enwiki:Wikipedia talk:WikiProject Chess ).

several comments:

@sbassett : currently, the beta deployment task, T244075 depends on this task.
iiuc, there is kind of agreement that the extension can be deployed to test wiki, maybe under some conditions.
can you please update the beta task, and clarify if it can progress despite declining this task, and if so, what needs to be done?
maybe it's clear to everyone but me...
peace.

(not very useful comment):

In T269222#6716104, @Aklapper wrote:

Please contact the Chrome/Chromium developers (or use another browser).
In my understanding, there is nothing we can do/fix on our side hence closing this ticket.
See also T269222#6681319.

I added a wishlist item to add this extension to wmf wikis.

fwiw, i added to mediawiki:minerva.js on hewiki the following line, and the pencils are visible again.

first of all, this is different than the error i see in the console when adding debug=1, which is

can someone please explain

on further examination, it's a bit more complicated than than.

i would add specific chess cases, to verify correct pgn parsing:

1. en passant
2. castling
3. promotion

currently, on wikimedia sites, the parsing _is_ lax, despite what the documentation says.

In T167423#3990447, @brion wrote:

3D has been deployed to Commons, but not yet to the other wikis, so files can be uploaded but not yet used in articles. It'd be real nice to have mobile support working when that further deployment goes out so we don't have a bifurcated experience for our users -- is there any current work on this?

another user have copied the whole content of her console:

In T220706#5107219, @Aklapper wrote:

Could you please try this with safemode=1? This allows you to test if a problem is because of your user scripts or personal gadgets without uninstalling them. See https://www.mediawiki.org/wiki/Help:Locating_broken_scripts for more information.

additional information:
user reports that on enwiki, and on hewiki with "uselang=en", she _does_ sees the "Save" button, but not with hebrew ui.

In T217087#5103885, @aezell wrote:

In T217087#5101989, @Jonesey95 wrote:

Here's a link to a broken page:
https://en.wikipedia.org/w/index.php?title=Template:Imagemap_Germany_district_AW&oldid=566491718

A couple of minor enhancement requests:

1. Add a tracking category, e.g. Category:Imagemap with invalid coordinates, so that gnomes can find and fix these errors instead of having to encounter them randomly.
2. Tweak the error text, which complains about the input not being a "number", even when the input is a number that happens to be negative.
3. Best option: If negative numbers are truly invalid, deprecate the use of negative numbers but continue the old behavior of replacing the negative number with a zero, but add a tracking category so that gnomes can fix these templates. Give the job queue some time to populate the error category (see also T157670, which means that it may take many months or years for the error category to populate fully), then remove support for negative numbers once all pages are null-edited.

In T217087#5102461, @aezell wrote:

....., I think we can agree that negative coordinates aren't logical in the coordinate system used for polygonal image maps.