Wikisource:Scriptorium/Archives/2023-07

Please do not post any new comments on this page. This is a discussion archive first created in July 2023, although the comments contained were likely posted before and after this date. See current discussion or the archives index.

Not proofread icon has changed

The "not proofread" icon that shows at the top of a page, and which is triggered by settings of Wikidata, has changed from the pink checkmark to a different icon: the "Escudo_de_Felipe_VI_de_España". --EncycloPetey (talk) 18:22, 6 July 2023 (UTC)

@EncycloPetey: Vandalism (or a very confused user) at Wikidata. I've reverted it. Xover (talk) 18:46, 6 July 2023 (UTC)

Thanks. I wasn't sure where this was coordinated from. --EncycloPetey (talk) 18:50, 6 July 2023 (UTC)

This section was archived on a request by: --EncycloPetey (talk) 20:45, 6 July 2023 (UTC)

Tech News: 2023-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.

Recent changes

• As part of the rolling out of the audio links that play on click wishlist proposal, small wikis will now be able to use the inline audio player that is implemented by the Phonos extension. [1]
• From this week all gadgets automatically load on mobile and desktop sites. If you see any problems with gadgets on your wikis, please adjust the gadget options in your gadget definitions file. [2]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 4 July. It will be on non-Wikipedia wikis and some Wikipedias from 5 July. It will be on all wikis from 6 July (calendar).

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

MediaWiki message delivery 22:51, 3 July 2023 (UTC)

Allow YouTube link in authority control template

On video items, Wikidata allows links to the YouTube video ID (property P1651), for example, on the item for the US Gov film How to Become President of the United States (at Q118106572). However, our {{authority control}} template does not seem to support that property. Can anyone add functionality for it so that the ID can appear on certain film pages? I know that YouTube itself isn't a very durable platform, but it can still be useful. Thanks. PseudoSkull (talk) 19:00, 6 July 2023 (UTC)

I think that is a low value addition and don't see that it is sufficiently universal for addition. Not in favour. — billinghurst sDrewth 14:05, 7 July 2023 (UTC)

@Billinghurst: What harm would it do to add it? And how is it not "sufficiently universal" in your view? PseudoSkull (talk) 20:06, 8 July 2023 (UTC)

I am not certain how you define universal, but I doubt that for either our author or our main namespace pages would have these, so it is of very limited scope, and as you said yourself it is not a durable or resilient link. If that is the source of the work, then we should link it through the edition point to the respective talk: page and set up a parameter to call it if it is on the WD item. I also don't think that we want to over-populate that template, it is ideally meant to be priority links (not that we have had a really good conversation about the template and its links in recent years.) — billinghurst sDrewth 00:34, 10 July 2023 (UTC)

Moving raw scans to Commons

This discussion is moved from #License_templates_on_files to this place because it should not "be hidden" under a heading signaling something else. --MGA73 (talk) 12:17, 9 July 2023 (UTC)

• I checked 2 random files: File:First Footsteps in East Africa, 1894 - Volume 2.djvu-12.png and File:Proceedings of the United States National Museum, Volume 76.djvu-685.png. They look okay to me so according to the message given to me in discussion mentioned above I should tag with {{sdelete|A1 transwikied}}. Can you think of anything missing or do you agree it is okay to delete now? --MGA73 (talk) 19:15, 8 July 2023 (UTC)

  @MGA73: 👍🏻 Xover (talk) 20:28, 8 July 2023 (UTC)

  Xover, great. I noticed that some files like File:A short guide to Syria (1943).djvu-10.png was fixed by uploading the edited version on top of the original file. That make me think that perhaps another way to fix this could be to move all the raw scan pages to Commons and have users do the crop, rotation and edits there. We would perhaps need a special template to add on all the files to edit asking for people to help edit and inform them that it is a good idea to upload the edit on top (which Commons usually do not prefer but since the original image is stored in file history and the main djvu then its fine to overwrite). I have a theory that all the users on wikisource that like to edit files could be persuaded to go to Commons and help fix, but not all the users on Commons that like to fix files know that wikisource have files that needs to be fixed. What do you think? (I know that it would require some work to find a working solution that would make FileImporter accept and transfer files to Commons with a good result. But there is also a lot of work if it is all done manually one file at a time.) --MGA73 (talk) 11:30, 9 July 2023 (UTC)

I have modified configuration file for FileImporter so right now it is possible to move files to Commons. I have not fixed it so it will add a license template. The files end in c:Category:Raw page scans for missing images.

For this to work the easiest would be to modify c:Template:Raw page scan for example so it suggest to upload new file on top and then rename file instead. It should also ask user to copy "information" template from original .djvu to replace "Raw page scan" template. --MGA73 (talk) 12:17, 9 July 2023 (UTC)

This is all very well, but some of us prefer to rederive images from the jpg2 files on IA and ignore these raw page scans in png format. As far as I'm concerned the raw png files are simply placeholders and will be disposed of when a proper image is made available. Additionally, we have 4159 pages in the relevant maintenance category. How will that work if the files aren't here on enWS? Beeswaxcandle (talk) 18:02, 9 July 2023 (UTC)

Per Beeswaxcandle, they are only meant to be placeholders, and there is a large conversation back in 2012, 2013 about it. The colouring, the format, the identification of the illustrator, the metadata and naming is all meant to be fixed. If a single page there is suitable to go over, then it can be individually have its info updated to suitable style to Commons and imported. There is not consensus for that change MGA73 please revert. — billinghurst sDrewth 22:50, 9 July 2023 (UTC)

Okay so everyone do not think editing the png is the best alternative. But some files like File:A short guide to Syria (1943).djvu-10.png were edited and a new version was uploaded locally. If edit on FileImporter is reverted then such files can’t be moved to Commons. So should those files be moved to Commons before a revert? Or should the upload of the new version be reverted too? --2.130.56.140 04:48, 10 July 2023 (UTC)

Huh? Of course they can be moved to Commons, I said that. However, fix up the file information first to a form that Commons allows with a copyright tag that Commons allows. All our File edit pages give you a pasteable copy of the {{information}} template, so just make the necessary changes. When moved to Commons, please make sure that it gets moved to a sensible name (eg. File:Bargaining takes time (A short guide to Syria, 1943).png), not one that reflects a scan number of a scan. We also did NOT say not to use a PNG, we said that these PNG of the pages are not the best available quality, and they typically need clean up. — billinghurst sDrewth 08:34, 10 July 2023 (UTC)

Roger that! Personally I would think it was easier to move first and copy paste information template, license and categories on Commons :-)

Feel free to archive this section. --MGA73 (talk) 11:59, 10 July 2023 (UTC)

Tech News: 2023-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

• The Section-level Image Suggestions feature has been deployed on seven Wikipedias (Portuguese, Russian, Indonesian, Catalan, Hungarian, Finnish and Norwegian Bokmål). The feature recommends images for articles on contributors' watchlists that are a good match for individual sections of those articles.
• Global abuse filters have been enabled on all Wikimedia projects, except English and Japanese Wikipedias (who opted out). This change was made following a global request for comments. [3]
• Special:BlockedExternalDomains is a new tool for administrators to help fight spam. It provides a clearer interface for blocking plain domains (and their subdomains), is more easily searchable, and is faster for the software to process for each edit on the wiki. It does not support regex (for complex cases), nor URL path-matching, nor the MediaWiki:Spam-whitelist, but otherwise it replaces most of the functionalities of the existing MediaWiki:Spam-blacklist. There is a Python script to help migrate all simple domains into this tool, and more feature details, within the tool's documentation. It is available at all wikis except for Meta-wiki, Commons, and Wikidata. [4]
• The WikiEditor extension was updated. It includes some of the most frequently used features of wikitext editing. In the past, many of its messages could only be translated by administrators, but now all regular translators on translatewiki can translate them. Please check the state of WikiEditor localization into your language, and if the "Completion" for your language shows anything less than 100%, please complete the translation. See a more detailed explanation.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 11 July. It will be on non-Wikipedia wikis and some Wikipedias from 12 July. It will be on all wikis from 13 July (calendar).
• The default protocol of Special:LinkSearch and API counterparts has changed from http to both http and https. [5]
• Special:LinkSearch and its API counterparts will now search for all of the URL provided in the query. It used to be only the first 60 characters. This feature was requested fifteen years ago. [6]

