This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
Problem with the position of coordinates with fund raising header
I finally located the problem code that is creating the conflict with the fund raising header and the position of the coordinates template. That code is:
<span id="coordinates">Test</span>
Where can one find the code used by id=coordinates?
and can it be altered, or a new copy created for the coordinaate template so we can finally get rid of the conflict with the fund raising header?
As noted at Wikipedia_talk:WikiProject Geographical coordinates#Coord loc on VP due to previous mention in VP, the coordinates are positioned with absolute coordinates. The fundraising and other notices shift the article position under the coordinates. The original position in the article moves to a different location for the expanded notice, the brief notice, and no notice (in addition to whatever other messages someone decides to create). I haven't checked if CSS allows positioning based upon an anchoring marker. (SEWilco (talk) 16:31, 29 November 2007 (UTC))
The next question would be: How is the position of the article title defined? That may give some insight into how best to alter the coordinates positioning. Dbiel(Talk)05:25, 1 December 2007 (UTC)
The minimum tag hierarchy to reduplicate its position would look something like this:
Nothing outside <div id="content"> (other than its direct parent tags, listed above) should affect its position, nor anything below it, so the conditions of its position are dependant on the stylings if these elements, the styling of <a name="top" id="top"></a> and the styling andcontent of <div id="siteNotice"></div>. The content of the sitenotice is extremely variable, and not very predictable. This means no absolute-positioning css trick can ever really exactly place an object on a page relative to the title, if the site has a sitenotice. A relative-position trick might be more feasable, but anything at the top between the title and contents (such as on a preview or diff page) would screw that up too.
BTW, if you want to see the stylings in effect, see monobook/main.css and look for the following definitions: body ; #globalWrapper ; #column-content ; #content ; #content ; h1, h2, h3, h4, h5, h6 ; h1 ; #bodyContent h1, #bodyContent h2 ; #bodyContent h3, #bodyContent h4, #bodyContent h5 ; .firstHeading ; a . --Splarka (rant) 09:43, 1 December 2007 (UTC)
Thanks for the reply. It is way over my head. I was hoping that someone with a good html background might be able to solve the problem as long as the variables were available; so thanks for posting them. It is a shame that a site with as much exposure as en.Wikipedia is unable to correct this display problem. Dbiel(Talk)05:42, 2 December 2007 (UTC)
If the #bodyContent (#article on older skins) box has "position:relative" on it, absolute coordinates on child elements seem to be taken based on it rather than the window. If this is done, and "top" is set to "-2em" on #coordinates, the results look ok at least in firefox. Can anyone verify what it looks like in other browsers?—Random83220:12, 7 December 2007 (UTC)
Note: #bodyContent is after the title header, and includes everything from "From Wikipedia, the free encyclopedia" to the category link box, inclusive. —Random83220:14, 7 December 2007 (UTC)
This seems to be the place to make the change then.
If it is possible to edit the line "From Wikipedia, the free encyclopedia" to include the coordinates so that "From Wikipedia, the free encyclopedia" is flush left and the coordinates are flush right. Any thoughts regarding this? Dbiel(Talk)03:28, 12 December 2007 (UTC)
This doesn't only affect coordinates - if someone could make a list of all templates that position themselves in the header, that would be great. —Random83215:42, 17 December 2007 (UTC)
VOA Script
I'm not sure, but I think perhaps a site change to the mediawiki code may have broken this widely used script.
I tried the script myself, and at least some of it functions seem to work. Make sure you tried to remove other scripts from your monobook.js and then refreshed the cache in your browser (usually Ctrl-R). I did find a small error in VoA's script (which he made several days ago), and I already notified him ∴ AlexSm18:32, 12 December 2007 (UTC)
Further investigation, mine works because I have the sub hardcoded, anyone who was importing that page will have issues. --uǝʌǝsʎʇɹnoɟʇs(st47) 20:09, 12 December 2007 (UTC)
That's actually pretty funny. :) However, like Tim, I don't see this as being a huge deal. The only way to "fix" it would be to overhaul the entire way the interwiki system is set up, and I can't imagine that it's that pressing an issue to warrant that much attention. EVula// talk // ☯ //09:35, 16 December 2007 (UTC)
Yeah, you're probably right. I've run across a couple of doubles clearly made accidentally, but I haven't been able to think of any harm that comes of it. Chick Bowen17:46, 16 December 2007 (UTC)
It's not that hard to fix. But Brion asked me the same question when I wrote the relevant code a couple of years ago, and I told him then that it doesn't matter. I have a habit of sticking to my guns. So it doesn't matter. -- Tim Starling (talk) 04:37, 18 December 2007 (UTC)
That is not (yet) possible. String parser functions have yet to be installed here. Most common solution is to use "Developer(s)". — Edokter • Talk • 12:40, 17 December 2007 (UTC)
prod template
Seems like something is wrong with the subst:prod|reason template. When I create the string ((subst:prod|non-notable group. no sources. possible WP:SPAM Google shows no real hits [1])) replacing the parens with the brackets {{}}, it posts a prod without the reasons included. Mbisanz (talk) 07:37, 17 December 2007 (UTC)
This is a common problem, and it's part of MediaWiki software. Try using:
((subst:prod|concern=non-notable group. no sources. possible [[WP:SPAM]] Google shows
no real hits [http://www.google.com/search?q=%22Tbilisi+Youth+City+Assembly%22+-wikipedia]))
When you transclude or substitute a template, parameters are separated by vertical bars: |. For example, {{template|param1=value1|param2=value2}}. param1 and param2 are named parameters, with the respective values value1 and value2. Before the equals sign you have the parameter name, and after it you have the value. When you don't have a specific parameter name, you get numbered parameters. For example, in {{subst:prod|non-notable}}, "non-notable" is a numbered parameter with a name of 1. Your reason was non-notable group. no sources. possible [[WP:SPAM]] Google shows no real hits [http://www.google.com/search?q=%22Tbilisi+Youth+City+Assembly%22+-wikipedia]. However, this is not a numbered parameter; it's a named parameter with the name non-notable group. no sources. possible [[WP:SPAM]] Google shows no real hits [http://www.google.com/search?q (everything before the equals sign) with a value of %22Tbilisi+Youth+City+Assembly%22+-wikipedia] (everything after the equals sign). To fix this, just precede the reason with 1= or concern=, as I've done above, whenever it contains an equals sign. GracenotesT§07:47, 17 December 2007 (UTC)
Note: I have modified the google search link used in the example above to be shorter, and modified comments to make sense in that context, in order to avoid unnecessarily widening the page. —Random83215:46, 17 December 2007 (UTC)
Hello. (PS: I moved this from WP:VPA). I don't know if the problem is only on my computer (even tought I tried both browsers I have) I noticed that all articles using Template:Infobox Algerian District, do not show up a map that should be in the infobox. For example the article Rouïba District, to which I added two images (maps) do not show up, I only get a transparent space, but if I click on the empty spaces, I can normally see those maps. Can someone fix this? TIA. --ESCONDITES12:49, 17 December 2007 (UTC)
Oops. Sorry guys, I fixed it, the problem was that I changed the infobox without changing the syntax of the articles. --ESCONDITES12:57, 17 December 2007 (UTC)
Userfication and Google searches
Hi, is it possible to prevent userfied pages from showing up on Google (and other) search listings? Current policy allows the userfication of pages which do not meet notability guidelines, such as those for films (which sensibly state that film articles should not be created in the mainspace until production has commenced). However, these userfied pages still return in Google searches, which defeats the point somewhat. For example, a userfied State of Play (film) ended up showing as something like the third result on Google searches for the film until I had it deleted from my userspace, and other projects yield similar results. I strongly suspect the answer will be in the negative, but is there anything which can be added to the page code to prevent this? Many thanks, Liquidfinale(Ţ) (Ç) (Ŵ)16:33, 11 December 2007 (UTC)
It's not currently possible through the interface to individually exclude pages from Google, but one option available is to blank the page, leaving the content available in the history, although this would not work so well if the page is actively being edited. Another option, if an entire set of subpages needs to be excluded (e.g. all AfD debates) is to have a developer put a rule in robots.txt. This would not, however, be practical to do for many individual user pages. Tra(Talk)17:09, 11 December 2007 (UTC)
Thanks for the speedy reply; I thought that might be the case, and I hadn't thought of merely blanking the page (though that would suggest to any lurking administrators that the userpage required deletion). I guess <!-- commenting it out --> would do the trick too. Best regards, Liquidfinale(Ţ) (Ç) (Ŵ)20:19, 11 December 2007 (UTC)
I don't know whether there is a special reason (strict privacy laws?) for eliminating Swedish and some Norwegian (maybe it should have been all Norwegian?) from all spiders. Is there an allowed place for things normally in English user space if you want it to be excluded by robots.txt? Currently it could for example be moved to a subpage at Wikipedia:Articles for deletion/title because of
But that would be a confusing place for something somebody wants to keep. Maybe robots.txt could add a special place for the purpose? PrimeHunter (talk) 00:55, 12 December 2007 (UTC)
That is kind of over my head...is there some way I can get my userpages on that list? And do you, or does anyone, know why WP allows user pages, etc., to show up on search engines? If this is not the place to bring it up, please direct me to the proper place. Regards.--Old Hoss (talk) 20:16, 18 December 2007 (UTC)
It's technically possible for a developer (I don't know whether others have the access) to add individual users or pages to robots.txt, but I doubt they will do it. There is a huge number of accounts and a large robots.txt would probably not be practical. I don't know whether it has been discussed to add the whole English Wikipedia user space to robots.txt, but it would be very simple to do. I suppose you could suggest it at Wikipedia:Village pump (proposals). I personally like being able to search as much as possible of Wikipedia with Google which is better than Wikipedias own search for some things. It sometimes annoys me that AfD pages are excluded (but I support that decision). PrimeHunter (talk) 21:34, 18 December 2007 (UTC)
Thanks for the feedback! I think I might continue this over at VP:proposals (maybe tomorrow when I have more time!) and see if anyone salutes it. My thinking is, if someone wants to see users on WP, they can go to speciallinks to do so; otherwise, it just confuses lay people. Regards.--Old Hoss (talk) 21:43, 18 December 2007 (UTC)
I just found that - I use Safari on WinXP. The article is John Rogers (divine) but I put it back to a single column. I take it that most browsers won't display it properly? Sbouldn't it be deprecated then? DuncanHill (talk) 01:15, 16 December 2007 (UTC)
When it says it won't "render properly" except in the mentioned browsers, it means it won't show two columns. Unless the unmentioned browser you're using is completely broken, it should just ignore the CSS specifying the multiple columns and display it just as if {{reflist}} were specified instead of {{reflist|2}}. I just loaded the old revision of that article in IE7, and that was the result I saw; maybe later I'll see if win-Safari will run under Wine. Also, eventually other browsers should get around to implementing that portion of CSS3, so the number of people who can see the intended effect will eventually grow. Anomie⚔16:57, 16 December 2007 (UTC)
I don't understand that. I did mention my browser - Safari (running on WinXP). It displays two columns, but some of the little letters (for multiple uses of a single source), don't shew where they should, instead they appear below the references, geting mixed up with other text, and making it hard/impossible to go from a reference to the sentence it is being used on. DuncanHill (talk) 17:05, 16 December 2007 (UTC)
Can you post a screenshot of what you're seeing with Safari? And I have no idea what version of IE7 you have, IE 7.0.6000.16575 on a Windows laptop I happened to have handy as well as an unknown version under Wine only show one column on that old revision. Anomie⚔18:38, 16 December 2007 (UTC)
OK, this is what I'm seeing with Safari on WinXP - the problem is at the bottom, where an a and b from one of the references overwrites the Obituary link. Problem with reflist2 displayDuncanHill (talk) 21:37, 16 December 2007 (UTC)
How very odd, Safari (at least on Windows) is drawing the two links where they would be if the first column just continued down... Do you see the same problem here, and if so for which letters? Also, if any Mac Safari users are reading this, do you see the same problem or is it Windows only? Anomie⚔01:32, 17 December 2007 (UTC)
So it's the <sup> tag interacting badly with the -webkit-column-count property causing the problem. Not that that helps you here, but if you decide to report it as a bug back to Apple it's good to know. Anomie⚔02:35, 17 December 2007 (UTC)
I've sent a bug report to Apple, with screenshot and source of page. It would be interesting to know if any other browsers have this problem. DuncanHill (talk) 10:19, 17 December 2007 (UTC)
Safari 3.0.4 for Mac displays the reflist fine for me as well, but the problem I've most noticed is that the links to the footnotes from the body of the article lead to nowhere, as they incorrectly target the place where the references would have been if they had been formatted in one column. Lesgles (talk) 21:36, 17 December 2007 (UTC)
Related problem, in FireFox with the Ref|2 in use, the second column (at least here and here) starts with two refs that are numbered the same. Additionally (at that's how I knew there was a problem), if you click on a ref then it doesn't match up with the footnote, which I assume is because of the double numbered refs. Both look fine in IE7 since the two columns thing doesn't work with IE as mentioned above. Any ideas why or is this a programing issue? Aboutmovies (talk) 19:18, 18 December 2007 (UTC)
My WORST fear...
I am User:L'Aquatique, and I am being forced to edit as an ip, which does not sit well with me! Here is what happened:
I use wikED to edit, and I guess it is malfunctioning. Lately the edit box has not been loading completely and slowly... Now it loads completely (but slowly, 5 mins and I've got a broadband connection) but I cannot input text into it. I believe it is wikED that is causing the problem because I signed out and turned off Greasemonkey and now I can edit. Unfortunately, I cannot remove the userscript from my monobook... because I cannot edit while signed in. I know that I'm supposed to report this to the developer, but I would consider this "exigent"... Can administrators edit my monobook and remove the script until it can be fixed? Thanks,
72.173.34.51 (talk) 06:08, 18 December 2007 (UTC)
Yea, now I see it. I'm not an admin though, otherwise I'd pull it. If you have IRC, I'd try that. Admin User:Misza13 looks like their on and active. I'd try posting to their talk page. Mbisanz (talk) 06:24, 18 December 2007 (UTC)
I've edited that out. However, please log in as User:L'Aquatique right away and respond showing that you are L'Aquatique. Although I couldn't see any security issues with removing one script, I'm a little uneasy editing user's .js based on IP requests. Gimmetrow06:30, 18 December 2007 (UTC)
If you're uneasy, next time give user a tip instead: "change the skin in Preferences, then edit monobook.js, then change the skin back to Monobook" ∴ AlexSm06:36, 18 December 2007 (UTC)
Whoops, forgot to date it. I was so excited. Nevertheless, the wikED function is still working... I'm afraid I am going to keep having problems. l'aqùatiquetalk06:40, 18 December 2007 (UTC)
Cleared the cache, that seemed to work. I'm going to bed now (if I went to bed knowing that I couldn't spontaneously edit the wiki if I wanted to, I'd have nightmares :D) but in the morning I'll drop a note by the developer of the script to see if he/she can get it fixed so I can use it again. Thanks SO much for everyone's help! l'aqùatiquetalk06:47, 18 December 2007 (UTC)
For future reference, you can fix these problems yourself by disabling javascript in your browser, editing your monobook.js, and removing the lines that are causing you trouble. AmiDaniel (talk) 10:05, 18 December 2007 (UTC)
In IE7, JavaScript is called "active scripting". You get to it via Tools > Internet Options > Internet > Custom level; it's in the "Scripting" section. (For other browsers, it's a lot easier to find JavaScript: fewer steps, more clearly labeled.) -- John Broughton(♫♫)14:09, 18 December 2007 (UTC)
Case sensitive links
This is a little bit picky and hard to explain, but here goes. A short time ago I was working on the disambiguation project disambiguating Britain, when I found a link in Court dress that should have been properly disambiguated as United Kingdom of Great Britain and Northern IrelandUnited Kingdom of Great Britain and Ireland. As I was about to type all that into a piped link, I thought to myself, "Wouldn't it be better if there were a redirect to some shortened version of that, say, "ukgbi"? Then, I wouldn't have to type all those letters into the link, and I could save a few bytes of server space, too. To see if anyone had thought of this before me, I typed "ukgbi" into the search box and hit "go." Sure enough, I was redirected to "United Kingdom of Great Britain and Ireland," so I disambiguated that way and went merrily along on my way. Then last night I was working on the same project, when Court dress came up on my list of links again. Perusing the history, I found that someone had undone my edit (which occasionally happens when someone doesn't understand the guideline about not linking to dab pages). Then I looked at the edit summary, and saw that someone claimed I had created a red link. "That can't be" I thought "I checked it." But when I looked into the history, the link was indeed red. A little investigation showed me that typing "ukgbi" in the search box caused the Wikipedia software to read it as UKGBI which was already a redirect (as you can see, it's a blue link), but making a link of ukgbi didn't have the same effect, so I created a new redirect (now also a blue link, but a different one).
So, my question is, is this a good idea? Is this the way the software is meant to function? Shouldn't the software handle the exact same text the exact same way, regardless of whether it's typed into the search box or into a link? It certainly seems like it should to me.
Yes, the search box will try alternative capitalisations if the page you have typed does not exist. As for linking to a redirect, this is probably not a good idea because if a page is created to replace that redirect, it is most likely that the link will now point to the wrong article (although a hatnote should be placed on the page), requiring another fix. Wikipedia:Don't worry about performance, and to save you typing out the correct links all the time, Wikipedia:Popups (available in the gadgets section of your preferences) and Wikipedia:AutoWikiBrowser can both speed up fixing (I think you need two clicks with Popups, a few more with AWB but you get all the other benefits of it too). Let me know if you would like help with either of these. mattbr20:06, 18 December 2007 (UTC)
I link to redirects all the time when disambiguating, and seem to remember reading (somewhere) that thats a perfectly acceptable procedure. Additionally both of the redirects mentioned were created specifically to make disambiguation easier (at least the one I created was) so I don't think they'll ever be replaced with an actual page. If I'm not right to link to redirects, I and a lot of other editors need to know about it. My primary reason for using it is to save typing, not help performance.
Also I have both popups and "popupFixDabs=true" in my monobook. Popups works fine, (on Firefox, but not IE), but I don't get the disambiguation choices that are advertised for "popupFixDabs=true." I suppose it might be helpful if you can tell me how to do that.
However, more to the point of my overall question, shouldn't the software be handling wikilinks the same way it handles text typed in the search box with respect to capitalization?--Steven J. Anderson (talk) 20:24, 18 December 2007 (UTC)
As far I'm aware, it isn't stated that you should not link to redirects while disambiguating, it is just that I would strongly advise against it specifically for the reason I have mentioned, whether the redirects have specifically been created or not. I would also consider it good practice while editing to link directly to the article desired (whether piped or un-piped) so that the appropriate text appears (the intended destination) when you hover over it (as happens in Internet Explorer, and this is probably useful for users of some assistive technologies as well), rather than some acronym, for example, which people may find more confusing.
As for Popups, when you hover over a link to a disambiguation page you should get a series of green links at the bottom of the popup which should be the links on the disambiguation page, click the one you want and away you go. If you have added it recently, try bypassing your cache.
With the search box and wikilinks, I'm not sure. It would need links to behave as they currently do depending on if the page exists or not, which would result in redlinks taking you to an article which you might not want (for example, you might want to link to aaaaa, and when you click it you would be taken to AAAAA which could be on a completely different topic). It could become confusing for people. People also tend to be lazier when typing in the search box as the result is not visible and doesn't matter, whereas it is visible and does matter when you are writing on a page. mattbr22:56, 18 December 2007 (UTC)
You can create a document in Notepad or something containing the possible page targets for a particular disambiguation page and copy and paste from there. That would be much easier than typing the links out all the time. Graham8701:50, 19 December 2007 (UTC)
Removing user name from search engines
Is there any way from preventing user pages from popping up on a search engine, especially as the first entry? I don't see the point in user pages being included in search engines. Also, user sub-pages pop up, which seems rather pointless as well. Thoughts?--Old Hoss (talk) 19:33, 18 December 2007 (UTC)
I was wondering, are there any plans to upgrade Wikipedia's interface making it more user friendly and... well... nicer?
I've been looking around but I can't find anything. Thanks, 2help (talk) 21:08, 18 December 2007 (UTC)
wikEd is a JavaScript application you can install to make editing more user-friendly. If not that, which part of Wikipedia's user interface do you find difficult or unintuitive to use? GracenotesT§23:14, 18 December 2007 (UTC)
Hi, thanks for the answer. It wasn't really a complaint; I was just wondering whether there was an active project to create some sort of 'newer-looking' Wikipedia. It just seems very simple at times. In a way that's good, I guess. Thanks again! 2help (talk) 00:43, 19 December 2007 (UTC)
SVG
What do I need to add/download to support svg files on my pc? It tries to save them as pngs and I would rather not do such. --Charitwotalk01:21, 19 December 2007 (UTC)
FireFox has built-in support for SVG, and so mediawiki won't try to translate to .png (or .jpeg). Even with lowly internet explorer, it ought to be possible by reverse clicking on an .svg image page and choosing "download link target" or whatever IE calls it. —EncMstr01:27, 19 December 2007 (UTC)
As far as I know, Mediawiki converts all SVGs to PNG (and doesn't look at your browser). You can easily get SVG file from the image page, e.g. using link Example.svg (SVG file, nominally 600 × 600 pixels, file size: 10 KB) on image:example.svg page ∴ AlexSm01:50, 19 December 2007 (UTC)
Classifying articles for a Wikiproject
Is there a bot which can be made to automagically add a "class=stub" to the Wikiproject template on the talk page of all articles which have the main articles shewing a stub-category included in that project? DuncanHill (talk) 03:00, 19 December 2007 (UTC)
How can I print a page with the link-colours shewing? I want to print off one of my userpages so I can work on the redlinks offline, but when I try print preview in either IE7 or Safari on WinXP, it is in black and white. DuncanHill (talk) 03:36, 19 December 2007 (UTC)
Try adding this to your monobook.css page and force refresh (ctrl+F5). This might add a red border around redlinks when printing (and in print preview). Only works for me in Firefox, but hey, maybe you'll have better luck. --- RockMFR09:14, 19 December 2007 (UTC)
@mediaprint{a.new{outline:#ba0000solid;}}
IIRC, IE7 doesn't support outline. You could try border instead, possibly with an additional rule display:inline-block;, or you might be able to highlight them all with something like background:#fcc. Anomie⚔12:36, 19 December 2007 (UTC)
I was testing this last night and couldn't get it to work - now I realize that I left a semi-colon in the wrong spot. LOL. Yeah, this is definitely the better solution. --- RockMFR16:49, 19 December 2007 (UTC)
To Susanlesch: this board is used for technical issues regarding MediaWiki / Wikipedia. Developers check here occasionally and will sometimes either respond here or elsewhere, or simply fix the issue. Cheers. --MZMcBride (talk) 20:14, 19 December 2007 (UTC)
To Random832: the developers are aware of this situation. Currently, there doesn't seem to be a way to stop the e-mail attacks. There are rate limits that could be imposed, however any such limit would most likely result in more sleeper accounts being used / created. Also, there are plenty of legitimate users who regularly send hundreds of e-mails through MediaWiki daily. Any solutions or potential fixes would surely be appreciated. : - ) --MZMcBride (talk) 20:14, 19 December 2007 (UTC)
What about a rate limit per account OR source IP [to prevent sleepers] per target (I can't think of ANY legitimate reason for someone to send even more than a few e-mails per hour to a single target user). Can you enlighten me, by the way, on a legitimate use case that requires sending hundreds of emails through emailuser in a day? —Random83206:20, 20 December 2007 (UTC)
Question about archiving
My talk page is automatically archived by User:MiszaBot III. I have a message at the top of the page saying that the page is automatically archived and giving the archive number. The problem is the archive number in the sign never changes, although the bot automatically goes to the next archive correctly.
I have fiddled with the sign and cannot figure out how to have it reflect correctly the archive number currently being used. For example, the sign says it is archiving to Archive 12, when it is really archiving to Archive 13. Occasionally I update the number in the sign manually. Any suggestions? Thanks! Mattisse15:48, 19 December 2007 (UTC)
I have never really liked the way article series boxes stick to the last reference, external link, or line of text in articles. It makes that part of the page look crowded, and sometimes even obscures the fact that the particular piece of text is the final text of the page.
I have, for some time now, applied a simple solution: when I edit articles, I usually make sure to leave two empty lines instead of one (or none) before the box(es). I also apply this practice to succession boxes, which always precede article series boxes and are actually rather close to them in terms of function. This way there can be some blank space dividing the box(es) from the text, which I find produces a much more pleasant result in terms of appearance.
I wonder if there could be some note in the style guidelines encouraging editors to precede the aforementioned boxes with two empty lines, and to what extent such a directive would be acceptable; I believe this is only a small adjustment of editing practices that would, however, perceptibly improve the very last part of many articles, especially the larger ones. Waltham, The Duke of16:38, 19 December 2007 (UTC)
Your question seems to be one of policy or a proposal, both of which have their own dedicated village pumps. However, from a technical perspective, padding could be added to the various templates that create the navigation templates in order to no longer require the "double-space" technique. Cheers. --MZMcBride (talk) 20:08, 19 December 2007 (UTC)
Maybe don't add the line breaks to the templates; that can cause inconsistency if templates are in a different order on another article. Standard practice is for templates to have no line breaks before or after. Gimmetrow20:17, 19 December 2007 (UTC)
I have posted this here because I did not know whether any template technical elements were involved. Perhaps if I leave messages in the other two pumps directing here? That should give the matter enough coverage.
Now, as far as any changes to the templates themselves are concerned, I am not sure that such a change would not result in unwanted side-effects. The gap is intended for the first template, after all, and I should not like to see any differences between the templates themselves (more often than not, there are more than one article series boxes in an article). Especially the idea of adding padding to a template with the intention of keeping it first at all times sounds inapplicable. No, I think that it had better be just this: simply add two empty lines between the article series boxes and any text (or reference list template) that might precede them.
Now that I think of it... Yes, I will submit this to the proposals section of the Pump (it does not sound much like policy). You are, of course, invited to offer your insight there. Waltham, The Duke of20:09, 20 December 2007 (UTC)
Special page link wiki-syntax
Where are the instructions for providing wiki links ([[___]]) to special pages?
Are you asking what Special: (namespace -1) pages have parameters that can be wikilinked? Eg: Special:Prefixindex/FooSpecial:Listusers/BarSpecial:Log/delete? If so, each Special page that takes a slash parameters has it written specifically for that Special: page. New Special: pages can also be added by extensions, so there is no definitive list of what parameters can be used, nor even of all the possible Special: pages on a wiki (Special:Specialpages for example does not list Special:Emailuser as it only works with a username supplied). Help:Special_page is a good place to start.
As far as I understand it, some of the special pages have convenient wikilink formats - for example, Special:Log/delete is a wikilink way of providing the same input as the url parameter type=delete to Special:Log. In general, though, if you need to link to one in a particular way that might not be supported using the convenient method, I prefer using class=plainlinks and an external link, perhaps even using fullurl: : <span class="plainlinks">[{{fullurl:Special:Log|type=delete&user=Nihiltres}} my deletion log]</span> makes my deletion log, which acts like one would want it to. In a template, you could go as far as to colour the output the same way as a normal wikilink, but I find that to be unnecessary for most non-templated cases. Nihiltres{t.l}16:26, 20 December 2007 (UTC)
"Written for it" = written in the code. The documentation is at Help:Special_page. If you do not find that documentation useful, you can research it yourself and improve it.
The only ways to find out which parameter (if any) are used for the slash, is to a) try it on each Special page (Special:Specialpages lists most, but not all), b) check the help pages linked above, or c) Check the source code at svn.wikimedia.org. For example, /phase3/includes/SpecialRandompage.php (look for $par):
* Main execution point
* @param $par Namespace to select the page from
Note that that only shows the default installed Special pages. Others are added via extensions, which are listed at Special:Version (see each version's source code for particular info). --Splarka (rant) 02:36, 21 December 2007 (UTC)
What links here: pages linked to within templates
Should links originating within transcluded templates have a special note beside them in the "What links here" page to reflect the fact that they're not mentioned in the body of the article? I'd like to be able to identify them at a glance. This is especially an issue with large templates of links. SharkD (talk) 12:06, 20 December 2007 (UTC)
What's the code for the rounded corners, i've been searching but can't find any reference to it. I've been noticing the rounded corners on different user pages. SKYNET X7000 (talk) 12:06, 20 December 2007 (UTC)
Rounded corners are a CSS effect that works only in Mozilla (aka Firefox) and Webkit (aka Safari) based browsers, which should use both of the following attributes within the style=" " attribute of the element to round, where z is by how many pixels to round and you replace the single corner code given here with code for each corner (i.e. this rounds only the top left corner, replace "top" or "left" with "bottom" or "right" and duplicate where applicable): -webkit-border-top-left-radius: zpx; -moz-border-radius-topleft: zpx; . That should work... you can also look at some of the code for my userpage if you get stuck, though I specifically only rounded top corners in my userspace. Nihiltres{t.l}14:16, 20 December 2007 (UTC)
I haven't found that it works in Safari; I've got rounded corners in my header, but don't see them in my browser of choice, which is Safari (I didn't even realize that the code was there for a while; it was "gifted" to me by someone, and truth be told, I'd rather have square edges, but want to maintain consistency across my userpages). EVula// talk // ☯ //15:20, 20 December 2007 (UTC)
Could User:Outriggr/metadata.js be made into a gadget? It's a very useful script that gives the article assessment data for each article right below the title. This is a function that I think would be useful to have more people using, as it would add to Wikipedia's credibility to some degree to have the assessment process be more open. It is of use to both editors and casual readers. I don't know whether it works in all major browsers, but if it is or can be changed to be cross-browser compatible, it's exactly the sort of script that makes a good gadget. Pyrospirit (talk·contribs) 14:34, 20 December 2007 (UTC)
It seems like a good script, and support its addition to the gadget list; my only issue with it is that it uses innerHTML to change the site notice. Ideally, the script should not use innerHTML, and the meta-information should be added to a more distinct location than the site notice. Also, the script does make a request every time an article is visited, which may be a problem if opening many articles in quick succession for purposes unrelated to assessment. GracenotesT§17:30, 20 December 2007 (UTC)
Wikipedia still accepts edits, only that they're NOT into any articles, except into the "history section". I've found a glowing mess near one of the articles. Wikipedia is doing a good impression of Three Mile Island. 205.240.146.37 (talk) 22:36, 20 December 2007 (UTC)
It's also unclear to me what you refer to. My best guess is that you need to bypass your cache on an article to see the current version, including recent edits you have only been able to see in the page history so far. PrimeHunter (talk) 23:13, 20 December 2007 (UTC)
Determining whether a page is watched
Is it possible to determine whether a page is watched without screen scraping off the human editing interface? I don't think the API allows me to do this yet. I'd like to come up with a better fix for this bug. (I've already dealt with the edit token and wpEdittime). Thanks. MER-C13:17, 21 December 2007 (UTC)
I believe MER-C meant whether the current logged in user could tell if a page was watched, either via the API, or via javascript variable. Screen scraping in this case involves checking something like if(document.getElementById("ca-unwatch")) which has to wait for the document to load. The API is not too helpful either. I suggest submitting a bug/feature request for a new JS variable like wgWatchStatus. It could maybe become part of the wgAjaxWatch array, like {"watchMsg": "Watch", "unwatchMsg": "Unwatch", "watchingMsg": "Watching...", "unwatchingMsg": "Unwatching...", "watched" : false}. Note that the ajaxwatch.js uses a document load hook event and screen scrape as well, ick. --Splarka (rant) 02:01, 22 December 2007 (UTC)
.png)
