Jump to content

Wikisource:Scriptorium/Archives/2018-11

From Wikisource
Latest comment: 5 years ago by EncycloPetey in topic Disambiguating Shakespeare

Announcements

Proposals

Bot approval requests

Repairs (and moves)

Other discussions

Indic Wikisource Community Consultation 2018

This Wikisource Meet, described at Meta, is going to be organised in Kolkata on 24-25 Nov., 2018. One member from each Indic Wikisource has been invited. I have been invited to represent English. If the Community desires me to talk specifically about some issue at this Meet, please let me know. Best, Hrishikes (talk) 01:33, 2 November 2018 (UTC)

Non apperance of CharInsert gadget...

When editing an Index page I do not see the additional toolbar generated for the CharInsert gadget. Can someone give EXACT configuration details to get it working again, thanks? ShakespeareFan00 (talk) 15:18, 5 November 2018 (UTC)

Currently under discussion at Wikisource:Scriptorium/Help#Wikitext_editor. I doubt anyone has EXACT configuration details to give you. —Beleg Tâl (talk) 16:04, 5 November 2018 (UTC)

17:29, 5 November 2018 (UTC)

Open call for Project Grants

Greetings! The Project Grants program is accepting proposals until November 30 to fund both experimental and proven ideas such as research, offline outreach (including editathon series, workshops, etc), online organizing (including contests), or providing other support for community building for Wikimedia projects.

We offer the following resources to help you plan your project and complete a grant proposal:

Also accepting candidates to join the Project Grants Committee through November 15.

With thanks, I JethroBT (WMF) 19:46, 5 November 2018 (UTC)

Plainlist does not indent for sub lists..

The page here has an index with 2 levels of entries Page:Mr. Punch's history of the Great War, Graves, 1919.djvu/330

I could format this using TOCstyle, but that seems like overkill, so I am using plainlist, however currently that just flattens the list down entirely, which is not the desired behaviour.

Is there someone here that can come up with a tweaked CSS class to accommodate a page like this?ShakespeareFan00 (talk) 14:29, 6 November 2018 (UTC)

Simplify. Don't use a list class at all. It's not necessary for indices. For something like this I usually use poem tags and a simple colon indent for the second level. No need to make it more complex than that. Beeswaxcandle (talk) 19:26, 6 November 2018 (UTC)
It's a list; it should be marked up as a list, not least to improve accessibility. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:26, 6 November 2018 (UTC)
The CSS you need is: style="list-style:none". Eg:
<ul style="list-style:none">
<li>Outer item 1</li>
<li>Outer item 2</li>
<li>
  <ul style="list-style:none">
    <li>Inner item 1</li>
    <li>Inner item 2</li>
  </ul>
</li>
<li>Outer item 3</li>
</ul>
Which renders like:
  • Outer item 1
  • Outer item 2
    • Inner item 1
    • Inner item 2
  • Outer item 3
...Unless I misunderstood what you were looking for? --Mukkakukaku (talk) 03:03, 7 November 2018 (UTC)

Which is essentialy what {{plainlist/s}}{{plainlist/e}} could be generating.. The class for plainlist needs a LI->UL->LI rule I think..ShakespeareFan00 (talk) 11:50, 8 November 2018 (UTC) which I don't think it currently has.. ShakespeareFan00 (talk) 11:51, 8 November 2018 (UTC)

Currently using TOCstyle as I understand it. ShakespeareFan00 (talk) 11:51, 8 November 2018 (UTC)
The actual style for plainlist is
.plainlist ul{line-height:inherit;list-style:none;margin:0}
.plainlist ul li{margin-bottom:0}

which seems to mean every UL is forced to left-hand margin of the DIV, irrespective of it being a "sub" list or not.

MAybe an additional rule such as

.plainlist_i ul li ul{position:relative; list-style:none; margin:1.6em} 

could be considered, so that successive sub-lists can beindented, but I don't think it's complete solution. ShakespeareFan00 (talk) 12:04, 8 November 2018 (UTC)

Pretty sure you don't need position:relative. I'm also pretty sure you don't need anything more complicated than:
.plainlist ul{ list-style:none; padding-left:0 }
.plainlist li > ul { padding-left:1em; }
Eg. as seen here: [3] --Mukkakukaku (talk) 03:07, 9 November 2018 (UTC)

19:22, 12 November 2018 (UTC)

Change coming to how certain templates will appear on the mobile web

