Wikisource:Scriptorium

by A and C

SpBot archives all sections tagged with {{section resolved|1=~~~~}} after 3 days and sections whose oldest comment is older than 30 days.

Proposals

WS:PP and protection for validated works

I quote:

The vast majority of documents hosted by Wikisource are not meant to evolve or be edited, since Wikisource collects material that has been published in the past. Wikisource hosts these published documents without corrections (including any typographical errors or historical inaccuracies). Once a page has been fully proofread, no further changes are necessary and the page should be protected.

These pages should contain the template {{locked}}.

The issue is that actually, we don't protect validated works, and for a good reason: we can never be sure that a work is "fully proofread"; someone can always have missed something, and so on. As evidence of our not doing that: Special:WhatLinksHere/Template:locked is essentially empty. Furthermore, pages protected under this provision were unprotected 12 years ago in line with present practice. These two paragraphs look like a vestige of the early years of copypasting PG and calling it a day. (I am not talking about featured works, which are the paragraphs below those I cited; but of validated works in general.)

I think these two paragraphs should be removed. So: a) does anyone disagree? and b) does anyone think this warrants a formal proposal? If no one answers yes to either of these questions, I'll try and remove it next week.Given this discussion itself turned into the proposal, that's about moot. — Alien  3
3 3 11:18, 10 July 2025 (UTC)

Even if the page has been validated against the scan, there is the potential to potentially add links to other works and authors within the text or. perhaps, more controversially change the styling, e.g. convert tables using CSS. There is the also the potential to address accessibility issues such as adding alt text to images or fixing layout decisions that break screen readers. Lastly, there might be issues with the conversion to ebooks for download which might require fixes as well. Given the document is an official policy document, not merely guidance or proposed, I would think it should go through a formal proposal to update. MarkLSteadman (talk) 13:56, 10 July 2025 (UTC)

 Support

Yes, the paragraphs should be removed, but I can understand the sentiment - the issue is that 'validated' is too low a bar for locking something - at a minimum it just means that each page has been looked at twice (at PGDP their final texts will have been proofread 3 times, formatted twice, and then assembled by a post-processor, and even then errors creep through). Qq1122qq (talk) 15:05, 10 July 2025 (UTC)

 Support Indeed, those paragraphs should be removed (and the section on featured works amended slightly). I am sure we have all seen works which have been properly validated where things have sneaked through, and frankly, there are some works maked as validated which haven't even been properly proofread. And also, doesn't that go against the whole wiki idea ? -- Beardo (talk) 13:05, 11 July 2025 (UTC)

 Support removing those paragraphs as above. —CalendulaAsteraceae (talk • contribs) 18:32, 11 July 2025 (UTC)

 Support as per all above reasons. Arcorann (talk) 02:36, 12 July 2025 (UTC)

 Support --Jan Kameníček (talk) 08:58, 12 July 2025 (UTC)

Given the "should this be a proposal" discussion turned into a proposal, I've moved it into this section. — Alien  3
3 3 14:48, 12 July 2025 (UTC)

 Support--Jusjih (talk) 04:27, 3 August 2025 (UTC)

 Comment Where else in our policies do we say: "Wikisource collects material that has been published in the past. Wikisource hosts these published documents without corrections (including any typographical errors or historical inaccuracies)" so that we can point newcomers to that fact as policy? --EncycloPetey (talk) 04:51, 3 August 2025 (UTC)

Deleting author pages with populate

I can't find any page that clearly lists our requirements for Author pages. I'm going to suggest a new one, despite that. Instead of just tagging a page with Populate, we delete them. That simplifies some discussions, like Author:Herod Antipas and Author:Marcus Antonius, who may or may not have extant writings. Others, like Author:Anne do have a Works About section, but are they really authors if no one can identify even one work they wrote? That should go to a portal page. There's a number that should be improved: Author:S. E. Birrell should actually list known works, since they were created for Punch/Volume 148/Index to link to.

Since we decided that an author without English works available for transcription should be deleted, I'd point out that many of these may be in that list, e.g. Author:Isaac Commelin, an obscure Dutch author whose EN Wikipedia page lists no English titles.

I am not suggesting that we suddenly delete every author in Category:Authors with no works, but it could be an easy clean up project, and I'd say actually listing a work available in English is a low but useful bar for an author page.--Prosfilaes (talk) 22:09, 10 August 2025 (UTC)

I think as long as there is at least one scan hosted here or on c: that we can include with {{ssl}}, then it's worth keeping because that serves the basic function of a library by at least pointing someone to a work that can be read. And when it comes to non-English authors, a page should really only be created if someone is willing to put forth the effort to provide a local translation. If someone really wants to introduce to the world a freely-licensed English translation of something by Isaac Commelin, then that's lovely. Otherwise, I agree that this is a sensible proposal. —Justin (koavf)❤T☮C☺M☯ 22:15, 10 August 2025 (UTC)

All I'm asking is that someone list a work, even without scan. As for translations, we had a long discussion on Wikisource:Proposed_deletions/Archives/2025#Author:Ivan_Rakovskyi.--Prosfilaes (talk) 00:40, 11 August 2025 (UTC)

I'm open to this idea, but would like to hear additional opinions before supporting it strongly. --EncycloPetey (talk) 22:23, 10 August 2025 (UTC)

The general principle (that is, going through that list and either populating or deleting) seems good to me. And {{populate}} has indeed been applied much too widely for sudden deletion. 3k pages is quite a backlog, though, especially considering that proper author research is time-consuming; so I wouldn't call that an easy clean up project. As we've seen in various discussions, answering the question "are there English texts by this author in PD?" is hard. So that's a general support from me but we'd need to discuss further the details of organisation (e.g. among others: how deletion is requested: individually with {{sdelete|G5}}? individually on WS:PD? in a single round trip at WS:PD?). — Alien  3
3 3 22:44, 10 August 2025 (UTC)

Part of my goal is that we don't necessarily need to ask "are there English texts by this author in PD?". It's good that we do, but the creator of the page should do it.Prosfilaes (talk) 00:40, 11 August 2025 (UTC)

I was expecting to have objections to that, but come to think of it, I don't really. I just can't think of a case of author page with no indications of contribution to works in scope, that it would actually benefit us to keep. So I agree. — Alien  3
3 3 13:44, 11 August 2025 (UTC)

Bot approval requests

• See Wikisource:Bots for information about applying for a bot status
• See Wikisource:Bot requests if you require an existing bot to undertake a task

Repairs (and moves)

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

See also Wikisource:Scan lab

Ancient India As Described in Classical Literature move request

Can someone move Ancient India As Described in Classical Literature to Ancient India as Described in Classical Literature (correctly case of 'as')? Thank you! Prosody (talk)

@Prosody: Done. I also moved the subpage to use arabic numerals instead of roman while I was at it. --Xover (talk) 09:05, 29 July 2025 (UTC)

Index:Mental Health (Public Safety and Appeals) (Scotland) Act 1999 (repealed) (ASP 1991-1 qp).pdf

Please move to Index:Mental Health (Public Safety and Appeals) (Scotland) Act 1999 (repealed) (ASP 1999-1 qp).pdf ToxicPea (talk) 00:23, 1 August 2025 (UTC)

Done --Jan Kameníček (talk) 06:32, 1 August 2025 (UTC)

Patrick Lyon book move request

Please move Index:CB0129560326.pdf to Index:CB0129560326 The narrative of Patrick Lyon, who suffered three months severe imprisonment in Philadelphia gaol; on merely a vague suspicion, of being concerned in the robbery of the Bank of Pennsylvania: with his remarks thereon.pdf. It is a far better and more descriptive name. Blahhmosh (talk) 22:27, 5 August 2025 (UTC)

I suggest you create a move request for the file on commons first. ToxicPea (talk) 22:47, 5 August 2025 (UTC)

+1 to that. Ping when the file has changed name, then I can do the whole mess. — Alien  3
3 3 23:04, 5 August 2025 (UTC)

As they say, the index here needs to reflect the name on Commons. But the index name doesn't really matter - it is the name of the work once it has been transcluded that is most important. But I would recommend not having such a long name. I think that "The narrative of Patrick Lyon" would be enough. -- Beardo (talk) 23:56, 5 August 2025 (UTC)

Other discussions

{{ls}}

A while back, I asked what the rules are regarding ſ and {{ls}}, and how authoritative is the the style guide statement:

For phonetically equivalent archaic English letter forms (e.g. ſ, ꝛ), a template (e.g. {{Long s}}) is generally desirable to track and maintain flexibility for the display of such characters.

This discussion is here. It involved debating things back and forth quite a bit, but ended on the final word:

Our practice is to take the style guide seriously. [...] Some readers (myself included) prefer displaying the original orthography of long s, and there is no reason not to enable it for them, if some contributor is willing to enable it for them. Although I do not know about anybody who would be actively searching throughout the Wikisource for occasions to apply the ls template, generally such contributions cannot be prevented. @User:Jan.Kamenicek

Today I tried to switch ſ to {{ls}} in Slavery, a poem, and @User:EncycloPetey undid it, scolded me, and told me I "misunderstood the policy". Eievie (talk) 19:05, 4 July 2025 (UTC)

From the discussion you linked to: "...its usage is recommended, but not required. So if somebody does not use it, nobody forces them to do so, and they can work without the template." --EncycloPetey (talk) 19:07, 4 July 2025 (UTC)

From the cited Style Guide section: "...the character should simply be entered," which indicates there are situations where the long-s can be entered without using the template. --EncycloPetey (talk) 19:09, 4 July 2025 (UTC)

Both of those quotes are taken out of context.

