Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

« Older discussions, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155
Centralized discussion
Proposals: policy other Discussions Ideas

For a listing of ongoing discussions, see the dashboard.


Search: Links from[edit]

In the search facility there is the linksto:<page> clause.

Is there the opposite, or the equivalent to, that is, a linksfrom:<page> clause, that is, returning all the pages linked to from within an article ?

Eno Lirpa (talk) 14:44, 18 May 2017 (UTC)

Any ideas anyone? Eno Lirpa (talk) 13:44, 23 May 2017 (UTC)

This is either an ultradifficult question to answer or a hyperboring one ? Eno Lirpa (talk) 12:04, 25 May 2017 (UTC)

Follow-up to the RfC for sister projects in search results[edit]

Thank you for the constructive feedback and discussion during the recent RfC. The following sister project snippets will be displayed on enwiki are listed below (in no particular order):

  • Wikisource
  • Wiktionary
  • Wikiquote
  • Wikibooks
  • Wikivoyage (title match only)

The following projects will not display on enwiki at this time:

  • Commons multimedia
  • Wikinews
  • Wikiversity

Barring any unforeseen circumstances or significant new issues being raised, we’ll enable this new feature on the search results page for all Wikipedias during the week of May 30th, 2017. Cheers, DTankersley (WMF) (talk) 10:34, 20 May 2017 (UTC)

@DTankersley (WMF): Thanks for this! This feature should really improve Wikipedia searches for the general public. I note, however, that the closure of the RfC states that there was a "strong consensus to oppose" the inclusion of Wikibooks. I disagree with the closer's assessment of "strong consensus", but I note that there was certainly a lack of support for the inclusion of Wikibooks. Would you be able to make a comment on this? — This, that and the other (talk) 03:57, 21 May 2017 (UTC)
@This, that and the other: Yes, I completely agree with you. I don't believe that there was a 'strong consensus' for not displaying Wikibooks; at the best, it got weak support. But, with only 4 people giving their opinion, I feel it's ok to display to our readers/editors/users if the content exists. I really liked @WhatamIdoing:'s response on the discussion...to note that Wikibooks is more of a site for "people seeking textbooks and related materials" and "provides non-fiction content for children" with simple concepts. The idea of displaying the sister projects is to promote discovery into new knowledge that users might not ever have seen before. Maybe we can even hope that they'll contribute and make those projects all the more better! :) DTankersley (WMF) (talk) 18:18, 23 May 2017 (UTC)

Tech News: 2017-21[edit]

22:02, 22 May 2017 (UTC)

@Johan (WMF): What does this mean? Surely we already have <div>...</div> elements that enclose the parsed page content? Indeed, when I view the source for this page, I find that this section - like all the other sections - is five divs deep:
<div id="globalWrapper">
  <div id="column-content">
    <div id="content" class="mw-body" role="main">
      <div id="bodyContent" class="mw-body-content">
        <div id="mw-content-text" lang="en" dir="ltr" class="mw-content-ltr">
Are you adding a sixth layer? Why would that cause us problems? --Redrose64 🌹 (talk) 23:02, 22 May 2017 (UTC)
@Johan (WMF): Gadgets with code that does not follow recommendations… It might be useful if you could provide a pointer to these recommendations, please, to help everyone know what to look for. Thanks. Murph9000 (talk) 23:07, 22 May 2017 (UTC)
Redrose64, Murph9000:
  • Surely we already have <div>...</div> elements that enclose the parsed page content?
    • The problem is that #mw-content-text does not only contain parsed page content. It also contains .diff, .diff-hr and .diff-currentversion-title in diffs and .patrollink on unpatrolled pages.
  • Are you adding a sixth layer?
    • The exact HTML structure depends on skin – Vector does not have #column-content or #globalWrapper – but yes.
  • Why would that cause us problems?
    • Any CSS or JavaScript that relies on parsed page content being directly in #mw-content-text will break. In other words, any CSS like #mw-content-text > .infobox or JavaScript like $( '#mw-content-text' ).children( '.infobox' ) would need to be changed to #mw-content-text .infobox and $( '#mw-content-text' ).find( '.infobox' ) respectively.
Nirmos (talk) 07:33, 23 May 2017 (UTC)

cite template with script-title messing Hebrew title with embedded number[edit]

