Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Rehman (talk | contribs) at 00:52, 19 January 2014 (→Site-wide template auto-collapse issue: you're right!). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (see how to report a bug). Bugs with security implications should be reported to security@wikimedia.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.


stats.grok.se

December 31 pageviews

The pageview tool seems to have either gotten interrupted or was subject to partial data. I need help figuring out which it was. From what I can tell there must be some process that runs through WP pages alphabetically. Somewhere between Tim Hardaway, Jr. and Tory Burch, the process did not run for December 31. Either the underlying data was not available for the end of the alphabet or they were not compiled. Can someone tell me whether the underlying data exist for the underlying data.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 04:31, 2 January 2014 (UTC)[reply]

It's the Y2K+14 bug I've been trying to raise the alarm about! Now don't you wish you'd listened to me??? EEng (talk) 05:14, 2 January 2014 (UTC)[reply]
  • Estimate the missing 31-December data: Since the stats are complete for pages "A"-"TNZ", then until the database is fixed (during the next few days), perhaps treat the partial day's stats in "To"-"Zzz" as an estimate for 31 December as either the pageviews from 30 December, or 17 December (2 weeks prior), or the average: (30Dec + 17Dec)/2. After "To" there is some partial data, such as "Toy" from 472 to 3, or "Tow" 72 to 5, or "TS" 114 to 76. -Wikid77 13:03, 2 January 2014 (UTC)[reply]
It looks like it's just a problem with the stats.grok.se site:
alexz@tools-login:~$ zgrep -F "en ZZ_Top " pagecounts-20131231-080000.gz
en ZZ_Top 52 1578087
-- Mr.Z-man 15:29, 2 January 2014 (UTC)[reply]
Either you are showing me something that suggests ZZ Top got 1.578 million pageviews or 52 pageviews in the 8:00 hour on December 31 according to the underlying data. I will assume it got 52 pageviews that hour. So something is not compiling correctly starting at some point in the alphabet between Tim Hardaway, Jr. and Tory Burch. Starting at "TO" there is minimal data according to User:Wikid77. I'll be watching here for confirmation that the database has been corrected.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 19:18, 2 January 2014 (UTC)[reply]
Yes, it's 52. The second number is the total number of bytes sent (I'm not sure why that's included in the data). Mr.Z-man 02:48, 3 January 2014 (UTC)[reply]
Having not run since the 1 January, it seems it tried to run for yesterday and most are complete but I've found a few that are missing. Blethering Scot 19:11, 6 January 2014 (UTC)[reply]
I am fairly certain that January 5 results are only about 25% of the daily totals.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 19:17, 6 January 2014 (UTC)[reply]
It looks like the underlying data does not exist after 5 AM and extending well into the 6th. All dates are now caught up except for December 31 (TO-ZZZ).--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 16:24, 10 January 2014 (UTC)[reply]

stats.grok.se support

The help page for stats.grok.se (which we link to from all sorts of places, for example DYK notificiations) directs people to User talk:Henrik, but that's littered with people pointing out that User:Henrik doesn't answer queries there. Should we be providing the equivalent service from a WMF server?

[FYI, The issue I wanted to raise is that, on, for example [1], it says "Magistrate of Brussels has been viewed 57 times in 201401.". But that doesn't include today's visits (the article was under DYK on the main page today). Better wording would be something like "As of 4 December 9013, Magistrate of Brussels has been viewed 57 times in 201401."] Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:06, 5 January 2014 (UTC)[reply]

I think a couple of years back there was talk about Wikimedia finding another service for stats. What happened to that idea, I wonder? Henrik will often fix things if you email him. But posting on that talk page goes nowhere fast. And there seems to be many breakdowns of the stats. — Maile (talk) 01:32, 6 January 2014 (UTC)[reply]
I think we need to consider rebuilding the tool with more capabilities.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 18:23, 6 January 2014 (UTC)[reply]
There is definitely a problem with it. For example this only records the stats of 5 January and not the days before or after it (including one when it was on the main page as a DYK). The C of E God Save the Queen! (talk) 20:33, 7 January 2014 (UTC)[reply]
How do we start the process of getting a replacement to the current tool?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 05:57, 9 January 2014 (UTC)[reply]
Find a volunteer to write the replacement, or write it yourself. WMF Tool Labs can host it. For finding someone else to write it, I don't know if there's somewhere specific to find tool developers, though this page is a good place to find technically-minded users. – PartTimeGnome (talk | contribs) 20:25, 11 January 2014 (UTC)[reply]

Page traffic counter is sick

The counter has been down for a quite a few days now. There's no information as to whether 2 Jan figures are going to melt into the ether, lost forever. And no indication of whether the system is up and running properly now.

Would it not be better for the WMF to take over this facility formally? It's a very important facility. Tony (talk) 02:54, 10 January 2014 (UTC)[reply]

There is no data for the 6 Jan as it skips from 5 to 7. Then again there is nothing for 8 either.Lihaas (talk) 04:25, 10 January 2014 (UTC)[reply]

All of a sudden, January 1–3 & 7 ran. December 31 (TO–ZZZ) and January 6, 8 & 9 remain a mystery and January 5 only seems to be about 25% of the data.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 04:38, 10 January 2014 (UTC)[reply]
There is definitely something wrong with it, I do agree that WMF probably should take over it so we can potentially minimize the disruption. for example, in this article, the 6th of Jan doesn't exist! The C of E God Save the Queen! (talk) 10:37, 10 January 2014 (UTC)[reply]

The raw data used to compute these things is generated by the WMF. This is what Henrik uses, what I use for WP:5000, and virtually all other statistical page view functionalities of which I am aware. I will note that something broke spanning Jan. 5 and Jan. 6 2014 (UTC). Otherwise, it has been quite stable for some time. West.andrew.g (talk) 16:03, 10 January 2014 (UTC)[reply]

West.andrew.g, thanks for the explanation about Jan 5/6. Can you tell me why December 31 was left incomplete for the TO–ZZZ portion of the alphabet. Also, what do you know about the dates listed at User:Killiondude/stats#Are_there_known_dates_for_which_complete_sets_have_not_been_compiled_although_the_data_seems_to_be_available?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 16:22, 10 January 2014 (UTC)--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 16:22, 10 January 2014 (UTC)[reply]
All went through as planned with my processing script on Dec. 31, so there does not seem to be a fundamental problem. I cannot comment on what might have happened with Henrik's script . Henrik's tool is known the be imperfect in some ways. I can't account for all those dates listed (my storage began sometime in 2010), but it did used to be a far more buggy process than it is now. West.andrew.g (talk) 18:28, 10 January 2014 (UTC)[reply]
I guess my question is whether the numbers posted on Henriks page are final or whether they can ever be compiled to include December 31st for the end of the alphabet?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 20:56, 10 January 2014 (UTC)[reply]
West.andrew.g, I am asking you.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 14:37, 12 January 2014 (UTC)[reply]
I can't answer that question. It would be simple to reprocess if the bug is found (I assume a single line had some weird encoding; or maybe it was just that the machine lost power) and Henrik or a tool admin re-fires the code. The raw statistical data is stored for perpetuity. It's my understanding that getting a hold of Henrik might be the hard part, though. West.andrew.g (talk) 23:07, 12 January 2014 (UTC)[reply]

Page-views

Hi there. I don't know if I am posting this in the right place, but I am sure that someone here you'll be able to send it to the right place. Is anyone here aware of these problems? The page-views Stats Grok is out order since early 2014. This is an important data information and I still don't get why WMF simply don't put it running in order and, so, we are still depending on unstable server and scripts. Regards, 177.148.179.211 (talk) 23:42, 9 January 2014 (UTC)[reply]

As I understand it, that's a private website run by a private individual. WhatamIdoing (talk) 01:16, 10 January 2014 (UTC)[reply]
So, thats another question. Its a important and very desirable information. Why we still depend on "private website run by a private individual" to get it? Come on, WMF guys, bring us the Page-views data back! 177.148.179.211 (talk) 03:55, 10 January 2014 (UTC)[reply]
Hi. See #stats.grok.se. Many things are provided by volunteers (bug fixes, tool/scripts used for editors, etc.). I actually prefer things that are run by (active) volunteers vs. the WMF getting involved. It's lamentable that Henrik's tool is erratic lately, however. Killiondude (talk) 22:35, 10 January 2014 (UTC)[reply]

Potential replacement

de:User:Hedonil has developed a tool on Labs that may be able to serve as a replacement. It doesn't currently have much historical data (only going back to September 2013), but it should hopefully be more reliable as it's run by a more active user. http://tools.wmflabs.org/wikiviewstats/?page=Example&lang=en&project=wikipedia Mr.Z-man 16:27, 10 January 2014 (UTC)[reply]

Thanks @Mr.Z-man:. Looks like a nice tool, however a comparison of a few pages stats show the newer tool comes out with a higher figure. Not sure whether thats because Henrik's tool discounts something or there is something else causing that, only checked out on two pages but with a variety of dates.Blethering Scot 16:47, 10 January 2014 (UTC)[reply]
Im wondering if it's redirects or something like that causing higher number of stats. Also what was interesting was if you run American Psycho (musical) on that tool it displays every days stats but adds a note that stats.grok.se was missing at least one day and page stats are lower by 1075. Thats useful buts different to the normally higher figures as doesn't display on all pages when data isn't missing on the other site. States uses dumps-wikimedia.org to get data but appears to check stats.grok.se to see if its missing data, can only assume tool was created for the basis of problems were having.Blethering Scot 17:26, 10 January 2014 (UTC)[reply]
The new tool is more powerful. You can click on a day and see the hourly totals. You can also see the current day partial totals. Can this tool be set to run over the historical datafiles to backfill its data?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 17:56, 10 January 2014 (UTC)[reply]
Its far better i agree, but whats accounting for the higher day to day figures. Also i cant link to a specific page's stats i.e. Kinky Boots (musical) it gives you a ? in domain name not the title of the search.Blethering Scot 18:51, 10 January 2014 (UTC)[reply]
Yes an explanation for the higher totals would be appreciated.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 20:57, 10 January 2014 (UTC)[reply]
He has explained in detail to another user on his talk page. Seems stats.grok.se is on average 10% lower.Blethering Scot 23:13, 10 January 2014 (UTC)[reply]
Victoria's Secret Fashion Show is one where stats.grok.se is 50% higher.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 23:28, 10 January 2014 (UTC)[reply]
Seems against the norm but all you can do is ask him. Seems pretty responsive.Blethering Scot 23:33, 10 January 2014 (UTC)[reply]
The translation tool that I used did not make it clear to me what the difference was. Does anyone understand it. How can some pages be slightly higher and others be significantly lower?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 09:26, 11 January 2014 (UTC)[reply]
Blethering Scot, u say "He has explained in detail". I don't see that. Am I translating the wrong thread. Which thread were you talking about?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 14:41, 12 January 2014 (UTC)[reply]
To be fair, stats.grok.se is treated as an "authoritative" source only because it's been around longest. As there aren't really any official stats to compare to, there's no real way of knowing which one is more accurate. As long as they're generally consistent, it's probably as good as we're going to get. If one tool shows views for an article increasing over time and another shows them decreasing, that would be more of a cause for concern. Even the raw data is not always accurate. Unfortunately, despite high community interest in this, it's not something the WMF seems to be highly prioritizing. Mr.Z-man 00:27, 13 January 2014 (UTC)[reply]
I like this as a replacement. I have inquired about whether it can be backfilled from the datafiles going back to 2007.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 00:35, 14 January 2014 (UTC)[reply]

Proposal : creating an automatic alert for invalid usernames upon new account creation?

Hello Wikipedia Team...great job !

Just an idea : basing on my personal experience, it can be sometimes harsh to make one's first steps as a new contributor (despite the fundamental principles :"Assume good faith" and "don't bite newcomers"...). So here is a small suggestion for Wikipedia's great platform to still improve in conviviality-and especially indulgence towards newbies.. !

(I hope I am addressing the right recepient!)

I would like to suggest that action is taken preventively, so that new users don't infrige the policies and get blocked right after their very first contribution (for instance on ground of invalid username).

Couldn't it be done simply by the same automatic programm responsible for the block? Let it notify the user beforehand that the account he is creating contains words that are likely to result in a block, such as Society, Foundation, Group, etc...

This would prevent the blunt barring a posteriori of good willing contributors, who just wished to contribute to the common knowledge. This type of proactive action is applicable to other domains of course.

For further reading, here is my short story: I assembled material, with the help of a few friends, to create and expand some articles that we thought interesting and missing on Wikipedia. It took us a few days to carefully complete the work (although we are well aware it is still highly perfectible). Putting the first part of the work online, as a token of consideration for my collaborators, I created an account with the name of this (unformal) group. No promotional purposes in that ! (This association is totally non-profit, its goal is mainly to raise public awareness about the environment on a tiny island in the Aegean).

BAM : blocked !

I realize I did unwittingly infrige Wikipedia policy, that is clearly specified. I apologize and wish to correct this. But please consider that Wikipedia's guidelines, policies and regulations span over dozens of pages, making it difficult for newcomers to absorb them all at once.

I suppose most contributers are like us, regular users of Wikipedia who simply wish to contribute to the common knowledge in their turn, in good faith...Assuming that sticking to the Five Pillars is fair enough. Be bold, they say ! So the blunt barring of a user- for an easily remediable problem - seems somewhat brutal. How could it be a motivating pedagogy ?


Still, congratulations for the remarkable achievement of Wikipedia and thank you for this worldwide epistemic adventure.

Lonaïs

Velanidia Foundation (talk • contribs) 14:37, 6 January 2014 (UTC)[reply]

@Velandia Foundation: FYI, the process for checking usernames is not automated, it is an editor based process. But yes you are right that it the terminology is somewhat 'scary'. In this case I would personally suggest we use the term 'locked account' instead of 'blocked account'. The technical result is the same, but it's less offensive to people I think . Also User:Steven (WMF) has promised in the past that there would be further improvements to the Create Account page that would give users more feedback/instructions about the usernames and passwords while you type them. This functionality had been held back for deployment a couple of months ago, but is still planned I think. Thank you for your feedback and please be free to point out any similar problems that you encounter. —TheDJ (talk • contribs) 15:22, 6 January 2014 (UTC)[reply]
We already use the term "locked account" for accounts that can't even be logged in to. How would we differentiate between these situations? Jackmcbarn (talk) 16:37, 6 January 2014 (UTC)[reply]
TheDJ misspelled @Velanidia Foundation: above. See meta:Global locks for the normal meaning of locked account. I think it would cause confusion to have two terms for blocked accounts, also if the terms aren't used for other things. I don't think the poster complains about the word blocked, but about being blocked so quickly. PrimeHunter (talk) 16:57, 6 January 2014 (UTC)[reply]
BTW, one of the reasons we block group usernames is because a user account should only be controlled by one person, and a group name gives the impression it is not. It's not just concerns about promotion. – PartTimeGnome (talk | contribs) 01:49, 7 January 2014 (UTC)[reply]

"I don't think the poster complains about the word blocked, but about being blocked so quickly." Indeed! Thank you PrimeHunter for clarifying. Locked or blocked, neither of those are likely to feel good for a newbie, who just would like to add his little contribution to the grand puzzle. The point is to prevent those hiccups from happening. At least why not give prior notice? Thanks! 18:22, 6 January 2014 (UTC)Velanidia Foundation — Preceding unsigned comment added by Velanidia Foundation (talk • contribs)

I don't see any reason why we couldn't give WP:NOSHARE accounts a few days' warning before blocking them. With WP:Flow, it might even be possible to get automatic follow-up reminders to reduce hassle for the admins. The main complaint in the past is that admins can't track these warned accounts efficiently, so "one week's fair warning, during which you need to get your name changed" turns into "indefinite freedom, because I can't remember who I warned". But if a Flow process automagically told you when the time was up, then you wouldn't have to remember anything. (Hey User:Quiddity (WMF): I want another pony for Christmas, okay?) WhatamIdoing (talk) 19:27, 6 January 2014 (UTC)[reply]
I agree that the problem identified should be addressed. I tried a more comprehensive approach:User naming convention proposal. I still think it has merit, and this proposal is further evidence that there is a problem.--S Philbrick(Talk) 19:52, 6 January 2014 (UTC)[reply]
I have given such accounts warnings before using {{uw-username}}. I was rather disappointed to find that admins block accounts that have been given such warnings rather quickly (after about a day), even if they haven't used the account since the warning. I don't think there's any worry about admins having difficulty tracking warned users. (The template categorises the users into Category:Wikipedia usernames with possible policy issues, making them easy for admins to find.) – PartTimeGnome (talk | contribs) 01:49, 7 January 2014 (UTC)[reply]
@PartTimeGnome and WhatamIdoing: Timer-based workflows (or "reminder Notifications" as my note on the scratchlist calls them) are definitely something Flow aims to improve. Anything from individual-editor-reminders ("A week has passed since I commented on X that I'd be back in a week"), to systemwide-workflows ("category of editors who've been warned for 5 days about username issues, and need followup action"). It's not being rushed, so will take a while to reach that level of complexity, but with our guidance and patience over the coming months, it will fix hundreds of small problems like this. (No more ponies for you, WhatamIdoing, they've all been hired by as extras for some tv show...) Quiddity (WMF) (talk) 00:50, 9 January 2014 (UTC)[reply]