CKoerner (WMF) (talk) 19:34, 13 November 2018 (UTC)

Books in french for French Wikisource

Hi,

I am contributing on french wikisource and I would like your help. I can download lots of books from Hathitrust (public domain work) but some books aren't accessible (but they are in the public domain). There are :

  • Labarre - Le chant de la paix, see HT
  • Marseille, porte du sud, see HT
  • Une officine royale de falsifications, see HT
  • Hello-Les Plateaux de la balance, Perrin, 1923, see HT
  • Œuvres complètes / Albert Londres, see HT
  • Poèmes à Lou see HT

Is someone can send me theses books by email ? Thanks ! --Shev123 (talk) 22:15, 9 November 2018 (UTC)

Moved from Wikisource:Requested texts--Prosfilaes (talk) 21:31, 13 November 2018 (UTC)

Remove DISAMBIG tag from Versions and Translations header templates

User:ValterVB has informed me that the DISAMBIG tag magic word causes problems on Wikidata if the linked item is not an instance of "Wikimedia disambiguation page". Is it possible for us to remove this tag without causing further issues? —Beleg Tâl (talk) 18:23, 14 November 2018 (UTC)

What would we replace it with? Versions pages and Translations pages function like disambiguation pages.
Wikidata has done very little to accommodate the structure and linking of the Wikisource projects. It sounds like something that they should be addressing, not us. --EncycloPetey (talk) 18:32, 14 November 2018 (UTC)
I agree. However, I don't trust Wikidata to address this, given their track record. Furthermore, these pages function like disambiguation pages on a conceptual level, but I do not see a need to have them tagged as such in the system, especially if it causes compatibility issues with sister sites. —Beleg Tâl (talk) 18:37, 14 November 2018 (UTC)
But Wikidata isn't a "sister site". Wikidata was proposed as a coordinated central location to support the Wikimedia sites. If they can't fulfill their function, it's not our problem.
Yes, I know what they're like. A misguided bot operator recently began adding Wikisource translations from multiple Wikisources to the same data item based on the interwiki links, because he didn't have the slightest idea that this was incompatible with both the Wikisource structure and the Wikidata data model for works. He didn't bother to do any research before turning the bot loose.
The only reasonable recourse I can see would be adopting the "Work:" namespace, just as the Italian Wikisource has done ("Opera:" in Italian). They have a separate namespace for listing editions or translations so that there isn't a need for tagging them as disambiguation. However, this would be a lot of work for us. --EncycloPetey (talk) 23:14, 14 November 2018 (UTC)
I agree with EncycloPetey on this one, in that it's something that WikiData should be fixing. Those are disambiguation pages, albeit a different kind of disambiguation. --Mukkakukaku (talk) 01:52, 15 November 2018 (UTC)
Is this about mainspace pages that disambiguate between different works of the same name? Or is it about mainspace pages that link to multiple editions of the work. The former are disambiguation pages and (I think?) can be instances of disambiguation page; the latter are works and are instances of creative work (or a subclass). But there is a great deal of misunderstanding around Wikisource on Wikidata, so let's not make concessions to fitting our structures to the wrong way over there! :-) Sam Wilson 05:20, 15 November 2018 (UTC)
This is about mainspace pages that link to multiple editions of the work, i.e. Versions pages. Versions pages, like disambiguation pages, contain the magic word __DISAMBIG__ in the {{versions}} template. This apparently causes problems on Wikidata, and given what we know of Wikidata they will almost certainly refuse to fix any such problems. Because of this, and because I know of no benefit that this magic word provides, I am therefore proposing to remove this magic word from the {{versions}} (and {{translations}}) headers. —Beleg Tâl (talk) 13:32, 15 November 2018 (UTC)
It seems everything causes problems on Wikidata, and nothing is ever fixed. If we concede to make changes to fit them, we will be doing so over and over. Then Wikidata will change their model and we'll have to do it over again. They've been doing just that with regard to data items for biological taxa for years, having the same argument over and over. I say we worry about what works for us, and if Wikidata can't cope, then oh well. --EncycloPetey (talk) 15:08, 15 November 2018 (UTC)
Hey! Dont talk about wiki- … oh, them, yeah! Wikidata is rubbish! CYGNIS INSIGNIS 15:15, 15 November 2018 (UTC)
Remove it … again? I thought we weren't supposed to mention it? I might have done once, think I got away with that [faints] CYGNIS INSIGNIS 15:15, 15 November 2018 (UTC)

