Wikisource:Scriptorium

From Wikisource
(Redirected from Wikisource:S)
Jump to navigation Jump to search
Scriptorium

The Scriptorium is Wikisource's community discussion page. Feel free to ask questions or leave comments. You may join any current discussion or start a new one; please see Wikisource:Scriptorium/Help.

The Administrators' noticeboard can be used where appropriate. Some announcements and newsletters are subscribed to Announcements.

Project members can often be found in the #wikisource IRC channel webclient. For discussion related to the entire project (not just the English chapter), please discuss at the multilingual Wikisource. There are currently 418 active users here.

Announcements[edit]

Proposals[edit]

Bot approval requests[edit]

Repairs (and moves)[edit]

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

See also Wikisource:Scan lab

The purpose of these moves is to preserve the original edit history while the updated version is transcribed into the pages. X5163x (talk) 06:15, 28 January 2023 (UTC)Reply[reply]

To match the naming of the other volumes and so the volumes template can find it. MarkLSteadman (talk) 15:06, 1 January 2023 (UTC)Reply[reply]

Done. Mpaa (talk) 16:54, 1 January 2023 (UTC)Reply[reply]

Other discussions[edit]

Policy on substantially empty works[edit]

[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:

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. Inductiveloadtalk/contribs 15:43, 3 July 2020 (UTC)Reply[reply]

  • 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).Reply[reply]
  • 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)Reply[reply]
  • @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. Inductiveloadtalk/contribs 20:55, 3 July 2020 (UTC)Reply[reply]
  • 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)Reply[reply]
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. Slowking4Rama's revenge 01:55, 5 July 2020 (UTC)Reply[reply]
@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)Reply[reply]
TEA is on his usual deletion spree. not a fan. will not be finding scans to save texts, any more. he can do it. Slowking4Rama's revenge 00:15, 6 July 2020 (UTC)Reply[reply]
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. Inductiveloadtalk/contribs 00:47, 6 July 2020 (UTC)Reply[reply]
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. Slowking4Rama's revenge 11:53, 9 July 2020 (UTC)Reply[reply]
@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. Inductiveloadtalk/contribs 14:18, 9 July 2020 (UTC)Reply[reply]
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. Slowking4Rama's revenge 21:00, 14 July 2020 (UTC)Reply[reply]

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:Reply[reply]

  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)Reply[reply]

@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)Reply[reply]
I meant the namespace. Clarified now. JesseW (talk) 05:17, 6 July 2020 (UTC)Reply[reply]
  • 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)Reply[reply]
  • Symbol oppose vote.svg 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)Reply[reply]
    • @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. Inductiveloadtalk/contribs 14:40, 6 July 2020 (UTC)Reply[reply]
      • 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)Reply[reply]
  • 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)Reply[reply]
    @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)Reply[reply]
  • @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. Inductiveloadtalk/contribs 17:35, 6 July 2020 (UTC)Reply[reply]
  • @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. Inductiveloadtalk/contribs 17:35, 6 July 2020 (UTC)Reply[reply]
      • @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)Reply[reply]
        • @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. Inductiveloadtalk/contribs 17:41, 7 July 2020 (UTC)Reply[reply]

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)Reply[reply]

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)Reply[reply]

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)Reply[reply]

Proposal[edit]

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. Inductiveloadtalk/contribs 11:00, 25 August 2020 (UTC)Reply[reply]

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? Inductiveloadtalk/contribs 08:10, 16 April 2021 (UTC)Reply[reply]
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)Reply[reply]
@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)Reply[reply]

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)Reply[reply]

@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)Reply[reply]
Create the Draft namespace to hold substantially empty works? Then delete if no improvement after months?--Jusjih (talk) 19:22, 1 November 2021 (UTC)Reply[reply]
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? Inductiveloadtalk/contribs 20:29, 1 November 2021 (UTC)Reply[reply]

First run through is done, and it's transcluded. Needs validation. Thanks in advance for any help. Jarnsax (talk) 18:13, 16 June 2021‎ (UTC)Reply[reply]

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

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 spatnaik at wikimedia.org.


About This Month in Education · Subscribe/Unsubscribe · Global message delivery · For the team: ZI Jony (Talk), Monday 4:02, 30 January 2023 (UTC)

Exporting works to PDF[edit]

I have read somewhere that all the pages linked from the root page are exported into a PDF book after clicking the Download button. However, when I tried it with Modern and contemporary Czech art, the Illustrations page with the plates was not downloaded. May I ask what the problem is? -- Jan Kameníček (talk) 15:54, 28 December 2022 (UTC)Reply[reply]

