Wikisource:Scriptorium/Archives/2024-09

Announcing the Universal Code of Conduct Coordinating Committee

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

Hello all,

The scrutineers have finished reviewing the vote and the Elections Committee have certified the results for the Universal Code of Conduct Coordinating Committee (U4C) special election.

I am pleased to announce the following individual as regional members of the U4C, who will fulfill a term until 15 June 2026:

• North America (USA and Canada)
  • Ajraddatz

The following seats were not filled during this special election:

• Latin America and Caribbean
• Central and East Europe (CEE)
• Sub-Saharan Africa
• South Asia
• The four remaining Community-At-Large seats

Thank you again to everyone who participated in this process and much appreciation to the candidates for your leadership and dedication to the Wikimedia movement and community.

Over the next few weeks, the U4C will begin meeting and planning the 2024-25 year in supporting the implementation and review of the UCoC and Enforcement Guidelines. You can follow their work on Meta-Wiki.

On behalf of the U4C and the Elections Committee,

RamzyM (WMF) 14:06, 2 September 2024 (UTC)

Tech News: 2024-36

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

Weekly highlight

• Editors and volunteer developers interested in data visualisation can now test the new software for charts. Its early version is available on beta Commons and beta Wikipedia. This is an important milestone before making charts available on regular wikis. You can read more about this project update and help to test the charts.

Feature news

• Editors who use the Special:UnusedTemplates page can now filter out pages which are expected to be there permanently, such as sandboxes, test-cases, and templates that are always substituted. Editors can add the new magic word __EXPECTUNUSEDTEMPLATE__ to a template page to hide it from the listing. Thanks to Sophivorus and DannyS712 for these improvements. [1]
• Editors who use the New Topic tool on discussion pages, will now be reminded to add a section header, which should help reduce the quantity of newcomers who add sections without a header. You can read more about that, and 28 other community-submitted tasks that were resolved last week.
• Last week, some Toolforge tools had occasional connection problems. The cause is still being investigated, but the problems have been resolved for now. [2]
• Translation administrators at multilingual wikis, when editing multiple translation units, can now easily mark which changes require updates to the translation. This is possible with the new dropdown menu.

Project updates

• A new draft text of a policy discussing the use of Wikimedia's APIs has been published on Meta-Wiki. The draft text does not reflect a change in policy around the APIs; instead, it is an attempt to codify existing API rules. Comments, questions, and suggestions are welcome on the proposed update’s talk page until September 13 or until those discussions have concluded.

Learn more

• To learn more about the technology behind the Wikimedia projects, you can now watch sessions from the technology track at Wikimania 2024 on Commons. This week, check out:
  • Charts, the successor of Graphs - A secure and extensible tool for data visualization (25 mins) – about the above-mentioned Charts project.
  • State of Language Technology and Onboarding at Wikimedia (90 mins) – about some of the language tools that support Wikimedia sites, such as Content/Section Translation, MinT, and LanguageConverter; also the current state and future of languages onboarding. [3]

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

MediaWiki message delivery 01:07, 3 September 2024 (UTC)

Have your say: Vote for the 2024 Board of Trustees!

Hello all,

The voting period for the 2024 Board of Trustees election is now open. There are twelve (12) candidates running for four (4) seats on the Board.

Learn more about the candidates by reading their statements and their answers to community questions.

When you are ready, go to the SecurePoll voting page to vote. The vote is open from September 3rd at 00:00 UTC to September 17th at 23:59 UTC.

To check your voter eligibility, please visit the voter eligibility page.

Best regards,

The Elections Committee and Board Selection Working Group

MediaWiki message delivery (talk) 12:15, 3 September 2024 (UTC)

Scholarship Applications Now Open for Wikisource Conference 2025!

Dear Wikimedians,

We are thrilled to announce that the Wikisource Conference is returning after a decade! It will be held from 14 to 16 February 2025 in Denpasar, Bali, Indonesia. This event will be a great opportunity for us to come together, share experiences, and discuss the future of Wikisource and its community. We are now accepting scholarship applications for the Wikisource Conference 2025 to promote diversity and inclusion. Scholarships are open to active contributors, community members, developers, and partners involved with Wikisource or related projects.

Important Details:

• Application Period: 1 September 2024 to 20 September 2024
• Application Deadline: 20 September 2024
• Meta page: Link

We encourage everyone who is passionate about Wikisource and interested in attending this unique gathering to apply for a scholarship. The selection committee will carefully review all applications, focusing on contributions to the Wikisource project, community engagement, and the potential impact of participation in the conference.

To apply, please fill out the scholarship application form. We will provide updates soon for more information about the conference, including program details, speakers, and venue.

If you have any questions or need help with your application, feel free to reach out on the Meta Talk page or email us at wikisourceconference@gmail.com.

We look forward to receiving your applications and hope to see many of you in Bali for the Wikisource Conference 2025!

Regards,

Nitesh Gill

The Wikisource Conference 2025 Team

MediaWiki message delivery (talk) 11:14, 5 September 2024 (UTC)

Scan Lab not linked on community pages?

Was trying to find my way to Scan Lab. Realised it wasn't linked at either Wikisource:Index/Community or Wikisource:Community portal, is there any particular reason? Arcorann (talk) 08:37, 7 September 2024 (UTC)

@Arcorann: No. Just nobody has done it yet. It's relatively recent. Xover (talk) 10:46, 7 September 2024 (UTC)

Since there's no particular reason, I added it to the "other" sections of the community portal and Index/community. — Alien333 ( what I did
why I did it wrong ) 12:28, 7 September 2024 (UTC)

How to get at the text to fix a typo

Where is the link to the text at New York Evening Post/1890/Death Of An Old Pilot RAN (talk) 02:10, 8 September 2024 (UTC)

@Richard Arthur Norton (1958- ): All links are in the usual places for me on that page. Could you elaborate on the problem? Xover (talk) 05:30, 8 September 2024 (UTC)

• Oh, What I was looking for was "just click on the [1] in the upper left corner". It wasn't that they were missing, I usually just work on jpgs not pdfs, where the text is right there. --RAN (talk) 05:34, 8 September 2024 (UTC)

Annotation versus fix error in transcription or ocr

The file New York Evening Post/Annotated/1890/Death Of An Old Pilot is now an annotation because I fixed an error in the transcription. Is this an actual Annotation or just a normal correction in the transcription, I am not making an interpretation or correcting an error of fact. RAN (talk) 21:32, 8 September 2024 (UTC)

The "and" in the scan is damaged, but readable. There is clearly a partial letter in the position of the n, with "and" as the reasonable word in the original given the portion of the letter not damaged and the context. --EncycloPetey (talk) 22:02, 8 September 2024 (UTC)

The annotation status is a result of the multiple wikilinks peppering the article, and not because of your correction. --EncycloPetey (talk) 22:13, 8 September 2024 (UTC)

Tech News: 2024-37

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

Feature news

• Starting this week, the standard syntax highlighter will receive new colors that make them compatible in dark mode. This is the first of many changes to come as part of a major upgrade to syntax highlighting. You can learn more about what's to come on the help page. [4][5]
• Editors of wikis using Wikidata will now be notified of only relevant Wikidata changes in their watchlist. This is because the Lua functions entity:getSitelink() and mw.wikibase.getSitelink(qid) will have their logic unified for tracking different aspects of sitelinks to reduce junk notifications from inconsistent sitelinks tracking. [6]

Project updates

• Users of all Wikis will have access to Wikimedia sites as read-only for a few minutes on September 25, starting at 15:00 UTC. This is a planned datacenter switchover for maintenance purposes. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [7]
• Contributors of 11 Wikipedias, including English will have a new MOS namespace added to their Wikipedias. This improvement ensures that links beginning with MOS: (usually shortcuts to the Manual of Style) are not broken by Mooré Wikipedia (language code mos). [8]

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

MediaWiki message delivery 18:52, 9 September 2024 (UTC)

The formatting of Author:Alfred Tennyson

This author page is very poorly formatted and cluttered and many works of the author are repeated twice. There is first a list of his "principal works", mostly his published collections of poetry, but also some individual poems (due of their notability?). After this follow most (but not all) of his collections of poetry, each having its contained poems linked and listed below it. These lists are incomplete (perhaps only poems considered notable are listed?). Finally there is a header "Other, to sort", which contains several poems found as part of the published collections.

I've tried cleaning this up a little, but it's still a mess. Should I just nuke most of the page other than the list of principal works? But of course for a poet, published collections are not whole works; rather the poems contained within them often grow an independent life beyond the collections wherein they were first published. For instance "Canto 104" from In Memoriam is better known as "Ring Out, Wild Bells", so much so that it has a duplicate page under that title. Mårtensås (talk) 19:03, 10 September 2024 (UTC)

See Author:John Greenleaf Whittier, where the listings of individual poems has been moved to a separate page. --EncycloPetey (talk) 22:20, 10 September 2024 (UTC)

@Mårtensås@EncycloPetey Having done a lot of work on migrating unbacked poems / transcribing various volumes of Tennyson's poetry, and continuing (slowly) to do so, it is my intention to address the author page issue in the same way as for Samuel Taylor Coleridge (but not the 'chronological order' listing) or Algernon Charles Swinburne (still a work in progress). However, if anyone else wants to do the Tennyson page, feel free. Chrisguise (talk) 13:33, 11 September 2024 (UTC)

Category:Undated works

There are more than 35K works contained in this category, but at a cursory look though the listings, a significant number are uploads by BenchBot from 2010-2011. Adding dates to court cases ought to be a simple thing to do, but many of these uploads have no usable content, such as Allen v. Hanks; Allman v. United States; Alling v. United States.

What should be done about these listings? --EncycloPetey (talk) 22:44, 10 September 2024 (UTC)

• EncycloPetey: I am bothered by these as much as the next guy, but your three examples are all wrong; they all contain the full text of the court’s opinion. The eventual solution for these is to move them all to sub-pages of United States Reports and scan-back them, although that is obviously a long-term project. TE(æ)A,ea. (talk) 03:20, 11 September 2024 (UTC)

  Then why is there an empty "Notes" section on Allen v. Hanks if it's complete? --EncycloPetey (talk) 04:31, 11 September 2024 (UTC)

  • EncycloPetey: The bot added “Notes” sections to all pages, even if there weren’t any notes. For example, syllabi almost never have footnotes, but the bot added the “Notes” section to syllabi pages anyway. I started work on scan-backing one volume a while back, but the low quality of the OCR made it hard work. I might get back to it soon, though. TE(æ)A,ea. (talk) 12:30, 11 September 2024 (UTC)

Floruit

If a person has got the single floruit parameter set in Wikidata, it is reflected in our author pages as well, see e. g. Author:William Smith (fl. 1596). Could this be done for the work period (start), aka floruit start, and work period (end), aka floruit end, parameters too? -- Jan Kameníček (talk) 18:00, 11 September 2024 (UTC)

Relevant discussion: Module talk:Author#Floruit ++ —Beleg Tâl (talk) 18:06, 11 September 2024 (UTC)

Template:Img float

On Page:Creation by Evolution (1928).djvu/58, I am facing two issues:

• Problem 1: The template {{img float}} is not centering the image, and is not allowing for the wrapping of text. Testing suggests that the alignment of the caption is interfering with the alignment of the image. Both of these behaviors have worked in the past. Did something break the template, or interfere with it in some way? Or am I missing something obvious in my syntax?
• Problem 2: The template documentation advises against using div-based templates, but provides no options for some of the formatting required by this page. Namely, the fact that the first line of the caption is centered, but the rest of the caption is left-aligned. --EncycloPetey (talk) 23:42, 9 September 2024 (UTC)

Problem 1 also occurs on Page:Creation by Evolution (1928).djvu/173, where Problem 2 is not a concern. --EncycloPetey (talk) 00:15, 10 September 2024 (UTC)

