Wikisource:Scriptorium

From Wikisource
Jump to navigation Jump to search
Scriptorium
The Scriptorium is Wikisource's community discussion page. Feel free to ask questions or leave comments. You may join any current discussion or start a new one; please see Wikisource:Scriptorium/Help. Project members can often be found in the #wikisource IRC channel webclient. For discussion related to the entire project (not just the English chapter), please discuss at the multilingual Wikisource. There are currently 328 active users here.

Contents

Announcements[edit]

Proposals[edit]

Bot approval requests[edit]

Repairs (and moves)[edit]

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

Missing and duplicated pages in the Yale 3 Henry 6[edit]

In Index:Henry VI Part 3 (1923) Yale.djvu, pp. 122 and 123 are missing, replaced with duplicates of pp. 120 and 121. HathiTrust has two Google scans of this edition—#1 and #2—with the pages intact (if with Google's usual poor scan quality). Help? (@EncycloPetey: FYI)

PS. Apart from this snag, good progress is being made on Portal:The Yale Shakespeare. Most of the history plays have been proofread and are awaiting validation—*cough* hint *cough* :)—and a large part of the rest are already set up with an index, pagelist, some formatting guidelines, etc.; and EncycloPetey has done a near-miraculous job of finding good clean scans to proofread from. --Xover (talk) 08:56, 13 March 2019 (UTC)

@Xover:, no point in dropping hints here when we have WikiProject Validate/Noticeboard (WS:WPV/N). I actually do check to see what's posted there. I'd love if more people started using it, but that's just me. I'll get started on it now, but a post there to let others know wouldn't hurt! :D –MJLTalk 00:57, 20 March 2019 (UTC)
@MJL: Thanks, I wasn't even aware it existed. But in this particular instance I was just sneaking in a little nudge when the opportunity presented itself by way of having something else to post here. Your efforts at getting more pages here greened is very much appreciated! --Xover (talk) 15:17, 21 March 2019 (UTC)
@Xover: I take whatever opportunity to plug WS:WPV that I can get! I totally feel you though. The struggle is real :D –MJLTalk 15:23, 21 March 2019 (UTC)

Done. I bit the bullet and delved into the arcana of DjVuLibre. New file uploaded that seems to fix this (unless I messed anything else up along the way). And found task T219376 while I was at it. It may be of interest to others poking around the guts of .djvu files. Short version: djvu files with pages that have invalid hidden text layers will confuse MediaWiki and lead to OCR text being offset by the same number of pages as had invalid hidden text. Simply removing the hidden text (djvused 'select <page>; remove-txt; save') seems to do the trick is the page contains no OCR text worth salvaging. --Xover (talk) 13:07, 27 March 2019 (UTC)

Replace OAW Vol 3?[edit]

The existing scan for Once a Week Volume 3 is pretty poor; would it be too much work to replace it with this Google Books scan instead? Levana Taylor (talk) 07:06, 15 March 2019 (UTC)

I can't see the file. If the offset betwen old vs. new is constant for most pages, it is not a huge work. Pls check and upload the file if you want that file. Please post here also the offset to move current pages to new position (e.g offset +N, page xxx +> xxx + N).— Mpaa (talk) 21:09, 25 March 2019 (UTC)
PDF uploaded at File:OAW Ser 1 Vol 3.pdf. There is no difference in page numbering from the old version. Levana Taylor (talk)
How do you link the file to the index? Levana Taylor (talk) 01:17, 27 March 2019 (UTC)
The link is automatic based on using the same name in both places. When uploading a new version of a file, upload it over the top of the old version rather than as a new file name. Beeswaxcandle (talk) 01:23, 27 March 2019 (UTC)
@Levana Taylor: I saw this, but would it not have been simpler to just re-upload the file to File:ONCE A WEEK JUL TO DEC 1860.pdf and then simply nominate the duplicate for speedy deletion? –MJLTalk 03:06, 27 March 2019 (UTC)
Maybe, except it's Commons policy that you should only replace a file with an altered version of the same file. Being as this is a whole different scanned book, I think we should keep both files. So, shift the old one to a different name. Levana Taylor (talk) 07:45, 27 March 2019 (UTC)

An Exposition of the Old and New Testament (1828) (Matthew Henry)[edit]

Further to Wikisource:Scriptorium/Archives/2017-02#An_Exposition_of_the_Old_and_New_Testament_(1828)_(Matthew_Henry) I have just discovered that DJVU 1 skips from page v to page viii at [Page:An_Exposition_of_the_Old_and_New_Testament_(1828)_vol_1.djvu/15]. I'm surprised at this, as I did some checking of that section in Feb 2017. Can anyone help, or do I have to approach Princeton for the pages and then get someone to reorganize the text? PeterR2 (talk) 09:48, 18 March 2019 (UTC)

If you can find an image for the missing age it can be inserted the djvu and the pages reorganized. Pages in Main ns. wil have to be realigned accordingly.— Mpaa (talk) 21:15, 25 March 2019 (UTC)

Pindar (Way 1922)[edit]

I have uploaded File:Pindar in English Verse (Way 1922).djvu to Commons, only to discover that it is missing two pages (p. 158–159) near the end of the volume.

Please, could someone pull copies of those pages from (external scan), and insert them into the correct position within File:Pindar in English Verse (Way 1922).djvu, to correct the file on Commons? --EncycloPetey (talk) 01:27, 26 March 2019 (UTC)

@EncycloPetey: Done. It looks like everything is good now, but please do a sanity check before proofreading to make sure I didn't mess anything up. --Xover (talk) 07:07, 11 April 2019 (UTC)

Missing pages in OAW Volume 7[edit]

In the scan for Once a Week Volume 7, two pages (pp. 629-630 of the magazine, pp. 637-638 of the scan) are missing. They are omitted from the source Internet Archive file, but may be taken from Google Books. Could someone please fix this? Thanks! Levana Taylor (talk) 23:40, 31 March 2019 (UTC)

Page disorder in Tales of my Landlord - 3rd series, vol. 1[edit]

Hello, In Index:Scott - Tales of my Landlord - 3rd series, vol. 1 - 1819.djvu, pages are not in the expected order: pages 65 and 66 are just after page 56. All pages are there, only 2 pages to move. If someone could help me in fixing the djvu, I'll move the 10 OCR. Thanks in advance. --M-le-mot-dit (talk) 14:00, 6 April 2019 (UTC)

Done. Nothing else is to be done.— Mpaa (talk) 20:21, 9 April 2019 (UTC)
Good. thanks, Mpaa. M-le-mot-dit (talk) 05:09, 13 April 2019 (UTC)

Links to scan pages missing[edit]

I have noticed that only 3 out of 19 pages of Siberia and the Exile System/Volume 2/Index (page no. 557, no.561 and no. 571) appear in the left margin. What can this be caused by? --Jan Kameníček (talk) 20:27, 14 April 2019 (UTC)

@Jan.Kamenicek: Without digging too deeply into it, I would guess it is either a variant of the problem discussed in WS:S/Archives/2018-08#Page numbers borked with hyphenated words or a variant of that problem caused by the pages being just one long table (see the older discussion linked from the 2018 discussion). I had intended to pursue a possible workaround, but there seemed to be little interest and quite a bit of general cleanup needed to the scripts before such workarounds could be safely tested (which is right now hampered by there not being any Interface Administrators on enWS, and no process for getting anybody assigned the bit, cf. #A process and policy for Interface Admins below). --Xover (talk) 04:37, 15 April 2019 (UTC)
My experience is that the appearance of this problem varies by OS and browser, so it may not be a simple a fix. --EncycloPetey (talk) 04:42, 15 April 2019 (UTC)
@EncycloPetey: I tried it with Firefox and Chrome and then again from a different computer at a different place again with Firefox and Chrome (and I suppose the versions of browsers are different although I did not check them at the previous one), and the problem is the same. --Jan Kameníček (talk) 06:10, 15 April 2019 (UTC)
When I have encountered this problem, I have sometimes found that Firefox on a Mac versus Chrome on a PC can yield different results. --EncycloPetey (talk) 14:19, 15 April 2019 (UTC)

Other discussions[edit]

Wikisource Community User Group representative vote[edit]

