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

Proposal that all works have dates

I propose that: Every edition of a work should have its publication date in the header.

This is a straightforward and simple proposal in response to the removal of dates from headers, which is a practice I strongly disagree with. --EncycloPetey (talk) 01:11, 20 September 2023 (UTC)

• EncycloPetey: What do you mean by “edition of a work”? Is it just like when you use versions, you want the date to be on each item, as opposed to on the versions page? TE(æ)A,ea. (talk) 01:17, 20 September 2023 (UTC)

  I guess the biggest issue is that dates are being removed from editions that are published as part of a collection. The date of publication is important, and readers should be able to find full basic citation infomation without having to go hunting. For example, use of the <header> tag will pull in the title, authors, editors, place of publication, publisher, and pages. But it won't pull in the date. And the immediate impetus is the continued stripping of dates from things like the English translations of Seneca's plays. For translations, and for any works with multiple differing editions, the date of publication is essential information for distinguishing one from another. Right now, collections of works will likely have a date only on the primary page, but perhaps not on the works themselves. And in some cases, where I have put in the dates, others are going in and removing them. I disagree with stripping that kind of core information from editions of works. --EncycloPetey (talk) 01:35, 20 September 2023 (UTC)

  Concrete examples of why this is relevant:

  • Alfred Tennyson had two separate collecions of poetry published under the title Poems. A person arriving at a poem in one of those collections will not know which collection it's in without them having to navigate to the primary page to find a date. Right now, the issue is kludgingly solved by having the date as part of the base page title and displaying the page name in the title field as on Poems (Tennyson, 1843)/Volume 1/Song—The Owl. I would rather the date field be populated with 1843.
  • Thyestes (1907 translation) versus Thyestes (1902 translation). Or Prometheus Bound and Prometheus Bound, both translations by Elizabeth Barrett Browning that differ from each other. Knowing the date of the translation is often critically useful to persons comparing, or even making use of, multiple translations. --EncycloPetey (talk) 01:51, 20 September 2023 (UTC)
  • EncycloPetey: I tend to remove dates from versions pages, because that’s a bad place for them; but I do think that they should be on the individual pages. (By the way, I picked up his Poems, chiefly lyrical, and should be able to scan it in the next week or so.) TE(æ)A,ea. (talk) 02:50, 20 September 2023 (UTC)

    This proposal does not cover versions pages, since versions pages are not themselves editions. That is a separate discussion. --EncycloPetey (talk) 17:13, 20 September 2023 (UTC)

Is there a standard way of indicating dates in the headers when the dates are uncertain or unknown? E.g. I know we had a major effort around digitization of chapbooks which are 18th / 19th century-ish? Similarly, if it is something like 1923/1924? I know for authors we pull the dates from wikidata which has logic around such cases but if we plan to explicitly not pull the data from wikidata but copy it into the headers what is the expectation here? In general, I would prefer having the data in wikidata rather than forcing copying over the data. MarkLSteadman (talk) 21:45, 20 September 2023 (UTC)

• I do not know whether we have a standard for that, or have the mechanism yet for pulling dates from Wikidata. An alarming number of our contributions here do not have their own Wikidata items, but are housed on the principal page for the "work" rather than for the specific "edition". So, I suspect we're not ready to implement Wikidata-pulled dates. We might want to have that discussion, and determine what it would take to implement that, and how feasible it would be to accomplish in a reasonable span of time. --EncycloPetey (talk) 03:35, 21 September 2023 (UTC)

  Wikidata would love to have more input from client projects about which pages should have their own Wikidata items and which should not. Our current notability criteria say (in relevant part): "On Wikisource, items for mainspace pages, Author pages, Translation pages, and Portal pages are valid, along with items for namespaces that exist on other Wikimedia sites (Category, Project...). Pages in the Index and Page namespaces are not considered valid. The status of subpages of mainspace pages (for example, individual chapters) is undetermined." If I understand correctly, these editions typically appear as subpages of mainspace pages (like chapters) and so fall into the unfortunate "undetermined" bucket. Bovlb (talk) 18:41, 9 October 2023 (UTC)

  I suspect that is in reference to having, say, a 1920 edition of a play by Shakespeare linked to the main play page in WD such that when pulling the date we would pull the 17th century date instead of 1920. This can be cases for subpages being a problem: works such as poems / stories that are then published in a book collection several years later after being published in a periodical or especially works published in multiple volumes where sometimes they mix between editions or dates, but it is not exclusively issues around subpages. MarkLSteadman (talk) 05:27, 5 November 2023 (UTC)

I don't know about making this an official policy ... but I will add that I personally always add the date to subpages if it is missing -- Beleg Âlt (talk) 13:41, 13 October 2023 (UTC)

•  Support. Yet per Beleg Âlt I see no need to make it a hard policy.--Jusjih (talk) 03:23, 16 October 2023 (UTC)

•  Comment When we know the year of publication of a work then it should be added to the top level of a work by use of the "year" field. There is zero need for subpages to have that added when the year applies to all subpages of the work, and they should not be added. We should not be adding dates where we cannot determine the year of publication.

  MarkLSteadman Template:header explains the alternative ways to add dates, and I will also note that we can use a decade eg. 1820sin a year field and it displays and categorises fine. — billinghurst sDrewth 14:01, 5 November 2023 (UTC)

   Comment I personally strongly disagree that "they should not be added". While it may not be necessary to have the year info on a subpage, it is certainly useful (especially in anthologies and other collections where the subpages are also works per se). In my opinion, you could just as well argue that there is zero need for subpages to contain the work's title and author, when those fields apply to all subpages of the work. —Beleg Âlt ^BT (talk) 14:42, 6 November 2023 (UTC)

Proposal to decide whether replacing a broken URL with a Wayback Machine archive counts as an annotation per WS:ANN

I have been looking at some older works in our collection that were sourced from digital web pages (specifically this one), and I noticed that several of the URLs in the original publication are now broken. I think it would be beneficial to replace the links to point to an archived version on the Wayback Machine.

My question is: would this count as an annotation per WS:ANN? On the one hand, replacing the URL would no longer faithfully represent the original edition as written—but on the other hand, it would better represent the original edition as intended.

Thus, I propose that we decide whether changing the URL in a source text to point to the Wayback Machine counts as an annotation; and if not, that we update WS:ANN#What are not annotations? accordingly. Beleg Âlt (talk) 14:14, 2 November 2023 (UTC)

I personally  Support allowing this replacement of URLs with archive links, and updating WS:ANN to exclude this as a type of annontation under the policy. — Beleg Âlt (talk) 14:17, 2 November 2023 (UTC)

 Support Link-rot has to be managed somehow and I don't see this as a true annotation. However, I suggest a small amendment to have the link-text showing as published with the updated link piped behind it. It is only acceptable to do this if the new link is to the Wayback Machine (or some similar future repository). We may need a new filter? Beeswaxcandle (talk) 17:25, 2 November 2023 (UTC)

I agree that only the link destination should be changed, and not the text of the link, even when the text of the link is the original URL itself. I also agree that an archive of the original page is the only acceptable use of this, but I don't know how a filter would be able to make that distinction. —Beleg Âlt ^BT (talk) 18:17, 2 November 2023 (UTC)

 Support, a very useful and practical thing to do. Since it's getting around a technical limitation, being that the webpage no longer exists, it's pretty straightforward to say that if the text was written in the modern day, they would've included a valid link rather than an invalid one. And leaving the text of the original link in, but have it link to the archive, would be the best solution since it leaves in that bit of the historical context of the work. PseudoSkull (talk) 19:09, 2 November 2023 (UTC)

I personally  Support this update, along with linking to other persistent name repositories (like doi or purl) to handle internal moves. I personally am undecided in preference between linking to the wayback link vs. linking to the moved content via using something like doi / or a purl instead. MarkLSteadman (talk) 05:07, 5 November 2023 (UTC)

