Wikipedia

Wikipedia:Village pump (technical)/Archive 168

< Wikipedia:Village pump (technical)
Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Editnotice in mobile view

Tracked in Phabricator
Task T201575
Tracked in Phabricator
Task T201595
Tracked in Phabricator
Task T201596
Tracked in Phabricator
Task T201597

There is an imposed discretionary sanction on Sarah Jeong and if one is editing on desktop, the Template:Editnotices/Page/Sarah_Jeong is very easy to see in the edit window.

We just had someone blow right past that, which led me to wonder if it is visible when editing on mobile. So i looked at the page in mobile view on my iphone, and the notice does not appear.

You can also (not) see this on desktop if you go to https://en.m.wikipedia.org/wiki/Sarah_Jeong and try to edit in mobile view. The edit notice is not there.

How can this be fixed? Jytdog (talk) 17:58, 8 August 2018 (UTC)

Hmmm, interesting. Yeah, I can confirm that, but my philosophy of the mobile skin is that you deserve what you get if you use it :-) Somewhat more interesting is that if I use the mobile app on my phone, and log in with my normal account, if I try to edit Sarah Jeong, I get "This page is protected. Sorry, your account does not have sufficient privileges to edit this page at this time". Which is kind of weird because I'm an admin. Do admin rights not have effect in the mobile app? -- RoySmith (talk) 20:00, 8 August 2018 (UTC)
I think your login failed. I can edit in mobile while logged in, and just did. Jytdog (talk) 20:06, 8 August 2018 (UTC)
 
 
It certainly looks like I'm logged in. I just logged out, logged back in again, and get the same result. -- RoySmith (talk) 20:54, 8 August 2018 (UTC)
That is bizarre. I wonder if it is because your only userright is "admin" and mobile doesn't recognize you as "extended confirmed". Totally guessing. Maybe try giving yourself "extended confirmed" rights and then try again? Jytdog (talk) 00:08, 9 August 2018 (UTC)
This has diverged from the original purpose of this thread. I've opened T201575 in phab. -- RoySmith (talk) 02:10, 9 August 2018 (UTC)
The admin who imposed the DS just did a workaround by showing the editing restriction in a comment: diff. That is not optimal. Jytdog (talk) 20:06, 8 August 2018 (UTC)
My main question would be why? As in why doesn’t mobile show that? Do we have any degree fo control over this or is it set in stone that edit notices don’t display on mobile? This would probably explain a lot of nonsense that goes on elsewhere, and more than one time I’ve said to someone “this was explained in the giant edit notice you should have seen when editing this page” but now it seems maybe they didn’t see it at all, which is just stupid. Beeblebrox (talk) 20:16, 8 August 2018 (UTC)
I looked for a task in phab and didn't see one. Given the existence of a task for "as close to the same workflow on mobile as on desktop" (CBA to look up the task number), I would guess this is just a "we haven't gotten around to it yet" and not a "we won't be adding these". --Izno (talk) 20:28, 8 August 2018 (UTC)
User:Beeblebrox, I am not the best explainer of this, but its my gleaning that the WMF Reading Team has worked a lot with the software people with the goal of making the presentation of content "light" and clean for people reading on their phones, who are maybe using their cell data. Some stuff "around" the main article content goes away -- no "categories" for example - and there are some different features like "related articles" that I understand are suggested based on articles with similar "description fields" taken from Wikidata.
There is a mission-central aspect to those decisions (making knowledge accessible) but I have been very unhappy with some of their decisions and the way they were made; the most prominent one of those was their decision to stick the "description field" from Wikidata at the top of mobile views (which we got them to stop doing).
I wasn't aware of this particular feature loss until today. I too would like to understand why. Jytdog (talk) 20:32, 8 August 2018 (UTC)
I get the idea of making it “light” for mobile, but in this case it’s removing something fairly important and directly contributing to behavioral problems that the edit notices are specifically designed to curb. Beeblebrox (talk) 20:43, 8 August 2018 (UTC)
I think simply no one really noticed it was missing until now. (which makes me wonder once more about the usefulness of plastering text in front of people out of an expectation that they will actually read it). What probably also didn't help is that many editnotices are multipage blobs of non-scalable HTML crap. The particular linked notice here would take up two lengths of an iPhone 8 screen before you could even reach the edit screen. That is just insane..... we need to think about different tactics here if we want to move this forward. —TheDJ (talk • contribs) 20:58, 8 August 2018 (UTC)
Sorry to ask, but you recognize that the editing community wants it to get in the way, right? I hear you that two lengths of iphone 8 is maybe too much but that would still be better for everyone than leaving mobile users with no notice, in my opinion. Jytdog (talk) 00:02, 9 August 2018 (UTC)
@Jytdog: Oh yes, it's just that the technology was never made to flexibly do this in forms other than Desktop. As such all those components will need to be rebuild every time you want to add it to an app or the mobile website. There is not even an API endpoint able to provide the information that a page has an edit notice. Neither do those notices have any structural information that would allow them to be condensed into a more sensible less noisy medium.
You could say that edit notices are currently a feature of the desktop website, not of the Mediawiki core platform. —TheDJ (talk • contribs) 08:54, 9 August 2018 (UTC)
Created phab:T201595, phab:T201596, phab:T201597. —TheDJ (talk • contribs) 09:32, 9 August 2018 (UTC)
@TheDJ: Oh yes, it's just that the technology was never made to flexibly do this in forms other than Desktop. We have TemplateStyles now. You might have to manually wrap the edit notice's content in <div class="mw-parser-output">...</div> for it to apply, as noted at mw:Extension:TemplateStyles#Caveats. Anomie⚔ 11:58, 9 August 2018 (UTC)
That's not what I meant for that specific point actually (although yes, that might help with some of the ugly html crap). Edit notices really only exist as a deep stack of interface messages. But if your interface (skin, mobile app, or plain api) doesn't use those specific interface messages, then they will not apply. Edit notices are therefor presentation layer elements instead of core elements. They exist by virtue of the skin that uses them, not by virtue of being attached to a certain page. Additionally, they also aren't really edit notices, but actually namespace notices. And then there are BLP notices, which are yet another technology, protection message, etc etc.. It's a cobbled together mess. ;) —TheDJ (talk • contribs) 12:27, 9 August 2018 (UTC)
Thank you for posting to phab. I hope a way can be found to provide these notices to mobile users.Jytdog (talk) 13:37, 9 August 2018 (UTC)
  • User:TheDJ, phab:T201595 was just marked as stalled and if I am correct the trail leads back to this from 2013. I am not sure why one person working on an approach to this, writing "I am not sure, if a rvprop=editnotices is a good idea." and abandoning a patch to do that, is described as a "blocker".... Does this make sense to you? Jytdog (talk) 14:29, 10 August 2018 (UTC)
    It is because the one task needs to be done before the other task can be done. The other (older) task 'blocks' progress on the other task. In other times called a 'dependency'. Solving this ticket is a multiweek task across multiple disciplines, touching one of the ugliest pieces of code of MediaWiki (EditPage). It is not currently scheduled for any team, expect it to take months before people will be able to get around to it. Unless a volunteer picks it up. —TheDJ (talk • contribs) 14:35, 10 August 2018 (UTC)
    Thanks for explaining. Jytdog (talk) 22:57, 10 August 2018 (UTC)

" You are now a Reviewer" tt glitch

I'm not sure if this has been reported, or if this is the best place to report it, but over the last few weeks I've noticed several users with oddly formatted text on almost the entirety of their Talk pages, which can be traced back to a missing forward slash in the "You are now a Reviewer" message, presumably added via an automated template (see for instance this edit. The first line is Hello. Your account has been granted the "<tt>reviewer<tt>" userright, when it should read Hello. Your account has been granted the "{{mono|1=reviewer}}" userright, with closed syntax. As a courtesy I've been fixing the syntax on user's talk pages when encountered, and haven't received any flak (nor thanks), but I imagine it affects quite a few (hundred? thousand?) talk pages. Is this issue still at work? Has the automessage been corrected? And is it worth running a bot to perhaps fix these messages? Thanks. --Animalparty! (talk) 20:55, 12 August 2018 (UTC)

This has since been fixed. --Izno (talk) 21:17, 12 August 2018 (UTC)
This affects a few thousand user talk/talk archive pages, Wikipedia:Bots/Requests_for_approval/Galobot should fix all instances Galobtter (pingó mió) 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. [1]

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. [2]

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)

Acme Mapper has changed

There have been changes to Acme Mapper that affect the interface to it. For instance, if I go to LeVeque Tower and click on the coordinates, if I select Acme Mapper - maps, it is OK. If I select Acme Mapper, satellite it shows a mostly blank screen. However, there is a square in the upper right corner - click on it and select "satellite" and it works. Someone can probably make a small change in the interface to make this work, but I don't know how to do it. Bubba73 You talkin' to me? 16:27, 11 August 2018 (UTC)

