Testwiki:Scriptorium/Archives/2024-12

Tech News: 2024-49

<section begin="technews-2024-W49"/>

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.

<section end="technews-2024-W49"/>

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)

Template:Ping 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

<section begin="technews-2024-W50"/>

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 ⧼project-localized-name-group-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:|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.

<section end="technews-2024-W50"/>

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)

Template:Ping 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)

Template:Talk quote inline 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 (Template:Nowrap). 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 Template:Tl and Template:Tl weren't used here (until I added them just now)? —Justin (koavf)❤T☮C☺M☯ 00:51, 11 December 2024 (UTC)

Template:Tl and Template:Tl, as it says on their pages, are now nearly useless. To quote the doc: Template:Tqi (emphasis original). — Alien  3
3 3 06:24, 11 December 2024 (UTC)

The creation of Template:Tl 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$\underset{Ping-me}{\overset{}{when-replying}}$ {_{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$\underset{Ping-me}{\overset{}{when-replying}}$ {_{user page} ^{(@ commons)} - _talk} 22:10, 14 December 2024 (UTC)

Template:Ping Since these also function as references, I did something here. Thoughts? —Matr1x-101$\underset{Ping-me}{\overset{}{when-replying}}$ {_{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

<section begin="technews-2024-W51"/>

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. [13]

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

<section end="technews-2024-W51"/>

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

problem uploading Djvus to commons

Hello fellow transcribers, I've had trouble uploading my two last djvus using the IA upload tool. The files seem to have been uploaded but they're not being rendered. I've have had a look at others fjvu uploads and see the same problem. For example File:Divine Healing.djvu Does anybody know anything about this? Jpez (talk) 09:47, 25 December 2024 (UTC)

It was a cache issue. It often helps with various issues to clear either the mediawiki cache (see the "purge clock" gadget), or your browser's cache (ctrl-F5 most of the time). Template:Sm — Alien  3
3 3 10:50, 25 December 2024 (UTC)

Thank you Alien  3
3 3! Jpez (talk) 23:21, 25 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 ? -- Template:Unsigned

In practice it has already been treated as a policy for a long time. However, we may start a formal vote to accept it as a policy de iure. --Jan Kameníček (talk) 13:44, 24 December 2024 (UTC)

Thanks. I don't know about the procedures, but I don't think that we should be treating as policy something which specififically states that it is not "policy" or "guideline". -- Beardo (talk) 17:26, 24 December 2024 (UTC)

Voting started at #Wikisource:Translations proposed for becoming a guideline. --Jan Kameníček (talk) 17:27, 26 December 2024 (UTC)

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 ? -- Template:Unsigned

Unfortunately, the current practice is to accept Wikisource translations only of works whose originals were proofread and scanbacked at the appropriate language wiki, which does not seem to be the case of the works mentioned above. --Jan Kameníček (talk) 13:46, 24 December 2024 (UTC)

Main page

The main page was vandalised with the message "You guys forgot to protect the main page..." - I reverted that. But should the main page be made for autoconfirmed users only ? -- Beardo (talk) 13:37, 30 December 2024 (UTC)

Someone deleted it ([14]) and forgot to restore the protection. I've reported it at AN. —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 13:50, 30 December 2024 (UTC)

Template:Ping make sure it's cascading protection —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 14:03, 30 December 2024 (UTC)

I did that Actually, no, it shouldn't be cascading (and it wasn't before), because Template:Tl, that is transcluded on it, should be editable by autoconfirmed editors (and sorry for the whole mess). — Alien  3
3 3 14:12, 30 December 2024 (UTC)

Cache problems when creating new indexes

After we have received two independent requests for help here and here I created Template:Phabricator in Phabricator. -- Jan Kameníček (talk) 15:19, 30 December 2024 (UTC)

This 0x0 problem (which is the same as the "Invalid Interval" one) has been noted in the past, though it's been a symptom of different things. T299521 is related to our issue (the one we have since March). Note: adding "or djvu" to the description: the problem is for some reason more persistent with pdf files, but also happens to djvu. — Alien  3
3 3 15:46, 30 December 2024 (UTC)

Poem formatting

Template:Tl, 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 Template:Tls, 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 Template:Tls 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)

Template: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, Template:Tl 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)

It shouldn't be the same content. Help:Poetry covers more than just the use of ppoem in its multifarious modes. Beeswaxcandle (talk) 01:53, 31 December 2024 (UTC)

Template:Tl 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. Template:Tl 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)

