Wikisource:Scriptorium

SpBot archives all sections tagged with {{section resolved|1=~~~~}} after 3 days and sections whose oldest comment is older than 30 days.

Proposals

Serialized works in periodicals (voting)

The problem has been discussed for a long time below at #Serialized works in periodicals (note especially the part summarizing advantages and disadvantages of each option), so I think it is time to start voting. --Jan Kameníček (talk) 20:25, 25 August 2024 (UTC)

1. Version/translation page, such as Fame (Čech)

   Oppose. The proper use for this translation page would be to have one item, Fame (Čech, Selver tr.), which would in turn be either 2. or 3. below. TE(æ)A,ea. (talk) 23:09, 25 August 2024 (UTC)

   Weak support. If we otherwise have a versions/translations page, listing the parts of a work under the version serialized is appropriate. Creating a new versions page for every serialised work that only contains one version is inappropriate. --Xover (talk) 05:30, 27 August 2024 (UTC)

    Oppose. Unless there is another version/edition, then this isn't an appropriate use of a versions page. Beeswaxcandle (talk) 07:31, 27 August 2024 (UTC)

   Weak  Support: This is an excellent solution where it works, but I don't think it should be the standard solution across the board. —Beleg Tâl (talk) 13:23, 27 August 2024 (UTC)

2. Auxilliary subpage with an AuxToC, such as The Czechoslovak Review/A Tale of Young Blood of '48

    Support --Jan Kameníček (talk) 20:25, 25 August 2024 (UTC)

   Oppose. This is improper because there isn’t a whole work within the Review by that title; the only thing within the Review (at the first level, which is where this is) are volumes. TE(æ)A,ea. (talk) 23:09, 25 August 2024 (UTC)

    Oppose per TE(æ)A,ea.. --Xover (talk) 05:30, 27 August 2024 (UTC)

    Oppose per Te(æ)A,ea's cogent argument. Beeswaxcandle (talk) 07:31, 27 August 2024 (UTC)

    Support, this seems to me the only solution that respects the relationship between the edition of the serialized work, and the edition of the periodical within which it was published. It is perhaps worth pointing out that we can have separate sections on the top level page for "volumes" and "serialized works". —Beleg Tâl (talk) 13:23, 27 August 2024 (UTC)

    Support preserves the relation to the periodical while providing the complete work.--Prosfilaes (talk) 20:28, 27 August 2024 (UTC)

    Oppose --EncycloPetey (talk) 22:50, 28 August 2024 (UTC)

3. Mainspace page with an AuxToc similar to point 2. above, such as Forerunners of the Russian Revolution

    Support --Jan Kameníček (talk) 20:25, 25 August 2024 (UTC)

   Support. This is the best approach. TE(æ)A,ea. (talk) 23:09, 25 August 2024 (UTC)

    Support --RaboKarbakian (talk) 15:53, 26 August 2024 (UTC)

    Support --Yodin^T 17:03, 26 August 2024 (UTC)

    Support - Probably the only option here that doesn't have serious issues, as per TE(æ)A,ea etc. Arcorann (talk) 00:15, 27 August 2024 (UTC)

    Support SnowyCinema (talk) 00:55, 27 August 2024 (UTC)

    Oppose per the point TE(æ)A,ea. made for option #2: we're creating an edition out of whole cloth that did not previously exist and is yet another step down the slippery slope. And once you've listed them on a faux publication page you're going to want to link them together, so now it either gets double navigation (faux publication + real publication) or it only gets the faux publication and loses its original publishing context. This is a very bad idea. --Xover (talk) 05:30, 27 August 2024 (UTC)

   • Xover: What makes it different, in my mind, is that with 3. (as opposed to 2.), we’re not claiming that there is some published edition which exists (insofar as being one singular unit). My problem with 2. is that it logically indicates that there is a top-level subdivision “A Tale of Young Blood of ’48” within the larger (periodical) work The Czechoslovak Review. This does not happen with 3. because you recognize that the work (as an entire work) is not one, top-level subdivision, but is actually a number of lower-level subdivisions. I don’t think that this constitutes “creating an edition out of whole cloth that did not previously exist” because it is a real edition. Just because the chapters (sections, &c.) were published (1) with other material (2) in separately published issues of a periodical doesn’t mean that the material doesn’t constitute an “edition” of that work—in most cases it is the original edition and holds greater weight thereby. As for the double-navigation issue, that is already done without any issues. It is also not an unnatural, original (as in Wikisource-based editorial) modification to the text; these individual sections will often mention both that they are continuations and that they will be continued, and there’s no reason to not add that connection to the header template. I don’t know how this sort of collection would “lose[] its original publishing context,” though—wouldn’t that information be listed on the main page and be inherent in the structure of all of the (in-periodical) chapters? TE(æ)A,ea. (talk) 11:57, 27 August 2024 (UTC)

    Oppose this is a blunt force solution and loses the context of its publication in the periodical. Beeswaxcandle (talk) 07:31, 27 August 2024 (UTC)

   Context can be added in the note parameter of the header. --Jan Kameníček (talk) 16:47, 27 August 2024 (UTC)

    Oppose: placing the serialized work as a separate top-level page from the periodical within which it was published implies that they are two different publications, which is false and misleading. —Beleg Tâl (talk) 13:23, 27 August 2024 (UTC)

   I might change this from strong oppose to weak oppose if a new, visually distinct, header template were to be used for this purpose. —Beleg Tâl (talk) 13:24, 27 August 2024 (UTC)

   Weak  Support doesn't preserve the link to the periodical, but makes the work as a whole available.--Prosfilaes (talk) 04:49, 28 August 2024 (UTC)

    Support --EncycloPetey (talk) 22:50, 28 August 2024 (UTC)

   Weak  Oppose – not terrible, but I prefer Beeswaxcandle's suggestion below. This would be my second pick. Cremastra (talk) 21:08, 29 August 2024 (UTC)

    Support--IdiotSavant (talk) 04:37, 7 September 2024 (UTC)

    Support—Akme (talk) 11:42, 7 September 2024 (UTC)

    Support Perhaps a template could be used to mark such pages as "virtual" editions. Bloated Dummy (talk) 22:00, 7 September 2024 (UTC)

