Wikisource:Scriptorium/Archives/2023-01

Index:The works of John Locke - 1823 - vol 02.djvu → Index:The Works of John Locke - 1823 - vol 02.djvu

To match the naming of the other volumes and so the volumes template can find it. MarkLSteadman (talk) 15:06, 1 January 2023 (UTC)

Done. Mpaa (talk) 16:54, 1 January 2023 (UTC)

1927 Works are accessible on HathiTrust

As a FYI, even though it says that the works are Limited (search only), works from 1927 will load if you click on them on HT. 10:37, 1 January 2023 (UTC) Languageseeker (talk) 10:37, 1 January 2023 (UTC)

Floating image template

It seems that the {{Img float}} template does not work as expected: when the align is set for "center", but the capalign for "left", the whole box gets centered to the left, see here. I had a look at the template's code but did not find what causes the problem. -- Jan Kameníček (talk) 19:04, 2 January 2023 (UTC)

There are two image templates FI which div based, and FIS is span based and floats. — ineuw (talk) 11:13, 4 January 2023 (UTC)

@Ineuw:Unfortunately, the {{FI}} works differently and not as intended in the example. It cuts the text after the word where it was placed, and the text then continues after the image, making it look like a new paragraph. But the {{Img float}} template does not cut it and lets the text flow dynamically without being interrupted. Compare the text with FI template and the same text with Img float template. Reading the documentation of the {{Img float}} template, it should be possible to align the image and the caption independently, but it does not work. --Jan Kameníček (talk) 17:31, 7 January 2023 (UTC)

Please take a look at notes 5 and 6. — ineuw (talk) 19:57, 7 January 2023 (UTC)