Respects to all of you for considering the issue and various ways to address it. PartTimeGnome, you mention a template that "categorises the users into Category:Wikipedia usernames with possible policy issues, making them easy for admins to find". -Couldn't the same programm simply deliver a warning to the new user (automatically)? Thank you. Lonaïs Velanidia 21:07, 13 January 2014 (UTC) — Preceding unsigned comment added by Lonaïs Velanidia (talk • contribs)

The template is called Template:uw-username, and it does give a warning as well as the category. Click my link to the template to see what the warning looks like. It is only invoked by humans, though, not automatically. To use this automatically, we'd need to define criteria a computer could use to determine which accounts should get the warning. That's the tricky bit, and it could never be perfect – there would be many cases that require human judgement. – PartTimeGnome (talk | contribs) 21:53, 13 January 2014 (UTC)[reply]
I seem to recall that there's a bot (can't remember which one) that files reports at WP:UAA using a filter test - it seems as though it wouldn't be difficult to apply that same filter at account creation. If tripped, it would produce a message along the lines of: "The username you have chosen may not meet Wikipedia's username policy. You may create an account with this username, but please be aware that username violations routinely result in accounts being blocked. Do you want to proceed with this username?" Potentially the wording could differ depending on the filter tripped (e.g. "...because it appears to indicate that you are editing on behalf of a company or organisation" for usernames which include strings like "corp", "official" or "sales"). I'm sure that can't be terribly hard to implement. Yunshui 雲‍水 10:48, 14 January 2014 (UTC)[reply]
That's User:DeltaQuadBot. It's not possible for it to catch usernames before they're registered, though, since there's no data for it to look at until after an account has been registered. This isn't the kind of thing that could be done by a bot. Writ Keeper ⚇♔ 17:21, 14 January 2014 (UTC)[reply]
But bots are the answer to everything... Seriously, though, ignoring the idea of using a bot, how complex is it to introduce a filter at account creation? Is it something that could only be done in the underlying MediaWiki software? Yunshui 雲‍水 09:44, 15 January 2014 (UTC)[reply]

Categorizing non-mainspace redirects

Per discussion on my talk page, is there a better or more obvious way to categorize general redirects located outside of mainspace? There were two suggestions brought up, that we should "consider removing the namespace restrictions on the r from/to plural templates" or that we should "create new 'r from/to plural in non-main namespace' templates". See also here for a more complete discussion. I understand that primarily the {{R from plural}} template is meant to produce the Category:Unprintworthy redirects insofar as to prevent the redirect showing up should a user wish to download files from the Wikipedia website (or Jimmy to construct his book) but there should be an easier way to categorize non-mainspace redirects. TeleComNasSprVen (talk • contribs) 18:35, 6 January 2014 (UTC)[reply]

There would be no need for a separate "R from plural in non-mainspace" template. {{R from plural}} could use a template like {{main other}} to detect where it is used, and output the appropriate categories for that namespace. In fact, I see it already does so – Category:Unprintworthy redirects is omitted when the template is used outside of mainspace.
As for Category:Redirects from plurals, this is a tracking/administration category, not an article category, so IMO there's nothing wrong with it containing redirects from mixed namespaces. The main question to answer is if there is any benefit in splitting main and non-main redirects, or would it just make things more awkward? – PartTimeGnome (talk | contribs) 01:17, 7 January 2014 (UTC)[reply]
The problem is that I don't see it categorizing non-mainspace redirects into Category:Redirects from plurals even if it says it does, which it honestly should. I'm fine with excluding it from Category:Unprintworthy redirects as things outside of mainspace should not be printed in the first place. TeleComNasSprVen (talk • contribs) 23:37, 7 January 2014 (UTC)[reply]
The sub-cats of Category:Cross-namespace redirects – Wbm1058 (talk) 01:25, 11 January 2014 (UTC)[reply]
{{R from plural}} uses |main category=Redirects from plurals, so only mainspace pages are placed in that category. To apply to all pages, each use of main category should be changed to all category (these parameters are passed to to {{Redirect template}}). – PartTimeGnome (talk | contribs) 18:06, 11 January 2014 (UTC)[reply]
I am the user who started the discussion in question. I never really thought that creating a separate template/category was the best idea; i.e., I am slightly in favor of just removing the namespace restriction, but it might be good to know who added that restriction in the first place and whether there was any previous discussion. I have no strong objections to anything here. --SoledadKabocha (talk) 16:37, 16 January 2014 (UTC)[reply]
The technical restriction was added by Paine Ellsworth in June 2011, with the edit summary "standardize with Template:R to plural". This was part of a larger rewrite of the template. Template:R to plural has the same restriction, which was added as part of a similar rewrite by Mclay1 in February 2011. The mainspace-only restriction was added to the documentation of both templates more recently (August 2013), again by Paine Ellsworth. – PartTimeGnome (talk | contribs) 21:37, 18 January 2014 (UTC)[reply]

A lua module should be able to automatically detect the categories that are needed. John Vandenberg (chat) 18:30, 16 January 2014 (UTC)[reply]

I wish there were an easy way to have Special:WhatLinksHere optionally (or even by default) not include links that only link through navigational templates. It there are way? Could there be?

