Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Patton123 (talk | contribs) at 13:54, 16 June 2010 (→‎Remove the editing bar when not editing please: new section). 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 
Shortcuts
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.

Vector issues

{{Link FA}} and {{Link GA}} look horrible in Vector

It's simply uncommon to have bullets there, and with Link GA, there's whitespace visible within the icon. I think this template needs a redesign for Vector. --The Evil IP address (talk) 14:55, 4 June 2010 (UTC)[reply]

Why is the Link GA code using an image with a white background in the first place. Doesn't seem very handy :D —TheDJ (talk • contribs) 15:52, 4 June 2010 (UTC)[reply]
File:Monobook-bullet-star.png and File:Monobook-bullet-ga.png should both be changed to have transparent backgrounds. They should probably be vectorized, too. Algebraist 16:44, 4 June 2010 (UTC)[reply]
Yeah, someone whip up an SVG version of the two? Also, on Vector, I think that perhaps more padding should be added between the images and the text, similar to how it is on Monobook. It seems too squished at the moment. Gary King (talk) 16:59, 4 June 2010 (UTC)[reply]
I'm not sure we should actually use bullets in Vector. Since the developers have removed them in there, it looks unusual to see them there. However, I must admit that I have no better idea what to do instead. --The Evil IP address (talk) 18:10, 4 June 2010 (UTC)[reply]
To avoid an unnecesary work to whoever is making the new images, is in discussion if it's right to use Link GA or not --by Màñü飆¹5 talk 02:16, 8 June 2010 (UTC)[reply]
One possible option is to have the stars on the right, see example here in ruwiki. — AlexSm 14:33, 9 June 2010 (UTC)[reply]
Chinese Wikipedia has also put it on the right, See here.--DS - fax 09:56, 13 June 2010 (UTC)[reply]

Internet explorer and table height

It seems that Internet explorer doesnt recognize style="height:100%;" for tables. Is there a way to get around this? just-emery (talk) 17:55, 10 June 2010 (UTC)[reply]

You could stop using Internet Exploder. Other than that, I don't know. IE doesn't support a lot of html stuff. —fetch·comms 21:21, 12 June 2010 (UTC)[reply]
Way ahead of you. Lemmiwinks2 (talk) 03:06, 13 June 2010 (UTC)[reply]

Question on sitenotice

Is it possible to selectively display the sitenotice for unregistered users: visible only in edit mode and in namespaces other than main, file, portal, category and book ? Failing that can the sitenotice be showed to anonymous users only in edit mode, or somehow a message in the same place using the editnotice system ? The idea is to show a message to all registered users (which can be done with the sitnotice for registered users) and unregistered editors, though not all readers. Or do we need developer intervention ? This would be for the pending changes trial. Cenarium (talk) 01:59, 12 June 2010 (UTC)[reply]

