Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Noosphere (talk | contribs) at 16:58, 9 February 2012 (→‎Transparent PNGs used for math formulas unreadable on black background). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (How to report a bug). Bugs with security implications should be reported to security@wikimedia.org.

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.

« Archives, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212


Templates with bugs in coordinates

  • Coordinates in {{Infobox_ancient site}} don't show up at the top of the article as they do in {{Infobox Historic Site}}.. Try it at Byllis.
  • {{Infobox settlement}} falsifies coordinates when given like longitude=49.12345. Compare source and geohack-link in Butrint. -- Kr51-2 (talk) 10:48, 28 January 2012 (UTC)[reply]
  1. {{Infobox ancient site}} has parameters for latitude, longitude and coordinates. Don't use latitude or longitude; use coordinates and the {{coord}} template with desired display options.
  2. Butrint has decimal coordinates in the infobox but then it has {{Coord|39|45|N|20|01|E|type:city}} near the bottom of the markup, which renders at the top of the page. ---— Gadget850 (Ed) talk 12:13, 28 January 2012 (UTC)[reply]
In Byllis, the problem with using |coordinates= instead of |latitude=|longitude= is that the pushpin map only works if |latitude=|longitude= are given. {{Infobox ancient site}} will display coordinates upper right when |latitude=|longitude= are given, provided that |coordinates_display=inline,title is also given.
The problem at Butrint is that {{infobox settlement}} doesn't recognise |latitude=|longitude= - you need to use |latd=|longd= instead, and also give it |coordinates_display=inline,title. The {{coord}} near the bottom does need to be removed though, if not the page will show up in Wikipedia:Database reports/Articles containing overlapping coordinates when that gets rebuilt on 2 February. --Redrose64 (talk) 19:43, 28 January 2012 (UTC)[reply]
Thanks for the details, though that's not much fun for a casual user... -- Kr51-2 (talk) 22:53, 3 February 2012 (UTC)[reply]
I have already fixed them, see here and here. --Redrose64 (talk) 13:02, 4 February 2012 (UTC)[reply]

Persistent Talk Page Links

A common issue I've found is, someone will post a link to a talk page (or a village pump discussion or whichever), and then you click on it and get the most current version of the talk page with the content of that link archived. From that point you could try searching for that page, but finding an archived copy of a talk page based on a broken link can be painful. My proposal - I'm not sure. I mainly just wanted to say this is an issue in Wikipedia.

One possible solution, that would need fleshing out... Maybe next to section headers on talk pages/village pump pages there could be a link that says "permalink"? Jztinfinity (talk) 18:09, 28 January 2012 (UTC)[reply]

I've been moaning and groaning for years about broken/stale links to past discussions. I usually just end up manually fixing the links myself. -- œ 14:38, 29 January 2012 (UTC)[reply]
This is something that the archiving bots ought to fix at archiving time. Josh Parris 14:41, 29 January 2012 (UTC)[reply]
User:ClueBot III does. Anomie 17:32, 29 January 2012 (UTC)[reply]
Example. --Redrose64 (talk) 19:52, 30 January 2012 (UTC)[reply]
So ClueBot III changes links to archived discussion sections, but what about pages on which ClueBot III does not run, or pages in userspace which users do not wish to be changed? And what about external links (or even links kept personally by users outside of Wikipedia, say, copy/pasted somewhere)? The solution is not to change references to dead section links to point to different targets; one solution would be to design the software such that links to sections of discussion pages automatically redirect to archived copies. —danhash (talk) 14:55, 2 February 2012 (UTC)[reply]
You'll love LiquidThreads, if they ever get it working and force it on us. Anomie 20:53, 2 February 2012 (UTC)[reply]
Any link fixing bot cannot solve the problem of link rot because there are also links in edit summaries, such as in [1]. Let us wait for LiquidTheads to come? Incnis Mrsi (talk) 19:17, 8 February 2012 (UTC)[reply]

Broken bullet points