23:28, 19 November 2018 (UTC)

Community Wishlist Survey vote

18:13, 22 November 2018 (UTC)

Can I upload Research works done in our University here?

Can I upload research works does by me, my friends and some of my faculty here? If yes, how can I prove that they are public domain if I'm the first person place them on internet and they haven't published them yet. In this way how can they prove that they doesn't have any sort of objections? IM3847 (talk) 15:39, 10 November 2018 (UTC)

In general, Wikisource does not accept original works. See Wikisource:What Wikisource includes#Works created after 1922:. Analytical and Scientific works can be included if the work has been published following peer review, or if the author or researcher is considered notable. --EncycloPetey (talk) 20:41, 10 November 2018 (UTC)
right - you could prove they are public domain by publishing in an open access journal with a CC0 license. if they are open pre-publication draft of paywall journals, you would then upload them to your website, with the CC0 license. Slowking4SvG's revenge 01:57, 11 November 2018 (UTC)
Some of them are published on our college library site, now can I upload them too?
You'll have to be a bit more specific about what is proposed to be uploaded. Self-publication on a website is not sufficient in itself to merit inclusion. --EncycloPetey (talk) 15:58, 11 November 2018 (UTC)
I've written a research paper on a few Natural disasters in India which contains a few desktop studies. This paper was published in our University Library. No can I upload it to Wikisource? If yes then how? IM3847 (talk) 16:09, 11 November 2018 (UTC)
Could you provide a bibliographical citation for the publication discussed? If they are accessible online, could you provide a link to them? --Jan Kameníček (talk) 16:41, 11 November 2018 (UTC)
[12] This is the link of the journal published by my classmate.
I think the main problem with works published in this journal is that the journal states at the bottom of the main page that all rights are reserved. What is more, the guidelines for the submissions of papers require filling and sending Copyright form, which states that "In the case of republication of the whole, part, or parts thereof, in periodicals or reprint publications by a third party, written permission must be obtained from the Editor-in-Chief of IJRET." So you would probably need such a permission stating that the article can be released into public domain. --Jan Kameníček (talk) 09:09, 12 November 2018 (UTC)
@Jan.Kamenicek: Can you please check [13] this link too.—IM3847 (talk) 15:30, 23 November 2018 (UTC)

Index:Growing Black Locust Trees.djvu

Hi, can someone please help me with the copyright tag for this? Is it {{PD-USGov}}? Jpez (talk) 06:31, 23 November 2018 (UTC)

{{PD-USGov}} is appropriate. It was written by a Forest Service employee, which is an agency in the US Department of Agriculture -- a part of the federal government. --Mukkakukaku (talk) 15:41, 23 November 2018 (UTC)
I think so too. Thanks! Jpez (talk) 18:29, 23 November 2018 (UTC)
there is a custom USDA FS license on commons, which i put on, not 70. Slowking4SvG's revenge 03:10, 24 November 2018 (UTC)
The FS template explicitly says it's for images though. (Not even sure what that license even exists since it uses the same rationale as US Gov...) --Mukkakukaku (talk) 04:32, 24 November 2018 (UTC)
the scan of a book is an image sort of. never underestimate the propensity of commons to add extraneous detail, including which branch of government did the work. Slowking4SvG's revenge 02:16, 25 November 2018 (UTC)

Match and Split across subpages

Is there a way to run Match and Split on a work that is split across several pages, without having to manually run it on each subpage? Either natively or using some sort of gadget or script or third-party tool ? —Beleg Tâl (talk) 16:48, 24 November 2018 (UTC)

Anthologies x Collections

Is there any difference between Category:Anthologies and Category:Collections? --Jan Kameníček (talk) 16:45, 25 November 2018 (UTC)

