Jump to content

Wikipedia:Village pump (technical): Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Alex Smotrov (talk | contribs)
Line 925: Line 925:


:It could be [[User:Ais523/catwatch.js]] called from [[User:Dismas/vector.js|your vector.js]]: it has 1 <code>alert()</code> in the code. Try switching to some other skin or clearing your vector.js. — [[user:Alex Smotrov|AlexSm]] 14:27, 21 July 2012 (UTC)
:It could be [[User:Ais523/catwatch.js]] called from [[User:Dismas/vector.js|your vector.js]]: it has 1 <code>alert()</code> in the code. Try switching to some other skin or clearing your vector.js. — [[user:Alex Smotrov|AlexSm]] 14:27, 21 July 2012 (UTC)

== "My preferences" tabs not working ==

Under "my preferences" none of the tabs across the top :- Appearance, Date and time, Editing etc. are doing anything. No matter which one I select it stays on "User profile". Is this just me, or a general glitch? - [[User:Arjayay|Arjayay]] ([[User talk:Arjayay|talk]]) 14:43, 21 July 2012 (UTC)

Revision as of 14:43, 21 July 2012

 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, 213, 214, 215

Database lag

Rising steadily for the past few hours. Up to 681 seconds now. Equazcion (talk) 10:19, 2 Jul 2012 (UTC)

Any info on when this might be resolved by? Jenks24 (talk) 10:48, 2 July 2012 (UTC)[reply]
It took a minute for the page to load. This is getting out of hand.—cyberpower ChatOffline 11:13, 2 July 2012 (UTC)[reply]
I just saw it go over 800 seconds! Roger (talk) 11:32, 2 July 2012 (UTC)[reply]
Over 900 seconds now. Counter-vandalism editing gets rather hard when it takes more than 15 minutes for an edit to appear in your watchlist... Fram (talk) 11:52, 2 July 2012 (UTC)[reply]
942 seconds now. Editing in general gets hard when your watchlist doesn't want to load.—cyberpower ChatOffline 11:56, 2 July 2012 (UTC)[reply]
If you want the lag message to display minutes/seconds also, I just made a script for that -- see User:Equazcion/LagToMinutes :) Equazcion (talk) 12:02, 2 Jul 2012 (UTC)
It doesn't work right. I'm getting 280000 minutes and 21 seconds.—cyberpower ChatOffline 12:34, 2 July 2012 (UTC)[reply]
1030 1057 1133 seconds....is this a record?--Gilderien Chat|List of good deeds 12:21, 2 July 2012 (UTC)[reply]
Caught is at 1000 even. W0OT! Is the number a 32-bit variable or a 64-bit variable? We wouldn't want an overflow after 9.10194444 hours... :) --Guy Macon (talk) 12:23, 2 July 2012 (UTC)[reply]
It's no record :( Highest I've seen is just over 9,000 seconds (!) Equazcion (talk) 12:27, 2 Jul 2012 (UTC)
Is there a point at which editing will (have to) be shut down to protect the integrity of the database? What are the server geeks saying about the problem? Roger (talk) 12:28, 2 July 2012 (UTC)[reply]
Well toolserver replag (edit counter) is at "4 hours, 24 minutes, 14 seconds" --Gilderien Chat|List of good deeds 12:45, 2 July 2012 (UTC)[reply]
PS. If anyone had tried my script above, it had a bug when the seconds went over 1,000, but it's been fixed now. Equazcion (talk) 13:02, 2 Jul 2012 (UTC)

Operations is now aware of the replication lag problems. They are investigating. You might want to keep an eye on server admin log with regards to resolution of the issue. —TheDJ (talkcontribs) 13:04, 2 July 2012 (UTC)[reply]

It's largely a false alarm, although it does seem to cause very slow loading of watchlists. IIRC there are five database slaves, and only one of the five is actually lagged; the other four are fine, so most of the time you will actually get an up-to-date response from the server. --R'n'B (call me Russ) 13:25, 2 July 2012 (UTC)[reply]
So far every single time I've reloaded my watchlist, the lag message appears accurate. The last change that appears in the list is from the time just before the lag amount showing. Equazcion (talk) 13:28, 2 Jul 2012 (UTC)
(/d) Yes, it's only db12 DB overview. BTW, check infra status to see how many problems operations is dealing with that you are actually NOT noticing as a user. :D Makes you wonder how often they fix stuff and we never even thank them for it. —TheDJ (talkcontribs) 13:32, 2 July 2012 (UTC)[reply]
Hey I'm not complaining. I look at database lags kind of like forced relaxation :) Equazcion (talk) 13:37, 2 Jul 2012 (UTC)
Yes, if I look at my watchlist it only shows changes from about 40 minutes ago. But if I actually load a page it shows the current version, not a 40 minute old version. Looks like the code is written so that Special:Watchlist always reads from the slowest slave. --R'n'B (call me Russ) 13:52, 2 July 2012 (UTC)[reply]
That's the way it always is with database lags. I've never seen the lag actually cause old versions of pages to show up. It just affects the watchlist display (far as I know). Equazcion (talk) 13:54, 2 Jul 2012 (UTC)
"just affects"? Heh, for me, the watchlist is god. Having it work this badly (and it was having problems yesterday, too) is heresy.--Bbb23 (talk) 15:11, 2 July 2012 (UTC)[reply]

Lag reached 1,483 seconds. --Meno25 (talk) 13:36, 2 July 2012 (UTC)[reply]

Is it just me or has this been happening a lot more since WP switched from Godaddy to the new provider? Kumioko (talk) 13:42, 2 July 2012 (UTC)[reply]
I doubt there's any correlation, since that switch only affected who the domains were registered with. Which has absolutely nothing to do with the databases. the wub "?!" 15:46, 2 July 2012 (UTC)[reply]
Agreed was about to say the same thing.—cyberpower ChatOnline 15:53, 2 July 2012 (UTC)[reply]

Loading my watchlist: <!-- Served by mw3 in 30.838 secs. -->

Now 2027 seconds. This could be related? If they are changing the times on all the edits made so far today?--Gilderien Chat|List of good deeds 15:28, 2 July 2012 (UTC)[reply]
I was about to ask if the leap second could have caused this as well.Edinburgh Wanderer 15:42, 2 July 2012 (UTC)[reply]

Update: We now at 36 min. lag and loading the watchlist reports <!-- Served by mw33 in 30.903 secs. -->cyberpower ChatOnline 15:48, 2 July 2012 (UTC) [reply]

The cause is not really known yet. The server is running some scripts to get the last remaining Sha1's of revisions populated, but that should not take that much resources to cause this. Another operations guy should be waking up soon and hope is that he can properly debug the problem. The lag has been going down a bit the past half hour though (without apparent cause). Unfortunately this db server is also serving up all the watch list requests, so it's a bit annoying for the editors. —TheDJ (talkcontribs) 16:04, 2 July 2012 (UTC)[reply]
It's not just lag. Getting many "general error" screens when trying to log in or edit. North8000 (talk) 16:25, 2 July 2012 (UTC)[reply]
(edit conflict) It's not just watchlists that are affected, but contribs lists too. For example, Special:Contributions/Redrose64 shows my most recent edit as being to Cardiff Central railway station at 15:48 UTC, but I'm certain that I've made at least six edits since (to Swansea railway station, Llanelli railway station, Carmarthen railway station, Whitland railway station, Template:POV, User talk:MSGJ). --Redrose64 (talk) 16:26, 2 July 2012 (UTC)[reply]
And page histories are similarly affected/afflicted, too. Bishonen | talk 21:23, 2 July 2012 (UTC).[reply]

Update: Replag decreasing at a rate of about 15 seconds per minute. I estimate 4 hours, 27 minutes, and 44 seconds until replag is cleared at current speed.—cyberpower ChatOnline 17:08, 2 July 2012 (UTC) [reply]

Now lag is 1,255 seconds. --Meno25 (talk) 17:14, 2 July 2012 (UTC) [reply]

Replag down to 10 seconds now. Yay. Now to fix the errors.—cyberpower ChatOnline 19:07, 2 July 2012 (UTC) [reply]

Toolserver replag

OK, up-to-date watchlists and contribs, at l(e)ast(!), which is good; but still an ever-growing replag on the toolserver: What is causing this and why is it not decreasing at all for days? Jared Preston (talk) 17:48, 3 July 2012 (UTC)[reply]
Update: "Caution: Replication lag is high, changes newer than 9 hours, 18 minutes, 10 seconds may not be shown."
Why is the replag getting higher? Does anyone know when/if the server-problem will be fixed in the next few days? Jared Preston (talk) 20:15, 4 July 2012 (UTC)[reply]
No idea what its means but tool server says High replag because of inserting of many SHA1-hashes. Its getting worse rather than better.Edinburgh Wanderer 22:08, 4 July 2012 (UTC)[reply]
See, I don't understand it either. The only hashes I like are these ones. Maybe someone has dropped some on the server, now up to 10 hours, 33 minutes, 20 seconds. Jared Preston (talk) 06:22, 5 July 2012 (UTC)[reply]
You should try corned beef hash some time.  :-) But this is the "technical" discussion area, and it is a rather technical issue. The Wikipedia database that stores old page revisions had a new field added to it recently to make it easier to determine whether two past revisions are identical or not, so that we can identify reverts. Now the servers are in the process of filling in this field, which previously had been blank, and all these changes need to be copied to the Toolserver (which is a separate system from Wikipedia). The flood of changes is overloading the Toolserver and causing the high replag. Unfortunately, according to the Toolserver admins, it could take another week or two for this process to finish. --R'n'B (call me Russ) 11:55, 5 July 2012 (UTC)[reply]
Just so you guys know, this isn't happening with me. Hadger 18:58, 5 July 2012 (UTC)[reply]
Hadger, can you confirm that by checking this link? Thanks for the help, Russ – I can cope (just about) with a week to ten days! Jared Preston (talk) 19:48, 5 July 2012 (UTC)[reply]
Oh. That's what you were talking about. I thought that you were talking about watchlists and contribution pages having that appear. :) Hadger 19:30, 7 July 2012 (UTC)[reply]
It's now on the way down, having peaked at around 10:00 UTC today with just under 140000 secs (38+ hours), the current figure is about 130000 (36 hours). --Redrose64 (talk) 21:10, 7 July 2012 (UTC)[reply]
It appears to have been steadily going up all month, and now at over 160,000 (44+ hours). However, the edit counter tool lists only 16 hours. Why the discrepancy? GoingBatty (talk) 03:19, 10 July 2012 (UTC)[reply]
There are two database servers for enwiki on the Toolserver (rosemary and thyme), and they are lagged to different degrees:
[2:31pm] <Earwig> @replag
[2:31pm] <tsbot> Earwig: s1-rr-a: 17h 13m 22s [+0.26 s/s]; s1-user: 2d 34m 37s [+0.22 s/s]
— The Earwig (talk) 18:34, 10 July 2012 (UTC)[reply]
Thanks for the explanation. Looks like the lags are continuing to increase and are now over 18h 41m and 2d 19h. On July 5, Russ said "according to the Toolserver admins, it could take another week or two for this process to finish." Is there any update from the admins? Thanks! GoingBatty (talk) 16:19, 13 July 2012 (UTC)[reply]
Not from the admins, but I've done my own analysis. Unless something is done about the cause, the replags are likely to continue increasing at least until the end of July, and probably for a week or two after that on s1-user. This is all due to a massive database update; eventually, it will get to the end of the database, but in the meantime all Toolserver tools are suffering. --R'n'B (call me Russ) 23:43, 13 July 2012 (UTC)[reply]
The replag has been racing up, in spurts, for the last 48 hours or so. When will this upward spiral end? Please help! Jared Preston (talk) 15:50, 19 July 2012 (UTC)[reply]
Certianly be good if we could get an official update on this.E W 18:56, 20 July 2012 (UTC)[reply]

Edit conflicts

I don't know if this is related to the above at all, but over the last day or so I've had some crazy edit conflicts. The two most memorable:

  • a.) the edit conflict page popped up showing no conflict, but having the orange "you have a talk page message" banner too. I clicked to see the talk page message (to a new tab) but no messages, though it sent me to an IP page and it showed an IP at the top, instead of me being logged in. But when I clicked on the "edit" button in the original window gain, it showed me as logged in.
  • b.) apparently had a three-way edit conflict, and though I got the conflict screen, the amazing thing was that my edit was already saved to the page (showing my full signature).

There have been several others conflicts of various types.

Not to mention seeing the wikimedia page fairly regularly.

And yesterday the database "read only mode" notice was up for several minutes.

Hope this helps. - jc37 17:23, 2 July 2012 (UTC)[reply]

And not only did I edit conflict with meno above (lol@ irony), but it took several minutes (with the wikimedia screen and even the browser "can't connect to server" screen for several minutes) in order to post the above. I connected to other websites just fine in the interim. - jc37 17:30, 2 July 2012 (UTC)[reply]

It wasn't an edit conflict but something wierd just happened at an RfA. I wanted to comment on an oppose and the entire page got messed up and then the server gave up so I had to wait before it came back. When I hit Rollback, it blanked the page and said it reverted it edits by me to the last version by a user that didn't even contribute to an RfA. Things returned to normal after I used a previous version and restored the RfA from there but I'm curious to know what that was especially the Rollback message that was created in the edit summary.—cyberpower ChatOnline 17:42, 2 July 2012 (UTC) [reply]

Weird; Special:Contributions/Flynnster14 shows just eight edits, and none of them are to Wikipedia:Requests for adminship/Zagalejo. At least ClueBot didn't come around and warn you for blanking pages :-) Nyttend (talk) 19:21, 2 July 2012 (UTC)[reply]
That's a plus, assuming ClueBot wasn't having issues as well. I can't figure out why Rollback acted the way it did. Maybe the foundation staff could figure it out.—cyberpower ChatOnline 20:27, 2 July 2012 (UTC)[reply]
I found this.—cyberpower ChatOnline 20:32, 2 July 2012 (UTC)[reply]
Any chance this is related to the leap second? --Guy Macon (talk) 20:32, 2 July 2012 (UTC)[reply]
No, leap second fun was yesterday. Max Semenik (talk) 22:19, 2 July 2012 (UTC)[reply]

Toolbar bloopers

Working on Firefox 13.0.1, with Windows XP. Forget about posting over at any toolbar talk page. I never got an answer the last time I posted. So, here this is. It's just been going on perhaps the last week. Cache has nothing to do with this, because I dump my browser's cache regularly.

  • Annoying, but workaround-able. The Cite button comes and goes. Workaround is that it comes back eventually, whenever. But almost a guarantee that when I first start editing, the Cite option isn't there.
  • Disabled completely. The "Link" icon on the toolbar will come up, and it works on internal links. If I try it with an external link, it goes through the motions like it's inserting the link. But it leaves a blank behind, not a link. This is consistent, as of this morning, all the time.
  • Find and Replace - sometimes it works, sometimes it doesn't.

Maile66 (talk) 17:25, 8 July 2012 (UTC)[reply]

