Wikisource:Scriptorium

Scriptorium

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

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

Pride and Prejudice

Can Pride and Prejudice be moved to Pride and Prejudice (Third Edition) to make way for a versions page? Languageseeker (talk) 02:33, 18 March 2023 (UTC)

A Room with a View

The DjVu file on Commons (File:A Room with a View.djvu) was deleted without first uploading it here. Can someone acquire the file and upload it locally? --EncycloPetey (talk) 23:15, 21 March 2023 (UTC)

@EncycloPetey it was uploaded here, see File:A_Room_With_a_View.djvu Mpaa (talk) 18:26, 22 March 2023 (UTC)

It needs to be under exactly the same name as the original, or it won't be transcluded. Right now, the entire book is broken. --EncycloPetey (talk) 19:01, 22 March 2023 (UTC)

Don't shoot the messenger :-) Mpaa (talk) 20:40, 22 March 2023 (UTC)

Done. Mpaa (talk) 20:48, 22 March 2023 (UTC)

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), Saturday 15:21, 25 March 2023 (UTC)

Duplicate book

Hi, Index:The Ramayana Of Tulsidas.djvu is a duplicate and inferior quality of Index:The Rámáyana of Tulsi Dás.djvu. The index is also in the old WS ([1]), but it is mosty in English. What to do in this case? Thanks, Yann (talk) 17:18, 5 February 2023 (UTC)

Do we need both djvu files to proofread here? Should proofreading be done here or on old WS? Ascertaining which djvu and where to proofread is the key to answer your question.--Jusjih (talk) 20:40, 5 February 2023 (UTC)

 Comment If they are the same edition, then two versions are redundant, and the transcriptions can be merged, and one of the files nominated for deletion at Commons. It takes a little more coordination if there are transcriptions on two wikisources, though I would think that isn't a barrier. If they are different editions, then that should become a discussion at WS:PD which is where those conversations are pertinent. Where we have a preferred edition, then just put a note on the index page directing them to the other. — billinghurst sDrewth 21:43, 5 February 2023 (UTC)

AFAICT, there are the same edition. This book is mostly in English, with a few pages in Hindi, so it should be done here. Yann (talk) 22:23, 5 February 2023 (UTC)

Hello, thanks for the note on my talk page. I am not familiar with the technical details on how one would go about doing a merger; if there is a better quality scan available, I have no objection to anyone going ahead on that. Since the book is mostly in English, I agree this is the right project for it. regards, TryKid (talk) 11:57, 6 February 2023 (UTC)

 Comment@Mpaa: are you able to script move these? They are not /1 to /1 as the early scanned pages are different, so we are going to need to offset to get the content to content to align. Thanks. — billinghurst sDrewth 00:18, 28 February 2023 (UTC)

@Billinghurst: done. I had to fix the djvu as pages were missing, cannot crosscheck due to caching. Mpaa (talk) 23:31, 28 February 2023 (UTC)

Is there a bot or script to harmonise the names on Wikisource from WCommons?

Hello.

There is apparently a problem for the "Page:" pages when the name of the file on WCommons and the one on Wiksource do not match. This problem consists in the left and right arrows not being displayed. It also prevent synchronisation with transcluded text. So, is there a bot or script which could be used to have the Wikisource item being moved along with all its pages, and the transclusions, to the current name the WCommons file has? Veverve (talk) 11:00, 19 February 2023 (UTC)

@Veverve: The requirement here is to simply create the Index: and Page: namespace pages to match the File: ns page at Commons. The requirement at Commons is that when the file is used at Wikisource to not move it.

Rather than talk generalities, please identify the problem index: and file: names and one of us with suitable rights here and at Commons will fix it up. — billinghurst sDrewth 21:11, 21 February 2023 (UTC)

FYI, Veverve was blocked on French Wikisource and Commons for disruptive editing. Yann (talk) 19:05, 22 February 2023 (UTC)

I have indeed been blocked on WCommons (by you). However, my block on French Wikisource was unjustified and was lifted after 10 days by the administration. I am not sure what this had to do with anything, but whatever. Veverve (talk) 21:38, 22 February 2023 (UTC)

@Veverve: you haven't responded to my query above, so did we resolve your issue? I will note that there is a delicate interaction between Commons files, and our Index:/Page: pages, and do suggest cautious approach and eyes wide open when things need to be moved/amended. With regard to the personal commentary, it is a little unfortunate, as we do try to assume good faith and act according to what happens locally, though naturally we do keep an awareness of problem editing elsewhere. — billinghurst sDrewth 22:29, 19 March 2023 (UTC)

@Billinghurst: I have solved the issue I had on Wikisourcefr with a WCommons file I had moved. To fix it, I simply made an automation process on my computer, to move all the Wikisource 'Page:' pages to the new name of the WCommons file. Veverve (talk) 22:46, 19 March 2023 (UTC)

@Veverve: Okay, though here we would typically move the Commons file back to where it was, unless there was a true need to have the Commons file elsewhere. There is a specific exclusion for file renames at Commons for files in use like this. It can become very messy for any work advanced in transcription and transclusion. AND AND AND the filename at Commons is never particularly a killer issue. — billinghurst sDrewth 00:17, 20 March 2023 (UTC)

