From Wikisource
(Redirected from Scriptorium)
Jump to: navigation, search
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 379 active users here.



This section can be used by any person to communicate Wikisource-related and relevant information; it is not restricted. Generally announcements won't have discussion, or it will be minimal, so if a discussion is relevant, often add another section to Other with a link in the announcement to that section.

SEARCH: Subphrase matching[edit]

There is now an advanced search feature within user preferences that enables subsidiary phrase searching. This phrase matching is very useful for finding subpages of works. For example typing Adamson, He into the general search field will show in the typeahead function the two biographical works Adamson, Henry (DNB00) and A biographical dictionary of eminent Scotsmen/Adamson, Henry.

To activate this search function go to special:Preferences#mw-prefsection-searchoptions and select the option Subphrase matching (recommended for longer article titles) and save the preference. — billinghurst sDrewth 10:20, 31 January 2017 (UTC)

Project by New Law College Pune[edit]


There is a discussion under progress at w:en:New Law College (Pune) to take up proof reading, validation, compilation etc. of Indian Laws and to begin with Copyright laws and Intellectual property laws at Portal:Copyright law/Copyright law of India as a (internship) project, most likely in consultation with CIS A2K and local wikipedian community. Activity likely to begin by middle of next week.

Undersigned requests your initial support in making other Intellectual property laws available, and initial support to new users. Please do note that most of the faculty and student's first exposure of editing is begining with wikisource and may not necessarily have previous exposure to wikipedia editing.

Besides would like to create a Project come Dashboard kind of page.
Besides would like to know if wikisource is already having any thing simillar tow:en:Wikipedia:Education_program separately for wikisource.
Suggessions are welcome.

Thanks for all support of all en wikisource community in this initiative.

Mahitgar (talk) 13:57, 10 February 2017 (UTC)

This sounds like a worthwhile project, Will this be solely in English or were translations (to official languages) on the appropriate Wikisource also being considered?
Although it may not yet exist in an open format, something else I'd also strongly suggest transcribing if licensing permits is a list of former British measures repealed in the Republic of India after 1947 to present day. As I understood it Indian legal practice followed English practice closely, and so a "Table of Statutes" for the Republic of India would almost certainly exist?
Did you plan to note in the headers of the transcribed items, information concerning subsequent repeals or amendments, or were you only transcribing the "as enacted" versions of the legislation concerned? Having an accurate Table of Statutes would assist in providing this metadata.

ShakespeareFan00 (talk) 15:50, 10 February 2017 (UTC)

I will also note that there was a series of {{cl-act-paragraph}} templates to assist with formatting legislation with side-titles, BUT having been involved with their development, was of the view that they need to be drastic overhaul before being used further. Other contributors here may be able to advise on formatting and cross-referencing issues.
It was however my understanding that in general, Wikisource used the "Short title" of a measure for linking purposes, Disambugating where needed. ShakespeareFan00 (talk) 15:54, 10 February 2017 (UTC)

Thanks User:ShakespeareFan00 for your valuable feed back. The focus of this college is mainly english specific; (Translations of entire laws will be too big a project for now, For example at Marathi wikipedia copyright case articles I am translating relevant sections only, at a latter stage they may be clubbed together at mr-wikisource and remainin translation can be done; For rest of Indic language translators looking for participation of different audience some thing like journalism students would be more effective.) Your discussion also reminded me need to take account pre-indipendance copyright acts applicable in Portugese and French published in Goa and Pondicherry.

Transcribing if licensing permits is a list of former British measures repealed in the Republic of India after 1947 to present day is a good suggession; this and other suggessions I will inform about this discussion to project co-ordinating faculty.

About wikisource style guide a seperate group of students can be made to study style guide and inform their peers.

Thanks for your valuable feed back once again and regards

Mahitgar (talk) 04:24, 11 February 2017 (UTC)

Some of the repealed acts are listed in Index:British Statutes (Application to India) Repeal Act 1960.djvu. Another list is at w:List of Acts of the Parliament of India. Hrishikes (talk) 04:55, 11 February 2017 (UTC)
We would not usually have a long discussion in an announcement.

We have always been supportive of Wikisource:WikiProjects. I would invite you to set up a project then announce it and invite people to discuss it there. There is a range of expertise and knowledge that can be provided or requested. Style and templates is definitely an issue to discuss, and these projects will have examples of what they have done. — billinghurst sDrewth 10:44, 11 February 2017 (UTC)

Publishers logos are being reorganized on the Commons[edit]

There are two main categories on Wikimedia commons that identify some 400 publisher logos. They are Logos of publishing houses and Publishers' marks. I am hoping that eventually I can merge the two categories and make "Publishers' marks" a redirect. Before creating or looking for book logos, please check these categories. Moreover, if you have already placed logos in other commons categories, please add to it the Logos of publishing houses category as well. Thanks. — Ineuw talk 16:11, 13 March 2017 (UTC)


Book downloads with the Featured download template[edit]

I'm not sure if this has been discussed/noticed previously but the downloads using the Featured download template only provides the main page of the work. Since most texts are split over multiple sub-pages, this isn't very ideal and defeats the entire purpose of having the download links since no one can easily get the full work. I do know that the tool isn't perfect and the download can still be very badly transcribed but something is better than nothing. Will it be possible to tweak the template to also transcribe all sub-pages as well? Ciridae (talk) 19:35, 16 March 2017 (UTC)

@Ciridae: It should provide the whole work. When you are on the work, are you getting the same result from the [download] option in the left sidebar? Which format are you downloading? — billinghurst sDrewth 02:46, 17 March 2017 (UTC)
@Ciridae: Not to worry. I have found and fixed the problem. [/me mumbles and mutters again about these dotted templates]. — billinghurst sDrewth 03:07, 17 March 2017 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. — billinghurst sDrewth 03:07, 17 March 2017 (UTC)

Font-style and font-size of layout 2 of display options[edit]

Would it be a possible to change the display options of layout 2 in the main namespace to the same font style and size as the other layouts? The current style now is Garamond which is not a very palatable font style and it's also smaller. I believe that the other layouts use Arial, and guessing a 1em font-size. I hope that the community would not object to uniformity. — Ineuw talk 04:19, 9 February 2017 (UTC)

No. Part of the reason for having this font is to preserve the serifs. In works on classical texts, it can be difficult or even impossible to tell what you are reading without serifs, because of the abundance of various styles of Roman numerals, abbreviations, and uses of lower-case "L". And changing the font size would retroactively affect the margins and line wrapping of hundreds of pages. So, not a good idea either. --EncycloPetey (talk) 04:24, 9 February 2017 (UTC)
First, I find that applying the words "classical texts" to displays is really meaningless. Second, I would like to take a poll as to how many users use the Layout 2. — Ineuw talk 04:58, 9 February 2017 (UTC)
You didn't read carefully: I said works on classical texts. That is, works about the literature of ancient Greece and Rome, the period we call "classical". Works where the various abbreviations II. Il. and ll. may all appear on the same page, each being entirely different, yet indistinguishable without serifs. --EncycloPetey (talk) 05:28, 9 February 2017 (UTC)
Umm, I would think that the means to that resolution would be to create Layout 4, use the config for 2 and amend the font. Additional layouts are easy. Noting that we also have the gadgetised trial layout where we can play with an additional layout in front space, though without inconveniencing anyone. — billinghurst sDrewth 06:00, 9 February 2017 (UTC)
@EncycloPetey: I didn't mean that what you said was meaningless. I said it because no matter how hard we try it will never be like the originals. This Layout issue also falls in the same category. Aside from being unable to read my work in full width mode, I was having problems at the beginning with centered image sizes, floating image sizes, and table layouts. Narrowing the layout, close to the original, resolved these problems. The PSM original is 540px, and Display layout 2 is 560px. If Layout 4 is set to 540px, would make me very happy. — Ineuw talk 06:31, 9 February 2017 (UTC)
Fixed width is a problem for mobile phones, and we should be avoiding fixing widths unless absolutely necessary. At least with the use of layouts, we allow people to have choice, if the default does not suit. — billinghurst sDrewth 06:35, 9 February 2017 (UTC)
I thought that Layout 2 is controlled by a width value. In any case, whatever you think is best — Ineuw talk 08:04, 9 February 2017 (UTC)
Yes, it is, the difference is that they can toggle out of it to something useful to them. If you set a fixed width in the template, then toggling layouts is non-functional as you have set the width. Layouts utilises the code in MediaWiki:PageNumbers.js which is more editable and a better way to code (is my understanding). — billinghurst sDrewth 10:20, 9 February 2017 (UTC)
@Billinghurst: Placed a copy of PageNumbers.js in my namespace to test Layout 4 and it works well. May I add the Layout 4 snippet to MediaWiki:PageNumbers.js? — Ineuw talk 00:29, 10 February 2017 (UTC)


For what it's worth, I read everything in Layout 2 because I prefer the serif font. As the layouts are really a matter of preference more than anything, I would suggest (and support) the addition of a new layout to address a desire for such a thing, rather than an adjustment to a long-existing layout that others prefer for certain (or all) works. --Mukkakukaku (talk) 01:35, 10 February 2017 (UTC)
Thanks @Mukkakukaku:. A majority of one is good enough for me to proceed. — Ineuw talk 06:37, 10 February 2017 (UTC)

Proposal to upgrade User:Dr. Sapna Deo user rights to account creator[edit]

Dr. Sapna Deo (talkcontribs) • enWS activityGlobal

This is a proposal cum request to give additional rights to User:Dr. Sapna Deo as an account creator. As anounced here earlier CISA2K is conducting a internship program for New law college,Pune students to proofread India law related pages. I suppose this may be first or very few of this kind of collborative activity on en wikisource.

One of the majior problem they are facing is account creation for their students. Their technical person informed me that sharing IP with mediawiki developers is not technically sound enough proposal for them. So they emailed me a list of students with email addressess where in I created user IDs on marathi language wikiource- being sysop on that project- that sent passwords dirctly to their respective email IDs. But that step rather than easing their problem it increased since message sent by mediawiki software is in Marathi language and none of these students understand Marathi language, and if some one tries to login directly to enwikisource without first log-in on Marathi wikisource also not supported well by the software. Today informed me telephonically that they created the new accounts again as much (6) allowed by the software but again rest of the students and activity got stuck.

User:Dr. Sapna Deo -while not having much experince in editing wikis she is avid reader of wikipedia and wikisource- is a reliable program co-ordinating and senior faculty their. And hence I propose and reuest to approve/give her additional account creator rights. To identify student accounts of their college for this activity separately those user names are being suffixed with BVPNLC will be additional step which helps maintain a sense of desciplene and co-ordination for wikisource project.

While earlier the better, frank community views in this regards are requested.

Thanks and regards

Mahitgar (talk) 08:47, 1 March 2017 (UTC)

@Mahitgar: For zero edits on any wiki, I don't believe that it is a reasonable request for the community to be able to assess. So ...

How many people are we talking about? Are talking about all using the same IP address or are we talking multiple IP addresses? If limited IP addresses can we identify the IP range? Do we know the period over which the accounts are being made? There are alternate solutions, we just need extra information prior to providing that advice. — billinghurst sDrewth 10:03, 1 March 2017 (UTC)

I understand your point, I worked with alternate solutions in few other universities and colleges. But everywhere we are dependant on co-operation and confidance from technical people. Few plces they dont have separate technical people. Like this college many places people donot know what wikisource is all about. The way you feel doubt they too may feel doubt from their side. Again what I am facing is language barrier, the college is in Marathi language area so we are supporting but students are not from Marathi language background.

Thanks for your inputs

Mahitgar (talk) 10:15, 1 March 2017 (UTC)

@Mahitgar: I also don't need to be lectured about technical issues, I didn't lecture you about our accountability and responsibilities for the rights that we allocate both to this wiki, nor to the broader WMF community. There are alternates and we should explore those first.

You also avoided answering my questions, which of course is your right, however, when someone is trying to assist you, it is not encouraging. I also believe that I have already offered support to your project, and will continue to do so, however, it will not be by choice to do it in a means of giving rights to a wiki newbie with zero edits. Call me a cautious former-steward. — billinghurst sDrewth 10:45, 1 March 2017 (UTC)

See I reuested in writing and in person both for IP addressess to their technical person. I did not get it officially what do I do ? I am an outsider for the institution. When I aproached them till recently Institution did not know me nor they were very conversant with wikipedia fuctioning let alone wikisource, CISA2K and all, It will take its own time from both side for confidance building and that will happen in due course of time.
Where I dont have answers I cant answer you.
They had given me list of 60 students who registered for internship-they (faculty) devided them in broad subject wise teams . I created accounts from mr-wikisource after consulting on phabricator. First team I was personally there for the workshop so problems could be handled. Now they tried on their own and seems to got stuck. On account creation aspect, Even mediawiki allows to send password info for new accounts in english lanuage even if it is created on mr-wikisource and they can log in directly on wikisource it will be easier to address problem.
It is not that I am insisting that this request be apprroved in any case. Becauase I amware of likely community aprehensions. At the most pace will remain bit slower till things get placed in their places and that every one need to bear with.
Thanks for your frank assessment, and all the support
Warm regards
Mahitgar (talk) 11:07, 1 March 2017 (UTC)
@Mahitgar: 1) If you were there, and creating accounts, we can have a steward run a CU request on the account creations and get the IP address(es), and have a phabricator request to remove the throttle if we can identify a time period. As it is you, you could request it at m:SRCU 2) We can have a list of account names provided to stewards requesting it be passed to me, and I can sit and create the accounts. 3) We can share it through a number of (English speaking) wikis (looks like 6 accounts a day per wiki), I could send a note to the CU mailing list or to stewards to share the message so the accounts are not blocked as sockpuppets ahead of time. All less than perfect I understand. All functioning. — billinghurst sDrewth 11:31, 1 March 2017 (UTC)

Use Web Fonts to improve {{cursive}}[edit]

I frequently use {{cursive}} for handwritten portions of a text (e.g. signatures), and occasionally for fully-handwritten texts such as letters. However, the default font on most browsers on Windows for cursive is Comic Sans, which looks nothing like any of the scripts used in any of the texts. Since we can use Web Fonts to provide a consistent view, I propose that we look for an easy to read, compatibly licensed script font that can be added to Web Fonts and used in {{cursive}} to improve the appearance of handwritten documents. —Beleg Tâl (talk) 21:24, 2 March 2017 (UTC)

@Beleg Tâl: We can use a combination of Web Fonts, in the template itself, and changes to MediaWiki:Common.css to fix this. Additionally, individually users can change their own CSS settings in MediaWiki and their browsers. —Justin (koavf)TCM 21:45, 2 March 2017 (UTC)
Updating MediaWiki:Common.css would be preferable, but I don't know whether Web Fonts can be used that way, and I also don't know if a better font than Comic Sans can be reliably found on all users' systems. —Beleg Tâl (talk) 21:48, 2 March 2017 (UTC)
@Beleg Tâl: In case I wasn't clear, we can use all of those options. If we change the global CSS, the CSS in the template, add in Web Fonts, and individual users change their settings on-wiki and in-browser, then that will give a large likelihood that they won't see Comic Sans (unless they deliberately choose it). —Justin (koavf)TCM 22:03, 2 March 2017 (UTC)
We do have template:ULS though you will just have to find the right webfont that is within ULS. I have a list from ages ago, though nothing definitive. Have you looked through mw:Universal Language Selector or asked there? — billinghurst sDrewth 10:34, 14 March 2017 (UTC)
@Billinghurst: that is exactly what I'm suggesting. They don't have any cursive fonts, so we will first need to find a good one and have it added to Web Fonts (which is what ULS uses). —Beleg Tâl (talk) 11:56, 14 March 2017 (UTC)
Okay, what do we think of Petit Formal Script? It's a Google font, licensed under the SIL Open Font License, looks pretty good in a wall of text, and is pretty easy to read. —Beleg Tâl (talk) 20:28, 21 March 2017 (UTC)
Possibly. What about [1], or even [2], which looks much more like the Copperplate style penmanship I usually see. --EncycloPetey (talk) 20:36, 21 March 2017 (UTC)
I think Pinyon looks better per se, but it's not as easy to read as body text. Tangerine looks different than normal cursive that I'm used to but is very legible; it doesn't seem to do well at small sizes though. I still think Petit Formal is better for simple legibility, but I think either of those could be excellent alternatives. (It would be nice to see what they all look like side by side in our website's context though.) Here's a comparison of the three fonts in use on Wikisource. —Beleg Tâl (talk) 20:57, 21 March 2017 (UTC)
I agree that Pinyon is the closest of the three to standard copperplate in the minuscules. The swashes on the majuscles are quite spidery and would be difficult at smaller sizes. The numerals in Tangerine are inconsistent with the letters and the changing baseline for them is difficult. The very high ascenders on the minuscles really make this a display font rather than something to use for chunks of text. While the numerals in Petit Formal Script are boring, the font is still legible at smaller sizes (I can read it at 8 point) and the swashes on the majuscles aren't overbearing. If I had to choose one of the three for a general use font I would !vote for Petit Formal Script. If there was a way to restrict the usage of the cursive font to display headings only (minimum size 36 point), then Tangerine would be my preference. Beeswaxcandle (talk) 06:23, 22 March 2017 (UTC)
"Overbearing majuscules"? 60-pound minuscules? Fonts in the gym?!? We are looking at a font that has a point of difference, that then works in all the broadest available uses (sizing, numerals, kerning) though probably not something like extended character set (unless we see that we need equations and translations). If it is a point of difference, one would hope that we would look to restrict use to templates rather than direct use in main ns, so other (mis)uses could be identified and replaced as required. — billinghurst sDrewth 05:50, 27 March 2017 (UTC)

Testing out the Timeless skin[edit]

Hi, I'm Isarra, a volunteer MediaWiki developer, and I've been working on a new responsive skin, Timeless, and I was wondering if you would be interested in having it deployed on your project to try it out.

It looks like this:

Timeless MediaWiki Skin.png

Some links:

  • A labs project for general testing and editing
  • A Beta Cluster clone of the Simple English Wikipedia, where Timeless is already deployed - you can create an account and in your preferences set your skin to Timeless and explore what it would be like on a real project
  • A grant proposal regarding doing proper research into usage of and problems associated with the current skins, and from there doing further development of Timeless to make it properly address the needs of the various Wikimedia projects

Timeless is currently undergoing review and I have a grant proposal in the works to do further work on it (see just above; any feedback on that would also be appreciated), but the end goal here is to, if not develop Timeless itself into a viable skin for all Wikimedia projects, then determine what exactly would be required of such a skin so that one may eventually be created.

I'm reaching out to you in particular because Wikisource has use cases that are very likely to totally break Timeless (and most skins), and I would very much like to see how so that this may actually be properly addressed. If there are also problems you are currently having with the existing skins that we might be able to look into, that would also be something I'd be interested in, but either way the very nature of your project would make your feedback invaluable moving forward.

So the question is, do you want to take part in this? Would you be willing to help me test out Timeless? -— Isarra 03:50, 27 March 2017 (UTC)

@Isarra: (off the top of my head) I think that a little technical detail is required for the community to consider. Please correct or expand on the following 1) this is just the skin, there are no functionality changes; 2) Means of implementation, ie. an extra skin will be added to user preferences, that will be "off" by default, and users can turn "on" to trial; 3) What period of testing would you expect to take place? How would you seek feedback on the functionality and tests; 4) What specific things should be tested, eg. a) Extension:ProofreadPage is a major part of our config; b) what toolbar changes might we expect as these are adapted by users, c) sidebar changes expected would be ...? 5) If it is not working for a user, would it be as simple as changing back to the other skin. — billinghurst sDrewth 04:42, 27 March 2017 (UTC)

Addendum. Some of us (dinosaurs) still use monobook as vector didn't suit, so you will see monobook customisations still existing in Mediawiki: ns; and some of still use the old toolbar as it is easier to code adaptations, whereas the new toolbar is an extra level of complexity. — billinghurst sDrewth 04:49, 27 March 2017 (UTC)
Do you mean the old edit toolbar? Or the action links at the top of the page? -— Isarra 05:04, 27 March 2017 (UTC)
mediawiki.toolbar with additional mw-customeditbuttons, rather than the enhanced toolbar. — billinghurst sDrewth 05:25, 27 March 2017 (UTC)
Yes, yes, and I'm not entirely sure yet, but setting up a project page here for it would probably make the most sense, or whatever you're comfortable with - it'd be great if you could just file the bugs directly, but I get that that would probably be a bit much to ask. As for what specific things you should be testing, I don't know - that's why I want you to try it. I often find the best thing for testing a skin is just use it - see what happens, what's annoying, what needs to be changed.
ProofreadPage is actually why I wanted Wikisource involved - I fully expect it to not really work, and obviously we need it to. And I doubt it's the only thing unique to the project, either.
Sidebar... mostly it's the same - other languages and toolboxes get moved around depending on screen size, but the actual content is the same as other skins, whatever you put in MediaWiki:Sidebar. What all changes do wind up happening may also depend a lot on user feedback - if a toolbox location/split is bad, that will be addressed, things like that.
And yes, if you don't like it, you'll be able to just switch back to a different skin, same as you switched to it. And that's totally fine. -— Isarra 05:03, 27 March 2017 (UTC)
All those responses sound reassuring as users can dip in and out as going about their daily/weekly tasks.

Either setting up a subpage of Scriptorium, or a project page for feedback both sound fine (guided by others feedback, and it may be something that we should flag to the broader WS community about how we compile feedback @Zyephyrus, @Micru, @Ankry, @Yann, @Aubrey, @Tpt, @VIGNERON:). Many of us are basic phabricator: literate, so we could transfer confirmed issues if you have a phab project set up, and we can create a direct link on a page for reporting anyway (and encouraging more users to have that phab familiarity is beneficial). — billinghurst sDrewth 05:27, 27 March 2017 (UTC)

There is indeed a Timeless project on Phabricator: Dereckson (talk) 15:21, 27 March 2017 (UTC)

Layout with justified text[edit]

Can we have a new default layout available for all users, based on Layout 1 but with justified text? Or maybe modify Layout 1 to have justified text? The current display of Layout 1 (with text just left-aligned) doesn't look very good. Ciridae (talk) 07:09, 27 March 2017 (UTC)

Bot approval requests[edit]


  • Bot name: SpBot (talkcontribs)
  • Bot operator: Euku (talkcontribs) (home wiki: de.WP)
  • Automatic or manually assisted: automatic
  • Purpose of the bot: Archiving discussions with Template:Autoarchive resolved section
  • Edit period(s): Nightly, about 1-6 edits/minute
  • Programming language(s) (and API) used: Pywikibot (Python)
  • Other projects that are already using this bot: 8 projects: de.wikipedia, de.wiktionary, de.wikisource, ja.wikipedia, ko.wikipedia, meta, wikidata and commons
  • Additional information:

I was asked to run this bot for en.wikisource too. This bot is for archiving resolved discussions and working queues, that are tagged with {{Section resolved|1=~~~~}}. For example see the German "quality assurance": wikipedia:de:Wikipedia:Qualitätssicherung/20. Dezember 2016. For more details, please see Template:Autoarchive_resolved_section. My SUL bot account has more than 800.000 edits at all - most of them made in the German Wikipedia. This archiving task is running almost non-stop since 2007. --Euku (talk) 08:27, 21 December 2016 (UTC)

Thanks Euku. To confirm that I asked for this bot to be applied locally so that we can update our archiving practices. I have seen the bot work successfully at meta in managing important WMF-central page. Also to note that these are pages with header templates that were set by Pathoschild as he set here, and, importantly, it archives within sections so can be used by us at WS:PD, WS:CV and WS:AN. It will only be operating in areas where we set it, and that will be talk pages (... talk: and Wikisource:), all of which are non-content. — billinghurst sDrewth 09:30, 21 December 2016 (UTC)
This would be a useful bot to have running. --EncycloPetey (talk) 19:04, 21 December 2016 (UTC)

When should I start? --Euku (talk) 17:05, 4 January 2017 (UTC)

I started to run the bot daily/nightly at 3 am UTC. As it still has no bot flag, it will also notify users when it edits a user talk page. Please also note that for now there is no page that uses this bot. :-/ --Euku (talk) 19:42, 8 February 2017 (UTC)
Apologies Euku, I dropped the ball on activating the templates, though did add them inactively in places. I had set them in awaiting 'crat action earlier.
@Hesperian, @Mpaa, @Zhaladshar: Is there something that you are wishing to see at this stage? — billinghurst sDrewth 10:25, 9 February 2017 (UTC)
No, I'm pretty comfortable. I checked out how SpBot worked on Meta and it seems like it works great. I say we accumulate a couple actions from SpBot here to make sure it works fine on our wiki.—Zhaladshar (Talk) 14:39, 9 February 2017 (UTC)
I have set WS:CV, WS:PD and WS:AN to each archive, and seven days post application of {{section resolved}}. First two to archive at default level 2 (per discussions to not further sort sections into 'kept', 'deleted', 'other') and the latter at level 3, hence archiving within sections. I will presume that any micro configuration can occur via discussion at the respective talk pages. — billinghurst sDrewth 21:41, 9 February 2017 (UTC)
Can we perhaps do WS:RT as well? I tagged the resolved sections of that a few months back, so it should be good to go as well. --Mukkakukaku (talk) 01:37, 10 February 2017 (UTC)
Yes check.svg Done at level 1 header. — billinghurst sDrewth 01:56, 10 February 2017 (UTC)
Looks like the config isn't quite right.... (Though honestly it would be useful if the bot told us what was wrong. Eg. what it was expecting that it couldn't find or whatever.) Mukkakukaku (talk) 04:38, 10 February 2017 (UTC)
Presumably it wants a full path, rather than a relative path (referring to examples). Not a major issue, I thought that it may be the case, just my habits. — billinghurst sDrewth 04:58, 10 February 2017 (UTC)
@Zhaladshar: and now? — billinghurst sDrewth 03:57, 12 March 2017 (UTC)
I think the edits have gone well. If there are no oppositions, I'll assign it the flag in a day.—Zhaladshar (Talk) 22:19, 12 March 2017 (UTC)
Bot flag's been added.—Zhaladshar (Talk) 01:44, 14 March 2017 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. — billinghurst sDrewth 04:52, 27 March 2017 (UTC)