Maybe when the cite button is not present your console shows a message like Uncaught TypeError: Object [object Object] has no method 'wikiEditor'?
As explained on mw:Extension:WikiEditor/Toolbar customization, it is required that any scripts which add buttons to the toolbar explicitly declare it depends on module "ext.wikiEditor.toolbar". If it doesn't, than it is likely there will be some race condition, which results in this kind of bug.
I didn't find any mention of the module "ext.wikiEditor.toolbar" on MediaWiki:Common.js/edit.js or MediaWiki:RefToolbar***, hence the problem happens.
It was suggested on January that this tool should be converted into a default gadget, but so far no one had the time to do so and I think that would also solve this problem... Helder 19:28, 8 July 2012 (UTC)[reply]
No messages on my console. But for the time being, the Cite button is there, and I can pull up cite templates. However, both Provelt and the cite templates fail to insert anything. They just sit there and do nothing. No messages on the console at all. Maile66 (talk) 20:35, 8 July 2012 (UTC)[reply]

Well, I thought rebooting might help. So, I've had my computer off for a few hours. I've made sure my JavaScript is enabled. WikiEd is checked under Preferences. Nada. As far as I can tell, it's only the toolbar features of adding citations, references or links. The pop up will occur to add text. And I can click "Insert". Sometimes the window closes upon clicking "Insert", and sometimes the window just sticks there. But either way, it isn't inserting anything. I've even changed skins, thinking that might help. But it doesn't. Maile66 (talk) 00:36, 9 July 2012 (UTC)[reply]

A number of editors have reported that the cite button has disappeared totally or intermittently. See discussions at Wikipedia talk:RefToolbar 1.0 and Wikipedia talk:RefToolbar 2.0. Unfortunately, there are a lot of complaints, but no fixes.— Preceding unsigned comment added by Gadget850 (talkcontribs) 00:43, 8 July 2012 (UTC)[reply]
Sigh.....thanks...complaints, but no fixes...sigh...Maile66 (talk) 00:52, 9 July 2012 (UTC)[reply]
OK, should be fixed now. Purge your browser caches and let me know if you notice it missing any more. Kaldari (talk) 19:32, 9 July 2012 (UTC)[reply]
Nope. Purged my cache. Shut down the browser and re-opened. The Cite button is there. But I still cannot insert anything., on anything on the toolbar that has a pop-up window to insert a reference, link or citation. The pop-up comes up, and I can type in it. But when I click "Insert" the window goes away, but nothing was inserted. Still at Square One. Maile66 (talk) 19:47, 9 July 2012 (UTC)[reply]

Do you have any gadgets other than ref toolbar enabled ? Perhaps one of them is interfering with this one. —TheDJ (talkcontribs) 20:36, 9 July 2012 (UTC)[reply]

I went through the Gadgets on Preferences and unclicked everything except WikiEd, which I assume I still need for this. Well, it still doesn't work for me. Maile66 (talk) 21:02, 9 July 2012 (UTC)[reply]
You don't need wikEd for this —TheDJ (talkcontribs) 22:32, 9 July 2012 (UTC)[reply]
Wait, perhaps you are not using Reftoolbar at all ? Is it just wikEd that is being problematic for you and you are confusing the two tools ? —TheDJ (talkcontribs) 22:34, 9 July 2012 (UTC)[reply]
I'm laughing...because the whole issue of toolbars and which is which can be confusing. Short of this...WikiEd was the conflict. But WikiEd is the nice visual aspect, right? With WikiEd, I've got RefToolbat 2.0b, but the citations quit working. Without WikiEd, the citations work, the visuals are plain, and the Reftool bar is a plain model without much to it. No Search and Replace, or the buttons. Better the plain model than one that doesn't work. Maile66 (talk) 22:55, 9 July 2012 (UTC)[reply]

Overview

It's not THAT hard (well it is sort of, but only because WE made it difficult)

Official toolbar elements

Traditional (old) MediaWiki toolbar, if you have more buttons, then those are extensions UPON the official old toolbar. Can be disabled in your Preferences by unselecting "Show edit toolbar" in the Editing tab.
The default, sometimes misnamed Vector toolbar, but actually the WikiEditor toolbar or 'enhanced editing toolbar'. (Does not depend on Vector and can be disabled in Editing tab of your preferences, using "Enable enhanced editing toolbar" option).

Unofficial toolbar elements

Buttons that the English Wikipedia adds to the old MediaWiki toolbar (enabled by default, cannot be switched off):

Part of the WikEd toolbar, itself part of the WikEd editor, a user script developed by User:Cacycle that can be used on top of both the old and the new (WikiEditor) toolbar and heavily interferes in the editor to do all sorts of wild things. Usually enabled trough Gadgets tab in your Preferences. Disabled by default.

Reftoolbar is an English Wikipedia extension that bolts both on top of the classical toolbar AND the WikiEditor toolbar (involving great deals of detection and loading routines to make it happen). Enabled by default. Cannot be easily disabled yet (see earlier comment about intension to convert to 'default gadget' but no one having executed that plan just yet).

How the ref toolbar looks when you use the classic MediaWiki toolbar.
How the ref toolbar options look like when you use the "Enhanced editing toolbar".

As far as I'm aware, most issues have always been in the unofficial (not supported and user developed) parts of the software. In terms of controllability as a software developer, my vote would be to just disallow user developed scripts. But that is not realistic. —TheDJ (talkcontribs) 10:56, 10 July 2012 (UTC)[reply]

If the so-called professionals would have sufficient time to develop such useful tools like the wikiEd, there would be no need for users beginning to write their own stuff. I dared to comment your comment on my user page. -- Rillke (talk) 09:30, 18 July 2012 (UTC)[reply]
Perhaps i wasn't clear enough on this front. My comment only went as far as loading of scripts and dependencies between scripts. The fact is that user scripts (and even common.js site scripts) are a maintenance hell in this regard, often incorporating a lot of legacy and duplication. They are a bad system because they are used by too many people who are not JS gods, which in all honesty, you need to be these days to have stuff continuously 'working' on Wikipedia (Roan, Krinkle and a few others are the only ones I still trust on this front). This is why the old system needs to go and it is why gadgets, then RL, then RL2 and soon Gadgets 2.0 were developed. It is a painful transition, but it's what is needed to take us from the free for all age into a sustainable age. The question is, can we really ever get rid of the 'traditional' user scripts. Probably not, but if we would have had Gadgets 2.0 in 2001, we probably would never have chosen to add user scripts for individual users, and in my opinion that would be a more ideal situation, than Gadgets 2.0 WITH userscripts. —TheDJ (talkcontribs) 09:57, 18 July 2012 (UTC)[reply]
I disagree. We just need self-managing code. With VisualFileChange, I started this idea on Commons. When it will become a gadget one day, it will simply remove it's installation from the user's own js and turn on the gadget. Having user scripts is important for testing. I don't want to see everyone testing new scripts as gadgets. Gadgets are supposed to work and their maintenance is also a pain. I think I made more than 500 gadget-related edits on Commons (!multilignual), so you can trust that I know what I am talking about. -- Rillke (talk) 10:10, 18 July 2012 (UTC)[reply]

Could it be this?

I'm not all that techno-savvy about how the toolbar cite popups and etc work, but the timing of the most recent issue does coincide with what happened over the weekend, that the FBI and local authorities have been warning users about (note, I can't insert the link properly for you). It does seem to me that the popups are looking to connect with something that doesn't connect. Is it possible? Maile66 (talk) 16:44, 9 July 2012 (UTC)[reply]

http://money.cnn.com/2012/07/06/technology/dnschanger/index.htm

No that's not it, then you wouldn't have any internet access whatsoever. —TheDJ (talkcontribs) 20:29, 9 July 2012 (UTC)[reply]
I wasn't exactly thinking that this might have affected my personal system. I was thinking that maybe the event affected some Wikipedia server out there, since the FBI had isolated infected systems. Maile66 (talk) 21:02, 9 July 2012 (UTC)[reply]

Skin reset

Based on feedback, it appears that a skin reset may now resolve the problem:

Open Preferences → Appearance, change your skin to anything else, save, change it back to the original skin, then save.

Please let us know if this works or does not work. ---— Gadget850 (Ed) talk 16:10, 12 July 2012 (UTC)[reply]

Well, it just did cure the issue. Thanks. I assume something was done to the skins in general, because I had tried a skin reset when this first happened, and it didn't work. But right now, that's the workable solution. Maile66 (talk) 16:43, 12 July 2012 (UTC)[reply]

Wikid77 and new 'fast' citation templates

Moved from WP:ANI

Wikid77 has created a suite of new 'fast' templates; {{fcite web}}, {{fcite book}}, {{fcite}} and maybe a few others and some redirects. They may be faster, but they break things like {{harv}} and {{sfn}} links. See India, England, Brazil and a few others where I've undone this. They also use a more restricted set of parameters. Wikid77 has deployed these to at least 50 articles often while making a sea of white space changes in the same edit. I left a note seeking discussion, but it has gone unanswered. I have also left notes for Gadget, Thumperward and Redrose64 seeking their input. I believe there is no consensus for this shift to new more limited templates. There was a thread on Jimmy's page about this, but I didn't read it.

I believe these need to be immediately reverted as manually removing them will be complex. These are mostly large, highly edited pages, so others are editing on top of this, which complicates restoring the standard versions. Br'er Rabbit (talk) 05:45, 11 July 2012 (UTC)[reply]

  • Hello, Wikid77 here. I have stopped adding those fast-citation templates to make major articles reformat 3x faster (reducing 21-second page-load to only 7 seconds). I have not been getting typical "You-have-new-messages" for the 2 messages on my user-talk page today. However, I noticed the ANI link on Jimbo's talk-page, when that thread failed to archive after 2 days of no other replies. Since ANI is not the proper forum for making articles load 3x faster, where should this topic be discussed? The exisiting gargantuan templates using Template:Citation/core are not easily improved, so I was able to make "50" of the most-read articles load (or edit-preview) within 7 seconds (rather than 15 to 32 seconds) by using streamlined fast-cite templates. Perhaps this is a general topic for WP:PUMPTECH, as it exceeds the {{Cite}} templates. -Wikid77 (talk) 09:15, revised 09:28, 11 July 2012 (UTC)[reply]
WP:CITEVAR. I'd say that's large scale disruption. Have they stopped? If not, they may need a preventative block to get them to talk. Fifelfoo (talk) 05:58, 11 July 2012 (UTC)[reply]
They did Andorra after I posted to their talk (where I got no reply). I'm not asking for a block; I believe we need more eyes on this stat. I've only looked at about a half dozen of them (and have reverted it). The prior 'talk' is at:
Br'er Rabbit (talk) 06:04, 11 July 2012 (UTC)[reply]
  • They are breaking articles; I've reverted or removed them from about a half dozen, but there are at least fifty (and they're large and heavily edited). There was a lot of search and replace here that was not properly done; red links in articles to template:Fcitation needed; others, too. Some of this was over the last week, so there are a lot of subsequent changes. I'm asking for others to look and help. Br'er Rabbit (talk) 06:36, 11 July 2012 (UTC)[reply]
If Wikid77 is correct that some of our template heavy articles take 30 times longer for registered editors to edit than for IPs then they deserve a barnstar for identifying the problem and starting on a solution. I'm almost tempted to log out and speed up my editing. If there are problems with the templates they are using then lets fix those templates and then deprecate and replace the slow ones. ϢereSpielChequers 06:50, 11 July 2012 (UTC)[reply]
With a buggy incomplete template, breaking CITEVAR on heavy trafficked articles. Yes they deserve a barnstar. Yes, if they continuing doing this without discussing on article talk pages per CITEVAR or getting a high traffic RFC, yes they should be blocked (preventatively, not punatively). Both may be in order. Blocks aren't punishment, in this case it is a restriction to enforce the RD elements of BRD because of a failure to pay attention to appropriate levels of consensus. Fifelfoo (talk) 07:04, 11 July 2012 (UTC)[reply]
@WSC; it's rather exaggerated. It's also not a new understanding; this has been talked about for years. The simplification here is extreme and more than 'buggy', it's about throwing out huge amounts of functionality. I've left notes for editors knowledgeable of the citation/core internals, so we should hear from them tomorrow. I'm all for slimming down dross in the standard templates. There's support in them for too many options and that has a cost. They're used millions of times; the solution is to work on the current templates. What's occurred over the last few days is an effort to cement this new thing into large complex articles without more than a few essays and a thread on Teh Jimbo's talk. These articles are now often broken. Br'er Rabbit (talk) 07:16, 11 July 2012 (UTC)[reply]
No one editor's talk is ever an appropriate place to establish consensus; especially for wide ranging multiple article changes that go against established understandings of how to deal with citation variations. Jimbo is just one of us, just an editor like any one of us. Fifelfoo (talk) 07:26, 11 July 2012 (UTC)[reply]
Jimmy doesn't much edit articles, 40% of his edits are to his own talk page. Br'er Rabbit (talk) 08:15, 11 July 2012 (UTC)[reply]
@Br'er Rabbit. I was aware that we had a problem, especially with large pages. We have had a couple of long threads at FAC about subdividing long articles to reduce page load times, and I recently spent a couple of hundred quid upgraded my own hardware because I thought it was just my kit getting obsolete. Wikid77's solution might not be working, but it does highlight a problem that we should try and resolve. It sounds like the Foundation has something in the works that may reduce the problem, but a lite template structure sounds attractive to me. If we can get Wikid77's templates debugged would that be a sensible route to follow? ϢereSpielChequers 12:32, 11 July 2012 (UTC)[reply]
I do think some of the largest articles should have stuff culled or split off, but not really for this reason; they're simply not articles, they're small books. Gadget's talking lite templates, but these ones are profoundly flawed. Too lite. The approach taken is to simply not support many parameters; like |last2=; the idea is to shuffle much into |coauthors=. See India before I fixed it. It may look right, but all the footnote links are broken. The article uses {{sfn}}, which relies on much that was omitted from these too-lite templates. It's not a matter of debugging; the design is wrong. This may well serve to start a discussion about refining the current templates or even deploying lite ones. But this was far, far, too disruptive; it cost me the last 8 hours. And I'm pretty sure there's still damage out there.
The 'related' is about navboxes; they take a fair amount of preprocessing. Too many/too huge navboxes can combine with templates to over burden the servers. That's on of the core ideas behind using WP:HLIST in navboxes. Since that launched late last year, the burden of navboxes is significantly reduced (the huge ones are still ridiculous). Br'er Rabbit (talk) 12:57, 11 July 2012 (UTC)[reply]
Comment Hello, everyone. Can you please define "fast" here? I am not sure I understand correctly. Best regards, Codename Lisa (talk) 08:13, 11 July 2012 (UTC)[reply]
There are speed issues with previewing very large pages. These are a good faith effort to address that, but there are issues; they break things and starting a new set of templates is not the way to go. Nutshell is this is a lone effort that has no consensus. Br'er Rabbit (talk) 09:00, 11 July 2012 (UTC)[reply]
I have since then added parameters to not "break things" and noted the Fcite templates are an "additional" choice, not a "new set". -Wikid77 15:56, 13 July 2012 (UTC)[reply]
The new templates also change the output and so violate WP:CITEVAR which says that you should not change the citation style without discussion and agreement of this on an articles talk page. Keith D (talk) 12:23, 11 July 2012 (UTC)[reply]
The minor changes to the output format were unintentional (as putting commas for "."), and I have modified the output to match the older templates. -Wikid77 15:56, 13 July 2012 (UTC)[reply]
related
Diff of Egypt {{tl}}'ing {{navbox}}es.
This is about not using navboxes, but rather linking to them. It's a very poor idea.
Br'er Rabbit (talk) 07:26, 11 July 2012 (UTC)[reply]
  • I see no point in these. We should be subtly changing the old templates (if we need to) not creating new ones and introducing them on such a scale without prior discussion. GiantSnowman 08:45, 11 July 2012 (UTC)[reply]
    Yes, I do believe that some consolidation of the standard templates is the appropriate means of addressing the speed issue. I have cut back a fair number of these. Br'er Rabbit (talk) 09:00, 11 July 2012 (UTC)[reply]
    • The introduction of Scribunto at the end of this year, will remove a large chunk of the speed issue with templates. Cite templates are the logic first set of templates that should make use of that. —TheDJ (talkcontribs) 10:34, 11 July 2012 (UTC)[reply]

