Wikipedia:Village pump (technical)/Archive 171

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

Contents

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:
RefToolbar 1.0.png
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 "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:
RefToolbar 1.0.png
...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). Face-wink.svg 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)
2010 wikitext editing toolbar.jpg
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:
2006 wikitext editing toolbar.png
--Timeshifter (talk) 13:30, 13 November 2018 (UTC)
@Timeshifter: No, I mean this CharInsert-it.PNG (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:

Commons edittools.png

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:

Active editors on English Wikipedia over time.png

--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:

2006 wikitext editing toolbar.png
  • 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:

  • 2017 wikitext editing toolbar.jpg

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

  • Edit tools. Bottom toolbar of wikitext editing window.jpg

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:

  • 2006 wikitext editing toolbar.png

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 "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:
Edit tools. Wiki markup. Bottom toolbar.jpg
Edit tools. Bottom toolbar of wikitext editing window.jpg
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":
Edit tools. Wiki markup. Bottom toolbar.jpg
Commons. "Standard":
Edit tools. Bottom toolbar of wikitext editing window.jpg
--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:
Wikitext editor. Show preview. Show changes. Edit summary. Publish.jpg

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)

Tech News: 2018-49

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)

Template:Infobox country

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: "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:
/* #REDIRECT */mw.loader.load("//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-responsiveContent.js\u0026action=raw\u0026ctype=text/javascript");
PrimeHunter (talk) 22:53, 6 December 2018 (UTC)
Consider this corrective edit: the passage concerned had displayed correctly at the time that I made the original post. --Redrose64 🌹 (talk) 23:41, 6 December 2018 (UTC)

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)
Scrunched desktop view on mobile.jpg
  • xeno Did it look like the screenshot at right? If so, I've been having that happen intermittently on my phone. Refreshing the page usually fixes it. ~ ONUnicorn(Talk|Contribs)problem solving 05:53, 5 December 2018 (UTC)
    Thanks ONUnicorn but it is simply the "mobile responsive" view for monobook which was implemented some months ago. In that view, once you're on a talk page I can't figure out how to get back to the article page. –xenotalk 17:54, 6 December 2018 (UTC)

A userscript to allow reversion on mobile

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

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

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)

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

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. Face-smile.svg — AfroThundr (u · t · c) 05:10, 19 November 2018 (UTC)
AfroThundr3007730, thank you so much for replying and trying to find a solution. Unfortunately, it did not work. I inserted the code into my [[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. Face-smile.svg Also I was avoiding using the a.new selector, which only seems to occur in the article body, because I also wanted to target the namespace tabs and any other interface element that could result in the editor spawning (with the sole exception of the edit tab). Your version is a lot more compact though. One of these days I need to learn jQuery and the MediaWiki JS properly. — AfroThundr (u · t · c) 00:06, 20 November 2018 (UTC)


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

Tech News: 2018-50

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)

Tech News: 2018-51

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?

Moved from Wp:Village pump (proposals): 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 Bihari languages whereas the proper code for Bhojpuri 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}}[[Ligurian (Romance language)|Ligurian]]Ligurian
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