Resolved

succession box on this page is not working pl help.[1].User:Yousaf465 (talk)

Moved to: Wikipedia:Village pump (policy)#Icons in sidebars.

Guys and gals, I am having a heck of a morning. can anyone remind me how to use the parser functions to check namespace value to assign a category? Basically, IF Namespace = Template Then Category:Nav Templates

Got up too early, went to bed too late. Thanks for the help.

[[User:Tigey|Expression error: Unexpected < operator]] ^{[[User_Talk:Tigey|Expression error: Unexpected < operator]] [[Special:Emailuser/Tigey|Expression error: Unexpected < operator]]} 14:21, 6 April 2009 (UTC)

{{#ifeq:{{NAMESPACE}}|{{ns:Template}}|[[Category:Nav Templates]]}}
Amalthea 14:49, 6 April 2009 (UTC)[reply]

Or use one of our easy to use namespace detection templates such as {{template other}}. Or if you need more complex detection use {{namespace detect}}. For instance like this:

{{template other
| [[Category:Nav Templates]]
| <!-- Don't categorise when not in template space. -->
}}

Since the namespace detection templates have the "demospace" feature they can be much better to use than to hardcode the detection, since it makes it possible to test and demonstrate the different behaviours of your template in its own documentation.

--David Göthberg (talk) 15:10, 11 April 2009 (UTC)[reply]

Yeah but I think the bare parser function is more comprehensible to almost anyone. — CharlotteWebb 19:11, 13 April 2009 (UTC)[reply]

Resolved.

The dev's seem to have broken recursion so now {{NextArchive}} doesn't work (a template I hacked together in my spare time; not widely used). See the template's wikitext for details on how it worked. Why doesn't that work anymore? I was thinking of extending it to {{FAC}}, but now I can't. I know it's a horrible hack, but if you don't like how my code looks, don't make me program in the equivalent of a COBOL/Pascal hybrid; give me sanity, or at least turing completeness. This type of check should be trivial, but now I can't see how to do it at all without writing a lot of boring code (like {{FAC}} is right now) and tying yourself to an arbitrary upper bound. --Thinboy00 @933, i.e. 21:23, 6 April 2009 (UTC)[reply]

This was deliberate, because these sorts of infinitely recursing templates were taking up ~40% of the CPU time of the entire Wikimedia cluster and also causing fatal OOM errors. If you want to discuss it, contact Domas Mituzas or Tim Starling on IRC.

Wikitext is not supposed to be a programming language, it's supposed to be a markup language. — Werdna • talk 04:04, 8 April 2009 (UTC)[reply]

Too late. I think it's Turing-complete these days. --Carnildo (talk) 08:31, 8 April 2009 (UTC)[reply]

Thinboy00: I have spent some day thinking about your problem. I think I now have a much more efficient solution for your {{NextArchive}} template and some other archive templates. But it is too complex to explain here. I will contact you when I have coded up those solutions. It might take some time, I am pretty busy, although this is the kind of programming I love to do. :))

--David Göthberg (talk) 14:41, 11 April 2009 (UTC)[reply]

Sounds like Fermat's last solution. Gimmetrow 15:50, 12 April 2009 (UTC)[reply]

Gimmetrow: Okay, you provoked me to disclose what I am going to do. But don't blame me if you get a headache from reading this:

As far as I know: The only way to find out how many archive pages a page has is to use the #ifexist parser function, since we must check if the archive pages exist or not. But #ifexist is a rather expensive operation since the server that parses the template has to call one of the database servers to check if the page exist or not.

But we don't need to check all the archive pages, we just need to find the last one. So I am going to use a binary search to find the last page. (But with some modifications so it works better in template code, and so we find low values faster.) Thus I can find the last archive page in the range 1-1000 with about 11 #ifexist calls. (WP:ANI already has 529 archive pages...) That is much more efficient than the approaches used now. If we need to check higher numbers I can do that too. I have already coded a binary search for another template that searches the range 0-500, so I know how to do it.

--David Göthberg (talk) 18:11, 12 April 2009 (UTC)[reply]

I thought of that, too. It just didn't seem necessary for my application, where the vast majority of searches involve less than 10 items. I figured, if it became necessary to handle more than 10, an increasing binary search tree could be used so that low numbers were found without too much penalty. Gimmetrow 20:41, 12 April 2009 (UTC)[reply]

Ah, "increasing binary search tree", good name for it. That is what I use in {{str len}}. Check out the documentation in {{str len/core}} if you are in the mood.

--David Göthberg (talk) 21:07, 12 April 2009 (UTC)[reply]

Just curious, but did you do any analysis to come up with the division used at str len/core? On finding archive pages, I thought perhaps this approach: test N, then 2N, then 4N, then 8N, then 16N, etc. to find bounds, then binary search within those bounds. N would depend on the expected distributions. If you did that with string lengths, you might use N=32. Gimmetrow 23:28, 12 April 2009 (UTC)[reply]

Since I am just about to create the {{number of archives}} template I have copied this discussion to Template talk:Number of archives and responded there. Please continue this discussion there. And a teaser: My user space prototype for {{number of archives}} already correctly reports that WP:ANI has 529 archive pages!

--David Göthberg (talk) 10:09, 13 April 2009 (UTC)[reply]

Is there a way to count the number of editors that actually set date preferences?

I am sure that there is already a count of the number of registered editors. But it would be interesting to have a count of the number of editors that actually set a date preference. This would help inform the debate about autoformatting and the vote that is about to end at: Wikipedia:Date formatting and linking poll. We solve other variations such as 'color/colour' without needing markup. It would be useful to know the statistics on usage of this bizarre feature of Wikipedia to see if it is worth all the trouble. Lightmouse (talk) 10:00, 10 April 2009 (UTC)[reply]

You need to run a SQL query like

USING enwiki
SELECT COUNT(*) FROM user
WHERE LOCATE( 'date=default' , user_options ) == 0

On a complete copy of the enwiki user database table. Which is not replicated to the toolserver. So you'll need to ask the devs to do it. And there are about 9 million rows in that table. You might need to pester the devs for some time :D Happy‑melon 10:49, 10 April 2009 (UTC)[reply]

      1 date=hh:mm d.m.yyyy
      1 date=12
      1 date=ISO dt
      1 date=vi longmonth
      1 date=9
      1 date=km
      1 date=hh:mm d mon y
      1 date=hijri
      1 date=vi spelloutmonth
      2 date=ÄŒSN basic td
      2 date=yue ymd
      2 date=hh:mm d. mon y.
      2 date=h:mm d month y
      2 date=ÄŒSN padded dt
      2 date=dmy short
      2 date=ÄŒSN padded td
      2 date=h:mm d mon y
      2 date=fy normal
      3 date=hh:mm dd.mm.yyyy
      3 date=yue dmy
      3 date=h:mm d. mon y.
      4 date=vi shorth
      5 date=ko
      5 date=dmy hr
      5 date=7
      6 date=yue
      6 date=PÄŒP dt
      6 date=tdmy
      6 date=hh:mm d month y
      6 date=h:mm d. month y.
      8 date=thai
      8 date=h:mm dd.mm.yyyy
     10 date=on
     14 date=vi shortcolon
     14 date=alt dmy
     14 date=short dmyt
     14 date=dmy full
     18 date=et numeric
     20 date=ja
     23 date=fi seconds
     28 date=vi normal
     34 date=persian
     37 date=dmyts
     55 date=ÄŒSN basic dt
     58 date=hh:mm d. month y.
     60 date=fi normal
     61 date=fi numeric
     68 date=dmyt
     92 date=zh
   1898 date=4
   2031 date=3
   4702 date=ymd
   5933 date=
  17876 date=ISO 8601
  44032 date=2
  47158 date=1
  72480 date=dmy
  84787 date=mdy
1723038 date=0
7242868 date=default

Lot of crap in there, which is why Werdna is rewriting the preferences system. --Splarka (rant) 07:15, 11 April 2009 (UTC)[reply]

Thanks. I am trying to translate that into statistics for the five date preference options. It looks to me like:

• 7,242,868 have it set to the 'No preference' option
• 84,787 have it set to the mdy option
• 72,480 have it set to the dmy option
• 4,702 have it set to the ymd option
• 17,876 have it set to the ISO8601 option

Is that correct? Lightmouse (talk) 08:44, 11 April 2009 (UTC)[reply]

Well 7 million have left it on the "no preference" option. Other than that, yes, I think that's right. Happy‑melon 09:26, 11 April 2009 (UTC)[reply]

The phrase left it implies that they have never changed it. How do we know that users don't change it and then change it back? My phrase was have it set which is more neutral. I see that 'date=0' has 1.7 million users. So my second question relates to these 'date=n' values. Are 'date=0' editors also using 'No preference? Lightmouse (talk) 09:52, 11 April 2009 (UTC)[reply]

Oh sorry, I read it as "have set it", which is equally unsupported; your version is indeed the most neutral. I'll have a dig through MediaWiki, see if I can work out what the other values evaluate to. Happy‑melon 11:29, 11 April 2009 (UTC)[reply]

Tried and failed. What a mess! Good luck Werdna! Happy‑melon 11:48, 11 April 2009 (UTC)[reply]

0 is "default", 1 is "mdy", 2 is "dmy", and 3 is "ymd", at least in English (see $datePreferenceMigrationMap in MessagesEn.php). BTW, it seems that having these numeric codes means the account has not saved any changes to their preferences since 2006, or the preference would have been automatically updated to the more familiar string key. It seems most of the odd values originate from non-English message files; does uselang give you the other language's date options? Anomie⚔ 15:24, 11 April 2009 (UTC)[reply]

Thanks. That would make the figures:

• 8,965,906 have it set to the 'No preference' option
• 131,945 have it set to the dmy option
• 116,512 have it set to the dmy option
• 6,733 have it set to the ymd option
• 19,774 have it set to the ISO8601 option

Using the 'date=x' figures and assuming that 'date=4' is ISO8601, it shows that 3.0% of editors have something other than 'No-preference' (the previous figure using post-2006 settings was 2.4%). Is that correct? Lightmouse (talk) 19:24, 12 April 2009 (UTC)[reply]

If those statistics are correct, it looks like 98% of registered editors have it set to 'No preference'. Lightmouse (talk) 11:56, 11 April 2009 (UTC)[reply]

How many of those 98% are indefinitely blocked (vandals, bad usernames, etc), vandals that abandoned the account upon receiving a final warning, abandoned SPAs, or other accounts that probably left all prefs at the default? Anomie⚔ 15:24, 11 April 2009 (UTC)[reply]

We don't have 47,333,722 "real" users. Under the current preferences system, all preferences are saved in the database at the default, so one cannot assume that the user specifically set that or even that they were aware that they could change it. Mr.Z-man 16:18, 11 April 2009 (UTC)[reply]

If setting a preference affects the likelihood of being inactive, that would be bizarre. But if you can get the statistics on that or any other factor, please post them. The debate has been long on opinion and short on statistical evidence. Lightmouse (talk) 16:51, 11 April 2009 (UTC)[reply]

Don't be obtuse. He's only saying that the most accounts have not been used in a meaningful sense, and that the presence of a default preference setting should not be interpreted as a preference not to set any preference. I don't suppose there's any way we could get statistics for "auto-confirmed" users (which by definition have at least ten edits). I think if you set a higher threshold for serious involvement with the project you'll find a lower rate of user-prefs apathy. — CharlotteWebb 17:20, 12 April 2009 (UTC)[reply]

I don't know what obtuse means, but it sounds like a bad thing. If you (CharlotteWebb) think I am a bad person, that doesn't matter. What matters to the community is evidence about how often autoformatting is used. It would help the debate if somebody could tell us all what 'date=0' and 'date=1' means. Statistics on autoconfirmed users would be interesting too, as CharlotteWebb suggests. The truth will set us all free. Lightmouse (talk) 17:49, 12 April 2009 (UTC)[reply]

Actually Lightmouse the current usage is irrelevant. If people want something we work on giving it to them, we don't assume bad faith and question their motives for wanting it... —Locke Cole • t • c 18:03, 12 April 2009 (UTC)[reply]

