Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 24.61.9.111 (talk) at 06:02, 24 December 2012 (Different backround color). 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 
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (How to report a bug). Bugs with security implications should be reported to security@wikimedia.org.

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.

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

No purging on newer version of images

NOTE: Parallel discussion in progress at Commons:Village Pump#Problem with new version of image.

I uploaded newer version of the Introspective cover art. While the image page is already updated, the article shows the prior version of the cover art. How long can I wait? --George Ho (talk) 03:06, 11 December 2012 (UTC)[reply]

Have you tried clearing your page cache? It could well be golding the 'old' version of the page. NtheP (talk) 15:42, 11 December 2012 (UTC)[reply]
I did delete "Temporary Internet Files" on Internet Explorer 9; old versions of images still appear. ...Well, I'm now seeing newer version of Showdown (Cheers)'s infobox image. However, Baby, Come to Me (Patti Austin and James Ingram song) should have the Japan single; I'm now seeing a French single. --George Ho (talk) 16:12, 11 December 2012 (UTC)[reply]
It appears the old thumbnail caching bug from mid-2011 has reappeared. I remember first seeing it around 23 May 2011 and the problem persisted to a greater or lesser degree through the summer of 2011. Around that time many users also reported very slow Wikipedia performance, even those on high-speed connections. I haven't seen much in the way of Wikipedia slowness (yet), but an image that I was trying to update yesterday failed to update the thumbnail cache, even after clearing my browser cache and purging the pages at Wikimedia Commons and on the English Wikipedia where the image is used. I tried a test edit by changing the thumbnail size by just one pixel, and the revised image appeared as it should have, but not if the image continues to use the same old thumbnail size. In 2011 the thumbnails would eventually get updated, but it could take 24-72 hours. I seem to recall this was assigned a bug tracking number, but after searching the Village Pump archives here and at Wikimedia Commons, I haven't been able to find the thread where that was mentioned. It's possible that the root cause was never properly identified and corrected, or someone may have re-introduced the bug with a software change that picked up a chunk of old source code from around mid-May 2011 or thereabouts. — QuicksilverT @ 05:46, 12 December 2012 (UTC)[reply]
Even just changing the filename seems to fix the image; look at File:KDEN-TV Logo.png, which I changed from File:Logo-denver.png, while the unchanged File:KFWD T52.png is still waiting to get my change in. Nate (chatter) 06:09, 12 December 2012 (UTC)[reply]
Template:Bug, I think. --Maggie Dennis (WMF) (talk) 19:41, 12 December 2012 (UTC)[reply]
That's it! Thanks for digging up the reference. — QuicksilverT @ 03:44, 14 December 2012 (UTC)[reply]

On File:Obama and Duke Duchess of Cambridge.jpg I get the following message on the 800px thumbnail no matter how much things are purged or refreshed, but can get other non-800px sizes: Error generating thumbnail
Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?
-- AnonMoos (talk) 13:45, 14 December 2012 (UTC)[reply]

Right now, the files are not loading properly (or is loading slowly). Are tech guys debugging the problem? --George Ho (talk) 23:13, 17 December 2012 (UTC)[reply]
Or maybe it's short-term loading problem. Now I'm confused. --George Ho (talk) 23:15, 17 December 2012 (UTC)[reply]
Loading issues resolved? I see that loading is all right. Now then, anything uploaded this week has no issues. Look at "Smokin' in the Boys' Room"; loading is stable. --George Ho (talk) 04:38, 18 December 2012 (UTC)[reply]
...Actually, any latest versions of non-free files are all right. Probably mostly Commons ones need some fixing? --George Ho (talk) 21:25, 19 December 2012 (UTC)[reply]

Having the same problem myself; Telemundo has undergone a major brand imagining and many of their affiliates unveiled new logos in the last few days. I have been trying to update the local logos as I can, but have not been able to purge out the old revisions at all in articles. Tried in Opera, Chrome, IE10 both in regular and IE8 compatibility mode, and Firefox. Nate (chatter) 03:16, 12 December 2012 (UTC)[reply]

Probably also related is this: Having problems with a corrupted image discussion at Commons, which is still unresolved. Begoontalk 00:11, 18 December 2012 (UTC)[reply]

Alpha version of the VisualEditor now available here

TL;DR: Today we are launching an alpha, opt-in version of the VisualEditor to the English Wikipedia. This will let editors create and modify real articles visually, using a new system where the articles they edit will look the same as when you read them, and their changes show up as they type enter them — like writing a document in a word processor. Please let us know what you think.

Why launch now?

We want our community of existing editors to get an idea of what the VisualEditor will look like in the “real world” and start to give us feedback about how well it integrates with how they edit right now, and their thoughts on what aspects are the priorities in the coming months.

The editor is at an early stage and is still missing significant functions, which we will address in the coming months. Because of this, we are mostly looking for feedback from experienced editors at this point, because the editor is insufficient to really give them a proper experience of editing. We don’t want to promise an easier editing experience to new editors before it is ready.

As we develop improvements, they will be pushed every fortnight to the wikis, allowing you to give us feedback as we go and tell us what next you want us to work on.

How can I try it out?

The VisualEditor is now available to all logged-in accounts on the English Wikipedia as a new preference, switched off by default. If you go to your “Preferences” screen and click into the “Editing” section, it will have as an option labelled “Enable VisualEditor”.

Once enabled, for each article you can edit, you will get a second editor tab labelled “VisualEditor” next to the “Edit” tab. If you click this, after a little pause you will enter the VisualEditor. From here, you can play around, edit and save real articles and get an idea of what it will be like when complete.

At this early stage in our development, we recommend that after saving any edits, you check whether they broke anything. All edits made with the VisualEditor will show up in articles’ history tabs with a “VisualEditor” tag next to them, so you can track what is happening.

Things to note
  • Slow to load - It will take some time for long complex pages to load into the VisualEditor, and particularly-big ones may timeout after 60 seconds. This is because pages have to be loaded through Parsoid which is also in its early stages, and is not yet optimised for deployment and is currently uncached. In the future (a) Parsoid itself will be much faster, (b) Parsoid will not depend on as many slow API calls, and (c) it will be cached.
  • Odd-looking - we currently struggle with making the HTML we produce look like you are used to seeing, so styling and so on may look a little (or even very) odd. This hasn't been our priority to date, as our focus has been on making sure we don't disrupt articles with the VisualEditor by altering the wikitext (correct "round-tripping").
  • No editing references or templates - Blocks of content that we cannot yet handle are uneditable; this is mostly references and templates like infoboxes. Instead, when you mouse over them, they will be hatched out and a tooltip will inform you that they have to be edited via wikitext for now. You can select these items and delete them entirely, however there is not yet a way to add ones in or edit them currently (this will be a core piece of work post-December).
  • Incomplete editing - Some elements of "complex" formatting will display and let you edit their contents, but not let users edit their structure or add new entries - such as tables or definition lists. This area of work will also be one of our priorities post-December.
  • No categories - Articles' "meta" items will not appear at all - categories, langlinks, magic words etc.; these are preserved (so editing won't disrupt them), but they not yet editable. Another area for work post-December - our current plan is that they will be edited through a "metadata flyout", with auto-suggestions and so on.
  • Poor browser support - Right now, we have only got VisualEditor to work in the most modern versions of Firefox, Chrome and Safari. We will find a way to support (at least) Internet Explorer post-December, but it's going to be a significant piece of work and we have failed to get it ready for now.
  • Articles and User pages only - The VisualEditor will only be enabled for the article and user namespaces (so you can make changes in a personal sandbox), and will not work with talk pages, templates, categories, etc.. In time, we will build out the kinds of specialised editing tools needed for non-articles, but our focus has been on articles.
Final point

This is not the final form of the VisualEditor in lots of different ways. We know of a number of bugs, and we expect you to find more. We do not recommend people trying to use the VisualEditor for their regular editing yet. We would love your feedback on what we have done so far – whether it’s a problem you discovered, an aspect that you find confusing, what area you think we should work on next, or anything else, please do let us know.

Jdforrester (WMF) (talk) 03:26, 12 December 2012 (UTC)[reply]

How will the WMF track the VisualEditor's quality impact on the encyclopedia? What metrics will be used? What parameter space in those metrics will determine success or failure of the tool? Jason Quinn (talk) 05:35, 12 December 2012 (UTC)[reply]
At the moment I imagine the quality tracking is "not at all", since it's only available to a small number of users - a large chunk of whom are going to be power users. Tracking quality wouldn't necessarily be useful. I'm actually working on a review of the VE's impact on full deployment now. Okeyes (WMF) (talk) 19:47, 12 December 2012 (UTC)[reply]
Oliver is correct; we don't currently plan to collect quantitative data whilst the VisualEditor is only in an opt-in state for a handful of users. Later, when it will be deployed to a much larger number of accounts, is the time for that. Jdforrester (WMF) (talk) 19:59, 12 December 2012 (UTC)[reply]
I was asking about post large-scale deployment. I was wondering if quality impact studies were going to occur at all. Your relies seem to imply that there will be some which partly alleviates my concern. I imagine modeling "quality impact" to be complex and subtle so I was curious about details such as the variables that will be tracked. The model ought to be made fully public and transparent so it can be reviewed and critiqued. It would be easy to misinterpret data in such a study. As the VisualEditor will affect a dramatic change to editing habits, a lot of thought needs to be put into such studies to make sure the editor is actually helping rather than harming the project. Jason Quinn (talk) 04:14, 13 December 2012 (UTC)[reply]
I agree. In my mind, post-deployment tracking has to be twofold. The first is quality, sure, but the second is sociological impact. Even if 90 percent of the edits from newcomers are perfect, if edit volume has increased tenfold there's still going to be a dramatic uptake in junk, and while I think we'd all agree that the good outweighs the bad, there, we have to be very careful that the uptake in junk doesn't burn out the users who deal with it. If it does, there's a knock-on effect on everyone else. We need to be measuring burnout as well as good/bad ratios.
Out of interest, how would you measure quality? Are we simply talking a very basic comparison between quality of pre-VE and post-VE edits using hand coding, or...? Okeyes (WMF) (talk) 21:41, 13 December 2012 (UTC)[reply]
To approach your question in a very literal sense, I would take this problem by starting with a very simple foundation and modifying that step-by-step to make it more useful. This could lead to several models, which is fine. The question of quality impact of the VisualEditor seems very specialized and the solution is not likely going to fit easily into some textbook solution. It also doesn't make sense to try to develop some grand analytical solution: too many subjective aspects to be perfectly quantifiable in a way that means something. Some model that "does well enough" is probably the best to be hoped for. Let's first just mention some of the variables likely worth tracking:
  • absolute number and percentage of reverts within X (24?) hours of an edit (in general and by IP/account editors)
  • number and percentage of blocks within X (24?) hours of an edit (in general and by IP/account editors)
The key is to focus on discontinuities in the graphs and a change in these variables that persist long-term. I say "long term" because I advise not to pay too much attention to any initial "jumps". People will edit abnormally for a while upon the introduction of new features because they are curious about them and test them out (er, play with them). After a few weeks or a month, things will become "old hat" and settle down. Any changes in the variables between this point and the point prior to the introduction probably have some significant meaning.
Your argument about burnout is a good one but I would frame it differently. Instead of thinking of it as a sociological effect (which is complicated and messy to handle), I would turn it into an analytical question: is the encyclopedia accumulating more undetected/reverted vandalism because of the VisualEditor? It would take a bit of thought to figure out how to estimate the rate of "undetected/reverted vandalism". I'm not sure off the top of my head how to do it but I've seen studies that graph the expected lifetime of vandalism, and perhaps that could be combined with the above data to estimate a reasonable yes or no.
Once tracking variables have been settled upon, I would pick some sensible values by which they are allowed to change due to the introduction of the VisualEditor. If they change by more than that, they should trigger (at the minimum) a second-guessing to the value of the Editor and prompt more study of the VisualEditor's impact. Regardless, a large amount of unbiased, common sense will be required to interpret any results. I would not have the same people who developed the editor helping to judge its success or failure. Jason Quinn (talk) 17:35, 17 December 2012 (UTC)[reply]
You may also wish to look at some quick thoughts I had on useful metrics for VE once we get closer to full deployment (linked to from the agenda of the latest monthly Metrics and activities meeting). Jdforrester (WMF) (talk) 16:05, 18 December 2012 (UTC)[reply]