Future changes

• There is an experiment with a ChatGPT plugin. This is to show users where the information is coming from when they read information from Wikipedia. It has been tested by Wikimedia Foundation staff and other Wikimedians. Soon all ChatGPT plugin users can use the Wikipedia plugin. This is the same plugin which was mentioned in Tech News 2023/20. [7]
• There is an ongoing discussion on a proposed Third-party resources policy. The proposal will impact the use of third-party resources in gadgets and userscripts. Based on the ideas received so far, policy includes some of the risks related to user scripts and gadgets loading third-party resources, some best practices and exemption requirements such as code transparency and inspectability. Your feedback and suggestions are warmly welcome until July 17, 2023 on on the policy talk page.

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

MediaWiki message delivery 19:53, 10 July 2023 (UTC)

504 Gateway Time-out on WS export page

Tracked in PhabricatorTask T335553

For the past 30 minutes or so, the WS export page (https://ws-export.wmcloud.org/) has been giving me the following error:

504 Gateway Time-out
nginx/1.18.0

Has anyone else been experiencing this? And @Samwilson: Might this have anything to do with the recent disambiguation-related change you mentioned earlier? (Thanks for pushing forward on that btw!) PseudoSkull (talk) 22:52, 13 July 2023 (UTC)

@PseudoSkull: It does suffer for pretty poor responsiveness (see the uptimerobot stats). It has previously run out of storage space, but that's not the case now. It looks like it's just getting lots of traffic — perhaps from a bot that we've not yet managed to put on the denylist. I'll look into that now, but at least now it's up and working again. Thanks for reporting! Sam Wilson 01:11, 14 July 2023 (UTC)

Problems with newly uploaded files (mostly PDF's)

I have suffered repeated problems with files I upload to Commons and their display in Wikisource (mostly PDF's but occasionally DJVU). I will use File:The life and opinions of Tristram Shandy (Volume 3).pdf as an example.

I have previously transcribed vols 1 and 2 of this 9 volume work, but the volume 3 scans are so degraded as to be largely illegible. To try and fix this, I downloaded each of the page images from the source (as JPEG's) and combined them into a single PDF (I have an up-to-date, legitimate version of FoxitPDF Editor and also a legitimate but somewhat elderly version of Adobe Acrobat). In both cases, this resulted in a file size over the 100MB limit for Commons, so I set about reducing the file size. Oddly, using the standard tool in both pieces of software collapsed the 128MB file to one of about 3MB with the same very poor quality as the original file on Commons. Much the same thing happened if I processed it to DJVU (using PDF 2 DJVU converter). After multiple failed attempts to achieve a good quality result, I gave up and printed the 128MB PDF to 'Print to Microsoft PDF'. This produced a c.48MB file which is very close to the original JPEG's in quality. I uploaded it as a replacement on Commons.

However, this file will not display in Wikisource. On Index: The life and opinions of Tristram Shandy (Volume 3).pdf it appears as a hyperlinked file name; on individual pages there is no image; and if I attempt to edit a page, a pop-up appears saying 'Failed to initialise OpenSeadragon, no image found'.

If I go to the Wikisource page holding the file (File:The life and opinions of Tristram Shandy (Volume 3).pdf), there is no thumbnail, only a logo icon and a hyperlink. It gives the correct file size and number of pages but states the page size as 0 x 0 pixels, as it also does in the file history at the bottom of the page.

If I click on the hyperlink, it takes me to the Commons page for the file. This is displaying all information correctly (i.e. page images, file size, page size and number of pages). If I re-download this file from Commons, it opens and displays properly in Abode Acrobat (both editor and reader versions), FoxitPDF (both editor and reader versions) and SmallPDF.

As I say, I have had this problem with other uploaded PDFs (mostly file fixes, as I usually use DJVU for my own new uploads). Does anyone have any suggestions as to the cause of the problem and how to rectify it? Chrisguise (talk) 07:34, 12 July 2023 (UTC)

If these PDFs are from IA, and the files are more recently accessioned files there, then I suspect it is tied to IA's decision to cease their high-powered processing in favor of a quicker and less vigorous process. Where I have used such recently acquired PDFs, the text layer is terrible, and the scan quality is poorer than in the past, so much so the OCR often can't convert the scan into a new transcription. For key texts, I've asked for a new text layer and a DjVu rather than work with the awful PDF. This doesn't provide a solution, but may point to a common cause. --EncycloPetey (talk) 07:40, 12 July 2023 (UTC)

In the particular case I mention there isn't any involvement with IA. The JPEG's were sourced from the Cambridge University library website and the PDF was uploaded directly to Commons. Chrisguise (talk) 08:46, 12 July 2023 (UTC)

I've encountered issues when I was trying to insert some placeholders. For some reason, the serving of the thumbnails from Commons ends up cached with the "0 page version" and then the wikisource copies fail to render even while the commons one are fine. After purging ant then waiting a few days it resolved itself to be able to pull in the updated version and rendered on WS. MarkLSteadman (talk) 12:46, 12 July 2023 (UTC)

I have also faced the same issues when uploading PDF files to Commons, usually when uploading new versions after fixing a file (no images, page size 0x0 pixels etc). I use a free trial version of Master PDF editor, which I believed was responsible for the issue, but if issues persist even with other editing software, I'd love to know if there's a solution out there. What do our Scan Lab members use?

For new uploads, I would suggest (without compressing the file so quality is preserved) first uploading the file to IA since it has a higher size limit , and then using IA-upload to upload the file as DJVU to Commons. This method is a bit more involved but it has served me well. Ciridae (talk) 11:42, 12 July 2023 (UTC)

@Chrisguise: That's horrible. I hope this gets squared away. I would also suggest bringing this up at Wikimedia Commons, because they might have a better idea as to the problem here. PseudoSkull (talk) 14:31, 12 July 2023 (UTC)

@Ciridae @EncycloPetey @MarkLSteadman @PseudoSkull Thanks all for your feedback. For whatever reason the file is now OK (index page displaying thumbnail and individual page images there too). I have raised this issue on the Commons forum. Chrisguise (talk) 15:13, 12 July 2023 (UTC)

Note that I purged both the commons and WS versions, which might have fixed it. MarkLSteadman (talk) 15:33, 12 July 2023 (UTC)

Yeah, I've found that a hard purge or simply waiting a few days sometimes works. Ciridae (talk) 05:40, 13 July 2023 (UTC)

@EncycloPetey@MarkLSteadman@PseudoSkull@Ciridae I previously looked for an option in Commons to do a purge but I guess my user privileges don't stretch to that option. Chrisguise (talk) 09:33, 13 July 2023 (UTC)

@Chrisguise It isn't provided as an "option" by default. You need to append ?action=purge to the url or enable a special gadget [[8]] MarkLSteadman (talk) 21:49, 13 July 2023 (UTC)

@Chrisguise, @MarkLSteadman: There is a file purge button at the top right of every Index: page. Click on the black circular arrow. It works evenwhen the file is on Commons. Beeswaxcandle (talk) 18:46, 14 July 2023 (UTC)

merging proposal for ws templates at en-wiki

May I please ask to take a closer look at the proposal at en-wiki to merge template: ws-author and ws? I do not really have a sharp view of the differences, but to me it seems these are completely different parts of our work, at least different namespaces. What are the consequences, now and in the future, of merging? --Dick Bos (talk) 08:27, 9 July 2023 (UTC)

If they do it with the facile approach of "let's merge" then it will screw the pooch. If they are going to do it with a sophisticated means of checking WD, and laying paths to follow property/item paths as we do based on main subject, and to know that there is also inter-language, then we may get something of value. That said until we get better data in WD for our items, and put in main subject, we are still setting ourselves up to manual slave labour. I have made comment there. — billinghurst sDrewth 00:05, 10 July 2023 (UTC)

As some here may recall, over the years I have had fundamental (sometimes bitter!) disagreement on policy matters with Andrew, to the extent I largely withdrew from the community in personal protest.

However, in this particular case, I earnestly believe sDrewth got it entirely right! 03:38, 16 July 2023 (UTC) (once/was AuFCL)

That discussion was closed two days ago. Wikipedia has decided to merge the templates. --EncycloPetey (talk) 21:04, 16 July 2023 (UTC)

They have the right to do as they need to do to effectively manage their templates, as we did when we retired the templates that pointed there, and how we now encourage linking to WD via {{wikidata link}} and through fields in headers. I will note that the decision to merge also is not converting to a redirect, it is about a considered plan where there was the firm suggestion to consult with us. We can hope that whomever takes up the mantle whenever does it as suggested. — billinghurst sDrewth 10:30, 17 July 2023 (UTC)

Download link appears in disambiguation pages where it shouldn't

Tracked in PhabricatorTask T273708

On {{Disambiguation}}, {{Versions}}, and {{Translations}} pages, the Download button appears where it really shouldn't. These are not works, so a download is not at all necessary.

We previously had a discussion about this with redirect pages, but I can't find it. The solution looks like it was to make it download the page that it redirects to (for example: if you try to download from the Safety Last redirect page, it downloads Safety Last! instead). But IMO for disambig pages of all sorts, we should strip the download button off entirely, if that's technically possible. PseudoSkull (talk) 21:07, 10 July 2023 (UTC)

What then is the purpose of the Download? To provide an off-line copy to the reader? Some Versions and Translations pages have quite a lot of content, because of the number of versions / translations listed. See Hamlet (Shakespeare) and The Souls of Black Folk to name just two. --EncycloPetey (talk) 22:03, 10 July 2023 (UTC)

It's to provide an e-book for a work in PDF/EPUB/etc. form, for those interested in reading it as an offline book. So it's for works, not disambiguation. As it says on an exported PDF footer: "This e-book comes from the online library Wikisource." An exported disambiguation page is not an ebook. PseudoSkull (talk) 23:52, 10 July 2023 (UTC)

@Inductiveload: Did we ever discuss this together? PseudoSkull (talk) 16:00, 12 July 2023 (UTC)

There's task T273708 where some ideas for how to best do this were discussed. If it's all disambig pages on every Wikisource, then that's not a big thing to change (but might require some wider communication? I'm not sure). Sam Wilson 06:34, 13 July 2023 (UTC)

@EncycloPetey, @PseudoSkull: I made a patch for that, and Tpt merged it just now, so disambiguation pages will now not get the download button. Hope that's the right action! I didn't think it'd be done so quickly (but it's easy to undo again if need be). Sam Wilson 08:01, 13 July 2023 (UTC)

Does it really matter? If someone wants to download a disambiguation page, is it really a problem? I mind not either way, I think that there are bigger issues. — billinghurst sDrewth 10:24, 17 July 2023 (UTC)

@Billinghurst: It's not a problem to download a disambig page, I guess, but it's probably also not very useful for most people. Perhaps they expect to get an ebook with all of the disambiguated pages in it, or maybe just the top one; e.g. someone clicking 'Download' on Emma might be expecting to get an ebook of Emma (Austen) but instead they get nothing but a four-point list. I don't really have an opinion, but it's been requested a few times that disambig pages be excluded so it seemed easiest to do it. Sam Wilson 06:30, 18 July 2023 (UTC)

@Samwilson: diff just put the actual string of the magic word that's supposed to be there on every disambiguation page. Is there something I'm missing here? PseudoSkull (talk) 06:12, 18 July 2023 (UTC)

@PseudoSkull: Sorry, I should've been clearer! The __NOWIKISOURCEDOWNLOAD__ isn't actually implemented yet (it's still to be worked on). The above change instead removed the download button from all disambig pages (via a different mechanism, not a magic word, and so there's no need to make any changes to any templates). This change will be deployed to this wiki from 2023-07-19 18:00. Sam Wilson 06:23, 18 July 2023 (UTC)

Stats tool not working

The Proofread Stats Tool at does not work. Is there any issue --Meghdhanu (talk) 02:24, 19 July 2023 (UTC)

@Meghdhanu: You will need to talk to the operators of the tool at Toolforge. We don't manage it nor have any better control of it. — billinghurst sDrewth 06:24, 19 July 2023 (UTC)

@Meghdhanu: A vigorous application of lateral force was required. Such has now been supplied. Xover (talk) 08:10, 19 July 2023 (UTC)

Tech News: 2023-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.

Recent changes

• We are now serving 1% of all global user traffic from Kubernetes (you can read more technical details). We are planning to increment this percentage regularly. You can follow the progress of this work.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 18 July. It will be on non-Wikipedia wikis and some Wikipedias from 19 July. It will be on all wikis from 20 July (calendar).
• MediaWiki system messages will now look for available local fallbacks, instead of always using the default fallback defined by software. This means wikis no longer need to override each language on the fallback chain separately. For example, English Wikipedia doesn't have to create en-ca and en-gb subpages with a transclusion of the base pages anymore. This makes it easier to maintain local overrides. [9]
• The action=growthsetmentorstatus API will be deprecated with the new MediaWiki version. Bots or scripts calling that API should use the action=growthmanagementorlist API now. [10]

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

MediaWiki message delivery 23:08, 17 July 2023 (UTC)

Noting that from next week the pagequality-validate user-right will be required to validate pages. This should not cause any significant disruption however, since the right is given to all users by default. More info at T341428. Sohom (talk) 06:45, 18 July 2023 (UTC)

@Sohom Datta: Essentially you are saying that accounts in "users" (all our editors) will have a new right pagequality-validate showing in special:ListGroupRights alongside Modify page quality flag (pagequality) and at this stage it will have no editing impact here. It does give us the potential to separately manage the process for moving pages to "validated" per Help:Page status. — billinghurst sDrewth 01:32, 19 July 2023 (UTC)

Yep, that is a better explanation of what I meant :) Thanks Sohom (talk) 02:37, 19 July 2023 (UTC)

Was there a process for applying for 'revocation' of this new user-right? ShakespeareFan00 (talk) 14:23, 20 July 2023 (UTC)

Once it is implemented, then make a request at WS:AN with cogent reasoning why you don't want the right and it will be considered. Beeswaxcandle (talk) 18:32, 20 July 2023 (UTC)

No, that is not possible, rights are tied to the user type(s), see special:usergrouprights (groups with rights). We can only move rights between user types, however, we cannot individually remove user-rights. Anyway, why would we want to do so based on an individual? We have cogent conversations about user types, and we have cogent conversations for moving people between user types, automatically or manually (per special:userrights), as we have always done. — billinghurst sDrewth 00:58, 21 July 2023 (UTC)

frameless

Our Help:Images page recommends including frameless as part of the syntax. Doesn't that merely cause a default size to be the same as a thumbnail? Is there any functional benefit to including that syntax if the image display size is specified? --EncycloPetey (talk) 02:56, 19 July 2023 (UTC)

So far as I know, without really digging into it, no. Xover (talk) 08:11, 19 July 2023 (UTC)

Concur it sets it to a thumbnail size if left without measurement, so pointless when it is not needing thumbnailing/other control. I reckon that if we dug into it, it would be ancient guidance and reflecting a time when we weren't using ProofreadPage.

“	The frameless option causes a plain picture to default to the same size as a thumbnail. As with thumbnails, the default can be adjusted with the upright=factor option. If you use the common default of 220 pixels for thumbnail widths, the following example image's width will be 220 × 0.2 pixels, which rounds to 40 pixels:	”
—w:Help:Pictures

I reckon that we can remove that aspect as it doesn't apply any more. — billinghurst sDrewth 03:31, 21 July 2023 (UTC)

Hyphenated word across a page break not connecting

Copied from a discussion I've been having. I am seeing the same error, and cannot determine why. Its n the first paragraph, which spans from section 2 from the first page of the chapter, onto the second page of the chapter. The word ambi- tion isn't connecting. I've tried swapping out the header tag for a template, I've tried making sure there is the correct kind of hyphen, that there is no stray character at the top of the second page. I've also tried transcluding the full first page instead of just the desired section, and have done purges. --EncycloPetey (talk) 21:11, 20 July 2023 (UTC)

• EncycloPetey: Thanks, but when I exported Middlemarch to an epub (before I made this change), it left the hyphenated word in the text as "ambi- tion". Is this possibly a bug in the epub generation software? Harris7 (talk) 20:59, 19 July 2023 (UTC)
  • EncycloPetey: Another data point: when I view chapter 1 here: Middlemarch_(1874)/Chapter_1 it also renders this as "ambi- tion" (about midway through the first paragraph).

• If you are seeing an error, then you should report it in the Wikisource:Scriptorium, as that bug would affect hundreds of works. --EncycloPetey (talk) 20:44, 20 July 2023 (UTC)

  There are two possible issues I can see that might be causing the problem:

  (1) The first page is a transcluded section, not the full page, and that might be a unique problem to be solved.

  (2) The header tag is being used instead of the full {{header}} template. --EncycloPetey (talk) 20:48, 20 July 2023 (UTC)

• I've tried a number of things to try to identify what is causing the issue, but can't find it. A Scriptorium discussion might turn up the cause. --EncycloPetey (talk) 20:50, 20 July 2023 (UTC)

Done Thanks to ShakespeareFan00 (talk • contribs) for finding and correcting the issue. A carriage return before the end-of-section meant that the hyphenation did not collapse as it should. --EncycloPetey (talk) 21:39, 21 July 2023 (UTC)

Can we not allow some cases of cross-namespace page redirects?

Context: User talk:PseudoSkull#Nathan Hale.

I've been notified on my talk page by EncycloPetey that my creation of Author:Nathan Hale to redirect to the disambiguation page Nathan Hale (which includes both works and author pages, and where consensus is to do it this way) is wrong, because cross-wiki page redirects are a speedy deletion criterion.

It seems like EncycloPetey's opinion on the matter, and the opinion of whoever wrote the speedy-deletion criterion, is that cross-wiki redirects should be explicitly banned in every case. Why? There's really no good reason for it to be a catch-all rule. Namespaces are just arbitrary technical distinctions at the end of the day, and if a redirect across namespaces is helpful (which I think in my case it was), then IMO it has a place. I've dug up some more examples of cross-wiki redirects that already exist, most of which were not created by me and all of which I think would not be considered controversial:

1. 1911 Encyclopædia Britannica/Project Disclaimer -> Wikisource:Project disclaimers/1911 Encyclopædia Britannica (literally created because of a community consensus to do so)
2. Author:Anonymous -> Portal:Anonymous texts
3. Sherlock Holmes -> Author:Arthur Conan Doyle/Sherlock Holmes
4. The Tatler (New York) -> Portal:The Tatler (New York) (fixed)
5. Wikisource -> Wikisource:About
6. Wikisource:Redirects -> Help:Redirects
7. Sandbox -> Wikisource:Sandbox

Pinging @Billinghurst: who also participated in the above talk page discussion. PseudoSkull (talk) 23:20, 20 July 2023 (UTC)

•  Comment I see lots of discussion about the issue in the links you provided, but no actual consensus. This issue resurfaces every so often without any resolution to make a decided change. --EncycloPetey (talk) 23:35, 20 July 2023 (UTC)

@EncycloPetey: Regardless of the direct outcome of those discussions, using a mainspace redirect is a tangible solution that both works and structurally makes sense. The only reason I've been presented to oppose this structural multi-namespace disambiguation model that makes sense, and the redirect issue that is the topic of this discussion, seems to me like some strange obsession with technicalities that would never matter to any readers. In all manner of practicality: a reader tries to type in Author:Nathan Hale, they come across a situation where they have to scroll down through the search suggestions to get what they want. Or, they end up at a deleted, admin-protected page if they type the Author link in the browser search bar, or through a direct wiki-link that was placed there in some circumstance. All of which is far less convenient and less useful than the quicker solution of a redirect. And the redirects would look the same each time we come across this situation, so it makes sense structurally and makes things slightly easier for everyone. So is there a practical issue at hand then, or are we only concerned that the string "Author:" is involved? PseudoSkull (talk) 23:48, 20 July 2023 (UTC)

See Henry V for an example that deals with both works and authors. The page was created as part of disentangling all the Shakespeare plays, and such. The play disambiguation pages received unanimous support, but the Mainspace disambiguation page was fashioned from the existing page at the time. The primary purpose of a Mainspace page is to disambiguate Works, not Authors. So Authors were listed under "See also" rather than as the principal content. --EncycloPetey (talk) 01:09, 21 July 2023 (UTC)

@PseudoSkull: I am hoping that this is a general discussion where you are hoping for gathering ideas so that you can come back to the community with a formed proposal with pros and cons, and case studies. I wouldn't be prepared to endorse any change without that firm piece of work. I see numbers of thought bubbles whichI don't see have suitable tests or studied thinking, and I feel that if you looked at specific examples based on the default search criteria of the community that there is already solutions to type ahead, searches and how people might arrive here from enWP. There is a whole case of author pages that are disambiguated in main ns, and we should be dealing with the collective, not a one-off, if we are looking for a new consensus to lever out this set of x-ns redirects. — billinghurst sDrewth 03:49, 21 July 2023 (UTC)

 Comment We need to differentiate what should never have happened,--and not been fixed--from what is purposeful. The community should be allow to have purposeful redirects where we reach a consensus to step outside of our rules, and we should document that on the redirect, rather than leave it floating in the wind.

I would argue that cases 3 and 4 (fixed now) should have been fixed long ago, and probably 6; cases 1, 2, 5 and 7 were special cases that the community left as part of a restructure and probably should have been reviewed earlier. Case 1, we could clean up and remove (it has been long enough); case 2, I am equivocal, cases 5 and 7 are purposeful individual exceptions, and we should document.

To allowing other x-ns redirects, of course we can, if that is what the community determines. I would rather have a reasoned proposal than try and respond to a general run-the-flag-up-the-pole routine, as what you are talking about is a change of an earlier consensus , a very very very long time ago policy discussion (prior to my time here). — billinghurst sDrewth

•  Comment re Nathan Hale. I don't see that we actually need a disambiguation page at that target, so the issue of a redirect page is actually not a relevant part of this conversation. Though I am always happy to have a review of how our old rules may not be relevant today. I would suggest that the disambiguation page be moved back to author: ns and just have a work and the relevant links to works as per normal. — billinghurst sDrewth 00:49, 21 July 2023 (UTC)

For case 3, the redirect makes sense IMO, because a casual reader (who knows nothing about our convoluted structure or namespace system) could easily assume that by searching "Sherlock Holmes" they should be taken to either the first Sherlock Holmes work, or more likely to a page listing works in the series. I feel that for most such similar series, there should be a mainspace redirect to the place that actually has the list. PseudoSkull (talk) 01:04, 21 July 2023 (UTC)

I disagree re case #3. Main namespace is for titles of works, not subject index. If you think that people think that it is a title for books, make it a disambiguation page, otherwise it should not be there. Main namespace is not a finding aid, and that work is no different from any other than writers of serial works with main characters. — billinghurst sDrewth 03:35, 21 July 2023 (UTC)

It isn't clear to me why the solution shouldn't be create a Portal:Sherlock Holmes and search will find it or use that as redirect instead of from main. MarkLSteadman (talk) 03:45, 21 July 2023 (UTC)

Absolutely a portal can exist with a suitable WD link back to the subject/article used at WP. Still no redirect. Remembering that a disambiguation page is a disambiguation page, and this would be a human name disambiguation page, not subject matter. — billinghurst sDrewth 03:54, 21 July 2023 (UTC)

I mean if for whatever reason we didn't want to fill it out with content and to avoid the duplication (although for Sherlock Holmes I think it would be good to create the portal as we can then link to the film adaptions that we have as well, or if someone creates a new work under a suitable license now that it is out of copyright). MarkLSteadman (talk) 04:02, 21 July 2023 (UTC)

@Billinghurst: What is the practical reason for it not being a finding aid sometimes? I repeat, as I feel like I keep having to repeat myself, that we're talking about a superstition revolving around technicalities here. The technicality doesn't need to matter if it actually helps someone, is my argument. What part about that is hard to understand? No one has given a single reason why deleting these pages would be helpful to anyone; the excuses given are a speedy deletion criterion, or "it's always been that way, so how dare you question it or try to make things make more sense."

As evidence that the redirect is clearly useful, the redirect Sherlock Holmes got 99 views in the past 30 days. Which is more than many popular works get here. You really can't deny the usefulness of it. So why go against what's useful for the sake of a technicality? PseudoSkull (talk) 22:08, 21 July 2023 (UTC)

1. We do not want a mess of redirects across namespaces, it makes a mockery of separating namespaces.

   So we need rules. History here shows us that every time anyone creates one millimetre of a gap or one exception to the rule, people take the metre. So going outside the norm needs to be justified. So exceptions to a strong rule should be by community consensus of allowing the one gap, or we change the rule by consensus. Present a cogent case based on the whole scenario, not your one example, that is not a special case. If it is that important you will do the work.

2. We have a default search and default lookahead, in defined content spaces that make searches/lookahead typing find things across the namespaces. Before you come to the community with your easy solution, please demonstrate that these are not working. A hit number of 99 for a redirect just means they hit that result first, and a properly constituted portal without a main ns interrupter would also likely get that number. Is "Sherlock Holmes" an outlier/special case for a redirect or is it a roadmap. Where is the divide between when we stop and go? [This is why it needs a proposal for consideration and how we would rewrite out policy/guidance,]
3. I am not talking about superstitions. I am talking about 15 years of administration, use of the mop, discussions here, and needing to arbitrate. I can tell you that our rules of no x-ns redirects has allowed for clear and easy management, movement of pages, removing mess or wild x-ns redirects and the lessening of later administrative burden. We have modified how we adapted by updating search, by updating disambiguation/versions/translation pages, and templates, use of WD and interwiki link, so please do not throw at me that facile and baseless superstition nonsense. I am up for the discussion, and managing a change of policy and procedure. However, I am not doing it based on your one need, or your feelings, I wish to see a cogent discussion document. — billinghurst sDrewth 22:36, 21 July 2023 (UTC)

Re: "usefulness" of Sherlock Holmes. Yes, that redirect page had 99 views in 30 days. And Author:Stephen King had 87 views in the same period, even though we have none of his stories. Number of views for a single page is not evidence of utility, of a pattern, nor a reason to overturn practice. We can choose to break our rules in specific instances where the community agrees that it merits deviation. But we wouldn't overturn a practice based on a single instance of such. I also note that the redirect was created in 2006, and so long predates our current practice. --EncycloPetey (talk) 17:45, 22 July 2023 (UTC)

@EncycloPetey: I admit that I care a bit less if a redirect like Sherlock Holmes or The Hardy Boys is allowed (which I could argue a structural hierarchy for series in this light), but the issue that was brought to my attention was whether Author:Nathan Hale should redirect to the mainspace disambiguation page Nathan Hale. But I guess before we can answer that question, we have to answer the question of whether or not the mainspace is even the correct place to harbor author and portal disambiguations along with work disambiguations. But, if we are to assume that community consensus will go in the direction of keeping Nathan Hale in the mainspace...then it seems like a no-brainer to me that an Author:Nathan Hale would be useful, since it is frustrating me even now to go to the link Author:Nathan Hale as a redlink, and not being redirected. If we're to assume the mainspace is the correct place for this, having a redirect from author to main would disseminate all confusion and frustration, and would certainly not cause other problems. And what structural model is it that you want? The case seems pretty straightforward. I could say it in one line. "If author and main pages are disambiguated in a human name disambiguation page -> Redirect author to main". It's a simple, straightforward process that I could write a script for in like 2 lines.

I also want to mention the bitter irony in the fact that we never want to be structured in any other instance, so it's funny that we'd be so obsessed with it in this specific minute circumstance. We want to keep our titling and disambiguation system completely wonky, to the point where it has no consistency whatsoever, and we don't even want to attempt to change that to make that more consistent (when Wikipedia and Wiktionary and Wikivoyage and Wikimedia Commons, and yes, virtually every other wiki except us, do have consistent rules on titling and disambiguation, so we're behind compared to them). We just want to allow whatever titling scheme someone wants to make up to just stay that way forever, unchanged, unimproved, for decades and decades on end. So people are up in arms against propositions for structure, usually.

