In T209310#9724404, @Mike_Peel wrote:

My point was that those volunteers should be appropriately informed, with links to this ticket for background. But fair enough with marking this as resolved.

And now I just got a resend of a different email to a different user, originally sent on April 11. That’s something like two out of three emails I’ve sent using «Email this user» the last month+ that are getting resent.

In T362502#9721109, @Uzume wrote:

… #iferror from Extension:ParserFunctions is supposed to find things with class="error" so it should catch such things but it should be noted that ‎PagesTagParser.render where the error is thrown from is for <pages/> not for <pagelist/> so you are wrapping the wrong thing to catch the error.

In T299521#9635282, @TheDJ wrote:

The patch should make any errors more verbose so that we can collect more information about these failures.

But now I haven't gotten any more copies since April 5, so whatever it was seems to have cleared for now. It's probably still a good idea to dig through the logs to get an idea what caused this since it could very well happen again and at larger scale.

I think it is generally a bad idea to bulk-write OCR to Page: namespace pages. It tends to create huge backlogs of very poor quality text that discourages many contributors from working on a text (enWS has a million-page backlog there, and the number is not decreasing). The text saved also becomes quickly out of date when newer models or OCR engines become available.

A digression for the specific scope of this task, but mentioning it here in case it can inform direction / the discussion:

In T361860#9694838, @Jan.Kamenicek wrote:

… it floods my alerts in the Wikimedia projects.

In T361860#9693188, @jhathaway wrote:

@Xover if you could paste the headers of two of the messages that would help, the whole raw text would be the best however. I am curious how identical the emails are, as that would help indicate where they are being duplicated.

And now another two ticked in.

In T361860#9691323, @DannyS712 wrote:

@Xover I created https://phabricator.wikimedia.org/P59624 that is restricted to WMF-NDA members and the subscribers of the paste (currently you), which should be secure to put the full headers

I'm not sure grouping them by Wikisource domain is a good idea. For one thing, these do not map cleanly to languages (enWS includes "ang"; Spanish is a relevant language for multiple Wikisourcen; Norwegian has a politically-decided split between no-nb and no-nn; etc.), and for another we have Multilingual Wikisource where all languages are in scope. Latin is laWS, but also mulWS, and occurs in many in-scope works on enWS (just as quotations and such). Multilingual works. Etc. etc.

Sigh. Please don't use tricks like combining margin-top and padding-bottom. You're doing it to defeat margin collapsing, which is how the CSS box model is supposed to work. This patch makes Vector legacy and Vector 2022 behave very differently for certain inputs, mainly due to p-wrapping (T253072), and it's going to be a massive pain to work around from templates and TemplateStyles.

@Soda Since you wrote the patch for T358437, perhaps we could prevail on you to do the same for this bit too? It's just cleanup of old config, so no particular rush.

I think the problem here is that this varies per page and not per wiki or per user. This is one main reason why enWS (and frWS and some others) have implemented a "Dynamic Layouts" system: basically a Gadget that applies different styles based on user preference with a default provided by the presence of e.g. {{default layout|Layout 2}} (Layout 2 being the main width-constrained layout on enWS).

In T345723#9664754, @TheDJ wrote:

I was inspecting the epub, and I noticed that it sets:

style="width:480; height:717; "

In T345723#9664633, @TheDJ wrote:

I'll just note that, as all elements on a page, any css can be overridden and changed. So even if you don't want to use the skin frame, that is possible via Common.css, template styles etc etc.

I'm not entirely sure I'm following the problem you're seeing, but...

Indeed. The workaround from enWS was linked here for the benefit of other projects until the problem can be fixed in WS Export. We can't carry manually added and manually updated custom CSS for this on 100+ Wikisourcen indefinitely.

An intent to roll out Vector 2022 to enWS in the very near future has been announced so this issue just became a lot more pressing.

In T359949#9632658, @Havang wrote:

Hello, Is this related to the wikisource statistics
https://phetools.toolforge.org/statistics.php getting out of service quite simultaneously to this purging. These categories feed the statistics. Or is this an accidental coincidence?

I am still planning to migrate this tool, IRL is just being recalcitrant about giving me sustained time slots to work on it.

In T142237#9594054, @taavi wrote:

https://k8s-status.toolforge.org/namespaces/tool-phabricator-bug-status/ shows the tool running on the Kubernetes backend.

Matt hasn't edited since 2019 and no longer works for the WMF so is unlikely to show up and fix the tool. But if anybody feels up for usurping it, the code is at

I can reproduce this in Safari on macOS (latest release). There is nothing obvious in the console, nor does inspecting #wpTextBox1 reveal anything obvious. The fact that you can delete text but not type normally suggests something is hijacking keyDown events rather than having disabled the textfield. Running Balinese palmleaf model did not seem to trigger this, but both handwritten and typewritten Ukranian models did. I didn't try any others because Transcribus is sloooow.