According to Nielson Online[2], en.wikipedia.org had 56 million unique visitors in April 2008. It appears that around 275 thousand users in the history of Wikipedia have set a date preference. It is unknown how many of these people are still active and log in when reading Wikipedia. (If you are not logged in, date autoformatting doesn't work.} The best case with these numbers is that 1 out of 200 readers benefits from date autoformatting. The Nielson survey shows most of Wikipedia readers arrive here via a search engine. When searching for information about the compulsive detective, Monk, I am sure the reader would remember to log in when they arrive at Wikipedia. -- SWTPC6800 (talk) 02:39, 13 April 2009 (UTC)[reply]

Probably they don't, but if they are using a personal computer they probably hit "Remember me" when they log in. --A. di M. (formerly Army1987) — Deeds, not words. 23:07, 13 April 2009 (UTC)[reply]

No matter which section is edited, the section name is automatically appeared in the edit summary, except lead section. I suggest that the edit summary should indicate "lead section" as other sections. This little change can help to make it easier to follow the edit history, like find out whether an edit is or is not related a particular section. Some other Wikipedia has already done so. --Quest for Truth (talk) 19:22, 11 April 2009 (UTC)[reply]

I agree - that would be useful. Then edits of the whole page would be more easily distinguishable from edits to the lede only.Tvoz/talk 19:52, 11 April 2009 (UTC)[reply]

I think that would be a worthy idea. It would certainly make it less difficult to follow the edit history of an article. tempodivalse [☎] 19:58, 11 April 2009 (UTC)[reply]

If you don't mind too much about the section name that appears in the edit summary, this can be done easily by adding "summary=/* firstHeading */ " to the section edit link, like this one.
I assume you use the editTop gadget? --Amalthea 20:52, 11 April 2009 (UTC)[reply]

Where is it supposed to link to? — Edokter • Talk • 22:51, 11 April 2009 (UTC)[reply]

To the <h1 id="firstHeading"> with the page title: #firstHeading. Another option is #top. The problem is, older skins such as "Classic" do not have these IDs in the HTML. —AlexSm 23:30, 11 April 2009 (UTC)[reply]

It can simply link to the article without anchor. This will always load the top of the page where the lead section is found. --Quest for Truth (talk) 10:29, 12 April 2009 (UTC)[reply]

It can even be text only as well! It is more important that the edit summary indicates only the lead section is edited. Where it links to is a rather not so important issue. --Quest for Truth (talk) 00:11, 14 April 2009 (UTC)[reply]

I really don't see the point in this. Those who take edit summaries seriously might consider the possibility that pre-filled comments like "/* In popular culture */" actively discourage attempts to "briefly describe the changes [they've] made" (assuming it is possible to actually do so). I think this also tends to confuse new users. Many times I've seen silliness like

(→added 2 paragraphs about homestar runner)

in recentchanges or on my watchlist because somebody has gotten the false impression that the edit summary is supposed to go between the slashes and asterisks. But hey as long as we're mucking around with this feature we should darken the light-gray color to make it more readable against a white background. — CharlotteWebb 17:56, 14 April 2009 (UTC)[reply]

you know, I'm going to throw this idea out there, because it's something I keep finding myself missing. would it be possible to make a special page (like the watchlist) dedicated to making notes to yourself? I'm thinking a tab or link (like the 'watch' tab) that you can click on to add a given page to your notes page, and then on the notes page itself, have a link to each page with some space to leave notes (maybe have the links constructed as section headers, or something like that). of course, I could build something like that on a user subpage, but that's got two drawbacks that have kept me from doing it so far: (a) it's a pain to set up and maintain, and (b) it would be public, and I'm not sure I want the dumb things I'm mulling over available for everyone to read. thoughts? --Ludwigs2 00:06, 12 April 2009 (UTC)[reply]

bugzilla:541#c2 --Splarka (rant) 07:33, 12 April 2009 (UTC)[reply]

B: Having a secret subpage like that could be abused in many ways. (Note: Don't confuse this with what we usually mean by "secret user subpage" = subpages in user space that are not linked from anywhere.) And I see in the bugzilla request that Splarka linked too that Brion said "NO". I think an acceptable solution perhaps could be if such a subpage were only visible for all logged in users. Thus it at least would not be visible for the search engines and the Wikipedia readers.

A: The "one click bookmarking" functionality can be coded in javascript as a user script. So I went looking, and there already exist two such readymade scripts! See User:Twinzor/Wikimark and user:js/popupBookmarks. I have not tested any of them, so I don't know how well they work, but they look promising.

Personally I use a text file on my hard disk for my Wikipedia notes and to-do list. And more "permanent" bookmarks I manually add to my user page. But I only edit Wikipedia from home. But I know many Wikipedia editors are more nomadic so I can see the need for an easy to use bookmarks+notes page.

--David Göthberg (talk) 12:52, 12 April 2009 (UTC)[reply]

lol - I see that issue produces some strong feelings. I hadn't actually thought about the javascript solution, but those look interesting. I'll check them out. and your 'logged in user' idea might work, though I'm still not sure I'd want my off-the-cuff thoughts enshrined forever in a public edit history. but if I could just make a decent bookmark list, that would be a good start. thanks. --Ludwigs2 16:22, 12 April 2009 (UTC)[reply]

This matter is also being discussed on the proposals page under 'favourites section' JRGregory (talk) 23:23, 15 April 2009 (UTC)[reply]

A few weeks ago, I was asking about the disappearance of automatic deletion summaries. I think I now know the cause. It seems when this edit to MediaWiki:Sysop.js was made to introduce some new code, it also removed the old code that generated automatic deletion summaries in the process. Is there a way to bring this "feature" back? Unfortunately, I am unable to do this myself since I suck at JavaScript/CSS coding, and there's probably a 99.99% chance I would mess something up if I tried anything. --Ixfd64 (talk) 02:03, 12 April 2009 (UTC)[reply]

"content was ..."/"only contributor was ..." default deletion summaries have been disabled, as it's never an appropriate rationale for deletion and was highly problematic for attack pages, etc. The discussion for removal is here, disabling this caused some side effects, but since then, it's been resolved. Cenarium (talk) 02:25, 12 April 2009 (UTC)[reply]

Ah, I guess that explains everything. Thanks for the information! --Ixfd64 (talk) 03:29, 12 April 2009 (UTC)[reply]

If you or anybody else really wants this and plans to use it I think I know how to make a javascript gadget to mimic the old behavior. — CharlotteWebb 17:05, 12 April 2009 (UTC)[reply]

Sure, that would be great. Maybe someone could make a user script or something. :) --Ixfd64 (talk) 21:00, 12 April 2009 (UTC)[reply]

Ew, a script to undo a script. — Werdna • talk 05:05, 13 April 2009 (UTC)[reply]

Well, since the first statement in the section was incorrect (the change was done by blanking system messages, not by the Sysop.js), the new would-be script would try to reproduce MediaWiki functionality. Or it could be even better, e.g. adding the number of deleted revisions. —AlexSm 17:56, 13 April 2009 (UTC)[reply]

It would be much better to put the number of revisions deleted or undeleted in a separate field of the logging table rather than making it part of the edit summary. — CharlotteWebb 13:28, 16 April 2009 (UTC)[reply]

s1 = "content was: '$1'"; s2 = "content before blanking was: '$1'";
s3 = " (and the only contributor was \"[[Special:Contributions/$2|$2]]\")";
function bytes(s){ return encodeURIComponent(s).replace(/\%[0-9A-F]{2}/gi, '_').length; }
function contentwas(){
  if(wgAction!="delete" || !(field = document.getElementById("wpReason"))) return;
  x = new XMLHttpRequest();
  x.open("GET", wgServer + "/w/api.php?action=query&format=xml&prop=revisions&rvprop=user|content&rvlimit=25&titles=" + wgPageName, true);
  x.onreadystatechange = function() {
    if(x.readyState != 4) return; z = new DOMParser().parseFromString(x.responseText,"text/xml");
    rev = z.getElementsByTagName("rev"); content = "";
    if(rev[0].childNodes.length) { content = rev[0].childNodes[0].nodeValue; s = s1; }
    else { s = s2; for(i = 1; i < rev.length && !content.length; i++)
      if(rev[i].childNodes.length) content = rev[i].childNodes[0].nodeValue; }
    if(!content.length) { field.value = "page was blank"; return; }
    content = content.replace(/\s+/, " ");
    only = rev[0].getAttribute("user");
    for(i = 1; i < rev.length; i++) if(rev[i].getAttribute("user") != only) { only = null; break; }
    if(only && bytes(only) > 64) only = null;
    if(only) s += s3.replace("$2", only, "g");
    limit = 257-bytes(s); // SIC!
    if(bytes(content) > limit){ content = content.substring(0, limit);
      while(bytes(content) > limit - 3) content = content.substring(0, content.length-1);
      content += "..."; }
    field.value = s.replace("$1", content);
    }
  x.send("");
  }
addOnloadHook(function(){ setTimeout("contentwas()", 1000); });

I tested this for a few hours in my own dark corner of the internet and it seems to work. If anyone wants to add better error-checking and a more graceful way to aim for 255 but avoid splitting multi-byte characters, go for it. — CharlotteWebb 19:06, 13 April 2009 (UTC)[reply]

I'd just like to note that anyone who uses this code and ends up putting "content was 'John Smith eats babies'" in a deletion summary will be fed to the lions... :D Happy‑melon 13:16, 14 April 2009 (UTC)[reply]

Resolved.

I know this isn't the Firefox help desk, but has anyone else experienced any issues with history pages taking forever to load in FF3.0.8 (Win) ? With javascript disabled, it works fine, but when enabled it takes anywhere from 30 seconds to a minute to load the history page. –xeno (talk) 03:49, 12 April 2009 (UTC)[reply]

Does this happen on other WM projects, other MediaWiki installs, or when logged out? Lets narrow it down. --Splarka (rant) 07:35, 12 April 2009 (UTC)[reply]

Unfortunately this doesn't narrow it down at all, but I have a possibly related problem with history pages for exactly the same configuration (+ many installed extensions). History pages generally load OK, but twice during the last 24 hours a history page froze my browser so that I had to restart it. And it seems I am not the only one, see WP:ANI#Technical Problem? and WP:Help desk#Firefox freezing on page histories. --Hans Adler (talk) 13:37, 12 April 2009 (UTC), extended 16:12, 12 April 2009 (UTC).[reply]

Seems to only occur on Wikipedia, doesn't matter logged in or out, but it seems to be when looking for 250 or more revisions of history. Chrome and IE are fine... Pulling my hair out! I've emptied my monobooks and turned off all gadgets and still no joy. –xeno (talk) 14:37, 12 April 2009 (UTC)[reply]

After a night of rest, it seems that history pages are now loading (quite quickly in fact) for me. Looks like whatever problem was going on, has been fixed. - NeutralHomer • Talk • April 12, 2009 @ 17:20

Still no luck for me. If and when the pages load fast, they kind of hang for about 30-45 seconds before allowing me to scroll or click on anything. Limiting myself to 50 or 100 revisions is my temporary workaround but I wish I knew what was causing this. –xeno (talk) 17:24, 12 April 2009 (UTC)[reply]

I too have had the same problem today, and it happened on both Firefox and IE7 (ah the joys of two browsers...); the page history was about 1000 edits though, so not sure if that had anything to do with it. It temporarily froze my browser, but when I came back after about 15 minutes, the page history had loaded and I was able to use it. Risker (talk) 20:40, 12 April 2009 (UTC)[reply]

There was a similar issue with JS on page history a few months ago on the Polish Wikipedia, bug 17240. Mr.Z-man 20:56, 12 April 2009 (UTC)[reply]

It's still happening for me as of right now, Firefox. Who then was a gentleman? (talk) 22:28, 12 April 2009 (UTC)[reply]

• Seems I spoke too soon above, it is back at it again. Same as everyone else, Firefox. *sigh* - NeutralHomer • Talk • April 12, 2009 @ 22:35

I tried IE8 and it's happening there, too. Who then was a gentleman? (talk) 23:15, 12 April 2009 (UTC)[reply]

The bug report has a workaround: Adding the line

removeHandler(window, 'load', histrowinit);

to your monobook.js. It breaks the extension that provides an "Only new" button in my watchlist. Since there is no sure way to reproduce the bug, I cannot absolutely confirm that the workaround works. --Hans Adler (talk) 23:24, 12 April 2009 (UTC) As I just found out, the workaround also disables the script that asks for rollback comments. --Hans Adler (talk) 23:30, 12 April 2009 (UTC)[reply]

Many thanks for the workaround! ... I can wiki again without wanting to shoot my computer. Unfortunately, I did all kinds of local troubleshooting before I came here, including deleting all my saved passwords and forms, but c'est la vie. –xeno (talk) 03:03, 13 April 2009 (UTC)[reply]

A better workaround is probably to set your Wikipedia "My preferences" - "Recent changes" - "Number of edits to show ..." to something lower than 250. Who needs to see 250 revisions at the same time anyway?