My problem is that when I look at Special:WhatLinksHere for an article to find other articles with an interest in this article, the results can be overwhelmed by links that only exist in a navigation template. Now while navigation templates are good, the incoming links they generate are not so useful. --SmokeyJoe (talk) 00:12, 10 January 2014 (UTC)[reply]

AFAICT, this can't be done right now. I'd like it, too.
Does anyone know if this could be handled by a user script, or if we'd need the devs to support it? WhatamIdoing (talk) 01:14, 10 January 2014 (UTC)[reply]
It's a frequently requested feature but the developers will not implement it. See for example bugzilla:1392 and bugzilla:3241. PrimeHunter (talk) 01:17, 10 January 2014 (UTC)[reply]
It's bugzilla:1392. I believe that priority setting translates to is "if you write it, then we'll (maybe) merge it, but we won't spend any time on this ourselves".
Could something be built at Labs to produce the same effect? It doesn't have to be onwiki. WhatamIdoing (talk) 01:22, 10 January 2014 (UTC)[reply]
It would require a re-design of the database in order to achieve it. Right now all links (from templates, Lua, and article text) are combined, duplicates are removed, and the resulting list is in the database. Werieth (talk) 01:24, 10 January 2014 (UTC)[reply]
Would the redesign be so bad. Exclude all links from transcluded templates, but keep the links from the template itself? --SmokeyJoe (talk) 03:43, 10 January 2014 (UTC)[reply]
The link tables in the database only store that a link is from a given page, but not whether the link is from a template. A new field could be added to store this, of course. Adding a new database field is not to be done lightly, but isn't that bad. The bad bit is figuring out what to put in it. The MediaWiki parser expands all templates in a page before it parses the expanded wikitext for links. Even if MediaWiki tracked which bits of text came from the original page and which came from templates, there are many cases where it is ambiguous whether the link is from a template or the page:
  • Where a link is passed in a template parameter, does it "belong" to the template? Common sense says the link belongs to the page passing the parameter, but tracking parameters as they pass through a template to ensure the appropriate links in the template's output are considered to belong to the page would be very tricky.
  • The most common one is a template that constructs a link based on parameters passed to it. The link is not in the page nor in the template, but is only present when the two are combined.
  • Consider a template {{X}} that contains "Page]]". A page uses this template as "[[Main {{X}}". Believe it or not, this is valid wikicode that produces the link Main Page. Since the link is split between the containing page and the template, does it "belong" to the template or the page?
A simplistic solution is to ignore all links from a page that are also links from templates on that page. This still has problems: If a page directly links to something that is also linked by a template on the page, the direct link would be ignored. Furthermore, links in a template inside <includeonly> or that are only output under certain conditions do not count as links from the template. With this simplistic approach, they'd count as belonging to the pages that contain the template which is probably not what most would expect. – PartTimeGnome (talk | contribs) 22:03, 11 January 2014 (UTC)[reply]
What if the MediaWiki parser didn't expand templates in a page before it parses the expanded wikitext for links? --SmokeyJoe (talk) 22:39, 11 January 2014 (UTC)[reply]
Then "what links here" would be useless for the exercise that I described at 21:52, 10 January 2014 (below). The goal was to locate pages with a link to Chapel-en-le-Frith railway station; but some of the links to that were (and still are) constructed using {{stnlnk|Chapel-en-le-Frith}}. This template is commonly used across pages dealing with railway stations whose article names are of the form "Foo railway station", but when linking to that, you just want the "Foo" part to be displayed. So, {{stnlnk|Chapel-en-le-Frith}} displays as Chapel-en-le-Frith and so is exactly equivalent to [[Chapel-en-le-Frith railway station|Chapel-en-le-Frith]] but occupies significantly less wikicode. --Redrose64 (talk) 23:39, 11 January 2014 (UTC)[reply]
(edit conflict) That would be a major rewrite of the parser. It would effectively need to parse each template separately from the page transcluding it, rather than expanding everything and parsing once. With each template parsed separately, any given markup in a template would need to be self-contained within that template (no splitting markup across templates). This would break existing pages that rely on templates being used in combination. I really hope no real uses of my split link example exist, but we do have things like {{collapse top}} and {{collapse bottom}} that are designed to be parsed together. We also have templates that combine to make tables, with each table row being a separate template. There are also subtler effects such as the way line breaks inside and outside templates can combine. (There might be ways around such issues, at the expense of further complexity.)
These changes would affect normal transclusion, but substitution would continue to work as it does now because it expands templates when an edit is saved, before the page is parsed. The increased differences between the two might confuse editors further.
Note that this still doesn't correctly resolve some of the ambiguities I mentioned. E.g. links constructed by a template based on parameters would be treated as links from the template, even though their destination is specified by the containing page.
I understand the developers want to rewrite the parser, but this is a long way off, and some of the changes will require a conversion process for existing pages. – PartTimeGnome (talk | contribs) 23:50, 11 January 2014 (UTC)[reply]
We can expand on the idea of skipping pages that link to a page and also use a template. Have two lists: One of pages that don't use the template and one of pages that do. With the second list, it should be simple enough to write a little program that reads the list and looks at each pages' ?action=raw to find bracketed links to the desired page(s). Overly convoluted, I know, but it should get the desired result. moluɐɯ 15:00, 13 January 2014 (UTC)[reply]
Not quite the desired result, though, since it still wouldn't handle non-bracketed links, such as Redrose64's {{stnlnk|Chapel-en-le-Frith}}. – PartTimeGnome (talk | contribs) 22:13, 13 January 2014 (UTC)[reply]
Hmmm. How many templates are there like that? and how similar are they to each other? If the majority of them create a link in a way that's as simple as what you linked, it might be worthwhile to take the page source reader idea a step further to include simple link creating templates like that. moluɐɯ 17:14, 14 January 2014 (UTC)[reply]
See Category:Internal link templates. There appear to be many such templates. There are also some linking templates not in that category. Citation templates can take an authorlink= parameter; some info-boxes take a page name in a parameter to produce a link. – PartTimeGnome (talk | contribs) 23:41, 14 January 2014 (UTC)[reply]

Workaround

What I used to do (and this still works but takes much, much longer than it did before) was to edit the navbox so that the link that I was interested in was modified in some way, but not actually broken - such as going through a redirect, like this. Over the coming minutes, whilst the job queue was updating the link tables, I would monitor "what links here" for the page that I was interested in. Once it stopped growing shorter, I would wait ten or fifteen minutes more to make sure, and then I would make any edits consequent on the remaining incoming links. Having completed that task, I would then revert my edit to the navbox, like this. However, in about May or June 2013, something happened to the job queue so that the wait is now measured in days or even weeks instead of minutes. It's just not practicable any more. --Redrose64 (talk) 21:52, 10 January 2014 (UTC)[reply]

@Redrose64: I think this was Template:Bug; see Wikipedia:Village pump (technical)/Archive 114#Null edits. --  Gadget850 talk 12:11, 11 January 2014 (UTC)[reply]
Well there's an idea. Require that all templates link only to template-redirects. Then you sort out the link-heres that link directly vs. those that link through template-redirects. And you would know that everything linking through a template-redirect was transcluding a template. So for example I have a template {{tools}} and one of the links in it is [[hammer-redirect|hammer]] hammer-redirect is just a redirect to hammer. When I look at what-links-to-hammer then I can ignore the pages coming through hammer-redirect. Yes, I know this would be a lot of extra work and is an idea that likely won't fly. The problem is editors who think that templates are a replacement for the category system and that every article in a broad topic area needs to be loaded up with template directories to everything remotely related to the topic. I'm frustrated with the amount of null-edits I need to make to thoroughly clean up after making certain changes. Wbm1058 (talk) 01:48, 11 January 2014 (UTC)[reply]
@Redrose64 and Wbm1058: ...except that redirect links in navboxes break functionality, because they do not show up in bold and unlinked when viewing that article, which hinders navigation through the articles in the navbox. Because of this, WP:NOTBROKEN specifically advises fixing redirect links in navboxes to point directly to the article in question. jcgoble3 (talk) 06:33, 11 January 2014 (UTC)[reply]
Oh, yea, right, I forgot about that. No, I actually bypass redirects in templates, in order to make the link appear in boldface. Wbm1058 (talk) 14:37, 11 January 2014 (UTC)[reply]
I didn't intend my post as advice to leave the redirect in permanently - I did know about the boldface feature, which is why I put "Having completed that task, I would then revert my edit to the navbox, like this". That edit eliminated the redirect (which was only intended to be temporary) so that the boldface showed again. --Redrose64 (talk) 15:49, 11 January 2014 (UTC)[reply]
  • ick.. no wonder the job queue is overloaded half the time... I've been working on some core enhancements to Special:Userlogin today, but tomorrow I would be happy to look into writing a userscript to filter out the unwanted links... Can someone give me a clear cut example of what is expected to be done? Like: "get rid of all links generated by Template:Bar on WLH for Foo" is what I currently think you want, and that should be easy via js. Technical 13 (talk) 02:19, 11 January 2014 (UTC)[reply]
    • I really have no idea whether my null edits have any impact on the job queue or not. Just a vague idea of how the job queue works. I've made changes where I needed to find every article that truly linked to a particular article and make real edits to those articles. But I have to sift through a forest of "fake" links via navigation templates. To clear that forest, I make null edits. Can't recall the situations exactly, but I think certain page moves, i.e. article title changes, comes to mind. Wbm1058 (talk) 14:37, 11 January 2014 (UTC)[reply]

Deletion warning in new version of MediaWiki

With the latest update, we get a warning when attempting to delete most pages: "Warning: Other pages link to the page you are about to delete". Most of the time, a page's creator will be warned about its deletion, many deletion-taggers log their tagging on a dedicated page (example), and many pages in CAT:CSD will end up being linked by userspace or WPspace pages (example) that are set up to track CSD-tagged pages. Is there any benefit to using it here, or any benefit to paying attention to it? Nyttend (talk) 06:36, 10 January 2014 (UTC)[reply]

I haven't tried it myself yet, but it sounds like it would be very useful if it could be configured to display a warning if the page had incoming redirects or transclusions, rather than just links. And maybe links from mainspace would be useful too? — Mr. Stradivarius on tour ♪ talk ♪ 07:45, 10 January 2014 (UTC)[reply]
This was the result of feature request 35485 —TheDJ (talk • contribs) 07:51, 10 January 2014 (UTC)[reply]
I would add that this feature is probably more useful for small wikis. Pages up for deletion here will almost always have incoming links. I suppose we could just blank the message if we don't want it. — This, that and the other (talk) 10:10, 10 January 2014 (UTC)[reply]
Restrict it to mainspace links, redirects, and transclusions, and I'd welcome it, and I can see how this would be much more of a thing for smaller wikis. Wouldn't complain about blanking either. Nyttend (talk) 23:02, 10 January 2014 (UTC)[reply]
I agree with Nyttend. The message as it is is meaningless, and I would welcome a facility to turn it off, because it will be a very rare page which doesn't have any incoming links. JohnCD (talk) 23:08, 10 January 2014 (UTC)[reply]
some more spaces where the warning is desired come to mind: template, portal, book, help, and possibly others. it probably should be fine to mask links from talk spaces (including all the "XXX talk"), WP and user space. peace - קיפודנחש (aka kipod) (talk) 18:14, 11 January 2014 (UTC)[reply]
I agree with everything said above. I've seen two situations where this feature would have been useful:
  1. Someone mistakenly G6-tagged a couple of templates that were in use. An admin deleted them without checking properly (the templates were subsequently restored). A warning that the template still had transclusions would have prompted the deleting admin to check more carefully.
  2. I've found a couple of broken redirects left behind after deletions. A warning to the deleting admin would prompt them to delete or re-target these redirects.
