Wikisource:Scriptorium/Archives/2024-02

Script doesn't load.

This section was archived on a request by: ShakespeareFan00 (talk) 13:50, 1 February 2024 (UTC)

Can someone please take a look at :- https://en.wikisource.org/wiki/User:ShakespeareFan00/common.js and explain why InductiveLoad's Minipane script has decided to stop working for me, it doesn't seem to display in the sidebar anymore? ShakespeareFan00 (talk) 09:44, 1 February 2024 (UTC)

The relevant script being - User:Inductiveload/MiniPane.js ShakespeareFan00 (talk) 09:58, 1 February 2024 (UTC)

It works for me. Xover (talk) 11:14, 1 February 2024 (UTC)

Please screenshot the list of gdagets you have installed, and link your Common.js. , because when I disabled everything apart from that script it still didn't load properly. ShakespeareFan00 (talk) 11:16, 1 February 2024 (UTC)

@Xover: - That it works for you suggests some very specific interaction, but I tried switching off various gadgets and it STILL didn't work. Perhaps YOU can take a look at https://en.wikisource.org/wiki/User:ShakespeareFan00/common.js and preferences and tell me what broke (or what I am doing incorrectly), because I am fed up running around after erratic usablity issues! ShakespeareFan00 (talk) 11:39, 1 February 2024 (UTC)