It "hangs" for me too on history pages when clicking to view 250 revisions. That is, it takes some minutes. I am not entirely sure I could handle such long history lists before, but I think I have used it occasionally. I still have my preference set to the default 50 revisions, since I don't need more and I have such a slow computer. I use Firefox 2.0 on WinME on a very old computer.

--David Göthberg (talk) 16:25, 13 April 2009 (UTC)[reply]

500 revisions makes it far easier to search within the history without having to click "older","older","older" all the time. Until recently I had no problem at all loading that many revisions. –xeno (talk) 16:36, 13 April 2009 (UTC)[reply]

I agree entirely. I often look at 500 at a time. Saying that, I don't seem to have the problem right now at least. But I usualy use Chrome (which breaks some Unicode so I have to be careful). Dougweller (talk) 18:03, 13 April 2009 (UTC)[reply]

Doing a hard refresh should fix the problem. Caused by a change at MediaWiki:Common.css. --- RockMFR 19:20, 13 April 2009 (UTC)[reply]

Yes, I disabled the workaround and it's working fine without it now. Thanks. Now I must find a rather large trout... –xeno (talk) 19:26, 13 April 2009 (UTC)[reply]

RockMFR found the problem and fixed it. The technical details are discussed here.

Important: Many of you will need to bypass your browser cache to get the fix. (Since the fix is in a CSS page and the Wikipedia CSS pages are cached in the browsers for up to 31 days.)

--David Göthberg (talk) 13:27, 15 April 2009 (UTC)[reply]

The MediaWiki subpage feature is enabled for most talkspaces. But it is disabled in the "Category talk" and "Help talk" namespaces. I think that is an omission that needs to be fixed. Among other things this makes it hard to do talk page archiving for category talk and help talk pages. I also think that subpages should be enabled for the "Help" namespace.

Background and details:

I found an old report from a user that some of the talk page archiving templates don't work on category talk pages. I investigated and discovered that the reason is that the MediaWiki subpage feature is disabled on category talk pages. This means that magic words like {{BASEPAGENAME}} and {{SUBPAGENAME}} don't work as you expect, and relative paths like [[../Archive 1]] doesn't work at all on those pages. It also means that there is no small backlink to the basepage in the upper left corner of the subpage.

I can work around this problem with some fancy template programming, but I rather have the problem itself fixed. I see no reason why the subpage feature should be disabled in those talk spaces, and I don't think it will break anything if we enable subpages there.

I have checked some other language versions of Wikipedia, and they do have subpages enabled for all talk spaces. Also, they have subpages enabled for the "Help" namespace, which we don't have.

I know this is a simple setting in MediaWiki. My guess is that our sysadmins simply forgot to enable it for those talk spaces and for the Help namespace.

For reference, here is the full list of the talk spaces:

Subpages disabled: Help talk, Category talk

Subpages enabled: Talk, User talk, Wikipedia talk, File talk, MediaWiki talk, Template talk, Portal talk

And the subject spaces:

Subpages disabled: main/article, File, MediaWiki, Help, Category

Subpages enabled: User, Wikipedia, Template, Portal

--David Göthberg (talk) 12:06, 12 April 2009 (UTC)[reply]

From the Wikimedia configuration files, subpages should be enabled in all namespaces except 0, 6, 8, 12 and 14; that is, all except article/main, File, MediaWiki, Help and Category. Subpages not appearing in the Help talk and Category talk namespaces is a bug, as they are explicitly enabled in config. I agree that they should be enabled in the Help namespace, as has been done on numerous other wikis. Happy‑melon 12:36, 12 April 2009 (UTC)[reply]

Well, in that settings file you linked to: Right below the default subpage settings there are some arrays which seems to be overrides for some projects. In the override array for enwiki the namespaces 12-15 are not listed, which I guess defaults to "false" = "no subpages". Thus Help, Help talk, Category and Category talk don't get subpages, no matter what the defaults say. So it seems we have located the exact place where this mistake was done.

Those arrays need to be fixed. And the code that uses those arrays should ideally be fixed so it falls back to the defaults for items that are not in the array, although that might be too tricky to be worth the trouble.

I see that the arrays for some of the other projects probably also need to be fixed.

So I guess this should be reported to Bugzilla? Can any of you guys who are used to Bugzilla file a bug report on this?

--David Göthberg (talk) 13:25, 12 April 2009 (UTC)[reply]

I just did (Template:Bug); well spotted on the source. I'll update the bug with the exact problem and its fix. Happy‑melon 15:12, 12 April 2009 (UTC)[reply]

Updated. Happy‑melon 15:26, 12 April 2009 (UTC)[reply]

I see that Andrew Garrett (which I guess is User:Werdna) closed the bug as "invalid". He said:

"If you want subpages in these namespaces, you're going to have to check that nobody minds, and then post a site request."

And then he said:

"I don't think anybody expects a full-blown vote on such a trivial matter, just a general note somewhere prominent that the behaviour will be changing, and a check to see if anybody objects, as with most configuration changes."

He doesn't seem to understand that the MediaWiki default is to have subpages in the Help talk and Category talk namespaces. And that the way those override arrays were added is buggy. Anyway, I guess we can do some announcing and then post a "site request". (Does anyone know what a "site request" is and how it is done?) Since we want to enable subpages in the "Help:" namespace too, I will try to get a watchlist notice or so pointing to here. See the next two sections.

--David Göthberg (talk) 17:26, 12 April 2009 (UTC)[reply]

Yes, it's just a particular category of bug reports. What 'bugs' me about his close is that he could just as easily turned the bug into a site request, rather than just shooting it and moving on. Happy‑melon 18:50, 12 April 2009 (UTC)[reply]

I did a search in Bugzilla and found this old but related Template:Bug. It seems to be about when they extended the default that Help talk, Category talk have subpages. But as mentioned before, the default is overridden for some projects, like enwiki.

--David Göthberg (talk) 22:36, 12 April 2009 (UTC)[reply]

Would pages in the namespaces in question that currently have a slash in the title then automagically become subpages? Example: Help talk:Table/Archive 1. --Gadget850 (talk) 13:11, 13 April 2009 (UTC)[reply]

Yes. There isn't a "subpage flag" for individual pages, the namespace flag just changes how slashes in a title are interpreted. I've created a list of the pages that would be affected here. Anomie⚔ 13:33, 13 April 2009 (UTC)[reply]

This will of course result in the slight oddity that Category talk:AC/DC in its upper left corner automatically will get a small link to Category talk:AC. (Oops, that's a red link, not sure if the link will be shown then.) But that is the same oddity that we already have in other places, such as that Talk:AC/DC in its upper left corner has a link to Talk:AC.

But in most case we want that link, since for instance Category talk:Articles to be merged/Archive 1 should link back to Category talk:Articles to be merged. And we need the magic word {{SUBPAGENAME}} to return "Archive 1" for that subpage. Currently that magic word instead returns the entire page name "Articles to be merged/Archive 1".

--David Göthberg (talk) 14:22, 13 April 2009 (UTC)[reply]

You would have had me at "yes", but as a tech support engineer, I'm always happy with a full explanation. --Gadget850 (talk) 14:30, 13 April 2009 (UTC)[reply]

Is there any particular reason why subpages of categories are not a good idea? I know that I came across some unexpected behaviour when we were setting up categories for WPAFC (for example Category:AfC submissions by date/14 April 2009), but I recall getting around the problem somehow (maybe by using the titleparts parser function). — Martin (MSGJ · talk) 10:47, 14 April 2009 (UTC)[reply]

I suspect there might be trouble; the category pages are constructed from two different tables: the editable page content comes from the page table like any other page, but the category memberlists come from the categorylinks table. If the code for one recognises subpages but the other doesn't, it could get messy. It might work, it's worth asking. Happy‑melon 10:52, 14 April 2009 (UTC)[reply]

I'm going to repost these as site requests now. Happy‑melon 10:52, 14 April 2009 (UTC)[reply]

Template:Bug Happy‑melon 10:57, 14 April 2009 (UTC)[reply]

So what do we do with the old Template:Bug ? I had already reopened that bug. I guess we should link from that bug to the new bug in some way, right? And what do we do then, vote for the bugs so they get attention or who do we poke?

--David Göthberg (talk) 17:13, 15 April 2009 (UTC)[reply]

Subpages in Help talk and Category talk

Per discussion in the section Subpage feature above, we want to enable the subpage feature in the "Help talk" and "Category talk" namespaces. We think it is just a bug that needs fixing, since all talk spaces are supposed to allow subpages. Among other things we need subpages for archiving of talk pages.

If anyone has any comments to this, please add them here.

--David Göthberg (talk) 17:26, 12 April 2009 (UTC)[reply]

• support I was just going to bring this up myself; I had been archiving some help talk pages and noticed the lack of the backlink. --Gadget850 (talk) 18:42, 12 April 2009 (UTC)[reply]
• Support Happy‑melon 18:50, 12 April 2009 (UTC)[reply]
• Support. There's no reason I can see not to have subpages in these namespaces. — Gavia immer (talk) 20:25, 12 April 2009 (UTC)[reply]
• Support. Ruslik (talk) 09:53, 13 April 2009 (UTC)[reply]
• Support ManishEarth^{Talk • Stalk} 10:56, 13 April 2009 (UTC)[reply]
• Support the bugfix. — Edokter • Talk • 13:23, 13 April 2009 (UTC)[reply]
• Support No reason not to, it matches the situation with the corresponding articles and their talk pages (e.g. Input/output and Talk:Input/output). Anomie⚔ 13:33, 13 April 2009 (UTC)[reply]
• Support. Subpages are natural for archiving in talk namespaces. — TKD::{talk} 14:08, 13 April 2009 (UTC)[reply]
• Sure. Stifle (talk) 09:00, 14 April 2009 (UTC)[reply]
• Support Most bots work with subpages and this would make automated archiving easier. - Mgm|^(talk) 09:03, 14 April 2009 (UTC)[reply]
• Support. Makes sense, — Martin (MSGJ · talk) 10:50, 14 April 2009 (UTC)[reply]
• Support — Ched :  ?  15:06, 15 April 2009 (UTC)[reply]

Subpages in Help

Per discussion in the section Subpage feature above, we want to enable the subpage feature in the "Help:" namespace. The reason being that subpages are often useful, and we only have disabled subpages in the namespaces where it causes problems. If anyone knows any problems this might cause, please tell us.

If anyone has any comments to this, please add them here.

--David Göthberg (talk) 17:26, 12 April 2009 (UTC)[reply]

• support Useful for related issues and test cases. --Gadget850 (talk) 18:42, 12 April 2009 (UTC)[reply]
• Support Happy‑melon 18:50, 12 April 2009 (UTC)[reply]
• Support. There's no reason I can see not to do this. — Gavia immer (talk) 20:26, 12 April 2009 (UTC)[reply]
• Support. The help namespace is just an extension of Wikipedia namespace, which has subpages. Ruslik (talk) 09:54, 13 April 2009 (UTC)[reply]
• Support Why not keep consistency? ManishEarth^{Talk • Stalk} 10:57, 13 April 2009 (UTC)[reply]
• Support the bugfix. — Edokter • Talk • 13:23, 13 April 2009 (UTC)[reply]
• Support No reason not to. Anomie⚔ 13:33, 13 April 2009 (UTC)[reply]
• Support per Ruslik0 (talk · contribs). — TKD::{talk} 14:08, 13 April 2009 (UTC)[reply]
• Sure. Stifle (talk) 09:00, 14 April 2009 (UTC)[reply]
• Support per Ruslik, based on the assumption that the search feature would still work properly. - Mgm|^(talk) 09:04, 14 April 2009 (UTC)[reply]
• Support, no reason not to. — Martin (MSGJ · talk) 10:50, 14 April 2009 (UTC)[reply]
• Support — Ched :  ?  15:08, 15 April 2009 (UTC)[reply]

I suggest that this text be added to MediaWiki:Expand templates intro:

To expand an entire article, one may type {{:articlename}} in the box Input text instead of pasting the article's source.

I saw it on the Swedish wiki. Iceblock (talk) 14:50, 12 April 2009 (UTC)[reply]

I tried it, and you are right it works. But I don't see the point? Why would you want to expand a whole article?

--David Göthberg (talk) 18:13, 16 April 2009 (UTC)[reply]

I suppose if you wanted to copy and paste an entire article to another wiki but you didn't want to copy over the templates. Tra (Talk) 19:33, 16 April 2009 (UTC)[reply]

Hi!

I would like to use the image File:Bo Obama.jpg on the french Wikipedia but I cannot transfert the image to Commons because of an error message. First, I cannot create a TUSC account to use CommonsHelper, and of course, it's not possible to transfert the image without such account.

Anyone can help please? Could you transfert the image for me please?

Thank you very much,

-- Bestter Talk to me 20:03, 12 April 2009 (UTC)[reply]

It's there: Bo "the First Dog". – ukexpat (talk) 14:09, 13 April 2009 (UTC)[reply]

thanks! -- Bestter Talk to me 20:21, 13 April 2009 (UTC)[reply]

I was trying to find templates that "collapse" a section of the text so that clicking on them can hide/show. I found {{Collapse}}, {{Collapse top}}, {{Collapse bottom}} and {{show}}, and another way seems to be to use

<div style="clear:both;width:95%;" class="NavFrame">

Are there others? Is it ok to create a "Category: Collapse templates" containing all of them? Regards, Shreevatsa (talk) 00:06, 13 April 2009 (UTC)[reply]

There is also {{hat}} and {{hab}}. tempodivalse [☎] 00:14, 13 April 2009 (UTC)[reply]

And {{hst}}, {{hidden}}, {{hidden begin}}, {{hidden end}} & {{HiddenMultiLine}} -- WOSlinker (talk) 16:28, 13 April 2009 (UTC)[reply]

No one said it's a stupid idea, so I decided to go ahead and add these to a new Category:Collapse templates, but after adding {{collapse}}, {{collapse top}}, {{collapse bottom}}, {{show}}, {{hst}}, and {{HiddenMultiLine}}, it seems {{hat}}, {{hab}}, {{hidden}}, {{hidden begin}}, and {{hidden end}} are edit-protected. Could someone with the right powers add these? (Or undo my changes if they're a bad idea.) Shreevatsa (talk) 21:41, 16 April 2009 (UTC)[reply]