4. Portal, such as Portal:Sherlock Holmes (UK Strand)

   Weak  Support --Jan Kameníček (talk) 20:25, 25 August 2024 (UTC)

   This is appropriate in some circumstances, but not all (or even most). I think it is good for the “Sherlock Holmes” stories because they are not in a serial order, there are other versions which have been brought together, and there are also simply a decent number of them (which all have different names because they are unique stories rather than chapter-like divisions). TE(æ)A,ea. (talk) 23:09, 25 August 2024 (UTC)

   This seems like a good choice for entire series, but I'm not sure this would work well for individual stories, especially ones that aren't part of any series. --Yodin^T 17:03, 26 August 2024 (UTC)

    Comment This can be the best approach in some circumstances, though I agreee that in most situations it may not be the best practice. We can choose one of these options as generally best practice, while also describing other special cases and the possible means to approach those complex or special circumstances. --EncycloPetey (talk) 01:20, 27 August 2024 (UTC)

    Support Not to overstate the perfection of this approach (it certainly isn't), but this is the only approach that does not involve us creating entirely new editions that do not exist in the real world. It is therefore the very-imperfect-but-safe option. We also haven't discussed this holistically before going to voting (Jan, you in particular should be sensitive to that issue). For example, our periodical pages suffer from exactly the same problem (our top-level page for, e.g., The New York Times corresponds to nothing physically published) so any discussion and potential change of practice should address both issues. For that discussion I have some ideas; for this narrowly-scoped one I have answered narrowly. --Xover (talk) 05:30, 27 August 2024 (UTC)

    Oppose Portals are for collections of works, rather than for single works. Beeswaxcandle (talk) 07:31, 27 August 2024 (UTC)

    Comment The line between those two is not always clear, as evidenced by Portal:Bible, which is both a work and a collection of works. The First Folio of Shakespeare is likewise both a work and a collection of works. And many "collections" of poetry, like The Waste Land by T. S. Eliot or Flowers of Evil by Baudelaire, also blur the line. --EncycloPetey (talk) 20:44, 27 August 2024 (UTC)

    Comment A portal would be inappropriate if used only to represent a single edition of a serialized work. However, I think it could be acceptable if the idea were modified slightly to be more, well, portal-esque. For example, Portal:Sherlock Holmes (UK Strand) must allow not only instalments of Sherlock Holmes in the UK Strand, but any work related to the publication of Sherlock Holmes within the Strand (because that's what portals are for). This would mean that the portal has a dual purpose, but I think that is acceptable (similar to option #1 with versions pages). —Beleg Tâl (talk) 13:23, 27 August 2024 (UTC)

   I suppose I should also mention that, as far as I am aware, there is still some controversy over whether periodicals should be placed in Portal space anyway ... —Beleg Tâl (talk) 13:26, 27 August 2024 (UTC)

    Oppose Portals aren't for works; they're for community made subjective collections.--Prosfilaes (talk) 20:28, 27 August 2024 (UTC)

    Comment So, you object to Portal:United Nations Security Council Resolutions and Portal:Appendix Vergiliana because they are for works and are not subjective? --EncycloPetey (talk) 20:33, 27 August 2024 (UTC)

   Neither of them are works; they're collections. The United Nations Security Council Resolutions I might move to mainspace, as a periodical. My instinct with Appendix Vergiliana would be to stuff it under Author:Virgil. Also note that Appendix Vergiliana also collects information about Vergiliana, and portals about subjects is definitely in scope for a portal.--Prosfilaes (talk) 04:48, 28 August 2024 (UTC)

   I'm confused then by your comment that Portals aren't for works, or why UN Security Resolutions aren't works. --EncycloPetey (talk) 04:52, 28 August 2024 (UTC)

   We're talking about a unitary work here, not an arbitrary collection. The UN Security Resolutions are works, but the set as a whole also form a work. Portals aren't for works; they're for collections of works.--Prosfilaes (talk) 22:33, 28 August 2024 (UTC)

   With regard to the Vergiliana: if the works were written by Virgil, then both those works and any articles about them would appear on Author:Virgil. Moving them to a Portal keeps the two together. If the works were moved to Virgil's Author page, then the works about them would not be, since they are not about works by Virgil, and thus there would be no place to collect both sets of items together. It also dilutes what we have if the works are listed under an author who did not write them. --EncycloPetey (talk) 04:56, 28 August 2024 (UTC)

   Presumably if the works were moved to Author:Virgil, so would the works about the works. I think this is sort of off-topic; it doesn't have much to do with this vote, nor does is anyone proposing a change to that right now.--Prosfilaes (talk) 22:33, 28 August 2024 (UTC)

Having opposed all four suggestions, what's left? Transcluding a work in its context as a part of a periodical and providing double linking: a) to the previous & next works in the issue of the periodical; b) to the previous & next sections of the work. If a work is published in more than one context, then a versions page can point to the first section of the work in the periodical and to the complete publication in a different medium. Beeswaxcandle (talk) 07:31, 27 August 2024 (UTC)

 Support as 1 misuses versions pages, 2 & 3 put it at the wrong level, and 4 misuses portals. — Alien333 ( what I did
why I did it wrong ) 20:33, 27 August 2024 (UTC)

• Oppose. This is the worst of the options (on its own); it merely leaves the job incomplete. Your solution for versions is wrong, as one section of a work is not a version of an entire work. TE(æ)A,ea. (talk) 21:13, 27 August 2024 (UTC)

Not sure it would be possible to export to epub using this method (unlike options 2–4 above)? --Yodin^T 21:33, 27 August 2024 (UTC)

Beeswaxcandle mentioned somewhere in the voting about duplicates in search results. I got to thinking about robots.txt (the way to keep search engines from web pages) and was wondering if there would be a way to prevent the duplicates from getting into the local search results. Perhaps a template similar but different to AuxTOC that would do this?--RaboKarbakian (talk)

 Support: this is definitely a cool idea, since it allows readers to read through in either context (periodical part / next serial installment). Cremastra (talk) 21:08, 29 August 2024 (UTC)

We already do this, I believe? At least, pages such as Popular_Science_Monthly/Volume_87/September_1915/A_History_of_Fiji_III have this sort of navigation bar. Arcorann (talk) 00:12, 30 August 2024 (UTC)

I also 'sidelink' extensively in The Strand Magazine. See for example

https://en.wikisource.org/wiki/The_Strand_Magazine/Volume_4/Issue_20/Zig-Zags_at_the_Zoo

https://en.wikisource.org/wiki/The_Strand_Magazine/Volume_2/Issue_7/Illustrated_Interviews

https://en.wikisource.org/wiki/The_Strand_Magazine/Volume_4/Issue_19/A_Romance_from_a_Detective%27s_Case-Book Qq1122qq (talk) 13:03, 3 September 2024 (UTC)

 Oppose, as this is both incompatible with what we use previous / next for here as well as incompatible with what Wikidata does with those values. That's in addition to problems with epub, mentioned above. --EncycloPetey (talk) 21:37, 29 August 2024 (UTC)

 Comment this is already what we do, and is separate from the options listed above, so I think any proposal to stop doing this should require a separate proposal. —Beleg Tâl (talk) 20:12, 2 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)

Bot approval requests

• See Wikisource:Bots for information about applying for a bot status
• See Wikisource:Bot requests if you require an existing bot to undertake a task

Repairs (and moves)

Designated for requests related to the repair of works (and scans of works) presented on Wikisource

See also Wikisource:Scan lab

Page moves in Index:Mathematical collections and translations, in two tomes - Salusbury (1661).djvu

The existing scan is incomplete, so I will be replacing it with a complete version. To support this, please carry out the following page moves.

• Index page name = Index:Mathematical collections and translations, in two tomes - Salusbury (1661).djvu
• Page offset = 1 (i.e. /10 moves to /11)
• Pages to move = "10-456"
• Reason = "inserted missing pages"

Thanks Chrisguise (talk) 16:28, 4 September 2024 (UTC)

@Chrisguise: Done Xover (talk) 16:47, 4 September 2024 (UTC)

Thanks. I've uploaded the new file. Chrisguise (talk) 18:25, 4 September 2024 (UTC)

Hi, really sorry about this but I missed a couple of variations when I requested the move above. Could you please do the following:—

• Index page name = Index:Mathematical collections and translations, in two tomes - Salusbury (1661).djvu
• Page offset = 1 (i.e. /115 moves to /116)
• Pages to move = "115-274"
• Page offset = -1 (i.e. /409 moves to /408)
• Pages to move = "409-454"
• Reason = "realigned pages"
• Delete = /705 & /706
• Reason = "pages not in work"

Thanks Chrisguise (talk) 14:21, 5 September 2024 (UTC)

Hi (again). Could you hold fire on this request. There's something odd going on with the index page. When I click on some pages they show a page image from the new file (gold trim to covers is visible) and some show the original file (plain brown cover edges visible). I've tried purging the Commons page where the file resides and the individual pages on WS, and things seem to be improving (slowly) but everything has clearly not properly updated yet. Chrisguise (talk) 14:42, 5 September 2024 (UTC)

@Xover Whilst there are still one or two pages of the old scan showing, they do not affect the pages needing to be moved. Could you do the two moves and deletion set out above? Thanks, Chrisguise (talk) 15:41, 10 September 2024 (UTC)

Other discussions

Serialized works in periodicals

I think we should come to some general recommendation how serialized works in periodicals should be dealt. At the moment each contributor deals with them differently, which is imo a problem with periodicals especially, as different attitudes within one periodical sometimes occur.

I have seen two attitudes which make sense in my opinion. The one which I slightly prefer is creating a version/translation page containing one version/translation of the work with links to all parts of the series. Although we usually create version pages only when we have at least two editions of the work, in similar cases it could be acceptable to create it for one edition only. Once more editions appear here, they can be easily added. An example of such a page is e. g. Fame (Čech).

Another attitude which also makes sense is creating a special subpage of the periodical containing just an auxilliary ToC with links to individual parts of the work. An example can be seen at The Czechoslovak Review/A Tale of Young Blood of '48. IMO there is some minor disadvantage: subpages of the main page are only volumes, while articles are subpages of these volumes or of individual issues. With this attitude the subpages with AuxToC would be on the same level as volumes, which is a bit confusing. Besides, not everybody (e.g. me) likes how the pages with pure AuXToC look, but that is very subjective, I admit. Despite these minor objections, I would not have any problem accepting this attitude if more people prefer it, because some unification is really needed.

There are also other related things which might be discussed, like whether and how individual parts should be interlinked from their headers etc., but I suggest leaving such discussions for later or at least making them separate from this one, not to lose the main goal. -- Jan Kameníček (talk) 16:46, 13 July 2024 (UTC)

Once upon a time, I was working on a magazine which had a Jules Verne short story serialized within. I thought to keep the magazine in tact, but to also make a separate instance where the story was complete (Magazine/Title of story) so that the work could be downloaded intact for my ereader device. That effort was deleted, citing something officious that I did not read. But it was easy to do (set up the separate instance) and perhaps a way to include it in the main toc but exclude it from being downloaded with the whole magazine volume could be found. And the officious document changed accordingly.--RaboKarbakian (talk) 15:27, 14 July 2024 (UTC)

If I understand it right, it was quite close to The Czechoslovak Review/A Tale of Young Blood of '48, only the AuxToC was not used in your case. If this solution prevails, I think the AuxToC should be used. --Jan Kameníček (talk) 19:04, 14 July 2024 (UTC)

Jan Kameníček: I made a Volume/whole_work and transcluded all of the parts to there (as well as how they appeared in the journal), it was crufty, klutzy and overall not elegant, really. Since then, I have come to more understanding of the exporter. To my understanding, The Czechoslovak Review/A Tale of Young Blood of '48 would indeed work with the exporter for the purpose of making an epub, etc version of that one specific work. I thank you for putting this all here so I had the time to think about it. And also agree that it is the best, cleanest and most non-redundant of solutions to the need for a recommendation and more importantly (to me), a means to export 'just the work' into other formats.--RaboKarbakian (talk) 15:15, 16 July 2024 (UTC)

I personally think that The Czechoslovak Review/A Tale of Young Blood of '48 is the closest to a "good" solution of all the various ideas I've seen. —Beleg Tâl (talk) 19:22, 14 July 2024 (UTC)

• I've worked on a few of these recently, and agree that it would be good to develop a guideline. I had been following Wikisource:Serial works, and creating a separate single-page transclusion in addition to transcluding them as part of the periodical (e.g. 1, 2, 3, 4, 5). I'd also used the versions page approach you described, with sub-bullet points for each part; I'm not against this, but haven't been very happy with it, as it means serial works take up so much more space on these pages than other works, and I also dislike readers having to click through many extra pages to view the work they want to read. Hadn't come across The Czechoslovak Review/A Tale of Young Blood of '48 method before; I understand what you mean that it might seem odd to have subpages that aren't just the volumes, but this does seem like a logical place to put these pages (I personally don't mind AuxTOC only pages, but you could also add the source text's title and date of first publication to the page's header notes if it was a translation, which would make the page a bit less empty). It looks like a good approach to me, as this could be the page you link to on any author/versions/translations page, and would avoid having to link to all the sub-parts on those pages. --Yodin^T 14:03, 16 July 2024 (UTC)