Code review for RunningHeader templates

I've been working on a Lua module, Module:RunningHeader, to implement the various templates based on {{RunningHeader}}, and I'd appreciate some additional sets of eyes on the code before I go full steam ahead with the migration. Notes:

• I've added support to {{RunningHeader}} for choosing how many cells there are. No need to make separate templates like {{Rh/5}}! The default behavior is still 4 cells if there's a 4th parameter and 3 otherwise.
• Roman numeral handling is more robust, and I've moved it into the core recto-verso functionality. This allows merging {{Recto-verso header}} and {{Recto-verso header2}}.
• Test pages:
  • Template:RunningHeader/testcases
  • Template:Recto-verso header/testcases
• Updated stylesheet, which combines the existing stylesheets into one: Template:RunningHeader/styles-sandbox.css

—CalendulaAsteraceae (talk • contribs) 04:07, 21 February 2023 (UTC)

See also WS:AN#Edit requests for Template:RunningHeader. —CalendulaAsteraceae (talk • contribs) 03:56, 27 February 2023 (UTC)

History of Costume

https://archive.org/details/ost-history-historyofcostume00khle

I'd like some more information on the author lifetimes, before adding it to the list of requested works which expire in a few years time. Anyone got more information? ShakespeareFan00 (talk) 09:36, 22 February 2023 (UTC)

@ShakespeareFan00 Carl Köhler has a Wikidata item. I haven't been able to find anything on Emma von Sichart. Alexander K. Dallas has a Wikidata item but not a death date. —CalendulaAsteraceae (talk • contribs) 05:12, 23 February 2023 (UTC)

Emma von Sichart seems to be described here: Google Books as living from 1879-12-08 to 1954-02-03. I suspect that was Rev. Alexander Kennedy Dallas, a German master at George Watson's College and died in April 1932 http://www.ecclegen.com/ministers-d/#DALLAS,%20ALEXANDER%20KENNEDY. MarkLSteadman (talk) 21:11, 19 March 2023 (UTC)

So another 2 years at least.ShakespeareFan00 (talk) 21:18, 19 March 2023 (UTC)

Although that identification is tentative, the birth date seems to be the right time frame and she is described as a writer, anyways Emma was described as an artist and lived in first Würzburg (1904) and then Munich, she also apparently translated Jesse Fothergill into German in 1903, wrote in the Volkische Beobachter in the late '20s and is listed as being active until 1942 in the DNB. MarkLSteadman (talk) 22:08, 19 March 2023 (UTC)

Invitation for February 2023 Wikisource Community Meeting

Hello fellow Wikisource enthusiasts!

We are the hosting this month's Wikisource Community meeting on 26th February 2023 at 11 AM UTC (check your local time) according to the wudele poll.

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 sgill@wikimedia.org 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)

Open\Close header script in Preferences\Edit?

In Preferences\Edit, there used to be an option which on opening of a page in edit mode, it opened the header/footer, if they were closed. Is this script still available for use in my vector.js? — ineuw (talk) 07:23, 23 February 2023 (UTC)

@IneuwI don't think that particular feature has gone away. The preference is definitely still availiable if you don't use the 2010 WikiEditor editing interface. (If you do use the WikiEditor interface, there should be a icon in the Proofreading tools section that should do the same thing). Sohom Datta (talk) 02:45, 5 March 2023 (UTC)

Thanks for the info. Unfortunately, I am using the 2010 interface, but will re-try the other skins. It's interesting, because the manual control group of closing and opening the header, and selecting the edit options of over/under or side by side editing still exists. So I thought it can add it the my vector.js — ineuw (talk) 20:02, 6 March 2023 (UTC)

Jo Pugh, RIP

I'm sorry to report that my friend, and an incredible Wikimedian, Jo Pugh, User:Mr impossible has died ([2]). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:07, 23 February 2023 (UTC)

My deepest condolences, Andy. We have lost some great ones of late. BD2412 T 21:02, 23 February 2023 (UTC)

Curation of external links to scans and media

In order to try and identify 'incompatible' scans on external links I created Category:Pages linking to external media needing verification of source copyright status, However I need some help of experienced reviews on Wikisource to slowly move items here into the other categories the {{copychecked}} uses.

It would be appreciated if other contributors could carefully review the links on the pages in this category adding, verified=yes to the relevant link template usage if the scans at the external link can be uploaded to commons.

The vast majority of the media/scans linked are without issue, but by adding the tracking categories allows the 'good' items to be removed when looking for problematic ones...

The other values for verified are as follows: no - The linked scan/media is still potentially subject to copyright protections. (such as being published after 1927, or by a living author) and there is no compatible license evident. ( such as CC-BY-SA, PD-US-Gov, PD-US-no notice).

localok - The linked scan/media is PD in the US but not necessarily globally.

islocal -The linked scan/media is already uploaded locally, and the link is on the relevant File: page.

pdscan - The linked scan is of a work that would be PD globally, but is subject to a licensing or ToU clause (typically the work is PD but the scan is under an NC style license.)

