Wikipedia:Village pump (technical)

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

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

view · edit

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

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

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

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

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

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

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

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

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

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

Interwiki/interlanguage links not changing to secure

Why isn't {{sec link auto}} behavior by default? Its incredibly annoying when you're using a secure connection, that whenever you click on an interwiki/interlanguage link, you get taken to the insecure connection. For example:

Wikinews (without sec link auto)
Template:Sec link auto

I don't really see the convenience in not making it default to a secure link if you're currently using a secure connection.Smallman12q (talk) 19:25, 15 January 2010 (UTC)[reply]

because {{sec link auto}} is a rarther new template, introduced because the bugzilla bugticket to actually SOLVE this issue has been stale for over 3 years. Much of this has to do with the parsercache btw. To introduce this feature, would mean that the entire set of pages of the Foundation has to be stored in two modes in the cache. Once with normal links, once with secure links. That requires an investment in resources. There are clientside scripts btw that can help with this. One is a greasemonkey script, the other is a script on en.wp but I can't find it right now. —TheDJ (talk • contribs) 20:15, 15 January 2010 (UTC)[reply]

I did use the greasemonkey script a while back. But greasemonkey only works on firefox, and not IE which is what most windows computer have. I do realize that the pages would have to be stored in 2 seperate caches...why doesn't the wikimedia foundation instead use javascript. It wouldn't be difficult to create a javascript solution...or perhaps offer a gadget to solve it.Smallman12q (talk) 20:46, 15 January 2010 (UTC)[reply]

(Edit conflict... Hehe, I see Smallman and I have the same idea.)

As far as I know and can see from my testing: Only pages that have been visited by a user on the secure server are cached with an extra copy. This already happens when we use {{sec link auto}}. And that copy is probably as usual just cached for a week. The number of users on the secure server is low, so the number of pages cached by them probably won't be that high.

I have tested the other script: User:Anakin101/alwayssecurewikipedia.js. It works splendidly. (But it lacks handling of some rare kinds of links.)

TheDJ: You said "clientside", that gave an idea: We could make it so all users on the secure server automatically load that script. So we could make this entirely clientside, no need to change the MediaWiki software. And that wouldn't cause any extra caching. The script should of course first be copied to an official location and updated/checked by some of you javascript experts. (I don't know enough javascript to understand that script.) And it would be nice if the script understood some kind of escape marking (a <span> with some class) so we could prevent the script from auto-changing some links, since sometimes we want to on purpose show normal links to users on the secure server.

--David Göthberg (talk) 20:52, 15 January 2010 (UTC)[reply]

Yes I was thinking something similar. Though I think it would be best to test that on the English Wikipedia first. I also wonder what happens when Greasemonkey and the Anakin script are both active..... —TheDJ (talk • contribs) 21:53, 15 January 2010 (UTC)[reply]

So is anything going to be done?Smallman12q (talk) 20:00, 17 January 2010 (UTC)[reply]

MediaWiki_talk:Common.js#Always_secure_Wikipedia —TheDJ (talk • contribs) 20:48, 17 January 2010 (UTC)[reply]

Thanks for the link.Smallman12q (talk) 17:26, 18 January 2010 (UTC)[reply]

MediaWiki:Common.js/secure.js is now automatically loaded when you use the English Wikipedia from the secure server. —TheDJ (talk • contribs) 20:54, 21 January 2010 (UTC)[reply]

So is there a need now for {{sec link auto}}? Should that template be marked obsolete?Smallman12q (talk) 23:40, 22 January 2010 (UTC)[reply]

First we should wait a while and see how well the new javascript fix works. Secondly, not all users have javascript enabled, since many schools, workplaces and libraries etc have javascript disabled on their computers (since many of the ways to hack browsers need javascript), and it is often exactly those users that need to use the secure server. So we should probably continue to use {{sec link auto}} on the main page (sections "Wikipedia's sister projects" and "Wikipedia languages") and the few system messages where we are using it now.

But for most other places it from now on is mostly overkill to use {{sec link auto}}. I will update its documentation and Wikipedia:Secure server so they explain that.

--David Göthberg (talk) 09:55, 23 January 2010 (UTC)[reply]

Also, every change that needs to be made to a page adds execution time to the script (much more than just "looking" at the url in the page). As such every link that is fixed with sec link auto, won't have to be fixed with the script and that will make usage of the site simpler. —TheDJ (talk • contribs) 20:55, 23 January 2010 (UTC)[reply]

But using {{sec link auto}} has other costs as well the human time cost (very high) and an increased in page rendering time since the wikiparser isn't typically efficient. And don't forget the whole thing is a workaround until the dev fix the bug (i.e. implement the script server side). — Dispenser 21:38, 23 January 2010 (UTC)[reply]

There's a bug with dumps with this link http://dumps.wikimedia.org/enwiki/20091128/
it becomes https://secure.wikimedia.org/wikipedia/dumps/wiki/
For those on the secure server, observe: http://dumps.wikimedia.org/enwiki/20091128/ Smallman12q (talk) 23:48, 24 January 2010 (UTC)[reply]

Added to the ignore list. You might have to purge your browser cache however. —TheDJ (talk • contribs) 01:54, 25 January 2010 (UTC)[reply]

Thanks, I'll let you know if any other bugs come up.Smallman12q (talk) 02:03, 25 January 2010 (UTC)[reply]

testing templates (continued)

for anyone interested in commenting bugzilla:22135. I would have posted this the previous discussion here, but the discussion has already been archived.

Sorting tables with ordinal numbers

At a current FLC, it has been brought to light that ordinal rankings such as 1st, 2nd, 19th, 24th don't sort properly in standard tables like this one. Instead of sorting in descending order of rank as 1st/2nd/19th/24th, it sorts as 19th/1st/24th/2nd, as shown here: Template:Awards table2 |- | 2001||First entry|| || style="background: #FFE3E3; color: black; vertical-align: middle; text-align: center; " class="no table-no2 notheme"|1st|| |- | 2002||Second entry|| || style="background: #FFE3E3; color: black; vertical-align: middle; text-align: center; " class="no table-no2 notheme"|2nd|| |- | 2019||Nineteenth entry || || style="background: #FFE3E3; color: black; vertical-align: middle; text-align: center; " class="no table-no2 notheme"|19th|| |- | 2024||Twenty-fourth entry|| || style="background: #FFE3E3; color: black; vertical-align: middle; text-align: center; " class="no table-no2 notheme"|24th||

|}

Is there an elegant way to solve this? Any help appreciated, Skomorokh 18:46, 19 January 2010 (UTC)[reply]

You need to use a sort template like {{ntsh}}.—NMajdan•talk 19:19, 19 January 2010 (UTC)[reply]

Like this:

Template:Awards table2 |- | 2001||First entry|| || 1st|| |- | 2002||Second entry|| || 2nd|| |- | 2019||Nineteenth entry || || 19th|| |- | 2024||Twenty-fourth entry|| || 24th||

|}

Although it doesn't appear to work with the {{nom}} template, so you may just have to format those cells individually.—NMajdan•talk 19:23, 19 January 2010 (UTC)[reply]

Ok, looks like you can put the sort template inside the {{nom}} template like this: {{nom|{{ntsh|19}}19th}}

Template:Awards table2 |- | 2001||First entry|| || style="background: #FFE3E3; color: black; vertical-align: middle; text-align: center; " class="no table-no2 notheme"|1st|| |- | 2002||Second entry|| || style="background: #FFE3E3; color: black; vertical-align: middle; text-align: center; " class="no table-no2 notheme"|2nd|| |- | 2019||Nineteenth entry || || style="background: #FFE3E3; color: black; vertical-align: middle; text-align: center; " class="no table-no2 notheme"|19th|| |- | 2024||Twenty-fourth entry|| || style="background: #FFE3E3; color: black; vertical-align: middle; text-align: center; " class="no table-no2 notheme"|24th||

