Wikisource:Proposed deletions

From Wikisource
Jump to navigation Jump to search
Proposed deletions
This page is for proposing deletion of specific articles on Wikisource in accordance with the deletion policy, and appealing previously-deleted works. Please add {{delete}} to pages you have nominated for deletion. What Wikisource includes is the policy used to determine whether or not particular works are acceptable on Wikisource. Articles remaining on this page should be deleted if there is no significant opposition after at least a week.

Possible copyright violations should be listed at Copyright discussions. Pages matching a criterion for speedy deletion should be tagged with {{sdelete}} and not reported here (see category).

Filing cabinet icon.svg
SpBot archives all sections tagged with {{section resolved|1=~~~~}} after 7 days. For the archive overview, see /Archives.


Nominations[edit]

Please place your request in a level 2 header at the bottom of this page.



Offences Against The Person Act, 1861 (repealed)[edit]

The following discussion is closed and will soon be archived:

A collection of extracts from the (complete and scan-backed) Offences against the Person Act 1861. The extracts consist of those portions of the original Act that “have been repealed and no longer represent the current law.” Putting aside for the moment the difficulty of keeping such a listing current (have no other portions of the underlying statute been repealed since Offences Against The Person Act, 1861 (repealed) was posted here a decade ago?), I question whether our own original listing of repealed statutes satisfies WS:WWI. Of course, if the UK Parliament issued a publication enumerating which portions of its Offences against the Person Act 1861 were no longer in force, I would see no problem with reproducing that document here. But Offences Against The Person Act, 1861 (repealed) doesn’t seem to be anyone’s work but our own and there is no indication that it was previously published. Tarmstro99 18:51, 18 October 2018 (UTC)

Could this be updated to be essentially an annotated version of Offences against the Person Act 1861? —Beleg Tâl (talk) 19:35, 18 October 2018 (UTC)
Perhaps more to the point: is anybody actually willing to do that work? I think part of Tarmstro99's concern was that we would need to also complete and maintain such a listing, and II don't see anybody stepping up to do so. Nor even show up too object to its proposed deletion. Hence my position below. --Xover (talk) 09:22, 18 July 2019 (UTC)
We don't have a policy requiring our annotated versions to be complete or maintained. Just move Offences Against The Person Act, 1861 (repealed) to Offences against the Person Act 1861/Annotated, put a header on it, and link it with {{annotation header}}, and voilà. No harder than actually deleting it. —Beleg Tâl (talk) 12:25, 18 July 2019 (UTC)
  • Symbol delete vote.svg Delete Per nom, and my reply to Beleg Tâl above. --Xover (talk) 09:22, 18 July 2019 (UTC)
  • Symbol keep vote.svg Keep because as an annotated text it violates no policies —Beleg Tâl (talk) 12:27, 18 July 2019 (UTC)
  • Symbol keep vote.svg Keep because i object to the use of threats to direct editor attention. i will be ignoring those works you threaten, you can do them. we are not german wikisource Slowking4Rama's revenge 03:02, 5 September 2019 (UTC)
Checkmark This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. BD2412 T 03:09, 3 December 2019 (UTC)

Template:Modern[edit]

Proposed for deletion on the grounds that it makes harder to actually figure out where a page is faulty.

ONE logic path for the behavior of a rendered page, makes it far far simpler to find out WHY and WHERE a Lint concern ACTUALLY broke a page, without having to run around chasing down two different versions of page determined by where it's being transcluded/rendered, through use of this template.

Deletion of this template is recommended in the interests of simplicity and sanity. ShakespeareFan00 (talk) 19:12, 18 July 2019 (UTC)

Prompted by An_Essay_in_Defence_of_the_Female_Sex/Section_8/Modern which is complaining about "Mis-nesting", which is next to IMPOSSIBLE to pin down with this Template in the markup.

ShakespeareFan00 (talk) 19:31, 18 July 2019 (UTC)

