Wikipedia:Village pump (technical)

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at BugZilla.

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

view · edit

Frequently asked questions (see also: Wikipedia:Technical FAQ)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.

No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an `accesskey` property on it (default to `accesskey="f"` in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.

If you have problems making your fancy signature work, check Help:How to fix your signature.

If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.

If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Category sort order (lower case no longer?)

Hey all. It used to be the case that categories were sorted based on capitalized titles, then you could also sort items after that with lower case sortkeys in this order: !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ (via Help:Category#Sort order). This is really important to us at WP:PLANTS as we use lower case sortkeys on species pages to differentiate the species from the subgenera or sections or articles titled at common names in genus categories. E.g. at Category:Stylidium under F, the species should be sorted under "f" and subgenus Forsteropsis should be sorted under "F" since species epithets are lower case and other ranks are capitalized. It was a really neat and tidy way to keep the genus categories.

What gives? Why was this changed? Can we get it reverted? What was the motivation for the change? I should note that others have noticed the change (here), and it undoes a lot of the work by one dedicated IP editor, Stephen Kosciesza. Cheers, Rkitko ^(talk) 15:40, 19 June 2011 (UTC)[reply]

This has to do with the fix to bugzilla:164. To my mind, the plants project had been relying on broken behavior, which is always risky. Ucucha 16:53, 19 June 2011 (UTC)[reply]

It changed in early March, not long after the deployment of MediaWiki 1.17 in February 2011 (although intended to be part of that update, it was held back a couple of weeks). There have been several related threads on WP:VPT, the main one being Wikipedia:Village pump (technical)/Archive 87#categorically random categories, although nobody has yet, AFAICT, shown where the primary idea to reform categorisation was proposed and approved. --Redrose64 (talk) 17:46, 19 June 2011 (UTC)[reply]

Thanks for the link and history. It's a bit frustrating. Could this comment at bugzilla help? He writes, "Note that if you still want to present a category ordered so that all lowercase letters will sort tegether separately from all other uppercase letters, you'll need to indicate a separate collation order, by specifying an additional non-default locale in that specific category. This will look probalby not natural for most users, that's why it will be a distinct locale and not the default. For example to use it in English or in French: {{SORTAS:en-x-uc}}"

As far as I know, a SORTAS template or magic word is not in use, but could be the answer to my issue. We could just plop that into each genus category - more work, but if this change is here to stay, it might be worth it. Rkitko ^(talk) 18:16, 19 June 2011 (UTC)[reply]

(edit conflict) I wondered if that was it. I don't think we were relying on broken behavior. We should have the capability to sort under lower case titles if we want to, without interfering with other sorting schemes. There's a lot to wade through at the bugzilla link - what was the course of action for the fix? Treat every letter of an article title as capitalized? At least that gets rid of the perceived need for the damned DEFAULTSORT on non-biographical articles. I'd like this functionality of lower case sorting back. Rkitko ^(talk) 17:49, 19 June 2011 (UTC)[reply]

I certainly think the previous behaviour (sorting "a" after "Z") ought to be seen as a bug rather than a feature, and I'm glad to see Wikipedia moving in the direction of providing proper alphabetical ordering a mere few hundred years after other reference works managed it, but I see why in some cases (like the plants categories) more flexibility might be required. For example, it might be made possible to treat lower case letters in explicitly defined sort keys as separate, while treating those in implicit sort keys (i.e. the page names) the same as capitals.--Kotniski (talk) 07:55, 20 June 2011 (UTC)[reply]

I totally agree with Kotniski. The old behavior was broken in many ways. Now that it is fixed, it might break your 'trick' in sorting plants, but so be it. In wiki categorization I would say that a genus should never share a category with a subgenus. They are 'separate' concepts and in wiki categorization separate concepts are usually sorted in separate categories. We don't make logical sortings inside categories based on the sort-algorithme, we sort alphabetically and use sup and parentcategories in order to separate elements based on characteristics and other forms of 'logic' sortings. A trick with broken behavior is not a feature, it is a misused side effect of a bug. —TheDJ (talk • contribs) 19:10, 20 June 2011 (UTC)[reply]

Uh, no, we almost never create categories for subgenera or infrageneric devisions. When browsing categories, it's usually difficult to find a species if it's categorized in a subgenus category. There's also usually terrible systematic support for such divisions, which usually means they change frequently in the literature. And with small genera, subgenus categories are a ridiculous proposition. You would really have me create subgenus and section categories for Category:Levenhookia, for example? In these cases, all articles pertaining to the genus should be contained within the genus category, and sorting helped keep it tidy. Prior to using the lower case sort keys for species, we used to keep the subgenera and section articles at the top of the category using an asterisk sort key, but that was undesirable. I also still disagree that sorting lower case after capitalized titles was a bug. As I understand it, bug 164 had more to do with sorting in other language wikis and fixing the need for DEFAULTSORT on non-biographical articles (speaking of which, I'm still seeing DEFAULTSORT being added to species articles, and it's entirely unnecessary now). I see lower case sorting as a victim of the solution for bug 164. I like Kotniski's idea. Is that something that would be possible? Where would this feature be proposed? Do you think it would gain much support? It seems like the right direction to go, as the explicitly defined sort keys (lower case) would only be used in situations where it is warranted. Rkitko ^(talk) 21:49, 20 June 2011 (UTC)[reply]

Are you sure DEFAULTSORT is now unnecessary on non-biographical articles? I tried reading through that bug report, but got lost in the later technical stuff. One of the reasons DEFAULTSORT is needed when it might appear it is not needed, is that it serves as a note that someone has checked the article for category sorting issues. Even if DEFAULTSORT=PAGENAME, you still need to be able to distinguish between an article that is checked and "nothing" is done, and an article that hasn't been checked yet. If you just say "oh, DEFAULTSORT is not needed" and then move on, then someone else will later repeat the check you have just done. In other words, leaving DEFAULTSORT there is a way of saying "this article has been dealt with". Does that make sense? It is a bit like the "ass" (assessment) parameter on disambiguation tags that tells those dealing with disambiguation that someone else did some work on that disambiguation page (or maybe it was orphan tags, I forget). i.e. Silent actions sometimes need recording to prevent someone else repeating them. Carcharoth (talk) 00:51, 21 June 2011 (UTC)[reply]

(A tangent, but let's go there.) I'm sure. It was being used on species articles because of the erroneous idea that all articles with more than one word titles needed to be categorized by titles that would have capitalized words (e.g. {{DEFAULTSORT:Drosera Paradoxa}} on the Drosera paradoxa article), even though all articles with the first word "Drosera" would all sort correctly in all categories, since they would all have lowercase second words (e.g. Drosera paradoxa sorted below Drosera pallida). The misapplication of DEFAULTSORT to species articles was quite vexing, since adding it indiscriminately to a few articles often caused situations in "Flora of (country)" categories where Drosera paradoxa would sort above Drosera pallida if only the former was given a capitalized DEFAULTSORT. That said, since this bug fix, DEFAULTSORT is superfluous if you always want it to sort as the title reads, regardless of capitalization: Drosera pallida will always sort above Drosera paradoxa regardless of whether or not the latter receives a capitalized DEFAULTSORT. If it's not necessary, we sholdn't include it, even for what I think is a very silly reason of a marker to say the article has been dealt with. We need to get out of that mode of thinking. Not every articles needs it, and now fewer than ever before do (I exempt biographical articles since they sort by last name first, and any other articles that sort by a title different from what is given). Also, orphan tags are sometimes exceedingly useless for species articles. Very often (most likely normally), a species will only be mentioned in its genus or "List of Genus species" article. But not more than that. It's a tag that will never be taken care of, because you often have to dig very deep in the literature to find any reason to mention that species on any other article (the only time I can think of such an example is in a few articles, it's possible species X will be mentioned as growing in an area where species Y grows, but usually those are dominant species in the area that already have lots of incoming links). So I usually remove orphan tags when it's clear they're never going to be addressed. Should every article in Category:Bulbophyllum be tagged with {{Orphan}}? (Go ahead, click a random sample.) Rkitko ^(talk) 01:45, 21 June 2011 (UTC)[reply]

There is no requirement for the sortkey of the article to closely resemble the title. So you could come up with a different system to sort the plant articles. E.g. the sortkey could have a prefix that says what sort of article it is, followed by the title of the article: [[Category:Foo|PREFIX:Title here]]. This could be extended to more levels if necessary. — Carl (CBM · talk) 23:44, 20 June 2011 (UTC)[reply]

Wait... what? Putting aside the fact that that would be a TON of work that would be hard to automate (just by the fact that it's difficult to find every genus category), would that work? If I went to Drosera paradoxa and typed in [[Category:Drosera|Species:paradoxa]], what would it sort under in the category? Would it go under the heading S? Species? or p? Perhaps you misunderstood. The goal is to get all the species in a genus to sort under different headings according to the first letter of their species epithet (Drosera paradoxa under "p", Drosera erythrorhiza under "e", but separate from Drosera sect. Ergaleium, Drosera subg. Ergaleium, and Drosera sect. Erythrorhiza, which should all sort under "E". Rkitko ^(talk) 01:45, 21 June 2011 (UTC)[reply]

Just tried it - doesn't work. [[Category:Drosera|species:erythrorhiza]] sorts the article under "S" which is undesirable. Rkitko ^(talk) 02:22, 21 June 2011 (UTC)[reply]

But you could make the exceptional ones (let's say subgenera, in a category where most of the entries are species) sort under "*" or space, so they come at the start of the listing. Then put a note in the category page text to say what you've done.--Kotniski (talk) 13:25, 21 June 2011 (UTC)[reply]

That doesn't account for articles at common name titles. We used to put subgenera, sections, etc. under a * sort key, but they never seemed to sort alphabetically. It also becomes a problem when you have so many of them. Rkitko ^(talk) 18:29, 26 June 2011 (UTC)[reply]

This sort of thing is already common for Templates (Τ tau was τ but is now capitalised) and Stubs (μ but is now capitalised as Μ). You may want to define a standard Greek character for species -- Σ perhaps. Mark Hurd (talk) 10:53, 23 June 2011 (UTC)[reply]

Perhaps I'm not explaining this well. If you used a single sort key for species, it would place all species under that sort key, which is undesirable and unwieldy in large genera. Take another look at Category:Drosera. Each species is sorted under the first letter of its species epithet. That what I want, only how it used to be in lower case. Personally, I think it's a failing of the bug "fix" that it capitalizes every sort key, which especially makes for a bit of confusion when μ becomes Μ, which looks like M but is sorted after Z. Rkitko ^(talk) 18:29, 26 June 2011 (UTC)[reply]

I"m not really seeing any problem with Category:Drosera at the moment. All the species are where they should be (I don't think anyone's going to be in any way confused by the fact that the section-heading letters are capital rather than small - we can all see what's going on). As I say, if you wanted to take the (relatively few) subgenera and sections out of the species list (which to me doesn't seem entirely necessary - people will be able to find them anyway), you just need to give them sort keys wihch begin with a space or asterisk or some such character, followed by the subgenus/section name so they get sorted correctly within their section. But I agree it would be better if the software didn't automatically capitalize explicit sort keys (people write sort keys in a particular way for a reason).--Kotniski (talk) 18:48, 26 June 2011 (UTC)[reply]

I saw this coming. As a fairly dedicated sorting gnome (with 3 or 4 comments on the dreaded bug #164, including one in which I said "Furthermore and FYI, on en, some folk have decided that case-sensitivity in the sort is a feature, not a bug."), it was obvious that when sorting for the general case got fixed it was going to break the taxonomy folks collective heart. But as a default behavior, case-sensitive sorting is a major bug and had to be fixed. Now perhaps there's some non-default trick the taxonomy folk can apply to restore their preferred sorting. However, I would argue that their sorting was "wrong" for a general purpose reference anyway. The issue simply, is that the average person who drills into a category sorted "their" way has no freaking clue that stuff sorted under capital letters is substantively different from things sorted under lowercase letters. Now serious biologists probably "get it" pretty quickly, and I (son of a paleontologist) figured it out eventually, but the average reader? All they see is stuff arranged "oddly" (to them), some things under capital letters and something under lowercase. Now if the sort groupings could be labeled arbitrarily, such as "Genus S", "Genus T", "Subgenus S", "Subgenus T", then fine, the poor average user gets a clue why all the entries starting with the letter s are split into two groups, what with the group names being there on the page. But without explicitly controlled headings, going back to headings "S", "T", "s", and "t", is confusing for non-specialists, IMHO, and is trying to "overload" the tool to do more than its really capable of, and it doesn't really matter if it's standard in specialist works. This is a point I've tried to make to some of the taxonomy folk a couple of times now and they've disagreed; they're doing the work, so fine. But since the topic has come up in a more general venue, I thought I'd repeat the point one last time; WP is a general work and categorization schemes ought to be immediately understandable by the general user. Studerby (talk) 18:25, 29 June 2011 (UTC)[reply]

The main reason that this was useful (apart from a slightly over-enthusiastic clinging to lower case as section headings) was in some older categories where it was good to separate, for example "Banksia, my love affair with the antipodean genus" from "Banksia mycoflorum", particularly useful for a large genus. This is of course sub-optimal categorization anyway, since the category structure does not then reflect the taxonomy, (works and people not being plants) - it looks as if there has been a wise move towards keeping the taxonomic categories clean (XX taxa), which makes the loss of case sensitive sorting less important. Rich Farmbrough, 15:29, 6 July 2011 (UTC).[reply]

Checking if new articles are reposts of deleted ones

Is there a way for non-admins to check if an article is a repost of a previously deleted article? It usually isn't obvious and if such a function doesn't exist, shouldn't one be created to nmake it easier for non-admins to see if the article has been deleted before? Valenciano (talk) 10:30, 28 June 2011 (UTC)[reply]

It's simple to see if a page with an identical title has ever been deleted - click on the "history" tab, and then on the "View logs for this page" link - if there's too much which isn't deletion logs, change the first dropdown from "All public logs" to "Deletion log" and then click on the "Go" button. עוד מישהו Od Mishehu 10:41, 28 June 2011 (UTC)[reply]

Without admin rights you can not see the deleted content, so will be unable to see if the recreated article is substantially the same as the deleted version. Edit comments, AfD or talk pages including a link to the article may help you decide if a speedy with WP:CSD#G4 is appropriate. Else apply improvements or edits are appropriate for any new article. JeepdaySock (AKA, Jeepday) 15:51, 28 June 2011 (UTC)[reply]

And occasionally a google cache may still have the original article - do a google search for a reasonably long quote and check if any hits represent an old Wikipedia article. Before I was an admin, I found one such recreation that way. עוד מישהו Od Mishehu 05:16, 30 June 2011 (UTC)[reply]

Threre sites that attempt to preserve content deleted on WP. Rich Farmbrough, 15:31, 6 July 2011 (UTC).[reply]

Facebook

How to convert a Wikipedia page into a facebook community page?117.195.65.163 (talk) 14:05, 28 June 2011 (UTC)[reply]

I believe you need to include the title in your profile interests section. For instance, if you want to create the Cooking page, then you need to include "Cooking" as one of your interests. Then I know the page will be automatically created. I don't think you can create a page without linking to it from your profile, otherwise people would spam it (more than they do now, anyway). Gary King (talk · scripts) 19:05, 28 June 2011 (UTC)[reply]

Facebook has a topic on Community pages and profile connections on their Help Center. ---— Gadget850 (Ed) ^talk 12:01, 29 June 2011 (UTC)[reply]

(od)The above page is of no help. Facebook has all of wikipedia, uploaded. It is amazing how deceptive these organisations have become, they beat around the bush. Well I think I have found the answer by trial and error. Spent many many hours. Correction I have only part of the answer. For example you want to put Vinoba Bhave, as a person whom you have been inspired by in your profile here is how one goes about...

you first type Vinoba Bhave in Facebook's search window
As you type you may get suggestions, select page that links to Wikipedia, ... see for Vinoba Bhave it was simple, as there was only one page, don't know what to do if there are numerous pages
Click on the like tab of the Vinoba Bhave Wikipedia-Facebook page
Check your profile, Bhave Wikipedia-Facebook may already be there as an info box, perhaps not where you want it, delete the infobox where you don't want it and add it where you do.
If you think this is confusing, you are right, but if you follow instructions step by step it could work, which cannot be said for the instructions on the Facebook page linked above created by nerds who are deep fried in moolah. 117.195.89.45 (talk) 07:33, 1 July 2011 (UTC)[reply]

Doesn't work with C.I.D. (TV series).Yogesh Khandke (talk) 06:47, 3 July 2011 (UTC)[reply]

This is an important technical issue, hope it is addressed by someone who knows how FAcebook works.Yogesh Khandke (talk) 05:49, 4 July 2011 (UTC)[reply]

Range blocking

Why is it that MediaWiki can't block ranges larger than /16? Is it different for IPv6 range blocks? Is it feasible to block a range larger than that by blocking multiple /16s?Jasper Deng (talk) 20:31, 28 June 2011 (UTC)[reply]

Because after /16 the internet becomes REALLY big. We don't want anyone to accidentally block 5% of all our users. —TheDJ (talk • contribs) 10:09, 29 June 2011 (UTC)[reply]

Yes, but, sometimes, we need to block things like /10, or even /8, especially in the case of LTA. I'm also interested in how this applies for IPv6.Jasper Deng (talk) 17:03, 29 June 2011 (UTC)[reply]

I'm pretty sure that a /10 isn't technically possible - it has to be a power of 2 (16 is 2⁴). Re the original q: a logical size would be 256 (2⁸). --Redrose64 (talk) 18:16, 29 June 2011 (UTC)[reply]

On the English Wikipedia you can block anything between, and including, a /16 (65,536 addresses) and a /32 (1 address). --(ʞɿɐʇ) ɐuɐʞsǝp 18:52, 29 June 2011 (UTC)[reply]

With a /16 you are already blocking 65000 endpoints of the internet. If you need to block more than that, you might as well do that by hand, because it gets really dangerous after that. /8 would be 16.581.375 addresses. I don't care how long the lta is, blocking 16 million addresses is simply stupid and should NEVER be done. —TheDJ (talk • contribs) 18:23, 29 June 2011 (UTC)[reply]

Assume 65000 is an approximation of 65536 (2¹⁶). Why 16.581.375 though? The next power of 2 above 16 million is 16,777,216 (2²⁴). --Redrose64 (talk) 18:49, 29 June 2011 (UTC)[reply]

My mistake, though, with accounting for reserved numbers, it might even be a better actual total. —TheDJ (talk • contribs) 18:59, 29 June 2011 (UTC)[reply]

FYI. part of this faulty reasoning that a block of more than /16 is useful, is the assumption that all vandalism needs to be eradicated and forever prevented. This assumption is false. Vandalism is part of Wikipedia. We undo it and sometimes make it slightly more difficult to repeat it. But vandalism will always be there and this is an accepted part of the Wikipedia ecosystem. If the prevention part is causing people to not be able to properly use Wikipedia, then the prevention step is going too far. Non-vandals should almost never be able to notice that we have issued a block with a /8 such an assumption is by definition false. —TheDJ (talk • contribs) 18:36, 29 June 2011 (UTC)[reply]

I'm talking about LTAs.Jasper Deng (talk) 18:41, 29 June 2011 (UTC)[reply]

That's nice. (For the rest of us, that's probably WP:LTA}. So you'd be happy to block 16 million IPs to get a single long term abuser. Excellent. --Tagishsimon (talk) 18:45, 29 June 2011 (UTC)[reply]

Sometimes the collateral damage is worth it. And I need answers about IPv6 here.Jasper Deng (talk) 18:47, 29 June 2011 (UTC)[reply]

That's the way. Can you give us an example of when blocking 5% of users to frustrate a single abuser is worth it? --Tagishsimon (talk) 18:51, 29 June 2011 (UTC)[reply]

Are there any examples where an entire /8 is blocked by a ton of /16 range blocks? I have a hard time imagining vandalism so terrible as to warrant such a massive block. Monty ₈₄₅ 18:55, 29 June 2011 (UTC)[reply]

Let's say that an abuser comes from various addresses within an ISP's /8 - or even a /12 - and the addresses are too dispersed for a /16.Jasper Deng (talk) 19:07, 29 June 2011 (UTC)[reply]

The question raised is not over whether it can or does happen, but whether is appropriate to block such a large range, and if so, what abuse is so severe as to justify it. Monty ₈₄₅ 19:10, 29 June 2011 (UTC)[reply]

And keep in mind that if the technical limit is /16, then it's simple and quick to block a /15 range (as 2 separate /16s) and even a /14 range (as 4 /16 ranges). This discussion is the first place I can recall anyone even disussing anything bigger than a /14 range. עוד מישהו Od Mishehu 05:19, 30 June 2011 (UTC)[reply]

Example of an /11. I've done a /10 at Wikia before (can't remember where, probably wikifur or uncyclopedia), and I am pretty sure someone had to do an /8 temporarily. It happens. *shrug* --Splarka (rant) 07:35, 30 June 2011 (UTC)[reply]

It may make sense for the maximum blockable range to be configured on the level of the site, as opposed to being hard-coded; the place to ask for that would be Bugzilla. On English Wikipedia, I think that /16 is as big as we need - even your examples, which are off our site, don't say anything about what we need on English Wikipedia. עוד מישהו Od Mishehu 13:14, 30 June 2011 (UTC)[reply]

That's especially true when IPv6 comes on. Apparently, MediaWiki cannot block IPv6 ranges larger than /64, which could be a problem if an entire organization (typically around /48) needs to be blocked. Or, a script can be used.Jasper Deng (talk) 22:06, 30 June 2011 (UTC)[reply]

It already is configurable ^demon^{[omg plz]} 00:19, 7 July 2011 (UTC)[reply]

Most ISPs I've seen usually occupy multiple /16 ranges at most. Though a user may appear to hop in a /10 or /8 range, I've found that many are actually using multiple smaller ranges such as /20. However, some of our most problematic ISPs are TalkTalk Business, BT Group, and Tiscali. I call these the impossible ISPs. Elockid ^(Talk) 17:40, 1 July 2011 (UTC)[reply]

A large problem often faced with range-blocks is lack of WHOIS info for rangeblocks to be specific enough.Jasper Deng (talk) 03:53, 2 July 2011 (UTC)[reply]

Transclusions, noinclude and load times

When you open a page that includes transcluded templates, does stuff within <noinclude> tags (e.g., costly things like images, links, other transclusions) also take time to get loaded? I know, for example, that <div style="display:none"> causes stuff not to show up but still cost load time, whereas  causes stuff not to show up or to cost any load time; what about <noinclude>?

Thanks, rʨanaɢ (talk) 17:55, 30 June 2011 (UTC)[reply]

<noinclude>...</noinclude> has no impact on load time. Any content within it is stripped during parsing (read: when saving a page). — Edokter (talk) — 18:31, 30 June 2011 (UTC)[reply]

<noinclude> is on the server end, so it's only downloaded where appropriate. <div style="display:none"> and  are on the client end, so they get downloaded and the browser determines whether to display them. —Designate (talk) 07:30, 1 July 2011 (UTC)[reply]

Most comments are omitted unless subst'd: Like most things in life, the handling of noincludes and HTML-style comments is somewhat complex. It appears that most HTML comments "" in templates (or articles) are omitted unless a template is subst'd, then comments outside of each <noinclude> are downloaded over the Internet to the reader's computer. For that reason, feel free to use many comments inside a template's markup coding, to explain all the complex "esoteric" features, but for templates designed for WP:Subst, then noinclude most commments as "<noinclude></noinclude>" otherwise, all those comments can get downloaded to the reader's computer. -Wikid77 (talk) 21:06, 3 July 2011 (UTC)[reply]

Note, html comments < are stripped on the server side (for security reasons due to things like conditional comments for IE - easier just to kill them then to actually check if they are safe). You can put as many such comments in an article as you like - it will never end up to the user. (However, even if they did, it'd have such a minute influence on the speed of a page load, it probably wouldn't matter). Bawolff (talk) 16:53, 4 July 2011 (UTC)[reply]

Wikilove link not working in Classic skin

Could someone who understands skins, css etc, attempt to fix or remove the new Wikilove link in Classic skin. Whilst it looks ok in the default Vector skin, all I get in Classic is a badly formatted text link, which doesn't do anything when I click it (see [1] for preview). Alternatively is there anything I can add to my personal css to hide it? (Please don't ask me to change to another skin - I still prefer Classic and refuse to change!)—Optimist on the run (the admin formerly known as Tivedshambo) (talk) 09:22, 1 July 2011 (UTC)[reply]

Special:Preferences → Editing → Labs → uncheck "Enable showing appreciation for other users with the WikiLove tab (experimental)". Took me a while to find it– would have expected it to be under "gadgets" instead. sonia♫ 10:34, 1 July 2011 (UTC)[reply]

Thanks - Have some wikilove :-) I'd looked at gadgets as well.—Optimist on the run (the admin formerly known as Tivedshambo) (talk) 10:43, 1 July 2011 (UTC)[reply]

Slightly off topic, but I don't see this tab at all. I've been wondering what all the sudden hubub about WikiLove even means. I have Mono on, and checking or unchecking doesn't seem to change anything (it was checked by default). ♫ Melodia Chaconne ♫ (talk) 14:00, 1 July 2011 (UTC)[reply]

It only appears when viewing a User: or User talk: page (including your own), and only appears when you are logged-in. In Monobook, it appears immediately to the right of the "watch"/"unwatch" tab; in Vector, it's a pinkish-red heart between the blue "watch" star and the downward-arrow thing. --Redrose64 (talk) 14:15, 1 July 2011 (UTC)[reply]

Personally I see the tab but when I click it nothing happens. It just sits there scared and alone!. I think my Wikilove needs some Wikilove. --Kumioko (talk) 14:41, 1 July 2011 (UTC)[reply]

It also requires your browser to be able to handle Javascript. Further information at mw:WikiLove. --Redrose64 (talk) 14:49, 1 July 2011 (UTC)[reply]

Javascript works fine, I use twinkle and I use several Java based gadets which all work fine. I Use IE and Mozilla depending what computer and I use Windows or Linux depending which computer. I just figured it was cause I was using the old look and feel of WP rather than the new look but I could be wrong. --Kumioko (talk) 14:56, 1 July 2011 (UTC)[reply]

For classic, it's a bug in the script. I created a ticket for the bug earlier today: bugzilla:29668 —TheDJ (talk • contribs) 20:03, 1 July 2011 (UTC)[reply]

It works fine for me, except the "make your own" won't allow me to pull a picture from commons. It says "Something went wrong when retrieving the image. Please try again", but does not elaborate, and trying again of course ends up the same way. Even their suggested example, File:Trophy.png, produces that error. ←Baseball Bugs ^{What's up, Doc?} carrots→ 20:30, 1 July 2011 (UTC)[reply]