Looking at these articles before they were reverted it is becoming clear what the "f" in "fcite" stands for. pablo 09:07, 11 July 2012 (UTC) [reply]

  • Lite versions of the citation templates have been discussed before, and have been on my todo list for a while. The current templates are rather bloated and do cause problems in page load speed and template limits when an article has a huge number of citations; this often occurs in conjunction with other templates, such as flag icons. Implementation of new templates like this should have involved a lot of community input and testing. Just looking at the markup, I can see that these will break certain citation implementations. There has also been discussion on converting the citation templates to Lua when the Scribunto is installed, which should resolve these issues. ---— Gadget850 (Ed) talk 10:53, 11 July 2012 (UTC)[reply]
Gadget850, I thank you for noting that, so I have added parameters last1, first1,... last3, first3 to support other citation implementations. -Wikid77 15:56, 13 July 2012 (UTC)[reply]
  • (@TheDJ, too) That would be mw:Extension:Scribunto. Looking forward to it. I know this has been discussed before. I'm thinking that the current templates could probably use a bit of streamlining; so many aliases and options. These templates did break a lot of pages; I happened to notice India with all of the harv/sfn glowing red with Ucucha's script. So I looked. A new template. It is dropping the lastn params and that's going to break harvs left and right (as will not supporting ref=). The deployment was sloppy. I found many red links to templates due to s/r of hundreds of cites. Wikid was not responsible for all of the deployment. I spoke with another user who happened to see it and, in all gf, adopted it. I saw IPs using it. That's to be expected when something appears in popular articles; people mimic. Br'er Rabbit (talk) 11:07, 11 July 2012 (UTC)[reply]
  • Just a note, Scribunto is (per the MediaWiki site) "incomplete. None of the interfaces are fixed at this time." Claiming that this will fix something does not fix anything now (although the problem is present now). In fact, it stifles development. To have someone say that these templates should be removed as Scribunto makes them unnecessary is akin to saying that creating any new article is unnecessary since, if the topic is notable, the article will be created eventually. Such a mentality serves no benefit to Wikipedia. --Nouniquenames (talk) 16:17, 17 July 2012 (UTC)[reply]

Fcite_web is a very fast alternative, and compatible

All of the {{Fcite_*}} templates are faster variations of the others, running about 5-6x times faster, but allow mixed use with the original templates. So, to list names of 8 authors, separately, then use the older template {{cite_web}}, while using {fcite_web} for fast cases of just 1 or 2 authors (or list all in "coauthors=") or 1 editor. To support {Harvnb} & {sfn} cross-links from author names, the Template:Fcitation has been fixed to set the {anchor|xx} tags in "CITEREFxx" format, and allow name parameters: last1, last2 and last3. The intent is to allow very rapid formatting of most references, but still support author-crosslinks, while allowing use of any and all original templates of the {{Cite}} family. In large articles with 100 or more references, the speed improvement has tended to make the whole article reformat 3x faster, such as during each edit-preview when editing the whole page. The 3x reformat speed has occurred in major articles, such as nations or big cities, but also in research topics which use many {cite_journal} or {cite_book} cases. With rare cases, such as 7 author names or 3 editors, then the speed improvement will be less when using some of the old cite templates. -Wikid77 (talk) 23:26, 11 July 2012 (UTC)[reply]

It's all quite moot given that there's a much more robust solution in the pipeline (see below, and above, threads). These are still reduced functionality templates and their use will only confuse editors who will not know just what the unsupported bits are. {{cite web}}, {{cite book}}, {{cite journal}}, {{cite news}}, are *standards*. They are on offer to all in the toolbar above every editbox (even anons). Forking to new names is itself disruptive. aside; I'd be all for nuking {{citation}} and making |ref=harv the default in the standard ones. Aren't we about sick of the noise over stops (or not), over commas, italics? And yours are doing some other anomalous formatting, right? Br'er Rabbit (talk) 23:50, 11 July 2012 (UTC)[reply]
What's wrong with {{citation}}? — Dmitrij D. Czarkoff (talk) 09:17, 12 July 2012 (UTC)[reply]
Template:Citation is very slow, only 14/second, compared to Fcite also setting anchors for {Harvnb} at 72/second, or 5x faster. Article "Israel" takes >41 seconds to edit-preview, but would be 13 seconds w/Fcite. -Wikid77 (talk) 12 July 2012, 05:06, 17 July 2012 (UTC)[reply]
Do you mean in comparison to Citation Style 1, or in comparison to the new {{fcite}} etc. or in comparison to something else? --Redrose64 (talk) 13:04, 12 July 2012 (UTC)[reply]
I happen to like the ability to use {{citation}} for just about any citation without having to think about which particular template to use. And this ability also makes it much easier for software to convert other sources of bibliographic data (such as bibtex files) to Wikipedia format automatically, for the same reason: the software neither has to guess which type to use nor be told manually. As for making cite work with the harv templates without having to add ref=harv (while citation always works) my understanding is that in some cases this will generate broken html, because the ref=harv option in conjunction with multiple cite templates that happen to have exactly the same authors and years as each other will lead to html anchors with the same name as each other, not allowed in html. —David Eppstein (talk) 15:12, 12 July 2012 (UTC)[reply]
@Dmitrij; my comment really is that it's superfluous. The editbox offers {{cite web}}, {{cite book}}, {{cite journal}}, and {{cite news}} to every editor. This makes them standard, and we should be moving that way. I wouldn't mind {{citation}} as thin wrapper that produced the same look (the convenience that David Eppstein speak of), but its look is different in trivial ways and so it doesn't mix well with the others. We've endless arguments over formatting with full stops or not, periods or commas. This is stupid.
@ David Eppstein; We should not, of course, be generating duplicate anchors. {{citation}} has |ref=harv on by default; I just want that for the others, too (working properly, of course). Br'er Rabbit (talk) 17:00, 12 July 2012 (UTC)[reply]
@David Eppstein: Yes, if you use two separate {{cite book}} with exactly the same authors/years, and give them both |ref=harv, you will generate invalid HTML by creating duplicate anchors. But exactly the same problem will occur if you use two separate {{citation}} and the same parameters (but omitting |ref=). There is no guard against such problems in either form, but the fix is exactly the same for both: you can either use |ref= to specify a custom anchor; or you can use the |year=2012a/|year=2012b system.
Regarding the thing about {{citation}} not requiring either the cite tool or the user to determine the source type: the problem still exists, but it's {{citation}} which has the responsibility for working that out. It doesn't always get it right, as witness threads like Template talk:Citation#trans_title or Template_talk:Citation/Archive_5#trans_title. --Redrose64 (talk) 17:23, 12 July 2012 (UTC)[reply]
  • Need to limit ref=Harv to limit collisions: Due to the danger of generating duplicate span-id tags, the current practice is to avoid using {Citation} for everything, and instead use Cite_book (Fcite_book) or Cite_journal (Fcite_journal), which do not create the span-id tags and allow 1 author to be cited for several publications in the same year, without risking a name collision on the span-id tags. -Wikid77 (talk) 17:45, 12 July 2012 (UTC)[reply]
This is simple. If it's faster and has the same capabilities and is fully compatible with our existing system, that's good but that is NOT the case here as it's breaking existing widely used template systems. This needs to go back into the lab post haste.PumpkinSky talk 10:17, 13 July 2012 (UTC)[reply]
Your concerns are so 24 hours ago (just kidding). It has been "back into the lab" and back out again, for further review. The reports of breaking links are from the early days, and author links have been correct for almost 1 week now. -Wikid77 16:34, 13 July, revised 05:06, 17 July 2012 (UTC)[reply]

Scribunto to fix the ~30 second page loading time problem for logged-in users?

Perhaps you should explain in more detail, TheDJ and Gadget850, how Scribunto will change things, given that it's been previously mentioned only as an aside, once ever, on the Technical Pump. What would a Scribbled {{cite book}} template look like? Why would it be faster for logged-in users? What should editors be planning for? Uncle G (talk) 10:56, 11 July 2012 (UTC)[reply]

I think there are two separate issues here:
  • A lot of the settings in user preferences are injected into the rendered HTML as JS/CSS. Then there are any custom user scripts or CSS. All of these can cause slow loading for logged in users.
  • Articles with a huge number of citation and other templates may load slowly due to template overhead, but this issue is not inherent to being logged in.
There have been instances where articles with a huge number of citations will not load at all when logged in, but it is due to a combination of the above.
I know little of Lua right now, but the Foundation is pushing it to resolve many of the current template issues. It is supposed to be more efficient, thus much faster and with less overhead. ---— Gadget850 (Ed) talk 11:18, 11 July 2012 (UTC)[reply]
Really its the non-JS/CSS preferences that cause slowness, not the preferences that inject JS/CSS. The non-JS/CSS preferences usually cause different parser options which cause pages to be re-rendered (which is slow, esp with heavy template usage). The preferences that inject JS/CSS usually do not cause very much slowness (I'm sure there are exceptions, especially for user scripts, but I mean in general). Bawolff (talk) 13:10, 11 July 2012 (UTC)[reply]
A "scribbled" {{cite book}} would bear some resemblance to the examples at scribunto.wmflabs.org; the general idea is that using an actual programming language rather than the current huge mass of parser functions for processing all the parameters the citation templates use will probably be much faster. BTW, the "slowness" referred to above doesn't really affect all logged-in users all the time; it affects people with unusual combinations of certain preferences, use of the Preview button, and the save/initial page view after a new edit is made. Anomie 14:46, 11 July 2012 (UTC)[reply]
Well, to be even more exact, of course it applies to everyone on these pages with an exceptional high complexity, it just depends on the configuration of the user and the timing of the request how much you are affected by it. The more caches that are invalid (due to edits) or elements that need to be specifically calculated (for you because you are either the first user in a long while or have 'differing' preferences), the longer the request to generate the page might take, the 'slower' the server will seem to respond, the more 'slowness' you will experience. It's all very subtle, specifically because so many different optimization levels have been created in the past.
An example of the coordinates for instance:
The first example uses copy of {{Coord}} and it's many subtemplates. The 2nd example a conversion to a Lua module with similar capabilities. You can note considerable speed differences. The Lua module is also far from optimized, because I converted in a style staying close to the original, instead of optimizing it fully. The final version of that lua module will probably be another factor of 2 faster in terms of logic, and there is likely also further optimization to be made in the processing logic of the Scribunto extension itself. But I think you will agree that the speed improvement is already quite noticeable. —TheDJ (talkcontribs) 16:27, 11 July 2012 (UTC)[reply]

Cleaning this up

Right. Now that the "fast" templates have been orphaned from articlespace, is there a reason to keep them around? Chris Cunningham (user:thumperward) (talk) 08:03, 12 July 2012 (UTC)[reply]

As an attractive nuisance? ;) Br'er Rabbit (talk) 16:46, 12 July 2012 (UTC)[reply]
I'm not sure that qualifies as a good reason to keep them around. As such, I'll probably TfD these in a few days, with a view to userfying them to Wikid77's space. Chris Cunningham (user:thumperward) (talk) 08:14, 13 July 2012 (UTC)[reply]
Didn't mean it as a good reason. I'll be supporting you there. You see on Jimmy's talk where wikid said he expected to be reverted? vely pointy. Br'er Rabbit (talk) 11:43, 13 July 2012 (UTC)[reply]
The "reverted" is the middle letter in "WP:BRD". I made a bold move to create and use this set of lite templates as add-on choices, and people have a choice to revert in each B-R-D cycle. -Wikid77 15:56, 13 July 2012 (UTC)[reply]
That's an essay. Performing an action dozens of times when you expect to be reverted is pointy and disruptive. Br'er Rabbit (talk) 19:30, 13 July 2012 (UTC)[reply]
The wp:BRD essay is linked from policy wp:Consensus, as an explanation of consensus techniques. I think the plan was to make B-R-D a guideline, but part-time volunteers can only do so much. See wp:BOLD, which is already set as a guideline. -Wikid77 (talk) 12:55, 14 July 2012 (UTC)[reply]
Just stumbled across {{Cite fast}}. It uses {{citation/core}} with some minimal parameters. ---— Gadget850 (Ed) talk 11:49, 14 July 2012 (UTC)[reply]
  • New Template:Cite_fast: Yes, {Cite_fast} was only 2x as fast as {Cite_web}, and there are still concerns of omitting all the optional parameters. Instead, {Fcite_web} remains 5-6x faster, and looks like it can handle many more parameters being added. However, I encourage others to explore faster methods everywhere. -Wikid77 (talk) 12:55, 14 July 2012 (UTC)[reply]
Thumperward/Chris Cunningham, why do you announce a TfD in the middle of this discussion? -DePiep (talk) 16:04, 15 July 2012 (UTC)[reply]
  • About TfD: Well, User:Thumperward submits many templates for discussion (wp:TfD), even perhaps most of my original templates have been recommended for deletion by him, over the years. However, announcing intent here does seem like wp:BATTLEground, rather than let people discuss the issues for a few weeks, with no talk of deletion. Any overly long VPT thread can be split, to close the old portion, but continue a new thread of conversation for weeks, where some users unaware of benchmarking techniques for template operation could discuss tactics so that more people would understand how some templates can be timed as being 5-6x times "faster" in actual use. Anyway, I link the TfD below:
·WP:Templates_for_discussion/Log/2012_July_15#Template:Fcite
After 3 years of trying to get Template:Citation/core to run faster, I would think people would realize, "There must be some big problems inside Citation/core, if it is still that slow after 3 years of wanting it faster". Anyway, let's continue discussing the technical issues. -Wikid77 (talk) 19:07, 15 July 2012 (UTC)[reply]

Fcite templates expanded for more parameters

