Wikisource:Scriptorium/Archives/2024-05

From Wikisource
Jump to navigation Jump to search
Warning Please do not post any new comments on this page.
This is a discussion archive first created in , although the comments contained were likely posted before and after this date.
See current discussion or the archives index.

After creating a new author page, it used to be the case that a wikidata search link appeared in the upper right hand corner. It no longer does. Is this a deliberate change, or has something been broken? Chrisguise (talk) 15:10, 1 May 2024 (UTC)

@CalendulaAsteraceae: did one of your recent changes remove the PlainSister component from the header when there is no linked Wikidata page? —Beleg Âlt BT (talk) 15:39, 1 May 2024 (UTC)
Not sure. I did just fix the invocation in Module:Author so it shows the search link. —CalendulaAsteraceae (talk • contribs) 16:57, 1 May 2024 (UTC)

Purge options on File: pages

As part of efforts to overcome occasional issues with PDF's (and even more occasionally DJVU's) not displaying properly, I had activated some feature (can't remember which) that resulted in a 'purge' option appearing on WS file: pages (e.g. File:The complete poetical works of Percy Bysshe Shelley, including materials never before printed in any edition of the poems.djvu). I think it was in the 'page' dropdown. However, the 'purge' option / options now seem to have disappeared.

Apologies for the vagueness here but I'd only used this a few times so don't have a clear memory of where this option was and how it looked. I think there was a 'purge', 'hard purge' and 'null edit', as per normal pages, but I might be imagining this. Chrisguise (talk) 06:25, 2 May 2024 (UTC)

@Chrisguise: Go to "Preferences" then the "Gadgets" tab then check the box that says "Purge tab: Adds a "*" tab or a "Purge" option in the actions tab, which purges the page's cache when clicked." Мишоко (talk) 10:18, 2 May 2024 (UTC)
Thanks for the reply — I should have said that I have the 'purge tab' option selected.
I've tried deselecting the option, saving, then reselecting it. I shutdown my browser and restarted it but to no avail.
The only two things that I'm aware of that have changed recently are that my browser (Firefox) updated (but I don't think it's that, as the same problem occurs in Edge) and my laptop had a BIOS update (but I don't think it's that, as I've tried another make of laptop (testing both Firefox and Edge) and the same problem is there). Chrisguise (talk) 11:13, 2 May 2024 (UTC)
That gadget, as far as I know, doesn't add a button in the File: namespace. I personally use the clock gadget (around the bottom). — Alien333 (what I did & why I did it wrong) 12:54, 2 May 2024 (UTC)
Yes, you are probably right about the File namespace. The other option that should work mostly everywhere including in the File namespace is to just add ?action=purge at the end of the url. Мишоко (talk) 13:44, 2 May 2024 (UTC)
@Alien333 @Мишоко It didn't add this as a button, rather (assuming I'm remembering this correctly) it was an option on the 'page' tab that appears to the right of the 'Add local description' tab on the File: page. Chrisguise (talk) 14:15, 2 May 2024 (UTC)
Do you use Vector 2022 or 2010? What you are describing seems to be Vector 2010 behaviour. With Vector 2022 Purge, Hard Purge and Null Edit are not in a tab, they are on the right side of the page below Tools, Actions, Suscribe... I can see them now while I am at the Scriptorium, and in the Page and Index namespaces, but not in the File namespace. Мишоко (talk) 14:29, 2 May 2024 (UTC)
If you see a "Add local description" tab then you're viewing a file from Commons, and what you're seeing is just a local mirror. In order to purge the file you'll need to go to that file on Commons and use their purge gadget. On enWS you have a purge option in the "Page" menu (added by the default MoreMenu gadget) as well as in the "Tools" menu (that may or may not be visible as a sidebar, depending on whether you have docked it) in Vector 2022. Xover (talk) 14:38, 2 May 2024 (UTC)
@Xover@Мишоко@Alien333 The sequence I was trying to follow (and why this became noticeable) was, based on various posts elsewhere on here:—
  1. purge Commons file page
  2. purge WS file: page
  3. purge WS page:
I have been using Vector 2010 (the default setting) but have just switched to 2022, although this has made no difference to the issue in question.
I have just enabled the 'clock and purge' gadget and will see if that helps. Chrisguise (talk) 16:40, 2 May 2024 (UTC)

Validation request: music for "Love lies a bleeding"

I've finished transcribing this song, but I'd like another set of eyes, especially with regard to the repeats. Page:The Dancing Master, Playford, 1686.djvu/190 —CalendulaAsteraceae (talk • contribs) 19:35, 3 May 2024 (UTC)

I found no transcription errors. --EncycloPetey (talk) 20:00, 3 May 2024 (UTC)
Great, thank you! —CalendulaAsteraceae (talk • contribs) 20:03, 3 May 2024 (UTC)

Tech News: 2024-19

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

Recent changes

Screenshot of the visual improvements made on talk pages
Example of a talk page with the new design, in French.
  • The appearance of talk pages changed for all wikis, except for Commons, Wikidata and most Wikipedias (a few have already received this design change). You can read the detail of the changes on Diff. It is possible to opt-out these changes in user preferences ("Show discussion activity"). The deployment will happen at remaining wikis in the coming weeks. [1][2]
  • Interface admins now have greater control over the styling of article components on mobile with the introduction of the SiteAdminHelper. More information on how styles can be disabled can be found at the extension's page. [3]
  • Wikimedia Enterprise has added article body sections in JSON format and a curated short description field to the existing parsed Infobox. This expansion to the API is also available via Wikimedia Cloud Services. [4]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 7 May. It will be on non-Wikipedia wikis and some Wikipedias from 8 May. It will be on all wikis from 9 May (calendar). [5][6]
  • When you look at the Special:Log page, the first view is labelled "All public logs", but it only shows some logs. This label will now say "Main public logs". [7]

Future changes

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

MediaWiki message delivery 16:44, 6 May 2024 (UTC)

What controls which pages have the new "Talk page" formatting? Because it's not just Talk pages that have changed, but selected pages in other namespaces as well, with no rhyme or reason that I can see. --EncycloPetey (talk) 01:03, 7 May 2024 (UTC)
@EncycloPetey: I'd have to do some digging to get the specifics, but I'm pretty sure MediaWiki already has a notion of pages that are not in a Talk namespace but are used for discussions that is used for various purposes. The new talk pages appearance stuff just relies on that, I'll bet, possibly with some additional heuristics of its own. But more to the point: are you seeing pages getting affected that shouldn't be, or pages not affected that should have been? Xover (talk) 05:23, 7 May 2024 (UTC)
How do I know whether they "should" be affected or not? As I say, there seems to be no rhyme or reason as to which non-Talk pages are affected. --EncycloPetey (talk) 13:57, 7 May 2024 (UTC)
Well, "should" here referred to your expectations. But let's say any page in Talk: should get it, as well as WS:S, WS:PD, WS:CV, etc. But WS:DP, WS:WWI etc. should not. Xover (talk) 15:21, 7 May 2024 (UTC)