That category seems to be a good idea. You can add the category to most of those protected templates yourself, since the /doc pages are not protected. In fact, that is the very reason we started using such /doc subpages, so anyone can edit the categories, interwikies and the doc text, even when the template itself is protected.

I created the /doc page and added your category for the two protected templates that didn't have a /doc page.

--David Göthberg (talk) 00:06, 17 April 2009 (UTC)[reply]

 Done Oh, looks like I was being unobservant. Thanks, I've added all the pages to the category now. Regards, Shreevatsa (talk) 00:41, 17 April 2009 (UTC)[reply]

I'm just full of ideas this week. sorry!

this is a comment I made a few months back on Wikipedia_talk:Vandalism#Ease_of_Use_Vinegar. there's a potential advantage in keeping track of the number of sound edits an IP user makes. if IPs that make a certain number of constructive edits (say 50 or so) could be noticed as semi-registered (i.e., regular and beneficial contributors who just haven't bothered to actually register, or regular users doing the wiki-gnome thing), it might help focus anti-vandalism efforts. I think most anti-vandal bots check user contribs already as part of their algorithm, and most good vandal patrollers will check an IP's contribs before reverting something borderline; this would just formalize it by having a defined status of 'trusted ip' (which might in itself be a nice little perk to encourage good-editor IPs) . the only potential risk would be the random event that some trusted IP moved, and the IP was reassigned to someone inclined towards vandalism.

basically, the idea is 'if IP x-x-x-x makes Y many good edits, then we don't have to worry about it, and we can watch other IPs more closely". would that kind of thing be worth the overhead? --Ludwigs2 06:20, 13 April 2009 (UTC)[reply]

While we're at it, why don't we also keep different levels of autoconfirmed? After all, it's quite easy to make a few edits to the sandbox or a user subpage and wait a few days and be autoconfirmed. There also should be a sysop tool marking users as confirmed (without auto), which means they have been putting good constructive edits on WP. Maybe one more level for people who have done major edits. ManishEarth^{Talk • Stalk} 11:02, 13 April 2009 (UTC)[reply]

Category:Redirect-Class AFC articles reports itself having 1536 members, although looking through the entries there are only 1320. That is the same number that one finds after compiling a list of category members using AWB. Anyone know why the page would report the wrong number of member pages? Someguy1221 (talk) 06:45, 13 April 2009 (UTC)[reply]

1320 does seem to be the correct number, as there are 6 full pages of 200 plus another 120. Just an idea, I don't suppose it would be double-counting pages which have been added to the category twice, or something weird like that? — Martin (MSGJ · talk) 07:19, 13 April 2009 (UTC)[reply]

I'll just note that 1536 is also (naturally) the number returned by the PAGESINCAT magic word. Someguy1221 (talk) 07:46, 13 April 2009 (UTC)[reply]

There was until recently a software bug where pages that were deleted were not subtracted from the category counts. That bug has now been fixed, but the numbers remain incorrect by the same amount they were when the fix was scapped. There is a maintenance script that needs to be run, but with enwiki having several million categories even running a maintenance script is a matter requiring some planning and thought. Happy‑melon 09:42, 13 April 2009 (UTC)[reply]

Would depopulating and repopulating the category help at all? If not, is there anything that we can do? — Martin (MSGJ · talk) 10:40, 14 April 2009 (UTC)[reply]

The only way is to undelete and redelete the pages that were in the category... assuming you can find them. Happy‑melon 11:39, 14 April 2009 (UTC)[reply]

I would have no idea how to find them! But I would be quite interested to find out what had happened to all of them. — Martin (MSGJ · talk) 11:49, 14 April 2009 (UTC)[reply]

Has anyone else noticed firefox hanging on Wikipedia pages? I'm trying to work out if it is something to do with wikipedia or with the no script extension for firefox. Anyone got any clues as to whether the java for Wikipedia has altered recently? If that hasn't I guess it's something introduced in the last couple of no script updates. Hiding T 15:00, 13 April 2009 (UTC)[reply]

Hmmm. It's not noscript, but it is definitely something to do with the java on wikipedia or wikimedia or somewhere, and how firefox is dealing with it, as far as I can make out. I disabled no script and still got the hanging. I enabled no script and removed all wikipedia and wikimedia whitelistings, and got no hanging. Any thoughts? Firefox seems to hang and chew cpu for a good couple of minutes before loading a page. Hiding T 15:05, 13 April 2009 (UTC)[reply]

Everything works fine for me.See comment below. I am using Firefox 2.0, on WinME on a very old computer, and I have javascript enabled and I run a number of user scripts too. What Firefox version are you running? On what OS?

--David Göthberg (talk) 15:41, 13 April 2009 (UTC)[reply]

I'm getting the exact same symptoms - started maybe 4 or 5 days ago? firefox 3.0.8 on windows Vista. Nancy ^talk 15:43, 13 April 2009 (UTC)[reply]

Is it only on (long) history pages? See above at #History pages taking forever to load with javascript enabled, there is a workaround:

removeHandler(window, 'load', histrowinit);

(added to your skin page) as for the actual problem itself, I don't think anyone has filed a bugzilla for en.wiki yet; not sure if it can just be tacked on to the existing bugzilla:17240. –xeno (talk) 15:47, 13 April 2009 (UTC)[reply]

For me, the issue isn't limited to such pages. —David Levy 15:52, 13 April 2009 (UTC)[reply]

Yes, for me as far as I can recall it is history pages, I'll give your fix a whirl, thanks! Nancy ^talk 15:55, 13 April 2009 (UTC)[reply]

Wow, I'm experiencing the same issue (which I assumed was due to a problem on my end). Last night, I had a page hang for several minutes (right before I was to save my edits), and I didn't even have many tabs open.

I'm running Firefox 3.0.8 in Windows 7 (beta). —David Levy 15:52, 13 April 2009 (UTC)[reply]

"Hangs" for me too on history pages when clicking to view 250 revisions. That is, it takes some minutes. But I am not sure I could handle such long history lists before, since I have my preference set to view 50 revisions a time since I don't need more and I have such a slow computer.

--David Göthberg (talk) 16:09, 13 April 2009 (UTC)[reply]

• Wow, I'm glad I posted. Not sure how to thread this though. I'm running 3.08 on Vista, and yes, it's been the last four or five days. I'll try that workaround, but I think it's any page as opposed to history pages. I'll keep an eye on it. At the minute I've revoked javascript permissions as the only work around. I'll try this workaround, enable javascript permissions, reduce history pages to 50 contribs and let you know. Hiding T 16:46, 13 April 2009 (UTC)[reply]

  Using the removeHandler workaround, there is no need to limit yourself to 50 revisions. –xeno (talk) 16:49, 13 April 2009 (UTC)[reply]

  I think I've added the code correctly, see [3], but I'm still seeing firefox hang when java is enabled and contribs are at 500. I'm going to cut history pages back to 50 contribs again. What's the next step? Hiding T 10:43, 14 April 2009 (UTC)[reply]

  Did you forget to use Shift-Reload? Anyway, after this change (and another Shift-Reload!) the problem should really be fixed now. --Hans Adler (talk) 10:52, 14 April 2009 (UTC)[reply]

  I usually just close and restart the browser. But I've removed the code from my js and it seems ok fingers crossed. Ta. Hiding T 22:56, 14 April 2009 (UTC)[reply]

In case this helps, I've had no problems. I use FF 3.0.8 on Win XP SP3. My add-ons are AVG Safe Search 8.0, AVG Security Toolbar (disabled), Greasemonkey 0.8.2nnnnnn and Java Quickstarter 1.0. I've had a dozen tabs open for the last couple of weeks (using the "restore last session" option). --Philcha (talk) 17:25, 13 April 2009 (UTC)[reply]

Do you view 500 revisions worth of history at a time? –xeno (talk) 17:26, 13 April 2009 (UTC)[reply]

Quite often, especially if I see a lot of reverted vandalism, so 2/3 of the history is not real changes. Also on categories & "what links here", when I use them. --Philcha (talk) 12:15, 14 April 2009 (UTC)[reply]

• Update: Still hanging, it's not just history pages it's pages in general, Firefox is having trouble responding quickly. I'm baffled by this, any ideas? Hiding T 10:20, 15 April 2009 (UTC)[reply]

  That sounds like the unrelated problem that I have most of the time. Often clicking the same link several times seems to help a bit. I am in the UK, and it was particularly bad during the Virgin Killer censorship. Then it was OK for a while, with some problematic periods. The problem has been consistently present (although not as bad as before) since around the time when IP data retention started. Therefore I guess it's related to such censorship/privacy intrusion mechanisms. --Hans Adler (talk) 10:48, 15 April 2009 (UTC)[reply]

  That's a possibility. I've revoked java permissions for the toolserver and wikimedia, and that seems to have helped though. Hiding T 12:39, 15 April 2009 (UTC)[reply]

RockMFR found the problem and fixed it. At least he fixed the problem that caused Firefox to hang for some minutes when trying to load a history list that is 500 long. It also hanged for a shorter time for history lists of 100 items. The technical details are discussed here.

Important: Many of you will need to bypass your browser cache to get the fix. (Since the fix is in a CSS page and the Wikipedia CSS pages are cached in the browsers for up to 31 days.)

--David Göthberg (talk) 13:38, 15 April 2009 (UTC)[reply]

I'm just curious why Importing is disabled? For bringing over translated articles, shouldn't we be importing the history for GFDL, the way the Germans do it? (I was quite surprised to see I had done a number of rollbacks on de.wiki, until I realized they import history of our pages [4] [5]). –xeno (talk) 19:01, 13 April 2009 (UTC)[reply]

Each wiki we want to import from has to be defined individually in a list... which of the 750 WMF wikis are we likely to import from? It's easier for other languages: we're the biggest, they're usually importing from us. It's harder for us to know which wikis we might want to import from, and the list is too long to simply put them all in; it would make Special:Import unusable. Happy‑melon 19:06, 13 April 2009 (UTC)[reply]

Hmmm... Just the most popular ones I guess? Rather than using Category:Interwiki translation templates in the mainspace. –xeno (talk) 19:10, 13 April 2009 (UTC)[reply]

The largest is dewiki. The one causing a current ripple apparently is fr-wiki. Is there a a importer user-class? Agathoclea (talk) 20:28, 13 April 2009 (UTC)[reply]

Yes, 'transwiki' Currently, however, it can only be granted by stewards. Happy‑melon 20:39, 13 April 2009 (UTC)[reply]

Where would we go to get a) some importers and b) get admins/bureaucrats to give those permissions. Agathoclea (talk) 20:48, 13 April 2009 (UTC)[reply]

Both are simple site requests to make to the devs. Just establish a local consensus that they're a Good Idea, and post them off to bugzilla. Happy‑melon 21:42, 13 April 2009 (UTC)[reply]