Hm, none of them looks really satisfactorily. Note 5 breaks the text that should be continuous into separate paragraphs, and Note 6 not only breaks the text, but even part of a sentence is misplaced next to the caption of the image :-( --Jan Kameníček (talk) 22:47, 7 January 2023 (UTC)

@Jan.Kamenicek: Didn't pay attention earlier, but the template insertion point was wrong. It would help if I could see the original. Please take a look at note 5. — ineuw (talk) 02:56, 8 January 2023 (UTC)

There is no original yet, I was just been experimenting with the template and noticed that it does not work in some cases, and I thought it could be a matter of some minor fix in the code of the template. I am sorry if I take too much of your time for something for which I do not have a real example, but I use the template often and so it is probably just a matter of time until such a case appears.

As for the note 5, the text that should be continuous is currently broken into two paragraphs in the middle of a sentence. The image is not floating at all. What I was aiming at is something like this, i. e. the picture placed and floating in the middle of the paragraph, with the lines above and below continuing dynamically, only the picture would be centered and its caption left-aligned. Meanwhile I have found Template:FreedImg/span#Example 5: Floating centred image which is almost exactly what I wanted to achieve, but the image size has to be given in % of the screen width, which is also far from ideal. What seems getting near the ideal to me is {{Img float}}, which enables the desired outcome if both the picture and its caption are centered, or if both are left-aligned, but for some reason it cannot left-align the caption for a centered image. --Jan Kameníček (talk) 11:45, 8 January 2023 (UTC)

Tech News: 2023-02

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

Recent changes

• You can use tags to filter edits in the recent changes feed or on your watchlist. You can now use tags to filter out edits you don't want to see. Previously you could only use tags to focus on the edits with those tags. [1]
• Special:WhatLinksHere shows all pages that link to a specific page. There is now a prototype for how to sort those pages alphabetically. You can see the discussion in the Phabricator ticket.
• You can now use the thanks function on your watchlist and the user contribution page. [2]
• A wiki page can be moved to give it a new name. You can now get a dropdown menu with common reasons when you move a page. This is so you don't have to write the explanation every time. [3]
• Matrix is a chat tool. You can now use matrix: to create Matrix links on wiki pages. [4]
• You can filter out translations when you look at the recent changes on multilingual wikis. This didn't hide translation pages. You can now also hide subpages which are translation pages. [5]

Changes later this week

• Realtime preview for wikitext is a tool which lets editors preview the page when they edit wikitext. It will be enabled for all users of the 2010 wikitext editor. You will find it in the editor toolbar.
• Some wikis will be in read-only for a few minutes because of a switch of their main database. It will be performed on 10 January at 07:00 UTC (targeted wikis) and on 12 January at 07:00 UTC (targeted wikis).
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 10 January. It will be on non-Wikipedia wikis and some Wikipedias from 11 January. It will be on all wikis from 12 January (calendar).

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

MediaWiki message delivery 01:07, 10 January 2023 (UTC)

Latest ProofreadPage changes and CSS.

It seems that my page namespace CSS width settings of User:Ineuw/vector.css, also affect editing in other namespaces. If I set the edit mode to side by side in the page namespace, edits elsewhere appear side by side, including the Scriptorium. What is the intent, and where do I go to read on the changes that affect our edit environment. — ineuw (talk) 20:13, 10 January 2023 (UTC)

vector.css gets applied globally across all pages (in the vector skin), it is not specifically restricted to the Page: namespace. If you want to select for page namespace editboxes try a selector like .prp-page-content > #wpTextbox1 if you are selecting (say) the textbox containing the page body in the Page: namespace. Sohom Datta (talk) 14:09, 11 January 2023 (UTC)

There hasn't been any new changes in this area as far as I know, so to answer your other question, I'd say keeping track of ProofreadPage tasks/Tech News would be the way to keep track of new developments/behaviorial changes. Sohom Datta (talk) 14:11, 11 January 2023 (UTC)

Disambiguation with authors and works

The mainspace disambiguation header says "it lists works that share the same title" (emphasis mine). This leads to an awkward situation on the page Jane Austen, where the two possible targets are a work and an author. Is it possible to customise the header in exceptional situations like this? If not, can the capability be reasonably added?

I found a 2022 discussion in the Scriptorium archives that mentions the issue, but it's in the context of changing policy and moving pages. What I'm suggesting is changing the wording to better describe pages as they are now. -- Perey (talk) 07:13, 16 January 2023 (UTC)

@Perey: Not exactly sure what you are asking though I am going to guess that you are wanting a means to visually identify that a target page is a disambiguation page. You can do that with a little css code in your special:mypage/common.css. The following text is what I use to turn those pages vivid orange.

/**
 * Display links to disambiguation pages in orange
 * @revision 1.0 (2015-05-27)
 * @author Kaldari
 */
a.mw-disambig { color: #f17600; }

If you want this to work on every wiki for you, then you can put that code into your m:special:mypage/global.css. — billinghurst sDrewth 09:36, 16 January 2023 (UTC)

@Billinghurst: No, I'm after the ability to edit a disambiguation page to change the message that's shown—for everyone, not just for me. Right now, Template:Disambiguation produces a header with different text depending on whether it's used in mainspace or the Author namespace. (Specifically, the magic appears to happen in Template:Disambiguation/info.)

• Main: "This is a disambiguation page. It lists works that share the same title."
• Author: "This is a disambiguation page. It lists authors that share the same name."

In this situation, I would like it to instead read something like, "This is a disambiguation page. It lists works and authors that share the same name." The exact phrasing isn't so important; what I'm aiming for is the ability to change the message as appropriate when a dab page includes cross-namespace links. -- Perey (talk) 12:06, 16 January 2023 (UTC)

@Perey: I hadn't overly fussed it as I thought that it was reasonably overt what it was trying to do and say. However, I created a parameter shared that does that and I have added it to Jane Austen. Feel free to suggest better wording. — billinghurst sDrewth 12:41, 16 January 2023 (UTC)

And I have yet to document it. I would like a level of review and agreement through the community prior to this sticking => Category:Merged disambiguation pages — billinghurst sDrewth 12:46, 16 January 2023 (UTC)

If we're sure about the concept side, this implementation seems reasonable.

But I'm a bit more iffy on the concept side. Do we really need to put authors there? The typical cases are "Jane Austen" and "William Shakespeare", and those will all have exactly one relevant author. Wouldn't that be better as a hatnote ala. For the author, see Author:Jane Austen (i.e. so the author isn't listed as a dab'ed item, and thus we don't need to change the wording or have an extra param)?

But I haven't really thought through this, nor have the experience to tell what works and what doesn't, so I'm not sure I really have an opinion on it (and certainly not a firm one). It's just that now we're listing two kinds of concepts on a single dab where otherwise we only list one (either works or authors, not both), which makes my inner information modeller itch. Xover (talk) 14:31, 16 January 2023 (UTC)

I think it could work:

This page lists works that share the title Sue Me. For the author named Sue Mee, see…

But then, what do we do with cases like Jane Austen, where there's only one work? If the mainspace page exists only to disambiguate works, not people, it doesn't need to exist, because we only have one work by that name! Do we get rid of the dab page, make it a redirect to Jane Austen (Sarah Fanny Malden 1889), and put the hatnote there?

(I said "cases like"… are there any other cases like this? It seems pretty rare for a biography to be simply titled with the subject's name. What about works named for characters who happen to share names with authors? Are we likely to publish anything by David Copperfield or Tom Jones?)

Also, I'm not sure about "exactly one relevant author". Author:William Shakespeare has four. Maybe it's lucky that we don't have any works titled William Shakespeare! -- Perey (talk) 15:53, 16 January 2023 (UTC)

Tech News: 2023-03

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

Problems

• The URLs in "prev" links on page history now contain diff=prev&oldid=[revision ID] in place of diff=[revision ID]&oldid=[revision ID]. This is to fix a problem with links pointing to incorrect diffs when history was filtered by a tag. Some user scripts may break as a result of this change. [6]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 17 January. It will be on non-Wikipedia wikis and some Wikipedias from 18 January. It will be on all wikis from 19 January (calendar).
• Some changes to the appearance of talk pages have only been available on Talk: and User talk: namespaces. These will be extended to other talk namespaces, such as Wikisource talk:. They will continue to be unavailable in non-talk namespaces, including Wikisource: pages (e.g., at the Village Pump). You can change your preferences (beta feature). [7]
• On Wikisources, when an image is zoomed or panned in the Page: namespace, the same zoom and pan settings will be remembered for all Page: namespace pages that are linked to a particular Index: namespace page. [8]
• The Vector 2022 skin will become the default for the English Wikipedia desktop users. The change will take place on January 18 at 15:00 UTC. Learn more.

Future changes

• The 2023 edition of the Community Wishlist Survey, which invites contributors to make technical proposals and vote for tools and improvements, starts next week on 23 January 2023 at 18:00 UTC. You can start drafting your proposals in the CWS sandbox.

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

MediaWiki message delivery 01:10, 17 January 2023 (UTC)

The Hardy Boys

Alright, it's happened everyone. We've got 3 works to do:

• The Tower Treasure
• The House on the Cliff
• The Secret of the Old Mill

Let's do it. Anybody know how to get original 1927 scans this early in 2023? Archive.org has a bunch that are locked because they're later versions, Google Books also doesn't seem to have any scans of the 1927 originals, and Hathi seems to not have caught up with the fact that it's 2023 yet. I'm pretty angsty about this one. PseudoSkull (talk) 08:06, 1 January 2023 (UTC)

@PseudoSkullI think it's best to think of PD-day as a process rather than an automatic switch. Although, all these works came into the PD domain at the stroke of midnight, it'll take a few days for the servers and librarians to catch up. I'm certainly waiting for a number of these for the MC. Hang in there! 10:27, 1 January 2023 (UTC)

We also need to remember that year rolled over on a weekend. If the servers need manual intervention, I would expect things to happen on Tuesday the 3rd. Imzadi 1979 → 16:35, 1 January 2023 (UTC)

@PseudoSkull Does this help? Index:The Secret of the Old Mill.pdf Languageseeker (talk) 17:19, 1 January 2023 (UTC)

@Languageseeker: Thank you so much for finding those. But I can't seem to find the original The Tower Treasure anywhere online, even HathiTrust or Google Books. It's really weird. PseudoSkull (talk) 18:37, 1 January 2023 (UTC)

The House on the Cliff.--Prosfilaes (talk) 19:38, 1 January 2023 (UTC)

And The Tower Treasure Beeswaxcandle (talk) 08:20, 11 January 2023 (UTC)

And Index:The Tower Treasure (1927).pdf was uploaded by TE(æ)A,ea. Languageseeker (talk) 01:30, 18 January 2023 (UTC)

Help:Table of contents

Hi, I am quite surprised we don't have such a page. This is really necessary with some examples covering different types of works. Thanks, Yann (talk) 11:48, 15 January 2023 (UTC)

BTW Template:TOCstyle is a labyrinthine system, and a PhD in rocket science is needed to understand it. Yann (talk) 12:13, 15 January 2023 (UTC)

@Yann: Please do not use that ugly cur Template:TOCstyle. I'd love to burn it. With the css available per work, it should just be a case of simple tables to create the TOC, then apply code to the css to do the formatting. We have so moved on since 2010 when we had none of the modern tools. That we still have some people overpowering works with dot leaders still flummoxes me. — billinghurst sDrewth 09:55, 16 January 2023 (UTC)

Is there some examples of well made ToC? Thanks, Yann (talk) 11:03, 16 January 2023 (UTC)

@Yann: I don't know that I can claim that they are particularly well made, but here are a couple of mine: Index:Shakespearean Tragedy (1912).djvu, The Master of Mysteries, Index:The Tremendous Event (1922).djvu. In essence, just use plain MW table markup with {{ts}} formatting as needed. The only thing that doesn't get you is dot-leaders, and in my experience it's just the learning curve that is steeper than the templates, not actual use once you've got it down. I also very much agree with Billinghurst on the TOC templates, and the dot-leader variants in particular. {{TOCstyle}} is especially over-engineered. Xover (talk) 11:35, 16 January 2023 (UTC)

yeah, welcome to wikisource. TOC are an intermediate task, requiring knowledge of wikicode, and tables. and old template bloat solutions hang around (we should put a big warning template on it). there are lots of completed works to copy the TOC from. it’s no harder than choosing the right license on commons. --((( S ))) ‽ digitaleffie's ghost 14:26, 18 January 2023 (UTC)

I have done quite many ToC on Wikisource, mostly in French. I thought there would be some easy way to do here too… Yann (talk) 19:04, 18 January 2023 (UTC)

There is an easy way to do TOC. Just use ordinary tables. My most recent example is the straightforward one starting on Page:Ruth Fielding at Lighthouse Point.djvu/9. A slightly more complex one starts on Page:Transactions NZ Institute Vol 22.djvu/11. IMNSHO, these are well made and, when transcluded, scale nicely. On my to-do list is to go back through some of my early TOC and convert them away from the ugliness of dot-leaders. Beeswaxcandle (talk) 04:19, 19 January 2023 (UTC)

lol, calling tables "easy" might well baffle a new editor; expecting wikiprojects to be easy, without a steep learning curve is hopelessly naive. French wikisource is better here, because they have down selected preferred solutions, English hangs on to the old failed templates past their due date. --((( S ))) ‽ digitaleffie's ghost 17:37, 19 January 2023 (UTC)

Michael Strogoff

Hi, This work needs to be moved to a new page, and a disambiguation to be made for other editions, i.e. Index:Works of Jules Verne - Parke - Vol 8.djvu and the 1927 edition illustrated by N. C. Wyeth. Thanks, Yann (talk) 15:42, 19 January 2023 (UTC)

@Yann: Done Xover (talk) 16:02, 19 January 2023 (UTC)

@Yann: Incidentally, according tpo the textinfo template on the talk page, the text now on Michael Strogoff (1876) is the edition published in Index:Works of Jules Verne - Parke - Vol 8.djvu (just transcribed by Gutenberg). If that's accurate it should be M&S-able. It also means the date is wrong and we need to move it to Michael Strogoff (1911), but since it was published within the greater volume it should in fact end up at Works of Jules Verne/Volume 8/Michael Strogoff (and Michael Strogoff (1911) should redirect there). But since I haven't verified that the textinfo is actually correct I just moved it to the immediate disambiguated title. Xover (talk) 16:11, 19 January 2023 (UTC)

OK, thanks, Yann (talk) 16:12, 19 January 2023 (UTC)

Author pages with complete names

Hi, I wonder why w:Charles Baudelaire page is at Author:Charles Pierre Baudelaire. Nowhere his middle name is used in the Wikimedia universe. Idem for Author:Agatha Mary Clarissa Christie. Can I rename these pages? Yann (talk) 16:42, 19 January 2023 (UTC)

Wikisource:Naming_conventions#Author_namespace —Justin (koavf)❤T☮C☺M☯ 18:22, 19 January 2023 (UTC)

Well, it doesn't make sense to me. Yann (talk) 19:12, 19 January 2023 (UTC)

Sorry, that was curt: the reason why those have a long name is because that's the rule. I think the reason that's a rule is because that is common in libraries and I think that is common in libraries to make it clear that one person and another person with the same name are two different persons. Does that make sense? —Justin (koavf)❤T☮C☺M☯ 19:29, 19 January 2023 (UTC)

In some cases, yes. But not for the 2 authors I mentioned above, and many others. And for Author:Charles Lindbergh, his father has the same middle name, so it is best NOT to use his complete name. Yann (talk) 20:56, 19 January 2023 (UTC)

Hi Yann. What is the problem with the naming convention? What problems is this causing for you? In short we arrived at the naming convention for many numbers of reasons in helping to manage problems we were seeing and needing to resolve. We have a strategy in place, and your thinking to tactically circumvent it for your one case will cause issues. Of course their is no perfection, however, this has caused least problems.

We have redirects in place from the shorter versions, and you can use whichever variation you wish in the main namespace. We cannot write our rules for one or two authors with very unique names, that sort of approach just leads to every person arguing that every author that they have is a special case, and we simply got sick of that argument years ago. It was also problematic back then as we were getting too many duplicate author pages as we didn't have the diligence to expand names, so we had many variations of author pages for shorter forms or for various pen names. Then add to that the value we have found in managing disambiguation pages is a whole lot easier by undertaking this early expansion, and not having to fix up other peoples external links to us, essentially managing link rot.

I will also note that many of the biographical works that we reproduce that for the same periods for the authors we have pages do have fully expanded names, so that sort of alignment has its benefits. I will also note that what does it matter what the WMF universe is doing? We have them linked that way within WD and the best thing to do is link them to the item there, and pull our link. — billinghurst sDrewth 21:37, 19 January 2023 (UTC)

I believe the principle of least surprise is important. I don’t see the benefit, but if there is a consensus… then OK. Yann (talk) 22:06, 19 January 2023 (UTC)

Least surprise? Nah, that is the lesser of the problems. Have you seen the issues with disambiguation and moves at enWP, then the mess that has occurred when we have had to move pages and the link rot? That is a worse surprise. Do you see the issue for us when an author who has multiple pen names? How about the variations for women's pen names, their maiden and married names, including the Mrs. (husband's name)? We have done those dances, and we ended up here. Yes, there are some prominent authors who end up with expanded names and that surprises some. Yes there are people who edit at enWP who want to come here and see enWP conventions. They all survive. We update their edits, and we don't berate. It isn't a problem, it is just another bit maintenance to our style.

Also as our notability perspective differs, we will often have grandfather / father / son authors so who will you give precedence? We instead make the disambig the base, and full expand. We have had all these discussions, so once you set the conventions, do we have to have arguments about who are those exceptions due to a quirk or a preference?

So we differ from the WPs, we do NOT use the (disambiguation) suffix, and we don't have to have the argument on who is dominant to hold the position; we expand names where possible to disambiguate, otherwise we start to use (yyyy-yyyy). Accordingly, we have pretty much eliminated the issues with duplicate author pages. We have managed to suitably identify numbers of obscure authors and document them, There are a ton of other issues that we have had to address around Snr / Jr, Elder / ... all which are problematic for us, and we had to develop a style that is different, and it was purposeful as we needed more structure than the WPs.

Again I will ask, apart from surprise, what problems are you actually having with our design. [Anyone who wants to convert that to an essay and explain why we differ, then go for it.] — billinghurst sDrewth 23:11, 19 January 2023 (UTC)

i’m shocked that new editors are surprised; and that functionaries from elsewhere expect that norms from elsewhere might apply here. it’s all a cultural goulash, and "i’m confused, so let’s change policy". --((( S ))) ‽ digitaleffie's ghost 20:02, 20 January 2023 (UTC)

I failed to understand this incivility. Those who ask deserve polite answers. --Jan Kameníček (talk) 23:11, 20 January 2023 (UTC)

Poll regarding January 2023 Wikisource Community meeting

Hello fellow Wikisource enthusiasts!

We will be organizing the January 2023 Wikisource Community meeting in the last week of January and we need your help to decide on a time and date that works best for the most number of people. Kindly share your availabilities at the wudele link below:

https://wudele.toolforge.org/5tauCFqk8NJQBcBv

Meanwhile, feel free to check out the page on Meta-wiki and suggest topics for the agenda.

Regards

KLawal-WMF and PMenon-WMF

Sent via MediaWiki message delivery (talk) 03:48, 20 January 2023 (UTC)

Metropolis (1927 film) not on its Wikipedia page

Is there some reason why Metropolis isn't on its Wikipedia page, even though Sunrise and The Jazz Singer are, other than the Wikimedia Commons upload rule? I think we could upload it to Wikisource and then to Wikipedia if need be. SurprisedMewtwoFace (talk) 16:04, 2 January 2023 (UTC)

you could also upload to english wikipedia as "PD-US". it is not a text, so maybe out of scope here. --((( S ))) ‽ digitaleffie's ghost 01:43, 3 January 2023 (UTC)

Find a copy with original subtitles from 1927, and you can upload it after removing the music. The original German subtitles exist, so that's possible. Given what a mess the movie is in, the reconstructions would have a better than normal chance of being copyrightable.--Prosfilaes (talk) 03:07, 3 January 2023 (UTC)

@Slowking4: Not out of scope, we have tons of film transcriptions, see Category:Film. @SurprisedMewtwoFace: The film Metropolis in any form would not be able to be uploaded to Wikimedia Commons until sometime like 2036 IIRC because it is still under copyright in Germany, the source country. The film could be hosted here on the English Wikisource, but as has been said, it is relatively unlikely that we will find a freely licensed English translation of this German film. A Wikisource translation of the German version of the film in the Translation namespace could theoretically be made, but note that films have never been translated at Wikisource in practice. PseudoSkull (talk) 06:20, 3 January 2023 (UTC)

@SurprisedMewtwoFace: Metropolis (film) has been transcribed. PseudoSkull (talk) 18:16, 21 January 2023 (UTC)

Excellent! SurprisedMewtwoFace (talk) 14:28, 22 January 2023 (UTC)

Newspaper changing names

I'm wanting to upload some scans of New Zealand's earliest newspapers and transcribe these. However the newspaper changed names a couple times in its early years. From "The New Zealand Gazette", to "The New Zealand Gazette and Britannia Spectator", to "The New Zealand Gazette and Wellington Spectator".

Should I pick just the latest name? The earliest name? Treat them as different newspapers (for page structure purposes)? ElDubs (talk) 20:13, 17 January 2023 (UTC)

do them as separate titles with a note in the header to indicate the change(s) on a time basis. Beeswaxcandle (talk) 22:06, 17 January 2023 (UTC)

Thanks for that! ElDubs (talk) 22:21, 17 January 2023 (UTC)

You are very welcome and Opinion of the Court delivered by Lady Paton in the Appeals under Sections 103 and 108 of the Extradition Act 2003 by Zain Taj Dean against (first) the Lord Advocate; and (second) the Scottish Ministers has a note with <onlyinclude> to automatically transclude the links in and to relevant pages.--Jusjih (talk) 05:46, 22 January 2023 (UTC)

Civil Disobedience, 1946

Hi, I finished proofreading this version. I am not sure what the title should be, and how to add it to new texts. Thanks, Yann (talk) 22:51, 21 January 2023 (UTC)

Moved to Civil Disobedience (1946), which is a more common way of disambiguating works, and added to New Texts. Thanks for this contribution! --Jan Kameníček (talk) 14:52, 22 January 2023 (UTC)

@Jan.Kamenicek: We should be more likely to call this "Civil Disobedience (Thoreau, 1946)" as the author name still has precedence and relevance. Adding a year alone is somewhat misleading. Wikisource talk:Naming conventions gives some examples. — billinghurst sDrewth 05:12, 23 January 2023 (UTC)

Ah, I did not know about that old discussion, thanks. I will add my point of view to a separate section below. --Jan Kameníček (talk) 13:10, 23 January 2023 (UTC)

Multi-volume work-

Courtesy notification of a discussion elsewhere: Index talk:New Edition of the Babylonian Talmud (Rodkinson) Volume 6.pdf ShakespeareFan00 (talk) 09:27, 23 January 2023 (UTC)

Portal:The_English_Reports

Hi.

I built this a few days ago... It would be nice if some other contributors could help fill in the missing volumes :) ShakespeareFan00 (talk) 23:30, 23 January 2023 (UTC)

Tech News: 2023-04

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

Problems

• Last week, for ~15 minutes, all wikis were unreachable for logged-in users and non-cached pages. This was caused by a timing issue. [9]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 24 January. It will be on non-Wikipedia wikis and some Wikipedias from 25 January. It will be on all wikis from 26 January (calendar).
• If you have the Beta Feature for DiscussionTools enabled, the appearance of talk pages will add more information about discussion activity. [10][11]
• The 2023 edition of the Community Wishlist Survey (CWS), which invites contributors to make technical proposals and vote for tools and improvements, starts on Monday 23 January 2023 at 18:00 UTC.

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

MediaWiki message delivery 23:46, 23 January 2023 (UTC)

Disambiguating editions by the same author

Unfortunately, we do not have clear naming policy, only a very old discussion of a couple of users from 2010, which did not result in any change to the very vague Wikisource:Naming conventions. Most of the points raised in that discussion make sense, with one exception. If we disambiguate more works by different authors, the authors' names are quite logically chosen for disambiguation. If it is not enough, we add year of publication. However, if we have only different editions of one work by the same author, I do not see any point in disambiguating the editions by both the author and the year. The year is just enough. Only if we have works with the same title by different authors, and at least one of them has also different editions, then it seems necessary to disambiguate them by both author and year. Otherwise I do not see the point in making the page name more complicated than needed. -- Jan Kameníček (talk) 13:34, 23 January 2023 (UTC)

Thanks for bringing this up, and I agree.

So far as I can see, the only places it makes sense to use the author name to disambiguate is in disambiguation pages, and these should never need a year. For any other type of page the best and most commonly used elsewhere disambiguator is the year of publication. That should deal with 99% of cases. When there are the rare exceptions (collisions), the better additional disambiguator is publisher or place of publication (to distinguish separate UK and US editions published in the same year). Xover (talk) 15:46, 23 January 2023 (UTC)

I don't see how the year of publication is the most common disambiguator. Usually, the format I see is Huckleberry Finn, by Mark Twain. I don't recall ever seeing the year used as a disambiguator without the author; in fact, a common academic format uses just the author and year (Stevens99) without the title to index into a bibliography.--Prosfilaes (talk) 03:53, 24 January 2023 (UTC)

Invitation to join Wikisource Community meeting (28 January 2023)

Hello fellow Wikisource enthusiasts!

We are the hosting the first Wikisource Community meeting of the year on 28th January 2023 at 12 PM UTC / 5:30 PM IST (check your local time) according to the wudele poll.

The first half of the meeting will be focused on non-technical updates and conversations like events, conferences, proofread-a-thons and collaborations. The second half will be focused on technical updates and conversations, such as talking about major challenges faced by Wikisource communities, similar to the ones conducted in previous Triage meetings.

If you are interested in joining the meeting, kindly leave a message on sgill@wikimedia.org and we will add you to the calendar invite.

Meanwhile, feel free to check out the page on Meta-wiki and suggest any other topics for the agenda.

Regards

KLawal-WMF, PMenon-WMF, Sam Wilson (WMF), and Satdeep Gill (WMF)

Sent using MediaWiki message delivery (talk) 13:03, 25 January 2023 (UTC)

Request to localize images from Index:Now We Are Six (1955).pdf

The images from Now We Are Six are not in the PD globally, but are in the PD in the US. Since they've been uploaded to Commons, the images have been flagged for deletion. Can they be localized? Languageseeker (talk) 15:44, 26 January 2023 (UTC)

Why is Category:Novelettes being merged into Category:Novellas?

I see a number of messages on my watchlist like "Moving from Category:Fantasy novelettes to Category:Fantasy novellas using Cat-a-lot". Shouldn't this have been discussed first? This doesn't answer my key problem, that it's not clear what is what. I'd rather have the distinction that a novelette is 7,500 words to 17,500 words, and a novella is 17,500 to 40,000 words, as per the Hugo/Nebula division w:Novella#Novelette, but if we do merge them, I think we should document that a novella is between 7500 to 40,000 words.--Prosfilaes (talk) 22:31, 27 January 2023 (UTC)

Adjustment to Template:PD-US system to accommodate film transcriptions

With normal (textual) works, we always go on the death date of the usually one (or sometimes more) writers of that work, and we insert the death year of that person into the PD-US template. That system is fairly straightforward. But with films, the copyright logic abroad gets a little weirder than that. It's not written in very many places on Wikimedia Commons or Wikipedia, but most jurisdictions (the EU is the one I'm going off of right now), several categories of filmmakers are considered authors, and all those people have to be taken into account when trying to figure out when a film will fall out of copyright outside the US:

• The principal director
• The screenwriter, and/or other writers of dialogue
• The composer (if the film is accompanied by sound)
• By extension, the authors of any works that may serve as the basis for a film's plot

Also, at Wikisource, we've traditionally listed only the directors of a film as the authors in the Header templates and Index pages, which is not quite an accurate representation of how things are, as was recently reminded to me in an edit by Hekerui on The Jazz Singer. And we've only been reflecting the directors' death dates in the copyright templates up to this point. So in the example of The Jazz Singer, to change the death year to 1983 in the copyright template (death date of Samson Raphaelson) serves to confuse readers, because there is no indication on the transcription page that Raphaelson needs to be considered an author by copyright standards. (Personally, I think the header templates and disambiguation pages should list the production or distribution company as authors, but that's a different matter that I'll fix another time.)

So, as someone who doesn't know Lua or the structure of these copyright templates, I'd like to request the following:

• If the work is a film, I should be able to fill in a parameter to specify that it is a film. For example, if I use:

  {{PD-US|1983|film=yes}}
  

• This would produce a copyright template with the text at Wikisource:WikiProject Film/Film copyright template, or:

Copyright template text if film

This work is in the public domain in the United States because it was published before January 1, 1928.

---

Copyright law abroad tends to consider the following people authors of a film:

• The principal director
• The screenwriter, and/or other writers of dialogue
• The composer (if the film is accompanied by sound)
• By extension, the authors of any works that may serve as the basis for a film's plot

The longest-living of these authors died in 1983, so this work is in the public domain in countries and areas where the copyright term is the author's life plus 39 years or less. This work may be in the public domain in countries and areas with longer native copyright terms that apply the rule of the shorter term to foreign works.

@CalendulaAsteraceae: Or anyone else who could help. PseudoSkull (talk) 19:22, 11 January 2023 (UTC)

Good idea! Hekerui (talk) 19:32, 11 January 2023 (UTC)

@PseudoSkull, thanks for pinging me! I've added a film option to the shorter_term_text function in Module:PD and implemented it in the relevant license modules:

• Module:PD-US
• Module:PD-old-US
• Module:PD-US-notice
• Module:PD-US-no-renewal
• Module:PD-US-no-renewal-unvested
• Module:PD-Canada
• Module:PD-India-CWMG
• Module:PD-1996

Would you be up for adding the film parameter to the documentation of these templates?

{{PD-US|1983|film=yes}}

—CalendulaAsteraceae (talk • contribs) 20:27, 13 January 2023 (UTC)

 Support and per w:List of countries' copyright lengths this template will be much more useful for Hong Kong and the United Kingdom, etc, copyrighting films for the longest lifetime of main authors plus some decades. Yet some countries just copyright films for many years since publication, regardless of the lifetime of main authors.--Jusjih (talk) 23:17, 29 January 2023 (UTC)

Wikisource:Works/2022

Hi, I added December, but November is still incomplete. Is anyone filling this up regularly? And January 2023 is still empty. Yann (talk) 22:48, 29 January 2023 (UTC)

We were doing it manually and curating, then it converted to another process, and within data files, so I backed away last year. @Inductiveload: — billinghurst sDrewth 02:00, 30 January 2023 (UTC)

Color vs Black and white diagrams in a law

I'm looking at submitting a UK law which includes some diagrams of signs. The drawings in the law are in black and white, but the actual signs were in color, and specified in the law below the diagrams. Should the diagrams be uploaded in black and white because they were black and white in the original document, or can I use images that are colored according the what was specified in the law?--The Navigators (talk) 01:50, 30 January 2023 (UTC)

@The Navigators: It is what is in the original work, rather than what is in the scan from which we are working? When all we have is the scan, then that has to suffice, however, if we know the facts of the publication of the work <=> scan, the the published work wins every time. Always a good idea to put notes on the respective Index_talk: page to explain what know and what you are doing; as that level of communication is also invaluable. — billinghurst sDrewth 01:59, 30 January 2023 (UTC)

The diagrams were black and white in the original work. I'll make a second set of images that are black and white for the work here. Thanks for the help.--The Navigators (talk) 05:19, 30 January 2023 (UTC)

Tech News: 2023-05

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

Problems

• Last week, for ~15 minutes, some users were unable to log in or edit pages. This was caused by a problem with session storage. [12]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 31 January. It will be on non-Wikipedia wikis and some Wikipedias from 1 February. It will be on all wikis from 2 February (calendar).

Future changes

• Wikis that use localized numbering schemes for references need to add new CSS. This will help to show citation numbers the same way in all reading and editing modes. If your wiki would prefer to do it yourselves, please see the details and example CSS to copy from, and also add your wiki to the list. Otherwise, the developers will directly help out starting the week of February 5.

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

MediaWiki message delivery 00:05, 31 January 2023 (UTC)

Template:Cite Q

Some of our pages use {{Citation}}. w:Template:Cite Q is a wrapper that populates {{citation}} with metadata drawn from Wikidata. The template's documentation on en.Wikipedia has more detail.

I propose that we import Cite Q from en.Wikipedia, so that it can be used on this project. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:53, 7 January 2023 (UTC)

There have been no objections; can an admin or file-importer do this, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:41, 2 February 2023 (UTC)

Andy Mabbett: You can do it. Just select -> copy -> paste. They should have a shared template versioning system, but they don't. {{Cite Q}} <--Just click! Then let us know here when it is in place because I will use it.--RaboKarbakian (talk) 20:27, 2 February 2023 (UTC)

That's not the right way to do template imports. Special:Import exists for the purpose, and will not only bring in subtemplates, modules and documentation, but preserve the editing history and thus attribution. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:40, 2 February 2023 (UTC)

Done @Pigsonthewing: please double check functionality and the imported documentation for required updates. — billinghurst sDrewth 10:33, 3 February 2023 (UTC)

oh, and the categorisation. Also note that we have template:wikidata link — billinghurst sDrewth 10:34, 3 February 2023 (UTC)

Subpages of Page:US Code Section 1.pdf

• Page:US Code Section 1.pdf/4 → Page:US Code Section 1.pdf/6
• Page:US Code Section 1.pdf/5 → Page:US Code Section 1.pdf/7
• Page:US Code Section 1.pdf/6 → Page:US Code Section 1.pdf/8
• Page:US Code Section 1.pdf/7 → Page:US Code Section 1.pdf/10
• Page:US Code Section 1.pdf/8 → Page:US Code Section 1.pdf/11
• Page:US Code Section 1.pdf/9 → Page:US Code Section 1.pdf/12
• Page:US Code Section 1.pdf/10 → Page:US Code Section 1.pdf/13
• Page:US Code Section 1.pdf/11 → Page:US Code Section 1.pdf/14
• Page:US Code Section 1.pdf/12 → Page:US Code Section 1.pdf/15
• Page:US Code Section 1.pdf/13 → Page:US Code Section 1.pdf/16
• Page:US Code Section 1.pdf/14 → Page:US Code Section 1.pdf/17
• Page:US Code Section 1.pdf/15 → Page:US Code Section 1.pdf/18
• Page:US Code Section 1.pdf/16 → Page:US Code Section 1.pdf/19
• Page:US Code Section 1.pdf/17 → Page:US Code Section 1.pdf/20
• Page:US Code Section 1.pdf/18 → Page:US Code Section 1.pdf/22
• Page:US Code Section 1.pdf/19 → Page:US Code Section 1.pdf/23
• Page:US Code Section 1.pdf/20 → Page:US Code Section 1.pdf/24
• Page:US Code Section 1.pdf/21 → Page:US Code Section 1.pdf/25
• Page:US Code Section 1.pdf/22 → Page:US Code Section 1.pdf/26
• Page:US Code Section 1.pdf/23 → Page:US Code Section 1.pdf/27
• Page:US Code Section 1.pdf/24 → Page:US Code Section 1.pdf/28
• Page:US Code Section 1.pdf/25 → Page:US Code Section 1.pdf/29
• Page:US Code Section 1.pdf/26 → Page:US Code Section 1.pdf/30
• Page:US Code Section 1.pdf/27 → Page:US Code Section 1.pdf/31
• Page:US Code Section 1.pdf/28 → Page:US Code Section 1.pdf/32

The purpose of these moves is to preserve the original edit history while the updated version is transcribed into the pages. X5163x (talk) 06:15, 28 January 2023 (UTC)

Does anyone have any faster way to move them without conflicts? If not, I will manually move them starting from Page:US Code Section 1.pdf/28 → Page:US Code Section 1.pdf/32.--Jusjih (talk) 19:26, 5 February 2023 (UTC)

Done all of these moves from Page:US Code Section 1.pdf/28 → Page:US Code Section 1.pdf/32 to Page:US Code Section 1.pdf/4 → Page:US Code Section 1.pdf/6 without redirects. Any other administrator may also do this kind of sensitive page moves by suppressing redirects. Then we may maintain evolving US Code.--Jusjih (talk) 22:34, 6 February 2023 (UTC)

The old Book Creator and PediaPress books

This is kinda a deletion discussion, but it's a bit too broad to only happen on WS:PD.

Once upon a time, the way to get PDF versions of our texts was the Book Creator. It was designed for Wikipedia and let you save a definition of "Wikipedia articles that should be included in a ‘book’" (plus ordering of chapters etc.). It was developed in a partnership with PediaPress (a commercial entity focused on print-on-demand services), and so it also offered the option of ordering print-on-demand physical books of these ‘books’. Somewhat half-heartedly it was extended to also work on non-Wikipedia WMF projects, including Wikisource.

However, since 2019 it has been effectively broken. The Creator tool kinda works, but none of the PDF/ODT/ZIM download options do and the print-on-demand function seems to have bitrotted in the intervening years.

At the same time, Community Tech developed the new ws-export function, the one that makes that big honkin' blue "Download" button on all our mainspace pages; offers PDF, ePub, and Mobi-format downloads; and is directly integrated in Wikisource and our content and workflows (naturally enough, since it was developed specifically for Wikisource).

The links to the Book Creator have already been removed from the sidebar and the associated project/help pages marked as deprecated and historic; but I think it's also time we got rid of all the now-mostly-broken pseudo-books sitting in Category:PediaPress books, along with associated templates with boilerplate etc. Thoughts? Xover (talk) 10:16, 28 January 2023 (UTC)

We should probably at least add a deprecation warning like the one present at w:template:Saved book. I don't know if it's necessary to actually delete these pages; if anything they should be kept for archaeological interest. Shells-shells (talk) 11:50, 28 January 2023 (UTC)

I "umm and ah" over this issue of the stored works some of the time and in the end I just walk away as seems one of our lesser issues. 1) They are static copies of works that are essentially dynamic as we proofread, validate and otherwise develop works--so that they are essentially uncontrolled copies as soon as they are output. 2) They do show a work at time A, and can show it later at Time B--possible showing versions. 3) They are in user: ns and WS: ns, so WS: ns is controlled by the community, and user: ns is controlled by the individual within community standards. 3) (open question) Where are they on a harm scale are static PDFs doing? Negative? Neutral? Positive? I would not want to be doing something that has zero harm and impacts uses. Have we even looked at the stats for visits? — billinghurst sDrewth 02:28, 30 January 2023 (UTC)

