Wikisource:Scriptorium/Archives/2024-07

From Wikisource
Latest comment: 1 month ago by Jan.Kamenicek in topic Serialized works in periodicals
Jump to navigation Jump to search

Aux Contents table row not green

I am using the exact same syntax that works elsewhere, but on this page it is not working. The Introduction is an auxiliary row not in the original contents, and as I say, I'm using the same auxiliary row syntax as elsewhere, but no green box is generated. What am I missing, and is there somewhere situations like this are explained? --EncycloPetey (talk) 01:00, 1 July 2024 (UTC)

What's an example that works? —Justin (koavf)TCM 01:34, 1 July 2024 (UTC)
For now, there is a temporary fix, so I guess that's something. :/ —Justin (koavf)TCM 01:44, 1 July 2024 (UTC)
The end of the contents for The Innocents Abroad on page xviii. --EncycloPetey (talk) 02:31, 1 July 2024 (UTC)
Well, your story certainly checks out. As a non-expert CSS guy who hasn't messed around with Web design in a bit, my suspicion is that there's some kind of conflict with the other styles, but I also tooled around with that and could not get it to work with an !important rule either. The only things that worked for me were 1.) directly inserting the CSS which is non-optimal and 2.) converting it to a template that I think works better anyway at reproducing the page. I think the latter is the best solution, but it doesn't resolve why your perfectly sensible approach didn't work. If you need me to investigate or tinker more, let me know, but I think this resolves the immediate problem. —Justin (koavf)TCM 02:50, 1 July 2024 (UTC)
{{auxiliary toc styles}} is in the header for your example, but not in the page you're having issues with. Arcorann (talk) 03:01, 1 July 2024 (UTC)
That has fixed the issue. Thanks. --EncycloPetey (talk) 03:15, 1 July 2024 (UTC)

Tech News: 2024-27

MediaWiki message delivery 23:59, 1 July 2024 (UTC)

Newspaper ads

Apologies if this has already been covered; in my search of the archives I found newspaper ads mentioned, but not discussed in any detail (ads in books seem to be addressed as something that can be freely omitted, if I understand correctly). I've been transcribing an issue of The New York Times, and many pages consist partly or mostly of large ads. My first thought was that I needed to transcribe the ads along with everything else, but when I got to the large pictorial ads, and realized how many there were, I had to ask myself: do we really need to add scores—perhaps hundreds—of old ads to Wikimedia Commons just to transcribe the news (mostly without pictures, since these are articles from before 1929)? That seems like it would be a project by itself. Even just transcribing the text—much of which might seem odd without the accompanying pictures—would potentially be complicated and perhaps prevent editors from working on newspaper content. And there will be large sections of newspapers which, although viewable in their original format, are unlikely to be transcribed at all—I'm thinking of pages of daily stock prices and apartment listings.

So the question is this: is it acceptable to transcribe only the articles and ignore the ads, and call the page proofread, or validated? Could a notice be included that ads have been omitted? What about identifying the contents of pages that consist entirely of ads, or financial data, or apartment listings, in the index pages? Is there a practical way of dealing with these pages or partial pages that are unlikely ever to be transcribed, that does not prevent the useful contents of a newspaper being marked proofread, validated, and transcluded to mainspace? P Aculeius (talk) 15:08, 1 July 2024 (UTC)

My approach when working on Frank Leslie's Illustrated Newspaper was to transclude each article/section to a separate subpage. This allowed me to, for example, transcribe most of Issue 450, but not worry about the several pages of advertisements I didn't feel like transcribing. This doesn't address the issue of marking individual pages proofread (e.g. page 126 is transcluded to "Recent Battles in Louisiana" but not marked proofread), but it definitely helps. (I also think it's good practice in general to make subpages for each article, because it's often desirable to link to individual articles.)
IMO it's fine to just transcribe particular articles from a periodical, as long as they're self-contained works. For example, this conversation has reminded me that I'd like to scan-back Fenimore Cooper's Literary Offences, and I don't think I should have to transcribe the entire July 1895 issue of the North American Review in order to do so. —CalendulaAsteraceae (talkcontribs) 20:24, 1 July 2024 (UTC)
  • The practice, so far as I have seen, is to mark pages as “not proofread” if the advertisements have not been added, but that an index whose only “not proofread” pages are advertisements can be marked as proofread. It is my preference to proofread entire indexes, or at least to work to that end, as otherwise we are left with vast swaths of indexes which are abandoned and worse than useless. Pages with content which it is not desirable to transclude may simply be ignored, I suppose. TE(æ)A,ea. (talk) 15:49, 2 July 2024 (UTC)
It's fairly easy to use section markers to separate out the adverts from the rest of the page (and articles from other articles) - you can then focus on proofreading the useful content then come back and work on the adverts if you really want to! That's the approach I took on the issue of The New York Times that I proofread - https://en.wikisource.org/wiki/The_New_York_Times/1918/11/11
If you look at https://en.wikisource.org/wiki/Page:The_New_York_Times,_1918-11-11.pdf/7 , for example, you can see lots of different articles + some adverts. In proofreading these are all separated by section markers like
## Our Men Attack on 71-Mile Front ##
I moved all the adverts to the bottom of the page in a section marked
## Adverts ##
In the end-user view of the newspaper I have a single Adverts page - https://en.wikisource.org/wiki/The_New_York_Times/1918/11/11/Adverts - which includes links to the adverts section of all the pages.
In terms of the page status, I didn't change it to 'proofread' until I'd done at least an initial pass at proofreading all the text on the page (including the adverts). Yes, including all the stock pages :). Having a page marked as 'not proofread' doesn't stop parts of it from being transcluded. Qq1122qq (talk) 22:02, 5 July 2024 (UTC)
That's pretty much what I'm doing now. I'm not marking new pages as proofread until I've transcribed all of the ads, but I'm transcluding individual stories once they've been proofread. Thanks for helping out—I feel more like I know what to do now! P Aculeius (talk) 03:02, 6 July 2024 (UTC)