•  Comment The works that we publish should always display the text of the published work. That does not mean that you cannot have a corrected url subsidiary to that text that points to an amended target. Easily accomplished with our works, and clearly not an annotation, just a wikilink per our accepted wikilink process. Whether you want to standardise it, and look to adopt the "url-status" components in things like w:en:Template:Cite news is a different conversation. I would say be wary of adding all that complexity for little benefit. — billinghurst sDrewth 14:06, 5 November 2023 (UTC)

  I find it interesting that you think that amending the target of a link is "clearly not an annotation". I do agree with this of course, but since neither WS:ANN nor WS:Links allows for this, I think it does need to be formalized. Note also that our accepted wikilink process explicitly disallows adding links to non-Wikimedia pages where those links are absent in the original source. —Beleg Âlt ^BT (talk) 14:33, 6 November 2023 (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

Other discussions

Policy on substantially empty works

[This is imported from WS:PD, where it applies to multiple current proposals, and several other works].

We have quite a few cases of works that are "collective" or "encyclopaedic" in that they comprise many standalone articles of individual value, which are basically just "shell pages", with no substantial content of any sort, not even imported scans or Index pages. For example, and this isn't intended to make any statement about these specific works, they're just examples and they may well get some work done soon during their respective WS:PD discussions:

• Auction Prices of Books, a four volume set of auction listings, by author. No scans, no content and a couple of notes in the header.
• Central Law Journal/Volume 1, a single volume from a periodical, with a AuxTOC of numbers, and a title page, but otherwise empty. Has scans and Index.
• A Critical Dictionary of English Literature, a three-volume dictionary by author. Currently has no scans, no title page, and a single non-scan backed article.
• Bradshaw's Monthly Railway Guide, a top-level periodical page with a single volume number and no other content. No scans linked, though Bradshaw's Monthly Railway and Steam Navigation Guide (XVI) did once exist, it was deleted and Index:Bradshaw's_Monthly_(XVI).djvu exists and is partly proofread.

Based on the usual rate of editing for things like that, unless dragged up into a process like WS:PD, they'll remain that way a very, very long time. I think it is perhaps there might be a case to host a mainspace page for this work, even though there is zero, or almost zero actual content. Do we want:

• Mainspace pages where this is a tiny bit of information like header notes, scan links and maybe detective work on the talk page (not in this case). This provides a place for people to incrementally add content. Also gives "false positive" blue links, since there is actually no "real" content from the work itself, or
• Do not have a mainspace page until there's some content. Only host this in terms of scan links author/portal scan links, much like we do for something like a novel.

Personally, I lean (gently) towards #2, but with a fairly low bar for how much content is needed. Say, Indexes, basic templates, a title page and one example article. Ideally, a completed TOC if practical, especially for periodical volumes/numbers. It is fair to not wish to transcribe entire volumes of these work, it is fair to not want to import dozens of scans when you only wanted one, it is fair to only want an article or two, but it's not fair, IMO, to expect the first person who wants to add an article to have to do all the groundwork themselves, despite having been lured in with a blue link. That onus feels more like it should be on the person creating the top-level page in the first place.

I do see some value in periodical top pages with decent lists of volumes and scans where known, because these are often tricky and fiddly to compile from Google books/IA/Hathi, so it's not useless work, even if there are no imported scans (though imported is better than not).

We currently have a large handful of collective works listed for deletion right now in various levels of "no real content", and, furthermore, every single periodical that gets added can fall into this situation unless the person who adds, so I think we could have a think about what we really want to see here. Inductiveload—talk/contribs 15:43, 3 July 2020 (UTC)

• I believe that, if there is no scan as an Index: page, the main-namespace page should not exist unless it is being actively completed or is already mostly completed. A few pages (of the volume itself) is not very helpful, and is entirely useless if their is no scan given. TE(æ)A,ea. (talk) 15:59, 3 July 2020 (UTC).

• I think such preparatory information would ideally be on more centralized WikiProject pages (for the broad subject), both for clarity and to assist in keeping different efforts consistent -- but that it certainly should be retained as visible to non-admins. I think that the red vs blue link issue is minor (but not totally negligible) and outweighed by the disadvantages of hiding the history of previous efforts. I strongly encourage redirecting such pages to appropriate WikiProject pages (after copying over the details there). JesseW (talk) 18:11, 3 July 2020 (UTC)

• @JesseW: I agree that history shouldn't be deleted, but I think we should approach this in terms of what we want to see from these works, rather than what to do with the handful of examples at PD. There are hundreds of periodicals we could have but don't, and this applies to those as well. If we can come to a conclusion about what is and isn't wanted, we can make all the deletion requested works conform to that easily enough. Inductiveload—talk/contribs 20:55, 3 July 2020 (UTC)

• I think these pages are necessary to list index pages and external scans of multi-volume works (such as encyclopaedias and periodicals) especially if they are wholly or partly anonymous or have many authors or are simply large. I think it makes no difference whether such pages are in the mainspace, the portal space or the project space (except that it is harder to find pages outside the mainspace). The point is that these works often have so many volumes (often dozens or hundreds) that they must have their own page, and cannot be merged into a larger portal or wikiproject. If the community starts insisting on index pages, what will happen is the rapid upload of a large number of scans for the periodicals that already have their own page. Likewise if the community insists on transclusion. I also think it is reasonable to have a contents page in the mainspace, as it allows transclusion of articles. Most importantly, new restrictions should not immediately apply to existing pages that were created before the introduction of the restrictions. This is necessary to prevent a bottleneck. James500 (talk) 23:55, 3 July 2020 (UTC)

move the works to a maintenance category, and i will work them; delete them and i will not: i find your sword of Damocles demotivating. Slowking4 ⚔ Rama's revenge 01:55, 5 July 2020 (UTC)

@User:Slowking4: I am not proposing a sword of Damocles. I agree that the imposition of deadlines is counter-productive. I do not support the deletion of any of these pages. I would prefer to see them improved. James500 (talk) 04:38, 5 July 2020 (UTC)

TEA is on his usual deletion spree. not a fan. will not be finding scans to save texts, any more. he can do it. Slowking4 ⚔ Rama's revenge 00:15, 6 July 2020 (UTC)

The entire point of moving this here, and not staying at WS:PD is to decouple from the emotions that get stirred up in a deletion discussion. Let's keep deletion out of this. If we come up with some idea of what we do and don't want, then we can go back to WS:PD and decide what to do. I imagine that all that will be needed will be a fairly limited amount of housework to bring those works up to some standard that we can decide on here, and all the collective works there will be easy keeps. Hopefully with some kind of consensus that we can point at to outline a minimum viable product for such works going forward. There are hundreds and thousands of dictionaries, encyclopedias, periodicals and newspapers that we could/will, quite reasonably, have only snippets of. How do we want to present them? What, exactly, is the minimum threshold? Let's head of all those future deletion proposals off at the pass, because deletion proposals often cause friction. Inductiveload—talk/contribs 00:47, 6 July 2020 (UTC)

and yet deletion is the default method to "motivate" quality improvement. i reject your assertion that "emotions get stirred in a deletion discussion", rather, anger is a valid response to a repeated broken process being kicked down on the volunteers. it is unclear that a minimum threshold is necessary, rather a functional quality improvement process is. until we have one, you should expect to see this periodic stirring of emotions, as the non-leaders act out. Slowking4 ⚔ Rama's revenge 11:53, 9 July 2020 (UTC)

@Slowking4: Thank you for presenting this opinion, and I'm sorry if I have not made myself clear. We do need to figure out how to avoid a de-facto process of using WS:PD as an ill-tempered ad-hoc venue for "forcing" improvements on people who have somehow managed to generate works that are so in need of improvement that another user has nominated them for deletion. Please also consider looking at #Re-purpose_WikiProject_OCR_to_WikiProject_Scans for an idea to have a "functional quality improvement process" to which such works could be referred upon discovery rather than kicking them straight to WS:PD. If you have other ideas or you have previously suggested something similar to address these frustrations, you could detail them there. Personally, I think we should always prefer improvement over deletion. Exactly what the remediation is (refer to a putative WP:Scans, WS:Scriptorium/Help, directly WS:PD as now, or something else) is not what this thread is for. This thread is for discussing, what, if anything, should be the tipping point for deeming a page "lacking" and doing something about, whatever "something" is. I don't think I can be much clearer that this is not about deletion. If we also have a better venue for improvements, then that's even better.

For example, my personal feeling and !vote on A Critical Dictionary of English Literature is "keep and improve", despite it lacking scans or even links to scans, having only one article and no other content, not even a title page: in short, failing almost every criterion suggested so far in this thread. The only thing it does have is have is good text quality of the one entry. I personally do not think this work should be deleted, but I do think it should be improved in specific ways. The first half of that sentence is not the focus of this discussion, the second half is. Inductiveload—talk/contribs 14:18, 9 July 2020 (UTC)

deletion threat has been an habitual method of communicating by admins since the beginning of the project. and text dumps have been habitual following in the guttenberg example. culture change and process change would be required to change those behaviors. we could may it easier to start scan backed works, but the wishlist was not supported. Slowking4 ⚔ Rama's revenge 21:00, 14 July 2020 (UTC)

I don't think this needs to be much of an issue going forward -- we all agree that it's OK to create Index pages for scans, even if none of the Pages have been transcribed yet; so the only case where this would come up is recording research where no scan has yet been identified as suitable to be uploaded. And for that, I still think a WikiProject page is the right location, not mainspace. (Or, if you must, your userpage.) JesseW (talk) 00:59, 6 July 2020 (UTC) I realized I may not have been clear enough here -- in my view, the ideal process goes like this:

1. Decide on a work you are interested in (in this case, a periodical/encyclopedic one) -- don't record that anywhere on-wiki (except maybe your user page)
2. Find and upload (to Commons) a scan of one part/issue/etc of the work.
3. Create a ProofreadPage-managed page in the Index: namespace for the scan. (You can stop after this point, without worry that your work will later be discarded.)
4. EITHER
   1. Put further research (on other editions, context, possible wikification, etc.) on that Index_talk page.
   2. Proofread a complete part of the scan (an article from the magazine issue, a chapter from the book, a entry from an encyclopedia, etc.) and transclude it to the mainspace (and create necessary parent pages), and put the further research on the Talk: page of the parent mainspace entry.

If you can't find any scan, and don't want to leave your working notes on your user page, put them on a relevant WikiProject's page.

If you come across such research done by others and misplaced, follow the above process to relocate it to an appropriate place, then redirect the page where you found it to the new location. That's my proposal. JesseW (talk) 01:08, 6 July 2020 (UTC)

@JesseW: It's not clear to me in your above whether when you use the term "index" you refer to a ProofreadPage-managed page in the Index: namespace, or a general wikipage in the main namespace on which an index-like structure (and/or a ToC, or similar) is manually created. Could you clarify? --Xover (talk) 05:14, 6 July 2020 (UTC)

I meant the namespace. Clarified now. JesseW (talk) 05:17, 6 July 2020 (UTC)

• Hoo-boy. Y'all sure know how to pick the difficult issues…
  My general stance is that: 1) scans and Index: (and Page:) namespace pages have no particular completion criteria to meet to merit inclusion, and can stay in whatever state indefinitely (there may be other reasons to get rid of them, but not this); and 2) the default for mainspace is that only scan-backed complete and finished works that meet a minimum standard for quality should exist there.
  That general stance must be nuanced in two main ways: 1) there must be some kind of grandfather clause for pre-existing pages; and 2) there must exist exceptions for certain kinds of works that meet certain criteria. I won't touch on the grandfather clause here much, except to say I'm generally in favour of making it minimal, maybe something like "No active effort to get rid of older works, but if they're brought to PD for other reasons they're fair game". The design of a grandfather clause for this is a whole separate discussion, and an intelligent one requires analysis of existing pages that would be affected by it. It is always preferable to migrate pages to a modern standard, so a grandfather clause is by definition a second choice option.
  Now, to the meat of the matter: the exceptions…
  We have a clear policy to start from: no excerpts. Works should either be complete as published, or they should not be in mainspace. But quite apart from the historical practices that modify this (which are somewhat subjective and inconsistent, so I'll ignore them for now), there are some fairly obvious cases that suggest a need for more nuance than a simple bright-line rule alone provides. The major ones that come to mind are: 1) massive never-completed projects like EB1911 or the New York Times (EB because it's big; NYT because new PD issues are added every year); 2) compilations or collections of stand-alone works with plausible claim to independent notability.
  For encyclopedias and encyclopedia-like things, we have to accept some subsets due to sheer scale of work. But when that is the grounds for exception, there needs to be some minimum level of completion. I'm not sure I can come up with a specific number of pages/entries or percentage, but it needs to be more than just a single entry (and, obviously, only complete entries). For this kind of exception to apply, I think it needs to be a requirement that the framing structure for it is complete: that is, the mainspace page should give a complete overview of the relevant work even if most of it is redlinks. That includes title pages and other prolegomena when relevant. For a periodical like the NYT, that means complete lists of issues with dates and other such relevant information (e,g. name changes etc.). For preference, these kinds of things should be in Portal: namespace or on a WikiProject page until actually complete, but that will not always be practical (EB1911 and NYT are examples of this). Mainspace or Portal:-space should never contain external links (i.e. to scans) or links to Index: or Page: space (except the implied link of transclusion and the "Source" tab in the MW UI provided by ProofreadPage).
  For exception claimed under independent notability there are a couple of distinct variants.
  Newspaper or magazine articles need to have a certain level of substance in addition to a specific identifiable byline (possibly anonymous or pseudonymous, and possibly identified after the fact by some other source, such as the Letters of Junius) in order to qualify. It is not enough to ipso facto be a newspaper article, a magazine article, a poem, or an encyclopedia entry. On the one hand we have things like dictionaries and thesauri, where an entry could be as little as two words. Or a one-sentence notice without byline in a newspaper. Or two rhymed lines (technically a poem) within a 1000-page scholarly monograph.
  To merit this exception it should be reasonable to argue that the "work" in question should exist as a stand-alone mainspace page (not that we generally want that; but as a test for this exception, it should be reasonable to make such an argument). This would clearly apply to moderately long entries in the EB1911 written by a known author that has their own Wikipedia article. It would apply to short stories or novella-length serialisations in literary magazines by authors that have later become famous (or "are still …"). It would apply to various longer-form journalistic material from identifiable journalists (again, rule of thumb is notable enough for enWP article), including things in magazines that have similar properties. For most periodicals the most relevant atomic (indivisable) part is the issue not the entry or article, but with some commonsense exceptions.
  It would, generally, not apply to things that are works by a single author, like a scholarly monograph that just happens to be arranged in "entries" rather than chapters. It would not apply to things that are essentially lists or tables of data. It would not apply to short entries in something encyclopedia-like or entries that are not by an identifiable author. The OED for example, iirc, is a collective work where entries are by multiple not individually identifiable authors (and each entry is mostly very short too); only the overall editor is usually cited.
  For works claiming this exception too the framing structure should be complete, even if most of it are redlinks. The same general rules about Portal:/WikiProject and no external or Index:-space links apply. An exception would be for periodicals where new issues enter the public domain every year; and we should generally avoid including even redlinks for the non-PD issues here (but may allow them in a WikiProject page). For non-periodical works in multiple volumes where some volumes were published after the PD cutoff, including listings for the non-PD volumes (but not links to scans; those are a copyvio issue) is ok.
  Poems, short stories, and novellas are a special class of works here. A lot of these were first published in a magazine (possibly serialized), and a lot of them exist as multiple editions in substantially the same form. Some exist in multiple versions. These should all primarily exist the same way as chapters as part of their various containing works; but there are some cases where we might want to have, for example, a series of connected pages of the poems of Emily Dickinson. I am significantly ambivalent about this practice, as it amounts to making our own "edition" or "collection" of her poems (in violation of several of our other policies), but I acknowledge that it is an established practice and it is something that has definite value to our readers. It may be that it is actually a practice that should be governed by its own dedicated policy rather be attempted to be handled within these other general policies.
  For the sake of example; applying this to the works Inductiveload listed at the start of this thread would shake out something like this:
  ⁠• Auction Prices of Books—This work appears to have no sensible subdivisions and is in any case by a single author. I see no obvious reason to grant this work an exception, except under sheer volume of work and even there I would want to see both a substantial proportion completed and some kind of ongoing effort towards completion (no particular time frame, but definitely not infinite and definitely not as an effectively abandoned project). In a deletion discussion I would very likely vote to delete the mainspace pages here (but, as nearly always, to keep the Index: and Page: namespace artifacts). I don't see this as a reasonable candidate for a Portal:, nor really a good fit for a WikiProject (though I probably wouldn't object to a WikiProject if someone really wanted one).
  ⁠• Central Law Journal/Volume 1—A single volume is too little, so I would want to see a complete structure for the entire Central Law Journal, with level of detail for each volume similar to the one existing volume. Each article in the journal can be individually considered for a stand-alone work exception; but for the collection I would want to see at minimum a full issue finished to justify having the mainspace structure, and preferably multiple issues (in a deletion discussion I might insist on multiple issues). Index: and Page:-space artefacts can, of course, stay. A Portal: might make sense for selections from the journal, of articles that meet the standalone work exception. A WikiProject to coordinate work and track links to scans etc. might be a decent fit here, if someone wanted that. As it currently stands I would probably vote delete for the mainspace artefacts (with option to move whatever content has reuse value to a non-mainspace page for preservation; and undeleting if someone wants to work on something is a low bar).
  ⁠• A Critical Dictionary of English Literature—The top level mainspace page has near-zero value, existing only to link to the single transcribed entry. For a credible claim to exception to exist it would need to be a complete framework for the work as a whole, and significantly more than a single entry must be complete. I would probably also want to see ongoing work, unless a substantial percentage of the entries were complete. The single finished entry is eligible to claim a standalone work exception, but I think it probably would not meet my bar for that (I might be wrong; and the rest of the community might judge it differently). In a deletion discussion I would probably vote to delete all the mainspace artifacts here (as always keeping Index:/Page: stuff) but with a definite possibility that I might be persuaded on the one completed entry (an absolute requirement for convincing me would be to scan-back it: as a separate issue, my tolerance for grandfathering of non-scan-backed works is small, and effectively zero for new/non-grandfathered works).
  ⁠• Bradshaw's Monthly Railway Guide—Would need a full framework and a number of individual issues finished to merit a mainspace page. I see no credible subdivisions for a standalone work exception, but might be persuaded otherwise if, say, one of the train tables was used as a (reliable primary) source in a Wikipedia article (implying some sort of notability beyond just being raw data). In a deletion discussion I would probably vote to delete all mainspace artifacts here. If anyone made the argument, I would entertain the notion that there is value in treating train tables like poems, and hosting a series of train tables like we do Dickinson's poems; but that would require a substantial number of them completed.
  For everything above my stance is nuanced by a willingness to accept temporary exceptions for things that are actively being worked: active being operative, but with no particular deadline to complete the work. We have differing amounts of time available, and some works are so labour-intensive or tedious to do, that my person threshold for "active" is a pretty low bar to clear. If it's months and years between every time you dip in and do a bit I might start to get antsy, but days or weeks probably won't faze me. And that the projected time to completion is very long at that pace is not particularly a problem so long as it is not infinite. Within those parameters I would always tend to err on the side of letting contributors just get on with it in peace, regardless of any of the policy-like rules sketched above.
  I also want to emphasise that I think this is a very difficult issue to deal with. There are a lot of competing concerns, and a lot of grey areas that will likely take individual discussions to resolve. My balance point on this issue is partly formed by a broader concern about our overall quality (we have waay too many works of plain sub-par quality, and too many not up to modern standards) and a hope that by preventing the creation of these kinds of works (rather than deleting them after creation) we will be able to retain the good and desirable exceptions without dragging down quality, and without the traumatic and stressful events that deletions and proposed deletion discussions are.
  And for that very reason I am grateful this issue was brought up here for discussion, and I hope we can end up with some clear guidance, possibly in the form of a policy page, going forward. And in any case, since it will create de facto policy, this is a discussion that needs to stay open for a good long while (there are several community members that have not yet commented whose opinion I would wish to hear before closing this), and depending on how well we manage to structure the consensus, may also require a formal vote (up in the #Proposals section). --Xover (talk) 09:03, 6 July 2020 (UTC)
•  Oppose. It is becoming clear that a policy on incomplete works in the mainspace is going to place enormous pressure on individual editors. I think it would be more effective to start a wikiproject devoted to scan-backing works that lack scans and so on. James500 (talk) 12:14, 6 July 2020 (UTC)
  • @James500: FYI, this thread was made in order to provide an exception to the current policy of "no excerpts". A literal reading of the policy as it stands has a plausible chance of coming down delete on the mainspace pages over at WS:PD. This thread is a chance to come up with a better way to support such partial collective works. That we have several substantially incomplete and abandoned collective works lolling around in mainspace is actually the result of laxity in respect to stated policy (not to say I think it's a bad thing). The deletion proposals, whatever you may think of them, are actually not in contradiction to policy. That said, as always, there is scope to adjust policy. Which is what this is.
  • Now, in terms of a WikiProject to scan back works, I think that is a good idea. See #Re-purpose_WikiProject_OCR_to_WikiProject_Scans above, which proposed to reboot Wikiproject OCR as a scan-backing Wikiproject. Inductiveload—talk/contribs 14:40, 6 July 2020 (UTC)
    • The policy says "When an entire work is available as a djvu file on commons and an Index page is created here, works are considered in process not excerpts." A literal reading of that policy is that no scan-backed work is an excerpt (it is expected to be completed eventually). Further the policy refers to "Random or selected sections of a larger work". A literal reading of that expression is that it does not include lists of scans, or auxilliary content tables, as they are not "sections" (they are not part of the work), and that not every incomplete portion of a work is either "random or selected" (which would not include starting from the beginning and getting as far as you can, with intent to finish later). I could probably argue that an encyclopedia article or periodical article is a complete work. James500 (talk) 15:16, 6 July 2020 (UTC)
• Nice wall of text, Xover (and I say that with great respect!) -- it generally makes sense and sounds good to me. As another hopefully illustrative example, take The Works of Voltaire, which I've been digging thru lately. I think this would very much satisfy your criteria as a large work, with sufficient scaffolding to justify the mainspace pages that exist for it. I would love to hear others thoughts on that. JesseW (talk) 16:07, 6 July 2020 (UTC)

  @JesseW: Yeah, apologies for the length. Brevity is just not my strong suit.

  The Works of Voltaire probably qualifies on sheer scale of work, yes. I don't think the current wikipage at The Works of Voltaire is quite it though: as it currently stands it is more WikiProject than something that should sit in mainspace (its contents are for Wikisource contributors, to organise our effort, not our readers, who want to read finished transcriptions). It also mixes a work page with a versions page in a confusing way. So I would probably say… Move the current page to Wikisource:WikiProject Voltaire; create a new The Works of Voltaire as a pure versions page, linking to…; The Works of Voltaire (1906), that is set up as a work page with the cover and title (and other relevant front matter) of the first volume, and an AuxTOC (and possibly also the {{Works of Voltaire}} volume navigation template). I don't know how tightly coupled the volumes of this edition are (does the first volume have a common ToC or index of works for all the volumes?), so some flexibility on format may be needed to make sense. But as a base rule of thumb it should start from a regular works page and deviate only as needed to accommodate this work (mainly the size is different).

  In any case… With a volume or two completed (they're only ~350 pages each) I'd be perfectly happy having something like that sitting around. With less then that I'd possibly be a bit more iffy, but it's hard to put any kind of hard limit on that. And with somebody actively working on it I'd be in no hurry whatsoever regardless of current level of completion.

  PS. I'm pretty sure a large proportion of the contents of these volumes are works that would qualify under "standalone works" that could exist independently in mainspace, regardless of what's done with the The Works of Voltaire page. Even his individual poems and essays can presumably make a credible claim here (because it's Voltaire; less famous authors would have a higher bar). Better as part of the edition, but also acceptable on their own. --Xover (talk) 16:56, 6 July 2020 (UTC)

• @JesseW: I personally take no issue with this page's existence (actually I think it's a nice work and good way to allow an important author's works to be slotted in piece-by-piece. I have some general comments which overlap with this thread (written before Xover's reply, so pardon overlap):

• • First off, I differ with Xover in terms of the scan links: I think they're better than nothing, and I don't see much value in duplicating the volume list onto an auxiliary page just to add scan links. However, I can sympathise with the sentiment that our mainspace shouldn't direct users off-wiki (or at least off-WMF). But if we don't have the scans, and that's what the user wants, they're leaving anyway. Real answer: import moar scans!
  • No scan links are necessary where the volume exists in mainspace and is scan-backed (e.g. v3)
  • Ext scan links should only be used when there is no Index page or imported scan. Use {{small scan link}} or {{Commons link}} when possible (e.g. v2)
  • The first volume list could probably be in an AuxTOC to mark it out as WS-generated content.
  • The "Other editions" section belongs on an auxiliary namespace page (Talk, Portal or Wikisource). I suggest the Talk page is best in this case. Inductiveload—talk/contribs 17:35, 6 July 2020 (UTC)

• @Xover: I am in agreement with the majority of what you say. Particularly, I think a framework around any collective work (be it a single-volume biographical dictionary or a 400-issue literary review spanning 80 years) is the critical prerequisite, plus at least some scans, the more the merrier. Where I think I differ:
  • I am inclined to be a bit more relaxed in terms of how much of a work we need. As long as a single article exists, it's not "trivial" (e.g. only a short advert or some incidental text like a "note to correspondents", as opposed to an actual article), it's well-formatted and scan-backed, and a complete framework exists, including front matter and a TOC, such that's it is easy for anyone to slot in new pieces, I'd be fairly happy. Lots of periodicals have all sort of tricky bits like tables of stocks or weather tables and writing into policy that those must be proofread in order to get the "real" articles into mainspace would be a chilling effect, in my opinion. If you allowed an exception, it would be verbose and tricky to capture the spirit without saying "unless, like, it's totally, like, hard, man".
  • I am not dead against scan links in the mainspace at the top level, when such a top-level page exists. See my comments on Voltaire above. I am against them where they could sensibly be on an Author page and they are the only mainspace content.
  • I am ambivalent on the presence of, e.g., disjointed train timetables. It's not my thing to have a smattering of random timetables, but as long as they're individually presented nicely, it's not too offensive to my sensibilities. I might question the sanity of someone who loves doing tables that much, but whatever floats the boats! Also, I think that this might circle back to "good for export" - a mark which certainly would require completed issues or volumes. If you want to get that box ticked, you have to do it all.
  • Re the "notability" aspect of individual articles, I'm not really bothered by that, as I don't think we'll see a flood of total dross because few people really want to take the time to transcribe 1867 articles about cats in a tree from the Nowhere, Arizona Daily Reporter, and, actually I think some of the "dross" can be quite interesting in a slice-of-life kind of a way (always assuming well-formed and scan-backed). And the real dross is usually so bad (no scans, raw OCR, etc) that it can be dealt with outside of this topic. I think part of the value of WS is the tiny, weird and wonderful, not just in blockbusters like War and Peace and Pultizers. I think I might like to see more of our articles strung together thematically via Portals, but that's another day's issue. Inductiveload—talk/contribs 17:35, 6 July 2020 (UTC)
    • @Inductiveload: We appear to be mostly in agreement. But… instead of me dropping another wall of text on the remaining points of disagreement, maybe that means we're in a position to try to hash out a draft guidance / policy type page with the rough framework? Then we could go at the remaining issues point by point. Because I think I'm in with a decent chance to persuade you to my point of view on at least some of them, but this thread is fast getting unwieldy (mostly my fault). It would also probably be easier for the community to relate to now, and much easier to lean on in the future. --Xover (talk) 18:31, 6 July 2020 (UTC)
      • @Xover: If there are no more comments forthcoming after a couple of days, I think that makes sense. I don't want to railroad it: considering we have at least one !vote for "do nothing", I'd like to see if there are any other substantially different opinions floating about. Inductiveload—talk/contribs 17:41, 7 July 2020 (UTC)

The quantity of text here has grown far faster than my ability to absorb it, so rather than continue to put it off, here's my position: I don't see any problem with transcriptions that are scan-backed, even if the transcription only covers a small fraction of the entire scan. If Sally chooses (say) to transcribe a favorite story, that happened to be published in an issue of Harper's back in the 1890s, and goes to the trouble of uploading the full issue, but only creates pages for the one story that interests her, I think that's great. It doesn't matter to me whether she intends to work on the other pages or not. If it's not scan-backed, but it's fairly high quality, I am personally willing to do some work trying to locate a scan and match it up to the text; I'd rather we take that approach, than deletion, though of course deletion is the better option in some cases where the scan is very hard to come by.

If all this has been said above, or if I've misunderstood the topic, my apologies. Please take this comment or leave it, as appropriate. -Pete (talk) 02:00, 8 July 2020 (UTC)

Apologies, I see I had missed the point.

I disagree with Xover's statement that a top-level page for a publication, with a link only to a single article within the publication, has "near-zero value." Such a page can serve an important function linking content together in ways that help the reader (and search engines) find the content they're looking for, or understand the context around it. For instance, A Critical Dictionary of English Literature is linked from the relevant Wikidata entry. The banner on the Wikisource page clearly tells a Wikisource reader that they won't find a full transcription here; and with a simple edit, it could link to a full scan on another site, or (with perhaps a little more effort) even transcription links here on Wikisource. This page has been here since 2010; we don't have any way of knowing what links might have been created elsewhere in the intervening decade. (I do think that new pages like this should not be created without a scan at Commons to be linked to.) -Pete (talk) 02:12, 8 July 2020 (UTC)

I'm really bad with walls of text, so I have only read a tiny portion of the above discussion. But I want to mention a couple of things that I think are worth considering in this discussion.

• Most of the time, a mainspace "work" that is only a table of contents, but which has none of the actual content, and is not actively being worked on, can be (and should be) deleted as No meaningful content or history under our deletion policy.
• A mainspace work that has only a little bit of content, but that content is a work unto itself within the scope of Wikisourse, should be kept. Most periodicals are like this. For an example, see the Journal of English and Germanic Philology which only has one hosted article, but that hosted article is scan-backed and firmly within scope.
• On some occasions, empty mainspace works do have value. I ended up creating the page The Roman Breviary, depsite containing no actual content, mostly because there are a lot of works that link to it, using many different titles, and if someone uploaded a copy of the work under one title then many of the links would remain red because they point to different titles of the work. This could be easily solved by creating redirects to a simple placeholder page, so I did. I tried to make the placeholder page as useful as a placeholder page can be, as it contains useful information about the history and authorship of the work, and links to the Index pages where the transcription will take place.

Anyway those are my 2 cents, sorry if they are redundant —Beleg Tâl (talk) 00:40, 29 July 2020 (UTC)

Proposal

Since there has been no extra input for a month, and not wanting this section to get archived without at least attempting a proposal, I have started a proposal #Collective work inclusion criteria above. Inductiveload—talk/contribs 11:00, 25 August 2020 (UTC)

Since the proposal has now slipped off the main page (to here), with vague support for the first part (collective work inclusion criteria) and a fairly consistent opposition to the second (no-content pages), my plan is to transfer the first part, as guidelines rather than policy, to Wikisource:Periodical guidelines. As non-binding guidelines, they can then be worked on further in situ. Sound OK? Inductiveload—talk/contribs 08:10, 16 April 2021 (UTC)

The example given in Wikisource:Periodical guidelines might be improved, PSM is and was an exercise that has gone its own way (no offense to @Ineuw:, this is a site under development and that is only one example).CYGNIS INSIGNIS 13:05, 17 April 2021 (UTC)

@Cygnis insignis: You would be wrong to think that I am offended. Remember that when I started, I knew everything. By now, so much of that knowledge is lost that I am happy to listen. Would you elaborate please? — Ineuw (talk) 19:50, 17 April 2021 (UTC)

---

I've created Bradshaw's Monthly Railway and Steam Navigation Guide (XVI) - it couldn't be done on one page, due to the very high number of template transclusions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:52, 1 September 2020 (UTC)

@Pigsonthewing: The links in the toc on that page appear non-functional. Also, depending on just exactly which templates were the culprit, it is possible that you may be able to put all the content you wanted onto one page now due to some recent technical changes (template code moved to a Lua module which drastically improves performance and prevents hitting transclusion limits until much later). Xover (talk) 11:17, 14 September 2021 (UTC)

Create the Draft namespace to hold substantially empty works? Then delete if no improvement after months?--Jusjih (talk) 19:22, 1 November 2021 (UTC)

The issue is that the "substantially empty works" can have useful and complete content that stands alone. For example, an article from a scientific journal.

I would not want to see that either shunted into a Draft namespace to rot or deleted a few weeks down the line.

Index and Page namespaces provide our long term staging areas, and works can and do remain unfinished there for years. But what do we do when a self-contained piece of a larger work is ready? Inductiveload—talk/contribs 20:29, 1 November 2021 (UTC)

Subscribe to the This Month in Education newsletter - learn from others and share your stories

Dear community members,

Greetings from the EWOC Newsletter team and the education team at Wikimedia Foundation. We are very excited to share that we on tenth years of Education Newsletter (This Month in Education) invite you to join us by subscribing to the newsletter on your talk page or by sharing your activities in the upcoming newsletters. The Wikimedia Education newsletter is a monthly newsletter that collects articles written by community members using Wikimedia projects in education around the world, and it is published by the EWOC Newsletter team in collaboration with the Education team. These stories can bring you new ideas to try, valuable insights about the success and challenges of our community members in running education programs in their context.

If your affiliate/language project is developing its own education initiatives, please remember to take advantage of this newsletter to publish your stories with the wider movement that shares your passion for education. You can submit newsletter articles in your own language or submit bilingual articles for the education newsletter. For the month of January the deadline to submit articles is on the 20th January. We look forward to reading your stories.

Older versions of this newsletter can be found in the complete archive.

More information about the newsletter can be found at Education/Newsletter/About.

For more information, please contact spatnaikwikimedia.org.

---

About This Month in Education · Subscribe/Unsubscribe · Global message delivery · For the team: ZI Jony ^(Talk), Thursday 10:31, 09 November 2023 (UTC)

A maintenance thread

Hi to all. As mentioned in the previous section there has been questions about where are we with maintenance, and with its coordination. We have

• Wikisource:Maintenance, and
• Wikisource:Maintenance of the Month

which were our attempts to get us on track years ago, and probably have fallen away since.

I know that I have my own maintenance schedule, scripts, and the like that I potter through--on what seems like one monotonous journey of (re)painting a bridge--to the point that my actual transcription editing is few and far between these days. I also know that doing new works and new information provision is always more fun than maintenance.

So

• Are there people interested in undertaking maintenance tasks?
• What maintenance tasks do you wish to see?
• What maintenance tasks would you have an interest in undertaking?
• What information and guidance would you expect to see for your tasks?
• Do you sort of want to own your task? Or do you just wish to lucky dip tasks that are there?
• New one-offs? Or a repeated, regular.
• Does anyone have an interest in coordinating/overseeing?
• Have good vision on how maintenance has been done elsewhere that would give us a good starting model?

(and your own questions, opinions, knowledge hereafter) — billinghurst sDrewth 03:18, 28 April 2023 (UTC)

Mulling this one over still (thanks for taking the initiative!), but… Regarding Maintenance of the Month: it'd be a nice thing to revive, but it's also one of those things that would require someone to run the process (light, or more extensive, but someone would need to run it either way), so I think maybe reviving that is not where we first start. Keeping it in mind as a tool in our toolbox for organising efforts would be smart though, especially if someone volunteers to be the one to manage the process. Xover (talk) 10:19, 5 May 2023 (UTC)

header ; footer field not editable

the header and footer field are not open to edit, when i hit the edit button. this will stop proofreading for pages for fields that are not automatically generated.

apparently it is a setting, since the problem does to show while logged out.

it happens in vector 2022, vector and timeless skin.

apparently, in order to check the "Preferences > Editing > Proofreading interface options > Show header and footer fields toggle the visibility of the noinclude header and footer sections when editing in the Page namespace" the editor must first uncheck the "2010 wikitext editor", or it is invisible. - that is bad UX design. Slowking4 ‽ digitaleffie's ghost 14:01, 26 September 2023 (UTC)

@Slowking4: The way it should be working is that if you have the toolbar turned on then you can toggle the header and footer via the button there, and if you have the toolbar turned off then you have to go to preferences to toggle it (the preference label is "Show header and footer fields when editing in the Page namespace"). Is that not what you're seeing? Sam Wilson 09:55, 8 October 2023 (UTC)

IMHO, it's best for a user to set first the universally relevant preferences, and then set the site exceptions, par site. — ineuw (talk) 03:11, 30 October 2023 (UTC)

Some problems in page namespace

Tracked in PhabricatorTask T348382

When editing in the page namespace, since a couple of days - I don't know exactly since when -, I encounter two strange changes, which may be connected:

1. on the bottom, besides the coloured radio-buttons for "without text, not proofread, problematic, proofread, validated" (grey, pink, blue, yellow, green), there appears a text "<a href="/wiki/Help:Page_status" title="Help:Page status">Page status</a>". This looks like an error.
2. when changing the button, e.g. from "not proofread" (pink) to "proofread" (yellow), and then pressing "Show preview", the button jumps back to the previous state. So that I have to click the correct radio-button again, when I publish my edits. This is extra work, and it never worked this way in the (recent) past.

What has happened? Who can change this back to the old situation?

Thanks in advance, --Dick Bos (talk) 18:17, 7 October 2023 (UTC)

Both problems appear also in the French Wikisource. Here, I can only reproduce the second problem (maybe something has changed). I just created a Phabricator task. Seudo (talk) 20:22, 7 October 2023 (UTC)

@Dick Bos, @Seudo: These bugs were from work I did on the page-quality widget. Sorry! Fixes for some parts are already done and merged and will be deployed soon, and the remaining part is now waiting review. Let me know if there are other bugs, and thanks for making the phab tasks. Sam Wilson 01:37, 8 October 2023 (UTC)

@Sam Wilson. All is functioning normal again (also on Dutch Wikisource) - as far as this little problem concerns. Thanks a lot for the quick repair. --Dick Bos (talk) 17:47, 11 October 2023 (UTC)

@Dick Bos: Great! Let me know if you find other problems. Sam Wilson 00:39, 12 October 2023 (UTC)

A Portal For Sandwich Recipes?

Under what portal category could the portal for compilations of sandwich recipes, either Portal:Sandwich recipes or simply Portal:Sandwiches, go under? -- Apisite (talk) 11:41, 8 October 2023 (UTC)

See Portal:Cookbooks; LC classification TX. You can include the sandwich recipe books in this portal, unless there are a substantial number of works that warrant a separate portal. Ciridae (talk) 11:38, 9 October 2023 (UTC)

@Ciridae: Thanks for the reply; I added a Cookbook from my Wish-list to the Portal of Cookbooks. --Apisite (talk) 19:41, 9 October 2023 (UTC)

@Apisite: The book has been uploaded to Commons and the index page can be found here: (transcription project). Happy proofreading! Ciridae (talk) 05:48, 10 October 2023 (UTC)

@Ciridae: Thanks, the sandwich book was a pleasure to proofread. --Apisite (talk) 05:48, 11 October 2023 (UTC)

@Apisite: You need to add headers and footers in the pages; there are images there. Also the Table of Contents needs to be fixed, and you need to check the alignment of the text in the pages. Have a look at the help pages. Also, check out a few of the completed works from the main page for tips. Ciridae (talk) 07:40, 11 October 2023 (UTC)

@Ciridae: I updated the table of contents by adapting what was done with the table of contents of the book The Tsar's Window. Now I have to sleep, at least. --Apisite (talk) 08:37, 11 October 2023 (UTC)

New gadget: page cleanup button

(I'm sure there's been discussion about this before, but I can't find it now; sorry if this is a rehash!) I'm wondering about converting the PageCleanUp script into a gadget. I think it'd be good to use @Jan.Kamenicek's version that doesn't do the comma-before-capitals replacement. My main reasoning is that I'm often showing people how to proofread, and I click this button in my toolbar and they want the same thing — but it's tricky to explain adding user scripts to a newbie, and a gadget would be much more approachable. What do people think? I'm sure there are lots of different ways of doing this sort of task (e.g. meta:TemplateScript), but a simple toolbar button is a good start I think. Sam Wilson 11:15, 11 October 2023 (UTC)

Sounds very good to me. --Jan Kameníček (talk) 21:43, 12 October 2023 (UTC)

And for those of us who don't use a toolbar? Will it still be invokable from the sidebar as currently? Beeswaxcandle (talk) 04:52, 14 October 2023 (UTC)

@Beeswaxcandle: The user script I'm talking of doesn't currently load in the sidebar, but definitely it can be changed to do so if there's no toolbar, good idea. @Xover, @Billinghurst: would either of you be interested in making this gadget (pinging you as I think you've worked on similar things recently)? Or could I be given interface-admin rights to do so? Sam Wilson 03:44, 16 October 2023 (UTC)

No available time to do much Sam. I know that my cleanup script has complexity, and elements of specificity for the quirky works that I do. Given time again, I would love to be able to compartmentalise the elements of the cleanup, and turn certain ones on per work. It would be great if we could specify per index level which cleanup compartments would apply for a work. [Think that would be really helpful for setting up shared contributed works] — billinghurst sDrewth 02:05, 7 November 2023 (UTC)

@Billinghurst: No worries, I figured as much! And it's a good point about the complexities of clean up scripts; it's hard to make a general-purpose one. I'm now thinking that it's probably a better use of time to come up with a way of composing sets of regexes together as you say, to form reusable compartments for this stuff (and probably still have a general cleanup one, different per language). It'll be easier to build that sort of thing in the Wikisource extension, I think, so I've made task T348829 for that. Sam Wilson 05:36, 7 November 2023 (UTC)

Error in original TOC

Hi. I have the situation of a listing missing from an original TOC, and I want to make sure I proceed as Wikisource would want me to.

The offending title is at https://en.wikisource.org/wiki/Index:Varied_Types_(1903).djvu. The TOC on the index page reflects what the original source does. However, between the chapters Maeterlinck and Queen Victoria, there actually exists an additional omitted chapter listing in the book, which starts on page 217, where the Queen Victoria chapter is supposed to reside.

So my initial urge is to just fix it—add the missing chapter in the TOC, shift the others down, and correct any page numbers. If I do this, do I make some sort of notation about what was done? Or should I just leave everything as-is claiming this was the way the original source was published?

Thank you for your time. snafu22q (talk) 18:03, 13 October 2023 (UTC)

What I do in this situation is transclude the printed TOC as is and add an {{AuxTOC}} for the missing items. Beeswaxcandle (talk) 04:44, 14 October 2023 (UTC)

Since you're using {{TOC begin}}, one alternative is to add the wst-toc-aux class to get the green background (as defined in Template:TOC templates/styles.css)—like this. For the page numbers, I would use {{SIC}}. In general, you don't want to change the original text without saying that's what you're doing, but it is good to fix these errors so readers aren't confused. —CalendulaAsteraceae (talk • contribs) 04:08, 17 October 2023 (UTC)

Thank you very much for your help. It turned out exactly the way I would have wanted, but I wasn't sure how to get there, and I'm not sure I understand exactly *why* it works like it does. One question I have is about the fvn tagging—I'm assuming that's what nullifies the small caps format for that small piece of text? I have other questions, but I guess I'll figure them out as I go along.

While I have your attention, could you see if I have transcluded the chapters correctly? By that i mean there are pages between the chapters that I didn't think should be included, but I'm really not sure. And do I let the one 'problematic' page prevent me from labelling the index as proofread (once I finish the last few pages)?

Again, thank you for your help. snafu22q (talk) 06:33, 21 October 2023 (UTC)

┌──────┘
@Snafu22q: Glad I could help! Indeed, {{fvn}} removes the small caps formatting. {{TOC row 2out-1|[[Varied Types/Chapter 16|Ruskin,]] {{sm|{{fvn|(not in original TOC)}}}}|{{spl|217|14}}|class=wst-toc-aux}} expands to

<templatestyles src="TOC templates/styles.css" />
|- class="__toc_row_m-1 __toc_row_2out-1 wst-toc-row-2out-1 wst-toc-aux" 
| colspan=2 |[[Varied Types/Chapter 16|Ruskin,]] {{sm|{{fvn|(not in original TOC)}}}}
|{{spl|217|14}}

and the wst-toc-aux class means that the row has a green background. The transclusion looks good to me. —CalendulaAsteraceae (talk • contribs) 06:59, 21 October 2023 (UTC)

Tech News: 2023-42

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

Recent changes

• The Unified login system's edge login should now be fixed for some browsers (Chrome, Edge, Opera). This means that if you visit a new sister project wiki, you should be logged in automatically without the need to click "Log in" or reload the page. Feedback on whether it's working for you is welcome. [1]
• Edit notices are now available within the MobileFrontend/Minerva skin. This feature was inspired by the gadget on English Wikipedia. See more details in T316178.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 17 October. It will be on non-Wikipedia wikis and some Wikipedias from 18 October. It will be on all wikis from 19 October (calendar).

Future changes

• In 3 weeks, in the Vector 2022 skin, code related to addPortletLink and #p-namespaces that was deprecated one year ago will be removed. If you notice tools that should appear next to the "Discussion" tab are then missing, please tell the gadget's maintainers to see instructions in the Phabricator task.

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

MediaWiki message delivery 23:47, 16 October 2023 (UTC)

Review and comment on the 2024 Wikimedia Foundation Board of Trustees selection rules package

You can find this message translated into additional languages on Meta-wiki.

More languages • Please help translate to your language

Dear all,

Please review and comment on the Wikimedia Foundation Board of Trustees selection rules package from now until 29 October 2023. The selection rules package was based on older versions by the Elections Committee and will be used in the 2024 Board of Trustees selection. Providing your comments now will help them provide a smoother, better Board selection process. More on the Meta-wiki page.

Best,

Katie Chan
Chair of the Elections Committee

01:13, 17 October 2023 (UTC)

Invitation for Wikisource Community Meeting October 2023

Hello fellow Wikisource enthusiasts!

We are the hosting this month’s Wikisource Community meeting on 28 October 2023, 7 AM UTC (check your local time). This meeting time is Eastern Hemisphere-focused and we will alternate the meeting times every month.

The first half of the meeting will be focused on non-technical updates and conversations like events, conferences, proofread-a-thons and collaborations. The second half will be focused on technical updates and conversations, such as talking about major challenges faced by Wikisource communities, similar to the ones conducted in previous Community meetings.

If you are interested in joining the meeting, kindly leave a message on [email protected] and we will add you to the calendar invite.

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

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

Sent using MediaWiki message delivery (talk) 14:11, 18 October 2023 (UTC)

'Stuppai' in Forward! by Harold Lamb

'Stuppai' in this rendition of 'Forward!' looks to be two words ('stup pai') when viewing the October 10, 1924 issue of Adventure Magazine. see page 7 column 1 paragraph 6 -- which shows a space between the p's. And confirmed in column 2, paragraph 5 of the same page. The language is stated to be Russian in the text, but Google Translate says it means 'come on' in Lithuanian. PDFs of the issue can be found at archive.org, luminist.org and elsewhere. That the word is in an italics font may have obscured this. 73.206.16.128 20:59, 18 October 2023 (UTC)

• See Forward (Lamb) and here. Based on the spacing of other italicized phrases, I would have to disagree. TE(æ)A,ea. (talk) 21:23, 18 October 2023 (UTC)

  I see your point, but the space appears obvious--at least to me. Of course, I might be looking for a space to be there.

  The trouble is neither the one, nor two word version seem to have any meaning in Russian. However, the 2 word version does have a meaning in Lithuanian. And, I have since discovered both the one & two word versions have meanings in Ukrainian. 73.206.16.128 07:21, 19 October 2023 (UTC)

Neither "stup pai" or "stuppai" are valid Ukrainian or Russian, since those languages are written in the Cyrillic script. I'm not finding stup in Lithuanian at all. Ukrainian is pretty close to Russian, so it's likely if it has meanings in Ukrainian, it has meanings in at least dialects of Russian. If I had Cyrillic spellings, I might be able to poke at it more, but I find the whole thing mildly pointless; the question is what is written, not whether it is correct.

As for what is written in the Adventure Magazine, I compare it to the splash and sau bul at the top of the page, and the mon prince at the bottom of page 9, and it looks like the kerning and design of the italic p in this font leaves a little more space than would be desired in pp, but it's clearly not supposed to be two words.--Prosfilaes (talk) 17:35, 19 October 2023 (UTC)

I found a few old books saying that Suwarrow (i.e. Suvorov)'s favourite maxim was "Stuppai e Be" meaning "Forward and Strike", no idea what the modern transcription of that would be though. -- Beleg Âlt (talk) 21:18, 19 October 2023 (UTC)

stupajka in Polish is slang for policeman, but also has tsarist overtones. My references do not give an etymology. --EncycloPetey (talk) 02:31, 23 October 2023 (UTC)

I did a bit more digging, and I'm convinced that the word is ступай - with "Forward" being a very loose translation. -- Beleg Âlt (talk) 18:39, 23 October 2023 (UTC)

Popular Science Monthly, The Scientific Monthly, World's Advance...

I've written elsewhere about how the Popular Science Monthly name was acquired in September 1915 and reused for a magazine Wikipedia calls Electrician and Mechanic but was known at the time as World's Advance (Wikipedia cites several other names, apparently it went through five names in two years), while the successor to PSM The Scientific Monthly was launched the following month. Anyway, it seems to me that this leads to a little bit of difficulty for characterising these periodicals; according to the Bulletin of Bibliography January 1916 the World's Advance publisher suggested that the "new" PSM be treated as World's Advance, while the Scientific Monthly publisher suggested that the Scientific Monthly be handled alongside the "old" PSM. I figure the best way to handle this is on our end as follows:

• PSM up to vol 87 issue 3 stays where it is.
• One new page for Electrician and Mechanic/World's Advance and PSM from vol 87 issue 4. (Where is the guideline for periodicals that change name?)
• The Scientific Monthly keeps its own page, but gets added to the PSM project (or else a new project launched for TSM).

Thoughts? Arcorann (talk) 11:22, 19 October 2023 (UTC)

There is no guideline for journals that change name as there is no standard for how the journals did it. The best guidance that we give, is to just publish them per the name of the journal, and the volumes. That way they remain true to how they are published. Then we build a portal namespace page that explains what is where and we heavily utilise redirects allow for getting people to the right place with the name variations. — billinghurst sDrewth 14:34, 5 November 2023 (UTC)

That still leaves the question of how to handle the fact that Popular Science Monthly from vol 87 issue 4 is literally a different periodical (really being World's Advance). Arcorann (talk) 11:42, 6 November 2023 (UTC)

Zuleika Dobson

There are two versions, a 1911 UK version - Index:Zuleika Dobson.djvu and a 1912 US version - Index:Zuleika Dobson; (IA zuleikadobsonbee00beer).pdf. Do we want both ?

@Languageseeker - it seems that you created both. -- Beardo (talk) 16:19, 20 October 2023 (UTC)

I see no reason not to keep both —Beleg Tâl (talk) 16:47, 20 October 2023 (UTC)

Fine - I have linked the other from the author page. -- Beardo (talk) 14:04, 22 October 2023 (UTC)

A couple of Mormon-related documents

We have Address from Jackson County citizens regarding the Mormons - July 20 1833 and Memorandum of agreement between Mormons and Jackson County citizen committee. Both seem to come from "The Western Monitor" of August 2, 1833 which is transcribed here - http://www.sidneyrigdon.com/dbroadhu/MO/Miss1831.htm#080233 which states "Note: No copy of this issue of the Fayette Western Monitor has yet been located for transcription. The text was taken from the LDS History of the Church I, pp. 394-402. See also the Columbia, Missouri Intelligencer, of Aug. 10, 1833 for essentially the same report."

Are we happy to accept what seems to be a third-hand transcription ? Is it OK to have those two parts separate ? -- Beardo (talk) 14:10, 22 October 2023 (UTC)

In my understanding adding works without the original printed source is no longer accepted practice on Wikisource. It was done a lot early on, when people were just grabbing stuff from Project Gutenberg and elsewhere and putting it here. Nowadays one should import a scanned version and work off of that. In order to reproduce the articles, there'd need to be either a scan of the newspapers or a scan of The History of the Church. The latter seems to be the way to go. Arbitan (talk) 05:11, 31 October 2023 (UTC)

Changes to templates of the same name. How are they managed?

I came across an unexpected change to the {{sp}} template. The spacing parameter became a fixed value, whereas I often used it with various spacing parameters, years ago.

I am now using the {{lsp}} template as a replacement for {{sp}} and my question is, what happened to the old templates which included this or other parameters for spacing? Were they edited by a script? — ineuw (talk) 07:30, 23 October 2023 (UTC)

Tech News: 2023-43

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

Recent changes

• There is a new Language and internationalization newsletter, written quarterly. It contains updates on new feature development, improvements in various language-related technical projects, and related support work.
• Source map support has been enabled on all wikis. When you open the debugger in your browser's developer tools, you should be able to see the unminified JavaScript source code. [2]

Changes later this week

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

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

MediaWiki message delivery 23:16, 23 October 2023 (UTC)

Tech News: 2023-44

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

Recent changes

• The Structured Content team, as part of its project of improving UploadWizard on Commons, made some UX improvements to the upload step of choosing own vs not own work (T347590), as well as to the licensing step for own work (T347756).
• The Design Systems team has released version 1.0.0 of Codex, the new design system for Wikimedia. See the full announcement about the release of Codex 1.0.0.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 31 October. It will be on non-Wikipedia wikis and some Wikipedias from 1 November. It will be on all wikis from 2 November (calendar).
• Listings on category pages are sorted on each wiki for that language using a library. For a brief period on 2 November, changes to categories will not be sorted correctly for many languages. This is because the developers are upgrading to a new version of the library. They will then use a script to fix the existing categories. This will take a few hours or a few days depending on how big the wiki is. You can read more. [3][4]
• Starting November 1, the impact module (Special:Impact) will be upgraded by the Growth team. The new impact module shows newcomers more data regarding their impact on the wiki. It was tested by a few wikis during the last few months. [5]

Future changes

• There is a proposed plan for re-enabling the Graph Extension. You can help by reviewing this proposal and sharing what you think about it.
• The WMF is working on making it possible for administrators to edit MediaWiki configuration directly. This is similar to previous work on Special:EditGrowthConfig. A technical RfC is running until November 08, where you can provide feedback.

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

MediaWiki message delivery 23:21, 30 October 2023 (UTC)

Encyclopedias

What is today the best known way to present an old encyclopedia on the web? Wikisource has several examples in Category:Encyclopedias, created at different dates. Are the most recent additions better than those of 5, 10, 15 years ago? Among the earliest is The New Student's Reference Work, which I scanned in 2005, 18 years ago (see talk page for internal history.). If I started that project today, with 18 more years of collective experience, which path should I follow? Are there examples (of web presentations of old encyclopedias) outside of Wikisource that we admire and envy? -- LA2 (talk) 09:38, 1 November 2023 (UTC)

I don't think we have The One True Solution for this. The newer examples should generally be followed because the old ones are 1) made in a world that was very different in terms of tools etc. and 2) before those 18+ years of experience and 3) under different policies and guidelines. For example, the first encyclopedias were made as completely new presentations, but our standards have since shifted towards presenting works true to how they were actually published. In addition, to some degree each encyclopedia will have its own needs and quirks (because it has its own structure and approach as it was published), so I don't think we can mandate One True Way by fiat.

All of which leads to my conclusion that we need to look at the specific encyclopedia and discuss a bit—at least among interested contributors, but maybe also broader in the community—how best to solve it. If it's a one or two volume work it's probably easier (just treat it like any other book), but if it's something on the order of EB1911 it's going to be much more complicated to find some way to balance all the different concerns. Xover (talk) 11:45, 1 November 2023 (UTC)

I'm intending next to scan Swedish encyclopedias from the 1950s. They are borderline copyright cases, meaning that I can get away with it, but can't grant a free license. Since these can't be hosted in Wikimedia Commons/Wikisource, I'll continue to use Project Runeberg as my base. So you don't need to limit your suggestions to what is currently possible in Wikisource and its ProofreadPage module.

The history is this: In 1992, I started Project Runeberg inspired by Project Gutenberg, just putting e-text online. In 1995, Project Gutenberg released volume I of EB11, and I thought that digitizing encyclopedias might be a nice idea, but it's a lot of work and the e-text routine (proofread first, then publish) was very slow. In 1998, I started to put facsimile scans + raw OCR text online, publishing first and proofreading later. In 2001, Wikipedia started and I started to scan an old Swedish encyclopedia, Nordisk familjebok. This was finished (scan + OCR) in 2003. In 2005, German Wikipedians wanted something similar for German books, and I suggested to use Wikisource for publishing scans + raw OCR instead of just e-text. The aforementioned The New Student's Reference Work was scanned by me as a proof of this concept. Originally, it used its own templates and categories. The ProofreadPage module was designed some years later.

Most likely, I will continue to use my existing method for scanning and presenting encyclopedias. But if radically new ideas are available, I will pick up what I can. --LA2 (talk) 12:26, 1 November 2023 (UTC)

 Comment I have probably done the most contribs and organisation and tidying to align collective works and the templates we have settled upon. For these sorts of works, we should be presenting each article independently and it should have wikidata that allows it to be referenced and linked to a main subject, volume, pp, contributor, language all captured data (think about how you can best scrape data and botify it into WD). Noting that the volumes of the work are not pertinent to the hierarchy, and just can be added to the header as detail. Contributors should be noted and we now use the contributor field which puts aligns with the section field. How to label articles and disambiguate is always a challenge and needs the early consideration, from there I use section labels that align with the article name to make transclusion easier and sensible when you have to pull multiple articles off a page (use of s1, s2, s3, ... names is ugh!) DjVu is still the best form, especially when these pages have columns. Look at how you want to internally link a work where it has internal references, and not overlink the rest of the work, let it be fairly self-contained. Set up your link templates early, and replicate what we already have in place with .../link / ... lkpl templates. Leverage Template:Collective work header to build the header for the work. Setting up a WikiProject is useful to bring together the editing information. There are many learnings and commentary.

Keep it as simple as possible, and remember that this is about reproduction not replication, so leverage existing templates, and don't try to drill into highly specific and quirky templates that don't align with the community's existing editing style, it just makes tidying impossible. — billinghurst sDrewth

If you want a permanent URL for each article, which is useful for Wikidata, the current design of the Page: namespace and the ProofreadPage extension forces us to create a page (a subpage like The New Student's Reference Work/Steam-Whistle) for each article, that contains a <pages index=... fromsection=... tosection=...>, that pulls the text from one or more proofread pages. It would be a lot easier if just adding the mark-up during proofreading could fix this automatically. --LA2 (talk) 23:52, 5 November 2023 (UTC)

Trying to help myself by asking for yes or no answers.

1. I am looking for the bot with which I can create the page: namespace pages. I looked at the list of users': bots, but I can't tell. Are there any general maintenance bots? I cannot do this manually, and my mouse+keyboard based macros no longer work in browsers. Is there such a script? Yes or No?
2. When Tesseract finishes, would it be possible to terminate the cursor position in the top row of the 'text area'? - Can I, manage this from my .js file? Yes or No?
3. Would it be also possible that at the termination of same process, to reset the image to the 'original size'? Yes or No? — ineuw (talk) 00:56, 5 November 2023 (UTC)

Tech News: 2023-45

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

Recent changes

• In the Vector 2022 skin, the default font-size of a number of navigational elements (tagline, tools menu, navigational links, and more) has been increased slightly to match the font size used in page content. [6]

Problems

• Last week, there was a problem displaying some recent edits on a few wikis, for 1-6 hours. The edits were saved but not immediately shown. This was due to a database problem. [7]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 7 November. It will be on non-Wikipedia wikis and some Wikipedias from 8 November. It will be on all wikis from 9 November (calendar).
• The Growth team will reassign newcomers from former mentors to the currently active mentors. They have also changed the notification language to be more user-friendly. [8][9]

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

MediaWiki message delivery 21:05, 6 November 2023 (UTC)