Replacing a file

I uploaded a new version of this file at 00:22 on 22 December 2012. It's used in one article. I've edited and reloaded the article, but I still see the old version there. Why? What can I do about it? Michael Hardy (talk) 00:31, 14 December 2012 (UTC)[reply]

Hard refresh, for a first try. If you've viewed that image on that page previously, your browser cache will still show you the old version. Steven Walling (WMF) • talk 00:41, 14 December 2012 (UTC)[reply]
Most likely this is the same problem as described at #No purging on newer version of images above. --Redrose64 (talk) 09:24, 14 December 2012 (UTC)[reply]

Nothing's working. I've purged the server cache, and emptied the cache on my machine from "the beginning of time", and the old image still appears in the article. But on this present page, I see the new one. Does anyone else see the new version in tangent half-angle formula? Michael Hardy (talk) 01:40, 15 December 2012 (UTC)[reply]

I see the old image on the article. When I remove the manually specified width limit (400px), the thumbnail shows the new version (given that my default thumbnail width is 220px). The 400px version of the image isn't updating for some reason. But yes, please read #No purging on newer version of images yellowtailshark (talk) 13:39, 15 December 2012 (UTC)[reply]
I don't think anybody said that the problem was limited to Commons images. This thread, also #No purging on newer version of images earlier, began by describing problems with images uploaded to English Wikipedia. The earlier thread does have a link to Commons:Village Pump#Problem with new version of image and some of the images mentioned later on are on Commons (e.g. File:Obama and Duke Duchess of Cambridge.jpg) but neither of these were part of the original post (see here).
Whether an image is uploaded to English Wikipedia or to Commons, the actual image files are held on http:/upwiki/ - for example, the English Wikipedia image File:Tan.half.svg is stored as http:/upwiki/wikipedia/en/d/d3/Tan.half.svg fullsize (http:/upwiki/wikipedia/en/thumb/d/d3/Tan.half.svg/220px-Tan.half.svg.png for the 220px thumbnail) and the Commons image File:Obama and Duke Duchess of Cambridge.jpg is stored as http:/upwiki/wikipedia/commons/c/c4/Obama_and_Duke_Duchess_of_Cambridge.jpg fullsize. Since the domains are exactly the same, I would expect the caching problems to be similar. --Redrose64 (talk) 08:21, 20 December 2012 (UTC)[reply]
For reference bugzilla:41130 (in particular the later comments). Bawolff (talk) 00:27, 22 December 2012 (UTC)[reply]

strange edit after page move

this looks weird. The middle edit is '-1' but nothing changes. John Vandenberg (chat) 02:36, 15 December 2012 (UTC)[reply]

There are three '-1' edits so I'm unsure which edit you refer to. Is it [1] where a space was removed after "residence they shared"? PrimeHunter (talk) 02:48, 15 December 2012 (UTC)[reply]
Sorry, I was referring to the, now deleted, edit by SilverFox183 (talk · contribs). There were only three edits: 1) the page move to include '2012' prefix, SilverFox183's edit, followed by a bot and I didnt inspect that edit. It's probably hard to debug now that the page has been moved back over the redirect, but the 'diff' omitted the diff section, similar to how it appears for moves and protection actions. John Vandenberg (chat) 04:38, 15 December 2012 (UTC)[reply]
If I compare [2] and [3] (admin only links) then the second apparently removed an extra newline at the end. That explains '-1' but raises another question: How could the first have en extra newline at the end? I thought it would be stripped on saving. I can no longer see a diff but maybe the diff ignored the extra newline or whatever it was. PrimeHunter (talk) 05:20, 15 December 2012 (UTC)[reply]
This was a case of bugzilla:42616: "Post-page move redirects contain two newlines below redirect code". The bug should be fixed but the fix had not been deployed. PrimeHunter (talk) 20:10, 19 December 2012 (UTC)[reply]

Job queue

The job queue for enwiki has been over 1,000,000 for most of the past week, having risen rapidly around 3 weeks ago:

Until November, typical values (allowing for brief spikes) were usually well under 100,000. Unfortunately, the more useful measure of job queue durations does not seem to be recorded (Bugzilla:9518).

This was recently discussed under Bugzilla:42614 in relation to recent code changes, but that bug has since been marked resolved.

Does Wikipedia:Don't worry about performance mean that this should not concern us, or does something need fixing?

Richardguk (talk) 12:07, 16 December 2012 (UTC)[reply]

This edit and two days later this one didn't exactly do wonders for the job queue. We know that it's still being processed because Category:Pages with malformed coordinate tags is still being populated. --Redrose64 (talk) 16:33, 16 December 2012 (UTC)[reply]
The queue seems to have risen further over the past 10 hours, to a recent peak of around 1,200,000. — Richardguk (talk) 17:42, 16 December 2012 (UTC)[reply]

Something should be done, I've been waiting for an update to whatlinkshere from a navbox update for 23 hours now, this is a measurable problem now... --Joy [shallot] (talk) 19:25, 17 December 2012 (UTC)[reply]

The job queue is now over two million. I'd say there's a major bug somewhere. jcgoble3 (talk) 20:56, 17 December 2012 (UTC)[reply]
And now it's skyrocketed to over 5.5 million. Can somebody please file a bug on Bugzilla? I don't have an account there and am not interested in creating yet another account that I'll rarely use. jcgoble3 (talk) 05:49, 18 December 2012 (UTC)[reply]
It's been discussed on the #wikimedia-tech IRC channel - those two big spikes are supposed to be the end of it, and things should be getting back to normal. --Joy [shallot] (talk) 09:26, 18 December 2012 (UTC)[reply]
Having risen to a peak of about 5,500,000 around 2012-12-18T06:00Z, the job queue has since steadily reduced. It is currently about 1.0M.
A measure more meaningful to editors would, I think, be the age of the oldest outstanding job. In terms of the MediaWiki table fields, this would be given by SELECT MIN(job_timestamp) FROM job; (the job_timestamp field was added in MW1.19). Could the siteinfo statistics API be extended to expose the oldest queued timestamp?
Richardguk (talk) 09:20, 20 December 2012 (UTC)[reply]
API enhancement proposed: Bugzilla:43287. — Richardguk (talk) 11:10, 20 December 2012 (UTC)[reply]

The backlog that began accummulating around 2012-11-29T12:00Z was finally cleared around 2012-12-21T00:00Z. — Richardguk (talk) 10:01, 21 December 2012 (UTC)[reply]

Some new scripts

So I added some new scripts to my userspace, that some of you might find interesting. Some of them are older than others, Some of them are ported from hewiki, some of them I added to WP:JS.

  • watchlistMark: As you know, when scanning Recentchanges, the pages in your watchlist appear in boldface. This script adds similar functionality to the pages "User contribution" and to Category pages. In addition, it adds under the page title a little button, that when pressed, adds "watch" link after each page, so you can easily add half (or all) pages in a particular category to your watchlist. For watched pages, the link becomes "Remove". same for pages in "User contribution".
  • Watchlist scout: Will poll your watchlist every time you go to a new page, and every 60 seconds hence. If there are unread pages in your watchlist (i.e., pages that would display in boldface on your watchlist), it jumps a message box similar to the "someone left you a message", with links to your watchlist, to the modified pages, and to their history.
  • Template Parameters Wizard: i mentioned it here before, but i take the opportunity to plug it here again. this script helps fill template parameters when editing
  • "In place" rollback (only for users with "rollback" permissions): this script changes the behavior of "rollback" button, such that instead of switching to the version diff page, you stay in place while the target page is rolled back. can be useful in conjunction with "popup". Also, right-clicking the "rollback" link allows you to add a summary to the rollback
  • Hide HotCat markers: If you are like me, you love HotCat functionality, but you hate the way it uglify the Categories section at the bottom of each article. this script hides all the ugliness, and adds "HC" at the right edge of the categories div. pressing the HC will expose all of hotcat controls, and pressing it again will re-hide them (personally, i think this is the way HotCat should have worked from the start).
  • Personal edit tools: allows you to add personalized edit tools in a subpage of your user space that are available when editing. you can have general toos *and* namespace specifci tools.

I hope some of you will find some of these helpful. if you try them and have problems/coplaints/suggestions, please let me know.

Peace - קיפודנחש (aka kipod) (talk) 00:07, 17 December 2012 (UTC)[reply]

Thanks for sharing these. Incidentally, would you be interested in using developer access to MediaWiki so you can contribute JavaScript improvements to the core and important extensions, critique others' front-end commits, and more easily test how your user scripts will interact with upcoming versions of the MediaWiki software? If you don't already have it, it's easy to get -- just get an account at labsconsole.wikimedia.org. Then follow the Git tutorial and skim How to become a MediaWiki hacker to get set up. Thanks! Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) 02:18, 20 December 2012 (UTC)[reply]

"4,122,002 articles in English"

...so says the front page. But it's not, though, is it? That includes redirects and disambiguation pages, which you can't claim to be articles. There are 222,842 disambiguation pages alone; there's no equivalently easy way of counting redirects, but there must be a hell of a lot. (Perhaps someone with Toolserver access could produce a figure.) I try to assume good faith, but if I'm right (I may well be misunderstanding something though) it strikes me as borderline dishonest to report the combined figure as "articles" on the front page in this way. — Hex (❝?!❞) 17:03, 17 December 2012 (UTC) Edit: qualify statement so as not to sound rude. Insertion marked. — Hex (❝?!❞) 17:37, 17 December 2012 (UTC)[reply]

The figure 6,922,662 is pulled from the variable {{NUMBEROFARTICLES}}. However, the MediaWiki documentation states that {{PAGESINNS:0}} differs from {{NUMBEROFARTICLES}} in that the former includes redirects and disambiguation pages - this implies that {{NUMBEROFARTICLES}} does not. --Redrose64 (talk) 17:18, 17 December 2012 (UTC)[reply]
Interesting, thanks. The figure on the front page links to Special:Statistics, which presents the figure as being "content pages", linking to Special:AllPages. However, the list on that page begins with !, which is a redirect. It would be beneficial to have some precise clarification on the matter from a developer. Either way, I would suggest that some wordage on this matter is added to relevant places to avoid any further ambiguity. — Hex (❝?!❞) 17:32, 17 December 2012 (UTC)[reply]
The Special:Allpages link is a bit misleading, I agree (though no doubt well-intended) - a link to the definition of the phrase "content pages" would be better. I vaguely recall we had something like this on Special:Statistics many years ago. Andrew Gray (talk) 18:09, 17 December 2012 (UTC)[reply]
I just found Template:Bugzilla which addresses this point. — Hex (❝?!❞) 19:53, 17 December 2012 (UTC)[reply]
Redirects aren't counted in that total, though disambiguation pages are, and a small number of things which are technically articles aren't. The value is generated using the NUMBEROFARTICLES "magic word" (6,922,662), which is apparently defined as "Number of pages in content namespaces", using the definition at mw:Manual:Using_custom_namespaces#Content_namespaces - so no redirects and at least one internal link. There are well over a million redirects (the largest category is 955k) but I'm not sure of an exact total. Andrew Gray (talk) 17:25, 17 December 2012 (UTC)[reply]
Thanks - had an edit conflict with you here. See my comment above as well. — Hex (❝?!❞) 17:32, 17 December 2012 (UTC)[reply]
We have 5,724,232 redirects in namespace 0 at the time of posting. - TB (talk) 18:15, 17 December 2012 (UTC)[reply]
I've just come across Wikipedia:Database reports/Page count by namespace which is where I'm guessing that figure came from. Useful report. — Hex (❝?!❞) 19:34, 17 December 2012 (UTC)[reply]
I see that the report shows four redirects from category space. This figure should be zero: how do we find which are the redirects? Special:ListRedirects is useless - it doesn't permit a namespace filter, even if you try to put one in the URL, like this. --Redrose64 (talk) 20:08, 17 December 2012 (UTC)[reply]
Using the API i only see one: Category:X2. peace - קיפודנחש (aka kipod) (talk) 21:01, 17 December 2012 (UTC)[reply]
I get the same result with AWB (special page → make list → all redirects → Category: namespace). Category:X2 is explicitly a testing category per the page history and should be left as a redirect. jcgoble3 (talk) 21:07, 17 December 2012 (UTC)[reply]
Ah - I generated the above figure on the Toolserver. I see three redirects from category space; Category:Ming_Empire, Category:X2 and Category:Suspected_Wikipedia_sockpuppets_of_RevAntonio. The fourth one counted on Wikipedia:Database reports/Page count by namespace seems to have been deleted within the last 20 hours. - TB (talk) 21:47, 17 December 2012 (UTC)[reply]