Symbol delete vote.svg Delete in favour of sanity and simplicity, PROVIDED that this template is first removed from all instances where it is currently used, and a reasonable alternative method of annotating these texts is implemented instead. —Beleg Tâl (talk) 21:02, 18 July 2019 (UTC)
FYI, the lint errors weren't caused by this template, they were caused by splitting italics across a template open like this:
''Sugar-{{modern|Jobber''...}}
This would break for any template that open a div, as the opening <i> is in the parent element, and the closing </i> will be in the tag provided by the template:
<i>Sugar-<div>Jobber</i><!--whoops!-->.....</div> 
Some new-lines might make that work more "sane" as it's a pain to edit, but it's not an issue woth {{modern}} specifically - it would have happened with {{smaller block}} too! As I mentioned previously on the Scriptorium, methodical bisection of the text makes it easy to pin down the offending content. Delete half, see if it fixed it, if yes, the error is in the deleted text, if no, it's in the undeleted half. Inductiveloadtalk/contribs 21:45, 18 July 2019 (UTC)
  • Symbol delete vote.svg Delete Hmmm Looking at the exemplar above I find it a horrid complex mess and have trouble finding commensurate value. BUT! …the idea of a template that adapts behaviour between namespaces (think links in an original ToC), or ways to mark up a work such that it can adapt itself to different needs and different contexts, is a generally good one. I am uncertain whether this template is one concrete instance of the good idea, just with a bad implementation. For a lot of things where this kind of thing would be good, templates are not a good technology match, and this may be one such, even if the functionality is otherwise a good idea. In sum: "Hmmm". --Xover (talk) 08:50, 28 July 2019 (UTC)
    Ok, after significant mulling on this, I don't think this template brings anywhere near sufficient value as currently implemented and as currently used to justify the costs (the linked example is both unreadable and uneditable). So I'm landing on delete: in practice we need to change template to always just emit the original version (first para), then subst: every instance of it, and then delete the template and all the /Modern subpages. Simply deleting the template will leave a big unfixable mess behind. --Xover (talk) 08:35, 5 October 2019 (UTC)
  • Pictogram voting comment.svg Comment It’s an intriguing idea being able to read a work in both original and modernised spelling. But could you imagine marking up The Canterbury Tales that way? Every second word would be wrapped in {{Modern}}! That’s an extreme example, but I’m thinking that works which have a sufficient density of archaic spellings to benefit from separate modernised versions would also have so many uses of the template to make them cumbersome to work on. That said, I’m not active in that area so maybe somebody else can say how useful or difficult it is to work with. Pelagic (talk) 00:15, 13 October 2019 (UTC)
Looking specifically at the normal and modern versions of An Essay in Defence of the Female Sex, there’s some creative use of the template to provide tool tips and wikilinks selectively into the modern version. Pelagic (talk) 08:40, 13 October 2019 (UTC)
  • Pictogram voting comment.svg Comment2 As for the broken formatting, the answer is simple: thou must not interleave markup! Is there anything wrong with two adjacent runs of italics like the following?
''Sugar-''{{modern|''Jobber''...}}
(Agreeing with Inductiveload on this aspect.) — Pelagic (talk) 00:15, 13 October 2019 (UTC)

Template:Chart[edit]

This template is not currently transcluded anywhere on the project—and as best I can tell never has been—and was imported from enwp (over an older WS-specific template) by John Vandenberg in 2008 based on a WS:S discussion where it was brought up as one possible solution. Apart from a few discussion pages that link to it, and See also links from the docs for {{familytree}} and {{chart2}}, it's not used anywhere on the project. So far as I know it's been entirely obsoleted by Chart2, and all these are likely to be even more obsoleted once the WMF eventually gets around to start pushing their horribly overengineered modern and powerful general chart solution.

This template and all its myriad subtemplates are currently generating about a hundred lint errors. --Xover (talk) 14:37, 19 July 2019 (UTC)

