Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
Jump to navigation Jump to 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. If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

Frequently asked questions (FAQ) (see also: Wikipedia:FAQ/Technical)
Click "[show]" next to each point to see more details.
If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
Font size changed unexpectedly?
You may have accidentally changed the font size on your browser for a particular website by pressing a shortcut key or scrollwheel without realising it. Try resetting the zoom with Ctrl+0 (typing the digit zero while holding down the control key) or adjusting the zoom with Ctrl++ or Ctrl+-. Alternatively, look for the View option on your browser's menu and reset it to 100%.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See bug 1864. There is an accesskey property on it (default to accesskey="f" in English), and for logged in users there is a gadget available in your preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you have problems making your fancy signature work, check Wikipedia:How to fix your signature.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
Numbers listed in parentheses in the "Recent changes" section, on history pages and in your watchlist are the number of added or removed bytes.
For server or network status, please see Wikimedia Foundation Grafana.
« Older discussions, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171

Contents


Preventing redlinks auto launch into edit source mode[edit]

I am an active anti-vandalism editor using the old school method. When I rollback and go to warn the User, the User TalkPage automatically launches in edit source mode and not the static (read) mode I am used to. This also happens when I click on non-existent pages/redlinks. Any ideas as to what is going on? Do I have something accidentally selected in my preferences or is this a bug? I am primarily an English language Wikipedia user, it is hard to tell but it appears that this does not happen when I am on the German Wikipedia or Wikimedia Commons. I have posted this issue here, the Help Desk, and Phabricator before but never received help/a solution. This might seem like a minor inconvenience, but adds major time in fighting vandalism for me. Thanks in advance for the assistance. Please ping me, as I do not watch posts. Classicwiki (talk) If you reply here, please ping me. 21:44, 16 November 2018 (UTC)

@Classicwiki: You could add the following to your common.js to disable the auto-edit on redlink annoyance:
(function() {
    var len = document.links.length;
    for (var i = 0; i < len; ++i) {
        var l = document.links[i];
        if (l.href.indexOf('&redlink=1') > -1) {
            l.href = l.href.replace('&action=edit', '');
        }
    }
})();
Or as a one-liner, for those who like a more compact version:
(function(){var len=document.links.length;for(var i=0;i<len;++i){var l=document.links[i];if(l.href.indexOf('&redlink=1')>-1){l.href=l.href.replace('&action=edit','');}}})();
I had to dig through several VP archives when I wanted to find this a month ago. Now I get to pass it on. Face-smile.svg — AfroThundr (u · t · c) 05:10, 19 November 2018 (UTC)
AfroThundr3007730, thank you so much for replying and trying to find a solution. Unfortunately, it did not work. I inserted the code into my [[1]]. It still launches into auto edit mode for rollbacks and redlinks. Classicwiki (talk) If you reply here, please ping me. 17:23, 19 November 2018 (UTC)
@Classicwiki: That's odd, assuming you've bypassed your browser cache, it should've worked. Are you getting any errors in the browser console? — AfroThundr (u · t · c) 20:40, 19 November 2018 (UTC)
@AfroThundr3007730: that javascript might be executing too early, before the page contents are loaded (thus no redlinks to find yet). It might be better to wrap it in a mw.hook that'll force it to wait until the page is ready. @Classicwiki: if the above code isn't working for you, try replacing it with this (reformatted to be a bit more concise/efficient):
mw.hook("wikipage.content").add(function() {
  $("a.new").each(function() 
  {
    this.href = this.href.replace("&action=edit","");
  });
});
HTH, Writ Keeper  21:26, 19 November 2018 (UTC)
Oh duh, I hadn't even though about that. In my common.js that line comes after another function waiting on mediawiki.util, which is probably why I haven't seen this race condition. This is why we pay you the big bucks. Face-smile.svg Also I was avoiding using the a.new selector, which only seems to occur in the article body, because I also wanted to target the namespace tabs and any other interface element that could result in the editor spawning (with the sole exception of the edit tab). Your version is a lot more compact though. One of these days I need to learn jQuery and the MediaWiki JS properly. — AfroThundr (u · t · c) 00:06, 20 November 2018 (UTC)


Writ Keeper, that works for the redlinks, unfortunately it does not work for the rollbacks. Still launches to edit mode of User:Talk page during rollbacks. Any idea about that? Classicwiki (talk) If you reply here, please ping me. 01:05, 20 November 2018 (UTC)
Classicwiki, that's because the above JS is only modifying links with the new CSS class, which only occurs in the article or page body (see my comment above). The redlinks that may appear elsewhere in the interface are not affected by that snippet. My version modifies all redlinks, regardless of class, but as Writ Keeper mentioned, it needs to wait until the page loads first, which is why you were seeing no effect. Combining both of the above snippets should look something like this:
mw.hook('wikipage.content').add(function() {
    $('a').each(function() {
        if (this.href.indexOf('&redlink=1') > -1) {
            this.href = this.href.replace('&action=edit', '');
        };
    });
});
The if condition is necessary to only target the redlinks and nothing else (e.g. the Edit button). Note: I'm not a JavaScript guru. WritKeeper, feel free to jump in if I'm off. — AfroThundr (u · t · c) 20:32, 20 November 2018 (UTC)
I don't think that's what Classicwiki is talking about...I think I need more information about what you mean. Can you describe exactly what steps you're talking about when rollback sends you to edit mode? Like, what page do you click on rollback from, which rollback link you click on, any pages or clicks in between there and the edit screen. Writ Keeper  20:52, 20 November 2018 (UTC)
Example diff showing both Twinkle (top line) and rollback (third line)
WritKeeper & AfroThundr3007730 Thanks again for taking the time to troubleshoot with me. Sorry if I wasn't being clear. When I hit the Twinkle rollback(AGF)/rollback/rollback(vandal) button (shown in the image above), two things happen. First, the page reverts the edit back and reloads; second, the offending user's talk page opens in a new tab. The user's talk page now automatically opens in edit mode, instead of read mode. This didn't use to be the case for me. It adds time in issuing warning for the edits because it slows my computer down to open in straight edit mode. Looking for a way to prevent that. I scanned my Twinkle settings, can't seem to find the offending code. Hope that clarifies things? Thanks again for helping! Classicwiki (talk) If you reply here, please ping me. 05:13, 21 November 2018 (UTC)
@Classicwiki: Ok, I see what you're talking about now. Those links are controlled by Twinkle, and don't have an edit parameter in them, they just control the rollback part of the workflow. After that, Twinkle pops a new tab so you can leave the user a message. Here is the link generated after I reverted some edits in the sandbox:
https://en.wikipedia.org/w/index.php?title=User_talk:174.63.196.239&action=edit&preview=yes&vanarticle=Wikipedia%3ASandbox&vanarticlerevid=870048912&vanarticlegoodrevid=870048366&type=norm&count=3.
If you were to use the "warn" button to leave a template, they would auto-populate all the relevant info (such as target article) in the template from those URL parameters. You could stop the user talk page from opening completely by unchecking those options in your Twinkle rollback preferences, but I'm not sure how to only stop Twinkle from opening the user's talk page in edit mode (short of forking the tool). This doesn't behave the same as originally intended with the new Wikitext editor now being the default. — AfroThundr (u · t · c) 03:58, 22 November 2018 (UTC)
AfroThundr3007730, yep closer to what I was talking about. Looking for a way to remove &action=edit&preview=yes section of the link you posted above so that it doesn't launch automatically load in edit mode. 05:40, 22 November 2018 (UTC)
Writ Keeper, any ideas? Best, Classicwiki (talk) If you reply here, please ping me. 15:29, 25 November 2018 (UTC)
Classicwiki, would you mind trying something? Go to Special:Preferences#mw-prefsection-betafeatures and turn off the "New wikitext mode" (which hasn't been "new" for more than a year now; someday, we've got to get that moved over to the regular prefs). Try that out for a while, and see if turning that off solves your problem. Whatamidoing (WMF) (talk) 00:01, 28 November 2018 (UTC)
Whatamidoing (WMF), thank you! I had done this before and hit save, which showed displayed a pop-up acknowledging my change in preferences. However, it would actually still have it on and I had not noticed. I had to uncheck "Automatically enable all new beta features" as well. This is saving me so much time in fighting vandalism. Thanks so much! Classicwiki (talk) If you reply here, please ping me. 04:56, 28 November 2018 (UTC)
Although, I wish I could use the wikitext editor simultaneously. Any suggestions, Whatamidoing (WMF)? Classicwiki (talk) If you reply here, please ping me. 18:38, 28 November 2018 (UTC)
I think the answer is "wait until the bug is fixed". I couldn't find the original Phabricator ticket, so I've filed another: phab:T211379. It'll probably get merged into the original, but in the meantime, the devs should see it and be reminded that this needs to get fixed. Whatamidoing (WMF) (talk) 21:04, 6 December 2018 (UTC)
Whatamidoing (WMF), Original Phabricator ticket was this: phab:T195914. I just made the original a subtask of yours. To explain a little further, having to switch between turning VE source editing and an older editor is burdensome for me, I don't know if others feel the same way. Often in anti-vandalism patrolling you stumble upon new users who do not cite their sources or make a simple mistake in a positive contribution to the project. I could revert that user for lacking citations or any other guideline they did not adhere to, but I fear that it will scare away a clearly good faith editor. VE's automatic citation tool is vastly superior. I am less inclined to assist problematic edits or I can not attend to as many as I would like, if I have to switch back and forth. Auto-opening in source mode not only slows down the computer because of VE, but it can make it more difficult to see what level of warning a vandal has received on their talk page, which ultimately slows down anti-vandalism patrolling. I will bring the same issue up over on phabricator. Thanks for bringing it up there! Best, Classicwiki (talk) If you reply here, please ping me. 16:12, 10 December 2018 (UTC)

WP:ITSTHURSDAY issues, 29 November 2018[edit]

Problems with edit summaries[edit]

Is there a problem with the MediaWiki interface? I can't see brackets around my edit summaries in my contributions. Normally, there would be brackets around the edit summaries at in my contributions page. Pkbwcgs (talk) 22:09, 29 November 2018 (UTC)

