Wikisource:Scriptorium/Archives/2018-08

Please do not post any new comments on this page. This is a discussion archive first created in August 2018, although the comments contained were likely posted before and after this date. See current discussion or the archives index.

Other discussions

{{Upright}} vs. {{Normal}}

Just came across these two templates that not only do the same thing, but also consist of the same code. It appears by a large margin that {{normal}} (and it's redirect {{n}} ) is the vastly preferable one of the two. -Einstein95 (talk) 03:23, 3 August 2018 (UTC)

Because they're identical, I've taken the liberty of making {{upright}} a redirect. —Beleg Tâl (talk) 00:06, 4 August 2018 (UTC)

@Beleg Tâl: You might recall now {{upright/doc}} is orphaned and clean that up too one day? As of a few minutes ago (c.f. Special:WhatLinksHere/Template:Upright/doc) nothing at all references this page. (O.K. now this note does!) 114.73.42.69 02:08, 4 August 2018 (UTC)

Done and thanks —Beleg Tâl (talk) 02:10, 4 August 2018 (UTC)

Help for identifying an English poem, please

Hello,

I contribute on fr.wikisource, and I found this poem, handwritten on a book of French poetry by Alfred de Musset. It is NOT Musset's.

After a quick search, I found that this poem was published in the Atlantic monthly, #130, july 1922, maybe page 789^[1]. But I cannot access this scan from France.

Could someone please help me identify the author of this poem ? Thanks for your help. --Hsarrazin (talk) 18:22, 1 August 2018 (UTC)

1. https://books.google.fr/books?id=okcwAQAAMAAJ

@Hsarrazin: The author of the poem "The Name" is Jean Kenyon Mackenzie. On previous pages of the Alfred de Musset book you linked are the previous two poems appearing in that Atlantic Monthly. Despite Google Books not allowing views, Hathitrust has it in full view https://babel.hathitrust.org/cgi/pt?id=uc1.31970021659070;view=1up;seq=799. -Einstein95 (talk) 03:09, 3 August 2018 (UTC)

I had posted the following reply yesterday, but a bot "archived" it away.

The poem appears on page 789, as you cited it, and is titled "The Name". It is the third of five poems on pages 788-780, all by Jean Kenyon Mackenzie d:Q50661279 --EncycloPetey (talk) 03:33, 3 August 2018 (UTC)

Thanks, EncycloPetey. I do not think of Hathi Trust generally, because a lot of books cannot be seen fron France. But this one is fine. Thank you… :) --Hsarrazin (talk) 10:24, 4 August 2018 (UTC)

I wonder wether we'll edit it of frws, because they are in English. Anyway, I will put them on wikidata with link :)

Something is wrong with the POTM

The page images for this month's POTM, Index:The Sikhs (Gordon).djvu, are three pages removed from the pages from which the preview text is coming. Can anyone fix this? BD2412 T 17:17, 3 August 2018 (UTC)

Seems like a job for @Mpaa:. For what it's worth, I'm willing to learn to do this, if it's something you can guide me through...seems like we're always relying on you to deal with stuff like this, and I'm not sure that's entirely fair. But it's much appreciated :) -Pete (talk) 18:27, 3 August 2018 (UTC)

Done.

No black magic, just patience. I use the djvulibre set of tools to extract the text layer (usually djvused), and a python script to realign page refs vs. page text. Sometimes djvused crashes if the text layer is malformed. In that case I use djvutoxml to generate xml file and compare it with the original on IA for the pages that generate the crash. Some this also crashes ... and then, on rare occasions, I need to insert some debug prints and recompile djvulibre tools.

Beware that IAupload renames the djvu internal files, so it is a bit tricky to compare the original xml on IA with the one generated by djvutoxml.

I think there is something fishy somewhere in IAupload tool, which is triggered under some conditions. I have some ideas and suggested an improvement on a ticket in PHAB but it got no attention yet (I would be glad to help but I do not have access to the tool).— Mpaa (talk) 19:25, 3 August 2018 (UTC)

and need to sort pagination for illustrations. i would expect POTM is be sorted before jumping the queue. please. Slowking4 ‽ SvG's revenge 23:54, 3 August 2018 (UTC)