I think (fwiw) async/await is the standout feature here, with everything else being possible to work around in various ways (transpiling, polyfills, do-it-the-old-way, etc.). I wouldn't want to argue in favour of raising browser requirements for that other stuff, and I wouldn't want to argue for generally raising it (with all that implies) for just the one language feature.

In T358437#9576405, @Lucas_Werkmeister_WMDE wrote:

Please disable and undeploy Extension:Collection from English Wikisource.

(other language Wikisourcen may want to consider requesting the same)

IMHO this combination of sentences implies that you’re requesting this on behalf of English Wikisource, but AFAICT you never discussed it on wiki?

Just as a curio, I had the same problem with the editing toolbar in the 2010 wikieditor and fixed it by sticking the following in my common.css:

In T357580#9560369, @Jdlrobson wrote:

@Xover which project are you referring to? To be clear the change has only occurred so far on the following wikis where impact is expected to be minimal:

• All projects where Vector legacy is the default skin
• Wikivoyage
• Wikibooks

Please also see the user notice from a year ago: T331679 - I am sorry if you missed that announcement.

In T357580#9558982, @Xover wrote:

Erm. Are you trying to say that this change has already happened for the wikis listed as "Wikis impacted", or that these will be impacted when the change is made at some as yet undetermined point in the future?

Erm. Are you trying to say that this change has already happened for the wikis listed as "Wikis impacted", or that these will be impacted when the change is made at some as yet undetermined point in the future?

In T319965#9536932, @Soda wrote:

Based on looking at the code, and playing around with the buildpacks/the jobs framework, I'm a bit pessimistic that we will be able to migrate everything (especially the custom jobs mess) to the newer framework in a reasonable amount of time, …

In T319965#9534722, @Soda wrote:

I'm looking into migrating some of the usable aspects (statistics and match + split) of phetools into seperate standalone tools. This might take a while however, so I'd like to request that the tool be kept running after the Feb 14th shutdown deadline.

In T357176#9530419, @Droftnats wrote:

Tried editing it here but don't have the rights: https://de.wikisource.org/w/index.php?title=Seite:Deutsche_Sagen_(Grimm)_V1_027.jpg&action=edit

The lack of accessibility for even colour blind people got to me, so I hacked up a local gadget to at least provide a tooltip with the text. I think that's probably the absolute minimum we should do while we wait for inspiration to strike regarding a long-term solution.

Erm. No use case for checking whether a page exists? That seems improbable.

We have a rather big document about follow, but as said above this was mostly wrong: https://docs.google.com/document/d/1n_V91k2s7ULVf2vBMEjbC-nMT6ma6UIsmYSoQJE4Oy4

I can't speak to the practical accessibility of this in screen readers (which should be checked in JAWS, NVDA, etc. too), but from a general perspective I don't think it makes sense to mark this up as a list, or to mark it up as a list and then change its display model to flexbox. My suggestion would be to use div + span; and possibly also to find some sensible content to put inside the elements instead of visually styling empty elements (think of it like alternative text, either percentages or absolute numbers).

As of right now ws-export has been down for 32 hours straight. Over the last 30 days recorded uptime is 60%. That's a 40% downtime.

Build Service image requirements

Quick status update

In T351035#9394371, @CCiufo-WMF wrote:

Note however that Codex components are meant to be MediaWiki agnostic, so direct integration with any specific APIs is unlikely.

But then we enter into the cache invalidation problem.

As of today, stats show 80% uptime over the last 90 days (aka. 20% downtime). Since December 6th, cumulative uptime is something like ~20%, with whole days of 0% uptime in the mix.

In T319965#9395054, @Soda wrote:

@Xover Could you add me as one of the maintainers (mainly to be able to see the current code).

In T353109#9395015, @VIGNERON wrote:

Could you confirm that you talking about https://phetools.toolforge.org/transclusions.html ?

Indeed, it's strange that only 21 Wikisource domains are shown because the other domains stats exist but are not displayed. For instance there is https://phetools.toolforge.org/graphs/Wikisource_-_texts_eo.svg for Esperanto Wikisource. I guess it should be quite easy to fix.

In T353109#9395042, @Soda wrote:

Is the current code for the tool publicly available ?

To the degree it is 1) technically feasible and 2) will actually help, I don't think a proposal to rename "wikisource.org" to something with a third segment will be received as an attack on the very foundations of… etc. We tend to call it "Multilingual Wikisource" or mulWS nowadays, and the two-segment name was a call made way back in the mists of time when the alternative was more "oldwikisource" than anything else. I can't predict how the communities will land on the question (they may prefer to maintain the status quo), but asking is at least an option.

Some initial thoughts:

In T351685#9356966, @Soda wrote:

The gadget is loading code from wikisource.org which is causing the session cookie conflicts mentioned, this should be temporary untill the patch that Tgr has proposed has been merged and deployed

I've disabled the gadget on enWS, but we have multiple gadgets that crossload code from other projects (HotCat from Commons, Wikidata Framework from an obfuscated code blob in user-space on ruWS, Popups from enWP, etc.) and across the Wikisourcen multiple languages crossload scripts from oldwikisource.

