Wikisource:Scriptorium/Archives/2024-05

Wikidata search link when creating new author pages

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

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

• A new service will be built to replace Extension:Graph. Details can be found in the latest update regarding this extension.
• Starting May 21, English Wikipedia and German Wikipedia will get the possibility to activate "Add a link". This is part of the progressive deployment of this tool to all Wikipedias. These communities can activate and configure the feature locally. [8]

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   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
  • See phab:T222224 for technical reasoning. [17][18]

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:

• File:A_Treatise_on_the_Steam_Engine_(1847).djvu-295.png
• File:BibleKJV1611-009.pdf
• File:ESafety_Commissioner_v_X_Corp.pdf
• File:UKOpenGovernmentLicence.svg

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:—

• The index page name = Index:The Yellow Book - 03.djvu

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

• RaboKarbakian: That chapter probably fails because of all of the {{nsl2}} used—but there’s no alternative. TE(æ)A,ea. (talk) 14:38, 16 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)

Template:EB9

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

Table of Contents help

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

@Rajasekhar1961 Which pages are the table of contents on? Thanks, Cremastra (talk) 15:37, 25 May 2024 (UTC)

Page:Indian Medicinal Plants (Text Part 1).djvu/24 through 39. then transclude on the index page. --Slowking4 ‽ digitaleffie's ghost 19:02, 25 May 2024 (UTC)

I could help, though there's the question of how. I'm going to use {{TOC row 1-dot-1-1}}, instead of the {{dtpl}} used on the first page, due to the size of it. — Alien333 (what I did & why I did it wrong) 19:08, 25 May 2024 (UTC)

@Alien333 Given that Chrisguise's TOC had approx.~500 entries, and this looks to have over 1000, is either SimpleTOC or, dare I say it, not dot-leaders whatsoever, going to be required (given the number of phantoms that the SimpleTOC might need, unless there is a good way to embed SimpleTOC's in another table)? TeysaKarlov (talk) 00:53, 26 May 2024 (UTC)

Hmmm. It's true that the TOC row's may be excessive here, but embedding tables is definitely not the way to go to reduce post expand size. Transcluding the first two pages with {{TOC row 1-dot-1-1}} is already a third of the maximum expand size, so I'm going to try with {{TOC row 1-1-1-1}}. — Alien333 (what I did & why I did it wrong) 07:10, 26 May 2024 (UTC)

@Rajasekhar1961 It's done. — Alien333 (what I did & why I did it wrong) 18:29, 26 May 2024 (UTC) EDIT: Well, looks like it's not over after all. The TOC manages to transclude entirely, but the PD-US after breaks down. {{TOC row 1-1-1-1}} is as near a raw HTML table as I can think of, so I don't know how we'll do this. I also moved the preface to a subpage, but still. I think there's just no way of making it fit on one page. — Alien333 (what I did & why I did it wrong) 18:45, 26 May 2024 (UTC)

Took a quick look. The PD template looks like that because it is missing the CSS styling, possibly because of the "Unstrip post-expand size" exceeds 5MB warning. Someone with more experience of mediawiki internals might understand why that error blocks the loading of the styles from {{License/styles.css}}. MarkLSteadman (talk) 23:50, 26 May 2024 (UTC)

Possibly because each row gets set with the class attribute, where it might be more scalable to use page styles to define once per a column? MarkLSteadman (talk) 00:40, 27 May 2024 (UTC)

I'll try using a bare something like |- | {{{1|}}} || {{{2|}}} || {{{3|}}} || {{{4|}}}, removing the class in the template, and instead putting it in the {|, as classes like __toc_row_1-m-1-1 appear to be passed to child nodes. — Alien333 (what I did & why I did it wrong) 05:50, 27 May 2024 (UTC)

Well, that did it. Removing the row classes brought it from 6MB to 180KB. I put it in {{TOC row min-4}}. It's a good idea to remove the row classes, put the class of most lines in {{TOC begin}}'s class parameter and override for the few cases we need. — Alien333 (what I did & why I did it wrong) 06:57, 27 May 2024 (UTC)

Note that The Art of German Cooking and Baking and Statesman's Year-Book 1913 both have the same issue as well. MarkLSteadman (talk) 07:08, 27 May 2024 (UTC)

Done Fixed them with {{TOC row min-3}}. Their unstrip sizes are now respectively 800KB and 1MB. — Alien333 (what I did & why I did it wrong) 07:42, 27 May 2024 (UTC)