I notice IA upload tool gives an option to use the original text layer or create a new one from the archive's jp2 or pdf file, and curious which was used in the example. My concern is this: Does the tool, using the 'original' setting, produce a File that may differ from a manual upload? CYGNIS INSIGNIS 04:38, 4 August 2018 (UTC)

Because IA didn't have a djvu file, I set the tool to create one from the jp2 files. The tool then produced the faulty offset version. I had completely forgotten that it does this sometimes and so didn't think to check it before going to bed. The tool does this strange thing whereby it inserts some page images with no text into the djvu, but not into the text layer. This then results in the offset occurring. Beeswaxcandle (talk) 05:07, 4 August 2018 (UTC)

Thanks for clarifying the background. I had been using the tool for multiple volumes, with high confidence in the files selected by BHL from IA, and didn't want to create a problem where none existed. BTW, the library that generated the general's text did provide _djvu.txt and _djvu.xml files separately, which the bot wouldn't recognise, I assume that would be another way to create the file if it comes up again. CYGNIS INSIGNIS 06:55, 4 August 2018 (UTC)

Tech News: 2018-32

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

Recent changes

• Special:NewPages now has the OOUI look. [1]

Problems

• The MediaWiki version that was released two weeks ago was late to some Wikimedia wikis. This was because of bugs. It was on all wikis 30 July. [2][3]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 7 August. It will be on non-Wikipedia wikis and some Wikipedias from 8 August. It will be on all wikis from 9 August.

Meetings

• You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 7 August at 18:30 (UTC). See how to join.
• You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 8 August at 15:00 (UTC). See how to join.

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

19:39, 6 August 2018 (UTC)

Release of AkBot block

I would like the block on my bot's account AkBot to be released. I do not intend any edits in this wiki using the bot account, so the bot flag is not needed. However, I would like to receive IRC cloak for the bot account which is not possible for blocked accounts. @Billinghurst, @EncycloPetey: you may wish to comment as you were involved in the block few years ago. Ankry (talk) 08:17, 7 August 2018 (UTC)

Done Please do be sure to meet the requirements of running a bot before doing so again. --EncycloPetey (talk) 14:32, 7 August 2018 (UTC)

Portal:American literature

Today I discovered that we had never started a Portal:American literature, so I started one.

The new portal needs a lot of work, and anyone who wishes to help may find Library of Congress Classification/Class P#Subclass PS useful. --EncycloPetey (talk) 16:24, 7 August 2018 (UTC)

Glasgow Advertiser - 13 August 1792 - Richard Arkwright

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

"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

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)

Tech News: 2018-33

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

Recent changes

• CSS in templates can now be stored in a separate page on all wikis. This is called TemplateStyles. This is to make it easier to edit how templates look. [4]

Changes later this week

• There is no new MediaWiki version this week.

Meetings

• You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 14 August at 18:30 (UTC). See how to join.
• You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 15 August at 15:00 (UTC). See how to join.

Future changes

• The developers are planning more ways to block users. This could be blocking someone from just a page or a namespace. You can read more. You can leave feedback on the talk page. [5]

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

17:53, 13 August 2018 (UTC)

How to Transclude TOC from Subpages?

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

Inline HTML broken

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. Slowking4 ‽ SvG's revenge 03:42, 14 August 2018 (UTC)

Permissions for MpaaBot