Task proposal for Wikisource-bot[edit]

I have prepared a script that can run on toollabs to replace the 'Google' page in djvu files (no pdf). The idea is as follows:

  1. tag an Index page with a template (to be defined), e.g. something like {{blank_djvu_cover}}.
  2. with the frequency we decide, the bot will modify and upload the corresponding djvu file, and blank the first Page:..../1 as 'Without text'
  3. the file will be updated locally, if not shared on Commons, or on Commons directly.

If you agree with the approach, I can take care of the above and I can first run a few tests offline as soon as taggings are done, and later on make the tool tun on tool-labs.

An item that is up for deeper discussion could be if we want the bot also to delete (only) the first page instead blanking it, specifying it via template parameter. We could limit this option for Indexes w/o pages in Page: ns, or apply it to all Indexes. In the latter case, user who tags the Index must be aware that it is up to him to make sure that the action is consistent with Index status, effects on page numbering etc.

Comments welcome.— Mpaa (talk) 20:11, 5 March 2017 (UTC)

I rather like this idea, but I have two questions:
  1. How often would this bot run this task? On demand, or would it be a scheduled daily/weekly/whatever thing?
  2. I don't entirely understand the reason for point #3, keeping the modified file local. Other than the difficulty/overhead of getting bot permissions against Commons as well as enWS, why would we want to start double-hosting Commons works at enWS?
--Mukkakukaku (talk) 22:41, 12 March 2017 (UTC)
Oops apologies Mpaa, I missed this. I would like to see the test occur. I (still) do not favour deletion of the page to shorten the file, just replacement of image and text.

To Mukkakukaku. This is the proof of concept. Talking about scheduling can follow, gut feel is check daily. Whether to move a file to Commons is not solely the Google cover page, it still needs to fit within scope at Commons, have the templates completed, etc. Moving them is not overly complex with aCommonsHelper@toollabs, or a tool like ForTheCommonGood.

Operationally, I have one to test File:Love Insurance - Earl Biggers (1914).djvu which was deleted at Commons due to this issue. One think that we should consider is categorise as having been done. That will allow us to review more easily and a touchpoint on whether to move to Commons. — billinghurst sDrewth 00:10, 13 March 2017 (UTC)

Clarification on point #3. I meant that the tagging will be done on the Index page here on WS, while the file will be updated where it is actually located.— Mpaa (talk) 18:37, 13 March 2017 (UTC)
For now, you can tag using {{User:Mpaa/x}}. I created Category:Djvu files requiring clean up and Category:Djvu files processed by wikisource-bot to follow up.
For now only first page blanking is allowed.— Mpaa (talk) 21:15, 13 March 2017 (UTC)
Is this for files that we already host? The IA Upload tool has been updated recently to allow uploaders to strip the Google page out.

For files that have not yet been started, then I favour deletion of the page, because it restores the correct right/left pagination. If proofreading is underway, then blanking is possibly the better option due to the tangle of page moves required in the Page: namespace. Beeswaxcandle (talk) 06:27, 14 March 2017 (UTC)

If it hasn't been started and it is via ia-upload, just upload the file again and strip the lead page. — billinghurst sDrewth 10:38, 14 March 2017 (UTC)
If someone could tag some images, I could test a bit more.— Mpaa (talk) 20:36, 23 March 2017 (UTC)
@Mpaa: pretty hard to find local copies of Google files with header sheets. I can find numbers at Commons, but limiting searches to local uploads ... meh! We can trial some standard files and just revert them if you need targets OR we can look to do some runs at Commons. I favour the second, and happy to run the gauntlet if necessary. — billinghurst sDrewth 06:12, 27 March 2017 (UTC)
It is OK to work at commons. If you can find some, I can run a few as Mpaa. If it is OK, the we can take the next step as ws-bot. Need to create {{Mpaa/something}} or Template:Ws-bot/something} there. What about categorisation? Still needed at Commons?--Mpaa (talk) 21:04, 27 March 2017 (UTC)
@Mpaa:I don't see the need for categorisation afterwards, though there may be some value for before, especially if the bot stops working. I think that we will need an explanation page (could be on category page), and a template, maybe {{google front page}}. Hmm, does it work for pdf and djvu, or did we just do djvu? If the latter, we may wish to be more specific with template name to avoid confusion.

... a selection needing doing and most, if not all, will be at Commons.

billinghurst sDrewth 22:18, 27 March 2017 (UTC)

Repairs (and moves)[edit]

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

Category:Christian authors[edit]

Move to Category:Christians per other categories in Category:Authors by religion and the fact that they are all authors--it's redundant to say. —Justin (koavf)TCM 22:33, 1 January 2017 (UTC)

Symbol support vote.svg Support, why not. —Beleg Tâl (talk) 22:50, 1 January 2017 (UTC)
Symbol support vote.svg Support Sam Wilson 01:00, 2 January 2017 (UTC)
  • Symbol oppose vote.svg Oppose My understanding is that it is a category for our Author: ns pages only, so we run the risk that we will then start having all the biographies added to it. There is some evidence of that approach in some of the other categories. When one uses the categorisation tools, one does not see the parent categories so the name needs to be fully evident. If that means we fix the other categories, then we can do that. So that is my counter proposal. — billinghurst sDrewth 04:11, 2 January 2017 (UTC)
Symbol support vote.svg Support. This would also bring them inline with other author categories such as nationality or time period. —Beleg Tâl (talk) 15:49, 4 January 2017 (UTC)
Pictogram voting comment.svg Comment I would like to point out that the other religions do not have the word "authors" in them. For example, Category:Buddhists, Category:Hindus, Category:Druids, and so forth. We should be consistent, whatever we decide. --Mukkakukaku (talk) 15:00, 4 January 2017 (UTC)
We definitely need to make a decision and do something in this space. We are either categorising author pages in among the articles or we are not. I went to add A biographical dictionary of eminent Scotsmen/Ballantyne, John to Category:publishers and it is all author pp. — billinghurst sDrewth 13:07, 7 February 2017 (UTC)
I'm not sure articles within an encyclopaedia (or dictionary, as it may be) should be categorized. Like we have a Category:Cookbooks but we don't put individual recipes in there. --Mukkakukaku (talk) 02:23, 8 February 2017 (UTC)
I am not wishing to tag the individual article as "biographical article" nor "people from Scotland" which is the equivalent I believe that you suggest. This is a point of differentitation for each subpage. We have always allowed categorisation of subparts of works where the subpart differs from the parent. — billinghurst sDrewth 00:38, 13 March 2017 (UTC)
Pictogram voting comment.svg Comment On further thought, I would like to perhaps raise the question -- what even is the purpose of these categories? Because statistically speaking, almost all of our 19th century English/American/Canadian/other European authors is going to be Christian, plus a large number of our encyclopedia articles in (for example) the DNB -- if we go that route. What does it matter the religion of the author? If the author writes religious works, cool -- put their works in a "Christian young adult fiction" category (or similar). But generally speaking religion is irrelevant to our purposes here, just like a categorization based on the fact that a person is blond, nearsighted, divorced, or male would be. --Mukkakukaku (talk) 02:29, 8 February 2017 (UTC)
If we address the nomenclature issue here that would be great as for many categories whether we differentiate between authors and articles. The issue of whether a category makes sense or not, is kept or not may be better in WS:PD, and presumably part of that is matching with other categories in other wikis. — billinghurst sDrewth 05:43, 8 February 2017 (UTC)
Proposing to close, and to specifically rename categories for authors, with the word authors. I will create any categories that require splitting. This will mean that author ns pages in authors pages, and all main ns works in those categories otherwise named. Please object now and propose alternatives. — billinghurst sDrewth 22:22, 27 March 2017 (UTC)

Requested move[edit]

Minimizing the Economic Burden of the Patient Protection and Care Act Pending Repeal to Minimizing the Economic Burden of the Patient Protection and Affordable Care Act Pending Repeal. Can't create due to blacklist. —Justin (koavf)TCM 17:59, 22 January 2017 (UTC)

Yes check.svg Done --EncycloPetey (talk) 18:16, 22 January 2017 (UTC)
To note that I have amended the global title blacklist. — billinghurst sDrewth 09:35, 30 January 2017 (UTC)

Request moves of Certain U.S. Presidents[edit]

Donald John Trump --> Donald Trump: Similar to the vein of Barack Obama or Ronald Reagan, Donald Trump is mainly referred to by his first and last names, not usually with his middle name like "Donald John Trump". It is like having a page named "Barack Hussein Obama" or "Ronald Wilson Reagan". Yoshiman6464 (talk) 04:44, 30 January 2017 (UTC)

William Jefferson Clinton --> Bill Clinton: William Jefferson Clinton is known mainly as "Bill Clinton". Yoshiman6464 (talk) 04:50, 30 January 2017 (UTC)

@Yoshiman6464: Per Help:Author_pages#Page_name, we are to include authors' full names. Why some pages lack this is beyond me. —Justin (koavf)TCM 05:44, 30 January 2017 (UTC)


Per above Please move Author:Barack Obama to Author:Barack Hussein Obama II--it is move protected. —Justin (koavf)TCM 05:50, 30 January 2017 (UTC)

Are there any works by his father? If not, then don't need the "II" disambiguator. Beeswaxcandle (talk) 06:16, 30 January 2017 (UTC)
Moved though to expanded name, not with suffix. — billinghurst sDrewth 09:46, 30 January 2017 (UTC)

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

Work has been in progress for some time on this, initiated by User:Heyzeuss, though it has not got all that far. Having done some proofreading in Genesis, I decided to check and if possible validate some of the earliest pages done before I arrived so that there were not too many "yellow" pages awaiting "green" validation. I discovered that the end of the Memoir of Matthew Henry was missing from Wikisource and from the source scan at . However I find at Hathi Trust that only two pages are missing and would like to add these from Hathi. Could someone put them in for me so I can proofread them? I'm fairly new to Wikisource so have no idea what is involved.

I did message Princeton about scans if the pages were present in the copy from which the work was taken, before I discovered the California scan of an apparently identical printing at Hathi. If Princeton send theirs to me, they will still be relevant for getting inserted into the edition. PeterR2 (talk) 22:28, 27 February 2017 (UTC)

Of course if it's going to cause lots of problems with references I could just type the missing material onto the bottom of Page:An Exposition of the Old and New Testament (1828) vol 1.djvu/35 with a hidden note as to what I've done and my source. It's hardly a major part of the book. PeterR2 (talk) 23:13, 27 February 2017 (UTC)
Princeton emailed me a monochrome scan of the two missing pages. They are having the two pages scanned and inserted into the record on Internet Archive. PeterR2 (talk) 00:23, 3 March 2017 (UTC)

Index:Acts of the Constituent Assembly of India 1949.djvu[edit]

Transcribed the contents list in good faith, but the source file was re-aligned.

Page text for what should be page 4, is currently on page 5 Page text for what should be page 5, is currently on page 7

Pages 6 and 8 should be reset to the OCR text. Thanks. ShakespeareFan00 (talk) 09:06, 9 March 2017 (UTC)


I've erroneously included the google first page boilerplate. Could someone please excise that page for me? Thank you. LeadSongDog (talk) 21:02, 27 March 2017 (UTC)

@LeadSongDog, @Mpaa: we are currently building a tool to do that. — billinghurst sDrewth 00:13, 28 March 2017 (UTC)
@LeadSongDog, @Billinghurst: I've removed the cover page. And it looks rather likely that we could use the same system as the Indic language OCR (Google's Cloud Vision API) to determine whether a Google cover page exists or not. I've not yet done much testing, but it might be better than the currently manual selection of the cover page in IA Upload. Although, we wouldn't want it deleting the wrong thing! Sam Wilson 00:46, 28 March 2017 (UTC)

Other discussions[edit]

Open access articles in Wikisource[edit]

I'm from the NOA project of the German Technical Information Library. It hasn't started yet, but we are planning to harvest open access publications. Mainly we are dealing with figures, but we would also like to bring fulltexts to Wikisource. I've worked in Wikisource a few years ago and know how crucial quality is. We will only do as much we can sufficiently handle with our manpower and are not intending to overstretch any volunteers resources. The publications will only be from full digital journals, so no OCR is necessary.

I would like to hear your opinion, which prerequisites are still missing and what you generally think about such work.--TIB-NOA (talk) 15:09, 29 November 2016 (UTC)

@TIB-NOA: Let me know when you start migration--I'd like to help if I can. —Justin (koavf)TCM 19:43, 30 November 2016 (UTC)
Just out of curiosity, is this potentially dealing with open access textbooks? If so, as someone who knows little if anything about them, would there be any sort of need to perhaps do "editions" of the text, if it gets revised often? John Carter (talk) 22:51, 30 November 2016 (UTC)
Thank you, I'm glad you pointed out that. Textbooks and reference works do contain excellent information and figures for many wiki places. And in general articles and books can be processed likewise. So, potentially yes! Editions may be needed whenever automatic processing isn't feasible. Tonitrus (talk) 10:05, 5 December 2016 (UTC)
@TIB-NOA, @Daniel Mietchen: I am presuming that you two have talk about the earlier work that Daniel did, and the discussion that we had at the time that Daniel and his colleagues uploaded a stack of works into the user namespace. In short, we will happily have the works, the important part is formatting (that DM explore) and getting the requisite wikidata in place for the articles. Bulk full digital is not something that the community cannot manage, BUT it is not something that we have well-addressed in the Wikidata age. I would think that we would be looking to get as much data as possible into WD, especially original source, and pulling it through rather than overly complicating matters here. We would probably want to talk to Wikidata about having a flag that clearly identifies digital sourced data, and one which we inhale rather than use our transcription ribbon. — billinghurst sDrewth 10:24, 5 December 2016 (UTC)
We are indeed doing something similar to Daniels Open Access Media Importer Bot. Probably Biblionik has already told him about us.
Yes, I told Daniel :) And a few other Wikipedians as well, see also my proposal at WikiCite 2016: Biblionik (talk) 17:21, 13 December 2016 (UTC)
@Billinghurst: With ribbon you are meaning a badge, like the stars for FA/GA?--TIB-NOA (talk) 18:57, 6 December 2016 (UTC)
@TIB-NOA: The primary conversation that we had with Daniel about the bot is at Wikisource:Scriptorium/Archives/2014-09#Automated import of openly licensed scholarly articles, there is probably other bits around; plus Daniel and I had a long chat at WM2014. It would be good if we can align the two components, to whatever extent, noting that that bot also uploaded images to Commons.

Wtih regard to ribbon, at the moment there is a direct relationship between the transcribed pages that are scan supported; an example is Shakespeare, William (DNB00) (up top). We migrate those ribbons to the badges at Wikidata. With your proposed additions, they will not have the ribbon as they aren't going through the (not proofread) ... (proofread) ... (validated) cycle, so we will need another means to identify a text to text relationship. I suggest that a new badge at WD could be that means, and have started a discussion at d:Wikidata talk:Wikisource. — billinghurst sDrewth 10:07, 7 December 2016 (UTC)

On my user talk page, there has been a little continuance of this discussion, though I want to bring it back to the community, and put forward some ideas that the community should discuss to progress this issue ...

Digital documents[edit]

Our community's approach to transcribing and transcluding works predominantly sprung up around reproducing old books, though we have had the occasional foray into modern documents. The system that has been set up has had a focus on a source to which we can verify an OCR/transcription which works well books/documents/... published on paper. It does not work well for digital documents, and we need a shared opinion and consensus to how we move forward with digital documents.

We need to

  1. Explicitly accept that we can host digital-only documents and that these works do not need to be taken through the index/page verification process and then transcluded.
  2. Sort out a marking system to identify digital documents akin though different our verifying ribbon
  3. Look at our requirements for how these works are displayed as if they can be dropped into WS electronically, then the expectation should be that the metadata can be dropped into wikidata equally easily
  4. Capture the consensus of the community into our help documentation

Can others identify other matters that should be discussed by the community in this regard? — billinghurst sDrewth 13:11, 14 December 2016 (UTC)

To these points I would like to add comment …

  1. The badges system in WD is a ready place to mark a work as digital against the link to the document here and that information can be extracted back into our systems to display as digital-only. I have submitted phabricator:153186 to address this issue.
  2. There is good scope to do an adaptation of {{header}} to something like {{header/digital}} (or something) that can completely extract data from Wikidata to populate the header without any intervention required locally. So if we are having a bot we would apply all fields via imported parameters, and its use in itself is a verification of known work from a known site with known, allowable copyright (all the provenance components)

billinghurst sDrewth 13:11, 14 December 2016 (UTC)

Update This is in the process of being implemented in the Wikidata code, so I propose to start development here to allow for its usage, and look to other components discussed above. — billinghurst sDrewth 11:37, 30 December 2016 (UTC)

To the origins of the project: The Recitation-bot (talkcontribs) (run by Maximilianklein) has already imported ~200 documents from PubMed Central (PMC) and converted them to Wikitext in 2014-2016. They were not placed in the main namespace, but as subpages of Wikisource:WikiProject Open Access/Programmatic import from PubMed Central. Now my project is trying to do the same, but with much more documents and not only relying on PMC. Of course I will wait for your permission and until a badge at Wikidata is ready.

Examples, how my work could look like are Challenges and opportunities for digital history (Wikidata object) and Overview on CO2 valorization: challenge of molten carbonates. I think, that digital documents should get an extra namespace to distinguish them from PDF-based documents, e.g. Fulltext:Challenges and opportunities for digital history.--TIB-NOA (talk) 12:31, 16 December 2016 (UTC)

Update There is now a badge on Wikidata for "digital documents" ([3]).--TIB-NOA (talk) 10:35, 10 January 2017 (UTC)
I need to get back to this. Apologies for tardiness in its management. @Samwilson: Are you able to explain how Wikipedia utilises w:template:icon & w:module:icon as this is relevant for our next step to pull badge data from wikidata, and to have that display within {{header}}. — billinghurst sDrewth 01:59, 13 March 2017 (UTC)
There's nothing special in Module:Icon; that just constructs the image syntax. But I think we can do something with Module:Edition e.g. {{#invoke:Edition|badge|wikidata=Q28020002}} gives Digital Electronics Icon.svg (and if no wikidata ID is passed, it'll use the ID of the page it's evoked from). Of course the icon and what it links to can be changed.

Is this the sort of thing you mean? I'm afraid I'm not fully up to date on what's going on with digital-born stuff. Sam Wilson 04:10, 19 March 2017 (UTC)

PhD theses from Edinburgh University[edit]

Hi, the digital curator at the University of Edinburgh has asked if it would be appropriate for out-of-copyright digitised PhD theses to be included on Wikisource? The university has been digitising its collection of PhD theses for the last few months and is now at a stage where it can consider uploading a test case to Wikisource: a medical thesis by British physician & geologist Thomas James Jehu. Just looking to establish if this project is something we can go ahead with in terms of Wikisource's project scope. NB: We also have a number of Open Books we could look to import. Many thanks, Stinglehammer (talk) 12:19, 12 January 2017 (UTC)

Are these thesis published in other journals? ShakespeareFan00 (talk) 18:49, 12 January 2017 (UTC)
Aside, I would encourage you to lobby for "open access" publication to be an option for recent thesis authors, once University formalities have been completed obviously.ShakespeareFan00 (talk) 18:49, 12 January 2017 (UTC)
The relevant issues are discussed at Wikisource:What Wikisource includes. Since PhD theses will have been reviewed and approved by a committee at the University, I would consider them suitable for inclusion, provided that there are no copyright concerns. The open books, I am unsure of, as they would normally need to have undergone some sort of peer review and publication. --EncycloPetey (talk) 21:52, 12 January 2017 (UTC)
The open books are a collection of works the library has scanned. Many of them are clearly in scope, and the rest of the English language works are old stuff that should be in scope.--Prosfilaes (talk) 23:59, 12 January 2017 (UTC)
  • Symbol support vote.svg Support @Stinglehammer: Peer-reviewed works that are in the public domain or are freely-licensed are within scope. There are of course some mechanics to discuss.

    Pictogram voting comment.svg Comment Re open books, are they static to a point of time? Are they approved by experts in a way analogous to peer-review? If they are not static, or they are not peer-reviewed then here may not be the most appropriate place. I am wondering whether we should be including our colleagues at English Wikibooks to see where they fit best. — billinghurst sDrewth 01:16, 13 January 2017 (UTC)

    Addendum Looking at the Open Books, some of those seem to be analogous to us as historic documents of notable people, so not needing the peer-review component as they have a notability aspect. Where that is the case, then they get my Symbol support vote.svg Support too. We may have to pick some out, or expand this conversation a little. — billinghurst sDrewth 01:21, 13 January 2017 (UTC)
  • Symbol support vote.svg Support Certainly the theses seem in scope for Wikisource, and the few Open Books I've looked at (at random) would, as Billinghurst says above, be fine. Perhaps, if there are materials that are not a good fit for Wikisource, they could be added to Wikiversity? They'd be good candidates for raw research material there. —Sam Wilson 01:30, 13 January 2017 (UTC)
  • That's the first thesis added. Thomas John Jehu's Some problems in variation and heredity from 1902. It's been proofread. Just needs validated. Is there a specific place we should place a link to it so that it is more likely to get validated? e.g. Proofread of the Month? Also, Gweduni who did the proofreading was wondering about how to represent the scoring out of certain words and the words inserted above the scoring out? Plus is there a shortcut for adding underlining other than just typing it as markup code as bold & italic seems represented on the menu bar but no underline? Many thanks, Stinglehammer (talk) 18:35, 28 February 2017 (UTC)
    • {{dual line}} works well for showing manual corrections, as you have used; {{u}} (a.k.a. {{underline}}) can be used for underlining. —Beleg Tâl (talk) 19:53, 28 February 2017 (UTC)

Refactoring dates in the author template[edit]