OK, so let's go with auxilliary subpages. --Jan Kameníček (talk) 13:46, 2 August 2024 (UTC)

I have added a section to Wikisource:Style guide#Serialized works in periodicals, comments are welcome. --Jan Kameníček (talk) 14:26, 2 August 2024 (UTC)

Normally, comments come first, then the community votes on the changes, and only then is the core Wikisource document changed in accordance with the proposal. Changing the core policy document, then asking for comment is backwards. --EncycloPetey (talk) 17:15, 2 August 2024 (UTC)

I'll note, Jan, that the one time I can recall you and I disagreeing vehemently on something it was because I had failed to make sure there was sufficient opportunity to discuss the proposal before it even came to a vote. This is a difficult issue and rushing into establishing a new status quo is not appropriate. Xover (talk) 07:33, 3 August 2024 (UTC)

I did not consider the change controversial after the discussion above where only opinions in favour of one solution appeared and nobody seemed to add anything else relevant to it. Anyway, I have reverted the change for now. --Jan Kameníček (talk) 08:04, 3 August 2024 (UTC)

Yeah, I know the feeling. :) It's hard sometimes to gauge what's controversial or not, and getting the community to even engage in the discussion can be an uphill battle. Thanks for reverting; and thanks for trying to figure out a solution to this issue. I agree that it's something that should be addressed somehow. Xover (talk) 09:13, 3 August 2024 (UTC)