On Page:Creation by Evolution (1928).djvu/180 and Page:Creation by Evolution (1928).djvu/183:

• Problem 3: I have two paragraphs of caption, and the second paragraph is not being displayed as part of the caption, but is instead being displayed as part of the main text.

The work-around for this seems to be a double <br> inserted, but is this clutsy work-around the best (or only) option? --EncycloPetey (talk) 01:03, 10 September 2024 (UTC)

I think you're trying to go beyond the capabilities of this particular template. Have you tried using {{FI}} instead? GO3 designed it to get around some of the issues you're having. Beeswaxcandle (talk) 06:25, 10 September 2024 (UTC)

That's a 10-year old template without much maintenance since then. I'll try it out, but is its code still as functional? --EncycloPetey (talk) 07:01, 10 September 2024 (UTC)

@Beeswaxcandle: I have tried using {{FI}}, so why on Page:Creation by Evolution (1928).djvu/194 is the paragraph not wrapping around the image? --EncycloPetey (talk) 23:42, 11 September 2024 (UTC)

Sorry, my mistake. I meant {{FIS}}. I've changed the page to that and it's wrapping nicely. Beeswaxcandle (talk) 07:02, 12 September 2024 (UTC)

GFDL and license update

Hello everyone!

I wonder about the content in Category:GFDL.

It looks like the w:en:Wikipedia:Image license migration / m:Licensing update was not completed for the files. But since most are screenshots the correct license template would perhaps be Template:Wikisource screenshot (the template should perhaps be updated to look more like c:Template:Wikimedia screenshot).

And what about the text content. For example Architekton Alexi Rilets. It was created in 2006-2007 so should it be marked as relicensed? I have mostly worked with files and I thought that all text was automatically relicensed on all wikis.

Does anyone know about what happend here on Wikisource in 2009 and why? MGA73 (talk) 10:47, 16 September 2024 (UTC)

This is due to the one time relicensing allowed in section 11: https://www.gnu.org/licenses/fdl-1.3.html which has a cutoff date of 2009. MarkLSteadman (talk) 16:27, 16 September 2024 (UTC)

Yes but as I undertand it ALL content was relicensed at/before that time by the central descision/resolution but it was not documented or written explicit at all (file) pages (yet). --MGA73 (talk) 16:47, 16 September 2024 (UTC)

Tech News: 2024-38

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

Improvements and Maintenance

• Editors interested in templates can help by reading the latest Wishlist focus area, Template recall and discovery, and share your feedback on the talkpage. This input helps the Community Tech team to decide the right technical approach to build. Everyone is also encouraged to continue adding new wishes.
• The new automated Special:NamespaceInfo page helps editors understand which namespaces exist on each wiki, and some details about how they are configured. Thanks to DannyS712 for these improvements. [9]
• References Check is a feature that encourages editors to add a citation when they add a new paragraph to a Wikipedia article. For a short time, the corresponding tag "Edit Check (references) activated" was erroneously being applied to some edits outside of the main namespace. This has been fixed. [10]
• It is now possible for a wiki community to change the order in which a page’s categories are displayed on their wiki. By default, categories are displayed in the order they appear in the wikitext. Now, wikis with a consensus to do so can request a configuration change to display them in alphabetical order. [11]
• Tool authors can now access ToolsDB's public databases from both Quarry and Superset. Those databases have always been accessible to every Toolforge user, but they are now more broadly accessible, as Quarry can be accessed by anyone with a Wikimedia account. In addition, Quarry's internal database can now be queried from Quarry itself. This database contains information about all queries that are being run and starred by users in Quarry. This information was already public through the web interface, but you can now query it using SQL. You can read more about that, and 20 other community-submitted tasks that were resolved last week.
• Any pages or tools that still use the very old CSS classes mw-message-box need to be updated. These old classes will be removed next week or soon afterwards. Editors can use a global-search to determine what needs to be changed. It is possible to use the newer cdx-message group of classes as a replacement (see the relevant Codex documentation, and an example update), but using locally defined onwiki classes would be best. [12]

Technical project updates

• Next week, all Wikimedia wikis will be read-only for a few minutes. This will start on September 25 at 15:00 UTC. This is a planned datacenter switchover for maintenance purposes. This maintenance process also targets other services. The previous switchover took 3 minutes, and the Site Reliability Engineering teams use many tools to make sure that this essential maintenance work happens as quickly as possible. [13]

Tech in depth

• The latest monthly MediaWiki Product Insights newsletter is available. This edition includes details about: research about hook handlers to help simplify development, research about performance improvements, work to improve the REST API for end-users, and more.
• To learn more about the technology behind the Wikimedia projects, you can now watch sessions from the technology track at Wikimania 2024 on Commons. This week, check out:
  • Hackathon Showcase (45 mins) - 19 short presentations by some of the Hackathon participants, describing some of the projects they worked on, such as automated testing of maintenance scripts, a video-cutting command line tool, and interface improvements for various tools. There are more details and links available in the Phabricator task.
  • Co-Creating a Sustainable Future for the Toolforge Ecosystem (40 mins) - a roundtable discussion for tool-maintainers, users, and supporters of Toolforge about how to make the platform sustainable and how to evaluate the tools available there.

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

MediaWiki message delivery 00:02, 17 September 2024 (UTC)

Limiting use of Template:old style

We had a deletion discussion for {{old style}} last year in which a divided discussion ended in a Keep vote. However, there were concerns raised about the misuse and overuse of the template, particularly where it adds no information encoded in the original text, but merely replicates a font style.

I propose that we officially restrict the use of {{old style}}, so that it is:

• never used for page numbers, whether in tables of contents, or in page headers, or page footers
• applied in running text only when the template is required for communicating encoded information

There are other places where I also feel it is misused, but these are the two situations I most often consider misuse of the template. --EncycloPetey (talk) 19:17, 2 September 2024 (UTC)

Disagree There are plenty of legitimate uses of fancy-looking numbers in texts and they can communicate a number of things, just like how text (running text, tables, titles, etc.) can vary between serif and sans-serif fonts for a variety of semantic and stylistic reasons. Due to the fact that there are various reasons and it's not always obvious if the rationale is stylistic or semantic, whatever else, this is one of many text style choices that can be inserted in a text and should be retained, like bold or italics or small caps, etc. —Justin (koavf)❤T☮C☺M☯ 19:24, 2 September 2024 (UTC)

Is this not what is meant by "communicating encoded information"? —Beleg Tâl (talk) 13:31, 3 September 2024 (UTC)

The difference with bold, italics, small caps, etc., is that the majority of text in a work is not in bold, italics, small caps, etc., and those options are used selectively to set a bit of text visually apart from the regular text. Whereas the use of old style does this in only a single instance found in the entire previous discussion on this template. This isn't being used to distinguish some numbers in old style from the usual numbers everywhere else in the work. So while you may disagree, your reason for disagreeing does not hold up as meaningful. --EncycloPetey (talk) 18:47, 17 September 2024 (UTC)

Sometimes it's true that a work uses old style numbers throughout, sometimes not. Please also respond to the message that you started on my talk. —Justin (koavf)❤T☮C☺M☯ 18:50, 17 September 2024 (UTC)

• Oppose. The template should be used, in any given index, if it is appropriate to use in the index; arbitrary, top-down limitations interfere with this objective. For example, in many cases old-style numbers are used to accompany a (meaningful) difference in font (style) (such as italics), but do not individually encode any information. I think a use in such cases is appropriate and æsthetically pleasing. This proposal is really just a move to limit (later ban) the template, for which there is not general support. TE(æ)A,ea. (talk) 19:44, 2 September 2024 (UTC)

  Italics typically encodes information, such as that the item is a title or ship name, or conveys emphasis. In a title page, it can be used to set one section of text apart from other sections of text. Old style numbering encodes no information about page numbers. --EncycloPetey (talk) 19:49, 2 September 2024 (UTC)

 Support The only reason {{old style}} should ever be used, is if the old style numerals are required for what the author/publisher is trying to communicate (for example, to show the reader the difference between 4 and 4). I assume this is what you mean by "communicating encoded information". I don't see why you'd add an additional stipulation for page numbers, since their use there would be subject to exactly the same standard. And of course, the same standard applies to {{serif}}, {{sans}}, and any other template that overrides the user's browser's font settings. —Beleg Tâl (talk) 20:11, 2 September 2024 (UTC)

It is possible some editors may agree with one point but not the other. By enumerating them separately, it creates specifics for discussion. --EncycloPetey (talk) 21:47, 2 September 2024 (UTC)

That's fair. And I think I also must  Oppose point 1 as worded, since it only applies independently from point 2 in cases where encoded information is communicated via the formatting of page numbers. And in such a circumstance,—if any such circumstance exists, unlikely as that may be—{{old style}} definitely should be used. —Beleg Tâl (talk) 13:37, 3 September 2024 (UTC)

I have yet to see a page number, in the header, footer, or table of contents, where the font of the number was specially different using old style numbering in order to make a distinction. I have seen italicized page numbers in indexes, and could imagine that italics might be used elsewhere for that purpose. And I have seen small-caps used on Roman numerals in bibliographic information. But I cannot imagine a situation where old style numbers are used to encode information about a page number in a way that is meant to set them apart from other page numbers in the same work. --EncycloPetey (talk) 17:01, 3 September 2024 (UTC)

I can't imagine it either. However, as far as I can tell, that would be the only circumstance covered under proposed rule 1 that isn't already covered under proposed rule 2. And since that's the case, proposed rule 1 essentially states "do not use {{old style}} in page numbers even if it communicates encoded information". The only other way it makes sense to me, is if proposed rule 2 struck down (which would change our whole approach to default fonts)—and if that were to happen, I think using {{old style}} for page numbers would be among its least egregious usage scenarios. —Beleg Tâl (talk) 17:41, 3 September 2024 (UTC)

 Support for all reasons given so far. I add that Help:Fonts states "In particular, Wikisource does not seek to force all texts to be be in the same or similar fonts to how they were published", which I would consider to apply to old style numerals where it is merely a feature of the published book's font (which covers most of its current usage and which I consider misuse; I previously cited The King in Yellow/The Repairer of Reputations as an example of such). Arcorann (talk) 00:35, 3 September 2024 (UTC)

 Support. I'm not usually in favour of this strict of a top-down limitation of an issue like this, because there are plenty of use cases that are either legitimate or where it doesn't really matter if a contributor prefers to reproduce these for essentially aesthetic reasons (or whatever), and there are softer mechanisms that can be used to guide usage to what is desirable.

However, in this particular case… The template was created in 2020 by the same contributor who is now on a crusade to use it extensively. We did just fine without it for the ~15 years prior, and it is now spreading out both in implementation (having been joined by {{Old style I}} in 2023) and usage: the template now has over 6500 transclusions (I checked ~100 at random; none were legitimate uses for it) and is spreading to new users (a remarkable number were added by IP editors and new accounts, enough so that I almost began to suspect socking). Softer guidance is clearly not working, and we are now way past the point where individual soft nudges are sustainable. In addition, when it becomes an issue we get situations like this, this, and this. There is clearly a vocal minority that not only disagree with what are the acceptable uses for forced old-style numerals, but also are actively spreading their use and resist all attempts to limit it.

In these circumstances I think it is necessary (call it the lesser evil, if you like) to make a sharp, top-down, limitation like the one proposed here. --Xover (talk) 11:14, 3 September 2024 (UTC)

 Support for the same reason we don't set the fonts for entire books: {{old style}} just replicates a font style, in most cases not bringing any information, especially when used for all numbers in a book. I see no reason to make an exception to the rule for it. — Alien333 ( what I did
