Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 109.153.227.154 (talk) at 14:53, 6 January 2015 (→‎Animated images). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

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


Access rights failure

Tracked in Phabricator
Task T85428

See this edit. It was made by a logged-out user. That shouldn't have happened, because editing subpages of Template:Editnotices is restricted to those with the template-editor and accountcreator rights. How was it possible? --Redrose64 (talk) 19:27, 27 December 2014 (UTC)[reply]

That does seem to be a flaw in security. One guess is that the token was grabbed while logged in and then used while logged out, the system may be failing to check that the user is the same on the token was issued to. If that is the case then session stealing may be possible via a MITM attack. However it happened it should be looked into. Chillum 19:31, 27 December 2014 (UTC)[reply]
Anyone know how this protection is actually implemented? I know it reads in WP:TPE that "The template editor user right allows trusted coders to edit templates and modules that have been protected with the "protected template" protection level (usually due to a high transclusion rate). It also allows those editors to edit edit notices, all of which are permanently uneditable without template editor, account creator, or administrator rights." but unless this is implemented in the core MediaWiki functionality, or an extension, there's no evidence I can see that unprotected templates - such as the edit notices - are actually protected. Mind you, I've still got a post Christmas hangover. QuiteUnusual (talk) 19:40, 27 December 2014 (UTC)[reply]
It is implemented via the Mediawiki:Titleblacklist, specifically:
  # Editnotice pseudospace
  Template:Editnotices\/.* <noedit|errmsg=titleblacklist-custom-editnotice>
If I attempt to edit Template:Editnotices/Page/European Union, I get a red warning box that thinks it is protected. Dragons flight (talk) 19:48, 27 December 2014 (UTC)[reply]
I was able to make a change. I'm just a regular user. --Edgars2007 (talk/contribs) 20:11, 27 December 2014 (UTC)[reply]
Ummm I can edit it [1] but now cant revert as the "You do not have permission to edit this page, for the following reason:" box appears ....So could someone please revert me - Sorry! –Davey2010 Merry Xmas / Happy New Year 20:17, 27 December 2014 (UTC)[reply]
Done. I also logged out and got my wife to log in (normal user). She can't edit it. So it's not that everyone can edit it and the protection isn't working at all. Black Kite (talk) 20:22, 27 December 2014 (UTC)[reply]
Now everything is ok - I can't edit it anymore. --Edgars2007 (talk/contribs) 20:27, 27 December 2014 (UTC)[reply]

It appears this bug has some nuance to it. Were those able to edit it using IPv6 and those not able using IPv4 per chance? Chillum 20:24, 27 December 2014 (UTC)[reply]

I did wonder that. Unlikely though, if Edgars2007 could edit it, but now can't. Black Kite (talk) 20:32, 27 December 2014 (UTC)[reply]
I was unable to replicate this while logged out. I even tried to copy the entire source of the page from a logged in as ACC & TE account (this one) to the logged out in IE one and although I could make it so I could type in the box and click save, it still got caught up in the back end. I'm guessing it is a caching issue and has nothing to do directly with tokens or the specific users. I'm wondering what things are similar between the two accounts and the default logged out. Should dig into what gadgets and preferences the two logged in users have disabled that were default as those can probably be excluded. Also, curious if there is a common userAgent string string involved. — {{U|Technical 13}} (e • t • c) 21:56, 27 December 2014 (UTC)[reply]
It shouldn't even let you alter the contents of the edit box, and no "Save page" button should be offered. The experience for a logged-out user attempting to edit an editnotice should be almost exactly the same as if they were on a template-prot page and clicked the "View source" tab: the only differences are that on an editnotice page, the "Edit" tab isn't modified to read "View source", and the notice above the edit window is different - crucially, it says "This editnotice can only be created or edited by administrators, account creators, and template editors" instead of "This page is currently protected so that only template editors and administrators can edit it". In both cases, the edit box is unalterable, and there are no tools or other buttons. --Redrose64 (talk) 22:49, 27 December 2014 (UTC)[reply]
  • It doesn't, on it's own. You missed the part where I said that I altered my local rendition of the code to see if it was an interface issue and it still caught it in the backend. ;) — {{U|Technical 13}} (e • t • c) 23:01, 27 December 2014 (UTC)[reply]
  • Likely this has nothing to do with it, but I will mention it just in case: I have several time been in the middle of an edit when the I was automatically logged out because my 30 days were up. I activated the edit window while logged in, but by the time I decided to save I was logged out. Is it possible that this situation is treated differently from one in which a person manually logs out? —Anne Delong (talk) 23:44, 27 December 2014 (UTC)[reply]
My first thought was the same as Anne's, although after reading everything, I also agree that it's less likely.
On a related point, whoever made it possible for me to get logged out mid-edit, and did not also make that result in large, annoying banners that said "You've been logged out again, so don't save!!!" with an automatic trip back to the login page, deserves to have a Long Discussion with the OTRS team about how much unnecessary work that choice makes for them.
(I don't know if it's possible, but I have wondered whether the usual ...w/index.php?title=Fee&action=submit could be changed to something like ...w/index.php?title=Fee&action=submit&status=logged-in, so that if I started editing while logged in, the URL would report the status when I try to save, and if I'm no longer logged in, then it would complain and give me the opportunity to log back in. (There would be no corresponding &status=logged-out, because if I started editing while logged out, and then logged in (in a separate window), then there's no harm done.) Whatamidoing (WMF) (talk) 00:22, 29 December 2014 (UTC)[reply]
I've opened phabricator:T85428 about this. Jackmcbarn (talk) 01:22, 29 December 2014 (UTC)[reply]

Download pdf still broken, round two

Tracked in Phabricator
Task T32706

The problems with the "Download pdf" link are still a problem. The tables and infoboxes are still not appearing. (Apparently not any navboxes, either.) I tried this on two different featured articles, and as anyone can see if you do a "download as pdf", critical information is omitted. On Appaloosa, the breed infobox and a critical illustrated chart of coat color patterns is omitted, and on California Chrome the pdf version omits the infobox and a chart of all his racing statistics (material that is really not easy to render in a simple bulleted list.) An earlier post here explained that "MediaWiki recently switched from using the legacy PediaPress PDF renderer to using OfflineContentGenerator." However, they basically said they were hoping to find some volunteers to fix the problem. It still isn't fixed. I'd say that if WMF broke it, they should fix it and not wait for volunteers to do it, but maybe someone here happens to be good at this sort of thing? I took a look at the same articles in WikiWand, and WikiWand renders it all beautifully. If a non-WMF project can deliver wikipedia content, so should WMF. Montanabw(talk) 22:12, 27 December 2014 (UTC)[reply]

Bug at phab:T32706. --  Gadget850 talk 14:58, 28 December 2014 (UTC)[reply]
Does WikiWand generate PDFs, though? I suspect not. It's not a fair comparison. — This, that and the other (talk) 04:42, 30 December 2014 (UTC)[reply]
The point is that generating templates seems to be well within the doable, and if a third party source can do it, and the previous pdf generating software could do it, why wasn't this bug fixed several months ago? It's a serious problem, particularly for articles that make use of templates for statistics and assorted data that is not suitable for rendering in narrative form. Another example would be rainbow trout. This failure of the pdf generator is causing some drama in certain articles where editors are trying to remove templates on the grounds that they don't show up in a pdf format. I know nothing about how the tech works to fix this, but hoping someone does and is willing to look at the issue. Montanabw(talk) 22:51, 30 December 2014 (UTC)[reply]

OneClickArchiver new feature!

Since there has been concern by some editors that they are "afraid" they'll accidentally activate Template:1CA while trying to click on the edit section link, I've added a new feature today that allows users to toggle the script on or off directly from talk pages! The best part is that it will remember what the last state was! Please see the documentation for more details and happy archiving! — {{U|Technical 13}} (e • t • c) 02:18, 29 December 2014 (UTC)[reply]

That's a really nifty feature. I see the "oca-on" and "oca-off" toggle at the top of the talk page. Thanks for doing this. — Maile (talk) 13:56, 31 December 2014 (UTC)[reply]
  • Maile66, the "on" or "off" is the current status of the tool. You can also toggle it with Alt+⇧ Shift+O. I made a large scale change to the tool yesterday that checks if the required parameters can be detected before polluting the page with lots of unusable |Archive links that just yell at you when you click them. I've replaced those links with an "error" message that fades away after five seconds in the top right corner of the screen instead. Due to some complaints about the error message, you should now only see those messages when the script is "on".
I've also added a small debugging feature to the script. If you click on Debug mode on any talk page where the script doesn't seem to be running or append ? or & and then debug=true to the URL of a talk page (ie en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)?debug=true or en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&debug=true) and then press enter you will see a box in the upper right corner that will not go away until clicked on that will tell you what the script could find for parameters.
If it couldn't find a parameter, that cell will be red and it will show what it's going to guess the default value should be. Those default values are for an upcoming feature that will allow you to use the script to set up automatic archival on pages that currently have none and will also be used for the requested features of being able to use the script to increment the counter, create new archive pages using the defined header, and respect maxsize. Lots of features in the works. I'll try and keep everyone posted! — {{U|Technical 13}} (e • t • c) 14:25, 31 December 2014 (UTC)[reply]

Log in every 30 days