Dear all,

Sorry for writing in English and cross-posting this message.

Following the previous message, the vote for the representative of the Wikisource Community User Group to the Wikimedia Summit 2019 is now open.

There is two great candidates on page on meta to decide who will be the representative of the user group to the Wikimedia Summit. You can support a candidate now. All active Wikisource users can vote. The vote is ending on December 14, 2018.

Feel free to ask any question on the wikisource-I mailing list or on the talk page.

Thank you!

For the Wikisource Community User Group, Tpt (talk) December 8, 2018 at 18:53 (UTC)

Biographies with no UIDs[edit]

The page I have created at Wikisource:Biographies with no identifiers contains a Wikidata query which returns a list of people with a Wikisource page, but with no UIDs (VIAF, ISNI, ORCID, etc) on Wikidata - in other words, if {{Authority control}} is used on their biography, it will have no content.

There are currently 2,230 people in the list.

[Caveat: a few of those pages are in the form Woman of the Century/Ada Iddings Gale; not in Author: namespace; should they be linked from Wikidata, as on Q41171030 (Q41171030)?] Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:10, 18 March 2019 (UTC)

Works on Wikisource, including subpages of Woman of the Century, should not be linked to Wikidata items representing people. Wikidata has properties that can be used for connecting the person-item to the work-about-person-item, that should be used instead. —Beleg Tâl (talk) 20:57, 18 March 2019 (UTC)
I've raised the issue on Wikidata: d:Project chat#Incorrect Wikisource links. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:51, 18 March 2019 (UTC)
@Pigsonthewing: That link points to a page that does not exist. I believe you meant d:Wikidata:Project chat#Incorrect Wikisource links --EncycloPetey (talk) 01:51, 19 March 2019 (UTC)
the fact that wikisource has individuals without authority control id’s is good. (author or subject of a biography) need to add them as notable wikidata people, even if they never produced a work in a library. Slowking4SvG's revenge 11:06, 19 March 2019 (UTC)
I can't parse half of that, but why is it good to not have authority control IDs? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:17, 19 March 2019 (UTC)
because you have to gather in the messy data before you can improve it. and need to clarify the ontology of depicted people. the fact that depicted people do not have authority control ID’s means they are not in someone else’s database, but we are now constructing an id in our database. Slowking4SvG's revenge 13:05, 20 March 2019 (UTC)
The fact that no Authority ID is present in Wikidata does not mean there is no authority data in any database. The point here is that we need a means to (a) identify which persons have a biography on WS, but lack an Auth. ID on Wikidata, and (b) determine whether or not there is an Auth. ID to be found in the various online databases, which can then be added. This requires (c) some means of correctly matching persons with records in other databases. --EncycloPetey (talk) 17:18, 20 March 2019 (UTC)
a- the query did it, but a more built-out depicts ontology would be better; b- the online databases are there already, the national libraries’ authority control data was ingested years ago, doubt you will find them in copyrighted or off-line databases; c- sounds like a task for mix or match, if you could find other data. in the meantime, need to create item based on wikisource depicts / subject of bio data. -- Slowking4SvG's revenge 12:29, 26 March 2019 (UTC)
Your statement on (a) is only partly correct. I am constantly finding VIAF, LoC, BnF, and GND data matches that have not been added to Wikidata. We are also constantly adding new Author pages to Wikisource. So what happened years ago is irrelevant when we have new pages created here. For some of the Author pages I have added, there was no data item on Wikidata, and I have had to create these, even as recently as a month ago. So we may have ingested all the data for existing Wikidata items, but as new items are created, we still have to go find UIDs. There are still many, many authors with UIDs on public databases (VIAF, LoC, BnF, etc) for which no Wikidata item yet exists --EncycloPetey (talk) 13:35, 26 March 2019 (UTC)
Yes, thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:17, 19 March 2019 (UTC)
Sorry with my first (or 2nd) question on Scriptorium but maybe this is the place where my question should be posted. (I'm never sure) So, an author does not exist on Wikidata or here and where should he exist or be created first? See my discussion with myself about it here on my talk page. Thank you.--Level C (talk) 16:45, 21 March 2019 (UTC)
If the person is an Author, then you create the Author page here first, then create a Wikidata item. Once the WD item exists, you link to the WS Author page from Wikidata. --EncycloPetey (talk) 17:11, 21 March 2019 (UTC)
OK. Thank you much! I'll try to create it here soon. --Level C (talk) 17:25, 21 March 2019 (UTC)

Problem with Once a Week volume 10 index[edit]

The index page for Once a Week volume 10 seems to be damaged -- what happened to the file? Levana Taylor (talk) 02:48, 25 March 2019 (UTC)

It got deleted from Commons by commons:User:Túrelio because it "has nothing to do with Betty Bossi AG" (whatever that means). I have requested undeletion. —Beleg Tâl (talk) 12:58, 25 March 2019 (UTC)

Redirects within an original published work[edit]

In some works, most commonly encyclopedias and dictionaries, a section or listing will only exist to redirect to another section or listing. In such cases, I have generally transcluded what is there, to allow the page to function as essentially a {{soft redirect}}. Examples include:

Do other editors have other methods that they prefer to use when handling such pages? —Beleg Tâl (talk) 13:59, 25 March 2019 (UTC)

I'm doing the same with the Grove Dictionary of Music. See Category:DMM article redirects for examples. I do note that in volume 1 of CE1913 previous editors have simply ignored these and didn't include them in the listings on Catholic Encyclopedia (1913)/Volume 1. Beeswaxcandle (talk) 17:29, 25 March 2019 (UTC)

Tech News: 2019-13[edit]

18:05, 25 March 2019 (UTC)

Text size in the edit box[edit]

How can the font size in the edit box be increased? The idea isn't to enlarge the whole webpage, just the characters that appear in the edit box. I would expect this to be in Preferences, but cannot seem to find it. Thanks, Dovi (talk) 16:48, 26 March 2019 (UTC)

@Dovi: You'd have to use custom CSS: go to Special:MyPage/common.css and add a line .wikiEditor-ui textarea { font-size:larger; } (or whatever your preference is) —Beleg Tâl (talk) 17:47, 26 March 2019 (UTC)
Thank you so much Beleg Tâl! What are the specific options (besides "larger")? Dovi (talk) 05:09, 27 March 2019 (UTC)
@Dovi: see https://developer.mozilla.org/en-US/docs/Web/CSS/font-sizeBeleg Tâl (talk) 12:14, 27 March 2019 (UTC)
Thanks so much Beleg Tâl! Dovi (talk) 12:56, 27 March 2019 (UTC)

Handle System[edit]

I propose the addition of Handle System identifiers to {{Cite book}}; please see Template talk:Cite book#Handle System. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:20, 27 March 2019 (UTC)

Symbol oppose vote.svg Oppose based on what I see. If the purpose is to show multiple offsite links to various databases, then perhaps we could instead use a single Wikidata value, and store all other values on Wikidata instead of displaying them locally? The results of what you've done make the primary citation very difficult to read, and will detract from the purpose of the Author pages, which is to link to works hosted on Wikisource. --EncycloPetey (talk) 15:03, 27 March 2019 (UTC)
What exactly have I "done" to "make the primary citation very difficult to read"? The template currently displays at least there external IDs (OCLC, doi, JSTOR); I am simply proposing that we include another, which is widely used. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:23, 27 March 2019 (UTC)
You have plastered {{Cite book}} all over an Author page. The resulting multiple blue links and arrows all over the page have made it hard to read the citations. We don't use {{Cite book}} on Author pages. It's intended purpose is for use on the Talk pages of works in the Main namespace to identify the source of a single work. --EncycloPetey (talk) 15:42, 27 March 2019 (UTC)
Funny; I read all the documentation for the template, on this project, and can find no mention of that intention. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:54, 27 March 2019 (UTC)
Documentation here is sporadic and often outdated or wrong. We are a much smaller community than most other projects, and members seldom take the time to document templates. If you find documentation that isn't up to snuff, you can always improve it. --EncycloPetey (talk) 16:18, 27 March 2019 (UTC)
I have no interest in abusing template documentation to suggest a practice is incorrect, when that suggestion is clearly not supported by current reality. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:53, 27 March 2019 (UTC)
You're linking without reading. What you're seeing are links in the References sections on Author pages, not links to specific works. Please look at what is happening, instead of presenting misleading statistics. I know you're new, and having trouble adapting, but please take the time to look at what's actually going on instead of assuming. --EncycloPetey (talk) 17:41, 27 March 2019 (UTC)
You clearly have no idea what I have read and what I have not read. I am not having any "trouble". It is you who needs to stop making assumptions, and to stop making ad hominem comments. And it was you who wrote, falsely, "We don't use {{Cite book}} on Author pages." Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:39, 27 March 2019 (UTC)
What is clear is that this discussion now has no goal, no focus, and no direction. I didn't come here for an argument. If that's what you wish to do, then please proceed without me. You have done nothing to convince me I should change my initial response, nor satisfactorily addressed the concern I raised, so my initial response will stand as is. --EncycloPetey (talk) 19:50, 27 March 2019 (UTC)
Also, could you please put your entire proposal and explanation in a single place (here) instead of spreading breadcrumbs across four pages on two projects? --EncycloPetey (talk) 15:05, 27 March 2019 (UTC)
The entire proposal is in a single - and the most appropriate - place, on this project. As that seems little-watched, I posted a pointer to it, here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:20, 27 March 2019 (UTC)
Yes, I know what you did. However, Wikisource (unlike Wikipedia or Wikidata) holds its conversations in the central discussion location of the Scriptorium. Placing proposals on other pages, with pointers to them is not best practice for Wikisource. Best practice is to place the proposal here and have the discussion here. --EncycloPetey (talk) 15:42, 27 March 2019 (UTC)
If you know what I did, then your comment alleging that I was "...spreading breadcrumbs across four pages on two projects" is nonsensical. Nonetheless: why, then, do pages like Template talk:Cite book exist; and where is this rather unusual convention not to us them documented? And why are there currently, for example thirty nine separate discussions on Template talk:Author? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:54, 27 March 2019 (UTC)
The simple answer: We frequently get new contributors who do not know what best practices are on Wikisource. --EncycloPetey (talk) 16:16, 27 March 2019 (UTC)
"contributors who do not know what best practices are". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:22, 27 March 2019 (UTC)
Instead of simply creating a link to a list, look at what you've linked to, and analyze it. Look at the total number of pages involved over the course of an entire year. Look at which contributors initiated those discussions. It's a very small number of pages created by a very small number of editors over a long period of time with very, very few created in any given year. Hence, best practice is to hold the conversation in the Scriptorium. --EncycloPetey (talk) 16:43, 27 March 2019 (UTC)
Look at which contributors... initiated those discussions. Do you assert that User:Billinghurst and User:Samwilson are "new contributors who do not know what best practices are on Wikisource"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:49, 27 March 2019 (UTC)
Again, you're linking without reading. The first example is a response, not the initiation of a discussion. The second example is a pointer to a discussion in the Scriptorium, not a discussion. The discussion itself is in the Scriptorium, where best practice says it should be. I'm sorry you're having trouble adapting, but I can't help if you only argue against the advice I'm giving. --EncycloPetey (talk) 17:37, 27 March 2019 (UTC)
"Again, you're linking without reading" Nope. The first is a response - as can be seen by anyone who has read it - telling someone to start a discussion on a template talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:39, 27 March 2019 (UTC)
Have fun arguing, if that's what you intend to do. I'll know in future that you look for individual exceptions to general patterns in order to claim that the general pattern doesn't exist. In such instances, there is no point in trying to help someone see the general pattern. --EncycloPetey (talk) 19:50, 27 March 2019 (UTC)
  • @EncycloPetey: Based on the above argument, I am reminded of this off-hand comment made by Jan Kameníček. It at least shamed me enough to make documentation for this mess of a template. Maybe that should be a set rule. Side note: considering both {{u}} and {{ul}} are redirect to {{Underline}}, would it a big ask to at least redirect {{ul}} to {{User link}}. It'd make my life a lot easier instead of using all caps {{UL}} for {{User link}}. –MJLTalk 20:28, 27 March 2019 (UTC)
    I would start a new thread asking the community for feedback, rather than asking in the midst of this thread. For one- and two-letter redirects, it's worth inquiring whether there are additional issues to consider. --EncycloPetey (talk) 20:34, 27 March 2019 (UTC)

Style Guide update[edit]

I have updated the Style Guide to reflect the fact that we normally list works on Author pages chronologically, but have also added a clause to permit alphabetical listing, if doing so will better serve the user.

Please post any questions, comments, objections, or approval below. --EncycloPetey (talk) 21:39, 27 March 2019 (UTC)

OK with me. --Jan Kameníček (talk) 22:39, 27 March 2019 (UTC)
No problem. The one exception is that for poets it is often sensible to list the poems alphabetically, especially given that their original publication history can be confusing and hard to find out. Many poets would benefit from having both a chronological list of collections and an alphabetical list of poems. Levana Taylor (talk) 22:48, 27 March 2019 (UTC)
If you look at the diff, listing of poems is one of the examples I point out specifically as likely benefiting from an alphabetical listing over chronological. The other is any listing where the dates of the works are uncertain (e.g. Classical writers). --EncycloPetey (talk) 23:30, 27 March 2019 (UTC)
Symbol support vote.svg SupportBeleg Tâl (talk) 15:22, 28 March 2019 (UTC)

blocks of text w/o blank lines between paragraphs[edit]

Does this template exist? If not, it should. It would be very useful for some purposes to be able to not have a blank line between successive divs, like there standardly is since the divs are treated as text paragraphs. For example, it would be good for letters: the right-aligned date should be immediately above the left-aligned salutation, and the signature should be immediately below the complimentary close. <poem> is not suitable for the purpose, it has its own formatting such as a wider-than-normal blank line. Levana Taylor (talk) 15:53, 28 March 2019 (UTC)

If you have a specific page in mind, there are some templates that could be used. But it is difficult to demonstrate usage without having text for the demonstration. --EncycloPetey (talk) 16:55, 28 March 2019 (UTC)
I am having difficulties with the formatting of letters on this page and this. I am particularly dissatisfied with the relative positioning of the date and the salutation on the latter page. They should be on successive lines, without a blank line between them, but not on the same line. Levana Taylor (talk) 17:16, 28 March 2019 (UTC)
If you are referring to "From the Mountain / January 1, 1863", I would suggest that the default paragraph spacing should go between them, just as the default indent-with-no-spacing is used in the source material. However, you could attempt something like: {{float right|From the Mountain}}<br />January 1, 1863.Beleg Tâl (talk) 18:48, 28 March 2019 (UTC)
That is not what I was referring to. Rather, on that page the tricky layout problem is the signature of the following letter. Levana Taylor (talk) 19:12, 28 March 2019 (UTC)
I think you've done an admirable job on the signature of the following letter. I would do it similarly: {{right|I am, sir,{{gap|6em}}<br />{{sc|Abr. Cooper, R. A.}}{{float left|{{smaller|19, New Millman Street.}}}}}}Beleg Tâl (talk) 20:48, 28 March 2019 (UTC)
The ad-hoc solutions for page 90 are pretty good, but I still don't have an answer for page 71, and I would like to be able to easily solve problems like this in the future. Levana Taylor (talk) 22:01, 29 March 2019 (UTC)
@Levana Taylor: It was never a popular solution but the precise effect you desire can be obtained by enclosing every paragraph within a leading {{p|m0}}, trailing </p> pair — i.e. explicit paragraph-with-zero-margins directives. 114.73.168.91 05:22, 30 March 2019 (UTC)
Thanks! I will experiment with that. Levana Taylor (talk) 06:05, 30 March 2019 (UTC)
@Levana Taylor: Another effective technique is to enclose each individual paragraph within <div>, </div> pairs similar to above. Mediawiki has long had the characteristic of butting such divisions up against one another without intervening padding. Your choice! 114.73.168.91 06:13, 31 March 2019 (UTC)

nomination for adminship[edit]

Hi all,

There is a nomination for adminship over at Wikisource:Administrators#Xover that has had very little community attention. I'm going to leave it open over the weekend.

Hesperian 03:16, 29 March 2019 (UTC)

And if the lack of community input there is a reflection of some reservation, uncertainty, or doubt, then please do express it! I promise I won't be offended. :) --Xover (talk) 06:26, 29 March 2019 (UTC)
@Hesperian: I encourage you to lead by example and contribute to the discussion :) —Beleg Tâl (talk) 12:07, 29 March 2019 (UTC)