why I did it wrong ) 11:32, 3 September 2024 (UTC)

 Oppose For ease of understanding how things work here. As published should not only be about typos. As published should only include technically impossible things (like those quote paragraphs where every wrapped line starts with a “). Perhaps it would be helpful to see if one of wikimedia's fonts has these old style numbers and add an @font to the template. Also, the thing about markup is that while maybe it doesn't work now, it might in the future and texts should get that markup now because something like this would be very difficult for software to add later.--RaboKarbakian (talk) 13:47, 9 September 2024 (UTC)

Modifying the font as a whole (serif vs sans serif, old-style vs new-style numerals, single-story g vs double-story g, etc) should not be done this way. If anything, it should be handled by something like {{Default layout}}. ... Actually, this could be a really good idea, and could solve issues like {{ls}} while we're at it :D —Beleg Tâl (talk) 14:35, 9 September 2024 (UTC)

Help with page files

I work with one page jpg documents. At Page:Joseph Henderson Obituary.pdf/1 I love how the text appears next to the image in page files, can this be done with jpg images as well or only pdf files? When I download the pdf is the text integrated into it or is still just an image? RAN (talk) 23:24, 17 September 2024 (UTC)

• RAN: Do you mean that when the page is first loaded, text already shows up on the left side of the screen? If that is what you mean to refer, then it is OCR, which can show up in PDF or DjVu files, but not JPG files. However, OCR can be generated for those pages in the Page: namespace. If a PDF file has built-in OCR, a downloaded copy will retain that OCR. TE(æ)A,ea. (talk) 23:58, 17 September 2024 (UTC)
• I am not sure how to word my question properly since I do not know the terminology. I use this format: Brooklyn Eagle/1903/Angelina A. Wilcox because it was a standard entry 10 years ago. Should I switch to creating Page:Joseph Henderson Obituary.pdf/1 for every entry and be switching to using pdf files instead of jpg files? Should I be creating "Page:Angelina A. Wilcox Obituary/1" for all entries from now on? Or should this be exclusive for multipage docs. --RAN (talk) 00:10, 18 September 2024 (UTC)

  You can create Index pages with image files. For example, you would create an Index page at Index:Angelina Annetta Henderson (1863-1903) obituary.png, and then use Page:Angelina Annetta Henderson (1863-1903) obituary.png for the transcription. —Beleg Tâl (talk) 01:21, 18 September 2024 (UTC)

The only problem is that we used to know who "Captain Joseph Henderson" was and what "Sandy Hook service" means. By removing the links, now they are just words without context. It could mean any of the three Joseph Hendersons in Wikipedia or Wikidata or VIAF. --RAN (talk) 01:55, 18 September 2024 (UTC)

That's fine, you can make annotated copies if you like so long as you follow the requirements of the annotation policy and keep the primary copy clean. (This policy applies whether or not the work is transcribed from an Index page.) Remember that the original article in the Brooklyn Eagle did not contain links explain who "Captain Joseph Henderson" was and what "Sandy Hook service" means either. —Beleg Tâl (talk) 02:36, 18 September 2024 (UTC)

Requested move of 100+ pages

• Representative women of New England → Representative Women of New England. The work has over 100 subpages, so I didn't do it myself. Please move per standard caps and usage in the work's scan itself. —Justin (koavf)❤T☮C☺M☯ 21:21, 19 September 2024 (UTC)

   Comment The title is in sentence case, which is permitted by the WS:MOS. While I personally prefer title case, sentence case is explicitly permitted by our rules. Unless there is some additional technical issue at play, the current title is fine. --EncycloPetey (talk) 21:52, 19 September 2024 (UTC)

Two page wide tables