For this feature to be useful, it needs to only warn about those cases that matter. Counting links in notifications left on talk pages and in deletion discussions means the warning will appear for almost every deletion, so will be ignored. There are many possible enhancements we could suggest on Bugzilla to make this more useful. – PartTimeGnome (talk | contribs) 22:17, 11 January 2014 (UTC)[reply]
The feature, as is, would probably end up being ignored due to banner blindness; unless we end up having some means of showing the warning only when it's likely to matter, we're better off removing it completely. (And some times speedy-deletable pages will have incoming mainspace links - either created by the author of the speedy-deletable page, or a user created a speedy-deletable page with a linked-to title.) עוד מישהו Od Mishehu 08:55, 12 January 2014 (UTC)[reply]
  • Thank you. Is there any way that we could make it default for everyone, e.g. putting it into the site JS? Or would this be overkill, since it would load for all non-admin users as well, and on every page? Nyttend (talk) 01:00, 14 January 2014 (UTC)[reply]
Sounds good WK. All we need is mainspace links and transclusions, not everyone's CSD list and talk page mention. So far, I think I've seen one or two pages where this thing didn't appear. Peridon (talk) 11:29, 14 January 2014 (UTC)[reply]
Err, how does one install it? I probably should know, but I do very little technical twiddling these days... Peridon (talk) 11:31, 14 January 2014 (UTC)[reply]
@Peridon: Sure, just add importScript("User:Writ Keeper/Scripts/backlinkWarner.js"); to your common.js page. Writ Keeper ⚇♔ 17:55, 14 January 2014 (UTC)[reply]
That won;t have had any effect. A link to a user page (which is all that a ping is) only trigers a notification if it is signed as part of the same edit. If you want to ping Peridon, you need to create a new signed edit, as I jsut did. DES (talk) 18:02, 14 January 2014 (UTC)[reply]
Yeah, I know that. I actually deleted my old sig on that post and replaced it with new tildes, since I know it's dependent on the post being signed, but apparently that's not enough. Writ Keeper ⚇♔ 18:05, 14 January 2014 (UTC)[reply]
Oh I failed to notice you had replaced the sig. Maybe that was enough then, I'm not sure. Well, no harm done if s/he gets 2 pings. DES (talk) 18:16, 14 January 2014 (UTC)[reply]
Actually, I don't think it was; after I did it, I got to wondering whether it worked; tested it from my test account, and it didn't seem to, so... Writ Keeper ⚇♔ 18:30, 14 January 2014 (UTC)[reply]
Thanks. Only one ping - from DES. I'm a 'he', by the way. Peridon (talk) 18:37, 14 January 2014 (UTC)[reply]
For an edit to trigger a user mention notification, Echo looks for signature-like text being added to the page: a full timestamp and a link to the editor's user, talk or contributions page. Writ Keeper's ping overwrote a previous signature; much of the new signature text was the same as the old, so did not count as being added to the page. – PartTimeGnome (talk | contribs) 23:56, 14 January 2014 (UTC)[reply]
@Writ Keeper: You shouldn't use "wgTitle" because it will leave the namespace part out. For example, if I am deleting Template:Navbox, there will be no message "There are pages that transclude this page" because wgTitle = "Navbox", not "Template:Navbox". --Nullzero (talk) 06:21, 15 January 2014 (UTC)[reply]

Search index not being updated

It appears that the index has not been updated for 4 or 5 days. Can we get it running again? Chris the speller yack 05:40, 11 January 2014 (UTC)[reply]

I'm not sure, but it might be because they are building the index for the new search engine that is going to launch soon. —TheDJ (talk • contribs) 11:28, 11 January 2014 (UTC)[reply]
Thanks. That's either very reassuring or very scary; I'm not sure which. Chris the speller yack 17:59, 11 January 2014 (UTC)[reply]
Until we know when "soon" actually is, rather than when it is meant to be, I'm assuming very scary. Arjayay (talk) 18:25, 11 January 2014 (UTC)[reply]
There was a blogpost with a link to timeline. So as you can see it is beta only and then there will be a bigger announcement when it leaves beta. I'll ask a sysadmin about the status of updates to the current index. —TheDJ (talk • contribs) 13:08, 12 January 2014 (UTC)[reply]
Bugzilla 59979 [2] has been created for this problem. Chris the speller yack 03:52, 13 January 2014 (UTC)[reply]

I'm sure this is not a new issue, just as I'm sure the job queue is tied in to why the Search is not working on new articles. As I go down the list of DYK nominations, I've noticed that articles created within the last few days don't show up on a search, as if the articles do not exist at all. I created a new article 16 hours ago, which naturally does not come up in Search. But also, I noticed where I had placed a link to the new article in other articles, the link in the other article showed as a redlink, while running my mouse over the redlink gave me a popup of the new article's lead paragraph. To get rid of the redlink, I had to do a null edit on the article containing the redlink. — Maile (talk) 13:37, 11 January 2014 (UTC)[reply]

I think old pages are being lost from the search index somehow. If I start typing "Semper fi", the suggestions include "Semper fidelis" so long as I have just entered "Semp" or "Sempe"; but if I get as far as "Semper", then nothing is offered. It's as if I'd mistyped, when in fact I'm certain that the spelling "Semper" is correct. --Redrose64 (talk) 18:57, 11 January 2014 (UTC)[reply]
i do not see the same phenomenon, and i predict you won't see it either if you repeat the same experiment. as each letter typed causes a new AJAX call, it's possible that one of those calls went berserk for whatever reason (maybe for a short while all of them did), and the suggestion mechanism had a brain-fart. i do not think this is related in any way to "old pages". peace - קיפודנחש (aka kipod) (talk) 20:58, 11 January 2014 (UTC)[reply]
Thanks, I look forward to their answer. It is now a whole week since it was updated, and us poor little WP:WikiGnomes will be swamped with spelling corrections etc. as it is, without any further delays. Arjayay (talk) 19:25, 12 January 2014 (UTC)[reply]

We haven't started building the new search index just yet (we are going to start in about 12 hours from now). And once we do, that won't have anything to do with the old search index not updating (we're running both in parallel for redundancy). Also, the job queue is not used for updating the old search index, it's done by a daily cron at about 1am UTC. The new search index will be done via the job queue via their own prioritized queue so it should be much faster :) I'll be posting here tomorrow about the new search some more when we start the indexing process. I'm having a look at the lsearchd indexer right now, will follow-up if I find anything interesting. ^demon[omg plz] 05:18, 13 January 2014 (UTC)[reply]

