Wikipedia:Village pump (technical): Difference between revisions

Policy

Technical

Proposals

Idea lab

WMF

Miscellaneous

• Table of contents
• First discussion
• End of page
• New post

Shortcuts

• WP:VPT
• WP:VP/T
• WP:TECHPUMP
• WP:PUMPTECH

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (see how to report a bug). Bugs with security implications should be reported to securitywikimedia.org or filed under the "Security" product in Bugzilla.

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.

view · edit Frequently asked questions (see also: Wikipedia:Technical FAQ) Click "[show]" next to each point to see more details. If something looks wrong, purge the server's cache, then bypass your browser's cache. This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown. No, we will not use JavaScript to set focus on the search box. This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences. No, we will not add a spell-checker, or spell-checking bot. You can use a web browser such as Firefox, which has a spell checker. If you have problems making your fancy signature work, check Help:How to fix your signature. If you changed to another skin and cannot change back, use this link. Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem. If an image thumbnail is not showing, try purging its image description page. If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear. For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217

The clickable button templates, {{clickable button}} and {{clickable button 2}}, among others, have been broken for a few weeks. I assume this was due to a css or js change or the like. Compare the working buttons on Commons: commons:Template:Clickable_button. Anyone know how to fix these?--Sage Ross (WMF) (talk) 15:44, 22 November 2013 (UTC)[reply]

I assume you're referring to the lack of "button" styling? Interestingly enough, [1] makes the buttons there render correctly, but they are unstyled when not in edit mode. Chris857 (talk) 15:49, 22 November 2013 (UTC)[reply]

Yes. And I just noticed the same thing, that they show up correctly in previews.--Sage Ross (WMF) (talk) 16:07, 22 November 2013 (UTC)[reply]

They currently work for me in all tested situations. There is a previous discussion at Wikipedia:Village pump (technical)/Archive 120#Dark blue over the word "wikicode" to the point where I can hardly see it. PrimeHunter (talk) 16:41, 22 November 2013 (UTC)[reply]

jQuery.ui is no longer loaded by default. See Wikipedia:Village pump (technical)/Archive 119#jQuery UI CSS may no longer load by default and linked mailing list post. Anomie⚔ 16:50, 22 November 2013 (UTC)[reply]

Thanks, that's helpful. Is there a fix, or are we just stuck waiting until the switchover is complete? (Or do we just need to deprecate these buttons?)--Sage Ross (WMF) (talk) 20:01, 22 November 2013 (UTC)[reply]

Well we can fix them. But it adds again to the stack of javascript. So I guess the question is: Why do we need them with this styling ? —TheDJ (talk • contribs) 20:41, 22 November 2013 (UTC)[reply]

Personally, I'd think having transclusion counts of 869 and 76,859 respectively would be enough of a reason to make sure these templates are working and continue to be supported, no? Technical 13 (talk) 21:01, 22 November 2013 (UTC)[reply]

Why use JavaScript? It can be done with CSS alone. CSS is generally less of a burden for browsers then JS, and works for people who have JS disabled. CSS pseudo-classes can be used in MediaWiki:Common.css, which allow for different formatting when the user hovers over the button (:hover), clicks on the button (:active), or gives the button keyboard focus (:focus). – PartTimeGnome (talk | contribs) 23:17, 22 November 2013 (UTC)[reply]

Well sort of my point. They no longer work, because jquery-ui is no longer needed by the core on every single page (and getting rid of unneeded dependencies is a good thing). So to bring them back, you either need to load all that CSS again (either all the time, or with JS only when there are buttons on the pages), or you decouple them from jquery-ui and implement some 'light' CSS on en.wp that doesn't have so much overhead and provides similar functionality. I'm not sure where these buttons are used, which contexts, which users, so it's a bit tough to call for me. —TheDJ (talk • contribs) 18:50, 23 November 2013 (UTC)[reply]

• I am unsure why the two templates aren't merged into one easy to use with advanced features template. I really don't care how they are supported and work, and even as a TE I don't have access to modify MediaWiki: namespace stuff, especially Common.* (which I would expect that even if MediaWiki: was added to something the could be edited by TE's in general would be fully protected anyways). So, what I'm thinking is, if you can get consensus to make {{Clickable button}} (with or without {{Clickable button 2}} merged into it) work with css in the MediaWiki:Common.css then go for it. Technical 13 (talk) 02:35, 23 November 2013 (UTC)[reply]
• I noticed that the buttons look fine on User:TheJJJunk, but not on User:GoingBatty. I'm using FF25. GoingBatty (talk) 02:35, 25 November 2013 (UTC)[reply]

@GoingBatty: They look fine to me on both our pages. Maybe this got fixed by the time I saw this. — TheJJJunk ^{(say hello)} 15:03, 25 November 2013 (UTC)[reply]

It works on both of those pages for me as well, but not on many others (for example, {{welcome student}}). It just depends on whether something else on the page causes the required code to be loaded, I guess.--Sage Ross (WMF) (talk) 15:15, 25 November 2013 (UTC)[reply]

Hmm, the button on that page appears correctly for me as well. Even before it was switched to clicakablebutton 2. I tried adding a button on my sandbox, and that also displays correctly. I must be special. Or I have a user preference set or a script that activates it? — TheJJJunk ^{(say hello)} 15:37, 25 November 2013 (UTC)[reply]

I'm guessing what people seem to be experiencing where some buttons seem to work for some but not others is due to caching issues (at least we are going to blame it on that because it makes such a good scapegoat). Try BYPASSing and see if they still don't seem right. Technical 13 (talk) 16:28, 25 November 2013 (UTC)[reply]