It was my experience that the big blue Download button was an option free quick thing, at the time, similar to Gutenberg no-images and I have avoided it in the years since. The pdf download is interesting, as a default setting. Use the options in the Navigation bar (Download/Print instead!--RaboKarbakian (talk) 16:15, 2 January 2023 (UTC)Reply[reply]
@RaboKarbakian: Unfortunately, the result is the same, the Illustrations were not been included in the PDF. --Jan Kameníček (talk) 18:59, 2 January 2023 (UTC)Reply[reply]
Per Help:Preparing for export: "If you use any template that applies ws-summary (e.g. {{AuxTOC}}), then only links in that container will be used by default. If you have other links to include (e.g. in a TOC that's part of the original work), you can wrap that TOC in {{export TOC}} to add the ws-summary class to it." {{TOC begin}} applies ws summary so it will only pull items in the TOC and not additional tables in the root. MarkLSteadman (talk) 20:22, 2 January 2023 (UTC)Reply[reply]
Ah, thanks, that helped. --Jan Kameníček (talk) 20:35, 2 January 2023 (UTC)Reply[reply]

The Hardy Boys[edit]

Alright, it's happened everyone. We've got 3 works to do:

Let's do it. Anybody know how to get original 1927 scans this early in 2023? Archive.org has a bunch that are locked because they're later versions, Google Books also doesn't seem to have any scans of the 1927 originals, and Hathi seems to not have caught up with the fact that it's 2023 yet. I'm pretty angsty about this one. PseudoSkull (talk) 08:06, 1 January 2023 (UTC)Reply[reply]

@PseudoSkullI think it's best to think of PD-day as a process rather than an automatic switch. Although, all these works came into the PD domain at the stroke of midnight, it'll take a few days for the servers and librarians to catch up. I'm certainly waiting for a number of these for the MC. Hang in there! 10:27, 1 January 2023 (UTC)Reply[reply]
We also need to remember that year rolled over on a weekend. If the servers need manual intervention, I would expect things to happen on Tuesday the 3rd. Imzadi 1979  16:35, 1 January 2023 (UTC)Reply[reply]
@PseudoSkull Does this help? Index:The Secret of the Old Mill.pdf Languageseeker (talk) 17:19, 1 January 2023 (UTC)Reply[reply]
@Languageseeker: Thank you so much for finding those. But I can't seem to find the original The Tower Treasure anywhere online, even HathiTrust or Google Books. It's really weird. PseudoSkull (talk) 18:37, 1 January 2023 (UTC)Reply[reply]
The House on the Cliff.--Prosfilaes (talk) 19:38, 1 January 2023 (UTC)Reply[reply]
And The Tower Treasure Beeswaxcandle (talk) 08:20, 11 January 2023 (UTC)Reply[reply]
And Index:The Tower Treasure (1927).pdf was uploaded by TE(æ)A,ea. Languageseeker (talk) 01:30, 18 January 2023 (UTC)Reply[reply]

1927 Works are accessible on HathiTrust[edit]

As a FYI, even though it says that the works are Limited (search only), works from 1927 will load if you click on them on HT. 10:37, 1 January 2023 (UTC) Languageseeker (talk) 10:37, 1 January 2023 (UTC)Reply[reply]

Metropolis (1927 film) not on its Wikipedia page[edit]

Is there some reason why Metropolis isn't on its Wikipedia page, even though Sunrise and The Jazz Singer are, other than the Wikimedia Commons upload rule? I think we could upload it to Wikisource and then to Wikipedia if need be. SurprisedMewtwoFace (talk) 16:04, 2 January 2023 (UTC)Reply[reply]

you could also upload to english wikipedia as "PD-US". it is not a text, so maybe out of scope here. --((( S )))digitaleffie's ghost 01:43, 3 January 2023 (UTC)Reply[reply]
Find a copy with original subtitles from 1927, and you can upload it after removing the music. The original German subtitles exist, so that's possible. Given what a mess the movie is in, the reconstructions would have a better than normal chance of being copyrightable.--Prosfilaes (talk) 03:07, 3 January 2023 (UTC)Reply[reply]
@Slowking4: Not out of scope, we have tons of film transcriptions, see Category:Film. @SurprisedMewtwoFace: The film Metropolis in any form would not be able to be uploaded to Wikimedia Commons until sometime like 2036 IIRC because it is still under copyright in Germany, the source country. The film could be hosted here on the English Wikisource, but as has been said, it is relatively unlikely that we will find a freely licensed English translation of this German film. A Wikisource translation of the German version of the film in the Translation namespace could theoretically be made, but note that films have never been translated at Wikisource in practice. PseudoSkull (talk) 06:20, 3 January 2023 (UTC)Reply[reply]
@SurprisedMewtwoFace: Metropolis (film) has been transcribed. PseudoSkull (talk) 18:16, 21 January 2023 (UTC)Reply[reply]
Excellent! SurprisedMewtwoFace (talk) 14:28, 22 January 2023 (UTC)Reply[reply]

Floating image template[edit]

It seems that the {{Img float}} template does not work as expected: when the align is set for "center", but the capalign for "left", the whole box gets centered to the left, see here. I had a look at the template's code but did not find what causes the problem. -- Jan Kameníček (talk) 19:04, 2 January 2023 (UTC)Reply[reply]

There are two image templates FI which div based, and FIS is span based and floats. — ineuw (talk) 11:13, 4 January 2023 (UTC)Reply[reply]
@Ineuw:Unfortunately, the {{FI}} works differently and not as intended in the example. It cuts the text after the word where it was placed, and the text then continues after the image, making it look like a new paragraph. But the {{Img float}} template does not cut it and lets the text flow dynamically without being interrupted. Compare the text with FI template and the same text with Img float template. Reading the documentation of the {{Img float}} template, it should be possible to align the image and the caption independently, but it does not work. --Jan Kameníček (talk) 17:31, 7 January 2023 (UTC)Reply[reply]
Please take a look at notes 5 and 6. — ineuw (talk) 19:57, 7 January 2023 (UTC)Reply[reply]
Hm, none of them looks really satisfactorily. Note 5 breaks the text that should be continuous into separate paragraphs, and Note 6 not only breaks the text, but even part of a sentence is misplaced next to the caption of the image :-( --Jan Kameníček (talk) 22:47, 7 January 2023 (UTC)Reply[reply]
@Jan.Kamenicek: Didn't pay attention earlier, but the template insertion point was wrong. It would help if I could see the original. Please take a look at note 5. — ineuw (talk) 02:56, 8 January 2023 (UTC)Reply[reply]
There is no original yet, I was just been experimenting with the template and noticed that it does not work in some cases, and I thought it could be a matter of some minor fix in the code of the template. I am sorry if I take too much of your time for something for which I do not have a real example, but I use the template often and so it is probably just a matter of time until such a case appears.
As for the note 5, the text that should be continuous is currently broken into two paragraphs in the middle of a sentence. The image is not floating at all. What I was aiming at is something like this, i. e. the picture placed and floating in the middle of the paragraph, with the lines above and below continuing dynamically, only the picture would be centered and its caption left-aligned. Meanwhile I have found Template:FreedImg/span#Example 5: Floating centred image which is almost exactly what I wanted to achieve, but the image size has to be given in % of the screen width, which is also far from ideal. What seems getting near the ideal to me is {{Img float}}, which enables the desired outcome if both the picture and its caption are centered, or if both are left-aligned, but for some reason it cannot left-align the caption for a centered image. --Jan Kameníček (talk) 11:45, 8 January 2023 (UTC)Reply[reply]

Template:Cite Q[edit]

Some of our pages use {{Citation}}. w:Template:Cite Q is a wrapper that populates {{citation}} with metadata drawn from Wikidata. The template's documentation on en.Wikipedia has more detail.

I propose that we import Cite Q from en.Wikipedia, so that it can be used on this project. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:53, 7 January 2023 (UTC)Reply[reply]

Tech News: 2023-02[edit]

MediaWiki message delivery 01:07, 10 January 2023 (UTC)Reply[reply]

Latest ProofreadPage changes and CSS.[edit]

It seems that my page namespace CSS width settings of User:Ineuw/vector.css, also affect editing in other namespaces. If I set the edit mode to side by side in the page namespace, edits elsewhere appear side by side, including the Scriptorium. What is the intent, and where do I go to read on the changes that affect our edit environment. — ineuw (talk) 20:13, 10 January 2023 (UTC)Reply[reply]

vector.css gets applied globally across all pages (in the vector skin), it is not specifically restricted to the Page: namespace. If you want to select for page namespace editboxes try a selector like .prp-page-content > #wpTextbox1 if you are selecting (say) the textbox containing the page body in the Page: namespace. Sohom Datta (talk) 14:09, 11 January 2023 (UTC)Reply[reply]
There hasn't been any new changes in this area as far as I know, so to answer your other question, I'd say keeping track of ProofreadPage tasks/Tech News would be the way to keep track of new developments/behaviorial changes. Sohom Datta (talk) 14:11, 11 January 2023 (UTC)Reply[reply]

Adjustment to Template:PD-US system to accommodate film transcriptions[edit]

With normal (textual) works, we always go on the death date of the usually one (or sometimes more) writers of that work, and we insert the death year of that person into the PD-US template. That system is fairly straightforward. But with films, the copyright logic abroad gets a little weirder than that. It's not written in very many places on Wikimedia Commons or Wikipedia, but most jurisdictions (the EU is the one I'm going off of right now), several categories of filmmakers are considered authors, and all those people have to be taken into account when trying to figure out when a film will fall out of copyright outside the US:

  • The principal director
  • The screenwriter, and/or other writers of dialogue
  • The composer (if the film is accompanied by sound)
  • By extension, the authors of any works that may serve as the basis for a film's plot

Also, at Wikisource, we've traditionally listed only the directors of a film as the authors in the Header templates and Index pages, which is not quite an accurate representation of how things are, as was recently reminded to me in an edit by Hekerui on The Jazz Singer. And we've only been reflecting the directors' death dates in the copyright templates up to this point. So in the example of The Jazz Singer, to change the death year to 1983 in the copyright template (death date of Samson Raphaelson) serves to confuse readers, because there is no indication on the transcription page that Raphaelson needs to be considered an author by copyright standards. (Personally, I think the header templates and disambiguation pages should list the production or distribution company as authors, but that's a different matter that I'll fix another time.)

So, as someone who doesn't know Lua or the structure of these copyright templates, I'd like to request the following:

Copyright template text if film

This work is in the public domain in the United States because it was published before January 1, 1928.


Copyright law abroad tends to consider the following people authors of a film:

  • The principal director
  • The screenwriter, and/or other writers of dialogue
  • The composer (if the film is accompanied by sound)
  • By extension, the authors of any works that may serve as the basis for a film's plot

The longest-living of these authors died in 1983, so this work is in the public domain in countries and areas where the copyright term is the author's life plus 39 years or less. This work may be in the public domain in countries and areas with longer native copyright terms that apply the rule of the shorter term to foreign works.

@CalendulaAsteraceae: Or anyone else who could help. PseudoSkull (talk) 19:22, 11 January 2023 (UTC)Reply[reply]

Good idea! Hekerui (talk) 19:32, 11 January 2023 (UTC)Reply[reply]
@PseudoSkull, thanks for pinging me! I've added a film option to the shorter_term_text function in Module:PD and implemented it in the relevant license modules:
Would you be up for adding the film parameter to the documentation of these templates?
{{PD-US|1983|film=yes}}

This work is in the public domain in the United States because it was published before January 1, 1928.


Copyright law abroad tends to consider the following people authors of a film:

  • The principal director
  • The screenwriter, and/or other writers of dialogue
  • The composer/lyricist (if the film is accompanied by sound)
  • The cinematographer
  • By extension, the authors of any works that may serve as the basis for a film's plot

The longest-living of these authors died in 1983, so this work is in the public domain in countries and areas where the copyright term is the author's life plus 39 years or less. This work may be in the public domain in countries and areas with longer native copyright terms that apply the rule of the shorter term to foreign works.

CalendulaAsteraceae (talkcontribs) 20:27, 13 January 2023 (UTC)Reply[reply]
Symbol support vote.svg Support and per w:List of countries' copyright lengths this template will be much more useful for Hong Kong and the United Kingdom, etc, copyrighting films for the longest lifetime of main authors plus some decades. Yet some countries just copyright films for many years since publication, regardless of the lifetime of main authors.--Jusjih (talk) 23:17, 29 January 2023 (UTC)Reply[reply]

Hi, I am quite surprised we don't have such a page. This is really necessary with some examples covering different types of works. Thanks, Yann (talk) 11:48, 15 January 2023 (UTC)Reply[reply]

BTW Template:TOCstyle is a labyrinthine system, and a PhD in rocket science is needed to understand it. Yann (talk) 12:13, 15 January 2023 (UTC)Reply[reply]
@Yann: Please do not use that ugly cur Template:TOCstyle. I'd love to burn it. With the css available per work, it should just be a case of simple tables to create the TOC, then apply code to the css to do the formatting. We have so moved on since 2010 when we had none of the modern tools. That we still have some people overpowering works with dot leaders still flummoxes me. — billinghurst sDrewth 09:55, 16 January 2023 (UTC)Reply[reply]
Is there some examples of well made ToC? Thanks, Yann (talk) 11:03, 16 January 2023 (UTC)Reply[reply]
@Yann: I don't know that I can claim that they are particularly well made, but here are a couple of mine: Index:Shakespearean Tragedy (1912).djvu, The Master of Mysteries, Index:The Tremendous Event (1922).djvu. In essence, just use plain MW table markup with {{ts}} formatting as needed. The only thing that doesn't get you is dot-leaders, and in my experience it's just the learning curve that is steeper than the templates, not actual use once you've got it down. I also very much agree with Billinghurst on the TOC templates, and the dot-leader variants in particular. {{TOCstyle}} is especially over-engineered. Xover (talk) 11:35, 16 January 2023 (UTC)Reply[reply]
yeah, welcome to wikisource. TOC are an intermediate task, requiring knowledge of wikicode, and tables. and old template bloat solutions hang around (we should put a big warning template on it). there are lots of completed works to copy the TOC from. it’s no harder than choosing the right license on commons. --((( S )))digitaleffie's ghost 14:26, 18 January 2023 (UTC)Reply[reply]
I have done quite many ToC on Wikisource, mostly in French. I thought there would be some easy way to do here too… Yann (talk) 19:04, 18 January 2023 (UTC)Reply[reply]
There is an easy way to do TOC. Just use ordinary tables. My most recent example is the straightforward one starting on Page:Ruth Fielding at Lighthouse Point.djvu/9. A slightly more complex one starts on Page:Transactions NZ Institute Vol 22.djvu/11. IMNSHO, these are well made and, when transcluded, scale nicely. On my to-do list is to go back through some of my early TOC and convert them away from the ugliness of dot-leaders. Beeswaxcandle (talk) 04:19, 19 January 2023 (UTC)Reply[reply]
lol, calling tables "easy" might well baffle a new editor; expecting wikiprojects to be easy, without a steep learning curve is hopelessly naive. French wikisource is better here, because they have down selected preferred solutions, English hangs on to the old failed templates past their due date. --((( S )))digitaleffie's ghost 17:37, 19 January 2023 (UTC)Reply[reply]

Blanking User: pages (as an alternative to deletion)[edit]

We currently have (and periodically get) a bunch of user pages, userspace drafts, and user sandboxes proposed for deletion at WS:PD. They are usually proposed for deletion because they contain some old crufty code that puts them in a real content category, a maintenance backlog, contain some problematic code, mess up searches, drown out relevant entries on limited Special: pages (these are often limited to 5000 entries, so too much cruft make them unusable). But the community has historically (going by the outcomes of the deletion discussions) had a fairly high threshold for actually deleting stuff in User: space. Naturally enough since on WMF wikis it tends to be a no no to edit inside another user's user space. So these crufty old pages tend to stick around unless there are really strong reasons to delete them.

So… As an alternative to deletion, I have just created {{blanked userspace page}}. It's a simple message template that just says:

It's intended to be used to replace the content of a userspace page (i.e. blanking it) while explaining both how to get the content back if wanted, and reassuring everyone that it's a purely technical measure. Only to be used for userspace pages that show up where they're not supposed to, and only for pages in inactive users' userspace (active or recently active users you should talk to instead of using this template). And any actual deletion reasons (copyvios etc.) should go to WS:PD or WS:CV as usual.

I've currently put in lots of warnings in the template's docs ("experimental!", "admin only!", "use caution!"), but if the community feels it's comfortable with this approach I'm thinking this should be fine for any experienced user to do if and when they come across such pages. There's no real reason it should be restricted to admins (beyond them being used to making that sort of judgement call and by definition trusted by the community), and if anyone misuses it they can be thwapped upside the head gently chided and shown the error of their ways.

Can I get a quick straw poll on this? Yes, no, indifferent? The more people chime in (even with "don't care") the better we can gauge what the community's sentiment is for this. Xover (talk) 20:30, 15 January 2023 (UTC)Reply[reply]

Pinging @ShakespeareFan00 and @PseudoSkull, who have recently participated in discussions on this issue. I have also added a watchlist notice pointing to this discussion in an attempt to better gauge what the community thinks about this. Xover (talk) 20:43, 15 January 2023 (UTC)Reply[reply]
It's gentler than deletion and does not alter the actual content of the page, so if there is a genuine need for it then I think it's an acceptable solution. I'm not clear on the maintenance issues, though. Can you give an example of a page in userspace causing technical difficulties? Shells-shells (talk) 20:58, 15 January 2023 (UTC)Reply[reply]
Well, the ones that are currently at WS:PD were probably (I'm guessing) found because they showed up on Special:LintErrors. I've had (since fixed) pages show up in Category:Pages with script errors (or other error categories added automatically by MediaWiki). We had one user with ~15k DNB stub articles in their user space, all of which showed up on Special:WantedTemplates (which only shows the first 5k pages). Userspace pages also regularly show up in searches when we're looking for, say, a CSS class and where it's used; trying to migrate from an old template to a new one (or migrating its arguments from one style to another, or...). It's that sort of thing: noise that makes other maintenance tasks harder or masks real problems. Very rarely do they directly cause any problems on their own. Xover (talk) 22:37, 15 January 2023 (UTC)Reply[reply]
Symbol support vote.svg Support, I don't see any problem with this approach. Although I do have a question (as someone who doesn't go around looking for pages with semantic errors or bugs): When looking for such linting errors/CSS errors, etc., is it not possible to filter outside of the User namespace for these? I think it would be very rare you'd need to fix a random userspace page in this way, since they generally shouldn't be edited unless they're your own user page per the wiki commandments. PseudoSkull (talk) 23:27, 15 January 2023 (UTC)Reply[reply]
Often it is possible to filter. Sometimes it is not. For example on Special:WantedTemplates and similar. It is also one more thing to juggle in sometimes quite complicated searches. e.g. in stuff like this. And for some things you can't filter on namespace because a template or CSS class might be in use on the user's user page itself, or on pages in other users' userspace, and needs to be migrated. Having the option to just "softly" remove old and inactive userspace drafts and sandboxes that create noise for these cases would make a lot of these operations a lot less finicky.
But just to be clear: we absolutely can make do without this. It'll just make some things a lot less annoying to deal with for the small subset of users that work on this sort of thing. Xover (talk) 04:57, 16 January 2023 (UTC)Reply[reply]
An example I just now ran across: User:BirgitteSB/Fuzzy-Wuzzy (plain)/wikified. It shows up in Special:WantedTemplates because it tries to transclude the long-deleted {{Wikipedia}}. And it shows up in Category:PD-old-80-US because it uses that license template. It would also have shown up as a use of {{PD-old-80-US}} before we moved all these to Lua, which would have needed to be investigated before that migration could be completed. It also uses the obsolete / deprecated <small> tag that we're trying to get rid of, meaning it's showing up on Special:LintErrors somewhere. And I can think of at least three more ways that page might show up as noise when we're performing various maintenance tasks, just off the top of my head.
The page is from 2005 (~18 years ago) and BirgitteSB hasn't edited since 2014 (~9 years ago), so it's exceedingly unlikely they'll ever return (although it would be nice if they did; they were a very active community member when they were around) and want to work on this page again. Xover (talk) 07:14, 16 January 2023 (UTC)Reply[reply]
Symbol support vote.svg Support. Jan Kameníček (talk) 23:57, 15 January 2023 (UTC)Reply[reply]
Symbol support vote.svg Support Looks good to me; I've edited the template so it doesn't itself show up in Category:Uses of blanked userspace page template in incorrect namespaces. —CalendulaAsteraceae (talkcontribs) 02:39, 16 January 2023 (UTC)Reply[reply]

Pictogram voting comment.svg comments User pages should not be needing to come to WS:PD unless it is truly necessary.
At the same time user pages should not be needing us to edit them to get around issues of css code issues, and the like. If we are fussing that stuff, we are fussing the wrong stuff.
If the special pages are showing those errors, then that is a problem with the special: pages. that they cannot filter out User: ns.
With regard to templates? If that is really what you need to then go ahead, it should not be a policy nor a required process, just something that you feel useful and comfortable to use. I currently have a practice of ignoring them, or blanking them, wrapping them in resolving code like <nowiki>; with an appropriate edit summary; or I also can delete them if that is more appropriate and more closely aligns with our deletion policy.
No, it doesn't need categorisation, nor anything overly bureaucratic, just use a good edit summary. It is a user page, and depends on its use and its level of problem. — billinghurst sDrewth 09:48, 16 January 2023 (UTC)Reply[reply]

Symbol support vote.svg Support, but if a user page is ever used for false vanishing, then delete the problematic versions.--Jusjih (talk) 06:22, 17 January 2023 (UTC)Reply[reply]
Symbol support vote.svg Support Creating a process/template like this is ideal. ShakespeareFan00 (talk) 16:59, 17 January 2023 (UTC)Reply[reply]

Disambiguation with authors and works[edit]

The mainspace disambiguation header says "it lists works that share the same title" (emphasis mine). This leads to an awkward situation on the page Jane Austen, where the two possible targets are a work and an author. Is it possible to customise the header in exceptional situations like this? If not, can the capability be reasonably added?

I found a 2022 discussion in the Scriptorium archives that mentions the issue, but it's in the context of changing policy and moving pages. What I'm suggesting is changing the wording to better describe pages as they are now. -- Perey (talk) 07:13, 16 January 2023 (UTC)Reply[reply]

@Perey: Not exactly sure what you are asking though I am going to guess that you are wanting a means to visually identify that a target page is a disambiguation page. You can do that with a little css code in your special:mypage/common.css. The following text is what I use to turn those pages vivid orange.
/**
 * Display links to disambiguation pages in orange
 * @revision 1.0 (2015-05-27)
 * @author Kaldari
 */
a.mw-disambig { color: #f17600; }
If you want this to work on every wiki for you, then you can put that code into your m:special:mypage/global.css. — billinghurst sDrewth 09:36, 16 January 2023 (UTC)Reply[reply]
@Billinghurst: No, I'm after the ability to edit a disambiguation page to change the message that's shown—for everyone, not just for me. Right now, Template:Disambiguation produces a header with different text depending on whether it's used in mainspace or the Author namespace. (Specifically, the magic appears to happen in Template:Disambiguation/info.)
  • Main: "This is a disambiguation page. It lists works that share the same title."
  • Author: "This is a disambiguation page. It lists authors that share the same name."
In this situation, I would like it to instead read something like, "This is a disambiguation page. It lists works and authors that share the same name." The exact phrasing isn't so important; what I'm aiming for is the ability to change the message as appropriate when a dab page includes cross-namespace links. -- Perey (talk) 12:06, 16 January 2023 (UTC)Reply[reply]
@Perey: I hadn't overly fussed it as I thought that it was reasonably overt what it was trying to do and say. However, I created a parameter shared that does that and I have added it to Jane Austen. Feel free to suggest better wording. — billinghurst sDrewth 12:41, 16 January 2023 (UTC)Reply[reply]
And I have yet to document it. I would like a level of review and agreement through the community prior to this sticking => Category:Merged disambiguation pagesbillinghurst sDrewth 12:46, 16 January 2023 (UTC)Reply[reply]
If we're sure about the concept side, this implementation seems reasonable.
But I'm a bit more iffy on the concept side. Do we really need to put authors there? The typical cases are "Jane Austen" and "William Shakespeare", and those will all have exactly one relevant author. Wouldn't that be better as a hatnote ala. For the author, see Author:Jane Austen (i.e. so the author isn't listed as a dab'ed item, and thus we don't need to change the wording or have an extra param)?
But I haven't really thought through this, nor have the experience to tell what works and what doesn't, so I'm not sure I really have an opinion on it (and certainly not a firm one). It's just that now we're listing two kinds of concepts on a single dab where otherwise we only list one (either works or authors, not both), which makes my inner information modeller itch. Xover (talk) 14:31, 16 January 2023 (UTC)Reply[reply]
I think it could work:
This page lists works that share the title Sue Me. For the author named Sue Mee, see…
But then, what do we do with cases like Jane Austen, where there's only one work? If the mainspace page exists only to disambiguate works, not people, it doesn't need to exist, because we only have one work by that name! Do we get rid of the dab page, make it a redirect to Jane Austen (Sarah Fanny Malden 1889), and put the hatnote there?
(I said "cases like"… are there any other cases like this? It seems pretty rare for a biography to be simply titled with the subject's name. What about works named for characters who happen to share names with authors? Are we likely to publish anything by David Copperfield or Tom Jones?)
Also, I'm not sure about "exactly one relevant author". Author:William Shakespeare has four. Maybe it's lucky that we don't have any works titled William Shakespeare! -- Perey (talk) 15:53, 16 January 2023 (UTC)Reply[reply]

Tech News: 2023-03[edit]

MediaWiki message delivery 01:10, 17 January 2023 (UTC)Reply[reply]

Newspaper changing names[edit]

I'm wanting to upload some scans of New Zealand's earliest newspapers and transcribe these. However the newspaper changed names a couple times in its early years. From "The New Zealand Gazette", to "The New Zealand Gazette and Britannia Spectator", to "The New Zealand Gazette and Wellington Spectator".

Should I pick just the latest name? The earliest name? Treat them as different newspapers (for page structure purposes)? ElDubs (talk) 20:13, 17 January 2023 (UTC)Reply[reply]

do them as separate titles with a note in the header to indicate the change(s) on a time basis. Beeswaxcandle (talk) 22:06, 17 January 2023 (UTC)Reply[reply]
Thanks for that! ElDubs (talk) 22:21, 17 January 2023 (UTC)Reply[reply]
You are very welcome and Opinion of the Court delivered by Lady Paton in the Appeals under Sections 103 and 108 of the Extradition Act 2003 by Zain Taj Dean against (first) the Lord Advocate; and (second) the Scottish Ministers has a note with <onlyinclude> to automatically transclude the links in and to relevant pages.--Jusjih (talk) 05:46, 22 January 2023 (UTC)Reply[reply]

Hi, This work needs to be moved to a new page, and a disambiguation to be made for other editions, i.e. Index:Works of Jules Verne - Parke - Vol 8.djvu and the 1927 edition illustrated by N. C. Wyeth. Thanks, Yann (talk) 15:42, 19 January 2023 (UTC)Reply[reply]

@Yann: Yes check.svg Done Xover (talk) 16:02, 19 January 2023 (UTC)Reply[reply]
@Yann: Incidentally, according tpo the textinfo template on the talk page, the text now on Michael Strogoff (1876) is the edition published in Index:Works of Jules Verne - Parke - Vol 8.djvu (just transcribed by Gutenberg). If that's accurate it should be M&S-able. It also means the date is wrong and we need to move it to Michael Strogoff (1911), but since it was published within the greater volume it should in fact end up at Works of Jules Verne/Volume 8/Michael Strogoff (and Michael Strogoff (1911) should redirect there). But since I haven't verified that the textinfo is actually correct I just moved it to the immediate disambiguated title. Xover (talk) 16:11, 19 January 2023 (UTC)Reply[reply]
OK, thanks, Yann (talk) 16:12, 19 January 2023 (UTC)Reply[reply]

Author pages with complete names[edit]

Hi, I wonder why w:Charles Baudelaire page is at Author:Charles Pierre Baudelaire. Nowhere his middle name is used in the Wikimedia universe. Idem for Author:Agatha Mary Clarissa Christie. Can I rename these pages? Yann (talk) 16:42, 19 January 2023 (UTC)Reply[reply]

Wikisource:Naming_conventions#Author_namespaceJustin (koavf)TCM 18:22, 19 January 2023 (UTC)Reply[reply]
Well, it doesn't make sense to me. Yann (talk) 19:12, 19 January 2023 (UTC)Reply[reply]
Sorry, that was curt: the reason why those have a long name is because that's the rule. I think the reason that's a rule is because that is common in libraries and I think that is common in libraries to make it clear that one person and another person with the same name are two different persons. Does that make sense? —Justin (koavf)TCM 19:29, 19 January 2023 (UTC)Reply[reply]
In some cases, yes. But not for the 2 authors I mentioned above, and many others. And for Author:Charles Lindbergh, his father has the same middle name, so it is best NOT to use his complete name. Yann (talk) 20:56, 19 January 2023 (UTC)Reply[reply]
Hi Yann. What is the problem with the naming convention? What problems is this causing for you? In short we arrived at the naming convention for many numbers of reasons in helping to manage problems we were seeing and needing to resolve. We have a strategy in place, and your thinking to tactically circumvent it for your one case will cause issues. Of course their is no perfection, however, this has caused least problems.

We have redirects in place from the shorter versions, and you can use whichever variation you wish in the main namespace. We cannot write our rules for one or two authors with very unique names, that sort of approach just leads to every person arguing that every author that they have is a special case, and we simply got sick of that argument years ago. It was also problematic back then as we were getting too many duplicate author pages as we didn't have the diligence to expand names, so we had many variations of author pages for shorter forms or for various pen names. Then add to that the value we have found in managing disambiguation pages is a whole lot easier by undertaking this early expansion, and not having to fix up other peoples external links to us, essentially managing link rot.

I will also note that many of the biographical works that we reproduce that for the same periods for the authors we have pages do have fully expanded names, so that sort of alignment has its benefits. I will also note that what does it matter what the WMF universe is doing? We have them linked that way within WD and the best thing to do is link them to the item there, and pull our link. — billinghurst sDrewth 21:37, 19 January 2023 (UTC)Reply[reply]

I believe the principle of least surprise is important. I don’t see the benefit, but if there is a consensus… then OK. Yann (talk) 22:06, 19 January 2023 (UTC)Reply[reply]
Least surprise? Nah, that is the lesser of the problems. Have you seen the issues with disambiguation and moves at enWP, then the mess that has occurred when we have had to move pages and the link rot? That is a worse surprise. Do you see the issue for us when an author who has multiple pen names? How about the variations for women's pen names, their maiden and married names, including the Mrs. (husband's name)? We have done those dances, and we ended up here. Yes, there are some prominent authors who end up with expanded names and that surprises some. Yes there are people who edit at enWP who want to come here and see enWP conventions. They all survive. We update their edits, and we don't berate. It isn't a problem, it is just another bit maintenance to our style.

Also as our notability perspective differs, we will often have grandfather / father / son authors so who will you give precedence? We instead make the disambig the base, and full expand. We have had all these discussions, so once you set the conventions, do we have to have arguments about who are those exceptions due to a quirk or a preference?

So we differ from the WPs, we do NOT use the (disambiguation) suffix, and we don't have to have the argument on who is dominant to hold the position; we expand names where possible to disambiguate, otherwise we start to use (yyyy-yyyy). Accordingly, we have pretty much eliminated the issues with duplicate author pages. We have managed to suitably identify numbers of obscure authors and document them, There are a ton of other issues that we have had to address around Snr / Jr, Elder / ... all which are problematic for us, and we had to develop a style that is different, and it was purposeful as we needed more structure than the WPs.

Again I will ask, apart from surprise, what problems are you actually having with our design. [Anyone who wants to convert that to an essay and explain why we differ, then go for it.] — billinghurst sDrewth 23:11, 19 January 2023 (UTC)Reply[reply]

i’m shocked that new editors are surprised; and that functionaries from elsewhere expect that norms from elsewhere might apply here. it’s all a cultural goulash, and "i’m confused, so let’s change policy". --((( S )))digitaleffie's ghost 20:02, 20 January 2023 (UTC)Reply[reply]
I failed to understand this incivility. Those who ask deserve polite answers. --Jan Kameníček (talk) 23:11, 20 January 2023 (UTC)Reply[reply]

Poll regarding January 2023 Wikisource Community meeting[edit]

Hello fellow Wikisource enthusiasts!

We will be organizing the January 2023 Wikisource Community meeting in the last week of January 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/5tauCFqk8NJQBcBv

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) 03:48, 20 January 2023 (UTC)Reply[reply]

Hi, I finished proofreading this version. I am not sure what the title should be, and how to add it to new texts. Thanks, Yann (talk) 22:51, 21 January 2023 (UTC)Reply[reply]

Moved to Civil Disobedience (1946), which is a more common way of disambiguating works, and added to New Texts. Thanks for this contribution! --Jan Kameníček (talk) 14:52, 22 January 2023 (UTC)Reply[reply]
@Jan.Kamenicek: We should be more likely to call this "Civil Disobedience (Thoreau, 1946)" as the author name still has precedence and relevance. Adding a year alone is somewhat misleading. Wikisource talk:Naming conventions gives some examples. — billinghurst sDrewth 05:12, 23 January 2023 (UTC)Reply[reply]
Ah, I did not know about that old discussion, thanks. I will add my point of view to a separate section below. --Jan Kameníček (talk) 13:10, 23 January 2023 (UTC)Reply[reply]

Multi-volume work-[edit]

Courtesy notification of a discussion elsewhere: Index talk:New Edition of the Babylonian Talmud (Rodkinson) Volume 6.pdf ShakespeareFan00 (talk) 09:27, 23 January 2023 (UTC)Reply[reply]

Disambiguating editions by the same author[edit]

Unfortunately, we do not have clear naming policy, only a very old discussion of a couple of users from 2010, which did not result in any change to the very vague Wikisource:Naming conventions. Most of the points raised in that discussion make sense, with one exception. If we disambiguate more works by different authors, the authors' names are quite logically chosen for disambiguation. If it is not enough, we add year of publication. However, if we have only different editions of one work by the same author, I do not see any point in disambiguating the editions by both the author and the year. The year is just enough. Only if we have works with the same title by different authors, and at least one of them has also different editions, then it seems necessary to disambiguate them by both author and year. Otherwise I do not see the point in making the page name more complicated than needed. -- Jan Kameníček (talk) 13:34, 23 January 2023 (UTC)Reply[reply]

Thanks for bringing this up, and I agree.
So far as I can see, the only places it makes sense to use the author name to disambiguate is in disambiguation pages, and these should never need a year. For any other type of page the best and most commonly used elsewhere disambiguator is the year of publication. That should deal with 99% of cases. When there are the rare exceptions (collisions), the better additional disambiguator is publisher or place of publication (to distinguish separate UK and US editions published in the same year). Xover (talk) 15:46, 23 January 2023 (UTC)Reply[reply]
I don't see how the year of publication is the most common disambiguator. Usually, the format I see is Huckleberry Finn, by Mark Twain. I don't recall ever seeing the year used as a disambiguator without the author; in fact, a common academic format uses just the author and year (Stevens99) without the title to index into a bibliography.--Prosfilaes (talk) 03:53, 24 January 2023 (UTC)Reply[reply]

Hi.

I built this a few days ago... It would be nice if some other contributors could help fill in the missing volumes :) ShakespeareFan00 (talk) 23:30, 23 January 2023 (UTC)Reply[reply]

Tech News: 2023-04[edit]

MediaWiki message delivery 23:46, 23 January 2023 (UTC)Reply[reply]

Invitation to join Wikisource Community meeting (28 January 2023)[edit]

Hello fellow Wikisource enthusiasts!

We are the hosting the first Wikisource Community meeting of the year on 28th January 2023 at 12 PM UTC / 5: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 Triage 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) 13:03, 25 January 2023 (UTC)Reply[reply]