But now that the very minor case of a redirect is involved; that most readers don't even care about the workings of, but just its utility in getting them to the page they want; and it just so happens to cross namespaces; and we have a 2003 rule written by people who probably left the community long ago, some of whom I'm sure have literally forgotten that Wikisource exists by now, before the smartphone age even required WS to have a mobile view, before scan-backing existed, when most of Wikisource was just messy copypastas of Gutenberg transcriptions and nothing else; that's when we're up in arms for structure even if it is literally sacrificing usefulness. And you want to work so hard, to come up with any excuse necessary, to defend this maxim (so dedicated that I'm sure one would reach so far as to even assume the existence of leprechauns as an argument against crossing namespaces) that has so little value and serves no purpose. It seems like a lot of the Wikisource community philosophy is completely inconsistent in this regard, and all we ever want to do is uphold tradition for the sake of tradition and reject change just because it's foreign to what we already know. This is a very deeply concerning problem to me that goes beyond the context of even this discussion. And because of that inevitable reality, it's probably more worth my time to just work on transcriptions again, than to engage with this circular and disagreeable conversation any further. PseudoSkull (talk) 20:22, 22 July 2023 (UTC)

No, that is not correct. I want to see a proper proposal based on proper logic that talks about what the change is that you are proposing based on a holistic situation, not starting and finishing on your one example. That simple. You are looking to change the basis of 15+ years operating policy and procedure.

Re your other mutterings, ff you merge all your irritations and frustrations of previous issues into one post, it doesn't help. That is unhelpful noise generation and makes it harder again. — billinghurst sDrewth 04:24, 23 July 2023 (UTC)

Adding my own work

I've a number of essays that I have written, but I don't know if they would be something the project is interested in. Philipp Michel Reichold (talk) 18:11, 23 July 2023 (UTC)

That depends! I recommend taking a look at Wikisource:What Wikisource includes. —CalendulaAsteraceae (talk • contribs) 18:23, 23 July 2023 (UTC)

Thanks Philipp Michel Reichold (talk) 18:38, 23 July 2023 (UTC)

@Philipp Michel Reichold: Peer-reviewed and suitable licence are the key factors here, and as CalendulaAsteraceae said, that page. That they are one own's works can be a hurdle, yet, it is also necessary for works that may need a copyright release. — billinghurst sDrewth 21:40, 24 July 2023 (UTC)

Easy image questions

Easy because I'm sure it's been answered many times. See Page:Albert Rhys Williams - Through the Russian Revolution (1921).djvu/32. I had transcribed the caption prior to finding the image.

So should I leave my transcribed text off the page and let the image caption suffice? It's not particularly clear at that size, but it is readable. The original image is very large, so I have this set at 500px. Is that correct/standard? A larger image would make the caption clearer, of course, but I don't know what other havoc would be unleashed.

Seems the proper way to handle this would be to edit the image, removing the caption, as well as the extraneous margins, then use my transcription as the caption. IF this is the course to take, what should be the final size of the image? Should I attempt to remove the yellowish hue of the image paper (unsure whether these books were printed on colored paper, or if it is just age discoloring)?

What say you, O Wiki wise ones? snafu22q (talk) 07:29, 24 July 2023 (UTC)

I usually remove the captions from the images and transcribe the caption. The one exception to this is when the caption is placed in the image rather than outside it. I use 450px for full-page portrait images and 600px for full-page landscape images. The shade of the image paper is usually faked in at the time of scanning and if you're able to strip it out, then that's good (I use Irfan Viewer to do this, as it's got a tool that does a colour replacement—and it's free). If the book came from Internet Archive, then there are high-res jpg2 images over there for each page that can be used as your starting point for clean-up. A recent image of mine that I've done the above for is the one on Page:Dave Porter in the Gold Fields.djvu/89. Beeswaxcandle (talk) 07:41, 24 July 2023 (UTC)

Thank you—just what I needed to know. Regarding the sizes you mention, you're not saying to increase the size should the image be smaller, are you? As quality seems to be the driving force here, increasing the size would seem to be counter-productive. I wouldn't have even thought of this but the next image I looked at was just less than 400px wide. Thanks for responding so quickly to my question, btw. snafu22q (talk) 09:45, 24 July 2023 (UTC)

Because I'm using the high-res jpg2 images, I can get away with those sizes for full-page images. If someone had uploaded a lower quality image, I would replace it with a higher quality one if I could. But, if an image is part page only, then I insert it at a smaller size so that it will look good when transcluded. Also, I don't always leave part-page images in the same alignment as they are in the printed page, I'll switch sides as needed. Floating images don't collide, but they can stack up and squeeze the text unreasonably—particularly on small screens. Beeswaxcandle (talk) 09:58, 24 July 2023 (UTC)

Pure images from Commons

Should wikisource include something like this - which is just a copy of photo that is on Commons - Page:Native Americans from Southeastern Idaho - NARA - 519339.tif ? -- Beardo (talk) 13:45, 24 July 2023 (UTC)

I speedied it. It was created as the single contribution of an IP address, with no real content, marked as "Not proofread". And on top of that, there's no associated Index page, and there is no content to transcribe, besides a single image from Commons. I'm not opposed to having a work that's a collection of images in book form, but we've gotta draw the line somewhere, and a single image with no text is definitely that line. I wouldn't say that this is something we should have here, and I think I'm pretty uncontroversial in saying that. PseudoSkull (talk) 13:56, 24 July 2023 (UTC)

If it has no text it is out of scope for enWS, simple as that. Xover (talk) 14:15, 24 July 2023 (UTC)

Cheers, both. That was my feeling, but I wanted to check first. Having it here added nothing to the version in Commons. -- Beardo (talk) 15:28, 24 July 2023 (UTC)

Help moving to Commons & renaming

I exported a pdf I've been working on to Commons. After I exported it, I renamed it on Commons, because the original filename was an IA file identifier, which I find singularly unhelpful. (I tried to rename it during the moving process, but it didn't work.) It left behind a redirect. (And I renamed it a second time, without a redirect, because it substituted a dash for a colon that I tried to use for the subtitle.) I put the correct filename from Commons into the template left on the file page here.