One of the works I'm currently proofreading has two-page-wide tables. I put the whole table into the left page, but I'm not entirely sure how to deal with the right page (I vaguely remember there was some guidance but I can't find it.) Arcorann (talk) 03:15, 17 September 2024 (UTC)

I just blank out the right page and put a comment to the effect that the content has been moved to previous page for ease of transclusion. Beeswaxcandle (talk) 05:48, 17 September 2024 (UTC)

Do you mark the right page as no-text? Arcorann (talk) 00:07, 20 September 2024 (UTC)

Yes, otherwise it shows up on the transclusion check. Beeswaxcandle (talk) 00:34, 20 September 2024 (UTC)

User:Prosfilaes/Norton World Literature 1800-1900

I've not imported it to namespace, and arguably could send it to Wikisource:Requested texts, but I'm not concerned about just the lack of scans. But I dug through one of the standard English language anthologies of world literature, and found some of our holes. Unfortunately, some of the works considered important now weren't considered important 95 years ago, so some of the authors weren't translated back then.--Prosfilaes (talk) 04:31, 20 September 2024 (UTC)

Your wiki will be in read-only soon

Read this message in another language • Please help translate to your language

The Wikimedia Foundation will switch the traffic between its data centers. This will make sure that Wikipedia and the other Wikimedia wikis can stay online even after a disaster.

All traffic will switch on 25 September. The switch will start at 15:00 UTC.

Unfortunately, because of some limitations in MediaWiki, all editing must stop while the switch is made. We apologize for this disruption, and we are working to minimize it in the future.

A banner will be displayed on all wikis 30 minutes before this operation happens. This banner will remain visible until the end of the operation.

You will be able to read, but not edit, all wikis for a short period of time.

• You will not be able to edit for up to an hour on Wednesday 25 September 2024.
• If you try to edit or save during these times, you will see an error message. We hope that no edits will be lost during these minutes, but we can't guarantee it. If you see the error message, then please wait until everything is back to normal. Then you should be able to save your edit. But, we recommend that you make a copy of your changes first, just in case.

Other effects:

• Background jobs will be slower and some may be dropped. Red links might not be updated as quickly as normal. If you create an article that is already linked somewhere else, the link will stay red longer than usual. Some long-running scripts will have to be stopped.
• We expect the code deployments to happen as any other week. However, some case-by-case code freezes could punctually happen if the operation require them afterwards.
• GitLab will be unavailable for about 90 minutes.

This project may be postponed if necessary. You can read the schedule at wikitech.wikimedia.org. Any changes will be announced in the schedule.

Please share this information with your community.

Trizek_(WMF), 09:37, 20 September 2024 (UTC)

Scholarship Application Deadline Extended for Wikisource Conference 2025!

Dear Wikimedians,

This message is about the Wikisource Conference, taking place from 14 to 16 February 2025 in Denpasar, Bali, Indonesia, after a decade-long break. This conference will be a fantastic opportunity to reconnect, share insights, and discuss the future of Wikisource and its vibrant community.

In the spirit of promoting diversity and inclusion, we're pleased to inform you that the deadline for scholarship applications has been extended to 29 September 2024.

If you still need to apply, please fill out the application form.

For any questions or assistance, feel free to contact us via the Meta Talk page or by email at wikisourceconference@gmail.com.

We look forward to your applications and hope to see you at the Wikisource Conference 2025!

Thank you MediaWiki message delivery (talk) 13:32, 20 September 2024 (UTC)

Wikisource Conference 2025 Scholarship Team

Any tricks/gadgets/shortcuts for filling in headers and footers?

I'm currently working on a book that has pretty much the same header on every page and the footer is the same except for the page number. Are there any tricks, gadgets, or shortcuts to make filling these in less tedious (or even completely automated)? User:Inductiveload/Running header.js and the associated gadget look promising, although they seem to require using {{rh}}. Is there anything more general? Nosferattus (talk) 23:31, 21 September 2024 (UTC)

I've edited the Index page. It will now auto-fill the header and footer. --EncycloPetey (talk) 23:44, 21 September 2024 (UTC)

Wow! Thank you!! Nosferattus (talk) 23:45, 21 September 2024 (UTC)

There's no reason to be using the running header template in the footer to center the page number. Likewise for the header, since it's merely a centered title in italics. --EncycloPetey (talk) 23:46, 21 September 2024 (UTC)

Linebreak in the beginning of a footer in the Page namespace

How can I emit a plain linebreak (not a <br/> tag or any other markup) in the beginning of the page footer in order to prevent it from messing up the last paragraph of the text in the Page namespace? I want to add something like {{newline}}{{rh|{{{pagenum}}}|}} to the 'Footer' field of the Index page, so that it's automatically initialized in every page. A Lua script executed from Template:Newline can do the job if it just prints "\n", but I wonder if I'm just trying to reinvent the wheel and a nice solution already exists? --Ssvb (talk) 05:55, 10 September 2024 (UTC)

I can correct the issue by manually entering a blank line at the start of the footer, but I do not know if this can be automatically done. The auto-generated headers and footers do not like to include line breaks. --EncycloPetey (talk) 06:01, 10 September 2024 (UTC)

A new Lua script can do it, but this means adding one more template and inventing a name for it ({{blankline}} or {{blank line}} is probably a good one). I can provide a demo of this functionality in my user space. --Ssvb (talk) 06:43, 10 September 2024 (UTC)

{{br}} exists as well. —Justin (koavf)❤T☮C☺M☯ 08:37, 10 September 2024 (UTC)

It just inserts <br> and this is not desirable. Here's a simple test. Go to Page:Donegal Fairy Stories (1915).djvu/24, click "edit" and experiment with the footer at the bottom. Right now the footer has an extra blank line at top. Removing this blank line and clicking on "Show preview" messes up the bottom paragraph and splits it into two separate parts: "Now there was a prince called Connal, who lived in a wee sod house close by Nancy and" and "Shamus, but whose fathers before him, ere their".

Can we substitute the blank line in the footer with some template and turn it into a single line? The {{br}} template doesn't help and neither do the other templates.

Why do I want this? For convenience and proofreading efficiency. The index page Index:Donegal Fairy Stories (1915).djvu allows to configure the default footer for the newly created pages, but this footer has to be provided as a single line. And this means that the starter blank line needs to be somehow smuggled there. --Ssvb (talk) 09:01, 10 September 2024 (UTC)

As a test, I have added 'blankline' function to the Sandbox module via this diff. Now the footer can be specified as a single line and this makes it suitable for the index page footer settings: {{#invoke:Sandbox|blankline}}{{rh||{{smaller|4}}|}}.

Is it possible to achieve the same using the existing templates? And if not, then would anyone oppose the creation of a new template {{blankline}} specifically for this? --Ssvb (talk) 09:35, 10 September 2024 (UTC)

I am not sure why the line breaks have been preserved throughout the page. I suggest removing them per Help:LINEBREAKS, this would also solve the issue with the last paragraph and no blank line in the footer would be needed. --Jan Kameníček (talk) 14:03, 10 September 2024 (UTC)

Line breaks are preserved throughout the page because removing them is optional per Help:Beginner's_guide_to_proofreading#Optional. Keeping line breaks to accurately match the structure of the original book makes the process of proofreading and validation significantly faster and more convenient. I believe that the convenience is more important than the artificial formalism. And if removing line breaks actually becomes mandatory, then this can be done automatically by a bot. But once gone, the line breaks can't be easily restored anymore.

If the rationale to remove line breaks was to workaround problems with the footers, then why don't we just fix the footers instead? --Ssvb (talk) 17:17, 10 September 2024 (UTC)

And to illustrate the point with a practical example, I suggest to go to Page:Donegal Fairy Stories (1915).djvu/37 and try to proofread the two somewhat longish paragraphs in the middle. First in the "View" mode. And then in the "Edit" mode, where line breaks accurately match the line breaks of the original book. Compare the convenience and speed of the whole process. Use a stopwatch to objectively measure time in order to make this comparison more scientific.

Maybe the experienced Wikisource contributors are used to it and just don't see anything wrong? But as a newcomer, I immediately perceive the Help:LINEBREAKS "best practice" recommendation as something very obviously harmful. If a proofreader removes line breaks, then he/she effectively makes everything much harder for the validator. --Ssvb (talk) 18:44, 10 September 2024 (UTC)

The usual reason we remove line breaks (as far as I'm aware) is that there are issues on line break, especially broken up words, that are often overlooked when not removing line breaks, and that are easier to remember to take care of if you remove the line breaks. — Alien  3
3 3 19:34, 10 September 2024 (UTC)

@Alien333: The official reason given in Help:Beginner's_guide_to_proofreading#Optional is that "Line breaks can cause problems (especially with templates, links and tables, and italics/bold which are closed by the line ending)". And yes, the footer problem from this topic happens to be one of such technical glitches (which we can fix).

As for the broken up words. Could you please show some practical example? The broken up words are in most cases highlighted by a spellchecker and this makes them difficult to miss. Admittedly Page:The Headless Horseman (1869).djvu/19 was one of the cases that could potentially fall through the cracks. The OCR layer had it as "with an ad mixture" without the end-of-line hyphen. But fortunately the book damage is visible, so this can be spotted in a high resolution high quality scan. Still I don't see how removing or keeping line breaks could make any difference in this situation. --Ssvb (talk) 20:28, 10 September 2024 (UTC)

Calling it an "official" reason gives it more status than it merits. The Beginner's Guide page you're referring to was largely written by a single person, a decade ago, and is geared for beginners. By the time a page is Validated, the line breaks should have been removed. But at what step in the process the line breaks are removed is the debatable point, since, as you note, leaving them in makes validation easier. Some proofreaders leave most of them in at the "Proofread" stage, but also as noted above, doing do creates formatting issues in some works. --EncycloPetey (talk) 22:40, 10 September 2024 (UTC)

I call it "official" because this guide is directly linked from the Wikisource:Community portal. Thus it's much more likely to be found and read by beginners than most of the other guides. And the statement that the line breaks are optional isn't outdated, because this particular part of the guide was last edited in June 2024. Also what's the purpose of removing line breaks in validated pages, considering that even the validated pages can't guarantee 100% accuracy? There may be cases when somebody may want to re-validate the already validated pages. --Ssvb (talk) 00:31, 11 September 2024 (UTC)

For the technical reasons already mentioned, among others. Stray line returns in the middle of paragraphs are generally not a good idea; they are technically an additional character. --EncycloPetey (talk) 01:11, 11 September 2024 (UTC)

These stray line returns aren't visible in the browser window. And if I copy-paste the text from the browser window, the additional characters can't be found there either. The end result is just identical in the browser, regardless of removing or keeping such line breaks in the middle of paragraphs in the wikitext. The advantages of removing line breaks seem to be purely ephemeral, unless this is done to workaround glitches with templates/links/tables/italics/bold. But the disadvantages of removing line breaks are very real and hinder proofreading. --Ssvb (talk) 01:35, 11 September 2024 (UTC)

Not purely ephemeral, no. There are pages where additional elements result in false paragraph breaks if the line breaks are not removed. The only reason to retain the line breaks is the perceived ephemeral advantage to proofreading, which is a back-end process. --EncycloPetey (talk) 04:35, 11 September 2024 (UTC)

Do I understand you correctly that you label the contributors' proofreading and validating efforts as a non-important "back-end process"? In my opinion, human work time is the most valuable and the actual bottleneck of the Wikisource project, despite having more than 8 billion people on Earth. --Ssvb (talk) 06:37, 11 September 2024 (UTC)

Take a look at Page:Creation by Evolution (1928).djvu/64, where leaving in the line break has resulted in a false paragraph, leading proofreaders to wonder how to correct the problem. I have seen many new editors here experience this issue for the first time and not know how to correct it. The solution is simple: remove the line breaks and the paragraphs become fully joined. --04:40, 11 September 2024 (UTC) EncycloPetey (talk) 04:40, 11 September 2024 (UTC)

The irony is that the false paragraph in https://en.wikisource.org/w/index.php?title=Page:Creation_by_Evolution_(1928).djvu/64&oldid=14470294 is caused by having no leading blank line in the automatically added footer {{c|[ {{{pagenum}}} ]}}, which is configured in the settings of Index:Creation_by_Evolution_(1928).djvu.

And coincidentally, this is exactly the topic of this discussion. The technical solution for fixing this problem is simple. We only need to reach consensus about what's the most appropriate way to do that. The decision is needed whether to add a new template, modify {{nopt}} or maybe do something else. See the discussion thread with @Arcorann below. --Ssvb (talk) 05:09, 11 September 2024 (UTC)

{{nopt}} is designed to do this; although it is meant for when table markup appears in the header and footer, the same principle should apply here. Arcorann (talk) 00:46, 11 September 2024 (UTC)

@Arcorann: Thanks for the suggestion, but in its current state just adding {{nopt}} in the beginning of a strictly single-line footer line doesn't help. While adding {{#invoke:Sandbox|blankline}} does. Still, you make a good point, because it possibly makes sense updating {{nopt}} to cover this use case rather than introducing a brand new template. --Ssvb (talk) 01:15, 11 September 2024 (UTC)

It was fine when I tested it. Did you add a line break after {{nopt}}, so that {{rh}} was on the next line? Arcorann (talk) 02:14, 11 September 2024 (UTC)

Ignore above, didn't notice that the footer box on the index page has trouble accepting newlines (standard usage requires {{nopt}} to be on its own line). Given that {{nopt}} is quite high use, a new template might be better then. Arcorann (talk) 02:21, 11 September 2024 (UTC)

Actually I did a quick test and it might be possible to adjust {{nopt}} to emit an extra new line without breaking it. More testing might be needed. Arcorann (talk) 02:29, 11 September 2024 (UTC)

@Ssvb@Koavf@Jan.Kamenicek@EncycloPetey@Arcorann@Alien333 Could I ask in what sense text in the footer messes up 'the last paragraph of the text in the Page namespace'? In my reasonably extensive experience it doesn't, unless there's a formatting fault in the main body (unclosed italics inside block formatting sometimes produce weird results) or the presence of what seem to be different types of line breaks. The latter can be made visible by switching on 'Generate paragraph (pilcrow) markers, ¶ , in the left margin of the Page: namespace to indicate HTML paragraph tag starts.' in preferences / gadgets. Chrisguise (talk) 13:48, 11 September 2024 (UTC)

I also have not experienced footers messing up the last paragraph of text in the Page namespace. —Justin (koavf)❤T☮C☺M☯ 13:53, 11 September 2024 (UTC)

@Chrisguise, @Koavf: https://en.wikisource.org/w/index.php?title=Page:Creation_by_Evolution_(1928).djvu/64&oldid=14470294 is an excellent example, which is a page from the current Proofread of the Month. And I already provided detailed explanations with another example in the other comments above. --Ssvb (talk) 14:09, 11 September 2024 (UTC)

I'm just answering the question you asked. I have not seen this and looking at Page:Creation by Evolution (1928).djvu/64, I see no problems with the last paragraph. Even looking at the HTML, I don't see anything that could be messing it up. It ends:

and every<link rel="mw-deduplicated-inline-style" href="mw-data:TemplateStyles:r13089542"></p><div class="wst-center tiInherit">

<p>[ 34 ]

</p>

</div></div></div>

¯\_(ツ)_/¯ —Justin (koavf)❤T☮C☺M☯ 14:32, 11 September 2024 (UTC)

@Koavf: Well, you see no problems with the last paragraph anymore because you made an edit to workaround it and also validated the page. But check the older revision and you will see the problem again.

The problem is that your workaround is not free and degrades the quality of life for anyone trying to re-validate this page in the future. The line breaks are now gone. It became significantly harder to locate where the original book's lines start or end on the left side of the screen. Moving the eyes back and forth is now slower and much more exhausting. --Ssvb (talk) 15:05, 11 September 2024 (UTC)

Workaround? Literally all I did was strip out extraneous new lines and use a template for a CSS transformation for capitals. That's what we should do on every page anyway. It's not a workaround...

This rev also ends:

and every<link rel="mw-deduplicated-inline-style" href="mw-data:TemplateStyles:r13089542"></p><div class="wst-center tiInherit">

<p>[ 34 ]

</p>

</div></div></div>

These two HTML snippets are identical. If they are both identical HTML there is literally no way for the pages to be different. I'm totally confused here about what you claim is a "workaround" by just doing completely pedestrian editing and how this page has its bottom paragraph messed up. —Justin (koavf)❤T☮C☺M☯ 15:11, 11 September 2024 (UTC)

Side note: us[ing] a template for a CSS transformation for capitals is should not be done on every page anyways. From {{uc}}'s documentation: Do not use "{{uppercase|example}}" where the uppercase content "EXAMPLE" is required. — Alien  3
3 3 15:34, 11 September 2024 (UTC)

Well, yes, it should be used where it should be used, of course. There are times when someone uses all caps for some semantic reason ("I am SCREAMING NOW!"), but in those instances where it is not and purely stylistic, {{uc}} should be used. —Justin (koavf)❤T☮C☺M☯ 15:51, 11 September 2024 (UTC)

@Koavf: Here's a screenshot with a painted arrow to show the precise location of the "false paragraph" from https://en.wikisource.org/w/index.php?title=Page:Creation_by_Evolution_(1928).djvu/64&oldid=14470294

Tested with both Firefox and Chromium. If you can't reproduce this problem in your browser, then could it be that you have some custom Javascript gadgets installed?

As for the "strip out extraneous new lines", this is precisely the action that I find very much undesirable. And I already explained what's wrong with it. There's no policy that strictly requires line breaks removal (see Help:Beginner's_guide_to_proofreading#Optional). If you prefer to remove them, then it's your choice and the choice of your friends. But my choice is to avoid participating in proofreading or validating the pages, which are already degraded by such line breaks removal. I hope that we can just peacefully work on different projects without causing problems for each other.

The "false paragraph" problem caused by the footer and demonstrated on the screenshot can be solved by adding a new template and one tiny Lua module. Do I need somebody's permission to just implement this and move on? --Ssvb (talk) 15:50, 11 September 2024 (UTC)

That's because of the extraneous new lines I mentioned before. Look at the HTML on that rev: it has new paragraphs inserted because those who proofread it did not remove these lines. When I did, that removed those paragraphs. This is not a workaround: it is what should have been in the first place. —Justin (koavf)❤T☮C☺M☯ 15:52, 11 September 2024 (UTC)

@Ssvb@Koavf Yes, but as I said before, if you turn on 'Generate paragraph (pilcrow) markers, ¶ , in the left margin of the Page: namespace to indicate HTML paragraph tag starts.' in preferences / gadgets, you can see what it is that causes the problem. There appears to be at least two types of 'carriage return'; both have the same effect in edit mode but when rendered in 'page' view, they behave differently. I am not a computer geek so don't know why or how this happens but I guess it's an artefact of the OCR software. Chrisguise (talk) 16:02, 22 September 2024 (UTC)

@Chrisguise: Sorry, I tried, but wasn't able to confirm this. Maybe in some books with some exotic OCR text layer this might be really the case, but not in the books that I looked at. Can you point me to a real example? --Ssvb (talk) 16:24, 22 September 2024 (UTC)

• General comment: The linebreaks that should be removed in the Page: namespace are those where a word is broken with a hyphen and those that cause "false" paragraphing problems when transcluded into the Mainspace. All others are optional to remove—it depends on how the editor finds it most efficient to work. That said, my question to @Ssvb: is: when these interaction problems happen between the body and footer in the Page: namespace, do they carry over into the Mainspace? If they don't, then it's not important to fix. Beeswaxcandle (talk) 18:07, 11 September 2024 (UTC)

  The linebreaks where a word is broken with a hyphen don't necessarily need to be removed completely, just two halves of the word can be glued together without causing a bigger disruption. As can be demonstrated using Page:Donegal Fairy Stories (1915).djvu/37 as an example:

  • Original:
    • Well, off to Shamus went Prince Connal with-
      out much loss of time, and called Shamus out of
      his little cabin.
  • Corrected:
    • Well, off to Shamus went Prince Connal without
      much loss of time, and called Shamus out of
      his little cabin.

  Such correction is already done automatically and is a part of the OCR layer of this particular DjVu file. Thus it requires no efforts from a proofreader and causes no time wastage. Or alternatively, such correction can be done by a locally installed Javascript gadget. Linebreaks in the wikitext matching the structure of the original book enable comfortable and fast proofreading/validation. --Ssvb (talk) 00:42, 12 September 2024 (UTC)

  The false paragraphs problem is real. And, as @EncycloPetey mentioned earlier, it often leads to a proofreader's confusion in cases like https://en.wikisource.org/w/index.php?title=Page:Creation_by_Evolution_(1928).djvu/64&oldid=14470294 . The main reason of this confusion is that the footer is added automatically outside of the proofreader's control, so the proofreader has a hard time linking the the cause and effect. But this particular problem is solvable, the automatically added footers can be amended not to cause it. A new template or an enhanced {{nopt}} template is needed for that. --Ssvb (talk) 00:46, 12 September 2024 (UTC)

  @Beeswaxcandle: The interaction problems happen between the body and footer only in the Page: namespace and do not carry over into the Mainspace. But I would still prefer to fix this problem rather than ignoring it. For example, the quotations in Wiktionary refer to the book pages in Wikisource. So it's desirable to have a nicely looking proper formatting even in the Page: namespace. This isn't just the Wikisource proofreader's private business and the end users can see these pages too. --Ssvb (talk) 00:55, 12 September 2024 (UTC)

  In that case the Wiktionary links are pointing to the wrong place. The ProofreadPage extension is solely a backend function and while accessible should never be a landing page from outside link. The correct place to link to is the transclusion in the Mainspace. If the reader wants to verify further with the scanned page, the mechanism is there with the page links. @EncycloPetey: is this linking from Wiktionary to the Page: namespace something that you could lead a discussion on over there? Beeswaxcandle (talk) 01:31, 12 September 2024 (UTC)

  I have tried. The Wiktionary community is set on doing what they do in this instance with Reference citations pointing to Wikipedia for Authors and book titles, and to the Wikisource Page namespace for the quotation itself. --EncycloPetey (talk) 01:40, 12 September 2024 (UTC)

  @Beeswaxcandle: There's no strict Wiktionary policy about what to use as a page link. The only requirement is that it needs to be a durably archived source. Or in other words, something that confirms the authenticity of a quotation. So in practice, Google Books links, Internet Archive links and Wikisource links are often used for quotations in Wiktionary articles. Wiktionary is not interested in Wikisource's Mainspace. The only thing that is valuable for Wiktionary is the scanned page from a real paper book, and the Wikisource's Page namespace provides exactly that, plus some extras. Why are you so much opposed to linking to Wikisource Page namespace? --Ssvb (talk) 02:29, 12 September 2024 (UTC)

  Just that it's an off label use and therefore not supported. Beeswaxcandle (talk) 07:22, 12 September 2024 (UTC)

  This risk is acceptable. And the same is true for any external links. Broken links can be updated by bots if such need arises. --Ssvb (talk) 10:58, 12 September 2024 (UTC)

I just went ahead and created the new {{nopf}} template. It makes preserving line breaks viable in the content of the pages by eliminating one of the most annoying glitches. It's especially useful for use in auto-added single-line footers, which are configured at Index pages.

It's possible that this template can also work as a perfect drop-in replacement for {{nopt}}, but I can't be completely sure without first doing some extensive testing. --Ssvb (talk) 05:36, 12 September 2024 (UTC)

@ShakespeareFan00: Regarding this diff and its revert. We probably don't need any special category for it, just like the {{nop}} and {{nopt}} templates don't add pages to any special categories either.

And regarding diff, diff, diff, ... The template is intended to make everything easy and convenient for Wikisource contributors. But if you are spending your time manually editing it out from the footers, then doesn't this defeat the purpose? What was your motivation for doing these edits? I mean, these edits do no harm, but they shouldn't be necessary. --Ssvb (talk) 05:10, 13 September 2024 (UTC)

When a simple solution like adding blank lines directly exists, adding a template seems like overkill. However, I won't continue this replacement outside of the Index concerned, and will not object if you start reverting me. The attempt to add a tracking category was so that if the underlying issues with P wrapping (something that's been on Phabricator for a while) do eventually get fixed, there some counting of how widespread the problem was. (Special:WhatLinksHere doesn't provide an overall usage count, whereas a category tracking does.) ShakespeareFan00 (talk) 08:29, 13 September 2024 (UTC)

Aside: Looking to reduce the constelattion of templates that do the same thing is a good idea though, and I would suggest also looking into how templates like {{pbr}} and {{pbr}} can be simplified into your approach.

ShakespeareFan00 (talk) 08:29, 13 September 2024 (UTC)

This was so long.... Did anyone try {{-}} which is "clear"?--RaboKarbakian (talk) 13:29, 13 September 2024 (UTC)

Well, now I did, and putting it at the end of the body works (start of footer doesn't), but the problem is that {{-}} uses a <br>, so it will break paragraphs when transcluded. — Alien  3
3 3 15:21, 13 September 2024 (UTC)

Layouts

Any chance that one of the layout options will be two columns of text in the future? RAN (talk) 21:38, 23 September 2024 (UTC)

Courtesy link for context: Help:Layout. —Justin (koavf)❤T☮C☺M☯ 21:45, 23 September 2024 (UTC)

Unlikely to happen as a layout option. There are a few things that need to be taken into account with the layouts. 1) Mobile view: viewing two columns on a phone is really horrible; 2) Accessibility: two columns confuses screen readers (both hardware and software); 3) Long texts: in a long piece of text, where should the column break happen? Each screenful? How would the core wiki software know when that is for the huge variety of screen sizes and ribbons, menu bars, and browser personalisations that our readers use? Beeswaxcandle (talk) 23:33, 23 September 2024 (UTC)

Tech News: 2024-39

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

Weekly highlight

• All wikis will be read-only for a few minutes on Wednesday September 25 at 15:00 UTC. Reading the wikis will not be interrupted, but editing will be paused. These twice-yearly processes allow WMF's site reliability engineering teams to remain prepared to keep the wikis functioning even in the event of a major interruption to one of our data centers.

Updates for editors

A screenshot of the interface for the Alt Text suggested-edit feature

• Editors who use the iOS Wikipedia app in Spanish, Portuguese, French, or Chinese, may see the Alt Text suggested-edit experiment after editing an article, or completing a suggested edit using "Add an image". Alt-text helps people with visual impairments to read Wikipedia articles. The team aims to learn if adding alt-text to images is a task that editors can be successful with. Please share any feedback on the discussion page.
• The Codex color palette has been updated with new and revised colors for the MediaWiki user interfaces. The most noticeable changes for editors include updates for: dark mode colors for Links and for quiet Buttons (progressive and destructive), visited Link colors for both light and dark modes, and background colors for system-messages in both light and dark modes.
• It is now possible to include clickable wikilinks and external links inside code blocks. This includes links that are used within <syntaxhighlight> tags and on code pages (JavaScript, CSS, Scribunto and Sanitized CSS). Uses of template syntax {{…}} are also linked to the template page. Thanks to SD0001 for these improvements. [14]
• Two bugs were fixed in the GlobalVanishRequest system by improving the logging and by removing an incorrect placeholder message. [15][16]
• View all 25 community-submitted tasks that were resolved last week.

Updates for technical contributors

• From Wikimedia Enterprise:
  • The API now enables 5,000 on-demand API requests per month and twice-monthly HTML snapshots freely (gratis and libre). More information on the updates and also improvements to the software development kits (SDK) are explained on the project's blog post. While Wikimedia Enterprise APIs are designed for high-volume commercial reusers, this change enables many more community use-cases to be built on the service too.
  • The Snapshot API (html dumps) have added beta Structured Contents endpoints (blog post on that) as well as released two beta datasets (English and French Wikipedia) from that endpoint to Hugging Face for public use and feedback (blog post on that). These pre-parsed data sets enable new options for researchers, developers, and data scientists to use and study the content.

In depth

• The Wikidata Query Service (WDQS) is used to get answers to questions using the Wikidata data set. As Wikidata grows, we had to make a major architectural change so that WDQS could remain performant. As part of the WDQS Graph Split project, we have new SPARQL endpoints available for serving the "scholarly" and "main" subgraphs of Wikidata. The query.wikidata.org endpoint will continue to serve the full Wikidata graph until March 2025. After this date, it will only serve the main graph. For more information, please see the announcement on Wikidata.

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

MediaWiki message delivery 23:36, 23 September 2024 (UTC)

A possible problematic book

As @user:Beleg Tâl, noticed, and I am also confused about this publication's license to be considered in public domain Diamonds To Sit On.

This book is universally known as The twelve chairs.. and is also faithfully recreated comedy film by Mel Brooks. This title was published earlier in English.

The two books are identical. It's possible that this publication was to circumvent the then existing copyright laws? — ineuw (talk) 21:25, 23 September 2024 (UTC)

If you are asking a question about possible copyright concerns, the correct place to post is Wikisource:Copyright discussions. It is more likely to be spotted there by people who specialize in answering such questions. --EncycloPetey (talk) 21:45, 23 September 2024 (UTC)

@EncycloPetey: Thanks. — ineuw (talk) 03:12, 24 September 2024 (UTC)

Dropletter

What markup do I use to get a dropletter at the start of a page? RAN (talk) 22:00, 23 September 2024 (UTC)

Are you looking for {{drop initial}} or {{initial}}? --EncycloPetey (talk) 22:04, 23 September 2024 (UTC)

Or even {{dropcap}}. Beeswaxcandle (talk) 23:34, 23 September 2024 (UTC)

• Thanks I will try each and see which matches the original text best. --RAN (talk) 04:50, 24 September 2024 (UTC)

@Beeswaxcandle: Any chance of migrating any of the templates to Commons? Text for news articles and image captions are usually first transcribed there, before they are migrated here. --RAN (talk) 23:37, 24 September 2024 (UTC)

Sorry to interject here where you explicitly asked someone else a question but 1.) anyone could copy/paste it and just provide attribution: these are all very simple templates (if you are really concerned about it, an admin at Commons could import) and 2.) maybe I am just somehow crazy ignorant after 20-some years, but where are there transcriptions of text with styling on Commons? I know that there is structured data and there are captions for media, but are there existing places where a file on Commons needs drop initial caps in the file information? And, of course, the structured data are all plain text. —Justin (koavf)❤T☮C☺M☯ 00:04, 25 September 2024 (UTC)

I'm not sure I understand the purpose of migrating these templates to Commons. If there is any text held there, it isn't formatted in the way that we do here. A text-layer in a pdf or djvu file is not formatted, rather that's what we do. Beeswaxcandle (talk) 06:46, 25 September 2024 (UTC)

Proofread Page colors have faded..

Tracked in PhabricatorTask T375114

Why? I'm finding it harder to distinguish between them. ShakespeareFan00 (talk) 08:29, 18 September 2024 (UTC)

Its only just happened for me, but it is certainly less clear. I assume some numbers have been changed in some template somewhere. IdiotSavant (talk) 12:56, 18 September 2024 (UTC)

I checked that, but couldn't see any obvious changes in Mediawiki namespace... ShakespeareFan00 (talk) 12:57, 18 September 2024 (UTC)

maybe a ticket? subtle changes affect this project while unseen in wikipedia. --Slowking4 ‽ digitaleffie's ghost 14:30, 18 September 2024 (UTC)

• The change is in span.oo-ui-widget.oo-ui-widget-enabled.oo-ui-inputWidget.oo-ui-radioInputWidget.prp-quality-radio.quality[] where [] is the number of each proofreading status. (This doesn’t appear to call any MediaWiki: for this step.) Without text: formerly #ddd, now #eaecf0. Not proofread: formerly #ffa0a0, now #fee7e6. Problematic: formerly #b0b0ff, now #eaf3ff. Proofread: formerly #ffe867, now #fef6e7. This makes the actual colors basically unusable and needs a Phabricator ticket. TE(æ)A,ea. (talk) 14:33, 18 September 2024 (UTC)

  The file that contains those definitions contains a lot of "cdx-", so I assumed it's mw:Codex. Looking at their phab & gerrit, they have indeed been doing some stuff with the color palette. phab:T373223, backlinked in this commit, says: The updated colors are lighter and less saturated. This is an intentional difference, but a noticeable one. Not what caused the problem. phab:T360494 provides the precise changelog of colors. The changes this did, if I understood correctly, were to rename some colors, sometimes tweaking them slightly, and to add others. I guess prp relied on these colors by their codex identifiers somewhere, and so when these names changed meaning the colors changed. — Alien  3
  3 3 14:36, 18 September 2024 (UTC)

  This, nine days ago, changed the variables to match the new color palette, and that, last week, changed prp code to use those variables. — Alien  3
  3 3 14:47, 18 September 2024 (UTC)

  The solution would probably be replacing

  .quality4 {
  	background-color: @background-color-success-subtle;
  	border-color: @background-color-success-subtle;
  }
  
  .quality3 {
  	background-color: @background-color-warning-subtle;
  	border-color: @background-color-warning-subtle;
  }
  
  .quality2 {
  	background-color: @background-color-progressive-subtle;
  	border-color: @background-color-progressive-subtle;
  }
  
  .quality1 {
  	background-color: @background-color-error-subtle;
  	border-color: @background-color-error-subtle;
  }
  
  .quality0 {
  	background-color: @background-color-notice-subtle;
  	border-color: @background-color-notice-subtle;
  }
  

  , over there, by

  .quality4 {
  	background-color: @background-color-green100;
  	border-color: @background-color-green100;
  }
  
  .quality3 {
  	background-color: @background-color-yellow100;
  	border-color: @background-color-yellow100;
  }
  
  .quality2 {
  	background-color: @background-color-blue100;
  	border-color: @background-color-blue100;
  }
  
  .quality1 {
  	background-color: @background-color-red100;
  	border-color: @background-color-red100;
  }
  
  .quality0 {
  	background-color: @background-color-muted;
  	border-color: @background-muted;
  }
  

  , to match the previous values of these variables before the name change. — Alien  3
  3 3 14:57, 18 September 2024 (UTC)

  Is it possible to override the styles locally, e.g. via MediaWiki:Gadget-Site.css? —Beleg Tâl (talk) 15:01, 18 September 2024 (UTC)

  I don't see why not? — Alien  3
  3 3 15:22, 18 September 2024 (UTC)

  Since we don't have from the css perspective access to the json that made it, though, instead of using the variables we should use their values, so that corresponds to what's in Template:Sandbox/styles.css.

  Someone should also make a pull request, a ticket, or whatever, to tell the PRP people this needs to be changed. — Alien  3
  3 3 15:50, 18 September 2024 (UTC)

  If you are raising a ticket , it would be a good time to also add in the functionatlity to show untranscluded pages with a sutiable border ( which is currently an additional script). ShakespeareFan00 (talk) 16:18, 18 September 2024 (UTC)

  (I'm not raising a ticket, I'm asking for someone to, as I don't have any experience with how that works). — Alien  3
  3 3 16:21, 18 September 2024 (UTC)

  Phab:T375114 —Justin (koavf)❤T☮C☺M☯ 16:44, 18 September 2024 (UTC)

  Thanks for starting the ticket. This is not the first time that a misguided attempt to improve aesthetics have clobbered the functionality of proofreading via the Index pages. --EncycloPetey (talk) 18:21, 18 September 2024 (UTC)

  Happy to do it, thanks for thanking me. And to Alien333 or anyone else, there are some proscribed ways to make bug tickets, but if you end up miswording something or making a duplicate ticket, someone else will fix it. And you get better the more you do it (I still have some clunky wording or make some tickets that are duplicates but had names that I could never have searched for or guessed). —Justin (koavf)❤T☮C☺M☯ 18:45, 18 September 2024 (UTC)

I am setting side-by-side images below to illustrate the severity of the faded colors problem. The first image has the vivid colors usually present on an Index page. The Index page is the coordinating hub for the addition of new books to Wikisource. As each page is created and proofread, it is color coded to indicate its progress state. In the first image, you can see the majority of pages are pink, indicating that those pages have been created, but still need proofreading. Pages that are yellow have been proofread by one editor, and lime by two editors. It is very easy at a glance to assess the current state of the work and to identify which pages need work.

• 
  Older Index page, with vivid colors
• 
  Current Index page with faded colors

The second image was taken today of a current Index. In this image, the colors are so faded, that it is not possible to tell the current state of any pages using the Index. This means that the entire purpose of using the Index is broken, and progress will be slowed or halted project wide, because it is not possible to determine what work needs to be done, or where that work is needed. I am not sure why the change to the colors was made, or whether its severe negative impact on Wikisource was considered. The colors on an Index page are supposed to be vivid, even garish, so that different colors marking each page of the book can be easily spotted and distinguished. Post change, I can't tell the difference between pink, purple, and gray, and can barely tell those apart from yellow. This means I cannot tell at a glance whether a page is intentionally blank, is in need of proofreading, or has been marked by someone asking for specialist assistance. This would be like making the page name and section headers on a Wikipedia article faded yellow, so that people couldn't read them. --EncycloPetey (talk) 18:46, 18 September 2024 (UTC)

If anyone wants to hard code the old colours, feel free to copy from me :D User:Beleg Tâl/common.css —Beleg Tâl (talk) 19:02, 18 September 2024 (UTC)

This could also be the basis of a gadget or local CSS settings in the Mediawiki namespace. —Justin (koavf)❤T☮C☺M☯ 19:10, 18 September 2024 (UTC)

Yeah, I suggested that earlier. If one of the interface admins wants to implement this I think it might be a good idea. —Beleg Tâl (talk) 19:14, 18 September 2024 (UTC)

Would local implementation help IP editors? Or will they be short shrifted until MW corrects the issue? --EncycloPetey (talk) 19:19, 18 September 2024 (UTC)

@Beleg Tâl: I have also (independently it seems!) rediscovered the old colors. My stylesheet is at User:Duckmather/common.css and is arguably simpler than yours. Duckmather (talk) 01:57, 19 September 2024 (UTC)

(The actual changes in the Codex were not breaking, it was a lack of coordination between the Codex people and the ProofreadPage people that led to the latter to start using names that, as of the time of their writing, still meant the same colors, but were about to change.) — Alien  3
3 3 19:18, 18 September 2024 (UTC)

• The surround of the text box in Page: is also much lighter: it used to be a soft blue color, but is now white. This makes it hard to edit. (See this image.) TE(æ)A,ea. (talk) 23:26, 18 September 2024 (UTC)

  I noticed that too. --EncycloPetey (talk) 23:39, 18 September 2024 (UTC)

  For the surround I propose to add:

  .wikiEditor-ui-view, .prp-page-image {

  background-color: #e0eef8;

  }

  to the stylesheet.— M-le-mot-dit (talk) 08:53, 19 September 2024 (UTC)

For those who haven't seen, the above ticket was closed and resolved. Virtually all of the comments are bots posting and talking to one another, but the takeaway is that this should be resolved already. —Justin (koavf)❤T☮C☺M☯ 16:25, 19 September 2024 (UTC)

• It is still very much not fixed. The Page: surround is still the same color. In addition, the Page:s linked from Index:s now display black text, instead of blue text. TE(æ)A,ea. (talk) 23:04, 19 September 2024 (UTC)

  The comment above was about how the colors were faded and they are no longer faded. I don't know why links have turned black now--that is definitely odd and visually confusing--but the initial issue is fixed. If you think that the blue links turning black needs to be resolved, you may want to make another ticket. —Justin (koavf)❤T☮C☺M☯ 23:15, 19 September 2024 (UTC)

  We'll need additional Phabricator tickets for the black links and grayed window border, since they were not mentioned in the faded color ticket. --EncycloPetey (talk) 23:32, 19 September 2024 (UTC)

  What the devs (here @Sohom Datta) did is only revert the page status colors to their old hard-coded values; the actual solution would have been to keep using codex, but use the correct color names instead, and for all the colors PRP uses, since those color names changed at about the same time PRP started using them. @EncycloPetey It's very much the same problem (except for the link colors which were added by Soda to ensure dark mode contrast), so I think it'd be more appropriate to add these to that first ticket. — Alien  3
  3 3 06:03, 20 September 2024 (UTC)

  • @TE(æ)A,ea.: The blue/black colour changed should be fixed by this code in your common.css (at least, it worked for me):

.prp-index-pagelist-page {
	color:blue;
}

Cremastra (talk) 15:30, 27 September 2024 (UTC)

'Wikidata item' link is moving. Find out where...

Apologies for cross-posting in English. Please consider translating this message.

Tracked in PhabricatorTask T66315

Hello everyone, a small change will soon be coming to the user-interface of your Wikimedia project. The Wikidata item sitelink currently found under the General section of the Tools sidebar menu will move into the In Other Projects section.

We would like the Wiki communities feedback so please let us know or ask questions on the Discussion page before we enable the change which can take place October 4 2024, circa 15:00 UTC+2. More information can be found on the project page.

We welcome your feedback and questions.
MediaWiki message delivery (talk) 18:57, 27 September 2024 (UTC)

How to organize public domain sections of copyrighted work

I have recently been scanning some sections (complete works on their own) from a collection of short stories and poems. The compilation copyright in the collection was renewed, but the copyrights to the individual items in the collection were not renewed. How should I go about transcluding these? I currently have them scanned as Short story 1.pdf, Poem 2.pdf, and so on. I was thinking of transcluding them either as just Short story title or, if disambiguation is needed, as Short story title (Collection title). In either case the “notes” field would mention the collection as the source. TE(æ)A,ea. (talk) 16:53, 28 September 2024 (UTC)

Why not put them at Collection title/Short story title, and use {{AuxTOC}} on the main page? It would be a lot less confusing IMO —Beleg Tâl (talk) 00:17, 29 September 2024 (UTC)

• Beleg Tâl: My issue with that is copyright: because there is a copyright in the compilation of works, wouldn’t that violate the compilation copyright? TE(æ)A,ea. (talk) 00:23, 29 September 2024 (UTC)

  Perhaps include in the Header Notes a template notice of where the item was published? The use of the template would allow someone understanding the syntax to locate the items without having us actually compile them together. It would also allow us to easily collect the items together once the renewal ends. This idea isn't a complete solution, but might help. --EncycloPetey (talk) 01:58, 29 September 2024 (UTC)

  • EncycloPetey: In your case, would the title be as my suggestion above? TE(æ)A,ea. (talk) 02:10, 29 September 2024 (UTC)

    I'm honestly not sure how I would title the pages for the individual works. This is an unusual situation that I've only (briefly) considered before, and in that case the issue went away before we had a viable solution. --EncycloPetey (talk) 02:50, 29 September 2024 (UTC)

Final Reminder: Wikisource Conference 2025 Scholarship Deadline

Dear Wikimedians,

This is a final reminder that the scholarship application deadline for the Wikisource Conference 2025 is 29 September 2024. The conference will take place from 14-16 February 2025 in Denpasar, Bali, Indonesia, after a decade-long break.

If you haven’t applied yet, please do so by completing the scholarship application form by 11:59 AM UTC, 29th September 2024.

For any questions, reach out via the Meta Talk page or email us at wikisourceconference@gmail.com.

We look forward to your participation!

Regards, Wikisource Conference 2025 Scholarship Team

MediaWiki message delivery (talk) 17:31, 29 September 2024 (UTC)

Tech News: 2024-40

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

Updates for editors

• Readers of 42 more wikis can now use Dark Mode. If the option is not yet available for logged-out users of your wiki, this is likely because many templates do not yet display well in Dark Mode. Please use the night-mode-checker tool if you are interested in helping to reduce the number of issues. The recommendations page provides guidance on this. Dark Mode is enabled on additional wikis once per month.
• Editors using the 2010 wikitext editor as their default can access features from the 2017 wikitext editor by adding ?veaction=editsource to the URL. If you would like to enable the 2017 wikitext editor as your default, it can be set in your preferences. [17]
• For logged-out readers using the Vector 2022 skin, the "donate" link has been moved from a collapsible menu next to the content area into a more prominent top menu, next to "Create an account". This restores the link to the level of prominence it had in the Vector 2010 skin. Learn more about the changes related to donor experiences. [18]
• The CampaignEvents extension provides tools for organizers to more easily manage events, communicate with participants, and promote their events on the wikis. The extension has been enabled on Arabic Wikipedia, Igbo Wikipedia, Swahili Wikipedia, and Meta-Wiki. Chinese Wikipedia has decided to enable the extension, and discussions on the extension are in progress on Spanish Wikipedia and on Wikidata. To learn how to enable the extension on your wiki, you can visit the CampaignEvents page on Meta-Wiki.
• View all 22 community-submitted tasks that were resolved last week.

Updates for technical contributors

• Developers with an account on Wikitech-wiki should check if any action is required for their accounts. The wiki is being changed to use the single-user-login (SUL) system, and other configuration changes. This change will help reduce the overall complexity for the weekly software updates across all our wikis.

In depth

• The server switch was completed successfully last week with a read-only time of only 2 minutes 46 seconds. This periodic process makes sure that engineers can switch data centers and keep all of the wikis available for readers, even if there are major technical issues. It also gives engineers a chance to do maintenance and upgrades on systems that normally run 24 hours a day, and often helps to reveal weaknesses in the infrastructure. The process involves dozens of software services and hundreds of hardware servers, and requires multiple teams working together. Work over the past few years has reduced the time from 17 minutes down to 2–3 minutes. [19]

Meetings and events

• October 4–6: WikiIndaba Conference's Hackathon in Johannesburg, South Africa
• November 4–6: MediaWiki Users and Developers Conference Fall 2024 in Vienna, Austria

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

MediaWiki message delivery 22:20, 30 September 2024 (UTC)

Template:Ambiguous hyphenation

It is a new template created by Yodin. I think it is better to discuss whether we need/want such a template before it gets into wider usage, because it might potentially be used on a really vast number of pages. Although I understand the motivation of its creation, I am a bit hesitant about its wide usage, wondering if its usefulness is big enough to counterballance the fact that it creates further distracting annotations. Any opinions? -- Jan Kameníček (talk) 19:13, 29 September 2024 (UTC)

To illustrate how widespread it may become: 1 day after its creation it has already got 130 transclusions in page namespace. --Jan Kameníček (talk) 19:23, 29 September 2024 (UTC)

Thank you for raising this; just to say most (maybe all?) of the current 130 transclusions are by me from notes I'd made while proofreading over the past few years. I wanted a way to tag cases where we cannot be sure of what the original text was intended to be, and can only make a best guess. I would also say that if the tooltips are problematic, the template could easily be changed to remove this (I was following {{SIC}} and {{Hyphenation inconsistency}}, etc.), and just appear as plaintext, closer to something like {{sic}}, which is invisible to the reader. In the longer term, I hoped to use these as data points, and try to improve these best guesses based on unambiguously hyphenated words in other works from the same time, by the same printers, publishers, authors, etc., etc. in a more systematic way (I may never get around to this in practice, but if I did I had thought it would be purely opt-in, and primarily for the texts I'd been transcribing, rather than changing others' work). --Yodin^T 20:01, 29 September 2024 (UTC)

Seems helpful. Hyphenation practices vary between time periods, printers, and styles, so accounting for ambiguity, and noting it in the text seems to be a net positive. As annotations go, it is not very big; but it should still be treated as such and used with care. Over-use (i.e. in cases where it's pretty clear but the proofreader decides to hedge their bets and use the template) would be not good, and caution should be advised in the documentation. Cremastra (talk) 23:43, 29 September 2024 (UTC)

Re the use of tooltips and is it too distracting: is a prominent link, in the toolbar, available for all readers, that allows them to "disable tooltips on this page" feasible? Cremastra (talk) 23:45, 29 September 2024 (UTC)

Given the focus on representing the source text exactly, this seems worthwhile to highlight differences we introduce, and is less prone to overuse than {{SIC}} (given that it is constrained by hyphenation use), and as said we can change the display later if we really want to clamp down on tool tips. MarkLSteadman (talk) 02:35, 30 September 2024 (UTC)

You say perfectly what I was trying to say but didn't quite manage: Given the focus on representing the source text exactly, this seems worthwhile to highlight differences we introduce... Cremastra (talk) 20:53, 2 October 2024 (UTC)

Why are unregistered users (IP editors) unable to change the page status of index pages?

Hello all,

Before I get to my real question, a little context:

First, I am aware that according to Wikisource policy: "Page status is visible to all users, though can only be changed by users logged into their Wikimedia user account. As such, IP editors cannot change page status."

Second, for those who aren't aware, when what I consider trusted IP editors contribute to the MC, I often put in bot requests for the pages to be marked proofread, see, e.g. Wikisource:Bot requests/Archives/2022, Wikisource:Bot requests/Archives/2023, Wikisource:Bot requests/Archives/2024 and Wikisource:Bot requests. Besides context, these archives also provide a non-exhaustive list of many of the contributions of IP editors, for the sake of judging the extent/value/accuracy of IP editor proofreading. I say non-exhaustive, because many of the works of IP editors have also been marked proofread manually, and it is this "issue", of manually checking pages which have essentially been proofread, which is motivating this post.

Third, I am aware that according to Wikisource policy: "This means that administrators have access and rights above and beyond the range of normal Wikisource contributors. The added rights generally fall into two categories: maintenance and fighting vandalism." and so appreciate that admins are necessarily going to be a little defensive. But I also think this can become excessive, and that maybe a middle ground can be sought elsewhere (i.e. this discussion).

If you have got this far, onto the real question: how do any and all Wikisource users feel about allowing IP editors to mark pages "without text", "problematic" or "proofread", assuming there are no technical issues prohibiting this change?

At this stage, I do not want to excessively argue the issue, as Wikisource seems to descend into unending discussions far too often. But my reasoning generally follows from a) There are a large number of pages marked proofread by non-IP (logged in) users which are very far from perfect, such that IP edits are of a higher quality than a not-small number of the total proofread pages on Wikisource. However, far from perfect non-IP edits are not subjected to a manual checking of each page marked proofread (besides being tagged as not patrolled), but IP edits + bot requests can easily be opposed on such grounds. b) While I accept that allowing IP editors to mark pages "proofread" could allow a user to mark a page as proofread, and then log in to validate, I still believe most validation is essentially good faith, i.e. it is not easy to detect or oppose when a non-IP (logged-in) user actually validates a page, compared to when they just mark the page as validated for the sake of it.

Hopefully I haven't overlooked anything obvious and thus wasted my time in typing this.

And to summarize, opinions on allowing IP editors to mark pages "without text", "problematic" or "proofread" are welcome.

P.S. Although this post is in a location I actually frequent, if you do have any questions for me specifically, please maintain the good practice of pinging me.

Thanks, TeysaKarlov (talk) 05:00, 21 September 2024 (UTC)

@TeysaKarlov: Do you mean Index: pages, or Page: pages, as the title mentions index, but your message seems to be about pages. — Alien  3
3 3 07:00, 21 September 2024 (UTC)

@Alien333. Sorry for any confusion, the title should have read "of an index's pages" or "of indices' pages", or however it should have best been pluralised and made possessive. To clarify, everything refers to Page: pages. TeysaKarlov (talk) 20:40, 21 September 2024 (UTC)

If IPs have the option to mark page status, this allows any change from any status to any other status. This has been a source of misuse in Wikisource's past. --EncycloPetey (talk) 17:06, 21 September 2024 (UTC)

@EncycloPetey Sorry, time got away from me a little with this, but would you be less concerned if IP editors could only change the page status (without text, problematic or proofread) up until any logged in editor marks the page either proofread or validated. For example, once the logged in editor upgrades the page status, that page becomes indefinitely locked to an IP editor, but can still be changed by other logged in users. Or do you also have other concerns? Regards, TeysaKarlov (talk) 07:27, 1 October 2024 (UTC)

As an example: setting a page to "Without text" also blanks the OCR, which causes problems for other IP editors if there was supposed to be text on the page. Under your proposal, the page would remain blank until a logged user checks it. This means having to additionally patrol "without text" pages, which are normally not much of a problem. This is just one instance which it creates a lot of additional work in a small community. We also have IP editors who hop from address to address. If you find such an IP editor has made a mistake, there is no means to alert them unless you get lucky and message them while they are remaining at an IP. These are just two points that come to mind. I would want additional feedback about other common issues experienced editors have seen or forsee. --EncycloPetey (talk) 07:43, 1 October 2024 (UTC)

@EncycloPetey Thanks for the response, but could you perhaps clarify a few things:

"Without text" also blanks the OCR, which causes problems for other IP editors if there was supposed to be text on the page. - Are you saying that IP users cannot press transcribe text? If this is currently the case, is there any reason changing this would cause further trouble?

This means having to additionally patrol "without text" pages, which are normally not much of a problem. - Why do you have to patrol the pages if the OCR is blanked, given that they aren't likely to have been transcluded into mainspace until they are proofread? The only issues I see in this regard is if one IP user messes with what another IP user is doing, and I am not sure how that creates more work for logged in users.

Thanks, TeysaKarlov (talk) 20:58, 1 October 2024 (UTC)

But allowing such a change means that proofread pages that have been transcluded could be blanked by IPs with the touch of a button, whether purposefully or accidentally. There is nothing in the process of proofreading that distinguished between transcluded pages and untranscluded pages. And if you're an IP, and you come across a blanked page, would you know to use an OCR tool, even if it existed? Would you know to look into the history of the page to see if it had been blanked? Or would you start typing the text again from scratch, or perhaps even skip working on the page? Someone blanking the page might blank raw OCR, or proofread text, or validated text. --EncycloPetey (talk) 21:11, 1 October 2024 (UTC)

@EncycloPetey Given you seem to be especially concerned about without text pages, how does this modified example of an implementation sound: IP editors can mark a page proofread or problematic, but not without text or validated. However, once a logged in user makes any edit on the page (or if you would prefer, even just patrols the page), then the page status is locked to all IP editors, and can only be changed by a logged in user? Regards, TeysaKarlov (talk) 20:30, 2 October 2024 (UTC)

I think it would work if administrators were able to grant IPs a temporary rights to change page status. Rights granted to a specific IP for a designated length of time, after seeing that the IP is active and contributing to Wikisource. The grant would be time limited because IPs come and go. We would not want a permanent change that would then have to be tracked. --EncycloPetey (talk) 18:07, 1 October 2024 (UTC)

The main problem with this is that even our most prolific IP editor is moving between several IP addresses as they work on the Monthly Challenge works. They tend to be on the same address for a session, but the length of the session is variable. So, the period for temporary rights is difficult to predict. Beeswaxcandle (talk) 06:17, 2 October 2024 (UTC)

But then the option is: patrol every page individually versus spot an IP who's back at it and flag them as OK. We typically have only a two or three such repeat IPs on any given day. --EncycloPetey (talk) 20:40, 2 October 2024 (UTC)

@EncycloPetey, @Beeswaxcandle Out of curiosity, does anyone have any further comments about the above, given that at least one IP user is back proofread pages in force? Also pinging @Xover, in the hope of finding out whether any of the above is/isn't viable (i.e. allowing IP editors to mark pages without text/problematic/proofread, so long as no logged in user has made edits to the page, or, temporarily flagging IP's as okay in some way or another). Of course, anyone else who can comment on technical viability, feel free to. Thanks, TeysaKarlov (talk) 20:58, 11 October 2024 (UTC)