Template:Act of Congress problem

You can see it here—the title is duplicated. Based on what I can tell, this is a problem with the header module (as usual). TE(æ)A,ea. (talk) 00:41, 1 May 2024 (UTC)

Should be fixed now. —CalendulaAsteraceae (talk • contribs) 02:29, 9 May 2024 (UTC)

United Nations PDFs

After creating Index:1970 UN M49.pdf, Index:1975 UN M49.pdf and Index:1982 UN M49.pdf (missing some pages) would anyone please make them as source texts here? c:Category:United Nations Treaty Series also has many files to work on. Recent UN works tend to be copyright-restricted.--Jusjih (talk) 00:08, 9 May 2024 (UTC)

'Page carousel' gadget not working

I have been using a 'gadget' (mw.loader.load('//en.wikisource.org/w/index.php?title=User:Inductiveload/page carousel.js&action=raw&ctype=text/javascript');) which enables the previous or next page image to be viewed when editing a page, which is useful mainly for confirming such things as whether or not a 'nop' 'peh' or 'upe' is required, or whether a stanza in a poem follows on or ends. Until recently, this generally worked OK (it would occasionally get stuck on the 'next' or 'previous' page and wouldn't return to the one being edited) but now appears to be broken. When the 'forward', 'back' or 'home' symbol is clicked, all that happens is the magnification level of the page image increases. Chrisguise (talk) 17:25, 1 May 2024 (UTC)

A partial workaround is at Special:Preferences#mw-prefsection-gadgets: "Add a toolbar button to check for and insert a paragraph-breaking {{nop}} at the end of the previous page." —Justin (koavf)❤T☮C☺M☯ 18:14, 1 May 2024 (UTC)
Thanks - I already use that too. Chrisguise (talk) 18:26, 1 May 2024 (UTC)
@Chrisguise That might have been me, looking. Sohom (talk) 14:52, 9 May 2024 (UTC)

Proofread extension not working

If I edit a validated page, the proofread extension tools do not display with the edit window. They do show up when I create a page, or edit a "proofread" page, but not when that page has been validated. By this, I mean the character insertion tools, advance tool, proofread tools, OCR, etc. --EncycloPetey (talk) 23:43, 9 May 2024 (UTC)

It looks fine to me. Which page, specifically, were you looking at? Or maybe whatever the issue was got fixed quickly. Cremastra (talk) 23:50, 9 May 2024 (UTC)
It is now working for me as well, so hopefully it was just a transient issue. --EncycloPetey (talk) 00:28, 10 May 2024 (UTC)

Alignment of text in headers of transcluded chapters, etc.

Previously, the 'previous', 'section' and 'next' entries in the header appeared to be allocated equal space, with longer items wrapping to fit. The wrapping no longer appears to happen, so if 'next' and 'previous' are of significantly different lengths (e.g. poem titles), the 'section' content is significantly offset to left or right, which is not a good look. This also occurs if either 'next' or 'previous' is empty. See, for example, An Essay on Translated Verse (Roscommon)/An Essay on Translated Verse or An Essay on Translated Verse (Roscommon)/To the Earl of Roscomon, on his Excellent Poem. I don't know whether this is a Firefox issue (125.0.2) or a WS one. Chrisguise (talk) 12:23, 1 May 2024 (UTC)

I've noticed the same problem recently, though I hadn't realized that it used to be different.
After a bit of testing, same problem exists at least in Edge (version 122.0) and Safari (version 14.1.2), so I think it's on our end — Alien333 (what I did & why I did it wrong) 12:37, 1 May 2024 (UTC)
Definitely on our end and definitely a bug. I think I see how to fix it, but I'm travelling right now and don't want to make any big changes when I'm not around to fix anything that breaks, so it might be a while. Xover (talk) 13:49, 1 May 2024 (UTC)
@Xover @Alien333OK, thanks. Chrisguise (talk) 13:54, 1 May 2024 (UTC)
Ok, I think I've finally got this one licked. The central header block should now be properly centered, and the distribution of space between the central block and the next/prev links somewhat reasonable. The automatic footers were broken for a while as a result, but should be back now. The footer has the same off-center alignment issue, but there's something wonky with that Gadget that makes me not want to make big changes to it before I've figured out what's going on.
Testing would be appreciated. Please report here any pages where the header is not properly aligned, where the presentation is suboptimal, any other weirdness, etc. Xover (talk) 21:29, 10 May 2024 (UTC)
Lol I thought I was misremembering the header being formerly centred XD —Beleg Âlt BT (talk) 15:41, 1 May 2024 (UTC)
Sort of unrelated, but {{rh}} does the same (example). I think it would make more sense to make it evenly spaced as well. — Alien333 (what I did & why I did it wrong) 17:47, 1 May 2024 (UTC)
It used to be centered, but no longer is. On this page, for example, the central header information is offset to the right because there is the "next" parameter. And since it is off-center above centered text, it looks unprofessional. --EncycloPetey (talk) 19:15, 2 May 2024 (UTC)
Yes, I know, I was just mentioning that {{running header}} also has this issue. — Alien333 (what I did & why I did it wrong) 19:21, 2 May 2024 (UTC)
What about the Template:Header structure/styles.css? In a former version of Template:Header/styles.css the width of the cells ('central', 'back', 'forward') where defined. --M-le-mot-dit (talk) 21:16, 2 May 2024 (UTC)
Not sure if this is related to this problem, but I've just noticed that the font size for the previous and next items in the headers has changed and it is now bigger than it used to be. As a result the text is bigger than that in the centre and over-emphasises the two items. Beeswaxcandle (talk) 08:53, 9 May 2024 (UTC)
@Beeswaxcandle: What skin are you using? These all show up as the same size for me (14px, but that's relative to my browser's base font size) in Vector 2022, and this is being set by the skin's "medium font size". They could of course have been smaller than the title before (i.e. they are now larger relatively), but they're definitely not showing up as bigger than the title for me. Xover (talk) 12:15, 9 May 2024 (UTC)
Nevermind, I think I found the reason for this and have attempted a fix. The next and previous links should now be quite a bit smaller than the title. It's not done very prettily in a technical sense, so we'll have to tweak it later, but it'll hopefully fix it for now. Xover (talk) 12:36, 9 May 2024 (UTC)
Monobook (of course) for the skin. Size is now better, but there are two different fonts now. That for previous matches the rest of the page, while that for next is a different san-serif font with fatter letters and a smaller x-height. Beeswaxcandle (talk) 20:23, 9 May 2024 (UTC)
I'm going to go ahead and assume the different fonts you see is due to your web browser automatically substituting a different font for one of the different font sizes (cf. below), and that now the font size issue is fixed both will use the same font. If you still see different fonts then please do let me know. Xover (talk) 05:39, 10 May 2024 (UTC)
Yep, it's fine now. Thanks, Beeswaxcandle (talk) 07:29, 10 May 2024 (UTC)
'Next' link is smaller than 'Previous'. For 'next': class wst-header-forward is set in two embedded div, see 'Module:Header structure' lines 70 and 77; For previous: there are 2 different classes wst-header-back and wst-header-previous, lines 53 and 61. M-le-mot-dit (talk) 20:56, 9 May 2024 (UTC)
Argh. I should know better than trying for a quick fix. Yeah, the classes and IDs for {{header}} have been a right royal mess, and now that mess bit us. The next link had the same class applied twice and each time the font size was reduced by 10%, whereas the back link only got the reduction once, leading to the difference in sizes. I cleaned out some unused cruft there so the font sizes should be the same now. The overall horizontal alignment / distribution issue isn't fixed yet though, and requires a bit of testing before implementing to reduce the risk of things like this font size issue as much as possible. Xover (talk) 05:45, 10 May 2024 (UTC)
This solution in my common.css seems to work. M-le-mot-dit (talk) 11:31, 10 May 2024 (UTC)

Header issue

The text is still misaligned (with the text being offset with large “previous” or “next” entries). In addition, the “next” entry is now in a smaller font size, for some reason. TE(æ)A,ea. (talk) 16:52, 9 May 2024 (UTC)

See WS:S#Alignment of text in headers of transcluded chapters, etc. Xover (talk) 17:11, 9 May 2024 (UTC)

ALSO: It looks as though the text in the "next" link is slightly smaller than the text for the "previous" link. --EncycloPetey (talk) 01:28, 10 May 2024 (UTC)

As of today: Now the corresponding footer that used to appear at the bottom of the page, with a "next" link, is no longer displaying. This means that a rader, upon reaching the bottom of the page, must now return to the top of the page to proceed forward in a work. --EncycloPetey (talk) 15:38, 10 May 2024 (UTC)

See WS:S#Alignment of text in headers of transcluded chapters, etc. above. Xover (talk) 21:30, 10 May 2024 (UTC)

Away for a few weeks

After tomorrow, I will be away for the next few weeks, first on a long-planned trip, and then taking care of my elderly mother, who is having major surgery this month. Please try to have this project finished by the time I get back. Barring that, it would be a nice surprise to at least discover that Index:Carnegie Flexner Report.djvu (or, to be even more ambitious, Index:Black's Law Dictionary (Second Edition).djvu or Index:Hoyt's New Cyclopedia Of Practical Quotations (1922).djvu) had been done. Cheers! BD2412 T 20:17, 1 May 2024 (UTC)

I'm back early, and needless to say I am very disappointed that Wikisource is not finished yet. BD2412 T 15:44, 10 May 2024 (UTC)
I'm sure now that you're back we'll be able to wrap everything up by June! —CalendulaAsteraceae (talk • contribs) 17:59, 10 May 2024 (UTC)
Indeed, let's do it! BD2412 T 21:29, 11 May 2024 (UTC)

Transcluded volume's Source tab is not linking to its Index

The Source tab on How to Tell the Birds from the Flowers and other wood-cuts is directing me to:

Index:How_To_Tell_the_Birds_From_the_Flowers,_and_Other_Woodcuts_(1917)_(IA_cu31924027175250).pdf

instead of to the Index page at:

Index:How to tell the birds from the flowers and other Woodcuts. A revised manual of flornithology for beginners (IA cu31924027175250).pdf.

Note that the file was recently renamed at Commons, which may be part of the problem. --EncycloPetey (talk) 20:04, 11 May 2024 (UTC)

@EncycloPetey: The index is probably tied to the (file) redirect instead of the actual file, which tends to give this kind of issue. The solution is usually moving the index and pages to match the actual file name, and updating the transclusions. And, yes, this is very annoying. Xover (talk) 20:14, 11 May 2024 (UTC)

Running header (again)

Hi. Time to reopen / continue (depends on point of views) this discussion Wikisource:Scriptorium/Archives/2024-01#Updates_to_Template:RunningHeader.

Objections have been raised to the bot request to clean up {{RunningHeader}} use, in order to enable the adoption of the new template signature (short summary: 1-param=center, 2 params=left/right, 3-params=left/center/right, and so on). The merit of the objection is if this discussion gave consensus or not: Wikisource:Bot_requests#Migrate_more_one-_and_two-parameter_invocations_of_Template:RunningHeader.

So the question is: is there consensus to support the new concept of {{RunningHeader}} (and then to continue with the bot work) or not?

Please do not shoot the messenger ... :-)

 Support I expressed concern for the 2-params case, but the new signature has its logic. Also considering that a lot of cleanup work has already been done to allow this migration, it would be a waste at this point not to proceed. Mpaa (talk) 22:42, 3 May 2024 (UTC)

 Support. Thanks for bringing this up here Mpaa! And to be clear, the logic is that the number of parameters given to {{rh}} will directly correspond to the number of cells produced (no more rh/1, rh/5, rh/whatever), and the cells will align in the way that's natural for that number of cells. This will require old-timers to retrain their muscle memory a bit, e.g. to use {{rh||pagenum|}} instead of {{rh||pagenum}}} to get a centered page number. But it will be a more intuitive and direct correspondence for newcomers and old-timers alike once done. It will also clean up the logic in the code considerably, doing away with special cases. It will also make it easier to style the running headers with CSS (including documenting style snippets that can be cut&pasted). Xover (talk) 06:35, 4 May 2024 (UTC)