@Bubba73: Our coordinates template uses geohack, an external tool, so we can't fix it here on the English Wikipedia. Paging external maintainers: @Magnus Manske: and @Kolossos: who may be able to look in to this. — xaosflux Talk 16:34, 11 August 2018 (UTC)
Additionally, it looks like you can file an external issue report here. — xaosflux Talk 16:38, 11 August 2018 (UTC)
Also if I go directly to satellite view, it will give me the previous one that I looked at. If I go to maps and then select satellite, it gives the correct place. Bubba73 You talkin' to me? 17:01, 11 August 2018 (UTC)
@Xaosflux: seems Kolossos (talk · contribs) isn't active as they last edited in November last year. –Ammarpad (talk) 18:03, 11 August 2018 (UTC)
@Ammarpad: just 2 days ago on dewiki (w:de:Spezial:Beiträge/Kolossos). Perhaps the other maintainer will work on this, there is nothing we can do here at all though (expect for disabling the link to geohack all together / migrate to Kartographer, etc). — xaosflux Talk 18:06, 11 August 2018 (UTC)
Bubba73, Xaosflux, and Ammarpad, please don't make any changes now. In the last week or ten days, they've been making lots of changes, and every day it's different. They just restored the site's capability to show the coordinates of the center and to go to the location specified in the URL (for several days, it always went to the location associated with your IP address), and I'm expecting that the problems reported here will be fixed soon. Nyttend (talk) 02:09, 12 August 2018 (UTC)
@Nyttend: there really isn't anything we can change, this tool is offwiki - most of the other parts of it work so completely disabling it would be a loss to readers - so it should be left up. — xaosflux Talk 04:30, 12 August 2018 (UTC)
Thank you, but I know :-) I meant that no changes should be made to the Geohack template. But I see TheDJ found a good change to make. Nyttend (talk) 11:33, 12 August 2018 (UTC)
@Bubba73, Xaosflux, and Nyttend: Fixed. Geohack uses a locale template for presenting that entire page, which can simply be edited as long as you know the right url. Which I figured out by going to ACME, and getting a 'persistent' (LOL, acme has changed so many times recently) link to a coordinate and comparing it with the same link for a different layer. Turns out they changed the idenfier for their satellite layer (or removed an old one we were still using or whatever). —TheDJ (talk • contribs) 10:29, 12 August 2018 (UTC)
I'm not qualified to mess with it. I contacted Acme, and he said that he has had to make changes. He has to use lower resolution images and I also noticed that the street view is gone. He referred me to this: Acme map updates. Bubba73 You talkin' to me? 16:28, 12 August 2018 (UTC)
And this is why Wikimedia doesn't rely on commercial services like Google. ;) As handy as it might be, can be gone or very expensive tomorrow. —TheDJ (talk • contribs) 18:22, 12 August 2018 (UTC)

Notification section displaying funky numbers

 
Notis on en.wiki randomly deciding to display old messages.

I refreshed a few days ago to notifications saying I had 40 unviewed notis. I actually had only 1. I took a screenshot and forgot about it. Then today I refreshed and saw it displaying the number 16, but when I clicked it was empty, no new notifcations. What is up? Cache? me? the WMF? Thanks, L3X1 ◊distænt write◊ 21:26, 13 August 2018 (UTC)

I occasionally get that. Old notifications of 1 months, 2 months and the like. –Ammarpad (talk) 06:30, 14 August 2018 (UTC)

Tracker on Wikipedia

Hello. I installed Ghostery extension and it detected a tracker on Wikipedia. As Wikipedia doesn't have ads, I was wondering what is this tracker for? Thanks. Vs6507 07:19, 14 August 2018 (UTC)

Don't use Ghostery. Privacy Badger and uBlock Origin (both open-source) each report no trackers for me, so I'm guessing the "tracker" detection might be based on the site setting login cookies or something. Jc86035 (talk) 07:50, 14 August 2018 (UTC)
@VS6507: For various reasons people are tracked. From our own analytics, to making it possible to automatically login on all wikimedia properties once you logged into one, to blocking certain IP addresses and keeping track of presented notices. All done with the utmost precautions to guard a persons privacy. It seems that ghostery features a "anti-tracking" intelligence that automatically detects tracking technologies (no matter how they are implemented). Unfortunately it doesn't seem Ghostery actually lets you see WHAT it has detected. Not much we can do therefore. —TheDJ (talk • contribs) 08:24, 14 August 2018 (UTC)

Edit filter on page moves by admins etc...?

Is there a way of triggering an edit filter, or something like it, on page moves performed by anyone, regardless of user rights?

These reason is that people will move Article Alert pages (e.g. Wikipedia:WikiProject Bradford/Article alerts → Wikipedia:WikiProject Yorkshire/Bradford/Article alerts) without updating WP:AALERTS/LIST. After such a move, the bot will keep posting alerts at Wikipedia:WikiProject Bradford/Article alerts, and Wikipedia:WikiProject Yorkshire/Bradford/Article alerts will remain stagnant and not be updated. Likewise for Wikipedia:WikiProject Bradford/Article alerts/Archive → Wikipedia:WikiProject Yorkshire/Bradford/Article alerts/Archive. Months can go by before this is detected, projects think they've done things right, but they've actually fucked it up and get no delivery [thinking there's simply no new alerts], and then there's a bunch of pages that need to be merged and histmerged.

Ideally I'd want the edit filter to simply block such moves the first time they are done, regardless of user rights, with a big notice saying If you move this page, make sure to update WP:AALERTS/LIST, otherwise the bot will ignore the page move and keep posting alerts here. Headbomb {t · c · p · b} 13:31, 14 August 2018 (UTC)

@Headbomb: to be clear, you only want this "warning" to get triggered for pages that are:
  1. In the Wikipedia: namespace
  2. During a move action
  3. Where the page title includes "Article alerts"
correct? — xaosflux Talk 14:00, 14 August 2018 (UTC)
Correct. Or rather pages with Article (A|a)lert in the title. Headbomb {t · c · p · b} 14:05, 14 August 2018 (UTC)
@Headbomb: that sounds feasible, at can at least get tried with a "log only" mode to see what would get hit. Put the specifics over at Wikipedia:Edit filter/Requested and someone can write it up. — xaosflux Talk 14:07, 14 August 2018 (UTC)

Find/replace tool disappeared?

Hi all, three days ago, my edit window had a Find/Replace tool built into it. (Desktop version) It was activated in the upper right corner or the edit window, near the View Source/Visual Editor selector. Any idea where this went? Was this a beta tool or something? I need it! It was useful! Thanks, Cyphoidbomb (talk) 14:09, 14 August 2018 (UTC)

Try clicking the "Advanced" button/drop down on the top bar Galobtter (pingó mió) 14:15, 14 August 2018 (UTC)
@Cyphoidbomb: while in visual editor, with something in the edit window selected, press CNTRL-F , or click on the "three lines" icon on the top right. — xaosflux Talk 14:21, 14 August 2018 (UTC)
Aw geez, I'm an idiot. Galobtter saved me. Thanks both of ya! Cyphoidbomb (talk) 14:23, 14 August 2018 (UTC)
Hah, I figured it was that because I've often spent way too long trying to figure out the same Galobtter (pingó mió) 14:45, 14 August 2018 (UTC)

Page curation glitch

Tracked in Phabricator
Task T169441

For some reason, when Meatsgains (talk · contribs) nominated Digiview Entertainment for deletion via Page Curation, it appended the AFD to the bottom of the previous one from 2009, instead of creating it as a "(2nd nomination)" page. I'm not familiar with how Page Curation works, so is this a known glitch? Ten Pound Hammer • (What did I screw up now?) 23:04, 14 August 2018 (UTC)

This is a known issue. (phab:T169441) — JJMC89 (T·C) 01:58, 15 August 2018 (UTC)

Can we make it easier to move deleted (or non-deleted) edits?

Tracked in Phabricator
Task T23312

Sometimes edit histories need to be cleaned up, particularly where it is discovered that an article has a lot of edits from an old improperly done cut-and-paste page move, or where an article is deleted, an article on a different topic happens to be written at the same title, and then the deleted article returns under a different title, with content that resolves whatever cause the initial deletion. Whatever the reason, there are sometimes circumstances where a block of edits in the current or deleted history of an article needs to be moved to a different title.

Currently, the way this is usually done is to:

1) delete the existing article, then
2) undelete the portion of the edit history to be moved, then
3) move the page generated by that undeletion to whatever the correct title is, without leaving a redirect then
4) undelete the edit history to be kept with the original title, and possibly
5) undelete any new edit history overwritten by the move of the old edits.

Occasionally all of this is complicated by the existence of deleted edits that need to stay deleted (such as periods when a copyvio was on the page). I can't put my finger on specific examples right now, but I would bet that User:Anthony Appleyard (who frequently cleans up such matters) can. What I would like it to able to just:

1) check off a block of edits in the edit history of an article (whether existing or deleted), and
2) move that block to the edit history of another article (without needing to delete/undelete anything).

Given the potential for some abuse, this would need to be an admin right. bd2412 T 00:38, 15 August 2018 (UTC)

  • @BD2412:
    • Lack of selective delete has been on Wikipedia's bug list for a while now. Always I must delete all edits and then undelete some edits. It wastes link time and Wikipedia's server's time, and as above.
    • Coping with pre-existing deleted edits has complicated my history-merging since I started history-merging.
    • I agree: we need selective move of non-deleted edits, and selective or nonselective move of deleted edits while keeping them deleted.
    • Anthony Appleyard (talk) 04:57, 15 August 2018 (UTC)
      • Frankly, I can't understand why this would be at all difficult to implement. We can already delete individual edits. bd2412 T 11:17, 15 August 2018 (UTC)
    • Yeah, it's been on the bug list for nearly nine years. I agree that such a feature would be very, very useful. Graham87 05:26, 15 August 2018 (UTC)

SineBot

Just noticed SineBot hasn't been active since 31 July. I've told Slakr, but I know he's not around much to give it a prod these days. Can anyone else help? I really think we need to get these bots in-house, or at least make them all open source so somebody else can take over them if necessary. Ritchie333 (talk) (cont) 18:34, 11 August 2018 (UTC)

Hopefully SineBot returns since it's well developed .. but if not... the new EventStreams can be used get revision ID's of Talk: edits ie.
curl -s https://stream.wikimedia.org/v2/stream/recentchange | grep -F data | sed 's/^data: //g' | grep -F '"domain":"en.wikipedia.org"' | grep -F '"title":"Talk:' | jq .
-- GreenC 21:10, 12 August 2018 (UTC)

@Ritchie333: SineBot is back, good thing. It does bring up long-term issue of need to open-source bots. -- GreenC 17:45, 15 August 2018 (UTC)

Media height and width