Now that I've been set straight (always happy to be corrected) about redirects, does it sound fair to suggest that maybe the figure for articles shouldn't include disambiguations? — Hex (❝?!❞) 19:46, 17 December 2012 (UTC)[reply]

There would be NO way to count that, because a large number (I'd guess well over half) of disambiguation pages don't have '(disambiguation)' as part of their title. Though I guess one could use articles with Category:Disambiguation pages -- but my gut tells me that 144,646 pages is very low, so there's probably many without the category. ♫ Melodia Chaconne ♫ (talk) 20:56, 17 December 2012 (UTC)[reply]
While not every disambiguation page has {{disambig}} or a similar template, I suspect the vast majority do - so deducting the 244k figure below, which is generated from these templates, would seem to be a good first approximation. You'd also want to account for set indexes such as USS Enterprise (37k pages), which aren't technically disambiguation pages but behave much the same way for readers. Andrew Gray (talk) 21:17, 17 December 2012 (UTC)[reply]
Good catch - I rarely encounter those. Melodia, even if the figure for disambiguations isn't accurate - and I think that Andrew is right in saying that most of them are categorized - it will get more accurate over time. And even incorrect, it still helps to make the total count of articles more representative of reality. — Hex (❝?!❞) 22:14, 17 December 2012 (UTC)[reply]

I missed this discussion in starting a thread at Wikipedia:Village_pump_(proposals)#Correct_the_Main_Page_.22article_count.22, which includes an autocalculation method for excluding disambiguation pages based on Category:All article disambiguation pages. Not sure how or whether to merge these threads; anyone feel free to do whatever seems best. Rd232 talk 21:03, 17 December 2012 (UTC)[reply]

This has been tried before. Graham87 12:21, 18 December 2012 (UTC)[reply]
That discussion (2008) seems mainly to center on what the definition of an article worth counting is, which is probably why it fizzled out - shades of counting the number of angels that can dance on the head of a pin. I don't propose to rule out pages on the basis of being a stub, merely on being disambiguations or set indices, which definitely aren't articles. However, it did lead to the creation of {{Number of actual articles}} (producing "6,445,088") which uses the technique that Rd232 suggested on the other pump. I've just updated it to subtract set indices as well. — Hex (❝?!❞) 13:00, 18 December 2012 (UTC)[reply]
From WP:SETINDEX: "A set index article is not a disambiguation page" (note the shortcut WP:NOTDAB); "Fundamentally, a set index article is a type of list article"; etc. That section repeatedly uses the word "article" in reference to set indices. Perhaps we shouldn't be so quick to dismiss them as non-articles? jcgoble3 (talk) 01:59, 19 December 2012 (UTC)[reply]
  • I would support taking out as many of the disambiguation pages from the total as we can. It might not ever be perfect, but there's no reason for us not to try and get it at least more accurate than it currently is. But this will probably need a Wiki-wide RfC on the issue, because it is kind of a big change to make. SilverserenC 01:19, 20 December 2012 (UTC)[reply]
  • Oppose (already!): Many of the "disambiguation" pages are actually wannabe articles (for example "wannabe"), often for a common word such as "Cotter pin", with see-also relatives that fill the page beyond the specific definition of the word, plus a link to Wiktionary. Too many words are borderline encyclopedic terms, with multiple semi-technical meanings such as for "waffling" (beyond dictionary definitions), or with a simple split personality to Wiktionary, or even a Jekyll/Hyde attempt to wikihijack a term for unusual (or advert) purposes. In fact, if more common words were dab pages, then the mainstream meaning of a word would be the first instance of the term on each dab page, rather than some unusual (or commercial product) name using that common word first on the page. -Wikid77 (talk) 03:38, 20 December 2012 (UTC)[reply]
  • Disambiguation pages are articles, though; they just have very specific structures (but so do list pages, so this isn't without precedent). See Georgia for an example of all the encyclopedic information that can appear on a disambig page. EVula // talk // // 22:38, 21 December 2012 (UTC)[reply]
  • Disambiguation pages are navigation pages, a bit like redirects but with more than one destination. The encyclopaedic content is a minimal amount of information about each linked article to help readers decide which link to click. The intended purpose of the pages is to help readers navigate to information, not to directly provide information. (List pages, on the other hand, are intended to give information directly, though the links in them can be used for navigation as well.) – PartTimeGnome (talk | contribs) 23:33, 21 December 2012 (UTC)[reply]
  • Disambig pages provide links to other pages, yes, but only because this is a wiki and that's what wikis do. You're seeing the links but missing the fact that it is stating all the other articles that have similar names, which, to me, is plenty encyclopedic. If disambig pages didn't "directly provide information", we wouldn't give any context to the links ("floating battery, commissioned 1863" versus "battleship, commissioned 1906", "Australian thriller" versus "American independent drama", etc). You can make the argument that the context is just helping with navigation, but we're splitting hairs at that point. I guess the real question is what constitutes "encyclopedic"? EVula // talk // // 19:10, 23 December 2012 (UTC)[reply]
I'm fairly sure Jimbo had a definition in mind when he typed "Hello world". If someone wants to start hacking at the project because they consider Preston by-election, 2000 less valid/encyclopedic than Flag of Denmark then fine, but there'll be very little support for them doktorb wordsdeeds 19:17, 23 December 2012 (UTC)[reply]

Better table editing?

One of the perils of editing a table with lots of columns and/or rows is that if you try to add or delete an entry or column, you can mess up the whole table.

Is there/should there be any way to make it possible to edit a table like you would in Word or Excel or something? That is, have an interface that looks like a table, where you can add or remove columns from the top of the table (instead of having to individually add the new column to each row), and edit a cell or add or delete a row without the possibility of messing up the "framing" for the rest of the table. It would let less computer-savvy people add things to tables without worrying about screwing up the entire table, and make it a *lot* less time-consuming to add a new column to a table with a lot of rows.

To keep people from throwing in gratuitous tables or whatever, you could restrict "table edit" to existing manually-created tables, but letting people add information to an existing table without having to worry quite so much about the format of the table would be nice.

(for example, recently, on the "vampire traits" page, I added a new column to one of the tables, and that page has something like 75 entries per table...) — Preceding unsigned comment added by Tamtrible (talkcontribs) 21:17, 17 December 2012 (UTC)[reply]

The VisualEditor - which in the long run will make Word/Excel style editing possible - went into alpha testing on the English Wikipedia last week; details here, and you can enable it in preferences. (It's opt-in for the moment) Tables are not currently supported, but hopefully that functionality will be along soon :-) Andrew Gray (talk) 21:58, 17 December 2012 (UTC)[reply]
Yay! Any ETA on it reaching the general public, and/or the addition of table functionality?... Tamtrible (talk) 22:12, 17 December 2012 (UTC)[reply]
Not sure about specific elements, but the development plan calls for it to be "enabled by default for (almost) every wikipedia/mediawiki instance" - presumably with all functionality up and running - by July 2013. It may well slip - it's a hard project - but they did manage to make the December 2012 target for initial deployment, so you never know :-) Andrew Gray (talk) 22:39, 17 December 2012 (UTC)[reply]
  • MS Word-to-wikimarkup or markup-to-Excel tools and templates: There is currently a tool that generates wikimarkup from an MS Word table. For the reverse, from wikimarkup to Word-format, there might be a tool under development, until the VisualEditor is expanded to handle wikitables. Also, for wikimarkup-to-Excel, see thread "#Widget for downloading tables into .csv format?" about generating quotation-mark strings with commas, by JavaScript tool User:Writ Keeper/Scripts/tableConverter.js. However, just as I advise people that the most-powerful text editors are experienced Wikipedians who have time to edit what you want, it might be much easier to just "hone some wikitable-editing skills" and get a hand-coded pattern to update wikitables using an external text editor, until some more complex tools are available. Also, remember that a "<td>" tag works like double-bar "||" and "<tr><td>" can be used to force a new row into a table, so there are some tricks which can be used to quickly insert a new column into a table of several hundred rows. Meanwhile, new Template:Autocol and Template:Autotable5_big can be used to auto-number items in a list of entries or table-row parameters (5 columns per row). -Wikid77 (talk) 04:25/05:11, 20 December 2012 (UTC)[reply]

Information about existing inter-language bots

I'm looking for information about:

  • which bots are active in Wikipedia for correcting inter-language links
  • what those bots actually do

I've searched around but could only find the list of registered bots, the help section about bots and interlanguage links and various other not really useful results. I could NOT find any information about what each of the listed bots actually does. Does that information exist anywhere, and if so where?

--Robert (talk) 04:25, 18 December 2012 (UTC)[reply]

I think they often use the same Pywikipedia code. See mw:Manual:Pywikipediabot/interwiki.py. PrimeHunter (talk) 05:11, 18 December 2012 (UTC)[reply]
By the way, Wikidata will soon make interwiki links obsolete. --Rschen7754 05:13, 18 December 2012 (UTC)[reply]
I don't think that all the ILL bots use the same Pywikipedia code; some of them screw up ILLs on template doc pages, but most don't. This suggests to me that more than one algorithm exists. --Redrose64 (talk) 13:37, 18 December 2012 (UTC)[reply]
I think the question on top is asking which bot can repair the problem inter-language links but not how to make a bot. The problem inter-language links are include: if A links to B, B will be linked to A, and if A links to B and B to C, A will be linked to C.(help section about bots and interlanguage links) --Roiny88 (talk) 17:03, 18 December 2012 (UTC)[reply]

Internet Explorer 8

My user scripts work on Firefox and Chrome, but almost all of them don't work on Internet Explorer 8, which is the browser installed on school computers. I tried enabling the JavaScript Standard Library in gadgets, but it did nothing. Here's a list of my enabled gadgets:

  • Disable access keys
  • Open external links in a new tab/window
  • Twinkle
  • Suppress display of the fundraiser banner
  • "Ask a question" feature for the Wikimedia Foundation's "Teahouse" project
  • Reference tooltips
  • HotCat
  • wikEd
  • Yet Another AFC Helper Script
  • Form for filing disputes at the dispute resolution noticeboard
  • Add an [edit] link for the lead section of a page
  • Change the "new section" tab text to instead display the much narrower "+".
  • Disable animations in the interface.

I especially need Twinkle, seeing how I use it for basically everything. Is it possible to fix this, or do I just have to use Chrome portable? ❤ Yutsi Talk/ Contributions ( 偉特 ) 13:09, 18 December 2012 (UTC)[reply]

For the last couple or three weeks (probably since the last MW upgrade), I've been having lots of delays in IE8; I'm always getting the "Stop running this script? A script on this page is causing your web browser to run slowly..." message, even at pages such as Guam or Commons:Special:Upload. Nyttend (talk) 13:37, 18 December 2012 (UTC)[reply]
Probably unrelated to the above problem. You may want to start your own thread of discussion. --Izno (talk) 13:55, 18 December 2012 (UTC)[reply]
You're SOL on at least Twinkle. See WP:TWINKLE. IE in general is notorious for being a special case in both Javascript and CSS, and it's only with the newest of versions that developers are able to do something useful with it without devoting hours of work for small functionality. --Izno (talk) 13:55, 18 December 2012 (UTC)[reply]
Probably unrelated, but you might have to upgrade your browser to Internet Explorer 9 if you have Windows 7 or Windows Vista Service Pack 2. Otherwise, good luck. --George Ho (talk) 15:18, 18 December 2012 (UTC)[reply]
Yutsi is using a school computer, so probably not in a position to change browsers.--SPhilbrick(Talk) 17:09, 18 December 2012 (UTC)[reply]
this may or may not solve this specific problem, but it might help: MediaWiki:Geonotice.js which is loaded by everyone, contains an extra comma on line #31. this does not bother the sane browsers, but it bugs the hell out of IE. if one of the sysops can delete this comma, Yutsi will be able to sail on until he/she will encounter the next problem... peace - קיפודנחש (aka kipod) (talk) 19:28, 18 December 2012 (UTC)[reply]
I'm guessing it's this one. It's been like that for weeks; people removing the last notice don't seem to remove the comma from the one that becomes the last notice. --Redrose64 (talk) 19:37, 18 December 2012 (UTC)[reply]
it would help if one or more of the sysops would occasionally browse the site using IE8 and IE9, esp. in "compatibility mode". what you want to do is go to Tools => Internet Options => Advance tab, and there, under the "Browsing" section, you want to mark "Display notification about every script error". after that, you want to browse enwiki with "Compatibility mode" on. it really doesn't matter if this is a despicable browser - one can't ignore the fact that it is used by huge potion of the readers and editors, so the site should better work correctly with this browser. it is also a good idea to repeat this exercise from time to time when logged out, to make sure anons do not run into problems. peace - קיפודנחש (aka kipod) (talk) 19:52, 18 December 2012 (UTC)[reply]
Agh - a thousand apologies for letting that one slip in. Thanks for noticing & fixing it! Andrew Gray (talk) 20:49, 18 December 2012 (UTC)[reply]

Huggle configure

Hi Editors, I have recently gotten rollback perms, and I want to use Huggle. I'm not sure how to configure it, so I was wondering if you could help me out. Cheers! Kevin12xd... | speak up | take a peek | email me 21:05, 18 December 2012 (UTC)[reply]

I would suggest you explore the menus. It's not really hard to use technically, the difficulty is avoiding false positives. Suggest you also look at the other tools available. Rich Farmbrough, 23:35, 18 December 2012 (UTC).[reply]


Ganglia

I was watching some job queue logs on Ganglia, suddenly it is asking for authorisation. http://ganglia.wikimedia.org/latest/graph_all_periods.php?c=Miscellaneous%20pmtpa&h=spence.wikimedia.org&v=93084&m=enwiki_JobQueue_length&r=hour&z=default&jr=&js=&st=1325547418&z=large is the url. Any ideas what's going on? Rich Farmbrough, 23:35, 18 December 2012 (UTC).[reply]

There is a security issue that has been discovered with the software (a cross-site scripting attack) so until this is resolved we've had to lock it down.--Jorm (WMF) (talk) 23:55, 18 December 2012 (UTC)[reply]
Explained in http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065184.html --Malyacko (talk) 11:56, 19 December 2012 (UTC)[reply]
Thanks. Never understood why people put these security holes in in the first place, when they know they will just have to remove them.... But good to know what's happening. Rich Farmbrough, 12:01, 19 December 2012 (UTC).[reply]
It's not that the developers put them consciously in place. They got notified only recently about them. --Malyacko (talk) 11:28, 20 December 2012 (UTC)[reply]

Signing in from "New section" on a village pump and returning afterwards goes to "Edit" on the village pump

I can't really put it any better than the title. This bug occurs for me on WP:Village pump (technical) and WP:Village pump (miscellaneous) under both Firefox and Chromium on Arch Linux. --Gizmoguy (talk) 23:43, 18 December 2012 (UTC)[reply]

Do you mean it goes to a full page edit and not to add a new section? It does the latter for me in Firefox with the url http://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia:Village_pump_%28technical%29&action=edit&section=new. My steps: Log out, click "New section", click "Log in" (without showing preview or changes), sign in, click "Return to Wikipedia:Village pump (technical)". Are you doing the same steps or talking about something else? If you mean that something you had written in the edit box is not restored after you click "Return to Wikipedia:Village pump (technical)" then it's not supposed to be restored. Try your browser back button for that, or use another tab to log in. PrimeHunter (talk) 00:32, 19 December 2012 (UTC)[reply]

Background color changing

Under Monobook (in IE9), whenever I roll over any link (including those in the sidebar) on a page that isn't white (or perhaps just pages in non-article space) the color of the text body area changes to white. This also happens with some pieces of the Main Page. Am I the only one experiencing this? - Purplewowies (talk) 23:58, 18 December 2012 (UTC)[reply]

Why Google search over internal search on village pumps?

At WP:Village pump I can see a search link for each village pump. These search links go to Google, which I feel is a bad idea for a number of reasons:

  1. If the internal search was used it provides a wider test base for the internal search for use over meta.
  2. Forcing an external search provider on users raises aesthetic and privacy concerns.

I discovered a discussion at WP:Village pump (policy)/Archive 59#NOINDEX of all non-content namespaces relating to this but it is old and I believe many of the counter-arguments to be outdated. Thus I propose a switch to the internal search.--Gizmoguy (talk) 00:00, 19 December 2012 (UTC)[reply]

As you may know, this was probably done when the internal search was less effective. You may find it easier to propose a change now. Superm401 - Talk 01:50, 21 December 2012 (UTC)[reply]

Spurious error message when attempting to move an article page

When attempting to move Palestinian territories—I can't do this directly because the move arrow drop-down doesn't appear on my monitor between the add-to-your-watchlist star and the search box, but I can try by directly using the URL [4]—I see the message: "Unable to proceed This image name or media file name is protected. When uploading files to Wikipedia, please use a file name that describes the content of the image or media file you're uploading and is sufficiently distinctive that no-one else is likely to pick the same name by accident."

But I'm not trying to upload or move an image, I'm trying to move an article. I wouldn't be surprised if the article is protected, but the usual padlock icon indicating protection doesn't appear in the usual place on the article page.

Actually I'm not really trying to move the page. I just want to look at the move log, which I can do for the talk page, but not the article. Oh, I see. There's a way to look at the move log without actually trying to initiate a move: [5].

Oh, I see. I can go to View logs for this page which is easy to overlook, just under the page title for Palestinian territories: Revision history.

Now I see that it is protected:

  • 02:57, 14 May 2008 NawlinWiki (talk | contribs) protected Palestinian territories (no reason to move this page w/o discussion [move=sysop])

So, I, with some effort, just backed into understanding everything here. It would be nice though, if a move attempt like mine above still showed the move logs (no reason why it couldn't), and when failing due to protection, also showed the protection log. Thanks, Wbm1058 (talk) 14:50, 19 December 2012 (UTC)[reply]

At the top of every history page, there is a link "View logs for this page", immediately below the page title. This link is present even if there are no log entries. However, page moves are always logged against the old name, not the new. --Redrose64 (talk) 17:35, 19 December 2012 (UTC)[reply]
The real question here is why Special:MovePage/Palestinian_territories returns an error message clearly intended for the File: namespace only. That sounds like a bug. jcgoble3 (talk) 18:56, 19 December 2012 (UTC)[reply]
Thanks – Worthy of telling bugzilla about? I don't have any experience with entering bug reports or searching to see if it's already been reported. Wbm1058 (talk) 19:54, 19 December 2012 (UTC)[reply]
As far as I can tell, this is not a bug in MediaWiki but rather in the template code at MediaWiki:Protectedpagetext. PleaseStand (talk) 20:18, 19 December 2012 (UTC)[reply]
I think that the message being referred to is:
This image name or media file name is protected.

When uploading files to Wikipedia, please use a file name that describes the content of the image or media file you're uploading and is sufficiently distinctive that no-one else is likely to pick the same name by accident.

Examples of good file names:

"City of London skyline from London City Hall - Oct 2008.jpg"
"KDE Kicker config screenshot.png"
"1863 Meeting of Settlers and Maoris at Hawke's Bay, New Zealand.jpg"
"Polyhedron with no vertex visible from center.png"

Examples of bad file names:

"Image01.png"
"Joe.jpg"
"DSC00001.JPG"
"30996951316264l.jpg"
For more information, please see Wikipedia:Image file names. If you have a good reason for uploading a file with this name, or if you receive this message when attempting to upload a new version of an existing file, please let us know at Wikipedia:Administrators' noticeboard. Be sure to specify the exact name of the file you are trying to upload. Thank you.
That's the message output by MediaWiki:Protectedpagetext when {{#ifeq:{{NAMESPACE}}|{{ns:-1}}| tests as true, which should only happen for pages in Special: namespace. --Redrose64 (talk) 20:55, 19 December 2012 (UTC)[reply]
There was a problem in MediaWiki:Protectedpagetext - but I don't think that it caused this particular issue. --Redrose64 (talk) 21:09, 19 December 2012 (UTC)[reply]
That's right, the template I see is {{Generic image names}}. There are 243 transclusions of this template, how do you know that MediaWiki:Protectedpagetext is the culprit? – Wbm1058 (talk) 21:19, 19 December 2012 (UTC)[reply]

I'm not sure what route Redrose64 took, but here are the tricks I would have used:

  1. Go to your link, so I see the same message you saw.
  2. Edit the URL to add ?uselang=qqx to the end. This causes all the messages on the page to be replaced with the name of the page that generates the message.
  3. Look at the source of MediaWiki:protectedpagetext, since the previous step showed "(protectedpagetext: protect)" (the bit after the colon is a parameter).
  4. Look at {{Generic image names}}, since it is one of the first templates mentioned, and find that it contains the text you saw.

I'm guessing MediaWiki:protectedpagetext shows that template on Special pages because someone thought Special:Upload was the only special page to show this message. Special:MovePage is also a special page that uses the same message, though. MediaWiki:protectedpagetext should probably be changed to check {{BASEPAGENAME}} to work out on which special page it is used. – PartTimeGnome (talk | contribs) 22:56, 19 December 2012 (UTC)[reply]

It's very simple... I read what PleaseStand posted at 20:18, 19 December 2012. --Redrose64 (talk) 23:04, 19 December 2012 (UTC)[reply]

 Fixed I've changed the test to specifically look for Special:Upload rather than any page in the special namespace. Anomie 03:27, 20 December 2012 (UTC)[reply]

There's still a minor issue: the "protection log" link does not work, as it points to the log for Special:MovePage/Palestinian territories rather than Palestinian territories. PleaseStand (talk) 14:15, 20 December 2012 (UTC)[reply]

Help to install fastbuttons

Dears, I'm trying to install fastbuttons, but it doesn't work. Can someoene help me please? Thanks in advance. E. Feld talk 15:11, 19 December 2012 (UTC)[reply]

You may be better off using Twinkle which can be installed from Preferences-->Gadgets. It does the same as fastbuttons and more.--ukexpat (talk) 17:45, 19 December 2012 (UTC)[reply]
Thank you very much. E. Feld talk 19:15, 19 December 2012 (UTC)[reply]

Enable Article Feedback Tool

How do I enable "Article Feedback Tool v.4" of Wikipedia on it.wikivoyage? Thanks Raoli (talk) 22:06, 19 December 2012 (UTC)[reply]

it's a Mediawiki extension. lookie here: mw:Extension:ArticleFeedback. please note that the latest version is v5, here: mw:Extension:ArticleFeedbackv5. peace - קיפודנחש (aka kipod) (talk) 22:32, 19 December 2012 (UTC)[reply]
So I have to ask here? mw:Extension talk:ArticleFeedback Raoli (talk) 23:33, 19 December 2012 (UTC)[reply]
But they are not installing the version 5 on other wikis yet... Helder 02:21, 20 December 2012 (UTC)[reply]
We can also install version 5, but I have to figure out whom I have to ask. v4 or v5 is the same. The question is
where ask --Raoli (talk) 03:05, 20 December 2012 (UTC)[reply]
i am not familiar with the specifics of it.wikivoyage. if it's managed by the wikimedia foundation, i think the right place to ask is at the mediawiki bugzilla ( https://bugzilla.wikimedia.org , i think). even though this is not bugzilla's stated reason for existence, it became the place where wiki communities for wikis run by the wikimedia foundation go to ask for local changes, such as installing new extensions, creating new permission groups or changing existing ones, changing defaults for this wiki etc.
if someone other than wikimedia foundation is running it, you have to discuss it with the sysop of this system (not "sysop" in the wiki sysop sense, but in the *nix sysop sense).
presuming it *is* the foundation, you need to get a consensus on your wiki in the appropriate place, probably the equivalent of WP:VP here, and then ask on bugzilla, with a link to the consensus/vote. peace - קיפודנחש (aka kipod) (talk) 03:08, 20 December 2012 (UTC)[reply]
Wikivoyage is the new Wikimedia project. Thanks a lot for help --Raoli (talk) 03:38, 20 December 2012 (UTC)[reply]
For extension deployment requests you file a ticket in https://bugzilla.wikimedia.org under product "Wikimedia" and component "Extension setup". If I remember correctly, AFTv5 won't be deployed to other installations before it's more stable. --Malyacko (talk) 11:34, 20 December 2012 (UTC)[reply]
Great Malyacko! yes, I also knew that the version 5 first has become stable and then can be used on other wikis. --Raoli (talk) 17:14, 20 December 2012 (UTC)[reply]

Weird maint category quirk

Something odd happens with populating Category:Articles with missing files. Todays example is David S. Alberts. It was edited on 3 Dec by adding a file that was then deleted from Commons on the 10th of Dec. But the David S. Alberts article popped up in the the category today (20 Dec). Does someone have to hand deliver the info between servers in a dead tree format? -- Alan Liefting (talk - contribs) 00:38, 20 December 2012 (UTC)[reply]

Updating of link tables can take a long time. See Help:Job queue#Updating links tables when a template changes for what is supposed to happen when a category change is caused by a template edit. (Per Wikipedia:Village pump (technical)/Archive 105#Special:WhatLinksHere/Too_Close I'm uncertain whether it actually works like that.) In the present case it wasn't even caused by an edit but a deletion of commons:File:Dr. David Alberts.jpg. I don't know whether anything is placed in the job queue at wikis using the file. Maybe the update just has to wait until an unrelated event causes a link table update for the page. mw:Help:Tracking categories doesn't say how updates happen. PrimeHunter (talk) 01:44, 20 December 2012 (UTC)[reply]
When someone deletes a (local) file, a job in the job queue is placed to clear the html cache (aka purge the squid cache [which is currently disabled on wmf wikis] as well as update page_touched). However links are not cleared. Furthermore if the image is from commons, nothing is placed in the job queue. Thus the missing file category only gets updated if somebody edits the page (or null edits, or edits a transcluded template). Bawolff (talk) 00:22, 22 December 2012 (UTC)[reply]

Re-cluttering of expansion-depth category

This is just an FYI that a questionable change to Template:Automatic_taxobox has again flooded the depth-error category, from containing 3 pages of entries, to over 16 pages (more than 2,500 new entries):

When scanning the now massive category, just remember that most of the animal/plant articles have exceeded depth due to {Automatic_taxobox}, which had been fixed back in November 2012. Other articles have depth problems in nested NRHP infoboxes or railway routes, which need conversion rounding by "|1" such as {convert|1.5|acre|ha|1} or similar. Talk-pages usually exceed the 41-level depth due to unclosed "}}" when transcluding WikiProject banner templates. I think the taxobox change is likely to be undone in a few days, or redone with a different taxonomy check, where the exceeded-depth error will no longer occur. However, the reformatting of articles with a shared template often requires over 4 days to complete now, so expect the depth-error category to shrink some time late next week. This is just typical Wikipedia progress: "take 10 steps forward, and 9 steps back" but eventually, things will get better. -Wikid77 (talk) 02:39, 20 December 2012 (UTC)[reply]

Can't expand sections in mobile version of this article

On my iPhone, when I view the article Ionized jewelry, I can't expand any of the sections. They all have grey titles and are not clickable. Anyone know what's wrong with this particular article? Gary King (talk · scripts) 20:39, 20 December 2012 (UTC)[reply]

It sounds like you're running into a caching issue, which sometimes happens after deployment. The mobile team just deployed some updates on Wednesday, but old code occasionally persists after deployment and mucks with things like section toggling. We're working to resolve this issue permanently. Sorry for the annoyance – in the short term, you can add &debug=true to the end of any mobile URL, and that should take care of the problem. Maryana (WMF) (talk) 21:24, 20 December 2012 (UTC)[reply]

Using Lua-based templates to scan for errors

This is just an FYI that we can perform some lightning-fast syntax checks using Lua script modules for templates that treat article text, or template innards, as nowiki-enclosed strings, limited to null-nowiki tags ("<nowiki/>") inside. An entire large section of an article, or the inside of a template could be passed as one argument enclosed by <nowiki>...</nowiki> if only null-nowiki tags are used within the Lua-scanned section, which could contain pipe-bars "|" inside the parameter text until ended by an end-nowiki tag, </nowiki>. This means that a Lua-based template could make very fast syntax scans of the text/markup, without actually fully parsing the double-brace "}}" tokens, and perhaps some quick miscoded markup, such as unclosed/unopened HTML comments "-->" could be quickly detected (and pinpointed) to save minutes/hours of proofreading markup to spot the embedded syntax errors. Based on allowing such capability to syntax-check template logic, then a typical null-nowiki would be coded as "{<nowiki/>{" rather than "<nowiki>{{</nowiki>" because the first end-nowiki "</nowiki>" would expose pipe-bars as end-of-parameter text to stop the scan for errors. Long-term, we might find rapid techniques to perform actual partial parsing of markup to check for more complex errors in syntax, or find misspelled parameters, by using a concordance list of parameter names used in the template (etc.). Things to ponder. -Wikid77 (talk) 21:20, 20 December 2012 (UTC)[reply]

Just because something is possible doesn't mean it's a good idea. This strikes me as an extremely bad one, as it did the last several times you've brought it up. Anomie 13:13, 21 December 2012 (UTC)[reply]

There is probably a more appropriate place to report this, but attempting to report a possible error brings up a peculiar page. Where from here? RashersTierney (talk) 22:47, 20 December 2012 (UTC)[reply]

The owner of the cluebot.org domain needs to renew the domain registration, which expired about 24 hours ago. jcgoble3 (talk) 01:17, 21 December 2012 (UTC)[reply]
Forgive the non-technical viewpoint, but what is an editor to do when cluebot gets it wrong? Is cluebot bust? RashersTierney (talk) 01:31, 21 December 2012 (UTC)[reply]
No, you just have to wait until they pay their bill. Until then, there isn't much we can do. I suppose you could post here.This, that, and the other (talk) 03:41, 21 December 2012 (UTC)[reply]
Regardless, reporting a CBNG false positive is always secondary to the much simpler task of reverting the edit. And considering how rare false positives are, I imagine the false-positive reporting system could go down for months without any noticeable decay in ClueBot's effectiveness. (And if it were to start seriously malfunctioning, it's so active a bot that an admin would have to shut it down immediately.) — Francophonie&Androphilie(Je vous invite à me parler) 03:51, 21 December 2012 (UTC)[reply]
Thanks for replies. RashersTierney (talk) 10:28, 21 December 2012 (UTC)[reply]

See this thread on my talk. A while back, {{ArticleHistory}} was moved to {{article history}} to get rid of the CamelCase (there had been a redirect at the new title for several years). Apparently user:GimmeBot, which keeps this template up to date, can only detect ArticleHistory and not the spaced version. This should be a trivial fix: could any friendly neighbourhood bot operators (or anyone who knows where to find one) help the operator of this one out? Chris Cunningham (user:thumperward) (talk) 00:40, 21 December 2012 (UTC)[reply]

I'd be happy to help. If the bot op is willing, I could take a look at the code and identify the changes that would be needed. 28bytes (talk) 04:37, 21 December 2012 (UTC)[reply]
This is a behaviuoral issue of User:Thumperward, who declared that his move 'will not break one single script nor bot of any sort', and '"Prominent" Gimme may be, but his understanding of how this will affect his bot is most certainly incorrect.' Then proceeded to make edits such as [6] to further interfere with the bot. His previous actions on the page include a unilateral move of the page despite prior discussions. User:Thmpeward also failed to notify me of this. Gimmetoo (talk) 13:44, 21 December 2012 (UTC)[reply]
(watching) you were in a discussion with User:Thumperward, linked above, it notified of this (I saw it), don't you think you should watchlist a discussion that you started? - Move or no move, the bot seems not to have functioned for the name "article history" during the time that is was a redirect, that needs to be changed, right? --Gerda Arendt (talk) 13:55, 21 December 2012 (UTC)[reply]
A redirect that wasn't being used (21 times out of >30k, a couple of which at the time had just been added by Thmperward.) This issue is one facet of the long-term disruption of the FA process, and it's time that disruption stopped. Gimmetoo (talk) 14:07, 21 December 2012 (UTC)[reply]
Let's keep it technical, please. I am not interested in the past of the FA process but in the future. I think that the present name is the better name for that future (I am not the only one, see the move discussion), and the bot should be able to handle it, - should have handled it in the past also, if you ask me. --Gerda Arendt (talk) 14:39, 21 December 2012 (UTC)[reply]
Yes, a move discussion supported by a number of people involved in the disruption of the FA process. Gimmetoo (talk) 14:45, 21 December 2012 (UTC)[reply]
Please let's keep this technical, --Gerda Arendt (talk) 15:26, 21 December 2012 (UTC)[reply]
There is no technical reason why one name is better than the other. The onus is on those who promised, at the time of the proposed name change, to facilitate that change. They have to follow through on their promises. It's not Gimmetrow's job to clean up the mess left by their broken promises. Raul654 (talk) 16:51, 21 December 2012 (UTC)[reply]
The bot, which has not run since the 19th, closes all FACs, FLCs, GANs, PRs and more while updating articlehistory. I wasn't aware that Gerda Arendt had technical expertise, and there is no reason for one name to be preferred over another, particularly when it interferes with bot code. Jack Merridew did have technical expertise; if this is yet another extension of long-standing disruption of the FA process, which has been spread to other FA pages, it needs to stop. Please restore the template so that the bot can continue closing content review pages; FAs promoted since the 19th have not been closed. SandyGeorgia (Talk) 17:06, 21 December 2012 (UTC)[reply]
Excuse me, Sandy, what gives you the idea that I have technical expertise? I have a reason to prefer one name, as you can read in the move discussion, and I don't like to be reverted when I use that name, which the template has, that's all. I expected the bot owner to simply change, but he said "no" and got us here. Now the technical question is how to make the bot accept all names the template has (more than two). I can't help because I have no technical expertise, but 28bytes and Frietjes offered help. --Gerda Arendt (talk) 21:30, 21 December 2012 (UTC)[reply]
What "gave me the idea" was your repeated reference to "technical"; thanks for the explanation. SandyGeorgia (Talk) 00:00, 22 December 2012 (UTC)[reply]
I think we can agree that this is a page for technical, not personal, matters? If I read your comments below, we don't agree (yet) that the bot has to accept all names for the template, regardless of what is currently the name and what are redirects. The present bot doesn't do that and therefore needs to be changed. Help has been offered, --Gerda Arendt (talk) 00:26, 22 December 2012 (UTC)[reply]
Sandy, I appreciate the support, but there is nothing particular stopping the bot from running. The technical issue here involves the name ("article history") and the spacing ({{ article history }}) that Thumperward chooses to use. The specific consequence is my code doesn't happen to recognize that particular combination of stuff in the text of a talk page, which means it won't update the existing data under that form (and so would likely create a second AH). Of course, I could write more code on my end to deal with yet more options, but more code means more code to maintain, more branches where things can go wrong, and slower code (when it has to check more options on big talk pages). I'm not interested in doing that, for reasons I imagine you can guess. I opposed the name change in October as unnecessary (and other reasons). It went though, in part, on the formal promise of Thumperward to fix all issues. There are a couple other solutions to this problem, but the easiest one is to put the template back where it was before October. Gimmetoo (talk) 18:03, 21 December 2012 (UTC)[reply]
Thanks, Gimme ... so that the bot works correctly, what do we need to watch for? Only article talk pages with article history instead of ArticleHistory (space) will affect the bot? Who is preventing the original from being restored? SandyGeorgia (Talk) 18:18, 21 December 2012 (UTC)[reply]
There was a rough consensus here to move the template title, but the closer said, "if any technical glitches and the like are not easily fixable, then I will move the template back". So it could be re-opened for discussion in light of the potential difficulties. —Torchiest talkedits 18:37, 21 December 2012 (UTC)[reply]
Thanks Torchiest; that seems to sum it up, then. The new template title is causing problems, and it doesn't appear that thumperward is addressing them, so it should be moved back. SandyGeorgia (Talk) 00:01, 22 December 2012 (UTC)[reply]
IMHO "the long-term disruption of the FA process" and causes for those disruptions are perhaps a matter of perspective and perception. — Ched :  ?  15:32, 21 December 2012 (UTC)[reply]
I came to add that I believe in the "FA process disruption narration" as in Santa, but you worded it better, Ched, --Gerda Arendt (talk) 15:54, 21 December 2012 (UTC)[reply]
I'm sure there is a good faith explanation for why the same users perennially show up in the same discussions; I'm just not aware of what that explanation might be. In the meantime, a bot that is important to closings in all content review processes is stalled over a triviality, which seems disruptive to me. SandyGeorgia (Talk) 17:09, 21 December 2012 (UTC)[reply]
Just to be clear, it's not stalled. Gimmetoo (talk) 18:07, 21 December 2012 (UTC)[reply]
Is there a particular reason why the code for the bot cannot be updated? is it binary only or something? according to the BRFA it says it is using Python which would be trivial to update. Frietjes (talk) 16:16, 21 December 2012 (UTC)[reply]
Several people have offered to update the bot code but it seems the bot owner prefers to keep the outdated CamelCase of "ArticleHistory" instead of an updated "article history".

Although there've been charges that the update is part of "the long-term disruption of the FA process", this doesn't seem to be the case. Gimmetoo (the bot owner) has repeatedly said that the bot is operating just fine for all FA processes and "there is nothing particular stopping the bot from running" and it is not "stalled". It's just that the bot code doesn't happen to recognize "article history".

I admit I've been put off by the "ArticleHistory", so when I pass an article for GA, I don't mess with updating it on the article talk page. But whatever. I guess the bot owner has the last say. MathewTownsend (talk) 23:49, 21 December 2012 (UTC)[reply]

CamelCase (for anyone interested). Mathew, I've not seen charges that the update is part of ""the long-term disruption of the FA process"; one question was why this was posted to WT:TFAR, a page that has nothing to do with GimmeBot, yet this unrelated issue was tacked on there to a thread about Gimmetrow being appointed delegate-- that is the issue. Looking over the move request, it appears that most editors opposed it (unclear to me why it was closed as a Move), and I will leave it to you to characterize the small group that supported it. I don't see this per se as part of "the long-term disruption of the FA process" at all; Merridew had numerous run-ins with Gimmetrow, and that move discussion occurred before Gimmetrow was appointed delegate at TFAR. So, again, the question is why an unrelated issue was re-visited upon WP:TFAR. SandyGeorgia (Talk) 00:10, 22 December 2012 (UTC)[reply]
whot? See your comment above: "if this is yet another extension of long-standing disruption of the FA process, which has been spread to other FA pages, it needs to stop."[7] MathewTownsend (talk) 00:13, 22 December 2012 (UTC)[reply]
Yep, spread to other FA pages is the issue that needs to stop; the long-term issue of Merridew/Gimmetrow is no longer, as Merridew is community banned, but that discussion occurred before his ban. WP:TFAR has nothing to do with GimmeBot. SandyGeorgia (Talk) 00:23, 22 December 2012 (UTC)[reply]
Nor does Br'er Rabbit have anything to do with this discussion. Is there some reason why you feel compelled so often to mention his name?--Wehwalt (talk) 00:30, 22 December 2012 (UTC)[reply]
Do you consider misrepresentation to be appropriate to civil and honest discourse? Gimmetoo (talk) 02:17, 22 December 2012 (UTC)[reply]
(ec) I would like to pose a different question. Why is Gimmetoo turning away the offers of help he has received from three coding experts who have offered to amend the bot? -- Dianna (talk) 00:16, 22 December 2012 (UTC)[reply]
I believe Gimme has already explained the difficulties that would impose. SandyGeorgia (Talk) 00:21, 22 December 2012 (UTC)[reply]

I've notified Jenks24 (talk · contribs) (the admin who closed what looks like a no clear consensus saying he would move it back if needed) of this discussion; Jenks24 hasn't edited since November 22, so another admin may be needed to move it back. SandyGeorgia (Talk) 00:21, 22 December 2012 (UTC)[reply]

No, Gimmitroo hasn't explained the difficulties, just "Of course, I could write more code on my end to deal with yet more options, but more code means more code to maintain, more branches where things can go wrong, and slower code (when it has to check more options on big talk pages)." By his reasoning (which doesn't make much sense and assumes infinite changes, when this is one measly change), nothing would ever get updated. Why has he turned down all help? MathewTownsend (talk) 00:31, 22 December 2012 (UTC)[reply]

Three different men have offered to look over the code; why are their offers of help being declined? What difficulties would accepting their help impose? -- Dianna (talk) 00:32, 22 December 2012 (UTC)[reply]

As is clear from the presence of numerous non-technical type editors in this discussion, there are clear non-technical issues involved. This is a behavioural issue centred around editors who supported an ill-considered template move, and their friends who support and enable them in various ways. Gimmetoo (talk) 02:14, 22 December 2012 (UTC)[reply]
This reply does not address my question, which was, Why do you not accept the help of the technical experts (Chris, 28bytes, and Frietjes) who have offered to help you go over the script and update it? This would be a Good Thing, and an example of collaboration that non-admins could emulate. -- Dianna (talk) 02:50, 22 December 2012 (UTC)[reply]
Too bad collaboration is not happening. Use:Thumpeward has done exactly nothing so far. Nor has anyone else who has defended him. That lack of action is one bit of evidence that this is not, primarily, a technical issue, but one of behaviour by Thmnperward and his frienda and enablers, which includes you. Gimmetoo (talk) 03:17, 22 December 2012 (UTC)[reply]
I'd like to make sure the situation is clear. There are two possible solutions to the problem:
  1. undo the template move
  2. change the bot's code to handle the new template name
Wouldn't the code change be a matter of having it look for another variation of the template name? Is the bot doing separate searches for each variation right now? Or does it do a case insensitive search? In the former case, it would increase the search time by, I think, 33%? If the latter, searching for spaced version would double the search time. Is that a significant problem in either case? —Torchiest talkedits 03:31, 22 December 2012 (UTC)[reply]


Oh, cut the nonsense. Anyone with enough technical know-how to write a regex to parse "{{ArticleHistory}}" can tweak it to be case-insensitive and eat the space in the middle. (And it should be dealing with leading and trailing spaces anyway; it's silly to have a bot that breaks because someone fat-fingers and types "{{ Article History}}" by mistake.

This is, as stated above, primarily a social issue: Thumperward wanted the template moved to get rid of CamelCase, Gimmetoo wanted it to stay where it is to avoid changing the bot. (This ties in to the greater "I'm from FAC, we're under attack, you can't make us change anything" partisan foodfight.) I don't feel terribly strongly about how the issue resolves; moving templates just to regularize the case seems like useless makework. On the other hand, this appears to be an attempt to overturn the results of a move by exaggerating the technical difficulties of coping with it. If Gimmetoo doesn't want to change his bot, then he should file to have the template moved back (and the redirect deleted) on those grounds, rather than pretending that this is some immense technical difficulty. Choess (talk) 06:16, 22 December 2012 (UTC)[reply]

of course you are correct that the actual code change is a non-issue to anyone with even a small amount of technical ability. (btw, this is also why the "offers to help" are meaningless). however, anyone with any technical experience also knows that writing the code is the smallest part of it, practically negligible. it's not enough to write code - you have to test it and maintain it, and for every future change or enhancement of the bot it means more test cases and more noise. this is not in itself unsurmountable obstacle, and if there was a good reason that requires such a change it's definitely reasonable to expect the bot maintainer to do it. the point here is that the bot maintainer does not think there really is any good reason for this extra work to be dropped on him, and i must admit, after superficially going over the move deliberation, i did not see any reason for this move other than "that's the way i like it". personally i do not care what the template is named (not crazy about camecase myself, but as far as i know it's not against the law of any jurisdiction i ever heard of), but i can definitely sympathize with a bot author/operator not willing to engage in busywork created by other people's whims, with nary a good reason. peace - קיפודנחש (aka kipod) (talk) 06:43, 22 December 2012 (UTC)[reply]
Both the "harm" done by leaving the template name in camel case and the additional complexity required to parse the new title seem very trivial. What I dislike here is the notion that a bot operator can unilaterally overturn a community decision simply by being obstinate, a behavior that's rewarded altogether too much around here. Now, the original move was a very weak example of consensus (to put the best possible face on it), and I think it would be reasonable to "re-run" the discussion with a broader audience; that is, under the original assumption that the template should stay at "ArticleHistory" unless there's a consensus to move it. There should also be greater clarity as to what parties are and aren't willing to do; e.g., I read Thumperward's promise to fix things as implicitly assuming that Gimmetoo would cooperate at least to the extent of adding "article history" to this conditional; Gimmetoo seems to have interpreted it as a promise to magically fix his bot even if he obstructed any attempts to fulfill the promise. I think if it was clear how much disruption this would cause, it would be much more difficult to generate a consensus for moving away from camel case. Choess (talk) 09:34, 22 December 2012 (UTC)[reply]
My understanding is the following: Template:Article history existed since August 2010, the bot has to handle that name (and its lowercase version) also, NO MATTER what the actual template name is. Too simple? Help has been offered. It's not Thumperward whose action is required, but the "bot op" (also termed "bot owner"), --Gerda Arendt (talk) 09:45, 22 December 2012 (UTC)[reply]
Gerda, I'm struggling to understand how you could produce that diff without having seen this one immediately following, where the name was moved back to "ArticleHistory" after an RM failed. That does suggest to me that the path of least resistance might be to update the bot, rather than refighting an RM every year or two. The benefits of moving still seem very small, though. Choess (talk) 15:42, 22 December 2012 (UTC)[reply]
I seem to have a language problem, trying again: the bot has to handle both names (and the other redirects), it has nothing to do with a move. The bot should have handled both names since 2010, it's about time that it gets done. That's what you recommend as well, right? --Gerda Arendt (talk) 15:52, 22 December 2012 (UTC)[reply]
The difference is that the version with the space in the name {{article history}} was not used until the last few months, so the bot didn't have to handle it. The redirect existed, but no articles were using that version of the template yet. It's only in the last few months that the spaced version has been inserted into talk pages, and it has been discovered that the bot doesn't process them. —Torchiest talkedits 16:04, 22 December 2012 (UTC)[reply]
As far as I can tell the bot has to be able to handle all existing names, template name and redirects (6 in the list), independent of whether they are used or not, --Gerda Arendt (talk) 16:50, 22 December 2012 (UTC)[reply]

Indeed. Either the bot handles the names or they should be deleted. So long as the names exist, there is the possibility for them to be used. Gimmetoo is under no obligation to update their bot (we're all volunteers, no one is required to do anything). However, should they continue to refuse, someone else can write a new bot and get it approved at BRFA (requires someone willing). A new bot could either completely replace GimmeBot (except task 3, which is unrelated), or simply clean up the talk pages where GimmeBot adds a second article history template. – PartTimeGnome (talk | contribs) 17:25, 22 December 2012 (UTC)[reply]

coord and navbox do not appear in article page

Resolved

While present in editors code, {{coord}} and {{Suez Canal}} have disappeared from final page El Ferdan Railway Bridge. I just bounced the code into Notepad++ (any bad characters in there?), but to no avail. Yo no comprendo any more. -DePiep (talk) 00:58, 21 December 2012 (UTC)[reply]

 Fixed The problem was the <references> tag – it should have been <references /> (note the slash). – PartTimeGnome (talk | contribs) 01:15, 21 December 2012 (UTC)[reply]
OK, that one again. Thx. -DePiep (talk) 01:17, 21 December 2012 (UTC)[reply]

Password reset improvements

I've made some improvements to Special:PasswordReset, as proposed at Wikipedia:MediaWiki_messages#Special:PasswordReset_improvements. I also created a documentation page about resetting passwords which anyone can edit. Superm401 - Talk 02:57, 21 December 2012 (UTC)[reply]

Wikinews Importer Bot

Does anyone understand Wikinews Importer Bot (talk · contribs) well enough to fix the issue described at Portal talk:Current events#Wikinews stories? I left a message for the bot operator, but Misza13 (talk · contribs) has not edited here since October. -- John of Reading (talk) 08:03, 21 December 2012 (UTC)[reply]

I don't want VisualEdit in sections

I've got VisualEdit enabled in my preferences. VisualEdit for the moment is only for the main name space and the User name space. When you try to section edit in such a page, you get VisualEdit by default.
This is not what I want.
Ideally you should be able to choose between Edit and VisualEdit when you section edit.
But if that's not possible then the default for section editing should be the usual Edit, with VisualEdit being only available when you edit the whole page and you can explicitly choose that option.
After all VisualEdit is an alpha version and I only use it to get a feel for how it works and to help improvement by reporting problems and bugs. My main editing tool still remains the usual Edit box.
I would like not to have to sit around waiting for someone to fix the above mentioned problem. Is there any way I could fix this for myself in the meantime? I mean, short of merely disabling VisualEdit in my preferences and not using it at all.
Many Thanks. Signed: Basemetal (write to me here) 12:04, 21 December 2012 (UTC)[reply]

I completely agree. Users that have chosen to enable VisualEditor for testing should not be forced to disable it in order to do regular section edits. jcgoble3 (talk) 19:04, 21 December 2012 (UTC)[reply]
See also report on the dedicated Feedback page.
Sorry about this; we noticed this bug and fixed it this week, but we haven't deployed it yet; it's scheduled for release as part of the regular deployment on 9 January of 1.21/wmf7. Our apologies for the inconvenience; this is my fault for not catching before release. Jdforrester (WMF) (talk) 21:01, 21 December 2012 (UTC)[reply]

Unintended pop-ups

I recently created this article on Walter Koschatzky. Several words have been created, not intentionally by me, as links and display a pop-up advert when the cursor passes over them. Two, in the Bibliography, are words I added and an intermittent third, "free" in the tag line under the title, is an auto inclusion. The incidence can vary with edits, even if the affected words are not edited. The original article in German also has some of these, eg the word "gold" in the "Auszeichnungen" section. The English article was created by copying text into Google translate, then cut and pasting the translation into the article and rephrasing as necessary. Norton hasn't reported anything. Any explanation; is this a new way of raising funds for wiki? Folks at 137 (talk) 12:29, 21 December 2012 (UTC)[reply]

It's a browser plugin hijacking your session; see here for more details. Try disabling anything you don't remember the name of and restarting the browser... Andrew Gray (talk) 12:49, 21 December 2012 (UTC)[reply]
Yep. Must be malware: MediaWiki:tagline contains no links, and no edit other than one that directly alters MediaWiki:tagline itself can add any. --Redrose64 (talk) 13:16, 21 December 2012 (UTC)[reply]

Restricted-access error messages

I was wandering around on Meta recently, and I clicked on something that turned out to be a steward or local admin function; I was very politely informed that I did not have the proper user rights to do so. I noticed, though, that it was a refreshing departure from the error message we have here. To wit, look at what happens if you - to take the most restricted action possible - attempt to delete the main page here, versus on meta (FAIR WARNING: do not click either of these links if you are a steward, and do not click the latter if you are an admin on meta; it's okay for admins here to click the first link, though) - here; meta. Anyways, the project namespace is rife with restricted-access links, and a lot of them occur in places viewed by many new or new-ish users, such as WP:PERM, WP:RENAME, and WP:AN3. And the "Unable to proceed" warning seems a bit... unfriendly. I mean, imagine you've just created an account named after your favorite local restaurant; you're warned that you should request a rename, and that you might be blocked if you continue to edit before being renamed. So you do, and then you see that convenient boldfaced "rename user" link, and think "Oh, that was easy," and click on it, only to be told that you're "Unable to proceed" because access is limited to the scary-sounding group "bureaucrats"... it might be yet another sign that you're not welcome here. I suggest that we reword the standard message, perhaps to something even lighter than what meta has, considering that the likelihood of seeing such a message decreases exponentially with experience. Why not something like Sorry, but you must be a <relevant required bit> to perform this action.? — Francophonie&Androphilie(Je vous invite à me parler) 12:36, 21 December 2012 (UTC)[reply]

So you'd like to see the "Sorry..." text replacing "The action you have requested is limited to users in the group: [relevant required bit]"? Nyttend (talk) 14:55, 21 December 2012 (UTC)[reply]
Yes. Or words to that effect. And something a bit less stuffy than "Unable to proceed," as well, though I'm not sure what would be the best fit... I've got a bit of a soft spot for those super-casual error messages that are all the rage lately "Uh-oh," "Oops," etc., but I don't imagine I'd ever be able to get consensus for something like that. Sorry for burying the lead there. — Francophonie&Androphilie(Je vous invite à me parler) 15:14, 21 December 2012 (UTC)[reply]
But I always liked the other messages; they sounded like a Microsoft Sam message. However, you have a good point; I'd agree with your proposal. Nyttend (talk) 16:15, 21 December 2012 (UTC)[reply]
I would agree as well. Perhaps "Insufficient permissions" in place of "Unable to proceed"? jcgoble3 (talk) 19:10, 21 December 2012 (UTC)[reply]
Hmmm. Definitely less authoritative. What about something like "Restricted access"? I know that at first glance that seems more, well, restrictive, but my thinking is this: "Unable to proceed" means "You just tried to do something that is impossible for you to do," but "Restricted access" means "Unfortunately, we can't let you do the thing you just tried to do": Instead of placing the burden on the recipient, we're placing it on ourselves (the community). It's just like in the real world - "Unable to proceed" is a cop telling you to get off the beach; "Restricted access" is an "Employees only" sign. And there's something about the impersonality of a sign that makes you feel a lot less offended when told that you can't do something. — Francophonie&Androphilie(Je vous invite à me parler) 19:30, 21 December 2012 (UTC)[reply]
"Restricted access" would work for me also. jcgoble3 (talk) 20:47, 21 December 2012 (UTC)[reply]
"I'm sorry, Dave. I'm afraid I can't do that." ? the wub "?!" 21:12, 22 December 2012 (UTC)[reply]

Signature "What you get" in Help toolbar is broken

In the formatting toolbar click on Help, then scroll down to Discussion and click. Here's what I see right now. Hover shows "Username" and "talk" as being linked to {{#special:mypage}} and {{#special:mytalk}} respectively; I haven't tried to reproduce that here.

Description What you type What you get
Signature with timestamp ~~~~ wikieditor-toolbar-help-content-signaturetimestamp-result: Parse error at position 19 in input: Username (talk) 15:54, 10 June 2009 (UTC)
Signature ~~~ wikieditor-toolbar-help-content-signature-result: Parse error at position 19 in input: Username (talk)

--Thnidu (talk) 19:37, 21 December 2012 (UTC)[reply]

Those messages are coming from MediaWiki:Wikieditor-toolbar-help-content-signaturetimestamp-result and MediaWiki:Wikieditor-toolbar-help-content-signature-result. If you view source on both of them and count off characters, position 19 appears to correspond with the first "{" of "{{#special:mypage}}", so I'm guessing that's what's causing the problem. Probably, the messages expect HTML only with no wikicode. jcgoble3 (talk) 21:01, 21 December 2012 (UTC)[reply]

"Opt in"

What does opt in mean? What would you put in a opt in page? I have no idea if this is technical, but I think it is. § WiHkibew (talk) § 21:07, 21 December 2012 (UTC)[reply]

Things which you may opt to use, but which are otherwise turned off by default (so that you need to make a positive action in order to turn them on). This is jargon, admitedly, but generally fairly well known on the 'net. The opposite it, predictably enough, "opt out". — Coren (talk) 21:31, 21 December 2012 (UTC)[reply]
No, I was talking about a page on Wikipedia. I went on my contributions and went to "edit count." I found it on that page. It says something about opting in. § WiHkibew (talk) § 21:51, 21 December 2012 (UTC)[reply]
Ahhh. I think I know what you mean. Click here and press "save". Leave the page blank. — Francophonie&Androphilie(Je vous invite à me parler) 21:56, 21 December 2012 (UTC)[reply]
I think an entirely blank page doesn't work; to opt in you have to key at least one character. See this archive. -- John of Reading (talk) 10:57, 22 December 2012 (UTC)[reply]
(edit conflict) I think you are talking about the month-by-month breakdown for you contributions here. I think the setup requires opting in for this feature to reduce server usage. If you want to see the monthly breakdown, follow the instructions. This is very specific to this one tool. Chris857 (talk) 21:58, 21 December 2012 (UTC)[reply]
Thanks. Someone said it's "on demand." What does that mean? § WiHkibew (talk) § 22:47, 21 December 2012 (UTC)[reply]
Is there any restrictions or "side effects?" § WiHkibew (talk) § 22:48, 21 December 2012 (UTC)[reply]
None that I know of. I think the only reason you need to "opt in" is that some people prefer to not have their detailed edit stats publicly viewable. (As for the "on demand" thing, I assume that's just another way of saying opt in? Someone correct me if I'm wrong on that, please.) — Francophonie&Androphilie(Je vous invite à me parler) 23:04, 21 December 2012 (UTC)[reply]
I think on demand means it isn't generated until and unless you or someone else asks for it - as opposed to some reports, which are generated on a regular schedule.--SPhilbrick(Talk) 23:47, 21 December 2012 (UTC)[reply]
Oh. Thanks! § WiHkibew (talk) § 02:19, 22 December 2012 (UTC)[reply]
See the Signpost coverage and this thread for more information about why opt-in was instituted for the edit counter. Graham87 09:55, 22 December 2012 (UTC)[reply]
Seeing as I wrote the tool, I feel like I should give explanation for it. Opting in is when you choose to allow something (as opposed to opting out, which is choosing to disallow something). In this case, it is the ability to get additional information about the user. This was done for two reasons: The calculations that have to be done for the namespace counts are slow and require a lot of computing power, and a lot of people don't want their editing history do be publicly analyzed, for privacy reasons. For the former, in 95% of times that someone is using the edit counter, they don't need to see those stats, and so the calculations that were done were worthless. For the latter, one of the rules of the Toolserver is that the database cannot be used to profile users. Thus, to prevent wasting power and speed, as well as to comply with the Toolserver rules, I set it so that the calculations are only done if the user requests it. This can be done by creating the page User:WiHkibew/EditCounterOptIn.js, with any text (it just has to exist). The counter checks if that page exist, and if it does, it runs the calculations. (X! · talk)  · @500  ·  10:59, 22 December 2012 (UTC)[reply]

Captcha

Please change the Captcha system. I just had to make five different attempts to read the blurry junk before I got one right. Other sites have much easier to read proofing texts. 202.179.19.3 (talk) 06:32, 22 December 2012 (UTC)[reply]

Edits at Talk:Padmasambhava don't show up

I've made an edit at Talk:Padmasambhava diff, but it doesn't show up. Anybody an idea why, or how to fix it? Joshua Jonathan (talk) 07:24, 22 December 2012 (UTC)[reply]

Actually no section beyond "On oathbinding" would show, it wasn't only yours that didn't. The problem was in section "On oathbinding". Someone had enclosed references within <references> ... <references/> instead of <references> ... </references>. People, preview your edits before saving. I've fixed it, but maybe this is a general problem worth reporting. Cheers. Signed: Basemetal (write to me here) 07:43, 22 December 2012 (UTC)[reply]
Another thing that's completely weird: most sections after "On oathbinding" now show my signature! Even though I didn't touch them and certainly never signed there. This probably has to do with the same problem. I'm gonna remove those signatures. People looking up the history will be able to see I have nothing to do with those comments. Definitely worth reporting. Signed: Basemetal (write to me here) 07:55, 22 December 2012 (UTC)[reply]
On second thoughts I'm leaving my signatures there as evidence. I think what happened is that because of the original problem in "On oathbinding" the ~~~~ strings were never resolved to a signature. In fact I remember, while editing, seeing all those ~~~~ strings unresolved to signatures, which was not something I had ever seen before while editing. Now when I fixed the problem those unresolved strings probably suddenly all got resolved, but they were resolved to my signature, since it was I who was editing at the time. This means also that the original signatures all got lost and there's no way to automatically retrieve them, I don't think. If you recognize a contribution of yours on that page between sections "On oathbinding" and "Removal of "Life story of Padmasambhava according to Jamgon Kongtrul"" that's signed with my name instead of yours, go there, erase my signature and sign again. In particular user Joshua Jonathan who asked the original question here. Please go there, remove my signature and sign your section. As it stands now, it looks superficially (though not in the history of course) like I created that new section. Very definitely worth reporting. But someone else will have to do it. I've got too much stuff to do already. Cheers. Signed: Basemetal (write to me here) 08:20, 22 December 2012 (UTC)[reply]
Fixed, with the help of SineBot, which tried to add signatures to many of the comments even when the user correctly signed them with "~~~~", because the signature code never expanded. Graham87 10:18, 22 December 2012 (UTC)[reply]
Thanks!!!!! Joshua Jonathan (talk) 11:24, 22 December 2012 (UTC)[reply]

Slow today

Is anyone else seeing slow or never loading pages, or is it at my end? Mr Stephen (talk) 12:25, 22 December 2012 (UTC)[reply]

Dreadful here in Scotland. Ben MacDui 12:39, 22 December 2012 (UTC)[reply]
Fucking terrible here. Lugnuts Dick Laurent is dead 13:41, 22 December 2012 (UTC)[reply]
Yes, HTTP/HTTPS is slow, API working as normal (near London, UK). Rjwilmsi 14:35, 22 December 2012 (UTC)[reply]

Recent change to hlist navbox templates?

Has there recently been a change to hlist navbox templates? Suddenly every hlist navbox template I open has an extra separator at the end of each list - see {{Williams}} as an example. Does everyone else see the same thing, or is it just me? DH85868993 (talk) 12:27, 22 December 2012 (UTC)[reply]

Did you change your browser to IE? --Izno (talk) 15:19, 22 December 2012 (UTC)[reply]
There was an error in hlist related javascript for IE, which should be fixed now. Edokter (talk) — 16:08, 22 December 2012 (UTC)[reply]
All fixed now. Thanks. DH85868993 (talk) 22:25, 22 December 2012 (UTC)[reply]

See this section of the appropriate MediaWiki talk page for context. AFRINIC has changed the layout of its website, so the WHOIS link to it no longer works. The Internet registry still has an online WHOIS tool, but I can't figure out how to look up a particular IP address directly through a URL with the new setup, and I never got a cogent response when I emailed AFRINIC about this some time ago. Could somebody help fix the link? Graham87 12:35, 22 December 2012 (UTC)[reply]

Birthdays - not incrementing age on Birthday

Julie Delpy's DOB was 21 December 1969.

So today, 22 December 2012 she should be 43, but her Wikipedia entry shows her as still 42.

Is this a particular error to Ms Delpy's entry, or is there a more widespread problem? — Preceding unsigned comment added by 82.69.180.246 (talk) 14:46, 22 December 2012 (UTC)[reply]

Pages are cached for performance reasons. See Wikipedia:Purge for how to force an update. PrimeHunter (talk) 14:53, 22 December 2012 (UTC)[reply]
There is a known problem with the age calculation templates in that in some circumstances, they calculate the "wrong" age on the person's birthday, but the following day it gets corrected. --Redrose64 (talk) 21:20, 22 December 2012 (UTC)[reply]

PD-OLD as sole licence

I do some image reviewing for FAC and quite a lot from the MILHIST project. I often find images licenced only with PD-OLD. PD-OLD is essentially a synonym for PD-70, that is to say life-plus-70, which is not a valid licence in the US. So I think we should explore possibilities for those which are hosted on the English Wikipedia only. I don't know how many that is. How straightforward would it be to find out how many files only have this licence and no others? Could someone possibly give me an estimate, if possible? (It's really how many of these files are on en.wp that I don't know - there are at least tens of thousands on Commons.) Grandiose (me, talk, contribs) 16:36, 22 December 2012 (UTC)[reply]

At User:West.andrew.g/Popular pages we now have a counter added to the bottom for FAs and GAs in the top 5000 most viewed articles. However, some "articles" are red links. West.Andrew.g commented here about what he thought it might take to generate a count of the red links. What might it take? I'd like to accurately estimate the percent of GAs and FAs in the most viewed content over time. Biosthmors (talk) 20:56, 22 December 2012 (UTC)[reply]

it is not clear what is meant by "generate". if you want to count it is a one-off operation, hit F12 (assuming you use FF Chrome or IE), select "console", and type $('td a.new').length. if you want it to show on the page itself, presumably by using templates, then i do not know how to do it. if you want it to appear on the page itself by installing some script in your "common.js", then you probably want to add to Special:Mypage/common.js something like:
if (mw.config.get('wgPageName') == 'User:West.andrew.g/Popular_pages' && mw.config.get('wgAction') == 'view')
$(function(){$('#contentSub').prepend('Number of redlinks: ' + $('td a.new').length + ' | '); });
this would add the redlink count to the contentSub (the smll text that appears below the page main title) the count of table cells which happen to be redlinks. peace - קיפודנחש (aka kipod) (talk) 22:17, 22 December 2012 (UTC)[reply]

Blue Dog Coalition

Blue Dog Coalition does not load for me, nor an OTRS correspondent. I can't load the editing window, either. I've tried purging, with no success, and the recent edit history doesn't seem problematic. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:56, 23 December 2012 (UTC)[reply]

I've fixed some unbalanced {{div col}} / {{div col end}} templates. Has that helped? -- John of Reading (talk) 12:11, 23 December 2012 (UTC)[reply]
Yes, thank you. I wonder why that would cause such an issue? Or was it a coincidence? I'm using chrome under Windows XP; my correspondent was using Safari. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:46, 23 December 2012 (UTC)[reply]
I had no trouble using the editing window with Firefox 17. -- John of Reading (talk) 12:56, 23 December 2012 (UTC)[reply]
Both Chrome and Safari are Webkit browsers. That revision hung my PC as well. Edokter (talk) — 12:57, 23 December 2012 (UTC)[reply]

Long reflist performance

Deaths in 2012 is taking about 25-30 seconds to render when reading or preview when editing. On a hunch, I removed the {{Reflist}} template at the bottom, and got a preview in just 5 seconds – that's where the bulk of the time is being spent. I tried hiding it inside a {{Collapse...}} pair, but apparently it still has to organize and render the data because it wasn't any faster.

Is there any way to put the reflist on a separate page from the page on which the refs occur, so they don't have to be organized/rendered unnecessarily?

There are other heavily-cited articles that can benefit from this too, like United States. —[AlanM1(talk)]— 16:10, 23 December 2012 (UTC)[reply]

This is not the use of {{reflist}} per se, but the use of many citation templates. See Wikipedia:Template limits. --— Gadget850 (Ed) talk 16:32, 23 December 2012 (UTC)[reply]
No, it is actually the {{reflist}} performance that I measured. It's presence was the only difference between the two tests, and I did them a number of times the two mentioned articles. —[AlanM1(talk)]— 17:00, 23 December 2012 (UTC)[reply]
Gadget850 is right that the number of citation templates causes the slowness. Without {{reflist}}, the citation templates in the <ref> tags are ignored, so there is no delay.
Though the page is slow, Deaths in 2012 hasn't reached the template limits, and seems to have some way to go before it hits a limit. The limits are where MediaWiki gives up and stops expanding templates altogether. The NewPP limit report below gives details of how close the article is to the limits (use the "View source" command in your browser to get this report when viewing a wiki page).
NewPP limit report for Deaths in 2012
NewPP limit report
Preprocessor visited node count: 149168/1000000
Preprocessor generated node count: 75188/1500000
Post-expand include size: 691782/2048000 bytes
Template argument size: 356985/2048000 bytes
Highest expansion depth: 24/40
Expensive parser function count: 3/500
This has been discussed on this page several times before (e.g. latest discussion). We're waiting for Scribunto to be deployed on Wikipedia, which would allow for more efficient citation templates to be written. – PartTimeGnome (talk | contribs) 17:32, 23 December 2012 (UTC)[reply]
And when you remove {{reflist}}, there is a cite error at the bottom of the page. --— Gadget850 (Ed) talk 17:56, 23 December 2012 (UTC)[reply]
Yes, of course. My point (and the reason I came to VPT with it) was to question if there is a technical way that the references can be put on a different page than the ref tags that it gathers, or rendered on demand, or anything to cause them to not have to all render when viewing or editing the page, which is taking a long time.
I can imagine something like a page Deaths in 2012/Refs, containing {{Reflist|page=Deaths in 2012}}, and a link to Deaths in 2012/Refs in the References section of Deaths in 2012. Alternatively, it might be even better if it were possible that, when the {{Reflist}} is inside a collapsed box, it did not activate until the box was shown (expanded). —[AlanM1(talk)]— 23:49, 23 December 2012 (UTC)[reply]

Perhaps the sensible solution would be to split the page into, say "Deaths in 2012 (Jan-June)" and "Deaths in 2012 (July-Dec)"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:12, 24 December 2012 (UTC)[reply]

That's already the case. Despite the name of the page, it only contains the last 30–40 days—the earlier months have their own pages. The references on the page are only for the current page articles (numbering 326 on the current page for December 1–23). —[AlanM1(talk)]— 04:46, 24 December 2012 (UTC)[reply]
Though I can think of a way to separate the reference list onto a separate page, as Gadget850 pointed out it would leave a big red Cite error message on the main article. Collapse boxes are implemented with browser-side scripts, so cannot be used to stop content being processed on the servers. Andy's idea should work, though.
Note that regular readers don't notice the delay – the page only takes ~2 seconds to load if accessed when not logged in. (Wikimedia have extra Squid caches for IP users, which are not used for logged-in users.) – PartTimeGnome (talk | contribs) 00:29, 24 December 2012 (UTC)[reply]
Subpages are disabled for articles, thus Deaths in 2012/Refs would be a separate article; see AC/DC for example. This is not the first suggestion to move the reference list to a subpage, but it just won't work. --— Gadget850 (Ed) talk 01:09, 24 December 2012 (UTC)[reply]

Different backround color

Hello Village Pump Technical- I am writing to see what can be done regarding the white colored backround that is everpresent on Wikipedia. For many of us out here in cyberland we have extreme photosensitivity and this white backround quite literally feels like being stabbed in the eyes over and over. Is there any setting or preference that can be turned on, modified, changed, etc that would allow for the changing of the backround color? Thanks so much. A loyal reader. — Preceding unsigned comment added by 24.61.9.111 (talk) 00:32, 24 December 2012 (UTC)[reply]

if you have some sensitivity that makes the regular wikipedia unpleasant, you could register, and then edit your own "vector.css" page (Special:Mypage/vector.css). the would only affect the way wikipedia looks for you when you are logged in - whenever reading articles without logging in you will still see it like everyone else.
here is in example of css that would make wikipedia appear with disgusting brownish-oink or pinkish-brown background. you can play with the colors until you find something which sooth both your sensitivity and the readability of different elements (regular text, links, redlinks etc.):
body {
background-color: rgb(157, 137, 110); 
}

.catlinks,
div.vectorTabs li.selected, div.vectorTabs li.selected a, div.vectorTabs li.selected a:visited,
div.vectorTabs ul li,
div#mw-head-base,
div#mw-head,
div#mw-page-base,
div#content { background-color: transparent; }
peace - קיפודנחש (aka kipod) (talk) 02:17, 24 December 2012 (UTC)[reply]

I honestly have no idea what you mean by vector, registering, whatever. Is it supposed to be that hard?

Missing name

I edited Wikipedia:WikiCup/History/2012/Contestants to keep it a nice document like the previous year's entry... but now my own name is missing (I should be among the Round 3 eliminations, and clicking on "Edit" shows the template's still there). Any guesses on why? igordebraga 01:47, 24 December 2012 (UTC)[reply]

Fixed in [8]. The username must match a parameter name in Wikipedia:WikiCup/Participant3 where the parameter is called Igordebraga with upper case 'I'. PrimeHunter (talk) 02:46, 24 December 2012 (UTC)[reply]