My understanding was that with the proposed redesign, the single centered heading would be {{rh|<centered heading>}} and {{rh/1}} would be deprecated. ShakespeareFan00 (talk) 06:54, 4 May 2024 (UTC)
(Aside: As part of the running header cleanup efforts , Would it be possible for you or another admin to set up some more tracking categories to find 'singleton' entries. I was finding in looking through some uses of {{rh}} that could be converted to {{continues}} or {{Overleaf}}.. typically single right aligned entries (in a 3 cell) with non numeric contents. I'd appreciated someone tidying up both templates, and {{leafsig}} which I intend to use at some point, even if generally leaf signatures aren't generally included.. )ShakespeareFan00 (talk) 14:13, 4 May 2024 (UTC)
Thanks for your work adding a tracking category to Module:Running header! I've implemented your edits with a few modifications. Category:Running headers with only one content entry should populate itself soon enough. —CalendulaAsteraceae (talk • contribs) 20:01, 4 May 2024 (UTC)
@ShakespeareFan00 before starting to mass work on this category (15k pages) to introduce new templates, I'd rather you explain your plans in advance. Also consider that there are pages where there is only one param by mistake, e.g. Page:Aurora_Leigh_a_Poem.djvu/200. Mpaa (talk) 08:38, 5 May 2024 (UTC)
The objective was to de-overload {{rh}}, by moving certain uses to semanticly more meaningful templates. Other than looking for the obvious errors, I was not going to deploy the three mentioned templates without further discussion, other than in works where they had already been used,to maintain consistency.
The three templates are:
  • {{leafsig}} - I'd created this to mark so termed "leaf-signatures" in Page:namespace where these were transcribed (These are generally part of the printing/binding process and so are optional in Page:namespace, and shouldn't appear in transcluded versions or exported PDF's etc..) As these typically have a consistent rendering across a given work, it seemed sensible to templatise it so that their format could be set 'consistently' on a per Index basis, but with only needing to update the 'format' in a single location. ShakespeareFan00 (talk) 08:59, 5 May 2024 (UTC)
  • {{continues}} - This was created to permit (in Page namespace) transcription of the catchwords at the base of a page, where the 'catchword' was a continuation of an existing word or paragraph. Again the format of these is generally consistent across a given Index.
  • {{Overleaf}} - This was created to be be the 'block' level equivalent of {{continues}}, (It causes a paragraph break.) In existing uses {{float right}}; {{right}}; {{right block}} , {{block right}} and {{rh|||continuation}} amongst others have all been used to mark these.
