Could we please make sure this component is accessible for people using screen readers like JAWS, NVDA, ZoomText, and Speechify?

In T299521#9853712, @Loman87 wrote:

Deprecated: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in /var/www/html/mediawiki/thumb.php on line 362

In T282027#9851464, @Jdlrobson wrote:

Okay, thanks @Pikne! it looks like I might be confused then :-) Does someone want to have a go at updating the description and re-tagging to make this clearer? There was a time things accidentally got tagged with legacy Vector, so perhaps this is one of them?

Apologies for all the confusion here.

Here are some notes.

In T333031#9332612, @cscott wrote:

There's a /looong/ standing issue to *add* section tags to HTML output, which I can't find at the moment but it's like a 4 digit bug number. Also T300467: Expose section identifier in HTML output -- so I'm also hoping <section> tags make the cut.

Possibly of relevance here: book2scroll.

In T357197#9833165, @TheDJ wrote:

Like I get the desire, but you also have to look at the impact of that desire for others.

In T357197#9586503, @Nux wrote:

[…]

@Jdlrobson While there is certainly some overlap (no pun intended), I'm not convinced this task and T358081 are about the same issue or have the same solution. For T358081 at the very least the issue is exacerbated by Wikisource tending to have much longer (wider) page titles (due to extensive use of subpages), and by the "Wikisource" extension (why is there no Phab tag for that extension?) putting that giant blue "Download" button in the indicators area. We also have the unique-to-Wikisource issue of the "proofreading status" progress bar (as seen in the screenshot in T358081, added by ProofreadPage).

@Theklan Not sure whether this is relevant or helps at all (not really sure what the goal of this task is), but the English Wikisource main page has been based on CSS Grid since the Mobile Frontend changes in 2020. It's simple (bordering on primitive), but does the job fairly well.

In T200704#8440436, @Tgr wrote:

In T200704#4506999, Anomie wrote:

• Have LinkHolderArray take an option to unstrip general markers when replacing the link holders, and use that option from Parser::internalParseHalfParsed().

I guess this would be the least risky of the three options.

In T137291#9731083, @Bawolff wrote:

Maybe, but i would argue a new task would be better, when and if that happens.

Like we are talking about transitioning to something that doesn't exist yet.

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?”