(This is related to a discussion above, but I thought I'd raise it here too, as this is more general.)

I'd like to propose replacing the date-handling bits of {{author}} with a new Lua module, Module:Author. This would be the date-display code and the categorisation code that's currently done in {{author/year}} (which could then be deprecated). At the same time, we can start pulling in data from Wikidata when possible and when it's not supplied locally with the birthyear and deathyear parameters.

I've started writing the code and documenting it at Module:Author/doc. The date-display stuff is pretty straight forward, but the categories are more complicated. At the moment the module is categorizing into the following categories:

  1. In all cases (where applicable):
  2. Where manual birthdates are supplied

I've started writing tests; see Module talk:Author/testcases. Not all are passing at the moment, and not all required code paths are present yet. There's also the dates in the microformat to be done. (I'm working on all these.)

I'd love anyone's feedback about this idea! :-) Thanks. Sam Wilson 06:54, 17 January 2017 (UTC)

Pictogram voting comment.svg Comment How will we deal with disambiguated author pages where the page title includes birth and death dates? That is, there is a possibility that we will have set up a pagename including dates which then change based on Wikidata. How would we track and account for this? --EncycloPetey (talk) 13:07, 17 January 2017 (UTC)
@EncycloPetey: Good point. We can parse the dates out of the page title and check them against the Wikidata values. If they don't match, we can add the page to a maintenance category, for manual follow-up. Do you think that'd work? If they're in the format like Author:John Newton (1725-1807) then it'll be fine. Sam Wilson 21:05, 17 January 2017 (UTC)
yes, that’s good. include a manual input override. include a "edit on wikidata" button, to lead people to fix there. need to think about non-standard date formats and OS vs. NS. Slowking4RAN's revenge 21:41, 17 January 2017 (UTC)
There is a whole project within WD to look at "in-wiki/local" editing. Maybe we can add some pertinent commentary there, especially about pushing data from our templates. To also note that there is javascript tool available with which I have been playing, and can set up for others if they so wish. Not perfect, but adds something. — billinghurst sDrewth 06:30, 18 January 2017 (UTC)
That will be super brilliant when it happens! And people at the Dev Summit last week were talking about also being able to show Wikidata changes in the local history of a page, which'd help too. Sam Wilson 07:18, 18 January 2017 (UTC)
agreed - the ticket seems to be about infoboxes, maybe some input about author / creator templates would be good there. Slowking4RAN's revenge 17:54, 18 January 2017 (UTC)
I've added a function to categorise disambig'd authors into Category:Authors with title-date mismatches where the title dates don't match Wikidata. Sam Wilson 08:24, 18 January 2017 (UTC)
I've been doing a bit more on this. If anyone's got a chance could you have a look at Module talk:Author/testcases and see what tests are missing? Both for dates as supplied in the {{author}} template and those retrieved from Wikidata. Thanks! Sam Wilson 02:22, 19 January 2017 (UTC)
The Module:Author dates method is ready to deploy to the author template. Is it okay if I go ahead with this? Does anyone have any other testcases that should be investigated? Sam Wilson 03:19, 26 January 2017 (UTC)
I'm going to go ahead with this. I'll be on hand to fix anything up that goes awry! Ping me if you notice anything. :) Sam Wilson 00:42, 30 January 2017 (UTC)
@Samwilson: Do you realize that this is adding hundreds of articles to Category:Pages_with_script_errors in instances where the author name has some disambiguation--e.g. Author:John_Newton_(1725-1807) or Author:Eusebius (Pope)? —Justin (koavf)TCM 06:17, 30 January 2017 (UTC)
@Samwilson: And evidently no last name, e.g. Author:Hippocrates. —Justin (koavf)TCM 06:20, 30 January 2017 (UTC)
Sorry! Yes, I'm fixing this right now. I thought I had tested all permutations of that, but in fact I failed. Sam Wilson 06:20, 30 January 2017 (UTC)
Okay, sorted those bugs out. What other problems are there? (I'm going through a random sampling of Author pages now.) Note that Category:Authors with birth dates differing from Wikidata and Category:Authors with death dates differing from Wikidata are getting rather a lot in them too! Sam Wilson 06:29, 30 January 2017 (UTC)
Pictogram voting comment.svg Comment Don't rush too fast Samwilson, let us bring the community along at a reasonable rate, supported and informed. We are better to hasten slowly with implementation than forcing changes. There is no absolute requirement to change templates to not show these fields as I presume that empty parameters will populate from WD. At this point, I feel that we are better to label them to be left empty, and to notify that we are using WD, rather than obliterate from our preloaded templates. We have numbers of authors not in WD where we have dates of life, and to not have that data available today to then create or match later at WD is not helpful. — billinghurst sDrewth 03:18, 31 January 2017 (UTC)
Yes, sorry!! I realise I was rather getting carried away. Thanks for reverting. I think it's okay to remove dates from individual authors though, where the data's already in WD though. I've been trying to investigate ones where there are differences especially. I shall try to be more communicative and slower! :) Sam Wilson 04:33, 31 January 2017 (UTC)
While I don't personally have an issue removing date parameters, I do know that we haven't discussed that with the broad community as a specific proposal. My experience with removing other parameters from author and authority control templates is that the community wants reassurance and clarity that problems are resolved prior to such actions. Let us see how the module works and its resilience, prior to the next step. — billinghurst sDrewth 06:32, 31 January 2017 (UTC)
Out of curiosity, is this work why Category:Living authors isn't auto-populating anymore? For example, Author:Andrew Beniuk should be in there, but he's not. --Mukkakukaku (talk) 04:15, 31 January 2017 (UTC)
Yes, good point. This is a tricky one. We were assuming that anyone with a birthyear but no deathyear was therefore living, but now with Wikidata we have the ability to explicitly mark 'date of death' as 'no value', which means someone is still alive (as opposed to 'unknown', which means they're known to be dead but not when they died). So I'm not sure what to do: we already have Category:Authors with missing death dates, which used to only apply if both dates were missing, but now can apply where we have an unknown death date. The ultimate solution is to update the data in Wikidata, but apart from that, what is the best option here? Sam Wilson 04:33, 31 January 2017 (UTC)
I can see now that I've got it backwards. We should assume that people without death dates are living, unless their birth dates are >130 years ago, and for the false positives we can give them "date of death = unknown" at Wikidata. That makes more sense doesn't it? Sorry I got it wrong; I'll fix it up now. Sam Wilson 04:42, 31 January 2017 (UTC)

Another thought on this: for authors with unknown dates, I have sometimes added dates = fl. YYYY for when they were active. I just noticed that Wikidata has a property floruit (P1317) ; is this also used or usable in the new module? —Beleg Tâl (talk) 20:56, 31 January 2017 (UTC)

@Beleg Tâl: yes definitely, good idea. Can you point me to a Wikidata item using this? One that's unlikely to be given more solid birth and death dates, that I can add to the testcases. I'd say that floruit should be displayed on its own when there are unknown birth and death dates, or as e.g. (1800 – aft. 1850) when there's a birth date and f. 1850 (and similar if there's only a floruit and death date). Does that sound okay? Sam Wilson 00:03, 1 February 2017 (UTC)
I recently created Author:Mrs. Dunbo (d:Q28585286) with no dates except for the floruit field. I think your ideas for how to display when there is a floruit date and only one birth or death date will work very well. —Beleg Tâl (talk) 17:50, 2 February 2017 (UTC)

Possible bot[edit]

Might there be any interest in maybe setting up some sort of bot which could, perhaps, on the talk page of a given portal, indicate which works mentioned in that portal have been scanned for proofreading, and maybe how far along in proofreading they have gotten? John Carter (talk) 19:39, 18 January 2017 (UTC)

It might be able to give some idea, but there are many Portals where authors are listed instead of duplicating the list of relevant works, even if not all of that author's works are relevant to the given Portal. And for some works, like the EB1911, that will be difficult to judge, since only a portion of the work might relate to the particular portal. --EncycloPetey (talk) 19:56, 18 January 2017 (UTC)
You mean like adding a link along the lines of this one? Not much of a justification for a bot. unsigned comment by (talk) .
I wasn't thinking of anything along the lines the first-time IP editor indicated, and find the conclusion rather remarkable, but, rather, more along the lines of a bot which might generate something which looks in some way, allowing for all the variations, something along the lines of wikipedia:Wikipedia:WikiProject Christianity/Popular pages, possibly with some sort of accomodating changes like my recent verifying of The Complete Works of Lyof N. Tolstoï/How to Read the Gospels. The relevant criteria for us might be number of page views, number of pages involved, and current development stage, maybe for the latter ranking them based on the existing index proofreading scheme. John Carter (talk) 20:12, 18 January 2017 (UTC)
Interesting idea @John Carter:. Beyond author pages, we are pretty horrid about presenting works to our public, completed or pending. We sort of have portals, though they are curatorial in nature, and based on what we think is the subject. [Truth be told, we mostly enjoy transcribing and are not fantastic on administrivia. Personally I am a shocker about working out the subject matter.] As has been mentioned for Special:IndexPages we can add keywords/phrases/title and display related books based on that, example at Wikisource:WikiProject DNB/Progress. That would take the addition of keywords/phrases to the Index: files, and then adding something like {{Special:IndexPages|key=(phrase)}} to a section on the pages or the talk page (IF PEOPLE LOOK THERE). I take your conversation as telling us that we should be doing better, and in that you are correct, and most look up, then go back to their comfort zone of transcribing. — billinghurst sDrewth 06:00, 19 January 2017 (UTC)
Believe me, I understand. I could myself try to do a lot more in this regard myself, and may well do so when I get a bit better grasp of how to do things here. Unfortunately, I still don't have any ability at making index pages, which I kind of hate, because some recent reviews of other encyclopedias have said wikipedia:Louis de La Vallée-Poussin's articles on Buddhism in the old Hastings Encyclopaedia of Religion and Ethics have been said in reviews of more recent reference works to be the best works on their topics ever written, and, fumbingly try as I might, I've still not really had any success in trying to add those volumes here. John Carter (talk) 20:53, 21 January 2017 (UTC)
that’s very good - i would support an agenda / action plan to refresh Main Page, Portals, Projects to make more useful. a bot could be a part of maintaining that. or wikidata maintenance list updated by bot. (i.e. [4]) using [5] minimizing impact on old transcription work flows would be critical for community acceptance. Slowking4RAN's revenge 16:39, 19 January 2017 (UTC)
Perhaps a "portal expansion drive" could be a weekly or monthly collaboration project. We could rotate through some of the portals that have not seen much attention for a while, or even initiate portals for subjects we are still missing? --EncycloPetey (talk) 17:41, 19 January 2017 (UTC)
Another good use for a bot along these lines: there are a lot of portals which have an equivalent category; a lot of the items in such categories could easily be automatically added to the relevant portals. —Beleg Tâl (talk) 04:22, 20 January 2017 (UTC)
Given the recent success over at wikipedia in "drives" headed by w:User:Rosiestep and w:User talk:Dr. Blofeld, both of whom I am more or less in awe of for the success they've had in their collaborative efforts, I think there may well be merit in maybe including in such a bot or a similar bot a search for recent hits at portals and author pages to determine the number of views of each for the purpose of seeing what is likely to get the most input for such "portal/author improvement" drives as suggested above. The reference work bot might then be used to see which reference works have articles on the topics which may not have yet been addressed, which might then be included in the portal improvement. Particularly for wikipedia editors, maybe finding which portal/author pages have shorter "entries" in collective works which could be listed by bot for expansion might help bring in some more wikipedia editors more used to working on shorter "projects" than proofreadings of full books, although maybe the "portal improvement" effort might be maybe optimally chosen to relate to the following months "Proofread of the Month" to maybe get a few more such newer editors involved in that effort as well. John Carter (talk) 20:44, 21 January 2017 (UTC)
One idea is to use Wikidata: I guess all portals have a Wikidata item, and so we can find out their main topic, and then find all editions that have that as their main subject (non-fiction) or genre (fiction), and list them all on the portal? But would this leave us with weird things? For example, we don't have a Portal:Novels in which Pride and Prejudice would go (let alone Portal:Satire). And anyway lots of things don't have subjects or genres at Wikidata. :-( I've played around with a script to make Portal:Penguin Classics, which seems to work okay, but that's a different sort of portal (and should probably be renamed Portal:Penguin Classics works or something). Sam Wilson 06:50, 20 January 2017 (UTC)
that’s very good. another step would be a wikidata list query that updates by bot. don;t know how community feels about semi-automatic versus automatic. we can use the lists to provide input for content drives such as women in red. lots of metadata to deconflict / get linked. Slowking4RAN's revenge 14:28, 22 January 2017 (UTC)

If we were to request a bot be created roughly along the lines of the Popular Pages bot linked to above, what sort of specific details would we want? I might include name of portal or category item linked to, number of hits (per month?) to same, individual pages included in those portals or categories which number of hits, number of pages per pagescan in the individual works, number of problematic pages in the transcluded text, and, maybe, level of development past the current proofread level of the pages transcluded into an individual work and/or of the broader work whose index is linked to. If the last isn't really clear, indicating the number of pages at non-proofread, proofread or verified level, not differentiating in the bot results between the two higher levels, for a work still at not-proofread level and that sort of thing. John Carter (talk) 15:34, 25 January 2017 (UTC)

I've left a request at wikipedia:Wikipedia:Bot requests regarding the above proposed bot. I hope to here something in response shortly. John Carter (talk) 14:47, 6 February 2017 (UTC)


A simple consultation. Should I continue converting this to use the sidenotes, which on a number of pages are currently not quite fully working, or revert back to the approach of using footnotes?

I'd also like a decision on whether to use the long s as I have been (faithful to text), or substitute a modern s for reader ease. ShakespeareFan00 (talk) 11:54, 22 January 2017 (UTC)

Wikisource:Style guide allows the use of {{long s}} in the Page: ns, though noting that it displays normal s when transcluded. Not sure that it is a work that would be any more special than that. — billinghurst sDrewth 13:45, 22 January 2017 (UTC)
EncycloPetey used hard-coded, visible-in-mainspace, Unicode long-s in next month's FT, The Clandestine Marriage. You appear to have done this so far. Considering it is a facsimile of the first edition from the 1600s, I would favour continuing with this approach. Interestingly, however, {{blackletter}} does not appear to support long s, meaning the page headers are incorrectly displayed. Not sure what you could do about that... BethNaught (talk) 14:35, 22 January 2017 (UTC)
{{long s}} also doesn't work nicely with {{hws}}{{hwe}} pairs, which is why I was considering hardcoding.ShakespeareFan00 (talk) 15:06, 22 January 2017 (UTC)

your style solution seem ok to me. i’ve kinda given up on easy to use sidenotes. i would note a lot of other transcription projects don’t even try. unclear benefit to reader, of sidenote, when content is there in a different place. it is vestigial marginalia Slowking4RAN's revenge 14:37, 22 January 2017 (UTC)
@BethNaught: {{blackletter}} does some glyph-replacement by default; you can override this with mode=1 as follows: s = s and ſ = ſ.
OK let's make this simple.
Hardcode {{ls}} as the Unicode Character? (Yes/No)
Hardcode {{rr}} as the Unicode Character? (Yes/No)
Use footnotes as opposed to sidenotes? (Yes/No)

I'm not going to reformat anymore pages until there is a clear consensus and someone else puts a style guide on the Index talk, I don't want to be changing back and forth.

Let's give it 7 days for someone (other than me) to write the style notes? ShakespeareFan00 (talk) 15:01, 22 January 2017 (UTC)

The preface to the work in question shows that "no pains have been spared. In all those matters of orthography, grammar, rough or quaint expression, typographical peculiarity, &c., above referred to, absolute reproduction has been the one aim." Because of this, I would encourage this attitude in the WS transcription as well, and would therefore suggest hard-coding the characters. That being said, if the sidenotes don't work, it's okay for them to be footnotes. —Beleg Tâl (talk) 19:43, 22 January 2017 (UTC)
Further to this, I'm pretty sure that ꝛ is only used once in the Preface, and subsequently only in the non-transcluded page headers, so it may not be worth changing. And finally, if you hard-code it we can use autowikibrowser to change it afterwards if desired. —Beleg Tâl (talk) 19:47, 22 January 2017 (UTC)

  1. While {{long s}} and {{ls}} both render as s in the edit screen and as ſ in the mainspace, {{s}} is always rendered as as ſ regardless of where it is rendered.

    We also have {{s|2}} (ʃ), {{ss}} (ſſ), {{ss|2}} (ʃʃ), {{ss|3}} (ß), and {{ss|4}} (ʃß).  These five always render as stated, regardless of where they are rendered.

  2. I definitely think it wise to use the exact typography found in the text being transcribed, meaning always using the long-s (etc.) when the text being transcribed uses the long-s (etc.) and using the short-s (etc.) when the text being transcribed uses the short-s (etc.).

    Take, for example, old Bibles and new Bibles.  We have some Bibles here on Wikisource from the 1600s.  We have other Bibles here from modern times.  When a person goes to look at one of the Bibles from the 1600s, that person wants to see all of the original typography; otherwise, she or he would have directed her- or himself to a more-modern printing.  If we incorporate modern typography into transcriptions of old printings, we do a grave disservice to those who are specifically seeking out those old printings.

    allixpeeke (talk) 00:20, 2 February 2017 (UTC)

Possibly, although I have trouble seeing how our having material in one format in our transclusions makes it harder for parties interested in the original forms of the typography to get them from the .pdf or .djvu we are basing the transclusion on. And, speaking personally, as someone who is highly involved in religious content here and elsewhere, personally, I want stuff I can read easily, and sometimes older typography isn't easy to read. I imagine the same might be true for students looking for a good source to use in papers, most of which are in current typography too. On that basis, and given that I don't know what proportion of readers meet the criteria you discuss, I'm not sure exactly how much of a disservice we would be doing, although, I guess, if rules here permit it, maybe having some older books in ye olde type for those interested in such might be possible, maybe? John Carter (talk) 01:26, 2 February 2017 (UTC)
Yes, people could take a look at the .pdfs/.djvus in order to see the original text, but then again, transcribing texts from .pdfs/.djvus into .html/wikitext is what wikisource is all about; otherwise, we'd simply upload .pdfs/.djvus here and do nothing more with them.

It's not unusual for someone to look for "stuff [she or he] can read easily," but I must ask you this:  When you, John Carter, go looking for easy-to-read Biblical content, do you tend to look for older sources or newer?

Personally, when I have occasion to look up stuff in the Bible, I go to the New American Bible (Revised Edition) (2011).  Sometimes I may opt for a side-by-side comparison with the New King James Version (1982).  But when I go to the Douay–Rheims Bible (1582–1610), I'm definitely not looking for easy readability; I'm looking for the actual 1582–1610 text.

Even back when I was a student, I always preferred the actual text as opposed to modernisations in spelling and typography.  It doesn't take much effort for students to take "The Booke of Genesis" and "the Spirite of God moued ouer the waters" (e.g.) and rewrite them as "The Book of Genesis" and "the Spirit of God moved over the waters" if they for some reason really need to.  (Doing so doesn't even require the student to look at the .pdf/.djvu; the student is able to make this revision, if necessary, by merely remembering how things are spelled nowadays.)  Conversely, however, taking a modernisation and diligently rendering it back to the original can be painstaking, especially insofar as the text that needs to be unmodernised is lengthy.  (The student has to keep looking at the .pdf/.djuv and then back at the document she/he is writing, back to the .pdf/.djuv, back to the document, back and back again.)

I am not averse to the idea of having texts rendered in dual formats.  That said, I regard the original print formats to be the more-valuable renderings, and any modernisations we do of secondary value.

Yours respectfully,
allixpeeke (talk) 02:50, 2 February 2017 (UTC)

This is why I like {{ls}} so much: it renders as 's' for the majority of people who want to have something easy to read, but individual users can configure their profile such that it renders as 'ſ' instead. It essentially removes the debate completely. Hard-coded ſ or {{s}}, on the other hand, should only be used sparingly, and with a good reason. In this version of Pilgrim's Progress, the original editor's insistence on preserving the typography provides that good reason. —Beleg Tâl (talk) 13:25, 2 February 2017 (UTC)
@Beleg Tâl:

You write, "This is why I like {{ls}} so much: it renders as 's' for the majority of people who want to have something easy to read, but individual users can configure their profile such that it renders as 'ſ' instead."

I have searched through the Preferences options, and I don't see how to turn it on so that I do see the long-s.  How do I do that?  Please help.

Thanks in advance,
allixpeeke (talk) 21:50, 5 February 2017 (UTC)

The documentation at Template:ls describes how to do this. You will need to modify your personal CSS file (Special:MyPage/common.css) or your personal JS file (Special:MyPage/common.js). —Beleg Tâl (talk) 01:49, 6 February 2017 (UTC)
I disagree; if I'm looking at the Wycliffe Bible, it's because I want to know what the Wycliffe Bible says, not because I care about the particular details of orthography. You talk about typography and use examples from orthography when we dispose of the first and keep the second, and the questions all lie on the line. We do keep the original text; the question is whether these features are text or typography.
I think it's also a peculiar choice to pick a book in translation. There are a lot of works that have no "modern edition"; American Cookery is one, and I think it entirely likely to want to read the details of early US cooking without digging through weird typography that might well stop someone unfamiliar with it. "the Spirite of God moued ouer the waters" forces me to stop and figure out what it says, a great deterrent if I'm trying to read more than a couple sentences.--Prosfilaes (talk) 22:14, 2 February 2017 (UTC)
It's funny you should mention the Wycliffe Bible, since I just went searching around the Internet specifically looking for transcriptions that included the original typography earlier today!  I even found a few that looked pretty good, having the thorn and whatnot correctly displayed.  But, to my utter chagrin, I couldn't find a single one that had all of the books' titles in their original typography!  Every book was either titled in modern English or semi-modernised English.  It was completely useless to my needs!

In any event, the Wycliffe Bible is a perfect example of a text that is best presented with side-by-side versions, showcasing both the original Middle English typography and a translation into modern English.  How better to show the evolution of the English language from the Middle Ages to today?  If only the modern English translation is presented, then all that rich history is tossed away.

allixpeeke (talk) 21:50, 5 February 2017 (UTC)

Nobody is talking about a translation into modern English! We're not even talking about modernizing spelling of the words. We're talking about changing a few letterforms to modern letterforms. Transcription is quite far from the original manuscript, but is also quite far from translation into modern English.--Prosfilaes (talk) 04:01, 6 February 2017 (UTC)

Index:Paper and Its Uses.djvu[edit]

I can't find anything on the author in Google, other than this work, which is making it hard to track down the dates. Also it seems this work is an update from a much earlier on by a different author who I've also been trying to trace with little success. ShakespeareFan00 (talk) 18:37, 23 January 2017 (UTC)

Suggest this might be his pedigree: Edward Arthur Dawe (house painter and paper-hanger; 1884-1970)?
I truly doubt that assignation. Did you read the small print of the title? Public servant with office at HMSO at the age of 25 who progresses to be a house painter and wallpaper. Doubtful. — billinghurst sDrewth 04:49, 24 January 2017 (UTC)
Edward Arthur Dawe (1875–1963), occupation shown as clerk with knowledge in printing @HMSO (1911 England census). Born Exeter, died Wallington.probate. Father was a photographer. — billinghurst sDrewth 05:01, 24 January 2017 (UTC)
Author:Edward A. Dawe created, What license to use? (And I note based on the dates the scans might need to be localised from Commons.) ShakespeareFan00 (talk) 12:02, 24 January 2017 (UTC)
Why you never ever indent your comments? It's not that difficult.— Mpaa (talk) 19:39, 24 January 2017 (UTC)
@ShakespeareFan00: file moved here, and deleted at Commons. Please update local file. — billinghurst sDrewth 21:45, 24 January 2017 (UTC)
You shouldn’t use initials for an author page. If you aren’t sure of the middle name, just leave the initial out and note on the author’s page.Zoeannl (talk) 00:07, 16 March 2017 (UTC)

AWB/bot Request[edit]

Does someone have a "conversion therapy" bot for apostrophes and quotes? (i.e makes them all straight.)

Was considering suggesting as a potential FT: Index:The_pilgrim's_progress_by_John_Bunyan_every_child_can_read_(1909).djvu

but another contributor expressed a concern about curved vs straight quotes.

Index:The Pilgrim's Progress, the Holy War, Grace Abounding Chunk1.djvu is what I was working on at the moment, and was wanting that to be consistent as well. ShakespeareFan00 (talk) 13:25, 26 January 2017 (UTC)

I'm sorry for causing confusion. I have not noticed a problem in "Every Child Can Read". The mixture of straight and curved apostrophes/quotes is in the "Grace Abounding Chunk1". BethNaught (talk) 13:31, 26 January 2017 (UTC)
@ShakespeareFan00: The nice thing is that it's easy to change <‘> and <’> to <'> since the curly quotes versions are almost only used for one purpose but an apostrophe is used all over the place for all kinds of purposes. Similarly, <“> and <”> to <">. It would require some discrimination for a very few cases but someone could easily do it with a replacement rule. If you need me, let me know. —Justin (koavf)TCM 22:39, 26 January 2017 (UTC)
Let's do the obvious cases first. The apostrophes may be have to done by a manual check. ShakespeareFan00 (talk) 22:43, 26 January 2017 (UTC)
Although our style guide says we should use typewriter quotes, I understand there are some dissenters from this. I don't think it is a good idea to unleash a bot on this until you are certain of consensus support for it. Hesperian 02:30, 27 January 2017 (UTC)
There are some cases where it's appropriate to use curly quotes, such as when the original work goes out of its way to intentionally do so. I ran into an example a while back which used straight quotes for quotation, and then the curly versions for nested quotations. Eg. "The man said to me, “Hello!” and then ran away."
Personally I just clean up the curly quotes manually as part of validation. --Mukkakukaku (talk) 04:24, 27 January 2017 (UTC)
e.g. Page:EB1911 - Volume 22.djvu/665 Hesperian 04:34, 27 January 2017 (UTC)
The style guide permits the use of curly quotes—provided that they are applied consistently throughout a whole work and a note to that effect is placed on the Index Talk: page by consensus of the proofreaders. If this is so, then validators are expected not to change to straight quotes. A bot that overrides a consensus on a particular work would be unacceptable. (Note: this is not a support of the use of curly quotes). Beeswaxcandle (talk) 07:35, 27 January 2017 (UTC)

Once you have finished the style discussion, any bot requests belong (weirdly) at Wikisource:Bot requests. — billinghurst sDrewth 09:56, 28 January 2017 (UTC)

A Woman of the Century[edit]

user:Zoeannl i belatedly found this work A Woman of the Century after uploading duplicate scan Index:A woman of the century.djvu after Index:Woman of the Century.djvu. the new scan looks cleaner, but thoughts ? delete new scan ? copy over OCR to old ? Slowking4RAN's revenge 05:00, 28 January 2017 (UTC)

It would take a lot of effort, but it would be worth looking through every page before making a decision, in order to make sure that the scan is complete and of quality throughout. I have occasionally found "better" scans at IA or Google, only to later discover missing pages, duplicate pages, pages blurred beyond hope of reading, etc. --EncycloPetey (talk) 05:16, 28 January 2017 (UTC)
Cleaning up that work is not going to be that problematic, most of it was bot applied, so we can work out which is preferable, move the requisite pages in whichever direction, and then clean up. — billinghurst sDrewth 09:59, 28 January 2017 (UTC)
Addendum. The reason that the pages are bot applied is that often one wishes to work on a specific biography from the complete work, so this makes finding them easier. For some biographical works even adding a search on the index page for the Page: ns is advantageous. — billinghurst sDrewth 10:01, 28 January 2017 (UTC)
ok, i will start in with index (found at separate prospectus) and then start in on new scan. we can bot copy over if decided later. Slowking4RAN's revenge 20:47, 28 January 2017 (UTC)
Okay, we can leave it with you. Do we prod you in later in Feb. so it is not forgotten? I would hate for work to get done on one of the variations and get lost/confused/wasted. — billinghurst sDrewth 22:45, 29 January 2017 (UTC)
Hi, I missed this. Where are we at? I have no real preference re scans, I just would rather not see proofreading go to waste. I am hoping to use as this book as a beginners project but still working on a Proofreaders guide atm. Zoeannl (talk) 00:04, 16 March 2017 (UTC)

Categories and {{plain sister}}[edit]

Should it be our practice to put {{plain sister}} template in each of our created categories? This means that once they are in Wikidata that they are interwiki paired by that system. Where we do have the template in place, then we can look getting them into WD as I don't think that we have many that are currently in that system (said without checking at all). — billinghurst sDrewth 22:42, 29 January 2017 (UTC)

Sounds like a good idea to me. —Beleg Tâl (talk) 03:41, 30 January 2017 (UTC)
It's certainly worth doing a trial run to see what we get. --EncycloPetey (talk) 03:51, 30 January 2017 (UTC)
Yes, this seems like a sensible thing to do. We need better descriptions on category pages, and this could help with clarifying what particular categories are intended to do (by linking them to their equivalent concepts elsewhere). Sam Wilson 04:06, 30 January 2017 (UTC)
Perish the thought, are we wanting to have {{category header}}. It enables a continued development, especially if we have wikidatafied. unsigned comment by Billinghurst (talk) .
Indeed! I have been wanting {{category}} for years!! :-) To specify interwiki links, and what namespaces files should be in a category, and most importantly a good highly-visible description of what the category is for. Sam Wilson 10:15, 30 January 2017 (UTC)

Digha Nikaya ... to a portal?[edit]

Anyone got ideas on where this sits? There does not seem to be a complete published work by the name so sitting it in the main ns seems inappropriate, and it seems to have components in numbers of places. Do we think that it should be a portal? (happy for anyone to make a solution) — billinghurst sDrewth 22:59, 29 January 2017 (UTC)