Can I specify both a height and width for an image? Something like [[File:Famagusta 01-2017 img10 Carmelite Church.jpg|thumb|right|100px|50px]]? Thanks. SharkD  ☎  03:00, 14 August 2018 (UTC)

The only case I know of is Template:Annotated image, which basically lets you dynamically crop and zoom an image. Chris857 (talk) 03:14, 14 August 2018 (UTC)
Note that if you set both the height and width, you will mess up the aspect ratio. Bubba73 You talkin' to me? 03:35, 14 August 2018 (UTC)
@SharkD: If you always want to preserve aspect ratio, simply use the widthxheight syntax as described Wikipedia:Extended_image_syntax#Size. —TheDJ (talk • contribs) 06:45, 14 August 2018 (UTC)
This is the image I want to stretch a little thinner. Breaking the aspect ratio is not a big deal in this case. SharkD  ☎  07:34, 14 August 2018 (UTC)
I ended up just uploading a new version. Thanks though. SharkD  ☎  07:49, 14 August 2018 (UTC)
@SharkD: The syntax allows us to add a parameter like x100px which sets the maximum height, but we can't alter the aspect ratio like this, as the numbers represent maximum heights and widths, so your work-around is simplest:
[[File:Example.jpg|thumb|100px]] gives an image 100px wide and 108px high, preserving aspect ratio;
[[File:Example.jpg|thumb|x100px]] gives an image 93px wide and 100px high, preserving aspect ratio;
[[File:Example.jpg|thumb|100x100px]] gives an image 93px wide and 100px high, preserving aspect ratio;
Note that using the thumb parameter disables upscaling of jpg images, so
[[File:Example.jpg|thumb|1000x1000px]] only produces an image 275px wide and 297px high, the 'natural' size of the file. --RexxS (talk) 19:00, 15 August 2018 (UTC)

Special:BookSources at htwiki

The Haitian Creole Wikipedia has nothing like out Wikipedia:Book sources; it just has a very simple page at Special:BookSources that provides links to four possible places to locate books. These links are dead or otherwise non-functional. See this example: https://ht.wikipedia.org/wiki/Espesyal:SousLiv/2-86741-008-8

I can't find the page that the links are configured on. The sentence at the top is w:ht:MedyaWiki:Booksources-text, but the links themselves don't reveal their location with the mw:qqx trick. Does anyone know how to fix this? WhatamIdoing (talk) 16:54, 15 August 2018 (UTC)

The instructions are here: mw:Manual:ISBN. ht:Project:Book sources needs to be created. Ruslik_Zero 19:37, 15 August 2018 (UTC)
@WhatamIdoing: See mw:Manual:ISBN referring to Project:Book sources or another page defined in MediaWiki:Booksources. —TheDJ (talk • contribs) 19:48, 15 August 2018 (UTC)

Problem accessing Eudora (email client)

I fielded two different inquiries at OTRS from readers with problems accessing an individual article. I'm not yet convinced they are related so I'm going to discuss them separately.

In one case ticket:nnnnnnnnnnnnn they attempted to access a page. The person accessed it indirectly, by first going to:

  • Eudora then clicking on the link to Eudora (email client) on that page

The result was a white screen which they interpreted as an attempt to load but a failure to properly render.

I asked thwm to let some time pass, and to try again to see if it's a momentary glitch.

They are using Safari on a Mac.

I made a complete copy of the article and placed it in my sandbox:

They reported that they can load that article fine, which suggests to me that it isn't anything about the particular code in that particular article. They still have the same problem trying to access from the link at the disambiguation page


Any thoughts on next steps?--S Philbrick(Talk) 13:18, 15 August 2018 (UTC)