I've looked through the archives (not all 133 pages, but did it by search) and didn't see anything directly answering this question. Why are we limited to 30 days per log in? I'm sure those with multiple bots find this aggravating, not to mention those, like me, who make changes sporadically. We go to make a edit and suddenly find we're not logged in. I can keep Wikipedia up and open for multiple days, so I can open on Friday, get logged out on Saturday, and not know it until Monday. I'd also like to see this changed, but not sure if I would have to resubmit the question in another section for that. I can log into my e-mail for years on end, and that is far more sensitive than my Wikipedia account. Only thing I can figure is that it is a server issue (too many active log ins slowing it down), but I'm not an IT guy, so I may be way off.

Thank you in advance and Happy Holidays and Happy New Year. Leobold111 (talk) 20:25, 29 December 2014 (UTC)[reply]

Actually, it's a little better than that, barring any flukes that happen once in a while. Mostly, as long as you edit on a semi-regular basis, say once a week or so, you'll stay logged in. The "flukes" have nothing to do with the 30-days max. And by that, I mean that a couple of times lately I've been editing, go to another article and find out I was involuntarily logged out. It has its kinks. But you'll probably stay logged in longer than 30 days if you edit regularly. — Maile (talk) 22:01, 29 December 2014 (UTC)[reply]
I usually bypass it by never cleaning he Chrome history and keeping the WP tab open - This year alone I've only ever been logged out once which was weirdly a couple of days ago! (although If you love your laptop more than I love mine it's probably a bad idea to keep laptop on 300 hours and on charger 247!..) –Davey2010 Merry Xmas / Happy New Year 22:13, 29 December 2014 (UTC)[reply]
I asked (read: complained) about this two or three years ago, and I was told that the 30-day limit was due to the privacy policy. The privacy policy (back then, at least) said that no cookies would be stored for more than 30 days, and therefore cookie-based logins couldn't be expected to last longer than 30 days. Whatamidoing (WMF) (talk) 20:37, 30 December 2014 (UTC)[reply]
For many years, the login cookies lasted 180 days. For almost the same number of years, the Wikimedia Foundation had a privacy policy that said cookies would not be set for longer than 30 days. At some point (2011 or 2012, I think) this discrepancy was noticed and the login cookies were reduced to 30 days. As a practical matter, it was easier to make the cookies shorter than to change the privacy policy. Relatively recently (2013, I think), there was a major overhaul of the privacy policy [2]. At present, the main text of the policy does not specify cookie durations, though there is an associated FAQ that lists current cookies and gives durations ranging from 1 day to 1 year [3]. Since the update of the privacy policy, I'm not aware of any discussions regarding to changing the duration of the key centralauth cookies to change the duration of an active login. Dragons flight (talk) 22:59, 30 December 2014 (UTC)[reply]
I'll go ask Legal if this limit is still necessary. It may take a while to get an answer. In the meantime, someone else can start thinking about remarks to file under the heading of "Why having a long login session is not a significant security risk, and why it is The Right Thing to do". Whatamidoing (WMF) (talk) 00:35, 1 January 2015 (UTC)[reply]
How about a warning box at the top of any page displayed during the last ten (?) minutes of the login session? "Your login session will expire in N minutes." That could help to reduce accidental logged-out edits. -- John of Reading (talk) 07:45, 1 January 2015 (UTC)[reply]
To Whatamidoing's point, I don't see how a long login here is such a security risk, or a security risk at all. If someone gets into my e-mail account, they can wreak havoc on my life, due to needing an e-mail address for everything. I'm almost positive it would be the same for most people reading this. If someone gets into my Wikipedia account, there's not really any damage that can be done, aside from easily revertable changes to pages. And if it continues, there can be a lock put on my account until it can be proven that the stolen account is no longer an issue. Breaking into this account would hurt my feelings, but nothing more. Leobold111 (talk) 22:31, 1 January 2015 (UTC)[reply]
John, that's an interesting idea, but I suspect that you meant something closer to "12 hours" where you typed "ten minutes". Whatamidoing (WMF) (talk) 00:20, 2 January 2015 (UTC)[reply]
And...it just did its magical trick of logging me out in the middle of an edit. — Maile (talk) 21:44, 2 January 2015 (UTC)[reply]
Sometimes it does that to me. I spot it instantly, because I use MonoBook skin and the difference from Vector is enough to alert me that I'm no longer logged in. If you use Vector skin, you need something else - such as the technique described at User:Gadget850/FAQ#Logged out that makes the Save page button green when logged in - if it's grey you're logged out. It works in MonoBook as well as Vector. --Redrose64 (talk) 21:57, 2 January 2015 (UTC)[reply]
I use Modern skin. And how it shows up, is if I'm in one article and then try to open a different article. In this case, and I use Firefox, I had an edit window open and then clicked on another tab to view another article I had been reading (but not editing). Strange stuff. I take it as a system hiccup. — Maile (talk) 22:48, 2 January 2015 (UTC)[reply]

Legal says that there is no longer any requirement (on their side) to log everybody out after 30 days. My proposal: Let's stop doing that. What do you think would be the ideal frequency for logging in? Every 60 days? 90? 180? Whatamidoing (WMF) (talk) 22:58, 4 January 2015 (UTC)[reply]

Provide options, with a default of, say, 90 days (quarterly). Personally, I'd set it to one year if a number had to be set, indefinite if one did not. — Huntster (t @ c) 23:06, 4 January 2015 (UTC)[reply]
My preference is 180, but I am thinking 30 is a reasonable default if one can choose in their preferences. Chillum 23:07, 4 January 2015 (UTC)[reply]
I say indefinite. If we had to have a certain time frame, I'd say 180 days. Anything over that and the risk is run that we will forget the password. I just don't see a reason for it if there isn't a legal reason. I can be logged into many different types of websites indefinitely, some of which would cause real issues. My Wikipedia account, not so much. Leobold111 (talk) 16:06, 5 January 2015 (UTC)[reply]

See phab:T68699. Legoktm (talk) 08:06, 5 January 2015 (UTC)[reply]

Template:Polytonic in special character inserter