Did you mean Extension:Graph which seems more concerned with data charts, or Extension:Graphviz for things more like org charts and family trees? ShakespeareFan00 (talk) 16:03, 19 July 2019 (UTC)
The former. See e.g. task T137291. The Chart extension seems likely to be the new basis for all such functionality eventually (but probably not very soon: there still aren't dedicated resources assigned to it afaik). --Xover (talk) 18:26, 19 July 2019 (UTC)
Meh, its presence isn't hurting anyone —Beleg Tâl (talk) 23:35, 19 July 2019 (UTC)
  • Symbol delete vote.svg Delete happy to cull an unneeded, and code problematic template. — billinghurst sDrewth 22:23, 25 July 2019 (UTC)

Huon of Burdeux[edit]

Incomplete work without a source, that has been long abandoned. If someone can find a text that matches then it is presuambly resurrectable, however, at this time, it is just problematic. — billinghurst sDrewth 15:28, 25 July 2019 (UTC)

Symbol keep vote.svg Keep the "original" version, there is a scan matching it here. I'm inclined to delete the "respelled" version as an abandoned annotated edition with no chance of completion. —Beleg Tâl (talk) 16:02, 25 July 2019 (UTC)
I am not saying that the work is out of scope, I am saying that what we have here is valueless and abandoned in the main namespace. There are so many differences: name, pages, etc., we should ditch what is there. No one is going to work on it, and it should be despatched. We should stop having rubbish hanging around. — billinghurst sDrewth 22:15, 25 July 2019 (UTC)
  • Symbol delete vote.svg Delete per Billinghurst; and because even the "Original" version is actually an annotation: In this e-text, under the original chapters, letters in grey do not appear on the manuscript, but have been supplied here for clarity's sake. (For example, qd has been expanded to quod.). But just to be clear, I think what was attempted here was a very good idea and something we should give some thought to how we can achieve. But in this specific case what we have is an abandoned annotation without an unmodified original (i.e. it is outside policy). If we can find some way to put this into a policy framework and completed I would be happy to see it undeleted. I see it was largely created by The Man in Question who is still active on enwp. Perhaps they would be interested in working on it? With an unmodified original available, I think this would be a great annotated edition. --Xover (talk) 09:24, 28 July 2019 (UTC)

Airasia flight QZ 8501 passenger manifest[edit]

Previously discussed at WS:CV as a copyright issue (kept). Original PDF was deleted with minimal discussion at Commons, and an undeletion request declined citing privacy concerns. As best I can tell regarding copyright, this is simply {{PD-ineligible}}.

However, a recurring issue in all the previous discussions was whether the data is in scope per WS:WWI. It was highly relevant in 2014 at the time of the incident, so it was probably smart to keep it at the time for that reason alone, but now that it has had time to fade into history a little bit I think we should assess properly whether this is worth keeping. And let me be clear: the same factors that make this ineligible for copyright (lack of original expression) also argue that this is not within scope for Wikisource. Arguments to the contrary that turn the work into being a copyright violation are probably not particularly effective. --Xover (talk) 09:50, 31 July 2019 (UTC)

Symbol keep vote.svg Keep This is clearly in scope as a documentary source, being "evidentiary in nature, and created in the course of events". I also agree that this is {{PD-ineligible}}. We will need to get a hold of that PDF for local hosting. —Beleg Tâl (talk) 13:15, 31 July 2019 (UTC)
The PDF can be retrieved from w:File:QZ8501 Passenger Manifest.pdf. —Beleg Tâl (talk) 13:18, 31 July 2019 (UTC)
This is a raw list of passengers on the relevant flight that IMO bears little resemblance to … constitutions and treaties [and] personal correspondence and diaries.. It does, however, sound quite a lot like 1. Lists;… 3. Tables of data or results, better known as Reference material, to me. However, the full report on that accident—which presumably includes that list in an appendix somewhere—would clearly be a documentary source. --Xover (talk) 17:43, 31 July 2019 (UTC)
Reference material is also in scope if "it is published as part of a complete source text". As far as I can tell this PDF is a complete source text, or do you have evidence to indicate otherwise? —Beleg Tâl (talk) 18:29, 31 July 2019 (UTC)
The exception for a "complete source text" refers to Reference data that is provided as part of larger publication (tables, appendices, etc.) is perfectly acceptable. The passenger list is just a dump of data from the airline's booking system (it's literally a tab separated dump of some rows of the database with minimal formatting: I've written the code to produce such about a gazillion times for various purposes over the years); unlike the complete accident report that would include such data as a table or in an appendix. That a mere data dump is "complete" does not ipso facto turn it into a "publication"; and reference material is not in scope on its own, it is merely "perfectly acceptable" if it is here because it is a part of a work that is in scope. --Xover (talk) 18:43, 31 July 2019 (UTC)
In my opinion, the fact that by publishing this data dump as a complete PDF document, AirAsia has turned it into a documentary source that is evidentiary in nature, and created in the course of events (the other stuff listed there are just examples and their similarity to the document in question is of no relevance). The entire contents of this documentary source is reference material which is published as part of the complete source text as released by AirAsia. Even if you disagree with this interpretation, it is still a valid interpretation of WS:WWI and therefore in my opinion this document should be kept regardless. —Beleg Tâl (talk) 19:01, 31 July 2019 (UTC)

┌────────────────┘
There appears to be a fundamental disagreement on the best course of action for this work among the (two) participants in this discussion. I would therefore request wider community input to enable a proper determination of consensus. All input would be valuable for that purpose: "keep", "delete", "dunno", "don't care", and whatever else you think relevant would all be helpful in that regard. --Xover (talk) 06:27, 18 August 2019 (UTC)

@Billinghurst, @Beeswaxcandle: As the only two still-active participants in the previous discussion, do you have an opinion on this issue? --Xover (talk) 17:46, 30 August 2019 (UTC)
I expressed my opinion and the community made a decision at that time. I generally don't revisit discussions unless there is a specific change in the circumstance around the decision. Generally we would live with previous discussions whether we agree voted for or against it, whether we agree or disagree with that decision. [Don't pick scabs] — billinghurst sDrewth

