:[[72nd Pennsylvania Infantry Monument]] is a redirect to [[List of monuments of the Gettysburg Battlefield]]. See [[Help:Redirect#Creating and editing redirects]]. [[User:PrimeHunter|PrimeHunter]] ([[User talk:PrimeHunter|talk]]) 01:13, 9 April 2012 (UTC)
:[[72nd Pennsylvania Infantry Monument]] is a redirect to [[List of monuments of the Gettysburg Battlefield]]. See [[Help:Redirect#Creating and editing redirects]]. [[User:PrimeHunter|PrimeHunter]] ([[User talk:PrimeHunter|talk]]) 01:13, 9 April 2012 (UTC)
== Improving the watchlist feature for MediaWiki ==
If you or a MediaWiki developer you know is interested in improving watchlists with grouping and usability enhancements, please let me know. I have submitted a clear and practical project proposal for the 2012 Google Summer of Code and I am seeking a mentor. I will, of course, do all of the heavy lifting (coding) to make it happen. All I need from a mentor is knowledgeable guidance and occasional assistance with debugging. Potential mentors can view the project here: [https://www.mediawiki.org/wiki/User:Blackjack48/GSOC_proposal_for_watchlist_improvements] and a partially functional example of the UI: [http://www.sociotopia.com/wiki/wikiwatchlist.html]
The technical section of the village pump is used to discuss technical issues aboutWikipedia. Bugs and feature requests should be made at Bugzilla (How to report a bug). Bugs with security implications should be reported to securitywikimedia.org.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
Problem displaying wikipedia content in iPad application
I'm seeing Wikipedia mobile content not sized correctly when displayed within iPad apps using UIWebView. It is as though the mobile version has the page width fixed to the size of the iPad device, not the actual view it is displayed in.
This is what I'm seeing: [1]
This is what I want to see: [2]
This used to work correctly. I suspect Wikipedia has become smarter in detecting it is displaying on an iPad and adjusting the frame size assuming it is being displayed with the iPad Safari browser.
Is there any way to specify the content width along the lines of http://en.m.wikipedia.org/w/index.php?title=Jupiter&device-width=320.0 (which doesn't work by the way)? — Preceding unsigned comment added by 24.87.55.100 (talk) 02:03, 22 February 2012
Yeah, Asher Feldman is tinkering with some of the boxes; this typically involves taking some capacity out of circulations and then rotating. The replication lag is actually a MAX() type query, hence the high figures. I believe. - Jarry1250[Deliberationneeded]18:02, 20 March 2012 (UTC)[reply]
...I'm going to juggle which db watchlist queries go to during the migration, so nothing should be noticeable on the site.
Ha! I assume that this was all tested on a large non-production database first? I also hope that the thumbnail calculation that someone made about this taking 48 days to resolve is not correct. Fingers crossed for the Wikipedia brand.
Coz MySQL is a toy playing at being a big kid's database. There's ways this could have been done without taking out toolserver, but they would have had the effect of an inconsistent database for a while. And the database schema wouldn't have been identical to production. That's all in the past. Josh Parris09:45, 23 March 2012 (UTC)[reply]
I don't know how this is handled, but if it's a case of being one volunteer and that we should not ask much because it is just one volunteer, maybe that is not enough. North8000 (talk) 10:52, 26 March 2012 (UTC)[reply]
Is there any sort of workaround for this? I believe a large number of projects are set to generate monthly reports on March 31st (I know WP:DPL does so), and the lack of such reports will, for the short term at least, gum up a lot of regular maintenance. bd2412T19:32, 26 March 2012 (UTC)[reply]
Same here; 7,567 for as long back as I can remember. Gosh, I don't even know how many edits I've done in these 8 days! But my Preferences still seems to be working. ~*~AnkitBhatt~*~ 14:36, 28 March 2012 (UTC)[reply]
I am hardly well-versed with any of the complex technicalities of running Wikipedia, but a week-long replication lag is disastrous for the continued running of the project. Edit counters have all become useless as edits for over a week have not been counted. In addition, some events such as WP:INDIA's Tag and Assess event have also been thrown out of gear due to wrong statistics. There seems to be no end in sight, and in my years on Wikipedia I have never had to encounter a replication lag as severe as this. Is there any fixed deadline allotted to rectify this problem? Because we need the replication lag to disappear fast, otherwise too many problems are going to build up. Perhaps setting a proper deadline and strictly sticking to it will speed up the rectification (if it hasn't already been done). ~*~AnkitBhatt~*~ 10:18, 27 March 2012 (UTC)[reply]
For the 99% of us who aren't insiders on this, could you explain? Are you the person who is handling this? Thanks. North8000 (talk) 00:38, 28 March 2012 (UTC)[reply]
I'm sorry, early April? How early? Do you realize how much of a problem this is going to become if this issue isn't fixed by March 31? How can the issue be so severe? It hardly matters what the record is on some other language Wikipedia, enwiki is the biggest by far and needs continuous running. Cracks are appearing all over the enwiki now, for God's sake the lag is 8 days! ~*~AnkitBhatt~*~ 14:34, 28 March 2012 (UTC)[reply]
There needs to be some more transparency here. We really need explained exactly what happened and what exactly is being done. Its causing two many problems.EdinburghWanderer17:14, 28 March 2012 (UTC)[reply]
Agree. If it's just one overloaded volunteer handling a huge and important area, then we should know that. North8000 (talk) 17:43, 28 March 2012 (UTC)[reply]
For future reference, fixes that are likely to cause several days worth of toolserver backup should be implemented towards the beginning of the month, and not towards the end, so that month-end project turnover will be unaffected. bd2412T20:54, 28 March 2012 (UTC)[reply]
So in effect we cannot predict when this problem will get over? In fact you are saying that this problem may not get over at all? What exactly do you mean by "waiting for a process"? What process? Why is it taking so much time? We need answers. I don't now whether you are familiar with the problem, but I expect somebody with knowledge of the problem to clearly specify what the problem is. Drop the vagueness. ~*~AnkitBhatt~*~ 09:02, 29 March 2012 (UTC)[reply]
Thanks for the update, so it's really a case of we don't really know. Could you please keep up us updated on any further updates however minor Thats all we askEdinburghWanderer23:31, 28 March 2012 (UTC)[reply]
Re Ankitbhatt: here is the exact problem: due to a schema change on the live servers, the toolserver databases cannot begin replication again until the schema change runs on them. This is a command that is executed on the database to change the structure of some of its tables, which was part of the latest Mediawiki upgrade.
The update is very slow. So at the moment we are waiting to see which of these happens first: (1) the schema change can finish running on the toolserver database, at which point replication can be resumed; (2) the foundation can create a new dump of the enwiki database, which will already include the schema change. Then this can be imported into the toolserver and replication restarted from there. Importing a full dump is not fast but it may be faster than running the schema change on the toolserver database. The toolserver admins announced yesterday on the toolserver-l list that a fresh dump is being prepared for them [3]. They do know what is going on and they are working to fix it. — Carl (CBM · talk) 11:22, 29 March 2012 (UTC)[reply]
Something to also note is that major database actions are somewhat unpredictable, especially if there's activity on the database. Large database systems have a lot happening under the hood to help with optimization, performance and maintenance. Trying to predict how a particular action will result can be difficult, even with significant testing and planning because live production will always be different than a test database. At my job I'm a developer who uses a pretty large and active database and work closely with our database team on issues. More than a few times an action that all of our planning and testing said would not have an impact ended up causing problems. We've managed to befuddle Oracle a couple of times. Database work is part science, part magic and part black voodoo. Ravensfire (talk) 18:21, 30 March 2012 (UTC)[reply]
Tomorrow we reach the two-week replication lag mark. Early April does not look like the time this problem can get rectified. Has there been any update? ~*~AnkitBhatt~*~ 15:47, 2 April 2012 (UTC)[reply]
To those who have requested an update on this issue: User DaB is one of the people who is working on the problem, and he has provided some more recent information at the bottom of this thread, in the #A little chronic sub-section. — Mudwater (Talk)23:11, 2 April 2012 (UTC)[reply]
Edit count
The edit counter for user contributions seems to have stopped. The current replication lag is more than four days. Is anyone working on it? HandsomeFella (talk) 09:13, 24 March 2012 (UTC)[reply]
Catscan 2 has been showing the same error message for a while now: "MYSQL error : The MySQL server is running with the --read-only option so it cannot execute this statement [INSERT IGNORE INTO cat2 ( catname ) VALUES ( "Suburbs_of_Johannesburg" )]"--eh bien mon prince (talk) 08:31, 27 March 2012 (UTC)[reply]
I've removed the page name from the above link so it appears as a same-page link. This probably means that it will still work when this discussion is archived. Graham8702:53, 28 March 2012 (UTC)[reply]
Extrapolated from 76,000 rows in ~10 minutes to 525 million; halved twice (Moore's law)
12 days
March 31
HDD seek
525 million row * one 3 ms seeks per row
18 days
April 6
Its wrong to assume a single seek for a read and write operation
HDD read + write seek
525 million row * (1 read seek + 1 write seek) * 3 ms seeks
36 days
April 25
Reasonable upper bound
2008 data point
Extrapolated from 76,000 rows in ~10 minutes to 525 million
48 days
May 6
Fudging the rounded numbers and it'll agrees with the 36 day estimate
Officially
We don't know when
Once replicating again the Toolserver catches up typically at a rate of 2-3 sec/sec. So it'll replay 2 or 3 days of edits everyday. At this point it'll miss the March 31 deadline.
The replication lag is caused by the schema update (jira:MNT-1225). If the WMF is done first, we'll try to import their copy (DaB. March 28). The Toolserver cluster is has some corruption in it (DaB. March 8). Asher who's updating the cluster is at some conference apparently (#wikimedia-tech). My numbers (above) are estimates with assumed WMF hardware and superficial understanding of databases. Other than that I don't know any more than you.
Speaking on behalf of the 99.9% who are not jocks and insiders on this, is there somebody willing an able to communicate more clearly to us, and in English instead of jargon and fragmented non-statements? We just need straight talk. If there is a volunteer who is embarrassed by this, don't be; we appreciate what you do and would like to thank you for your efforts. We just need straight talk and then to see how we can help to keep this important function working 99.9% of the time in the future, understand when it will be fixed, and to bring a speedy end to the current problem. Sincerely, North8000 (talk) 23:37, 28 March 2012 (UTC)[reply]
Nobody's sitting there doing anything manually, they're waiting for ("automated") database updates to finish. Nothing much we ordinary users can help with. SD502:40, 29 March 2012 (UTC)[reply]
Yeah, so here's what's happened: The record of each and every single edit ever made has been changed on the servers in Florida. In Amsterdam, the Toolserver has a full copy of Wikipedia. The database software that WikiMedia uses does replication from Florida to Amsterdam, but it's been overwhelmed by the half billion changes to the database. It's desperately trying to copy them over, and while it's doing so it's not keeping up-to-date with ongoing changes to articles - so things like edit counts, date-last-changed, etc aren't making it into the database. Estimates for how long this will take vary wildly, presumably because a "how far have we gotten" can't be obtained - so effectively there's no progress bar. So various ways of making an estimate have been used, but the real answer is "it'll be done when it's done". The whole replication process can be halted by merely restoring a backup of Florida's database over Amsterdam's, and that's what the Toolserver technicians have requested from the WMF, because - what I consider to be the likely case based on the numbers above - it's going to take a very long time. Josh Parris08:45, 29 March 2012 (UTC)[reply]
Hello all,
I am one of the roots of the toolserver and I was asked to do a little explaining what's going on at the moment and where the source of the problem was. A little history first:
At the middle of January both active roots were visiting the datacenter of the toolserver and had no internet-access for several hours. Sometime during the offline-periode the WMF changed the master-db-server of enwiki, because there was a problem with with the old server; that means that the toolserver stops the replication ("replication" is the process that keeps 2 (or more) db-servers in sync) and waits until a root changes the master-config-entry so the replication can continue. The situation was special that time, because the WMF brought the old-master (as slave) back very fast and so the toolserver continued to replicate from the old-master instead of the new-master; as we noticed that, it was already too late. We managed to switch to the new master later, but we were unsure if corruption had happened.
At the beginning of March an toolserver-user noticed a strange result in a database-query and further investigatment proved that our copy of enwiki was corrupt; the only way to fix that is to get a fresh dump from the wmf. We requested a dump at the WMF and were told that it will take a few days. We have 2 servers for enwiki and 1 of them did not show the wrong result – so I changed our setup in a way that only the non-corrupt server is used.
Roughly arround the same time, Mediawiki became version 1.19. The update brought some changes in the database-shema – the most important is the adding of some fields. The adding of a field takes some time, depending how big the table is – it can take days if the table is realy big (like the "history-table" of enwiki).
Of course it is not possible today to switch the english-wikipedia in read-only for some days until the change is done – so the wmf does a trick: they change the database-slaves first (one by one) and when every slave is done, they switch the master to a slave (so a slave becomes master). The toolserver can do that too for normal, because we have 2 servers for enwiki – but not this time because 1 server is still corrupt; also there was some miscommunication between the wmf and us and between the toolserver-roots, and so the update was brought to us with the normal replication – which is bad because now we have to wait several days until the change-command is done until the next command can be executed by the server.
What the near future brings: I requested a fresh dump again at the wmf tonight and the dumping is done at the moment. I think that will be done today night or tomorrow morning. Than it will take some hours to copy the dump over the atlantic. The import will take 2 or 3 days AFAIR and than few hours to catch up the replag – so there will be a non-corrupt- and up-to-date-server real soon (and a second few days later). Today morning 1 of our server finished the update (what a pitty: it was the server that is corrupt for sure) and so I hope that the other server will finish soon too (the server has more load and so it will take longer for normal).
I hope that answer your questions what happened. If you have further question, ask and I will try to answer them here – but please accept that I will not watch this village-pump forever, because enwp is not my home-wiki. --DaB. (talk) 13:50, 29 March 2012 (UTC)[reply]
Thanks, DaB, for the explanation, which I partially understand. It seems that several different problems occurred, and combined to cause this issue. I'm sure many editors appreciate getting your communication about this. For now, one question: Do you have an estimate of when the problem will be completely fixed, and the replication lag all caught up? I'm sure it would be hard to pinpoint an exact hour, but can you estimate it to within, let's say, a day? Thanks again. — Mudwater (Talk)01:01, 31 March 2012 (UTC)[reply]
The revision-table (that's the table which contains the history-data) is importing at the moment; that's one of the last big ones. I would say that tomorrow evening the import should be done. --DaB. (talk) 20:08, 31 March 2012 (UTC)[reply]
I really like the server names :¬) My favourite so far is hemlock ... Is the dump in yet and are we still on track for 01-April finish? Chaosdruid (talk) 03:00, 1 April 2012 (UTC)[reply]
No, the importing is slower then I thought it would be and it is not finished yet. I guess we have to wait until tomorrow. --DaB. (talk) 22:34, 1 April 2012 (UTC)[reply]
DaB. posted earlier today on toolserver-l as follows:
the import of s1 on thyme was finally done this morning (took a few days longer than I expected); replication is already running, replag is lower than 5 days at the moment. I declared it as sql-s1-rr and it is read-only at the moment (to speed up the replication a bit).
I will also switch sql-s1-user to it and will make it read/write somewhen tonight. Shortly after I start the re-import on rosemary. Please note that thyme has no commons-copy at the moment, so joins between enwp/commons are not possible on sql-s1-rr at the moment and will not be possible on sql-s1-user soon (when I start the re-import on rosemary).
Since "tonight" is in Central European Time, I take that (with hope) to mean sometime within the next couple of hours, at which point those tools that rely on user databases (but not those that need to access commons) should become available again. --R'n'B (call me Russ) 18:47, 3 April 2012 (UTC)[reply]
I found some tools on toolserver, such as edit counter, didn't appear recent changes on the English Wikipedia. However, other wikipedia doesn't have this problem. --MakecatTalk13:14, 3 April 2012 (UTC)[reply]
Can someone tell me what is the obsession with edit counters, so I can stop making tools that work like witchcraft and start making popular stuff. And why isn't WP:popups enough? — Dispenser19:31, 3 April 2012 (UTC)[reply]
The Toolserver database is used by many reports and tools; some bots depend upon it. When the replag is high, these processes may be at best inaccurate, at worst may carry out some harmful action which they believe will "correct" a problem which no longer exists on en.wp
X!'s edit counter is one of the easiest ways of checking whether Toolserver's replag is high or not, because it puts a great big message right at the top when replag is high.
Caution: Replication lag is high, changes newer than 3 days, 16 hours, 53 minutes, 31 seconds may not be shown.
I just created {{recent changes}} to create links to the recent changes feature. It works as expected with zero or one parameter, but with the second parameter (for namespace) it doesn't seem to work correctly. The first parameter is the title of the link and can be blank. The second parameter is also optional and is the namespace number to pass to recent changes.
Note that {{#if:{{{2|}}}|namespace={{{2|}}}|}}}} works for the fullurl parser function where it wouldn't work as you might expect in a normal template, precisely because fullurl is a parser function and not a template. Anomie⚔23:02, 30 March 2012 (UTC)[reply]
Thanks! I just started using the parser so I'm still learning. I updated the code and it works better, but {{recent changes||0}} gives [4]. —danhash (talk) 14:12, 2 April 2012 (UTC)[reply]
Wikipedia has gone Blue
The English language version of Wikipedia is displaying as blue for me, no other websites are effected. Basically everything appears as blue apart from infoboxes & wikitables. It happens even when I'm not logged in can someone help please. ★☆ DUCKISJAMMMY☆★ 12:37, 31 March 2012 (UTC)[reply]
I have gone blue for the first time. It is very frustrating - I am used to having Chrome as I like it, not how Wikipedia forces me to. Why has Wikipedia gone blue? Will this be changed? doktorbwordsdeeds23:01, 31 March 2012 (UTC)[reply]
It will be changed back as soon as Chrome fixes their bug; The blue is caused by Chrome misreading a CSS background property. Nothing we can do about it. — Edokter (talk) — 23:24, 31 March 2012 (UTC)[reply]
Wasn't that an April 1st then too? Or was that when they dropped float:center? Sometimes jokes go bad really ugly. -DePiep (talk) 20:43, 1 April 2012 (UTC)[reply]
For one, the renderer won't be outputting deprecated elements in the near future, and I don't think this would be a good idea knowing that much. For two, it's easier simply to add the margin to the given wikitables as desired. --Izno (talk) 02:43, 2 April 2012 (UTC)[reply]
Edit previews fail to display - network problem?
I am still having occasional instances of edit previews failing to display, but if I cancel and try again it works. It is not as bad as the problems covered by bugzilla:35448, but it is a similar sort of thing. In other words, it seems like the response from wikipedia fails to arrive at my end, as though packets are being lost and not re-sent in a timely manner (I'm not sure exactly how this stuff works technically). I had this problem, for example, about 40 minutes ago, close to 2300 UTC. Nurg (talk) 23:41, 1 April 2012 (UTC)[reply]
I'd still appreciate a heads up on how to fix the problem though. I know that there's a way... I'd swear that I've run into that before. — V = IR(Talk • Contribs)05:43, 2 April 2012 (UTC)[reply]
I suggest an update to the move tool. In case a page is moved from an article name with diacritics to a name with diacritics, maybe the tool could add template "R from title without diacritics" to the redirect that is left behind? And vice versa, if an article is moved away from diacritics, then the redirect created should have template "R from title with diacritics" (currently no-existant).
The explanation is the eternal low-intensive "war" on diacritics. If the category transcluded from the template ("Redirects from titles without diacritics") is a valid category, then the template should be added at all times (right?). And the only way to add it is to edit the redirect. But editing redirects, especially after a move, is generally frowned upon, to say the least, as it prevents the page to be moved back, over the redirect.
So whether you're acting in good faith or not, this would be an improvement. Editors who add the template to the redirect in good faith would not involuntarily prevent others from moving a page back, and the same goes for editors who act in bad faith; editing the redirect will not prevent others from reverting the move. There have been cases of this.
A search term in another language will not be found, although it exists in the appropriate Wikipedia.
For example, search Firngleiter in en.wikipedia and no results are found although de.wikipedia.org has a large entry on it. Would it not be better functionality to check foreign language search terms in the other databases? — Preceding unsigned comment added by 206.116.217.47 (talk) 16:08, 2 April 2012 (UTC)[reply]
I created File:Wp first edition.jpg a long time ago. At one point in 2009, a user who's now blocked reverted one of my edits to it and then reverted himself. Now it seems all previous revisions are gone, leaving only his latest. Seems petty but I was sort of proud of this little creation and would like to see my name back in the history. Can an admin check if the previous revisions are un-hideable? I don't remember there being any reason for hiding them. Thanks. Equazcion(talk) 18:35, 2 Apr 2012 (UTC)
Well, the history magically re-appeared after I attemted to restore the old versions, got an error, but no log entry. How's that? — Edokter (talk) — 18:47, 2 April 2012 (UTC)[reply]
Looks good now, thanks, whatever you did :) Equazcion(talk) 18:49, 2 Apr 2012 (UTC)
Correct. Does not look like that. Is not a red thing. Is a mostly a yellow/ blue map or Russia surrounded by the normal sea / other countries. --Tagishsimon(talk)01:31, 3 April 2012 (UTC)[reply]
Could it be that it's your adblocker software? The image file resides at a URL that has the "/a/ad/" components: [5]. Try whitelisting the *.wikimedia.org and *.wikipedia.org domains from your adblocker. Lupo10:42, 3 April 2012 (UTC)[reply]
Could be a McCarthy-era close-up. Your browser is still harboring some latent hostility. Equazcion(talk) 10:58, 3 Apr 2012 (UTC)
There is a predictable system in folder names like "/a/ad/". It's the first two characters of the md5 hash of the filename. See mw:Manual:Image Administration#Data storage. Breaking the system and changing individual folder names because some users have odd software blocking them sounds likely to create a lot more problems than it's worth, for example making some existing software unable to find the files. PrimeHunter (talk) 21:56, 3 April 2012 (UTC)[reply]
slow script on history pp.
It's annoying to be unable to use a Wikipedia page, even unable to scroll it or switch browser tabs, or to have my browser switch browser tabs unsolicited from elsewhere to a tab the browser chooses, because a script is running and the browser eventually says the script is slow and asks if I want to stop the script. Of course, I stop it. I've even had the experiences on a public terminal running Windows XP and Internet Explorer and on another public terminal running IE 7, probably on Windows XP. I assume those are reasonably fast enough that slowness on them should be cause for concern among script writers, even if accesses from slower computers are not of much concern (and I would disagree, given the desire for Wikipedia to be accessible worldwide). I also notice the effect on my laptop running Fedora 10 Linux and Firefox 3.x. I notice this lately with an article history page and user talk history pages, including when I use the browser's Back function to revisit an already-loaded page. Could you please speed up script operation in your designs? Nick Levinson (talk) 15:48, 3 April 2012 (UTC)[reply]
NUMBEROFVIEWS Magic word
There's a magic word, {{NUMBEROFVIEWS}} which lists "number of page views". It seems to be coming up with a number which is dramatically too small for enWikipedia: I show it at 63,208,806 (currently displays Template:NUMBEROFVIEWS). Of course this seems too small for a Wiki which has hundreds of millions of edits. It also does not seem to be changing as rapidly as we might expect. Anyone know if this is a bug, or there's some subtlety to the definition of "views"? Thanks, --TeaDrinker (talk) 18:32, 3 April 2012 (UTC)[reply]
Thanks; looks like the number is not changing. I wonder if it was the number of views before switching to some cashing approach. --TeaDrinker (talk) 10:12, 6 April 2012 (UTC)[reply]
We want to bring 100-150 people together, including lots of people who have not attended such events before. User scripts, gadgets, API use, Toolserver, Wikimedia Labs, mobile, structured data, templates -- if you are into any of these things, we want you to come!
We also have other upcoming events where you can learn more about MediaWiki customization and development, how to best use the web API for bots, and various upcoming features and changes. We'd love to have power users, bot maintainers and writers, and template makers at these events so we can all learn from each other and chat about what needs doing. Check out the the developers' days preceding Wikimania in July in Washington, DC and our other events.
Numeric sorting has been a long standing but fixable issue, however the "Value" column you refer to uses different currencies. Moreover I'm guessing they should be US dollars and British pounds but some of the acquisitions listed were Canadian. — Blue-Haired Lawyert—Preceding undated comment added 11:52, 4 April 2012 (UTC).[reply]
If you put any figure - like 0 - into the empty Value cell on the first row, the column becomes sortable. Perhaps you could put a hidden dummy value there. --Redrose64 (talk) 12:47, 4 April 2012 (UTC)[reply]
List of article I created
Problem: I was able to get a list of article I created with this tool. But now it says "403: User account expired". Is there an alternative tool to get such a list without having to register first or to contact anybody by mail? Thanks in advance.--Antidiskriminator (talk) 11:37, 4 April 2012 (UTC)[reply]
I use the template "Template:Election summary party" every so often, though have only discovered today there is no easy way to create an entry for a party which has no article. These parties are registered but are not notable enough for Wikipedia articles, so ideally I need "Template:Election summary party with no link" or something similar. I can see that STV election box templates have this exact requirement. However I know nothing, nada, nowt about what part of the template I need to keep everything as is with the addition of an uncoloured or white square to indicate 'other party'.
I think you're supposed to use |party=Other if it's not set up yet. Or you can make a templates at Template:Partyname/meta/shortname for the name to display in the table and Template:Partyname/meta/color for the color of their cell. — Bility (talk) 17:57, 4 April 2012 (UTC)[reply]
Around 5 days ago everything disappeared from the top of every Wikipedia Page. Mostly I'm annoyed with how I can't search for anything. I have to figure out what the link is for searching. Any help figuring out how to fix it so I have my search at the top of the page will be incredibly helpful. — Preceding unsigned comment added by 173.183.165.30 (talk) 18:57, 4 April 2012 (UTC)[reply]
This is something I haven't encountered before. Starting just over two hours ago, I haven't been able to open any pages on the English Wikipedia using Firefox. I can get into other-language Wikipedias with Firefox, and anywhere else on the Web, and I can open EN using other browsers. But EN and Firefox have suddenly become incompatible for me. Is it just my machine? SlimVirgin(talk)04:56, 5 April 2012 (UTC)[reply]
No problems here, I'm using Firefox 11 on EN for the past half hour. Another browser might've gone to a different server? Try clearing your cache and cookies maybe. Equazcion(talk) 05:10, 5 Apr 2012 (UTC)
Lucene search is a cheapie and does not recognize not only ® and ™, but a half of symbols, and probably even more. Developers are apparently indifferent, so we have to make an independent search engine. Is somebody interested in a simple title search based on the Toolserver? Incnis Mrsi (talk) 06:44, 6 April 2012 (UTC)[reply]
At the bottom of what? Lucene2 is a cheapie, but MW developers are indeed not morons to index and search in final HTMLs. The wiki code (either source one, or after transclusions – I do not know which of two) is used. Incnis Mrsi (talk) 07:58, 7 April 2012 (UTC)[reply]
Some change in MediaWiki broke two templates in a weird way. Any ideas?
Template:Clarifyref and Template:Clarifyref2 no longer work properly. MediaWiki is doing something very strange, interpreting [[something]], inside a <nowiki>...</nowiki>, inside a template's popup tooltip output as if it were an external link! Never seen this weirdness before, and these templates have worked fine for years but are boogered now. — SMcCandlishTalk⇒ ɖ∘¿¤þ Contrib.12:42, 6 April 2012 (UTC)[reply]
I want to change the main colors of my Vector skin, partly so it's always visible whether I'm logged in or not. Is there an example of customized CSS I could look at?
(I also want to experiment with colors for Vector on Appropedia - Vector's nice, but if Appropedia's skin looks the same as WP's skin, it gets confusing.)
The only way to change the colors when you're logged out is to add some javascript or css to your browser (as I've never done it, I only know that it exists...), to possibly load custom css on your side or possibly the css at your vector.css page. --Izno (talk) 15:35, 6 April 2012 (UTC)[reply]
Mass talk page notice and email for HighBeam Research Applicants
The HighBeam Research collaboration, in which 1000 free accounts were donated to Wikipedia editors, will result in at least 400 talk page messages and 400 emails to: 1) notify people that their accounts were approved and 2) deliver their account activation code along with instructions. I'd like to automate the notification process as much as possible. Is there a way to efficiently message the 400 applicants in one go? Is there a way to email them on the same scale? I'd like to avoid having to make 800 different actions; I'm also assuming this wouldn't be considered spam since each editor has actively signed up. Thanks for your help. Ocaasit | c13:27, 6 April 2012 (UTC)[reply]
My understanding is that the account activation code is unique to each account; this adds complexity that I presume no existing bot can deal with. Josh Parris23:29, 6 April 2012 (UTC)[reply]
The bug was opened for clarification of the preference on using the wikieditor (the javascript-based edit toolbar and related tools). This has ended up in a patch being submitted and merged which enables the editor for all users by default and takes away the preference switch.
This basically means that the related javascript will always load. I find that to be a little detrimental to attracting new users. Users may not have internet connections which are speedy enough to load extra javascript, or users may not want the toolbar. Many users would probably like/need it, but there may be some who do not want/need it. While the intention is to make editing easier for the majority, that does not mean we should take away the choice of the editor altogether.
I think this problem could/should be better handled by clarifying/fixing the preferences language, or by adding individual switches for the stuff the current preference enables with one switch.--Siddhartha Ghai (talk) 04:56, 7 April 2012 (UTC)[reply]
I am not much of a editor but IMHO new users will find it easier to edit with the toolbar. Most new users are unaware of what they can change in the preferences, and also don't know much of wiki formatting; WikiEditor makes this editing easy for them.--Nischayn22 (talk) 06:25, 7 April 2012 (UTC)[reply]
As I have already stated, that can be easily accomplished by turning it on for IP users or new users by default. It doesn't require taking away the choice from established users of disabling the toolbar, which they may wish to do due to various reasons.--Siddhartha Ghai (talk) 08:04, 7 April 2012 (UTC)[reply]
If I'm understanding this properly, that doesn't seem good at all. Aside from being slow, needless, or whatever to some folks, said edit toolbar also doesn't entirely work in all browsers - not only would it be annoying in general for the usual picky folks, but removing the option for those for whom it has unintended side effects is just bad. — Isarra༆08:33, 7 April 2012 (UTC)[reply]
This patch doesn't seem to be intended to enable the javascript edit toolbar by default. According to the bugzilla thread, it enables by default the "Enable dialogs for inserting links, tables and more" option in Preferences -> Editing -> Usability features (the preference is still present for me right now). This option added a search/replace button to the toolbar, as well as popup dialogs for the link and table buttons (whereas before those buttons just pasted some empty generic code directly). Being that they're simply changes to the toolbar, I'm assuming that if your toolbar is disabled, the javascript for those dialog boxes won't be loading -- and even if it did, it seems a negligible amount. Equazcion(talk) 09:40, 7 Apr 2012 (UTC)
No scrollbars show up for me in the diff, aside from the ordinary vertical browser one. Equazcion(talk) 17:49, 7 Apr 2012 (UTC)
Search results no longer appearing
If I use this page for searching, I no longer get a list of search results. For example, this search for 'crane' does bring up 'There is a page named "Crane" on Wikipedia', but the page doesn't list other search results as it used to. Is there something wrong, or am I mssing something?--A bit iffy (talk) 07:44, 8 April 2012 (UTC)[reply]
Works fine for me right now. Is it still broken for you? Maybe it was a momentary burp in the server, or a dev created and immediately fixed a bug. Someguy1221 (talk) 08:13, 8 April 2012 (UTC)[reply]
Thank you for figuring that out, nice detective work. I've moved one of the div tags - it looks like the closing div tag was hidden by default, which caused the behavior. The page is now fine, but I wouldn't think a misplaced tag should affect the interface like that. --Bongwarrior (talk) 13:04, 8 April 2012 (UTC)[reply]
If you or a MediaWiki developer you know is interested in improving watchlists with grouping and usability enhancements, please let me know. I have submitted a clear and practical project proposal for the 2012 Google Summer of Code and I am seeking a mentor. I will, of course, do all of the heavy lifting (coding) to make it happen. All I need from a mentor is knowledgeable guidance and occasional assistance with debugging. Potential mentors can view the project here: [8] and a partially functional example of the UI: [9]
wikimedia.org.
Resolved
Jared Preston (talk) 14:07, 3 April 2012 (UTC)
![[1]](http://www.gosoftworks.com/download/wiki/What_I_see.png){kind=link}
![[2]](http://www.gosoftworks.com/download/wiki/What_I_want.png){kind=link}
![[5]](https://upload.wikimedia.org/wikipedia/commons/thumb/a/ad/Russia_edcp_location_map.svg/640px-Russia_edcp_location_map.svg.png){kind=link}