The character inserter at the bottom of the edit box has the option to insert the template {{polytonic}} at the end of its menu of Greek characters. This template is deprecated and should be replaced with {{lang|grc}} in the programming of this thing. I'm commenting here because couldn't find any Help or Wikipedia page relating to the character inserter. (I feel like I'm in a bizarre nightmare....) — Eru·tuon 00:12, 30 December 2014 (UTC)[reply]

I've removed it. I don't think it needs to be replaced with the lang tamplate. -- [[User:Edokter]] {{talk}} 00:52, 30 December 2014 (UTC)[reply]
Well, I am trying to standardize articles on Ancient Greek by adding that template, and since {{IPA}} and {{Unicode}} are included in the special character inserter, it would make sense if {{lang|grc|}} were as well. — Eru·tuon 04:54, 30 December 2014 (UTC)[reply]
We'd have to add to to every language section then. Can you post this at MediaWiki talk:Edittools? -- [[User:Edokter]] {{talk}} 09:02, 30 December 2014 (UTC)[reply]
@Erutuon: It's a gadget, and the gadget's front page is MediaWiki:Gadget-charinsert. There is a small help page at Help:Edittools. These do have talk pages, more than two in fact - the main one is MediaWiki talk:Edittools, which you were directed to by Edokter, but in addition that there is MediaWiki talk:Gadget-charinsert there is also MediaWiki talk:Gadget-charinsert-core.css. The gadget has been renamed and reconfigured more than once, and I suspect that other talk pages are strewn about along the way. --Redrose64 (talk) 14:18, 30 December 2014 (UTC)[reply]
@Edokter: Thanks for the pointer. I posted a comment there.
@Redrose64: Thanks for the info. Seems like the gadget ought to at least be briefly mentioned and linked in Help:Editing. I posted a suggestion in the talk page there. — Eru·tuon 22:21, 30 December 2014 (UTC)[reply]

Edit window font

I edit with Firefox 34.0.5 for Windows 8.1, 64 bit. To choose a font for the edit window, I went into Preferences-->Editing, and for the Edit Font Area Style I chose Monospaced Font. In Firefox I chose Tools-->Options-->Content Tab-->Advanced. For the Monospace font I chose Consolas, size 16. But the Wikipedia editor just started ignoring my choice and displaying some nearly illegible font. What changed, and how can it be fixed? — Preceding unsigned comment added by Jc3s5h (talk • contribs) 00:37, 30 December 2014 (UTC)[reply]

Consolas works for me in Firefox 34.0 on Windows Vista. Have you tried the more common Courier new? Does it help to log out? PrimeHunter (talk) 04:39, 30 December 2014 (UTC)[reply]
After some experimenting, I found that in the Wikipedia editing preferences, I need to specify "Browser default" rather than "Monospaced Font". Somehow the broweser monospace font is chosen rather than any of the other browser defaults (serif or san-serif). Jc3s5h (talk) 17:12, 30 December 2014 (UTC)[reply]
@Jc3s5h: Browsers typically have more than one default font; Firefox 34.0.5, for instance, has several sets of four. You can check and set these as follows: in the menu at the top, select "Tools" → "Options"; in the icon strip at the top of that, click on "Content"; in the "Fonts & Colors" box, click Advanced... and this opens another dialog box. This has a pull-down menu named "Fonts for"; if you're checking the fonts used in English Wikipedia, make sure that "Latin" is selected there. Below that are four fonts - the one that is used for English Wikipedia edit boxes is the one shown against "Monospace" - I've got "Courier New" here, size 13. --Redrose64 (talk) 20:14, 30 December 2014 (UTC)[reply]
Thanks, my confusion was that the preferences dialog in Wikipedia does not make it clear that when "Browser default" is chosen, it will be the browser default monospaced font.
and indeed it shouldn't, b/c it's not WP choice, it's the browser's choice. the part that may be confusing is the fact that most (all?) browsers use by default monospace fonts for a "textarea" element. maybe this (i.e., the default font used by the browser for textarea element) can be configured for some browsers, and if it can, then you might find non-monospace fonts in edit box. peace - קיפודנחש (aka kipod) (talk) 21:49, 30 December 2014 (UTC)[reply]

Undoing translation edits

Could someone explain to me how in blazes I'm supposed to undo junk edits like the ones at c:Help:Contents/pt. I am surprised that this functionality is not readily apparent. Magog the Ogre (t • c) 05:44, 30 December 2014 (UTC)[reply]

@Magog the Ogre: What's stopping you from reverting? Oh, I see. Hmm. Gonna look.--Fuhghettaboutit (talk) 06:15, 30 December 2014 (UTC)[reply]
Phab:T41415 maybe? — {{U|Technical 13}} (e • t • c) 06:23, 30 December 2014 (UTC)[reply]
It looks like you have to contact a Commons:Special:ListUsers/translationadmin.--Fuhghettaboutit (talk) 06:15, 30 December 2014 (UTC)[reply]
(edit conflict) Well I guess I'll just have to deal with it for now - the edits did translate the text afterall; they goofed up the linking too. Thanks. Magog the Ogre (t • c) 06:27, 30 December 2014 (UTC)[reply]
@Fuhghettaboutit: - could I make myself a translation admin? I tried that once and it didn't work. Magog the Ogre (t • c) 06:27, 30 December 2014 (UTC)[reply]
Simple. Just make yourself a steward first.--Fuhghettaboutit (talk) 06:29, 30 December 2014 (UTC)[reply]
Or, you know, click the translation administrator box under Groups you can change?[4] But it still doesn't work. Magog the Ogre (t • c) 06:40, 30 December 2014 (UTC)[reply]
I wonder what are the junk edits at c:Help:Contents/pt? Can't find... I don't understand Portuguese but at least the edits made by MEX VICENTE M3 seems fine to me. --Stryn (talk) 17:57, 31 December 2014 (UTC)[reply]
The edits seem to be a bit messy. There are headlines which are not present in the English version, and various links are broken. I don't know whether the text matches the English text. --Stefan2 (talk) 22:11, 31 December 2014 (UTC)[reply]
Well, if the edits are not that good they can be deleted (commons:Special:Contributions/MEX_VICENTE_M3) or fixed (if someone knows pt). --Stryn (talk) 00:12, 1 January 2015 (UTC)[reply]

Specifying location in Template:Infobox Company Comment

On pages such as Deutsche Waffen und Munitionsfabriken the company infobox seems to be broken with respect to the location field. The way I have it seems to be the recommended way per the documentation, which advises leaving the location_city and location_country parameters blank, but this instead leaves extra commas after the location string "Germany". Is there a proper way to express the location of the company with only country, without city, or is the template currently broken? Anon423 (talk) 15:15, 30 December 2014 (UTC)[reply]

Fixed with this edit to the infobox template. Due to the span tags the parameters in the {{comma-separated entries}} call were considered non-empty, so the template added commas. SiBr4 (talk) 15:30, 30 December 2014 (UTC)[reply]
Thanks! So I'm not going crazy. And I didn't even have to go back and re-fix it. I have a lot to learn about infoboxes, but should this fix be similarly applied to {{infobox company}}'s sister infoboxes, and/or other fields with similar syntax pitfalls? Anon423 (talk) 15:43, 30 December 2014 (UTC)[reply]
These are all templates that use {{Comma separated entries}}. Randomly checking the source for a few of the infoboxes, most appear to either already use #if cases or not need them. {{Infobox company}} did also use them until they were removed today. SiBr4 (talk) 16:22, 30 December 2014 (UTC)[reply]

Image in Limbo

File:Action-centre-warning.PNG was reported at Wikipedia:Teahouse/Questions#Disapearing image file (but not image page)? It's still at http://upload.wikimedia.org/wikipedia/en/d/d6/Action-centre-warning.PNG. It could probably be fixed with a new upload but maybe somebody first wants to investigate further in case there is a more general problem. PrimeHunter (talk) 12:25, 31 December 2014 (UTC)[reply]

Re-uploaded. This should not frustrate any investigation (I think). -- [[User:Edokter]] {{talk}} 14:31, 31 December 2014 (UTC)[reply]

Pending Changes Log

The article Twitch.tv has Pending changes protection. However it neither has a lock in the top corner, nor any entries in the log [5]. Why is this? meamemg (talk) 23:51, 31 December 2014 (UTC)[reply]

The padlock icons need to be manually added; you can do it yourself with {{pp-pc1}}. Regarding the logs, that page was recently moved after it had been protected. According to the fine print at WP:MOVE, pending changes protection is moved with the page but isn't logged against the new page name after a move (unlike other protection types, which are logged). Regards, Orange Suede Sofa (talk) 00:04, 1 January 2015 (UTC)[reply]

"action=" parameters

Need a link to a list of valid "action=" parameters, say, in https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=edit. I know a few constructive ones like "edit", "purge", etc., but need a wider list for antivandalism check. Thanks in advance. Materialscientist (talk) 02:26, 1 January 2015 (UTC)[reply]

Help:URL#URLs of Wikipedia pages has some. PrimeHunter (talk) 02:40, 1 January 2015 (UTC)[reply]
I think what you are looking for is MW:Manual:Parameters to index.php#Actions. — {{U|Technical 13}} (e • t • c) 03:09, 1 January 2015 (UTC)[reply]
Yes, thanks. Materialscientist (talk) 04:07, 1 January 2015 (UTC)[reply]

Lua help needed

I would like to make a template, say {{Make diff}}, that takes a URL like https://en.wikipedia.org/w/index.php?title=Robin_Williams&diff=next&oldid=639931566 and outputs a formatted {{Diff}}? (A bot could regularly Subst: instances) That would be useful in many circumstances, and should be doable in Lua, in which I unfortunately have no skills.

I'd like as similar template, say {{Make unsigned}}, that would turn a string like 11:37, 1 January 2015‎ Pigsonthewing (which is easy to cut & paste from an article history) and render a formatted {{unsigned}} template. (Or perhaps the existing template could be modified to except that format of input?)

Could someone assist, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:42, 1 January 2015 (UTC)[reply]

Re: the second request, there's {{unsigned2}} and {{UnsignedIP2}}. Graham87 12:36, 1 January 2015 (UTC)[reply]
Thank you. They still require a pipe; I think Lua could be used to do away with that and to detect the parameter value's format, so we could merge them all. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:14, 1 January 2015 (UTC)[reply]
The first one shouldn't be too hard - I'll have a go at writing that now. The second will be easy if we're talking about copying and pasting the date format as it is shown in the page history, but if we want to handle free-form dates then it will be difficult to write code that can tell where the date ends and the username begins. (Consider that, technically, someone could set their username as a date if they wanted to.) — Mr. Stradivarius ♪ talk ♪ 14:17, 1 January 2015 (UTC)[reply]
Also keep in mind, dates in page history are formatted based on user preferences with 4 possible options. Mr.Z-man 17:39, 1 January 2015 (UTC)[reply]
I was only thinking of C&P from page histories. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:23, 2 January 2015 (UTC)[reply]
@Pigsonthewing: Your first request is now done - check out Template:Url to diff. — Mr. Stradivarius ♪ talk ♪ 17:21, 1 January 2015 (UTC)[reply]
@Mr. Stradivarius: That's fantastic, thank you! Could it be made to work ith un-named parameters, also? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:23, 2 January 2015 (UTC)[reply]
@Pigsonthewing: As in {{subst:url to diff|url|label}}? The problem with that is that diff URLs always have an equals sign in, so you would always need to make it {{subst:url to diff|1=url|2=label}} otherwise the text before the equals sign would be interpreted as a parameter. People tend to get that wrong, so I thought it was easiest to just make it a named parameter and have done with it. — Mr. Stradivarius ♪ talk ♪ 14:11, 2 January 2015 (UTC)[reply]
@Mr. Stradivarius: Ah, good point. Thanks again. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:09, 2 January 2015 (UTC)[reply]

Pagename: magic word, no disambiguation

Please remind me: I think we have a magic word, or template, like {{{PAGENAME}}, but which returns a disambiguation-free version of the page name, so "Foo" from a page called "Foo (bar)". What is it? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:12, 1 January 2015 (UTC)[reply]

{{PAGENAMEBASE}}. PrimeHunter (talk) 13:41, 1 January 2015 (UTC)[reply]
That's the one thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:34, 2 January 2015 (UTC)[reply]

I added it to the see also section of the documentation for {{PAGENAME}}. Oiyarbepsy (talk) 15:49, 2 January 2015 (UTC)[reply]

Category:Pages with malformed coordinate tags

If you look at what's in the above category, you'll find two user scripts: User:GregorB/FixCroIS.js and User:David Condrey/edit-tools.js (@David Condrey:). I have no idea why my script appears there: it's supposed to be JavaScript source code, but it seems as if MediaWiki treats it as wikitext and erroneously transcludes "templates" in it. (The script itself works fine.) Does anyone know what is happening here? GregorB (talk) 00:49, 2 January 2015 (UTC)[reply]

I usually get rid of such "false" detections by wrapping the content (very first and absolute last lines) of the offending .js file like so....
//<source lang="javascript">

  your normal .js stuff remains here 

//</source>
some folks use //<nowiki>; others use //<pre> -- it shouldn't matter -- they all seem to do the trick. Beats me why it it happens. -- George Orwell III (talk) 01:22, 2 January 2015 (UTC)[reply]
Oh and the "false detection" might still be listed for some time afterwards -- basically until your cache (or the wiki-system's) catches up with the change(s). -- George Orwell III (talk) 01:28, 2 January 2015 (UTC)[reply]
That's a clever trick - thanks, I'm going to try it. This seems to confirm that the problem is indeed due to MediaWiki treating source code as wikitext - although everything is displayed verbatim, "template code" seems to be transcluded under the hood, which leads to spurious warnings. So, in all likelihood that's a MW bug. GregorB (talk) 10:13, 2 January 2015 (UTC)[reply]
@GregorB: The MediaWiki software does indeed look for constructs that resemble templates, and attempts to expand them. In the case of your script, it's attempting to expand the string constant '{{Infobox settlement | pushpin_map = Croatia | pushpin_map_caption = $1 | latd = $2 | longd = $3}}'. Another possible fix for that is to escape the second opening brace whenever there is a pair inside a string constant: '{\{ ... If MediaWiki did not expand templates, speedy deletion templates like {{db-user}} wouldn't work on user javascript pages. The same is true of wikilinks - for example, the text // Linkback: [[User:Anomie/previewtemplatelastmod.js]] is why User:Redrose64/common.js shows in Special:WhatLinksHere/User:Anomie/previewtemplatelastmod.js - this is intentional, it helps Anomie to track usage of the script. --Redrose64 (talk) 11:47, 2 January 2015 (UTC)[reply]
In fact, this is something that probably wouldn't be implemented were the code being written today, since it was originally a not-really-intended side effect. See T43155 for some history on that. Anomie⚔ 16:37, 2 January 2015 (UTC)[reply]
@David Condrey: In the case of User:David Condrey/edit-tools.js, it's 'Coordinates for place of burial, ash-scattering etc. Use {{coord}} template.' - again, you can escape the second opening brace: 'Coordinates for place of burial, ash-scattering etc. Use {\{coord}} template.' --Redrose64 (talk) 11:57, 2 January 2015 (UTC)[reply]
@Redrose64: All good points. Not a bug then, just a sneaky feature... BTW the script is gone from the category now, so problem solved. GregorB (talk) 11:59, 2 January 2015 (UTC)[reply]
@David Condrey: FYI, he's got the closing tag(s) in the last line of the script but lost the opening tag(s) for the first line at some point -- which is not all that uncommon. Point here is if you're going to use the "hidden tag" approach don't forget to check for such breakages before applying new ones first. In instances like this, the missing or opening "hidden-tags" may not be missing at all but have become part of the body of the script instead of residing on the first or last line(s) as bits of script get added/amended over time. -- George Orwell III (talk) 20:49, 2 January 2015 (UTC)[reply]

"Your language setting British English is not recommended."

The language I've chosen is British English. If it's not supported, fine. But what does this mean? I propose that it be removed or explained. There are lots of other language variants on the list, too. How come half of the English-speaking world gets this message? --Tom- (LT) (talk) 05:19, 2 January 2015 (UTC)[reply]

Do you know where you set this option, and where do you see the message?
BTW, British English is nowhere near half the English-speaking world. It is only about 14% or one in seven See English-speaking world. —EncMstr (talk) 06:20, 2 January 2015 (UTC)[reply]
The explanation is linked: "Many messages have been customized at the English Wikipedia but usually only for the default "en - English". It is therefore not recommended to select "en-GB - British English" or "en-CA - Canadian English". -- zzuuzz (talk) 06:30, 2 January 2015 (UTC)[reply]
Having trouble finding 14% but that's beside the point, there's still quite a lot of us however you cut the cake. Do we display the same message for simplified and traditional Chinese? The varieties of German? How come there's not an "American English" option, and that's viewed as standard English and not "American English"? What I propose is this: remove "Is not recommended", it's (mildly) offensive. --Tom (LT) (talk) 06:39, 2 January 2015 (UTC)[reply]
By the way, unlike variants of English, traditional and simplified Chinese are wildly different. The characters aren't the same, so are many expressions. Zhaofeng Li [talk... contribs...] 07:05, 2 January 2015 (UTC)[reply]
OK, but we don't have one labelled just "Chinese" because it's used by the PRC and the other labelled "Traditional Chinese" with a message "This is not a recommended option" (implication: please use simplified). I hope you could see, Zhaofeng Li, how that could cause some offense, eg to a person from Hong Kong or Taiwan or part of the Chinese diaspora. --Tom (LT) (talk) 07:13, 2 January 2015 (UTC)[reply]
For those who are still confused, as I was, this is what you get if you go to special:preferences, click the drop-down box labelled "Language", and choose "en-GB" as your language.
I have to agree with Tom that this is weird. If we're going to localize for English varieties, then we should really do it, for all user messages. If we're not going to localize for English varieties, then there's no point in having them listed in the drop-down box. It should just say "English", and let that include all varieties that we use. --Trovatore (talk) 07:22, 2 January 2015 (UTC)[reply]
@LT910001: This only affects the local, English-Wikipedia-specific customizations, which are maintained locally by administrators here. The MediaWiki software is correctly localized both for British English, varieties of Chinese and varieties of German. Matma Rex talk 09:36, 2 January 2015 (UTC)[reply]
  • As for your question, How come there's not an "American English" option, see Phab:T33874. — {{U|Technical 13}} (e • t • c) 11:56, 2 January 2015 (UTC)[reply]
The language preference applies to the user interface which includes the sidebar, the topbar and user messages. It does not affect any content on the page. Each of these interface elements has a default for all of the supported languages. But, the English Wikipedia has heavily customized many interface pages. You can browse through Special:AllMessages to see the interface pages. The customized pages are highlighted in green and you can select the language to see how the interface page appears for that language.
Lets look at MediaWiki:Cite references link many. This is one of the pages that styles the backlink for references. By default this is ↑ but on the English Wikipedia with language set to en it shows as ^ in the reference list. MediaWiki:Cite references link many/en-br has also been customized so ^ shows when en-br has been set for British English. But MediaWiki:Cite references link many/en-br does not exist so users with Canadian English en-br will see ↑. This is just one of thousands of interface pages.
British English is currently the fourth most selected language, behind Spanish, French and Bahasa Indonesia and just above Arabic, Russian and Brazilian Portuguese. See Wikipedia:Database reports/User preferences. None of those other languages have these interface page translated.
In my opinion, the English variants for the language preference are not useful. I just cannot think of any words that we would use on one of these pages that would not be comprehensible. As I recall, there is one British language interface page that uses "colour" which is a pretty trivial change.
Thus, there is no advantage to setting the language preference to British or Canadian English, and a number of disadvantages.
--  Gadget850 talk 12:51, 2 January 2015 (UTC)[reply]
I do agree with what you say (ie that what is written is comprehensible) but as a native speaker and reader/writer of British English I'd prefer if there was a language option reflecting this.--Tom (LT) (talk) 21:28, 2 January 2015 (UTC)[reply]
It was me who added "Your language setting British English is not recommended." to MediaWiki:Preferences-summary/en-gb, displayed at https://en.wikipedia.org/wiki/Special:Preferences?uselang=en-gb. "not recommended" is a link to an explanation. See https://en.wikipedia.org/wiki/Nosucharticle?uselang=en versus https://en.wikipedia.org/wiki/Nosucharticle?uselang=en-gb for an example of English Wikipedia customization at the default language en. It was done by editing MediaWiki:Noarticletext. It would be possible to edit hundreds of similar pages for other languages like MediaWiki:Noarticletext/en-gb, but it's usually only done for en. The MediaWiki default (which cannot link or refer to anything at the English Wikipedia) is displayed for the rest. There have been suggestions to do something systematic for en-gb or en-ca to display the same as en, but nothing has been done so far. PrimeHunter (talk) 13:17, 2 January 2015 (UTC)[reply]
FWIW c:, d:, m:, mw:, w:de:, and w:ru: all let me pick en-gb (but not en-GB) without comment. Of course the w:ru: folks didn't bother to translate their "gadgets" on Special:Preferences. Maybe write "might cause problems" with something boiling down to "needs volunteers with write access on interface messages" or similar. –Be..anyone (talk) 10:58, 3 January 2015 (UTC)[reply]
Problems with the British English preference keep appearing here. They've included a much less prominent warning when editing an old version of a page, Twinkle offering less options, disappearance of tools and overnight font changes. I agree with Gadget850: there are no significant benefits and many risks, including that it's yet another cause to be considered when trouble-shooting. NebY (talk) 14:39, 2 January 2015 (UTC)[reply]
Perhaps the warning could be rephrased, something like "Descriptions in British English don't exist for all pages. See more here." I just find it strange that WP is telling me not to use settings in my mother tongue. --Tom (LT) (talk) 21:28, 2 January 2015 (UTC)[reply]
Non-specific English (which is what "en - English" is intended for) shouldn't be unintelligible to any native English speaker, whether they be American, Australian, British, Canadian or another. Bigger differences between those dialects (like elevator/lift, pavement/sidewalk, or faucet/tap), simply don't occur in the interface pages so are not a problem. Others, like colour/color (which do come up in the interface pages) are trivial. We shouldn't need to maintain three sets of interface pages when only one is necessary. --Redrose64 (talk) 21:37, 2 January 2015 (UTC)[reply]
It's standard to link text to a page with more details, and in Wikipedia it is extremely common. I don't think we need to say "See more here" when "not recommended" can be linked. "Descriptions in British English don't exist for all pages" is problematic. Many of the customized interface messages cannot be called descriptions. And many readers would probably think the text just means that the descriptions are in another English variant. But if we give the impression that no text is given at all for British English users then it's also misleading, because they see the MediaWiki default (it's blank in some cases but not usually). I think MediaWiki:Preferences-summary/en-gb should be a single line for most users and then it's hard to include an argument which is meaningful by itself and not misleading. Additionally, if we do say they lose some interface customization then they may still think it's worth it because they overestimate the tiny amount of British changes they get – basically a few minor spelling differences (mostly a single letter) in a few interface messages. I think everybody who knows how much customization it loses and how little British it gives have agreed that British English is a poor user setting. PrimeHunter (talk) 22:06, 2 January 2015 (UTC)[reply]
OK but I think my point still stands. It is not up to an individual user to "not recommend" an entire language group or customisation be used... this language as stated is the 4th most selected language. Would anything prevent this being rewritten in a more objective way? (eg "Only a few customisations exist for British English; the majority still use American English. See more.") --Tom (LT) (talk) 21:23, 3 January 2015 (UTC)[reply]
Perhaps we could put this into the FAQ for this page; I refer you to my post of 19:30, 13 June 2014 at Wikipedia:Village pump (technical)/Archive 127#Interface problems. --Redrose64 (talk) 14:48, 2 January 2015 (UTC)[reply]
I had forgotten that I had started a FAQ at User:Gadget850/FAQ/Language that anyone is welcome to use as a start. --  Gadget850 talk 15:12, 2 January 2015 (UTC)[reply]

Sounds like there should be a single interface customisation for all varieties of English, and we can simply mix and match the few spellings that differ. Oiyarbepsy (talk) 15:47, 2 January 2015 (UTC)[reply]

It appears from mw:Localisation statistics that only 70 of 3125 default MediaWiki messages currently have an en-gb variant. In August 2013 it was 51 of 2979 and I used a language file to make a probably complete list of the differences: "$1"/‘$1’ (different quote characters in many messages), color/colour, canceled/cancelled, vandalized/vandalised, Kilometers/Kilometres, meters/metres, digitize/digitise, program/programme, License/Lisense. That's all! And for that you lose hundreds of customized messages, often with links to relevant help, policy and process pages. PrimeHunter (talk) 22:19, 2 January 2015 (UTC)[reply]
So why don't we just officially go to a single English locale, then? I think it's fine if it's just a random mix of US and Commonwealth spellings. Or, let someone who cares go through all the messages and localize them. I don't really care which. --Trovatore (talk) 22:32, 2 January 2015 (UTC)[reply]
This is by far the best option. en-gb is far, far more trouble than it's worth (and actively problematic to well-meaning people who try and select it) and should be disabled. Andrew Gray (talk) 12:32, 3 January 2015 (UTC)[reply]
Many people are very attached to British English. Maybe there will be more British texts in the future. There could even be a feature with automatic conversion of text in articles. I think the best solution would be a fallback system: If en is customized and en-gb is not then display the customized en version to en-gb users. Disabling en-gb would be second best. PrimeHunter (talk) 16:57, 3 January 2015 (UTC)[reply]

I can easily see why the "not recommended" message could be better. People do not like hearing that their language is not recommended, even if that's not the real intent behind the message. Why not replace it something that is nearly as short and happens to be both neutral and true, like "not fully supported"? Regards, Orange Suede Sofa (talk) 22:38, 2 January 2015 (UTC)[reply]

If spelling is the only difference surely it could be automated by a bot? => Spudgfsh (Text Me!) 22:41, 2 January 2015 (UTC)[reply]
Thank you, I wholeheartedly agree. If we follow the strand of thinking above we might as well mark French and Arabic with little message too "Your languages received less attention than standard English. They are not recommended" of course we wouldn't do such a thing! If it's not supported, it shouldn't be offered. If it is supported, then it shouldn't be "not recommended". --Tom (LT) (talk) 22:55, 2 January 2015 (UTC)[reply]
I use Dutch as my interface language here, primarily to avoid all the "helpful" additions to the user interface. It wouldn't be a problem to me if some message popped up when I selected it that told me that I was not going to received customized messages as a result.—Kww(talk) 23:06, 2 January 2015 (UTC)[reply]
@Kww such a message would be welcome. As it is, the message is phrased that the language I speak (British English) isn't "recommended". I find it strange and slightly insulting. Surely the message could be rewritten ("Customisations don't exist for all options"). As stated above, in wikis of other languages no such message is provided. --Tom (LT) (talk) 21:23, 3 January 2015 (UTC)[reply]
Such messages probably should be provided in some other wikis if they have heavy customization and a language option very close to the default. If a user has chosen a language far from the default then it's less relevant. Then you probably chose it because you know it much better and can live with some lost customizations, and you don't expect your interface to match help pages. But with the current software I really want to discourage users from picking en-gb instead of en. Some of the suggested messages here will probably give many users the impression that the only problem with en-gb is that you still get some American spellings. The real problem is that the content of many messages is completely different. In addition to losing information, big differences in the interface also make it harder to use help pages which may for example describe non-existing links. It also confuses communication with other users if you ask for or give help. How about: "Your language setting British English is poorly supported. It loses many interface messages." PrimeHunter (talk) 01:25, 4 January 2015 (UTC)[reply]
The "not recommended" warning would be easily missed in any case. The situation is far from satisfactory, where you're offered an option and then find out (or don't ever find out) that it's not fully supported. If it's too much work to maintain three English variants, then jsut the one should be offered. Anyone who installs computer packages will be quite used to that: Noyster (talk), 09:42, 4 January 2015 (UTC)[reply]
Thanks PrimeHunter, I think that is a better phrasing and also more accurately reflects the situation. Also it makes the problem more obvious which, in turn (ideally) will provoke more users into supporting localisation.--Tom (LT) (talk) 10:37, 4 January 2015 (UTC)[reply]
I have updated MediaWiki:Preferences-summary/en-gb and MediaWiki:Preferences-summary/en-ca. PrimeHunter (talk) 14:20, 5 January 2015 (UTC)[reply]
PrimeHunter thanks greatly for making this change. Although it's a small change in wording, it is a big change in meaning. --Tom (LT) (talk) 22:36, 5 January 2015 (UTC)[reply]
I was just considering that. What if the selected interface page detected the default en page was customized and showed a button? --  Gadget850 talk 23:19, 2 January 2015 (UTC)[reply]
If they were all pages, that would work, but sometimes they are single words.—Kww(talk) 15:34, 3 January 2015 (UTC)[reply]
It would simply require a check to see if the interface page exists. MediaWiki:Abusefilter-edit-action-disallow does not exist, so the message is the default; MediaWiki:Abusefilter-edit-action-flag exists so it is customized. --  Gadget850 talk 15:58, 3 January 2015 (UTC)[reply]
You misunderstand me. MediaWiki:Abusefilter-edit-action-flag is a single sentence. Where would you put the button? If you have a displayed page that incorporated hundreds of such messages, would you have hundreds of buttons?—Kww(talk) 16:23, 3 January 2015 (UTC)[reply]
You are correct, we have many sections and pages built of multiple interface messages. This would not be viable. --  Gadget850 talk 17:31, 3 January 2015 (UTC)[reply]

Links are blue and followed links are purple, of course, as has always been true at Wikipedia. But the purple of a followed link used to have clear contrast with the black of surrounding plain text. Now I find it to have frustratingly poor contrast. Sometimes I cannot notice that a term is linked when I am reading (skimming comfortably over the lines at a normal reading pace). If I *stare* at a followed link, I can tell that it's dark purple and not black, but the point of visual contrast is that you're not supposed to have to stare or squint to discern it. Please no one reply that "maybe you have poor vision." I have normal visual acuity (wearing glasses) and color vision. The point here is not my vision, it is that between the font choice and the color choice for the UI, the contrast has been set at a very low level, and I suspect that someone let their own aesthetic preference get in the way of usability or user experience (UX). Which is poor UI design, but yet seems quite trendy within the past few years at many organizations (Microsoft comes to mind). Choosing fonts with super-skinny lines (which is now a trendy fad/obsession among web designers) does not help the problem. If I (with normal vision) am experiencing this, then I am not the only one. I don't know whether I am the first to complain about it, but I cannot be the first to have a degraded UX because of it. Hope someone might at least consider maybe choosing a lighter shade of purple. Quercus solaris (talk) 20:11, 2 January 2015 (UTC)[reply]

Which skin do you use? There are four available, and their link colours differ. We can advise you on how to change link colours for yourself, but to do that, we also need to know which skin. --Redrose64 (talk) 20:18, 2 January 2015 (UTC)[reply]
I use Vector (and I like it the most out of the four). Thanks, Quercus solaris (talk) 21:12, 2 January 2015 (UTC)[reply]
  • Visited link color in Vector skin
  • Visited link color in MonoBook skin
To use the slightly-lighter MonoBook link color in Vector, the rule is 
a:visited { color: #5a3696; }
- put that in Special:MyPage/vector.css You could even make it green, by using something like #008800 instead of #5a3696 --Redrose64 (talk) 21:27, 2 January 2015 (UTC)[reply]
From previous discussions, it appears that "the color" is actually a significant range of colors, depending on your browser, OS, screen, and ambient lighting. If the color goes lighter for one person, then it might be too light to be legible for another person. Also, some people have their browsers set to override Wikipedia's local link colors. If these seems different from what you remember in the past, then you might check your browser settings.
(Personally, I'm waiting for the day when job postings for web designers start saying things like, "Must use bifocals or consent to wearing low-vision simulator eyeglasses at work." Not enough attention is paid to the basics, like whether people can see the stuff on the screen.) WhatamIdoing (talk) 23:39, 2 January 2015 (UTC)[reply]
Thanks much for the follow-up, Redrose64 and WhatamIdoing. I added the css tweak and it seems to help. And now I feel better having vented and knowing that some backstory exists ("From previous discussions, it appears that "the color" is actually a significant range of colors, depending on your browser, OS, screen, and ambient lighting"). Cheers, Quercus solaris (talk) 23:49, 2 January 2015 (UTC)[reply]

Addition and subtraction in templates?

I am currently trying to find a way of entering a certain number into a template {{{year}}} and displaying a link to the years right before and after it. Is there a way to use addition and subtraction in templates? Dustin (talk) 03:19, 3 January 2015 (UTC)[reply]

{{#expr:}}. Mr.Z-man 04:18, 3 January 2015 (UTC)[reply]
(edit conflict) See mw:Help:Extension:ParserFunctions##expr. For example [[{{#expr:{{{year|{{CURRENTYEAR}}}}}-1}}|previous]] [[{{#expr:{{{year|{{CURRENTYEAR}}}}}+1}}|next]] if year is optional with the current year being default: previous next. PrimeHunter (talk) 04:20, 3 January 2015 (UTC)[reply]
Thanks. I'll try out {{#expr:}}. Dustin (talk) 06:33, 3 January 2015 (UTC)[reply]

Stopping unnecessary notifications

Tracked in Phabricator
Task T85728

I protect a page here and a few minutes later an editor makes this edit. I then get the notification that "Your edit on Sethi has been reverted by Vigyani. (Show changes)". Is there any way to stop that particular type of notification? CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 08:49, 3 January 2015 (UTC)[reply]

This happens when an editor uses "Reverted to..." as the summary. In this case, the software assumes all changes between the revert and the target are undone (including all "informational" edits like protection changes which don't modify the text at all). Dunno if this is a known bug, though. Zhaofeng Li [talk... contribs...] 09:20, 3 January 2015 (UTC)[reply]
The revert notification does not depend on the edit summary – I received a ping for this revert with blanked edit summary. Per the feature documentation the notification is triggered by "click[ing] 'Undo', 'Rollback', manual or automated". SiBr4 (talk) 12:55, 3 January 2015 (UTC)[reply]
Yes indeed, I was wrong. Zhaofeng Li [talk... contribs...] 01:36, 4 January 2015 (UTC)[reply]
Yes, you can stop these "unnecessary" notifications. Go to your settings, click on the notifications tab and untick the tickbox under web and next to edit revert. While you are at it, you might as well go over all of your notification settings.--Snaevar (talk) 11:45, 3 January 2015 (UTC)[reply]
Thanks. So there is no way to stop just that particular type of notification. I don't want all of the edit revert notifications to stop. I just want the false ones, like in the above example, that aren't actually reverting my edit to stop. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 12:06, 3 January 2015 (UTC)[reply]
Definitely seems like a bug. I think I've flagged this on Phabricator (but it's the first time I've used it...) - T85728. Andrew Gray (talk) 12:33, 3 January 2015 (UTC)[reply]
Yes, you did a good job, Mr. Gray. :D — {{U|Technical 13}} (e • t • c) 14:26, 3 January 2015 (UTC)[reply]
Thanks all. CambridgeBayWeather (mobile) (talk) 19:22, 3 January 2015 (UTC)[reply]

Looking for unreferenced articles across muliple categories

Can anyone help with a quick way to look across multiple categories for unref'd articles? I'm looking for any Olympic-related article that is currently unref'd. For example, this article was in this state before I sourced it. It was in two categories that contain the word "Olympic" along with the Category:All articles lacking sources. Can this be done? Thanks. Lugnuts Dick Laurent is dead 13:15, 3 January 2015 (UTC)[reply]

CirrusSearch for incategory:"All articles lacking sources" insource:/\[\[Category:.*Olympic.*\]\]/ gives 184 articles. I don't know if that finds all conforming articles; I suspect not. SiBr4 (talk) 13:30, 3 January 2015 (UTC)[reply]
CatScan will also help, giving better results. Zhaofeng Li [talk... contribs...] 13:36, 3 January 2015 (UTC)[reply]
Thanks. How do I do a wildcard search in Catscan? Lugnuts Dick Laurent is dead 13:43, 3 January 2015 (UTC)[reply]
It's probably easier to do a tree search (ie, anything in a subcategory of "Olympic Games"). This search (928 pages, will take ~50s to run) goes five levels deep below the original OG category. Andrew Gray (talk) 13:48, 3 January 2015 (UTC)[reply]
Alternatively, this one (528 pages, 24s to run) is anything in the lacking sources category with a WP Olympics talkpage banner. Andrew Gray (talk) 13:56, 3 January 2015 (UTC)[reply]
Nice one! THanks. Lugnuts Dick Laurent is dead 18:20, 3 January 2015 (UTC)[reply]

Double exclamation points problematic for Dashboard table

Noticed the village pump section of the Dashboard was broken (this version). Looks like the problem is the double exclamation points in one of the section headings breaking the table. For now I replaced them with html codes, so when Legobot next updates the template it should be ok (I think), but what would be the best way to fix this for the future? --— Rhododendrites talk \\ 21:33, 3 January 2015 (UTC)[reply]

Happened before, and there is no quick fix. The exclamation points are mistakenly parsed as table markup. Bast action is just to remove the exclamation marks. -- [[User:Edokter]] {{talk}} 22:41, 3 January 2015 (UTC)[reply]
@Rhododendrites: Yes, table markup can produce two kinds of cell - data cells, where a line begins with a single pipe; and header cells, where a line begins with a single exclamation mark. In both cases, a second cell may be defined without starting a new line by using a double symbol. WP:W is essentially a table, with content transcluded from elsewhere; so if the transcluded content includes wiki markup, that markup will be processed as if it had been typed directly into the page. Since it's a table, any occurrence of either || or !! will be treated as the end of one cell and the start of the next. --Redrose64 (talk) 00:59, 4 January 2015 (UTC)[reply]

IPv6 edits

As I'm sure many people do, when I see an edit by an IP on my watchlist, I check the edit. For IPv4 IP addresses, everything works as expected. The issue I have is with IPv6 addresses. If I see that they've made more than one edit, I will then click on "Next-to-last editor" to view all of the changes they made. This never works as expected for IPv6 IPs though. Instead, I get something like this where both the current and previous edits are the same, most recent, edit. Is this issue known about? I've seen it on different OSs, on different computers, and with different browsers. Dismas|(talk) 02:49, 4 January 2015 (UTC)[reply]

Just to confirm, you're using User:DerHexer/revisionjumper, correct? Sounds like a bug that will have to be fixed within the script. ~SuperHamster Talk Contribs 02:55, 4 January 2015 (UTC)[reply]
Yes, that's what I'm using. Dismas|(talk) 03:14, 4 January 2015 (UTC)[reply]

Watchlist on Wikipedia for Android mobile phones is no longer under the top right left pull down menu

I noticed that today, the watchlist on Wikipedia for Android mobile phones is no longer under the top right left pull down menu. Does anyone know what happened? --Jax 0677 (talk) 03:13, 4 January 2015 (UTC)[reply]

User:Deskana (WMF) probably knows what's going on. Did you make sure that you're still logged in? Whatamidoing (WMF) (talk) 22:50, 4 January 2015 (UTC)[reply]
@Jax 0677: Are you accessing Wikipedia through your phone's browser, or on the app? For the former, I've tested it on my Android device and verified that the watchlist is accessible, so I'll need more details in order to reproduce the issue, such as the kind of phone you're using, such as the model, Android version, and browser. For the latter, the watchlist feature has never actually existed on the Android app, and we're presently not working on adding it in as our current work focuses around readership rather than editorship. Hopefully that helps! Let me know if you have any questions. Thanks! --Dan Garry, Wikimedia Foundation (talk) 00:27, 5 January 2015 (UTC)[reply]
Reply - @Deskana (WMF):,@Whatamidoing (WMF): I am using a web browser to access the mobile phone Wikipedia site on my Samsung Galaxy S3 telephone that I bought in 2012. I am not sure how to determine the browser and android version, but the browser does allow me to utilize multiple windows. --Jax 0677 (talk) 14:57, 5 January 2015 (UTC)[reply]
Mozilla/5.0 (Linux; U; Android 4.4.2; en-us; SCH-I535 Build/KOT49H) Apple Webkit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30 --Jax 0677 (talk) 18:19, 5 January 2015 (UTC)[reply]

@Jax 0677: Can you take a screenshot of what the left menu looks like? That may help us diagnose the problem. This screenshot shows what it looks like on my device (Nexus 5, Android 5.0, Chrome). Thanks! --Dan Garry, Wikimedia Foundation (talk) 18:56, 5 January 2015 (UTC)[reply]

Reply - @Deskana (WMF):, I do not know how to take a screen shot of my phone. However, my screen looks similar to that one, except there are no icons left of "Home", "Random" and "Settings". "Jax 0677" replaces "Login" (there is no icon left of it either). There are no rows for "Nearby" and "Watchlist". --Jax 0677 (talk) 22:55, 5 January 2015 (UTC)[reply]

Archiving

I am not sure if I am in the right part of WP Help. I have got into a tangle with archiving my Talk page.

  1. For the last archive I created, number 4, it always showed duplicated as the current Talk page, I think because that time I had tried to set up a bot to do the archiving and it went wrong. So for a while I had current Talk page and Archive 4 that were the same, and there was a redirect, which I must have created but don't know how.
  2. On trying to sort all this out now, I could not see how to remove the redirect, and with some juggling and attempted reverting (which couldn't be done because of intervening edits) have now lost Archive 4 altogether. It is still in the edit history, of course, but I don't know how to retrieve it to make a new Archive 4 and a new blank Talk page. Can someone help, please?
  3. In the new Archive 4 I want to keep all deleted sections that I assume were showing in the old Archive 4, but am not sure how this is done.
  4. I also want to steer clear of bots and go back to manual archiving, which is how I created the earlier archives. ~ P-123 (talk) 12:34, 4 January 2015 (UTC)[reply]
I saw your question at Wikipedia:Help desk before you moved it here. It was fine to post at the help desk. On December 25 you moved User talk:P-123 to User talk:P-123/Archive 4 and moved it back 5 minutes later.[6][7] This created a redirect from User talk:P-123/Archive 4 to User talk:P-123. I have copy-pasted an old revision of User talk:P-123 to User talk:P-123/Archive 4. See Wikipedia:Redirect#How to edit a redirect or convert it into an article. PrimeHunter (talk) 12:45, 4 January 2015 (UTC)[reply]
PrimeHunter Thank you very much for doing that. What about the deleted sections and deleted comments that I said I would like to keep in the archive? I cannot find them. Is there any way of looking in an edit history somewhere to find them?
Sorry, have found them. ~ P-123 (talk) 13:10, 4 January 2015 (UTC)[reply]
(edit conflict) I'm not sure which individually deleted sections and comments from https://en.wikipedia.org/w/index.php?title=User_talk:P-123&action=history you want to restore. You removed some of them with edit summaries like 'Rmv comment - will backfire', 'Rmd - patronising', 'Rmv intrusive "chat" among IPs', and the removals were interspersed with additions to other sections so it's complicated to sort out. If you want to archive a previously deleted comment or section then you must manully find a revision which contains it and copy-paste it to the archive. My archiving [8] had a url to the revision I copied completely. PrimeHunter (talk) 13:18, 4 January 2015 (UTC)[reply]
PrimeHunter: I assume it is only possible to restore removals to the archive and have them visible there. For example, if I wanted to transfer from edit history a removed comment to the archived thread, can I add it to that archived thread and then delete it so that it does not appear on that archived thread? ~ P-123 (talk) 13:38, 4 January 2015 (UTC)[reply]
  • P-123, you seem to have a misunderstanding of how archiving works. What you appear to believe is that the talk page and its archives are an intertwined system where when you do something to one page, an equal and opposite reaction automatically happens on the other side. This is not at all the case. Each page of the system is entirely its own thing. So, simply have the archive deleted and restore all of the sections that were archived from your talk page from its history. I'd be happy to get you back to ground zero if you like. — {{U|Technical 13}} (e • t • c) 14:29, 4 January 2015 (UTC)[reply]
Technical 13: No, I did realise they were separate systems, but was unclear about how deletions from the current page could be archived along with the current page. It would be much better to start Archive 4 afresh, but have no idea how to do that. Could you help, please? I can't understand the sentence starting "So, simply have the archive deleted ...". Once the archive is restored back to current page form, I could add back in the deletions, but I would want them deleted again in the archive so that they don't appear on the archive page. I will do any donkey work needed if you tell me where. ~ P-123 (talk) 14:54, 4 January 2015 (UTC)[reply]
  • First thing to do is to restore all the archived sections that you want to archive back to your talk page. Let me know when that is done and we can go from there. :) — {{U|Technical 13}} (e • t • c) 14:59, 4 January 2015 (UTC)[reply]
Technical 13: Have just done that. ~ P-123 (talk) 15:09, 4 January 2015 (UTC)[reply]
Technical 13: I didn't get your ping so went ahead and did it myself. Why does an admin have to delete? I can't retrace my steps to explain how I did it, but I managed to restore the deletes I wanted restored to the current Talk page, then archived it, then in the archive deleted the comments I didn't want to be visible, but they can be reached via the Edit Summary of the archive. Was that the right way to go about it? Once I had archived, I tried to delete the current Talk page which I had archived (as the last step in the archiving process) but whereas before I could do a global delete, this time I had to do them individually and cannot see why. I tried removing the code that normally goes at the top of the Talk page (the yes/no part) but it still didn't work, I couldn't delete all at once. Don't even try to make sense of the Edit Summaries for archive 4 and the Talk page I was archiving, as I was doing everything by trial and error! P-123 (talk) 19:00, 4 January 2015 (UTC)[reply]
You were going to explain how to archive by myself. I have always managed it before, but did not restore deletes before doing so, which is worrying as the archives won't be a complete record. There must be a simpler way of transferring the edit history of the Talk page to archive than the way I did it. P-123 (talk) 19:00, 4 January 2015 (UTC)[reply]
Technical 13: Got held up. Have done that. P-123 (talk) 20:22, 4 January 2015 (UTC)[reply]
Technical 13: Thanks for fixing it. I see you just have to click on "Archive" to archive the thread.
  • Does that "Archive" note appear every time a new thread is started?
*I experimented by clicking on the only thread there at the moment and it went to archive, but underneath where the old archive ended. Is that what should happen? (I restored it after experimenting.) I meant the note underneath the old archive where it says "Do not alter this archive", but having looked again, I must have misremembered, as there is no such note.
  • If I delete comments from a thread while it is on the Talk page, I presume they won't carry over when the thread is archived. I presume before you archive you have to restore those deletes. Is that right?
I haven't looked at the documentation yet but perhaps those things are explained there. ~ P-123 (talk) 21:10, 4 January 2015 (UTC)[reply]
  • 1) yes 2) yes, unless you toggle the script off (documented, doesn't work well in Chrome) 3) archive header notices should only be at the top of the page, so yes, it did what it was suppose to 4) correct. — {{U|Technical 13}} (e • t • c) 21:51, 4 January 2015 (UTC)[reply]
  • P-123, you may be interested in Template:1CA. This is a semi-automatic archiving script that allows you to archive sections in one click from your talk page to your archive page. I'll note that the live version currently doesn't support a maxarchive size, but the beta version does and that should be moved to live in a few weeks. I'd be happy to help you set it up, just ping me from your talk page. :) — {{U|Technical 13}} (e • t • c) 13:07, 4 January 2015 (UTC)[reply]
Technical 13: Thank you. That was going to be my next question! I will wait until the move has happened, and then ping you, in a week or two. ~ P-123 (talk) 13:26, 4 January 2015 (UTC)[reply]
Technical 13: I had better not try it myself. That is how I got into trouble the last time, trying to set up a bot to do the archiving, after learning how to do it here. If I may I will ask you to help once the move has happened in a week or two. ~ P-123 (talk) 13:43, 4 January 2015 (UTC)[reply]

Animated images

Tracked in Phabricator
Task T85838
Tracked in Phabricator
Task T85840

Animated GIFs, especially the more frantic ones, can be incredibly annoying when one is trying to read adjacent text (e.g. see example here). Rather than removing the image altogether, is there any way to have Wikipedia display one static frame until the user requests "play"? Any other good solutions to this problem? 86.136.150.215 (talk) 14:09, 4 January 2015 (UTC)[reply]

Actually, this sounds interesting. But I would rather "vote" for such feature as a gadget not enabled by default. --Edgars2007 (talk/contribs) 17:50, 4 January 2015 (UTC)[reply]
Thanks; I agree that it should be optional not default. I'm not totally sure what a "gadget" is, but if it's available only to logged-in users then I don't think this wouldn't be a satisfactory solution since the majority of ordinary users are (I assume) not logged in. I think that such a feature should be enabled on a per-image basis by editing the page, using some switch in the syntax that displays the image. 86.136.150.215 (talk) 18:35, 4 January 2015 (UTC)[reply]
See Wikipedia:Gadget; there are almost 70 of these on the English Wikipedia. Most are only available to logged-in users on an opt-in basis; but about ten are enabled by default for all users, and logged-in users may opt-out of these. --Redrose64 (talk) 19:58, 4 January 2015 (UTC)[reply]
All the bug reports that I saw in my search were about animated GIFs not annoying people being animated when people wanted them to be. I believe the usual thing to do is to handle this in the browser, although I'm not sure if that's even possible in Safari any longer. How would you like it to work in practice? Whatamidoing (WMF) (talk) 23:06, 4 January 2015 (UTC)[reply]
However annoying, animated GIFs displayed as animated would presumably never be logged as a bug since this is the designed/intended behaviour. I think, as I mentioned, that in an ideal world there would be a switch somewhere in the wiki-text syntax to allow editors to switch off automatic animation. The page would then display a static frame along with some kind of "Play" control to allow the reader to begin animation if and when desired. The default would be automatic animation so that existing pages would not change except by conscious editor decision. 86.136.150.215 (talk) 03:32, 5 January 2015 (UTC)[reply]
I don't think that will be sufficient to solve the reader's problem. What if the editors all decide that it's great to have this one animated by default, but I really, really want to turn it off while I'm reading that page? Whatamidoing (WMF) (talk) 05:56, 5 January 2015 (UTC)[reply]
Well, that's no worse than what happens right now of course, but I guess a "Stop" control could be added? 109.156.50.255 (talk) 12:48, 5 January 2015 (UTC)[reply]
I've started two feature requests for you; the numbers and links are in the boxes above. Anyone with other ideas (especially details about what it should look like) should feel free to add comments. Whatamidoing (WMF) (talk) 19:03, 5 January 2015 (UTC)[reply]
Thank you for your interest. 109.153.227.154 (talk) 14:53, 6 January 2015 (UTC)[reply]

parser functions generate extraneous linebreaks

Tracked in Phabricator
Task T14974

here is the scenario: i want some element to have background color depending on some condition. i try to do something like 

<div style = "background-color: {{#ifexpr: 0 < 1 | #aaaaaa | #bbbbbb }}" >

for clarity, i'll remove the "<div" part. what i get is

style = "background-color:

  1. aaaaaa"

similar problem with #if and #switch

  • is it a known issue? i ran some shallow search and did not find anything.
  • is there a clever way around it?
  • is there some "remove-linebreaks" template i can wrap around the #if to "flatten" the result? maybe some scribunto thing?

thanks, peace - קיפודנחש (aka kipod) (talk) 15:31, 4 January 2015 (UTC)[reply]

This is the parser mistakenly thinking you are trying to start a numbered list (using the # markup). Just move the hash out of the parser function: <div style = "background-color: #{{#ifexpr: 0 < 1 | aaaaaa | bbbbbb }}" >
Which should result in: background-color: #aaaaaa. -- [[User:Edokter]] {{talk}} 16:29, 4 January 2015 (UTC)[reply]
thanks. קיפודנחש (aka kipod) (talk) 16:39, 4 January 2015 (UTC)[reply]
This behavior is bug T14974, by the way. Matma Rex talk 16:57, 4 January 2015 (UTC)[reply]
It's also related to Help:Template#Problems and workarounds. --Redrose64 (talk) 17:54, 4 January 2015 (UTC)[reply]

Wikicode erros in Template:Rjukanbanen map

Template:Rjukanbanen map included in Rjukan Line is producing some errors. Could someone take a look at it? 94.175.114.220 (talk) 16:16, 4 January 2015 (UTC)[reply]

I managed to fix the obvious error (missing table start), but I'm not quite sure is the article is showing as it should. -- [[User:Edokter]] {{talk}} 16:43, 4 January 2015 (UTC)[reply]

Wrong footnote order in Menorrhagia

The footnote system in the Menorrhagia article assigns wrong numbers to the entries. For example, the last one in the list by A Shaw, Julia is number 8 in the list, but shows up as [3] in the article text. Besides, clicking the number in the article text neither shows the reference nor takes you to the list at the bottom. Perhaps we should simply convert to the usual <ref> </ref> system? Mikael Häggström (talk) 18:32, 4 January 2015 (UTC)[reply]

Indeed. I went ahead and did it: [9]. Matma Rex talk 19:02, 4 January 2015 (UTC)[reply]

Signature button: enter only four tildes

Hi,

according to Help:Edit toolbar the signature button in the panel should be entering only four tildes, but it enters two dashes and four tildes. Can I force the button to act as described, so it adds only ~~~~? Thank you. Wesalius (talk) 18:48, 4 January 2015 (UTC)[reply]

@Wesalius: No; altering it would make it inconsistent with all the other wikis which include two hyphen-minus characters (n.b. not dashes) in the button signature; also, it's been like that as far back as I can remember. It's far easier to fix the documentation, which was altered in this edit by Gareth (talk · contribs). --Redrose64 (talk) 20:10, 4 January 2015 (UTC)[reply]
Understood. Wesalius (talk) 20:23, 4 January 2015 (UTC)[reply]
(marginally relevant) personally, i prefer not to change what the button do (and anyway, i rarely use the button). however, several years back, some user(s) in hewiki asked to change it, and in a moment of boredom, i knitted the following script. it's very artificially tested. it's supposed to change the signature button's behavior to only inject four ~ chars, without the preceding dashes:
$(document).ready(function () {
mw.loader.using( 'ext.wikiEditor.toolbar', function () {
        var x = $("[rel=signature]").data('action');
        if (x && x.options)
                x.options.pre = '~~' + '~~';
});
});
peace - קיפודנחש (aka kipod) (talk) 17:44, 5 January 2015 (UTC)[reply]

MediaWiki:Titleblacklist not working

I'm not sure what is causing this, but MediaWiki:Titleblacklist is currently not functioning as intended; pages that are on the page can currently be created by any logged-in editor. I tested this theory with my test account earlier with a title that has about 30 consecutive capital letters, and I was given the option to create it. (I cannot use this account to test the blacklist since I have the template editor user right.) Is there a resolution to this issue, or is one in the works? Steel1943 (talk) 19:09, 4 January 2015 (UTC)[reply]

Could this be related to #Access rights failure above? --Redrose64 (talk) 20:00, 4 January 2015 (UTC)[reply]
As I read it, the consecutive caps restriction is applied to page moves only? Zhaofeng Li [talk... contribs...] 13:15, 5 January 2015 (UTC)[reply]
By the way, I was also given the option to create this. Zhaofeng Li [talk... contribs...] 13:17, 5 January 2015 (UTC)[reply]
MediaWiki:Titleblacklist includes:
.*[^\p{L}\d ]{6}.* # Disallows six consecutive characters that are not letters (in any script), numbers, or spaces
My non-admin account could create User:PrimeHunter2/Test.............................. with 30 periods. Should that have been impossible? There were no warnings. PrimeHunter (talk) 14:26, 5 January 2015 (UTC)[reply]
@Redrose64: Looking at it, the two are probably related. Steel1943 (talk) 14:33, 5 January 2015 (UTC)[reply]
Another example of a blacklisted title I can create right now (with my test account) is here. Steel1943 (talk) 14:31, 5 January 2015 (UTC)[reply]
The Titleblacklist works now. Your example This shoe will die it not blacklisted as a pagename. It is only blacklisted as a username for account creation with this entry:
.*will die.* <newaccountonly>
Now that the blacklist is working, my non-admin account cannot create User:PrimeHunter2/Test...... with 6 periods. My admin account gets a warning before creating the page. PrimeHunter (talk) 16:42, 5 January 2015 (UTC)[reply]
The titleblacklist is failing again. I can now click User:PrimeHunter2/Test...... without getting a warning in my admin account, and without getting a message that I cannot create it in my non-admin account. PrimeHunter (talk) 20:40, 5 January 2015 (UTC)[reply]
Ah, I misunderstood that entry. Steel1943 (talk) 22:16, 5 January 2015 (UTC)[reply]
I am getting a message with my admin account about blacklisting for Category:Category:Cats, and I can't get a create page for it with a non-admin account. Note that this comes with a special message (MediaWiki:Titleblacklist-custom-double-category-prefix), don't know if this is relevant. עוד מישהו Od Mishehu 22:12, 5 January 2015 (UTC)[reply]
Yeah, looks like the title blacklist is working again; I get a warning message while trying to create ''''. However, this isn't the first time that I have noticed the title blacklist having issues in the previous couple of months; I'll bring this if I see the issue happening again. Steel1943 (talk) 22:16, 5 January 2015 (UTC)[reply]

Is there a tool that can tell me what pages link to a particular section of a page? That is, instead of merely linking to Foo, a link to Foo#Bar? Oiyarbepsy (talk) 03:24, 5 January 2015 (UTC)[reply]

User talk

Is there (or is it possible to make) a list of user talk pages, sorted by size? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:34, 5 January 2015 (UTC)[reply]

Wikipedia:Database_reports/Talk_pages_by_size#Other_talk_pages, but it's about six months out of date. WhatamIdoing (talk) 19:08, 5 January 2015 (UTC)[reply]
Wasn't there a report on Labs that did this ? http://tools.wmflabs.org/betacommand-dev/reports/Long_Pages.html  ?

ShakespeareFan00 (talk) 19:21, 5 January 2015 (UTC)[reply]

Custom notices on user .js and .css pages

I recently found while attempting to use {{GitHub top icon}} on some of my scripts, which I have made available for bug reporting and pull requests on GitHub, that only pages in MediaWiki: currently transclude the page's editnotice. I started a discussion on MediaWiki talk:Clearyourcache#Protected edit request on 31 December 2014 seeking to change this behavior. Mr. Stradivarius respectfully declined the direct request and suggested that I propose the question here.

Since MediaWiki: pages already use the editnotice for this behavior, my first inclination is that this is the best way to go. Edit notices are protected by the TBL and only Template editors, Account creators (for now), Administrators, and the editor who's userspace they are in can edit them. This seems logically the best place to me, but I also thought that maybe a /doc or /header subpage might be preferable by some editors if we don't want/need to protect the documentation pages in that way. I look forward to hearing back from the community to see if that level of protection is needed for these transclusions and if there are any preferences for what the page name should be.

An option that I'm just thinking of to meet the best of both worlds is to transclude the editnotice and allow the editor to transclude the subpage if they want others to be able to edit the documentation. This could probably be done with greater consistency through a template for what the community agrees such a subpage name should be in those cases. Since /doc is already used for templates and modules, that seems the logical choice if this is the option agreed upon. — {{U|Technical 13}} (e • t • c) 14:38, 6 January 2015 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=641248977"