I don't know if this is a new issue, but I've never encountered it before until twice recently: Bullet points and numbered lists failing to wrap around floating images (example) breaking away from their sentences. (I can't remember the other example!) There's a similar, not-so-critical problem with indents not working when placed to the right of an image. Can this be fixed with code or is it a software issue? nagualdesign (talk) 07:56, 29 January 2012 (UTC)[reply]

What browser/OS are you using? Your example looks OK to me using IE8 on Windows 7 (but I think I remember seeing the problem you have described using IE9 on Windows 7). DH85868993 (talk) 08:11, 29 January 2012 (UTC)[reply]
Yes I've seen it with Win7 & IE9. Roger (talk) 08:20, 29 January 2012 (UTC)[reply]
Win7/IE9, yes. I found another example, too. Edit: On my computer the bullet points float above the image on the far left. nagualdesign (talk) 08:32, 29 January 2012 (UTC)[reply]
I've rearranged the images, adding {{-}} to prevent text-wrapping. Goodvac (talk) 08:25, 29 January 2012 (UTC)[reply]
Thank you but that was not what I wanted, and moving the panorama down was unnecessary either way - it's the smaller image causing the interference. nagualdesign (talk) 08:32, 29 January 2012 (UTC)[reply]
I moved the panorama because it just looked odd at the top of the article. Feel free to move it back up if you so wish, but {{-}} is the key to fixing the text-wrapping. Goodvac (talk) 08:39, 29 January 2012 (UTC)[reply]
It's a small bug in the CSS implementation. The bullets/numbers are placed outside the list item content (list-style-position: outside;). This is fine when there is nothing in front of them, but interferes with floating content. What basically happens is that the list margins are ignored. Using inside would fix lists beside floating content, but will break list indenting. Edokter (talk) — 11:17, 29 January 2012 (UTC)[reply]
Examples in IE today 29 Jan 2012
Has the bug always been there? The layout isn't ideal in IE8 or IE6 either (see screenshot). I don't recall seeing this before. - Pointillist (talk) 11:40, 29 January 2012 (UTC)[reply]
Yes, it has always been there. Edokter (talk) — 11:55, 29 January 2012 (UTC)[reply]
It's been there as long as I can remember (May 2009). I try to avoid placing left-aligned images low down in a section, in case they protrude into the next. Right-aligned images protruding into the next section are less of a problem. --Redrose64 (talk) 17:12, 29 January 2012 (UTC)[reply]
Thank you to those who have taken the time to follow this issue up. Whilst it is arguably very minor it's certainly worth adding to the To do list for the programmers. Internet Explorer with all of its quirks is the bugbear of many a website designer, but design for it we must. 'Favouring the other leg', so to speak, is not technically a solution. nagualdesign (talk) 11:20, 30 January 2012 (UTC)[reply]
It's not just IE; all browsers exhebit this behaviour. And as I explained above, there is no solution. It's basically a design consideration. Edokter (talk) — 11:27, 30 January 2012 (UTC)[reply]
Would adjusting the right-hand margin of left-floated images to a more happy medium help? - Jarry1250 [Deliberation needed] 14:08, 30 January 2012 (UTC)[reply]
That may cause excessive space between the image and normal text. Edokter (talk) — 14:41, 30 January 2012 (UTC)[reply]
AFAICS it is just IE 9 (the top screenshot in the image above) where the list numbers and bullets are outside the layout box. Happens in both 32-bit and 64-bit IE9 on 64-bit Windows 7, using Vector, Monobook and Simple skins. This is a distinct bug using IE9/Win7. It doesn't happen in Chrome, FF or older IE: they just exhibit the known list-style-position: outside; issue described by Edokter. - Pointillist (talk) 10:10, 6 February 2012 (UTC)[reply]
Ah, didn't catch that. I'm curious to see what would happen with list-style-position: inside; in IE9 (which I don't have). In any case, I'm afraid we still would not be able to fix it. Best practice is to avoid lists next to left-floating elements. Edokter (talk) — 11:53, 6 February 2012 (UTC)[reply]

Nesting templates

I found general discussion when searching the archives, but nothing specific to my question. This edit to Template:Copied multi/Copied effectively unsubsts {{diff}}, {{history}}, and {{no redirect}}. The nested templates include extra logic and redundant plainlinks (they should be enclosed within {{Copied multi}}, which uses {{tmbox}}). Using nested templates benefits from any improvements or updates to them, but I think that changing the basic index.php syntax is unlikely. Any input on whether I should revert the unsubsts? Thanks. Flatscan (talk) 05:32, 30 January 2012 (UTC)[reply]

My personal opinion is that basic templates should not utilize other basic templates if not necessary. It adds to the complexity of the template and adds unneeded transclusion depth which may cause problems. Since those templates add no functionality (and basically make them unsubstable), I think reverting those changes is the best option. Edokter (talk) — 11:25, 30 January 2012 (UTC)[reply]
Thanks for your reply. I have reverted the changes. Flatscan (talk) 05:07, 3 February 2012 (UTC)[reply]

Remove a category which seems to be included using a #babel tag

Please help me remove User:Altaïr from the speedy deleted Category:User simple-N. As far as I can tell, the category is included using a {{#babel}} at the beginning of the page. עוד מישהו Od Mishehu 06:25, 31 January 2012 (UTC)[reply]

Why? The babel system categorises user pages by the languages that the user understands, and by the level of understanding. If you are looking for a translator, it's better to look for somebody in the lang-N category than in the lang-1 category. --Redrose64 (talk) 11:05, 31 January 2012 (UTC)[reply]
Not only that, but the babel system automatically re-created the category too. Unfortunately, since r105540 it appears to be impossible to override this (or any of the "default" babel templates or categories). Anomie 12:29, 31 January 2012 (UTC)[reply]
The reason is CSD G4, per Wikipedia:Categories for discussion/User/Archive/February 2008#Category:User simple and all subcategories. עוד מישהו Od Mishehu 07:49, 5 February 2012 (UTC)[reply]
G4 doesn't mean that the page must be deleted on sight for evermore. It allows change of circumstances, under which G4 will no longer apply; and the addition of the babel system to the various Wikiimedia projects (inc. English Wikipedia) in late September 2011 (see meta:Babel extension#Deployment) constitutes significantly changed circumstances.
Previous to this, the user language cats (such as Category:User simple-N) were only added to user pages by use of userbox templates, each of which could be customisable individually; but now the #babel: parser function (e.g. {{#babel:simple-N}}) will add the standard categories. I rather suspect that you'll need to get MediaWiki changed to permit exceptions. --Redrose64 (talk) 15:23, 5 February 2012 (UTC)[reply]

Combination of Template:Dts and Template:Birth date and age2

Hello Pump.

Is there a template that is the combination of Template:Dts and Template:Birth date and age2?

Background: I'd like to be able to create wikitables that are sortable and present the athlete's age at a certain point, for instance at the beginning of a tournament. The Dts is sortable, but is not able to calculate and present age. The Bda2 calculates age and presents birth date and age, but is not sortable (well, it's sortable, but you know what I mean).

In other words, I'm looking for a template that essentially achieves this:

{{sort|1991-01-02|2 January 1991 (age 21)}} or {{sort|1991-01-02|January 2, 1991 (age 21)}} (depending on date format) from parameters date-of-birth, date-starting-point and date-format.

HandsomeFella (talk) 18:04, 31 January 2012 (UTC)[reply]

Would nobody help me with this? HandsomeFella (talk) 10:46, 3 February 2012 (UTC)[reply]
I don't know of any way to get it to calculate and sort at the same time. You'll probably have to go with the code you used inside the nowiki tags. Nyttend (talk) 03:28, 4 February 2012 (UTC)[reply]

proposals to improve assessment of reliability of wikipedia articles- making a quantitative and visible index

Currently, assessing the reliability of a given wikipedia article is difficult.

Problems: 1.Some heuristic methods are intuitively developed by people to make this assessment (length of article, number/quality of references, etc..). However, this heuristic is not made by most people, who often remain confused on this matter. This erodes the overall credibility of the encyclopedia.

2. Articles are sometimes flagged, or put in some categories, (and on the other hand, very few articles are classified as "Featured/good articles). But it must be recognized that this organization is very rudimentary. More efficient tools are needed and possible.

Proposals:

1. build a quantitative index of assessment of the probable "reliability" of an article. This index includes: length of article, number/quality of references, people's judgment about the reliability, etc..

2. Improve visibility of this index: adopt a color code. Instead of a uniformly white article, color each article and/or each paragraph, and/or each sentence with (the "whiter", the more "possibly reliable" the information is). Page ratings are not widely used nor visible.

It will also give incentives to good participation, as their changes will be more visible. — Preceding unsigned comment added by Mokotillon (talkcontribs) 21:45, 31 January 2012 (UTC)[reply]

This sounds like WikiTrust. Graham87 02:45, 1 February 2012 (UTC)[reply]
thank you. i feel like i reinvented the wheelMokotillon (talk) 20:21, 5 February 2012 (UTC)[reply]

Interwiki links

{{Resolved|Should be fixed now. --slakrtalk / 00:35, 1 February 2012 (UTC)}}[reply]

Is it just me or has something gone really weird with interwiki links? Jenks24 (talk) 00:16, 1 February 2012 (UTC)[reply]

Not just you, I see it too. It reads de:Players Tour Championship in the "Languages" panel instead of "German" and the turn red if I purge the cache. Armbrust, B.Ed. Let's talkabout my edits? 00:19, 1 February 2012 (UTC)[reply]
Same here. Also, newly added iw links will appear as redlinks at the bottom of the page. Lithoderm 00:19, 1 February 2012 (UTC)[reply]
All interwiki links are acting up, not just new ones. Jeancey (talk) 00:21, 1 February 2012 (UTC)[reply]
Not just you. Interwiki links are shown just below TOC; and there is no interwikis at usual place (at some moment there was a list at usual place with text "lang_code:name_of_article" instead of usual "language name"). Every interwiki link just goes to the current wikipedia, like "en.wikipedia.org/w/index.php?title=Fi:Wikipedia:Kahvihuone_(tekniikka)&action=edit&redlink=1". Seems to be bug of mediawiki. `a5b (talk) 00:22, 1 February 2012 (UTC)[reply]
This is wikipedia-wide, not just en. Choyoołʼįįhí:Seb az86556 > haneʼ 00:26, 1 February 2012 (UTC)[reply]
From Server admin log: "February 1. 00:05 logmsgbot: reedy synchronized php/cache/interwiki-pr.cdb 'Updating interwiki cache'". — AlexSm 00:27, 1 February 2012 (UTC)[reply]
Meaning? Choyoołʼįįhí:Seb az86556 > haneʼ 00:28, 1 February 2012 (UTC)[reply]
According to meta:Wikimedia Forum#interwiki's, "Interwiki map was updated very recently, techs are working to see what has gone wrong." Jenks24 (talk) 00:35, 1 February 2012 (UTC)[reply]
After third update "00:33 logmsgbot: reedy synchronized php/cache/interwiki-pr.cdb 'Updating interwiki cache' " all works again. `a5b (talk) 00:36, 1 February 2012 (UTC)[reply]
I can confirm this, it works again now. --Matthiaspaul (talk) 00:41, 1 February 2012 (UTC)[reply]

BTW I would say, this is a problem with interlanguage links, as commons: and wikt: work. Armbrust, B.Ed. Let's talkabout my edits? 00:32, 1 February 2012 (UTC)[reply]

Yeah, it's fixed. --Anime Addict AA (talk) 00:40, 1 February 2012 (UTC)[reply]

I also confirm, that it works. Armbrust, B.Ed. Let's talkabout my edits? 00:44, 1 February 2012 (UTC)[reply]
Doesn't seem to be working for me - edited Bungotakada and the interwiki links still seem to be displaying incorrectly, Thanks, Maculosae tegmine lyncis (talk) 00:50, 1 February 2012 (UTC)[reply]
I purged the page and now it seems to display correctly. Maybe it is an issue when the last edit was done during the time the cache was still updating? --FordPrefect42 (talk) 00:57, 1 February 2012 (UTC)[reply]
I think the cache is still catching up. Template:Dts exhibited the same problem until a minute ago, when I went for the "[purge]" link top right of the green documentation box: that fixed it. --Redrose64 (talk) 17:38, 1 February 2012 (UTC)[reply]

Screwed up again. How many more updates will there be? Choyoołʼįįhí:Seb az86556 > haneʼ 19:48, 1 February 2012 (UTC)[reply]

I don't know if this helps in the analysis. But both Reliability engineering‎ and Category:Reliability engineering showed this behaviour in previous revision when a not existing category was added (just before the interwikis). After reverting, the problem disappeared. -- SchreyP (messages) 20:18, 1 February 2012 (UTC)[reply]

Interwiki on United States Department of Commerce

For some reason, the interwiki is showing up as in-page redlinks on United States Department of Commerce; I'm sure there's some incredibly simple explanation for this, but I can't figure out how to fix it. Anybody more technically minded care to take a look? -- Khazar (talk) 00:29, 1 February 2012 (UTC)[reply]

see above :) Choyoołʼįįhí:Seb az86556 > haneʼ 00:30, 1 February 2012 (UTC)[reply]
Still fucked. Thanks. Lugnuts (talk) 19:35, 1 February 2012 (UTC)[reply]

Cats too

Fucked for me, too - on cats, inc CAT:AFC and C:SD. All interwikis are showing as red-links within the body, instead of in the language bar.  Chzz  ►  19:37, 1 February 2012 (UTC)[reply]

MEOW? Ceiling Cat (talk) 19:44, 1 February 2012 (UTC)[reply]

Fixed?

It looks like it's fixed, at least for now. JIP | Talk 20:08, 1 February 2012 (UTC)[reply]

not quite

There must still be a glitch somewhere, in Languages. Have a look at this → Frederic Leighton: all languages now appear at bottom of article, in red but live - they have disappeared from left column. And when I navigate some other pages, on some they show at left (as usual) but with country initials in front (for instance nl:xxxx, fr:xxxxx, etc.). If I return to that page, they have gone back to normal!--Smintheus Fellin (talk) 20:19, 1 February 2012 (UTC)[reply]

It looks OK to me. Perhaps the bug was fixed in the meantime? I hadn't heard of Frederic Leighton before, and hadn't visited the article, so I know it's not because of caching. JIP | Talk 20:25, 1 February 2012 (UTC)[reply]
For me the problem persists when I am/was logged in and look at the pages, which I just opened for edition. 93.72.141.128 (talk) 20:48, 1 February 2012 (UTC)[reply]
Yep, gone now, JIP, thanks for the info.--Smintheus Fellin (talk) 21:18, 1 February 2012 (UTC)[reply]
Category:Wikipedia scripts still had the problem until I purged it a few minutes ago. Will all affected pages automatically be fixed by a job queue, or can they linger indefinitely until the page is rerendered for other reasons? PrimeHunter (talk) 22:27, 2 February 2012 (UTC)[reply]
Wikipedia:Snowball clause. --Anime Addict AA (talk) 23:59, 2 February 2012 (UTC)[reply]
Hm, I purged and it displays. --Anime Addict AA (talk) 00:00, 3 February 2012 (UTC)[reply]

Rika

Not fixed yet. Carlossuarez46 (talk) 19:56, 1 February 2012 (UTC)[reply]

Try this. JIP | Talk 21:00, 1 February 2012 (UTC)[reply]

Creating an interwiki link as an article

Is this issue potentially related to the thread about "tr:In Bruges" at WP:ANI? A user created an article whose title included the prefix for the Turkish Wikipedia, and all of the admins who commented in an ANI thread about it noted that they couldn't modify, delete, or even nuke it. It's since been deleted, but I'm not sure how, since it doesn't have a log entry. Nyttend (talk) 06:44, 2 February 2012 (UTC)[reply]

Yes. The bugzilla I entered for the tr: issue was closed as a duplicate of the other iw issue(s). Also, using my non-admin account I was unable to reproduce the tr: issue once the other iw issues were fixed. 28bytes (talk) 06:47, 2 February 2012 (UTC)[reply]
You can see the deletion in Amalthea's log. 28bytes (talk) 06:50, 2 February 2012 (UTC)[reply]

Problem with Interwiki links on Neon tetra

What's with the interwiki links on Neon tetra? They just appear as redlinks in the main body of the text, but at a glance there's nothing wrong with the markup. Lankiveil (speak to me) 06:47, 5 February 2012 (UTC).[reply]

There was a cockup in the database, see recent discussions. The problem is likely apparent or residual, try to purge your cache. Incnis Mrsi (talk) 07:29, 5 February 2012 (UTC)[reply]
Don't purge *your* cache; purge *the server's* cache, as described in the link above. Graham87 08:42, 5 February 2012 (UTC)[reply]
Ah, purging worked, thankyou. It was the only page I saw that was affected so I assumed it was a template screwup or something. Lankiveil (speak to me) 09:26, 5 February 2012 (UTC).[reply]

Killer whale: what has gone wrong with the interwikis on this page?

--eugrus (talk) 13:21, 5 February 2012 (UTC)[reply]

ok. It's a known issue. I see. --eugrus (talk) 13:23, 5 February 2012 (UTC)[reply]
Purging fixed it here too. Ucucha (talk) 13:39, 5 February 2012 (UTC)[reply]

User talk page

Please suggest how long a question/answer in one's user talk page should be kept before deletion? --Robert Fraser (talk) 06:54, 2 February 2012 (UTC)[reply]

How about moving stuff to an archive after, say, 31 days? This can happen automatically if you adapt the code from here. -- John of Reading (talk) 08:28, 2 February 2012 (UTC)[reply]
It varies widely by user - I archive mine in groups of 20 sections, some just archive it when the page seems to be too long, etc. --Philosopher Let us reason together. 11:46, 2 February 2012 (UTC)[reply]
See also Help:Archiving a talk page. If there is low activity like your talk page then many users go by size instead of age. It's still so small that there is no need for archiving but you are free to do so. By the way, many users copy barnstars to their user page. PrimeHunter (talk) 14:13, 2 February 2012 (UTC)[reply]

template assistance needed

I'd be grateful for some help with these template-related tasks, please, which are beyond my skills, (and require admin privileges):

{{Infobox settlement}} has code which could be adapted for the first of those. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:34, 2 February 2012 (UTC)[reply]

Anyone? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:28, 5 February 2012 (UTC)[reply]

The Flowers of War article's rating box

This article has a faulty rating box where it says "no ratings" in places where there have been substantial amounts of ratings. Can someone fix this, please? AnonymousAnimus (talk) 21:03, 2 February 2012 (UTC)[reply]

Hmm, I can see the ratings in my browser:
Current average ratings.
  • Trustworthy, 5.0, 51 ratings
  • Objective, 5.0, 46 ratings
  • Complete, 5.0, 50 ratings
  • Well-written, 5.0, 55 ratings
They are all suspiciously high, maybe there is something wrong with the rating system at the moment? jonkerz ♠talk 23:25, 2 February 2012 (UTC)[reply]
Probably someone trying to game the system; although what you win is not clear to me here. I've seen this happen to AfD candidates. Josh Parris 07:46, 4 February 2012 (UTC)[reply]

Template magic for link text

Is there any template magic, similar to {{urlencode}} which will turn Wikimarkup in a parameter value into text. For instance for [[wibble]] it would return a value of "wibble" and for [[foo|bar]] it would return "bar"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:47, 2 February 2012 (UTC)[reply]

I don't think so, but without knowing exactly what you're trying to do, I'm not sure. Edokter (talk) — 00:14, 3 February 2012 (UTC)[reply]
I want to use the text value as part of an external URL. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:37, 3 February 2012 (UTC)[reply]
Not possible I'm afraid. Edokter (talk) — 13:00, 3 February 2012 (UTC)[reply]

:-( How are magic words like {{urlencode}} created - do I need to raise a MediaWiki ticket? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:22, 3 February 2012 (UTC)[reply]

Exactly. And then you need to wait for someone inclined to writing it of course —TheDJ (talkcontribs) 14:11, 5 February 2012 (UTC)[reply]
Thank you. Bug raised: https://bugzilla.wikimedia.org/show_bug.cgi?id=34215 Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:34, 5 February 2012 (UTC)[reply]

New file upload wizard proposal

I believe we need a better file uploading mechanism, especially for new users. I have written a draft new upload wizard, implemented in Javascript. It is currently at User:Future Perfect at Sunrise/Upload forms draft. To test it, you will need to activate the Javascript, by adding

importScript('User:Future Perfect at Sunrise/uploadscript.js'); [update see below]

to your personal .js page (Special:Mypage/vector.js).

The idea is to have a wizard-style dialogue that guides the user through all the necessary decisions about copyright, sourcing and fair-use issues. For a number of reasons, I came to the conclusion that the new Commons upload wizard would not be easy to adapt to our needs on en-wiki, so I felt the Javascript solution might be a good alternative.

This is obviously still in alpha stage (but the basic functionality ought to be working). If all goes well and this thing can be brought into a stable working condition, I reckon it could be deployed as a Gadget, or through site-wide js.

All help in further developing, bugfixing, testing and feedback will be greatly appreciated.

Fut.Perf. 01:27, 3 February 2012 (UTC)[reply]

Just so long as there is an option to disable it or use the old method. In Commons, the link in the left margin "Participate" → "Upload file" goes to an upload wizard which is so s-l-o-w that it times out (Firefox, Windows XP). I've never succeeded in using it, so I've pasted a link to the old upload page at my commons user page. It may not cover the minefield of copyright, but at least it works. --Redrose64 (talk) 10:57, 3 February 2012 (UTC)[reply]
My draft is quick on my machine. Maybe that's an advantage of doing it in javascript, rather than as a php extension like the Commons wizard, because here all the wizard code runs locally on your machine, without additional server traffic. Wanna give it a try? And yes, I quite agree, the old Special:Upload should of course remain in place for experienced users. This new thing is meant more to replace the current hack at Wikipedia:Upload and its subpages. Fut.Perf. 11:35, 3 February 2012 (UTC)[reply]
  • THis form should also mention that it is better to upload typical free work to commons (except PD-US-only) Bulwersator (talk) 16:21, 3 February 2012 (UTC)[reply]
    • It actually does, as soon as you click the "free work" option. It also offers a link for submitting the file at Commons directly with the information collected here. (Only I haven't yet included a check for the PD-US-only situation yet; thanks for reminding me of that.) Fut.Perf. 19:55, 3 February 2012 (UTC)[reply]
Update: on advice from User:AlexSm, I have moved the script page to MediaWiki:UploadScriptDemo.js, so it can be tested even without changing one's personal .js. The new method of testing is now:
Sorry for the inconvenience if you already edited your .js with the old value.

Counting number of sections on page

Hey. I was looking for something that would return the number of sections on a page. Is there any functionality that would do this? PuppyOnTheRadio (talk) —Preceding undated comment added 07:04, 3 February 2012 (UTC).[reply]

The table of contents box lists that (immediately after the opening section).Jasper Deng (talk) 07:07, 3 February 2012 (UTC)[reply]
Useless for what I was after. I'm trying to set up so that I can return the value to a different page so that indivdual sections can be transposed into a different page. PuppyOnTheRadio (talk) 01:22, 6 February 2012 (UTC)[reply]

Barack Obama - too many templates

The article has its Post-expand include size exceeded (2048000/2048000 bytes), making templates fail. Any technically minded editors feel like trying to clean this up? Edokter (talk) — 11:00, 3 February 2012 (UTC)[reply]

Not a technical problem... you need to gut or split the article. Choyoołʼįįhí:Seb az86556 > haneʼ 11:32, 3 February 2012 (UTC)[reply]


One thing that would help is to cut back on the number of references. Do you really need 8 references to support his christian faith (ref. 3) for instance? Plus for ref 252, 2 references would be fine for that statement rather than 4 it currently has. Also ref 91 has 5 refs when surely 2 or 3 should be sufficient?
You might want to think about using more book sources and/or use {{vcite news}}, see Elvis Presley to see how they have done this. The structure they have used there is well with the template limits. Mattg82 (talk) 17:03, 3 February 2012 (UTC)[reply]
Citation Style Vancouver is more than the one template. And you can't just switch from one to the other as parameters differ. ---— Gadget850 (Ed) talk 18:41, 3 February 2012 (UTC)[reply]
Post-expand include size: 399636/2048000 bytes
Template argument size: 170200/2048000 bytes
This version does not show any problem that is immediately obvious. How can you tell there is a problem? Jc3s5h (talk) 18:31, 3 February 2012 (UTC)[reply]
Near the bottom of the page, templates do not render; instead, the template names show. ---— Gadget850 (Ed) talk 18:35, 3 February 2012 (UTC)[reply]
Atrocious loading speed, "Template:PersondataTemplate:Link GA Template:Link GA Template:Link FA Template:Link FA Template:Link FA Template:Link FA Template:Link FA Template:Link FA" on the bottom and hidden category "pages where template include size is exceeded"? Bulwersator (talk) 18:37, 3 February 2012 (UTC)[reply]
Exactly. The page as it stands shows five navboxes followed by a bunch of bluelinks to templates, but if you edit the "External links" section, don't alter anything but go straight for "Show preview", you'll see six navboxes and an "Authority control" (plus the persondata if you have that enabled); and all the template links have disappeared. --Redrose64 (talk) 20:37, 3 February 2012 (UTC)[reply]

Realy, we should have a Cleanup template for this (to be placed on top). -DePiep (talk) 14:19, 4 February 2012 (UTC)[reply]

Check for duplicate references. They are may be a few of them. Ruslik_Zero 14:56, 4 February 2012 (UTC)[reply]

New shoutbox that actually works

I've created a shoutbox template that doesn't completely screw up your talk page, at Template:Shoutbox sidebar, with very simple and clean installation. People have been trying to use shoutboxes here since at least 2009, but they've always been weird floating boxes that got in the way of other content and features. Fixed! — SMcCandlish Talk⇒ ʕ(Õلō Contribs. 19:05, 3 February 2012 (UTC)[reply]

SharedIP user Newtalk notification is still broken

The "You have new messages" notification that we all know and love does work for SharedIP user talkpages, which breaks the whole idea of vandalism warnings for such users.

Consider that a school at {arbitrary ip address} may have many users accessing from the same IP, even if only one is editing. When (let's call him) Bart deletes content, someone posts a warning on [[User talk:{arbitrary ip address}]] to tell Bart not to do that. But at that moment in the next classroom, Lisa clicks on a wikilink only to see the orange banner. She follows the embedded link to [[User talk:{arbitrary ip address}]], and sees the warning intended for Bart, {{subst:uw-delete}}. He, however, never sees even the banner, let alone the warning. Encouraged by the apparent lack of notice, he continues vandalizing...

There ought to be a way that this can be avoided. Perhaps by ensuring the Newtalk field isn't cleared on IP talkpages until one of the SharedIP users actually edits that usertalk page instead of just reading it. Even better (if somewhat harder) would be to drop a persistent cookie on the browser to stamp the last time that browser read the IP user talkpage and if that cookie is older than the talkpage, changing display on that basis. LeadSongDog come howl! 19:54, 3 February 2012 (UTC)[reply]

This is an interesting idea, but may not be fruitful. For one, most shared ips are filled with editors at schools who don't know or don't care about talk page messages. That may be cycnical, but I think it's accurate. If we implement such a change, it will simply keep the banner at the top of any article that is visited for the entire batch of editors. That will likely annoy them, and not lead to the relevant individual seeing the message for them in a timely manner anyway. I sadly think this is a problem that just doesn't have an easy solution. It's part of the price we pay for allowing ip and shared ip editors. I'm not sure if 'more banner' will do the trick. Ocaasi t | c 21:40, 3 February 2012 (UTC)[reply]
Regarding "[…] drop a persistent cookie on the browser […]": less than two years ago, I had proposed a way to tie edits and warnings together using unique, one-hour tokens for this exact situation. PleaseStand (talk) 22:02, 3 February 2012 (UTC)[reply]
The fraction of IP users in a given hour who edit is fairly small, likely below 1%. Most just read (like Lisa in my example). Putting the orange bar atop their screen until someone edits the talkpage has positive effects. First, it may engage Lisas in editing, not just the Barts. Second, it may cue the Mr Skinners who are curious what Bart is smirking about in the back of the detention hall. Third, it lets Bart actually read the message intended for him. Who knows, it may even motivate some users to create an account! LeadSongDog come howl! 22:12, 3 February 2012 (UTC)[reply]
I like your analogy, and the idea of bringing some of those ip editors into the fold, especially the Lisa's is intriguing. But there has to be some intelligent way for them to get rid of the banner, otherwise it breaks basic usability principles. You shouldn't be harangued by warnings; you should be able to make them disappear once viewed. At the least, an alternate banner would have to be designed just for shared ips which told them what to do to make it go away. If that involves editing the talk page, then so be it, but at least they'll be informed. I don't know if a special banner is technically feasible, but it seems the only way to maintain balance while aiming for better messaging. Ocaasi t | c 22:30, 3 February 2012 (UTC)[reply]
Well it would certainly better if it can be made automatic as per PleaseStand's earlier suggestion. The Newtalk fields already distinguish ipusers, it doesn't seem that big a reach. Even if that's a "just click here to dismiss" button, that would be an improvement on the present situation. LeadSongDog come howl! 06:34, 4 February 2012 (UTC)[reply]
Usually, the organization learns its lesson after its first block, and then tries to educate its users on it. Schools, due to the natural immaturity schoolchildren have, are a constant source of vandalism, so their IPs are usually blocked regardless of whether a warning was given or not. I'd support this idea only for sessions that have been editing Wikipedia, since the cookie can just be for that particular session.Jasper Deng (talk) 06:38, 4 February 2012 (UTC)[reply]
So, set a session cookie when an IP's browser edits, and then have a message that is shown only to browsers from that IP which have that cookie set while remaining hidden from other browsers at that IP? It sounds like something that could be implemented by the wizards. It would ensure Bart can receive the message, and avoid annoying Lisa. LeadSongDog come howl! 02:47, 6 February 2012 (UTC)[reply]

Zoom for Template:Coord and related

Having a possibility to the define a zoomlevel would be a nice to have for articles like Nizami Street. Here the bare toolserver link shows the entire city plus a lot of surrounding area instead of pointing direct to the street. -- Kr51-2 (talk) 23:49, 3 February 2012 (UTC)[reply]

See the scale and dim parameters at Template:Coord#Coordinate parameters. Compare for example these: 40°22′23″N 49°50′25″E / 40.372944°N 49.840395°E / 40.372944; 49.840395 40°22′23″N 49°50′25″E / 40.372944°N 49.840395°E / 40.372944; 49.840395. PrimeHunter (talk) 00:17, 4 February 2012 (UTC)[reply]
Thank you. -- Kr51-2 (talk) 13:10, 4 February 2012 (UTC)[reply]
This is actually a landscape PDF file.

What's going on here? Is the MediaWiki renderer misinterpreting the page dimensions? — This, that, and the other (talk) 23:55, 3 February 2012 (UTC)[reply]

Looks like it may just be a extension:pdfhandler bug; thing apparently doesn't like non-standard aspect-ratios... is landscape as opposed to the other way non-standard? Isarra (talk) 02:55, 4 February 2012 (UTC)[reply]
The renderer is either unaware of landscape A4, or unaware that 29.700 x 20.997 cm (the exact dimensions of the PDF page) is really the same as landscape A4. I'll have to reupload the image in some other format. — This, that, and the other (talk) 10:37, 4 February 2012 (UTC)[reply]

Annoying box templates

Hi, I've encountered an annoying problem on many Wikipedia pages with box templates interfering with image placement, so that wherever one of this boxes is placed, all images on the opposite or same side of the page are moved down. A weird example can be seen here Hafez al-Assad The "Baathism box" pushes all images on right side way down. What can be done about such boxes? FunkMonk (talk) 13:34, 4 February 2012 (UTC)[reply]

Not much. Any box or image placed on the right side of a page is a 'floating' element and they stack on top of each other. Edokter (talk) — 15:02, 4 February 2012 (UTC)[reply]
Browsers and other factors can affect what people see. I'm not sure what you mean by "way down". The image "a statue of Hafez Al-assad in Aleppo" is right below the "Part of a series on Ba'athism" box for me. It should either be right below the Ba'athism box or right below the "Presidency" heading, whichever of the two is lowest. Is it further down for you? {{Stack}} can change page layout in some cases. PrimeHunter (talk) 15:33, 4 February 2012 (UTC)[reply]
Moving them down on the same side is normal, and intended, since otherwise they'll pile up and make an article nigh unreadable, but the stuff on the opposite side (in the example case, the left) shouldn't be affected at all, but for some reason it is trying to clear right. But it really shouldn't be doing that; the box seems to be formatted the same way as the image thumbs themselves, which as you're probably aware, only prevent piling up on whatever side they happen to be on - so either it's just too many things adding up and confusing browsers, or something else (another template?) in the article is probably forcing an unwanted clear. I couldn't find anything in the linked one, though. Isarra (talk) 17:09, 4 February 2012 (UTC)[reply]
The layout of Hafez al-Assad appears normal to me in Firefox 10. As mentioned, browsers and other factors can affect what people see. If you think an image is displayed in the wrong place then please be specific about which image, where you see it and in which browser. PrimeHunter (talk) 18:29, 4 February 2012 (UTC)[reply]
(edit conflict) Left-aligned images that occur after right-aligned images in the wikicode will appear below, or level with, the right-aligned image which precedes it in the wikicode. They will not appear above. So if a right-aligned image is pushed down, for whatever reason, it will also push down left-aligned images. Kludges like {{stack}} apart, the only way to get a left-aligned image to appear above a right-aligned image is for it to also occur earlier in the wikicode. This behaviour is known, and has been mentioned many times on this page in the past. --Redrose64 (talk) 18:30, 4 February 2012 (UTC)[reply]

MathML

This is a question asked at the help desk earlier. As suggested in a reply there, I'm asking the question here. I have set the math appearance setting to "MathML if possible". Although Firefox 9.0.1 supports MathML, all equations in Integral are rendered as PNG images. The caption line at the settings page has no URLs as to where the feature is described or developed. Is this feature a part of mw:Texvc? Should I report a bug to MediaWiki bug tracker or somewhere else? Thank you in advance. Gryllida 00:04, 5 February 2012 (UTC)[reply]

This "feature" has been completely out of commission since around 2003 or 2004. Development on MediaWiki is pretty stagnant for the most part. There was a brief resurgence with the BlahTex plugin but last time I checked, no one was working on it. —Designate (talk) 02:31, 5 February 2012 (UTC)[reply]
See also Wikipedia:Village pump (technical)/Archive 94#MathML. --Redrose64 (talk) 14:38, 5 February 2012 (UTC)[reply]
According to bugzilla:25646#c5, this was "fixed" on by removing the MathML option (and some other math options) on rev:104498 (and it seems this change will be live once MW 1.19 is deployed - check on Wikimedia labs). See also:
Helder 17:58, 5 February 2012 (UTC)[reply]

Link rot continuing

So a while ago (I think over a year, but I may be overstating things), I made a pitch to start auto-adding archive links to cite-web template links. That discussion got bogged down and I lost track of it, but it seems, at least from the numerous dead links I've seen, that the end result was apparently no action.

I tend to use archive.org, I don't care which archive source we use, I don't care if we use a random number generator to choose among a list of possible archive sites and invite anyone who wants to join that list if they can handle the requests.

We could do this via bot. All we need is a simple bot that goes to cite-web template links, checks if there are archived copies, if it's dead (or I would prefer even if it wasn't dead yet), add an archiveurl and archivedate parameter (if we can make it smart enough and the archive source offers multiple archived copies, we should aim for the copy closest to the access date (if available, otherwise closest to the date the citation was added, if available, otherwise latest), barring those with bad http response codes). I'm not an expert on Wikipedia bots and I also am not generally active enough to wade through the bot approval process, but someone could write this.

However, this is also something which ought to be doable on the Wikipeda software-level, and/or the Wikipedia foundation. I would just like to see some action by some one to combat this problem. Of course, I'm sure someone will ask, why not me? Maybe someday, but given my level of Wikipedia involvement, I'm not betting on soon. Jztinfinity (talk) 19:20, 5 February 2012 (UTC)[reply]

Random web pages archive OK, but very few periodicals allow themselves to be archived by free services, opting rather to use a pay-to-view archiving solution. An automated archiving solution would preferentially maintain links to the lowest quality sources, unfortunately. Not a bad idea to do, it's just a matter of looking at the consequences of putting such a solution in place. --User:Ceyockey (talk to me) 19:51, 5 February 2012 (UTC)[reply]
I think that one thing which could help to deal with link rot where a periodical is involved would be implementation of the findtpl extension. I found this a minute ago while poking around for ways to search citation template parameter values for a particular periodical title, The News Journal, which has a 'move to pay-to-read archive' policy in place which breaks all article links in a matter of weeks after use here. The use of the findtpl extension in conjunction with some bot work could provide a useful assist to people who want to monitor references to particular periodicals in citations. --User:Ceyockey (talk to me) 23:16, 5 February 2012 (UTC)[reply]

Help moving list defined references

I want to move a lot of text with a lot of references from Game of Thrones (TV series) to Game of Thrones (season 1). Unfortunately, the source article uses list-defined references (WP:LDR). This means I must copy the entire huge list of references to the target article, and then I get cite errors in the reference lists in both articles because many footnotes defined in the list are now used in the other article. Is there some fix or workaround for not having to sort out manually every single reference? Or is there a tool that can convert the article back to normal inline references format, which allows much more flexible editing?  Sandstein  20:12, 5 February 2012 (UTC)[reply]

I fixed the cite errors by converting the entire article (including the LDR portion that you added) back to the inline format using my References segregator script. These are the steps I performed:
  • I used regex to replace uses of the {{r}} template with plain ref tags.
  • I copied and removed (cut) the entire LDR list from the wikitext.
  • I clicked the "Segregate refs for editing" button.
  • I removed all the empty ref tags from the lower text box.
  • I pasted the LDR list into the lower text box (after its existing contents).
  • I saved the page, which merged the citation templates from the lower text box into the upper text box and removed the unused footnotes in the process.
I only did a quick check for obvious errors and duplicate references, so you probably should examine the list of references to see if there is anything that did not convert correctly. PleaseStand (talk) 20:54, 5 February 2012 (UTC)[reply]
Thanks for your prompt and competent help! I'm now trying to fix the corresponting errors in the source article using the same procedure. Do you remember the regex you used for the first step?  Sandstein  21:03, 5 February 2012 (UTC)[reply]
Or are there other regex experts around? Simply using {{r|(.+)}} → <ref name="\1" /> doesn't work, as this will treat lines that contain multiple {{r}} entries as one match. (As an aside, this weird references format really annoys me; it's ridiculous that one needs regex knowledge and a special script just to move text from one article to the other.)  Sandstein  21:34, 5 February 2012 (UTC)[reply]
I agree that {{r}} and {{rp}} are annoying. If your regex engine is sufficiently advanced, you could try {{r|(.+?)}} instead; otherwise you could try {{r|([^}]+)}}. See Regex#Lazy quantification for an explanation of how this works. Anomie 00:36, 6 February 2012 (UTC)[reply]
I have fixed the cite errors on the source article using the same procedure. I used the "Search and replace" feature of the enhanced editing toolbar (Search for: {{r\|([^}]+)}}, Replace with: <ref name="$1"/>, Treat search string as a regular expression) to deal with {{r}} (note the backslash that escapes the vertical bar). PleaseStand (talk) 02:38, 6 February 2012 (UTC)[reply]
Thanks again! I have documented this at Help:Converting between references formats.  Sandstein  07:15, 6 February 2012 (UTC)[reply]

Renumbering template parameters

When adding a new parameter to a template that calls {{Infobox}}, it's necessary to increment the numbers of all the subsequent parameters. Does anyone have a script or tool to perform this tedious task? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:37, 5 February 2012 (UTC)[reply]

HOW TO EDIT IN IPHONE?

LONG ARTICLE, I CAN NOT EDIT IN IPHONE. BECAUSE I CAN NOT SCROLL DOWN IN EDIT WINDOW.

HOW TO SCROLL DOWN IN EDIT WINDOW?

I WANT, BELOW SUBJECT, "WRITE THE LAST" ICON

BECAUSE, IN IPHONE, SCROLL DOWN IS VERY DIFFICULT.

IN SOUTH KOREA, 1/2 PEOPLE USE IPHONE. -- Bonafide2004 (talk) 23:15, 5 February 2012 (UTC)[reply]

All other observations aside, this is probably a very valid point. Anyone else tried editing with iOS or Android devices? ▫ JohnnyMrNinja 23:24, 5 February 2012 (UTC)[reply]
Please don't shout. --Redrose64 (talk) 23:28, 5 February 2012 (UTC)[reply]
general question - not responding to Nin — Would searching for a term not jump to that term location in the edit window, as it does in a regular browser instance? --User:Ceyockey (talk to me) 23:28, 5 February 2012 (UTC)[reply]
There is no search for term native for Safari/iPhone. I have an applet that I use for that purpose, and it will highlight terms, but not jump to them. PuppyOnTheRadio (talk) 03:35, 6 February 2012 (UTC)[reply]

I USE ANDROID. :)

I READ Help talk:Mobile access#Scroll down when editing a wiki page -- Bonafide2004 (talk) 23:31, 5 February 2012 (UTC)[reply]

iPhone iOS 4.x will not allow scrolling, whereas iPhone iOS 5.x will. Updating your iOS software through iTunes should fix your issues. PuppyOnTheRadio (talk) 02:16, 6 February 2012 (UTC)[reply]
Of course that only works for 3GS or later, as earlier models can't support iOS 5, if the users even want to update. Perhaps we should look at a simple addition to the editing window for these types of devices? ▫ JohnnyMrNinja 07:36, 6 February 2012 (UTC)[reply]
People still use older model iPhones! OMG! PuppyOnTheRadio (talk) 08:22, 6 February 2012 (UTC)[reply]
Serious note - it's an issue with the browser and not the site. I have tried playing with different options to be able to adjust it and had no joy. Again, going to Help talk:Mobile access#Scroll down when editing a wiki page I've added another way of getting around this, which is to copy all text to notepad, make the edits, and tyhen copying it all back to the edit box. It's a pain to do but I have not been able to find any better work-around. PuppyOnTheRadio (talk) 08:38, 6 February 2012 (UTC)[reply]

Local image search?

I've been trying to search local images but the search results include Flickr images. Is there an easy way to filter these out? ▫ JohnnyMrNinja 01:48, 6 February 2012 (UTC)[reply]

I usually attempt using MediaWiki's search function as well as Google to find hard-to-reach things. Does this search help? Killiondude (talk) 06:24, 6 February 2012 (UTC)[reply]
The problem is that Commons images display as local WP pages to search engines, so many images that come up are actually on Commons. ▫ JohnnyMrNinja 06:33, 6 February 2012 (UTC)[reply]
How about this? Goodvac (talk) 06:41, 6 February 2012 (UTC)[reply]
That does it, thanks! Although, it still doesn't make sense that the default search for this wiki contains images hosted on another wiki. Makes maintenance a bit of a pain. ▫ JohnnyMrNinja 07:03, 6 February 2012 (UTC)[reply]
It's the way that the Wikimedia projects are linked together. File:Commons-logo.png is hosted on commons at http://commons.wikimedia.org/wiki/File:Commons-logo.png, and to make it usable on Wikipedia, it may also be reached as http://en.wikipedia.org/wiki/File:Commons-logo.png - two locations, one page. If shortcuts like this didn't exist, it would be more difficult to use images from commons, and much of the point of having commons would be lost. --Redrose64 (talk) 14:48, 6 February 2012 (UTC)[reply]
Most image searchers probably want to view or use images without caring where they are so it makes sense to include Commons by default. But it would sometimes be helpful if the namespace selector had an option for local files. PrimeHunter (talk) 15:08, 6 February 2012 (UTC)[reply]

Edit a section from a diff

Wasn't it once possible to edit a section directly from a diff? It would be convenient to do so. DrKiernan (talk) 08:31, 6 February 2012 (UTC)[reply]

I'm glad you can't. I often forget I'm looking at a diff and try to edit a section. But that's just me. Someguy1221 (talk) 08:35, 6 February 2012 (UTC)[reply]
On the other hand, I don't a point in not being able to edit a section in a diff to the latest version of a page. Helder 09:47, 6 February 2012 (UTC)[reply]
That's what I mean: if I click on a diff from my watchlist then I often want to go straight to the amended section to make a further edit; but instead I have to edit the entire page. I thought we used to be able to go straight to the section and edit it. DrKiernan (talk) 10:36, 6 February 2012 (UTC)[reply]
@Someguy1221: The old behaviour was that section edit links would only show in a diff if the more recent version of the two being compared was the current version; in that way you couldn't accidentally edit a section within an old version. The new behaviour is that some pages show section edit links in a diff: and when they are shown, they still follow the old rule about only showing when comparing to current version.
Editing a section from a past version is technically possible as a combination of oldid=id with action=edit&section=n, but it would be unwise to call this from a diff or oldid because of the risk of wikitext corruption due to sections' renumbering. Incnis Mrsi (talk) 10:13, 6 February 2012 (UTC)[reply]
See Wikipedia:Village pump (technical)/Archive 96#Missing section edit links on a diff and bugzilla:33671. PrimeHunter (talk) 11:33, 6 February 2012 (UTC)[reply]
Yes, this used to be possible and was recently broken. You can still edit from a diff if you transclude a special page onto the page, though no one knows why. According to comments in the bug, this has been fixed in MediaWiki 1.19, which will hopefully be rolled out within the next few weeks. Ucucha (talk) 13:53, 6 February 2012 (UTC)[reply]
Yeah, it's hisioulsy anoying to me -- 98% of the time when I want to edit and it's not a rollback/undo, I'm looking at a diff, because after all, how else would I check what's new?. The change has been annoying enough that I've simply not even bothered a few times. ♫ Melodia Chaconne ♫ (talk) 14:54, 6 February 2012 (UTC)[reply]

Movepagetext not showing proper message to admins.

I've noticed that I'm not getting the admin-specific message when I move a page: "Note to admins: The "leave a redirect behind" option should only be unchecked when..". I left a note on this on the talk page here but there's been no response. Is this just me or is no sysop seeing the appropriate warning? Tassedethe (talk) 17:01, 6 February 2012 (UTC)[reply]

That message is not used anymore, the new message is Movepagetext-noredirectfixer but nobody cared to update it, see WP:Village pump (technical)/Archive 96#Special:MovePage instructions. — AlexSm 17:13, 6 February 2012 (UTC)[reply]
Ah, that explains that then. It does seem that the new message is missing much of the older one's functionality e.g the specific warnings about trying to move User pages. Tassedethe (talk) 18:46, 6 February 2012 (UTC)[reply]

System messages in German?

Please see this permanent link. At the bottom of the page an extra-large red font text says that there are <ref> tags but no <references /> tag in the article, but why does it say that in German? Maybe we've decided to gradually turn into a German-language Wikipedia, but there is one already... I'm confused :) --Theurgist (talk) 17:54, 6 February 2012 (UTC)[reply]

It doesn't for me. --Golbez (talk) 18:02, 6 February 2012 (UTC)[reply]
It's a bug, see Template:Bug. A purge fixes it. Anomie 18:06, 6 February 2012 (UTC)[reply]
(edit conflict) This is part of bug #31216, it's a fairly complex issue todo with the interaction of caching layers. - Jarry1250 [Deliberation needed] 18:07, 6 February 2012 (UTC)[reply]
Documented at Help:Cite errors#Error in wrong language. ---— Gadget850 (Ed) talk 18:12, 6 February 2012 (UTC)[reply]
Same issue as Wikipedia:Village pump (technical)/Archive 95#German cite error. The last person to edit the page had their interface language set to German, and you're getting their cached copy back. WP:PURGE the page, and it'll sort itself out. --Redrose64 (talk) 18:39, 6 February 2012 (UTC)[reply]

Database error

Getting the following error when I save an edit:

A database error has occurred. We apologise for any inconvenience this might have caused. The most likely cause of this problem is a search or other operation that took too long. Possible reasons include:

   * A search where all words are in quotes. Try searching without the quotes initially or add a few more words outside the quotes to restrict the search;
   * An exceptionally large personal watchlist (probably over 10,000 items); or
   * Exceptionally heavy load on the database servers. 


Technical details about this error: Last attempted database query: (SQL query hidden) Function: SqlBagOStuff::set MySQL error: 1637: Too many active concurrent transactions (10.0.6.50)

Thanks. Lugnuts (talk) 19:10, 6 February 2012 (UTC)[reply]

I keep on getting that too - only in the last 20 minutes or so, but I did get the same error a few times last week as well. It's not only when you try to save a page either - I got it the first time I tried to come here. SmartSE (talk) 19:14, 6 February 2012 (UTC)[reply]
I'm getting this too. It'll come up, but the edit will still go through. Ten Pound Hammer(What did I screw up now?) 19:20, 6 February 2012 (UTC)[reply]
This error was caused by a mistake in the swift deploy (see next topic). It was resolved at about 19:20UTC. Bhartshorne (talk) 21:56, 6 February 2012 (UTC)[reply]
Thanks. Lugnuts (talk) 08:06, 7 February 2012 (UTC)[reply]

Database error and linking with Commons

I originally got the Database error as mentioned above. Now I see odd things with images that come from Commons. Over at Commons, it's very slow to load a page with multiple images, and not all the images load. If I pull up a WP page that has images from Commons, such as Museums in East Texas or Museums in West Texas, some of the images will load, but in some places it instead links directly to the WP page image, rather than the image as the other do. Maile66 (talk) 19:24, 6 February 2012 (UTC)[reply]

On my computer, the situation has been resolved for the time being. Maile66 (talk) 21:11, 6 February 2012 (UTC)[reply]

Deploying Swift for thumbnails this week (Feb6-9)

This week (Monday through Thursday), I will be switching over the backend system that hosts thumbnails (scaled images) for all wikis from our existing server to Swift, a clustered object store. This move gets us ready to be able to dramatically increase the amount of data we can hold in Commons and the other wiki projects.

As with all new systems, though it has been tested, the possibility exists that something will go wrong. I would like your help testing and reporting any issues. There are two main methods available to report issues:

  • IRC: join #wikimedia-tech and ping maplebed
  • Wiki: add a section to the Issues page on mediawiki.org.

Today, only files that contain "/a/a2/" in the URL are be affected. More files will be affected throughout the week following a gradual rollout schedule. Though I will take bug reports on other issues, they're less likely to be related to the change I'm making.

More detail is available on the wikitech-l mailing list post I wrote last week.

Thanks for your help, Bhartshorne (talk) 21:53, 6 February 2012 (UTC)[reply]

FYI: There is an Interwiki map that can be used as a reference to wikify links to wikitech:Swift and mailarchive:wikitech-l/2012-January/057905.html. – Allen4names 06:51, 7 February 2012 (UTC)[reply]
Thanks; I've updated the post with the correct interwiki links. Bhartshorne (talk) 00:43, 9 February 2012 (UTC)[reply]

infobox and image conflicting (IE9)

Hi, just started having an issue with the infobox and the centered image in Fluorine conflicting. It was NOT an issue for weeks before, just started right now. Seems to be only in IE9 an issue. Mozilla is fine and so is Chrome. And even IE was fine until just now (fine for several days).

FYI, moving the image to the left did not help (with space separators). Still have the conflict (basically image will not display until after the infobox is done). If I allow to text wrap, will work, but then I break the section header. REally I want it the way it was before (centered, looked sweet).

Ideas? Will it fix itself?

TCO (talk) 05:23, 7 February 2012 (UTC)[reply]

P.s. Don't fuss at me for too many pictures or a big infobox or centering an image. I like using the layout as more than just a wall of text and only text wrapped images. Help please instead of fussing.  ;-) Really everything was fine until a few hours ago.

Is compatibility view enabled? If so, it breaks all sots of stuff on Wikipedia. ---— Gadget850 (Ed) talk 13:46, 7 February 2012 (UTC)[reply]
That was it. Turned it back off. Must have hit it by mistake...it is right next to the reload button. Thanks for your expertise!TCO (talk) 14:51, 7 February 2012 (UTC)[reply]

Automatically combining male and females into a single category

Is it possible to redirect categories? So if you put Category:Swordswomen on an article it would really go into Category:Swordsmen, but show as Swordswomen on the article? Richard-of-Earth (talk) 06:43, 7 February 2012 (UTC)[reply]

It's not possible to display the pages in the target category. See Help:Category#Moving and redirecting category pages. If Category:Swordswomen was redirected to Category:Swordsmen then an article using Category:Swordswomen would display Swordswomen on the article and clicking it would lead to Category:Swordsmen, but the articles using Category:Swordswomen would not be displayed there. PrimeHunter (talk) 12:44, 7 February 2012 (UTC)[reply]
The only permitted method for redirecting a category is by using the {{Category redirect}} template, see for example Category:Living People. If an article were given the wikicode [[Category:Living People]] (capital "P"), it would be categorised as such; and within 24 hours a bot will come along and recategorise it as [[Category:Living people]] (small "p"). I don't know if the bots will fixup all redirected categories though: Matekoraha Te Peehi Jaram has been in Category:Ngati Maru (Taranaki) for over three days now. --Redrose64 (talk) 14:06, 7 February 2012 (UTC)[reply]
So, should this be changed? Should a new kind of category redirect be made? Opinions? Richard-of-Earth (talk) 20:32, 7 February 2012 (UTC)[reply]
This is a poor idea. It will just cause confusion if a page is displayed in a category but another category name is displayed on the page. PrimeHunter (talk) 20:40, 7 February 2012 (UTC)[reply]

Counting number of sections on page for transposing

I put something up earlier about this. I'm trying to get something that will count the number of sections in a particular page, and return the value to another page to be used with parser functions (so to return the nth last section.) I had a response that didn't help me earlier, so I'm bumping it back up. PuppyOnTheRadio (talk) 07:45, 7 February 2012 (UTC)[reply]

You don't need to start a new thread. If you post to your original thread, which is at #Counting number of sections on page, it saves the discussion from becoming split. This will become a greater problem when one of the two becomes old enough for archiving, but the other isn't. --Redrose64 (talk) 14:10, 7 February 2012 (UTC)[reply]
Good point. Still not an answer that helps me, and as the last discussion seems to have come to a schreeching halt, I'm just putting it up again now rather than waiting for the last one to be archived and then putting it up. PuppyOnTheRadio (talk) 00:56, 9 February 2012 (UTC).[reply]
The best I can come up with is:
  1. Goto Google
  2. If you don't have one already, open an account
  3. Go to Google docs
  4. Create a spraedsheet
  5. Put in a cell this: =counta(ImportHtml(ʺhttp://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)ʺ,ʺlistʺ,3))
  6. You now have the count of topics from this page.
  7. Put in a cell this: =ImportHtml(ʺhttp://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)ʺ,ʺlistʺ,3)
  8. You now have a list of topics from this page.
I don't know if this works for every article. You may have to change the index (3 in this case) for different pages. I leave it to you to figure out how to reverse the list. Richard-of-Earth (talk) 08:39, 9 February 2012 (UTC)[reply]

Hidden text

The edit box used to have a one-click feature to hide text. But, it's not there anymore. I forgot how to hide text, and I had to search for in a labyrinth of help pages. Why can't that feature be retained in the new edit box? Aditya(talkcontribs) 13:26, 7 February 2012 (UTC)[reply]

"Hide text" can refer to different features and I'm not sure which one you mean. Below "Save page" you can select "Wiki markup" in a drop down box (if you have JavaScript enabled). There you can click <!-- --> to make a source comment if that is what you mean. PrimeHunter (talk) 13:42, 7 February 2012 (UTC)[reply]

Type of user in javascript

Is there a simple test in javascript to determine whether a given username is a registered user or an ip? SpinningSpark 15:38, 7 February 2012 (UTC)[reply]

Presumably a regex match is easiest, and to keep things simple (since I'm fairly confident we don't allow you to imitate anything that even looks like an IP address), we can use a more general regex that we might otherwise. If username is the relevant string:
if( username.match( /^([12]?[0-9][0-9]\.){3}([12]?[0-9][0-9])$/ ) ){
 //IP
} else {
 //User
}
It's not particularly specific, but I don't think it needs to be. - Jarry1250 [Deliberation needed] 15:50, 7 February 2012 (UTC)[reply]
This solution is not safe for work, because there are IPv6 unregs too. Incnis Mrsi (talk) 16:01, 7 February 2012 (UTC)[reply]
It's not future proof, but it'll work for now. We don't have IPv6 users (yet). - Jarry1250 [Deliberation needed] 16:28, 7 February 2012 (UTC)[reply]
What about mw.user.anonymous()? Helder 16:03, 7 February 2012 (UTC)[reply]
If a set of four numeric values is tested, it's worth testing that each of those is in the range 0-255. That is, a user name like 256.256.256.256 cannot be an IP address. --Redrose64 (talk) 16:08, 7 February 2012 (UTC)[reply]
I don't think we allow people to register as User:256.256.256.256, though I could be wrong. and mw.user.anonymous would be fine if you have a user object; I'd forgotten about that. It depends how careful you want to be (AFAIK, it's all done by username anyway: there's no official IP/username divide). - Jarry1250 [Deliberation needed] 16:28, 7 February 2012 (UTC)[reply]
I just tried and couldn't register User:256.256.256.256; User:256.256.256.256.256 didn't work either. That one gave a different error message though (complaining about there being no letters in the name). It might come from MediaWiki:Titleblacklist though I haven't located the relevant regex. Ucucha (talk) 16:46, 7 February 2012 (UTC)[reply]
Forgive me for not being very smart with this, but isn't mw.user.anonymous just returning whether or not I am an IP or not? What I need to know is whether a name I have stored in a variable is an IP. SpinningSpark 16:50, 7 February 2012 (UTC)[reply]
How about mw.user.name() then (listed in the same manual page)? It apparently returns NULL for logged-out users. Ucucha (talk) 16:52, 7 February 2012 (UTC)[reply]
I don't understand how I enter my variable into that expression. Can you give an example? SpinningSpark 18:02, 7 February 2012 (UTC)[reply]
At svn User.php, the following test is defined (with ".xxx" as an alternative suffix for compatibility with old logs) in User::isIP:
return preg_match('/^\d{1,3}\.\d{1,3}\.\d{1,3}\.(?:xxx|\d{1,3})$/',$name) || IP::isIPv6($name);
IP::isIPv6 is in turn defined at IP.php with some complicated regexes.
User::isValidUserName rejects usernames that match User::isIP, are blank or too long, contain a slash, or (for ucfirst wikis) begin with a lowercase letter.
Richardguk (talk) 17:00, 7 February 2012 (UTC)[reply]
function isIP(userName) {
	var ip=false;
	$.ajax({
		url: '/w/api.php?action=query&list=allusers&aufrom='+userName+'&auto='+userName+'&auprop=rights&format=json',
		success: function(data) { ip=typeof(data.query.allusers[0])=="undefined"; },
		dataType: 'json',
		async: false
	});
	return ip;
};

Bility (talk) 18:42, 7 February 2012 (UTC)[reply]

I have tried to implement that regex at User:Spinningspark/monobook.js but I don't really understand regex very well. It seems to be returning userIP=true no matter what the input. Can someone take a look? - it is right near the beginning of the page. SpinningSpark 19:06, 7 February 2012 (UTC)[reply]
Don't wrap the regex in single quotes. In other words, change '/^\d{1,3}\.\d{1,3}\.\d{1,3}\.(?:xxx|\d{1,3})$/' to /^\d{1,3}\.\d{1,3}\.\d{1,3}\.(?:xxx|\d{1,3})$/. — Bility (talk) 19:21, 7 February 2012 (UTC)[reply]
Done it, but it makes no difference. The line still returns userIP=true no matter what. SpinningSpark 23:24, 7 February 2012 (UTC)[reply]
The code if (userIP=true) is wrong. It should be if( userIP == true ) with two equal signs. — AlexSm 23:34, 7 February 2012 (UTC)[reply]
Ah, thanks for that. Forgot about the ==, all works now. Cheers everyone who looked at this. SpinningSpark 00:03, 8 February 2012 (UTC)[reply]

Template:US year nav is included at the bottom of every XXXX in the United States article. But it really makes a mess of itself in some of these articles, such as 1777 in the United States. Notice how the bottom elements of the page get all bunched up? I thought I would be clever and insert {{clear}} at the top of the template, purge everything, and then the problem would be solved. But that did not work. Does anyone know how this problem can be solved? Am I missing an obvious problem in the article page? --Andrew (User:90) (talk) 21:26, 7 February 2012 (UTC)[reply]

It wasn't you, someone didn't close some divs elsewhere on the page. — Bility (talk) 21:36, 7 February 2012 (UTC)[reply]
Ah, I see what you did. I just did the same to 1776 in the United States and it worked. I wonder if it is a good idea to use {{Div col}} at all for lists that only contain a few items. Perhaps this is not the correct place to ask, but would anyone object if I just removed {{Div col}} instead of closing it in the other XXXX in the United States articles that are unclosed? --Andrew (User:90) (talk) 21:46, 7 February 2012 (UTC)[reply]
I wouldn't object, since it looks stupid like that. — Bility (talk) 22:03, 7 February 2012 (UTC)[reply]
I expect that there will be no technical objections, but you might like to run it past WP:USA who might have some sort of agreed style. --Redrose64 (talk) 22:14, 7 February 2012 (UTC)[reply]

Edit notice color

Does anyone know the hex color of the bright orange edit notices we used to have? I would like to adopt it for my Wikia sites. – Confession0791 talk 03:40, 8 February 2012 (UTC)[reply]

If you are talking about this notice:
then the hex color is #ffce7b. Hope that helps. However, I may be misunderstanding you, as you said used to have. --Andrew (User:90) (talk) 04:13, 8 February 2012 (UTC)[reply]
No, it was used for lists of tv episodes concerning the addition of unsourced future material. The color was closer to #ffcc00. – Confession0791 talk 04:24, 8 February 2012 (UTC)[reply]
Ah, sorry 'bout that. Is there an article where you know for sure the edit notice was used? If so, and if the edit notice has been deleted, then perhaps an administrator would be willing to provide you with the deleted content so you could find your color. --Andrew (User:90) (talk) 04:43, 8 February 2012 (UTC)[reply]
Do you mean Template:Future episodes editnotice? I don't see orange in the page history. PrimeHunter (talk) 04:49, 8 February 2012 (UTC)[reply]
It was used for some teen sitcom episode lists. I talked to Beeblebrox, but he doesn't know anything about hex colors. – Confession0791 talk 04:53, 8 February 2012 (UTC)[reply]
This search contains a lot of editnotices for TV episodes, but the couple I looked at did not have anything helpful in the history. I'm gonna have to give up on this one, but good luck finding what you're looking for. --Andrew (User:90) (talk) 05:00, 8 February 2012 (UTC)[reply]
Found it.Confession0791 talk 05:12, 8 February 2012 (UTC)[reply]
Web colors#X11 color names says:
HTML name Hex code
R   G   B
Decimal code
R   G   B
Orange FF A5 00 255 165   0
Testing that background:#FFA500 gives the same color as background:orange:
HTML name Hex code
R   G   B
Decimal code
R   G   B
Orange FF A5 00 255 165   0
PrimeHunter (talk) 12:51, 8 February 2012 (UTC)[reply]

Unified login

Not sure if I'm in the right place, but after using {{help me}} I was advised to ask my question here.
When logging into Wikipedia through unified login, I'm logged into every project except Wiktionary (and of course the three two projects pending SUL-request). At first this was solved by not using the secure server (https://), but now it refuses regardless of settings. When logging into Wiktionary directly there is no problem, but then I won't be logged into any of the other projects. In both cases the icons shown suggest I should be logged into all projects. To make it even more interesting: when logging into Wiktionary (manually) after logging into Wikipedia, then logging out on Wiktionary, all of a sudden I am logged out on Wikipedia too, so for logging out it does seem to work... I haven't been able to find anything in the help sections, does anybody have a suggestion? Thank you, — Quibus (talk) 14:00, 8 February 2012 (UTC)[reply]

Curious. When I'm logged into Wikipedia, going for wikt: shows the "Redrose64 / My talk / My preferences / My watchlist / My new messages (None) / My contributions / Log out" links upper right, so I'm logged in there too. If I then log out of Wiktionary, and return to Wikipedia, I find that I have been logged out there too. This is what I expect SUL to do.
I have observed the following over a period of many months, which may not be the whole story. The process of logging out zaps the cookie created when you logged in. I think that SUL means that one cookie is shared by all projects: therefore, logging out of Wiktionary will also log you out of Wikipedia. When additional projects join SUL, the user database is not always copied over, so it's worth visiting Special:MergeAccount every so often to keep them up to date.
When the secure server had its own URL structure, i.e. https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page for the Main Page, it had its own cookies. Now that the only difference in URL structure is https versus http (the secure server main page is now at https://en.wikipedia.org/wiki/Main_Page), it can be demonstrated that by logging in "insecure" and then switching to "secure" (by altering http to https in the browser address bar) you are still logged in, therefore the cookie is shared. --Redrose64 (talk) 15:38, 8 February 2012 (UTC)[reply]
The cookies are only shared if you log in insecurely. If you log in using https, the cookies are marked "secure" so you will not be logged in when accessing via http. Anomie 17:30, 8 February 2012 (UTC)[reply]

RIPE blocks WHOIS requests

It seems that RIPE are now blocking WHOIS requests from Toolserver: http://toolserver.org/~chm/whois.php?ip=2.222.86.252

See also http://www.ripe.net/data-tools/db/faq/faq-db/why-did-you-receive-the-error-201-access-denied Andy Dingley (talk) 22:33, 8 February 2012 (UTC)[reply]

"Edit count" and "Articles created" links

Since X! (talk · contribs) has now retired and his account has expired on the toolserver, what are we going to do with the "Edit count" and "Articles created" links at the bottom of Special:MyContributions page? Jared Preston (talk) 01:16, 9 February 2012 (UTC)[reply]

You beat me to it. I was not aware of the connection until things evolved from my query at User talk:Drmies#Technical issue.3F. I hope that something can be sorted out but the technicalities are beyond me. - Sitush (talk) 01:38, 9 February 2012 (UTC)[reply]
Need someone at the toolserver to resurrect this pretty important tool.Jasper Deng (talk) 03:42, 9 February 2012 (UTC)[reply]
Apparently, the source code to the edit counter was only published through the web interface in a non-crawlable fashion. I do not see it in https://svn.toolserver.org/svnroot/soxred93/. So unless someone already happened to download the source code, X! is willing to provide a copy of his source code, or his Toolserver account can be somehow reactivated, someone will have to rewrite it. PleaseStand (talk) 05:52, 9 February 2012 (UTC)[reply]
  • Edit-counts for all-language WPs: The SUL tool "sulinfo" still works, and shows the edit-counts for all WP languages, including for enwiki:
That tool uses the Quentinv57 account. -Wikid77 (talk) 13:41, 9 February 2012 (UTC)[reply]
Edit count w/ stats: http://toolserver.org/~River/cgi-bin/count_edits (or http://toolserver.org/~River/cgi-bin/count_edits?user=xxx&dbname=enwiki_p) for direct access on en-Wiki. Gives the same numerical results as X!'s counter, though you have to add the total edits (actually the live edits) and deleted edits to get what X! called total edits. There's a machine readable output version, too http://toolserver.org/~River/cgi-bin/count_edits?user=xxx&dbname=enwiki_p&machread=1. Regards, TransporterMan (TALK) 14:48, 9 February 2012 (UTC)[reply]
  • Edit-counter pie chart for self use: I have been able to use the WikiChecker tool, but only for my own username and only with the default 500-edit analysis. For a user named "Axx" checking self:
When I tried to request an analysis of "1000" edits, it gave an error message, but at least it had given the pie chart for my recent 500 enwiki edits. -Wikid77 14:55, 9 February 2012 (UTC)[reply]

Transparent PNGs used for math formulas unreadable on black background

Math formulas created using Wikipedia's markup look fine on a white or light-colored background, but are virtually unreadable on browsers which are using a black background. This is because they are turned in to PNGs with black fonts (with a very faint gray outline) on a transparent background.

Examples:

Original image

What it looks like on a white background

What it looks like on a black background

The only solution I can think of to this that accomodates users who browse Wikipedia with a browser configured to use a black background is to make all math PNGs use a white or light-colored background by default.

Using PNGs with transparent backgrounds but any fixed color for the foreground is a recipe for trouble. -- noosphere 12:49, 9 February 2012 (UTC)[reply]

First of all, your lookpic.com links are HTTP 403. Please, point to a page in Wikipedia where such formulas on the black background may have some use. Even if it exists, a workaround for a particular task may be found easier than to accommodate some changes to texvc. Incnis Mrsi (talk) 13:26, 9 February 2012 (UTC)[reply]
403 for me as well. Some readers prefer a black background, such as can be enabled with Preferences → Gadgets → Use a black background with green text on the Monobook skin. If we switch to Monobook and enable that gadget, then we would probably see the issues. ---— Gadget850 (Ed) talk 13:39, 9 February 2012 (UTC)[reply]
That gadget includes the appropriate workaround: img.tex { background: white; }. You can preview the gadget by adding useskin=monobook&withCSS=MediaWiki:Gadget-Blackskin.css to the url, e.g. [2]. Anomie 13:58, 9 February 2012 (UTC)[reply]
I might not call this workaround an appropriate one. White bars with black glyphs are definitely better than black glyphs on black background, but this does not yet fit to the green-on-the-black style. File a bug to bugzilla: to permit custom foreground in WP:texvc. Not only green and white foregrounds can be used, but possibly also a blue one, to place hyperlinks on formulas. Incnis Mrsi (talk) 15:12, 9 February 2012 (UTC)[reply]
Sorry about the 403 error. Hopefully the following imageshack links will work: white bg, black bg. As for your request to see "a page in Wikipedia where such formulas on the black background may have some use," that would be any page with a math formula! For example, the formulas on the Wikipedia article on Mathematics look pretty much like the ones I linked to above: virtually unreadable to someone viewing the article with a browser configured to use a black background. -- noosphere 16:58, 9 February 2012 (UTC)[reply]