From Wikisource
Jump to navigation Jump to 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 331 active users here.



Initiative for coordinating documentation, practices and solutions of misc. Wikisource versions[edit]

Hello, everybody is invited to participate in the project of coordinating documentation, practices and solutions of misc. Wikisource versions. Although the page itself is only in English so far, all comments in any language are welcome in the talk page and will integrated in the page thereafter. It will also be internationalized once enough attention will have been dedicated to it. Thank you in advance for all your contributions, and please be bold to spread the word everywhere you feel apropriate. Cheers, Psychoslave (talk) 03:20, 14 August 2018 (UTC)

Growth team is looking for your feedback and ideas[edit]


Have you heard about Growth team?

The Growth Team's objective is to work on software changes that help retain new contributors in mid-size Wikimedia projects. We will be starting with Wikipedias, but we hope these changes will benefit every community.

We are contacting your project today, because you may be interested by what we work on.

8 ideas we consider: tell us what you think about them!

We are considering new features to build, that could retain new editors in mid-size Wikipedias. We will be testing new ideas in Czech and Korean Wikipedias, and then we'll talk to more communities (yours!) about adopting the ideas that work well.

We have posted the 8 ideas we are considering. We would really appreciate your thoughts and the thoughts from your community. Please share the ideas, and tell us what do you and your community think of those ideas before September 9.

Share your experiences with newcomers

We want to hear about what is working and what is not working for new contributors in your wiki. We also want to hear any reactions, questions, or opinions on our work. Please post on the team’s talk page, in any language!

Learn more about us

You can visit our team page to find out why our team was formed and how we are thinking about new editors, and our project page for detailed updates on the first project we'll work on.

Get updates on your project page

The Growth team's newsletter will provide updates regularly. You can subscribe to it.

On behalf of the Growth team, Trizek (WMF) (talk) 17:41, 27 August 2018 (UTC)


Template to mark works ineligible for copyright due to lack of human authorship[edit]

I propose either creating a new template (perhaps {{PD-machine}}), or altering our current {{PD-ineligible}}, to account for works that are in the public domain due to the absence of human creative expression. This template would make clear, for example, that machine translations of non-English works may be freely hosted here (so long as the foreign-language original works are also eligible).

The question whether machine translations may be hosted here has been discussed at meta: Wikilegal/Copyright for Google Translations, which concludes that such Google holds no U.S. copyright in the automatic translations produced by its software.

Guidance from the U.S. Copyright Office also supports this conclusion. Section 306 of the current (2017) Compendium of U.S. Copyright Office Practices states:

The U.S. Copyright Office will register an original work of authorship, provided that the work was created by a human being.

The copyright law only protects “the fruits of intellectual labor” that “are founded in the creative powers of the mind.” Trade-Mark Cases, 100 U.S. 82, 94 (1879). Because copyright law is limited to “original intellectual conceptions of the author,” the Office will refuse to register a claim if it determines that a human being did not create the work. Burrow-Giles Lithographic Co. v. Sarony, 111 U.S. 53, 58 (1884). For representative examples of works that do not satisfy this requirement, see Section 313.2 below.

The cross-referenced Section 313.2 does not expressly mention translations, but it does provide, in part, that “the Office will not register works produced by a machine or mere mechanical process that operates randomly or automatically without any creative input or intervention from a human author.” This further supports the principle that machine translations contain insufficient human expression to qualify for their own copyright protection.

At present, none of our Category:License templates address the human authorship requirement directly. The closest analog is {{PD-ineligible}}, which addresses works that “consist[ ] entirely of information that is common property and contain[ ] no original authorship.” All the works marked with the present version of {{PD-ineligible}}, however, appear to be the product of human authorship (or at least human transcription), and the {{PD-ineligible}} tag does not appear to address the ineligibility of non-human-originated works as discussed in the above-quoted language from the Compendium.

Because {{PD-ineligible}} in its present form does not quite fit the scenario of works created by machine, I suggest creating a new template that would expressly note that the lack of human authorship disqualifies such works from copyright protection in the United States. Tarmstro99 14:45, 8 September 2018 (UTC)

CC-BY 4.0 as default license in upload forms[edit]

I suggest that CC-BY 4.0 should be the default suggested licensing when using the upload forms in Wikimedia projects for own works, instead of the current CC BY-SA 4.0 license (example at Commons), sometimes with dual GFDL licensing (example here at Wikisource). The main difference would be that derivatives are not required to have the same license. Reasons for changing to CC-BY 4.0 are:

  • It is a more permissive license.