So if somebody does not use it, nobody forces them to do so, and they can work without the template. (At the same time when somebody applies it, it must be accepted.)

That's talking about not messaging a user and saying "Using ſ is wrong and you should be using the template instead."

For phonetically equivalent archaic English letter forms (e.g. ſ, ꝛ), a template (e.g. {{Long s}}) is generally desirable to track and maintain flexibility for the display of such characters. However, in those cases where the archaic form is necessary (e.g. a work that is comparing letter forms or satirizing archaic styles), the character should simply be entered.

In this poem, ſ is phonetically equivalent to s.

Eievie (talk) 21:07, 4 July 2025 (UTC)

This is an issue that has long divided the community, which is why the policy page says "generally" and not "always". And the first quote in your reply was most certainly not out of context. --EncycloPetey (talk) 21:36, 4 July 2025 (UTC)

There is a great difference between "it is permitted to use the character without the template" (which is true), and "it is not permitted to improve a transcription by replacing the character with the template" (which is false). I note also that the discussion on the Index talk page supports implementing {{ls}} in this work. In this circumstance, reverting Eievie's edits would seem to be highly inappropriate. —Beleg Tâl (talk) 21:19, 4 July 2025 (UTC)

The Index Talk page first asks "long-s or regular-s", then a reply (paraphrasing) "I am not against it, using the template, but not going to do it", then a third editor favors long-s without mentioning use of a template, then you replied favoring use of a template. Only two of four editors favored use of the template, and only two of the four even said anything about the template. With a 50/50 split, it is not clear that the discussion supports implementation with a template. --EncycloPetey (talk) 21:31, 4 July 2025 (UTC)

50/50 split between support and non-oppose is more than plenty and you know it. You are clearly out of line on this one and your pedantry isn't fooling anyone. —Beleg Tâl (talk) 21:48, 4 July 2025 (UTC)

The long-s character was inserted by one of the four editors involved in the discussion. The template was added months later (today) by someone not involved in any way with the discussion or the proofreading and validation of the work. I have restored the pages to the state they were in. If you believe that the original discussion favored using the template, we can ask the four editors who were involved to weigh in explicitly, for/against. But clearly the editor from the discussion, who changed the regular-s into long-s, did not opt for the template. --EncycloPetey (talk) 22:09, 4 July 2025 (UTC)

That is completely irrelevant. This is a communal project. Eievie's edits were consistent with the discussion. Your actions were inappropriate and uncalled-for. It is behaviour like yours that drives good editors away from Wikisource. —Beleg Tâl (talk) 22:27, 4 July 2025 (UTC)

The actions of editors who participated in the discussion are irrelevant? The opinions of people who participated in the discussion are irrelevant? Really? --EncycloPetey (talk) 23:07, 4 July 2025 (UTC)

The fact that the person who added the template was not actively involved in the discussion is irrelevant. I notice you also did not participate in the discussion, and yet you took it upon yourself to enforce a decision you weren't even part of (and which, for the record, is contrary to the discussion in question). —Beleg Tâl (talk) 00:43, 5 July 2025 (UTC)

Admins support communal decisions whether they participated in making the decision or not. It's part of what admins do. --EncycloPetey (talk) 15:14, 5 July 2025 (UTC)

What decision ? There wasn't a communal decision to that effect. -- Beardo (talk) 15:49, 5 July 2025 (UTC)

@Eievie A general note on the authority of Wikisource:Style guide/Orthography (not on the use of the template in this specific index): the entirety of it is mostly one user's opinion 14 years ago. As Jan already told you in the discussion you linked to yourself: It has been added to Wikisource:Style guide/Orthography ages ago (in 2011) and I did not find any relevant community discussion that would actually approve it. I do not remember on coming across any such discussion myself. So in general avoid taking that for the gospel. (To EP & BT: maybe cool down a bit? Aggressiveness doesn't help with anything.) — Alien  3
3 3 23:23, 4 July 2025 (UTC)

Rather than being one person's opinion, it was put together as a statement of what our practice was at the time. We were particularly having issues with the ff, fl and ct ligatures, which some editors were insistent on adding, despite breaking searches. At the time, we had no formal approval processes. However, if the community had had problems with this page of the Style Guide, then we would have amended it or canned it when it was published. The fact that it has required minimal editing since its initial inception indicates that it should now be regarded as definitive guidance and major changes will require an RFC. Beeswaxcandle (talk) 03:23, 5 July 2025 (UTC)

It is almost never preferable to have the character directly inserted instead of the template. The only reasons I can think of are if you are transcluding too many templates on one page, causing some technical issue or if you absolutely should display the direct character, e.g. for comparison with the standard version. —Justin (koavf)❤T☮C☺M☯ 01:29, 5 July 2025 (UTC)

'@Koavf@EncycloPetey@Eievie@Beleg Tâl@Beeswaxcandle@Alien333 For what it's worth . . . I can see little point in transcribing the long 's' as a long 's', and frankly I don't do so, and I rarely contribute to transcriptions where it is being used. I have been known to remove transcribed long 's's on validation, especially when whoever's done the proofread isn't consistent with how they've applied it (mixed use of various templates and direct insertion) or the validation is more challenging in other ways (NLS chapbooks!). However, if I do this, I do it to the whole work. If anyone changes 's' to long 's' on random pages of a work that I've done, I will and do revert such changes.