I've bypassed and cleared my caches on FF25 and IE10, and User:GoingBatty still doesn't show clickable buttons for me. :-( GoingBatty (talk) 01:42, 26 November 2013 (UTC)[reply]

I've tried another computer with IE8, and I don't see the clickable buttons whether I'm logged in to WP or not. GoingBatty (talk) 14:17, 26 November 2013 (UTC)[reply]

It seems much more likely to me that the reason people see different results, is because they have different gadgets/scripts enabled, which might be loading the code that the clickable button requires. —TheDJ (talk • contribs) 15:12, 26 November 2013 (UTC)[reply]

The buttons work for me, so I logged out, and they didn't work. When logged in, I commented out all my imported scripts and blanked my .css page, and the buttons still worked. Gadgets then? — TheJJJunk ^{(say hello)} 15:22, 26 November 2013 (UTC)[reply]

@TheJJJunk: Do you mind sharing what gadgets you have enabled? Thanks! GoingBatty (talk) 16:02, 29 November 2013 (UTC)[reply]

These are all of the options I have enabled in the Gadgets section of my Preferences:

• After rolling back an edit, automatically open the contributions of the user whose edit has been rolled back
• Open external links in a new tab/window
• Twinkle
• "Ask a question" feature for the Wikimedia Foundation's "Teahouse" project
• Reference Tooltips
• Citation expander
• HotCat, not checked in the gadgets, but imported through a script
• Form for filing disputes at the dispute resolution noticeboard
• CharInsert
• Add an [edit] link for the lead section of a page
• Add a "Sandbox" link to the personal toolbar area.
• Display diffs with the old yellow/green colors and design.

If you want to go through the scripts I have included as well, I have some on my common.js and vector.js I think. — TheJJJunk ^{(say hello)} 17:51, 29 November 2013 (UTC)[reply]

Aha - enabling Twinkle fixes the clickable button, and disabling breaks it again. Anyway to have the button work without using Twinkle? I also noticed that with Twinkle disabled, the buttons don't appear when I'm reading User:GoingBatty, but they do appear in edit preview mode. Thanks! GoingBatty (talk) 00:03, 2 December 2013 (UTC)[reply]

As Anomie said way up, jquery.ui is no longer loaded by default, and the button relies on some of its styles.
Unsurprisingly activating a gadget that requires jquery.ui (like Twinkle) will make the styles available, and I assume the editing toolbar also uses jquery.ui which explains why it happens to work there.
Amalthea 10:13, 2 December 2013 (UTC)[reply]

Since we weren't getting anywhere, i've proposed to add the most efficient loader that I could come up with to fix this problem. —TheDJ (talk • contribs) 13:12, 2 December 2013 (UTC)[reply]

I have a potential solution here. Kaldari (talk) 19:20, 3 December 2013 (UTC)[reply]

Thanks to both of you! Today I see the buttons just fine on User talk:ChrisGualtieri, but still don't see them on User:GoingBatty. GoingBatty (talk) 03:13, 7 December 2013 (UTC)[reply]

It used to be that you could click on a "^" next to a reference and it would direct you back up to where the citation is from in the text. Those carets have disappeared, at least for me. Was there a change recently? --Coemgenus (talk) 22:00, 24 November 2013 (UTC)[reply]

You didn't give an example so I don't know whether you are looking at an article using another reference system, but I see "^" at for example Thomas F. Bayard#References. If a reference is used more than once then "^" is not a link. Instead there are letters linking to each use. PrimeHunter (talk) 22:20, 24 November 2013 (UTC)[reply]

OK, it must be a problem on my end somehow, because that article isn't working for me. I held CTRL and hit reload and they appeared for a second, then vanished. Using Chrome browser. --Coemgenus (talk) 22:23, 24 November 2013 (UTC)[reply]

All right, it came back when I disabled the "Near this page" beta feature. That's a bug, I guess. Is there someplace I should report it? --Coemgenus (talk) 22:29, 24 November 2013 (UTC)[reply]

Bugs should be reported at mw:Talk:Beta Features/Nearby Pages. -- John Broughton (♫♫) 22:42, 24 November 2013 (UTC)[reply]

According to mw:Talk:Beta Features/Nearby Pages#Disrupts footnote linking from reflist to article footnotes there is already a fix in gerrit:97143 but I guess it hasn't been deployed yet. PrimeHunter (talk) 00:28, 25 November 2013 (UTC)[reply]

I'm guessing that this problem is related to "Reference problem" up above, but that section is too vague for me to be sure. As long as I can remember, the reflist has had a ^ next to each number, which when clicked takes the reader to the spot where that citation is referenced; or when <ref name=whatever> and <ref name=whatever /> are used, we get a series of letters (a, b, etc.), each of which will take the reader to the reference spot when clicked. Within this month (seemingly in the last week or two) these have disappeared without warning or explanation; any idea what's going on? It's plainly a skin problem: these letters are missing when I view pages in Monobook with Firefox 25.0.1 and with IE 8, but when I use Vector, both browsers display the links properly. Nyttend (talk) 01:45, 30 November 2013 (UTC)[reply]

Have you enabled "Near this page" at Special:Preferences#mw-prefsection-betafeatures? If so, does it help to disable it? PrimeHunter (talk) 02:23, 30 November 2013 (UTC)[reply]

I've never checked the beta features, given the mess they made of removing the orange bar. I was completely unaware that the "Near this page" even existed, so no, I've not enabled it. Nyttend (talk) 17:28, 30 November 2013 (UTC)[reply]

I forgot to specify that for the same period of time I've been having what otherwise would seem to be an unrelated problem. Whenever I go to a category with subcategories, I've traditionally been able to find the sub-subcategories by clicking the little arrow next to the name of the subcategory. However, for the last week or two, clicking the little arrow always produces a message of "Problem loading data. Please wait a moment and try again." The second sentence is a link that effectively refreshes the category page. Has anyone else witnessed such a problem? Nyttend (talk) 17:55, 30 November 2013 (UTC)[reply]

What happens if you log out and view https://en.wikipedia.org/wiki/Thomas_F._Bayard?useskin=monobook#References and https://en.wikipedia.org/wiki/Thomas_F._Bayard?useskin=vector#References? In Firefox 25.0.1 I see ^ in both MonoBook and Vector, both logged in and out. PrimeHunter (talk) 20:35, 30 November 2013 (UTC)[reply]

I see everything properly when logged out, and when I view them in Vector while logged in, things are just as wrong as when I'm in Monobook. I didn't feel like switching skins just for this, so I'd been logging out before in order to use Vector; I never knew about the ?useskin thing. Time to check my preferences, I guess. Thanks for diagnosing it! Nyttend (talk) 14:11, 1 December 2013 (UTC)[reply]

Reference backlinks are missing:

This is page content.<ref>LibreOffice For Starters, First Edition, Flexible Minds, Manchester, 2002, p. 18</ref>
{{reflist}}

--  Gadget850 ^talk 01:17, 6 December 2013 (UTC)[reply]

I see the backlink in your example and in articles but I guess you have the issue in #Reference problem. PrimeHunter (talk) 01:50, 6 December 2013 (UTC)[reply]

Replication lag is now at over three weeks and counting. Any assistance with this problem would be much appreciated. DavidLeighEllis (talk) 01:29, 27 November 2013 (UTC)[reply]

WMF+WMDE have chosen to axe the Toolserver, so most people have given up and don't care. You can use Labs: [2]. Legoktm (talk) 06:26, 27 November 2013 (UTC)[reply]

Thank you. DavidLeighEllis (talk) 15:06, 27 November 2013 (UTC)[reply]

Would it be possible to add a notice to the old version, so people know?--S Philbrick(Talk) 17:41, 27 November 2013 (UTC)[reply]

Actually, before tool server dies, we intend to turn it into a redirect page to let everyone know to change their links to point to labs.—cyberpower _Online^{Merry Christmas} 14:04, 1 December 2013 (UTC)[reply]

And has anyone else noticed that X!'s editcount tool on labs hasn't been accessible for a couple of days? Jared Preston (talk) 16:42, 5 December 2013 (UTC)[reply]

I haven't been able to access it recently either... DavidLeighEllis (talk) 21:51, 5 December 2013 (UTC)[reply]

The counter seems to be up and running now. DavidLeighEllis (talk) 23:19, 6 December 2013 (UTC)[reply]

Hello all. I have outlined an idea at m:Grants:IEG/Automated inventory pages for all WikiProjects. The gist of the idea is this: a nice page, inspired off of the wikiHow model, should exist for each WikiProject, in order to keep track of all cleanup templates. In hindsight, I shouldn't have applied for the grant without already having technical expertise lined up, but I've been convinced this is a good idea for all WikiProjects for almost 18 months now. Does anyone with technical expertise think they might like to be hired to work on this project? I need to find technical assistance for the idea to succeed. I will likely re-submit the grant in the beginning of 2014. Thanks. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 15:19, 27 November 2013 (UTC)[reply]

• Biosthmors Like what I was trying to do at Template:Page reports? If I had better on wiki support there wouldn't be a need for the grant and I could have it operational within 14 days. Werieth (talk) 15:25, 27 November 2013 (UTC)[reply]
  • Thanks for working towards this Werieth. I'm OK with whatever it takes to get the job done. =) Is this tracked in Bugzilla? I know User:Ragesoss is good with templates. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 15:32, 27 November 2013 (UTC)[reply]
    • It has nothing to do with bugzilla. It would be a bot. Getting that functionality into Mediawiki and wikipedia wont happen, those types of requests are too resource intensive. Werieth (talk) 15:35, 27 November 2013 (UTC)[reply]
      • Werieth, the WP:Teahouse happened, and I heard it used some Java. What about that route? Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 16:07, 27 November 2013 (UTC)[reply]
      • User:Jtmorgan mentioned that to me, if I remember correctly. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 16:12, 27 November 2013 (UTC)[reply]
        • Teahouse uses JavaScript for the most part. Don't worry about the technical aspects, I can implement the features you want and more. Take a look at what I was trying to do at Template talk:Page reports. If you can develop and implement the on wiki part, getting the backend is easy. Werieth (talk) 16:19, 27 November 2013 (UTC)[reply]
          • @Werieth: Can you give me a brief summary of what on-wiki work needs doing? I'm getting information overload from that talk page. — Mr. Stradivarius on tour ^{♪ talk ♪} 08:49, 28 November 2013 (UTC)[reply]
            • @Mr. Stradivarius on tour: basically we need to define a template, and the associated parameters that go with it in order to get the data that you want. Take User:Werieth/Request as an example. There is a non-visible template at the top, which basically creates a list of all articles in WP:MED and Category:All articles lacking sources (AKA all unsourced articles within the wikiproject) Given the flexibility that I envisioned we could create reports that enabled us to filter a list of pages on basically any of a multiple set of criteria. I can easily handle the parsing/generating the datasets, However getting it setup on wiki, defining what reports should be created and where those reports should be saved to, along with any other associated information that might be needed. Werieth (talk) 03:01, 30 November 2013 (UTC)[reply]

User:Mr. Stradivarius on tour, any ideas? Best. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 01:44, 4 December 2013 (UTC)[reply]

• FWIW, this pretty much already exists (but without all the prettification wikihow uses) as something maintained by Svick. See User:Svick/WikiProject cleanup listing. Example: WP:HOCKEY. Resolute 04:37, 4 December 2013 (UTC)[reply]
  • Holy smokes that's useful. Thank you for pointing it. The fact that the data is also downloadable as CSV and the source code is available makes the prospect of building an automated dashboard of some kind much easier. FWIW, I don't think anyone working at WMF is going to jump on developing this immediately, but we're supportive of providing better data to editors about which articles need help in certain topic areas. From our perspective, it's not just about helping WikiProjects. Having good data available about which articles need what, segmented by WikiProjects/topics, might help us build a system that directs newbies to help out in an area they're interested in. Steven Walling (WMF) • talk 06:02, 4 December 2013 (UTC)[reply]
    • I agree. I've had to argue pretty loudly in the past about the value of project-specific lists such as this. The unsourced BLP gongshow in 2010 was a prime example of just how well it works. Resolute 20:53, 4 December 2013 (UTC)[reply]

Hello.

Could someone help identify where there's an unnecessary line-break in {{Year in Norway}}. The line-break is transcluded, which makes the articles that use the template look a bit awkward.

Thanks.

HandsomeFella (talk) 11:35, 3 November 2013 (UTC)[reply]

I removed some line breaks between categories that seemed extraneous, which fixes the issue in tests, but the whitespace is still showing up when this template is used just after {{Use dmy dates}} (as seems to be the case with most of its uses). equazcion → 11:59, 3 Nov 2013 (UTC)

This seems to be caused by the line break in the code before the wikitable begins. Since that wikitable code needs to be at the beginning of its own line, I can't find a way to get rid of the whitespace, aside from chopping off everything that comes before it (which does effectively remove the whitespace in these articles, FYI). This seems like it might be a common issue for templates so maybe someone knows of a solution I'm unaware of. equazcion → 12:07, 3 Nov 2013 (UTC)

I think there is at least some improvement. Thanks for trying. HandsomeFella (talk) 14:29, 3 November 2013 (UTC)[reply]

I've managed to fix it. That was a tricky one. A single line break before the table is fine, the problem was caused by having two consecutive line breaks before the table. The first line break is not in the template itself, but in the articles that use it (between the {{Use dmy dates}} and {{Year in Norway}} templates). The fix was to put something between those line breaks to stop them being consecutive, but that doesn't cause a visible gap itself. An empty <nowiki/> tag did the trick. – PartTimeGnome (talk | contribs) 16:33, 3 November 2013 (UTC)[reply]

The real problem was the text before the beginning of the table, which introduces a whiteline before the {| class=. See the warning about whitelines on WP:NOINCLUDE. I moved the text to the beginning of the template, and removed the <includeonly> tag. The obvious minus being that the page Template:Year in Norway itself now looks ugly. Debresser (talk) 09:08, 5 November 2013 (UTC)[reply]

I think you've misunderstood the warning at WP:NOINCLUDE. It refers to white space before <noinclude>, after </noinclude>, after <includeonly> or before </includeonly>, warning that said white space will be included in the template's output. There wasn't any white space on either side of the <includeonly> tags you removed. I tested re-adding them without making any other change, and the template still displayed correctly in the article 1972 in Norway (I didn't save this test).

Also, your changes moved text inside the table, but before the first table row, which is neither valid nor logical. The error text is intended to be shown outside the infobox, so should not be inside the table. Your changed worked in articles thanks to HTML Tidy fixing the invalid markup by moving it outside the table. If you'd tried this at Special:ExpandTemplates (where HTML Tidy does not run), invalid HTML is generated due to a <span> tag between <table> and the first <tr>. W3C's validator reports "Start tag span seen in table. Cannot recover after last error. Any further errors will be ignored.". (There are two other errors reported by the validator, but those are down to HTML generated by MediaWiki itself, unrelated to the template.)

Since your changes generated invalid HTML and messed up the appearance of the template page itself, I have undone them. (I completed your move of the category to the doc page. The doc page is the right place for categories.)

PS: I see you made several attempts before you found something you liked. Please don't make test edits on a live template. You can see what effect your changes will have on another page without saving by using the "Preview page with this template" options beneath the edit box. – PartTimeGnome (talk | contribs) 23:57, 5 November 2013 (UTC)[reply]

<includeonly>...</includeonly> is bad template engineering to begin with. You should just have a dummy default variable value in <noinclude>...</noinclude> tags in the #if conditional, like {{{1|<noinclude>dummy year</noinclude>}}}. Then you can include a default value for {{{1|}}} so that the template displays on its own page. VanIsaac_{WS Vex}^contribs 00:37, 6 November 2013 (UTC)[reply]

I agree with you completely that one template per line is the standard, and looks good. I was surprised you didn't see the whiteline: it is the break between the end of the remark about the red warning text and the beginning of the table with {|. That is why I moved the warning inside the template. Even conceptually, I think the warning is not out of place inside the template proper, as you claim above. The biggest minus I see is that the template page became real ugly. Debresser (talk) 01:17, 6 November 2013 (UTC)[reply]

Er... I did see that. See my first post in this section: "A single line break before the table...". As I think you realised, a line break is required before a table unless it is the first thing in the template. This is not normally a problem since a single line break does not create a gap; it is only when combined with another line break from the transcluding page that a gap appears. Since it is clearly no-one's intent that these two line breaks should combine to make a gap, I added the <nowiki/> to stop them combining. (Perhaps in a more logical markup language, code from inside and outside a template would not be allowed to combine like this.)

I think there might be an argument for showing the error message inside the table, but it would have to be done properly so it actually displayed inside the table rather than being moved out again by HTML Tidy. Another idea would be to replace the table with the error message, since nothing else in the template makes sense if the parameter was omitted.

The template page becoming ugly was more down to removing the <includeonly> tags (see my next reply). – PartTimeGnome (talk | contribs) 23:23, 7 November 2013 (UTC)[reply]

I know that the template becoming ugly was because the <includeonly> tags were removed. But that in its turn was done to remove the whiteline before the beginning of the template. You really don't need to speak with me as though I am making my first edit on intricate templates, and then perhaps you will also understand me better. Debresser (talk) 02:12, 8 November 2013 (UTC)[reply]

My apologies. I tend to be rather verbose, and I understand how I might seem like that. I'm not very good at adjusting my tone for the person I'm talking to. I do not consider you to be a beginner at template editing.

I guess you didn't see my other reply below? I already addressed your claim that removing the <includeonly> tags eliminated whitespace. (Sorry if I confused matters by making multiple replies in a single edit last night.) – PartTimeGnome (talk | contribs) 21:39, 8 November 2013 (UTC)[reply]

@PartTimeGnome See below (now above—PTG) for my response. Just wanted to mention here that I did not err in my reference to WP:NOINCLUDE, and it is precisely that whiteline issue I was referring to. Just that often people don't recognize the whiteline. Debresser (talk) 01:24, 6 November 2013 (UTC)[reply]

(I have moved your response above, to be immediately after the post to which you were responding.) One of us is misunderstanding that WP:NOINCLUDE bit, we both understand it but don't understand each other, or we're both thoroughly confused . I did test that taking your latest version of {{Year in Norway}} and re-adding the <includeonly> tags did not cause any gaps to appear. For example, see how that appears in "1972 in Norway", one of the articles that displayed a gap before either of us edited the template. – PartTimeGnome (talk | contribs) 23:23, 7 November 2013 (UTC)[reply]

Vanisaac, you make a good point. I've made the changes you suggested. I used {{CURRENTYEAR}} for the default value to show on the template page. – PartTimeGnome (talk | contribs) 23:23, 7 November 2013 (UTC)[reply]

The unnatural extra code can be avoided by moving the code generating the warning after the table. There will obviously not be a whiteline, while the warning will still be displayed in the same position. Debresser (talk) 01:53, 8 November 2013 (UTC)[reply]

That's interesting. This trick could fix the common problem that occurs whenever two "invisible" templates are placed at the top of an article. See the white space at the top of User:John of Reading/Sandbox. -- John of Reading (talk) 16:56, 3 November 2013 (UTC)[reply]

The first three templates in your sandbox all use {{Dated maintenance category}}. Adding a <nowiki/> to that template fixes the gap in your sandbox too. Before I make a protected edit request, can anyone think of any undesirable side effects this could cause? – PartTimeGnome (talk | contribs) 17:53, 3 November 2013 (UTC)[reply]

I would strongly oppose the addition of stray code to template. First of all because another user will surely remove it sooner or later, not knowing why it is there. Secondly, because it is ugly. It is against all rules of coding to do such things. But the main reason is that there is a simpler solution to the problem: put all the invisible templates right after each other without any spaces between them. See User:John of Reading/Sandbox where I did so and the whitespaces are gone. We could add a warning about this to the documentation of certain templates like {{Use dmy dates}} and others, but even if there would be an extra space, this is not a big problem. Debresser (talk) 11:42, 4 November 2013 (UTC)[reply]

Alternatively, since templates like {{use dmy dates}} or {{use British English}} do nothing except categorise, put them with the other cats - at the bottom. Any spurious blank lines which may be generated will be much less obtrusive in such a position. There is precedent for this, since templates like {{coord|display=title}} which place their output somewhere other than the actual position of the template, are typically placed at the bottom as well. --Redrose64 (talk) 11:52, 4 November 2013 (UTC)[reply]

Another thing that might artificially reduce the problem is adding the problematic templates to {{Multiple issues}}. Debresser (talk) 07:27, 5 November 2013 (UTC)[reply]

There are problems with that. {{multiple issues}} is for enclosing cleanup message boxes: requests to fix the article, to be removed when the fix has been done; when all have been done, and when there are none left to fix, {{multiple issues}} gets removed as well. By contrast, {{use dmy dates}} and similar are not requests to fix the article - they are permanent indicators of the article's writing style. If the article has no cleanup issues, and you add

{{multiple issues|
{{use dmy dates|date=November 2013}}
{{use British English|date=November 2013}}
}}

it looks kind of odd, see User:Redrose64/Sandbox5, it's got a blank area within the {{multiple issues}} box with the implication that there should be some message or other. --Redrose64 (talk) 15:41, 5 November 2013 (UTC)[reply]

You are right. Thanks. Debresser (talk) 21:07, 5 November 2013 (UTC)[reply]

Regarding someone possibly removing the code because it is not clear what it does, an <!-- editor comment --> will fix that. (I'd hope administrators would show more care editing a fully protected template, but maybe I hope for too much... )

On the point about ugliness, I agree, but I couldn't think of a better way to do it. There is much that is ugly about MediaWiki's markup language, so we often have to do ugly things to get the job done.

As for the "simpler" solution: good luck getting editors to use the templates all on one line. Many editors find placing each template on a separate line to be more intuitive, as evidenced by the many pages where this is the case. Generally, templates should be designed to be easy for editors to use, rather than expecting editors to adapt to their quirks. Templates should try to hide the complexities of wiki markup from the people that use them. One template per line is certainly easier to read. Keep the ugly stuff in a template so other editors don't need to worry about it.

One template per line is consistent with how categories are normally used (given the main purpose of the templates is categorisation): categories are typically one-per-line too. Also note that the current behaviour is inconsistent: where the template outputs a category, it is safe to use one per line. Where it outputs nothing, it will cause a gap. Code that looks fine in article space will show with gaps when copied to a user sandbox (because the categories are suppressed in userspace). – PartTimeGnome (talk | contribs) 23:00, 5 November 2013 (UTC)[reply]

I agree that templates are best placed on consecutive lines. I still strongly oppose the addition of code for the purpose of avoiding whitelines. It is a counter-intuitive non-solution. If the problem, i.e. a whiteline, should arise in any given article, it should be taken care of on an ad hoc basis, just like we did with the Year in Norway template. Debresser (talk) 17:07, 9 November 2013 (UTC)[reply]

It is counter-intuitive, but I don't think an intuitive solution exists. I don't think "non-solution" is the right word, since it does solve the blank line issue. Why should this be solved over and over on a case-by-case basis when it can be solved once for all cases? The editors using the templates might not know how to fix the unwanted blank lines. If we fix it in the template, they would never be troubled by the problem in the first place.

I don't know if you'll like this any better, but here's an alternative proposed edit for {{Dated maintenance category}}. (Here's John's sandbox example using the new version.) I've added comments explaining why the nowiki tags are there. Furthermore, because no blank line occurs when a category is output, the nowiki tag is only used if the template won't output any category. – PartTimeGnome (talk | contribs) 23:33, 10 November 2013 (UTC)[reply]

I called it a "non-solution" because it is only a workaround. The real problem is the existence of whitelines, in the code of the other templates or simply in the articles if the templates are placed on different lines. The alternative proposal is the same as the first, with an added explanation. — Preceding unsigned comment added by Debresser (talk • contribs) 08:00, 11 November 2013 (UTC)[reply]

It is a workaround, but it's better than nothing. I didn't think you'd like my tweaks any better, but figured I'd give it a try anyway.

I think it's too late for the ideal solution of modifying the wiki mark-up language to be more sensible. The real problem is the inconsistent behaviour: when the template outputs a category or a <nowiki/>, it can be used one-per-line without a gap (even though there is no visible output). When the template outputs nothing, the line it is on is treated as blank so causes a gap. My workaround resolves this inconsistency. I think the behaviour many editors expect is that a line with a template should not leave a gap unless the template contains a gap. – PartTimeGnome (talk | contribs) 22:57, 11 November 2013 (UTC)[reply]

Question: instead of outputting a non-intuitive <nowiki />, what would happen if it output a soft space? This should be possible using the HTML entity   --Redrose64 (talk) 00:31, 12 November 2013 (UTC)[reply]

Yes, that change works (tested with John's sandbox example). – PartTimeGnome (talk | contribs) 22:08, 12 November 2013 (UTC)[reply]

I agree that this is better than a closing tag without an opening tag, which was, as Redrose64 put it mildly, non-intuitive. Adding an explanatory remark also helps. Even though I prefer to keep the problem in some cases, when it can be removed by good coding of templates like we did with Years in Norway, I do see the advantages of removing the problem, even with a workaround. Debresser (talk) 00:38, 14 November 2013 (UTC)[reply]

That's not what I said. The post to which you refer states "a non-intuitive <nowiki />" - <nowiki /> is not a closing tag (which would be </nowiki>); it is an empty-element tag, one that opens and immediately closes - it is an element that has no content. The syntactic difference is that a closing tag has the slash first; an empty-element tag has the slash last.

I meant that by using <nowiki /> it is not clear what is intended. The normal use of nowiki is in a construct like <nowiki>[[link]]</nowiki> so that Wiki markup is not processed but displayed as plain text, so when somebody sees <nowiki /> which is exactly equivalent to <nowiki></nowiki> they might think "what's the point of preventing wiki markup from being processed when there's none actually there?" But by using   it's (I hope) clearer that something is intended, even if it's not obvious why a normal keyboard space has not been used. --Redrose64 (talk) 00:59, 14 November 2013 (UTC)[reply]

Thank you for the explanation. I indeed had not noticed the difference. Your explanation made me agree with your point no less. Debresser (talk) 11:07, 14 November 2013 (UTC)[reply]

I have reposted this section from the archive, in view of new information.

Please see this edit, that the two template Use dmy dates and Use Australian English in front of an infobox result in a whiteline only if there are no protection templates in the middle. Can anyone explain that?? Debresser (talk) 14:25, 28 November 2013 (UTC)[reply]

You commented out the protection templates, but did not comment out the line breaks on either side of them. Comments are discarded early in parsing, so what was left after removing the comment was a blank line. You would not have gotten a blank line had you started the comment at the end of the previous line, and finished it at the start of the next line. – PartTimeGnome (talk | contribs) 21:26, 28 November 2013 (UTC)[reply]

I understand. It is rather the other side of this that interests me. How come that the protection templates stop the whiteline from appearing? Debresser (talk) 00:45, 29 November 2013 (UTC)[reply]

Those templates do not expand to be empty. Their expansion shows that they add several categories to the page. – PartTimeGnome (talk | contribs) 22:41, 29 November 2013 (UTC)[reply]

That was my guess. I thought it would have to be actual text, but I see that not. Thanks. This perhaps opens a new solution to the problem above: do we have anything non-empty that does not do anything? I tried {{Void}}, but that didn't help. Any other ideas? Debresser (talk) 17:48, 30 November 2013 (UTC)[reply]

Well, my original suggestion of <nowiki /> fits the bill, and Redrose64's suggestion of   works too. Some empty XHTML tags such as <span /> also work. – PartTimeGnome (talk | contribs) 15:18, 1 December 2013 (UTC)[reply]

Then I say, let's do it, just that we need to add a remark with some explanation, to avoid other editors removing it, as discussed above. I still think it an ugly ad-hoc solution, but I see no better way. Debresser (talk) 19:03, 1 December 2013 (UTC)[reply]

Okay, protected edit request made! – PartTimeGnome (talk | contribs) 23:21, 2 December 2013 (UTC)[reply]

Hey, I have not been able to log in to my account "NahidSultan" for a while. Even though I enter the correct password, the page always returns "Incorrect password". I tried resetting the password through email several times, but right after I logged in with the email code and set my new password it returns to Special:UserLogin with the message "Incorrect password". I've opened a bug here --180.234.190.98 (talk) 08:22, 1 December 2013 (UTC)[reply]

Can anyone help in creating a list of all pages that contain Wikipedia articles in ref tags? Most probably a list of all pages that contain <ref>[[Foo]]</ref> and <ref>https://en.wikipedia.org/w/Foo</ref>. Wikilinks are accepted in references as part of footnotes. My aim is to clean pages that use wikipedia articles as references. I think if I do it by myself I'll get a lot of false positives. -- Magioladitis (talk) 14:37, 1 December 2013 (UTC)[reply]

I've posted a report at User:Magioladitis/wikiel that attempts to list what your after. - TB (talk) 23:32, 1 December 2013 (UTC)[reply]

TB Thanks! -- Magioladitis (talk) 00:04, 3 December 2013 (UTC)[reply]

I recently removed an outdated portion of a sporting standings table, by the updated but full table. Given that there are 20 teams in a league, the table is displayed in either of two ways -

• Display a portion of the table (Say only top 5 teams) in the relevant article, which looks better, but requires being updated at 20 locations
• Display the entire list in every article, making it unecessarily long, but requiring update at a single location.

Considering these two alternatives, I wonder if there is any way to re-organise this current format sere is a way to transclude the full list to display only the relevant portions of a table, using some set parameters? (For example, if the parameters are 1 and 5, then only the top 5 clubs are shown)? I think a hack like that could be useful for usage in many more sporting articles.

In short, all I want is a possible way to display {{2013–14 Premier League table}} so that only a portion of the table is shown, based on how you call the template. Is it possible?

TheOriginalSoni (talk) 23:42, 1 December 2013 (UTC)[reply]

Thanks to TheOriginalSoni for inviting me to this discussion. I agree that the best solution would be a centrally updated template with the ability to only show certain sections of the table when the focus of the article is a specific team; after all, there is no point showing the teams at the bottom when the focus is on the top. I would love to know if this is possible, although I'm sure it would take such intricate coding that it may not be worth making such a template when it would need updating every few days (and therefore more chance of breaking the template). – PeeJay 02:39, 2 December 2013 (UTC)[reply]

I made a test at {{2013–14 Premier League table/sandbox}} with code choosing which rows to display based on the already passed team parameter, so the season articles don't have to be updated when the team positions change. I had problems controlling pipes and newlines so the source isn't pretty. Here is how it looks with the parameter team=ALL:

Template:2013–14 Premier League table/sandbox

With team=ARS:

Template:2013–14 Premier League table/sandbox

With team=MNU:

Template:2013–14 Premier League table/sandbox

With team=CPA:

Template:2013–14 Premier League table/sandbox

You control which rows to display for each team by adding its 3-letter code to a switch statement for each of those rows. When team positions change, those codes have to be manually swapped around in the template. You can choose to display more than 3 rows by adding the team code to more rows. PrimeHunter (talk) 04:41, 2 December 2013 (UTC)[reply]

• PrimeHunter, The formatting of this truncated table is exactly how I expected it to be.

I also created a subpage at {{2013–14 Premier League table/sandbox/1}} with the text "Template:2013–14 Premier League table/sandbox/1" which I intended to replace at the code's switch expressions. You can see I've replaced one instance of ARS in the code to see that it works.

This way the places do not have to be replace everywhere on the table, making it less likely to break the code, albeit more clumsy. Also, whenever teams change positions, the respective subpages would have to be altered to have the correct rankings.

While this code works, I was kindof hoping for a less hacky of a way. Is there any way to do that?

TheOriginalSoni (talk) 06:09, 2 December 2013 (UTC)[reply]

As one (of very few) editing this template so far, I must say I really like this idea of having this table. A reason for having it is to have something that is continuosly updated, which do not happen on all club articles. To make it only show parts would be fantastic, then it would be better for each of the articles. If/when this is done some visual things maybe can be done (yellow color of team unneccesary?) to make it look even better.

My only concern is that it can not be to complicated to update, since that makes a bigger risk for errors. Today a lot of IP edit league table and if we should use it even on the main PL article with team=ALL then there could possibly be a lot of correcting to do. The more articles it is used in, the more editors will try and edit it. But in total I am very positive and I have tried editing in the sandbox above (just show preview, never saved it) and to me it is not that hard updating it, but I could imagine other editors "forgetting" to update the parameters of which rows to be shown. QED237 (talk) 12:03, 2 December 2013 (UTC)[reply]

User:PrimeHunter, I love you. This is exactly what I was expecting. Now to sort out some minor user-friendliness issues and it'll be perfect! – PeeJay 12:08, 2 December 2013 (UTC)[reply]

Thanks. 20 subtemplates like {{2013–14 Premier League table/sandbox/1}} for team positions would be impractical. I have changed {{2013–14 Premier League table/sandbox}} to get all 20 teams from {{2013–14 Premier League table/p}} by supplying a parameter for the position. PrimeHunter (talk) 13:04, 2 December 2013 (UTC)[reply]

• Looks good to go. Great work, PrimeHunter.

Could we use another less obstrusive colour, like #F5D44E to highlight? TheOriginalSoni (talk) 13:27, 2 December 2013 (UTC)[reply]

Might I suggest writing this in Lua? By moving it to Lua you could just input the wins, draws, losses, goals for, and goals against for each team, and then the template could automatically calculate the matches played, the goal difference, and the points. It could also automatically update each team's position in the table, and you could also pass a parameter to limit the number of entries. All the complicated bits could be put in the module, and the template invocation would look something like this:

{{#invoke:league table|premier
|limit = 5
|team1 = [[Arsenal F.C.|Arsenal]]
|team1_wins = 10
|team1_draws = 1
|team1_losses = 2
|team1_for = 27
|team1_against = 10
|team2 = [[Chelsea F.C.|Chelsea]]
|team2_wins = 8
|team2_draws = 3
|team2_losses = 2
|team2_for = 24
|team2_against = 11
...
}}

If there's any interest in this, I can try and code something up tomorrow. — Mr. Stradivarius ^{♪ talk ♪} 14:08, 2 December 2013 (UTC)[reply]

Mr Stradivarius, that sounds great. I'd like to see how that would look. – PeeJay 14:40, 2 December 2013 (UTC)[reply]

I don't edit league tables but it sounds great. You may need more parameters for a general module. Some leagues can give punishments where points are deducted from a team (they can even have a negative number of points). Automatic computation of positions would give complications with some tie rules like La Liga#Competition format. PrimeHunter (talk) 14:53, 2 December 2013 (UTC)[reply]

Okay so now there has been no edits for a while, what is the next step? Is there something more to be done? Should I we go to WT:FOOTY to find consensus for instering it on the team articles? QED237 (talk) 00:02, 6 December 2013 (UTC)[reply]

Yesterday I created an article about a controversial 1978 novel, entitled: "S: Portrait of a Spy". Articles that start with "S:" become interwiki links.

For now I entitled the article Portrait of a Spy (novel, 1978) -- but, if possible, I'd like to put it at the correct name. Geo Swan (talk) 15:52, 2 December 2013 (UTC)[reply]

It's only possible to have a colon when the left of the colon is not an interwiki prefix. See Wikipedia:Naming conventions (technical restrictions)#Colons. PrimeHunter (talk) 16:17, 2 December 2013 (UTC)[reply]

Leave the article where it is, but add {{Correct title|S: Portrait of a Spy|reason=:}} near the top. --Redrose64 (talk) 16:32, 2 December 2013 (UTC)[reply]

Now located at S – Portrait of a Spy. — Edokter (talk) — 16:34, 2 December 2013 (UTC)[reply]

And I see that Erwin had already added {{Correct title}} before I suggested it. Thanks, Edokter! --Redrose64 (talk) 16:37, 2 December 2013 (UTC)[reply]

• Thanks everybody! Geo Swan (talk) 01:59, 3 December 2013 (UTC)[reply]

I have made several edits to various pages, all without incident. Now, over the past 2 days, every time I try to comment on this talk page, I get the following message screen popping up;

Wikimedia Foundation

Error

Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes.

If you report this error to the Wikimedia System Administrators, please include the details below.

Request: POST http://en.wikipedia.org/w/index.php?title=User_talk:Shirt58&action=submit, from 208.80.154.136 via cp1055 frontend ([10.2.2.25]:80), Varnish XID 2620319949 Forwarded for: 24.212.213.146, 208.80.154.136

Error: 503, Service Unavailable at Mon, 02 Dec 2013 19:34:53 GMT

Initially, I had though that meant the edit was not saved (and I re-posted), but now it seems the edit is saved, immediately, but instead of showing you the page with the new content (and that little pop-up that says "Your edit was saved"), you instead get this message screen, and manually have to go to the page again.

Like I said, it only happens with the one account. Is this normal? - ^theWOLFchild 19:47, 2 December 2013 (UTC)[reply]

I see that error on a recurring basis. It seems that certain pages, and pages containing certain templates, are more likely to have this guy show up. My SOP is to just hit the back button, where my edit loads up just like I saved it, then I go up to the article tab, and left click - open in a new tab, to see if the edit went through. Probably 3/4 of the time, it did, so I just shut down the edit window tab, and continue on like the article tab was just the normal post-save view. VanIsaac_{WS Vex}^contribs 19:59, 2 December 2013 (UTC)[reply]

This often comes up on this page. See for example #Wikimedia error, site very slow, looks like when Internet first developed and some of the archive pages. Maybe I should put it into the FAQ. --Redrose64 (talk) 20:39, 2 December 2013 (UTC)[reply]

That page is quite large. Though wiki markup is fast to save, parsing it to create a HTML page can be slow for large and/or complex pages. If it takes too long to parse, you get this error. I've left a message for Shirt58 drawing this discussion to their attention and requesting that they archive the page. – PartTimeGnome (talk | contribs) 22:41, 2 December 2013 (UTC)[reply]

List of Nelvana programs is PC protected but https://en.wikipedia.org/w/index.php?title=Special%3ALog&type=&user=&page=List+of+Nelvana+programs&year=&month=-1&tagfilter=&hide_patrol_log=1&hide_review_log=1&hide_thanks_log=1 doesn't show that it was protected at any point. What am I misunderstanding? Josh Parris 20:41, 2 December 2013 (UTC)[reply]

If a page is moved, the logs are not moved too - they stay on the old name. It's a pain in the ass. --Redrose64 (talk) 20:52, 2 December 2013 (UTC)[reply]

That makes discovering the reason for protection... challenging... and thus doing appropriate review equally challenging. Josh Parris 21:06, 2 December 2013 (UTC)[reply]

Luckily, changes to the PC status are dual-recorded - see the page history. --Redrose64 (talk) 21:33, 2 December 2013 (UTC)[reply]

This particular trick needs writing down somewhere. Josh Parris 01:46, 3 December 2013 (UTC)[reply]

Pending changes logs should behave the way the regular protection logs do when a page is moved. I've filed this as bug 57912. Graham87 08:05, 3 December 2013 (UTC)[reply]

Obviously I can't since I am not an administrator. So the question is how to get someone to do it?

I posted on a talk page asking for a source, and I have reason to believe said talk page, along with its article, has been deleted. It had very detailed unsourced information about the TV character Rumplestiltskin. This spelling does not match the usual one but I wanted to find the response on that talk page which gave a reference for that spelling.— Vchimpanzee · talk · contributions · 21:56, 2 December 2013 (UTC)[reply]

I think that the page was Talk:Rumplestiltskin (Once Upon a Time) and it had three edits, all to a section titled "How do you spell it?". I don't see why the final text of the page shouldn't be disclosed:

Why is it "le" only on the show and not anywhere else? Where is the proof?— Vchimpanzee · talk · contributions · 19:43, 11 March 2013 (UTC)[reply]

Here it is, screenshot from beginning of episode "Manhattan" . Michu1945 (talk) 20:29, 11 March 2013 (UTC)[reply]

I see. I should have been paying more attention. Thanks.— Vchimpanzee · talk · contributions · 21:00, 11 March 2013 (UTC)[reply]

Is that the right one? --Redrose64 (talk) 22:19, 2 December 2013 (UTC)[reply]

That's it. Thanks.— Vchimpanzee · talk · contributions · 22:27, 2 December 2013 (UTC)[reply]

As you can see at this "everything" search of WP ([3]) certain new users are creating their new user pages in a subpage of their user at /UserProfileIntro. I've randomly checked a few of the pages and they were all created with the following summary: (Updating user profile introduction) (Tag: Mobile edit). November 22, 2013 is the oldest user account where this has happened, and there have been scattered instances since. I did a little Google searching and found the phrase UserProfileIntro in a script that was being developed for the mobile users. I submitted a bug report (now closed/deleted) at Bugzilla and was left a stern message that said "Closing this bug - this feature works as intended. If you have problems with it, please open a more specific bug." I'm fairly certain that new users shouldn't be directed to create their user page in a subdirectory, and that whatever is causing this is not right.

Am I nuts, or is this really a problem. If it is, can someone notify the proper people about it. I failed in that area. Thanks. --| Uncle Milty | talk | 02:30, 3 December 2013 (UTC)[reply]

Apparently the mobile people are "reinventing" user pages just for mobile. How strange. Anomie⚔ 03:20, 3 December 2013 (UTC)[reply]

Yep, that looks odd. Most of the User pages are non-existent, but there is content at the User:XXXX/UserProfileIntro page that would typically appear on the User page. Is there someone reading this page who can explain how/why this behavior counts as "works as intended"? Alternatively, is there someone here who has enough pull on Bugzilla to open this as a bug and not have it closed summarily? It doesn't seem consistent with how things have typically been done around here, but maybe there is some grand plan of which we have not been made aware. – Jonesey95 (talk) 05:46, 3 December 2013 (UTC)[reply]

Jdlrobson, do you know about this? — This, that and the other (talk) 10:54, 3 December 2013 (UTC)[reply]

This is a controlled experiment in beta to explore ways that we can in future encourage people to edit their user pages via smaller micro contributions. For the time being we want to see if people would fill these in and what kind of things they would say. We did not want to pollute user pages with this so we created it as a sub page. Let us know if you want to mark them in a way to make your lives easier or to make it clearer this is an experiment. Jdlrobson (talk) 21:48, 4 December 2013 (UTC)[reply]

I was wondering how long it would take people to notice this :D I don't see a problem with this, we can do whatever we want with it at any time. Let them play, measure and find the best solutions. —TheDJ (talk • contribs) 11:02, 3 December 2013 (UTC)[reply]

I added an example for those are wondering where this is used. —TheDJ (talk • contribs) 12:28, 3 December 2013 (UTC)[reply]

• Uncle Milty, it would be useful to have the closed tickets ID number. Then the ticket can simply be re-opened with some added detail instead of creating a "new" ticket that would simply get closed as a duplicate. :) Technical 13 (talk) 12:56, 3 December 2013 (UTC)[reply]

Sorry, I thought it was gone, but it was filtered out of my search. ID # 57748. --| Uncle Milty | talk | 13:47, 3 December 2013 (UTC)[reply]

I noticed bugzilla:57931 while reading this thread. Yay for bugs! Legoktm (talk) 16:38, 3 December 2013 (UTC)[reply]

I have placed a hidden comment onto an article using the <!-- and --> tags to deter deleterious edits to the page but it seems that whenever an IP editor edits the page the comment disappears. Is this a consequence of visual editor and is there an alternative I can use so the text remains in the section of the article where it has been placed?—Ryulong (琉竜) 03:03, 3 December 2013 (UTC)[reply]

Considering that VE isn't available to IPs at this time and the edits aren't tagged with the VE tag, it seems unlikely that VE has anything to do with it. More likely you've run into an IP editor who is deleting your comment. Anomie⚔ 03:24, 3 December 2013 (UTC)[reply]

Well shit. How do I keep it in there then?—Ryulong (琉竜) 17:52, 3 December 2013 (UTC)[reply]

Semi-prot the page? --Redrose64 (talk) 17:56, 3 December 2013 (UTC)[reply]

PC1 protection maybe? Technical 13 (talk) 18:57, 3 December 2013 (UTC)[reply]

An WP:Edit notice for the page is another possibility, but have you considered whether adding this is truly necessary and appropriate? "How do I keep it in there" sounds like an WP:OWNership issue. Have you considered whether the IP might actually be improving the page by removing a message that might seem unfriendly? WhatamIdoing (talk) 19:24, 3 December 2013 (UTC)[reply]

I had put it in there because editors had been expanding the antagonists' entries to be summaries of the entire TV series from the point of view of the antagonists, which is still somewhat a problem on the article as evident here.—Ryulong (琉竜) 09:39, 7 December 2013 (UTC)[reply]

Editnotice created. --Redrose64 (talk) 15:43, 7 December 2013 (UTC)[reply]

I can not print a (content) template from template space. How come, given that similar file and category pages I can print? -DePiep (talk) 11:32, 3 December 2013 (UTC)[reply]

Please give an example. --Redrose64 (talk) 17:55, 3 December 2013 (UTC)[reply]

If you look at a page like Template:Diseases of poverty, it appears that the entire Print/Export section is missing from the sidebar. This is also true for your watchlist, pages that you're currently editing with the wikitext editor (but not VisualEditor), and more. WhatamIdoing (talk) 19:18, 3 December 2013 (UTC)[reply]

And the "but not VisualEditor" part is now reported at Template:Bug. Whatamidoing (WMF) (talk) 19:25, 3 December 2013 (UTC)[reply]

57940 is about Print/Export showing when editing with VE.

You can print {{Diseases of poverty}} by using your browser's File > Print. I can't see why you would want a book or PDF version. It appears that template and special namespaces don't show Print/Export, although MediaWiki namespaces do.

And Printable Version doesn't really do anything special. See Help:Printable. There is also a Bugzilla ticket discussing removing Printable version. --  Gadget850 ^talk 19:56, 3 December 2013 (UTC)[reply]

As WhatamIdoing 19:18 writes: in template space I do not see/have the options (in main lefthand vertical menu bar) "Print/export": "Create a book", "Download as PDF", "Printable version". This submenu does appear when in article space, category space, my userspace. (A file I can print from commons).

I have not noticed an interaction with VisualEditor (I don't use).

I wrote this question expecting that it was based on a philosophy, about publishing WP. The browser's print function is not in discussion, it is about printing from WP. Any more questions? -DePiep (talk) 20:41, 3 December 2013 (UTC)[reply]

Adding, the actual pages: not available in {{Periodic table}}, did got my print of page User:DePiep/Print (having the template transcluded). -DePiep (talk) 20:44, 3 December 2013 (UTC)[reply]

I looked up some old template page snapshots at http://archive.org and didn't find signs of any Print/export options since Vector became the default skin in 2010. People rarely have reason to print template pages and your browser's print function should work fine so I don't see a need for a "printable version" link on template pages. PrimeHunter (talk) 22:20, 3 December 2013 (UTC)[reply]

The browser print option is there for articles too. The rarely argument could apply to other spaces too. But I understand there is no feature reasoning behind it, just forgotten back then. -DePiep (talk) 14:04, 4 December 2013 (UTC)[reply]

Hi, I'm a consumer more then a user and I have the following concern:

What human does, should be human conform. Wikipedia treats information and should be in this way brain conform.

The best way to read without any distractions - excluded these of the place your working at – is to use Safari Reader. This is not publicity, but just my personal opinion upon what is good informatics function: It let me do what I want to do: To read without distraction.

This is thus not possible with any other reader. If I make browser window smaller, I get bothered by the windows surface; if I apply full screen mode on browser, the text its spread on my 27 inch screen an becomes heavily to read.

Nevertheless, I experience tranquilly readying by using Safari Reader, not all Wikipedia pages can be read by this browser function.

I know, that this problem is discussed outside of Wikipedia, but my opinion is, that this excellent experience of reading is the best and should be possible on any Wikipedia site, hence it should be discussed on Wikipedia. Please let me know, if you have any good ideas, to access Reader the content of all Wikipedia sites, or you have maybe any suggestions of how to create Wikipedia’s proper function which give access to its content to a more brain conform way.

If not – I will be forced to buy a „higher-than-wide“-screen (3:1) and to install it in place of my 27 inch screen. Thanks for any comments on that.

Muntscher (talk) 14:33, 3 December 2013 (UTC)[reply]

Did Apple release any documentation about how this thing works, even at a basic level? According to this, it depends on a number of factors, such as the page size. Is it possible that the pages it does not allow using the Reader on are just shorter? I don't see this as a problem with Wikipedia or the MediaWiki software per se, but feel free to file some sort of bug on our issue tracking system. πr² (t • c) 04:58, 6 December 2013 (UTC)[reply]

A few minutes ago, I opened up my /links page that has the admin dashboard and other stuff on it. In between AIV and UAA was a load of cats. On reloading the page, they'd disappeared. I can't find any sign in the History of my page, the admin dashboard page or AIV of anyone reverting cats. Has anyone else had this happen? And, no, I'm not drunk and haven't been smoking funny stuff. Peridon (talk) 17:14, 3 December 2013 (UTC)[reply]

Found it in the History at AIV now. Don't know why I didn't before. Peridon (talk) 17:21, 3 December 2013 (UTC)[reply]

Moved from Wikipedia:Administrators' noticeboard/IncidentArchive821 § Script Error in Templates

I was not sure where to post this, so I think the ANI is the best place. I noticed that Template:M1 year in topic suddenly has a script error. Judging by the templates it includes, the error seems, based on timing, to be the result of edits on Template:Navbar and Module:Navbar by Edokter (linked so she/he is aware, not because the report is about them). The Navbar pages are fully protected so I cannot edit them myself to see if they are indeed the source of the error. EvergreenFir (talk) 03:58, 4 December 2013 (UTC)[reply]

One of the greatest weaknesses of Lua modules, and something that Wikidata has to deal with all the time in its project namespace, is that if you have too many lua modules on one page, they stop loading after a while and you get that message. That might be what it is, but as I don't understand templates very well, it might be something else entirely. Sven Manguard Wha? 04:43, 4 December 2013 (UTC)[reply]

Lua's worst problem has been the miserly 10-second timeout, which then stores "Script error" for each Lua function in the rendered page. Some have imagined the Lua clock ran like traditional CPU time, but numerous tests confirmed it can double (or triple) in slow servers (a 4-second Lua slows 2.5x as 10-second and craters). -Wikid77 00:34, 7 December 2013 (UTC)[reply]

@EvergreenFir: This should be at WP:VPT. If you have scripting enabled in your browser (JavaScript, nothing to do with modules), when a "script error" occurs, you can click the red error message to see a popup box with details. You can select that text and copy it, to be pasted into a report at WP:VPT.

@Sven Manguard: Ouch, I try to follow WP:VPT and have not seen any mention of a problem with modules (apart from the total runtime of 10 seconds per page, which is plenty). Is there a discussion about that somewhere? Has Anomie commented? Johnuniq (talk) 05:46, 4 December 2013 (UTC)[reply]

Oh no, Lua 10-second timeout is way low, should be 20-25 seconds. Timing has confirmed slow servers can double/triple Lua clock and "safe" 4-second run slows to wannabe 12-seconds (aborted at 10-sec. limit). -Wikid77 00:34, 7 December 2013 (UTC)[reply]

OK, I should have clicked the first link above (Template:M1 year in topic). I had assumed that it was the usage of that template somewhere that had a problem, but it is actually on the template page. The error text is:

Lua error: Cannot pass circular reference to PHP.

Backtrace: (none)

A little digging shows the problem occurs when "{{#invoke:Year in other calendars|main}}" is previewed in a sandbox. Mr. Stradivarius may be able to throw some light on the matter, which is possibly in Module:Year in other calendars or one of the modules it calls. This section should be closed, with further discussion elsewhere. Johnuniq (talk) 06:14, 4 December 2013 (UTC)[reply]

My first thought is that it looks complicated, and that it might be a server-side change. It's not a change in Module:Year in other calendars, as that hasn't been edited recently, and it was working as late as 27 November when I made this comment. It might be a change in one of the modules it calls, which I'll investigate now. It is quite a hefty module, though (as was Template:Year in other calendars/old before it), so Sven Manguard may be on to something with the "too many modules on the page" comment. More in a second. — Mr. Stradivarius ^{♪ talk ♪} 07:03, 4 December 2013 (UTC)[reply]

It looks like the problems are coming from Module:Japanese calendar, but neither that or the modules it calls have been edited recently, so I think it must have been a change server-side that has broken things. I'm not sure yet about any possible fix. — Mr. Stradivarius ^{♪ talk ♪} 07:29, 4 December 2013 (UTC)[reply]

Also, the module calls that are causing the script errors from #invoke work fine when used from the debug console. It appears to be only module invocations using #invoke that are affected. — Mr. Stradivarius ^{♪ talk ♪} 07:37, 4 December 2013 (UTC)[reply]

This appears to be due to the fix for Template:Bug, which was deployed yesterday. Module:Year in other calendars is returning various objects in its 'p' table. Removing those should fix the problem. If access to those objects is necessary for some other module, the p table could contain an accessor function which would return them. BJorsch (WMF) (talk) 14:15, 4 December 2013 (UTC)[reply]

Yep, that's the one, and I've fixed it now. Thanks! It was confusing because I had done the same thing in both Module:Year in other calendars and Module:Japanese calendar. I got rid of the extra objects in 'p' for the former, and used an accessor function for the latter. By the way, where can I subscribe so that I know that things like this are coming? :) — Mr. Stradivarius ^{♪ talk ♪} 14:47, 4 December 2013 (UTC)[reply]

That's a very good question. Unfortunately, there isn't any non-developer-oriented place for change notifications. I suppose the closest thing is [4] and [5] (if only there were a way to filter out the "Localisation updates" entries) if you want to watch changes that have been merged, and [6] will show you changes that are currently proposed, and [7] shows open bug reports and feature requests. BJorsch (WMF) (talk) 18:33, 4 December 2013 (UTC)[reply]

• Raise Lua 10-second timeout: Meanwhile, keep pressing to raise the pitiful Lua timeout limit to 25 seconds. Many Lua timing tests have confirmed how slow servers can double/triple the Lua clock and a "safe" 4-second run slows to wannabe 12-seconds (aborted at 10-sec. limit). Should be 25-second limit, because unlike "wp:Wikimedia Foundation error" (WFE), Lua timeout stores "Script error" in the rendered page (forever) with no 70-second grace period to extend the formatting and save good results 7 minutes later. Again the Lua timeout is not a mere smaller version of the 60+10-second parser limit, and instead a Lua timeout scars the rendered page with "Script error" for every aborted Lua #invoke run after the 10-second cutoff. The Lua 10-second timeout is like narrowing a 7-foot (2-metre) road shoulder as 7x smaller along a mountain-side road at the cliff's edge (all because the Lua tires are better, except on gravel!). -Wikid77 00:34, 7 December 2013 (UTC)[reply]

Sometime in the past few days the custom edittools in my modern.js have disappeared from the Insert menu (from the character subset drop-down menu in the page-editing interface) when I'm using Firefox 25 or Chrome 31. The menu is intact in IE 11. Does anyone know if there has been a recent change in how JavaScript is implemented? I have verified that the current version of Java is installed on my machine, and, I believe, that it is functioning properly.

• Problem occurs in Firefox 25.0.1 and Chrome 31.0.1650.57 m
• Problem does not occur in IE 11.0.9600.16428
• System is Windows 7 64-bit
• screenshot of menu as it appears in IE. Tools circled in orange are standard; the rest are my custom ones.

Thanks in advance for any info, and please let me know if I should be reporting this at the MediaWiki support desk as well or instead. Eric ^talk 13:55, 4 December 2013 (UTC)[reply]

Try adding the line if(window.updateEditTools) window.updateEditTools(); after the assignment to window.charinsertCustom. It's possible that something changed with the JS loading that is making your modern.js be processed after the main edittools script is run where it used to be run before it. Anomie⚔ 14:20, 4 December 2013 (UTC)[reply]

Hey, that worked like a charm! Thanks a bunch! Eric ^talk 14:31, 4 December 2013 (UTC)[reply]

I am developing a course in Wikiversity and I would like two tools to take advantage of peer learning, as in MOOCs. I wonder if there are already ways to implement these in wikis or whether we would need to develop new extensions.

1. I want to present a question prompt with a textarea input box for the user to input an answer. Then after submitting, the user would see the prompt, the course-recommended answer, and a page of all submitted answers (which have been stored with automatically added user's signature --~~~~).
2. I want for users to be able to click vote up or down comments/answers, so that a page will display postings in order by rank of up/down votes.

Is there a way to approach either of these functionalities with currently existing wiki tools or extension? I know we have some sort of polling tool for administration. Is it adaptable to these needs? If there isn't an existing way, is there a group I should contact that would be the logical place to propose developing these tools?

Note: In part this is a rethinking of an earlier question I posted in the Help desk here --Kenmayer (talk) 14:33, 4 December 2013 (UTC)[reply]

There might be existing extensions for upvotes/downvotes/likes/+1, but I don't know whether the devs/ops would be willing to install it on Wikiversity. Try searching on MediaWiki.org. It would be possible to write a quick JS hack to do something like this (assuming the user has JavaScript enabled), but it would log the username of every voter. Not sure if you want that or not. You might also be able to write a complex template or Lua module to do something like this, but I don't think it would be very good for the students. πr² (t • c) 04:48, 6 December 2013 (UTC)[reply]

• Careful editors could vote in a preformatted, sortable wikitable: I have noted how wp:edit-conflicts during a 20-user edit session can be prevented by separating each user response by a separator line, such as table-row token "|-" between each response stored in the page. Ideally, each of 20-30 students would have voter-id codes (V1-V30) pre-stored as "line id codes" in the empty voting table, and then each student would respond by updating the row which has their voter-id code, putting remarks in the empty row, but as a sortable table. Example:

  {| class="wikitable sortable" <--also set columns for sorting
  ! Id || Issue || Vote || Time || Remarks
  |-
  | V1 || issue #1 || vote || ~~ ~ ~~ || (remarks)
  |-
  | V1 || issue #2 || vote || ~~ ~ ~~ || (remarks)
  |-
  | V2 || issue #1 || vote || ~~ ~ ~~ || (remarks)
  |-
  | V2 || issue #2 || vote || ~~ ~ ~~ || (remarks)
  |-
  | V3 || issue #1 || vote || ~~ ~ ~~ || (remarks)
  |-
  | V3 || issue #2 || vote || ~~ ~ ~~ || (remarks)
  |}

Explain to each student to update the rows for their voter-id under the "vote" column to "yes" or "no" (or whatever choices), and connect the 5 tildes ("Template:J") together, as the timestamp next to their vote. If the voting all occurred during the same month, then the time-of-day could be sorted by timestamp column, hours/days "0:01, 1-31 December" etc.

Also each voter could change their prior votes, if they felt misled or mistaken during an earlier response. Of course there is always the chance for glitches during editing of the wikitable format, but if various students were asked to "moderate" and check the table format, from time-to-time, then the wikitable of votes would be keep functional, and best of all: almost no edit-conflicts with 20-30 users all updating the same page within a period of minutes or hours. Also, any hostile comments could be redacted in such a system, although the "peer pressure" of all students meanwhile editing the same table would tend to "tone down" excessive remarks during voting. To reduce name-related problems, students could be asked to avoid discussing voter-ids, as semi-anonymous editing (although ids could be deduced), and privately discuss when someone else is editing under their voter-id. Due to the "magic" of the "|-" separator lines between rows, then all 20-30 students could edit the table at the same time, or announce "I'm saving edit now" to allow other students to wait 30 seconds before the next attempted Save-page operation. Even with the current primitive level of edit-conflict merging, such a voter-wikitable could be used to collect votes, allow re-votes, and sort the issues/votes into date-time order. Once sorted, then the total votes, for each related issue, would be easy to count. -Wikid77 (talk) 23:26, 6 December 2013 (UTC)[reply]

How soon do you need this? I believe that something like this will eventually be possible via WP:Flow, but I doubt that these sorts of advanced workflows would be before the end of next year (or the year after that, even). WhatamIdoing (talk) 01:15, 7 December 2013 (UTC)[reply]

So will Flow have upvotes? Will it keep track of each user's karma? I don't see why that would be needed. This is an encyclopedia, not a social network. Oh, wait, are you talking about creating a custom workflow that would be equivalent to likes/dislikes? Are there any examples of how this would work? πr² (t • c) 04:34, 7 December 2013 (UTC)[reply]

Just a random idea, but would it be worthwhile to replace the {{tl}} template with a more "built-in" method of linking to templates? (i.e. a parser function or something? {{tl:ambox}} instead of {{ambox}}?) Would it even be worth it? ViperSnake151  Talk  17:17, 4 December 2013 (UTC)[reply]

I cannot phantom any reason why that would make a significant impact. —TheDJ (talk • contribs) 21:58, 4 December 2013 (UTC)[reply]

The built-in method is a normal wikilink with namespace: Template:Tl. I see no reason for anything else. PrimeHunter (talk) 23:02, 4 December 2013 (UTC)[reply]

Yeah, the {{tl}} templates are just wikilinks with some nifty css styling (templates are still linked like normal wikipages). Theopolisme (talk) 03:14, 5 December 2013 (UTC)[reply]

• No, there's no way it's worth it. Right now, we have over a dozen tl* templates that do all sorts of linking, formatting, with or without parameters, and there are probably more that will be built in the future. It would be insane if we had to have a mediawiki update in order to add new tl* functions. This isn't even anything that would be worth it to try to do with lua - they're basically about as simple as templates get. VanIsaac_{WS Vex}^contribs 03:31, 5 December 2013 (UTC)[reply]
• Template:tl runs 800x/sec, #ifeq at 750x, Lua 500x: Comparing the runtime of {{tl}}, as 800x per second, to the #ifeq parser-function at 750x/second, then the operations seem about equal, where {tl} must format the template-name wikilink and that involves a check for existing page to set link color blue/red, etc. Also, {tl} has remained static, as a rapid template, not burdened with 15 layers of /core subtemplates dragging /core2 subtemplates. A tiny template, inserting one word, runs at 2,400x/second. Formerly, the Lua Scribunto interface ran tiny Lua scripts at only 300x per second, but we complained and the developers quickened Scribunto in April 2013 to 500x-600x Lua per second. Some people have imagined that complex Lua script never gets slow, but runtime tests have confirmed how checking 100 parameter names and error-check formatting those Lua parameters does, as could be expected, slow the operation of Lua, where simple checks of just a dozen parameters might run 3x faster. Hence, the current template {tl}, as 800x per second, is running perhaps 2x faster than Lua could offer. -Wikid77 19:30, 6 December 2013 (UTC)[reply]

I get the following during my last few attempts at doing a Rollback: "Grabbing data of earlier revisions: parsererror "OK" occurred while contacting the API." I then have to hit the back button to get off that screen.

Using Firefox 25.0.01 on Windows 8.1. (Windows updated recently and may have something to do with it.) Any thoughts or info? GenQuest ^{"Talk to Me"} 17:38, 4 December 2013 (UTC)[reply]

Do you have either twinkle or one the Beta features enabled? I remember there have been some similarish error messages. Chris857 (talk) 17:42, 4 December 2013 (UTC)[reply]

Both. GenQuest ^{"Talk to Me"} 17:54, 5 December 2013 (UTC)[reply]

Yes, Beta Features is the likely culprit. Previous reports of this issue: Wikipedia:Village pump (technical)/Archive 120#Twinkle, Wikipedia:Village pump (technical)/Archive 120#Twinkle problem?, mw:Talk:Beta Features/Nearby Pages#Twinkle (with technical detail).

According to bug 57556, the issue has been fixed. Hopefully we'll get the fix on the next deployment. – PartTimeGnome (talk | contribs) 21:18, 4 December 2013 (UTC)[reply]

Practically none of the scripts in my User:Kudpung/vector.js have been working for a while. Some of these are quite important such as semi automated tools for admins for closing AfD and blocking/unblocking, etc. An admin working through backlogs gets used to these tools. The Bugzilla report states RESOLVED FIXED but it hasn't been fixed. Kudpung กุดผึ้ง (talk) 23:58, 4 December 2013 (UTC)[reply]

It has been fixed, the fix just hasn't been deployed to Wikipedia yet. See mw:MediaWiki 1.23/Roadmap. (Because the fix was made after 21 November, it won't reach us with 1.23wmf5 - but it did occur before 5 December, so we'll hopefully get it with 1.23wmf6.) — This, that and the other (talk) 00:25, 5 December 2013 (UTC)[reply]

@Kudpung: you can just disable the BetaFeature which is causing problems you know. Legoktm (talk) 02:16, 5 December 2013 (UTC)[reply]

Forgive my stupidity, but where do I do that disablement? Kudpung กุดผึ้ง (talk) 02:33, 5 December 2013 (UTC)[reply]

I believe at Special:Preferences#mw-prefsection-betafeatures. Killiondude (talk) 02:40, 5 December 2013 (UTC)[reply]

Ah, but I never had those enabled. Kudpung กุดผึ้ง (talk) 16:46, 5 December 2013 (UTC)[reply]

Thanks. I'll just wait for the new deployment and see what happens. Worse case scenario, I'll get off the beta-test. GenQuest ^{"Talk to Me"} 17:54, 5 December 2013 (UTC)[reply]

On the main proposal page, the archives only go up to 105 but once I go to archive 105, the archives go up to 107. My peoposal Pending changes in archive 106 is no longer in the main proposal page. I assumed the main proposal page was archive 106 because the archives on that pagw went up to 105 but instead there's no way to go from the main proposal page which doesn't have the Pending changes proposal to archive 106 which does have that proposal in only 1 click instead of 2. The main proposal page should list all archives that contain a proposal not appearing in that page. Blackbombchu (talk) 18:23, 5 December 2013 (UTC)[reply]

Well spotted! I've adjusted the header at the top of Wikipedia:Village pump (proposals) so that it displays links to archives 86 to 107. -- John of Reading (talk) 18:48, 5 December 2013 (UTC)[reply]

I'm getting really annoyed. Enhanced recent changes isn't allowing me to expand grouped up edits (it was allowing it intermittently before, especially if I WP:BYPASSed my cache) except in really, really, rare occasions. I'm wondering if it has anything to do with removing jQuery from loading on all pages by default? Any one else experiencing this (I've tested on multiple machines with various OSes and browsers and two out of three of my accounts with the same results). Any suggestions on what may be causing it? Technical 13 (talk) 22:48, 5 December 2013 (UTC)[reply]

I personally don't have enough time to investigate this, but I'm sure you could give more details. :) Please add ?debug=true or &debug=true to the query string and check the JS error console. P.S. AFAIK, jQuery is still loaded by default, but jQuery UI is not anymore. πr² (t • c) 04:42, 6 December 2013 (UTC)[reply]

Adding ?debug=true makes enhanced recent changes work, so there is nothing appearing in the error console when I do that. The error console without ?debug=true looks like:

I hope all of this helps you figure it out PiRSquared17. Technical 13 (talk) 02:25, 7 December 2013 (UTC)[reply]

O_O. That's a lot more than I expected. Order of magnitudes more. I can't duplicated this (works for me), so could you provide your browser and skin? I'm wondering if you get a JS error when you actually click the expand links. πr² (t • c) 03:39, 7 December 2013 (UTC)[reply]

PiRSquared17, I've done some more testing to see if I can narrow it down and isolate it, and when I click the expand arrows/links and they don't expand I get nothing int the error console (I load the page and clear the log and nothing new appears). With ?debug=true set and the sections expand, I get the following JavaScript warning, but that is it: [11:54:13.836] ReferenceError: reference to undefined property queue[0] @ https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20131207T024812Z:26 It's a real nuisance having to add ?debug=true each time to make it work. I'll do some more digging because if no-one else is having an issue, it must be in one of the userscripts I am using or made. Technical 13 (talk) 17:03, 7 December 2013 (UTC)[reply]

This had been hanging at the end of the "before posting" page for a month (does no-one ever read that? :-), apparently misplaced there and presumably intended for here:

• IE8, W7, AATTV, paragraph 'Unit Badge'. In an endeavour to comply with Wikipedia verification criteria I edited the page to provide what I considered to be two verifiable sources. As these have been removed,(presumably by an administrator or similar), could you please explain my error[s]). Laurencenic (talk) 01:22, 2 November 2013 (UTC)[reply]