I have expanded the Fcite templates to allow more parameters (such as: last1, last2, last3 and journal types). The emerging consensus is that the Fcite templates need to support more options, where some users felt that their basic needs could not be met with templates trimmed to have far fewer options. In particular, links to ISBN & ISSN numbers have been added, and most of the journal links are allowed, such as for JSTOR, DOI, PMID, OCLC, RFC, SSRN, ZBL, etc. Of course, the addition of dozens of parameters could slow the templates 100% as 2x slower, so I have devised new tactics to support many new options while retaining extreme speed. Hence, the Fcite templates are becoming quick "turbo templates" rather than just "lite templates" because they are supporting far more options than a lite-structure template would imply. It is likely that the Fcite templates will handle 90% of all current usage, at 4-5x times the speed. Many groups of "3,000 articles" still use odd-ball parameters, such as surname1 to surname8, or "editor1last" which is a reason why Template:Citation has to be somewhat slower, to check for all those many, many variations of parameter names. -Wikid77 (talk) 19:07, 14 July 2012 (UTC)[reply]

That's an odd reading of "the emerging consensus". I for one don't think creating yet another different incompatible set of templates for the same thing is a good idea. —David Eppstein (talk) 05:39, 17 July 2012 (UTC)[reply]

Can't "paint" and copy (Firefox)

Starting several days ago, I have not been able to "paint" and copy/cut material from my Firefox article editor. "Select all" does not work, neither from toolbar, nor from right mouseclick within editor. "Sometimes" when I disabled Javascript, I was able to "paint," but then had "other" problems. My Firefox version is 13.0.1, running on Windows XP, which is automatically updated. I am not aware of having made any editor option changes myself. Disabling Javascript no longer works (if it ever actually did!  :). I would appreciate suggestions. Student7 (talk) 20:31, 11 July 2012 (UTC)[reply]

Does it work if you log out? Does it work at other websites? Try to clear your entire cache. PrimeHunter (talk) 21:39, 11 July 2012 (UTC)[reply]
YES! It works when I log out but not in!
It worked (works) everyplace but inside the article editor itself. In other words I can exit this subcomment and "paint" the title just fine. Just not when I'm inside the editor. I've tried to clear the cache with no effect. Will double check. Student7 (talk) 22:21, 12 July 2012 (UTC)[reply]
Just zeroed the cache and that had no affect, so reset it to 1024. (It had been using 756 MB BTW). Student7 (talk) 22:36, 12 July 2012 (UTC)[reply]
What is your skin? Does it work at fr: in that skin? I guess you haven't set any preferences there and I can see you don't have .js or .css pages there. PrimeHunter (talk) 23:04, 12 July 2012 (UTC)[reply]
My skin is Monobook. I do not remember how or why or when that was chosen. "Paint" DOES work in French Wikipedia! I do not have the knowledge to change the skin page. What should I select for .js or .css? I just want to do normal editing. No bots, java modification (except to my own attributes when required), etc. Student7 (talk) 14:07, 13 July 2012 (UTC)[reply]
Skin is selected at Preferences → Appearance. The default for unregistered and new users is Vector. If you switch from Monobook to any other skin, your User:Student7/monobook.js will no longer be active, but your User:Student7/common.css will still be used. --Redrose64 (talk) 16:27, 13 July 2012 (UTC)[reply]
Selecting Vector (and saving) did not solve the problem. Also cost me the "tabs" at the top: watch/unwatch, etc. I've switched back to Monobook (not knowing any better how to solve the newest problem).Student7 (talk) 17:05, 14 July 2012 (UTC)[reply]
In Vector skin, you typically get five tabs on all pages: Article/Talk appear at the left, and Read/Edit/View history towards the right. Most of the "missing" tabs are offered as selections in a pull-down menu. This menu is the downward-pointing black triangle immediately left of the search box; the options offered here may vary between pages. Between the "View history" tab and the black triangle, you should see a white or blue star. This performs the watch/unwatch function: white star=watch, blue star=unwatch. --Redrose64 (talk) 19:35, 14 July 2012 (UTC)[reply]
I haven't been able to reproduce your problem but it sounds like something in your account. What is enabled at Special:Preferences#mw-prefsection-gadgets and Special:Preferences#mw-prefsection-editing? PrimeHunter (talk) 19:54, 14 July 2012 (UTC)[reply]
Gadgets: 1)" After rolling back an edit, automatically open etc." This ususally doesn't work, nor do I much care anymore. Could dispense with it.
2) Disable access keys. Don't know what this even means.
3) Focus the cursor in search bar upon loading page. This sounds great, but have to force "search" from "edit" BEFORE the search box comes up. Not much use.
4) Navigation popups. Really like this feature.
5) Twinkle
6) Ask a question, which I never have done. Sure don't need it.
Editing: 1) Show preview before edit box
2) Enable section editing
3) Prompt me when editing a blank edit summary.
4) Warn me when I leave an edit page with unsaved changes. Haven't noticed this working nor really understand how it could work.
5) Show me the difference between lastest pending and latest accepted pages. Not sure this is needed yet/anymore.
I will switch skins if I have to, to solve the problem, but it is a "cultural change" for me, which I would rather avoid between Monobook and Vector. Student7 (talk) 19:12, 15 July 2012 (UTC)[reply]
What do you want me to do?
Right now, when I need to move more data than I care to recopy (with footnotes!  :), I log out, edit and move, then log back in. Editors, of course, do not know who I am unless I identify myself on the edit summary. Student7 (talk) 00:10, 17 July 2012 (UTC)[reply]
  • I have the same set up as you - Firefox version is 13.0.1, running on Windows XP. My skin is Modern, and I don't have the problems you do, even if I switch to Monobook. However, recently I had quirky stuff happening with my Edit toolbar that nobody else seemed to have. The only solution was to change skins (doesn't matter which one you chose temporarily). Save the change. Then go back into Preferences and go back to the skin you prefer. In my case, that resolved my issues, as if the toolbar "booted" itself with the skin change. I don't know the answer for you, except to give it a try to change skins, save, and then return to the skin you want. It can't hurt you to try it. Maile66 (talk) 00:30, 17 July 2012 (UTC)[reply]