Zodiac Killer letters[edit]

All of the text at Zodiac Killer letters has been scan-backed and split to individual document pages. I will now proceed to move Zodiac Killer letters to Author:Zodiac Killer (to preserve edit history), then replace the contents of Zodiac Killer letters with the current contents of Author:Zodiac Killer. I intend to leave a {{soft redirect}} from Zodiac Killer letters to Author:Zodiac Killer due to incoming links from works external to Wikisource. None of this is controversial; it is standard procedure for pages like this. I merely post it here to inform the community due to the importance of this page. Please let me know if you have any comments. —Beleg Tâl (talk) 01:24, 1 April 2019 (UTC)

Is CSS/JS cleanup worthwhile even if some stuff might break along the way[edit]

In the Site gadget (in your preferences, Gadgets tab, Interface section; the details can be seen on Special:Gadgets) there's a bunch of custom CSS and JS included that is, I believe, intended to be of general use for various bits of the interface and templates on enWS. Mostly these seem to have come about as a result of GOIII's efforts around 2013-2015, and they are not particularly well documented (that I can find, anyway). Looking over it I have a nagging suspicion that a lot of it is actually obsolete: it's custom stuff that either never was used, is no longer used, or has been superseded by newer versions of MediaWiki and its skins (Vector in particular). However, as these things tend to go, nothing ever gets removed because it's very hard to tell what's used and what isn't, and what might break if you do.