Remembering "Move to Commons" from Wikipedia, and/or perhaps the rename/move process on Commons, I was expecting a bot to go through and fix all the links, and then to delete the file here at WS.

Almost all of my expectations failed. Now it seems I have a mess to clean up. Is there a bot that will fix all the pages on WS to use the new filename at Commons? If so, where do I find it so that I can add my request to its to-do list?

Everything appears to be working right now since the file is still here on WS and I didn't attempt to change its filename here.

Did I miss a policy or how-to page somewhere that would have helped me avoid these pitfalls? Thank you for any help. Laura1822 (talk) 19:35, 24 July 2023 (UTC)

Moving a file for an Index is always messy, and best not to do once proofreading has started unless you are very skilled with experience about exactly what is going on.

It will be hard for anyone to help without knowing any of the filenames. Can you provide each individual filename involved at each step? --EncycloPetey (talk) 20:52, 24 July 2023 (UTC)

@Laura1822: There is a bot at Commons that will rename file usage here, though it needs to be part of its rename process.

If you are going to move a File: move it prior to starting a transcription. Also noting that due to the issue of renames and the problem that it causes, the renaming policy at Commons does not strictly apply to djvu and pdf files where they are in use at the Wikisources.

Fixing, yes we can, though as EncycloPetey said, the data helps, and so if we have fixes to do please add it to #Repairs (and moves) — billinghurst sDrewth 21:48, 24 July 2023 (UTC)