1. In the original work, the long 's' obviously makes transcription and proofreading more difficult (although the OCR is getting better) especially in poorer quality scans where it can be difficult to differentiate the long 's' from an 'f' (or the OCR thinks it's a 't', or misses it altogether ('she', 'the', 'he' is a particular favourite)). However, the long 's' is in the printed original and I can't do anything about that.
2. The language, sentence structure and paragraph length in most pre-20th century works is usually richer and more complex (I'm being generous here) than the 'Janet and John' (or whatever the American equivalent is) level of writing more often encountered today, especially on websites. On the assumption that WS does what it does in order to make texts available to read, reproducing the long 's' really gets in the way of reading what may already be challenging enough.
3. If you are going to transcribe them, at least set the system default so that it doesn't display them. If you're so invested in the long 's' then you can find the 'on' switch, rather than inflicting them on everyone.
4. I haven't ever come across an example where I've thought 'oh look, there's a long 's' that isn't phonetically equivalent to an 's'.'
5. On screen the rendering of the long 's' is awful, particularly without serifs, and especially when italicised.

Chrisguise (talk) 08:42, 5 July 2025 (UTC)

That's the reason we have the template {{ls}}—so that the long s is there if you want it, and gone if you don't. And in mainspace, it defaults to gone. (It does make proofreading harder, I grant you that.) —Beleg Tâl (talk) 19:25, 5 July 2025 (UTC)

I'm in a similar boat to @Chrisguise. For example, although currently in hiatus, I am working on transcribing the first volume of The Gentleman's Magazine from 1731. The page scans and OCR of this are pretty awful, and so quite a lot of manual typing is involved. I am transcribing all types of s as s in all the pages I'm doing (which, across the 3 1/2 issues done so far is... all of them).

I can understand keeping the long s when there is some strong stylistic reason for doing so (for example, in [Byrne's Euclid from 1847], where the use of long s is conscious and deliberate) , but for the vast majority of pre-1800 works, the only reason the long s was used is that's what typesetting looked like at the time, and it is as pointless to replicate in a modern edition as the other typographical tropes of the time. The only purpose that the ls template serves in these cases is to make proofreading/validity reading basically impossible, and to reduce the potential pool of people who might want to work on what will probably already be quite a niche project.

I have my suspicions that the call to preserve the long s came from people who weren't used to reading pre-1800 texts and thought that it was somehow a 'special character' that needed to be kept like Þ in middle English.

I imagine this discussion will now subside until the next time someone complains about long s in 6 months time, when the arguments will repeat, as is traditional. Qq1122qq (talk) 22:56, 5 July 2025 (UTC)

@Qq1122qq, among others. I (also) dislike these ever-repeating discussions that Wikisource seems to end up in. Although I am not exactly sure what the result of this discussion is, could a short summary be added to the Template:Long s documentation, like the note that was added to Template:Old style, to at least attempt to stop the cycle repeating (as viciously)? Or is no such summary likely to be agreed upon? Regards, TeysaKarlov (talk) 01:28, 6 July 2025 (UTC)

@TeysaKarlov - please give your opinion - was it wrong for a user to change ſ to {{ls}} ? (@Duckmather, @CitationsFreak - what are you opinions on that ?) -- Beardo (talk) 02:16, 6 July 2025 (UTC)

@Beardo I think wrong is a bit of a strong word here. If we are talking specifically about Index:Slavery, a poem.pdf, I mildly preferred conventional "s" throughout. However, I don't think either @Duckmather or @Eievie did any real harm in modifying the conventional "s" characters (in Duckmather's case, given that they asked, and in Eievie's, given that the non-template long-s characters were then already there, and that the pages were validated). If you mean wrong more generally, then I think it depends a great deal on the circumstances. However, Wikisource practice/guidance aside, I think many editors are quite invested in both the indices they work on, and in Wikisource more generally, and so I think some sort of common courtesy should prevail (perhaps more so than a "be bold" mentality). Regards, TeysaKarlov (talk) 02:36, 6 July 2025 (UTC)

I've always thought that the text should generally match the text on the page (so that long S's and the single-character digraphs are used if they appear on the page). However, nine times out of ten, the long-S template should be used in these sorts of cases.

(I've also avoiding proofing a work because it's one of those cases where a normal S is used in the copy, and a long S is used in the source. Maybe I should get over that and proof it.) CitationsFreak (talk) 02:27, 8 July 2025 (UTC)

I think it would be very sensible to indicate in the documentation (either for the template, in the help page for formatting, or both) something relatively neutral: that there are good reasons both for replicating and for not replicating the exact style of 's' used, that it has been the source of some argument, and that both are being used successfully on the site. In general current practice would indicate that 'the person who makes the index gets to decide' is a good summary of current practice (there are issues with this and index abandonment, though - I've in the past worked on a project where someone declared that people should use 'long s', and then did no work on the project for years). FYI this is me giving ground, as my personal opinion is that there is no reason for the ls template to exist or be used :).

It's part of a wider discussion on what the point of WS is, and exactly how far we wish to be on the 'perfect transcription of both content and form' dial, along with topics like replication of page headers and footers, asterism styles, exact font sizes, exact typefaces, transcribing adverts/back matter, how to format TOCs and indices, etc. Qq1122qq (talk) 08:56, 9 July 2025 (UTC)

I think the problem with long s, is that it's not clear whether it should be treated as a variant glyph (like old style numerals, or serif vs non-serif fonts), or whether it should be treated as a separate character (like ß vs ss, or σ vs ς, or honestly s vs S). If it's a variant glyph, it should not be transcribed. If it's a separate character, it should be transcribed. Hence the controversy.

—That being said, I don't see why replacing either s or ſ with {{ls}} would be controversial, even in a completed Index. It provides the benefit of both positions without the downsides of either, and allows any user to access the text according to their preference. It seems to me that it can only be an improvement for someone to update a text to use {{ls}}. —Beleg Âlt ^BT (talk) 15:06, 10 July 2025 (UTC)

In the 'controversy' stakes it's hardly up there with the top 100 things that annoy me most in the world, but yes, the 'glyph or separate character' question is the cause of the issue.

My basic issue with {{ls}} is that its presence makes working with the source of a page painful, particularly if you are manually typing a text or trying to correct errors in a page that uses {{ls}}.

I don't get how people create texts that use it - do they manually paste in the {{ls}} every time an 's' appears, or do they do a search-replace operation after proofreading the page with 'normal' 's'?

Why not just use normal 's' anyway and use a couple of lines of Javascript to do the replacing if someone wants that style while reading the final text? Qq1122qq (talk) 16:03, 10 July 2025 (UTC)

When I use it, it's a manual paste in, yes. And I only have the patience for it if the work is relatively short. But if the work is already proofread, and someone wants to go through and add it, I don't see any problem with that. —Beleg Âlt ^BT (talk) 16:06, 10 July 2025 (UTC)

I agree with @TeysaKarlov, that the convention on Wikisource has tended to be to try to be considerate to the people who have already put time into proofreading, and this seems like a good approach. This doesn't seem to be documented at the moment, which could be why formatting disputes like this are brought up here. I think it would be a good idea to state this in the documentation, otherwise, how are new users expected to know this, especially as it's a very different approach from Wikipedia? Personally, I would also strongly support encouraging users to improve typography (including changing works to use {{ls}}) if they have checked on the index talk page, and there is either a consensus that's neutral on the issue or generally in favour, or if there is no response; if the proofreader(s) of a project don't want the formatting changed, then it should remain as it is. All that said, my main impression in this case is that @EncycloPetey's behaviour towards @Eievie and @Beleg Tâl is completely unacceptable and needs to be called out. This seems to be part of a pattern of behaviour that I don't remember from previous years: EncycloPetey – are you aware of the impression you're giving, and is everything ok? --Yodin^T 07:23, 6 July 2025 (UTC)

I'm not sure how to mention this without sidetracking the whole conversation, which I don't want to do, but this is part of a pattern of behavior. EncycloPetey seems to have a generalized issue with me making any edit to a book I'm not the main creator of. Eievie (talk) 17:19, 6 July 2025 (UTC)

I do have a problem with your over-bold, under-considerate approach to editing. I encourage other users to look at the pattern, timing, and proximity of your July 4 edits, which give the impression of being calculated to upset people, especially given previous patterns of editing on your part. --EncycloPetey (talk) 16:33, 8 July 2025 (UTC)

No, I am not aware of the impression I am giving, --EncycloPetey (talk) 16:33, 8 July 2025 (UTC)

If you look at my comment on your last admin confirmation discussion, I have outlined it for you —Beleg Âlt ^BT (talk) 13:17, 9 July 2025 (UTC)

I outlined the issues with this user's editing at Wikisource:Administrators' noticeboard#User:Eievie unilateral style changes, on which you did not comment at the time. --EncycloPetey (talk) 16:46, 9 July 2025 (UTC)

why bother commenting when "the admin is always right"? the imposing of admin positions, unsupported by a clear consensus, is a problem with other wikis which unfortunately is increasing here.--Slowking4 ‽ digitaleffie's ghost 02:07, 30 July 2025 (UTC)

Two more PDFs not parsing properly

I am getting a 0 x 0 size error for the following two files, and the Index pages associated with them are giving an "Invalid Interval" error. Purging / Refreshing in various forms has not solved the issues for me.

• File:Charles Dickens (a Critical Study) by George Gissing, 1898.djvu
• File:The Pigtail of Ah Lee Ben Loo.pdf

Can someone who knows how to fix the issue please help? --EncycloPetey (talk) 23:37, 19 July 2025 (UTC)

Isn't the first explicitly a DjVu and not a PDF? Note the second one looks to load properly for me now. MarkLSteadman (talk) 02:20, 20 July 2025 (UTC)

The first has had a problem for a few days now, as a lot of pages suddenly appeared in the orphaned pages list. -- Beardo (talk) 02:28, 20 July 2025 (UTC)

This looks like another 0x0 bug, which previously was PDF-specific. From experience, it disappears after a few days to a few weeks. — Alien  3
3 3 08:35, 20 July 2025 (UTC)

The first file seems correct now (pages 107 and 108 replaced again). • M-le-mot-dit (talk) 17:46, 20 July 2025 (UTC)

There is no issue rendering either file or the indices in my browser and I did not Purge or hard refresh the pages. —Justin (koavf)❤T☮C☺M☯ 14:11, 21 July 2025 (UTC)

... because, as I said, it's been a few days and now it's fixed itself. — Alien  3
3 3 16:02, 21 July 2025 (UTC)

Yeah, I'm just confirming it on my end. This is a classic problem of caching: what displays on one person's computer doesn't show up the same on the other's and it takes time for things to propagate. I thought I was just being nice and helpful. —Justin (koavf)❤T☮C☺M☯ 18:40, 21 July 2025 (UTC)

Ah, my bad then. I misunderstood. — Alien  3
3 3 19:21, 21 July 2025 (UTC)

Tech News: 2025-30

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

• The Translation Suggestions feature in the Content Translation tool now has another level of article filters added to the "... More" category. Translators who use the Suggestions feature can now select and receive article suggestions that are customized to geographical locations of their interest using the new "Regions" filter. [1]
• Administrators can now limit "Add a Link" to newcomers. The "Add a Link" Structured Task helps new account holders start editing, but some communities have requested the ability to restrict it to its intended audience: newcomers. Administrators can configure this setting within the Community Configuration feature.
• View all 29 community-submitted tasks that were resolved last week.

Updates for technical contributors

• For AbuseFilter editors on some wikis, it is now possible to filter edits based on the RevertRisk score of the edit being attempted. It is only populated if the action being evaluated is an edit. For more information, please see the ORES/AbuseFilter variables documentation.
• The Beta Cluster wikis have been moved from beta.wmflabs.org to beta.wmcloud.org. Users may need to update URLs in any tools, or in their password managers. Any related issues can be reported in the task.
• Detailed code updates later this week: MediaWiki

Meetings and events

• WikiCite 2025 will take place from 29–31 August, both online and in-person in Bern, Switzerland. The event's goals are to reconnect communities, institutions, and individuals working with open citations, bibliographic data, and the Wikidata/Wikibase ecosystem. Registration is open and the call for proposals will be announced soon. [2]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 23:42, 21 July 2025 (UTC)

Hotcat on Index Pages

The Hotcat gadget doesn't show up for me in some namespaces, mainly the Index namespace. It was working fine for me a few days ago and it works in mainspace so I feel like something is wrong here. ToxicPea (talk) 21:23, 23 July 2025 (UTC)

Nothing local, at any rate, given we just copy commons'. My bet is that HotCat only activates on pages with the wikitext contentmodel; whereas index pages are not exactly wikitext, but a wrapper for that. Anyhow, though, from what I've seen (though I have by no means been focusing on categorisation) it appears that we tend to not categorise indexes much, and rather do that on the corresponding mainspace pages. — Alien  3
3 3 21:41, 23 July 2025 (UTC)

But it worked fine a few days ago. see the edit history of Index:Sea Fisheries (Shellfish) Amendment (Scotland) Act 2000 (ASP 2000-12 qp).pdf for example. What would be causing the gadget to stop activating now? ToxicPea (talk) 21:50, 23 July 2025 (UTC)

There were a few edits recently, notably one that added contentmodel safeguards. Probably they didn't take into account ProofreadPage. Are there error or warning messages when you open your browser console? — Alien  3
3 3 00:17, 24 July 2025 (UTC)

Left an upstream report on commons at [3]. — Alien  3
3 3 00:28, 24 July 2025 (UTC)

I do get the following error

Uncaught TypeError: Cannot read properties of undefined (reading '2')

at createEditors (index.php?title=MediaWiki:Gadget-HotCat.js&action=raw&ctype=text/javascript:3240:69)

at setup (index.php?title=MediaWiki:Gadget-HotCat.js&action=raw&ctype=text/javascript:3246:18)

at HC.start (index.php?title=MediaWiki:Gadget-HotCat.js&action=raw&ctype=text/javascript:3340:5)

at api.php?format=json&callback=HotCat.start&action=query&rawcontinue=&titles=Index%3AAmended_Standing_Order_2025-01_for_the_District_of_Maryland.pdf&prop=info%7Crevisions&rvprop=content%7Ctimestamp%7Cids&meta=siteinfo&rvslots=main&rvlimit=1&rvstartid=15218249:1:12 ToxicPea (talk) 01:54, 24 July 2025 (UTC)

Why would you need it to work in the Index namespace? We typically do not want Work, Subject, or Date categories added to Index pages, so it's probably better if it does not function there. --EncycloPetey (talk) 03:39, 24 July 2025 (UTC)

Sometimes Wikiproject categories are added to indexes. — Alien  3
3 3 09:04, 24 July 2025 (UTC)

Also, I don't think that (we typically do not use this feature for X purpose) is a sufficient reason for (this feature should be left nonfunctional).

Also, the Index template explicitly contains a field for categories, so leaving HotCat nonfunctional does not actually deter the addition of categories, but rather it only makes it more inconvenient for people who do have reasons for adding categories. —Beleg Âlt ^BT (talk) 14:24, 24 July 2025 (UTC)

Isn't the whole point of HotCat that it's more convenient? I don't see how this is a good reason to leave the feature nonfunctional. ToxicPea (talk) 15:28, 24 July 2025 (UTC)

Multivolume works with overlapping editions.

I'm creating Index pages for The Liturgical Year, which consists of fifteen volumes published between 1867 and 1903. I noticed, however, that the scans at Commons were a mix of different editions. I also noticed that some of the earlier volumes have second editions that were published before the first editions of later volumes. Do we have any precedent for dealing with overlapping editions in other multivolume works? (I ended up finding scans of each volume's first edition, so this question is mostly theoretical). —Beleg Âlt ^BT (talk) 17:19, 25 July 2025 (UTC)

No helpful precedents that I can think of. Typically we try to avoid that situation. It's one reason I have not scan backed one work in particular that I'd really like to, because it's a two-volume work with more than a dozen different editions I've located, yet nowhere have I found both volumes from the same edition. But there are also editions where the volumes from the same edition were published in different years, and that can be difficult to verify when it occurs. --EncycloPetey (talk) 21:38, 25 July 2025 (UTC)

We have a fair number of these around. We have a fair number of mixed US / UK editions as well "deluxe" vs. "standard" editions. In general if the editions are similar, it's not the biggest problem... MarkLSteadman (talk) 01:25, 26 July 2025 (UTC)

Hmm, I think mixed editions are a problem, more so than overlapping editions. But not so much of a problem to be worth fussing over lol —Beleg Âlt ^BT (talk) 13:48, 28 July 2025 (UTC)

Tech News: 2025-31

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Weekly highlight

• The Community Tech team will be focusing on wishes related to Watchlists and Recent Changes pages, over the next few months. They are looking for feedback. Please read the latest update, and if you have ideas, please submit a wish on the topic.

Updates for editors

• The Wikimedia Commons community has decided to block cross-wiki uploads to Wikimedia Commons, for all users without autoconfirmed rights on that wiki, starting on August 16. This is because of widespread problems related to files that are uploaded by newcomers. Users who are affected by this will get an error message with a link to the less restrictive UploadWizard on Commons. Please help translating the message or give feedback on the message text. Please also update your local help pages to explain this restriction. [4]
• On wikis with temporary accounts enabled and Meta-Wiki, administrators may now set up a footer for the Special:Contributions pages of temporary accounts, similar to those which can be shown on IP and user-account pages. They may do it by creating the page named MediaWiki:Sp-contributions-footer-temp. [5]
• View all 21 community-submitted tasks that were resolved last week.

Updates for technical contributors

• Detailed code updates later this week: MediaWiki

Meetings and events

• Wikimania 2025 will run from August 6–9. The program is available for you to plan which sessions you want to attend. Most sessions will be live-streamed, with exceptions for those that show the "no camera" icon. If you are joining online to watch live-streams and use the interactive features, please register for a free virtual ticket. For example, you may be interested in technical sessions such as:
  • Temporary Accounts: Enhancing privacy for our unregistered editors
  • Building a Sustainable Future for Wikimedia Contributors
  • A dozen visions for wikitext!
  • Coordinate Across Stakeholders with the Product and Technology Advisory Council
• The MediaWiki Users and Developers Conference, Fall 2025 will be held 28–30 October 2025 in Hanover, Germany. This event is organized by and for the third-party MediaWiki community. You can propose sessions and register to attend.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 00:26, 29 July 2025 (UTC)

Science-Gossip TOC Help

I've recently finished the initial proofreading of Hardwicke's Science Gossip, Volume I (Main|Index). Now I'm starting the transclusion, but the book doesn't have a TOC (only an Index), so I decided to make one.

My current plan is that the navigation built into the {{header}} templates will go from section to section (e.g. Zoology to Entomology) and the TOC will list all distinct entries in the original order. I've written up a sample TOC in my Sandbox for one-quarter of the full book (January–March) and would like some feedback before I start making pages.

Some specific questions:

• I do understand that this makes a long TOC. Should I condense it? Any techniques useful for handling TOCs for periodicals?
• Some articles (usually very short notes) do not have titles. In these cases, I took the liberty of making up a basic, relevant title. An example is "Blue Flowers Becoming White" and "Corrosive Sublimate" being made-up titles for the third and fourth entries on this page. Is this approach okay? Should I indicate in some way that the title is not original?
• There are some short, filler articles scattered throughout the book. I denoted them as "Interludes." Any better ideas for handling the URL organization? And how can I make the displayed text more distinct in the TOC?

If you have advice, techniques, or examples of how I could format it better, please let me know!
—SpikeShroom (talk) 02:52, 31 July 2025 (UTC)

From some advice I've received elsewhere, I'm now planning to have the main page list each issue in the periodical (January-December), and on each of those pages will be the TOC for that month's issue. I've created a mock-up of this TOC in my Sandbox as well.

—SpikeShroom (talk) 02:33, 6 August 2025 (UTC)

Global ban proposal for Chealer

Hi community, this is to notify that there is a Global ban proposal for User:Chealer on Meta. Please participate at m:Requests for comment/Global ban for Chealer. Thank you. CyrusHickman (talk) 05:45, 31 July 2025 (UTC)

Noting that this is a formal process notification at all sisters the User has edits on. The User has made only two edits here, back in 2009. Beeswaxcandle (talk) 07:35, 31 July 2025 (UTC)

TemplateStyles failing to work within wikilinks

Tracked in PhabricatorTask T200704

I know this has been brought up before, but I'm having trouble finding the Phabricator ticket for it. Could someone link me to the Phabricator ticket? TemplateStyles does not work when the first call is inside a wikilink. —Beleg Âlt ^BT (talk) 14:12, 31 July 2025 (UTC)

Update: found - phab:T200704 —Beleg Âlt ^BT (talk) 14:24, 31 July 2025 (UTC)

By the way, there are workarounds. None of them especially appealing, but may be workable depending on the specific situation. One non-obvious such is to put a dummy (empty) invocation of the relevant template in the header in Page:-namespace, or even manually import the template's stylesheet (the extension tag works anywhere in wikitext, not just in Template:-namespace templates). It's if the first invocation of a given template on a wikipage is inside wikilink markup that this breaks, so any fudging or adjustment that puts that first invocation on the page outside the wikilink will fix it. Really annoying and unpretty, and completely impenetrable for newcomers, but it does seem like nobody is willing to touch this problem until the Great Parser Unification is complete (<voice mode="dripping with sarcasm">any day now, I'm sure</>). Xover (talk) 15:49, 31 July 2025 (UTC)

Yes - in fact the reason I was asking this question, was so that I could put a link to phab:T200704 in a comment next to a workaround dummy template invocation :) —Beleg Âlt ^BT (talk) 15:52, 31 July 2025 (UTC)

Upcoming Deployment of the CampaignEvents Extension

Hello everyone,

The Campaigns Product Team is proposing to deploy the CampaignEvents extension to all Wikisource, including this Wikisource, during the week of August 25th.

This extension is designed to help organizers plan and manage events, WikiProjects, and other on-wiki collaborations - and to make these efforts more discoverable.

The three main features of this extension are:

• Event Registration: A simple way to sign up for events on the wiki.
• Collaboration List: A global list of events and a local list of WikiProjects, accessible at Special:AllEvents.
• Invitation Lists: A tool to help organizers find editors who might want to join, based on their past contributions.

Note: The extension comes with a new user right called "Event Organizer", which will be managed by administrators on this Wikisource. Organizer tools like Event Registration and Invitation Lists will only work if someone is granted this right. The Collaboration List is available to everyone immediately after deployment.

The extension is already live on several wikis, including all Wikipedia, Meta, Wikidata, and more ( See the full deployment list)

If you have any questions, concerns, or feedback, please feel free to share them on the extension talkpage. We’d love to hear from you before the proposed date.

Thank you! Udehb-WMF (talk) 15:49, 31 July 2025 (UTC)

Author tool?

Isn't there a tool/button I can enable so that I can highlight a name, and then automatically append the [[Author:X Y Z|X Y Z]] formatting to it? Fundy Isles Historian - J (talk) 20:11, 31 July 2025 (UTC)

You can apply [[Author:NAME|]] to get the same result, and there is a button to apply the brackets and pipe. So if there isn't a specific tool, it should be easy to add. --EncycloPetey (talk) 20:28, 31 July 2025 (UTC)

True, but it would be nice to have a tool that inserts the whole code at once. I have been thinking about that already too, and now, after this inquiry, I tried adding the following to my common.js:

// Add custom CharInsert entries
window.charinsertCustom = {
 "Insert": '[[Author:+|]]'
};

Unfortunately, after saving it the part [[Author:+|]] changes into [[Author:+|+]] for some reason, and as a result it does not work as intended. Could this be solved somehow? --Jan Kameníček (talk) 20:39, 31 July 2025 (UTC)

I suspect that whatever is converting the pipe into pipe-plus-text is interacting with the code. The [[|]] can be applied by first highlighting the word, then hitting the button. This new code should be possible to apply using the exact same syntax. --EncycloPetey (talk) 20:55, 31 July 2025 (UTC)

Got it. The trick is a slash between the first two square brackets, i. e. [/[Author:+|]]. So the code to add to one's common.js is:

// Add custom CharInsert entries
window.charinsertCustom = {
 "Insert": '[/[Author:+|]]'
};

@Fundy Isles Historian - J:: Open your common.js and add the above code there and save the page. That should add the code to your CharInsert box below the editing window. --Jan Kameníček (talk) 21:25, 31 July 2025 (UTC)

PS: Just to make clearer what EncycloPetey already mentioned: Note that when editing a page, you do not have to repeat the name after the pipe. It is enough when you save a page with [[Author:NAME|]], you do not have to write [[Author:NAME|NAME]]. --Jan Kameníček (talk) 21:30, 31 July 2025 (UTC)

(To be precise, it looks like [[Author:Name|]] until you save the page; right before writing in the database, the code is replaced by [[Author:Name|Name]] during the post-save transforms. So if/when someone later looks at the source code, they'll see [[Author:Name|Name]].) — Alien  3
3 3 22:55, 31 July 2025 (UTC)

BTW: it might be good to have it in the general CharInsert box so that every new user does not have to be finding out how to add it. --Jan Kameníček (talk) 23:16, 31 July 2025 (UTC)

It's already there in the Wiki markup section. Xover (talk) 06:34, 1 August 2025 (UTC)

Ah, I have missed that completely :-) --Jan Kameníček (talk) 06:43, 1 August 2025 (UTC)

Thanks, also appreciate knowing about the "piping" issue to save time. Related note, image in thumbnail here...is there some way to tell OCR to only scan inside a selected square or to quickly/easily cut off those margins from the opposing flap/version/whatever? Trying to proofread some more of Index:Campobello Tourist Booklet 2.pdf but it's difficult without OCR. Fundy Isles Historian - J (talk) 22:47, 1 August 2025 (UTC)

• Fundy Isles Historian - J: The easiest way I’ve found for this case is to use the tool here; after loading in the image, you can tell the OCR machine to generate text only within a specified box. TE(æ)A,ea. (talk) 17:38, 4 August 2025 (UTC)

New transclusion tool

I've made (with @Ignacio Rodríguez) a webservice to ease transclusion, running at https://wstranclude.toolforge.org/. Normally, it should be able to figure it out with just the titles of the index and the mainspace page, and the template that marks the titles of subpages (with user confirmation, of course). It's also available in french and spanish (other translations are welcome). Examples: the subpages of Poems (Becker) and The Fate of the Jury (edit summary format has changed since, but the logic is the same). The code and its documentation are at https://gitlab.wikimedia.org/toolforge-repos/wstranclude. Pages are created with the account WSTranscluderBot. — Alien  3
3 3 22:22, 2 August 2025 (UTC)

WikiCite 2025

Hi all, apologies for cross-posting.

I would like to share that the programme for WikiCite 2025 (taking place August 29–31) is nearly finalized. This year marks the reboot of WikiCite, a conference dedicated to sources, references, and their metadata within the wikiecosystems.

We are currently working to incorporate the remaining community proposals. The jury will be meeting again in less tha two weeks to review the final round of suggestions for online talks.

Additionally, our sponsor has asked me to prepare a white paper on the future of WikiCite — so all perspectives are welcome. Don’t forget, there are prizes available for the best talks and proposed activities. Alexmar983 (talk) 08:45, 4 August 2025 (UTC)

Browser-specific issues with font size templates

Tracked in PhabricatorTask T401137

I'm observing two separate but maybe related cases, when using {{smaller block/s}}/{{smaller block/e}} and when using {{smallrefs}}, where when Mediawiki produces <p> elements in the contents of these templates, the font size gets reset to the default for those elements when viewed on Safari on iPhone. Desktop Firefox or Chrome-based browsers don't appear to have this problem, even in responsive mode. Both cases can be seen in Ancient India as Described in Classical Literature/Section 2, {{smaller block/s}} at the top and {{smallrefs}} at the bottom of the page. In the former case, a <p> element is generated thorugh normal line breaks for text paragraphs that are neither the first or last in the block, in the second case <p> elements are generated by the use of {{pbr}} to produce line breaks in footnotes. Prosody (talk) 15:48, 4 August 2025 (UTC)

Actually scratch that, it's reproducible with other browsers when using en.m.wikisource. Prosody (talk) 15:54, 4 August 2025 (UTC)

I'm not seeing the issue in Firefox on my desktop. But then I'm not sure what you mean by "when using en.m.wikisource" --EncycloPetey (talk) 17:13, 4 August 2025 (UTC)

@EncycloPetey: https://en.m.wikisource.org (as opposed to https://en.wikisource.org) is the url for the mobile website. It's the default shown to mobile users, but is also viewable on desktop. It's managed by mw:Extension:MobileFrontend; see comment below on how it does that. The url to test the problem would be [6]. — Alien  3
3 3 17:23, 4 August 2025 (UTC)

It's the fault of mw:Extension:MobileFrontend. To be precise, it enforces the font-size settings with rems, which is an effing bad idea, knowing that those are independent from the parent elements; as time passes, it looks more and more like the Web team just likes forcing arbitrary styles onto wiki content. To be precise, the compiled CSS contains:

.mf-font-size-clientpref-small .mw-body p,
.mf-font-size-clientpref-small .content p {
  font-size:1rem;
}

It comes from [7]; which also changes the line-height while it's at it. That code really ought to only target the containers. Left phab:T401137; however, this being "maintained" by the Web team (or whatever it's just split into), which are the same people responsible for the V22 and QuickSurveys debacles, we probably won't get any answer for a long while; if we ever get an answer that isn't IDHT corporatespeak, that is. Why, why do they always feel such a need to overwrite styling of page content? Sigh. — Alien  3
3 3 17:21, 4 August 2025 (UTC)

@Alien333 Thank you for taking the time to dive deep into that. Prosody (talk) 19:14, 4 August 2025 (UTC)

There are reasons, and at least some of them are good reasons. For mobile, in particular, they had to do a lot of transformation in MobileFrontend in order for even enWP to work at all on mobile. This was at a time when mobile readership jumped from 2% to 80% over a few short years, and there was no chance—zero—the communities would adapt all their content (templates etc.) to be mobile friendly in any reasonable time (we still haven't). Also, for non-techy (i.e. almost all) users on a project like Wikipedia, it's not enough that the software (MediaWiki) gives you a blank canvas in the middle of the screen. They need the consistency of display and behaviour that styling like that involved here attempts to bring (hence also why VisualEditor is a priority).

That being said, I also really wish they'd stop trying to style content in detail like that. On the Wikipedias it doesn't much matter beyond personal preference, but here where we actually have to reproduce arbitrarily complex formatting the constraints and impositions are downright maddening. For mobile, especially, the existence of MobileFrontend and its transformations makes it impossible to ever make the normal site mobile friendly. Xover (talk) 06:54, 5 August 2025 (UTC)

Hmm. Ok, the differences between the paragraphs is just due to p-wrapping. When you put a block element (which is what templates like {{smaller block/s}} use) on the same line as the text, the MediaWiki parser disables p-wrapping (because the old parser is a really dumb regex based one). So for a three-paragraph block of text you get a markup structure like <div class="wst-smaller-block">first para<p>second para</p>third para</div>. The styles from MobileFrontend target that <p>…</p> with high specificity and so overrides the styles we've applied in {{smaller block/s}}. With the template on a separate line you instead get <div class="wst-smaller-block"><p>first para</p><p>second para</p><p>third para</p></div> and thus consistent (even if incorrect) styling.

P-wrapping is pretty much impossible to get rid of in practice (long story, just trust me) so the first order of business is to always put block templates like {{smaller block/s}} and {{smaller block/e}} (yes, the end tag too) on its own line. That will get you consistent formatting, and it's a good idea on desktop too.

That MobileFrontend overrides our block styling templates is annoying but not fatal. Mobile is a limited interface for many reasons, so losing some formatting fidelity there is not the end of the world, and MobileFrontend will eventually go away. In the mean time we can look into raising the specificity ("priority") of the styling in our own templates so the MobileFrontend styling no longer overrides them. That's a bit scary because they have to play nice with all the other black box magic MobileFrontend applies, and higher specificity makes it harder for us to override when we need to (think nested templates). I also really don't relish having to write long hyper-specific selectors in all our templates because that's going to be an absolute hell to maintain over time. But we may have to, at least for the most common templates that MobileFrontend messes with (i.e. font size), since different text sizes can be pretty important semantically and ease of reading. Xover (talk) 07:39, 5 August 2025 (UTC)

Hmm. This going to take some figuring out…

All our standard font-size templates use percentage-based sizes. Percentage units are relative and based on the parent element, whatever that parent element is. So assuming a default browser font size of 16px, a {{fine block}}, which sets the font size to 92%, will get an effective font size of 14,72px. If you put a {{fine}} inside that fine block you'll get an effective font size of 16px * 0,92 * 0,92 or 13,54px. That's well and good, but it also means that if we try to override MobileFrontend by also targetting the p tags the relative sizes will compound. The {{fine block}} will reduce the font size to 92% of 16px and every nested p tag will reduce it by a further 92%, leading to a net font size of 0,92 * 0,92 = 84,6%. It will also make the font size inconsistent based on whether p-wrapping happened or not. These issues will affect all the length units that are 1) relative and 2) based on the parent element (i.e. em, ex, etc.).

An alternative approach is to use root-relative length units, primarily rem. Since these are relative to the root element size (i.e. whatever is set for the html element, usually the browser's default font size of 16px), setting font size to .92rem on both the block element from {{fine block}} and the p element added by p-wrapping will set both to root element font size * 0,92 and an effective font size of 13,54px. If the user changes their default font size in their browser to, say, 24px the effective font size will be 22px. The downside is that if you have a word that's smaller inside of a fine or smaller block and try to use {{fine}} inside a {{fine block}} everything will be 92% of the browser default. In order to actually get that word to be smaller you would have to use a different font size template like {{smaller}}. Smaller is 83%, so 16px * 0,83 = 13,2px vs. 13,54px, which is close enough in practice.

These are fundamentally different approaches and each with their pros and cons, both in terms of use for normal contributors and in terms of the technical stuff (how hard is it to make them behave predictably etc.). For example, I am guilty of using constructs like {{x-larger|{{xxxx-larger|Chapter I}}}} to get the font size I want. This is bad practice but it's very convenient. Being able to express "this paragraph has smaller text, and that word inside the paragraph is even smaller" is perhaps a better example, and it is inherently relative for most people (some very few will think of it like absolute font sizes). However, learned behaviour from or existing templates aside, I'm not immediately certain whether most people's mental model of it will be "smaller than the surrounding text" or "a smaller font size template than the surrounding text". The former suggest parent element relative font sizes, while the latter suggests root-relative font sizes.

Absolute font sizes are, I think, not an option for us; not least because we would have to maintain those in the face of browser changes, skin changes, manually maintaining ratios between every other absolute font size, not to mention accessibility issues, and so forth.

This is very messy and I am not at all certain how best to deal with it. To a degree we're now paying for not doing a better job at picking a sustainable approach back when the project forst started, and for leaving it up to each contributor and each text to pick something that "looks right" for them in their browser rather than enforcing more semantic and uniform sizing. On the other hand, we've made this work reasonably well so far (not, I hasten to add, perfectly: there are both accessibility and other problems in this area that we've just ignored), and it's the WMF's intrusion into formatting of content that is making things really messy just now.

My immediate inclination would be to look into using root-relative units (i.e. rem) to resolve most of this (along with a reminder to put block templates on a separate line), but that would change 1) existing formatting and 2) change the mental model contributors need to relate to. Neste font-size templates are not common, but not unheard of, so it would be A Job™ checking existing texts. Contributors mental model can be harder, but I'm not sure how much of it is learned from how the templates have worked historically and how much is inate. Xover (talk) 08:46, 5 August 2025 (UTC)

Aha, or we can (probably) work around it by forcing the font-size for <p>...</p> elements to be inherit. I've added that to the relevant stylesheet and it's fixed the obvious problem in the above example, but I'm not entirely certain it won't have unintended consequences. Xover (talk) 11:53, 5 August 2025 (UTC)

@Xover:

• MobileFrontend will eventually go away - eventually as in it's planned to sunset? Or just the hope that one day it'll disappear? And, one way or another, replaced by what?
• using constructs like {{x-larger|{{xxxx-larger|Chapter I}}}} to get the font size I want - use case for {{fsx}}? it's what I usually use for Big™
• Relative font sizes are a very good thing; they let content adapt to their surroundings. For {{sm|{{sm|a}}}} to display as a not a wouldn't make sense. Or, say someone has bad eyesight and sets font-size:120% on .mw-parser-output or whatever; using rems will throw that away. From my perspective, we made the good and reasoned choice of letting font-size changes cascade down; and they've made the weird one of breaking that inheritance. It doesn't necessarily mean we should follow.
• My immediate inclination would be to look into using root-relative units - idem; could you explain why? I don't really see. Absolute units have many problems, and I don't see what they would actually bring.
• not entirely certain it won't have unintended consequences - possible one: user CSS that for some godforsaken reason changes individual p tag font-size with no more specificity; though that's arguably a low-profile and relatively unimportant one (compared to what it avoids; common templates breaking down)

— Alien  3
3 3 23:25, 5 August 2025 (UTC)

@Alien333: I am following this discussion with interest, and agree with your points about relative font size.

Re user CSS that for some godforsaken reason changes individual p tag font-size with no more specificity, as a frequent CSS-customizer I think that's squarely in the realm of "play stupid games, win stupid prizes". Nevertheless, in case of this or other issues, it might be good to document the workaround at {{font size block}}.

Maybe we should also document any other weird things we're doing as MW workarounds? Transcluding stylesheets to work around phab:T200704 comes to mind. —CalendulaAsteraceae (talk • contribs) 06:19, 6 August 2025 (UTC)

@CalendulaAsteraceae: Yes please… No, wait, that's not emphatic enough. Let me try again.

Yes please do document all such hacks, exhaustively.

The hours I've spent trying to figure out why someone once did something a specific way is insane. If you ever wonder why I add code comments like this, now you know. If it took me that much time and effort to figure out then some poor schmuck will need the information at some point even if others find it obvious or uninteresting. For on-wiki hacks around MediaWiki quirks it's especially important: most of the literally dozens of weird hacks implemented in our site CSS when I started cleaning were no longer needed or didn't work due to subsequent changes in MediaWiki.

I don't think one central page for all of them is a good idea (document it where it will be needed and can be found), but things like task T200704 might merit something in Wikisource:-space. Xover (talk) 06:45, 6 August 2025 (UTC)

@Xover: I've imported Wikisource:TemplateStyles from enWP and added a bug section. (Cc @Beleg Tâl, we have an enWS-specific process page now.) —CalendulaAsteraceae (talk • contribs) 20:51, 6 August 2025 (UTC)

@Alien333: rem is still a relative length unit, it's just relative to a predictable reference (they're root-relative). Your example of user CSS on .mw-content-text is contrived: people with bad eyesight (like me) do not fiddle with MediaWiki-specific CSS as a first approach, they raise their web browser's base font size to something larger than 16px. By using units relative to that you get predictable sizes that scale with the user's preferred minimum text size. Parent-relative units (like em and ex) also scale, but they scale much more unpredictably and relative to some random font size someone else set. In MediaWiki, for example, 1em is initially 1rem * 0.875. So my carefully chosen 16px minimum font size is now ignored in favour of a 14px base font size.