Template:Cl-act-p[edit]

Overly complex, will soon be unused (outside of testcases). Per certain contributors views on over-complicated layouts. The related family of templates and associated module should probably be reviewed as well.

This is an overly complicated train-wreck of a template, that would need a major overhaul before it's anything like suitable for use on English Wikisource, and still remains incompatible with many other templates in common use.

Delete and redesign, once existing usages have been resolved. ShakespeareFan00 (talk) 16:05, 17 August 2019 (UTC)

Symbol support vote.svg Support after current usage replaced —Beleg Tâl (talk) 17:50, 17 August 2019 (UTC)
  • Symbol delete vote.svg Delete These complex formatting templates can be a boon, but they have a steep cost so using (creating) them wisely is recommended. Works large and regular enough to merit work-specific formatting templates (like EB1911, DNB, etc.), and without too complex formatting needs, will be the optimal use case. If the users of this template are frustrated by ongoing and unfixable problems and interactions with other templates, that's a strong indication that this template is not worth the hassle. --Xover (talk) 05:52, 8 October 2019 (UTC)

Template:numbered div family[edit]

Also listing the related {{numbered}} and {{numbered div}} family below, because they use a near identical technique to the previous incarnation of this template, with broadly simmilar incompatiblites.

In line with the on-going efforts to remove overly complex and incompatible layout templates. ShakespeareFan00 (talk) 09:02, 18 August 2019 (UTC)

Symbol neutral vote.svg Neutral on these, I do not know how they work, but I would think a simple numbered div template should not be overly complex. —Beleg Tâl (talk) 13:38, 18 August 2019 (UTC)
  • Symbol delete vote.svg Delete I have no idea what a "numbered div" is ideally supposed to be, but when I went to check what these were used for I found that they are actually used for creating fake lists with list item markers like "(a)" or "a." instead of just "a". This is really poor coding practice for accessibility purposes; from a semantic web perspective; and from a maintenance perspective. I'm sure there's a good "numbered div" use case out there somewhere, but actual uses were not it: lists should be marked up as lists. --Xover (talk) 06:06, 8 October 2019 (UTC)
An example usage would be - http://en.wikisource.org/wiki/Page:Compendium_of_US_Copyright_Office_Practices_(1973).pdf/11 to get specfic formatting, which when the template was written was not feasible with plain lists. However, now that templates styles has been implmented the approach should be revisited. ShakespeareFan00 (talk) 09:46, 13 October 2019 (UTC)

AWK Language Programming[edit]

This is the documentation for w:AWK (a domain-specific programming language often used for text processing). The version we're hosting is licensed under probably-free but nonstandard terms (it pre-dates the GFDL iirc), and a previous copyright discussion concluded that it was sufficiently free that we could host it in terms of copyright and licensing. See the previous copyright discussion.

However, one concern raised in that discussion, and which I share, is whether this is the sort of text we should host at all.