Hi. I was investigating the possibility of changing Proofread status via pywikibot and I had problems using MpaaBot instead of Mpaa (see https://phabricator.wikimedia.org/T173385).
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 https://en.wikisource.org/wiki/Special:ListGroupRights.
If so, how is it that MpaaBot does not have it?

I get the following via pywikibot.

Mpaa
"groups":["abusefilter","bureaucrat","sysop","*","user","autoconfirmed"]
"rights":["abusefilter-modify","noratelimit","oathauth-enable","override-antispoof","suppressredirect","deleterevision","deletelogentry",
"editcontentmodel","edituserjs","editusercss","block","createaccount","delete","deletedhistory","deletedtext","undelete","editinterface",
"editsitejson","edituserjson","import","move","move-subpages","move-rootuserpages","move-categorypages","patrol","autopatrol","protect",
"editprotected","rollback","upload","reupload","reupload-shared","unwatchedpages","autoconfirmed","editsemiprotected","ipblock-exempt","blockemail","markbotedits","apihighlimits","browsearchive","movefile","unblockself","mergehistory","managechangetags","deletechangetags",
"editsitecss","editsitejs","tboverride","titleblacklistlog","transcode-reset","transcode-status","globalblock-whitelist","nuke","skipcaptcha",
"abusefilter-log-detail","massmessage","read","edit","createpage","createtalk","writeapi","viewmywatchlist","editmywatchlist","viewmyprivateinfo",
"editmyprivateinfo","editmyoptions","centralauth-merge","abusefilter-view","abusefilter-log","vipsscaler-test","reupload-own",
"minoredit","editmyusercss","editmyuserjson","editmyuserjs","purge","sendemail","applychangetags","changetags","pagequality","spamblacklistlog",
"mwoauthmanagemygrants","collectionsaveasuserpage","collectionsaveascommunitypage"]

MpaaBot
"groups":["bot","*","user","autoconfirmed"],
"rights":["noratelimit","bot","autoconfirmed","editsemiprotected","nominornewtalk","autopatrol","suppressredirect","apihighlimits","writeapi","skipcaptcha",
"read","edit","createpage","createtalk","abusefilter-view","abusefilter-log","reupload-own","move-rootuserpages",
"move-categorypages","minoredit","purge","applychangetags","changetags","reupload","upload","move"]}}}

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 https://phabricator.wikimedia.org/T201904 .— Mpaa (talk) 15:32, 15 August 2018 (UTC)

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

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) .

Scans with missing pages

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)

Visual Editor

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 pl.ws 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: https://phabricator.wikimedia.org/T202200 .-— Mpaa (talk) 18:37, 18 August 2018 (UTC)

TemplateStyles and book formatting

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

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

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 21 August. It will be on non-Wikipedia wikis and some Wikipedias from 22 August. It will be on all wikis from 23 August (calendar).

Meetings

• You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 22 August at 15:00 (UTC). See how to join.

Future changes

• The 2018 Community Wishlist Survey begins on 29 October. The survey decides what the Community Tech team will work on. You can post proposals from 29 October to 11 November. You can vote on proposals from 16 November to 30 November.
• Legacy JavaScript global variables have been deprecated for seven years. They will soon be removed from all wikis. Gadgets and scripts that use them will stop working. You can test your community's gadgets on "group0" wikis. For example Test Wikipedia or mediawiki.org. The legacy JavaScript global variables are already disabled there. You can read the migration guide to fix old scripts. [6]

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

16:46, 20 August 2018 (UTC)

Latest message for Collaboration team newsletter; Growth team's newsletter invite

Hello

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)

Page numbers + links in left-hand margin

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)❤T☮C☺M☯ 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 https://phabricator.wikimedia.org/diffusion/?view=markup#l1, but the proofread.js script actually lives at https://phabricator.wikimedia.org/diffusion/EPRP/browse/master/modules/page/ext.proofreadpage.page.edit.js. 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. [7]) don’t know if global find is an improvement. Slowking4 ‽ SvG'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)

Page numbers borked with hyphenated words

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. Slowking4 ‽ SvG'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. Slowking4 ‽ SvG's revenge 03:23, 28 August 2018 (UTC)

More details than you wanted

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…

    <p>
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/>
    </p>

…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   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 ​ 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? 114.73.42.69 10:07, 8 September 2018 (UTC)

Thanks! For this particular purpose, it looks like simply adding ​ 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. 114.74.168.126 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)

Notes

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.

List of broken links from Wikipedia to Wikisource

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. Slowking4 ‽ SvG's revenge 02:55, 29 August 2018 (UTC)

by the way, some of those may be the em dash versus en dash conflict. Slowking4 ‽ SvG's revenge 02:52, 3 September 2018 (UTC)

fyi, (a lot of links are are malformed template syntax) the english admins are mass reverting my attempts to work this backlog, so i leave it to you. Slowking4 ‽ SvG's revenge 00:24, 19 September 2018 (UTC)

Hmm. What changes are getting reverted? --Xover (talk) 17:02, 19 September 2018 (UTC)

well, for example, this one here [8] apparantly a bot changed the dashes in title to em dashes breaking the link. an attempt to fix it was mass reverted. Slowking4 ‽ SvG's revenge 03:47, 17 October 2018 (UTC)