|}

Hope that helps.—NMajdan•talk 19:27, 19 January 2010 (UTC)[reply]

To avoid duplicating the number, you can use something like {{nts|19}}th. Svick (talk) 19:35, 19 January 2010 (UTC)[reply]

Haha. Yeah. Didn't even think of that. That would be cleaner.—NMajdan•talk 19:37, 19 January 2010 (UTC)[reply]

Thanks very much for the workaround chaps, very helpful. It would seem preferable though, given the likelihood that charts will become more common, for there to be tables or templates that "understood" ordinal sorting, as in "table class:ordinal" or similar setting. Mahalo, Skomorokh 23:26, 21 January 2010 (UTC)[reply]

Move-tool Rdr option

The move-tool page includes an option to suppress creation of a Rdr for the moved page, or of one for each of the two being moved. Usually an article worth moving has a talk page, but the main-namespace page that will take over the moved page's title is unlikely to initially need any talk. I've responded to this situation in various ways. The full range of choices that occurs to me is:

Leave all three boxes checked, and delete the talk-page Rdr that results.
Uncheck create-Rdr (wincing at the red-tinged warning msg saying you're recreating a de-facto "deleted" page), and create the new Dab page, new primary-topic article, or presumably needed Rdr, thus starting the history of the new main-namespace page. *
Uncheck move-talk-page, then separately move the talk page, copying the same "reason for move" and unchecking create-Rdr
Leave all three boxes checked, and immediately edit the talk-pg Rdr to convert it to a soft Rdr
Leave all three boxes checked, and count on someone, when talk on the talk-pg commences, to edit it to start with a soft Rdr.

* ^{Note re point 2 above -- the No-Move-tool-Rdr option}
BTW, once the new main-namespace page is created, its edit history shows no sign of a deletion, but its public-logs page does show e.g.

moved Outgroup to Outgroup (cladistics) [without redirect]

If (per option 2) the talk page is left uncreated, the first edit page of a session that (if saved) will create it has a similar red-tinged warning msg (only similar, bcz "Talk:" appropriately appears in both this one's links). The same msg appears (along with "There is no revision history for this page.") on its history page, which can be reached by editing a URL, or by using Pop-up tools from the edit page; a third route is via pop-ups, from a link (other than one on a page's tabs) to the main-namespace page, by hovering "talk" on the pop-up menu and clicking "history" when the talk-page's menu pops up.

Note that only the last 2 avoid breaking any existing links from other talk pages, in ways whose repair probably require (brief or extensive) consultation of edit histories.
On reflection, i'm inclined to think that immediate soft Rdr is the right approach (soft-Rdr only-when-needed will not occur to many discussion-starting editors, especially the non-signing IPs who often initiate on a page's talk; hard Rdr as talk page content -- for a main-namespace page that was only briefly a Rdr -- violates the principle of least astonishment, and in fact can create complete frustration on the part of the user: Rdr'n to an article is often unsurprising & the "Rdr'd from..." notice can go unnoticed without harm; in contrast, Rdr'n to a talk page that is only tenuously and perhaps cryptically related to a corresponding un-Rdr'd main-namespace page can be "indistinguishable from [evil] magic", and very off-putting to a non wiki-editor.
I came to VPT intending to suggest changing the move to so that creation of main-namespace and talk Rdrs become separable from each other. If others support my new insight abt soft Rdrs, i suggest that the move tool at least to have a red-tinged message drawing attention to something like WP:Soft redirect, whenever a combined main-namespace/talk page move is requested.
It might in fact be a good idea, whenever a talk page is moved (even separately) without explicit suppression of Rdr (ands without explicit request for a "hard" Rdr), for the move tool to leave behind a soft Rdr rather than a plain "hard" one.
--Jerzy•t 23:17, 20 January 2010 (UTC)[reply]

Tl;dr, just leave the redirects behind. They're cheap. –xeno^talk 23:19, 20 January 2010 (UTC)[reply]

Color this
X UNRESOLVED
-- tho i've probably already given too much detail, and will simply reiterate: Tk pgs should discuss their accompanying articles & Rdr'g to discussions of other articles considered harmful.
--Jerzy•t 18:14, 21 January 2010 (UTC)[reply]

I'm not trying to be difficult, but I still don't understand the problem. Redirects to articles have the talk pages of the redirect redirected to the talk page of the article. So? –xeno^talk 18:20, 21 January 2010 (UTC)[reply]

problem with clicking on PDF file

Clicking on File:Apollo 11 Tapes Report.pdf and then "open PDF" brings up Adobe Reader with a blank page and an error message. If I enter "File:Apollo 11 Tapes Report.pdf" into the search box it works. Is this a bug? Bubba73 ^{(Who's attacking me now?)}, 00:20, 21 January 2010 (UTC)[reply]

Yeah something is wrong with the document or the conversion process. When I download it, the text is blurry. I don't understand what you mean by "searching" for the file though as it would just bring you back to that page. Gary King (talk) 02:25, 21 January 2010 (UTC)[reply]

If I enter "File:Apollo 11 Tapes Report.pdf" in the Search/Go box and click "Go" it works as it should. If I click on it from there and click "open PDF" it works and the text is clear. The error is when clicking on File:Apollo 11 Tapes Report.pdf and then "open PDF". Bubba73 ^{(Who's attacking me now?)}, 02:31, 21 January 2010 (UTC)[reply]

I went to the file via the search box as you said, downloaded the file, and the text still appears blurred. I don't understand why that method would return a different result, anyway. Gary King (talk) 02:38, 21 January 2010 (UTC)[reply]

Looking at it on File:Apollo 11 Tapes Report.pdf, the text looks blurred, but not so much when downloaded. The problem, however, is that (foe me at least) it doesn't show anything when clicking on File:Apollo 11 Tapes Report.pdf and then "open PDF" - just a blank page and an Adobe Reader error message. Do you get the error message? (It might only be me.) Bubba73 ^{(Who's attacking me now?)}, 02:44, 21 January 2010 (UTC)[reply]

Did you click http://upload.wikimedia.org/wikipedia/commons/a/a4/Apollo_11_Tapes_Report.pdf? It is not blurred. Regards, —mattisse (Talk) 02:46, 21 January 2010 (UTC)[reply]

Bubba, I did not get an error message but that's most likely because I am using a different computer setup than you are (I'm on a Mac and using Preview.app to read PDF files). Anyway, when I open the PDF file directly from the link above, the text is still blurred. No error message though. Gary King (talk) 02:48, 21 January 2010 (UTC)[reply]

Clicking on the link above works. I have the problem with Firefox but not with IE. The Beta version of WP has no effect on the problem. Bubba73 ^{(Who's attacking me now?)}, 02:51, 21 January 2010 (UTC)[reply]

If clicking on that link gives you a readable PDF file then something is wrong with your setup, as that is the exact same link that your browser goes to if you try to download the PDF from File:Apollo 11 Tapes Report.pdf. Gary King (talk) 02:53, 21 January 2010 (UTC)[reply]

I have the problem with Firefox and I am using some sort of add-on for PDFs in it. Bubba73 ^{(Who's attacking me now?)}, 03:21, 21 January 2010 (UTC)[reply]

Hm, using Firefox, and it looks pretty clear to me. Woogee (talk) 22:19, 21 January 2010 (UTC)[reply]

Then the problem is most likely with the Firefox PDF add-onm I have. Bubba73 ^{(Who's attacking me now?)}, 22:34, 21 January 2010 (UTC)[reply]

That's possible, I don't have that add-on. Woogee (talk) 23:04, 21 January 2010 (UTC)[reply]

Special Page Problem

There's a major problem I've noticed. If this doesn't belong here, please move it to where it does belong. Anyway, whenever you type a special page that doesn't exist, it always says "Return to Main Page". Now, the problem here is that it always says that, no matter what page you were on before (so if you were on the page Wikipedia, for example, it would still say "Return to Main Page"). Please fix this as soon as possible. Thank you. --Ha dg er 04:03, 21 January 2010 (UTC)[reply]

The question is whether or not the wiki software keeps track of what page you were just viewing. Typically this is done by adding an extra parameter to the URL. There's also the JavaScript method, but that's not always reliable as some people have JavaScript disabled, etc. I don't think this feature exists in the software and will be implemented any time soon, which is why it just suggests that you return to the Main Page. If you really want, you can just use your browser's back button to return to where you were. Gary King (talk) 05:01, 21 January 2010 (UTC)[reply]

The login screen offers the correct "return to" link. OrangeDog (τ • ε) 13:32, 21 January 2010 (UTC)[reply]

That's because the Login/register link explicitly contains the "returnto=" option. You would have to add that to each and every special page link. —TheDJ (talk • contribs) 13:51, 21 January 2010 (UTC)[reply]

If the feature already exists in the software, then yeah it could be done for Special links, too. Depending on how those links are constructed, it doesn't have to be added to each one, of course; it'd just have to be added to the function creating the links. If that's the case, then this could be a legitimate suggestion to be added to MediaWiki's Bugzilla. Gary King (talk) 17:36, 21 January 2010 (UTC)[reply]

(undent) Why not just use the HTTP referer to determine where the viewer came from? Isn't that what it's for? --Thinboy00 @076, i.e. 00:49, 25 January 2010 (UTC)[reply]

Need help with a table

I created a table that works fine in my Sandbox, but when I go to put it on the article it's intended for, it screws up. The problem is that I want to keep a background color in the table (a soft pastel green), and also have a dark green border. But when I save it to the article, it surrounds everything below the table with the dark green border, and fills the whole lower part of the article with the light pastel green color. I've tried to do everything I could think of, and have been working on it for hours, all to know avail. Does anyone who knows about table design have time to look at this? I would be so grateful! Here is my Sandbox (to see how it's supposed to look): User:Saukkomies/My Sandbox

And here is the article where it isn't working right: House burning of the Cucuteni-Trypillian culture

You'll see the table when you get there, you can't miss it. It's entitled: Periodization table of Neolithic cultures that practiced house burning Thanks! --Saukkomies ^talk 06:24, 21 January 2010 (UTC)[reply]

The problem is in your original code, so it's actually "broken" in both your sandbox and the article. I fixed it. Gary King (talk) 08:17, 21 January 2010 (UTC)[reply]

Thanks so much Gary! I deeply appreciate your help. :) --Saukkomies ^talk 01:39, 22 January 2010 (UTC)[reply]

Extra line added when transcluding a template that begins with a line enclosed in curly braces

For some reason, an extra line is added immediately before {{NYinttop}} wherever it's used. Similarly, this revision of {{Jcttop}} did the same thing until I came up with a workaround this morning. This is probably a MediaWiki bug, but does anyone know of a workaround that can be used to eliminate the extra line in the meantime? (As a side note, the presence of the extra line is only noticeable when the template is preceded by another blank line separating the template from a paragraph; however, I'd appreciate a better workaround than removing that line.) – T M F 12:06, 21 January 2010 (UTC)[reply]

Well known problem. It's not really a bug as a line with a template and a newline character would, well, have a template and a newline character. Any two newline characters in a row creates a new paragraph in MediaWiki. So this is really just expected behavior. You'll just have to remove one of the newlines to "fix" this. If the software were to fix this for you, then it would have to "trim" the text, which could return undesired results since sometimes people WANT newlines but then cannot create them, and therefore the software instead acts the way it is now. Gary King (talk) 17:31, 21 January 2010 (UTC)[reply]

But the template doesn't have a new line in it, which is the issue here. The only new line in {{NYinttop}} is where the documentation is, and since that's enclosed in "noinclude" tags, that shouldn't be transcluded. – T M F 17:39, 21 January 2010 (UTC)[reply]

It looks like you fixed it with your edit. Gary King (talk) 17:53, 21 January 2010 (UTC)[reply]

For {{Jcttop}} yes, for {{NYinttop}} no. See List of county routes in Erie County, New York (225–256) (which is a horrible article, but that's beside the point), where two new lines are present before both uses of NYinttop, even though there's only one new line preceding the template in the article and no new lines in the template. – T M F 18:03, 21 January 2010 (UTC)[reply]

I think you may be referring to the bug or feature documented here: Meta:Help:Newlines and spaces#Automatic newline at the start: "Templates starting with *, #, :, ; or {| automatically get a newline at the start" (and similarly at Help:Newlines and spaces#Automatic newline at the start: "Templates starting with *, #, or : automatically get a newline at the start"). In which case, obscuring the start character(s) with a dummy template may help. — Richardguk (talk) 18:20, 21 January 2010 (UTC)[reply]

Yeah, that would definitely explain it. How would I go about obscuring the start character in this case? – T M F 18:36, 21 January 2010 (UTC)[reply]

One way to sidestep the bug/feature would be to use <table><tr><td>...</td></tr></table> HTML syntax instead of wikitable syntax, as this is not senstive to line breaks in the code.

Looking more closely at {{Jcttop}}, I think the problem may be related to the optional "The entire route is in..." text preceding the table as plain text. So the template can begin with text (inline or paragraphed depending on where the template is placed) or a block element (the table), according to the arguments sent to it. One simplification would be to move the text to follow (rather than precede) the table. But this might be too complicated given that you are using multi-part templates to build the table. Another option might be to incorporate the text into an optional row prior to the table heading (taking care to make it span the appropriate number of columns), so that the template generates only tabular output.

The template currently includes the code: ...<LINEBREAK>{|{}}| class="wikitable"... This seems to translate to if the optional text applies, end it with a linebreak and the opening brace of a wikitable-start; otherwise just have the opening brace of a wikitable-start; then close the pair of braces from the opening #if; then add a pipe to turn the table brace (from either the true or false part of the long #if) into wikitable markup "{|"; then apply the 'wikitable' class.... It's not clear to me why the {| wikitable markup has been split across the closing pair of braces rather than falling entirely within or (more simply) following the initial conditional code. Maybe changing the code to ...|}}<LINEBREAK>{| class="wikitable"... would clarify things.

I won't pretend to understand all that is happening here, but those are the options I would consider.

— Richardguk (talk) 19:37, 21 January 2010 (UTC)[reply]

Well, {{jcttop}} is fine, it's {{NYinttop}} that has the issue at the moment since all the latter template is is a call to {{jcttop}} with state=NY specified. – T M F 21:36, 21 January 2010 (UTC)[reply]

Experimenting with Special:ExpandTemplates, it does seems as though the template-within-a-template is leading the bug/feature to add a double linebreak rather than a single linebreak before the table. Given that, the only other option I can think of would be to copy (or subst) the relevant code from {{Jcttop}} into {{NYinttop}} and amend it there instead of double-transcluding it. — Richardguk (talk) 22:27, 21 January 2010 (UTC)[reply]

This is Template:Bug. Happy‑melon 00:08, 22 January 2010 (UTC)[reply]

Great, a bug that's been open for two years with no fix in sight. *sigh* @Richardguk: I think what I'll just do instead is call {{jctint}} where the extra line is an issue, i.e. where {{NYinttop}} is used following prose and not starting a section (where the presence of the extra line doesn't matter). It's a shame that this is for all intents and purposes an unresolvable issue, but I appreciate everyone's help anyway. – T M F 01:18, 22 January 2010 (UTC)[reply]

E-mail User gone from Toolbox?

I can't seem to find "E-mail User" on the toolbox (or anywhere) on the left side of the page on user pages and user talk pages in which I know they have e-mail enabled. I can always use Special:Email but I'm confused as to why I cannot find it in the toolbox where it always has been. There's no reason that I shouldn't be seeing it as I'm an admin and definitely not blocked and I haven't heard anything about a developer changing the coding to remove the Email User link. Thanks, Valley2city^‽ 15:47, 21 January 2010 (UTC)[reply]

I'm still seeing it (at least, I saw it on your page!) in Firefox... ╟─Treasury Tag►directorate─╢ 16:28, 21 January 2010 (UTC)[reply]

The "E-mail user" link on your user page works for me, too. First thing first: try blanking your monobook.js page, then do a hard refresh as explained on that page, to see if that fixes it for you. Gary King (talk) 17:34, 21 January 2010 (UTC)[reply]

Hmm, maybe it's a Google Chrome thing. As a Dell Tech is currently working on my laptop I'm on another computer and it worked for one refresh in Firefox and then disappeared and it did not work in IE. There possibly is something in my monobook as I have a lot of administrative and other tools run from it. I'll take a look and see if I can figure out if anything is wrong. Thanks. Valley2city^‽ 18:52, 21 January 2010 (UTC)[reply]

Transcluded related changes feed breaks section headers

At Wikipedia:Wikipedia Signpost/Newsroom, the transcluded feed of related changes started distrupting the headers for all the sections on the page: [1] . This had been working fine before, but today the page headers went wacky and the only thing that has been able to restore them is removing that transcluded feed. Halp! —Preceding unsigned comment added by 99.26.235.126 (talk) 19:52, 21 January 2010 (UTC)[reply]

This is know problem bugzilla:16129 —TheDJ (talk • contribs) 20:10, 21 January 2010 (UTC)[reply]

"nowiki" inside "pre" problem

Why this code:

<span style="white-space:nowrap;"><nowiki>[[File:{{PAGENAME}}|thumb|Legenda]]</span></nowiki>

inside <pre></pre> result in this:

<span style="white-space:nowrap;">[[File:{{PAGENAME}}|thumb|Legenda]]</span>

See for example this in edit view:

<span style="white-space:nowrap;">[[File:{{PAGENAME}}|thumb|Legenda]]</span>

It's not the same. Isn't something wrong? Mosca (talk) 23:37, 21 January 2010 (UTC)[reply]

Not sure what you're trying to achieve, but how about using one of the following instead of "pre"? - Pointillist (talk) 23:51, 21 January 2010 (UTC)[reply]

<span style="white-space: pre; font-family: monospace; display: block;"><nowiki>[[File:{{PAGENAME}}|thumb|Legenda]]</nowiki>

result= [[File:{{PAGENAME}}|thumb|Legenda]]

or just

<code><nowiki>[[File:{{PAGENAME}}|thumb|Legenda]]</nowiki>

result= [[File:{{PAGENAME}}|thumb|Legenda]]

Try:

<span style="white-space:nowrap;"><nowiki>[[File:{{PAGENAME}}|thumb|Legenda]]</nowiki></span>

That is, doubling the nowikis. Look at it in the edit window to see what I mean. Happy‑melon 23:57, 21 January 2010 (UTC)[reply]

Thanks for you answers. I'm not trying to find solutions. What I mean is: "nowiki" really works inside "pre" while other code (<ref></ref>, <includeonly></includeonly>, <blockquote></blockquote>, tables, wiki code in general...) is shown like plain text? Mosca (talk) 00:16, 22 January 2010 (UTC)[reply]

Back in the old days we had to use <nowiki> tags inside the <pre> tags, otherwise all other tags were interpreted by MediaWiki. So for that reason <nowiki> tags were not shown, since they were not supposed to be seen. I am pretty sure that behaviour was kept for backwards compatibility, otherwise lots of old <pre><nowiki> ... </nowiki></pre> usages out there would suddenly have shown their old <nowiki> tags.

If you want to actually show a <nowiki> tag then we usually code the tag like this: "<nowiki>". Here's an example, check it out in the edit window too:

<nowiki> Some text. </nowiki>

Of course, it is now some years since the <pre> tags were updated to also have the functionality of the <nowiki> tags, so it is probably time to update MediaWiki to show <nowiki> tags inside them.

--David Göthberg (talk) 01:18, 22 January 2010 (UTC)[reply]

Thanks for you explanation. I though <pre> worked fine unless it had another <pre></pre> inside <pre></pre>. It's strange since I never saw this problem. Always learning. Mosca (talk) 02:09, 22 January 2010 (UTC)[reply]

You probably haven't seen it before since it is so rare that we need to show <nowiki> tags inside <pre> tags, and the editors that write such examples are usually very experienced and already know how to handle that.

By the way, if you want to show <pre> tags inside <pre> tags, then you escape them the same way: "<pre>". The "<" part simply is the html code for the lower than "<" character. So here's an example with that:

<pre> Some text. </pre>

We use such escaping to insert all kinds of special characters that otherwise would be interpreted by MediaWiki, like hash "#" = "#", space " " = " ", pipe "|" = "|", and braces "{ }" = "{ }" and so on. We mostly use this in template code. Wikipedia of course has several articles about this.

--David Göthberg (talk) 10:54, 22 January 2010 (UTC)[reply]

Can I change the link color by style attribute rather than setup a CSS?

I want to make a parameter in the template which will control the text color. The text entry isn't linked by default. Rather I prefer to make it optional to modify link color along the unlinked text because the default background is quite deep, making the default linking color scheme to hard to read. Can I change the link color by style attribute like style="(link-color):white" or something like that? -- Sameboat - 同舟 (talk) 04:42, 22 January 2010 (UTC)[reply]

Not without sticking span tags with style attributes within every link, off the top of my head. --Izno (talk) 06:15, 22 January 2010 (UTC)[reply]

I suggest that the Image Annotator gadget be installed for Wikipedia.

I suggest that the Image Annotator gadget be installed for the Wikipedia site. This is a gadget that allows people to comment on portions of a picture. The gadget is active over at WikiCommons and I find that it's useful. Installing the gadget on Wikipedia would not only make this functionality available there, but would also allow Wikipedia readers to see comments attached to Wikicommons photos. Without the gadget Wikipedia readers will not even realize that there are notes attached to a Wikicommons photo.

Here is an example of a Wikicommons photo that has notes attached. By hovering your mouse cursor over the photo you can read the notes. Also notice the "add note" button, that's the entry point to using the gadget. http://commons.wikimedia.org/wiki/File:Magnus_890_electric_chord_organ.JPG

Here is a Wikipedia page that displays the above photo from Wikicommons, but the notes are not visible because the Image Annotator gadget is not available on Wikipedia: http://en.wikipedia.org/wiki/Chord_organ

If a reader was to find the photo interesting and click on it to get an enlarged view, s/he would get to: http://en.wikipedia.org/wiki/File:Magnus_890_electric_chord_organ.JPG

If you hover your mouse on the above photo you will see that the notes do not get displayed. The reader would not even know that any notes are available. To see the notes, the reader would have to be really persistent and also lucky enough to click the correct one of several links on this page to get to the source page on the Wikimedia Commons page, where they would finally be able to see the notes. Few readers would be that persistent.

The gadget can only be installed by an admin. I have requested the admins install this but three different ones have vacillated, with one calling for some sort of vote/consensus. That's installed on my talk page.

The help file for installing the gadget is here: http://commons.wikimedia.org/wiki/Help:Gadget-ImageAnnotator/Installation

TheLarryBrown (talk) 04:43, 22 January 2010 (UTC)[reply]

Those admins are correct, Larry - You need consensus for any changes to the page involved, since it effects *everyone*. —Jeremy ^{(v^_^v Boribori!)} 04:45, 22 January 2010 (UTC)[reply]

I can see this appropriate for free content that can be built on (eg commons licensing) but I don't see this working for non-free content - if it is not as controlled as regular text edits, I could see malicious users "vandalizing" images with these tags, and possibly get us in trouble with copyright owners. --MASEM (t) 04:49, 22 January 2010 (UTC)[reply]

I have also told LarryBrown over at the Commons that there would need to be a demonstration of consensus for having it enabled here. However, Masem, the edits made through this thing are regular text edits: notes are stored on the image description page, using normal edits. Furthermore, this thing can be configured extensively. At the Commons, we have it running now allowing adding/editing/removing of image notes only for autoconfirmed users.

Also, there should be some compatibility testing with widely used other scripts, such as Popups or Twinkle, before an installtion here at the English Wikipedia was attempted. Lupo 22:40, 24 January 2010 (UTC)[reply]

My experience with this at Commons is that it's very useful for a small class of images (those that have both enough detail and enough history to warrant annotations) and that having it available on all images leads to a visible quantity of "Hi Mom!" lameness being added as annotations and sticking around. That's on Commons, where people actually watchlist image pages, as opposed to here where they mostly don't. Before we enabled annotations here, I'd want to see evidence that we can avoid that trouble - but also I'd want to see evidence that it's worth it in the first place, given that free images can already be uploaded to Commons to enable this functionality. — Gavia immer (talk) 22:58, 24 January 2010 (UTC)[reply]

The main advantage would be that annotations made at the commons would become visible here directly on image thumbnails used in articles. Lupo 08:07, 25 January 2010 (UTC)[reply]

I looked at the annotations to the organ photo. I think Wikipedia editors would object to the unsourced PoV expressed in there. However if the annotations are at Commons then there wouldn't be anything that could be done about it, short of enforcing en.wp standards there. Will Beback talk 08:48, 25 January 2010 (UTC)[reply]

Or switching off the inline display of annotations for particular images (can be done with a template at the place the file is included), or configuring the extension such that it doesn't show notes for thumbnails that come from the Commons (either not at all, or by just showing a little icon indicating the presence of notes, which would then be visible on the local image description page), or improving the annotations. The annotations on that particular image are not typical. There are many good examples of uses of the feature at the Commons. There are also many bad examples. But this type of discussion is perhaps leaving the scope of the technical VP and enters the realm of consensus building (or demonstration of non-consensus, as the case may be :-) about whether the feature might be desirable at all. Lupo 17:26, 25 January 2010 (UTC)[reply]

Category intersections

Is there a way to generate a list of all articles that fall in the categories:

Category:All unreferenced BLPs, and
Category:India (and all its subcats)

That would help the India wikiproject review the unsourced BLPs that fall under its purview (at least the ones that are sorted into a India category). Abecedare (talk) 15:07, 22 January 2010 (UTC)[reply]

Wikipedia:Category_intersection —TheDJ (talk • contribs) 15:25, 22 January 2010 (UTC)[reply]

A pity. I was hoping that someone would at least have a tool available to generate such lists on request, even if it's not a feature of mediawiki itself. Any volunteers ? Abecedare (talk) 15:29, 22 January 2010 (UTC)[reply]

You mean like WP:CATSCAN which is linked from the category intersection page? Nanonic (talk) 15:42, 22 January 2010 (UTC)[reply]

Yes. I just found out about it. Am trying that and Intersection search tool. Abecedare (talk) 15:59, 22 January 2010 (UTC)[reply]

Update for anyone interested: Intersection search tool worked for me and was used to generate this list, which is now being reviewed by members of India wikiproject. Abecedare (talk) 23:02, 22 January 2010 (UTC)[reply]

Download all Templates (Having issues)

I've spent the better part of three weeks trying to figure out, on my own, how to download the templates for Wikipedia to Upload to my own site (which has the Wikimedia engine installed) and I am at a loss. I have already asked for help at Wikipedia talk:WikiProject Templates and Wikipedia:Help desk the WikiProject Templates sent me to the Help Desk which sent me here... can someone help me out? Does anyone know how to do this? Quando Omni Flunkis Moritati - ( When all else fails, play dead ) (talk) 19:19, 22 January 2010 (UTC)[reply]

I sincerely doubt you want all templates on the English Wikipedia on your own wiki. But if so, there are database dumps available that contain pages in the Template namespace. If you just want a particular template, use Special:Export on this site and use "Special:Import" on your own site. --MZMcBride (talk) 19:39, 22 January 2010 (UTC)[reply]

I know it sounds ridiculous... but I really do. Whether or not I use them is irrelevant to me. I am putting together pages right now, and I just put together a page with references. I used the ^[1] and the Reflist template. It didn't work. There are other entries I've tried to make that I discovered were apparently handled by Templates on Wikipedia. Not being able to just use my Wiki as if it was part of Wikipedia is frustrating, especially with templates that are reliant on templates. Rather than have to research every template to see if it requires other templates, I would rather tap up to 5-6GB of space on my own server for templates alone to avoid dealing with THAT hassle. So yeah, I really would rather download ALL templates. I've tried to dumps. I cannot get a single dump to give me an actual file. And I've tried to get them from pc's at work, home, and even from a Mac laptop. Nothing. I'm so beyond frustrated... Surely someone has directions for grabbing ALL WIKIPEDIA TEMPLATES in one easy swipe. I don't have the time to study each template I want and make sure it doesn't require more templates... this is just plain easier. I know I repeated myself... I'm frustrated. HELP! Quando Omni Flunkis Moritati - ( When all else fails, play dead ) (talk) 20:12, 22 January 2010 (UTC)[reply]

I agree that the process of setting up something that functions, looks, and feels like Wikipedia is bad. I'd really like to see Wikimedia publish a version of Mediawiki that provides a relatively comprehensive set of template, extensions, and other things to provide people who want it with an experience that mimics Wikipedia. But wishing for that to happen isn't going to help you now. Of the dumps, the smallest one you could use is pages-articles, which includes all the templates, but also includes all the articles and image descriptions. It is 5.4 GB with bzip compression and would expand to somewhat more than 100 GB uncompressed. I just verified that the file is present and you should be able to downloaded it. Browsers sometimes choke on very large downloads, but if you have a Linux style server with shell access, I've found that wget from the command line seems to always work. That said, assuming you get the file you still have to either load lots of unnecessary article content (which I wouldn't recommend unless your database is backed up by a lot of RAM), or you will need to filter the dump to extract only the template pages. Overall this approach is a lot of work, and far from an easy solution. But it can be done if that's what you really want.

An alternative I've used (more or less with success) is whenever you find a template you don't have but that you want, create similar wikicode on a page in your userspace, e.g. something like User:Randomblink/dummy. After saving the page with the corresponding template calls in it, head to Special:Export. Add "User:Randomblink/dummy" (or whatever you called your page) to the big box of things to download and then make sure to check the box "include templates". When you hit download it will then include not only that page, but all templates that were needed to render it (up to 1000 per export). You then take that file over to Special:Import on your site and it will load the necessary templates for that specific application. This way you avoid having to track down the dependencies yourself. It is still likely to take many such downloads before you have copied all the templates you might want, but it is probably still less trouble than trying to copy all of Wikipedia's templates via dump. Dragons flight (talk) 21:23, 22 January 2010 (UTC)[reply]

Well, it took me a couple hours but I have collected ALL the Wikipedia Templates into an Importable XML file... ugh! NEVER want to do that again... ah well, it's importing now. Thanks anyway one and all. Reverend randomblink - Ask and you shall believe. (talk) 23:00, 22 January 2010 (UTC)[reply]

It might be worth posting that somewhere (don't know where though) so others can use it in future. OrangeDog (τ • ε) 15:16, 23 January 2010 (UTC)[reply]

Userboxtop template is breaking my user page formatting

The formatting on my user page is being broken by the 'userboxtop' template. Notice the huge gap in the section titled "Interesting Wikipedia Articles". Any suggestions on how to fix this? Jrtayloriv (talk) 22:20, 22 January 2010 (UTC)[reply]

It looks like someone fixed it for you but you made a edit that broke it again. So I added the {{FixBunching}} template, which kind of fixes it. Gary King (talk) 04:29, 23 January 2010 (UTC)[reply]

Their edit didn't fix it for me (I'm using Firefox 3.5), so it was broken for me still before I made the last edit. The editor that attempted to fix it was someone on IRC, and the change that he made fixed it for his screen, but not for me and for other people on IRC at the time. {{FixBunching}} is not doing anything for me either. I still have the gap on my screen. Thanks for trying to help. Any other suggestions? Jrtayloriv (talk) 22:11, 23 January 2010 (UTC)[reply]

It seems to have something to do with the {{top}} etc, templates for creating columns. That is the only noticable difference I can see between my page, and that of, say, User:Soxwon. Any idea why these might interfere with each other?Jrtayloriv (talk) 22:13, 23 January 2010 (UTC)[reply]

Fixed the box flow for you. {{top}} + {{middle}} + {{bottom}} creates a table. But that table uses "width: 100%", so in most browsers it flows below the right floating boxes on your user page so it can get that 100% width. The trick is to instead use "margin: 0;" in the table, then you get a box that uses all available width but doesn't flow down below the right floating boxes. So I hand coded a table for you with that setting.

--David Göthberg (talk) 03:51, 24 January 2010 (UTC)[reply]

Cross referencing two categories

Is anyone aware of a tool which lets an editor see pages with the same two categories, like, for example,Category:Unreferenced BLPs and Category:American songwriters Ikip ^{Frank Andersson (45 revisions restored):}_{an olympic medallist for f**k's sake} 22:45, 22 January 2010 (UTC)[reply]

Have you taken a look at WP:CI and Wikipedia:CatScan? – ukexpat (talk) 22:57, 22 January 2010 (UTC)[reply]

Ikip, see above. Abecedare (talk) 22:58, 22 January 2010 (UTC)[reply]

You folks are wonderful, god bless you. Ikip 23:06, 22 January 2010 (UTC)[reply]

Edit box - symbols, IPA, etc

That thingy under the edit box where you can select symbols, IPA, Greek letters, etc doesn't seem to be working for me. I clisk on the relevant bit in the drop-down menu, but the symbols or whatever don't come up. I'm using IE8 on WinXP. DuncanHill (talk) 23:01, 22 January 2010 (UTC)[reply]

Blank User:DuncanHill/monobook.js, see if that works. Then remove all gadgets. Then try a different browser. Gary King (talk) 04:24, 23 January 2010 (UTC)[reply]

But first of all, bypass your browser cache to reload the javascript that adds the "edittools". And if/when you do changes to your personal /monobook.js, then you normally need to wait one minute, then again bypass your browser cache to see the changes.

--David Göthberg (talk) 10:54, 23 January 2010 (UTC)[reply]

Bypassing the cache did nothing. DuncanHill (talk) 14:19, 23 January 2010 (UTC)[reply]

There was a thing called "wikimarks" in my monobook, which has never worked properly. Removed that and Ctrl+F5, and it let me select the symbols, but now I can't change from those. DuncanHill (talk) 14:24, 23 January 2010 (UTC)[reply]

- Then I tried blanking my monobook, I could change which symbols/alphabet but only when in the edit screen for my monobook, and whatever I chose their stuck for other pages. Then I restored everything to my monobook apart from the wikimarks thing, and now it all seems OK. Thanks everyuone for the help :)♥æЖ DuncanHill (talk) 14:38, 23 January 2010 (UTC)[reply]

What happened here was probably that DuncanHill didn't wait one minute between editing his /monobook.js and bypassing his browser cache. It often takes 30-60 seconds from the edit until the new versions of javascript and CSS pages are available at all Wikipedia servers. So reloading before that usually gives the old version. While in the edit preview of your /monobook.js the current version is loaded so you see the effect there immediately.

--David Göthberg (talk) 15:54, 23 January 2010 (UTC)[reply]

It's now stopped working again, I haven't done anything more to my monobook or gadgets since I got it working :( DuncanHill (talk) 01:36, 24 January 2010 (UTC)[reply]

No images when searching

When I search anything in wikipedia no image will show with text, this problem has been occuring for last few weeks, I have cleared my cache but still I am facing problem —Preceding unsigned comment added by 117.20.19.18 (talk) 04:42, 23 January 2010 (UTC)[reply]

Web browsers have a setting where you can choose if images should be loaded or not. You might have unset that setting. Do you see images on other web sites?

Another possibility is that you might have adblocked upload.wikimedia.org, since that is where our images are loaded from. If you have an "adblocking" plug-in in your web browser check there. Such blocking can also be done in the firewall if you are using one, so check there too.

--David Göthberg (talk) 16:02, 23 January 2010 (UTC)[reply]

Or are you talking about images in the results ? In that case, you might be looking for Google instead of our own search feature. Or you have to select one of the different searchmodes in the results page, because by default not all namespaces are searched I think. See also Wikipedia:Searching. —TheDJ (talk • contribs) 17:04, 23 January 2010 (UTC)[reply]

Unusual undo results?

A few moments ago, I clicked the "undo" button to revert revision 339578635 at Discover Card. I also manually edited the undo to restore the Sears Tower link (which had been changed to Willis Tower in revision 339011701). When I saved this edit, I noticed the bytecount inexplicably dropped from 13,223 to 11,388; I then checked the diff and saw that various citations and prose were removed through my edit. I then attempted to simply undo my edit, without making and manual changes (until I figured out what was going wrong), which did not restore the material that went missing in my first edit. I'm at a loss for figuring out what's going on here. Anybody? jæs (talk) 00:40, 24 January 2010 (UTC)[reply]

FYI I've manually rolled back to before the undos, so the article right now seems okay. That doesn't, of course, address your very valid question as to why this odd thing happened. -- Finlay McWalter • Talk 00:46, 24 January 2010 (UTC)[reply]

Thank you, Finlay! I did a couple of tests, and have narrowed down the culprit: the official Google Voice extension for Google Chrome on Mac. I can't explain why, but when that extension is enabled, it has a nasty side effect of removing anything between (and including) reference tags. The only "feature" of the extension that I can think of that would be interfering is that the Google Voice extension is designed to transform ten-digit telephone numbers on any page into clickable "dial" links. I can only guess that something about this feature either utilizes or devours reference tags? I'm really at a loss here, but, needless to say, I'm going to keep the extension disabled for now. I'll also check, momentarily, on how I can forward this issue on to Google. I apologize again for the mess. jæs (talk) 01:17, 24 January 2010 (UTC)[reply]

The first diff given by jaes above takes me to a very old revision of Hypatia of Alexandria, even though the address bar says I'm on a difff on Discovery Card. DuncanHill (talk) 01:34, 24 January 2010 (UTC)[reply]

That's how diff works – it ignores the title parameter and shows the revision from oldid parameter. The correct link is probably this one: [2]. Svick (talk) 01:44, 24 January 2010 (UTC)[reply]

I've corrected the link. I realize I'm starting to sound like a broken record, but I believe the link error had something to do with the extension, as it was altered inexplicably in a revision I made earlier to this post, before disabling the extension. I guess this is what I get for using beta software, and I think I may take more advantage of "Show changes" in the meantime. jæs (talk) 02:08, 24 January 2010 (UTC)[reply]

I would recommend that you let Google know if you haven't already done so. --Thinboy00 @082, i.e. 00:57, 25 January 2010 (UTC)[reply]

Move page using url coding

Is there a preloadtitle code in http://www.mediawiki.org/wiki/Manual:Parameters_to_index.php which allows you to move one page to another, simply by entering a url?

In the alternative:

Can I preload the title I want to move the page too?
Something like: http://en.wikipedia.org/w/index.php?title=Special:MovePage/ORIGINALARTICLE&preloadtitle=NEWARTICLE
Is there a keyboard shortcut to move down to the new page title box?
In Wikipedia:Keyboard_shortcuts , (comma) which Jumps to the edit box, does not work.

Ikip 04:24, 24 January 2010 (UTC)[reply]

You can preload a target, http://en.wikipedia.org/w/index.php?title=Special:MovePage/ABC&wpNewTitle=Thispage for example. (You can preload a reason and all the checkboxes too) If you want to actually move the page automatically you should use the api. Prodego ^talk 05:58, 24 January 2010 (UTC)[reply]

Oh remind me again what the api is. Thanks :) thanks for your response. Ikip 11:04, 24 January 2010 (UTC)[reply]

api and API documentation. —TheDJ (talk • contribs) 13:59, 24 January 2010 (UTC)[reply]

We're never going to make a URL so you can do something automatically just by following a URL. If we allowed that, it would be easy to trick a sysop into clicking a link to move Main Page to Main Page ON WHEELS!!!!. You can't do things like edit or move pages without clicking an actual button, or running a script. —Simetrical (talk • contribs) 16:15, 24 January 2010 (UTC)[reply]

Search Bar is too inconspicuous!!

My name is Christopher Kelly. I'm just a wikipedia reader, like the millions out there. And I have just ONE suggestion to make. It's about the search bar. I would prefer that Wikipedia place it more boldly in the upper center rather than inconspicuously 1/4 of the way down on the left hand side. Is it just me, or do others agree?

1/24/2010 —Preceding unsigned comment added by Kellyc01 (talk • contribs) 07:03, 24 January 2010 (UTC)[reply]

well, personally I happen to like it where it is. but if you click the Search button while the search box is empty you'll get a much bigger search field.. You might try some of the other wikipedia skins, as well; they have different layouts for the page content. see wp:skin to learn how to do that. --Ludwigs2 07:55, 24 January 2010 (UTC)[reply]

In the beta version the seaarch bar appears at the top, new users expect to find it there like in other sites. Sole Soul (talk) 08:38, 24 January 2010 (UTC)[reply]

Not attempting to complain about the style that's obviously existed as-is for this long for a reason, but this does kind of seem like a common sense sort of change for exactly the given reasons. I'd entirely forgotten that it's a beta thing since I can't even remember the box over on the left. One minor consolation-- recent versions of Firefox have this (English) Wikipedia as one of the pre-set "search engine options" in the top-right. ♪ daTheisen (talk) 09:07, 24 January 2010 (UTC)[reply]

The new Beta (see link at the top of your window), has the search bar at the top right, mainly for this reason. But most of all http://www.wikipedia.org if you want a searchfield, or just use google of course. —TheDJ (talk • contribs) 14:04, 24 January 2010 (UTC)[reply]

Template Tidy? like HTML tidy?

Is there by any chance anything like HTML Tidy for templates? If you are not familiar with HTML tidy, and want to see what it does, here is an online tool for HTML tidy [3]. Is there any tool that helps to make template logic more visually intuitive - and cleans it up - checks for missing braces, etc? Thanks. stmrlbs|talk 22:35, 24 January 2010 (UTC)[reply]

wikEd has several features that help when editing templates.

And the bracket matcher user script is also useful. Its description on Wikipedia:WikiProject User scripts/Scripts says this:

Adds a 'parse' link that shows a copy of the edit box with matched curly braces highlighted, for help in tracing complex nested expressions.

It works fairly well. Here's the code to put in your personal /monobook.js to load it:

/* Colour matching brackets in a copy of the edit box.
   [[User:ais523/bracketmatch.js]]   */
importScript("User:ais523/bracketmatch.js");

As usual, after editing your /monobook.js you need to wait one minute, then bypass your browser cache, to see the change.

--David Göthberg (talk) 01:05, 25 January 2010 (UTC)[reply]

Thanks! This is a big help when trying to figure out some of these templates - and when checking my own changes. stmrlbs|talk 02:20, 25 January 2010 (UTC)[reply]

Printable Version suggestions

I have two suggestions for the printable version.

The first is with references/notes. Could we remove the "^" and a, b, c...etc from the printable version? You can't click on the ^ or a,b,c,etc in the printable version. However, I would still like for there to be a counter of how many times that reference was used...maybe something like (#) in small font.

The second is that I'd like to request that you add a small icon next to the printable version so that more people know that there is a printer friendly page.Smallman12q (talk) 23:35, 24 January 2010 (UTC)[reply]

I also would like to ask that you put the type of time such as UTC, GMT, EST, etc on the printable version, and on the bottom of the website where it says "This page was last modified on 24 January 2010 at 23:25".Smallman12q (talk) 23:41, 24 January 2010 (UTC)[reply]

Your suggestion of removing the ^caret in printed footnotes is, I think, good. The caret is a screen navigation thing (although we disable that for refs that are used more than once). The print code is very good about removing other navigation; this seems to me to be an oversight. But Mediawiki doesn't generate an HTML object to wrap just the caret, so there's nothing for the stylesheet to disable for the print view. So doing this would need a change-request on the software. -- Finlay McWalter • Talk 23:49, 24 January 2010 (UTC)[reply]

"printable version" isn't very important, and I don't think we need to emphasise it. It's there mostly for people with rubbishy old browsers that can't handle the CSS stuff; even IE6 does the print media stylesheet stuff fine. -- Finlay McWalter • Talk 23:55, 24 January 2010 (UTC)[reply]

The printable version is basically the same as the normal version, but with the print stylesheet activated for viewing. Mr.Z-man 00:11, 25 January 2010 (UTC)[reply]

I was surprised to read Finlay McWalter's last point, which is confirmed by Help:Printable and my own experiments with Firefox/Firebug. I had always thought (well, assumed) that the "Printable version" link pointed to a different version of the page with all bitmap images at original resolution, and vector images rasterized at 1200*1200 or higher. It seems I was naïve: despite all the advice to upload high resolution images and use vector graphics for tables and diagrams, this seems to make no difference for printing. So presumably if you are donating images you own to Wikipedia, there's no reason to upload anything better than screen resolution. Is that correct? - Pointillist (talk) 00:30, 25 January 2010 (UTC)[reply]

Sure, you download the images separately and do your own layouting. —TheDJ (talk • contribs) 00:35, 25 January 2010 (UTC)[reply]

Of course, I know that if I want to make money out of WP content I can write a script to import it into my CMS using the original SVGs, JPGs and PNGs, and then pump out my own InDesign, Flash, Silverlight etc. I was asking the opposite question: if I own images that I'm happy to contribute to Wikipedia, why should I upload a high resolution version that Wikipedia won't use? - Pointillist (talk) 00:42, 25 January 2010 (UTC)[reply]

Why do you assume people only print Wikipedia articles ? I click on thumbnails and download images all the time. —TheDJ (talk • contribs) 00:50, 25 January 2010 (UTC)[reply]

Back to the point

Remove ^ and abc.
This is currently not possible, because they are hard to identify in the content of the ref. You cannot CSS style them atm. We would have to change MediaWiki:Cite_references_link_many and MediaWiki:Cite_references_link_one, to identify this elements (making pages bigger and more complex once more).
Count references
The printable version cannot do things that the normal webpage does not already do. So counting them in any other way then a, b, c. just for print, is not possible.
Add an icon
We could add an icon, but it's not needed. People should just choose print from their menu. Only IE 5.5 really needs the printable stylesheet, and IE 5.5 support is being deprecated so we don't really care.
Opened bugzilla:22256 on this issue.
Add UTC
I'll open a bugreport on that one. bugzilla:22257

Hope that answers your questions. —TheDJ (talk • contribs) 00:57, 25 January 2010 (UTC)[reply]

Ye, it does. Thanks for opening the bug reports. I'd ask for a printer rendering solution, but the server/coding cost just wouldn't be justified. On a side note, I did find a bug with the new secure linker...see Wikipedia:VPT#Interwiki.2Finterlanguage_links_not_changing_to_secure.Smallman12q (talk) 01:48, 25 January 2010 (UTC)[reply]

Well we have the "Download as PDF" option, which basically is just that. But that can't help folks that simply use "Print", which is rather common. So I don't think that at this time those resources should be directed at something that will basically be of little use to many people, for just a few corner issues. —TheDJ (talk • contribs) 01:58, 25 January 2010 (UTC)[reply]

Back to the point (II)

Why do you assume the "Printable version" link should be limited by CSS? It could point to a printer-oriented page rendering system using different logic to handle citations and embed high resolution images. After all, we already render thumbnails at user-preferred sizes. Given that the current printable version offers no benefits (except for old browsers) Featured picture criterion #2 ("is of sufficiently high resolution to allow quality print reproduction") is misleading. Contributors should be made aware that screen-resolution images are entirely sufficient for Wikipedia's purposes and they don't need to GFDL/CC3 high resolution versions of their IP. - Pointillist (talk) 01:18, 25 January 2010 (UTC)[reply]

I had always taken that to mean that it was for people who wanted to print just the image. Given how expensive ink can be, I'd be somewhat annoyed by larger pictures in the printable version. IMO the printable version should stick as closely to the web layout as possible, minus the stuff around the edges (sidebar, tabs, sitenotice, etc.). Mr.Z-man 01:26, 25 January 2010 (UTC)[reply]

And I think that the relatively few people that have actually READ the featured picture criteria, almost all will agree with your interpretation Mr.Z-man. —TheDJ (talk • contribs) 01:43, 25 January 2010 (UTC)[reply]

Perhaps I'm not explaining this very well. When a reader clicks the "Printable version" link of an article (e.g. Helix-turn-helix), an HTML page is prepared and downloaded to the browser for printing. Currently the page embeds screen-resolution images (e.g. src="200px-Lambda_repressor_1LMB.png" class="thumbimage" height="294" width="200"). Instead, the page could embed the original image (e.g. src="http://upload.wikimedia.org/wikipedia/commons/8/8f/Lambda_repressor_1LMB.png" class="thumbimage" height="294" width="200"). Either way, the image will be scaled to the same height and width, the layout doesn't change and no more ink is used. But... using the original image, which contains more data, will show more detail when it is rendered to a printer. This is a simple change ...all that is needed is to use the filename of the original bitmap (or best rastered SVG) image rather than the screen-scaled version. If we aren't prepared to do this, why should contributors upload print-resolution images? - Pointillist (talk) 02:45, 25 January 2010 (UTC)[reply]

Well, obviously I wasn't explaining this at all well, as the functionality I was looking for is already part of "Download as PDF" (as TheDJ says above). I've updated the sample image accordingly. I still wonder why the "Printable version" link doesn't use this approach, though.... - Pointillist (talk) 03:07, 25 January 2010 (UTC)[reply]

If the printable version used the full original images, then users on connections slower than DSL would not be able to print Wikipedia pages...

But there are a number of good reasons to upload large images:

The images should preferably be at least twice the size of what is used in the articles, so the resampling function have good data to work with.
We are in it for the long run. Wikipedia, or at least some of its data, will be used far into the future. Over time people use computers with larger screens and higher resolutions. So some years from now we need larger images than we use now. When I started using computers 320x200px was a common screen resolution, now 1600x1200px is used by some users.
As have been mentioned above: Many of us click on the images to go to the image page to see fullscreen versions of the images, and sometimes to download them. I am currently using one of the images from Götheborg (ship) as my desktop background. And images from Wikipedia can and are reused in other places. For instance, two of the crypto diagrams I have created have been used in a printed book about the security system of one of the biggest US banks. They sent me a copy, it looks very nice in my bookshelf. :))

--David Göthberg (talk) 17:52, 25 January 2010 (UTC)[reply]

Thank you David, those are all very good points - especially the sampling issue, which I'd forgotten to consider. All the best - Pointillist (talk) 18:21, 25 January 2010 (UTC)[reply]

missing references

Hi! I've been working on the Linda McMahon page recently, and the page is up to about 70 references right now. I'm not sure why, but due to some technical problem, the only references that show are up to number 31 and that's it. The other references are still there, but when you click on them, they don't lead to anything in the references section. I use the <ref></ref> tags, and the references section is marked with {{reflist|2}}.

I appreciate your help. Thanks! --Screwball23 talk 03:11, 25 January 2010 (UTC)[reply]

Found the problem; it was in ref 27, where a bad template was screwing up the next 30 or so references. --Golbez (talk) 03:35, 25 January 2010 (UTC)[reply]

I've put a nowiki tag around some of the text in your message, so the raw text is shown, rather than an actual reflist template or ref tags. Graham87 04:41, 25 January 2010 (UTC)[reply]

Annoying, constantly present invisible div.

There seems to be an annoying, ever-present div added via Javascript to the page, preventing me from right-clicking properly, as I have discovered with Safari's Inspector. It contains an empty iframe, and this image: . It is normally hidden using visibility:hidden, but that doesn't actually hide it, I think display:none should have been used instead?

What is it, anyway? --(ƒî)» 04:34, 25 January 2010 (UTC)[reply]

It is WikiMiniAtlas, and you are experiencing a bug in Safari, which I have recently reported. https://bugs.webkit.org/show_bug.cgi?id=34042 —TheDJ (talk • contribs) 11:30, 25 January 2010 (UTC)[reply]

I have notified the author of WMA of the issue. —TheDJ (talk • contribs) 11:39, 25 January 2010 (UTC)[reply]

Thank you for mentioning it here, and thanks to TheDJ for the additional info! I'm glad I'm not going mad, and that it's not just me. I was starting to think all sorts of worrying thoughts about dodgy javascript injection or other malicious things, and it's hard to track down where it's coming from... gothick (talk) 13:14, 25 January 2010 (UTC)[reply]

Thanks for notifying me. I guess it won't hurt to make it both visibility:hidden and display:none. --Dschwen 15:42, 25 January 2010 (UTC)[reply]

Ok, changed the code. Pleas clear cache and try again. --Dschwen 15:46, 25 January 2010 (UTC)[reply]

Page Statistics Void Since Jan. 23, 2010

Has anyone else out there noticed that hits have not been counted on articles since the 23rd? I visited many random pages from two different IP's and page statistics is showing zero hits. Anyone know what this is about? Thanks in advance! :) --Neon Sky (talk) 19:43, 25 January 2010 (UTC)[reply]

^ sample

[1] sample

[1]