Template:Tl, like <poem>, encodes the gap between stanzas as <br>. Specifically, Template:Tl 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 Template:Tl 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 Template:Tl 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 Template:Tl and confirm that the sandbox version a) has the same visual output and b) copypastes the same, before putting it live. It Template:Done 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)

Tested on Safari, also works. Going to put in live module. — Alien  3
3 3 16:38, 30 December 2024 (UTC)

Update: it's a long story, but in the end that didn't work. Ppoem is going to stay pretty much as it was. — Alien  3
3 3 09:51, 3 January 2025 (UTC)

Wikisource:Translations proposed for becoming a guideline

Wikisource:Translations, originating in 2013, has always been taken into serious account here and treated as if it were an official policy. A short time ago it was noted that it has not undergone any official vote, and so I am proposing it now to become an official guideline. --Jan Kameníček (talk) 16:42, 26 December 2024 (UTC)

Voting

• Template:Support --Jan Kameníček (talk) 16:42, 26 December 2024 (UTC)
• Oppose. The restrictions on original translations are too heavy, I think, for this proposal to be legitimated. TE(æ)A,ea. (talk) 22:27, 26 December 2024 (UTC)
• Tentative Template:Support I'd like to see the clarification mentioned below to the guideline, but in general I'm in favor of the proposal. Update to full support. —Tcr25 (talk) 22:54, 27 December 2024 (UTC)
• Template:Support — Alien  3
  3 3 09:27, 28 December 2024 (UTC)
• Template:Oppose because the policy on original translations says that works "incomplete and abandoned for long periods" can be deleted. I think that this is against the spirit of Wikisource, which, like Wikipedia, is always a work in progress. There is always the possibility that a long abandoned project can later be picked up by another user; we wouldn't delete an English language transcription simply for being incomplete, so I don't think that we should delete a translation for being so either. prospectprospekt (talk) 15:40, 28 December 2024 (UTC) striking my vote per Xover prospectprospekt (talk) 21:05, 2 January 2025 (UTC)
• Template:Support making this a policy. In fact it is one of the strongest policies we have, because it was the subject of extensive community discussion through the RFC mechanism. What it lacks is a mostly pro forma !vote to label it as policy.Template:PbrHowever, I support the existing policy page being promoted; not the moving target being hashed out in the discussions below. First promote the existing policy then make separate proposals for the changes being discussed. For example, The Knickerbocker Gallery/Ad Fontium Nymphas is not a translation covered by the translation policy. Changing the policy text for this case makes little sense to me (at present; I am absolutely persuadable on the point). I have similar issues with the other proposed change. --Xover (talk) 10:56, 30 December 2024 (UTC)

  I might be missing something, but I brought up The Knickerbocker Gallery/Ad Fontium Nymphas as an example of an original language text that's not on Latin Wikisource, but for which a translation has been made (Translation:The Knickerbocker Gallery/Ad Fontium Nymphas). A strict reading of the policy would require the poem to be on Latin Wikisource before a translation could be hosted on English Wikisource. —Tcr25 (talk) 01:51, 2 January 2025 (UTC)

  I personally understand this concern, and support adding it to the guideline. Although it makes sense that we should probably first accept de iure the text which has de facto already been used as a policy for many years – among others, it is linked from the Template:Template template, from Wikisource:Annotations policy, and has been used as a basis in numerous RfD discussions – this particular change is not really big, and so if it gets support in the discussion below, it can imo be added straight-away. Otherwise, a separate vote can be triggered subsequently. --Jan Kameníček (talk) 13:33, 2 January 2025 (UTC)

  Yes. The point of the restriction is (in part) to make sure contributors do not just create a translation on enWS, but in fact proofread the work on its original language Wikisource too. Having a loose poem translation from an English language original does not aid this goal. This is why I do not want to make changes simultaneously with the !vote: what's being suggested is actually a substantive change to the policy. It's possible Translation:The Knickerbocker Gallery/Ad Fontium Nymphas is a sufficiently relevant edge case to merit adjusting the policy to accommodate it, but I'd want that as a proper separate discussion where we also look at specific wording and consequences. Xover (talk) 08:42, 3 January 2025 (UTC)