The {{cite news}} template with |script-title= is messing up the display of a Hebrew title with an embedded number and displaying the external link icon centered on the link anchor text instead of to its right. Here are three examples. The first two examples use |script-title= for the original Hebrew and |title= for the English translation. The third example uses |title= for the original Hebrew and |trans-title= for the English translation. The first example replaces the number, "1.5", in the Hebrew title, to an asterisk (*), and display is normal. The second and third examples use the correct Hebrew title with the number "1.5" . In the second example, using the full Hebrew title with |script-title=, the Hebrew title displays wrong near the number, extra white space is added to make up for the error, and the external link icon is misplaced. This would seem to be a bug. The third example displays normally. Note: surrounding the Hebrew title with <bdi lang="he" dir="rtl">...</bdi> does not help.

  1. |script-title= and |title= (asterisk: *) (markup)<ref>{{cite news |author=Alexander Katz |url=http://www.ice.co.il/media/news/article/361862 |script-title=גם ג'רוזלם פוסט נכנס לטרנד: השקיע * מיליון ש' במהדורת חדשות באינטרנט |language=he |title=The Jerusalem Post also enters trend: it invested NIS * million on an Internet news edition |publisher=ICE.co.il |date=10 June 2013 |accessdate=2013-11-21}}</ref> (display)[1]
  2. |script-title= and |title= (number: 1.5) (markup)<ref>{{cite news |author=Alexander Katz |url=http://www.ice.co.il/media/news/article/361862 |script-title=גם ג'רוזלם פוסט נכנס לטרנד: השקיע 1.5 מיליון ש' במהדורת חדשות באינטרנט |language=he |title=The Jerusalem Post also enters trend: it invested NIS 1.5 million on an Internet news edition |publisher=ICE.co.il |date=10 June 2013 |accessdate=2013-11-21}}</ref> (display)[2]
  3. |title= and |trans-title= (markup)<ref>{{cite news |author=Alexander Katz |url=http://www.ice.co.il/media/news/article/361862 |title=גם ג'רוזלם פוסט נכנס לטרנד: השקיע 1.5 מיליון ש' במהדורת חדשות באינטרנט |language=he |trans-title=The Jerusalem Post also enters trend: it invested NIS 1.5 million on an Internet news edition |publisher=ICE.co.il |date=10 June 2013 |accessdate=2013-11-21}}</ref> (display)[3]
References

Anomalocaris (talk) 00:50, 23 May 2017 (UTC)

I don't read Hebrew so I can't really know if there is anything wrong with the Hebrew text in the title. I do know that when using |script-title=, you should tell it what language you are using. In this case, |script-title=he:... – the language code helps browsers to display it correctly; I do know that when using |script-title=, |title= is to be used for a transliteration of the original language title; I do know that |trans-title= is to hold the English language translation of the title in |script-title=.
In all three of your examples, the external link icon is at the right end of the linked text. I see no example that has the external link centered on the link anchor text.
Are we to understand that in your first example, the asterisk identifies the correct location of the 1.5 text? Perhaps because I don't read Hebrew, replacing '1.5' with '*' does not appear to have changed anything. Can you elaborate? Can you devise a very, very simple example that illustrates the problem. Can you show the same text, correctly formed, outside of a cs1|2 template so that the cs1|2 rendering can be compared to it.
I think that the correct parameter usage for this citation is this one:
{{cite news |author=Alexander Katz |url=http://www.ice.co.il/media/news/article/361862 |script-title=he:גם ג'רוזלם פוסט נכנס לטרנד: השקיע 1.5 מיליון ש' במהדורת חדשות באינטרנט |language=he |trans-title=The Jerusalem Post also enters trend: it invested NIS 1.5 million on an Internet news edition |publisher=ICE.co.il |date=10 June 2013 |accessdate=2013-11-21}}
Alexander Katz (10 June 2013). גם ג'רוזלם פוסט נכנס לטרנד: השקיע 1.5 מיליון ש' במהדורת חדשות באינטרנט [The Jerusalem Post also enters trend: it invested NIS 1.5 million on an Internet news edition] (in Hebrew). ICE.co.il. Retrieved 2013-11-21. 
Trappist the monk (talk) 02:33, 23 May 2017 (UTC)
Trappist the monk: Yes, the only difference between the first two examples is that in the first example, asterisk replaces "1.5". As you can see from your experiment, adding "he:" to the beginning of |script-title= helps a little. The external link symbol is not centered, but off to the right where it belongs, and the Hebrew letters near "1.5" are less scrunched. In fact, what seems to happen is that the Hebrew before (to the right of) "1.5" displays normally, starting from the right; then "1.5" displays, but instead of "1.5" being entirely to the left of the Hebrew preceding it, the "1" in "1.5" is just to the left of the last word before it, so that ".5" overwrites the right end of the last word before it, and then the Hebrew after (to the left of) "1.5" starts up, rather than entirely to the left of "1.5", just to the left of the "5", overwriting "1.". Here is a shorter example set:
  1. |script-title= and |title= (asterisk: *) (markup)<ref>{{cite web |author=Johnny Appleseed |url=http://www.apple.org/ |script-title=he:הרופא: תאכל * תפוחים |language=he |title=Doctor: Eat * apples |publisher=apple.org |date=10 June 2017}}</ref> (display)[1]
  2. |script-title= and |title= (number: 2) (markup)<ref>{{cite web |author=Johnny Appleseed |url=http://www.apple.org/ |script-title=he:הרופא: תאכל 2 תפוחים |language=he |title=Doctor: Eat 2 apples |publisher=apple.org |date=10 June 2017}}</ref> (display)[2]
  3. |title= and |trans-title= (markup)<ref>{{cite web |author=Johnny Appleseed |url=http://www.apple.org/ |title=he:הרופא: תאכל 2 תפוחים |language=he |trans-title=Doctor: Eat 2 apples |publisher=apple.org |date=10 June 2017}}</ref> (display)[3]
References
  1. ^ Johnny Appleseed (10 June 2017). "Doctor: Eat * apples" הרופא: תאכל * תפוחים (in Hebrew). apple.org. 
  2. ^ Johnny Appleseed (10 June 2017). "Doctor: Eat 2 apples" הרופא: תאכל 2 תפוחים (in Hebrew). apple.org. 
  3. ^ Johnny Appleseed (10 June 2017). "רופא: תאכל 2 תפוחים" [Doctor: Eat 2 apples] (in Hebrew). apple.org. 

In this shorter example set, using |script-title=, the Hebrew near the number ("2") is scrunched and the external link symbol is misplaced, but when "2" is replaced with "*" it works fine, and it also works fine to avoid |script-title= entirely and use |title= and |trans-title=. The bug is: if |script-title= is in a right-to-left language and includes an embedded number, even if only one digit long, the display is messed up near the number. —Anomalocaris (talk) 05:03, 23 May 2017 (UTC)

I get the links as can be seen at File:Image of Hebrew text in link.png. עוד מישהו Od Mishehu 07:46, 23 May 2017 (UTC)
This is what I see File:WP VPT screencap 2017-05-23T04 15 37.png. Chrome on win7. Is this a browser issue?
You are still misusing |title= in these examples. The English translation of the Hebrew goes in |trans-title=; when |script-title= is used, |title= gets the transliteration of the original language title; in this case, Hebrew words written with Latin characters.
Trappist the monk (talk) 10:44, 23 May 2017 (UTC)
Trappist the monk: Yes, you're right that |trans-title= is for the English translation whether the foreign title is in |title= or |script-title=. That's irrelevant to the bug of bad display of |script-title= containing Hebrew with embedded digits. —16:00, 23 May 2017 (UTC)
Mozilla Firefox problem, not Internet Explorer or Chrome

Thank you, עוד מישהו, for suggesting the possibility that it is browser-related. For all three browsers, it makes no difference if I am logged in or not. Can we make the output of |script-title= containing Hebrew with embedded digits render correctly for Mozilla Firefox? —16:00, 23 May 2017 (UTC)

Reflist-talk[edit]

Adding {{reflist-talk}} to talk pages has produced a red link for me several times, most recently at Talk:Comma splice § "I came, I saw, I conquered". Please help. —Sangdeboeuf (talk) 05:24, 23 May 2017 (UTC)

@Sangdeboeuf: You had some strange character on the end of the template name. With URL encoding, you were linking to "Template:Reflist-talk%E2%80%8B". It was unprintable for me, and I've not tried to figure out what character it is. It's either an intentionally blank Unicode character, or in some quite unusual part of the Unicode range, or similar. Murph9000 (talk) 05:36, 23 May 2017 (UTC)
According to r12a, %E2%80%8B is an encoding of U+200B, or zero-width space. I have expressed my dislike for such characters several times, most recently at User talk:Corinne#MoS. --Redrose64 🌹 (talk) 08:50, 23 May 2017 (UTC)

Category Wikipedian librarians is giving funky output[edit]

Please check out Category:Wikipedian_librarians ([2]).

The output List I get starts like this:

(

*

0–9 A

Any idea what is going on? I'm guessing some of the user names start with non-alphanumeric and/or non-standard, non-printing characters. I'm wondering if the code that processes the list of users in the categories is deliberately sorting some users into categories that start with "(" or "*", or if the code does not expect those characters in the user name and is acting funky like this. If anyone does decide to look at the display code, can you tell me where it is? I'm starting to get curious about what the code looks like and where to find it... --David Tornheim (talk) 12:52, 23 May 2017 (UTC)

Leading space character in the sort key?
[[Category:Wikipedian_librarians| Aphilli]]
instead of:
[[Category:Wikipedian_librarians|Aphilli]]
Trappist the monk (talk) 12:59, 23 May 2017 (UTC)
You're right. Do you think it would be okay if I fixed it on their user page and told them at the talk page why I corrected it? It definitely looks like typos for five of them, not including those whose true user name starts with "(". I don't know what to make of people who put the category in their userbox. That seems weird, but might be acceptable. Do you know? --David Tornheim (talk) 13:11, 23 May 2017 (UTC)
I just make the change boldly and usually nothing comes of it. --Izno (talk) 13:28, 23 May 2017 (UTC)
It seems sensible that userboxes adding a category are sorted separately under space or asterisk like User:Nowimnthing/User library and information scientist and User:Quartermaster/Userboxes/RefLibrarian. The pages are not there to help find librarians but to help users who want to say they are librarians. Userboxes are often added to the category text instead like Category:Wikipedian air traffic controllers. I would just remove the sort key in User:Jodi.a.schneider. The user may have copied the code without knowing what it means. PrimeHunter (talk) 13:58, 23 May 2017 (UTC)

Why do most of thumbs of this PDF file have wrong color?[edit]

Wrong color.
Correct color.

--fireattack (talk) 08:10, 24 May 2017 (UTC)

@Fireattack: I don't see a difference.. Can you be more specific about which colours you are seeing, and where in which image ? —TheDJ (talkcontribs) 08:18, 24 May 2017 (UTC)
@TheDJ: The green is totally different. In the first image it's oversaturated.-fireattack (talk) 08:21, 24 May 2017 (UTC)
They look exactly the same to me. Have you tried clearing your cache to check that you're not viewing an older version of one of the images? ‑ Iridescent 08:22, 24 May 2017 (UTC)
No I found it, it seems there were some old thumbnails laying around, which for some reason had a different color. I purged the image on Commons, forcing a re-render of all known thumbnails and once your browser cache catches up, it should be all fine. —TheDJ (talkcontribs) 08:24, 24 May 2017 (UTC)
More to the point, why on earth are we using a pdf file for a map? ‑ Iridescent 08:25, 24 May 2017 (UTC)
It links to a pdf source https://www.nps.gov/gate/planyourvisit/upload/GATE-Locator-Map.pdf. But there is also a jpg version at https://www.nps.gov/gate/planyourvisit/images/GATE-Locator-Map.jpg. PrimeHunter (talk) 10:22, 24 May 2017 (UTC)
Thanks, now after another ctrl+F5 it shows the right color. -fireattack (talk) 08:25, 24 May 2017 (UTC)

Bugs in the new mobile update (1)[edit]

  • Saved pages from the previous version are all erased
  • Template:flagicon does not work anymore.
  • Copy-Pasting from within edit screens is very buggy.
  • template:Image map for The Situation Room gives very wierd results. It ignores the [[Article Name|Anything you want]] format. I am investigating it now.

will update
 • Sammy Majed  • Talk  • Creations • Wikipedia Arabic  • 08:58, 24 May 2017 (UTC)

@SammyMajec: .. which mobile ? mobile web or mobile app ? Android or iOS ? —TheDJ (talkcontribs) 11:47, 24 May 2017 (UTC)
@SammyMajed:TheDJ (talkcontribs) 11:48, 24 May 2017 (UTC)
@SammyMajed: Thanks for reporting! This is for the Android app, correct?
    • For the first issue, OS-level backups to preserve saved pages will be enabled beginning in the next beta release.
    • Could you explain a little more about what bugs you are seeing with copy/pasting from the editing activity?
    • For each the template problems, could you please provide an example of an article that shows the problem? —MHolloway (WMF) (talk) 13:36, 24 May 2017 (UTC)


@MHolloway (WMF): Indeed, Android.

  • for copy-pasting, I find copying glitchy. sometime it successfully copies, sometimes it doesn't. I do not know why. I noticed that copying special symbols (&/@*#^![}>+÷%`~) almost never works.
  • for templates, check the image map template. that template offers a famous picture of white house personnel and features a "click on the person to go to their article" feature. I know as a fact that it used to work because I am currently translating an article about the photo to Arabic. now it gives "there is no such article as this". also, I noticed that clicking on anywhere other than a person in the photo will give a very wierd result, while if you clicked so in the previous version it will just take you to the image file page. for flagicon, I do not know for certain where it is used, so check its usage in my userpage in the section named "places I'd like to go" or something like that.

I will do another report of bugs I encountered afterwards in the bottom of this page. please, remeber that while I report bugs to you do not expect technical knowledge from me.  • Sammy Majed  • Talk  • Creations • Wikipedia Arabic  • 05:02, 25 May 2017 (UTC)

Hide references when editing?[edit]

Is there a way to hide/collapse inline citations when editing an article? Sometimes they get in the way, and doing this would be a great help. Thanks. SharkD  Talk  12:00, 24 May 2017 (UTC)

Yup. Try installing User:PleaseStand/References segregator - I use it all the time. Yunshui  12:05, 24 May 2017 (UTC)
And also annoys some other editors, who don't appreciate WP:LDR. You actually have to get explicit consensus on each and every article to make that switch, per the guideline.
You could try mw:User:Remember the dot/Syntax highlighter or WP:WikEd, which has syntax highlighting. A lot of people turn WikEd off pretty quickly again (it takes a few days to get used to, and it works best on a good computer), but if you have a good computer or don't mind waiting a few seconds here and there, then you might become one of its fans. WhatamIdoing (talk) 15:18, 24 May 2017 (UTC)
@WhatamIdoing: Confused; the script page says that it can change the format to list-defined, not that it has to. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
15:24, 24 May 2017 (UTC)
The script may have added some features since the last time I used it. Nobody cares about changes that don't affect what they're seeing when they edit later. But people do care about changes that move all of the refs out of the section they want to edit. WhatamIdoing (talk) 15:32, 24 May 2017 (UTC)

Linewrapping for very long URLs without breaking the link[edit]

Is there a way to make a very long URL wrap within the normal width of the page instead of doing this? -- Roger (Dodger67) (talk) 12:06, 24 May 2017 (UTC)

It wraps for me in Firefox but not in Edge. <div style="overflow-wrap: break-word; word-break: break-all;">...</div> also wraps for me in Edge:
https://upload.wikimedia.org/wikipedia/commons/thumb/f/fd/%D0%9C%D0%B5%D0%B4%D0%B0%D0%BB%D1%8C_%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B5%D1%81%D1%81_%28%D0%90%D0%B7%D0%B5%D1%80%D0%B1%D0%B0%D0%B9%D0%B4%D0%B6%D0%B0%D0%BD%29_%28%D0%BB%D0%B5%D0%BD%D1%82%D0%B0%29.png/60px-%D0%9C%D0%B5%D0%B4%D0%B0%D0%BB%D1%8C_%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B5%D1%81%D1%81_%28%D0%90%D0%B7%D0%B5%D1%80%D0%B1%D0%B0%D0%B9%D0%B4%D0%B6%D0%B0%D0%BD%29_%28%D0%BB%D0%B5%D0%BD%D1%82%D0%B0%29.png
PrimeHunter (talk) 12:59, 24 May 2017 (UTC)
Thanks PrimeHunter it also works in Chrome on an Android tablet. Roger (Dodger67) (talk) 15:17, 24 May 2017 (UTC)
@Dodger67: I would also strongly recommend decoding the URL, which both makes it human-readable and has around a 2:1 or 3:1 size reduction. Here is the above with minimal URL encoding: https://upload.wikimedia.org/wikipedia/commons/thumb/f/fd/Медаль_Прогресс_%28Азербайджан%29_%28лента%29.png/60px-Медаль_Прогресс_%28Азербайджан%29_%28лента%29.png That's still long enough that wrapping may be beneficial, but it's significantly less horrible, and more likely to correctly break into lines as there's actual words and punctuation there, rather than %-soup. Murph9000 (talk) 19:06, 24 May 2017 (UTC)

My Reddit AMA about Wikipedia and ethical, transparent AI.[edit]

Hey folks, I'm doing an experimental Reddit AMA ("ask me anything") in r/IAmA on June 1st at 21:00 UTC. For those who don't know, I create artificial intelligences that support the volunteers who edit Wikipedia. I've been studying the ways that crowds of volunteers build massive, high quality information resources like Wikipedia for over ten years. This AMA will allow me to channel that for new audiences in a different (for us) way. I'll be talking about the work I'm doing with the ethics and transparency of the design of AI, how we think about artificial intelligence on Wikipedia, and ways we’re working to counteract vandalism. I'd love to have your feedback, comments, and questions—preferably when the AMA begins, but also through the ORES talkpage on MediaWiki.

If you'd like to know more about what I do, see my WMF staff user page, this Wired piece about my work or my paper, "The Rise and Decline of an Open Collaboration System: How Wikipedia’s reaction to popularity is causing its decline". --EpochFail (talkcontribs) 14:50, 24 May 2017 (UTC)

Infobox placement in mobile view[edit]

I was just looking up some articles on my phone, when I noticed that the infobox is appearing below the first paragraph of the lead in mobile view, opposed to the first thing when looking at an article. See Captain America: Civil War, United Kingdom, and Agents of S.H.I.E.L.D. for some examples. - Favre1fan93 (talk) 18:51, 24 May 2017 (UTC)

@Favre1fan93: As a frequent mobile user, I tell you it is most normal and most convenient. A bug arised in the last 2 weeks that made the infobox appear first, which totally destroyed the hyperlini view. It was thankfully fixed in this version. Regards;  • Sammy Majed  • Talk  • Creations • Wikipedia Arabic  • 05:11, 25 May 2017 (UTC)
This is not actually how it was, at least not for IOS users. It has always been infobox first. And While I can understand where it might be appropriate for some intense picture heavy articles, it does not at all flow naturally for others. For instance, TV shows, movies games, should have it come first. It's weird to read a paragraph about, say Agents of Shield, and then have to scroll past and infobox giving you mostly the same info. It should at least be toggleable . --Deathawk (talk) 07:21, 26 May 2017 (UTC)

phab:T143139, phab:T145216, phab:T150325. Nirmos (talk) 11:14, 25 May 2017 (UTC)

I have also noticed this issue. It looks kind of odd to find the first paragraph at the top. I have used mobile phone but I have never seen this before. The infobox always appears first but its not the case recently. Please fix. Nyanchoka : talk 2 me 19:23, 25 May 2017 (UTC)
I hope so too, or at least there should be an option to turn it back. --Deathawk (talk) 07:36, 26 May 2017 (UTC)
This is how the mobile apps (so not web) have been doing it for a while. For web it's new. The reasoning I have heard in the past is that it helps readability of an article to have the first paragraph as text. On web this is not a problem because they are side by side, but on mobile it's either one or the other. —TheDJ (talkcontribs) 08:10, 26 May 2017 (UTC)
To confirm, this is an intended change recently deployed to the mobile website, it has been available on the iOS and Android apps for a while now. The main motivation is exposing introductory content, such as the lead paragraph, prior to more-detailed content available in the infobox - saving some scrolling time and focusing on consistency with the desktop website where infobox content is presented as secondary to text content. Another main motivator is for cases where users who are unfamiliar with the article content and have to scroll through the infobox only to realize they selected the wrong article. More details and examples are available on the project page. - OVasileva (WMF) (talk) 13:12, 26 May 2017 (UTC)

Bot edits in watchlist[edit]

When I remove bot edits from my watchlist, I don't see the article even if on that same day an edit was made by a non-bot. Is this a bug? Debresser (talk) 21:10, 24 May 2017 (UTC)

The phab task to fix it has been open since 2007. I wouldn't hold your breath. ‑ Iridescent 21:30, 24 May 2017 (UTC)
Thanks. :) Debresser (talk) 10:30, 25 May 2017 (UTC)
Will turning on "Expand watchlist to show all applicable changes" help? What will be the side effects of that? Debresser (talk) 10:32, 25 May 2017 (UTC)
It's a setting at Special:Preferences#mw-prefsection-watchlist currently called "Expand watchlist to show all changes, not just the most recent". It will show all edits you are not hiding. It's often combined with "Group changes by page in recent changes and watchlist" at Special:Preferences#mw-prefsection-rc. There is no setting to only show the most recent edit you are not hiding. PrimeHunter (talk) 11:03, 25 May 2017 (UTC)
I tried out combining these two settings. The result is interesting, and has more details as to how many edits and by whom, but has the problem that it also shows edits to pages which I edited afterwards (since I checked "hide my edits"). In any case, I understand there is no workaround. Strange, that this was never fixed. Debresser (talk) 11:55, 25 May 2017 (UTC)

bugs in the android app (2)[edit]

  • First and foremost: The first tab in the tab list always resets to "main page" when restarting the app.
  • The talk link in the bottom of userpages does not work. it apparently does [[Talk:User:Example]] instead of [[User Talk:Example]].
  • I am still investigating several things, I will update.

 • Sammy Majed  • Talk  • Creations • Wikipedia Arabic  • 05:14, 25 May 2017 (UTC)

What does Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH mean?[edit]

I gotthe error message (in my console) when an article failed to load except for the first sentence. I get these hangups once or twice a day. I'm going to try to renew all my scripts but would like to understand this message. Thanks. Doug Weller talk 12:26, 25 May 2017 (UTC)

@Doug Weller: I don't know, but Google suggests it is a message from the Chrome browser indicating a clash between the browser's expectation about the length of data the server should send and what the browser actually received. From stackoverflow: Before sending data, the server sends an HTTP header which may include a Content-Length value. The error message means that value disagrees with what was received, and a couple of remedies are suggested, although they may not apply to your case. They mention an add blocker possibly installed in your browser, or a proxy between your computer and Wikipedia, or hitting the limit of a data cache somewhere. Johnuniq (talk) 11:54, 26 May 2017 (UTC)
@Johnuniq: that's brilliant, I never even though to use Google, assuming it was something to do with a script. I think I can fix it then. Doug Weller talk 12:02, 26 May 2017 (UTC)

Login problem on iPad[edit]

I accidentally logged myself out on my PC. I was able to log back in with no problem (had to get my 2FA code but that's all), but on my iPad I keep getting "There seems to be a pproblem with you login session, this action has been canceled as a precauion against session hijacking. Go back to the previous page, reload that page and try again. But that doesn't work. Doug Weller talk 19:37, 25 May 2017 (UTC)

18 hours later, still getting the same message with both Safari and Chrome. Doug Weller talk 13:50, 26 May 2017 (UTC)
@Doug Weller: can you clear any local cookie stores and caches on the browsers you are having a problem with? — xaosflux Talk 14:01, 26 May 2017 (UTC)
@Xaosflux: Perfect. Thanks very much. I'll remember next time I hope! Doug Weller talk 15:02, 26 May 2017 (UTC)

Heading moved to wrong part of page[edit]

At Talk:Victoria Park & Bow railway station, the section heading "coordinates" appears at upper right, instead of the proper place at the top of its section. Why is this? --Redrose64 🌹 (talk) 22:19, 25 May 2017 (UTC)

@Redrose64: It's caused by an insufficiently specific CSS rule for #coordinates at the top of MediaWiki:Vector.css. Capitalising the section heading solves that particular instance of it. Really the selector should be more specific, to avoid this problem. It needs some careful thought as to exactly what more specific selector (or possibly group of selectors) should be used, as there's a few scenarios to cover. My first guesses would be that it could be changed to element#coordinates, or .some-class#coordinates, possibly for several different classes. Murph9000 (talk) 22:36, 25 May 2017 (UTC)
From a fairly quick look at Module:Coordinates, I believe that changing the CSS to use span#coordinates is probably the appropriate fix. I'm not absolutely certain that module is the only place generating it, but it probably should be. Murph9000 (talk) 22:53, 25 May 2017 (UTC)
It happens in all skins due to similar code in MediaWiki:Monobook.css, MediaWiki:Modern.css and MediaWiki:Cologneblue.css. safemode=1 prevents it by not loading any of the skin modifications. It could be brought up at Wikipedia talk:WikiProject Geographical coordinates. In a search of all namespaces I get 13 hits on "coordinates" insource:/=coordinates=/, and 45 on "coordinates" insource:/= coordinates =/. None of them are in mainspace. All tested examples display the problem. PrimeHunter (talk) 23:01, 25 May 2017 (UTC)

I don't see how changing the selector to span#coordinates would solve the problem. If we look at the heading structure in Special:PermanentLink/782185879, the element with the id "coordinates" is a span. However, changing it to span #coordinates might work, because proper coordinates are wrapped in an outer span that sets the font size to small. Nirmos (talk) 04:01, 26 May 2017 (UTC)

Damn, you're right. Sorry, I mistakenly thought the heading id was on the h2 element, or used the traditional anchor for it, I was focussed on Module:Coordinates and should have checked the heading markup as well. Yes, checking for a parent span element would work, although span > #coordinates would be more efficient. Even better might be to change the module to add a class, then use .coordinates-title#coordinates, or something like that. Another alternative would be #coordinates:not(.mw-headline). Murph9000 (talk) 18:49, 26 May 2017 (UTC)

Redlinks at user pages[edit]

Hello. I would like a tool please that ensures redlinked categories at user pages do not end up in Special:WantedCategories. Thanks. The reason for this is that Wikipedia has a fun tradition of users putting humorous redlinked categories on their user pages, but this clogs up the list of more serious redlinks that must be dealt with by serious editors. Anythingyouwant (talk) 01:17, 26 May 2017 (UTC)

As noted elsewhere, a redlinked category in an error per WP:REDNOT, which should be fixed either by creating the categ page or by removing the redlink.
This request amounts to asking that editors be assisted in their desire to intentionally generate an error in the category system, for the purpose of either breaching WP:USERCAT's guidance that user categories should not be used as "bottom-of-the-page" notices or the policy WP:NOTSOCIAL.
And you want the programming resources of he community and/or WMF to be used to add complexity to the code to facilitate this? Boggle.
If somebody somewhere wanted to program this, how do you propose that such a tool distinguish between deliberate redlinks and the many types of legitimate user categories which my initially be redlinked? Those legitimate usercats include sockpuppet categories, translator and proof-reader category, language proficiency categories, categories by location, nationlity, skill, interest etc. We need Special:WantedCategories to include redlinks of those legit ucats, so a blanket exclusion of all redlinked user categories won't work.
Yes, I know that redlinked user cats existed for years. I had two myself (2009 to early 2017), but I removed them in January 2017 when I became aware that they impeded enyclopedic maintenance. I GF that most editors who add such categories were, like me, unaware of adverse effects. Most editors who have become aware of this have been happy to remove the redlinks, because they don't want to be disruptive.
A tiny minority of editors have chosen to be selfish extremists, intentionally creating redlinked usercats specifically in order to troll and create work for the editors engaged in this form of maintenance.
Thankfully, most of the editors who still want to see redlinked ucats are, like Anythingyouwant, keen to avoid disruption, and I thank Anythingyouwant for their courtesy and consideration in pursuing this idea. But I am still bewildered by the amount of effort they want to expend in having a redlinked category rather than a userbox or some text or a graphic. Is a redlinked categ 'really so hilariously funny that all this effort is justified? Really? --BrownHairedGirl (talk) • (contribs) 11:20, 26 May 2017 (UTC)
Keep on personally attacking people who disagree with you, BHG. It's really doing wonders for your credibility. "Selfish extremists" my ass. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 13:13, 26 May 2017 (UTC)
(edit conflict) I saw the notification from BHG to user categories discussion, and am disappointed to read the same flawed arguments being made. When the category for Gay Wikipedians was deleted, retaining the red link was not a deliberate creation of an error in the category system, it was a protest against an action that was unprincipled and homophobic in its effect. Many of the editors involved did not recognise that this would be the effect, but it was. Protesting homophobia is justified, and the protests were vindicated in that the correct solution of re-creation of the category eventually occurred. Applying the current "solution" of placing gay Wikipedians (but not Christian Wikipedians, say) in a category for "idiosyncratic Wikipedians" would hardly have been inoffensive, nor was emptying the category. Those Wikipedians were not a tiny minority of editors [who chose] to be selfish extremists, intentionally creating redlinked usercats specifically in order to troll and create work for the editors engaged in this form of maintenance – seriously, BHG, you can't see the failure of AGF in your statement?
Another example I have raised with BHG before was the Wikipedians who are not Wikipedians category, a deliberate protest against a shocking statement from an Arbitrator that was part of debates / discussions around Wiki-governance. Part of its point was made by being red because it invoke the idea of an unperson. Neither of the dictates of "solutions" according to REDNOT applies, which is a fault in REDNOT, not a campaign of Wiki-destabilisation against the closed shop of editors interested in category work who act as though their decisions have the consensus support of the entire community.
This latter problem is well illustrated by this ongoing CfD where the idea that not notifying editors in user categories of deletion proposals is somehow not problematic. It has been argued elsewhere that telling editors who are in user categories of deletion proposals would amount to canvassing or votestacking.
I don't doubt there are (were?) many pointless red categories that were unfunny jokes, but the notion that a red category is inherently an error and a deliberate disruption in many cases is neither true nor fair. A technical solution is much better than the one BHG has adopted, especially given the consensus at the user categories discussion appears unlikely to favour the category regulars. There are people behind each editor name, and treating them like sheep to be managed by the routine exercise of inflexible rules is both harmful and not the wiki way. The ease-of-use of the special Wanted Category page is not the only consideration, and even here where a technical fix is sought to help with that tool, the editors who disagree with BHG's views are disrespected and criticised. Seriously, if an editor is willing to do the work to address the technical issue, that would be great. EdChem (talk) 13:29, 26 May 2017 (UTC)
@EdChem: I am sorry to have offended you, but please re-read what I wrote. You have taken offence at something I didn't say, because you misunderstood the scope of my comments.
My comment about "selfish extremists" was directed at a small set of editors such as MjolnirPants who specifically announced their intention to create redlinked usercats to "get under the skin" of another editor[3], and promptly created such a category[4] purely to make work for others. One or two other editors behaved similarly deplorably, but as I noted above the vast majority of editors who created redlinked ucats had no such disruptive intent. I tried to be quite clear about that, and am sorry if my wording wasn't clear enough.
I did not invent the notion that a redlinked category is an error. It is inherent to the nature of the category system, and is a long-standing point of WP:REDNOT, for the simple reason that the central goal of the category system is to provide navigational links to all Wikipedia pages in a hierarchy of categories which readers, knowing essential—defining—characteristics of a topic, can browse and quickly find sets of pages on topics that are defined by those characteristics. If the category page doesn't exist, that central goal is broken, regardless of the type of category.
As to the 2007 deletion of Category:Gay Wikipedians etc, I can well understand why gay editors were irate about that -- especially since there was no parallel deletion of the categories for Wikipedians by religion, which is significant because religions have played a leading role in the historical persecution of LGBT people. If the ide is to get rid of identity categories, we should be consistent.
However, I'm sure that an experienced editor like yourself is well aware that consensus can be flawed, sometimes badly so. I have long since lost count of he number of really bad consensus decisions I have seen over the years. But the point about consensus is that we don't have to like the outcome, just accept that it stands until overturned. Some issues where I have felt sore about being on the losing side have come right years later, and Category:Gay Wikipedians is one of those which later came right.
So what to do when there is a bad decision? The long-standing principle is Do not disrupt Wikipedia to illustrate a point. Create uerboxes is fine. Mention the grievance in discussions is also fine. Rising the issue at the village pump is fine. There are many other non-disruptive ways of making the point.
But populating redlinked category does have a disruptive effect, by creating an error which clutters up cleanup lists. I have reason to believe that any editors who populated a redlinked Category:Gay Wikipedians had any desire to cause disruption, and I think it is likely that none of them knew of any disruptive effect. But now that the disruptive effect is understood, please don't defend it -- because defending it now, knowing the effects, is WP:POINTy. --BrownHairedGirl (talk) • (contribs) 16:38, 26 May 2017 (UTC)
@EdChem: see this comment of mine. The technical work which BHG thinks is all but impossible is actually very trivial. I wrote that in C# off the top of my head in about 45 seconds. I could re-write it in almost any C-type language rather quickly. I could build an interface and set up an offsite tool that WMF would be free to "steal" and incorporate into their code whenever they could. It would not be difficult, unless there is some unknown factor going on with the way categories are stored, or named, or something similar. Even then, it could be done. It would just take longer. But I am highly disinclined to attempt to work with BHG for what should be obvious reasons. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 14:05, 26 May 2017 (UTC)
@MjolnirPants: Writing a few lines of code to exclude categs from one namespace is of course trivial. But this job involves more than that.
I look fwd to seeing:
  1. how a tool can distinguish between a) valid usercats which may be initially redlinked, and b) jokey redcats which are only ever intended to be redlinks
  2. how you intend to persuade WMF to add this extra complexity to the code, or
  3. how an offsite tool can replicate the functionality of Special:WantedCategories, which updates the category count in real time
You first mentioned this months ago. You don't need any involvement with me to set it up. If it's all as trivial as you claim, why can't you show us a working demo to evaluate? --BrownHairedGirl (talk) • (contribs) 14:50, 26 May 2017 (UTC)
why can't you show us a working demo to evaluate? Because I have no interest in doing anything to make your life easier. I've said this before (which you've quoted out of context to fallaciously "justify" yet another personal attack against me). I find your behavior in this matter to be utterly reprehensible and will do nothing to encourage it. Not to mention the fact that there's no need for it, as bluelinked and categorized user cats fixes the problem quite nicely. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 15:48, 26 May 2017 (UTC)
(e/c)Except that it turns Wikipedia into a social networking site to some extent, where users can not only put frivolous categories on their user pages, but can easily see who else is in those cats, and can browse other such cats and their memberships. Anythingyouwant (talk) 16:54, 26 May 2017 (UTC)
So you boast for months that it would be ever-so-easy for you to create a solution to a technical problem ... but when challenged to actually implement it, you refuse because it would help those who seek a solution. Not a very mature response.
The comments by you which I cited were not out-of-context. They show very clearly that you set out to create an error in the category system purely in order to annoy another editor.[5][6]
If you want to call other editors utterly reprehensible, you do well to clean up your own act. That includes cleaning up behavior like your comment to which I responded at WT:UCAT[7], where your response to evidence of flaws in your code was yet more personal attacks. --BrownHairedGirl (talk) • (contribs) 16:50, 26 May 2017 (UTC)
I'll just comment briefly in response to User:BrownHairedGirl's mention of WP:NOTSOCIAL. I don't think that continuing to tolerate humorous redlinks at user pages promotes social networks or cliques or anything like that. In contrast, it seems to me that BHG and other editors have recently set up a system that does do those things by changing those humorous redlinks to bluelinks, see, e.g., Category:Wikipedians who do not feel the need to use the category namespace to convey their feelings of pleasure, annoyance or boredom about the state of the world or about Wikipedia's processes, and who wonder if anyone pays any attention to such things anyway which now enables users to see who else is in the "cat", and to also see a list of the other humorous cats including lists of which users are in those cats. Anythingyouwant (talk) 14:37, 26 May 2017 (UTC)
Maybe what is wanted is a MediaWiki:Wanted-categories-exceptionlist page analogous to MediaWiki:Uncategorized-categories-exceptionlist. Jo-Jo Eumerus (talk, contributions) 15:08, 26 May 2017 (UTC)
That might work, thanks. I hope someone can make such an exceptionlist and then we can be done with this matter. Cheers. Anythingyouwant (talk) 15:21, 26 May 2017 (UTC)
It might work. But as noted before, I'd want to see it in action. The first substantive suggestion I have seen of how to define the exceptions is in MJP's code snippet[8] posted earlier today. As I noted in reply[9], MJP's proposal to exclude categories containing the word "users", "wikipedians" or "editors" is waay too simplistic. It would generate a huge number of false positives. --BrownHairedGirl (talk) • (contribs) 16:59, 26 May 2017 (UTC)
  • I agree with much of what BHG has to say here. While I don't per se oppose a "technical solution" to have these categories not show up in Special:Wantedcategories, I echo BHG's worry that this encourages categories that don't further the encyclopedia to be considered more acceptable, in violation of WP:REDNOT. To me, while I consider the redlinks a problem, I think the bigger problem is that these categories don't help improve Wikipedia and in fact likely impede collaboration. With joke categories allowed, there's no reasonable expectation to be able to use the user category system to go seek out others to improve content. The proper recourse should be deleting them all and removing the users from any that have been deleted, and disciplining those who are disruptively intentionally creating redlinks with no reasonable expectation of improving the encyclopedia. There are various RfCs and other forums discussing these issues. I also take issue with the above allegation that those supporting the deletion of Category:Gay Wikipedians were somehow homophobic. I don't disagree that there have been some double standards in regards to keeping categories, which if that is what you are getting at I would agree that perhaps homophobia plays a role in those that would delete that but keep other similarly situated categories. However, I supported deletion then, I support deletion today, and I'll support deletion 50 years from now - Just as I would support deletion of Category:Wikipedians by religion and all subcategories. In fact, I would delete every user category that does not have a clear and obvious benefit the encyclopedia, and support a standard naming convention such as "Wikipedians interested in collaborating on topics related to x" to be the norm for user categories. We are building an encyclopedia and should be using the category tool to that end - not for jokes, telling people what we like or don't like, etc. We can freely do that on our userpages already, I see no reason to bleed into the category namespace for this sort of thing, especially when it likely has the practical effect of dissuading people who would use to to actually collaborate on content. A true technical solution would not be what is proposed here, but to add a "User Category" namespace. VegaDark (talk) 02:57, 27 May 2017 (UTC)

Can we please keep this discussion focused on the technical request? This is VPT. The link to the RFC is below, if you would like to discuss the categories themselves. Thanks. – Jonesey95 (talk) 05:49, 27 May 2017 (UTC)

The guideline should answer this question[edit]

We have a guideline at Wikipedia:User categories#Overcategorization (substantially duplicated or forked at Wikipedia:Overcategorization/User categories) that should provide enough guidance to tell whether these redlinked categories should be created or removed from pages. If it does not provide such guidance, the guideline should be improved. Excluding them from a report is not provided as an option in the guideline. – Jonesey95 (talk) 15:30, 26 May 2017 (UTC)

My request does not involve inserting or deleting any redlinks or any bluelinks related to categories that are jokes/nonsense. The request is merely to modify a tool. Can a redlink really be a category anyway? At most it seems like a request for a category, or a humorous suggestion of a category. Anythingyouwant (talk) 16:13, 26 May 2017 (UTC)
I see one category that has more than one transclusion and is a joke in that report: Wikipedians with red-linked categories on their user talk page‏‎. Are there more red links that you are worried about? If that is the only one, I suggest that you either live with it, or create it (and put a note on the top of the category page that editors should style the link using {{red}} or some other geeky workaround), or go on a crusade to remove those links from user pages (not recommended). – Jonesey95 (talk) 16:20, 26 May 2017 (UTC)
What Report are you referring to? The Wanted Categories Report? BHG and others have turned many of the humorous usercat redlinks into bluelinks or deleted them. In any event, the issue of joke redlinks on user pages is currently a HUGE issue at Wikipedia, and there is substantial support for changing the guidelines so as to turn them into allowed bluelinks.[10] If the tool that I'm requesting is created, the whole controversy may well go away. Anythingyouwant (talk) 16:25, 26 May 2017 (UTC)
"A HUGE issue".. sorry, but most people won't lose a night of sleep over it. Huge in your point of view, but there is something "huge" in every single contributors view and together that makes up thousands of issues. And still everything sorta still work. Let's keep a bit of perspective :) —TheDJ (talkcontribs) 17:29, 26 May 2017 (UTC)
All I meant is that the RFC I linked to is huge. Just count the words. Jonesey95 was saying it involves one measly redlink, which is incorrect. I have sleep problems, but not because of this.🙂 Anythingyouwant (talk) 17:50, 26 May 2017 (UTC)
I am surprised that you did not link to that 32,000-word discussion in your original request. It would have helped provide some context for your technical request, and it may have reduced the amount of policy-related back and forth that has been forked onto this page from that discussion. In my experience, following guidelines like WP:MULTI has gotten me better results with less friction, especially from people who haunt the village pumps. I wish you luck with your quest, and thank you for working to clean up the wanted categories list. Having worked on Special:WantedTemplates myself, I know it can be a thankless and never-ending project. – Jonesey95 (talk) 19:17, 26 May 2017 (UTC)
Thanks. That RFC did not ask about improving the Wanted Categories Report, and so it did not seem useful or necessary to mention it initially. Anyway, I look forward to seeing if anyone here can help with my initial request above. Cheers. Anythingyouwant (talk) 20:36, 26 May 2017 (UTC)

Top images and infobox, no longer appear at top of article on mobile[edit]

This just started to happen today. I don't know if it's a glitch or a deliberate design change, but if it's the latter I'm not a fan. It's incredibly jarring to read about a game and then get through the intro only to have to scroll through the infobox. --Deathawk (talk) 04:21, 26 May 2017 (UTC)

Hi Deathawk. There is some info above. Here is the thread Wikipedia:Village pump (technical)#Infobox placement in mobile view to save you a little scrolling. MarnetteD|Talk 04:29, 26 May 2017 (UTC)
Why the need to scroll through? For me, the infobox is closed, so a a single line, easily skipped. Having said that, I'm talking mobile view on a mobile, not the mobile view on a desktop, which is different.--S Philbrick(Talk) 21:34, 26 May 2017 (UTC)

Help with Collapsible list in Basque Wikipedia[edit]

Hello! We have been using {{collapsible list}} in Basque Wikipedia for a while, and I have noticed that is not working anymore. You can see the effect in an infobox, for example at eu:Steven Spielberg. The module and template haven't been touched, so I think the problem is elsewhere. Could someone help us with this? Thanks! -Theklan (talk) 10:07, 27 May 2017 (UTC)

It seems that eu:Common.js was outdated. -Theklan (talk) 12:52, 27 May 2017 (UTC)
(I presume you mean eu:MediaWiki:common.js) Pppery 12:55, 27 May 2017 (UTC)

Enable wizards for links, formatting, tables, citations, and the search and replace function[edit]

Special:Preferences#mw-prefsection-editing

"Enable wizards for links, formatting, tables, citations, and the search and replace function"

Can this be broken up in preferences? I would like to try out the table wizard for now. But not the rest. They just get in the way. --Timeshifter (talk) 05:02, 28 May 2017 (UTC)

Template doc isn't transcluding[edit]

Hi, the doc page for {{X2 review help}} isn't transcluding onto the template page, after I moved the template out of my sandbox where the doc transclusion was working fine.

What I see when I look at {{X2 review help}} is just the arg-less expanded template, followed by a rump blue rectangle at the bottom labeled Template documentation and inviting me to " [Create]" the page. Clicking the 'Create' anchor goes to an edit window filled with the documentation page content. There is also a line at the bottom of the blue box saying, "Please add categories to the /doc subpage. Subpages of this template." where "/doc" is red and has this exact value: "https://en.wikipedia.org/w/index.php?title=Template:X2_review_help/doc&action=edit&redlink=1" but clicking it goes right to the subpage, and clicking the "Subpages" link shows the doc (in blue) as the only subpage, and the blue link works. Somehow, the template page itself is the only one that can't see the doc, and doesn't transclude it. Why? I tried a fresh browser that has never seen that page, so doesn't appear to be a cache issue, at least not locally. Mathglot (talk) 06:06, 28 May 2017 (UTC)

@Mathglot: I purged the template page, and the documentation is now showing. -- John of Reading (talk) 06:10, 28 May 2017 (UTC)
@John of Reading: Thank you. I'll have to add "purge" to my tips page! Mathglot (talk) 06:47, 28 May 2017 (UTC)