Automatic year of publication in the license templates

It seems that a new feature has been added to the license templates: if the year of publication is not given in the template's paramater, it is taken from the Wikidata item of the work. However, this does not work well for translations, because translations are usually published later than the original work, and so the date should be taken from the Wikidata item of the version/translation, not of the work. See e. g. here, where both licenses for original work and translation claimed they were published in the same year, which was not true. I solved this particular case by adding the publication year parameter, but there can be many others. -- Jan Kameníček (talk) 11:21, 3 July 2024 (UTC)

This is also affecting lots of editions that are not translations. For example, Love's Labour's Lost (1925) Yale now has a claim that it was published in 1598, which is true for only the play contained in the work, whereas the appendices and notes, which make up one-third of the book, were not published on that date, and therefore that date is irrelevant for judging copyright. --EncycloPetey (talk) 13:38, 3 July 2024 (UTC)
Okay, the {{translation license}} issue is an understandable oversight, but Love's Labour's Lost (1925) Yale explicitly has the date "August 1925" in Wikidata and the fact that it is failing to use the correct date means the whole functionality is broken —Beleg Tâl (talk) 13:42, 3 July 2024 (UTC)
I've disabled the WD pubyear functionality for now; will investigate this bug when I have time. —CalendulaAsteraceae (talkcontribs) 13:46, 3 July 2024 (UTC)
I've been thinking about this further, and I don't think automatically pulling the date from WD is wise in general. The date of copyright may not be the same as the date of publication (e.g. reprints), nor is it necessarily the same as the date of original publication (e.g. expanded or annotated editions). I do not think it is currently possible to automatically determine which, if either, is the case—even if the work and the edition are modelled correctly on WD, which they often aren't. And that's before dealing with {{translation license}} and other uses of {{License container begin}}/{{License container end}}. —Beleg Tâl (talk) 15:18, 3 July 2024 (UTC)
There are explicit properties such as "relevant date for copyright". I think we should distinguish between trying to do things like inferring as opposed to be prescriptive and narrow about when we pull the data from wikidata. However, if we can't agree on a data model in WD, then I suspect we will just continue to have problems here as we argue about what the various dates mean and because WD allows far more information and searching to find and correct issues. MarkLSteadman (talk) 03:28, 4 July 2024 (UTC)
The problem with "relevant date for copyright" on Wikidata is that the property is very is context dependent. Is it the effective date of publication for evaluating US copyright? Is it the date the work enters public domain? If so, in which localities? Is it the date the last surviving author/editor perished? Is it the date of copyright registration in the US? There are many, many things that might be placed into that property. --EncycloPetey (talk) 03:34, 4 July 2024 (UTC)
the attempt to reduce copyright determinations to date maths is bound to failure. but it is common practice on commons. they want a simple but wrong query to mass nominate works, and the burden will be on the uploader to explain the nuances of formalities, edition publication, and local law. they would do better to follow the logic tree of the experts at https://onlinebooks.library.upenn.edu/licenses.html --Slowking4digitaleffie's ghost 02:04, 9 July 2024 (UTC)

Table continuations (perrenial issue)..

Okay why is this showing up as having forstered content, Page:Compendium of US Copyright Office Practices (1973).pdf/515, when I thought I'd followed the appopriate use of {{nopt}}? ShakespeareFan00 (talk) 00:06, 4 July 2024 (UTC)

And here - Mrs._Beeton's_Book_of_Household_Management/Chapter_LXVII#pageindex_1948, The table should be the same layout both sides of the page split and for some reason isn't. (Sigh). ShakespeareFan00 (talk) 05:51, 4 July 2024 (UTC)
@ShakespeareFan00:: Page 1747, the rule template should use 90% only (or width=90%). Page 1748, the "width: 50%" in the first cell is not included, so the 2 columns had not the required sizes. M-le-mot-dit (talk) 13:27, 4 July 2024 (UTC)
And another NIOSH Hazard Review: Carbonless Copy Paper/Health Effects- Is too much to ask that there is ONE sensible way of setting up continued tables, without having to play hunt the quirks REPEATEDLY? (sigh) ShakespeareFan00 (talk) 06:05, 4 July 2024 (UTC)
@ShakespeareFan00: Yes, that's too much to ask, because you're asking for mind-reading software. None of these cases are the same and so they require different solutions, which one is needed is impossible for the software to figure out. In addition, you are not describing a problem here, just venting your frustration.
Judging from a quick and superficial peek at what I think is the revision you're referring to in this thread, you're seeing a fostered content warning because the lintHint script is requesting the content from the API, which does not see the stuff you put in noinclude, meaning the first table cell of the second table is not inside a table row. This is an entirely fictitious problem that only exists inside lintHint and nowhere else. If this is what's set you off on an editing-spree then that was a mistake (I haven't checked your edits, I just saw there were lots of them on my watchlist). Xover (talk) 15:42, 4 July 2024 (UTC)
It wasn't. It was that https://en.wikisource.org/wiki/Special:LintErrors/fostered had started to fill up again, with pages that I thought with the {{nopt}} was designed to resolve. ShakespeareFan00 (talk) 17:58, 4 July 2024 (UTC)
Thanks for the vote of confidence. If you wanted to rework linthint.js into a local gadget that's Page: aware, I'd certainly be a user of it. ShakespeareFan00 (talk) 15:58, 4 July 2024 (UTC)