The established tool we have for this is a Portal. Why is that not sufficient? Xover (talk) 07:35, 3 August 2024 (UTC)

It is a possibility too, though it does not seem to be used by contributors for serialized works in periodicals at the moment. Portals are probably more understood as a tool to gather different works on a specific subject. But I am not against this solution either. --Jan Kameníček (talk) 08:12, 3 August 2024 (UTC)

I thought it would be good to link to some example of such a portal containing a single edition of a work serialized in a periodical, but I failed to find any. --Jan Kameníček (talk) 08:48, 3 August 2024 (UTC)

Portal:Sherlock Holmes (UK Strand).

Portals are the tool we have for arbitrarily grouping texts by properties other than the specific forms they were originally published in, and can be on any arbitrary (but consistent and logical) grouping principle. The above example was created because a contributor who shall remain nameless was a bit more than averagely concerned with first editions. Personally I think versions pages like The Problem of Thor Bridge would have been sufficient for this case, but it should illustrate the general approach that's also adaptable to this use case.

Not that portals are by any means perfect, but it's the established tool for this kind of need and I am extremely sceptical of any approach that creates pseudo-editions of one story within the structure of a periodical. Xover (talk) 09:07, 3 August 2024 (UTC)

Just noting that the linked portal does not contain one serialized work in a periodical but a series of works by one author in a periodical. (Also not sure why AuxToC is used in that portal.) This portal is imo not really necessary, though possible, while parts of a serialized work really need to be gathered somewhere so that they can be linked to as a whole when needed. Although I originally also slightly preferred the version pages, now I realized that once another edition is added to such a version page, it cannot be used for linking to a particular periodical edition only. For linking purposes we need a solution for gathering individual parts of specific editions in a periodical, which can be done by an auxilliary subpage of the periodical or by a portal. --Jan Kameníček (talk) 10:04, 3 August 2024 (UTC)