Has abuse of IP status been a frequent problem, in the past when it's been allowed? If most IP editors are good-faith, how about tools to revert an editing session or set of editing sessions from IPs? A single bad-faith editor will probably use a predictable set of IPs and also have a predictable pattern in their edits. I find it hard to imagine someone abusing IP editing by marking random pages from random IPs, with no machine-recognisable pattern.

Especially if IP marking is allowed, making the interface a bit easier to learn might be a good idea. We could test it on wiki-naive people and see if they understand it immediately. Making it easier to get started would win us more new people, it always does, in pretty much any context. HLHJ (talk) 00:15, 13 October 2024 (UTC)

Accents in translated foreign works

For works translated into English with accents in the original names or phrases, should we keep those accents? Curuwen (talk) 00:42, 28 September 2024 (UTC)

If you are working on an original translation, then it's up to you. Otherwise, you will need to follow the convention used in the edition that you are proofreading. —Beleg Tâl (talk) 00:49, 28 September 2024 (UTC)

For the actual title or a work or an Author's name used in a wikilink, often a redirect is used (e.g. Author:Moliere to Author:Molière, Quran to Qur'an, etc.) MarkLSteadman (talk) 02:41, 30 September 2024 (UTC)

There are key-combo settings, browser extensions and other tools that make them easier to type, if that's useful?