Every new generation of contributors invent new templates to produce toc tables, thinking surely, surely, there must be a better and easier way to do this. Slowly but surely, if they stick around, they discover all the problems with wrapping table syntax in templates; but the myriad overlapping and multiplying templates persist. Now we've gotten to the point where we have templates that literally just spit out…

|-
| {{{1|}}} 
| {{{2|}}} 
| {{{3|}}}

…instead of typing…

|-
| || Constitution and Government || 4

…and requires you to manually add another template to attach a stylesheet. That is, it is literally more complexity for less functionality than doing the same with normal table wikimarkup and Help:Page styles. I despair…

Pretty please with sugar on top, stop using templates for tables of contents and stop creating ever more templates to spit out some custom combination of template markup. Please? --Xover (talk) 13:50, 30 May 2024 (UTC)

I know that these templates seem a bit useless, but it's in case someone not familiar with table markup has a large TOC to deal with.

I don't think they really want to know that it works by removing the row classes and that therefore it's just simple table markup.

EDIT: The advantage is also that it's easier to integrate it with the other TOC row's.

The tables to be fixed with this are often started before the problem is recognised, and it's much easier to just to a search-and-replace from whatever there was before to another template name than having to painstakingly replace the template starts by |- | and some but not all |'s with ||.— Alien333 (what I did & why I did it wrong) 16:57, 30 May 2024 (UTC)

Don't take my ranting to heart; it's a long-standing and generalised frustration.

Yes, when creating a point solution to this one specific problem this was a rational approach. I'm saying that, in general, these templates by merely existing create the expectation that they should be used and is somehow better than plain table markup (and we keep amassing more and more of them). In reality they cause more problems than they solve, and contributors who struggle with the complexities of creating tables of contents have no easier time of it with the templates than they would with the table markup. Rajasekhar1961, for example, is a prolific and long-standing contributor whose strengths simply lie elsewhere than table of contents creation. No template we ever create is going to change that.

IMO, we should bulk deprecate all the toc templates and focus our efforts on documentation, how-tos, community assist, and maybe some tooling to make table wikimarkup + Page styles easier and more efficient to use. Xover (talk) 17:21, 30 May 2024 (UTC)

I agree about the whole documentation bit (I often grumble to myself about it), but I will stay a fervent defender of templates.

Template's primarily utility of factorizing formatting is indeed reduced when the template call is as long as the formatting, but they also factorize change.

If we make a decision, change our mind or just find a better way to do it, if it's a template we only have to fix one page, if it's direct formatting we have to fix all of them.

And specifically for the TOC templates, apart from the whole dot leader mess, they are I think simpler than table markup. Take for instance {{TOC row 3-1}}.

What's quicker, {{TOC row 3-1|a|b}} or |- |colspan=2 style="width:99%;text-align:left"|a |style="text-align:right"|b?

And that's excluding the other things like padding, vertical align or wrapping that make it nicer although they're not necessary — Alien333 (what I did & why I did it wrong) 17:41, 30 May 2024 (UTC)

See Help:Page_styles#Tables_of_contents. You can have just table markup and still get your fancy formatting in a more reusable way, no templates needed. You can do arbitrarily complex formatting that way without a proliferation of templates, but it really shines for the simpler more regular tables of contents. Xover (talk) 18:29, 30 May 2024 (UTC)

The only update you can do with table styles that will propagate is changing the classes, if any more significant changes are to be made they have to be made individually. As you said, it works best for simpler TOCs, and it's to be expected that we have many different templates when there are so many ways for a TOC to be different. — Alien333 (what I did & why I did it wrong) 18:44, 30 May 2024 (UTC)

We're getting far afield, but… You're trying to teach grand-pappy to suck eggs. Yes, in almost every case we should use template wrappers over raw formatting markup. But for tables the markup syntax is not suited to wrapping with a template and creates endless problems. And the use case (toc tables) in effect requires creating a completely new microsyntax to cover all the cases, at which point all you've done is make it less accessible because you can no longer rely on general knowledge of (and documentation and howtos for) tables and CSS. The important part of working with toc tables is describing the structure of the table; and changing the structure of the table is not something you can reliably do through the template abstraction. Any formatting and similar is more readily and reliably handled with page styles (or an approach like {{auxiliary toc styles}} in a pinch). Xover (talk) 06:18, 31 May 2024 (UTC)