Hmm.. I've gone through switching off and on various add-ons in Firefos, and it all works again, so I'm not sure what 'glitched'. Minipane needs porting over to OOUI anyway (it's still using jquery), and it would be nice if and the functions of jump to file were more closely intergrated into Proofread page more directly, as happened with the OCR tools earlier. ShakespeareFan00 (talk) 12:11, 1 February 2024 (UTC)

Tech News: 2024-06

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 mobile site history pages now use the same HTML as the desktop history pages. If you hear of any problems relating to mobile history usage please point them to the phabricator task.
• On most wikis, admins can now block users from making specific actions. These actions are: uploading files, creating new pages, moving (renaming) pages, and sending thanks. The goal of this feature is to allow admins to apply blocks that are adequate to the blocked users' activity. Learn more about "action blocks". [1][2]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 6 February. It will be on non-Wikipedia wikis and some Wikipedias from 7 February. It will be on all wikis from 8 February (calendar). [3][4]
• Talk pages permalinks that included diacritics and non-Latin script were malfunctioning. This issue is fixed. [5]

Future changes

• 24 Wikipedias with Reference Tooltips as a default gadget are encouraged to remove that default flag. This would make Reference Previews the new default for reference popups, leading to a more consistent experience across wikis. For 46 Wikipedias with less than 4 interface admins, the change is already scheduled for mid-February, unless there are concerns. The older Reference Tooltips gadget will still remain usable and will override this feature, if it is available on your wiki and you have enabled it in your settings. [6][7]

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

MediaWiki message delivery 19:22, 5 February 2024 (UTC)

Rendering of 'blackletter' text

For awareness, while validating this page Page:The_Economist_1843-08-_Vol_1_Preliminary_Number_(IA_sim_economist_1843-08_1_preliminary-number).pdf/1 using Firefox, I thought there were typos in the line 'And Banker's Gazette', as both the 'A' and 'k' did not look right in blackletter. However, the text is correct. When viewing the same page in Edge, the blackletter text renders correctly. Chrisguise (talk) 08:10, 6 February 2024 (UTC)

Chrisguise: Template:Blackletter#Modes mode 4 gets the s and the k. 'k?--RaboKarbakian (talk) 11:50, 6 February 2024 (UTC)

Thanks for the fix. I've not previously had any problems with the default mode. Chrisguise (talk) 12:05, 6 February 2024 (UTC)

Chappaquiddick

What is the copyright position of a speech like this ? -- Beardo (talk) 02:12, 5 February 2024 (UTC)

@Beardo: Personally I would consider this speech to be primarily a political speech (it concerns the then-Senator's resignation and whether he should seek reelection, and addresses these questions to the voters), and as such is outside the scope of {{PD-USGov}}. This means normal copyright rules apply, and the issue of copyright status hinges on when it was first subject to general publication with the author's consent (note that the speech was just a performance, not a publication, so you'll need to look for, typically, a book form publication or a newspaper article bylined by Kennedy rather than reported by the newspaper's staff). If that publication was without copyright notice, or if whatever work it was did not have its copyright renewed, then it is {{PD-US-no notice}} or {{PD-US-no renewal}}, otherwise it's in pub. +95 copyright (or if unpublished in pma. 70 copyright). Xover (talk) 09:05, 7 February 2024 (UTC)

Making WS:Annotations official policy

Please see the discussion on this subject below at #Wikisource:Annotations —Beleg Tâl (talk) 02:05, 9 February 2024 (UTC)

Template:M-larger

What is this template for? --EncycloPetey (talk) 17:28, 5 February 2024 (UTC)

I'm confused as to what's confusing: it makes text that is 110% the font size of the previous text. —Justin (koavf)❤T☮C☺M☯ 17:45, 5 February 2024 (UTC)

Under the Usage heading, it merely says: "This template simplifies formatting text that is M-larger" without explaining what that means. --EncycloPetey (talk) 17:50, 5 February 2024 (UTC)

Sure, but Template:M-larger#Font_size_definition_by_relative_differences_using_words. —Justin (koavf)❤T☮C☺M☯ 17:58, 5 February 2024 (UTC)

Ah! Instead of explaining the usage in the Usage section, its explanation was placed much further down the page, buried in a table explaining multiple templates in relation to each other. --EncycloPetey (talk) 18:10, 5 February 2024 (UTC)

Our current size classes are a deliberate standardisation of text sizes, and new sizes should not be added without a policy-level discussion. Arbitrary other sizes can be achieved—when there is some exceptional need to deviate—using {{font-size}} (alias {{fs}}). Xover (talk) 09:10, 7 February 2024 (UTC)

It seems {{m-larger}} was added to this table in July. I had never heard of the template prior to seeing it used recently. Was there a discussion to add that template as standard? --EncycloPetey (talk) 19:43, 8 February 2024 (UTC)

Copyright status check..

IS this PD-US-Gov - https://archive.org/details/coloruniversalla440kell/mode/1up It seems to contain reprints of earlier material from copyright journals. If it is PD-US-Gov ( as a NIST/NBS published) work can someone please put it on commons? (Or at the very least identify the portions that can be.) ShakespeareFan00 (talk) 10:19, 9 February 2024 (UTC)

Yes, this is just a repackaging of two earlier works, which would presumably have copyright protections and it is not clear if/when/how/that they were put into the public domain. —Justin (koavf)❤T☮C☺M☯ 10:39, 9 February 2024 (UTC)

Seems fine to me; it's a 1976 work published without copyright notice, with permission of the author (see introduction). For the two underlying works, "THE ISCC-NBS METHOD OF DESIGNATING COLORS AND A DICTIONARY OF COLOR NAMES, by Kenneth L. Kelly and Deane B. Judd, NBS Circular 553, Nov. 1, 1955" is an NBS Circular, and in this context NBS obviously means the National Bureau of Standards, the same federal government body that's publishing this book, and "A UNIVERSAL COLOR LANGUAGE, by Kenneth L. Kelly, Color Engineering 3, 16 (March- April 1965)" is solely authored by the author of the introduction, so it had his permission. https://tsapps.nist.gov/srmext/certificates/archives/2106.pdf is a copy of the original article with a copyright notice from Color Engineering's publisher. I believe it to be the work of a US government official in the course of their job, and thus not eligible for copyright, but that part could be a concern. The other work is clearly PD-USGov/PD-US-no notice, IMO, and is not a problem.--Prosfilaes (talk) 17:04, 9 February 2024 (UTC)

Circular 533 is something to find :) - The only difference here is that the 1976 printing might have had eratta corrected? ShakespeareFan00 (talk) 17:14, 9 February 2024 (UTC)

Other works on Colorimetry:

• Ridgway, Robert, Color Standards and Color Nomenclature, Washington D.C (1912)
• D.H. Hamly, The ridgway Color Standards with a Munsell Notation Key, J.Opt. Soc. America , 39, 592(1949)
• Colors for Moldeld Urea Plastics, Commercial Standard CS147-47, U.S Department of Commerce, (1947)
• Colors for Polysterene Plastics, Commercial Standard CS156-49, U.S Department of Commerce, (1949)
• Federal Specifcation TT-C-595 , Colors : Ready Mixed Paints. Issued: 1951 (It became FS 595?)
• Judd, D.B. The 1931 I.C.I Standard Observer and Coordinate System for Colorimetry, Journal of the Optical Society of America 23,359 (1933)
• Judd, D.B and Kelly, K.L., Method of Designating Colors, Journal of Research, NBS 23,355 (1939) RP1239
• Kelly, K.L., Central Notations for the Revised ISCC, NBS 61, 427 (1958); RP 2911
• Kelly. K.L., Coordinated color identifications for Industry, NBS TN152 (Nov. 1962)
• Kelly. K.L., and Judd, D.B. The ISCC-NBS Method of Designating Colors and a Dictionary of Color Names. NBS Circular 533. Nov 1. 1955

ShakespeareFan00 (talk) 18:51, 9 February 2024 (UTC)

• The original of “A Universal Color Language” can be found here on IA. Color Engineering is a privately published periodical, “© Kinelow Publishing Company, Inc., 1965.” There is no copyright notice on Kelly’s article, nor on any other article. Copyrights on issues of periodicals apply to the issue itself (for the proprietor of the periodical) and to the articles printed within (for the authors of the articles). It’s not clear whether Kelly held on to his copyright, or assigned it to Kinelow so as to have the article published. At the end of the article, there is a short description of Kelly’s professional career, highlighting his work with the National Bureau of Standards, in addition to three papers co-authored with Dr. Judd, “Method of Designating Colors,” “ISCC-NBS Method of Designating Colors and a Dictionary of Color Names,” and “Central Notations for the Revised ISCC-NBS Color-Name Blocks.” In addition, this description does not make any mention of private work (except work done collaboratively, in which he was the Federal part). As the original article was published in an issue of a periodical with a copyright notice, if the article was done separately from his work, than the copyright on that work would continue through the new (combined) publication, even though the modifications would be PD-US-no notice. On balance, though, I would say the article is PD-USGov, despite the non-government publication. TE(æ)A,ea. (talk) 19:28, 9 February 2024 (UTC)

longdash not transcluding properly

See A_Chambermaid's_Diary on p.7, where the longdash inside italics is not transcluding properly, neither does it it look correct in the Page namespace. --EncycloPetey (talk) 23:26, 11 February 2024 (UTC)

Nevermind. I found the problem. --EncycloPetey (talk) 23:29, 11 February 2024 (UTC)

Style sheet per book

One often puts energy into shaping each heading or image caption to look a bit like the printed typography. An idea that has struck me is that this could be done with a CSS style sheet per book. In this book, all chapter headings are written in ALL CAPS, section headings in small caps, and image captions in cursive. Then you could just run away with ==h2== and ===h3=== and <img> tags and all would be fine. Has anybody experimented with this? Would it work with transclusions under the ProofreadPage extension? LA2 (talk) 21:02, 6 February 2024 (UTC)

@LA2: See Help:Page styles. But don't use MediaWiki default heading and image caption syntax for these. MediaWiki and the skin "owns" these and can change their styling at any time (in addition to heavily styling them in the current style sheets). Use our normal Wikisource-specific formatting templates and then override their styles using page styles. For chapter headings and subheadings I am working on {{h}} and {{sh}} as a simple and consistent way to handle most (think 80/20) such constructs. They add very simple default styling, but are designed to be enriched or overridden by Page styles. And I plan to make more such templates as I come across other good candidates for standardised handling (plates and image captions may be one such). They're currently undocumented while I test them out in my own proofreading projects to get experience with where they work well and where they need tweaks, but I'm happy to help if you want to try experimenting with them in your proofreading projects. Xover (talk) 09:20, 7 February 2024 (UTC)

@Xover I think they cam be merged with {{Pseudoheading}} and relatives. Mpaa (talk) 20:40, 11 February 2024 (UTC)

@Mpaa: Eventually, yes. Right now they're deliberately separate because we're exploring the same ideas from slightly different angles. Xover (talk) 06:05, 12 February 2024 (UTC)

Announcing the results of the UCoC Coordinating Committee Charter ratification vote

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Dear all,

Thank you everyone for following the progress of the Universal Code of Conduct. I am writing to you today to announce the outcome of the ratification vote on the Universal Code of Conduct Coordinating Committee Charter. 1746 contributors voted in this ratification vote with 1249 voters supporting the Charter and 420 voters not. The ratification vote process allowed for voters to provide comments about the Charter.

A report of voting statistics and a summary of voter comments will be published on Meta-wiki in the coming weeks.

Please look forward to hearing about the next steps soon.

On behalf of the UCoC Project team,

RamzyM (WMF) 18:24, 12 February 2024 (UTC)

Tech News: 2024-07

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 WDQS Graph Split experiment is working and loaded onto 3 test servers. The team in charge is testing the split's impact and requires feedback from WDQS users through the UI or programmatically in different channels. [8][9][10] Users' feedback will validate the impact of various use cases and workflows around the Wikidata Query service. [11][12]

Problems

• There was a bug that affected the appearance of visited links when using mobile device to access wiki sites. It made the links appear black; this issue is fixed.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 13 February. It will be on non-Wikipedia wikis and some Wikipedias from 14 February. It will be on all wikis from 15 February (calendar). [13][14]
• As work continues on the grid engine deprecation,[15] tools on the grid engine will be stopped starting on February 14th, 2024. If you have tools actively migrating you can ask for an extension so they are not stopped. [16]

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

MediaWiki message delivery 05:48, 13 February 2024 (UTC)

Moving essays between namespaces

After receiving a talk I would like to strongly oppose an unilateral move to userfy the essay for several reasons:

1. The move lacked prior discussion.
2. The move would discourage faithful improvement by others.
3. Jimbo Wales, not me, originated the post against attacks on userpages, which should document wmf:Policy:Terms_of_Use#4._Refraining_from_Certain_Activities.
4. Template:Blanked userspace page is further documented.

Hopefully this matter will be peacefully solved.--Jusjih (talk) 02:37, 4 February 2024 (UTC)

@Jusjih: You think this issue is very important due to a personal bad experience with a Chinese project that permitted one such page aimed at you, but using user pages for attacks on other contributors is an absolute non-issue on enWS. To the degree it ever occurs (which I don't recall ever seeing) the admins will deal with it under existing policy (and the UCoC, which requires us to deal with such pages even if there was no local policy). Xover (talk) 07:37, 4 February 2024 (UTC)

@Jusjih: I also do not see which problem present in Wikisource either currently or in the past you are trying to address and what is the point of having such an essay in the Wikisource namespace. I am very sorry if you were a subject of an attack somewhere else, in the past I experienced it too, so I know what it is like and you have all my sympathy, but I do not see how it could help when you import the essay to an unrelated project. Essays in the Wikisource namespace should address Wikisource issues only. According to Wikisource:Essays, Wikisource essays are general-interest essays while User essays are specific or minority-interest essays... The text you imported really does not seem to be connected with anything we generally feel as needed to be solved here, as far as I know there has never been such a problem since I started contributing here, and so it falls under the category of user essays (if needed here at all). --Jan Kameníček (talk) 10:07, 4 February 2024 (UTC)

I don't see any issue with having this essay, or any other relevant essay that a contributor wishes to write, present in WS space. I have no problem moving this one back to WS space where it belongs.

Personally, it doesn't matter to me what space the essay is placed in. However, I think that a discussion should have been had before moving it, i.e. WS:S should have been consulted before moving from WS to User space, rather than before returning it from User space back to WS space. —Beleg Tâl (talk) 16:58, 4 February 2024 (UTC)

@Beleg Tâl: with an edit in the essay in question gave me permission in private emails to move it into the user subpage. If anyone has any issues, please let the latest host of the essay to follow up. Hopefully it will please everyone peacefully. :-)--Jusjih (talk) 03:29, 14 February 2024 (UTC)

Automatically empty "Without text" pages:

I came across this gadget today and enabled it in my preferences. I've tried it on a number of blank pages but it doesn't seem to work. The examples I've tried only had text in the main box but it wasn't cleared before the page saved. Chrisguise (talk) 00:50, 3 February 2024 (UTC)

@Chrisguise: There's something very weird going on with that Gadget, in that sometimes it completely fails to load for no obvious reason. Usually it loads if you then reload the page, but that kinda defeats the purpose of the Gadget. I'm looking into it, but I'm having trouble figuring out where to start looking. Xover (talk) 08:45, 7 February 2024 (UTC)

@Chrisguise: I think I found the problem. It should work now. Please let me know how it works for you. Xover (talk) 11:26, 18 February 2024 (UTC)

Hi. It seems to work in normal 'create' and 'edit' modes, clearing all content from the main body, header and footer. It doesn't seem to work when I tried it with the 'edit pages in sequence' gadget. Thanks. Chrisguise (talk) 17:29, 18 February 2024 (UTC)

Approximate birth and death categories

When there is just an approximate date of birth or death in Wikidata, the software tries to categorize the author into non-existing categories like category:C. 1390 births, see e. g. Author:Petr Chelčický. I am not sure whether such categories should be founded. Would it be possible to change it so that the authors are categorized directly into category:1390 births? -- Jan Kameníček (talk) 22:24, 18 February 2024 (UTC)

Ah, only now I have noticed that the author is categorized into both categories. So is the approximate date category necessary? Would it be possible to remove such categorization, leaving only e. g. category:1390 births? --Jan Kameníček (talk) 22:27, 18 February 2024 (UTC)

Thanks for catching this! I've updated Module:Author to remove the inappropriate categories. —CalendulaAsteraceae (talk • contribs) 23:19, 18 February 2024 (UTC)

Discourse Concerning the Natation of Bodies

This was just listed as "new". In researching the supporting scan, I discovered that the Commons file simply lists "Internet Archive" as the source, without any specifics. I cannot find the scan there. Can anyone else please locate the source of the scan at Commons? --EncycloPetey (talk) 20:28, 19 February 2024 (UTC)

Possibly extracted from this facsimile? [17] MarkLSteadman (talk) 01:38, 20 February 2024 (UTC)

Tech News: 2024-08

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

• If you have the "Email me when a page or a file on my watchlist is changed" option enabled, edits by bot accounts no longer trigger notification emails. Previously, only minor edits would not trigger the notification emails. [18]
• There are changes to how user and site scripts load for Vector 2022 on specific wikis. The changes impacted the following Wikis: all projects with Vector legacy as the default skin, Wikivoyage, and Wikibooks. Other wikis will be affected over the course of the next three months. Gadgets are not impacted. If you have been affected or want to minimize the impact on your project, see this ticket. Please coordinate and take action proactively.
• Newly auto-created accounts (the accounts you get when you visit a new wiki) now have the same local notification preferences as users who freshly register on that wiki. It is effected in four notification types listed in the task's description.
• The maximum file size when using Upload Wizard is now 5 GiB. [19]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 20 February. It will be on non-Wikipedia wikis and some Wikipedias from 21 February. It will be on all wikis from 22 February (calendar). [20][21]

• Selected tools on the grid engine have been stopped as we prepare to shut down the grid on March 14th, 2024. The tool's code and data have not been deleted. If you are a maintainer and you want your tool re-enabled reach out to the team. Only tools that have asked for extension are still running on the grid.
• The CSS filter property can now be used in HTML style attributes in wikitext. [22]

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

MediaWiki message delivery 15:36, 19 February 2024 (UTC)

Changes to loading user scripts in Vector and Vector 2022

Obsolete information for historical reference.

As announced in Tech News 2024-08 there are changes coming to how your vector.js / vector.css and vector-2022.js / vector-2022.css are loaded. Currently, if you are using the Vector 2022 skin, both the vector and vector-2022 variants are loaded. Starting at some point in the near future (date has not been set yet, but the original ambition was to get it done by the end of 2023 so we're on borrowed time) the Vector 2022 skin will only load the vector-2022 variants.

If you are using the Vector 2022 skin (not on by default, so you must have explicitly turned it on) you will need to migrate the code in your vector.js / vector.css to vector-2022.js / vector-2022.css. You should not do this until the change goes live or the same code will be loaded twice with unpredictable results (unpredictable, but it's very likely your scripts will break in some way).

Once some of the site-wide code affected by this change has been migrated it is likely we will ask for an expedited transition, in which case it will be announced here that it has happened. If that plan doesn't pan out you will have to keep watch for your old scripts to stop getting loaded and migrate then, but we may not be able to announce a specific date when it happens (it depends on upstream communication about the change). In either case it is likely that once the change has been implemented (for all sites, not just enWS) there will be a notice about it in a future Tech News.

If you are using any other skin but Vector 2022 (including original Vector aka. Vector 2010) you should not be affected by this and there is no action needed on your part.

If you have questions or need help migrating your vector.js / vector.css please feel free to post in this thread. --Xover (talk) 13:07, 20 February 2024 (UTC)

Nevermind. This information turns out to be obsolete. Updated information will follow shortly. --Xover (talk) 14:30, 20 February 2024 (UTC)

Second attempt: As announced (extremely subtly through the use of the past tense) in Tech News 2024-08, changes have already been made to how your vector.js / vector.css and vector-2022.js / vector-2022.css are loaded. Previously, if you were using the Vector 2022 skin, both the vector and vector-2022 variants were loaded. Starting at some point in the recent past (I don't have the exact date) the Vector 2022 skin will only load the vector-2022 variants.

If you are using the Vector 2022 skin (not on by default, so you must have explicitly turned it on) you will need to migrate the code in your vector.js / vector.css to vector-2022.js / vector-2022.css or they will not be loaded. There are significant changes to to the skin in Vector 2022 so there is no guarantee that your old scripts will work in the new skin without modifications.

If you are using any other skin but Vector 2022 (including original Vector aka. Vector 2010) you should not be affected by this and there is no action needed on your part.

If you have questions or need help migrating your vector.js / vector.css please feel free to post in this thread. --Xover (talk) 14:36, 20 February 2024 (UTC)

Invitation to join February Wikisource Community Meeting

Hello fellow Wikisource enthusiasts!

We are the hosting this month’s Wikisource Community meeting on 24 February 2024, 7 AM UTC (check your local time).

The meeting agenda will be divided into two halves. The first half of the meeting will focus on non-technical updates, including discussions about events, conferences, proofread-a-thons, and collaborations. The second half will delve into technical updates and conversations, addressing major challenges faced by Wikisource communities, similar to our previous Community meetings.

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

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

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

Sent using MediaWiki message delivery (talk) 11:11, 20 February 2024 (UTC)

Wikisource:Annotations

I'd like to have a straw poll, to resolve the community's stance without discussion on whether or not WS:ANN should be considered official WS policy. This is merely a fact-finding poll, to determine whether or not the community supports this page as policy. This is not intended to be a discussion, as its associated Talk page already has more than enough of that. If largely supported, then I'll start some kind of official !vote; if opinion is divided or against, then at least we'll know, and discovering that is the sole purpose of this poll. --EncycloPetey (talk) 22:17, 3 February 2024 (UTC)

•  Support ---EncycloPetey (talk) 22:17, 3 February 2024 (UTC)
•  Support --Jan Kameníček (talk) 22:40, 3 February 2024 (UTC)
• Support. I don’t see any indication (in the header, anyway) that this is not official, and I was always led to that page when I asked about annotations. TE(æ)A,ea. (talk) 23:26, 3 February 2024 (UTC)
•  Support--Jusjih (talk) 02:37, 4 February 2024 (UTC)
•  Support --Xover (talk) 06:55, 4 February 2024 (UTC)

 Support —Beleg Tâl (talk) 16:56, 4 February 2024 (UTC)

I was under the impression that the policy was made official in 2021 as per this edit and the corresponding discussion. Was that not the case? Arcorann (talk) 10:03, 7 February 2024 (UTC)

Making it policy

Rather than asking everyone to support a second time, since the support seems to be unanimous, I'm going to ask whether there are any objections serious enough to prevent this page from becoming policy. Keep in mind that it is possible to change policy, so if the objection can be corrected with a discussion afterwards, please consider that option as well. This page seems to be considered policy already, but I'll leave this open for at least a week before adding the official tags and such, in case there are serious objections. --EncycloPetey (talk) 19:36, 8 February 2024 (UTC)

Proceeding now with the official action to mark it as policy, based on unanimous support. --EncycloPetey (talk) 19:17, 22 February 2024 (UTC)

Awesome! —Beleg Âlt ^BT (talk) 19:39, 22 February 2024 (UTC)

Combine the {{PD-US}} and the {{PD-US-no-renewal}} templates

There are still many, many authors who have both works that fit into the scope of the {{PD-US}} template and those fit into the scope of the {{PD-US-no-renewal}} template. These templates, when used both on the same page, occupy a plenty of space which both has an inelegant appearance and contains some redundant text. I suggest making the third template (for example, {{PD-US-expire-no-renewal}}) that combines the content of both templates and can be used on pages of such authors (like Lovecraft or Frank Owen) --Nonexyst ^d 14:35, 17 February 2024 (UTC)

@Nonexyst: I definitely agree with the sentiment here, but I'd like to take it a step further and just take the public-domain reasons off of author pages altogether. In other words, perhaps we should just have a template that says something like "This author has works that are in the public domain." (in the usual more formal terms of course)

The part where tagging specific public-domain reasons is actually important is in the individual works themselves. Author pages exist effectively as directories for finding these works, and since we're starting to delve into territory where keeping up with the copyright statuses of all the works within these "directories" is complex and therefore repetitive and redundant, we should just remove that altogether.

This is just another bit of constant maintenance that we don't need. SnowyCinema (talk) 14:45, 17 February 2024 (UTC)

Yeah, let's just drop hyper-specific templates like {{PD-US-no notice}} and {{PD-US-no renewal}} from Author: pages. Author's works are either generally in the public domain, some are in the public domain, some are compatibly licensed, or they are generally still in copyright. More nuance and detail is just noise there (an explanation can go on the talk page if needed; eg. like for Tolstoï and the translations, or the hyper-complicated situation for Lovecraft). Xover (talk) 17:43, 17 February 2024 (UTC)

If we're going to make an author-specific licensing template, the name of the template should make it clear that the template is for use on Author pages, and no resemble the templates we use on works, in order to reduce the likelihood of confusion. --EncycloPetey (talk) 18:33, 17 February 2024 (UTC)

I can see dropping some of the hyper-specific templates, but I don't think we should toss out all of the details. We should have separate templates for authors whose works are generally all in the PD (died 95 years ago), authors who have some works expired due to age, and US authors who may have some works not renewed or no notice. I think it's important to say whether works are generally in the public domain, or if there's more elaborate checking needed.--Prosfilaes (talk) 16:13, 19 February 2024 (UTC)

Just want to say I'm pleased to see this discussion going. Previously I've felt that copyright banners on Author: pages were extraneous and sometimes misleading, but these kinds of refinements would make a big difference. Kudos all. -Pete (talk) 17:54, 24 February 2024 (UTC)

It is not only author pages where both {{PD-US}} and {{PD-US-no-renewal}} may appear, it can happen with some periodical too, see e.g. The World (newspaper). Besides creating a combined template, we could also solve it in a way similar to {{Translation license}}. --Jan Kameníček (talk) 19:12, 24 February 2024 (UTC)

New Gadget: MoreMenu

There's a new Gadget available in your preferences: MoreMenu.

This should be familiar for enWP contributors where it's been available for years. The basic gist is that it adds a new dropdown menu next to the search field (in Vector) with useful links for pages (the "Page" menu) and, on user pages, about the user (the "User" menu). If you have particular rights you may see extra links specific to those user rights (e.g. admins get a few extra links that require administrator rights to see or use).

The Gadget is currently non-default so you need to explicitly turn it on to use it, but going by experience from other projects this is so useful that we'll probably want to turn it on by default once we're sure it doesn't cause any problems here. Xover (talk) 10:53, 24 February 2024 (UTC)

British patents

There is a handful of patents which have been placed on pages of the form GB1893 15805 but with header title "Great Britain patent 15805". I think that these pages should be moved to something clearer, and I think that the mention of Great Britain is incorrect - British or UK. I suggest that the example link should go to "British patent no. 15805", or something like that, and the others moved similarly. Do people agree ? -- Beardo (talk) 02:25, 24 February 2024 (UTC)

Note that GB is the official patent country code: https://www.uspto.gov/patents/apply/applying-online/country-codes-wipo-st3-table. And that is the id at espacent: https://worldwide.espacenet.com/patent/search?q=pn%3DGB189315805A MarkLSteadman (talk) 03:06, 24 February 2024 (UTC)

Note that: https://worldwide.espacenet.com/patent/search?q=pn%3DGB189415805A is also 15805, https://worldwide.espacenet.com/patent/search?q=pn%3DGB189515805A is also 15805, https://worldwide.espacenet.com/patent/search?q=pn%3DGB2361408A is also GB 15805. You will probably need the date in the title at some point, e.g having a versions page once duplicates start appearing. Another option is the patent title "Improvements in or connected with Chest Expanding Braces or Straps." 03:21, 24 February 2024 (UTC) MarkLSteadman (talk) 03:21, 24 February 2024 (UTC)

Thanks. That does seem to imply that the actual patent number includes the year at the start.

And whilst GB might be the reference, "Great Britain" is not correct. -- Beardo (talk) 06:02, 25 February 2024 (UTC)

Index:Cumhadh do dh' iarla Earraghaidhail.pdf

One of the small books from the Scottish national archive - but this one is not in English. Can it be moved to the Gaelic part of wikisource ? -- Beardo (talk) 06:04, 25 February 2024 (UTC)

What does it take to have RELIABLE tools?

Index:NBS_Circular_553.djvu IA Upload- but the OCR is out by one. What does it take to have tools that can RELIABLY do what they claim to? ShakespeareFan00 (talk) 23:18, 9 February 2024 (UTC)

What is more, this bug is really old, see task T194861 founded in 1918! I sometimes come across this problem too, so I ignore the original (shifted) OCR and simply overwrite it using our OCR tools. --Jan Kameníček (talk) 00:11, 10 February 2024 (UTC)

I would love to see this bug fixed! In the meantime, however, the folks at Wikisource:Scan lab are very helpful in fixing the broken OCR generated by IA-Upload. —Beleg Âlt ^BT (talk) 14:22, 26 February 2024 (UTC)

Size of edit window in Page: namespace..

I don't know what changed but the size of edit window in proofread page is now too small to be reasonably useable. Please change it back to the previous setting. Thanks. ShakespeareFan00 (talk) 22:08, 24 February 2024 (UTC)

@ShakespeareFan00: If it helps, in my CSS file I figured out how to control the width of the #textbox1 of the proofread page. Specifying width doesn't work, but margins or padding does. — ineuw (talk) 23:35, 24 February 2024 (UTC)

i find timeless skin can get full width on screen by zooming in. yrmv. --Slowking4 ‽ digitaleffie's ghost 01:18, 25 February 2024 (UTC)

Welcome to endless art of managing one's proofreading page. — ineuw (talk) 01:59, 25 February 2024 (UTC)

such is the open source paradise. i tend to stay away from custom css and java tools, as they are prone to break, interact poorly, and are hard to trouble shoot. i expect tools to break as there is little tool management and support. unsupported skins will eventually break also, but timeless is quite an improvement over flat sidebar gadget, and the skin that does flat sidebar. the wiki software changes are wikipedia focused with many unintended consequences on other projects. the configuration labor is a barrier to entry, making it harder to onboard newbies. --Slowking4 ‽ digitaleffie's ghost 15:12, 26 February 2024 (UTC)

Tech News: 2024-09

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 mobile visual editor is now the default editor for users who never edited before, at a small group of wikis. Research shows that users using this editor are slightly more successful publishing the edits they started, and slightly less successful publishing non-reverted edits. Users who defined the wikitext editor as their default on desktop will get the wikitext editor on mobile for their first edit on mobile as well. [23]
• The mw.config value wgGlobalGroups now only contains groups that are active in the wiki. Scripts no longer have to check whether the group is active on the wiki via an API request. A code example of the above is: if (/globalgroupname/.test(mw.config.get("wgGlobalGroups"))). [24]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 27 February. It will be on non-Wikipedia wikis and some Wikipedias from 28 February. It will be on all wikis from 29 February (calendar). [25][26]

Future changes

• The right to change edit tags (changetags) will be removed from users in Wikimedia sites, keeping it by default for admins and bots only. Your community can ask to retain the old configuration on your wiki before this change happens. Please indicate in this ticket to keep it for your community before the end of March 2024.

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

MediaWiki message delivery 19:23, 26 February 2024 (UTC)

Sister projects:

When did Sister_projects start importing all the main_subject= from Wikidata? RAN (talk) 20:25, 27 February 2024 (UTC)

At approximately 12:31 (UTC) on 12 April 2021. Xover (talk) 21:13, 27 February 2024 (UTC)

• I see by deprecating the main_subject at Wikidata I can suppress their appearance here. If there is a news article about a person getting married, I don't think we need to link to the Wikipedia article on wedding, just the person. --RAN (talk) 22:56, 27 February 2024 (UTC)

• @Richard Arthur Norton (1958- ): Could you link to an example of this? -Pete (talk) 17:45, 28 February 2024 (UTC)

• You can see at Oakland Tribune/1945/06/08/Cited Pilot Home From Italy Is Wed, where I have not yet deprecated "wedding" at Wikidata and it links to the Wikipedia article. The problem is that I overstuff search terms at Wikidata so I can find the article in a Google search, when it should be used only for main_subject. --RAN (talk) 18:17, 28 February 2024 (UTC)
• I solved the problem, the solution appears to be the promote the main search term, rather than deprecate the minor ones. I will do that moving forward. --RAN (talk) 19:34, 28 February 2024 (UTC)

New beta Gadget: Automatically empty Without text pages

There's a new Gadget available in the "Beta" section of your preferences: Automatically empty Without text pages.

This is a really simple little Gadget that watches the page status radio buttons in the Page: namespace and when you click the "Without text" one it empties out any stray automatic headers and footers as well as OCR text that may be in the page. It also saves away the text that was there so that if you click it by mistake you can just click any other pages status radio button to get the contents back.

The Gadget has been available for a while but was plagued by a "mystery bug" that made it fail to do anything most of the time. This problem should now be fixed (/me crosses fingers) and some wider testing would be useful. In my own experience this functionality is so useful that it's a no-brainer to make it default for all users, but it started life as my personal user script and hasn't had sufficient testing yet (feedback on this if you have an opinion would be welcome). Xover (talk) 11:02, 24 February 2024 (UTC)

Nice! You're right it really should be default feature. Jpez (talk) 06:02, 29 February 2024 (UTC)

Wikidata questions

There are a few points that don't seem to be covered in Wikisource:Wikidata:

• Work and edition items: how does this work when there's only one version? What do we do with the links?
• How do we handle periodicals and issues of periodicals?

(Also once these get resolved can we update the page?) Arcorann (talk) 09:58, 23 February 2024 (UTC)

The work is more generic than editions. Works have different "outside information" than editions, which helps to keep the two separate. Works are instances of "literary work" or "work of science". Works might have a publisher, but be sure to only put the publisher of the first edition on it. Editions often have different publishers. A work should never have a property pointing at a scan or the gutenberg publication of the same or of an edition in the local library. Each of those would be an instance of "version, translation or edition". The edition gets the url to the wikisource index and the work gets the Main space link. It doesn't matter if there is only one edition. Editions link to the work via "edition of" and works link back to the edition via "Edition or translation of". Everything here that is in quotes has a property number at wikidata, but a few characters typed into the property area at wikidata will usually pull up the property you are looking for, if you are not a machine.

Magazines and journals are a mess of the same thing. Each freaking issue getting a work and at least one edition. Each issue reaching to its volume and each volume reaching to its first data, that states the beginning publication date, and the end date. Many of the journals have this information but it is under the "inception" property as is the wikipedia way. Adding publication date information makes those records useful for wikisource.

About adding this to the help. There are a million ways to say something but nothing works quite as well as experience. A very very helpful thing for me in figuring this out was to make the data and the {{Book}} template work on the scan, the scan being the edition that is used here. And then making the category at the commons and putting the link to that on the Work data. The book template has places for many things that should be found as edition properties at wikidata. The category needs the place of first publication, and the year [[Category:1928 books published in the United States]] and [[Category:Books published in Massachusetts]] or New York City or Boston. Those categories are about the licence, at least the year and country. The later, I guess, being interesting. Well, the {{Book}} template and getting everything installed at commons was very helpful to me in working through the wikidata that gets connected to it. It might help you also.--RaboKarbakian (talk) 15:12, 23 February 2024 (UTC)

As Rabo points out, periodicals are a real morass of challenges from a data perspective, and Wikisource has to deal with many of the same issues. I'm not sure which are bothering you at the moment, but some that really bug me are:

• What constitutes a distinct periodical? Are The Herald, The Weekly Herald, The Sunday Herald, The Herald Town & Country Monthly Insert, The Springfield Herald, and the Metro County Herald different names of the same publication, or five separate publications? How about the Times-Herald, formed after a merger? Other databases/authority controls such as the U.S. Library of Congress seem to err in the direction of making a separate data record for each title variant, but there are often important qualities of a publication that span many names (same publisher, same status as "only paper in town with unique social/political influence," etc.) that are harder to capture that way. The specifics of every publication's unique history are an important factor, and coming up with a general rule that is workable and accurate seems impossible. The Overland Monthly is a magazine that contends with these issues; I put several different name variants all on one Wikisource page, which I think is the least-bad approach and probably the most useful to a reader (but maybe not a data-oriented researcher), but still not very satisfying.

(oops, I left out the main point I was after: the audience and purpose of Wikidata might lead to different approaches for Wikidata vs. Wikisource vs. Wikipedia, but even that is an issue, because how do you link them? Especially with publications with numerous name changes, some innocuous and some substantive... -Pete (talk) 19:35, 23 February 2024 (UTC) )

• Our templates are largely designed with books in mind. There's no header template to capture an overall publication (such as year started/year ended, founder, predecessor, successor), and no header template for individual volumes or issues (month, day of month, etc.) "Year" as the only available template parameter in {{header}} does not fit well with periodicals
• With some periodicals, especially newspapers, it's unclear the best framework for more granular pages. Below the top level, do we organize by year or volume number? Sometimes volumes span two years, other times there are two volumes per year, so it's a fundamental question. Below that, do you go with "/12 May 1902/" or "/1902/May/12" or something in between? Even with daily naming, what about a newspaper with separate morning and evening editions?
• Copyright status is supposed to be asserted at the top level page, but this can result in weird collections of templates that are messy and not very informative without careful reading. See The Overland Monthly for an example of this too.

Some of this is addressable by developing more bespoke templates here. If you're interested in working with me on that, I'd suggest Wikisource talk:Periodical guidelines as a place to dig into what's needed and develop specs/proposals.

Also, if you haven't, I'd suggest consulting periodical-related WikiProjects on other projects, such as wikidata:Wikidata:WikiProject Periodicals and w:en:Wikipedia:WikiProject Newspapers. -Pete (talk) 19:21, 23 February 2024 (UTC)

Arcorann this should be the best help for publications at wikidata: wikidata:Wikidata:WikiProject_Books They have not updated about oclc classify being superceded, but, these tables are really good.--RaboKarbakian (talk) 15:20, 24 February 2024 (UTC)

What about Wikisource links on Wikidata? In particular, if we have only one edition for a work (so no versions page), and we link the work to the edition page, does the work entry just not get a Wikisource link? Arcorann (talk) 09:31, 28 February 2024 (UTC)

Arcorann: Link the Main page (transcluded work) to the "work" and there is a property P1957 "Wikisource index page URL" that goes with the scan edition.--RaboKarbakian (talk) 16:18, 28 February 2024 (UTC)

So to confirm, both the work page and edition page on Wikidata have the same link, with the link on the work page on Wikidata being changed when a versions page is made? Arcorann (talk) 00:56, 11 March 2024 (UTC)

No. The edition of a work (housed at Wikisource) goes on the data item for that edition, with information and links for that edition. The "work" data item is the generic information such as original date of writing, original language, and links to the work data records at VIAF and the Library of Congress as well as for other databases. Any information that is specific to a particular publication should go on a data item for that particular edition/publication. This includes the first edition of a work, which should also have a data item for it. This mirrors the format used internationally for major library databases: one data item for the generic information, separate data items for each edition of that work that has been published. It must be done that way so that we can record all data specific to the edition such as publisher, publication date, location of scans, and holdings of that edition in libraries. The edition data item gets crosslinked to the work data item using P747 (has edition or translation) from the work and P629 (edition or translation of) from the edition. What RaboKarbakian has told you is the nonstandard maverick approach he uses, and not the recommendations followed by everyone else.

Periodicals are sometimes handled differently, because they do not have multiple editions, though some periodicals now have print editions and electronic editions of articles, but what I've described is true for most editions of other kinds of things. --EncycloPetey (talk) 01:31, 11 March 2024 (UTC)

OK, we all agree that the edition page on WD and the work page on WS should be linked. If a versions page exists on WS then it should be linked to the work page on WD; that much is clear. What I'm still confused about is what (if anything) should be linked to the work page on WD if no versions page exists on WS. Arcorann (talk) 08:10, 12 March 2024 (UTC)

Template:Beleg Tâl's sidenotes

There are too many sidenote templates on this website, so I've decided to add yet another :D

It is my hope and belief, that someday English Wikisource will have a standard general-purpose approach to sidenotes. At that time, this template should be replaced with the adopted standard template.

In the meantime, you can use this template as a placeholder to indicate a sidenote that should be standardized once a standard has been created. The actual formatting of the sidenotes in the meantime may vary. (Currently it uses {{right sidenote}}.) —Beleg Âlt ^BT (talk) 14:17, 26 February 2024 (UTC)

I was originally going to call this template Template:Generic sidenote, but I decided to give it a name that clearly indicated that it shouldn't be treated as an alternative permanent approach to sidenotes —Beleg Âlt ^BT (talk) 14:18, 26 February 2024 (UTC)

@Beleg Tâl: I feel your pain, but I think it is a very bad idea to put a username in any page name outside User: space, I think it's a very bad idea to make temporary placeholder templates, and I think it is a very bad idea to react to a proliferation on half-broken templates by adding yet another deliberately half-broken template.

I might suggest a more productive channel for that frustration is collecting a structured description of use cases along with problems with existing templates somewhere. It is conceivable that we'll be able to "solve" (fsvo) this eventually, but it will at very least require that the issue works its way up to the top of someone's list of annoyances, and for that a structured description of the use cases and problems will be essential. Xover (talk) 09:43, 27 March 2024 (UTC)

As it happens, in this case there is no pain or frustration. I created a formatting-agnostic template because we didn't have one and we needed one; and I made it a placeholder template because we don't have community consensus (yet) on what a formatting-agnostic sidenotes template should look like and how it should work.

You do make a good point, however. Perhaps it would be better if, instead of a placeholder template that should be replaced when consensus is reached, I were to make it a permanent template that should be modified and updated with whatever behaviour is decided upon? Alternatively, I could just rename it, to at least remove the username as an issue. What do you think of this?

As for compiling the issues and use cases of the various existing sidenotes templates—that has already been done in much detail elsewhere (primarily by @ShakespeareFan00), and I do not think that this thread is the place for rehashing that whole discussion. I merely intended to inform the community of the template I created so that works containing sidenotes could still be proofread in the meantime. —Beleg Âlt ^BT (talk) 17:42, 28 March 2024 (UTC)