What we currently host describes an ancient version of AWK (1996 is the stone age in software terms), and was never completed (it's a fragment / excerpt). The original for this text is in w:Texinfo format, and is hosted in version controlled repositories with numerous global mirrors under the auspices of the Free Software Foundation.

I can't see that we add any value whatsoever for this work, and certainly not when we only have less than 5% of it. If we wanted to help out the FSF we should just get the WMF to mirror the texi2html-generated HTML version somewhere and not bother wasting resources on turning it into wikitext.

So… To generate a discussion of that issue, I am proposing that we delete this text as being outside the purpose of and a bad fit for Wikisource. --Xover (talk) 05:52, 3 September 2019 (UTC)

Symbol keep vote.svg Keep if we can get the full text. It should also be moved to scan. —Beleg Tâl (talk) 13:53, 3 September 2019 (UTC)
Is that the same edition? --Xover (talk) 16:33, 5 October 2019 (UTC)
Yes —Beleg Tâl (talk) 18:04, 5 October 2019 (UTC)
Symbol keep vote.svg Keep My personal collection has many programming books from the 1960s, so 1996 is hardly stone age. Especially for Awk, which has hardly changed since the 1980s. If it can be completed, it's a valuable work for us.--Prosfilaes (talk) 00:29, 4 September 2019 (UTC)
Sure, but this isn't so much a book as the "README" file distributed with the software (not literally of course; I'm making a point here). The "authorative" source for this work isn't a paper book that we can scan, but w:Texinfo source from which various displayed versions can be generated (one such would be something suited from printing as a paper book). What is the added value that we bring here? What is the point of taking Texinfo source, building PS or PDF, printing that to a book (notionally), scanning that book (again, notionally), transcribing and formatting it in our own markup format (instead of Texinfo), and then have Mediawiki generate HTML that gets displayed to the reader (if there are any)? Why not let Texinfo generate HTML directly? What value would this bring to our readers and reusers that justifies our expending the resources for that mildly insane process? --Xover (talk) 16:33, 5 October 2019 (UTC)
You could make a similar argument about a lot of stuff we host. We have a lot of texts that are digital publications only, and we convert them from HTML to MediaWiki only to be displayed as HTML again. And this is significant content too, like the huge amount of presidential texts we have that are taken from the White House website. —Beleg Tâl (talk) 18:22, 5 October 2019 (UTC)
Certainly, to a degree; and I would make that argument, to a degree. For anything whose native format is very close to our output format—i.e. HTML or a HTML-precursor markup format, or something that has the properties of HTML—we should be asking the question of what added value do we bring to our readers and reusers, and is it commensurate with the resources expended on it.
The closer you get to a traditional printed work like a book or magazine, the more clear the answer is; so that things like the Mueller report, that's published in a typeset and paged PDF essentially identical to a scan of a paper publication, are essentially no-brainers for inclusion. Hosting a work here has some inherent advantages like providing complete collections of related works, and navigability and discoverability (and don't underestimate the value of our having vetted works for copyright issues either!). The "curation" part of our work, in other words.
But our main value proposition comes from proofreading, and validating, and dynamic presentation of works; and none of these obtain to any significant degree for HTML-like "born digital" documents. So long as we get these for "free" (a reasonably low amount of our most precious resource: volunteer effort) the inherent value suffices. But the second the cost goes up—because of licensing issues, or lack of formatting, or being incomplete—that equation changes. A HTML-like "born digital" document that we have only a few percent of has a massive cost to complete, and the result adds very little value compared to a simple web archive of the original. This particular work can be treated as both a traditional work (a book) and as a "born digital" document (both are correct), but for the vast majority of "born digital" content, Wikisource is just simply not the right tool for the job. Computer program documentation like man pages, on the one extreme, belong in source code control repositories (like Github), and web pages need something like a web archive like IA. (actually, come to think of it, for your typical web page, "evolving work" applies) --Xover (talk) 07:57, 6 October 2019 (UTC)
Pictogram voting comment.svg Comment we are going to have more born digital works with the right license going forward. they are in scope, aren’t they? Slowking4Rama's revenge 01:39, 6 October 2019 (UTC)
I think they are unquestionably in scope both in terms of de jure policy and de facto community practice as they currently stand. This thread is more of "strawman proposal" to generate some discussion on whether all such "born digital" documents should be in scope.
The AWK manual, while I did stumble over it by chance (and apart from the discussion of principle it is an excerpt etc.), seemed a good example sitting in a grey area there: it is formatted as a book, and, I believe, was available as a physical printed book at some point, but its native and authoritative format is a kind of source code (Texinfo is not really human readable, but sort of markup-y) and it lives in the source control repository along with the program code for AWK. I am here asserting that it is more akin to program source code than to a book or other "document", would cost us a lot of effort, in a technically nonsensical process, and would bring very little added value to our readers and reusers.
A more extreme example would be a literal README file, or the groff source for a man page included in a source distribution tarball, or even the source code file itself if it included "self documenting comments". We need to draw the line somewhere, and this seemed a good example to generate a discussion of where those lines are. --Xover (talk) 07:10, 6 October 2019 (UTC)
I think that AWK Language Programming is very solidly on the in-scope side of the line, especially since it was published and distributed as a print book, and we do have access to a PDF edition for proofreading. Compare it to a document like the Apache License, which straddles the line between document and source code in a much more obvious way, and I think you will see that the work in question isn't anywhere near that line. —Beleg Tâl (talk) 15:12, 6 October 2019 (UTC)
The fact that we have access to the original formatting code should not be a reason to not include a book; that's a feature, not a bug. It's not a README file, it's a textbook for a programming language, and not even a proprietary dialect; it adheres to the POSIX standard fairly closely.
I have a lot more problems with things that never showed up on library shelves and never would. We should keep books, including stuff like Knuth's self-documenting source code books that were published as books and are kept on the main shelves of libraries (at which point we can include them).--Prosfilaes (talk) 05:26, 7 October 2019 (UTC)