Thank you everyone for the help. I do not know the technical aspects. Is it possible to link the subpages of the species to their corresponding pages.--Rajasekhar1961 (talk) 09:33, 29 May 2024 (UTC)

I'm not sure what you mean, can you clarify? — Alien333 (what I did & why I did it wrong) 09:35, 29 May 2024 (UTC)

See this page Indian Medicinal Plants/Natural Order Moringeæ; It has two plant species 336 and 337. Is there any necessity to link these individual species of plants from Table of Contents.--Rajasekhar1961 (talk) 11:32, 29 May 2024 (UTC)

No, there's no real necessity. On top of that, I fear that it would be too large if we add 1381 more links. — Alien333 (what I did & why I did it wrong) 11:37, 29 May 2024 (UTC)

You can add {{anchor+}} and then link via ChapterName#AnchorName if you really want to, but in general, there is no need and it makes the chapter divisions less clear. Other works with Chapter composed of many small sections we don't typically break up and link either. MarkLSteadman (talk) 12:53, 29 May 2024 (UTC)

Move Template:Dhr to TemplateStyles

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

You'll find someone somewhere has been using it instead of em-dashes inside link markup, which means it'll break if you change it to use TemplateStyles. I still  Support doing so, of course, but we have way way too much baggage to imagine any such change to go without breaking something. Xover (talk) 17:41, 30 May 2024 (UTC)

Yeah, hacky stuff is guaranteed to break eventually, so I'm not worried if this is what does it :D —Beleg Âlt ^BT (talk) 17:42, 30 May 2024 (UTC)

I don't think I got it right, did you really mean someone used {{dhr}}, a spacing template, to replace an emdash? — Alien333 (what I did & why I did it wrong) 17:43, 30 May 2024 (UTC)

I think they just mean that there's a good chance that someone, somewhere, used {{dhr}} in a really weird and unpredictable way. —Beleg Âlt ^BT (talk) 17:44, 30 May 2024 (UTC)

I was thinking {{rule}} for some reason, but, yeah, as Beleg sussed I was speaking more in the general sense. Assume that someone has abused any template in ways horrifying to anyone technically inclined, and plan accordingly. Xover (talk) 18:32, 30 May 2024 (UTC)

+1  Support and good luck dealing with all the horrifying things you find along the way. —CalendulaAsteraceae (talk • contribs) 18:54, 30 May 2024 (UTC)

Where are the test cases and such for us to look at? Without that, it's hard to identify known edge cases, or even determine what situations were checked. --EncycloPetey (talk) 18:59, 30 May 2024 (UTC)

The test page for this template is located at Template:DoubleHeightRow/testcases (which is linked from the documentation page for Template:DoubleHeightRow) —Beleg Âlt ^BT (talk) 19:16, 30 May 2024 (UTC)

Granted, but where can we see the results of the sandbox testing you say you performed? That's what I'm asking. There is no proposed code linked, and no demonstration of how the proposed code will work.  Oppose the introduction of secret code tested without public access to the results. --EncycloPetey (talk) 19:39, 30 May 2024 (UTC)

Umm, not sure, but Template:DoubleHeightRow/sandbox contains code marked experimental and using Templatestyles, so I think this is it. — Alien333 (what I did & why I did it wrong) 19:41, 30 May 2024 (UTC)

The proposed changes, as I said, are in the sandbox (which is located at Template:DoubleHeightRow/sandbox) and the demonstration of how it works is in the test cases page (which is located at Template:DoubleHeightRow/testcases). —Beleg Âlt ^BT (talk) 19:42, 30 May 2024 (UTC)

Also, the code is hardly "secret", it's literally just copy-pasting some CSS from Template:DoubleHeightRow to Template:DoubleHeightRow/styles.css —Beleg Âlt ^BT (talk) 19:48, 30 May 2024 (UTC)

Saying "the" sandbox usually means Wikisource:Sandbox. Thank you for providing links. In any situation like this, please do provide links instead of expecting everyone to have to go track down the relevant pages themselves, especially when you are proposing a change. And you did not tell anyone at the outset what change you were proposing or where to find the code. Please do not expect your audience to be mind readers. --EncycloPetey (talk) 19:53, 30 May 2024 (UTC)