I don't think that is possible without some Javascript, or making actual changes to the PHP code. —TheDJ (talk • contribs) 02:01, 12 June 2010 (UTC)[reply]
Cenarium. You may be looking for editnotice. Parser Functions may be useful. – allen四names 02:34, 12 June 2010 (UTC)[reply]
The notice should be displayed at the place of the sitenotice to unregistered users when editing. I don't know how to do that with the editnotice system. Cenarium (talk) 16:59, 12 June 2010 (UTC)[reply]
What does "at the place of the sitenotice" exactly imply?
IP detection in editnotices is possible through {{REVISIONUSER}}. Proper version can probably be built with some iffy Category:string manipulation templates use. Poor man's version is
{{#ifeq: {{lc:{{REVISIONUSER}}}} | {{uc:{{REVISIONUSER}}}} | is IP | is not IP}}
which will have some false positives, but should suffice.
Amalthea 22:10, 12 June 2010 (UTC)[reply]
An alternative would be to use MediaWiki:Anoneditwarning. Killiondude (talk) 22:20, 12 June 2010 (UTC)[reply]
I mean at the position of the sitenotice, above the tabs, I tried with position:fixed on the testing wiki on the Anoneditwarning and the editnotice, the text appears but links don't work, so it seems it can't be done. Though the message can be placed right above the Anoneditwarning, as here. To display the message on talk pages, we could also use Mediawiki:Talkpageheader, but likewise it would be below the tabs, not above. Cenarium (talk) 01:10, 13 June 2010 (UTC)[reply]

Browsers crashing upon accessing Wkipedia main page (en.wikipedia.org)

All browsers netscape 7.0 and mozilla in Solaris and Linux are crashing upon accessing Wikipedia main pages as of yesterday. Wikipedia can now be accessed only through Windows browsers (i.e., Windows Explorer, etc.). —Preceding unsigned comment added by Vescalant (talk • contribs) 04:17, 12 June 2010 (UTC)[reply]

Reported as bugzilla:23926 by someone else. Voted "normal" (!!!!) This is a total crash bug (should be marked "serious") caused by a recently added javascript that is not integral to the look of the site, possibly the new edit menu which presumably uses updated drop-down graphics and whatever. This is a huge problem for those of us who have it.
Observation: Turn off javascript and the page (including new skin and edit functions) loads fine on Netscape, although the script causing the problem probably turns on and off some pop-up menus that wouldn't work on those broswers anyway and should therefore have a global browser test for those scripts.
Vector (is that the name of the new skin?) also looks fine with javascript turn off, so the source of the crash one of the controllers for a special feature that only recently got ported over in the last week or two, AFTER the new skin was implemented, since the skin is not the source of the crash, a Wikimedia script is.
I believe the problem is a javascript controller (perhaps for the advanced edit features?) since it started on Wikimedia, then all Wikimedia pages using Vector beta, started crashing older browsers when they hit the same script, and when the new skin has imported to the main site, it initially worked just fine on older browsers. up till the past week or day or so. While only a "small number" of people have older (2004) browsers, this renders Wikipedia completely inaccessible to them.
The site still works on Netscape 7 when javascript is turned off, it only turns off the advanced edit menu, and such things, one of which is presumably the source of the error. So this seems like a fixable bug even if the fix is to revert to monobook for those (of us) users, or simply tell the browser to ignore the script in question.
I don't yet have a logon id (although I plan to, but why take the trouble if the site is inaccessible to me on my regular computer?) but people shouldn't have to log on to a site that they can't access in order to submit a bug report or set their preferences to traditional view.
At the very least, set the default skin to monobook for all older browser users until the problem is fixed.
Although I think the problem is easily fixable since it's not inherent to the new look. And fixing the problem would fix the problem for Wikimedia too, which has been crashing the same pages on selected features that used Vector beta since last fall. Sincerely, --berr 216.15.63.67 (talk) 05:00, 13 June 2010 (UTC)[reply]
Almost all bugs are 'normal'. Serious and critical bugs are bugs that affect ALL users. This problem affects just 0.2% or something of our audience. The most significant problem with fixing this issue, is probably going to find the hardware to test it on. It may take a while. —TheDJ (talk • contribs) 12:06, 13 June 2010 (UTC)[reply]
Wouldn't it be a browser (software) issue? The problem can be fixed, at least temporarily: set the default layout to "monobook" for all those of us users in question who are on older browsers.
You could even display the current layout on older browsers by telling older browser users to ignore javascript emanating from Wikimedia, which should cause the new Vector layout (is that what it's called?) to display and function normally, with perhaps some minimal loss of functionality.
I would recommend either approach as a quick and easy stopgap. (my case I investigated a little bit by turning javascript off, thereby causing the new layout to display and edit normally).
If you want, you (or whoever knows) can post the global javascript files on the bugzilla page (the ones that every page calls), and I can run them thru the javascript console on my older browser (on an example of older hardware in question) and let me know what to look for.
(i.e. assuming every page is now calling a Wikimedia gadget that older browsers can't read, since the Wikimedia pages that use Vector were already crashing said browsers, whereas the new skin was not crashing said browsers until some script or other got ported over recently from Vector beta). That might help you diagnose? Thanks, --berr 216.15.63.67 (talk) 15:39, 14 June 2010 (UTC)[reply]
Yes it is a browser problem. The issue is much more complicated than that however. Non registered users all get exactly the same version of the HTML. There is no way around that, as we would have to increase the number of servers multiple times. We can also not work around this issue with Javascript, because it is the javascript FILE that makes the browser crash, not the executing of the Javascript code. But I and Roan have spent multiple hours on this problem today, and it seems as we might have found a workaround for the problem. The solution however also needs to be tested on the other 99.8% of the browser market, so it will take a little more time to verify that our fix won't break anything else. All aside, old browsers have an end of life, especially when they tend to crash. Consider upgrading to SeaMonkey or if you are on MacOS 9, Classila. —TheDJ (talk • contribs) 17:09, 14 June 2010 (UTC)[reply]

This issue should now be fixed. —TheDJ (talk • contribs) 21:24, 14 June 2010 (UTC)[reply]

Slow Wikipedia Connection

I don't know if this issue belongs here. I've noticed in the last few months that Wikipedia has slowed down. I'm not sure whether it dates from the user interface changes. In particular, I notice more instances where my (Firefox) status bar says it's "waiting" or "connecting," even some instances where it is unable to connect before timing out. Wikipedia (for me) used to be very crisp and quick. I'm wondering if this is a problem others are experiencing (whether they are editors like me or just plain users) and, if so, whether the problem is being addressed.

(If there's a better place to have this discussion, please tell me.)--Bbb23 (talk) 16:40, 12 June 2010 (UTC)[reply]

Does this happen even when you are logged out? Do you have some non-standard preferences like <math> formatting or default image size? This can affect page loading time, because each page is cached, but only for the combinations of preferences that visited it recently. But the slowdown should be noticeable only on very big or complex pages. Svick (talk) 22:05, 12 June 2010 (UTC)[reply]
I'm pretty much logged in all the time. I could try it at work where I don't log in at all. As far as I can tell, I have no non-standard preferences (I looked). The problem isn't transferring data (meaning the size of the data - I have a very fast connection, at least 10Mbps) - it's the length of time Wikipedia takes to respond at all, implying that Wikipedia is the problem. Although it doesn't happen all the time, it happens with some regularity.--Bbb23 (talk) 22:13, 12 June 2010 (UTC)[reply]

Safari 5.0, monobook skin, my watchlist

Howdy all. I recently updated from Safari 4.x to 5.0. I use Windows XP SP 3. After the update, anytime I have the monobook skin selected, and try to view my watchlist in Safari 5.0, I get a message from Windows saying that it needs to close Safari due to an error. It also happens on occasion when I just try to bring up the main page. I used to have code in my monobook.js, but I emptied it out, refreshed, and even emptied Safari's cache. The error still comes up. A portion of the error message can be seen here. I tried to pastebin the error report contents, but it won't let me copy/paste. I tried using this link, and still got the error. So far, I can browse perfectly fine when logged into my RockfangBot account. I'm about to try reinstalling java. I asked in the help chat room, and they suggested I bring it up here. If anyone has any advice, please share. :) Rockfang (talk) 21:33, 12 June 2010 (UTC)[reply]

If your Safari crashes, it is a bug in Safari, not Wikipedia's fault. You could report it to Apple: have a look at the Safari support site and maybe this topic. Svick (talk) 22:12, 12 June 2010 (UTC)[reply]
Thank you for replying. I understand that at least part of the blame is in Safari, but this error only has shown up for me while using wikipedia. I've tried a number of other websites. I will try the second link you provided. Thank you.--Rockfang (talk) 22:45, 12 June 2010 (UTC)[reply]
First of all, JAVA and JavaScript are totally not related, so reinstalling JAVA will definetly not help you. Beyond this, I have no idea. I think it is a bug in Safari windows and Apple probably will have to take care of it. —TheDJ (talk • contribs) 22:53, 12 June 2010 (UTC)[reply]
Thanks for the tip. I understand they aren't the exact same thing. My purpose in sharing that information was to provide steps that have already been taken.--Rockfang (talk) 00:22, 13 June 2010 (UTC)[reply]
For what it's worth, Safari 5 on OSX 10.6 loads both my watchlist and the main page without error. I also tried the Windows version on XP SP3 (virtualized) and had no errors, so it may be something with your particular installation. —DoRD (talk) 13:58, 13 June 2010 (UTC)[reply]
Thanks for replying. I tried repairing, and remove and reinstall, but it still happens. And only on wikipedia. I guess I'll just wait until an update comes out for Safari and hopes that fixes it.--Rockfang (talk) 17:54, 13 June 2010 (UTC)[reply]
You could try asking at Wikipedia:Reference desk/Computing: someone there might have some advice. Gwinva (talk) 02:11, 16 June 2010 (UTC)[reply]

Drop down menu underneath edit summary

First, if you could solve this problem it would be greatly appreciated. Second, I did a quick search through the Pump technical archives but didn't find anything that addresses this problem. This could partly be, because I wouldn't know what the title is of such a problem or how it would be described, except as I might describe it here.

Third, I went to Bugzilla, but I am not inclined to give my email address as it appears that email addresses will be visible to the public. And I don't have a secondary account or free web email service because I wouldn't use it on a regular basis. OK now the problem...

When I try to enter a character into the edit box using the drop down menu underneath the edit summary, instead of entering the character, the entire page rapidly scrolls (or jumps) to the top of the article. Alongside the drop down menu is a set of characters that comes with each setting. The settings are titled: Insert, Wiki-markup, Symbols, Latin, etc. etc. It is when I click on any one of these characters that the entire page rapidly scrolls upward, actually to the title of the article. This happens instead of entering the character into the edit box, as part of the article being edited. Thanks in advance for looking into this ----Steve Quinn (talk) —Preceding undated comment added 00:18, 13 June 2010 (UTC).[reply]

Yes this is a known issue. I will fix it later in the week, it requires some coordination with the developers in order to repair this problem properly. —TheDJ (talk • contribs) 11:58, 13 June 2010 (UTC)[reply]
I have the same problem and will add two details. 1. The same problem occurs with ~~~~ and <ref></ref>. 2. The problem occurs with Internet Explorer 7.0, but all these insertions work correctly with Firefox 6.0. Dirac66 (talk) 22:44, 13 June 2010 (UTC)[reply]
I am glad this is a known issue, and can be fixed. BTW I am in no rush, I have been working around it, and can continue to do so. Perhaps, I should have mentioned that I have Internet Explorer 7.0. Thanks for your responses. ----Steve Quinn (talk) 00:38, 14 June 2010 (UTC)[reply]
This is being tracked as one of the issues at Template:Bugzilla but may have been mentioned in other bugs as well, as it comes up at Wikipedia:Requests for comment/May 2010 skin change/Bug reports‎ in a variety of contexts. ~ Ningauble (talk) 00:40, 15 June 2010 (UTC)[reply]
OK now for me on IE 7.0 and WinXP Home. Thanks. Dirac66 (talk) 01:45, 16 June 2010 (UTC)[reply]

Bugzilla question

How do I relate the information in a Bugzilla report to the real world? If I look at http://www.mediawiki.org/wiki/Special:Code/MediaWiki/64726 it shows that a bug I am desperate to see fixed, https://bugzilla.wikimedia.org/show_bug.cgi?id=22474 is included. If I look at WP:About, it shows that we are running r66620. Silly me: I would think that since 66620 is bigger than 64726, we'd already have the fix. Alas, no. How do I find out when we will?—Kww(talk) 06:35, 13 June 2010 (UTC)[reply]

Wikimedia does not always run the latest version of the software. It runs the software that is in the WMF branch, specifically the 1.16wmf4 branch. The number you see in About, refers to the latest revision that was deployed from that specific branch. Almost all changes are made initially in trunk. When a change is prioritized and copied to the branch, this is usually listed BELOW the revision diff in the CodeReview system. See for instance this revision. At the bottom it says that this revision was copied to 1.16wmf4 in a 2nd revision (67753). —TheDJ (talk • contribs) 11:50, 13 June 2010 (UTC)[reply]
P.S. in this specific case, i would call this change a new feature. It is for the 1.17 release (1.16 is almost final now, but not yet released). That means that before you see this on Wikipedia, probably a few more months will pass. —TheDJ (talk • contribs) 11:53, 13 June 2010 (UTC)[reply]

Line through Image

Hi Everyone, I’m relatively new to editing Wikipedia, and I think I’ve run into a site-wide problem already (sorry). I’ve made extensive changes to the Burnley page, including nesting the infobox in a single column wikitable to create an easy to manage vertical image gallery. While (I think) it works well, I’ve run into the following problem: The section lines run through the images from the third section onwards (even though the edit link is in the correct place). The one tiny reference that I was able to find, leads me to think that a change may be required to common.css which I can’t do myself.

Any suggestions? (Apologies if I’ve missed something obvious). IE8 on Win7 pro 

--Trappedinburnley (talk) 13:22, 13 June 2010 (UTC)[reply]
This looks similar to Template:Bug. Svick (talk) 14:00, 13 June 2010 (UTC)[reply]

I agree, sort of (IE dosn't seem to want to let me turn on compatibility view for wikipedia, and switching to monobook didn't seem to do much either). I've installed Firefox and it's fine, so if this is limited to ie8 I care a fair amount less. --Trappedinburnley (talk) 14:53, 13 June 2010 (UTC)[reply]

help with titleparts

There's an unfortunate piece of strange behaviour at musicline.de: it expects internal "/" characters to be encoded with %A5. I built a template to compensate for it at {{singlechart/germanencode}}. It works fine, with one nasty glitch: it outputs an extra space at the end of the string. There's a simple test case at Template talk:singlechart/germanencode that demonstrates. That extra space is fatal: it breaks the URL in the caller at the wrong place. I can't figure out where the space comes from. Can anyone else?—Kww(talk) 16:17, 13 June 2010 (UTC)[reply]

Fixed it. Don't know how, but it's repaired.—Kww(talk) 16:30, 13 June 2010 (UTC)[reply]

Mysterious Wikipedia traffic drop

I'm noticing a rather steep drop in Wikipedia traffic lately, e.g. for the EN main page (http://stats.grok.se/en/201006/Main_Page). Other projects like WP-DE show the same trend (http://stats.grok.se/de/201006/Hauptseite). What's going on, is the stats tool broken or is this real? And what is causing this decline? Morn (talk) 10:05, 14 June 2010 (UTC)[reply]

School is out for the summer? —DoRD (talk) 13:16, 14 June 2010 (UTC)[reply]
Maybe, or is it due to the Soccer World Cup? (Since the drop is the same on the German Wiki.) I think WP also had a minor technical glitch on the 11th, but hopefully that's been fixed... Morn (talk) 13:20, 14 June 2010 (UTC)[reply]
P.S. I also notice that last year around this time, there was no drop in viewership. So it can't be the schools. The WP main page always seems to get millions of hits daily, no matter what time of year. Even on Dec. 25th, 2009 there were 3.1M hits! That's about as low as it goes normally. Morn (talk) 13:25, 14 June 2010 (UTC)[reply]
Looks like it's a technical issue with the stats tools after all, see User_talk:Henrik#Stats_drop-off_question. Hopefully the stats will be back to normal tomorrow. Morn (talk) 13:34, 14 June 2010 (UTC)[reply]
Good. I've been wondering about this as well; it's good that we have an answer. A pity that Henrik isn't really around anymore to help with this sort of thing. Nyttend (talk) 17:33, 14 June 2010 (UTC)[reply]
Yeah, i figured it had to be a problem with the stats tool because the Google Insights shows no equivalent change on topics such as Lady Gaga (compare with Google Insights), Barack Obama (compare with Google Insights), Eckhart Tolle (compare with Google Insights). Gregcaletta (talk) 04:16, 16 June 2010 (UTC)[reply]

"Maximum" function for comparison

Hey folks,

Got a bit of a tricky problem at {{multiple image/sandbox}}. I need a way to find the greatest value out of ten different possible widths. Comparing them one by one doesn't seem to work, and this is backed up by the suggestion in {{max}} that it only works for a maximum of three different values. Is there an obscure parser function which might work here, or does anyone have any suggestions? The present code (which errors out unless exactly 10 widths are given) is as follows: 

| vertical   = {{#expr:{{#if:{{{width|}}}|{{{width}}}|{{#ifexpr:{{{width10|}}}>{{{width9|}}}|{{{width10}}}|{{#ifexpr:{{{width9|}}}>{{{width8|}}}|{{{width9}}}|{{#ifexpr:{{{width8|}}}>{{{width7|}}}|{{{width8}}}|{{#ifexpr:{{{width7|}}}>{{{width6|}}}|{{{width7}}}|{{#ifexpr:{{{width6|}}}>{{{width5|}}}|{{{width6}}}|{{#ifexpr:{{{width5|}}}>{{{width4|}}}|{{{width5}}}|{{#ifexpr:{{{width4|}}}>{{{width3|}}}|{{{width4}}}|{{#ifexpr:{{{width3|}}}>{{{width2|}}}|{{{width3}}}|{{#ifexpr:{{{width2|}}}>{{{width1|}}}|{{{width2}}}|{{{width1}}}}}}}}}}}}}}}}}}}}}}}+12}}

Chris Cunningham (not at work) - talk 11:20, 14 June 2010 (UTC)[reply]

How about nesting the maxes? {{max|1|{{max|{{max|2|3|4}}|{{max|5|6|7}}|{{max|8|9|10}}}}}} seems to work. --McGeddon (talk) 12:10, 14 June 2010 (UTC)[reply]
Awww yeah. Perfect. Cheers! :) Chris Cunningham (not at work) - talk 12:25, 14 June 2010 (UTC)[reply]

Error when trying to edit or compare edit differences on article

Article in question is List of Wales national rugby union players and it is eventually going to a blue Wikimedia Foundation error page with the following error in various languages:

'Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes.'

Whilst it's a fairly long page, there are others that are longer and which don't have the problem, and it used to work fine before. I'm on IE, and this error has happened on numerous occasions over the last week or so. Please note I also posted this query to the relevant WikiProject page but no response yet. [1] Eldumpo (talk) 21:00, 14 June 2010 (UTC)[reply]

A server error isn't going to be IE's problem. I'd fancy that this is a temporary glitch; it's working fine here now. Chris Cunningham (not at work) - talk 21:27, 14 June 2010 (UTC)[reply]
It's still not working for me, and when I try and compare edits it takes ages to load and then eventually comes up with the error page. Is anyone else having problems, else it's something to do with my settings? Eldumpo (talk) 07:21, 15 June 2010 (UTC)[reply]
It's certainly taking a stupidly long time to load. I would hazard a guess that this might be due to the thousands (literally) of {{dts}} templates and the like it transcludes. It's not something you're doing; it's a server-side problem. Chris Cunningham (not at work) - talk 08:53, 15 June 2010 (UTC)[reply]
I've encountered similar errors when trying to edit extremely long sublists of United States National Register of Historic Places listings, such as National Register of Historic Places listings in Denver, Colorado before we split it into several pieces for navigability purposes. The page is simply so long and so complex, with so many templates, that the server has trouble processing the edit or loading the page or something like that. Nyttend (talk) 13:54, 15 June 2010 (UTC)[reply]

Collapse option seems dead?

I've noticed that all the templates depending on some code to allow for collapsing are not collapsed. There must be something wrong with the behind-the-scenes code, but I'm not qualified to fix it, let alone identify it. Can this be fixed? upstateNYer 23:23, 14 June 2010 (UTC)[reply]

Sorry, my mistake. Fixed now. I tested it, but apparently the change hadn't propagated to all the servers yet. —TheDJ (talk • contribs) 23:28, 14 June 2010 (UTC)[reply]
Thanks, was noticing the same problem Tommy2010 [message] 23:51, 14 June 2010 (UTC)[reply]
Yeah sorry for the disruption. I was catering to our Internet Explorer users trying to fix the bugs with the bottom inserttools and a few other elements in the new Vector interface. Path of avoidance of these kinds of problems is in my opinion blocking access to all Internet Explorer users and telling them to get a proper browser. I now spent 1 month on this issue, and if it still doesn't work after all this, i'm gonna be very angry with my IE voodoo dolls, they will not survive. —TheDJ (talk • contribs) 23:54, 14 June 2010 (UTC)[reply]
Surprised people still use IE.... Chrome's the way to go! Tommy2010 [message] 00:04, 15 June 2010 (UTC)[reply]
I was wondering why the collapse boxes didn't work in Firefox. Bypassing the cache worked. —MC10 (T•C•GB•L) 01:18, 15 June 2010 (UTC)[reply]

Monobook insert characters dropdown

Is the insert characters dropdown no longer supported for Monobook? -- I haven't changed to Vector because I dislike the new format, but today I've found the insert characters dropdown is replaced by a limited list of items which require copy and paste, thus making it much slower to edit using special characters such as en rules. Espresso Addict (talk) 01:01, 15 June 2010 (UTC)[reply]

It has been fixed again. I think it was temporary. —MC10 (T•C•GB•L) 01:34, 15 June 2010 (UTC)[reply]
Still not working for me :( Espresso Addict (talk) 01:42, 15 June 2010 (UTC)[reply]
Seems to be fixed now. Excellent, thanks! Espresso Addict (talk) 17:34, 15 June 2010 (UTC)[reply]
  • Not working for me. Monobook, Chrome, WinXP. DuncanHill (talk) 13:12, 15 June 2010 (UTC)[reply]

Diffs out of order

I discovered a glitch while tinkering with the MediaWiki API. This diff appears out of order relative to other diffs. Notice that the "previous" edit is a year later than the "current" diff. The timestamps appear to be correct -- the 2001 version is clearly an earlier revision than the 2002 version -- it's the revision id which seems wrong. I understand the revid to be sequential in time, but is not in this case, and it seems that also messes up the diff view. If you traverse backwards in diffs, the revids decline as they should, but that one diff appears to be out of place.

Does anyone know if this is a bug with the software, or perhaps some database glitch from the early days? Should I report it to MediaWiki as a bug? ATren (talk) 03:50, 15 June 2010 (UTC)[reply]

If I recall correctly, some time in the distant past numerous old revisions were lost. Some of them were later restored somehow, but with new IDs. That's why the ID of the oldest revision is greater than those that come after it. Hopefully someone more familiar with MediaWiki and the history of Wikipedia can provide some more information on what happened. Reach Out to the Truth 04:08, 15 June 2010 (UTC)[reply]
This is mostly correct. Some revisions were lost, but still present on http://nostalgia.wikipedia.org. It took years, but now these old 'missing' changes can be imported into wikipedia, to restore history sort of speak. The only problem is the effect noticed by ATren. I don't believe it is possible to fix this. —TheDJ (talk • contribs) 10:18, 15 June 2010 (UTC)[reply]
OK, thanks, that makes sense. The software doesn't seem to handle it too well, but I'm not sure if that can be fixed. The assumption in the software seems to be "sequential revid == forward in time", but that's clearly not true in these diffs. The MediaWiki API also makes that assumption, because the continuation parameter of API queries returns the next revid even for timestamp queries (that's how I found this glitch). To work around this glitch, the API should return a timestamp-based continuation, not a revid-based one. In any case, it's not a major concern for me; I can work around it. I just wanted to get some input from others. Thanks. ATren (talk) 11:51, 15 June 2010 (UTC)[reply]
The diff linked above does not contain an edit that was imported from the Nostalgia Wikipedia. About 90% of edits from 2001 were imported in September 2002, and hence their revision ID's indicate that fact; see Wikipedia:Usemod article histories. Graham87 06:34, 16 June 2010 (UTC)[reply]
I've also imported an edit from the Nostalgia Wikipedia to Eiffel, to make things more interesting. :-) Graham87 09:03, 16 June 2010 (UTC)[reply]

Languages panel title tooltip for links

Languages panel links in the left navigation panel currently dont have tooltip (also called alt text or title) which show up on mouseOver that link. But all the links in wikipedia article show the title of linked article as that tooltip. Same feature should be implemented in language panel links too which are very helpful to see the title of the different language article. Currently the article title shows up in status bar of the browser, but that is full url not only title. So showing up target article title will look beautiful and consistent with wikilinks in the article beside. Noted trip3 (talk) 08:56, 15 June 2010 (UTC)[reply]

For example see article India where wikilinks in article show tooltip when mouse pointed over link, while same page when mouse pointed on other language links on left navigation panel tooltip doen't show up. Noted trip3 (talk) 09:02, 15 June 2010 (UTC)[reply]
I have implemented this change in revision 68079 of the software. It will take a few months, before you will see it in wikipages probably. —TheDJ (talk • contribs) 15:09, 15 June 2010 (UTC)[reply]

Vector & Pending Changes

I see from press releases, that people will directed to a "small magnifying glass" "on the upper right corner of the article". Now I'm sure I'm not the only one who noticed that there's already a magnifying glass there for the Vector search. Now we'll have two different star icons and two different magnifying glass icons, all in the top right, all meaning different things.

Who should be complained at more, the "usability" team or the Pending Changes people? OrangeDog (τ • ε) 12:18, 15 June 2010 (UTC)[reply]

This was only finally changed yesterday, I believe. Not entirely sure what the purpose was. I guess a lock conflicts with the "open" idea Pending Changes. But yeah, you are right, this isn't optimal either. —TheDJ (talk • contribs) 12:31, 15 June 2010 (UTC)[reply]
Yeah, it's got pages behind it, this one. And its own box, with accompanying text, not sure how confusing it would be a casual visitor. I would say probably little impact though, as long as PC remains only on a handful of pages. If we see an expansion, then maybe not. - Jarry1250 [Humorous? Discuss.] 14:07, 15 June 2010 (UTC)[reply]

Problem with pop-ups and en-dashes

When a page title contains an en-dash (an obscure and untypeable symbol beloved of the MoS), pop-ups shew the page as empty. DuncanHill (talk) 13:00, 15 June 2010 (UTC)[reply]

That is because Internet Explorer is not supported in Navigation popups. —TheDJ (talk • contribs) 15:10, 15 June 2010 (UTC)[reply]
Who said anything about IE? I use Chrome. DuncanHill (talk) 17:21, 15 June 2010 (UTC)[reply]
Exactly, if you don't say things, I start making assumptions :D —TheDJ (talk • contribs) 17:32, 15 June 2010 (UTC)[reply]
That may be true, but as I have pointed out before, it is not the only case. I don't know why it can't be reproduced, but I have still problems in Chrome with en-dashes; hovering over List of Pokémon (341–360) shows a page title of List of Pokémon (341–360) and content as empty. I can usually view a diff in a popup for similarly titled pages, but not the history or the page itself. —Ost (talk) 16:49, 15 June 2010 (UTC)[reply]
Well I cannot reproduce that issue, so I cannot help you. Perhaps someone else can find the problem ? —TheDJ (talk • contribs) 17:32, 15 June 2010 (UTC)[reply]
In case anyone is reading here and not at WT:POP, it appears that the gadget causing conflicts with popups is the final one for JavaScript compatibility; disabling fixes en-dashes in Chrome for me. —Ost (talk) 20:51, 15 June 2010 (UTC)[reply]
Fixes it for me too, thanks Ost. DuncanHill (talk) 22:29, 15 June 2010 (UTC)[reply]

'MY' character set

I can't get pages on my.wikipedia.org, like http://my.wikipedia.org/wiki/%E1%80%90%E1%80%AC%E1%80%B7%E1%80%82%E1%80%BB%E1%80%BA%E1%80%99%E1%80%9F%E1%80%AC%E1%80%9B%E1%80%BA, to show; nor the transwiki links on en.wikpeida in that language. What font/ character set do I need to install? (I'm using various browsers under Windows XP) Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:15, 15 June 2010 (UTC)[reply]

See Malayalam_script and Help:Multilingual_support_(Indic). —TheDJ (talk • contribs) 15:16, 15 June 2010 (UTC)[reply]
See this link: http://my.wikipedia.org/wiki/Wikipedia:Font It has links to free fonts at the end of the page. Morn (talk) 15:19, 15 June 2010 (UTC)[reply]
A good first step to extend font coverage is to install Code2000. It covers a range of things you will encounter, including Myanmar. It is not however (let me point this out before I get hit over the head ;-) the best font for a number of languages, and some people think, with some reason, that parts of it are fairly ugly. One can install it, and then look for specific fonts for languages to improve the presentation if needed. (for some ideas on preferred fonts, see wikt:MediaWiki:Common.css where we set default preferences for the wiktionary, for example Mymr is Padauk, Myanmar3, Myanmar2, Myanmar1, ParabaikSans, MyMyanmar) Robert Ullmann (talk) 17:24, 15 June 2010 (UTC)[reply]

Template:Alr

I recently created Template:Alr (ALR = "Article Length Rating") for use with WP:NRHP and really anyone else that wants to use it. It gets the size of an article and rates it on a 0-10 scale based on the size of the article. We use it for our new articles to see which ones could use more work, and which ones are satisfactory. I just added the template to Wikipedia:WikiProject National Register of Historic Places/New articles/2009, and I've run into an issue. Because the template uses the {{PAGESIZE}} parser function, when many of them are transcluded on a single page, it breaks the limit and puts the page into Category:Pages with too many expensive parser function calls.

The only way around this is to either not transclude as many times on the same page or optimize the code to use less expensive parser functions. Currently it uses {{PAGESIZE}} twice – once to see if the length is more than 20,000 bytes (in which case the article receives a "10" rating), and once more to rate the article if it isn't a 10. My question is can this code be optimized to only call {{PAGESIZE}} once? The code is copied below: 

[[File:{{#ifexpr:{{PAGESIZE:{{{1|}}}|R}}<20000|{{#expr:floor(({{PAGESIZE:{{{1|}}}|R}})/2000)}}|10}}von10ggr.png]][[{{{1}}}|{{{2|{{{1}}}}}}]]

Thanks!--Dudemanfellabra (talk) 20:20, 15 June 2010 (UTC)[reply]

You seem to have a reasonable range of values. You could try a #switch instead, like so:
{{#switch:{{#expr: trunc({{PAGESIZE:{{{1|}}}|R}}/2000)| 15 }}
 | 0 = 0
 | 1 = 1
 | 2 = 2
 | 3 = 3
 | 4 = 4
 | 5 = 5
 | 6 = 6
 | 7 = 7
 | 8 = 8
 | 9 = 9
 |#default=10}}

There's probably a mistake somewhere in there; I look back when I'm not in a hurry. Intelligentsium 20:58, 15 June 2010 (UTC)[reply]

Found the error (shouldn't have truncated the second time). This does have the minor disadvantage of changing your layout, however: the rating scale will be 0-1,999; 2,000-3,999; and so forth. The 15 is an arbitrary large number to make sure all the decimals are gone, because I don't remember at the moment the place at which #expr rounds. Intelligentsium 21:05, 15 June 2010 (UTC)[reply]
Ah, awesome! I didn't even think about using #switch. I used a different variation though.. I stuck with "floor" instead of "trunc" (code below), which works the same way. No problem with changing the limits; I'll just update the doc. I was wondering what you were doing when you were truncating a second time haha.. here's the code I ended up using:
{{#switch:{{#expr:floor({{PAGESIZE:{{{1|}}}|R}}/2000)}}|0=0|1=1|2=2|3=3|4=4|5=5|6=6|7=7|8=8|9=9|10}}
Unfortunately, this still doesn't save the 2009 page from the category. Apparently there are over 500 template calls on the page anyway, so it still brings up an error. Thanks for your help! --Dudemanfellabra (talk) 21:26, 15 June 2010 (UTC)[reply]

Flagged-revisions menulet rendering bug

The "accepted v" menulet overwrites the GA insignia. This is with the vector skin, with no user-level css or other local modifications. The only nonstandard display setting is that I have the "[edit] for lede section" gadget enabled. DMacks (talk) 00:56, 16 June 2010 (UTC)[reply]

Thanks for reporting this. We have a long-term fix in the works, and we'll see if there are some short-term fixes to improve things for this case. William Pietri (talk) 06:26, 16 June 2010 (UTC)[reply]
Gadget adapted. But this really requires a more sensible approach at some point :D —TheDJ (talk • contribs) 12:50, 16 June 2010 (UTC)[reply]

Editors user group

I noticed something strange in the user rights log; "# (del/undel) 02:52, 16 June 2010 Ser Amantio di Nicolao (talk | contribs | block) changed rights for User:Ser Amantio di Nicolao from Autoreviewers and Reviewers to Autoreviewers, Reviewers and Editors ‎ (autopromoted)" There's a few more, but not many. Going to User Rights management I see the log entry again, and a list of groups this user is in, including "Editors" linking to Wikipedia:Editor... but no check box to modify this right, whatever it is. Special:ListGroupRights also makes no mention of an "editors" group.... so... can anyone enlighten me? Courcelles (talk) 05:05, 16 June 2010 (UTC)[reply]

It's related to the flagged revisions implementation, now known [in doublespeak] as Pending changes. Shadowjams (talk) 05:18, 16 June 2010 (UTC)[reply]
I know about flagged revs, and I've been handing out the reviewer flag like it was day old newspaper, but the editor group was new to me, as was seeing an autopromotion in the logs- when a new user hits autoconfirmed, there's no log entry for that. Is "editor" going to end up superfluous to "reviewer"? Courcelles (talk) 05:23, 16 June 2010 (UTC)[reply]
Oh I'm sorry. You're right. Actually, you assigned me the reviewer flag (thanks :)). Yeah, what is this? Shadowjams (talk) 05:31, 16 June 2010 (UTC)[reply]
Weird. Special:ListGroupRights doesn't list this group. Ucucha 06:13, 16 June 2010 (UTC)[reply]
We currently have four editors. Ucucha 06:30, 16 June 2010 (UTC)[reply]
That is weird. Afaik the only wiki where you can assign yourself rights is en.labs.wikimedia.org. Is this editor right related to the editor right on Wikinews and such-like? {{Sonia|ping|enlist}} 06:38, 16 June 2010 (UTC)[reply]
Perhaps this is a question for Starling, or one of them technical fellas Shadowjams (talk) 06:57, 16 June 2010 (UTC)[reply]
Moved from ANI

Those big "The use of this file is permitted only on Wikipedia." notices

How does one cause one's image to be tagged with the big "The use of this file is permitted only on Wikipedia." that includes an F3 speedy deletion? I always assumed that it was a case of the uploader not providing a license, but File:Sizan Ronaldo.JPG had such a notice despite being tagged at upload with {{GFDL-self}} and {{PD-self}}. Moreover, the same individual had earlier uploaded a similar image with just GFDL-self, but it was deleted because it had the same notice. Nyttend (talk) 13:13, 16 June 2010 (UTC)[reply]

If, under the License option on the upload form, you choose the option that only Wikipedia can use the file, this is automatically applied. The option exists in order to identify the people who are uploading that sort of file so it can be deleted - if the option didn't exist, they would still upload the file, but may choose a license that they didn't actually mean/want/have permission for. Ale_Jrbtalk 13:34, 16 June 2010 (UTC)[reply]

Remove the editing bar when not editing please

When I click on some text while not editing, a flashing bar like you'd see in a word processor, or our edit window, is displayed. Can this be removed? It's annoying and could make people think they can edit the text as-is.--Patton123 (talk) 13:54, 16 June 2010 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=368388514"