There are other "creative" uses of RH which should also be examined. {{rh| |heading|}} not in a Page: header or footer could be replaced with {{pseudoheading}} or a simple {{c}}, for example.
Within the last year (12 mos), there was a Featured Text that used {{rh}} to build the table of contents (the Swedish language featured text).--RaboKarbakian (talk) 14:34, 5 May 2024 (UTC)
I've no objection to other contributors tidying up the three template concerned, or adding the ability to class them, as I've attempted to do with {{leafsig}} ShakespeareFan00 (talk) 08:59, 5 May 2024 (UTC)
@CalendulaAsteraceae:, I'm going to hold on doing more repairs for a few days, The category is STILL populating. I also added a mechanism for using an '_' as an obvious blank field in the sandbox. It converts to a &nbsp; . If it's also possible to add a shorthand for doing singular left or right headings using a short hand, it should be considerd I favour an approach like left|<<|<< and >>|>>{!}right as this would be easy to implement and migrateable to from the existing 'blank' usages.. A 'centered' item would then be >>|heading|<< obviously, unless we convert the latter to rh/1 type bevahiour. The existing code for blanks would be unchanged, but it would be more explicit about intended layout. ShakespeareFan00 (talk) 19:53, 5 May 2024 (UTC)
@ShakespeareFan00: I don't want to add that kind of special string parsing to the module, and I don't see the point of adding a &nbsp; as opposed to just having a blank cell. In any case, this is all getting pretty far afield from the original thread topic, but feel free to discuss this more on my talk page or the talk page for the template. —CalendulaAsteraceae (talk • contribs) 20:36, 5 May 2024 (UTC)
@CalendulaAsteraceae: No special parsing needed, See sandbox and testcases. It's a 3 line change. ShakespeareFan00 (talk) 22:41, 5 May 2024 (UTC)
Further comments on the template page as you suggest please.ShakespeareFan00 (talk) 22:42, 5 May 2024 (UTC)
 Support as above :) —CalendulaAsteraceae (talk • contribs) 19:47, 4 May 2024 (UTC)
 Support Seems like a solid plan! Nosferattus (talk) 22:52, 4 May 2024 (UTC)


Summary: No one else in addition to TE(æ)A,ea. has opposed, so I am considering this an approval for the template migration / bot work. Mpaa (talk) 17:30, 12 May 2024 (UTC)

If this is about converting 2 param uses case, I have no objections. However, will be you 'batching' these to allow for review as the bot progresses?, I was finding some situations were the running headers affected needed to be patched up manually ( 2 param case blank, center, right) entered as left,center via typo. I'm not sure the bot would catch these.. ShakespeareFan00 (talk) 07:37, 13 May 2024 (UTC)
@ShakespeareFan00 I am not planning batches, I will do something every now and then. If I can spot issues, I'll fix them, otherwise too bad, they are already errors anyhow, so it will not get worse. Mpaa (talk) 19:31, 13 May 2024 (UTC)

Disambiguation styling

How are entries supposed to be styled?

I suggest we standardize it, if it's not already done, and if it is, then write it in WS:MOS and/or in Help:Disambiguation

  1. titles are a) plain b) italicized c) "quoted"
  2. (poetry-specific) first lines are a) (plain) b) (italicized) c) ("quoted") d) ("quoted and italicized") (rarer)
  3. (poetry-specific) and they are shown a) never b) when there is another entry by same author c) always
  4. between the title and the author is a) systematically the type of work (such as "a poem by") b) the type of work except when already in a section containing the type (such as only "by" in the section "Poems") c) the occasional "a work by"
  5. dates are a) shown b) not shown
  6. and they are a) after the title b) at the end of the line

As of now the disambiguation pages are a mosaic of different combinations of these, differing sometimes even on the same page.

I think we should choose one style and stick to it. — Alien333 (what I did & why I did it wrong) 07:55, 13 May 2024 (UTC)

There is some guidance on the {{disambig}} template page, although I don't agree with parts of it. I think I've seen other bits elsewhere but can't track them down. The approach I try take (can't claim to be wholly consistent), based on having looked at quite a lot of these pages, is:
  1. Only give the title, the type of work and the author (with first line if needed to discriminate between similarly titled works by the same author).
  2. As all titles are nominally the same, sort the entries alphabetically by author surname.
  3. If there are a lot of entries, consider splitting the page into sections (e.g. poems, short stories, novels, etc.) although this generally isn't necessary.
  4. If there are a lot (e.g. Sonnet), then section by initial letter of surname, then sort by surname. Again, this isn't often required.
  5. I always put encyclopaedia articles, if any, under a separate heading ===Encyclopaedia articles=== as the last section.
  6. Part works (e.g. a poem or short story from a collection) are in " ", complete works (e.g. poetry collections, novels, etc.) in italics.
  7. If an author has more than one work of the same name (usually, but not exclusively, poems), I would create a disambig page specifically for that work, but having done so and been rebuked for it, the option I follow is to quote the first line of the work after the author's name, formatted as ("Blah, blah, ..."). Some poetry disambig pages quote first lines for all works listed, which can be a help.
  8. I don't see the point of including a date. Versions of works transcribed are often not first publication, so the date of the transcribed version typically isn't specifically interesting. Quoting the date of first publication is, in my opinion, misleading, if that version isn't on WS.
  9. I don't see the point of quoting the source, since the title link will take you there anyway (if it's a sole version), or to an {{other versions}} page, if not; this should quote the source, as part of the versions disambig.