No more opinions seem to come so I think we can start voting soon. Before doing so, let's summarize the options we have:

1. Version/translation page, such as Fame (Čech)

   Advantages: Easy to create, no special tool needed.

   Disadvantages: Not suitable to be linked to if a link to the whole work is needed, as other versions/translations may be added to the page later. Some people also may not like a version page containing just one version.

2. Auxilliary subpage with an AuxToC, such as The Czechoslovak Review/A Tale of Young Blood of '48.

   Advantages: Solves the linking problem mentioned above.

   Disadvantages: Creates a subpage that was not included in the original periodical.

3. Portal, such as Portal:Sherlock Holmes (UK Strand) (although probably without the AuxToC template)

   Advantages: Solves the linking problem mentioned above. It is an established tool.

   Disadvantages: Not a current practice to use it for serialized works. It contradicts the definitions of the portal at Wikisource:Portal guidelines (Portals are pages intended to serve as "main pages" for specific topics or areas) and at Help:Portals (Portals exist as a gateway to a subject area on Wikisource), which would have to be extended (which can be done easily).

So let's wait for some more time if some other suggestion appears and then I will start the voting about them. --Jan Kameníček (talk) 13:21, 14 August 2024 (UTC)

If there's a problem having these hosted as subpages of the periodical, how about an AuxTOC in mainspace, so basically the same as 2, but moved to A Tale of Young Blood of '48 (The Czechoslovak Review) instead? --Yodin^T 15:21, 14 August 2024 (UTC)

