Wikisource:Scriptorium

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

Proposals

Request that English Wikisource be added to Commons deletion notification bot

Per an earlier discussion, it sounds like it would be useful for Wikisource to be notified when files in use here are nominated for deletion on Commons. The Commons deletion notification bot run by the WMF Community Tech team provides such a service. We just have to have local consensus for using the bot and then make a request on Phabricator. If you have any opinion about this, please make it known below. Nosferattus (talk) 02:16, 10 December 2024 (UTC)

 Support - not only useful for copyright reasons but for the fact that for almost every Index, there are hundreds of page namespace pages that would have to get mass-deleted / mass-moved etc. every time something is deleted, so better to know ahead of time to prepare our admins for that in advance. SnowyCinema (talk) 02:40, 10 December 2024 (UTC)

provisional support—provided that the notifications are restricted to files that are relevant to enWS and that the notifications are prior to deletion rather than post-deletion. Beeswaxcandle (talk) 05:42, 10 December 2024 (UTC)

 Support, would be useful to be able to import files. @Beeswaxcandle: From what I can see of this bot's edits, it only makes "file has been nominated for deletion" pings, which are pre-deletion. Also, it only notifies a Talk: page when a file used on it or on its item is getting nominated, so I don't think we're going to get flooded by irrelevant files. — Alien  3
3 3 06:29, 10 December 2024 (UTC)

 Support per all above. We should not be caught unawares by actions on another project. BD2412 T 05:15, 21 December 2024 (UTC)

 Support --Jan Kameníček (talk) 18:27, 23 December 2024 (UTC)

Bot approval requests

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

User:Leaderbot

For meta:Global reminder bot - the bot will rarely run here, but this wiki requires explicit authorisation, so putting it here. Please ping me in a response. The bot flag is NOT required. Leaderboard (talk) 09:34, 7 November 2024 (UTC)

@Beeswaxcandle, is this something you can assist at? Thanks in advance. Leaderboard (talk) 08:36, 25 November 2024 (UTC)

Given no opposition, as per the policy I am turning on the bot here, though I do not expect it to post anytime soon. Please let me know if there are issues. Leaderboard (talk) 06:07, 1 December 2024 (UTC)

Repairs (and moves)

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

See also Wikisource:Scan lab

Page moves in Index:Mathematical collections and translations, in two tomes - Salusbury (1661).djvu

The existing scan is incomplete, so I will be replacing it with a complete version. To support this, please carry out the following page moves.

• Index page name = Index:Mathematical collections and translations, in two tomes - Salusbury (1661).djvu
• Page offset = 1 (i.e. /10 moves to /11)
• Pages to move = "10-456"
• Reason = "inserted missing pages"

Thanks Chrisguise (talk) 16:28, 4 September 2024 (UTC)

@Chrisguise: Done Xover (talk) 16:47, 4 September 2024 (UTC)

Thanks. I've uploaded the new file. Chrisguise (talk) 18:25, 4 September 2024 (UTC)

Hi, really sorry about this but I missed a couple of variations when I requested the move above. Could you please do the following:—

• Index page name = Index:Mathematical collections and translations, in two tomes - Salusbury (1661).djvu
• Page offset = 1 (i.e. /115 moves to /116)
• Pages to move = "115-274"
• Page offset = -1 (i.e. /409 moves to /408)
• Pages to move = "409-454"
• Reason = "realigned pages"
• Delete = /705 & /706
• Reason = "pages not in work"

Thanks Chrisguise (talk) 14:21, 5 September 2024 (UTC)

Hi (again). Could you hold fire on this request. There's something odd going on with the index page. When I click on some pages they show a page image from the new file (gold trim to covers is visible) and some show the original file (plain brown cover edges visible). I've tried purging the Commons page where the file resides and the individual pages on WS, and things seem to be improving (slowly) but everything has clearly not properly updated yet. Chrisguise (talk) 14:42, 5 September 2024 (UTC)

@Xover Whilst there are still one or two pages of the old scan showing, they do not affect the pages needing to be moved. Could you do the two moves and deletion set out above? Thanks, Chrisguise (talk) 15:41, 10 September 2024 (UTC)

File:The Eye of Argon.djvu

Recently found that a near-complete scan of the fanzine this story appeared in (and confirming that it was printed with no copyright notice) was on the internet, so the existing partial scan can be moved to the new index.

• Pages to move:
  • Page:The Eye of Argon.djvu/1 -> Page:OSFAn-10 (1970).pdf/1
  • Page:The Eye of Argon.djvu/2 -> Page:OSFAn-10 (1970).pdf/28
  • ...
  • Page:The Eye of Argon.djvu/24 -> Page:OSFAn-10 (1970).pdf/50
• Add pages Page:The Eye of Argon.djvu/25 and Page:The Eye of Argon.djvu/26 to File:OSFAn-10 (1970).pdf

-ei (talk) 00:38, 26 October 2024 (UTC)

It sounds as though the file needs to first be repaired to include the missing pages. The PDF is incomplete, and missing pages. --EncycloPetey (talk) 03:29, 5 December 2024 (UTC)

Spectacles and eyeglasses, their forms, mounting, and proper adjustment

I foolishly renamed the PDF on Commons while transcribing, and it broke stuff.

• Index:Spectacles and eyeglasses, their forms, mounting, and proper adjustment (IA spectacleseyegla00phil).pdf renamed to
• Index:Spectacles and eyeglasses- their forms, mounting, and proper adjustment 1895 (2nd edition).pdf

What should I have done? HLHJ (talk) 15:12, 11 November 2024 (UTC)

Thanks to MarkLSteadman for fixing it. HLHJ (talk) 15:53, 11 November 2024 (UTC)

Done with tranclusion updated. Let me know if I missed anything or you have any issues. MarkLSteadman (talk) 16:30, 11 November 2024 (UTC)

Will do, but it all seems to be working perfectly now. HLHJ (talk) 03:47, 12 November 2024 (UTC)

File:Cambridge Modern History Volume 1.djvu and File:Cambridge Modern History Volume 2.djvu

I think these files can be moved to Commons as they should be in the public domain in the UK too. Among all the editors and authors for volume 1, the latest death year is 1938 which puts it in the public domain in the UK and its publication date of 1902 puts it in the public domain in the US. The list of authors by chapter can be found here. Can someone validate this and move the files to Commons?

For volume 2, the latest death year is 1948, which should also be in the clear. Ciridae (talk) 17:59, 14 November 2024 (UTC)

Index:Fiddlers house Colum.djvu

Something has gone wrong. This page shows invalid interval and there are a number of pages which show nothing linking to them. I don't know enough to work out what needs to be done. @Packer1028, @ShakespeareFan00 @Xover - you have worked on this. Any ideas ? -- Beardo (talk) 03:10, 13 December 2024 (UTC)

Beardo This file has been deleted at commons. commons:Commons:Deletion requests/File:Fiddlers house Colum.djvu. I discovered this by using that special purge button (the swirly arrow) found on index pages.--RaboKarbakian (talk) 12:14, 13 December 2024 (UTC)

Yes, but the file page contains the message "Do not copy this file to Wikimedia Commons." implying that there should be something there. Is that the problem - does the file need to be uploaded again there ? -- Beardo (talk) 12:49, 13 December 2024 (UTC)

It was migrated to a local copy because of the Commons deletion. That local copy on WS isn't rendering / parsed properly (as the File view shows 0 pages) which causes the Index page to not find anything to render. Why it is not parsed into pages on the File page I do not know, the file works downloaded to my local machine .... MarkLSteadman (talk) 12:55, 13 December 2024 (UTC)

@Beardo I've removed the "Google page" and it looks fine. // M-le-mot-dit (talk) 15:24, 13 December 2024 (UTC)

@M-le-mot-dit - excellent. -- Beardo (talk) 18:18, 13 December 2024 (UTC)

Other discussions

Bars and manicules and other old timey items

Do we have a page that shows the bars and manicules and other old timey page flourishes, so I can match the closest ones to use in a transcription? They are easier to match by sight rather than by name. Do we have a Help:Flourishes or Help:Visual Elements, or something similar? Is there a collective name for all these types of visual elements? RAN (talk) 01:52, 16 October 2024 (UTC)

I'm not aware of such a page, and it sounds like a good idea! The following pages might be helpful:

• w:List of typographical symbols and punctuation marks
  • w:Asterism (typography)
  • w:Fleuron (typography)
  • w:Manicule
• Category:Typography templates
• Help:Beginner's guide to typography § Symbols and special characters

—CalendulaAsteraceae (talk • contribs) 22:19, 16 October 2024 (UTC)

I'm not exactly sure how they could be organized. But, it'd be an extremely helpful page. I'd say, let's be bold and create it. SnowyCinema (talk) 23:03, 16 October 2024 (UTC)

☛ I just looked these up. ☚ They don't look very old timey though. I made a list of things I needed for a while. User:RaboKarbakian/Symbols. There was an extra special challenge ( ⛐ ) to get the text (and not emojified) astrological symbols.--RaboKarbakian (talk) 01:35, 17 October 2024 (UTC)

It's a shame that Unicode Charcter charts aren't necessarily license compatible with Wikisource.. (Or possibly in scope , for that matter).. ShakespeareFan00 (talk) 20:36, 18 October 2024 (UTC)

There are now lots of (partial) license-compatible Unicode implementations. They would have charts we can use. HLHJ (talk) 15:41, 18 November 2024 (UTC)

See also Dingbat and Commons:Category:Typographic ornaments. The alternate name "printers' ornament" may also be useful for searching. HLHJ (talk) 15:48, 18 November 2024 (UTC)

• @RaboKarbakian: You should move your page to Help:Symbols and link to a new page we can call Wikisource:Typography or Help:Typography. I am going to concentrate on non-ASCII decorative elements. --RAN (talk) 20:23, 18 October 2024 (UTC)

IIRC theres also a BIG chart/list of symbols attached to a US -GPO style manual that various contirbutors here tried to put the relevant unicdoe symbols in? . ShakespeareFan00 (talk) 13:42, 17 October 2024 (UTC)

ShakespeareFan00, you mean this: U.S. Government Printing Office Style Manual/Signs and Symbols, also, thank you for fixing the sun and moon!--RaboKarbakian (talk) 14:21, 17 October 2024 (UTC)

The "floral heart" in Unicode is termed an "aldus leaf" on Commons, and there is a category of various orientations there. --EncycloPetey (talk) 20:37, 18 October 2024 (UTC)

Side note, but while searching I found both {{manicule}}: ☞, and {{finger}}: ☞. These two probably need to be merged. — Alien  3
3 3 05:16, 17 October 2024 (UTC)

Good catch! —CalendulaAsteraceae (talk • contribs) 06:03, 17 October 2024 (UTC)

• Some will be ASCII characters and some will be jpg elements. --RAN (talk) 12:25, 17 October 2024 (UTC)

I recently created {{fleuron}}, which may be of interest to this discussion. —Beleg Tâl (talk) 22:33, 22 October 2024 (UTC)

Also of note: Category:Special character templates —Beleg Tâl (talk) 22:34, 22 October 2024 (UTC)

@Richard Arthur Norton (1958- ): Did anything come out of this discussion? Having a reference page would be super useful. I saw that you asked RaboKarbakian to move their page into the Help namespace, but it doesn't look like that happened. Nosferattus (talk) 20:06, 29 November 2024 (UTC)