Voting to ratify the Wikimedia Movement Charter is ending soon

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

Hello everyone,

This is a kind reminder that the voting period to ratify the Wikimedia Movement Charter will be closed on July 9, 2024, at 23:59 UTC.

If you have not voted yet, please vote on SecurePoll.

On behalf of the Charter Electoral Commission,

RamzyM (WMF) 03:47, 8 July 2024 (UTC)

Documented standards for CSS?

Is there any documented standards for CSS used in TemplateStyles or Index styles? I've noticed that many templates using TemplateStyles use the prefix wst- but I haven't been able to find any documentation to ensure that I'm doing it properly when I create new templates or Index stylesheets. —Beleg Tâl (talk) 15:00, 8 July 2024 (UTC)

Don't know if it can be called documented, but I was told that "for new code, wst-* is a class added by a template; wsg-* by a Gadget; ws-* is a global style. Per-work styles use _* class names, or __* for once-off styling". — Alien333 (what I did & why I did it wrong) 16:07, 8 July 2024 (UTC)
Awesome, thanks! —Beleg Tâl (talk) 16:36, 8 July 2024 (UTC)

Tech News: 2024-28

MediaWiki message delivery 21:31, 8 July 2024 (UTC)

DJVU thumbs rotated

When I open Page:The Czechoslovak Review, vol3, 1919.djvu/8 or any other page from this index in the edit mode, the image of the page appears to be rotated 90° to the right. When I refresh the page, it appears correctly for a fraction of a second and then gets rotated again. It does not happen with saved proofread pages in the reading mode, unless they are open in the edit mode too, then the image gets rotated as well, see e. g. here. The problem started today. I have not noticed this problem with any other file so far. Any idea what is happening? -- Jan Kameníček (talk) 10:20, 9 July 2024 (UTC)

Now I have tried to open the pages in Firefox, and they look correctly. The problem appears only in Chrome. --Jan Kameníček (talk) 10:24, 9 July 2024 (UTC)
If you hit the r key does it rotate? you could use that to straighten it out again —Beleg Tâl (talk) 14:23, 9 July 2024 (UTC)
Yes, problem solved :-) Thanks! -- Jan Kameníček (talk) 20:15, 9 July 2024 (UTC)

U4C Special Election - Call for Candidates

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

Hello all,

A special election has been called to fill additional vacancies on the U4C. The call for candidates phase is open from now through July 19, 2024.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community members are invited to submit their applications in the special election for the U4C. For more information and the responsibilities of the U4C, please review the U4C Charter.

In this special election, according to chapter 2 of the U4C charter, there are 9 seats available on the U4C: four community-at-large seats and five regional seats to ensure the U4C represents the diversity of the movement. No more than two members of the U4C can be elected from the same home wiki. Therefore, candidates must not have English Wikipedia, German Wikipedia, or Italian Wikipedia as their home wiki.

Read more and submit your application on Meta-wiki.

In cooperation with the U4C,

-- Keegan (WMF) (talk) 00:03, 10 July 2024 (UTC)

Template:Nastali'q

Is this the template that should be used for all Persian text (like {{Hebrew}} for Hebrew), or only for some types of Persian text (like {{Polytonic}} for Greek)? I don't know enough about Persian/Farsi to be able to tell. —Beleg Tâl (talk) 13:37, 10 July 2024 (UTC)

w:Arabic_script#Table_of_alphabets says that Persian is written in Naskh and Nastaliq, and at least at one point Wikipedia says that Nastaliq use in Persian is occasional.--Prosfilaes (talk) 23:36, 10 July 2024 (UTC)

Tech News: 2024-29

MediaWiki message delivery 01:31, 16 July 2024 (UTC)

Proposal for community collaboration

A discussion has been started at Wikisource talk:Community collaboration#Proposals to select a work to restart community collaboration. Current proposal is Balzac's works. Posting here because probably no one noticed that discussion. — Alien333 (what I did & why I did it wrong) 15:40, 16 July 2024 (UTC)

Categorization of media which cannot be uploaded to Commons

I have been working with some media which cannot be uploaded to Commons. So far, they exist in a category which does not exist. If I were to make those categories: How do books fit into the categories here? For sure, it is documented somewhere, but I would truly appreciate a quick how to so that I (and maybe others) don't overthink the process. Thank you.--RaboKarbakian (talk) 15:23, 16 July 2024 (UTC)