Joriki (talk) 08:06, 6 December 2013 (UTC)[reply]

Presumably refers to Wikipedia:Village pump (technical)/Before posting, and Laurencenic's comment refers to Australian Army Training Team Vietnam (AATTV), this edit via IP before registering their account.

The edit didn't actually add references, but added a link to the "see also" section. The link was to an article that doesn't exist. As it says in the subsequent revert, "see also" is just for linking related Wikipedia articles. See Wikipedia:Citing sources for information on adding sources. equazcion → 08:22, 6 Dec 2013 (UTC)

On Benjamin Netanyahu, I'm getting a red error message:

Failed to render property signature: Property not found for label 'en' and language 'signature'

The line that specifies the signature using the signature property hasn't been changed for half a year, and the corresponding Wikidata item does seem to have a signature property that specifies a proper signature image file. The fact that it says "language 'signature'" when that should be the property label and not the language seems to indicate that something rather fundamental has gone amiss?

Firefox 25.0.1, Mac OS X (10.8.5)

Joriki (talk) 08:15, 6 December 2013 (UTC)[reply]

I did a quick test, and it appears that the code {{#property:label}} is broken on every page it is used on. The code {{#property:pnnn}} still works. From the error message it looks like the language and label codes are swapped around somewhere between the #property invocation and Wikidata. If the label doesn't exist on Wikidata, no error is returned - #property just returns nothing. I assume that this must have been broken in this week's software updates, but that is just a hunch. In your case you could use {{#property:p109}} and it should work, but that doesn't help for the other pages that are returning errors. I'm not sure who best to ask about fixing it, but filing a bug in bugzilla ought to get it to the right person soon enough. — Mr. Stradivarius ^{♪ talk ♪} 09:13, 6 December 2013 (UTC)[reply]

We are urgently investigating the issue. Thanks for reporting it. Katie Filbert (WMDE) (talk) 15:32, 6 December 2013 (UTC)[reply]

The article Thunderbirds merchandise contains {{DISPLAYTITLE:''Thunderbirds'' merchandise}}. So I would expect the word "Thunderbirds" in the title to be italicized and the word "merchandise" not to be italicized. But using IE11 (or Chrome 31.0.1650.63 m) on Windows 7, I see both words italicized. Is that what everyone else sees? And if so, does anyone know how to fix it? Thanks. DH85868993 (talk) 13:52, 6 December 2013 (UTC)[reply]

Fixed. --Redrose64 (talk) 14:24, 6 December 2013 (UTC)[reply]

Thanks. DH85868993 (talk) 14:31, 6 December 2013 (UTC)[reply]

Wikipedia:Database reports/Broken WikiProject templates indicates that Wikipedia:WikiProject Taxation transcludes the (nonexistent) Template:Wiki project Templates. But I couldn't find any such transclusion, either in the project page itself, or any of the things it transcludes. Can anyone explain why this transclusion is being reported? Thanks. DH85868993 (talk) 13:55, 6 December 2013 (UTC)[reply]

No, but I've fixed the problem by doing a null edit to Wikipedia:WikiProject Taxation. -- John of Reading (talk) 14:27, 6 December 2013 (UTC)[reply]

It was the Nurhusien vandal. --Redrose64 (talk) 14:30, 6 December 2013 (UTC)[reply]

Thank you both. DH85868993 (talk) 14:32, 6 December 2013 (UTC)[reply]

Using IE11/Win7. I see various glitches with table sorting at List of elements. For example:

1. Load page. Click repeatedly on the sort button for the "Abundance" column (far right). Some clicks appear to do nothing, others appear to sort the table by atomic number (ascending or descending) instead.

2. Load page. Click each of the sort buttons in turn, from left to right, ("Z", "Sym", "Element". etc.). When I get to "Atomic weight" the sort ceases to function (on that or any other column).

Is this a browser bug or something in Wikipedia? 86.171.42.57 (talk) 18:20, 6 December 2013 (UTC)[reply]

Hey, thanks for finding this. I think I fixed it with this edit. There are 13 columns, but there were only 12 sort keys (don't know if that's what they're called). There was also a random test edit that I reverted, which didn't seem related. So, your browser and Wikipedia are fine, just a mistake in the table. Chris857 (talk) 20:17, 6 December 2013 (UTC)[reply]

Hi Chris, all seems to be working properly now, thanks very much for sorting it out. 86.171.42.57 (talk) 01:30, 7 December 2013 (UTC)[reply]

Is it possible for persons creating articles to be presented with a dropdown box of the categories at the time of submission. On choosing the desired category, the person can save the article. Thus work involved in looking for articles that are not categorized is eliminated?

Thank you

Anupama Srinivas (talk) 18:21, 6 December 2013 (UTC)[reply]

I oppose. Special:UncategorizedPages is made automatically so it isn't much work to find them. There are tens or hundreds of thousands of categories for articles so a dropdown box of "the categories" is not practical. And most articles should be in several categories. If we force new users to select one category then they would often make a poor choice and it's harder to find the problem articles to add better categories. It would also require a software change. The developers have better things to work on, and many new users would be frustrated when they are unable to save. And should it apply to moving drafts into mainspace? Drafts should not have categories intended for articles. PrimeHunter (talk) 20:41, 6 December 2013 (UTC)[reply]

The answer to this is probably really obvious but apparently my brain isn't working properly. Why is the template on Dead to Fall (and related) pointing to User:Jax 0677/Template:Dead to Fall rather than Template:Dead to Fall as it should, and how can I fix it? Thanks--Jac16888 ^Talk 19:16, 6 December 2013 (UTC)[reply]

• Look inside {{Dead to Fall}}, the name parameter is set to User:Jax 0677/Template:Dead to Fall. VanIsaac_{WS Vex}^contribs 19:35, 6 December 2013 (UTC)[reply]

Bingo, thanks--Jac16888 ^Talk 19:45, 6 December 2013 (UTC)[reply]

According to this list, a lot of articles link to BB&T Ballpark. I had to link to similar article earlier this week and discovered the need to make that a disambiguation page, but after moving the article that was there, I found a bunch of articles where even if I clicked on edit and tried CTRL-F, I couldn't find the words "BB&T Ballpark". I know I fixed a template, but a bot has tagged the article now. I reverted the tag and reported the situation to the bot's talk page, because I'm just not finding the links.— Vchimpanzee · talk · contributions · 19:53, 6 December 2013 (UTC)[reply]

If you update a link in a template, as here, the links at Special:WhatLinksHere/BB&T Ballpark aren't updated immediately; you normally need to wait for the job queue to process them. --Redrose64 (talk) 20:00, 6 December 2013 (UTC)[reply]

I figured I had given it time.— Vchimpanzee · talk · contributions · 20:34, 6 December 2013 (UTC)[reply]

The job queue has been ropey since they reconfigured it about six months ago. It's two days since your edit - but it can take more than two weeks in some cases. --Redrose64 (talk) 21:16, 6 December 2013 (UTC)[reply]

Ive noticed the same thing a few times. Surely that isn't normally what it should be like.Blethering Scot 21:29, 6 December 2013 (UTC)[reply]

If you, like me, have added VisualEditor template data to templates, you will probably agree that it becomes a boring task after the first time. Then again it is a very useful work. At Google Code-in we are looking for new tasks, because 13-17 years old students are completing tasks almost faster than we can create them. For them, a task like this will be instructive. For en.wiki, this is a chance to get work done and new contributors with a potential to stick around. Note that this work would benefit not only en.wiki, but also all Wikimedia projects watching and using copies/adaptations of these templates.

What do you think? It would be great if someone would step in, become a Google Code-in mentor, and coordinate this little project until January 6, when GCI ends. If you want to try before committing, just point me to 5 templates welcoming VisualEditor template data. I will create a task, and share here the news when the updated templates are ready for review. Then you can decide what comes next. Deal?--Qgil (talk) 19:28, 7 December 2013 (UTC)[reply]

Really? Data entry? That's what you had those kids doing? I'd be very surprised if anyone outside the autism spectrum would be considering sticking around after having that as their first significant "coding" (?) experience. equazcion → 20:00, 7 Dec 2013 (UTC)

Is there a way to run a global search across all (or multiple wikis) looking for different language versions of the same article or results from the same search term? Thanks.-Godot13 (talk) 19:44, 7 December 2013 (UTC)[reply]

@Godot13: - Have you tried a Google search - for example, search for "godot site:wikipedia.org" GoingBatty (talk) 20:00, 7 December 2013 (UTC)[reply]