Per @Arlolra in T274654#6946964 this is actually almost precisely the opposite of what I assumed in the task description: Parsoid isn't parsing the content of extension tags and instead calls out to the legacy parser. Since the legacy parser can't see outside its context (the extension tag content) neither does the nested call to Cite, which therefore has no way to know there is a <references /> tag elsewhere and thus emits one at the end of the extension tag content (the individual PRP <pages … /> tag). The patch that just landed for T278481 is likely to wholly or partially fix this issue.

In T278481#11147466, @gerritbot wrote:

Change #1155672 had a related patch set uploaded (by Jgiannelos; author: Jgiannelos):

[mediawiki/extensions/ProofreadPage@master] Add parsoid support in ProofreadPage extension

https://gerrit.wikimedia.org/r/1155672

@Aram: It looks like only administrators have the move-subpages permission on testWP. PWB is probably trying to move the subpages and failing (and the MW API makes this situation hard to detect). The same is the case for suppressredirect permission, except members of the Bot group can also do this in addition to administrators.

@Aram Not sure where you got "-movesubpages" from. As best I can tell it's been -nosubpages since support for the option was added (in 2022), and all the documentation I find seems to have the correct name. Could you retest and close this task if it was just a mistake? Or if there's documentation somewhere giving the incorrect name for the option knowing where would be good.

In T401754#11082723, @Pecha-Tsewang wrote:

The developers have surely thought about the user interface, but I doubt they've themselves done much editing/proofreading in wikisource with Tibetan manuscripts.

@Soda #wpTextbox1 isn't resizeable because it wreaks havoc with other functionality. It used to be, but got broken in the last big revamp of the PRP UI. I think @Samwilson was involved at least peripherally at the time. But a proper fix for this bug is to constrain both the minimum and maximum dimensions of the PRP editor UI so that e.g. very tall and narrow or very wide a low scan images doesn't lead to extreme situations like this.

In T357463#11068281, @SD0001 wrote:

Not yet, but someone can upload them and it's trivial to write a bot to keep them up to date.

In T340477#11031618, @SD0001 wrote:

I think the cleanest solution would be to reopen T56864 and work on implementing a secure "sandbox mode" in the LESS compiler that treats input as untrusted.

Now that async/await is finally available (T381537) I'll be starting work on replacing the above referenced Gadget that prompted this task. Async/await makes it possible to rewrite it, but it'll still contain a lot of boilerplate API calls with iffy semantics to figure out where it is in the subpage hierarchy. Having API like that described in this task could make that Gadget actually somewhat elegant and maintainable.

And per the use case described in T358660 having parity with the Lua library would be really helpful and avoid a lot of boilerplate calls to the Action API. As a first "MVP", having .exists for the current page (with its parent pages if the current page is a subpage). But long term also for arbitrary pages.

Note that this raises thorny issues of cross-project policy, permissions (e.g. filemover on Commons vs. move permissions on Wikisource), and what happens when the same file on Commons is used by multiple Wikisourcen (e.g. a book transcribed on one of the Indic Wikisourcen and translated on enWS). Files being renamed on Commons without the Wikisource community being aware of it (before someone notices the broken transcription) causes quite a few problems already, and if renaming a file on Commons suddenly triggered mass moves on Wikisource that's likely to get even worse.

In T319965#10891075, @taavi wrote:

Hello folks - this tool has a cache directory (/data/project/phetools/cache) that's over 100G in size. Is that in use or could we reclaim that disk space?

In T384725#10661228, @kostajh wrote:

In T384725#10660795, @Xover wrote:

But do remove all vestiges of the "account reputation" term first, it's almost guaranteed to lead a subset of the contributor community down rabbit holes that do not reflect the intent of this work.

Yeah, I agree with that. In terms of the proposals for the user-facing feature, I think we've done that, but if you think we should adjust any other wording, please let us know.

In T384725#10660715, @kostajh wrote:

… But we also saw that there are many useful data points that are helpful to quickly surface to moderators, …

"User Info Card", as used in the title is fine and dandy, but further down in the task description (and subtasks) the term starts morphing into "Account Reputation" at which point the immediate connotation is "Social Credit Score". I think the "account reputation" term needs to excised anywhere it appears.

In T389430#10654683, @EBernhardson wrote:

I'm not familiar enough with wikisource and ProofreadPage to know what effects this has on the wiki itself.

Potential subtask: T351035

In T210959#8920374, @TheDJ wrote:

google fonts api returns woff2 for Windows, but returns woff for macOS
This apparently has to do with issues like https://github.com/google/fonts/issues/2602

Still that means that if we have like 2 buckets, we'll probably cover the most significant browser support for that ppl will actually need.

Hmm. Did anybody check the intersection of browsers that do not support async/await and those that do support CSS Variables (which are required by Codex, and Night Mode, and…)?

In T384803#10495669, @Samwilson wrote:

I've not looked into this deeply yet, but it appears it may be related to the Toolforge proxy. The app is sending Content-Length correctly on my local Apache:

Remove myself as assignee on this task since I won't have time to work on it any time soon (and @Aklapper keeps nagging me :)). I still plan to get back to it eventually, but this better reflects the real staus just now.

In T370304#10111235, @Ladsgroup wrote:

… the specs allow [Retry-After] for 200 responses too, I can't find it in RFC 7231 though, I will check but I'm sure we checked the specs …

In T370304#10110960, @matmarex wrote:

https://www.mediawiki.org/wiki/Manual:Maxlag_parameter says that you can add e.g. &maxlag=5 to all of your requests, and retry if they fail with the maxlag error code. You don't need a separate request to fetch the current maxlag value. And you can read the suggested delay to wait before retrying from the Retry-After HTTP response header.

We could add something making use of that to mw.Api. It could be similar to how postWithToken() already works (that method implements retrying on specific failures).

In T370304#10107091, @Ladsgroup wrote:

You can get maxlag via queries like this: https://www.wikidata.org/w/api.php?action=query&format=json&titles=Main%20Page&maxlag=-1

In T370304#10105689, @Ladsgroup wrote:

I recommend that between each request, the tool should wait as long as max lag which is between 0.1s to 0.5s in normal times. That would automatically makes it back off during stress.

In T370304#10072844, @Ladsgroup wrote:

Random note: The gadget currently waits 1 second before next edit, I think it's fine to lower it to 500ms.

In T139144#10067083, @Xqt wrote:

… there are other issues which might be more important.

I don't particularly care how the various bits of the distro is broken into pieces, but for anyone who primarily wants to use the finished scripts the PyPI package is a bit useless right now. Installing the pywikibot package and then having to do a git checkout of it too in order to use it is… well, let's call it "not optimal" and leave it at that.

On English Wikisource the limitations and problems with the poem extension led to the development of {{ppoem}}. It's not universally used and some contributors still prefer the tradeoffs of the poem extension tag, but the approach taken by the template might be a good reference for this task.

If this is due to T294397, then as a result if it getting rolled back in T371977 the problem should now be gone. @BD2412 could you retest and report results here?

In T371977#10048477, @LucasWerkmeister wrote:

In T371977#10048450, @LucasWerkmeister wrote:

however, AutoWikiBrowser (AWB) also checks writeapi.

Eh… looking closer, it seems to check the writeapi right, not the siteinfo response member. So it’s not gonna be directly broken in the same way, I guess. Let’s untag them again.

This seems to be zhWS-specific, so removing the (somewhat confusingly named and conceived) "All-and-every-Wikisource" tag.

Wikieditor now provides a decent(ish) API for adding new groups, sections, and buttons; which is documented(ish) with examples at mw:WikiEditor/Toolbar_customization. It also provides the mw.hook() event wikiEditor.toolbarReady and wikiEditor-toolbar-doneInitialSections (documented on the same page). The API for removing things and modifying things is certainly not great, but it exists and is documented (ditto).

This 2012 bug (imported from Bugzilla) is about UI that has seen major revamps at least twice since the bug was reported (both in ways that would directly affect the subject of this bug report), and the user reporting the bug is no longer active on Wikimedia projects (they have like ~10 edits the last five years, the last one a year and a half ago). I am therefore going to close this as "Invalid".

This is unrelated to the 2010 Wikieditor; the horizontal/vertical switch and the sizing of the text boxes is controlled by ProofreadPage.

Should this be closed? It's ~9 months old and only reported once on a beta instance (which I guess is "production", but…). It seems odd to clutter up, e.g., the WikiEditor (2010) workboard with this.

Also reported at enWS here.

In T282027#9857561, @Jdlrobson wrote:

Getting away from solution-ing. It seems like the general issue here is the idea that indicators should be included some how in the header component rather than occupy the space between the article and Article/Talk/Tools bar - am I understanding that correct?

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:

Does someone want to have a go at updating the description and re-tagging to make this clearer?

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?