Diacritics are phonemic in many languages; Kuchen and Küchen are not the same, and an English speaker I knew who walked into a German bakery and tried to buy kitchens caused genuine confusion, resolved only when she gave up on the phrasebook and pointed at the cakes she wanted. Proper names, placenames, and phrases can change meaning according to the diacritics; you might accidentally call someone something insulting by leaving them off. Even if the meanign is clear, someone reading a word without the accents will almost certainly mispronounce it (many languages have hilarious malpropism-phrases stereotypically spoken by language learners who don't understand the accents yet). Rendering "Utúlie'n aurë!" as "Utulien aure!" pretty much guarentees than an English speaker will hideously mispronounce it as "ewe-tlee-en our" or "you-tyoo-lee-en ow-ree" or some such; the diacritics cue stress and syllabification. In extreme cases, the lack of accents can actually make a text unintelligible, as the famous poem Lion-Eating Poet in the Stone Den illustrates. HLHJ (talk) 03:29, 13 October 2024 (UTC)

First of all, aurë entuluva! I agree that lack of accents can cause major confusion. I will err on the side of including accents then. Thanks for your examples. Curuwen (talk) 03:43, 13 October 2024 (UTC)

Hantan tyen! Ironically, in a post just a little further up this page, I spelt "naïve" as "naive". The new javascript reply windows unfortunately do not have the special-character menu that a normal editing window has. Good luck with it! HLHJ (talk) 17:21, 13 October 2024 (UTC)

Curuwen, I've found it (unless this is a default and you already have it). Click "preferences" at the top of the screen, and under the "Editing" tab, tick the box labelled "Enable the editing toolbar This is sometimes called the '2010 wikitext editor'." Click "save". Now you should have a "Special characters" drop-down menu at the top of every editing window. Should make it easier. Unless it was already enabled. HLHJ (talk) 01:56, 15 October 2024 (UTC)

Looking for Indiana/Indianapolis pages to transcribe or proofread

In preparation for the WikiConference North America 2024 editing challenge, I'm looking for any pages within the Indiana or Indianapolis (where the conference will be held) to transcribe or proofread. Can someone point me to outstanding tasks or categories which fall within this scope? OhanaUnited^{Talk page} 14:33, 1 September 2024 (UTC)

• OhanaUnited: You can look at Portal:Indiana, which has a few works. As for more general works, I could set up History of Indianapolis and Marion County, Indiana, Hyman’s Handbook of Indianapolis, A History of Indiana, from Its Exploration to 1850, History of Indiana, from Its Exploration to 1922 (2, 3), The History of Indiana for Boys and Girls, or any other work you may find interesting. TE(æ)A,ea. (talk) 18:07, 1 September 2024 (UTC)

Two other ones, more specifically about Indianapolis: Early Indianapolis, 1919 (27 p.), and Centennial History of Indianapolis, 1920 (72 p.). — Alien333 ( what I did
why I did it wrong ) 22:34, 1 September 2024 (UTC)

Works by Jacob Piatt Dunn could be of interest. See c:Category:Jacob Piatt Dunn. —Justin (koavf)❤T☮C☺M☯ 19:26, 2 September 2024 (UTC)

Thanks for these ideas. I think I will use Index:A standard history of Lake County, Indiana, and the Calumet region (IA standardhistoryo01howa).pdf as demonstration and tutorial. Can someone proofread a few pages for this book so that I can also demonstrate validation to the audience? @Alien333: I like your suggestion for Early Indianapolis, 1919 as the total number of pages is small enough that it can be tackled by all conference participants. Can you set up that publication? OhanaUnited^{Talk page} 22:25, 2 September 2024 (UTC)

Done, here it is: Index:Early Indianapolis.djvu. (You may want to familiarize yourself with WS:SG and H:T for formatting.) Cheers, — Alien333 ( what I did
why I did it wrong ) 23:19, 2 September 2024 (UTC)

The text doesn't seem to be automatically transcribed. Are there additional steps needed to OCR the text? OhanaUnited^{Talk page} 02:54, 3 September 2024 (UTC)

There's a button on the top right, marked "Transcribe text". — Alien333 ( what I did
why I did it wrong ) 11:23, 3 September 2024 (UTC)