Since this kind of cruft-accumulation tends to offend me, I would like to try chipping away at it (slowly, intermittently), deleting what's unused, moving things to TemplateStyles where that makes more sense, etc. However, this kind of cleanup is almost guaranteed to break stuff, and so I'd like to have some backing from the community that some (presumably temporary) breakage and inconvenience is acceptable as a tradeoff for decluttering and easier future maintenance. Or if the community thinks this kind of cleanup is unnecessary and annoying for no good reason, then I would prefer to have that feedback before I start proposing such changes. I'd also like to hear to what degree the community is interested in getting changes individually proposed and discussed, and to what degree they would prefer I just plow ahead and not bother everyone with such arcana unless something breaks.

As an example, the issue that prompted me to start digging into this in the first place: in MediaWiki:Gadget-enwp-boxes.css there are some CSS rules to add disclosure triangles to collapsible elements like lists and boxes. You'll most commonly see these when previewing a page you're editing, usually at the bottom of the window, where it says "Parser profiling data" and "Pages/templates included in this preview" etc.; or in your Watchlist if you have the pref to group changes by page enabled. The custom CSS points to some image files that no longer exist (and haven't existed for years) making collapsible elements show up without any kind of visual indication that they can be expanded. I'd initially though to just fix the link (the rules point at a .svg but the files are actually .png), but as I dug into it it seems that this functionality is now actually included in MediaWiki.

My proposal is thus that the relevant bits of custom CSS is simply removed. Note that it shouldn't really affect the behaviour of collapsible elements, just the visual styling with a custom disclosure triangle.

The CSS in question is:

/* General-purpose icons via CSS. Classes here should be named "mw-icon-*". */
/* Adds arrows to toggle-blocks for collapsible elements */
/* For the collapsed and expanded arrows, we also provide selectors to make it
 * easy to use them with jquery.makeCollapsible. */
.mw-icon-arrow-collapsed, .mw-collapsible-arrow-toggle.mw-collapsible-toggle-collapsed {
	background-image: url(/w/skins/Vector/images/arrow-collapsed-ltr.png);
	background-image: -moz-linear-gradient(transparent, transparent), url(/w/skins/Vector/images/arrow-collapsed-ltr.svg);
	background-image: -webkit-linear-gradient(transparent, transparent), url(/w/skins/Vector/images/arrow-collapsed-ltr.svg);
	background-image: linear-gradient(transparent, transparent), url(/w/skins/Vector/images/arrow-collapsed-ltr.svg);
	background-position: 0% 50%;
	background-repeat: no-repeat;
	padding-left: 20px;
}
.mw-icon-arrow-expanded, .mw-collapsible-arrow-toggle.mw-collapsible-toggle-expanded {
	background-image: url(/w/skins/Vector/images/arrow-expanded.png);
	background-image: -moz-linear-gradient(transparent, transparent), url(/w/skins/Vector/images/arrow-expanded.svg);
	background-image: -webkit-linear-gradient(transparent, transparent), url(/w/skins/Vector/images/arrow-expanded.svg);
	background-image: linear-gradient(transparent, transparent), url(/w/skins/Vector/images/arrow-expanded.svg);
	background-position: 0% 50%;
	background-repeat: no-repeat;
	padding-left: 20px;
}

PS. The Vector skin didn't really exist until around 2014, and MediaWiki and Vector have gained a lot of functionality since then that used to require custom scripts and styling on the various Wikimedia projects. In particular, Gadgets and TemplateStyles are relatively recent developments that enable us to have a lot less global CSS and JS and push more of it either to only those users who need it, or into the templates that actually use it. I think it's likely that there's quite a lot of cleanup that's possible there, and which might both make future Mediawiki changes less fraught and make it easier to add custom stuff afterwards if we need it. But then again, nothing is currently horribly broken, so conservatism is an entirely valid stance to take on this: we don't have to clean any of this up urgently, I just think it's worthwhile to at least get started. --Xover (talk) 11:05, 1 April 2019 (UTC)

I'd say go for it. I don't think GO3 felt it necessary to pass these cleanup tasks by the community unless it was a functionality change. Keep us posted though, in case there are issues. —Beleg Tâl (talk) 15:06, 1 April 2019 (UTC)
Well, I know there were those who expressed frustration with the sweeping nature of the changes—and particularly with documentation and maintainability—so I figure it might be prudent to thread carefully in order to not aggravate such frustrations. Particularly as it is inevitable that such changes will cause at least minor breakage at some point: at least some such change will have to be of the "try it and see if anything breaks" variety. I'm hoping the community will be prepared to tolerate that, but I feel it's better to be upfront about the downsides. --Xover (talk) 16:21, 1 April 2019 (UTC)
Yes check.svg Done I have left it in the css, though rem'd it within the page. Please report any problems so that it can be reverted. — billinghurst sDrewth 06:19, 6 April 2019 (UTC)
@Billinghurst: Thanks. Much appreciated! I can confirm that the built-in disclosure triangles are now displayed as intended. Could you also split the page layouts and page numbers script to separate functions and make each of them a gadget (so they can be disabled per-user in order to test out changes to them in a user script)? --Xover (talk) 08:57, 6 April 2019 (UTC)

Wikisource:News: April 2019 Edition[edit]

Wikisource Community Logo globe notext.svg
English Wikisource's monthly newsletter; Wikisource:News, which seeks to inform all about Wikimedia's multilingual Wikisource.

Tech News: 2019-14[edit]

16:29, 1 April 2019 (UTC)

Any Commons admins?[edit]

Are there any Commons admins here? I'm trying to get help at commons:Commons:Administrators' noticeboard, and have been waiting over half an hour for a simple bit of file move help. I can't proceed with adding the related data, creating Wikidata entries, or setting up Index pages until the files are renamed, and I need an Admin to do this move. --EncycloPetey (talk) 01:38, 2 April 2019 (UTC)

I can't help with the double file move, but I think one of your targets is wrong. Sonnets moving to Romeo and Juliet? Beeswaxcandle (talk) 02:37, 2 April 2019 (UTC)
Nope. The targets are 100% correct. The Romeo & Juliet file was mistakenly uploaded as "Shakespeare's Sonnets", and the Sonnets file was mistakenly uploaded as "Romeo and Juliet". I can't swap the files myself because I can't overwrite an existing target. I can't correct the problem through a re-upload because it would detect a duplicate file. I can't just choose alternative names because these are part of a series. I temporarily moved one of the files so that the swap could proceed, but cannot complete the swap for the same reasons mentioned above. --EncycloPetey (talk) 02:45, 2 April 2019 (UTC)
Yes check.svg Done Thanks to User:Jusjih. --EncycloPetey (talk) 17:43, 2 April 2019 (UTC)
For future reference, our Commons admins are Jusjih, Billinghurst and myself. Hesperian 03:06, 15 April 2019 (UTC)

A process and policy for Interface Admins[edit]

Somewhat related to the above proposed CSS changes… I had presumed I would be able to bug someone with the new interface admin bit to make the edits needed, but it seems there aren't any here. It is also, prudently enough, not one of the permissions administrators can assign themselves when needed. The description page at Wikisource:Interface administrators does not exist, and I've failed to find any documented policy or process related to this right.

The Wikimedia community consultation on this issue was last July, at which time there was a brief discussion here about it (raised by BethNaught, the only comment was by Billinghurst). That discussion does not appear to have had any conclusion.

The change took effect on August 27 as announced here: Editing of sitewide CSS/JS is only possible for interface administrators from now

The issue was raised again in October with comments from Mpaa, Beleg Tâl, Mukkakukaku, Beeswaxcandle, BD2412, and a logged out user. The discussion outlined several options: "Assign right on demand when needed" (A); "Assign right permanently to willing Admins, to be reviewed in the confirmation process" (B); "Assign right permanently to selected Admins, after approval process, to be reviewed in the confirmation process" (C); "assign the rights to all the admins, who have already been vetted for community approval, and then whoever has the ability and desire can make use of it as they will and as needed" (D). There was no firm conclusion reached, and some difference of opinion expressed, but the general sentiment seemed to be to assign this right to either all administrators or to willing administrators, only subject to assessment during the periodical admin confirmation process.

Subsequent to these discussions, the WMF Office has added a requirement for two-factor authentication (2FA) for holders of this permission. Since the Mediawiki 2FA feature is sufficiently… bumpy… that the enwp admins flat out refuse to make 2FA a requirement for the broom, even after several cases of compromised accounts with advanced permissions wreaking havoc, I conclude that this requirement in practice rules out giving all admins interface administrator privileges by default.

I take it there has so far not been any pressing need for handling this right, but I would assert that once such a need does materialise it is a bit late to start figuring out our policy for it. For that reason, and based on the above referenced discussions, I propose the following:

  • Wikisource:Interface administrators is filled with something very similar to m:Interface administrators and w:Wikipedia:Interface administrators.
  • All administrators may be added to the interface-admin group by self-request in a new section on the Administrators' noticeboard
    • Requests should include explicit affirmation of familiarity with the policy embodied in Wikisource:Interface administrators, in particular awareness of the privacy expectations of Wikimedia wikis and the 2FA and account security requirements, as well as sufficient technical proficiency
    • The intent of requiring explicit affirmation is to ensure the permission is not requested without full awareness of its requirements and effects
  • Requests are processed by Wikisource bureaucrats (currently Hesperian, Mpaa, and Zhaladshar)
  • During the regular confirmations for normal administrator rights, interface administrator rights are assessed as a separate matter
    • The intent being that interface administrator rights may be removed but normal administrator rights retained, for example in the case of a perfectly capable normal admin that happens to have a blind spot regarding their own technical (in)competence
  • Interface administrator rights require administrator rights and losing the latter automatically means losing the former
  • Interface administrator rights removed by the community (typically during the periodical confirmation process) are considered to be removed "under a cloud" and may not be restored without a nomination (as for admin rights) and community discussion
  • Interface administrator rights should be removed 12 months after a user's last edit, or after 24 months of being substantially inactive even if there are intermittent edits
    • This is for security reasons: inactive accounts with advanced permissions are at high risk of hijacking and may cause significant harm in the hands of a bad faith actor
  • Interface administrator rights may be voluntarily relinquished by request in the same manner they were requested
  • Interface administrator rights removed due to inactivity or voluntarily relinquished are not considered to be "under a cloud" and may be regained through simple request
  • There should always be a minimum of two interface administrators, much like checkusers, so that they can audit each other's edits
    • This is to have the ability to do so, not a requirement that all relevant edits are audited or patrolled
  • If the number drops to one for whatever reason, the permission should be removed until at least one more interface admin can be added

I think that covers all eventualities, and should be mainly unobjectionable based on the above linked discussions. As this is in effect proposing project-wide policy on advanced permissions (and with security implications for all users) I ask that everyone chime in, even if your stance is "Don't care" or similar, but especially with support/oppose. I also stress that any policy can always be amended: the above proposal presents a single option in the hopes we can get a policy and process in place, even if it's not perfect. Nine months in and we are still without interface admins on the project, have no way to get them (because the stewards at meta require a policy before assigning it), and no way to install or remove gadgets, edit CSS/JS, etc. --Xover (talk) 17:25, 2 April 2019 (UTC)

I think this is still too complicated; I think that all admins (with MFA) should be granted interface adminship, either automatically or by request/as desired. The regular admin vetting procedure should assume that the admin being vetted may use interface admin features, and should only be removed by request or when adminship is revoked. My primary reason for this is: who is going to manage this additional procedure, and why should they have to manage it when they could be adding more works or dealing with backlogs instead?—See, for example, Wikisource:Administrators' noticeboard/Archives/2018#Billinghurst interface rights for how simple it can be —Beleg Tâl (talk) 17:33, 2 April 2019 (UTC)
My assumption is that the 2FA requirement in practice precludes automatically making all admins interface admins. I don't have personal experience with Mediawiki's implementation, but having skimmed some of the discussions at enwp I am convinced at least some admins will be adamantly opposed to such a requirement, and that there is at least partially cause for the opposition. The above is also designed to require the very minimum of additional management. The bureaucrats have to add and remove such groups anyway, and periodic confirmation for adminship can rubberstamp interface admin rights unless there is cause for concern. The "minimum of two" requirement is in practice self-managed: when we dropped to just one checkuser due to a resignation, the remaining checkuser resigned the bit themselves pending appointment of a second checkuser. The above also says all admins can have it by just saying they want it: the only added requirement in the above relative to what you describe is that the request has to say "I've read the policy and know what I'm doing". "Complicated" I'll grant you, but mainly due to the requirements of the role. Or at least I've tried to make anything more complicated than it has to be.
Your example is apt; the above is intended to be essentially that simple in practice. However, Hesperian strictly probably shouldn't have honored that request: in the absence of a local policy for interface admins the request should have been made to the stewards at meta, and they should have verified that Billinghurst had 2FA enabled (which is a WMF requirement not subject to modification by local policy). The loads of words in the above proposal is to deal with stuff like that, not to make the process any more complicated or labour-intensive in practice. --Xover (talk) 18:04, 2 April 2019 (UTC)
i don’t know that the admins here are as persnickety or cell-phobic as at english WP, 2FA might be worth a try. (i would much prefer the secure key fob i.e. [6] to 2FA, but they don’t listen to me.) Slowking4SvG's revenge 01:58, 3 April 2019 (UTC)
Good point. enwp is… well, let's just say enwp is rarely entirely representative of other projects and leave it at that. --Xover (talk) 05:21, 3 April 2019 (UTC)
This sounds like a great idea. I'd like to put my hand up to become one. :-) As for the policy, it sounds pretty good I think. And as far as giving the right to all admins who have 2FA: that seems pretty good to me, the only possible drawback I can think of is that it might give some people without Javascript knowledge access to edit JS — and, I don't know, maybe open an avenue for someone else to socially engineer a non-technical admin into adding malicious JS. (After all, it's the JS security angle that resulted in this new right originally, isn't it?) But either way, we certainly need people here who can update gadgets! —Sam Wilson 03:46, 3 April 2019 (UTC)
Security is what drove this change, yes, so far as I know; both JS, CSS, and the various interface strings and markup in the Mediawiki: namespace can be appropriated by a bad actor to attack all users of a wiki, steal personal information, etc. I don't have the details, but I believe this was not a purely theoretical issue: the change was triggered by a specific incident. Hence the strong suggestion that the right should be considered to require even more trust than the regular admin privileges. It is also good security practice in general to restrict advanced permissions to only those who actually need them, so those who will not ever edit CSS/JS here should not have the permissions to do so either. But the flip side of that is also true: with more granular permissions it should also become easier to get the permissions you do need because it is clearer what the consequences are. --Xover (talk) 05:21, 3 April 2019 (UTC)
I'm generally supportive of this proposed policy. There may need to be some wording tweaks, but I would need to read it in a more final format on the policy page. At present it's not a right I would be seeking, but it is needed here with some urgency. I see no issues with 2FA being needed here for such a right. I already have to do so for some other areas of RL. Beeswaxcandle (talk) 19:25, 3 April 2019 (UTC)

I'm also generally supportive. However, we have a confirmation process for admins, and by longstanding convention we have confirmed other rights such as checkuser and bureaucrat as part of this process. People are able to, and indeed do, register !votes of the form "support as admin, oppose as checkuser". So I don't see why we wouldn't roll interface editor confirmation into the existing confirmation process in the same manner. Hesperian 01:54, 5 April 2019 (UTC)

I have no strong opinion on that. The above proposal suggests a separate section mostly due to my default preference for orderliness. There's no particularly good reason I can think of for why it's actually necessary to have a separate section, and given the general thrust of comments here favour being light on structure I think we can take it as read that it should be handled as you describe. And in any case, this kind of stuff is easy to adjust after the fact. --Xover (talk) 06:27, 5 April 2019 (UTC)

Pictogram voting comment.svg Comment Three part answer.

  1. If changes are required to elements that require interface administrators, they are probably best put to the community rather than to an individual. So make requests at WS:AN and the administrators can work the best means to implement such changes rather than an individual needing to do so.
  2. The community has discussed our needs previously, and it was agreed that we can temporarily assign these rights locally and without much fuss, and the rights disappear reasonably quickly, and no requirement for 2FA. Pretty certain there is some discussion in archives at WS:AN, though forget all the places that I saw discussions from that time.
  3. To note that if it is a simple change that we want, without the assignation of an ongoing right that we can ask global interface admins to make a change.

If we aren't making large amount of changes it isn't overly problematic to manage with temporary rights. — billinghurst sDrewth 06:14, 6 April 2019 (UTC)

And I probably should add that I do have global interface editor rights, and that gets reviewed annually at m:SRGP. — billinghurst sDrewth 06:28, 6 April 2019 (UTC)
@Billinghurst: The 2FA requirement comes from WMF Legal and has no exception for temporary assignment of the rights. For example, requests for temporary intadmin rights made to the Stewards on Meta are put on hold or denied if 2FA is not enabled. If the local 'crats are not checking and enforcing this requirement their practice is in conflict with the terms of service. And I have not been able to find any previous discussions of this issue that reached any conclusion; just the two discussions linked above that were inconclusive. Or put another way: absent an actual central policy documenting the enWS community's consensus on this, if our three local 'crats go on vacation at the same time, and we have to make such requests to the Stewards, what do we point them at so that they can verify whether to honour the request or not? --Xover (talk) 08:44, 6 April 2019 (UTC)
Our crats have the ability to remove and add interface rights, and the ability to set temporary interface rights, which was the light agreement. Let us not fuss the stewards doing such rights. I was meaning the ability to have stewards and global interface editors to make changes for us as required and requested. — billinghurst sDrewth 10:41, 6 April 2019 (UTC)

Seemingly identical links are not identical[edit]

Could somebody explain me please the difference between two revisions of [7] ? The link looks absolutely identical, yet in one of the versions it works and in the previous one it did not work. The same problem appeared also at [8] . Now I am going to continue founding the rest of the subpages of the book and I reckon I am going to face the problem again. I am really curious what the cause is and if there is any remedy, as it is really annonying.
I think it is related to the problem described at WS:Scriptorium/Help#The name of the main namespace page does not link to the Table of Contents entry. --Jan Kameníček (talk) 14:35, 7 April 2019 (UTC)

The text of the target page Anthology of Modern Slavonic Literature in Prose and Verse/In a Foreign Land had a U+2060 word-joiner character at the end of it, which displays no visible space. I have moved the page to the correct title and corrected the link. --EncycloPetey (talk) 14:47, 7 April 2019 (UTC)
Thanks very much. Is there any way how to avoid such problems in the future? I. e.:
  • Is there any way how to notice that there is such a character before I create another page with non-functioning link?
  • Is there any way how to avoid adding such undesired characters?
  • Would it be possible that the software either ignored such an character or automatically removed it at the moment of saving the page? --Jan Kameníček (talk) 14:57, 7 April 2019 (UTC)
@EncycloPetey:. It seem I keep having the same problems with Anthology of Modern Slavonic Literature in Prose and Verse/The Tiny Man. I am trying to move the page to the handwritten title instead of a copied one, but the software tells me that the title is the same and so it cannot be moved. It is really annoying... Can you give me some advice, please? :-( --Jan Kameníček (talk) 15:19, 7 April 2019 (UTC)
I seldom come across this issue, so I do not know what has caused it. My best guess is that it is related to the original scan and the method by which the OCR layer was created. The best advice I can give for this volume is to retype by hand all the titles to be linked within the Table of Contents page(s) before creating any more pages: including a couple of characters before title as well as the curly braces afterwards. That is, highlight with your cursor the full title and a couple of characters before and after the title, then retype those characters by hand.
The only other suggestion I can make to to create a list of any weird characters that are known to be hidden as they are found, and seek someone with a bot to eliminate those characters from the text. I know that's not much help, but I'm not sure what else I could suggest. If there were a editing tool that could make those characters visible in some way, it would be helpful, but I know of no such tool. --EncycloPetey (talk) 15:37, 7 April 2019 (UTC)

Unwanted line return[edit]

Is there a simple way to correct the unwanted line return between pages 212 and 213 in The Osteology of the Reptiles/Chapter 7 without either introducing a new issue or requiring a massive re-coding? --EncycloPetey (talk) 22:39, 7 April 2019 (UTC)

Abuse of {{hyphenated word start}} and {{hyphenated word end}}? Hesperian 00:05, 8 April 2019 (UTC)
Or use <includeonly> and <noinclude> - I did similar for the page break in A Manual of Prayers for the Use of the Catholic Laity/Hymns and Sequences/AdventBeleg Tâl (talk) 00:48, 8 April 2019 (UTC)
I tried being creative with just putting the ending parts of the code in the header and footer boxes, but yeah that gave less-than desirable results. –MJLTalk 01:04, 8 April 2019 (UTC)
Yeah, it doesn't work when you transcribe only part of a template call on a single page. Mostly we get around it with separate templates for opening and closing (like {{center block/s}} and {{center block/e}}) but creating these for just a few words is a bit overkill here. —Beleg Tâl (talk) 01:07, 8 April 2019 (UTC)

Scan pages not appearing in Edit window, again[edit]

Is the Page extension broken again after the latest update? Today, I have started to have random pages from a DjVu file fail to display in the Page namespace, either in the Edit window or Page view. Is anyone else experiencing this same issue? --EncycloPetey (talk) 00:12, 8 April 2019 (UTC)

Yes three pages from Index: The Osteology of the Reptiles.pfd Index pages 243, 248 and 283. I've tried with Safari and Firefox (Mac). --kathleen wright5 (talk) 05:52, 8 April 2019 (UTC)
Any other editors currently having this problem on other files? --EncycloPetey (talk) 13:41, 8 April 2019 (UTC)

Colours in the edit window[edit]

When I try to edit a page, various templates or formatting stuff are coloured in blue or purple. I am not sure whether I switched something on by mistake or whether it is some new feature, but it distracts me quite a lot. However, I cannot find where to turn it off. May I ask for advice? Thanks! --Jan Kameníček (talk) 08:30, 8 April 2019 (UTC)

@Jan.Kamenicek: There's a button in the editor toolbar that's supposed to look like a magic marker, which turns on and off syntax coloring. --Xover (talk) 08:40, 8 April 2019 (UTC)
I see now thanks! I was exploring the preferences instead :-) --Jan Kameníček (talk) 08:42, 8 April 2019 (UTC)

Read-only mode for up to 30 minutes on 11 April[edit]

10:56, 8 April 2019 (UTC)

Tech News: 2019-15[edit]

18:24, 8 April 2019 (UTC)

Wikisource:News (en): April 2019 edition[edit]

Unsourced works by Bolesław Prus[edit]

I have come across several works by Author:Bolesław Prus (e. g. A Legend of Old Egypt (2005)) and marked them as unsourced as I was not able to find there any info about where the translation comes from. Only then I found some old discussion at Wikisource:Copyright_discussions/Archives/2007-10#Works of Author:Bolesław Prus where some OTRS email is discussed. If such an email exists, can it be marked somehow at the works? And should these works be moved into the Translation namespace? --Jan Kameníček (talk) 11:24, 9 April 2019 (UTC)

i see a reprint here [19], but no results at Library of Congress. Slowking4SvG's revenge 13:52, 9 April 2019 (UTC)
Mold of the Earth is sourced from this article in The Polish Review. —Beleg Tâl (talk) 15:21, 9 April 2019 (UTC)
Regarding ORTS: you should post on commons:Commons:OTRS/Noticeboard to confirm the ticket number for the permission letter referenced at Wikisource:Copyright_discussions/Archives/2007-10#Works of Author:Bolesław Prus. Once you have the ticket number, you can add {{PermissionOTRS}} immediately following the GFDL tag on the three works that use this permission (namely Mold of the Earth, A Legend of Old Egypt, and The Most General Life Ideals). —Beleg Tâl (talk) 15:23, 9 April 2019 (UTC)
Thanks for the advice, I have asked for the ticket number. --Jan Kameníček (talk) 17:57, 9 April 2019 (UTC)
Ticket added. --Jan Kameníček (talk) 06:57, 10 April 2019 (UTC)

Category:Index - File to check[edit]

Would it be possible for someone to empty this category any-time soon?ShakespeareFan00 (talk) 12:19, 10 April 2019 (UTC)

Go for it —Beleg Tâl (talk) 12:51, 10 April 2019 (UTC)
Well I would, if there was more information on the author dates, I don't work on stuff that's still in UK/EU Copyright as far as I can determine. ShakespeareFan00 (talk) 14:55, 10 April 2019 (UTC)
Which is partly why there are still some entries in this category. ShakespeareFan00 (talk) 14:55, 10 April 2019 (UTC)

Linking to Wikipedia, Commons etc.[edit]

I've been experimenting lately with {{wdl}} for making links to author pages, Wikipedia articles, Commons or Reasonator. It dynamically changes the target based on what's available, so it's easy to add the link (using a Wikidata ID) and to start with it'll link to Reasonator but then later when a Wikipedia article has been created it'll link there. Does this sound like a sensible thing? —Sam Wilson 06:02, 11 April 2019 (UTC)

@Samwilson: I'm having trouble seeing the use cases. Examples? --Xover (talk) 06:10, 11 April 2019 (UTC)
@Xover: Sorry, yeah I should have been more detailed. See for example Battle_of_Minderoo#pagenumber_5 where each person's linked goes to the most relevant page about them. It's basically aimed at saving time when proofreading and not wanting to go searching beyond Wikidata for a mentioned topic's other pages. Sam Wilson 06:19, 11 April 2019 (UTC)
@Samwilson: Hmm. Annotating identities, and possibly also other concepts, with Wikidata QID sounds like a good option to have, and that might be useful for some future fancy functionality (javascript gadget that can show some sort of popup/preview and links; automated analysis of interconnectedness of works; etc.). However, I am less convinced at the utility of linking to Wikidata and Commons in the body of a prose work. Even internal links to Author:, Portal:, and other mainspace works are to some degree controversial; and links to enwp are, I think, actively discouraged by some parts of the community (I disagree, but that's somewhat beside the point in this context).
However, for various reasons I spend a lot of time on digging up interwiki links, and something interactive that made it easy to look up (through the Wikidata index) what's available on various projects and pick the most appropriate one to insert would be very useful (big time-saver). In such a setting, using a template that's fed a QID and a project ID to generate a specific link would have certain advantages. It'd protect against linkrot when other projects (like enwp) moves stuff around (the iw at WD would reflect the move, and our link would automatically update). We could possibly give a "preferred order of links", so the link would show as to Author:Plato if it existed, to Portal:Plato if not, and to :w:Plato if neither one did; with automatic updates if Author:Plato was later created.
There might also be a case for using something like that for internal links to other works, at least where we have multiple editions and a versions page. In at least some cases, you might be more interested in the enwp article about the referenced work than the work itself. By taking the detour through a Wikidata QID for the work we might be able to offer such linking as an optional add-on functionality: a javascript gadget that adds a choice of links for the user to pick from (all the versions we list, plus any enwp article about the work, plus possibly a relevant category or set of files on Commons, and the Reasonator link).
In any case, I do see some potential utility here; but I think maybe it lives somewhere around the functionality it enables, and not the template itself. For example, what would take me the most time in the scenario you describe is probably finding the QID itself, not the link to enwp (Google gets you there pretty fast) or our Author: page (linked from enwp). In other words, for that scenario, enwp is a better source for this than Wikidata in practical use. --Xover (talk) 06:57, 11 April 2019 (UTC)
@Xover: We could definitely add edition-of traversal as a next-level fallback. As you say, it'd be good to be able to link to an edition's Wikidata ID and for the link to go to that work's page on Wikipedia, and then when the edition has been added to Wikisource the link would change to that. I'll add a todo. Oh, and at the moment it supports Portals as well, or rather it just looks for any link from the Wikidata item to Wikisource and uses it. —Sam Wilson 01:14, 12 April 2019 (UTC)
@Samwilson: if you are looking to put such links in text, you need to make sure it falls within our annotations guidelines. Links within English Wikisource aren't considered annotations, but if they fall back to Wikipedia or Wikidata then they are annotations and should be treated accordingly.—If you are looking to put such links in the header, do you intend to integrate this with {{plain sister}}? —Beleg Tâl (talk) 12:30, 11 April 2019 (UTC)
@Beleg Tâl: Yes, within works and not in the header. I totally understand not wanting to add extraneous annotation, and so far I've only used this on works such as letters and diaries, which are more about 'reference' than 'reading'. Do you think this is okay? It's annotation, certainly, but mostly of the names of people and places and so maybe less likely to be controversial. I feel like it's different from e.g. the links we've got in some novels here to Wiktionary. I'm making sure not to add them to just any work. —Sam Wilson 01:14, 12 April 2019 (UTC)
@Samwilson: the current consensus is that if you have an edition with these external annontations, then you also should have a separate unannotated edition as well. —Beleg Tâl (talk) 14:10, 12 April 2019 (UTC)
@Beleg Tâl: I'll make sure I do this for all the ones I've been experimenting on. —Sam Wilson 01:18, 13 April 2019 (UTC)
@Samwilson: I've just stumbled upon {{annotation header}} which might be useful to you —Beleg Tâl (talk) 16:29, 17 April 2019 (UTC)
I like it. Such links should be inline, and can be styled to display or not, acording to community (and individual) preference. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:12, 11 April 2019 (UTC)
I haven't really thought about styling them differently; that's a good idea. They're wrapped with the module-wikidata-link class, so could easily be styled. —Sam Wilson 01:14, 12 April 2019 (UTC)

Match and Split bot[edit]

Match and Split bot is not running. Is anyone able to check on it? With Phe's long absence and imminent admin removal, is this tool still maintainable? —Beleg Tâl (talk) 14:11, 11 April 2019 (UTC)

You may need to ask on frWS. Phe took the tool over from ThomasV when they moved on. It should be able to be taken over again by someone else. They need to have the right skillset and accesses, but that should be arrangeable. Beeswaxcandle (talk) 04:56, 12 April 2019 (UTC)

Wikimedia Foundation Medium-Term Plan feedback request[edit]

Please help translate to your language

The Wikimedia Foundation has published a Medium-Term Plan proposal covering the next 3–5 years. We want your feedback! Please leave all comments and questions, in any language, on the talk page, by April 20. Thank you! Quiddity (WMF) (talk) 17:35, 12 April 2019 (UTC)

Wikidata items for works?[edit]

I know that some people like to create a Wikidata item for works they add to Wikisource, and I'm willing to do that for the contents of the magazines I'm adding here (at least the longer and less-ephemeral contents). Can anyone point me to a few good examples to show what information it is best to include in such items--some particularly full, complete, and correct examples hopefully? Levana Taylor (talk) 15:02, 13 April 2019 (UTC)

You may find it convenient to use Cradle to do so; it has a forms for various types, including one for "book edition". We can add "magazine " and/ or "magazine article" if you wish.
For examples of best practice, and other guidance and support, see d:Wikidata:WikiProject_Books, d:Wikidata:WikiProject Periodicals and d:Wikidata: WikiProject Source MetaData. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:54, 13 April 2019 (UTC)
Wikiproject:Books on Wikidata has rejected "book" and "book edition" as values. The term "book" can refer to a work, a published edition, or an instance of an individual physical object, so if Cradle is using "book" or "book edition" as a model, then it is presenting outdated information. --EncycloPetey (talk) 20:12, 13 April 2019 (UTC)
Also see: Wikisource:Wikidata and d:Wikidata:Wikisource. The former has some good examples, based on Treasure Island. In particular, note the distinction between works (instances of d:Q47461344 or one of its subclasses, generally associated with a {{Versions}} or {{Translations}} page on Wikisource) and editions (instances of d:Q3331189, generally associated with the proofread text on Wikisource). —Beleg Tâl (talk) 20:53, 13 April 2019 (UTC)

Thank you, all! I am going to read all those links and will comment more tomorrow or the day after. @Pigsonthewing: I very much like the idea of creating a form for magazine articles and have posted some very preliminary thoughts at Wikidata talk:Cradle. Levana Taylor (talk) 00:00, 14 April 2019 (UTC)

Copyright discussion[edit]

I am aware that we have Wikisource:Copyright discussions for discussions about texts already on Wikisource, but what about texts before they get added?

I recently found https://archive.org/details/lameprince00tolsiala/ that I wanted to add, but only after a lot of research have I thought otherwise due to when it could possibly have been published in the USSR (by Foreign Languages Publishing House between 1946 and 1964), when the author died (1945), copyright in Russia (life+70, making it under copyright in 1996), but then discovering that it was actually life+50 that was done retroactively in 1993 (Copyright law of the Soviet Union#Transition to post-Soviet legislation in Russia) making it PD in 1996.

I have since thrown out that entire paragraph of thinking as the translation was done semi-anonymously, where the copyright depends on when it was published, something I have no knowledge about. So is there a place to discuss this sort of conundrum, or for questions not answered by the existing documentation? -Einstein95 (talk) 08:40, 14 April 2019 (UTC)

WS:CV is fine for these discussions, but here is ok too. For the anonymous translation to have been PD in 1996, it would need to have been published prior to 1946 (1996 - 50). Since the publisher was founded in 1946, this seems unlikely to me. If we can't be sure it's PD, then we can't host it. —Beleg Tâl (talk) 12:39, 14 April 2019 (UTC)
Authors who lived and worked in the "Great Patriotic War" got an additional four years, which Alexei Tolstoy apparently did, which would push it past 1996, and thus restored to copyright in the US.--Prosfilaes (talk) 05:47, 15 April 2019 (UTC)

Tables with braces[edit]

Plutarch's Lives (Clough)/Preface and Life of Plutarch#pagenumber xxiii
Is there a better way to go about this table? Also yes, the braces switch directions on the 2nd page compared to the first. -Einstein95 (talk) 10:48, 14 April 2019 (UTC)

use {{brace2}} ? —Beleg Tâl (talk) 12:40, 14 April 2019 (UTC)
Well... I guess. -Einstein95 (talk) 23:27, 15 April 2019 (UTC)
In addition, you can use the "cell-padding" property to prevent the text of the columns from being right up against each other. Levana Taylor (talk) 19:16, 14 April 2019 (UTC)

Tech News: 2019-16[edit]

23:00, 15 April 2019 (UTC)

Technical question about the <pages/> function[edit]

When using the <pages/> function, what causes the margin at the left and the appearance of the page numbers? All the function itself does is transclude the pages (from experimentation on a separate wiki). Dovi (talk) 10:19, 16 April 2019 (UTC)

@Dovi: it's MediaWiki:PageNumbers.jsBeleg Tâl (talk) 12:47, 16 April 2019 (UTC)
Thank you, Beleg Tâl! Dovi (talk) 03:06, 17 April 2019 (UTC)

Template modification request: Roman numerals for article link[edit]

I hate to keep bringing up the exact same topic repeatedly, but since my previous two posts, one month ago and two months ago, got replies from exactly one person in total, here goes. Back in February I requested a parameter for {{article link}} that would display volume numbers as Roman numerals. ShakespeareFan00 was kind enough to create one in the sandbox, but it has not been implemented; and no one else has commented on the proposed change. Would people please comment and say whether you think this would be good to implement? Thanks. Levana Taylor (talk) 18:44, 16 April 2019 (UTC)

Go for it —Beleg Tâl (talk) 13:20, 17 April 2019 (UTC)
Thanks for the support, but who is going to actually do the implementation? Levana Taylor (talk) 19:45, 19 April 2019 (UTC)
You can, if you like. Or ShakespeareFan00 can copy their sandbox implementation into the main template. Or any other editor who is able and willing. —Beleg Tâl (talk) 11:40, 20 April 2019 (UTC)

The Hunchback of Notre Dame[edit]

I think, the title of this book is wrong. All editions of Isabel F. Hapgood's translations that I found have title "Notre-Dame de Paris" (eg. 1888/1, 188/2, 1891 (with first chapter starting sentence being: Three hundred and forty-eight years, six months...).

The title "The hunchback of Notre-Dame" is used by other translations:

  • Henry L. Wiliams, Jr's (It is to-day three hundred and forty-eight years...)
  • Frederic Shoberl's (?) (It is this day three hundred and forty-eight years...)
  • anonymous (On the 6th of January 1862 the Parisians...)

I think this is worth to be fixed before we start propagating incorrect info via Wikidata. Any idea how to fix this? Just rename? The text seems to originate from Project Gutenberg, but it is unclear which edition exactly. Ankry (talk) 16:53, 18 April 2019 (UTC)

The Gutenberg text is titled "Notre-Dame de Paris, also known as The Hunchback of Notre Dame". As an older Gutenberg text, it's probably a composite of various different editions. —Beleg Tâl (talk) 17:11, 18 April 2019 (UTC)
For Wikidata, I'd probably consider The Hunchback of Notre Dame to be itself an edition of Hapgood's translation with the title "The Hunchback of Notre Dame". It doesn't correspond to a printed edition, so it doesn't matter. It would be better to pick a good edition and replace our copy with it. —Beleg Tâl (talk) 17:14, 18 April 2019 (UTC)
I can even see that it was allegedly published in 1831, but the translator was not even born in that time... --Jan Kameníček (talk) 18:15, 18 April 2019 (UTC)
1831 is the publication date of the original French work. —Beleg Tâl (talk) 18:44, 18 April 2019 (UTC)

OK, so I created: Index:Victor Hugo - Notre-Dame de Paris (tr. Hapgood, 1888).djvu.

Also if someone interested in another translation: Haynes (1902), Shoberl (1833). Ankry (talk) 21:14, 19 April 2019 (UTC)

Report On The Investigation Into Russian Interference In The 2016 Presidential Election[edit]

page 49 [22] and page 100 [23] have a link to youtube on the spam list. please white list these links. -- Slowking4SvG's revenge 02:46, 19 April 2019 (UTC)

Constitution of Macedonia[edit]

Should AMENDMENT XXXIII to AMENDMENT XXXVI be added to the text? An administrator has stopped me to do so.--Mike Rohsopht (talk) 05:06, 20 April 2019 (UTC)

@Mike Rohsopht: As said by @EncycloPetey, "please create a new document under another name". This means you should make a page with the text of the new document under the name Constitution of North Macedonia, not move the existing document to that title. This means that people can compare and contrast the two documents. -Einstein95 (talk) 08:10, 20 April 2019 (UTC)