Wikisource:Scriptorium/Archives/2018-08

= Announcements =

= Proposals =

= Bot approval requests =

=Repairs (and moves)=

= 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&thinsp;) 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)
 * 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)
 * ✅ 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. 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)


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

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 Scriptorium/Help 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  tags instead of  and. 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  or , and  . 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
 * Octicons-sync.svg 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
 * Octicons-sync.svg Octicons-tools.svg 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.
 * Octicons-tools.svg 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.

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)
 * 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  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)
 * the javascript for page numbering is a main namespace feature. — billinghurst  sDrewth  22:36, 28 August 2018 (UTC)
 * 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)
 * Note that the WMF has fiddled with stuff so none of the source links work now (or the handful I tested anyway). For instance, 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 (+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)
 * Those of us with basic skills to write regex use the 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   to   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. ) 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, or a quote that crosses page boundaries (using + ; and closed with 2 x ), 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  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  . 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  is calculated incorrectly for empty inline elements (the page numbers are an empty  ). 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   (making it non-empty, and avoiding the bug). However, since this only affects certain pages, but all page markers are empty   elements, there has to be a further factor at play. And it looks like that factor is this: when  is used, there is a space character before it, and that shows up in the generated HTML before the page marker   (which won't be there for non- pages). That single space character appears to be what triggers the Webkit   bug. To wit: I removed the space before  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… …which approximates what MediaWiki + ProofreadPage + pagenumbers.js is doing/using, webkit will report the wrong  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 -element in line 3, and by the single space character after the  -element in line 4. It does this even though all of them report the same  (the  -element in my test case; on Wikisource it's the  -element).

The extra space character in line 3 is the case that seems to trigger it on Wikisource when / are in use, because in the final HTML output you will get both the literal space character preceding the 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 / it can be worked around by moving the preceding space character into the template:  →  . 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 ).


 * 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 +, both in start+end-tag mode ( 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   tags; but the formatting templates mentioned above will insert a   start tag in one paragraph that won't have its corresponding   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  at the end of the first page rather than the extra space character left behind by, 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   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, -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  is less than the previous page span's, and then temporarily set the current span to   or something just to get the correct  ? Since inline page numbers (which are inline-block and have the page number as content) have the correct   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 ( or  ) that surrounds the quote across pages, and the   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   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  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   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   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. 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)


 * 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: Scriptorium/Archives/2016-09 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   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)


 * (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)

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:

Thanks, Uziel302 (talk) 10:51, 22 August 2018 (UTC)
 * Alabama to Alabama
 * Afghanistan to Afghanistan
 * Azerbaijan to Azerbaijan
 * Ancient_Egypt to Ancient_Egypt
 * Aga_Khan_III to 1922_Encyclopædia_Britannica/Aga_Khan_III
 * Antipope to Dictionary_of_Christian_Biography_and_Literature_to_the_End_of_the_Sixth_Century/Dictionary/Z/Zephyrinus
 * Andrew_Carnegie to 1922_Encyclopædia_Britannica/Carnegie,_Andrew
 * Angles to Ecclesiastical_History_of_the_English_People/Book_2
 * Angles to Historia_Ecclesiastica_gentis_Anglorum_-_Liber_Secundus
 * Angles to The_Ecclesiastical_History_of_the_English_Nation
 * Aswan to Dictionary_of_Greek_and_Roman_Geography/Aswan
 * Andalusia to Estatuto_de_Autonomía_de_Andalucía_2007
 * Beryllium to Beryllium


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