Wikipedia:Village pump (technical)/Archive 171

Support ends for the 2006 wikitext editor

The 2006 wikitext editor will be officially removed next week, on the normal deployment train (i.e., Thursday, 25 October 2018 for the English Wikipedia). This has been discussed since at least 2011, was planned for at least three different months in 2017, and is finally happening.

 
This toolbar is being removed from MediaWiki.

If you are using this toolbar (and almost none of you are), then you will be given no toolbar at all (the 2003 wikitext editor). This default was chosen so that your editing windows will open even faster, and to avoid cluttering the window with the larger toolbars (a particularly important consideration for Wikisource's PagePreviews). Of course, if you decide that you would prefer the 2010 or 2017 wikitext editors (or a gadget like WikEd), then you are free to change your preferences at any time.

Although it is not a very popular script overall, I know that some editors strongly prefer this particular tool for specific reasons, such as regularly using the <sub> or <sup> buttons. If you are one of its fans, then you might want to know that some long-time editors are talking about re-implementing its best features as a volunteer-supported user script. I believe that any announcements about that project will be made at mw:Contributors/Projects/Removal of the 2006 wikitext editor. Whatamidoing (WMF) (talk) 17:36, 15 October 2018 (UTC)

And if you're thinking "Yeah, she said that three times last year..." – No, really, the fourth time's the charm! This time, they really do think it's not going to completely break the wikis. ;-) Whatamidoing (WMF) (talk) 17:40, 15 October 2018 (UTC)
Best of luck, I'll be sorry to see it go! In case you're interested in some anecdata, it was the codeeditor that really did it for me. I like the shortness and simplicity of the old one, but the linting is just too useful for js/css. ~ Amory (utc) 21:03, 15 October 2018 (UTC)
How does one know which toolbar one is using? DuncanHill (talk) 21:37, 15 October 2018 (UTC)
See Help:Edit toolbar. PrimeHunter (talk) 23:06, 15 October 2018 (UTC)
Or see mw:Editor which has an overview of all different editors that are currently supported. —TheDJ (talkcontribs) 17:59, 16 October 2018 (UTC)
I'm with DuncanHill, i'm afraid; completely non-techclever, i simply found a Preference which says "Show edit toolbar" and i've had it active for years, i think. Is that the toolbar that's going? How do i choose another one? The only other Preference i've seen talks about an enhanced toolbar, which rather frightens me.... Happy days (or possibly not, if i don't understand toolbars), LindsayHello 15:41, 16 October 2018 (UTC)
The editing preferences are unusually confusing, even by Wikipedia standards. Some of the pref items silently override the others, and it's especially difficult to explain to new editors. I've proposed improvements at phab:T202921, but unless that wins the m:Community Wishlist (starts in a few weeks), I don't think it will happen any time soon.
Lindsay, if you're a non-technical person, then you might want to consider trying the visual editor again. It is really vastly better than it was back in the day. If you don't have separate "Edit" and "Edit source" tabs already, then look for a little pencil icon (not the highlighter marker pen) and switch to it. It works mostly like a normal word processing document, and is really the only sensible way to do some things, like adding or removing a column from a large wikitext table.
If you prefer wikitext, then I think you would likely be happy with the light blue "enhanced" toolbar. It has been the default for all users since approximately 2010, and it gets used thousands and thousands of times each day with very few complaints.
Finally, if you don't actually use the buttons in the little toolbar (which is not unusual for experienced editors), then your easiest option is probably doing nothing. In that case, the toolbar, which you're already not using, will just go away all by itself. Whatamidoing (WMF) (talk) 17:22, 16 October 2018 (UTC)
P.S. I fully and wholly expect a lot of editors to turn up here on the day in question, who as always likely missed all the announcements, because they just don't follow fora like these. Please keep in mind, that according to the data, last year 1500 en.wp editors making a single edit in a 1 month period had the toolbar enabled. Note this doesn't equal USED the toolbar, many people simply have it enabled because they always have. —TheDJ (talkcontribs) 17:59, 16 October 2018 (UTC)
Of course they will. It's just impossible to keep up with everything. That's why I appreciate it so much when people ping me for interesting discussions. This will also be announced in m:Tech/News on Monday, as well as the Editing newsletter, which will go out next week (Tuesday?).
Schedule update: There's been a slight delay. But it's finally up on the Beta Cluster. It doesn't seem to have broken anything obvious, so it should reach this wiki next WP:THURSDAY.
Tech folks here might want to take a look at what Arkanosis has been doing about a replacement script, especially that edit about a gadget for Monobook users. (Hmm, I wonder whether the copies of gadgets are up to date on the Beta Cluster? If they're not, that might explain why last week's watchlist problem wasn't visible until it hit production.) Whatamidoing (WMF) (talk) 17:37, 24 October 2018 (UTC)
We have a script! See mw:Contributors/Projects/Removal of the 2006 wikitext editor#Alternatives for most of the details.
Also, based upon the conversation at w:fr:Discussion utilisateur:Arkanosis#Page, we probably have some scripts/gadgets that will break. I think that this search will find the gadgets. Calling all interface admins... Whatamidoing (WMF) (talk) 18:00, 29 October 2018 (UTC)
Reminder: It's almost WP:THURSDAY, and this change is riding the deployment train. Whatamidoing (WMF) (talk) 06:03, 1 November 2018 (UTC)

So, and this is me showing my techability again, did this happen or not happen? I'm sure it's past the date Whatamidoing (WMF) mentioned in the opening statement, and it's also after the next Thursday too, but i still have the same toolbar when i edit which i understood was going away. Am i misunderstanding, even less clever than i thought, or did something change the plans? Happy days, LindsayHello 16:13, 2 November 2018 (UTC)

It looks like https://tools.wmflabs.org/versions/ says that yesterday's deployment (the big weekly update of everything) had a problem on the Wikipedias and was rolled back after 10 minutes. My best guess is that phab:T208549 is the reason they reverted it. This change (and all of the others in the weekly update) has been made to all of the non-Wikipedias already, and it will happen here as soon as they re-deploy, which looks like it will be after 18:00 UTC Monday. So you are correct, and it appears that you have a brief reprieve.  ;-) Whatamidoing (WMF) (talk) 19:11, 2 November 2018 (UTC)
Well, unless gadget maintainers figure it out first, with only two days left till deployment it's probably not worth other editors and developers trying to guess what will break when the deployment gets rolled out. Thanks for the heads up. Deryck C. 11:38, 6 November 2018 (UTC)

Update: It happened.

The German Wikipedia appears to have had a problem in a local gadget, and they may not be the only ones. If you encounter complaints, I recommend that your first question be this: Are you talking about the 2006 wikitext editor (picture), or about mw:CharInsert (picture)? Only the blue-gray toolbar at the top of the editing box is supposed to be removed. Access to special characters is meant to remain in place. Whatamidoing (WMF) (talk) 21:20, 6 November 2018 (UTC)

Please let me know if that toolbar gets reconstituted as a user script. I can probably figure out how to do no-wiki tags manually, but the string for hidden comments defeats me, and neither seems to have been included in the "enhanced" toolbar. Numbers using a tool are not a good indication of its usefulness; editors do many different kinds of tasks, using different hardware, and with different technical backgrounds. Yngvadottir (talk) 22:27, 6 November 2018 (UTC)

  • I use monobook with the green on black gadget. The "advanced" toolbar is almost unreadable - white icons on a very pale blue background. It also takes ages to load. Is there an alternative that actually works? Or is this another of those "improvements" that just makes things worse and we are told to be grateful for? DuncanHill (talk) 23:50, 6 November 2018 (UTC)
    • As noted in the comment on 29 October that begins with the words "We have a script!", there is already a replacement user script available. You can follow the directions at mw:Contributors/Projects/Removal of the 2006 wikitext editor#Alternatives to install it in common.js (or your global.js at Meta, if you edit multiple wikis and want it on all projects). It's also possible for any interface admin to turn it into a local gadget. Then you'd only have to open Special:Preferences and tick the box. Whatamidoing (WMF) (talk) 00:09, 7 November 2018 (UTC)
      • The instructions there are almost incomprehensible, and I lack the language skills to translate the French. DuncanHill (talk) 00:13, 7 November 2018 (UTC)
      • Thanks, Whatamidoing (WMF), I actually did look there after posting, and I can read the French. I would have considered asking for help installing something, which would be a first; the warning about damaging my computer by downloading a script has always stopped me, but I really can't do without hidden comments. Nowiki I think I can learn to do manually, and my current laptop allows me to type tildes to sign. But ... guess which button is missing both from the screenshot of the bar and from the script? So the WMF has now forced me to make a wallet card with the code for a hidden comment on it, to carry at all times. Way to go, simply for the sake of making changes. Yngvadottir (talk) 00:37, 7 November 2018 (UTC)
        • Have you looked in the CharInsert/EditTools for the codes you want? It's in between the bottom of the editing window and the top of the Edit summary box. Set the menu to "Wiki markup" if it isn't there already. Whatamidoing (WMF) (talk) 00:53, 7 November 2018 (UTC)
          • This may be the moment to point out I use Monobook. In any event, I doubt such a thing is hidden among chart codes, and I have the alt chars (Latin) chart open all the time in that location for the things where I can't immediately remember the Microsoft ctrl+ code. (My head is actually surprisingly full of codes to get nonstandard things to display, which is why I deeply resent something unique to this site that requires a string of unmemorizable symbols being removed from clickability.) Yngvadottir (talk) 01:08, 7 November 2018 (UTC)
        • Whatamidoing (WMF) Where do I go to make a request for those instructions to be re-written in a way that makes sense , and 2) get the French stuff translated too? It tells me to import things to local media wiki whatever the hell that is, and lots of other stuff that might make sense to you but is meaningless to me. Is there perhaps some kind of "technical" desk where people could get help? DuncanHill (talk) 01:37, 7 November 2018 (UTC)
          • I think the answer to that question depends upon whether you're the only person at this wiki that wants this. If you're not, then it's possible that someone else (i.e., someone with more technical skill than me ;-) would sort it out, and then you could just copy what they did. Whatamidoing (WMF) (talk) 02:47, 7 November 2018 (UTC)
            • WP:ITSNOTTHURSDAYYET. --Izno (talk) 04:12, 7 November 2018 (UTC)
              • 1. ^ this and 2. I asked Amory about this a couple of days ago and she seemed to think that perhaps TheDJ had begun importing it. I also use Monobook and would like to continue doing so. Killiondude (talk) 04:59, 7 November 2018 (UTC)
                Killiondude, I have no intention of bringing that thing back. I'm maintaining more than enough old junk and it's also why I didn't protest the removal from MediaWiki core. If someone prepares all the necessary work, as an iadmin I will of course review and deploy peoples contribution. —TheDJ (talkcontribs) 09:45, 7 November 2018 (UTC)
  • Whatamidoing, DuncanHill is certainly not "the only person at this wiki who wants this", as you're well aware from when you asked a year ago; as you're also well aware, the reason the only people who were using this are people who joined pre-2010 isn't that the 2010 editor is superior, but that the devs forced the slow editor on all new signups and buried the option to change it in preferences so most editors were never even aware that a toolbar existed that didn't take forever to load, and consequently either disabled the new toolbar altogether or put up with waiting for it to load each time. Can you—or someone at the WMF—please explain in a way that doesn't involve my needing to learn French what steps I need to take to re-enable it? ‑ Iridescent 19:42, 7 November 2018 (UTC)
  • DuncanHill, sounds like you have a problem with the green on black gadget. You should ask it's maintainer to improve it. —TheDJ (talkcontribs) 09:46, 7 November 2018 (UTC)
    This should improve the green on black gadget to where it works well enough with WE2010. Seems someone started that work in the past and didn't completely finish it. —TheDJ (talkcontribs) 10:05, 7 November 2018 (UTC)
    TheDJ I don't see any difference - the icons are still almost invisible, white on a pale blue background. I don't have any problems with the green on black gadget until somebody else goes and breaks something else! DuncanHill (talk) 14:29, 7 November 2018 (UTC)
    Now it's changed and I can see the icons. It really is a lot less useful than the old toolbar, especially in the way it hides the cite templates (and then hides parts of them even once you've opened them). DuncanHill (talk) 15:15, 7 November 2018 (UTC)
    And now it's changed back and the icons are invisible again. DuncanHill (talk) 16:30, 7 November 2018 (UTC)
  • Hi all (noting Iridescent and DuncanHill); I've taken the liberty of importing the script that WAID mentioned above into the English Wikipedia and translating it. It's in my userspace right now (I'd need to request interface admin to move it to Mediawiki). Y'all can install it by adding the line: mw.loader.load("/w/index.php?title=User:Writ_Keeper/Scripts/legacyToolbar.js&action=raw&ctype=text/javascript"); to your common.js page. Let me know if there are any issues or concerns, or if I've done something horribly wrong. Writ Keeper  20:15, 7 November 2018 (UTC)
  • Excellent, and thank you. (I suppose there's no way to bring back the "cite" button as well, which IIRC was a separate script? One of my main peeves with the 2010 editor, aside from the slowness to load and the space it took up, was that the citation tools were so much worse than those of the 2006 version.) ‑ Iridescent 20:23, 7 November 2018 (UTC)
  • No worries! If we can dig up the separate script, I can probably convert it over pretty easily. Otherwise, you'll have to describe how the button worked, and I can recreate it. (I always do refs manually, which is probably pretty timewasting.) Writ Keeper  20:26, 7 November 2018 (UTC)
Was the cite button part of Wikipedia:RefToolbar. I too appreciate your work on making the script work, and echo Iridiscent's desire for trhe cite button. DuncanHill (talk) 20:29, 7 November 2018 (UTC)
It looks like it was part of Wikipedia:RefToolbar, but because it auto-detected which toolbar you were using—and the WMF removing "edit toolbar" from preferences has now made us all appear to have toolbars disabled altogether—it's unable to figure out where to display the "cite" button. Seriously, sometimes I wish the WMF would tell us which of their many management consultants told them that "run fast and break things" was the best way to operate, so I can track them down and every Thursday disrupt them trying to go about their work. ‑ Iridescent 20:39, 7 November 2018 (UTC)
@Writ Keeper: Thank you! Does your version include the hidden comment button, or is there any way to add that? Yngvadottir (talk) 20:29, 7 November 2018 (UTC)
Hidden comment should be fairly easy to add. I'll look at both of those. Writ Keeper  20:31, 7 November 2018 (UTC)
@Yngvadottir: You should be good to go for hidden comment. Writ Keeper  20:58, 7 November 2018 (UTC)
Thank you thank you thank you! That appears to have worked. Yngvadottir (talk) 21:04, 7 November 2018 (UTC)
@Writ Keeper: There was a "create redirect" button too, which was very useful. DuncanHill (talk) 21:21, 7 November 2018 (UTC)
Indeed, the "redirect" button was (and is, until now) the one I use most often. Makes it very quick and easy to set up new redirects. Here's the old toolbar, that I really liked:
 
It looks like I might have to spend some time playing around with all the various editor options (apart from VE, which I loathe). Haven't bothered to do this so far, since I use an external editor for most of my editing. A big "thank you" to Writ Keeper for his work on this. --NSH001 (talk) 11:44, 8 November 2018 (UTC)
Implemented the redirect button. Still working on the cite button; it's mostly working, but it's a complicated script and there are some apparently old bugs that need ironing out. @Iri: I've disconnected the URL/DOI/etc. lookup buttons; they connect to an offsite script that I don't know about and can't vouch for. Let me know if that was an important feature for y'all. Writ Keeper  15:55, 8 November 2018 (UTC)
Lookup wasn't something I ever used—I found that because it imported the formatting quirks of the source website (curly quotes, allcaps, etc) it took more time to check its output than it did to input the citation manually field-by-field. I know that trainers use the URL/DOI lookup in training courses for new editors as a "see, citing sources aren't as scary as the raw reference markup makes it look" exercise, but I would imagine they're likely using vanilla default settings so as not to confuse people who've just created the account, so this toolbar won't appear. Paging Redrose64, NeilN, SpinningSpark, LindsayH, Keith D and Diego Moya as the people (other than me) who said they were still using it last time the WMF claimed nobody was still using this, who may be able to give a better idea of whether people consider this functionality important. ‑ Iridescent 17:08, 8 November 2018 (UTC)
Thanks, Writ Keeper. I've always been fond of that citation tool, especially for Google books. I like it better than WP:ProveIt, but I've had to make do with since. howcheng {chat} 17:15, 8 November 2018 (UTC)
@Iridescent: I turned off that toolbar when it got too slow to load. Virtually all of its functionality is available in the "(D) CharInsert: add a toolbar under the edit window for quickly inserting wiki markup and special characters (troubles?)" gadget, which is enabled by default - it amazes me just how many people claim that they can't do something, and all the while it's in that gadget, usually when "Wiki markup" is selected. A few buttons, like the "cite" one, are absent, but I never used that. The interminable whining at Wikipedia talk:Manual of Style/Archive 208#Doesn't MOS:DASH contradict WP:ACCESS? is a similar case of people not knowing that they can use the same gadget to make dashes. --Redrose64 🌹 (talk) 22:20, 8 November 2018 (UTC)
The charinsert box is better than nothing, but it adds an additional layer of complexity with no obvious benefit; as with the 2010 toolbar, the functions are there, but you need to switch to the right page to access them. Yes, it's only one extra click (or two extra clicks if you switch back out of "wiki markup" afterwards), but over time the difference between one click and two adds up. The charinsert tool is particularly user-unfriendly when using a mobile device to edit, which we're always being told is the future, as the buttons are so small and fiddly (and using the 2010 toolbar on a mobile device is also horrible—unless you're in a 4G spot, you can literally watch the buttons load one at a time). ‑ Iridescent 23:50, 8 November 2018 (UTC)
It's no extra clicks if you leave it set to "Wiki markup", which is what I do - I occasionally need the things in Cyrillic or Greek, after which I switch it back to Wiki markup. This set includes all of those in the "Insert" set, which is where it starts if you've never used it, have switched devices, or have zapped your cookies. --Redrose64 🌹 (talk) 00:20, 9 November 2018 (UTC)
  • Hey, allUser:DuncanHillUser:Iridescent, the RefToolbar is ready for trial. Owing to its complexity, it's a separate script from the toolbar itself; you can install it by adding mw.loader.load("/w/index.php?title=User:Writ_Keeper/Scripts/legacyRefToolbar.js&action=raw&ctype=text/javascript"); to your common.js page on a new line, similar to the installation for the rest of the toolbar. Let me know how it works, and if there's anything else missing from it or the toolbar. Thanks! Writ Keeper  19:12, 8 November 2018 (UTC)
  • On some very limited testing, it looks to be working fine. Many, many thanks. ‑ Iridescent 19:17, 8 November 2018 (UTC)
    • Thank you, looking good. Please can you take over from the Foundation? DuncanHill (talk) 19:20, 8 November 2018 (UTC)
    • Thank you so much Writ Keeper. I'm another editor who was still using it and I am eternally grateful :) Pawnkingthree (talk) 20:16, 8 November 2018 (UTC)
      • @Writ Keeper: I've created my common.js page and copied and pasted that code into it. I am using monobook on Chrome and I have the 2010 tab turned off. However it doesn't appear to be showing up for me? The C of E God Save the Queen! (talk) 16:26, 11 November 2018 (UTC)
        • @The C of E: legacyRefToolbar adds a cite button to legacyToolbar which must already be loaded (maybe this should happen automatically). Load both with the below code. PrimeHunter (talk) 16:43, 11 November 2018 (UTC)
mw.loader.load("/w/index.php?title=User:Writ_Keeper/Scripts/legacyToolbar.js&action=raw&ctype=text/javascript");
mw.loader.load("/w/index.php?title=User:Writ_Keeper/Scripts/legacyRefToolbar.js&action=raw&ctype=text/javascript");

MonoBook editing toolbar removed

I haven't had the toolbar visible since last night (the older version, of course), has it been removed from service? I have checked all my browsers and it's gone (no changes to any of my gadgets, enables or beta components). Nate (chatter) 16:38, 8 November 2018 (UTC)

@Mrschimpf: If you mean this toolbar:
 
...then it has indeed been removed. See the #Support_ends_for_the_2006_wikitext_editor section above; I'm currently working to re-implement it as a user script for those that prefer it. Writ Keeper  17:25, 8 November 2018 (UTC)
Thank you, Writ Keeper, I liked that toolbar much better! If you are able to set that up, can you make some kind of announcement here, maybe start a new section heading so we will see it in the history - maybe something along the lines of "Rejoice, you can have your old toolbar back!" 0;-D And include simple instructions (preferably not in French) on how to implement it, for us tech-ignorant folks? --MelanieN (talk) 00:15, 14 November 2018 (UTC)
Thanks; sorry I missed it above (I just knew it as 'the older toolbar' and nothing else, so I didn't think of looking up there). I look forward to having it back in some form. Nate (chatter) 17:39, 8 November 2018 (UTC)
ARGH. So, some time back my software on my tablet updated and changed ...something... so that when I try to add bolding the “old fashioned way” it doesn’t work. Example: ‘’’Bold should be here’’’ but apparently whatever software change went on broke that. So, whatever, I adjusted and started using the toolbar instead. And now it’s gone and I am apparently unable to use bolding or italics. Beeblebrox (talk) 17:47, 11 November 2018 (UTC)
@Beeblebrox: You are using curly apostrophes (and indeed curly quotes too). Besides being advised against in text (see MOS:CURLY), they won't produce the desired markup either. You must use straight apostrophes - like this - for them to work. This is basic Wiki markup, see WP:CHEATSHEET. --Redrose64 🌹 (talk) 21:57, 12 November 2018 (UTC)
 
This is what I see in the editing window, but when I save it it’s ‘’’Bold’’’ and ‘’italics’’
The thing is, when I type them in they look like y always did, but when I save my edit they turn curly and I have no idea why. I’m pressing the same key I always did. Beeblebrox (talk) 21:28, 13 November 2018 (UTC)
I found the issue at some point my settings were changed to include smart punctuation which I have now turned off. Yay. Beeblebrox (talk) 21:42, 13 November 2018 (UTC)
@Beeblebrox: For a feature called 'smart' it's about the dumbest feature I know. I always turn it off in everything when I get a new device (Microsoft Office is painful for this when I just want to post something in complete plain text). Nate (chatter) 03:24, 29 November 2018 (UTC)

Missing edit shortcuts

I've noticed that over the last couple of days I appear to be missing the edit shortcuts (the line of icons above the edit box for lack of a better description) from the edit space in my Chrome browser. I haven't deactivated anything so I was wondering if there is a technical problem in the wiki syntax. The C of E God Save the Queen! (talk) 22:36, 10 November 2018 (UTC)

Yes, see #Support ends for the 2006 wikitext editor above. Killiondude (talk) 22:58, 10 November 2018 (UTC)

Add the 2006 editing toolbar as a community-supported gadget

Hi all, as I've discussed above, I've re-implemented the 2006 toolbar as a user script, and modified the refToolbar script to work with it again. I haven't uncovered any unfixed bugs in my testing, and none of the other editors using it have reported any problems, either. So, I'm proposing to do two things: first, I would add the toolbar itself as a new gadget, and second, I would merge my changes into the existing MediaWiki:RefToolbarLegacy.js, which is currently non-functional after removal of the 2006 toolbar proper and is called by the existing refToolbar gadget entry. This would have the effect of both centralizing the source code for the community-supported 2006 toolbar and making it much easier for users to install it; they would be able to install by simply checking the boxes in their preferences, rather than mucking about in their common.js.

It's important to note that this script/gadget is incompatible with the 2010 toolbar that's currently accessible through the editing tab of preferences; if that option is checked, the 2010 toolbar will overwrite the 2006 toolbar. I would make a note of this in the gadget description.

Here are the changes I've made to the code itself:

  • User:Writ Keeper/Scripts/legacyToolbar.js: diff. The changes here are basically just adding the buttons themselves to the toolbar framework, as well as adding a hook that can be used by other scripts to add their own buttons (the refToolbar uses this hook).
  • User:Writ Keeper/Scripts/legacyRefToolbar.js: diff. Some more substantial changes; minor refactoring, removing the connection and associated UI to an external site that was causing errors with the new CSP, changing to use the mw.toolbar API, including the mw hook.

As mentioned, these scripts are currently usable through importation into one's common.js in the usual way. Any code review, comments, concerns, or suggestions are welcome. As an intadmin, I'm willing and able to take lead for maintaining this script whether it's in the gadget space or my userspace. Thanks! Writ Keeper  18:14, 16 November 2018 (UTC)

Adding pings for feedback: User:Whatamidoing (WMF)User:AmorymeltzerDuncanHillTheDJLindsayHYngvadottirIridescentNSH001Redrose64HowchengPawnkingthreeThe C of EMrschimpfMelanieNBeeblebrox Writ Keeper  18:27, 16 November 2018 (UTC)
  • I'm not competent to judge if the coding is stable, but certainly on using this I've not seen any bugs, issues with functionality or anything that behaves differently than the old toolbar did (other than that some of the text-formatting buttons are missing). ‑ Iridescent 18:36, 16 November 2018 (UTC)
  • Almost all over my head of course, including the merits or even feasibility of integrating it into the Mediawiki Official Options (TM) as you propose. No issues, except that I had no idea what most of the buttons on the old extended toolbar did, so the fact that others miss them is further illustration that we work in many different ways and the WMF really has no idea what-all we do; and therefore I'd of course like to have all those mysterious buttons restored for those who did use them. However what really matters is to say once more: thank you thank you thank you. Yngvadottir (talk) 18:41, 16 November 2018 (UTC)
  • Thank you, Writ Keeper, for your work on this. I shall use either the script or the gadget, whichever is most easily available, as the old edit bar was just right. You certainly are a whizz-bang clever guy, aren't you ~ especially that cool trick of pinging without showing our names! Happy days, LindsayHello 18:38, 16 November 2018 (UTC)
  • I can testify that this works well and restores the look and functionality of the traditional toolbar. I was particularly glad to get the "cite" button back, since I found the citation function of the WMF's new toolbar to be very clumsy. Thank you, Writ Keeper. -- MelanieN (talk) 18:39, 16 November 2018 (UTC)
P.S. Maybe somebody should tell the WMF about beta testing, so they could get some feedback from actual users? Here's a useful introduction to the concept: Beta testing. (Sorry for the sarcasm, but why is it that their "improvements" are so often unpopular with actual editors? And then our heroic volunteer programmers have to step in and improve or work-around the "improvement".) -- MelanieN (talk) 19:08, 16 November 2018 (UTC)
Your contributions say that you haven't been using "the WMF's new toolbar". You've probably been using the eight-year-old one, which (at this wiki, but not at most of them) has a local citation gadget bolted on to it. "The WMF's 2010 toolbar" has the very simplest citation "tool" imaginable: an empty box into which you can type whatever wikitext you want. This animated gif shows the citation feature in the WMF's new toolbar.
I'll see your link and raise you a link to End-of-life (product).   This particular change was not done for the sake of being popular. It was done for the sake of having a responsible sunsetting process, rather than passively waiting until the product suddenly and permanently failed someday.
As for beta testing, the site is http://en.wikipedia.beta.wmflabs.org/, and people are welcome to do beta testing whenever they want. Early Wednesday is usually the best time to get started, as you'll have a week to find problems before the changes would go live. That's also a good place to test gadgets or CSS changes; just ask for the relevant user rights. The French editors used it to develop the replacement script before the change happened, so their transition from "toolbar in MediaWiki core" to "toolbar in the local gadgets list" went almost unnoticed by most users. I don't understand why the other large wikis didn't do the same.
Yngvadottir, I'd really like to see the editing prefs section redesigned. We've had this system of secret overrides for at least eight years, and it needs to stop. You should be able to pick your choice, and not have it overridden by some other tickbox. But this local gadget won't end up in that list of "official" supported editors, because it's a local gadget, and it needs to be maintained locally. The same rules apply to this as have always applied to WikEd. Whatamidoing (WMF) (talk) 19:40, 16 November 2018 (UTC)
The only thing I'm missing is the URL lookup for Google Books in the cite button. Thanks. howcheng {chat} 19:12, 16 November 2018 (UTC)
@Howcheng: unfortunately, that functionality is part of what I removed due to CSP violations as I mentioned above. Basically, that function was linking to an application that was hosted offsite (specifically, at http://reftag.appspot.com/), which performed the actual data retrieval. I don't have write access to that tool, so I can't maintain it or vouch for its security or accuracy. Moreover, using an external program automatically like this is inherently unsafe; even before the WMF disables our ability to do so (which they probably will eventually), it's not really a good idea, so that functionality is unfortunately unlikely to return. Writ Keeper  19:26, 16 November 2018 (UTC)
Yes, they probably will disable that kind of access at some point.
I wonder whether the mw:citoid service could be used instead. It was built to be portable that way. User:Salix alba, you had a script doing that a while ago; what do you think of the feasibility? Whatamidoing (WMF) (talk) 19:43, 16 November 2018 (UTC)
Ooh, that looks really promising! I'll start looking into it. Thanks! Writ Keeper  20:04, 16 November 2018 (UTC)
WP:ProveIt is able to do HTTP queries. It would be worth checking to see how they do it too. howcheng {chat} 20:27, 16 November 2018 (UTC)
Yes its relatively easy to work with mw:citoid you can see my script at Citoid. I've had to change the script a couple of times as the API has changed. --Salix alba (talk): 21:39, 16 November 2018 (UTC)
@Writ Keeper: On the subject of CSP & external loads - The rough plan (which isn't finalized yet) is that we will disallow loading external scripts, but will still allow fetching external non-script data provider the user opts-in (via a special page or something. This is a bit TBD at the moment. Ticket is phab:T208188). BWolff (WMF) (talk) 15:50, 17 November 2018 (UTC)
While I work on incorporating Citoid into the ref toolbar, I'm going to move this into the gadgetspace, since I don't see any opposition. It should be up later today; I'll post here again when it's ready--with pings for people to switch over to the new functionality. Thanks, everyone! Writ Keeper 
User:DuncanHillUser:IridescentUser:YngvadottirUser:LindsayHUser:MrschimpfUser:PawnkingthreeUser:The C of EUser:HowchengUser:NSH001User:BeeblebroxUser:MelanieNUser:SchetmUser:Yankees10User:BilCatUser:MifterUser:Chaheel RiensUser:Keith DUser:TassedetheUser:JuneGloom07User:PonyoUser:MelanieNapologies for the mass ping I've finished transferring the script to gadget space, as detailed at Wikipedia:Legacy_toolbar. Everyone, I recommend uninstalling the user script versions of legacyToolbar and legacyRefToolbar (just blank the associated lines in Special:MyPage/common.js or wherever you installed them) and re-enable them through the Preferences menu. Thanks, all! Writ Keeper  20:03, 28 November 2018 (UTC)
That it excellent, thank you. I hadn't realised how irritating and unfriendly charinsert is to use, until the disappearance of the 2006 toolbar forced me to try to use it. ‑ Iridescent 20:08, 28 November 2018 (UTC)
Thank you for all of your work on this, Writ. It's very appreciated by me and likely everyone else you pinged. Nate (chatter) 20:18, 28 November 2018 (UTC)
Seconded! Tassedethe (talk) 01:36, 29 November 2018 (UTC)
Thanks! It would be nice if more of these editing gadgets were moved to the editing tab of preferences. And I would like an option for the 2006 toolbar above the 2010 wikitext editor. -- Timeshifter (talk) 21:03, 28 November 2018 (UTC)
Thank you @Writ Keeper:. The old toolbar made editing so much easier as it was simple but perfect for the job. I'm glad to have it back due to your tireless work. The C of E God Save the Queen! (talk) 07:02, 29 November 2018 (UTC)

Separate buttons for single and double bracket links in the editing toolbar

My current editing toolbar has a single button for links. It is slow to create links this way. The 2 buttons were much faster.

Is there any editing toolbar that has both buttons? --Timeshifter (talk) 11:07, 13 November 2018 (UTC)

Timeshifter can you explain why this is slow ? I do paste, hit enter and I'm done ? —TheDJ (talkcontribs) 11:59, 13 November 2018 (UTC)
I use the wikitext editor. For internal links I select the internal link text, hit the link button, and then hit enter or "insert link". That is 2 steps. In the past it was 1 step. No "insert link" popup box.
For external links. I have to cut the text or the URL from the wikitext editing window, then click the link button, and paste it into the insert link box, and then hunt around for the other part, and then paste it into the insert link box, and then hit enter or "insert link". It's a nightmare compared to before.
It was much easier until very recently with the old toolbar that had separate buttons for single and double bracket links. I could set up right in the wikitext editing window.
I don't use the visual editor since I usually only do quick little edits that are much faster in the wikitext editor versus waiting for the visual editor to load. Which can be a long time in even articles of average length.
The wikitext editor opens a section almost instantly. And until very recently adding an external link was almost instant too. Single click. No "insert link" popup box.
--Timeshifter (talk) 12:18, 13 November 2018 (UTC)
Timeshifter, well you can also just type the brackets. Even faster and you don't need to move your hand to your mouse. And they are of course right beneath the edit area in the Wikitext section of the char inserter as well. —TheDJ (talkcontribs) 12:20, 13 November 2018 (UTC)
For an [[internal link]] that's 6 clicks versus 1 click. You have to place the cursor on each end. Gotta do that with a mouse if the link is buried in a paragraph. --Timeshifter (talk) 12:28, 13 November 2018 (UTC)
6 ? No... ah. Don't click the [ characters. Choose the drop-down "Wiki markup" and use the [[]] inserter. One click (well two the first time you switch the menu). —TheDJ (talkcontribs) 12:37, 13 November 2018 (UTC)
I am not seeing a drop-down "Wiki markup" in my wikitext editing toolbar. I only see the link button icon consisting of intertwined chain links. --Timeshifter (talk) 12:54, 13 November 2018 (UTC)
 
I uploaded a screenshot of the wikitext editing toolbar I am seeing now. I could not find anything that was exactly what I was seeing in this category:
commons:Category:MediaWiki edit toolbar screenshots
I think this below is close to the wikitext editing toolbar I was using until recently:
 
--Timeshifter (talk) 13:30, 13 November 2018 (UTC)
@Timeshifter: No, I mean this   (italian version, but it looks similar), which is positioned directly underneath the textarea and is a gadget enabled by default for all users. —TheDJ (talkcontribs) 13:51, 13 November 2018 (UTC)
Let me try it here and [here]. OK, thanks a lot. That will work. Would be nice though to have those 2 buttons at the top too, instead of the popup "insert link" box from the top toolbar button which is for newbs, but only slows down experienced editors. I often have to scroll to get to the toolbar. Having my favorite buttons at both the top and bottom would speed things up and allow me and others to make more edits. That adds up. Maybe there could be a way to have custom toolbars. Where I could pick and choose buttons. Kind of like how one can customize Firefox with button placement in various locations of one's choice. I just had to scroll to find the signature button I prefer. The one that puts 2 dashes in front. :) --Timeshifter (talk) 14:28, 13 November 2018 (UTC)

(unindent). @TheDJ: No joy! After a day of use, I find this to be no help. I am usually editing at the top of the textarea in the editing window. But the single-bracket link is at the bottom of the textarea window. So I have select at the top, scroll to the bottom, be careful not to click wrongly in the interim, and then click the [] icon at the bottom. Then scroll back up to do more work. And often the wiki markup dropdown is back to being closed. So many steps, clicks, and scrolls involved just to add a couple brackets.

I am baffled as to how this could get past the MediaWiki developers. I mean it is absolutely basic to wiki editing by wiki editors across many different type of wikis. Experienced editors often use the wikitext editor. And I believe we were promised long ago that the wikitext editor would never be phased out without approval by users. Single-brackets are used all the time in wikis outside Wikimedia. Because external links are often more common than internal links.

I believe there used to be a way in preferences to turn off these popup "aids" such as the insert link popup box.

There is an easy fix. Just add an option in preferences to add those 2 wiki markup buttons to the toolbar: [] and [[]] --Timeshifter (talk) 02:20, 14 November 2018 (UTC)

Well then you should file a ticket in phabricator. —TheDJ (talkcontribs) 08:18, 14 November 2018 (UTC)
OK. See T209487 --Timeshifter (talk) 13:33, 14 November 2018 (UTC)

(unindent). Part of the problem is I no longer see a way to permanently adjust the size of the wikitext editing box. So that I don't have to scroll as much, or at all, to get to the bracket buttons. Dragging the corner adjusts the height of the editing window, but it is not remembered. It seems that wikitext editing is being limited bit by bit. --Timeshifter (talk) 14:26, 15 November 2018 (UTC)

@Timeshifter: The size of the wikitext editing box can permanently be made larger by setting the CSS declarations for width and height (the removal of the user preference for this was a long long time ago). --Izno (talk) 17:39, 15 November 2018 (UTC)
@Timeshifter: This was covered at Wikipedia:Village pump (technical)/Archive 153#Edit box size and, to a lesser extent, at Wikipedia:Village pump (technical)/Archive 169#Hard to scroll down in lower right corner of edit window. In brief: you can use this CSS rule
textarea#wpTextbox1 {
  height: 15em;
  width: 60em;
}
to set a smaller edit box size. It goes in Special:MyPage/common.css. You may need to play with the dimensions, some browsers measure an "em" according to the font size outside the edit box, so a height of 15em will not necessarily give 15 rows within the edit box. In my browser (Opera 36), those dimensions give 12 rows of 94 characters, YMMV. Omit the width: declaration if you want to stick with the default width. --Redrose64 🌹 (talk) 23:48, 15 November 2018 (UTC)
Can you make a gadget for this? --Timeshifter (talk) 06:12, 16 November 2018 (UTC)
@Timeshifter: I can't make gadgets any more. That ability was taken away from myself (and virtually all other admins) a few weeks ago, when they set up the new interface-admin right. Anyway, even if I could, I don't think that it would be a good idea. First, it's very simple - just one CSS rule, no JavaScript; second, the values that you might wish to set will probably be different from the values that others would prefer. Just copy that rule to your clipboard, go to Special:MyPage/common.css, paste it in and save. Then edit the same page and judge whether the size of the edit box is appropriate for your needs, and adjust the values accordingly. You need to save after each adjustment, since no "preview" feature is possible. --Redrose64 🌹 (talk) 11:03, 16 November 2018 (UTC)

(unindent). A simple solution would be to permanently put the 2 one-click link buttons at the very end of the wikitext editing toolbar. This way both logged-in and anonymous users have the fastest wikitext functionality .

Right now on English Wikipedia those 2 one-click link buttons are buried in the menu at the bottom of the page. On the Commons they are buried in a different menu in another location. The 2 one-click link buttons are the first 2 on the left on the top line:

 

This solution is the right thing to do if the goal is to increase the number of total edits on Wikipedia, rather than stay flat or decrease. Every little bit of time saving, simplicity, and clarity helps. See active editors over time:

 

--Timeshifter (talk) 06:12, 16 November 2018 (UTC)

The actual right thing to do is for the parser to simply not care if you use a single or double bracket point to enter a link and do the smart thing regardless. It's fairly trivial for regular expressions to detect content that begins with (http|https|ftp|sftp|gopher) or any other tcp protocol and than assume that its an external link and treat it accordingly. The fact that internal links and external links are handled differently in wikitext is frankly stupid.--Jorm (talk) 06:22, 16 November 2018 (UTC)
Wouldn't it slow down previews and saves in the wikitext editor? If the software had to analyze each link before saving it? For example on country lists with several hundred links in a table section. The beauty of the wikitext editor is that editing, previews, and saves are very fast. Especially compared to the Visual Editor. --Timeshifter (talk) 07:07, 16 November 2018 (UTC)
heh. No. It would not slow anything down in the slightest degree. At all. Every chunk of text is already parsed to that degree of difficulty or worse. --Jorm (talk) 07:11, 16 November 2018 (UTC)
n fact (and don't quote me on this) it might make things faster simply because I expect that it handles the detection between [[ and [ as separate regular expressions: "if it is not [foo bar] then parse against [[foo bar]]"; the right "I don't care how many brackets there are" regular expression may be faster as it could be run as a single regex request. --Jorm (talk) 07:15, 16 November 2018 (UTC)

(unindent). My idea of adding 2 single-click link buttons (single and double brackets) is in contrast to re-enabling the old toolbars. The addition of the 2 link buttons could even be made a default gadget so that people can remove them if they don't like them. But I think most people that try them will keep them.

Many wikitext editors on Wikipedia may not know about them since they were part of the old toolbars that were removed long ago from Wikipedia, and only found later via preference settings and gadgets.

Whereas outside Wikipedia, the old toolbars are the current toolbars in use for wikitext source editing. For example; when source editing on Wikia. From my reading on the Wikia forums most experienced editors on Wikia use source editing much of the time.

Shoutwiki does not have the Visual Editor at all. See the old toolbar in use. Click the edit button on this sandbox page for a wiki on Shoutwiki: http://cannabis.shoutwiki.com/wiki/Sandbox

Wikipedia editors are missing out on how fast link creation is with the 2 single-click link buttons (single and double brackets) in the wikitext editor.

The first 4 buttons in the old toolbars are the ones people use all the time:

 
  • Bold. Italics. Internal link [[double brackets]]. External link [single brackets].

There could be a short quick launch toolbar of around 5 or 6 single-click (no popup aids) commands. It could even be customizable so that people could pick and choose. This way there will be less people desiring the old toolbars. --Timeshifter (talk) 20:39, 18 November 2018 (UTC)

2017 wikitext editor. Keep top toolbar. Add Commons edit tools on bottom

This solves all my problems a lot more simply, and nothing new has to be created. It effectively replaces the 2006 wikitext toolbar.

The 2017 wikitext editor (2017WTE) ("beta features" menu in preferences) makes using a bottom toolbar much more feasible. The editing window fills the whole screen. There is only one scroll bar.

The 2017WTE top toolbar is fixed in place. Scrolling does not move it. It always stays visible. 2017 top toolbar:

An edit tools bottom toolbar could be fixed in place too, and always stay visible:

It is currently in default use at the bottom of the Commons wikitext editing window.

All of those edit tools buttons are single-click (no popup instructions). Just like the old 2006 wikitext top toolbar:

A single-click preview button added to either toolbar would be nice. --Timeshifter (talk) 16:41, 20 November 2018 (UTC)

People like the 2006 wikitext editor because it is lightweight. The 2017 editor is the opposite of that, and (like visual editor) is close to unusable on older or lower-performance computers. --Ahecht (TALK
PAGE
) 17:08, 20 November 2018 (UTC)
@Ahecht: When was the last time you tried using the 2017 editor? The editing team made some significantly performance improvements towards the end of the last year. It used to be a lot slower than it is now, and in fact in many cases now it's faster than the 2010 editor. --Deskana (talk) 22:04, 20 November 2018 (UTC)
It had been a while, and while it's certainly better than it was, it still takes twice as long to load as the 2010 editor. --Ahecht (TALK
PAGE
) 18:57, 21 November 2018 (UTC)
@Timeshifter: We've got this already, except that it looks like a row of links instead of buttons. It is found immediately below the edit window, just above the edit summary. If you don't see it, it is likely that you have disabled it at Preferences → Gadgets where it is described as "(D) CharInsert: add a toolbar under the edit window for quickly inserting wiki markup and special characters (troubles?)", since it is enabled by default. You can style the links to look like buttons if you like, directions are at mw:Extension:CharInsert#Styling except that the place to put those CSS rules is Special:MyPage/common.css and not MediaWiki:Common.css as directed. --Redrose64 🌹 (talk) 20:48, 20 November 2018 (UTC)
It doesn't show up in the 2017 wikitext editor. And if it eventually does show up there, then my selection of the "wiki markup" toolbar needs to stay open when I close and reopen Firefox. So that whenever I go to the Wikipedia wikitext editing window it is available and open for immediate single-click use.
I don't want to have to choose "wiki markup" from the menu every time I open an English Wikipedia wikitext window. I want it opened by default somehow.
And I want separate bold and italic buttons in the top toolbar as in the 2010 wikitext editor.
I would like to combine the best aspects of these 2 edit tools menus:
 
 
I prefer [] and [[]] from the first toolbar.
I want <code><nowiki> from the 2nd toolbar. I used it here, but had to retrieve it from the Commons editing window.
And I want a signature button with 2 dashes in front. --~~~~ Timeshifter (talk) 21:44, 20 November 2018 (UTC)
Mine stays at "Wiki markup" long-term. If yours is switching back to "Insert" when you close and reopen Firefox, that tells me that the relevant cookie has been deleted. --Redrose64 🌹 (talk) 23:22, 20 November 2018 (UTC)
Mine reverts back to "Insert" whenever I close all my Firefox windows. Even though I have "site preferences" unchecked in "settings for clearing history". I have an on-and-off battle with Firefox options. I tend toward severe settings such as "always use private browsing mode". Because opening web pages is much faster when using the severe settings. Combined with Adblock Plus.
And what much of this whole discussion is about, for the most part, is speed.
I suggest that the default setting in the English Wikipedia menu be "Wiki markup" which produces nearly the same result as the default setting in the Commons menu: "Standard". Then the cookie complications don't matter for most editors.
English Wikipedia. "Wiki markup":
 
Commons. "Standard":
 
--Timeshifter (talk) 03:57, 21 November 2018 (UTC)

Show preview. Show changes. One-click buttons needed in 2017 editor

The 2006 editor has something else that is missed. What I miss most in the 2017 wikitext editor (WTE) are the separate one-click buttons for Show preview, Show changes, and Publish. They are in the 2010 wikitext editor:
 

I use "show preview" more than any other command in the wikitext editor. The lack of one-click access to a preview in the 2017 WTE slows me down more than anything else in the 2017 WTE.

In contrast the 2010 WTE has all 3 buttons, the wikitext editing window, and a preview. All on one page. So I can scroll back and forth between the preview and wikitext. To see errors more easily. 2010 WTE is what I am using now to post this message.

I can type in some wikitext, hit preview, and see if it works for me right away. I can do this as often as I want.

It would be much better if 2017 WTE had a "show preview" button that opens up the preview in a different tab.

Wikia, in their "classic editor", opens up the preview as an overlay. When not logged in to Wikia go to a sandbox page and click on "classic editor" from the menu next to the edit button.

That overlay could be a tab within the same page. That way one could quickly click back and forth between the wikitext editor and the preview. Versus scrolling up and down as in the 2006 and 2010 editors.

That scrolling would be difficult in the 2017 editor since the toolbars are fixed. So tabs on the same page would be better. It would be fast too. Everything would be one click. --Timeshifter (talk) 21:23, 23 November 2018 (UTC)

2017 WTE. It comes down to adding a one-click button strip

Now that the 2006 toolbar is back as a gadget on English Wikipedia I see that all of my problems would be solved by putting a one-click button strip on the top or bottom of the 2017 edit window. It would have to stay visible all the time. Not in a menu.

We need both. Menus and one-click buttons.

The Show preview, Show changes, and Publish buttons would need to be on that strip too. Or they could be in the sidebar. Visible all the time that the 2017 editing window is open.

The sidebar might also be the place to put the publishing verbiage (possibly in a menu): "By publishing changes, you agree to the Terms of Use, and you irrevocably agree to release your contribution under the CC BY-SA 3.0 License and the GFDL. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license."

That publishing info and related buttons (preview, show changes, publish) would take over the visible sidebar anytime the 2017 editing window is open. So the sidebar would also be one-click buttons visible all the time. -- Timeshifter (talk) 22:12, 28 November 2018 (UTC)

Hot buttons in the editing screen

Was there any decision to remove the hot buttons (bolding, signature, etc) from the editing screen? I haven't seen them for some time already. Brandmeistertalk 15:04, 29 November 2018 (UTC)

@Brandmeister: are you referring to the editing bar (see discussion above at Wikipedia:Village_pump_(technical)#Support_ends_for_the_2006_wikitext_editor)? If so you can enable this with a gadget now. — xaosflux Talk 15:12, 29 November 2018 (UTC)
Yes, thanks for the link. Brandmeistertalk 15:16, 29 November 2018 (UTC)

Facing an issue with mobile edit

I am a user who used to view articles from my mobile. I haven't yet tried to edit wikipedia through it. I have recently opened wikipedia from my mobile phone through Google Chrome browser. I then took the 'view history' page of a random article. I then tried to thank an edit done by a user. In the text that appears ie. 'Publicly send thanks?', I am seeing it in a too low font. I mean the size. So I suggest you to increase the font size for that specific text including the buttons thanks and cancel. All these changes needs to be made only in that confirmation menu. If this issue is not intended for this section, please mention the place where I can ask this.Adithyak1997 (talk) 09:40, 28 November 2018 (UTC)

@Adithyak1997: Thanks for the report. Could you tell me a little more? It sound like you're using the desktop "skin" and not the mobile one. Is that correct? Do you know what model phone and version of Chrome you're using? I created a task for the engineers to take a look at. Any additional info you can share would be helpful. I'm hopeful that the mobile interface will be more useful to folks such as yourself in the future. The web teams working to improve contributing via the mobile skin this year. CKoerner (WMF) (talk) 16:34, 29 November 2018 (UTC)
@CKoerner: As you said, I was using desktop version in my mobile. While using in mobile view, I am facing two issues:

1)I am selecting the option 'Last edited 1 hour ago by...' present at the bottom of the page which redirects to the history page. My suggestion is to change the link from '1 hour ago' to the greater than symbol as it does not have any function currently.Or else by clicking anywhere in the green colour needs to redirects to the history page. I also have doubt whether anybody is facing difficulty to identify the history of the current page.
2)I think, as done in desktop version, a confirmation message asking whether to publicly send thanks in a shorter version could have been given in that. I don't know whether it will breaks many of the current alignments.
I am using Google Chrome browser of version 70.0.3538.110. My phone is Redmi Note 5 with android version 8.0.Adithyak1997 (talk) 17:33, 29 November 2018 (UTC)

logevents

Is there a way to link to a specific logevent (out of Special:Log)? I manage to get a whole log, I manage to get a log for users/pages/combination of user and page, but I am looking for code to say 'you hit <this log> [here]'? Any suggestions? Note: I don't mind if it comes out of the api, as long as it is the specific logevent I am thinking of. --Dirk Beetstra T C 11:55, 29 November 2018 (UTC)

This is what Enterprisey made User:Enterprisey/links-in-logs to do, although at least on my end it needs some minor fixes to work. ~ Amory (utc) 12:41, 29 November 2018 (UTC)
If you find the log ID for the entry (e.g. from the API or the data-mw-logid attribute on the <li>), you can then link to it by specifying the logid parameter in the URL, like this. The script Amorymeltzer linked looks to automate that process. Anomie 13:20, 29 November 2018 (UTC)
@Anomie: that helps: https://en.wikipedia.org/w/index.php?title=Special:Log&logid=1 is what I was looking for. Thanks! --Dirk Beetstra T C 13:26, 29 November 2018 (UTC)
Amorymeltzer & Beetstra, let me know if it works now. Enterprisey (talk!) 04:42, 30 November 2018 (UTC)
Yup, all good! Thanks. ~ Amory (utc) 12:09, 30 November 2018 (UTC)

AWB can't log in

In the last 30 minutes, my WP:AWB login attempts have been failing with the error msg "Check page failed to load. Check that your internet is working at that the Wiki is online".

Both checks passed. AWB will happily load a page list ... it just won't log in.

It was fine a few hours ago. I have never encountered this before.

Any ideas what's going on? --BrownHairedGirl (talk) • (contribs) 03:41, 1 December 2018 (UTC)

@BrownHairedGirl: works for me. What version of AWB are you using? Do you have 2FA on your account (are you trying to use a different account?). In preferences are you pointed to English Wikipedia? — xaosflux Talk 04:32, 1 December 2018 (UTC)
Thanks, @Xaosflux. I tried again when I read your reply, and it logged in straight away. No settings or anything changed at my end.
Using AWB v.5:10.1.0, no 2FA.
Must have been some transient server glitch. --BrownHairedGirl (talk) • (contribs) 04:52, 1 December 2018 (UTC)

Log entries in watchlist RSS feed have an invalid <link> and <guid>

The Wikipedia watchlist shows not only changes to articles, but also certain log entries, such as deleting revisions and setting up pending changes. All these entries are also included in the RSS feed, but their <link> and <guid> fields always have the same value: https://en.wikipedia.org/w/index.php?title=article_name&diff=0, obviously because these entries are not diffs.

Therefore, I can end up with multiple <item>s with the same <guid> in my feed, which breaks most RSS readers in some way. In fact, in my current feed, I have three items for the same article with the same <guid>, all having diff=0.

For example, here's an entry for the Ha! Ha! Pyramid article, with which I was involved yesterday:

<item>
	<title>Ha! Ha! Pyramid</title>
	<link>https://en.wikipedia.org/w/index.php?title=Ha!_Ha!_Pyramid&diff=0</link>
	<guid isPermaLink="false">https://en.wikipedia.org/w/index.php?title=Ha!_Ha!_Pyramid&diff=0</guid>
	<description>purely disruptive (Drmies)</description>
	<pubDate>Thu, 22 Nov 2018 15:24:00 GMT</pubDate>
	<dc:creator>Drmies</dc:creator>
</item>

The source of this entry can be seen in the logs for that article.

I've had a quick look at the archives, but didn't find anything. Is this already known? Should I file a bug in phabricator for this? Isa (talk) 07:21, 23 November 2018 (UTC)

Filed as phab:T210920. I think it'd make a good task for mw:GCI (relatively easy and self-contained). Thanks for mentioning this. BWolff (WMF) (talk) 15:25, 1 December 2018 (UTC)

Taxonbar error on every article that has it

I see "Lua error in Module:Taxonbar/conf at line 25: Tried to read nil global DNE." at the bottom of every article that uses Template:Taxonbar. SL93 (talk) 00:45, 2 December 2018 (UTC)

Me too, and no taxonbar. William Avery (talk) 00:46, 2 December 2018 (UTC)
Some effort underway at: https://en.wikipedia.org/w/index.php?title=Module:Taxonbar/conf&action=history William Avery (talk) 00:51, 2 December 2018 (UTC)
That must have been a cosmic ray bug because Trappist the monk's edit at Module:Taxonbar/conf was good in that it made the style consistent, but it would have had no effect on what the code did. That error message comes from Module:No globals and it is saying that DNE was a global variable that was read at line 25 in Module:Taxonbar/conf but the variable contained nil. However, there is no such variable (it's in a comment) and each of the recent edits at the module was valid where DNE was always in a comment. Anyway, it looks as if editing the module fixed the problem so just another mystery.
Correction: The code before Trappist's fix had "--[[AfroMoths]] DNE" which looked benign but --[[ in fact starts a multiline comment that finishes at the ]] so DNE was a global. Ouch. Johnuniq (talk) 02:37, 2 December 2018 (UTC)

New Pages

I'm thinking of a bot project and wondering what the options are for retrieving a list of new page titles created during a time-frame, say the past 30 days. Special:NewPages actually does this, but there's no API equivalent that I can find. I could poll S:NP and scrape the HTML but that is last resort. The idea is to be able to get the list in a single session and not have to keep a demon running real-time monitoring recent changes. -- GreenC 21:22, 1 December 2018 (UTC)

@GreenC: Would action=query&list=recentchanges&rcnamespace=0&rctype=new (only available while in the RC table) or action=query&list=logevents&letype=create&lenamespace=0 (only available since the create log was added) work? — JJMC89(T·C) 23:10, 1 December 2018 (UTC)
@JJMC89: Yes API:Logevents works: action=query&format=json&list=logevents&letype=create&lestart=2018-11-02T03%3A35%3A24.000Z&leend=2018-10-30T03%3A35%3A24.000Z&lenamespace=0&lelimit=50 .. can't get API:RecentChanges working action=query&format=json&list=recentchanges&rcstart=2018-11-04T03%3A50%3A23.000Z&rcend=2018-11-30T03%3A50%3A23.000Z&rcnamespace=0&rcprop=title%7Cids%7Csizes%7Cflags%7Cuser&rclimit=50&rctype=new maybe the date range exceeds the RC table. But OK with Logevents. Thank you. -- GreenC 04:02, 2 December 2018 (UTC)
RC only goes back 30 days. — JJMC89(T·C) 04:17, 2 December 2018 (UTC)

Year template

Is there a template (or module for that matter) that will return a year from a date? So for example if given "1 Jan 1990" it would return "1990". Or if given "1-12-1920" would give "1920"? (please {{ping|zackmann08}} in your repsonse if possible) --Zackmann (Talk to me/What I been doing) 07:06, 2 December 2018 (UTC)

@Zackmann08: try the {{YEAR}} template or its underlying {{#time:}} parser function. DMacks (talk) 07:13, 2 December 2018 (UTC)
@DMacks: Thanks a million!!! I looked at {{year}} but didn't think to try the all caps. I knew there had to be something. Much appreciated. --Zackmann (Talk to me/What I been doing) 07:14, 2 December 2018 (UTC)

From {user en} templates to Babel extension

Hello! In the Russian Wikipedia, we voluntarily decided to go from single templates {{user en}} to global Babel extension - ru:Template:User lang. And I would like to suggest this decision for the English Wikipedia. Usually all mechanics copy from the English Wikipedia, and this will help to quickly solve many problems associated with single templates. Iniquity (talk) 16:28, 29 November 2018 (UTC)

@Iniquity: We already have it, both in the older templated form e.g. {{babel|en-N|fr-1|ru-0}} and in the newer universal form e.g. {{#babel:en-N|fr-1|ru-0}}. This second form works on virtually all Wikimedia wikis, the documentation is at mw:Extension:Babel#Usage. As an example, see ru:Участник:Redrose64. --Redrose64 🌹 (talk) 21:07, 29 November 2018 (UTC)
@Redrose64: Thanks for your answer! I know it :) But we have delete these templates in Russian Wikipedia (ru:Template:User en) and replaced them with new Template:User lang. Iniquity (talk) 10:18, 30 November 2018 (UTC)
@Iniquity: We have a Template:User lang as well, but it works differently from ru:Шаблон:User lang. Not all wikis have that template; consider d:Q6316821. This shows which wikis have a version of Template:User lang, and how it is named on that wiki. This lists 31 languages of Wikipedia, 17 languages of Wiktionary, and several others (in various languages) for a total of 67 wikis. But this is a small proportion of the Wikimedia wikis that actually exist. See Wikimedia wikis: this shows that Wikipedia exists in approximately 300 languages; also that Wiktionary, Wikibooks, Wikinews, Wikiquote, Wikisource, Wikiversity and Wikivoyage exist in more than one language (but not as many as Wikipedia), giving a total of over 800 Wikimedia wikis. It's not feasible to try and provide over 800 copies of the same template that all work in the same manner.
The point about {{#babel:}} is that it is available in all Wikimedia wikis, and works exactly the same way in all of them. There is no need for locally-hosted templates, and no need to ensure that 800+ versions all work in the same manner. There is also no need to adapt to a different way of doing it on wikis that don't have that template. So whilst asking us to switch over to {{User lang}} might seem like a good idea, it's counterproductive. --Redrose64 🌹 (talk) 18:32, 30 November 2018 (UTC)
@Redrose64: I have a feeling that we didn't understand each other :) I don’t propose switch over to {{User lang}}, although it’s a good idea in my opinion (if you’ve seen how it works and for what it works). I propose to completely abandon the 800+ redundant templates that are difficult to maintain in a small wikis. Iniquity (talk) 13:31, 2 December 2018 (UTC)

Contrast between visited & unvisited links

I often find it hard to differentiate between links using Vector's default colours (visited: #250F82; ) and (unvisited: #067CD0; ) links. My contrast analyser tool, CCA, tells me the difference between them fails WCAG's "AA" level test for contrast.

I know I can fix this with a local style sheet, but presumably it affects other users, too.

Is this something we can improve, or bat up to the MediaWiki crew for a fix?

I've searched Phabricator, and found lots of tickets about colour contrast, but nothing on this specific issue. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:05, 30 November 2018 (UTC)

The Vector link colours are darker than the MonoBook link colours, one reason why I never liked Vector and instead stuck with MonoBook. --Redrose64 🌹 (talk) 20:18, 30 November 2018 (UTC)
FYI I made a comparison table a year ago at mw:Design/Link colors. I also tried to find good external recommendations, but could not find anything consistent. I believe there is a widespread desire to improve these (and make some of them a bit more internally consistent), but it involves aesthetics so every change will make some people happy and some people unhappy, thus it's more complicated than just finding an objectively-measurable contrast-separation and making a global change. Quiddity (talk) 20:31, 30 November 2018 (UTC)
Colour contrast is an accessibility problem when the foreground and background colours are insufficiently different to read the text comfortably, and WCAG addresses that issue. Being able to detect the difference between visited and unvisited links is a functionality issue. It should be obvious that since the background to a link doesn't change when the link is visited, both the visited and unvisited link text colours must meet WCAG standards for contrast between either of them and the background. I think you'll find that it consequently becomes very difficult to create a large difference in contrast between visited and unvisited links. The best you can hope for is to have a sufficient difference in hue, rather than just lightness, to enable you to distinguish between visited and unvisited. Unfortunately, there are many different colour defects in the population, so it's quite hard to recommend a pair of colours that everyone can distinguish while retaining sufficient contrast with a range of common backgrounds. I'd say use your local common.css to meet your own personal needs. That's what it's for. --RexxS (talk) 20:56, 30 November 2018 (UTC)
Ah right, good points, +1 throughout. Quiddity (talk) 06:29, 1 December 2018 (UTC)
Since when are those the default Vector colors and not respectively #0b0080 and #0645ad? ekips39 (talk) 22:29, 30 November 2018 (UTC)
Maybe I picked up the wrong colours, due to shading; you suggest / respectively. The same issue pertains; only moreso. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:39, 30 November 2018 (UTC)
I have no opinion on this issue, though I find the visited link color to be too similar to regular text. But I don't "suggest"; I know. ekips39 (talk) 07:22, 1 December 2018 (UTC)
I agree with ekips39. For me, it's hard to find the visited links among the regular text.--Pere prlpz (talk) 19:04, 1 December 2018 (UTC)

I've analysed the colours, using a logged-out session so that I get the site defaults uninfluenced by any non-default gadgets and custom css/js. I got the colour values by inspecting the style sheets that were loaded by the browser.

Link colours for various skins
Skin Unvisited Visited
Timeless #0088dd   Contrast ratio: 3.773 #006699   Contrast ratio: 6.249
Minerva Neue (mobile) #3366cc   Contrast ratio: 5.366 #5a3696   Contrast ratio: 8.739
MonoBook #002bb8   Contrast ratio: 10.305 #5a3696   Contrast ratio: 8.739
Modern #003366   Contrast ratio: 12.609 #5a3696   Contrast ratio: 8.739
Cologne Blue #223366   Contrast ratio: 12.114 #8d0749   Contrast ratio: 9.295
Vector #0645ad   Contrast ratio: 8.528 #0b0080   Contrast ratio: 15.837

The contrast ratios are for a white background. In such circumstances, colours marked with the † symbol are WCAG 2 AA Compliant but not WCAG 2 AAA Compliant; all of the others are WCAG 2 AAA Compliant. --Redrose64 🌹 (talk) 18:54, 2 December 2018 (UTC)

NOINDEX question

Please see Wikipedia:Village pump (miscellaneous)/Archive 60#Important pages hidden from search engines if you are familiar with _NOINDEX_ and/ or {{NOINDEX}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:35, 3 December 2018 (UTC)

Email address causing error for user rights viewing

I came across a note at AN about a compromised account and tried to view the user groups of the account (to see if if was a sysop or anything of sort). Have a look at Special:UserRights/Chasenstark@gmail.com. It appears the "@gmail.com" spawns an error. Is there a known workaround for this? Home Lander (talk) 17:23, 1 December 2018 (UTC)

Yes, I know I could have just scrolled down and noticed that it had barely edited in the first place... Home Lander (talk) 17:25, 1 December 2018 (UTC)
You can use Special:ListUsers/Chasenstark@gmail.com which shows the same thing. The name is conflicting with the interwiki user right change scheme. It appears to never had any explicit userright and was created before "@" symbol was technically prohibited in usernames. –Ammarpad (talk) 18:06, 1 December 2018 (UTC)
Yes, the current user rights can be seen at Special:ListUsers, available on "User rights" at the bottom of user contributions. As far as I know, the only workaround for Special:UserRights is to have the user renamed without "@". See phab:T14602 and phab:T14581. PrimeHunter (talk) 18:29, 1 December 2018 (UTC)
A bit of a workaround, you can usually use the API for stuff like this.[1] -- zzuuzz (talk) 18:38, 1 December 2018 (UTC)
Zzuuzz, wow, that even works for [2]. Home Lander (talk) 18:43, 1 December 2018 (UTC)
@Home Lander: For usernames with certain odd characters use the userid to edit/view userrights with the GUI like this. — xaosflux Talk 18:54, 1 December 2018 (UTC)
You could also use XTools for this, https://xtools.wmflabs.org/ec-rightschanges/en.wikipedia.org/Chasenstark@gmail.com MusikAnimal talk 22:52, 3 December 2018 (UTC)

Unicode representation of non-breaking space

In wikitext, non-breaking spaces are represented by the html entity &nbsp; or {{nbsp}}. The resulting wikitext could be hard to decipher. Maybe the relevant Unicode Character U+237D “⍽” (Shouldered Open Box) of the Miscellaneous Technical block could be used instead for wikitext legibility and replaced by mediaWiki to the correct nbsp? It could be placed in the char. set below the editor in /symbols/ like , or even replacing the cryptic &nbsp; in /wiki markup/ to gain some space, maybe with a mouseover explainer like (on a side note, every item in /wiki markup/ could be explained with a mouseover explainer).--Marc Lacoste (talk) 17:26, 3 December 2018 (UTC)

Isn't the Unicode "NO-BREAK SPACE" U+00A0? - Nunh-huh 19:04, 3 December 2018 (UTC)
(edit conflict) That seems unlikely to happen, and IMO a bad idea. If anything, it might be better to convince the maintainers of wikitext syntax highlighting to highlight U+00A0 (the actual Unicode non-breaking space character, " "), and convince maintainers of any tools that mangle that character to fix their tools. Anomie 19:05, 3 December 2018 (UTC)
U+00A0 is the proper nbsp wharacter, but in wikitext it can't be seen!--Marc Lacoste (talk) 20:16, 3 December 2018 (UTC) (btw, thanks for your bot)
It can be seen, it just can't be visually distinguished from a breaking space. -Nunh-huh 21:19, 3 December 2018 (UTC)
Indeed, it's U+00A0. If you really can't decipher &nbsp; (which is, after all, merely an acronym), and wish to enter a row of figures instead, you could use any of: &#xa0; &#x00a0; &#160; &#0160; but please don't, as it will cause further confusion. --Redrose64 🌹 (talk) 21:28, 3 December 2018 (UTC)
Anomie's suggestion is phab:T181677. It should actually be rather simple to do, the biggest problem is probably that you need either need to be able to disable that, and/or possible that it might influence what you copy/paste... It would be nice if someone worked on this. —TheDJ (talkcontribs) 09:27, 4 December 2018 (UTC)

my user script: text input does not autocomplete

How could I possibly add autocomplete to the script? I tried adding form, label, name, or id, to no avail. --Gryllida (talk) 23:32, 2 December 2018 (UTC)

Have you tried jquery.chosen? It's provided in ResourceLoader by default. Enterprisey (talk!) 01:56, 3 December 2018 (UTC)
Not sure how to use that? I don't have a list of options, I'd like to get them from history of previous inputs, Enterprisey. Gryllida (talk) 22:56, 3 December 2018 (UTC)
Gryllida, if you mean autocomplete/fill history, then the input fields require a name attribute, they need to be inside a form element, and the form needs to have a submit button. —TheDJ (talkcontribs) 16:35, 3 December 2018 (UTC)
You're right, it was missing a submit button. Should (or does) this documentation mention this? Gryllida (talk) 22:59, 3 December 2018 (UTC)
Gryllida, updated MDN. —TheDJ (talkcontribs) 09:52, 4 December 2018 (UTC)
Thanks!! :-) Gryllida (talk) 10:50, 4 December 2018 (UTC)

search box for contributions, history, recent changes

Filed bug report now: T211147 - add search to recent changes, history, contributions views

The Special:{RecentChanges,Contributions] and ?action=history pages could have a search box with option to search by edit summary, page title, diff content, user name and date range. I think it would make it a lot easier to navigate.

Maybe I am missing something...? Is there a user script for this.

--Gryllida (talk) 21:20, 4 December 2018 (UTC)

16:12, 3 December 2018 (UTC)

Johan, the link to time is wrong (the 16:00 one), it links to 23:00. --Gryllida (talk) 23:05, 3 December 2018 (UTC)
OK, I see what happened. Thanks for telling me. /Johan (WMF) (talk) 04:25, 4 December 2018 (UTC)
I am not sure whether mass message allows you to reply to yourself clarifying this in all places. Probably not. :L In any case you are welcome. Gryllida (talk) 04:49, 4 December 2018 (UTC)
It doesn't. Unfortunately. /Johan (WMF) (talk) 04:55, 4 December 2018 (UTC)
T211158 added Gryllida (talk) 23:29, 4 December 2018 (UTC)

Maximum volume of a WP article

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)

viewing new pages

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?

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)

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)

WP:ITSTHURSDAY issues, 29 November 2018

Problems with edit summaries

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

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.

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

  • 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

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)

Extended-confirmed user criteria

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)

int: changed?

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: "(D) 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 [9] so {{int:MediaWiki:Gadget-responsiveContent.js}} displays it:
⧼MediaWiki:Gadget-responsiveContent.js⧽
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)

Mobile editing

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 [10] 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)
 
  • 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

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