If you update the file description page with the actual IA identifier I can regenerate the DjVu with a OCR text layer (I have custom tooling for that). Xover (talk) 12:27, 3 September 2024 (UTC)

Done, assuming you only wanted it to be written somewhere. — Alien333 ( what I did
why I did it wrong ) 12:48, 3 September 2024 (UTC)

@Alien333: Done Xover (talk) 14:11, 3 September 2024 (UTC)

(@Koavf: Early Indianapolis was supposed to be for an editing contest next month. Don't do the next one we set up, will you :) ?)

@OhanaUnited: We're going to have to set up another one, as Koavf already did this one. Fine with Centennial History of Indiana?

@Xover: For curiosity's sake, what do you use for OCR? — Alien333 ( what I did
why I did it wrong ) 15:55, 3 September 2024 (UTC)

Oh sheesh. What a moron. :/ Sorry guys, I just totally misread this. If you really want, I wouldn't be offended if you deleted my work. What an idiot. —Justin (koavf)❤T☮C☺M☯ 15:57, 3 September 2024 (UTC)

I think A standard history of Lake County, Indiana, and the Calumet region should have sufficient number of pages for proofreading and Early Indianapolis for validating. It actually makes the contest verification process simpler by splitting tasks into different books.

@Koavf: it's fine. We will let the editing contest participants focus validation on Early Indianapolis.