By itself, it is not a single work. It is a collection of 34 separate works, arranged in 3 divisions, originally in Pali language. 1987 tr. by Maurice Walshe is available at 1899 tr. by Rhys Davids, in 3 vols, is at 1, 2, 3. Therefore yes, complete published work in English translation is available; but not in Wikisource right now. Hrishikes (talk) 01:28, 30 January 2017 (UTC)
In that sense it looks like it would be comparable to the Bible, also a collection of 24 to 51 books (depending who you ask) in up to 3 divisions. In that case, a mainspace page would be appropriate, especially as the collection is generally published as a unit, but individual mainspace pages for each component work would also be approporiate. —Beleg Tâl (talk) 03:41, 30 January 2017 (UTC)
But we don't have it as a single published work, which is our focus for main namespace. So either it becomes a disambiguation page if we have more than one copy of the work, or in its current form it becomes a portal. — billinghurst sDrewth 09:31, 30 January 2017 (UTC)
This collection does not behave like a portal. In a portal, the order of the listed works is not fixed. If fiction is before poetry, you can change it. You can also add new items. In Digha Nikaya, the number of components is fixed. Their order is also fixed. A portal where you cannot change the order of the items, cannot add extra items, I don't think the concept of such an un-amendable portal exists in this site. From this angle, the components behave more like chapters of a book. Hrishikes (talk) 14:26, 30 January 2017 (UTC)
The order and number of elements in the Bible is also fixed (albeit they differ slightly among religious groups), so a Portal is probably the best approach, just as we have done for the Judeo-Christian Bible. --EncycloPetey (talk) 23:20, 30 January 2017 (UTC)
In a portal the order of works is what we make it, many are not ordered, but that is just those. An portal can be what we make it IMNSHO. If a portal page is ordered and should remain ordered, then it is stated to be so. I also understand that it can be considered a book, that is not my argument, that page is a construct, not a published work. The main ns is for published works, so those components published appear as per the work. — billinghurst sDrewth 04:56, 31 January 2017 (UTC)
@Billinghurst, @EncycloPetey: The text here is indeed published work. It is the Rhys Davids translation; IA has it, in 3 vols., link given above. Although the current root page is a TOC only. Hrishikes (talk) 02:59, 2 February 2017 (UTC)
I think you misunderstood. The Portal is a construct, and not itself a published work, so it has flexibility. --EncycloPetey (talk) 03:04, 2 February 2017 (UTC)
I do not understand what you mean by misunderstanding. The root page here is a TOC; linked items are the items in the Rhys Davids translation. That 3-vol-set is Part 2 of the series, Sacred Books of the Buddhists, edited by Max Müller. This series is analogous to another series Sacred Books of the East, also edited by Max Müller. Hrishikes (talk) 03:34, 2 February 2017 (UTC)
@Hrishikes: What exactly was published and when. The versions of the bible that we have are specific editions, I do not see that Digha Nikaya is an edition of an English translation. To me it looks like a construct. If that work has been published like that, then let us get it into the shape expected of an edition. — billinghurst sDrewth 04:46, 2 February 2017 (UTC)
@Billinghurst: I have added the concerned index files and also the migrate to djvu template on the root page. Currently the root page shows the TOC of all 3 volumes, which is not appropriate, I think. The name should also be changed to English (Dialogues of the Buddha) from the current Pali form. To reconcile the Pali and English forms, I have moved the root page to Portal:Tipitaka/Digha Nikaya, and now, the linked component works can be kept in the main space under English title used by Rhys Davids. Hrishikes (talk) 06:25, 2 February 2017 (UTC)
Thanks. Always good to get knowledge and sense applied to a solution. — billinghurst sDrewth 09:52, 2 February 2017 (UTC)

Tech News: 2017-05[edit]

18:45, 30 January 2017 (UTC)

Tyronian et[edit]

I started working on Index:The Jolly Pinder of Wakefield with Robin Hood Scarlet and John.jpg, which is a poem written in blackletter font. For simplicity's sake, I'm dropping the blackletter typeface and updating the long-s and rotund-r to regular s and r and so forth. However, the text also makes significant use of the Tyronian et, '⁊', which is also a defunct character. Based on w:Tyronian et and w:Ampersand, this symbol is not just an old version of & or + or similar 'and' symbols, so I can't just replace it with the modern version. Should I preserve the et symbol in the text, or replace it with something? If I replace it, with what? —Beleg Tâl (talk) 19:54, 30 January 2017 (UTC)

Do you mean w:Tironian notes? It is an abbreviation for "and", so there's no reason not to replace it with & unless the text actually uses it for basically word-play.--Prosfilaes (talk) 22:21, 30 January 2017 (UTC)
As a side note -- whatever you decide can you note it on the Index's talk page for the reference of whoever comes by to validate? --Mukkakukaku (talk) 03:44, 31 January 2017 (UTC)
I've replaced it with & in the text and made a note of it in the Index talk page. I have also created {{et}} (similar to {{ls}} and {{rr}}) for future use as desired. —Beleg Tâl (talk) 13:30, 31 January 2017 (UTC)
Oof, this is going to be one of those things ... the {{et}} renders like a little rectangle for me. :( --Mukkakukaku (talk) 05:01, 14 February 2017 (UTC)
Pretty sure that rendering was one of the matters that we covered all those years ago. That said, we now have {{ULS}} capability added since those years ago, so maybe see what may be renderable through that implementation. — billinghurst sDrewth 06:09, 14 February 2017 (UTC)
OK, based on the info at the enWP article and that cool {{ULS}} template, I've hacked together this, which shows for me: . Which I think is the letter we're all talking about? Except it just renders like a square for me even in the text input area which makes it really hard to work with.... --Mukkakukaku (talk) 02:39, 15 February 2017 (UTC)
Please don't use ULS in the template. Most of the places I've seen this character are within the context of {{blackletter}} or {{insular}} and this will override those. Sometimes you just need to display a raw Unicode character. If necessary, you can use Special:MyPage/common.css to set a font-family on the class "typographic-et". —Beleg Tâl (talk) 12:53, 17 February 2017 (UTC)
Well yeah, but overwriting my common.css will just help me and let everyone else with the same problem see little rectangles. Given the choice between seeing a little rectangle or seeing a letter in a different font in the middle of a blackletter, I think the second is preferred. --Mukkakukaku (talk) 04:44, 18 February 2017 (UTC)

Some custom Wikidata queries about WS[edit]

I'm gradually learning how to write queries for Wikidata, so my work might duplicate work elsewhere, but I've found these useful:

  1. Dead people with a Project Gutenberg ID but no English Wikisource profile, whose main language isn't English (source): a source of people who are very likely to have public domain English text, but no WS author profile. Including people with no language defined captures a lot of people who definitely didn't write English, but also many who did. The first several entries in this are Chinese, but keep scrolling.
  2. Wikisource items with no statement of what they are (no "instance of" or "type" statement) (source) ordered by number of statements Wikidata has about them.
  3. Number of Wikisource entries of each type (excluding Wikimedia internal stuff), along with the number in each category that have a publication date attached (source)

Hope these are useful to somebody. Is there a central place on WD or WS where relevant WD queries reside? Are there queries like this that people would like created? MartinPoulter (talk) 22:47, 30 January 2017 (UTC)

Missing sections[edit]

There is a block of several discussions on this page that cannot be edited by my, for whatever reason. They do not have [edit] displaying, and when I try to circumvent this by editing a different section, and changing the section number, the system balks. Is anyone else having this issue? --EncycloPetey (talk) 03:01, 2 February 2017 (UTC)

Yes.  I've resorted to hitting the main edit button for the section missing section-edit links.  allixpeeke (talk) 04:13, 2 February 2017 (UTC)
It looks as though billinghurst has sorted the problem now. :) --EncycloPetey (talk) 05:19, 2 February 2017 (UTC)

What would you like done about "found" dates of death or birth?[edit]

In fixing up author pages I have come across a situation where we have had authors having died since we created the author page, predominantly people with the licence of {{PD-USGov}}, though not exclusively. The data in the situation that I was looking at is in Wikidata.

If the data is in wikidata, we can right a test within {{author}} to display the data for year of death where we have left it empty. Is that something that contributors like to see done? Plus if we do that, are we wanting this to be the only solution? Or are we then wishing to manually enter that data locally to the template, ie. create another maintenance task (either manual or possibly bot'able)

To note that I ran a test query with petscan that looked at pages within Category:Authors with missing death dates and then said show me pages where wikidata has a "date of death" property. There are numbers of "no value" or "unknown value" fields which would require some qualification, though that is fairly simple.

Then it poses the situation that we can do the same for missing birth dates. What would the community like done. — billinghurst sDrewth 10:30, 9 January 2017 (UTC)

There are also situations where we have the data (manually entered by someone) and Wikidata, even VIAF does not. So we should keep both options open. The Wikidata option should be default, it should be displayed as long as someone manually does not enter something. If some manual entry is made, that should override the input from Wikidata. I have seen many times that editors here make entry of birth and death years after considerable research. This practice often yields valuable information, and should not be discontinued. However, editors should be encouraged to update the concerned fields in Wikidata simultaneous with local entry. Hrishikes (talk) 12:08, 9 January 2017 (UTC)
might want to think about author template pulling items from wikidata and edit data there. if you find a source, update it and include url reference. Slowking4RAN's revenge 02:33, 17 January 2017 (UTC)
Wikidata sometimes lists more than one date of birth or death, especially for ancient and classical authors, where sources disagree about the date. There is also the issue that Wikidata sometimes records dates using the Julian calendar or other systems, according to whatever source was cited for the date. --EncycloPetey (talk) 02:36, 17 January 2017 (UTC)
@Slowking4: That is why I am asking, it is a technical vs. social question. What does the community want?
@EncycloPetey: That is all able to be identified and managed if we choose to take the WD-populated approach. 1) if multiple dates of birth we can always take the preferred. 2) If it is a Julian date, we can call back that qualifier, too. If we can identify what we want to do, then we can identify how we do, and a plan to avoid the pitfalls. — billinghurst sDrewth 06:14, 17 January 2017 (UTC)

Actually as I asked the question, I didn't express an opinion, though that I asked at all flags my general thoughts. Some thoughts, philosophically I would like to be able to use a set of authoritative or best known data for our {{author}} and {{header}} templates. I would much rather have data stored in WD, and be widely available, searchable and retrievable, rather than bottled-up here, and I would much rather have data entered correctly once, than in multiple places. [Call me lazy] That said we don't want dodgy data, and we do want the ability to readily manage data, so we want to have the ability to set up alerts and warnings.

If we do have our data well-populated at WD, I see that it offers us more, much more, enabling smart tools to do smart things. An example of the bigger sorts of things that we could do is use ListeriaBot to generate all our Wikisource:Authors-... pages and to update on a regular basis. For that we need 1) all authors in WD, and on author items 2) first and family names, 3) dates/years of birth and death, 4) a descriptor.

We can set up WD at a passive level, and do some mix and match with available tools, or by use of categories to identify where data differs between our data and WD data. In the end it is about what level of control, and whether we wish to manually enter data, and have it potentially out-of-date, or to let the system populate, and us to overview. — billinghurst sDrewth 06:14, 17 January 2017 (UTC)

@Billinghurst: I think that if data for blank parameters is in Wikidata then we should use it. Also, as @Slowking4 says, that if the {{author}} template uses Wikidata data, then any wrong dates can be fixed over there instead. I've been investigating converting the date-handling bits of {{author}} to Lua (in Module:Author:dates()). Doing that would mean the various confusions around multiple dates and different qualifiers etc. could be handled with more ease than is the case in pure wikitext (e.g. multiple possible years for Author:David (1039 BCE/1040 BCE – 969 BCE/970 BCE) rather than just 'circa' (c. 1040 BCE – c. 970 BCE), to be more accurate). We can add tracking categories for managing the cases where data is different. Do you think this is a worthwhile direction to explore?

I've started writing some test cases to make it easier to maintain too. Sam Wilson 06:20, 17 January 2017 (UTC)

Oops, I was actually replying to your earlier comment @Billinghurst (you posted as I was writing), but I'm just agreeing with you, so it sort of makes sense still. :-) I think the way forward is to use WD data where we can, and bit by bit migrate to only using it. Sam Wilson 06:26, 17 January 2017 (UTC)
@Billinghurst: What we call "first name" and "family name" here are very different from what Wikidata uses. Our values are a matter of convenience, splitting the name so that the "family name" sets the alphabetical positioning for sorting, regardless of whether it is actually the "family name" or not. Likewise, the "first name" value is the remainder of the name to complete display in the header, and not simply the "first name". Wikidata does not do it this way, so there will not be a match.
Additionally, Wikidata values will necessarily be dynamic. It is not uncommon for the primary value for a name or name element at Wikidata to be altered. This would play havoc with any kind of internal linking to Author pages if we took that information dynamically from Wikidata, or updated. --EncycloPetey (talk) 13:03, 17 January 2017 (UTC)
@EncycloPetey: I understand that there are issues to work through, datum to populate, however, our "lastname" ties to "family name" and their combinations for "first name" can align with our components of "firstname", eg. Author:Adam Storey Farrar and d:Q350994. We can and should also be demanding of the system to generate data aligned with our needs. I have started working with their team to look at utilising our template parameters to further populate their data, and one of their team is involved with frWS. We will hasten slowly and deliberately. Sitting on our hands and doing nothing, means we become static and isolated, and to me that is a danger. We need to have bots, tools, and data extraction to make us more visible, and more flexible and to do the drudge work. — billinghurst sDrewth 22:20, 17 January 2017 (UTC)
@Billinghurst: I'm thinking especially of names from Arabic and Chinese, of medieval and classical names, of names that are royal or clerical, and of pseudonyms and pen names, where the usual rules seldom apply. Whatever we choose to do will have to account for such situations and ones like them. --EncycloPetey (talk) 03:07, 18 January 2017 (UTC)
@EncycloPetey: These are definitely things to be careful of. I think a lot of it comes down to how names are represented in WD, because I think it's pretty possible to capture all the nuance that is required at Wikisource, but that sometimes people don't add all the required data (which is fine; we can just fix it up). For example, given name (P735) can contain multiple statements, and each should be given a series ordinal (P1545) qualifier to record what order the names go in. So we can recreate the Wikisource version of someone's name by joining the names together in the required order. And then we could add maintenance categories to help fix the pages where the page title doesn't match what is retrieved from Wikidata. Do you have some examples of authors to examine?

Anyway, I think the current discussion is just about dates isn't it? (Specifically the idea to use Wikidata where there's no local date given.) Should we defer the discussion of names until the dates are sorted out? Sam Wilson 03:41, 18 January 2017 (UTC)

@Billinghurst: what do you think of the idea of switching {{author}} to using Module:Author? It should leave everything pretty much as it is, but also give us Category:Authors with birth dates differing from Wikidata and Category:Authors with death dates differing from Wikidata as a means to find problems. Do you have example authors with particularly weird dates? —Sam Wilson 06:02, 23 January 2017 (UTC)
Some examples of authors with weird dates:
All of these are from Category:Ancient Roman authors, and there are more besides—some with two birth dates separated by a slash and such. --EncycloPetey (talk) 17:45, 2 February 2017 (UTC)
Hm, yeah, there's some weird ones! :) Will try to fix...
Sam Wilson 01:49, 3 February 2017 (UTC)
Pictogram voting comment.svg Comment why are we trying to generate vague years of birth and death in such situations, we simply should be using floriut. It is something that we would do well to reflect upon with wikidata availability. — billinghurst sDrewth 05:00, 3 February 2017 (UTC)
I think that (4th century – 4th century) and (1st century BCE – 1st century BCE) should just be rendered as (4th century) and (1st century BCE) respectively; I think that's what most editors have done with the dates parameter in the past for such authors. However, if that's too much bother, I don't think it matters very much. —Beleg Tâl (talk) 12:40, 3 February 2017 (UTC)
Typo: floruit, and I think using that in any instance where the birth and death dates are identical would be a good approach. --EncycloPetey (talk) 12:43, 3 February 2017 (UTC)
Yes, nice. YesYbillinghurst sDrewth 00:50, 4 February 2017 (UTC)
  • Pictogram voting comment.svg Comment I edited Author:Quintus Curtius Rufus and found out that the qualifier for a date of death was "presumably" at wikidata, which is pretty weird . As we didn't plan for such use we didn't give a "c." marker, we may wish to monitor for it. (Personally I think that they should be corrected, which is what I did for this at WD.)

Wikidata date guidance[edit]

Cleanups required ...[edit]

Looking at the some of the pages that are throwing up errors, I see that there are some practices that have taken place that are not ideal, especially if we can automate data. Some of these are also unnecessary as the author template had also means to handle some uncertainty. So without discussing the value of the parameters are sourced here or at WD, there is cleanup. We should maybe classify what needs to be done to what is clearly needed doing, and stuff that should be discussed in some depth. (Please feel free to add to the list)

Uncontroversial tasks

  • remove birthyear = ?
  • remove deathyear = ?
  • remove dates = ?-? and variations

Other tasks

Shall we proceed with these?— Mpaa (talk) 20:28, 13 February 2017 (UTC)
Good idea. I'm confused about the categories though. Is the current idea is that authors with empty birth or death dates (i.e. empty here and on Wikidata) are categorised in Category:Authors with missing birth dates, but if we "know that we don't know" then they're in Category:Authors with unknown birth dates? What's the difference between Category:Authors with unknown birth dates and Category:? births (and their 'death' counterparts)? On the face of it I think we only need:
  1. Category:Authors with missing birth dates
  2. Category:Authors with missing death dates
  3. Category:Living authors
There's no difference between a 'missing' and an 'unknown' birth date, because every author was born. The only difference comes with death dates, because living authors don't have death dates but that's not because they're missing.
With regard to displaying the dates and question marks, I think a missing birth or death date should be displayed as a '?', because for living people we already leave a blank death date after the dash (e.g. "?–1890" or "1840–?" for dead authors, or "1940–" for a living author). Alternatively, we could go the Wikipedia MoS route and do "b. 1940" for living authors, so that any dates with a dash would end with a date or a question mark. Or maybe just write "(living)" or something after instead?
Sam Wilson 02:08, 14 February 2017 (UTC)
How are you going to tell the difference between a living person, and a person with no death data? If they were born a loooong time ago (>120 years), then we can assume that they are dead, and apply "?", if they are marked as death date unknown/not recorded at WD, then we can apply a "?". If there is nothing shown, and < 120 years I will presume that we will regard as (presumed) living. I am happy with no terminator, it is understood and is easier to do automagically. To complicate matters, we are starting to get modern works that are freely licensed papers, and typically we don't have dates of life for these authors. So to me it seems wrong to manage that as ?–? for an author of a 2017 paper is not pertinent. Plus we are going to need to manage two different scenarios of "no birth date/no death date". I would always recommend play it safe, and we wait until there is some data like floruit or like showing which we can hang off and apply ?–? to it. — billinghurst sDrewth 06:29, 14 February 2017 (UTC)
I think we just have to assume that if no death date is given then they're alive, because it's easy to add 'unknown value' as the death date if they're known to be dead. At least, this seems to be the way it's working on Wikidata. The Author module here also takes "death date = no value" to mean living. We could additionally not mark people born more than 120 years ago as living (seems sensible to me) but we should really just do this as a way of tracking who needs to be updated at wikidata.

For the 2017 author example, I guess the current answer would be (20th century –); does this sound okay?

Birth dates are different in all this, because every author either has one or it is "unknown", so I think we only need Category:Authors with missing birth dates. Death dates have three states: known, unknown, and "living" (or no value). What do we need the other categories for?

Sam Wilson 02:49, 15 February 2017 (UTC)

Index:Majjhima Nikāya.djvu[edit]

Non english work? Uploaded for translation? ShakespeareFan00 (talk) 21:25, 2 February 2017 (UTC)

Creation of an index page is within scope. — billinghurst sDrewth 23:04, 2 February 2017 (UTC)

Disambiguation in Translation: namespace[edit]

We need to update {{disambiguation}} to work in the Translation: namespace. Parked here in case someone gets the time to do it before I do. We need to fix Translation:Penal Code of Thailand.

In fact there is a bit of work to do around those works as there is a portal-type construction going on there around dynamic laws, contrary to WS:WWI. Though one thing at a time. — billinghurst sDrewth 22:55, 2 February 2017 (UTC)

Why not limit {{disambiguation}} to the Main namespace. If there is a page in the Translation namespace that needs to function as a disambiguator (as we have here), then redirect it to the Main namespace for disambiguation, and link to entities there. Otherwise, we could end up with situations where we duplicate disambiguation lists in two different namespaces (e.g. when there are one or more copies in the Main namespace and one or more in the Translations namespace). --EncycloPetey (talk) 23:57, 2 February 2017 (UTC)
There was some similar commentary in /Archives/2016-10#Disambiguation and Wikidata items — a conundrum with no perfect solution by Hesperian. So are you thinking that no disambiguation in Translation: namespace, and that we utilise main namespace with templates disambiguation/versions/translations. — billinghurst sDrewth 05:27, 3 February 2017 (UTC)
I think that would be the simplest solution. The alternative would be to follow what the Italian Wikisource has started doing, and create an entirely new "Work:" namespace where information about any work is stored, including all versions/translations listings. However, I'm not decided in my own mind that their approach is a good or necessary change. --EncycloPetey (talk) 12:41, 3 February 2017 (UTC)
I agree that translations should be disambiguated in mainspace (Odes is an okay example). This is especially true since occasionally works in mainspace and works in Translation space need to be disambiguated from each other. —Beleg Tâl (talk) 12:46, 3 February 2017 (UTC)

Attempting a summary[edit]

We are therefore saying

  1. disambiguate only once per title variation (all namespaces);
  2. {{disambiguation}} can be used in one of three namespaces of Main, Author, Portal; and not in Translation, shouldn't be required elsewhere, think that there is one in Wikisource:
  3. that where {{disambiguation}} is used it will initially occur in the namespace of the conflict; and if there is a title conflict in the main namespace with other namespaces (portal, author, translation), then the disambiguation will only take place in main namespace, and not be duplicated in other namespaces.