Thanks, will add it to the list. --Jan Kameníček (talk) 19:30, 14 August 2024 (UTC)

Voting started above at #Serialized works in periodicals (voting). --Jan Kameníček (talk) 20:29, 25 August 2024 (UTC)

Template:Signature

Shouldn't this (transcluded on 178 pages) be replaced to a redirect to Template:missing image? Asking because I don't think we should treat signatures as any other image. — Alien333 (what I did & why I did it wrong) 14:35, 11 August 2024 (UTC)

Boldly Done, since I can't see the value of having a separate template, apart from unnecessary confusion. If there is value, of course feel free to revert. Cremastra (talk) 23:23, 24 August 2024 (UTC)

Undone. The value of this template is that the signature may not be legally reproduced in some situations, not that we are missing an image. --EncycloPetey (talk) 00:50, 25 August 2024 (UTC)

In what situations would a signature not be PD in the US per c:COM:SIG US? Sure, some local hosting may be required, but nothing thst can't be added here. — Alien333 ( what I did
why I did it wrong ) 01:04, 25 August 2024 (UTC)

The link you pointed to lists one situation where US copyright would protect the signature. We also have situations where the signature was redacted or otherwise not reproduced in dissemination of a document. In those situations, we know a signature was there, but we do no have a scan that reproduces it. --EncycloPetey (talk) 01:08, 25 August 2024 (UTC)

It would be good to give it a documentation specifying that its only use is for artistic signstures (it actually has none), then, vecause in most places where it's been used (like here), it doesn't match that. — Alien333 ( what I did
why I did it wrong ) 01:32, 25 August 2024 (UTC)

• The templates definitely have different purposes. For transcription of texts oftentimes the only part which is necessary is the existence of a signature, whereas for images usually the content of the image matters. EncycloPetey’s comment is also true; most dissertations and government documents (FOIA releases, anyway) will redact signatures so they can’t be illicitly reproduced. TE(æ)A,ea. (talk) 01:29, 25 August 2024 (UTC)

  For redacted signatures, we already have {{redacted}}.

  There are a lot of images that don't have any specific meaning except being there, e.g. there, and we still add them, and consider pages without them to be problematic. I don't see why signatures specifically are not necessary. — Alien333 ( what I did
  why I did it wrong ) 02:15, 25 August 2024 (UTC)

  • Alien333: The “redact” template is for text, where nothing is visible or identifiable as to the original; for redacted signatures, it is clear that it is a signature which is redacted, and in most cases the person who gave the signature is identified. Another concern is with the actual purposive nature of signatures; in most cases each signature will be (technically) a unique image, in many cases obscured by surrounding text. In no case is it necessary for the visible signature to be distinguished from, say, the text Signature. Ornamental images are of doubtful utility but are still part of the text. TE(æ)A,ea. (talk) 02:44, 25 August 2024 (UTC)

    Once it's redacted, a signature looks just like a block of text.

    Can you clarify why it's in no case necessary for the visible signature to be distinguished from, say, the text Signature?

    What keeps us from replacing all images by an alt text, at this rate?

    And there are also illustrations out of copyright, and we probably (?) already have a template for that, so why should signatures be different? — Alien333 ( what I did
    why I did it wrong ) 13:38, 25 August 2024 (UTC)

Documentation for Template:brace3

See title. On the one hand, I'd like to migrate from {{brace2}} if possible due to the issues of using MathJax to format a single brace; on the other hand, I've had a multitude of problems getting it working, and documentation is non-existent. Can someone help? Arcorann (talk) 02:15, 19 August 2024 (UTC)

(Pinging @ShakespeareFan00 as they were the last to work on it). — Alien333 ( what I did &
why I did it wrong ) 11:36, 19 August 2024 (UTC)

@Arcorann: I added documentation to it. Nosferattus (talk) 14:41, 25 August 2024 (UTC)

Coming soon: A new sub-referencing feature – try it!

Hello. For many years, community members have requested an easy way to re-use references with different details. Now, a MediaWiki solution is coming: The new sub-referencing feature will work for wikitext and Visual Editor and will enhance the existing reference system. You can continue to use different ways of referencing, but you will probably encounter sub-references in articles written by other users. More information on the project page.

We want your feedback to make sure this feature works well for you:

• Please try the current state of development on beta wiki and let us know what you think.
• Sign up here to get updates and/or invites to participate in user research activities.

Wikimedia Deutschland’s Technical Wishes team is planning to bring this feature to Wikimedia wikis later this year. We will reach out to creators/maintainers of tools and templates related to references beforehand.

Please help us spread the message. --Johannes Richter (WMDE) (talk) 10:36, 19 August 2024 (UTC)

DEFAULTSORT

I've noticed that some pages that are missing {{DEFAULTSORT}}, are still being sorted properly on Category pages. Does this mean that {{DEFAULTSORT}} is no longer needed? —Beleg Tâl (talk) 13:29, 19 August 2024 (UTC)