Anthologies are usually assembled by a compiler (not the author) and typically contain works from multiple authors. Collections typically feature works from a single author, and may be collected by the author himself.
However, anthologies can also be assembled as selection of the "best" literature or "representative" (as determined by the compiler), and collections can be assembled as "comprehensive" (regardless of quality) or as "focused" (narrow subject).
There is no hard and fast distinction in the terms, but generally an anthology is not assembled by the author(s); covers multiple authors; and was assembled by the compiler with some theme, form, or genre in mind, without regard to the source nor original context of the works. --EncycloPetey (talk) 17:13, 25 November 2018 (UTC)
I see. However, the Wiktionary quotation at the top of Category:Anthologies stated just: An anthology is a collection of literary works such as poems or short stories, which was quite confusing. The proof that people were confused was that two out of five publications included in this category have only one author ( Earth-Hunger and Other Essays and Miscellaneous Poems to 1920. So I have rewritten the introduction to the category as follows: This category includes collections of works by multiple authors. For collections of works by a single author see Category:Collections.
Another possibility would be merging the categories because of lack of simple distinction. --Jan Kameníček (talk) 17:31, 25 November 2018 (UTC)
There is value in distinguishing between a collection and an anthology. The lack of coordinated curation in our categories is not limited to these two examples. Wikisource categorization has typically taken a low-priority here. Many (most?) works lack proper categorization, and most categories have not been tidied in ages.
Note: There are also some works that resemble anthologies or collections, but are most often treated as a single work. The Hebrew Bible was written by multiple authors over an extended period, and assembled by compilers, but is generally treated as a single work by virtue of the relative stability of the component works over a long period. Virgil's Eclogues are a borderline case between a collection and a work. They are always printed together and have a set number and sequence. --EncycloPetey (talk) 17:13, 25 November 2018 (UTC)
Works like Slavonic Fairy Tales would probably qualify as a Collection. The tales are not reprinted works from other authors, but are being told by the author of the book. Anthologies collect published works, without creative effort from the compiler. Arts and Crafts Essays would probably fit better as a collection because the essays were written for a specific event; they were not compiled later, but were purposely dedicated by the authors who knew the essays would be collected. --EncycloPetey (talk) 17:39, 25 November 2018 (UTC)
Slavonic Fairy Tales/The Wicked Wood-Fays is a tale by K. J. Erben, while Slavonic Fairy Tales/The Wise Judgment is by J. Košín z Radostova, so I thought the book should fall under Anthologies. --Jan Kameníček (talk) 17:45, 25 November 2018 (UTC)
Ah, the title page did not make that clear. If these are works by particular authors, then Anthology is a better description. --EncycloPetey (talk) 17:50, 25 November 2018 (UTC)

Johanna Strodt (WMDE) (talk) 10:57, 26 November 2018 (UTC)

Community Health Metrics Kit consultation

This message is also available in other languages.

The Community Health Metrics Kit is a new project to measure more aspects of our communities. If you are interested in metrics, statistics, and measurement of editing and contributing, please join us on Meta to discuss how and what the new project should measure! JSutherland (WMF) (talk) 19:21, 26 November 2018 (UTC)

Some of the metrics will not apply to projects like Wikisource, Wikiquote, Wikispecies, or Wiktionary. The last three do not have any "biographies" to count for the "gender bias" metric. It looks as though this metrics project is geared primarily towards looking at Wikipedias, and will not apply elsewhere. --EncycloPetey (talk) 01:36, 27 November 2018 (UTC)

22:23, 26 November 2018 (UTC)

{{DISPLAYTITLE}}

I have questions about the ignorance of {{DISPLAYTITLE}} here. The greatest question is would be the reason(s) for the ignorance...--RaboKarbakian (talk) 15:37, 30 November 2018 (UTC)

Your question makes no sense. Templates cannot be ignorant nor informed. They are inanimate objects. --EncycloPetey (talk) 16:11, 30 November 2018 (UTC)
Category:Pages with ignored display titles. Ignorance. A verb. --RaboKarbakian (talk) 16:41, 30 November 2018 (UTC)
Your question still makes no sense. Also, ignorance is a noun. --EncycloPetey (talk) 16:48, 30 November 2018 (UTC)
Software activated. I get the creeps using punctuation in filenames (having managed files on my computer and for web display), and not all punctuation that occurs in titles are allowed as filenames. DISPLAYTITLE fixes many actual problems and my creepy feelings, yet it has been de-activated here. --RaboKarbakian (talk) 16:56, 30 November 2018 (UTC)
I have fixed the page you were having trouble with. I cannot help you with your feelings. If you will follow community norms, this sort of problem can be easily avoided. --EncycloPetey (talk) 17:06, 30 November 2018 (UTC)
@RaboKarbakian: We will not change our naming conventions based on creepy feelings. If you have examples of actual problems we can discuss actual problems. We have had no need to modify the title display of page titles, nor are we likely to in future. —Beleg Tâl (talk) 17:10, 30 November 2018 (UTC)
I was not having a problem with it, beyond my lack of understanding of reasons for it being disabled here. There must be at least one good reason(?)... --RaboKarbakian (talk) 17:15, 30 November 2018 (UTC)
But that isn't what your "question" said, was it? You demanded the community explain ignorance to you. We have done that; the ignorance was your own. You now know how to avoid the problems you were creating for yourself. The "new" version of the question was answered before you posted your question. --EncycloPetey (talk) 17:28, 30 November 2018 (UTC)
@EncycloPetey: Their original question was poorly phrased: "Why is there ignorance of DISPLAYTITLE on Wikisource" should be read as "Why does Wikisource [software, not userbase] ignore the DISPLAYTITLE tag". It is the same question. —Beleg Tâl (talk) 19:55, 30 November 2018 (UTC)
Speaking of this, does anyone have an objection to me deleting {{DISPLAYTITLE}} which is not used and is easily confused with the Magic Word {{DISPLAYTITLE:}} ? —Beleg Tâl (talk) 17:12, 30 November 2018 (UTC)
None, though you may wish to (a) post in the Deletions page for proper process, and (b) delete {{Trim2}} as well, which was created at the same time by the same User. --EncycloPetey (talk) 17:14, 30 November 2018 (UTC)
@RaboKarbakian: I believe I have solved the mystery. The DISPLAYTITLE magic word is not disabled. However, it only works if the displayed title is the same canonical form as the actual page title. Replacing ' with does not result in the same canonical form, so the DISPLAYTITLE was ignored when you tried to use it in that way. —Beleg Tâl (talk) 20:17, 30 November 2018 (UTC)
@Beleg Tâl: this: commons:Category:HMS Terror (ship, 1813)! Maybe I could have used "’". ((i'll read the docs. . . .)) --RaboKarbakian (talk) 23:38, 30 November 2018 (UTC)

Slow loading of scan

Am I the only one who is recently suffering slow loading of scans when creating new pages? It does not happen very often, but at random moments the scan does load very slowly, or not at all. I think this happens more, in the last few weeks, than before. Do other users experience the same problem? --Dick Bos (talk) 17:23, 28 November 2018 (UTC)

From time to time, I have the same issue. Because I have needed few scans for the past few days, I cannot say whether it is a problem for me now. --EncycloPetey (talk) 18:34, 28 November 2018 (UTC)
I have experienced this problem too. --Jan Kameníček (talk) 22:41, 28 November 2018 (UTC)
You can try Zdzislaw's gadget that I use in my common.js (first line). It preloads the next page image while in edit mode. IMO, this speeds up loading significantly. Ankry (talk) 22:36, 30 November 2018 (UTC)
Thank you @Ankry. I installed the tool. But the thing is that in larger projects I often do all the odd pages, and then all the even pages, so then the tool is of no use. --Dick Bos (talk) 18:56, 1 December 2018 (UTC)
@Dick Bos: Not exactly: after you process all the odd pages, all the even should load fast :) Alternatively, you can try to preload all images for the book (1024px wide unless there are non-standard settings or the first page has lower res.) in a batch job. I noticed that most time is spent to generate images from djvu; If they have already been generated (maybe, by sb else request) and are cached on servers, they should load fast. Ankry (talk) 20:03, 1 December 2018 (UTC)

wgMaxArticleSize

Working on transclusion for the current POTM (Confederate Military History, vol. 3), there's one section which spans over half the book: Confederate Military History/Volume 3/Biographical. Currently the page transcludes 630 pages and hits the post‐expand include size of 2MB, leaving a number of links at the bottom untranscluded.

 NewPP limit report
 Parsed by mw1335
 Cached time: 20181127051932
 Cache expiry: 1900800
 Dynamic content: false
 CPU time usage: 2.804 seconds
 Real time usage: 4.763 seconds
 Preprocessor visited node count: 49817/1000000
 Preprocessor generated node count: 0/1500000
 Post‐expand include size: 2097152/2097152 bytes
 Template argument size: 67171/2097152 bytes
 Highest expansion depth: 8/40
 Expensive parser function count: 3/500
 Unstrip recursion depth: 1/20
 Unstrip post‐expand size: 2072395/5000000 bytes
 Number of Wikibase entities loaded: 0/400
 Lua time usage: 0.046/10.000 seconds
 Lua memory usage: 1.61 MB/50 MB

Is there any way to increase the $wgMaxArticleSize variable by the server admins? -Einstein95 (talk) 05:33, 27 November 2018 (UTC)

Sidestep the problem. Why be so greedy as to include all of the Biographical section as a single, indigestible lump? Better by far to break it into sub-chapters at every major name change (hint: look for the embedded {{dhr}}s!) 114.74.56.136 08:06, 27 November 2018 (UTC)
Because that's not how it is done in the ToC. Plus if I was to divide it, who would get the images? -Einstein95 (talk) 20:00, 27 November 2018 (UTC)
My own sidestep would be to split by first letter and use an alpha TOC template. Remember we don't have to slavishly reproduce a printed work. It's more important to make the work accessible. Beeswaxcandle (talk) 05:51, 28 November 2018 (UTC)
Best practices and workarounds aside, who is actually able to modify this value? Can we do it, would we have to go through Phabricator, or what? Just curious. —Beleg Tâl (talk) 13:32, 28 November 2018 (UTC)
Phabricator. Hoping, that you will be more lucky than our, pl.ws attempt over a year ago at phab:T158242. So good luck! Ankry (talk) 23:01, 30 November 2018 (UTC)
And note, that the page mentioned in this ticket works now because we use page code substitution (see the talk page for details). This way we may raise the real limit to about 4MB (2MB trancluded + 2MB "raw" wikicode), but the cost is that the main ns. page content is not updated automatically when the Page ns. content is modified (actually a bot does the job now). Ankry (talk) 23:14, 30 November 2018 (UTC)
Right. We've run into this issue before -- though it usually shows up with super complicated templates like the old TOC templates. The powers that be don't seem to be too keen on bumping the limit. That being said, I support IP 114.74.56.136's suggestion that we impose an artificial structure onto the section -- eg. /Biogaphical/A, /Biographical/B. The TOC would, of course, still link to /Biographical. We've done this in other places and for other kinds of works as well. --Mukkakukaku (talk) 17:59, 2 December 2018 (UTC)

Disambiguating Shakespeare

Anyone who has looked through our current coverage of Shakespeare's plays will have noticed that it's an execrable mess right now. Most of our copies are not backed by scans, and our Versions pages have lengthy titles, if they exist at all. Multiple transcription projects exist for some plays, but usually in various stages of neglect.

The 400th anniversary of the publication of the First Folio is 2023, and this date may bring interested individuals to Wikisource. It seems only right to at least organize what we have, and set things up to make it easier to find transcription projects and various editions of plays.

Toward that end I did some poking around last night to see where things stand. The first big hurdle is that our Disambiguation and Versions pages associated with titles like "Hamlet" and "Macbeth" are in bad shape and have not been edited in a long time. I am willing to put in the work to clean up these pages, but want to establish a standard for the naming of these pages. Because some of them have been around for a long time, and because of the high-profile nature of Shakespeare's plays, I am putting forward a proposal backed by a few case studies before proceeding.

Case studies for three of Shakespeare's tragedies
Title of Play (LoC) current versions page sample titles

Hamlet Hamlet (Shakespeare) The Tragedie of Hamlet, Prince of Denmarke

The Tragedy of Hamlet, Prince of Denmark
Hamlet, Prince of Denmark: A Tragedy
The Tragedy of Hamlet
Hamlet, Prince of Denmark


King Lear none The Tragedie of King Lear

The Tragedy of King Lear
The Chronicle History of the Life and Death of King Lear and His Three Daughters


Romeo and Juliet The Tragedy of Romeo and Juliet The Tragedie of Romeo and Ivliet

The Tragedy of Romeo and Juliet
The Most Excellent and Lamentable Tragedie of Romeo and Iuliet
Romeo and Juliet


As can be seen from the case studies, there is no uniformity of titles for these three plays. Not only is there significant variation in spelling and overall title length, but even structure and form of the titles vary. Therefore, it seems to me that selecting one particular spelling, or one specific title, to represent all forms of any given play would be neither helpful nor intuitive.

Furthermore, doing so would also eliminate the possibility of hosting an edition with that title at that location, and would preclude the possibility of a disambiguation or versions page for that title. That is, if there were more than one work titled "The Tragedy of Romeo and Juliet", possibly a work about the play in addition to editions of the play itself, we would have no means of disambiguating these titles if the Versions page for the play was located at that title.

I therefore propose that all of Shakespeare's plays be given versions pages of the form:

(1) Macbeth (Shakespeare), for most plays, where the simple title adheres to the common base name used for his plays in the Library of Congress database, instead of a longer title such as The Tragedy of Macbeth.
(2) Henry IV, Part 3 (Shakespeare) for the historical plays. For these latter plays, the Library of Congress includes "King" in the title and separates the "Part" with a period instead of a comma. The result of having this full stop within the play's name causes some odd rendering on VIAF. Wikidata avoids the problem by using a comma, which is standard for most bibliographic references I have seen, including the Pelican Shakespeare. The Cambridge Shakespeare uses neither a period nor a comma, and the Riverside Shakespeare uses the confusing form 3 Henry VI to abbreviate the same title. The Yale Shakespeare spells the title out in full as The Third Part of King Henry the Sixth.

This proposal has the additional advantage of not forcing a move of any existing copies of plays to make way for a Versions page.

I set up Hamlet (Shakespeare) yesterday as an example of how I imagine the Versions pages ought to look.

Support and comments are welcome. But if there are no serious objections, and a general positive view of my proposal, I will begin work this coming weekend to clean up the Versions and Disambiguation pages associated with titles of Shakespeare's plays. --EncycloPetey (talk) 02:54, 27 November 2018 (UTC)

 Support, this is entirely reasonable and would be a great improvement. —Beleg Tâl (talk) 04:22, 27 November 2018 (UTC)
A question: are you proposing to standardise all of them with the (Shakespeare) disambiguator, or only those that share a title with other works on this site? —Beleg Tâl (talk) 04:24, 27 November 2018 (UTC)
We already have Reference works with entries for Shakespeare's plays (vide Characters of Shakespear's Plays as an example), and almost every play has at least one commentary, retelling, or derived work with the same or nearly the same title. It seems preferable to go ahead with (Shakespeare) now, rather than having to move those pages again later. Shakespeare's plays are of sufficient stature that I think we ought to select stable locations for the Versions pages. --EncycloPetey (talk) 04:32, 27 November 2018 (UTC)
 Support, after seeing the example disambig set up, it saves everything from getting more and more cluttered and lost. -05:23, 27 November 2018 (UTC)
 Support and take it on over to wikidata as well. (which i see you have dome) Slowking4SvG's revenge 17:16, 29 November 2018 (UTC)
 Support. I've been holding off chiming in here for various reasons, despite otherwise having an opinion on almost anything related to Shakespeare, but having had a little bit of time to think about it I've landed on a tentative position. I definitely support a cleanup of this, and that's irrespective of the details of the approach. Any consistent approach is better than the existing mess. I'm less sure about the details of the new approach, both because I've not thought very deeply about it; because I am not sufficiently experienced with the needs and factors applying on Wikisource; and because I have a lot of enwp baggage that could easily lead me astray here. However, with those caveats, and having had the chance to try it out slightly, I tentatively also support the specific approach sketched above. I would only add that where (if) the LoC title differs from enwp's naming, it's a good idea to at least consider enwp's article title (they've been subject to lots of wide discussion; but with the downside that the discussions relate to enwp's needs and naming conventions). I would also suggest that the history plays have redirects at the title variants: Henry IV, Part 3 (Shakespeare), Henry IV. Part 3 (Shakespeare), Henry IV., Part 3 (Shakespeare), and 3 Henry IV (Shakespeare). All are common variant spellings for these (you'll even find "3HIV" in the literature). The full-stop isn't there really a separator, but a ordinal suffix for the regnal number: "Henry V." is essentially "Henry 5th". You'll find the full-stop used thus in running text: "Henry V. was king of England". --Xover (talk) 07:52, 19 December 2018 (UTC)
Agreed. Where there are title variants, I have been creating redirects except that Wikisource has a problem that Wikipedia does not have: the possibility of editions claiming one or more of those variant titles for a specific edition. Where this happens, I am using {{other versions}} to create a link back to the Versions page. And yes, I am familiar with the use of a full stop for regnal ordination; I've worked in several of our encyclopedic works which use that notation. But using Wikipedia article names would not be feasible. Wikipedia has very different criteria and processes for naming. For example, they have Hamlet at w:Hamlet, which would not work for Wikisource, as we need a disambiguation page for all works titled Hamlet, and they put Julius Caesar at w:Julius Caesar (play) on the assumption that there is only one play by that name. It is not that Wikipedia names have been dismissed out of hand, but they are working to a very different set of rules and expectations that simply do not translate to the needs of Wikisource. --EncycloPetey (talk) 16:09, 1 January 2019 (UTC)