I plan on adding some logic to {{copychecked}} to add question mark/tick box icons if anyone has suitable ones in mind. Currently the template only adds hidden tracking categories.

This should be a one time curation effort in terms of mass-efforts, as in the future the tracking categories could be put on watchlists so a curation backlog doesn't build up over time, as it has previously. ShakespeareFan00 (talk) 00:24, 25 February 2023 (UTC)

Abandoned, due to concerns expressed ShakespeareFan00 (talk) 10:17, 25 February 2023 (UTC)

When there is no ToC

Hi, What to do when there is no table of content? In Index:Fischer - A Week with Gandhi.pdf, 136 pages in one single work seem to be quite a lot. Should I create a ToC? Yann (talk) 19:18, 26 February 2023 (UTC)

Finally, I made a ToC here, as there is a clear subdivision of chapters. But the general question remains. Yann (talk) 21:07, 26 February 2023 (UTC)

Hi. We use the {{Auxiliary Table of Contents}} template in such cases. --Jan Kameníček (talk) 23:54, 26 February 2023 (UTC)

Undeleting 1911 Encyclopædia Britannica/Sin (God)

1911 Encyclopædia Britannica/Sin (God) page was created by me, then probably renamed while leaving a redirect behind. The putative redirect was deleted in 2019. The problem with that deletion is that it is no longer clear to which page the redirect was targeted. Ideally, the redirect ought to be restored together with its talk page. The database storage will not be saved anyway (deleted pages remain in the database), and the readers, especially me, will have the traceable evidence of history of the pages, that is, what text there was on the page and to which page it was redirected. I contributed many pages on philosophy to the 1911EB project, and restoring the redirect would be a minor courtesy toward a contributor of substantial content, that is myself. I will be grateful for a restoration. I will try to respond to any inquiries unless I get lost in my other wiki activities. Thank you. Dan Polansky (talk) 05:59, 27 February 2023 (UTC)

@Dan Polansky: Undeletion requests are best made at Wikisource:Proposed deletions. Not that it can't be discussed here too, but it's best to use the established process. For reference, the above page was first moved to 1911 Encyclopædia Britannica/Sin (Moon-god), and then to 1911 Encyclopædia Britannica/Sin (moon-god) where it now lives. The reason for the moves was alignment with our page naming standard for the EB1911, and the reason for deleting the redirects was presumably our established practice of avoiding sub-page redirects (just guessing based on the logs). Xover (talk) 06:54, 27 February 2023 (UTC)

Thank you. Can you please direct me to that "page naming standard for the EB1911" from which it follows that the disambiguator should be "moon-god" rather than "god"? And is the choice of "moon-god" based on that term's use in the first sentence in 1911 Encyclopædia Britannica/Sin (moon-god)?

Furthermore, can you please point me to evidence that there is an established practice of avoiding subpage redirects? Since, these seem to be potentially very useful, as much as non-subpage redirects.

Thank you for any information requested above that helps establish traceability. --Dan Polansky (talk) 07:14, 27 February 2023 (UTC)

@Dan Polansky: For the naming, the most apposite links would seem to be Wikisource:Style guide#Page titles and Wikisource:WikiProject 1911 Encyclopædia Britannica/Style Manual#Entry titles. But we're not all that great on expressing community practice in the form of actual written policy so I'm not sure I'm able to accommodate the essence of your request very well. Xover (talk) 08:27, 27 February 2023 (UTC)

All right, then. I created a redirect from 1911 Encyclopædia Britannica/Sin (moon-god) for convenience. Since no argument against these kinds of redirects has been presented or linked to, nor has a reference to a collective editor decision on the matter been given, I consider the utility of the redirect trump various subjective whims or preferences not traceable to anything like a discussion or a vote showing strength-of-the-argument-augmented consensus process. --Dan Polansky (talk) 09:04, 27 February 2023 (UTC)

I understand your thinking, but it's rather pointless: eventually someone will run across it and delete it again. It is annoying that we're not better at documenting things in written policies, but that's a separate issue. The bottom line is that it's established practice that we do not use subpage redirects like this. Xover (talk) 15:19, 27 February 2023 (UTC)

As for the phrase "apposite links", Google finds low number of hits and I have only a vague idea of what it is supposed to mean; can someone please translate this into a clear, simple, unambiguous and in general reader-friendly English? --Dan Polansky (talk) 09:04, 27 February 2023 (UTC)

 Comment @Dan Polansky: Redirects at subpage level have been found to be problematic, so the general process is to not have them. When we are moving works at the root level, especially when disambiguating works, the presence of a string of redirects as subpages is a right devil. The clear and easy solution that is everpresent for subpages is that the subpages are all listed on the rootpage of each work, and they should be listed on the preceding and succeeding pages, so are readily findable. Also, as we encourage encyclopaedic articles to have their corresponding wikidata items, these contain and maintain the links, hence making the requirements for redirects essentially redundant where people appropriately use the WD as the base for links. — billinghurst sDrewth 22:34, 27 February 2023 (UTC)

And please do not recreate deleted redirects. There had been {{dated soft redirect}} in place so links had been checked and fixed. — billinghurst sDrewth 22:37, 27 February 2023 (UTC)

