Wikisource:Scriptorium/Archives/2018-11

From Wikisource
Jump to navigation Jump to search
Warning Please do not post any new comments on this page.
This is a discussion archive first created in , although the comments contained were likely posted before and after this date.
See current discussion or the archives index.

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)

Tech News: 2018-45

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

Recent changes

Changes later this week

  • You can choose to see edit conflicts in a two-column view. This is a beta feature. You can find it in your preferences. The interface for the two-column edit conflict will change. You can read more.
  • When you edit with the visual editor you can use the "Automatic" citation tab. This helps you generate citations. You will now be able to write plain text citations or the title of a journal article or a book in this tab. This will search the Crossref and WorldCat databases and add the top result. [2]
  • Recurrent item The new version of MediaWiki will be on test wikis and MediaWiki.org from 6 November. It will be on non-Wikipedia wikis and some Wikipedias from 7 November. It will be on all wikis from 8 November (calendar).

Meetings

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

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)

Tech News: 2018-46

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

Recent changes

  • Some old mobile browsers can use the watchlist again. This has not worked for a while. These browsers are called grade C browsers. This helps for example Windows Phone 8.1 with Internet Explorer and Lumia 535 with Windows 10. [4]

Problems

  • You can choose to see edit conflicts in a two-column view. This is a beta feature. You can find it in your preferences. Users who use this view saw the edit conflict resolution page when they wanted to see a preview. This has been fixed. [5][6][7]

Changes later this week

  • Recurrent item The new version of MediaWiki will be on test wikis and MediaWiki.org from 13 November. It will be on non-Wikipedia wikis and some Wikipedias from 14 November. It will be on all wikis from 15 November (calendar).

Meetings

Future changes

  • You can use the content translation tool to translate articles. The developers are working on a new version. One of the changes will be a maintenance category. Articles where users add a lot of text from machine translation without changing it will be in that category. This is so the community can review it. The users will also have been warned before they publish the article that it has a lot of unchanged text from machine translations. [8]

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

19:22, 12 November 2018 (UTC)

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

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

Please help translate to your language

Example of improvements

Hello,

In a few weeks the Readers web team will be changing how some templates look on the mobile web site. We will make these templates more noticeable when viewing the article. We ask for your help in updating any templates that don't look correct.

What kind of templates? Specifically templates that notify readers and contributors about issues with the content of an article – the text and information in the article. Examples like Template:Unreferenced or Template:More citations needed. Right now these notifications are hidden behind a link under the title of an article. We will format templates like these (mostly those that use Template:Ambox or message box templates in general) to show a short summary under the page title. You can tap on the "Learn more" link to get more information.

For template editors we have some recommendations on how to make templates that are mobile-friendly and also further documentation on our work so far.

If you have questions about formatting templates for mobile, please leave a note on the project talk page or file a task in Phabricator and we will help you.

Thank you!

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)

Tech News: 2018-47

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

Recent changes

  • You can vote on proposals in the Community Wishlist Survey. The survey decides what the Community Tech team will work on. You can vote until 30 November.
  • Advanced item There is an A/B test for sameAs data. This is to make it easier to find the right information with a search engine. This changes the metadata for a wiki page. It doesn't change how the page looks. [9]

Changes later this week

  • There is no new MediaWiki version this week.

Meetings

Future changes

  • The Wikimedia wikis use templates to show readers there are problems with the content on some pages. For example if there are no sources or the page needs to be rewritten. The mobile website will soon show more information when you use these templates. Some templates may need to be updated. [10]
  • The Education Program extension was removed from all Wikimedia projects. The database tables used by the extension will be archived. This will happen in a month. If you want the information on your wiki you should move it to a normal wiki page. [11]

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

23:28, 19 November 2018 (UTC)

Community Wishlist Survey vote

The Community Wishlist Survey. Please help translate to your language.

Hey everyone,

The Community Wishlist Survey is the process when the Wikimedia communities decide what the Wikimedia Foundation Community Tech should work on over the next year.

The Community Tech team is focused on tools for experienced Wikimedia editors. The communities have now posted a long list of technical proposals. You can vote on the proposals from now until 30 November. You can read more on the wishlist survey page.

/User:Johan (WMF)

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. Slowking4 ‽ SvG'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. Slowking4 ‽ SvG'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. Slowking4 ‽ SvG'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)

Advanced Search

Advanced Search will become a default feature on your wiki on November 28. This new interface allows you to perform specialized searches on the search page, even if you don’t know any search syntax. Advanced Search originates from the German Community’s Technical Wishes project. It's already a default feature on German, Arabic, Farsi and Hungarian Wikipedia. Besides, more than 40.000 users across all wikis have tested the beta version. Feedback is welcome on the central feedback page.

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)

Tech News: 2018-48

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

Recent changes

  • On wikis with translatable pages you could create a mess when you moved a page that had translatable subpages. A subpage is when you use / to create a new page: /wiki/Page/Subpage. The subpages would be moved but not the translations. The subpages are no longer automatically be moved. This is to make it safer to move pages. [14]

Changes later this week

  • The advanced search interface will be available by default on all Wikimedia wikis. It makes it easier to use some of the special search functions that most editors don't know exist. It's already active on German, Farsi, Arabic and Hungarian Wikipedia. [15]
  • Special:UnusedCategories show empty categories with no files or other categories. You can soon choose to not show soft redirect categories or some maintenance categories there. You can do this with the magic word __EXPECTUNUSEDCATEGORY__. [16]
  • Recurrent item The new version of MediaWiki will be on test wikis and MediaWiki.org from 27 November. It will be on non-Wikipedia wikis and some Wikipedias from 28 November. It will be on all wikis from 29 November (calendar).

Meetings

Future changes

  • Advanced item The mw.util.jsMessage() function was deprecated in 2012. It will be removed next week. Look for the warning Use of "mw.util.jsMessage" is deprecated in the JavaScript console to know if you use an affected script or gadget. If you are a gadget maintainer you should check if your JavaScript code contains mw.util.jsMessage. There is a migration guide. It explains how to use mw.notify instead. [17]

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

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) Slowking4 ‽ SvG'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)
Retrieved from "https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium/Archives/2018-11&oldid=9081281"