I remember having read somewhere that {{header}} & co now do this auto. — Alien333 ( what I did &
why I did it wrong ) 18:07, 19 August 2024 (UTC)

Yep, {{header}} and {{translation header}} automatically handle articles now! See Template:Header/doc#defaultsort for details. —CalendulaAsteraceae (talk • contribs) 04:39, 20 August 2024 (UTC)

Does {{dab}} do that too? — Alien333 ( what I did &
why I did it wrong ) 11:46, 20 August 2024 (UTC)

It does in mainspace, where it uses Module:Header; {{author}} has its own sorting rules and {{portal header}} does not currently do any autosorting. —CalendulaAsteraceae (talk • contribs) 17:07, 20 August 2024 (UTC)

Tech News: 2024-34

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

• Editors who want to re-use references but with different details such as page numbers, will be able to do so by the end of 2024, using a new sub-referencing feature. You can read more about the project and how to test the prototype.
• Editors using tracking categories to identify which pages use specific extensions may notice that six of the categories have been renamed to make them more easily understood and consistent. These categories are automatically added to pages that use specialized MediaWiki extensions. The affected names are for: DynamicPageList, Kartographer, Phonos, RSS, Score, WikiHiero. Wikis that have created the category locally should rename their local creation to match. Thanks to Pppery for these improvements. [1]
• Technical volunteers who edit modules and want to get a list of the categories used on a page, can now do so using the categories property of mw.title objects. This enables wikis to configure workflows such as category-specific edit notices. Thanks to SD001 for these improvements. [2][3]

Bugs status

• Your help is needed to check if any pages need to be moved or deleted. A maintenance script was run to clean up unreachable pages (due to Unicode issues or introduction of new namespaces/namespace aliases). The script tried to find appropriate names for the pages (e.g. by following the Unicode changes or by moving pages whose titles on Wikipedia start with Talk:WP: so that their titles start with Wikipedia talk:), but it may have failed for some pages, and moved them to Special:PrefixIndex/T195546/ instead. Your community should check if any pages are listed there, and move them to the correct titles, or delete them if they are no longer needed. A full log (including pages for which appropriate names could be found) is available in phab:P67388.
• Editors who volunteer as mentors to newcomers on their wiki are once again able to access lists of potential mentees who they can connect with to offer help and guidance. This functionality was restored thanks to a bug fix. Thank you to Mbch331 for filing the bug report. You can read about that, and 18 other community-submitted tasks that were resolved last week.

Project updates

• The application deadline for the Product & Technology Advisory Council (PTAC) has been extended to September 16. Members will help by providing advice to Foundation Product and Technology leadership on short and long term plans, on complex strategic problems, and help to get feedback from more contributors and technical communities. Selected members should expect to spend roughly 5 hours per month for the Council, during the one year pilot. Please consider applying, and spread the word to volunteers you think would make a positive contribution to the committee.

Learn more

• The 2024 Coolest Tool Awards were awarded at Wikimania, in seven categories. For example, one award went to the ISA Tool, used for adding structured data to files on Commons, which was recently improved during the Wiki Mentor Africa Hackathon. You can see video demonstrations of each tool at the awards page. Congratulations to this year's recipients, and thank you to all tool creators and maintainers.
• The latest Wikimedia Foundation Bulletin is available, and includes some highlights from Wikimania, an upcoming Language community meeting, and other news from the movement.

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

MediaWiki message delivery 00:53, 20 August 2024 (UTC)

{{Pline}} problems with overflow

At Page:United States patent 647007.pdf/3 I have a wide table and plines. For the wide table, I used "overflow:auto;" in the style sheet which I think caused the plines to not show. While typing this, it occurred to me to restrict the overflow to the table; but perhaps pline could be fixed for this? Thanks!--RaboKarbakian (talk) 14:59, 24 August 2024 (UTC)

The {{pline}} template is to specify line numbers. You've used auto-wrapping for the text, removing the line breaks that were previously there, so no one will be able to tell which text was on line 10 as aopposed to line 9 or line 11 anymore. There is therefore no reason to try to retain the line numbers. Line numbers are meant to be keyed to specific rows of text. --EncycloPetey (talk) 15:11, 24 August 2024 (UTC)

Ignoring the off-topicness: I have found the anchored plines to be helpful to these particular texts with their repetitiveness, run-on sentences and overall horribleness as only the marriage between legal and technical languages can be. That particular patent reiterates (and describes) the table contents in those same legal/technical words, even! And certainly, leaving the plines out would be easier.

What is it with this group of editors!?! When it comes to words you are all "AS IT WAS PUBLISHED" {especially with typos) but when it comes to something like this or publisher ornamental images--you don't do that "AS IT WAS PUBLISHED". It is inconsistent and the only way I can remember these conflicting policies is to think "What would the lazy over-literate population do?" Which also makes it easier to forget.</rant>--RaboKarbakian (talk) 13:33, 25 August 2024 (UTC)

