This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
This will add a new entry, called "Personal script" to the p-cactions menu (inverted triangle to the left of the search). You can type there a wikipedia page, or a URL (if you do not define the protocol, i.e. the URL begins with //, it will use the current protocol). if the page name ends with ".css" it assumes it's a stylesheet, otherwise it assumes it's a javascript file.
The script will remember your choice (using cookies, so this is "per machine", not "per user"), and retain history of last 10 scripts you loaded.
When developing, often times I use it to point to "//localhost/<MY_WIKI_DEVELOPMENT_FOLDER>/script_under_developnet.js" (of course, one has to run httpd server on one's computer for this to work).
I find it especially handy when trying to find out problems other users were having: instead of editing my own common.js, I just point my "personal script" to "User:Username/common.js" to see what bugs them.
Wait, you import arbitrary and potentially malicious js from random editors into your own browser? You are a brave user, or a silly one, depending. 66.127.54.40 (talk) 17:22, 4 December 2012 (UTC)
i am not sure you use words in their intended meaning. i do not "import" scripts from "random" editors. i sometimes _run_ scripts written by others, as does, practically everyone else. when asked to support users, one sometimes need to test what those users run.
as to "brave": no more "brave" than any person who browse the web with javascript enabled. do _you_ know what every script at any site you point your browser to is doing?
Unlike scripts on other websites, scripts on Wikipedia have access to your Wikipedia cookies, and hence can take actions on Wikipedia using your user account (particularly nasty in the case of administrators). The script could also send your login cookies to someone else, allowing them to impersonate you until you logout. To avoid blame for someone else's vandalism, either read the script to check it does nothing malicious before you run it or be sure that you trust the person who wrote the script. – PartTimeGnome(talk | contribs)20:56, 4 December 2012 (UTC)
Back in January, I developed Wikipedia:User script sandbox, which does not require a personal web server for use. It is especially useful for HTTPS users, who do not have to set up mod_ssl, certificates, and the like. The script has already allowed me to avoid many unnecessary wiki page revisions; however, I would appreciate any feedback. PleaseStand (talk) 17:27, 4 December 2012 (UTC)
very cute. i could not figure out how to debug the code in the sandbox, though. using local httpd has some more advantages, like using a decent editor without having to constantly cut/paste to the sandbox. again, i think your sandbox is mighty cute.
I'm making a template (A) that will be used on several other templates (B), which will be used other places (C). How can I make a <noinclude> so that part of A will appear on B but not on C? sorry if my question's not so clear -- ypnypn (talk) 03:23, 5 December 2012 (UTC)
I don't think that technique will work. Could you simply distinguish B from C by checking the namespace or page name? (See Help:Magic words#Variables for details of {{NAMESPACE}} and {{FULLPAGENAME}}.) For example, {{Namespace detect|template=B_text|other=C_text}} produces different results according to the final namespace. — Richardguk (talk) 04:19, 5 December 2012 (UTC)
Why is it that all the graphs and all or almost all of the maps on Wik pages are blurry beyond legibility? Photos are crisp and usable, but I have to click on the graphs to get any use out of them. Since I am in a country where internet connection is slow, this means adding about a minute or doing with-out. Can't this be changed? Kdammers (talk) 05:18, 23 November 2012 (UTC)
Widespread conversion of maps/graphs to PNG: Years ago, there was a massive, rabid, almost tyrannical push or shove to force all maps or lettered graphs into the blurry, fuzzy, hazy, cloudy PNG format which is 5x-8x-20x times slower than the JPEG format. The original JPEG maps or graphs were then rapidly, viciously deleted. The oft-noted reason was for "clarity" of labels in PNG-format images to avoid "image artefacts" in some adjacent-color mismatches, even though the JPEG format tended to sharpen the contrast of dark lines and letters against the background colors. Plus, in cases of questionable labels, then a JPEG image could be quickly expanded to a larger size, while the slow gargantuan PNG-format image took eons of time to slowly enlarge for better readability. And get this: when small JPEGs were changed into cumbersome PNG format, then article pages were switched from mostly text-based data into becoming mostly PNG-based data, far larger than the text data in the page. I must have run hundreds of experiments to confirm that the JPEG images were almost always clearer than PNG-format images when scaled to similar sizes. Meanwhile, GIF-based thumbnails were force-blurred for some months, but eventually returned to clearer thumbnails as in years past. Later, many images were converted into variable-size SVG-format images, which are rendered as blurry, fuzzy, hazy (etc.) PNG-format images, as thumbnails. I guess the rationale has been to always use PNG-format images, just in case a labeled map or graph might use a rare color combination which "bleeds" artefacts into the nearby mismatch colors. However, in practice, most labeled images tend to avoid bleed-prone color edges (such as lime green on tan), so the quick, crisp JPEG format could be used, except for rare color borders. Now, huge JPEGs can also turn blurry when thumbnailed very small, so a reasonable trick has been to excerpt a small-scale closeup (such as downtown map) from a huge multi-megapixel image, and then use that reduced-size closeup to generate the small, clear thumbnail-size images, much clearer than thumbnails based on the huge megapixel JPEGs. Another tactic is to thicken the major labels on maps to 3-pixel letters (or "2.5 pixels" using 1-gray + 2-black pixels in lines). Hence, when 3-pixel letters are thumbnailed as JPEG format, then the sharpening of labels is improved so even small thumbnails have readable labels. It is amazing how simple to create readable maps in lightning-fast JPEGs which are still readable as tiny thumbnails, and quickly enlarged to confirm small labels. Unfortunately, the genocide of JPEG-based maps, now deleted into mass graves, has made the restoration of readable maps a very difficult problem. -Wikid77 (talk) 06:26, 23 November 2012 (UTC)
The conversion to slow, blurry PNG-format images has been a colossal failure, which thwarted real improvements to map or graph design; so now we need some real solutions. -Wikid7703:54, 25 November 2012 (UTC)
These days, when I see a post outside of a WP:!VOTE which begins with a bullet and some boldface, I expect that sooner or later I'll apply WP:TLDR. So, whether it's misinformed or not I couldn't say. I do know this: if you convert an image which is in a lossy format (like JPEG) to any other format (whether lossy or not) there's no way that you can recover the lost information and so sharpen up the image. --Redrose64 (talk) 19:51, 23 November 2012 (UTC)
I do not believe you. You mean, you really do not look at the editors name before you stop reading? And hey, you still do know this. How brave, and what a community you keep up. -DePiep (talk) 00:00, 5 December 2012 (UTC)
Of course I look at the editor's name, it's right at the top of the diff. Only one editor that I've encountered uses this peculiar way of formatting a post when replying to an ongoing thread. It's just so "hey, I've used a bullet and some boldface so that my text appears to be more important than everybody elses". I don't have to read the whole post to get the idea: and the idea I get is that there seems to be some "magic formula" for improving an image by converting it from a PNG to a JPEG. Now, I might have got entirely the wrong idea there, but I simply cannot believe that converting a non-photographic image (such as a graph) to a lossy format (which JPEG is, and always has been) will preserve all the detail, let alone improve existing detail. It's just not possible. --Redrose64 (talk) 07:41, 5 December 2012 (UTC)
@Kdammers: Can you cite some examples? What is your approximate screen size (in inches) and resolution (in pixels)? —[AlanM1(talk)]—08:37, 23 November 2012 (UTC)
I have no problems whatsoever. I do believe that the quality of the default PNG handler in Internet Explorer is rather poor. It would be useful to know if that is perhaps the browser that you are using. —TheDJ (talk • contribs) 09:46, 23 November 2012 (UTC)
Have you changed your browser zoom from the default of 100%? (It's easy to do this accidentally and some browsers remember the setting.) That makes text larger but also shows images at a scaled up size. (In most browsers, Ctrl-0 resets the zoom: control and zero.)
Brion Vibber recently implemented a nice enhancement for tablet browsers (where high-DPI and user rescaling are ubiquitous) so that scaled pages display properly rescaled images. But this does not seem to work for old-style zooming on desktop browsers, so a scaling factor greater than 100% there would result in blurry or jagged images.
I am using Firefox. I re-set to 100%, and the images seem to be sharper, but the texts are so small that they are not readable. Kdammers (talk) 10:58, 23 November 2012 (UTC)
By "texts", do you mean the article text or the text within the images? Assuming you mean the latter:
Zooming is a bad way to see small image text (as you've discovered!). There are two better ways, depending on how the image is specified:
If an image is a thumbnail and its size is unspecified in the wikitext (as with the images in List of countries by population), Wikipedia uses a size based on your user Appearance preferences (see "Thumbnail size" under Special:Preferences#mw-prefsection-rendering; I think 220 pixels is the standard width if editors have not changed their user preferences). So you could increase that to something larger.
However, some images (such as most of those in Gini coefficient) have a particular size specified in the Wikitext (it will say something like [[File:...|123px|...]] to specify the width, [[File:...|x456px|...]] to specify the height, or [[File:...|123x456px|...]] to specify a cap for both, as detailed at Wikipedia:Extended image syntax). If you think the images should be made larger for everyone, simply edit the article text to use a larger number. But avoid widths of more than about 500px, because the images will be too wide for readers with narrow screens.
Thank You for Your help. I meant the text (e.g., legends) with-in the picture.1) I tried Your suggestion for thumbnails. I set Thumbnail to max, and now the image is blurry but the legend is still minuscule and not readable. 2) I am chary of unilaterally make a blanket size change with-out feedback from other users, in case the problem lies just with me or my set-up. — Preceding unsigned comment added by Kdammers (talk • contribs) 02:04, 24 November 2012 (UTC)
To enlarge an image, don't zoom the browser, click on the image. For the page List of countries by population, clicking the first image takes you here. Click on the image again to get it as large as your browser will allow; if your mouse pointer then changes to a shape like , you can click again to get the maximum enlargement. --Redrose64 (talk) 10:38, 24 November 2012 (UTC)
Assuming that your zoom is now reset to 100%, I think the remaining problem is simply that most of the graphs in the pages you mentioned have been designed for displaying at relatively large sizes (hence with relatively small legend text):
SVG format images are better suited to scaling than PNG and GIF, but I don't think that's the main problem in the above cases because the unscaled originals are relatively large.
The article editors probably wanted to avoid cluttering the article with many large images, because readers can always click on the images to see much larger versions on the individual file description pages.
Some of the images would have been better if they had been created with larger legend text (a design issue). But most of the images have detailed graphic content that is inherently unsuited to rendering at small sizes, so the only sensible way to view them is to display them at large sizes in the article or to rely on readers clicking through to the large previews on the file description pages.
In other words, might the remaining problem be that the image text is too small rather than too blurry?
Autosized images but need larger legends: I have modified article "Gini coefficient" to now wp:autosize the images as "upright=2.20" or "upright=1.40" as scaled 2.20-1.40x times larger than each user's default-image-size setting in Special:Preferences. However, the world-map legend box is still too small to read easily. I am uploading a less-glaring GIF variation of File:GINIretouchedcolors.png with a larger legend box, with the legend border as 3-pixel width, for thumbnail comparisons. The Commons Upload Wizard is very slow, so it will take a long time to upload. More later. -Wikid77 (talk) 16:38, 24 November 2012 (UTC)
As shown in the map images at right, I have uploaded a fast GIF version of the GINI world-map image (3x faster, thinner than the PNG-format image), which now has a larger legend box and bigger lettering enlarged towards 3-pixel letters. However, at typical 220-pixel thumbnail size, the labels were still blurry, so I think that major lettering should use 4-pixel lines to be legible in a typical thumbnail. I worked on map lettering some years ago, so I am just now remembering the issues about using large labels. Anyway, after all these years, I clearly see, rather than the prior push to tediously convert all these images to PNG-format (or SVG) data, there should have been a strong recommendation to use larger labels and lettering in map or graph images. -Wikid77 (talk) 23:52, 24 November 2012 (UTC)
Expanding letters to 5-pixel width: For the major map label ("GINI Coefficient"), the letter size was increased to use 5-pixel lines in labels with letters separated by 5-pixel gaps, and even that size is barely legible on smaller thumbnails (plan 6-pixel lines/gaps). The effect is that words must be displayed in over-size letters to be legible in thumbnail proportions. Hence, in some cases, the major labels should be superimposed as larger text onto the map, or have a larger-font, closeup image version, or else repeat some of the legend labels inside the caption area of an image. A single map cannot have both large-size text and tiny details. Due to cramped space, I changed the GINI-map legend to 1-column (was 2) and narrowed the map 5% to enlarge labels 5.3% (100/95). -Wikid77 03:54/08:45, 25 November 2012 (UTC)
Summary of results: We acknowledge that the (thousands of) map/chart labels are blurry in thumbnails, and should often have been redrawn larger, years ago (as a design choice). Meanwhile, zooming the browser is not much help, but a user should right-click blurry charts to enlarge in background while reading an article, then later view each enlarged image-tab to see both the larger labels as well as more chart/map details. Although some large PNG-format maps might grind for almost a minute, many PNG charts/maps will right-click within 25 seconds on a slow-dialup line. Very slow maps could have large-label closeups stored in quick JPEG format (for rapid right-click). When tiny thumbnail maps are spotted in articles, then perhaps edit to wp:autosize charts/maps as 40% larger by "upright=1.40" (adding "frameless" when not "thumb" style images). When even 40% (or 50%) larger does not help, then repeat/recap the tiny labels inside the caption of the map/chart (see new captions in "List of countries by population"). In an ideal world, all over-wide charts would be narrowed 5-20% to show labels as 5.3%-25% larger. Also, all full-screen maps/charts would show major labels in 4-pixel (or 6) letter lines (4-pixel gaps) for legible thumbnails, but beware that very-large labels overpower an enlarged map, so also consider the large-label closeups as 2nd images, or use Template:Superimpose to show large labels (live) over modest labels as needed for the topic showing the map/chart. Large labels are often the enemy which overwrites finely detailed charts, so the choice requires editorial judgment, not unlike planning map use in other-language Wikipedias. Long-term, I think there were also plans to quicken the rendering of PNG images which were displaying in excessive high-precision format, as 3x slower than GIF image thumbnails. Anyway, I think we have enough techniques now to solve many of these blurry graphs. -Wikid77 (talk) 08:45, 25 November 2012 (UTC)
"We acknowledge" - you mean, you acknowledge. I can't see anyone else here concurring with your tl;dr diatribes. — Hex(❝?!❞)16:18, 25 November 2012 (UTC)
Thanks for noting the lengthy topics. Well, actually, I was concurring with several other opinions above (across the whole thread), but I do understand your point about all the details, because computer graphics is a highly complex subject, and perhaps there should be a separate Village Pump section just for maps, graphs and photographic-display problems. For example, we have not even mentioned mouse-over enlargement or quick map-legend images, nor legends in alt-text, nor pre-loading of enlarged maps as hidden images to allow instant right-click to show pre-loaded images. Ironically, what I wrote above is less than half of what should be noted about the problems with blurry graphs, to also include guidelines for graph line segments, map symbols, histograms, bar graphs, and standardized templates to ensure larger, legible labels. Anyway, thanks for raising the issue, because I would not want people to think that the segments I wrote above could cover even half of the techniques which we should consider. This is a multi-year problem, with many facets. -Wikid7723:00, 25 November 2012 (UTC)
I didn't make any point like that at all. Are you replying to me, or to yourself? Out of all your verbiage above, the only thing that has emerged that anyone else has even remotely concurred with is that images displayed at a small size in articles could have larger text. Well excuse me, but no shit, Sherlock. — Hex(❝?!❞)13:46, 30 November 2012 (UTC)
You are too kind in claiming I had quickly devised all the above techniques by myself, to make labels more legible, with no help from others in the discussion, as if I were a solitary genius who could think so fast, while others merely advised "have larger text". No instead, upon re-reading the above, it was the others who first noted how browser-zoom is not much help, and right-clicking images not only expands for larger labels but also enlarges crucial map details as well. Plus, others had noted the use of small labels was a "design choice" which emphasized that entire maps should be relabeled, rather than expect Wikipedia to auto-enlarge labels for better clarity. Anyway, I thank you for the compliment, but others here are also very intelligent, whether "Sherlocks" or not. -Wikid77 (talk) 20:33, 2 December 2012 (UTC)
"Interaction" drop down menu in Wikipedia tool box
The "Interaction" drop down menu on the left hand tool box section keeps closing up. Every time I go to a new page, I have to open it up. This just started happening today. 216.93.234.239 (talk) 00:22, 1 December 2012 (UTC)
The box is supposed to remember its latest state and begin there on a new page. It works for me. What is your browser and version? Did something with your browser change when it started? PrimeHunter (talk) 05:32, 4 December 2012 (UTC)
Firefox 17.0, Windows 8. It's a new laptop that I've only been using for a week, but I swear the old way of things was like that when I first came here with the new computer. 216.93.234.239 (talk) 05:54, 4 December 2012 (UTC)
Maybe this isn't the right forum for this, but I just have to say that I love the new "Preview page with this template" feature. No more fiddling around with template sandboxes - now we can preview the effects of templates on the fly. A big thank you to the developers! — Mr. Stradivarius(have a chat)12:48, 4 December 2012 (UTC)
Also consider dangers of bypassing sandbox versions: I agree that skipping some template sandboxes can be convenient. However, in many cases, having an entire testbed of "/sandbox2" versions should be used to compare before-and-after results and maintain a level of sanity, across numerous subtemplates, rather than all being changed on the fly. In fact, some editors have scolded others when throwing new changes live into the system, without first carefully testing in sandbox versions, and leaving sandbox versions non-updated, as several revisions behind the live versions of templates. In general, "If you don't have time to test it fully, then 10x times as many users don't have time to deal with new bugs". Also remember: typically 1 in 10 tested updates will generate unforseen new bugs/problems. What is probably more valuable is to also have a "/old" version, of perhaps several revisions prior, to compare if newer revisions, of a template, introduced an insideous bug not there months ago. Just be very, very careful. -Wikid77 (talk) 18:40, 4 December 2012 (UTC)
Very true - saying "no more fiddling around with template sandboxes" was a bit of an exaggeration, and I hope you'll forgive me for not being as objective as I could have been in my joy at discovering the new feature. :) Sandboxes will still be required for non-obvious changes, of course, and /testcases pages won't be much use without sandboxes. However, I think we will start to see a significant reduction in template sandbox edit histories consisting of "test", "more testing", "even more testing" (demonstrated very neatly by myself here), and that can only be a good thing, in my opinion. — Mr. Stradivarius(have a chat)07:14, 5 December 2012 (UTC)
Page descender cropped
I use the Vector skin and have Preferences → Pending changes → Add page and user options to drop-down menus on the toolbar enabled. The Page tab is now missing the descender on the g. And yes, I have purged and bypassed. I expect there was some sort of CSS tweak in the update. --— Gadget850 (Ed)talk19:20, 4 December 2012 (UTC)
There were changes in the skin HTML, changing the invisible H5 headers to H3, which in turn forced some CSS to be rewritten. My guess is Haza-w (the script maintainer) has yet to update to script to reflect this. — Edokter (talk) — 21:30, 4 December 2012 (UTC)
I've tried purging this page yesterday and today after I created the subcategory yesterday. However, there is no avail. How will the category be updated? --George Ho (talk) 01:28, 5 December 2012 (UTC)
Either 1) null edits to the file pages, or 2) special purges of the file pages through the API with a nearly-undocumented parameter. I did the former to one file to confirm the issue and the latter to the rest. jcgoble3 (talk) 01:54, 5 December 2012 (UTC)
Hi guys! I would like to suggest a different way of searching and targeting of the information (when the user is searching for information on a topic but nothing specific)
Why not have a tool where you can scroll and select Years or period of time / then domain (litterature, music, art, history, science etc) / then geographic location (as narrow as a town and as wide as the world depending on what you want)?
The system would then pull all the corresponding information.
of course this would require that pages be given a category, a period and a location when applicable and theres a few technical complications to work on, but nothing too out of reach given that the most important for such tool to be successful is the content and it's all already here! :)
Initially I proposed to make this search option available on monthly membership, so that wikipedia could make some money, the current search would remain free and as it is, the other one would cover wikipedia's costs... but well, wikipedia's all about being all free isn't it?
You can add &debug=true (or ?debug=true, if there is no existing query string argument) to the end of any page's URL. This will cause the unminified CSS of each module to be loaded in a separate request, so you can see where the problematic CSS is actually located. See mw:ResourceLoader/Features#Debug mode. PleaseStand (talk) 16:18, 5 December 2012 (UTC)
Every Autoconfirmed user is a patroller now? Is it "by design"?
As can be seen in Special:UserGroupRights, Autoconfirmed users can now mark other users' edits as "patrolled".
This seems to work a bit strange: for instance, I can only see the "unpatrolled" mark in Special:RecentChanges for new pages, but not for new unpatrolled edits in existing pages.
What's more, Autoconfirmed users are not even "autopatrolled", so we can mark our own edits as "patrolled", but we need to do it manually.
This seems to be pretty recent, as far as I know. Is this intentional? Can someone point me to the discussion that led to this change? Or maybe it was there all along and I just did not notice? What is the rationale behind displaying the "unpatrolled" mark for new pages only?
It's always been like that. The logic of unpatrolled being for new pages only is that it's designed for new pages only. Patrol in that context refers to New Page Patrol. And I don't think you're supposed to be marking your own articles as patrolled anyway, though I doubt anyone particularly cares much; that's why the "autopatrolled" right exists exists separately. (Actually, upon checking, I don't think the software allows you to patrol pages you created yourself, so it's kind of a moot point.) Writ Keeper⚇♔16:27, 5 December 2012 (UTC)
Thanks. This is confusing - I never knew there was any distinction between "patrol" and "new page patrol". Specifically, I can't find different permissions for the two. As to "it was always like this": this is also interesting. this is not the case for most other languages wiki (i.e., Autoconfirmed users do not usually have the "patrol" right). Peace - קיפודנחש (aka kipod) (talk) 16:55, 5 December 2012 (UTC)
There isn't a "distinction" per se; new page patrolling isn't a permission, it's just a loosely-defined activity that some editors perform, using either Special:NewPages or the new Special:NewPagesFeed pages to look at newly-created articles and check them for problems. The "patrolled" status that you're seeing on pages is meant to assist in this, as pages that are patrolled appear differently in the lists; thus, when an editor has already checked an article for problems, they mark it as patrolled, and then later editors know that they don't have to re-check that page, avoiding duplicate efforts. Any autoconfirmed user has the capability to flag new articles as "patrolled", which means that any autoconfirmed account can participate in new page patrolling. A user with "autopatrolled" has any article they create automatically marked as patrolled; the permission is meant to be given to those who can be trusted to create good articles and so don't need another editor checking it for basic problems. Does that make more sense? Writ Keeper⚇♔17:04, 5 December 2012 (UTC)
In hewiki the "patrolled" flag is used extensively. We have a whole user group called "patrollers" who can mark edits as "Patrolled". This group is somewhat similar to the "Rollbackers" group in enwiki, i.e., users in this group can also rollback. The "patrolled" flag is not just for new pages, it is for any edit by a user who is not "autopatrolled", But I guess, in enwiki, users who are not admins can only see (and mark) this flag for new pages and not for every edit. Peace - קיפודנחש (aka kipod) (talk) 17:22, 5 December 2012 (UTC)
(added after collision): Ok, I think I found it: there are two distinct flags that can be used in LocalSettings.php:
/** Use RC Patrolling to check for vandalism */$wgUseRCPatrol=true;/** Use new page patrolling to check new pages on Special:Newpages */$wgUseNPPatrol=true;
I guess enwiki only enables $wgUseNPPatrol, while hewiki enables $wgUseRCPatrol, which is the source of my confusion....
I now have giant text at the top of my page which has random words like "Namespaces" "Personal tools" "Views" "Actions" and "Search" at the top of every page. Using Chrome Version 23.0.1271.95 m on Windows 7. Can we go back to this not happening and implement changes to the user interface after (rather than before) they are tested? Thanks! --Jayron3219:10, 3 December 2012 (UTC)
Based on my interpretation of this. All the pages need to either be edited or purged. I used ?action=purge to purge the main page and the problem appeared fixed. Can we create some type of botlike thing to go to all of the URL's on Wikipedia and purge them? RyanVesey19:18, 3 December 2012 (UTC)
I didn't think so either but the timing matches. Do you have the courage to repeat my edit and see what happens? I'm not touching that again. Expect a trout slapping if you actually try it and it destroys Wikipedia. PrimeHunter (talk) 19:29, 3 December 2012 (UTC)
https://wikitech.wikimedia.org/view/Server_admin_log says 1.21wmf5 was deployed to the English Wikipedia 19:05 today. My edit was 19:05 and the interface broke right after. Maybe I'm innocent. Or maybe it was a combination where my edit was the first interface edit to cause something to be reprocessed by 1.21wmf5. 1.21wmf5 has apparently caused similar issues at other wikis where it was deployed 28 November. PrimeHunter (talk) 20:15, 3 December 2012 (UTC)
(edit conflict)(more than I can count)I'm having the same problems as Jayron32 with the same specs, using modern though. It seems to be inconsistent, with pages occasionally displaying correctly at the top but mostly not. I also restored a pertinent comment from Steven (WMF) that Drmies ECed into oblivion. —Torchiesttalkedits19:22, 3 December 2012 (UTC)
Moving up from the thread below. That Shift/Reload has worked for me - and other newly opened pages are coming up clean too. Must remember that one. Peridon (talk) 19:26, 3 December 2012 (UTC)
I have the heading on the left side larger, and random headings across the top. Also the Article title is behind the Article and Talk tabs. This is apparent on first visits to page. Not sure clearing browser cache is the solution as it is happening with pages I have not visited before. Using Chrome 23.0.1271.95 on Windows 7 Pro SP1. --Stewart(talk | edits)19:29, 3 December 2012 (UTC)
Just FYI: I think it will help because it's the sitewide CSS and/or JS pages that were borked and need to be cleared, not any article page in particular. Just my hypothesis, though. Writ Keeper⚇♔19:35, 3 December 2012 (UTC)
I should add that although Shift/reload in Firefox has eliminated the garbage, not all pages look normal. For example, my watchlist page looks fine. However, a revision history page has some parts of the print missing in the upper right-hand corner (page history, etc.). If I recall correctly, I don't use the normal settings. I think I use some kind of script that moves certain actions from the left sidebar to the the spot that's not quite right.--Bbb23 (talk) 19:41, 3 December 2012 (UTC)
Above the link to the "Main page" on the left hand side I realised it now says "Navigation", but the tabs underneath, such as "Toolbox", no longer collapse/expand. So I suspect something is still broken. And despite clearing the cache, the problem still comes back for me on Firefox. Jared Preston (talk) 19:43, 3 December 2012 (UTC)
Cleared my cache, and it worked to fix the problem. Thanks for the tips. However, I am having the problem that the collapse function no longer works on the leftside menu, as noted above. --Jayron3219:46, 3 December 2012 (UTC)
Same problem. I have big, bold, "Views" and "Personal tools" at the top, and my buttons are hidden. I'm in Firefox and purging the cache did not work. Glad I'm not alone in this...well, kinda. ~Adjwilley (talk)20:16, 3 December 2012 (UTC)
Figured out my problem, cache still wasn't quite cleared. Now all pages working properly. If at first you don't succeed, purge, purge again. Sailsbystars (talk) 20:43, 3 December 2012 (UTC)
I am using Firefox 17.0.1. I have cleared my entire cache. The Main page is an example of it not being back to normal. In the upper right-hand corner, to the left of the search box, I have "Page" with a drop arrow and "TW" with a drop arrow. I can see only the top half of those two words, whereas before I could see all of them.--Bbb23 (talk) 21:47, 3 December 2012 (UTC)
I cleared my cache a few hours ago and have been fine since then. Except... didn't the dropdown arrow for Twinkle used to be next to the "TW", not above it and to the right? Just odd for that to be the only glitch I'm getting. Anyone else? — Francophonie&Androphilie(Je vous invite à me parler)21:53, 3 December 2012 (UTC)
Its doing the same thing on my iPad. How can I clear the cache on my iPad? It's really hard to edit with everything on the page.--Astros4477 (talk) 22:26, 3 December 2012 (UTC)
Purging my cache has helped for me. Chrome; Settings -> Show advanced settings -> Clear browsing data -> Empty the cache. However, it's not appropriate to expect every reader to browse here and follow the instructions to purge their cache. Presumably the underlying problem is still going to be fixed sooner or later? bobrayner (talk) 22:43, 3 December 2012 (UTC)
Some temporary workarounds - I have found (using chrome and 'modern' UI) that the user/talk/prefs/watchlist line and the article/talk/edit/history line of the interface are both just gone. Purging cache, full refresh, etc did not change anything. However, using tab and shift-tab to navigate between links on the page causes them to reappear as normal when you tab to a link on the line. Also, my watchlist, which uses the 'sort by namespace' javascript advertised on the js help page, doesn't suffer from this problem, nor the messed up sidebar font sizes. All other pages seem to, so maybe something that script does is incidentally fixing the problem. And if both of those fail....firefox seems completely fine. --Qetuth (talk) 22:46, 3 December 2012 (UTC)
I've purged my cache, switched skins temporarily, restarted my browser...every normal page is fine now, but all special pages (watchlist, contribs, etc) still have broken menus. Any suggestions? I'm using Modern in Firefox. Nikkimaria (talk) 04:05, 4 December 2012 (UTC)
Click the top left orange Firefox button. Then "History->Clear recent history" Then check just the "cache" box, and make sure "Time range to clear" is "Everything". That's what fixed it for me. —Torchiesttalkedits04:45, 4 December 2012 (UTC)
And on older versions of Firefox, you would go Tools, Options, Privacy, Clear your recent history, then check the cache box and choose Everything as before. Stifle (talk) 10:06, 4 December 2012 (UTC)
My manifestation of this (I suppose) is that columns previously set in em no longer worked, on different machines with different browsers. I don't know if that was fixed, but I changed them to px anyway (but I hate that). Also, the width of infobox islands increased 50% or more.
Today's variation - the sequencing of footnotes {{efn}} has changed from lower-alpha to upper-alpha. No problem there I suppose, except I also had a <ref> with a group name of lower-alpha which was supposed to slip into the sequence. Why? Because it includes a table which doesn't parse properly in efn. Or maybe I should sprinkle a few {{!}} in. John of Cromer in China (talk) mytime= Wed 00:36, wikitime= 16:36, 4 December 2012 (UTC)
Sorry, my bad. Just a (double-) coincidence that highly-visible, protected pages were changed on a personal whim at the same time! Is bugzilla the place to report issues like that and my earlier problem with tables, or do I go through a human intermediary? John of Cromer in China (talk) mytime= Wed 08:30, wikitime= 00:30, 5 December 2012 (UTC)
Bugzilla is really for problems concerning the MediaWiki software. Any issues that are the result of changes to one or more pages (including templates) within Wikipedia itself are outside the scope of Bugzilla, since if we have the ability to break it, we also have the ability to fix it. If you can determine which templates have been altered (and I get the impression that you identified {{efn}} as having changed), you can raise a thread at the template's talk page; if you can also determine which specific edit(s) caused the changed behaviour, you can also post a message to the relevant editor's talk page directing them to your thread. In this case, there had been only two edits to {{efn}} in the five months leading up to your post, and the sum of those edits was to change two instances of |group=lower-alpha to |group=upper-alpha. Your original post does mention "changed from lower-alpha to upper-alpha", so I'm pretty sure that your problem is a direct consequence of the two edits to {{efn}}.
WP:VPT is a good place to come for technical issues, it has a lot of watchers with varied knowledge and specialisms. We do sometimes direct people to bugzilla, but only when necessary. If your first action is to raise a bugzilla ticket, it can go months without being answered. As an alternative to VPT, some of the talk pages associated with Help pages permit questions to be asked; Help talk:Table is one such. --Redrose64 (talk) 08:16, 5 December 2012 (UTC)
I am no longer having the problem on regular pages but as stated above, I'm still having the problems on my Special pages. How do I fix that?--Astros4477 (talk) 20:22, 4 December 2012 (UTC)
I'm getting it too. It's not stopping me deleting things, but it's a damn nuisance finding the tag when the buttons are behind the article title. I'm in Firefox 15 with XP. This page (except in 'edit view') is fine, but the type size in the sidebar has enlarged on ordinary pages. Peridon (talk) 19:18, 3 December 2012 (UTC)
Have you tried clearing the browser cache, though? Purging is a server thing, IIRC, and I think this is a client browser thing. Writ Keeper⚇♔19:23, 3 December 2012 (UTC)
After purging my local browser cache since the begining of time. GoogleChrome WinXP. Why the hell did they let something so broken ship, and without any sort of notice? Hasteur (talk) 20:29, 3 December 2012 (UTC)
It became unusable for me in Firefox 17/Linux today, although it still looked normal in SeaMonkey 2.14. Clearing the cache by going to Edit -> Preferences -> Network -> Cached Web Content and clicking the Clear Now button and reloading the Wikipedia page fixed the messed up layout problem. — QuicksilverT@02:11, 4 December 2012 (UTC)
Layout issue
I was minding my own business (and possibly hit a button), when my layout turned to this. It's not my computer cause when I log out it goes away, and it occurs on my iPhone as well. Please help. Grammarxxx(What'd I do this time?)23:47, 3 December 2012 (UTC)
I'm also still seeing this, depite having refreshed, purged and generally done everything short of colonically irrigating my browser cache. It only seems to affect Firefox, I'm not seeing it in any other browser. Yunshui雲水08:38, 4 December 2012 (UTC)
It did it for me, a few minutes ago. It seems to be fixed now. I did change some preferences, so it might be a side effect of one of the gadgets. — Arthur Rubin(talk)08:51, 4 December 2012 (UTC)
It's now gone for me, after I completely deleted my cache a second time. I'm assuming something didn't work properly last time I did this. Yunshui雲水08:55, 4 December 2012 (UTC)
I just purged (again), and when I refreshed the problem was still there. It is on and off, though, and only seems to occur every other time I refresh a page. --Saddhiyama (talk) 23:22, 4 December 2012 (UTC)
I am hoping that whoever changed it for whatever reason (I don't think anyone knows), is currently at work fixing this issue, because it is beginning to be rather annoying. --Saddhiyama (talk) 01:00, 5 December 2012 (UTC)
Possible Solution: Try clearing everything. Not just the cache, but cookies, data, history, Internet files it stored, everything that the browser collects while you browse. Make it as if the browser were browsing for the first time ever. It cleared this up on my end it for you guys too.—cyberpowerOnlineMerry Christmas14:08, 5 December 2012 (UTC)
Just delete those cookies that are about *.wikipedia.org and related pages. For Firefox there is for example an extension called "Form History Control" so you don't lose all of your cookies. --Malyacko (talk) 18:27, 5 December 2012 (UTC)
Another recommendation is to load the website and attaching "?debug=true" to the web address. According to some users on the Polish Wikipedia this helps. --Malyacko (talk) 11:57, 6 December 2012 (UTC)
Counting template
Is there a template that works in a similar manner to bare external links (i.e. [3], [4], [5]), in other words one that outputs the number of times it has appeared on a given page? This would be particularly useful for automatic numbering of long, frequently updated tables (such as List of countries by population). mgiganteus1 (talk) 19:31, 3 December 2012 (UTC)
Auto-numbering templates have been begun: There are at least 2 templates which count or "auto-number" their parameters:
Template:Autocol - quickly formats a list to have auto-numbered entries (or asterisk-bullets), as columnized into "ncols=n" columns across the page.
Template:Autonumbered_list - highly complex (5-second slow) template to auto-number the rows in a table (max: 50 rows of 5 cells), also wrapped into multiple columns across the page.
I recently wrote the quick Template:Autocol to auto-wrap, and auto-number multiple columns in a lightning-fast manner on any browser, as 1 item per line. Slower Template:Autocol_big allows 65-140 items in an autonumbered table. Now, the extremely complex Template:Autonumbered_list was written way back in 2009, to miraculously number up to 50 rows in a table of up to 5 row cells, which is then wrapped as multiple columns across the page (and get this: it works!). It is so complex, I had to struggle to rewrite it to avoid "wp:Exceeded template limits". However, it is a good example of the future of a table where all rows would be auto-renumbered when any rows are added/removed (likely to be rewritten much faster with a Lua module). However, using {autocol} today is simple and fast:
New Template:Autotable5_big can auto-number up to 280 rows: After months of discussions, I have created Template:Autotable5_big to quickly format a table with an auto-numbered counter in column 1, plus 5 other columns (or set to blank entries for fewer columns). It is relatively fast, formatting up to 280 rows (of 5 other columns) in 0.6-2.0 seconds. It took months of analysis to realize that hard-coding a rigid set of 280 rows (skipping blank rows), while showing 1-1400 data parameters was the most-efficient method, whereas dynamic numbering of row cells would likely have run 20-40 seconds to format a similar auto-numbered table of 280 rows, rather than 1-2 seconds. It is currently so fast that not much speed would be gained by using an equivalent Lua module. However, after trying more examples, I plan to create a smaller Template:Autotable5 (not "big") to autonumber just 1-60 rows within 1/4 (quarter) second. -Wikid77 (talk) 18:17, 4 December 2012 (UTC)
Implement table coding that will automatically close a table at a section break?
I have no love for any of the table coding, but would it be possible to add in something to the display that would automatically "close" a table at a section break so that we dont end up with messes
like this? -- TRPoD aka The Red Pen of Doom18:19, 4 December 2012 (UTC)
Under HTML, any table that is not explicitly closed extends to the end of the document. The ==Section== syntax doesn't generate any "section break" recognised by HTML, but a heading. Headings are valid within tables; here is one such use. --Redrose64 (talk) 18:35, 4 December 2012 (UTC)
Perhaps we can write a quick Lua-based table-sanity checker template: Because the speed of string searches is so fast in Lua-based templates, I think we can have live syntax-checker templates, in live articles, to "instantly" check for unclosed tables or mismatched "{{{ }}}" and issue specific warning messages, depending on levels of ignore-this-case parameter settings. Remember, templates are only executed when a page is reformatted, and vast numbers of readers view a cache-copy of an article, so an extra split-second check for invalid markup would be a quick, pleasant relief in many cases. Plus some cases are so "obviously wrong" (such as mismatched "{{{ }}}"), and that means Lua-based syntax checkers could be the extra assistance that is needed to make complex markup more bearable. Also, a syntax checker could help deter editors who "cobble-together" scrambled markup which operates by convoluted bug-dependent quirks, where when modified in rational ways, the cobbled markup would no longer trigger the bugs on which it depended. Anyway, we might detect unclosed tables by checking for standard token "|}" or "</table>" or common templates such as "{{col-end}}" or similar. This is a topic which, once we try, we might find that "94%" of unclosed tables or mismatched "{{{ }}}" are easily detected for warnings. -Wikid77 (talk) 06:16, 5 December 2012 (UTC)
in lieu of getting table coding that is actually usable by general editors, or getting rid of editors' obsession with tablizing everything, I am in favor of anything that would make the current table coding better. -- TRPoD aka The Red Pen of Doom12:54, 5 December 2012 (UTC)
mediawikiwiki:VisualEditor probably counts as actually usable. If those are the issues you see, then I do not see how either problem is fixed by automatically closing the table. Fixing the editor habits or simply fixing the pages that are problematic fixes the problem. You can only influence the former by doing the latter, unless an editor already has knowledge of html/tabling. --Izno (talk) 17:26, 5 December 2012 (UTC)
Unclosed tables are a bug/feature, not always bad: Tables cannot be forced as always closed because it is a useful feature to leave them unclosed. We have numerous templates which have been written as unclosed tables, to allow templates to format special, partial table sections. For example, new Template:Autotable5_big (which auto-numbers rows 1-280) has option "headers=yes" to leave the table unclosed, where the user supplies the top "{|" table open (with column headers), later following the template with end-table token "|}". Another template for partial table rows is Template:Taxobox/taxonomy, which generates infobox rows for over 50 taxon names in the taxonomy of biological organisms. -Wikid77 (talk) 22:18, 6 December 2012 (UTC)
Yes, most of them are missing. Can somebody use something to add a [[]] around all the entries? Dabbing can be checked afterwards.♦ Dr. ☠ Blofeld22:32, 5 December 2012 (UTC)
Taking a very simple approach, I've wikilinked the first occurrence in each column of each place name. As well as applying numerous dabfixes and checking for incorrect links, you'll need to manually edit the links for several dozen townlands which have an alias specified in brackets, changing "[[Fooname (or Barname)]]" to something like "[[Fooname]] (or Barname)" or "Fooname (or [[Barname]])". — Richardguk (talk) 23:58, 5 December 2012 (UTC)
My username has an ampersand in it. This isn't a problem if I'm just using the urlencodemagic word on its own - {{urlencode:Francophonie&Androphilie}} renders as Francophonie%26Androphilie, as it should.
However, {{urlencode:{{BASEPAGENAME}}}}, when executed in my userspace, generates Francophonie%26%2338%3BAndrophilie, which is not read as the same thing in a URL bar. For instance, in my {{User wikipedia/Confirmed}} userbox, if you click on "verify" (which links to the user rights log instead of the conventional Special:Listusers since Confirmed status is removed once you're autoconfirmed), it takes you here, instead of here.
Now, %26%2338%3B translates to &, which is the html code for an ampersand. And seeing as ampersands are integral to HTML, I'm assuming the error has something to do with this - that {{BASEPAGENAME}} outputs something in HTML (in this case "Francophonie&Androphilie), which {{urlencode}} promptly percent-encodes (in this case as Francophonie%26%2338%3BAndrophilie), when really {{urlencode}} should be simply percent-encoding the raw text, as it would normally, without {{BASEPAGENAME}} thrown into the mix.
This appears to happen in any userbox containing the "verify" button - for instance, the link in my {{User wikipedia/Rollback}} userbox takes you here instead of here - but doesn't normally have any effect, since you still get to the page you want by virtue of the "display users starting at" function. I only stumbled on this because of the aforementioned special case with the Confirmed userbox. But, I suppose, there is also room for error in the other user right userboxes, e.g. if someone were to create an account called "Francophonie&Aardvark," then my "verify" link would actually go to their entry in Special:Listusers.
So can anyone think of a way to fix these templates and any other effected ones, or is this just something we'll have to live with? It's also possible I've missed something incredibly basic here, in which case I apologize for wasting y'all's time.
From the info at mw:Manual:PAGENAMEE encoding, I think {{BASEPAGENAMEE}} would solve this (instead of wrapping {{BASEPAGENAME}} in {{urlencode:}} – note the additional E). But if numerous templates are affected by this glitch, I don't think there is a practicable way to fix them all other than by identifying them one by one and either editing them individually or raising edit requests on the relevant talk page of those that are protected. — Richardguk (talk) 00:49, 6 December 2012 (UTC)
I think you've misunderstood me; the encoding described at mw:Manual:PAGENAMEE encoding applies similarly to BASEPAGENAMEE. So there's no need to use {{PAGENAMEE}}, because {{BASEPAGENAMEE}} directly encodes the name of the base page. — Richardguk (talk) 01:44, 6 December 2012 (UTC)
On that note, when clicking on User contributions on F&A's userpage (in the toolbox), the link uses the raw '&'--therefore terminating at User:Francophonie. Any idea how to fix this? —Theopolisme22:09, 6 December 2012 (UTC)
Interestingly, it works fine in my toolbar, as when I use the toolbox. Toolbar makes some sense, since it's individualized, but the toolbox is a tad surprising, as you'd think it'd have the same source code for every user, regardless of whether they're using it on their own page or not. — Francophonie&Androphilie(Je vous invite à me parler)22:15, 6 December 2012 (UTC)
It's me, not you... Yep, you're exactly correct. I'll fix up the script in question; I think I know the cause of the problem. —Theopolisme22:49, 6 December 2012 (UTC)
I boldly added a username=Francophonie&Androphilie parameter to the {{User wikipedia/Confirmed}} on F&A's userpage, which seemed to solve the problem. ⋘HueSatLum?❢⋙22:58, 6 December 2012 (UTC)
After some testing to make sure I wouldn't get lynched for borking templates used on thousands of pages, I revised the Rollbacker, Reviewer, and Autopatrolled userboxes with the {{BASEPAGENAMEE}} fix last night - no angry mob yet. My rollbacker userbox is working just fine now. I (or someone else) still need to fix the other ones, but it looks like I'm the only one effected by it so far. Still, I have to stick up for the rights of my fellow Ampersandian-Wikipedians, we oft-persecuted few. It's ironic that I forgot to fix {{User wikipedia/Confirmed}}, as I'm currently the only person who actually uses it. (I reworked it a few weeks ago, from a previous, rather unappealing version... if I'm still the only person who links to it in a few months, I'll take it to MfD myself.) — Francophonie&Androphilie(Je vous invite à me parler)23:53, 6 December 2012 (UTC)
Sounds reasonable, so also done. So that your user signature is included in the small text, this template now has auto-signing. You can disable the auto-signing by adding a |sig= parameter with no value. – PartTimeGnome(talk | contribs)01:43, 6 December 2012 (UTC)
How about also building a template identifying editors who spend a minute (sometime less) going from AfD to AfD and voting Delete on every single article nominated for deletion every single day? Ottawahitech (talk) 13:51, 6 December 2012 (UTC)
Hi, the GeoData extension announced here finally went live! So far it's mostly in data collection mode, the only enabled function is to retrieve page coordiantes (example). I've initiated data population with this edit, it should take job queue some time to process all the pages using this template. Pages with coordinate problems are tracked by Category:Pages with malformed coordinate tags, example fix. The next step would be to enable spatial searches (find pages around the given point) once we have the hardware for it. Max Semenik (talk) 15:37, 6 December 2012 (UTC)
I've notice an oddity in the re-generation of articles when a template (or indeed other page) on which they depend is altered. I understand that when a page is 'touched' (edited or purged mostly), the timestamp of the touch is recorded and all pages dependent on it added to a queue to be rebuilt as resources permit.
Recently, I modified Template:Universities in Taiwan, and can see the page_touched value (via the toolserver) for the article is now 2021129230858. On checking, many dependant articles did not reflect the change, even after 48 hours. Manually performing a null edit on a dependent article does cause it to show my change. Looking at the page_touched value of the seemingly un-updated dependents shows them to now have the same value as the edited template - 2021129230858. See [Pages that link to "Category:Universities and colleges in Taiwan" for some example titles.
I suspect there is a race condition causing dependent pages to be re-evaluated before the change they are being updated to include has been fully committed and/or propagated.
While I would normally raise an issue like this with the MediaWiki bods, my own reading of the relevant source shows no obvious problems, and I cannot re-create the problem on an admittedly very basic test-bed. My suspicion is that the race condition is unique to (or more often triggered within) the more complex setup that serves the live Wikipedia - replication within MySQL or Memcached would be likely candidates.
Can anyone here sanity-check my findings and/or point me to an existing discussion of this phenomenon before I bother the nice people at Wikimedia please? - TB (talk) 20:18, 1 December 2012 (UTC)
Why Job queue seems to require 5 days to reformat 2,000 pages: It seems illogical that the job queue would actually be so slow as to require 5 days to reformat 2,000 articles which use a recently-changed template. Formerly, a template could be changed, and over 400 dependent pages would reformat within 1 hour 10 minutes. When Template:Rnd (numeric rounding) was updated on 5 April 2010, then over 306,000 dependent pages were reformatted within 4 hours, leaving only 1,196 as "stuck" pages. Is there a database race condition which prematurely reformats many of those dependent pages as already "touch'ed" (updated), so the reformatting with the new template revision does not occur (unless forced by a null edit)? This problem has persisted since years ago, when I changed a navbox template used in 23 articles about Vienna, and those 23 articles took days, not minutes, to reformat. -Wikid77 (talk) 08:00/08:06, 2 December, revised 06:06, 3 December 2012 (UTC)
Yes, I am aware of the job queue, but can find no flaw in the way it is implemented by either inspection or testing. Variously through Wikipedia's history we have experienced problems with the timely regeneration of dependent pages for a variety of reasons but there has generally been an identifiable issue. This one eludes me. - TB (talk) 08:32, 2 December 2012 (UTC)
Run experiments to test race-condition hypothesis: Because everyone is busy and might not have time to respond here with full explanations of current job-queue logistics, we should meanwhile run experiments to test the distributed-database, race-condition hypothesis. Perhaps update a template used in a few dozen articles, then wait a few hours and "count" (by representative sample) the ratio of done-to-not-done with reformatting. Then after several hours (perhaps 12), edit the same template again with a new change, and according to the race-condition hypothesis, then all dependent articles should be reformatted within a few hours with the prior-revision template (a sample of size 30 would show 0 non-reformatted). Some weeks ago, I was sensing that articles were deliberately non-reformatted (pseudo-touched) to reduce the size of the job queue. If every article containing gobs of navspam navboxes were actually reformatted as expected, perhaps the job queue would be delayed by weeks, rather than days to reformat pages using a shared template. Remember some off-topic or remote-tangent navboxes are spammed into over 25,000 articles, none of which are listed in the mega-spammed navbox. I predicted this artificially-created, navspam resource-hog problem in "wp:Overlink crisis" which has been bitterly denied by some editors; however, there have been many articles with more than a dozen bottom navboxes, most of them remote-tangent navboxes. It is part of a wider problem of wp:Datahoarding in articles, where navboxes are only a part of the problem, such as showing 2 entire climate-table boxes for the same town, as if one climate-table was not close enough for temperatures/precipitation on the other side of a small town. -Wikid7717:27, 2 December 2012 (UTC)
Re-edit refuted race-condition hypothesis as still no reformat: As I suspected, a test to re-edit a template, 16 hours later still failed to trigger quick reformatting with recent revisions of the template. There was no evidence to support the concept that a recent edit, to a shared template, causes the dependent pages to run a race condition and reformat with the prior-revision template (before the new revision is fully saved); no, instead, even when a template has been edited with an obvious change, and then re-edited 16 hours later with another obvious change, neither edit causes any of the dependent pages to reformat within 2 hours, as has been the case in prior years. Rather than trigger an immediate reformat with a prior-revision template, the reformatting is sporadic, where some articles are still not yet reformatted within 28 hours after the initial change to the shared template. I had suspected the race-condition hypothesis, of pages imagined to quickly reformat with prior-revision templates, was incorrect due to the widespread failure of any (repeat: any) articles to reflect recent template edits, even when templates have been re-edited many hours later. The implications are clear: when a recent template edit must be reflected in related pages, then perform the edit many days in advance, or else crank a script that issues a null-edit (no-change edit) on every page which is needed soon. When a template is changed, it might be days before the dependent pages are reformatted, and some pages might require days longer than others in the list to reformat, as in prior years. -Wikid77 (talk) 23:15, 3 December 2012 (UTC)
I agree with these findings - it isn't a race condition, it's a plain old failure to re-evaluate dependent pages. The fault still fails to manifest on a simple test-bed though. Some optimisation feature on the live Wikipedia environment misbehaving perhaps ? - TB (talk) 09:27, 4 December 2012 (UTC)
Seems like king-of-the-hill struggle in queue priority: In my tests of re-changing a shared template, 16 hours apart, the final 2 (of 40) articles reformatted within 48 hours of first edit. I do not know how the dependent pages could be updated as recently "touch'ed" while not actually reformatted. Anyway, for over 2,000 articles, the span has been over 4 days to reformat all. The effect seems like a stretched round-robin queue, where every set of dependent articles are processed among other interleaved newer requests. So, depending on the number of new requests to reformat dependent pages, older requests seem stretched further down the queue, and further apart, so that rather than being reformatted as a consecutive group on the queue, the straggler pages (at the end of the stretched round-robin queue) might be delayed over twice as long, when finally reaching their turns in the round-robin selection. The good news, about the stragglers, is that if all pages need to be reformatted soon, then perhaps null-edit the remaining stragglers which have been pushed many hours/days down in the queue. Of course, that "stretched round-robin queue" might not be the actual queueing process, but it seems to predict the job-queue results, where a handful of leftover pages (5%?) need an extra day or two to reformat, even when 90% of related pages reformatted earlier within the first 1-3 days. -Wikid77 (talk) 06:51, 6 December 2012 (UTC)
Again, agree - there's something funky in the way the queue is handled whereby it is processed in a not-obviously-rational order. Furthermore, some rebuilds seem to get skipped entirely. The problem is probably more visible now because the job queue is not being completed - see the recent graphs for details. In all likelihood we're seeing a side-effect of some genius-level optimisation technique that breaks down when the load is too high. Will wait a few weeks and revisit this in the new year. - TB (talk) 11:23, 7 December 2012 (UTC)
Deactivate page curation toolbox
Hi, I've come here after a discussion at the helpdesk. I was wondering whether it is possible to permanently deactivate the page curation toolbox so it only appears if I want it? I clicked on it a couple of days ago and now it seems to show up on anything new, but I'd like to have the choice of whether or not it appears. Can anyone help? Cheers Paul MacDermott (talk) 09:32, 6 December 2012 (UTC)
I thought that might be what happens but it didn't appear to work for me. I was expanding the article Sarah Champion (politician) a couple of days ago and hit "curate this page" rather than "DYK check". The toolbox appeared so I closed it, but every time I went back to the page (even by clicking on save) the toolbox reappeared. It seems to have fixed itself now as I've just revisited the page without any problems, but it was driving me nuts the other day. :) Paul MacDermott (talk) 12:50, 6 December 2012 (UTC)
Sounds like a caching problem, I suspect! If it becomes "sticky" again in future, try appending ?action=purge to the URL and see it that shakes it loose. Andrew Gray (talk) 11:40, 7 December 2012 (UTC)
What doesn't work? The only issue I see is that three subsections in section 7 are in a collapsed box and the TOC link only goes to the section when it's visible. This is normal behaviour. PrimeHunter (talk) 14:52, 6 December 2012 (UTC)
@PrimeHunter, yes, thank you I see now that only subsections inside a collapsable box (there are two collapsible boxes there) are the ones that do not work in the table of contents. Since I have introduced links to those subsections on other pages at Wikipedia, I am wondering if it would be proper for me to uncollapse these boxes – but I guess this is no longer a technical question, so where should I take it? Ottawahitech (talk) 14:33, 7 December 2012 (UTC)
class or font-family
I am working with a contruct that adds style="font-family:...;" for rare Unicode characters. Do I understand that one can alternatively use class="..." (and add that class) to get good font selection? -DePiep (talk) 15:21, 6 December 2012 (UTC)
Yes {{Unicode}} (and {{IPA}}) use the construct class="...". I can see. Now my question was: can that replace <span style="font-family:...">? (how and when) -DePiep (talk) 22:49, 6 December 2012 (UTC)
In principle, any style="..." can be replaced by a class declaration, but it requires adding the corresponding CSS for the class to site-wide CSS, presumably MediaWiki:Common.css. I was hoping someone more knowledgeable would comment on whether that’s desirable in this particular case, but if not, you can ask at MediaWiki Talk:Common.css.—EmilJ.12:56, 7 December 2012 (UTC)
Sandbox versions for articles
Do we have any "standard" for naming a sandbox version of an article (since "/sandbox" would be in article main namespace)? I am thinking to use a subpage of the talk-page as:
Talk:Article_xx/sandbox - would be the "official" name of Article_xx's sandbox
As a "/sandbox" version, then anyone could edit the shared page, as opposed to a userfied version of an article where other editors might avoid editing. Any thoughts or warnings about this? I am rewriting article "List_of_countries_by_population" to autonumber the 242 table rows by {{Autotable5_big}}, but I want to use a /sandbox version, of the article, until more people are comfortable with the idea of the huge, 242-row list table (1,210 parameters) being quickly formatted inside the template. -Wikid77 (talk) 16:31, 6 December 2012 (UTC)
Agree with the "official" (default) /sandbox page in Talk space. Is a useful habit indeed. A few weeks ago I created one in Article space, and the delete cowboys had my limbs roped before I could edit. -DePiep (talk) 17:06, 6 December 2012 (UTC)
does not support is a nice way of saying. Actually they killed my page while I was editing, Gadget850. No questions were asked. -DePiep (talk) 23:02, 6 December 2012 (UTC)
Does not support means that it is technically impossible. You didn’t create a subpage, but an unrelated main article (including / in its name), and that was killed, unsurprisingly.—EmilJ.13:05, 7 December 2012 (UTC)
No. As I mentioned, it was deleted before I could hit the objection button in the speedy-template. And, in line with this post: it should have been moved to the Talk space. -DePiep (talk) 01:02, 8 December 2012 (UTC)
Well, a simple configuration change could easily enough turn on subpages for mainspace. But then AC/DC would show up as a subpage of AC, just like Talk:AC/DC shows up as a subpage of Talk:AC. And either way, the "sandbox" could show up in Special:Random and in other ways would be counted as an article on its own instead of being ignored as you might expect. Anomie⚔13:53, 7 December 2012 (UTC)
Thanks, I trust your judgment (most of the time!), and the rewriting of whole articles is so rare that most editors would not have used an article sandbox. -Wikid7717:13, 6 December 2012 (UTC)
This should be solved by a sysadmin: add to Mediawiki:gadgets-definition, in "proveit" line, a dependency in "jquery.ui.tabs" (you'll need to use resourceloader - not clear why is it not used already).
@Kiefer: you can solve it temporarily for yourself, until someone will fix the problem for everyone, by adding the following line to your Special:Mypage/common.js page:
All the suggestions should be fixed. There are no more HTTP resources (media/stylesheet/etc.) actually included. A few are linked, but that shouldn't pose a problem. Let me know on the ProveIt talk page if you see more HTTPS-related issues.
I've also gone ahead and added ResourceLoader (with the dependencies, jquery.ui.tabs and jquery.effects.highlight), as suggested (I have been meaning to do this already). I'm not 100% sure if this is related to the original issue. Please test, and feel fee to follow up at User talk:ProveIt GT. Superm401 - Talk09:12, 7 December 2012 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
When trying to edit List of Methodist churches by removing some commented-out text, I saved and got an "Internal error" page with the following message:
[24f700d9] 2012-12-07 00:00:15: Fatal exception of type MWException
The message appeared in a small box outlined in red with a grey background; nothing else is on the page. IE8, Monobook, Windows 7. Any clue what happened? To my surprise, the edit actually went through; I made a second edit to remove something else, and like the first edit, I got the error message even though that edit went through. Nyttend (talk) 00:02, 7 December 2012 (UTC)
Interestingly enough, I just tested it and got [7b2af81d] 2012-12-07 00:05:17: Fatal exception of type MWExceptionLegoktm (talk) 00:05, 7 December 2012 (UTC)
I tried a null edit on both of the articles mentioned here and got the same error on both. Firefox 17.0.1, Vista, Vector. I notice that both articles are displayed (if you have your preferences set to show hidden categories) as being in Category:Articles to be expanded, but the category page does not list any pages at all in that category, only subcategories (and purging the category did nothing). Probably unconnected, but might provide a clue to the devs. jcgoble3 (talk) 05:13, 7 December 2012 (UTC)
Somehow, I didn't get an edit conflict with Nyttend's expansion of his comment. I get the same error with the Presbyterian list, but like him, not with the Unitarian list. Of the four, only Unitarian does not have {{Incomplete}}, which is what produces the phantom category I mentioned above. The Presbyterian list, like the other two, is tagged {{Incomplete}} and has the phantom category. Looks like a stronger connection than I originally thought. jcgoble3 (talk) 05:19, 7 December 2012 (UTC)
OK, Nyttend is right. The {{incomplete}} correlation appears to be a coincidence. It's too late for me to investigate further, though. I may take another look tomorrow. jcgoble3 (talk) 05:25, 7 December 2012 (UTC)
I've asked Doncram to come here; he's been editing these pages more than anyone else, so he might have some clue what's going on. Nyttend (talk) 05:31, 7 December 2012 (UTC)
Yes, the coord template was just changed, and it happened to trash the appearance of these list-articles in development by making a bad red message appear, where nothing properly appeared before. I asked about this and was advised to comment out the empty coord templates. Note, many lines like
| <!---<small>{{coord||||N||||W|name=}}</small>--->
now appears in List of Baptist churches, and edits there cause no MWException fatal error messages. While presence of lines like
| <small>{{coord||||N||||W|name=}}</small>
seems to kick the MW error after an edit. Help in these articles commenting out, but not removing the coord template usages would be appreciated. --doncram15:28, 7 December 2012 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Recent changes to MediaWiki
Not sure what is happening, but {{#expr:( ( 4100 )*1 )/(0.3048)}} is currently generating a division by zero (13451.443569554)? Frietjes (talk) 00:06, 7 December 2012 (UTC)
I've also just added those test cases to the ParserFunctions tests [7], so I (or anyone else) doesn't knowingly break those cases. Purging the page is probably the simplest fix. Reedy (talk) 01:29, 7 December 2012 (UTC)
Does it have to be a null edit? I'm running a script that ?action=purge&forcelinkupdate 's them via the API but it doesn't seem to have much effect...once that finishes and if it doesnt have an effect, I'll run a script to null edit. Legoktm (talk) 03:45, 7 December 2012 (UTC)
That is weird. Regardless, Done. There are 0 articles in that category, I'm guessing all the pages left actually have real errors. Legoktm (talk) 11:58, 7 December 2012 (UTC)
It's clearly broken though, as shown by this example. Should we unwrap the span for now, then file a bug to make the message accept HTML? Superm401 - Talk14:37, 7 December 2012 (UTC)
I agree the span tag should be removed, because it is misleading to users who might think some expression "{{#expr:...}}" has generated a span class as non-numeric data inside the expression. Instead, it should be a simple message, where "{{#expr: < 1}}" should simply report "Expression error: Unexpected < operator". I have previously imagined there was an invalid span class in the original markup, where the less-than sign "<" was the first character of "<span>". Perhaps this is also another example of instruction creep, or more specifically "too-many-CSS-classes creep" where now there are sub-sub-subclasses of CSS classes, and where CSS classes are now being put in messages which do not allow them because there are no other places left on earth which do not have unneeded CSS classes. -Wikid77 (talk) 15:50, 7 December 2012 (UTC)
I can tell you why the span was added: to identify the message when it appears in the html. There is no other way for us, for some messages, to identify a particular message as belonging to a Mediawiki page otherwise, and so for certain messages html is added, with an associated ID or class, to be able to identify this when troubleshooting is needed. --Izno (talk) 17:35, 7 December 2012 (UTC)
Why are some of my en.wiki edits appearing on de.wiki?
Looks like these images probably need the ?action=purge&forcelinkupdate to get them in the right category. I had to null edit the image to get it to show up in the category. I'm not sure though that the way the {{OTRS pending}} is set up to auto-date is the best way though. Legoktm (talk) 15:23, 7 December 2012 (UTC)
Yeah, I was afraid that might be the problem. Is there another way to date things though rather than setting up the template to use/require a date parameter? VernoWhitney (talk) 17:35, 7 December 2012 (UTC)
Misspelling search
Is there a way for me to search for examples of McDonald's spelled without the apostrophe? Searching for "McDonalds" still yields results with the apostrophe. RyanVesey20:03, 7 December 2012 (UTC)
That's a great start. It's been a while since I fired up AWB, but I think that will be useful in fixing them quickly. RyanVesey21:55, 7 December 2012 (UTC)
The latest issue of Signpost had an item about a paper on research comparing readability scores of WP, simple and Britanica. Other than pasting an article into a word processor and asking for a readability report, is there an an easy way to get a readability score? RJFJR (talk) 02:59, 1 December 2012 (UTC)
There are some automated tools (I don't recall where, off-hand), but I generally wouldn't bother. There are so many additional considerations that need to be taken into account when considering "readability" that an automated tool (and most of these papers' analyses) simply don't – or can't – take into consideration. – PhilosopherLet us reason together.13:15, 1 December 2012 (UTC)
I took down my readability tool as I realized it is more harmful then helpful. Those readability algorithms are a horribly crude and papers failing to mention selection bias and the wide standard deviation. Its inclusion in word processing software is because of the contractual requirements.
What I'd like to see is dictionary based analyses such as a time-to-read (via TTS) by section and word occurrences by topic (that is an adaptive spell check). — Dispenser23:06, 1 December 2012 (UTC)
I compiled it and prototyped a tiny Wikipedia front-end for it. Then, I fed Today's Featured Article (the November 7th revision of Imagine (song)) into the program and posted the results to the right. Afterwards, I crossed-check with Microsoft Words and noticed the Flesch Reading Ease was 45.2 and Flesch-Kincaid grade level was 12.5. Maybe Word counts syllables better?
In any case, just among the tests you see basic a ±2 grade differences and that's because these tests are calibrated to three points, the elementary, middle, and high school readers. We're not Simple English nor what we write is important (like safety instructions) that we need to constrain ourselves to a seventh grade level. We for better or worse generally try to write for the web.
Reading the article's prose should take between 9 to 15 minutes at 180 to 300 wpm and an audio book at 18 minutes. Just for giggles, I timed my text to speech reader at 9.75 minutes. — Dispenser06:52, 8 December 2012 (UTC)
Complex template edit request
I'm hoping an adept editor can update Template:Cite court so it behaves more like Template:Citation. That is, "Citation" works with Template:sfn via a "ref" parameter. It's my understanding that using Template:sfnRef as a parameter for "ref" in the "Citation" template, allows one to set an arbitrary label to use with "sfn". Maybe I'm mistaken. Please help me understand how the sfn, citation, and cite court templates work. Xaxafrad (talk) 10:40, 8 December 2012 (UTC)
{{sfnref}} doesn't set an arbitrary label, it allows a label to be defined which matches the one that {{sfn}} is expecting. It's mainly of use on anonymous works. Consider a book titled something like "Report on the financial situation", published by a faceless government department. We might cite that as follows:
*{{cite book |title=Report on the financial situation |publisher=Governent of Fooland |year=2012 |ref={{sfnref|Governent of Fooland|2012}} }}
Then we may use {{sfn|Governent of Fooland|2012|p=123}} etc.
{{cite court}} doesn't have a |ref= parameter, and there was a big row at Wikipedia talk:Citing sources a little over a year ago about bringing {{cite court}} within the Citation Style 1 system, which would have sorted this for you. What you can do is use {{wikicite}}. Let's suppose that the case of Box vs Cox was heard in 2012. We might want to use {{sfn|Box vs Cox|2012|p=123}}. To link that to a {{cite court}} we would wrap the {{cite court}} in {{wikicite}} like this:
{{wikicite |reference={{cite court | ... all the normal parameters ... }} |ref={{sfnref|Box vs Cox|2012}} }}
When using the Reliable sources wizard the "Continue to the next step" link from step 3 to step 4 seems to be broken meaning steps 4, 5 & 6 are unavailable, Shall I do I Bugzilla or am I using it wrong? --wintoniantalk16:57, 8 December 2012 (UTC)
It isn't you. I just tried it. Step 3 was fine, except "Continue to the next step" is a red link. When clicked, that red link tells me no such page exists. There is, therefore, no way to continue to find steps 5 and 6. — Maile (talk) 17:05, 8 December 2012 (UTC)
Hi! When reading the French Wikipedia, I came across the link "Gaeltachtaí", and I found that the same thing happens here: when special characters appear after the link brackets, they are not included as part of the link in the same way as the s in "numbers" ([[number]]s). There are workarounds (writing [[Gaeltachtaí]] and creating a redirect, or using a piped link, e.g. [[Gaeltacht|Gaeltachtaí]]). But it seems to me that fixing the way the text renders would be a more elegant solution. Or is there some reason this is impossible or undesirable? Lesgles (talk) 02:47, 9 December 2012 (UTC)
For English, the "link trail" is currently set to contain only ASCII letters; for French, it also includes any of these: àâçéèêîôûäëïöüùÇÉÂÊÎÔÛÄËÏÖÜÀÈÙ. There was an attempt back in 2008 to make it more comprehensive, but at the time old server software didn't support it well and it wound up having to be rolled back. The situation may have changed in the four years since. It might be worth raising the issue anew in bugzilla or in a post to wikitech-l. Anomie⚔03:21, 9 December 2012 (UTC)
Your character í is not there. You can make a request at bugzilla:, but I note that the article í does not mention French among languages using the character. If it only occurs in foreign names then I'm not sure there should be a huge $linkTrail assignment for this and a multitude of other foreign characters. PrimeHunter (talk) 03:30, 9 December 2012 (UTC)
No, I don't see the need to bother anyone for this one example, which is indeed pretty rare. In the future, though, I do think it would be simpler to find a way to allow all Unicode characters in the link trial for all languages. Thanks to both of you! Lesgles (talk) 22:53, 9 December 2012 (UTC)
watchlist drop-down message
Can I disable the watchlist drop-down message? I don't need it to tell me that something has been added or removed from my watchlist. I'm using Firefox. I'm referring to the messages reading: "The page "XXX" has been added to your watchlist, which will list edits to this page and its associated talk page. The page title will also appear in bold type in the list of recent changes" and "The page "XXX" has been removed from your watchlist." Thank you. Bus stop (talk) 18:49, 9 December 2012 (UTC)
Need article titled "Independent State of Albania" moved to "Albanian Kingdom (1943–1944)", no such "Independent State of Albania" existed, need administrator to restore to previous title
Someone moved the article titled Albanian Kingdom (1943–1944) to Independent State of Albania and now it is not possible to undo this without administrator assistance. I looked at the German sources for the title, there is no mention of that title at all in German or Albanian in those sources. However from my research, Albania remained an kingdom from 1943-1944 without a king, but a "Regency Council" being in charge, a regency of course is adopted when there is a kingdom with no king currently available to govern. Thus the people who created the title Albanian Kingdom (1943–1944) were accurate, and I am requesting that the article be restored to that title since there is no evidence of the state being titled "Independent State of Albania".--R-41 (talk) 03:12, 10 December 2012 (UTC)
I just moved my vector.js and vector.css files to common.js and common.css, respectively. When I went to tag the resulting redirects for speedy deletion, I discovered that somehow the redirects had been suppressed, even though I am not an admin and do not have the suppressredirect right. Is this normal behavior when working with .js and .css files, or is this a bug? Also, the confirmation screen telling me that the move was successful told me incorrectly that a redirect had been created in both cases, which added to my confusion. If this is a bug, it should be fixed; if it is proper behavior, then the move confirmation screen should be adjusted to correctly indicate what happened. jcgoble3 (talk) 07:28, 10 December 2012 (UTC)
I think that it's new behaviour, but should not be considered a bug, because the previous behaviour was to leave a Wikicode redirect, which was both invalid CSS and invalid JS. It was certainly still leaving a redirect in October this year. --Redrose64 (talk) 14:11, 10 December 2012 (UTC)
It is new behavior due to the ContentHandler code recognizing that .js and .css pages don't actually do redirects. But it is probably still a bug that this failure to create a redirect is not reflected in the page move UI, so I've submitted that as T44915. Anomie⚔14:25, 10 December 2012 (UTC)
Watchlisting rollbacks
Does anyone know of any scripts to automatically watchlist any pages you use standard (non-Twinkle) rollback on? I don't know JavaScript very well, but as best I can tell, it should be possible. I use a script (very slightly modified from the original) that, if I understand correctly, adds a ?summary= to the rollback URL... so I figure it should also be possible to add a?action=watch, right? — Francophonie&Androphilie(Je vous invite à me parler)01:12, 8 December 2012 (UTC)
The "obvious" thing to do would be to add &action=watch to the existing query string; but unless that is also given a watchlist token, it asks for confirmation, like this. If you can live with the extra click, it should be possible in javascript. --Redrose64 (talk) 12:26, 8 December 2012 (UTC)
2nd thought: this should work for "vanilla" rollback, but may or may not collide with the script you already use to add summary. however, on the script that adds the summary option, it should be very easy to change just one line, i.e., instead of
a bit difficult for me to test, not having "rollback" permissions myself. according to the API documentation, this works for "action=rollback" thorough the API.more ofent than not, the API parameters are the same as the "regular" parameters, but apparently not here. this can still be accomplished by changing the behavior of the rollback link to work through the API, but it will be a bit more elaborated (not by much - maybe making it a 4-line script instead of the one-liner above), but it will change the behavior a bit (by leaving the user on the same page instead of getting them to a different page). let me know if you are interested - i'll try to knit something peace. קיפודנחש (aka kipod) (talk) 22:55, 9 December 2012 (UTC)
Sure, if you don't mind. Sounds great. As for testing, well, I just stalked your contribs a little, and with 20,000 edits on Hebrew, I don't imagine it'd be too hard for you to convince an admin that you're trusted enough that you can be given rollback simply for testing purposes. (I assume they don't have it over there?) There's also testwiki, where they'll give any trusted user the full admin bundle, provided they can demonstrate a need for it. Or you can just try to put something together blind, and I'll try it out and cross my figures that I don't, like, rollback every latest revision or something. (In one attempt to do this on my own, I clicked rollback in my sandbox and was promptly informed that, no, I could not revert the latest revision to the main page.) — Francophonie&Androphilie(Je vous invite à me parler)23:55, 9 December 2012 (UTC)
Following this discussion I've just given קיפודנחש the rollback right. I would suggest caution in using it for anything other than testing but they seem trustworthy enough to read the documentation before using it for anything else. Dpmuk (talk) 05:04, 10 December 2012 (UTC)
I've been thinking about this, having noticed that after a non-Twinkle rollback there is the usual set of tabs along the top - one of these is the "watch" tab. You could use that directly, no need for a script which just gives an equivalent button in a different place. --Redrose64 (talk) 12:52, 10 December 2012 (UTC)
so i created this script, with some rudimentary documentation in the talk page. in a nutshell, this script changes the behavior of the "rollback" link, such that it would work through the API instead of through "action=rollback". This basically means that the user remains on the same page after pressing "rollback". together with the popup gadget, it might make it slightly easier to deal with vandalism, because you can stay on "recent changes", get the content of the change through popup, decide whether or not to rollback, and immediately move to the next edit.
with this script, if you hold the <Alt> key while pressing "rollback", you will be prompted for a summary for this rollback instead of the default one. if you have "window.watchOnRollback = 1;" in your common.js, every page you rollback will automagically be added to your watchlist.
Beautiful beautiful beautiful. ! תודה רבה Now I remember the problem I had with Israel - everyone's smarter than me there. One thing: Now, this isn't a big deal, since I already have that summary script, but on my laptop, at least, "alt"-clicking has the same effect as a right-click (PC)/control-click (Mac)/two-finger click (trackpad). Is there any workaround? As I said, perfectly fine if there isn't, especially since my next question would be if there's a way to pre-load a default summary when doing that. (I, for one, like to retain a slightly pared-down version of the standard notice whenever I rollback with a summary, to make it clear that I'm reverting - see here, for instance.) — Francophonie&Androphilie(Je vous invite à me parler)03:33, 11 December 2012 (UTC)
so i changed the "summary" behavior from <Alt>+click to Right click (aka "context menu"), and added "User Contributions" to the list of pages this takes effect. as to default: add to Special:Mypage/common.js the following:
Now, in the spirit of asking you to do more and more complex things... normally, when you go to diff view after rollback, Twinkle puts the link to the user's talk page in boldface, signifying that it's added &vanarticle=[whatever the article was] to the URL - so that when you click the "warn" tab, the "linked article" field is already filled. So, for bonus points, would there be a way to incorporate that into the script as well? Maybe so when the "rollback" button disappears, the "talk" link for that user gets put into boldface, and gets the &vanarticle= tacked on? — Francophonie&Androphilie(Je vous invite à me parler)09:49, 11 December 2012 (UTC)
ok, i did what you asked, but there are some caveats:
i did not test it in all places where the "rollback" link appears. i do not feel very comfortable rolling back other people's edits just for some script testing. so testing is on you.
i am not familiar with twinkle, but i am not sure the "vanarticle" thing will actually do what you want. specifically, there is a fundamental difference between "blue" talk links, which lead to viewing the talk page, and "red" links, which lead straight to the edit page.
Haha I had this script fired up before you even posted here. Awesome. It worked after I reverted myself in my sandbox. And revision history's the only place where it makes a big difference - you only ever go out of watchlist or contribs if you're blindly reverting what you're sure will be vandalism - in which case the user's either already blocked, or has vandalized so extensively that you don't really need to link to any articles in your warnings. — Francophonie&Androphilie(Je vous invite à me parler)16:53, 11 December 2012 (UTC)
Self reference and mobile
The #works section of Giles Gilbert Scott says "Click on arrows to sort by work, place or date". This isn't applicable on our mobile version or mobile app (nor, probably, on sites that reuse our content).
How can we mark up instructions of this kind, so that they will not render in such circumstances? We could perhaps have a template for the purpose, which applies an HTML class that hides them for mobile, but other re-users might not understand the purpose of that. Perhaps we could have several classes, for text relating to various types of functionality, which could be dropped as and when that functionality becomes available in mobile.
We definitely should NOT banish such instructions. A pair of black triangles base to base is not a self-evident instruction, especially since they are black and not blue. This is not some-thing I was taught in school, in college, in grad school, or even in HTLM class (and we certainly cannot expect our readers to have had such special training). If some-one thinks it is self-evident or common knowledge, then please give a source for such. Wikipedia has enough stumbling blocks for users and editors; we don't need to have this one.Kdammers (talk) 07:34, 11 December 2012 (UTC)
The javascript that provides the table sorting should do a better job of instructing the reader how to operate the sorting. This text should indeed be banished from the article. I would suggest identifying where the table sorting comes from and raise a bug about it not being clear to readers... Jdlrobson (talk) 21:07, 8 December 2012 (UTC)
Readers with JavaScript disabled don't have sort functionality either. We have {{noprint}} with class="noprint" to omit something from printing. It could be used for texts about sorting to at least remove it in one type of case where it's not relevant. PrimeHunter (talk) 21:18, 8 December 2012 (UTC)
Do we really need the instruction to tell people they can sort by clicking the arrows, any more than telling them how to use scroll bars or other UI features? —[AlanM1(talk)]—21:28, 8 December 2012 (UTC)
As I just wrote above, the triangles -- NOT arrows -- are not obvious. I only found out what they were supposed to do long after having seen them and been baffled by them. Kdammers (talk) 07:38, 11 December 2012 (UTC)
Request for installation of Extensions on Wikipedia
Hello, I am a top editor on DDOwiki, which is a wiki for a popular MMORPG. I recently was in the process of creating a couple of templates on my wiki, and I checked on Wikipedia for ideas on how to make my templates work. I was in need of creating a set of templates that could convert decimal numbers to roman numerals (Template:Dec2roman) and roman numerals to decimal numbers. I was able to use this wiki's Template:Dec2roman as a starting point for my Template:Dec2Roman. This wiki did not have a Template:Roman2dec however, so I created one on my wiki (Template:Roman2Dec), which works great; however, when I attempted to copy it to Wikipedia I found that Wikipedia does not seem to have mw:Extension:Loops OR mw:Extension:VariablesExtension installed, so my template does not work here. Is there any way of getting these extensions installed on Wikipedia or can someone suggest an alternative way to write my template with existing extensions. Thank you for your time -- ShoeMaker ( Contributions•Message ) 01:03, 10 December 2012 (UTC)
Neither are installed here due to security/performance concerns, I believe. You will probably want to wait for Scribunto, which is coming to Wikipedia soonTM. --Izno (talk) 01:11, 10 December 2012 (UTC)
Exactly, we developers are not fond of what wikitext has mutated into so we will not aggravate the situation by adding more weird parser functions. Also, Loops looks very doubtful from the performance point of view while Variables users might discover that evaluation order is different from what they expect so fun ensues. Max Semenik (talk) 19:19, 10 December 2012 (UTC)
That doesn't explain why the link is to a third-party domain, especially one associated with an adware/malware browser add-on. A web search tells me the program might be called "NetAssistant". PleaseStand (talk) 01:47, 10 December 2012 (UTC)
What's wrong with the ref error at Death of Maria Ridulph? I'm using the same code <ref name=Wade /> that I used in all of the other refs, but one of them is giving me an error message. It's listed as ref 3. RyanVesey15:40, 11 December 2012 (UTC)
It's because you haven't actually defined the "Wade" ref anywhere, you just invoke the name. You need to do the whole <ref name="Wade">Wade, John. "GOTO Statement Considered Harmful". etc. etc. </ref> thing somewhere. Writ Keeper⚇♔15:46, 11 December 2012 (UTC)
I did define that though, and I used the named ref 6 times, it's only on the one where it doesn't work. Interestingly, refs before and after the one that is broken behave normally. RyanVesey15:48, 11 December 2012 (UTC)
Redlinking users with zero edits in User:Jfd34/filterlog.js not working
User:Jfd34/filterlog.js is a script which on the edit filter log is supposed to show links to the user's filter log and the history of the edited page, and also if the user has made zero edits, show the user contribs link as a red link. However the redlinking of "contribs" for usernames with zero edits does not work (this is done by using the API to get the edit count of each user on the list and red link the contributions if it is zero). On archive #105 of this village pump someone said the problem was related to a bad change in the user creation log ([14]) but I do not think this problem is related to that in any way, it is most probably something to do with the script itself. jfd34 (talk)17:27, 11 December 2012 (UTC)
Anybody interested in maintaining the currently maintainerless Reftoolbar?
The Wikipedia:RefToolbar (the javascript utility that allows for references to be easily added to articles) currently has no active maintainers. Since the toolbar is such a useful and critical part of the default interface, this is both surprising and unfortunate. I have spent some time organizing pages related to the toolbar to make it easier for people to understand how the toolbar works and where's it's relevant sources are. I have consolidated bugs I have noticed and some ideas for improvement into a "Roadmap to 3.0", whiich I hope attracts attention to this abandoned project. If any of you hackers wish to tackle a small code base that has a big impact, this a great opportunity. Jason Quinn (talk) 21:45, 11 December 2012 (UTC)
Article traffic display
I keep finding that this (for example) no longer shows the article hits per month in bar form. The same goes for any other article. I have found this problem both in Chrome and FireFox for a few weeks now. Simply south......walking into bells for just 6 years00:20, 12 December 2012 (UTC)
It works for me in Firefox 17.0.1, IE9, Opera, Safari, but the bars are not shown in Google Chrome 23.0.1271.95. In Chrome I see the grid and can see the hits as numbers when I hover where the bar should have been. With IE9 in compatibilty mode I don't see anything. Not the bars, grid or any numbers, and nothing happens when I hover over the big blank space where the bar chart should have been. PrimeHunter (talk) 02:52, 12 December 2012 (UTC)
Below is a copy of the regular update for the past fortnight on the VisualEditor project so that you all know what is happening (and make sure you have as much opportunity to tell us when we're wrong, as well as help guide the priorities for development and improvement).
In the two weeks since 1.21wmf5, the team have spent their time finalising the code and preparing for its test deployment tomorrow for editors to use and give us feedback.
A lot of changes were made to how the VisualEditor integrates with MediaWiki. These included having a separate VisualEditor tab rather than replacing the existing edit tab (42221 and 41159), integrating into the existing edit controls so that protection, global blocks, AbuseFilter etc. work (37844, 38268 and 42142) and the user is sent somewhere when there's an edit conflict (37828), adding a 'cancel' button from editing mode back into read mode (37845), fixing watch and minor edit functions in the save dialog so they work as expected (38034, 40774, 42136, 42137, and 42764), custom save buttons for old revisions and new pages (41865 and 42750), adding page notices into the workflow so it's clear when you're editing a page with some form of protection, or which has special issues (42220), and tagging all edits made with the VisualEditor so that they can be identified (42172).
The user interface inside the editor, and in particular the link inspector, had a number of changes, including preventing undetectable links over whitespace (42839), avoiding two highlights for the same suggestion (42665), highlighting suggestions on mouse hover (39977), instant response from the link suggestions box (42341), allowing link "pre-annotations" when nothing is selected (33141), buttons not responding to clicks when disabled (40976), and a bug when switching between links (42552).
We fixed a number of bugs and minor annoyances with the core editing surface module, including deleting failing on blank lines (42657 and 42655), on documents that had been blanked (41071), around 'alienated' content (42350), in Firefox with empty paragraphs (41223) and select-all replacements (42404), selection getting removed every few moments (42801) and breaking going backwards (42401), with errors being wrongly-thrown (39255, 41501, and 41504).
Finally, a series of changes were made to the 'Data Model' component that converts between the information that Parsoid gives us and a structure that the code can edit. These include allowing paragraphs inside spans (and other invalid HTML sequences - 42487), fixing the way that unlisting buttons work (41929), correcting the data model when "unbalanced" content is copied (42806) or when you delete alienated content (42707), the leading newline of <pre> elements (42469), and annotating inline aliens (like HTML entities - 42340).
About five days ago a user somehow managed to create an article at the title Сloser, without interfering with the disambiguation page that exists at the title Closer. I'm having trouble figuring out how this happened, as I'm entirely unable to discern any character differences between the two titles — but even after I moved the article to its properly disambiguated title, Сloser (Mandy Capristo song), I still had to manually redirect the original title to the disambiguation page. Can somebody with more technical expertise than I've got around things like this try to figure out how it is that Сloser and Closer are somehow managing to function as two distinct page titles? The only obvious (to me) candidate, a 1-for-l substitution, doesn't seem to be the answer. Thanks. Bearcat (talk) 03:40, 12 December 2012 (UTC)
Thanks. I did not know that the Latin and Cyrillic C's actually had two separate unicode numbers (although I should have figured that character was the problem, since the article was sorting after Z in an alphabetical cleanup list.) You learn something new every day, I guess. Thanks again. Bearcat (talk) 04:04, 12 December 2012 (UTC)
The Cyrillic character that looks like the Roman "C" is equivalent to the Roman "S". I wouldn't expect it to have the same Unicode character as "C". — QuicksilverT@05:52, 12 December 2012 (UTC)
One of the principles of Unicode is that each alphabet has its own block (or blocks) of code points, which do not overlap with those of other alphabets, even when two letters look the same and are pronounced the same; as noted, the letters S and С look different but are pronounced the same; conversely, P and Р look the same but are pronounced differently. The Russian for "Tennis" is "Теннис", which looks odd to a Western reader - but don't worry, it's pronounced "Tennis"; T (U+0054) and Т (U+0422) (also the Greek Τ, U+03A4) are visually identical, phonetically pretty much equivalent, but have different codepoints. --Redrose64 (talk) 13:43, 12 December 2012 (UTC)
fwiw, the following JS code will show you the actual charcodes of characters in a pasted string.
the way to use it is to press F12 on your browser (works for IE, FF and Chrome on windows and FF and chrome on linux. i do not know about macs and handheld), choose "console", paste the code there, replace the 'paste your string here' with the actual string you want analyzed, and press <Enter>.
$('paste the string here'.split('')).each(function(index,item){console.log(index+': "'+item+'": '+item.charCodeAt(item,0).toString(16))})
Nice. I confirmed that it gives UTF-16 encoding with the character "𐐀" (U+10400), which correctly produces 0xd801dc00 (I added the 0x prefix to the script for clarity):
0: "�": 0xd801
1: "�": 0xdc00
It would be cool if this function could be integrated into the interface, like maybe a shortcut key that dumps the contents of the clipboard to the console. Can that be added to my common.js? —[AlanM1(talk)]—17:39, 12 December 2012 (UTC)
It does, but reviewer also includes several other permissions, such as the key ability to manually mark others' revisions as accepted. Autochecked does not have that ability; it includes nothing but the one permission I quoted above. jcgoble3 (talk) 19:33, 12 December 2012 (UTC)
Yes and no. I think that, with policy as it is, it is redundant. However, if the second level of PC were ever approved, then this userright would allow editing on a PC2-protected page similar to how confirmed/autoconfirmed works on a PC1-protected page now. This chart might be helpful. Since PC level 2 wasn't approved, the userright has no current use. Writ Keeper⚇♔20:56, 12 December 2012 (UTC)
So if I understand correctly, autochecked users' edits are automatically accepted for pages with PC-protection, but they are not allowed to review other users' edits (as reviewers can). Kind of like autopatrolled, but for PC-protected articles. The Anonymouse (talk • contribs) 21:26, 12 December 2012 (UTC)
Quick question: Why do I have to unaccept a revision, then reject it afterwards if I find it nonconsctructive? Shouldn't unacceptance at least imply rejection and, if possible, trigger an automatic rejection of the unaccepted revision? I imagine this would be fairly easy to achieve, but I'd like to hear others comment on it. Evanh2008(talk|contribs)10:54, 12 December 2012 (UTC)
I could envision a situation where someone's accepted a potentially very defamatory revision without leaving any summary explaining that they've done some quick research and confirmed that it's true (and the source provided in the edit doesn't conclusively say so): You unaccept it, look up the person to see if they are in fact whatever awful thing they've been accused of being, and if you can find a good source for it, you revise the unaccepted version to include the better source, and then re-accept. I agree that the vast majority of unaccepts will be shortly followed by rejections, but considering that unaccepts are supposed to be fairly rare, and that rejections are only supposed to take place after you've ascertained that the edit's in violation of a policy, I see the logic in separating the functions. — Francophonie&Androphilie(Je vous invite à me parler)21:07, 12 December 2012 (UTC)
Pending Changes unaccepting
Not that I would be one to go around doing this, but I found on one of the test pages that any reviewer can unaccept any revision to a PC protected page, even one from a confirmed editor, and it isn't publicly logged at all unless the reviewer chooses to "advertise" their unacception. This seems kind of bad to me, as it would allow a reviewer to unaccept a revision multiple times without anyone knowing, therefore bypassing 3RR and creating a sort of hierarchy. Anyone else see this, and if so, comments? Thanks, gwickwiretalkedits23:44, 12 December 2012 (UTC)
For about the last 20 hours, I've been having problems with my scripts functioning temperamentally. Problems specifically in the last 5 hours include script buttons that occasionally fail to appear on the sidebar so that attempts to repeat script calls after a diff are impossible. I refresh the vector page and the script buttons appear for a few more diff cycles, and then [sometimes not all of them] disappear again. Is anyone else experiencing these same problems? -- Ohconfucius ping / poke06:11, 13 December 2012 (UTC)
I am sorry, I thought I was editing the Wikimedia Commons village pump. But then again, it may be Wikpedia project wide. Tekstman (talk) 13:14, 13 December 2012 (UTC)
I've since noticed that even popups isn't working for me now, and the insertion bars at the top of the edit window has disappeared, and the one at the bottom don't now insert anymore. It's becoming a minor catastrophe! -- Ohconfucius ping / poke03:58, 14 December 2012 (UTC)
Pending div/mod function change
Just a warning that the div and mod functions have changed, following the resolution of bug 6068. This is about how these functions work with non-integer parameters. It doesn't seem to have been implemented here yet, but has caused problems with co-ordinate displays on Commons (now resolved). See Commons:Village pump#Template Location damaged for further information. An optimist on the run!14:44, 13 December 2012 (UTC)
Hat template not working?
Go to Wikipedia:Redirects for discussion/Log/2012 November 25 and you'll see a massive list of redirects that are up for deletion. Because the list is so long, I added the {{hat}} template some days ago at the start of the list, and I placed {{hab}} at the bottom. All was well: the page became substantially shorter unless you clicked the "show" tab. However, "hide" and "show" are no longer appearing — the page is set at "show" and can't be changed to "hide". Any clue why not? The code appears to be the same. Nyttend (talk) 02:38, 14 December 2012 (UTC)
How again do I enable and disable Java? I learned how in order to get around the SOPA blackout, but I've since forgotten. Running IE8. Nyttend (talk) 05:43, 14 December 2012 (UTC)
This should be how. Unfortunately I'm on a Mac so I don't have anyway of testing whether something is broken with the template show/hide code on IE8. It would be nice if we had something like WP:IE8 which listed all the problems with using it. :P Legoktm (talk) 05:50, 14 December 2012 (UTC)
Tsk, tsk; you need to start using a computer instead of a Mac. The link was helpful, but it looked like I already have everything turned on. Turns out that it was a script, though — many pages lately have been giving me a "Stop running this script? A script on this page is causing your web browser to run slowly..." message; if I stop running it, the hat template doesn't work; if I permit it to continue, the template works fine. Thanks! Nyttend (talk) 05:56, 14 December 2012 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I'm trying to monitor article feedback at Special:ArticleFeedbackv5, but all of the text fields and buttons for featuring, marking as resolved, hiding, and requesting for oversight are gone (all it has is the "Feature this post" text and the "x" close button). Anybody else seeing this?
Is it possible, and if so, might it be a good idea, to turn off AFT until it's fixed? I know it's still in development and all, but I'm a bit worried about the fact that we've lost our capability to moderate what can at times be a rather turbulent part of the project. People post feedback submissions without even thinking where they go, and it's a lot simpler to type in a bunch of curse words in the helpful text box at the bottom of the page than to open up the edit window and vandalize. If that's all this were about, though, I obviously wouldn't be suggesting this, but... there is stuff that has to get oversighted on AFT. Clearly it doesn't happen that often, but I'm kinda bothered that right now someone could write (as I indeed once saw someone write) "FIX THIS FUCKING ARTICLE OR I'LL COME TO YOUR HOUSE AND KILL YOU," and we wouldn't even be able to hide it from the public view, much less oversight it. Same goes for saying nasty things about friends and winding up disclosing personal details about a minor, or a host of other things: At the moment, when a random reader looks at an article's feedback, they see absolutely everything that's been posted since this glitch started. I don't know, but I find that a bit troubling. — Francophonie&Androphilie(Je vous invite à me parler)11:10, 14 December 2012 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Archives search bar
Hi,
I see the topic has been raised at least once in 2011, but I did not understand how the concern has been addressed.
Here’s the issue : if I type, for instance, « Blanchett » or « iconic » in the search bar of this Talk page, I get no results although those words are present in the archives. What’s the problem ? Cheers, --182.163.42.82 (talk) 12:49, 14 December 2012 (UTC)
The template {{talk other}} takes two positional parameters, and returns the first if used on a talk page, and returns the second if used on a non-talk page. Thus,
{{talk other|This is a talk page|This is a subject page}} returns This is a subject page
when used here. However, it breaks if all or part of the second parameter is wrapped in <span class="error">...</span>:
{{talk other|This is a talk page|This is a <span class="error">subject page</span>}} returns
(i.e. nothing). I spotted this because I found a case of {{edit semi-protected}} being used on an article here, when searching for bad edits by this anon. It should have shown Error: Semi-protected edit requests should only be made on the talk page. and put the page into Category:Non-talk pages requesting an edit to a semi-protected page, but did neither of these. If I amend {{edit semi-protected}} to remove the class="error", it works. I've determined that if the <span> has no attributes, it works - but as soon as it's given an attribute, whether class=id= or style=, regardless of whether the attribute has a value or not, the whole of the second positional parameter is ignored. --Redrose64 (talk) 15:41, 14 December 2012 (UTC)
Try this:
{{talk other|This is a talk page|This is a <span class{{=}}"error">subject page</span>}} returns This is a subject page
I can not Upload file. Tried twice. After clicking on "upload' it gives message Once uploading is completed, you will find your new file at this link:, but when after some time when clicked on the link, I found the files have not been uploaded. Tried thrice. File name: File:Gomolo logo.jpg --Tito Dutta (talk) 00:13, 15 December 2012 (UTC)
Hi, I'm not sure if this is the right place to ask this. I was referred by the Teahouse to come here.
I often find myself looking at a table in Wikipedia (or elsewhere) and thinking to myself: "I'd like to download that data into Excel and rearrange it or merge it with data from elsewhere." But if I just copy the table and paste it, I usually get a long string of information. Instead of tabs between fields and a carriage return at the end of the line, there are just spaces between each of the entries. Using tools like BBedit, Tex-Edit Plus, Word, and lots of perseverance, I can usually recreate the table in a form that I can upload to Excel from this data stream, but it is often a difficult process (especially if the cells of the table have textual data with spaces).
So I would really like someone to create a widget that would make this task easy. What I envision: at the top of each table in Wikipedia there would be an icon. If you clicked on the icon, it would automatically download the table in .csv (comma-separated values) format which could then be easily imported into Excel or another spreadsheet program (Google Docs, etc.). I assume it would be relatively easy to create such a widget since tables have a regular and simple markup language (though text that extends over two or more cells might be a bit tricky). There are already widgets for converting spreadsheets into Wiki's markup language, but as far as I can tell, no easy way to go the other direction.
Not exactly the way you want to do it, but you can, instead, query the web page from Excel. In Excel 2007, it's at Data→Get External Data. You enter the URL, it loads the page in a special dialog, and you then choose which objects you want to import into the spreadsheet. I just tried it with the page you mentioned and it's not ideal – it doesn't manage to pick out the tables separately like it does with other sites I've used it on, but the data you need is there, embedded within a bunch of other stuff, starting at cell FA194. —[AlanM1(talk)]—16:04, 12 December 2012 (UTC)
Okay, try User:Writ Keeper/Scripts/tableConverter.js. It's a bit ugly, but it should work (possibly not in IE, though). When you get the download prompt, do pay attention to what the file is named; the file name starts out as weird garbage in my tests, and I don't know how to get around that. So just make sure to name it something sensible, and remember to end it with the ".csv" extension. Any advice on how to sex up the appearance or output would be welcome. Writ Keeper⚇♔17:05, 12 December 2012 (UTC)
Neither the 2004 or 2008 versions of Macintosh Excel seem to be able to import from a url. The 2008 version let's me import an html file from my desktop (File-Import...) but that, of course, involves an extra few steps (edit page on Wikipedia, copy table lines, paste into a new text document, save as an html file). I can do this, but it would be nice for it to be more automated. I don't know how to run the script that Writ_Keeper has created. Perhaps someone else can try it. I was hoping there would be something as simple as what the Census Bureau does, for example, at the bottom of this page: http://quickfacts.census.gov/qfd/states/39000.html . Randy Schutt (talk) 17:52, 12 December 2012 (UTC)
Oh, sorry, just put importScript("User:Writ Keeper/Scripts/tableConverter.js"); into your common.js page. Once you do that (you might have to bypass the browser cache afterwards; instructions for how to do that are at this page), you should see a link that will appear below every wikitable, and when you click on it, it'll prompt you to download a file. As I said, just rename the file to something sensible with the ".csv" file extension, and it should be good. Writ Keeper⚇♔18:19, 12 December 2012 (UTC)
Thanks. I now have a nice "Export as CVS" line at the bottom of the table (though note that it is actually part of the table - a new cell in the first column and below the last row). But when I click on it I don't get the hoped for results. I'm running OS 10.5.8 on my iMac. On Safari 5.0.6, I get a new page with all the table's html code splayed across the screen. With Firefox 16.0.2, I can save the file (with a weird name zMpfGqwp-1.part), which I can rename and open in Excel, but the file has no content. With Chrome 21.0.1180.90 I get a file ("Download") that I can rename and open in Excel. It has the table information, but still includes all the anchors and span html code (could that be stripped out?). Randy Schutt (talk) 18:56, 12 December 2012 (UTC)
Randy, your few extra steps to get HTML into Excel won't work. The text shown on Wikipedia's edit screen is in wikitext format, not HTML. It doesn't turn into HTML format just because you save it in an HTML file. A technique that should work (and is also fewer steps) is to use your browser's File ▸ Save As... command while reading the page. In the Save dialog, select HTML (without images) as the file type. (The default in some browsers is a "web archive" or with-images format such as MHTML. I'm not sure Excel can handle that.) Writ Keeper's script is the easiest option if it works for you (I've not tried it myself). – PartTimeGnome(talk | contribs)18:49, 12 December 2012 (UTC)
PartTimeGnome, oh yes, you're right. In the past, I've used a text editor to put the proper html headers on the file to make it into a proper html file. But for converting Wikipedia, your solution would be much better/easier. This process doesn't work if I use Excel 2003 for Mac (since it can't open html files), but it does with Excel 2008 for Mac. So this is a solution. Still, I would like a one-button solution and especially to have this be a normal part of Wikipedia (rather than having to install scripts, etc.) But, so far, Writ Keeper's script isn't working very well for me. Maybe I'm asking for too much. Randy Schutt (talk) 19:20, 12 December 2012 (UTC)
Hmm, it's working for me in Firefox and Chrome, though I did have to fix a few bugs. Perhaps you should bypass your cache again and retry. What table are you trying this on? Writ Keeper⚇♔19:27, 12 December 2012 (UTC)
one small problem is that tables in enwiki often contain junk in the form <span style="display:none">some-string-for-sorting</span> (it's not "junk" per se, but it cause pain for the converter. you probably want to do something like
Writ_Keeper, it works pretty well now: On this page List of Justices of the Supreme Court of the United States, Mac OS 10.5.8, Safari 5.0.6 opens up a new page with all the items enclosed in quotation marks and delimited by commas, and all the anchors and span code has been stripped out. I can copy and paste it into Excel and it converts without much effort. Firefox 16.0.2 worked for me once I turned off TACO (oops, my bad). And Chrome 21.0.1180.90 works pretty well too. The script works well on the two tables on this page too: United States Senate elections, 2014 and the second table has lots of empty cells. It mostly works on this page too List of United States Supreme Court Justices by time in office, but the term in office number is not quite right: for example, for Douglas it is 700413358000000000013,358 instead of 13,358. Perhaps the comma in the number is screwing up the conversion. But overall, this is a good solution for me. Thank you very much. Now my wishlist is: make the "Export to cvs" text smaller, make it into a button instead of a cell in the table, put it at the top right of the table instead of the bottom, and make it available to everyone without them having to put the script call in common.js. — Preceding unsigned comment added by Randy Schutt (talk • contribs) 21:35, 12 December 2012 (UTC)
what cause the problem you report is not the comma, it's exactly what i was talking about: an invisible field that's placed in sortable tables for sorting purposes. the remedy would be to remove the invisible data before generating the file. my snippet (admittedly untested) is supposed to do that. peace - קיפודנחש (aka kipod) (talk) 21:52, 12 December 2012 (UTC)
How easy would it be to produce a data set consisting of the age of accounts that have created pages that have been deleted via CfDs and Afds? The data would be number of pages per new account age time bands (it would mean getting access to the history of deleted pages). I want to see if there is a case for lengthening the stand down period of new page creation for new user accounts. -- Alan Liefting (talk - contribs) 18:47, 15 December 2012 (UTC)
The best way to do that would be to run a query on the database, so any Toolserver user should be able to do that for you. Legoktm (talk) 19:44, 15 December 2012 (UTC)
Watchlist JS bolding
Demonstration of the problem. See below for explanation.
This is not a new problem, but rather something that I've put up with since the day I registered nearly two years ago and I'm finally fed up with it. When I load my watchlist for the second or subsequent time in the same browser session, JavaScript bolds the entire line of all edits that are new since the last time I loaded my watchlist. This would seem helpful except for three major problems: first, it's based solely on whether it was listed the last time I loaded my watchlist with no regard to whether I've viewed the edit through other means, and second and more important, I have CSS set up to bold the titles of pages that have changed since I last visited them, and this JS thingy hinders that by bolding edits that I've already visited via other means, including my own edits. I've had enough of this and am looking for a way to disable the script that's doing this. Any ideas? jcgoble3 (talk) 21:49, 15 December 2012 (UTC)
I did. Most of that page deals with how to work with the changes from bugzilla:33123. There's nothing there about whatever script this is, which is far older than the $wgShowUpdatedMarker change. jcgoble3 (talk) 23:00, 15 December 2012 (UTC)
That's off, and again, that deals with $wgShowUpdatedMarker, which I actually use and want. This JavaScript is something totally different that has been around since at least January 2011. I know I did not do anything to turn it on; it was on from the moment I created my account. I'll get a screenshot for you guys in a few minutes. jcgoble3 (talk) 00:09, 16 December 2012 (UTC)
(edit conflict) Here's a screenshot. The top half of the image shows the watchlist as it is loading, with this page correctly not bolded because I have visited this page since the last change (indeed, the last edit was my own). The bottom half shows my watchlist after it completed loading, with the entire WP:VPT line and the entire line for my last edit now annoyingly fully bolded because that edit was made after the last time I loaded my watchlist. The fact that the bolding does not occur until after the page completes loading tells me that this is being done my JavaScript. If I use the "Inspect Element" feature of Firefox 17.0.1 to examine the HTML, I see that inline CSS has been added to the <td> of the VPT line and the <tr> of my last edit. jcgoble3 (talk) 00:33, 16 December 2012 (UTC)
reply to Anomie OK, then if that script is the problem, then which parts of that script do I copy over to get just the top-of-page notifier line? I want to keep that but get rid of the watchlist bolding. jcgoble3 (talk) 00:38, 16 December 2012 (UTC)
Looks like User:Ais523/watchlistnotifier.js would benefit from updating to accommodate the updated marker; probably excluding rows which have the class mw-changeslist-line-not-watched. I don't know enough JavaScript to comment more specifically.
As an aside, I think this illustrates a core failing of watchlists. The standard user interface ought to exclude edits made before a page was last visited, and also exclude edits that are listed on the watchlist when the "Mark all pages visited" button is clicked. (At present, the button also resets pages that were edited between the time the watchlist was generated and the time the button is clicked, so very recent edits are wrongly marked as visited even though they have not yet shown up on the user's watchlist.) See Bugzilla:4903#c7 for a related feature request that has been open for nearly seven years.
Screenshot of how Special:GettingStarted appears just after you've registered
Hi all,
Today we've launched the first preliminary version of a new way to try and get newly-registered people up to speed.
Right now, only between 20-25% of registered accounts ever edit,[17] even once. We'd like to improve that fairly dismal rate. Our first experiment is aimed at helping users who sign up, willing to edit, but who don't have an idea of where to get started editing.
To help those editors get started, we're presenting newly-registered users with articles gathered by SuggestBot from the copyediting backlog, optimizing for shorter articles that are easier to edit. In the future we will continue to tweak and optimize the task list, either by adding other easy task types, or reducing the number of choices new users have to make. We also have future plans for adding helpful tools, such as tooltip-based guided tours of how to edit.
Feel free to take a look at the Special:GettingStarted page now, though it appears slightly differently for users who just registered, so check out the screenshot to the right as well. Please let us know if you have any questions or feedback, and I'll keep folks updated as we iterate on this idea. If you're interested in more detail, our product requirements and analysis plans are available to read. Steven Walling (WMF) • talk00:38, 14 December 2012 (UTC)
Looks neat. Is the extension pulling off a wiki-page that SuggestBot updates? If so, which page is it? And per WP:BEANS, is that page at least semi-protected? How often is the list updated? (If this is answered somewhere else, sorry about that!) Legoktm (talk) 03:04, 14 December 2012 (UTC)
Aaaand the bots keep going back and forth. It's actually important that we leave out the padlock, since the template is transcluded. It doesn't seem the padlock gets transcluded in to the MediaWiki message, so it's not a real UI problem. However, we probably want the bots to quit edit warring. ;) Steven Walling (WMF) • talk07:26, 14 December 2012 (UTC)
Sorry about causing this, the script updating the template page isn't sophisticated enough to prevent this issue. I've stopped the bot for now and will rewrite its logic so it doesn't touch the padlock template. I'll probably also move the notice about SuggestBot updating the template from the talk page in the process. Should be going again in a few hours. Cheers, Nettrom (talk) 16:15, 14 December 2012 (UTC)
I've implemented a fix that keeps the <noinclude>...</noinclude> sections intact while the list might get replaced. I've also made the bot less insistent on editing regardless of the circumstances. Should hopefully keep everything running smoothly from now on, otherwise I'm sure someone will get in touch again. Cheers, Nettrom (talk) 19:01, 14 December 2012 (UTC)
For me, the "How to help / Fix spelling and grammar ..." box spills about half-off the right side of my screen. Using a 1024x768 resolution with Chrome on XP. Chris857 (talk) 03:34, 14 December 2012 (UTC)
OT (for here, anyway), is there a discussion somewhere about finding the reason for this surprising (to me) statistic? It's hard to imagine 75% of people bothering to register are just overwhelmed. I wonder if there is some other reason people would register and not edit. Other than giving you a personalized watchlist, what benefit would there be to registering if you are just reading? —[AlanM1(talk)]—17:14, 14 December 2012 (UTC)
this seems to me like asking for trouble and frustration. imagine what will happen when, say, 455 new editors will be presented with the same list of 10 "article for improvement". if 10% will respond, the many edit collisions that will ensue is a fire-safe method to guarantee huge amount of frustration.
one way around it is to find some way to "personalize" the list, i.e. distribute the articles among the users in some clever way. complete randomization will not be good - you do not want to present to the user a whole new list every time she goes to Special:GettingStarted, but presenting the same list to everyone can cause trouble. קיפודנחש (aka kipod) (talk) 17:36, 14 December 2012 (UTC)
The frequency of updates is something we can tinker with. It's also in our roadmap of potential features to add a 'refresh' button on the page, allowing people to skip through multiple article sets. We'll also have a sense of the rate at which people are trying to edit, but running in to edit conflicts or other problems (we're anonymously tracking article edit attempts and save attempts or previews, in addition actually saved edits). Steven Walling (WMF) • talk19:52, 14 December 2012 (UTC)
twisi, the idea of presenting to the whole english speaking crowd a set of 10 articles and asking them "edit these", does not make sense.
if you won't get enough response to create collisions then the whole effort probably isn't worth it, and if you *will*, you'll just frustrate the participants. peace - קיפודנחש (aka kipod) (talk) 20:05, 14 December 2012 (UTC)
You can click the image to see a larger version. Once at that page, click the "Original file" link to see the image at its maximum size. (If your mouse pointer then turns into a magnifying glass when you hover over the image, you might need to click once more to see it at maximum size.) – PartTimeGnome(talk | contribs)16:55, 15 December 2012 (UTC)
"An administrator on Wikipedia should customize this message"
When I go to that page, I get a message that makes it look like Wikipedia isn't configured properly: "An administrator on Wikipedia should customize this message by editing MediaWiki:gettingstarted-msg." (See it for yourself.)
The linked MediaWiki page exists and has content, so the message is rather misleading as to the problem. The message should link to MediaWiki:gettingstarted-msg/en-GB, since I use en-GB for my language. This can probably be fixed easily enough for English variants by creating redirects at the /en-GB and /en-CA pages (admin needed). Or, if redirects aren't allowed in MediaWiki space, transclude the main MediaWiki:gettingstarted-msg page instead. However, I think the fallback message should be friendlier for users whose native language is not English. For example:
This page is not yet available in your language. The default language is shown below:
(Obviously, the "This page is not yet ..." bit should be in the relevant language. I note that the current "An administrator ..." message is always English, even if your language is set to e.g. French. I'm guessing this is because this is a new feature, and the guys at translatewiki.net haven't had a chance to translate it yet.) – PartTimeGnome(talk | contribs)23:11, 14 December 2012 (UTC)
as far as i understand, this message is shown to a new user immediately after signing up (i.e., creating a new account). as such, the user preferences can't have anything other than the default language for this specific wikipedia as "useLang". so the content of the message you see will show (in English) for new users on wikis that did not set MediaWiki:gettingstarted-msg, and do not have appropriate translation for the message in translatewiki. it is not a problem here. setting uselang to en-GB and then looking at the message is kinda silly test: once you reached the point of setting the user language, you are past the point of *actually* ever seeing this message... peace - קיפודנחש (aka kipod) (talk) 23:21, 14 December 2012 (UTC)
Kipod is correct. It's currently impossible for the intended audience (newly-registered users) to have set an alternate language when they view the page, because it is delivered before they have access to their preferences. Steven Walling (WMF) • talk00:04, 15 December 2012 (UTC)
When looking at someone's SUL accounts at Special:CentralAuth, it would be useful to have the table automatically sorted by edit count when the page opens. Does anyone know if there's a way to sort a table by a specified column in Javascript? Jafeluv (talk) 13:04, 14 December 2012 (UTC)
I don't think I should have to download something to watch a video. I don't feel safe downloading something from Wikipedia. Like anyone at all can watch new changes for whatever reason, the same is true for videos and programs. Every day my virus softwhere finds something new that some creep wrote. --69.3.114.139 (talk) 06:50, 15 December 2012 (UTC)
You're not downloading it from us. Depending on whether you want the program embedded in your browser or instead into an existing video player, and which one, you'll have your choice of downloading it from Mozilla, Microsoft, VLC, Real, Java, etc. See Wikipedia:Media_help_(Ogg). Someguy1221 (talk) 06:58, 15 December 2012 (UTC)
I don't need to download anything, because the internet browser that I use to read websites supports embedded video so I don't need any additional software. You didn't mention which browser and version you use, but if it's an older one maybe you could consider upgrading? --Malyacko (talk) 09:35, 17 December 2012 (UTC)
Partly corrupted image?
What's going on with File:Bethlehem Inn NO Vacancy.jpg? It appears to be partly corrupted; thumbnails sometimes download and sometimes don't. When I try to go to the 250px thumbnail, I get a message of "503 Service Unavailable [line break] The server is currently unavailable. Please try again at a later time. [line break] There was a problem while contacting the image scaler: [Errno 110] ETIMEDOUT". When I uploaded it, neither the thumbnail (same resolution as the smaller image here) nor the large-resolution image displayed on the file description page, but they've since started working properly. While the 250px resolution version is displaying fine here, it's not showing at WP:RDH. Nyttend (talk) 17:15, 16 December 2012 (UTC)
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.
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)
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)
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)
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)
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.
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)
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?
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)
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)
Many thanks for all the replies (and sorry for my own late reply). However, I'm not asking about algorithms or program code. I merely would like to know if there is an up-to-date register of ILL bots, and some basic documentation on what each of those bots does, not how it works or how it's implemented. Is any of that information available? --Robert (talk) 10:24, 4 January 2013 (UTC)
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? ❤ YutsiTalk/Contributions ( 偉特 ) 13:09, 18 December 2012 (UTC)
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)
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)
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)
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)
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)
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. RichFarmbrough, 23:35, 18 December 2012 (UTC).
Signing in from "New section" on a village pump and returning afterwards goes to "Edit" on the village pump
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/w/index.php?title=Wikipedia:Village_pump_%28technical%29&action=edit§ion=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)
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)
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)
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)
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)
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)
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)
If I compare [21] and [22] (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)
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.
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 (talk • contribs) 21:17, 17 December 2012 (UTC)
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)
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)
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)
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)
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)
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. RichFarmbrough, 12:01, 19 December 2012 (UTC).
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 - Talk01:50, 21 December 2012 (UTC)
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 [23]—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: [24].
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)
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)
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)
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.
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.
I'm not sure what route Redrose64 took, but here are the tricks I would have used:
Go to your link, so I see the same message you saw.
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.
Look at the source of MediaWiki:protectedpagetext, since the previous step showed "(protectedpagetext: protect)" (the bit after the colon is a parameter).
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)
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)
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)
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)
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)
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)
Can't expand sections in mobile version of this article
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)
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.
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)
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)
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)
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 SELECTMIN(job_timestamp)FROMjob; (the job_timestamp field was added in MW1.19). Could the siteinfo statistics API be extended to expose the oldest queued timestamp?
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
(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)
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)
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)
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)
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)
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)
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)
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. Graham8710:18, 22 December 2012 (UTC)
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)
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)
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)
How to count red links at User:West.andrew.g/Popular pages
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)
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)
"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)
The figure 6,929,572 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)
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)
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)
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,929,572), 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)
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)
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)
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)
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)
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)
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)
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,451,425") 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)
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)
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. SilverserenC01:19, 20 December 2012 (UTC)
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)
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)
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)
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)
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?
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)
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).
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)
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)
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)
Those who are active on Commons (the image hosting wikimedia wiki that's used to share files among all wimimedia wikis), may be familiar with Cat-A-Lot. This is an extremely powerful categorization tool. Basically, when viewing a category, it allows you to select some or all the pages and subcategories, and execute batch-operation on the selected pages, such as adding a new category, removing the selected pages from current category, moving them to a subcategory, moving them to a super category, or moving them to a new category. This tool was originally written by User:Magnus Manske, and then rewritten by a German wikipedian named de:User:DieBuche. the code is here: Commons:Mediawiki:Gadget-Cat-a-lot.js. this tool is especially useful when changing the structures of categories, e.g., when deciding to create a new subcategory, and then move (or just add) many of the pages in the original category to this subcat, or when there is a need to change category name: one creates the new category with the new name, and then, in a single batch operation, move all the pages from the old name to the new one. the help page for cat-a-lot is here: commons:Help:Gadget-Cat-a-lot.
Until recently, the tool in commons only worked with files, but not with regular pages. a couple of years back, i copied the code from commons to hewiki, and hammered on it enough so it agreed to work with regular articles. we've been using this tool in hewiki for a couple of years now, with great success. i believe some other wikis (specifically fawiki, maybe more) took this basterdize code and are using it.
over the years there were several requests, including in WP:VPT to import this tool to enwiki.
Well, the good news is that User:Rillke, added some new features to the Commons version of Cat-A-Lot, and specifically, taught it to deal with regular pages, not just files.
you can now use Cat-A-Lot in enwiki by adding the following 3 lines to your Special:Mypage/common.js:
Broken links to AFRINIC WHOIS service on contributions page for IP addresses
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? Graham8712:35, 22 December 2012 (UTC)
Hello,
I prepared you a script returning a text file with the relevant whois information, from the afrinic whois server.
This is http://toolserver.org/~dereckson/cgi-bin/whois-afrinic.tcl?ip=<IP>
Hi. Is there something like Twinkle that's just specific to nominating pages for deletion? I've long given up trying to nominate a page for deletion by hand, but my current workflow involves temporarily enabling Twinkle in the "Gadgets" section of Special:Preferences, nominating the page for deletion, then disabling the gadget. It's a bit much. I just need to be able to nominate a page for deletion with some kind of sane interface, but I don't need nine hundred other features. Is there a Twinkle lite somewhere? Or a dedicated page for deletion nomination tool? --MZMcBride (talk) 08:56, 24 December 2012 (UTC)
How about a button to load Twinkle when you need it? Something like:
I am not sure if anyone else is having this problem - but Wikipedia seems to be logging me out every 20 mins or so....meaning i notice I have to log back on every 20 mins.Moxy (talk) 23:14, 24 December 2012 (UTC)
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)
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)
Now, on 20 December, the new version of File:Tan.half.svg appears in the article, with the original 400px size. Because the image is not on Wikimedia Commons, then the stuck-image-cache problem is not limited to Commons images, but apparently any image in an article can get stuck, where only a new-size thumbnail will show the current image version, and using the old-size thumbnail will refuse to update for 24-72(?) hours. Follow progress at the related thread, "#No purging on newer version of images". -Wikid77 (talk) 04:52, 20 December 2012 (UTC)
At Talk:Town centre#Fatal exception of type MWException I supply some details about a repeated attempt to use an archiveurl in {{cite web}} as a replacement to a dead link detected via WP:reflinks. I've used archiveurl literally thousands of times but never received an internal error/red error box before.
Don't know if anyone would find this worth looking into but I thought I'd bring it to the attention of the village pump... 72.244.206.81 (talk) 09:59, 25 December 2012 (UTC) P.S. Note I did not set $wgShowExceptionDetails = true as recommended since an as IP editor I've never looked into whether I can set up LocalSettings.php.
Should be fixed now, the problem was with Swift storage for captchas which made everything requiring captchas (including account creation) fail. Max Semenik (talk) 11:08, 25 December 2012 (UTC)
I see it too, though instead of a text link, I get a broken image icon (Chrome). The file is correct in the direct upload.wikimedia link. Chris857 (talk) 19:58, 25 December 2012 (UTC)
Right-clicking on either text link and selecting "View Image" in Firefox brings up this URL, which says Error generating thumbnail - The source file for the specified thumbnail does not exist.jcgoble3 (talk) 20:49, 25 December 2012 (UTC)
Appending ?1 to the thumbnail URL brings up [26], which displays the image correctly even though there should theoretically be no difference between the two URLs. Perhaps a caching issue? jcgoble3 (talk) 20:53, 25 December 2012 (UTC)
Perhaps it's OK for you, but I still get the text links. I purged it myself (again, since I did so during my own investigation) and bypassed my browser cache, but it's still not working. jcgoble3 (talk) 20:58, 25 December 2012 (UTC)
Unfortunately, bots will occasionally become unavailable some times, not infrequently arouind the same time as their operators. This may be anything from a user deciding that {s)he can't afford to spend much time on Wikipedia, to a user's computer breaking down, to a user getting too sick to be able to be active here. I have no idea what happenned to Ummit; however, unless either Ummit will bring the bot back on line, or some other user runs a bot to do the task (the place to request this is Wikipedia:Bot requests), there is nothing anyone can do. עוד מישהוOd Mishehu18:07, 25 December 2012 (UTC)
I am looking in to trying to modify the following Template:referendum (a new template may be required or new possible parameters) this would be by being able to have the options "yes" and "no" replaceable with free-form options. This has come about in relation to UK Mayoral Referendums where the options are not a yes no but a choice between one of two different systems. Any help on the technical means of being able to do this would be very much appreciated. Sport and politics (talk) 01:19, 26 December 2012 (UTC)
First of all, excuse me if this is not the right place to post this, but I could not think of a better page to report it.
I have been told that the aforementioned template ruins the table layout if either "name" parameter or "article" parameter contain the string "!!" (without quotes). I have made a test; with an only exclamation mark in both parameters the template renders the table correctly but if I add the second exclamation mark on any of them (or both) the layout gets broken. Could anybody find a fix for this? Thank you in advance. --Canyq (talk) 16:45, 26 December 2012 (UTC)
Thank you very much for your idea: it's a clever workaround, but I was wondering if there is a more general solution to apply on the template itself because you know that trick, and now I learnt it, but each time a new contributor uses the template with a name including "!!" will struggle to make the table be displayed correctly. I mean perhaps there is a parser function or something like that which applied on a parameter string makes special characters be treated as plain text instead as a part of the table. --Canyq (talk) 18:59, 26 December 2012 (UTC)
Do you have an idea of how to make create automatically by this user the categories needed to the Babel extension? Should be required at Bugzilla? Thanks Raoli (talk) 17:24, 27 December 2012 (UTC)
i do not believe you need to do anything. afaiu, what this pseudo user does is tell the bable extension to automatically create a new category as soon as there is a user with this language/level combination. e.g., at the moment there isn't a single user in enwiki claiming to have level 4 in Newar (a Nepalese language, language code "new"). as soon as someone will place in their user page the template {{Babel|new-4}}, the extension will automagically create Category:User new-4. i might be mistaken, of course, but i am 84.63% confident that my description above is correct. peace - קיפודנחש (aka kipod) (talk) 18:07, 27 December 2012 (UTC)
this is an extension. i do not believe an extension (you can see it in Special:Version) qualifies as "bot". the extension code is not run by some user with some account, but rather directly on the same server that serves us the pages, so i don't see how one can classify it "bot". peace - קיפודנחש (aka kipod) (talk) 18:26, 27 December 2012 (UTC)
(edit conflict)I believe you misunderstand it. It’s not a bot. The categories are created automatically by the MediaWiki software (the Babel extension), it’s just that this autocreation has to be recorded as an edit in the database, and these virtual edits are labelled as if they were done by User:Babel AutoCreate. The user does not actually do anything.—EmilJ.18:29, 27 December 2012 (UTC)
What EmilJ and קיפודנחש said here and what I tried to say on ANI is indeed accurate. This is not a bot but rather a pseudo user created to take credit for edits made by a MediaWiki extension and it is fully authorized by virtue of being deployed by the m:System administrators. SnowolfHow can I help?18:35, 27 December 2012 (UTC)
i do not believe there is anything wrong with the extension (let me rephrase: i do not believe that failing to create Category:User simple-2 points to a problem with the extension). as far as i could see, the extension does not believe there is a language named "simple", and more specifically, there is no known Language code associated with "simple". the extension *does* recognize some 7,700 languages, with one or two codes each; "simple" is not one of them. if there should be such a code, methinks you should discuss it on mw:Extension talk:Babel. peace - קיפודנחש (aka kipod) (talk) 21:57, 27 December 2012 (UTC)
Looking for this to appear but without the term "Title" to appear when rollingover the abbrevation:ia
So only "$1 million Inflation Adjusted" to appear.
Any help would be appreciated! Market St.⧏ ⧐ Diamond Way03:42, 28 December 2012 (UTC)
Thanks for the quick response, I am running Opera (latest download) on a Windows OS. So it displays as: "Title: $1 million Inflation Adjusted" also just checked your statement in Chrome it seems your right might just be an Opera browser thing, any way to solve the issue for potential Opera viewers? Market St.⧏ ⧐ Diamond Way05:56, 28 December 2012 (UTC)
just tried with opera 12.12, and i do not see the "Title:" part of the hint. it may be a strange combination of something in your user account + opera. can you please test it again when logged out? also, what exact version of opera? do you have any add-ons installed on the browser? peace - קיפודנחש (aka kipod) (talk) 06:11, 28 December 2012 (UTC)
Thanks so much for your assistance! That is all the info I need . . . if its just my or 2% of the views out there not concerned, just was concerned before I made several edits with a code that would have to be re-edited later. I'll work on checking my Opera settings later, not sure the version but have installed the most recent updates, no matter thou. For my big concern you did a great job answering this, feel free to mark resolved and thanks again! Market St.⧏ ⧐ Diamond Way07:11, 28 December 2012 (UTC)
{{abbr|ia|$1 million Inflation Adjusted}} produces the wikicode <abbr title="<nowiki>$1 million Inflation Adjusted</nowiki>">ia</abbr>. It renders as ia. The html source of the rendered page says <abbr title="$1 million Inflation Adjusted">ia</abbr>. It all looks correct to me. See http://www.w3schools.com/tags/tag_abbr.asp. My Opera 12.12 on Windows Vista doesn't display "Title". I don't know why yours does. Try the "Try it yourself" link at http://www.w3schools.com/tags/tag_abbr.asp. The mouseover for "WHO" says "World Health Organization" for me with no "Title". Does that case also say "Title" for you? PrimeHunter (talk) 19:36, 28 December 2012 (UTC)
Purging is not enough. It often requires a null edit (or any other edit) of a page to update which categories it is displayed in. Talk:Land's End to John o' Groats has not been edited since 2010. The category added by the template was changed 21 July 2012.[27] Five months is the longest delay I have heard about for a couple of years. Something may have gone wrong in this case. PrimeHunter (talk) 10:46, 28 December 2012 (UTC)
I've just spotted a bug in the styling of edit summaries when displayed in the watchlist, page history and in diffs. If the edit summary contains a section heading created with the code /* SomeSectionHeading */, then any spaces afterwards are interpreted literally, but the closing bracket of the edit summary appears as if the spaces weren't there. This results in the edit summary appearing over the top of the closing bracket and the undo link, etc. (I've tested this in Chrome.) I first noticed this problem here and was able to reproduce it in my sandbox several times. Is this a known bug? It seems to be fixed on the test2 wiki but I couldn't find it in bugzilla. — Mr. Stradivarius(have a chat)11:10, 28 December 2012 (UTC)
Ah, ok, thanks for telling me. I thought that I might have been the first person to notice it, but it makes sense if it's a Chrome bug that they haven't fixed yet. — Mr. Stradivarius(have a chat)14:45, 28 December 2012 (UTC)
The infobox for women's national basketball teams {{Infobox women's national basketball team}} apparently was designed for the senior team, which will compete at the Olympics. There are other national teams, e.g. USA Women's U16 and U17 teams, and USA Women's Pan American Team which will not compete at the Olympics.
However, it appears that an entry is added to the infobox for the Olympics, even if no parameters are passed.
I would like to learn one of the following:
Learn if there is a way to suppress the Olympic games section, without changing the template
Learn if there is a way to modify this template so it can be used for both the senior and other teams (in other words, change it so the Olympic section is optional (as well as the world championships, so it could be used for Pan Am which aren't world championships; the zone championship will work fine)
Learn how to create another template for non-senior teams, if it isn't appropriate to change the main template
My original plan was to create the original author, but that editor is on wikibreak.
The first question is relatively easy: looking at the current coding of the template, there is no way to suppress the Olympic Games section.
As for learning how to make the change, I'm eager to practice template coding myself, so I've experimented with a copy of the template in User:John of Reading/X3. I've implemented a test for "oly_appearances=N/A" using the #ifeq magic word; the actual changes needed are worse than this because all the pipe symbols in the table markup have to be replaced by {{!}} to avoid confusing the #ifeq. There's test data in User:John of Reading/X2.
The proper place to discuss this is probably the template talk page, with a brief link at VPT to attract attention to it if no-one responds. That way, the history of the template would be easier to follow. But never mind, we're here now. -- John of Reading (talk) 21:40, 28 December 2012 (UTC)
My friend Polymorphism wasn't able to log in, so she used the link to have a new password emailed. It said that it was sent, but she never received it. She's checked her Spam folder. Does she have any recourse at this point, or will she have to create a new account? Nick Number (talk) 19:13, 28 December 2012 (UTC)
as far as i know, the "password reset" did not yet happen: only by clicking on a special link that's sent with the "Reset password" email, the reset actually occurs. so she has 3 venues open to her:
if she will recall the old password, it should still be usable, even though she clicked the "Reset password" thingy.
she can click it again, hoping that on the 2nd attempt it will work, even though it failed on the 1st.
and lastly, as you noted, "the nuclear option" is to re-register with a new user name.
please note that my description is based on my theoretical understanding of the process - i've never actually tried it myself, so i may be awfully wrong. peace - קיפודנחש (aka kipod) (talk) 20:54, 28 December 2012 (UTC)
Actually, there's another option: register under another username, edit a bit, and then WP:USURP the old one. Are you sure you've got the username correct? Only that one has no edits - which is why it can be usurped. Grandiose(me, talk, contribs) 22:48, 28 December 2012 (UTC)
ToolServer
Hi dear all
it's some days i face to below error message when i want to run my bot on Toolserver. Is here someone who know what's the problem?
Regarding your problem on Toolserver, I don't know much about Toolserver, but to check the obvious, how much disk space are you using on Toolserver? (E.g. run "du -sh ~" from a shell prompt on Toolserver.) – PartTimeGnome(talk | contribs)00:51, 29 December 2012 (UTC)
And below the section heading is {{shortcut|WP:POVFORK|WP:POVSPLIT}}, which creates anchors. If you use WP:POVFORK as the link, then the redirect will work regarless of the section heading. --— Gadget850 (Ed)talk02:55, 29 December 2012 (UTC)
I suspect the issue may be the simple fact that the Malay template page is not protected. The template is designed to only show up when the page is actually protected, otherwise it shows nothing and categorizes the page into Category:Wikipedia pages with incorrect protection templates—and the Malay template page itself is in that category because the category is not in noinclude tags (which there's no need for on the English version because the template is protected and thus doesn't trigger the category here). Simply protecting the template page (even semi-protection) will likely cause the template to come out of hiding. jcgoble3 (talk) 02:38, 27 December 2012 (UTC)
I am working on list of people with various sortable columns which I would like to appear in alphabetic order by their last names. If I enter the names as, for example, "John Able", "Mary Baker", "Edward Charles", and "John Doe", then the list will sort by first name. Should I enter the names as "Able, John", "Baker, Mary", "Charles, Edward", and "Doe, John", or is there some hidden mark-up to use that will let the names be sorted by last name? Thanks! Location (talk) 15:11, 29 December 2012 (UTC)
I had difficulty enabling feedback protection for 1272; see here for a permlink to the discussion (scroll down a little to 1272). Short version: feedback protection works inconsistently. Has anyone else seen this behavior? I'm thinking of doing a little testing and filing a bug report. Thanks, Mackensen(talk)15:39, 29 December 2012 (UTC)
Etymology of Psychotronics and a technicism about it?
Do you think that the Grecian linguistic root of the word Psychotronics: (from Ancient Greek ψυχή 'breath, soul, spirit' and ἤλεκτρον 'amber, electron') needs a reliable source, in order to justify its presence in a Wikipedia page? Is there a problem with the corresponding template?--Paritto(talk)04:21, 30 December 2012 (UTC)
If someone is asking for a source for it - yes, it needs a source. "All quotations and any material whose verifiability has been challenged or is likely to be challenged, must include an inline citation that directly supports the material" - from Wikipedia:Verifiability. The etymology has been challenged - and if we are to provide one, find a source for it. Given that you seem to have added the etymology in the first place, it shouldn't be too hard for you to cite the source you got it from. And no, the fact that we don't state that a source may be required in the template documentation is of no significance: Wikipedia:Verifiability is policy everywhere within an article. AndyTheGrump (talk) 04:35, 30 December 2012 (UTC)
Dead horse
Sorry to keep beating the proverbial deceased equid, but my complaint about the bug in the B function has not been addressed, except for one other editor confirming that it is a bug. To see what I mean, just click on the B and see what you get: five single quotes. Kdammers (talk) 06:59, 28 December 2012 (UTC)
Sorry for not specifying, but I only see on B' when I'm editing, as no. As I stated and another editor confirmed, does not work fine. It prints out five squotes when it is clicked on unless a text has already been selected. Kdammers (talk) 07:45, 29 December 2012 (UTC)
I'm sorry, but I don't understand what you are saying. At Help:Edit toolbar, when I log out, I get a frozen page (i.e., buttons are inactive). The text there says, "If you click a button without selecting any text, sample text will be inserted at the cursor's position (like so: Bold text). " This is also not what happens. What happens to me is that the five squotes appear in a gray field in which I cannot type until clicking some-where or hitting the space bar. If I click in the gray area, to type some-thing, I have to add a squote to get bolding. Kdammers (talk) 05:11, 30 December 2012 (UTC)
I see. It is the former. I checked the latter, and it works properly. Also, when I edit on Simple English, it works properly. Thanks for looking into this. I hope the bug gets fixed. 202.179.19.10 (talk) 03:25, 31 December 2012 (UTC)
Easy table editing
Is there a way to easily edit wikitables, such as add or remove a column without having to go thru every single row? Heck is there a Dreamweaver type deal for wiki editing? Please talkback me when you respond because I might forget to come back here. Thanks.--Metallurgist (talk) 13:50, 29 December 2012 (UTC)
This has been brought up before. Here's a quick summary of the previous discussion: The VisualEditor will eventually allow WYSIWYG editing of tables, but doesn't do it yet. Wikid77 mentioned some tools for using wikitables in MS Word and Excel, though I'm not sure where to find these tools. Such tools would probably be more useful for creating new tables than editing existing ones, since I'm not sure they would fully preserve existing wikicode when converting to MS Word then back again (round-trip format conversion). – PartTimeGnome(talk | contribs)14:49, 29 December 2012 (UTC)
Sounds like the answer is not yet, but soon. I thought I had read that there was a few years ago, but I guess not. That Visual Editor sounds like it will be great. I just rotated a table from like 25 columns to 25 rows and it took hours, but it certainly looks better now and will be easier to manage. It was overdue by 5 years (back then it wouldve been a bit easier too with less columns). Now I have to eliminate two columns from a table, which involves digging thru dozens of rows. Thanks for your help.--Metallurgist (talk) 02:45, 31 December 2012 (UTC)
Footnotes in templates
Hi, the template {{katakana table}} previously used an arcane and unfriendly footnote style, which I recently changed to the "<ref>" style. It is required that the footnotes in the table are expanded immediately beneath the table when the template is included in an article. To that end, a <references> section is included at the end of the template. However, it has become apparent that unless the template uses a unique "group" in its "<ref>" tags, the references/footnotes for the whole article up to that point are expanded beneath the table. This is not what is required: the references/footnotes for the main article need to be kept separate and expanded at the end of the article. At the moment, by luck rather than judgement, the template footnotes do indeed have a unique "group". However, I would prefer to get rid of this and have a plain numbering system (i.e. [1] rather than the current [† 1]), which I currently cannot see how to do. An additional problem is that the article Transcription into Japanese includes two tables, {{katakana table}} and {{katakana table extended}}, both with their own separate footnotes. If I update {{katakana table extended}} to also use the "<ref>" style, rather than the peculiar existing style, then presumably I will have to choose another unique "group" name, which is undesirable since the visual appearance of the footnotes should be the same in both tables. Can anyone advise on the recommended way to handle this? 86.130.66.65 (talk) 03:14, 30 December 2012 (UTC)
The groupnames showing in the reference link is inherent to how references work, see WP:REFGROUP. You could use "lower-alpha" as the groupname and have single letters in the ref labels. — Edokter (talk) — 12:45, 30 December 2012 (UTC)
Note if you go the "lower-alpha" route, you can use the same thing in both templates because each template will "clear" the refs with its own <references group="lower-alpha" />. Conflict will only arise if an article tries to use the "lower-alpha" group for its own purposes. Anomie⚔14:17, 30 December 2012 (UTC)
Thanks for the replies. Unfortunately, because of the nature of the information in the table (e.g. including IPA pronunciation codes like "[a]" and "[i]"), going the "lower-alpha" route would be too confusing. Is there no way I can have numbers like [1], but kept separate from the series in the main article? (The original method achieved this, but only at the expense of an unfriendly syntax that made maintenance a real pain.) 81.159.111.255 (talk) 14:56, 30 December 2012 (UTC)
You can also try "group=decimal". Scrap that, that will cause the article refs to be included. There are several options you can choose from, standard decimals is just not one of them. — Edokter (talk) — 15:19, 30 December 2012 (UTC)
Ok, is it possible to introduce the complete language, i.e. any kind of command, not just formulas? May you suggest me in which way? Is it feasible to "convert" Latex into Wikitext?--Paritto(talk)05:17, 30 December 2012 (UTC)
Am I correct in assuming that Snotbot(task list·contribs) is no longer functioning, subsequent to Scotty's departure? At User:Snotbot/RFPP, BOT_RUN is set to "Yes", but Scotty's announced that he's shut down all of his bots and tools (which is definitely true for the tools), and Snotbot appears to be overdue on its tasks - see this RPP, for instance.
I've come up with a working solution for RFPP. See here. To all users who know javascript - please please please find a way to fix the rolling archive issue I explain there.
But speaking of people who know how to program, I'd really like to know how long it'll take to get a new bot on the job. Does anyone have a copy of Snotbot's source code? And, if so, was it licensed in a way that it could just be folded into a new bot? — Francophonie&Androphilie(Je vous invite à me parler)09:33, 30 December 2012 (UTC)
This seems like a pretty compelling case for us not tying the running of tools to individual users. Perhaps if this can happen another fifty times, someone at the Foundation will see a compelling use case for actually fixing this. —Tom Morris (talk) 12:04, 30 December 2012 (UTC)
If Scottywong approved, and gave me the source code, I have a Python instance installed, and run an adminbot using a python script. As this is not an admin task, I do have other inactive bot accounts that could take over the task. This would not require a new BFRA as the task is approved (✉→BWilkins←✎) 12:37, 30 December 2012 (UTC)
Actually, I think it would. I would gladly take over the bot, but I don't do much python. I'll see if Scottywong is willing to give up the code.—cyberpowerChatOffline14:22, 30 December 2012 (UTC)
I gave someone a 3RR warning because their last edit was [[28]" which has the edit summary "(Undid revision 530265298 by Mikenorton"]. The editor doesn't understand this nor do I, as looking at the article the addition of a see also didn't revert its removal as revision 530265298 didn't have anything to do with the see also. It's a bit embarrassing to find that it wasn't a revert. I trusted the edit summary to be correct - is this a glitch or something we always have to be wary of? Dougweller (talk) 07:44, 30 December 2012 (UTC)
In theory, I can click "undo" and do anything with the edit (leaving the last edit in place and adding a line, as happened in this case), and unless I change the edit summary manually, it'll stay as Undid revision 123456789 by Username (talk). I can also do whatever edit I want and use that edit summary manually. Perhaps the user initially clicked undo to revert the last edit, changed his mind when he realized he was about to violate 3RR, and instead made a good edit but without navigating away from the page or fixing the edit summary to something else? I'm also concerned this might be a way to prove a point, although I'd obviously rather assume good faith from all parties and see no reason for that particular assumption. Salvidrim!10:09, 30 December 2012 (UTC)
Thannks,that makes sense. Good faith would be nice too, but the editor involved is continuing to accuse me of abusing the 3RR template. Ah well. Dougweller (talk) 11:49, 30 December 2012 (UTC)
Spam filter rules
I just tried to add a youtu.be link to communicating sequential processes -- a recording of a technical talk by programming language designer Rob Pike. The spam filter then blocked my edit. That's all ok, as I got the regular URL in, but the spamfilter gave me no contact info -- I'd like to know to whom I should direct questions regarding the filter? Qwertyus (talk) 11:48, 30 December 2012 (UTC)
... which will be denied in the case of youtu.be, because it is trivial to use a direct link to youtube.com instead. The same goes for any other shortener/redirector. Anomie⚔17:25, 30 December 2012 (UTC)
I suspect the problem is generated at {{Colevel/item set}} or related template. What I see is that a whole table row with an arbitrary number is generated, but I can't trace it's origin. — Edokter (talk) — 17:42, 30 December 2012 (UTC)
Restored column-width format in {Colevel/display_item} for alpha/beta pairs: I have restored the table cell-width logic, as in the 2008/2009 calculations, for the column-width format in those 2 templates, {{Colevel/process_item}} and {{Colevel/display_item}}, which I had edited on 22 November 2012. I hope that fixes all the problems for the prior month. Apparently because the template had lacked documentation, I did not realize how the template was being used and was over-zealous in simplifying the format of the 2-column pairs, as used by the upgraded Template:Autonumbered_list (which I have bypassed with new, fast Template:Autotable5_big). Sorry for the conflicting changes. I suspect that Wikipedia should adopt minimal template-documentation standards, so that templates, in use for years, would no longer seem like experimental hack templates, but instead, link to text which explains the purpose, operation, and major applications with other templates. Currently, Special:WhatLinksHere/Template:Colevel/process_item does not provide sufficient background information to clearly warn of other applications which might be affected by changes, such as by free-form alignment of table columns. We need more comprehensive documentation to wade through Wikipedia's vast primordial swamp of millions of once-upon-a-thought templates. I can forsee that pre-approved templates could stiffle innovation or hinder the offshoot improvements, but the current avalanche of teaming multitudes (of questionable, partial, undocumented templates) has led to a maintenance nightmare to prioritize changes, or even find a functioning utility template in the overwhelming ocean of current templates. No wonder there were formerly over 16,000 pages which were linked to the category for pages exceeding the expansion-depth limit of 41 levels. Template usage is basically out-of-control, and needs some more standards for documentation. -Wikid77 (talk) 21:27, 30 December 2012 (UTC)
Thanks for sorting this out. There probably does need to be some sort of version control and obligatory documentation update needed especially for templates. Updating the document probably isn't enough as that's about what it does for the lay user like me; but some sort of technical change log is needed so that the experts like you realise what has been intended in the past instead of having to guess and occasionally getting it slightly wrong. NtheP (talk) 22:11, 30 December 2012 (UTC)
Different backround color
I took the liberty of injecting this solution at the top of the article.
It would be easiest for this person to adjust his display brightness, which if lowered a bit, will be a permanent and manageable solution. Display brightness would apply at all times without having to code/configure applications.
Windows has a display brightness slider control somewhere in the control panel, you may have to dig for it, either in mobility settings, power settings, or somewhere else in the control panel. Not sure about the Mac or Linux Boxen.
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)
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.):
One of the benefits of having an account on Wikipedia is that you can give yourself your own custom CSS stylesheet, or webpage layout design. If you register an account here, this allows you to add the code that kipod posted to your custom CSS page, located at User:(insert your username)/vector.css. That code will set your background to a much less harsh color. (X! · talk) · @300 · 06:11, 24 December 2012 (UTC)
Vector is one of several skins that Wikipedia provides. For users who are not logged in, it is the only one available for normal use (although you can try out others - for example, this page looks like this when viewed in the MonoBook skin); and for users who registered since about May 2010, Vector is the default, but may be altered.
But you need not worry about whether you're using Vector or not; once you have registered an account (and are logged in), go to this page, paste in the code shown above, and save it. The link that I have just given will work whatever your login name is, and also regardless of skin. --Redrose64 (talk) 11:40, 24 December 2012 (UTC)
Sorry but that's just too complicated. For being the most popular website on the internet can't wikipedia make it a lot simpler to do this? It's a miracle I got to this technical support page. Now you want me to become a programmer? — Preceding unsigned comment added by 24.61.9.111 (talk) 18:41, 24 December 2012 (UTC)
To summarise: in order to customise the appearance of Wikipedia, you need to register an account. If you don't do that, you can't choose a different background colour, because IP addresses like 24.61.9.111 cannot be customised.
I wiil make this offer: if you do register an account, log in and then post here requesting that somebody set up your account so that all the page backgrounds become this colour - or any other colour that you like - I will gladly do that as soon as I can. But I cannot do that without knowing what name you have registered under.
Please bear in mind that I will not be available on 25 December, 31 December to 1 January, or between 23:00 and 11:00 (British time) any day. --Redrose64 (talk) 19:59, 24 December 2012 (UTC)
Another option: Rather than using CSS, you can get green text on a black background by creating an account, then setting just two options in Preferences: First, set Preferences → Appearance → Skin = MonoBook, then scroll down to put a check next to Preferences → Gadgets → Appearance = Use a black background with green text. Click the Save button at the end of the page to save your changes. Before you can set any preferences, you must first create your account (click the link and follow the instructions).
If you don't want to create an account, look through the settings in your web browser for an option to always use your preferred colours. The exact name and location of this option depends on your browser. This will affect all websites you visit, of course. – PartTimeGnome(talk | contribs)21:44, 24 December 2012 (UTC)
If you're using Firefox, you can also try the Stylish extension (try googling it), which will work regardless of whether you register and log in. More generally, you may wish to look into a solution that dims the display on your PC more generally. - Jarry1250[Deliberationneeded]15:43, 28 December 2012 (UTC)
Closing slashes
Unresolved
http://en.wikipedia.org/wiki/Cheese/ (for example; with a closing slash; see Cheese/) returns a 404 response and invites the user to create a new article. Should we not redirect such URLs to the version without the closing slash (http://en.wikipedia.org/wiki/Cheese)? Do we have any articles where the closing slash is a significant part of the article name, and how could we cater for such a small minority of cases? Is this perhaps something for MediaWiki, via Bugzilla? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits18:16, 26 December 2012 (UTC)
I don't see the benefit; /Cheese is a page, while /Cheese/ is a directory. I don't see any other webpages ending with "/index.html/". — Edokter (talk) — 19:18, 26 December 2012 (UTC)
I don't see what "/index.html/" has to do with this, as none of our article titles end in ".html"; nor why /Cheese/ has to be a directory. There are a good many sites where /foo/ and /foo are synonyms. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits19:23, 26 December 2012 (UTC)
We have 171 titles in namespace 0 (the main encyclopedia) ending with a forward-slash (/). Of these, 55 have corresponding titles with no slash at the end. In most cases the slash-less title is the target of a redirect from the slashed one (for example James Clerk Maxwell/ → James Clerk Maxwell), although some pairs are distinct (for example Apple_Monitor_/// / Apple_Monitor_///, F/ / F, Home/ / Home). Nothing that couldn't be worked around if the logs show a compelling need for this change. - TB (talk) 22:55, 26 December 2012 (UTC)
Despite being 404, Cheese/ has been viewed 27 times in the last 90 days; not counting today. Barack_Obama/ has been viewed 504 times in the last 90 days. Internet/ has been viewed 4209 times in the last 90 days. I think there's an issue here which we can resolve to the significant benefit of our readers, with a simple(ish!) server config change. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits23:21, 26 December 2012 (UTC)
When you go to a redlink like Thing (comics (note the unclosed parenthesis), a helpful "Did you mean" message directs you to Thing (comics). (Your language in preferences must be set to English for this to work.) Something similar could be done if removing the final character (regardless of what it is) results in a valid page name. The wikicode that generates the current "did you mean" is at MediaWiki:Newarticletext and Template:No article text. Changes would require an admin, of course. – PartTimeGnome(talk | contribs)00:14, 27 December 2012 (UTC)
View larger image with description upon mouse click.
When pressing the 'enlarge' button on an image the user is unable to view the description associated with the image, this is particularly inconvenient when viewing labelled diagrams.
Proposal: Using simple JavaScript code clicking on the enlarge button should expand the image to larger size with the description still visible; a second click should redirect the user to the 'File:' page.
Great idea but perhaps conflicts with current plans: I like that image-enlargement idea, and almost ten years ago, I had dynamic enlargement (20%) for mouseover response on images in websites which I developed. However, changing the underlying structure, to have hidden thumbnail centers 20% larger, to flash-display during button-click, might interfere with operations for sight-impaired users. Instead, I have put "right-click" links in the image-caption text (of some articles), to tell readers to click those text links for enlarged, or related, or animated/video images. There is no reason that a caption cannot contain 5 lines of text to explain various, optional right-click links. Meanwhile, sight-impaired readers can still depend on a single image-click to display the full description page of an image which they might be unable to view clearly. -Wikid77 (talk) 21:55, 30 December 2012 (UTC)
Would having a hidden div that would be filled with the relevant HTML code upon mouseclick cause problems for sight impaired users? Just to be clear the lightbox link was just an example, I think we could achieve a similar effect with more simplicity. I agree with your "right-click" concept, but this would be a more universal solution. Obviously we will need a beta test before publishing the code, but surely that is true of any technical update to the encyclopaedia? -HeavyQuark (talk) 10:16, 31 December 2012 (UTC)
Not sure about the "why", but you can check status.wikimedia.org to see the status of things. (dunno if it has more information when a project goes down) EVula// talk // ☯ //02:41, 31 December 2012 (UTC)
Generally, if the site is down you can expect the topic in #wikimedia-tech on freenode to state why. Additionally, the server admin log will usually have the log messages from ops as they deal with the outage. For widespread outages, the @wikimedia account on Twitter tends to provide updates. Post-mortems from downtimes can usually be found on the blog (or discussions on wikitech-l). ^demon[omg plz]15:33, 31 December 2012 (UTC)
Template event list
It seems the template outputs an error as soon as the list of dates is strictly less than 25 (I know it sounds weird, just my theory...). Have a look at Oscar Werner Tiegs. The use of event list seems perfectly correct, however only an error is displayed. Vincent Lextrait (talk) 03:59, 31 December 2012 (UTC)
On 21 November 2012, User:Wikid77 edited the subtemplate {{Colevel/find first}} and seems to have introduced a logical error so that it wrongly returned 51 as the first item if item 25 was not specified. I have attempted to fix the error. See also the above section (#Template:Overlay) about similar errors with related subtemplates that were affecting the Overlay template and which were fixed yesterday. Hopefully {{Event list}} and {{Overlay}} are now both working. — Richardguk (talk) 04:50, 31 December 2012 (UTC)
Yep, I know, I was the one reporting the Overlay bug at the Tea house. As I saw that it was reported here in turn, I came directly here... Thanks for the fix. Vincent Lextrait (talk) 12:30, 31 December 2012 (UTC)
Link to Wiktionary didn't work
Several times in the past, I have inserted links to the Wiktionary definitions of words when I have been editing Wikipedia articles. They have worked just fine, e.g. in Solar cooker#Parabolic troughs. However, this morning, I tried doing this is Fire#Chemistry and it didn't work. Is there any known reason why? DOwenWilliams (talk) 16:07, 31 December 2012 (UTC)
Your edit today was using the link in the form [[wikt:extinguish]]; the one before was [[wikt:single curve|single curve]]. This is a piped link, which displays the second element ("single curve") rather than the link itself ("wikt:single curve"). To make the first one look clean, you'd want to use [[wikt:extinguish|extinguish]]. Andrew Gray (talk) 16:15, 31 December 2012 (UTC)
Or you can use the pipe trick, which means that the text [[wikt:extinguish|]] is automatically expanded into [[wikt:extinguish|extinguish]]. It just saves a little time. Graham8706:07, 1 January 2013 (UTC)
After a username change, some pages did not get moved
It didn't. So I called a second ambulance that arrived, all lights flashing, driven by user Dreamyshade.
I told her what I had done so far on the advice of the first ambulance driver:
I have enhanced recent changes disabled (I suppose this is what you call enhanced recent changes: "Group changes by page in recent changes and watchlist (requires JavaScript)" and I do not have that checked in my preferences)
So I walked, all battered and bruised, to this Village Pump (it took me 2 weeks), and here I am. Can anybody help? Anybody here who's actually made this work? Signed: Basemetal (write to me here) 17:58, 31 December 2012 (UTC)
For more general use, you can achieve this in effect without using your watchlist, and instead creating a page in your userspace containing links to all the pages that you want to watch, then bookmark the Related changes link in the sidebar of that page. Then, instead of adding or removing pages from your watchlist, you add or remove links to them from your user page.
But note that talk pages are automatically added to watchlists for good reason. There is a risk that you might miss out on significant discussions or announcements affecting the pages!
I appreciate that this technique might not be well suited to you if you only want to hide Talk:Main Page.
please note that the test you used to see if the CSS "trick" works is the wrong test.
the css trick is supposed to hide the pages when you open Special:Watchlist, but it will *not* prevent the little star from appearing blue when you actually open the talkpage, nor will it remove it from the pages you see when you click "View and edit watchlis". the trick does not *really* remove the page from your watchlist - it just hides it on the page that opens when you click "Watchlist", namely Special:Watchlist. peace - קיפודנחש (aka kipod) (talk) 19:23, 31 December 2012 (UTC)
Thanks to all who responded. All fixed. Note, for those who want to try this but want "enhanced recent changes" enabled, that the line .watchlist-1-Main_Page{display:none;} needs to be replaced with .mw-changeslist-ns1-Main_Page{display:none;}. I'll also give user Richardguk's method a try some time soon. Thanks again to all who responded. Signed: Basemetal (write to me here) 20:29, 31 December 2012 (UTC)
Great, and I also was able to get the CSS to work (it didn't work at first – maybe I didn't fully bypass the cache). However, the CSS (as קיפודנחש said) only hides the page on the watchlist, but you are still actually watching the page. Thanks for the CSS trick, by the way – I hadn't heard of it before. The Anonymouse (talk • contribs)22:13, 31 December 2012 (UTC)
New HTML5 elements; custom data attributes
From the last MediaWiki update, we now have <data>[29], <markup>[30] and <time>[31].
I have also noted that MediaWiki will pass HTML5 custom data attributes.[32]
However, the documentation at Help:Sorting and elsewhere has only partly been updated, and most editors continue to apply more familiar sorting templates which use CSS to hide sortkey text.
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)
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)
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 [33] 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)
(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)
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)
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)
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)
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)
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)
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)
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)
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)
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. —Torchiesttalkedits18:37, 21 December 2012 (UTC)
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)
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)
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)
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)
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)
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)
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."[34]MathewTownsend (talk) 00:13, 22 December 2012 (UTC)
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)
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)
(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)
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)
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)
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)
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)
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)
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)
I'd like to make sure the situation is clear. There are two possible solutions to the problem:
undo the template move
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? —Torchiesttalkedits03:31, 22 December 2012 (UTC)
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)
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)
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)
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)
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)
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)
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. —Torchiesttalkedits16:04, 22 December 2012 (UTC)
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)
So, by your logic, if folks keep creating new names, based on weak or no consensus, bot operators are forced to do the work to maintain the bot to account for community whim, even when they were part of designing the original name and template that was in use without problem for years until a small group decided they wanted a space and a capital letter change? Is that a reasonable demand to place on all bot writers? When the template and the bot were simultaneously designed, there was one name. Who is reponsible for getting that up to six, and why should bot writers have to accomodate that whim? SandyGeorgia (Talk) 14:39, 24 December 2012 (UTC)
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 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)
I didn't say it would be easy (it would be easier if the bot's code were available). Nor did I say it would be desirable – it is rather overkill for something so trivial. If you're referring to my idea for one bot to clean-up after another bot, on reflection I think that was rather silly, so I've struck it out. For now, I think the template should be moved back, then the redirects not recognised by the bot should be deleted (changing any existing uses of them back to ArticleHistory). The point I was trying to make was if anyone really cares enough about the template's name, then they should be prepared to do the work to replace the bot if they cannot convince Gimmetoo to change their bot. I'll add to that the point you make below: Anyone trying to do this needs to understand all the work GimmeBot does, to be sure they get it right. – PartTimeGnome(talk | contribs)22:22, 24 December 2012 (UTC)
Some history of the articlehistory
Talk page clutter
Perhaps some accurate history will help with some of the misstatements and misconceptions on this page: from The Signpost, Taming talk page clutter. I hope everyone advocating that a bot that has done enormous amounts of productive grunt work for five or six years, without issues, reads that piece of history before advocating, "oh, someone else can just knock out a bot and do the work". As with all bot work, every content review process on Wikipedia has come to depend on something that didn't exist before Gimmetrow and two others designed the template, and the bot that comes through and records your peer review, GAN, FAC, etc in a format that didn't exist until Gimme, Dr pda and Raul654 set it up. I'm concerned about who is really going to do the work if this assault on GimmeBot for the sake of a space and a capital letter, when nothing was broken before, succeeds.
Way back in 2007, talk pages looked like the image on the left. Almost all of them looked like that, throughout Wikipedia. Raul654, Dr pda, Gimmetrow, Maralia and I got together to try to solve cluttered Featured article talk pages, the template was designed, and Gimmetrow worked through Every Single Featured Article and Former Featured Article on Wikipedia to make (for example) that talk page look like this. Then he moved on to GAs. Then to Peer reviews. Then to every other content review process like Featured Lists, Sounds, whatever, and more. Since 2007-- more than five years-- Gimmetrow and Gimmebot have been responsible for making sure that every single article touched by a content review process has a clutter-free history on its talk page. Folks take this for granted now ... a content review process happens, and no editor has to do a thing to get it added to article milestones. Gimme does it all, and has, singlehandedly as far as I know, for every single process for over five years. Why anyone is mentioning anything about "since 2010" is a mystery to me: Raul654, Gimmetrow and Dr pda designed the articlehistory template in 2007 and Gimmebot then began the maintenance. It started out as only for Featured Articles, but Gimmebot now does Everything.
FACT: Gimmetrow was part of the team that designed the template to begin with and gave it its original name. Then he wrote the bot to maintain it. Then he did the maintenance on not only FAs, but every content review process on Wikipedia for about five years.
Along comes someone years later, when there have been no problems, who decides the template needs a name change, creating work for Gimme, for all the reason of one space and one capital letter. And then the discussion is positioned as if Gimme is the one being difficult or obstinate or operating on a whim!!
Choess said: What I dislike here is the notion that a bot operator can unilaterally overturn a community decision simply by being obstinate, ... but that is not the case at all. GimmeBot was functioning fine for about five years, using the name that was used when the bot and the template were simultaneously developed, until someone else decided a template name needed to change, and then Gimme should do the work to satisfy that whim based on a Move Request that was closed on very weak consensus. There is no situation here of a bot operator being obstinate and overlooking great community consensus. The bot operator was part of the original design of the template, and then a very small group decided to make him do more work for a capital letter and a space.
IMO, the most sensible post on the page was when Kibod said: 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. That is accurate. Someone (with Support from another who had long-standing issues with Gimme) wanted the name changed, no matter that there wasn't really a problem, no matter that this meant extra work for Gimme.
And Jenks24 said, when closing a move request on very weak consensus, including support from a now-banned prolific sockmaster who was the subject of numerous ANI reports where he followed Gimmetrow to article after article and hounded him, if any technical glitches and the like are not easily fixable, then I will move the template back. No one is fixing this, and in fact, even when the bot is operating without issue, we have unnecessary reverts of the bot when there was nothing wrong with what the bot installed.
Jenks said he would move it back; Jenks isn't editing. The notions expressed here about who is being obstinate, and who wants to create work for someone else based on a whim, are wrong. One person has done all of this work for five years, and done it well, to the point that most editors have no recollection of the work "they" used to have to do on talk pages to figure out what content review processes had been engaged. Then a very small group of people decided they wanted to change a name, consensus was weak, regardless of the work that would create for the bot operator. The idea that, oh, let someone else write a new bot in accordance with the new name ... right, and we are going to trust that that person has any idea of all of the work that Gimme does in closing every single content review process on Wikipedia, and has done that unfailingly for over five years, without mistake, and is going to keep at it as Gimme has for another five years? The solution is simple: move it back. Let Gimme keep doing what he has done well since he and Dr pda designed the template, and let us show some appreciation and respect for the work involved. SandyGeorgia (Talk) 14:55, 24 December 2012 (UTC)
Thank you for a diligent search, but find it scary or not, (repeating:) the bot has to support all valid names, that means, even if it is moved back, the bot has to support "article history" as a redirect, --Gerda Arendt (talk) 15:17, 24 December 2012 (UTC)
I'm not sure what you mean about "diligent search"; a good deal of the history of the development of the template and the bot happened on my talk page, and I still have some memory even if growin' old ain't for sissies. Do you think bot operators should have to do the work to support persons reverting a functioning bot creating functioning articlehistories to names of their personal choice which are very rare and based on very weak consensus? I agree with the person above who said all of these other names should just be deleted; let the bot operator code for one name only. Don't let community whim drive bot operators to endless testing, coding, tweaking, writing. It's such a disrespectful way to treat the folks who keep this place running. SandyGeorgia (Talk) 15:34, 24 December 2012 (UTC)
I am sorry if you see lack of respect. I see six redirects that have to be handled, and they would need to be deleted to not do it, that means delete discussions first. Interesting topic on Christmas Eve, --Gerda Arendt (talk) 16:26, 24 December 2012 (UTC)
Discussion of history of history
Six of the eleven templates on the example talk page are wikiproject templates, which have nothing at all to do with Gimmebot. Wikiproject templates are nowadays tied together with a {{WikiProjectBannerShell}}. Only two of the templates on the sample page would be the sort of thing managed by Gimmebot.
SandyGeorgia, once again you are making vague accusations that people are editing on behalf of and at the direction of a banned user. This is a very serious accusation. If you have some proof that this is happening, you need to present it at one of the appropriate noticeboards or talk to one of the administrators who is most familiar with the case such as Elen or Courcelles or NYBrad. In the meantime, dropping this unsubstantiated accusation into conversation on talk pages is not an appropriate thing for you to be doing, and I politely request that you stop. -- Dianna (talk) 15:40, 24 December 2012 (UTC)
I'm glad you read the article to see that, in that example yes, about half of the templates are related to another template we were simultaneously developing-- don't know what your point is on that, unless to show the broad collaboration that existed. I presume you're capable of abstraction and can understand what talk pages would look like today if every content review process added a separate template, even if the example we used when writing the Dispatch contained some of both.
Diannaa, once again you are making inaccurate accusations where you are reading things even though I didn't write them. This is a very serious accusation. If you have some proof that this is happening, please point out the specific phrase in my post above that troubles you. That now-banned Merridew and his many socks had a long-standing history with Gimmetrow across many pages is well documented in archives everywhere, including various ANIs, that is relevant, and my post above contains no "vague accusations that people are editing on behalf of and at the direction of a banned user", although it is curious that you read that into my post. In the meantime, dropping this unsubstantiated accusation into conversation on talk pages is not an appropriate thing for you to be doing, and I politely request that you stop.
The move request was closed with a qualifying statement from the closing admin based on roughly an equal number of supports and opposes, More significantly, considering that it is difficult to imagine any user who has not encountered the articlehistory template on talk, only eight supports showed up; is that not a very small consensus for a move that will create unnecessary work for a bot operator on a template that was working fine for years? Diannaa, you cannot continue to read things into my posts that aren't there; put up or shut up. If you don't point out which part of my statement you are misreading, I've no way to know what you misunderstand or what needs fixin'. SandyGeorgia (Talk) 16:21, 24 December 2012 (UTC)
And since you are the one who took it off-topic here, it isn't welcome on my talk, and responses will be here. I asked you to point out where your accusations reside in the text I wrote. Put up or shut up; if you're reading text I'm not writing that is not my problem. Do you have something to say on the substance of the matter or are you just here to make accusations at me that result in stalling discussions of the substance of the issue? I started a fresh section here to start over focusing on history; look where you went with it. The accusation is implied when I didn't write what you're reading --> failure to AGF. SandyGeorgia (Talk) 18:33, 24 December 2012 (UTC)
Diannaa, you don't get to make stuff up (your "implied" = your failure to either read or AGF or just plain old continuing old disputes instead of focusing on the history of the template, per the new section I started), and then spread it around. Answering the parts of my post above you didn't understand belongs here where you started it. There is no answer to your post, because it contains nothing but what you cooked up in your imagination: that is, what you decided to read between the lines. I have no indication whatsoever that "all of the people" who were in favor of moving the template were part of anything. Nor did I mention anything about "damaging the FA process" in my post above: you made that up, too. And then you, with the usual weak argument, start bringing in old posts from other parts of discussions, some on other pages, to justify your claim about what I'm saying when I try to restart a discussion. No, I can't see what you see, because my mind doesn't seem to work the way your mind works. What I do know is that the age-old issues that Merridew had with Gimmetrow are well documented, and it is not surprising that he would support something that would make Gimme's work harder. Stop bringing in old disputes; stop spreading disputes around to multiple pages; stop reading between the lines. Just Stop. SandyGeorgia (Talk) 19:03, 24 December 2012 (UTC)
Re the statement by SandyGeorgia "it is difficult to imagine any user who has not encountered the articlehistory template on talk, only eight supports showed up" - yes, many users who have viewed a talk page will have seen the {{ArticleHistory}} at the top; but that doesn't mean that they have an opinion on what it's called. I suspect that the only ones who were aware that there was a move proposal were those that had the template on their watchlists, plus those who periodically check WP:RM.
I fall into the former camp - as may be verified by my contributions to other threads at Template talk:ArticleHistory - but I did not offer either support or oppose because I didn't consider it important enough to stick my oar in. I'm sure that I wasn't the only neutral who didn't have an opinion on what it's called. Perhaps if Gimmetoo had actually stated "this will break GimmeBot", instead of it being implied (not explicitly stated) by Rschen7754, some of us might have paid more attention. --Redrose64 (talk) 20:26, 24 December 2012 (UTC)
I feel confident that if we can just get the distractions to stop, and keep the discussion here instead of moving all over the Wiki and involving old disputes (I originally encountered this on a page that has nothing to do with Gimmebot-- an irritation which impacted my first entries here), the bot and technical folk here who are neutral and previously uninvolved (assuming there are some who haven't been impacted by the dispute spread) will come up with a reasonable solution that encompasses all concerns. I just wanted to present the history, which seems to be misunderstood. SandyGeorgia (Talk) 20:38, 24 December 2012 (UTC)
My understanding is that the name of the template and six valid redirects have to be supported by the bot, whatever the current name is, - the move history seems not relevant to that. --Gerda Arendt (talk) 23:10, 26 December 2012 (UTC)
I would certainly say that pretty much everyone here agrees that situations where the GimmeBot code is confused by encountering names of the history template that it does not recognise, should be avoided. Therefore it would seem sensible that if the proponents of the 'status quo' ({{ArticleHistory}}) do not wish to see the bot's functionality expanded to recognise the alternative names, they should list them at RfD. The fact that they are/were unused is irrelevant, indeed a stronger reason to RfD them while it is still easy to do so. Happy‑melon14:02, 29 December 2012 (UTC)
Hi Happy Melon. The problem is that one of the names that the bot does not recognise is the template's current name, {{Article history}}. In fact the only version that the bot does recognise is Gimmetoo's preferred version, {ArticleHistory}. There's also the following additional redirects, none of which are currently supported, and according to Gimmetoo's remarks above, none of them have ever been supported:
T:AH - created April 2007
Template:Article History - created May 2009
Template:Article milestones - created October 2008
Template:Articlehistory - created February 2007
Template:Articlemilestones - created October 2008
I am pretty sure that the status quo doesn't have any proponents; since the template is at one name, and the bot only recognises a different name, and the bot owner has declined to modify his script, we are left with a non-functional system. -- Dianna (talk) 15:53, 29 December 2012 (UTC)
Yes, I'm familiar with the situation, I had some involvement in the migration to ArticleHistory myself (although a relatively minor role). I think the term "status quo" is too vague, I meant the 'historically consistent' status of the template being located at Template:ArticleHistory and none of its redirects (including Template:Article history) being supported, not the status at this precise moment. The question of whether the actual template code lives at the camel-case or non-camel-case version is separate to the question of whether the other 'spellings' should be valid template names; the fact that there are (or at least could be) instances of the template that the GimmeBot code does not recognise is not a new problem. Listing the other redirects at RfD would prompt a structured discussion that would be helpful for resolving the impasse here: if the redirects are deleted it would provide support for Gimmetrow's argument that there should be a minimum of variation in the template name, while if they are kept it would provide support for the argument that the bot should support multiple names. At the moment this discussion is not really being productive, but is perpetuating a completely broken middle ground which benefits no one at all. Happy‑melon16:36, 29 December 2012 (UTC)
The discussion has descended into a poo fight. Me finger is suffering severe 'MouseWheelChaffe'.
'CamelCase' is a symbol. 'Camel Case' is two words separated by white-space.
In terms of technical Markup, I would rather read, write, and parse symbols. My eye see's 'CamelCase' as a symbol, where as I must read and parse 'Camel Case'. It is the same for a script bot. For a script bot, accurate parsing of 'Camel Case' adds SUBSTANTIALLY to the script's computing load.
Under_Scores_In_Symbols sux. They are worse than whitspace, and should be banned to (that_place_which_dare_not_be_named).
I have not read absolutely all of the above, but let me see if I got most of the idea.
There is/was a bot that works/ed fine for some years
Some users changed a template name
Changing that name made the said bot to stop work properly
The former users, want the bot owner to change the bot's code to conform to their change
The later user, and bot owner, wants the template name to be changed back
That's it? If so I'd say both sides are right and wrong. If the name change was valid according to WP policies, the bot owner has no right to demand it to be reversed to keep their bot working; they either change the bot or give it up. OTOH the 'name changers' can not force the bot owner to change its code, it is not their bot. If they want the new name, and they can not convince the bot owner to change it, the either carry on without a bot or code their own and better bot.
Of course, the comunity should observe, consider how disruptive to WP is the behaviour of ALL the involved editors, and act accordingly - Nabla (talk) 16:22, 30 December 2012 (UTC)
To answer your post directly is to make this subsection basically a continuation of the discussion above, while I think Gerda meant it to be a different line. To continue more in that vein than the 'standard' (and IMO not very productive) line, the situation as I see it is:
There is a bot that worked fine for some years managing {{ArticleHistory}}
{{ArticleHistory}} has six redirects which the bot code does not handle; if the template is created on a page using one of the redirects, on editing the bot creates a duplicate template. Substantial problems have thus far been avoided because the redirects were almost completely unused.
As a result of a now-contested/disputed process, the template was moved so that one of the unsupported names ({{article history}} is now preferred. Incidents of the bot producing duplicate templates will now increase.
The former users, want the bot owner to change the bot's code to conform to their change
The later user, and bot owner, wants the template name to be changed back
There seems to be a complete impasse over which of #4 or #5 is the 'right' course of action, but my (and Gerda's) point is that the actual problem we are encountering is not new and is not caused by this template move, only highlighted by it. As such the 'platform' of the "move the template back" camp is incomplete: for their argument to be cohesive it should also include removing these unsupported redirects, not merely discouraging their use. If I go and find a talkpage and add the template to it using one of the unsupported redirects, I am not being disruptive but I am requiring work to be done in order for the 'status quo' to continue to function correctly, either that the bot code be updated, or that the wikitext be updated to work with the existing bot code. The "it's less work and more maintainable to keep things as they are" argument only holds water if it involves removing the redirects which are sources of good-faith disruption to the existing process. As such neither camp has the right to claim that they need to do nothing for their version of the system to work. So why has no one from the "move the template back" camp sent these redirects to RfD? Happy‑melon18:14, 30 December 2012 (UTC)
You and Dianna above gave a good summary. I don't understand the function of the redirects (none of them new), but think it should be easy for the bot to just handle them all. I think sending redirect ArticleHistory to RfD would take things too far, --Gerda Arendt (talk) 18:33, 30 December 2012 (UTC)
Happy-melon, sorry for possibly breaking the intended flow, I quite simply wrote "at the bottom". I don't know about RfD'ing or not RfD'ing anything, or whatever. But I think it is not to be expected that a _voluntary_ programmer changes a bot anytime some voting decides to change it. The community can not expect that. That said, yes it looks like there is a need for a bot to do the job, but it clearly is up to the people that changed something to guarantee that the change works, makes no sense to try to force others to finish up one's job, against their will (even if it does not look like a huge change, as this one does not)- Nabla (talk) 22:00, 30 December 2012 (UTC)
I'm a stalwart proponent of WP:NOTCOMPULSORY etc: indeed no one is required to proactively do anything. The point is that the change under discussion is not the cause of these problems, so claims that it's solely up to the pro-change supporters to "finish the job" are disingenuous: the job has always been unfinished, and both sides have a step to take to complete it in their preferred fashion. Happy‑melon22:18, 30 December 2012 (UTC)
Sorry, I don't see "sides", I see that, beginning in 2007, various names were around that should be accepted. The last move (from one of them to another of them, not to a new one) didn't change that at all, imo, --Gerda Arendt (talk) 22:46, 30 December 2012 (UTC)
Well, if nothing caused no problem... what's the discussion about? May someone suggest a actionable solution (one that does not require anyone _else_ to act)? - Nabla (talk) 09:45, 31 December 2012 (UTC)
Either the template is moved back, or the bot is changed. (short term solution: the name of the template is changed in the bot. long-term solution: the bot is told to distinguish template redirects and follow them to the real template, permanent solution: the bot owner releases the code and anyone can make the change).
Repeating again (Lord, give me patience): the move of the template has nothing to do with the "wish" that the bot may handle all names. The present name was a redirect since 2010 and should have been handled all this time, a move back wouldn't help, --Gerda Arendt (talk) 10:46, 31 December 2012 (UTC)
your "lord give me patience" comment is simultaneously condescending and ironic, as it seems to me that _you_ are the one taxing the community patience. you seem to think you can make demands on other people's actions ("The bot *should* do this and the bot *should* do that). IMO, this is not the case. anyone can create redirects to any article and to any template anytime they want, without any review process. true, these redirects may be subject to deletion, but the idea that merely by creating yet-another-redirect-to-the-template one can somehow "oblige" the bot operator to do something is just ridiculous. it really does not matter how long these redirects have existed - the bot operator is not obliged to take them into account ten seconds or ten years after they are created. of course, one can politely _ask_ the bot operator to take these redirects into account, an maybe it would even be nice of him if he did, but it seem you somehow presume you can actually *demand* it. if you believe that by not taking the redirects into account the bot is actually doing more harm than good, you can request for the bot to cease operating, but this is the limit of what you can *demand*.
Peace is one of my favourite words, thank you! (English is not my first language, I didn't know that "should" translates to "demand", - what I mean is "wish".) Needless to say, we are here AFTER I asked the bot owner (politely, at least I thought so), to handle the former redirect which is at present the name, and he said no. It was not me who brought it here ;) He could have simply said yes, --Gerda Arendt (talk) 18:28, 1 January 2013 (UTC)
twisi, claiming over and over and over and over that something "should" happen, and adding the "lord give me patience" bit is _exactly_ "demanding".
seeing that you realize that the bot operator said "no", please let me ask: what is the point of all this?
it is my understanding that the community can do one of 3 things (here "it" means "the community"):
it can leave things as they are, i.e., the bot place {{ArticleHistory}} in talk pages, which happens to be a redirect, while ignoring all the other redirects to the template, including the current template name.
it can revert the template name change, and try to retire the dysfunctional redirects (some of them may not need to be retired, e.g., T:AH is meant as a shortcut, and was never intended to be used instead of the template itself)
it can tell the operator to cease running the bot.
what it *can't* do is force the bot operator do something they choose not to do.
from the discussion so far, it seems that the broad consensus is that choosing option #3 would be asinine. many people seem to think that option #1 is unacceptable.
Is there any reason why {{Dropimage}} couldn't be modified to work and appear in the same way as the similar template at Wikibooks (b:Template:Dropdown) The wikibooks template has a better look e.g. dropdown arrow rather than show/hide, and operates in a better way e.g. click anywhere to show/hide rather than on the prompt. NtheP (talk) 17:11, 1 January 2013 (UTC)
Template link font
I have noticed that as of today, on many templates, the font of them is Aerial Black instead of the usual font. Strangely this does not affect all templates, only many within the transport projects. Simply south......walking into bells for just 6 years21:22, 1 January 2013 (UTC)
Does the text look like this? If so, it's because its a link pointing to the same page. An example would be nice, though. (X! · talk) · @996 · 22:54, 1 January 2013 (UTC)
Screenshot
Actually it has also been happening in the {{S-line}} but I can't seem to find what is wrong. And no, the "preceding" and "following stations" are not linking to the article. Simply south......walking into bells for just 6 years23:36, 1 January 2013 (UTC)
I think this is a browser issue rather than a problem with templates (though the template styling might benefit from removing redundant bolding). You're seeing extra-bold where a <TH> table header contains text with bold or strong formatting. The logic, presumably, is that the boldness of a table header should combine to make the content extra-bold, and Arial Black is an extra-bold font.
This might be caused by whether the browser defines the default TH style as font-weight:bold; or font-weight:bolder; – the latter definition would combine with bold elements to render as extra-bold. From a quick search, it appear that bolder was recommended by CSS2.1 for HTML4, but bold is recommended by WHATWG for HTML5 (but the latter spec recommended bolder for <b>; maybe "bolder" has no effect if it is the child of a bold parent but has an effect if the parent of a bold child). Anyway, I'm not an expert on this, but it seems related.
Test case:
<table><trclass="wikitable"><th>TH normal</th><th>TH <b>bold</b> and <strong>strong</strong> and <b><strong>combined</strong></b></th><th>TH <spanstyle="font-weight:bolder;">bolder <b>bold</b> and <strong>strong</strong> and <b><strong>combined</strong></b></span></th></tr><tr><td>TD normal</td><td>TD <b>bold</b> and <strong>strong</strong> and <b><strong>combined</strong></b></td><td>TD <spanstyle="font-weight:bolder;">bolder <b>bold</b> and <strong>strong</strong> and <b><strong>combined</strong></b></span></td></tr></table>
TH normal
TH bold and strong and combined
TH bolder bold and strong and combined
TD normal
TD bold and strong and combined
TD bolder bold and strong and combined
For me, this renders everything in standard bold, except for those words in the TD row that are neither bold, strong, combined nor bolder (all of which I see rendered in a normal weight).
, you can click again to get the maximum enlargement. --Redrose64 (talk) 10:38, 24 November 2012 (UTC)
Yep, you're exactly correct. I'll fix up the script in question; I think I know the cause of the problem. —Theopolisme 22:49, 6 December 2012 (UTC)
My rollbacker userbox is working just fine now. I (or someone else) still need to fix the other ones, but it looks like I'm the only one effected by it so far. Still, I have to stick up for the rights of my fellow Ampersandian-Wikipedians, we oft-persecuted few. It's ironic that I forgot to fix {{User wikipedia/Confirmed}}, as I'm currently the only person who actually uses it. (I reworked it a few weeks ago, from a previous, rather unappealing version... if I'm still the only person who links to it in a few months, I'll take it to MfD myself.) — Francophonie&Androphilie(Je vous invite à me parler) 23:53, 6 December 2012 (UTC)
Done. I also fixed a problem where the template didn't work properly if the 2nd parameter was omitted. – PartTimeGnome (talk | contribs) 00:44, 6 December 2012 (UTC)
As for testing, well, I just stalked your contribs a little, and with 20,000 edits on Hebrew, I don't imagine it'd be too hard for you to convince an admin that you're trusted enough that you can be given rollback simply for testing purposes. (I assume they don't have it over there?) There's also testwiki, where they'll give any trusted user the full admin bundle, provided they can demonstrate a need for it. Or you can just try to put something together blind, and I'll try it out and cross my figures that I don't, like, rollback every latest revision or something.
"watch" tab. You could use that directly, no need for a script which just gives an equivalent button in a different place. --Redrose64 (talk) 12:52, 10 December 2012 (UTC)
Thank you --Redrose64 (talk) 16:25, 14 December 2012 (UTC)
"City of London skyline from London City Hall - Oct 2008.jpg"
"Image01.png"
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)
Helder 02:21, 20 December 2012 (UTC)
Resolved
Fixed The problem was the <references> tag – it should have been <references /> (note the slash). – PartTimeGnome (talk | contribs) 01:15, 21 December 2012 (UTC)
— Francophonie&Androphilie(Je vous invite à me parler) 15:14, 21 December 2012 (UTC)
Your bot is not approved to run on the English Wikipedia. Please complete the bot approval process before running it again. Also, please do not use templates in your signature.
![[26]](https://upload.wikimedia.org/wikipedia/en/thumb/4/40/Compact_Cassette_Logo.svg/170px-Compact_Cassette_Logo.svg.png?1){kind=link}
Unresolved