Another use case: referring to core/extension UI elements in user documentation and messages. I just had need to update a MediaWiki:Newarticletext message to refer to two specific UI elements provided by a WMF-deployed extension as brief instructions for inexperienced editors.

It's currently impossible to work with page-spanning tables (they show up as gobbledygook due to missing open table wikimarkup), previewing changes to the header (e.g. a running header), any formatting that requires a template or similar in the header, etc. I'm getting tired of having to round-trip into Preferences to toggle this off and on again every single time I have work with such constructs.

Oh, somehow missed that this task got created and assigned to me.

In T285354#9330068, @Aklapper wrote:

I boldly set the "Sign-in text" in GitLab to the following line:
`By signing in you agree to the following terms and policies:

Has this been tested on anything that's not a Wikipedia? And does "all wikis" mean "all wikis" or "all Wikipedias" in the announced "Enable Reference Previews on all wikis"?

A concrete example of the use case on Wikisource:

Man, this is getting complicated…

In T348658#9244694, @dcausse wrote:

@Xover I don't recall the prefer-recent keyword to ever have worked with a syntax like prefer-recent:2,30, searching via global search it appears that this page is almost the only one using this syntax across all WMF wikis.

Incidentally, cf. T106948, Extension:InputBox might be a useful reference for what types of things are needed on-wiki; and obsoleting it might not be a bad goal when deciding what facilities Codex should make available for use from wikitext.

Rename this task to target Codex instead, perhaps?

Thanks for the explanation. Unfortunately, the actual case where this was reported was in a search link generated by Extension:InputBox, so I don't control the order of arguments.

Workaround added on enWS.

Just mentioning this here so it's not lost in the shuffle:

In T337649#9162778, @akosiaris wrote:

I can sense the frustration pretty clearly […]

“So, Xover, how do you contribute to the Wikimedia projects?”

It's beyond the scope of this task, but I'm dropping a note about it here as it's a relevant factor to consider in designing and implementing a new modernized multipage viewer. This will appear in a separate Phab task at some point when I've chewed it over sufficiently to make sense. In ay case…

Yesterday, while uploading a small SVG file using bigChunkedUpload.js, the finalize stage took an unusually long time for such a small file and then logged 00019: FAILED: backend-fail-internal: An unknown error occurred in storage backend "local-swift-codfw". The file did seem to finish upload as expected despite this though.

In T241524#8201147, @Tgr wrote:

loading style modules instead of templatestyles (why?)

Why not? We could disallow making style modules embeddable, if we wanted, but I'm not sure I see the point. They are more restricted permission-wise but allow for more modern CSS.

In T340705#8975269, @Izno wrote:

1. Uses https://meta.wikimedia.org/wiki/MediaWiki:Gadget-luaparse.js

Apparently pa.wikisource is so bad it counts as two. 😎 I'd edit the description directly but I'm guessing this is a typo for pa.wikipedia or another of the pa. sisters that you might want to include.

@Bodhisattwa I think the idea is to let each project express such preferences through bn:MediaWiki:Epub.css (compare e.g. s:MediaWiki:Epub.css).

In T204201#8345942, @Xover wrote:

In T204201#7607036, @Jack_who_built_the_house wrote:

[…] Namespaces could be less urgent/relevant.

For Wikisource, and probably other sisters with multiple content namespaces, namespaces are a high priority.

In T87276#8784283, @Xover wrote:

This is still spewing errors in the console for every page load in Safari due to the hyphenless keyword. But cf. T180921 and T178356, are there any still-supported UAs that need (and do something sensible with) the old version of the keyword? That actually support current SSL/TLS versions and options (i.e. can actually connect)? Can we get rid of it? (finally, after eight years)

Hmm. The Page Status menu item icons also do not change appearance when the menu item is disabled (i.e. the "Validated" option), making it hard to tell that the menu item is in fact disabled. This isn't helped by the low contrast change to the menu item text label: it looks very little different from a normal enabled item. Further exacerbated in a typical case of looking at it on a "Proofread" page, when the much-more contrasty menu item is between the normal items and the disabled items.

Incidentally, judging by the volume and variety of feedback on this feature (I don't think I've seen this much engagement on a change to PRP so long as I've been active), it might be worthwhile to set up a #eis tag and / or a separate Edit-in-Sequence column on the ProofreadPage workboard so that issues can be filed as separate tasks against ProofreadPage but still grouped so you can keep track of them.

Just mentioning here, since it seems not unlikely that Edit Recovery will need to have the necessary hooks, depending on how strictly it's layered, to enable things like s:MediaWiki:Gadget-Easy_LST.js that need to transform wikitext on page load and before saving.

Is the proposal here to merge the functionality into the Wikisource extension, or to drop the functionality entirely?

In T308098#9101401, @Xover wrote:

In T308098#9100738, @Soda wrote:

EIS does use the postEdit callback, so that might be a good place to start ?

I'm not familiar with that.