The compounding effects of parent-relative units are also problematic and non-intuitive. The canonical example is <span>outer <span>inner</span> outer</span>. If you use CSS like span {font-size: 1.6em} you'll get surprising results (the outer span will have a font size of 25,6px the inner 40,96px). That's what we ran into with this workaround: if we targeted the <p>...</p> from p-wrapping in addition to the <div>...</div> we emit ourselves (to override the skin's font size) then p-wrapped paragraphs would have gotten a compounded font size. You also never know what the parent-relative font sizes will be because there can be arbitrary adjustments in between. Quick, without breaking out a calculator, how big is {{xl|{{xxxxl|…}}}} going to be? What if they occur inside a {{fine}} block? Which has its font size adjusted from Index CSS because it's part of a table?

But mostly it's a matter of mental model. Nowhere outside of Wikisource (for historical reasons) and PowerPoint do you think of the size of your text as "one larger than the previous text". Everywhere else you think in terms of an absolute font size. If you go into a paragraph of 14pt text and set the font size of a word to 18pt you expect to get 18pt, not some weird relative calculation. On the web everything has to be relative, but being relative to a fixed reference is a lot easier to mentally model than being relative to an arbitrarily deep and complex tree of also relative sizes.

All of that is not to say I think we should go to root-relative sizing in these templates (that's a completely different calculation). But there are some very good reasons we might want to consider that, and some other alternatives (like Codex size tokens, or the standard CSS size keywords). That we found a simple workaround for the problem @Prosody identified means we can kick that can down the curb a ways, but eventually we'll need to deal with it.

PS. MobileFrontend is being actively killed, but the timeline is more or less infinite as of yet. It now depends on most sites' content being adapted for mobile, and especially enWP's. But there's very little incentive to do so due to the existence of MobileFrontend, and mobile is so contrained an environment that you need a level of discipline in designing for it that "the community" (an arbitrarily large and undisciplined comittee, in effect) just doesn't have.

PPS. Hmm. I wonder if it's possible to request MobileFrontend be turned off for a project? It would be interesting to get rid if it for enWS and then start working actively on making all our content responsive. I think Vector 2022 is pretty responsive to begin with, but I imagine MobileFrontend hides quite a few sins there too. Xover (talk) 08:27, 6 August 2025 (UTC)

Yeah, admittedly my example on a user changing font size was a bit far-fetched.

relative to a predictable reference - but a reference that is constant in the whole document; hence pretty much absoluete

You also never know what the parent-relative font sizes will be because there can be arbitrary adjustments in between. - I suppose this is also the question of mindsets, but to me that is a good point. If I wanted to do eg {{smaller block|{{Page:Whateverfile.ext/42}}}}, I expect what's inside a smaller block to be smaller than if it was just dumped outside. Using rems just nullifies many templates; to me that's the counter-intuitive here.

we found a simple workaround for the problem - more of a hack than anything else. I feel like the one thing we should be doing is (figuratively) shake/yell at the web team until they leave the content alone

MobileFrontend is being actively killed - to what degree is actively? ORES has been "being deprecated" for nearly two years and a half. And MobileFrontend is even less deprecated than that (not even slapped with a tag). Around the wikimedia ecosystem, "actively killed" has an awful tendency to mean "Yeah, it's broken, but we slapped a deprecated marker on it so it's fine", while still leaving something broken in prod. Thanks for the info, though.

It would be interesting to get rid if it for enWS and then start working actively on making all our content responsive - we can already kinda test. That is, just remove the .m in the url and see what happens on a narrow screen. — Alien  3
3 3 11:16, 6 August 2025 (UTC)

MobileFrontend isn't deprecated (which has specific meaning). They're just removing stuff from it when they can, and everyone (so far as I know) want to get rid of it eventually. There's no plan beyond that that I am aware of.

On rem/em: yes, "conceptual model" is key here. There's pros and cons to both, and no matter our main approach we will always need to use the other in some places. But right now our perception of the two approaches is coloured by the conceptual model currently implemented: we're used to that so that seems more logical until we really think about it. But it does have rather a lot of cons too, so it is worth thinking about even if we end up keeping the status quo in the end. Xover (talk) 11:27, 6 August 2025 (UTC)

Tech News: 2025-32

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

• Editors can now enable the User Info card. This feature adds an icon next to usernames on history pages and similar user-contribution log pages. When you tap or click on the icon, it displays data related to that user account such as the number of edits, reverted edits, blocks, and more. It's part of a broader project to make it easier for moderators to evaluate account trustworthiness. The feature can be enabled in your global preferences, and later this week it will be available in local preferences. [8]
• Everybody is invited to share comments on Collaborative Contributions, a project recently launched by the Connection team. The project aims to create a new way to display the impact of collaborative editing activities (such as edit-a-thons, backlog drives, and WikiProjects) on the wikis. Post your comments on the project talk page. [9]
• Administrators can now define the default block duration for temporary accounts. To do that, they need to create a page named MediaWiki:Ipb-default-expiry-temporary-account and use a value defined in MediaWiki:Ipboptions. This allows administrators to easily block temporary accounts for 90 days, which is functionally equivalent to an indefinite block. The advantage of this solution is that it does not clutter Special:BlockList. More documentation is available. [10]
• View all 27 community-submitted tasks that were resolved last week.

Updates for technical contributors

• Gadgets can now include .vue files. This makes it easier to develop modern user interfaces using Vue.js, in particular using Codex, the official design system of Wikimedia. Codex icons can be loaded through the gadget definition. The documentation has examples. For user scripts that use Vue.js, an API module now exists to load Codex icons. [11][12]
• Module developers can now use a Lua interface to simplify the preparation of Lua modules for translation on Meta-Wiki. This improvement makes it easier for translators to find and edit module strings without dealing with raw Lua code. It helps prevent mistakes that could break the module during translation. Module developers and translators are invited to watch the demo video, read more about translatable modules to understand how it works, refer to Meta-Wiki's Module:User Wikimedia project for example usage, and share their feedback on how well it addresses the challenges in their workflow. The interface still has some performance issues, so it should not be used in widely used modules yet. [13]
• Developers of external tools that connect to Wikimedia pages must set a user-agent that complies with the user-agent policy. This policy will start to be more strongly enforced in August because of external crawlers that are overusing Wikimedia's resources. Tools that are hosted on Wikimedia's Toolforge or Cloud VPS will not be affected by this for now, but should still set a user-agent. More technical details are available, and related questions are welcome in that task.
• Parsoid Read Views is going to be rolling out to some smaller Wikipedias over the next few weeks, following the successful transition of Wikivoyages and Wiktionaries to Parsoid Read Views. For more information, see the Parsoid/Parser Unification project page. [14]
• Detailed code updates later this week: MediaWiki

Meetings and events

• Wikimania 2025 will run from August 6–9. The program is available for you to plan which sessions you want to attend. Most sessions will be live-streamed, with exceptions for those that show the "no camera" icon. If you are joining online to watch live-streams and use the interactive features, please register for a free virtual ticket. For example, you may be interested in technical sessions such as:
  • Wikimedia’s knowledge infrastructure in a changing internet: Establishing sustainable pathways for content reuse
  • Wikifunctions is coming soon to a wiki near you!
  • Shaping the Future of Wikipedia’s Reader Experience
  • Making Wikipedia More Readable: What Comes Next

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 03:40, 5 August 2025 (UTC)

Note: the userinfo card is of course broken (shows 0 for lots of non-0 stuff) because it relies on the (for now at least) wikipedia-only growth api, and apparently developers just didn't bother checking on non-wps. (Not that much of a problem, knowing it's only in beta features.) Just don't believe the 0s for at least thanks received & given, reverted edits, and articles (wp vocab of course) created. — Alien  3
3 3 23:29, 5 August 2025 (UTC)

Auto header failing to parse Illustrator field from Index page

See Three Hundred Æsop's Fables/Preface. This page (and all? other subpages of this volume) use the auto header populated from the Index page. The illustrator field is correct on the Index page, but is incorrectly displayed in the auto headers as "illustrated by [[Author:Harrison Weir|Harrison Weir]]" —Beleg Âlt ^BT (talk) 13:52, 7 August 2025 (UTC)

Fixed. The root cause is that MediaWiki:Proofreadpage header template is fed the index fields, including links and all; and so giving those to the "regular" {{header}} parameters would give us broken links, like you saw. Currently we're feeding everything to override_* parameters, which is meh. Perhaps, that should use a module, and the module should parse the links in the index field, to extract the page names, and then feed those to the regular parameters, putting the display texts in the *_display parameters. — Alien  3
3 3 00:01, 8 August 2025 (UTC)

I got annoyed at this whole override business so I finished the module Calendula had started in may: Module:Proofreadpage header template. I've implemented some cleanup of links that PRP gives the header template, into sanitised page name & display arguments. As a bonus, gets rid of the bold due to the PRP-added selflink in {{{section}}}, and adds support for {{{section-author}}}, {{{section-translator}}} and {{{section-year}}}.

To test it (admins only):

1. to be able to do the "preview with this template" thing in MWspace, import/copy the code at User:Alien333/.js one way or another, eg type importScript('User:Alien333/.js') in your browser console. (Note: don't import that page permanently, it's a sandbox and content may change)
2. edit the source of MediaWiki:Proofreadpage header template
3. without saving, replace the code by {{#invoke:Proofreadpage header template|pp_header}}
4. insert in the last input field a test page's name, I put some tests at Sandbox (had to use the mainspace redirect, not the WSspace page)
5. preview (with the new, script-added, small button)

If all goes well, it should show a functioning header that looks like this. — Alien  3
3 3 23:15, 10 August 2025 (UTC)

ooh, section-author and section-translator is nice :) — is there any chance it can be made to support the full range of Module:Header/attribution data (including modified parameters like "section-author2"), preferably without needing to make further changes when that module is updated? If so, I might be able to start using the auto header feature :D —Beleg Âlt ^BT (talk) 14:02, 12 August 2025 (UTC)

tl;dr: yes, but in a different format. See details. (Oopsie, hadn't subscribed to this thread.)

So, on the question of *1, *2, and so on. The issue is that to be passed from the pages tag to MediaWiki:Proofreadpage header template, that key must be in MediaWiki:Proofreadpage index data config.json with header=true (and hidden=true for the section thingies to not show them in the form). W can't add every author* parameter.

However, what I've implemented in the module can take multiple links in one argument, and from that use the appropriate *1, *1_display, *2, *2_display, and so on. So eg you could do <pages index="Sandbox.djvu" include="6,9-42" header="1" section-author="[[Author:A|B]] and [[Author:C|D]]"/>, and assuming Index:Sandbox.djvu's author field contained [[Author:E|F]], in collaboration with [[Author:F|G]], the header call made would be approximately:

{{header
|title=Sandbox
|author1=E
|author1_display=F
|author2=G
|author2_display=H
|section=[whatever this page's name is]
|section-author1=A
|section-author1_display=B
|section-author2=C
|section-author2_display=D
}}

which gives:

Same goes for translator, illustrator, and mostly editor (section-editor didn't make sense to me). I have limited it to the parameter you can actually add in index config. But if we want to allow everything it's just going to be a matter of adding some lines to MediaWiki:Proofreadpage index data config.json. In that case, we'd also want to directly use Module:Header/attribution in MediaWiki:Proofreadpage header template; saves us the duplication (though the json duplication is inevitable).

So bottom line is yes, my code can support the whole range of Module:Header/attribution. Currently only accepts parts of it, but that's up for discussion. — Alien  3
3 3 02:42, 14 August 2025 (UTC)

Oh, and about adopting automatic headers: I definitely recommend. To me, the nicest thing is how it just updates itself for everything, including notably previous and next fields. Suppose you messed up transclusion and swapped two subpages's names. You can just move the individual offending subpages and it fixes itself; as opposed to having to gruelingly update the backlinks and section parameters in headers everywhere. — Alien  3
3 3 02:49, 14 August 2025 (UTC)

Oh absolutely. If I didn't spend most of my time working on projects with headers like The University Hymn Book/God reveals his presence, I'd be using auto headers all the time :D —Beleg Âlt ^BT (talk) 13:51, 14 August 2025 (UTC)

TitleCase Addon Problem

Years ago I installed the Addon "TitleCase" into my Firefox Browser. (I think it was recommended by user Billinghurst). It allowed me to change the case of text simply by selecting it in the edit page and the choosing the option for the required case. It was very useful even though I only use it occasionally.

This now does not work as it used to.

It used to directly change the case of the text in the edit page, now nothing happens in the edit page, but on the preview page or the image page the line of text appears in the desired case, but often I am unable to copy or past it from there.

It is frustrating when I want to use it. I was wondering if anyone else has seen this issue? or is it already a known problem or maybe an issue with the Addon? Are there any alternative Addons that I could replace it with? My PC runs windows 11 with Firefox v141.02 Thanks ~~ Sp1nd01 (talk) 21:09, 7 August 2025 (UTC)

CSS not aligning cols as expected

I'm missing something at Page:Astronomy for Everybody.djvu/245, which uses Index:Astronomy for Everybody.djvu/styles.css (class satellites.saturn) but the columns that should be right aligned are not. --EncycloPetey (talk) 01:05, 9 August 2025 (UTC)

• EncycloPetey: The . in the class name caused an issue; I’ve renamed it to satellites_saturn and the columns now align correctly. TE(æ)A,ea. (talk) 02:00, 9 August 2025 (UTC)

  Thanks. --EncycloPetey (talk) 02:14, 9 August 2025 (UTC)

Index:Material Culture of the Iglulik Eskimos.djvu

It seems that the file at commons was deleted as still in copyright in its home country. That leaves this index with no file to call up. Can the source file be uploaded here in wikisource ? Or should the index and associated pages be deleted ? -- Beardo (talk) 18:10, 9 August 2025 (UTC)

It can be hosted here, maybe a commons admin can see about grabbing the deleted file. 18:27, 9 August 2025 (UTC) MarkLSteadman (talk) 18:27, 9 August 2025 (UTC)

I've asked the closing admin for a temporary undelete so we can xwiki it. Success rate has historically been 50/50 on that, so we may have to go through a full UDEL request or figure out the original source and redownload from there. Xover (talk) 18:31, 9 August 2025 (UTC)

It was nominated for deletion there by ShakespeareFan00; not sure why they did not take care of the localization after the file got deleted. --Jan Kameníček (talk) 18:38, 9 August 2025 (UTC)

See d:Q134420472 for sourcing. ShakespeareFan00 (talk) 18:44, 9 August 2025 (UTC)

That file is not publicly accessible, either at GBooks or HT. Which means we don't have anything right now. (Direct link to the deletion discussion, to spare someone else the looking: c:COM:Deletion requests/File:Material_Culture_of_the_Iglulik_Eskimos.djvu.) — Alien  3
3 3 20:08, 9 August 2025 (UTC)

I reuploaded the file locally with the original description from Commons. Please, fix it. And feel free to ask me directly for help in such cases in future. Ankry (talk) 20:55, 9 August 2025 (UTC)

Thank you. -- Beardo (talk) 21:11, 9 August 2025 (UTC)

Long vs Short Page title

Should the page titled Treaty between the United Kingdom of Great Britain and Northern Ireland and the Federal Republic of Germany on Friendship and Bilateral Cooperation be moved to its short title Kensington Treaty? ToxicPea (talk) 07:00, 10 August 2025 (UTC)

I'm not sure that's a good idea, especially knowing that the official title does not include the words "Kensington Treaty". Maybe shortening the country names, i.e. "Treaty between the UK and the FRG on Friendship and Bilateral Cooperation"? That would make it a more reasonable length, but not be exactly faithful either.

I'd say maybe just keep the current state: the page can be linked to with the short redirect, and apart from linking a long title does no harm. — Alien  3
3 3 22:52, 10 August 2025 (UTC)

I'm asking because most other treaties I can find here use their short name as the page title when they have one. ToxicPea (talk) 00:32, 11 August 2025 (UTC)

More eyes on undeletion proposal

Wikisource:Proposed_deletions#Undelete NYT funeral notices There are two concepts here that I believe were misapplied.

One is that funeral notices are copyrightable and that the copyright holder is the newspaper publishing them, and that any implied copyright would be renewed when the newspaper renewed their copyright. The text in question was [redacted as this was deleted for copyvio]. Funeral notices are paid advertisements, they are not obituaries, and they contain only facts, not the commentary found in an obituary. The rote form has not changed in 150 years. The funeral director fills out a standard form" [insert family name], [insert death date], father of … husband of … . Interment [insert cemetery]. To be eligible for a copyright you need creative elements, not rote facts. For a funeral notice, two people filling out the form would create identical text.

The second involves the Associated Press and whether the publisher or the creator is responsible for copyright renewals. The AP text may appear in over 100 different subscribing newspapers. In this case the question was whether the New York Times renewing the issue covers material created by the Associated Press. When discussing whether photographs by the Associated Press are in the public domain prior to 1977, the photo division of the Library of Congress determined that they were not because of this very issue. The Library of Congress hosts AP images from various defunct newspaper image morgues. See also the included opinion of C. Lindberg, who made the determination for Commons. RAN (talk) 19:08, 10 August 2025 (UTC)

@Richard Arthur Norton (1958- ) Please note that when something has been deleted for a copyright violation, it is not OK to repost that text. Please do not repost texts that have been deleted for copyvio. --EncycloPetey (talk) 21:32, 10 August 2025 (UTC)

What he wrote was not eligible for copyright and was deleted for no good reason. His undeletion rationale is correct and if those pages are what he says they are, they should be undeleted on that ground. —Justin (koavf)❤T☮C☺M☯ 21:51, 10 August 2025 (UTC)

The copyright issue is open to discussion. But if the community discussion result was "This is a copyvio", then reposting that deleted content, in multiple locations, prior to a new discussion reversing the decision, is not OK. --EncycloPetey (talk) 03:16, 14 August 2025 (UTC)

I didn't write that it was, but it's not a copyright violation and no one can assess if it as at the appropriate page without it being undeleted or someone pointing to where to read it. —Justin (koavf)❤T☮C☺M☯ 03:57, 14 August 2025 (UTC)

• This comes down to accepting, or not accepting the findings of the Library of Congress and their lawyers. It appears that we are contravening their opinion based on own non-legal opinions. Their finding were based on Associated Press images that the Library of Congress house on their website. The same copyright laws apply to both the images and the text. They have the image morgues from various newspapers as they were sold off or donated, when the papers closed. They have not received a takedown notice from the AP, so the AP appears to agree. --RAN (talk) 23:33, 14 August 2025 (UTC)

Tech News: 2025-33

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

• The WikiEditor toolbar now includes its keyboard shortcuts in the tooltips for its buttons. This will help to improve the discoverability of this feature. [15]
• The Product and Technology Advisory Council published a set of proposed experiments the Wikimedia Foundation can try to improve communication with community. Feedback on the proposals are welcomed until August 22 on this talk page.
• The search bar on the Minerva skin (mobile) has been updated to use the same type-ahead search component that is used on the Vector 2022 skin. There are no changes in search functionality but there are minor visual changes. Specifically, the close-search button has been changed from an "X" to a back arrow. This helps to distinguish it from the other "X" button that is used to clear any text. [16]
• Editors on some wikis will see a new toggle for "Group results by page" on watchlist, related changes, and recent changes pages. This is an A/B experiment that is planned to start on August 11, and will run for 3–6 weeks on the Bengali, Chinese, Czech, French, Greek, Portuguese, and Urdu Wikipedias. The experiment will examine how making this feature more discoverable might affect editors' ability to find the edits they are looking for. [17]
• View all 31 community-submitted tasks that were resolved last week.

Updates for technical contributors

• The multiwiki datasets of Unicode data have been moved to Category:Unicode Module Datasets on Wikimedia Commons, to follow the idea of "One common data source, multiple local wikis". Most wikis have been updated to use the Commons version. You can ask questions at the talkpage. [18]
• Lua code can add warnings when something is wrong, by using the mw.addWarning() function. It is now possible to add more than one warning, instead of new warnings replacing old ones. If you maintain a Lua module that used warnings, you should check it still works as expected. [19]
• Detailed code updates later this week: MediaWiki

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 23:29, 11 August 2025 (UTC)

Maintenance of categories populated from Wikidata

Many of our author categories are being populated from Wikidata through Module:Author/data. This works well until somebody changes the specific Wikidata item, e. g. by merging it into another item. Then the system gets broken, as happened with the item supplying author pages to the Category:Travelers as authors, which stayed unnoticed for 1 month. I suspect there can be more cases like that and so I would like to ask whether

1. it is possible to check all other categories whether their supply from WD is not broken, and
2. (more importantly) it is possible to change the system so that it does not get broken when a WD item is changed into a redirect.

-- Jan Kameníček (talk) 15:49, 13 August 2025 (UTC)

Page letters

Is there a setting for page numbers in the Index namespace that assigns lowercase letters to the pages? I have a volume where a section of pages are lettered following the main text of the book, but I find nothing in Help:Page numbers telling me how to do this. --EncycloPetey (talk) 23:16, 14 August 2025 (UTC)

The built-in styles allowed for numbers are: 'normal', 'highroman', 'roman', 'folio', 'foliohighroman', 'folioroman', 'beng', 'deva', 'tamldec', 'guru', 'gujr', 'telu', 'knda', 'mlym', 'orya', 'thai', 'arab', 'arabicjomml', 'arabicjommlmaghribi' and 'empty'. Styles like upper-alpha or lower-alpha would have to be added manually or via a request at phab:. —Justin (koavf)❤T☮C☺M☯ 00:37, 15 August 2025 (UTC)