And to give some feedback about the original contribution. You created the article in 2010 as a free text contribution, and it was similarly created from a scan-backed page in 2011. A soft redirect was created in and place for a period of time prior to being checked for links and removed. The article's item is Sin (Q84653266) and can be referenced from enWP with {{cite Q|Q84653266}} with all its mobility. — billinghurst sDrewth 22:51, 27 February 2023 (UTC)

Added some text to Help:Redirects about when not to do redirects, focusing on not doing subpage to subpage. We give suggestions about where we do redirects, though as usual in positive guidance, we talk about where and what we do do, rather than focus on the negative of what one shouldn't do. Plus every time we are pushed to blackletter style guide we always seem to get the declaration, that we don't say that you shouldn't do such and such. — billinghurst sDrewth 02:55, 28 February 2023 (UTC)

As for "it's established practice": citation missing. Where is the debate or the vote? That rule still makes no sense to me.

As for "Redirects at subpage level have been found to be problematic": this statement is too general and vague and comes with no substantiation.

In any case, a policy or guideline page ought to be created where subpage redirects are discoraged, and a proper rationale is provided. Anything else turns the project into a playground for elders rather than a broad-editor-base governed wiki project.

This thread has been a disappointment. --Dan Polansky (talk) 05:24, 28 February 2023 (UTC)

As for the part of the user signature reading "sDrewth", what is that supposed to mean and why does it point to a talk page? Is the real user name "Billing Hurst"? If so, would not a rename of the user name be in order? These were some usability asides. --Dan Polansky (talk) 05:26, 28 February 2023 (UTC)

Established practice does not necessarily come from a debate nor a vote, it also comes from our experiences and our resolution There is commentary in the archives of these pages and other places about the problems. We are a wiki with subpages in the main namespace, which is different from most wikis, and there are clear problems we have found with having subpage to subpage redirects. Also do not take that in isolation the other commentary around subpages with rootpage, and that they are different from rootpages which will be your experience at most wikis. Our approach for subpages and root pages is different, we typically have all the root pages with redirects. You can either take the word of experienced administrators or not, expecting me to run around doing a song and dance is not going to happen.

I don't need to explain my signature nor my username, the links are appropriate and unambiguous, that is actually quite a rude approach and not one I find becoming of an experienced user like yourself. And I don't think that a former steward and an editor of over a million edits should truly be applying for a rename, nor even need to consider one. I mean really, where do you get off? — billinghurst sDrewth 06:30, 28 February 2023 (UTC)

Standardizing links to scanned works on external sites...

On Author and Portal pages there are a number of external links to sites like archive.org , HathiTrust and Google Books, for which linking templates such as {{IA}} , {{IAl}} & {{IA small link}}; {{HTl}} & {{HTlink}}; and {{GBS}} respectively.

In places these links are raw http:// style links. It would be desirable to attempt standardization/conversion of these if possible, using the linking templates to permit tracking of site specific links, and potentially easier maintenance if the URL structures of these external sites changes.

Generic templates like {{ext scan link}} also exist, and it would also be desirable for this template to also support having (site specific?) tracking , or ways to better support the generation of semi automated reports and lists of 'compatible' scans for upload.