Tech News: 2023-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

• On July 18, the Wikimedia Foundation launched a survey about the technical decision making process for people who do technical work that relies on software that is maintained by the Foundation or affiliates. If this applies to you, please take part in the survey. The survey will be open for three weeks, until August 7. You can find more information in the announcement e-mail on wikitech-l.

Changes later this week

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

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

MediaWiki message delivery 02:20, 25 July 2023 (UTC)

What to do about mainspace-author disambiguation pages that share the same name

split from above discussion PseudoSkull (talk) 23:12, 21 July 2023 (UTC)

4. And for this situation, I still state that I do not see the case for a main namespace disambiguation page for Nathan Hale as it doesn't meet the criteria, and you keep avoiding that part of the conversation. I think we should undo that move. — billinghurst sDrewth 22:41, 21 July 2023 (UTC)

I really don't know how you don't see the case for it, given that you yourself gave me the case a few years ago. How is a main namespace page for Nathan Hale any different than your main namespace page for John Brown, that you created and merged yourself? There are actually even more works with that title, such as a work mentioned on "Hale, Nathan," in Encyclopædia Britannica (11th ed., 1911). He was a very popularly known historical figure in America for centuries, so there will be lots of books, poems, plays, etc. with his name as their title. If you want it to be in the author space, fine; if you want it to be in the main namespace, fine; but you were the one who merged my Author:John Brown page from author to main, and then notified me that that was the proper way to do it back then. And now you're telling me to do the opposite with Nathan Hale... So I'm the confused one here... PseudoSkull (talk) 22:58, 21 July 2023 (UTC)