• Template:Support--Jusjih (talk) 00:59, 2 January 2025 (UTC)
• Template:Support. Though I have a couple of minor quibbles, the page has had all serious issues ironed out, and is being regarded as guiding policy at this point. To my mind, the vote simply formalizes the community position. --EncycloPetey (talk) 21:25, 2 January 2025 (UTC)
• Template:Oppose — The restrictions on original translations are too stringent. The requirement that a scan-supported original work exist on some Wikisource would rule out many of our existing translations, and the requirement to have one translation per original work doesn't take into account that, as explained earlier in the proposal, different translations will satisfy different needs. Dmoews (talk) 05:33, 5 January 2025 (UTC)

  Yes, it would, and have you actually looked at (most of) those existing translations? The quality is in general extremely poor, and they cannot be improved reliably because there is no original scan to work from. In practice these are user-generated pseudo-editions that we are allowing users to self-publish on Wikisource. We do not allow users to host their own "improved" version of War and Peace (or reconstructed Cardenio or…) in English, so why in the world would we allow those things just because they are translations? Xover (talk) 08:24, 5 January 2025 (UTC)

  I've looked at the four translations from German (1, 2, 3, 4) linked from Arnold Sommerfeld, which were done by D.H. I think they have some value, although they don't comply with the proposed bureaucratic policy. Still, if you want to check how good or bad they are, it's easy enough, since there are external original-language scans which are linked (#2, 3, 4) or easy to find (#1. In this case there is an original-language transcript on the multilingual Wikisource with a link to an external original-language scan.) The proposed policy would not make it much easier. Dmoews (talk) 17:36, 7 January 2025 (UTC)

Discussion

The restrictions on original translations are more than necessary, and in fact they have already been applied for a long time. The main reason is that patrolling original translations would be too difficult without this rule, because the patroller would have to to check 1) the original used for translation and 2) the translation itself. If the translation is based on a scanbacked original in the appropriate language wikisource, we can focus only on patrolling the translation itself. This is still a very difficult task, given the low number of people who do the patrolling here (and especially the low number of people who patrol translations), so refusing this rule would be a huge step back. Of course the situation would be different if there were crowds of patrolling volunteers, but there are not. --Jan Kameníček (talk) 19:20, 27 December 2024 (UTC)

The bit I have a question about is "A scan supported original language work must be present on the appropriate language wiki, where the original language version is complete at least as far as the English translation. An inter-wiki link to the original language work must be present on the English translation." There are instances where, for example, an untranslated work is included in a work that is otherwise all in English (for example, "Ad Fontium Nymphas" in The Knickerbocker Gallery). In a case like that, so long as the Latin text is scanbacked and linked to with the rest of the English document, it shouldn't require adding a version to the Latin Wikisource to back an original translation. —Tcr25 (talk) 19:36, 27 December 2024 (UTC)

That is reasonable. In fact no rule can cover all possibilities that may arise in reality, and so various specific cases are usually dealt with individually. In doubts there is always a possibility to start a specific-case discussion where any rule can be overruled by the community. --Jan Kameníček (talk) 21:03, 27 December 2024 (UTC)

Just to head off possible issues, I'd suggest adding something like "If a non-English work is included in a scan-supported work otherwise eligible for inclusion on English Wikisource, a link to that work will suffice." to the guideline. —Tcr25 (talk) 22:53, 27 December 2024 (UTC)

I agree with this, and if there is no opposition, it can be included. --Jan Kameníček (talk) 23:17, 27 December 2024 (UTC)

Template:Re And what about "If a non-English work is included in a scan-supported work present on English Wikisource, a link to that work will suffice"? --Jan Kameníček (talk) 23:35, 27 December 2024 (UTC)

That sounds good to me. —Tcr25 (talk) 01:33, 28 December 2024 (UTC)

Incomplete and abandoned