Authority control RfC

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

  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

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)

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

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. [11][12] (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)

Diff highlighting colors

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)

Swiss flag too big

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)

Initial page reported

  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

problem with dates

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)

Sometimes WYSIWYG editor doesn't open

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)

Preventing redlinks auto launch into edit source mode

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.   — 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 [[13]]. 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.   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)

17:33, 10 December 2018 (UTC)

Interwikilink for users?

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)

Dark theme and math readability

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)

Visible ndash

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)

Using templatestyles inside of wikilink text

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)

Time-sensititive templates

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)

Categorization that will not update

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

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)

Taxonbar throwing Lua error

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)

More populated category redirects

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)

"New contribution"

When I select "Contributions" from the menu bar, suddenly I'm getting the title "New contribution" [sic] coming up at the top of the page instead of the usual "User contributions". Is this intentional? Deb (talk) 18:44, 13 December 2018 (UTC)

@Deb: That is in reference to the "New page" / "Upload media" / "Translation" buttons. That and the "New contribution" heading have apparently been there since 2015, going by phab:T96170. Personally I don't find these buttons to be that helpful, especially since "New page" goes to Special:WantedPages (which as currently implemented isn't very useful on this wiki). Furthermore, there's no CSS class or ID applied to the element that contain both the "New contribution" heading and the buttons, so we can't easily hide it, if we wanted to. MusikAnimal talk 18:54, 13 December 2018 (UTC)
@MusikAnimal: what page are these on? I don't see them at this link and Special:Contributions looks normal to me? — xaosflux Talk 18:58, 13 December 2018 (UTC)
That's what puzzling me. I've never seen this before today. When I try to look at my contributions, the normal heading, "User contributions", flashes up for a split second, then changes to "New contribution" [sic]. The buttons you mention are called "Contributions" / "Translations" / "Uploaded media". How can I get rid of this misleading heading? Deb (talk) 19:04, 13 December 2018 (UTC)
To see this you need to enable Content Translation in the Beta Features of your preferences, and vice versa to hide it. It's just possible that this title is determined by what's written at MediaWiki:Cx-contributions-new-contributions. -- zzuuzz (talk) 19:13, 13 December 2018 (UTC)
@Deb: try turning off CXT at Special:Preferences#mw-prefsection-betafeatures. — xaosflux Talk 19:16, 13 December 2018 (UTC)
Thanks so much. That worked. I won't attempt to understand why. Deb (talk) 19:19, 13 December 2018 (UTC)
Great, I didn't even realize this was a beta feature (and hence can be disabled)! If it is not already clear, xaosflux, the "New contribution" thingy is only shown when viewing your own contributions. MusikAnimal talk 19:31, 13 December 2018 (UTC)