It looks like it is fixed but it still looks slightly strange. (diff |hist) instead of the regular (diff|hist). I don't know what happened then. Pkbwcgs (talk) 22:12, 29 November 2018 (UTC)
WP:ITSTHURSDAY. We got a new MediaWiki version in the last hour.[2] PrimeHunter (talk) 22:38, 29 November 2018 (UTC)
We got mw:MediaWiki 1.33/wmf.6. It's probably caused by this:
PrimeHunter (talk) 22:46, 29 November 2018 (UTC)
I have noticed that in the watchlist, the figure that shows the change in byte count is no longer enclosed in parentheses. --Redrose64 🌹 (talk) 23:10, 29 November 2018 (UTC)
Parentheses are showing up for me. Try bypassing your cache? Anomie 00:52, 30 November 2018 (UTC)
They're back now. Closer inspection shows that the parentheses, which were formerly part of the plain-text HTML for the page - old HTML
<span dir="ltr" class="mw-plusminus-pos" title="182,015 bytes after change of this size">(+378)</span>
new HTML
<span dir="ltr" class="mw-plusminus-pos mw-diff-bytes" title="182,015 bytes after change of this size">+378</span>
are now generated by ::before and ::after pseudo-elements, with these rules:
.comment--without-parentheses:before,
.mw-changeslist-links:before,
.mw-diff-bytes:before,
.mw-tag-markers:before,
.mw-uctop:before {
  content: '(';
}
.comment--without-parentheses:after,
.mw-changeslist-links:after,
.mw-diff-bytes:after,
.mw-tag-markers:after,
.mw-uctop:after {
  content: ')';
}
So I guess that the style sheet containing those rules either wasn't served, wasn't received, or wasn't being loaded by my browser. --Redrose64 🌹 (talk) 16:52, 30 November 2018 (UTC)
It looks like it's supposed to display as (diff | hist), but for some reason in Firefox 63 at least it's displaying as (diff | hist). git blame tells me it was caused by gerrit:473144. Anomie 00:43, 30 November 2018 (UTC)
Normally, there are brackets around the "tags" when checking a diff but there isn't anymore. However, there are brackets around edit sumaries now so that is good. Pkbwcgs (talk) 23:12, 1 December 2018 (UTC)

Internal error[edit]

This happened when I tried to move Talk:United Kingdom general election, 2010, a talk page with archive subpages.

[XABumQpAME0AAI5Jln0AAAAD] 2018-11-29 22:56:26: Fatal exception of type "MWException"

I tried twice, and it happened again.

[XABwvwpAMFUAAHveT4AAAABS] 2018-11-29 23:05:35: Fatal exception of type "MWException"

Oh, I see. Someone moved the subpages without moving the main talk page. So I tried just moving the main talk page without moving the subpage redirects. Still got an error.

There may be more coming where this came from, given that a bot has been given permission to move election pages at hyper-speed.

FWIW. Thought I'd put it down here in case it's helpful to anyone. – wbm1058 (talk) 23:12, 29 November 2018 (UTC)

The move succeeded after I manually deleted the redirect at the target first. I wasn't able to get it to move by the usual method of checking the box. – wbm1058 (talk) 23:22, 29 November 2018 (UTC)
Filed as T210819 — JJMC89(T·C) 03:12, 30 November 2018 (UTC)
I was experiencing this problem earlier today when attempting to move over edited redirects. Like wbm, my workaround was to manually delete the redirect first. Cheers, Number 57 15:41, 30 November 2018 (UTC)
Yesterday was WP:THURSDAY. wbm1058 (talk) 16:44, 30 November 2018 (UTC)

Something new in our edit contributions.[edit]

In out contribs history. We now get a wiki-link to the section we've edited. GoodDay (talk) 23:54, 29 November 2018 (UTC)