@Sphilbrick: can they get to the page if they input the URL (https://en.wikipedia.org/wiki/Eudora) in to their browser directly? Can they go to other disambiguation pages (e.g. https://en.wikipedia.org/wiki/0_series)? Can you verify the browser version? — xaosflux Talk 13:36, 15 August 2018 (UTC)
I shared a link to this discussion with them, I will encourage them to answer directly, or get the answers.--S Philbrick(Talk) 13:39, 15 August 2018 (UTC)
The problem appears to be solved - from the custoemr:
The Eudora link was always okay, still is, other test dismbiguation link from case record also okay, copy/paste link also okay. Today, everything seems fine in all cases, so I may never understand. I can add that I’ve never had a problem with a wiki article before, like, ever.
I relaunched and dumped cache yesterday, so that should have been consistent too, but I turn my computer off when not in use and don’t know how that single change might have enacted something. TCP/IP was certainly fine for other uses. I wonder if somebody like IP=Shaw is mid-stream caching, and the failed cached got dumped overnight?
But if anyone has any ideas what might have been the problem, please share.--S Philbrick(Talk) 22:07, 15 August 2018 (UTC)

Position of help links

On some sets of pages, there is a link to help about using the page towards the upper-right of the page. Some are generated by the WM software, while others are created on-wiki by various templates and standard layout methods. These two approaches give different results, both in terms of placement compared to other displayed content and for visibility for mobile users.

In the first case, we have pages in Special: namespace. These have "◯? Help", where the circled-questionmark is embedded SVG data. Thanks to User:MER-C for tracking down the addHelpLink function and CSS for its layout. In the second case, we have pages at the ref-desks (e.g., Wikipedia:Reference desk/Science) and the other help-desks (e.g, Help:Contents), where custom icons (commons files) are displayed via {{RefDesk help icon}} and {{HelpDesk icon}}. The MW ones are not displayed on mobile view and are not controllable on-wiki. The template ones display on mobile in a way that overlays other elements (see 1 and 2). Both of those are sub-par...we want to have en.wp-centric help available and controllable locally and that is visible cleanly on mobile.

I'm going to unify the two ...icon templates to {{Page help link}} and retain User:PrimeHunter's id= tag to allow hiding via user CSS. Do we want to hide it for all mobile users (via site CSS)? Is there a way to set its class/id to use the MW one's CSS rather than hand-coding a comparable positioning? I tried and couldn't. Is there a way to get the mobile help icon visible and moved a bit to not overlap other things? DMacks (talk) 06:09, 16 August 2018 (UTC)

Kennedy Space Center Launch Complex 39

Hi guys,

In the section "Launch history" of this article, there is a graph about the launches. The figures on the left are the number of launches. It looks very strange that the numbers used are 2.5 then 5 then 7.5 and so on. There will never be 2 launches and a half so I guess it would make sense to use 2, 4, 6 and so on. I don't want to mess up the graph so if anyone is good at it, thanks for doing it! Ericdec85 (talk) 03:00, 16 August 2018 (UTC)

Link: Kennedy Space Center Launch Complex 39#Launch history. It requires a Lua coder for Module:Chart unless you somehow change the largest number in the data to at most 10 (gives intervals of 1) or at least 16 (gives intervals of 5). It's currently 12 for 2017. There are requests at Module talk:Chart#Y scale and Module talk:Chart#Whole numbers in bar chart Y axis. PrimeHunter (talk) 09:21, 16 August 2018 (UTC)

Hmm, I remember using that module years ago in a non-wikimedia wiki. It is still just as badly documented as it was back then, considering that it still probably uses an SVG image hack for pie charts, it might be better to use the graph extension. In any event, in its current state that module should just be discontinued especially due to its limited use in ~300 pages. Not only does it insert a massive number of inline styles that will not properly render on mobile devices, it can also cause these overlap problems with labels even on desktop devices.

One could resolve this particular problem in a nuclear way by hiding all Y labels for those particular charts, by replacing line 374, e.g.: 

  local modGraphYScales = (val == math.floor(val)  ) and "modGraphyScalesInteger modGraphYScales" or "modGraphyScalesFloat modGraphYScales"
                local div = mw.text.tag( 'div', { style = string.format( valStyleStr, width - 10, y - 10, color ), class = modGraphYScales }, mw.getContentLanguage():formatNum( tonumber( val ) or 0 ) )

Then it becomes a simple matter of hiding it with templatestyles. A more interested lua person could make it work using a template parameter. 12:53, 16 August 2018 (UTC) — Preceding unsigned comment added by 197.235.100.35 (talk)

A different page load problem

As mentioned in the post above, I also received an inquiry ticket:2018081410008025 yesterday about a page not loading. I felt the facts felt sufficiently different from the case above that I'm writing this is to separate posts.

In this instance the problem was accessing this page:

I thought it was relevant that this is a larger than average page at about 350 K. As a separate matter we might consider urging a subdivision into multiple articles but I'll leave that for others.

My usual response when someone indicates they have trouble accessing an article is to ask them to try again later because it's my experience that we sometimes have momentary glitches and I don't want to ask people to be doing a lot of research if the problems simply goes away by trying again later.

In this particular case they indicated that they had checked with some friends in multiple countries on multiple continents all of whom had the problem. I asked them to try again today and this is the report:

Hi, we tried to load the page today again and here are the results. I can access the page both on pc and mobile from Poland but my Dutch friends still can't see it. NY friend can load both versions of the page just fine but the one in Morocco can only use the mobile version.

I still wonder if the page size is contributing to the problem but any other thoughts?--S Philbrick(Talk) 16:24, 15 August 2018 (UTC)

Customer added - Chrome ver 68.0.3440.106 64 bit --S Philbrick(Talk) 17:34, 15 August 2018 (UTC)
There have been attempts to reduce the size of this page by tightening criteria for inclusion, but soon enough new entries get added so it's whackamole. Probably it needs to be split into separate articles by date. -- GreenC 13:16, 16 August 2018 (UTC)

Add a feature for logged in users in the account preferences to have the system Auto-sign messages.

Hello, I request that in the future there should be a feature implemented for logged in users in their account preferences to be able to enable/disable a setting in order to have the Wikipedia system Auto-sign a person's message with their signatures regardless if it functions as a bot or not. I know nothing about programming so I can't give any specific details on how it could be implemented but if it's possible to add a feature like that. I would appreciate it because I keep frequently forgetting to click on the Signature and Timestamp button or type 4 tildes to sign it since signatures it not something that is my main priority whenever I'm typing a message as I assume the system does it for you as I just type the message. From what i understand, using SineBot by requesting to use the bot yourself by adding programming - or requesting to have someone else do it if you know nothing about programming isn't an infallible solution as it's bound to make lots of mistakes. As long as it's possible to implement, I'd love for that to be added so I don't have to keep seeing "Preceding unsigned comment added by {Username Here}" if I forget to manually sign it. It's just a trivial suggestion for newcomer editors to save time and make it easier I think I recall seeing that happen with many other fandom wikia sites that I used depending on the site and the programming. --Mkikoen (talk) 17:54, 15 August 2018 (UTC)

I think the Structured Discussions project kind of covers all or some of that. I know it was trialled here in 2016 to a pretty lukewarm to negative response, and turned off. Scott might have more of an idea on the specifics. Ritchie333 (talk) (cont) 21:10, 15 August 2018 (UTC)
Mkikoen (talk · contribs) had previously been posting on this matter at Wikipedia:Bot requests#Request for someone to run SineBot for me. --Redrose64 🌹 (talk) 08:12, 16 August 2018 (UTC)
  • @Mkikoen: this is not technically feasible to include with edits in general, because there is not a system concept of this is a batch of text where I am discussing something. Even in namespaces where you think it might apply, there are many exceptions. For example, right now we are editing Wikipedia:Village pump (technical). If I just hit save now it might be useful to insert a signature at this point in the text. But if I wanted to go correct a typo, add a template or image to the page, etc it would be inappropriate to insert a signature anywhere. Even on pages like article-talk where a primary activity is discussing, people also make other types of edits like adding project banners that should not be signed. — xaosflux Talk 13:44, 16 August 2018 (UTC)

template/module output, MediaWiki, and the newline character

At Template_talk:Lang#BUG:_Current_template/Module_does_not_support_multi-paragraph_usage..., and editor complained that {{lang}} creates malformed html when given text that contains paragraphs defined by \n\n because <p>...</p> does not belong inside <span>...</span>. I thought to correct that by detecting the \n\n sequence and using that detection to switch from <span>...</span> to <div>...</div> but the results are perplexing.

In plain text, when we write this: 

first line
second line

third line

MediaWiki makes this html: 

<p>first line
second line
</p><p>third line
</p>

and it renders like this:

first line second line

third line

So that is what I expect from this (except italicized because the 'text' contains all Latin characters and is 'non-English' per MOS): 

{{lang/sandbox|de|
first line 
second line

third line}}

Module:lang/sandbox produces this html: 

<div lang="de" title="German language text"><i>first line  second line</i>

<i>third line</i></div>

from which MediaWiki makes this: 

<div lang="de" title="German language text"><i>first line  second line</i>
<i>third line</i></div>

and that, renders like this (no line breaks):

first line second line

third line

To make things even stranger, from this (no \n\n sequence): 

{{lang/sandbox|de|
first line 
second line
third line}}

Module:lang/sandbox produces this: 

<i lang="de" title="German language text">first line 
second line
third line</i>

from which MediaWiki makes this malformed html (<p>...</p> inside of <i>...</i>): 

<div style="margin-left:1.6em"><i lang="de" title="German language text">first line
<p>second line
</p>
third line</i></div>

and that, renders like this:

first line

second line

third line

This should have rendered as the first example because no \n\n to imply <p>...</p> shouldn't it?

But then, from this (using \n\n sequences): 

{{lang/sandbox|de|
first line 

second line

third line}}

Module:lang/sandbox produces this: 

<div lang="de" title="German language text"><i>first line </i>

<i>second line</i>

<i>third line</i></div>

from which MediaWiki makes this html: 

<div lang="de" title="German language text"><i>first line</i>
<p><i>second line</i>
</p>
<i>third line</i></div></div>

and that, renders like this:

first line

second line

third line

What is it that I'm not understanding about how newline characters are handled? Is MediaWiki working correctly in all of the above cases?

A simple experiment showed me that I can replace \n\n sequences in the template's text input with <p>...</p> markup and replace single \n characters with a space character to mimic how they are handled in plain text, but should I have to do that?

Is newline character handling in MediaWiki documented anywhere? Is there some fundamental something about html that I'm not understanding?

—Trappist the monk (talk) 12:33, 15 August 2018 (UTC)

@Trappist the monk: How many cases of this problem are there ? What about simply forbidding paragraphs as input for this template ? And have we considered simply always turning them into divs and then always using "display:inline" ? Seems much simpler. These hacks to parse and interpret wikicode are really scary and not what Lua was intended for. I also note a tendency of late to make every template do everything at the same time. That's not a good idea in general. Use different templates for different usecases and then make them share the same Lua core if advantageous. Hell this entirely template is nothing more than a lang="en" attribute for people afraid of HTML rly, we hardly even need it to begin with. —TheDJ (talk • contribs) 13:58, 15 August 2018 (UTC)
I mean if we need 1180 !!!!!! lines of Lua to properly generate a simple language attribute then we are doing something seriously wrong. We need to step back and reassess, because if we start doing that for all 9 character sequences of the encyclopedia, then soon it will break down under its own weight. —TheDJ (talk • contribs) 14:06, 15 August 2018 (UTC)
The module is doing work for a series of templates, not just the single template {{lang}} (someone clearly just counted lines instead of reviewing the documentation in the module ;). It also validates the language tag and applies various MOS rules, one of which is italics for certain non-English content--the best HTML tag for which is <i>. However, <i> can only appear in certain places in HTML, so Ttm is attempting to hack around by the craziness of the above. There are a number of cases for block display of non-English languages, especially poetry and lyrics, from what I have observed in the wild (they pop up where {{lang}} is used around e.g. <poem> in the associated Linter category). However, I'm about to the point where we should probably abandon the use of <i> in the block case and have the user explicitly provide a |display=block or similar as the less common use case of {{lang}}. The template can then just error check for as much block content as possible and ask the user to reconsider what he's doing with the template, instead of trying to get it right as above. --Izno (talk) 16:02, 15 August 2018 (UTC)
I admit that i was trying to push the exegeration button I bit, but I'm growing tired of having to say "don't parse wikicode with lua". :) —TheDJ (talk • contribs) 19:40, 15 August 2018 (UTC)
Just to put some numbers on it: Module:lang directly supports {{lang}}, {{transl}}, and about 700 {{lang-??}} templates. I anticipate that in future, the module will also directly support some 1100 {{ISO 639 name ??}} templates.
Instead of a rant, can I have honest answers to my questions?
—Trappist the monk (talk) 13:10, 16 August 2018 (UTC)

The problem is fully with your lua module and your misunderstanding of newlines / line breaks and their interactions with html tags / parser, see meta:Help:Newlines_and_spaces. The easiest way to prove that is using the {{1x}} template, and maybe special:expandtemplates. It also seems pretty strange to add a <i> tag to each element. If all items need to be italic, then it makes more sense to add the styling based on the attribute to the parent tag instead of individual tags. Generally speaking, as noted above, it makes very little sense to have a catch all template to add the lang attribute. Also if all items with the lang attribute need to be italic, it might make more sense to use sitewide css to style it instead. 13:10, 16 August 2018 (UTC)— Preceding unsigned comment added by 197.235.100.35 (talk) 13:11, 16 August 2018‎ (UTC)

I'm not surprised that I don't fully understand newline handling; that is, after all why I posed the questions. Thanks for the link.
You are wrong in your interpretation of what Module:lang does. Please read the documentation; you might even read the comments in the code – there is a reason why I comment my code. Also read the discussions about this module at Template talk:Lang.
Editors complained when we used the font-style=italic attribute so we went back to the <i>...</i> html tags.
—Trappist the monk (talk) 13:30, 16 August 2018 (UTC)
Ohh, it also does some validation. It still doesn't change the fact that there is 0 need to add italic tags to every line. You're essentially going to have to fight with the parser to get what you want, which is pretty awful considering that lua doesn't have a library to fetch the html parser output. Templates also add a newline whenever they are transcluded, and probably other crazy tools. As far as the problem of having to override it with !important, it is a weak complaint considering that they are already going out of their way to override site css. Either way there are plenty of ways to address such a complaint. The simplest is using css specificity developer.mozilla.org/en/docs/Web/CSS/Specificity. Alternatively, if it is added through good practices like a class or even defined using the lang attribute (developer.mozilla.org/en-US/docs/Web/CSS/:lang), editors should always be able to override it using their css. It can be done using sitewide css, templatestyles, or any number of simpler ways. 197.235.100.35 (talk) 14:07, 16 August 2018 (UTC)

The 1 won't go away

Maybe this has been reported. I got a notification (which I shouldn't have) that someone signed in to Wikipedia. Of course I did because I had articles to improve at a library I don't go to that often. I went to the page and the 1 is still there.— Vchimpanzee • talk • contributions • 15:23, 15 August 2018 (UTC)

@Vchimpanzee: try to go to Special:Notifications an see if you can clear it from there. — xaosflux Talk 15:33, 15 August 2018 (UTC)
Thanks. I may have gotten that response before.— Vchimpanzee • talk • contributions • 15:57, 15 August 2018 (UTC)
You mean it isn't normal to have notifications and alerts both saying "99+"? Natureium (talk) 18:34, 15 August 2018 (UTC)
@Natureium: That is not normal. The normal is to mark them as read and then there shouldn't be any number afterwards. See mw:Help:Notifications/Special:Notifications#Notifications list. Some notifications are automatically marked as read if you click them. PrimeHunter (talk) 19:50, 16 August 2018 (UTC)

Watchlist only displaying 7 hours

Something happened today, and my watchlist only displays 7 hours worth of edits. I have it set for 3 days. I haven't made any changes. Not sure what happened, is there anything I can do? Work permit (talk) 18:58, 16 August 2018 (UTC)

Help:Watchlist#Options can adjust a maximum number of messages to display. I've occasionally had a busy day and increased it. Jim.henderson (talk) 19:01, 16 August 2018 (UTC)
Thank you. I did look at that. It's set at 3 days, 250 changes. I haven't touched it. Work permit (talk) 19:44, 16 August 2018 (UTC)

I figured it out. I recently had turned off the filter for "latest edit". Some pages I have on my watch list generate a large number of changes. So the 250 change limit kicked in. Work permit (talk) 19:56, 16 August 2018 (UTC)

Page Previews as a pure JavaScript API for use in external sites

Hello! I have a personal blog that includes many Wikipedia links. I would like to make use of the Page Previews functionality on those links, but the info I found (such as https://www.mediawiki.org/wiki/Extension:Popups) insists on server side php files and control. Since I am hosting my blog on Blogger, I would like the option of an all JavaScript API to use. Is there something like this available?

Thank you! Siderite (http://siderite.blogspot.com) — Preceding unsigned comment added by 188.27.124.98 (talk) 10:03, 15 August 2018 (UTC)

Hi there. Popups is written as a PHP and JavaScript extension for MediaWiki, the software that powers Wikipedia. The PHP code in the extension is unrelated to the actual task of displaying page previews; for example, there is PHP code to add a preference to the preferences page that allows wiki users to disable page previews. It is possible to compile all the JavaScript code into one file (see the end result here and instructions in the README), but you would need to manually remove references to MediaWiki-specific JavaScript objects and functions, which could be a substantial task. — This, that and the other (talk) 11:29, 15 August 2018 (UTC)
Actually there is a proof of concept of a standalone version (made by WMF engineers) available on GitHub. —TheDJ (talk • contribs) 11:51, 15 August 2018 (UTC)
Hah, nice! — This, that and the other (talk) 01:07, 17 August 2018 (UTC)

That is exactly what I was looking for. I've implemented the joakin/context-cards project and it works as a charm. Thanks! Siderite — Preceding unsigned comment added by 188.27.124.98 (talk) 20:58, 16 August 2018 (UTC)

Listas parameter issue

I've noticed this issue on several pages now, but I'll use Talk:Paul Linden as an example. It has the WikiProject Biography tag, but it has no listas parameter within that tag. This means that it should be showing up here, but it's not. Can someone explain why this is the case? I've been working on the backlog in that category for a while, and now I'm concerned that there might be a bunch of other pages that should be in the category but aren't. Lepricavark (talk) 18:32, 15 August 2018 (UTC)

I made a null edit and it shows now. Ruslik_Zero 19:40, 15 August 2018 (UTC)
Ok. Is there any way of knowing how many other articles need listas parameters but aren't showing up in the backlog? Lepricavark (talk) 19:43, 15 August 2018 (UTC)
@Lepricavark: There are two issues here. Whether there's any other problem that's preventing them from showing up in the category or whether it is only problem of caching which is now solved with null edit. If it is the former, then we need to have example of a page that's still not showing up despite the null edit. –Ammarpad (talk) 05:12, 16 August 2018 (UTC)
@Ammarpad: I've been unable to create an example of such a page, so I guess there's not much more we can do. Thanks for your assistance. Lepricavark (talk) 14:44, 16 August 2018 (UTC)
Before making a null edit, you can try adding "?action=purge" to the end of the page URL (that is, https://en.wikipedia.org/wiki/Category:Biography_articles_without_listas_parameter?action=purge) in order to force the page to be refreshed. isaacl (talk) 17:39, 16 August 2018 (UTC)
@Isaacl: A purge will only refresh the page text; it will not rebuild the category table entries. After a purge, the correct categories may be shown at the bottom of the page, whereas the page may not be listed in the category. A null edit will force synchronisation. --Redrose64 🌹 (talk) 08:43, 17 August 2018 (UTC)

Template:Archive top huge spacing problem on mobile

Template:Archive top leaves a huge amount (multiple screens) of blank space (shaded purple by the default background color of the template) between its result= argument and the actual discussion being archived by the template on the Chrome browser on an Android smartphone (there is no such problem on Chrome when I tested on a Windows laptop). For an example, see any archived topic (topic to which the template has been applied) in Wikipedia:Administrators' noticeboard/Archive300. —Lowellian (reply) 00:32, 2 August 2018 (UTC)

I can confirm the same on my device on mobile Android in Chrome. Firefox does not have an issue that I observed (but I wasn't being particularly observant). --Izno (talk) 01:40, 2 August 2018 (UTC)
This has been happening since phab:T160946. Since we now have template styles, we should get the overrides on quotebox removed and then setting it directly from {{quotebox}}. —TheDJ (talk • contribs) 05:28, 2 August 2018 (UTC)
@TheDJ and Anomie: Thank you, TheDJ, for the preparatory edits made at Template:Quote box/styles.css. Any idea of a timeline for when the full changes can be made and the spacing fixed? —Lowellian (reply) 18:54, 10 August 2018 (UTC)
@Lowellian: the patch to remove the quotebox styling in the server software was merged a day ago. So should arrive in the next deploy train, which for en.wp is on thursday. —TheDJ (talk • contribs) 19:40, 10 August 2018 (UTC)
@TheDJ and Anomie: Thursday has passed, but the problem is still there... —Lowellian (reply) 14:24, 17 August 2018 (UTC)
@Lowellian: Apparently wikitech:Deployments#Week_of_August_13th there were no deploys this week, because there was a WMF holiday. —TheDJ (talk • contribs) 14:59, 17 August 2018 (UTC)
Also in mobile view in Chrome, Firefox and Safari on Mac, in case it matters. But not in every archived topic in the example WP:Administrators' noticeboard/Archive300, just some of them. --Pipetricker (talk) 11:32, 2 August 2018 (UTC)
Ah, okay, thank you, I see. The problem isn't occurring specifically with Chrome for Android, but instead for any browser on the mobile version of Wikipedia. —Lowellian (reply) 16:37, 2 August 2018 (UTC)

Visibility of page issues on mobile view

I think we need better visibility of page issues on mobile view. Compare, e.g. https://en.wikipedia.org/wiki/Covert_hypnosis and https://en.m.wikipedia.org/wiki/Covert_hypnosis -- on desktop view, readers are duly advised that this page may need to be taken with a grain of salt, but on mobile it's too easy to overlook the tiny bit of grey text that opens three screenfuls of warnings. Daß Wölf 04:45, 17 August 2018 (UTC)

@Daß Wölf: What you're seeing now is as a result of huge improvement done by WMF's Reading Team recently. I am not sure whether they're thorough, but you can still give feedback at the project's talk. However, keep in mind that these templates will never be fully expanded on mobile view, like they're on desktop view, for several reasons. –Ammarpad (talk) 09:15, 17 August 2018 (UTC)
If you are seeing a small gray link that says "Page issues", that is being phased out in favour of the newer solution mentioned by Ammarpad above. — This, that and the other (talk) 11:02, 17 August 2018 (UTC)
Yeah, that looks better. I don't know how long the small grey link has been around but I haven't even noticed it until yesterday. Daß Wölf 18:39, 17 August 2018 (UTC)

"C" keyboard shortcut broken on Portal pages

Is the "C" keyboard shortcut (usually alt+shift+c) broken on Portal-namespace pages for anyone else? Enterprisey (talk!) 01:30, 17 August 2018 (UTC)

What is it supposed to do? --Redrose64 🌹 (talk) 08:43, 17 August 2018 (UTC)
@Redrose64: Alt-shift-c is the usual shortcut for the article tab (like alt-shift-t is the talk/discussion page tab, alt-shift-h the history page tab, etc.) --RexxS (talk) 20:30, 17 August 2018 (UTC)

Inter-template linkages must be documented at both ends

A major frustration when trying to de-lint, debug, or just understand templates is when a <div>, <table>, or {| is opened in one template and not closed there. One wonders whether it is an error or whether some other template closes it. I believe that, whenever a template intentionally has unclosed one or more tags that are closed elsewhere, or one or more closing tags that intentionally close a tag opened elsewhere, there should be a mandatory HTML comment saying that the tag is intentionally missing its pair and where the opening or closing tag is located. Not doing this is worse, for example, than mixing mdy and dmy dates or using bad punctuation, because those, at least, can be trivially fixed, but Wikipedians can study this kind of bad coding for hours. —Anomalocaris (talk) 00:01, 8 August 2018 (UTC)

It would actually help VisualEditor if this was not just a comment, but some kind of machine-readable tag or code, to show that the template contains partial markup. I wonder if Cscott has any thoughts on this — This, that and the other (talk) 02:32, 8 August 2018 (UTC)
@This, that, and the other: phab:T114445? :) --Izno (talk) 02:44, 8 August 2018 (UTC)
I am pleased that there is some interest in this topic. According to
Outstanding linter errors on enwiki, there are 6,825 missing end tag lint errors and 4,404 stripped tags lint errors (closing tags without paired opening tags) in the Template namespace. Here are the lists:
There are numerous very likely careless missing end tags for <p>, <i>, <small>, <font>, but also plenty of intentional missing end tags for <table> and <div>.
A related problem is templates that have table row markup with either or both of <table> and </table> located elsewhere.
Here are some among probably thousands of examples of this problem for templates involving table markup:
<table> <tr> </table>
Portal:Globalization/Header ?
{{S-start}} {{S-break}}
and many others		 {{S-end}}
{{AFC statistics/header}} {{AFC statistics/footer}}
{{OntMPP}} {{OntMPP End}}
{{Graphic novel list/header}} {{Graphic novel list}} {{Graphic novel list/footer}}
{{Begin flag gallery}} {{Flag entry}} {{End flag gallery}}
{{Sumo record box start}} {{Sumo record year start}}
{{Sumo record year end}}		 {{Sumo record box end}}
The first example is where I started. This template is a sub-template of Portal:Globalization, which is messy and I don't know if all table tags are properly paired and if so where the tags are all located.
I wonder if we should start a separate article somewhere for tracking templates with undocumented external opening or closing tags (or unbracketed table row and cell markup), with a column to note that comments have been duly inserted showing the linkages. —Anomalocaris (talk) 09:04, 8 August 2018 (UTC)
For template pages themselves, you can (and should) apply something list this. —TheDJ (talk • contribs) 09:50, 8 August 2018 (UTC)
Most end templates don't render something meaningful by themselves and the code can be placed in <includeonly>...</includeonly>. For many start templates we could write <noinclude>{{name of end template}}</noinclude>. That may be more helpful for testing and debugging than to directly add the missing tags in noinclude. PrimeHunter (talk) 23:52, 8 August 2018 (UTC)
On a related note, the person who can find and fix the missing span end tag at the root of {{Userspace linking templates}} and similar templates will fix a couple dozen template pages. – Jonesey95 (talk) 12:22, 9 August 2018 (UTC)
Jonesey95:   Done. Easy with lintHint! —Anomalocaris (talk) 22:03, 9 August 2018 (UTC)

Null comment to keep this from being archived just yet. —Anomalocaris (talk) 23:32, 17 August 2018 (UTC)

Whole map

Hello. This is a map. [3] If you zoom you could find some informations, according to your selection. But you can see all the map at onse, with all the informations that shows you after zoom. Is there a way to copy or something else, to have all the map with all informations. It's for personal use, not for wikipedia, but I thought that you may help. Xaris333 (talk) 09:07, 18 August 2018 (UTC)

Missing </font> tag causing rest of page to be red

I just came across a talk page that had most of the text in red – everything after Talk:Henry Hill § Hill's place of residence. It appears to be because User:Redd_Dragon's sig is:

[[User:Redd_Dragon|<font color="red">'''Redd''' <font color="black">'''Dragon'''</font>]] <sup>''[[User talk:Redd_Dragon|speak]]''</sup>

Note the missing </font> tag after '''Redd'''. I see that the post causing the problem is from 2006. I also see that I posted to the page in 2012 and I'm fairly certain that I would have noticed and done something about the problem if it were rendering that way then. Was there a change in behavior, like maybe it (what?) previously closed the span to which the <font> setting applies after each section or something like that? The user's talk page exhibits the same problem because of the missing tag in the first line. I see it in Chrome and Edge, too. —[AlanM1(talk)]— 21:20, 17 August 2018 (UTC)

I closed the font tag - it's obviously the same issue as Wikipedia:Village_pump_(technical)/Archive_167#Horrible_colour_and_font_on_article_talk_page. Home Lander (talk) 21:26, 17 August 2018 (UTC)
Was there a change in behavior MediaWiki's July 2018 switch to a new linter package, probably. Vexations (talk) 21:51, 17 August 2018 (UTC)
I guess I was looking for a more general solution. Does it need to be reported to the people working on the thing that used to fix these automatically when rendering (and stopped doing so)? Meanwhile, is there maybe something I can add to my css to do the equivalent of a </font> before each section header to at least limit the length of the span? —[AlanM1(talk)]— 21:54, 17 August 2018 (UTC)
@AlanM1: From all the feedback I've seen, the WMF's opinion is that the previous rendering was incorrect per the HTML5 standards. To force us to fix non-compliant pages, there is no effort being made to make the new HTML cleanup tool replicate the behavior of the old one. I have created a bot, Ahechtbot, which can fix specific problematic signatures that appear on lots of pages, but if it's not widespread, it's best to just fix them as you find them. Looks like this particular signature only affects about 25 pages --Ahecht (TALK
PAGE) 22:36, 17 August 2018 (UTC)
@Ahecht:Wow. There are ~600,000 pages just in the high-priority section if you ignore the whopping 4.2 million with the wrong link color issue. That seems insurmountable. I'm sure it's been beat to death. I'll read some more. —[AlanM1(talk)]— 22:46, 17 August 2018 (UTC)
@AlanM1: Yup. Fortunately, most of those errors don't actually result in the page displaying incorrectly, and most of the serious ones are on talk, not article, pages. --Ahecht (TALK
PAGE) 23:14, 17 August 2018 (UTC)
To answer your other question, there's no way to use CSS to close font color tags, but you can reset it on a per-paragraph basis with something like div.mw-parser-output p, div.mw-parser-output dl { color: #222222; font: 0.87em sans-serif; }. I'd imagine, however, that there'd be pretty severe side effects of doing so. --Ahecht (TALK
PAGE) 23:14, 17 August 2018 (UTC)
@AlanM1: Yes, CSS is for styling pages (that's what the first S stands for): it can alter colours, fonts, spacing and over 100 other characteristics; but it cannot affect the underlying HTML of a page. If that HTML is malformed, no amount of CSS can repair the missing or misplaced tags. CSS can be used to hide page content, but that's a sledgehammer approach: moreover, the broken HTML is still there. Ahecht's suggestion immediately above again does not fix the problem of missing tags - all it does is to force a colour and font upon particular portions of a page. It is possible to use JavaScript to add in the missing tags (and that is to some extent what the old HTML Tidy tool did); but again a JavaScript approach will just mask the fact that a problem exists - it doesn't remove the problem.
I also refer you to the thread at Wikipedia:Village pump (technical)/Archive 167#HTML formatting issues in archived talk pages, particularly my two comments of 09:14, 23 July 2018 (UTC) and 10:17, 23 July 2018 (UTC). --Redrose64 🌹 (talk) 10:35, 18 August 2018 (UTC)

Bots Newsletter, August 2018

Bots Newsletter, August 2018
 

Greetings!

Here is the 6th issue of the Bots Newsletter. You can subscribe/unsubscribe from future newsletters by adding/removing your name from this list.

Highlights for this newsletter include:

ARBCOM
  • Nothing particular important happened. Those who care already know, those who don't know wouldn't care. The curious can dig ARBCOM archives themselves.
BAG
  • There were no changes in BAG membership since the last Bots Newsletter. Headbomb went from semi-active to active.
  • In the last 3 months, only 3 BAG members have closed requests - help is needed with the backlog.
BOTREQs and BRFAs

As of writing, we have...

Also

Discussions

These are some of the discussions that happened / are still happening since the last Bots Newsletter. Many are stale, but some are still active.

New things

Thank you! edited by: Headbomb 15:04, 18 August 2018 (UTC)

(You can subscribe or unsubscribe from future newsletters by adding or removing your name from this list.)

Help - Sneaky Vandalism!

Tracked in Phabricator
Task T201772
Resolved

Reported at OTRS Ticket:2018081110004267 (and a second one as well). On Empire_State_Building, the map clearly shows the words “Jewtropolis” over Manhattan and the phrase “INSIDE JOB” over lower Manhattan. Where does this data exist? I looked at https://maps.wikimedia.org/ and zoomed in to NY - and there it is. foundation:Maps_Terms_of_Use says if you find an error then go to https://www.openstreetmap.org to fix it - but it not there to be fixed! I've asked at ANI, but no joy there. Ronhjones  (Talk) 18:01, 11 August 2018 (UTC)

Chrysler Building has the same problem. Tornado chaser (talk) 18:08, 11 August 2018 (UTC)
Note just add | mapframe = no to the infobox to disable this while the third party issues are being looked at. — xaosflux Talk 18:19, 11 August 2018 (UTC)
Noting that Template:Infobox building was only recently updated to automatically show these kind of maps. Ping Evad37 since he might have more of an idea where exactly the data is stored, having created the modules and templates behind these maps.. Galobtter (pingó mió) 18:29, 11 August 2018 (UTC)
It's also in 2 World Trade Center and 2 Broadway and possibly others. I found them in the category Office buildings in Manhattan, I didn't check all of them. -kyykaarme (talk) 18:53, 11 August 2018 (UTC)
JW Marriott Essex House - reported at OTRS Ronhjones  (Talk) 19:15, 11 August 2018 (UTC)
It doesn't get any better if you zoom right into the World Trade Center (2001–present). From what I can tell, some large vandalism was reverted on openstreetmap in the last day or so.[4] Perhaps there's a caching issue? Drawing live content from a user-generated site, I don't know... Adolf Hitler Boulevard and Donald Trump Avenue anyone? -- zzuuzz (talk) 18:55, 11 August 2018 (UTC)
Good grief, I was walking near Fuck Road last week ..... I'm not sure how WM Maps syncs with OpenStreetMap, but somebody needs to tell the WMF tech team to run a resync ASAP. I've taken data off OpenStreetMap before, you basically have database dumps of planet.osm released weekly that you can grab and extract.Ritchie333 (talk) (cont) 19:08, 11 August 2018 (UTC)
Since no one seems to have an idea of when this could be fixed on the third-party end, I've just implemented the hackiest hack to disable maps for the vague manhatten area. Feel free to revert if this problem is fixed/the hack causes problems/if it is a terrible idea. Galobtter (pingó mió) 19:38, 11 August 2018 (UTC)
  • I've disabled mapframe from Template:Infobox building. @Evad37: please review. — xaosflux Talk 19:39, 11 August 2018 (UTC)
    Xaosflux I realized now that you may have meant to disable mapframe until we've figured out why this vandalism occured/how to deal with this vandalism on a permanent basis, and not just for fixing this singular issue - if so, apologies for my revert of your edit on the basis of me hackily fixing the issue by disabling mapframe for the manhatten area Galobtter (pingó mió) 19:50, 11 August 2018 (UTC)
    And seeing Template_talk:Infobox_building#Mapframe_code_disabled I see that is the case... Galobtter (pingó mió) 19:54, 11 August 2018 (UTC)
    @Galobtter: assuming the immediate problem is fixed I'm fine. There may need to be wider discussion regarding including third party content in our articles, especially if that content is not up to our editorial standards such as displaying hard-to-fix vandalism. — xaosflux Talk 21:07, 11 August 2018 (UTC)
    Yeah, this may be another wikidata-esque thing, where the benefits (nice maps) has to be weighed against vandalism concerns. Per Ronhjones comment below, the folks over at openstreetmap don't appear very good at dealing with vandalism.. Galobtter (pingó mió) 21:11, 11 August 2018 (UTC)
@JMatazzoni (WMF): @Quiddity (WMF): @CKoerner (WMF): Tagging WMF employees to check how the syncing works with OpenStreetMap. Daylen (talk) 20:16, 11 August 2018 (UTC)
Looking at openstreetmap and trying to follow the history. The user who added the data to NY, Lon, (and Russia, I think - changed to "Commieland"), is called "MedwedianPresident", and I see a comment about "repeat vandal". He seems to know exactly what he is doing, to the point that the edit titles do not always reflect the change - The Russian one was entitled "Cosmetic changes near Auckland, NZ". Looks like the edits survived for around 5 hours before being reverted. User has been blocked for 3 days (https://www.openstreetmap.org/user_blocks/2141). One has to question the use of a map that can cause so much offence to the viewers. Ronhjones  (Talk) 20:25, 11 August 2018 (UTC)
Three days? If I saw someone with a named account doing that sort of thing here, it would be an indef. Ritchie333 (talk) (cont) 21:11, 11 August 2018 (UTC)
Yeah I saw that the account had some 2 year old vandalism too, yet didn't get indeffed for that. Galobtter (pingó mió) 21:13, 11 August 2018 (UTC)
In my experience, OSM is a bit more forgiving of users than on the English Wikipedia. It is rare that a user account gets indefinitely banned. —seav (talk) 06:05, 12 August 2018 (UTC)
I've created phab:T201772 — MusikAnimal talk 21:14, 11 August 2018 (UTC)

Wikimedia runs its own copy of the OSM data. A simple refresh should fix this. 96.35.92.95 (talk) 01:26, 12 August 2018 (UTC)

The replication frequency is currently once per day, the task for increasing the frequency is phab:T137939 - Evad37 [talk] 02:21, 12 August 2018 (UTC)

In the future, report any such incidents to the FBI as well, as hate crimes. I know, it' s online, semi-anonymous, but please do! Thanks! Cammy169 (talk) 23:13, 18 August 2018 (UTC)

Glitch in "Thanks" diffs, maybe just on initial creations of articles

Tracked in Phabricator
Task T201218

Hey for about the last week when I have been "thanked" for edits, the linked diff shows an error message. E.g. I was "thanked" for this diff which gives page title as "Error" and then comments "One revision of this difference (855181989) was not found. / This is usually caused by following an outdated diff link to a page that has been deleted. Details can be found in the deletion log" and then gives the page's content. The edit history of the article has normal diffs, I only see the Error message when I click on the link from the Thank notice. I am not sure, but possibly all of these have been thanks for initial creations of articles (in which case maybe the "diff" is different, because there was no prior version), but I am sure that I have previously been thanked for many initial creations without getting any error messages. P.S. Browsing through past "thanks" seems to confirm that it is thanks for initial article creations only which provokes the Error message. --Doncram (talk) 22:41, 18 August 2018 (UTC)

Is this the place to report a bug/glitch like this? Hope this helps, and apologies if this is not the right way. Thanks for your attention, --Doncram (talk) 22:33, 18 August 2018 (UTC)

This seems to have been caused by gerrit:445136. Reporting bugs here is ok, although Phabricator is better. In this case, it looks like it has already been reported as phab:T201218. Anomie⚔ 00:01, 19 August 2018 (UTC)

Parser giving me grief, again

Consider the (fake) section header below:

x :

It seems normal: for the wikitext, I just typed "x :" (x, a normal space, and a colon). However, at the HTML level, there's actually a non-breaking space between the "x" and the colon, instead of the normal space I would expect. (This shows up when I use document.getElementById to log the textContent of the header. It also shows up when I use a normal header, but I used a fake header here for convenience.) Is there a legitimate reason for this behavior? Could it be a parser bug? Enterprisey (talk!) 04:48, 19 August 2018 (UTC)

(Phab at T202212.) Enterprisey (talk!) 05:00, 19 August 2018 (UTC)
And thanks to Brion on masto with the observation that "there's some nbsp replacement around certain punctuation to handle patterns common in French", which might be the root cause of this. Enterprisey (talk!) 05:05, 19 August 2018 (UTC)

Trying to pull in some template help on Commons

Please see:

--Timeshifter (talk) 05:00, 18 August 2018 (UTC)

Solved. See: Commons: Template talk:Mbox. --Timeshifter (talk) 08:10, 19 August 2018 (UTC)

Minor appearance issues with hovering pages and theme

 
See the black square, the bottom part of the "g" is missing.
 
Fairly more obvious

So I am using the cologne blue theme. When I hover over a linked Wikipedia Page, and it shows me the preview, there are some minor appearance issues (see the images). One is less obvious, one is more. Safari 12 (14606.1.36.1.3) (macOS Public Beta [18A365a]). Abequinn14 (talk) 01:01, 19 August 2018 (UTC)

This is intentional, but I think the effect wasn't made with the line-height of the cologneblue skin in mind. Cologne blue is a community maintained skin however, so you'll have to find a volunteer to fix it. —TheDJ (talk • contribs) 09:20, 19 August 2018 (UTC)
What's that cogwheel for, anyway? I've tried viewing this page in Cologne Blue, and can find no cogwheels anywhere - not even in in the languages list, which is where it appears in MonoBook. --Redrose64 🌹 (talk) 09:56, 19 August 2018 (UTC)
Its for page previews; you have to disable navigation popups in gadgets, and then make sure to enable page previews in Appearance, and then hover over a link (or you can view that page in incognito mode) Galobtter (pingó mió) 10:39, 19 August 2018 (UTC)

Committed identity template displaying oddly in some browsers

Mz7 brought to my attention that a committed identity template I have on my userpage is displaying oddly in some browsers. For me it displays as intended in Google Chrome, but both his version of Firefox as well as the browser on my cell phone display it like this. The script for my userpage is stored here; is this a coding issue on my part or something haywire with the template? Home Lander (talk) 22:31, 18 August 2018 (UTC)

@Mz7: If you zoom out using Ctrl+- once or twice (to reduce the text size) does the box reduce to a more normal size? --Redrose64 🌹 (talk) 22:36, 18 August 2018 (UTC)
@Redrose64: Yes! That does reduce it to a more normal size! So I guess it's a browser size issue. Mz7 (talk) 23:03, 18 August 2018 (UTC)
This confirms my suspicion: that it's a word-wrapping issue. The committed identity, being a very long sequence of random letters and figures, is treated as a single word. Normally, when a passage of text is too long to fit into the space available (in this case, between the left margin and that Userboxes sidebar on the right), the browser wraps the text at the space between two of the words. Such wrapping to another line cannot occur inside a word; and so if you have a very long word, your browser moves it down the page until it finds a place where it will fit - which in this case is just below the sidebar. The top edge of the box is in the expected position, but the bottom edge of the box cannot appear above the text, so it is pushed down; and so you get an overtall box. --Redrose64 🌹 (talk) 23:21, 18 August 2018 (UTC)
@Home Lander: If you zoom in using Ctrl++ once or twice (to increase the text size) does the box expand to exhibit the problem? --Redrose64 🌹 (talk) 22:39, 18 August 2018 (UTC)
@Redrose64: No, on my main browser, zooming in or out just causes the box to adjust as necessary to contain the text. Likewise, zooming in or out with my phone does not resolve the issues; the box stays huge. Home Lander (talk) 22:47, 18 August 2018 (UTC)
@Home Lander: I tried zooming in on Firefox 52 ESR, this happens when the page becomes too narrow to accomodate the whole SHA hash without breaking it in two rows. I think the problem is in the fact that the committed identity template overlaps with the userbox (even at normal zoom levels). If you can stop that, you will probably fix this. Looking at your CSS page, I'd reckon the problem is in the {{userbox top}} template, which has a float attribute. Daß Wölf 23:30, 18 August 2018 (UTC)
@Daß Wölf: You lost me quick with the code talk.   I moved the committed identity template above almost everything else. Does it display normally now? Home Lander (talk) 23:38, 18 August 2018 (UTC)
@Home Lander: Yeah, it diplays fine. The problem was the userbox table. I've experimented a bit, if one adds overflow: auto to the CSS attributes of the committed identity template, the old layout will work too. I don't see how you could do that since the template doesn't offer such an option, but since I don't see any downsides to this, I've added a suggestion on Template talk:Committed identity. Daß Wölf 23:48, 18 August 2018 (UTC)
@Home Lander: The attribute was added to the template by TheDJ. Your old layout should display fine now (no huge boxes). Daß Wölf 19:21, 19 August 2018 (UTC)
@Daß Wölf: Yep, I reverted and sure enough it now looks normal on my phone. Thanks. Home Lander (talk) 00:05, 20 August 2018 (UTC)

Namespace issue in ifeq?

{{#ifeq:{{Namespace|Talk:Quark}}|Talk|Do|Don't}} is weird.

  • {{Namespace|Talk:Quark}} returns Talk[[Category:Pages which use a template in place of a magic word|EVillage pump (technical)/Archive 168]]

{{#ifeq:{{Namespace|Talk:Quark}}|Talk|Do|Don't}} should therefore be equivalent to {{#ifeq:Talk|Talk|Do|Don't}}

  • {{#ifeq:Talk|Talk|Do|Don't}} returns Do
  • {{#ifeq:{{Namespace|Talk:Quark}}|Talk|Do|Don't}} returns Don't

What gives? Headbomb {t · c · p · b} 17:13, 20 August 2018 (UTC)

They aren't equal, {{Namespace|Talk:Quark}} secretly contains a hidden category, whereas "talk" doesn't. Why are you using {{Namespace}} at all instead of calling the magic word? {{3x|p}}ery (talk) 17:35, 20 August 2018 (UTC)
@Pppery: Because {{NAMESPACE|Draft:Foobar}} is a no go, you can't pass a specific page to {{namespace detect}} and I know of no other way of checking for a namespace, short of string manipulation, which I'd like to avoid if possible. Headbomb {t · c · p · b} 17:44, 20 August 2018 (UTC)
Do {{NAMESPACE:Draft:Foobar}} for Draft Galobtter (pingó mió) 17:59, 20 August 2018 (UTC)
Strange, I though I tried that and it didn't work when I did. But it works, so let's go with that.Headbomb {t · c · p · b} 18:00, 20 August 2018 (UTC)
Template output often includes non-displayed parts. You can see the complete output at Special:ExpandTemplates. {{Namespace|Talk:Quark}} produces Talk[[Category:Pages which use a template in place of a magic word|N00ExpandTemplates]]. {{NAMESPACE:Talk:Quark}} only produces Talk. PrimeHunter (talk) 19:29, 20 August 2018 (UTC)
Yeah I used an HTML inspector thinking it'd be equivalent to that, but it obviously wasn't. Anyway, Galobtter's solution above worked just fine. Headbomb {t · c · p · b} 19:51, 20 August 2018 (UTC)

Malfunctioning archive bot (moved from WP:ANI)

Hello,

It appears my talk page archive bot no longer works. There are month long entries that are not being archived. Anything wrong with it? Heres the code: 

{{Archives|auto=yes|search=yes}}
{{User:MiszaBot/config
| algo                = old(30d)
| archive             = User talk:AmericanAir88/Archive %(counter)d
| counter             = 2
| maxarchivesize      = 75K
| archiveheader       = {{Automatic archive navigator}}
| minthreadstoarchive = 2
| minthreadsleft      = 5
}}

Thank you AmericanAir88 (talk) 17:44, 20 August 2018 (UTC)

AmericanAir88 I only see one thread where the newest signature is older than a month; "minthreadstoarchive = 2", so another thread needs to become a month old before archival will occur. Galobtter (pingó mió) 17:57, 20 August 2018 (UTC)
@Galobtter: Thank you. Ill give it a try. Is it ok if I change the algo and minthread? AmericanAir88 (talk) 17:58, 20 August 2018 (UTC)
Yes, it is your talk page Galobtter (pingó mió) 18:00, 20 August 2018 (UTC)
@AmericanAir88: Prior to ANI, you had posted this. Please see WP:MULTI. --Redrose64 🌹 (talk) 20:35, 20 August 2018 (UTC)

LUA Specialist at Template_talk:Find_sources#Appearance

We need someone with LUA capabilities here. Thanks in advance. Headbomb {t · c · p · b} 21:55, 20 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

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)

We're still cleaning up the mess caused by switching from Tidy to RemexHTML, and tech-savvy editors will still be needed to working on the hundreds of thousands of pages with broken rendering for the forseeable future. Breaking all the old scripts and gadgets "soon" would be a disaster. This is only compounded by the roll out of the Interface Administrator group later this month, which means that gadgets and scripts in the mediawiki namespace or in the namespace of inactive users will only be able to be fixed by the very small number of editors granted this permission. --Ahecht (TALK
PAGE) 21:05, 20 August 2018 (UTC)
I'm not real sympathetic to this comment. If the particular old script or gadget has not been updated in something silly like 7 years, then either a) no one cares or b) someone cares but we don't know about it. The same people who will update the scripts will be the same people who would have prior to IAdmins... because all those sorts will be IAdmins. And, Remex cleaners aren't the same set of people as those, for the most part. --Izno (talk) 23:18, 20 August 2018 (UTC)

Preview page with this template (not in template namespace)

I'm trying to fix the fact that 21 extra pages were recently added to Category:Pages with parser function time errors. The pages are: 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18 + 19 + 20 + 21 (most of them appear also to be in Category:Pages with script errors).

What I would like to do is edit an old revision at User:Thayts/Userboxes/DST in user time zone then use "Preview page with this template" to see if the problem (the hidden error category) occurs on one of the above target pages. However, that option is only available in template and module namespaces. Is there some magic way of achieving the same result on a non-template page like this? I have occassionally wanted to do something similar with other transclusions, for example with user boxes which have generated a parser error.

Also, it would be good if anyone feels like investigating the problem because I'm caught up with other stuff. Ping Thayts as the author of the above, and BrandonXLF who has done some recent edits in the area. Johnuniq (talk) 05:07, 20 August 2018 (UTC)

A <span id="templatesandbox-editform"> exists in the edit form so a user script or gadget could easily enough insert visible fields in the right place. I don't know whether anyone has written such a script. Anomie⚔ 11:42, 20 August 2018 (UTC)

−

My userpage is No. 5 on your list - the error seems to have been generated by an incorrect time zone code in a userbox which displays my current local time - now fixed. Cheers, Bahudhara (talk) 14:01, 20 August 2018 (UTC)

For the simple case it would be trivial to do, even without templatesandbox. All it would need to do is parse the page and replace all transclusions with the new template. Of course that would be just reinventing the wheel. Anyway, this request is probably (https://phabricator.wikimedia.org/T74464). One could probably do it with special:apisandbox without coding... 16:35, 20 August 2018 (UTC) — Preceding unsigned comment added by 197.235.60.157 (talk)

Looks like BrandonXLF would be the best person to fix this userbox. It uses a series of nested templates that BrandonXLF has modified in the past couple of days. – Jonesey95 (talk) 16:46, 20 August 2018 (UTC)

Seems like a lot was changed, not sure if it's all still working with the abbreviations for non-DST (e.g. CET) and DST (e.g. CEST) as I intended. But it's up to BrandonXLF to get it right, I'm not feeling like spending a lot of effort on this right now. Thayts ••• 18:51, 20 August 2018 (UTC)

Understood. Johnuniq (talk) 00:44, 21 August 2018 (UTC)

Thanks all, phab:T74464 shows there is a script with the required magic at User:Jackmcbarn/advancedtemplatesandbox.js. Johnuniq (talk) 00:44, 21 August 2018 (UTC)

Gallery won't size

At Wind chill § North American and United Kingdom wind chill index, the image gallery contains three images, all of them appearing 180px wide, with heights of 101, 123, and 135 (left to right; correct according to the original image size and aspect ratios). However, they are rendered in 200x200px boxes, wasting 65px vertical space (maybe minus some padding). I tried a number of things, including specifying various values of |height= and |width=, without effect. What's up? —[AlanM1(talk)]— 07:45, 21 August 2018 (UTC)

width = worked for me. put it after align. - X201 (talk) 08:01, 21 August 2018 (UTC)

Issue with local links

There’s an issue with the local links on this wiki, such as in this template. The issue is with the {{plain link}} function, the links are having arrows displayed next to them as they’re links that direct you to outer websites. What’s the issue here?--▸ ‎épine talk♬ 01:08, 19 August 2018 (UTC)

@Épine: External link icons are by default added to links made with url's whether they go to external sites or the wiki itself like Example. wrapping the link in class="plainlinks" will remove the icon per Wikipedia:Plainlink: Example. Your in this template link has class plainlinks in "[دروست کردن]" in the top line and I see no external link icon there. The links in the "testcases" line do not have class plainlinks so external link icons are shown. PrimeHunter (talk) 22:03, 20 August 2018 (UTC)
@PrimeHunter: but the template’s data is pulled from module:documentation which is the same as the English one. And it’s not the only template with this issue, I’ve seen other links that use {{fullurl}} templates with the same issue. Note: It wasn’t like this before, I don’t know what changed. I thought maybe there’s a certain broken module or something.--▸ ‎épine talk♬ 05:36, 21 August 2018 (UTC)
ckb:Module:Documentation is not synchronized with Module:Documentation. There are differences in the testcases code. PrimeHunter (talk) 08:05, 21 August 2018 (UTC)

How to correctly do a template

 – No help at Help desk. ―Mandruss ☎ 12:57, 21 August 2018 (UTC)
 – ―Mandruss ☎ 23:28, 19 August 2018 (UTC)

Hi, I don't know if this little problem has to be here. If not, I please want to somebody traslate this section where it corresponds.

Before all, I'm a ES wiki user, but I never found help in that place. I want to do a template, exactly like this (explicit wikilink: es:Wikiproyecto:Automovilismo/Fórmula 1/Nuevas tablas#Escuderías y pilotos) but with more chances of adding more info to the header "Pilotos", obviously "Siglas" and "Rondas" too, but only adding as "optional" info, for example in one row putting two, and in another one putting 4 rows. I try to do the template on a small scale right here, but I have problems "hiding" the addional data, as you see here is there a small black background under the first column, because I don't know how to put these data as optional. I think the |style="color:#{{{equipo_1_color_letra|}}}; background:#{{{equipo_1_color_fondo|}}}; text-align:center;"| is hindering. Again, sorry if this don't have place here. shaGuarF1 23:22, 19 August 2018 (UTC)

Side talk at Help desk. ―Mandruss ☎ 12:57, 21 August 2018 (UTC)
Nobody's taking this one, so I'm wondering if moving it from VPT was the best thing for the user. This is clearly the more appropriate venue—no technical problem is being reported—but should I move it back anyway? ―Mandruss ☎ 19:18, 20 August 2018 (UTC)
WP:VPT probably the better place to get technical help etc, even if maybe it isn't technically in scope. Galobtter (pingó mió) 19:24, 20 August 2018 (UTC)
Yeah, I was told this is the place for help of a more technical nature, as compared to WP:TEAHOUSE. But that was years ago and things may have changed. I'll wait a little longer. ―Mandruss ☎ 20:15, 20 August 2018 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_168&oldid=1149976535"