Unfortunately switching skins doesn't seem to help. Switched to "Modern." And switched to "Vector", since that was mentioned the other day. Saved. Logged out. Etc. Doesn't work.
I guess we're at the point where I just have to try "random things" and see what happens. Since I know little about the system, this is a bit harder to do with any confidence. Student7 (talk) 14:33, 17 July 2012 (UTC)[reply]
Well, selected ones didn't work either. I guess the last thing I can think to do is to restore all defaults on every preference page. Not quite ready for that yet, but I will be in a few days, I guess. Student7 (talk) 14:45, 17 July 2012 (UTC)[reply]
Restored standard settings to "gadget" preferences. That worked for about 5 minutes! Have no idea why or when it quit working. Student7 (talk) 22:36, 17 July 2012 (UTC)[reply]
Restored all standard settings including Vector skin and everything else. That seems to be working! How could it not? Will try to re-add vital editing tools one-by-one. Student7 (talk) 22:44, 17 July 2012 (UTC)[reply]
Have you tried disabling (or blanking your User:Student7/monobook.js and User:Student7/common.css? --Redrose64 (talk) 22:47, 17 July 2012 (UTC)[reply]
Might this Firefox bug have something to do with it? https://bugzilla.mozilla.org/show_bug.cgi?id=692153PartTimeGnome (talk | contribs) 20:05, 18 July 2012 (UTC)[reply]

I have been asked to inform you of a proposal concerning the section 0 edit link. See WP:VPR#Activate section 0 edit link for everyone -- 76.65.131.160 (talk) 11:19, 12 July 2012 (UTC)[reply]

  • WARNING: (corrected) Although the option to display section-0 edit tab "[edit]" does not disable page-cache display, beware setting unusual user-preferences which make an article appear different and disable cache display. However, I have tested the section-0 edit option in Special:Preferences, now, as safe to use:
  • [_]   Add an [edit] link for the lead section of a page.
Beware other Special:Preferences options which might disable the page-cache display, so as to make viewing most articles/pages 10x-50x slower (forced custom reformatting upon each viewing), as happened to me for the past several years. Any similar page-display option, which causes an unusual page format, will make that user's format out-of-step with the bulk of users who view standard, cached copies of articles. Using a different default image-size is NOT so unusual, as experiments have confirmed that both 220px and 250px default-image settings will display cache copies of major, large articles. The constant, slow reformatting is not a problem for small, or stub, articles which can reformat within 4 seconds each time. I will try to have confirmed this section-0, lead-section edit option still allows page-cache display, since I am quite used to having seen 30x slower reformat of every page for the past several years now. -Wikid77 (talk) 00:08, revised 00:46, 15 July 2012 (UTC)[reply]
Nothing in the Gadgets tab is going to fragment the cache in that manner. As far as I can tell, options that will affect it include the math preference, stub threshold, date format, "Auto-number headings", user language, thumbnail size, and "Enable section editing via [edit] links". Basically, if you look in the page source for the HTML comment along the lines of "Saved in parser cache with key enwiki:pcache:idhash:15580374-0!*!0!!en!4!*", any preference that manages to change that key has a chance of causing your pageviews to have to rerender; the actual amount of rerendering you experience will depend on how many other people have preferences giving the same key. Anomie 02:23, 15 July 2012 (UTC)[reply]
Thumbnail preference 250px disabled quick cache: Anomie, thank you for taking time to list those options. Option 250px was trouble, but default-thumbnail as 220px was fast. Even with "Enable section editing via [edit] links" (edit-tabs), it would display cache-article copies when 220px. For me, the default thumbnail size 220px was lightning fast with cache-article copies, but default-thumbnail setting as 250px caused slow reformatting of almost all major articles (films, celebs, famous scientists) and all 7 Special:Random articles which I viewed. I switched the Special:Preferences several times, between 220px to 250px, to establish a clear cause-effect link: all pages reformatted at 250px, got cache copies at 220px, reformatted at 250px, got quick caches at 220px, etc. I was surprised the tiny no-image stubs reformatted, because it would seem the servers could "see" there were no images in a tiny stub to reformat the page, but I guess the upset potential for included templates, for a template to pop-in an image, caused ALL tiny random stubs to reformat at 250px preference. It is difficult to predict when a transcluded template might be changed, in an instant, to now throw an image onto a page. Hence, every single article reformatted at 250px, even mega-article "Wikipedia" took 24 seconds to reformat, as if no one ever viewed that page with 250px defaults. Again, thank you for your page-cache notices, as you helped me view major WP articles 38x (yes) thirty-eight times faster as cache-article copies. -Wikid77 (talk) 22:21, 15 July 2012 (UTC)[reply]
The option Preferences → Editing → Enable section editing via [edit] links is the default. It is turning this off which will cause a non-cache copy to be served. --Redrose64 (talk) 07:15, 16 July 2012 (UTC)[reply]

Template:Afd and equivalent

I've noticed an odd bug with this template in that even when the deletion page has been created, the link there stays as a redlink in the template. Clicking on the redlink still takes you through to the deletion page as normal however. Simply south...... always punctual, no matter how late for just 6 years 21:53, 12 July 2012 (UTC)[reply]

If the template is added with Twinkle then the deletion page is often created so shortly after the template is added that the creation isn't registered yet and the link becomes red. This can be fixed by purging the nominated page. PrimeHunter (talk) 22:01, 12 July 2012 (UTC)[reply]
I don't use twinkle. The bug seems to affect other pages not done by me as well. Simply south...... always punctual, no matter how late for just 6 years 22:13, 12 July 2012 (UTC)[reply]
Please give an example. That applies to all reports of suspected bugs. If the template was added before the deletion page was created then a purge will also often be needed. PrimeHunter (talk) 22:19, 12 July 2012 (UTC)[reply]
(edit conflict) I don't use twinkle either; but I've seen this happen several times. Whenever I notice a redlink in an AfD banner, I go for the "purge" tab. In case you're wondering where to obtain this... see Preferences → Gadgets and switch on 'Add a "Purge" option to the top of the page, which purges the page's cache'. Such a purge almost always turns the redlink blue; if it doesn't, the nominator hasn't done WP:AFDHOWTO step II. --Redrose64 (talk) 22:22, 12 July 2012 (UTC)[reply]
Thanks. Although I have seen it redlinked on different computers, I used that tab and it went back to normal. Cheers. Simply south...... always punctual, no matter how late for just 6 years 21:50, 15 July 2012 (UTC)[reply]

Sort order problem

Is there any way to get consistent sorting results for entries with the same value in a sortable table column? Take the Players table in this article for example: Sort any of the columns with numerical values and compare it with the "Cap" column; keep sorting the same column over and over again, observing the pattern of the "Cap" column (ex: The top results for batting HS goes 2, 37, 2, 27, 2, 41, 2, 32...) I know that this can be fixed by assigning appropriate sort values in the template {{sort}}, but this is going to be quite tedious for columns with entries that have dozens of similar values. Is there a simpler way of doing this? Perhaps using a different template? Thanks in advance. ASTRONOMYINERTIA (TALK) 12:11, 13 July 2012 (UTC)[reply]

The best way to fix it would be to fix the tablesorter itself to use a stable sort. In the mean time, if you hold Shift while clicking the sort arrows it will do a multi-column sort, e.g. click on one of the numeric columns and then on "Cap" to use that as a secondary sorting criterion. Anomie 20:10, 13 July 2012 (UTC)[reply]
Previously reported in March (VPT/Archive 98 and Bugzilla:35526). Thanks for filing the above fix. — Richardguk (talk) 23:23, 13 July 2012 (UTC)[reply]
Can you please clarify how to apply the fix for the table itself? Or an example would suffice. Thanks!! ASTRONOMYINERTIA (TALK) 14:50, 14 July 2012 (UTC)[reply]
It's not something to apply on an individual table, but a change to the MediaWiki software that will correct the issue in all tables. It just needs to get reviewed and pushed live, hopefully that won't take too long as it appears to be a fairly simple change. the wub "?!" 22:14, 15 July 2012 (UTC)[reply]

en.wikipedia.g-webs.com

What on earth is this? A user asked to have his user sub-page deleted, which was done, but he is upset to find that Google still shows up a copy on http://en.wikipedia.g-webs.com/wiki/. I would think it was just a mirror site, but an address starting "en.wikipedia" looks as if it is something to do with the WMF. JohnCD (talk) 22:57, 13 July 2012 (UTC)[reply]

Looks like a trademark violation at least for File:Wiki.png. I don't know how agressive the foundation is about protecting that image's trademark. The actual page content there wouldn't be anything to do about, as its creative commons licensed. Monty845 23:01, 13 July 2012 (UTC)[reply]
I know the foundation went after a Christian site with a logo that looked like the globe logo but with crosses instead of glyphs. They are protective. Chris857 (talk) 23:36, 13 July 2012 (UTC)[reply]
Not sure the point of contact for trademark stuff, but someone should pass it up. Monty845 23:48, 13 July 2012 (UTC)[reply]
I posted to Steven (WMF)'s talk page because, IIRC, he has been involved before and works for the foundation. Chris857 (talk) 00:13, 14 July 2012 (UTC)[reply]
(edit conflict) and I raised it with the WMF's General Counsel - see User talk:Geoffbrigham#Mirror site using Wikipedia logo and "en.wikipedia" address. JohnCD (talk) 00:19, 14 July 2012 (UTC)[reply]
I'd also be concerned that they offer our log-in screens. That'd be a perfect means for capturing Wikipedia login information. (Couldn't quite create an account there, though!) --j⚛e deckertalk 00:45, 14 July 2012 (UTC)[reply]
See WP:MIRROR. I think this site is in breach, since it doesn't link back to the original wiki page on English Wikipedia, hence not providing the attribution required by CC-BY-SA. It also seems to be pulling data live from Wikipedia (look at http://en.wikipedia.g-webs.com/wiki/Wikipedia:Sandbox?action=history, for instance), which the WMF doesn't like at all. So it would probably be blocked at the server level if the techies are alerted. (Don't know what it's doing, but it's not doing that.) — This, that, and the other (talk) 01:13, 14 July 2012 (UTC)[reply]
Hi all, I've sent an email to the Trademarks team for this, FYI the email address is trademarks@wikimedia.org. They are all at Wikimania at present so there may be a delayed response time and I've also made them aware of this thread. The Helpful One 01:38, 14 July 2012 (UTC)[reply]
That is a very peculiar site. It seems to be a dump of WP as at 8 April. Wikilinks work, but the search box doesn't, and there are no "History" or "Edit" tabs. If you try to create an account, the form appears, but no CAPTCHA image shows so you cannot proceed. What seems to me highly undesirable is that a casual reader who happens on it has no obvious way to tell that it is not the real thing - even if they look at the web address, it starts "en.wikipedia". JohnCD (talk) 20:34, 15 July 2012 (UTC)[reply]

Pointless message and button on Watchlist

Isn't it about time we removed the "Pages which have been changed since you last visited them are shown in bold" message and "Mark all pages visited" button from the Watchlist? The message is irrelevant because nothing is shown in bold, and pushing the button has no effect. It has been like this for a few months now, and it's ridiculous and embarrasing. I think the message and button were left there pending the outcome of this discussion, but this now seems to have ground to a halt. Either we should enable the bolding and button functionality, or remove them. And this should be done globally, not just for users who know how to mess around with css. Bazonka (talk) 07:43, 14 July 2012 (UTC)[reply]

Users with the default language en at Special:Preferences don't see "Pages which have been changed since you last visited them are shown in bold". The watchlist displays MediaWiki:Wlheader-showupdated which is blank for en. Users who changed language see the MediaWiki default for that language. For en-gb it is as you quote: MediaWiki:Wlheader-showupdated/en-gb. en-gb and en-ca are not recommended because many messages have only been customized for the default en. PrimeHunter (talk) 10:21, 14 July 2012 (UTC)[reply]
I am set to en-gb, so that would explain it. But it hardly seems to be in the spirit of WP:ENGVAR - "The English Wikipedia prefers no major national variety of the language over any other". I object somewhat to being forced to set my preferences to what is essentially a foreign language, albeit one that is mostly mutually intelligible. En-gb and en-ca should work in exactly the same way as en, and so this ridiculous message and button should be removed from their settings. Alternatively en-gb and en-ca should be removed entirely - if they don't work properly, then why do they exist? Bazonka (talk) 14:02, 14 July 2012 (UTC)[reply]
Huh? My setting is the default "en - English" but I still see that annoying button... Jared Preston (talk) 14:57, 14 July 2012 (UTC)[reply]
You see the "Mark all pages visited" button but not the text "Pages which have been changed since you last visited them are shown in bold". See http://en.wikipedia.org/wiki/Special:Watchlist?uselang=en-gb for how it looks with en-gb selected. The choice between en, en-ca, en-gb and a lot of foreign languages is part of the MediaWiki software. The English Wikipedia usually only customizes the default language en. Users with all other choices see the messages built into MediaWiki. The language choice only affects interface messages and not wiki text. PrimeHunter (talk) 15:07, 14 July 2012 (UTC)[reply]
In other words there is a button and a message next to it. The message is blanked in default language. — AlexSm 15:14, 14 July 2012 (UTC)[reply]
Yes it is ridiculous and embarrasing but apparently someone decided that his time is much more valuable than of hundreds other editors. Discussions were here: MediaWiki talk:Common.css#Please undo the last change. It breaks functionality for one group for the aesthetic appeal of another and User talk:R'n'B/Archive 16#Common.css. — AlexSm 15:14, 14 July 2012 (UTC)[reply]
  • Alex, I don't appreciate the tone of your comments or your presumption to claim to know my thoughts. My reason, which I expressed in the discussions you linked to, was that changes should be made after the RFC discussion was completed, not before. If the discussion is now completed, the results of that discussion should be implemented. --R'n'B (call me Russ) 15:54, 14 July 2012 (UTC)[reply]
If the message is blanked by default then so should the button too. But I guess I'm not the only one thinking this. Jared Preston (talk) 15:25, 14 July 2012 (UTC)[reply]
  • Note to whoever decides to be bold or reckless: please get things right this time. There are two systems, one is opt-in, and a large number of users (myself included) make use of the opt-in system. Because of the way Recent Changes was enabled, long after the discussion, it evoked a strong reaction and was hidden away. An endless slew of .css amendments were crafted to overcome each change, and it quickly became frustrating to have to seek out why my watchlist wasn't working every 36 hours. Make this a gadget, or don't change anything. Otherwise, you will have a lot of angry users to forcefeed some new css amendment to make Recent Changes work properly. A pointless button is better than a broken function. With one you get an odd "so what does this do, exactly?"; with the other you get a borked watchlist for hundreds of users. - ʄɭoʏɗiaɲ τ ¢ 15:41, 14 July 2012 (UTC)[reply]
I agree that a pointless button is better than a broken function. But no pointless button and no broken function is better still, which is what we used to have. Can't somebody put things back to where we once were? And if the css users (a small minority of Wikipedia editors) have to make some more changes then so be it. Bazonka (talk) 20:20, 14 July 2012 (UTC)[reply]
And having a useful feature not hidden from all new users would be better yet. Anomie 22:12, 14 July 2012 (UTC)[reply]
So what is going to be done? Bazonka (talk) 13:51, 15 July 2012 (UTC)[reply]

Who writes on Wikipedia

Who writes on ikipedia — Preceding unsigned comment added by 213.233.154.239 (talk) 20:26, 14 July 2012 (UTC)[reply]

See Wikipedia:Who writes Wikipedia. PrimeHunter (talk) 20:32, 14 July 2012 (UTC)[reply]

Perhaps increase NewPP preprocessor limits

Again, I wonder if we have gained support, yet, to increase the NewPP preprocessor limits:

  • The post-expand include size: from 2,048,000 to 2,750,000 (+34% larger)
  • Expansion depth limit: from 40 to 70 nest levels deep (+75%, or 30 if-else-else).
  • Expensive parser-function limit: from 500 to 700 instances (+40%).

Because the template-generated (post-expand) page contents can still pose a risk, I am thinking just a 34% increase would be conservative, yet enough to handle some over-sized pages. However, for years, I have explained that a 40-level depth limit is far too limited, where programmers often design if-else-else-else-else logic which, for multiple templates, would be equivalent to 200 levels. Hence, I strongly urge the 70-level limit, to encourage more editors to write templates which nest the if-else-else-else logic 7-20 levels deep in each template, before calling other templates, where 3 or 4 templates could combine beyond 40, to allow 70 levels deep. Recall that a #switch structure can only process exact-equals branches, and so the if-else-else-else logic is needed to simulate a switch based on multiple conditions, as a guarded command structure, easily checking a stack of 7-20 preconditions ("a >  b") before choosing an option. Even with some nested #switch structures, experiments have confirmed that multi-level #switches (<90 cases per switch) are much faster, as nested by 1st letter of key, extracted by the rapid {{padleft:|1|{{{key}}} }}, to branch to each nested #switch checking more-common letters earlier, then #default to all low-usage letters. For optimal template speed, all crucial validation checks of template parameters should occur as nested if-else-else-else before #switch-#switch, and hence a 7-level-deep structure would be common in many such templates, before invoking other subtemplates.

Anyway, explanations aside, I think the time has come to seriously increase the NewPP limits to allow writing more-efficient if-else-else templates, and handle larger groups of data items within a page. -Wikid77 (talk) 02:15, 15 July 2012 (UTC)[reply]

I think it may be a non-issue with Lua coming to a wiki near you (in the far if not near future). --Izno (talk) 02:28, 15 July 2012 (UTC)[reply]
I would not say it's a non issue, it's a very real issue. I just think that the new lua stuff IS gonna happen this time, so I think any time invested is probably best spent on experimenting, improving and converting to that. —TheDJ (talkcontribs) 08:19, 18 July 2012 (UTC)[reply]

MediaWiki parser trashing white space

See Template talk:Legend#Whitespace effect

Consider the following HTML:

<span style="color:black;background-color:yellow ;">Black text, yellow background</span>

This renders as Black text, yellow background. It should render as Black text, yellow background. The MediaWiki parser appears to be changing the (valid) normal space &#32; in the style= attribute into a non-breaking space &#160;, which is invalid. Are there any outstanding bugzillas for this? --Redrose64 (talk) 13:27, 15 July 2012 (UTC)[reply]

I understand you mean &#x20; for regular space. -DePiep (talk) 13:52, 15 July 2012 (UTC)[reply]
Yeah, sorry. Doesn't affect the demo though, where I used a keyboard space. For consistency with the &#160; shown as such in the HTML, I've kept it as decimal so amended to &#32; --Redrose64 (talk) 15:36, 15 July 2012 (UTC)[reply]
Yeah very minor. I like your analysis, well pointed & explained. -DePiep (talk) 15:52, 15 July 2012 (UTC)[reply]
MediaWiki has a "feature" where it tries to make normal spaces into non-breaking spaces in certain contexts: before '?', ':', ';', '!', '%', or '»', and after '«'. Apparently this sort of thing is common in French, as the comment describes it as "french spaces". As you noted, it can cause problems when a normal space is what is actually needed. I don't know if there is a bug for this issue specifically, but Template:Bug and Template:Bug are somewhat related. Anomie 16:51, 15 July 2012 (UTC)[reply]

Alternate editing mode is buggy

Hello folks, Please excuse my lack of technical know-how and vocabulary! When I am editing articles on English Wikipedia I use an alternate editing mode that was suggested to me by someone on here a couple of years ago. I don't know the name of this mode, but I find it very handy because it shows file names in green, links in blue, hidden text in yellow, etc. It's very easy to find your way around visually because of this. However, it is quite buggy. The software quite often leaves out ledding spaces between linked words when you save. It also gets very confused with line spaces when you save, sometimes converting one line space into two, three, or more. And, just in the last couple of months this interface has developed a really major bug whereby it won't preview or save a new article but shows a blank page instead. Am I using an outdated version of this interface? Or what is going on? Thanks, Invertzoo (talk) 14:31, 15 July 2012 (UTC)[reply]

Maybe you are using wikEd from User:Cacycle/wikEd. Some weeks ago it stopped functioning with me. I used to toggle it on/off, to use its value and to sail around its bugs (eg find & replace). -DePiep (talk) 15:04, 15 July 2012 (UTC)[reply]

I am using Safari version 5.1.7, what are using DePiep? And should I report this to User:Cacycle? Invertzoo (talk) 18:55, 16 July 2012 (UTC)[reply]

Interwiki mouseups

There is currently a discussion at Talk:Main Page#Languages are not in English... During that discussion, I noticed that the {{Wikipedia languages}} template has mouseup functionality showing the English language name for the language of each link (explained at {{Wikipedia languages/core}}). What I was wondering is if anyone here can say whether it is possible to implement that mouseup functionality in the place that generates the interwiki links for every article? Most of this is summarised here, but I'm hoping those here can answer the questions (either here or there). Thanks. Carcharoth (talk) 18:40, 15 July 2012 (UTC)[reply]

When I mouseover the interlanguage links on this page, I get a tooltip showing the link target, just as I do for any other link on this page. It's in the language of the target page, i.e. the Català link shows "Viquipèdia:La taverna/Ajuda". But when I try the same at Main Page, there is no tooltip. Firefox 13.0.1 Windows XP. --Redrose64 (talk) —Preceding undated comment added 20:46, 15 July 2012 (UTC)[reply]
Now I feel silly! :-) I should have realised that the Main Page interwiki links are a special case. They are limited to be just the ones in the {{Wikipedia languages}} template. Not sure how that limiting trick is done, but anyway, now I know to load up an article, I see that the mouseup/tooltip does indeed show you the interwiki title (i.e. the text typed on the source page inside the interwiki link code). That's not quite what I was after, but it is good to know that these aren't missing altogether. Hopefully someone can add them back in for the Main Page ones, and I'll have to go away and think a bit about how and whether it will ever be possible for an English-language speaker to glance over at the list of interwiki links and be able to browse down them and think "hmm, this article has equivalents in the following languages, that's interesting", as opposed to "hmm, a list of languages, some of which I recognise, some I don't. I could look up the ones I don't recognise, but wouldn't it be nice if I could hover my mouse cursor over them and be told what language they are?" Maybe one day. Carcharoth (talk) 21:08, 15 July 2012 (UTC)[reply]
There is a whole slew of issues with what you propose. Historically, we didn't have every language translated into every other language (we still don't, but 90% there probably). It's a lot of permutations. 2nd for anonymous users there is an idea that you might want someone to find their own language back if they happen upon another article. The reason for this being limited to anonymous has yet another reason, and that is that presenting a different language version of that part of the pages, would cause a HUGE amount of 'duplicates' to enter the system of cached pages, or we would have to exclude certain variants from being excluded, but that would lead to huge amounts of load on the 'backend' of the system, so also not acceptable. For logged in users, the biggest issue is that there is no 'global' preference for language yet, so if a logged in user happens upon a chinese page, he again might be unable to find his way back to the english article. Most of these issues have bug tickets, most have been known for quite a long time, they are just either difficult to solve or low priority. —TheDJ (talkcontribs) 23:35, 16 July 2012 (UTC)[reply]
The reason why there are no tooltips on the Main page interlanguage links, is that the Main page is named differently (Some have Portal:Main page for instance) on every single instance of a wiki and they have a habit of changing once in a while. Because they are difficult to maintain by interwiki bots (most main pages are locked for editing) and because both bots and humans have made quite a few errors in the past in this field, it's a maintenance nightmare. This also partly why {{Wikipedia languages}} uses the language IDs and translations I presume. But you could just add every main page name in {{Main Page interwikis}} and you would then have tooltips that correspond to the name of the portal in that language, just as interlanguage links work on all other pages. —TheDJ (talkcontribs) 23:56, 16 July 2012 (UTC)[reply]
If you want to translate the interwiki links to English (and add a translate link), then see User:Manishearth/sidebartranslinks. ---— Gadget850 (Ed) talk 14:10, 17 July 2012 (UTC)[reply]

I have a ton of edits by User:Svenbot (edit | talk | history | links | watch | logs) on my watchlist, including when I click the "hide bots" button. The edits are not showing the "b" next to the bot. However, Svenbot was given the botflag in 2011. Why is this occurring? Magog the Ogre (talk) 19:33, 15 July 2012 (UTC)[reply]

Bots don't have to use the bot flag they possess; I guess in this case it's usage has been turned off for some reason (usually talkpage messaging?!) - Jarry1250 [Deliberation needed] 20:00, 15 July 2012 (UTC)[reply]
Best would be to ask the bot op for the reason, and if there is no good reason ask them to start using it. Anomie 20:46, 15 July 2012 (UTC)[reply]

Byte changes in histories and contributions

The negative changes should certainly have the &MINUS; hyphens instead of the regular hyphens at present. Surely this wouldn't overload the Wikimedia software? (I am a Chrome user, but the browser should be irrelevant) GotR Talk 00:53, 16 July 2012 (UTC)[reply]

See Template:Bug Anomie 03:37, 16 July 2012 (UTC)[reply]

My signature breaks stuff

And I'm not quite sure why. As you can see, it is currently causing #39 under the "Sports and recreation" section at WP:GAN to display in superscript. If someone can figure what's wrong in the code and let me know how to fix it, I would be greatly appreciative. Evanh2008 (talk|contribs) 07:16, 16 July 2012 (UTC)[reply]

My guess is it's the pipe in your signature that broke it. I've fixed WP:GAN. DH85868993 (talk) 07:28, 16 July 2012 (UTC)[reply]
You could change the pipe to &#124; in your sig. Would still look the same. | | -- WOSlinker (talk) 08:38, 16 July 2012 (UTC)[reply]
(edit conflict) As above, it is probably the pipe | which separates [[User talk:Evanh2008|talk]] from [[Special:Contributions/Evanh2008|contribs]]. I suspect a similar problem to User talk:Piotrus/Archive 36#Signature problems. This pipe therefore needs to be either recoded or omitted; I assume that you don't want to omit it, so if you were to amend this to &#124; it should work. n.b. don't use {{!}} instead - signatures must not contain templates. --Redrose64 (talk) 08:38, 16 July 2012 (UTC)[reply]
Users with the default language "en - English" at Special:Preferences see MediaWiki:Tog-fancysig below the signature box. If you have en-gb or en-ca then it's not recommended because you miss many customized messages like this. PrimeHunter (talk) 10:28, 16 July 2012 (UTC)[reply]

Resolved
 – Fixed now. Thanks for the input and the help, everyone! Evanh2008 (talk|contribs) 10:52, 16 July 2012 (UTC)[reply]

insecure content message

I'm new to Chrome (less than 24 hours) so maybe I'm missing something obvious, but when I load https://en.wikipedia.org/wiki/Port_Loko_Teacher%27s_College I get a notice from Chrome that the site has insecure content. I don't see the messgae in Mozilla. I see that I can view other pages on the secure server without the message, the only time I am getting the message is when I go to some of the pages listed as CSD G12 and look at the underlying page.--SPhilbrick(Talk) 11:54, 16 July 2012 (UTC)[reply]

I guess it only happens when you are logged in and open a new tab or window. I don't know your skin but both User:Sphilbrick/monobook.js and User:Sphilbrick/vector.js have content referring to the insecure http://en.wikipedia.org. PrimeHunter (talk) 12:49, 16 July 2012 (UTC)[reply]
You don't have pages for other skins so you should be able to test whether this is the cause by choosing a third skin and opening new tabs or windows. PrimeHunter (talk) 12:53, 16 July 2012 (UTC)[reply]
Your .js pages also have document.write loading, a technique deprecated for 6 years now, and something that definitely should not be used in combination with Chrome or Safari. —TheDJ (talkcontribs) 23:25, 16 July 2012 (UTC)[reply]
Thanks. I'm sure I copied someone else's. I'm not at the computer now, will look into it when I'm home again. --SPhilbrick(Talk) 14:30, 17 July 2012 (UTC)[reply]

WMA button2b.png displaying oddly

Over the last few weeks, File:WMA button2b.png has started to display oddly in {{coord}} and other WikiMiniAtlas contexts, although it appears properly when I visit the image directly. When I hold my mouse over it, the miniature globe displays just like a reduced-size version of what I get when I visit the image description page, but at all other times, the globe is substantially darker and nearly black; due to my colourblindness I'm not sure what colour exactly, but perhaps dark greenish blue. I'm using IE8 like I have for years, and I've been using Windows 7 since last year. Is this perhaps the result of one of our many recent MW upgrades? I searched through {{coord}} and some of its subpages without finding anything. Nyttend (talk) 17:07, 16 July 2012 (UTC)[reply]

No it isn't the result of a MW upgrade. At most it's because User:Dschwen made some changes to his user script WikiMiniAtlas, the script responsible for adding the globes and maps everywhere someone uses {{coord}}. —TheDJ (talkcontribs) 23:23, 16 July 2012 (UTC)[reply]
Hey guys! I have indeed made a little change due to some feedback I got at the Wikimania. I added a mouseover effect that should make the WMA icon light up when hovered. Sorry, it was a bit ad hoc and I did not get to test it in IE. Hmm, but this was just changed two days ago, not a few weeks ago. I'm still on travel right now. Give me two more days and I will have access to an IE and time to debug the issue. --Dschwen 02:01, 17 July 2012 (UTC)[reply]
IE + image + dark... Perhaps the alternative version you added uses a PNG feature that IE doesn't support by default ? We have seen that before. —TheDJ (talkcontribs) 07:51, 17 July 2012 (UTC)[reply]
For the last few days it uses the css opacity property. --Dschwen 13:38, 17 July 2012 (UTC)[reply]
Maybe I'm just remembering wrongly on the date. For me, it lights up when hovered, but only because it's darker otherwise; it's vaguely like a store raising its prices and calling it a sale when it temporarily returns the prices to the old level :-) Nyttend (talk) 20:09, 17 July 2012 (UTC)[reply]
I have confirmed that this is an IE bug triggered by the opacity change. I changed it so that it only looks crappy in IE when hovered. I'm working on a full fix. --Dschwen 21:27, 18 July 2012 (UTC)[reply]

On a side note I realized, that the WMA did not work at all in IE8. This is fixed now. You won't get all the cool stuff, like overlays, but at least it displays map and labels. --Dschwen 23:12, 18 July 2012 (UTC)[reply]

Bolding of unread in Watchlist again...

I'm getting the articles that I haven't read in bold in my watchlist again. Wasn't that turned off?Naraht (talk) 18:13, 16 July 2012 (UTC)[reply]

I'm getting something similar, but whatever they did now is messing up all the scripts etc people have made for customization of the feature. Looks like everything is showing up as "read already", at least for my particular script. I haven't looked into the coding changes yet though, hoping they revert whatever they did soon. Equazcion (talk) 18:16, 16 Jul 2012 (UTC)
(edit conflict) And there once again appears to be no option to turn it off. Not only that but I believe I'm still using manual code written to override the last time this was done, which means the old fixes don't work either. GRAPPLE X 18:17, 16 July 2012 (UTC)[reply]
I checked MediaWiki:Vector.css and MediaWiki:Common.css and neither of them have a change today. Ryan Vesey Review me! 18:18, 16 July 2012 (UTC)[reply]
Yes I came here to ask what on earth . . . it's a sea of bold again, even pages I have visited recently. I thought the RfC demonstrated the majority didn't want this as default? Hopefully something just broke temporarily. Yngvadottir (talk) 18:20, 16 July 2012 (UTC)[reply]
I think that the reason pages that have recently been visited are still showing up in bold is from the database lag, not the styling change (I had the same problem the last time we had lag, and I wasn't using the bold style.) David1217 What I've done 18:24, 16 July 2012 (UTC)[reply]
(edit conflict × 4) Me too. Here we go again... I'm using manual CSS to style my watchlist, and it's getting overridden. Not sure about the scripts problem though. David1217 What I've done 18:21, 16 July 2012 (UTC)[reply]
It looks like they did away with the <strong> tags and replaced them with classes instead? Which if so is actually a good thing in the longrun, as long as it's not styled by default, which it currently is, apparently. It's also breaking all the current scripts and custom css. Some warning would've been good, especially after what we went through last time. Equazcion (talk) 18:23, 16 Jul 2012 (UTC)

(edit conflict)

I am using a patch for now.
/* Patch for now. */
.mw-title { font-weight: normal !important; }
It may be time for a strike. I am getting tired of these code tricks. – Allen4names (IPv6 contributions) 18:25, 16 July 2012 (UTC)[reply]
I suggest someone makes a gadget to hide this feature, something like .mw-changeslist-line-watched .mw-title {font-weight: normal} #mw-watchlist-resetbutton {display:none} . Please do NOT use personal CSS this time, see #Pointless message and button on Watchlist above. — AlexSm 18:26, 16 July 2012 (UTC)[reply]
Do we really have to refight that battle? Roger (talk) 18:31, 16 July 2012 (UTC)[reply]
(e/c)No, any gadget should turn it on - the default should be off - and why did someone decide they knew better - yet again? - Arjayay (talk) 18:32, 16 July 2012 (UTC)[reply]

(edit conflict) Once this feature (presumably) gets turned off by default, would someone please make a gadget for opting-in in preferences? New users will probably get to this feature easier if they don't have to manually edit their CSS page. David1217 What I've done 18:33, 16 July 2012 (UTC)[reply]

Now it is gone. Bus stop (talk) 18:38, 16 July 2012 (UTC)[reply]
For anyone who may have been using User:Equazcion/ReverseMarked to fade old changes rather than bold new ones, I updated the code to work with the changes. Equazcion (talk) 18:38, 16 Jul 2012 (UTC)
A lot of other scripts and CSS customizations will need updating too. Equazcion (talk) 18:40, 16 Jul 2012 (UTC)
I want the bold-faced text, and now it's gone. Is someone fiddling with stuff? Please don't impose your personal preferences on me. I want it to look just like the normal MediaWiki default so that all of my WMF watchlists behave the same. WhatamIdoing (talk) 18:41, 16 July 2012 (UTC)[reply]
(three million edit conflicts) If it was you fixed that, Equazcion, thank you! Panic over until the next time. SlimVirgin (talk) 18:43, 16 July 2012 (UTC)[reply]

I want my italics back. -- Toshio Yamaguchi (tlkctb) 18:42, 16 July 2012 (UTC)[reply]

This time using ".mw-changeslist-line-watched .mw-title { font-weight: normal !important; }" worked for me to turn it off. Fut.Perf. 18:43, 16 July 2012 (UTC)[reply]

  • To whoever turned the boldface off: thank you. I thought we went down this road already, and my recollection is that consensus was established not to spring ugly little surprises on the community anymore. Rivertorch (talk) 18:45, 16 July 2012 (UTC)[reply]
@Slim: It was actually User:Jarry1250 who fixed the default CSS. I just fixed one of my scripts some people are using, not sure if you're one of them. I'm working on Wikipedia:Customizing watchlists to make the tips there work with the new watchlist coding. Check there soon to get code that'll fix all your customizations. Thanks for the explanation, Richard (why no warning beforehand this time though?) Equazcion (talk) 18:47, 16 Jul 2012 (UTC)
What kind of warning were you thinking about? - Jarry1250 [Deliberation needed] 18:50, 16 July 2012 (UTC)[reply]
We've generally been seeing some notice on this page before significant MediaWiki updates, and I kinda woulda expected one before something like this. Though if no one foresaw a visual change I guess I can understand the mistake. Equazcion (talk) 18:52, 16 Jul 2012 (UTC)

I updated Wikipedia:Customizing watchlists. If you have customizations in place that aren't working anymore, go to that page to find the updated code that will hopefully work now. Equazcion (talk) 18:58, 16 Jul 2012 (UTC)

That worked for me. Thank you very much Equazcion, for doing that. --Tryptofish (talk) 19:52, 16 July 2012 (UTC)[reply]
Thanks to whoever it was for having gotten rid of that annoying watchlist-button! Hooray! Jared Preston (talk) 19:57, 16 July 2012 (UTC)[reply]
That would be User:Anomie, who despite being annoyed that no one wants the bold on by default, has apparently finally conceded and removed that button for everyone. And glad to be of service, Tryptofish :) Equazcion (talk) 20:03, 16 Jul 2012 (UTC)
I believe I was the first person to try to remove the button, but it got reverted. If a vocal minority is going to make us be stupid, we may as well be consistently stupid. Personally, I still think that if a few admins hadn't reacted wrongly to the "Oh noes, my watchlist has bold in it! It's the end of the world!" whining when this was first enabled and just made a gadget to disable it like we did the new diff colors, everyone would be used to it by now. Anomie 21:04, 16 July 2012 (UTC)[reply]
It's actually a vocal majority, according to the RfC. I guess we could refer to any opinion against a change as "whining", and assume that all changes are good things we should get used to... but I have to question the validity of that argument. Or is it just the changes you like and others don't? Either way. Equazcion (talk) 22:08, 16 Jul 2012 (UTC)
Yeah I suppose if you count 130 users as a good profiling of the thousands who were instantly affected and didn't complain, or take some equally skewed statistical analysis of an RfC. In reality, the majority of those who were vocal were against the changes. - ʄɭoʏɗiaɲ τ ¢ 22:27, 16 July 2012 (UTC)[reply]
I'm not talking about the ones who instantly voiced an opinion, but the ones who responded to the RfC advertised as a watchlist notice. People who didn't respond must have liked the feature? But then, when it disappeared, wouldn't we have seen those thousands complaining? The RfC notice continued after the revert, and I didn't see an equal -- much less a majority -- of counter-complaints. I guess we could each make a number assumptions about non-respondents that support our respective positions. Equazcion (talk) 22:43, 16 Jul 2012 (UTC)
Can I be one of the thousands complaining? I like the feature, without having to sift through all the garbage back and forth nonsense (Reads more like a silly blog here), how do I opt in again?--Education does not equal common sense. 我不在乎 23:09, 16 July 2012 (UTC)[reply]

Go to Wikipedia:Customizing watchlists and copy the code for your preferred style into your CSS page. David1217 What I've done 23:20, 16 July 2012 (UTC) [reply]

Reverted

Just to clarify, since no-one was actually intending to enable the feature, a few minutes ago I disabled it again, returning us to the place where we were before today. However, you will need to change any user scripts that reference the bolding, replacing "strong.mw-watched" wherever it appears with ".mw-changeslist-line-watched". Regards, - Jarry1250 [Deliberation needed] 18:50, 16 July 2012 (UTC)[reply]

Can you please be consistent and hide the useless button as well (reverting this edit)? The only reason the button was there is that (the last time) some people already customized the feature (e.g. using underline instead of bold) and did not want to fiddle with their personal CSS again. But now they have to change their personal CSS anyway. — AlexSm 18:57, 16 July 2012 (UTC)[reply]
I'm not familiar with the background to those discussions, so I'll leave that to someone who is. - Jarry1250 [Deliberation needed] 19:01, 16 July 2012 (UTC)[reply]
You can use User:Equazcion/RemoveMarkAll to get rid of the button, and anything else left over from this feature. Equazcion (talk) 19:02, 16 Jul 2012 (UTC)
I've got a shitty looking watchlist with green stars and bolding everywhere including the rollback button. FIX IT NOW. THIS IS GETTING ANNOYING.—cyberpower ChatOnline 19:32, 16 July 2012 (UTC)[reply]
Cyber, you've actually got code for that in your vector.css page, that's why you're seeing it that way. It was probably broken before and just started working because of the MediaWiki changes today. Equazcion (talk) 19:36, 16 Jul 2012 (UTC)

I took the advice above and changed "strong.mw-watched" to ".mw-changeslist-line-watched" to get the marking back. I used to have green stars marking unread changes. Now I have every line littered with multiple green stars. Does someone know how to fix this? I would have been just as happy with the default bolding. Why are we making life so hard? SpinningSpark 19:48, 16 July 2012 (UTC)[reply]

Replace ".mw-changeslist-line-watched a" with ".mw-changeslist-line-watched .mw-title", I think that should work. Equazcion (talk) 19:59, 16 Jul 2012 (UTC)
Can we put out a watchlist notice saying, "If you use custom CSS, then replace 'strong.mw-watched' with '.mw-changeslist-line-watched .mw-title'"? Otherwise, we'll have a lot of angry and confused editors. David1217 What I've done 20:03, 16 July 2012 (UTC)[reply]
MediaWiki talk:Watchlist-details would be the place to request that. I'd maybe just point people to Wikipedia:Customizing watchlists instead of putting the techie-code right in the notice though. Equazcion (talk) 20:11, 16 Jul 2012 (UTC)
Drat; I don't know what CSS stands for and don't care to know, except that when I hit the link in the page about how to make bold, to edit my CSS page to bring back the bold unexamined edits, it replies that user page User:Jim.henderson/common.css doesn't exist. I thought creating this file was how I got the bold. Did someone delete it, or did I get the wrong name or something? Jim.henderson (talk) 21:27, 16 July 2012 (UTC)[reply]
Hey Jim! Are you still using the vector skin? The bolding on yours is in User:Jim.henderson/vector.css. In any case it appears like the settings changed a little bit. Try adding the code below to the page, or creating User:Jim.henderson/common.css with the code. Ryan Vesey Review me! 21:33, 16 July 2012 (UTC)[reply]

Code for Jim
span.updatedmarker {
    background-color: transparent;
    color: #006400;
}
.mw-special-Watchlist .mw-changeslist-line-watched .mw-title {
    font-weight: bold;
}
.mw-special-Watchlist #mw-watchlist-resetbutton {
    display: inline;
}
It's at User:Jim.henderson/vector.css, so the CSS only affects the Vector skin (common.css affects all of your skins—I assume you use Vector). Just copy-paste the code from Wikipedia:Customizing watchlists over the old code. David1217 What I've done 21:36, 16 July 2012 (UTC)[reply]
Splendid and it works after some errors of my own. Biggest being, I forgot that I changed to "Modern" because that's the only skin that looks good on my strange "Superpad" tablet that I intend to sell soon. Thank you much, and I long for the day when it's just a button to push in "My Preferences".
Speaking of which, with MSIE9 when I hit any of the line of options at the top of the preferences page, it jumps, not to "Editing" or "Appearance" or whatever, but to the bottom of the "User Profile" page where the E-mail option is. Google Chrome 20.0.1132.57 shows it correctly, however. Again, all with "Modern" skin in Wikipedia though normally I use Chrome only in Commons where MonoBook is my skin. Always there are little bugs somewhere. Jim.henderson (talk) 22:56, 16 July 2012 (UTC)[reply]
I have the same problem on IE8. Very annoying. Was working fine yesterday, now not, and I have no way of knowing what I have looked at already so will stop patrolling my watchlist until it works again. Peter (Southwood) (talk): 17:37, 17 July 2012 (UTC)[reply]