Derivative of medical imaging.jpg
  • It makes it much easier to combine and mix works. The combination of the two images at right, for example, would not have been possible at all if the images were licensed under let's say CC BY-SA 4.0 for the first one and CC BY-NC 2.0 for the other. However, if either was CC-BY 4.0 it would have been permitted. See WP:Adaptation for further information in this regard.
  • CC-BY is by far the most popular licensing for open access journals (see Directory of Open Access Journals - Journal license tab), and is similarly popular in databases (see CC: Data and CC licenses). CC BY-SA is therefore not compatible for inclusion in most open access journals, denying them free access to the sum of Wikimedia knowledge.
  • Most uploaders may very well be as willing to upload under CC-BY, but may not be familiar with the differences between having SA or not. The current upload form layouts thus make lots of works receiving a more restrictive licensing than necessary. Just because uploaders can upload under the most restrictive license Wikimedia has to offer doesn't mean they need to be presented with that option by default. Those who still want to put the additional SA restriction would still be able to actively choose so.
  • The currently suggested dual licensing with CC BY-SA 4.0 with GFDL such as here in Wikisource (link to form) is actually incompatible in a strict sense (see Wikipedia section on this matter, and is also a lot of extra read for those who want to know what GFDL means, since it doesn't provide the short presentation as given in Creative Commons licenses (compare GFDL license page to the CC BY-SA 4.0 page. It would therefore be both easier for uploaders and more legally correct if we simply dropped GFDL from the default license suggestion. Again, those who do want to choose dual licensing for some reason would still be able to actively choose so.

I want to know if you agree with this suggestion, and we can then bring it to Wikimedia's legal team for review before implementation. I know the change is technically not that hard, since we only need to change the upload form layouts, not the licenses of any already uploaded works, nor the overall licensing of any wiki. I've started a vote on this issue in Wikimedia Commons. Please go to that page to join:

Mikael Häggström (talk) 20:57, 10 September 2018 (UTC)

Bot approval requests[edit]

Repairs (and moves)[edit]

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

Index:Her Benny - Silas K Hocking.djvu and pages[edit]

It's been moved to File:Her Benny - Silas K Hocking (Warne, 1890).djvu. Prosody (talk) 23:12, 1 September 2018 (UTC)

What needs to be done (and why isn't it handled automatically)? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:03, 2 September 2018 (UTC)
Since the work was proofread before the file was moved, all of the pages exist using the name of the original file. Someone needs to do a bulk page move to shift the pages to the correctly named file. This is why we try to do all work "fixing" the underlying file before the pagelist is added and the work is listed as 'ready for proofreading'. --Mukkakukaku (talk) 18:23, 2 September 2018 (UTC)

Other discussions[edit]

Boys' Life[edit]

I'm new here. If this magazine is still being published today under the same name, are old versions of it (from 1923 and under) in the public domain? I'd like to make freely accessible here old versions of the magazine, as I find them very entertaining historical reads. Learning about young people from the 1910s-20s and the Scouting movement back then is my intention with this pursuit. PseudoSkull (talk) 19:31, 26 July 2018 (UTC)

Under US law, anything published before 1923 is in public domain, including old issues of magazines. The license may not extend to other countries, depending on the author's date of death, but for en.WP, we concern ourselves with US copyright status. --EncycloPetey (talk) 19:34, 26 July 2018 (UTC)
@PseudoSkull: And just in case I'm talking down to you, please let me apologize beforehand: the fact that it's published today may mean that someone has a trademark on the name "Boy's Life" and certain trade dress associated with it but that trademark cannot serve as a perpetual copyright on previous work. That may be where a confusion is setting in: whether or not something is continuously published today will not impact that old copyrighted material but may make a big difference in trademark issues. —Justin (koavf)TCM 19:38, 26 July 2018 (UTC)
First copyright renewals for periodicals says "Boys' Life: issues renewed from July 1934 (v. 24 no. 7); see 1962 Jan-Jun; contributions renewed from Oct. 1923; see Jan-Jun 1951". We'd have to be careful, but we could go about a decade beyond 1923. I don't know where he's seeing Oct. 1923; the first renewed contribution I see is in 1927. 1923 works will also be clearly public domain in January.--Prosfilaes (talk) 03:08, 27 July 2018 (UTC)
don’t see much scanned at Internet Archive. [1] one standout issue 1924-01 [2] ; they appear at google books [3] but not scanned? i see they have an archive site with scans.
maybe a trip to the library is in order, in addition to Dance Magazine. Slowking4SvG's revenge 19:43, 27 July 2018 (UTC)
@Slowking4: Don't worry; all volumes are on Google Books. I'm doing the monking, since it actually helps with my reading, if you guys don't mind me doing that. See my contributions in my user space. PseudoSkull (talk) 02:08, 28 July 2018 (UTC)
i would suggest uploading them to internet archive, and then to commons using the IAuploader, (then we can have side by side transcription. see also Help:Beginner's guide to adding texts. Slowking4SvG's revenge 02:12, 28 July 2018 (UTC)
@PseudoSkull: Without side by side scans, then the works will never be validated, and will not feature at our site. To get quality-rated works, we do recommend scans. — billinghurst sDrewth 05:22, 29 July 2018 (UTC)
Well, I finished what I guess you would call the first stage of rewriting the story "The Lost Express". I feel good that I accomplished that. I understand I'm probably gonna need to do a lot of extra things to these before they can be officially published here, including at least one personal proofread and probably a peer proofread as well, but I will work on that later. I look to do this whole reading-writing thing more often now, so that's where my contribution to Wikisource comes in. By the way, unrelated, but you guys should probably give that story a read. It was full of great creativity and suspense and was a very enjoyable reading experience for me, so just throwing it out there in case you want to enjoy it yourselves. PseudoSkull (talk) 06:43, 29 July 2018 (UTC)
@PseudoSkull:: see comments above about side by side scans. You will soon find out that you will have to redo a lot of work if you do not start with the right step.— Mpaa (talk) 10:06, 29 July 2018 (UTC)
So you mean you want me to give it a second scan? (as in, buy this and scan it)? I mean surely the book is legitimate in the first place, I won't have to redo any steps due to just the nonexistence of 2 scans right? PseudoSkull (talk) 14:54, 29 July 2018 (UTC)
You were given advice about the process above. See Help:Beginner's guide to adding texts, step 1. Get a file with scans where you (legitimately) find it.— Mpaa (talk) 16:17, 29 July 2018 (UTC)
cut and paste text layer is so 2011, and gutenberg-like. we have been going through and redoing the old ones, i.e. [4] by doing the setup work, we can host complete issues in a e-reader / phone friendly format, with a good provenance to the scan.
do not need to buy issues. the old scans are at their archive site and google books.[5] (and we normally book scan at library) please experiment with uploading complete issues
ok did first one, bouncing at commons for the moment.[6] try some other issues - i can help if you have questions. Slowking4SvG's revenge 17:23, 29 July 2018 (UTC)
File:Boys'_Life_Mar_1,_1911.djvu.— Mpaa (talk) 21:00, 10 August 2018 (UTC)
thanks Index:Boys' Life Mar 1, 1911.djvu , we could use a commons template:magazine for the issn number, like book Slowking4SvG's revenge 16:49, 14 August 2018 (UTC)

New user group for editing sitewide CSS/JS[edit]

This is happening in five days, so we need to be ready. See previous discussion at Wikisource:Scriptorium/Archives/2018-07#"Technical_administrators"_are_coming:_we_need_a_plan. BethNaught (talk) 09:11, 22 August 2018 (UTC)

Adapting Template:pd/1996 or a new template[edit]

As per previous conversation started by Prosfilaes, from next year US-published works published in 1923 will be out of copyright, and progressively year by year others will follow. We need to start working on whether we will adapt Template:pd/1996 to have wording that says that the work is out of copyright, and reconfigure that template to set triggers. Or whether we are going to implement a new template for post 1922 works. (Full coverage at copyright tags.) — billinghurst sDrewth 09:34, 5 August 2018 (UTC)

Don't the 1996-series of template primarily apply to works published outside the US? For works inside the US, we've been using the 1923-series of templates, and I would assume that it's the 1923-series that would need to be adapted to accommodate US-published works from 1923. It would be odd to have "published before 1923" to be a reason a work is in PD, if works published before 1924 is the actual set of works in PD. --EncycloPetey (talk) 15:55, 5 August 2018 (UTC)

You are correct that the pd/1996 has been non-US first publications to this point, and there would be complications in updating the template. Template:pd/1923 is set, and incrementing Template:PD/19xx is possible, though becomes a lot of templates. It is why I brought up the issue as we have to get the wording right, and look to the easiest means to progress through the years. As 1977 is the next US copyright milestone, maybe it is something like pd/1978 with both a year of birth AND year of publishing as parameters, where year of publishing flicks between copyright and not copyright.

billinghurst sDrewth 22:46, 5 August 2018 (UTC)

Let us keep watching for the rest of 2018 to be sure that the US copyright term is not extended. Then I may want to introduce "PD-pub-95" to mean "public domain for being published more than 95 years ago. Renaming Pd/1923 will probably be too disruptive, so making a new template may be better.--Jusjih (talk) 04:48, 9 September 2018 (UTC)
It's not going to happen, and part of the reason it's not going to happen is because we are going to rip the hell out of Congress if they try. Being able to say that are already preparing for this change will only help our case. And when the ball drops in New York, I will be uploading 1923 works, and will need an appropriate tag.
I'd like a single PD tag that takes publication year and author death year (if known), and it shouldn't mention in the name the exact rules, just applying all the rules that can be deduced clearly from publication year and author death year. Maybe just naming it PD-old would be too much?--Prosfilaes (talk) 06:35, 10 September 2018 (UTC)
I support the single-PD template idea. While it would be rather an in-depth template, I don't think it would be particularly difficult to implement (just a series of if-elsif-else conditions). Mukkakukaku (talk) 00:56, 13 September 2018 (UTC)
The US Copyright Office already considered the copyright terms too long. Mid-term election will be soon. Template:Pd/1923 is heavily used, so renaming will be harder than adding new template like "PD-pub-95". I will wait for the ball to drop in Times Square.--Jusjih (talk) 03:00, 18 September 2018 (UTC)

How to Transclude TOC from Subpages?[edit]

The page Translation:Likutei_Moharan has its content split into three subpages.

Each subpage has its own Level Two sections and TOC. How can I get those TOC's transcluded into the main page TOC?
Because the work is in progress and some sections are not yet done, a static TOC on the main page is not desired; a transcluded TOC is wanted.

I've tried {{CompactTOCalpha-fromsubpage}} which didn't work (it's on the page code currently), and I don't want the alphabetical style.
I don't see a sort of "TOC-fromsubpages|limit=#" template.

How can this be done?

Nissimnanach (talk) 21:15, 8 August 2018 (UTC)Nissimnanach

where is the match and split? where is the commons source? you could transclude from base page if you had it. for example, you have a title page for this work only File:Likutey Moharan.gif -- Slowking4SvG's revenge 10:53, 14 August 2018 (UTC)
@Nissimnanach: I don't think this is actually possible. The TOC on each subpage is automatically generated from the section headers on that page, so it would only appear on the main page if you were to transclude the section headers manually. The list of subpages should be sufficient. —Beleg Tâl (talk) 12:34, 14 August 2018 (UTC)
We probably could do it with section tags, or with <includeonly> tags, my question would be why? We are better off to just manually apply it rather than force the system to perform black magic through complex page calls. You have the ToC on the subpage, just copy, paste and reformat. — billinghurst sDrewth 23:20, 14 August 2018 (UTC)

Glasgow Advertiser - 13 August 1792 - Richard Arkwright[edit]

I'm still learning. How cold Glasgow Advertiser - 13 August 1792 - Richard Arkwright be improved? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:20, 8 August 2018 (UTC)

On en.Wikisource, we don't have categories by author or people. Also, it isn't necessary to categorize by work, if the work has a base page built into the name: e.g. Blackwood's Magazine/On the Cockney School of Poetry VI.
Also missing a license; now added. --EncycloPetey (talk) 22:18, 8 August 2018 (UTC)
@EncycloPetey: Thank you. I've moved it to Glasgow Advertiser/1792-08-13 - Richard Arkwright and create a parent page. However, without a category, how can we associate the text with (other Wikimedia content about) Richard Arkwright - not least the related Wikidata item, d:Q294153? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:09, 9 August 2018 (UTC)
(1) If the person in question is a published author, then we create an Author page in the Author namespace, and list the item under "Works about Arkwright". (2) Otherwise, you can create a data item for the obituary, and link the obituary's data item to the subject's data item using the Wikidata property "described by source". (3) There is also a {{wikisource-inline}} template on Wikipedia that allows for the listing of individual Wikisource works in the References or External links section. --EncycloPetey (talk) 14:36, 9 August 2018 (UTC)


In English texts, like 'Description and Use of a New Celestial Planisphere', should we change "ſ" to "s", or transcribe ("tranſcribe"?) the character as written? Substitution certainly aids readability for a modern audience. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:06, 9 August 2018 (UTC)

You will find that opinions on this vary among contributors. I would recommend using the {{ls}} template: this renders as ſ in page space and s in mainspace, but there is a script to let users choose how they see the template. BethNaught (talk) 13:35, 9 August 2018 (UTC)
While there is opinion, the community's consensus is that the output in the main namespace should typically be "s", unless the work requires the production of it; covered in Wikisource:Style guide/Orthography. BethNaught mentions an option for Page: ns production, with options. — billinghurst sDrewth 13:53, 9 August 2018 (UTC)
@Pigsonthewing: What BethNaught and billinghurst said. And there are charset issues with using the raw long s character directly, so if included it should be by way of the template. However, to give you an answer that I think addresses your question directly, nobody is going to complain if you modernise this character to "s". --Xover (talk) 14:43, 9 August 2018 (UTC)
The underlying thought is that preserving archaic orthography typically matters only when the text is highly significant in some way, either historically or academically, such at the original handwritten text of the US Constitution, or the First Folio of Shakespeare. For most works, the shape of an "s" in the text is irrelevant. --EncycloPetey (talk) 15:08, 9 August 2018 (UTC)
It's marginally orthography; it's as much typography. When G.W. revised English orthography in Magazine, he left the long-s as is. When the long-s was dropped, nothing else in English changed. It's more a part of certain font styles than actual orthography.--Prosfilaes (talk) 00:45, 10 August 2018 (UTC)
Handwritten text is not a matter of typography; it does not involve the setting of type. Please read again what I wrote, which includes a well-known handwritten example. --EncycloPetey (talk) 15:16, 10 August 2018 (UTC)
Handwritten text is subject to variations, positional and otherwise, usually far more than typeset material. It's not typography--I don't know of a neat word for it--but it's a matter of handwriting style as much as a matter of orthography.--Prosfilaes (talk) 19:16, 10 August 2018 (UTC)
The "neat" word is orthography = "writing correctly". It is only the more modern usage of the word that tends to limit its definition to spelling; the broader sense of the word includes handwritten forms. Some people segregate handwritten forms to graphology, but that split is not universal. --EncycloPetey (talk) 00:35, 11 August 2018 (UTC)

Typo on the front page[edit]

"Observations upon the Dublin Bills of Mortality (1863)". Date of text is 1683. Celuici (talk) 20:19, 10 August 2018 (UTC)

Fixed, thanks.— Mpaa (talk) 20:41, 10 August 2018 (UTC)
My mistake! Sorry! --Dick Bos (talk) 16:42, 12 August 2018 (UTC)

Google notice[edit]

Do we still consider the Google notice at the beginning of a scan from that source as something that must be fixed prior to proofreading? Or can we just mark those "no content" and ignore such pages?

I'm working my way through the category of indices to check and there's a lot whose only problem is the presence of that Google scan notice is present. I'd rather not have to mark them as 'to be fixed' since the backlog in that category is insane.

Thanks. Mukkakukaku (talk) 20:12, 11 August 2018 (UTC)

The main problem with it is that it pushes all the ensuing pages out by one. This means that left and right pages show up incorrectly as right and left. This is why the iaupload tool now offers the option of deleting the first page. There is also the minor issue of some Commons admins deeming that page to be copyright and therefore the whole book is not permitted to be on Commons. So, yes, they should be fixed (unfortunately). Beeswaxcandle (talk) 22:59, 11 August 2018 (UTC)
Commons does not necessarily delete such files. Please see c:Commons:Deletion requests/Google books with Google first page -- Hrishikes (talk) 02:56, 13 August 2018 (UTC)
That deletion discussion is weird. The conclusion is "delete" but the rationale provided is "Public Domain no matter what Google claims. Faithful repro doesn't create new copyright. Just a generic page added." ... Either way. I'm marking those files as needing fixing. Mukkakukaku (talk) 02:59, 13 August 2018 (UTC)
As I understand previous thought at Commons on the matter, it is the notice from Google that is under copyright and can't be reproduced. So it's the notice itself that is the problem—not the claim made by Google, which is deemed to have no validity—but the notice page stating the claim. --EncycloPetey (talk) 03:14, 13 August 2018 (UTC)
What about the "new" form of the Google notice which doesn't make a copyright claim? Like the one on the first page of this file? I've been treating all forms of Google notice the same, but it only occurred to me that these new ones that don't make a claim might be ok. (Though I personally am on the side of cleaning up the scan because it's just cruft.) Mukkakukaku (talk) 03:52, 13 August 2018 (UTC)
My opinion is that it should go away. The Google logo is potentially an issue, but even if it isn't, the left/right and odd/even pagination will be off for the entire work because of that extra Google page. --EncycloPetey (talk) 15:19, 13 August 2018 (UTC)

Permissions for MpaaBot[edit]

Hi. I was investigating the possibility of changing Proofread status via pywikibot and I had problems using MpaaBot instead of Mpaa (see
Digging into it in the ProofreadPage extension, I think it narrows down to MpaaBot not having the 'pagequality' rights.
My understanding is that such right comes automatically for all users, see
If so, how is it that MpaaBot does not have it?

I get the following via pywikibot.

It comes automatically for users. It does not come automatically for bots. If you want to add that feature to your bot, we'd need to have a request with rationale. We've usually considered changing the proofread status to be a highly significant change, implying a user proofreading against a scanned text. I don't see why a bot would need to mark proofread status. --EncycloPetey (talk) 02:47, 13 August 2018 (UTC)
Proofreading against a scan can be done manually offline. The result can be uploaded in bulk via API instead of the standard page-by-page web interface. The bot is just like a CLI tool to post content.— Mpaa (talk) 08:37, 13 August 2018 (UTC)
Mpaa, can PageQuality be applied through the API? Wondering whether this may be a front end issue that PQ needs to go via the interface, or an equivalent of the interface. There are number of restrictions around PQ so guessing that it is something bundled up with those rules. I can test with sDrewthbot at some point to see if it can force things with that. — billinghurst sDrewth 00:19, 14 August 2018 (UTC)
Yes, it can (with the same rules as standard interface). But not for Bot accounts because they miss the 'pagequality' right. BTW, I think it is something good to have, not a negative thing.— Mpaa (talk) 07:01, 14 August 2018 (UTC)
One more info. The difference is not in being a standard account or a bot account, but how the account is logged in. If the account is logged in with OAuth, the set of allowed rights is limited. I wonder where to ask to add "pagequality" as a right for OAuth authentication.— Mpaa (talk) 09:05, 14 August 2018 (UTC)
@MarcoAurelio: You are more around OAuth than others and have a modicum of Wikisource interest, are you able to advise here with regard to a right that comes from mw:Extension:ProofreadPage? — billinghurst sDrewth 23:14, 14 August 2018 (UTC)
See also .— Mpaa (talk) 15:32, 15 August 2018 (UTC)

Inline HTML broken[edit]

Page:The Columbia River - Its History, Its Myths, Its Scenery Its Commerce.djvu/151

Why? ShakespeareFan00 (talk) 08:08, 13 August 2018 (UTC)

Because the text was copy-pasted from Gutenberg, then matched-and-split, instead of being proofread from the source scan. --15:17, 13 August 2018 (UTC)
And also because the correct syntax for images is [[File:PictureName.jpg]] and the correct syntax for <br> does not have a space after < —Beleg Tâl (talk) 15:24, 13 August 2018 (UTC)
ok. i tend to replace missing image with raw image, to encourage crops. and then use crop tool and FI template. did your one example. the bot of page creations are nice, but it needs improvement / copyediting for hard things like image formating. Slowking4SvG's revenge 03:42, 14 August 2018 (UTC)

Tech News: 2018-33[edit]

17:53, 13 August 2018 (UTC)

Scans with missing pages[edit]

Inside of Category:Index - File to fix is a sub-category Category:Scans with missing pages. Is it possible to sort Index pages in there? (A template would be ideal if nothing else.) It appears to be unused, but it would be quite useful to be able to categorize pages in there since they're a distinct kind of fixing (as opposed to misaligned text layers, duplicate pages, page re-orderings, and google scan page removals). Mukkakukaku (talk) 05:04, 16 August 2018 (UTC)

It is filled from Template:Missing pages which designated for use on index pages. — billinghurst sDrewth 06:24, 16 August 2018 (UTC)
I don't think that template is working, then. I added it to Index:15 decisive battles of the world Vol 1 (London).djvu but the category remains empty. :( Mukkakukaku (talk) 23:52, 16 August 2018 (UTC)
Nevermind, the template wasn't detecting the namespace correctly. I took care of it (though there might've been a better solution, I'm only like 60% on this template syntax stuff.) Mukkakukaku (talk)

OK that being said, should we be proofreading the files with missing pages? The template indicates we should be -- "Placeholders have been inserted, so proofreading can be done without needing to move content later, if the missing pages are found." -- but I was under the impression that these files should be marked as needing fixing, and only returned to the proofreading pool once the missing pages were located and surgery performed on the file. There's a number of older works apparently utilizing the template in the "placeholders inserted, go ahead and proofread" workflow, while the newer ones I've begun tagging are marked for fixing. --Mukkakukaku (talk) 03:54, 17 August 2018 (UTC)

To me it is all about whether we can fix the work or not. If we can fix the work, then we should mark it for repair, or replace it.

That said, I have proofread works where they are missing maps through scans, or missing a page or two, and I have proofread as the remainder of the work was of sufficient novelty or interest, and there was no alternative version available. Sure it won't be a work capable of gaining our quality stamp, however, I would rather have it short a page or two, than not at all, and maybe we will get the missing pages in time. — billinghurst sDrewth 04:01, 17 August 2018 (UTC)

Agree with this. Example, Index:FirstSeriesOfHymns.djvu is missing one page, but the rest of the work is worth hosting regardless, and that one page can be easily repaired if a scan of that page is located. —Beleg Tâl (talk) 13:05, 17 August 2018 (UTC)
Seems like we might want to formalize a policy. What if they're missing illustrations? Index, table of contents, actual pages of a novel, appendices, etc. I'm sure it's a judgement call at times, but it seems to me that actual content pages are more "valuable" than non-content pages. (PS: I fixed your link to First Series of Hymns.)
Counter example: I recently deleted a copy of a Beatrix Potter book that was missing some illustrations. For those unfamiliar, half of the charm is the fact that they're classic hand-illustrated children's works, with very distinctive and recognizable illustrations of the animal characters. The works are only about 30 pages long, each, alternating text and illustrations. What if we were missing a page or two of illustrations? That's almost 10% of the work right there, even if it's not the text of the work, the illustrations are half the point anyone reads those books. (Actually I don't even recall the plots of most of them, just the illustrations.)
Counter example 2: Index:CAB Accident Report, United Airlines Flight 16.pdf. I personally wouldn't want this official government report proofread until someone tracks down the missing page 17 because I think the content is material to the integrity of the overall work, even when only a single page is missing.
Imagine reading something, a novel, only to get to a certain point and to find that the content is just not there because the scan was faulty and we proofread it anyway -- I personally wouldn't want that experience and would be extremely disappointed. Since it doesn't seem anyone is really working the backlog in the files for fixing (there's some easy stuff in here I marked for fixing five years ago and nobody's touched since), I think this isn't an altogether safe workflow to rely on. The First Series of Hymns isn't even categorized into the Indices with Missing Pages category, so it's invisible. Easily fixed by adding the template, true. But the point is that this isn't on anyone's radar for addressing. --Mukkakukaku (talk) 18:24, 17 August 2018 (UTC)
It is always a qualitative call, and we often make those calls. We have WS:PD for that reason. Trying to write a specific "policy" statement is too tricky. If we were to say anything it should be a qualitative statement within WS:WWI. The best we can talk about the deletion determinations that we have made based on quality. — billinghurst sDrewth 09:09, 18 August 2018 (UTC)

Unable to change status of What Can I Do^ - NARA - 534471.jpg[edit]

Yesterday I had a go at proofing Page:What Can I Do^ - NARA - 534471.jpg, however it doesn't appear to be associated with an index, so I am unable to change the pages status from "To be Proofread" to "To be Validated."

Is this a problem with the file or as expected for a single page? Is it possible to change the pages status? Sp1nd01 (talk) 08:35, 16 August 2018 (UTC)

@Sp1nd01: We have to force an index page, which I have done Index:What Can I Do^ - NARA - 534471.jpg. As we have to manually code the page: rather than use <pagelist /> the Index: name is flexible, though here it is just easy to match it. Transclusion is a little different in the code and is explained at mul:Wikisource:ProofreadPage, so if you have an issue getting it going, then please get back to us. — billinghurst sDrewth 04:12, 17 August 2018 (UTC)
Thank you for the help, I have created the pagelist and transcluded it. I think its now fully complete. unsigned comment by Sp1nd01 (talk) .

Visual Editor[edit]

There is most likely an issue with Visual Editor (see Wikisource:Scriptorium/Help#Wuthering_Heights discussion and related bug). I think we should consider to stop using it for now as (some) pages will need rework. In they decided to block such breaking VE edits using AbuseFilter (see my talk page discussion).— Mpaa (talk) 15:32, 18 August 2018 (UTC)

Is it the VE itself? I see that this page has a double "to be proofread" header, and I see this quite a lot on pages. I assume you weren't using the VE to create these pages? So there may be an additional issue causing the duplication or complete removal of the page information about page status. --EncycloPetey (talk) 18:22, 18 August 2018 (UTC)
I am not sure but I think so, pages in question are tagged with 'visualeditor'. For the one you mention, I submitted a bug: .-— Mpaa (talk) 18:37, 18 August 2018 (UTC)

TemplateStyles and book formatting[edit]

TemplateStyles are enabled now. Can we consider using this to make CSS for specific books and implement semantic HTML? For example, using real h2 tags instead of {{center}} and {{smaller}}. Suzukaze-c (talk) 03:17, 19 August 2018 (UTC)

That would be an odd choice of tags. h2 is for second-level headings, while all {{center}} and {{smaller}} do is either center the content or change the font size and make no implications as to page hierarchy. If anything they'd be replaceable with CSS text-align:center or margin:0 auto, and font-size:0.9em. Mukkakukaku (talk) 04:51, 19 August 2018 (UTC)
I am talking about emulation of header tags using these formatting templates, such as at Page:TRC Canada Interim Report.pdf/10. Suzukaze-c (talk) 06:51, 19 August 2018 (UTC)
The issue is that we have no standard H2, so how can we push that universally. We should definitely be looking to utilise TemplateStyles, however, I don't think that we are looking to override existing default styles. — billinghurst sDrewth 13:59, 19 August 2018 (UTC)

Tech News: 2018-34[edit]

16:46, 20 August 2018 (UTC)

List of broken links from Wikipedia to Wikisource[edit]

In my profile: User:Uziel302 I put a list of 340 broken links from Wikipedia to Wikisource, any help fixing those links is much appreciated. Thanks.Uziel302 (talk) 07:58, 22 August 2018 (UTC)

Some examples:
  1. w:Alabama to Wikisource:Alabama
  2. w:Afghanistan to Wikisource:Afghanistan
  3. w:Azerbaijan to Wikisource:Azerbaijan
  4. w:Ancient_Egypt to Wikisource:Ancient_Egypt
  5. w:Aga_Khan_III to 1922_Encyclopædia_Britannica/Aga_Khan_III
  6. w:Antipope to Dictionary_of_Christian_Biography_and_Literature_to_the_End_of_the_Sixth_Century/Dictionary/Z/Zephyrinus
  7. w:Andrew_Carnegie to 1922_Encyclopædia_Britannica/Carnegie,_Andrew
  8. w:Angles to Ecclesiastical_History_of_the_English_People/Book_2
  9. w:Angles to Historia_Ecclesiastica_gentis_Anglorum_-_Liber_Secundus
  10. w:Angles to The_Ecclesiastical_History_of_the_English_Nation
  11. w:Aswan to Dictionary_of_Greek_and_Roman_Geography/Aswan
  12. w:Andalusia to Estatuto_de_Autonomía_de_Andalucía_2007
  13. w:Beryllium to Beryllium

Thanks, Uziel302 (talk) 10:51, 22 August 2018 (UTC)

There may be some broken links to the Folk-Lore Journal at en.wikipedia, the result of a move with suppressed redirects. — CYGNIS INSIGNIS 11:25, 22 August 2018 (UTC)
Anything that was Wikisource: namespace is now Portal: ns. To the others, there looks to be a collection of never/wishful, or moved. — billinghurst sDrewth 12:15, 22 August 2018 (UTC)
Looking through the list itself, one wonders why it was linked in the first place. Can I suggest for people, that you can use {{wikisource author}} as that was redesigned to utilise Wikidata interwiki links so moved pages are automatically updated. One day I am hoping that Wikipedia is better acclimatised to WD and many of their citation templates will be able to utilise a WD-based citation. — billinghurst sDrewth 12:23, 22 August 2018 (UTC)
billinghurst, is there an option to make Wikisource namespace redirected to Portal namespace? Uziel302 (talk) 16:09, 22 August 2018 (UTC)
No, that would be a cross namespace redirect, and wikis don't do it. Portal is a content namespace, and Wikisource is not. — billinghurst sDrewth 22:54, 22 August 2018 (UTC)
Just found a better query for these broken links, updated my page to include over 5,000 broken links. Uziel302 (talk) 08:02, 24 August 2018 (UTC)
Bunch of those aren't actually intentional links to Wikisource. They're trying to link to articles about Swedish tv shows, churches, etc. that are prefixed using the abbreviation S:t -- eg. "S:t Mikael" (a tv show). The "s:" prefix is forcing a WS interwiki.
Also this seems like something that they should be fixing up over the the enWP side. I fixed up a bunch where it was a clear "page moved" situation, but it's a thankless task. Mukkakukaku (talk) 00:32, 25 August 2018 (UTC)
well, i will thank you. a bunch of those are broken DNB links, and missing transcribed articles that were copied there from IA. (i.e. The New International Encyclopædia/Leutze, Emanuel) we did a 12000 article backlog for EB1911 - NIE and Appletons should be easy, not soul crushing at all. Slowking4SvG's revenge 02:55, 29 August 2018 (UTC)
by the way, some of those may be the em dash versus en dash conflict. Slowking4SvG's revenge 02:52, 3 September 2018 (UTC)

Latest message for Collaboration team newsletter; Growth team's newsletter invite[edit]


Sorry to use English if that's not your favorite language.

You are receiving this message because you were reading the Collaboration team newsletter.

The Collaboration team doesn't longer exists. That team was working on building features that encourage collaboration. This is the latest message for that newsletter.

The Growth Team, formed in July 2018, supports some former Collaboration projects. The Growth Team's main objective is to ease new editors' first steps on wikis, through software changes. You can discover all objectives and missions of the Growth team on its page.

If you wish to be informed about Growth team's updates about easing new users first steps, you can subscribe to the new list to get updates. The first message from Growth –with a call for feedback on a new project– will be posted in a few days!

If you have questions or you want to share experiences made on your wiki about new users' first steps, please post them on the team talk page, in any language.

On behalf of the Growth team, Trizek (WMF) (talk) 10:29, 22 August 2018 (UTC)

N-like character[edit]

What is the penultimate character, in "BRÂHMANA" / "Brâhmanas", in Page:Sacred Books of the East - Volume 12.djvu/11 and oher pages of that work? en.Wikipedia renders the word as "Brāhmaṇa". Note also "ā" vs. "â". Which should we use? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:42, 24 August 2018 (UTC)

It's just an italic N. The author's choice of notation should be followed, so Brâhmana is the preferred option here. —Beleg Tâl (talk) 22:05, 24 August 2018 (UTC)
The initial "s" in SATAPATHA is also italicized. --EncycloPetey (talk) 00:02, 25 August 2018 (UTC)

Link spans two DjVu pages[edit]

The last words at the end of Page:The Cambridge History of American Literature, v4.djvu/18 and the first word of Page:The Cambridge History of American Literature, v4.djvu/19, taken together, are the title of a work, which should form a single HTML link in the final rendered page. How is this to be achieved? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:43, 25 August 2018 (UTC)

The templates to use are {{linkable phrase start}} and {{linkable phrase end}}. —Beleg Tâl (talk) 11:56, 25 August 2018 (UTC)
Or utilise the footer on the first page to put the text to be melded, then judicious use of <includeonly> with the respective text, on the second page. — billinghurst sDrewth 01:26, 27 August 2018 (UTC)

Using gadget to create an index page[edit]

I have uploaded a DjVu file to Commons, and am trying to create the corresponding index page here. I have enabled the "gadget to auto-populate fields from the File: at Commons", but cannot see how to use that gadget when I'm on the Index creation page. Should it activate automatically? (If so, why is it not?), or should there be a button or link to invoke it? (If so, where?). I have checked all the relevant help pages, but could not find anything on this. I have also double-checked my spelling of the file name. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:32, 25 August 2018 (UTC)

I use the link provided from the book template on the djvu file at commons and open the source index page. Then I get this daunting page that feels like failure (about how the page doesn't exist, blah blah blah). I use the "Create" or "Create this page" link located at the upper portion of the failure page and if I could spell walah.... The index page that occurs will need some help, but it is pretty cool how the gadget works.--RaboKarbakian (talk) 15:07, 25 August 2018 (UTC)
If you have the {{book}} (preferable) or {{information}} template completed at Commons, when you create (action on your part) the Index page will be populated with the appropriate corresponding data fields. — billinghurst sDrewth 06:55, 26 August 2018 (UTC)
I have done a little text edit to the gadget description to (hopefully) clarify the process. — billinghurst sDrewth 06:58, 26 August 2018 (UTC)

Page numbers borked with hyphenated words[edit]

In working on Characters of Shakespear's Plays (which is ready for validation, hint hint :) ) I notice that page number display in mainspace seems to be broken whenever there's a {{hyphenated word start}}, or a quote that crosses page boundaries (using {{margin left}} + {{smaller block/s}}; and closed with 2 x {{div end}}), in the relevant Page:-pages. When these occur the bits of the page highlighted in mainspace when hovering over the page number is truncated in strange ways, and the page numbers corresponding to the relevant pages do not show up (they are in the html source of the page though). Subsequent page appear correctly numbered and the highlight works as expected; and the actual content of the affected pages is present as expected. A known issue with… the page number display? Something I'm doing wrong? --Xover (talk) 13:12, 26 August 2018 (UTC)

Would you please provide a direct link to a broken subpage. Also it would be worth using {{auxiliary Table of Contents}} on the root page. It is not a known issue that it is broken, and I have been doing plenty of works that way recently. — billinghurst sDrewth 13:14, 26 August 2018 (UTC)
Thanks. Page 18–19 on Characters of Shakespear's Plays/Macbeth (in that there's no page 19 link in the left margin on my browser). AuxToC is coming up. --Xover (talk) 13:21, 26 August 2018 (UTC)
works for me in firefox browser. Slowking4SvG's revenge 16:23, 26 August 2018 (UTC)
Meh. I hadn't even considered the possibility that it might be browser-related. Thanks. I'll try fiddling there to see if anything dawns. --Xover (talk) 17:32, 26 August 2018 (UTC)
Works in Firefox and Internet Explorer 11. Broken in Safari and Chrome. All latest versions, except IE. Logged in or logged out doesn't affect it. --Xover (talk) 17:44, 26 August 2018 (UTC)
Hmm. And when I turn on page numbers inside the text from the Display Options in the sidebar (that I, frankly, had no idea existed until now), page 19 shows up again and is in the right place in the text. But, looking through this with a debugger, I see Safari gives the span element with the ID "18" an .offsetTop() of 1225 pixels; page 19 is 976 pixels; and page 20 is 1814 pixels. Which is of course impossible since the spans in question follow one another from top to bottom in the page. The immediate reason page 19 isn't showing up is that the page numbering code checks that there's at least 5 pixels between the current and previous page number, and since 976 - 1225 is in fact less than 5 (as it's a negative number), the scripts hides the page number with display: none. Now, as to why Safari gives page 19 a nonsensical .offsetTop()… I have no idea. Could this really be bugged in Safari? Or, rather, in Webkit, since Chrome also sees this behaviour. Not sure where to dig next with this. --Xover (talk) 19:46, 26 August 2018 (UTC)
Just for completeness, I checked the offsets in Firefox and got: 984 for page 18; 1186 for page 19; and 1436 for page 20. Pretty much as expected, in other words. --Xover (talk) 20:48, 26 August 2018 (UTC)
Ok, this is getting… weird. It appears there's a bug in Webkit where .offsetTop is calculated incorrectly for empty inline elements (the page numbers are an empty <span>). The bug was reported in 2011 but the Webkit project seems to think it's notabug (I don't understand their reasoning for this, and the conclusion appears nonsensical on the face of it). That explains why page numbers inside the text works: when you toggle this the PageNumbers script puts the link etc. inside the formerly empty <span> (making it non-empty, and avoiding the bug). However, since this only affects certain pages, but all page markers are empty <span> elements, there has to be a further factor at play. And it looks like that factor is this: when {{hyphenated word start}} is used, there is a space character before it, and that shows up in the generated HTML before the page marker <span> (which won't be there for non-{{hws}} pages). That single space character appears to be what triggers the Webkit .offsetTop bug. To wit: I removed the space before {{hws}} on page 19 in the Page:-namespace, and lo and behold, now the page number for page 19 shows up properly in mainspace. I have no idea what to do about this (cry? laugh hysterically? take up fishing?). --Xover (talk) 15:26, 27 August 2018 (UTC)
You might consider opening a ticket on phabricator with your findings? Since it is a known defect in webkit's implementation of offsetTop, then it stands to reason there are workarounds that can be implemented in a cross-browser fashion, if not by browser sniffing then possibly via another mechanism. Mukkakukaku (talk) 00:20, 28 August 2018 (UTC)
yeah- wrap it up with a bow, for a GSoC or hackathon task. display options have only worked since 2016. you could also apply for a grant to fix it. Slowking4SvG's revenge 03:23, 28 August 2018 (UTC)

More details than you wanted[edit]

Ok, I've done some more digging into this, and it still boils down to a really weird bug in webkit (Safari, Chrome). Given a construct such as…

1: TEXT <span id="p1"></span>TEXT<br/>
2: TEXT <span id="p2"></span>TEXT<br/>
3: TEXT  <span id="p3"></span>TEXT<br/>
4: TEXT <span id="p4"></span> TEXT<br/>

…which approximates what MediaWiki + ProofreadPage + pagenumbers.js is doing/using, webkit will report the wrong .offsetTop value for lines 3 and 4 (that is, for the page markers for a page 3 and a page 4). In this example it is triggered by the two space characters in front of the <span>-element in line 3, and by the single space character after the <span>-element in line 4. It does this even though all of them report the same .offsetParent (the <body>-element in my test case; on Wikisource it's the <div id="regionContainer">-element).

The extra space character in line 3 is the case that seems to trigger it on Wikisource when {{hws}}/{{hwe}} are in use, because in the final HTML output you will get both the literal space character preceding the {{hws}} on the first page and the character entity reference for the space character that Mediawiki inserts when it transcludes the two pages together.

The webkit folks haven't acted on this bug over the last 7 years (reported in 2011 I think), and seemed then to think that this was intended behaviour, so I'm not holding out much hope that they'll do anything about it any time soon. Instead I'm going to look into whether there is any kind of reasonable workaround that can be implement here to avoid triggering this bug. Not sure there is one, at least not without major surgery to MediaWiki/ProofreadPage, but it seems more promising than getting Webkit fixed in any case. --Xover (talk) 16:48, 30 August 2018 (UTC)

Ok, it looks like in every case where this is triggered by {{hws}}/{{hwe}} it can be worked around by moving the preceding space character into the template: it is not {{hws|no|normal}}it is not{{hws| no|normal}}. This gives correct presentation in the Page:-namespace, even if the underlying markup is technically incorrect, and doesn't affect the main namespace (because the mainspace content is taken from the following {{hwe}}).
There are, however, other things that trigger this (or possibly a similar bug), mainly variations of cross-page formatting markup. In my case I have long multi-page quotes offset using {{margin left}} + {{smaller block}}, both in start+end-tag mode ({{div end}} in the footer, and on the page where the quote ends). In these cases my suspicion is that it's actually illogical markup that gets generated. By default a paragraph will be wrapped in <p>…</p> tags; but the formatting templates mentioned above will insert a <div> start tag in one paragraph that won't have its corresponding </div> end tag until a later paragraph. This is either output as is (leading to invalid markup), or some Mediawiki mechanism is doing something magical to compensate for it. In either case, whatever it is that's happening there gives the same symptoms as the Webkit bug, and seems likely to be a different way of triggering the same bug. --Xover (talk) 06:16, 6 September 2018 (UTC)
Ok, it looks like the multi-page quotes are just another variant of the trigger for the same bug. In this case it's the <br/> at the end of the first page rather than the extra space character left behind by {{hws}}, but in both cases it's having extra whitespace before the page span that triggers the Webkit bug. In the multi-page quote (or, probably, more properly multi-page formatting of any kind) case, a workaround is to simply move the <br/> to the start of the following page. It ends up displaying a single extra newline on the following page in the Page: namespace (which you won't notice if you don't have pilcrow paragraph markers enabled), but otherwise gives correct presentation. Both these workarounds are, of course, {{nop}}-level voodoo coding, and tedious as nevermind, but do sort of work. --Xover (talk) 06:41, 7 September 2018 (UTC)
Hmm. Perhaps we could detect this bug by checking if the current page span's .offsetTop is less than the previous page span's, and then temporarily set the current span to display: inline-block or something just to get the correct .offsetTop? Since inline page numbers (which are inline-block and have the page number as content) have the correct .offsetTop it should be possible to do at the cost of some more processing. Combined with ignoring negative offsets to work around the possible Firefox bug mentioned below, that might eliminate a whole bunch of cases of weirdness with the page numbers. Anyone have any thoughts on such an approach? Billinghurst? Anyone? --Xover (talk) 05:31, 7 September 2018 (UTC)
No, testing suggests it's insufficient to simply set the spans to be inline blocks: the core issue in all of these is that both the specifications and browser implementations treat empty inline elements in weird and inconsistent ways. As an example, what is actually happening in the case of multi-page quotes, is that there's a block-level element (p or div) that surrounds the quote across pages, and the span that marks the page—because it is empty—is taken out of the normal flow (much like floating elements) and placed at the beginning (top left corner) of the containing block's layout box. The .offsetTop value we get back in those cases isn't so much wrong in itself so much as they are reflexive of an underlying behaviour of the layout engine.
That underlying layout engine behaviour seems the best place to tackle this. The construct currently used when two pages are are transcluded together is &#32;<span><span class="pagenum ws-pagenum" id="19" data-page-number="19" title="Page:Some_Work.djvu/49"></span></span> The &#32; is the default configured page separator for the ProofreadPage-extension. I'm not entirely clear on where the spans come from, or why there are two of them, but the main problem is that both of them are empty. When inline elements are empty browsers tend to calculate a layout box for them that is 0 pixels high and 0 pixels wide: that is, a dimensionless point. This is then removed from normal flow and placed at the beginning of its containing element's layout box. Any content inside these spans that generates a text box (a text layout box is what its CSS background-color applies to; it's the area with the gray background in the code snippets here) will make them non-empty and will make the layout engine start treating them the same as it would, say, an <i>emphasised</i> word in the text.
Since anything we put in there will affect the rendering of the page, we can't just stuff a random text string in there (it'd show up in the page). Normal whitespace also won't work because the layout engine optimizes it away and ends up treating the span as empty again. However, we have the Unicode Zero-width space character. It is intended to be an invisible character that hints to layout engines about a suitable place to break text between lines (see the example in the enwp article). But it also works fine as a general invisible marker: in the rendered page it is invisible, but gets a text box that's 1px wide and font sizepx high.[1] Since it now has dimensions the layout engines treat it as part of the normal flow, and we will avoid all the weirdness that comes with empty inline elements.
Depending on what particular bit of code is inserting those spans, the (proposed, must be tested) solution is either to add a &#8203; in the innermost span there, or to make the PageNumbers.js script add it dynamically before getting their positions. --Xover (talk) 07:30, 8 September 2018 (UTC)
@Xover: One possible existing "hook" is MediaWiki:Proofreadpage pagenum template which is the "template" (yes, yes, wrong namespace - you didn't think this stuff ought to make sense, did you?) for the inner of your two nested spans. You may also wish to view the archives - an aborted discussion on a related topic which might have some useful facts: Wikisource:Scriptorium/Archives/2016-09#Making_<pages>_more_flexible? 10:07, 8 September 2018 (UTC)
Thanks! For this particular purpose, it looks like simply adding &#8203; to MediaWiki:Proofreadpage pagenum template would be sufficient. And I can't immediately think of any likely negative side effects of doing so. In other words, it might actually make sense to simply do so and then spot-check a couple hundred works for obvious breakage. The most likely places for that to occur are the very pain points mentioned in that discussion thread: multi-page tables. But since Phrasing content (which text, including character references, are) is allowed anywhere <span> is, the addition should not create any problems that are not already present. The only way to know for sure is to try, I think. --Xover (talk) 07:03, 9 September 2018 (UTC)
Something else to note (official documentation here): {{hws}} is not the source of the extra space between transcluded pages. It is inserted by global mediawiki PHP code beyond the scope of administrative control within local enWS. 02:12, 17 September 2018 (UTC)
@Billinghurst: (or anyone else with relevant knowhow) It looks like MediaWiki:PageNumbers.js is loaded unconditionally by the skin (or somesuch)? That is, there's no actual way for me to disable it in order to experiment with a custom version in my user scripts. Any suggestions for how I might approach trying to implement a workaround for this bug (and the Firefox one below) in the script? --Xover (talk) 06:47, 7 September 2018 (UTC)


  1. The height of the text box is weird: the CSS spec punts on the definition, leaving it up to each browser to figure out, and each browser does it differently. The core issue is that a given bit of text can be in one or more fonts; each font has different inherent size; and "font size" can be measured in many different ways. Is the height measured from the top of the highest ascender (on the "h" say) to the lowest descender (on the "j")? Or from the baseline to the highest ascender? And there's the concept of "x-height", the size of the character "x", and an "em", the width of the character "m". This topic would make for a pretty beefy chapter, or even two, in a book on typography, and I've only barely scratched the surface.

Editing of sitewide CSS/JS is only possible for interface administrators from now[edit]

(Please help translate to your language)

Hi all,

as announced previously, permission handling for CSS/JS pages has changed: only members of the interface-admin (Interface administrators) group, and a few highly privileged global groups such as stewards, can edit CSS/JS pages that they do not own (that is, any page ending with .css or .js that is either in the MediaWiki: namespace or is another user's user subpage). This is done to improve the security of readers and editors of Wikimedia projects. More information is available at Creation of separate user group for editing sitewide CSS/JS. If you encounter any unexpected problems, please contact me or file a bug.

Tgr (talk) 12:39, 27 August 2018 (UTC) (via global message delivery)

Tech News: 2018-35[edit]

16:16, 27 August 2018 (UTC)

em-dash at page end[edit]

How do we deal with an em-dash at the end of a page, as on Page:Her Benny - Silas K Hocking.djvu/293? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 07:46, 28 August 2018 (UTC)

@Pigsonthewing: Reckon {{nop}} would work. Try transcluding this page and the next one in your sandbox and see how it looks. —Justin (koavf)TCM 08:05, 28 August 2018 (UTC)
I understand that we want the text to render one one line, as "foo—bar"; surely {{nop}} would break that onto two lines? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:04, 28 August 2018 (UTC)
It is a new paragraph on the next page, so NOP it and reproduce as set—separate paragraphs. — billinghurst sDrewth 11:33, 28 August 2018 (UTC)
Ah so it is, in that case. But were it not? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:19, 28 August 2018 (UTC)
This is one of the times that the software ought not to render a space but does so anyway. Some people use {{linkable phrase start}} and {{linkable phrase end}}, but I think it would be better to have the software recognize what's happening and render it correctly. --EncycloPetey (talk) 13:58, 28 August 2018 (UTC)
@Pigsonthewing: If there is an em-dash at page end and next line on next page is to be continuous, say A—B, then do this: on first page: {{hws|A—|A—B|hyph=}}; on next page: {{hwe|B|A—B}}. That would work. Hrishikes (talk) 17:04, 28 August 2018 (UTC)
OR just put A— in the footer, and on the next page put either <includeonly>A—</includeonly>B or use {{hwe}}, all just system tricks. We have the templates to help explain the process to newbies, though in terms of output, it is a more systematically complicated way, for experienced mediawiki users it is fine to use the tools available.

Page numbers + links in left-hand margin[edit]

On Her Benny and subsequent chapters, the left-hand side of the page incudes links to individual DjVu pages. If I transclude the pages into a sandbox, they are not shown. How can I force their display? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:43, 28 August 2018 (UTC)

@Pigsonthewing: Hm. Leave it up to you to come up with obscure cases... I think this is a function of Index:Her Benny - Silas K Hocking.djvu and where that points. If you change the title field from "[[Her Benny]]" to "[[User:Pigsonthewing/Sandbox]]" then it would include those floating page numbers that hi-lite the text. I don't think you can have it present on more than one page. Anyone correct me if I'm wrong here. —Justin (koavf)TCM 17:50, 28 August 2018 (UTC)
@Pigsonthewing: the javascript for page numbering is a main namespace feature. — billinghurst sDrewth 22:36, 28 August 2018 (UTC)
@Billinghurst: If it's JavaScript, could it be made available as a gadget, or even a user script? It would be immensely useful. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:21, 28 August 2018 (UTC)
The script is at MediaWiki:PageNumbers.js, so if you are wanting something for personal use, I would suggest copying and morphing that for your personal common.js settings. If someone adapted it to suit a particular page set in a user namespace, then we could possibly gadgetify it. We wouldn't adapt it for all user ns pages as the left hand sidebar aspects are not pertinent. Presumably no one has previously seen the need. — billinghurst sDrewth 01:25, 29 August 2018 (UTC)
Construct at Help:Proofread/Technical. — billinghurst sDrewth 01:29, 29 August 2018 (UTC)
@Billinghurst: Note that the WMF has fiddled with stuff so none of the source links work now (or the handful I tested anyway). For instance, {{MediaWiki SVN|ProofreadPage|proofread.js}} now leads (via redirects) to, but the proofread.js script actually lives at I'm not sure the linking template is fixable for the new source browsing system at the WMF so it may be better to just throw the raw links in there. I'd offer to do it but I don't feel confident in my ability to spot the correct links where things have moved around or been renamed. --Xover (talk) 06:35, 29 August 2018 (UTC)

To clarify: the use case is that, for a book like Her Benny, I can transclude the entire work at User:Pigsonthewing/Sandbox. I can then search (Ctrl+F) that for OCR artefacts like ^ for commas and '* for quote marks. But without the left-hand links, I cannot quickly find and edit the relevant page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:38, 29 August 2018 (UTC)

@Pigsonthewing: Those of us with basic skills to write regex use the m:TemplateScript javascript/gadget to do those replacements as we proofread. You will see a series of replacements in my common.js file. To note that if you use the gadget itself and its sidebar toggle, it has a regex save and reuse function. For instance, one of my regex scripts is /\[(http.[^ ]+)( external (scan|link|source))?\]/g to ([$1 external scan]) for use on author pages. These tools have been more productive than trying to morph a user ns page to have page numbering, to manually find and replace isolated characters. — billinghurst sDrewth 13:24, 29 August 2018 (UTC)
There are other fixes I'd want to make, using the same method - finding missing images; fixing the indentation of quoted poems, etc. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:52, 29 August 2018 (UTC)
if you use visual editor, you can find and replace, by page and cruise to next page. (i.e. [17]) don’t know if global find is an improvement. Slowking4SvG's revenge 13:56, 30 August 2018 (UTC)

Sorry to backtrack, but can the "javascript for page numbering is a main namespace feature" restriction be loosened some? It seems like it should also work in the Translation namespace. As it is, even the source isn't linked in the Translation namespace (usually the second tab), so it's a lot harder to find the scan backing the work. --Mukkakukaku (talk) 16:45, 3 September 2018 (UTC)

Are pages that "do not need to be proofread" transcluded now?[edit]

Hi to all! Recently I discovered, that pages for which the proofread status has been set as "This page does not need to be proofread.", seemingly are transcluded if they get into transclusion range set by expression <pages index="..." from= to= />. For example, this page: Domestic Encyclopædia (1802)/Potatoe: after page 434 (458 in the source file) — seemingly the next page is displayed (marked with sign [-] on the left side) though it has status "This page does not need to be proofread." As I remember from the past experience, some time ago such pages were not transcluded, they were simply ignored even if they got into transclusion range. And it looked reasonable because such pages, by the sense of this status, are not expected to have valid content which might be intended to be displayed. Why are such pages transcluded and displayed now? Is now the proofread software designed to work so? Or this is just a bug and will be fixed soon? --Nigmont (talk) 22:21, 29 August 2018 (UTC)

If a page is inlcuded in the <pages> it is transcluded. If it is an empty page then it will not display as it is empty and the page number will be hidden; if it has content, eg. an image or some other proofread text, then it will be display. — billinghurst sDrewth 12:56, 2 September 2018 (UTC)
The image (figure 1) is referenced in the article, why would you wish to exclude it? It would be proofread as normal, it simply lacks a page number. The page number is just our labelling, and has nothing to do with a page is transcluded or not — billinghurst sDrewth 12:59, 2 September 2018 (UTC)
Oh, I see the issue. The page numbering script excludes page numbers where they are squished out, and typically that is the first page that contains text or image, and the second is blank, here the blank page has the label, and the second has its label squished. In this case, simply use exclude= nnn to ignore the blank page and you will see that it will display fine. — billinghurst sDrewth 13:05, 2 September 2018 (UTC)

Errata listed in original document[edit]

Page:A Treatise of the Mechanical Powers - Motte - 1733.djvu/240 lists errata for the work of which that page is a part. I presume we do not correct the original text, but can we add footnotes or similar, so that the errors do not affect readers? Is there a guide, or an example, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:07, 2 September 2018 (UTC)

Correct that we don't emend it. We have used various means with regard to errata. DNB we have transcluded the errata to the bottom of the respective biographies. We have added links to errata, we have transcluded the errata into the notes field, often labelling the error with {{SIC}}. There is no exact right way. Examples, umm, digging them out from my edit pool is a challenge, often they are just part of doing the work. I would suggest a search for ERRATA in the main ns to see what you find. — billinghurst sDrewth 12:51, 2 September 2018 (UTC)
I did Highways and Byways in Sussex/Errata forever ago. — billinghurst sDrewth 12:52, 2 September 2018 (UTC)
for DNB there is a Template:DNB errata to transclude the errata section as a footer, i.e. Atkins,_William_(DNB00) see also Template:Errata -- Slowking4SvG's revenge 21:44, 2 September 2018 (UTC)

Word order jumbled[edit]

The print quality in Page:Bird Haunts and Nature Memories - Thomas Coward (Warne, 1922).pdf/21 and others from that work is better than others I've worked on, yet the OCR results have words out of order. Is there anything that can be done to remedy this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:17, 2 September 2018 (UTC)

@Pigsonthewing: Looks like a problem with the text layer in the source PDF (the text you see isn't usually OCR done on the fly; it comes from the original file, usually done at the time of scanning the paper book). If you use the "OCR" gadget in the toolbar (you may need to enable it first, I can't recall atm) you'll get much better results on that page. Not sure what backend it's using, but it redoes the OCR and replaces whatever text layer was in the original. --Xover (talk) 20:42, 2 September 2018 (UTC)
Yes, much better. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:02, 2 September 2018 (UTC)

Tech News: 2018-36[edit]

16:47, 3 September 2018 (UTC)[edit]

This page says that it needs proofreading. I did. Who do I send it to?? Lemme Noe!! Jim Graves e-mail addy:(snipped)

—Preceding unsigned comment added by (talk)

Please see Help:Beginner's guide to proofreading for information on proofreading pages. —Beleg Tâl (talk) 20:48, 3 September 2018 (UTC)
In short, click "edit" on the page, and make the corrections in situ, then click the "publish" button on the page. — billinghurst sDrewth 00:17, 4 September 2018 (UTC)


Has any one else noticed how trashy the page looks when the header is pushed down by the misleading status bar, any hat notes, and the snail trail [<title<subtitle] that repeats the information in the aforementioned header (repeated in the page it atops). The float overlays the page numbers, though I could switch them off I suppose, and it looks like a dingo's canine's breakfast. The italic AUTHOR and unitalic TITLE is also setting off the whole impression.

I have, for a number of years, but not prepared to say it is useless—beyond average—because it scares off people who might take the site seriously :-) Good night — CYGNIS INSIGNIS 14:24, 4 September 2018 (UTC)

@Cygnis insignis: No clue what you're talking about. Can you link to an example? —Justin (koavf)TCM 18:47, 4 September 2018 (UTC)
The {{header}} style dates back to about 2008 or 2009, and also contains our attempts at metadata, at which we probably still suck. I would presume that discussion was here (now within WS:Scriptorium/Archives) and at Template talk:header. The periphery components have had discussions afterwards. We tried the notes at the bottom, and that didn't work either as they were unseen. It should never be an issue to have a productive conversation about the components of the headers, and the layouts of the pages. Things evolve (front and back end; desktop and mobile), and there is occasional design creep, so sounds reasonable discuss components that are problematic. We can lack good skills in css in our populace, or maybe that is those willing and able in css. Also to note that with the new mw:Extension:TemplateStyles there is scope for us to pull elements out of the Template:Header and modules to separate/simplify components. I suppose that we want to break the conversation down to reasonable bite size pieces, as mega conversations often go unresolved here. — billinghurst sDrewth 22:11, 4 September 2018 (UTC)
Addendum, back then it would have been discussion about "header2", as it was then. — billinghurst sDrewth 22:17, 4 September 2018 (UTC)
@Koavf: An example can be found at Begin reading from the very top, left to right, and imagine you are seeing it for the first time. As you move down the page, note things like the header object overlapping the first page number (the link to the transcluded page). Would you like me to screenshot what is visible to everyone? Billinghurst wanted the author in italic and the title not italic, so that is characterised as a 'meta discussion' and therefore never to be fixed. CYGNIS INSIGNIS 02:37, 5 September 2018 (UTC)
Mate, stop picking fights, it advances nothing, and turns things difficult. I neither designed nor developed the header, anything that was chosen at the time would have been community consensus. — billinghurst sDrewth 11:42, 5 September 2018 (UTC)
no ur Is this the 'consensus' you recall: User_talk:Billinghurst/Archives/2009#bot_bug. Do I need to find where you obstructed the simple fix of the italic issue? Pull your head in, and don't call me 'mate'. —CYGNIS INSIGNIS 20:11, 5 September 2018 (UTC)
@Cygnis insignis: What you linked to went to Richard de Abyndon (DNB00) for me. I'm using Firefox and not seeing overlapping. Yes, if you need to screenshot, please do. —Justin (koavf)TCM 02:39, 5 September 2018 (UTC)
I too don't see any problem -- for me the random page picked was Speeches of Carl Schurz which does not have a source file, and thus no page numbers. But I also have set Layout 2 as my preferred default so I generally do not have a problem with things like overlapping page numbers. A screenshot would be helpful to show what you're having issues with, I think, so we're all at least on the same page. (I'm in Chrome, FWIW.) --Mukkakukaku (talk) 05:39, 5 September 2018 (UTC)
Header page overlap.png
Thank you both for the response, the statement was prompted by Essays on Political Economy, complaining about the header was easier than wading through that again. The capture at right shows the problem I have always seen on my platform (antique Mac, FF, default layout.) — CYGNIS INSIGNIS
I can confirm that overlap is still present in Firefox 62 on macOS 10.13.6 (latest release version). It's not present in ditto Chrome or Safari. It's probably just a too tight default margin or something that's fixable if someone digs a bit. --Xover (talk) 08:22, 6 September 2018 (UTC)
Oh, interesting. It actually looks like this might be another .offsetTop bug, along the lines of the Webkit one I've detailed in another thread, only in Firefox this time. In Chrome and Safari the <span> that marks the first page has a (correct) .offsetTop value of 0. In Firefox, though, its value is -11. When the PageNumbers.js script creates the page number links in the left margin, it uses the .offsetTop value reported by the browser for the page marker as the position for the page number. And with a -11 the page number ends up encroaching on the layout box for the header. Since I can't tell what triggers it I don't see how we could make enough of a test case to be able to report this to Mozilla and have any chance of getting it fixed. But it's possible we could work around it in PageNumbers.js by simply ignoring negative .offsetTop values: for our use case these will always be incorrect. --Xover (talk) 15:54, 6 September 2018 (UTC)

I'm unsure of some of what Cygnis insignis is referring to, but I too have long thought that we have become blind to the awfulness of our layout, and need to see it with fresh eyes. Consider The Collected Works of Dugald Stewart/Volume 1/Part 1/Chapter 1:

Firstly, no self-respecting website should be entitling its pages with slashes like this. Sure, that's our subpage structure, and sure, we editors need to know about it. But it just looks weird and stupid to our readers.

Secondly, follow Cygnis's advice and read it sequentially from the header, with fresh eyes. You get:

  • The Collected Works of Dugald Stewart/Volume 1/Part 1/Chapter 1
  • < The Collected Works of Dugald Stewart‎ | Volume 1
  • The Collected Works of Dugald Stewart (Volume 1) by Dugald Stewart
  • Part 1: Chapter 1

That's an awful lot of pointless repetition.

Hesperian 07:46, 5 September 2018 (UTC)

templates do not work well in small screens / mobile. we could use a refresh. but that would require some coding, and consensus building for a redesign. Slowking4SvG's revenge 12:24, 5 September 2018 (UTC)
  1. Example one is a mediawiki construct, what are you suggesting instead? What other configurations are available through mediawiki, and how else would you wish to work the issues around subpages and their linking?
  2. Example 2, is similarly a mediawiki construct, though it seems to be able to be controlled by class="firstHeading". It is an interesting breadcrumb, and only appears when we have subpages. I have no idea of its malleability otherwise. It does allow quick flicking to layers of works, or to a rootpage of a work. It also only appears when the subpage layer is created. Not visible at Koafv's example. If you are in a journal, or newspaper, like The Times/1937/Obituary/Mr. Alan Butterworth it gives the root, it gives the year, and omits the non-existent obituary. Those active sublinks can be useful for navigation in certain circumstances. Also in my last example, there is less other repetition, and the subpage structure allows an automated collation at 1937, though it is still the ugly output, we haven't yet managed to get {{SUBPAGENAME}} display.
  3. Example three display is choice of the contributor, and I would have said less typical, as usually it is simple a manufactured hyperlink to the rootpage. There is clear variation in user generated output
  4. Example four display is also a choice of the contributor
What would your preference be? Which of those are you suggesting that we remove? What is the equivalent mobile output like? — billinghurst sDrewth 12:29, 5 September 2018 (UTC)
These are all excellent questions, and the reason I've not raised these issues before now is I've had no answers/solutions to offer. Hesperian 07:44, 6 September 2018 (UTC)
If we set $wgRestrictDisplayTitle to false, we can use the magic word {{DISPLAYTITLE: …}} to set the page title ("Example one", I think) to something else. Whether that's wise or would even be an improvement, and what to set it to, I'll leave for wiser minds than mine to figure out. My immediate opinion is that the bits that matter are in the hands of the WMF developers (i.e. outside the hands of the community), and the rest isn't in any immediate need of changing. I might have picked a different background colour for {{header}} myself, but that's about it. --Xover (talk) 17:34, 5 September 2018 (UTC)
as we see with mw:Winter or mw:Skin:Timeless, it is a herculean task to upgrade the look and feel of the reading experience. maybe we need to add it to wishlist, or recruit an Isarra to push the consensus. (they did listen to us a little) Slowking4SvG's revenge 23:54, 5 September 2018 (UTC)
It is my memory, (and it could be flawed as it was a long time ago) that there was lots of discussions and trials of background colours, and in among earlier colour palettes of skins. We did what we could with the skills to hand, and the css/css2 restrictions of the browsers at the times, and prior to much in mobile. GOIII did lots of work in the area, though generally his edits are ever-present though undocumented in edit summaries. I am sure that things can do things better, and it will be the balance between doable, reliable, extensible and consensual. I can see that WSes may be able to get it into the annual FIXME cycle if we get enough votes, or can clearly demonstrate value. — billinghurst sDrewth 07:30, 6 September 2018 (UTC)
or we can just get rid of the title of the page we're talking about altogether. All the information should be in the header anyway and if an editor needs to know where they're at they can just look at their browsers address bar.Jpez (talk) 04:20, 6 September 2018 (UTC)
That is also a rationale for disposing of the header and keeping the title page, replacing the title page is what happened in the days before scans made text integrity verifiable. It was invented to rebadge Gutenberg texts and throw away front matter that someone decided we don't need to see, and shape any text as a meta version of a work, novel, poem, essay, at least I assume so as that is why I never bothered reading texts here. — CYGNIS INSIGNIS 08:18, 6 September 2018 (UTC)
If you don't like the header, you can use Layout 3 -- though sadly these layouts seems to only work for transcluded works. The header contains useful information, though; how are you supposed to navigate a multi-chapter work without it? Go back to the front matter, scroll to the TOC or index, figure out where you were and click the subsequent link? Now that seems like extraneous work. --Mukkakukaku (talk) 03:16, 8 September 2018 (UTC)
@Mukkakukaku: What I like is solutions. I do not favour the layout options as a solution to anything but an imagined problem, and the header is a historical legacy that no amount of tweaks and workarounds will fix. I have a solution, but proposing may be futile; it is certain to be resisted because other users already have a substantial investment in the header's problems. — CYGNIS INSIGNIS 02:36, 10 September 2018 (UTC)
Well, sure, solutions are good. But I have yet to understand what the actual problem is. I mean, Hesperian did a good job explaining the redundancy concern with the page title/hierarchical display (that shows when you have subpages) -- and I agree that it's redundant and needs to be addressed. But I have no idea what the problem is with the rest of the header. Frankly, in my experience it solves more problems than it creates: it provides a standardized format to display the current work's title, author, year of publication, section title, contributor title, etc., plus navigational options for "next" and "previous" chapters. I don't have a lot invested in the design, but I do have a lot invested in the functionality, and little interest in fixing what ain't broke, as they say. (And as I mentioned, I haven't heard what's broke about it yet.) That being said, this discussion has become somewhat nonlinear, which is a pity. Feel free to ignore this tangent. --Mukkakukaku (talk) 02:55, 10 September 2018 (UTC)
Haha. "Well", I'm taken aback when people start their sentences that way, but Reagan was a great public speaker :) I'm not good at describing problems, but here goes: The header, as I describe above, was created to replace title pages and provide navigation; this distinguished a text from other hosting sites. Creating these 'points of difference' is a legacy of when wikisource was trying to justify its existence. The solution is to dispose of the faux title display on which the header is based, and replace it with a box of labelled data and links, left aligned, using bibliographic styles. This could do what the header is supposed to do, the items you mentioned, and much more besides. The headers only solves the 'problem' of forcing constraints on how data is displayed, not how it can be more useful. A basic application of a data box is output, like a citation for the page being viewed, or for WD bots to extract metadata from works or their subpages. I contend that people have been unknowingly viewing this the wrong way round, value is found in the text and its metadata, not in controlling its display. The situation is similar to the assemblage of sister link boxes, some newer users streamlined and improved them and it was incorporated into the header; the header object could never effectively work for open access to data when it is designed to work against that principle. — CYGNIS INSIGNIS 05:13, 10 September 2018 (UTC)

Read-only mode for up to an hour on 12 September and 10 October[edit]

13:33, 6 September 2018 (UTC)

page style looks terrible on page[edit]

I am obeying some style page suggestions I was spanked for not using, and it looks over-done and with distracting bling.

Glorious Roll of the American Drum

Is there a way to fix this in which I will not be harrased? --RaboKarbakian (talk) 15:33, 7 September 2018 (UTC)

Probably not with that attitude, no. And if you want help with something you'll have to explain in more detail what you perceive to be the problem. --Xover (talk) 16:13, 7 September 2018 (UTC)
I am sorry for the attitude, well, more like slang. "Bling" is fancy things which have no purpose, in this case, the hover highlighting of the text of the page. It is a useful thing (and not bling) when found on a document which contains more than one page.
The word spank is being used inappropriately here, but it was a shorthand that I was using to remind myself "be careful as you are editing in a public space and have had experiences in which seemed jarring or shaken out of a pleasant workflow". My nice looking documents were changed from the second transclusion method described at wikimedia into these lovely looking page highlighted somewhat more natural language hashed templates that are too much for the single item document I just made.
I came here because I would like to go back to the "non-deprecated" method I was using before only this time, without the changes and without reprecussions for using it. (There was an ongoing discussion of the use of the word deprecated also, as from a software point of view, the "deprecated thing" was server side includes.)
I don't care about the language I use here. It's all wrong. Sorry?--RaboKarbakian (talk) 17:47, 7 September 2018 (UTC)
The highlighting when you hover your mouse cursor over the page number in the margin is something all works on Wikisource get. However, if you dislike it you can disable it using the "Page links displayed" link under the "Display options" in the sidebar. In the sense you're intending here, there is only one way to transclude works from the Page: namespace to a main namespace page (there are some variations surrounding use of sub-pages for chapters and such). The syntactical variants you've found are mere technical artefacts: think of them as bugs, in software development terms.
You might also want to take a moment to look into what the purpose of Wikisource is. We reproduce the original work faithfully (within reason, and there are unsettled gray areas), rather than make new editions. If your aims are different from Wikisource's aims, then you are bound to be endlessly frustrated here.
Finally, for any given method or bit of "bling", you may safely assume that it is the way it is based on the consensus of the community here that that is how it should be. Some things are certainly better debated than others, but if it is a certain way there's a good chance it's because it has at least de facto consensus. All such consensus is subject to change (within technical and legal limits), of course, but that requires good arguments that change is needed and persuading a majority of the community that your alternative is better. On the way to transclude works I don't like your chances; on other issues you might have better luck.
Of course, that would probably necessitate taking some care with the language you use… --Xover (talk) 18:23, 7 September 2018 (UTC)
Maybe it's just my browser glitching, but I don't see neither a page number, nor a "page links displayed" option under the 'display options' sidebar section. Or maybe it's because the last edit to this work swapped out the pages tag for a ... I have no idea what that is being used to transclude but it's weird.
What is kind of distracting is the wikidata authority control footer at the bottom of this work. I've never actually seen one of those outside of the Author namespace. That and the weird "follows and followed by at wikidata" note in the notes field are the only blatantly out-of-place things I can see with the work. I mean, I guess the redlinked "Unknown" contributor instead of using an override parameter, too, but that's a minor tweak to fix. --Mukkakukaku (talk) 03:13, 8 September 2018 (UTC)
And there you go!! a recent diff I put the note that the follows and followed by can be accessed at wikidata. I thought it might be a good experience in making templates for me or someone else.
Extremely brief discussion, apparently with the "concensus" about it, but the consensus has a user name.--RaboKarbakian (talk) 09:57, 8 September 2018 (UTC)
Every consensus has a user name attached to it, or it wouldn't be part of a consensus, now would it? We don't include those kinds of "educational notes" on the pages of works. Procedural notes ought to be in the Help: namespace or a Talk: page, not in the work itself. And let's be frank here: You're not following community norms, and when you get called on it, you deliberately ignore what you're told, and then go do your own thing anyway. So don't try to play the "poor little me" act when you've set yourself up for this by ignoring most of the advice you've been given and flouting established style at every turn. If you're going to refuse to follow convention, then at least be honest about what you're doing. --EncycloPetey (talk) 15:48, 8 September 2018 (UTC)
@RaboKarbakian: I made this diff to give you another spanking. If you ever use multicol for that situation, the printer saving paper, your buttock will be toasting crumpets for the senior boys. CYGNIS INSIGNIS 02:45, 12 September 2018 (UTC)
<html5> is great. Pasting <br /> after everything is not so great. <poem> is real handy, especially when I know what crap html {{dhr}} is probably making.--RaboKarbakian (talk) 02:55, 12 September 2018 (UTC)
@Cygnis insignis: You didn't need to revert this. <poem> doesn't play well with the block templates /s /e. I have been using <br /> there. It is more choicey of the two formats.--RaboKarbakian (talk) 12:55, 12 September 2018 (UTC)
Pasting it! what a good idea, I had been typing it out each time ;) I'm not aware of a problem with the start and end templates, has someone been recoding it? — CYGNIS INSIGNIS 13:40, 12 September 2018 (UTC)

Do you have small tasks for new contributors? It's Google Code-in time again[edit]

Hi everybody! Google Code-in (GCI) will soon take place again - a seven week long contest for 13-17 year old students to contribute to free software projects. Tasks should take an experienced contributed about two-three hours and can be of the categories Code, Documentation/Training, Outreach/Research, Quality Assurance, and User Interface/Design. Do you have an idea for a task and could you imagine mentoring that task? For example, do you have something on mind that needs documentation, research, some gadget or template issues on your "To do" list but you never had the time, and can imagine enjoying mentoring such a task to help a new contributor? If yes, please check out mw:Google Code-in/2018 and become a mentor! Thanks in advance! --AKlapper (WMF) (talk) 13:51, 9 September 2018 (UTC)

Would fixing the edit page tool bars be a suitable task? There are things that are there that shouldn’t be and things that should be that aren’t e.g. the maths characters are up the wop and ff isn’t on the ligatures and the User choice is at the bottom of the pull-down list, it would be best at the top. Zoeannl (talk) 23:56, 16 September 2018 (UTC)

Aux TOS now full-width?[edit]

Did we at some point recently discuss having the auxiliary TOC templates now be full-width? Can someone point me at that? Because all of the aviation accident reports I've been working on, which rely on these auxiliary TOC templates to link attachments (since they have no formal tables of contents) now have this garish full-width green green box, with the content floating sadly in the middle at the specified width.

Cf: Aviation Accident Report: American Airlines Flight 320

I'd really rather not have to go back and swap out templates on all the completed reports. --Mukkakukaku (talk) 03:57, 10 September 2018 (UTC)

@Mukkakukaku: The change was made by Esponenziale in this edit on 7 September. The preceding discussion was here (the thread above it from 2016 is also relevant: pinging Hesperian). Because this change was insufficiently discussed, affects a large number of works, and has been objected to here, I have reverted it for now. In my opinion such changes should be discussed (pro—con, details, needed remedial action, etc.) thoroughly here first, and sit a reasonably long while up in #Proposals to make sure everyone has a chance to see it and raise concerns before it is implemented. Other than that I currently have no opinion on this change (but the discussion here might induce me to develop one). --Xover (talk) 04:42, 10 September 2018 (UTC)
@Mukkakukaku, @Xover: I've better detailed my reasons in Template_talk:Auxiliary_Table_of_Contents#Responsive_design, I'd rather move any further discussion there if you like —Esponenziale (talk) 14:08, 10 September 2018 (UTC)
@Esponenziale: This affects a lot of works across the project and not very many editors watch the template's talk page. I think it's best to keep the discussion here. That being said, I don't think it's a good tradeoff to make changes to the formatting that impacts the website (which is the primary interface) to benefit one of the possible export formats (ePub). Particularly as CSS is explicitly designed to allow different styling of the same content for different media (webpage + book was one of the combinations specifically designed for). Thus, any change whose goal is to affect the ePub needs to start with the requirement not to affect the master web version. The web version can, of course, also be changed iff it benefits the web version. And if a change is good for both, then so much the better. But that needs to be thoroughly discussed beforehand; and that starts with clearly articulating the problem and a proposed solution that takes into account the different interests. --Xover (talk) 14:54, 10 September 2018 (UTC)
A part for design responsiveness, which was the real objective of my edit, the appearance was only slighted modified (green background enlarged to full width also when viewport is large) mainly because it allowed to simplify the template (see explanation at Template_talk:Auxiliary_Table_of_Contents#Responsive_design), but also because the other green boxes used for navigation between subpages are 100% large, and in my opinion they're better off all equally large.
To sum up, I think this tweak to appearance was good for ePub, web and template code. But it was't of much relevance, if @Mukkakukaku: doesn't like it, I'll find a solution (suboptimal, at least to me) in order to satisfy his preference. —Esponenziale (talk) 23:24, 10 September 2018 (UTC)
The issue isn't whether Mukkakukaku likes it or not (and it's a bit unfair of you to cast the issue that way). The issue is that this change, whether good or bad, affects a very large number of works across the whole project, and so it should be discussed before implemented. Try changing the page background to pink on all 5 million articles on English Wikipedia without gaining a solid consensus first, and see what the response of the c. 30k active monthly editors there will be (well, actually, you can't do that because enwp has added protection on all the relevant bits for this very reason). Wikisource is a much smaller project, but the same principle applies. It's actually even worse here, in some ways, because the specific visual display of a work is a much bigger factor here than at the Wikipedias.
And in light of the bigger issues flagged below, it seems that discussion properly belongs as part of a larger discussion of how we deal with the needs of the mobile frontend. --Xover (talk) 08:05, 11 September 2018 (UTC)
@Esponenziale:, the fact that you thought this edit was better is not sufficient reason to impose your opinion on everyone. I do not agree with the reasons you have given and do not support the change. Making a ToC template look more like a Header template is more likely to confuse readers than assist them. --EncycloPetey (talk) 14:02, 11 September 2018 (UTC)
Yet another thing jostling with the header, easily merged to a template with labelled display of data. I am looking for a seconder for a proposal to replace the header template, so talking it up at every opportunity. CYGNIS INSIGNIS 17:47, 11 September 2018 (UTC)
An Auxiliary ToC has nothing to do with the Header and shouldn't do. If you thought I said otherwise, you misunderstood what I was saying. --EncycloPetey (talk) 00:29, 12 September 2018 (UTC)
Oh, hi :| It was not intended as a reply to your comment on our central discussion page, it is about sowing a seed of change; I tried to make it clear that I was shamelessly using the example of that ToC to demonstrate the merit of my proposal to dispose of the header. I believe I understood what you were saying, agreeing that it is a confusing fix, and already assume you are firmly opposed to any solution I might present. — CYGNIS INSIGNIS 02:00, 12 September 2018 (UTC)
@EncycloPetey, @Xover: I see that there's no consensus about the change to full width. What about responsiveness?
P.S.: I'm quite surprised by your reactions, I've made this edit without bothering anybody here (I wrote in advance only on the template talk page) because in my opinion, as I've already pointed out, the change in appearance was minor and didn't necessarily need discussion. I've no problem in discussing it now and I've no problem if someone find it more relevant than I do. But there's really no need to waste time explaining why I can't be the dictator of Wikisource...—Esponenziale (talk) 09:54, 12 September 2018 (UTC)
@Esponenziale: Ah, I see now from whence the confusion stems. No, the visual layout change was not a minor one. I'm also quite surprised you could conclude it was: are you certain you've not let yourself be misled by, say, only looking at the ePub output (or mobile or…) rather than how it's actually used in different works on the desktop website? I'll repeat that I'm not particularly a fan of the status quo, but even a cursory inspection suggests to me that making it full-width would be a dramatic change for which consensus must be sought first.
Whether or not to make it responsive is an orthogonal issue: responsive design is a fine and laudable general principle, but the devil is in the details. What are the downsides and tradeoffs? What is the implementation cost? What, specifically, will it gain us for this particular interface element? And in any case, that process starts by making it responsive while preserving its current visual appearance.
Personally I think its biggest problems are its relative paucity of functionality (e.g. I would prefer to float it to the side, and perhaps some more automated linking for convenience) and a certain distaste for its visual design (but it matches the house style, so that's not this template's fault). Making it responsive is waaay down on my list of priorities. --Xover (talk) 11:13, 12 September 2018 (UTC)
Appearance can be left unchanged on big viewport, but some very slight differences in appearance allow to obtain some minor benefits. Would the following rendering be ok with you? –Esponenziale (talk) 13:39, 12 September 2018 (UTC)
Chapters(not individually listed)
  1. Chapter I
  2. Chapter II
  3. Chapter III
What are you asking with regard to? In asking approval for "the following", do you mean as new code for the template? Do you mean as an alternative non-template use? You'll have to spell out what it is you are asking, so that people here can judge the proposal. --EncycloPetey (talk) 13:55, 12 September 2018 (UTC)
We were discussing a change to the template to make it responsive, without enlarging it to full width. That is the output of the template once modified. –Esponenziale (talk) 14:40, 12 September 2018 (UTC)
The template intentionally takes a width parameter. I'm not sure what you're doing there, setting width to 100% and then max-width to 400px. ;)
That being said, swapping out the table-based layout for a div-based layout is a fine improvement, since tables are slow to render anyway and this particular thing doesn't have any tabular data. Using style margin:0 auto; padding:0 6px; width:400px seems more appropriate. (The current version of the template uses 400px as the fallback width.) You can also use a flex layout to get the '(not individually listed)' positioned properly like so:

Chapters(not individually listed)

  1. Chapter I
  2. Chapter II
  3. Chapter III
It could help if it was made clear what is meant by "responsive" because my understanding of the word was that it is displayed appropriately in all size formats including mobile, tablet, and desktop -- which as far as I knew this version already did. The optimal solution would be for it to be treated more like a full-width secondary header in the mobile view since that matches most mobile design paradigms, but the only way I know of doing this involves CSS media queries which are (as far as I know) not supported in templates. --Mukkakukaku (talk) 00:47, 13 September 2018 (UTC)
Your understanding of the word responsive is correct. And if the width is defined as you did, then the layout isn't responsive: when the viewport width is smaller than div, it is either scaled or only partially displayed (see screenshot here). Setting the width to 100% and max-width to 400px (or, equivalently, setting the width to 400px and max-width to 100%) solves this problem without the need for media queries.
I'm not very accustomed with flexbox. In my opinion it would represent a small complication because it should fallback nicely (it's currently not supported by 5% of browsers and probabily far more e-readers). Note also that your current implementation lacks any padding between the two texts (they touch together when the width is small or they're long).–Esponenziale (talk) 09:26, 13 September 2018 (UTC)
Re: flexbox -- The wikimedia folks seem to only care about supporting the latest release of each browser. It degrades into what your version looks like anyway, so it doesn't matter in the long run. I don't know what you mean by "padding between two texts", either. Paragraph tags have native bottom margin as part of the browser default styling, which is what I leveraged. You can always put a margin-bottom:6px or whatever on the paragraph tag. If that's not what you mean, then I have no idea what you're talking about. Slap a max-width:100% on the parent container if you don't want it to overflow its parent, I guess. --Mukkakukaku (talk) 00:22, 14 September 2018 (UTC)
Done: I've updated the template just now, using flexbox to keep the comment on the right corner, as you suggested. Top and bottom paddings and margins are not defined in order to be inherited from the subheadertemplate class. Padding between title and comment (the two texts I was mentioning before) is guaranteed by imposing a min-width of 1em on the span between the two. –Esponenziale (talk) 14:20, 14 September 2018 (UTC)
@Mukkakukaku: in Aviation_Accident_Report:_American_Airlines_Flight_320 the template has 100% width because you defined the width as 250px instead of 250 (without px) as the documentation requires. –Esponenziale (talk) 14:26, 14 September 2018 (UTC)
We had been trying to not embed units in any of our applied widths. I would think that we may be better to look to update the template so that it is unitless. There are about 900 uses, we could bot replace those with px where we have applied a custom width. — billinghurst sDrewth 15:21, 14 September 2018 (UTC)
Ok I see now that the previous actual implementation of the template was unitless since 2015, but the documentation wasn't up to date and was saying that the unit of measure shouldn't be entered. Today I updated the template in compliance with the latter. Now I've just made the template unitless, as you asked, and I've updated the documentation to reflect that. –Esponenziale (talk) 21:30, 14 September 2018 (UTC)
Now I'm confused since that particular page clearly sets width=250px (with unit) on the Aux TOC template, and it looks correct (since the initial change was reverted in the template itself). Prior to the template revert it was a 100% wide green rectangle, with the actual TOC content (the links) at 250px floated in the center. Either way, I officially have no idea what we're talking about anymore. :) Either of those two last proposed templates is fine in my opinion (the one I proposed or the one Esponenziale proposed). They both seem to accomplish the desired affect -- the box is green, limited to the size of the content/requested width, doesn't grow scrollbars at smaller resolutions, and is not based on the HTML table tags. --Mukkakukaku (talk) 23:26, 14 September 2018 (UTC)
Oh. I see. Yes, when things don't work as the documentation says, I go and make them work anyway which is why I used the units when declaring the width because that's what made it work. Less confused now. I've been using this template like this forever and didn't realize the documentation had gotten out of sync. But still. We should be ok now, yes? --Mukkakukaku (talk) 23:28, 14 September 2018 (UTC)
Yes! –Esponenziale (talk) 09:32, 15 September 2018 (UTC)

Tech News: 2018-37[edit]

22:35, 10 September 2018 (UTC)


The above discussion at mediawiki that relates to mobile configuration seems particularly problematic and antithetical to production of a literary work, and to how we have structured our pages. It would seem that we need to be involved with the conversation, and it highlights how we do produce components and probably need guidance from the Reading team about what we are doing. — billinghurst sDrewth 04:17, 11 September 2018 (UTC)

I don't see how it affects producing transcripts, only where the 'page structure' (and layout) is non-compliant. Which components need attention? — CYGNIS INSIGNIS 08:05, 11 September 2018 (UTC)
Well it's because these days we don't produce transcripts (eg. just the content). We try to preserve the work in its entirety, including the original print layout as best we can.
Most of our layouts are non-compliant, really. Any place where people set an explicit width in pixels -- for example, on an image. Anything that relies on hovering -- the {{SIC}} and {{redact}} templates come to mind -- aren't compliant. Heck, the argument I accidentally started a few sections ago about the auxiliary tables of contents is about a non-compliant template.
There's just not enough horizontal real-estate on a mobile device to support our layouts because we attempt to mimic and preserve the printed page. Sidenotes? no room for that -- but what can we do as an alternative?
It almost seems like we'll want to have our templates and layouts degrade gracefully into something that looks more like what Gutenberg produces (just puking the content onto the screen; come back to desktop to see the work as it was intended to be consumed.) --Mukkakukaku (talk) 01:06, 13 September 2018 (UTC)
What are the problems with SIC and redact? [So much to have to know that takes away from transcribing] — billinghurst sDrewth 01:57, 13 September 2018 (UTC)

The list from that cited page

  1. Use common class language for components in templates across projects
  2. Don't put infoboxes or images at the top of the wikitext
  3. Meta data (including coordinates) should be positioned at the bottom of the article
  4. Use consistent ordering for hatnotes and ambox templates
  5. Inline styles should not use properties that impact sizing and positioning
  6. Avoid tables for anything except data
  7. Make sure your main page is mobile friendly
  8. Templates should use a single root element with a sensible CSS class
  9. Collapse issues with a multiple issues template
  10. Do not assume positions of images, infoboxes, tables in text

and some thoughts.

We try to do 1) though we don't do it effectively. Header templates is an example of 2), and some of the other aspects of featured works similarly sit there per 3). We use inline styling a lot to replicate the work per 5). We do large amounts in tables, often to replicate a work, though also with {{block center}} as other means has failed us per 6). We don't container multiple issues per 9).

Probably other components in the others. I am time-poor and not suitably knowledgeable to be authoritative. I started a topic on the respective talk page, and am endeavouring to add to it, though not the quality time to be lucid and extrapolative. — billinghurst sDrewth 01:54, 13 September 2018 (UTC)

Re: SIC and redact -- They rely on hover to indicate content. How does one hover with a touch screen? The SIC template moreso in this regard because the corrected spelling is indicated in hover, whilst the redact template uses the hover to indicate why the data was redacted as a result of a FOIA request. The redact template's other issue is that it uses a specified fixed width, usually determined by the proofreader to be somehow related to the redacted content length in the original text. This would be number 5 in the above list.
I'm actually extremely surprised they didn't mention hover explicitly since that's one of the first things that have been brought up as an issue I've had to deal with when adapting desktop-first websites to mobile/tablet. But perhaps in a Wikipedia-centric world that's a much less used paradigm.
As someone who actually does occasionally read works on their phone, I actually find the header's consistency rather useful in the mobile view -- I'll know I can find the title, author, year of publication, portal/wikidata/wikipedia links all in the same consistent place. Moving them to the bottom where they suggest moving the "metadata" would actually be really really unhelpful in my opinion.
Also we have a lot of tables. The older experimental TOC templates do not degrade gracefully for the mobile view. Even things that should never have had tables for layout -- like {{Auxiliary Table of Contents}} in the argument above -- has a table based layout which it simply doesn't need. --Mukkakukaku (talk) 02:25, 13 September 2018 (UTC)
From memory it harks back to the issue that we had with centre blocking (see Template talk:Block center) where it didn't work unless it was a table, and was why {{block center}} was a table (and I hadn't noticed that it had stopped being so.) So the issue is that we haven't kept up well with the progression of html/css and retirement of browsers. I would think that {{AuxTOC}} needs that same treatment as "block center", and if we could even better apply template styles to each of them, that may be better again. — billinghurst sDrewth 04:42, 13 September 2018 (UTC)
  • Pictogram voting comment.svg Comment Looks like we need a formatting and template repair and review space, so where we identify old/recalcitrant formatting, and its use in templates, that we can methodically fix things in an informed way. It might also serve as a place where we can report forthcoming known coding issues and then hunt for those problems on our site. If we did, we could do and fix somewhere within Wikisource:Maintenance of the Month (which should also be renamed Wikisource:Maintenance). — billinghurst sDrewth 05:01, 13 September 2018 (UTC)
(edit conflict) Right. Tables for layouts was something that kind of went out with IE6 and the browsers wars. (And even over at phabricator they make a point of not supporting anything older than the current release of a given browser.) These days the preferred method to do a centering would be to use a div or other block-level element with a style of margin:0 auto;. But truthfully even that is problematic from a mobile design standpoint. In order for something to be centered, you need to have a width that is less than the maximum; in mobile you're severely limited in horizontal real-estate anyway, so there's nearly never a reason to use the 'center block' concept because you're artificially forcing a user to scroll by squishing content into a fraction of an already limited area. (The centered text concept is different; alignment is still relevant.)
What we might want to consider is using CSS media queries to have our styling specific target different widths of screen. That way we could specify how a view looks at mobile (or other extra-small interfaces), versus tablets (small), small computer screens (eg. 1024x768; medium), then desktop (larger). The problem is that -- to my knowledge -- you can do media queries at the element level and instead have to declare them at the global level. (As an example, look at this website and shrink your browser window. There's a lot more examples like this in the modern web.)
That would involve a consistent effort across-the-board to figure out what the user experience in mobile (vs tablet vs desktop) should be so as to get the global styles in places. But then templates could just inherit those base styles (via classes) and then adjust using as needed based on the needs of the template itself.
As far as I can tell, this push to be more mobile friendly didn't come with any software based tools to make this easier to do. Just watch they'll ask us to be more screen reader friendly next. Mukkakukaku (talk) 05:05, 13 September 2018 (UTC)
I wonder whether we should be seeking a grant for a project to get someone to investigate the css needs of the WSes, and fix the framework. — billinghurst sDrewth 21:45, 13 September 2018 (UTC)
And maybe it is ultimately, for mobile devices do we really want to throw in the formatting that the book had? Is this a case of KISS? — billinghurst sDrewth 21:52, 13 September 2018 (UTC)
I think we're going to find that we can't reproduce the book layout faithfully due to the limitations of the medium. There just isn't enough horizontal room on the phone screen to render, say, two side notes plus content. Or a larger detailed image (eg. a map from an aviation accident report). We might need to consider making it policy that in mobile you'll get the content, but if you want to experience the work in the way the publisher intended originally you'll need to switch to a larger format. But that would be a decision that we'd have to make as a community. --Mukkakukaku (talk) 00:26, 14 September 2018 (UTC)
  • Question Question Would it possibly be useful to create a WikiProject to direct an effort to systematically update our templates and other pages to make them more mobile friendly? --Mukkakukaku (talk) 23:37, 14 September 2018 (UTC)

Main page[edit]

There is guidance for main page design that we should read at mw:Mobile Gateway/Mobile homepage formattingbillinghurst sDrewth 04:26, 11 September 2018 (UTC)

Living authors category[edit]

It seems that authors with the date of the death missing in Wikidata are categorized as "living authors" in Wikisource. As a result authors whose date of death is unknown, such as Author:Chval Dubánek, are categorized as "living" as well. Can it be fixed in some way, please? --Jan Kameníček (talk) 18:51, 11 September 2018 (UTC)

The problem is probably in the module:Author, particularly in the lines:
if type == 'death' and isHuman then
-- If no statements about death, assume to be alive.
addCategory( 'Living authors' )
It really looks weird if we assume that people working centuries or even millenia ago (such as Author:Zeuxippus are still living. For this reason I suggest that people over 90 should not be categorized based just on the fact that Wikidata do not have any record of their death. However, they might be categorized here manually. --Jan Kameníček (talk) 20:20, 12 September 2018 (UTC)
Less of us play in the module: ns for fear of breaking things. I would suggest leaving a note on Template talk:Author and applying a ping for "Samwilson". — billinghurst sDrewth 01:08, 13 September 2018 (UTC)
Yes check.svg handled at template talk:Authorbillinghurst sDrewth 21:53, 13 September 2018 (UTC)

Constitution of Angola[edit]

The page named Constitution of Angola (1975) actually contains the 1992 version of the constitution. Since this is my first time editing WikiSource, I could use some help or advice on this. Is it fine for me to rename the page to "Constitution of Angola (1992)"? Here are the relevant sources I'm aware of. Krubo (talk) 04:06, 12 September 2018 (UTC)

Yes check.svg Done Thanks for pointing that out. — billinghurst sDrewth 04:36, 12 September 2018 (UTC)
Thanks! Krubo (talk) 17:23, 12 September 2018 (UTC)

Table of images[edit]

What's the best template for the list of images on Page:Bird Haunts and Nature Memories - Thomas Coward (Warne, 1922).pdf/15, where the photographer credits are right aligned in the column before the page number? I've tried {{Dotted TOC line}}, with |dotend=, but that didn't do what I'd hoped (its documentation is less than clear). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:07, 15 September 2018 (UTC)

{{TOC row 1-1-1}} might do it. Those templates are kind of finicky though, though there's a decent amount of choice if that one doesn't work. --Mukkakukaku (talk) 22:10, 15 September 2018 (UTC)
Or possibly {{TOC row 2-1-1}}. That one seems more likely to be what you need. If all else fails you can just do a regular table. --Mukkakukaku (talk) 22:12, 15 September 2018 (UTC)
Thank you. I found that {{dotted TOC page listing}} gave the closest approximation to the source. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:53, 15 September 2018 (UTC)

My first index[edit]

I'm abut to transcribe my first book index, starting at Page:Bird Haunts and Nature Memories - Thomas Coward (Warne, 1922).pdf/273. Does anyone have any tips, good examples or recommended templates, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:16, 15 September 2018 (UTC)

I generally proof them like extended tables of contents. (I also don't preserve the two-column layout unless there is a good reason for it.) Page numbers can be linked using {{DJVU page link}} if you think it's worthwhile, otherwise they're transcribed as-is. If you run into any ditto marks, there's a template for that.
I like to link topics as close to where they are in the work as is possible. If there's a proper section heading with an anchor, they can be linked to that, otherwise just to the chapter. (Thus it's sometimes useful to have already figure out the TOC/how the work will be organized in the main namespace.)
It's really just like proofreading/transcribing a set of highly ordered pages (eg. standardized layout.) It can get tedious. For complex indices I sometimes copy the content into a text editor which supports useful things like regex find/replace, column editing, etc. --Mukkakukaku (talk) 01:53, 16 September 2018 (UTC)
Thank you. Is there a template that will make each line in the source code appear as a new line in the rendered result, as <poem> does, rather than putting <br> at the end of each line? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:18, 16 September 2018 (UTC)
  • Pictogram voting comment.svg Comment Index pages are always a little 'urk', and there is no one way to do them, as it depends on how they are indexed. Please don't retain columns as they don't stitch together well. Add {{anchor}}s at each section and when transcluding put {{compactTOCalpha}} into the notes. Generally with spacing I have just put one empty line between each line, and two empty lines b/w each letter. If you need to centre the Index label, I "noinclude" the formatting as it transcludes poorly. I will also often {{block center}} the entire transcluded set as a left aligned column can look "urk". If you are looking for examples, I have had parked quite a few at user talk:Phe over the years. — billinghurst sDrewth 13:34, 16 September 2018 (UTC)

On the other hand, I never block center/center block indices because I use Layout 2 by default and it looks "urk". ;) But to each, his own.
I sometimes use the {{dhr}} template to guarantee the explicit "blank line" between sections (the software collapses whitespace for you otherwise.) I also find {{plainlist}} to come in useful, though I tend to use it more for ingredient lists in cookbooks than for indices. --Mukkakukaku (talk) 18:05, 16 September 2018 (UTC)

Tech News: 2018-38[edit]

21:58, 17 September 2018 (UTC)