OR; I could more aggressively read the above comment to replace the last dot point as

  1. (as above)
  2. (as above)
  3. All disambiguation shall take place for all namespaces in the main namespaces, irrespective of where the conflict takes place.
    Noting that the consequence of this variation would be that we would need to consider the status of all existing disambiguation pages outside of the main namespace (currently 250+ in Author, 5 in Portal


  • Any further comment?
  • Should we prod the broader community for their opinion prior to next steps? Yes check.svg Done
  • What about guidance {{versions}} and {{translations}} which both could be used in Translation: namespace — noting that they are not currently.

Required outputs:

  • Update Help:Disambiguation
  • Possibly update existing disambiguation pages
  • Possible tracking of use of templates (either Petscan or tracking categories)

billinghurst sDrewth 06:06, 5 February 2017 (UTC)

Pictogram voting comment.svg Comment Watchlist announcement put in place for all logged-in users. Suggested close of RFC: 14 February 2017

Comment about disambiguation change[edit]

I think that your summary #2 is the best option. I think it is worth noting that pages in mainspace and pages in Translation space are closely related, in that they are both works. Thus, a work called (say) Tim Jones could exist in mainspace, and another different work called Tim Jones could exist in Translation space. In such a case, Wikisource would have two hosted works entitled Tim Jones, and it would be useful to disambiguate between them; the appropriate place for such a disambiguation would be mainspace.
I am not sure about {{translations}} and {{versions}} without specific use cases. It seems to me that {{versions}} would be utterly inappropriate in Translations space, since {{translations}} is essentially the same thing as {{versions}} but for translations, and every single work in Translations space is a translation. I could see {{translations}} being used in Translation space if there were multiple Wikisource translations of the same work, but even then I would put the disambig page in mainspace. An example would be İstiklâl Marşı. Sometimes of course there will be a mix of translations in mainspace and in Translation space, such as The Internationale. —Beleg Tâl (talk) 17:37, 5 February 2017 (UTC)
You've misunderstood. The items given above constitute a summary, not a list of options. We're not choosing one of them; we're choosing all of them, or modifying them as needed. --EncycloPetey (talk) 17:42, 5 February 2017 (UTC)
Yes, it appears I did misunderstand. I think that mainspace works and Translation space works are both works, and therefore should be disambiguated with each other, and such disambiguation page should be in mainspace only. I think that Author space pages and Portal space pages are not works and should not require disambiguation with works in either mainspace or Translation space, even if the names are the same (e.g. St. Francis of Assisi and Author:Francis of Assisi) although in such case a link from one space to the other could be appropriate as in the example. I don't think this view aligns with either summary above, so do with my two cents as you will. —Beleg Tâl (talk) 01:57, 6 February 2017 (UTC)
The one comment to add here, and it was what provoked the previous thread (linked above) is that a disambiguation page we can only have one link to English Wikisource from Wikidata (like all interwiki links). So if Wikidata has the disambiguation page "John Smith" that can only be linked to once so would take main ns Whilst there could also be a disambiguation page "Author:John Smith" it would sit separate from the other disambig page, it would presumably never have a pairing page. And at the moment our linking to Wikidata from our content namespaces ignores the namespace nomenclature, so it would add complexity. That may not matter, and should not be the determinator, it is something to note, and consider. — billinghurst sDrewth 05:51, 6 February 2017 (UTC)
I personally do not think that that is a major problem, at least not for us. Commons has an issue where a given person might have a gallery in mainspace, a category in Category space, and a Creator space page as well, but only one page can be listed for Commons as an interwiki link. I understand that Wikidata is doing its best to accomodate Commons, rather than Commons accomodating Wikidata. In our case, I do not think that the benefit of having automatic interwiki links on our disambig pages is sufficient to justify the great undertaking of merging all disambiguation pages to mainspace. —Beleg Tâl (talk) 13:07, 6 February 2017 (UTC)
And to elaborate further: we do have instances where a work exists in multiple namespaces at once, e.g. Matthew (Bible) (the work) and Portal:Gospel of Matthew (works about the work), which has the same problem as having a disambiguation exist in multiple namespaces at once. —Beleg Tâl (talk) 13:13, 6 February 2017 (UTC)
Well, yes and no. There is no reason that Portal:Gospel of Matthew will be limited to copies of Matthew's gospel, or to works title "Matthew", but the page for Matthew (Bible) and Matthew are necessarily so limited. And it is always possible to have a more broadly defined portal that simply points to a disambiguation page for that portion of its content, but more likely it will contain a richer source of information. Consider Portal:Ancient Greek drama as an example of a Portal presentation that does list the translations of various Greek tragedies, but do so in a completely different sort of way from the associated disambiguation pages. So, I don't think the situation of having some duplication between Main namespace disambiguation and Portal namespace is especially relevant. --EncycloPetey (talk) 04:46, 8 February 2017 (UTC)
I think perhaps you have misunderstood me. What I mean is this, with a better example:
  • The item that is the Gospel of John, represented on Wikidata as d:Q36766, has two pages on Wikisource: John (gospel) listing translations of this item, and Portal:Gospel of John listing works related to this item.
  • The item that is disambiguation on "John", represented on Wikidata as d:Q397210, has two pages on Wikisource: John listing works labelled as this item, and Author:John listing people labelled as this item.
To me these scenarios are functionally equivalent and therefore quite relevant to the discussion. It is common practice to split a logical item into pages in separate namespaces with separate functions, and this is true of both disambig pages and work pages. —Beleg Tâl (talk) 13:49, 8 February 2017 (UTC)
Further to the above: if people really want to consolidate disambig pages from works, authors, and portals all on one page, I would not oppose a move in that direction, and in that case would prefer all such disambig pages to be in mainspace. —Beleg Tâl (talk) 04:09, 6 February 2017 (UTC)

I vote for mainspace-only. In my view:

  1. Disambiguation pages (and also versions pages and translations pages) are in essence curated search results: a user types something into the search box, and, rather than let it be handled by the search tool, we intercept it and present a list of the things they were likely looking for. Or, a user follows an incorrect (because ambiguous) link, and we present a list of the things they were likely looking for.
  2. With respect to the search box case: Only our experienced users (i.e. mainly our editors) know to type "Author:George Bush" into the search box, and we don't really need to worry about them—they will find what they are looking for. Our inexperienced users will type "George Bush" every time, and we must respond to this by taking them to our curated content, else there's no point having it. At present, these users get presented with search results, because George Bush doesn't exist. This suggests mainspace-only disambiguation pages are the way to go.
    aside @Hesperian: did you see #SEARCH: Subphrase matching. I am of a mind to ask whether the default for the community (anon and new) could be set to subphrase. That partially addresses the cases that you mention. — billinghurst sDrewth 05:16, 8 February 2017 (UTC)
  3. With respect to the incorrect link case, this is best handled by us editors not creating such links in the first place. I know if I add a link that points to Author:George Bush and it comes up blue in preview, then I'll probably save without looking at the target. Thus we build up a heap of incorrect links to Author:George Bush, and these links then serve to justify the existence of the page. But if the page didn't exist, the link would have come up red, and I would have checked and disambiguated.

Hesperian 04:27, 8 February 2017 (UTC)

Matthew Henry's earlier edition[edit]

PeterR2 found a 1721 edition edition of Matthew Henry's An Exposition of the Old and New Testament (1828). It is not the whole thing, just the last folio in a four-volume set. I had started working on the later edition because I thought that the whole Bible version was not published until the nineteenth century. Matthew Henry died before finishing the final volume and other people completed it from his notes. Originally I thought that it was not published until about a century later, but I was definitely wrong. It has wonderful old-timey typography. In any case, the pdf is originally at Princeton, where I do not have a library account. Are there any legal concerns with moving the volume to Commons? Does anybody have access to download the pdf? Heyzeuss (talk) 18:46, 3 February 2017 (UTC)

I'm not sure I follow entirely, but if your only problem is downloading the work from HathiTrust, I've compiled instructions for how to do so without a login here. --Mukkakukaku (talk) 22:28, 5 February 2017 (UTC)
How, Mukkakukaku? I can download image or .PDF as single files and put them all together as one .PDF file but all single .PDFs have extra information added to both sides of the scan. It is as though each scan is placed on a larger sheet of white paper that has watermarks and information. —Maury (talk) 22:40, 5 February 2017 (UTC)
Another point, I have never had to log in here to download anything from HathiTrust and I have downloaded several works from HathiTrust but usually one page at a time. —Maury (talk) 00:10, 6 February 2017 (UTC)
Oh, okay, on your user page - I thought you meant you placed that on Wikisource or had it in a file on your computer. I am in the USA and I do use Firefox. —Maury (talk) 00:15, 6 February 2017 (UTC)
DownThemAll of Firefox is good for those sites (like DLI) where pages are individually numbered. In HathiTrust, all pages are named "image", without numbering. During batch download, smaller files get downloaded earlier. So they get renamed as per chronology of download, not original order in the book. Moreover, text pages are in png format and image pages in jpg format; so they get renamed separately. To overcome this problem, I am using Hathi Download Helper for downloading from HathiTrust. It is a free software, you only need to enter the id of the work. You can save the work in pdf, images etc, ocr option is also there. Hrishikes (talk) 01:26, 6 February 2017 (UTC)
Thank you, Hrishikes. Typically I have been working with Adobe Acrobat 11.0.08 and learned several ways to work with files from there, pdf, png, or jpg. But I have downloaded DownThemAll and I will download what you have suggested to see what those programs will do. I don’t know why Mukkakukaku would make such an excellent statement and then not answer a question about it. Again, thank you, —Maury (talk) 13:06, 6 February 2017 (UTC)
Oh, another tip for whomever, those files named "image" can easily be renamed and an extension placed on it. For example, if I want 3 image files and it shows "image" I will give them a number page 344.jpg, 345.jpg, 346.jpg By numbering them in sequence they remain that way, in (alpha/numerical) order after downloading.—Maury (talk) 13:20, 6 February 2017 (UTC)
Sorry, Maury, I didn't see your question. I hope Hrishikes was able to clarify things for you. (I personally have never had the problem them mentioned about downloaded pages being out of order, but I'm definitely going to check out the download helper tool recommended above.) For naming the files I usually apply a mask to get them numbered, something like *name**inum*.*ext*, but I think you figured this out already. :) --Mukkakukaku (talk) 04:02, 7 February 2017 (UTC)
No problem, Mukkakukaku. I thought perhaps you were still in this area but I found your user page. The program is one I had not used and I was curious about it. Hrishikes posted a very good explanation for the both of us. My thanks to the both of you for mentioning and clarifying the programs. Respects, —Maury (talk) 04:10, 7 February 2017 (UTC)
Just wondering whether anything further happened about this, Heyzeuss? PeterR2 (talk) 08:53, 18 February 2017 (UTC)

Index:The International Code of Marketing of Breast-milk Substitutes.pdf[edit]

Was raised at CV a long time ago, Scans now deleted at Commons, which means it needs cleanup, anyone?

ShakespeareFan00 (talk) 11:48, 6 February 2017 (UTC)

See - for page links.

Thanks.ShakespeareFan00 (talk) 11:51, 6 February 2017 (UTC)

And the Page: s ? ShakespeareFan00 (talk) 12:39, 7 February 2017 (UTC)
Done.— Mpaa (talk) 21:59, 7 February 2017 (UTC)

Tech News: 2017-06[edit]

19:45, 6 February 2017 (UTC)

Fix coming this week[edit]

At the advanced Special:Search the use of MediaWiki:Powersearch-ns was broken for the use of wikilkinks. I reported it this week, and a fix is is in the code and expected to be rolled out this week. Once this is rolled out then we can mark this as resolved. The fix expected is that wikilink code will become a wikilink. — billinghurst sDrewth 11:03, 7 February 2017 (UTC)

Proofread progress bar[edit]

Hi all, any chance we can get the proofread progress bar mw:Proofreadhelp#Proofreading_status_indicator next to listed works, or wherever we want it for each individual work. For example in portals or our user pages, where works are listed, to help with seeing where each individual work is at in the proofreading process. Is it possible?Jpez (talk) 10:37, 9 February 2017 (UTC)

@Jpez: It has been previously talked about and there is a phabricator ticket somewhere, so no. BUT! Please see recent discussions here (probably archived) about use of Special:IndexPages and it can be utilised to display a cut down list, and that list transcluded. Definitely not as perfect as what you desire, however <shrug>. — billinghurst sDrewth 21:47, 9 February 2017 (UTC)
@Jpez, @Billinghurst: It's a good idea, and wouldn't be too hard to implement I reckon. I can't find an existing phab task for it though; do you remember what it might be called? Or we can just create a new one. Sam Wilson 00:28, 10 February 2017 (UTC)
I could be dreaming that it became a phabricator ticket, and it would have been bugzilla time anyway. I cannot find it listed at mul:Wikisource:Wishlist, so it maybe was just an item discussed with Tpt or ThomasV before that. <shrug> Create a new one. — billinghurst sDrewth 01:23, 10 February 2017 (UTC)
Anyone willing to create the task? I wouldn't know where to begin myself. Jpez (talk) 12:34, 14 February 2017 (UTC)

CIA UFO reports[edit]

Hi, The CIA released last year some UFO reports [15]. I imported a few. May be some of you are interested: Index:Flying Saucers in East Germany, CIA Report.pdf. Regards, Yann (talk) 13:49, 9 February 2017 (UTC)

Errata - because life is never simple[edit]

I've run into an issue on Page:Odes of Pindar (Myers).djvu/91 with the use of {{errata}} because the error to be annotated appears within a footnote.

Does anyone technically-minded enough have the means to edit the template, or to suggest a way this might be handled? --EncycloPetey (talk) 02:58, 11 February 2017 (UTC)

Yes check.svg Done Nevermind. Found a workable solution documented at Help:Footnotes and endnotes that did the trick. --EncycloPetey (talk) 04:49, 11 February 2017 (UTC)

New problem with {{errata}}: I'm getting text overlap at Page:Odes of Pindar (Myers).djvu/98, and this appears in the transcluded version as well.

Any suggestions? --EncycloPetey (talk) 21:39, 13 February 2017 (UTC)

Should be okay now. The style you applied to the containing <div> "text-indent:-1em" also applies to any block child elements, and {{errata}} displays as inline-block. —Beleg Tâl (talk) 02:07, 14 February 2017 (UTC)

Proposal: Add Wikidata to Special:Import sources[edit]

The following discussion is closed and will soon be archived: consensus to add wikidata to approved list for import — billinghurst sDrewth 11:01, 14 March 2017 (UTC)
As with the recent discussion for imports from mediawiki and update to mul.wikisource, I would like the community to support the addition of Wikidata (d:) as a source for Special:Import. The primary reason for this is to allow administrators to directly update our modules for use of Wikidata. An example is that Module:Wikidata has been announced at d:Wikidata:Project chat as having been updated, and our only means to currently do that is a cut and paste. Cut and paste is less desirable, it adds new editors and doesn't clearly align with other versions which import will better do. Thanks. — billinghurst sDrewth 12:20, 11 February 2017 (UTC)
Symbol support vote.svg SupportBeleg Tâl (talk) 03:17, 12 February 2017 (UTC)
Symbol support vote.svg Support Seems like a no-brainer to me. --Xover (talk) 14:18, 14 February 2017 (UTC)
Symbol support vote.svg Support Sam Wilson 21:20, 14 February 2017 (UTC)
Symbol support vote.svg Support obviously sensible, thanks sDrewth. —Justin (koavf)TCM 21:49, 14 February 2017 (UTC)
Now available for admins. — billinghurst sDrewth 13:51, 15 March 2017 (UTC)

Index:Mrs Beeton's Book of Household Management.djvu[edit]

All the recipe text is now present. Much appreciated if someone could work on the 16 pages of Menus, and the Index which remain, as I'd like to focus on some other projects.

ShakespeareFan00 (talk) 12:01, 13 February 2017 (UTC)

Orphaned pages of deleted index.[edit]

Bulk speedy anyone?

ShakespeareFan00 (talk) 16:10, 13 February 2017 (UTC)

Yes check.svg DoneBeleg Tâl (talk) 18:56, 13 February 2017 (UTC)

De-Recognition of Wikimedia Hong Kong[edit]

This is an update from the Wikimedia Affiliations Committee. Translations are available.

Recognition as a Wikimedia movement affiliate — a chapter, thematic organization, or user group — is a privilege that allows an independent group to officially use the Wikimedia trademarks to further the Wikimedia mission.

The principal Wikimedia movement affiliate in the Hong Kong region is Wikimedia Hong Kong, a Wikimedia chapter recognized in 2008. As a result of Wikimedia Hong Kong’s long-standing non-compliance with reporting requirements, the Wikimedia Foundation and the Affiliations Committee have determined that Wikimedia Hong Kong’s status as a Wikimedia chapter will not be renewed after February 1, 2017.

If you have questions about what this means for the community members in your region or language areas, we have put together a basic FAQ. We also invite you to visit the main Wikimedia movement affiliates page for more information on currently active movement affiliates and more information on the Wikimedia movement affiliates system.

Posted by MediaWiki message delivery on behalf of the Affiliations Committee, 16:25, 13 February 2017 (UTC) • Please help translate to your languageGet help

Tech News: 2017-07[edit]

18:06, 13 February 2017 (UTC)

Collaboration products newsletter: 2017-02[edit]

09:40, 14 February 2017 (UTC)

Script created for assisting Fourier/FFT/descreening/half-tone removal workflows[edit]

I've assembled a bash script for assisting with workflows for removing half-toning and the resulting moire effects in scanned images. It automates a few of the tedious steps of FFT processing, automatically reprocessing an image each time an intermediary file is edited. It's primarily ripped from an ImageMagick guide, and requires ImageMagick and inotifywait.

I'm thinking of linking to this from the Commons guides to descreening: Help:Scanning and Commons:Cleaning up interference with Fourier analysis.

Any input would be appreciated. djr13 (talk) 01:00, 15 February 2017 (UTC)

Oh, that's cool. Will it run on Windows under Cygwin if I can convince ImageMagick to cooperate, do you think? --Mukkakukaku (talk) 02:43, 15 February 2017 (UTC)
It would almost certainly require significant adaptation. I'm not sure if there's a Windows compatible equivalent of inotifywait...the script could be changed to make it an optional feature though. And of course that assumes you can run bash scripts without a problem. Feel free to modify it. I put it together rather crudely. djr13 (talk) 03:36, 15 February 2017 (UTC)

Author template[edit]

Sorry everyone, I just stuffed up the author template for a moment. It's fixed now. I hiding the dates on author disambiguation pages (or rather their categories). Sam Wilson 04:36, 15 February 2017 (UTC)

@Samwilson: Thanks. —Justin (koavf)TCM 04:39, 15 February 2017 (UTC)

Review of initial updates on Wikimedia movement strategy process[edit]

Note: Apologies for cross-posting and sending in English. Message is available for translation on Meta-Wiki.

The Wikimedia movement is beginning a movement-wide strategy discussion, a process which will run throughout 2017. For 15 years, Wikimedians have worked together to build the largest free knowledge resource in human history. During this time, we've grown from a small group of editors to a diverse network of editors, developers, affiliates, readers, donors, and partners. Today, we are more than a group of websites. We are a movement rooted in values and a powerful vision: all knowledge for all people. As a movement, we have an opportunity to decide where we go from here.

This movement strategy discussion will focus on the future of our movement: where we want to go together, and what we want to achieve. We hope to design an inclusive process that makes space for everyone: editors, community leaders, affiliates, developers, readers, donors, technology platforms, institutional partners, and people we have yet to reach. There will be multiple ways to participate including on-wiki, in private spaces, and in-person meetings. You are warmly invited to join and make your voice heard.

The immediate goal is to have a strategic direction by Wikimania 2017 to help frame a discussion on how we work together toward that strategic direction.

Regular updates are being sent to the Wikimedia-l mailing list, and posted on Meta-Wiki. Beginning with this message, monthly reviews of these updates will be sent to this page as well. Sign up to receive future announcements and monthly highlights of strategy updates on your user talk page.

Here is a review of the updates that have been sent so far:

More information about the movement strategy is available on the Meta-Wiki 2017 Wikimedia movement strategy portal.

Posted by MediaWiki message delivery on behalf of the Wikimedia Foundation, 20:31, 15 February 2017 (UTC) • Please help translate to your languageGet help

How to edit a typo?[edit]

Here in the last sentence a scanning error: "We'11 have" instead of "We'll have". I am an experienced Wikipedia editor, but here after 10 mins of searching a way to edit this I decided to ask. --Neolexx (talk) 10:13, 18 February 2017 (UTC) Whatever you've done with the interface — it is way overdone.

@Neolexx: The page numbers on the left hand side of the page link through to the underlying publication with the image (from Commons). From there you can edit the text with the image. — billinghurst sDrewth 11:21, 18 February 2017 (UTC)
Thank you, done. --Neolexx (talk) 11:27, 18 February 2017 (UTC)

Short titles[edit]

Following a disscussion here:


I, felt this needed a wider disscusion.

Various items of legislation in the UK (and other Commonwealth Realms) use short titles.

English Wikisource has a Lua module accessed via a series of {{short-title}} templates.

However, those templates (which were used quite extensively by me), don't necessarily included any form of automatic disambiguation or ability to consider that different Jurisdictions may have identically titled legislation.

{{short-title/y1}} for example links to Copyright Act 1956 which is a redirect to the actual item at Copyright Act, 1956 (United Kingdom)

There hasn't to date necessarily been any consistency of titling, and I'm not aware of any semi-formalised Wikisource policy on this, so I am opening this thread with a view to establishing what the actual guidelines should be so that the relevant Lua module and dependent templates only need to broken ONCE, and that there only needs to be one set of re-titlings (or redirects) to ensure consistency across English Wikisource.

In the linked user talk disscussion, concern was also raised about the use of an "Act # of YYYY (India)" form for Indian primary legislation , on the basis that although able to link uniquely, a title of that form wasn't necessarily what potential searchers would be familiar with. I'd also note that many earlier items of UK legislation also have A regnal, Chapter form, which although identifying stuff uniquely, might not be how researches find relevant items.

My view currently was that United Kingdom acts should be suffixed (United Kingdom) to disambig them from Indian ones suffixed "(India)" and so on..

Hence you'd have:-

(Note: In the latter the Suffix might be considered redundant but is included for completeness.)

It would also be nice to have a consistent rule about when to use a Comma before the Year, for Acts passed in various Jurisdictions

So I'm opening this disscussion in the hope that someone can sort out :-

  • Consistent titling/linking guidelines.
  • Document such guidelines.
  • Update the {{short-title}} series of templates accordingly.
  • Check for existing linked items, and update links accordingly.

The eventual goal being ONE consistent and logical approach. ShakespeareFan00 (talk) 12:20, 18 February 2017 (UTC)

Read later[edit]

is there any way i can add pages to some place to read them later on other devices if there is pleas tell me and if not then tell me so that i can make one it would be nice to save pages you like to read them later on all the devices your account is logged in unsigned comment by Zia-ur-Rehman Rehmanii (talk) .

@Zia-ur-Rehman Rehmanii: You can make a book at Special:Book and choose whichever text you want to save and read later or print out as a PDF. —Justin (koavf)TCM 18:07, 18 February 2017 (UTC)
yes but that would be not as efficient as a link to that page saved in your account like a bookmark
eg. you can save it on your computer and read it in your tablet or mobile just mark the page and it is synced into all your devices @Zia-ur-Rehman Rehmanii:
@Zia-ur-Rehman Rehmanii: You can save it at User:Zia-ur-Rehman Rehmanii/Book. —Justin (koavf)TCM 18:41, 18 February 2017 (UTC)
do you mean save for offline reading if you do then it would not be synced into all your devices and if you mean a bookmark into the browser then some browsers do sync bookmark but there are these other browser which do not sync them and that's the problem
oh sorry i dint see the last part but any how that would save it like a book and that's not what you would want like massing up Wikisource just for your own benefit so that you can read the page later i just want to save the link for it so that later when i click the link i am directed to the page just like that no making useless books and massing up the Wikisource unsigned comment by Zia-ur-Rehman Rehmanii (talk) .
@Zia-ur-Rehman Rehmanii: You can save for offline reading as a PDF or you can make it on the Web and bookmark it. You can do both. It's not a problem to make user books--it's a feature. Sorry, I'm not sure about what you mean by syncing links. Firefox has a feature like this so you may want to use that browser. —Justin (koavf)TCM 19:03, 18 February 2017 (UTC)

Sir i don't think that your are getting my point lets say for example that you want to save a page to read it later in your mobile or tablet so if you save it like a book you would generally loss the link to that page itself so i just want to make it a bookmark so when i open Wikisource in my mobile or tablet there is a notification saying hay you have just bookmarked a page want to read it and when i click that link it redirects my browser to that page itself by its link not to a saved PDF file or something like that because that way i will not b able to see the categorys below the page and the tools available for simple page not for pdf files or books

Does your browser have bookmarks? If so, you can save that bookmark, and add a hashtag for the page number when you save, such as "#45" to the end of the page location to take you back to page 45. To make this portable, save the link on your user page. For example: Cape Cod (1865) Thoreau/The Plains of Nauset#45. --EncycloPetey (talk) 19:23, 18 February 2017 (UTC)

Well thank you all but i think i have founded my solution somewhere else i just gonna ma a suggestion on phabricator for something like this or i will make an extension for it thanks again

  • Pictogram voting comment.svg Comment @Zia-ur-Rehman Rehmanii: the download/print options (left sidebar) available for every work allow you to save the work in a format for you to read offline (epub/mobi/pdf/...) We prefer those over the default Special:Book, though we left the default in place. — billinghurst sDrewth 10:15, 19 February 2017 (UTC)
    And if you are on mobile technology then you should be getting those icons which you should be able to bookmark. — billinghurst sDrewth 10:17, 19 February 2017 (UTC)

Tech News: 2017-08[edit]

19:25, 20 February 2017 (UTC)

Footnote groups?[edit]

On w:Help:Cite link labels, there's a description of predefined ref group names (lower-alpha, upper-roman, etc.) that can be used to make the footnote markers for non-default groups be [a], [b], or [I], [II], and so forth; rather than something like [groupname 1], [groupname 2]. I've used that approach in various places on enwiki with reasonable success, however, on WS, with a <ref group=lower-alpha> tag, I'm instead getting [lower-alpha 1], [lower-alpha 2].

Is this a known issue? Deliberate? Can it be fixed? Worked around?

I ran into this with a work that has ordinary running footnotes throughout (that I am putting in the default group and will be collecting at the end), but for one page has inline notes in the middle of that one page (annotating a piece of Middle English poetry). --Xover (talk) 09:07, 21 February 2017 (UTC)

Wikisource does not attempt to replicate the specific footnote symbol notation of the original. Instead, we use sequential numbering, regardless of the style of footnote markings in the original. It is possible to create a separate grouping, but the process is not pretty. See Help:Footnotes and endnotes. --EncycloPetey (talk) 09:10, 21 February 2017 (UTC)
@Xover: In many cases we would transclude the work to its own page, rather than a series of works on a page. If it is on its own page then the references become a tidy set of endnotes without any need to differentiate with anything else on other pages. — billinghurst sDrewth 09:57, 21 February 2017 (UTC)
Hmm. I don't think I'm following you (sorry). The work in question is a sixty-odd page book (pamphlet?) that originally appeared as a newspaper article, with very little internal division (chapters and so forth). The only way I could see it transcluded to mainspace would be as a single unit. But perhaps I'm missing something?
Note that this is not a collection of poetry (if your meaning was that each poem would be its own page?), but a critical commentary on a literary controversy (Malone's takedown of Chatterton's fake Middle English "Rowley" poems) that happens to quote some poetry in order to illustrate its points.
The notes in question (explanations for individual words in a Middle English poem) really do belong, not only on the same page, but really just under the poem they are attached to. In the work they are distinct from all the other, normal, notes (which I am treating as EncycloPetey suggests), and really should be treated as such. Intermingling them with regular notes would, in my opinion, be very suboptimal and lose a small, but significant, amount of fidelity.
I could certainly just use a ref group name like "n", to get [n 1], but even that is pretty gross for where it'll be used. The optimal solution would be to use the lower-alpha predefined group, which, I believe, is a default part of Cite.php (which is these days a core part of MediaWiki and should be updated whenever it is). As best I can tell, that this does not work is either an error somewhere, a lack of the requisite configuration for it on WS (the note markers for each group need to be defined, as outlined on the enwiki Help: page I linked above), or functionality that has been deliberately disabled on WS for some reason (which I would be interested to know, incidentally). --Xover (talk) 10:26, 21 February 2017 (UTC)
What (non-stylistic) reason is there to use footnote groups for this particular work? Admittedly I only spot checked a few pages, but I don't see any real reason why standard footnotes won't suffice.
If you're concerned about the length of the work, you can navigate back from the footnote to where you were originally in the text by clicking the little arrow next to the on the footnote number. It's less convenient than when you're looking at a paged work, but it's the functionality that we have implemented here at this time. --Mukkakukaku (talk) 03:03, 22 February 2017 (UTC)
If there are some logical spaces to break or interrupt the work, then we can even do (on the one page) sets of transclusions, and put {{smallrefs}} in between the transclusions. There are numbers of ways to address the issue without thinking that we are having to do an exact replica. [We have already changed the presentation by doing endnotes rather than footnotes.] — billinghurst sDrewth 06:34, 22 February 2017 (UTC)

Second attempt[edit]

Ok, I seem to have been unclear, so let me make a second attempt…

My request here is primarily regarding a technical capability.

The Cite.php extension has for quite some time now been a part of MediaWiki core and included in updates of MediaWiki, and is what provides the <ref> functionality… This module has support for reference groups (using <ref group="someGroupName">), and these work also on English Wikisource. In addition to this, the module has support for some "special" group names which, when used, affect how the note marker that's displayed for the note is generated. In the default group, this is [1], [2]. In these special groups, as typically implemented (it's configurable to at least some extent), these can be [a], [b] (with the special group lower-alpha) or [I], [II] (using upper-roman), and so forth.