It was there before, you just had to click the little tiny arrow. Ian.thomson (talk) 23:56, 29 November 2018 (UTC)
Seriously? How in all the hours of looking at my watchlist did I not notice that? Anyway - good idea! SmartSE (talk) 00:00, 30 November 2018 (UTC)
Too much linkage (sea of blue), though. Should be changed back to 'just' the arrows. GoodDay (talk) 00:03, 30 November 2018 (UTC)
Don't feel bad. I've been around over a decade, and I never noticed that until you just now pointed it out. — Maile (talk) 00:26, 30 November 2018 (UTC)
Is there a way to go back to the old format? (Someone's bound to ask whenever something changes). –Deacon Vorbis (carbon • videos) 02:03, 30 November 2018 (UTC)
  • Exactly!!! Let’s WP:RFC to revert this change ... which is what we seem to usually do. Yes, what an annoying sea of blue. Steel1943 (talk) 02:35, 30 November 2018 (UTC)
Personally, I'd revert the change. Imzadi 1979  02:41, 30 November 2018 (UTC)

This change should've been discussed first by the community, before the big wigs implemented it. GoodDay (talk) 03:37, 30 November 2018 (UTC)

The clear solution is to change the color back to #72777d if you prefer the previous color, not to revert the change. (GoodDay, Deacon Vorbis, Steel1943, and Imzadi1979, you can do this by adding (note: quite buggy) .comment a { color: #72777d } to your common.css.) I originally made a user script to do this, and a MW dev (shoutout to Legoktm) pointed out that it would be much more efficient to change it on the MW end. Enterprisey (talk!) 04:05, 30 November 2018 (UTC)
On further reflection, there are some issues with this implementation. See T165189 for further discussion. Enterprisey (talk!) 04:11, 30 November 2018 (UTC)

10/10 I like it (can the devs do something and get some praise for it :). Definitely didn't notice the arrow (or I forgot about it); and the new links are pretty convenient. Galobtter (pingó mió) 04:53, 30 November 2018 (UTC)

I don't know if someone already invented a script to restore the previous appearance and functionality, but I've just written up User:Ekips39/sectionsummaries.js. This will make it exactly like it was before, unlike the suggested CSS solution. ekips39 (talk) 05:05, 30 November 2018 (UTC)

Unfortunately there are bugs. In recent changes and watchlists, sometimes there's an extra parenthesis after the arrow link, fixed and sometimes the space between the section name and the edit summary is missing. I haven't figured out why yet.
Also, if you want to change the color without changing the link back, it would be better to create a span inside the link that contains the section name and not the arrow and is the appropriate gray. I could do that too if anyone wants it. ekips39 (talk) 05:37, 30 November 2018 (UTC)
This is a horrible change and should be reverted. Looking at my watchlist it's just a sea of blue links. It's nearly impossible to tell the difference between a section link and a normal link. How was this change implemented? Where was it implemented? Who made the decision to implement it? Nihlus 06:16, 30 November 2018 (UTC)
Enterprisey linked to the Phabricator task that led to this. I'm not sure why you indented your comment as a reply to mine. I don't like the change either because I found the small arrow link obvious and usable enough, but apparently some people didn't. ekips39 (talk) 06:26, 30 November 2018 (UTC)
  • Humble request: if you're going to change the look of a page that people have become used to over a decade or more, please provide an option in preferences to revert that change. –xenotalk 14:47, 30 November 2018 (UTC)
    I don't think it's practical to have a preference for every look feature and this one is quite minor. Jo-Jo Eumerus (talk, contributions) 14:50, 30 November 2018 (UTC)
    It's made the watchlist nigh-on indecipherable much harder to parse. –xenotalk 14:52, 30 November 2018 (UTC)
    Unlike almost all other sites, almost everything on this site is customisable using on-site per-user CSS and JS, and there's an active group of people writing such customisations for others to use (like Writ Keeper, thanks!) There is a preference for it, it's using one of those scripts. Having a tick box for everything in the preferences would make that page even less usable than it is. Also, I find your assertion that expanding the click area of some links on the watchlist has made it "nigh-on indecipherable" to be a bit melodramatic. --Deskana (talk) 15:18, 30 November 2018 (UTC)
    Customizable yes, and the script is nice, but the links appear momentarily before disappearing which is a bit jarring. And yes, when basically the entire watchlist is blue it makes it a lot harder to quickly distinguish the page names and other links from the section links on a smaller screen. Yes, perhaps I exaggerated a bit. –xenotalk 15:47, 30 November 2018 (UTC)

User:xenoUser:NihlusUser:Ekips39User:Steel1943User:Deacon VorbisUser:GoodDayUser:Imzadi1979Hi, all, I've written a quick script to restore the old section link style: User:Writ_Keeper/Scripts/sectionLinkShortener.js. Install as usual by putting mw.loader.load("/w/index.php?title=User:Writ Keeper/Scripts/sectionLinkShortener.js&action=raw&ctype=text/javascript"); (<code></code> tags not included) on a new line in your common.js page. Writ Keeper  14:54, 30 November 2018 (UTC)

I'm not a techno type. Just want the bigwigs to change this back to how they were. This reminds me of when they unilaterally deleted the 'orange bar' notification & replaced it with the facebook notification style, without input. Thankfully then, the community raised up enough dust, so that a 'small' orange bar was restored for one's being contacted on one's talkpage. GoodDay (talk) 15:03, 30 November 2018 (UTC)

I don't like this because now you can't immediately tell it apart from ordinary wikilinks. The entirety of the section name being a link is fine. Using the same color as other links is not. Perhaps the section links should be assigned a CSS class. Nardog (talk) 15:10, 30 November 2018 (UTC)

  • Yup, the sea of blue watchlist officially sucks. Thanks again to Writ Keeper for being a rockstar when it comes to providing us with .js fixes.-- Jezebel's Ponyobons mots 18:32, 30 November 2018 (UTC)
Yes, thanks for that - great stuff. I could tell there was something different today, but I couldn't quite put my finger on it. Nice work! Lugnuts Fire Walk with Me 18:51, 30 November 2018 (UTC)
Writ Keeper to the rescue again! Sea of blue banished.-- Pawnkingthree (talk) 18:56, 30 November 2018 (UTC)

For those who can't recall the old appearance, or weren't aware that the little grey arrows were links, pop over to a wiki that hasn't yet been updated - for example the history of the "Events" page at Wikimedia UK. --Redrose64 🌹 (talk) 19:31, 30 November 2018 (UTC)

The arrows were blue as normal for links but it could be hard to spot when you weren't looking for it. The unlinked heading was grey. PrimeHunter (talk) 19:42, 30 November 2018 (UTC)
Ctrl++++++ Blue, indeed. Blame my eyesight for that. Ctrl+0 One of the reasons that Firefox has annoyed me for the last two years is that they switched from easy-to-read sharp-edged character glyphs to the smudgy kind (anti-aliased?) that Internet Exploder had used for years. Often I have to look several times (I wonder if it is this smudging that has caused other people to have arguments about dashes on another page), and shape is easier than colour to pick out when smudges are present.
Back to the main q. In essence, what has happened is that a link was always there (or since April 2007 at least), but some text that previously appeared outside the link has now been moved inside the link. Old HTML:
<a href="/wiki/Wikipedia:Village_pump_(technical)#Something_new_in_our_edit_contributions." title="Wikipedia:Village pump (technical)"></a>&#x200E;<span dir="auto"><span class="autocomment">Something new in our edit contributions.</span></span>
New HTML:
<a href="/wiki/Wikipedia:Village_pump_(technical)#Something_new_in_our_edit_contributions." title="Wikipedia:Village pump (technical)">→Something new in our edit contributions.</a>
This is more efficient, since less HTML is served. --Redrose64 🌹 (talk) 20:45, 30 November 2018 (UTC)

I never use this feature. The best watchlist feature in the world forever that should be default: User:Writ Keeper/Scripts/commonHistory.js view diffs in the watchlist page without clicking through to the article. -- GreenC 19:46, 30 November 2018 (UTC)

I'm considering opening an Rfc on this matter. Wish the bigwigs would check with the community first, before making such changes. GoodDay (talk) 21:00, 30 November 2018 (UTC)

  • I actually like the new feature. In the 14 years I've been here, I never had a clue you could click on the little arrow. The longer text is much more obvious. Should there be a preferences setting to reset this to the old behavior? I guess; it's just a CSS tweak. -- RoySmith (talk) 21:57, 30 November 2018 (UTC)

So now it seems to have gone back to how it was before, and Writ Keeper and I have two scripts that do (almost) the same thing. Now what? ekips39 (talk) 22:25, 30 November 2018 (UTC)

Some discussion happens on Phab, and hopefully we get a CSS class on the section header, so everyone can give it whatever color they want without the user script loading delay. Enterprisey (talk!) 23:03, 30 November 2018 (UTC)
Not the class "autocomment"? I don't want the section header in the link at all, so I'll be sticking with my script. ekips39 (talk) 00:24, 1 December 2018 (UTC)

My $0.02 would be that the link to the section is desirable, but let's stick with the old colour (grey). This would help easily distinguish automatically generated section links with other links in edit summary. As well as avoid the "sea of blue". Until WMF considers such a suggestion, here is the CSS manipulation:

$('.comment a:contains("→")').css('color', 'grey');

that does the trick. Add the line to your common.js. SD0001 (talk) 05:54, 1 December 2018 (UTC) UPDATE: They were listening! Now the effect produced by this code has been implemented globally. SD0001 (talk) 16:53, 6 December 2018 (UTC)

"gray"/"grey" is the wrong color, and there's no need to add any additional color specifications if you're using JavaScript. The section name should be wrapped in <span class="autocomment"> as it was before. This code does this. ekips39 (talk) 06:42, 1 December 2018 (UTC)
Okay. I was just suggesting something simple. FWIW I would suggest changing for (i = 0; i < comment.length; i++) to var n = comment.length; for (i = 0; i < n; i++) (more efficient) and if(comment[i].getElementsByTagName("a")[0].innerHTML.indexOf("→") == 0) to if(comment[i].getElementsByTagName("a")[0].innerHTML[0] === "→") (more readable and straightforward). Also, the blue underlines (on hover) under grey text looks weird. Finally, is there a plan to move this code to Mediawiki:Common.js? SD0001 (talk) 12:39, 1 December 2018 (UTC)
Nice, I didn't know you could use innerHTML as an array. I haven't fully learned JavaScript yet. Yes, it looks weird, but that's what happens when you recolor it without delinking it. The original version of my script also changes the link to be just the arrow, so it doesn't have the underline. There's now a documentation page at User:Ekips39/sectionsummaries.
What code would be moved to common.js? Are you asking me? I don't know. ekips39 (talk) 02:48, 2 December 2018 (UTC)
While we're discussing the format of the section-link, there is also a separate phab about the specific symbol to use (currently the arrow) to denote it. DMacks (talk) 20:51, 1 December 2018 (UTC)
I continue to oppose script or CSS solutions to controversial dev changes without prior discussion let alone community consensus. With a very few exceptions that I would prefer to have avoided, I refuse to clutter my software environment with user-level stuff that I don't understand, that usually adds overhead, and that lacks any formal support. It's just. Bad. Practice. ―Mandruss  21:12, 1 December 2018 (UTC)
It's actually a web best practice, and assumed by the authors of the various web specifications, that users will customize the output of a particular website. If you don't understand it, there are many people who can help you. As for "controversial", all changes are controversial inside the first week, sometimes two. But people don't remember that something was controversial years down the line. That's just the nature of most change. --Izno (talk) 21:42, 1 December 2018 (UTC)
1. that usually adds overhead, and that lacks any formal support.
2. As for "controversial", all changes are controversial inside the first week, sometimes two. But people don't remember that something was controversial years down the line. That's just the nature of most change. Thanks, I'll quote you the next time I make a site-wide controversial change without prior community consensus, and I get summoned to ANI on a DE complaint. I assume you'll be there to defend my action. ―Mandruss  21:49, 1 December 2018 (UTC)
That's not how that works.
True, they do lack formal support, but as I said, if you need help, there are plenty of people who hang around who are happy to help. --Izno (talk) 21:57, 1 December 2018 (UTC)
Sorry, I'm here to build and maintain an encyclopedia, not to spend my time pursuing fixes to problems with my personal version of the software environment. ―Mandruss  21:59, 1 December 2018 (UTC)
Maybe you don't remember, Izno, but I do. But maybe other people don't. Maybe they think we've always been at war with Eastasia Eurasia. Except we haven't. And that doesn't justify anything. ekips39 (talk) 22:35, 5 December 2018 (UTC)
I do remember those but they do not often come to mind not least because I did not oppose those changes. --Izno (talk) 00:06, 6 December 2018 (UTC)
What should the people creating these solutions do instead? What solution would be better? ekips39 (talk) 02:46, 2 December 2018 (UTC)

Survey[edit]

  • Change back to Arrow linkage - as it was better the old way. GoodDay (talk) 04:21, 3 December 2018 (UTC)
  • Keep given the number of people who have commented that they never knew about the arrow link, the old interface was obviously not intuitive enough. It would be nice, however, if the section links had their own class so that editors could change the appearance of the links via CSS. --Ahecht (TALK
    PAGE
    ) 15:48, 3 December 2018 (UTC)
  • Put it back how it was, i.e. the all-blue link, or put the autocomment span inside the link and exclude the arrow from it. I didn't have any practical problems with the original change, I just don't like how it looked. Definitely do something other than making the entire link gray like it is now. That doesn't help. ekips39 (talk) 22:35, 5 December 2018 (UTC)

Copying edit summaries[edit]

Hi, On the contribs page where you've got "Article (Edit summary) - The first letter after each bracket cannot be copied
So for instance "Ashley Benson (Adding local short description: "American actress and model" (Shortdesc helper))" - The A in "Adding" cannot be copied and it's like this for them all,
It's also worth noting the brackets themselves cannot be copied and pasted either (I've added them here manually),
Thanks, –Davey2010Talk 16:03, 2 December 2018 (UTC)

Put your mouse just before the opening bracket, and you will find that by dragging to the right, you can copy the first character of the edit summary. The brackets are not copyable because they are not physically present in the page; they are generated by your browser. This is related to Problems with edit summaries above, specifically the bit where I mentioned the ::before pseudo-element. --Redrose64 🌹 (talk) 17:01, 2 December 2018 (UTC)
@Redrose64: But I can copy them, including the bracket. –Ammarpad (talk) 17:28, 2 December 2018 (UTC)
@Ammarpad: Davey2010 said "on the contribs page", so try it at Special:Contributions/Ammarpad. --Redrose64 🌹 (talk) 18:00, 2 December 2018 (UTC)
Hi Redrose64, Ah brilliant you're a life saver thank you so much! :), (Sorry for the reping I misread your reply, Thanks again, –Davey2010Talk 19:30, 2 December 2018 (UTC)
Redrose64 Yes, I can't copy it on the Special:Contribs. I earlier just used the example Ashley Benson he gave. –Ammarpad (talk) 21:49, 2 December 2018 (UTC)

Template:Infobox country[edit]

Hello. I update template on Azerbaijani Wikipedia from Template:Infobox country. But I want change somethings, for example in English Wikipedia uses |gini= and |HDI= parameter like 39.6, but I have to use like 39,7 (with comma). When use like that, I get error (Error: Invalid Gini value). How I can change decimal separator from "." to ","? --Drabdullayev17 (talk) 12:38, 1 December 2018 (UTC)

