The Scriptorium is Wikisource's community discussion page. Feel free to ask questions or leave comments. You may join any current discussion or start a new one; please see Wikisource:Scriptorium/Help.

The Administrators' noticeboard can be used where appropriate. Some announcements and newsletters are subscribed to Announcements.

Project members can often be found in the #wikisource IRC channel webclient. For discussion related to the entire project (not just the English chapter), please discuss at the multilingual Wikisource. There are currently 396 active users here.





Bot approval requests




I'd like to request community approval (bot permissions) for SodiumBot to continue Phebot's matchandsplit task (The server for using the match and split service is at I am aware that this is somewhat late since SodiumBot has already been doing this for a bit (since the last Wikimedia Hackathon), however, better late than never :) Sohom (talk) 14:11, 13 June 2024 (UTC)Reply

What is the plan with respect to Phebot and this task? Is SodiumBot going to pass the task back to PheBot or will SodiumBot now take this on as a "permanent" task? Beeswaxcandle (talk) 20:08, 13 June 2024 (UTC)Reply
@Xover might be able provide more context here about the plans regarding phebot, but my understanding is that this task is going to be hard to setup using Phebot's old architecture (because unlike wsstats a lot of the code depends very very heavily on the now deprecated grid engine). Sohom (talk) 20:39, 13 June 2024 (UTC)Reply
My plan is to try to resurrect phetools at some point when I have the time for it, and at that point I will probably try to fix all of it (at which I may or may not succeed). The likelihood of my finding the time to work on it in any kind of reasonable time frame is very small, and the urgency of doing so is much much reduced now that we have an alternative for the Match&Split functionality in SodiumBot and toolforge:matchandsplit (not to mention the stats that Sohom has also set up). In other words, I wouldn't recommend holding your breath waiting for phe-bot to pick up this task again. Xover (talk) 07:37, 15 June 2024 (UTC)Reply
In that case, let's treat this Bot Approval Request as a request to change the six-month flag to indefinite provided that SodiumBot remains doing just the Stats update and Match&Split. I'll keep the request open for a week to allow for community input. Beeswaxcandle (talk) 07:48, 15 June 2024 (UTC)Reply
I agree. Permanent bot flag for the user account, plus authorization for the two specific tasks it is already performing.
@Sohom Datta: It is a bit overkill just now, but it's generally a good idea to document each distinct task the bot is authorized for on its user page, including linking to the discussion where that task was authorized, and to link to the documentation in the edit summary for edits the bot makes under that task. That way anyone that comes across an edit by the bot can easily find out a) what the bot is doing and why, and b) who authorized it to do so. It's convenient for other contributors and staves off unnecessary drama. Xover (talk) 08:05, 15 June 2024 (UTC)Reply
  •   Support, and thank you so much for doing this Sohom! Match&Split is an important tool for the community so your stepping up to the plate here is very very appreciated!
    I've checked some of the bot's recent edits and see no problems. This should also have pretty much the same risk profile as Match&Split in phetools, except that Sohom is actually around and responsive (which Phe hasn't been since 2016). --Xover (talk) 07:45, 15 June 2024 (UTC)Reply

Repairs (and moves)


Designated for requests related to the repair of works (and scans of works) presented on Wikisource

See also Wikisource:Scan lab

The Yellow Book Volume 3 - page moves


I have repaired the file for this work by adding in two missing pages (207 and 208) and removing duplicates. To address the new version, could you please:—

  • Delete /325 - /328
  • The page offset = -4
  • The pages to move = /83 - /220
  • The reason = Remove duplicate pages
  • The page offset = -2
  • The pages to move = /242 - /324
  • The reason = Insert missing pages (move is -ve as it needs to partly offset the effect of the first move)

Thanks unsigned comment by Chrisguise (talk) 23:56, 1 May 2024‎ (UTC).Reply

Update: Following issues with the scan of this volume, it has been replaced with yet another version (thanks M-le-mot-dit) which, touch wood, appears to be working OK. Could the requested moves now be undertaken. Thanks. unsigned comment by Chrisguise (talk) 11:08, 15 May 2024‎ (UTC).Reply
Pages /75-/78 are repaired. Offset -4 will start with /83. --M-le-mot-dit (talk) 09:50, 15 May 2024 (UTC)Reply
@Chrisguise, @M-le-mot-dit: I have performed the page moves and deletions as specified above. Please check that the results are as expected. Xover (talk) 06:39, 16 June 2024 (UTC)Reply
Thanks for doing this, your efforts have produced the exact result required. Much appreciated. Chrisguise (talk) 07:39, 16 June 2024 (UTC)Reply
  This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. --Xover (talk) 07:44, 16 June 2024 (UTC)Reply

Other discussions


Simplify Scriptorium page structure


[I thought we'd discussed this before, but I'm failing to find it in the archives just now. I think I recall that people were generally positive, but that we didn't have a good plan for alternative solutions for Announcements and Proposals. So reopening the issue to see if we can at least make a little progress.]

I'd really like to simplify the page structure of this page to avoid having subsections. It makes a lot of things much more complex, and don't work all that well on mobile (or in the Vector 2022 skin, but that's… a different issue). It is also confusing for newbies, and the important stuff (announcements, proposals) tends to get lost. So…

What would we have to do as an alternative for the current sections?

  • Announcements
  • Proposals
  • Bot approval requests
  • Repairs (and moves)
  • Other discussions

Other discussions would, obviously, just become the one section present on this page (with no actual separate heading, of course).

Bot approval requests could probably either move to WS:BR, with instructions to also post a notice here; or it could be just a normal thread here on the Scriptorium. We average far less than one bot approval request per year, and while looking through the archives for something else I saw several that just languished with no comment. Depending somewhat on the outcome for other sections, I think just making bot approval requests normal threads here is the most practical and pragmatic way to handle them.

Repairs (and moves) doesn't really seem to warrant a separate section on the Scriptorium, and in any case tend to be overlooked in their own section up above. I think most such requests should go to WS:S/H, requests specifically about scans should go to WS:LAB, and anything needing +sysop should go to WS:AN. So we could replace the whole section with instructions about where to go instead up in the header.

Announcements are, I don't think, very useful as a separate section here because they tend to get lost. I think probably we could make announcements just normal threads here, maybe with "Announcement: " tacked on as a prefix to the thread title. We could have instructions to add {{do not archive until}} so that announcements where that's relevant stay on the page more than 30 days. There may be other things we could do to enhance their visibility while keeping them as a normal thread.

Proposals too are, I think, better handled as normal threads here, combined with use for separate pages for things that are RFC-y (and with a notice here). We should also use watchlist notices (cf. the recent one about Vector 2022 users needing to update their scripts) for important ones (especially policy proposals), and possibly also create a template where current proposals are listed (the template could be permanent at the top of this page and WS:S/H, and we could encourage users to transclude it on their own user page to keep up with proposals). I think that would actually improve visibility of proposals.

I'm sure I've forgotten about something, and I'm sure people will have different views on what the best way to handle stuff is; but that's a snapshot of my current thinking.

PS. This thread isn't in itself a proposal, as such, but the discussion that precedes a potential future proposal. If there is significant support, or general apathy in the absence of active opposition, I'll make a concrete proposal up in #Proposals that would, then, presumably, be the last such under the status quo. Xover (talk) 10:44, 28 March 2024 (UTC)Reply

This sounds like a good idea to me! —CalendulaAsteraceae (talkcontribs) 15:15, 1 April 2024 (UTC)Reply
Just a note that this is the kind of change that needs positive agreement. If there isn't significant participation, and absence of strong opposition, no change can be made. I was hoping to get a sense of where the community stood in this thread, before proceeding to a specific proposal. If nobody thinks this is an issue or doesn't think it's worth the time-investment, then making an actual proposal would just be wasting everyone's time. Some yay, nay, or meh would be helpful, is what I'm saying. :) Xover (talk) 09:32, 5 April 2024 (UTC)Reply
Just wondering, how did this end? Because we still have #Announcements up there, which has not been used for a while, but apparently also WS:Scriptorium/Announcements, which is at least used for some newletters. — Alien333 (what I did & why I did it wrong) 10:56, 12 April 2024 (UTC)Reply
@Alien333: If it bugs (almost) nobody but me enough to comment here then there's obviously no support for making any change and the status quo prevails (and there's no point making a proposal under those circumstances). I'm guessing the reason nobody's commenting here is that they're mostly fine with how things are, and thus not motivated to think through the sketch of an alternative above. The current structure has worked well for a long time so changes to it has the presumption against it. Xover (talk) 12:25, 12 April 2024 (UTC)Reply
@Xover Perhaps this post became lost in the otherwise difficult to navigate Scriptorium? At any rate, I am not a great fan of the current layout, but equally wonder whether everything may become harder to find if things changed (for the most part, if I want to find the scan lab, I google it, as who knows where the link on Wikisource resides). If the Scriptorium did change, a clear table of contents at the start of this page, linking to the bot request, scan lab etc. subpages, would be much appreciated. TeysaKarlov (talk) 21:33, 12 April 2024 (UTC)Reply
I've thought for some time that the community pages here really need some sort of navbox. It'd certainly make it easier to get around. Arcorann (talk) 13:48, 13 April 2024 (UTC)Reply
Yeah, that's partly what I have in mind. I'd like to split things into more separate pages, with one thing (main section) per page, and then have a navbox type thing on each page. I also think we can make a template that's displayed prominently in strategic places that lists all currently open proposals. Something like w:Template:Centralized discussion. Xover (talk) 13:53, 13 April 2024 (UTC)Reply
The irony for me is—indeed!—this discussion got lost and I didn’t see it until just now despite my best efforts to follow this page. As a new WS contributor, it’s been hard for me to get invested in this page despite it being on my watchlist (where multiple edits are easily lost track of because of the default way it collapses multiple edits into just one, which I don’t fully understand).
I’m not smart or experienced enough to propose specific restructuring solution(s), but wanted to say I support any effort by admins and other experienced folks to improve our community interaction. Compared to other “risky” proposals that would affect content in the main namespace, it seems relatively lower risk to talk about improving this discussion namespace. Just a lot of inertia and potential loss aversion at play probably, which is understandable as a human cognitive bias. Brad606 (talk) 14:59, 13 April 2024 (UTC)Reply
@Brad606: Yeah, the default watchlist is a bit confusing in this sense. I recommend going to both the Watchlist section of your Preferences to turn on "Expand watchlist to show all changes, not just the most recent", and to go to the Recent Changes section to turn off "Group changes by page in recent changes and watchlist". Why in two different tabs of the Preferences? I have no idea. ¯\_(ツ)_/¯ Xover (talk) 18:30, 13 April 2024 (UTC)Reply
@Xover: Yes, indeed, part of the reason this discussion has been unseen is because of the mountain of obscured discussions already in the Scriptorium from other cases.
Specifically for proposals, I think this deserves its own separate page. Note that Wiktionary has wikt:Wiktionary:Votes, a process which works quite well. Official votes (on policy, etc.), aka proposals, are done in a very structured format:
  • Draft it out, based on and reference previous discussion.
  • Set a time when the vote begins. Have it sit there as it would be when it starts more or less, but don't allow people to actually vote until the date and time of it starting. This serves a useful purpose: People can comment on the vote's talk page, etc., if the proposal has lack of clarity or has other inherent issues.
  • Most importantly to me, set a clear time when the vote ends. Most of our discussions here (being one of the problems with both the Scriptorium and our desert known as RFC) do not have clear end dates, or clear definitions or enactments of resolution. So they just sit around more or less as thought experiments, going back to the huge "community practice vs. policy" dichotomy we have as well.
So, I think our proposals should function somewhat like this. They should at least be structured so that action is ensured to be taken if consensus allows. Wiktionary also transcludes a list of all current votes on everyone's watchlist, as well as in many other places, so that the wider community is aware... Some ideas for a page title: Wikisource:Votes, Wikisource:Proposals, or (and I like it a lot less) Wikisource:Scriptorium/Proposals.
I'm interested to know what your thoughts on this proposal structure are. I'd move to get the other sections mentioned to subpages as well (and repairs could maybe be merged with WS:Scan lab), though I have less to comment about them. SnowyCinema (talk) 00:13, 14 April 2024 (UTC)Reply
Ok, based on the feedback so far it seems there is interest in pursuing this. The next step then is to start drafting an actual proposal. I'm a bit pressed for time, so I won't get to that soon, but I've tagged this thread so it doesn't get archived. Once I get around to it I'll make a subthread here with a specific proposal text that can be discussed until we're happy with it. And once we have rough consensus on what the proposal will be we can run it up in #Proposals, add a Watchlist notice, etc. Xover (talk) 09:11, 29 April 2024 (UTC)Reply
(@Xover I found that other discussion you mentioned in your first message, you did not find it because it is in the talk page) — Alien333 (what I did & why I did it wrong) 16:32, 22 May 2024 (UTC)Reply

Match and split


I've managed to get a rudimentary version of the old code up and running at :) Unlike the previous version, the bot is not omnipresent and jobs need to be manually submitted at the match endpoint and the the split endpoint respectively. The resulting edits will be made by SodiumBot.

Feel free to test the tool and let me know if there are any bugs/issues/crashes that you find. Once a significant amount of people have used the tool and confirmed that it is working as intended, I'll start the process of making the tool automatic (similar to how phetools worked) Sohom (talk) 11:54, 5 May 2024 (UTC)Reply

omg I missed this but I'm going to test this so hard —Beleg Tâl (talk) 16:52, 31 May 2024 (UTC)Reply
I'm not sure if I'm doing it wrong, but I submitted The Singing Bone (Freeman)/The Case of Oscar Brodski to the match endpoint and it said Response: {"status":"recieved"}, but nothing happened on the page and the task didn't show up at either. —Beleg Tâl (talk) 17:18, 31 May 2024 (UTC)Reply
Update: It's working now :) —Beleg Tâl (talk) 20:56, 12 June 2024 (UTC)Reply

Transclusion of ToC for 'The Poetical Works of Robert Burns'


Can anyone explain what's happening with this work? It contains six pages of contents, running to something of the order of 500 items. Of the six pages, only four will transclude on both the index page and in the main space. The final two pages (/15 & /16) only appear as links, and also appear to cause the 'authority control', 'defaultsort' and copyright templates to fail too. I've checked that all the 'begin' and 'end' elements are present and in the correct locations, etc. I'm guessing that it might be due to the total number of entries, but who knows?—hopefully someone out there. Chrisguise (talk) 10:30, 15 May 2024 (UTC)Reply

Chrisguise Even though you used the more complicated yet "lighter" dotted TOC, the index is one page too long for rendering in the Main. See how it also dumps it into Category:Pages where template include size is exceeded? It is a pity because it looks great until it stops rendering pages.--RaboKarbakian (talk) 11:15, 15 May 2024 (UTC)Reply
You should leave that "up" for a while; it is a great example of everything that is right and wrong about the dotted TOC. Look how when the wiki decided to quit sending its cpu/ram/whatever to draw the page, it didn't even render DEFAULTSORT which (I think) is closer to the wiki works than {{authority control}} which it also refused to render! In that same category is Compendium of U.S. Copyright Office Practices (3d ed. 2014)/Chapter 600 which tanked out fairly early. That page uses the easy but even more terrible {{dtpl}}. Old-fashioned pings to User:Xover and User:Inductiveload. Maybe a script or two (that is already written and one that can be pecked out in 20 mins or less) might show up to make conversion to (boring yet still nice to look at) wiki-sane TOCs easier.--RaboKarbakian (talk) 11:54, 15 May 2024 (UTC)Reply
TE(æ)A,ea. maybe {{nsl2}} but a lot more of it will render if it is relieved from {{dtpl}} which uses a new table for each use. So approx. 30 tables per page on 14 pages that is close to 400 tables, maybe more. IL has a script that will change {{dtpl}} into the {{TOC begin}} format and it will reduce the number of tables started and completed from 400+ to 1. So whatever problem the page has rendering after the reduction of table number will probably be caused by the large number of {{nsl2}}, but, with ~399 less tables to start and end, maybe everything will render.--RaboKarbakian (talk) 14:55, 16 May 2024 (UTC)Reply
Chrisguise, TE(æ)A,ea.: toc to toc conversion.--RaboKarbakian (talk) 13:19, 17 May 2024 (UTC)Reply
@Chrisguise this looks like a perfect place to use {{SimpleTOC}}. EDIT: I've updated it to use {{SimpleTOC}} and it's working well now :) —Beleg Tâl (talk) 16:42, 17 May 2024 (UTC)Reply
don't know why the love of dotted lines. maybe we should deprecate the bloatware, as a snare for the unwary. and add examples in the toc help. --Slowking4digitaleffie's ghost 03:44, 21 May 2024 (UTC)Reply
@Beleg Tâl @RaboKarbakian @TE(æ)A,ea. @Slowking4 Thanks for the responses and the editing (the help page for 'SimpleTOC' is not helpful at all, so wasn't sure how to use the template). It does seem to render properly now.
I like the dotted templates because I like to achieve a reasonable facsimile of the front matter, plus the dotted TOC performs the same function on screen as it does on the page, of providing visual alignment of the chapter information and the page number. Perhaps someone should fix the bad coding of these simple, easy to use templates, rather than investing in the not user-friendly alternatives. Chrisguise (talk) 09:34, 21 May 2024 (UTC)Reply
Thanks for the reminder - I've updated the docs for {{SimpleTOC}} to hopefully be more helpful. —Beleg Tâl (talk) 13:55, 21 May 2024 (UTC)Reply
I agree with Chrisguise that the dot leaders are both practical and helpful, and in the case of {{SimpleTOC}} (unlike most other TOC templates) they do not add any bloat at all. Once dot leaders are fully implemented into CSS this won't be an issue anyway. —Beleg Tâl (talk) 14:00, 21 May 2024 (UTC)Reply

In case anyone has an idea: we're having the same problem down there, but even worse (more than 1300 lines in TOC, even using {{TOC row 1-1-1-1}} that is as close to a raw table as I know of, it exceeds the unstrip size by 20%) — Alien333 (what I did & why I did it wrong) 18:51, 26 May 2024 (UTC)Reply



Was depreciated in 2010. How many years need to go by until the (even originally unimportant) "minor differences" in formatting are entirely irrelevant and we can just redirect this to whatever template makes text in the |1= field smaller? As is, the current treatment is just a waste of everyone's time.  — LlywelynII 18:45, 15 May 2024 (UTC)Reply

For reference to the original discussion for why kept but deprecated, Wikisource:Proposed_deletions/Archives/2010-05#Absolute_font_size_templates. In short: 1. to prevent well-intentioned individuals from recreating them (if deleted) and 2. to prevent confusion with the HTML small tag [1] and CSS font-size making a distinction between small and smaller, large and larger. [2] (if redirecting small to {{smaller}}, etc.). Of course, this can be revisited. MarkLSteadman (talk) 00:10, 16 May 2024 (UTC)Reply
Looking at what links to the template, there is exactly one place that still makes reference to small that isn't an archive: the documentation for {{hlist}}. If we switch out all the references to deprecated templates there, that'll be it. Arcorann (talk) 00:54, 16 May 2024 (UTC)Reply
If we consider redirecting, we should also keep in mind that a "Small" template exists on multiple Wikipedias, Wikisources, etc. Part of the reason for keeping the template as deprecated is that there is a template by that name on many, many projects, and the font-size is not quite the same on those other projects. --EncycloPetey (talk) 01:32, 16 May 2024 (UTC)Reply
That was already brought up, that the "minor differences" are not worth keeping it around. For those who do actually care, they can, and probably should and will, use custom CSS anyways. MarkLSteadman (talk) 13:30, 19 May 2024 (UTC)Reply
I do not see a previous comment above that mentions the fact that (a) other projects have a template with this name, or that (b) it is the standard name for such a template on those projects. So in fact this was not already brought up. --EncycloPetey (talk) 15:13, 19 May 2024 (UTC)Reply

Manual aggregation of newspaper articles versus automatic aggregation


What is the advantage to switching from automatic aggregation of newspaper articles to manual aggregation? I see them being switched from time to time, but I can't fathom the reason. It just adds another layer of work and misses new articles unless someone remembers to add them. See for instance: San Francisco Call, the most recent one I noticed. See the edit history for before and after. The format is almost identical, other than one column versus multiple columns. Automatic aggregation has one more entry than the manual aggregation. RAN (talk) 00:39, 16 May 2024 (UTC)Reply

In theory, the advantage is that manual aggregation can be better-organized and exclude redirects. —CalendulaAsteraceae (talkcontribs) 19:03, 17 May 2024 (UTC)Reply
  • Better is subjective, and missing articles from the index is more important than having one column versus three columns. We would probably be better of deleting unused redirects if they are cluttering the index. There are currently eight different formats for creating an index. We should standardize on one or allow an automatic and a manual aggregation, the way it is available at Wikimedia Commons. We can have Portal:Newspaper and Newspaper, with Portal:Newspaper (or the other way around) always automatic. --RAN (talk) 23:56, 17 May 2024 (UTC)Reply
  • Is anyone against me creating Portal:San Francisco Call so we can have both automatic aggregation there and manual aggregation at San Francisco Call (or the other way around) using one of the eight different formats in use throughout Wikisource. It would be the equivalent of Commons:Category:Abraham Lincoln (automatic and includes everything) and Commons:Abraham Lincoln (manual in any format you please). --RAN (talk) 02:20, 19 May 2024 (UTC)Reply
why don't you seek a consensus about the arrangement of newspaper pages? the broken commons category process may not be the best model, rather you might want to look at the commons creator, or institution pages, or commons:Template:Wikidata_Infobox, that are wikidata generated. --Slowking4digitaleffie's ghost 03:39, 21 May 2024 (UTC)Reply
currently, Category:Category:Steamboat_Willie, Category:Film_characters_by_actors, and Category:Men of the <country> by name, where "the" isn't needed. apparently there is constant discussion about categories, to an uncertain purpose. it does not disseminate images. i would call that broken. you can hand curate a subject index, but what is your maintenance process? leveraging wikidata is a better method.--Slowking4digitaleffie's ghost 19:04, 7 June 2024 (UTC)Reply
and now an attempt at a problem statement RFC:_Automatic_categorisation_both_bane_and_gain;_work_needed_to_identify_source_of_categorisation apparently the editors think generating categories by infobox is "wrong", --Slowking4digitaleffie's ghost 14:59, 9 June 2024 (UTC)Reply
(the above link is broken, here's the correct one: c:COM:VP#RFC: Automatic categorisation both bane and gain; work needed to identify source of categorisation) — Alien333 (what I did & why I did it wrong) 16:07, 9 June 2024 (UTC)Reply

Invitation to join May Wikisource Community Meeting


Hello fellow Wikisource enthusiasts!

We're excited to announce our upcoming Wikisource Community meeting, scheduled for 25 May 2024, 3 PM UTC (check your local time). As always, your participation is crucial to the success of our community discussions.

Similar to previous meetings, the agenda will be split into two segments. The first half will cover non-technical updates, such as events, conferences, proofread-a-thons, and collaborations. In the second half, we'll dive into technical updates and discussions, addressing key challenges faced by Wikisource communities.

Simply follow the link below to secure your spot and engage with fellow Wikisource enthusiasts:

Event Registration Page

Agenda Suggestions: Your input matters! Feel free to suggest any additional topics you'd like to see included in the agenda.

If you have any suggestions or would just prefer being added to the meeting the old way, simply drop a message on

Thank you for your continued dedication to Wikisource. We look forward to your active participation in our upcoming meeting.

Regards, KLawal-WMF, Sam Wilson (WMF), and Satdeep Gill (WMF)

Sent using MediaWiki message delivery (talk) 11:34, 20 May 2024 (UTC)Reply

Tech News: 2024-21


MediaWiki message delivery 23:04, 20 May 2024 (UTC)Reply

Feedback invited on Procedure for Sibling Project Lifecycle

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Dear community members,

The Community Affairs Committee (CAC) of the Wikimedia Foundation Board of Trustees invites you to give feedback on a draft Procedure for Sibling Project Lifecycle. This draft Procedure outlines proposed steps and requirements for opening and closing Wikimedia Sibling Projects, and aims to ensure any newly approved projects are set up for success. This is separate from the procedures for opening or closing language versions of projects, which is handled by the Language Committee or closing projects policy.

You can find the details on this page, as well as the ways to give your feedback from today until the end of the day on June 23, 2024, anywhere on Earth.

You can also share information about this with the interested project communities you work with or support, and you can also help us translate the procedure into more languages, so people can join the discussions in their own language.

On behalf of the CAC,

RamzyM (WMF) 02:25, 22 May 2024 (UTC)Reply

The Kojiki is incomplete


The Kojiki (Horne) is incomplete here and has been so for over a decade. the full text is here can I just copy it to here? Immanuelle (talk) 21:04, 23 May 2024 (UTC)Reply

The short answer is no, per the policy Wikisource:What Wikisource includes second hand transcriptions are no longer acceptable. One reason it leads to situations like here where a work might be edited or changed, for example, this version appears to be a complete version of a latter abridged / edited version (The Sacred Books and Early Literature of the East/Volume 13/Book 1), but it is missing the footnotes, so maybe it is actually an edited version published somewhere else without the footnotes (e.g. published on some other website someone copied...)? There was an effort that got 178 pages into transcribing the 1882 publication Index:Kojiki by Chamberlain.djvu, that anyone interested in can proofread against. Note the version from sacred-texts appears to be based on a scan of a 1970s reprint of a 1919 reprint. MarkLSteadman (talk) 00:16, 24 May 2024 (UTC)Reply

Table of Contents help


Can someone help me in the creation of Index:Indian Medicinal Plants (Text Part 1).djvu. We are working to complete the project. Can anyone extend your helping hand in completing the Table of Contents. Thanking you. Rajasekhar1961 (talk) 06:48, 24 May 2024 (UTC)Reply

@Rajasekhar1961 Which pages are the table of contents on? Thanks, Cremastra (talk) 15:37, 25 May 2024 (UTC)Reply
Page:Indian Medicinal Plants (Text Part 1).djvu/24 through 39. then transclude on the index page. --Slowking4digitaleffie's ghost 19:02, 25 May 2024 (UTC)Reply
I could help, though there's the question of how. I'm going to use {{TOC row 1-dot-1-1}}, instead of the {{dtpl}} used on the first page, due to the size of it. — Alien333 (what I did & why I did it wrong) 19:08, 25 May 2024 (UTC)Reply
@Alien333 Given that Chrisguise's TOC had approx.~500 entries, and this looks to have over 1000, is either SimpleTOC or, dare I say it, not dot-leaders whatsoever, going to be required (given the number of phantoms that the SimpleTOC might need, unless there is a good way to embed SimpleTOC's in another table)? TeysaKarlov (talk) 00:53, 26 May 2024 (UTC)Reply
Hmmm. It's true that the TOC row's may be excessive here, but embedding tables is definitely not the way to go to reduce post expand size. Transcluding the first two pages with {{TOC row 1-dot-1-1}} is already a third of the maximum expand size, so I'm going to try with {{TOC row 1-1-1-1}}. — Alien333 (what I did & why I did it wrong) 07:10, 26 May 2024 (UTC)Reply
@Rajasekhar1961 It's done. — Alien333 (what I did & why I did it wrong) 18:29, 26 May 2024 (UTC) EDIT: Well, looks like it's not over after all. The TOC manages to transclude entirely, but the PD-US after breaks down. {{TOC row 1-1-1-1}} is as near a raw HTML table as I can think of, so I don't know how we'll do this. I also moved the preface to a subpage, but still. I think there's just no way of making it fit on one page. — Alien333 (what I did & why I did it wrong) 18:45, 26 May 2024 (UTC)Reply
Took a quick look. The PD template looks like that because it is missing the CSS styling, possibly because of the "Unstrip post-expand size" exceeds 5MB warning. Someone with more experience of mediawiki internals might understand why that error blocks the loading of the styles from {{License/styles.css}}. MarkLSteadman (talk) 23:50, 26 May 2024 (UTC)Reply
Possibly because each row gets set with the class attribute, where it might be more scalable to use page styles to define once per a column? MarkLSteadman (talk) 00:40, 27 May 2024 (UTC)Reply
I'll try using a bare something like |- | {{{1|}}} || {{{2|}}} || {{{3|}}} || {{{4|}}}, removing the class in the template, and instead putting it in the {|, as classes like __toc_row_1-m-1-1 appear to be passed to child nodes. — Alien333 (what I did & why I did it wrong) 05:50, 27 May 2024 (UTC)Reply
Well, that did it. Removing the row classes brought it from 6MB to 180KB. I put it in {{TOC row min-4}}. It's a good idea to remove the row classes, put the class of most lines in {{TOC begin}}'s class parameter and override for the few cases we need. — Alien333 (what I did & why I did it wrong) 06:57, 27 May 2024 (UTC)Reply
Note that The Art of German Cooking and Baking and Statesman's Year-Book 1913 both have the same issue as well. MarkLSteadman (talk) 07:08, 27 May 2024 (UTC)Reply
  Done Fixed them with {{TOC row min-3}}. Their unstrip sizes are now respectively 800KB and 1MB. — Alien333 (what I did & why I did it wrong) 07:42, 27 May 2024 (UTC)Reply
Every new generation of contributors invent new templates to produce toc tables, thinking surely, surely, there must be a better and easier way to do this. Slowly but surely, if they stick around, they discover all the problems with wrapping table syntax in templates; but the myriad overlapping and multiplying templates persist. Now we've gotten to the point where we have templates that literally just spit out…
| {{{1|}}} 
| {{{2|}}} 
| {{{3|}}}
…instead of typing…
| || Constitution and Government || 4
…and requires you to manually add another template to attach a stylesheet. That is, it is literally more complexity for less functionality than doing the same with normal table wikimarkup and Help:Page styles. I despair…
Pretty please with sugar on top, stop using templates for tables of contents and stop creating ever more templates to spit out some custom combination of template markup. Please? --Xover (talk) 13:50, 30 May 2024 (UTC)Reply
I know that these templates seem a bit useless, but it's in case someone not familiar with table markup has a large TOC to deal with.
I don't think they really want to know that it works by removing the row classes and that therefore it's just simple table markup.
EDIT: The advantage is also that it's easier to integrate it with the other TOC row's.
The tables to be fixed with this are often started before the problem is recognised, and it's much easier to just to a search-and-replace from whatever there was before to another template name than having to painstakingly replace the template starts by |- | and some but not all |'s with ||.— Alien333 (what I did & why I did it wrong) 16:57, 30 May 2024 (UTC)Reply
Don't take my ranting to heart; it's a long-standing and generalised frustration.
Yes, when creating a point solution to this one specific problem this was a rational approach. I'm saying that, in general, these templates by merely existing create the expectation that they should be used and is somehow better than plain table markup (and we keep amassing more and more of them). In reality they cause more problems than they solve, and contributors who struggle with the complexities of creating tables of contents have no easier time of it with the templates than they would with the table markup. Rajasekhar1961, for example, is a prolific and long-standing contributor whose strengths simply lie elsewhere than table of contents creation. No template we ever create is going to change that.
IMO, we should bulk deprecate all the toc templates and focus our efforts on documentation, how-tos, community assist, and maybe some tooling to make table wikimarkup + Page styles easier and more efficient to use. Xover (talk) 17:21, 30 May 2024 (UTC)Reply
I agree about the whole documentation bit (I often grumble to myself about it), but I will stay a fervent defender of templates.
Template's primarily utility of factorizing formatting is indeed reduced when the template call is as long as the formatting, but they also factorize change.
If we make a decision, change our mind or just find a better way to do it, if it's a template we only have to fix one page, if it's direct formatting we have to fix all of them.
And specifically for the TOC templates, apart from the whole dot leader mess, they are I think simpler than table markup. Take for instance {{TOC row 3-1}}.
What's quicker, {{TOC row 3-1|a|b}} or |- |colspan=2 style="width:99%;text-align:left"|a |style="text-align:right"|b?
And that's excluding the other things like padding, vertical align or wrapping that make it nicer although they're not necessary — Alien333 (what I did & why I did it wrong) 17:41, 30 May 2024 (UTC)Reply
See Help:Page_styles#Tables_of_contents. You can have just table markup and still get your fancy formatting in a more reusable way, no templates needed. You can do arbitrarily complex formatting that way without a proliferation of templates, but it really shines for the simpler more regular tables of contents. Xover (talk) 18:29, 30 May 2024 (UTC)Reply
The only update you can do with table styles that will propagate is changing the classes, if any more significant changes are to be made they have to be made individually. As you said, it works best for simpler TOCs, and it's to be expected that we have many different templates when there are so many ways for a TOC to be different. — Alien333 (what I did & why I did it wrong) 18:44, 30 May 2024 (UTC)Reply
We're getting far afield, but… You're trying to teach grand-pappy to suck eggs. Yes, in almost every case we should use template wrappers over raw formatting markup. But for tables the markup syntax is not suited to wrapping with a template and creates endless problems. And the use case (toc tables) in effect requires creating a completely new microsyntax to cover all the cases, at which point all you've done is make it less accessible because you can no longer rely on general knowledge of (and documentation and howtos for) tables and CSS. The important part of working with toc tables is describing the structure of the table; and changing the structure of the table is not something you can reliably do through the template abstraction. Any formatting and similar is more readily and reliably handled with page styles (or an approach like {{auxiliary toc styles}} in a pinch). Xover (talk) 06:18, 31 May 2024 (UTC)Reply
Thank you everyone for the help. I do not know the technical aspects. Is it possible to link the subpages of the species to their corresponding pages.--Rajasekhar1961 (talk) 09:33, 29 May 2024 (UTC)Reply
I'm not sure what you mean, can you clarify? — Alien333 (what I did & why I did it wrong) 09:35, 29 May 2024 (UTC)Reply
See this page Indian Medicinal Plants/Natural Order Moringeæ; It has two plant species 336 and 337. Is there any necessity to link these individual species of plants from Table of Contents.--Rajasekhar1961 (talk) 11:32, 29 May 2024 (UTC)Reply
No, there's no real necessity. On top of that, I fear that it would be too large if we add 1381 more links. — Alien333 (what I did & why I did it wrong) 11:37, 29 May 2024 (UTC)Reply
You can add {{anchor+}} and then link via ChapterName#AnchorName if you really want to, but in general, there is no need and it makes the chapter divisions less clear. Other works with Chapter composed of many small sections we don't typically break up and link either. MarkLSteadman (talk) 12:53, 29 May 2024 (UTC)Reply

Tech News: 2024-22


MediaWiki message delivery 00:15, 28 May 2024 (UTC)Reply



This template now seems to be producing redundant information. It has always(?) included a linked statement in the 'notes' part of the header concerning the volume the article is from, but it now also includes a link to the same place (as a roman numeral only) as the first line of the transcluded article. The former seems to me to remain appropriate, the latter unnecessary. For an example see Encyclopædia Britannica, Ninth Edition/Turmeric. Chrisguise (talk) 10:14, 28 May 2024 (UTC)Reply

Block center vs Center block


Can someone explain the difference between {{block center}} and {{center block}}? I haven't been able to figure out which one is preferred. Arcorann (talk) 00:12, 29 May 2024 (UTC)Reply

The {{block center}} template has been around longer and is better maintained. --EncycloPetey (talk) 01:23, 29 May 2024 (UTC)Reply
Block center is based on a div, while center block is based on span. So, it depends on the level you need to use them at. You can't wrap block center inside a template that is a span, but you can with center block. I usually put the "where on the page" outside the "what it looks like", so nearly always use block center. Beeswaxcandle (talk) 08:01, 29 May 2024 (UTC)Reply
Both templates are div-based. —CalendulaAsteraceae (talkcontribs) 21:25, 29 May 2024 (UTC)Reply
I personally prefer {{center block}} because it is more consistently named with other block templates ({{smaller block}}, {{italic block}}, etc.) However, I think {{block center}} is generally more popular. —Beleg Âlt BT (talk) 14:04, 30 May 2024 (UTC)Reply
Also I think there used to be significant differences between them (one of them was table based I think?) but I'm pretty sure both are more or less equivalent now. —Beleg Âlt BT (talk) 14:10, 30 May 2024 (UTC)Reply
No, there are significant differences in how they're implemented. One sets the display model of the div to be a faux table and uses positioning and other weirdness. The problem is they both have a gajillion options and are being used in weird ways that rely on undocumented quirks of how they're implemented, so any attempt at consolidating them is going to trigger mobs of villagers contributors with torches and pitchforks because you've changed alignment by a pixel in some pathological edge case that was never intended to work to begin with. It can be done but it's a lot of thankless work, and I am not at all certain we could get community consensus to do so. The community would have to accept that some stuff inevitably would break along the way, and given the pushback we've had on less intrusive changes I'm not sure the appetite is there. Xover (talk) 17:37, 30 May 2024 (UTC)Reply
Oh yeah, I'm not going anywhere near any attempts to merge those templates :D —Beleg Âlt BT (talk) 17:45, 30 May 2024 (UTC)Reply
Are you sure? I'd be prepared to offer 150% of your base admin hourly rate! :) Xover (talk) 18:37, 30 May 2024 (UTC)Reply
Is there any difference between these that could not be effected by a single template with parameters added to toggle between specific functionalities? BD2412 T 01:38, 1 June 2024 (UTC)Reply
I've done some work to bring the templates closer together (making sure they have the same gajillion options and simplifying the code somewhat). At this point, the differences in implementation are:
.wst-center-block {
.wst-center-block-title {

.wst-block-center {
.wst-block-center-title {
I also added some tracking categories:
CalendulaAsteraceae (talkcontribs) 03:44, 10 June 2024 (UTC)Reply
I've discovered a practical difference in behaviour: {{center block}} will ignore a floated element in its margin, but {{block center}} will be shifted to the side and centered in the remaining space. See for example Page:The baby's opera - a book of old rhymes, with new dresses (IA babysoperabookof00cran).pdf/11. —Beleg Tâl (talk) 15:29, 12 June 2024 (UTC)Reply
That's good to know about! Which behavior do you think is preferable? (I'd be inclined to say the template should account for the floated element, but I'm open to opposing arguments.) —CalendulaAsteraceae (talkcontribs) 17:25, 12 June 2024 (UTC)Reply

Move Template:Dhr to TemplateStyles


I have tested this in the sandbox and it appears to work properly, but since it is such a fundamental template I want to get community consensus before migrating it. —Beleg Âlt BT (talk) 14:02, 30 May 2024 (UTC)Reply

You'll find someone somewhere has been using it instead of em-dashes inside link markup, which means it'll break if you change it to use TemplateStyles. I still   Support doing so, of course, but we have way way too much baggage to imagine any such change to go without breaking something. Xover (talk) 17:41, 30 May 2024 (UTC)Reply
Yeah, hacky stuff is guaranteed to break eventually, so I'm not worried if this is what does it :D —Beleg Âlt BT (talk) 17:42, 30 May 2024 (UTC)Reply
I don't think I got it right, did you really mean someone used {{dhr}}, a spacing template, to replace an emdash? — Alien333 (what I did & why I did it wrong) 17:43, 30 May 2024 (UTC)Reply
I think they just mean that there's a good chance that someone, somewhere, used {{dhr}} in a really weird and unpredictable way. —Beleg Âlt BT (talk) 17:44, 30 May 2024 (UTC)Reply
I was thinking {{rule}} for some reason, but, yeah, as Beleg sussed I was speaking more in the general sense. Assume that someone has abused any template in ways horrifying to anyone technically inclined, and plan accordingly. Xover (talk) 18:32, 30 May 2024 (UTC)Reply
+1   Support and good luck dealing with all the horrifying things you find along the way. —CalendulaAsteraceae (talkcontribs) 18:54, 30 May 2024 (UTC)Reply
Where are the test cases and such for us to look at? Without that, it's hard to identify known edge cases, or even determine what situations were checked. --EncycloPetey (talk) 18:59, 30 May 2024 (UTC)Reply
The test page for this template is located at Template:DoubleHeightRow/testcases (which is linked from the documentation page for Template:DoubleHeightRow) —Beleg Âlt BT (talk) 19:16, 30 May 2024 (UTC)Reply
Granted, but where can we see the results of the sandbox testing you say you performed? That's what I'm asking. There is no proposed code linked, and no demonstration of how the proposed code will work.   Oppose the introduction of secret code tested without public access to the results. --EncycloPetey (talk) 19:39, 30 May 2024 (UTC)Reply
Umm, not sure, but Template:DoubleHeightRow/sandbox contains code marked experimental and using Templatestyles, so I think this is it. — Alien333 (what I did & why I did it wrong) 19:41, 30 May 2024 (UTC)Reply
The proposed changes, as I said, are in the sandbox (which is located at Template:DoubleHeightRow/sandbox) and the demonstration of how it works is in the test cases page (which is located at Template:DoubleHeightRow/testcases). —Beleg Âlt BT (talk) 19:42, 30 May 2024 (UTC)Reply
Also, the code is hardly "secret", it's literally just copy-pasting some CSS from Template:DoubleHeightRow to Template:DoubleHeightRow/styles.cssBeleg Âlt BT (talk) 19:48, 30 May 2024 (UTC)Reply
Saying "the" sandbox usually means Wikisource:Sandbox. Thank you for providing links. In any situation like this, please do provide links instead of expecting everyone to have to go track down the relevant pages themselves, especially when you are proposing a change. And you did not tell anyone at the outset what change you were proposing or where to find the code. Please do not expect your audience to be mind readers. --EncycloPetey (talk) 19:53, 30 May 2024 (UTC)Reply
@EncycloPetey: In the context of a template "the sandbox" is usually going to mean the "/sandbox" sub-page. There's a common (cross-project) convention for templates that there are "/doc", "/testcases", and "/sandbox" sub-pages where these things live (and they're auto-linked from the documentation footer etc.). TemplateStyles stylesheets by convention live in "/styles.css", but the precise location should be manually documented (in /doc) using {{TemplateStyles|Template:Foo/styles.css}}. Similarly, any Scribunto (Lua) modules used should be documented with {{lua|Module:Foo}} (both create the visible banner in the top right area of the documentation page).
I'm guessing BT didn't specify tests and demonstrations etc. because moving it to use TemplateStyles should have literally zero visible effect (but for that massively annoying bug that the WMF seems to have no plan to ever fix, sigh): it is in itself a purely technical change that makes it easier to maintain. That they are asking for consensus here is because… well, first because, unlike me, BT is a super-nice person, of course :)… but also because technical contributors have been getting a lot of grief lately, and being tediously fastidious about getting community support first is a way to ameliorate that. Xover (talk) 05:50, 31 May 2024 (UTC)Reply
If it takes two paragraphs to explain something after the fact, then that explanation should have been provided at the outset. It should not be assumed that all members of the community know arcane technical details that specialists "just know". And providing links to locations for relevant viewing is always a courtesy, regardless of the kind of conversation happening. --EncycloPetey (talk) 14:20, 31 May 2024 (UTC)Reply

Proposal to merge replace one of the following with a redirect to the other: Template:Hidden text and Template:Phantom


These two templates are literally identical, can we please merge them before scope creep causes them to diverge? —Beleg Âlt BT (talk) 19:28, 30 May 2024 (UTC)Reply

  SupportCalendulaAsteraceae (talkcontribs) 20:04, 30 May 2024 (UTC)Reply
  Support (and this should not be controversial). Xover (talk) 05:22, 31 May 2024 (UTC)Reply
  Comment What would be the point of merging the two templates? Why not just pick one to be replaced by a redirect to the other? --EncycloPetey (talk) 14:57, 31 May 2024 (UTC)Reply
... that's just the same thing with different wording —Beleg Tâl (talk) 15:26, 31 May 2024 (UTC)Reply
No, it isn't. Merging is deletion of one item, moving the other to its location, deleting, then undeleting so that the edit histories are merged. Merging includes the merging of edit histories, not the simple deletion/replacement of one item. --EncycloPetey (talk) 15:44, 31 May 2024 (UTC)Reply
Oh, lol. To clarify: I am proposing to merge the functionality of these templates via redirecting one to the other so that they are both the same template. I do not remotely care at all whether their edit histories are also merged. —Beleg Tâl (talk) 16:55, 31 May 2024 (UTC)Reply
Then this isn't a proposed merge. It's a proposal to replace one of two items with a redirect, without telling us which one will be replaced with a redirect and which one will be kept. Nothing is actually being merged.
Your statement "I do not remotely care at all whether their edit histories are also merged" is very troubling, as it shows a blatant disregard for copyright attribution requirements central to all Wikimedia projects. I suggest reading up on w:Wikipedia:Merging before proceeding. --EncycloPetey (talk) 17:53, 31 May 2024 (UTC)Reply
I would assume that the edit history would be maintained under whichever title is redirected to the other. Not to be pedantic, but copyright is inapplicable to functional elements presented in their simplest expression. I don't think there is anything at all that could be subject to copyright protection here. BD2412 T 02:08, 1 June 2024 (UTC)Reply
Yeah, otherwise the implication is that any replacement of a page with a redirect is a copyright violation, it would seem —Beleg Tâl (talk) 15:24, 10 June 2024 (UTC)Reply
  Support merge/redirect to Template:Hidden text. Even under the hood, these are functionally exactly the same thing. As to the merge target, I prefer the name that offers the more straightforward description. BD2412 T 01:36, 1 June 2024 (UTC)Reply
Yes, I agree that {{Hidden text}} is the better name. —Beleg Tâl (talk) 15:23, 10 June 2024 (UTC)Reply

Badge edit error on Wikidata


Does anyone here know why badge editing on Wikidata is currently not displaying the image or name of the badge to be selected? Currently I'm only getting the badge's item number when editing. Sample image shown at right. --EncycloPetey (talk) 17:45, 31 May 2024 (UTC)Reply

I can confirm this is happening to me too, so unlikely to be client-side. Phabricator appears to be down atm but I think this should be raised there. —Beleg Tâl (talk) 17:53, 31 May 2024 (UTC)Reply
This is most likely due to T366236, and I'm guessing the fix for it will go out in this week's deployment train (in which case it should hit some time today). --Xover (talk) 09:21, 3 June 2024 (UTC)Reply

Announcing the first Universal Code of Conduct Coordinating Committee

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language


The scrutineers have finished reviewing the vote results. We are following up with the results of the first Universal Code of Conduct Coordinating Committee (U4C) election.

We are pleased to announce the following individuals as regional members of the U4C, who will fulfill a two-year term:

  • North America (USA and Canada)
  • Northern and Western Europe
  • Latin America and Caribbean
  • Central and East Europe (CEE)
  • Sub-Saharan Africa
  • Middle East and North Africa
  • East, South East Asia and Pacific (ESEAP)
  • South Asia

The following individuals are elected to be community-at-large members of the U4C, fulfilling a one-year term:

Thank you again to everyone who participated in this process and much appreciation to the candidates for your leadership and dedication to the Wikimedia movement and community.

Over the next few weeks, the U4C will begin meeting and planning the 2024-25 year in supporting the implementation and review of the UCoC and Enforcement Guidelines. Follow their work on Meta-wiki.

On behalf of the UCoC project team,

RamzyM (WMF) 08:15, 3 June 2024 (UTC)Reply

PDF Page:s not loading


I’ve been having this problem on-and-off over the past week or so, and it doesn’t seem to be limited to one computer (I’ve tried other public computers). The Page:s of an Index:….pdf will sometimes load, but then sometimes won’t load, and when they don’t load the “Image” tab will give a “Too Many Requests” error. The actual PDF (on Commons) loads fine. This happens with multiple PDFs. TE(æ)A,ea. (talk) 22:21, 3 June 2024 (UTC)Reply

I am having the same issue, although it seemed better this morning. MarkLSteadman (talk) 23:19, 3 June 2024 (UTC)Reply

Tech News: 2024-23


MediaWiki message delivery 22:34, 3 June 2024 (UTC)Reply

Index CSS applying to mediawiki layout


In Index:Eggless recipe book for cakes, cookies, muffins, and desserts.djvu, a table { width:100%; } is causing the index info table to take full width and wrap around.

I think that index CSS should not change the way the site displays, only the content, but is that possible?

For width, it's not that bad, but if someone had something like td { background-color:red; }, it would be a bit more problematic. — Alien333 (what I did & why I did it wrong) 06:39, 8 June 2024 (UTC)Reply

This appears to only apply to ProofreadPage layout, not Mediawiki.
Also, I guess we could just use classes for that instead of targeting elements. — Alien333 (what I did & why I did it wrong) 10:07, 8 June 2024 (UTC)Reply
That's a limitation of the TemplateStyles extension, that the CSS will affect anything in the article (and the index info table is part of the index's article text), which is why one should always give elements one wants to style a class (see guidance at Help:Page styles#Classes_and_IDs). Arcorann (talk) 11:53, 8 June 2024 (UTC)Reply
Yes, I know. (I didn't do that index, just stumbled on it). — Alien333 (what I did & why I did it wrong) 11:55, 8 June 2024 (UTC)Reply

File:Original recipes of good things to eat.djvu


On Commons File:Original recipes of good things to eat.djvu shows as 2,038 × 3,125, 200 pages (16.89 MB) on Commons, but Wikisource shows as 0 × 0 (16.89 MB). I am wondering what is the issue. Xeverything11 (talk) 18:22, 9 June 2024 (UTC)Reply

It's a problem we often have these days, you have to purge it on commons (there's a purge clock gadget to do it).
I did it, it should work now.— Alien333 (what I did & why I did it wrong) 18:47, 9 June 2024 (UTC)Reply

Tech News: 2024-24


MediaWiki message delivery 20:20, 10 June 2024 (UTC)Reply

The final text of the Wikimedia Movement Charter is now on Meta

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Hi everyone,

The final text of the Wikimedia Movement Charter is now up on Meta in more than 20 languages for your reading.

What is the Wikimedia Movement Charter?

The Wikimedia Movement Charter is a proposed document to define roles and responsibilities for all the members and entities of the Wikimedia movement, including the creation of a new body – the Global Council – for movement governance.

Join the Wikimedia Movement Charter “Launch Party”

Join the “Launch Party” on June 20, 2024 at 14.00-15.00 UTC (your local time). During this call, we will celebrate the release of the final Charter and present the content of the Charter. Join and learn about the Charter before casting your vote.

Movement Charter ratification vote

Voting will commence on SecurePoll on June 25, 2024 at 00:01 UTC and will conclude on July 9, 2024 at 23:59 UTC. You can read more about the voting process, eligibility criteria, and other details on Meta.

If you have any questions, please leave a comment on the Meta talk page or email the MCDC at

On behalf of the MCDC,

RamzyM (WMF) 08:45, 11 June 2024 (UTC)Reply

Page status selection fails on change


If I need to change the page status without saving it fails as follows:

Changing Non-proofread to Proofread and then to Problematic or, vice versa, cannot be a simple change. I have to save, close and retry again.

I tried the same steps in fr.Wikisource where it works as it should. I am using Firefox only for such tests. — ineuw (talk) 21:59, 12 June 2024 (UTC)Reply

I'm not sure I understand what your problem is, can you detail, please? — Alien333 (what I did & why I did it wrong) 11:32, 16 June 2024 (UTC)Reply

Files missing machine-readable data


Hi all,

The categories…

…have a bit of a backlog that it would be nice if the community helped out with. The two overlap so it's not quite as bad as at first glance (889 + 675), but it's still enough that it's a "dip in, do a few" kind of task that's easy work if enough people help out. Xover (talk) 08:47, 16 June 2024 (UTC)Reply