Database lag III

Lag seems to be spiking and disappearing sporadically. It's at 12 minutes now. PS. To plug yet another one of my scripts, you can use User:Equazcion/LagToMinutes to have lag notices display minutes/seconds in addition to the default total seconds, which I find useful during long lag periods. Equazcion (talk) 19:22, 16 Jul 2012 (UTC)

I'm experiencing the lag, too. It seems to be going down, though. Hadger 19:27, 16 July 2012 (UTC)[reply]

GUI for editing tables

I know there are a lot of tools that convert tables from Excel/Openoffice/.csv format to the MediaWiki markup, but so far I haven't seen anything that goes backwards (Wikipedia to Excel), except for this tool that I can't figure out because I'm not a computer programmer. I was wondering if anybody else knows of a way to export Wikipedia tables to other programs so they can be edited in a user-friendly environment, and then exported back to Wikipedia.

What would be really nice is if there were an option in wikiEd to see the table as a table, instead of a jumble of code.

On a related note, there was a proposal from 2007 to move large tables to a different namespace (like pictures) so they don't clutter the editing space. There seemed to be a pretty good consensus for the idea, but I don't see than anything ever happened as a result. ~Adjwilley (talk) 19:11, 17 July 2012 (UTC)[reply]

There is some info here:
commons:Category:Commons charts and graphs
Please add links to those pages to any tools you find. Also, please write up some short tutorials to add to some of those pages. Or create additional pages in the Commons namespace. --Timeshifter (talk) 01:27, 18 July 2012 (UTC)[reply]