Whilst it is possible to use an insource: style search to find raw links, a regexp on a given URL pattern, is not necessarily reliable in excluding links which are included as template parameters. A Negative look-behind (?<[^=|]) (for an = or | preceding the link in a regexp seems to be one possible way of working around this, but I wasn't sure if that was supported by the search tools used locally or by AWB.

I will also note that {{scans available}} also potentially needs a redesign so that it can be used as a 'staged' template, giving different advice and guidance to contributor at each stage of the process of migrating works to scan backed versions. I recently added some additional functions to handle IA style links to it. However, it would also be nice to have that for links to Google Books, Hathi Trust, and other sites with standardized link formats. Both of these redesign points would suggest that migration to some kind of module to support them is desirable.

What are the views of other contributors? ShakespeareFan00 (talk) 08:42, 27 February 2023 (UTC)

BTW - insource:/[^|=]https:\/\/archive.org/ gave around 940 entries, which would be a couple of days effort, once a standard template to convert these to is decided. ShakespeareFan00 (talk) 09:12, 27 February 2023 (UTC)

I don't see the point of the change. Why would we want to track these? Why would we want to search these? The application of the template is specifically related to the point and place of the link. The added links are of their time and place and the person adding them; they do not indicate the best available scan at the later time of grabbing a work. They have only ever been indicators of something at the target, nothing more, nothing less. To go through and make these changes puts us in no better position at the end of the day.

When I am thinking of large scale changes, I always stand back and think "at the end of all these tasks, does this achieve something in the bigger picture of making the site better, easier, etc." And I don't see that with this proposal. — billinghurst sDrewth 22:14, 27 February 2023 (UTC)

Thank you for your input, so I am starting to wonder if my conversions were thus in the wrong direction...

In terms of templated links, do you consider it desirable to have one standard way of linking to external scans?

Thoughts on having one ext scan link template with identifier support

On something related to the actual templates for linking...

If we ignore any tracking categories, How easy would it be for ext scan link to be updated to treat it's inputs as a series of identifiers for a specific site, with a site or siteN paramaters, telling it to generate a link from a set of known patterns? The thinking is that you could then specify as URL directly as at present, or as identifiers only, which have pre-defined patterns. What's actually displayed would be "external scan" or what ever displayN title was specfied. The additional function I added in {{IAl}} are to some extent what {{ext scan link}}'s displayN does, and there's {{ext scan link}} can handle multiple volumes better. Doing this would also mean that {{IA small links}} and {{ext scan link}} could effectively be merged! (The thinking here is the patterns for external links and modes would be in a /Data page, not unlike a sort of interwiki map but for scanned documents rather than other wikis.). Adding a new site, would only mean adding a new set of patterns to the /Data rather needing to implement an entirely new template for each new site (allowing sites British Libray, Biodiversity Heratige Library, NLS to be added) with the added gain of being able to handle multiple volume works.

An example link in /Data would look something like...

{IA, 'https://archive.org/details/$1', 'IA', '/page/$1'},

The first is a shortID followed by the link format, text to suffix to a 'Via' indication text, and the format to apply if a deep link to a specfic page is given. If tracking is needed, then an additional tracking category could also be in the Data?

ShakespeareFan00 (talk) 23:07, 27 February 2023 (UTC)

The edits were unneeded at the time, though once they are done, there is also little value in undoing them. It is all noise. Reverting/undoing something also has to have a value proposition.

In terms of a standard way? Meh! While somethings are nice, for something like an external link on an author page, sometimes I am just wishing to drop it, format it and move on with minimal effort. Others may have their preference, and in the end it doesn't matter. The target and looking neat on the page is the purpose, not the mechanics to create a link. So we can play with our style on the templates, and let the users make their choice. Plus why do you think that we need to update those links? What is that doing? They are all point in time things and not essentially unique. All these links are a convenience, and a flag, not much else. When any of us come to upload a work, we should always go and check the quality of the work to upload, do we want that edition, are its pages complete, is it a quality scan, etc. Don't overthink this. — billinghurst sDrewth 00:07, 28 February 2023 (UTC)

Criminal Code Act 1995 (Cth.) cleanup required

I'm recently starting to deal with the Australian Criminal Code Act 1995 (Cth.), but the page of Criminal Code Act 1995 (Australia) is preoccupied with a later version of the text, and it seems to be difficult to properly transcribe my works once everything's completed. Can someone help to move the pre-existing pages to a suitable name, so that the original paper-backed version can be transcribed? Many thanks.廣九直通車 (talk) 11:28, 27 February 2023 (UTC)

Done @廣九直通車: I have moved the pages and left a redirect in at the root level. I will note that at this stage we would say that the root name would be a {{versions}} page and point to the respective versions of the work (see Help:Versions for more info). I would suggest that your title is going to need to need to find a way to uniquely identify the version that you are transcribing. — billinghurst sDrewth 21:52, 27 February 2023 (UTC)

The legislation gov.uk approach (albiet in respect of revised UK legislation) is to have a subpages for the revised versions. This is done by appending /yyyy-mm-dd after the title to indicate a specific revision. Ideally specific revised versions should be back by an authoratative source for the version at the date concerned. It would also be worthwhile coming up with something to put in the header to indcate a "point in time" transcription. as opposed to an "as enacated" one ShakespeareFan00 (talk) 08:53, 1 March 2023 (UTC)

Your wiki will be in read only soon

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

The Wikimedia Foundation tests the switch between its first and secondary data centers. This will make sure that Wikipedia and the other Wikimedia wikis can stay online even after a disaster. To make sure everything is working, the Wikimedia Technology department needs to do a planned test. This test will show if they can reliably switch from one data centre to the other. It requires many teams to prepare for the test and to be available to fix any unexpected problems.

All traffic will switch on 1 March. The test will start at 14:00 UTC.

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

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

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

Other effects:

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

This project may be postponed if necessary. You can read the schedule at wikitech.wikimedia.org. Any changes will be announced in the schedule. There will be more notifications about this. A banner will be displayed on all wikis 30 minutes before this operation happens. Please share this information with your community.

Trizek (WMF) (Discussion) 21:21, 27 February 2023 (UTC)

Tech News: 2023-09

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

Problems

• Last week, in some areas of the world, there were problems with loading pages for 20 minutes and saving edits for 55 minutes. These issues were caused by a problem with our caching servers due to unforseen events during a routine maintenance task. [3][4]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 28 February. It will be on non-Wikipedia wikis and some Wikipedias from 1 March. It will be on all wikis from 2 March (calendar).
• All wikis will be read-only for a few minutes on March 1. This is planned for 14:00 UTC. [5]

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, 27 February 2023 (UTC)

Single adverts...

File:March_1923_Victor_Records_list-complete.jpg in scope or not? Thought I would ask first. ShakespeareFan00 (talk) 19:37, 2 March 2023 (UTC)

Not in itself. But, in the context of the full page from the Boston Globe, it is—once that issue of the paper is scanned and uploaded. Beeswaxcandle (talk) 19:53, 2 March 2023 (UTC)

Thanks. I won't waste time on it then. ShakespeareFan00 (talk) 19:55, 2 March 2023 (UTC)

Broken template transclusion

On Author:William Buckland, the instance of {{PT link}} is broken. I can't figure out why. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:52, 3 March 2023 (UTC)

I experimented by editing it and previewing my changes repeatedly - it seems like the link parameter is too long. When the generated link gets longer than 256 characters, it breaks. Since it starts with "Philosophical Transactions/Volume 112/", the "link" parameter here can be no longer than 218 characters. — Dcsohl (talk)
(contribs) 22:42, 3 March 2023 (UTC)

That's a (hard) limit on the length of page names in MediaWiki, and that's one reason why we don't tend to slavishly reproduce the entire title of original works in the page name. In this case I would have shortened that to Philosophical Transactions/Volume 112/Account of an Assemblage of Fossil Teeth and Bones (including disambiguating the page names if needed). Inside page content we'd use the full text as it appears, of course, but the page name is more of a technical identifier or address. Xover (talk) 08:29, 4 March 2023 (UTC)

Tech News: 2023-10

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 Community Wishlist Survey 2023 edition has been concluded. Community Tech has published the results of the survey and will provide an update on what is next in April 2023.
• On wikis which use LanguageConverter to handle multiple writing systems, articles which used custom conversion rules in the wikitext (primarily on Chinese Wikipedia) would have these rules applied inconsistently in the table of contents, especially in the Vector 2022 skin. This has now been fixed. [6]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 7 March. It will be on non-Wikipedia wikis and some Wikipedias from 8 March. It will be on all wikis from 9 March (calendar).
• A search system has been added to the Preferences screen. This will let you find different options more easily. Making it work on mobile devices will happen soon. [7]

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

MediaWiki message delivery 23:49, 6 March 2023 (UTC)

Creeping trend to have articles set as root pages within the header fields

It seems that we are seeing subpages set as rootpages using title and author rather than section and contributor of {{header}}. I know that I was guilty of that years ago, though thinking that we need to come back to our preferred methodology rather than being all over the place as we are tending to do so. — billinghurst sDrewth 01:04, 7 March 2023 (UTC)

 Support —CalendulaAsteraceae (talk • contribs) 08:12, 8 March 2023 (UTC)

 Support agreed 100%. —Beleg Tâl (talk) 14:44, 15 March 2023 (UTC)

Wikisource:Index librorum prohibitorum

Hi, I created this based on the Wikipedia list. The idea is to be able to see which works on this list are on WS, and which aren't. I see that some notable works are missing here. WP uses templates which don't exist here. Any idea? Thanks, Yann (talk) 22:09, 8 March 2023 (UTC)

@Yann Interesting stuff! I've substituted for the missing templates in question. —CalendulaAsteraceae (talk • contribs) 03:41, 9 March 2023 (UTC)

PS we also have relevant works The Roman Index of Forbidden Books (with a partial list in English) and An Index of Prohibited Books (with a complete? list in Latin), which would be good to incorporate in this project. —Beleg Tâl (talk) 14:52, 15 March 2023 (UTC)

PPS should this not be in Portal space? —Beleg Tâl (talk) 15:28, 15 March 2023 (UTC)

Why not. I don’t know what is WS policy about this, and if it should be a portal for several such documents. Portal:Censorship? Yann (talk) 16:34, 15 March 2023 (UTC)

We do already have Portal:Banned books for the general concept —Beleg Tâl (talk) 15:25, 16 March 2023 (UTC)

Ah yes, but Censorship is a wider scope than Banned books. It includes magazines, journals, pamphlets, etc. Yann (talk) 17:22, 16 March 2023 (UTC)

Presumably there is a published list. It would need to be backed by a scan and set up at LAtin Wikisource, after which we could create a local translation. But in the meantime, the Catholic Church's list might warrant a Portal of its own. --EncycloPetey (talk) 00:09, 16 March 2023 (UTC)

In a couple of years, this edition in English will be PD in the US. However, I do not believe there exists any published edition, in Latin or otherwise, that lists all works that were ever prohibited. Each edition of the Index added some works and removed some works. So a portal would still be valuable. —Beleg Tâl (talk) 15:54, 16 March 2023 (UTC)

No page about partnerships?

Hi,

Is there no documentation page listing all collaboration partnerships with the English Wikisource ? (I only found Category:WikiProjects but it seems it mixes internal and external projects... and there is no quick overview of what has been done when). I was expecting something like fr:Wikisource:Partenariats or it:Wikisource:Collaborazioni?

Did I miss it? and if so, is someone willing to create it?

Cheers, VIGNERON en résidence (talk) 14:39, 13 March 2023 (UTC)

sorry, we are poor at documentation; no, you did not miss it. Some of this is historical: while French had an early collaboration with the French national library, English was following Project Gutenberg, and providing sources for PD text dumps in English wikipedia. w:Wikisource#History Our Library of Congress developed their own in house transcription site. We could try to promote partnerships, but institutional interest has been low. what activity there is gets reported in the GLAM newsletter. There is video activity of WSUG on meta, but documentation is a challenge. --Slowking4 ‽ digitaleffie's ghost 21:59, 18 March 2023 (UTC)

Wikimania 2023 Welcoming Program Submissions

Do you want to host an in-person or virtual session at Wikimania 2023? Maybe a hands-on workshop, a lively discussion, a fun performance, a catchy poster, or a memorable lightning talk? Submissions are open until March 28. The event will have dedicated hybrid blocks, so virtual submissions and pre-recorded content are also welcome. If you have any questions, please join us at an upcoming conversation on March 12 or 19, or reach out by email at wikimania@wikimedia.org or on Telegram. More information on-wiki.

Validated content promotion

Hi, On French Wikisource Main Page, there is a section for validated works (down at right). This encourages contributors to validate content. Any idea how to do that here? Yann (talk) 21:04, 13 March 2023 (UTC)

They are using that to give special attention to New works that have gone straight to validation before being listing as new. Most editors here aim for simple proofreading; it's rare that anything but the shortest works get validated before being listed. --EncycloPetey (talk) 00:14, 16 March 2023 (UTC)

while we have matched the French in proofread rate, we lag behind in validation. we also have more non-scan backed pages, given the influence of gutenberg. maybe we need to offer some prizes to encourage validation. it is a section in the Monthly Challenge. but i don’t think rearranging the main page real estate will make a difference. --Slowking4 ‽ digitaleffie's ghost 21:17, 17 March 2023 (UTC)

We used to dedicate 1 of the 12 proofread months of the year to validating works. We also used to roll works in need of validation in after we completed the primary proofread work. [Both those mechanics are still there.] We changed our processes as people preferred a different approach. In short frWP does things differently to us, and why do we think that we need to replicate their approach? I would much prefer that there is a conversation about validating works and why that needs further effort than an idea that we need to mirror someone else's approach. All of our works that are proofread and in need of validation are at Category:Index Proofread.

Also, it is wrong analysis to say that our non-scanned works is due to Gutenberg, while that may have been the case 10-15 years ago, it is not the truth today. There are simply some contributors who just add texts without scans, and nobody harasses them sufficiently to get a change of practice. — billinghurst sDrewth 12:20, 19 March 2023 (UTC)

Sure, we don't need to copy frWS, but don't you think that the large amount of works waiting to be validated is an issue? We could do a portal where validated works are displayed. Yann (talk) 20:17, 19 March 2023 (UTC)

if you validated 100 pages per day, you would be keeping up with the French. --Slowking4 ‽ digitaleffie's ghost 13:45, 22 March 2023 (UTC)

@Slowking4: Do you mean "we" as a project? That seems perfectly doable. Yann (talk) 15:39, 22 March 2023 (UTC)

Tech News: 2023-11

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

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 14 March. It will be on non-Wikipedia wikis and some Wikipedias from 15 March. It will be on all wikis from 16 March (calendar).
• Starting on Wednesday, a new set of Wikipedias will get "Add a link" (Chavacano de Zamboanga Wikipedia, Min Dong Chinese Wikipedia, Chechen Wikipedia, Cebuano Wikipedia, Chamorro Wikipedia, Cherokee Wikipedia, Cheyenne Wikipedia, Central Kurdish Wikipedia, Corsican Wikipedia, Kashubian Wikipedia, Church Slavic Wikipedia, Chuvash Wikipedia, Welsh Wikipedia, Italian Wikipedia). This is part of the progressive deployment of this tool to more Wikipedias. The communities can configure how this feature works locally. [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 23:20, 13 March 2023 (UTC)

Math error

Hi, does anyone know how to fix Page:Epjconf mmUniverse2021 00017.pdf/4? I know latex, but not so much how it works here. Thanks. Mike Peel (talk) 18:02, 18 March 2023 (UTC)

Template:Arxiv

Can we import w:en:Template:Arxiv from en.Wikipedia (or elsewhere)? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:47, 18 March 2023 (UTC)

Why do we need it? What use are you envisioning? Almost seems that arxiv should be pushed into WD and we pull it out through an authority control. — billinghurst sDrewth 12:06, 19 March 2023 (UTC)

Same as {{doi}} and {{BHL page link}}, &c. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:46, 19 March 2023 (UTC)

Poll regarding March 2023 Wikisource Community meeting

Hello fellow Wikisource enthusiasts!

We will be organizing this month’s Wikisource Community meeting in the last week of March and we need your help to decide on a time and date that works best for the most number of people. Kindly share your availabilities at the wudele link below:

https://wudele.toolforge.org/U2feqmZBy62FJjVd

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

Regards

KLawal-WMF and PMenon-WMF

Sent via MediaWiki message delivery (talk) 05:31, 19 March 2023 (UTC)

Some banal questions

Coming back into en.source after years, I'm going to upload a large work in 6 volumes: Lives of the most eminent painters, sculptors, and architects, by Giorgio Vasari, translated by Jonathan Foster, published by Henry C. Bohn, London 1850. My first problem is, to select a good name for the six volumes, harmonized with en.wikisource preferences.

My proposal (short but informative): File:Vasari - Lives, Bohn 1850, I.djvu.

Can any of you give me any comment or suggest a better alternative? Thanks!

(Other questions will follow for sure.... :-) ) Alex brollo (talk) 18:33, 19 March 2023 (UTC)

@Alex brollo: Please look to use arabic numbering, rather than roman numerals. Looking at the name of the work at enWP, and adding a clearer indication of a volume would be helpful, so File:Vasari - Lives of the Most Excellent Painters, Sculptors, and Architects, volume 1 (Bohn 1850).djvu would have been where I would go, noting that "Bohn 1850" may be superfluous if there is only the one English edition. — billinghurst sDrewth 22:21, 19 March 2023 (UTC)

@Billinghurst Thanks! IA stores multiple editions of that work, some of them from the same editor, nevertheless there is no upload of any of them into en.wikisource by now, so I can simplify the file name.

Another question: is syntax header="1" into pages tag recommended into en.source? Alex brollo (talk) 05:47, 20 March 2023 (UTC)

Not "recommended" as such. It's available for simple transclusions, but doesn't work for the more complex where there are contributors. I usually say "use with caution." Beeswaxcandle (talk) 10:42, 20 March 2023 (UTC)

@Alex brollo: For these encyclopaedic/dictionary works, we have been building work specific templates based on template:collective work header ([10]) or building something based on {{header}}, eg. {{oxon}} as a means to make the transclusion plug and play, and that actually works way better than header=1 IMNSHO. It is my aim to look to migrate more to "collective work header". I just haven't got there yet. Happy to build something for you, just need to see more what the work look like. — billinghurst sDrewth 10:51, 20 March 2023 (UTC)

@Beeswaxcandle @Billinghurst Thanks. I'll do some tests working into Volume 1 upload by a "try and learn" strategy. If I'll do any severe mistake.... please warn me. Alex brollo (talk) 14:31, 20 March 2023 (UTC)

@Beeswaxcandle @Billinghurst After some tries, I found that Lives... is an heavy, but simple text, and syntax header="1" seems effective.

1. What is en.wikisource policy about new template creation? If it is not severely discouraged:
   1. Can I create a work specific template to be used for TOC elements?
   2. Can I create a Template:Ct, importing it from it:Template:Ct?
2. What's the policy of en.source about styles.css nsIndex: subpage? I see it as a extraordinary advancement, can I do some tries?

Alex brollo (talk) 08:05, 21 March 2023 (UTC)

@Alex brollo: We suggest {{collective work header}} as a basis for a work specific template for numbers of good reason. 1) it is a template and allows us to categorise easily; 2) apply css styling from the template, 3) utilise for feeding things to WD, 4) apply templates that allow WD management finders, etc. Re work specific template, we would not think that we need more formatting templates, they typically exist, so most are other organisational aspects; for ToC, it isn't generally needed as we have the Index: .css files for that purpose and that is a far more efficient means to manage and style ToC; it also allows for simple table coding (peek at User:Billinghurst/styles for index css for some examples), I find "work_TOC" style works in so many simple ToC.