Wikipedia and Wikisource are projects in neverending progress as a whole, but they differ as for their elementar parts. While WP articles are always a work in progress, this is not true about individual works in WS, which, once proofread and validated, are finished and only minor improvements like correcting overlooked typos can take place there afterwards. The problem with WS translations is that we (unlike Wikipedia) can rarely expect that somebody will continue an abandoned work. There are zillions of books worth translation, and from time to time a dedicated contributor picks one of them to translate, but if they stop working without finishing it, the translations simply stay unfinished. Unfinished translation is much more difficult to continue than unfinished profreading of some index, and so they tend to pile up. Even without this rule being accepted, the current practice has been deleting translations which have been abandoned for many years without anybody noticing them. If this point were a real obstacle for the rule to be accepted, it could be changed of course, but it would be better if it stayed there. --Jan Kameníček (talk) 17:15, 28 December 2024 (UTC)

BTW, the rule says it "can be deleted". The fact that a work appears to be abandoned does not mean it gets deleted automatically. It is always nominated at WS:Proposed deletions, where the community has a chance to decide about it being kept, if it is worth keeping. --Jan Kameníček (talk) 17:23, 28 December 2024 (UTC)

Maybe there's not much point writing "... can be nominated for deletion", though. After all, any page can at any time be nominated for deletion. Why not remove that? — Alien  3
3 3 16:27, 29 December 2024 (UTC)

That is OK with me. --Jan Kameníček (talk) 00:29, 30 December 2024 (UTC)

The phrasing was used because of strident grandfathering of translations with no specific source text to translate, such as claims that works could not be deleted because they've been here for a long time. The phrasing was meant to say that a deletion discussion was a viable option, and deletion could not be objected to simply because of a translation's age or length. --EncycloPetey (talk) 21:32, 2 January 2025 (UTC)

Broken file title: "Star Film Catalogue 1905/1908"

Hello from a novice! I'm trying to proofread Georges Méliès's Complete Catalogue of Genuine and Original "Star" Films, but the filename of the scan is causing technical problems.

Years ago I uploaded the scan to Commons as "Star Film Catalogue 1908", which is an accurate name: this is the 1908 edition of the catalogue, listing films released from 1897 through 1908. However, just a few days ago some well-meaning editors renamed the file "Star Film Catalogue 1905," since the copyright page misleadingly says 1905. (Presumably Méliès saw no need to pay to register the updated edition for copyright, so he just carried over the copyright page from the 1905 edition.)

This rename has broken a lot of links on the Wikisource project; the backward/forward arrows for each page of the transcription no longer appear, and the up arrow has become a redlink. I've asked on Commons for the rename to be undone, but should I also take any action here to fix the broken links? If so, what? Many thanks for any advice. Lemuellio (talk) 15:08, 29 December 2024 (UTC)

Apart from renaming the file, no, nothing to do as far as I know. — Alien  3
3 3 15:16, 29 December 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)

Index:Wireless Telegraphy and Telephony (1908, Massey and Underhill).djvu

The file name has the authors name spelled wrong, by me, at IAUpload. It was annoying enough that there was a request to change the name. It will need to be moved at commons also, so I require a filemover there to complete this task here.

Index:Wireless Telegraphy and Telephony (1908, Massey and Underhill).djvu to Index:Wireless Telegraphy and Telephony (1908, Massie and Underhill).djvu Thank you.--RaboKarbakian (talk) 02:52, 31 December 2024 (UTC)

All Template:Done on the wikisource side. Waiting for the commons rename request. — Alien  3
3 3 08:12, 31 December 2024 (UTC)

Thank you!--RaboKarbakian (talk) 15:52, 31 December 2024 (UTC)

Alien The transclusion (first page, chapters, and index) needs to have a name change.

<pages index="old.djvu" to index="new.djvu" />

I fixed the File:djvu and Category: at commons and wikidata; at least I hope I did. Russbot there moves files out of frequented categories that don't exist. I put that category on the bots list temporarily to see if the files get automatically moved. To be sure, I am not using the template correctly there and will remove it after the move. Usually, I try to avoid the Russbot. Nothing against Russbot, I just try to look before I drop something there.--RaboKarbakian (talk) 17:02, 31 December 2024 (UTC)

I did change the <pages> tags to match the name change this morning, just have to purge out the cache. — Alien  3
3 3 17:15, 31 December 2024 (UTC)