Articles I edit not in watchlist

Though I have selected same under preferences, the articles I edit are not in the watchlist. They are, of course, under "my contributions." (I was just forced to reset all preferences due to another error. Then manually select the ones I really needed. The box to display my watchlist edits is selected). Student7 (talk) 00:21, 18 July 2012 (UTC)[reply]

So you've ticked [x] Add pages and files I edit to my watchlist and/or [x] Add pages I create and files I upload to my watchlist, but the software is not respecting your selection, is that correct? Do they appear in the "edit my watchlist" view (either normal or raw)? - Jarry1250 [Deliberation needed] 10:04, 19 July 2012 (UTC)[reply]
One reason that your edits are not showing in your watchlist might be to do with the setting of Preferences → Watchlist → Expand watchlist to show all changes, not just the most recent. If this switched off, you will only get one change per page; but this assumes that when viewing your watchlist, you have not selected "Hide" for any of: "Hide minor edits"; "Hide bots"; "Hide anonymous users"; "Hide logged-in users"; "Hide my edits"; "Hide patrolled edits". For example, you might add {{cn}} to an article, without the |date= parameter. Sooner or later, a bot will come along and add |date=July 2012 to that. The most recent edit is now the bot edit, so if you have filtered out bot edits, that won't show - and nor will your edit, because it's not the most recent change. --Redrose64 (talk) 14:07, 19 July 2012 (UTC)[reply]

JavaScript help needed

Please see:

Mac user needed for test

We need a Mac user to test this. Please go to the above link. --Timeshifter (talk) 05:04, 18 July 2012 (UTC)[reply]

Problem solved. Thanks! --Timeshifter (talk) 07:17, 19 July 2012 (UTC)[reply]

Need JavaScript for middle click to open search in new tab

If you can help with the JavaScript please go to the above link in the beginning of this topic. We have successfully figured out the JS for ctrl-click (PC keyboards) and cmd-click (Apple key on Mac keyboards). Now we are looking to add the JavaScript for middle click. --Timeshifter (talk) 07:18, 19 July 2012 (UTC)[reply]

Duplicated coordinates at Prussian Homage (painting)

Any idea why those coordinates appears on the left and right of the article? --Piotr Konieczny aka Prokonsul Piotrus| reply here 12:08, 18 July 2012 (UTC)[reply]

About three months ago the coords were moved outside the infobox, see here. If you alter |display=inline,title in Prussian Homage (painting) to |display=title it'll fix it for this one article. --Redrose64 (talk) 13:31, 18 July 2012 (UTC)[reply]

Editing oddities

Edit page annoyances. Began happening about the time I "rebooted" my skin to resolve the issue of the non-inserting enhanced toolbar. Currently on Firefox 14.0.1 with Windows XP. This problem was also happening before I updated Firefox and was on 13.0.1. If I'm doing a Delete, or insertion, or something of that nature, it jumps to another place and puts the edit in the wrong place. i.e., if I'm hitting the delete key to erase multiple characters, it will delete a character or two, and then jump to another place and delete in the wrong area. Provelt just disappeared off my screen. But before that happened, I was using Provelt to do insertions on a bibliography list. And it had a tendency to jump the insertion up into another line or paragraph. Maile66 (talk) 14:09, 18 July 2012 (UTC)[reply]

Pending Changes question

I've been asked several times whether we should be considering an application of Pending Changes to long pages or busy pages. I was told at Wikimania (consider this a rumor, but it's a rumor I have to deal with) that some dev said that no substantial changes could be made before the Pending Changes rollout because it would cost a lot of money and take a lot of time. It's hard to know how to proceed here; I'm operating under constraints. Let me just throw out a few statements and ask for informal, off-the-top responses from anyone who wants to volunteer:

  • In most database applications, marking information as read-only tends to make the application run faster when displaying that information; it certainly doesn't make it run slower, right?
  • Merely for the purpose of pondering whether any implementation of Pending Changes necessarily has to run slowly, consider this implementation of PC-level-2 (i.e. a substitute for full-protection), suggested to me in an email: full-protect an article, except that you can still click on the "edit" button, which redirects you to a subpage of that article's talk page, the "working version" of the page. When the edits are "accepted", the old version of the page is replaced by the working version. That's a few extra pages, and surely that wouldn't take a lot of dev time. Can anyone think of a reason that this implementation would be a drain on the servers, or wouldn't be able to handle large or busy pages? - Dank (push to talk) 19:16, 18 July 2012 (UTC)[reply]

URL encoding

I'm having a bit of a problem with URL encoding in {{QRpedia article}}; the "statistcs" link, when used on, say, Talk:Kings Head Hotel, Monmouth„ should go to http://qrwp.org/stats.php?path=Kings_Head_Hotel,_Monmouth Can someone help me, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:05, 18 July 2012 (UTC)[reply]

{{SUBJECTPAGENAME}} will give you the article name without the "Talk:". Any use? -- John of Reading (talk) 21:20, 18 July 2012 (UTC)[reply]
That seems to have fixed it; thanks. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:50, 18 July 2012 (UTC)[reply]

Deducing thumbnail file names for images.

When you submit an image to Wikimedia at:

http://commons.wikimedia.org/wiki/Commons:Upload

The back-end database does several things. Let us say the file name I submit is:

LargePineConeFromTheAngelesNationalForest.jpg

After the file is submitted the system produces the following files in the following locations:

http://upload.wikimedia.org/wikipedia/commons/7/7a/LargePineConeFromTheAngelesNationalForest.jpg

http://upload.wikimedia.org/wikipedia/commons/thumb/7/7a/LargePineConeFromTheAngelesNationalForest.jpg/358px-LargePineConeFromTheAngelesNationalForest.jpg

http://upload.wikimedia.org/wikipedia/commons/thumb/7/7a/LargePineConeFromTheAngelesNationalForest.jpg/143px-LargePineConeFromTheAngelesNationalForest.jpg

http://upload.wikimedia.org/wikipedia/commons/thumb/7/7a/LargePineConeFromTheAngelesNationalForest.jpg/287px-LargePineConeFromTheAngelesNationalForest.jpg

http://upload.wikimedia.org/wikipedia/commons/thumb/7/7a/LargePineConeFromTheAngelesNationalForest.jpg/359px-LargePineConeFromTheAngelesNationalForest.jpg

http://upload.wikimedia.org/wikipedia/commons/thumb/7/7a/LargePineConeFromTheAngelesNationalForest.jpg/459px-LargePineConeFromTheAngelesNationalForest.jpg

http://upload.wikimedia.org/wikipedia/commons/thumb/7/7a/LargePineConeFromTheAngelesNationalForest.jpg/612px-LargePineConeFromTheAngelesNationalForest.jpg

The confusing part is if you look at a file of, say, Margret Thatcher, these file images are replicated thusly:

http://upload.wikimedia.org/wikipedia/commons/f/ff/Thatcher-loc.jpg

http://upload.wikimedia.org/wikipedia/commons/thumb/f/ff/Thatcher-loc.jpg/503px-Thatcher-loc.jpg

http://upload.wikimedia.org/wikipedia/commons/thumb/f/ff/Thatcher-loc.jpg/201px-Thatcher-loc.jpg

http://upload.wikimedia.org/wikipedia/commons/thumb/f/ff/Thatcher-loc.jpg/403px-Thatcher-loc.jpg

http://upload.wikimedia.org/wikipedia/commons/thumb/f/ff/Thatcher-loc.jpg/504px-Thatcher-loc.jpg

http://upload.wikimedia.org/wikipedia/commons/thumb/f/ff/Thatcher-loc.jpg/645px-Thatcher-loc.jpg

http://upload.wikimedia.org/wikipedia/commons/thumb/f/ff/Thatcher-loc.jpg/860px-Thatcher-loc.jpg

The problem with this is I see no pattern in the thumbnail sizes (and file names). They seem, quite frankly, random in size.

So given the image name "LargePineConeFromTheAngelesNationalForest.jpg".

Is there any way of getting a list of all of the thumbnail file names associated with it (without having to download the "home page" for this picture)?

Thanks in advance, Jeff Jroehl (talk) 00:33, 19 July 2012 (UTC)[reply]

There is a means to obtain these thumbnail sizes but it requires some number crunching to accomplish. What seams to you to be random numbers are actually the width of the image in pixels when said image is scaled to one of several standard vertical sizes (240, 480, 600, 768 pixels, or 1,024 pixels). I am not familiar with the specific algorithm(s) used by the Wikimedia software to accomplish this scaling so am unable to scaling so I am unable to assist in providing the exact formulas for the calculations. All in all it is probably simplest to just check the image description file and see what pixel numbers listed for the various sizes. --Allen3 talk 01:10, 19 July 2012 (UTC)[reply]

This was the exact response I was expecting. And this makes complete sense. The problem is that if I have to download image description file for every image, it is a whole lot of bandwidth that would otherwise need not be used. Is there anyplace where I can get this algorithm? Or a place where this algorithm is discussed?

Thanks Jeff Jroehl (talk) 01:21, 19 July 2012 (UTC)[reply]

You might try at the mediawiki support desk. --Tagishsimon (talk) 02:32, 19 July 2012 (UTC)[reply]
This might also be a useful starting link; my eyes started to glaze over... Manual:Image_thumbnailing#Image_thumbnailing --02:36, 19 July 2012 (UTC)

"Eyes glazing over" I got that. I have been trying to figure this out for a week. Jroehl (talk) 03:20, 19 July 2012 (UTC)[reply]

What exactly are you trying to download: presumably not just the wikitext of the file description pages, but the full HTML? Why should the images you need to download be a mystery then - they'll just be written there in the source? Sorry, I'm obviously missing something here. - Jarry1250 [Deliberation needed] 10:01, 19 July 2012 (UTC)[reply]
The multiple and various different resolutions given on file description pages are just examples. You don't need to worry about which ones exist or not, nor what the ultimate filenames are. Just use syntax like [[File:LargePineConeFromTheAngelesNationalForest.jpg|thumb|nnnpx|A pine cone]] - just set nnn to any positive integer, and the appropriately-sized image will be displayed (it will be generated for you if it doesn't already exist). When forcing a size like this, please bear in mind MOS:IMAGES and WP:IMGSIZE. --Redrose64 (talk) 12:57, 19 July 2012 (UTC)[reply]
You can also get the image files directly in any size, by just changing the number in the URL. e.g. http://upload.wikimedia.org/wikipedia/commons/thumb/7/7a/LargePineConeFromTheAngelesNationalForest.jpg/42px-LargePineConeFromTheAngelesNationalForest.jpg. If it doesn't exist already then the servers will generate the thumbnail for you. the wub "?!" 16:28, 20 July 2012 (UTC)[reply]