Any examples?--Jusjih (talk) 16:42, 16 July 2024 (UTC)
One example are the images for the A. A. Milne Pooh series. The artist hasn't been dead for 100 years (or 70, Brit law has been difficult for me to follow).--RaboKarbakian (talk) 06:34, 17 July 2024 (UTC)
For what reason can they not be uploaded to Commons? Is it because they're still under copyright (in which case, we can't really have them here either—assuming the claim of copyright is valid), or does it have to do with the type of media they are? Books, which you asked about, certainly can be uploaded to Commons if they're in the public domain, using .pdf or .djvu files. Lots of books, especially older ones, are hosted at Commons and here. The help topics on Wikisource are pretty good for things like file types, how to obtain and upload them (which is not to say that every question is easy to find the answer to), and you can find categories in part by looking up possible category names in the search window, and seeing whether anything by that name comes up. You can also look for similar works, and see how they're categorized. But as Jusjih said, we might be able to provide more guidance if you can be specific about what it is you'd like to upload to Commons or publish on Wikisource, and what specific problems you ran into! P Aculeius (talk) 04:36, 17 July 2024 (UTC)
P Aculeius: I have often wondered if commons OTRS would work here; you know, get permission from whatever might be left from defunct publishers.--RaboKarbakian (talk) 06:34, 17 July 2024 (UTC)
There are works that are public domain in the US, and so can be hosted here, but are not yet public domain in their country of origin, and so cannot be hosted on Commons. English Wikisource follows US copyright law as the baseline for what can be hosted, because the servers are located in the US. In the past, we've had alternative hosting sites for selected works in Canada, Korea, and Australia. Commons chooses to follow copyright based on both the US status and that of the country of origin for the work. This situation applies to whole works, parts of works, and illustrations for various publications hosted on the English Wikisource.
My experience in the past has been that a lot of that maintenance was organized by Billinghurst, who has not been as active here lately as in the past. I do not know whether his practices have been documented. --EncycloPetey (talk) 05:10, 17 July 2024 (UTC)
EncycloPetey Thanks for this answer. Billinghurst told me: Don't worry about categorization here, it is different than Commons (slightly paraphrased). I get the feeling that more thought has gone into author cats (by Billinghurst, which now seem to be automatic) than works.--RaboKarbakian (talk) 06:34, 17 July 2024 (UTC)

Uploading over 100MB djvu to WS instead of Commons

I have some djvus that I would like to host on WS (because they are UK origin) but they are just over 100MB. I can regenerate them at higher compression if needed, but was curious if there was guidance about how to get them into WS, aside from upload to Internet Archive and then import the djvu (since archive.org I believe is on the import from url allow list). Commons would not be a problem as it has higher limits, even raising the limit to 150MB would help here. MarkLSteadman (talk) 00:29, 18 July 2024 (UTC)

I don't think that Internet Archive is generating djvu's anymore—but check to make sure they don't already have one of the work in question! I may be confused by your question, but maybe this is the answer you want: we seem to prefer importing files from Commons anyway, so if you can upload them there (no matter where you got them, as long as they're in the public domain), that would be ideal—Wikisource will simply use the images from Commons, so you don't need to upload anything here. P Aculeius (talk) 03:29, 18 July 2024 (UTC)
Commons and enWS treat PD differently. We accept anything that's PD in the US regardless of its status elsewhere. Commons require PD in US and PD in country of origin. The files that Mark wants to upload can't go to Commons because they're not PD in the UK, thus his question about how to upload them here. Beeswaxcandle (talk) 09:42, 18 July 2024 (UTC)
@MarkLSteadman: It's not really a limit as such. There's a limitation in the web serving components of Wikimedia's MediaWiki installation (varnish, apache, etc.) that caps raw HTTP uploads at 100MB. For larger files you have to use a custom MediaWiki-specific protocol called Chunked Uploading, in which case you can upload files as large as 2.5GB (IIRC). The difference between Commons and enWS is that Commons has Upload Wizard, which supports and uses Chunked Uploading, while enWS does not (we just have the plain old upload form).
For an occasional need I would generally recommend that you drop your files into Dropbox or Google Drive (or whatever such service you have) and shoot the link my way so I can upload them for you. But if you anticipate having this need regularly and can deal with a relatively high geek-factor, the solution is the tool I use…
…namely commons:User talk:Rillke/bigChunkedUpload.js. There are som docs in that link, but the gist is that you put mw.loader.load('//commons.wikimedia.org/w/index.php?title=User:Rillke/bigChunkedUpload.js&action=raw&ctype=text/javascript'); into your common.js and then you get some new "Chunked upload" options in relevant parts of File:-namespace pages. Important thing to remember: bigChunkedUpload starts upload immediately when you select a file. There's no confirmation, extra button click, etc. unlike most other similar tools. So make sure you select the options you want in the dialog before selecting a file to upload. It also has a pretty high geek factor, so it's pretty off-putting to non-technical people, but since it's fairly limited in scope most people should be able to use it in a pinch. Xover (talk) 06:15, 18 July 2024 (UTC)

User translations without scan-backed original: how long to wait?

If someone uploads a user translation of a work, which does not have a scan-backed original on the relevant language Wikisource (e.g. Translation:Does Spring Come, Even to Stolen Fields / ko:빼앗긴 들에도 봄은 오는가), how long of a grace period should we allow for the original to be added before deleting the user translation? Mostly just looking for general thoughts; I feel like it needs more grace than WS:PD would usually allow, but should still be on some sort of time limit or else there's no point disallowing this situation —Beleg Tâl (talk) 13:20, 18 July 2024 (UTC)

Wikimedia Movement Charter ratification voting results

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

Hello everyone,

After carefully tallying both individual and affiliate votes, the Charter Electoral Commission is pleased to announce the final results of the Wikimedia Movement Charter voting.  

As communicated by the Charter Electoral Commission, we reached the quorum for both Affiliate and individual votes by the time the vote closed on July 9, 23:59 UTC. We thank all 2,451 individuals and 129 Affiliate representatives who voted in the ratification process. Your votes and comments are invaluable for the future steps in Movement Strategy.

The final results of the Wikimedia Movement Charter ratification voting held between 25 June and 9 July 2024 are as follows:

Individual vote:

Out of 2,451 individuals who voted as of July 9 23:59 (UTC), 2,446 have been accepted as valid votes. Among these, 1,710 voted “yes”; 623 voted “no”; and 113 selected “–” (neutral). Because the neutral votes don’t count towards the total number of votes cast, 73.30% voted to approve the Charter (1710/2333), while 26.70% voted to reject the Charter (623/2333).

Affiliates vote:

Out of 129 Affiliates designated voters who voted as of July 9 23:59 (UTC), 129 votes are confirmed as valid votes. Among these, 93 voted “yes”; 18 voted “no”; and 18 selected “–” (neutral). Because the neutral votes don’t count towards the total number of votes cast, 83.78% voted to approve the Charter (93/111), while 16.22% voted to reject the Charter (18/111).

Board of Trustees of the Wikimedia Foundation:

The Wikimedia Foundation Board of Trustees voted not to ratify the proposed Charter during their special Board meeting on July 8, 2024. The Chair of the Wikimedia Foundation Board of Trustees, Nataliia Tymkiv, shared the result of the vote, the resolution, meeting minutes and proposed next steps.  

With this, the Wikimedia Movement Charter in its current revision is not ratified.

We thank you for your participation in this important moment in our movement’s governance.

The Charter Electoral Commission,

Abhinav619, Borschts, Iwuala Lucy, Tochiprecious, Der-Wir-Ing

MediaWiki message delivery (talk) 17:53, 18 July 2024 (UTC)

Why is Mainspace now Pagespace?

I've noticed that the tabs that link to Source, Styles, and such at the top of a work now use "Page" for the Mainspace location. That is very confusing because we have a Page: namespace that is separate from the Mainspace. Is this an oversight on the part of the developers for the potential confusion, and what can we do about it? --EncycloPetey (talk) 16:56, 21 July 2024 (UTC)

On which page (and implicitly, in what namespace) are you seeing a different text string for the content tab than previously; what text did you used to see there; and what skin are you using?
As best I can recall the main content tab in mainspace has always read "Page" (meaning here, of course, "wikipage"), at least since 2007. It's always been confusing, but with no obvious good alternative. In the Index namespace (which is where you should see a "Styles" tab) the main content tab should read "Index". Xover (talk) 18:55, 21 July 2024 (UTC)
Yeah, this is the default name out of the box in MediaWiki; it's only confusing for the small handful of projects that happen to also have a namespace called "Page". It's the same confusing nomenclature that you get when you're talking about the "Talk page" and the "Index page" and the "Page page" and so forth. (Yes, I have had to use the phrase "Page page", on occasion.) —Beleg Tâl (talk) 22:46, 21 July 2024 (UTC)

Template:Expand list / Template:Incomplete list

The {{Expand list}} and its redirect {{incomplete list}} were originally developed for use on Periodical pages where the lists of articles were incomplete. See, e.g., The New York Times/1901/08/01 where the template is used in the page's Aux ToC. However, the template is now used on around 300 Author pages, where the template is superfluous. I say superfluous because the vast majority of our Author pages are incomplete, even for works we can currently host, and potentially all Author pages will forever be incomplete because new works about authors are continuously being published. Placing a template onto every Author page that is "incomplete" is therefore superfluous since all Author pages could be described as incomplete. Placing the template serves no useful function, nor provides any useful information.

Either we should (a) officially restrict the use of this template to exclude Author pages, or (b) place the template on every Author page because 99% of our Author pages have incomplete lists of works, and all such pages will forever have the potential for new works about the author to come into existence at any time. --EncycloPetey (talk) 17:17, 13 July 2024 (UTC)