Constitution of Rojava[edit]

Incomplete machine translation untouched since 2016, and by a contributor that has not edited since 2016, with no source, no license (though we would probably consider it PD-EdictGov), and in the wrong namespace (it's a Wikisource translation of the foreign-language original). It popped up on my radar because it's the kind of thing that attracts both vandals and "factual corrections". --Xover (talk) 11:41, 9 October 2019 (UTC)

Wikisource translations are kind of the wild west. Suggest to move to Translations page and tag it with translation license|original={{PD-EdictGov}}. —Beleg Tâl (talk) 13:29, 9 October 2019 (UTC)
Sigh. How about we just provide a link to the original on Google Translate? If we can track it down, as no source is provided. What possible value can a straight machine translation that will never be worked on have? Are we willing to keep any old thing so long as it's called a translation? And conversely, do we really want the translation namespace to be a dumping ground for low-quality cruft that overwhelms what high-quality translations we have (do we have any high-quality translations?)? I swear, some times on here I feel like I've wandered into an episode of Hoarders! Come on people, let's get some KonMari going here! --Xover (talk) 14:02, 9 October 2019 (UTC)
Lol. Translation namespace is kind of a dumping ground for low-quality cruft - even WS:T notes that "there is no requirement to show any level of competence in a subject or a language to participate". However, there is a way to get around it: if the work was added after July 2013 (such that the grandfather rule does not apply), and if a scan-backed copy is not present on the original language Wikisource, then technically it falls afoul of WS:T and we can delete it as such :) —Beleg Tâl (talk) 14:09, 9 October 2019 (UTC)
So far as I can tell, this clearly and straightforwardly fails to meet WS:T on multiple scores. First and foremost, WS:T says A full translation into English, by Wikisource contributors, of a work previously published in another language. (emphasis in original). This is neither a "full translation", nor meaningfully "by Wikisource contributors" (it's cut&paste from Google Translate, the exclusion of which was an explicit goal of WS:T). It also says A scan supported original language work must be present on the appropriate language wiki, where the original language version is complete at least as far as the English translation. An inter-wiki link to the original language work must be present on the English translation. Neither of which clauses are met here. And, finally, it says Works that are incomplete and abandoned for long periods may be nominated for deletion …. Which brings us to this proposal.
I don't think these are mere technicalities, or having the policy becomes pointless. But still we keep moving these low-quality works into Translation: where they gather dust indefinitely… --Xover (talk) 16:29, 9 October 2019 (UTC)
I think one could argue that this is a "full" translation in the sense that there is no part left untranslated, and that this is "by Wikisource contributors" in the sense that "the resulting copyright owner would be the user of the software". There is an inter-wiki link to ar:العقد الاجتماعي للفيدرالية الديمقراطية لروج آفا – شمال سوريا as required. We have yet to establish a consensus of what constitutes "abandoned for long periods" (someone argued to me recently that February 2019 counted as "a long time ago", which I'm sure even you would agree is insufficient).
To sum up, I think that this discussion has the ability to set precedent for many other works in Translation space and so we should be very clear about what we are willing to tolerate. In my opinion, "abandoned for long periods" is the key argument here, so putting a value on "long periods" would be a good starting point. The rest are, in my opinion, technicalities. We could also consider explicitly disallowing machine translations. —Beleg Tâl (talk) 17:39, 9 October 2019 (UTC)
It seems to me that two years of inactivity is a good line to draw, what do you think? —Beleg Tâl (talk) 17:46, 9 October 2019 (UTC)
See, the thing is, we do disallow machine translations! That was explicit and uncontested in the RFC that led up to the 2013 update of WS:T, it was just never actually written into the policy page (because we have such a lax attitude towards formal policies). And the way translations were supposed to work (again, explicit in the RFC) is that 1) a scan-backed foreign language work is proofread on the appropriate language WS, then 2) an index for the foreign-language work is set up here and 3) the translation done in the Page: namespace as if proofreading, before 4) transcluding into the Translation: namespace. Translated works here should cover no more of the work than is already proofread in the original language's WS if it is not complete. The decision to require a scan-backed foreign-language proofread work was deliberate. The goal of the RFC was to clean up the mess that had accrued prior, so being strict about what Wikisource translations were to be permitted was by design. And yet we're treating it as the exact opposite.
In any case, I very much agree with your other points except the "technicalities" bit. All those things are standards set through the RFC in order to give guidance for just such discussions as this. Not that they can't be overruled when the case requires it and consensus supports it (everything can), but it changes the default presumption and prevents rehashing each aspect every time.
As to time period, I'd happily accept anything between one and three years for incomplete stuff sitting in the Translation: namespace. For incomplete translation sitting in the Page: namespace (and scan-backed) I would not personally be in any hurry, so maybe 3+ years with a low bar to resetting the clock if anybody expresses an interest in working on it. --Xover (talk) 20:05, 9 October 2019 (UTC)
It is strange to me that this RFC (which I have not read) is so different from the policy that resulted from it. When I (independently) began creating scan-backed user translations a couple of years ago, some other admins flagged my work as out of scope, and said that what I was doing was "very unusual", so this is not well known even among the more experienced admins. I think I am more anti-deletionist than most, so there is also that. But yeah, three years sounds good (and if no one objects to it, I'd count this as precedent). As far as machine translations go: I just realized that if it were not masquerading as a Wikisource original translation I would have no hesitation to nuke it as an unpublished translation in violation of WS:WWI, so I guess that rationale works here too since no original content has been added to it. But I do think machine translations should be explicitly addressed in WS:T. —Beleg Tâl (talk) 12:45, 10 October 2019 (UTC)
  • Pictogram voting comment.svg Comment move it to the contributor's user namespace, and leave them a note that if finished that it belongs in the Translation: ns. — billinghurst sDrewth 12:06, 20 October 2019 (UTC)
    Symbol support vote.svg Support A good compromise, I didn't think of that, but we should probably take this course of action more often. —Beleg Tâl (talk) 13:45, 20 October 2019 (UTC)
    @Billinghurst: Regarding moves to User space, you moved the work Translation:Mayan legends (discussed below) to User space for much this reason, but it was then moved out of user space by another user without the underlying issues having been resolved. Any ideas how to prevent this? Perhaps an {{mbox}} or category (or both) to track and educate? —Beleg Tâl (talk) 17:56, 31 October 2019 (UTC)
    @Beleg Tâl: We can handle it in a number of ways. 1) simply protect the work against a move, either soft or hard; 2) write a filter that disallows it, or warns against it, and a permission level, or some of the AF rights or other conditions that can be applied; 3) simply write a filter that flags such a move out of a namespace. — billinghurst sDrewth 20:10, 31 October 2019 (UTC)
    Moving junk to user space solves very little: it's just another namespace to use as a dumping ground. At the very least this option should only be applicable when the user in question is active and asserting an intent to work at something that may eventually be suitable for a content namespace (and should be a time-limited grace period even then). And once we start accumulating junk in User: space it is going to be essentially impossible to clean up: main and Translation: space have at least some standards, User: has none. --Xover (talk) 19:13, 31 October 2019 (UTC)
    @Xover: Yes, though qualified. Firstly, we have always been pretty liberal with our user ns, and as long as it is not abuse, or clearly contravening decency, we have allowed numbers of constructs where they are within the true nature of Wikimedia. Secondly, we delete junk, though there can be occasions when it may not be, and you simply want the time to explore, discuss and don't want the user to get kicked in the guts when they are seemingly, or trying to be, doing the right thing, but it doesn't fit. If the user ns is less pure, so what. It is user space, it isn't primarily indexed, and if it has some constructs, and they are not harmful, they are not copyright, they are not abuse, what do we really care??? I have pages of junk in my user space, some of which I prod and turn over, some of which I do not. One user has 00s of proto WP articles here. How is any of that different? — billinghurst sDrewth 20:17, 31 October 2019 (UTC)
    I'll grant that moving to userspace does achieve the most critical aim: it gets junk out of the main content namespaces. I'll also stipulate a general exception for instances where we have something that is not yet, but may eventually be, suitable for main/Translation: and where a user is actively asserting an intent to work on it in their sandbox. That's essentially the "don't discourage [kick in the guts] contributors" scenario.
    What I am objecting to is using Translation: and User: space (or any other namespace) as dumping grounds for stuff that would otherwise be deleted. The case at hand is a machine translation straight out of Google Translate. It has had minimal wiki formatting, but the translation itself has not been fixed. It's been sitting there untouched for well over three years (2016). The user who uploaded it has not edited for three years. In other words, it's junk that has zero realistic chance of ever being worked on at all, much less improved to the point we'd host it.
    And every page of junk we have sitting around has a maintenance cost. Take this one, dumped in Translation: where we tend to dump everything, sitting there with a {{under construction}} tag that puts it in a maintenance category, contributing to the backlog and hiding other articles needing attention. It attracts "corrections" and vandalism, showing up in Recent Changes and needing patrolling. If it had templates in it it would be another page needing (possibly manual) intervention when migrating or deprecating templates. Etc. Nothing much to care about for one page, but something that accumulates quickly if we make a habit of it (which this thread is in danger of creating precedent to do).
    I have no complaints about a user creating a gazillion sandboxes and works in progress in their user space: it's us using the user space of an absent user as a convenient place to hide our trash that's the problem. Sooner or later it'll start to stink bad enough to lower property values in the whole neighbourhood. --Xover (talk) 05:50, 1 November 2019 (UTC)