No, do not create "ct" template, it has already been discussed by the community and deleted, it is just a typographic style that existed for a short period of time, it is not a real typographical character.

Interwiki Links in Recent Changes: Where did They Go?

Maybe i lost some update, but let me ask a simple question:

I switched from Vector 2010 to Vector 2022 to test the new interface in Wikisource: I quickly noticed a different position fo the interwikilinks: there are (unfortunately) very few of them in ns0, but that is not my concern: I am used to navigating through main pages or RecentChanges in different languages.

The interwikilinks in the Main Page were moved in the bottom-right of the page, but... where are they located in the RC page? In Vector 2010 (on it.source) I added them myself and they showed up, but in Vector 2022 they simply disappeared. Is Wikidata involved? is there an open task in Phabricator? Did I miss anything? THank you for your kind reply! εΔω 12:34, 20 March 2023 (UTC)

Tech News: 2023-12

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

Problems

• Last week, some users experienced issues loading image thumbnails. This was due to incorrectly cached images. [11]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 21 March. It will be on non-Wikipedia wikis and some Wikipedias from 22 March. It will be on all wikis from 23 March (calendar).
• A link to the user's Special:CentralAuth page will appear on Special:Contributions — some user scripts which previously added this link may cause conflicts. This feature request was voted #17 in the 2023 Community Wishlist Survey.
• The Special:AbuseFilter edit window will be resizable and larger by default. This feature request was voted #80 in the 2023 Community Wishlist Survey.
• There will be a new option for Administrators when they are unblocking a user, to add the unblocked user’s user page to their watchlist. This will work both via Special:Unblock and via the API. [12]

Meetings

• You can join the next meeting with the Wikipedia mobile apps teams. During the meeting, we will discuss the current features and future roadmap. The meeting will be on 24 March at 17:00 (UTC). See details and how to join.

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

MediaWiki message delivery 01:25, 21 March 2023 (UTC)

March 2023 Wikisource Community meeting

Hello fellow Wikisource enthusiasts!

We are the hosting this month’s Wikisource Community meeting on 27th March 2023 at 10 AM UTC / 3:30 PM IST (check your local time) according to the wudele poll.

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 sgill@wikimedia.org 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) 10:01, 25 March 2023 (UTC)