@Alien333: I don't see the button that says "transcribe text". Do you need specific userrights to use this tool? Or only on pages with no text transcribed? We are (ok, it's just me at the moment) planning to do an introduction workshop to different sister projects and the newbies are going to ask the same kind of questions as myself. OhanaUnited^{Talk page} 17:30, 3 September 2024 (UTC)

Once again, I have failed upward. Thanks for your graciousness: I'll be sure to not touch that other work. —Justin (koavf)❤T☮C☺M☯ 17:32, 3 September 2024 (UTC)

Errm, are you sure that when you edit a page in Page: namespace, you don't see anything that looks like what's described there? It's not a very visible button, but normally it should be there. This is supposed to work with all skins, and to need nothing special.

If we're lucky, Xover or someone else will graciously do the OCR beforehand, but this really, really isn't supposed to happen. — Alien333 ( what I did
why I did it wrong ) 17:40, 3 September 2024 (UTC)

Nope. I don't see anything like that on the top right. I remember seeing this button during demonstration session at Wikimania Singapore last year. I see buttons like page logs, analysis, search and subpages. I'm on Firefox and even tried Chrome (and god forbid, Microsoft Edge). But definitely nothing related to OCR on my end! That's why I thought I didn't have the userrights to do OCR yet. OhanaUnited^{Talk page} 05:16, 4 September 2024 (UTC)

Would you mind uploading (locally) a screenshot of what the editing window looks like for you in Page: namespace? If the OCR button is missing you might have other problems. — Alien333 ( what I did
why I did it wrong ) 07:33, 4 September 2024 (UTC)

Here is how it looks on my end. OhanaUnited^{Talk page} 21:53, 4 September 2024 (UTC)

Aaand in the end it was just a question of enabling the editing toolbar (also called 2010 wikitext editor, in the Editing section of preferences). I'd forgotten that that toolbar was not default. Note: while we're at it, gadgets that are not default but that I think greatly facilitate editing experience and should be recommended to new editors (by label):

• Preload useful templates such as header, textinfo and author in respective namespaces.
• Add a toolbar button to check for and insert a paragraph-breaking {{nop}} at the end of the previous page.
• Running headers: Load running headers from surrounding pages

— Alien333 ( what I did
why I did it wrong ) 22:25, 4 September 2024 (UTC)

Yes. It is now showing on my end. Why isn't the editing toolbar enabled by default? And is there a particular "preferred" OCR? Or pick the one that does the best job for that page?

I think what you described regarding headers and textinfo may be too advanced for complete newbies to the project. The purpose of the tutorial session and the editing challenge is to get existing editors to try their hands on editing in other sister projects. OhanaUnited^{Talk page} 16:56, 5 September 2024 (UTC)

For normal text, use the Google OCR mode, it's god the best accuracy, most of the time. It has a few drawbacks, in which cases it's better to use Tesseract:

• It's quite bad at locating columns of text, e.g. gives "texta textb textc textd" in a column layout like this: texta
  textctextb
  textd rather than the correct "texta textc textb textd". This is also a problem for TOCs.
• It always transcribes Small Caps as CAPITALS, which means you have to retype it, whereas Tesseract at least tries to render it in the correct case, so if you've got lots of smallcaps you might want tesseract.

— Alien333 ( what I did
why I did it wrong ) 17:38, 5 September 2024 (UTC)

Just finished sister projects presentation which included Wikisource. 3 new editors joined during the session, including one who's fluent in multiple languages and participated in non-English Wikisource language projects. There will be more activities by new editors between now until Sunday to participate in the editing challenge. OhanaUnited^{Talk page} 18:51, 4 October 2024 (UTC)

The first 48 pages of Index:Constitution of the state of Indiana and of the United States (IA constitutionofst00indi 0).pdf have the 1851 constitution of Indiana, with footnotes. We are always looking to back mosre copies of constitutional documents with scans of published copies. --EncycloPetey (talk) 21:17, 4 October 2024 (UTC)

We have finished the challenge. About 6-8 editors contributed to Wikisource part of the challenge. And out of those contributors, 2-4 are brand new editors. During the tutorial session, I have observed Japanese, Korean and Spanish Wikisource being edited as well. Next year's event will take place in New York City, and you will find me bugging you guys again this time next year :) OhanaUnited^{Talk page} 21:24, 21 October 2024 (UTC)