So… I am asking for this technical capability to be made available here, completely independently of the policy and practical questions of where it is appropriate to use it. The feature is mature, included in MediaWIki core, in use on other high-volume Wikimedia wikis, is (as best I can tell) not very costly to implement, should cause very little added maintenance (effectively none that I can see), and has no obvious drawbacks or downsides.

Now, the reason I thought to ask for this is a specific problem I ran into where having this capability would have solved the problem in a much nicer way than the workaround I eventually landed on.

The specific case, for which I wanted to use this technical capability, is in the work Cursory Observations on the Poems Attributed to Thomas Rowley (1782). This sixty-odd page book discusses Thomas Chatterton's forged Middle English poems—published in the 18th century, but passed off as being by a priest named "Thomas Rowley" in the 15th century—and tries to demonstrate why the poems in questions are modern (18th century) fakes. The work has running notes throughout (and Edmond Malone is a right bastard about footnotes, so there are a lot and they are long!) that I have implemented using the bog standard <ref> tags in the default group, and which are transcluded, using {{smallrefs}}, in a separate section after the pages of the work itself are transcluded. So far so good…

However, in the course of his takedown of the poems, Malone at one point (on one page) quotes one of the poems in its original Middle English in order to, among other things, show that Chatterton's use of Middle English words is inconsistent (and he invents words, etc.). In this poem he has annotated the text with little footnote-ish markers, that point to explanations that are then given inline in the text (in the middle of the page; not down at the bottom with the other footnotes). These are distinct from the running notes, both conceptually and concretely as implemented in the original work. That is, they are a perfect case for using reference groups. Except that absent support for the "special" group names, the note labels generated are of the form [groupname 1], [groupname 2], which, in this specific case, is really ugly and disturbing (big blue markers inside the text of a poem, even multiple ones in a single line).

To work around this lack I've used {{ref}}/{{note}} templates, but that's a really tedious and suboptimal approach, that I would really rather have tried to solve using the pre-defined group name feature of Cite.php.

The page in question is this one: Page:Cursory Observations on the Poems Attributed to Thomas Rowley (1782).pdf/52

So… There are two distinct issues here. The first is the availability of the technical capability, and the second is when, where, and how to actually use it. And on the latter issue it seems obvious that it should be used sparingly, but if we don't have that technical capability it can't be used at all; in no cases, even in ones we have as yet not thought of. --Xover (talk) 10:46, 22 February 2017 (UTC)

Another work which would benefit from this feature: Bible (Webster's)/ObadiahBeleg Tâl (talk) 13:28, 22 February 2017 (UTC)
WMF Wikis all have the same version of mw:Extension:Cite so I would presume that is simply a style issue.

Our reluctance has been addressed previously in this forum, and comes down to 1) footnotes to endnotes changes the dynamics of a work, 2) ye olde use of * † ‡ § ... is extremely limiting and becomes problematic, 3) fussing on (archaic) footnotes through a work was problematic in a shared environment, 4) pushing that approach is out of step with our guidance (use KISS). — billinghurst sDrewth 21:52, 22 February 2017 (UTC)

If it is the labelling for the grouping that you wish, you can create it manually, it is just a representation at that point. — billinghurst sDrewth 22:17, 22 February 2017 (UTC)
Pictogram voting comment.svg Comment for Page:Cursory Observations on the Poems Attributed to Thomas Rowley (1782).pdf/52 within our current setup, I would have done a reference group "∞" (pick your symbol of choice that works with Cite) and then had an inline and within-page{{smallrefs|group="∞"}}. You are wanting to keep it in situ and not as a endnote. I can see that utilising a horizontal list can have benefits, and we may wish to adapt the template to be able to force a horizontal list. — billinghurst sDrewth 22:25, 22 February 2017 (UTC)
Our reluctance to add alternate styles to reference presentation is related to once we make something available there are some who wish to slavishly replicate a work, despite the difficulties in presenting, and in further proofreading. We have experience in those (ugly) difficulties and those difficult conversations. Reproduction of works covers a spectrum, and being hard up against the "100% look" of a book doesn't work on the web in our experience, so we look to be close, though retain modern features, and be web (desk and mobile) and wiki compliant. — billinghurst sDrewth 22:45, 22 February 2017 (UTC)
all explained at w:Help:Cite link labelsbillinghurst sDrewth 05:55, 23 February 2017 (UTC)

Display of floruit dates from Wikidata[edit]

I know there was recently some work done on importing floruit dates from Wikidata and I’ve just noticed there might be a small error in the import. I’ve created author page A. M. Sanchez and corresponding Wikdata item d: Q28811762 and since there was very little to find regarding date of birth or death, I added a floruit date for the 1900s (meaning 1900-1910), which was about as accurate as I could make it.

It was imported to the author page as (fl. 1895s), so there seems to be some mistranslation going on there. I’m not sure where the import is defined or happening or I’d gladly have a look. Anyone with some more knowledge able to help here? Ping @Samwilson:, I believe you did a lot of work here? Marjoleinkl (talk) 12:25, 21 February 2017 (UTC)

@Marjoleinkl: Thanks for finding this bug! :-) I've tweaked Module:Author to hopefully better account for decade precision in all dates. Let me know if there's anything still amiss. Sam Wilson 12:41, 21 February 2017 (UTC)
See also Category:Authors with approximate floruit dates. Sam Wilson 12:43, 21 February 2017 (UTC)
Great thank you very much :) I’ll let you know if I run into other things Marjoleinkl (talk) 13:52, 21 February 2017 (UTC)
Error: Author:Corinna is categorized in Category:Living authors, despite "fl. c. 509 BCE". I assume this has happened because the Wikidata item uses floruit and there is no definitive date of death. --EncycloPetey (talk) 00:46, 26 February 2017 (UTC)
Fixed. It will now remove 'living authors' from anyone with a date more than 110 years ago. Sam Wilson 23:43, 26 February 2017 (UTC)

Trinity's Access to Research Archives — plenty of downloads available[edit]

Hi. I have found that Trinity College has both some open access and old works available as scans. See

I have started to probe "JSSISI: Journal of The Statistical and Social Inquiry Society of Ireland, 1847- " and ther eis quite an eclectic mix of stuff there. — billinghurst sDrewth 06:29, 25 February 2017 (UTC)

I need some feedback about Index:History of Greece Vol I.djvu[edit]

Since I’m not really acustomed with en.wikisource I would like some feedback and opinions about the following matters:

  1. Am I handling well the refs that span 2 pages? I copy the rest of the reference to the previus page (e.g. Page:History of Greece Vol I.djvu/59)
  2. When a new paragraph is need within a ref, I insert a newline followed by a {{nop}}. Is this the manner I should handle it? (e.g. Page:History of Greece Vol I.djvu/60)
  3. Am I supposed to link every instance of an Author that has a page in en.wikisource, and every instance of a work cited or once per page, or just once (only the first time)?
  4. Since this work cites greek classical texts in their original language, should I link the ref to el.wikisource, when the original is available? (E.g. [[Author:Plutarch|Plutarch]], [[Lives (Dryden translation)/Solon|Solon]], [[:el:Βίοι Παράλληλοι/Σόλων|c. 12]] i.e. Plutarch, Solon, c. 12)
  5. should I use the <poem> tag in cases like in the second ref of Page:History of Greece Vol I.djvu/59, or is the <br /> tag preferable?

Thank you in advance! —Ah3kal (talk) 08:10, 26 February 2017 (UTC)

@Ah3kal: some comment in reply
  1. Help:References ... we look to leave them in situ as there is a means to identify and join continuing refs. Weird or bug-eyed formatting solutions would drive us to amalgamate, ie. when there is a table split across two pages (my bane yesterday)
  2. I would usually put in a <p> or a <br/> to make up for the collapsing component. Whatever works, it isn't critical.
  3. I normally link once per chapter, and again for a link going into an endnote. We are more likely to underlink than overlink.
  4. Bit of a toughie, if you know that the work exists at the wiki, and is the author's direct work, then sure. Often with those ancient works we end up with a disambig page, and that can contain a link to the works. That is usually what I do, but that is personal. As it is rarer for a work to exist in native language it is not something that we have discussed from memory.
  5. We don't prescribe between <poem> and <br/>, personal choice to get the desired result, community did not reach a consensus and in the end it makes little difference. — billinghurst sDrewth 10:35, 26 February 2017 (UTC)
Thank you very much billinghurst. I feel a bit dumb that I didn’t notice Help:References. As for greek texts, given that el.wikisource is my homewiki, I can resolve the links to the actual texts (when no exact edition is mentioned). —Ah3kal (talk) 14:21, 26 February 2017 (UTC)
2. A {{dhr}} {double hard return) between paragraphs works too. Zoeannl (talk) 23:50, 15 March 2017 (UTC)

Tech News: 2017-09[edit]

19:55, 27 February 2017 (UTC)

Index:Mrs Beeton's Book of Household Management.djvu[edit]

I finally managed to complete the Index.

Does anyone want to validate and transclude? ShakespeareFan00 (talk) 22:09, 27 February 2017 (UTC)


I have had it, what seems like it's the logical approach isn't. Short Titles Act 1896/First Schedule/Pre Union

The last attempt to do what was thought to be reasonably standard generated a spurios table end marker |} and I am not prepared to spend yet more endless hours going round and round in circles, because I can't cope with what appear to me to be phase of the moon issues with precisely where wiki markup/LST interact in certain ways.

This has probably already been explained many times previously, so I am not going to get into yet another argument. I am considering marking ALL my efforts on this work for speedy deletion, so that someone that is actually competent with where depending on the phase of the moon specfic syntax has to go has a clean start unencumbered by previous attempts at half baked 'fixes'.

I appreciate that this may seem like you seeing me in the middle of a burnout, but having put a lot of effort into trying to get something working, I am really frustrated when making what should be a simple simplification or change brings down the entire edifice.

This isn't the only work affected. I may be considering asking for deletion of other efforts that use overly complex templates as well. ShakespeareFan00 (talk) 18:17, 1 March 2017 (UTC)

@ShakespeareFan00: If it's any consolation, I feel your frustration and I really value all you add to WMF projects. —Justin (koavf)TCM 21:00, 1 March 2017 (UTC)
Decided to take a break, and put my brain under a cold tap... The relevant fix was found... Sometimes it's better to stand well back from exploding contributors (sigh).ShakespeareFan00 (talk) 21:27, 1 March 2017 (UTC)
If you see a spurious |} it will either be due to there being two, so one is seen as raw text, or that it isn't seen as starting on a new line. — billinghurst sDrewth 01:51, 2 March 2017 (UTC)
and I usually find that it is not lunar phases when it happens to me, but the input at keyboard end. I can usually work it out when I have the code in front of me, though when you have to go through complex code in templates, it is a nightmare. Use Wikisource:Sandbox and simplify and test in parts. While sometimes it is quirks of references, or tags, it is usually me. Identify the signs and remember first principles. — billinghurst sDrewth 01:57, 2 March 2017 (UTC)
Well perhaps you can explain in simple terms why the technique used here Page:Chronological_Table_and_Index_of_the_Statutes.djvu/29 when implemented in like fashion here Page:Public General Statutes 1896.djvu/34 generates 2 different outcomes? We've had the same discussion about precisely how Mediawiki handles {{nop}}, table synatx at least twice previously, with no conclusive long-term fix to the issue being forthcoming. Why is it such a chore to have what should be near identical techniques work consistently when the SAME technique is applied in different content? (Sigh.) ShakespeareFan00 (talk) 15:32, 2 March 2017 (UTC)
No, I will not. You got yourself into that trouble with non-standard, overly complex templates. Expecting people to bale you out on a regular basis is not reasonable. There will be a coding error or difference there somewhere, you just haven't found it. Your total attention to detail is often not there, whether it be proofreading or templates. I simply do not have the time nor the patience to dig through crud like this.

We don't get into this sort of pickle as we don't go for overly complex, error-prone templates, we keep it simpler. — billinghurst sDrewth 22:44, 2 March 2017 (UTC)

Harsh, but fair.. and as it's unreasonable to expect anyone else to care deletion of anything using the overly complex templates (up to annd including my entire 8 years worth of effort) may be the simplest option. Having reached the limits of my own confidence, patience and expertise, it's perhaps time to just stop contributing altogether? I don't hold anyone else responsible for this at present, but will consider further disscusion pointless. It's a shame that I seem to have wasted my efforts, trying to make this project better, and that you've had to witness a rather public meltdown. As I was saying the other day, I blew it :(

ShakespeareFan00 (talk) 02:16, 3 March 2017 (UTC)

The current "fix" seems to be do with some very precise positioning of line-feed/carriage returns and in forcing additional nops on every template call, which seems like overkill to me. If someone is willing to loose their sanity reducing the templates concerned to the absolute minimum needed to get them working, I'd appreciate the attempt.ShakespeareFan00 (talk) 15:46, 2 March 2017 (UTC)
Second concern (as indicated previously), even when {{nop}} is implemented on the pages (and for each row of the table) an assembled page like - Short Titles Act 1896/First Schedule/6 Ann still apparently needs a convoluted template like {{table-page}}. That it works at all is a miracle. (sigh)ShakespeareFan00 (talk) 16:09, 2 March 2017 (UTC)
At the very least it would be nice to have documented somewhere (not by reading the source code directly), how LST/mediawiki/table is 'wrapping' what it thinks it's rendering, so that the quirks of it all can be better understood.

ShakespeareFan00 (talk) 16:14, 2 March 2017 (UTC)

And also today when I decided to when I decided to work on this Index:Chronological Table and Index of the Statutes.djvu, by reformatting the index using TOCstyle, yet more issues (albiet my own fault due to the precise paramaters calling that template needs.) when trying to input all the relevant formatting. When something is too complex for normal users to use without additional tools (like enhanced editors and so on), a fundamental rethink of certain assumptions are needed on the part of the entire community. Sadly I don't see solutions like Visual Editor being ready for Wikisource use any time before the next ice age...

ShakespeareFan00 (talk) 20:47, 2 March 2017 (UTC)

I do think there is a lot of template bloat when it comes to tables. I prefer to stick with the default syntax, {{ts}}, and a few basic special cases ({{multicol}} and {{TOC begin}} and related). I find it is generally a waste of time to try to get a giant uber-complex template to work in all cases. —Beleg Tâl (talk) 21:04, 2 March 2017 (UTC)
while i in general like the look and feel of the customization that we can do, after a certain point i have to weigh the effort versus effect. if it truly is enough for you now, then maybe it is a good time to reassess or reconsider the choices that led you here. and then adjust them a little so that your productivity / mental health is greater, even if you had to make an aesthetic compromise. if you want to establish a MOS about certain cases, set it up in user space, and we can brainstorm and have a SOP going forward. Slowking4SvG's revenge 23:23, 3 March 2017 (UTC)

Archaic spelling in titles...[edit]

In giving something a second look I thought it might be worth noting some things in regard to older titles. - Page:Public General Statutes 1896.djvu/34

However {{SIC}} to me would seem to be more for printer errors, which isn't what's happening here. There did not seem to be an {{archaic}} to mark titles/spellings which whilst correct are not necessarily modern usage.

Would it be reasonable to consider forking {{SIC}} so that an additional note can be added in the popup?

The thought was to write some like {{oldspell}} or something. ShakespeareFan00 (talk) 13:38, 2 March 2017 (UTC)

I was also wanting to ask how tooltips are implemented because I might want to use them to add certain annotations in portal space. ShakespeareFan00 (talk) 22:20, 2 March 2017 (UTC)
Wikisource:Annotations is your guide here. I am not sure why we need to make any commentary whatsoever. If the term is uncertain then link to Wiktionary for the meaning where they will mark the definition as archaic. — billinghurst sDrewth 22:37, 2 March 2017 (UTC)
Also I would be very reluctant to use tooltips for things because they're incompatible with mobile devices. But if you really want to, you can use the title= parameter on the HTML tag. See, for example these last few words which have a tooltip. (But as you can see there's no outward styling on the previous sentence to indicate that there might be a tooltip -- something else to keep in mind. The principle of "discoverability" is very important in usability/user interface design.) --Mukkakukaku (talk) 01:27, 3 March 2017 (UTC)
@Mukkakukaku: when you say incompatible, do you mean that they don't show, or they break something? The former is perfectly acceptable as it leave the work in a natural state; the latter is not acceptable and if happening should be raised for resolution. — billinghurst sDrewth 01:54, 3 March 2017 (UTC)
When I say "incompatible", I mean that doing it the standard way with just a title attribute doesn't work on mobile devices. Since it's fundamentally impossible to hover over an element using a touch screen, such interfaces are fundamentally incompatible. The {{tooltip}} template, as far as I can tell, implements just a title attribute as well, plus some styling to let you know that you can hover over the box.
If we had a template that provided both a hover tooltip and a tap-to-show tooltip, that would be compatible with mobile devices -- but we don't as far as I know. --Mukkakukaku (talk) 16:58, 5 March 2017 (UTC)
I agree with user:billinghurst that there is no need to mark up archaic spelling in any way. I would also like to point out to all interested that {{tooltip}} exists. —Beleg Tâl (talk) 01:13, 4 March 2017 (UTC)

Index:An Answer to the Declaration of the American Congress.djvu[edit]

This is using an experimental template {{sn-paragraph}} which has got sufficiently complex that it's no longer understandable. I've reverted my attempts to fix it back to the previous contributors attempt. I am of the view that someone ought to just nuke the incomplete effort and start again with the ONE approach that's seemingly been agreed upon for sidenotes, (even if it seems to be broken in page namespace display). ShakespeareFan00 (talk) 23:07, 2 March 2017 (UTC)

The process for that would still be WS:PD not here. — billinghurst sDrewth 01:50, 3 March 2017 (UTC)
Starting a new disscusion there then ShakespeareFan00 (talk) 02:28, 3 March 2017 (UTC)

Announcement: Change to transclusion checker tool[edit]

Following a change to ProofreadPage in January, the transclusion checker tool needed to be updated. Then change is that the transclusion checker (available from each Index: ns page) now only reports for transclusions in the main namespace. I will need to go back and check each rechack each work we have changed a works status to either proofread and validated to ensure that they have been properly transcluded, and will get to that over the next week or so. — billinghurst sDrewth 01:34, 5 March 2017 (UTC)

What is the impact of this change? The only other namespace that I am aware of where Indexes get transcluded is Translation space, and there are a number of ProofreadPage features that are lacking there, so to me this says nothing beyond "transclusions to mainspace are still checked as before". —Beleg Tâl (talk) 02:31, 5 March 2017 (UTC)
The notification is here primarily as a courtesy. It means what it means. The practical difference is nothing for most eyes who hadn't noticed that the tool check was problematic for a period (as said there is a change in the tool due to the changes in ProofreadPage). The only thing that most may notice from December is that pages that are transcluded to the Index: page (ToCs) would show then, not now. If we want Translation: ns checked then we can ask to have those included. — billinghurst sDrewth 05:08, 5 March 2017 (UTC)

HTH moment[edit]

It's amazing what happens when you do something else entirely for a bit.

I've found out why some of my templates didn't work... because they would have NEVER worked as intended. So I was about to start converting all uses of them into something else when, I found something... buried in the documentation for {{left sidenote}} was a note about dynamic layouts ( in effect Wikisource's version of CSS stylesheets?) and following the help there I "tweaked" the sample to be roughly the same as the inlined CSS in the template that was creating so much difficulty, I put the custom layout in my Vector.JS and, so far it worked as designed. Well in mainspace at least, I can't say it's working in Page and User: but that may be due to Ui elements being called different things.

8 years of being wrong.. 8 Years! (Sigh). ShakespeareFan00 (talk) 22:17, 5 March 2017 (UTC)

Tech News: 2017-10[edit]

23:23, 6 March 2017 (UTC)

Edit window limitations[edit]

Do we have a new vertical size limit on the edit window? Today, I can't extend the window to the same size as the neighboring DjVu page image, which I was able to do as recently as yesterday. Today, I drag the size down, and hit a sticking point beyond which it will not extend. --EncycloPetey (talk) 04:05, 9 March 2017 (UTC)

Firefox 51.0.1 allows me to expand the edit box to the same height as the image, which is not unexpected in a table or div. — billinghurst sDrewth 05:54, 9 March 2017 (UTC)
My Firefox 51.0.1 allowed me to do so yesterday (and in all times past), but not today. Now, my edit window is limited to a height which is decidedly shorter than the image. --EncycloPetey (talk) 05:57, 9 March 2017 (UTC)
Have you been using Visual Editor, or have you upgraded to Firefox 52.0 ?

ShakespeareFan00 (talk) 19:56, 9 March 2017 (UTC)

Neither. --EncycloPetey (talk) 02:43, 10 March 2017 (UTC)
I have checked in Chrome (56.0.2924.87) and Firefox (51.0.1), the edit window can be dragged to bigger size vertically than the scanned page. So the problem may be local. Hrishikes (talk) 03:11, 10 March 2017 (UTC)
I've been having this problem on two different computers, running different OS (Windows / MacOS) but with Firefox. Lately the situation has changed slightly. I still get a maximum size at which point I can't increase the size of the edit window, however it's no longer always shorter than the accompanying image. Previously, the sticking point was always relative to the size of the image at about the same place (~90% of the image size). But now the sticking point seems to be at a fixed size irrespective of the size of the image. So now, my edit window can sometimes go larger (but only so far), and sometimes only short, depending on the djvu file I'm working with. --EncycloPetey (talk) 17:42, 16 March 2017 (UTC)
I wonder if it's related to this recently reported problem, which was ultimately blamed on a long-forgotten user script. Whatamidoing (WMF) (talk) 16:54, 18 March 2017 (UTC)
If so, it's a different tweak than it is here. I have no such code in my common.css to cause that problem. Also, my issue is a maximum size when I change it, not an externally forced window height that needs to be adjusted. --EncycloPetey (talk) 17:20, 18 March 2017 (UTC)

Overview #2 of updates on Wikimedia movement strategy process[edit]

Note: Apologies for cross-posting and sending in English. This message is available for translation on Meta-Wiki.

As we mentioned last month, the Wikimedia movement is beginning a movement-wide strategy discussion, a process which will run throughout 2017. This movement strategy discussion will focus on the future of our movement: where we want to go together, and what we want to achieve.

Regular updates are being sent to the Wikimedia-l mailing list, and posted on Meta-Wiki. Each month, we are sending overviews of these updates to this page as well. Sign up to receive future announcements and monthly highlights of strategy updates on your user talk page.

Here is a overview of the updates that have been sent since our message last month:

More information about the movement strategy is available on the Meta-Wiki 2017 Wikimedia movement strategy portal.

Posted by MediaWiki message delivery on behalf of the Wikimedia Foundation, 19:43, 9 March 2017 (UTC) • Please help translate to your languageGet help

Problematic work Indian Copyright Law[edit]

@Hrishikes, @Mahitgar, @Ciridae: Somewhere, somehow, under the general watch of this community, the work at Indian Copyright Law stopped being an edition and has become a bit of a mess as an annotated document. WS:WWI clearly states that we are not trying to have "current" law or dynamically adapt works; we have editions. It would seem that we need to pare back that work to an edition, and to get it named for the edition, then look to disambiguate as required for other versions of the law. — billinghurst sDrewth 01:35, 10 March 2017 (UTC)

The dynamic law is required, for linking from various copyright templates and also for generally citing the law anywhere. If an "edition" is needed, then the version at can be added here and used as the source file; this version, however, is updated upto the 1999 amendment and does not incorporate the 2012 amendment. Should I add it? Hrishikes (talk) 01:48, 10 March 2017 (UTC)
Now added: Index:Indian Copyright Act, 1957 (updated upto 1999).djvu. This may serve as the edition. Hrishikes (talk) 02:14, 10 March 2017 (UTC)
We do not limit the number of (differing) editions of a work that can exist, they just need to be of a point in time. We are not trying to be the site that is for the law as it is today, we are not that reliable. We do serve a purpose of "as a day here is what an edition said". So I have to challenge your statement that dynamic law is required, maybe it is, however, it if it is here, then it is a string of editions to the current, not amending a single version here. — billinghurst sDrewth 05:29, 10 March 2017 (UTC)
Also to note that if a version is available as an electronic document, then we do not need to step through transcription process against a scanned version. Just put it into place and we mark it as electronic. (and I/we need to fix up that approach.) — billinghurst sDrewth 05:34, 10 March 2017 (UTC)
@Billinghurst: I am still confused, things are not clear to me. Indian Copyright act 1957 has 6 amendments, So what do you mean by edition is
  1. Indian Copyright act 1957 + 1'st amendment = Second edition after amendments (Since Indian Copyright act 1957 initself amounts to be first edition.)
  2. Indian Copyright act 1957 + 1'st+2'nd amendment = Third edition after amendments
  3. Indian Copyright act 1957 + 1'st+2'nd + 3rd amendment = Fourth edition after amendment
  4. Indian Copyright act 1957 + 1'st+2'nd + 3rd+ 4th amendment = Fifth edition
  5. Indian Copyright act 1957 + 1'st+2'nd + 3rd+ 4th+ 5th amendment = sixth edition
  6. Indian Copyright act 1957 + 1'st+2'nd + 3rd+ 4th+ 5th + 6th amendment = seventh edition
What do I mean by edition is as above. Now problem before online (even ofline) Indic community is all these editions either are not available and where those are available are usually copyrighted; since this edition creation is usually done by non-govt agencies or indivisuals is usually copyrighted and fair dealing provisions can not be used easily, And many Indic wikimpedians suffer much more and end up using some wrong editions from online. Getting copyright free versions of these editions is not an easy job. My personal experience is Indian leagal fraternity still doesnot look wiki projects favourably enough.
So we need to develope these editions for supporting Indic wiki community for sure. We need to know whether and to what extant english wikisource allows this edition creation on english wikisource itself. To that extant we will keep here the rest of the activity we will need to find some other project if en-wikisource declines to allow the same.
As far as acuracy is concerned undersigned plans to create and cross-verify these editions with help of copyrighted sources. With the help of various law colleges from Maharashtra. Basically other copyrighted versions do have copyrigh mainly due to their arrangement and style. Since wikiprojects will be creating editions indipendantly and follow a separate style guide system we will not have copyright issues when we use copyrighted versions just for cross confirmations of accuracy only.
Please do guide me exactlly which points of above can not be covered in en-wikisource and we need to look for some other arrangements.
Mahitgar (talk) 06:32, 10 March 2017 (UTC)
Yes, there need to be (eventually) multiple editions. However, they should be disambiguated by year. i.e.
Beeswaxcandle (talk) 07:00, 10 March 2017 (UTC)
Although it seems you are concurring my perception, still would like to confirm for clarity further. In case of these Indian Copyright act 1957, subesequent amendment's text passed by parliament does not include base law/previous edition rather it is assumed. Uptill now some professionals did this job of creating a new edition and market the same. It is first time wikipedians are creating editions on their own on en-wikisource, and that you concur with me that it is possible. From the billinghurst' openion that we can not officially claim these editions to be dynamic, but we can certainly create editions.
And as you say we need to name these editions some thing like below. and link them in [Portal:Copyright law/Copyright law of India]]
1. Indian Copyright Act 1957 (1st edition) (transcription project)
2. Indian Copyright (1st Amendment) Act 1983 (transcription project)
2.1 Indian Copyright Act 1957 (1983 edition) (i.e. 2nd edition →page constructed by wikisource editors)
3. Indian Copyright (2nd Amendment) Act 1984 (transcription project)
3.1 Indian Copyright Act 1957 (1984 edition) (i.e. 3rd edition →page constructed by wikisource editors)
4. Indian Copyright (3rd Amendment) Act 1992
4.1 Indian Copyright Act 1957 (1992 edition) (i.e. 4th edition →page constructed by wikisource editors)
5. Indian Copyright (4th Amendment) Act 1994 (transcription project)
5.1 Indian Copyright Act 1957 (1994 edition) (i.e. 5th edition →page constructed by wikisource editors)
6. Indian Copyright (5th Amendment) Act 1999
6.1 Indian Copyright Act 1957 (1999 edition) (i.e. 6th edition →page constructed by wikisource editors)
7. Indian Copyright (6th Amendment) Act 2012 (transcription project)
7.1 Indian Copyright Act 1957 (2012 edition) (i.e. 7th edition →page constructed by wikisource editors)