I personally feel this would be better mostly in Author space in "About" sections for each and a dab page to find which author. I am not against having dab pages in main space about works with similar names but if there are also authors with similar names why not just "see also" the Author space dab page? —Uzume (talk) 12:56, 25 July 2023 (UTC)

@Uzume: The concern is Wikidata. The rule somewhere states, one Wikidata item per disambiguation title. PseudoSkull (talk) 14:07, 25 July 2023 (UTC)

@PseudoSkull: I don't know about that. I agree that having a separate dab page for every single thing defeats the purpose of having dab pages to begin with but there are certainly related dab pages and one for "Nathan Hale" about people can easily be different than "Nathan Hale" about works. E.g., there is Brown (Q219307) as well as Brown Building (Q991034), Brown Hotel (Q4976170), Brown Island (Q991045), Brown Mountain (Q4976209), Brown River (Q991060), Charles Brown (Q448382), Justice Brown (Q16800479), Brown Peak (Q4976231), Mount Brown (Q6919872), etc. I do not see a problem with having multiple "brown" dab Wikidata items for separate categories of things (even when they sometimes overlap, e.g., "building" vs. "hotel" and "peak" vs. "mount", etc.). —Uzume (talk) 14:38, 25 July 2023 (UTC)

Joe Biden letter

Is - Index:Joe Biden letter.jpg something that is worth having in wikisource ? If so, I think it needs to be moved to something with a more precise name. -- Beardo (talk) 12:18, 25 July 2023 (UTC)