@EncycloPetey: In the context of a template "the sandbox" is usually going to mean the "/sandbox" sub-page. There's a common (cross-project) convention for templates that there are "/doc", "/testcases", and "/sandbox" sub-pages where these things live (and they're auto-linked from the documentation footer etc.). TemplateStyles stylesheets by convention live in "/styles.css", but the precise location should be manually documented (in /doc) using {{TemplateStyles|Template:Foo/styles.css}}. Similarly, any Scribunto (Lua) modules used should be documented with {{lua|Module:Foo}} (both create the visible banner in the top right area of the documentation page).

I'm guessing BT didn't specify tests and demonstrations etc. because moving it to use TemplateStyles should have literally zero visible effect (but for that massively annoying bug that the WMF seems to have no plan to ever fix, sigh): it is in itself a purely technical change that makes it easier to maintain. That they are asking for consensus here is because… well, first because, unlike me, BT is a super-nice person, of course :)… but also because technical contributors have been getting a lot of grief lately, and being tediously fastidious about getting community support first is a way to ameliorate that. Xover (talk) 05:50, 31 May 2024 (UTC)

If it takes two paragraphs to explain something after the fact, then that explanation should have been provided at the outset. It should not be assumed that all members of the community know arcane technical details that specialists "just know". And providing links to locations for relevant viewing is always a courtesy, regardless of the kind of conversation happening. --EncycloPetey (talk) 14:20, 31 May 2024 (UTC)

Badge edit error on Wikidata

Tracked in PhabricatorTask T366236

File:Temp-WD badge editing error.png

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

I can confirm this is happening to me too, so unlikely to be client-side. Phabricator appears to be down atm but I think this should be raised there. —Beleg Tâl (talk) 17:53, 31 May 2024 (UTC)

This is most likely due to T366236, and I'm guessing the fix for it will go out in this week's deployment train (in which case it should hit some time today). --Xover (talk) 09:21, 3 June 2024 (UTC)

Manual aggregation of newspaper articles versus automatic aggregation

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

In theory, the advantage is that manual aggregation can be better-organized and exclude redirects. —CalendulaAsteraceae (talk • contribs) 19:03, 17 May 2024 (UTC)

• Better is subjective, and missing articles from the index is more important than having one column versus three columns. We would probably be better of deleting unused redirects if they are cluttering the index. There are currently eight different formats for creating an index. We should standardize on one or allow an automatic and a manual aggregation, the way it is available at Wikimedia Commons. We can have Portal:Newspaper and Newspaper, with Portal:Newspaper (or the other way around) always automatic. --RAN (talk) 23:56, 17 May 2024 (UTC)
• Is anyone against me creating Portal:San Francisco Call so we can have both automatic aggregation there and manual aggregation at San Francisco Call (or the other way around) using one of the eight different formats in use throughout Wikisource. It would be the equivalent of Commons:Category:Abraham Lincoln (automatic and includes everything) and Commons:Abraham Lincoln (manual in any format you please). --RAN (talk) 02:20, 19 May 2024 (UTC)

why don't you seek a consensus about the arrangement of newspaper pages? the broken commons category process may not be the best model, rather you might want to look at the commons creator, or institution pages, or commons:Template:Wikidata_Infobox, that are wikidata generated. --Slowking4 ‽ digitaleffie's ghost 03:39, 21 May 2024 (UTC)

• @Slowking4: What do you mean by "broken commons category process", can you give examples of what you mean? --RAN (talk) 18:05, 7 June 2024 (UTC)

currently, Category:Category:Steamboat_Willie, Category:Film_characters_by_actors, and Category:Men of the <country> by name, where "the" isn't needed. apparently there is constant discussion about categories, to an uncertain purpose. it does not disseminate images. i would call that broken. you can hand curate a subject index, but what is your maintenance process? leveraging wikidata is a better method.--Slowking4 ‽ digitaleffie's ghost 19:04, 7 June 2024 (UTC)

and now an attempt at a problem statement RFC:_Automatic_categorisation_both_bane_and_gain;_work_needed_to_identify_source_of_categorisation apparently the editors think generating categories by infobox is "wrong", --Slowking4 ‽ digitaleffie's ghost 14:59, 9 June 2024 (UTC)