On occasion I've seen people wish to import from Meta and other "working" projects. Majorly talk 21:44, 13 April 2009 (UTC)[reply]

I could see this being useful if enabled. –Juliancolton | ^Talk 21:46, 13 April 2009 (UTC)[reply]

The "View logs for this page" link seems to be missing for the Main Page. Is this a bug or is it intentional? --Ixfd64 (talk) 03:05, 14 April 2009 (UTC)[reply]

It's caused by the hiding of #contentSub at MediaWiki:Monobook.css. --- RockMFR 06:01, 14 April 2009 (UTC)[reply]

It behaves normally (not hidden) in the Modern skin. Kusma (talk) 06:12, 14 April 2009 (UTC)[reply]

Resolved

 – ukexpat (talk) 14:56, 14 April 2009 (UTC)[reply]

Some pages have a banner that appears when users try to edit them. For example, User:Jimbo Wales has a banner that says "You may edit this page!" above the edit box. Does anyone know how to edit such messages? Special:AllMessages doesn't seem to give any information. --Ixfd64 (talk) 04:02, 14 April 2009 (UTC)[reply]

WP:EDITNOTICE. – ukexpat (talk) 04:08, 14 April 2009 (UTC)[reply]

Thanks! --Ixfd64 (talk) 05:19, 14 April 2009 (UTC)[reply]

is there any way to transclude a template across wikis? For example, if I have made a template on meta or enwiki, and I want to use it on the other wikis like wikt:, s:, v:, etc (and maybe even other language wikis), do i have to make the template again on every wiki or or is there a way to use it directly? ManishEarth^{Talk • Stalk} 05:55, 14 April 2009 (UTC)[reply]

No. Among other issues, the various wikis use different implementations of CSS and JS; many templates depend on these. --Gadget850 (talk) 09:24, 14 April 2009 (UTC)[reply]

Is mw:Manual:$wgEnableScaryTranscluding disabled on all Wikimedia wikis? PrimeHunter (talk) 10:01, 14 April 2009 (UTC)[reply]

Yes. Happy‑melon 11:39, 14 April 2009 (UTC)[reply]

• The types of headings can be viewed here.

The above is the hierarchy of headings in which H2 is the only heading which is not bold. Does anyone know why and how this came about? Also, why there is a line stretching across the page associated with H2? Rotational (talk) 12:21, 14 April 2009 (UTC)[reply]

I've replaced the list of headings with a link to the sandbox so that this discussion doesn't affect the archiving system. Tra (Talk) 12:37, 14 April 2009 (UTC)[reply]

Actually, the h1 heading is also not bold, it's just in a large enough font size that it appears quite thick. h1 and h2 headings have a bottom margin, that's the "line" you see. Is there some reason why this shouldn't be the case? Happy‑melon 13:12, 14 April 2009 (UTC)[reply]

Well, the H1 line makes some sort of sense being the title heading, but using the H2 repeatedly in an article cuts the page into unaesthetic watertight compartments, which H3 and H4 don't. Is it possible to use an H2 heading and have the option of a bottom margin or not? If one could skip from H1 to H3 without using H2 there would be no problem, but some editors have hysterics at that and quote MoS:Headings in support Rotational (talk) 13:57, 14 April 2009 (UTC)[reply]

And they are right. As much as headings are about esthetics (which is a very personal preference), they are even more so about how we order article content. --TheDJ (talk • contribs) 14:12, 14 April 2009 (UTC)[reply]

This is about why it is necessary to have a bottom margin associated with the H2 heading when the line itself quite clearly doesn't help to order the article content. Rotational (talk) 22:19, 14 April 2009 (UTC)[reply]

If you are asking why the headers show as they do, then it is because they are defined in http://en.wikipedia.org//skins-1.5/monobook/main.css. You add personal CSS to change them as you desire. --Gadget850 (talk) 18:09, 14 April 2009 (UTC)[reply]

Well we wouldn't want the same type of heading to appear differently in different articles. Changing the CSS to removing all the horizontal section lines might not be a bad idea actually. I think the current divided appearance just subtly reinforces the page-within-a-page misnomer among users who don't understand how they actually work. You probably don't know how often we get questions like "why is there no edit history for just this section?" or "why can't I add just one section to my watchlist?" or "why don't these '→' links work anymore?", occasionally from admins "why I can't I protect just this one section?", etc. — CharlotteWebb 18:11, 14 April 2009 (UTC)[reply]

Another long-time WP editor has pointed out that Wikipedia's line-associated H2 heading is "a somewhat unusual layout convention, and one that is not followed by most publications, including our nearest rivals citizendium, encyclopedia.com, britannica.com, etc." Rotational (talk) 22:19, 14 April 2009 (UTC)[reply]

Your britannica.com link has horizontal lines beneath the H2 headings. --Amalthea 22:30, 14 April 2009 (UTC)[reply]

The lines are almost invisible and do not extend across the page.....Rotational (talk) 06:10, 15 April 2009 (UTC)[reply]

The difference is light gray versus darker gray, they're both 1 px solid lines and they both stretch all the way across the body content, technically neither go all the way across the page, britannica just has the TOC on the right, so the content area isn't as wide. Also, encyclopedia.com doesn't use heading tags for section headings, they use an h2 where we use an h1 (for the article title), they use strong tags for the section headings, which semantically, I'm not sure is entirely correct. Mr.Z-man 00:12, 16 April 2009 (UTC)[reply]

Well, if one has to have a line going with the H2 heading, the light grey version is a vast improvement. Can't someone just tweak the CSS and see what the reaction is? Rotational (talk) 09:15, 17 April 2009 (UTC)[reply]

Back to the original post: The appearance of bold also seems to be dependent on the browser zoom. At 100%, all of the headings H1 through H4 appear bold on my computer, but if I zoom out a step (ctrl+-, or ctrl + mouse scroll wheel), the H2 level appears noticeably lighter than the H1, H3, and H4. It's possible this may also be dependent on the display's DPI setting, which may explain why some users see the headings differently. -- Tcncv (talk) 23:12, 15 April 2009 (UTC)[reply]