No doubt others have different views. There's a fractious debate somewhere on here about whether encyclopaedia articles should be included on disambig pages. It's a no-brainer as far as I'm concerned. Chrisguise (talk) 17:21, 13 May 2024 (UTC)

There is no universal one way that's going to work for all cases. In some situations, we need to disambiguate two poems with the same title by the same author, so additional information is needed. Sometimes it makes sense to sort alphabetically by author surnames, but some authors do not have surnames. Sometimes it makes sense to sort chronologically, because the works are inspired by the earlier works. Sometimes it makes sense to put the most obvious and frequent usage first, for ease of the reader. Sometimes it makes sense to use sectional grouping, but other times it doesn't. --EncycloPetey (talk) 17:33, 13 May 2024 (UTC)

Tech News: 2024-20

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

Recent changes

  • On Wikisource there is a special page listing pages of works without corresponding scan images. Now you can use the new magic word to exclude certain pages (list of editions or translations of works) from that list. [9]
  • If you use the user-preference "Show preview without reloading the page", then the template-page feature "Preview page with this template" will now also work without reloading the page. [10]
  • Kartographer maps can now specify an alternative text via the alt= attribute. This is identical in usage to the alt= attribute in the image and gallery syntax. An exception for this feature is wikis like Wikivoyage where the miniature maps are interactive. [11]
  • The old Guided Tour for the "New Filters for Edit Review" feature has been removed. It was created in 2017 to show people with older accounts how the interface had changed, and has now been seen by most of the intended people. [12]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 14 May. It will be on non-Wikipedia wikis and some Wikipedias from 15 May. It will be on all wikis from 16 May (calendar). [13][14]
  • The Special:Search results page will now use CSS flex attributes, for better accessibility, instead of a table. If you have a gadget or script that adjusts search results, you should update your script to the new HTML structure. [15]

Future changes

  • In the Vector 2022 skin, main pages will be displayed at full width (like special pages). The goal is to keep the number of characters per line large enough. This is related to the coming changes to typography in Vector 2022. Learn more. [16]
  • Two columns of the pagelinks database table (pl_namespace and pl_title) are being dropped soon. Users must use two columns of the new linktarget table instead (lt_namespace and lt_title). In your existing SQL queries:
    1. Replace JOIN pagelinks with JOIN linktarget and pl_ with lt_ in the ON statement
    2. Below that add JOIN pagelinks ON lt_id = pl_target_id

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

MediaWiki message delivery 23:58, 13 May 2024 (UTC)

Sign up for the language community meeting on May 31st, 16:00 UTC

Hello all,

The next language community meeting is scheduled in a few weeks - May 31st at 16:00 UTC. If you're interested, you can sign up on this wiki page.

This is a participant-driven meeting, where we share language-specific updates related to various projects, collectively discuss technical issues related to language wikis, and work together to find possible solutions. For example, in the last meeting, the topics included the machine translation service (MinT) and the languages and models it currently supports, localization efforts from the Kiwix team, and technical challenges with numerical sorting in files used on Bengali Wikisource.

Do you have any ideas for topics to share technical updates related to your project? Any problems that you would like to bring for discussion during the meeting? Do you need interpretation support from English to another language? Please reach out to me at ssethi(__AT__)wikimedia.org and add agenda items to the document here.

We look forward to your participation!


MediaWiki message delivery 21:22, 14 May 2024 (UTC)

What is wrong with index:The Yellow Book - 03.djvu?

I fixed the scan of this work (missing / duplicate pages) and uploaded the new version, on 1st May 2024, to Commons [19]. This displays perfectly well, and if downloaded, the file works fine. However, the file does not display on the WS file: page File:The Yellow Book - 03.djvu. Thumbnails for all previous versions have disappeared and file data for the latest version is incorrect. I have repeatedly purged this page using both the 'clock' gadget and ?action=purge, to no avail. The index: page Index:The Yellow Book - 03.djvu is completely broken: there is no thumbnail (typical in these cases) and the 'pages' section is showing an 'invalid interval' error message (not typical). I've reviewed the <pagelist/> entry and haven't spotted anything wrong with it. Can anyone assist, as this is becoming really annoying? Chrisguise (talk) 17:42, 13 May 2024 (UTC)

I'm unsure of the cause, but the file history at Commons [20] indicates a page size of 0 x 0. --EncycloPetey (talk) 17:47, 13 May 2024 (UTC)
Did you try purging on Commons first, then purging on WS? It worked for me every time I had this problem (though it does raise the question of why it seems to be happening more often lately). Arcorann (talk) 00:03, 14 May 2024 (UTC)
@Arcorann: sadly, it looks like we actually don't have a solution. I purged evry related page twice, and it still dorsn't work. — Alien333 (what I did & why I did it wrong) 05:09, 14 May 2024 (UTC)
File replaced by another scan (Internet Archive identifier: yellowbook3). M-le-mot-dit (talk) 12:09, 14 May 2024 (UTC)
For the record, I uploaded the file locally to WS to check whether possibly there is something about it that triggered, say, the unsafe file type check here as opposed to on commons and it uploaded and rendered fine. MarkLSteadman (talk) 00:24, 16 May 2024 (UTC)

Template:Welcome image change

The following discussion is closed:

The sentiment of the discussion was about 2:1 (66% vs 33%) in favour of switching back to The Bookworm by Carl Spitzweg.

Arguments advanced in favour of The Bookworm centred on the painting's symbolism, that it was an abstract representation of Wikisource and what we do here, that it expressed warmth and humour, and that its message and purpose was universally and immediately recognisable.

There were relatively few arguments advanced specifically against this image (vs. merely in favour of the alternative), but those proposed included that it is visually busy, its subject is imaginary rather than real, that the person in the painting has his back turned towards the viewer, and that its representation of the project is of Wikisource's worst aspects rather than its best ([it] says: ‘I'm busy so don't bother me.’ That may be an accurate representation of Wikisource, but it is not a welcoming image.).