You could write a template (if it's only one parameter) or lua module (if it's more than 1 parameter) wrapper for infobox in which you will convert that number parameter(s) before calling original template (or change #expr parser function, but it's probably too much work and requires access to wiki source code) --178.235.147.84 (talk) 19:22, 1 December 2018 (UTC)
It is two parametrs at least. Can you show me example lua module? I have no tecnical skills for write new module. --Drabdullayev17 (talk) 06:57, 2 December 2018 (UTC)
Azerbaijani Wikipedia has az:Module:String so you could start by creating az:Template:Decimal with {{#invoke:string|replace|{{{1|}}}|,|.}}. This changes any commas to periods. To fix a template without making a wrapper, whenever a template parameter foo may have a comma instead of a period, change each {{{foo}}} in the template code to {{decimal|{{{foo}}}}}. Also change {{{foo|}}} to {{decimal|{{{foo|}}}}}, and {{{foo|...}}} to {{decimal|{{{foo|...}}}}} for any "...". If the template only invokes a module instead of using template code then this fix cannot be used. PrimeHunter (talk) 12:41, 2 December 2018 (UTC)
Thank you very much, PrimeHunter --Drabdullayev17 (talk) 12:06, 6 December 2018 (UTC)

Visible ndash[edit]

How come that 839&ndash, 841 is visible in Lajos Winkler#Further reading, even though the source text looks okay to me? --Leyo 22:33, 1 December 2018 (UTC)

WT:CS1#ndash entity in pages parameter. --Izno (talk) 22:46, 1 December 2018 (UTC)
I don't know what to take from that, but Template:Cite journal#COinS says not to use &ndash; there, so I wouldn't use it there. ―Mandruss  22:50, 1 December 2018 (UTC)
Well, what about fixing all such uses by a bot? --Leyo 23:31, 2 December 2018 (UTC)
The fix is known and working in the sandbox version, we just need an admin to deploy it. After 2+ months. Headbomb {t · c · p · b} 21:11, 6 December 2018 (UTC)
What exactly needs to be done? --Leyo 08:56, 7 December 2018 (UTC)
Headbomb, links please ? Then people can maybe help in achieving that. ;) —TheDJ (talkcontribs) —TheDJ (talkcontribs) 14:51, 7 December 2018 (UTC)
Ask Trappist the monk (talk · contribs), he's the one that fixed things in the sandboxes. He could deploy the fix, it's tested, and knows what needs to be done. Although don't get your hopes up, he's typically not very responsive about such requests. Headbomb {t · c · p · b} 14:57, 7 December 2018 (UTC)
I think that it's this edit. The thing about Module:Citation/CS1 is that Trappist the monk doesn't put updates live straight away (except fixes for breaking changes), they go through in bundles; and two months delay is nothing unusual. --Redrose64 🌹 (talk) 20:15, 7 December 2018 (UTC)
"except fixes for breaking changes" evidently not. Headbomb {t · c · p · b} 12:51, 10 December 2018 (UTC)
@Headbomb: You are more than capable of starting a discussion to deploy that exact fix. --Izno (talk) 00:08, 11 December 2018 (UTC)
@Izno: I did that... 2 months ago. Headbomb {t · c · p · b} 00:37, 11 December 2018 (UTC)

viewing new pages[edit]

I'd like to view new pages or new drafts which

  • have no categories added (for main namespace)
  • have no wikiprojects added (for main or draft namespace)

Sorted by date of creation of article. Is this possible I know of Special:PageAssessments but it does not seem to do this. I am asking because I think newly created pages should be categorized and marked with wikiprojects as soon as practically possible to engage newcomers and wikiprojects into collaborative work. --Gryllida (talk) 04:47, 4 December 2018 (UTC)

On the category issue, new articles without categories are logged by filter. They're logged in the order they're created with the top one being the most recent. –Ammarpad (talk) 14:30, 4 December 2018 (UTC)
Gryllida, Special:NewPagesFeed marks articles without catoriges with a big red message that says, "No categories". As far as wikiprojects added to the talk page, virtually no new articles have talk pages. Do you have the New Page Reviewer right? I think that would help with what you want to do. ~ ONUnicorn(Talk|Contribs)problem solving 14:53, 4 December 2018 (UTC)
Thanks, this looks useful. :-) Perhaps new pages feed should have a filter for pages which do not have WikiProjects with them -- not only for categories? And what advantages would the new page reviewer right give me? Gryllida (talk) 19:11, 4 December 2018 (UTC)
Gryllida, I'm assuming the reason you are looking for new pages without categories and/or Wikiprojects is because you want to add categories and/or Wikiprojects to them. Presumably, in the course of doing that if you notice other problems with the page you are tagging the pages appropriately. Presumably, if in the course of doing that you notice a page that really needs to be deleted (perhaps obvious vandalism or attack pages), you are speedy tagging as appropriate. At this point, you are basically doing the job of a new page reviewer, and thus should have the userright so that you get the little sidebar which is quite useful and so that you can mark them as reviewed and no one else needs to duplicate your work. ~ ONUnicorn(Talk|Contribs)problem solving 13:58, 5 December 2018 (UTC)

Filter to block files?[edit]

Is it technically possible to create a filter or something like that which would block the addition of images/files? We could urgently use something like that at the Donald Trump article. You probably know what happened at that article in November: a vandal using compromised accounts (which allowed them to get past the Extended Confirmed protection) replaced the primary picture of Trump with a picture of male genitals. Even though it was reverted and revdel’ed within minutes, the photo remained in the memory of Google and Siri long enough to be seen by many people. The incident was reported in the media, giving Wikipedia a bit of a black eye (even though the stories mostly focused on the actions by regular editors to fight the problem). The vandal did it half a dozen more times, using different compromised accounts and different image files each time. We ultimately had to full-protect the page. We would like to lift the full-protection but we don’t want the problem to recur. That’s why I wondered if there might be some way to prevent changing or adding files. I am not techie enough to know if this is possible or even what to call it, but does anyone here know of a way to accomplish this? Thanks. -- MelanieN (talk) 17:16, 4 December 2018 (UTC)

MelanieN, this is possible, see Wikipedia:Edit filter noticeboard#RFC enforcement - TFA image protection. Ping MusikAnimal on this, the same filter can be used for both eventually protecting TFAs and Donald Trump. Galobtter (pingó mió) 18:32, 4 December 2018 (UTC)
Well actually, the TFA one would be about disallowing non-autoconfirmed users while for Donald Trump it'll be any user (except perhaps admins, I suppose); but it is the same idea. Galobtter (pingó mió) 18:33, 4 December 2018 (UTC)
@MelanieN: We do have MediaWiki:Bad image list. Warning: if you go to that page, do not click the file links therein unless you are happy to be shown explicit photographs. See also Wikipedia:Village pump (proposals)/Archive 154#RfC: should we automatically pending-changes protect Today's Featured Articles?, including my comment of 08:02, 14 October 2018 (UTC) in that. --Redrose64 🌹 (talk) 23:05, 4 December 2018 (UTC)
Thanks for the info. I don't know if that would help, because the vandal uses a different picture every time, and apparently the list didn't stop him from using them. I was really hoping to find something that would block ALL addition of files. -- MelanieN (talk) 23:50, 4 December 2018 (UTC)
@MelanieN: It can be done. Is there any rough consensus for this? For the short-term I am inclined to do it, anyway, but I wanted to make sure. My bigger plan which will require much broader consensus is to introduce a new template, {{no image changes}}, that has no visual effect except putting the page in a category like Category:Pages under image protection. The template can only be added or removed by an admin (enforced via a filter). If the template is anywhere in the source, the filter will disallow addition of images or changing the filename of existing image syntax. Then we can put it on Donald Trump, and other high-profile pages suffering from the same abuse as needed. Because it's a template, you'll be able to easily see which pages are under this editing restriction. We'd need to keep an eye on it because admins will probably forget to remove it. Or, taking it a step further, have a bot remove it after some time, perhaps even a time specified by the template, e.g. {{no image changes|expiry=2018-12-10}} MusikAnimal talk 06:55, 5 December 2018 (UTC)
Thanks for your reply, MusikAnimal. That’s encouraging, to know that it can be done. Would that be like full-protection on images only? In other words, extended-confirmed editors could make text edits, but only admins could make image changes?
About consensus: The idea of an edit filter for “image protection” came up briefly here, where we were kicking around possible solutions to the problem. It got several positive reactions but did not get a full discussion. The current discussion is here and mainly focuses on how/when to lift the full protection - in other words restoring EC protection but opening back up to the possibility of vandalism. As a temporary measure we have made the infobox into a template which is fully protected, but IMO that is something the vandal could easily get around if we unlock the article. If you’d like to see more of a consensus I can start a discussion at the talk page, to see how people feel about the idea of an “image protection” filter for the article. Or would that violate your earlier suggestion, not to carry out this kind of discussion on-wiki where the vandal can see it? I could do an email survey of the half-dozen most active commenters there. To tell you the truth I don't think anyone would object; this seems like a great solution to the problem. -- MelanieN (talk) 07:54, 5 December 2018 (UTC)
I agree no one would object; if it is between full protection and full protection only for images..; and images are rarely changed on the article anyhow. Galobtter (pingó mió) 12:55, 5 December 2018 (UTC)
Thanks. In that case, feel free to lower to ECP, MelanieN. The filter is running. No one can add or change imagery except admins. In the coming days I'll start a thread at WP:VPR or the like about a more general image-protection system using a template. MusikAnimal talk 21:53, 5 December 2018 (UTC)
Thank you! I will restore the ECP protection. -- MelanieN (talk) 22:32, 5 December 2018 (UTC)

Mobile editing[edit]

Hey, so I 3dit on the mobile Wikipedia incredibly frequently, and have noticed a plethora of issues, including the absence of undo buttons, categories, etc. on the mobile view, which makes editing very frustrating.

Yet the most present and irritating thing is that pages always display as a specific version, which makes the edit button swap out for the comparatively useless view source button. I always start editing on mobile with my watchlist, and from there, there is no way to directly edit the article, even a simple revert, without retyping the article name in the search box to load the editable version, or by switching to the desktop view and back. Has anyone else experienced this? I'm also fully sure it hasn't always been this way; I've been editing on mobile for a long time. ɱ (talk) · vbm · coi) 18:23, 4 December 2018 (UTC)

That very request just missed the cut-off in the community wishlist survey. ~ ONUnicorn(Talk|Contribs)problem solving 18:59, 4 December 2018 (UTC)
Does phab:T200969 sound like that problem?
And on the general subject of mobile editing problems, there's work being planned for mobile's visual editing mode at mw:Visual-based mobile editing/Ideas/October 2018. A nice long list of what's not working with mobile editing, or recommendations for making it less painful, would actually be really helpful right now. Whatamidoing (WMF) (talk) 19:18, 4 December 2018 (UTC)
Try [3] on mobile. If you like it, use it. Does it work better? Gryllida (talk) 19:47, 4 December 2018 (UTC)
  • What confuses me is that the desktop view is not actually the desktop view anymore, but some squished up bastardization. –xenotalk 19:49, 4 December 2018 (UTC)
The desktop view looks normal to me (desktop PC with Firefox, no current access to a mobile device). What is your skin at Special:Preferences#mw-prefsection-rendering? Does it look normal if you log out? What is your browser? Try to clear your entire cache. PrimeHunter (talk) 20:54, 4 December 2018 (UTC)
My guess is the new mobile-responsive look for Monobook. One can replicate this on a desktop window by shrinking the window size to less than 600 pixels, at which point the text of most of the top links and the like get replaced by icons and stuff like that. There's a VPT thread about it somewhere. (Edit: here it is) If that is the source of the problem, there's an opt-out function in Special:Preferences, in the Appearance tab; uncheck "Enable responsive Monobook design". Writ Keeper  21:07, 4 December 2018 (UTC)
Yes! Perfect. All is back to how it should. Thank you Writ Keeper! –xenotalk 22:18, 4 December 2018 (UTC)
  • What did it change to now? Do you have a screenshot, please? Gryllida (talk) 21:18, 4 December 2018 (UTC)
    It was the "mobile Responsive" view I guess. Which is strange because if I ask for a desktop view, that's what I want! –xenotalk 22:18, 4 December 2018 (UTC)
Scrunched desktop view on mobile.jpg
  • xeno Did it look like the screenshot at right? If so, I've been having that happen intermittently on my phone. Refreshing the page usually fixes it. ~ ONUnicorn(Talk|Contribs)problem solving 05:53, 5 December 2018 (UTC)
    Thanks ONUnicorn but it is simply the "mobile responsive" view for monobook which was implemented some months ago. In that view, once you're on a talk page I can't figure out how to get back to the article page. –xenotalk 17:54, 6 December 2018 (UTC)

A userscript to allow reversion on mobile[edit]

Just want to put this here in case anybody wants / needs it, I have developed a userscript which allows a editor to undo an edit while on the mobile interface. (Installation instructions here). Comments, criticism, bugs, requests welcomed.Face-smile.svg — fr+ 07:00, 5 December 2018 (UTC)

Thanks everyone, and yeah the phab ticket does explain out my problems. It's hard to read, but is anyone actively working on fixing it right now, or will it need some sort of further community support? I did install the userscript mentioned above, which solves one problem. Thanks! ɱ (talk) · vbm · coi) 19:08, 5 December 2018 (UTC)
There's a team working on it mw:Reading/Web/Advanced mobile contributions, nothing more needs to be done from here. However, know that it's part of a "big" task T198313 consisting of many bugs on mobile user interface. So it will be fixed when it is fixed, but not "right now," of course. –Ammarpad (talk) 23:11, 5 December 2018 (UTC)
, If you add the following hack
var pageName=$('#mw-mf-diff-info a').text();
$('#mw-mf-diff-info a').click(function(e){
    e.preventDefault();
    location.href=mw.util.getUrl(pageName);
});
to your minerva.js the major bug which you mentioned above can be overridden. — fr+ 10:05, 7 December 2018 (UTC)

Maximum volume of a WP article[edit]

I have a question related to the maximum volume of articles. The size of an article on Wikipedia is not infinite, indeed. But, what is the maximum possible volume for an article, potentially/actually? For example, how many typical words (or bytes) a user can put on their own "Sandbox"? — Hamid Hassani (talk) 10:14, 5 December 2018 (UTC)

The software limit is 2 MB = 2048 kB for the wikitext. This should not be used in articles. See Wikipedia:Article size. Wikipedia:Template limits can prevent rendering in some cases. PrimeHunter (talk) 10:28, 5 December 2018 (UTC)
Thank you for your useful advice! — Hamid Hassani (talk) —Preceding undated comment added 11:33, 5 December 2018 (UTC)

Diff highlighting colors[edit]

I find the light blue color used to highlight diff changes within an altered paragraph hard to pick out if the changes is very small, e.g. an added character or punctuation. This makes subtile vandalism hard to detect. Is there any way to select a more intense color? It this better in another skin?--agr (talk) 03:52, 6 December 2018 (UTC)

I have the same problem and definitely support looking into doing something about it. Dhtwiki (talk) 06:02, 6 December 2018 (UTC)
@agr and Dhtwiki: There's another color. Navigate to Preferences → Gadgets → Appearance. Under the appearance header, check the option: Display diffs with the old yellow-and-green colors and designAmmarpad (talk) 07:27, 6 December 2018 (UTC)
There is also the gadget wikEdDiff which gives a different type of diff. The standard diff is still shown but diff pages get an option to also show wikEdDiff. This is often much better when the standard diff is poor. PrimeHunter (talk) 10:22, 6 December 2018 (UTC)
That gadget loads MediaWiki:Gadget-OldDiff.css so if you're not thrilled with those colors, you can put it in your own custom css (User:ArnoldReinhold/common.css) and tweak it. — Preceding unsigned comment added by Amorymeltzer (talkcontribs) 11:28, 6 December 2018 (UTC)

Thanks for all the responses. I tried the "Display diffs with the old yellow-and-green colors and design" and it is a vast improvement. I might try the wikEdDiff gadget in the future, but I like the clear before and after comparison of the default diff. How did the change to the present pale highlighting get made? Vandalism, especially the subtler forms, are a major threat to Wikipedia. Why would we want small edits to be easy to overlook? What would it take to restore the "old yellow-and-green colors and design" as the default or at least publicize the option more widely?--agr (talk) 12:53, 6 December 2018 (UTC)

@ArnoldReinhold: They were made to conform to international accessibility and design standards for colour-blindness, contrast, and other concerns. To change them, you would need to propose an alternative that (a) met or exceeded the current standards, (b) works in all the different contexts, (c) tested well in the user-testing with experienced editors, new users, and people "off the street" from different cultures and societies (conveying the correct understanding and implied concept to almost all the users tested), and (d) is acceptable to the hundreds of different communities who might object to a change. I'm not aware of anyone interested in working on that right now. Jdforrester (WMF) (talk) 15:52, 6 December 2018 (UTC)
You can also go to Special:Preferences#mw-prefsection-betafeatures and enable the visual diff tool; then you can toggle back and forth between the two views. Some changes are easier to spot in one system than the other. Whatamidoing (WMF) (talk) 21:16, 6 December 2018 (UTC)
One problem with the "Display diffs with the old yellow-and-green colors and design" gadget (i.e. OldDiff) is that it makes it more difficult to spot where spaces have been removed or added, as compared to the current default diff highlighting. This is because the default one indicates removed and added characters in two ways - boldface and a coloured background, whereas OldDiff uses boldface and a coloured foreground - but spaces don't show up, because they cannot be bolded and have no foreground either. Fortunately, it's quite easy to adapt OldDiff so that removed and added characters have a differently-coloured background in addition to boldface and a coloured foreground. First enable the gadget, and then add these two rules
/* make it easier to spot spaces added/removed in diffs */
td.diff-deletedline del.diffchange { background-color: #cfc; }
td.diff-addedline ins.diffchange { background-color: #ffa; }
to your Special:MyPage/common.css. --Redrose64 🌹 (talk) 21:18, 6 December 2018 (UTC)

First, thanks to everyone for their responses, and especially @Jdforrester (WMF): for taking the time to explain the constraints WMF sees. In my view diff is not some minor editing feature, it is central to the integrity of Wikipedia. Fortunately, these days most vandalism is easy to spot and correct. But the Internet is getting more ugly and the very idea of objective information is under attack, so we may see more sophisticated and organized vandalism in the future. We depend on volunteer editors and the time they devote to reviewing page changes is a precious resource. Anything that diminishes their productivity should be cause for concern. At least we have a viable option already. The change suggested here solved the problem I had, but I'm pretty far out there on the spectrum of motivated editors and it took me a while to to ask about a better diff. Most editors won't bother. One solution for now that doesn't get us into an international accessibility and design standards morass is to make the "Display diffs with the old yellow-and-green colors and design" easier to find. For starters, pick a better name, maybe "Alternative diff display with enhanced change visibility for some". The modification Redrose64 (talk · contribs) suggested above could be incorporated. There is no need to cling to the past. Longer term, I think graphics designers could come up with an effective way to highlight small changes without getting into color wars—drawing a light grey circle or oval around the changes, for example. Fixing this problem for one editor is not enough.--agr (talk) 18:27, 7 December 2018 (UTC)

You can't draw a circle or oval, but you can draw a rectangle - with rounded corners.
td.diff-deletedline del.diffchange,
td.diff-addedline ins.diffchange { border: 1px solid red; }
This is for Special:MyPage/common.css as previous, it does not require the previous pair of rules as well. --Redrose64 🌹 (talk) 21:27, 7 December 2018 (UTC)

Extended-confirmed user criteria[edit]

This user has over 500 edits and began editing years ago, yet they are not listed as having extended confirmed user rights. They are not currently blocked. Is this a bug, or is there some other undocumented criterion for being extended confirmed besides 30 days on the project and 500 edits? wbm1058 (talk) 12:39, 6 December 2018 (UTC)

@Wbm1058: the "check" for "promotion" to extended confirmed happens when an edit is made. If that account were to make any edit now it would be automatically granted. Note it hasn't made any edits in about 9 years, long before the EC system was created. — xaosflux Talk 12:52, 6 December 2018 (UTC)
@Xaosflux: Do you know the specific cutoff date for when extended confirmed went live? wbm1058 (talk) 12:57, 6 December 2018 (UTC)
@Wbm1058: Looks like the first editor to get autopromoted was on 2016-04-05T23:17:43 - so very shortly before then. — xaosflux Talk 13:00, 6 December 2018 (UTC)
See also phab:T126607. — xaosflux Talk 13:02, 6 December 2018 (UTC)
  • Indeed. Thanks, this log view confirms that's when the switch was flipped on. wbm1058 (talk) 13:31, 6 December 2018 (UTC)
    Those early log entries include many people who were well past the 500-edit threshold by then, I recognise some names who have over 100,000 edits at present. --Redrose64 🌹 (talk) 21:52, 6 December 2018 (UTC)

Special pages for the Education Program – what happened to them?[edit]

Some time ago I indexed the Special pages at Help:SpecialPages. Now I see that a bunch of them are now red links, with no redirects left behind. What happened? What's the status of the Education Program? From all the presentations relating to this at the October Wikiconference North America, I thought it was still an active program.

We should check "what links here" to each of these, to clean up the loose ends. – wbm1058 (talk) 17:18, 6 December 2018 (UTC)

I noticed this because Wikipedia:Training/For educators/Setting up your course 3 links to Special:Institutions. Hmm, what-links-here doesn't seem to support the Specials. wbm1058 (talk) 17:26, 6 December 2018 (UTC)

Wikipedia:Student assignments#Examples of best practices says: "An example of a thorough course page design can be seen at Saint Louis University: Signal Transduction. You can adapt it from this page. Another good example is North American Environmental History."

I think [[Education Program:Saint Louis University/Signal Transduction (SP13)]] used to be a functioning link. Was there an Education Program namespace, and has everything that was there been vaporized? Oh, I see – per Wikipedia:Namespace#Not installed, "The Education Program namespace (prefix Education Program:) was uninstalled in 2018, and replaced with the Programs & Events Dashboard."[1][2]

References

So what should be done about the notice banners on pages like Talk:G protein-coupled receptor where the banner

This article is part of an assignment from Saint Louis University in Spring 2013 (see the course page for more details).

now links to a dead end, with not even anything deleted there that administrators can see. – wbm1058 (talk) 17:51, 6 December 2018 (UTC)

@Wbm1058: The old Education Program extension was finally removed from production on 27 September 2018 after the decision to switch it off was made in February 2016. We had a final note here in Tech News 47, it appears, after several reminders. Jdforrester (WMF) (talk) 18:41, 6 December 2018 (UTC)
m:Tech/News/2018/06 – 2018, week 06 (Monday 05 February 2018)
The Education Program extension will be removed on 30 June. It is replaced by the Programs and Events Dashboard. [4][5] (found previous Tech News notice) wbm1058 (talk) 14:13, 7 December 2018 (UTC)
m:Tech/News/2018/47 – 2018, week 47 (Monday 19 November 2018)
The Education Program extension was removed from all Wikimedia projects. The database tables used by the extension will be archived. This will happen in a month. If you want the information on your wiki you should move it to a normal wiki page. phab:T174802
Comment. Linking to the Wikipedia article on database tables isn't particularly helpful here, a pointer to the actual tables themselves would be more helpful. How can anyone "move it to a normal wiki page" if they can't even find it? wbm1058 (talk) 19:33, 6 December 2018 (UTC)

Were the records for these old courses ported to the new Programs & Events Dashboard, if so, how do we find them there? wbm1058 (talk) 17:53, 6 December 2018 (UTC)

@Wbm1058: No, I believe not. Program leaders were told (for years) to migrate to the new system. Jdforrester (WMF) (talk) 18:41, 6 December 2018 (UTC)
The entire program was deprecated, there are some references to dumps and archives you can follow up on the linked tasks to phab:T125618. — xaosflux Talk 18:44, 6 December 2018 (UTC)
  • phab:T188407 – Document clear method for users to access historical data from the education extension. From a glance, it's unclear to me if that's been done, or will be done, and who will do it. Just noting from the history of this one page, it was edited only by former staff member Sage Ross (WMF) who is no longer around to clean up after himself. Will anyone from (WMF) be taking care of this? wbm1058 (talk) 19:05, 6 December 2018 (UTC)
  • phab:T200391Cleaning up after Education Program needs triagewbm1058 (talk) 19:43, 6 December 2018 (UTC)

So, if the database tables can be located and moved to a normal wiki page, then for the example shown above, the logical normal wiki page to move this to is Education Program:Saint Louis University/Signal Transduction (SP13), since the notice placed near the top of Talk:G protein-coupled receptor already points to that page. Except that the page is now in mainspace. Otherwise, if everything that pointed to is to remain dead and buried, then I suppose the solution is something like this edit I made to Talk:Human cloning. – wbm1058 (talk) 15:05, 7 December 2018 (UTC)

@Sage (Wiki Ed): the entry point Wikipedia:School and university projects needs to be updated to be current. Thanks, wbm1058 (talk) 15:31, 7 December 2018 (UTC)

Template:Course assignment is deprecated, but it's transcluded on 4293 pages. – wbm1058 (talk) 15:56, 7 December 2018 (UTC)

I created Category:Pages linking to the Education Program namespace, which is now being populated by Template:Course assignment. – wbm1058 (talk) 17:09, 7 December 2018 (UTC)

I don't know if it helps any, but Wikipedia:Namespace was updated soon after. --Redrose64 🌹 (talk) 20:36, 7 December 2018 (UTC)

int: changed?[edit]

Something seems to have happened to {{int:}}. In the past, I could either include the MediaWiki: namespace, e.g. "{{int:MediaWiki:Gadget-charinsert}}"; or omit it, e.g. "{{int:Gadget-charinsert}}" and both would operate the same way - to transclude MediaWiki:Gadget-charinsert in the language of the reader (or in the site language if there is no translation), like this: "CharInsert: add a toolbar under the edit window for quickly inserting wiki markup and special characters (troubles?)". Now, if the namespace is included, it displays the page name inside single guillemots instead, i.e. "⧼MediaWiki:Gadget-charinsert⧽". Is this a thursday change? --Redrose64 🌹 (talk) 19:36, 6 December 2018 (UTC)

@Redrose64: There were no deployments this week, so it's not a Thursday change.
Have you tried to use it recently, as in not today but in the last week or 3? Possibly something changed in earlier weeks but you only just noticed?
That usage isn't mentioned in the docs at mw:Help:Magic_words#Transclusion_modifiers so I'm not sure if it was ever officially supported?
Where is it being used? I can only see a couple of instances using some insource searches... . HTH. Quiddity (WMF) (talk) 22:27, 6 December 2018 (UTC)
The current MediaWiki 1.33.0-wmf.6 at Special:Version is from last Thursday: mw:MediaWiki 1.33/Roadmap#6. I haven't seen documentation saying {{int:MediaWiki:Gadget-charinsert}} is allowed. It didn't work when I tried it years ago, and it doesn't work at a wiki with MediaWiki 1.27.3 from May 2017. I haven't tried it recently. {{int:MediaWiki:Gadget-charinsert}} tries to display MediaWiki:MediaWiki:Gadget-charinsert . It doesn't exist so it displays the page name without namespace, as normal for non-existing MediaWiki pages. MediaWiki:MediaWiki:Gadget-responsiveContent.js does exist [6] so {{int:MediaWiki:Gadget-responsiveContent.js}} displays it:
/* #REDIRECT */mw.loader.load("//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-responsiveContent.js\u0026action=raw\u0026ctype=text/javascript");
PrimeHunter (talk) 22:53, 6 December 2018 (UTC)
Consider this corrective edit: the passage concerned had displayed correctly at the time that I made the original post. --Redrose64 🌹 (talk) 23:41, 6 December 2018 (UTC)

Authority control RfC[edit]

There is an RfC at the policy village pump on the function of {{Authority control}}. Please post comments/opinions there. Thanks, Jc86035 (talk) 10:58, 7 December 2018 (UTC)

Email information revealed when creating an account with temporary password - proposing email address be hidden from user creation log[edit]

Resolved: Issue resolved, and further damage prevention done by Xaosflux by creating MediaWiki:Createacct-reason. Steel1943 (talk) 17:48, 7 December 2018 (UTC)

Well, I did not expect this to happen. I recently created a new test account for myself, User:Steel1943 (tester). To create the account, I decided to choose the option which sends a temporary password to an email address, and went through that process to create the account. However, I just realized what a big mistake that was...

In the account’s user creation log, the email address I chose to send that temporary password is listed in its log. Well, if I knew that was going to happen, I would have never chose the temporary password option. Now, anyone who knows how to navigate Wikipedia can easily find the email address associated with that account (so now I have to change the email address.) I had no warning or anything if that nature letting me know that the email address I provided was going to be permanently displayed in such a manner; if I knew that it was, I would have never chosen the "email temporary password" option. Now, I have to change the email account associated with that account, as well as probably never use that email account ever again for privacy reasons.

I propose that the email address chosen while utilizing the temporary password option not be displayed in the user creation log when going through account creation. This is an unintended breach of privacy for editors creating accounts.

Anyways, I’m posting this in the "technical" board since this happening again can probably be changed on a MediaWiki page, etc. If anyone feels this needs to be moved to a different board, by all means. Steel1943 (talk) 17:21, 7 December 2018 (UTC)

@Steel1943: it doesn't look like this is normal (per this log) I suspect it was a process issue (that may need better directions) on the interface? — xaosflux Talk 17:27, 7 December 2018 (UTC)
Did you put the email in the 'Reason' field possibly in error? We can add message text that the reason is publicly logged perhaps? — xaosflux Talk 17:29, 7 December 2018 (UTC)
Label is at MediaWiki:createacct-reason. — xaosflux Talk 17:31, 7 December 2018 (UTC)
(edit conflict) @Xaosflux: I think that’s what I did. Gah, I cannot believe that I did that. (I must have thought that the "Reason" field was an email confirmation field, like some web sites have.) Anyways, if you were the one that hid the edit summary (or whoever did), thank you. Steel1943 (talk) 17:35, 7 December 2018 (UTC)
@Steel1943: OK, at least not a bug, I revdel'd it and sent it to OS for handling. I also updated that field label to note it was publicly logged. Go to know we don' have a bug, happy editing. — xaosflux Talk 17:36, 7 December 2018 (UTC)

Structured Data on Commons Newsletter - Fall 2018 edition[edit]

Welcome to the newsletter for Structured Data on Wikimedia Commons! You can update your subscription to the newsletter. Do inform others who you think will want to be involved in the project!

Community updates
Things to do / input and feedback requests

Current:

Since the last newsletter:

Presentations / Press / Events
Partners and allies
  • The info portal on Structured Commons now includes a section on GLAM (Galleries, Libraries, Archives and Museums).
  • We are currently planning the first GLAM pilot projects that will use structured data on Wikimedia Commons. One project has already started: the Swedish Heritage Board researches and develops a prototype tool to provide improved metadata (translations, data additions...) from Wikimedia Commons back to the source institution. Read the project brief.
  • The documentation for batch uploads of files to Wikimedia Commons will be improved in 2019, as part of preparing for Structured Data on Wikimedia Commons. To prepare, the GLAM team at the Wikimedia Foundation wants to understand better which types of documentation you already use, and how you like to learn new GLAM-Wiki skills and knowledge. Fill in a short survey to provide input!
Stay up to date!

-- Keegan (WMF) (talk)

Message sent by MediaWiki message delivery - 17:58, 7 December 2018 (UTC)

Swiss flag too big[edit]

Hey, does anyone have any suggestions how to get each year in this table parallel? It seems that the flag of Switzerland is just slightly too big for a cell. Pelmeen10 (talk) 13:31, 8 December 2018 (UTC)

Template:Country data Switzerland specifies the height of the Swiss flag as 16px (16 pixels), even though Template:Flagicon states that flags should be no taller than 15px. This one-pixel difference is causing the problem that you see. You could maybe set the row-heights manually, but you still have the double-height rows from ties to deal with, and long names like "Alexandre Bilodeau" causing cells to be double-height, at least in my browser. – Jonesey95 (talk) 13:55, 8 December 2018 (UTC)
I made some edits for you to align the rows; they should be aligned on most screens now. Feel free to revert if they are not to your liking. – Jonesey95 (talk) 14:26, 8 December 2018 (UTC)

Special:Badtitle/NS447:Stanford University/Technology entrepreneurship (2014 Spring)/Course description[edit]

Initial page reported[edit]

Resolved: This specific page has been deleted. — xaosflux Talk 18:32, 8 December 2018 (UTC)

I came across Special:Contributions/YOUNG_DIAMOND and noticed the creation of the following page: Special:Badtitle/NS447:Stanford University/Technology entrepreneurship (2014 Spring)/Course description. It appears as a redlink here, but the creation of this page is listed on this account's contributions page and the following diff: Special:Diff/619755755. Does anyone know what's going on here, and if I can't edit this page, how was it created? Thanks, 72 (talk) 15:37, 8 December 2018 (UTC)

@72: I think this will have to be deleted on the back end, I've opened phab:T211478 to address, thank you for reporting. — xaosflux Talk 16:13, 8 December 2018 (UTC)

It seems like Badtitle is the new name for the Education Program namespace. See #Special pages for the Education Program – what happened to them?wbm1058 (talk) 16:44, 8 December 2018 (UTC)

That page only had one revision, with one word. I think I got it deleted via the API (see log). — xaosflux Talk 16:51, 8 December 2018 (UTC)

Additional examples[edit]

Sometimes WYSIWYG editor doesn't open[edit]

Trying to edit article's section sometimes gives progress bar that stucks at some point. At the moment I cannot edit page ru/Си_(язык_программирования). It always stucks editing ″Динамически выделяемая память″ subsection. I tried to refresh page but it doesn't help. I assume it caused by huge page size. Editing subsection in code mode works fine. D6194c-1cc (talk) 06:18, 9 December 2018 (UTC)

What progress bar? I never get one when editing. I don't see the point either - how would it know how much I had edited? --Redrose64 🌹 (talk) 08:46, 9 December 2018 (UTC)
I assume the editor is talking about the progress bar as a large page is processed for visual edit mode when one clicks the "edit" link. Galobtter (pingó mió) 08:50, 9 December 2018 (UTC)
It appears to be working for me. Are there any errors in your javascript console? --AntiCompositeNumber (talk) 15:52, 10 December 2018 (UTC)

More populated category redirects[edit]

The following category redirects are proving awkward to fix:

Is anyone able to fix the problems or at least identify what needs adjusting? Timrollpickering 13:31, 9 December 2018 (UTC)

The user page in the final category assigns its category within User:Sceptre/modules/boxes.css. It's full-protected. I fixed the other pages in that category. – Jonesey95 (talk) 14:26, 9 December 2018 (UTC)
Category:WikiProject Articles for creation participants is now empty. — xaosflux Talk 14:41, 9 December 2018 (UTC)
Not sure what was wrong with the first one but deletion and recreation solved it. I'll try the others. Timrollpickering 16:31, 9 December 2018 (UTC)
Hmm - adding and removing my sandbox ultimately did the trick. Odd. Timrollpickering 16:36, 9 December 2018 (UTC)
Yes, sometimes it seems you need to make such "WP:Null edits" to clear a category, if somehow the "job queue" missed them. wbm1058 (talk) 16:42, 9 December 2018 (UTC)

Two other redirects that have piled up. These language categories are a pain because of the convoluted generation when the language is a redirect to an alternate name.

Timrollpickering 15:01, 10 December 2018 (UTC)

Fixed the first one. – Jonesey95 (talk) 15:43, 10 December 2018 (UTC)
For the second one, I don't understand why the category redirect goes in the direction it does. The en.WP name of the language appears to be "Mandarin Chinese", per the article header and this naming convention page. – Jonesey95 (talk) 15:46, 10 December 2018 (UTC)
Your edit on the first one was reverted. On the second, it got turned into a redirect back in July 2017 - it's probably best to undo this for now. Timrollpickering 11:59, 11 December 2018 (UTC)
My first edit was technically reverted, but the editor who did so actually turned my deletion into a commented section of text, achieving the same effect that I achieved. I agree with your fix for the Mandarin Chinese category. – Jonesey95 (talk) 13:47, 11 December 2018 (UTC)

Further cases:

Timrollpickering (Talk) 14:41, 12 December 2018 (UTC)

It's not Template:Babel but the babel extension which needs these last three categories. They are part of a scheme that is intended to be the same across all Wikimedia wikis, as I have explained (several times) before, sometimes on this page (or another pump), sometimes at a CFD, but more often at Template talk:Babel. --Redrose64 🌹 (talk) 16:47, 12 December 2018 (UTC)
Pinging Trappist the monk for Category:Articles containing Baruya-language text. This appears to be caused by Module:Language/data/ISO 639-3, but I don't know if reversing the order of the byr language names is the right fix. – Jonesey95 (talk) 02:42, 13 December 2018 (UTC)
The correct place to override ISO/IANA names and codes is Module:Lang/data because the ISO/IANA modules are periodically updated by script from data retrieved from the ISO custodians and from IANA; reapplying all of the necessary fixes to those data would be a monstrous pain. I have pointed byr so that {{lang|byr|...}} categorizes to Category:Articles containing Yipma-language text. Karuka may now require editing but I am unqualified to do that. Similarly, Yipma language could use a brush-up.
Trappist the monk (talk) 11:35, 13 December 2018 (UTC)

I've listed the User cats at Wikipedia:Deletion review/Log/2018 December 13#Category:User simple-N to try to sort out the problem. Timrollpickering (Talk) 14:36, 13 December 2018 (UTC)

Time-sensititive templates[edit]

How to make a template sensitive to the time since it was added to a page? I mean: the template should show some content when originally added to the page, but the contents should change after n days. SD0001 (talk) 18:26, 9 December 2018 (UTC)

A template has no way of telling how long it has been on a page. It would need a parameter telling when it was added, or when it should display differently like {{Show by date}}. Editors could add the date, or the template documentation could say to use substitution with the template using code for the current day to save the time it was substituted in a parameter for another template. See Category:Date mathematics templates, mw:Help:Magic words#Date and time, mw:Help:Extension:ParserFunctions##time for some available features. PrimeHunter (talk) 19:34, 9 December 2018 (UTC)
@SD0001: Check also subcategories (Category:Date-computing_templates_based_on_current_time - Show by (date), Category:Date-computing templates‎ - After templates might be what you're looking for, H:SUBST might be needed for passing dates). --MarMi wiki (talk) 19:37, 9 December 2018 (UTC)
You might also check out the work done in Template:Db-g13. I have an inkling what this may be for... ~ Amory (utc) 01:52, 10 December 2018 (UTC)
This was for {{Old prod full}}, yeah ... but not on the top of my to-do list though ... SD0001 (talk) 21:28, 11 December 2018 (UTC)

Dark theme and math readability[edit]

Hello. I would like to make a suggestion for readability.

As Windows 10 has just implemented a dark mode. the formulas and scientific equations for anything related to maths or science come out in black. this is very hard to read, since it is a black text on a dark grey back ground. Can you please help.

Thanks — Preceding unsigned comment added by 2A02:C7F:2C68:2100:F903:6BE4:4DEB:AA6 (talk) 18:40, 9 December 2018 (UTC)

Registered users have the option "Use a black background with green text" at Special:Preferences#mw-prefsection-gadgets. Maybe this gadget works better with the dark mode. The gadget uses MediaWiki:Gadget-Blackskin.css which includes this code:
/* Fix background of Tex images, which are black on transparent. */
.mw-body img.mwe-math-fallback-image-inline {
    background-color: #fff;
    filter:invert(100%) hue-rotate(180deg);
    border:none;
}
You can test the gadget without an account by adding ?withCSS=MediaWiki:Gadget-Blackskin.css to a url, e.g. https://en.wikipedia.org/wiki/Help:Displaying_a_formula?withCSS=MediaWiki:Gadget-Blackskin.css. If you create an account but don't want the gadget then you can also try to just save the above code in your CSS. PrimeHunter (talk) 19:15, 9 December 2018 (UTC)


ADDITIONAL: Does not work entirely with the Dark Mode Chrome extension. Graphics appear green on white. — Preceding unsigned comment added by 2A02:C7F:2C68:2100:F903:6BE4:4DEB:AA6 (talk) 21:09, 9 December 2018 (UTC)

This is a known issue, cf. T111222. This snippet might be useful. Pkra (talk) 20:51, 10 December 2018 (UTC)

problem with dates[edit]

I've had this problem in the past and though I tried to search the archives cannot find the thread or the fix. Not sure why this happens only with Arabic (recently did a Hebrew translation, another right-to-left-reading language, without the problem), but when I use the language template on this article Ashraf os-Saltaneh, it is as if the ending }} of the template doesn't stop the foreign text insertion, because the dates 1863-1914, always flip to 1914-1863. Probably not explaining this well, but she couldn't possibly have been born in 1914 and died in 1863. Can someone please tell me how to stop the dates from flipping? Thanks!! SusunW (talk) 22:33, 9 December 2018 (UTC)

I've fixed it for you. The trouble is that numerals can be regarded as part of left-to-right or right-to-left text, although the numbers display the same order in both, so the text processor has to rely on context to determine which applies. I also took the liberty of changing the language to Persian, as the subject is clearly Iranian. --NSH001 (talk) 23:28, 9 December 2018 (UTC)
Thank you! Totally appreciate the help. SusunW (talk) 23:30, 9 December 2018 (UTC)
"Persian: اشرف السلطنه‎‎, 1863–1914" is working correctly, or you would like it to work without the {{lrm}} as well? Gryllida (talk) 23:58, 9 December 2018 (UTC)
Sorry, was replying before seeing the discussion above. Please disregard. Gryllida (talk) 23:59, 9 December 2018 (UTC)

Interwikilink for users?[edit]

Is there a reason why, if you go to User:Headbomb, you don't get interwiki links to my other wikipedia accounts (e.g. fr:Utilisateur:Headbomb?) in the sidebar? (Same for say User talk:Headbomb having interwikilinks to fr:Discussion utilisateur:Headbomb)? That seems like it would be a useful feature. Headbomb {t · c · p · b} 12:50, 10 December 2018 (UTC)

Because you did not add the links. Add [[fr:Utilisateur:Headbomb]] (or even [[fr:User:Headbomb]]) on your userpage, the sidebar link will appear. Do the same on the talkpage. –Ammarpad (talk) 14:56, 10 December 2018 (UTC)
Yeah, but the question is "why should I be doing this in the first place?". We have global accounts now. This should be handled by the system automatically, either via wikidata, or via some other thing. Headbomb {t · c · p · b} 15:18, 10 December 2018 (UTC)
And "why do I need these links" - is because there are no automated integrations (e.g. on wikidata) between accounts (WMF users are currently out of scope of wikidata). — xaosflux Talk 15:19, 10 December 2018 (UTC)
Also, @Headbomb: would you want 116 links on your page? I wouldn't want 736 on mine! — xaosflux Talk 15:22, 10 December 2018 (UTC)
More response to your second question: even in mainspace (the main reason for interwiki link), articles are not linked automatically. All interwikis on wikidata are either added by human or bot configured by human to do so. The software has no such configuration to automatically link pages across wikis. But you can request so on phabricator and likely consensus first. –Ammarpad (talk) 15:40, 10 December 2018 (UTC)
See wikidata:Wikidata:Requests for comment/Inclusion of non-article pages#User pages and wikidata:Wikidata:Project chat/Archive/2013/03#Why an Exception on User pages? for old discussions about allowing Wikidata items for user pages. PrimeHunter (talk) 20:04, 10 December 2018 (UTC)

Tech News: 2018-50[edit]

17:33, 10 December 2018 (UTC)

Using templatestyles inside of wikilink text[edit]

has this been discussed somewhere? in particular, it has been brought to my attention that [[A|<templatestyles src="smallcaps/styles.css"/><span class="smallcaps">a</span>]] doesn't work, while <templatestyles src="smallcaps/styles.css"/>[[A|<span class="smallcaps">a</span>]] does work, which means that {{smallcaps}} won't work for link text. thank you. Frietjes (talk) 18:08, 10 December 2018 (UTC)

@TheDJ and Izno: Frietjes (talk) 21:14, 10 December 2018 (UTC)
okay, found phab:T200704. is this going to be fixed, or do we need to stop using templatestyles for inline text styling? Frietjes (talk) 21:19, 10 December 2018 (UTC)
@Frietjes: Whether it's changed or not, this can be worked around (as you identified--move the template outside the link). I don't know if it will be fixed. --Izno (talk) 00:13, 11 December 2018 (UTC)
Frietjes I'd consider small caps the template version of an HTML element. It has no meaning, no context etc. As such they are basically inline styles yes. I'd vote to not use template styles for now, for such templates... —TheDJ (talkcontribs) 08:59, 11 December 2018 (UTC)
Izno, what is the fix for 6th Armoured Division (South Africa) which uses [[Ultra|{{smallcaps|Ultra}} intercepts]]? Frietjes (talk) 13:44, 11 December 2018 (UTC)
@Frietjes: Not to style something with small caps text per MOS:SMALLCAPS (see the article in question, Ultra, which has no such curious styling). --Izno (talk) 17:34, 11 December 2018 (UTC)
Izno, that was just one of 40 or so examples that I found that cannot be fixed by moving the {{smallcaps}} outside of the link. others include Pseudoephedrine, Monosaccharide, Hexose, Esperanto orthography, S-type star, ... TheDJ's suggestion to go back to the non-templatestyles version seems to be the best idea for the near future. Frietjes (talk) 17:47, 11 December 2018 (UTC)
Of those, I see one article with a good use of the template (that's the article on orthography), but even there the specific link to the person or thing in question could be removed without loss given the context. I disagree entirely with the suggestion as a result. --Izno (talk) 17:59, 11 December 2018 (UTC)

Categorization that will not update[edit]

Template:Taxon italics has been put into two categories. If you go look at them (e.g. Category:Scientific name templates), the template doesn't appear in the category listings, but the categories do appear on the template page. These problems usually seem to go away after a few hours, but in this case it's been days. Is there a) a way to force it to update, and b) a way to prevent this from happening? Logging in and logging out have no effect on it, nor does removing and re-adding the categories, making tiny edits to the template and category pages then re-saving, nor purging the category and the template (and its documentation). It's just stuck.  — SMcCandlish ¢ 😼  09:28, 12 December 2018 (UTC)

SMcCandlish, a null edit of Template:Taxon italics fixed it. Galobtter (pingó mió) 09:38, 12 December 2018 (UTC)
Yes, you have to edit the page itself to force an immediate update of link tables for the page. A null edit works but not a purge. SMcCandlish only edited Template:Taxon italics/doc where the category is transcluded from. PrimeHunter (talk) 09:43, 12 December 2018 (UTC)
Fargh. It figures that of every step I would think to try I somehow forgot one and it was the one that would actually have worked. Thanks for the info. :-)  — SMcCandlish ¢ 😼  19:15, 12 December 2018 (UTC)

Llanelli - inconsistency between watchlist and page history[edit]

Further to Wikipedia:Village pump (technical)/Archive 170#SECR N class - inconsistency between watchlist and page history, this edit is not showing in my watchlist, but its revert two minutes later is shown. At Preferences → Watchlist, "Expand watchlist to show all changes, not just the most recent" is enabled, so both should be listed. Unlike the previous issue, the page has not been deleted and undeleted in between. --Redrose64 🌹 (talk) 18:25, 12 December 2018 (UTC)

I am able to reproduce it and also found the same thing on mobile device where option to show only the most recent changes doesn't even exist. Opened bug report. –Ammarpad (talk) 06:03, 13 December 2018 (UTC)

Currently disabled: two issues[edit]

About 4:25 pm EST, which is 21:25 UTC, today (December 12), I opened Wikipedia:Reference desk/Humanities, and saw at the top the box that begins:

Editing of this page by new or unregistered users is currently disabled until December 12, 2018 at 8:09 pm UTC

First issue: I believe it is not considered correct practice to write UTC times using the 12-hour clock. WP:MOSNUM#Times of day is silent as to this detail, but whoever wrote the the first example under the subheading Time zones seems to believe it. Could the template that generates this message be changed to display the time, in this case, as 20:09, the same that Wikipedia would use in most other places?

Second issue: I had something to add to an existing thread, and since I knew the semi-protection was due to come off this afternoon, I was just waiting until then. I knew that if I clicked "View source" it would open the page for writing, but I wanted to edit the individual section, rather than the whole page. So I first loaded https://en.wikipedia.org/w/index.php?title=Wikipedia:Reference_desk/Humanities&action=purge in order to purge the cache.

But when I clicked on Yes and the page reloaded, it still said

Editing of this page by new or unregistered users is currently disabled until December 12, 2018 at 8:09 pm UTC

So I purged a second time, and this time the notice went away and I could start a section edit. (And then, on rereading what other contributors had posted, I realized I had nothing to add to what they'd said after all. Oh well, never mind.)

So why didn't the first purge do the job? --76.69.46.228 (talk) 21:48, 12 December 2018 (UTC)

My guess would be that you did the first purge after 2018-12-12T20:09:00Z but before the protection actually expired at 2018-12-12T20:09:27Z (see the log data from the API, which includes the expiry time to the second). Anomie 03:03, 13 December 2018 (UTC)
  • For issue 1, please follow up at Module_talk:Protection_banner#Time_format. This isn't a "bug" in the software, but was placed by template editors - it could need updating. — xaosflux Talk 03:41, 13 December 2018 (UTC)
    • Done. ~ Amory (utc) 12:02, 13 December 2018 (UTC)

And why a CAPTCHA?[edit]

When posting the above item, I had to answer a CAPTCHA. I wouldn't be surprised by that if the URL I cited had been to an outside site, but this one was to Wikipedia itself, and I thought those were exempted. What happened? --76.69.46.228 (talk) 21:48, 12 December 2018 (UTC)

That link should be exempt per MediaWiki:Captcha-addurl-whitelist - can you try this in a sandbox and let us know if it is still an issue? — xaosflux Talk 21:59, 12 December 2018 (UTC)
Looks like gerrit:333365 introduced a bug in SimpleCaptcha::loadText() where passing false for $section (as the calling code does) would start loading section 0 instead of using the whole page. That means the $wgCaptchaRegex check where it tries to count only added instances of the regex will not work right because the $oldtext contains only the lead section while $newtext contains the whole page content. Anomie 03:03, 13 December 2018 (UTC)

Taxonbar throwing Lua error[edit]

I am seeing a red error message: "Lua error in Module:Taxonbar at line 549: attempt to call field 'italicizeTaxonName' (a nil value)." on pages such as Manoba greenwoodi. William Avery (talk) 13:31, 13 December 2018 (UTC)

A null edit fixed it. Looks like an error that got fixed but still present on some pages due to cacheing. Galobtter (pingó mió) 13:39, 13 December 2018 (UTC)
Odd. Thanks. William Avery (talk) 14:16, 13 December 2018 (UTC)

How do I add an option for a second image in an infobox template?[edit]

Hi all

I'm starting to learn more about infobox templates and I'd like to know how I can modify an infobox template to allow a second image, I've read the instructions and looked at examples but I'm not sure and don't want to break anything. Do I simply rename the fields or is there more to it? As an example if I wanted to add an option to add a second image to Template:Infobox dog breed to allow the article to show things like sexual dimorphism, what would I change?

Thanks

John Cummings (talk) 14:51, 13 December 2018 (UTC)

Template in a mess[edit]

Template:Category U.S. State elections by year underpins the US state election category tree which is currently being renamed from e.g. Category:Wyoming elections, 2018 to Category:2018 Wyoming elections. However changes to the template are producing very odd categories - e.g. Category:Wyom elections in the United States by state, Category:Ing electi elections by year and Category:Wyom in ing electi.

Does anyone know how to untangle all this to generate the new category form? Timrollpickering (Talk) 16:46, 13 December 2018 (UTC)