(the above link is broken, here's the correct one: c:COM:VP#RFC: Automatic categorisation both bane and gain; work needed to identify source of categorisation) — Alien333 (what I did & why I did it wrong) 16:07, 9 June 2024 (UTC)

Match and split

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

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

omg I missed this but I'm going to test this so hard —Beleg Tâl (talk) 16:52, 31 May 2024 (UTC)

I'm not sure if I'm doing it wrong, but I submitted The Singing Bone (Freeman)/The Case of Oscar Brodski to the match endpoint and it said Response: {"status":"recieved"}, but nothing happened on the page and the task didn't show up at https://matchandsplit.toolforge.org/status either. —Beleg Tâl (talk) 17:18, 31 May 2024 (UTC)

Update: It's working now :) —Beleg Tâl (talk) 20:56, 12 June 2024 (UTC)

Block center vs Center block

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

The {{block center}} template has been around longer and is better maintained. --EncycloPetey (talk) 01:23, 29 May 2024 (UTC)

Block center is based on a div, while center block is based on span. So, it depends on the level you need to use them at. You can't wrap block center inside a template that is a span, but you can with center block. I usually put the "where on the page" outside the "what it looks like", so nearly always use block center. Beeswaxcandle (talk) 08:01, 29 May 2024 (UTC)

Both templates are div-based. —CalendulaAsteraceae (talk • contribs) 21:25, 29 May 2024 (UTC)

I personally prefer {{center block}} because it is more consistently named with other block templates ({{smaller block}}, {{italic block}}, etc.) However, I think {{block center}} is generally more popular. —Beleg Âlt ^BT (talk) 14:04, 30 May 2024 (UTC)

Also I think there used to be significant differences between them (one of them was table based I think?) but I'm pretty sure both are more or less equivalent now. —Beleg Âlt ^BT (talk) 14:10, 30 May 2024 (UTC)

No, there are significant differences in how they're implemented. One sets the display model of the div to be a faux table and uses positioning and other weirdness. The problem is they both have a gajillion options and are being used in weird ways that rely on undocumented quirks of how they're implemented, so any attempt at consolidating them is going to trigger mobs of villagers contributors with torches and pitchforks because you've changed alignment by a pixel in some pathological edge case that was never intended to work to begin with. It can be done but it's a lot of thankless work, and I am not at all certain we could get community consensus to do so. The community would have to accept that some stuff inevitably would break along the way, and given the pushback we've had on less intrusive changes I'm not sure the appetite is there. Xover (talk) 17:37, 30 May 2024 (UTC)

Oh yeah, I'm not going anywhere near any attempts to merge those templates :D —Beleg Âlt ^BT (talk) 17:45, 30 May 2024 (UTC)

Are you sure? I'd be prepared to offer 150% of your base admin hourly rate! :) Xover (talk) 18:37, 30 May 2024 (UTC)

Is there any difference between these that could not be effected by a single template with parameters added to toggle between specific functionalities? BD2412 T 01:38, 1 June 2024 (UTC)

I've done some work to bring the templates closer together (making sure they have the same gajillion options and simplifying the code somewhat). At this point, the differences in implementation are:

.wst-center-block {
	display:block;
	width:fit-content;
}
.wst-center-block-title {
	display:inline-block;
	width:100%;
}

.wst-block-center {
	display:table;
	width:auto;
}
.wst-block-center-title {
	display:table-caption;
}

I also added some tracking categories:

• Category:Pages using center block with title parameter
• Category:Pages using center block with style parameters
  • Category:Pages using center block with class parameter
  • Category:Pages using center block with height parameter
  • Category:Pages using center block with width parameter
  • Category:Pages using center block with max-width parameter
  • Category:Pages using center block with align parameter
  • Category:Pages using center block with style parameter

—CalendulaAsteraceae (talk • contribs) 03:44, 10 June 2024 (UTC)

I've discovered a practical difference in behaviour: {{center block}} will ignore a floated element in its margin, but {{block center}} will be shifted to the side and centered in the remaining space. See for example Page:The baby's opera - a book of old rhymes, with new dresses (IA babysoperabookof00cran).pdf/11. —Beleg Tâl (talk) 15:29, 12 June 2024 (UTC)

That's good to know about! Which behavior do you think is preferable? (I'd be inclined to say the template should account for the floated element, but I'm open to opposing arguments.) —CalendulaAsteraceae (talk • contribs) 17:25, 12 June 2024 (UTC)

The Kojiki is incomplete

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

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

There is a contradiction you seem to be missing here. With historical texts it can be impossible to obtain primary sources, and often secondary sources can have their own historical merit, especially in the case of translations, which this is. For *any* translation there is no primary source in the first place. Often having multiple reprints translations of a work is important to understanding it's context.

By all means mark a work as a degraded copy/translation/etc, but do not use that as an excuse to exclude important works. Just mark them appropriately. 216.67.62.63 20:00, 17 June 2024 (UTC)

I think you are confusing primary / secondary source with primary / secondary transcription. We accept copies of published editions, as long as the transcription is directly from that published edition or translation. What we do not accept is a copy-paste from an internet transcription such as Project Gutenberg or other websites. The transcription in that case is once removed from the published source. It is second-hand transcription; and that is what we do not allow. We need a scan of the publication or text being transcribed. It does not have to be a primary source; it simply cannot be second-hand. --EncycloPetey (talk) 20:19, 17 June 2024 (UTC)

• Immanuelle: The main reason that that would be a bad thing is because the copy at Kojiki (Horne) is the exact same as the copy at The Sacred Books and Early Literature of the East/Volume 13/Book 1, just with the footnotes removed. It is not, to my knowledge, an official later edition, just an on-line version of the text only. I’m working on the original version (which has more footnotes) right now at Index:Kojiki by Chamberlain.djvu, with another user helping with the Japanese text (which is very hard to read because of the scan quality). TE(æ)A,ea. (talk) 21:33, 29 May 2024 (UTC)

  @TE(æ)A,ea. I can try to help with the Japanese text. This is Immanuelle, I’m just logged out right now. Although it will probably take me a few weeks since I’m on a trip to Japan right now. 220.156.77.119 02:59, 30 May 2024 (UTC)

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

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

 Support —CalendulaAsteraceae (talk • contribs) 20:04, 30 May 2024 (UTC)

 Support (and this should not be controversial). Xover (talk) 05:22, 31 May 2024 (UTC)

 Comment What would be the point of merging the two templates? Why not just pick one to be replaced by a redirect to the other? --EncycloPetey (talk) 14:57, 31 May 2024 (UTC)

... that's just the same thing with different wording —Beleg Tâl (talk) 15:26, 31 May 2024 (UTC)

No, it isn't. Merging is deletion of one item, moving the other to its location, deleting, then undeleting so that the edit histories are merged. Merging includes the merging of edit histories, not the simple deletion/replacement of one item. --EncycloPetey (talk) 15:44, 31 May 2024 (UTC)

Oh, lol. To clarify: I am proposing to merge the functionality of these templates via redirecting one to the other so that they are both the same template. I do not remotely care at all whether their edit histories are also merged. —Beleg Tâl (talk) 16:55, 31 May 2024 (UTC)

Then this isn't a proposed merge. It's a proposal to replace one of two items with a redirect, without telling us which one will be replaced with a redirect and which one will be kept. Nothing is actually being merged.

Your statement "I do not remotely care at all whether their edit histories are also merged" is very troubling, as it shows a blatant disregard for copyright attribution requirements central to all Wikimedia projects. I suggest reading up on w:Wikipedia:Merging before proceeding. --EncycloPetey (talk) 17:53, 31 May 2024 (UTC)

I would assume that the edit history would be maintained under whichever title is redirected to the other. Not to be pedantic, but copyright is inapplicable to functional elements presented in their simplest expression. I don't think there is anything at all that could be subject to copyright protection here. BD2412 T 02:08, 1 June 2024 (UTC)

Yeah, otherwise the implication is that any replacement of a page with a redirect is a copyright violation, it would seem —Beleg Tâl (talk) 15:24, 10 June 2024 (UTC)

 Support merge/redirect to Template:Hidden text. Even under the hood, these are functionally exactly the same thing. As to the merge target, I prefer the name that offers the more straightforward description. BD2412 T 01:36, 1 June 2024 (UTC)

Yes, I agree that {{Hidden text}} is the better name. —Beleg Tâl (talk) 15:23, 10 June 2024 (UTC)

 Support: seems like the sensible thing to do. Cremastra (talk) 18:23, 19 June 2024 (UTC)

Well, it's been a week since last comment now, and no one appears to have a problem with it, so I suggest we do it. Any objections? If not, I guess I'll just go ahead with it. — Alien333 (what I did & why I did it wrong) 09:03, 19 June 2024 (UTC)

Done: redirected {{Phantom}} to {{Hidden text}}. — Alien333 (what I did & why I did it wrong) 12:37, 20 June 2024 (UTC)