Arguments made in favour of the portrait of George Eliot by François d'Albert-Durade centred on Eliot's stature as an author, that the painting's subject is real rather than imaginary, that the subject is facing the viewer, and that it is perceived as more welcoming and inclusive. A (relatively) new contributor also chimed in and expressed their positive experience with this image, emphasising that the image was perceived as "puzzling and inviting": When I was welcomed in last fall by the aesthetically pleasing G. Eliot painting, it inspired me to discover her Author portal, and thus begin learning how WS is organized. It was puzzling and inviting. I suppose I did wonder ‘why her?’ over all other possibilities, but I confess I simply enjoyed the non-sequitur enigma of it; it felt like an unexpectedly welcoming artistic and aesthetic flourish (which defied my expectactions and contributed my warming up to WS in a hurry).

There was also a significant amount of opposition to the Eliot portrait, mostly focussed on its lack of immediate recognisability, the perceived implicit elitism and lack of universality, the use of a specific concrete author over an abstract representation of the project, and the painting's general aesthetic characteristics.

Closer: Xover (talk) 06:10, 11 May 2024 (UTC)

Apparently this is a thing that happened. The image for the welcome got changed from someone going through books (which is what we do) to some random woman (who is apparently an author, not that the portrait makes it at all clear). I support the change. Other interested editors: Xover, SnowyCinema. TE(æ)A,ea. (talk) 03:24, 9 April 2024 (UTC)

  •  Oppose The portrait of an actual English author (George Eliot) is preferable over an imaginary random guy from a painting. The portrait of G. Eliot is more welcoming and inclusive, and is also far less busy visually. More welcoming because the subject is facing the viewer, not facing the other way, ignoring the viewer. --EncycloPetey (talk) 03:57, 9 April 2024 (UTC)
Right, but as I noted in the other discussion, (and as TEA's comment further proves), the image is not universally recognizable. You're assuming that every editor will come from the same background. A book is a universally recognizable symbol, whereas this individual is certainly not. SnowyCinema (talk) 04:25, 9 April 2024 (UTC)
No author will be universally recognizable;that's a bar we cannot reach. And neither is the fictional man from an obscure painting going to be recognizable. Yes, books are widely recognized, but the older image is not that of a book, but of a person standing on a ladder with his back to the viewer. Is that a welcoming image? That image doesn't say "Welcome to Wikisource", but says: "I'm busy so don't bother me." That may be an accurate representation of Wikisource, but it is not a welcoming image. --EncycloPetey (talk) 19:22, 9 April 2024 (UTC)
  •  Support I've always felt weird about this change for a lot of reasons, though I wasn't aware of it being a result of a discussion until now, and apparently I wasn't the only one.
  • A portrait of George Eliot is not universally recognizable, and people from many different backgrounds will not resonate with the image. At most, she is symbolic of a specific literary movement in Western history...barely relevant at that time outside of Europe...and therefore to many she just represents a random individual on a portrait.
  • Also, we are a neutral platform and shouldn't appear that we favor certain authors over others. We can say certain authors are notable, that's fine—but for our welcome template? I know some will claim they didn't choose the image because of some personal preference or bias for the author herself as has been argued, but whether or not that's true, this is favoritism in practice, inherently, even if unintended. Why not choose Blake, Tennyson, Wells, Fitzgerald, Wollstonecraft, Chesterton, Doyle, ... the list goes on? This just creates an argument about who to choose, and that's counterproductive and unnecessary, even if we're just going to count popular women writers in this... So, individual people should be out of the question.
I think the previous image was better than what we had after; it was creative, unique, obscure, unexpected, gives a certain nostalgic appeal that also relates to what we're doing in the modern sense, and was certainly not "too visually busy" whatsoever. I don't think anyone will care that much that the person in the portrait is not facing the viewer. It is a slight downside, sure, but the benefits and relevance more importantly of the image far outweigh this extremely slight and almost unnoticable con in my opinion. SnowyCinema (talk) 04:25, 9 April 2024 (UTC)
  •  Oppose but only because I want to make a case for the effectiveness of the G. Eliot painting specifically. When I was welcomed in last fall by the aesthetically pleasing G. Eliot painting, it inspired me to discover her Author portal, and thus begin learning how WS is organized. It was puzzling and inviting. I suppose I did wonder "why her?" over all other possibilities, but I confess I simply enjoyed the non-sequitur enigma of it; it felt like an unexpectedly welcoming artistic and aesthetic flourish (which defied my expectactions and contributed my warming up to WS in a hurry). I also was assuming this photo rotates regularly; so I suppose in that sense I "support" changing it, but I'd hope it could continue to be welcoming, intriguing, and aesthetically pleasing. Not sure I'm even entitled to a vote here, but I thought I might have a relatively different perspective as a new Wikisourcer. Brad606 (talk) 05:02, 9 April 2024 (UTC)
@Brad606: Yes, you are certainly entitled to vote here with your edit count and your time since registration, and I have loads of respect for this direct user feedback and the unique perspectives. I really wish we had more of this kind of thing in our votes and discussions (more often than we should, we rely on the opinions of the hyper-experienced, rather than the end users who the technology affects the most). I think if the image were rotated, using specific authors might make more sense, since it doesn't suggest partiality, so you raise a valid point about that for sure. This is something that (as far as I know) is technically possible, actually, and if George Eliot were one of a diverse collection of 365 author portraits rotated every day of the year, that would be an interesting (and more neutral) way of doing this. SnowyCinema (talk) 05:14, 9 April 2024 (UTC)
Indeed, for this issue in particular, input from a newer (well, relative to some of us dinosaurs; 3+ years is not all that new) contributor is very valuable.
Whether it makes sense to rotate the image I don't immediately have an opinion on, but if we were to opt for that we needn't make a whole catalog of 365 images and auto-rotate (which is hard to do sensibly in MediaWiki). It would be enough to simply say that "this image rotates periodically" and then let people propose changes here. Simple and low-tech, and easy to relate to and maintain. Xover (talk) 06:10, 9 April 2024 (UTC)
  • I'm not sure what "support" and "oppose" would be relative to here (support the change that has already happened? oppose that change? support changing from what's currently there to something else, possibly the previous image? oppose changing it further and stick with what currently there?), but I am in favour of returning to the Spitzweig image we had for fifteen years. It's funny and quirky, and more importantly it represents well and directly Wikisource as a project and what we do here. A generic portrait of an author says nothing about this project, except maybe "look how sophisticated we are that we know immediately who this generic-looking person is". Having a specific author leads to endless discussions of this author vs. that author, and kinda begs for a caption for the image in {{welcome}} that explains who the person is and why they are relevant to welcoming new users. --Xover (talk) 06:31, 9 April 2024 (UTC)
  •  Oppose, as in opposing the change back to the original picture. The "random woman" in question being a pillar of english literature, I don't think there's an argument for her to be replaced by an actual random man, and George Eliot being unknown by major contributors is all the more reason to actually keep her there. Mind that this isn't a picture to represent the entirety of Wikisource, but to be presented to all new contributors, and new young users could be more enticed to stay and to take the website seriously if welcomed by a young writer than by the quintessence of stuffy old archivist. However it's true that the change done was quite one sided and that the original image has its merits, so I support a rotation in pictures, although not a daily one Ostrea (talk) 09:55, 9 April 2024 (UTC)