Agree with excluding Author pages per rationale above. --Jan Kameníček (talk) 18:12, 13 July 2024 (UTC)
I didn't even know that template existed, but I agree there's not much point putting it on author pages. — Alien333 (what I did & why I did it wrong) 13:56, 14 July 2024 (UTC)
Established practice is that Author: pages should not aim for completeness (they're not a bibliography); they should cover the texts we have, but with considerable leeway for adding additional text (e.g. to facilitate linking external scans). Given that, {{expand list}} on an Author: page is not appropriate. I also agree with the reasoning above. Xover (talk) 16:51, 14 July 2024 (UTC)
I'm inclined to suggest  Delete these templates entirely, and on pages like The New York Times/1901/08/01 replace it with {{incomplete}} instead —Beleg Tâl (talk) 19:25, 14 July 2024 (UTC)
A deletion discussion would need to happen at WS:PD, not here. --EncycloPetey (talk) 04:14, 15 July 2024 (UTC)

Based on the above responses, I have requested the Templates be removed by bot from the Author namespace. --EncycloPetey (talk) 17:54, 22 July 2024 (UTC)

Tech News: 2024-30

MediaWiki message delivery 00:04, 23 July 2024 (UTC)

OPDS catalogs not updated?

There are two OPDS catalogs at https://ws-export.wmcloud.org/opds/ (one for English books, one for French books), but it seems they have not been updated since December 2023. They used to be regularly updated in the past. Is there a new location for them?

Thanks. Eric Y Muller (talk) 03:17, 17 July 2024 (UTC)

@Samwilson: Do you know what's up? Xover (talk) 09:41, 17 July 2024 (UTC)
@Eric Y Muller, @Xover: I've replied on the task. Hopefully we'll get things working again soon! Sorry for the failure. Sam Wilson 09:55, 17 July 2024 (UTC)
@Eric Y Muller, @Xover: So it seems there's some other issues, one of which is T370257 where Keeban (Little, Brown and Company) has an incorrect (but valid) cover image specified. I'll not fix it on-wiki right now, in case anyone wants an easy way to reproduce the bug, but it does suggest that Module:Header should add an error tracking category for non-existent cover names. I've made a patch to fix the problem, will hopefully get it merged and deployed soon. Sam Wilson 11:43, 17 July 2024 (UTC)
At least on the French side, it is now working fine (I don't use the English one). Thanks a lot for your work. Eric Y Muller (talk) 16:03, 23 July 2024 (UTC)
The english one has also been updated. @Samwilson: maybe the task should be resolved. I left a message there, but I'm not very familiar with phab, so I didn't want to mess up. — Alien333 (what I did & why I did it wrong) 18:42, 23 July 2024 (UTC)

Missing maintenance template

{{Improve documentation}} calls {{Dated maintenance category}}, which does not exist. Should we import it, or remove the call from the former template? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:40, 24 July 2024 (UTC)

We should get rid of {{improve documentation}}, which you imported from enWP by cut&paste in 2019, because if there is one thing we do not need on enWS it is yet another template to point out the fact we are all aware of (our documentation is inadequate). It adds maintenance (this thread being the case in point) for no added value beyond letting people vent about inadequate docs in template form instead of in a talk page comment. Xover (talk) 11:22, 24 July 2024 (UTC)

Template bug

{{Plainlist}} does not work for ordered ("#") lists; yet it does so on en.Wikipedia, for example.

Markup (ordered list):

{{Plainlist|
# one
# two
# three
}}

Rendering (ordered list):

  1. one
  2. two
  3. three

Markup (unordered list):

{{Plainlist|
* one
* two
* three
}}

Rendering (unordered list):

  • one
  • two
  • three

The first rendering should look like the second. Can anyone fix it, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:51, 24 July 2024 (UTC)

What's your use case for an unbulleted (unsigilled) ordered list? Xover (talk) 11:24, 24 July 2024 (UTC)
Yes, I am confused too. If the numbering is not displayed, then it's not really ordered, so why use an ordered list? —Beleg Tâl (talk) 13:17, 25 July 2024 (UTC)
Page:Midland naturalist (IA midlandnaturalis01lond).pdf/258, for example. Note also that there is no requirement in the HTML spec for ordered lists to display numbering; that's merely the default. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:46, 25 July 2024 (UTC)
If you take an ordered list and you remove the numbers, you get (visually) exactly the same thing as an unordered list without bullets, it's just decoration. — Alien333 (what I did & why I did it wrong) 14:19, 25 July 2024 (UTC)
Visually you do, yes. But the markup is semantic, not presentational ("decoration"). Removing the presentational component does not change the underlying meaning. The two types of list are not the same. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:47, 25 July 2024 (UTC)
That's not an unsigilled ordered list. That's an ordered list with sigils that cannot currently be reproduced in MediaWiki due to a combination of limitations in MediaWiki and web browsers. Making that an ordered list with hidden sigils and then manually reproducing the numbering would be unsemantic and cause a problem for, e.g., non-visual browsers (and other user agents that automatically number ordered list items, or that fall back on a default numbering style when they do not support the custom style specified). There may be use cases for unsigilled ordered lists, but absent evidence to the contrary I am sceptical that any of them occur in our content namespaces. Xover (talk) 16:09, 25 July 2024 (UTC)

Problems with rendering thumbs of PDFs

It takes several attempts to display a thumb of a PDF file page in page namespace. Sometimes I have to refresh the page 5 to 10 times. Also transcribing text with any of the OCR tools takes long (20+ seconds) and sometimes it fails completely. I noticed the problems yesterday morning, but I do not know when they actually started because I had not worked in the page namespace for a long time. -- Jan Kameníček (talk) 11:26, 25 July 2024 (UTC)

Jan Kameníček I had this problem today. I filled the "waiting time" by purging here and at commons, multiple times; which, unfortunately, was a step backwards as I initially lost the thumb on the index page. This is not the "other problem" where there seems to be a network time out while putting the page into the exact same location and magnification that was previously used. That problem is solved, often, by twirling the mouse wheel thus adjusting the magnification and causing the page to render. Moral: fill that render time wisely and if wisely is unavailable, then fill it while calmly purging everything that might be touching it, I think.--RaboKarbakian (talk) 14:44, 25 July 2024 (UTC)
Meanwhile, the problem seems to have disappeared... --Jan Kameníček (talk) 18:15, 25 July 2024 (UTC)

Slight modification of WS:MOS regarding chapter numbering

As per this discussion, it would be helpful if the Style Guide explicitly stated that numbered chapters should use Arabic numbering (as per our usual practice, and as documented at Help:Subpages#Chapters and sections).

To this end, I am proposing the following change:

OLD:

  • Works that have chapters/sections should be numbered, not named (eg. use [[/Chapter 1/]] and not [[/The Dog Returns/]]). The section name should reflect those in the original work (Chapter 2, Act 2, et cetera). Subpage titles such as [[/Preface/]] and [[/Appendix/]] are fine though.
  • When a work is a collection (e.g. poetry) or a compiled work (e.g. a journal or almanac), then the subpages are works in their own right, and the original title of the work should be used in the subpage title.

NEW:

  • Works that have chapters/sections should be numbered, not named (eg. use [[/Chapter 1/]] and not [[/The Dog Returns/]]).
    • The section name should reflect those in the original work ("Chapter 2", "Act 2", etc.). Subpage titles such as [[/Preface/]] and [[/Appendix/]] are fine though.
    • The section number should use Arabic numerals ("Chapter 2"), even if the original work uses Roman numerals ("Chapter II") or another numbering scheme ("Chapter Second", etc)
  • When a work is a collection (e.g. poetry) or a compiled work (e.g. a journal or almanac), then the subpages are works in their own right, and the original title of the work should be used in the subpage title.

Beleg Tâl (talk) 13:41, 23 July 2024 (UTC)

 Support, though it may be useful to specify in the first bullet points that it does not apply to collections, else it and the last bullet point may seem contradictory. — Alien333 (what I did & why I did it wrong) 13:52, 23 July 2024 (UTC)
 Oppose, since this does not provide for the handful of exceptions where the approach runs into problems, and will therefore run us into rules-lawyering. For 98-99% of cases, the above approach is desirable. But there are problems. One such issue is that nearly every citation of Shakespeare uses capital Roman numerals for the Acts, his means that any linking will have to juggle back and forth in two systems, both in the work itself, and in the linking from works that cite. Links from off-site will have to do the same juggling. This is a nearl-universal citing format for his works. I brought up this issue the last time we discussed this topic. Further, the proposed change does not actually specify that the names of subpages themselves should follow any particular rule; this could be interpreted as rules describing display fields in the header or in tables of contents. This vote is premature, because we first need a discussion to decide what it is we want the change to say, instead of jumping directly to a vote. --EncycloPetey (talk) 14:33, 23 July 2024 (UTC)
WS:MOS already explicitly states that "These are not hard rules, and can be ignored where necessary". This is just a clarification of our usual guidelines to prevent confusion for new users. —Beleg Tâl (talk) 16:11, 23 July 2024 (UTC)
Also: last time I submitted a proposal like this with a discussion instead of jumping to a vote, you yourself opposed it on the grounds that I had not explicitly stated what I was proposing to change the wording to. If you have a suggestion for a better wording, provide it yourself. —Beleg Tâl (talk) 16:13, 23 July 2024 (UTC)
The previous proposal I recall was opposed because the wording kept changing after people had voted, invalidating all previous votes with each change, because each vote was in support of a different wording. There needs to be a discussion first to work out problems in the wording, and then a vote to adopt the new wording. What you have presented here is a support / oppose situation, without room for discussion first. And in the previous instance there was continual revision concurrent with voting. The wording discussion should come first, then support / oppose afterwards. --EncycloPetey (talk) 23:05, 23 July 2024 (UTC)
I'm with EP on this one: let's discuss our way to a proposed text first, and then vote on the resulting text as a simple yes/no vote. Trying to vote on a text that is constantly changing in small and less small ways is impossible to do cleanly. Xover (talk) 08:53, 24 July 2024 (UTC)

Vote now to fill vacancies of the first U4C

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

Dear all,

I am writing to you to let you know the voting period for the Universal Code of Conduct Coordinating Committee (U4C) is open now through August 10, 2024. Read the information on the voting page on Meta-wiki to learn more about voting and voter eligibility.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community members were invited to submit their applications for the U4C. For more information and the responsibilities of the U4C, please review the U4C Charter.

Please share this message with members of your community so they can participate as well.

In cooperation with the U4C,

RamzyM (WMF) 02:47, 27 July 2024 (UTC)

Tech News: 2024-31

MediaWiki message delivery 23:10, 29 July 2024 (UTC)

OCR error

I just got an http error while using Tesseract to transcribe Page:Midland naturalist (IA midlandnaturalis01lond).pdf/350; twice.

The error message disappeared before I could read or copy it, but perhaps it is logged somewhere? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:46, 28 July 2024 (UTC)

FWIW, I've been getting more timeout errors using the OCR button. It takes longer to successfully retrieve an OCR output, and I'm getting timeout errors with greater frequency. I noticed the increase following this weekend's server maintenance downtime. I do not know whether this is the same issue, a related issue, or coincidentally similar, however. --EncycloPetey (talk) 16:35, 28 July 2024 (UTC)
I've also noticed it's taken longer than usual these days. Jan.Kamenicek mentioned something similar a few days ago, it might be linked. — Alien333 (what I did & why I did it wrong) 19:32, 28 July 2024 (UTC)
I am grateful if the above posters provide links to the projects for my benefit. I am collecting information on the type of documents being scanned. i. e.: I follow this issue closely as well, but lack data on numerous conditions that may be considered as one of the causes of the problem. Thanks. — ineuw (talk) 18:59, 2 August 2024 (UTC)
I'm just guessing (but it's an educated guess), but I think the root cause is probably the performance and reliability problems on Commons that especially affect PDF files (but DjVu files aren't immune either). It's the same issue that's causing the various problems with Index: pages for newly uploaded files, showing page thumbnails in Page: namespace, etc. and that can sometimes be fixed by purging the file description page. All the OCR engines have to start by downloading the thumbnail of the relevant page from Commons, and usually they ask for a different-sized thumbnail than what's displayed by Proofread Page so that Commons has to generate a new one (instead of just serving the one it already has). Xover (talk) 09:20, 3 August 2024 (UTC)
@Xover: Thanks for adding to my understanding. My work is almost exclusively with .djvu files by preference, which are somewhat slow but consistent page after 100's of pages.
Internet Archive's claim, for ceasing to publish .djvu format, was that the demand didn't justify it. I regret their decision when I come across some interesting material (to me), and is not available in .djvu format.­­ — ineuw (talk) 16:25, 3 August 2024 (UTC)
Couldn't you convert from what IA offers to djvu? — Alien333 (what I did & why I did it wrong) 16:39, 3 August 2024 (UTC)
@TE(æ)A,ea.: I looked at the .pdf work in the link and it takes twice as long to render as .djvu. — ineuw (talk) 16:30, 3 August 2024 (UTC)
  • — ineuw: I made the mistake of saying that Modern Japanese Stories was working fine, because when I proofread the latest story that I’ve done it started to not load again. It’s bad enough that it happens, but it’s so annoying that it’s inconsistent. TE(æ)A,ea. (talk) 13:08, 4 August 2024 (UTC)

Parallel corpus functionality via crosslinking different language Wikisource projects

I mean, would it be possible to combine "Twenty Thousand Leagues Under the Sea" with its French original "Vingt mille lieues sous les mers" and display these texts side by side, linking the corresponding chunks of text to each other? Something like:

Comparison of French and English texts
French English
L’année 1866 fut marquée par un événement bizarre, un phénomène inexpliqué et inexplicable que personne n’a sans doute oublié. Sans parler des rumeurs qui agitaient les populations des ports et surexcitaient l’esprit public à l’intérieur des continents, les gens de mer furent particulièrement émus. Les négociants, armateurs, capitaines de navires, skippers et masters de l’Europe et de l’Amérique, officiers des marines militaires de tous pays, et, après eux, les gouvernements des divers États des deux continents, se préoccupèrent de ce fait au plus haut point. THE year 1866 was signalized by a remarkable incident, a mysterious and inexplicable phenomenon, which doubtless no one has yet forgotten. Not to mention rumors which agitated the maritime population, and excited the public mind, even in the interior of continents, seafaring men were particularly excited. Merchants, common sailors, captains of vessels, skippers, both of Europe and America, naval officers of all countries, and the governments of several states on the two continents, were deeply interested in the matter.
En effet, depuis quelque temps, plusieurs navires s’étaient rencontrés sur mer avec « une chose énorme, » un objet long, fusiforme, parfois phosphorescent, infiniment plus vaste et plus rapide qu’une baleine. For some time past, vessels had been met by "an enormous thing," a long object, spindle-shaped, occasionally phosphorescent, and infinitely larger and more rapid in its movements than a whale.

What kind of additional page markup syntax and visualization plugins could be used to get this implemented for a few books? Or is this totally out of scope of the Wikisource project? --Ssvb (talk) 21:50, 31 July 2024 (UTC)

If you have an edition of the text that is bilingual, that belongs at mul:. Do you have one like that or are you trying to compare two different texts of the book? —Justin (koavf)TCM 21:53, 31 July 2024 (UTC)
I'm trying to compare two different texts of the book. The "chapter" markup is already there and it's possible to open, let's say, the third chapter of the French book in one browser window and the same third chapter of the English book in another browser window. A more fine grained "paragraph" or "sentence" level markup would make it easier to see the matching parts of text. --Ssvb (talk) 22:13, 31 July 2024 (UTC)
Hmm, now I see that Wikisource:Annotations is probably very much related. But the banned items list there includes: "Comparison pages: Pages from different versions of the same work, whether whole works or extracts, placed alongside each other (whether in series or in parallel) to provide a comparison between the different versions". --Ssvb (talk) 23:00, 31 July 2024 (UTC)
If it's only for comparing text, have you considered opening two browser windows side by side, one in English, and one in French? I am experimenting with similar concept for the same reason, but my current needs are offline, although later it will progress to online. I am only limited by time. Setting the window properties, like aligning side by side, with a minimal border may be much quicker. — ineuw (talk) 19:18, 2 August 2024 (UTC)
@Ineuw: In reality I'm interested not in an English-French pair, but in a Belarusian-English pair (but this doesn't change anything in principle). What I wanted to have is to be able to easily match pages between the Belarusian translation and its English original.
I think that I found some sort of a solution at least for now. For example, a page in the Belarusian translation of "The Prince and the Pauper" now got its page number at the top also working as a wikilink to its approximate location in the English book here. I'm using a Scribunto Lua script to calculate the mapping between chapters and some templates to establish this link. Now if somebody is reading a Belarusian book, then the approximate location of the corresponding text fragment in the English book is just a few clicks away. The correct chapter is identified precisely, but the actual page is estimated approximately. The accuracy can be improved via implementing a few additional tricks. It's not fully finished yet, but the results look very promising. --Ssvb (talk) 08:50, 6 August 2024 (UTC)
Comment: I don't know about the policy of belarusian wikisource on links, but you might want to make sure that it's allowed to do that there. Also, though it may be intentional, you're putting these links in the headers in the page namespace, which will not be transcluded onto the finished version of the work. — Alien333 (what I did & why I did it wrong) 09:31, 6 August 2024 (UTC)
@Alien333: Yes, I'm in contact with the most active contributors of the Belarusian Wikisource right now. My personal opinion is that this kind of wikilink from the page number in the running head of a page is non-invasive, doesn't change the overall visual representation of the page and possibly can be categorized as a "basic wikilink" per Wikisource:Wikilinks#Basic_wikilinks rather than an "annotation". This feature is still in a "pilot mode" and is only enabled just for a few books, which are still being OCRed as we speak. It's possible that the feature may evolve into something else. Or it can be ditched if it proves to cause some problems or is deemed to add little value. As for being used only in the page namespace for now, this is intentional. But this can be changed later if necessary. --Ssvb (talk) 08:11, 7 August 2024 (UTC)

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. --YodinT 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? --YodinT 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)