Please include your Browser + version + Wikipedia skin, that always helps finding causes for issues like these. —TheDJ (talk • contribs) 21:24, 1 July 2011 (UTC)[reply]

WikiLove has been fixed for the Classic skin in r91320. The fix will probably be deployed next week (along with a few other small bug fixes). Not sure about Bugs' issue though. Will need to investigate further. Kaldari (talk) 00:02, 2 July 2011 (UTC)[reply]

I posted my info on your page. If that fix goes in next week, maybe it will fix mine as well. This is not an earth-shattering problem. It would just be nice for it to work. :) P.S. Has there been any discussion about having one option be a one-touch posting of the standard "welcome" message? ←Baseball Bugs ^{What's up, Doc?} carrots→ 03:58, 2 July 2011 (UTC)[reply]

In the absence of anything else, you can do speedy welcomes with Twinkle. Regards, Orange Suede Sofa (talk) 04:47, 2 July 2011 (UTC)[reply]

I've never used it, and all I see about it are negatives, so I stay away from it. :) ←Baseball Bugs ^{What's up, Doc?} carrots→ 05:32, 2 July 2011 (UTC)[reply]

There is talk of adding Welcome templates in the local WikiLove config. Stay tuned. Kaldari (talk) 01:34, 6 July 2011 (UTC)[reply]