Wow! That is really cool. Sort of mind boggling really.

I noticed the "42px-" parameter specifies its width.

Is there any way to specify its height?

Thanks Jeff Jroehl (talk) 19:25, 20 July 2012 (UTC)[reply]

This is how to get the width I want.

original_height = 165 original_width = 200

The_height_I_want = 60

width_to_get = original_width * (The_height_I_want / original_height)

? width_to_get && 72 = This is the width to get from Wikipedia.

Jroehl (talk) 00:52, 21 July 2012 (UTC)[reply]

If you want to get a specific height, you can use a file tag thus: [[File:Wiki.png|thumb|x25px]] <-- Note the x (See mw:Help:Images#Syntax for more). You can also use the API to get a specific height image: titles=File:Wiki.png&prop=imageinfo&iiprop=url&iiurlwidth=999&iiurlheight=25. The Image generated will be fit into the box bounded with iiurlwidth x iiurlheight (you must include width parameter in this instance). There is also thumb.php (the 404 handler backend) but it doesn't support a height parameter. --Splarka (rant) 08:22, 21 July 2012 (UTC)[reply]

Sortable icon disappears if coloured

hello,

how do you make the sortable icon in tables visible? It was previously always visible, but now as it was updated it can not be displayed if there is a background-colour. Regards.--GoPTCN 09:19, 19 July 2012 (UTC) [reply]

The workaround described at Help:Sorting#Header styling, links, and markup still seems to be working. Any good? -- John of Reading (talk) 10:14, 19 July 2012 (UTC)[reply]
Thanks, my mistake. Regards.--GoPTCN 10:37, 19 July 2012 (UTC)[reply]

Hi,
I have been watching advertisements on Wikipedia for about 6 months now. I have used different computers and different internet connections but they appear to pop up every where. So has Wikipedia started doing advertisements or these are just accidental? I am attaching a preview so that technical experts can get an idea of what I am facing. They appear on every article.
Preview-1
Preview-2
--Inlandmamba (talk to me) 14:21, 19 July 2012 (UTC)[reply]

They are not from Wikipedia. See Wikipedia:FAQ/Readers#ADS. PrimeHunter (talk) 14:26, 19 July 2012 (UTC)[reply]
You've got malware, spyware or something similar. As a minimum keep your plugins updated. Regards, SunCreator (talk) 14:52, 19 July 2012 (UTC)[reply]
Okay. I'll reinstall my windows and delete the previous one. If the problem is solved, then good otherwise, I'll let you guys know.
Thanks--Inlandmamba (talk to me) 15:13, 19 July 2012 (UTC)[reply]
The culprit is almost certainly the Ilivid Downloader Manager you have there. Judging by the comments here and WOT rating there, letting it onto your computer is not a good idea.--illythr (talk) 19:45, 19 July 2012 (UTC)[reply]

Strange ratings stats

Irish presidential election, 2011 has 55 ratings for "Well-written" (average of 5.0) and 0 ratings for the other three categories. Is this ballot-stuffing or has something gone wrong with its ratings stats? jnestorius(talk) 17:25, 19 July 2012 (UTC)[reply]

Numbered lists in more than one part

Other than using raw HTML, do we have a means to make numbered lists starting other than at number 1? For example:

Apples:

1. Golden Delicious
2. Granny Smith's
3. Worcester Pomains

and my favourites:

4. Cox' Orange Pipin
5. Russets

I can't find anything about this on WP:LIST. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:29, 19 July 2012 (UTC)[reply]

No; but you can force a number by adding a <li value=n> immediately after the hash:
Apples:
  1. Golden Delicious
  2. Granny Smith's
  3. Worcester Pomains
and my favourites:
  1. Cox' Orange Pipin
  2. Russets
It's only a small amount of raw HTML but it does mean that you don't have to code the entire list that way. --Redrose64 (talk) 17:57, 19 July 2012 (UTC)[reply]
Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:32, 21 July 2012 (UTC)[reply]

RefToolbar2 has disappeared again!

As in the subject, RefToolbar2 has vanished again , and DYKcheck has disappeared. I've tried switching from Monobook to Vector and back again, and clearing my cache, but no joy.Nigel Ish (talk) 21:01, 19 July 2012 (UTC)[reply]

IP serial editing on templates

This is not the place to list this, I know. But I think we have a serial thing going on, and I need to know where to get quick action. Any sysops reading this? Please see [1] This IP user is making a whole lot of format edits on templates without discussion. Looks to me like hundreds of template formatting edits. Some have been reversed by another editor. I reversed the formatting changes they did to Template:Texas History, because I don't believe the format of it should have been revised. There was a whole lot of discussion that went on at the Texas project before that template was improved a few years ago. But I don't think this should be happening at all on templates. Please advise. Maile66 (talk) 23:27, 19 July 2012 (UTC)[reply]

First ask the editor to stop and talk about it. If he won't, and you can make a case that he need to be blocked to stop damage, take it to WP:ANI (not WP:AIV as it doesn't lok like vandalism). Mr Stephen (talk) 23:35, 19 July 2012 (UTC)[reply]
Thank you. Maile66 (talk) 23:44, 19 July 2012 (UTC)[reply]

Account usurpation

Hi. Can someone please tell me why bot has not taken my request? Thanks. --Andreateletrabajo (talk) 01:13, 20 July 2012 (UTC)[reply]

It looks like it did, here, but due to the screwed-up section the IP made the formatting was all confused. The long delay was because AnomieBOT's server crashed again earlier today (I'm hoping a kernel upgrade will fix that). Anomie 01:21, 20 July 2012 (UTC)[reply]
Ok, now it seems it make it right. Just need to wait for answer. Thanks, --Andreateletrabajo (talk) 15:31, 20 July 2012 (UTC)[reply]

Self edit conflicts

I've noticed that since I switched ISPs, I've been getting a lot (like half my edits) of self edit conflicts. Just curious if there's a reason for this. Hot Stop 05:21, 20 July 2012 (UTC)[reply]

Perhaps your ISP has some sort of misbehaving proxy service. Try using https version of the website. If that helps, you might want to state which ISP you are using (so others can avoid it) and then call them and complain :D —TheDJ (talkcontribs) 07:27, 20 July 2012 (UTC)[reply]
I have comcast. Hot Stop 03:57, 21 July 2012 (UTC)[reply]

How to sign your posts

For years, my signing - 4 tildes or signature button - results in automatic eMails, telling me, that I do NOT sign correctly (please also see exchange below). WHAT exactly is the Problem?

  • Signed with 4 tildes: Grey Geezer 06:10, 20 July 2012 (UTC)
  • Signed with button: --Grey Geezer 06:10, 20 July 2012 (UTC)

It is not a bad idea to sign your posts by simply typing 4 Tildes at the end of your post. Please see WP:TILDE. Happy editing! Bus stop (talk) 22:03, 18 July 2012 (UTC)[reply]

<sigh> I do this for 5 years now - I also use the "signature button" once in a while - but somehow THE SYSTEM does not accept / see / recognize that.
Now I sign with 4 Tildes: Grey Geezer 07:29, 19 July 2012 (UTC) ...
now I sign by button: --Grey Geezer 07:29, 19 July 2012 (UTC) ... and what happens? ... :
This is what is meant by four tildes: ~~~~. Is that what you are typing? Bus stop (talk) 10:54, 19 July 2012 (UTC)[reply]
Exactly that. I'm editing for 4+ years in the German WP. I now copy/paste your ~~~~ (betw. the nowikis) and I get => Grey Geezer 15:50, 19 July 2012 (UTC)
Maybe if you post an inquiry at the Village pump, technical, somebody there will be able to shed some light on this. Bus stop (talk) 20:36, 19 July 2012 (UTC)[reply]
Thanks! I'll do that. Bothers me since the beginning. Grey Geezer 06:07, 20 July 2012 (UTC)
Try this: go to "My preferences", remove the words "Grey Geezer" from the "signature" box partway down, leaving it empty, and then click the "Save" button at the bottom. The software should then give you the default signature like mine. -- John of Reading (talk) 06:56, 20 July 2012 (UTC)[reply]
That will fix it yes. The problem is that you signature needs to contain a link to either your user page or your talk page. If you don't have either, then the bots will not be able to recognize it as a signature. —TheDJ (talkcontribs) 07:25, 20 July 2012 (UTC)[reply]
The Box is empty.
Above it says "Existing signature: Grey Geezer "
Below: [ x ] Treat the above as wiki markup. i.e. Checked.
Am I supposed to take the "checked" out ? Grey Geezer 11:45, 20 July 2012 (UTC) — Preceding unsigned comment added by Grey Geezer (talkcontribs)
Taking the "checked" out results in => Grey Geezer (talk) 11:46, 20 July 2012 (UTC)[reply]
If the "Signature" box is empty, the "Treat the above as wiki markup" box must be clear. If "Treat the above as wiki markup" is switched on, the "Signature" box must contain at least one of the three links described at WP:SIGLINK. If you look at the row marked "Existing signature", you'll see how your sig will appear (without time and date); when you move your mouse over it, this will reveal any links which are present. --Redrose64 (talk) 13:06, 20 July 2012 (UTC)[reply]
All's straightened out - thanks a lot! Case closed. GEEZERnil nisi bene 13:29, 20 July 2012 (UTC)[reply]

Change of name

Greetings. I recently changed my username on my home Wiki (BS Wiki), so what I have to do to merge my old username (Kukac) and edits with my present name (KWiki) at this Wiki (and other Wikis)? Thanks in advance. -- KWiki (talk) 17:31, 20 July 2012 (UTC)[reply]

It should all be covered at WP:RENAME. --Redrose64 (talk) 17:47, 20 July 2012 (UTC)[reply]
Thank you for your response. I appreciate that. But I still have some questions. I just realized that my present username (which I have unified globally few days ago) represent a different account. Does it mean that "merging" / renaming "Kukac" to "KWiki" is now impossible or I'm getting it wrong? If it is impossible, what I should do with "Kukac" name/account? Thank you for your help and sorry for any bothering. I'm administrator on Bosnian Wiki, but I'm still pretty unfamiliar with this kind of stuff and I don't want to create a mess. -- KWiki (talk) 19:54, 20 July 2012 (UTC)[reply]

How can sortable tables be fixed?

I've noticed this for a long time, but our sortable wikitables are effectively broken. Try sorting List of rampage killers: Americas ascending by number killed. Note that the killers with the most kills appear half way down the list because 28 kills is considered less than 3 kills but more than 23. Is there any way to fix this? Ryan Vesey Review me! 20:58, 20 July 2012 (UTC)[reply]

Use {{sort}} to force a hidden alphabetic code that will sort right, eg: {{sort|03|3}} will print "3" but sort on "03". --MASEM (t) 21:13, 20 July 2012 (UTC)[reply]
Is there any way to modify the underlying code of a sortable table so the workaround isn't necessary? Ryan Vesey Review me! 21:16, 20 July 2012 (UTC)[reply]
We don't have to. We already did that about a year ago. It's just not working, because it depends on some HTML5 syntax, and we still haven't switched to HTML5. Though that is planned for this month I believe. —TheDJ (talkcontribs) 22:03, 20 July 2012 (UTC)[reply]

RM bot inactive

RM bot, which maintains the Requested Moves process, has been inoperative since 18th July. The user running the bot, User:HardBoiledEggs, has been inactive for months. Without the bot, the Requested Moves process does not function. There is a discussion at Wikipedia talk:Requested moves and at Wikipedia:Administrators' noticeboard/Incidents#RM bot inactive, but there is no solution as yet. As things stand, no page moves can be requested, across Wikipedia. Can anyone assist please with repairing the bot? MatthewHaywood (talk) 22:55, 20 July 2012 (UTC)[reply]

Adding a collapsable infobox to a table

Specifically, I wanted to know it if possible to add a template such as {{Infobox D&D creature}} to the tables on List of Advanced Dungeons & Dragons 1st edition monsters for the purposes of merging in articles. The idea is to have it collapsible so that it doesn't take up too much space, but at the same time make it available for anyone who wants to view it. I guess I got some inspiration from how pages like List of minor X-Men characters and List of G.I. Joe video games are organized, so I wanted to bring some of that functionality in. Is this a simple "oh, here you go" fix, or am I asking the basically impossible? BOZ (talk) 00:16, 21 July 2012 (UTC)[reply]

Unless I missing something, per MOS:COLLAPSE, collapsible boxes should not be used for article content (which exceptions for repeated material in infboxes, etc.--SPhilbrick(Talk) 12:30, 21 July 2012 (UTC)[reply]

Archived talkpage discussion

When a bot has archived a talkpage discussion that is still useful and germane, what is the procedure to "un-archive" it and return it to the current talkpage? I'm not sure that at this point I can revert the archiving, but would not want to in any case, because the bot archived several older discussions together, and only the one should be restored. Thanks for any suggestions. Milkunderwood (talk) 03:11, 21 July 2012 (UTC)[reply]

The safest way is to leave the archive alone; raise a new thread on the main talk page, and at the top of that add a link to the archived discussion so that others may refer to it. See for example Wikipedia:Village pump (technical)/Archive 97#Intermittent search problems and Wikipedia:Village pump (technical)/Archive 99#Error on loading page (2) where the link was added at the time that the new thread was raised; or Wikipedia:Village pump (technical)/Archive 95#False edit conflicts where I added two links afterwards - but still at the top. --Redrose64 (talk) 12:05, 21 July 2012 (UTC)[reply]

Talk page template

I there an easy way to add a template message when an IP editor adds a semi-protection request edit template to an article talk page? I just cleared many from the backlog at: Category:Wikipedia semi-protected edit requests. I noticed quite a few that are experienced editors but have never created an account. 'Please create an account to stop backlogging us with trivial requests' type message.--Canoe1967 (talk) 05:27, 21 July 2012 (UTC)[reply]

You could try {{subst:welcome-anon}}, or {{subst:register}}. If these aren't suitable, the place to request a new template is WT:UTM or possibly WT:WC. --Redrose64 (talk) 12:14, 21 July 2012 (UTC)[reply]

Blank error message coming up on watchlist

For some reason today, every time I pull up my watchlist I get a blank error message box that I have to hit "OK" on before I can do anything else. I'm running Windows 7 with Firefox v14.0.1. I've been running this for a few days now and this is the first time I've encountered this issue. Just to be clear, it's only when I click through to my watchlist and the error box is always empty. Has anything changed today that would cause this? Dismas|(talk) 14:09, 21 July 2012 (UTC)[reply]

It could be User:Ais523/catwatch.js called from your vector.js: it has 1 alert() in the code. Try switching to some other skin or clearing your vector.js. — AlexSm 14:27, 21 July 2012 (UTC)[reply]

"My preferences" tabs not working

Under "my preferences" none of the tabs across the top :- Appearance, Date and time, Editing etc. are doing anything. No matter which one I select it stays on "User profile". Is this just me, or a general glitch? - Arjayay (talk) 14:43, 21 July 2012 (UTC)[reply]