Last Will and Testament of Cecil Rhodes[edit]

Dump and forget text that is ugly OCR. Whilst the text is in scope, the presentation is most definitely not. The contributor is long gone, God rest his soul. If someone feels like trying to getting something, it is at Internet Archive identifier : lastwilltestamen00rhoduoftbillinghurst sDrewth 12:02, 20 October 2019 (UTC)

Pictogram voting comment.svg Comment While my immediate inclination was to agree with you, I notice that there was an effort to clean it up as recently as two weeks ago. If someone is interested in salvaging it I would be inclined to give them the time to do so. @Arlo Barnes: What're your plans for this work? Are you planning to clean it up completely? Billinghurst has found a scan (see above), so if you're interested we could help you get set up to proofread it properly to modern standards. Otherwise it'll probably get deleted (with no prejudice to recreating if someone wants to work on it in the future) because as it stands it's just a cut&paste of the OCR text at IA. --Xover (talk) 12:38, 20 October 2019 (UTC)
Here is your index page: Index:Last Will and Testament of Cecil Rhodes.djvuBeleg Tâl (talk) 13:52, 20 October 2019 (UTC)
I am new to Wikisource QA, but I would be willing to give it a try (I ventured onto that page from the Wikidata entry, where I spend more time). Arlo Barnes (talk) 16:40, 20 October 2019 (UTC)
Excellent. I'll follow up on your talk page. --Xover (talk) 06:39, 21 October 2019 (UTC)

