Wikisource:Scriptorium/Archives/2024-12

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. [1]
• 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). [2]
• 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. [3]

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)

Wikisource:Administrators#Nominations for adminship

Just as a reminder to the community, there is a live nomination now open, and due to close tomorrow, so speak now or forever hold your peace. Cheers! BD2412 T 17:55, 25 December 2024 (UTC)

This section was archived on a request by: Ciridae (talk) 11:32, 31 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. [4]
• 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. [5]
• 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. [6]
• One new wiki has been created: a Wikivoyage in Indonesian (voy:id:) [7]
• 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. [8]
• 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. [9][10]

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. [11]
• 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. [12]

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)

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)

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)