@Beardo: That's an index page, and index pages are representative of the files they represent. So it's not really a question for us to change the filename, but for Wikimedia Commons. The work is fine, we have plenty of letters like that involving government officials and other notable figures. The place where naming really ought to be precise, for Wikisource purposes, is in transclusion. A title like Letter from Vice President Biden to Ken and Dakota Bihn (January 27, 2010), which has been suggested on the index page itself, is acceptable for transclusion of a letter (because letters aren't generally given titles in the works themselves). PseudoSkull (talk) 14:05, 25 July 2023 (UTC)

@PseudoSkull - OK - now created. -- Beardo (talk) 16:52, 25 July 2023 (UTC)

Rider Haggard's She

There seem to be two versions of the same original at:

• Index:She - a history of adventure (cu31924098819562).djvu, and
• Index:She - a history of adventure (IA cu31924098819562).pdf

The .pdf has slightly more work done, but I guess the djvu is better quality. What should be done? @ShakespeareFan00 and @Uzume created the two pages. -- Beardo (talk) 12:48, 25 July 2023 (UTC)

The revised edition from the next year and uploaded by @Xover is even more complete: Index:She (1888).djvu. —Uzume (talk) 13:04, 25 July 2023 (UTC)

@Uzume - yes, but I assume that we would want a copy of both editions. -- Beardo (talk) 16:53, 25 July 2023 (UTC)

HathiTrust changed its layout

Just wanted to let everyone know that HathiTrust did what seems like a complete overhaul of its former layout last night. Take a look for example at the full text page, and the catalog record page.

For anyone who has a HathiTrust downloader script of any sort, the code may need to be changed to accommodate for this new version of the Hathi site. PseudoSkull (talk) 16:31, 26 July 2023 (UTC)

Descriptions in portal templates

Are they supposed to be full sentences starting with a Majuscule and ending with a "."? Should it read "military personnel. He served in World War II" or "Military personnel. He served in World War II." as an example. --RAN (talk) 03:22, 24 July 2023 (UTC)

Some Portals require little explanation at all: such as Portal:Russian literature which has no explanation at all. Others, like Portal:Appendix Vergiliana have some explanation because it is unlikely that the average person stumbling across it will even know what it is. Some, such as Portal:West Germanic languages, have an explanatory image and caption. Portal:Medieval poetry, and other era-defined portals include an explanation of the period covered, with links to the previous and following periods. Portals have more flexibility than the other namespaces because they exist to cover a very diverse array of topics and needs. --EncycloPetey (talk) 19:18, 24 July 2023 (UTC)

• Thanks, but I asked a very specific question about punctuation. This edit removed the capital letter at the start of the sentence and removed the period at the end of the sentence. Is this the standard punctuation for Wikisource pages? --RAN (talk) 01:45, 25 July 2023 (UTC)

Comment: We really ought to migrate those descriptions to Wikidata or something, or have all descriptions be auto-generated. They're a mess. It's nearly impossible (and not worth time) to properly maintain duplicate descriptions in two separate places, with one more problematic even than the other. PseudoSkull (talk) 01:48, 25 July 2023 (UTC)

• Wikidata doesn't store prose, only individual facts. If we want information on the person, we should use the Wikidata infobox which will give all the descriptive info we need to identify/disambiguate a person. If we migrate the Wikidata infobox template, we can have as much/little biographical info we desire and all/none of the authority identifiers like VIAF and LCCN. --RAN (talk) 01:54, 25 July 2023 (UTC)

Wikidata does also allow descriptions of each item. Maybe we can just get the English one. PseudoSkull (talk) 02:33, 25 July 2023 (UTC)

@PseudoSkull, @Richard Arthur Norton (1958- ): I've wondered for ages about using the Wikidata descriptions, but they are not full sentences like are generally used here. Or at least, I've always assumed we aim for full sentences here, but RAN your question makes me wonder! Your example I would write as "Military personnel, served in World War II." or something like that. Sam Wilson 03:31, 25 July 2023 (UTC)

• It looks like the person who changed it wants the standard to be no capital at the start and no period at the end. We should discuss the standard we want. It looks odd to have no period at the end and to start with a lower case letter. We should use the standard sentence case where we start with a capital and end with a period. If we import the wikidata_infobox, we have control of how much or how little we want to display. --RAN (talk) 04:11, 25 July 2023 (UTC)

  I agree about having a capital letter and full stop. I wonder what the results are if we just capitalize the first letter of the Wikidata description and chuck on a dot at the end (probably not good; I'm not really advocating that…). Sam Wilson 08:16, 25 July 2023 (UTC)

  it is meant to be a descriptive jot of text to contextualise, and we have long said that. We are not writing an essay nor prose. As it is done with disambiguation pages through the WMF site, and descriptions at WD, they don't, and I don't see any value in it. Keep it simple. — billinghurst sDrewth 08:23, 25 July 2023 (UTC)

  No one has answered my question: Full sentence starting with a Capital letter and ending with a "."? Currently some start with a small letter and have no period at the end. Someone is converting some to this form. --RAN (talk) 04:45, 28 July 2023 (UTC)

  @Richard Arthur Norton (1958- ): My preference would be for capital and dot, i.e. full sentence. If we do go with the other form then I think we should just show Wikidata descriptions instead (and edit them to include what we want, of course). Sam Wilson 06:44, 28 July 2023 (UTC)

Community collaboration/Monthly Challenge/July 2023

There seems to be a problem with this updating. 'Plato', which is in the 'To fix' category, has been fixed and was completed (full transclusion and full validation) a couple of weeks ago. Chrisguise (talk) 12:14, 28 July 2023 (UTC)

What's wrong? There is still a page to be fixed in the Scan. I posted the details at Wikisource:Scan Lab under "Scan repair". --EncycloPetey (talk) 17:08, 28 July 2023 (UTC)

Tech News: 2023-31

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 Synchronizer tool is now available to keep Lua modules synced across Wikimedia wikis, along with updated documentation to develop global Lua modules and templates.
• The tag filter on Special:NewPages and revision history pages can now be inverted. For example, you can hide edits that were made using an automated tool. [11][12]
• The Wikipedia ChatGPT plugin experiment can now be used by ChatGPT users who can use plugins. You can participate in a video call if you want to talk about this experiment or similar work. [13]

Problems

• It was not possible to generate a PDF for pages with non-Latin characters in the title, for the last two weeks. This has now been fixed. [14]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 1 August. It will be on non-Wikipedia wikis and some Wikipedias from 2 August. It will be on all wikis from 3 August (calendar).
• Starting on Tuesday, a new set of Wikipedias will get "Add a link" (Georgian Wikipedia, Kara-Kalpak Wikipedia, Kabyle Wikipedia, Kabardian Wikipedia, Kabiyè Wikipedia, Kikuyu Wikipedia, Kazakh Wikipedia, Khmer Wikipedia, Kannada Wikipedia, Kashmiri Wikipedia, Colognian Wikipedia, Kurdish Wikipedia, Cornish Wikipedia). This is part of the progressive deployment of this tool to more Wikipedias. The communities can configure how this feature works locally. [15]

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

MediaWiki message delivery 23:54, 31 July 2023 (UTC)

Proposed speedy deletion criteria: empty categories

As some of you may know, we have criteria for speedy deletion that lets us avoid discussion of the merits of deleting a certain piece of content. One type of content that is routinely speedy-deletable elsewhere and a default option in the drop-down menu for deletion is an empty category. Right now, we have several hundred such categories that are also not particularly likely to be filled in (and are also very easy to recreate). I would like to propose that we add "Empty categories" as a valid criterion for speedy deletion to keep from a protracted process of discussion and waiting for deletion for content such as Category:118 BCE deaths, Category:Lucy poem, Category:7 Edw 2, Category:Jules de Grandin, Category:Jain Hymns, and Category:Icarus in poetry. —Justin (koavf)❤T☮C☺M☯ 19:26, 5 July 2023 (UTC)

•  Oppose (1) We have maintenance categories that are routinely empty. (2) We have categories like Category:118 BCE deaths, which was tagged for speedy deletion [16], but which exists as part of our categorization of authors. The fact that we don't currently have anyone in the category does not mean that it is worthless. (3) We have, in the not too distant past, had persons empty a category in order to propose its deletion. If we make emptiness a reason for speedy deletion, we invite people to empty categories for the purpose of having them speedied. --EncycloPetey (talk) 19:31, 5 July 2023 (UTC)

  1) can be easily avoided with a tag, such as those on many of our sister projects to not delete as a process or maintenance reason. That's an obvious caveat. What is the value of 2)? Should we have thousands of empty categories just in case we have a text by someone born in 2,598 BC or something? As far as 3), it's also easy to say that emptying a category for the purpose of speedy deletion is not allowed, as with (e.g.) the English Wikipedia. This is no different than all the other speedy deletion criteria: you can't take a page and then edit it to be nonsense in order to speedy delete it. —Justin (koavf)❤T☮C☺M☯ 19:34, 5 July 2023 (UTC)

  See the corresponding WP category, which contains w:Marcus Porcius Cato (consul 118 BC), who has some recorded speeches, and is thus a potential author to host on Wikisource. So, yes, that specific category has value. --EncycloPetey (talk) 19:47, 5 July 2023 (UTC)

  Marcus Porcius Cato was not born in 2,598 BC. Do you concede that issues 1 and 3 are easily dealt with and already comprehended? —Justin (koavf)❤T☮C☺M☯ 19:56, 5 July 2023 (UTC)

  Do you concede that you were incorrect to mark Category:118 BCE deaths for speedy deletion, simply because it was empty? --EncycloPetey (talk) 20:06, 5 July 2023 (UTC)

  You answered a question with a question. —Justin (koavf)❤T☮C☺M☯ 20:08, 5 July 2023 (UTC)

•  Support — ineuw (talk) 19:41, 5 July 2023 (UTC)
•  Oppose as a blanket rule. I'm not opposed to deleting junk categories and those that are against policy (works by author comes immediately to mind), but categories that are part of a legitimate sequence, such as year of birth/death, legislation (e.g. 7 Edw 2), journal issues, language, etc. should not be speedied. Beeswaxcandle (talk) 21:11, 5 July 2023 (UTC)
•  Oppose As with Category:118 BCE deaths, Category:Jules de Grandin is sitting around waiting for someone to transcribe The Horror on the Links and then The Tenants of Broussac. The fact that two out of categories described as "not particularly likely to be filled in" are indeed likely to be filled in doesn't make me comfortable with this proposal.--Prosfilaes (talk) 02:48, 6 July 2023 (UTC)
•  Support with one simple condition: Once the category is no longer empty, allow speedy undeletion by any administrator, or if no active administrator, rebuild by anyone.--Jusjih (talk) 03:59, 20 July 2023 (UTC)
•  Oppose as a blanket rule. If it is part of a template that redlinks, then leave it. If it is empty though has a Wikidata categorisation, then probably leave it. There are some that are never going to be populated so can be deleted. There are some that are moved that should utilise Template:Category redirect, and still be empty. If it is someone's transient edit as they think it a good idea, then we can delete it.

  As a comment, I have developed template:iflink that we can use to stop some of those rampant redlinks and will show the text, and once someone creates the category, then it will appear as an active link.—unsigned comment by Billinghurst (talk) 21:58, 24 July 2023‎.

 Oppose The last thing we need are more speedy deletion criteria, since there are already problems with some of the ones currently there. But since there are legitimate uses for some of these empty categories, as mentioned above, let a discussion ensue case by case. PseudoSkull (talk) 22:41, 24 July 2023 (UTC)

 Support. However, it should be not only empty but also unused by any template, and the general rule should have some specified exceptions mentioned by people above: 1) maintenance categories, 2) categories which are a part of a legitimate sequence, such as year of birth/death categories etc., and 3) categories with the Template:Category redirect. --Jan Kameníček (talk) 11:51, 5 August 2023 (UTC)