It seems to me like English literature had quite a lot of "pillars" (including some of the other authors I've mentioned), and I think these pillars would only interest a certain subset of our contributor base, even if more or less the majority. As I pointed out, users from certain cultural backgrounds, age groups, educational and class backgrounds, hobby/interest areas, etc., may not find her immediately recognizable, personally relevant, or even know her by name. From my own personal experience, even in America, let alone countries completely outside the "global West", she wouldn't be recognizable to most adults... And in the Philippines, you can absolutely forget it.
So, I do agree with Xover's point that the portrait has a certain aura of elitism on our part, an issue I forgot to mention in my vote. It isn't wrong of anyone not to know who this author is, as there are plenty other interest areas in Wikisource's league that are unrelated to 19th century English literature and poetry. For example, maybe somebody comes here out of interest in the history of the Boy Scouts...or engineering manuals...or film history...or the New York Times...or school yearbooks...or a plethora of others.
Well, anyway, the "actual random man" isn't the crux of my argument, as it's not just the man but what he's doing that leans me to favor it. This is something that the Eliot portrait lacks—there's nothing about that image, except the expectation to recognize her as an individual, that makes it relevant (tangentially) to what we do here. SnowyCinema (talk) 12:53, 9 April 2024 (UTC)
    • Ostrea: I know who George Eliot is, I just wouldn’t know off-hand (nor, I think, would most readers) that that portrait is of George Eliot. In addition, George Eliot is by no means the most prominent author we have on Wikisource, and is in general not a good representation. The man is fictional, but that is the benefit; he is an abstraction of the process involved at Wikisource. When representing Wikisource, you can see one tiny facet (with the Eliot portrait), if you can even recognize it, or an abstraction of the basic concept. One is clearly more valuable. TE(æ)A,ea. (talk) 20:32, 9 April 2024 (UTC)
  • comment The current picture of George Eliot has been in place for 2½ years (Sept 2021). Prior to that we had the Carl Spitzberg image for 11 years (Oct 2010). There was no painting image used in the versions prior to then. Both images were chosen by User:Cygnis insignis as part of updating the template. I am not aware of any discussion that led to either change. Personally, my preference is for the humour expressed in the Carl Spitzberg image. Beeswaxcandle (talk) 10:16, 9 April 2024 (UTC)
  • I'd prefer the old image too. Being french (you don't have to look as far as the Philippines), I'd never even heard of the name of G. Eliot before coming here. I was very puzzled it took me a while to discover that she was an author and not just some picture of a random woman. The Spitzberg one is more clearly related to Wikisource (and funnier). (note: Only been here for a few months, if I shouldn't vote in things like this please tell me so) — Alien333 (what I did & why I did it wrong) 19:56, 9 April 2024 (UTC)
    @Alien333: You very definitely should, and we very much appreciate new users engaging themselves with the running of the project. If there's anywhere we have "experienced users only" stuff an experienced user (natch) will take care of it. Essentially it's a matter of a few kinds of votes where votes by users who are not "established" count less or not at all (and that's for the vote counters to deal with). I can't recall any time that rule actually came into play. We also have a few technical things that are better performed by experienced users or admins, but that's purely for practical reasons (easy to make mistakes that are a pain to clean up, or requires admin tools to do right). But in general I wouldn't worry about that: there's no place or aspect of the project where relative newcomers are inherently not welcome, and in most things it's a "with open arms" type situation. Xover (talk) 06:22, 10 April 2024 (UTC)
Assuming the desired proposal is to change back to the previous image (this should have been stated explicitly),  Support as per Cremastra etc. Arcorann (talk) 05:19, 12 April 2024 (UTC)

 Support Logging in makes talk pages active and otherwise increases availability. I am usually busy doing something when I am logged in. Then, me the hipster, wants to be done with gender talks. G. Eliot and the people who are available here have one thing in common. We and she had to declare a gender before authoring any opinion or request. We have an extra choice. I can choose to be in a very specifically defined new gender, one which I don't feel qualified to speak for, much less be a member of. And that is the default choice. My experience with the works of G. Eliot was like the bash manual for reading (aka sleep inducing). I couldn't do it. Reading a lot of the crap that is here is work also, so, people logged in for editing or reading are probably busy here. When you can easily be honest with that image of the old fashioned guy putting a book on the shelf and avoid a whole bunch of the politics of personal definitions. Dear George Eliot: Glad to know you, don't let the door hit you on the way out. Hopefully, with you gone, we can walk down the path of "NON DISCLOSED because it REALLY DOESN'T MATTER" universe, where every person on the internet is a 14 year old boy. Tread lightly.--RaboKarbakian (talk) 10:28, 10 April 2024 (UTC)

As mandatory gender selection goes, it claims to be there for software to run. I become very suspicious when a "person" knows which gender I have opted for. I don't know how to sift through your preferences to learn anything about you. Is there a user gender template any where?--RaboKarbakian (talk) 09:22, 12 April 2024 (UTC)
@RaboKarbakian: You can't set a gender in MediaWiki, but in your preferences you can, if you like, specify what pronoun the software should use when it needs to refer to you in the third person. The default is the gender-neutral singular they (the setting predates the recent proliferation of pronouns and politicisation of they as a pronoun), and you have to actively choose to have it use she or he. What a given user has set this preference to is made available through a parser function (essentially a "built-in template"). So for example you could type {{GENDER:Xover|he|she|they}} to get "they" and {{GENDER:RaboKarbakian|he|she|they}} to get "he".
Also please note that gender here is a very nebulous concept as the software knows nothing about who you are in real life, and cannot tell what your biological, social, cultural, or legal gender is (I think there's even an ethnic conception of gender). It only knows that a particular user has chosen for the software to use either he, she, or they in certain interface messages where non-gendered language is impossible or too awkward. Nobody knows whether what you specify there is true, in whatever sense is relevant, or not. Xover (talk) 13:53, 12 April 2024 (UTC)
Xover: the point being that software can access that information but people cannot, at least not without software like at minimum, a template. Which would explain a lot about Petey's "Rabo is a maverick" rant. Petey taught me at wikidata. So I had a software rant from him. For example. I have seen gender (also) used in a "he is typing" sort of way also, in the wiki gui, where it was supposed to be.--RaboKarbakian (talk) 16:24, 13 April 2024 (UTC)
  •  Support: while I don't classify George Eliot as "some random woman", the original painting better reflects what goes on here. If you don't immediately recognize the current picture as depicting George Eliot, it's somewhat confusing, whereas the original painting is immediately understandable (as SnowyCinema said above, "a book is a universally recognizable symbol, whereas this individual is certainly not.) Cremastra (talk) 22:15, 10 April 2024 (UTC)
  •  Support, I was first welcomed to Wikisource by this picture of George Eliot, and while I don't know who she is, her friendly, smiling face on the talk page has reminded me that Wikisource is both friendly and welcoming. --FPTI (talk) 06:04, 1 May 2024 (UTC)
    @FPTI: You say you support changing the picture, but your comment seems to support keeping the picture. Did you mean to {{oppose}}, as in opposing changing the picture? Cremastra (talk) 13:13, 4 May 2024 (UTC)
    It seems a lot of people are confused as to what exactly support and oppose mean here. — Alien333 (what I did & why I did it wrong) 13:43, 4 May 2024 (UTC)
    Well, it'll be a fun discussion to close, then... :) Cremastra (talk) 21:07, 10 May 2024 (UTC)


File History vandalised

Whatever page/template sets out the formatting for file history appears to have been vandalised. Where it previously had "Date/Time" and "thumbnail", there appears to be somebody's name.

"Click on a date/time to view the file as it appeared at that time." has been replaced with this string of text: Yi efo/eka'e gwa ebo wo le nyangagi wuncin ye kamina wunga tinya nan

Not sure when it happened but I noticed it now. I observed it on multiple uploaded files uploaded locally to Wikisource. DraftSaturn15 (talk) 09:01, 15 May 2024 (UTC)

I'm not seeing this problem. Could you provide some examples of where you're seeing it? --EncycloPetey (talk) 20:00, 15 May 2024 (UTC)
I see it on every locally uploaded file, however only when I'm logged in. When logged out, I don't see the vandalism. If it has something to do with the skin, I'm using Vector Legacy (2010).
Here are some examples:
Here's a screenshot of what I see.
DraftSaturn15 (talk) 02:28, 16 May 2024 (UTC)
I assume it's something specific to your account, since I'm using Vector legacy myself and do not see this issue. --EncycloPetey (talk) 02:49, 16 May 2024 (UTC)
Have you tried checking your language settings? Arcorann (talk) 02:49, 16 May 2024 (UTC)
@Arcorann @EncycloPetey I was using en-GB British English and that's where the vandalism appears. When I switch to en English or en-CA Canadian English, it has the usual text under file history. DraftSaturn15 (talk) 05:13, 16 May 2024 (UTC)
See here: https://translatewiki.net/wiki/MediaWiki:Filehist-help/en-gb. It looks like it using the Nupe language version for some reason. MarkLSteadman (talk) 15:27, 16 May 2024 (UTC)
Which seems that it will be fixed in the next Mediawikiu deploy: https://github.com/wikimedia/mediawiki/commit/f4d953a7144b65183be82607a81c256460d4942a MarkLSteadman (talk) 15:33, 16 May 2024 (UTC)

Template:Small

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)

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 [21] and CSS font-size making a distinction between small and smaller, large and larger. [22] (if redirecting small to {{smaller}}, etc.). Of course, this can be revisited. MarkLSteadman (talk) 00:10, 16 May 2024 (UTC)
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)
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)
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)
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)

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).

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).
Pages /75-/78 are repaired. Offset -4 will start with /83. --M-le-mot-dit (talk) 09:50, 15 May 2024 (UTC)
@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)
Thanks for doing this, your efforts have produced the exact result required. Much appreciated. Chrisguise (talk) 07:39, 16 June 2024 (UTC)
This section was archived on a request by: --Xover (talk) 07:44, 16 June 2024 (UTC)

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 klawal-ctr@wikimedia.org.

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)