parameter in <div>

Done
Is it true: you cannot use a parameter in a <div>-tag attribute? e.g.:

<div style="font-size:{{{foo|50%}}};">ABC</div> → ~~wrong~~ result not as expected.

-DePiep (talk) 23:55, 1 July 2011 (UTC)[reply]

This should be no problem (at least in templates). — Edokter (talk) — 00:39, 2 July 2011 (UTC)[reply]

Eh, the Q was: true or false? (or: how do I make it not a problem?) -DePiep (talk) 01:19, 2 July 2011 (UTC)[reply]

What is the problem? What did you expect and what actually happened? The code as you wrote it should work fine: if you specify the foo parameter, that is going to be used as the value for font-size. If you don't specify it, the default value of 100% will be used. User<Svick>.Talk(); 02:10, 2 July 2011 (UTC)[reply]

First experience: any input did not arrive (i.e. no effect). It was in a 3-nested template development. Too much at once. I created a more simple test.

Looks like: from the calling template T:

foo=proper value as in {{T|foo=200%}} --> OK
foo=is missing as in {{T|}} --> font-size takes the parameter-default (in example above: 50%)
foo=is blank as in {{T|foo=}} --> whole font-size thing is ignored. Resulting is 100%. -DePiep (talk) 02:17, 2 July 2011 (UTC)[reply]

This is not a special characteristic of <div> (or any other HTML markup); it's how MediaWiki expands any template parameter. Basically: a parameter that is present, but blank, is not the same as a parameter which is completely absent. If you want them to behave the same, you need to explicitly code for that, as in:

{{#if:{{{foo|}}}|{{{foo}}}|50%}}

Some templates deliberately take advantage of the non-equivalence of blank and absence; the {{tag}} template, for example, (which I just used as {{tag|div|open}}), can be used as follows:

{{tag|div|content=ABC}} → <div>ABC</div>

{{tag|div|content=}} → <div></div>

but

{{tag|div}} → <div>...</div>

So, try this:

<div style="font-size:{{#if:{{{foo|}}}|{{{foo}}}|50%}};">ABC</div>

Another example is {{cite book}}, where the use of a blank |postscript= suppresses the trailing period; that period is displayed when |postscript= is absent. --Redrose64 (talk) 10:42, 2 July 2011 (UTC)[reply]

Thank you RR64. At first, when posing this question, I thought the sequence of expanding was causing the trouble (which is does not). Anyway, all clear now. I'll close it. -DePiep (talk) 12:11, 2 July 2011 (UTC)[reply]

.js and .css pages not working

I recently got renamed and when I logged in afterward I found that my .css and .js pages were not working (they still aren't functional). I originally stuck a {{help me}} on my talk page, however, after 3 days of Q&A I was told to come here after I'd exhausted all possible solutions. I thank those who offered their assistance. —James ^{(Talk • Contribs)} • 11:50am • 01:50, 2 July 2011 (UTC)[reply]

Umm... hello? —James ^{(Talk • Contribs)} • 7:48pm • 09:48, 3 July 2011 (UTC)[reply]

One likely problem: I see that in this edit, you changed the first reference from User:Ancient Apparition/CSDlog (the correct old name) to User:M.O.X/CSDH_log (the wrong new name). Does it work now? עוד מישהו Od Mishehu

Nope, I'm completely puzzled, this didn't happen during my first rename. Could it be that some of the edits from my old username weren't transferred, some of which were to my .css and .js pages? —James ^{(Talk • Contribs)} • 11:56am • 01:56, 4 July 2011 (UTC)[reply]

Login error

After I logged on,it just displayed another logon page! — Preceding unsigned comment added by 121.44.108.83 (talk) 05:23, 2 July 2011 (UTC)[reply]

Try deleting the cookies for Wikipedia and/or clearing your browser cache. You can also try the secure server.Jasper Deng (talk) 05:30, 2 July 2011 (UTC)[reply]

But how? — Preceding unsigned comment added by 121.44.108.83 (talk) 05:44, 2 July 2011 (UTC)[reply]

Depends on your browser.Jasper Deng (talk) 05:59, 2 July 2011 (UTC)[reply]

google chrome121.44.108.83 (talk) 06:01, 2 July 2011 (UTC)[reply]

click the little wrench in the upper right corner ... go to tools .. you'll see the option to clear browsing data.— Ched : ? 08:23, 2 July 2011 (UTC)[reply]

I have a different login error: I cannot log into my account, it does not recognize my password, and when I ask it to e-mail me a new password, nothing arrives. Could somebody have hacked my account, and changed the settings so it e-mails my password to whatever e-mail they have determined? Any idea who I should talk to to regain access to my account? I am usually logged in as ElijahBosley but of course since I can't log in, the following IP address will have to serve.: — Preceding unsigned comment added by 216.12.64.8 (talk) 17:12, 8 July 2011 (UTC)[reply]

Never mind. I don't know what was wrong, but whatever it was has been fixed.ElijahBosley ^{(talk ☞)} 22:09, 8 July 2011 (UTC)[reply]

Infobox educational trusts scholarships bursaries

Rhodes Scholarship is a page without an infobox.

Is there one? Which would be the best template to use as a base when writing one? Once created where would be the best place to get peer review? --ClemRutter (talk) 09:53, 2 July 2011 (UTC)[reply]

Not every article needs an infobox. Having said that, you're probably best asking at WT:INFOBOX who specialise in this sort of thing. --Redrose64 (talk) 10:50, 2 July 2011 (UTC)[reply]

That's the link I needed. I was already watching the page! Other thoughts welcome. --ClemRutter (talk) 15:04, 2 July 2011 (UTC)[reply]

Anyone can add an impromptu infobox into any article, or below any standard infobox in an article, by using a WP:Wikitable with "class=infobox". See essay: WP:Thinking outside the infobox, for some examples. I am thinking, for Rhodes Scholarship, to list when the endowment began, note the typical 2-year span, institution: University of Oxford, payment: by Rhodes Trust +monthly stipend (etc.), as a "nutshell summary" of the scholarship. Then, that simple infobox can be translated into more than just the mere 9 other languages, to help create that article in some of the 250 other-language wikipedias, such as Spanish, Italian, Norwegian, Swedish and Greek. -Wikid77 (talk) 20:33, 3 July 2011 (UTC)[reply]

Flawed "Show changes"

Hello,

I am reading an article... I open several "edit section" tabs. Then I edit some sections. Then I am editing a section and I click "Show changes". It must display only the changes in this section. But the comparison is made between the whole article as it was when I clicked "edit this section" and the text in the form. So a lot of "changes" appear: cancellations of my edits in other sections. This is a serious bug. Please correct it. Thank you.

Nnemo

--Nnemo (talk) 00:21, 3 July 2011 (UTC)[reply]

Which page? When? עוד מישהו Od Mishehu 10:45, 3 July 2011 (UTC)[reply]

The problem occurs with any page having sections. It occurs always.

--Nnemo (talk) 12:59, 3 July 2011 (UTC)[reply]

Actually, the comparison says "Latest revision" and is made between the latest saved page version when you clicked "Show changes" (which is not necessarily the version when you clicked edit). This can be helpful, for example alerting you if you are adding something another editor has already added to another section, or you are relying on something another editor has removed from a previous section. In many other cases it will not be helpful but the software cannot predict in which cases it is helpful. In your scenario it was your own edits but I think it's unusual to have several section edit tabs open for the same page. I use the "Edit" tab at top to edit the whole page in that situation. PrimeHunter (talk) 13:04, 3 July 2011 (UTC)[reply]

The comparison tells me that, if I save, many changes will be made: reverts of my recent edits in other sections. Is it true? God knows — as for me, I never dared saving when in that buggy situation. But if, instead of "Show changes", I directly save, then all those reverts will not be made, happily. So, one way or the other, there is a serious bug. Either MediaWiki makes a lot of reverts I didn't demand. Or MediaWiki displays a lot of changes about to be made, which, in fact, will not be made.

Editing a big or busy page is a mess. So happily we can cut it in pieces, to be focused and to avoid edit conflicts. I believe the future of Wikipedia lies in the possibility to edit even much more precisely. A table cell? A paragraph? A sentence? A word? A reference?

I see a missing "s" at some word. In WYSIWYG, I click and add it; saved. In the current Wikipedia, I edit the minimal block, the section, which can be very big, I find my way in the jungle of templates, references, images and so on, and eventually I add the "s".

--Nnemo (talk) 23:54, 4 July 2011 (UTC)[reply]

If you save a section edit then it only affects the section you are editing. Recent edits in other sections will not be reverted. I agree the diff displayed by Show changes can appear confusing if others have saved edits since you clicked edit at a section, but I also think it has advantages in some situations to be aware of other edits. Don't worry about clicking Save. If there is actually a conflict with other edits then the save will be prevented by an edit conflict. PrimeHunter (talk) 00:50, 5 July 2011 (UTC)[reply]

bantu aku

please create WikiBar images contained in id:Pengguna:Erik Evrest/Bak Pasir at Wikipedia Indonesia on the "Usulan Halaman Utama" in the "[date] dalam sejarah" together with the yellow box above it. Many times my experiment did not work all the time.--Erik Evrest (talk) 13:05, 2 July 2011 (UTC)[reply]

I have absolutely no idea what are talking about. What's WikiBar? What's “Usulan Halaman Utama”? What does this have to do with the English Wikipedia? User<Svick>.Talk(); 16:21, 3 July 2011 (UTC)[reply]

There is an error in id:Templat:Peristiwa terkini: a "</div>" after "<onlyinclude>" and a </noinclude> must be removed (edit pending), then that page will show OK. — Edokter (talk) — 17:28, 3 July 2011 (UTC)[reply]

Bug-reports documented???

Where heavier bugs are documented? It is simply impossible that this can be investigated only on bugzilla!? --Perhelion 14:11, 3 July 2011 (UTC)[reply]

What's so impossible about that? Bugzilla is just for that: tracking bugs. So why should they be documented elsewhere? Although it's not unusual that some bugs are documented on relevant Help: or Wikipedia: pages, these can sometimes be quite outdated. User<Svick>.Talk(); 16:24, 3 July 2011 (UTC)[reply]

Ok yes, redundancy must be avoided. I meant more in terms of media files. There are a lot of (frustrating) unknowing mistakes committed. Only very few people explore Bugzilla. -- Perhelion_»♥› 16:00, 4 July 2011 (UTC)[reply]

Getting user's image-size

Is there a magic-word to get the current user's image-size setting, such as with "{{gender: username|...}}" to get a username's gender? I have been auto-sizing & re-scaling images relative to each user's image-size preference, by putting "upright=1.20" in image-links to show images as 20% larger than the current user's preference for image-size. However, I want to calculate sizes by getting the user's image-size as a number from their preferences page, in the way {gender:...} gets a gender setting.

{{gender:Svick|MALE|FEMALE|NOTSET}} → MALE
{{imagesize:xxxx}} → Template:Imagesize:xxxx

Any suggestions? -Wikid77 (talk) 17:28, 3 July 2011 (UTC)[reply]

Say whut ? No of course not. That would defeat the whole point of people having their own thumbnail setting. People get the option to override the default, now if you create a method to override the override, then we get into .... well I don't know, but it sure ain't flatland. —TheDJ (talk • contribs) 18:13, 3 July 2011 (UTC)[reply]

Attempts to access admin accounts are logged?

It's interesting what you can find in leaked arbcom-l correspondence. I read here that, from what I understood, Risker said that all attemps to log into admin accounts are logged and that that information is accessible to developers. Is this accurate? Is it documented anywhere? — Waterfox ^~talk~ 17:58, 3 July 2011 (UTC)[reply]

I'm not sure that making such information documented is a good idea, per WP:BEANS. Every single edit and action on Wikipedia is logged somewhere, though much of it is obscured for public view. That is, every single time anyone attempts to log in to any account, it is recorded. It's a simple thing to take such records and cull out the admin accounts. --Jayron32 18:11, 3 July 2011 (UTC)[reply]

Yes, failed logins for admin accounts are logged and these logs are (like all logs) available to the developers. This might not be documented, but it isn't a secret. MrBlueSky (talk) 18:58, 3 July 2011 (UTC)[reply]

That should be "available to the system administrators". Developers write software, the system administrators run/maintain the software and servers. —TheDJ (talk • contribs) 20:16, 3 July 2011 (UTC)[reply]

Just like they don't tell us exactly what information checkusers have access to. (At least not anywhere I have ever seen) Monty ₈₄₅ 19:04, 3 July 2011 (UTC)[reply]

The MediaWiki software is open source, so there is nothing stopping you from figuring that out (well, except maybe lack of technical skills). MrBlueSky (talk) 21:16, 3 July 2011 (UTC)[reply]

And, do not misunderstand, the WP:OFFICE can do & see everything. This includes Jimbo. -DePiep (talk) 21:25, 3 July 2011 (UTC)[reply]

Technically all attempts to access all accounts are probably logged, as with all attempts to do anything on Wikipedia. Prodego ^talk 22:14, 6 July 2011 (UTC)[reply]

Bolding on Watchlist

Done

I'm confused about how to get the watchlist pages that I haven't read to be bolded. Is there any way to set that to work? I heard on the IRC channel it was disabled on English Wikipedia. Is that true? --Nathan2055 ^talk 00:11, 4 July 2011 (UTC)[reply]

Hi, I found the script: User:Gary_King/mark_unviewed_watchlist_items.js. mabdul 00:14, 4 July 2011 (UTC)[reply]

I added the script to my Vector file, we just have to wait for a page to be updated. I'll watch this page so I can test when you respond. --Nathan2055 ^talk 03:27, 4 July 2011 (UTC)[reply]

Uh oh. I logged on today and my new changes were not bolded! Anything I could have done wrong? --Nathan2055 ^talk 16:43, 4 July 2011 (UTC)[reply]

I found the setting to fix the problem with help from the IRC channel. Thanks for your help with finding the script. --Nathan2055 ^talk 20:02, 4 July 2011 (UTC)[reply]

Works better if you import it rather than copy it, by using this instead:

importScript('User:Gary King/mark unviewed watchlist items.js'); // [[User:Gary King/mark unviewed watchlist items.js]]

This makes it so that you will receive all updates to the script. Gary King (talk · scripts) 04:44, 5 July 2011 (UTC)[reply]

Image not displaying

Someone who released an image for use in an article I wrote has emailed me to say he can't get the image to display. All he can see is a red cross in a box. I can see it fine on several browsers I've tried. I've noticed this a few times with other images myself, but I don't know what to suggest to him. Does anyone know what causes it? SlimVirgin ^{TALK|CONTRIBS} 02:48, 4 July 2011 (UTC)[reply]

I think this is an issue that cannot be properly investigated unless we have the specific image to investigate. Do you have a link ? —TheDJ (talk • contribs) 11:15, 4 July 2011 (UTC)[reply]

Most likely, this is a bug with the software. I'd recommend getting more information on how/when it happens, and openning a bug as described by WP:BUGS. עוד מישהו Od Mishehu 07:09, 5 July 2011 (UTC)[reply]

CZ: prefix

Since Citizendium uses "CZ:" the way we use "WP:", as a shortcut to policy pages, I typed "cz:" as a page title to learn if it would send me over there, in the same way that I type "en:" on other projects to get to http://en.wikipedia.org/wiki/Main_Page. To my surprise, it took me http://cs.wikipedia.org/wiki/Hlavní_strana, the Czech Wikipedia. Why does it take me to a project whose language tag is different from what I typed? I later tried the "cs:" tag, and it worked as I expected it would by giving me the Czech Wikipedia. Nyttend (talk) 03:51, 4 July 2011 (UTC)[reply]

m:Help:Interwiki_linking. Ruslik_Zero 10:15, 4 July 2011 (UTC)[reply]

.cz is the country code top-level domain the Czech Republic, and easily confused with cs which was the country code top-level domain for Czechoslovakia and is the ISO 639-1 language code for Czech, while the ISO 639-2 code is cze/ces (see List of ISO 639-2 codes). If cz: went off site then it would probably cause a lot of false links when Czech was intended. citizendium: takes you to Citizendium. PrimeHunter (talk) 13:02, 4 July 2011 (UTC)[reply]

"cz" isn't the only such confusing issue; I would expect, for eample, that to link to a MediaWiki bug by number one would type [[bug:###]], but that would link to the Buginese Wikipedia. The actual way to link to bugs is actually [[bugzilla:###]]. עוד מישהו Od Mishehu 06:39, 5 July 2011 (UTC)[reply]

Pre 2007

Is there any way of looking through all the previous villlage pumps' archives pre 2007 without looking at the hundred of archived versions once at a time? What I am curious about is the start of the MOTD project which was proposed here and then the project started up 30 March 2005 by a now blocked user. Simply south...... digging mountains for 5 years 15:18, 4 July 2011 (UTC)[reply]

I don't think there is. It would be possible to set it up back to August 2004, but it would take A LOT of manual work. עוד מישהו Od Mishehu 06:45, 5 July 2011 (UTC)[reply]

I feel a script coming on. I shall add it to my to-do list (alas a fairly long one). - Jarry1250 ^{[Weasel? Discuss.]} 14:20, 5 July 2011 (UTC)[reply]

Unless I am missing the point... can you not just search (i.e. run a search query) them for relevant keywords till it finds what you need? --Errant ^(chat!) 14:26, 5 July 2011 (UTC)[reply]

Afraid not. The project should appear somewhere here but these list archived versions of the page histories only, not physical archives so-to-speak. Simply south...... digging mountains for 5 years 15:43, 5 July 2011 (UTC)[reply]

Looks like Special:Export can't export that many revisions for a local search. I'm with Jarry1250...it's trivial (if you've got a command-line and some scripting-fu) to pull all of them and grep for certain strings. Give me some strings (the user's name, for example). However, there are only what, 20ish VPT archives from prior to your given date, by this time one probably could have right-clicked along the list to open a pile of tabs, then browsersearch for a key term? DMacks (talk) 22:59, 5 July 2011 (UTC)[reply]

Even better, it's trivial to recompile the "history" style archives into the more modern style. The only problem is deciding on a numbering system. I suppose we should recompile into the new style but with an /old/ in the name. The entire history of News, for example, I have extracted and put at http://toolserver.org/~jarry/news.txt (.txt, 1.3MB). - Jarry1250 ^{[Weasel? Discuss.]} 18:33, 6 July 2011 (UTC)[reply]

WP:AFDO

There are 3 outstanding AfDs (all closed) on the list for June 25 (Wikipedia:Articles for deletion/Log/2011 June 25) which Mathbot can't seem to clear. I tried reverting one to its pre-close state and then closing it again, but it still doesn't clear out. Anyone got any ideas? Probably something obvious, but I can't see it. Black Kite (t) (c) 23:39, 4 July 2011 (UTC)[reply]

NPP - show the patrol option to wikignomes

I'm an occasional newpage patroller and also a typo fixer, so I'm very conscious that a high proportion of the unresolved typos in Wikipedia are in new articles which may or may not have been marked as patrolled. Similarly a significant proportion of our articles with uncategorised, deadend, wikify and some other maintenance templaes will be new and sometimes unpatrolled articles. Currently you only see the button to mark an article as patrolled if you have gone to the article from Special:NewPages, I think it would be useful if the mark as patrolled option was displayed to all Autoconfimed editors who happened to view an article that they had not created. The Newpages queue keeps hitting its 30 day limit, and if the option to mark as patrolled was available to the editors who are working the various maintenance backlogs then I suspect that many of the innocuous new articles would get marked as patrolled, thus enabling the back of the queue patrollers to focus on the more borderline ones. Ϣere SpielChequers 09:24, 5 July 2011 (UTC)[reply]

This would be a new feature, I think, so please follow the instructions at WP:BUGS (despite the name, it applies also to new features, as does the target website, Bugzilla). עוד מישהו Od Mishehu 10:48, 5 July 2011 (UTC)[reply]

See Bug 15936. Apparently it worked this way for a while, but the change was reversed for "nasty performance" reasons. -- John of Reading (talk) 10:55, 5 July 2011 (UTC)[reply]

Reducing repetition and redundancy with BibTeX style referencing

I thought I'd float this here first: the citation system could be improved on Wikipedia in one simple way - using the page numbering system from BibTeX.

From the BibTeX article, here is an example citation:

@Book{hicks2001,
 author    = "von Hicks, III, Michael",
 title     = "Design of a Carbon Fiber Composite Grid Structure for the GLAST
              Spacecraft Using a Novel Manufacturing Technique",
 publisher = "Stanford Press",
 year      =  2001,
 address   = "Palo Alto",
 edition   = "1st,",
 isbn      = "0-69-697269-4"
}

Note: the first argument on the first line is the equivalent of the name attribute in the ref element in MediaWiki's citation system.

Now, when you cite this book (hicks2001) in BibTeX, you can do it two ways:

\cite{hicks2001}

\cite[5]{hicks2001}

The latter cites page 5 of hicks2001. The footnote and bibliography (etc.) is updated to note this. So if you are citing in Harvard style, it says "(Hicks, 2001, p.5)" while if you are using footnote style, it'd have a footnote that said "Hicks, 2001, p.5".

We could have something like this for MediaWiki.

On first use.<ref name="hicks2001">{{Cite book ... }}</ref>
Then on second use.<ref name="hicks2001" page="5" />

The first footnote would be the citation as it now is, then the second footnote would simply be a transclusion of the first footnote with ", p. 5" on the end. This could dramatically simplify citation of books and other offline sources. Obviously, there would have to be changes to the Cite module in MediaWiki and it'd have to be tested to ensure backwards compatibility, and the community would have to determine whether or not such an approach would be acceptable under the WP:REF guideline. Currently, one either ends up with repetition or one has to use the shortened footnotes style. Basically all this is doing is creating a technical way to have an improved version of the shortened footnotes style.

Alternatively, one could bundle the 'short version' into an attribute, like this:

On first use.<ref name="hicks2001" short="Hicks, 2001,">{{Cite book ... }}</ref>
Then on second use.<ref name="hicks2001" page="5" />

Obviously existing tools like ProveIt would need to be updated to support the new style. Any thoughts? —Tom Morris (talk) 12:42, 5 July 2011 (UTC)[reply]

The BibTeX citation is very similar to the current use of citation templates. What you are adding is the ability to include the page number per <ref> tag. See Template:Bug - Page number attribute for <ref> tags (2008-02-23). ---— Gadget850 (Ed) ^talk 16:11, 5 July 2011 (UTC)[reply]

The syntax is good, but I don't know about the proposed layout. The way it's usually done, all the page number citations go in one section and the expanded citations go in a General Sources section (e.g. Battle of Osan#References). That's a more appealing layout than putting all the footnotes into one section, I would think. —Designate (talk) 16:39, 5 July 2011 (UTC)[reply]

Ah, I didn't know about that bug. That's pretty much exactly what I'm proposing! —Tom Morris (talk) 18:06, 5 July 2011 (UTC)[reply]

As you can see, that request has been open for three years without a concrete example of where to put the page numbers. ---— Gadget850 (Ed) ^talk 03:14, 6 July 2011 (UTC)[reply]

I had a suggestion for this .. let me dig. Rich Farmbrough, 23:40, 6 July 2011 (UTC).[reply]

Chaco Culture National Historical Park is an example of pure shortened footnotes. Battle of Osan mixes long footnotes, shortened footnotes and explanatory notes. ---— Gadget850 (Ed) ^talk 03:14, 6 July 2011 (UTC)[reply]

Answer is an example of the use of Template:Harvnb (Harvard-style citations, no brackets) in conjunction with Template:Citation, which is in active use right now. harvnb does what you are also proposing. For example {{harvnb|Smith|2005|p=25}} renders as Smith 2005 p.25 There is a link under Smith 2005 to the full citation. --Ancheta Wis (talk) 00:46, 7 July 2011 (UTC)[reply]

Chaco Culture National Historical Park, like Answer, uses <ref>{{harvnb}}</ref>. There is an easier way: the {{sfn}} template produces output which is identical to {{harvnb}} in behaviour and appearance, but dispenses with the need for <ref>...</ref>; differing page numbers are given different ref numbers, but where a given author/year/page combination occurs more than once, they are automatically merged. See Reading Southern railway station which uses {{sfn}} to such an extent that although there are 59 inline references, the <ref>...</ref> tag doesn't occur at all. --Redrose64 (talk) 17:54, 7 July 2011 (UTC)[reply]

How to search for any articles with a section named "X"

Hi, I'm trying to use the search feature to return a list of all articles that have a section with a particular title. (For example "Give me any articles that have a section titled 'In popular culture'"). Is there any way to do this currently? I asked at WP:Help desk, and was referred here. Thank you. ~ Mesoderm (talk) 22:44, 5 July 2011 (UTC)[reply]

Its possible but it would be one heck of a query. Are you looking in a certain category or article list or are you talking the whole 3 million plus articles. --Kumioko (talk) 22:59, 5 July 2011 (UTC)[reply]

I am talking about searching every article on Wikipedia. When I type "Dogs" into the search bar, I get all of the articles that have the word "dog" in them. When I type "intitle:dog" I get all articles with the word "dog" in the title. What I'm asking is if there is something akin to "insectiontitle:dog" that will return all articles that contain the word "dog" in a section title. An example of where this would be useful is dealing with the horrid "In popular culture" sections that are slopped all over the encyclopedia. The large majority, probably 98+% of the "In popular culture" sections on Wikipedia contain nothing but unreferenced trivia that doesn't belong in an encyclopedia article anyway. Even those articles that do warrant such a section generally do it very poorly (including irrelevant junk like "In SOME_ANIME_SERIES episode 3, John mentions TOPIC_OF_ARTICLE while eating a cheeseburger with Jane"). I'd like to be able to do "insectiontitle:popular culture" and go through these articles and clean this type of garbage up. Other people have expressed interest in this as well when I asked this at the help desk. Even if it doesn't already exist, it doesn't seem like it would be much more difficult to implement than the title search and I think it would be very useful.(Other examples that comes to mind is searching for sections called "Criticism" or "Controversy", which also almost always suck.) ~ Mesoderm (talk) 02:35, 6 July 2011 (UTC)[reply]

Well, unfortunately appears that this functionality is not available at the moment. There is currently a feature request bug outstanding on Bugzilla that has been stagnant since September 2010. I have posted a link to this thread on the bug report, as well as providing an example of how it could be useful here on Wikipedia. I'm personally unable to implement this myself, so I'll have to wait until I hear back from the developers. If I hear anything within the next few days, I'll post updates here. ~ Mesoderm (talk) 06:53, 7 July 2011 (UTC)[reply]

Problems with API search

Just dropping by to check I'm not Doing Things Wrong(TM) before going to Bugzilla:

The prefix:X operator does not appear to work in API search. Compare:
- GUI - lots of results
- API - 0 results

The API documentation claims "sectiontitle - Adds a parsed snippet of the matching section title". In this search, shouldn't sectiontitle be "Zola Enterprises spam on Wikipedia" as opposed to the page title? Strangely, if I change srprop to sectionsnippet, which the API promises "a parsed snippet of the matching section", I get what I want (here I'd expect the actual contents of the section). The corresponding GUI search is [2].

Thanks in advance. MER-C 05:28, 6 July 2011 (UTC)[reply]

Definitely right on that last one. Reported and fixed in bugzilla:29746. Ill get back to you on that first issue. —TheDJ (talk • contribs) 20:49, 6 July 2011 (UTC)[reply]

Twinkle dead on my PC

I can no longer get Twinkle to function in reverting vandalism! Yes, I cleaned out my cache as instructed, but still I get no red Vandal revert highlight after clicking "diff", and no TW button when I manually (since I can no longer Vandal revert) click on the offender's Talk page. Do I need to get an upgrade to reinstate Twinkle? --- Glenn L (talk) 07:09, 6 July 2011 (UTC)[reply]

How is your Twinkle activated? As a gadget or included in your JavaScript? Hazard-SJ ± 18:52, 6 July 2011 (UTC)[reply]

I've also been getting the same problem today. It is a gadget. Most of the time it doesn't show up at the top of the page, but sometimes it does. I've also been getting a ton of "Service Not Available" messages while trying to load pages. Bgwhite (talk) 20:02, 6 July 2011 (UTC)[reply]

Me too for the service availability errors! I've posted that below. Also re twinkle, the links showed up twice today, as if I had it on both as a script and a gadget (although it usually shows up as normal, with only one set of links), and then later it stopped appearing altogether. A few times, I got the message saying twinkle did not load. /ƒETCH COMMS / 20:47, 6 July 2011 (UTC)[reply]

All you guys using the secure server right ? See one topic below. Known issue. —TheDJ (talk • contribs) 21:00, 6 July 2011 (UTC)[reply]

Secure server, I don't think so. Mine's just the gadget, that, while it's still listed as an option, no longer functions, having been replaced by the dreaded "WikiLove" application. I've even lost the list of symbols I used to use to close my remarks like this one. -- Glenn L (talk) 08:00, 8 July 2011 (UTC)[reply]

Frequent 503 errors?

At least on the secure server today, I've been continually getting 503 errors "Service Temporarily Unavailable", saying:

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Apache/2.2.8 (Ubuntu) mod_fastcgi/2.4.6 PHP/5.2.4-2ubuntu5.12wm1 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g Server at secure.wikimedia.org Port 443

I haven't encountered this on the regular site (yet?), anyone know what's going on? I also have been having issues with Twinkle appearing (see above). /ƒETCH COMMS / 20:47, 6 July 2011 (UTC)[reply]

Known issue. likely related to: "19:15 logmsgbot: hashar: srv154 seems unreachable. dberror.log is spammed with "Error connecting to <srv154 IP>" sysadmin log. Not 100% sure if it is solved now... —TheDJ (talk • contribs) 20:59, 6 July 2011 (UTC)[reply]

OK, not yet solved, but the right people are aware of it now. —TheDJ (talk • contribs) 21:01, 6 July 2011 (UTC)[reply]

fwiw....it's failing on probably 3/4 of the page requests at the moment. I know people are looking at it RxS (talk) 21:47, 6 July 2011 (UTC)[reply]

Also looks like the css file is failing at times (if it even uses a css)...RxS (talk) 21:56, 6 July 2011 (UTC)[reply]

Should be fixed now with "depooling srv154, repooling srv178". —TheDJ (talk • contribs) 22:16, 6 July 2011 (UTC)[reply]

It was fine earlier today but the 503 errors are occurring again now. /ƒETCH COMMS / 03:40, 8 July 2011 (UTC)[reply]

The article that won't die

There is a particular article Aaron Sanders, that appears to be stuck in a month old version according to toolserver and Bots that read the database. It was deleted on May 8, recreated and redeleted a few weeks later, and then I recreated it as a redirect, but it still shows up in searches such as this, this or Dashbot's list. It is very strange. I've asked here before, tried doing a purge, but nothing's helped. Can someone get into the toolserver database and update this file? Thanks. The-Pope (talk) 13:03, 7 July 2011 (UTC)[reply]

I did a null edit (clicking on the edit tab, and then on the "Save page" button without making any changes). Lets see if that helps here - I know it fixes some problems.. עוד מישהו Od Mishehu 13:10, 7 July 2011 (UTC)[reply]

I've tried null edits, actual edits, purge edits, deletion, recreation but this indicates that the database last change time is updated, but the file size and categories are still as per over 2 months ago. Still not fixed. The-Pope (talk) 17:01, 7 July 2011 (UTC)[reply]

Can anyone who has access to the deepest darkest corner of the database assist? Or are us mere mortals just going to keep trying the same thing over and over again, in a futile search for a different result from the same actions? The-Pope (talk) 04:08, 10 July 2011 (UTC)[reply]

Image update problems

I'll just copy and paste this from helpdesk. They told me to ask here. I'm here to report a possible bug. When I upload a new version of an image at a different resolution, the image does not update, but it takes the new image's dimensions causing it to distort, stretch or squeeze. I've tried all possible options such as purging the cache, clearing my browser etc. If I rename the image, it updates to the newer version but that's the only way. It'd be ridiculous if I had to rename every image I upload. Any help would be appreciated. Thanks, ..George Sorby • Talk • Contribs .. 15:08, 7 July 2011 (UTC)[reply]

Known problem: Bugzilla:28613. — Edokter (talk) — 15:49, 7 July 2011 (UTC)[reply]

I have had this problem in the past, usually ctrl-shift-r/f5 works for me. /ƒETCH COMMS / 16:22, 7 July 2011 (UTC)[reply]

It could be bugzilla:28613, but usually it's just your browser cache like Fetchcomms said. See also how to bypass your browser cache. —TheDJ (talk • contribs) 20:19, 7 July 2011 (UTC)[reply]

Mis-sorted articles in categories

Sometime in the last day or so, it looks like something happened to the internal storage of some sort keys. I'll explain:

When I look, for example, at this page of the Living People category, I currently see 4 articles. All 4 have DEFAULTSORT statements with sort keys that should place the articles on a different page in the category. The page should be blank, and it was yesterday (I'm a sorting gnome, and I check it most every day). None of the 4 articles show recent edits.

Whatever happened doesn't appear to be affecting current edits. When I first looked at the category page, there were 6 articles listed; I edited 2, fixing the sort key on one article (Bruno César, a typical Iberian naming foulup) and on the other article (Bonnie Zacherle) leaving the sort key unchanged but making MOS edits. In both cases, the article subsequently was to be found on the right page of the category.

This problem is not unique to "from=Zzz", it's easily visible on some other pages in the category:

At the moment, it looks like (extrapolated guess) about 1/10th of a percent of the articles in the Living people category are not showing up on the right page; affected articles are not just mis-sorted in that one category, but in all categories in which they appear. For example, Steven W. Taylor is in the wrong spot in this category page - http://en.wikipedia.org/w/index.php?title=Category:United_States_Marine_Corps_officers&pagefrom=T Studerby (talk) 17:18, 7 July 2011 (UTC)[reply]

Probably left overs from the changed collation in the sort algorithm for categories that was deployed a month or so ago. A purge or null edit should resort them. —TheDJ (talk • contribs) 20:25, 7 July 2011 (UTC)[reply]

While a null edit appears to fix them, and it's possibly related somehow to the category fix from a while ago, they weren't there yesterday. Really... I look at "from=Zzz" every day, and most of the "Living People" category pages with "from" for [A-Y]zz every week or two, looking for mis-sorted biographical articles (articles where the first or second letter has a diacritic, resulting in a mis-sort - after the 2nd letter, they're going to be close enough to where they should be in almost all categories that they'll be findable by the average user). In other words, something in the last 24 hours triggered the shift of the placement of these articles; if it's also related to the change, then it's a 2-factor issue. And it doesn't seem to be just biographical articles (though I don't know if these are older or of recent vintage):

I don't see this as a crisis if the back-end folk know what's going on and are reasonably sure it's not going to happen again; any edits will fix them, and frankly it's mostly gnomes of various stripes that care deeply about sorting anyway. While a mis-sorted list doesn't look good and I'm personally a bit frustrated, categories are just not looked at that much by the general public (IMHO), so 1/10th of 1% and declining isn't a crisis, if it's understood. So far, I don't think it is; I'll certainly speak up if it happens again, and I hope the back-end folk at list think about what might have triggered this change.Studerby (talk) 20:52, 7 July 2011 (UTC)[reply]

Two RfCs for allowing bureaucrats to remove the admin bit

Two related Requests for Comment are now open to discuss giving bureaucrats the ability to remove administrator user permissions under specific circumstances. Wikipedia:Requests for comment/Granting bureaucrats the technical ability to remove the admin flag proposes enabling the technical ability for bureaucrats to do this. Wikipedia:Requests for comment/Bureaucrat removal of adminship policy proposes the specific policy conditions under which they would be allowed to use that ability. Please visit both RfCs to give your input. Thanks. --RL0919 (talk) 20:13, 7 July 2011 (UTC)[reply]

Chesterton link

This help request has been answered. If you need more help, you can ask another question on your talk page, contact the responding user(s) directly on their user talk page, or consider visiting the Teahouse.

I noticed that a link in the mobile version pointed to a different (wrong) place from the full version. It is Wiener Library in G K Chesterton. I thought I ought to tell someone, but don't know`who. I've had a look through recent history, assuming it was just a time delay in correcting vandalism, but have not spotted any change to the link. The link in the mobile version was to the article Joseph Pearce, but later, when I rebooted the iPhone, all was well.

I did get a reply to this from John of Reading, who ‘cancelled” the HelpMe, and suggested ‘we’ ‘move on’ – puzzling really, as ‘we’ have not paused. Maybe he thinks I imagined the misdirection. I did not, and am concerned that a link can be tampered with without leaving a trace. Please, John O'R, do not ‘cancel’ again, but leave it for someone to see who understands and shares my concern.John Wheater (talk) 22:14, 7 July 2011 (UTC)[reply]

Another user suggested I had clicked on a footnote and then another link, thinking I had just clicked on the Wiener link. Not so!John Wheater (talk) 22:22, 7 July 2011 (UTC)[reply]

Just for the record, here's my reply. -- John of Reading (talk) 07:57, 8 July 2011 (UTC)[reply]

(outdent) It would probably help if I tried to summarised the technical issue. The article G K Chesterton has a link to Wiener Library; five sections further down it has a link to Joseph Pearce. John Wheater reports that he clicked on the "Library" link and ended up at the "Pearce" article. The problem went away after a reboot. So:

Can anyone think how the HTML code for the page could have been scrambled as it was transmitted or loaded, so that the link went to the wrong URL?
Or, can anyone think how the iPhone software could have misjudged the position of the click on the "Library" link, so that it acted as if the "Pearce" link had been clicked?

(John W, is this a fair summary?) -- John of Reading (talk) 21:10, 8 July 2011 (UTC)[reply]

WHAT HAS HAPPENED TO WIKIPEDIA ?!

Someone posted this at Talk:Barack Obama but I'm moving it here for a quicker response. Hot Stop (c) 15:37, 7 July 2011 (UTC)[reply]

sorry for using caps and i am aware that this meybe not belong here(feel free to move it)but now that ive got your attention what happened to the infoboxes on all biographic articles on wikipedia ?! the text is smaller and evrything actually is smaller , why is that ? can somebody inform me or atleast make a reference to why it is soFREESAVELIY ^talk 15:27, 7 July 2011 (UTC)[reply]

Sounds like you changed the textsize in your browser by accident (Often happens when you press a modifierkey and use the scrollwheel at the same time). Which browser are you using ? For me under Safari I have "Actual size" as an option under the "View" menu. That restores 'normal' textsize on Safari for me. —TheDJ (talk • contribs) 20:21, 7 July 2011 (UTC)[reply]

no am using the latest version of google chrome and microsoft internet explorer and it is normal text size settings, this is not a problem for just me this is a problem for evryone, please compare the infobox textsize before and after 7 juli 2011 then you will see what i meanFREESAVELIY ^talk 00:28, 8 July 2011 (UTC)[reply]

I think it must be your problem, I don't see anything wrong.--SPhilbrick T 00:37, 8 July 2011 (UTC)[reply]

What do you mean ? do you accept the changes or do you not see them, not my problem hereFREESAVELIY ^talk 00:45, 8 July 2011 (UTC)[reply]

I don't see any evidence that the text in the infoboxes has changed size materially.--SPhilbrick T 11:39, 8 July 2011 (UTC)[reply]

I'm guessing without much looking into it that this might be related to the discussions at Template talk:Infobox officeholder#Terrible Changes and Template talk:Infobox officeholder#Trying this again. Wtmitchell (talk) (earlier Boracay Bill) 00:52, 8 July 2011 (UTC)[reply]

[3] Text size was changed from 90% to the default for the infobox class, which is 88% - the difference is only visible at some zoom levels. Peter E. James (talk) 01:04, 8 July 2011 (UTC)[reply]

I really see no reason for using smaller fonts. We should use the smallest easily readable font and then never go any smaller. To go smaller creates accessibility issues. Rich Farmbrough, 14:48, 9 July 2011 (UTC).[reply]

link underline color

As a user of the “Underline links: Always” setting, I noticed how when people get cute about link colors they usually do something like this:

[[Foo|<span style="color:orange;">Bar</span>]]

Bar

and that this causes the underline color to remain blue (#002BB8) instead of matching the span color (see [4]). One solution for this would be to use the following in concert with the “Underline links: Always” setting:

a, a * { text-decoration:underline; }

This will allow elements inside the <a> tag to underline in the current text color. Ideally we would have some way to specify the properties of the <a> tag itself, but this will have to suffice. ―cobaltcigs 16:37, 8 July 2011 (UTC)[reply]

Curiously, if the <span>...</span> specifies the background colour, it's browser dependent whether or not the underline is shown. Try hovering your mouse over the first 9 characters of my signature: Google Chrome, IE7 and Opera underline all, but Firefox and Safari don't underline the first 3, only the next 6. --Redrose64 (talk) 16:54, 8 July 2011 (UTC)[reply]

That has to do with line-height issues more than anything, whether the underline is inside or outside the area affected by the background. In my browser the light-gray rectangle does in fact cover up the blue underline. If I rewrite your sig as Redrose64 I see a red underline on top of a light-gray rectangle, on top of a blue underline (see difference). ―cobaltcigs 19:17, 8 July 2011 (UTC)[reply]

The ", a *" is an uncommon construction, incidentally. If you have a specificity problem, you should use !important. - Jarry1250 ^{[Weasel? Discuss.]} 18:46, 8 July 2011 (UTC)[reply]

Merely using a { text-decoration:underline !important; } makes no difference. It simply makes the blue underlining of the <a> tag more important. It does not underline the colored interior span (using the text-color of said span) which is the goal here. ―cobaltcigs 19:17, 8 July 2011 (UTC)[reply]

.colorlink a {color:inherit;} + <span class="colorlink">[[foo]]</span> should do the trick for both prefs. It won't work with external/extiw/new unless the specificity is increased (with !important for example), but IMHO that is probably the desired operation. --Splarka (rant) 07:24, 9 July 2011 (UTC)[reply]

Derp. Actually, on further retrospection, you should just be able to do it inline: [[Foo|<span style="color:orange;text-decoration:inherit;">Bar</span>]] -> Bar. --Splarka (rant) 05:48, 10 July 2011 (UTC)[reply]

I don't think people should be getting cute about link colours. It breaks look and feel, HCI and accessibility. Rich Farmbrough, 14:50, 9 July 2011 (UTC).[reply]

Odd behaviour in category

If I load up Category:All free media, the first 130 images are images that have a CSD notice on them, then I get 70 images as expected. If I then select "next 200" - I get a page with the same 130 images and the next lot of 70 images. Should there bee 200 images witha CSD, I doubt if I can see anything else. I've used 2 browsers, on 3 PCs and logged in and logged out - all do the same. Ronhjones ^(Talk) 20:38, 8 July 2011 (UTC)[reply]

I was able to duplicate the issue with Fx 4.0 on Win 7x64 just by taking a look. That's just bizarre. --Izno (talk) 22:04, 8 July 2011 (UTC)[reply]

Off to Bugzilla then? User<Svick>.Talk(); 13:01, 9 July 2011 (UTC)[reply]

Well that will be a first, but I'll give it a whirl. Ronhjones ^(Talk) 14:18, 9 July 2011 (UTC)[reply]

https://bugzilla.wikimedia.org/show_bug.cgi?id=29787 Ronhjones ^(Talk) 14:25, 9 July 2011 (UTC)[reply]

(Partially) italic titles?

I was trying to change the displayed title of Hot Coffee mod from "Hot Coffee mod" to "Hot Coffee mod" by adding a DISPLAYTITLE template - but, it would seem, to no avail. I checked Guitar Hero (video game), and that seems to manage a partially italic title without any template whatsoever. Please advise. It Is Me Here ^{t / c} 23:01, 8 July 2011 (UTC)[reply]

Fixed in [5]. The infobox also set DISPLAYTITLE after you. PrimeHunter (talk) 23:15, 8 July 2011 (UTC)[reply]

Thanks very much! It Is Me Here ^{t / c} 10:33, 9 July 2011 (UTC)[reply]

How Wikipedia stops the nonsense bots

Wikipedia (& other Wikimedia sites) have no CAPTCHA for anon edits that don't contain a url. It also does not use the Bad Behavior extension for MediaWiki, is a much greater spam target than other wikis, and yet isn't overwhelmed by nonsense bots. How does it manage this? Is it just that those edits are reverted and the IP blocked so quickly that we don't see them? That's the only explanation that I can think of, but don't the bots just change IP address for every edit? Seeing other wikis get hammered by nonsense bots, I'm really curious how the Wikimedia wikis escape.

This would be useful to know for other wikis I work with - thanks. --Chriswaterguy talk 07:56, 9 July 2011 (UTC)[reply]

It's very difficult for a bot to "just change IP address for every edit". Wikipedia is pretty aggressive about blocking TOR exit nodes and other proxies, which greatly limits attackers' capacity to change IP with an effective frequency. Anti-vandal bots like Cluebot catch much of the dumb stuff, and edit filters do more. But the real reason is one of population - en.wikipedia has a very large number of active users, and lots of people with anti-vandal tooks like Twinkle. The vandals and spammers, even those with bots, are outnumbered and outgunned. This isn't an innate property of all wikis (nor of all Wikimedia wikis); en.wikipedia's editor base grew organically as its size and readership grew; there's no reason to suppose that if someone sets up a wiki in general that it won't be overwhelmed. I regularly see someone who has set up MediaWiki on their host somewhere and breathily hopes that "if you build it they will come", that a Wikipedia-like community will magically condense there and make wonderful things - in practice they get pasted by spambots because they don't have an adequate userbase to police their wiki. -- Finlay McWalter ☻ Talk 14:09, 9 July 2011 (UTC)[reply]

If they desired, of course, they could use WP's IP blocking as a blacklist. They do have the features Chris mentions avaialbe though. (And note that we do require captchas for certain critical actions like account creation.) Rich Farmbrough, 14:53, 9 July 2011 (UTC).[reply]

Is there a MediaWiki plugin that makes doing that (mirroring another wiki's block list), for a minor wiki, practical? -- Finlay McWalter ☻ Talk 17:11, 9 July 2011 (UTC)[reply]

I'd also like a way to mirror Wikimedia projects' blocking of proxies. Thanks for the answers. --Chriswaterguy talk 20:39, 9 July 2011 (UTC)[reply]

Oh, and to support Finlay's point, part of the reason some of the MediaWiki prokjects have been mothballed is inability to keep up with vandalism. Rich Farmbrough, 14:54, 9 July 2011 (UTC).[reply]

I agree with the point about making a wiki not being just a matter of setting up and waiting for people to come. I actually wrote Appropedia:How to make a successful new wiki - the main point being that it's hard, and that too many people have set up green wikis or whatever without properly looking at what others are doing.

But for those of us who are doing a serious job, including keeping spam under control, learning from how Wikimedia projects do things is extremely valuable. --Chriswaterguy talk 21:11, 9 July 2011 (UTC)[reply]

BTW, all Wikimedia sites do use a CAPTCHA for anonymous edits that contain a URL; I just tested it myself. Graham87 04:42, 10 July 2011 (UTC)[reply]

Wikipedia email from non-existent user

How is this possible? See WP:ANI#Spam from Wikialpha. Thanks. Dougweller (talk) 11:53, 9 July 2011 (UTC)[reply]

I'll take a stab at this. I think when not logged in, any user can still see the e-mail user function for users who accept e-mail. Thus, it's possible for an IP user to send an e-mail to someone. I do wonder why you can't be required to register first, but there's surely a reason IPs are allowed to do that. CycloneGU (talk) 15:08, 9 July 2011 (UTC)[reply]

Good stab, but the e-mail user function is only available to accounts who can receive email in return. --jpgordon^{::==( o )} 15:14, 9 July 2011 (UTC)[reply]

So they see the option but, when clicking it, are told they cannot use it? Hmm.

In that case, I'd be curious myself. It sounds like Dougweller was the recipient of the e-mail. We might need an e-mail header or something (not the actual address it came from or the e-mail itself, just the templating and such), but I'll let the technical experts address this. CycloneGU (talk) 15:20, 9 July 2011 (UTC)[reply]

Indeed you need to have an account to have the minimum requirement (which means being in the "User" group) to be authorised/ability to use the EmailUser function. Bidgee (talk) 15:25, 9 July 2011 (UTC)[reply]

Any registered user can access the email function if they have a valid email address. AFAIK email addresses can also be shared between accounts. I was previously sent email from WikiAlphaBot (talk · contribs), which has no edits and existed primarily to access the email function. It's likely here that the email is coming from a registered account but they aren't saying the account here. elektrik SHOOS (talk) 16:26, 9 July 2011 (UTC)[reply]

I'm getting the emails after WikiAlphaRobot was blocked. I'm also getting more of the emails. User is VallorVir. Great, do a AfD and get spammed every time. Bgwhite (talk) 16:56, 9 July 2011 (UTC)[reply]

While I was typing, Dougweller put a block on the account. So, spammer is now blocked. Bgwhite (talk) 17:04, 9 July 2011 (UTC)[reply]

Creating Categories

All right, this is one of those rare times I am clueless. I have attempted to create categories for a new template, Template:WikiProject_South_Sudan, but I am lost. For example, Category:High-importance South Sudan articles is one of the many I had to set up to make the new template work. Obviously we add the category to the page we want in that category, but is there anything else I need to do to make it work? Is anyone willing to check my work (see my contribs) and ensure I didn't screw up somewhere? Mostly, I need help getting the template set up to allow quality rating and importance rating, which may take care of a lot of needed categories over time. CycloneGU (talk) 15:05, 9 July 2011 (UTC)[reply]

I'm in the process of setting up some of the categories right now, and I've adjusted the template to allow quality and importance ratings. elektrik SHOOS (talk) 17:36, 9 July 2011 (UTC)[reply]

I noticed the latter, that was an important thing to fix in there. Thanks for adding that. I created a few more class categories in the meantime and got this working with Carl's (CBM) help, so it's now on the WikiProject page. CycloneGU (talk) 18:09, 9 July 2011 (UTC)[reply]

Percentage of thumbnail size, or minimum size unless thumbnail is larger?

In some articles the images are important enough to retain detail and exceed the thumbnail size, which can be quite ridiculously small. However, these absolute settings work against the user when their monitor resolution is high enough that they actually need fairly huge thumbnails, that are bigger than the absolute setting.

Is there some way to specify that certain images should always be a certain percentage larger than the thumbnail default?

Or that an image should at least be a certain size, unless the user's thumbnail setting is set to a higher size?

DMahalko (talk) 15:17, 9 July 2011 (UTC)[reply]

See WP:PICTURE, MOS:IMAGES and examples at right. --Redrose64 (talk) 18:25, 9 July 2011 (UTC)[reply]

Browser page zooming: Higher detail thumbnails?

Is there some way to make images appear in a zoomed browser window with higher detail than what is seen by simply zooming the window and the browser stretching the images from the "normal / 100%" zoom size?

Normally I use Firefox with the zoom being +5 over the normal setting (Ctrl-Plus 5 times, it doesn't show what percentage that is). It would be nice if I actually got higher detail images from Wikipedia, rather than FF just stretching the 100% size image.

DMahalko (talk) 15:23, 9 July 2011 (UTC)[reply]

The zooming is done on your computer, Wikipedia has no knowledge of it, so there is no way to do it directly. Apparently, there is no reasonable way to do it using JavaScript either. The only way I can think of doing this would be a script in which you set the zoom level and it would download bigger images based on that. User<Svick>.Talk(); 15:47, 9 July 2011 (UTC)[reply]

The only way to have more detailed images is to increase your thumb size in your preferences. Then you may want to check a little script I've been working on: User:Edokter/FontSizer.js (see my user page on how to use). — Edokter (talk) — 19:49, 9 July 2011 (UTC)[reply]

Tlrow template not working

On the Wikipedia:Template messages/File namespace#Non-free images page, about half way down that section, after the row with {{Non-free logo}} in it, the rows in the table are appearing to be broken. I can't find where the error is, whether it's in the Non-free logo template or elsewhere. Appreciate someone's technical expertise here!! --Funandtrvl (talk) 18:37, 9 July 2011 (UTC)[reply]

The problem lies within {{non-free logo}} or one of its subtemplates, and isn't on the WP:TMFN page. There's something about the combination of a table, the {{imbox}} template and the numeric list ("This tag is not sufficient on its own ...") that is causing the table to be closed prematurely. --Redrose64 (talk) 19:20, 9 July 2011 (UTC)[reply]

OK, thanks, I'll put a request on the non-free logo template talk page. --Funandtrvl (talk) 19:27, 9 July 2011 (UTC)[reply]