Wikisource:Scriptorium/Archives/2022-07
![]() | Please do not post any new comments on this page.
This is a discussion archive first created in , although the comments contained were likely posted before and after this date. See current discussion or the archives index. |
Four pages of this scan have sticky notes stuck on them and can’t be proofread as the text is illegible; all four are marked Problematic. Can they be replaced by pages from another file? There is another scan of this very edition here but it entirely black-and-white; I don’t think that should matter since it is text only but if it does, I’ll try to find another scan on IA.
The pages are listed here:
- Page:Addams - 1902 - Democracy and Social Ethics.djvu/200
- Page:Addams - 1902 - Democracy and Social Ethics.djvu/202
- Page:Addams - 1902 - Democracy and Social Ethics.djvu/215
- Page:Addams - 1902 - Democracy and Social Ethics.djvu/265
Ciridae (talk) 11:10, 20 July 2022 (UTC)
- Alternative scan, here [1]. Languageseeker (talk) 15:27, 20 July 2022 (UTC)
- The version linked by Ciridae is a 1905 edition. Languageseeker (talk) 15:57, 20 July 2022 (UTC)
- @Ciridae done. Mpaa (talk) 16:14, 20 July 2022 (UTC)
- @Mpaa, @Languageseeker: Thanks! Ciridae (talk) 03:54, 21 July 2022 (UTC)
- This section was archived on a request by: Ciridae (talk) 03:54, 21 July 2022 (UTC)
- This section was archived on a request by: Mpaa (talk) 13:56, 25 July 2022 (UTC)
Two pages are missing: Pages 101 and 102. Currently, page 100 corresponds to Page:The Country of Pointed Firs - Jewett - 1896.djvu/114 and page 103 corresponds to Page:The Country of Pointed Firs - Jewett - 1896.djvu/115.--Tylopous (talk) 09:42, 12 June 2022 (UTC)
- Pages 101 and 102 can be found here: https://archive.org/details/countryofpointed00jewerich/page/100/ MarkLSteadman (talk) 14:01, 12 June 2022 (UTC)
- Thanks for this information. I'm still grateful for further assistance, because I've never added pages to djvu files.--Tylopous (talk) 16:40, 12 June 2022 (UTC)
- Done. Mpaa (talk) 20:41, 12 June 2022 (UTC)
- Thanks for the quick help.--Tylopous (talk) 05:41, 13 June 2022 (UTC)
- @Mpaa: On closer inspection, now pages 103 and 104 of the book are twice contained in the djvu file. The four pages
- Page:The Country of Pointed Firs - Jewett - 1896.djvu/115 to Page:The Country of Pointed Firs - Jewett - 1896.djvu/118 now contain 103,104,103,104 instead of 101,102,103,104. Sorry that I didn't notice this earlier.--Tylopous (talk) 15:53, 13 June 2022 (UTC)
- @Tylopous I think you are seeing cached pages, try to purge the pages. See e.g. page 115 in the djvu file. Mpaa (talk) 21:35, 13 June 2022 (UTC)
- @Mpaa: Now it's clear. Thank you very much again.--Tylopous (talk) 05:19, 14 June 2022 (UTC)
- @Tylopous I think you are seeing cached pages, try to purge the pages. See e.g. page 115 in the djvu file. Mpaa (talk) 21:35, 13 June 2022 (UTC)
- Thanks for the quick help.--Tylopous (talk) 05:41, 13 June 2022 (UTC)
- Done. Mpaa (talk) 20:41, 12 June 2022 (UTC)
- Thanks for this information. I'm still grateful for further assistance, because I've never added pages to djvu files.--Tylopous (talk) 16:40, 12 June 2022 (UTC)
- This section was archived on a request by: Mpaa (talk) 13:57, 25 July 2022 (UTC)
FYI the index file is at Index:Her Benny - Silas K Hocking.djvu with proof read pages while the commons backing file is at "Her Benny - Silas K Hocking (Warne, 1890).djvu" which is breaking the internal links as things pint towards the nonexistent Index:Her Benny - Silas K Hocking (Warne, 1890).djvu. MarkLSteadman (talk) 07:21, 23 June 2022 (UTC)
- done. Mpaa (talk) 18:30, 24 June 2022 (UTC)
June Monthly Challenge
During the June Monthly Challenge, 5155 pages were processed, about 1000 less than in May. Nevertheless, this is more than 250% of the target of 2000 pages per month and thus it is a very good result. Interestingly, also last year's June challenge processed about 1000 pages less than in May 2021, so this may be a first indication of seasonal patterns in activity levels in the challenge.
Fewer indexes were fully proofread or validated than in previous months. But, true to the spirit of the challenge, the completed works covered a wide range of subject matters and original creation dates: From a translation of Homer's Iliad to a document pertaining to U.S. law of the 20th century; from Sherlock Holmes stories to a work discussing etiquette.
To highlight one work, Volume 5 of the complete works of H. G. Wells was proofread in June, an important step forward in the ambitious project of transcribing all 28 volumes of the series, of which some only entered the public domain this year. The completion of volume 5 was a true community effort. Thanks to everyone involved!
In July, contributors will find the opportunity to take up again the work on some important works that were already present in the challenge once, but didn't reach completion. Among others, these are:
There are lots of fascinating books to discover. Come and join the challenge!--Tylopous (talk) 08:14, 1 July 2022 (UTC)
Proposal for a new layout
Can we have a new layout where the text can encompass the full width of the page (without useless whitespace at the sides) and is also justified like a regular book? I’d like to have this for works that don’t have sidenotes especially; Layout 1 is ugly, and the other ones are rather sub-optimal for the purpose given the wasted space and unnecessary scrolling required. Basically Layout 1 but with justified text. Ciridae (talk) 06:48, 1 July 2022 (UTC)
Two pages need to be removed from this scan/file. The first page is a bad scan of an image and the second is the blank page that follows it. Both are unnecessary as the proper scan of the image follows immediately after. The pages are listed below:
- Page:Bismarck and the foundation of the German empire (IA bismarckfoundati00head).pdf/533
- Page:Bismarck and the foundation of the German empire (IA bismarckfoundati00head).pdf/534
Ciridae (talk) 12:14, 25 July 2022 (UTC)
- Sigh. I seem to have broken the file entirely while attempting to fix it. I'd be much obliged if someone can fix the mess. Ciridae (talk) 09:44, 27 July 2022 (UTC)
- Done --Jan Kameníček (talk) 15:53, 27 July 2022 (UTC)
- @Jan.Kamenicek: Thanks a lot! Ciridae (talk) 06:05, 28 July 2022 (UTC)
- This section was archived on a request by: Ciridae (talk) 06:05, 28 July 2022 (UTC)
- @Jan.Kamenicek: Thanks a lot! Ciridae (talk) 06:05, 28 July 2022 (UTC)
- Done --Jan Kameníček (talk) 15:53, 27 July 2022 (UTC)
Large names on legislative texts
For some reason every report and legislative text in the 19th century had a massive name.
And I guess it's preferable to work with the actual name, but it's just so unwieldy to work with on pages for transcription. Is it at all frowned upon to just change this to a shorter name like "Statutes of New Zealand - 1841 to 1853" Or is it preferred to keep the original name? Supertrinko (talk) 05:11, 1 July 2022 (UTC)
- As long as the mainspace title for the work is a correct one, the only rules about the title of the Index: are that it's unique and matches the File: name. It's preferable that the title has meaning, but we have titles in the form "CU964561". I frequently use short file names when uploading, and would have used "Ordinances of NZ 1841-53" for this example. Beeswaxcandle (talk) 05:19, 1 July 2022 (UTC)
- Thanks! I think in this instance, the long name provides no value, so I'd be inclined to do it in the format you suggested. I'll look at changing it since I haven't done much with it at this stage. Supertrinko (talk) 05:21, 1 July 2022 (UTC)
Missing End tags : center
https://public.paws.wmcloud.org/User:ShakespeareFan00/obs_center
It would be nice if these could be cleared soon. The thinking behind concentrating on these, (and the related mismatched font,strike and tt tags) is so that there are NO mismatched version of these obselete tags in Content pages. The automated approach to conversion that Wikiveristy uses to resolve 'obsolete' tags can than reasonably be applied. ShakespeareFan00 (talk) 17:41, 1 July 2022 (UTC)
Lots of blank pages
Around half of the pages (every other pair, in this case, but I've seen books where it was every alternate page) in an old book I'm transcribing are blank. Is there a tool that will let me select them all from the pagelist, and mark them as such? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:46, 1 July 2022 (UTC)
- It is a task a bot can run. Mpaa (talk) 20:52, 2 July 2022 (UTC)
- Thanks. That will be a good fallback, but I don't have the sills to run such a bot, and am looking for a tool that I - and others like me - can use. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:44, 3 July 2022 (UTC)
- No end-user / user friendly tool that I'm aware of, sorry. But if you provide a list of the pages it should be fairly easy for a bot operator to do (I'm assuming, I've never done that, but I know Mpaa has handled many similar requests here). Large numbers of blank pages is not a very prevalent problem, so far as I can tell, so it's probably more efficient to just handle these cases as one-offs (vs. making an end-user tool to do it). Xover (talk) 12:49, 3 July 2022 (UTC)
- Thanks. That will be a good fallback, but I don't have the sills to run such a bot, and am looking for a tool that I - and others like me - can use. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:44, 3 July 2022 (UTC)
Where is the A in the {{di}} template?
I took a screenshot, because, this is difficult for me to believe. There is no "A" in the template, yet, it is displaying as though there is one. Page:Historical essay on the art of bookbinding (IA 0130ARTO).pdf/7
How can this be?--RaboKarbakian (talk) 15:41, 3 July 2022 (UTC)
- @RaboKarbakian: Looking at the code of the template, the {{di}}'s first parameter supplies the letter to be displayed, and if none is provided, it supplies "A" by default.--Jan Kameníček (talk) 18:16, 3 July 2022 (UTC)
- If you give it nothing, it punishes you by giving you the Scarlet Letter. PseudoSkull (talk) 18:18, 3 July 2022 (UTC)
- Jan Kameníček OH doh! I was so miffed by this that I did not even think to read the template source, the idea of a default initial did not occur to me. Thank you, nice to see your name 'round here again, and also, sorry (and embarrassed) to bother.--RaboKarbakian (talk) 18:22, 3 July 2022 (UTC)
- PseudoSkull Poor Hester!--RaboKarbakian (talk) 18:24, 3 July 2022 (UTC)
- Jan Kameníček OH doh! I was so miffed by this that I did not even think to read the template source, the idea of a default initial did not occur to me. Thank you, nice to see your name 'round here again, and also, sorry (and embarrassed) to bother.--RaboKarbakian (talk) 18:22, 3 July 2022 (UTC)
- If you give it nothing, it punishes you by giving you the Scarlet Letter. PseudoSkull (talk) 18:18, 3 July 2022 (UTC)
Results of Wiki Loves Folklore 2022 is out!
Please help translate to your language
Hi, Greetings
The winners for Wiki Loves Folklore 2022 is announced!
We are happy to share with you winning images for this year's edition. This year saw over 8,584 images represented on commons in over 92 countries. Kindly see images here
Our profound gratitude to all the people who participated and organized local contests and photo walks for this project.
We hope to have you contribute to the campaign next year.
Thank you,
Wiki Loves Folklore International Team
--MediaWiki message delivery (talk) 16:12, 4 July 2022 (UTC)
Tech News: 2022-27
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Changes later this week
- The new version of MediaWiki will be on test wikis and MediaWiki.org from 5 July. It will be on non-Wikipedia wikis and some Wikipedias from 6 July. It will be on all wikis from 7 July (calendar).
- Some wikis will be in read-only for a few minutes because of a switch of their main database. It will be performed on 5 July at 07:00 UTC (targeted wikis) and on 7 July at 7:00 UTC (targeted wikis).
- The Beta Feature for DiscussionTools will be updated throughout July. Discussions will look different. You can see some of the proposed changes.
- This change only affects pages in the main namespace in Wikisource. The Javascript config variable
proofreadpage_source_href
will be removed frommw.config
and be replaced with the variableprpSourceIndexPage
. [2]
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
19:32, 4 July 2022 (UTC) —unsigned comment by MediaWiki message delivery (talk) 21:32, 4 July 2022 (UTC).
- @Inductiveload: User:Inductiveload/Metadata form.js is the only "current" use of
proofreadpage_source_href
. I'm pretty sure that's both broken and unused, but you may want to take a look just to be sure. Xover (talk) 09:07, 5 July 2022 (UTC)
Wikisource public library project in New Zealand
Some background: with the help of User:Beeswaxcandle, the Westland District Library in New Zealand in early 2021 began scanning and uploading out-of-copyright works in its collection to Wikisource. The completed works were then uploaded as EPUBs to the library's ebook catalogue in OverDrive, and made available for loan through most of the South Island. There's been brisk lending, with more readers for the books in the last six months than in 10 years on the shelves or locked away in a Special Collections cabinet. We now have a small group of New Zealand volunteers proofing and verifying, and I've given talks on the project to a couple of library conferences. I've blogged about how the work got started, how Wikisource works (from a public talk Beeswaxcandle gave at the library in Hokitika), and how we've gotten a local author to release their work under an open licence. The Grey District Library has employed a librarian part-time to source and scan New Zealand works, and I've just received a grant from the Mātātuhi Foundation, funded by the Auckland Writers Festival to spend a help-day a week supporting the project. The Foundation were very interested in the possibility of using Wikisource to increase the visibiity of New Zealand writers, and extending the project to more libraries.
Many people here have kindly stepped in to help out our team and untangle some of the more technical aspects of Wikisource. If anyone would like the add themselves to the task force project page, it would be great to have some regular assistance with transclusion, ToCs and indexes, and some other more complex fornatting—I'm just a beginner, having only been brought into the fold last year. We're looking forward to significantly increasing the amount of New Zealand content on the site over the next six months, and building a volunteer community here so the project becomes self-sustaining. Any help appreciated! —Giantflightlessbirds (talk) 02:06, 3 July 2022 (UTC)
- @Giantflightlessbirds: It would be great if you can nominate some works at the Monthly Challenge as well. Ciridae (talk) 10:57, 3 July 2022 (UTC)
- That's a great idea; we have some big works coming online soon, including a long biography of Richard Seddon. Giantflightlessbirds (talk) 11:14, 3 July 2022 (UTC)
- @Ciridae @Giantflightlessbirds Love the idea! Really happy to see libraries using the epubs produced by Wikisource. Languageseeker (talk) 11:51, 3 July 2022 (UTC)
- That's a great idea; we have some big works coming online soon, including a long biography of Richard Seddon. Giantflightlessbirds (talk) 11:14, 3 July 2022 (UTC)
- Yo this is awesome, thanks for bringing awareness to Wikisource to more people, and for increasing the number of NZ works on here! Reboot01 (talk) 23:59, 9 July 2022 (UTC)
Some TOC pages do not get transcluded
May I ask why the last TOC pages at The Acts and Monuments of John Foxe/Volume 3 are not transcluded? I have noticed that some pages using {{Dotted TOC page listing}} started to have this problem (although not a long time ago they worked fine) and so I started replacing that template with {{TOC begin}} templates, which always helped, except the above mentioned page.-- Jan Kameníček (talk) 21:42, 8 July 2022 (UTC)
- Jan Kameníček: It’s a built-in “feature” that makes pages with lots of text simply not work: see Category:Pages where template include size is exceeded. The solution is to subst: all templates, so make sure you’ve proofread the text. TE(æ)A,ea. (talk) 21:57, 8 July 2022 (UTC)
- Has the limit changed recently? The pages used to work well. --Jan Kameníček (talk) 22:02, 8 July 2022 (UTC)
- Jan Kameníček: If they can change it, I wish they would just remove the limit: that would fix other problems where even two pages can trigger the problem. TE(æ)A,ea. (talk) 22:20, 8 July 2022 (UTC)
- @TE(æ)A,ea.: Thanks very much for the advice, I have substituted the TOC templates and now it works fine.The limit must have been lowered for some reason :-( Can it be raised or removed for en.ws locally? --Jan Kameníček (talk) 22:27, 8 July 2022 (UTC)
- Jan Kameníček: I believe it is related to mw:Manual:$wgMaxArticleSize; I don’t believe it can be locally reset. TE(æ)A,ea. (talk) 22:39, 8 July 2022 (UTC)
- @TE(æ)A,ea.: Thanks very much for the advice, I have substituted the TOC templates and now it works fine.The limit must have been lowered for some reason :-( Can it be raised or removed for en.ws locally? --Jan Kameníček (talk) 22:27, 8 July 2022 (UTC)
- Jan Kameníček: If they can change it, I wish they would just remove the limit: that would fix other problems where even two pages can trigger the problem. TE(æ)A,ea. (talk) 22:20, 8 July 2022 (UTC)
- What, no, certainly not! Subst:ing templates is not something you should be doing, and certainly not recommending others do, unless the template is specifically designed for being subst:ed. It solves nothing—at best it hides a symptom—leaving the underlying problem in place and creating myriad new ones. Xover (talk) 08:25, 9 July 2022 (UTC)
- Has the limit changed recently? The pages used to work well. --Jan Kameníček (talk) 22:02, 8 July 2022 (UTC)
- @Jan.Kamenicek: The limit has not changed recently, and is unlikely to change any time soon (another in a long line of requests for this was declined just last week), because the limit is there for good technical reasons; mostly because raising it would cause performance problems. The "post-include expand size" is one of several limits built into MediaWiki that are designed to keep the sites from falling over when people do dumb things. One can quibble over the exact size of this limit (for instance, the limit is currently in bytes and heWS uses almost exclusively multi-byte characters, so they effectively get half the limit enWS gets).But the underlying problem here is actually the TOC templates, which are all various degrees of broken. {{Dotted TOC page listing}} is the very worst of the bunch, but all of them have severe problems. For the (really rather shocking) illustration, see this thread.For this reason I really very strongly recommend everyone use plain table wikimarkup (combined with {{ts}} where needed) for tables of contents. Yes, it is less convenient for some things (but more convenient for others), and, yes, it is a bit harder to learn; but it also gives much better control, is much easier to debug, and it completely avoids the problems with the TOC templates. It'd take a pretty epically massive table of contents to hit any of the built-in MediaWiki limits that way, at which point we're probably close to the point where splitting it up would be necessary for the reader in any case. You can hit the limits with plain tables and table styles as well, but that's typically when the tables are used in very long chapters or appendices with a lot of long tables with complicated formatting (and for these we now have a possible workaround in per-Index stylesheets).For shorter tables of contents (which is the majority after all) you can get away with using the templates with no visible problems (all the bloat and inefficiency is still there, it's just not visible unless you go digging at a technical level), so for these cases I've given up on nagging on people. But for anything a bit longer the bloat is just too much. {{Dotted TOC page listing}} in particular should never be used, and if I thought I'd get the community in general to go along I'd have proposed it for deletion a long time ago (I'm almost certain the community won't agree, which is why I'm here waving that flag instead of at WS:PD). Xover (talk) 11:22, 9 July 2022 (UTC)
- Some of the complexity will in time become obselete anyway... There's a proposal for the next 'level' of CSS for table to support the concept of dot leaders... which when supported in browsers should make adding the dots in TOC entries 1 line of CSS style, as opposed to the complex convolution used currently.
- ShakespeareFan00 (talk) 11:53, 9 July 2022 (UTC)
Tech News: 2022-28
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
- In the Vector 2022 skin, the page title is now displayed above the tabs such as Discussion, Read, Edit, View history, or More. Learn more. [3]
- It is now possible to easily view most of the configuration settings that apply to just one wiki, and to compare settings between two wikis if those settings are different. For example: Japanese Wiktionary settings, or settings that are different between the Spanish and Esperanto Wikipedias. Local communities may want to discuss and propose changes to their local settings. Details about each of the named settings can be found by searching MediaWiki.org. [4]
- The Anti-Harassment Tools team recently deployed the IP Info Feature as a Beta Feature at all wikis. This feature allows abuse fighters to access information about IP addresses. Please check our update on how to find and use the tool. Please share your feedback using a link you will be given within the tool itself.
Changes later this week
- There is no new MediaWiki version this week.
- Some wikis will be in read-only for a few minutes because of a switch of their main database. It will be performed on 12 July at 07:00 UTC (targeted wikis).
Future changes
- The Beta Feature for DiscussionTools will be updated throughout July. Discussions will look different. You can see some of the proposed changes.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
19:24, 11 July 2022 (UTC)
Common.js: line 33 to 59
There're two scripts in th:MediaWiki:Common.js line 53 to 79, which are documented as "envelope subNotes" and "envelop hatNotes", which are also presented in MediaWiki:Common.js from line 33 to 59 here. I wonder what these scripts actually do because from poking around the inspect element, I couldn't find how these two scripts currently apply to Wikisource. --Bebiezaza (talk) 15:03, 2 July 2022 (UTC)
- @Bebiezaza Both of these snippets seach for elements that have a specific selector and adds them to the top of the page.For example, the envelop hatNote section searches for elements that are tables with classes
ambox
orombox
(i.e. the wrapper element generated from the{{ambox}}
and{{ombox}}
templates and prepends them to the top of the page. (Take a look at British_Medical_Journal with and without?safemode=1
) Sohom Datta (talk) 13:37, 10 July 2022 (UTC)- @Bebiezaza, @Sohom data: These are adjuncts to the page numbers / dynamic layouts script. In order to display the layouts, that Gadget needs to wrap the content part of the page (the transcluded content) inside a few extra
div
containers. But that operation also catches maintenance templates (typically implemented using {{ambox}}/{{ombox}}) that we do not want to be subject to dynamic layouts. So the lines you point to tries to hoist those out of the dynamic layouts container and place them in a suitable place in the DOM. It's currently a bit buggy here on enWS so I wouldn't follow our code too religiously. In fact, you may want to try doing without that code and then add back in a modified version if and as needed. It's likely I will do the same here at some point to try to cut down on the amount of global code and the flaky behaviour. Xover (talk) 08:36, 12 July 2022 (UTC)
- @Bebiezaza, @Sohom data: These are adjuncts to the page numbers / dynamic layouts script. In order to display the layouts, that Gadget needs to wrap the content part of the page (the transcluded content) inside a few extra
Board of Trustees elections 2022 -- Election Compass
Hi all,
The 2022 Board of Trustees elections are from 15 August 2022 to 29 August 2022.
Members of the Wikimedia community have the opportunity to elect two candidates to a three-year term.
To make the election process more straightforward and to help the community members make informed decisions about candidates they want to support, we have prepared a tool called Election Compass.
How does the Election Compass work?
The Election Compass is a tool to help voters select the candidates that best align with their beliefs and views. The community members will propose statements for the candidates to answer using a Lickert scale (agree/neutral/disagree). The candidates’ answers to the statements will be loaded into the Election Compass tool. Voters will use the tool by entering their answers to the statements (agree/neutral/disagree). The results will show the candidates that best align with the voter’s beliefs and views.
Here is the timeline for the Election Compass:
- July 8 - 20: Community members propose statements for the Election Compass
- July 21 - 22: Elections Committee reviews statements for clarity and removes off-topic statements
- July 23 - August 1: Volunteers vote on the statements
- August 2 - 4: Elections Committee selects the top 15 statements
- August 5 - 12: candidates align themselves with the statements
- August 15: The Election Compass opens for voters to use to help guide their voting decision
Thank you!
BPipal (WMF) (talk) 15:31, 13 July 2022 (UTC)
Alumni Oxonienses: the Members of the University of Oxford, 1715-1886 done
Joseph Foster's Alumni Oxonienses: the Members of the University of Oxford, 1715-1886 now has all its entries posted here. It is a standard reference work, and the first part (1500-1714) is already digitised online; and would be a possible bot project here.
The four index pages were set up in July 2010, and many editors have since worked on this project. I'd like to mention Billinghurst (talk • contribs) and Miraclepine (talk • contribs). The scans present particular difficulties, with varying systematic errors that substitute one digit for another (especially in the third volume).
Integration work is under way: on Author pages here, on enWP for referencing, and in the creation of Wikidata items. I'd particularly like to mention the Topicmatcher tool, Wikisource version, by Magnus Manske. That link is set up for Foster, but can be used for any work here organised in subpage style. Charles Matthews (talk) 16:33, 11 July 2022 (UTC)
- @Charles Matthews: Thanks for the ping. I'll go do some work on the Wikidata items as soon as I can. I do want to note, though, that the Topicmatcher hasn't assigned preliminary matches to the recently created items. ミラP@Miraclepine 17:38, 11 July 2022 (UTC)
- I can ask Magnus what happens about refreshing that list. Charles Matthews (talk) 17:48, 11 July 2022 (UTC)
- @Miraclepine: Done - 8K more automatches. Charles Matthews (talk) 11:07, 18 July 2022 (UTC)
Tech News: 2022-29
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 feature on mobile web for Nearby Pages was missing last week. It will be fixed this week. [5]
Changes later this week
- The new version of MediaWiki will be on test wikis and MediaWiki.org from 19 July. It will be on non-Wikipedia wikis and some Wikipedias from 20 July. It will be on all wikis from 21 July (calendar).
Future changes
- The Technical Decision Forum is seeking community representatives. You can apply on wiki or by emailing TDFSupport@wikimedia.org before 12 August.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
22:59, 18 July 2022 (UTC)
Page Preview lacking headers and footers
For some time now I've been noticing that, when editing a page in the Page namespace, when I preview the page it is rendered without the header and footer (and thus as a side effect shows the page as "not proofread"). When the page is published, all is well; it appears to be solely the preview functionality. Have others seen this? Is this a known bug? — Dcsohl (talk)
(contribs) 18:48, 19 July 2022 (UTC)
- I have never noticed anything of that kind so far… Have you tried different browsers and/or different computers? --Jan Kameníček (talk) 18:59, 19 July 2022 (UTC)
- @Dcsohl: This is due to T309451. The workaround for now is to disable "Show previews without reloading the page" in the "Editing" section of the Preferences. Xover (talk) 20:08, 19 July 2022 (UTC)
Second-hand transcriptions
Can second-hand transcriptions be speedied based on Wikisource:What_Wikisource_includes#Second-hand_transcriptions or should they be listed at Wikisource:Proposed deletions? Currently, they are not among the Wikisource:Deletion policy#Speedy deletion criteria, but they are repeatedly proposed for speedy deletion. -- Jan Kameníček (talk) 09:09, 20 July 2022 (UTC)
- Only speedy-able if a sourced version of the same text is hosted, per G4. There are no other valid criteria for speedy deletion of such. Summary deletion of so-called "second-hand" transcriptions without discussion is against the open nature of us as a library that anyone can bring works to. We can encourage people to bring them in a scan-backed form, but at present we don't have a policy that restricts to on-site scan-backing. If we speedy delete a new-comer's contributions we lose the new-comer. Also, the definition of "second-hand" seems quite arbitrary. Why aren't the various Executive Orders treated as second-hand? They are after all, simply brought over from the White House websites with minimal wikification. Yet, I've never seen them proposed for deletion on this ground. Beeswaxcandle (talk) 09:49, 20 July 2022 (UTC)
- once upon a time, we used old guttenberg transcriptions pasted in the side by side edit box, when the text layer was really bad. (as a part of the migration process) yrmv. --Slowking4 亞 Farmbrough's revenge 21:23, 20 July 2022 (UTC)
- I believe that they would fall under G5. I don't think that there is any evidence that many of these contributions stay on enWS. Most of them come, copy-and-paste a text (often without formatting), and then leave. It's an extremely fast process for them. Then, other enWS contributors then have to spend time on trying to format properly. PG are especially problematic because they silently correct errata. The entire process is just a time drain. As for the Executive Orders, I would also say that they should be speedied. They are published in the Federal Register and should be scan-backed from there. Languageseeker (talk) 21:38, 20 July 2022 (UTC)
- they were useful to me, if you delete them, then i cannot migrate works to scan backed works. increasing the scrap rate does not increase quality. --Slowking4 亞 Farmbrough's revenge 22:41, 20 July 2022 (UTC)
- Definitely not G5. That is for content that is out of scope. The content of these works are in scope (on the whole), it's just the source that is seen as problematic by those tagging for speedy deletion. Beeswaxcandle (talk) 06:44, 21 July 2022 (UTC)
- I believe that they would fall under G5. I don't think that there is any evidence that many of these contributions stay on enWS. Most of them come, copy-and-paste a text (often without formatting), and then leave. It's an extremely fast process for them. Then, other enWS contributors then have to spend time on trying to format properly. PG are especially problematic because they silently correct errata. The entire process is just a time drain. As for the Executive Orders, I would also say that they should be speedied. They are published in the Federal Register and should be scan-backed from there. Languageseeker (talk) 21:38, 20 July 2022 (UTC)
- once upon a time, we used old guttenberg transcriptions pasted in the side by side edit box, when the text layer was really bad. (as a part of the migration process) yrmv. --Slowking4 亞 Farmbrough's revenge 21:23, 20 July 2022 (UTC)
- Second-hand transcriptions are out of scope for enWS, and any newly added second-hand transcriptions are speediable as such (that is, under CSD G5, which is the criterion for all content that does not meet WS:WWI). But the definition of it is inherently a grandfather clause in that it says enWS
no longer accepts any new … second-hand transcriptions of any sort
(my emphasis). So for anyone pasting in a new Gutenberg text today you can speedy it (presumably while explaining the issue to the contributor on their talk page); but for any similar text that was added in 2021 or earlier it needs to go through a normal deletion discussion. It is also not a given that older second-hand transcriptions will be deleted at WS:PD: the policy only implicitly marks these as undesirable, so absent community consensus to delete the status quo will obtain. There's no strong presumed default "delete" outcome for these. I personally think there should be, but that's not what the policy currently is. --Xover (talk) 06:42, 24 July 2022 (UTC)- While I agree that such works should not have a place at WS, I am hesitant about their speediness under current deletion policy. I agree with Beeswaxcandle that G5 with its bracketed part "(such as advertisements or book descriptions without text)" does not seem to give way to general speedying of all beyond-scope texts. So if we agreed that it does not apply only to completely blatant cases, we should either make the criterion more general by removing the brackets, or we should explicitely add some less blatant examples, e. g. the second-hand transcriptions.However, after this discussion and after several current similar nominations at WS:Proposed deletions, it seems to me that listing such cases there is useful, as some contributors sometimes save such works by scanbacking them, which would not be happening if they were speedied. --Jan Kameníček (talk) 12:19, 24 July 2022 (UTC)
- The bracketed stuff are informative examples to illustrate; the criterion itself is
Beyond scope: The content … lies outside the scope of Wikisource
(i.e. it fails to meet WS:WWI), and the limiting clause is… The content clearly lies outside the scope …
. The point there is that if something is borderline or there's a significant possibility of mistake the admin shouldn't unilaterally decide (speedy) and it should go to WS:PD instead for community discussion. The latter is usually exemplified by someone pasting Harry Potter here—which is clearly a copyvio—versus someone proofreading a 1964 book that makes a superficially plausible claim of being {{PD-US-no renewal}}. The latter could still be a copyvio, but a single admin shouldn't decide that based solely on misbelieving the contributor's assertion: it should go to WS:PD where the community can examine it and possibly dig up the evidence (either way) to determine its actual copyright status. Harry Potter, obviously, should be speedied on sight (and preferably before Wizarding World Digital sends its DMCA-wielding Nazgûl after us).That being said, I absolutely agree our policies are in dire need of tightening and should be written with much greater clarity. Navigating them now are an exercise in frustration for both general contributors and admins trying to apply them. --Xover (talk) 14:43, 24 July 2022 (UTC)- "but a single admin shouldn't decide that based solely on misbelieving the contributor's assertion:" and yet they do. we have very few DMCA, and yet the copyright enforcement is adamant, summary, and non-consensus. we would not need more tl;dr policy if the praxis were reasonable; and what makes you think admins will follow policy? --Slowking4 亞 Farmbrough's revenge 19:47, 25 July 2022 (UTC)
- The bracketed stuff are informative examples to illustrate; the criterion itself is
- While I agree that such works should not have a place at WS, I am hesitant about their speediness under current deletion policy. I agree with Beeswaxcandle that G5 with its bracketed part "(such as advertisements or book descriptions without text)" does not seem to give way to general speedying of all beyond-scope texts. So if we agreed that it does not apply only to completely blatant cases, we should either make the criterion more general by removing the brackets, or we should explicitely add some less blatant examples, e. g. the second-hand transcriptions.However, after this discussion and after several current similar nominations at WS:Proposed deletions, it seems to me that listing such cases there is useful, as some contributors sometimes save such works by scanbacking them, which would not be happening if they were speedied. --Jan Kameníček (talk) 12:19, 24 July 2022 (UTC)
Let's talk about the Desktop Improvements
Join an online meeting with the team working on the Desktop Improvements! It will take place on 26 July 2022 at 12:00 UTC and 19:00 UTC on Zoom. Click here to join. Meeting ID: 5304280674. Dial by your location.
Read more. See you! SGrabarczuk (WMF) (talk) 16:19, 25 July 2022 (UTC)
Tech News: 2022-30
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
- The www.wikibooks.org and www.wikiquote.org portal pages now use an automated update system. Other project portals will be updated over the next few months. [6]
Problems
- Last week, some wikis were in read-only mode for a few minutes because of an emergency switch of their main database (targeted wikis). [7]
Changes later this week
- The new version of MediaWiki will be on test wikis and MediaWiki.org from 26 July. It will be on non-Wikipedia wikis and some Wikipedias from 27 July. It will be on all wikis from 28 July (calendar).
- The external link icon will change slightly in the skins Vector legacy and Vector 2022. The new icon uses simpler shapes to be more recognizable on low-fidelity screens. [8]
- Administrators will now see buttons on user pages for "Change block" and "Unblock user" instead of just "Block user" if the user is already blocked. [9]
Future meetings
- The next open meeting with the Web team about Vector (2022) will take place tomorrow (26 July).
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
19:27, 25 July 2022 (UTC)
ToC links
I like to style ToC's with the text linking to the transcoded page (unconditionally), and the page number linking to the Page namespace (when viewed from the Page or Index namespace), and to the transcoded page when the ToC is transcluded. This is *mostly* satisfied by {{TOC row 2dot-1 linked}} but it seems to be partially broken; does anyone know of a better choice, or how to fix it? The bug I've observed is that, for multi-level subpages, e.g. The_Works_of_Voltaire/Volume_36, the page number links are broken (they assume a single level, e.g. they link to The Works of Voltaire/The Lisbon Earthquake but the actual page is The Works of Voltaire/Volume 36/The Lisbon Earthquake). I think there may be other bugs, too. But it's really nice to have working links both to the transcluded pages and the Page namespace from the Index page, on the actual ToC, so I'd love to get this fixed. Suggestions? JesseW (talk) 03:50, 24 July 2022 (UTC)
- Seems to me that this behaviour is caused by the part
#invoke:Filter|CleanParentDirectories
in the code of {{TOC link}}. --Jan Kameníček (talk) 11:57, 24 July 2022 (UTC)- Yeah, but I'm not sure what would break if I took that out. I suppose I could make a separate version... JesseW (talk) 14:03, 24 July 2022 (UTC)
- I took a look, and it looks like {{TOC link}} is broken by design: it has a hard assumption that there is never more than one level of subpage. Unfortunately, people have apparently depended on the broken behaviour for the last decade or so, so fixing it will require going through all extant uses and fixing the broken ones. I'm not sure that's a task that can be reasonably automated either (it'd need a lot of custom coding, not just application of existing tools), so there's no quick fixes here. Xover (talk) 18:34, 24 July 2022 (UTC)
- Cool, that makes creating a {{TOC link multilevel}} much more appealing. I'll see what I can do. JesseW (talk) 21:06, 24 July 2022 (UTC)
- Actually, it looks like {{TOC link}} is fine; it's {{TOC row 2dot-1 linked}} that needs fixing for multi-level subpages. Specifically, {{TOC link|1|Volume 3/Something|link label}} works fine; the trick is that {{TOC row 2dot-1 linked}} breaks up the page link as "The Works of Voltaire/Volume 36" and "The Lisbon Earthquake" (and makes the text link label just the second part), while {{TOC link}} needs the "Volume 36" part explicitly included. I should be able to make a variant of {{TOC row 2dot-1 linked}} that handles this correctly, just by splitting the "The Works of Voltaire/Volume 36" param. JesseW (talk) 22:59, 24 July 2022 (UTC)
- Sweet, I figured out a way to add an optional parameter (subpages=) that solves the problem! Yay, going off to fix ToC's now. JesseW (talk) 23:18, 24 July 2022 (UTC)
- Good to see you solved your problem. I'll have to take another look, but I suspect you're still relying on a quirk of the implementation which we'll need to design a proper migration path for at some point. Not a pressing issue, but just so you're aware.But let me just add the obligatory Please Don't Use These Templates™ rant: none of the current crop of toc templates should be used, because they are technically poor (every single use creates technical debt for us, and it's unsustainably huge already), a large proportion produce really rather horrid output (in a technical sense), their operation is prone to cause confusion (a link that looks blue in Page: may be broken in mainspace, and these templates make that harder to detect), and provide very little actual value for the complexity (linking to the physical page in Page: makes little sense: you'll never use it and it tells you nothing about the link's state in mainspace where it matters). It also doesn't help that we have a myriad inconsistent and incompatible such templates. The alternative is plain old table markup, which admittedly can be a little harder to learn and slightly more complicated to use for simple cases, but which gives you far more control and flexibility for the hard cases without the downsides of the toc templates.So far, nobody much are listening to me on this, but I live in hope… Xover (talk) 08:19, 25 July 2022 (UTC)
- I thought the {{TOC begin}} ones (like {{TOC row 2dot-1}}) were acceptable. And I find the links to the Page namespace very helpful as a way to get from the Index page to the start of the work, without having to bypass thru the transcluded page. I'd be fine with always linking the page number on the ToC to the Page namespace (like the titles on the ToC always link to the transcluded page), but I don't want to abandon all links to the Page namespace. What I want to avoid is repeating the transcluded page name, as that provides opportunities for typos. I'd be delighted if you give me an example of how your preferred way would look on Page:Works of Voltaire Volume 36.djvu/17 and, assuming I can understand it, I'll likely apply it to the others. JesseW (talk) 14:34, 25 July 2022 (UTC)
- @JesseW: My preferred approach would be something like this. If you feel the page number links are important you could easily apply {{TOC link}} to the page number column (I wouldn't, but that's a minor issue). My main point is that it's preferable to use plain table wikimarkup rather than any of the various TOC templates.But I need to stress that this is my personal opinion, and in terms of things like policy, style guide, community practice etc. there's absolutely nothing wrong with your current approach. It's just that I, from a primarily technical perspective, think they are a bad idea and take every opportunity to say so in the hopes of persuading as many as possible of that. But nobody (myself included) will give you the stink-eye if you still want to use your existing approach.Oh, and… The TOC-row family of templates are not by far the worst (that honor goes to dtpl), but anything that tries to fake dot leaders is going to be actively problematic. And using a new pseudo-syntax implemented as templates in order to generate wikimarkup which is then used to generate HTML is just a bad idea in general. But, you know, in the grand scheme of things… Xover (talk) 19:51, 28 July 2022 (UTC)
- @Xover: Great, thank you! Losing the dot leaders makes me sad (they are so pretty), but it fundamentally doesn't matter much. As I've said, I really value having links to the Page namespace from the Index, so I would certainly either apply {{TOC link}} or do unconditional links to the Page namespace (but I think some people don't like that). It's good to know about {{Table style}}. I don't think I'm going to go back and re-do any of the ToC's I've made, but I'll likely use your style for the other volumes of The Works of Voltaire as I make them. If I can't bear to leave out the dot headers, do you have a least-bad preference for making them? JesseW (talk) 20:10, 28 July 2022 (UTC)
- @JesseW: I agree dot leaders are both pretty and useful, but sadly they're the kind of thing that can really only properly be implemented with built-in support in browsers (and the CSS WG has been promising a specification for this Real Soon Now™ for going on a decade, iirc). After pouring way way too many hours into a clean(ish) way to fake them I've come to the conclusion that we'll just have to do without until browser support materialises. At which point I hope retrofitting them to existing TOCs will be a fairly easy, possibly automatable, task.Any of the TOC-row templates with dot leader support should be in the "least bad" camp I think; it's just {{dtpl}} itself that's truly pathological.Links from mainspace to Page: and Index: namespaces are an actual no-no (we have a draft linking policy floating around somewhere that addresses that specifically), so if you're going to have the page numbers linked it needs to be through through something namespace-conditional (like {{TOC link}}). But as I've mentioned, I question the utility for most works (there are always exceptions). Personal preference aside, it's rather a lot of complexity for something that will at best be irrelevant, and at worst actively confusing, for most readers. Xover (talk) 20:45, 28 July 2022 (UTC)
- @Xover: Cool, I'll leave out the dot leaders, pending browser support. As for the page number links (which I find particularly valuable for works with LOTS of tiny parts, like Index:Works_of_Voltaire_Volume_36.djvu, because that gives me a sense from the Index of which parts are done), I think I'll go for linking them to Page from the Index and Page namespaces, and leaving them unlinked in mainspace (since the transcluded page will be linked from the title). That has the advantage of not requiring any handling of the transcluded page name. I don't know if there's an existing template implementing that? If not, I'll make one. JesseW (talk) 21:46, 28 July 2022 (UTC)
- @JesseW: I agree dot leaders are both pretty and useful, but sadly they're the kind of thing that can really only properly be implemented with built-in support in browsers (and the CSS WG has been promising a specification for this Real Soon Now™ for going on a decade, iirc). After pouring way way too many hours into a clean(ish) way to fake them I've come to the conclusion that we'll just have to do without until browser support materialises. At which point I hope retrofitting them to existing TOCs will be a fairly easy, possibly automatable, task.Any of the TOC-row templates with dot leader support should be in the "least bad" camp I think; it's just {{dtpl}} itself that's truly pathological.Links from mainspace to Page: and Index: namespaces are an actual no-no (we have a draft linking policy floating around somewhere that addresses that specifically), so if you're going to have the page numbers linked it needs to be through through something namespace-conditional (like {{TOC link}}). But as I've mentioned, I question the utility for most works (there are always exceptions). Personal preference aside, it's rather a lot of complexity for something that will at best be irrelevant, and at worst actively confusing, for most readers. Xover (talk) 20:45, 28 July 2022 (UTC)
- @Xover: Great, thank you! Losing the dot leaders makes me sad (they are so pretty), but it fundamentally doesn't matter much. As I've said, I really value having links to the Page namespace from the Index, so I would certainly either apply {{TOC link}} or do unconditional links to the Page namespace (but I think some people don't like that). It's good to know about {{Table style}}. I don't think I'm going to go back and re-do any of the ToC's I've made, but I'll likely use your style for the other volumes of The Works of Voltaire as I make them. If I can't bear to leave out the dot headers, do you have a least-bad preference for making them? JesseW (talk) 20:10, 28 July 2022 (UTC)
- @JesseW: My preferred approach would be something like this. If you feel the page number links are important you could easily apply {{TOC link}} to the page number column (I wouldn't, but that's a minor issue). My main point is that it's preferable to use plain table wikimarkup rather than any of the various TOC templates.But I need to stress that this is my personal opinion, and in terms of things like policy, style guide, community practice etc. there's absolutely nothing wrong with your current approach. It's just that I, from a primarily technical perspective, think they are a bad idea and take every opportunity to say so in the hopes of persuading as many as possible of that. But nobody (myself included) will give you the stink-eye if you still want to use your existing approach.Oh, and… The TOC-row family of templates are not by far the worst (that honor goes to dtpl), but anything that tries to fake dot leaders is going to be actively problematic. And using a new pseudo-syntax implemented as templates in order to generate wikimarkup which is then used to generate HTML is just a bad idea in general. But, you know, in the grand scheme of things… Xover (talk) 19:51, 28 July 2022 (UTC)
- I thought the {{TOC begin}} ones (like {{TOC row 2dot-1}}) were acceptable. And I find the links to the Page namespace very helpful as a way to get from the Index page to the start of the work, without having to bypass thru the transcluded page. I'd be fine with always linking the page number on the ToC to the Page namespace (like the titles on the ToC always link to the transcluded page), but I don't want to abandon all links to the Page namespace. What I want to avoid is repeating the transcluded page name, as that provides opportunities for typos. I'd be delighted if you give me an example of how your preferred way would look on Page:Works of Voltaire Volume 36.djvu/17 and, assuming I can understand it, I'll likely apply it to the others. JesseW (talk) 14:34, 25 July 2022 (UTC)
- Good to see you solved your problem. I'll have to take another look, but I suspect you're still relying on a quirk of the implementation which we'll need to design a proper migration path for at some point. Not a pressing issue, but just so you're aware.But let me just add the obligatory Please Don't Use These Templates™ rant: none of the current crop of toc templates should be used, because they are technically poor (every single use creates technical debt for us, and it's unsustainably huge already), a large proportion produce really rather horrid output (in a technical sense), their operation is prone to cause confusion (a link that looks blue in Page: may be broken in mainspace, and these templates make that harder to detect), and provide very little actual value for the complexity (linking to the physical page in Page: makes little sense: you'll never use it and it tells you nothing about the link's state in mainspace where it matters). It also doesn't help that we have a myriad inconsistent and incompatible such templates. The alternative is plain old table markup, which admittedly can be a little harder to learn and slightly more complicated to use for simple cases, but which gives you far more control and flexibility for the hard cases without the downsides of the toc templates.So far, nobody much are listening to me on this, but I live in hope… Xover (talk) 08:19, 25 July 2022 (UTC)
- I took a look, and it looks like {{TOC link}} is broken by design: it has a hard assumption that there is never more than one level of subpage. Unfortunately, people have apparently depended on the broken behaviour for the last decade or so, so fixing it will require going through all extant uses and fixing the broken ones. I'm not sure that's a task that can be reasonably automated either (it'd need a lot of custom coding, not just application of existing tools), so there's no quick fixes here. Xover (talk) 18:34, 24 July 2022 (UTC)
- Yeah, but I'm not sure what would break if I took that out. I suppose I could make a separate version... JesseW (talk) 14:03, 24 July 2022 (UTC)
- I was looking for precisely that! A while back I made Template:LinkedTOC_row_1-1-1 because I couldn't find something that worked.
- Example of it working: Social Security Act 2018 (Version 56). You'll see in the transcluded version, you just see links to transcluded pages, but if you click on page 1 or 2 to the page space, the main space links disappear, and now only the page links show. It might not be exactly what you want, but I think you could very easily create another template that meets your needs from this. It's very simple code that either displays links or not depending on whether you're in the main or page namespace. Mine is also very "sub-page" specific so you might need to adjust that too for your uses. Supertrinko (talk) 00:21, 26 July 2022 (UTC)
- Interesting! I'm not sure I like the page numbers disappearing entirely in mainspace, as they are there in the original document. But it's nicely made. JesseW (talk) 12:19, 26 July 2022 (UTC)
- I chose that because I felt page numbers are not valuable in a transcribed document where pages are meaningless, but being a template, it's easily adjusted to act like the main links, where they could instead display as text without a link, or they could just permanently link to the page regardless and not be special at all. Supertrinko (talk) 20:33, 26 July 2022 (UTC)
- Interesting! I'm not sure I like the page numbers disappearing entirely in mainspace, as they are there in the original document. But it's nicely made. JesseW (talk) 12:19, 26 July 2022 (UTC)
Deletion of redirects
Hi Wikisource folks. An outside observation from English Wiktionary: I have done an audit of broken links from English Wiktionary to English Wikisource. You can see the list here. As you can see, a significant number of the links were once valid but have since been broken by page moves on this wiki. In particular, chapters of Moby-Dick and Sons and Lovers as well as the Song of Everlasting Regret appear all throughout the list.
It seems that this situation has arisen because of eager deletion of redirects on this project. The administrators who deleted those redirects evidently did not consider the impact this would have on other websites (not just wikis) which link to Wikisource texts. Keeping long-standing URLs functional is a courteous thing for a website to do, especially one such as Wikisource where the content is very stable and drastic changes would not be expected. It's reasonably easy for us on Wiktionary to fix these broken links because of our use of templates, but the same can't be said for everybody who links to this site.
I am curious to understand Wikisource's policy on redirects, how it has come about, and whether there is appetite for keeping certain long-standing redirects even if current naming schemes are not followed. This, that and the other (talk) 14:19, 9 July 2022 (UTC)
- This, that and the other does wiktionary have much going on with wikidata yet? Here {{wdl}} can be used and will prevent this kind of problem from enthusiastic redirect deleters and other problems of inter-wiki linking, as it grabs the current link.--RaboKarbakian (talk) 15:32, 9 July 2022 (UTC)
- @This, that and the other: Well, admittedly, we are sometimes a bit too aggressive in pruning top-level redirects that are non-standard (but might be targeted from another wiki). But mainly the short answer is that page moves and deletions happen and we need to use other mechanisms to keep the dead links down (maybe we should look at bot-updating any link whose target has turned into a soft redirect?). For example, as RK says above, adopting linking through Wikidata would catch page moves, and might make it easier to detect page deletions. And some discipline in (i.e. policy for) what to link to: in your list I find links to the Page: namespace here (which is an internal working area you generally shouldn't link to), links to subpages in mainspace (subpages have zero stability guarantees and don't get redirects on page moves), links to one specific edition of a work when it is likely the intent is to link to the work, and so forth.And I see another significant subset of the pages in your list are pages created before standards for things like page names were set here, and as such have seen a larger than average amount of attrition due to cleanup and standardisation. As a general rule of thumb, top-level pages for works (that is, versions pages) and specific editions do not tend to change much here (when they're done they're done). At worst an edition gets moved to make way for a versions page, but then the old page name still gets you a list of editions of the work. In other words, I think a lot of the current dead links are the inevitable consequence of cleaning up old messes (other projects, like enWP, have done this years ago and are now much more stable); and a lot of the rest can be ameliorated (not eliminated) by more disciplined linking.But I think a better question to address is how we can enable "deep linking" (for lack of a better term). For parts of works that are themselves works (poems, short stories, some, but not all, newspaper and magazine articles, etc.; stuff that's usually published in some form of collection) we can usually create top-level redirects to the subpage (and you should link to the redirect instead of the subpage). But for, say, a chapter of a novel our standard is to not have redirects. At the same time, Wiktionary and Wikipedia (e.g.) will often want to link to such a sub-part of the work. I also expect both to have a need to link directly to a specific sentence or position (think "To be or not to be"). We currently have no facility to enable this. And both these things are sometimes needed for internal linking on enWS as well, so it's not just our sister projects that need this. Xover (talk) 17:01, 9 July 2022 (UTC)
- One of problems I can see is the fact that when we move a work we can check what links there only from Wikisource, we cannot check what links there from other Wikiprojects. If we could, it would help to prevent such things from happening very much. --Jan Kameníček (talk) 07:43, 10 July 2022 (UTC)
- as a part of the process of deleting redirects, should we include a "what links here check" and if not fixing right away, then adding to a list for linking at the other wiki? --Slowking4 亞 Farmbrough's revenge 18:11, 10 July 2022 (UTC)
- This sort of thing has even happened here with intrawiki links: see Page:Hero and Leander - Marlowe and Chapman (1821).pdf/36 and The Passionate Shepherd to His Love, both of which were broken because the page to which they both linked (Golden Treasury of English Songs and Lyrics/Book 1/Poem 5) was moved to The Golden Treasury, etc. A redirect was left for the root page in mainspace, but not for all the subpages.The former of the two broken pages also illustrates the use of {{anchor}}, which is one way—albeit unwieldy—to link to a specific passage in a text. Shells-shells (talk) 20:24, 10 July 2022 (UTC)
- Wiktionary wants to cite a use of a word. Thus Wiktionarians don't want to cite a generic form of the work, or link to the top level; they want to link a page that has the word in question on it in a specifically dateable context. It doesn't strike me as that rare; while there are times you want to link to a generic version, there's times you want to talk about Homer's use of rosy-fingered dawn ("as soon as early rosy-fingered Dawn appeared, then they set sail for the wide camp of the Achaeans") and link not to the Iliad, but the Iliad, book 1, and a translation that faithfully translates that (not Alexander Pope's! apparently many students over the years have been confused by that).--Prosfilaes (talk) 04:14, 11 July 2022 (UTC)
- Thanks all for your input. I am glad to have generated some discussion around this topic. This, that and the other (talk) 09:59, 16 July 2022 (UTC)
- It is precisely because of Wiktionary linking that I have endeavored to avoid the need for later moves. We have some editors here who insist that if a work does not have multiple editions hosted now, then the base title is where the edition must be hosted, which means that, if ever we have an additional edition, the work gets moved. We can avoid this issue by more forward-thinking effort. If a work is a translation, or exists in multiple significant editions, we ought to place any edition/translation of that work at a more specific title, and set up a versions page for the main item. This would not only help with Wiktionary linking, but would also assist with connecting to Wikidata and Wikipedia. --EncycloPetey (talk) 18:11, 2 August 2022 (UTC)
- One of problems I can see is the fact that when we move a work we can check what links there only from Wikisource, we cannot check what links there from other Wikiprojects. If we could, it would help to prevent such things from happening very much. --Jan Kameníček (talk) 07:43, 10 July 2022 (UTC)
Uploading new versions of files
I have been asking in vain for help with the for some time now and humbly request that my problem be given some attention. I CANNOT upload a new version of any file. This has been the situation for many months now. Any attempt to upload a new version is inevitably corrupted and all I get is Fileicon-pdf.png and no file. Esme Shepherd (talk) 20:40, 17 July 2022 (UTC)
- @Esme Shepherd Sorry to hear that. I've been having some trouble with some pdfs recently, it might be a bug. What file are you trying to upload? Languageseeker (talk) 22:13, 17 July 2022 (UTC)
Every file I have tried to load a new version to for maybe a year now. The latest was Lydia Sigourney 1834.pdf, which is now in Category: Lydia Sigourney Redundant Files, as I had to re-upload it as Lydia Sigourney, 1834.pdf, which I am now working on. Esme Shepherd (talk) 06:05, 18 July 2022 (UTC)
This problem has not gone away. I still cannot upload a new version of any file. It seems that wiki will eventually become unusable due to such lack of attention to detail. Any hope of action soon, please? Esme Shepherd (talk) 16:21, 16 August 2022 (UTC)
- I didn't see any files by the names you cited above, but I did see you have uploaded both Index:Poems Sigourney, 1834.pdf (uploaded July 13 and which you have fully proofread) and the older Index:Poems Sigourney 1834.pdf (uploaded July 12 and not proofread), so just to be clear, are these the correct files? Because I see the pages of both PDFs perfectly fine. Is it possible there may be some browser caching issue at play here? What process are you using when you encounter the difficulty? — Dcsohl (talk)
(contribs) 19:00, 16 August 2022 (UTC)
Copyright status of Men, Ships, and the Sea (1962)
I have done some searching in the copyright.gov database and come up empty for a renewal of the first edition of Men, Ships, and the Sea by Alan Villiers, published in 1962 by the National Geographic Society. As far as I can tell it should therefore have lapsed into the public domain (excepting, possibly, licensed photographs and illustrations within it). However, seeing as other works by Villiers have had their copyrights renewed (e.g., the very similarly named Of Ships and Men, also published in 1962), I would like to know the opinion of a more experienced user in judging the copyright status of this work, as I may have missed something important.
On a related note, is there a proper area for discussion about the copyright statuses of works not yet added to WS? I would have put this on WS:Copyright discussions, but that seems to be more about works already on WS than about ones offsite. Shells-shells (talk) 04:31, 23 July 2022 (UTC)
- Do you have the book? If you look at the actual book, you may see a list of copyright notices from other works. With or without them, I'm still concerned that there may be a number of other works that it's copying from.--Prosfilaes (talk) 20:15, 23 July 2022 (UTC)
- @Prosfilaes, @Xover: I'm reasonably confident that at least the text content was written specifically for this book, not copied from another source. I have a copy of the 1973 edition, which explicitly states: "Text by Alan Villiers / with a foreword by Melville Bell Grosvenor / and additional chapters by [several other authors]". The foreword to this edition seems to indicate that the book was written from scratch: "In commissioning him [Villiers] as chief author of Men, Ships, and the Sea, the Society chose the greatest sea writer of our time."There are, however, a proudly proclaimed "423 illustrations, 294 in full color" in my copy. Most of these are undoubtedly still under copyright (although a few are obviously in the public domain, and some were commissioned specifically for the book). That's slightly less than one illustration per page. I suppose I could redact all the offending images if I wanted to, but it's probably not fruitful enough to spend a great deal of time with. (If I were to do so—assuming all the text content is PD—would it then be suitable to host here?) In any case, thanks to both of you for the help and advice.
:)
Shells-shells (talk) 17:12, 24 July 2022 (UTC)
- @Prosfilaes, @Xover: I'm reasonably confident that at least the text content was written specifically for this book, not copied from another source. I have a copy of the 1973 edition, which explicitly states: "Text by Alan Villiers / with a foreword by Melville Bell Grosvenor / and additional chapters by [several other authors]". The foreword to this edition seems to indicate that the book was written from scratch: "In commissioning him [Villiers] as chief author of Men, Ships, and the Sea, the Society chose the greatest sea writer of our time."There are, however, a proudly proclaimed "423 illustrations, 294 in full color" in my copy. Most of these are undoubtedly still under copyright (although a few are obviously in the public domain, and some were commissioned specifically for the book). That's slightly less than one illustration per page. I suppose I could redact all the offending images if I wanted to, but it's probably not fruitful enough to spend a great deal of time with. (If I were to do so—assuming all the text content is PD—would it then be suitable to host here?) In any case, thanks to both of you for the help and advice.
- @Shells-shells: You're right that WS:CV is more a workflow for discussing the copyright status of texts already on enWS. But you can certainly raise other copyright issues, such as the one in this thread, there too. It's more a question of what's the best venue for your needs: WS:CV is watched by only a small subset of the community (unfortunately) and is often months and years backlogged (because of insufficient community participation) so as a practical matter you may prefer to post here. On the flip side, for complicated copyright issues WS:CV may be better because the copyright wonks will see it there, and it may get you a more definitive answer (or at least guard against wholly incorrect answers).Short version: feel free to post such queries either place.PS. I agree with Prosfilaes: even if the copyright on this work was not renewed, it may contain independently copyrighted works that for our purposes has the same effect as if the whole was in copyright. Xover (talk) 06:53, 24 July 2022 (UTC)
- and this is why i would support a limited "fair use of the illustrations in the public domain text". we are stopping work on lots of texts, because the "de minimus" of the mueller report was a one off. --Slowking4 亞 Farmbrough's revenge 19:41, 18 August 2022 (UTC)
Despite the name, this appears to be a scan of Volume 23 of The Strand Magazine, rather than 22, so it would be good to get it replaced with the correct volume (for example, https://archive.org/download/TheStrandMagazineAnIllustratedMonthly/TheStrandMagazine1901bVol.XxiiJul-dec.pdf ).
Let me know if there is a better place to post this, as this is my first post that isn't a proofreading edit. Qq1122qq (talk) 14:42, 29 July 2022 (UTC)
- At Wikisource:Scan lab. Mpaa (talk) 08:57, 7 August 2022 (UTC)
- Thanks - it looks like this has been noticed and dealt with, but I'll use the scan lab for future problems. Qq1122qq (talk) 13:18, 28 August 2022 (UTC)