How long does it usually take for a new category to populate itself? I made a few modifications to {{val}}, so that when a particular parameter is present in an instance of {{val}}, it adds that page to a category. That was about 17 hours ago, and there's virtually nothing in the category (one article-space entry). It's entirely possible that only one article uses these parameters, but that would come as a bit of a surprise (especially to the template maintainers, I'd imagine). I'm therefore wondering if there have been any job queue delays or other issues lately, that might cause recent changes to the template from being reflected on cached pages. (Incidentally, purging and refreshing had no effect. The job queue is currently at 5872, and was at 0 yesterday.) TheFeds 14:32, 14 April 2009 (UTC)[reply]

See Special:Statistics. The current job queue is at 7K, which is relatively small. Try a dummy edit on the page; if it does not appear in the category, then something else is wrong. --Gadget850 (talk) 17:39, 14 April 2009 (UTC)[reply]

When you change the categorisation in a template it takes about two days before most cases have arrived in the category. And about two weeks until nearly all cases have arrived.

And here's the long explanation:

This is because the pages that use the template are only re-rendered when they are visited, and the categorisation of the page is only updated when it is re-rendered. And it takes some days before most of the pages have been visited. If some page never gets a visit, then it will never turn up in the category. (And I have tested it, I had a secret page that didn't get categorised for months.) If it is a very widely used template or it is used on exotic pages deep in the "Wikipedia:" namespace or similar, then you might see stragglers arrive for a long time. Thankfully at least our articles get visited regularly, if not by humans so by the search engine crawlers, such as Google's crawler. So I think the search engines actually help us keep our categories updated!

So most of this delay is not caused by the jobqueue. The jobqueue does many things, but in this case: When you change a template, all pages that use that template gets put on the jobqueue, and when the process that processes items on the jobqueue takes the next page from the jobqueue it sends a message to all servers to drop that page from the cache. Note that it doesn't re-render the page. But since the pages get dropped from the cache they will be re-rendered the next time they get visited.

And that is why we need a jobqueue, since one change might affect thousands of pages, and for each of those pages a message has to be sent to each cache server to drop that page. Thus the jobqueue means that that heavy work can be done in the background when the servers have time for it.

Actually, even after the page has been visited and re-rendered, it still takes some time before the page turns up in the category. My guess is that the order to insert the page in the category is put on the jobqueue (or some other such queue system), and thus it takes some time before the category shows the page. Usually this only takes some minutes after you visited the page, but when the servers are really busy it can sometimes take a day.

There's much more to this, I guess we should write a guide about this sometime...

And a disclaimer: I am not a developer and I have not studied the MediaWiki code and Wikipedia server settings. Instead what I stated is based on what I have read and then verified by years of Wikipedia editing and template coding.

--David Göthberg (talk) 21:46, 14 April 2009 (UTC)[reply]

I didn't think this day would come, but I think I'll have to partially disagree with you David ;) At least my experience doesn't match some of what you've said. After making a change to a template, simply visiting a page (and re-rendering as you've called it) does not update the category. It will show the new category on the page, but it won't update the category contents. Even purging the page doesn't do it: the only way to force the updating of the category is by making a null edit. On the other hand, I believe the job queue does update the categories, even though it can take several weeks. Your secret page did get recategorised eventually, didn't it? I've recategorised thousands of pages by changing a template, and I know for sure that not every page was revisited by someone. — Martin (MSGJ · talk) 21:57, 14 April 2009 (UTC)[reply]

I believe the job queue should be updating the links tables (categorylinks, pagelinks, etc.) when you edit a template. If its not, that sounds like a bug. I'll have to ask Tim Starling, or someone else more familiar with the job queue than me about it. Mr.Z-man 23:09, 14 April 2009 (UTC)[reply]

Mr.Z-man: We can't have the servers re-render all dependant pages every time a template is edited. It would cost way too much server resources. You know, some templates are used on millions of pages. And sometimes the same template is edited many times in one hour. So unfortunately the servers have to be lazy and only update things if/when a page is visited.

MSGJ: First of all, even when you have visited the page or even purged it, then it takes some time before the page gets visible in the category. This takes anywhere from some minutes to a day depending on how busy the servers are. Did you wait for 24 hours to see if the page turned up?

But yeah, sometimes it seems that even though the page shows the new category, it "never" turns up in the category, and then not even purging seems to help. I haven't figured out under what circumstances this happens. Then one has to do an actual edit that changes something on the page (adding a space is enough) to cause the page to re-categorise. I don't know if a null edit is enough.

I know another circumstance when a category gets shown on a page but sometimes "never" shows up in the category: If a template or code on the page adds a category automatically, without any edit to the page or template. For instance if the date or a category count or other such measurement is used to trigger the adding of a category. Then that category is shown on the page on the next page re-render (pages are cached for a week if not edited), but it seems then the page sometimes doesn't show up in the category. But it also seems that the category often do show up. (But I haven't done enough testing of this, so I don't know for sure.)

My secret page got categorised only because I accidentally visited it myself. (I felt kind of stupid, ruining my own test run.) The page turned up in the category some minute after I had visited the page.

How can you know no one visited your pages? There are search engine crawlers and other automatic bots that visit pages. Some of them don't heed noindex and nofollow tags and similar.

--David Göthberg (talk) 23:38, 14 April 2009 (UTC)[reply]

According to mw:Manual:Job queue, template edits do (or are supposed to) update the links tables, which should include categories. Duplicate entries are removed when a job is run [6], so multiple edits to a template will only cause one reparse, unless the edits are far enough apart that the reparse is done before the 2nd edit. Mr.Z-man 23:54, 14 April 2009 (UTC)[reply]

DG, my knowledge of the MW code base also disagrees with you. IIRC your secret page test was testing dynamic inclusion: {{#ifexpr: {{CURRENTDATE}} > Some date | [[Category:...]] }}, which is indeed a 'black hole' where pages are only added to the category when someone edits the page. Also don't forget that Tim purged the job queue a while back and a lot of jobs were lost: if your page recaching was still outstanding at that time it would have been abandoned.

Happy-melon: I have done more secret page + category tests than the test you are referring to. But you don't know about those tests since I used secret pages. :)) But this is tricky stuff and I haven't done enough tests to be sure, and there's always the occasional server hiccups, so my conclusions might be wrong.

Anyway, one thing I am sure of is that when we change the categorisation in a template it usually takes some days before most pages that use that template arrive in (or are removed from) the category. And that is the answer to the original question above. So TheFeds, just be patient and wait some days.

Yes, I intend to start out such a guide page and copy this discussion to the talk page of that guide page. I think the guide page should be be about most of the different kinds of delays that we experience here on Wikipedia. I suggest we name that page Wikipedia:Update delays. The guide page itself might be fairly empty in the beginning, but we could discuss and report conclusions and test results on its talk page. And it would be nice to be able to point people to that talk page.

--David Göthberg (talk) 14:08, 15 April 2009 (UTC)[reply]

It should probably be a Help page. --Gadget850 (talk) 14:23, 15 April 2009 (UTC)[reply]

Happy-Melon is mostly correct, though there is another layer of caching using memcached, which stores the parser output – the rendered text minus the skin, as well as a few miscellaneous things – and all write actions are done on the master database. Slaves should always be read-only, otherwise lag could cause auto-increment indices to become out of sync. Most reads are done from the slaves, except in cases where lag would be more than an inconvenience. Mr.Z-man 16:32, 15 April 2009 (UTC)[reply]

• Oh yes, of course, that could be messy :S But it's still possible to get the old version if you then read from a slave that hasn't been fully synced.
  Is the memcache layer what's marked as "Try file cache" in Article::view()? Line 751... Happy‑melon 10:15, 16 April 2009 (UTC)[reply]
• Z-man, so who's assembling the skin and the personalized frame with the memcacheded parser output? It has to go through another Apache somewhere, right, to check login status, and render the "new messages" banner and the user (talk) page links? --Amalthea 13:16, 16 April 2009 (UTC)[reply]

• The file cache seems to be something different, where it stores the full rendered HTML to disk, like Squid, but built into MediaWiki and not as fast. The memcached layer is the parser cache. Any request by a logged-in user goes to apache, the content stored in memcached is set and accessed by MediaWiki. Mr.Z-man 18:20, 17 April 2009 (UTC)[reply]

In addition (and it pretty much follows from what Melon said): If a category is transcluded from a template and changes due to some parser function then it needs a (null) edit to actually put it in the category. Good examples for this can always be found in Special:WhatLinksHere/Template:Db-t3, which categorizes a page in CAT:CSD if it has been tagged for seven days. E.g., {{New York Yankees seasons}}, {{Infobox HAR}} and {{Dodgers retired numbers}} have all been tagged on March 24, all claim to be in CAT:CSD (since they have been rerendered in the last two weeks), but no amount of purging will make them actually show up in the category. A null edit would. --Amalthea 14:29, 15 April 2009 (UTC)[reply]

At WP:CFD, about a month ago, we tested this with emptying of categories after it was removed from a template. Our results would appear to confirm what DG has said, in that edits were necessary. It took so long waiting for the job queue to take care of it that I went ahead and made null edits to clear the category out. --Kbdank71 14:35, 15 April 2009 (UTC)[reply]

I can't remember exactly when Tim killed the job queue, but it might have been around that time. The whole process needs a fairly radical overhaul, I think it's on the medium-term todo list for one or other of the devs. Happy‑melon 10:17, 16 April 2009 (UTC)[reply]

I did some testing with my own wiki, and haven't been able to replicate any of the issues described here. When editing a template, the job queue was properly populated and the script used by Wikimedia to run the jobs as well as the jobs themselves seemed to be working correctly. The only 2 possible issues I can see are:

1. The backlink cache is never forcibly cleared. However, it has an expiry time of an hour, so this should only affect pages where the template is added within an hour of an edit to the template, so it shouldn't affect the majority of pages, and should be fixed if the template is edited again after the cache expires.
2. If the category is dependant on some parser function that doesn't return true when the job is run, it won't be updated.

-- Mr.Z-man 18:20, 17 April 2009 (UTC)[reply]

I'm looking for a way to have links to disambig pages in an article get a different font. That way as I'm reading through an article I can spot links that need updating while I'm familiar with the context and correct it. Is this possible? Vicarious (talk) 00:23, 15 April 2009 (UTC)[reply]

I'd be surprised if there is a way to do that, but check out WP:POPUPS: you can hover over a suspected link to see what the beginning of the linked article looks like. —EncMstr (talk) 00:41, 15 April 2009 (UTC)[reply]

User:Splarka/dabfinder.js adds a link to the toolbox to find disambiguation links on the page. Mr.Z-man 04:24, 15 April 2009 (UTC)[reply]

As for fixing link to disambigs, there are also some tools listed on WP:WikiProject_Disambiguation/fixer, and there is a tool at tools:~jason/disambigs_in_an_article.php. —AlexSm 04:35, 15 April 2009 (UTC)[reply]

I appreciate the prompt response and advice from all of you. EncMstr, I've fiddled with POPUPS before but having to hover over every link is more than I'd like to do. AlexSm, I checked out the tool and it certainly has it's uses, however in my natural reading of articles (a common event) it wouldn't help, and I'd find it cumbersome to go to the tool for each article I read. Mr.Z-man, your suggestion seems to be closest to what I'm looking for, although I find the documentation somewhat lacking. I tried adding it to my monobook (and clearing my cache) but didn't notice a change. Although, perhaps I'm at fault for a lack of comprehension, and perhaps I should be asking elsewhere for it. Vicarious (talk) 05:29, 15 April 2009 (UTC)[reply]

Well, first of all, you should blank User:Vicarious/monobook.css, none of that is css. Then you should undo this and simply use importScript('User:Splarka/dabfinder.js');. Then you should go to an article page (like via Special:Random), purge your browser cache of the site (ctrl-shift-reload or whatever) and click the "Find disambiguations" link showing in the toolbox. There isn't much documentation because there are only two things to do, click that or click the similar redirect hilighter (and it is a somewhat advanced tool). --Splarka (rant) 07:18, 15 April 2009 (UTC)[reply]

User:Anomie/linkclassifier.js looks to be what you want. The stylesheet I use with it underlines redirects and makes dab pages the colour of 'stub links' (which I have disabled). Subtle and unobtrusive, but effective. Happy‑melon 10:00, 15 April 2009 (UTC)[reply]

Both my edits today have added garbage at the end of the section I have been editing: [7] and [8]. Text seems to align in some way with qLauncher toolbar items. Restarting Firefox 3.0.8 and deleting qLauncher made no difference but disabling Smarter Fox 1.2.2 has (I hope) removed the problem. Thincat (talk) 14:59, 15 April 2009 (UTC)[reply]

Resolved

I was just trying to add commentary to the Reference Desk, and in the edit-text window everything is backwards at the bottom of the window. (This appeared when there was an edit conflict and the whole page was in the edit-text field; and I also saw it after clicking "edit page" for the whole page. Didn't appear when editing a section.) Tempshill (talk) 16:41, 15 April 2009 (UTC)[reply]

Should be fixed now. --- RockMFR 16:53, 15 April 2009 (UTC)[reply]

Reminds me of my attempts to usurp xeno on the Hebrew Wikiquote. –xeno (talk) 16:57, 15 April 2009 (UTC)[reply]

I hate doing any interwiki work on the Arabic, Persian, or Hebrew wikis for that very reason. RTL screws with my head every time. EVula // talk // ☯ // 17:04, 15 April 2009 (UTC)[reply]

Resolved.

The template Template:Infobox comics character used to render just fine in Opera 9.0. Some time in the last few days or weeks, however, some change (I don't know if it's a change in this template and or in some nested template that this template uses) broke this template in Opera: now this template expands to fill the entire width of the page, pushing the intro text entirely down below the template box rather than having it flow to the left of the infobox. For example, see the Superman or Spider-Man page in Opera (note, on the other hand, that some pages that use the template, like Magog (comics), render just fine). Could someone please fix this? This affects literally thousands of pages in Wikipedia. Thanks. —Lowellian (reply) 17:22, 15 April 2009 (UTC)[reply]

I see it too. That infobox blows up to full page width on for instance Spider-Man when I view that page with my Opera 9.02. While it looks normal in my Firefox 2.0 and my very old IE 5.5. I have no idea why that happens.

--David Göthberg (talk) 13:42, 16 April 2009 (UTC)[reply]

Probably related to this edit. But I can't find anything wrong with it. The infobox in Superman still has a valid width of 24em. — Edokter • Talk • 13:56, 16 April 2009 (UTC)[reply]

Fixed - Yeah, I too thought the use of {{comics infobox sec}} had something to do with it, so I already checked that code before. But now that you Edokter pointed to it I took a second look. Some code prettifying helped. That is, I indented the code to make it more readable and then I discovered that the first if-case in {{comics infobox sec}} was lacking the necessary colon ":" in the first "{{#if:||}}".

--David Göthberg (talk) 15:19, 16 April 2009 (UTC)[reply]

I should have spotted that... I usually do... — Edokter • Talk • 16:15, 16 April 2009 (UTC)[reply]

Yes, it's fixed now and rendering correctly! User:Davidgothberg, thank you so much for fixing[9] this problem. :) —Lowellian (reply) 06:01, 17 April 2009 (UTC)[reply]

Greetings. File:Homopholis fasciata1.JPG here on en.wiki is not the same image as Commons:File:Homopholis fasciata1.JPG on Commons. (The one here is a cropped version.) I'd like to be able to display the Commons version of the image. Is there a way to do this? [[Commons:File:Homopholis fasciata1.JPG]] creates a link, just as if I'd said [[:Commons:File:Homopholis fasciata1.JPG]].

(My reasoning is, I want to use a bot to create a list of these images, showing them side by side, so I can visually see if they look the same. But I can't seem to do this with Wikisyntax, unless there a method I don't know about.) – Quadell ^(talk) 19:09, 15 April 2009 (UTC)[reply]

Since both the full and the cropped version have been properly transferred to commons I just deleted (WP:CSD#F8) the local version (and changed the one link to it so that it points to commons:File:Homopholis fasciata1 cropped.JPG). To my knowledge there is no way to show a commons image that is obscured by a local image. --Amalthea 19:52, 15 April 2009 (UTC)[reply]

ETA: I thought I had changed the link, but RockMFR beat me to it. :) --Amalthea 20:01, 15 April 2009 (UTC)[reply]

I invite users to test User:TheDJ/slimpopups.js. An update that I'm planning for WP:POPUPS.

• removes all fallback methods for elements that can already use api.php. Presents an alert if api is not enabled on your mediawiki installation
• fixes an issue with autoedits not autosaving/previewing.
• now supports images from Commons again
• now supports descriptions from Commons again
• "hacks" to support both the Image and File namespace
• switches from custom to firebug/safari error/debug logging
• fixes an issue with timezone corrections that had been broken for a while now.
• adds support for several new interwiki prefixes
• fixes an issue with listing image usages.
• contributions tree removed due to brokenness.
• Now always show template code when looking at a template link, or an image link.
• Switched to soxred editcounter
• Preview user's info. blocked/groups/editcount. Thx to Splarka

Usage:

importStylesheet('MediaWiki:Gadget-navpop.css');
importScript('User:TheDJ/slimpopups.js');

Unless serious regressions are reported, this code will likely go into effect somewhere next week. --TheDJ (talk • contribs) 21:01, 15 April 2009 (UTC)[reply]

I think it works good. Powergate92Talk 22:13, 15 April 2009 (UTC)[reply]

For the sites without api.php, I think it's unacceptable to have two alert boxes pop up on every page load about how the api is not enabled. It's very disruptive to the user experience and most users won't know what it means at all. I think better options would be to either:

• Keep popups working with minimal functionality.
• Have the notification appear when they hover over a link but in the form of the yellow popup boxes that the user is expecting to see. The text could then be something along the lines of "Due to recent updates, navigation popups is no longer compatible with this site. Click here for instructions on how to use an older version." That could then link to a page explaining how to copy and paste in an older version of popups.
• Fail silently, so that the page renders as if popups was not installed. Tra (Talk) 22:36, 15 April 2009 (UTC)[reply]

Mmm, good points. The idea is that I want people to realize that we are switching to a requirement of API. We can't go supporting "old technologies" on a tool that is "little" maintained. As a matter of fact, the plan is to switch more and more of popups to API and writeAPI, so that the JS code can be cut down significantly, reducing maintenance work. I guess your second option might be worth considering.... --TheDJ (talk • contribs) 00:24, 16 April 2009 (UTC)[reply]

Done. --TheDJ (talk • contribs) 09:58, 16 April 2009 (UTC)[reply]

I also figured it's about time I switched the edit counter link. My personal preference would be Soxred93/X!. If you think that is a bad idea, please let me know. --TheDJ (talk • contribs) 09:58, 16 April 2009 (UTC)[reply]

TheDJ: I suggest you add that "importStylesheet('MediaWiki:Gadget-navpop.css');" line to your User:TheDJ/slimpopups.js. Thus people only have to load the javascript and that in turn will load the CSS. I stumbled on that and wondered "WTF? Why do I only get transparent popups?". Took me a while to figure out what had happened.

If you are going to overwrite the old User:Lupin/popups.js then you have to load the CSS from your code, or you will break it for those of us that load User:Lupin/popups.js from our personal /monobook.js instead of using the gadget.

The preliminary results from my testing is that your popups seems to be working both in my Firefox 2.0 and my Opera 9.02.

--David Göthberg (talk) 14:57, 16 April 2009 (UTC)[reply]

The official version is now the gadget version. The User:Lupin/popups.js is only a loader for the gadget and it's stylesheet, primarily kept in order to facility any 3rd party websites that use it. My version will replace the "Gadget' code, and thus need not include the stylesheet. --TheDJ (talk • contribs) 15:15, 16 April 2009 (UTC)[reply]

Ah, I didn't notice that. So all good then. And thanks for taking care of the popups script. It is a lovely script that makes life much easier for us editors, and it does need some updates.

--David Göthberg (talk) 18:19, 16 April 2009 (UTC)[reply]

Yeah I like it myself, that's why I work on it :D. I don't foresee myself doing a full rewrite of it any time soon, but some things just needed to get fixed and I guess I'm doing it. --TheDJ (talk • contribs) 21:06, 16 April 2009 (UTC)[reply]

There is a table at 2007–08 Pittsburgh Penguins season#Skaters exhibiting strange sorting behavior. The first six columns sort correctly, but the last five (Playoff) columns have a mind of their own. I have no idea what's going on. Any help would be appreciated! Thank you. — Twas Now ( talk • contribs • e-mail ) 09:54, 16 April 2009 (UTC)[reply]

style="width: 0.1em;" rowspan="39" class="unsortable". colspan and rowspan confuse the sortable tables code. You will have to add separate empty fields for all the rows. --TheDJ (talk • contribs) 12:24, 16 April 2009 (UTC)[reply]

Thanks for the help. That solved it. — Twas Now ( talk • contribs • e-mail ) 12:37, 16 April 2009 (UTC)[reply]

There is still something weird going on with the sorting of zeros in the playoff section (so it only affects G, A, and Pts). Does the sorting recognize a 0 as equal to an empty cell? — Twas Now ( talk • contribs • e-mail ) 16:05, 16 April 2009 (UTC)[reply]

Both Talk:1978 Washington summit and Talk:1977 London summit give the MediaWiki:Missing-article error. The history is empty for both pages. Anomie⚔ 11:40, 16 April 2009 (UTC)[reply]

Hmm, strange. I thought I'd have a go at deleting and restoring Talk:1977 London summit, but as there seems to be no history, there is nothing to restore! Do you know if there was definitely a page there once? — Martin (MSGJ · talk) 12:21, 16 April 2009 (UTC)[reply]

I'm getting rather wierd results from the toolserver database (that is, nothing!); not sure why it's even a bluelink. Please don't anyone touch the Washington one; play around all you will with the London one (unless you can find any more, Anomie?). Happy‑melon 12:29, 16 April 2009 (UTC)[reply]

No idea if there are any more or if they ever really existed, my bot found those two by throwing errors on them. Anomie⚔ 12:34, 16 April 2009 (UTC)[reply]

Ah, that's explains things. I'm looking at a list of the pages with page_ids surrounding the Washington one, and they've all been edited by your bot. I was going to complain that you'd probably destroyed other examples, but if the bot errors out on them then that's not the case.

The toolserver database confirms what appears to be the case: there is an entry in the page table for the Washington talk page, and it has a page_id (22431511). However, there are no entries in the revision table associated with that page_id. Curious. Happy‑melon 12:49, 16 April 2009 (UTC)[reply]

Same with Talk:1978 Washington summit; no history to restore. Could this be a botched move? — Edokter • Talk • 12:55, 16 April 2009 (UTC)[reply]

I'm running a really nasty query that (assuming River doesn't kill it and eat me!) should flag up any more of these. Happy‑melon 13:38, 16 April 2009 (UTC)[reply]

Query failed, too nasty... FTR it was something like this:

SELECT page.page_id, page.page_title
    FROM page LEFT JOIN revision ON page.page_id = revision.rev_page
    WHERE revision.rev_page IS NULL;

That is, "create a table containing every row from the page table (11 million entries) mapped to every row of the revision table (250 million entries) wherever the page_id and rev_page values are the same (creating a null row if there is no such row in the revision table), then return only the rows where such a null row had to be created". Happy‑melon 14:58, 16 April 2009 (UTC)[reply]

Is this:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

    (SQL query hidden)

from within function "Revision::insertOn". MySQL returned error "1205: Lock wait timeout exceeded; Try restarting transaction (10.0.6.22)".

related? –xeno (talk) 16:58, 16 April 2009 (UTC)[reply]

Don't think so, I got that too a few hours ago. I think the servers are being put through the mill at the moment, probably a random period of high load (plus the connection between the Squid servers in Amsterdam and the Apaches in Florida went down this afternoon, so they were thinking about disabling that entire cluster until it got fixed). All manner of things seem to be shaking loose. Happy‑melon 17:33, 16 April 2009 (UTC)[reply]

yea, i managed to get it sorted. –xeno (talk) 17:49, 16 April 2009 (UTC)[reply]

Ah whats going on with the change in red links? A black link with red question mark? Red links are ugly I agree but that was exactly why -they strongly point to missing articles. I think this change will have a negative effect on people creating articles from the missing links. Dr. Blofeld ^{White cat} 12:08, 16 April 2009 (UTC)[reply]

Go to "my preferences", then "misc", and check the top box (format broken links) - that should restore redlinks. DuncanHill (talk) 12:12, 16 April 2009 (UTC)[reply]

Thanks. I'm thinking though about new comers who may want to contribute and not know this and bypass these links. Dr. Blofeld ^{White cat} 13:03, 16 April 2009 (UTC)[reply]

The default behaviour is the same as it ever was. Either you changed your preferences accidentally or the software changed them of its own accord (as it has been known to do from time to time). Algebraist 13:07, 16 April 2009 (UTC)[reply]

Yes my browser seems to have slightly "changed" when I logged this morning. I have no idea how!! Dr. Blofeld ^{White cat} 15:32, 16 April 2009 (UTC)[reply]

I'd fix it, but have NO idea how to do it.

Every time i go to the science refdesk, the sidebar that links to the other refdesks empties out and is completely blank. Not to be rude, but someone should fix it; it's kinda annoying.  Buffered Input Output 13:04, 16 April 2009 (UTC)[reply]

Looks fine to me...Browser/version/OS? –xeno (talk) 13:08, 16 April 2009 (UTC)[reply]

And to me. Have you tried bypassing your cache? Does the problem occur on any of the other refdesks? How about on Wikipedia:Reference desk/header/nav? Algebraist 13:10, 16 April 2009 (UTC)[reply]

Bypassing the cache does nothing; the links still don't appear. And they are all fine on Wikipedia:Reference desk/header/nav. Browser is Internet Explorer 7, OS is XP Professional SP3.  Buffered Input Output 12:42, 17 April 2009 (UTC)[reply]

Looks fine to me as well. Do you have any special scripts or gadgets installed which could be causing this? — Martin (MSGJ · talk) 12:54, 17 April 2009 (UTC)[reply]

I'd say it was the school's server/blocking scripts, but the problem occurs at my house as well (IE6+XP Home SP3). The only difference is that bypassing the cache fixes it at my house.  Buffered Input Output 16:37, 17 April 2009 (UTC)[reply]

My contributions just lost all the links to articles etc, and just shewed stuff like this " () () m ‎ (Reverted 4 edits by identified as to last revision by . ()) (top) []" when I clicked on "earlier 50". DuncanHill (talk) 14:58, 16 April 2009 (UTC)[reply]

I just had the same problem with Preston Village, Brighton. A purge worked there. Algebraist 15:00, 16 April 2009 (UTC)[reply]

And just now with my watchlist. Reloading worked there. Algebraist 15:02, 16 April 2009 (UTC)[reply]

 Works for me. Perhaps somebody was messing with a MediaWiki page? –Juliancolton | ^Talk 15:02, 16 April 2009 (UTC)[reply]

Seems to be OK again. Very odd. DuncanHill (talk) 15:03, 16 April 2009 (UTC)[reply]

Has happenned a couple more times, and also happened on "my preferences" where it displayed my username etc as (). DuncanHill (talk) 15:17, 16 April 2009 (UTC)[reply]

I saw it too, on my contributions and a couple of templates and pages I was viewing at the same time. Purging or refreshing seemed to clear it tho. - Trevor MacInnis (Contribs) 15:32, 16 April 2009 (UTC)[reply]

I saw it on an article a few minutes ago, disappeared on null edit. I suspect one or more servers are serving borked pages, hence the intermittence. Happy‑melon 16:09, 16 April 2009 (UTC)[reply]

I was just referred here from the Help Desk, where I had posted about this in Waltheof, Earl of Northumbria. --ColinFine (talk) 20:25, 16 April 2009 (UTC) - But it seems to have fixed itself now --ColinFine (talk) 20:31, 16 April 2009 (UTC)[reply]

If it is of any help, when I was over at Wikinews earlier today I had something similar happen: the main page didn't display any links at all. Tried a refresh, nothing happened. When I came back a few minutes later everything was fine. Looks like this is a cross-wiki occurrence? tempodivalse [☎] 20:33, 16 April 2009 (UTC)[reply]

Now pages display in a strange font, with the editing tabs in a list near the bottom og the page and the my talk/my preferences stuff in another list below that. DuncanHill (talk) 16:06, 16 April 2009 (UTC)[reply]

That's where those links are if not moved elsewhere by CSS, so this might be caused by your browser failing to load the stylesheets properly. Algebraist 19:05, 16 April 2009 (UTC)[reply]

Oops... I deleted Talk:Recession to remove personal information included in some vandalism, but every time I try to restore it, I get this Database Error:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

(SQL query hidden)

from within function "Article::insertOn". MySQL returned error "1205: Lock wait timeout exceeded; Try restarting transaction (10.0.6.22)".

Help! – Toon^(talk) 19:23, 16 April 2009 (UTC)[reply]

Oh wait... it's back... :s – Toon^(talk) 19:24, 16 April 2009 (UTC)[reply]

(edit conflict) This was happening to me earlier. Took me about 30-45 minutes to get it restored. (Just kept trying). –xeno (talk) 19:25, 16 April 2009 (UTC)[reply]

I asked on the Policy Village Pump as well because it may be a policy question.

Eaglenest Mountain is a confusing article. North Eaglenest Mountain is actually the taller of two adjacent peaks (by a few feet) and the more famous one. And the hotel for which the two peaks were named was actually on North Eaglenest Mountain. But only one could be a stand-alone article unless there was a lot of duplicate content. The problem is that I can't put two infoboxes in one article. The coordinates for the first appear at the top of the page and in both infoboxes. If this can't be fixed (technical), I suppose two articles are justified (policy).Vchimpanzee · talk · contributions · 20:57, 16 April 2009 (UTC)[reply]

I went ahead and separated the two articles, so now it's a policy problem.Vchimpanzee · talk · contributions · 22:33, 16 April 2009 (UTC)[reply]

Is there something going on with Persondata today ? Normally, I can see Persondata on every article that has it but today I can't. Is there anything going on ?

Thanks,

Tovojolo (talk) 21:42, 16 April 2009 (UTC)[reply]

See MediaWiki talk:Common.css#InChI and persondata. The CSS has been moved to {{Persondata}}, which may cause them to be invisible again. If you use your monobook.css to show persondata, try adding !important to the declarations. In fact I did it for you. Does that restore it? — Edokter • Talk • 22:51, 16 April 2009 (UTC)[reply]

Tovojolo confirmed that it fixes the problem. — Edokter • Talk • 23:30, 16 April 2009 (UTC)[reply]

For some reason, when I log out and view the page Armalite and ballot box strategy, all the links are missing - the blue text simply doesn't appear. When I log in again, they reappear. I haven't noticed this problem on any other articles. Does anyone have any idea what might be causing it? Robofish (talk) 23:23, 16 April 2009 (UTC)[reply]

See above. Algebraist 23:25, 16 April 2009 (UTC)[reply]

Thanks, I tried saving a null edit and that seemed to do the trick. Strange... wonder what's causing the problem? Robofish (talk) 23:32, 16 April 2009 (UTC)[reply]

I make a lot of edits to page using AWB, many of which are new and unpatrolled. Unfortunately, it seems that because I'm an admin my AWB edits that take well under half a minute each mark the pages as patrolled... but I haven't looked at the full article. Is there some way to deactivate the autopatrol feature for my account without it interfering with other sysop abilities? Thanks. –Drilnoth (T • C • L) 02:07, 17 April 2009 (UTC)[reply]

I don't think so, but you could create an alternate account for such purposes. Stifle (talk) 08:45, 17 April 2009 (UTC)[reply]

Correct me if I'm wrong, but shouldn't autopatrolling only affect pages that you create here on en-wiki? It won't mark a page as patrolled just because you edit it. Have a look at your patrol log, only pages you (recently) created are marked as "patrolled (automatic)". Amalthea 10:16, 17 April 2009 (UTC)[reply]

Yes I believe Amalthea is right. — Martin (MSGJ · talk) 12:51, 17 April 2009 (UTC)[reply]

Oh... okay. Maybe the person who let me know about this was mistaken. Anyway, thanks! –Drilnoth (T • C • L) 13:56, 17 April 2009 (UTC)[reply]

• Currently the allowed formats for wikilinks are:

But it would be useful if this was also allowed:

and this would be useful if the whole of the article name is not the first part of all derived forms, e.g. to link from a word "emancipated" to page emancipation, [[emancipat||ion]]ed is shorter, and perhaps easier to read in text, than [[emancipation|emancipated]]. Anthony Appleyard (talk) 09:48, 17 April 2009 (UTC)[reply]

That makes the wikilink syntax unnecessarely complicated IMO. We now have [[link|display]], and we shouldn't complicate it further by combining these; it results in an ambigous link construction. — Edokter • Talk • 13:49, 17 April 2009 (UTC)[reply]

Agreed. While personally, I like the suggested syntax, we should be keeping this as user-friendly as possible. — Martin (MSGJ · talk) 13:56, 17 April 2009 (UTC)[reply]

• It is not ambiguous. Anyone with reasonable eyesight can distinguish | from || . Anthony Appleyard (talk) 16:06, 17 April 2009 (UTC)[reply]
  • I think it would depend more on what font they are using. — CharlotteWebb 19:00, 17 April 2009 (UTC)[reply]

I don't think this is necessary; at best it saves a few characters for those prepared to learn an esoteric syntax. I do not agree that the proposed structure is "easier to read in text" than the current system, which seems to be completely adequate. This does not enable any constructions that cannot already be made with the existing syntax, and completely obstructs our ability to develop the link syntax in other ways. Happy‑melon 16:29, 17 April 2009 (UTC)[reply]

Not sure where to post this, so I'll try here. If you're on a category page, you see a message saying "this list may not reflect recent changes (learn more)", and "learn more" links to a very technical (and probably not particularly accurate) section of a help page intended for editors. However, since categories are intended to be navigated by readers, and they are liable to be intrigued by this message, it would be far more appropriate to link this to information that they might be able to understand. I've tried to write such information at WP:FAQ/Categories#Why might a category list not be up to date?. Please can someone who knows the magic change the link under "learn more" to point to that FAQ section rather than the help page section? Or even better, get rid of it (it's not really a common problem, espcially in reader-facing categories) and add a more general link, something like "To learn more about using categories, see the FAQ." (That FAQ is a starting point for readers, but it also contains a clear onward link to the other FAQ: WP:FAQ/Categorization, which is meant for editors.)--Kotniski (talk) 10:09, 17 April 2009 (UTC)[reply]

Should all three of MediaWiki:Category-article-count, MediaWiki:Category-article-count-limited and MediaWiki:Category-empty be updated to point there? Amalthea 10:21, 17 April 2009 (UTC)[reply]

Yes, that would seem to be it!--Kotniski (talk) 10:46, 17 April 2009 (UTC)[reply]

 Done Amalthea 10:57, 17 April 2009 (UTC)[reply]

Thanks! Kotniski (talk) 14:55, 17 April 2009 (UTC)[reply]

On MediaWiki:Category-article-count, we could add "approx." to the total. -- User:Docu

Is that necessary? Is it inexact for any other reason than the thing about templates? --Kotniski (talk) 14:55, 17 April 2009 (UTC)[reply]

I'm not sure about the full effects of the template thing. It might be just a delay in updates, but sometimes the count remains off by several. -- User:Docu

Kotniski: Category updates are delayed for a whole bunch of reasons. Even when not using templates and you manually add or remove a category from a page it can take anywhere from some minutes to several hours before the page is added or removed from the category. Removing a page usually takes longer time, and adding and removing subcategories also take longer time. So removing a subcategory is the operation that takes the longest time. (I guess that is a priority setting in the system, and I agree with that priority order.) Also some categories show the wrong category count. See discussions Categories reporting wrong number of members and Category & job queue sanity check above.

And it is a common problem. We added the text that says "This list may not reflect recent changes" and the (learn more) link since we constantly have problems with editors worrying why their page doesn't turn up in or are removed from the category. So they start doing extra edits to the page and testing all kinds of weird things, and they go ask on our user talk pages and/or here on the Village pumps. And they even ask for or suggest that bots should "touch" (do dummy edits) to all pages in their category. When all they need to do is to wait long enough for the category to update. See the discussions above for examples. (Well, there are some odd circumstances when you perhaps need to "touch" the pages.)

Already a 10 minute delay is enough for an editor to start panicking and try extra edits and come asking us what is going on etc., and delays of 10 minutes or more are common even when templates are not involved. Things have been much more quiet after we added that text and the learn more link.

I think that the (learn more) link should be linked to a page specifically written to be its target. Since then that page can be written in a way that is helpful for both readers and editors. It was linked to a good text, but that text has since been changed.

--David Göthberg (talk) 17:05, 17 April 2009 (UTC)[reply]

OK, if that's the case, then we probably need more explanation than is present at either the previous or the new link target. Do you know where we can find the "good text" in the history (or would you be able to recreate something similar)? As a temporary measure, I've added some extra text at the current link target - the second paragraph of WP:FAQ/Categories#Why might a category list not be up to date? - please improve if you can (but let's try to keep that page simple - if it starts getting technical, then perhaps better to link to a separate page like you suggest, or do something at the editors' FAQ).--Kotniski (talk) 17:18, 17 April 2009 (UTC)[reply]

There are really to issues: (1) the category doesn't necessarily display all articles that list the category on their list. (2) the count on the page doesn't match the number of articles displayed below. For point (1), I think it can take several weeks. -- User:Docu

I'd like to put something in place that keeps me from editing from my work computer, without actually blocking access to the site. Maybe a perl-based proxy script that blocks WP pages with "edit" in the URL? Has anybody done this in a way that they found to be convenient?--SarekOfVulcan (talk) 14:46, 17 April 2009 (UTC)[reply]

Something like this? Papa November (talk) 17:02, 17 April 2009 (UTC)[reply]

That would prevent the user logging in altogether, I believe he's looking for a way to simply prevent him editing whilst at work... Self-restraint sometimes fails us... =] –xeno ^talk 17:05, 17 April 2009 (UTC)[reply]

Bingo. :-)--SarekOfVulcan (talk) 17:32, 17 April 2009 (UTC)[reply]

Actually, I could probably modify that script to block me between 8 and 6 every day, instead of watching for an end date...--SarekOfVulcan (talk) 17:34, 17 April 2009 (UTC)[reply]

If you look in my monobook.js you will see a routine called 'wikibreak'. You can give it a date to reactivate, but I am sure you could modify it to work with a time range. It works by finding and removing your edit token. Chillum 17:34, 17 April 2009 (UTC)[reply]

That would appear to work, unless I just broke my ability to edit at all. :-)

if (today.getHours() >= 8 
      && today.getHours() <= 18 
    && today.getDay() >= 1 
      && today.getDay() <= 5)
  {
  addOnloadHook(wikibreak);
  }

are you sure you won't now just end up editing as an IP? =] I suppose you could block yourself it that became an issue... –xeno ^talk 18:20, 17 April 2009 (UTC)[reply]

I've got a couple of scripts that will prevent you from ever editing as an IP. Let me know if anyone wants them. Note that they require Greasemonkey because they have to work all the time, and User:YOURNAME/monobook.js will not. — CharlotteWebb 18:30, 17 April 2009 (UTC)[reply]

Sure, send them along! –xeno ^talk 18:32, 17 April 2009 (UTC) (For the record I just want it to prevent me editing as an IP, nothing to do with wikibreaking...)[reply]

• Why not just ask your boss to help? DuncanHill (talk) 18:37, 17 April 2009 (UTC)[reply]

I've found an extension for Firefox that works well; it allows you to select any website, and then create specific access rules for that site. In your case, you could set it up to block all access to Wikipedia between certain hours, or to only allow a certain amount of time per time period. (For example, you could allow yourself 10 minutes of access every two hours, which I've found is enough for quick information searches, but not enough time to get into editing.) I'll try to look up the script name and post it later today as it is on a different computer. --Ckatz^chat_spy 18:55, 17 April 2009 (UTC)[reply]