Nosferattus I welcomed RAN to copy/paste on the talk page but I am unlikely to move my notes. After that, HLHJ edited my notes, and probably that is okay (I haven't looked to see what was changed). And that is all that I know.--RaboKarbakian (talk) 20:26, 29 November 2024 (UTC)

Apologies if I've overstepped; I noticed you had left the box for the name of the therefore sign blank, so I added the name, linked to Wikipedia. Then I was thinking "Oh, the pilcrow should be linked to Wikipedia too, and I should add paragraphus marks, which are closely related, and some other common sectioning marks..." and I did. And then I thought maybe I should leave it to you. Feel free to delete any of the stuff I added, I will not be in the least offended.

Speaking of pilcrows, in Preferences>Gadgets, there is "Generate paragraph (pilcrow) markers, ¶ , in the left margin of the Page: namespace to indicate HTML paragraph tag starts", which I find quite useful. HLHJ (talk) 03:08, 30 November 2024 (UTC)

• I will have time to work on it shortly, it will start as a list of lists to direct people to what already exists as standalone pages, and add some new standalone pages. Just compiling all the dashes was time consuming. I have a backlog of news articles I have to load this month, before I lose track of them. --RAN (talk) 18:33, 4 December 2024 (UTC)

Qid

Is there any place we can add a Wikidata qid so a bot adds the portal or the news article to the corresponding Wikidata entry? RAN (talk) 03:53, 26 October 2024 (UTC)

Wouldn't that be adding a sitelink to the wikisource page to the item? — Alien  3
3 3 08:15, 26 October 2024 (UTC)

• Yes, we could have: {{author | firstname = Tirey Lafayette | lastname = Ford | last_initial = Fo | '''wikidata = Q7809200''' | description = American lawyer and politician; California Attorney General, District Attorney from California }}

That way a bot at the Wikidata end could add the Wikisource link automatically, and they would be paired at both projects.

What I'm saying is that is already done, you just have to add it at the other end, at WD. When an item has for example a sitelink to one of our authors, {{author}} picks it up, takes the data, and puts a link to the item.— Alien  3
3 3 14:39, 26 October 2024 (UTC)

• The idea is to have a bot perform that function. --RAN (talk) 01:21, 27 October 2024 (UTC)

  What I don't understand is what would the bot do? We'd already give it the QID, and the link that needs to be added to the corresponding item. This wouldn't be much simpler than just going to the WD item and adding the link manually? — Alien  3
  3 3 08:37, 27 October 2024 (UTC)

• I found that "wikidata=" is already in every header template for both portals and individual books/news articles, so the first part is already in place. Any function that can be performed by a bot is superior to doing it by hand. I found that there are already >50 entries that have Wikidata ids but do not appear in Wikidata. "Pi bot" performs this function linking wikidata to Commons categories when it finds matching Qids. --RAN (talk) 22:58, 12 November 2024 (UTC)

  (I previously didn't get that you meant having a bot search, rather than already give it the ids.) We could do that. — Alien  3
  3 3 12:24, 17 November 2024 (UTC)

• I should have written it more clearly, I contacted the creator of pi_bot, but they have not responded. One thing I noticed is that an occasional wikidata number at Wikisource is incorrect, probably from a cut and paste error, would the bot fix an error if we replace the Wikidata number here with the correct one after it already has added the incorrect one? --RAN (talk) 18:05, 17 November 2024 (UTC)
• @Alien: What would it take to get the bot written and approved? You can copy pi_bot, which performs the same function at Commons. When it find a "qid=" in a commons category, it then goes to Wikidata and if "commonswiki=" is empty, it adds the category name at Wikidata. If it find a mismatch, it makes a correction, so if a qid gets changed at Commons, the corresponding entry at Wikidata gets updated with the new value. This is for when people make errors or cut and paste a template with the wrong value in it already, and correct it later. --RAN (talk) 15:49, 21 November 2024 (UTC)

  @Richard Arthur Norton (1958- ): (The 333 is part of my username)

  I don't like using code I don't understand, and we have a simpler use case, so I fiddled a bit with pywikibot, and I made this, that seems to work:

code

import pywikibot as pwb 
from pywikibot.pagegenerators import SearchPageGenerator
import re
enws = pwb.Site("en", "wikisource")
wd = enws.data_repository()
gen = SearchPageGenerator("insource:/wikidata *= *Q[0-9]+/", site=enws, namespaces=[102,100,0])
for page in gen:
    title = page.title()
    content = page.text
    try:
        page.data_item() # means that it's correctly linked and we don't care
    except:
        qid = re.match(r"(.|\n)*wikidata *= *(Q[0-9]+)", content, re.M).groups()[1]
        item = pwb.ItemPage(wd, qid)
        try:
            item.getSitelink("enwikisource") # the item already has another enws sitelink
        except:
            try:
                item.setSitelink(sitelink={"site":"enwikisource", "title":title}, summary="added missing sitelink to English Wikisource (bot)")
                print("Added sitelink "+title+" to the item "+qid)
            except:
                print("Error: Addition of sitelink "+title+" to the item "+qid+" was skipped")
print("All pages done.")

• I've done some experimenting, take a look at d:Special:Contribs/Alien333.

  There are about 65 authors, 117 portals, and 615 mainspace pages that manually link to a WD item.

  It as of now finds, across these three namespaces, 147 of them which are not as sitelinks on their WD item.

  From an administrative point of view, this only edits at wikidata, so it's there a bot request should be made.

  Thoughts? — Alien  3
  3 3 19:56, 21 November 2024 (UTC)

  Account created at User:333Bot, and BRFA started at d:Wikidata:Requests for permissions/Bot/333Bot. — Alien  3
  3 3 08:16, 22 November 2024 (UTC)

• Good stuff! If we change the Wikidata number here, will it make a correction at Wikidata? In the past I made two cut and paste errors where I had the wrong Qid here, and had to change it to the correct one, would the bot find that we changed the qid here and replace the incorrect with the correct at Wikidata? Or does it just make one pass and not look for mismatches? --RAN (talk) 17:42, 23 November 2024 (UTC)

  Those were the 50 "official" test edits for the BRFA. Until I get approval, though, I won't be able to do any more.

  For now, as long as the item already has a sitelink, or that the ws page is already an item's sitelink, it assumes that it's not smart enough to do this and it ignores it.

  It could be a good idea to make it do that, but we should think carefully about it. It, at first, didn't care about an item already having an enws sitelink, and it crushed it in a few places. It's not often a good idea to do so. An example with The Count of Monte Cristo (dab page), The Count of Monte-Cristo (specific work) and d:Q191838, the item. Both the dab page and the work link to the item. Which should be kept? It depends on a lot of factors. — Alien  3
  3 3 17:52, 23 November 2024 (UTC)

@Richard Arthur Norton (1958- ): First run completed, will run every sunday morning from now on. — Alien  3
3 3 10:08, 1 December 2024 (UTC)

• @Alien333: It worked amazingly well, one type it missed was the new surname categories. See for example Category:Winblad (surname) linking to Wikidata=Q20661912. I started adding surname categories for portal and author space as an experiment. One of the problems was the creation of duplicates because you were never sure is someone was listed as "John Smith" or "John Smith Jr." or "John Smith II" or "John Allan Smith" or "John A. Smith" or "John Smith (1901-1982)". Once you look at the list it becomes obvious if they were already added. --RAN (talk) 20:26, 1 December 2024 (UTC)

Android app for Wikisource

Hi, is there an Android app for Wikisource? How does it work? I have been advised that there is no infrastructure for push notifications for Android apps for sister wikis and I would be interested to know more. Related: phab:T378545. Thanks! Gryllida (talk) 23:14, 29 October 2024 (UTC)

There is no app for Wikisource at all. For any platform. There is only the website.

This isn't a terribly popular website, so it's probably not worth the time to develop an app to help editors—even though I would love it. —FPTI (talk) 06:50, 25 November 2024 (UTC)

Portals in headers

The portals were traditionally listed in the portal parameter and divided by slashes. Now CalendulaAsteraceae started replacing this with individual portal1, portal2... parameters, see e. g. here, and plans to stop splitting portals at the slashes in the long run completely. As this is going to influence a really large number of pages, I think it should be discussed first, and so I am posting it here. Jan Kameníček (talk) 12:01, 3 November 2024 (UTC)

Very long run; I don't actually want to take that project on anytime soon because (as you mention) it would be a lot of work. —CalendulaAsteraceae (talk • contribs) 12:04, 3 November 2024 (UTC)

Well, you have already taken some steps, and the discussion should have preceded them.
As for the replacement itself, in my opinion it is not only unnecessary, but also unnecessarily more complicated for contributors. Slashes work well and are easy and quick to write. --Jan Kameníček (talk) 12:07, 3 November 2024 (UTC)

• The new way makes it difficult to change the order, you have to swap entries, not just move a single name to change the order. What is the advantage of the new way? Do we gain anything useful? --RAN (talk) 13:27, 5 November 2024 (UTC)

  I think the new way is overall more difficult or lengthy to type. --Jan Kameníček (talk) 15:38, 5 November 2024 (UTC)

A possible advantage of this would be to allow for the about a thousand portals that include slashes in their names to be used, though I don't know if that's a major loss. (After all, at this point there are probably more pages that use / to include multiple portals than portals that are incompatible with that.) In case anyone else is interested by the technical side of it, it's with this edit at module:plain sister. — Alien  3
3 3 14:08, 5 November 2024 (UTC)

True. It is definitely not necessary to deprecate it, it can stay optional, but should not replace the older way. And unless there is a reason in specific cases, like this one, it should not be being replaced massively by a bot. --Jan Kameníček (talk) 15:38, 5 November 2024 (UTC)

Many of the "portals with slashes in their names" are subpages that should not be linked to directly. Many others are experiemntal, or old, and are not being maintained. Another approach might be to start cleanup of those Portals that should not have a slash in their name. --EncycloPetey (talk) 03:39, 5 December 2024 (UTC)

• @Jan.Kamenicek, @CalendulaAsteraceae: While on the subject of portal space, can we drop the period (.) at the end of the list of portals. It isn't a sentence and we end up with portals for people named "Jr." and "Sr." getting a double period. --RAN (talk) 20:13, 6 November 2024 (UTC)

  That sounds good to me, and would be easy to implement without requiring any changes to how the template is invoked. I'll wait a bit in case there are any objections, but barring that, I'm happy to go ahead and make the change. —CalendulaAsteraceae (talk • contribs) 03:58, 9 November 2024 (UTC)

  Good point. BTW, if the period is dropped out from portal, it should be also dropped out from related_author for the sake of consistency, as they are displayed one above the other and it would look weird if one was finished with the period while the other was not. --Jan Kameníček (talk) 12:47, 9 November 2024 (UTC)

  (They use the same code of Module:Plain sister anyways, so if we remove that period for one of them it'd also remove it for the rest) — Alien  3
  3 3 12:49, 9 November 2024 (UTC)

  So I guess that it would affect {{Plain sister}} and other templates using it as well. Imo, it should not be a problem in any of them. --Jan Kameníček (talk) 13:00, 9 November 2024 (UTC)

  Done! —CalendulaAsteraceae (talk • contribs) 16:01, 11 November 2024 (UTC)

Switching to the Vector 2022 skin: the final date

A two minute-long video about Vector 2022

Hello everyone, I'm reaching out on behalf of the Wikimedia Foundation Web team responsible for the MediaWiki skins. I'd like to revisit the topic of making Vector 2022 the default here on English Wikisource. I did post a message about this in March, but we didn't finalize it back then.

What happened in the meantime? We built dark mode and different options for font sizes, and made Vector 2022 the default on most wikis, including all other Wikisources. With the not-so-new V22 skin being the default, existing and coming features, like dark mode and temporary accounts respectively, will become available for logged-out users here.

If you're curious about the details on why we need to deploy the skin soon, here's more information

• Due to releases of new features only available in the Vector 2022 skin, our technical ability to support both skins as the default is coming to an end. Keeping more than one skin as the default across different wikis indefinitely is impossible. This is about the architecture of our skins. As the Foundation or the movement in general, we don't have the capability to develop and maintain software working with different skins as default. This means that the longer we keep multiple skins as the default, the higher the likelihood of bugs, regressions, and other things breaking that we do not have the resources to support or fix.  
• Vector 2022 has been the default on almost all wikis for more than a year. In this time, the skin was proven to provide improvements to readers while also evolving. After we built and deployed on most wikis, we added new features, such as the Appearance menu with the dark mode functionality. We will keep working on this skin, and deployment doesn't mean that existing issues will not be addressed. For example, as part of our work on the Accessibility for Reading project, we built out dark mode, changed the width of the main page back to full (T357706), and solved issues of wide tables overlapping the right-column menus (T330527).
• Vector legacy's code is not compatible with some of the existing, coming, or future software. Keeping this skin as the default would exclude most users from these improvements. Important examples of features not supported by Vector legacy are: the enriched table of contents on talk pages, dark mode, and also temporary account holder experience which, due to legal reasons, we will have to enable. In other words, the only skin supporting features for temporary account holders (like banners informing "hey, you're using a temp account") is Vector 2022. If you are curious about temporary accounts, read our latest blog post.

So, we will deploy Vector 2022 here in three weeks, in the week of November 25. If you think there are any remaining significant technical issues, let us know. We will talk and may make some changes, most likely after the deployment. Thank you! SGrabarczuk (WMF) (talk) 15:46, 6 November 2024 (UTC)

To any admins passing by: Could someone take a look at MediaWiki talk:Gadget-Preload Page Images.js? (with V10, since the last codex change, the green border's broken so the arrow shifts down but it's still a noticeable change, whereas in V22 it will be plain undistinguishable, so it'd be nice to fix it.)

@SGrabarczuk (WMF): Why would dark mode and temporary accounts need V22? I already use dark mode on V10, and if we have a banner for IPs editing I don't see why we couldn't have a banner for temp editing.

I can only think of one significant technical issue, and that is paragraph spacing, also mentioned in March without an answer.

On one hand, why? what is the supposed advantage of spacing paragraphs further from each other?

On the other hand, here at ws we often need to make text fit into fixed boxes, and making the height of text that different across skins is a bad idea. Out of my hat, the most common issue I can think of is {{overfloat image}}s that make some kind of border around multiline text that does not already override paragraph spacing, e.g. Page:Salomé- a tragedy in one act.djvu/7, Page:Poems Tree.djvu/9, Page:Poems Jackson.djvu/7, &c. — Alien  3
3 3 18:49, 6 November 2024 (UTC)

• As someone who has seen Vector 2022 in action, I don’t know how you can say this. The use of Vector 2022 is not possible here; it makes Wikipedia much worse at it is, and at Wikisource it is completely untenable. There is no reason to make potential contributors make an account and change their setting configurations to be able to edit here without great difficulty. We have a lot of highly specialized formatting here, and if recent “fixes” are anything to go by, whoever makes technical changes thinks of Wikisource last in making them. Our site was rendered practically unusable because of an “accessibility” change recently, and it took days to get that patched—and it was only partially patched, at that. You mention “new features” for your shiny new toy, but I’m not sure why they’re necessary (or even not harmful here on Wikisource); the big push towards “dark mode” mirrors the tech industry’s general push towards AI, in that it is being done without consideration of the actual userbase (who, of course, has no need for such a feature). Your list of “[i]mportant … features” showcases the lack of connection to our community (despite your evident desire to force this unwanted and harmful change upon us): tables of contents are usually produced manually here, with templates; dark mode is a fad, and in any case would clash with any of the many texts here with images; and “temporary accounts” are a terrible idea that I can’t even imagine a justification for. I’ve only heard of them now, but I do remember the suggestion from a few years back; this change will make vandalism significantly worse without any demonstrable benefits whatsoever. Luckily, we don’t have much vandalism here, (and we have good administrators to deal with it,) but it seems (to me, at least) obvious that changes should not be made which will encourage and facilitate vandalism while making the prevention of vandalism harder (and in many cases fruitless). Of course, you’ve saved the best for last: changes will happen “most likely after the deployment.” You people, who do no good to Wikisource, Wikipedia, or any other project that actually drives traffic (beyond the moral good of writing articles, transcribing texts, &c.) see fit to make changes—without our consent—to the detriment of our work, and when problems inevitably arise force their solutions on the people you so ungraciously “helped” in the first place. I shouldn’t have bothered writing this, but your attitude in “suggesting” this change was enough to encourage me to write this quick statement down. TE(æ)A,ea. (talk) 22:51, 6 November 2024 (UTC)

• Just to be clear SGrabarczuk: If you think there are any remaining significant technical issues, let us know. We will talk and may make some changes, most likely after the deployment. – are you saying that you're planning to deploy to a live production website with over half a million views per day, without having addressed any of the issues that prevented you from deploying in April, without carrying out any user testing, and with plans only to possibly fix any breaking changes after carrying this out? What on earth is your deployment process (please link if you have one)? And what is the WMF policy about pushing changes on some communities that have serious unaddressed concerns, but not others (such as de.Wikipedia) – again, please link this. Very concerned that you're rushing this through without realising that it will greatly impact the website. --Yodin^T 11:25, 7 November 2024 (UTC)

• @SGrabarczuk (WMF): Absolutely agree with everything written above, Vector 2022 was not designed with Wikisource in mind and so should not be deployed here. --Jan Kameníček (talk) 13:13, 7 November 2024 (UTC)

  @SGrabarczuk (WMF): Does not seem that you take our concerns seriously. --Jan Kameníček (talk) 13:58, 9 November 2024 (UTC)

• yeah, while the skin is better than flat sidebar gadget, it is not better than timeless skin, so count me out until that breaks. i guess we will have to advise newbies to first change their skin preferences. --Slowking4 ‽ digitaleffie's ghost 00:49, 10 November 2024 (UTC)

@Alien333, @Jan.Kamenicek, @Slowking4, @TE(æ)A,ea., @Yodin - thank you for taking the time to share your concerns and apologies for the late reply. Many of the team working on this were traveling for a work event this week. My name is Olga and I’m the product manager for the Web team (the team that build the skin). Hopefully I can help answer some of your questions.

In the short term, we’re reviewing the more explicit requests we’ve received from Wikisource wikis to see which, if any, we can address prior to deployment. We’ll try to let you know next week on which fixes (if any) we’re planning on making and what the timeline for those fixes is. It’s possible that some of them might come after the deployment itself.

More generally, I want to reassure you that we do read through the requests and questions here, and also underline that the deployment of Vector 2022 won’t be the end of the conversation here. We’ll continue working with you as people begin using the skin - answering questions, filing tickets, fixing bugs, and improving the skin based on your feedback. Our plan is not to deploy and then leave immediately. I can’t promise that we’ll fix or work on every request - that depends on what specific issues Wikisource users have, how large they are, and how many people are exposed to those issues - but we will try to at the least reply to everything and give a status update (we specifically want to look into and continue discussing the accessibility concerns you’ve raised above) .

In general, we understand that Wikisource has unique needs. This is why we’ve introduced some Wikisource-specific customizations (such as the full width for the main namespace) in the first place. In addition - while each Wikisource community is different, there are oftentimes almost if not perfectly identical in terms of design. Almost every other Wikisource community has been using Vector 2022 for quite some time now (years for some) and we haven’t seen major issues flagged there by communities in terms of the usability of the site. Hopefully that can help ease worries around bringing the skin to a production Wikisource - it’s already live on most of them.

More specifically I wanted to address:

• Dark mode: the dark mode gadget available in Vector legacy relies on an invert method, unlike the feature-level dark mode in Vector 2022. This means that it’s easy to break or represent information inaccurately, especially in the cases of graphics, templates, or any manual color selections. This could potentially lead to common issues like content being displayed as white text on a white background, disappearing images, inaccurate graphs and data visualizations, etc. Either way, dark mode is an optional feature - we are not turning on dark mode for anyone, even if they have their browsers set to use dark mode (although for those interested that is an option that can be turned on using the setting called “automatic” in the dark mode menu)
• Temporary accounts: While we are not representing the temporary accounts team, we can connect you to folks on that team that can provide a lot more detail on why the change is important, especially as it concerns the safety and privacy of editors and communities
• Timing: As we mentioned above, this announcement is in part due to the technical burden in supporting two different default skins for logged-out users from a maintenance perspective. We are accelerating the timeline for the remaining wikis because we are no longer able to provide this support across wikis for logged-out users (logged-in users, who do not use cached pages can continue to access any skin as before)

Thanks again for sharing your thoughts - hope some of this was helpful! OVasileva (WMF) (talk) 15:46, 15 November 2024 (UTC)

And what about the breaking technical issues mentioned? Specifically, the paragraph spacing? — Alien  3
3 3 16:43, 15 November 2024 (UTC)

@OVasileva (WMF), @SGrabarczuk (WMF):: That is what I am really interested in too: The spacing problems which break our pages were mentioned as early as in March, why has it not been still solved until now, i.e. more than 7 months later? Why did you not answer this concern in March and avoid answering it now again? Why is the skin which we did not ask for planned to be deployed without solving this issue? If your team was not able to pay any attention to this until now, could you rectify it and solve the issue now before the deployment, or postpone the deployment until you solve it? --Jan Kameníček (talk) 14:27, 16 November 2024 (UTC)

@OVasileva (WMF), @SGrabarczuk (WMF):: And what is most frightening is the statement that "...I can’t promise that we’ll fix or work on every request ... but we will try to at the least reply..." Sounds like you are making just fun of us, and your answers above are in fact the embodiment of this approach: instead of solving our concerns you just "try to reply" to calm people down without any real action taken. It is not the first time I have met with this approach here, and I could see too often that it drives various zealous contributors out of WMF projects. --Jan Kameníček (talk) 14:40, 16 November 2024 (UTC)

Hello, thank you for your continued comments here and messages to us as we move towards getting everything ready for the deploy.

First, we decided to deploy next week instead. This is to give everyone some space to continue to make adjustments and keep this conversation going.

We fully recognize that the spacing issues have not yet been resolved, we didn't communicate about it earlier, and we apologize for the inconvenience this has caused.

We believe that the long-term solution would not be further adjusting the skin itself, though, but rather decreasing dependence on absolute values when making editing decisions. Yes, this means that together with you, we will need to spend more time changing the existing and new code. But there's good news - the skin is not a static product, and we plan on continuing to improve the desktop experience over time. We want to ensure that the platform evolves in a way that allows for continuous improvements.

Bearing this in mind, we wanted to say that assuming absolute values can lead to breakages as we move forward because it makes things more difficult to change across wikis. We encourage you to review Wikisource practices around expecting absolute values in the code in general.

Also, our engineers have read the conversation #Deployment of Vector 2022 and they recommend replacing .mw-body p { margin: 0.5em 0 1em 0; } with .mw-body p { margin: 0.5em 0; }. We may introduce some tweaks, but we strongly discourage from hiding the font size menu outright, too.

In terms of not being able to work on every request - we commit to working on breaking issues and significant usability improvements. However, we often get requests that do not align with the needs of most readers and editors. Some are simply technically impossible - these might be for new features, or workarounds that are catered to the needs of an individual user. Without knowing what the requests will be ahead of time, how many people they will help on Wikisource, or how difficult or technically possible they will be, we can't promise that we'll work on them. We thought this was important to point out so that we're not making empty promises.

How does this sound to you? We are curious if you have more questions, particularly about the technical side. On a side note, we can recommend the Vector (2022) and Related thread on Discord where community members discuss technical tweaks to the skin. This is a useful space for coordination in addition to the conversation we're having here.

Thanks! OVasileva (WMF) and SGrabarczuk (WMF) (talk) 22:44, 25 November 2024 (UTC)

From my perspective this sounds good, and would be good to continue to discuss in more detail 👍 --Yodin^T 06:50, 26 November 2024 (UTC)

(That css line has already been changed to that.

Oh, and that discord link you provided, at least for me, is broken.)

Thanks for delaying the deployment.

It is mostly concerning images that paragraph spacing and text size cause problems. We are aware that absolute widths are bad, but with images (except for SVGs, but a great majority of our images can't be easily SVG-converted) we can not scale them by a factor 1.4 (ratio between V22's "Small" and "Large" text) without their getting, in most cases, horribly pixelated. All the uploaded illustrations will not magically have their resolution augmented until they're 1.4 times larger than they are now. And this is not doable either, because the diversity of scan sources prevents automation (and some don't even have higher-res versions). Thus, making the images scale with the text is here not an option.

Regarding the needs of most readers and editors: it is true, that Wikisource is small, and minor, especially when compared to the Wikipedias. It is thus understandable for V22 to be thought mostly for them, and for it not to fit our needs.

But it is equally understandable that we should protest its deployment, or at least customise it through site CSS to fit our needs.

You (meaning those who made V22 in general), at least according to this page, wanted to standardise things (and btw this is rather bad communication, as it comes across as disdainful of the people who prefer V10 (which there are a great many of) and of their way of doing), specifically standardise the interface, and expressly not [...] the content (emphasis mine).

You modified paragraph spacing and set up ways to make the text larger, as that was, for WP, not part of the content.

For purely interface changes (e.g. what's in a dropdown menu or not), I mostly agree with the view that it's not necessarily worse, and people'll get used to it.

However, at WS, paragraph spacing and text size is part of the content, and V22 does as a side effect break the content.

As such, these changes break the content, and to me the best solution to that is to locally override V22 (including reverting paragraph spacing, nullifying the effect of the font-size changing, and, yes removing that select). — Alien  3
3 3 12:04, 26 November 2024 (UTC)

I think their engineers are supporting your idea of locally overriding the paragraph spacing. If the default font size was changed from "standard" to "small" on Vector 22, this would make the content exactly the same as it currently is. Would definitely be good to discuss separately and get a community consensus on how to handle {{overfloat image}}, whether to allow font resizing (I think this is worth considering, as it is basically a shortcut to see how the texts would display on different screen sizes etc.), and also how to handle dark mode, as @MarkLSteadman pointed out on Meta. [I'd also say that I am very frustrated by the way all of this was handled as well, but as they've been allocated time to implement the community consensus we should take them up on that and make sure the outcome is as good as possible for readers and editors]. --Yodin^T 14:31, 26 November 2024 (UTC)

We are going to want to support people who need larger font sizes for accessibility reasons. I also suspect that we will need to find some solution for people who read WS on a phone, where the narrower width does mean the paragraph spacing becomes important because you can no longer rely on the sentence ending mid-line as a visual cue. It's that it is difficult enough to produce high-quality transcriptions and we do want to get towards some standardized solutions to these issues rather than having individual contributors invent their own one-off solutions when they see things broken and try to fix it or become frustrated when if they log out and now their hard work looks bad. MarkLSteadman (talk) 16:13, 26 November 2024 (UTC)

Surname categories

Is there anything preventing us from having surname categories like "Category:Smith (surname)" for portals to match Commons? It would make it much easier to find news articles and portals for someone where we know their last name but they may appear as James Smith or Jack Smith, once you see them in the list you will figure out the correct person. RAN (talk) 20:14, 9 November 2024 (UTC)

• They can also link to Wikidata at "Wikisource=Category:Smith (surname)" at the surname entry in Wikidata. --RAN (talk) 18:16, 12 November 2024 (UTC)

We have Category:People in portal namespace, with a total of 39 portals about people. Few of the people who have listed portals have any surname at all. Therefore, I do not believe that instituting a categorization by surname is warranted for these portals. --EncycloPetey (talk) 03:47, 5 December 2024 (UTC)

No redirects from Portals to Author

I was always told there are to be no redirects from Portals to Author, but why? I don't see any valid reason. I only see the value of knowing that someone is an author and not the subject of works. RAN (talk) 23:48, 13 November 2024 (UTC)

Wikisource:Deletion_policy#Miscellaneous would include "unneeded redirects". Yet redirects from Portals to Author as crossing the namespaces do not automatically fall into them. Need wider talks on this.--Jusjih (talk) 04:11, 17 November 2024 (UTC)

I can imagine that a redirect from the Author NS to Portal NS can be useful. E. g. an author does not have any works eligible to be hosted in English Wikisource and so works about the author are gathered in a portal. However, some people might be searching for the author in the Author NS, because that is the place where we usually have pages on authors, and so a redirect can be helpful. For example we used to have the page Author:Socrates redirecting to Portal:Socrates, until it was deleted a few years ago as redundant, which was imo not necessary. However, the other way, i. e. redirect from Portal NS to Author NS does not really seem useful to me. --Jan Kameníček (talk) 10:22, 17 November 2024 (UTC)

I see two reasons that this might exist:

• Subject portals about particular authors. Like you want to subclass "Russian Literature" into Portals for Tolstoy, Gogol and Pushkin, or "Biology" into Mendel, Darwin, Aristotle, etc. What is the need for creating these subportals as opposed to just listing the author? And if you wanted a sub portal for separation, (e.g."U.S. Presidential Administrations" --> "Obama Administration" separate from works Obama authored) then you are trying to make a distinction that a redirect is wrong, (e.g. a memo from one official to another) And subclassing these portals with an Author creates problems anyways (is "Aristotle" a subportal of Biology, Ethics, Political Science...).
• Non-human authors, e.g. pseudonyms. I can see some situations where this might be appropriate (e.g. a letter from a fictitious company) but this seems extremely narrow.

MarkLSteadman (talk) 19:10, 17 November 2024 (UTC)

The general feeling in the past has been that works by an Author should be listed on that Author's page. Listing them again in Portal space is duplication both of function and of content, doubling the work to maintain them both. --EncycloPetey (talk) 03:50, 5 December 2024 (UTC)

• I work in news articles about people, mostly obits, so almost everyone has a portal as the subject of a news article, but occasionally someone will have written an editorial or a got a letter published in a newspaper, I would like to have the portal redirect to the author page when this occurs. Normally if someone just wrote an editorial, I would keep them as a portal, but several times others have moved them into author space. --RAN (talk) 04:31, 19 November 2024 (UTC)

When an author is the subject of a work, then the section "Works about" should be created on the Author page. Portals are for topics and there can be a link from a portal to an author. Cross-namespace redirects are not required. Beeswaxcandle (talk) 07:41, 21 November 2024 (UTC)

Yes, but we have to distinguish between book authors who may write many books, and an author of a single editorial in a newspaper. And we have to distinguish between "not required" and "banned". I have had the redirects deleted as if banned. --RAN (talk) 15:23, 21 November 2024 (UTC)

I don't understand why a distinction is needed for how much an author wrote. If a work (regardless of length) is in scope for hosting here, then the author of that work needs an Author page. Cross-namespace redirect is a speedy deletion criterion, hence their deletions. A "not required" redirect is within the same namespace from an unlikely search title or to a non-existent page that is unlikely to be created in the short-term. Beeswaxcandle (talk) 02:23, 23 November 2024 (UTC)

• I and Jan Kameníček seems to think they are "useful" and should not be deleted. The best example of no redirect is Author:Socrates and Portal:Socrates as pointed out by Jan Kameníček. I think we should keep them, and we should hear what others think as to their utility. Sometimes we have rules and forget why we created them and follow them blindly. This appears to be a hard rule that doesn't actually solve a problem, it is just a rule we follow blindly. --RAN (talk) 19:05, 23 November 2024 (UTC)

The Socrates example is the opposite to what you are asking for in this thread and Author:Socrates was not a redirect, so it's not relevant to this discussion. What is the actual problem you want to solve by creating a page in the Portal: namespace that is a redirect to the Author: namespace? What's a use case for such a redirect? Note, I'm not saying "no", I just don't have a reason to say "support" yet. Beeswaxcandle (talk) 02:36, 24 November 2024 (UTC)

• I want to be able to have non-mandatory redirects in both directions when someone is an author (author space) and the subject (portal space). The problem starts when someone is moved from Portal space to Author space, or the other way around, and it is no longer clear where they are now located. It seems like we have a hard rule that is in search of a problem. I see absolutely no problem with redirects in both directions. All other projects use redirects liberally, and we should too. Can you give me some good reasons that we do not allow them? As per Jusjih, the rule appears to be someone's interpretation of "unneeded redirects", now policed regularly. I argue that they are needed to ease finding people, without knowing if the are the subject of a news article or the author of a news article. --RAN (talk) 20:26, 24 November 2024 (UTC)

  I don't know why we forbid them, but if someone doesn't know any information but name, typing the name in the search box already brings up both portals and authors, so redirects wouldn't bring much. — Alien  3
  3 3 20:49, 24 November 2024 (UTC)

  To prevent that confusion is exactly why they shouldn't be redirects in the first point. If we are just going just going to redirect and treat Portal:Foo and Author:Foo as equivalent why even have Author:Foo? Is the idea here to always create both, then why not just have portals?

  And as I mentioned above, the problem here is that works about Foo from a subject perspective should ideally be grouped in an appropriate subject category, e.g. biographies of Tolstoy under biographies, literary criticism of Tolstoy under literary criticism, anarchists talking about Tolstoy under Anarchism, etc. If we are just going to redirect biographies of Tolstoy to Author:Tolstoy/Biographies, anarchism to Author:Tolstoy/Anarchism and recreate a parallel subject structure under Authors what is the point of portals anyway if they are just going to be collections of links to authors, why not just use Author categories?

  If we don't think the current distinction is useful, merge the two, don't create a conflicting mess where we just plop things down haphazardly between the two and then just say redirect, it doesn't really matter. MarkLSteadman (talk) 21:25, 24 November 2024 (UTC)

  I am not asking for duplicate entries, just a redirect from Portal space when someone is moved to Author space. I also agree that we do not need to have both spaces to distinguish an author from a subject, but have it historically. Every Author could have just been a Portal. We also do not "always [have to] create both"., just allow it when someone is moved. --RAN (talk) 21:35, 24 November 2024 (UTC)

  What are you linking to what that is moving? What is being moved where? Which subject area on this list Portal:Portals is the portal under that is being moved? How often are we doing things like building out a portal for Austeniana, Dickensiana, Shakespeariana under British Literature (PR) and then deciding to move them to their author pages, and need a redirect rather than just listing them under the appropriate subject area? MarkLSteadman (talk) 22:28, 24 November 2024 (UTC)

  The situation is occurring when a portal is created for a person who is the subject of a news article. It is then found that the person is an author, at which point they are moved to the Author: namespace. However, there are various links that are left pointing to the Portal. AFAIK we don't have a mechanism to automatically update those links, and thus RAN would like to retain the redirect so that the page remains within the Portal: namespace, thus allowing other news articles to also link within that namespace. I am yet to look at how these non-author person portals are being parented within the Portal structure, so that they link up to Portal:Portals, but that's a side issue to the topic of this thread. Beeswaxcandle (talk) 04:48, 25 November 2024 (UTC)

  If you think that a listing of works about a person has value, it should have value whether that person is an author or not. If we create portals (or just list works on the main portal) "Historical Works about Augustus" , "Historical Works about Julius Caesar" "Historical Works about Nero" etc. under Roman History (or biography, with "Biographies" instead of "Historical Works"), why does it matter which ones have extant authored works and which ones don't? The reason that the portal structure matters is that is why a redirect is inappropriate. If these are under "Newspapers" --> "News Articles about Foo" why does it matter whether Foo wrote a poem while for "News Articles about Bar" Bar didn't? MarkLSteadman (talk) 05:36, 25 November 2024 (UTC)

  Parenting is required per policy. Per Help:Portals#Necessary_parts "all portals on Wikisource must have: 2. A classification (or call number)." Also relevant: "Portal space is structured into a five layer hierarchy. The top layer contains only the one, main portal, Portal:Portals." Per Help:Portal classification "An adapted version of the Library of Congress Classifiaction system (LCCS) is used to classify all portals on Wikisource." And then if they grew large enough they can be split again.

  These likely should be {{Portal subpage}} instead: "Used for subpages of named items in the Portal: namespace, eg. People," Lets say you are collecting documents about people on Jan 6th: indictments, proceedings, news articles, etc. You might create a main portal "Jan 6 Prosecution" and then create portal subpages for each, linked by name, date, whatever (for previous / next). Or do something similar for "Settlers of Foo." But I wouldn't then go start moving them out into Authors and breaking the subpage structure as it is found that this person was a journalist with articles, that settler wrote a poem etc. MarkLSteadman (talk) 07:23, 28 November 2024 (UTC)

News articles with no titles

We can use descriptive names like New York Tribune editorial on the Dred Scott case or my preferred would be New York Tribune/1857/It is Impossible to Exaggerate to use the first few words of the article. In the 1800s the front page of most papers were hundreds of small articles with no titles. RAN (talk) 18:12, 17 November 2024 (UTC)

I agree with your preference as it matches with the way the more famous editorials are referenced (e.g. "Yes, Virgina, there is a Santa Claus"). The category system will deal with the topic. Beeswaxcandle (talk) 02:41, 24 November 2024 (UTC)

Probably influenced by my poetry work, where it's preferred, but I think that the first words are better too. — Alien  3
3 3 11:13, 24 November 2024 (UTC)

• It will affect all the entries in Category:Dred Scott v. Sandford, should we delete the old names, or keep as redirects? --RAN (talk) 21:14, 24 November 2024 (UTC)

  Change to dated soft redirects. These stay in place for a few months before being deleted. This allows any external links to be amended prior to deletion. Beeswaxcandle (talk) 04:32, 25 November 2024 (UTC)

• We should also discuss other harmonization issues, there was a lot of experimenting with titles at the start, now we have entries like The Times/1882/News/Funeral of Charles Darwin and The Times/1882/Editorial/Burial of Charles Darwin. Do we still want to distinguish "news" from "editorials"? I can see only using this if we have an identically named article and an identically named editorial, but that would be rare. --RAN (talk) 21:58, 24 November 2024 (UTC)

  No, we don't want to separate out "news" from "editorial" like this. If we ended up with an identically named article and editorial, we would disambiguate in a different way. Beeswaxcandle (talk) 04:34, 25 November 2024 (UTC)

• I agree, if we encounter identical titled editorials and news articles, I would add something at the end of the title, not the beginning like there. As I said there was a lot of experimenting at the start of the project. I identified 6 different ways that newspaper articles were transcribed and there were 12 different ways that they were indexed, now down to about 6 types of indexes. --RAN (talk) 00:50, 27 November 2024 (UTC)

Did the site's CSS just change again?

I was just editing Constitution of the Commonwealth of Massachusetts (1780) and the colors of the header template became all faded and pale, similar to what happened several weeks back on index pages. What is going on? —Justin (koavf)❤T☮C☺M☯ 14:21, 22 November 2024 (UTC)

It's probably @CanonNi's editing Template:Header/styles.css about one hour ago. To CanonNi:

• Are you aware that the variables you used do not correspond to the old colors?
• If yes, why did you do it?
• Did you discuss it somewhere?
• Do you mind if I revert? — Alien  3
  3 3 14:47, 22 November 2024 (UTC)

 Comment I reverted it for now, on the grounds that it is the highest-used template on the site and was causing a styling issue. So headers should be back to normal, and will await CanonNi's response here. SnowyCinema (talk) 15:50, 22 November 2024 (UTC)

My apologies. I was tweaking the colors so that they look more natural in dark mode, and the variables are copied from the Chinese Wikisource. Thanks for reverting the edits. '''[[User:CanonNi]]''' (talk • contribs) 07:47, 25 November 2024 (UTC)

@CanonNi: The new changes are not problematic. Still, I'm wondering, is there a specific reason why you are changing the styles? — Alien  3
3 3 18:13, 5 December 2024 (UTC)

Well, I'm using the official-ish dark mode, and the original styles were way too bright when the background is dark, so I made a couple of tweaks per the recommendations. '''[[User:CanonNi]]''' (talk • contribs) 01:58, 6 December 2024 (UTC)

Deployment of Vector 2022

Following the above discussion #Switching to the Vector 2022 skin: the final date where the WMF employees did not seem to pay much attention to our concerns, Yodin was so kind to write a request for postponing the deployment to Wikimedia Foundation Board noticeboard at meta. Feel free to make there any comments too. -- Jan Kameníček (talk) 15:58, 22 November 2024 (UTC)

Erm, it looked strangely empty, so I looked at the history and saw this, with edit summary: (moving section to talk page to respond, as the NoticeBoard is for announcements). I think we should move our post to the talk page too. (@Yodin)

Also noting that, regarding the WMF personnel not answering our concerns, I emailed the two involved, hoping that they will actually answer the questions, as I believe that they are not any more in bad faith than we are, and that they aren't just ignoring us. — Alien  3
3 3 18:49, 22 November 2024 (UTC)

Good point @Alien333, and apologies to everyone if I've rushed in here and gone about this the wrong way! Good idea to nudge the web team, and to assume good faith; I'm a bit reluctant to move the message at this stage though, in case for example any of the trustees have emailed links to the discussion (the WMF staff looking after the page also seem to have left it where it is for now), but will do so if you all think this should be done.

I did also follow up the message by posting to the talk pages of each of the community appointed trustees, and there have been encouraging replies from three so far (Mike Peel, Victoria Doronina, and Rosie Stephenson-Goodknight). Mike Peel mentioned the Conversation with Trustees next Wednesday (27 Nov); not sure I want to attend as I'm already well outside my comfort zone, don't want to tread on any more toes here than I already have, and know that there are many admins and other editors who would be better at representing the community than me! That said, I'd be prepared to if no-one does. He also suggested starting a Phab ticket to track all issues relating to deployment of Vector 2022, which could be a good way to regain a bit of momentum on this? --Yodin^T 01:41, 23 November 2024 (UTC)

TL;DR:

• I was pointed to justification that more paragraph spacing would be more readable
• WMF has not taken into account the technical side
• We can override it with site css
• Are there other issues?

 

I did get an answer as to why they decided to space the paragraphs.

I was directed to [1], which notably contains: Increase the space between blocks of text to create better signposts for scanning

And ultimately points only, besides unjustified opinions, to the WCAG's [2], which regarding this says:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;

[1] also contains: any change to the Wikimedia wikis' typography might have a temporary negative impact on readability for community members and frequent readers, even if it improves readability for the billions of others whom this work is intended to benefit. The good news is that negative transfer effects do not last for long. Effects like this suggest that allowing readers to customize their reading experience could improve readability for more people.

What I find alarming is that they appear to have wholly not taken into account the technical side of it.

 

On the brighter side, we are not wholly powerless if they just force that on us.

I, for one, though this might be an unpopular opinion, do not think that's V22's general layout is problematic, and I now use it, though I had to do some css customisation to revert the technically problematic stuff.

We always have MediaWiki:Gadget-Site.css. Nothing prevents us from adding: (keeping this code up to date)

.mw-body p { margin: 0.5em 0; }
.vector-body { font-size:0.875em; }
#skin-client-prefs-vector-feature-custom-font-size { display: none; }

Are there other actually breaking issues (as opposed to merely less practical)? Can we solve them all with MediaWiki:Gadget-Site.css? — Alien  3
3 3 08:54, 23 November 2024 (UTC)

Unfortunately, I am not very techy, so: do I understand it right that we can locally adjust both spacing following paragraphs and line height to preserve the current state? --Jan Kameníček (talk) 10:16, 23 November 2024 (UTC)

Yes you do, it's only a css rule. We shouldn't have to hack through stuff forced on us, but we can. Actually, .mw-body p { margin: 0.5em 0; } would be much better.

Oh, and for line spacing, V22 didn't change that, as far as I know. — Alien  3
3 3 10:34, 23 November 2024 (UTC)

That doesn't seem to be enough to fix the {{Overfloat image}} problems; not sure how much CSS is causing those problems. A couple of other (non-breaking) issues I've found so far:

• Spacing of the progress bar (green/yellow/red), backlinks for subpages, and placement of the featured text icon and download ebook button at top of mainspace pages
• The previous, next and up arrow links at the top of each Page:

@Alien333 you mentioned "I had to do some css customisation to revert the technically problematic stuff" – how much custom CSS are you having to use at the moment? --Yodin^T 13:43, 23 November 2024 (UTC)

Did you use the first rule I gave (the one with !important) or the other one? The other one does work. Also, need to be careful and test without V22's spacing for {{overfloat image}} stories, as many calls to it are broken even without. Can you point me to a page that works without V22 and without .mw-body p { margin: 0.5em 0; }, but that doesn't work with V22 and with .mw-body p { margin: 0.5em 0; }?

Regarding the quantity of css, not that much, currently only this (related to V22). I also have one other rule because the invert dark mode (which tbh is better than the "feature-level" dark mode) does a weird thing with table backgrounds. — Alien  3
3 3 14:54, 23 November 2024 (UTC)

Yep, using the second one, and seeing issues with pretty much all uses of {{overfloat image}}. I think it's when Text size is set to Standard in the Appearance menu (which is the default for logged out users). When it's set to Small (i.e. the normal font from Vector 2010) it seems to be ok. When it's set to Large, it becomes completely broken. --Yodin^T 15:05, 23 November 2024 (UTC)

Oh, indeed, hadn't thought of that. We'd have to add .vector-body { font-size:0.875em; } too. — Alien  3
3 3 15:12, 23 November 2024 (UTC)

Which I guess would override the Appearance font size options entirely? As you said above, we could introduce hacky fixes like this, but really these are issues the Web Team should be addressing. --Yodin^T 15:23, 23 November 2024 (UTC)

If we're overriding it, might as well hide it (added above). — Alien  3
3 3 16:11, 23 November 2024 (UTC)

I think there's a standard way to disable those options without hiding them (like on the Watchlist for example). Maybe a MediaWiki: namespace editable option? The page layouts also seem to override the Width section of the Appearance menu too (or at least I haven't come across a mainspace page that is affected by changing from Standard to Wide mode)? --Yodin^T 17:15, 23 November 2024 (UTC)

I think that's because they did take some trouble to vaguely try and make it wikisource-compatible. I know that for Page:space it's always wide for that reason, it's probably the same for Main. — Alien  3
3 3 17:17, 23 November 2024 (UTC)

Ah, probably shouldn't be a selectable option in those namespaces then? Seems to work as expected here in the Wikisource namespace, and probably all talk pages. --Yodin^T 17:31, 23 November 2024 (UTC)

For these non-breaking issues, I'm unsure how you would prefer it to be. If you mean some things that were above the title going beneath, I don't think it's that problematic. — Alien  3
3 3 15:05, 23 November 2024 (UTC)

As I said, they don't break any pages, but I think we should list all the visual glitches that the Vector 2022 introduces. For the download button at the top of each mainspace page, it introduces a lot of whitespace above the header; this could be solved by putting it (and any featured text icons, etc.) on the same line as the proofread progress bar, and links from subpages. This is one example, and one I wouldn't be certain of the best practice way to fix, in a way that only applies to Vector 2022, but keeps Vector 2010 as it is. --Yodin^T 15:19, 23 November 2024 (UTC)

"The designer-oriented discourse on web typography available from sites like Smashing Magazine and Medium is not very relevant to the task of improving readability of Wikipedia. Most of the articles assume that designers want to optimize an in-depth editorial reading experience of long-form text articles, rather than the quick, task-oriented, contextualized skimming behaviours Wikipedia's readers are most likely to employ" From the link. That is the heart of it for me: 1. Only mention of Wikipedia and 2. What do they expect people to be doing here. have a quick skim over, say, a novel or actually read it on our site? MarkLSteadman (talk) 13:57, 23 November 2024 (UTC)

• Alien, Jan Kameníček: On my end, it’s been forced through. Could we have this reversed? While we’re at it, can we have SGrabarczuk (WMF) and such ilk banned? They are clearly not here to contribute to the project and have already disrupted it to a make a point, both of which are bannable offenses on Wikipedia (the only place they seem to care about). TE(æ)A,ea. (talk) 00:46, 4 December 2024 (UTC)

  @Jan.Kamenicek Would definitely be good to discuss this to get an overall consensus. @TE(æ)A,ea. in the meantime, you can switch back to Vector 2010 by going to Preferences > Appearance selecting Vector legacy (2010) then Save. --Yodin^T 01:38, 4 December 2024 (UTC)

Are categories moved automatically like at Commons?

See Category:Editorial being migrated to a new category name. RAN (talk) 22:54, 24 November 2024 (UTC)

I'm a notoriously not-smart person, so pardon me if I'm just being a dummy again, but can you elaborate on what you mean? —Justin (koavf)❤T☮C☺M☯ 23:01, 24 November 2024 (UTC)

The contents of Category:Editorial are being moved to Category:Magazine editorials, will a bot do the move, like at Commons? Previously we had Category:Editorial and Category:Editorials as dupe categories. --RAN (talk) 21:36, 25 November 2024 (UTC)

I am pretty sure no, since categories are not as integral or widespread here as at Commons. Moving things from one category to another is pretty trivial with HotCat, which you can add here: Special:Preferences#mw-prefsection-gadgets. —Justin (koavf)❤T☮C☺M☯ 21:41, 25 November 2024 (UTC)

• Catalot at Commons is intuitive, I can't figure out HotCat. --RAN (talk) 00:46, 27 November 2024 (UTC)

Please remove redlink

MediaWiki:Gadget-interwiki-transclusion. Alternately, insert a useful link (maybe to mw:?). Thanks. —Justin (koavf)❤T☮C☺M☯ 19:37, 25 November 2024 (UTC)

After some digging around, there isn't a page anywhere describing it. (We should have one). Closest that comes to that is Template:Iwpage/doc. Note: this probably should've gone to WS:AN, as only admins can solve this. Also, this section is supposed to be for Scan "repairs and moves", so this if it stays at WS:S should be all the way down. — Alien  3
3 3 19:53, 25 November 2024 (UTC)

Moved. Thanks. —Justin (koavf)❤T☮C☺M☯ 20:08, 25 November 2024 (UTC)

Tech News: 2024-48

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

Updates for editors

• A new version of the standard wikitext editor-mode syntax highlighter will be available as a beta feature later this week. This brings many new features and bug fixes, including right-to-left support, template folding, autocompletion, and an improved search panel. You can learn more on the help page.
• The 2010 wikitext editor now supports common keyboard shortcuts such Ctrl+B for bold and Ctrl+I for italics. A full list of all six shortcuts is available. Thanks to SD0001 for this improvement. [3]
• Starting November 28, Flow/Structured Discussions pages will be automatically archived and set to read-only at the following wikis: bswiki, elwiki, euwiki, fawiki, fiwiki, frwikiquote, frwikisource, frwikiversity, frwikivoyage, idwiki, lvwiki, plwiki, ptwiki, urwiki, viwikisource, zhwikisource. This is done as part of StructuredDiscussions deprecation work. If you need any assistance to archive your page in advance, please contact Trizek (WMF).
• View all 25 community-submitted tasks that were resolved last week. For example, a user creating a new AbuseFilter can now only set the filter to "protected" if it includes a protected variable.

Updates for technical contributors

• The CodeEditor, which can be used in JavaScript, CSS, JSON, and Lua pages, now offers live autocompletion. Thanks to SD0001 for this improvement. The feature can be temporarily disabled on a page by pressing Ctrl+, and un-selecting "Live Autocompletion".
• Tool-maintainers who use the Graphite system for tracking metrics, need to migrate to the newer Prometheus system. They can check this dashboard and the list in the Description of the task T350592 to see if their tools are listed, and they should claim metrics and dashboards connected to their tools. They can then disable or migrate all existing metrics by following the instructions in the task. The Graphite service will become read-only in April. [4]
• The New PreProcessor parser performance report has been fixed to give an accurate count for the number of Wikibase entities accessed. It had previously been resetting after 400 entities. [5]

Meetings and events

• A Language community meeting will take place November 29 at 16:00 UTC. There will be presentations on topics like developing language keyboards, the creation of the Mooré Wikipedia, the language support track at Wiki Indaba, and a report from the Wayuunaiki community on their experiences with the Incubator and as a new community over the last 3 years. This meeting will be in English and will also have Spanish interpretation.

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

MediaWiki message delivery 22:42, 25 November 2024 (UTC)

How to handle repeated footnote calls? (two footnote 1's)

How do I handle a source with repeat footnote calls? e.g., on page one uses footnote 1, then on page three uses another footnote 1, then on page four a footnote 2, then it continues consecutively. If I just use <ref> then the numbers will all be one off. Thanks! Apt-ark (talk) 05:02, 27 November 2024 (UTC)

You can use the name attribute. See [6] MarkLSteadman (talk) 16:44, 27 November 2024 (UTC)

Do the two footnote 1s have the same text? — Alien  3
3 3 17:13, 27 November 2024 (UTC)

• What if they are separate? I have a work where it goes 1, 2, 3, 2, 4, 5, where the 2s are different. TE(æ)A,ea. (talk) 16:36, 30 November 2024 (UTC)

This isn't something that is practicable to reproduce exactly. We have other works where the footnotes restart on every page, & others that use symbols or letters. Just use ref markers as normal—which is our "house style." Beeswaxcandle (talk) 17:45, 30 November 2024 (UTC)

Purging/updating Index pages?

How does a user update/refresh/purge the cache of index pages beyond purge, hard purge, and null edit? I ask since I and another user have cleared all cases of a tracked error usage (Obsolete Font tags) on 73 Index pages a few weeks ago, but Wikisource is still reporting these errors as existing in the Special:LintErrors reports. Wondering if it is something we don't understand about how the page is built, or if something isn't working/updating correctly, and needs a phab ticket. Anyone have any insight? Thanks. Zinnober9 (talk) 03:58, 29 November 2024 (UTC)

That list implies that the "issue" (it's not an error) is coming through a template. Have you verified that the template and attendant module and css are not contributing? Beeswaxcandle (talk) 04:34, 29 November 2024 (UTC)

Yes, the Template and CSS are clean. The indication sometimes means it's in the template used, in other cases, it's within the template's usage on the page in question. An example of the latter would be that of en:Wikipedia:User:Gwillhickers/Current (report). It claims the errors are through Template:Navbox, but that is a clean template, and the errors are on the user's page in the template usage (the two fonts in title and list1, and the unclosed bold after Ulysses S. Grant).

For the Index pages here, each Index page claimed one Font tag usage before and after edits like this clearing one Font tag. I feel like that should have cleared it, but it didn't, so started asking questions. Another editor who I've talked with about this issue did two tests at Index:Love Songs.djvu and found that a test blanking of Table of Contents section didn't update the error claim, and in a second test, that it did not create a reported error by the addition of a selfclosing tag error. Edits display the changed text, but doesn't seem to update the metadata reports. Zinnober9 (talk) 06:57, 29 November 2024 (UTC)

"(partial list)" on author pages

If you search for "partial list" in the Author namespace, you will find there are a handful of author pages that say the word "(partial list)" before listing out the works. But there are many issues with this:

• That phrase was usually added to those pages over a decade ago, and it's easy for editors to keep the word "partial list" there despite the fact that the list had probably been significantly updated since then.
• The whole point of a wiki is to collaboratively improve content over time. So, in a sense, any page is always supposed to be assumed under some kind of construction, meaning the list is in a sense inherently partial.
• This is especially true for author pages, since because of lack of easy access to many periodicals and newspapers, and other obscure publications that are sometimes overlooked or not scanned, it's extremely difficult to claim a comprehensive list of all works published by a particular author.

Can we just remove all instances of this?

(There are other similar issues with author pages by the way, for example the claim made on some author pages that they're static lists based on someone's bibliography or another, rather than dynamic lists that can be improved or changed over time.) SnowyCinema (talk) 11:52, 30 November 2024 (UTC)

I think we should remove them, just like we removed {{incomplete list}} in July, for the same reasons. — Alien  3
3 3 12:25, 30 November 2024 (UTC)

I agree. Bibliographies like that are often not perfect and could discourage editors from including any additional works that they missed. Seems like it might be trying to use a Wikipedia style approach of requiring secondary sources, which I don't think is needed on author pages, and wouldn't be possible for most obscure authors. --Yodin^T 20:25, 30 November 2024 (UTC)

Done SnowyCinema (talk) 23:43, 4 December 2024 (UTC)

In WS:CV, should Commons take precedent for scans?

It's a recurring issue in Wikisource:Copyright discussions (and not anyone in particular's fault) that indexes are discussed in copyright terms here first, when the scans themselves are hosted on Commons. And if they're copyrighted in the US, then presumably the scans would have to be deleted at Commons too and not just here, in every case I can think of.

Example: In the case of Max Headroom signal hijacking of WTTW, our CV discussion had to be sent to Commons because the video file itself, if copyrighted, would be a copyright issue across projects and not just at Wikisource.

So, shouldn't we make it the standard at CV that, unless (1) the scans are hosted here (such as if they're PD-US but not PD-UK or something), or (2) the work's text is not scan-backed and hosted here—that we send the discussion to Commons first? How might we do this? SnowyCinema (talk) 21:58, 2 December 2024 (UTC)

• I don’t think that this is a good idea. In my experience, people at Commons do not have a sufficient knowledge of the copyright issues we experience here to be able to answer the questions accurately. Everyone here who can talk about copyright has some knowledge of how historic copyrights (and issues with book publication, &c.) work; but this is not the case on Commons, where photographs and licenses are more pressing issues. Our forum is simply better for eliciting relevant discussion. TE(æ)A,ea. (talk) 01:00, 3 December 2024 (UTC)

Ok, but if a transcription project for a scan gets deleted here, wouldn't they have to have their own deletion discussion for the scan itself and then similarly determine to delete it after another month? What if they determine otherwise? I guess this is an inherent problem with the "global" system either place it goes first, though, so there's really not an easy answer. SnowyCinema (talk) 01:08, 3 December 2024 (UTC)

Always better for us to have the conversation first. The copyright rules at Commons are different from ours and there have been too many times when they have deleted a file that is acceptable to us without letting us import it first. We could add to our process that, if we decide a file is not accepted here either as a CV or a DEL, then Commons gets notified. At that point they can have their own discussion. Beeswaxcandle (talk) 05:04, 3 December 2024 (UTC)

Personally, I support the idea of having copyright discussions about Commons-hosted files on Commons. That's what every other wiki does and I don't see any reason why Wikisource should act differently. I also don't agree that Commons users lack sufficient knowledge of copyright about book publication. There are copyright discussions about books and things scanned from books on Commons all the time. Does anyone have examples of cases where such discussions have gone awry on Commons? Nosferattus (talk) 02:27, 4 December 2024 (UTC)

Just remembered. The other problem we have is that we usually have pages in both the Page: and Index: namespaces linked to commons-hosted work files that become orphaned when the file is deleted on Commons. These are often not discovered for considerable periods of time (sometimes years). We need a notification mechanism to remove them prior to deletion of the file. Beeswaxcandle (talk) 02:38, 4 December 2024 (UTC)

Pretty much every project that has local files has had Commons delete files they would keep locally. And every project that has different copyright rules from Commons has to have its own determinations. German Wikipedia won't use works that are public domain in the US but not public domain in Germany, like Mickey Mouse. We use works that are PD in the US that would be deleted in Commons, and works not PD in the US are often kept on Commons; I stopped fighting that battle long ago.--Prosfilaes (talk) 03:15, 4 December 2024 (UTC)

• Nosferattus: Commons has made objectively wrong decisions on a number of occasions. The problem with this is that no one here is notified, so we only find out sometime after the file has been deleted that there even was a discussion. Once a file is deleted, it’s fairly hard to get it undeleted; usually, the same people who got it deleted (for the wrong reasons) will prevent it from being undeleted (for those same reasons). A bigger issue is when a file is deleted because it would be copyrighted if it were published in Europe, even though it was published in the United States. No one there seems to check the Hirtle chart, and will think you’re lying when you’re talking about licenses like PD-US-1976-89 and whatnot. Another issue is that, because of a lack of knowledge about book copyrights, deletion nominations with only the nominator’s comment (which might not even be a firm “this is copyrighted”) can be closed without any discussion as “delete.” I’ve spent several hours (in the past, on numerous occasions) responding to such deletion requests. Like Beeswaxcandle said, the lack of notification (or effort to notify) makes it hard to track down the files. And like I said earlier, the people best qualified to answer the question of copyright as to a book are the people here at English Wikisource, who almost exclusively deal with historic, book-adjacent copyrights, rather than the people at Wikimedia Commons, who mostly deal with contemporary, photograph-adjacent and license-related copyright issues. As for SnowyCinema’s other comments, I don’t particularly care if Commons has to duplicate work; I avoid Commons as much as possible anyway. As for different interpretations, that has happened to me in the past; the result is that the work is available on Commons, but you get threatened by administrators if you try to transcribe it here. TE(æ)A,ea. (talk) 13:47, 4 December 2024 (UTC)

@TE(æ)A,ea.: It sounds like the problem is mostly due to lack of notification. Why don't we just request that English Wikisource be added to the Commons deletion notification bot? Nosferattus (talk) 18:32, 4 December 2024 (UTC)

See https://phabricator.wikimedia.org/T190233#7597437 for the current process. Looks like we have to have a local RfC first. Nosferattus (talk) 18:36, 4 December 2024 (UTC)

It isn't just notification, that is one area of improvement but it isn't just, say looping admins in here to do the complementary work, or starting the discussion. The issue is that there is so much more uncertainty in our cases. This is both because we need to track down actual facts and history for many of the discussions, was the copyright proper, was it renewed, was the author serving in the US armed forces when they wrote this dissertation, was this an official government translation etc. as well as interpretation in the context of the law, are Biden's and Harris's speeches at the DNC in the public domain as government officials or not as private people campaigning? Which products of international conferences are edicts in the US or have copyrights owned by foreign governments? What exactly happened to a published translation by US government official of a Soviet mathematical paper when the URAA restored foreign copyrights? While ideally it would be great to reach consensus across the communities, we have difficulty enough on our own, have our own precedents, etc. MarkLSteadman (talk) 04:36, 5 December 2024 (UTC)

"The copyright rules at Commons are different from ours" Given that both - all Wikimedia - projects are hosted on the same sets of servers, and operate in the same jurisdiction, this is troubling. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:18, 5 December 2024 (UTC)

• Andy Mabbett: It’s purely a matter of choice, to make copyright more sensible to contributors from different regions. Us here, Wikimedia Commons, and all sister projects must (and do, I hope) abide by U.S. copyright law, because the servers are hosted in the U.S. In addition, some sister projects choose to voluntarily bind themselves to other copyright laws which bind a majority of their contributors. For example, German Wikisource chooses to follow Germany’s copyright law in addition to U.S. copyright law. Similarly, Wikimedia Commons chooses to follow the copyright of the work’s country of origin in addition to U.S. copyright law. English Wikisource and English Wikipedia only follow U.S. copyright law, by contrast. We often run into problems that involve deletions on Wikimedia Commons for works which are copyrighted in foreign countries (even if the book was first published in the U.S.), but which are not copyrighted in the U.S. TE(æ)A,ea. (talk) 12:36, 5 December 2024 (UTC)
  • Yes, I know why and where it happens, It is the very fact that it happens at all which is concerning. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:02, 5 December 2024 (UTC)

I don't know why you are concerned. The cultural buzzsaw has been baked in from the beginning, and there has been absolutely no desire for culture change. Functionaries do not play nice with others, and it has never been a criteria for selection. It works for the functionaries. So it goes. Some egregious mistakes include Iwo Jima flag raising photo, and MacArthur foundation images. I see no reason to defer to commons copyright decisions. --Slowking4 ‽ digitaleffie's ghost 00:57, 11 December 2024 (UTC)

Tech News: 2024-49

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

Updates for editors

• Two new parser functions were added this week. The {{#interwikilink}} function adds an interwiki link and the {{#interlanguagelink}} function adds an interlanguage link. These parser functions are useful on wikis where namespaces conflict with interwiki prefixes. For example, links beginning with MOS: on English Wikipedia conflict with the mos language code prefix of Mooré Wikipedia.
• Starting this week, Wikimedia wikis no longer support connections using old RSA-based HTTPS certificates, specifically rsa-2048. This change is to improve security for all users. Some older, unsupported browser or smartphone devices will be unable to connect; Instead, they will display a connectivity error. See the HTTPS Browser Recommendations page for more-detailed information. All modern operating systems and browsers are always able to reach Wikimedia projects. [7]
• Starting December 16, Flow/Structured Discussions pages will be automatically archived and set to read-only at the following wikis: arwiki, cawiki, frwiki, mediawikiwiki, orwiki, wawiki, wawiktionary, wikidatawiki, zhwiki. This is done as part of StructuredDiscussions deprecation work. If you need any assistance to archive your page in advance, please contact Trizek (WMF). [8]
• This month the Chart extension was deployed to production and is now available on Commons and Testwiki. With the security review complete, pilot wiki deployment is expected to start in the first week of December. You can see a working version on Testwiki and read the November project update for more details.
• View all 23 community-submitted tasks that were resolved last week. For example, a bug with the "Download as PDF" system was fixed. [9]

Updates for technical contributors

• In late February, temporary accounts will be rolled out on at least 10 large wikis. This deployment will have a significant effect on the community-maintained code. This is about Toolforge tools, bots, gadgets, and user scripts that use IP address data or that are available for logged-out users. The Trust and Safety Product team wants to identify this code, monitor it, and assist in updating it ahead of the deployment to minimize disruption to workflows. The team asks technical editors and volunteer developers to help identify such tools by adding them to this list. In addition, review the updated documentation to learn how to adjust the tools. Join the discussions on the project talk page or in the dedicated thread on the Wikimedia Community Discord server (in English) for support and to share feedback.

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

MediaWiki message delivery 22:22, 2 December 2024 (UTC)

Movie scripts and television news transcripts

Do we host public domain movie scripts and television news transcripts? RAN (talk) 20:47, 4 December 2024 (UTC)

@Richard Arthur Norton (1958- ): Yes, we do, see Wikisource:WikiProject Film, and Category:Film for examples. SnowyCinema (talk) 21:46, 4 December 2024 (UTC)

If you're referring to the original paper scripts of old films, those are really hard to find, but theoretically if you were to find one, I don't see why not. They'd be a valuable asset to our knowledge base on those films, surely. SnowyCinema (talk) 21:51, 4 December 2024 (UTC)

Poem formatting

{{ppoem}}, made by Inductiveload in 2021, is, as far as I can see, better than the <poem> extension in all ways. It was not mentioned at Help:Poetry until Peteforsyth and I added it in April. We still tried to be about neutral and to describe all alternatives. I am thinking of making a proposal in the near future to deprecate <poem> in favor of ppoem, and officially state in all relevant places that poetry should be done with ppoem. The only real disadvantage I have seen to the template has been premature wrapping around {{di}}s, but that can be fixed easily and is anyhow not a breaking issue. Is anyone aware of others issues that would prevent officially recommending ppoem? Regards, — Alien  3
3 3 20:06, 7 December 2024 (UTC)

It would be helpful to note / illustrate that it works across pages inside ref tags, as especially the joining together of muti-page references has its own quirks. MarkLSteadman (talk) 20:19, 7 December 2024 (UTC)

Will do (assuming you mean about {{ppoem}}s in <ref follow=s centering with those before, not sure I understood correctly). — Alien  3
3 3 20:30, 7 December 2024 (UTC)

Exactly. I have seen various templates break in that context caused by the slightly different behavior of the Cite extension parsing. MarkLSteadman (talk) 20:43, 7 December 2024 (UTC)

Done — Alien  3
3 3 08:57, 8 December 2024 (UTC)

@Alien333 I am not sure what you have in mind when you say deprecate <poem>, but are you aware that <poem> often appears in strange places, as a simple means of introducing line breaks? One of the more recent examples I could think of is Page:R Theranos Inc CMS 07-07-2016 Letter.pdf/32, noting that remembering where <poem> shows up for non-poetry uses is more the difficulty here (for not giving more examples), rather than the lack of random appearances of <poem>. For the record, I am not against the (sensibly biased) recommendation of ppoem for poetry, but am just trying to clarify what deprecating <poem> would involve. Regards, TeysaKarlov (talk) 20:12, 11 December 2024 (UTC)

It would only involve stating in the relevant WS/Help pages, that the preferred way to do poetry, for new works, is through ppoem. It would not involve replacing older uses of <poem>, and it would not be a ban, just a guideline.

On treating other line-based passages as poems: I've done it myself from time to time, but I don't see how it would be affected by this proposal. After all, {{ppoem}} is able to do that just as well as the poem tag.

(Also, I don't understand what you mean by "sensibly biaised", would you mind clarifying?)

— Alien  3
3 3 20:23, 11 December 2024 (UTC)

@Alien333 Thanks for clarifying, and sorry for any confusion regarding 'sensibly biased', which just meant I agree with you (i.e.~it is sensible that you are biased in favor of ppoem, for poetry). Also, by default, doesn't ppoem automatically center? How would you simply generate a 'poem' with, e.g. left alignment and a 5em left offset like in the above example? Not saying you can't, just saying that I would like to know how you would (maybe also as an example on the ppoem or poetry pages, as every example for ppoem I can see is centered). Thanks, TeysaKarlov (talk) 20:38, 11 December 2024 (UTC)

You can kill two birds with one stone with {{ppoem|style=margin-left:5em|...}}. It works like that because ppoem's centering is through margin:0 auto;. — Alien  3
3 3 20:56, 11 December 2024 (UTC)

@Alien333 Thanks (you make it seem too easy...). At any rate, would happily support your proposal. Regards, TeysaKarlov (talk) 21:18, 11 December 2024 (UTC)

Also, as a side note: if this gets consensus, Help:Poetry and Template:Ppoem/doc should probably be merged/redirected one into the other, as it'll be the same content. — Alien  3
3 3 21:00, 11 December 2024 (UTC)

{{ppoem}} appears to have the same primary issue that <poem> has; namely, that it uses explicit line breaks rather than paragraph breaks between stanzas. I think I'll stick to manual formatting. —Beleg Tâl (talk) 01:51, 14 December 2024 (UTC)

I don't get what you're saying. {{ppoem}} uses \n\n (which I think was what you meant by explicit line breaks, correct me if not), as does ppoem, and as does manual formatting (well, it doesn't have to, but from looking at manual formatting pages you've done you seem to use that too). Also, I didn't understand what you meant by paragraph breaks (I'd have said \n\n, but that's what ppoem and <poem> already use). — Alien  3
3 3 08:46, 14 December 2024 (UTC)

{{ppoem}}, like <poem>, encodes the gap between stanzas as <br>. Specifically, {{ppoem}} renders it as <span class="ws-poem-break"><br></span>. Manual formatting, i.e. using the standard wiki parser, turns two line breaks into a paragraph break, </p><p>, which in my opinion is much preferable. —Beleg Tâl (talk) 01:04, 16 December 2024 (UTC)

I'm not sure that it's an issue. This br (which btw I have just simplified into just a classed br as opposed to a br in a classed span) has position:absolute on it, so it is unrelated to the stanza spacing, which is done through .ws-poem-stanza:not(:last-child) { margin-bottom: 1em; } (and can be customised through index css). The use of this br is only for the content to copypaste correctly.

In a way, it's exactly the same as if it was </p><p>. The only difference is that it is </div><div>(as the br in the middle does nothing). It could be </p><p>, though, if you think semantic-wise it would make more sense (as nothing uses div.ws-poem-stanza). It must be said, though, that p tags have already have a lot of styling attached to them, so it's less practical. — Alien  3
3 3 19:39, 17 December 2024 (UTC)

One thing I don't like about {{ppoem}} as it is is that the HTML markup it produces is a lot more complex. This is due to the many <div> and <span> tags, which apply several CSS classes. By contrast, the HTML markup created by <poem> is a lot simpler. If there's some way to make {{ppoem}} produce simpler HTML, I would love for that to happen. Duckmather (talk) 21:10, 16 December 2024 (UTC)

• The only thing that was not useful, as far as I can see, is wrapping the br in span tags. I have replaced <span class="ws-poem-break"><br/></span> by <br class="ws-poem-break"/>, which is more concise. It is necessary for the linebreaks to have a class for them to not disrupt the layout, which is in fact only done through display:block and margin-bottom:1em (respectively on lines and stanzas). (Ppoem also has brs, by the way.)
• poem also has a parent container, used here to centre it, and adapt some other templates inside it (plus, can and is used to target it in index CSS).
• poem also has stanza containers (p instead of div.ws-poem-stanza). These, along with line containers (the only difference between ppoem and poem output), is I think more of a feature than of an issue, because it allows applying classes to these easily (the predefined classes, {fine}, {sc}, & co, are very useful, and you can also do custom ones), saving much proofreading time (from my experience). See uses of this.

So, in the end, we could remove some of the markup, but we'd also be removing features, and it's not much worse than poem in my opinion. How bad of an issue do you think it is? I hadn't thought of the output markup as a problem (given it's not invalid HTML, and who looks at it?). — Alien  3
3 3 20:34, 18 December 2024 (UTC)

(@SnowyCinema) I did something that should help:

• make the stanzas use p tags and not div tags, because p tags naturally copypaste as a line break, and so there's no need to put a "position:absolute"'d br between stanzas (to be able to actually position:absolute it on all browsers, it had to be wrapped in a span, which is unnecessary markup complexity). @Beleg Tâl: as a side effect, this is now literally </p><p>.
• and so remove entirely that br between stanzas
• change <span class="ws-poem-break"><br></span> at end-of-line to <br/>. This br does not in fact have to be absoluted, and so there is a need neither for the span nor for the class. @Duckmather: I think that this is as far as it can get on the simplification side, without seriously hacking into the features.

I believe that this answers all issues raised. If it doesn't, please say so.

This is for now only in the sandbox, because as this is linked to cross-browser stuff, I'd appreciate if you could take a look at {{ppoem/testcases}} and confirm that the sandbox version a) has the same visual output and b) copypastes the same, before putting it live. It works on Firefox, Chrome, Opera and Edge, on mobile, and when exporting. Tests still needed for Safari.

Assuming it works and everyone's satisfied, I'll make the proposal sometime next week. — Alien  3
3 3 15:21, 21 December 2024 (UTC)

Size of editing window in proofread extension

When editing in the proofread extension, the editing window and the window with the scan are very small in the new skin. The space can be gained by hiding the toolbars on the left and right, but this works only until I click the preview button, after which both the windows get small again and cannot be enlarged anymore. Is there anything to prevent this behaviour? -- Jan Kameníček (talk) 20:34, 7 December 2024 (UTC)

I'm not having this issue with the preview button. Maybe need to change some settings? — Alien  3
3 3 08:18, 8 December 2024 (UTC)

No idea which settings could be changed. After clicking the "show preview" the toolbars stay hidden, but the editing space gets narrow again, creating empty margins for the to toolbars on both sides. BTW, I can see the empty margins on both sides also in the reading mode in the WS namespace, but that is not such a problem, as in the editing mode in the Page NS, where the scan gets so small that I have problems reading it. --Jan Kameníček (talk) 12:20, 8 December 2024 (UTC)

You don't happen to have Preferences > Appearance > Skin preferences > "Enable limited width mode" on, do you? — Alien  3
3 3 12:31, 8 December 2024 (UTC)

I can confirm this issue; it does seem to be solved by switching "Enable limited width mode" off. Unfortunately, it looks like the default for IP editors to have this option enabled at the moment, so they would have the same problem if using preview when proofreading. The description for the option on the settings page ("Enable limited width mode for improved reading experience.") is also very unhelpful, giving no indication of exactly what it does. Would probably be good to have this switched off for IP editors by default, and the description changed to something that would make sure editors are aware of what this option does, and don't switch it on without knowing the effect it would have on proofreading previews. --Yodin^T 12:45, 8 December 2024 (UTC)

One thing it is good for is that the change in the window width adjusts the lines and missed <cr> can be easily seen. I think I am going to leave it.--RaboKarbakian (talk) 14:23, 8 December 2024 (UTC)

Tech News: 2024-50

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

Weekly highlight

• Technical documentation contributors can find updated resources, and new ways to connect with each other and the Wikimedia Technical Documentation Team, at the Documentation hub on MediaWiki.org. This page links to: resources for writing and improving documentation, a new #wikimedia-techdocs IRC channel on libera.chat, a listing of past and upcoming documentation events, and ways to request a documentation consultation or review. If you have any feedback or ideas for improvements to the documentation ecosystem, please contact the Technical Documentation Team.

Updates for editors

Layout change for the Edit Check feature

• Later this week, Edit Check will be relocated to a sidebar on desktop. Edit check is the feature for new editors to help them follow policies and guidelines. This layout change creates space to present people with new Checks that appear while they are typing. The initial results show newcomers encountering Edit Check are 2.2 times more likely to publish a new content edit that includes a reference and is not reverted.
• The Chart extension, which enables editors to create data visualizations, was successfully made available on MediaWiki.org and three pilot wikis (Italian, Swedish, and Hebrew Wikipedias). You can see a working examples on Testwiki and read the November project update for more details.
• Translators in wikis where the mobile experience of Content Translation is available, can now discover articles in Wikiproject campaigns of their interest from the "All collection" category in the articles suggestion feature. Wikiproject Campaign organizers can use this feature, to help translators to discover articles of interest, by adding the <page-collection> </page-collection> tag to their campaign article list page on Meta-wiki. This will make those articles discoverable in the Content Translation tool. For more detailed information on how to use the tool and tag, please refer to the step-by-step guide. [10]
• The Nuke feature, which enables administrators to mass delete pages, now has a multiselect filter for namespace selection. This enables users to select multiple specific namespaces, instead of only one or all, when fetching pages for deletion.
• The Nuke feature also now provides links to the userpage of the user whose pages were deleted, and to the pages which were not selected for deletion, after page deletions are queued. This enables easier follow-up admin-actions. Thanks to Chlod and the Moderator Tools team for both of these improvements. [11]
• The Editing Team is working on making it easier to populate citations from archive.org using the Citoid tool, the auto-filled citation generator. They are asking communities to add two parameters preemptively, archiveUrl and archiveDate, within the TemplateData for each citation template using Citoid. You can see an example of a change in a template, and a list of all relevant templates. [12]
• One new wiki has been created: a Wikivoyage in Indonesian (voy:id:) [13]
• Last week, all wikis had problems serving pages to logged-in users and some logged-out users for 30–45 minutes. This was caused by a database problem, and investigation is ongoing. [14]
• View all 19 community-submitted tasks that were resolved last week. For example, a bug in the Add Link feature has been fixed. Previously, the list of sections which are excluded from Add Link was partially ignored in certain cases. [15][16]

Updates for technical contributors

• Codex, the design system for Wikimedia, now has an early-stage implementation in PHP. It is available for general use in MediaWiki extensions and Toolforge apps through Composer, with use in MediaWiki core coming soon. More information is available in the documentation. Thanks to Doğu for the inspiration and many contributions to the library. [17]
• Wikimedia REST API users, such as bot operators and tool maintainers, may be affected by ongoing upgrades. On December 4, the MediaWiki Interfaces team began rerouting page/revision metadata and rendered HTML content endpoints on testwiki from RESTbase to comparable MediaWiki REST API endpoints. The team encourages active users of these endpoints to verify their tool's behavior on testwiki and raise any concerns on the related Phabricator ticket before the end of the year, as they intend to roll out the same change across all Wikimedia projects in early January. These changes are part of the work to replace the outdated RESTBase system.
• The 2024 Developer Satisfaction Survey is seeking the opinions of the Wikimedia developer community. Please take the survey if you have any role in developing software for the Wikimedia ecosystem. The survey is open until 3 January 2025, and has an associated privacy statement.
• There is no new MediaWiki version this week. [18]

Meetings and events

• The next meeting in the series of Wikimedia Foundation discussions with the Wikimedia Commons community will take place on December 12 at 8:00 UTC and at 16:00 UTC. The topic of this call is new media and new contributors. Contributors from all wikis are welcome to attend.

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

MediaWiki message delivery 22:16, 9 December 2024 (UTC)

hyphens across pages in transclusion

I just had an interesting conversation with TeysaKarlov in which I learned that a simple hyphen at the end of a page will disappear in transclusion. An example of this (provided by TeysaKarlov) is Page:Peter Pan in Kensington Gardens (1912, Hodder & Stoughton).djvu/188 where it transcludes to Peter Pan In Kensington Gardens/Lock-out Time#66

Is this wonderful thing a real thing? When did it happen? Can I rely on it?--RaboKarbakian (talk) 14:03, 10 December 2024 (UTC)

• RaboKarbakian: This change happened recently. It works for only the most basic cases; if there is anything between the first and second halves of the word, then it doesn’t work. So, if there is an image in between the text, or if there is a cross-page hyphenated word in a footnote reference, then you still need to use the old system. Other then that, though, in cases like the one you gave, it will always work, regardless of index style settings. TE(æ)A,ea. (talk) 16:56, 10 December 2024 (UTC)

  @RaboKarbakian: You may have a look to H:HYPHEN. There is also a side effect when the page is divided in sections (## xx ##). Implicitely the page ends with </section name="xx"> and not with the hyphen. // M-le-mot-dit (talk) 18:00, 10 December 2024 (UTC)

yeah, and much correction of guttenberg texts that kludge this issue. --Slowking4 ‽ digitaleffie's ghost 00:45, 11 December 2024 (UTC)

Is there some reason why {{hws}} and {{hwe}} weren't used here (until I added them just now)? —Justin (koavf)❤T☮C☺M☯ 00:51, 11 December 2024 (UTC)

{{hws}} and {{hwe}}, as it says on their pages, are now nearly useless. To quote the doc: There are only a few cases where this template is still the best option. These include if Labelled Section Transclusion stops automatic hyphen joining from working, if an image page appears before a hyphenated word is ended, and for footnotes (emphasis original). — Alien  3
3 3 06:24, 11 December 2024 (UTC)

The creation of {{peh}} took over "I want to keep the hyphen function" and the automatic hyphen swallowing dealt with word joining function. So, there is little left for hws/hwe to do. However, they do need to be kept to cope with the odd quirk. Beeswaxcandle (talk) 07:29, 11 December 2024 (UTC)

"Recently" being four months after my first edit here, and before I learned to lurk here and around. Heh. All that PITA since then.--RaboKarbakian (talk) 11:50, 11 December 2024 (UTC)

References leading to nowhere?

Hello, so I am trying to proofread Page:Ancient India as described by Megasthenês and Arrian.djvu/52, but there are small reference numbers for which I can't find a corresponding reference. How do I deal with this? It also happened on this page. Should I ignore it? —Matr1x-101$_{when-replying}^{Ping-me}$ {_{user page} ^{(@ commons)} - _talk} 18:43, 14 December 2024 (UTC)

Those are sentence numbers within the fragment rather than references. Beeswaxcandle (talk) 18:52, 14 December 2024 (UTC)

Ohhh (I feel so stupid now... thanks for clarifying lol) —Matr1x-101$_{when-replying}^{Ping-me}$ {_{user page} ^{(@ commons)} - _talk} 22:10, 14 December 2024 (UTC)

@Beeswaxcandle: Since these also function as references, I did something here. Thoughts? —Matr1x-101$_{when-replying}^{Ping-me}$ {_{user page} ^{(@ commons)} - _talk} 22:32, 14 December 2024 (UTC)

Actually, nevermind, Template:Ref seems to work better. —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 18:39, 15 December 2024 (UTC)

Tech News: 2024-51

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

Weekly highlight

• Interested in improving event management on your home wiki? The CampaignEvents extension offers organizers features like event registration management, event/wikiproject promotion, finding potential participants, and more - all directly on-wiki. If you are an organizer or think your community would benefit from this extension, start a discussion to enable it on your wiki today. To learn more about how to enable this extension on your wiki, visit the deployment status page.

Updates for editors

• Users of the iOS Wikipedia App in Italy and Mexico on the Italian, Spanish, and English Wikipedias, can see a personalized Year in Review with insights based on their reading and editing history.
• Users of the Android Wikipedia App in Sub-Saharan Africa and South Asia can see the new Rabbit Holes feature. This feature shows a suggested search term in the Search bar based on the current article being viewed, and a suggested reading list generated from the user’s last two visited articles.
• The global reminder bot is now active and running on nearly 800 wikis. This service reminds most users holding temporary rights when they are about to expire, so that they can renew should they want to. See the technical details page for more information.
• The next issue of Tech News will be sent out on 13 January 2025 because of the end of year holidays. Thank you to all of the translators, and people who submitted content or feedback, this year.
• View all 27 community-submitted tasks that were resolved last week. For example, a bug was fixed in the Android Wikipedia App which had caused translatable SVG images to show the wrong language when they were tapped.

Updates for technical contributors

• There is no new MediaWiki version next week. The next deployments will start on 14 January. [19]

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

MediaWiki message delivery 22:24, 16 December 2024 (UTC)

Translation matters

A couple of matters:

Wikisource:Translations

This page has at the top "This page is a proposed Wikisource policy, guideline, or process. The proposal may still be in development, under discussion, or in the process of gathering consensus for adoption. References or links to this page should not describe it as a "policy" or "guideline"." Is that still the case ? It seems to me that I have seen elements of this described as if policy> Or is the policy placed somewhere else ?

User translations in Mainspace

There are some translation in Mainspace with comments along the lines "This translation ... was made for Wikimedia projects by " with a link to the user page. Should such translation be moved to the Translation space ? See An einen Boten, Das Todaustreiben, Es kam ein Herr zum Schlößli, Rätsel, Wenn ich ein Vöglein wär, Wiegenlied (Des Knaben Wunderhorn).

Is there a policy as to whether the name should be the original (in these cases German) or the English translation ? -- —unsigned comment by Beardo (talk) .