Please do correct if I am missing any thing in my perception.
Mahitgar (talk) 09:13, 10 March 2017 (UTC)

@Hrishikes: I doubt your uploading of . this file uploading may not get covered under fair dealing, since file contains annotations without giving name of the author so it is separately copyrighted for sixty years there upon -without fairdealing protection in this case as per my personal openion- if I am not wrong.
Mahitgar (talk) 05:15, 10 March 2017 (UTC)
@Mahitgar: These annotations are of informatory nature, i.e., footnote references about which later act inserted which provision (The provisions themselves, being taken from parliamentary acts, are exempt under section 52). Are such annotations sufficient for fresh copyright? I don't have enough knowledge about such matters. However, if not permissible, then the file should be deleted, of course. Hrishikes (talk) 07:44, 10 March 2017 (UTC)
@Hrishikes: While it will take much longer time to cite particular court decesions, but to my knowldge usually Indian courts believe that adding such information needs special skill and effort so who so ever does such job or their employer as the case may be gets the copyright.
To my knowledge only the bare act as created by legislature or a bare judgement as written by the court is copyright free (i.e. fairdealing); whenever some one else puts any additional effort on that, that becomes copyrighted again.
This issue needs to studied with latest judgements and all; but over all my impression and advice is to avoid (emphasis added) using such documents on wiki projects.
Thanks and warm regards
Mahitgar (talk) 08:18, 10 March 2017 (UTC)
@Hrishikes: after limited google search I came across following reference material ref 1, ref 2 and ref 3. Frankly for want of time I could not read them again before citing here. But yourself or some one may go through such judgements to take the best decesion in this respect.
Mahitgar (talk) 08:33, 10 March 2017 (UTC)

@Mahitgar: I am saying a published edition — however published, whenever published. Each different published edition can be hosted here. We (Wikisourcians) do not munge or create works, that is out of scope, we just reproduce. Also don't get hung up in what went through parliament as they are Bills, not Acts. Think what is published as a result of a Bill in Parliament (noting that a Bill in Parliament can alter numbers of pieces of legislation at once). You will probably find a fully published edition per Bill. For example if you look at you will see lots of mentions of versions, go to an Act, and the twisty at the bottom has all the published versions. — billinghurst sDrewth 11:24, 10 March 2017 (UTC)

@Billinghurst: Thanks, atleast it is clear that, we would not be able to construct editions on english wikisource atleast. So project of constructing edition may be needed to shift to some other project (In any case Indic wikipedians and Indians would need that), or we will need to give space on some marathi language wiki. I will ask wikiversity community if they can support in first step. Please bear with me untill I trasfer the project somewhere else.
I know diff bttw bill & act, still thanks for the info.
Mahitgar (talk) 13:20, 10 March 2017 (UTC)
@Hrishikes, @Mahitgar, @Billinghurst: I think every published document of the Copyright Act, including the amendments, either separately or together, should be present in Wikisource as long as it is free of copyright. What I'm not sure about is whether Indian Copyright Law, as it currently is, should exist since it does not seem to be a single published document. Ciridae (talk) 13:39, 10 March 2017 (UTC)
@Mahitgar: If a single document is needed that agglomerates the various published pieces of Indian copyright legislation, I would suggest that Wikibooks would be a good place for it. —Beleg Tâl (talk) 13:43, 10 March 2017 (UTC)
Thanks I will ask at their discussion page if they allow.
Mahitgar (talk) 13:49, 10 March 2017 (UTC)
@Mahitgar: The document Indian Copyright Law may be shifted to Wikibooks if they would allow, then amended as needed. As for copyright office file, you may propose deletion if you think that is proper. You seem to be more knowledgeable, so I leave it at your discretion. Hrishikes (talk) 14:21, 10 March 2017 (UTC)

Index:The pilgrims progress as originally published by John Bunyan ; being a facsimile of the first edition (1878).djvu[edit]

I appreciate that the aim isn't to mirror exactly what's printed, but there having been no decision on this, I've hard-coded the long-s, which may be against the style manual.

However, once a suitable font which can do the change automatically can be put on English Wikisource I'm more than happy for someone with AWB to run a search and replace on this turing the long-s back into conventional ones.

One possible typeface for displaying older works like this is Junicode ( which has an Open Font License), but I was having considerably difficulty in getting it to behave exactly like the rules apparently used in the scans. Namely ct/st ligatures long-s mid word but not end-word and so on.

There also appears to be variable levels of support for the various glyphs needed in different versions of the font. (and the rounded top lower case k variant used in italic form.)

I've tried, but feel this needs an expert looking into it.

There's no problem with the scans though. ShakespeareFan00 (talk) 17:49, 11 March 2017 (UTC)

@ShakespeareFan00: Having run into long (loooong, sorry) discussions of this issue: the long s is not a violation of the MoS. It's a special case, and for some people it is tolerated more than allowed, but long s is specifically permitted. Other historical ligatures, such as the ct-ligature, are being forcibly removed as mere typographic puffery (note that I've been unable to find policy support or previous consensus to support this, but that's the observable practice in any case).
That being said, I think the basic problem here is really the atrocious support for historical ligatures (and related features of relevance to us) in current web browsers. The CSS and OpenType standards have support for pretty much everything we'd need (that I've checked), but web browsers simply have not implemented those features. If they did, we would be able to enable correct use of ct-, ffi-, and sh-ligatures, &c., in CSS even absent use of explicit such templates in the page text. I still like to mark as many of these as I am able to pick up when proofreading, in case it turns out we will need to mark them for the styling to work in practice, but overall my current thinking is that this is an issue that will be dealt with in CSS, proper fonts, and web browsers rather than templates.
In particular, I don't think using a special font and forcing an alternate glyph will help at all until browser support is in place: the font can't do this properly without cooperation from the font renderer (the web browser). --Xover (talk) 07:46, 12 March 2017 (UTC)
Some font's allow for historical ligatures to be selected by font-features: . I've started a phabrictor ticket asking for the support in mediawiki/extensions that would allow for such font's to be provided for Wikisource use.ShakespeareFan00 (talk) 10:04, 12 March 2017 (UTC)
What we're talking about is (primarily) the Open Type font feature option hlig, which is supported in the CSS standard by using font-variant-ligatures: historical-ligatures. There are plenty of fonts that support this Open Type feature; but browsers do not yet support enabling those font features, and operating system font engines do not support displaying them. Thus, having the font available is a necessary precondition, but it is not in itself sufficient. --Xover (talk) 10:20, 12 March 2017 (UTC)
Owing to some views expressed elsewhere I'll consider converting the hard-coded long-s back to standard ones, at least until there's "appropriate" support for older texts. At least the text will render on anything under that.ShakespeareFan00 (talk) 14:03, 12 March 2017 (UTC)
I would suggest not to. Last month's featured text, The Clandestine Marriage, uses hard-coded long s throughout. BethNaught (talk) 14:09, 12 March 2017 (UTC)
Yes, which will break on some devices I've been told (not on wiki though).ShakespeareFan00 (talk) 14:16, 12 March 2017 (UTC)
Where does it break? First time I've heard of this. It should be ok on any device I think. Jpez (talk) 16:27, 12 March 2017 (UTC)
{{ls}} and hardcoding long-s should eventually be un-necessary as it could be handled by a font-features choice at a much higher level. I'd rather break stuff ONCE then several times, as I explained in the discussion that was had a month ago. ShakespeareFan00 (talk) 14:32, 12 March 2017 (UTC)
Long-s is one archaic character that is widely supported by browsers. It is the archaic ligatures (joining of letter pairs such as ct or fl) that are not generally supported in browsers. There should be no technical problems with long-s. --EncycloPetey (talk) 16:51, 12 March 2017 (UTC)
Another issues is that searching for s doesn't also recognise ſ that's another reason why I am unhappy about hard-coding it. The following site : uses a font called Junicode and a font-feature "hist" to do long s forms, but due to apparent limitations in mediawiki, it was as I said not possible to have that font installed locally, and in-line it so that it behaved like the text on the scans in all instances (medial long s, final short s) in both italic and non-italic instances. If someone is willing to write yet another 'kludge' template rather than fixing the underlying lack of support in mediawiki, they are welcome, but it would nice for once to fix the root problem rather than continually writing yet more "un-necessary" formatting templates. (Sigh). ShakespeareFan00 (talk) 17:16, 12 March 2017 (UTC)

long s searches fine on google which is the most used search engine and I also just tried it on our own search engine and it worked fine. Compatability on devices and search engines isn't an issue I think. The only problem I could see with the long s is end users difficulty in reading texts that use it. Jpez (talk) 17:28, 12 March 2017 (UTC)
Can you find words inside the work concerned then? Just by searching using the modern presentation? If so there's less of an immediate concern.ShakespeareFan00 (talk) 17:46, 12 March 2017 (UTC)
Yes, text searches using modern "s" in the word will return results using long-s. Google and have supported this for years now, so long-s is no longer a technical issue for users as it was a decade ago. --EncycloPetey (talk) 17:54, 12 March 2017 (UTC)
So technically, {{ls}} could now be mass subst? and the ſ character added to CharInsert (or the other relevant toolbars) There was some objection to that the last time it was suggested.
It's still not possible to type long-s directly from a standard keyboard when transcribing though, meaning it's take longer if hard-coding it directly.
{{ls}} has to be typed precisely, The number of times I've played hunt the bracket, when previewing due to unclosed s invocations is quite high. Only needing to type ONE s form that can't mismatch brackets etc is less error prone.
{{ls}} isn't a very complex template so it's easily processed, but for a long work using it, there will eventually be the issue of transclusion limits. I'm not sure if anything has yet hit it but.
Thusly, I still think it should be possible to just not have to worry about long-s and let a font/mediawiki backend handle it. However any prospect of that at the current time seems to be vapourware like many other thing that would make Wikisource a better platform.( Like sidenotes that flow better.) (sigh) ShakespeareFan00 (talk) 18:24, 12 March 2017 (UTC)

Search failure[edit]

Although Poems of Nature (1895) was listed as a "New text" in January 2017, and appears first on the list at Wikisource:Works/2017, a search in the WS namespace does not turn up this link. Has this problem been noted before? --EncycloPetey (talk) 18:39, 12 March 2017 (UTC)

I'm guessing this is a caching or job queue issue. It's now showing after I gave it the relevant pages a barrage of purges and null edits. BethNaught (talk) 20:38, 12 March 2017 (UTC)
I wonder how many of our pages are failing to show up in searches for this reason. --EncycloPetey (talk) 17:37, 16 March 2017 (UTC)

Tech News: 2017-11[edit]

15:25, 13 March 2017 (UTC)

Action items[edit]

  • The above components about CSS are very pertinent to us. We should be looking to get our heads around what is happening, especially as 1) much of what we apply inline is styling, rather than structural, 2) we style tables! I need to do some more reading and thinking. Others more expert please feel welcome to throw in your opinions. To me it will over us the change to overhaul what we do.
    Good news, with the planned change we can start to utilise nth-child type css, and other CSS3, formatting at a template level, rather than just globally (per common.css). What that will mean is that where we can finally style a column of a work rather than have to format every cell in the column (yippee). We will have some work to do to set up something like template:table style and its subsidiary. We will also want to look at what we consider good template styles, and what we consider problematic. [We probably should review what bloat we have created and should put centrally anyway,eg. making some of our static formatting templates just be classes and move the formatting centrally. And yes, I should create a separate section :-/ ] — billinghurst sDrewth 02:52, 15 March 2017 (UTC)
  • With regard to references. I don't believe that we would have many, if any, uses of references presented in columns. If we do, we should be looking to identify these and determine where we want to take these. — billinghurst sDrewth 23:46, 13 March 2017 (UTC)
We don't use references in columns, but we do use {{reflist}} and {{smallrefs}} an awful lot. Will this change affect those templates? --Mukkakukaku (talk) 04:13, 14 March 2017 (UTC)
both templates have coding for columns and that will need to be updated, (or maybe we just remove it?) — billinghurst sDrewth 11:04, 14 March 2017 (UTC)
Added the phabricator tracking. It seems that there will be an ON group of wikis and an OFF group, though the process for which is not stated. I have asked the question. We will need to work that option into our templates. It will probably mean that we will need to move the style components of templates into Mediawiki:common.css though I will leave that to those who play that space better than I. — billinghurst sDrewth 11:17, 14 March 2017 (UTC)
Opt-in. So we can update at our leisure. — billinghurst sDrewth 14:16, 14 March 2017 (UTC)
There's definitely no rush.
For now, you can turn this feature on for any individual page (requires >10 refs to see a change). If you ever want that to change (in which case, you could turn it off on any individual page), then please file a task in Phabricator, or talk to me. My goal is for the default setting at your wiki to be the best setting for your wiki – not the best setting for some hypothetical average wiki. Whatamidoing (WMF) (talk) 21:38, 14 March 2017 (UTC)

Decoupling CSS from dynamic templates?[edit]

How are templates that style dynamically, like {{Numbered div}} intended to be done correctly, if CSS is being "decoupled"? ShakespeareFan00 (talk) 15:11, 15 March 2017 (UTC)

The above said, some aspects of what numbered div does could ideally be implemented with CSS counters in any event.ShakespeareFan00 (talk) 15:44, 15 March 2017 (UTC)
That is the discussion that we have to have. Basically the change is going to be equivalent to html where we can have <style> sections or separate style sheets. It is a big change and we are going to have to work out what we want to do. We may choose to not do anything at this point of time as most of our templates are pretty set. You especially need to settle! Running amok changing templates and adding further complexity and tangentially to what the community decides would not be ideal. — billinghurst sDrewth 13:47, 16 March 2017 (UTC)
If the existing inline styles will still work, then there's no need to change anything (which was the impression I got from the TemplateStyles documentation). However, if there is a general consensues that "decoupling" style and content, is a good thing, then it should be seen as a chance to massively overhaul many templates.
For example, currently we have {{p}},{{tf}},{{ts}} that essentially all do the same thing, albeit for different HTML elements. Would it not be a more sensible approach to have one central style/parse to handle the short codes, rather than 2 or more, and to have the short codes/expansion stored separately from the parse portion of the template? That way to add new codes, it wouldn't need to necessary to modify the parse template (which could be protected.) and instead there could be a page which was used as a lookup table for the style codes.
I am also of the view that are some templates (mine included) DO need to be massively overhauled. ShakespeareFan00 (talk) 14:16, 16 March 2017 (UTC)

Upcoming changes[edit]

There are a lot of small changes happening in the next couple of weeks, and I wanted to give you all a quick heads-up about them. Please share this information with other people/languages/projects that will be interested:

  • There's a change to how columns in reference lists are handled, at the request of the German Wikipedia. This change will improve accessibility by automatically formatting long lists of <ref>s into columns, based on each reader's screen width. (It has no effect when the references list contains fewer than 10 refs.)
    • What you need to do: Nothing visible is happening now. If your project uses the normal <references /> tag (or doesn't really use refs at all), then file a Phabricator task or just tell me, and I'll get your wiki on the list for the next config change. If your project uses a "reflist" template to create columns, then please consider deprecating it, or update the template to work with the new feature.
    • I have a few worries about this for the Wikisources. I don't know how the different Wikisources are formatting columns of footnotes in sources. I also don't whether you'll decide, in the case of a narrow printed source being reproduced on a wide computer screen, that it's better to to maintain the narrow columns of the original (which could mean many narrow columns vs two narrow columns in the original) or the number of columns in the original (which could mean two wide columns rather than many narrow ones). So I'd particularly like to hear from each of the Wikisources about whether this should be enabled on each one. If this feature is really going to break things, then we probably shouldn't enable it here.
  • The label on the "Save changes" button will change on most projects tomorrow (Wednesday) to say "Publish page". This has been discussed for years, is supported by user research, and is meant to be clearer for new contributors. (Most of us who have been editing for years don't even look at the button any more, and we all already know that all of our changes can be seen by anyone on the internet, so this doesn't really affect us.)
    • If you have questions or encounter problems (e.g., a bad translation, problems fixing the documentation, etc.), then please tell me as soon as possible.
    • When we split "Save page" into "Save page" and "Save changes" last August, a couple of communities wondered whether a local label would be possible. (For example, someone at the English Wikipedia asked if different namespaces could have different labels [answer: not technically possible], and the Chinese Wikipedia has some extra language on their "Save page" button; I think it's about the importance of previewing.) Whether the Legal team can agree to a change may depend upon the language/country involved, so please ask me first if you have any questions.
  • As part of the ongoing, years-long user-interface standardization project, the color and shape of the "Save changes" (or now "Publish page"), "Show preview" and "Show changes" buttons on some desktop wikitext editors will change. The buttons will be bigger and easier to find, and the "Save" button will be bright blue. (phab:T111088) Unfortunately, it is not technically possible to completely override this change and restore the appearance of the old buttons for either your account or an entire site.
  • Do you all remember last April, when nobody could edit for about 30 minutes twice, because of some work that Technical Ops was doing on the servers? The same kind of planned maintenance is happening again. It's currently scheduled for Wednesday, April 19th and Wednesday, May 3rd. The time of day is unknown, but it will probably afternoon in Europe and morning in North America. This will be announced repeatedly, but please mark your calendars now.

That's everything on my mind at the moment, but I may have forgotten something. If you have questions (about this or any other WMF work), then please {{ping}} me, and I'll see what I can find out for you. Thanks, Whatamidoing (WMF) (talk) 19:01, 13 March 2017 (UTC)


U.S. Government Printing Office Style Manual 2008 is nearly completely proofread. I have found an earlier copy to fix the last Problematic pages. The proofreading has been done by ShakespeareFan00 and I over the last year, and is frankly a bit erratic. We’ve both been trying different approaches as we’ve worked through it. I think it now really needs a thorough editorial eye passed over it as it is validated.

My intention is to use this text and Cowie's Printer's Pocket-Book and Manual as proofreading reference books/exemplars/training material so I want them to be reflective of WS standards, especially demonstrating that there are different approaches to "solving" proofreading "dilemmas". I would really appreciate erudite discussion referencing these books. I think we could use Page discussion to detail the finer points and then link them to Help pages.

Any takers for a thorough review?

Cheers, Zoeannl (talk) 01:28, 16 March 2017 (UTC)

@Zoeannl: can you describe the different approaches in style? Maybe we can get a bot to go through and either check or adjust some of the differences. — billinghurst sDrewth 13:40, 16 March 2017 (UTC)
@Billinghurst: You have clearly not even looked at this transcription before sounding off. It is a demonstration piece of the limits of typography and as such a robotic solution can only be detrimental at best. 23:12, 16 March 2017 (UTC)
Absolutely I didn't check it on the limited moments that I had, which is why I asked for an expanding on the comments so that people can better understand prior to venturing to the work. Start with open questions to better have the issues defined, so we don't all have to work it out. Mention some of the possible solutions, so the thinking is shared with a common approach. Running a bot through is always possible at this stage if there are style differences. — billinghurst sDrewth 02:23, 17 March 2017 (UTC)
Specifically, I have issues with font size mark-up both in terms of consistency between proofreaders and as faithfully representing the text which specifies things like "7 point" in places (as a printing standard).
Generally … SF came up with a template specifically for the project which is pretty cool and worth discussion. The book covers a lot of stuff like non-English fonts, symbols, tables, poetry etc so as I am proposing would provide a great exemplar for what we should/could/would do for proofreading and formatting.
Cheers, Zoeannl (talk) 07:32, 18 March 2017 (UTC)

Wiki 4 Coop[edit]

Hello everyone,

I come to you to invite to re-read the submission of a new partnership project between the Wikimedia movement and the Belgian NGOs. The project is titled Wiki 4 Coop and I invite you to discover its submission page on Meta-Wiki. Do not hesitate to endorse the project if you like it and even correct my English if you have a little time. A beautiful end of day for all of you, Lionel Scheepmans (talk) 12:06, 17 March 2017 (UTC)

We invite you to join the movement strategy conversation (now through April 15)[edit]

05:09, 18 March 2017 (UTC)

I have started a discussion relevant to Wikisource to which I encourage people to add comments, especially regarding the value and impact behind integration of Wikisource with Wikidata, Wikipedia, and Libraries. --EncycloPetey (talk) 16:52, 18 March 2017 (UTC)
@EncycloPetey: Thanks for that.
I've also created a local page for this at Wikisource:Wikimedia Strategy 2017, if anyone would prefer to participate here instead of on Metawiki. Please let your fellow editors know, in the optimum locations for you. Looking forward to your input! :) Quiddity (WMF) (talk) 01:04, 22 March 2017 (UTC)

commons poty banner[edit]

i see we are getting a commons banner here. [43] anybody comment or consent to this? Slowking4SvG's revenge 14:07, 18 March 2017 (UTC)

We are? I never see banners here. Gadgets win! — billinghurst sDrewth 14:58, 18 March 2017 (UTC)
Yeah, that just popped up for me on the Community Portal. Can't say I like the idea that people visiting a page like that are greeted by a huge banner that directs them to another project. --EncycloPetey (talk) 16:49, 18 March 2017 (UTC)
there is a global turn-off "following code to your common.css page: #siteNotice {display: none;} " [44] cheers. Slowking4SvG's revenge 00:44, 19 March 2017 (UTC)

Changes in Preferences Editing settings & other issues[edit]

The textarea window row size setting from Preferences/Editing settings was removed with one of the recent wmf software updates.

Also noticed that {{rule}} and table borders etc., are not rendered and this causes some confusion when previewing. Had anyone else noticed these issues? — Ineuw talk 20:42, 18 March 2017 (UTC)

The rendering of {{rule}} is platform specific. When I view pages from home, rules and table borders render just fine. When I view pages at work, rules and table borders render only sometimes, but often not. This is true whether I preview an edit or simply view a page. I use Firefox at both locations, but have issues at work because it runs Windows. --EncycloPetey (talk) 21:28, 18 March 2017 (UTC)
Thanks, I will check this issue in Linux. However, the lines do show up eventually on the same platform (Windows 7 & Firefox) and this was never an issue before. — Ineuw talk 04:28, 19 March 2017 (UTC)

On Pearl Buck[edit]

How come I cannot find Pearl Buck as an author? Billingsmell 21:56, 18 March 2017 (UTC)

Primarily because nobody has created an author page for her yet. Based on her Wikipedia page, all her writings were in the 1930s or later, which means they are all (probably) copyright. If there are no public domain works by her, there is no point in creating an author page for her anyway, and any author page would probably be deleted. —Beleg Tâl (talk) 22:07, 18 March 2017 (UTC)
But she is very famous and a page has to be devoted to her.Billingsmell 22:14, 18 March 2017 (UTC)
Famous has nothing to do with it. Most Wikisource projects (English or otherwise) only create Author pages if there are works written by that person that are in the public domain. If a person has not written anything, or all their works are under copyright, we do not create an Author page for them. the purpose in having an Author page is to provide a list of what we have on Wikisource, not simply for the sake of having a page. --EncycloPetey (talk) 22:30, 18 March 2017 (UTC)
That is it. I also searched for "Karen Blixen" but I could not see her name here. I had book written by her and I wish to edit her page if it exists.Billingsmell 22:35, 18 March 2017 (UTC)
I can only find three of her works published before 1923, and those were published in Danish. Have you tried Danish Wikisource? --EncycloPetey (talk) 23:15, 18 March 2017 (UTC)
i suspect we have some orphans that may not have been renewed, but it is too hard. you could build the author and bibliography, (or grab from wikidata) and then start with the hathi trust search of the pdfs. [45]; and copyright search [46] Slowking4SvG's revenge 00:51, 19 March 2017 (UTC)

New Page that I created[edit]

Please start contributing to the page I just created: Thanks. Billingsmell 22:55, 18 March 2017 (UTC)

That's not the sort of thing Wikisource does. We don't create new works or articles, but re-publish works that have already been published, and create indexes/categories/catalogs so that people can find those works on our site. --EncycloPetey (talk) 00:24, 20 March 2017 (UTC)

Re-reading previously proof-read..[edit]

I've decided to take another look at some stuff I proofread earlier this year, and in previous years. I am not finding many big errors, but I am finding a lot of tiny single character or format errors, on pages I was sure I'd checked at least twice previously. So if I am somewhat quieter for a while or I seem to be making a LOT of minor edits don't be surprised, The aim is to try and push the page quality as far as I reasonably can before it gets validated (And that reminds me, I should probably check some of those as well). ShakespeareFan00 (talk) 23:01, 18 March 2017 (UTC)

Your proofreading is passable. Even on Project Gutenberg things get missed after 6 rounds of proofreaders have been through. Which is why WS has an advantage as we can continue to improve once "published". PG’s process for fixing mistakes is arduous. Because of this Distributed Proofreaders, where the books are processed, has a very vigorous training program that I would really recommend for everyone here at WS. It doesn’t take long to get through their first stage (P1) and they have projects and feedback specifically for beginners. It is 95% relevant to what we do here, and even the differences help train the eye. They have tutorials and quizzes too. I notice they have 300+ active users in the last 24 hours, about the same as WS in the last month … They do know what they are doing re proofreading. I think it’s a real shame that their end product is IMHO so inferior to WS. Cheers, Zoeannl (talk) 01:13, 19 March 2017 (UTC)
@ShakespeareFan00: I recommend you to install typoscan.js by AuFCL. It highlights a of typos. — Ineuw talk 04:35, 19 March 2017 (UTC)
@ShakespeareFan00: have a look at Page:The Holy Bible (YLT).djvu/55, and read through it a bit. This is how you've been proofreading this whole work. It's a page I randomly picked which I remember working with you for a bit, and I remember your proofreading there was as if you just speedily went through it. Also check some of the pages I've validated and compare history from your proofreading. I thought of bringing it up to you many times, but I don't like putting down someone who after all is just trying to help, but in the end is it help? or would it have been better if no help was provided at all, since in this circumstance my validating was as if I was proofreading and in the end the true validation is lost, since I'm sure I've left many mistakes behind myself. So I must say your proofreading is unacceptable in this work. As I said I wouldn't have mentioned this at all (probably should of though) but it seems you're looking for critique and and your work here Index:The Holy Bible (YLT).djvu speaks for itself. Sorry. Jpez (talk) 05:11, 19 March 2017 (UTC)
@Jpez: Added to my re-read list. If you find others LMK.ShakespeareFan00 (talk) 09:36, 19 March 2017 (UTC)
Cassell 3? Although there you're not the only one missing lots of stuff. I agree with Jpez about how difficult it can be to raise issues needing to be raised. BethNaught (talk) 11:05, 19 March 2017 (UTC)
Thanks, Any objections to a complete re-read of all volumes of this completed so far?ShakespeareFan00 (talk) 11:26, 19 March 2017 (UTC)
Why would anyone object to anyone rechecking their own work? BethNaught (talk) 11:42, 19 March 2017 (UTC)
@Ineuw: , I may already have typoscan.js installed, I am not going to rely on automated tools to spot "errors" though. ShakespeareFan00 (talk) 09:36, 19 March 2017 (UTC)
I'm glad you're taking steps to recheck your work, but I would recommend you follow Zoeannl's advice re PG training. I haven't done it but it looks helpful; your rechecks are still missing quite a bit, see my randomly sampled page [47] vs. [48]. BethNaught (talk) 11:05, 19 March 2017 (UTC)
I can't promise 100% ever. This is EVEN with the typo script, the spell-checker in Firefox, and page preview. Was there a plan to add further text-check' tools, to look for mismatched brackets, quotes and s/e template mismatches? ( Kind of like a Wikisource specfic set of checkwiki hurestics.)ShakespeareFan00 (talk) 11:26, 19 March 2017 (UTC)
I never asked for 100%, and I would never claim that I never make errors. Nevertheless you clearly have a blind spot for punctuation, which spell-checkers won't help with. Try using the MS Word (or equivalent) spell checker as that also checks grammar. But really when so many of your works have problems, you should consider that there may be a fundamental problem with your proofreading, which may need to be fixed with e.g. the PG training. BethNaught (talk) 11:42, 19 March 2017 (UTC)
Quite. I will also note at one point, I was marking pages I'd effectively only cleaned up from OCR as "Not-proofread" until someone queried why I was creating a backlog, and why I was apparently asking for 2 proofreads as well as the validation step. If scan errors and typos are being missied in sufficient number (on the initial entry and) re-checking as well, it clearly needs at least 3 (independent) people. I'm thusly also not happy that it's possible to mark as proofread directly on new page-creation, as barring someone that's done a LOT of proof-reading previously, it's unlikely all the errors will be removed on a first-pass. ShakespeareFan00 (talk) 12:13, 19 March 2017 (UTC)
  1. If anyone finds anything they want "re-read" drop a note on my talk page. I won't be starting 'new-projects' (other than stuff I already have watchlisted) until June.
  2. I will be marking 'new-pages' as 'Not-Proofread' (given my concerns)
  3. I obviously have no objections to other contributors correcting scan errors that have been overlooked/missed (Letting me know so the entire work can be "re-read" would be appreciated.)
  4. The spell-check dictionary in most software doesn't like archaic spellings or long-s. Would there be any interest in people slightly more able than me developing an 'archaic' list for older word forms? ( and yes I'm well aware that until a certain date English spelling was NOT uniform.)

ShakespeareFan00 (talk) 12:33, 19 March 2017 (UTC)

Is there any kind of agreement in the community as to an acceptable error rate, or to what level the formatting should to be accurate, in order to mark a page as proofread? I always understood it to be "as perfect as possible", but accepting that an error every couple of pages, more if pages are very long or complicatedly laid out, will happen. I often feel when checking or validating others' work (not just SF00, and not naming other names) that others have different standards. BethNaught (talk) 11:42, 19 March 2017 (UTC)

Let's just say that finding 2-3 typos per PAGE on a recheck is probably too high. The speed at which proofreading/validation occurs has also been a concern raised. (There was at one time a suggestion that to validate needed two people to independently flag an unchanged page (i.e no changes) as such, but the outcome of the disscussion was that it wasn't feasible in the software.)ShakespeareFan00 (talk) 12:13, 19 March 2017 (UTC)
Might I suggest a method for processing a page, which would include proofing, validating, revalidating as many times as you like? There was someone many years ago at Distributed Proofreaders who was having some difficulty in catching OCR misinterpretations, publisher typos and punctuation mishaps despite the use of Wordcheck. It was suggested to the user that the method of using Ctrl+right arrow key might help. I too was having the same issue. Originally I was just moving my mouse over the text but when I checked my diffs I found I was missing too much and it was obvious stuff. Then I started using the Ctrl+right arrow key method and things started to improve. Although that may sound time consuming, it really isn't once you get used to it. I like to "read" as I proof (or maybe in this case, "proof" as I read) as I am doing both. Somewhere in my past, I recall a statement that "the eye follows movement". Do you ever find yourself watching the movement in the background of a TV interview instead of the non-moving person in the front? Not to say that this is the best method (I'm sure I still miss the occasional thing) but something you could try. Humbug26 (talk) 18:00, 19 March 2017 (UTC)
I've found myself using that technique, especially with some old texts that needed special formatting inserting, I still can't do non-latin text (sigh) .ShakespeareFan00 (talk) 18:43, 19 March 2017 (UTC)
  • BethNaught, I am glad to see your mention of Cassell’s and to that I would state that if you see a mistake anywhere please fix it. That is "as perfect as possible" - helping one another create a better Wikisource and not only on one’s personal projects. The situation you are seeing on Cassell’s v.3 came about as a speed reader (guess who) went through that volume and because of the swift marking of "proofread" I came behind and missed many mistakes while I did get as many as possible while trying to keep up (my mistake) with the speed reader who often makes many mistakes although I have seen that same person edit with perfection. I don’t know why he speed reads but he has been notified by several people and sometimes he has stated he was going to take a "break" but that break doesn’t last very long. My idea includes to going over all of the 9 Cassell volumes once fully done and especially vol.3 My basic job, as agreed upon at the outset among 4 of us, was to insert all images in proofread text plus look over the text. Your comment, "Is there any kind of agreement in the community as to an acceptable error rate, or to what level the formatting should to be accurate, in order to mark a page as proofread? - is an excellent point in my opinion. Speed reading causes more harm than good in my experiences. I have followed and have seen many pages marked "proofread" yet filled with mistakes. Speed dominates that person but he is not a bad person. Also, some do not format pages. When looking into the edit mode one easily sees those. Best, —Maury (talk) 19:27, 19 March 2017 (UTC)