Tech News: 2024-21

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

Recent changes

  • The Nuke feature, which enables administrators to mass delete pages, will now correctly delete pages which were moved to another title. [23]
  • New changes have been made to the UploadWizard in Wikimedia Commons: the overall layout has been improved, by following new styling and spacing for the form and its fields; the headers and helper text for each of the fields was changed; the Caption field is now a required field, and there is an option for users to copy their caption into the media description. [24][25]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 21 May. It will be on non-Wikipedia wikis and some Wikipedias from 22 May. It will be on all wikis from 23 May (calendar). [26][27]
  • The HTML used to render all headings is being changed to improve accessibility. It will change on 22 May in some skins (Timeless, Modern, CologneBlue, Nostalgia, and Monobook). Please test gadgets on your wiki on these skins and report any related problems so that they can be resolved before this change is made in all other skins. The developers are also considering the introduction of a Gadget API for adding buttons to section titles if that would be helpful to tool creators, and would appreciate any input you have on that.

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

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

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)

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)

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)
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)
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)
Chrisguise, TE(æ)A,ea.: toc to toc conversion.--RaboKarbakian (talk) 13:19, 17 May 2024 (UTC)
@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)
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. --Slowking4 ‽ digitaleffie's ghost 03:44, 21 May 2024 (UTC)
@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)
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)
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)

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)

Tech News: 2024-22

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

Recent changes

  • Several bugs related to the latest updates to the UploadWizard on Wikimedia Commons have been fixed. For more information, see T365107 and T365119.
  • In March 2024 a new addPortlet API was added to allow gadgets to create new portlets (menus) in the skin. In certain skins this can be used to create dropdowns. Gadget developers are invited to try it and give feedback.
  • Some CSS in the Minerva skin has been removed to enable easier community configuration. Interface editors should check the rendering on mobile devices for aspects related to the classes: .collapsible, .multicol, .reflist, .coordinates, .topicon. Further details are available on replacement CSS if it is needed.

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 28 May. It will be on non-Wikipedia wikis and some Wikipedias from 29 May. It will be on all wikis from 30 May (calendar). [28][29]
  • When you visit a wiki where you don't yet have a local account, local rules such as edit filters can sometimes prevent your account from being created. Starting this week, MediaWiki takes your global rights into account when evaluating whether you can override such local rules. [30]

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

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

Retrieved from "https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium/Archives/2024-05&oldid=14300822"