Template in a mess

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)

The template has already been updated but it is still used on category pages with old names. So, the result is strange, of course. Ruslik_Zero 20:18, 13 December 2018 (UTC)
The template has been updated to use new naming scheme while the category is still using the old naming scheme resulting in conflicting arrangement. That's what generates the weird name. It will be okay when Category:Wyoming elections, 2018 is actually moved to Category:2018 Wyoming elections. –Ammarpad (talk) 21:13, 13 December 2018 (UTC)

And why a CAPTCHA?

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)
Thanks for identifying the problem. Say, I needed a CAPTCHA to post this followup too. --76.69.46.228 (talk) 08:12, 14 December 2018 (UTC)

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

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)

The meta template Template:Infobox allows one to add more than one image. Instructions are in Template:Infobox#Illustration_images. Ruslik_Zero 20:21, 13 December 2018 (UTC)
For an example of how it works in practice, see Template:Infobox school. – Jonesey95 (talk) 02:01, 14 December 2018 (UTC)
Thanks @Ruslik0: and @Jonesey95:, I've read this several times and still don't understand, could one of you add a second image option to Template:Infobox dog breed for me please? Its a widely used template. I can ask one of my more technical friends to show me in person some time. Thanks, John Cummings (talk) 09:35, 14 December 2018 (UTC)
I am just passing by and saw your request. There are two sides to template editing- the first is working with some lovely markup code, but the second and the more difficult is to get agreement for the need to change. That is really tough. Start here Template talk:Infobox dog breed and you will see comments going back to 2005- there are folk who believe that even stable Infoboxes should be simplified, and years later you need to fight your corner. So the simple workaround if you really need multiple images is to take your two pictures and combine them on you laptop (Gimp/Inkscape/apple photo editor/ microsoft/adobe whatever). You now have just one image- and the issue has gone away. Good luck.ClemRutter (talk) 11:31, 14 December 2018 (UTC)
One can use {{Photomontage}} to display multiple images in an infobox. Galobtter (pingó mió) 11:38, 14 December 2018 (UTC)
John Cummings,   Done See [17]; Copying over and renaming the fields is indeed how you do it. Galobtter (pingó mió) 11:49, 14 December 2018 (UTC)
(edit conflict) I added the option for image2/alt2/caption2/etc. in the template's sandbox and added a second image in the testcases page, which is a good way to have something to talk about when you start a discussion on the talk page. – Jonesey95 (talk) 11:59, 14 December 2018 (UTC)
Well, I did it BOLDly since the template isn't template-protected. Galobtter (pingó mió) 12:09, 14 December 2018 (UTC)

Thanks very much @Galobtter: and @Jonesey95:, it looks like its all done and works. Thanks again, John Cummings (talk) 13:57, 14 December 2018 (UTC)

Seeing wrong image

If I look at The Plague I see a book cover, if I click it to go to the image page at File:La Peste.jpg, I get a commons image! and the non-free stuff for the book cover. The commons image is at c:File:La scene de la peste Grevin.jpg - jumps them from a redirect at c:File:La Peste.jpg. I tried a second browser (in case Firefox was playing up, but got the same). Anyone else see this issue? Ronhjones  (Talk) 17:23, 14 December 2018 (UTC)

Yes. Purging locally didn't fix it. Maybe try deleting and restoring? —Cryptic 17:42, 14 December 2018 (UTC)
It is possible that this page move and redirect creation on 2 December 2018 by Jo-Jo Eumerus has something to do with it, but the ways of files on Commons are a bit of a mystery to me. – Jonesey95 (talk) 17:49, 14 December 2018 (UTC)
When a local file exists under the same name as a redirect on Commons, the Commons redirect overrides the local file. The normal solution is to move the local file to another name, typically un such situations the file name is not really a good one. Jo-Jo Eumerus (talk, contributions) 17:51, 14 December 2018 (UTC)
I moved the file. Galobtter (pingó mió) 18:10, 14 December 2018 (UTC)
@Jo-Jo Eumerus: Is that not a bug? I don't pop over here every time I move a commons image to see if the created re-direct clashes.— Preceding unsigned comment added by Ronhjones (talkcontribs) 18:44, 14 December 2018 (UTC)
Yes, phab:T30299. I don't think it's a common occurrence and when it happens there is often a case to be made for renaming the local file, that might be why it has not been fixed. Jo-Jo Eumerus (talk, contributions) 19:40, 14 December 2018 (UTC)

Issue with RevDel request feature

Greetings and salutations. I use the User:Primefac/revdel tool (although not that frequently). I was just getting used to the ins and outs of it, and all of a sudden it stopped asking for the start and end edits for input. I reached out to Justlettersandnumbers, and they gave me a script to use, which I will so that the admin doesn't have to search for the issue, but it was easier using that tool. Don't know if it was done on purpose, or if it's simply a glitch. Regards.Onel5969 TT me 14:00, 15 December 2018 (UTC)

@Onel5969: that script was taken over by another user, please check at User_talk:Enterprisey for current usage. — xaosflux Talk 15:28, 15 December 2018 (UTC)

Categorization on watchlist

I watchlist several category pages, and my watchlist settings include not hiding categorization. Thus, when someone moves a page into or out of a category that I watch, it shows up on my watchlist. However, over the last several days (not sure quite how long), I've noticed that sometimes this shows up on my watchlist and sometimes it doesn't, with no obvious pattern as to why. Any insights? --Tryptofish (talk) 20:36, 15 December 2018 (UTC)

The phab: ticket linked from this thread above indicates that a few days ago there was a problem saving to the recent changes data table (which is the main one used to generate the watchlist). Maybe it's happened again. --Redrose64 🌹 (talk) 21:24, 15 December 2018 (UTC)
That seems possible, thanks. For me, this appears to be exclusively related to categorization. --Tryptofish (talk) 21:31, 15 December 2018 (UTC)
@Tryptofish: probably the problem is larger, though definitely related with that bug. Someone (from dewiki) reported all categorization don't show on Watchlist. But it seems you're seeing some? but not all. Can you confirm here or on the phab ticket, whether it's for all categorization or just some pages you noticed this?. –Ammarpad (talk) 17:18, 16 December 2018 (UTC)
As far as I can tell, I have not had any problems that were unrelated to categories. Specifically, I have some category pages on my watchlist. A few days ago, someone added some additional pages to one of these categories. One of those additions appeared on my watchlist (as "editor name" added "pagename" to "category name"), but two others did not. Then, a few days later, those two suddenly did appear on my watchlist, as of the date when they happened. I double-checked, and it cannot be accounted for by other edits to those pages after the edits for categorization: the categorization edits were each the most recent edits to those pages. I then changed those category assignments by removing the category, and in some cases replacing it with a second category that is also on my watchlist, and none of those category changes appeared on my watchlist, although they showed correctly on my contributions. On my watchlist, where it has various kinds of edits to hide, I do not have categorization checked, so it should not be hidden. I tried checking it, refreshing the watchlist, then unchecking it and refreshing again, and none of that made any difference. In my user preferences under the Watchlist tab, the only things I have checked are "Use non-JavaScript interface" and "Add new files I upload to my watchlist", and nothing else is checked. --Tryptofish (talk) 18:11, 16 December 2018 (UTC)

20:34, 17 December 2018 (UTC)

Thanks doesn't work on rev-delled revisions

Is this intentional? There is no thanks button next to any page revisions that have been hidden, such as those currently near the top of [23]. Home Lander (talk) 23:11, 17 December 2018 (UTC)

Yes, that's on purpose (source code). Legoktm (talk) 00:07, 18 December 2018 (UTC)

Easier way to add missing ")"

On List of people who disappeared mysteriously: post-1970, all of the entries are missing the second ")" in the age column after "2018". Is there an easier way to fix this instead of going through and adding it to every single one manually? Home Lander (talk) 02:26, 18 December 2018 (UTC)

In the wikitext editor choose the advanced menu. At the far right click the spyglass for search and replace.
Trappist the monk (talk) 02:28, 18 December 2018 (UTC)
Trappist the monk, brilliant. Thanks! Home Lander (talk) 02:33, 18 December 2018 (UTC)

CAT:CSD admin backlog

What's wrong with {{admin backlog}} at CAT:CSD? It won't disappear, even though the category's empty and I've purged the category using the link in the template. The settings are the same as normal: the template's supposed to disappear whenever there are fewer than 50 items in the category. Nyttend (talk) 22:46, 17 December 2018 (UTC)

Nyttend, for what it's worth, the page counter is also off at Category:Administrative backlog. It shows 198 pages, when there's (currently) only two. I purged it also, and it didn't help. Home Lander (talk) 23:17, 17 December 2018 (UTC)
This has been an ongoing issue for about half the year (see phab:T195397 and phab:T200402 as well) and has been reported here and elsewhere more than once. ~ Amory (utc) 01:55, 18 December 2018 (UTC)
Hm, I'm sorry; I don't have any memory of reporting this situation a couple of months ago. Nyttend (talk) 03:07, 18 December 2018 (UTC)

Any use for a "rare character" index?

 – SD0001 (talk) 18:57, 15 December 2018 (UTC)

Hello! There was recently a discussion at Extension:CirrusSearch about creating a new search index for "rare" characters that are currently not indexed by the on-wiki search engine. The three examples of difficult-to-find characters given were (Ankh), (ditto mark), and (ideographic closing mark). (Note that you can currently do an insource regex search like insource:/☥/, but on large wikis this is guaranteed to time out and not give complete results, and it is extremely inefficient on the search cluster.)

We can't index everything—indexing all every instance of e or . would be very expensive and less useful than , for example. So, in English, we would ignore A-Z, a-z, 0-9, space, and most regular punctuation (exact list TBD) and index pretty much everything else.

The most plausibly efficient way to implement such an index would only track individual characters at the document level, so you could search for documents containing both and , but you could not specify a phrase like "☥ 〆" or "〆 ☥", or a single "word" like ☥☥ or 〆☥.

I've opened a Phabricator ticket T211824 to more carefully investigate such a rare character index, to get a sense of how big it would be and what resources it would take to support it. If you have any ideas about specific use cases and how this would or would not help with them, or any other thoughts, please reply here or on the Phab ticket. (Increased interest increases the likelihood of this moving forward, albeit slowly, over the next year.)

Thank you! TJones (WMF) (talk) 16:26, 14 December 2018 (UTC)

It would be useful to be able to search for strings that include the newline (\n) character. My specific use case is that I was searching for "insource:/\<small\>\n\*/" in order to find and fix misnested <small>...</small> tags (a Linter error). I was unable to do it. It's possible that there is some way to do it, but I found MW documentation saying that it was not supported (yet?). – Jonesey95 (talk) 19:54, 15 December 2018 (UTC)
The unicode tables aim to index every character known, together with their usage and the alphabet which includes that character. For example 𓉑 is Egyptian Hieroglyph O001a, unicode U+13251 . The last I checked, there were 110,000 codes. --Ancheta Wis   (talk | contribs) 20:21, 15 December 2018 (UTC)
Ancheta Wis, that's not the type of index that is meant here ;) This is a search index, which would be the mapping between such symbols and lists of pages that contain them. —TheDJ (talkcontribs) 10:54, 17 December 2018 (UTC)
@TJones (WMF), @User:TheDJ, what about a tiered-search index. The Unicode tables user interface illustrates such an approach: the broadest scope is a block, or alphabet, which restricts the search to alphabets. In addition, in the search field, there can be a search for the graphical symbol of the unicode in a specific alphabet, a search for the spelled-out name of the unicode, and finally the numeric unicode by little-end or big-end. One deficiency that I can see is the current searches in this interface is that the CJK characters don't have the nuances in the description that I am used to in wikipedia.
One of the disadvantages to a 'rare event'-type of search is that such searches can be over such a broad field; the analogy would be zooming in on a specific point in the Pacific Ocean on Google Maps — it only makes sense to zoom out to a projection that shows the curvature of Earth, and that the user can rotate Earth's image to the specific region of interest, before zooming in. --Ancheta Wis   (talk | contribs) 15:03, 17 December 2018 (UTC)
@Ancheta Wis, what you are describing with the tiered search, if I understand it correctly, is interesting, but seems to be more about getting to a page about a specific characters; the goal that I'm describing is more about being able to find instances of a character that you already have in hand, as it were. In another discussion, the idea of indexing Unicode character blocks came up, and it's a good idea, but not necessarily the first thing I'd look at implementing (if this ever gets that far), though I plan to document what it does to the size of a theoretical index. I think it would be inexpensive to index at the block level, though it would be complex to refer to them. (Some existing ways to refer to them in some languages' regexes are here.)
I'm not sure I follow the map analogy, but I agree that different use cases have different scope, and this might not work for everything. However, I realized in another discussion that something like a complex regex with all the nuance and context you need, but which would normally time out because it has to scan every character of every document in the entire wiki, could be made much more efficient by adding a clause to the search that requires a specific character (or character block) to be present in the document, thus limiting the expensive scan to tens of thousands or fewer docs, rather than millions. TJones (WMF) (talk) 23:11, 17 December 2018 (UTC)
There is another complication, which is that WMF might want to build in a protective interface to manage the misuse of an esoteric symbol by communities which might seek to co-opt such a symbol for their own purposes in dog-whistle politics. I refer of course to the swastika, which had a completely different connotation in the culture that originated it. Right now, most of these symbols enjoy security by obscurity. --Ancheta Wis   (talk | contribs) 23:41, 17 December 2018 (UTC)
There are definitely lots of complicated issues with certain characters and symbols. Since the use of a symbol for political purposes is mostly outside search—other than making it easier for community members to find instances of the symbol—I'm not sure what the best way to deal with it would be. It seems like it would be up to the particular wiki community to come up with a policy, unless things were so extreme that WMF Trust & Safety had to get involved—but I don't really know because that is far outside my bailiwick. Automated ways of addressing the use of a particular symbol (or word, or anything) can be complicated by the use–mention distinction, since articles can reasonably want to document how people use a symbol, which is hard to do without being able to mention it. TJones (WMF) (talk) 16:47, 18 December 2018 (UTC)
@Jonesey95, this index wouldn't help with your use case, since it would be document-level, and not part of regex searches. Also, "regular" whitespace characters, like spaces, tabs, and newlines, would be too common to index—almost every document would contain a newline! I did try to find a hack to get a newline character into the insource regex, but I couldn't do it. The browser UI won't let you paste it in. Hacking it into the URL doesn't work. I tried to define a character range that covered it (on the assumption that 99% of matches would be newlines and not, say, the BELL character), but that didn't work either. Sorry not the have better advice. TJones (WMF) (talk) 22:59, 17 December 2018 (UTC)

French language version of article not linking in Laguages tab for English version of article

The article for Bizot group in English is presently not linking in the Languages interwiki tab to the French version of the article here [24] under the title "Groupe_international_des_organisateurs_de_grandes_expositions". This is possibly due to the English language preference for calling it the Bizot group instead of the French name. Can someone figure out how to get the language interwiki links to work, possibly on the French side as well as the English Wikipedia side for this article. CodexJustin (talk) 15:53, 18 December 2018 (UTC)

@CodexJustin: Fixed. I clicked "Edit links" on the French Wikipedia version, which took me to the relevant Wikidata conceptual/linking page, where I added the English Wikipedia one. Hope this helps for next time! James F. (talk) 16:13, 18 December 2018 (UTC)
Just what was needed. Fixed on both versions. CodexJustin (talk) 19:51, 18 December 2018 (UTC)

Issue - Missing "remembered" lines for Edit summary box

Greetings, I'm on WP almost daily doing article assessments & article category updates. As of yesterday (sorry, maybe mid-day) the Edit summary box became blank with no remembered lines. Previously, if I typed Upda for example, several lines would appear for me to click on instead of re-typing entire line. My browser is chrome-based & laptop computer with Windows7 Pro. Today I looked at Gadgets, Editing & activated Add two new dropdown boxes below the edit summary box with some useful default summaries. This had no effect. Wondering if something changed & what needs to be done to restore this functionality? Regards, JoeHebda (talk) 22:14, 18 December 2018 (UTC)

@JoeHebda: it sounds like what you are describing is your browser's auto-fill form feature, not something that comes from Wikipedia. Have you changed browsers lately? — xaosflux Talk 22:18, 18 December 2018 (UTC)
@Xaosflux: - Thanks, for clarifying issue. Yes, I checked browser's auto-fill form setting & sure enough, it was switched "Off". Turned back "On" & now all is Good! Cheers! :-) JoeHebda (talk) 22:27, 18 December 2018 (UTC)

template fix request

please fix {{iso2language|lij}} with link to Ligurian (Romance language). thanks!!! --2001:B07:6442:8903:8D3C:C5DA:57A1:9F2F (talk) 14:56, 18 December 2018 (UTC)