We haven't found an answer to the broken old search yet. Nik and I both have been taking a look at it. ^demon[omg plz] 17:09, 13 January 2014 (UTC)[reply]
Ok, so the search indexer was restarted about a week ago, but the jobs to index don't seem to have restarted. We're pretty sure we've fixed this and they'll begin indexing overnight like before. I hate the once-per-day updates :( ^demon[omg plz] 00:29, 14 January 2014 (UTC)[reply]
The index updater has caught up to reality. Thanks to all who helped get this fixed. Chris the speller yack 21:44, 15 January 2014 (UTC)[reply]

Rethinking the entire CSS framework

Main page: Wikipedia:New CSS framework
The Senate side of the United States Capitol in Washington, D.C.

I have been toying with this idea in my head recently, for redesigning most of the current CSS in Common.css. Instead of singlular blocks of CSS geared towards each template separately, it would be much more efficient breaking them up in smaller entities that can be reused by all templates. So instaed of one large block dedicated only to {{navbox}}, there would be several smaller blocks describing borders, headers and the like, which are in turn used by multiple templates. This involves some work, but I want to poll the idea and see if this is feasable. One major benefit is eliminating the many occurences of duplication. It would also make design easier and more consistent, while still allowing flexibility.

This sprang to mind when I thouhgt about redesigning individual templates; doing each one separately is way to much work and very inefficient. Why not use a modular and reusable CSS framework that can be employed by all templates? As a side note, this gives a great oppurtunity to refresh the aging look of many templates. As an example, all floating element would look like the thumb image (the only element that would need a change in core) on the right. A consistent look also comes across much more professionally. Thoughts? — Edokter (talk) — 15:17, 11 January 2014 (UTC)[reply]

I'd support this idea. Jackmcbarn (talk) 16:07, 11 January 2014 (UTC)[reply]
  • support. You are certainly an expert in CSS and I would follow your lead here. --  Gadget850 talk 16:12, 11 January 2014 (UTC)[reply]
  • Support I do give this proposal. Modular code is the way to go. I'm somewhat of an intermediate css person myself, let me know if I can be of any assistance in developing the prototype. Technical 13 (talk) 18:26, 11 January 2014 (UTC)[reply]
  • Comment @Edokter: I'd strongly recommend posting to the Design list about this. There are a number of volunteer and staff mediawiki devs and designers, who watch that list, that might be interested, including the folks who are implementing LESS in mediawiki core (See mw:CC/LESS for details). HTH. –Quiddity (talk) 00:13, 12 January 2014 (UTC)[reply]
    • @Quiddity: This mainly concerns local templates and CSS in Common.css. Is LESS going to be supported from Common.css as well? In that case, I may ping the list. (But as I understand it, LESS is only supported in core CSS.) — Edokter (talk) — 00:32, 12 January 2014 (UTC)[reply]
      • @Edokter: There's nothing stopping LESS from being supported via, say, MediaWiki:Common.less and similar pages – it was just not done yet because everyone was eager to get support for it in core out, and allowing user-supplied LESS to be parsed would require considering various security issues, which obviously takes time :) (For example, you can use @import to load other LESS files – it would have to be disabled in the parser for usages from wiki pages, or some core files could be whitelisted, or it could embed other wiki pages – and AFAIK none of these are possible to do by just toggling a setting right now.) Matma Rex talk 01:01, 12 January 2014 (UTC)[reply]
        • That's not helping much here. In either case, that doesn't stop us from creating a new framework here. — Edokter (talk) — 01:55, 12 January 2014 (UTC)[reply]
        • See bugzilla:54864 for one step towards that. I think there are more discussions (on either a mailing list, or one of the numerous wikis or bug tickets) but I can't find them. That's another reason to ping the design list! HTH. –Quiddity (talk) 01:58, 12 January 2014 (UTC)[reply]
        • If I may suggest something, then for the love of all that is holy, do not ping the design list. You will not gain anything through the experience, but you will get to admire truly impressive amounts of stillborn ideas and overblown egos. When you do need design input, ask someone directly. The list can sometimes be useful when you already have concrete ideas with proof-of-concept implementations and several people readied to put out any fires of stupidity that will inevitably start spreading. Matma Rex talk 02:43, 12 January 2014 (UTC)[reply]
  • Conditional support; while this sounds like a great idea, I'd want design changes to be separate from the code structure changes insofar as that's possible. Without that, I fear that the improvements that the code structure changes represent would be mired in frustrations with the specifics of the design changes. {{Nihiltres|talk|edits}} 03:12, 12 January 2014 (UTC)[reply]
  • Support. I fully trust Edokter with our CSS, I know he knows what he is doing, and I think this will set us up to be able to improve our tired-looking styling. — This, that and the other (talk) 09:51, 12 January 2014 (UTC)[reply]
  • Note that it is very likely that at some point in the next 2 years we will see CSS that is bound to templates. This is to cleanup the pervasive use of inline styling in templates while at the same time not serving every page with a ton of unused styling statements. Additionally, we have of course a lot of classes that double as semantic classes so we would have to be careful there as well. —TheDJ (talk • contribs) 13:00, 12 January 2014 (UTC)[reply]
  • Support but raise parser limits: While condensing the massive CSS classes and style text will reduce size, there is also the need to support longer page names, as more people split mega-articles into long-named subarticles, and the wp:post-expand include size needs to be larger (3 MB?) to support longer page names as well as all the massive CSS style tags which have swamped the parser with long-winded style text. -Wikid77 19:56, 12 January 2014 (UTC)[reply]
    Parser limits have nothing to do with this proposal. – PartTimeGnome (talk | contribs) 22:24, 13 January 2014 (UTC)[reply]
  • I'm all for modularity and reusable code, so this makes a lot of sense to me. Anything that can reduce our dependency on inline styling counts as a big step forward in my opinion. I'm thinking that we should have a transition period where both the old-style and new-style classes are available, so that our major templates can be moved over to the new system, but I suppose whether this makes sense or not will depend on the details of the implementation. — Mr. Stradivarius ♪ talk ♪ 07:54, 14 January 2014 (UTC)[reply]

Template:Infobox animanga/Video and Wikipedia:Categories for discussion/Log/2014 January 3#Films by country and year

Wikipedia:Categories for discussion/Log/2014 January 3#Films by country and year was closed as double upmerge and delete. Unfortunately, some of the categories are being populated by {{Infobox animanga/Video}}. Can some user please help with removing/fixing the code which populates these categories in this template? עוד מישהו Od Mishehu 16:53, 13 January 2014 (UTC)[reply]

I think this edit has fixed that. Thanks. Lugnuts Dick Laurent is dead 19:56, 13 January 2014 (UTC)[reply]
Yes, it works. Thanks - I can't handle complex tempaltes like this one. עוד מישהו Od Mishehu 17:35, 15 January 2014 (UTC)[reply]

CirrusSearch now enabled

Hi all. The exciting day of new search is upon us. We've just enabled the new search backend for enwiki and we're starting to build the index now. What does this mean for your searches? Nothing yet. Right now you can only engage the new search engine via url parameters (&srbackend=CirrusSearch for API & Special:Search). Once we get the index built, we'll look at turning it on as a Beta Feature so more people can try it out. I'll keep this thread updated with indexing progress (honestly, we don't know how long enwiki will take just yet). As the index fills out you'll start to see more and more reasonable results. If you see any problems relating to the new search (Cirrus, elasticsearch, any term like that), please please let me know so we can fix it. Things should be mostly invisible to everyone right now while we're building things out, other than you'll see the job queue rise some (we'll be keeping an eye on it and try not to flood it). Thanks everyone! ^demon[omg plz] 17:14, 13 January 2014 (UTC)[reply]

Confirmed CirrusSearch matches pages changed within prior minute: Although the overall search-index is still being populated, we can already run instant near-real-time searches (including pages updated within recent minutes) by using the new CirrusSearch backend on typical Special:Search for text. For example, to search template-talk pages about recent "custom-text parameters" being discussed, use:

• https://en.wikipedia.org/wiki/Special:Search/?search=Template_talk%3A%20%22custom-text%20parameters%22&srbackend=CirrusSearch

Note the template-talk prefix is "Template_talk%3A" where colon ":" is encoded as "%3A" and spaces are "%20" in the URL encoding. Alternatively, just run a typical wp:wikisearch (MWsearch), and then rerun the URL with "&srbackend=CirrusSearch" appended, to also search pages recently edited within the prior minute. -Wikid77 08:40, 14 January 2014 (UTC)[reply]

You can also float pages with more recent edits to the top using some somewhat cryptic syntax. I don't know if that is useful for you.
• https://en.wikipedia.org/w/index.php?title=Special%3ASearch&profile=default&search=Template_talk%3Aprefer-recent%3A1,10+text&fulltext=Search&srbackend=CirrusSearch
The "1" means scale the whole document score and the "10" means that the half life of the score should be 10 days. You can leave off either or both of the numbers to get the defaults that are used on wikinews: 60% of the score is scaled at a half life of 160 days. NEverett (WMF) (talk) 20:26, 14 January 2014 (UTC)[reply]


Update on indexing status: we're churning away. Just passed the 9 million document mark, which is good. Trying to find ways to speed it up all the time. ^demon[omg plz] 20:11, 14 January 2014 (UTC)[reply]

Template sort appears to not give the correct sort key

I'm probably getting blind, can someone else see why my sort doesn't work. Please see article 2014 European Allround Speed Skating Championships. In it, I have prepared the sort key like this {{sort|24|NQ24}} where I want to indicate both placing and that the skater didn't qualify for participation in subsequent events. In three of of four tables, it work as it should, but in the fourth – the second "Ranking after three events" section, the one for women – it doesn't.

Check the sort order by clicking first on "Skater", then back to "Rank". As mentioned, it works for the first three similar tables, but not the fourth. Why? Why? (to quote Nancy Kerrigan) ;-)

I would be greatful if someone could point out what I'm obviously missing. Will have get my eyes checked?

Thanks

HandsomeFella (talk) 20:32, 13 January 2014 (UTC)[reply]

The type auto detection only looks at the first few rows, for reasons of efficiency. Forcing it will give more reliable results (and ideally should be done for most more complicate cases where you are using table sorting —TheDJ (talk • contribs) 20:54, 13 January 2014 (UTC)[reply]
(edit conflict) The thing to remember is that whatever data you put into it, {{sort}} emits a text string. In the first three tables, you haven't used {{sort}} until the eighth row or later, and the sorting software has been able to work out from the first few entries that the column contains primarily numeric data, and so should be sorted numerically. But in the fourth one, the first use of {{sort}} is in the third row, and {{sort|3|WD3}} expands to <span style="display:none;" class="sortkey">3 !</span><span class="sorttext">WD3</span> - that exclamation mark causes the sorting software to believe that the cell isn't purely numeric, and so the column should be sorted as text: 1, 10, 11...19, 2, 20, 21...29, 3 etc. --Redrose64 (talk) 20:57, 13 January 2014 (UTC)[reply]

Brilliant! Mille grazie. I'll try to remember that. HandsomeFella (talk) 21:20, 13 January 2014 (UTC)[reply]

Just one question: why does the template produce an exclamation mark there? HandsomeFella (talk) 23:25, 13 January 2014 (UTC)[reply]
It was added with this edit, replacing a &#xfeff; BOM. The final version of the relevant discussion is here. --Redrose64 (talk) 23:53, 13 January 2014 (UTC)[reply]

Jakebot help - was directed here from the Teahouse

Hi,

I've been trying to run a bot and have been trying to work out editing using the API, but it doesn't appear to work. The code is: 

       Socket s = new Socket("en.wikipedia.org", 80);
       PrintWriter out = new PrintWriter(s.getOutputStream());
       out.print("POST "+ "/w/api.php" + "?action=edit&format=json&title="
               + "User%3AJakebot%2FTest%20report&text=foo&"
               + "token=1a783fff5b06fd636a301606d67b629d+\\&"
               + "summary=Test");
        Scanner in = new Scanner(s.getInputStream());

And yes, I make sure to get the correct token from [3] before running it. Any ideas? --Jakob (talk) 22:42, 13 January 2014 (UTC)[reply]

The code you have there isn't speaking proper HTTP to the server. Why don't you use a library/framework that will handle all the details of the HTTP protocol for you, including processing cookies correctly and such? Anomie⚔ 13:38, 14 January 2014 (UTC)[reply]

WikiProject Military History Lag.

WikiProject Military History is experiencing lagging. "We" (the WikiProject) is experiencing lagging inseveral areas. I am using Internet Explorer, and I clean my internet browser several times a day, yet I still see articles there. Please see the following:

Adamdaley (talk) 06:45, 14 January 2014 (UTC)[reply]

  • Directly check categories in page, not sub-pages: The system has become very slow to update nested sub-pages, and so try to simplify massive status pages to directly list the categories and related counts. For example:
It is better to avoid nesting the layer upon layer upon layer of obtuse nested pages, where most people do not even know where the nested crap is coming from. Many wp:WikiProjects have created these uber-complex status pages which lag behind the actual counts. If you are not allowed to simplify the status pages, then create one in your own user-space to directly check {{PAGESINCATEGORY:}} for each category count. Then edit that status page, and rerun "Show-preview" when wanting to see the current counts. Otherwise, to update the whole massive status page, you will need to run a wp:null_edit to force all the sub-pages to update and re-render the whole page with current details. -Wikid77 (talk) 09:12, 14 January 2014 (UTC)[reply]
There is anything I can do to stop this? There has to be a way? If so please explain it in a way that I can understand it. Adamdaley (talk) 07:06, 15 January 2014 (UTC)[reply]
hello? How can I stop this? Adamdaley (talk) 23:10, 16 January 2014 (UTC)[reply]

Item appearing in watchlist-changes list, but is not being watched

I notice this morning that Wikipedia:Village pump (proposals) (and its talk page) is appearing on my watchlist-changes list, but I'm not watching it - it does not appear in "edit watchlist" or "edit raw watchlist", and when I visit the page the tab reads "watch", not "unwatch". I did make an edit on that page on 9 December last, which is now archived, but the page would not have stayed on my watchlist for more than a few days. That is the only page affected. Does anybody know what the problem is likely to be? Thanks Rwxrwxrwx (talk) 10:12, 14 January 2014 (UTC)[reply]

Bug: MathJax processes "script error" messages

Tracked in Phabricator
Task T57675

View this post with MathJax enabled: Script error: You must specify a function to call. and Script error will look like . This leaves me unable to read the error message after MathJax mangles it. Keφr 16:38, 14 January 2014 (UTC)[reply]

"Cite Journal" template shortcut on Edit Toolbar not working properly

Hi folks,

This is frustrating -- the "Cite Journal" template in the editing toolbar (at least the one I see) is not working properly all of a sudden (I don't know how long this has been going on, since I don't think I've used in a month or so). If one clicks "Cite Journal", the "Cite Book" template pops up instead! It is missing all of the critical ingredients of the "Cite Journal" template, like PubMed number, DOI number, and so forth. I tried to make some manual adjustments after I filled in the fields in the "Cite Book" template that in now the only one available, but it's still not working correctly. Even odder is the fact that though the edit toolbar clearly titles the template "Cite Book" (instead of the "Cite Journal" requested), when one clicks "add citation", the resulting citation text reads <ref>{{cite journal}}</ref>, even though it's clearly not and doesn't have the normal journal fields.

Anyway, this is really really frustrating for those of us citing medically related articles, and so forth. BTW, I've checked this on Chrome and on IE, and it's the same glitch on both.

Can someone please restore the "Cite Journal" template to its former correct state, complete with the proper name, and the PubMed number field, DOI number field, and so forth? Thank you. Softlavender (talk) 23:41, 14 January 2014 (UTC)[reply]

It works for me. You can ask at Wikipedia:RefToolbar, but there hasn't been a lot of activity. --  Gadget850 talk 09:07, 15 January 2014 (UTC)[reply]
Just to confirm, I'm getting the standard journal form to fill in as well (Chromium 31). What happens if you try selecting cite web/news/book? Andrew Gray (talk) 17:15, 15 January 2014 (UTC)[reply]
After a little digging, MediaWiki:RefToolbarLocal.js is the local version of the configuration code - it's not been altered since October. I suspect this is a local glitch on your computer, though I have no idea what's causing it! Andrew Gray (talk) 17:17, 15 January 2014 (UTC)[reply]
None of the "Cite" tools work for me, but they never have in IE11 (no sarcastic comments please). That includes all the "Templates", the "Named references" and the "Error check"; furthermore the "Link", "Embed file" and "Reference" icons on the initial toolbar do not work either. Of course, "Search and replace" hasn't worked on IE for several years. The templates sometimes work in "Compatability view" but that uses the old, simplified, drop down menus and creates other problems. Arjayay (talk) 17:31, 15 January 2014 (UTC)[reply]

Templates on List of PlayStation 3 games not showing up

Screenshot showing the problem

Hello. I experienced some problems on List of PlayStation 3 games where templates after the “Viking: Battle for Asgard" entry are not showing up, and I suspect this is a server problem. The full explanation of the problem can be found on Talk:List of PlayStation 3 games#Templates not showing. Thanks a lot! Zhaofeng Li [talk... contribs...] 09:41, 15 January 2014 (UTC)[reply]

It is in the hidden Category:Pages where template include size is exceeded. See Wikipedia:Template limits. --  Gadget850 talk 10:12, 15 January 2014 (UTC)[reply]
Oh, I see. However, it needs to be fixed since it affects both editors (saving a tiny edit takes over a minute) and readers (confusing links leading to confusing template pages). I think splitting the long list into short ones by their initials is a good workaround. Is there any bot that can do this automatically, or we have to do this manually? Zhaofeng Li [talk... contribs...] 10:45, 15 January 2014 (UTC)[reply]

Notifications have not been working for weeks

What does work for me: notifications of a new message on my talk page and of "thanks". What notifications don't trigger: Everything else that is supposed to. I first noticed this on January 4 - a ping had been left for me on a talk page not my own, and it never showed up in Notifications. Here and there, I've noticed others. Another notification should have triggered for me from WP:DYK about half an hour ago - but didn't. Is this issue already known?— Maile (talk) 15:34, 15 January 2014 (UTC)[reply]

For mentions to work, you have to sign your new comment. So this will never generate a mention notification (not signed) and neither will this (not a new 'comment' block). This is because in our talk format it is difficult to distinguish editing from 'new posts'. Flow will fix that. —TheDJ (talk • contribs) 17:08, 15 January 2014 (UTC)[reply]
Also ensure that at Preferences → Notifications, you have "Mention" enabled. --Redrose64 (talk) 18:54, 15 January 2014 (UTC)[reply]
Thanks for that - my Preferences are set correctly. I get what TheDJ is saying. Where I first noticed a ping wasn't notifying me was Here, which was a new post that seems to be signed by the posting editor. — Maile (talk) 20:18, 15 January 2014 (UTC)[reply]
That particular post screwed up the template syntax, so it didn't generate a link to User:Maile66. And, of course, the fix in the next edit didn't count because it wasn't a new post with a signature. Anomie⚔ 20:43, 15 January 2014 (UTC)[reply]
Got it. So what it amounts to when the Notifications don't work is "...user error..." — Maile (talk) 20:52, 15 January 2014 (UTC)[reply]
@Maile66: not sure i'd put it the way you did, but sure, user error can cause notification to fail. genuine bugs in the software can also cause it to fail, but in this case, it was the former. check to see if you get notification for this one... peace - קיפודנחש (aka kipod) (talk) 00:06, 16 January 2014 (UTC)[reply]
I got the notification on this one. Thanks. — Maile (talk) 00:08, 16 January 2014 (UTC)[reply]

Current article link wish

I've two enhancement ideas:

  1. Expanding navbox to highlight (bold) link. Example: Jetpack (Firefox project) and its link in navbox
  2. Marking redirect link too. Example: XKeyscore and its link in navbox sidebar (Programs section)

This can be done probably with JavaScript (especially the first idea) and IMO will make navbox navigation really better.

Please comment! --Rezonansowy (talk • contribs) 15:40, 15 January 2014 (UTC)[reply]

The first should already be showing as bold by use of CSS. The second can be done by using User:Anomie/linkclassifier. For example, I see self-redirects with a green background. --  Gadget850 talk 15:49, 15 January 2014 (UTC)[reply]
In first I meant expanding navbox to show its content with bolded link. In second, I know about this gadget, but that's not only an enhancement, IMO thats a bug and should be corrected in core of MediaWiki. Please tell me if you agree. --Rezonansowy (talk • contribs) 16:12, 15 January 2014 (UTC)[reply]
You want to automatically expand a collapsed box that contains a link to the page it is transcluded on? --  Gadget850 talk 16:52, 15 January 2014 (UTC)[reply]
Yes, but only on current page where it is transcluded on, then the bolded link will be visible. --Rezonansowy (talk • contribs) 17:31, 15 January 2014 (UTC)[reply]
That practically means that every navbox would be expanded as they normally all contain a link to the current page. That goes against the current practice of automatically collapsing navboxes when there are more then two navboxes on the page. — Edokter (talk) — 17:40, 15 January 2014 (UTC)[reply]
And changing link colors to nonstandard is going to confuse readers. I enabled the linkclassifier so I understand why I get all those colors. It should never be a default. --  Gadget850 talk 22:28, 15 January 2014 (UTC)[reply]

Fixing issues with medical articles

A question I've seen a lot is "What about the people who use Wikipedia for medical advice? How do we protect them from vandals?" Well, how about a button to point out the recent changes that may not have had a chance to be reverted if they're vandalism, maybe by highlighting the edits in the past week? Ideas? Supernerd11 (talk) 22:30, 15 January 2014 (UTC)[reply]

Template:WPMED related changes was recently developed for this purpose. Maralia (talk) 22:49, 15 January 2014 (UTC)[reply]
Alright, thanks. Supernerd11 (talk) 13:20, 16 January 2014 (UTC)[reply]
enwiki has the ability to define some pages as "require review" - the whole shebang is explained in WP:RVW.
it seems that this is the right tool to solve the problem you raise, by marking all pages that readers might turn to for medical advice as "require review".
peace - קיפודנחש (aka kipod) (talk) 19:19, 16 January 2014 (UTC)[reply]

RfC: Should we support MP4 Video on Wikipedia?

The Wikimedia Foundation's multimedia team seeks community guidance on a proposal to support the MP4 video format. This digital video standard is used widely around the world to record, edit and watch videos on mobile phones, desktop computers and home video devices. It is also known as H.264/MPEG-4 or AVC.

Supporting the MP4 format would make it much easier for our users to view and contribute video on Wikipedia and Wikimedia projects -- and video files could be offered in dual formats on our sites, so we could continue to support current open formats (WebM and Ogg Theora).

However, MP4 is a patent-encumbered format, and using a proprietary format would be a departure from our current practice of only supporting open formats on our sites -- even though the licenses appear to have acceptable legal terms, with only a small fee required.

We would appreciate your guidance on whether or not to support MP4. Our Request for Comments presents views both in favor and against MP4 support, based on opinions we’ve heard in our discussions with community and team members.

Please join this RfC -- and share your advice.

All users are welcome to participate, whether you are active on Commons, Wikipedia, other Wikimedia project -- or any site that uses content from our free media repository.

You are also welcome to join tomorrow's Office hours chat on IRC, this Thursday, January 16, at 19:00 UTC, if you would like to discuss this project with our team and other community members.

We look forward to a constructive discussion with you, so we can make a more informed decision together on this important topic.

All the best, Fabrice Florin (WMF) (talk) 01:42, 16 January 2014 (UTC)[reply]

Confusing media redirection

In Category:Wikipedia soft redirects there is one file. It is called "Normalspace.gif". If you click on it, you appear on page "File:Normal space.png". The reason is commons:File:Normalspace.gif is a redirect to commons:File:Normal space.png. However we have a local page called File:Normalspace.gif. See https://en.wikipedia.org/wiki/File:Normalspace.gif?action=history It is probably easy enough to fix this case by deleting the local gif , however there is a bug somewhere in there, and many more files may be affected. John Vandenberg (chat) 02:24, 16 January 2014 (UTC)[reply]

The problem is that the file still appears to be present in the category. Even though the deleted file is no longer in the local category, it seems the system does not realize that this is the case. It might be that it just takes long to update due to the job queue, or perhaps it simply doesn't realize that the local page no longer exists. I suggest we wait a bit and see if the job queue cleans it up. If it is still there after a few days, we call in the system administrators :D —TheDJ (talk • contribs) 09:26, 16 January 2014 (UTC)[reply]
@TheDJ: the local page does exist, with a {{soft redirect}} which is doing the categorisation. You can see it here https://en.wikipedia.org/w/index.php?title=File:Normalspace.gif&action=edit John Vandenberg (chat) 13:28, 16 January 2014 (UTC)[reply]
Deleted the local file page; soft redirect was overridden by the Common hard redirect anyway. — Edokter (talk) — 13:36, 16 January 2014 (UTC)[reply]
I was leaving in undeleted so that we could identify the bug. John Vandenberg (chat) 18:28, 16 January 2014 (UTC)[reply]
I was unaware of that. Though I don't really see a bug here. Had the page contained an image, you would have landed on the local page. Otherwise, the Commons redirect takes precedence. — Edokter (talk) — 18:48, 17 January 2014 (UTC)[reply]

Does the mw:Extension:Disambiguator have a MagicWord to count the amount of the page which have the __DISAMBIG__?

I want to calculate the amount of the page which is the disambiguation page.Now I use the {{PAGESINCATEGORY:<the category's name of the disambiguation page>}} to calculate it,but I hope my formula can work in any plan beacause of the difference of the category's name in different plan.Thank you for help.--Cwek (talk) 04:00, 16 January 2014 (UTC)[reply]

No magic word, but
MariaDB [enwiki_p]> select count(*) from page_props where pp_propname="disambiguation";
+----------+
| count(*) |
+----------+
|   242120 |
+----------+
1 row in set (0.38 sec)
Legoktm (talk) 09:22, 17 January 2014 (UTC)[reply]

Message at page bottom

When on a wikibreak, I put a message at the bottom of my talk page informing visitors of the fact and asking them to write above that message and below everything else. In practice, people often add their message below my advisory notice, which therefore gets lost. Is it possible to pin my message to the bottom of my talk page so that it stays there despite other editors?

I've left it very late to post this, since I'm flying this evening, so if it can be done, please feel free to fix my talk page according. Thanks, Jimfbleak - talk to me? 07:56, 16 January 2014 (UTC)[reply]

Yeah, the add section button always puts the new section at the very end of the talk page, so oftentimes, people won't even see your notice. You might try out a WP:Editnotice as an alternative, since I don't know how to add a section that stays at the bottom. VanIsaacWS Vexcontribs 08:56, 16 January 2014 (UTC)[reply]
You might be able to concoct something with absolute positioning in CSS, a little like the "Jimbo peeking" picture, but I'd recommend against it. It would probably look annoying, and there are some tools (like popups) that allow you to go straight to adding a new section, so people might not even see it then. I'd go for an edit notice plus a notice at the top of the page if you want maximum visibility. — Mr. Stradivarius ♪ talk ♪ 10:55, 16 January 2014 (UTC)[reply]
Thanks, I've added an edit notice, and put the message at top and bottom of talk page, so we will just have to see if it works! Jimfbleak - talk to me? 12:05, 16 January 2014 (UTC)[reply]
  • MediaWiki software should have page-footer notices: This issue is one of the quite important features to have, which should have been added years ago, as another example of a typesetting environment without typesetting capabilities, because footers have been provided in computerized typesetting for over 40 years. Perhaps enough people can keep reminding the developers to implement page-header and page-footer directives always positioned to the top/bottom of a page, especially as instructional messages without editing a page. Perhaps there is already a wp:MediaWiki extension which provides headers/footers, as with the extension to store data-settings between templates (which could make some markup-based templates run 10x faster). -Wikid77 12:52, 18 January 2014 (UTC)[reply]
    There are multiple extensions providing page footers: Extension:PageNotice, Extension:Header Footer and Extension:HeadersFooters are some that I know. I don't think any are up to the code quality required for deploying on Wikimedia, but I don't think it would take much work to bring one up to scratch. I agree that such a feature would be useful.
    The other extension you mention (I guess you mean Extension:Variables) isn't relevant here, but is unlikely to be deployed. Templates are not intended as a fully-featured programming language, and the developers won't support attempts to turn them into such, especially when we already have Lua. – PartTimeGnome (talk | contribs) 20:59, 18 January 2014 (UTC)[reply]
Tracked in Phabricator
Task T60157

Does anyone else find that, when trying to perform a namespace-specific search in new users' contributions, they receive the following error message? 

A database query error has occurred. This may indicate a bug in the software.
   Function: IndexPager::buildQueryInfo (contributions page filtered for namespace or RevisionDeleted edits)
   Error: 0

I periodically run through and check new user uploads in the file namespace and have been experiencing this problem for the last three or four weeks. Sometimes, after much loading, I am able to view the most recent changes up to the end of the first results page; attempts to view changes older than the top 100 or 200, however, produce the database error. As a consequence, the oldest recent changes in the namespace (dating back a month) become inaccessible. SuperMarioMan 04:03, 17 January 2014 (UTC)[reply]

Confirming that something similar happened to me too when I tried it, via this link. I didn't get the database error you mentioned though, but a "data not received" error from Chrome. (The actual error message may be different, as I translated it from Japanese.) I remember something similar was also reported for user log pages recently - I'll see if I can find the archive link. — Mr. Stradivarius ♪ talk ♪ 04:21, 17 January 2014 (UTC)[reply]
Here it is: Wikipedia:Village pump (technical)/Archive 118#timeouts. Also see bugzilla:54876. That bug report was resolved as fixed, so this may be a separate issue. — Mr. Stradivarius ♪ talk ♪ 04:43, 17 January 2014 (UTC)[reply]
bugzilla:58157 is still open though. --Redrose64 (talk) 10:39, 17 January 2014 (UTC)[reply]
Yes, the error is pretty much exactly as described in the second Bugzilla report. I didn't know that named user contributions lists were affected as well – yet, true enough, when I try the links provided in the first two posts there, the page is just as slow to load, and the eventual result is the same message as before. Curiously, if I remove the "&namespace=X" suffix, load the full contributions list, and then click back to the previous page, the namespace-specific list displays as normal.

For reference, this is the bookmarked URL that I normally use: http://en.wikipedia.org/w/index.php?limit=150&tagfilter=&title=Special%3AContributions&contribs=newbie&target=&namespace=6&tagfilter=&year=&month=-1. Until a few weeks ago, the link functioned perfectly, and I was able to cycle back through past edits in batches of 150 up to the cut-off point (30 days?); now, it works only if lower limits of 20 or 30 are applied, and batches no longer show past the 100 or 200 mark – in upload terms, no further back than the last few days. For what it's worth, I'm using Firefox and Internet Explorer, although this is clearly not a browser issue. SuperMarioMan 14:42, 17 January 2014 (UTC)[reply]

Can we please get rid of those shouty comments in template documentation?

You know the ones I mean... "PLEASE ADD CATEGORIES AND INTERWIKIS AT THE BOTTOM OF THIS PAGE" and "CATEGORIES AND INTERWIKIS HERE, THANKS". I don't know where or when they originated, presumably in the first ever template documentation template. But we've now been successfully using the system for years, and everybody knows how it works. For the times that someone doesn't, another person will fix the transclusion of a category momentarily; and it causes no actual harm until they do. Perpetuating this copy-and-paste mess also creates its own maintenance overhead, as I've now seen someone who's decided that they need to grind through them adding a mention of Wikidata. That's a colossal waste of time.

So can we please, please agree that it's time to get rid of these patronizing and shouty comments? And when we have, get a bot to remove them? I, for one, am sick to death of seeing them, and will continue my practice of nuking them on sight if they occur in a documentation template that I'm working on. — Scott • talk 12:26, 17 January 2014 (UTC)[reply]

Technical: The comments are added by Template:Documentation/preload. --  Gadget850 talk 14:37, 17 January 2014 (UTC)[reply]
Thank you. I was almost right, then; they originated in the first version of Wikipedia:Template documentation in 2006. See also my reply below. — Scott • talk 16:02, 17 January 2014 (UTC)[reply]
  • I'm assuming they are still there for all of the editors that are new to templates and documentation that might not know. The reason for them to be all caps like that is that they are HTML comments, and as such, need to stand out to be noticed in a seas of text or walls of code. I suppose there could be a note added to the editnotice for all template pages, but that might be more work than it is worth and easier to just have the SHOUTY comments in the source (where they are more likely to be seen than editnotices anyways). Technical 13 (talk) 14:55, 17 January 2014 (UTC)[reply]
Yes. Later on, the interwiki link message has changed too, for wikidata. Maybe a botter would like to clean these. -DePiep (talk) 17:14, 17 January 2014 (UTC)[reply]
Removing the comments would have the disadvantage that all of the templates' transclusions would have to be updated. If it's done by bot, then that would become a very large number of pages, probably in the millions. — Mr. Stradivarius ♪ talk ♪ 04:44, 18 January 2014 (UTC)[reply]
Most of them are /doc subtemplates, with few transclusions each (not millions). -Wikid77 00:36, 19 January 2014 (UTC)[reply]

everybody knows how it works ...except for the hundred-thousand-plus editors who are active now but have never touched a template, and the tens of thousands who have occasionally edited templates, but not often enough to remember how it works. The "everybody" who already knows how this works is actually a quite small percentage of users. WhatamIdoing (talk) 00:16, 18 January 2014 (UTC)[reply]

Yes, and they're the ones who'll fix it when the inexperienced ones get it wrong. Them, or bots. We have innumerable bots crawling around the site making similar grades of fix on a vastly larger scale; this should be one of the things that they look out for. — Scott • talk 21:57, 18 January 2014 (UTC)[reply]
Why waste the time of more experienced editors? Why make it easier to make mistakes? The comments do no harm. They help inexperienced editors learn what to do, and hopefully reduce the time the rest of us spend fixing mistakes. – PartTimeGnome (talk | contribs) 22:04, 18 January 2014 (UTC)[reply]
  • Update SHOUTy text with new /preload text: The new format should be copied to replace any old, ALL-CAPS comments in /doc pages, as from the current Template:Documentation/preload, especially to control /sandbox use:
<includeonly>{{#ifeq:{{SUBPAGENAME}}|sandbox||
<!-- Categories go here, and interwikis go in Wikidata -->

}}</includeonly>

It's not just HTML cmts but also the #ifeq for sandbox use. The plan is for any new /sandbox to omit the category links of the doc subpage. -Wikid77 00:36, 19 January 2014 (UTC)[reply]

IRC feeds down?

I'm not sure the logistics behind how recent changes work... but Huggle says it's connected to the IRC feed but nothing is showing up. Likely related, ClueBot NG has made no reverts since 12:15 EST. Anyone know what's going on? Thanks! — MusikAnimal talk 18:04, 17 January 2014 (UTC)[reply]

There is a network failure at the moment (apparently the fiber feeds into one of our datacenters have no less than three breaks) that reduces or prevents some services from running properly. Impact on Labs is variable, depending on the exact tool, but no access to the database replicas will work until the network has been repaired (outside our control, atm). — MPelletier (WMF) (talk) 18:22, 17 January 2014 (UTC)[reply]
Gotcha, thanks for the update. For anyone else reading this that uses Huggle, change your options to force the software to use the API queries rather than the IRC feed. System > Options > uncheck "Use IRC feed for recent changes if possible". Cheers! — MusikAnimal talk 18:38, 17 January 2014 (UTC)[reply]
The RC-IRC feed is back up since about a minute. --Sitic (talk) 19:29, 17 January 2014 (UTC)[reply]
Seems like it came back up, but isn't really stable and is having intermittent issues. Just need to be patient with it until the fibers are patched... Technical 13 (talk) 19:47, 17 January 2014 (UTC)[reply]
Hm, so that's why I couldn't access the IRC feeds when I opened up Huggle during my lunch (Yes, I do that a lot). I thought it was my Internet, but apparently not. MusikAnimal left me a note on my talk page saying that he/she couldn't access IRC either. It might also explain why ClueBot NG isn't working, though most RC patrolling bots, such as SineBot, are still okay as they use the API queries. I think that might be an idea - in case IRC goes down again, ClueBot NG should automatically switch to API, like Huggle does. It's slower, but it's better if vandalism was reverted one hour after it was made than never being reverted at all. K6ka (talk | contrib) 20:37, 17 January 2014 (UTC)[reply]
Or... not. While Huggle can access the IRC feeds just fine, ClueBot NG is still down. It may be an issue on ClueNet's end again. K6ka (talk | contrib) 21:46, 17 January 2014 (UTC)[reply]

Capitalization problem

I added a hatnote to Large-screen television technology because I didn't capitalize a T and TV technology sent me there. But there was no such redirect and my hatnote got changed because of a flag that the redirect didn't exist. Obviously, it does now, because I fixed it, but the redirect was from Tv technology.

This has surely been discussed but I have lots to do and will have to come back tomorrow.— Vchimpanzee · talk · contributions · 22:38, 17 January 2014 (UTC)[reply]

I'm not sure what your complaint is. You added the hatnote {{redirect|TV technology|the trade journal|TV Technology}} at a time where there was no redirect at TV technology, so {{redirect}} correctly added the article to Category:Missing redirects. User:Wbm1058 saw that and removed your hatnote. Maybe Wbm1058 should have changed the hatnote or created the redirect instead, but that isn't a technical issue. Are you saying that your hatnote should have automatically detected there existed a redirect at another capitalization Tv technology? I don't think that is possible without testing each potential capitalization one at a time, and that would be too expensive. Maybe Category:Missing redirects should include suggestions to check incoming redirects by clicking "What links here" and "Hide links". PrimeHunter (talk) 00:10, 18 January 2014 (UTC)[reply]
Just to be clear I did not completely remove the {{redirect}}, I changed it to a {{for}} (diff). If the editor truly believes that readers searching for "TV technology" will find themselves surprised to land on an article about television technology, then fine, I won't further contest a decision to explain it to the confused readers with a {{redirect}} hatnote. Wbm1058 (talk) 00:33, 18 January 2014 (UTC)[reply]
Per PrimeHunter's "testing each potential capitalization"; we do this over at Wikiproject Red Link Recovery and fix cases like this one as part of our normal process. We also catch missing diacritic marks, confusions of n and m dashes and many other cases where red links are very-nearly-but-not-precisely-like the title of an article, template or redirect. - TB (talk) 10:41, 18 January 2014 (UTC)[reply]
If you enter a title in the search box then you automatically find a redirect with any other capitalization. An editor going through Category:Missing redirects can certainly do that but since this was posted to the tech pump, the question may be whether a template like {{redirect}} can do it and produce different output depending on the result. mw:Help:Extension:ParserFunctions#.23ifexist only works for one capitalization. I don't know whether there is a way to do it in Lua. PrimeHunter (talk) 14:37, 18 January 2014 (UTC)[reply]
When I first ran across Category:Missing redirects it was a crowded and neglected maintenance category begging for attention. I enhanced several templates in the {{redirect}} family to populate the category, as it was only being populated by a minority of these templates. As far as I know, I am the only one who actively patrols this category, and as a result I create redirects all the time. You would be surprised at how many editors put {{redirect}} on top of an article, mistakenly thinking that is the way to actually create a #REDIRECT. So I create the xyzzy redirect and remove the template, as disambiguation to xyzzy (disambiguation) is unnecessary. So, please forgive me for simply simplifying the hatnote, and prioritizing my time by not bothering to create that particular redirect. And thank you, Vchimpanzee, for taking the time to create the redirect. I think the template functions fine as-is and shouldn't be modified to "work around" red links. Redirects are cheap, and fixing content forks is expensive. – Wbm1058 (talk) 15:10, 18 January 2014 (UTC)[reply]
  • I'm not entirely sure why Vchimpanzee posted this here either, I would have thought the Help Desk, the talk page of TV technology, or the talk page for the wikiprojects involving that would have been more appropriate. If there was some kind of template that could determine all of the existing capitalization possibilities as discussed here, what exactly would it be expected to do with that knowledge? Add the page to a category, perhaps? Place a hat note on the page, perhaps? Not sure this would be appropriate in most cases, and may cause confusion... Lua can't really do any more than a standard template in this case, and the big issue with using either one of them will be the fact that Template:(pf)ifexist: has a limit of 500 call before it quits working and both Templates and Lua run into this issue. Now, I suppose, what would be great here is if there was a bot... @Anomie, Hasteur, Legoktm, Theopolisme, and GorillaWarfare: or any other "bot guy/gal" that might be interested, can one of you volunteer to help write a bot for this task of creating redirects to likely redirects for various characters or casing, assuming such a bot doesn't already exist... Technical 13 (talk) 17:45, 18 January 2014 (UTC)[reply]
I'm not sure what result I was expecting. I didn't realize I had caused a problem until later, and of course I was confused when I landed on this article that at the time looked completely different. I think my problem is that in some cases it has appeared the redirect existed when it didn't because I didn't capitalize something, but then later I discovered a red link or something. Or I might never have discovered the red link and it would have been a problem for someone else.— Vchimpanzee · talk · contributions · 18:23, 18 January 2014 (UTC)[reply]
Wait, I know. The only reasonable expectation is that because TV is sort of an acronym, the fact that I didn't capitalize the V should have somehow led to a solution. The other letters in "technology" besides the T wouldn't have been a problem.— Vchimpanzee · talk · contributions · 18:26, 18 January 2014 (UTC)[reply]
Looking at what has been said above, maybe the problem has been dealt with sufficiently.— Vchimpanzee · talk · contributions · 18:34, 18 January 2014 (UTC)[reply]

Incorrect notice following pagemove

Even when redirect creation is successfully suppressed during a page move, the special page confirming the move displays a notice at the bottom stating "A redirect has been created." This is a minor issue, but it is an unnecessary source of confusion. Is this an issue that can be fixed on-wiki or does it need to be reported at Bugzilla? Thank you, -- Black Falcon (talk) 06:52, 18 January 2014 (UTC)[reply]

bugzilla:45348: moving a page with suppressredirect produces misleading message "A redirect has been created". PrimeHunter (talk) 08:33, 18 January 2014 (UTC)[reply]

Site-wide template auto-collapse issue

File:RehmanTestUpload.jpg
Does anyone know what's going on? --Rehman 13:01, 18 January 2014 (UTC)[reply]

As seen in the image, does anyone know what's going on? Templates on Firefox 26 is acting funny, while IE10 (which I never use), displays fine... Rehman 13:01, 18 January 2014 (UTC)[reply]

I see no issues here, using Firefox 26. Try purging the template. — Edokter (talk) — 13:11, 18 January 2014 (UTC)[reply]
It's on all templates, and on all pages using templates. On all 3 W7/FF PCs I use. Rehman
I seem to remember a beta feature (Near here) could be responsible for this. — Edokter (talk) — 13:13, 18 January 2014 (UTC)[reply]
You're right! The "Near this page" beta feature is what's responsible for this! Thanks. Rehman 00:52, 19 January 2014 (UTC)[reply]
I can confirm this for the latest version of Chrome for Windows (32.0.1700.76 m). — Scott • talk 22:00, 18 January 2014 (UTC)[reply]

FlaggedRevs

Hi. Please help me to make a patch. Sincerely -- Дагиров Умар (talk) 13:51, 18 January 2014 (UTC)[reply]

Opt-in for pending changes

Is it technically possible to make it so an editor can opt-in to pending changes for a specific edit?

For example, if I am making a relatively small edit on an article where I have a COI. There is no need to discuss it on Talk, but because I have a COI, I think it would be polite and proper to have another editor approve it sort of speak. CorporateM (Talk) 14:53, 18 January 2014 (UTC)[reply]

If it's on a pending-changes article, you can make the edit and then unaccept it, since you're a reviewer. For people who aren't reviewers, or for non-pending-changes articles, it's not currently possible. The best we have is {{request edit}}. Jackmcbarn (talk) 17:57, 18 January 2014 (UTC)[reply]
Yah, I use Request Edit a lot, but I don't think anyone would be a happy camper with me submitting 20 Request Edits for various copyedits as part of a GA review or anything like that. OTOH, a quick click on the "approve" button as a formality to comply with WP:COI and Bright Line. It might also be great for new editors uncertain about their edit.
Do you think it's something I could reasonably beg and plead a technical person to make possible or would it be a huge thing? CorporateM (Talk) 19:00, 18 January 2014 (UTC)[reply]
Flagging one edit as "please review this" is an interesting idea. However, what would happen to subsequent revisions by non-reviewers before the edit is reviewed? Such revisions would incorporate the edit flagged for review, but I'm not sure we'd want further edits to be subject to review as well. The alternatives – auto-accepting, auto-rejecting or forcing the next editor to make a choice – don't seem great either.
Regardless of how that is answered, I imagine some effort would be involved in implementing this. – PartTimeGnome (talk | contribs) 20:19, 18 January 2014 (UTC)[reply]

Streamlining page moves over redirects?

Moving a page over a redirect is becoming less likely to succeed because so many minor adjustments are being made to redirect pages. Many of us are allowed to move over a redirect if it has just one line in its edit history, but have to request a page move in other cases. Would it be difficult to relax these restrictions so that multiple edits of rather minor sorts would not hold up a page move? A case where Avicbot had fixed a double redirect is discussed at Talk:Gomphocarpus fruticosus, and there is some more discussion on my talk page. Some of these edits are manual, and some made by bots. Category additions are one type, and template additions such as the "redirect to …" and the "R from …" templates. Sminthopsis84 (talk) 19:57, 18 January 2014 (UTC)[reply]

Nothing we can do at this end; it would need a amendment to the MediaWiki software. Please file a feature request at bugzilla. --Redrose64 (talk) 20:17, 18 January 2014 (UTC)[reply]
Before you do, please define "of minor sorts" in a manner that can be determined quickly and unambiguously by a computer program. Anomie⚔ 22:02, 18 January 2014 (UTC)[reply]
Thank you both, this is clearly beyond my knowledge realm, so I'll drop the matter. Sminthopsis84 (talk) 22:04, 18 January 2014 (UTC)[reply]
Here's one way to define it: allow a redirect to be overwritten if all of its revisions are redirects to the page being moved over it, and the redirect does not have any form of protection. So that MediaWiki doesn't have to look over potentially hundreds of revisions, also include a restriction that there must be fewer than 20 revisions. Any change to a redirect that does not change its target or turn it into an article is minor enough to allow it to be overwritten, to my mind. Under this system, should there be a special case that must not be overwritten, an admin could semi-protect it. – PartTimeGnome (talk | contribs) 22:14, 18 January 2014 (UTC)[reply]
That won't handle the relatively common case of double redirect fixes though, because they will have pointed to a different target at some point. Anomie⚔ 23:07, 18 January 2014 (UTC)[reply]
@Anomie: What if, as long as the page has never been anything but a redirect, regardless of target, allow moving over it? If that would lend itself to abuse, then require that the initial revision must have pointed to the page being moved over it. Jackmcbarn (talk) 23:13, 18 January 2014 (UTC)[reply]

File usage bug

OK who is ready for a brain bender? I was cleaning up WP:NFCC#9 issues and came across File:Corvus.jpg which Mediawiki lists as being used on 4 pages. So no big deal right? I went to remove the file and cant find it in the wikitext or any template being used. Odd, might be a cache issue, so I purged the pages where the file is used .... No go, still showing up. At this point Im scratching my head, as I cannot figure out why the file is being listed on a page where the file isnt displayed. I had one other thought perhaps it was a [[Media: link causing the false hit, After digging around, no luck. I finally decide to look at the HTML source of the article, and I discover that File:Corvus-illustration.jpg is the source. The file is on commons and is a file redirect to their version of commons:File:Corvus.jpg. Can someone please dig me out of this rabbit hole? Werieth (talk) 20:57, 18 January 2014 (UTC)[reply]

Wikipedia handles Commons redirects in a strange way. User:Haus clearly wants to use the Commons file in his userspace and this situation is very confusing, so I have moved away our local file. --Stefan2 (talk) 21:06, 18 January 2014 (UTC)[reply]
No Commons redirect, simple name clash. Local page deleted. — Edokter (talk) — 23:50, 18 January 2014 (UTC)[reply]

Search results number

There used to be a setting in preferences to say how many results would be shown on each screen as the result of a search. I think the default was 20; I had mine set at 500, but now it is showing 100. Has something changed or am I missing something? SchreiberBike talk 00:35, 19 January 2014 (UTC)[reply]

Maybe it got removed on en? The preferences help at en does not mention that, but [4] does. RudolfRed (talk) 00:44, 19 January 2014 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=591349166"