Recently, User:Butwhatdoiknow has been adding the heading "Related information" before the templates at the bottom of articles (eg, H1_antagonist#Related_information, Loratadine#Related_information). His rationale is summarised at User:Butwhatdoiknow/Related information. He has also added a sentence to WP:LAYOUT (here: "There is no consensus establishing that a heading is prohibited or required for navigational aids."). Well, I'd like to use this space to help establish that such a heading is not needed.

• No one has been asking for the heading. We have no evidence anyone (aside from its creator and a handful of others) sees a need for it.
• A header makes templates part of the article, which they are not.
• We can safely assume a reader knows how to scroll to the bottom. We need not assume our readership are morons: shall we have pop-up messages telling them there's relevant information just after the lead, or in the middle of the article? Shall we put "click to enlarge" in every image caption?
• Also in the "not morons" category: is there any evidence whatever that putting templates under "external links" has led anyone to believe those links are in fact external?
• Headers are for prose and information directly relevant to prose (references, notes), not templates. Moreover, the table of contents is for elements of the prose, not templates.

In short, this is a needless element of clutter that serves no real purpose, and should be eliminated. - Biruitorul ^Talk 16:21, 17 April 2009 (UTC)[reply]

I don't think this page is the correct place to discuss this move; perhaps WT:LAYOUT would be better. Wherever it goes, feel free to say from me that this is completely unnecessary and undesirable, per all your points above. Templates are not part of the article prose, therefore they are not part of the ToC hierarchy. Happy‑melon 16:34, 17 April 2009 (UTC)[reply]

That would seem a more logical place for the discussion, but there was an ANI thread on this a while ago which was closed, with the recommendation that the issue be taken up here. - Biruitorul ^Talk 16:58, 17 April 2009 (UTC)[reply]

I was poking around on the meta wiki but couldn't really find a good place to ask this: has there been any attempt to implement global preferences using SUL? It's a bit of a pain to have to set my language, signature, time offset, etc., every time I stumble onto a new sister project. –xeno ^talk 18:17, 17 April 2009 (UTC)[reply]

It might actually be coming to a wikipedia near you ! bugzilla:14950 --TheDJ (talk • contribs) 02:16, 18 April 2009 (UTC)[reply]

Wikipedia is one of the few major sites on the internet that specifies most of its CSS specifically for the "screen" media type. This, in a way, excludes Opera users browsing in full-screen, as Opera triggers the fullcreen "presentation" media type. While I'm aware that the two media types represent different purposes, as Wikipedia is not explicitly setting any separate styles for fullscreen presentations, and as no other WikiMedia project that I know of does this (so it's evidently not a MediaWiki peculiarity), I see no reason for it. _ɹəəpıɔnı 00:12, 18 April 2009 (UTC)[reply]

It is because we have "alternative" skins for handheld and printing. Note how I say alternative, and not additional. The solution is to use: media="screen, projection, tv, tty, aural etc..." You can see the obvious problem here CSS forgot it might be handy to define "all but" :D --TheDJ (talk • contribs) 01:23, 18 April 2009 (UTC)[reply]

There are only so many CSS media types. It seems perfectly reasonable to make our "screen" style rules apply to "projection" also. —Remember the dot ^(talk) 01:48, 18 April 2009 (UTC)[reply]

As a matter of fact, it seems that we used to do that. This must be a recent regression. --TheDJ (talk • contribs) 02:02, 18 April 2009 (UTC)[reply]

Commit located [10] --TheDJ (talk • contribs) 02:06, 18 April 2009 (UTC)[reply]

Ticket created. --TheDJ (talk • contribs) 02:14, 18 April 2009 (UTC)[reply]