Easier said than done. Some background for anyone able to help: {{iso2language|lij}} produces [[Ligurian language|Ligurian]], a link to a dab. For an example, see WP:Slogans (search for lij). iso2language uses {{Language article}} which hard codes the article name as "Language_name language". We recently resolved a similar problem in Module:Lang after discussion at Template talk:Lang#Ligurian dab and WT:Disambiguation pages with links#Ligurian language. I think that {{Language article}} should call Module:Lang instead of Module:ISO 639 name. However, Lang can only provide a complete wikilink, with displayed text that (depending on the parameters) may not be suitable here, not the raw article name.
@Trappist the monk: Sorry to bother you again, but would it be possible to give Module:Lang's name_from_code an option, e.g. |link=title or |title=yes, to return only the raw article title instead of a wikilink? I hope that would be the last enhancement, as it would give any similar cases access to the One True Article Name. If not then we could do some string mangling to remove the unwanted parts of the link and parse out the article title ([[X|Y]] → X). After that, an easy change to {{Language article}} should resolve this problem, but might introduce other subtle incompatibilities. The template to be changed is not widely used. Should I be bold here? Certes (talk) 16:24, 18 December 2018 (UTC)
I've mocked up a possible implementation of |link=title in Module:Lang/sandbox. I'm unable to test this as only template editors can view previews. Certes (talk) 16:49, 18 December 2018 (UTC)
If this is about WP:Slogans then there are more problems than code lij; do a text search to the string 'error'. WikiMedia in its wisdom (or lack thereof) elected to use non-standard codes for the subdomain name of some language editions of Wikipedia. For example, the Bhojpuri wikipedia is located at bh.wikipedia.org. ISO 639-1 code bh is assigned to Script error: The function "iso_639_name" does not exist. whereas the proper code for Script error: The function "iso_639_name" does not exist. is bho. Most of the other 'codes' that show errors are non-standard. These might best be accommodated by using the {{#language:}} magic word instead of {{iso2language}}. perhaps like this:
[[{{#language:bat-smg|en}} language]]Samogitian language
But then I have to wonder, shouldn't the links in the language column of that page really be linking to the the <language> Wikipieda article? In that case, perhaps this:
[[{{#language:bat-smg|en}} Wikipedia]]Samogitian Wikipedia
For lij and xlg, I suspect that the correct solution for Module:ISO 639 name is a solution similar to the one made to Module:Lang. I will consider how that should be implemented.
Trappist the monk (talk) 17:15, 18 December 2018 (UTC)
Yes, this discussion may form part of a WP:BRD about WP:Slogans. The first column links to a Wikipedia; the third normally links to enwiki's article on its language. The page is a minor backwater and I was happy to let the matter rest as we don't mind links to dabs from WP: namespace, but any improvement to the templates might be more generally useful. Certes (talk) 01:03, 19 December 2018 (UTC)
{{iso2language|lij}} → {{code|{{iso2language|lij}}}} → {{iso2language}}
Yes, I know what all of the columns are. The third column, in my opinion, is linking to the wrong place; text in the fourth and fifth columns should be wrapped in {{lang}}.
Trappist the monk (talk) 11:50, 19 December 2018 (UTC)
Thank you for the enhancement. Although the immediate effects are minor, your changes improve the code base for future use. I'll leave the other suggestions to the IP editor who started this discussion, who has been a main contributor to WP:Slogans. Certes (talk) 12:03, 19 December 2018 (UTC)

Is Lowercase Sigmabot II broken?

I understand archive bots are not part of the core project, and I'm happy to be redirected. It looks like neither WT:ITN nor WT:ITNR have been auto-archived in a while, even though the bot had been working on those pages previously. The archive templates are still on those pages. Is the bot broken? Did something change? --LaserLegs (talk) 13:59, 19 December 2018 (UTC)

@LaserLegs: No, the bot is following the instructions left for it on those pages. At WT:ITN, minthreadsleft = 4 tells the bot to leave at least four threads on the page; at WT:ITNR, the instruction is minthreadsleft = 5 -- John of Reading (talk) 14:31, 19 December 2018 (UTC)
@John of Reading: So it's my incompetence then, TYVM! --LaserLegs (talk) 19:31, 19 December 2018 (UTC)

"Submit an edit request" button failing

In the "View source" mode of a cascade-protected module, clicking on the "Submit an edit request" button leads to Wp:Main Page/Errors. SD0001 (talk) 11:31, 18 December 2018 (UTC)

@SD0001: Not every module; compare Module:String and Module:Lockbox. It's a little convoluted, but in the end the button is delivered by Module:Submit an edit request. It seems the doc for Template:Protected page text is a little misleading, but the button will link to mainpage errors for any module that is transcluded on the Main Page, which is intentional. ~ Amory (utc) 12:21, 18 December 2018 (UTC)
We may want to add a little label next to the button that says exactly that. Enterprisey (talk!) 05:54, 20 December 2018 (UTC)

Currently disabled: two issues

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)
Good guess, but no; I did say it was about 21:25 that day. --76.69.46.228 (talk) 08:11, 14 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)
      • Thanks. --76.69.46.228 (talk) 08:11, 14 December 2018 (UTC)
        • Ah, still wrong, I'm afraid. It is usual to use leading zeroes, so 09:10, not 9:10 as the current format produces. --76.69.46.228 (talk) 11:24, 14 December 2018 (UTC)
            Fixed Galobtter (pingó mió) 11:29, 14 December 2018 (UTC)

Only show [edit] links on mouseover

I don't remember if it was on Wikipedia or another wiki, but I recall there being a setting or gadget in Preferences that made it so [edit] links only show when moving the mouse cursor over the section. Does this still exist? Erik Humphrey (talk) 09:56, 18 December 2018 (UTC)

Erik Humphrey, section header or the whole section? If the former, I can write the script pretty quickly. Enterprisey (talk!) 05:55, 20 December 2018 (UTC)
The former, please. Not sure if it had compatability with "Add an [edit] link for the lead section of a page". Erik Humphrey (talk) 13:40, 20 December 2018 (UTC)

2FA

I have a new phone.

I no longer have the old one.

Before I changed phones I looked and found sites that explained how to transfer 2FA to a new phone. it sounded straightforward. They made it clear I could log into a browser and choose a new phone. However, now that I'm trying to carry it out, I see that the instructions relate to 2FA for a Google account, not Wikipedia.

The help page at meta doesn't explicitly talk about transferring from one phone to another. it does discuss what to do if the device is lost but that requires the original scratch codes which I may not be able to locate.

Are there any other options?--S Philbrick(Talk) 01:16, 19 December 2018 (UTC)

@Sphilbrick: the "transfer to a new device" is "un-enroll, re-enroll". You will need your scratch codes to do this if you no longer have access to your device. — xaosflux Talk 01:46, 19 December 2018 (UTC)
Your other option is "go beg WMF trust and safety" by opening a phab ticket such as phab:T191708. — xaosflux Talk 01:48, 19 December 2018 (UTC)
Xaosflux, Thanks. The good news is that I found my codes. I have disabled 2FA. Now need to turn back on, but will pause a bit to make sure I want to keep this phone. S Philbrick(Talk) 03:21, 19 December 2018 (UTC)

I think we ought to consider some more prominent advice/warning regarding 2FA.

As background, here is my situation which I could see happening to others: I decided to buy a new phone for my spouse so went shopping at a store associated with a carrier. while talking through options for a phone for her, they mentioned, almost in passing, that if we switch carriers they could upgrade my phone to the latest version for free and reduce my monthly fee. At this point, you might be guessing that I went ahead and did so without thinking through how to transfer my 2FA, but at the decided not to make the decision on the spot, and did some research to see what would be involved in the transfer. I found this site, which sounded exactly on point and gave a step-by-step process. It seemed clear that I could get the new phone, add the app, go to a website and transfer it to the new phone, so I made the purchase decision, got my new phone and they factory reset the old one.

Unfortunately, as I started to go through the steps, I see that they do indeed help you transfer Google authenticator to a new phone, but only in the context of using the authenticator for a Google account, not for Wikipedia. In retrospect, a very careful reading of the instructions might've revealed that, but I think it's plausible that someone could look at those instructions on how to transfer Google authenticator to a new phone and think that they might apply to a situation where you need to transfer Google authenticator to a new phone.

I suggest that we ought to provide more explicit warnings letting people know that if they are planning to change phones they should disable 2FA on the old phone before letting go of it.S Philbrick(Talk) 15:33, 19 December 2018 (UTC)

@Sphilbrick: You can add that information at Wikipedia:Simple 2FA. 2FA still has many problems and that's effectively why it's not been set to be used by all users yet. –Ammarpad (talk) 19:47, 19 December 2018 (UTC)
I have one simple advice for you and everybody: when setting up 2FA preserve the key (together with scratch codes). Then you can use this key to set up authenticators at any device at any time that you like. Ruslik_Zero 20:43, 19 December 2018 (UTC)
If you do keep that code (not recommended!) you must ensure the highest level of security on it, with that seed anyone could impersonate your 2FA and you wouldn't even know it. The only way to "change" that is to unenroll and reenroll as well. — xaosflux Talk 14:56, 20 December 2018 (UTC)
Keep the code the same place you keep your scratch codes, since either one allows someone to impersonate your 2FA. I also personally use WinAuth, which allows me to display the enrollment barcode after entering my WinAuth password (which, of course, is different from the passwords of any of the sites I am using 2FA with). --Ahecht (TALK
PAGE
) 15:51, 20 December 2018 (UTC)

Keyboard shortcut to activate citation bot / load a specific link?

Currently when doing some cleanup related to WP:JCW, my workflow process is something like

  • Load several articles by control-clicking various links present on e.g. WP:JCW/Target25
    • A Click on the first tab/article
    • B) Scroll down to "Citation bot" link in my toolbox
    • C) Click "citation bot"
  • Repeat A/B/C for each article/tab.

This is pretty tedious, especially step B. So I'm looking at something like

  • Run citation bot directly by "keyboard shortcut + clicking on a link"

or

  • Load several articles by control-clicking various links present on e.g. WP:JCW/Target25
    • A) Click on the first tab/article
    • B) Use keyboard shortcut to activate Citation bot directly.
  • Repeat A/B/C for each article/tab.

Is there a way to do that? Headbomb {t · c · p · b} 17:23, 19 December 2018 (UTC)

@Headbomb: is this for the Wikipedia:Citation expander gadget? — xaosflux Talk 01:00, 20 December 2018 (UTC)
Well right now I use a custom version of it, I think. Not really married to using my custom version, the gadget could likely be updated with my code tweaks if needed if there's a gadget-way of having a keyboard shortcut of some kind. Headbomb {t · c · p · b} 02:32, 20 December 2018 (UTC)
Yes, you can add a keyboard shortcut to a link or button by setting the accesskey attribute to a letter, and then you can use it like a regular Wikipedia keyboard shortcut (see WP:K for more info on those). If you also want the tooltip of that element to reflect the new access key, use ResourceLoader to load jquery.accessKeyLabel and then call updateTooltipAccessKeys() on the jQuery object of the element you just set the attribute on. For an example, see the final function in User:Enterprisey/hover-edit-section.js. Enterprisey (talk!) 05:51, 20 December 2018 (UTC)
Enterprisey, you don't even need to do that, addPortletLink has an optional accesskey argument. —TheDJ (talkcontribs) 08:03, 20 December 2018 (UTC)
@TheDJ:, so how would I go about setting up an accesskey/keyboard shortcut in User:Headbomb/citations.js? Like Alt+Shift+A ? Assume I can't write anything in javascript. Headbomb {t · c · p · b} 08:35, 20 December 2018 (UTC)

Thanks, this is now solved and works like a charm! Headbomb {t · c · p · b} 16:00, 20 December 2018 (UTC)

Cosmetic change problem

  Resolved
 – Nothing needed. Kirbanzo (talk) 18:08, 20 December 2018 (UTC)

For some reason, occasionally when I make an edit, a &nbsp; or two gets inserted into the page. Here's an example that popped up while I was closing a discussion that didn't have any activity for a while, brought to my attention by Isaacl: [25].

I'm using the source editor with wikiED, and the problem seems to not care about browser. As such, I'm not sure what the issue is, since I'm not deliberately putting in the &nbsp;s. Is there a solution?

Thanks, Kirbanzo (talk) 14:44, 17 December 2018 (UTC)

@Kirbanzo: WP:WIKEDNBSP. --Izno (talk) 14:54, 17 December 2018 (UTC)

Add option in preferences to link to userspace subpages/sandboxes

It's been a while since I discovered PrimeHunter's very useful script User:PrimeHunter/My subpages.js which adds a "subpages" link next to one's "sandbox" link at the top of the page. Yesterday, while talking about sandboxes, someone asked me if there was an easy way to view all of one's sandboxes. I started to show them where it was in my preferences, and quickly remembered that it is in fact a script rather than a simple option that can be enabled.

We encourage new users to practice/experiment/draft in sandboxes, but outside of the default sandbox we don't give them an intuitive way to access a list of those sandboxes. (I'm not looking for advice on using PrefixIndex, to reuse the default sandbox, how to use one's contribution history to find such pages, etc.).

Can we incorporate this script (or the equivalent function) as a gadget or other preference that can be enabled? — Rhododendrites talk \\ 17:36, 20 December 2018 (UTC)

@Rhododendrites: software-wise nothing is different about a user sandbox and a user subpage, see User:Xaosflux/sandbox for an example of how I manage my sandboxes. You could use the same type of markup for "all subpages" if you wanted. — xaosflux Talk 20:36, 20 December 2018 (UTC)
@Xaosflux: I know. As someone who's been around a while, I can come up with various ways to access my own sandboxes. I'm thinking of a newbie, though. I want them to be able to create multiple sandboxes and then be able to easily access all of those sandboxes without searching through their contributions, without tracking down the PrefixIndex, without coming up with their own linking scheme, etc. — Rhododendrites talk \\ 21:18, 20 December 2018 (UTC)
No special tools are needed. Go to your user page; in the left-hand margin, locate the "Page information" link and click it. In there, you will find some tables; in the left-hand column of the first table, there is a link "Number of subpages of this page". Click that. --Redrose64 🌹 (talk) 21:30, 20 December 2018 (UTC)
The bottom of user contributions also has a "Subpages" link for that user (assuming your language at Special:Preferences#mw-prefsection-personal is English). My script is listed at Wikipedia:User scripts/List#Personal toolbar (top). It's easy to add a script to Special:Preferences#mw-prefsection-gadgets but we limit the number of scripts there to not overwhelm users. The script only adds a single link which can be reached in other ways. PrimeHunter (talk) 21:50, 20 December 2018 (UTC)
@Rhododendrites: and do you wan't this somehow know what is a "sandbox" vs a "non-sandbox" subpage? This would at the very least require some sort of declaration. Are these "sandbox" pages being created using a consistent manner? — xaosflux Talk 21:46, 20 December 2018 (UTC)

Let's say a new user doesn't know their way around Wikipedia. You walk them through creating /sandbox and /sandbox2. Then they say "how do I find my other sandbox?" or "I can't remember the name of my sandbox." This is very common for new users. Telling someone to find a link in the page information, telling someone how to use the prefixindex, etc. are far from user friendly solutions. The subpages link at the bottom of contributions is better -- I had forgotten that was there. It just seems like something that, at least in my experience, is a very common question new users have. We have a link to "the sandbox" at the top, which makes it seem like that should take them to their sandboxes. I'd like to see a link that's just as easy to see take them to a list of their sandboxes (and yes, other subpages if they exist). In other words, to just move the subpages link from the bottom of a contribs screen to an easier to find place. An alternative would be to display a link on and /sandbox subpage that links to "other sandboxes" or something. — Rhododendrites talk \\ 22:22, 20 December 2018 (UTC)

EN-GB minor adjustments

Would it be possible to:

  1. have the main page read "Welcome to Wikipædia, the free encyclopædia..." instead of "Welcome to Wikipedia, the free encyclopedia..." when a user's interface language is set to EN-GB (British English)?
  2. have the English Wikipedia logo in the corner replaced by the Scots Wikipedia logo (with "æ" spellings) when a user's interface language is set to EN-GB?

Kamafa Delgato (Lojbanist)Styrofoam is not made from kittens. 00:58, 20 December 2018 (UTC)

(1) is in theory possible, but the level of hackery involved in the only way I know of doing it is beyond what I think is reasonable, however (2) is not possible by any method I know. {{3x|p}}ery (talk) 01:03, 20 December 2018 (UTC)
Not really (and certainly not easily) - unlike most parts of the interface, these elements are not mediawiki messages with corresponding translations, they are just text. — xaosflux Talk 01:06, 20 December 2018 (UTC)
Isn't Wikipedia a trademark? That is, we mustn't vary the spelling even if we wanted to? --Redrose64 🌹 (talk) 21:26, 20 December 2018 (UTC)
wikidata:Q52#sitelinks-wikipedia shows what the article Wikipedia is called in other languages. Most of them also use that translation in the logo and elsewhere but I think the name must be accepted by the Wikimedia Foundation. However, the English Wikipedia is called "Wikipedia" and I don't think we should show the name differently to users with another language setting at Special:Preferences. Regardless of their preferred language, they are at "Wikipedia" here. PrimeHunter (talk) 22:33, 20 December 2018 (UTC)
@Lojbanist: It's not a good idea to use the EN-GB language setting. A number of interface messages are only kept up to date for the plain EN language (which despite the belief of some people, is not Americanm English but international English). --Redrose64 🌹 (talk) 21:26, 20 December 2018 (UTC)

Unable to remove center tag

Since the <center> tag is deprecated, I tried to replace the tag present in [this] page. I was able to replace all the <center> tags except one. I need help in removing that specific occurrence of the <center> tag.Adithyak1997 (talk) 15:32, 19 December 2018 (UTC)

@Adithyak1997: does Special:Diff/874488524 do it for you? You may want to contact this user as well about changes you are making in their space - center still works and is very widely used. — xaosflux Talk 15:53, 19 December 2018 (UTC)
@Xaosflux:I have two doubts related to the information given by you above. Firstly, if center tag is widely used, then why was it put under the category of Linter error?Adithyak1997 (talk) 16:04, 19 December 2018 (UTC)
@Adithyak1997: The 11 million+ obsolete-tag linter errors are "low priority" for a reason, they aren't really causing breaking issues for readers today (and may not lead to issues tomorrow). Obsolete HTML tags like center are such because they aren't precise (they somewhat misleadingly define the presentation of content, as opposed to describing content). A simple search will quickly show you center in use. That being said, it is not wrong to fix these as you come across them, but you shouldn't go on a campaign of changing these. In places like tables with centered text, the "best" answer would be to stylize the table, as opposed to changing each cell from center to a span style for example. — xaosflux Talk 16:14, 19 December 2018 (UTC)
@Adithyak1997: HTML element says it's been deprecated since HTML 4 (from 1999). Jc86035 (talk) 16:24, 19 December 2018 (UTC)
The <center>...</center> element was added to the HTML specs with HTML 3.2; the next formal revision (HTML 4.0) deprecated it; and HTML 5.0 marked it as obsolete. --Redrose64 🌹 (talk) 23:51, 20 December 2018 (UTC)

Cannot add language link to a module

I am able to add language links to Module:ISO 3166/data/IN but I am unable to add it to Module:ISO 3166/data/US. I would like to know the cause of this problem.Adithyak1997 (talk) 15:12, 20 December 2018 (UTC)

@Adithyak1997: You didn't say what went wrong. If you were looking for a link saying "Wikidata item" or "Edit links" then there isn't one because Module:ISO 3166/data/US currently has no Wikidata item. You should be able to create a Wikidata item with a chosen language link by clicking "Add links" below "Languages" in the left pane. PrimeHunter (talk) 22:13, 20 December 2018 (UTC)
@PrimeHunter: I was actually trying to add malayalam language link for this module. When I tried the option for creating a wikidata item, it showed following error
The save has failed. Warn: Links to certain pages, like the one(s) you are trying to add (eg. template documentation subpages), are not allowed in Wikidata. Please check our rules. You can contact an administrator if you think you are correct..Adithyak1997 (talk) 10:17, 21 December 2018 (UTC)
@Adithyak1997: "/US" in the page name is matching [uú]so? in wikidata:Special:AbuseFilter/36. There is apparently a language where /us subpages are used for template documentation or similar. Wikidata administrators are exempted from the filter. There is already a report at wikidata:Wikidata:Administrators' noticeboard#Can't create item for Module:ISO 3166/data/US. If the problem is explained with a request to create the item with a list of links then maybe it will get a response. PrimeHunter (talk) 11:00, 21 December 2018 (UTC)

Tables of content disappearing in Waterfox SOLVED!

  Resolved

Hi,

this is my first time even going near the village pump, so I'll apologize for any faux pas I'll surely make. Sam Sailor suggested I ask for help here.

This morning, I look up Rings of Saturn. The page loads, the table of contents appears on the left. I click "Physical parameters of the rings", while the progress bar and spinning thing in the tab indicates loading is not yet complete. But when loading does complete, the whole Table of Contents disappears.

I'm sure the cursor wasn't even near the "hide" link, and no unhide link is to be found. Unfortunately, this is how all pages, all articles look now, and the visible chain of events is identical (without me clicking anything): The page loads, it appears, the Table of Contents is in its usual place so long as the progress indicators are still visible, the page is not done loading. And the moment the indicators disappear, so does the Table of Contents. It may be that this is what the Rings of Saturn page would have done had I clicked nothing. I took a screenshot, which is here. Anything I look up on Wikipedia, the Table of Contents goes missing, in my usual browser. Last time I had looked up anything, last night, it looked fine and as usual. The browser had stayed up all night, with the computer, it was the same browser session, still.

This browser being Waterfox 56.2.5, with a number of addons (but no new ones since the last time I had used Wikipedia problem-free), under Windows 10 (Version 1803). I have cleared the cache, deleted all Wikipedia cookies, restarted the browser, and tried logging in on Wikipedia (which I don't usually do). The tables of contents will appear only so long as the page is still loading, then they disappear.

When I try and replicate the problem in Microsoft Edge or Mozilla Firefox, I am confounded. There, the tables of contents do appear, all looks normal.

I've spent some time trying to find some solution via Google, and in Help and FAQ sections here. I tried my best working through search results, but found nothing. Tried my best, because reading through long texts is difficult and, at times, painful for me. I suffer from homonymous hemianopsia, so anything that lets me find what I'm specifically looking for in an article is not just a convenience for me.

I will be most grateful for any suggestions what I bollocksed up (I have no doubt that is what I did), and more grateful still for any idea how I might unbollocks it.

DerGolgo (talk) 16:33, 19 December 2018 (UTC)

Do you have an add-on such as an ad blocker which might mistake the table of contents for unwanted content? I just tried Waterfox 56.2.5 (on Ubuntu 16.04, no add-ons, not logged in to Wikipedia). Opening Rings of Saturn looks normal (just like Firefox), including the TOC. The only oddity is that scrolling down about one page (with Page Down, down-arrow key, scrollbar or mouse wheel) makes the screen jerk almost back to the top, but the TOC is still there. Certes (talk) 17:08, 19 December 2018 (UTC)

Certes By golly, your suggestion put me on the right track! Thank you!! The adblockers I use weren't it. But I found the culprit, "Pericles", a text-to-speech addon. I was, and am, certain I had used Wikipedia with no problems after installing it. Disabling it solved the problem, though, and I see tables of contents once more! Final question: what is the procedure for questions that have been answered? Do I delete my post? DerGolgo (talk) 14:15, 20 December 2018 (UTC)

@DerGolgo: nothing to do here - the new header is fine, this will get archived so that people can search for it in the future if they have them same issue. Thank you for posting the solution! — xaosflux Talk 14:53, 20 December 2018 (UTC)

@Xaosflux: Thank you! DerGolgo (talk) 15:04, 20 December 2018 (UTC)

@DerGolgo and Xaosflux: The heading (n.b. not "header") should really be left alone, since altering it breaks inward links. What you can do is add {{resolved}} after the heading. --Redrose64 🌹 (talk) 23:38, 20 December 2018 (UTC)

@Redrose64: Thank you! I'll try and keep that in mind should I ever ask a question here again! DerGolgo (talk) 12:13, 21 December 2018 (UTC)

User account merge

Hi, a few years ago I made an account on both the slovak and english variants of wikipedia and later in 2015 this account was automatically renamed to "Marek594~skwiki", due to the other account also being named "Marek594". Can I somehow have my accounts merged? I would really like to use the name "Marek594" for all my accounts. — Preceding unsigned comment added by Marek594~skwiki (talkcontribs) 16:46, 20 December 2018 (UTC)

Unfortunately your local accounts on skwiki can not be merged. Ruslik_Zero 20:25, 20 December 2018 (UTC)
You can use Marek594 at all wikis but the edits currently attributed to Marek594~skwiki cannot be merged to Marek594. The message at sk:User talk:Marek594~skwiki#Your account will be renamed says you can merge accounts but that was only for a period in 2015 before the account was renamed. You are free to write on the user pages that you are the same user. PrimeHunter (talk) 22:05, 20 December 2018 (UTC)
Ok, thanks anyway.

--Marek594 (talk) 15:49, 21 December 2018 (UTC)

Medicine/Discussions

Hi Wikipedia:WikiProject_Medicine/Discussions has stopped working apparently, any help is appreciated--Ozzie10aaaa (talk) 11:21, 20 December 2018 (UTC)

Limits to revision deletion?

I imagine this has been discussed before, but I can't see where. In revision deletion, there seems to be a sort of ceiling to the number of revisions that can be hidden in one go (around 120, I think). Is this intentional? If not, can it be fixed? It probably isn't often necessary to hide hundreds of revisions, but it would certainly be good to be able to do it in one operation when it actually is needed. If I try it using my usual browser, Safari 12, I get kCFErrorDomainCFNetwork:303, which I know can sometimes be fixed by deleting data associated with the domain; but deleting all data relating to Wikipedia is not something I want to do. So I tried using Firefox 64, and the "change visibility of selected revisions" button did exactly nothing at all. Any advice, anyone? Justlettersandnumbers (talk) 19:47, 19 December 2018 (UTC)

You actually have to tick some revisions for the change button to do something, and then you have to put more ticks to specify if user, summary or revision needs to be hidden. Anyway of you try to act on too many revisions at once the database action will probably lag too long and time out. Doing it in smaller sets should avert this. I sometimes get this problem when restoring pages. Retrying usually overcomes the problem. Graeme Bartlett (talk) 12:15, 22 December 2018 (UTC)
It is more of a "seconds of operations" limit vs a "number of revisions" and may vary depending on how busy the server is at the time. — xaosflux Talk 14:08, 22 December 2018 (UTC)

Bibcodes

Richard Feynman was littered with bibcode-related warnings. Note knowing how to fix them, I have removed the bibcodes. Does anyone know anything about this problem? Hawkeye7 (discuss) 04:13, 23 December 2018 (UTC)

Looks like Headbomb has figured it out. Don't know what happened though. Hawkeye7 (discuss) 05:15, 23 December 2018 (UTC)
It was due to this edit by Hmains; Headbomb also mentioned it on Hmains's talk page. Graham87 06:22, 23 December 2018 (UTC)

Analysing long articles

For very long articles (like 1918 New Year Honours - caution, ~690Kb!), with many subsections, is there a tool that will tell us the size of each section? That would help when deciding where to split them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:46, 22 December 2018 (UTC)

It doesn't require accuracy so you could just click the sections in the TOC one at a time and watch how much further the vertical scrollbar in your browser jumps. Using this method, 1918 New Year Honours#Military Cross (MC) is currently the longest section with around 1/3 of the whole page. I don't know whether there are honours which logically belong on the same page or are so important that they should be on the main page. PrimeHunter (talk) 21:28, 22 December 2018 (UTC)
User:Dr pda/prosesize.js might help. Edit each section in turn and record the prose size / word count of each in a list. – Jonesey95 (talk) 22:13, 22 December 2018 (UTC)
Thank you both for the suggestions, but there are sixty-five sections on the page I gave as an example; hence my question about a tool. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:59, 22 December 2018 (UTC)

{{#invoke:Sandbox/trappist the monk/section size|size|1918 New Year Honours}}Script error: No such module "section size".

Trappist the monk (talk) 15:23, 23 December 2018 (UTC)

@Trappist the monk: Just the job; thank you. I have incorporated that in {{Section sizes}} and deployed it on Talk:1919 New Year Honours, by way of an example. Could I request one change? The example currently has, for example:

  • Royal Red Cross 25
  • First Class (RRC) 3728
  • Second Class (ARRC) 17235
  • Awarded a Bar to the Royal Red Cross (RRC*) 746

With no indication that the latter three are sub-sections of the first item. Could we have it so that either the first item shows the cumulative total or the other three show the level of heading, or both - whichever is easiest to code. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:54, 23 December 2018 (UTC)

WP 1.0 bot obsolete listings

I am seeking clarification on two items:

  1. The project index for WP 1.0 bot includes two entries for one project: WikiProject Law and "WikiProject Legal". As a result, the bot creates User:WP 1.0 bot/Tables/Project/Legal (and will recreate it if it is deleted), which has been superseded by User:WP 1.0 bot/Tables/Project/Law. Can the duplicate entry be removed?
  2. Category:Version 0.5 articles by quality and its subcategories were deleted based on this discussion, but "Version 0.5" still appears in the index. Can the deleted project be removed?

I originally posted the same question at Wikipedia talk:Version 1.0 Editorial Team/Index‎ but no one seemed to know. Thank you, -- Black Falcon (talk) 18:42, 23 December 2018 (UTC)

CSS Usergoup show classes

For those not aware, per a request at MediaWiki_talk:Common.css#New_show_class_for_extendedconfirmed_users, we recently introduced a new CSS show class for users in the "extendedconfirmed" usergroup. However, in its first deployment at Wikipedia:Requests for adminship/Nominate, it inadvertently hid the "nominate another user" input box from sysops (as sysops are not in the extendedconfirmed group as its rights are redundant to the sysop set). I worked around the issue by duplicating the input box under <div class="sysop-show">. Given that using such a workaround whenever the classes are used is less than ideal, I was wondering if there were any thoughts on requesting a config change so that any text under <div class="extendedconfirmed-show">, <div class="extendedmover-show">, <div class="patroller-show">, <div class="templateeditor-show">, and any relevant future classes also be viewable by those in the sysop group to avoid confusion or information being inadvertently hidden (perhaps by making sysops implicit members of the rights they can add except IP block exempt (as IPBE does have some rights not automatically included in the sysop package regarding editing through TOR). Best, Mifter (talk) 04:24, 23 December 2018 (UTC)

I've removed the duplicate and added both classes: <div class="sysop-show extendedconfirmed-show">. — JJMC89(T·C) 04:42, 23 December 2018 (UTC)
(edit conflict) just use multiple classes on the section you want seen to multiple groups. — xaosflux Talk 04:46, 23 December 2018 (UTC)
Makes sense in general, for sure, but given that we can just add all the CSS classes to the same div (JJMC89 beat me to the punch in doing that), it's not that big a deal IMO. Writ Keeper  04:48, 23 December 2018 (UTC)
Thanks for fix JJMC89. Best, Mifter (talk) 00:24, 24 December 2018 (UTC)

Consensus needed: MediaWiki talk:Common.js

Please help in forming a consensus at a discussion at Mediawiki talk:Common.js regarding a temporary fix for T200969 (No way to reach the editable version of a page when viewing the most recent mobile diff). — fr+ 05:09, 24 December 2018 (UTC)

Could not identify and resolve two issues

In [this] page, I was able to see two pages in that list in which there are tidy bug affecting font tags wrapping links error. When I tried to resolve that issue, two problems occurred. One, its protection. Secondly, I was not able to figure it out. If somebody can, please check for correcting those two errors.Adithyak1997 (talk) 11:05, 24 December 2018 (UTC)

@Adithyak1997: Those two interface pages happen to display their own talk pages on the interface page. To take them out of the LintErrors report, you could have a look at the "font" tags in the editor signatures on MediaWiki talk:Deletedtext. -- John of Reading (talk) 11:26, 24 December 2018 (UTC)

IP tools traceroute links to paywalled domaintools site

The traceroute link in the top menu (User → IP lookup... → Traceroute) points to [27] which is not (any longer) free. I don't recall if this menu is from a MW gadget or something else. Where should it be reported (assuming it's not intentional/desirable)? —[AlanM1(talk)]— 00:43, 23 December 2018 (UTC)

@AlanM1: this is a good place to start. I'm having a little trouble finding what you are talking about, not sure what the "top menu" is you are referring to? Is this from a script or gadget? Is it from a hover-popup? Is it a page tab or sidebar link? — xaosflux Talk 00:49, 23 December 2018 (UTC)
Here is a random IP user for reference: User:196.229.244.173. — xaosflux Talk 00:51, 23 December 2018 (UTC)
@Xaosflux: On the top tab menu, I have the tabs: Read, Edit, View history, (star), More v, Page v, User v, TW v . This is on the User menu. I'm guessing it's an optional gadget if you aren't seeing it. —[AlanM1(talk)]— 00:57, 23 December 2018 (UTC)
@AlanM1: It's the MoreMenu script, currently maintained by User:MusikAnimal. Issues can be reported at meta:Talk:MoreMenu. --AntiCompositeNumber (talk) 00:58, 23 December 2018 (UTC)
@AntiCompositeNumber: Thanks. I'll report it there. —[AlanM1(talk)]— 01:00, 23 December 2018 (UTC)
Also maybe MediaWiki talk:Gadget-dropdown-menus-vector.js. — xaosflux Talk 01:22, 23 December 2018 (UTC)
I'm not aware of a free alternative, so I've just removed the link. Thanks MusikAnimal talk 21:34, 24 December 2018 (UTC)

Template:copyvio-revdel

This template has parameters that allow you to specify the oldid= numbers for the revisions that should be removed, e.g. {{Copyvio-revdel |start = 670675971 |end = 874594651}} produces links to https://en.wikipedia.org/w/index.php?oldid=670675971 and https://en.wikipedia.org/w/index.php?oldid=874594651. Is it possible to add a link that, if clicked, will load a history page and cause these revisions and all of those intervening to be clicked for revdel? Obviously you don't have to do a ton of clicking, but there's no obvious way to identify revisions in the page history by their oldids (without mousing over each link to see the full URL), and the current setup seems error-prone. (I'm asking this after messing up a revdel on the page where those oldids occurred.) I'd like to propose that the template have such a link, but I figured I'd start here by asking about the possibility before I propose its advisability. Nyttend (talk) 04:51, 22 December 2018 (UTC)

I don't think there was an existing way to pass in checkbox IDs via the URL, so I wrote one. Once you install User:Enterprisey/url-select-revdel.js and go to User:Enterprisey/sandbox, you will see the sandbox version with a link that has the checkboxes auto-selected. Once it looks good, we can copy over the sandbox version of the template. Enterprisey (talk!) 07:56, 22 December 2018 (UTC)
Perhaps it's unnecessary as it appears the change is afoot, but I too would like to see this change. I had my first experience with the template a few days ago, and I was struck by how needlessly cumbersome the process was. Many thanks to Enterprisey for attempting a fix. Xymmax So let it be written So let it be done 16:31, 23 December 2018 (UTC)
I have started a discussion on merging in the sandbox version of the template, so that this link will appear to everyone. I don't like how a user script is required to use the link, but since the target audience is so small it would be silly to put it in, say, a default gadget or common.js. Enterprisey (talk!) 03:40, 24 December 2018 (UTC)
How about putting it in MEdiawiki:Group-sysop.js, since only sysops need to see it? SD0001 (talk) 03:45, 24 December 2018 (UTC)
Sure, I wouldn't object to that. Enterprisey (talk!) 03:53, 24 December 2018 (UTC)
Okay, I added it to the template; it needs my user script to work for now. Enterprisey (talk!) 07:44, 25 December 2018 (UTC)

Script to revert last 1 edit?

Can someone quickly hack together a script to revert the last edit on a page, precisely? It would be useful for script writers and testers to quickly revert their test edit on a page. Of course, neither MW rollback nor Twinkle rollback is useful since those would revert all edits by the last editor, and the built-in undo is too slow and requires a lot of clicks. SD0001 (talk) 08:59, 25 December 2018 (UTC)

SD0001, User:Enterprisey/undo-last-edit Galobtter (pingó mió) 09:00, 25 December 2018 (UTC)
@Galobtter: Neat, thanks! SD0001 (talk) 09:02, 25 December 2018 (UTC)

Christmas greeting header issue

Hi, Ser Amantio di Nicolao has been sending this Xmas greeting to everyone however when you clicked on the edit button next to the header on anyones talkpage it took to you to https://en.wikipedia.org/w/index.php?title=Template:ShilohbyBillings&action=edit, Is there a way to fix this ?

I've removed the header for the time being so now the headers don't show but as I said when they did it was taking you to that template as opposed to that section of whoevers talkpage,
Thanks, –Davey2010 Merry Christmas / Happy New Year 21:06, 25 December 2018 (UTC)

This is why templates that go on user talk pages should be substituted. I've added autosubst code to the template. {{3x|p}}ery (talk) 21:35, 25 December 2018 (UTC)
Hi, Just left you a message - Unfortunately it's still taking me too https://en.wikipedia.org/w/index.php?title=Template:ShilohbyBillings&action=edit&section=T-1, Sorry if this is all simple and basic stuff but I'm hopeless when it comes to templates, Many thanks, –Davey2010 Merry Christmas / Happy New Year 21:41, 25 December 2018 (UTC)
  Resolved

- Many thanks Pppery. –Davey2010 Merry Christmas / Happy New Year 22:23, 25 December 2018 (UTC)

@Pppery and Davey2010: It's not a problem with templates on user talk pages per se. The problem concerns templates that contain headings, transcluded into any namespace. If {{ShilohbyBillings}} were to be transcluded right here on this page, the problem would also occur. If Template:ShilohbyBillings did not contain a heading, there would be no problem. --Redrose64 🌹 (talk) 01:20, 26 December 2018 (UTC)
If a heading is output from a template or parser function like {{#if:1|==Merry Christmas!==}} then it produces no section edit link when it's transcluded, or at the page itself. But it's confusing and should be avoided in most cases. PrimeHunter (talk) 01:35, 26 December 2018 (UTC)

Archive urls

Why bot added in this article archive urls to websites that are avaiable? For example swedishcharts.com. Eurohunter (talk) 08:17, 25 December 2018 (UTC)

I guess (for swedishcharts) it's because the charts are constantly updated, so they need to be archived with date from context. --MarMi wiki (talk) 01:59, 26 December 2018 (UTC)

How to say on WP: "Pssst, hey, I got a nicer version here for you"?

I am working with a table that has many colors and info. We have also created usable versions in black-and-white, simplified, and with extended details. Q: How can/should we link to these from an article, being a good website? Good article code does not allow such links.

The table is {{Periodic table}}, and the variants are like detailed, blind, b/w. -DePiep (talk) 23:56, 23 December 2018 (UTC)

@DePiep: Your question seems not clear. Where do you want link {{Periodic table}} from. Is that in an article here in enwiki?, on another WMF wiki? or completely external website?. –Ammarpad (talk) 04:50, 26 December 2018 (UTC)
I guess he's talking about linking them from enwiki articles only. @DePiep: this discussion would better be held at WT:WikiProject Chemistry and/or the talkpage of MOS page which "does not allow such links". SD0001 (talk) 06:39, 26 December 2018 (UTC)
Problem is: from article periodic table, we are not supposed to link to an non-present, alternative image/table version. But for some situations the reader might be helped with a black/white version (in tablespace, or on commons). WIll go to MOS as proposed. -DePiep (talk) 09:50, 26 December 2018 (UTC)

convert to multi column list

There is an article with a very long list. I'd like to change it to multiple columns. Is there a way to do this (or convert it to a multi column table) that is easy? RJFJR (talk) 00:58, 27 December 2018 (UTC)

@RJFJR: Put {{div col|colwidth=20em}} immediately before the list, and {{div col end}} immediately after. Adjust the value of the parameter |colwidth=20em to suit the typical length of the entries in the list For real-world examples, see e.g. WP:Meetup/UK#Oxford. --Redrose64 🌹 (talk) 10:23, 27 December 2018 (UTC)

Books / Collections

Hi,

for quite some time now the function to create PDFs from Collections on Wikipedia is broken. To remedy the situation I put up a server

http://mediawiki2latex.wmflabs.org/

Because of limited resources I had to limit the PDF output to roughly 200 pages. On my computer at home I was able to generate a PDF file with more than 5000 pages.

I now consider to set up a server that is able to create PDFs up to 25000 pages. Since the I would have to pay 3000 EUR for that, its is interesting to me if anybody wants PDF versions of collections that are between 5000 pages and 25000 pages in size. Please comment here or contact me in any other way if you are interested.

Yours Dirk Hünniger (talk) 12:03, 27 December 2018 (UTC)

Anybody have any idea why this infobox is displaying images at default like 75px? The documentation seems to indicate it uses the same 220px default as basically every other template. Compare Meiko (American singer). It's like an infobox with a postage stamp. GMGtalk 17:05, 27 December 2018 (UTC)

The issue there was that |landscape=yes which made the image height 200px. {{#ifeq:{{lc:{{{Landscape|{{{landscape|}}}}}}}}|yes|{{min|300|{{#if:{{#ifexpr:{{{Img_size|{{{image_size}}}}}}}}|300|{{{Img_size|{{{image_size}}}}}}}}}}x200px sets the image size (essentially, 200px width is the default, unless landspace is set to yes then it is 200px height). There was previous discussion at Template talk:Infobox musical artist/Archive 14#Image size about this. Infobox musical artist should definitely be set to not use fixed image sizes. Galobtter (pingó mió) 17:38, 27 December 2018 (UTC)
Silly templates. Thanks for fixing. GMGtalk 17:42, 27 December 2018 (UTC)

Hi, I was involved in developing this page. The other page creator copied and pasted it into mainspace, rather than moving it to article space. Here is the original page: User:E.M.Gregory/sandbox Could you restore the page history, please? Thanks, Yoninah (talk) 13:41, 27 December 2018 (UTC)

Fixed. Wikipedia:Requests for history merge is the recommended place for requests. PrimeHunter (talk) 17:54, 27 December 2018 (UTC)
Thank you! Yoninah (talk) 18:35, 27 December 2018 (UTC)

finding unnecessary instances of template:image requested

Found myself going through some pages with {{image requested}} on the talk page, and found that a lot of them are outdated (i.e. an image has been added in the time since being tagged). I'm looking for a way to generate a report/list of such cases. In other words, articles with images that have {{image requested}} on the talk page. (Even better if we can restrict those instances of image requested to those without the "if" parameter set, which is often used when there's already an image to indicate what additional image would be useful).

To be clear, instructions for how to do this would be appreciated, but I'm also more interested in the report itself if this is the sort of thing that someone else has the knowhow to just produce easily. :) — Rhododendrites talk \\ 02:34, 28 December 2018 (UTC)

Rhododendrites, I looked through PetScan again and found that it can search by talk page template and lead image. this query is not perfect and is not suitable for a bot run or anything, but should give an idea of the scale of the problem. In the Output tab you can turn on the Image page metadata which will show the image in the list. That's a lot of images, so I have it off in the query above. --AntiCompositeNumber (talk) 14:00, 28 December 2018 (UTC)
@AntiCompositeNumber: Ah! Nice. Yes, that's helpful. Clicking through the first bunch, indeed most of them are outdated. :/ — Rhododendrites talk \\ 14:24, 28 December 2018 (UTC)

Is it possible

to design a template (and primarily the associated module) that makes it possible to verify (in binary; yes or no) whether a particular user is in a particular user-group? It shall have two parameters; one for the username and another for the group-name.WBGconverse 13:38, 28 December 2018 (UTC)

No. There's no way to get the information without API access or scraping Special:listusers, neither of which is possible through Lua. SD0001 (talk) 14:32, 28 December 2018 (UTC)

Unable to load script from local server

On trying a load a user script from my local web server,

mw.loader.load('http://localhost/xxxxx.js');

as recommended at Wikipedia:User_scripts/Guide#Loading_it_from_a_localhost_web_server, I get the following in the console:

[Report Only] Refused to load the script 'http://localhost/xxxxx.js' because it violates the following Content Security Policy directive: "script-src 'unsafe-eval' 'self' meta.wikimedia.org *.wikimedia.org *.wikipedia.org *.wikinews.org *.wiktionary.org *.wikibooks.org *.wikiversity.org *.wikisource.org wikisource.org *.wikiquote.org *.wikidata.org *.wikivoyage.org *.mediawiki.org 'unsafe-inline'". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

Is there any solution? SD0001 (talk) 08:53, 24 December 2018 (UTC)

its ‘report only’ it shouldnt actually stop you from running the script. It might do so at some point in the future however. —TheDJ (talkcontribs) 11:02, 24 December 2018 (UTC)
ohh, I see its indeed working, just that earlier there had been some issue with the script itself. Thanks, SD0001 (talk) 12:24, 24 December 2018 (UTC)
We probably shouldn't block localhost URLs. I've added a comment to that effect on phab. Enterprisey (talk!) 08:43, 25 December 2018 (UTC)
Enterprisey, which phab ticket? SD0001 (talk) 06:51, 26 December 2018 (UTC)
SD0001, phab:T135963#4843260 --AntiCompositeNumber (talk) 14:39, 28 December 2018 (UTC)

Why aren't the sections in this meta-wikimedia article collapsible?

Note: This question is being migrated from the Help Desk, per suggestion by Vchimpanzee, the original is here.

I was reading the Community Engagement Insights Report and noticed that all of the sections for the Community Engagement Department were expanded and not collapsible. I couldn't find anything wrong with the source code, so I was wondering if anyone knew why the sections are behaving in such an odd way. I decided not to ask this question at the Wikimedia Help Forum because it appears to be inactive. —The Editor's Apprentice (TalkEdits) 18:32, 28 December 2018 (UTC)

The Editor's Apprentice, are you talking about mobile view? Because sections aren't collapsible in desktop view. Galobtter (pingó mió) 18:36, 28 December 2018 (UTC)
Yes, I am, let me clarify that in my link! —The Editor's Apprentice (TalkEdits) 18:41, 28 December 2018 (UTC)
@Galobtter: Do you have any ideas? —The Editor's Apprentice (TalkEdits) 21:16, 28 December 2018 (UTC)

Do edit summaries still autocomplete in Firefox?

In the past Firefox has allowed me to save custom edit summaries (not the dropdown-boxes gadget, which is very general) for reuse as a dropdown list, but now I can't; I've tried all the FF troubleshooting advice, including disabling add-ons. Any ideas? I'm using Windows 10 and Firefox 64.0. Thanks and all the best, Miniapolis 20:21, 28 December 2018 (UTC)

I've never used this. It sounds vaguely like a general autocomplete field that I would've disabled immediately. Have you recently cleared anything, reinstalled FF, moved to a new system, or anything like that? That would probably reset the autocomplete info. Ian.thomson (talk) 20:24, 28 December 2018 (UTC)
I use FF's form autocomplete there and it is still working for me, is that what you are referring to? — xaosflux Talk 20:31, 28 December 2018 (UTC)
Yes, but my form autocomplete isn't working for some reason. I didn't realize until I switched to Chrome (because my old computer became too slow for FF) that the edit-summary autocomplete was a browser setting and not WP; it wasn't available, AFAIK, in Chrome. FF troubleshooting alludes to possible conflicts with antivirus software (I'm using Windows Defender) and I took a look at what I have, but don't want to disable something important for a convenience. I miss it, though; my chief contributions here are copyediting, and it makes life easier. Never got the dropdown boxes when I checked the gadget in Preferences, and I wonder why. This is a new computer, hence the switch back to FF (which I love otherwise) :-). Thanks for the suggestions and all the best, Miniapolis 23:31, 28 December 2018 (UTC)
Finally saw an autocomplete suggestion. Don't know if it was a FF setting I tweaked or the Simple Form Fill extension but thanks, Xaosflux, for letting me know it was still possible. All the best, Miniapolis 03:09, 29 December 2018 (UTC)
If this was forms autocomplete, unless you did something special to migrate, those values don't normally follow you between computers. — xaosflux Talk 03:40, 29 December 2018 (UTC)

Bot tab at AWB

Hello. I try to use Wikipedia:AutoWikiBrowser after a long time. I have downloaded it but the bot tab is not there. Why? Xaris333 (talk) 00:27, 30 December 2018 (UTC)

You must log into it with a bot account. Enterprisey (talk!) 02:13, 30 December 2018 (UTC)
The bot option will allow AWB to autosave without the manual save click. You must check each edit that AWB makes before saving. Particularly if you have not much experience with it, you had better find out what the options do. I have had problems with editing templates, file names, and URLs when it should be leaving them alone. Not everything it attempts to do is sensible and the operator is responsible. Graeme Bartlett (talk) 08:01, 30 December 2018 (UTC)

Interesting floating menu of icons

  Resolved
 – Thank you, --Dweller (talk) Become old fashioned! 11:01, 31 December 2018 (UTC)

When I visit this page: Hosen_Yisrael, I see a floating menu of 7 icons in the upper right hand edge of the page. I've never seen such a menu before. What's making it appear? I can't see anything in the wikicode, but then again, I'm rubbish at wikimarkup. Any ideas? --Dweller (talk) Become old fashioned! 17:32, 30 December 2018 (UTC)

@Dweller: You have enabled WP:Page Curation. --Izno (talk) 17:46, 30 December 2018 (UTC)
Hmmm... I've changed no settings in ages. Never seen that before, and it's not showing on any other pages. --Dweller (talk) Become old fashioned! 00:10, 31 December 2018 (UTC)
Dweller, Press the top button and then x out of it and it will go away again. It was recently tweaked with regards to when and where it appears, so old settings were likely overridden. If you X out of it, it should go away so long as you don't open it via the curate link in the toolbox. — Insertcleverphrasehere (or here)(click me!) 10:54, 31 December 2018 (UTC)

Ahhhh is it because it's a recently created page? --Dweller (talk) Become old fashioned! 10:52, 31 December 2018 (UTC)

Dweller, Yes it was configured to show up on new pages automatically unless that user disables it. — Insertcleverphrasehere (or here)(click me!) 10:56, 31 December 2018 (UTC)

Thanks. --Dweller (talk) Become old fashioned! 11:01, 31 December 2018 (UTC)

Experts of CSS handling in IE11 please

  FYI
 – Pointer to relevant discussion elsewhere.

Please see Template talk:Tree list#A problem with long Tree list and assist there please. --Redrose64 🌹 (talk) 22:27, 31 December 2018 (UTC)

Mobile view hiccup

We have an odd problem as seen at Japan. The problem is with mobile view as seen here in mobile view ...note: the first paragraph is all out of order.... as in the first paragraph seen in mobile view is not the first paragraph of the article in normal view.--Moxy (talk) 20:48, 1 January 2019 (UTC)

It seems to have been caused by Special:Diff/852164711. But the edit summary of that change indicates that it was an attempt to avoid exactly this problem. Strange. Suffusion of Yellow (talk) 21:02, 1 January 2019 (UTC)
@Moxy: Ok, it looks like someone was trying to move the {{Coord}} template to the bottom of the page, but mistakenly wedged it between the first two paragraphs. I've moved to where WP:ORDER says it should go, between the navboxes and the categories, and the problem seems fixed. Suffusion of Yellow (talk) 21:13, 1 January 2019 (UTC)

Updated since my last visit

Maybe a backlog issue if updates are lazy. I noticed today that [28] keeps showing two "updated since my last visit" entries despite me visiting the two related diffs and the page itself twice (doing an explicit browser refresh to each the last time). Here are the pages I revisited and refreshed: [29] [30] [31]. I would usually expect the history to no longer show those entries as unvisited. —PaleoNeonate – 23:37, 1 January 2019 (UTC)

This appears to be resolved, I suspect that my hypothesis about the backlog or dynamic update was right. Sorry for the noise, —PaleoNeonate – 23:44, 1 January 2019 (UTC)

Extra buttons not appearing on Legacy Toolbar gadget?

I enabled the option "Add extra buttons to the old (non-enhanced) editing toolbar" in the Preferences settings, but I don't see extra buttons appearing, like the CodeMirror/Syntax highlighting (Pencil/Pen) icon and the TemplateWizard (Puzzle) icon. Is there something wrong with either the toolbar or the option? -- George Ho (talk) 22:12, 1 January 2019 (UTC)

The old toolbar is not supporting them yet. Read this description to see the buttons you should expect before and after enabling the 'extra buttons'. –Ammarpad (talk) 05:56, 2 January 2019 (UTC)

Adding Tilde in ANI notification template.

Template:You should notify any user that you discuss that is used in the edit notice at ANI only mentions Template:AN-notice and does mention that the editor has to add the ~~~~ after copy/pasting the notification template. I have proposed to add this ~~~~ to the Template with an edit request at Template_talk:You_should_notify_any_user_that_you_discuss#Template-protected edit request on 2 January 2019.

I have edited the sandbox here but only "{{subst:AN-notice}}" shows up with a white background and the tilde appears seperate.

Can someone please help with the HTML tags so that both "{{subst:AN-notice}}" and "~~~~" are shown with a white background, so that it is easier to copy paste the notification template. --DBigXray 17:09, 2 January 2019 (UTC)

The template code is displayed with {{Tlsx}} which adds <code>...</code>. I have added it to the tildes too.[32] PrimeHunter (talk) 19:34, 2 January 2019 (UTC)
PrimeHunter Thank you for your edit, that was exactly I was looking for. I am marking the thread as resolved, regards. --DBigXray 19:40, 2 January 2019 (UTC)
  Resolved

substituting deprecated template without category

Trying to clean up an old template's transclusions. In a few places I need to simply substitute the template's code but I'm running into an issue. The template includes some code to add a category: <includeonly>[[Category:Pages using deprecated medal table templates]]</includeonly>. I don't want that to be included in the substitution. I've tried to look through the safesubst documentation but am kind of lost. Can someone show me how to do this? If I have the following template code, how do I make it so that the first 2 lines are substituted but the bottom line is not. Note that the category SHOULD be included if you transclude the template.

This is my template
It includes a smiley :-)
[[Category:Some category that is ommitted ONLY when you substitute the template]]

Thanks in advance. (Please {{ping|Zackmann08}} in your response if possible). --Zackmann (Talk to me/What I been doing) 22:52, 2 January 2019 (UTC)

@Zackmann08:{{{{{|safesubst:}}}ifsubst||[[Category:Some category that is ommitted ONLY when you substitute the template]]}} {{3x|p}}ery (talk) 22:54, 2 January 2019 (UTC)
@Pppery: There's a ifsubst function?!?!?!!?! --Zackmann (Talk to me/What I been doing) 22:57, 2 January 2019 (UTC)
It's just a template (Template:Ifsubst). {{3x|p}}ery (talk) 01:51, 3 January 2019 (UTC)

Editing text has different colors, need to revert

  Resolved

I was editing in a non-module namespace, and suddenly, the editing text changed colors for some reason. I don't know what happened, and I don't know how to revert it. How do I revert this change? Steel1943 (talk) 02:55, 3 January 2019 (UTC)

  • ...Never mind, just figured it out. Steel1943 (talk) 03:02, 3 January 2019 (UTC)

New gadget proposal: Script Installer

I propose we add one of the Script Installer scripts (User:Enterprisey/script-installer or User:Equazcion/ScriptInstaller) as a new gadget. It would make the setup process for new users easier: instead of having them go through common.js for the first user script install, they could just check a checkbox. (The difference between the two scripts? Not much, but mine has one or two more features and is more actively maintained. I don't personally prefer either that strongly.) For the sake of unambiguity, "Support" votes by default will be for my script; if you prefer the other one, please indicate that. Enterprisey (talk!) 07:40, 2 January 2019 (UTC)

  • Support Great idea. I always wanted to promote user scripts and encourage more users to use them. Abelmoschus Esculentus talk / contribs 08:02, 2 January 2019 (UTC)
    Abelmoschus Esculentus, thanks for supporting; I modified the proposal to say that unspecified "Support" recommendations will be taken to mean my script. Is that fine? Enterprisey (talk!) 08:43, 2 January 2019 (UTC)
It's okay, I don't mind. Abelmoschus Esculentus talk / contribs 08:45, 2 January 2019 (UTC)
  • Support Making such a script a gadget enabled by default for all registered users. Just installed Enterprisey's version to try it out but it isn't working. I've been using Equazicon's version for some time and would like to see 2 improvements in that: (i) don't display that unnecessary "Must be installed manually" message on Medawiki JS pages, because user scripts would always be in userspace, JS pages in MW namespace are usually gadgets or their supporting files, which are most of the time not supposed to be installed manually. (ii) Show a Install button inside {{Infobox user script}} invocations that specify the |source= parameter. This would allow people to install scripts right from the documentation page, without needing to go the source file (non-tech-savvy people anyway have no business looking at the source file). SD0001 (talk) 09:53, 2 January 2019 (UTC)
    Done for both. Enterprisey (talk!) 22:59, 2 January 2019 (UTC)
  • Support A script installer is seriously needed. I have a some knowledge of coding which allows me to understand what is going on in my common.js, but for people with no knowledge, it must be a nightmare to copy and paste lines of gibberish onto their common.js. It seems that Enterprisey's script may have some minor flaws which prevent it from working at the moment. However, I would any day support a maintained script over a un-maintained one. — Preceding unsigned comment added by FR30799386 (talkcontribs) 11:50, 2 January 2019 (UTC)
  • I support this idea in general, but I'd like to see some warnings (such as those from MediaWiki:Jswarning) incorporated in to this - and present them every time it is used. — xaosflux Talk 13:27, 2 January 2019 (UTC)
  • Support. And I think we should use the one with more features and being actively maintained. –Ammarpad (talk) 15:05, 2 January 2019 (UTC)
  • Conditional Support only if the gadget version is limited to a whitelist of scripts, preferably curated by WP:INTADMINs. Scripts can be powerful and dangerous, and if someone can't figure out how to edit their common.js file, they probably also don't have to skills to evaluate a random script they found in someone's user space. If someone wants to have an installer for random scripts, they can add User:Enterprisey/script-installer or User:Equazcion/ScriptInstaller the old fashoned way. --Ahecht (TALK
    PAGE
    ) 17:18, 2 January 2019 (UTC)
    • That would be basically redundant; that's effectively what Special:Gadgets is right now. It would be simpler to just make that curated list of scripts into gadgets themselves. Writ Keeper  17:33, 2 January 2019 (UTC)
    • @Ahecht: the script installer can also be used to uninstall scripts. SD0001 (talk) 17:45, 2 January 2019 (UTC)
  • What should be supported is adding more gadgets, not continuing to support random scripts. So, I actually oppose this suggestion. --Izno (talk) 18:51, 2 January 2019 (UTC)
    User scripts are much easier to make than gadgets, and not all scripts become gadgets, especially niche or experimental ones. There will always be editors wanting to install user scripts, so we should make it easier for them to do so. Making this script a gadget shouldn't prevent new gadgets from being added. Enterprisey (talk!) 21:23, 2 January 2019 (UTC)
  • Conditional support People who don't understand how to install scripts wouldn't know how to install Script Installer, so a gadget makes sense to me in that regard. But I agree with Xaosflux, please have it show MediaWiki:Jswarning or the like and require confirmation. That is a must. The alternative would be some sort of curated list of reviewed user scripts to guarantee they are safe, as some have mentioned above, but I think that may pose too much of a maintenance burden. MusikAnimal talk 22:59, 2 January 2019 (UTC)

On warnings

While we discuss the proposal above, a couple of people (xaosflux and MusikAnimal) wanted warnings before installation. I thought we could discuss how the warnings should be designed here. I don't want a box to click through for every install, because users will quickly learn to ignore the box and just click through. (I would be happy with adding such a box if we can't think of something better, of course.) However, that doesn't leave us with many other options. Maybe we could have the script display a new notice at the top of user script pages, like Jswarning, mentioning the specific action of clicking "Install" as a potential risk? Enterprisey (talk!) 02:16, 3 January 2019 (UTC)

The notice is all we give now on the top of your own page when you are about to install something (e.g. Special:MyPage/common.js) so "insert a box" would at least insert the warning since you would not see the traditional one first when using an installer, maintaining the same warning level. — xaosflux Talk 02:26, 3 January 2019 (UTC)
We just need to be transparent that the script you're installing is not guaranteed to be safe, and this should be conveyed before the script is installed. A normal JavaScript window.confirm() popup would do fine. I think it's okay if users learn to ignore it -- they only need to see it once to understand the risks. A message atop a page where scripts are installable seems okay too, but I would give it a red background like MediaWiki:Jswarning so that it stands out. On that note we'll probably want our own wording, as Jswarning is written assuming you're editing source code directly ("Code that you insert on this page..."). MusikAnimal talk 02:56, 3 January 2019 (UTC)
Mediawiki:Jswarning is displayed atop every userspace js page, not just on your own common.js. So, we just need to modify it so that it says something else ("Scripts could contain malicious content capable of compromising your account. Please install scripts only from trusted sources") while on others' script pages, and retain the existing wording while on the user's own common.js or skin js pages. I don't think a confirm popup before every install is necessary. SD0001 (talk) 03:55, 3 January 2019 (UTC)

Searching for strings specifically not in a page's source

I understand that we can search for specific "character strings" within a page's source, but: can we search for pages that do not contain a specific string? Particularly, I am seeking pages in need of a {{Short description}} by searching for pages without "{{Short description" in their source. Thank you.--John Cline (talk) 03:57, 3 January 2019 (UTC)

Use hastemplate instead. --Izno (talk) 04:33, 3 January 2019 (UTC)
(But that said, yes you can--you just shouldn't want to here. --Izno (talk) 04:34, 3 January 2019 (UTC))
Thank you Izno, I understand and appreciate the information.--John Cline (talk) 11:22, 3 January 2019 (UTC)

Finding "hidden articles" hidden behind redirects

Is there a tool/method/way of finding "articles" that are hidden behind redirects? While updating some pages to avoid double redirects I came across Isoko people and China Sourcing Fairs, which until I fixed them contained an improper #REDIRECT at the top. I don't know if this was a failed attempt at a merge, vandalism, or what, but it might be a good idea to find any similar pages in order to properly evaluate them. I just have no idea of how to do that! Primefac (talk) 16:38, 3 January 2019 (UTC) (please ping on reply)

I just got pointed to Special:ListRedirects, which I forgot existed, but I still can't think of a way to cross-reference that with potentially hidden articles. Primefac (talk) 16:40, 3 January 2019 (UTC)
Pretty easy to query for redirects with long wikitext. I'm not sure what an appropriate cutoff is; 250 characters is enough for a moderately long stub, but short enough that, what with all the needlessly-categorize-this-redirect templates out there, there's some 64000 hits. —Cryptic 17:06, 3 January 2019 (UTC)
Awesome, thanks! SQL made up a list of those pages, definitely some questionable redirects in there! It looks like anything in the 500-800 range will likely have categories and/or rcats involved, but the top of the list definitely needs looking at. Primefac (talk) 17:16, 3 January 2019 (UTC)
This is what the now-defunct Wikipedia:Database reports/Redirects obscuring page content reported, with the cutoff then set at >449. The presence of rcategorization makes the low end tricky. ~ Amory (utc) 22:39, 3 January 2019 (UTC)
Amorymeltzer, I've written a script to remove markup, templates, wikilinks, categories, and html comments from the page_len count. There are a couple edge cases missed, mostly due to unclosed tags, but it's a lot easier to use: User:SQL/Hidden pages/Adjusted. SQLQuery me! 00:44, 4 January 2019 (UTC)
We could use the edit filter to help prevent this from happening again. I think it could be fairly reliable at detecting whether it's a full article versus redirect templates, but we'd probably want a "if page size > N" check, just to be sure. MusikAnimal talk 23:18, 3 January 2019 (UTC)

Hyphens, ndashes, and (gasp!) Nazis!

How's that for a heading? More seriously, all of a sudden, a bunch of history-related articles, including one linked on the main page of the English Wikipedia have a broken flag icon for Nazi Germany. That isn't the only one, and in fact there are a massive number (e.g., Battle of the Bulge, Battle of the Atlantic, Battle of Kasserine Pass, et al.). Rather than plow through a gazillion WWII pages, can this be fixed more easily? Thanks!--Surv1v4l1st Talk|Contribs 06:13, 4 January 2019 (UTC)

Fixed, looks like Illegitimate Barrister broke things with a series of page moves on commons that left a double redirect where we linked the file. (as an aside, per c:Commons:File renaming#cite note-4, not sure the moves are necessary/allowed..). Galobtter (pingó mió) 06:35, 4 January 2019 (UTC)
Excellent. Thanks so much for your help. :) --Surv1v4l1st Talk|Contribs 07:22, 4 January 2019 (UTC)

Edit summary links to section titles

I did some reformatting on WP:ERRORS yesterday and some of the links to the section titles in the edit summaries are not working anymore. The problem occurs when a template or parser function is used to determine the correct link. The software is misinterpreting the pipe as the label of the link. See [33] for example. Is there any way to improve this? Thank you — Martin (MSGJ · talk) 09:56, 4 January 2019 (UTC)

Hello MSGJ, I am not sure that I understand correctly. The link you provided displays an awkward looking link in the edit summary, and it's not blue, but it is functional for me as are the ones before it and after. I can't parse them as "not working". What am I failing to grasp? Thank you.--John Cline (talk) 12:02, 4 January 2019 (UTC)
I'm sorry MSGJ, They're not working. The are allowing pop-ups to display a preview of the linked section, and the pop-up link works, but as you stated: the link itself is not working.--John Cline (talk) 12:09, 4 January 2019 (UTC)

citation and doi resolving

When I add a doi into the citation dialog in the visual editor, I frequently get the result formatted as a website and this is happening for a number of journals (I initially thought it was some metadata issue on specific journal websites). For example - 10.1080/09397140.2012.10649001 gives {{Cite web|url=https://www.tandfonline.com/action/captchaChallenge?redirectUri=%2Fdoi%2Fabs%2F10.1080%2F09397140.2012.10649001&|website=www.tandfonline.com|doi=10.1080/09397140.2012.10649001|access-date=2019-01-05}} - PS I see that the T and F are using a captcha for resolution requests... :( - when I try dx.doi.org/10.1080/09397140.2012.10649001 - it resolves perfectly. Also, have just tested this on a few other dois, it seems to be a problem only with Taylor and Francis. Shyamal (talk) 14:33, 5 January 2019 (UTC)

Well, it is also a problem with doi:10.2973/dsdp.proc.5657.114.1980 which works with dx.doi but not with Citoid. Jo-Jo Eumerus (talk, contributions) 15:27, 5 January 2019 (UTC)

Project's page shows up in search results

(Originally posted at project's page and was directed here)

I was searching on Bing.com for something, and one of the search results was the Mistagged articles cleanup page. I thought the backstage wiki pages were not indexed for search (or something like that). Maybe there's a tag or something missing on that one? Schazjmd (talk) 16:12, 5 January 2019 (UTC)

The Wikipedia namespace is indexed by default. Some of the pages are noindexed with __NOINDEX__ or in https://en.wikipedia.org/robots.txt. See more at Wikipedia:Controlling search engine indexing. PrimeHunter (talk) 16:54, 5 January 2019 (UTC)
I added noindex to that page since it contains article titles but isn't useful for readers. — xaosflux Talk 17:35, 5 January 2019 (UTC)
We shouldn't noindex pages which are useful to editors unless we are trying to achieve some other goal. --Izno (talk) 18:00, 5 January 2019 (UTC)

Appearance of my watchlist

Hi,

In the front of my watchlist I read "Changes to pages you haven't visited since the changes occurred are in bold, with solid markers". Something is apparently wrong. The pages, which I have not visited since the changes occurred, are well with solid markers, but are not in bold.

My watchlist appears well as mentioned on the other wikipedia sites (commons, fr, nl & de). Is this wrong appearance on the English site coming from the manner that my computer is downloading the watchlist?

Thanks in advance for your advice. --Réginald alias Meneerke bloem (To reply) 10:15, 3 January 2019 (UTC)

Is "Display pages on your watchlist that have changed since your last visit in bold" disabled at Special:Preferences#mw-prefsection-gadgets? Have you changed the default interface language "en - English" at Special:Preferences? If you have chosen en-gb or en-ca then it often causes problems and the top of preferences should display a warning about it. It sounds like you see MediaWiki:Rcfilters-watchlist-showupdated/en-gb instead of MediaWiki:Rcfilters-watchlist-showupdated. PrimeHunter (talk) 12:48, 3 January 2019 (UTC)
Thank you. I have corrected these two items and the "Changes to pages you haven't visited since the changes occurred" are indeed now in bold. --Réginald alias Meneerke bloem (To reply) 12:06, 4 January 2019 (UTC)

single word link template

I would like to see a single word link template {{sglw}} comparable to the single template {{sgl}}

It would be very useful for two word links where the first word is the title of a disambiguation page. For example, "He was a [[Dominican]] priest" is bad because it points to a disambiguation page. So we need to use "He was a [[Dominican Order|Dominican]]" instead. This occurs a lot when resolving links to disambiguation pages. A pipe trick is helpful to remove the parenthetical qualifier in a disambiguated qualifier, but that doesn't work if the second word is not in parentheses. This could be solved with a single word link template, e.g., "He was a {{sglw|Dominican Order}} priest". Coastside (talk) 04:53, 6 January 2019 (UTC)

It would make the source harder to read for editors and tools, e.g. when searching for wikilinks. I don't like {{sgl}} either. Ahecht made it in response to #making plural links singular. PrimeHunter (talk) 10:30, 6 January 2019 (UTC)
I didn't realize Ahecht made {{sgl}} specifically for that reason. Because of the concerns you raise about being hard to read for editors and tools, I kind of think maybe it's not such a good idea. I will probably change the few links I made that way using {{sgl}}.Coastside (talk) 16:43, 6 January 2019 (UTC)
Why not just link to Dominican priest and make that a redirect to Dominican Order? Redirects are cheap and usually resolve such problems. ϢereSpielChequers 11:40, 6 January 2019 (UTC)
Better still, make the redirect to the relevant section in the article. You also have the advantage that if the redirect is subsequently expanded into an article it already has incoming links. ϢereSpielChequers 11:46, 6 January 2019 (UTC)
And add a {{short description}} for good measure. · · · Peter Southwood (talk): 12:14, 6 January 2019 (UTC)
Why exactly do you not like [[Christians|Christian]] and [[Dominican Order|Dominican]]? If the problem is the typing and/or discovering that the pages with the shorter titles are actually disambiguation pages, I've made a Smart Linking tool for that (that almost no one is using and so I'm not maintaining either). --V111P (talk) 19:42, 6 January 2019 (UTC)

Download required

Should I mark in web cite that pdf requires download in order to open it? How I can achieve this? How I can provide navigation on the folders and files and that zip archive need to be unpacked? Eurohunter (talk) 22:36, 24 December 2018 (UTC)

The point of a citation is to identify the source where you found information. That does not usually require detailed instructions. --Izno (talk) 23:42, 24 December 2018 (UTC)
@Izno: Link instantly gives you option to download zip file and nothing more. Should I use header as a title directly from expected file? There should be instruction in which file information is included. Eurohunter (talk) 23:50, 24 December 2018 (UTC)
Example link would be helpful.
What I would do: point citation url to a web (directory) page from where the document (file) can be downloaded (if it's possible; use at/others citation field to point a location of specific file and cited pages), or to direct link of a file (if there's no page/directory). If it's an archive (with more than one subdirectory), give an inside path to a file (with ex. page number) in at/others.
If you wondering (only) what to put in title, use title from the pdf. --MarMi wiki (talk) 00:04, 25 December 2018 (UTC)
@MarMi wiki: [34] You need to unpack it and then get to the folder basshunter_bio and basshunter_2014.pdf file. Eurohunter (talk) 00:08, 25 December 2018 (UTC)
I would do it something like this: url=http://www.extensivelab.com/press/, title=Basshunter: Bio (or title/header from inside the pdf), at=(Basshunter: Bio - if title/header is from the pdf) (in )directory/file.pdf(, pp. pages - if needed) --MarMi wiki (talk) 00:25, 25 December 2018 (UTC)
Is it just my small screen resolution, or their main page (http://www.extensivelab.com/) have no links? --MarMi wiki (talk) 00:28, 25 December 2018 (UTC)
@MarMi wiki: Main page has no links. Eurohunter (talk) 00:32, 25 December 2018 (UTC)
That's a bad web design (or subpages aren't meant for public use). And I don't think it's their official site (or at least not anymore - [35]). --MarMi wiki (talk) 00:52, 25 December 2018 (UTC)
@MarMi wiki: It's their site for press. It is linked from extensivemusic.com or somewhere on their social media pages. Eurohunter (talk) 08:07, 25 December 2018 (UTC)
Google search doesn't show that (search inurl:extensivelab - no site links to that domain, at least by direct links indexed by google). --MarMi wiki (talk) 23:57, 25 December 2018 (UTC)
Woooooaaaahhh. In no way, ever, should we be requiring a user to unpack an unknown ZIP file to read a citation. I've removed it, an alternative will need to be found. Black Kite (talk) 00:14, 25 December 2018 (UTC)
@Black Kite: We are talking about Extensive Music official site. Link to archived version (Wayback Machine) may be added. Eurohunter (talk) 00:19, 25 December 2018 (UTC)
Doesn't matter where it comes from, you can't link to a ZIP file. There is surely a citation for that sentence that isn't in that format, somewhere - archive version or elsewhere. Black Kite (talk) 00:42, 25 December 2018 (UTC)
Archived version gives you the same instant link to download but from Wayback Machine. Eurohunter (talk) 00:52, 25 December 2018 (UTC)
@Black Kite: Problem is that it may be the only (primary) source with date. Other search results doesn't contain a date (ex. [36]) or doesn't look trustworthy (ex. blog posts). --MarMi wiki (talk) 23:57, 25 December 2018 (UTC)
@MarMi wiki: What date you mean? I see you found it. I'm going to add it to article (Tendence Trend Management it's artist management & booking company). Eurohunter (talk) 12:14, 26 December 2018 (UTC)
"According to 2014 Extensive Music label figures,[citation needed] more than six million Basshunter records have been sold." Link gives info about 6 mil, but doesn't give the date it was achieved. Or that it was Extensive Music.
@MarMi wiki: True. Maybe I will add file to download in the same ref as supporting source with description that there is avaiable information about that it's Extensive Music data and it comes from 2014? Eurohunter (talk) 20:58, 26 December 2018 (UTC)
@MarMi wiki: @Xaosflux: @Redrose64: @TheDJ: @Black Kite: @Izno: I could add the custom description about file download to the "file", "id" or other parameter which I don't know about. Eurohunter (talk) 21:36, 28 December 2018 (UTC)
I think that giving the url in citation to the page instead of zip should be enough (with eventual direct link in other field). --MarMi wiki (talk) 19:00, 29 December 2018 (UTC)
@MarMi wiki: @Xaosflux: @Redrose64: @TheDJ: @Black Kite: @Izno: I added description to id parameter. "Originally uploaded to Extensive Lab. Zip file download required to verify a year and origin of figures (direct link). Diectory: basshunter_bio. File: basshunter_2014.pdf." Eurohunter (talk) 11:17, 1 January 2019 (UTC)
I can add archived link yet by direct link bracket "archived file download". Is it needed? Eurohunter (talk) 11:21, 1 January 2019 (UTC)
I think it's not needed if you make sure that the file is archived on archive.org/web. --MarMi wiki (talk) 23:10, 6 January 2019 (UTC)
@Black Kite: regarding, "In no way, ever, should we be requiring a user to unpack an unknown ZIP file to read a citation." - well why not? If that is the only place the source exists, so be it. We also "require" readers to go to library, buy database access, or visit the newspaper archive to read certain citations, it doesn't make them any less reliable. — xaosflux Talk 13:57, 26 December 2018 (UTC)

“you can't link to a ZIP file” I dont see why not. Did you know that word documents are also zip files? —TheDJ (talkcontribs) 10:19, 25 December 2018 (UTC)

Word documents with the .docx extension are indeed zipped, but this is kinda transparent: Word opens the document without the need for an external utility, and the user does not take any actions that are different or extra compared to those taken when opening a normal .doc file. There are two significant things about true .zip files as compared to .docx files: (i) an extra utility (such as PKUNZIP, WinZip, 7-Zip - others are available) is necessary to extract and inflate (decompress) the file before it may be opened; (ii) it's not a compressed file as such, but a compressed archive - a single .zip file may contain one or more actual files (or just part of one), so there needs to be some means for selecting which file is to be extracted from the archive. --Redrose64 🌹 (talk) 01:47, 26 December 2018 (UTC)
Windows centered but: 1. Word IS an extra/external utility (unless you meant WordPad/Write or equivalent in newer Windows) and 2. old zip (NOT zipx) in Windows is treated as normal directory (you can also extract all files if you want). (I'm not using Win 10+ so this may be wrong) Providing a filename with path should suffice in that case.
I agree that direct linking to a file should be avoided if possible (unless it's an addition to a link - for user convenience). --MarMi wiki (talk) 02:28, 26 December 2018 (UTC)

Narrow window talk page icon bug

When on my phone, I generally prefer editing in desktop mode, but due to the narrow window, you get the icons at the top, not the text tabs "article", "talk page", "edit this page" etc. This is mostly a good thing, and I've got used to the drop-down menus for most items. I also only just realised that this change from text tabs to icons also occurs when using any actual desktop browser, when you make the window narrow.

There is a bug in the icons, however, that if you click on the talk page icon, there is no article page icon to get back to the article page. In normal width mode, the text tabs "article", "talk page" and "edit this page" remain visible on both mainspace and talk pages, but in narrow window mode, there is only the "talk page" and "edit this page" icons visible. Hence once you click on the talk page, you can't get back to the mainpage without using your phone's back button (or turning your phone into landscape mode to switch to widescreen text tab mode).

Please change the narrow window icon display settings to show the "talk" and "edit" link icons when in mainspace, but the "article" and "edit" link icons when in talkspace. Add the less useful "article" or "talk" icons to the "more" dropdown menu when you are already on those pages. The-Pope (talk) 14:04, 7 January 2019 (UTC)

The feature with icons instead of text tabs in narrow windows only appears when you select MonoBook at Special:Preferences#mw-prefsection-rendering. The feature can be disabled at "Enable responsive MonoBook design" (option only appears in MonoBook). I can reproduce your problem when the feature is enabled. A page icon to go to the non-talk page appears very briefly when the page is loading. PrimeHunter (talk) 14:51, 7 January 2019 (UTC)
This is phab:T211378. --Izno (talk) 16:07, 7 January 2019 (UTC)

18:29, 7 January 2019 (UTC)

Structured Data - file captions coming this week (January 2019)

My apologies if this is a duplicate message for you, it is being sent to multiple lists which you may be signed up for.

Hi all, following up on last month's announcement...

Multilingual file captions will be released this week, on either Wednesday, 9 January or Thursday, 10 January 2019. Captions are a feature to add short, translatable descriptions to files. Here's some links you might want to look follow before the release, if you haven't already:

  1. Read over the help page for using captions - I wrote the page on mediawiki.org because captions are available for any MediaWiki user, feel free to host/modify a copy of the page here on Commons.
  2. Test out using captions on Beta Commons.
  3. Leave feedback about the test on the captions test talk page, if you have anything you'd like to say prior to release.

Additionally, there will be an IRC office hour on Thursday, 10 January with the Structured Data team to talk about file captions, as well as anything else the community may be interested in. Date/time conversion, as well as a link to join, are on Meta.

Thanks for your time, I look forward to seeing those who can make it to the IRC office hour on Thursday. -- Keegan (WMF) (talk) 21:09, 7 January 2019 (UTC)

Captions in January

The previous message from today says captions will be released in November in the text. January is the correct month. My apologies for the potential confusion. -- Keegan (WMF) (talk) 20:43, 7 January 2019 (UTC)
@Keegan (WMF): The mentioned "previous message" was not sent to this page. It was sent to meta:Global message delivery/Targets/Structured Commons focus group, for example here. The correction should have been sent to the same group but was instead sent to meta:Global message delivery/Targets/Structured Data on Commons which includes this page. The message in the following section was sent to the latter group. PrimeHunter (talk) 22:47, 7 January 2019 (UTC)

Articles added/removed from categories don't show up on watchlist anymore

So, my problem is that when I have a category page on my watchlist, following markings either don't ever show up at all or they show up with a few days of delay:

Category:X; 11:05 . . ‎User1 (talk | contribs)‎ (ArticleA removed from category)
Category:Y; 11:04 . . User2 (talk | contribs)‎ (ArticleB added to category)

My watchlist settings' "Hide categorization of pages" is not on. This feature has been very useful to me for a long time, but now it hasn't worked properly for a month or so. --Kliituu (talk) 19:06, 7 January 2019 (UTC)

I notice the same bug occur in every wiki.--3knolls (talk) 10:22, 8 January 2019 (UTC)
@3knolls and Kliituu: See T212432. –Ammarpad (talk) 10:27, 8 January 2019 (UTC)

reFill is looking for a maintainer

As you may have noticed, the reFill tool that I created has not been maintained for a while, and the unfixed bugs have led to many faulty edits that have wasted the time of people around here. There are several key problems with the current tool:

  1. An old PHP codebase with a regex-based wikitext parser, the source of many problems reported
  2. The lack of a feedback system built into the tool that will facilitate reporting bad suggested changes
  3. The absence of a maintainer that will improve the tool and help resolve issues when I'm away

For #1, there was effort to make a complete rewrite of the tool in Python, with APIs that may be used by other tools and bots. Unfortunately it was not sufficiently publicized, and few people have tested this version. I believe effort should be spent on continuing this work, bring it in parity with the current tool in terms of functionality, possibly incorporating #2.

For #3, I'm looking for a maintainer that will help fix issues reported by the community, and assist in developing the tool. As mentioned, I believe more time should be spent on developing the rewrite in #1, which will provide the community with a more stable and maintainable tool in the long term.

Last but not least, I would like to apologize for my disappearance. I left Wikipedia a year ago due to personal reasons, and I realize my lack of communication was deeply irresponsible on my part. I eventually got over my issues, but coming back has become increasingly difficult after a long hiatus. I'd like to thank User:Smuckola who pinged me on IRC and helped me make up my mind to come here and post this. Zhaofeng Li talk (Please {{Ping}} when replying) 03:21, 8 January 2019 (UTC)

@Zhaofeng Li: Z is a model Wikipedian with a long history of providing reliable engineering and support, which has overall saved far more time and effort than not. This project is a successful community pillar. Hopefully this can be somehow unified with VisualEditor, Citoid, and the WikiCite project to become everything for everyone. Whatever we use, nothing is perfect so it's on each of us to preview our work! — Smuckola(talk) 11:09, 8 January 2019 (UTC)

Full template expansion for debugging

I was recently trying to track down some weirdness with a particular template's behavior. I eventually figured it out, but it would have been a lot easier if I could have just seen the ultimate markup that would have been produced once all templates and #invokes and such were processed, and I mean recursively here. Are there any tools that can help with this? Thanks, –Deacon Vorbis (carbon • videos) 16:09, 8 January 2019 (UTC)

@Deacon Vorbis: have you tried Special:ExpandTemplates? — xaosflux Talk 16:38, 8 January 2019 (UTC)
That seems to be exactly what I was looking for, thanks! –Deacon Vorbis (carbon • videos) 16:40, 8 January 2019 (UTC)

Replacing coordinates

I would like to know the method in AWB by which I can replace the values of latd and longd to the current format of coord.Adithyak1997 (talk) 15:42, 8 January 2019 (UTC)

It depends on where the latd and longd appear. Can you please link to articles that you would like to convert? The Wikipedia:Coordinates in infoboxes project converted coordinates in infoboxes in about one million pages. Did we miss some? – Jonesey95 (talk) 20:20, 8 January 2019 (UTC)

Page view stats per country?

The Page View Stats API includes "Get pageviews by country" (under "Pageviews data"). This works at the project level (eg. show all from Canada reading Enwiki). However there is no apparent way to get country data at a more granular level (eg. show all from Canada reading the pop music article). Is there a way to get country-specific data on a per article basis? -- GreenC 14:40, 8 January 2019 (UTC)

@GreenC: For privacy reasons this is not publicly available. It may seem silly since we're only reporting the country, but it is what it is. Say there is only one editor to the page, and only one country reported in the pageviews. Now you know what country they're located in. MusikAnimal talk 18:48, 8 January 2019 (UTC)
@MusikAnimal: OK, thank you. -- GreenC 19:01, 8 January 2019 (UTC)
I wonder if that's a real good reason though. We have a similar rationale for pages with fewer than 30 watchers, but you could just as easily (for low-visit pages) say "results unavailable due to privacy reasons". --Izno (talk) 19:36, 8 January 2019 (UTC)
Yeah, I agree there could be some logic to not expose country data if there's only so many pageviews to begin with, etc. I'm pretty sure it's a no-go, though. For privacy reasons, the current project-level country pageviews doesn't even give you exact numbers, rather they are ranges like "Spain: 5,000 - 10,000 pageviews".

There are probably also storage concerns. The normal pageviews API is quite large as it is, then you add in slots for the major countries (perhaps up to all 190+), times the number of articles, possibly for each platform (desktop/mobile) and agent (user/bot), and finally for each project. That's huge!

I didn't find a task for per-article country views on Phabricator, if you wanted to create one. Maybe the Analytics team could find a happy medium. MusikAnimal talk 20:27, 8 January 2019 (UTC)

I'll try, thanks! -- GreenC 21:26, 8 January 2019 (UTC)

pipe trick's don't work in website param of citeweb template when included in references

Pipe tricks don't work in the citeweb parameter of the {{citeweb}} template when the template is included in a citation references.

This works:

{{cite web |url=http://fortune.com/big-chocolate-child-labor/|title=pipe tricks don't work in refs|website=[[Fortune (magazine)|Fortune]]|date=1 March 2016|accessdate=7 January 2019}}

"pipe tricks don't work in refs". Fortune. 1 March 2016. Retrieved 7 January 2019.

But this doesn't work (check the reference, i.e., the footnote):

<ref>{{cite web |url=http://fortune.com/big-chocolate-child-labor/|title=pipe tricks don't work in refs|website=[[Fortune (magazine)|]]|date=1 March 2016|accessdate=7 January 2019}}</ref>Check out "Fortune" in the footnote

[1]Check out "Fortune" in the footnote

Coastside (talk) 22:42, 8 January 2019 (UTC)


An ancient issue; phab:T4700 is the ticket. --Izno (talk) 22:47, 8 January 2019 (UTC)
It's nothing to do with {{cite web}}. The problem is with the <ref>...</ref> tags.. --Redrose64 🌹 (talk) 23:58, 8 January 2019 (UTC)
Yes. Compare "Fortune" with the identical wikilink in note [2]. ♦ J. Johnson (JJ) (talk) 00:30, 9 January 2019 (UTC)



References

  1. ^ "pipe tricks don't work in refs". [[Fortune (magazine)|]]. 1 March 2016. Retrieved 7 January 2019.
  2. ^ [[Fortune (magazine)|]] -- wikilink only, no template.

Why does MediaWiki insert <p>...</p> inside <blockquote>...</blockquote>?

{{IPAc-en}} wraps the whole notation in class="nowrap" and uses <wbr /> to control line breaking. I recently noticed that while

Lorem {{IPAc-en|ˈ|l|ɔːr|ə|m|_|ˈ|ɪ|p|s|əm}} ipsum

results in "Lorem /ˈlɔːrəm ˈɪpsəm/ ipsum",

<blockquote>Lorem {{IPAc-en|ˈ|l|ɔːr|ə|m|_|ˈ|ɪ|p|s|əm}} ipsum</blockquote>

results in

Lorem /ˈlɔːrəm ˈɪpsəm/ ipsum

Apparently MediaWiki automatically inserts <p>...</p> inside <blockquote>...</blockquote>, which generates these line breaks. Is this an intended behavior on MediaWiki's part? Nardog (talk) 12:07, 2 January 2019 (UTC)

Probably some weird exception in the mediawiki parser. The parsoid parser does it correctly. Regardless, the use of nowrap is terrible in many situations and should be avoided. I think we should consider replacing it with display:inline-block instead of nowrap. That actually does what people want it to do (put it on its own line if it won't fit on the current line), without breaking the internal line breaking where it is needed if the block doesn't fit on a line of its own. —TheDJ (talkcontribs) 14:55, 2 January 2019 (UTC)
Apparently <p>...</p> is required in XHTML so that seems to be the reason.
@TheDJ: Can you elaborate on what you mean by "replacing it with display:inline-block instead of nowrap"? White space handling is a nightmare with IPA because ˈ ˌ / - ( etc. trigger line breaks when they shouldn't, and putting the whole notation in nowrap and appending wbr to spaces is about the best solution I know. Does display:inline-block provide a better solution to it? Nardog (talk) 15:08, 2 January 2019 (UTC)
Nardog, yes I think it does. The problem with nowrap is that is ALWAYS prevents line breaks, no matter if this breaks display in other situations. This is an issue on mobile where, because people have slapped this thing on entire phrases, it will cause half the phrase to be outside of the screenspace. Using display:inline-block however makes a phrase behave in a different way that is probably more suitable. It will render on a separate line whenever it detects that the current line doesn't have 'enough' space. This thus avoids line breaks within that phrase, up until the point where the width of that phrase is as wide as an entire line, where you DO want normal line breaking to take place, to make sure the phrase is at least visible. —TheDJ (talkcontribs) 15:22, 2 January 2019 (UTC)
@TheDJ: But, again, with ˈ ˌ / - ( etc. we don't want normal line breaking to take place. For example, in "/prəˌnʌnsiˈeɪʃən, -ˌnaʊn-/", /, ˌ, ˈ, and - all trigger a break. But we want it to break only at the space. Nardog (talk) 15:44, 2 January 2019 (UTC)
@Nardog and TheDJ: Here's the interesting thing I just discovered, though: The problem isn't that MediaWiki inserts <p>...</p>, but that it inserts two pairs of <p>...</p>, one around "Lorem" and one around "ipsum". (It's really unclear to me why it's doing it that way — there are no newlines in the generated output once the Lua module is executed, just a sh*t-ton of <span>s.) However, it only does that if there isn't already a paragraph defined. IOW, this:
<blockquote><p>Lorem {{IPAc-en|ˈ|l|ɔːr|ə|m|_|ˈ|ɪ|p|s|əm}} ipsum</p></blockquote>
produces this:

Lorem /ˈlɔːrəm ˈɪpsəm/ ipsum

(Also, second observation of weird behavior: In the "Show preview" view of the Visual Editor, Nardog's second example does not render with added line breaks.) -- FeRDNYC (talk) 11:18, 9 January 2019 (UTC)

edit summary sections are off

The edit summaries of some sections for me come up as "Example{{anchor|Example}}" as opposed to simply "Example". Any explanation as to what happened? [Username Needed] 11:25, 9 January 2019 (UTC)

Markup in section headings usually breaks links to that section. --Redrose64 🌹 (talk) 12:03, 9 January 2019 (UTC)

Pending changes accepted or not

Would anyone like to comment on what is happening here? https://en.wikipedia.org/w/index.php?title=Secondary_school&type=revision&diff=876540760&oldid=874796028

On my watch list diff, I see that an addition has been made to the list. (Say Iran-Israel-Italy) It says in bold [accepted addition]. I opt to edit the source code- and two items are missing Iran-Israel. Is this a configuation issue or a feature? --ClemRutter (talk) 10:04, 3 January 2019 (UTC)

Not sure how you did it. Open the source code of the revision and search for the items using ⌘ Command+F or Ctrl+F depending on what you're using. They're indeed there. –Ammarpad (talk) 15:24, 3 January 2019 (UTC)
Not sure how I did it either. But I went back to see- and unfortunately- my configuration will not show it still.
Here is a screen dump. It looks like a tricky one- above my pay grade. I have tried it on two computers Linux Mint 17. 3 and 18.1. (Firefox) I cannot see Iran or Israel on either. The Israel entry was edited twice in the meantime by John Cline so it must be something in my WP profile that is conflicting with the additions pending mechanism. The plot thickens? ClemRutter (talk) 21:12, 3 January 2019 (UTC)

I apologize ClemRutter, if my actions compounded the difficulty of your endeavor. I inadvertently rolled back the page's then "currently accepted version" and subsequently undid the resulting changes. Interestingly, if not for the error you'd not have mentioning me, and I'd not have this opportunity to answer your original question (I hope I am up to the task).

It appears to me that the forces of nature have conspired (for their own amusement) to choreograph some technical chicanery at our expense; tricking us by the combined effect of a truncated diff and the article's rendered output where both represent the page's "currently accepted version" (or, better yet, misrepresent it).

Upon looking closer, you'll notice that the changes, reflected in the diff, were actually added inside an HTML comment where the beginning is marked by <!--, the end by -->, and everything between is hidden except when viewing the page's source code. If that's not enough, the entire visible list is generated by the transclusion of {{List of names for secondary schools by country}}; proving that things do not always exist as they seem (at least not in this case).

I hope this has been helpful in answering your question; it was a challenge for me, and a joy. If it has not helped, follow on where confusion remains and I'll try to help further. If it has, happy editing and best regards.--John Cline (talk) 22:07, 3 January 2019 (UTC)

I am curious ClemRutter, did the comments given directly above answer your question; resolving it completely or not? In fact, I am keenly anxious to know. Thanks.--John Cline (talk) 11:49, 8 January 2019 (UTC)
Oh yes. Sorry for not saying.ClemRutter (talk) 13:59, 8 January 2019 (UTC)

@ClemRutter: The reason you got tricked is because, as John Cline says, the text being edited was commented out. Specifically, someone wrapped that entire list in an HTML comment reading:

<!-- maintained so the lists can be checked- and corrections made to the template- when done this should be deleted
IMPORTANT: if you edit the below, there will be no change to article text, you must also change the template

Since that list never was deleted, there were significant differences between the template and the source text. (Naturally, since that comment is far from sufficient to warn people off, especially given the length of the list.) I've copied the items that were added to the commented-out article source (including Iran) over to the template, rearranged a few that were out of alphabetical order, and deleted the giant commented-out list at Secondary school to avoid confusing people in the future. -- FeRDNYC (talk) 12:01, 9 January 2019 (UTC)

@ClemRutter: And all that being said, I'm now amused by the discovery that you were apparently the one who created Template:List of names for secondary schools by country in the first place (and presumably the one who wrote that comment, as well?) 😃 -- FeRDNYC (talk) 12:04, 9 January 2019 (UTC)
Yep, it was Clem. --Redrose64 🌹 (talk) 12:11, 9 January 2019 (UTC)

The totally insane URL I now get for my watchlist

I'm fine with all the updates and "improvements" made to the personal watchlist page; if I don't want to use those feature, I'm not obliged, and none of them are creating a problem. However, until these recent changes, the URL for anyone's watchlist page was https://en.wikipedia.org/wiki/Special:Watchlist. Now, the URL when I go to my watchlist is https://en.wikipedia.org/wiki/Special:Watchlist?hidepreviousrevisions=1&hidecategorization=1&limit=250&days=3&damaging__likelybad_color=c4&damaging__verylikelybad_color=c5&urlversion=2

Yeah, I've noticed this for a while. And frankly I think it's really bad practice to be putting all that information into an URL; do we really need to have the colours of the buttons in the URL? The precise level of filtering that the individual user has selected? But it's really annoying me a lot now that I'm in the process of switching computers, and updating my most frequently viewed pages. How do I get back to the original, no-frills URL? Is there a preference I can select? Risker (talk) 00:25, 2 January 2019 (UTC)

@Risker: do you also want the original, no-frills watchlist - it comes with the plain URL. (Use non-JavaScript interface / Loads Watchlist without filters search or highlighting functionality) option is preferences can turn off the frills. — xaosflux Talk 00:31, 2 January 2019 (UTC)
@Xaosflux:, thank you. While I support the additional frills in principle, I wasn't actually using any of them for anything, so I'll use the "old" style. You've made my day. Risker (talk) 00:36, 2 January 2019 (UTC)
  • I wish there was a preference called "Don't change a damn thing" that just opted out of all new features. Yeah yeah, get off my lawn... (No disrespect to the developers, I'm just an old dog.) –xenotalk 01:58, 2 January 2019 (UTC)
  • The basic Watchlist link is still Special:Watchlist and afaik always has been; if you want to link from outside Wikipedia, https://en.wikipedia.org/wiki/Special:Watchlist does exactly the same thing. When you get a long list of extra parameters in the URL's query string, that's usually a sign that you've altered one or more of the Watchlist options and clicked Show. The extra parameters will include one or more redundancies (action=submit is totally pointless) since the long-form URL has parameters for most selectable options, and options that are not specified in the long-form URL will mostly default to whatever you have set at Preferences → Watchlist. The only ones without a configurable preference are the "Namespace:" menu, and the "Invert selection" and "Associated namespace" checkboxes. So if you wanted show the last six hours of changes by people other than yourself, you can start at Special:Watchlist and append the query string ?days=0.25&hidemyself=1 which gives https://en.wikipedia.org/wiki/Special:Watchlist?days=0.25&hidemyself=1 - if you also wanted to see only edits to articles, you can append &namespace=0 to that. --Redrose64 🌹 (talk) 10:59, 2 January 2019 (UTC)
  • @Risker: Yeah, this is a tricky one. The thing is that the watchlist view now applies several filters by default, so those are all encapsulated in the query string. (At the risk of contradicting Redrose64, you don't have to have modified any of the options, because the default view is already filtered when the "enhanced" watchlist is enabled.) Even the damaging__likelybad_color=c4 and damaging__verylikelybad_color=c5 query-string components are filters (filters that happen to color their matched entries) — without those items in the query string, there's no highlighting of those items.
(That the highlight color is set in the query string is secondary — their primary purpose in appearing there is to establish the filter, so those components are indeed "needed" if that filter is to be applied. And in fact the color thing is kind of nonsense because (a) it's "magical" — c1 is blue, c2 is green, c3 is yellow, c4 is orange, c5 is red, c6 is apparently an error (not purple!), and other than the trial-and-error method I just used to discover that mapping, how would anyone possibly know?; and (b) apparently its customizability is sort of half-hearted, since if you set either filter to a non-default color, it shows two dots alongside each item — the default color followed by your configured color — indicating that the code doesn't "really" trust the user to customize the coloring.)
But the alternative to having all of those settings in the query string would be to store them in a cookie, in which case you wouldn't be able to bookmark or link differently-configured views. That's the big advantage to using query strings for customizable views, which is why it's often the preferred method for doing so. -- FeRDNYC (talk) 12:52, 9 January 2019 (UTC)

Unexplained errors in Javascript console

The Navigation Popups gadget created by Lupin is spewing tons and tons of errors on my console.Could somebody look into what is causing it ? — fr 12:15, 3 January 2019 (UTC)

 
@FR30799386: I have Navigation Popups enabled on my account, and I'm not getting those errors. So either the issue has been corrected since, or there's something unique to your environment that's causing them. -- FeRDNYC (talk) 11:24, 9 January 2019 (UTC)
I get these errors occasionally. The errors look very weird, and I haven't been able to reliably reproduce it. I will investigate further once I get them again. Enterprisey (talk!) 20:23, 9 January 2019 (UTC)

making plural links singular

For group article names, such as [[Christians]] it's unfortunate to have to use a pipe to get the singular version. For instance I have to say "He was a [[Christians|Christian]]". Going from singular to plural is easy, i.e., [[Christian]]s and it would be nice to be able to use such a shortcut in reverse. Something like [[Christian<s>]] or some such.Coastside (talk) 21:15, 4 January 2019 (UTC)

A similar request was declined at phab:T5527. PrimeHunter (talk) 21:28, 4 January 2019 (UTC)
@Coastside: See {{sgl}}. --Ahecht (TALK
PAGE
) 22:30, 4 January 2019 (UTC)
@Ahecht: I didn't realize {{sgl}} was created as a response to this request. I thought it was an established template that I didn't know about. PrimeHunter raised concerns about readability for editors and tools. Maybe we shouldn't use this? I can change the few links I created that way. Thoughts?Coastside (talk) 16:50, 6 January 2019 (UTC)
@Coastside: The template is now substable, and when substed will look idential to a traditionally-created link (similar to how the pipe trick works). I flagged the template so that any transclusions will be automatically substed by a bot. --Ahecht (TALK
PAGE
) 16:18, 7 January 2019 (UTC)
I find it less confusing to put the brackets around the name even if it is plural (e.g. I would use both [[Christian]] and [[Christians]]), and let the link redirect if necessary. Why complicate things? —Remember the dot (talk) 05:42, 8 January 2019 (UTC)
That makes sense in general. Unfortunately Christian is a disambiguation page. I think that's likely to be the case for a lot of pages on groups of people. (Whether Christians should be a page on a group of people, as opposed to say a redirect to Christianity, is a separate question.) --Trovatore (talk) 06:35, 8 January 2019 (UTC)
Good point. I should have realized that Christian is a disambiguation page and Christians is not. —Remember the dot (talk) 02:10, 10 January 2019 (UTC)

Template transclusion including partial if statements in articles

  Resolved

Can someone fix {{Mergeto}} and {{Mergefrom}}? They are including a new line and "{{#if:List of TurboGrafx-16 games||", see (e.g.) List of PC Engine games and List of TurboGrafx-16 games. Thanks. ―Justin (koavf)TCM 01:55, 10 January 2019 (UTC)

See Template talk:Merge#Broken. — JJMC89(T·C) 05:07, 10 January 2019 (UTC)

Suggestion to update Reference Tooltips gadget

 

Hello! I would like to suggest to update to the new version of this gadget I've presented at mw:Topic:Ueqlcc482l9yw8gv. There are numerous bugfixes and added features like Harvard-style citations support. Tooltip style & animations are also updated to be consistent with Page Previews' style & animations. It has been tested thoroughly, including by the author of the original script, and used in Russian Wikipedia for several months with no complaints.

Jack who built the house (talk) 13:00, 4 January 2019 (UTC)

Jack who built the house, I think that this is good to go;-) Will ask at IAN. — Preceding unsigned comment added by Winged Blades of Godric (talkcontribs) 11:29, 10 January 2019 (UTC)

Artist templates need mending

Hi, and requesting help from someone on this. Two templates, {{Evelyn De Morgan}} and {{Daniel Chester French}}, are missing their "view, discuss, edit" links at the top left. Can't figure it out, and user Another Believer suggested bringing it here. Am wondering if someone can reveal the nonexistent buttons. Thanks. Randy Kryn (talk) 14:26, 10 January 2019 (UTC)

  Done by Another Believer. Randy Kryn (talk) 14:37, 10 January 2019 (UTC)

References section in the Wikipedia's articles: adding "Show context" lable like here

Good evening, please let You look at the use of references in the IEEE website. By expanding the label "Show context", in the ending footnotes users have a preview of the paragraph(s) in which the citation is positioned.

Il would be useful if users can view the same "Show context" for the "References" section of the Wikipedia's articles.

If citation is called more times in the article by the <ref name =" " /> , the "Show context" join the multiple ranges of row line numbers where the citation it is used, limited by a fixed maxmimum leght.

Context can be visualized in:

  • an ony-text mode,
  • hypertexual mode: with the wikilinks and eventual external links. Wikilinks can also conserve the related preview, as visualized in the article.

Images and files coming from Wikimedia Commons aren't visualized in the "Show context".

Once the article is updated, the set "Show context" is dinamically synchronized to the last edit saved for the article.

Furthermore, WP editors can be enabled to associate a unique and optional parameter for the context to any given citaton template. This is waht just happens through the less used template:clarify (e.g. the clarify on it.wikipedia)- — Preceding unsigned comment added by 78.14.139.111 (talk) 22:37, 9 January 2019 (UTC)

When I go to https://ieeexplore.ieee.org/document/6248110/references#references/ I get a "References" heading, below which are a number of blank spaces each beginning with a dot. If I scroll up the page, there is a blue box saying "Sign in to Continue Reading". Not very helpful. --Redrose64 🌹 (talk) 23:27, 9 January 2019 (UTC)
Hi. I thank for your reply. I noticed this problem now, since yesterday it was not. I am connecting with a laptop, with Windows 8.0 version 64 bit, and Google Chrome. I have closed and opened again the heading "References" and the list works rightly and it is full displayed. It may be read also by non signed users. Example:
  1. Reference n.1 (the first reference): "S. Behnke. Hierarchical Neural Networks for Image Interpretation, volume 2766 of Lecture Notes in Computer Science. Springer, 2003. 1, 2".

which is followed by three links: "Show context", "Crossref", "Google Scholar".

    • the first one (named "Show context"), if expanded, is nowm displaying the string: "We focus on deep convolutional neural networks (DNN), introduced by [11], improved by [19], refined and simplified by [1], [32], [7]." Under the text there is an unique link named "Go to the text", that can be read only for signed users.
  1. Reference n 37 (the last): "D. H. Wiesel and T. N. Hubel. Receptive fields of single neurones in the cat's striate cortex. J. Physiol., 148:574-591, 1959. 2".

The related link "Show context", if expanded below, displays the following: "The approach is inspired by Hubel and Wiesel's seminal work on the eat's primary visual cortex [37], which identified orientation selective simple cells with overlapping local receptive fields and complex cells performing down-sampling-like operations [15]."

I would like to suggest an adaptation of this feature for Wikipedia's articles, that:

  • hasn't the need for users to be signed.
  • can be web archived with the list of citations (otherwise that [http://archive.is/K3fCr/ in the example).

I mean that in the section "References", readers (yet signed or not) have a link named "Show context" for each number of reference, that it can be expanded, displaying the last paragraph. One possible way to identify this paragraph is like in the IEEE website "from dot to dot":

  • starting from the first dot before the tag <ref>, that originates the citation in the article.
  • ending to the first dot after tha tag </ref> , that ends the citation in the article.

For the longest periods, it can be fixed a maximum possible lenght of four (or more) lines of text, assigned to the event named "Show context", so as to have displayed the current line where is the tag <ref> in the article, adding the previous two row lines and the following one.


Maybe this feature will be hopefully introduced in Wikipedia without the need to be signed. — Preceding unsigned comment added by 84.223.68.190 (talk) 14:42, 10 January 2019 (UTC)

Responsive data tables for mobile Wikipedia

I think that the styling for tables on mobile can use a revamp. The horizontal scroll makes it hard to read information on smaller devices. Since Wikipedia already uses a separate subdomain for mobile, why not make tables responsive? Perhaps a column collapse like this:

https://css-tricks.com/responsive-data-tables/ — Preceding unsigned comment added by LionelAsh (talkcontribs) 03:50, 11 January 2019 (UTC)

I'm trying to move Roosevelt Senior High School (Washington, D.C.) to Theodore Roosevelt High School (Washington, D.C.) (as that is the current name used on the school website) when I get:

  • "[XDg0zgpAICwAALjkrO0AAABX] 2019-01-11 06:16:46: Fatal exception of type "MWException""

I would like to report this to Phabricator, but I also want to notify you guys here so I can have assistance moving the page WhisperToMe (talk) 06:18, 11 January 2019 (UTC)

@WhisperToMe: I've moved it for you by deleting the target page first instead of using the delete when moving over an existing page functionality. I had the same issue a few times earlier but forgot to note the exception for a bug report. — JJMC89(T·C) 06:31, 11 January 2019 (UTC)

Is there a discussion about how to fix links to highbeam.com?

(Not really a technical question:) HighBeam Research appears to have shut down a couple of weeks ago, and we appear to have something like 15,000 articles that use it as a source. Does anyone here know of a WP discussion that is happening about how to resolve the suddenly dead links in all of these citations? Thanks. – Jonesey95 (talk) 02:45, 2 January 2019 (UTC)

Hey. Normally the entire domain would be marked "dead" in IABot, then whenever it comes across it, would convert to a dead link and add an archive URL. But IABot management interface is not responding well. I will contact Cyberpower678. T212753 -- GreenC 03:13, 2 January 2019 (UTC)
If they are in a cite journal or similar, purge them all. They should never have been added in the first place. Pure preference/promotion of a commercial entity. Headbomb {t · c · p · b} 03:30, 2 January 2019 (UTC)
I agree they are last resort, but sometimes they are the only things available for on-line verification purpose when they provide the first few paragraphs of the source-text for free (example). -- GreenC 03:41, 2 January 2019 (UTC)
I could see keeping them when we have no doi/bibcode/pmid/whatever, but they're equivalent to links to Amazon for books. If you've got an identifier, purge them out. And if the links are dead, they're not much point in keeping them around. They won't even be archived, since they are commercial links that block archiving. Headbomb {t · c · p · b} 00:27, 4 January 2019 (UTC)
There has been some discussion on this topic at WT:Highbeam. —AntiCompositeNumber (talk) 14:57, 3 January 2019 (UTC)
I seem to have got it working and have set a bot job for it under job 3041.
Correction, it was not working on that job, but I have managed to set the base URL to dead, I do not have the domain changer user right on IABot [Username Needed] 15:56, 11 January 2019 (UTC)

Dupe ref name check could be made smarter

Now it trips just because parameters are in different order even if their content matches... E.g.

[1] [1]

References

  1. ^ a b "aa". Cite error: The named reference "bob" was defined multiple times with different content (see the help page).

Somebody please make it smarter. Now articles get ugly errors when the only error is in the check! --Palosirkka (talk) 17:05, 11 January 2019 (UTC)

It doesn't expand templates. It compares the raw text between the <ref> and </ref> tags. You get the same thing with plain text and an extra space:[1][1]

References

  1. ^ a b cc Cite error: The named reference "kate" was defined multiple times with different content (see the help page).
You would need to file a ticket at phab: to get this changed. --Redrose64 🌹 (talk) 17:23, 11 January 2019 (UTC)

Gallery slideshow

Hello, considering the aforementoned issue, can somebody here help me along with this inquiry of mine from HD (which, unfortunately, remained unanswered)?--Hildeoc (talk) 22:55, 11 January 2019 (UTC)

Caching and slow to populate category.

About a month ago I adding some deprecated parameter tracking to {{Infobox song}} with this edit. The purpose is to populate Category:Pages using infobox song with deprecated parameters with pages using the old parameters. What I'm confused about is every few hours new pages are showing up in the category despite having no new edits. For example, Air Man ga Taosenai was just placed in the category this morning. Why is it taking SO long for the template to update these pages? Usually I've found that this happens within 24 hours or so. Am I missing something? --Zackmann (Talk to me/What I been doing) 19:03, 11 January 2019 (UTC)

The WP:Job queue has been unreliable in this respect since mid-2013, I've given up waiting for them to fix it. The thing to do is to ask Joe Decker (talk · contribs) nicely, if they wouldn't mind sending in Joe's Null Bot (talk · contribs) to process every page that transcludes {{Infobox song}}. Here's the list, it has over 63,000 entries. --Redrose64 🌹 (talk) 20:34, 11 January 2019 (UTC)
Taking a few weeks, or even a few months, is not unusual, especially for high-use templates (more than a few thousand transclusions). – Jonesey95 (talk) 21:07, 11 January 2019 (UTC)
The rendering of pages using a template is usually updated quickly in my experience. It's the link tables used elsewhere like on category pages which can be very slow. The search "Pages using infobox song with deprecated parameters" finds updated article pages, even for a hidden category like this. I currently get 826 hits. They display the category (assuming "Show hidden categories" is enabled at Special:Preferences#mw-prefsection-rendering) but Category:Pages using infobox song with deprecated parameters currently displays as empty. PrimeHunter (talk) 21:32, 11 January 2019 (UTC)
@Redrose64: Joe's Null Bot is currently down. I have also added the phab task that tracks this (below the other phab task tracked already) --DannyS712 (talk) 23:40, 11 January 2019 (UTC)

OneClickArchiver creating unwanted pages

Is there a way to disable OCA on pages such as WP:UAA, where there is no reason to "archive" the posts? It results in the creation of a new page that serves no purpose. See the log for Wikipedia:Administrator intervention against vandalism/Archive 1 for what I mean. I also saw a similar situation with WP:RFP, which the accidental clicking of "Archive" resulted in the creation of a competently unnecessary page several times. funplussmart (talk) 15:39, 12 January 2019 (UTC)

Question: extracting lists from Unused templates lists

I have just discovered this: Wikipedia:Database reports/Unused templates. Wow! I was wondering if there is any way to perform queries of the list to extract entries matching certain parameters? (eg. created before a certain year, have certain phrase or characters in the name, or have had no revisions since creation). I think that would be a useful way to filter the list to have a look more in depth at certain templates.

It goes without saying that one will need to have a closer look at the lists are generated before proposing them all for discussion / deletion (to ensure they truly aren't used in other environments such as modules, or aren't transclusionless etc.), but I think it is a useful place to start. Any ideas how I can achieve this? --Tom (LT) (talk) 01:16, 29 December 2018 (UTC)

@Tom (LT): You should look at WP:Petscan. --Izno (talk) 14:11, 29 December 2018 (UTC)
@Izno thanks --Tom (LT) (talk) 11:41, 6 January 2019 (UTC)
  Question: @Izno. PetScan is for categories. Most of the unused templates only show up on the database report so I can't actually view the categories. IF it can solve my problem (ie let me search through the database report) could you kindly show me how...? With thanks, --Tom (LT) (talk) 01:21, 13 January 2019 (UTC)
Wow, over 75,000 unused templates. It's easy to copy all the text from the first page (5000 entries) and paste that into a spreadsheet, then sort by Latest edit or First edit. I used "paste special" as text and then had to format the date columns as number with 0 decimal digits. That is enough to work on! Template:Veg-stub is on page 16 of the report. It was last edited in July 2005 but it turns out to be a redirect to Template:Vegetable-stub which is used. Getting redirects deleted can be difficult because people will argue that redirects are cheap blah blah. It would be nice to know how many of the first 5000 entries are redirects. Johnuniq (talk) 02:12, 13 January 2019 (UTC)
@Tom (LT): Petscan works on categories, templates, or other selection criteria. When you start it up, it's in the "Categories" form - but there are five other tabs along the top. These are: "Page properties"; "Templates&links"; "Other sources"; "Wikidata" and "Output". All of these (except "Output") can be used instead of "Categories" - or in combination with it. --Redrose64 🌹 (talk) 18:40, 13 January 2019 (UTC)

Hi. I have BrandonXLF's invert script here but for some reason it went away from my menu bar. --Thegooduser Life Begins With a Smile :) 🍁 21:40, 13 January 2019 (UTC)

Have you tried asking at User talk:BrandonXLF? — xaosflux Talk 21:46, 13 January 2019 (UTC)
Outside that, start looking for conflicts - remove all your imported scripts except for that one and see if it is still working. — xaosflux Talk 21:47, 13 January 2019 (UTC)
Xaosflux If I remove all my scripts how can I see which ones I have Installed? Can I rollback my edits after? --Thegooduser Life Begins With a Smile :) 🍁 21:48, 13 January 2019 (UTC)
Asked it on BrandonXLF's talk page. Thegooduser Life Begins With a Smile :) 🍁 21:56, 13 January 2019 (UTC)
@Thegooduser: certainly, your script page (User:Thegooduser/vector.js) has a history that you can revert to just like any other page. — xaosflux Talk 22:14, 13 January 2019 (UTC)
@Thegooduser: The latest version moved the link from your "p-personal" toolbar to the "p-tb" toolbar - check the tools side menu (the one with "page information," "permanent link," etc.) --DannyS712 (talk) 22:04, 13 January 2019 (UTC)

Broken links to peer review pages.

Apparently, on occasion, an article and its subpages are moved to a new title. However, peer review pages existing in project space are not captured when subpages are moved. I became aware of this while participating in the mass-move of political campaign articles to put the dates before the name of the respective campaign or election, but it is likely that it has occurred in other contexts. There are two ways to address this, those being to move all the affected peer review pages to the new titles, or to create redirects to them. Either one would require that someone compile a list of the links that are now broken. If someone makes such a list, I'll be glad to check and move the pages. Cheers! bd2412 T 17:43, 10 January 2019 (UTC)

@BD2412: most articles moves leave a redirect behind, and articles shouldn't have subpages. Can you show some examples of this problem? — xaosflux Talk 18:20, 10 January 2019 (UTC)
To be more precise, talk pages usually move with the article, and talk pages often have subpages (typically archives). The case that was brought to my attention was from my move of William McKinley presidential campaign, 1896 to William McKinley 1896 presidential campaign, pursuant to consensus for the above-referenced mass-move of political campaign articles. It was later brought to my attention that this resulted in a broken link on the talk page of that article to Wikipedia:Peer review/William McKinley presidential campaign, 1896/archive1, which I thereafter moved to Wikipedia:Peer review/William McKinley 1896 presidential campaign/archive1. It is likely that there are other subpages of Wikipedia:Peer review that have become untethered due to page moves, since these are not in a space that is carried along with the page move. bd2412 T 18:32, 10 January 2019 (UTC)
Simplez, use an ifexist in {{Old peer review}} to categorize talk pages with nonexistant links. Galobtter (pingó mió) 18:40, 10 January 2019 (UTC)
If someone who knows how to do that would create the category, I can do the rest. Cheers! bd2412 T 19:24, 10 January 2019 (UTC)
I have added ifexist code [41] and created Category:Pages using Template:Old peer review with broken archive link. It will take time for the job queue to automatically populate the category. PrimeHunter (talk) 22:06, 10 January 2019 (UTC)
Thanks, this works. I will keep an eye on it. bd2412 T 22:27, 10 January 2019 (UTC)
@BD2412, PrimeHunter, and Galobtter: How about pages that use {{article history}} to display peer reviews but not the {{Old peer review}} template, like Talk:Charles Boycott? (Not that the link there is broken ... just using it as an example. Graham87 10:30, 11 January 2019 (UTC)
Graham87, {{article history}} does not automatically generate the link as {{old peer review}} does (you have to specify the link as e.g |action1link=Wikipedia:Peer review/Charles Boycott/archive1}}), so links don't break. Galobtter (pingó mió) 10:34, 11 January 2019 (UTC)
@Galobtter: Oh of course, oops! Graham87 11:45, 11 January 2019 (UTC)
Note that this has generated a list of 642 errors, which is a bit bigger of a task than anticipated. In other words, a technical solution may be required to fix these. bd2412 T 13:40, 11 January 2019 (UTC)
You could ask for bot help at Wikipedia:Bot requests, or manual help at Wikipedia talk:Peer review. I'm not a bot coder. The best I could do is modify {{Old peer review}} to check a list of exceptions if the normal link would be red. A list entry in a big switch could look like this: |William McKinley 1896 presidential campaign = Wikipedia:Peer review/William McKinley presidential campaign, 1896/archive1. Peer reviews can be in other places like Wikipedia:WikiProject Military history/Peer review/Murray Bourchier so we shouldn't assume a subpage of Wikipedia:Peer review. The list would still have to be compiled somehow but it might be easier than editing each talk page, or make moves or redirects. If somebody makes a script to compile a list then it wouldn't require bot approval like solutions which make 642 edits. PrimeHunter (talk) 19:04, 11 January 2019 (UTC)
Can someone make a list of the untethered peer review pages that correspond to the ~640 (I fixed a few) broken links? bd2412 T 22:22, 13 January 2019 (UTC)

Help with modules

I noticed that a lot of templates on Wikipedia use modules/Lua/Scribunto. I know modules can do almost the same things as templates. However, I was wondering if I can set two arguments to do the same thing. For example, with {{Infobox film}}, I can use both "film-name" and "film name" arguments. They do the same exact thing (in the template's code is "| data1 = {{{film_name|{{{film name|}}}}}}"). Now, say the template was converted to Lua — how would it be written? —CaiusSPQR (talk) 23:22, 13 January 2019 (UTC)

That assignment might be written:
local data1 = frame.args['film_name'] or frame.args['film name']
Perhaps read WP:LUA.
Trappist the monk (talk) 00:17, 14 January 2019 (UTC)
Thank you. I'm a bit confused though. Should I use "data1" or both "frame.args" in the rest of the code? —CaiusSPQR (talk) 00:23, 14 January 2019 (UTC)
Were it me, I would use data if I needed to use that value more than once so that every time I needed the value assigned to |film_name= or |film name= I didn't have to do the 'or'ing every time.
Trappist the monk (talk) 00:32, 14 January 2019 (UTC)
Thank you so much for your help! 😁 —CaiusSPQR (talk) 00:34, 14 January 2019 (UTC)
Some lua tips:
Depending on what you want to do, you can also use a template wrapper for parameter conversion: {{#invoke|...|data1={{{film_name|{{{film name|}}}}}}|...}}.
frame.args['film_name'] can be shortened to frame.args.film_name (table).
Lua treats empty parameters ("" or spaces) differently than template: Module:Arguments#Trimming and removing blanks. MarMi wiki (talk) 02:09, 14 January 2019 (UTC)

Category tree trace tool

Is there any tool which can help me understand why a specific article is in a specific category tree? For example, what is the root from Category:Mammals to Phronima? עוד מישהו Od Mishehu 12:20, 13 January 2019 (UTC)

I think that Pintoch (talk · contribs) was working on something like this. --Redrose64 🌹 (talk) 18:42, 13 January 2019 (UTC)
@Od Mishehu and Redrose64: There is vCat (but it's not my tool). − Pintoch (talk) 08:25, 14 January 2019 (UTC)

FileExporter beta feature

Johanna Strodt (WMDE) 09:41, 14 January 2019 (UTC)

Cannot log on through TOR

I have Wikipedia:IP block exemption. Today I attempted to log on through the Tor browser and got this error:

There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Please resubmit the form.

Resubmitting gives the same error. Clearing browsing/download/form/search history, site preferences, offline website data, active logins, cookies and cache and then restarting the computer didn't help. Trying to log on to several other WMF projects didn't help.

Previously I could log on through TOR, and I can still log on normally with Firefox through my normal ISP.

Has something changed?

I searched for "precaution against session hijacking"[42], read every thread, and tried everything anyone suggested. Nothing worked.

Note: I have IP block exemption because I often am at a remote site in China where industrial espionage is a real problem (I do consulting work in the toy industry) and my US employer requires that when in China I access the Internet through Tails and Tor. There is a lot of waiting around at the remote site so I have plenty of time to edit Wikipedia -- if I can log on. --Guy Macon (talk) 18:25, 12 January 2019 (UTC)

@Guy Macon: this seems to be related to phab:T151770 - can you try connecting with Tor, but using a different browser? — xaosflux Talk 20:48, 12 January 2019 (UTC)
As far as I know you need to use the Tor browser (Firefox based) to access Tor, so simply using a different browser won't work. I will give the suggested change to Firefox configuration in the phab a try and get back to you.. --Guy Macon (talk) 06:06, 13 January 2019 (UTC)
Nope. Made the change, cleared everything and restarted, still getting the error message. :( --Guy Macon (talk) 06:55, 13 January 2019 (UTC)
Since we are at the desperate stage, are you logged on somewhere? For example, if you had logged on as normal without Tor because you were in a safe location, did you log off there before trying the Tor logon? Perhaps you did not have to in the past, but if convenient it would be worth testing. Johnuniq (talk) 08:32, 13 January 2019 (UTC)
Good suggestion. I am indeed logged on normally. I occasionally fire up my Tor browser and do some small bit of noncontroversial typo fixing just so I know it will work the next time I get a call to go to China and fix a production problem. It doesn't seem like that should matter, but it is easy enough to test. I will get back to you after trying that. --Guy Macon (talk) 16:09, 13 January 2019 (UTC)
This could be due to attempted https inspection (interception) where the session has some sort of invalid certificate inserted that is rejected by the browser. Graeme Bartlett (talk) 05:44, 13 January 2019 (UTC)
I am pretty sure that it is a Wikipedia error message, not a browser error message. It is in the HTML that Wikipedia sends:
 <div class="error"><p>There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Please resubmit the form.</p></div>
I also changed my Tor Exit not to one on another continent. Didn't help. Tor is completely encrypted from the Tor Browser on my PC to the exit node, so if something is inserted it would have to be between the exit node and Wikipedia. The fact that is still happens when I change exit nodes would imply that someone is intercepting everything that goes to and from Wikipedia. The simpler explanation is that Wikipedia is cancelling my login and sending me the above error message. --Guy Macon (talk) 06:06, 13 January 2019 (UTC)
The above message is from MediaWiki:Sessionfailure. –Ammarpad (talk) 06:42, 13 January 2019 (UTC)
Thanks! I thought that it was one of our error messages. That Wikilink was to a page that was deleted ten years ago. Did you mean [ https://www.mediawiki.org/wiki/Manual:$wgReadOnly ]? --Guy Macon (talk) 16:16, 13 January 2019 (UTC)
Guy Macon, the page Ammarpad linked is still a MediaWiki message despite being deleted - mediawiki messages have defaults and a page is only necessary when changing that default. Galobtter (pingó mió) 16:40, 13 January 2019 (UTC)
(edit conflict) MediaWiki:Sessionfailure sounds right. It displays the exact message you quoted. Messages in the MediaWiki namespace have a default value which is used if a wiki has not created or has deleted the corresponding page. The link is blue, indicating the message name is known to MediaWiki even though there is no wiki page. PrimeHunter (talk) 16:42, 13 January 2019 (UTC)
@Guy Macon: I get exactly the same uninformative message when I try to log on with cookies disabled. Could your browser or Tor client could be blocking cookies from wikipedia.org for some reason? Suffusion of Yellow (talk) 22:23, 13 January 2019 (UTC)
...aaand it logged in just fine after I told it to accept cookies from wikipedia.org and wikimedia.org. Thanks! I can't help but wonder, though, what changed. I test this once a month or so so and last month I was able to log in even though I wasn't accepting cookies.
OK, my problem is solved, but what can we do to help others? How about a help page that tells the user about the cookies, suggests clearing the cache, etc. rather than an uninformative "Please resubmit the form" error message? Who do we talk to to get a better error message? --Guy Macon (talk) 22:46, 13 January 2019 (UTC)
A local version of MediaWiki:Sessionfailure can be created and edited by administrators. It could link Help:Logging in. PrimeHunter (talk) 22:59, 13 January 2019 (UTC)
I asked for help at AN.[43] --Guy Macon (talk) 23:11, 13 January 2019 (UTC)
@Guy Macon: I'm assuming your logon failure isn't limited to the English Wikipedia? If so I suggest you open a phab ticket. — xaosflux Talk 12:26, 14 January 2019 (UTC)
When I found that I suddenly could not log on to the English Wikipedia, I tried the french, Wiktionary, Meta, and half a dozen others -- no luck. When I enabled cookies on Wikipedia, I was able to log on, and the unified login logged me on to all of the other projects, even ones that still have cookies blocked. So yes, it appears to be project wide. This implies that as a bare minimum we should fix the help page for all languages and all WMF wikis. There is also a strong argument for fixing the underlying problem instead of simply making the error message suggest turning on cookies; first, anyone using Tor is especially likely to turn off cookies, block trackers, etc. Second, it isn't only the WMF that uses our software. A bunch of independent wikis use it as well. Sites like Brickepedia use our software but do not have our error pages unless they come "baked in" with the software. Third, it isn't our business to force the users to accept cookies, and indeed other than logging on, Wikipedia works just fine with cookies disabled. --Guy Macon (talk) 16:56, 14 January 2019 (UTC)
@Guy Macon: thanks for the update, just making sure we captured everything:
  1. You are able to logon and edit via TOR now
  2. The primary technical issue was that you were blocking cookies, and allowing the authentication cookies resolved this for you
  3. Updating our interface message (and further the mediawiki default) for MediaWiki:Sessionfailure to include information about cookies may be useful.
Thanks for your patience as well! — xaosflux Talk 17:04, 14 January 2019 (UTC)
That appears to cover it. --Guy Macon (talk) 17:25, 14 January 2019 (UTC)
@Guy Macon: thanks for the update, I've updated our local message to reference cookie handling, and have requested a core update in phab:T213763 - coincidentally 10 years to the date after phab:T19029 was opened for Session failure warning message ('sessionfailure') gives bad advice. — xaosflux Talk 22:00, 14 January 2019 (UTC)
@Trizek (WMF): I think this edition got truncated. Graham87 04:13, 15 January 2019 (UTC)
@Graham87: yes it was (meta:). You can read the entire issue here: meta:Tech/News/2019/03. — xaosflux Talk 04:55, 15 January 2019 (UTC)
@Graham87:, yeah, I'm very sorry about that. I've fixed it above. Trizek (WMF) (talk) 13:45, 15 January 2019 (UTC)

List of Wikipedians by article count

I know I've raised this before, but does anyone have the time and skills to be able to fix this list so it updates automatically each day, as per the number of edits list? Many thanks. Lugnuts Fire Walk with Me 09:07, 15 January 2019 (UTC)

@Lugnuts: that really needs to be done by a bot, it looks like it used to be done by MZMcBride's bot - so you could start by asking MZMcBride. Alternatively, someone else could take it up, and you could ask at WP:BOTREQ. — xaosflux Talk 13:50, 15 January 2019 (UTC)
Thank you. IIRC, I've asked MZMcBride before about this, and I think there was something technical stopping it from being updated. I'll do a bit of digging, and see what I find. Lugnuts Fire Walk with Me 13:58, 15 January 2019 (UTC)

AFD transclusion

Bit of an odd situation I wanted to see if somebody on the technical side could look into. Earlier today, User:Cyberbot I detected Wikipedia:Articles for deletion/John Dingfelder as "not correctly transcluded to the log", and added it to today's AFD list accordingly — but the page is, and always has been, correctly transcluded to the daylog for the day it was created, January 9 (and there's no indication in the edit history of that page that it got temporarily vandalized, the only explanation I can think of for why a discussion on it might appear untranscluded six days later.) And it's not a case of the discussion having been relisted for further consideration without getting readded to the new daylog, either, as January 9 isn't seven days ago yet and the discussion's already on a consensus track and won't even need to be relisted at all.

So could somebody take a few minutes to look into why a bot might make this mistake? Thanks. Bearcat (talk) 16:25, 15 January 2019 (UTC)

Black box appearing

Hello,

Today I have logged onto Wikipedia and there seems to be a solid black box on the articles box and what activity I am doing. For example: This page right now will have a black box around "Article" and a black box around "Edit source". Another example would be if I was on a random page and there would be a black box around "Article" and a black box around "Read".

Thank you AmericanAir88(talk) 22:59, 14 January 2019 (UTC)

What is your browser? What is your skin at Special:Preferences#mw-prefsection-rendering. Does it happen if you log out? PrimeHunter (talk) 23:10, 14 January 2019 (UTC)
@PrimeHunter: It happens when I log out. I use safari. I use the default skin. AmericanAir88(talk) 23:45, 14 January 2019 (UTC)
Is it on a computer or iOS device? Safari dropped the Windows version in 2012 so I cannot test it on a computer. I don't see it on an iPad. It sometimes helps with interface rendering to clear the entire cache. PrimeHunter (talk) 00:01, 15 January 2019 (UTC)
@PrimeHunter: Clearing the cache did not work. This is on a MacBook Air. AmericanAir88(talk) 00:39, 15 January 2019 (UTC)
MacBook Air uses macOS and not iOS so I cannot help properly. PrimeHunter (talk) 00:47, 15 January 2019 (UTC)
@PrimeHunter: Is there someone I can speak to who has expertise in MacOs? AmericanAir88(talk) 02:50, 15 January 2019 (UTC)
Using Safari on MacBook Air and everything appears normal to me, logged-in and out. –Ammarpad (talk) 07:52, 15 January 2019 (UTC)
I don't see any changes, either, AmericanAir88. Have you tried restarting? After that, as today's not Thursday, I'd look at updates (Safari, OS X, or a Safari extension) and new extensions, and double-check that I hadn't changed any preferences. BlackcurrantTea (talk) 16:58, 15 January 2019 (UTC)

Special:Block

 

I note that the blocking form has changed in this week's update, though I'm not entirely sure why or how it's an improvement. What would be useful though, is the form actually being at the top of the page, so you can fill it in without having to scroll down? A trivial thing, I know, but it all looks a bit amateur, and has done for a while. Black Kite (talk) 15:36, 11 January 2019 (UTC)

@Black Kite: you should be getting a bunch of text in that large empty space at the top (this isn't new) - are you blocking scripts or perhaps set your interface language to some English variant? — xaosflux Talk 15:39, 11 January 2019 (UTC)
The text you should see is MediaWiki:Blockiptext. — xaosflux Talk 15:40, 11 January 2019 (UTC)
Also note, it is so low on the page, because we have filled it up with all those directions (you could hide them with css as well). Look for example at the page in another language: de language block screen. — xaosflux Talk 15:43, 11 January 2019 (UTC)
The text isn't showing because of the #blockiptext { display: none;} line in User:Black Kite/monobook.css. {{Sensitive IP addresses}} isn't hidden though, so it pushes the rest of the form down. It probably started happening around the end of March 2018 when Special:Block switched to OOUI. --AntiCompositeNumber (talk) 16:01, 11 January 2019 (UTC)
Only the first three lines (and the comment lines also) of User:Black Kite/monobook.css are valid CSS - all the rest (i.e. this lot) is JavaScript and should probably be at User:Black Kite/monobook.js - I would fix it myself, but I can no longer do so (it's unlikely that I ever will be able to fix it, since I cannot be an interface admin without WP:2FA, and my hardware won't handle it). --Redrose64 🌹 (talk) 16:58, 11 January 2019 (UTC)
I suspect a lot of my CSS/JS is there to fix issues that have since been fixed by gadgets or scripts etc. - is any of it necessary any more? If not I'll just delete it. Black Kite (talk) 17:49, 11 January 2019 (UTC)
You can't put JavaScript into a CSS page. At best, it will be ignored; at worst, some strange things may happen. Either way, it won't be executed as JavaScript, so will not perform its intended purpose. If you merely revert this edit either you'll see no difference, or you'll see an improvement. --Redrose64 🌹 (talk) 18:05, 11 January 2019 (UTC)
Thanks. Black Kite (talk) 15:41, 12 January 2019 (UTC)
Related to the new block screen: I've taken the liberty of modifying the text label for the "disable talk page access" option. Before I changed it, it was labeled Editing their own talk page, which is not terribly helpful or descriptive. I used Twinkle's Prevent this user from editing their own talk page while blocked instead. The change is at Mediawiki:ipb-disableusertalk; I couldn't find any previous interface messages related to this option (other than MediaWiki:Ipballowusertalk, which obviously isn't relevant). Writ Keeper  18:15, 15 January 2019 (UTC)

Code correction

Hi - I don't do code so would like this line looked at

div style="padding: 14px; background: #FFFAF0;<!--#ddcef2;--> border-style: groove; border-width: 5px; border-color: green; font-size: 95%; text-align:left; font-family: Euphema, arial;"

Its the top line on my talk page and its in pink; is the code deprecated perhaps? Thanks your time   MarkDask 15:22, 15 January 2019 (UTC)

Added nowiki tags to your div above. I suspect that your browser doesn't ignore the commented color value (violet) (tested on Firefox based/IE11/Chrome based and the background color is FFFAF0), or you just need to refresh (F5/Ctrl+F5) the page. MarMi wiki (talk) 16:49, 15 January 2019 (UTC)
And comments in css (in style too?) are done by /* and */ - CSS Comments. MarMi wiki (talk) 16:57, 15 January 2019 (UTC)
Yes, according to CSS Style Attributes (linked from Semantics, structure, and APIs of HTML documents) the value of the style attribute must match the syntax of the contents of a CSS declaration block (excluding the delimiting braces). So comments inside a style= attribute can only be of the /* ... */ form. --Redrose64 🌹 (talk) 21:35, 15 January 2019 (UTC)
(edit conflict) @Markdask: I suspect this is because you have a <div> element that is missing a </div> closing tag. This happens on talk pages when people want unusual affects sometimes. Are you trying to keep that box border around future sections that other people add, or just around your welcome box? — xaosflux Talk 16:50, 15 January 2019 (UTC)

Find unusually short articles

How can I query (or search, if no such list exists) the English wikipedia for articles obviously having a problem because they are meaninglessly short, i.e. zero prose, or less than 10 words, or even less than 100 words. Searching wikipedia is likely to be an enormous task, and such a script might need admin or even higher access to the wiki, Nonetheless, can it be done?

If there is a list, or when there is one, what can/should be done with it? These articles should be moved to some kind of editors-only (requires login to access) sandbox until they are suitable for publication, but I know of no such global structure. Articles can be so severely impaired for reasons other than length that they shouldn't be in the encyclopedia. Maybe deleting them isn't the best policy, because we'd rather eat dirt than delete a page because, well, it just doesn't measure up, and not for any admin or technical reason. Sbalfour (talk) 22:14, 15 January 2019 (UTC)

See Special:ShortPages. It excludes disambiguation pages but includes set index articles like surnames with two entries. PrimeHunter (talk) 22:31, 15 January 2019 (UTC)

Combating the issue of bare URLs

Hello all,

Apologies for putting this here, I don't know really where else to put it besides Wikipedia talk:Bare URLs where it certainly wouldn't get the input it deserves.

Fetterly et al (2003, DOI: 10.1002/spe.577) noted that 40% of webpages change within a week and that one in two-hundred links disappear from the Internet in the same time period. McCown et al (2005, arXiv:cs/0511077) noted that 28% of URLs failed to respsond in a study on D-Lib Magazine. Needless to say, bare URLs are bad news for Wikipedia, because they are prone to link rot which will compromise verifiability. Despite only five articles appearing in the link rot maintenance category, the problem is much more severe. A RegEx search I have run on the latest enwiki database dump reveals that 489,767 articles, approximately 8.5% of all enwiki articles, use bare URLs. That means that every week, on average, just shy of 2,500 articles will have at least one reference turned into a dead link and we will have no contextual information to rescue the sources.

I have laid out a plan here, however I don't believe reFill has the functionality of batch processing, which rather snookers the plan. I've got the list of the 489,767 articles but I sure as hell can't use reFill on every single one of them. Does anyone have any ideas on how to go about this?

Many thanks,

SITH (talk) 23:52, 3 January 2019 (UTC)

Per WP:Link rot:
All new links added to Wikipedia are automatically saved to Wayback Machine within about 24hrs. This is done with a program called "NoMore404" which Internet Archive runs and maintains. It scans the IRC feed channels, extracts new external URLs and adds a snapshot to the Wayback. This system became active sometime after 2015, though previous efforts were also made. etc..
Any links added after 2015 there is a very-high chance of a Wayback link being available. For earlier links there is also a very-good chance due to previous archiving efforts by Wayback, Archive.is and other providers. Still, some links which went dead a long time ago have no archives, and some links the providers can't or won't archive for some reason, link rot remains to some degree. -- GreenC 00:18, 4 January 2019 (UTC)
@GreenC: yep, but going through the AWB list, most of these articles are pre-2015 unfortunately. Perhaps it's a legacy issue with NoMore404, maybe we could link up a bot to reFill to clear out the backlog? SITH (talk) 00:49, 4 January 2019 (UTC)
reFill is one tool that works on bare links. There is also User:Citation bot. And IABot converts them (if the link is dead). I don't know what that error rate is for these tools, if they can safely be automated without user oversight. IABOt is fully auto, but when a link is dead the conversion isn't much to do. -- GreenC 01:03, 4 January 2019 (UTC)
One idea is extract a few thousand bare URLs at random into a test page (each surrounded by <ref></ref>). Make three copies of that test page. Run reFill on one, Citation bot on another, and IABot on the third. See what the results are - look for problems and differences. The quality of the edits will give a sense how viable it would be to run in fully automated mode. -- GreenC 01:32, 4 January 2019 (UTC)
There is also WP:Reflinks, which seems to correct a wider range than refill.Onel5969 TT me 01:38, 4 January 2019 (UTC)
One could presumably also build a bot to interface with mw:Citoid. --Izno (talk) 03:06, 4 January 2019 (UTC)
@Izno: reFill appears to be forkable on GitHub and doesn't depend on labs hosting so I could fork it and integrate it into AWB. I'd probably have to go to WP:BRFA first but that looks like the most feasible idea. — Preceding unsigned comment added by StraussInTheHouse (talkcontribs) 13:33, 4 January 2019 (UTC)
Whomever the nameless ping was from, you'll also need to check that reFill produces citations conforming to our current citation module. One or another of the gadgets does not presently. The reason I mentioned Citoid (which is similarly open source) was because it also has integrated a much-better specific site integration, I would guess. --Izno (talk) 14:44, 4 January 2019 (UTC)
reFill uses Citoid to generate citations. --AntiCompositeNumber (talk) 15:51, 4 January 2019 (UTC)
Oh, that's cool. I wasn't aware that it was using citoid. --Izno (talk) 18:30, 4 January 2019 (UTC)
Bears repeating - these tools are not run and forget. They make mistakes, quite frequently. They are designed as a starting point with further manual edits to fill in and fix. You are responsible for every edit. Focus on getting it right, the mistakes these tools makes are far more work and time to find and fix after the fact. That's why I recommended, run tests to see which tool does the best job, and see how many mistakes they are actually making. It may be we don't have any tools reliable enough for an unattended bot run. -- GreenC 15:42, 4 January 2019 (UTC)
@StraussInTheHouse: The current tool isn't very flexible in this regard, but a rewritten version under development (I'm planning to take it back from the ashes after my hiatus) provides a set of APIs that will allow for easy integration with bots. It's nowhere near completion, but the new version has much less cruft compared to the existing PHP version, and is where more development effort should go. Zhaofeng Li talk (Please {{Ping}} when replying) 15:21, 8 January 2019 (UTC)
Zhaofeng Li, that looks good, let me know when you’re fully back and I’ll help all I can! SITH (talk) 18:11, 8 January 2019 (UTC)
@StraussInTheHouse: I've got the new version back in shape in the past week, and it should be ready for public testing at this point. Zhaofeng Li talk (Please {{Ping}} when replying) 05:00, 16 January 2019 (UTC)
@GreenC: test cases on draftified versions would be the best bet. SITH (talk) 16:20, 4 January 2019 (UTC)
Yeah create a page in userspace with the URLs and run the tool on it. When done delete the page. It's userspace can do whatever you want. -- GreenC 16:25, 4 January 2019 (UTC)

File names which have been changed

I'm going to ask this here since I figure it's a technical question and because there are probably more people watching this page than there are watching WT:File names. What happens to a file name once it has been changed? Is a redirect to the new name created? I came across File:Kedi (2006 film).jpg while checking on some non-free images; this file used to be named File:Kedi.jpg, which if you click on the link you'll see is now a completely different file uploaded to Commons. It's probably not a big deal except that there is a link to the original file name in Wikipedia:Non-free content review/Archive 55#File:Kedi.jpg which now lead to a completely different file and the log shows that "File:Kedi.jpg" was deleted per WP:F2. I know that {{Shadows Commons}} is used in cases where two files (one on Commons and one on Wikipedia) have the same name; but, I'm not sure if that applies in a case like this. -- Marchjuly (talk) 05:51, 16 January 2019 (UTC)

Hitting "enter" in the edit summary box no longer saves the page

When I am in the edit summary box and hit "enter" rather than saving the page this action now brings up a menu of common edit summaries, even if I have already typed my edit summary. I have no use for this feature. Can I at least get the previous effect of saving the page as an option? bd2412 T 21:15, 10 January 2019 (UTC)

Testing... It saved it for me. What skin are you using? Did you change anything in your preferences or gadgets? ~ ONUnicorn(Talk|Contribs)problem solving 21:28, 10 January 2019 (UTC)
  • I am facing the same problem as User:BD2412 and it started a few hours back, so something recent has changed it. Now the only way to save a comment is to use the mouse and hit the publish button. I have not made any changes and would like the old functionality back. thanks.--DBigXray 21:31, 10 January 2019 (UTC)
Wikipedia:ITSTHURSDAY? Works fine for me, is there a chance your browser updated recently? ~ Amory (utc) 21:40, 10 January 2019 (UTC)
This is happening to me, sometime today (no browser restart or the like). "Enter" on the Edit Summary triggers the drop down of "common edit summaries" --Masem (t) 21:54, 10 January 2019 (UTC)
  • @BD2412, DBigXray, and Masem: At Preferences → Gadgets, what is your setting for "Add two new dropdown boxes below the edit summary box with some useful default summaries"? --Redrose64 🌹 (talk) 22:01, 10 January 2019 (UTC)
    It was enabled. Disabling it removes this above stated behavior. --Masem (t) 22:07, 10 January 2019 (UTC)
    Same. The issues is solved, but I note that I did not make any recent changes to preferences to cause the change. My computer did install updates within the past few days, but the behavior noted above did not manifest until earlier this afternoon. bd2412 T 22:17, 10 January 2019 (UTC)
    @Redrose64: it was selected from a long time, and still is selected (same as Masem and BD24). Unselecting the option, removed the 2 boxes of default summary. While deselecting the option solves the problem but I would still prefer to be able to use the option of hitting the enter key at the edit summary box, "while having" these 2 default edit summary boxes at the same time. Like it was before. This problem started in the last 2-3 hours so I suspect some change from the wikimedia server side triggered it. if someone could restore this back, or if there is another way to fix this, it will be appreciated. --DBigXray 22:26, 10 January 2019 (UTC)
    There are no recent changes in MediaWiki:Gadget-defaultsummaries.js --Redrose64 🌹 (talk) 23:24, 10 January 2019 (UTC)
    Something has definitely changed, though, as I had the extra boxes enabled for ages and the "unable to press Enter to submit" issue only started today. Black Kite (talk) 00:48, 11 January 2019 (UTC)
"Fails" for me as well in Chrome and FF (if the gadget is enabled). — xaosflux Talk 22:39, 10 January 2019 (UTC)
  • Additional problem - the same issue arises in the [Reason] field when trying to move a page. The fix that solved this problem for the regular edit box does not appear to be available for this one. bd2412 T 23:35, 10 January 2019 (UTC)

I've just started to notice that clicking edit doesn't save edits anymore... It used to be that if I was in the Edit Summary panel and I hit enter, the page would save. Now, doing that causes the "Common edit summaries" dropdown to open. Has anyone else seen this? --Zackmann (Talk to me/What I been doing) 23:02, 10 January 2019 (UTC)

Zackmann08, I have, and it's annoying me to no end. These sort of "updates" are completely unnecessary. -- /Alex/21 00:37, 11 January 2019 (UTC)
FWIW, I am not having this issue on testwiki or test2wiki. — xaosflux Talk 01:02, 11 January 2019 (UTC)
And it just stopped happening here.... — xaosflux Talk 01:03, 11 January 2019 (UTC)
@Alex 21 and DBigXray: are you still having the issue? — xaosflux Talk 01:04, 11 January 2019 (UTC)
Never mind, with gadget enabled it is still failing here. — xaosflux Talk 01:05, 11 January 2019 (UTC)
@Alex 21 and DBigXray: FWIW once I disabled the 2 fields, problem solved. :-) --Zackmann (Talk to me/What I been doing) 04:19, 11 January 2019 (UTC)
@Zackmann08:, have you tried doing a page move? For me, disabling the fields does not seem to fix the issue for the edit summary for that action. bd2412 T 13:41, 11 January 2019 (UTC)
  • If any intadmin (xaosflux?) wants to put a quick patch in to restore this functionality while we try to figure out what went wrong, they can copy over the content of User:Enterprisey/Gadget-defaultsummaries.js and then G6 it. Not a very good fix (it's just another keydown handler to check for enter presses, and then trigger the save button), of course, but this issue seems to be disrupting some workflows. Enterprisey (talk!) 06:43, 11 January 2019 (UTC)
  • Gonna go ahead and make a wild guess that the OOUI update to v0.30.0 that was rolled out 20:00–22:00 UTC as part of the normal update to 1.33.0-wmf.12 (all from wikitech:Deployments#Thursday,_January_10 and mw:MediaWiki_1.33/wmf.12. The underlying issue might not exactly be trivial to find. Edit request filed. Enterprisey (talk!) —Preceding undated comment added 07:28, 11 January 2019 (UTC)
    @Enterprisey: I promoted your code to the gadget, this does seem to be bigger problem as there are some other workflows mentioned above. Probably needs a dev ticket opened. — xaosflux Talk 12:05, 11 January 2019 (UTC)
  • phab:T213544 opened. — xaosflux Talk 14:48, 11 January 2019 (UTC)

This issue is resolved now. Matma Rex talk 00:44, 15 January 2019 (UTC)

Thank you, I've reverted the workaround on MediaWiki:Gadget-defaultsummaries.js. — xaosflux Talk 02:54, 15 January 2019 (UTC)
  • Possibly related issue Inserting wiki markup via the bottom tabs after editing an edit summary will lead to the markup being in the summary, even when you have since edited the main article body. [Username Needed] 15:31, 11 January 2019 (UTC)

Is there a way to turn off the saving when hitting the ↵ Enter in the edit summary? I occasionally accidentally hit ↵ Enter instead of ', saving an incomplete summary or incomplete edit. I normally use the Alt+⇧ Shift+S (or click Publish) to save my edits, and would rather have it ignore ↵ Enter. I tried it with the "Add two new dropdown..." option both set and not set; it made no difference. —[AlanM1(talk)]— 11:06, 16 January 2019 (UTC)

User:Anomie/nosubmitsummary.js seems to still work for me. Anomie 12:53, 16 January 2019 (UTC)
@AlanM1: ^-- that, also the issue describe above was a bug, and was fixed. — xaosflux Talk 12:55, 16 January 2019 (UTC)