https://pageviews.wmcloud.org/?project=en.wikisource.org&platform=all-access&agent=user&redirects=0&range=latest-20&pages=Category:PediaPress_books <= view stats
https://xtools.wmflabs.org/articleinfo/en.wikisource.org/Category:PediaPress%20books <= other stats

These aren't PDFs, and you can't get any versioning wit them. The old "Book Creator" stuff saves pages that are essentially an AuxTOC/portal with a non-standard and broken header. A Book Creator "book" looks like this:

A book?

	This is a Wikisource book	Bookshelves [ Wikisource ] [ Wikipedia ]
	This is not an encyclopedic article. For more information, see Wikisource:Books, and the introduction to Wikisource.
	[ Download PDF ]  [ Download ODT ]  [ Download ZIM ] [ Open in Book Creator ]  [ Order Printed Book  ]

Alice's Adventures in Wonderland

Alice's Adventures in Wonderland/Chapter 1

Alice's Adventures in Wonderland/Chapter 2

Alice's Adventures in Wonderland/Chapter 3

Alice's Adventures in Wonderland/Chapter 4

Alice's Adventures in Wonderland/Chapter 5

Alice's Adventures in Wonderland/Chapter 6

Alice's Adventures in Wonderland/Chapter 7

Alice's Adventures in Wonderland/Chapter 8