Deploying the Phonos in-line audio player to your Wiki

Hello!

Apologies if this message is not in your language, ⧼Please help translate⧽ to your language.

This wiki will soon be able to use the inline audio player implemented by the Phonos extension. This is part of fulfilling a wishlist proposal of providing audio links that play on click.

With the inline audio player, you can add text-to-speech audio snippets to wiki pages by simply using a tag:

<phonos file="audio file" label="Listen"/>

The above tag will show the text next to a speaker icon, and clicking on it will play the audio instantly without taking you to another page. A common example where you can use this feature is in adding pronunciation to words as illustrated on the English Wiktionary below.

{{audio|en|En-uk-English.oga|Audio (UK)}}

Could become:

<phonos file="En-uk-English.oga" label="Audio (UK)"/>

The inline audio player will be available in your wiki in 2 weeks time; in the meantime, we would like you to read about the features and give us feedback or ask questions about it in this talk page.

Thank you!

UOzurumba (WMF), on behalf of the Foundation's Language team

02:26, 27 July 2023 (UTC)

We probably should update {{listen}} to this format when this is live. Though I would suggest that we consider using {{#tag:phonos||file=En-uk-English.oga|label=Audio (UK)}} as required. — billinghurst sDrewth 04:57, 8 August 2023 (UTC)