@ShakespeareFan00: Where did you get the idea that it's automated? All it does is highlights possible errors, then it's up to the user to check the context. For example. ii, li, Av and St, are possible errors depending on their context. The Regex for the errors were ones suggested by other users who found them in the scans. — Ineuw talk 21:47, 19 March 2017 (UTC)

Is there a page to suggest new patterns to look for? ShakespeareFan00 (talk) 21:59, 19 March 2017 (UTC)
In old-school printing you got this Page:U.S. Government Printing Office Style Manual 2008.djvu/21 when checking proof's. Is there a way to do something like that in UI/digital terms for Wikisource pages? (i.e noting errors with a carret in the text, and the actual errors down the side.). I am also thinking in terms of VE stuff... ShakespeareFan00 (talk) 22:11, 19 March 2017 (UTC)
On the topic of punctuation: the Wikisource:WikisourceMono font can help with making it easier to see differences between commas, dashes, colons etc. Sam Wilson 23:15, 19 March 2017 (UTC)

pagelist for two page scans[edit]

I have a book scanned as two page spreads. How do I configure the pagelist tag to number it correctly in such a situation? Is there any workaround? --Prateek Pattanaik (talk) 07:22, 19 March 2017 (UTC)

You'd probably have to do it manually: 1=1 2=3 3=5 4=7 etc. —Beleg Tâl (talk) 12:11, 19 March 2017 (UTC)
That is how I have managed it in the past. — billinghurst sDrewth 00:16, 20 March 2017 (UTC)

WIkisource Tutorial ?[edit]

In a previous thread it was mentioned that there was a tutorial/quiz on the Distributed Proofreaders website. Given that it was possible to implement the "Wikipedia Experience" tutorial on English Wikipedia, would it be possible to implement a "Wikisource Tutorial" based on the DP example? (noting that some of the formatting is done slightly differently on English Wikisource).

I couldn't come up with a name other than tutorial, unless someone knows what an apprentice scribe or typesetter was called way-back. ShakespeareFan00 (talk) 16:46, 19 March 2017 (UTC)

/* By Request */[edit]

ShakespeareFan00 has told me on my talk page that there was some sort of editing conflict. So, I repeat what I previously wrote without the highlight and this is copy/pasted from that highlight.

BethNaught, I am glad to see your mention of Cassell’s and to that I would state that if you see a mistake anywhere please fix it. That is "as perfect as possible" - helping one another create a better Wikisource and not only on one’s personal projects. The situation you are seeing on Cassell’s v.3 came about as a speed reader (guess who) went through that volume and because of the swift marking of "proofread" I came behind and missed many mistakes while I did get as many as possible while trying to keep up (my mistake) with the speed reader who often makes many mistakes although I have seen that same person edit with perfection. I don’t know why he speed reads but he has been notified by several people and sometimes he has stated he was going to take a "break" but that break doesn’t last very long. My idea includes to going over all of the 9 Cassell volumes once fully done and especially vol.3 My basic job, as agreed upon at the outset among 4 of us, was to insert all images in proofread text plus look over the text. Your comment, "Is there any kind of agreement in the community as to an acceptable error rate, or to what level the formatting should to be accurate, in order to mark a page as proofread? - is an excellent point in my opinion. Speed reading causes more harm than good in my experiences. I have followed and have seen many pages marked "proofread" yet filled with mistakes. Speed dominates that person but he is not a bad person. Also, some do not format pages. When looking into the edit mode one easily sees those. Best, —Maury (talk) 19:27, 19 March 2017 (UTC)

Further, BethNaught has shown me a page he corrected where five people did not catch all words in proofreadig for which I thanked him and thank him again. Best regards, —Maury (talk) 21:02, 19 March 2017 (UTC)

Collaboration products newsletter: 2017-03[edit]

17:02, 20 March 2017 (UTC)

Tech News: 2017-12[edit]

22:03, 20 March 2017 (UTC)

publish may work for wikisource communities, but i can imagine the community pushback on wikipedias. maybe an opt out? or change for VE and not wikitext? Slowking4SvG's revenge 22:24, 21 March 2017 (UTC)

Typo words.[edit]


Can I ask that if you find a word that looks like a scan/typing error to list it and the Page it appears in here User:ShakespeareFan00/Typo words, so I can use a regexp to find and fix them? Thanks. ShakespeareFan00 (talk) 12:39, 21 March 2017 (UTC)

It is all a bit tentative but may I suggest you liase with either da capo or da boss regarding outline of potential solution (or equivalent as I am no longer active)? Might be relevant. (ex-AuFCL) 03:11, 23 March 2017 (UTC)

Portal:War poetry cleanup[edit]

Before I have at it, I'm seeking permission to clean up the "Individual poems" section of Portal:War poetry > World War One poetry. To list all WW1 poems available at Wikisource would be "too much." Therefore, if a poem currently listed is contained within one of the Collections listed, I would remove it from the list. Otherwise, an incomplete listing such as we currently have seems pointless to me. Any suggestions would be appreciated. Just thought I'd tidy things up in light of the 100th anniversary of American involvement in the War. Thanks, Londonjackbooks (talk) 21:32, 22 March 2017 (UTC)

user:AdamBMorgan? thoughts? a subpage for loose would be a compromise. Slowking4SvG's revenge 02:42, 23 March 2017 (UTC)
I believe AdamBMorgan is gone for a time, unfortunately. They would have been my go-to person... I will go ahead with some adjustments, and will keep in mind the words of Florence Earle Coates, to "Take not away what thou canst not restore!" Input is still welcomed! Thanks, Londonjackbooks (talk) 00:04, 24 March 2017 (UTC)


This template states "The existence of this template has not been discussed, and the consequences have not been examined, usage is not recommended." Let's discuss and examine so that we can use, modify, or remove the template :)

The benefit I see to the current template usage (spaced dots) is simply that it spaces the dots nicely. In particular, it works well in cases where there are four dots, i.e. an ellipsis and an extra period; it then spaces them out nicely, like this. . . .

The downside is, of course, that an actual ellipsis may be preferred typography in all cases. In that case, I would support modifying {{...}} to simply place an ellipsis, and it could be used for ease of typing. —Beleg Tâl (talk) 14:00, 23 March 2017 (UTC)

I strongly and violently oppose the proposal to disfigure thousands of pages with artificially compressed ellipses. This is about more than typography and ease of editing, but also about context, rhythm, and communication. An ellipsis used simply to indicate omitted text can be compressed, certainly, but the spacing of dots in dialogue is often intended to communicate pauses of varying lengths. In this instance, the typography communicated through intervening spaces is used to indicate a longer or shorter duration of pause. Eliminating this feature from Wikisource mars the original text. The spacing of periods are also used in reconstruction of documents to indicate a lacuna in the surviving copy. The spacing and number of the dots indicates the size of the lacuna. A similar effect occurs in poetry, where the spacing and number of dots are used to visually align or space sections of text. So, claiming that the only benefit is that the template merely "spaces the dots nicely", is an empty argument that fails to account for all the various reasons that printers have used for the spacing or dots in text. --EncycloPetey (talk) 14:27, 23 March 2017 (UTC)
{{...}} doesn't currently support variable spacing and number of dots, so I think that's a little beyond the scope of the discussion, though we could of course modify the template to support some of that functionality. It's my understanding that the template is currently only used as a more aesthetic alternative where a regular ellipsis would still be appropriate. Do you have any examples to the contrary? or examples of situations where {{...}} would be appropriate, but &hellip; would not? —Beleg Tâl (talk) 15:11, 23 March 2017 (UTC)
And, of course, on researching into even my own usage of this template, I find I am completely wrong . . . . . my apologies. So: what would you say to the use of the template in cases where a regular ellipsis is appropriate? —Beleg Tâl (talk) 15:16, 23 March 2017 (UTC)
Per our Style Guide, we prefer regular ellipsis of omission as a character by default, but even the Style Guide allows that there are situations where another option is permitted. I have given examples of situations which I believe can warrant doing things differently. But when there is no need to use this template, then it should not be used. My editing style is that I prefer not to use a template at all unless either (a) a template is necessary to produce the desired result, (b) a template makes the coding much easier than without it, or (c) the template makes the document easier to adjust later should the need arise. Others may feel differently. --EncycloPetey (talk) 20:07, 23 March 2017 (UTC)

Index:The Bab Ballads.djvu[edit]

is currently the featured text. However I have found a large number of pages with errors: of the 88 I have cursorily checked so far, 32 have had at least one error, often more. That's 36%. If anyone else would help me clean up the rest I'd be grateful. (See related changes to see which ranges I have checked.) Thank you, BethNaught (talk) 15:56, 23 March 2017 (UTC)

Never mind. A hundred total edits and I've skimmed it all myself. BethNaught (talk) 20:25, 23 March 2017 (UTC)

The Subjection of Women by J. S. Mill[edit]

We currently have an unsourced, non-scan-backed copy of this work. However I have almost finished proofreading this scan. Given the current copy is unsourced, could I overwrite it, or should I create a versions page?

There was a similar situation re. Pollyanna, where overwriting happened. This case is different in that there is no source, but in Billinghurst's words, "Until we have a firm statement and guidance in the deletion policy, I will seek the community's opinion where I come across these examples." BethNaught (talk) 19:30, 26 March 2017 (UTC)

How certain are you that it is/isn't the same version? That's generally the deciding question. If there's no indication of what version they are, a direct comparison of text is necessary. —Beleg Tâl (talk) 21:17, 26 March 2017 (UTC)
Yeah, we are looking for edition differences, often it will be British vs. American, in the editing. Does Special:ComparePages help? Which edition have you transcribed? — billinghurst sDrewth 21:58, 26 March 2017 (UTC)
It's London, 1869, which makes it first edition or a reprint thereof AFAICT. The IA metadata claims the scan is the author's presentation copy, although I don't know how much I believe that. The side-by-side comparison is here: our current mainspace text, as opposed to the scan, appears to: a) have many scannos, b) correct a couple of typos in the scanned text, c) consistently change -ize spellings to -ise. Would that indicate an American edition for the period in question? I can't easily see any place where major revision has happened, although I might have missed something due to paragraphing errors. (Thanks for the tip about ComparePages, I didn't know about that.) BethNaught (talk) 22:28, 26 March 2017 (UTC)
Thanks for the comparison. Looking at the comparison my opinion is to kill the old work, whether it is a different version or not as it would seem to be a significantly inferior quality transcription, and without the ability to check the transcription against the source, I propose that the scanned-backed text take its place. @BethNaught: lovely work as always! — billinghurst sDrewth 00:13, 27 March 2017 (UTC)
OK then, if nobody objects I'll do the replacement probably tomorrow. Thanks for the input. BethNaught (talk) 17:56, 27 March 2017 (UTC)

Change 'plain sister' to follow edition linkages[edit]

Hi all, I'd like to suggest a new feature for the {{plain sister}} template: Module talk:Plain sister#Follow_edition_links Sam Wilson 00:07, 27 March 2017 (UTC)

@Samwilson: I think that we are going to need a higher-level explanation, rather than a technical explanation. At the minute plain sister has numbers of sister link components, through manual linking to the (parent) literary works at the sisters, and automated to the edition data at wikidata through the sister link at WD. What is the expected outcome that you would expect to see in the header at an edition page here? — billinghurst sDrewth 00:19, 27 March 2017 (UTC)

@Billinghurst: Sorry! Yes, good point. :) The problem I'm trying to solve is situations like the following and also similar situations where there are multiple editions of the same work spread over different Wikisources.

Take for example w:The Swiss Family Robinson:

In the current system, the two editions both require wikipedia = The Swiss Family Robinson to be added to their header template, because their Wikidata items do not link to Wikipedia (because only the 'work' item is allowed to do that). In fact, in this example, the second edition doesn't have that, and so its sister links don't currently list Wikipedia at all.

The fix is to use the fact that all editions have a 'edition or translation of' statement that links to the work item: we follow that link, and from there can get the Wikipedia sitelink. This results in e.g. {{plain sister/sandbox|wikidata=Q19100453}} resulting in:

(The wikidata paramter is included here because we're on the Scriptorium and not on the edition's Wikisource page; in actual usage it'd just be {{plain sister}}).

Sam Wilson 01:03, 27 March 2017 (UTC)

I'm not sure we can do that automagically. Yes, every edition will have an 'edition or translation of' statement, but not every edition will have a single value for that property. For instance, Swanwick's translation of Aeschylus' Agamemnon is a translation of Aeschylus' play, but there are four editions of Swanwick's translation. So Swanwick's translation will have a "work" item (without Wikipedia article), which will list the four edition data items, and Aeschylus' play Agamemnon will also have a "work" item with Swanwick's translations listed, and the individual editions of Swanwick will have both "work" items listed, since Wikidata does not distinguish between "edition of" and "translation of". Here's the catch: there is no article about the play Agamemnon on the English Wikipedia: it is included as a section within the larger article about the Oresteia trilogy.
If this case seems complicated, I can suggest ones that will be even worse once Wikidata catches up with its own data structure. --EncycloPetey (talk) 01:49, 27 March 2017 (UTC)
@EncycloPetey: Certainly, I'm sure there are many cases where things will be weird (I think this is called the Bonnie and Clyde problem?), but for those we can always override locally, as we're currently doing. I'm just talking about the situations in which a sitelink does exist on the work item, so we needn't repeat it here.

We could perhaps in the future look at doing more traversals, such as following 'part of' (P361) relationships (which is perhaps what would get us to Oresteia from Swanwick's translation?) But not doing that needn't stop us handling the simpler cases.

Sam Wilson 02:21, 27 March 2017 (UTC)

  • Pictogram voting comment.svg Comment I will think about this when my brain has some thinking and play time. Now to confuse matters this approach only works well for fiction works, or the rare mega non-fiction works like EB1911 that have articles, but generally not so well for other types of works. All because the relationship between WS and WP and our laissez faire approach.

    Our other, and larger, use case we face is for biographical/encyclopaedic entries. We (perhaps a little naughtily) label as biographical/encyclopaedic articles and not editions at Wikidata, and these need to link back to "main subject", eg. Byron, George Gordon to w:Lord Byron. (If we had a complete biographical work, would we expect it to link back to the article about the book, or the article about the person?) — billinghurst sDrewth 03:56, 27 March 2017 (UTC)

    • All of those can be reasonably easily handled, I think: we'd just define a set of properties that should be followed when looking for a sitelink (and one hasn't been found yet). We could even do it on the next step as well, and get the main subject (or 'part of' or other property) of a work if that work doesn't have a sitelink.

      I don't agree that this only works for fiction works though; it works for anything that has a 'edition or translation of' property. In fact, that's all it works for! :-) I'm trying to keep it simple; we can grow the idea later, if desired.

      One complexity even with this simple case is when there are multiple values for 'edition or translation of'—but we could just list them all. Sam Wilson 04:10, 27 March 2017 (UTC)

You missed the keyword "well" as in works well with. Meaning that the vast majority of our works that have enWP articles and have editions here are primarily fiction works, ie. fiction works tend to get notability in the numbers game rather than non-fiction, so non-fiction books are less likely to have wikipedia articles. Where we have a periodicial article, the periodicial may be listed, however that tends not to cascade down to the article level. — billinghurst sDrewth 05:08, 27 March 2017 (UTC)
@Samwilson: There is another type of situation, where Wikipedia may not have an article on the specific edition or work here, but it has an article on the specific subject. Other than biographies, this is also true about mythological stories (e.g. 1) and fairy tales (e.g. 2). If the story is famous, it will be a part of many collections, in slightly different languages, rendered by different authors. Wikipedia will have a general article on the story in such cases; these need to be linked locally, because linking through Wikidata may not be possible. Hrishikes (talk) 04:13, 27 March 2017 (UTC)
@Hrishikes: good point. Would these be linked with 'main subject'? Actually, it doesn't really matter what the property is, as long as there is some connection to Wikipedia we can just follow it (we have to just define what we consider reasonable linking properties). We'd have to give each chapter in your example its own Wikidata item, but that's a pattern that seems likely to be followed for other things such as journal articles etc. so should be fine. Do you think the base idea here is okay though? That we start by just following 'edition of' properties, where they exist? Sam Wilson 04:20, 27 March 2017 (UTC)
@Samwilson: As I said, one such story will be part of many collections, some of which will be present here. For example, 1 has an image here. So Wikidata will need linking to several chapters of different works. Do you think this kind of thing is feasible? (One Wikipedia article vs. different chapters of different books in multiple language wikisources.) This will come handy for most famous stories of mythological/fairy tale genre. Hrishikes (talk) 04:28, 27 March 2017 (UTC)
@Hrishikes: I think that SW is saying above, 1) let us have a proof of concept, 2) it will have capacity to be expandable as the community considers use cases and sets rules for it to happen. Maybe like a cascading #ifexist hierarchy of links 1st "edition of" < 2nd "main subject" < 3rd ??? — billinghurst sDrewth 05:01, 27 March 2017 (UTC)

Tech News: 2017-13[edit]

14:46, 27 March 2017 (UTC)