Request to localize images from Index:Now We Are Six (1955).pdf[edit]

The images from Now We Are Six are not in the PD globally, but are in the PD in the US. Since they've been uploaded to Commons, the images have been flagged for deletion. Can they be localized? Languageseeker (talk) 15:44, 26 January 2023 (UTC)Reply[reply]

Why is Category:Novelettes being merged into Category:Novellas?[edit]

I see a number of messages on my watchlist like "Moving from Category:Fantasy novelettes to Category:Fantasy novellas using Cat-a-lot". Shouldn't this have been discussed first? This doesn't answer my key problem, that it's not clear what is what. I'd rather have the distinction that a novelette is 7,500 words to 17,500 words, and a novella is 17,500 to 40,000 words, as per the Hugo/Nebula division w:Novella#Novelette, but if we do merge them, I think we should document that a novella is between 7500 to 40,000 words.--Prosfilaes (talk) 22:31, 27 January 2023 (UTC)Reply[reply]

The old Book Creator and PediaPress books[edit]

This is kinda a deletion discussion, but it's a bit too broad to only happen on WS:PD.

Once upon a time, the way to get PDF versions of our texts was the Book Creator. It was designed for Wikipedia and let you save a definition of "Wikipedia articles that should be included in a ‘book’" (plus ordering of chapters etc.). It was developed in a partnership with PediaPress (a commercial entity focused on print-on-demand services), and so it also offered the option of ordering print-on-demand physical books of these ‘books’. Somewhat half-heartedly it was extended to also work on non-Wikipedia WMF projects, including Wikisource.

