Wikisource:Scriptorium/Archives/2020-04

Someone with css smarts to update Template:Dotted TOC page listing

When someone uses Template:Dotted TOC page listing inside Template:auxiliary Table of Contents we have the issue that the default for the former template is white background. Forcing it to have the matching colour of the latter template can be done, however, due to the shite of the former template it has to be done line by line (see special:diff/10056337).

So to those who use Template:Dotted TOC page listing or its redirect "dtpl" if we can remove the default forcing to white would seem to be the best option, but I don't know enough about that template's wide usage. So there need to be alternatives built so that it is easier to apply the colour used in headertemplate class or universally override the white application by default. The solution I used is just an an unnecessary brute force hack.

I have started up a discussion on Template talk:Dotted TOC page listing about the forced white background, if people that the preferred means to resolve this matter. Otherwise we need a more elegant solution from someone with css smarts. — billinghurst sDrewth 23:06, 4 April 2020 (UTC)

Spam coordination

How do y'all handle spam here? And is there a universal spam list? Questions due to peeking at User:ChanaEdo66103 which has strange link to "hairtrade.com". Shenme (talk) 04:51, 5 April 2020 (UTC)

Yikes! That was quick. spambot, huh? Shenme (talk) 04:51, 5 April 2020 (UTC)

@Shenme: if you feel that you need to do anything just mark it with {{sdelete}}, and it will be got to within the day, at the most. There are some old heads around here. — billinghurst sDrewth 05:02, 5 April 2020 (UTC)

Tech News: 2020-15

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

• There was a problem with user pages not being shown properly on desktop. This was because of a bug. It will soon be fixed. [1]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 7 April. It will be on non-Wikipedia wikis and some Wikipedias from 8 April. It will be on all wikis from 9 April (calendar).

Future changes

• MediaWiki will use a newer version of Unicode. Some characters that did not have an upper case equivalent before do now. Titles beginning with one of these characters will be moved. A list of these titles can be seen on Phabricator. The titles will be renamed by the user Maintenance script. This will start on 13 April 2020. You can rename them before this if you wish and the new title can be different from the one the script would rename it to. [2]

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

19:01, 6 April 2020 (UTC)

Reminder: Technical maintenance planed‬

This is a reminder of the message sent on Monday 27th April.

A maintenance operation will be performed on Thursday 30th April at 05:00 AM UTC.

It impacts all wikis and is supposed to last a few minutes.

During this time, new translations may fail, and Notifications may not be delivered. For more details about the operation and on all impacted services, please check on Phabricator. a A banner will be displayed 30 minutes before the operation.

Please help making your community aware of this maintenance operation.

Thank you, Trizek (WMF) 15:05, 29 April 2020 (UTC)

Layout 5

I suggest to add new layout 5 to {{default layout}} with max-width: 84ex; text-align: justify; margin: 0 auto; font-family: Cambria, Times New Roman, Times, FreeSerif, serif; font-size: 120%;
Example
It's more suitable for eyes than other layouts which are very small. And mobile version of this layout is enjoyable. Taken from ru.wikisource («Основной класс для оформления прозы»).
PS. It's impossible to do such layout through browser settings for ordinary users. And very few people know CSS, non-wiki code etc. Please do not use objections that require knowledge of programmers or technical students. Thanks. Ratte (talk) 11:03, 10 April 2020 (UTC)

It would help if you outlined precisely what this Layout is intended to do differently from existing Layouts. Also, Is there a broad need for this layout, or do you have only the one work in mind for its application? Work-specific layouts have little utility. --EncycloPetey (talk) 19:31, 10 April 2020 (UTC)

Layout 1, Layout 2, Layout 3, Layout 4, proposed Layout. You can see how is it different from the rest. A text can be read without breaking eyes. No, I don't have only the one work in mind for its application. PS. I don't know if Layout 3 ever used here — never seen a text without header in enWS (speaking about broad need). Ratte (talk) 21:47, 10 April 2020 (UTC)

Asking people to figure it out for themselves is never a strong argument in favor of something. Without a justification for creating a new Layout, it will likely not happen. --EncycloPetey (talk) 22:11, 10 April 2020 (UTC)

Sorry I don't understand what exactly I have to explain. Proposed layout makes the font bigger (unlike all layouts). The text is displayed in a serif font (like layout 2) and the content is centered (fixed-width column, like layots 2 and 4) but the text is wider than all of them. Similar to the style at Russian Wikisource. You cannot reach such an effect in browser (it's possible to enlarge text, but you cannot increase the number of letters in a line). Ratte (talk) 22:55, 10 April 2020 (UTC)

A layout should never force a font size change. That should be entirely under the control of the reader. A comparison with Russian Wikisource is not meaningful; Russian uses a different alphabet and necessarily will look different from languages in a Latin alphabet and therefore have unique requirements. --EncycloPetey (talk) 23:27, 10 April 2020 (UTC)

Reconstruction on context, and clipped scans...

Prompted by:-

Page:Loss of the Comet steam-boat on her passage from Inverness to Glasgow, on Friday the 21st October, 1825.pdf/17

I wrote a quick template {{Reconstruct}} to allow for "reconstructed" text which is determinable from context to be transcribed but marked as such, and to allow the {{illegible}} to be used for text that is more obviously unreadable or undeterminable.

However, before a template like this widely,I'd like some opinions, given that generally English Wikisource doesn't annotate works. ShakespeareFan00 (talk) 16:14, 10 April 2020 (UTC)

Chronological order or reverse chrono?

When compiling a bibliography of an author does the earliest work go at the top of the list or the bottom of the list? --Richard Arthur Norton (1958- ) (talk) 01:38, 11 April 2020 (UTC)

You mean for an Author page? We list oldest first, and proceed in chronological order. However, long lists can be broken into logical groups by type, and lists of items such as poetry can be sorted alphabetically if the dates for many items are not known. See Wikisource:Style_guide#Author_pages --EncycloPetey (talk) 01:46, 11 April 2020 (UTC)

• Thanks! --Richard Arthur Norton (1958- ) (talk) 02:27, 13 April 2020 (UTC)

Seeing: File:Lua error

I was just following a link [3] and on the top of the page I see the following message:

<quote> [[File:Lua error in Module:I18n at line 19: bad argument #1 to 'next' (table expected, got boolean).|thumb| Sigmund Freud ]] </quote>

(Sorry, I can't quote display it correctly here.)

I don't see any obvious related line causing the error myself, so guess it may be some hidden code.

Would somebody have time to be able to investigate this, or do I need to report it to a support group? Thanks Sp1nd01 (talk) 09:53, 11 April 2020 (UTC)

@Sp1nd01: The page that you noted existed for a sum total of five minutes 01.47 to 01:52, you should be fine now. I am not currently seeing it on the author page that you cited. The module is protected with a note to not create, even if empty. — billinghurst sDrewth 10:05, 11 April 2020 (UTC)

Thanks the page looks fine again now. Sp1nd01 (talk) 10:13, 11 April 2020 (UTC)

@Sp1nd01: I have been seeing that error on multiple Author pages, cause by the issue billinghurst described. A null edit will correct the page when you find it again. It seems to appear more often on high-traffic Author pages, and I have been manually correcting the problem on all the high-traffic Author pages. --EncycloPetey (talk) 15:29, 12 April 2020 (UTC)

Spam whitelist request 2

I would like to ask whether it is possible and desirable to whitelist external internet page https:// medium.com/freely-sharing-the-sum-of-all-knowledge/wikimedia-coronavirus-response-people-first-8bd99ea6214b as Slowking4 has expressed their desire to quote the executive director of the Wikimedia Foundation, and provide a reference on their user page. I am founding a brand new request as it seems to me better to start the discussion anew without the burden of previous problematic contributions. --Jan Kameníček (talk) 10:43, 13 April 2020 (UTC)

Done — billinghurst sDrewth 12:37, 13 April 2020 (UTC)

Template:Outdent

en:Template:Outdent, on en.Wikipedia as on many sister projects, is different to Template:Outdent on this project, and is used on talk pages to reduce excessive indentation in long threads.

Please can someone import it to this project, with a suitable name; perhaps Template:Talk outdent? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:08, 13 April 2020 (UTC)

@Pigsonthewing: Were you looking for {{outdent talk}} perhaps? 114.78.66.82 12:00, 13 April 2020 (UTC)

Thank you; yes. I didn't find it, because the wrong template was linked to the corresponding Wikidata item, which I did check. I have now fixed that. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:07, 13 April 2020 (UTC)

This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:08, 13 April 2020 (UTC)

Tech News: 2020-16

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 now use the articletopic search word on all Wikipedias. It searches articles by topic. [4]
• You can see wiki tools in the new Tools Gallery. [5]
• You can see edits from the Wikimedia Cloud Services in a new dashboard.
• When you use filters on a history page you sometimes don't see any edits. There is a text explaining this now. Before it was just empty. [6]
• There is a new Wikimedia Technical Blog. [7]

Problems

• There was a problem with the Wikidata database last week. Some wikis went down for twenty minutes. Wikidata and other projects showed error messages. Interwiki links were not shown, some tools did not work and other problems. Some of this was fixed quickly. The developers are working on fixing the rest. [8][9][10]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from April 14. It will be on non-Wikipedia wikis and some Wikipedias from April 15. It will be on all wikis from April 16 (calendar).

Future changes

• Some graphs have not worked on mobile. This will soon be fixed. [11]
• The article tab on talk pages of redirects links to the target of the redirect. It could link to the redirect page itself instead. You can leave feedback on this.
• For pages using syntax highlighting, the use of the deprecated <source> tag, as well as the use of the deprecated enclose parameter, will add tracking categories.

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

15:30, 13 April 2020 (UTC)

Post: Help smaller wiki communities grow their technical capacity!

“	Hello all, Small Wiki Toolkits (SWT) is an initiative to support small wikis communities by sharing and developing technical skills needed to support, maintain, and grow a language wiki. You can learn more about it here: m:Small wiki toolkits. As a next step for this initiative, we would like to share with you some ideas on how you can be a part of this: Contribute to a Starter kit by proposing or helping develop and write recommendations for technical topics in simple English. Develop toolkits using the recommendations on the SWT page. You can see existing toolkits in the c:Category:Small wiki toolkits on Wikimedia Commons. Learn technical topics using the resources on the SWT page and apply the skills gained to provide technical support to a small wiki community. Translate resources such as the SWT page itself and tutorials on technical topics linked from it. Provide technical support on the support desk on mediawiki.org, mailing lists, etc. Organize a technical workshop or a session to help a small wiki community. If you want to help with any of the above or there is anything else you would like to share around building local capacity in a small wiki, please start a discussion on the talk page and/or add your name to the list of interested members. Cheers, The Small Wiki Toolkits Initiative	”
—Srishti Sethi, Wikitech-ambassadors-L mailing list

Reposted from mailing list. While we are not exactly small, our technical capacity is different due to our dynamics, as such we share similarities and may have experiences. — billinghurst sDrewth 00:11, 14 April 2020 (UTC)

Why is Medium on blacklist?

Hi all,

I'm totaly confused by this situation. @Pigsonthewing: has not provided a clear use case on #Spam whitelist request but nonetheless, why is Medium block on en.wikisource ?

I've looked on all the 800+ Wikimedia projects, it's the only one who fully put Medium on the blacklist. It was added last August by @Billinghurst: (Special:Diff/9560485) without comment, is there a specific reason behind that?

Meanwhile, I can see a lot of links to Medium who seems legitimate (see Special:LinkSearch) and Billinghurst himself provide a good use case (adding this link to Author:Katherine Maher).

Am I missing something?

Cdlt, VIGNERON (talk) 09:56, 13 April 2020 (UTC)

┌─────────────────────────────────┘
"has not provided a clear use case" As I said above:

That question is beyond pointless. Once the link is whitelisted, any editor can use it anywhere on Wikisource. And still no good reason has been given why a post by the CEO of the Wikimedia Foundation, about the work of the Wikimedia Foundation should remain spam-blacklisted has been given.

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:01, 13 April 2020 (UTC)

Medium is on the meta:Spam blacklist too. It was added there based on some "spambot regexes", but I have no idea what it means. --Jan Kameníček (talk) 11:15, 13 April 2020 (UTC)

[ec] It is not; the entry there is for \bmedium\.com/@Technsolution which is a single Medium user (presumably not a senior member of WMF staff). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:20, 13 April 2020 (UTC)

@Pigsonthewing: a use case is indeed not *needed* but it would still be very *welcome*, especially since it has been asked several times. It may make the situation clearer to everyone and make us understand each other better.

That said, I totally agree and I'm going further: don't whitelist this link (and other links), remove the blacklist on the whole website. Just to clarify, this Medium post is not blacklisted specifically, the whole Medium website is blacklisted for some unknown reason yet to be determined; which may be good or bad, but again context is key to understand the situation, let's wait for @Billinghurst: explanation before drawing any unsupported conclusion.

@Jan.Kamenicek: not exactly, the whole website is not blacklisted, only one page (who seems to have disappeared in-between). Blocking one page, this is usual and I totally understand (especially, if it's spammed) but blocking the whole website, this is very unusual and unexpected.

Cdlt, VIGNERON (talk) 11:20, 13 April 2020 (UTC)

I requested this URL be whitelisted on 16 March; that is four weeks ago today. I have given a very good reason why it should be. No good reason why it should not be whitelisted has yet been given. No reason why the whole domain is black-listed has been given. More then enough time has been wasted by obstructionist editors; please don't proxy for them. As for Billinghurst, they have yet to reply to the questions I asked them, also on 16 March, so I wouldn't hold your breath - especially as those unanswered questions have now been hatted by another admin. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:24, 13 April 2020 (UTC)

 Comment medium.com is regularly spambot spammed, it got blacklisted. It is why have blacklisted many others that are there. Regular enough hits in the spamblacklist log, and regularly shows up in abuselog filters. — billinghurst sDrewth 12:06, 13 April 2020 (UTC)

And still no good reason why the specific link under discussion cannot be whitelisted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:09, 13 April 2020 (UTC)

Sure it can be whitelisted, not certain why my opinion on the link matters. I cannot say that I had read the discussion to form an opinion. Guess what, I don't read every discussion here, and don't get buried in your carry-on, nor pay much attention to your general discussion. Life is too precious, and with you most things are a drama. As I have mentioned before, if people have a request for an admin action, they are best placed at WS:AN; another place for requests for whitelisting is Mediawiki talk:spam-whitelist and utilise {{edit protected}}. At those forums I personally pay attention for things that require admin attention. — billinghurst sDrewth 12:34, 13 April 2020 (UTC)

It matters because of your comment and my reply to it - though those were so long ago I can conceive that you might have forgotten them. If you actually done what was - quite reasonably - asked for in the first place, instead of going off at tangent; and if you had not ignored the latter, then there would have been no need for what you so pejoratively deride as "drama", in order to achieve what has finally, and rightly, and inevitably, been done. You'll also note that my original post - the one to which you did respond - ended "[Feel free to point me to a more suitable venue, if not here]." You did not do so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:58, 13 April 2020 (UTC)

the drama will continue until routine whitelist requests are handled in a routine way, wherever they might happen to be made. when outsiders are astonished, then you know you have crossed a line; and we should all understand that the drama is caused by admins: it is a power trip thing, as we see in this case. Slowking4 ⚔ Rama's revenge 22:54, 14 April 2020 (UTC)

User:Dmitrismirnov

User:Dmitrismirnov reported deceased April 9 [12] - Slowking4 ⚔ Rama's revenge 13:14, 14 April 2020 (UTC)

That is sad news. He will be missed. --EncycloPetey (talk) 20:13, 14 April 2020 (UTC)

very sad news. Perhaps someone should protect his user page? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:58, 14 April 2020 (UTC)

Thanks for sharing the sad news, @Slowking4:. -Pete (talk) 04:19, 15 April 2020 (UTC)

)))-: I have protected the user page, left a report of death on said page, and asked stewards to remove the administrator rights. request. WS:Administrators will need to be updated in the removal from the list, and closing the graph. — billinghurst sDrewth 05:08, 15 April 2020 (UTC)

Done The ugly side of saying goodbye. — billinghurst sDrewth 08:23, 15 April 2020 (UTC)

Scratch that!

So I just noticed that Treaty of Wanghia does not have the lengthy table as seen in the linked 'source' PDF (starts page 9 just more than half-way)

(This text differs in many small ways from what is seen in the PDF - capitalization, -ise/-ize, punctuation - it is obviously not a direct correspondence. It may be that the *actual* scanned source did not have the table, thus no text to start from)

If I were to attempt adding the table, it would take a long time. I might not finish completely. (future viewers may check the date for why I mention that) Thus while I have on occasion worked on small bits (like Lilypond music) in my own user space subpages before, I am hesitant to do so with something intended for main space, and that I would want someone else to be able to pick up to complete. Yet I don't want to tromp all over the existing main space article Treaty of Wanghia with wierd eldritch workings in the meantime.

So, do I

• work in a user space subpage, leaving in Talk:Treaty of Wanghia a note for the future where to find that, or
• work in a subpage of the article, e.g. Treaty of Wanghia/Import Export Tariff Duties, and then link from article to that subpage?

Advice? Shenme (talk) 06:02, 16 April 2020 (UTC)

What would be best is to create an Index: from the pdf and then work in the Pagename space. Once it's all satisfactory there, then it can be transcluded over the top of the current content. Beeswaxcandle (talk) 06:34, 16 April 2020 (UTC)

yeah welcome to the limitations of non-scan backed works, where they leave off the hard images and tables. we on the other hand eat table code for breakfast. ([13]) you need to change to book template (c:Template:Book) at commons, c:File:Treaty of Peace, Amity, and Commerce.pdf to make a link to the index page, to start the migration to a page by page scan backed version here. when working tables, i tend to dump the text layer into an old Magnus tool [14], and visual editor makes table editing a little easier. cheers. Slowking4 ⚔ Rama's revenge 12:55, 16 April 2020 (UTC)

Index:Arthur Cotton - The Madras Famine - 1898.djvu

The pages need to be moved to accommodate for the corrected file. TE(æ)A,ea. (talk) 23:28, 17 April 2020 (UTC).

Mis-sorting behaviour

If I put the relevant category in manually then an entry for Category:WikiProject NLS sorts into an appropriate alphabetic location, if I put it in using the Category field in the Index page edit mode, then the Index concerned is placed under W, even when the name does not start with a W.

Suggestions as to what I am ACTUALLY supposed to do to get proper sorting in the category would be appreciated. ShakespeareFan00 (talk) 13:45, 17 April 2020 (UTC)

Seems to be an issue with how the category component has been built recently. It seems to be sorting based on the category name, overriding the defaultsort (based on pagename, or the key field, even where forced MediaWiki:Proofreadpage index template). Trying to pipe it through HotCat fails as well. Lodge a phabricator ticket against ProofreadPage. — billinghurst sDrewth 14:10, 17 April 2020 (UTC)

Time before a wiki page is refreshed expires

When in edit mode, does anyone know what is the length of time before a page is required to be refreshed reloaded? — Ineuw (talk) 22:20, 18 April 2020 (UTC)

No idea of what you are asking. — billinghurst sDrewth 02:29, 19 April 2020 (UTC)

Pages that are opened for editing and remain opened, after some time they expire and cannot not be 'published' on the first try. My question is whether the web page expiration is a timed event, or does it depend on web traffic? — Ineuw (talk) 03:31, 19 April 2020 (UTC)

System. Just save it again. As long as the page hasn't been edited by someone else it can go for multiple days in that mode. — billinghurst sDrewth 05:15, 19 April 2020 (UTC)

Thanks. I had an idea and that's why I asked. — Ineuw (talk) 05:21, 19 April 2020 (UTC)

@Ineuw: Presuming you mean the issue where you try to hit "Publish" and MediaWiki complains that the page could not be saved due to a "loss of session data" (and "please make sure you're still logged in" etc.). I haven't been able to dig up decent documentation on this, so the below is a bit of guesswork, but…

…it's an artefact of how MediaWiki does authorization and edit conflict detection. When you start to edit a page it saves some info (revision id, user session) in a web browser cookie. The cookie has a specific expiry time (that I haven't been able to find documented) and MediaWiki tries to associate the other information in the cookie with a specific user session server-side. If the cookie expires (purely time based) or if it fails to associate the operation with a user session (I'm not sure, but I think this can happen for a myriad of reasons; including low level technical stuff like TCP connections changing, or getting load-balanced to a different server, etc.), then MediaWiki will give you that error message and ask you to try again. I usually see this when my laptop has been put to sleep after I started editing a page but before I try to save it. I don't think I've seen it happen just because of time.

There's no obvious good reason why MediaWiki should do this, but I'm guessing it's a tradeoff with other concerns (i.e. the edit conflict detection) that makes it hard or impossible to just handle the relevant situation "under the hood" without bothering the user. --Xover (talk) 05:23, 19 April 2020 (UTC)

@Xover: Great explanation! My thirst for knowledge and understanding is quenched. I had a vague thought that it depends on both the system and the connection.

To avoid edit conflicts, I had the idea of a temporary notice to be displayed on the "read" and "edit" view when a page is opened for edit — displaying the time when edit began, and remain displayed when "Show preview" is clicked, but disappear when the view is back to read (regardless if it's saved or closed). If {{Under construction}}, or {{In use}} are used, they need to be saved and are visible only on the watch list, but it's still not readily seen by an editor. Just a thought, and thanks again. — Ineuw (talk) 06:44, 19 April 2020 (UTC)

Index:A Glimpse at Guatemala.pdf

I have started adding a few of the images for this book, however on some pages the scan parts appears blank in my browser.

So far I've come across:
https://en.wikisource.org/wiki/Page:A_Glimpse_at_Guatemala.pdf/5 (No Image on page, but no text displays.)
https://en.wikisource.org/wiki/Page:A_Glimpse_at_Guatemala.pdf/29 (No Image on page, but no text displays.)
https://en.wikisource.org/wiki/Page:A_Glimpse_at_Guatemala.pdf/37
https://en.wikisource.org/wiki/Page:A_Glimpse_at_Guatemala.pdf/49

The original source where I am obtaining the images from does display the missing images and text as expected, so the source file isn't faulty.

i.e. see https://archive.org/details/glimpseatguatema00maud/page/21/mode/2up

Can anything be done to fix this problem or do I mark the book as "source file incorrect"?

Thanks Sp1nd01 (talk) 10:43, 19 April 2020 (UTC)

@Sp1nd01: MediaWiki weirdness. The thumbnail size (1024px) that PreviewPage requested was broken on Commons. Manually requesting a different size worked fine; so I purged the file on Commons and that seems to have fixed it. You may still have the broken thumbnails cached in your browser, but the pages look fine here now. --Xover (talk) 14:57, 19 April 2020 (UTC)

Thank you, it's now displaying normally for me also after I purged the pages. Sp1nd01 (talk) 16:24, 19 April 2020 (UTC)

Dating in Mommsen's History of Rome

Another marginalia problem. I've been working on porting over what we had of The History of Rome (Mommsen) to a scan version and doing some more of the transcription. The book has some sidenotes, but because the scan has cut off many of the headers and there are also clusters of them that are hard to present, at the moment I'm just ignoring the marginal headers per previous community discussions that suggested people don't generally think they are essential.

The dating however is a bit more intractable. The book uses Ab Urbe Condita dating, which is probably going to be difficult for most readers, and adds the corresponding BC dates in the margins. I'd like to have the BC dates available in the transcription, and I think there's probably a more elegant option than the sidenote templates—for example a work-specific template to produce text like 400 u.c. ^{(350 b.c.)} Curious what others think. —Nizolan ^(talk) 12:04, 21 April 2020 (UTC)

Went ahead and created Template:AbUC, will see how it goes. —Nizolan ^(talk) 23:17, 21 April 2020 (UTC)

Fixing author page

Paṇḍit Naṭêsá Sástrî is represented as Author:Natesa Sastri and Author:Sangendi Mahalinga Natesa Sastri; I have used the latter. They both have metadata, which need to be combined. TE(æ)A,ea. (talk) 21:44, 20 April 2020 (UTC).

Done thanks for the note. -Pete (talk) 21:54, 20 April 2020 (UTC)

• Thank you. TE(æ)A,ea. (talk) 23:04, 20 April 2020 (UTC).
•  Comment I am not certain, but "Sangendi Mahalinga" look like honorifics to me. I am not able to read Tamil source material to be sure, but if they are honorifics then they should not appear as part of the author's name. Does anyone here know someone who can read Tamil? --EncycloPetey (talk) 23:17, 20 April 2020 (UTC)

  Good observation. @Thamizhpparithi Maari: can you help? -Pete (talk) 23:47, 20 April 2020 (UTC)

I've just consulted with a couple of my staff who come from South India. The usual pattern for their names is place of birth (Sangendhi is a village in Tamil Nadu) followed by father's name (Mahalinga is an aspect of Shiva), which together make the surname. So, choosing the longer version as primary is correct for enWS. The other needs to be a redirect. Beeswaxcandle (talk) 05:26, 22 April 2020 (UTC)

Thanks for gathering that information. --EncycloPetey (talk) 14:50, 22 April 2020 (UTC)

Done

Special:IndexPages reporting incorrect number of proofread pages

I have only recently learned of the existence of Special:IndexPages. Useful, but in this case, it seems to be misleading. Look at this result; the work I'm interested in is the third one listed, Index:History of Oregon volume 1.djvu. If you look at the index page, you'll see that we've made good progress: more than a third of the pages are validated. But if you look at the report, it appears that very few pages have been validated. Anybody know what's going on? Should I file a bug on Phabricator? -Pete (talk) 22:03, 21 April 2020 (UTC)

It just needed a "null edit" to the Index page to cause the statistics to update. I have made such an edit, and you can see that the statistics are now current. --EncycloPetey (talk) 23:00, 21 April 2020 (UTC)

I have just checked statistics of several other index pages and it was mostly wrong too (example). The necessity to go to the index page and make a null edit whenever I want to check similar statistics makes the statistics page much less useful and not very user-friendly, especially as the statistics page does not say anything about it :-( --Jan Kameníček (talk) 23:11, 21 April 2020 (UTC)

That will presumably be phab:T111235 and phab:T188856 again. I will run through a complete purge of the index files, and see how that long that takes for 17k files. I would prefer to not have to whack the system that indiscriminately, and definitely not very often. Let us see what at mw:Manual:Pywikibot/touch.py may allow us to discriminate, and let us see how long it takes. — billinghurst sDrewth 15:45, 22 April 2020 (UTC)

Project activity

Hello everybody, is there a tool showing the progress of a certain project? I'd like to have something similar like the code frequency for repositories shown here for example. It should show the changes of all pages related to the project over the last days, weeks or months. Thank you in advance, --Arnd (talk) 10:46, 20 April 2020 (UTC)

@Aschroet: I am unaware of any frequency or time lapse data. We can do "now" with Special:IndexPages and projects Dictionary of National Biography. Noting that you can load keywords into the Index pages if you wish to track some series. Otherwise there is just the holistic toollabs:phetools — billinghurst sDrewth 11:05, 20 April 2020 (UTC)

Hi billinghurst, i found something useful: Special:RecentChangesLinked/Index:Early Man in Britain and His Place in the Tertiary Period.djvu. --Arnd (talk) 07:01, 24 April 2020 (UTC)

@Aschroet: Yes, though that only has the time period of "RecentChanges" so it is fine for a month. — billinghurst sDrewth 07:09, 24 April 2020 (UTC)

Public domain cutoff, again

Background For a long time, works first published before 1 January 1923 have been public domain in the United States. For various Mickey Mouse related reasons, this cutoff date did not advance until 2019; ever since then the cutoff has been 1 January [current year - 95]. This fact is well established and is not in dispute.

In January 2019, there was a community discussion regarding updating both our standard public domain templates and our copyright help pages to reflect the fact that the cutoff for published works in the U.S. was finally advancing. The consensus was that the content of these pages should reflect the correct cutoff date of January 1, {{#expr:{{CURRENTYEAR}}-95}}. No consensus was reached on whether templates like Template:PD/1923 should be moved or renamed. At the time, the only objector was User:EncycloPetey, for reasons that I do not understand. At any rate, the content was changed, and User:EncycloPetey stopped reverting these edits, so I thought at the time the issue was resolved.

Fast forward to more than a year later, when I notice that Template:PD-anon-1923 has a hard-coded date of January 1, 1924, of all things. Clearly someone updated it for the 2019 advance but wasn't thinking about the years to come. I correct it to the dynamic {{#expr:{{CURRENTYEAR}}-95}} expression, but then along comes User:EncycloPetey to undo it, and then, in an ensuing discussion, he chides me for bypassing consensus, and raises more objections that do not make any more sense than the ones he raised more than a year ago.

I am starting this discussion to resolve this once and for all, because there are potentially more PD templates that need to be corrected, and I do not want to dance this dance again. Phillipedison1891 (talk) 08:32, 21 April 2020 (UTC)

P.S. Please remember to separate this issue from the issue of renaming the PD templates that have 1923 in their name. The community may be legitimately divided on that issue but it is not on this one. Phillipedison1891 (talk) 08:37, 21 April 2020 (UTC)

Please do not start duplicate or parallel discussions.

Please note that the discussion you've linked above is not last year's discussion. It is the side-discussion you started last year while another discussion on the same topic was ongoing, and this thread is yet another side-discussion that you've started while the same discussion is ongoing on the same page. Please participate in the primary discussion on this topic instead of opening a duplicate thread. --EncycloPetey (talk) 14:31, 21 April 2020 (UTC)

You mean the discussion about the completely different topic of renaming templates with 1923 in their name? That has nothing to do with ensuring the content of those templates accurately reflects which works are in the public domain in the United States. No contributor on this God-blessed wiki has provided any input on why this template should give January 1, 1924, rather than the undisputed accurate date.

Frankly, the intended topic of this discussion is at least partly about your disruptive behavior, which is why I first tried to resolve this on your talk page (until you rebuked me for that, too). You revert completely uncontroversial edits made in good faith. You cite your own objections, which nobody understands, and you make no serious effort to reach an understanding. You then pawn off your objections (which again, nobody shares nor understands) as "community discussion" all while doing everything possible to shut down actual community discussion.

Again, it cannot be emphasized enough that we went through all of this last year, practically word for word, right down to the "Please do not start duplicate or parallel discussions" card being played. Right now, my frustrations are at a peak, and this is the last time that I will engage with you directly. I await the input of other community members. Phillipedison1891 (talk) 17:20, 21 April 2020 (UTC)

Please read the proposal. It is not a different topic. Again, do not start a parallel discussion on the same topic as an ongoing discussion. --EncycloPetey (talk) 18:16, 21 April 2020 (UTC)

It's not a very ongoing discussion, and it seems dissimilar to that discussion, anyway. I see no reason why this change shouldn't be made.--Prosfilaes (talk) 05:16, 24 April 2020 (UTC)

That discussion proposes to retire this template altogether. If you think we should instead edit the existing template, then please close that other discussion as "failed" or "no consensus". Once we know that the template isn't being retired or replaced, then we can discuss making changes to it. Are you saying that the open discussion is not likely to reach a consensus> That is what is sounds like. If so, that needs to be summarized, because we have an open discussion on the fate of this template. --EncycloPetey (talk) 06:22, 24 April 2020 (UTC)

This doesn't make a huge amount of sense to me if it's presenting inaccurate info. Improving articles subject to ongoing AfDs is explicitly allowed at Wikipedia, for example, without prejudice to the outcome of the discussion, and I don't see a good reason why it shouldn't be allowed here. —Nizolan ^(talk) 20:20, 24 April 2020 (UTC)

@Nizolan: What is inaccurate about the text of the Template? Which anonymous work published in 1924 is displaying this template? --EncycloPetey (talk) 20:51, 24 April 2020 (UTC)

@EncycloPetey:, I imagine that if the template inaccurately suggests that works currently fall out of copyright before January 1, 1924, rather than 1925, it would be a disincentive to add anonymous works from 1924, no? Not surprising if there aren't any! —Nizolan ^(talk) 20:55, 24 April 2020 (UTC)

...and hence, there is nothing inaccurate in the text of the template as it stood. The status of works that bear this template has not changed, so there is neither a need to change the template nor any inaccuracy in its statement. --EncycloPetey (talk) 20:58, 24 April 2020 (UTC)

I don't think so: it is inaccurate in suggesting that the works are out of copyright because they are published before 1924, when in fact they are out of copyright because they are published before 1925. This seems fairly straightforward to me, unless there is some very pressing reason why Wikisource must not include anonymous works published in the year 1924 that I'm missing. —Nizolan ^(talk) 21:00, 24 April 2020 (UTC)

That's not how English works. Are you suggesting that being published before 1 January 1924 is insufficient reason for such works to be in public domain? --EncycloPetey (talk) 21:23, 24 April 2020 (UTC)

For works published in 1924 it sure is! —Nizolan ^(talk) 10:36, 25 April 2020 (UTC)

But we've already established that there are no such works here. You are suggested that we need to change the template to make accommodation for a need that does not exist. --EncycloPetey (talk) 16:08, 25 April 2020 (UTC)

I have changed the template (again) merely to reflect accurate information. If we are discussing renaming/replacing it, that's fine, but in the meantime it should be accurate. Since this is for all purposes an edit war, I will be following 1RR on this and encourage others to do the same. Phillipedison1891 (talk) 16:07, 24 April 2020 (UTC)

@Phillipedison1891: Following Wikipedia policies on Wikisource indicates that you are confused about policy. You have chosen to act against the advice of an admin, and against consensus procedure, and have attempted to bolster your position by citing a policy from another Wikiproject, whose policies do not apply here. There was no inaccuracy in the text of the template, despite your claim. Further, since the template no longer has the content it had when the other discussion started, any votes cast must be considered null, since the template now had content different from what it had at the start of that discussion. --EncycloPetey (talk) 20:47, 24 April 2020 (UTC)

i have reverted the non-consensus change to the template. please get a clear consensus. Slowking4 ⚔ Rama's revenge 00:11, 25 April 2020 (UTC)

@Slowking4: It would be great if we could take a break from meta-arguing about consensus and start trying to actually reach consensus. If there is some valid reason why this template should read 1 Jan 1924, contra all the other PD-US templates, I would be sincerely grateful to hear it. Otherwise this seems like a pure Joseph Hellerian nightmare of red tape and wiki-lawyering. Phillipedison1891 (talk) 03:20, 25 April 2020 (UTC)

It just comes off as very funny to me as someone without a particular stake in this. No substantive argument whatsoever has been presented for retaining the incorrect "1924", merely proceduralism—and that on a project without clear procedures! For example, the guideline Wikisource:Alternate accounts mentions the "three-revert rule" as though it's in effect, yet it's nowhere else to be found. Do Wikipedia policies apply in that case? BRD is not a stated policy here either, and if 3RR and 1RR aren't and Wikipedia procedures are irrelevant, why not just keep reverting the template until the cows come home?

From what I can tell, the only substantive policy here is Wikisource:Protection policy, which mentions protecting the page, but not sanctions for the edit-warring accounts! (Of course Wikisource:Blocking policy also exists—but unlike WP it doesn't offer any specific definition of what constitutes excessive reverting.) The rights listed at Wikisource:Adminship do not mention adminship being a veto power in an edit war (and indeed states that beyond the listed rights "administrators are no different than ordinary contributors", viz. Wikisource:Blocking policy: "all editors are considered equal"). So is the blanket ban against "choosing to act against the advice of an admin" suggested above another unwritten policy? —Nizolan ^(talk) 10:36, 25 April 2020 (UTC)

@Slowking4: If there is no consensus for stating the correct date of 1925 on this particular template, then is there also in fact no consensus for displaying it at Template:PD-old? I had been looking forward to adding a work published in 1925 next year, so that would be unfortunate if so. —Nizolan ^(talk) 10:48, 25 April 2020 (UTC)

It makes not much sense to me to set the date of the template with 1923 in its name for 1925, but the situation for 1924 works should be solved. Hopefully it will be easier if the voting in #PD-anon-1923 again is succesful. However, there is a danger that voting for this change could be cancelled if the template was changed meanwhile. I think that templates that are subject to a discussion and are undergoing some voting process should not be changed until these are closed. Opening this new discussion is very unfortunate as it enables delaying the solution. --Jan Kameníček (talk) 11:25, 25 April 2020 (UTC)

@Jan.Kamenicek: Again, I got the impression that that discussion had nothing to do with the correct PD cutoff date, and that it would be completely uncontroversial to make PD-anon-1923 harmonious with PD/1923, PD-old, and others. This without prejudice to the ultimate fate of the template in question, of course. I certainly see no reason why this should somehow "void" or "nullify" the votes over there. Phillipedison1891 (talk) 16:25, 25 April 2020 (UTC)

@Phillipedison1891: Of course it has a lot in common. You cannot take a template with a fixed year in the name and change its contents so that it refers dynamically to different years which do not correspond to its name. These changes need to be done toghether. --Jan Kameníček (talk) 16:40, 25 April 2020 (UTC)

the template makes no difference to what works get added when. delay is guaranteed when some insist on imposing hard math upon the perverse arcane copyright situation. it would be easier to create a license from scratch and mark historical the old. but people seem intent on "one right way". Slowking4 ⚔ Rama's revenge 13:14, 25 April 2020 (UTC)

Duplications of texts, USA treaties, between individual projects and within United States Statutes at Large

So it was still bothering me that the PDF source didn't quite match the scanned text for Treaty of Wanghia, and trying to discover the actual original, as a first investigation I plugged a bit of text into search here. Twisty maze of nasty duplications!

There are at least two examples of individual projects for treaties between China and USA, Treaty of Wanghia (1844) and Treaty of Tien-Tsin between the United States of America and the Empire of China (1858).

These are then duplicated within United States Statutes at Large, e.g. Index:United States Statutes at Large Volume 8.djvu (1844) (page 592), and then Index:United States Statutes at Large Volume 18 Part 2c.djvu (1858) (129)

I suppose that's not too surprising to find those treaties within USA records. But then I found duplications *within* the records, such as Index:United States Statutes at Large Volume 18 Part 2c.djvu (1844) (page 116) and Index:United States Statutes at Large Volume 12.djvu (1858) (page 1023).

And I can only think I'd find more repeat instances of near identical texts.

Is there someplace where explicit warnings are given that texts such as this could be duplicated between projects? Similarly, do the individual projects of United States Statutes at Large and friends strongly advocate, before proofreading pages/sections, to search for duplicate texts already done?

Similarly where there are copies, revised copies, new editions, etc. of things like encyclopedias or whatever, are there explicit warnings that previously proofread texts might be better starting points than a randomized new scan of an associated text?

Basically I keep encountering duplications at WS, and now hesitate to "drop in" and contribute without guarding against time wastage. This shouldn't be. Shenme (talk) 23:48, 17 April 2020 (UTC)

@Shenme: We host editions, so there is the expectation that some things will have multiple versions. If multiple authors through the years republish something, we will still host these. This is why we have {{versions}} and have good sourcing. Work with a good source that is scan-backed so you are working from some truth. Some will be interested in the variation between versions. — billinghurst sDrewth 00:05, 18 April 2020 (UTC)

[edit conflict] Wikisource does not prohibit "duplicate" texts. The instances you've given above have different dates, and are therefore different publications or editions of the same work. There should be no warning because Wikisource encourages multiple editions of texts. --EncycloPetey (talk) 00:08, 18 April 2020 (UTC)

Perhaps I was not explicit enough in noting the problems resulting from the duplication of texts. It is not that multiple editions exist. It is that the work of proofing and validating is multiplied unneeded.

The problem I'm focussing on is the duplication of effort, when each proofreader starts from a blank slate, without knowing that much work may have already been done elsewhere. I'm worried that the process as it stands now encourages, perhaps requires, wasted work.

Here is a one clause sample from each of three copies of one treaty, two unproofed and one proofed (and this sample not picked as worst case):

• "Anrronm 1II. Iu order that the people of the two countries may know and obey the publication 0 r provisions of this treaty, the United States of America agree, immedi- treaty. ately on the exchange of ratiiications, to proclaim the same, and to publish it by proclamation in the gazettes where the laws of the United . States of America are published by authority;"
• "Axricmc III. In order that the people of the two countries may know To be published and obey the provisions of this treaty, the United States of America agree, immediately on the exchange of ratitications, to proclaim the same and to publish it by proclamation in the gazettes where the laws of the United States of America are published by authority;"
• "ARTICLE III. In order that the people of the two countries may know and obey the provisions of this treaty, the United States of America agree, immediately on the exchange of ratifications, to proclaim the same, and to publish it by proclamation in the gazettes where the laws of the United States of America are published by authority;"

If you had just now proofed/validated/perfected one of these first two, and then discovered the third already existed, what would you think of this whole process?

It is not hard to justify hosting multiple editions/versions of works. You mistake my misgivings if you thought I was criticizing that.

It *should* be hard to justify wasting peoples' time. And not taking advantage of prior work from years ago is another type of waste.

I am asking for background to be available to general newcomers, and especially to newcomers to projects where duplication is endemic/expected, warning them that it is possible that texts new-to-them may have close correspondences elsewhere here, and that those other texts may be better starting points for proofreading than new randomized scans, e.g. - Anrronm - Axricmc - ratiiications - ratitications.

The currency of most value here is time, contributor time. If through process failure you waste that, it is a tragedy. And a likely reason for attrition. Shenme (talk) 03:19, 18 April 2020 (UTC)

@Shenme: I generally agree with you on this, on general sentiment if not necessarily on all the details. I've observed similar in non-scan-backed texts sitting around in random places in mainspace, but to a much lesser degree, and much more rarely yet with scan-backed works. Which makes me suspect that the problem you're seeing is particularly endemic to the Statutes at Large and its related or overlapping works. It may be that that particular area has additional need of guidance and coordination that would not necessarily be appropriate as general guidance for all works on Wikisource. Do you have any ideas on how we might do that in practice? A Wikiproject with local guidelines would seem one obvious possibility. Perhaps supplemented with links to the Wikiproject from some of the general guidance. But at the same time, we generally do not have so many contributors working in any given area that these things can't be figured out by talking to one another.

PS. Keep in mind that cut&paste or cross-work-transclusion short-circuits the normal transcription process on Wikisource: it's by design that every edition of a text should be proofread and then validated against the scan of the edition it was published in. Reusing proofread or validated text from a different edition skips this quality control mechanism, relying instead on a much simpler assessment by a single contributor that the texts are probably identical. That's probably good enough in practice most of the time, but worth keeping in mind all the same. --Xover (talk) 08:07, 18 April 2020 (UTC)

"The currency of most value here is time, contributor time. If through process failure you waste that, it is a tragedy. And a likely reason for attrition." i agree, however, volunteer time is treated at wikimedia as an infinite resource: it is held cheap, because we can't put a price on it. more attrition is done by biting newbies, hounding veterans, and the creaky UX, than frustration at duplicated work. editors are constantly burning out, or taking wikibreaks for self-care. the fact that statutes at large is a compendium of all law and treaties, does not waste time of transcribing elsewhere: the works will get completed elsewhere years or decades before. we are doing only a tiny fraction of texts, and there are many transcription projects. but we are part of an ecosystem of digital humanities, and lessons learned can help find-ability, verify-ability, and scholarship across the internet.Slowking4 ⚔ Rama's revenge 13:38, 26 April 2020 (UTC)

George Orwell out of copyright in 2021

Hi all, I wondered if any thought had been given to George Orwell's main works going out of copyright at the end of this year. These are very popular works that would benefit from being digitised and released for everyone to read quickly. So two considerations: (1) is this something Wikisource would want to do; and (2) who else, eg Project Gutenberg, might want to help or do something similar (we definitely don’t want to duplicate I would suggest)?

I think this applies only to countries where works enter the public domain 70 years after the author’s death, but English Wikisource follows US copyright laws, and so we can generally accept only Orwell’s works published 95 years ago, although there are also some exceptions for works published later described at Help:Public domain. --Jan Kameníček (talk) 20:01, 13 April 2020 (UTC)

The English Wikisource works on US law, as does Project Gutenberg, and in US law George Orwell's work will generally have 95 years of copyright from publication. His first major works will start leaving copyright in 1933 + 95 years + 1, or 2029, in the US.--Prosfilaes (talk) 20:10, 13 April 2020 (UTC)

Ugh. Thanks, I’d forgotten how complex term is in the USA. I'm so used to the US copyright term being shorter and clearer. Do you think Wikimedia Foundation would consider hosting a separate EU-based server to digitise works like these? It has various national chapters, and it is a problem that will run some decades. If not then *somebody* should and I guess may do. JimKillock (talk) 07:15, 14 April 2020 (UTC)

Some non-English wikisources follow only their national copyright laws ignoring the US laws (although technically they probably should not as the servers are located in the US). I am not sure whether the problem could be solved by locating part of servers in Europe. It is also possible that then it could be demanded that US citizens should not have access to the contents of European servers and vice versa… (similarly as Google Books has to distinguish readers based on their location). WM Foundation should probably be more active in influencing copyright laws in the key countries instead. --Jan Kameníček (talk) 08:18, 14 April 2020 (UTC)

On the policy point, perhaps: but European copyright terms aren't going to change any time soon; more likely is that US and EU laws harmonise over time as is already planned (harmonisation at life plus 70 years).

On the point about denying access in different countries; this could be demanded of wikimedia or archive.org now I am sure, if they had non-US legal presence (which is complicated if you are a local WMF chapter). It would be interesting to know if availability issues had ever got close to court action.

It might be that Wikimedia doesn't want to get into restricting content by judisdiction (even when this means more availability overall) as having the power to restrict would require them to deploy it more widely, which would be very fiddly and incomvenient indeed.

As for whether the problems could be 'solved'; the problem from my perspective is to transcribe and publish Orwell and other works when these works are public domain in the EU. So from that perspective, an EU hosted service solve my problem :) – the second issue is whether this effort can be done within an existing project or if it would need to be a new project. It’s always better to avoid reinventing the wheel! But perhaps this would just raise too many complicated questions. JimKillock (talk) 12:19, 14 April 2020 (UTC)

@Jan.Kamenicek: I think what you're describing is Project Gutenberg Australia, and they already have most of Orwell's works transcribed. Kaldari (talk) 18:02, 14 April 2020 (UTC)

Oops, meant to ping JimKillock, not Jan.Kamenicek :) Kaldari (talk) 18:03, 14 April 2020 (UTC)

Thanks very much :) I didn’t know about that project or the position with a few years of shorter Australian terms. JimKillock (talk) 18:20, 14 April 2020 (UTC)

you could also search for renewals,[15] and [16] and [17] and upload to commons at pma 70. here is a scan [18] the URAA gatekeepers will be upset, but that is icing. Slowking4 ⚔ Rama's revenge 21:50, 14 April 2020 (UTC)

George Orwell's book renewals are fairly extensive; it's possible some of his minor novels may have lost copyright in the US, but he was British and it seems that they were only originally published in the UK, so it's unlikely they weren't restored by the URAA. Like Anne Frank's estate, George Orwell's will be quick to issue a takedown notice on uploaded copies, at least of major works.

With my admin's hat on, I'm going to request that you don't state on Wiki that annoying your fellow Wikimedians is "icing". It does not contribute to collegial cooperating on Wikimedia projects.--Prosfilaes (talk) 12:41, 15 April 2020 (UTC)

when the URAA deletionists start following the wmf legal advice and consensus, then it will be collegial, i.e. [19]; statements here have no bearing on the toxic culture at commons, i.e. [20]. your selective speech code is telling. [21] Slowking4 ⚔ Rama's revenge 22:19, 27 April 2020 (UTC)

Multiple images problem on author pages

There’s an issue, which I believe has been known to a number of people for quite a while, where the Author page templates fail to correctly display an image if there are several to choose from on Wikidata -- it will return the best-ranked image but fail if there are several of those. This week the problem became acute due to importation of a whole lot more images to Wikidata. I asked for a query to check the scope of the problem, and it turns out there are 530 affected author pages today, including such folks as Thomas Jefferson and Nathaniel Hawthorne. Time to fix the template I guess? There’s a suggestion for one way of doing so in that Wikidata discussion I linked.

P.S. It might be a good idea to make sure that images set to "deprecated" rank are not displayed, while you’re at it. Levana Taylor (talk) 12:24, 26 April 2020 (UTC)

I have noticed the same problem with several author pages too. As the images are being added to Wikidata robotically (e. g. [22]) we cannot expect that somebody will go through and choose the best of them to give them preferred ranks. So we should solve it somehow here (I would suggest that with two pictures of the same rank the one which was at the Wikidata earlier should be priotirized as there is a higher probability that somebody checked it). --Jan Kameníček (talk) 12:43, 26 April 2020 (UTC)

They are currently tracked at Category:Pages with missing files. You cannot make any assumption about quality. Sometimes the latter file is added because it is better quality. I still feel that fixing them is the best option. It would neat if there was an easy tool to do a quick comparison and just apply a quick selection. I truly hate some of their bot operations at times. They see more interested in populating rather than quality additions, irrespective of the issues that they create. — billinghurst sDrewth 13:01, 26 April 2020 (UTC)

i could expect it. but it would require someone to edit wikidata. the bot haters will increasingly hound the bot operators on wikidata, as they have done on english, so just wait a while.Slowking4 ⚔ Rama's revenge 13:27, 27 April 2020 (UTC)

I see that the author header template doesn’t currently allow specifying that no image should be used. That might be useful, what do you think? I mean for cases where there isn’t an actual portrait of the person in existence. For people like saints, how do you decide which of the imaginary portraits to go with? Probably better to use none. Levana Taylor (talk) 18:34, 27 April 2020 (UTC)

Not always for saints. Some saints have "standard" portraits. But the problem with the bots is almost always an import of images from the Catalan Wikipedia. So the best solution is to go over there and replace whatever image they have with the preferred one so that their bot won't re-create the problem. --EncycloPetey (talk) 19:00, 27 April 2020 (UTC)

Technical maintenance planned

A maintenance operation will be performed on Thursday 30th April at 05:00 AM UTC.

It impacts all wikis and is supposed to last a few minutes.

During this time, new translations may fail, and Notifications may not be delivered. For more details about the operation and on all impacted services, please check on Phabricator.

A banner will be displayed 30 minutes before the operation.

Please help making your community aware of this maintenance operation.

Trizek (WMF), 18:04, 27 April 2020 (UTC)

Index:Arthur Cotton - The Madras Famine - 1898.djvu

The pages need to be moved to accommodate for the corrected file. TE(æ)A,ea. (talk) 23:28, 17 April 2020 (UTC).

The Chinese Fairy Book missing Frontispiece.

I've located an alternative copy of it from [23] and uploaded it to commons as [24]

Would someone have time to add this file into the book please?

The pattern seems to be a blank page followed by the image, so I suspect it should be inserted after the current page 4 [25]

Thanks Sp1nd01 (talk) 07:58, 30 April 2020 (UTC)

GFDL with invariant sections

This is a question for old timers, or anyone with extensive license experience: Has there ever been discussion of a case at Wikisource regarding a book licensed under the GFDL with "invariant sections"? I.e. where the book in question can be used under "attribution share-alike" terms but must include certain limited text pertaining to the publisher?

In some ways it is like an extended, defined "attribution". Wikipedia migrated away from the GFDL precisely because of concerns about "invariant sections", among which were the concern that a requirement to include such text would weigh down encyclopedia articles. But in a book, to include required publication data is somewhat different. If anyone knows about this issue, or could refer me to someone who does, I would be grateful.Dovi (talk) 16:57, 29 April 2020 (UTC)

It's not really free; the Debian Free Software Guidelines exclude it, because it includes significant non-free content. It's not just required publication data; GNU examples often have a political essay or something.--Prosfilaes (talk) 01:11, 30 April 2020 (UTC)

commons allowed the GFDL 1.2 only until recently, so it is theoretically possible. using it would be controversial [26]. [27], [28]. it is of historical interest, not used elsewhere, only the free software fanatics who hung around wikimedia used it.Slowking4 ⚔ Rama's revenge 01:03, 1 May 2020 (UTC)

@Slowking4: Quick straw polling: is it your opinion that the GFDL should not be used as a license here on enWS (except as part of a dual-licensed work)?

@Everyone: Anybody else thinking along those lines?

I'm asking because 1) we have some messes left over after the Great Relicensing when enWS didn't complete its cleanup, and 2) I personally find the GFDL problematic when used here. So I'm sort of polling to see if anybody else thinks this is something worth the effort to clean up? --Xover (talk) 06:53, 1 May 2020 (UTC)

I believe that the GFDL without invariant sections (as I believe has always been required on Wikimedia) to be fine. It's just the GFDL with invariant sections that's non-free.--Prosfilaes (talk) 12:43, 1 May 2020 (UTC)

i would put a maintenance category on it, and we can clean the mess up. future graduate students will want to know about all those manifestos, of the weird free fanatics. we need to maintain all the intellectual cul-de-sacs. the fanatics would strenuously disagree that their tl;dr was "non-free": that is a coinage to label for deletion things they do not like.[29] Slowking4 ⚔ Rama's revenge 22:32, 1 May 2020 (UTC)

Thanks to all of you for your replies. :-) If anyone has links to further clarifications or people to contact they would be appreciated. Dovi (talk) 14:16, 1 May 2020 (UTC)

My inclination is that it should not be allowed, under section 7(c) of the Terms of Use. With or without invariant sections. Of course, this discussion might be a little easier with a few examples of the content we're talking about. -Pete (talk) 01:35, 5 May 2020 (UTC)

Tech News: 2020-17

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

Tech News

• The next issue of Tech News will be sent out on 4 May 2020.

Recent changes

• The small wiki toolkits is to help smaller wikis that need technical skills. They can learn and share technical skills. [30]
• Over-qualified CSS selectors in Wikimedia skins have been removed. div#content is now .mw-body. div.portal is now .portal. div#footer is now #footer. This is so the skins can use HTML5 elements. If your gadgets or user styles used them you will have to update them. [31]

Changes later this week

• There is no new MediaWiki version this week.

Future changes

• Some things on the wikis might look weird or not work in Internet Explorer 8 in the future. Internet Explorer 8 was replaced in 2011. [32]
• The font in the diffs will change. [33]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 28 April next week. It will be on non-Wikipedia wikis and some Wikipedias from 29 April next week. It will be on all wikis from 30 April next week (calendar).

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

18:44, 20 April 2020 (UTC)

Files affected by CSS changes

The change announced in this Tech News (Over-qualified CSS selectors in Wikimedia skins have been removed. affects the following files on enWS. Each change will have to be investigated individually, but as a rule of thumb, CSS files that use something like div.classname can be changed to simply omit the element name: .classname. Other changes will be slightly more involved, for example as given in the news item: div#content must be changed to .mw-body.

• User:Consulnico/vector.css (pinging Consulnico)
• User:Dagon1846/common.css (pinging Dagon1846)
• User:VNNS/vector.css (pinging VNNS)
• User:Arlen22/vector.css (pinging Arlen22)
• User:Laura1822/common.css (pinging Laura1822)
• User:Gary123/common.css (pinging Gary123)
• User:JoeAuH2O/common.css (pinging JoeAuH2O)
• User:Alex_brollo_bis/common.css (pinging Alex_brollo_bis)
• User:Natuur12/vector.css (pinging Natuur12)
• User:George_Orwell_III/vector.css (pinging George_Orwell_III)
• User:Atreides7/vector.css (pinging Atreides7)
• User:Vorziblix/vector.css (pinging Vorziblix)
• User:Timothydague/vector.css (pinging Timothydague)
• User:Jwillia3/vector.css (pinging Jwillia3)
• User:Robert.Baruch/vector.css (pinging Robert.Baruch)
• User:Hesperian/common.css (pinging Hesperian)
• User:OwenBlacker/common.css (pinging OwenBlacker)
• User:Inductiveload/quick_access.js (pinging Inductiveload)
• MediaWiki:Gadget-Site.css (Badly over-specified and likely to break with future changes, but existing fixes appear to be sufficient for the announced change.)
• MediaWiki:Gadget-CollapsibleNav.css (Badly over-specified and likely to break with future changes, but existing fixes appear to be sufficient for the announced change.)
• MediaWiki:Common.js (Badly over-specified and likely to break with future changes, but existing fixes appear to be sufficient for the announced change.)

None of the needed changes are likely to cause catastrophic failures, but some may be annoyances and it is generally a good idea to implement the necessary changes sooner rather than later. If anybody needs technical assistance then post here so one of our more technical contributors can help out (or feel free to ping me directly, I'm a bit busy IRL but happy to help where I can). --Xover (talk) 06:22, 12 May 2020 (UTC)

Thanks for pinging me. Am I right in understanding that what you're saying is that those identifiers have changed (or are about to) in the HTML, so I should update my user stylesheet to reflect the change? I know my user CSS has some overqualified properties to ensure they take effect (and some !importants too 😞), so hopefully some of those can be made less shoddy? — OwenBlacker (Talk) 07:41, 12 May 2020 (UTC)

@OwenBlacker: Yup. ID selectors (#) almost never need the element name, and classes (.) rarely do. Since the specific element used for those components may change, specifying the element in the selector makes them fragile. The Tech News item is a warning that some of those elements may now change going forward. In addition, it lists the following specific changes to classes and IDs: div#content is now .mw-body. div.portal is now .portal. div#footer is now #footer. The tracker for these changes is phab:T248137. --Xover (talk) 15:02, 12 May 2020 (UTC)

US Supreme Court determination re copyright and government edicts

Nemo bis flagged a recent news report of via Wikisource-L

• Georgia Copyright Loss at High Court Could Jolt Many States (2)

This definitely gives us broader scope and clarity for some of our copyright discussions, and especially for our application of {{PD-GovEdict}}. Thanks to Nemo bis for that email. — billinghurst sDrewth

[Pinging Prosfilaes if you haven't seen this already.]

Wow! I find myself hard pressed to avoid using profanity as an intensifier in describing the effects of this ruling!

What Roberts and the USSC majority does in this ruling is to turn the "edict of government" doctrine pretty much entirely on its head! The test used to be a "force of law" test: in order to qualify as an edict of government the work itself had to carry some measure of force of law in some manner. This ruling completely changes the test to instead focus on the author of the work: if the author of the work has the authority to define or interpret the law, then the creator of the work cannot be an "author" under the Copyright Act. In practical terms, this means that both judges and legislators, both federal and state-level, when acting in their official roles, cannot hold copyright for works they produce irrespective of the nature of the material!

And it even goes further: this applies to a committee established by the legislature even though it is notionally external to the legislature (includes non-legislators in its makeup), and, yet further, even to a private commercial entity that produces work-for-hire material (ultimately) on behalf of a judge or legislator. Roberts underlines that for these works the "author" for copyright purposes is actually ultimately "the people", and explicitly names this "public domain".

Summing this up in a layman's rule of thumb: we now have the same sort of exception from copyright as {{PD-USGov}} for works by judges and legislators at both federal and state level. And, in terms of US copyright, this principle will apply equally to foreign works (the edicts of government doctrine always has; this ruling does not alter that). --Xover (talk) 09:47, 28 April 2020 (UTC)

Wow. This is going to change some things! I just hope the documents are available, as opposed to just not copyrighted --DannyS712 (talk) 10:16, 28 April 2020 (UTC)

 Comment We are going to need to head back to WS:CV and look at the state works that we have deleted, and works by state members. We will need to apply our brains particularly to the responses to the State of the Union addresses, and re-evaluate the US Democratic and Republican national conventions. I would suggest that we are going to also look at our documentation at template:PD-EdictGov/doc, and I am presuming that this will only apply to US state legislators, not foreign legislators, or do we think that for US copyright purposes it is more universal. — billinghurst sDrewth — billinghurst sDrewth 14:29, 28 April 2020 (UTC)

Does this ruling (and I have a view this will go to appeals) change the status of papers submitted in a case? ShakespeareFan00 (talk) 14:38, 28 April 2020 (UTC)

@ShakespeareFan00: This does not affect submissions by parties in legal cases: the parties and their counsel do not define or interpret the law (they just argue it). And the Supreme Court is the court of last appeal. For the states to change this they will have to change the actual law (the Copyright Act). --Xover (talk) 16:19, 28 April 2020 (UTC)

@Billinghurst: I agree we will need to reassess quite a few previous discussions, and the docs (and the template text) definitely need updating. Note that it is by no means a given that this will change the outcome of those discussions (the test is legislators in their role as legislators, so for most actual works we've looked that I can recall the result will be the same); we just need to review them to make sure the changed legal test doesn't affect them.

This ruling only affects US copyright, but that was true previously too. The "edict of government" doctrine has (for our purposes) always been a US issue: the US copyright office will refuse to register such works. However, it has always also applied to a foreign work's US copyright status. If a foreign work meets the new "edict of government" test, it will be ineligible for copyright protection in the US. What it does not affect is the copyright status in its country of origin: if the country of origin has a PD-USGov or its own "edict of government" exception it will be PD in that country, and if they do not then it will be in copyright there. In other words, this change is a big deal for enWS but far less so for Commons (on Commons, only US works will actually be affected by this). --Xover (talk) 16:19, 28 April 2020 (UTC)

not too surprised. the US judges have a tendency to make it up, when confronted with egregious behavior. (see also fair use) for all those copyright maximalists, take note, a literal parsing of the code may not stand up in court. and might not be the right method. and have fun on your backlog. but on the other hand, give it time, the MPAA / author's guild will be talking to their Federalist friends, and they will have another go at this political court. (public domain anywhere is a threat to copyright everywhere.)Slowking4 ⚔ Rama's revenge 23:07, 28 April 2020 (UTC)

The Electronic Frontier Foundation's blog post about this is worth reading (and FWIW is CC BY). This is an issue we dealt with here in my home state of Oregon back in 2008. Nice to have the feds pushing in the right direction on this one. -Pete (talk) 20:01, 5 May 2020 (UTC)

I have drafted an updated Template:PD-EdictGov; take a look. One issue is whether we still even want to cite to the Copyright Office compendium, when the Supreme Court is the controlling authority. Phillipedison1891 (talk) 19:20, 18 May 2020 (UTC)

The United Nations Treaty Series should have uniform naming of files

We use File:UNTS 1.pdf, File:United Nations Treaties and international agreements registered - Volume 221 (13 November 1955 - 30 November 1955).pdf, File:UN Treaty Series - vol 935.pdf, etc. here with very inconsistent naming. Please also come to commons:Commons:Village pump#The United Nations Treaty Series should have uniform naming of files to discuss on uniform naming. How will renaming impact our uses of these files?--Jusjih (talk) 03:17, 21 April 2020 (UTC)

@Jusjih: While it is nice and better to have a uniform naming pattern, it has never been a requirement for files. We can manage it through transclusion. If you wish to organise it for future files, or files that are yet to be transcribed, I doubt that we have an issue. If you are saying that we should be renaming files that have been transcribed, I don't think that is a good idea, and I hope that you tell that to Commons. — billinghurst sDrewth 07:58, 24 April 2020 (UTC)

All three files are hosted on Commons, so I wonder how renaming there will impact our transclusion here. As Commons gets growing consensus for "UN Treaty Series - vol 935.pdf", I have uploaded UN Treaty Series - vol 2.pdf through UN Treaty Series - vol 11.pdf.--Jusjih (talk) 03:59, 26 April 2020 (UTC)

My talk at Commons has been archived at Commons:Village_pump/Archive/2020/04#The_United_Nations_Treaty_Series_should_have_uniform_naming_of_files and I have asked any disinterested user to carefully consider if renaming File:UNTS 1.pdf requires substantial efforts.--Jusjih (talk) 05:03, 4 May 2020 (UTC)

Someone else renamed File:UNTS 1.pdf to File:UN Treaty Series - vol 1.pdf on Commons without affecting Index:UNTS 1.pdf, Page:UNTS 1.pdf/1, etc. here. It looks like a good news as renamed Commons files keep the redirects.--Jusjih (talk) 03:36, 5 May 2020 (UTC)

• Someone will have to track down all of the partial files, as well: File:United Nations Treaties and international agreements registered - Volume 221 (13 November 1955 - 30 November 1955).pdf was created to replace File:Agreement concerning migration of Filipino labor for employment in British North Borneo.pdf, yet we have Overseas Service (Malaysia) Agreement, 1964 (from File:Agreement concerning certain overseas officers serving in Sabah and Sarawak 7 May 1965.pdf), from another volume. Here’s what I’ve found:
• Overseas Service (Malaysia) Agreement, 1964 (from File:Agreement concerning certain overseas officers serving in Sabah and Sarawak 7 May 1965.pdf)
• Exchange of notes constituting an agreement relating to the implementation of the Manila Accord of 31 July 1963 (from File:Implementation of the Manila Accord.djvu)
• Vienna Convention on the Law of Treaties between States and International Organizations or Between International Organizations (1986) (from [[:File:Vienna Convention on the Law of Treaties between States and International Organizations or Between International Organizations (1986).djvu) (possibly, as the file is from 2005)
• Vienna Convention on Succession of States in respect of Treaties (from File:States succession in respect of treaties.pdf)
• Vienna Convention on the Law of Treaties (not from File:Vienna Convention on the Law of Treaties (1969).djvu, although the file claims such)
• United Nations Treaty Registered No. I-8029, Manila Accord (31 July 1963), Manila Declaration (3 August 1963), and Joint Statement by the Philippines, the Federation of Malaya and Indonesia (5 August 1963) (from File:Manila Accord (31 July 1963).djvu)
• United Nations Treaty Registered No. I-8206 (from File:Agreement relating to the separation of Singapore from Malaysia as an independent and sovereign State.djvu)
• United Nations Convention on the Law of the Sea (not from File:Unclos e.djvu, although the file claims such)
• Exchange of notes constituting an agreement relating to the implementation of the Manila Accord of 31 July 1963 (from File:Implementation of the Manila Accord.djvu)
• File:Agreement on External Defence and Mutual Assistance between the Government of the United Kingdom and the Government of the Federation of Malaya.djvu
• Agreement relating to Malaysia between United Kingdom of Great Britain and Northern Ireland, Federation of Malaya, North Borneo, Sarawak and Singapore (from File:Agreement relating to Malaysia (1963).djvu)
• Agreement relating to Malaysia between United Kingdom of Great Britain and Northern Ireland, Federation of Malaya, North Borneo, Sarawak and Singapore/supplementary agreement (from File:V750 2.djvu) (not from File:Supplementary Agreement relating to Malaysia on 11 September 1963.pdf, although the file claims such)
• Agreement (with annexes) concerning migration of Filipino labor for employment in British North Borneo. Signed at Manila, on 29 August 1955 (from File:United Nations Treaties and international agreements registered - Volume 221 (13 November 1955 - 30 November 1955).pdf, although not indicated)

I believe that there may be some more such treaties in Category:PD-UN. TE(æ)A,ea. (talk) 11:36, 9 May 2020 (UTC).

Most of your cited files are partial pages of certain volumes of the United Nations Treaty Series. See also #Duplications of texts, USA treaties, between individual projects and within United States Statutes at Large.--Jusjih (talk) 18:50, 17 May 2020 (UTC)

Billinghurst and I have reached a consensus on Commons talk to grandfather File:UNTS 1.pdf and File:United Nations Treaties and international agreements registered - Volume 221 (13 November 1955 - 30 November 1955).pdf to avoid major impact from renaming. All others are to be named like File:UN Treaty Series - vol 935.pdf.--Jusjih (talk) 03:37, 26 May 2020 (UTC)