Template:for, Template:for loop, and Module:ForLoop[edit]

The templates / module Template:for, Template:for loop, and Module:ForLoop reimplement a basic programming construct for use in Mediawiki templates (i.e. they are strictly meta-templates, not really suitable for exposing to normal users). Almost any conceivable use for this is better solved through an actual Lua module with a suitable template frontend. But so long as these exist they will end up being used somewhere; to wit, the only two transclusions of them are in two Page: pages from August of this year (where they're used to achieve brevity in a disputable tradeoff with clarity and standard practice). All three were experiemental imports from other projects in 2014, and have not been touched since.

I propose that we remove the two extant uses and then kill it with fire! delete them. --Xover (talk) 13:34, 17 November 2019 (UTC)

Symbol support vote.svg SupportBeleg Tâl (talk) 13:47, 17 November 2019 (UTC)

Pages of w:University of Farmington[edit]

Copies of webpages contributed by user:Cuatro Remos

Rationale for retention: "I believe these pages should be kept here for historical and educational purposes". Seems the website was a honeypot set up by a government agency (see linked article).

I don't see that they are within scope as expressed at WS:WWI. There is also no certainty to whom created the pages, and the content to know that the specific pages are created by government employees, or contractual agreement. (Noting that I have not tagged the individual pages.) — billinghurst sDrewth 23:18, 1 December 2019 (UTC)

I would not mind having them deleted. However, it should be noted that this is not just another spoof site. It was a site set up by a US govt. agency in order to deceive undocumented immigrants and have them deported for a reason. Having these texts here may not make a difference at all, but I think they are of historical interest and may be interesting from that side. But, I repeat, I don't really care if you decide to delete them. --Cuatro Remos (talk) 23:27, 1 December 2019 (UTC)
There are many things that are historical interest that we can not include because there is an absence of a clear line to the public domain. We don't know, frankly, whether these documents are copyright free. BD2412 T 01:15, 2 December 2019 (UTC)
  • Symbol delete vote.svg Delete per nom. --Xover (talk) 14:27, 2 December 2019 (UTC)

Template:TOCstyle and associated module..[edit]

Per the views of other contributors, too complex to use reliably, and eventually overruns Mediawiki limits. Delete once an "appropriate" alterantive have been provided. ShakespeareFan00 (talk) 15:05, 7 December 2019 (UTC)