Alice's Adventures in Wonderland/Chapter 9

Alice's Adventures in Wonderland/Chapter 10

Alice's Adventures in Wonderland/Chapter 11

Alice's Adventures in Wonderland/Chapter 12

[[Category:PediaPress books|Alice's Adventures in Wonderland]]

They don't update in any meaningful sense. So, for example, when we delete the subpage redirects for the chapters in the above example, the "book" will be completely broken (just a list of redlinks). The links in that header template also do not work, not even the "Order Printed Book" one, with the exception of the link to the Book Creator (which lets you produce more broken "books" and confuse users and visitors).

In order to get a PDF (or ePub, or...) you have to use the big blue "Download" button that is implemented through "ws-export". It's completely separate from "Book Creator", and Book Creator is unlikely to ever be meaningfully fixed (which is why enWP nuked it). But the good news is that the "ws-export"-based function doesn't need a separate book creator as it uses our existing page structure, and thus it's always entirely live updated (modulo some short term caching).

In any case... I'd say the value to users of these is now actually negative: it doesn't work but it leads them down the garden path by looking like it ought to work. We also have a great alternative that is integrated directly into our normal workflow. On the harm scale it doesn't rate all that high: there are few links remaining, and the prominent "Download" button from ws-export means users rarely end up on one of these "books". So my main motivation here is just getting rid of old cruft that no longer serves any useful purpose. I've now stumbled across them enough times that instead of just grumbling and moving on I took the time to post about it here.

PS. See w:Wikipedia:Books for how enWP handled getting rid of all the broken pages while still making it possible for "archaeologists" to do their thing if anyone should ever be interested. @Shells-shells: cf. your above concern. --Xover (talk) 14:18, 30 January 2023 (UTC)

Generally I would prefer not to have them here, especially as some of them break our policy forbiding compilations, like Wikisource:Books/Human Rights: A compendium. However, I am quite reluctant to interfere in the user space. So I suggest to keep those which are in the user space but at the same time get rid of everything that implies that Wikisource supports such books. This includes:

• delete those which are in the Wikisource namespace, unless somebody wishes to move some of them into their own user space
• cancel categorization of those left in the user space
• remove the {{saved book}} template saying "This is a Wikisource book" or replace the text of the template with some other text saying that it is a result of a deprecated project not supported by Wikisource anymore.

However, if it is decided that they should all simply go, I would not protest either. --Jan Kameníček (talk) 00:34, 12 February 2023 (UTC)

Blanking User: pages (as an alternative to deletion)

We currently have (and periodically get) a bunch of user pages, userspace drafts, and user sandboxes proposed for deletion at WS:PD. They are usually proposed for deletion because they contain some old crufty code that puts them in a real content category, a maintenance backlog, contain some problematic code, mess up searches, drown out relevant entries on limited Special: pages (these are often limited to 5000 entries, so too much cruft make them unusable). But the community has historically (going by the outcomes of the deletion discussions) had a fairly high threshold for actually deleting stuff in User: space. Naturally enough since on WMF wikis it tends to be a no no to edit inside another user's user space. So these crufty old pages tend to stick around unless there are really strong reasons to delete them.

So… As an alternative to deletion, I have just created {{blanked userspace page}}. It's a simple message template that just says:

It's intended to be used to replace the content of a userspace page (i.e. blanking it) while explaining both how to get the content back if wanted, and reassuring everyone that it's a purely technical measure. Only to be used for userspace pages that show up where they're not supposed to, and only for pages in inactive users' userspace (active or recently active users you should talk to instead of using this template). And any actual deletion reasons (copyvios etc.) should go to WS:PD or WS:CV as usual.

I've currently put in lots of warnings in the template's docs ("experimental!", "admin only!", "use caution!"), but if the community feels it's comfortable with this approach I'm thinking this should be fine for any experienced user to do if and when they come across such pages. There's no real reason it should be restricted to admins (beyond them being used to making that sort of judgement call and by definition trusted by the community), and if anyone misuses it they can be thwapped upside the head gently chided and shown the error of their ways.

Can I get a quick straw poll on this? Yes, no, indifferent? The more people chime in (even with "don't care") the better we can gauge what the community's sentiment is for this. Xover (talk) 20:30, 15 January 2023 (UTC)

Pinging @ShakespeareFan00 and @PseudoSkull, who have recently participated in discussions on this issue. I have also added a watchlist notice pointing to this discussion in an attempt to better gauge what the community thinks about this. Xover (talk) 20:43, 15 January 2023 (UTC)

It's gentler than deletion and does not alter the actual content of the page, so if there is a genuine need for it then I think it's an acceptable solution. I'm not clear on the maintenance issues, though. Can you give an example of a page in userspace causing technical difficulties? Shells-shells (talk) 20:58, 15 January 2023 (UTC)

Well, the ones that are currently at WS:PD were probably (I'm guessing) found because they showed up on Special:LintErrors. I've had (since fixed) pages show up in Category:Pages with script errors (or other error categories added automatically by MediaWiki). We had one user with ~15k DNB stub articles in their user space, all of which showed up on Special:WantedTemplates (which only shows the first 5k pages). Userspace pages also regularly show up in searches when we're looking for, say, a CSS class and where it's used; trying to migrate from an old template to a new one (or migrating its arguments from one style to another, or...). It's that sort of thing: noise that makes other maintenance tasks harder or masks real problems. Very rarely do they directly cause any problems on their own. Xover (talk) 22:37, 15 January 2023 (UTC)

 Support, I don't see any problem with this approach. Although I do have a question (as someone who doesn't go around looking for pages with semantic errors or bugs): When looking for such linting errors/CSS errors, etc., is it not possible to filter outside of the User namespace for these? I think it would be very rare you'd need to fix a random userspace page in this way, since they generally shouldn't be edited unless they're your own user page per the wiki commandments. PseudoSkull (talk) 23:27, 15 January 2023 (UTC)

Often it is possible to filter. Sometimes it is not. For example on Special:WantedTemplates and similar. It is also one more thing to juggle in sometimes quite complicated searches. e.g. in stuff like this. And for some things you can't filter on namespace because a template or CSS class might be in use on the user's user page itself, or on pages in other users' userspace, and needs to be migrated. Having the option to just "softly" remove old and inactive userspace drafts and sandboxes that create noise for these cases would make a lot of these operations a lot less finicky.

But just to be clear: we absolutely can make do without this. It'll just make some things a lot less annoying to deal with for the small subset of users that work on this sort of thing. Xover (talk) 04:57, 16 January 2023 (UTC)

An example I just now ran across: User:BirgitteSB/Fuzzy-Wuzzy (plain)/wikified. It shows up in Special:WantedTemplates because it tries to transclude the long-deleted {{Wikipedia}}. And it shows up in Category:PD-old-80-US because it uses that license template. It would also have shown up as a use of {{PD-old-80-US}} before we moved all these to Lua, which would have needed to be investigated before that migration could be completed. It also uses the obsolete / deprecated <small> tag that we're trying to get rid of, meaning it's showing up on Special:LintErrors somewhere. And I can think of at least three more ways that page might show up as noise when we're performing various maintenance tasks, just off the top of my head.

The page is from 2005 (~18 years ago) and BirgitteSB hasn't edited since 2014 (~9 years ago), so it's exceedingly unlikely they'll ever return (although it would be nice if they did; they were a very active community member when they were around) and want to work on this page again. Xover (talk) 07:14, 16 January 2023 (UTC)

 Support. Jan Kameníček (talk) 23:57, 15 January 2023 (UTC)

 Support Looks good to me; I've edited the template so it doesn't itself show up in Category:Uses of blanked userspace page template in incorrect namespaces. —CalendulaAsteraceae (talk • contribs) 02:39, 16 January 2023 (UTC)

 comments User pages should not be needing to come to WS:PD unless it is truly necessary.
At the same time user pages should not be needing us to edit them to get around issues of css code issues, and the like. If we are fussing that stuff, we are fussing the wrong stuff.
If the special pages are showing those errors, then that is a problem with the special: pages. that they cannot filter out User: ns.
With regard to templates? If that is really what you need to then go ahead, it should not be a policy nor a required process, just something that you feel useful and comfortable to use. I currently have a practice of ignoring them, or blanking them, wrapping them in resolving code like <nowiki>; with an appropriate edit summary; or I also can delete them if that is more appropriate and more closely aligns with our deletion policy.
No, it doesn't need categorisation, nor anything overly bureaucratic, just use a good edit summary. It is a user page, and depends on its use and its level of problem. — billinghurst sDrewth 09:48, 16 January 2023 (UTC)

 Support, but if a user page is ever used for false vanishing, then delete the problematic versions.--Jusjih (talk) 06:22, 17 January 2023 (UTC)

 Support Creating a process/template like this is ideal. ShakespeareFan00 (talk) 16:59, 17 January 2023 (UTC)

 Comment I am a little concerned that we are starting to overly fuss about user namespace pages, and to have a level of authoritarian approach and resolution. These are meant to be our user's space to be able to play and practice. They are not our presentation space, and users have to purposefully go to these pages through interest to see such pages. We should be allowing users to do anything within scope, and to have whatever errors on their pages that they like.

That we are having lint errors showing on those pages is not a problem of the user, it is an issue of the linterror not being able to avoid or exclude those pages. The user has every right to have a linterror if they so choose. If pages are being categorised in a problematic nature, then we can fix our categorisation scheme, or tune the page so it doesn't categorise. We should only be blanking truly problematic pages that are out of scope, highly problematic and unable to be resolved by other means, or redundant by duplicating content from elsewhere. If we can keep out and let the user play within scope of the wiki, then that should be our first and only action. — billinghurst sDrewth 03:59, 13 February 2023 (UTC)