But you're not reproducing it as published, since you're removing the line breaks necessary for the line numbers to do their job. And that's the whole point of my previous comment. You have two options: (1) use pline and retain the original line breaks, or, (2) eliminate the line breaks and remove the line numbers. You have created this problem by trying to have your cake and eat it too, but you must instead make a choice. --EncycloPetey (talk) 20:01, 31 August 2024 (UTC)

Sign up for the language community meeting on August 30th, 15:00 UTC

Hi all,

The next language community meeting is scheduled in a few weeks—on August 30th at 15:00 UTC. If you're interested in joining, you can sign up on this wiki page.

This participant-driven meeting will focus on sharing language-specific updates related to various projects, discussing technical issues related to language wikis, and working together to find possible solutions. For example, in the last meeting, topics included the Language Converter, the state of language research, updates on the Incubator conversations, and technical challenges around external links not working with special characters on Bengali sites.

Do you have any ideas for topics to share technical updates or discuss challenges? Please add agenda items to the document here and reach out to ssethi(__AT__)wikimedia.org. We look forward to your participation!

MediaWiki message delivery (talk) 23:20, 22 August 2024 (UTC)

Tech News: 2024-35

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

• Administrators can now test the temporary accounts feature on test2wiki. This was done to allow cross-wiki testing of temporary accounts, for when temporary accounts switch between projects. The feature was enabled on testwiki a few weeks ago. No further temporary account deployments are scheduled yet. Temporary Accounts is a project to create a new type of user account that replaces IP addresses of unregistered editors which are no longer made public. Please share your opinions and questions on the project talk page.
• Later this week, editors at wikis that use FlaggedRevs (also known as "Pending Changes") may notice that the indicators at the top of articles have changed. This change makes the system more consistent with the rest of the MediaWiki interface. [4]

Bugs status

• Editors who use the 2010 wikitext editor, and use the Character Insert buttons, will no longer experience problems with the buttons adding content into the edit-summary instead of the edit-window. You can read more about that, and 26 other community-submitted tasks that were resolved last week.

Project updates

• Please review and vote on Focus Areas, which are groups of wishes that share a problem. Focus Areas were created for the newly reopened Community Wishlist, which is now open year-round for submissions. The first batch of focus areas are specific to moderator workflows, around welcoming newcomers, minimizing repetitive tasks, and prioritizing tasks. Once volunteers have reviewed and voted on focus areas, the Foundation will then review and select focus areas for prioritization.
• Do you have a project and are willing to provide a three (3) month mentorship for an intern? Outreachy is a twice a year program for people to participate in a paid internship that will start in December 2024 and end in early March 2025, and they need mentors and projects to work on. Projects can be focused on coding or non-coding (design, documentation, translation, research). See the Outreachy page for more details, and a list of past projects since 2013.

Learn more

• If you're curious about the product and technology improvements made by the Wikimedia Foundation last year, read this recent highlights summary on Diff.
• 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:
  • Community Configuration - Shaping On-Wiki Functionality Together (55 mins) - about the Community Configuration project.
  • Future of MediaWiki. A sustainable platform to support a collaborative user base and billions of page views (30 mins) - an overview for both technical and non technical audiences, covering some of the challenges and open questions, related to the platform evolution, stewardship and developer experiences research.

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

MediaWiki message delivery 20:33, 26 August 2024 (UTC)

Sisterlinks on category pages

A user has (relatively) recently systematically added the {{plain sister}} template (which shows links to our sister projects, fetched from Wikidata) to a lot of category pages. These links are already available as "In other projects" in all skins (even Monobook) except Minerva (the mobile site) and are fetched from the same source. The links provided by the template are therefore redundant, and I find they get in the way (especially when a category exists on many sister projects). You can see a randomly picked example at Category:Hidden categories.

I would like to remove the template, but as there is no policy or guidance one way or the other on this issue I am seeking the community's input on it first. Does anyone specifically want to retain the template on category pages? Are you ok with removing it? Other thoughts or comments? Xover (talk) 14:53, 31 August 2024 (UTC)

 Comment Whatever we decide, the template is defective when applied to the Category: namespace, as it claims to link to the Wikipedia article, although it actually links to a category there. The template does not seem to have been designed to work correctly in the Category namespace, although users have been placing it there at least as far back as 2005. --EncycloPetey (talk) 19:57, 31 August 2024 (UTC)

That template does so in all namespaces, as it is only meant for article namespace (cf the top of this very page). — Alien333 ( what I did
why I did it wrong ) 20:12, 31 August 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)

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. [5]
• 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. [6]
• 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. [7]

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. [8][9]
• 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. [10]

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. [11]
• 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). [12]

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)

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)

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)

• 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)

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)

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. [13]
• 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. [14]
• 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. [15]
• 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. [16]

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. [17]

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)

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)

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)

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)

(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)