However, since 2019 it has been effectively broken. The Creator tool kinda works, but none of the PDF/ODT/ZIM download options do and the print-on-demand function seems to have bitrotted in the intervening years.

At the same time, Community Tech developed the new ws-export function, the one that makes that big honkin' blue "Download" button on all our mainspace pages; offers PDF, ePub, and Mobi-format downloads; and is directly integrated in Wikisource and our content and workflows (naturally enough, since it was developed specifically for Wikisource).

The links to the Book Creator have already been removed from the sidebar and the associated project/help pages marked as deprecated and historic; but I think it's also time we got rid of all the now-mostly-broken pseudo-books sitting in Category:PediaPress books, along with associated templates with boilerplate etc. Thoughts? Xover (talk) 10:16, 28 January 2023 (UTC)Reply[reply]

We should probably at least add a deprecation warning like the one present at w:template:Saved book. I don't know if it's necessary to actually delete these pages; if anything they should be kept for archaeological interest. Shells-shells (talk) 11:50, 28 January 2023 (UTC)Reply[reply]
I "umm and ah" over this issue of the stored works some of the time and in the end I just walk away as seems one of our lesser issues. 1) They are static copies of works that are essentially dynamic as we proofread, validate and otherwise develop works--so that they are essentially uncontrolled copies as soon as they are output. 2) They do show a work at time A, and can show it later at Time B--possible showing versions. 3) They are in user: ns and WS: ns, so WS: ns is controlled by the community, and user: ns is controlled by the individual within community standards. 3) (open question) Where are they on a harm scale are static PDFs doing? Negative? Neutral? Positive? I would not want to be doing something that has zero harm and impacts uses. Have we even looked at the stats for visits? — billinghurst sDrewth 02:28, 30 January 2023 (UTC)Reply[reply]
https://pageviews.wmcloud.org/?project=en.wikisource.org&platform=all-access&agent=user&redirects=0&range=latest-20&pages=Category:PediaPress_books <= view stats
https://xtools.wmflabs.org/articleinfo/en.wikisource.org/Category:PediaPress%20books <= other stats

Hi, I added December, but November is still incomplete. Is anyone filling this up regularly? And January 2023 is still empty. Yann (talk) 22:48, 29 January 2023 (UTC)Reply[reply]

We were doing it manually and curating, then it converted to another process, and within data files, so I backed away last year. @Inductiveload:billinghurst sDrewth 02:00, 30 January 2023 (UTC)Reply[reply]

Color vs Black and white diagrams in a law[edit]

I'm looking at submitting a UK law which includes some diagrams of signs. The drawings in the law are in black and white, but the actual signs were in color, and specified in the law below the diagrams. Should the diagrams be uploaded in black and white because they were black and white in the original document, or can I use images that are colored according the what was specified in the law?--The Navigators (talk) 01:50, 30 January 2023 (UTC)Reply[reply]

@The Navigators: It is what is in the original work, rather than what is in the scan from which we are working? When all we have is the scan, then that has to suffice, however, if we know the facts of the publication of the work <=> scan, the the published work wins every time. Always a good idea to put notes on the respective Index_talk: page to explain what know and what you are doing; as that level of communication is also invaluable. — billinghurst sDrewth 01:59, 30 January 2023 (UTC)Reply[reply]