Wikipedia:Village pump (technical)

Policy

Technical

Proposals

Idea lab

Miscellaneous

• Table of contents
• First discussion
• End of page

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 securitywikimedia.org or filed under the "Security" product in Bugzilla. Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

« Older discussions, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111

Centralized discussion
Proposals	Discussions	Recurring proposals
Binding RfC on how to word the lead section of the Jerusalem article RfC on whether preemptive semi-protection of an editor's own user pages should be applied upon request RfC on the implementation of a new platform linking to libraries RfC on whether to implement pending changes protection level 2 RfC on images in "Today's Featured Article" on the main page Petition to the WMF on handling of interface changes RfC on the Main Page's design, content, and purpose RfC on the return of the orange talk page notification banner (removed as of April 30). Should plays list awards or only the most prestigious awards? Should English Wikipedia conduct a readership survey? RfC on adding expiry options to watchlisted pages. RfC on WP:MOS-AM, possible change to article content guideline. RfC on WP:DIPLOMAT, possible change to biography notability guideline. RfC on the use of the account creator flag for purposes other than account creation. RfC about the new speedy deletion criterion G13's scope. A proposal to merge WP:AFD, WP:PM, and WP:ATD-R into a single Articles for discussion process. RfC about whether the authors of copyrighted images should be credited in a footnote in the article where the image is used. Note: inactive discussions, closed or not, should be archived.
archive talk edit history watch

FYI: Toolserver web tools and bots down

Our friendly toolserver admins/roots are aware (see mailing list). In the meantime, migrate to Labs! Theopolisme (talk) 01:12, 12 May 2013 (UTC)

That depends on how much the WMF is willing to pay me. They have a spectacular record of pushing ahead with bad ideas and then ditching them. Not worth the opportunity cost of developing something else for the community. And there's some comfort knowing the WM-DE can run Wikipedia if another image filter debacle comes up. — Dispenser 03:01, 12 May 2013 (UTC)

To put the above in a wider context, Toolserver users (of which I am one) have invested hundreds (if not thousands) of voluntary hours building useful tools to aid in the writing and maintainance of Wikimedia projects like Wikipedia. Differences between the way Labs and the Toolserver work mean that it'll take quite a bit more voluntary effort to move things over. Many (most?) Toolserver users are struggling to justify putting in this work until there's an expectation that Labs will offer some advantage to our tools. - TB (talk) 11:22, 12 May 2013 (UTC)

This worries me greatly. Every system this important should have a backup. What, exactly, would it take to make a backup toolserver that would keep running if the main one went down for an extended period? If funds are required, we can raise our own, independently of Wikipedia. bd2412 T 12:59, 12 May 2013 (UTC)

Let's see ... bare minimum, three server boxes, rack space + pipe, 0.5 FTE admin and a data feed from Wikimedia ... $60k + $60k/year. Realistically, around double these figures to run a useful equivalent as a backup. - TB (talk) 17:06, 13 May 2013 (UTC)

You could run it for way less than that using cloud services like EC2, rackspace cloud, hp cloud, etc.. I recommend using rackspace/hp or one of the other OpenStack based clouds for compatibility with Labs. If you'd like to have independence from WMF, we don't discourage it. Everything we're doing is open source and in Gerrit. I've been building Labs with forkability specifically in mind. I believe our current database replication strategy should make it easier for us to define non-labs replication targets if the community finds it necessary.--Ryan Lane (WMF) (talk) 01:01, 15 May 2013 (UTC)

That's good to know thanks. Not sure how the plan is progressing - are things in a position yet to give and easy estimate of the bandwidth required to accept a feed of the binlogs from PreLabsDBDBS? - TB (talk) 18:34, 15 May 2013 (UTC)

Sorry, no bandwidth estimate at this time. I do have an update on (legal) requirements for this, though. It'll require an NDA for anyone with direct access to the replication and the servers must be located in the US.--Ryan Lane (WMF) (talk) 18:25, 21 May 2013 (UTC)

Far as I know, independence is the underlying problem. German Wikimedia Chapter run Toolserver and don't have enough money. WMF don't want to give them the money and instead will replace Toolserver with something much better, in-house. Someday. Jim.henderson (talk) 13:08, 12 May 2013 (UTC)

Then how can we either support the German Wikimedians in their efforts, or begin our own. We absolutely must have tools that are independent of such "political" concerns. Important repairs can not be done, and are falling behind. bd2412 T 13:22, 12 May 2013 (UTC)

The 2013 WM-DE budget is 5 million € and includes Wikidata development. It is the uncertainty of running a service that is largely dependent on WMF not threatening to cut off the database feed. That feed makes the Toolserver different from other chapter run servers.
The WMF attitude of throwing away and redoing what works deters and detracts programmers ("Why should I make it if its going to be thrown out anyway?") and leads to when announcements are made that work in the area stops. They also internally price volunteer effort at zero dollar; which is why they have so many reader focused initiatives (and helps brings in donations to boot). — Dispenser 14:39, 12 May 2013 (UTC)

I wouldn't worry too much about Labs being ditched. It's an integrated part of WMF's development and testing process (the deployment-prep project) as well as a development and demo location for hackathons and such. It also greatly reduces the load on the operations team as it allows our staff and volunteer developers to make infrastructure changes (and the project is run by the operations team).--Ryan Lane (WMF) (talk) 01:10, 15 May 2013 (UTC)

• Comment My understanding is that Wikimedia Labs is replacing the toolserver. The WMF planned to stop supporting the toolserver at the end of 2013 in favor of Labs. That caused WMDE to remove their funding, which is 90% plus of the operating costs. From what I've read, the tentative plan is to decommission the toolserver at the end of 2014 and give away the servers. Meaning there will be no toolserver 2 years from now. This is all tentative, but I have not seen any other plans to keep the toolserver running at this point. As far as I know, WMDE will decide what happens on May 25th, 2013 when they get together, but there is something of a Toolserver vs. Labs controversy (see here and here), so who knows what will happen. 64.40.54.26 (talk) 14:54, 12 May 2013 (UTC)

For more information there is https://meta.wikimedia.org/wiki/Future_of_Toolserver but I don't know how up-to-date that is. --AKlapper (WMF) (talk) 09:08, 13 May 2013 (UTC)

That document is rather outdated, as it represents the picture last September while many things were still rather uncertain. I don't think we currently have a clean overview document of the current status, although the current TODO list gives a good idea of the current completion. In practice, any tool that does not need direct access to the replicated database can be hosted in the Tool Labs already (and many already are. — MPelletier (WMF) ^(talk) 01:40, 15 May 2013 (UTC)

Hi all! WMDE has several reasons to discontinue the toolserver. This is not only about WMF's database dumps or about funding but the whole project is complicated to run the way we've been doing it: The toolserver has grown to become an infrastructure of ~25 servers, that has been taken care of by only two part-time/volunteer admins. (They will be three from now on to improve the situation.) It has become an essential part of community development for Wikimedia projects: Such an infrastructure requires more planning of capacities and a good documentation of the setup. We do not want a project that completely depends on very few individuals. (For example, it should be possible for an admin to leave without the whole project collapsing.) For us, there is a physical barrier, too: The toolserver is in a data center in the Netherlands to which WMDE doesn't have access (WMF has, but nobody is on-site or very close to it permanently). So the process to replace hardware there is always tedious. So the toolserver now has a size and importance that would greatly benefit from a more professional surrounding in organizational matters and we think that WMF can offer this with a bigger ops team (consisting of paid staff and volunteers) and the cloud-based concept that is integrated into a larger setup. As to the most recent status documentation, here are some links: Roadmap for the migration, Overview of features needed in Tool Labs, WMF database plan (for the db replication issue), List of tools running in Tool Labs: http://tools.wmflabs.org/, First draft of FAQ (tbc) That said, WMDE will continue to run the toolserver until Tool Labs is ready and volunteers have had a reasonable amount of time to migrate (one year as you can see on the roadmap). Silke WMDE (talk) 10:29, 15 May 2013 (UTC)

tools:~dispenser

Not sure if this is related to the above post .....but we have some links (as seen below) that are on hundreds of page (mostly project and help pages) that are not working. Will they be returning or should we get a bot to go around and remove the tools?Moxy (talk) 06:21, 12 May 2013 (UTC) tools:~dispenser....like

• Reflinks
• Checklinks
• Dab solver

Yes, it's the same problem. Sounds like Dispenser is refusing to migrate to Labs, which might make things a bit difficult for these tools down the track. In the short term, though, I would expect that they will start working again before long. — This, that and the other (talk) 06:51, 12 May 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Also intermittent problems when clicking on geographical co-ordinates on any Wikipedia article, as this also uses toolserver. Getting "Bad Gateway", time-outs and so on. In the meantime I've taken to manually copying and pasting the co-ordinates from the articles directly in to Google maps. Also issues with other tools I use such as GLAMorous - indeed it appears like it is all to do with the same underlying issue. Rept0n1x (talk) 07:39, 12 May 2013 (UTC)

So, now it's a second day without these services. Will it be another two weeks before a decision is made? And perhaps months for something actually to go live? Ought relevant templates such as "coord" be hidden until then? Jim.henderson (talk) 11:44, 13 May 2013 (UTC)

So, an hour later, Geohack etc are working. I hope something steadier can be established soon. Jim.henderson (talk) 12:47, 13 May 2013 (UTC)

DYK tools

This also affects Did You Know, since all nominations there have to be checked for copyvio and close paraphrasing. The tools that I'm aware of affected by this are:

• Earwig @ Toolserver Copyvio Detector
• Duplication detector

— Maile (talk) 11:58, 13 May 2013 (UTC)

The Duplication Detector now resides at https://tools.wmflabs.org/dupdet/ . MER-C 12:59, 13 May 2013 (UTC)

Thank you! — Maile (talk) 13:11, 13 May 2013 (UTC)

WP:AFC tools

{{AFC submission}} links two of the tools, Webreflinks http://toolserver.org/~dispenser/cgi-bin/webreflinks.py and CitationBot http://toolserver.org/~verisimilus/Bot/citation-bot/doibot.php - both passing the name of the proposed article as a parameter. This appears on the several hundred articles currently backlogged at Category:Pending AfC submissions as a means of cleaning up bare references on newly-submitted pages. These were down but seem to be back up at the moment; will there be more issues with these in the future? K7L (talk) 16:26, 13 May 2013 (UTC)

Year with comma

Tracked in Bugzilla
Bug 48692

I know - I'm a pedant. I wouldn't do a lot of the WP task I do if I wasn't. But one thing rankles me every time I look at a contribs page, and there must surely be an easy fix to it. Go to your "user contribs" page, and in the box at the top you will find "From year (and earlier): 2,013". Is there some way the comma can be suppressed to make the year numbers right and stop the strange itching I get whenever I see it? It also strikes me as odd that you can check all contributions from, say, 1890 and earlier - but that's an even more minor problem... Grutness...wha? 01:54, 12 May 2013 (UTC)

I don't see a comma. It says 2013 for me. —Designate (talk) 02:07, 12 May 2013 (UTC)

Perhaps it's a problem with the MonoBook skin I'm using - here's a screenshot of how it appears for me. Grutness...wha? 11:22, 12 May 2013 (UTC)

Nope, monobook is fine for me. It could be your browser - are you using Safari on Mac? -- King of ♥ ♦ ♣ ♠ 11:33, 12 May 2013 (UTC)

(edit conflict)Let me guess... you're using a very modern browser? Chrome or Safari, maybe? Your browser is seeing that the year field is described as containing a "number", and so it is kindly providing you with thousand separators and a nice little up/down spinner. However, the separators shouldn't be seen for year values. I wonder if there a way around this in the HTML5 specification... — This, that and the other (talk) 11:40, 12 May 2013 (UTC)

Another possibility could be user scripts. One of those might be interfering. I've not looked at specifics, but I notice that User:Grutness/common.js is lacking a "); from the right-hand end of its single line. --Redrose64 (talk) 11:51, 12 May 2013 (UTC)

Using the Vector skin, I see the comma in Safari (iPad) but not in Firefox. JohnCD (talk) 12:07, 12 May 2013 (UTC)

That's Safari showing the year as a pretty number. The field has type "number", so there is no indication that it is even a year. Ideally, the type should be "month" to combine both fields, but IE and Firefox do not support this type. — Edokter (talk) — 12:35, 12 May 2013 (UTC)

It's curious that the <input>...</input> element allows type=month as an attribute - which is actually a year/month combination - but has no type for year alone. --Redrose64 (talk) 13:23, 12 May 2013 (UTC)

Is there a bug report for this already ? —TheDJ (talk • contribs) 17:04, 12 May 2013 (UTC)

Perhaps https://bugs.webkit.org/show_bug.cgi?id=62939? Although that indicates the bug has been fixed for some time now, and I see correct behavior (no comma, but spinner controls) in Chromium 26. But when Apple will update Safari, I have no idea. They don't seem to make their bug reports public. Anomie⚔ 18:27, 12 May 2013 (UTC)

Sorry I didn't get back to this sooner, yes it's Safari I'm using, but not a very recent one - 5.1.7. Grutness...wha? 02:16, 16 May 2013 (UTC)

Yes that would explain. I don't see a good way to fix this, without javascript trickery (or dropping support of the new HTML5 field validation), which seems a bit over the top to me. I think we better let this one be. I did add it to the tracker, in case others encounter the problem. —TheDJ (talk • contribs) 19:44, 21 May 2013 (UTC)

Search and replace regular expression option

I've been experimenting with the regular expression option in the advanced drop down of the edit window and I keep bumping into problems. When I try to do a lookaround I can match the thing I'm looking for but I can't seem to replace it.

For example, in here I can track the placings from 1st to 3rd with "\d (?=\w)", but replace does nothing (even though it tells me 123 replacements are done!). I get a quantifier error when trying to use lookbehind (?<!X) too.

I might just be completely noobing it (I've only just started playing with regex patterns), but I'm a bit lost. Why isn't this working? And, more importantly, why is there no documentation for this tool? SFB 17:45, 15 May 2013 (UTC)

this tool is powered by javascript, and unfortunately, JS regex has a few shortcomings. specifically, it does not support "lookbehind", and is not likely to overcome this anytime soon. peace - קיפודנחש (aka kipod) (talk) 21:31, 15 May 2013 (UTC)

Fair enough, but why does the replace function fail when using a lookahead? SFB 18:22, 16 May 2013 (UTC)

if you are certain the regex you entered is "kosher" and "search and replace" did not execute it correctly, you should probably open a bug in Bugzilla:. make sure the regex you try to execute is correct, e.g. by pasting the article into regex-capable editor, and testing your regex there. קיפודנחש (aka kipod) (talk) 05:35, 19 May 2013 (UTC)

Cool. I'll do just that. Replacing with that regex works here (another Javascript editor) so I guess it's a bug. SFB 10:43, 19 May 2013 (UTC)

Bug reported SFB 11:04, 19 May 2013 (UTC)

Special:Nearby lets you see all the Wikipedia articles around you

Hi folks,

Wanted to let you know that there's a neat new feature out on Wikipedia – articles nearby! Anyone on a compatible device (mobile or laptop/desktop device that supports JavaScript and location data) can visit Special:Nearby and see a list of the Wikipedia articles that are near them. This feature relies on the GeoData extension and API, so if you know of an article around you that doesn't show up on the list, consider adding {{Coord}} to it :)

Nearby was originally built for the mobile site, since users on camera phones are able to take a picture of things near them that are missing lead images (designated by the little blue camera icon) and upload to Commons + add a thumbnail to the top of the article in one easy step via the Wikipedia mobile site. But we figured it would be useful for non-mobile users, too :) There's currently one known bug (clicking the search box after loading the page causes some mobile code to leak in and disrupt the experience a bit) but we've got a fix and should have that taken care of soon. Take a look and let us know what you think! Maryana (WMF) (talk) 19:17, 15 May 2013 (UTC)

It's great to finally see this truly integrated. Points to the mobile team for building our very own geo database. —TheDJ (talk • contribs) 19:34, 15 May 2013 (UTC)

Very neat, indeed. It even showed something just a few minutes away by car as the top choice. ♫ Melodia Chaconne ♫ (talk) 22:20, 15 May 2013 (UTC)

An option to display distances in miles would be nice. Killiondude (talk) 22:38, 15 May 2013 (UTC)

Now that Wikipedia knows my location to within 10 metres, do we need an update to the privacy policy? Is this information retained anywhere? -- John of Reading (talk) 06:40, 16 May 2013 (UTC)

Maybe we need something like "Wikipedia is not Grindr". --Redrose64 (talk) 08:21, 16 May 2013 (UTC)

There are two parts. Geolocation, this is done either trough your browser (you gave explicit permission), or trough the geoiplookup api (which also serves geo notices). For the geosearch part, it's interesting. I'm not sure if those are treated separately in the statistics collection process. This statistics are anonimized as much as always, but i'm not sure if extra steps would be required for the geosearch api. We should probably ask the analytics team. —TheDJ (talk • contribs) 09:20, 16 May 2013 (UTC)

John of Reading: No, we are not collecting, storing, or looking at user location data in any way. "Wikipedia" doesn't actually know where you are – your browser does, and if you give it permission, the extension simply locates Wikipedia articles tagged with geo-coordinates close to yours. Maryana (WMF) (talk) 17:17, 16 May 2013 (UTC)

How does this work? My browser must now all coordinates stored on Wikipedia then. Otherwise it has to submit at least some rough location data to the Wikimedia server. --Patrick87 (talk) 09:20, 17 May 2013 (UTC)

I believe the browser is querying Wikipedia for articles near to a given location, which so happens to be your location. When Wikipedia receives this query, it doesn't know this is where you are because the same API can be used to make queries for any arbitrary position (example). – PartTimeGnome (talk | contribs) 21:34, 21 May 2013 (UTC)

Very neat ~ y'all are so clever. Several articles within a couple of hundred metres needing pictures, if i can just work out how to upload them... :) One question, though, not entirely a WP:WP one, just a simple one from a know-nothing: Just how does my browser know where i am? Cheers, Lindsay^Hello 10:25, 17 May 2013 (UTC)

@LindsayH:Here's the explanation from the Firefox people: [1]. Roughly: when Google Street View took a picture of your street, they also remembered the names of all the wireless networks they found. -- John of Reading (talk) 10:52, 17 May 2013 (UTC)

So if my connection is, and always has been, through copper wires, they don't know about me, right? --Redrose64 (talk) 12:12, 17 May 2013 (UTC)

I don't know. They can still geolocate your IP address and read all the hints you've placed on your user page. -- John of Reading (talk) 12:24, 17 May 2013 (UTC)

If you're using a computer that has Wi-Fi capability you don't use, your browser can use your neighbours' Wi-Fi to locate you. Turning off your Wi-Fi radio stops this, of course. (Or you can just decline permission for geolocation when your browser asks.) – PartTimeGnome (talk | contribs) 21:34, 21 May 2013 (UTC)

When I signed up for broadband, they sent me a free WiFi router which also had four network sockets and one network patch cable. Since my computer has no WiFi, I connected using that cable. Almost as soon as I got it going, I turned off the WiFi - if I wasn't going to use it, I didn't want my neighbours getting a free connection. It was probably switched on for about three minutes. --Redrose64 (talk) 23:02, 21 May 2013 (UTC)

Let me get this clear, this special page only "knows" about pages in article that have the {{coord|...}} template attached to them? Just making sure that it doesn't work in WT: or User( talk): drafts. Technical 13 (talk) 10:44, 17 May 2013 (UTC)

Technically, it's any page that uses the {{#coordinates}} parser function, either directly or through a template like {{coord}}. I don't know of any other templates using this parser function. As for draft pages, I know that GeoData tracks these pages (e.g. [2] gives two user pages at present), but I don't know whether Special:Nearby filters them out. I suspect it does filter them, since the GeoData query I linked earlier wouldn't return non-articles until I added &gsnamespace=2 to the URL.

This is pretty cool. I noticed one curiosity in my results. Nearly all of the results were within 2.2 km, but the last entry was for Colorado College, which was correctly described as about 2235 km away. How did that outlier entry sneak onto the list over the innumerable other articles on subjects that are closer than that? older ≠ wiser 12:47, 17 May 2013 (UTC)

I may have found the answer to my question. Seems that until April 19, the article contained incorrect coordinates that placed it in my vicinity. So the function seems to use some stale/stable collection of geodata from the articles to generate a first pass listing, but then also uses more current geodata in the articles to calculate the distance. older ≠ wiser 12:56, 17 May 2013 (UTC)

It would be nice if this feature let me enter an arbitrary location to find articles near to it (as is possible using Marble). Not only would this be useful, but it could eliminate the dependency on JavaScript (automatic geolocation by the browser requires the JS, but users without JS could still use the option to enter a location). – PartTimeGnome (talk | contribs) 21:34, 21 May 2013 (UTC)

New #time: TimeZone parameters

MediaWiki's new #time(TimeZone) arguments added in 1.22wmf2 that are supposed to return if it is DST or not don't work... Anyone know more about this or are there plans to fix this? Technical 13 (talk) 21:44, 16 May 2013 (UTC)

#time returns the time in UTC (verify: UTC), which never has DST. #timel uses the server's local time, which for enwiki is also UTC (verify: UTC). On other sites with different local timezones, such as dewiki with CET, you can see that it works as you're expecting. Anomie⚔ 21:22, 19 May 2013 (UTC)

That is not working as I would expect it. I would expect #timel; to return the local time based on the user's preferences. Technical 13 (talk) 21:32, 19 May 2013 (UTC)

That would fragment the caches, and so is unlikely to happen for the same reasons we don't have a magic word to give the username of the user currently reading the page and things like that. Anomie⚔ 00:54, 20 May 2013 (UTC)

With regard to your last point (about usernames and caching), I have seen at least one wiki use a bit of js code to emulate this. Not being a techie and all, I don't know if this is verboten. Killiondude (talk) 03:23, 20 May 2013 (UTC)

Since it uses JS, that gets run client side so it doesn't affect the caches. Legoktm (talk) 23:18, 21 May 2013 (UTC)

Autocorrecting Edit-conflicts as Edit-merges

We need to focus on having an Edit-merge dialog to autocorrect for simple edit-conflicts. I wrote essay "wp:Avoiding edit-conflicts" to explain how to proofread, then simply re-edit, and tediously copy/paste before SAVE, to reduce edit-conflicts, but some autocorrection could be done as well. For years, we have wanted the edit-conflicts to be fixed, especially for simple cases, such as a new thread appended at bottom, inserting a short reply, or changing a few words in the non-edited paragraphs. Because any intervening change can profoundly alter the meaning of the edit-conflict text (such as someone inserting the word "not"), then the Edit-merge dialog would be yet another edit-preview requiring active approval, but with new text retro-inserted into the latest, prior revision of a page, for further proofreading. Then, the editor (handling the Edit-merge) decides whether to hit SAVE or rewrite the edit-merged text, as perhaps to respond otherwise to the recent interleaved changes. What is the status of developer updates to directly auto-correct and merge the edit-conflict problems? Does anyone think retro-inserting the reply text, at the same relative points would not work well enough in most cases? This has been a high-priority problem, especially when working on new hot-topic articles, where inserting a short phrase+footnote often gets an edit-conflict for some other erstwhile modified paragraph, even within a section-edit change. -Wikid77 (talk) 05:19, 17 May 2013 (UTC)

• Edit-merge works for separate portions but 2-reply conflict needs FIFO consensus: Extensive auto-correction for many edit-conflicts has existed since 2004, when re-combining separate parts of a page, such as the 1st editor changes the infobox parameters, while 2nd editor changes a later paragraph, and the 2nd editor's paragraph is inserted with the 1st editor's infobox. The next fix would be for 2 replies added after the same line, in a talk-page, or a list (etc.). However, the editor community needs to reach a consensus, so the developers would have a resolution, to append a 2nd reply, after the 1st reply, at the same line number, which is currently treated as "edit-conflict" and extremely common in fast-moving talk-pages. I suggest to use FIFO order (first-in, first-out), so the 1st reply takes precedence over the 2nd reply, to be inserted after the 1st. The developers have already finished "90%" of the bigger, complex Edit-merge operations, and what is left is to decide the community's choice as to which order to append two replies at the same line number, such as FIFO order. Perhaps we need an RfC to decide that issue. -Wikid77 (talk) 10:54, 21 May 2013 (UTC)

  Too much editor discretion is involved in merging that type of conflict for it to be automated. One might choose to place the 2nd comment after the 1st, to maintain chronological order. However, if the 2nd comment is in reply to something particular, while the 1st is a reply to the whole thread, the author of the 2nd comment might choose to place it before the 1st. The 2nd commenter might choose to abort their edit if the 1st commenter said pretty much the same thing they did. They might also want to change the indentation of their comment or even the content, to be more consistent with the first editor.

  Basically, the 2nd commenter needs to answer the question "what would you have done if the 1st comment was there when you started to comment?". The software can't answer that without additional input from the 2nd commenter.

  Also consider that the same edit conflict resolution algorithm is used on articles – if two people try to insert a paragraph at the same position in an article, it needs a human to arrange and/or re-edit the text so that it flows smoothly from one paragraph to the next.

  Your current concerns seem mainly about talk pages, so the developers probably won't have much interest in changing this – they want to replace wiki-style talk pages with Flow. Since each comment is kept separately in Flow, it isn't possible for one comment to conflict with another (the same was true of LiquidThreads, but the WMF killed that project).

  I think the main development work needed for edit conflict handling is to make the UI friendlier and easier to use. Some examples: a) Only show the sections of the page that are in conflict, rather than the full wikitext of the page. b) If an edit affected multiple parts of the page, automatically merge those parts that did not conflict rather than forcing the user to manually merge all of it. c) A single edit box with SVN-style conflict markers. (The wiki software could reject attempts to save if the conflict markers weren't removed from the text. This would also make it harder for someone to copy the text of their edit over the current text without merging the changes.) – PartTimeGnome (talk | contribs) 22:36, 23 May 2013 (UTC)

• Stopping the edit-conflict to give 2nd user power to choose is illusion: I know it might seem there are many decisions for the 2nd editor's reply, as to rethink the placement, to rethink the wording, or to consider the 1st editor's reply was enough, but that level of control is just an "illusion of control" and the 1st editor (or anyone) could re-edit to shift comments, or hat-hide sections, to overpower the careful edit-conflict resolution of a 2nd editor. The same would happen in articles, when the 2nd editor added a line or sentence, at the same point, where the 1st editor's text was added. In a general sense, the edit-conflict halt is a heightened case of multiple people working on the same page, but focused on the same consecutive lines. The general problem is:

• Edition-confliction:  Some other people might change what you wrote,
  please reconsider editing this page next month, next year or never again.

However, the fatal edit-conflicts at consecutive lines are an interesting narrow, rabid focus on 2 editors changing nearby lines, as if it were an end-of-the-world crisis decision, "Aaarrgghh! OMG, another editor inserted a line at that same point, can u imagine? Oh no, Oh no, what to do? what to do? how could life go on if your text was inserted after the 1st editor's text rather than before it, OMG, call for help, sound the alarm, OMG, OMG, Oh-My-friggin-GAAWWDD!"  I had not realized that edit-conflicts were actually such an exaggeration of the critical impending dangers of 2 editors inserting text at the same line, as yet another DramaQueenapedia blowup over what should be just, "2nd editor's text is inserted following 1st editor's text" (simple as that). However, I can understand how the exaggerated fear of consecutive lines has allowed the edit-conflicts to remain all these years, but it is past time to just simply combine the edits of the 2 editors, where the 2nd editor follows the 1st text. When that is fixed for talk-pages, then the same fix would apply in articles, where the 2nd editor's new sentence would append after the 1st editor's text inserted, or a 3rd editor might decide to rearrange the text added by both editors. -Wikid77 (talk) 01:16, 24 May 2013 (UTC)

Report days since Edit-conflicts still not fixed

Related: "#Autocorrecting Edit-conflicts as Edit-merges".

Another option, to help focus on fixing major issues, might be to have a frequent report, as with "Days since Edit-conflicts still not fixed". In this case, I am thinking about the type of edit-conflicts where editing a bottom section, to add another new section, should be considered an automatic correction, and so we could count the days since that bottom-section problem has not been fixed. However, how far back should the count extend? Perhaps start one year ago, or what date would more fairly reflect how long people have wanted the edit-conflicts to be fixed. Also, which template(s) should be used to show the elapsed time. Perhaps a years+days counter would be better, such as:

"4 years, 257 days, and edit-conflicts still not fixed"

That seems better than showing thousands of days. Then, we could show the not-yet-fixed counters in pages about edit-conflict issues. Any other suggestions? -Wikid77 (talk) 17:27, 18 May 2013 (UTC)

• New Template:Days_since to show years/days: I have created another date-utility template, to focus on counting days (not just months/years) since a specific date, as Template:Days_since. The related help-page, Help:Edit_conflict, had been created over seven years ago, on 24 November 2005, and so:

• {{days since|2005|11|24}} → 7 years, 183 days

But perhaps the year parameter should be dated back, even further, based on other pages where people discuss needing to fix the edit-conflict problems. -Wikid77 18:34, 18 May 2013 (UTC)

And how does that help ? As long we are not using the parsoid system, edit conflicts will be inevitable, and even with parsoid, we would be subject to them until we add live collaborative editing. Please add something useful instead of being pointy. —TheDJ (talk • contribs) 20:34, 18 May 2013 (UTC)

• Many would-be edit-conflicts are already avoided but others can be fixed: Thank you for noting the parsoid issues. I guess not many people realize that section-based edits are already retro-inserted into previously-edited pages, to avoid edit-conflicts (not "inevitable") even though the prior page is in true conflict with the next revision generated. It does not take much additional logic to treat portions of text as similar to section-editing, or the unchanged end-section text as an implicit new-section edit (any person who appends to end-section 'n' unchanged, is creating implicit new section 'n2' or 'n3' when conflict). Another issue, which makes many edit-conflicts seem hopeless is the current text-differencing algorithm which becomes confused by a line deletion or insertion. Instead, an edit-conflict can be auto-corrected by re-syncing on the prefix/suffix sections of other lines, rather than just the complete match against whole lines (ignoring the power of prefix/suffix matches). By that method, many partially-changed lines can be recognized as equivalent to the prior unchanged lines, and even some interleaved changes to every other line could be re-synced during an edit-merge, as in User:A changes lines 2, 4, 6, 8, 10, and 12, meanwhile User:B changes lines 1, 3, 5 (etc.), but inserts new lines, and the result is: "Auto-corrected edit-conflict, no difficulty at all". The 3 versions would be merely line-for-line recombined, treating the current saved version as the base, and then treating the differences against the prior version as the new text (skip lines 2, 4, 6, 8, etc.). In complex cases, the merge could be reported as "too extensive" to autofix. I know when this is implemented, the developers will be accused of "black magic" and watched suspiciously for their "alien powers" of advanced technology to solve the impossible edit-conflicts, but I think we could even explain the process to new users, as to how the partially changed lines are spotted as being re-sync points which allow the amazing auto-correction of numerous wannable edit-conflicts. I promise you, this will be awesome fun, as the finest wizardry, for the developers who agree to update the software to auto-correct these easy-to-merge conflicts (as a 3-revision synchronization). In fact, we could even have a user-preference: "Accept auto-corrected edit-conflicts as edit-save" to make it seem there are almost no edit-conflicts to busy editors. I think the imagined difficulty comes from text-book examples with short-line text, but because our editors create such ultra-long lines of text, then the re-sync of numerous changes can be easier to spot by prefix/suffix matches than in short-line, text-book cases. Another issue, but rare, is lookahead of several lines to re-sync, as in repeated groups of similar test-data lines. I have studied these issues for many years, so that is why I knew the many secrets. -Wikid77 (talk) 22:03, 18 May 2013 (UTC)

Who are you preaching to ? Devs already know this, you are not doing it, and other readers are not served with this —TheDJ (talk • contribs) 08:52, 19 May 2013 (UTC)

Are you trying to imply the developers are hopelessly incompetent, while knowing how to fix edit-conflict text, they just cannot seem to fix it, and the readers do not want to know about that? Sorry, I am not buying that line of reasoning, and I have seen evidence to the contrary that the developers could fix the edit-conflict pages, at the very least, to show an "Edit-merge" dialog of the retro-inserted new text for an editor to resume editing after an edit-conflict occurs. Please remember, when editing the hot-topic articles or busy discussions, then edit-conflict is the #1 problem with Wikipedia. It happens many, many times every day. Several people have even noted to click "New section" to avoid edit-conflicts on the bottom section, so I do not believe other readers do not care about fixing edit-conflict text. -Wikid77 (talk) 13:44, 19 May 2013 (UTC)

• Edit-merge already done for separate portions but 2-reply conflict needs consensus: It seems there is already extensive auto-correction for many edit-conflicts since 2004, when re-combining separate parts of a page, such as the 1st editor changes the infobox parameters, while 2nd editor changes a paragraph, and the 2nd editor's paragraph is inserted with the 1st editor's infobox. So, I apologize for the misunderstandings. The next fix would be for 2 replies added after the same line, in a talk-page, or a list (etc.). However, the editor community needs to reach a consensus, so the developers would have a resolution, to append a 2nd reply, after the 1st reply, at the same line number, which is currently treated as "edit-conflict" and extremely common in fast-moving talk-pages. The developers have already finished "90%" of the bigger, complex Edit-merge operations, and what is left is to decide the community's choice as to which order to append two replies at the same line number. Perhaps we need an RfC to decide that issue. -Wikid77 (talk) 23:32, 20 May 2013 (UTC)

Have list: Top 10 New useful features

I have been trying to find ways for people to focus on valuable new features for Wikipedia, to help with real problems. Perhaps if we maintained a list, as a reminder, "Top 10 New useful features" then that list could be used to focus efforts on important things to do. For example, pages need a {Setfooter:} to show a bottom message, such as a reminder ending a talk-page:

• {{setfooter: End of talk-page — click "New section" to add at bottom.}}

By having a valuable new feature, such as a {setfooter} to display a message at page bottom, then Wikipedia could be improved to help new users know what to do next, when seeing the bottom of various pages. We need to focus on valuable new features for Wikipedia. Add to list below. -Wikid77 (talk) 09:03, 17 May 2013 (UTC)

Top 10 New useful features

The following list contains valuable features which could greatly improve Wikipedia operations.

1. Have an Edit-merge dialog to autocorrect Edit-conflict and retro-insert new text. -Wikid77 09:03, 17 May 2013 (UTC)
2. Have a {setfooter} to show a wikilinked message at page bottom, such as more instructions. -Wikid77 09:03, 17 May 2013 (UTC)
3. Have an option to list categories with page-size after each page title. -Wikid77 09:03, 17 May 2013 (UTC)
4. Have an option to sort categories by date-edited, after each page title. -Wikid77 09:03, 17 May 2013 (UTC)
5. New parser function {set:x|7} to store values, such as global options between templates/modules or incremental counters. -Wikid77 13:49, 17 May 2013 (UTC)
6. Increase template wp:expansion depth limit from 40/41 to 60/61. -Wikid77 13:49, 17 May 2013 (UTC)
7. New magic-word variable {setsize:3000kb} to raise post-expand include-size limit beyond 2000kb as special request inside larger pages. -Wikid77 13:49, 17 May 2013 (UTC)
8. Unbundle the admin toolkit Kumioko (talk) 12:58, 17 May 2013 (UTC)
9. Replace the RFA process Kumioko (talk) 12:58, 17 May 2013 (UTC)
10. Have an option to view the talk page after the article name when looking at the articles in categories like the one User:Equazion made here. Kumioko (talk) 12:58, 17 May 2013 (UTC)
11. Improve the new pages feed tool to allow all namespaces to be viewed.Kumioko (talk) 12:58, 17 May 2013 (UTC)
12. Improve the new pages feed tool to allow group selection of multiple articles at once Kumioko (talk) 12:58, 17 May 2013 (UTC)
13. Implement some kind of Admin review committee to look into abuse of the admin tools and admin behavior. Kumioko (talk) 12:58, 17 May 2013 (UTC)
14. Show a category with edit-buttons at each title in list. -Wikid77 13:49, 17 May 2013 (UTC)
15. Fix the layout when viewing the site from a mobile device in desktop mode so that all of the sites functionality isn't broken by the oversized search box and the globe logo. (screenshot upon request) Technical 13 (talk) 17:06, 17 May 2013 (UTC)
16. Fix the application so that editors with more than 30, 000 edits can be renamed.Kumioko (talk) 13:06, 19 May 2013 (UTC)
17. Create a global watchlist so we don't have to go into every single project to check our watchlistKumioko (talk) 13:06, 19 May 2013 (UTC)
18. Allow users the option of switching their watchlist to a subpage, or a group of subpages instead of a hidden server only location.Kumioko (talk) 13:06, 19 May 2013 (UTC)

(Add more major features to the list above). The list can be expected to grow beyond 10 items, but then prioritize to move the top-10 most-valuable new features up to the top of the list. I will put a copy of this at wp:VPIL Idea Lab to also get suggestions there. -Wikid77 09:03, 17 May 2013 (UTC)

For specific enhancement requests that are considered useful by a number of people it would be nice if somebody could send a feature request to the 'Bugzilla' bug tracker by following the instructions How to report a bug (please try to check first if a request does not already exist in Bugzilla). This is to make developers of the software aware of the idea. Thanks in advance! --AKlapper (WMF) (talk) 10:01, 17 May 2013 (UTC)

I added a few but not all are technical solutions. Also a couple have been brought up before but I will submit them anyway. Kumioko (talk) 12:58, 17 May 2013 (UTC)

What about some new buttons at top of a page? Should there be another option when viewing history-log pages? -Wikid77 13:49, 17 May 2013 (UTC)

i do not understand what is the point of this list (this is not meant to assert there is no point - just that i do not understand it). note that some of the items may not be good changes according to consensus: for instance, i think several of the proposed changes are actually bad. some are not clear (what is meant by "Improve the Recent changes tool to allow all namespaces to be viewed"? i can see all namespaces in recent changes). so each individual proposal needs discussion, clarification, and some way to say "support", or "object". isn't this exactly what wp:vpr is all about? so how is this list productive? peace - קיפודנחש (aka kipod) (talk) 19:43, 17 May 2013 (UTC)

For the new pages tool see here. If you click on Set filters you can see where it only allows editors to select User and Artice. It would be very helpful to be able to see the other namespaces like Book, Category, Template, Project, etc. Kumioko (talk) 20:58, 17 May 2013 (UTC)

I think you meant to put "new pages feed" rather than "recent changes" in your numbered point above. — This, that and the other (talk) 00:52, 18 May 2013 (UTC)

Your right, good catch. Kumioko (talk) 00:57, 18 May 2013 (UTC)

This list is nice, but it would be more useful if it only contained easily actionable technical improvements. Putting "fix RFA" on this list is not really germane to VPT, and the devs can't do much to fix this problem, sadly. — This, that and the other (talk) 00:52, 18 May 2013 (UTC)

Problems with relisting AfDs

I just noticed that apparently, when using the script that puts tabs at the top of the page for closing and relisting AfDs, that relisted AfDs are not always being removed from the original AfD log, and also that they're not having the 'log' link on the AfD page change to reflect the updated log. See for instance Wikipedia:Articles for deletion/SuaVay Nova - listed for AfD on the 9th, it was relisted on the 17th, but remained on the 9th's log and the 'View log' link still goes to the 9th... - The Bushranger _{One ping only} 17:42, 18 May 2013 (UTC)

Sorry, this is my fault. If you use the closeAFD script's relist button, the action can often take 30-45 seconds to complete. In this case, I think I relisted two AfDs in the same minute, which resulted in an edit conflict when removing from the older page. LFaraone 02:53, 23 May 2013 (UTC)

Problem in conversion from wiki code to HTML

Hello people,

I enter this wiki code :

<code style="background: yellow; color: dimgray;">A B C </code><code style="background: pink; color: darkgreen;">D</code>

I get this result :

A B C D

The space between C and D is not in "code", and gets no colour background.

The HTML code generated is :

<code style="background: yellow; color: dimgray;">A B C</code> <code style="background: pink; color: darkgreen;">D</code>

There is a problem in the conversion from wiki code to HTML.

Thank your correcting that, and have a nice day.

--Nnemo (talk) 20:15, 18 May 2013 (UTC)

@Nnemo:Replace the space after "C" with an explicit non-breaking space:   Voilà! A B C D Ignatzmice•talk 20:35, 18 May 2013 (UTC)

This is the builtin HTML Tidy system at work, (over) correcting for oft made mistakes in HTML authoring. —TheDJ (talk • contribs) 20:37, 18 May 2013 (UTC)

I did not know there is a built-in applying of HTML Tidy. Not a so good idea. --Nnemo (talk) 21:51, 18 May 2013 (UTC)

What's worse, we are pretty much dependent on it. I've tried importing Wikipedia templates to a Mediawiki instance with HTML tidy turned off and one often finds places where tables, spans, and divs were never closed properly but local users here don't actually notice because tidy has been hiding the mistakes. Dragons flight (talk) 01:51, 19 May 2013 (UTC)

This is yet another good reason for turning off HTML Tidy. Currently HTML Tidy hides errors under the carpet. If we turn off HTML Tidy, we will find the templates broken, and we will soon correct them. --Nnemo (talk) 18:09, 20 May 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘If the HTML is sufficiently broken to display incorrectly in a browser, the chances are HTML Tidy will also do the wrong thing. Hence badly broken HTML is easy to spot even with HTML Tidy.

Also, different browsers handle bad HTML differently: an editor's browser might display it as intended, so they don't know to fix it. Some readers could see the page as broken, however. By ensuring the HTML sent to browsers is valid, HTML Tidy makes it more likely that everyone sees the page the same – consistently broken or consistently as intended.

Furthermore, most Wikipedia editors are not technically minded. If HTML Tidy was not there to correct the broken HTML before sending it to the browser, the level of invalid HTML output by Wikipedia would probably grow faster than technically-minded editors could correct it. – PartTimeGnome (talk | contribs) 21:16, 23 May 2013 (UTC)

Thank you Ignatzmice, but here I am not looking for a way to circumvent the bug. I was. And I discovered that this bug is really nasty. But now I have done the workarounds I needed. The character you propose is different from the space character, this has consequences. --Nnemo (talk) 21:51, 18 May 2013 (UTC)

• Nest 2nd tag inside end of 1st tag: When a colorized tag ends with a trailing space, then another tag (perhaps null-span: "<span/>") needs to be nested within that tag to preserve the color of the non-breaking trailing space. So some options:

• <code style="background: yellow; color: dimgray;">A B C <code style="background: pink; color: darkgreen;">D</code></code> → A B C D
• <code style="background: yellow; color: dimgray;">A B C <span/></code><code style="background: pink; color: darkgreen;">D</code> → A B C D

If the text wrapped after "C" then the trailing space would still appear at the end-of-line, with the next line having letter "D". Although the request was to note/fix the bug, due to restrictions of HTML Tidy, then other editors need to realize how a nested-tag or null span-tag "<span/>" must be used to preserve the trailing-space color inside the outer tag. The use of mixed-color labels can be an issue in annotated maps or images. -Wikid77 23:24, 18 May 2013 (UTC)

Hacking in crosswiki watchlists with a JavaScript gadget

Hi. Crosswiki watchlists (bugzilla:3525) are still a way off. But I'm wondering how difficult it would be to hack up something in the meantime using a JavaScript gadget.

Here's the basic idea: a user would go to Special:Watchlist on his or her home wiki and at the top there would be a prominent drop-down menu that defaults to the user's current wiki (e.g., "en.wikipedia.org"). The drop-down menu would be configured on a per-user basis to list other wikis (e.g., "meta.wikimedia.org" and "test.wikipedia.org").

If the user selects one of these domains in the drop-down menu, the watchlist content would reload (staying on the same domain and hopefully not requiring any browser window refresh). Ajax would be used to pull watchlist content via the MediaWiki API from remote wikis. Watchlists already have support for external tools pulling their contents via a watchlist token.

Here's where I'm having difficulty mapping out this feature in my head:

1. How would you store which wikis to feature in the drop-down menu on a per-user basis? We don't want to list all possible wikis as the list is simply overwhelming and most users just want to keep an eye on one or two other wikis.
2. How would you store the watchlist token on a per-user basis in a place that's both configurable, but still allows the user to keep the token private?

Between cookies, local storage, JavaScript obfuscation, and possibly the action=options MediaWiki API module, I feel like figuring how to store this information in a persistent, yet private, way should be possible. Thoughts? --MZMcBride (talk) 01:10, 19 May 2013 (UTC)

Discussing this with people smarter than me, it seems like CORS could work to grab the remote HTML to solve question 2 (i.e., instead of using watchlist tokens + RSS, just grab the generated watchlist HTML), assuming SUL can be relied upon to log the user in. --MZMcBride (talk) 01:25, 19 May 2013 (UTC)

Once they complete the SUL finalization, that shouldn't be a problem. Theopolisme (talk) 13:08, 19 May 2013 (UTC)

SUL finalisation will ensure that everyone has an account they can use on every WMF wiki. It won't force them to be logged in to it, though. There have been various cases where people have needed to log-in manually to our sister projects, despite having an SUL account. (This is possibly due to security features in modern browsers.) Hence, you can't rely on SUL to log a user in even once SUL finalisation is complete. – PartTimeGnome (talk | contribs) 22:56, 23 May 2013 (UTC)

How do you test for a redlink?

I'm about to write a perl script to strip redlinks from a (wiki-marked up) list of links, but I don't have a clue where to start. I wish redlinks could be specified in a regex.

How would I go about testing the links on a WP page for redlink status? The Transhumanist 01:45, 19 May 2013 (UTC)

User:MZMcBride/stripredlinks.js is an old script that does this by looking at the rendered HTML. In a Perl script, you'd need to use the MediaWiki API to check each title (or preferably batch-check titles) to see if they exist on a particular wiki. But link existence can be very tricky with interwiki prefixes, namespace aliases, etc. --MZMcBride (talk) 01:50, 19 May 2013 (UTC)

How does one use/activate this script? And what does it do exactly? The Transhumanist 02:55, 19 May 2013 (UTC)

It's activated the same way any user script is activated: importScript('User:MZMcBride/stripredlinks.js'); in your relevant /skin.js subpage.

You should be able to read through the script fairly easily. It takes a list of pages and temporarily removes the red links. For example, if you have the following list:

• hello
• this page doesn't exist
• goodbye

This script adds a link to the sidebar ("Remove red links"). When you click this link, the list will read:

• hello
• goodbye

Until you next refresh the page (i.e., temporarily). Hope that helps. --MZMcBride (talk) 03:19, 19 May 2013 (UTC)

Ah, it adds a link to the sidebar. That's the part that wasn't obvious from your initial description. Thank you for your patience with my questions.

By the way, I don't understand that script at all. Which line actually identifies the red links as red? And how does it do it? The Transhumanist 04:03, 19 May 2013 (UTC)

i am not familiar with the specific script, regarding the "how is it done" question: it is very easy to do in a javascript which runs on wikipedia itself. red links have the CSS class "new", and there is absolutely no reason for anything which is not a redlink to have this class, so basically a super- simple expression such as $('a.new'); produces a list of all redlinks. now, what you can do with it in the script is a different matter. the script described above hides them and then exposes them back. what you want to do is to generate a list on the perl side which you can work with. as to "regex": basically you want to scan the html for "a" element with class="new". should not be that difficult. you can also, as mentioned above, use the API to get the list of redlinks. קיפודנחש (aka kipod) (talk) 05:11, 19 May 2013 (UTC)

(edit conflict) Fair enough. I've documented the script: User:MZMcBride/stripredlinks.js. --MZMcBride (talk) 05:17, 19 May 2013 (UTC)

The way I prefer to test for redlinks is with jquery like $('a[href*="&redlink=1"]').whatever you want to do with it Hope this is useful to you. Technical 13 (talk) 12:12, 19 May 2013 (UTC)

"redlink=1" is in the API-generated HTML source text. You're talking about scraping the html page, aren't you? The Transhumanist 09:56, 21 May 2013 (UTC)

Category not updating

Anyone know why Category:Wikipedia semi-protected edit requests hasn't been updated in many hours? It's listing as open requests that were closed many hours ago. I don't think it's me: I purged the page, cleared my cache, and even dumped all my Wikimedia cookies. Rivertorch (talk) 06:11, 19 May 2013 (UTC)

I assume you mean the chart? The category membership itself seems fine to me. The chart is updated by a bot (cf. this page history). It looks like the bot may be broken. Try contacting its maintainer? --MZMcBride (talk) 07:47, 19 May 2013 (UTC)

Duh, I neglected to look at the bottom of the page. I've grown so used to relying on the chart that I'd forgotten there's a regular old category underneath. It looks as if someone already left a message in the right place. Rivertorch (talk) 09:22, 19 May 2013 (UTC)

Current method I'm using to remove redlink entries in a set of lists - need faster method

RESOLVED: Use #ifexist to omit 400 redlink lines from a list in 1 second. -Wikid77 07:07, 20 May 2013 (UTC)

I'm removing superfluous redlinks from country outlines.

To remove the redlinks of "Political scandals of foo" (where foo is a country name) from each country outline, I take a list of country outlines (on a user subpage) and replace "Outline of" with "Political scandals of". That list now shows which links are red.

Then I use AWB's listmaker to make a list of all the redlinks on that page, and I paste them back in to the same page and linkify them. Now there's only redlinks on that page.

Next I change "Political scandals of" back to "Outline of". The list is now all the country outlines that contain the "Political scandals of" redlink in them.

I make a list in AWB from that, and then do a regex search/replace with AWB to get rid of the entry in each of those outlines.

Unfortunately, I have to do this whole procedure over again for each redlink I wish to nuke (so as not to nuke the blue links too), and this approach only works with sets of links that share the "of foo" nomenclature. Because AWB has no way to search/replace strings based on redlink status (as far as I know).

If you know of a easier/faster way to do this, please let me know...

Please post replies to Wikipedia:Bot requests#Current method I'm using to remove redlink entries in a set of lists - need faster method. Thank you. The Transhumanist 06:26, 19 May 2013 (UTC)

• Just use rapid #ifexist for those redlinks or show all links as blue: Although the parser limits the use of #ifexist to 500 conditions, it can be used to choose to show non-wikilinked text at redlinks:

• {{#ifexist:boguspage|[[boguspage]]|boguspage}} → boguspage

Then, when eventually someone writes the missing page, then the wikilink "magically" returns as a blue-link text. However, another method is to force the link-display text to appear blue, so redlinks look blue but still click to create the new page. Example:

• [[boguspage|{{color|#1144FF|boguspage}}]] → boguspage

Use a regex editor to update all, or the most-likely wikilinks, to use those methods. Either way, the page will have wikilinks to those pages, once they are created, or to create them when someone clicks a blue-toned redlink. -Wikid77 (talk) 14:09, 19 May 2013 (UTC)

Don't use the second of Editor Wikid77's options because that can confuse reader expectation. Readers are trained to expect that blue links will take them to another article or location. Don't break that training. Better to have redlinks or non-linking text than to have redlinks masquerading as a blue links.

—Trappist the monk (talk) 14:29, 19 May 2013 (UTC)

• Red text has many meanings now and users can underline wikilinks: Many pages use red text to indicate error conditions (some use "orange" text), and that does not mean the error-page text does not exist. Also, some usernames have the signature set to show red text, often identical to redlink text, or map labels shown in blue when not wikilinked, but editors have learned the red/blue coloring is not mandatory. In the case of a page with many to-be-created subarticles, several editors have complained how the redlinks can be quite distracting, and so the links could be made less distracting by putting blue-links with red-underline (as option "Underline links" in Special:Preferences). As a practical, technical consideration, most readers do not click the wikilinks, and so the red/blue distinction does not even matter that much for page functionality. Also, there have been brown-colored links for small-size pages, and so perhaps the redlinks could be shown as bluish-brown to indicate a difference compared to non-redlinked text. All these options are technical topics, as opposed to debating the "don't use" rules of wp:VPP policy considerations. -Wikid77 (talk) 15:58, 19 May 2013 (UTC)

Yep, pretty much all of that is true. But we're not discussing what colors are used for error messages, nor signatures, nor map labels, nor distractions, nor small pages. Yep, what you've described is a technical possibility but such technical possibilities must be tempered with everyday accessibility requirements and reader-expectations of the articles in main space. Individual editors can make links that they see be anything they like. But, that is not a good reason to allow them, or even recommend to them, that they can or should start making changes contrary to accepted conventions without having first sought and obtained a consensus to do so. You know better and should have so stated when you made that second suggestion.

—Trappist the monk (talk) 16:34, 19 May 2013 (UTC)

• Compromise as blue-green-colored redlinks or red-underline: I focus more on "how" rather than "do/don't" because I have seen too many thousands of cases of "exceptions to the rule", such as people wanting to link many wannabe new pages, but the whole page shows too much redness. As a compromise, perhaps we can show redlink titles as blue-green links with red-underlining. Example:

• {{#ifexist:boguspage|[[boguspage]] |[[boguspage|{{color|#1177DD|boguspage}}]]}}
    boguspage

Then, even with many redlink articles, the overall page would show mostly as blue-green-linked text, with just the minor red-underlines in the text for users with Special:Preferences set for option "Underline links". Once each linked title has been created, then the link color would shift from blue-green to typical blue wikilinks. -Wikid77 19:34, 19 May 2013 (UTC)

Per WP:Easter egg: "Keep piped links as intuitive as possible". Changing the link colors has nothing to to with the original request, and it is a bad idea. --  Gadget850 ^talk 22:45, 19 May 2013 (UTC)

Showing redlink titles as blue-links with red-underlines is just a variation, rather than omitting them. -Wikid77 07:07, 20 May 2013 (UTC)

I doubt WP:AWB identifies redlinks by the color of their font. It probably tests for existence of a page, or checks a redlink flag or something. Where would I find documentation on this stuff? The Transhumanist 00:19, 20 May 2013 (UTC)

AWB doesn't know whether a link references a valid page or not. -- John of Reading (talk) 06:53, 20 May 2013 (UTC)

• I think using #ifexist to check and omit redlink lines in 200 live articles is what is wanted here. -Wikid77 07:07, 20 May 2013 (UTC)

Wikimirrors, how do they work?

I've been thinking about the problem (in my view, at least) of WikiMirrors mirroring AfC content (e.g. [3]), often very quickly. It would be lovely, but I suspect impossible, to figure out how to delay reporting AfC stuff externally. I presume the mirrors are either scraping Wikipedia (in which case we can't prevent this without blanking our page, which is not going to happen in general), or retrieving the information via the API (in which case not publishing content would make that content unreachable by bots, undesirable because bots do things like copyright checks on the submissions). Still, if anyone has a clever technical solution to this, something that would delay out-of-WP publication of AfCs for a few days until the worst of it had a chance to be vetted for copyrights and attacks, well, that might be worth talking about more. --j⚛e decker^talk 16:59, 19 May 2013 (UTC)

Deleted edit

This is a very basic question but I've never asked so I don't know. What is a deleted edit and why would any of my edits be deleted? Would it necessarily be because I have done something wrong? Thanks Cls14 (talk) 08:20, 20 May 2013 (UTC)

It means that you edited a page that was later deleted. Your edits were probably fine - only an admin can see them, so I can't comment. In particular, if you've ever tagged a page for deletion, then those edits will be part of your count of deleted edits. -- John of Reading (talk) 08:35, 20 May 2013 (UTC)

Of the 360 or so deleted edits that are credited to you, almost two-thirds are for files. Quite a few of the files that you've uploaded have been moved to commons:, such as File:Frank Nagington Stand New Bucks Head.jpg. These no longer exist on English Wikipedia, so will count towards the deleted edits. --Redrose64 (talk) 11:25, 20 May 2013 (UTC)

Thanks for the information, I am very impressed how fast the community has got back to me about this. I have been meaning for a while to sign up for a Commons account. I think it needs to be done :-) Cls14 (talk) 14:43, 20 May 2013 (UTC)

Deleted edits are not a badge of shame, just saying. On that note, through unified login, you should already have an account on commons... Technical 13 (talk) 15:04, 20 May 2013 (UTC)

Cls14 has an old account and has never unified it.[4] The user name is taken at Commons but based on for example [5] and [6] I strongly assume it's the same user. If you have a working password to the Commons account then you can unify the accounts at Special:Mergeaccount. PrimeHunter (talk) 15:24, 20 May 2013 (UTC)

Job queue question

Hi everyone. Can someone who knows about the job queue chime in on this question about the {{db-c1}} template? I'm not sure if I have all the details correct. Thanks — Mr. Stradivarius ^{♪ talk ♪} 09:03, 20 May 2013 (UTC)

Prerequisites for technical articles

The text below is a compilation of quotes from #wikipedia and ##math on freenode. Also see Prerequisites Project. Editingeddie (talk) 22:08, 20 May 2013 (UTC)

It seems it's time for Wikipedia to include a new section to its technical articles (math is the best example): prerequisites.

It's not going to be easy, but from giving our readers exhaustive prerequisites trees to not trying anything at all and letting them find their way around there's a long distance. There's always *some* minimal content to: "here's a non-exhaustive list of topics that the reader is assumed to be familiar with before reading this". Furthermore, a work-in-progress prerequisites tree (like a Debian dependency tree) would be of great encyclopedic value itself.

Again, I am aware how difficult this can be; it's not like I can't find tens of arguments against it myself. I just think there are some solid reasons to give it some thought. Perhaps fewer and less solid than the reasons to do nothing, but that's just normal for a concept that many people may have not even thought about. So perhaps if we gave it a chance...

The most exciting thing about this new editorial approach is that it would *finally* begin to address the "too technical" problem *without* affecting accuracy/completeness.

How can we get this started? Does it need some voting or something? Where could we meet and talk about it? Perhaps we could use ##wikipedia-prerequisites channel on freenode to talk about it (I just created it provisionally). — Preceding unsigned comment added by 79.115.8.76 (talk) 10:23, 20 May 2013 (UTC)

See {{Pre-read}} for a possible wording. ShakespeareFan00 (talk) 10:40, 20 May 2013 (UTC)

A good place to talk about it would probably be Wikipedia talk:WikiProject Prerequisites Project. For wider input, the idea lab would be a good place to go. If you're looking to create content guidelines for this, take a read of Wikipedia:How to contribute to Wikipedia guidance. Proposed guidelines normally go through a process like RFC to be approved by the community (RFCs typically use !voting). – PartTimeGnome (talk | contribs) 22:01, 21 May 2013 (UTC)

I've left a comment at Wikipedia talk:WikiProject Prerequisites Project. – PartTimeGnome (talk | contribs) 22:15, 21 May 2013 (UTC)

Applying custom user common.css to mobile site (m.wikipedia.org)

I created a custom user common.css (http://en.wikipedia.org/wiki/User:Vbksdvbkuyvb/common.css).

It works on the normal wikipedia.org site, but not on the m.wikipedia.org mobile site.

What must I do to get this to work on the mobile site?

Thanks.

Vbksdvbkuyvb (talk) 10:57, 20 May 2013 (UTC)

You can try copying the CSS to User:Vbksdvbkuyvb/mobile.css, but I'm not sure the MobileFrontend extension will even look at that file. (It does ignore the sites and users Common.css.) — Edokter (talk) — 10:46, 20 May 2013 (UTC)

Thanks for the suggestion, but I already tried that and it didn't work. (I should have mentioned that in my initial post)

I also tried using the @media handheld CSS directive, but that didn't work, either.

Any other ideas?

Thanks again.

Vbksdvbkuyvb (talk) 10:57, 20 May 2013 (UTC)

Not possible right now. The mobile team is very reluctant in adding 'custom' styling and are working on finding better core solutions to avoid it whereever possible. —TheDJ (talk • contribs) 15:12, 20 May 2013 (UTC)

Thanks for the answer.

My custom CSS is only used to change the color scheme (mainly dark backgrounds with light text, as the white background is too bright for me).

Unless they offer a color scheme preference page, I don't see how they would offer the same functionality as allowing me to write custom CSS.

Creating a color preference page would take much more work on their end than just loading custom CSS if it exists for my user.

From my uninitiated perspective, I don't see why allowing users to implement custom CSS would be that bad.

If I enter my own CSS, it shouldn't bother any other user; I'd know what the CSS is and that I've enabled it, so I'd be left to my own devices to make it work.

Where should I request that custom CSS be allowed for the mobile site?

Thanks again.

Vbksdvbkuyvb (talk) 18:26, 20 May 2013 (UTC)

Watchlist changes since last login

I would appreciate it if my Watchlist noted which of the pages listed have been changed since I last logged in. There's something similar when I look at the history of a page on my watchlist ("Updated since your last visit"). Any chance? Thanks. (p.s. why isn't 'watchlist' in our spellcheck dictionary?) --Ring Cinema (talk) 13:57, 20 May 2013 (UTC)

This is already implemented in MediaWiki, but disabled here because some people... loudly complained when it was enabled. You could probably have it enabled back, just ask an admin. Matma Rex talk 14:29, 20 May 2013 (UTC)

See Wikipedia:Customizing_watchlists. And i'm not going to put myself into that cesspit again, but yes, it's still ridiculous to be disabled by default. There were several very good proposals about painting this bike shed. —TheDJ (talk • contribs) 15:11, 20 May 2013 (UTC)

(edit conflict) i do not think the last statements are correct. to the best of my knowledge the requested functionality is not implemented in mediawiki, and was never active on enwiki. (i think the gentlemen who answered did not read the question carefully enough: he is talking about "change since last login", not "change since last visit").

i am not sure what the OP meant by the p.s.: where is this "spellcheck dictionary"? the only one i am aware of has nothing to do with wikipedia, and is part of my browser. one can't expect wp to shove entries into one's browser's dictionary, but most browsers make it easy enough to add entries yourself. peace - קיפודנחש (aka kipod) (talk) 15:14, 20 May 2013 (UTC)

It is indeed correct, $wgShowUpdatedMarker has been enabled for over a year, see Wikipedia:Village pump (proposals)/Archive 83#Enable "Show changes since last visit" on watchlist. Current discussion is at Wikipedia:Village pump (proposals)#"Updated since last visit" markers. I do intend to re-enable it using colored bullets, which was not previously possible due to limits in CSS which have since been adresses. — Edokter (talk) — 15:32, 20 May 2013 (UTC)

$wgShowUpdatedMarker is a different matter. this has to do with bolding "changes since last visit", and the OP was asking about a new functionality: show changes since last login. i do not believe this functionality is implemented by mediawiki. קיפודנחש (aka kipod) (talk) 15:38, 20 May 2013 (UTC)

It basically boils down to the same thing. Changes since last login is not possible; to my knowledge, MediaWiki does not store login activity. — Edokter (talk) — 15:41, 20 May 2013 (UTC)

It may not be possible on en.wiki but as an admin on a Wikia I know it stores the last edit and last login of the other admins, possibly all users.--Gilderien Chat|List of good deeds 18:06, 20 May 2013 (UTC)

It does for all users, but that's a Wikia-specific extension, not core MediaWiki. Maybe the OP can clarify if they really meant since last login or since last visit. I myself would really like if the watchlist would not only mark which pages have been modified since my last visit, but also which revisions. Especially for pages like this one. — HHHIPPO 20:44, 20 May 2013 (UTC)

For highlighting new revisions since your last watchlist visit, try User:Ais523/watchlistnotifier.js. In addition to its stated function of adding a notice to each page of what the most recent edit on your watchlist is (which is very unobtrusive and easy to ignore), it will also, when viewing the watchlist, bold all new revisions since the last time your watchlist was loaded, provided that the last time the watchlist was loaded was within the same browser session. Note that it will not do this on the first watchlist load of each browser session, though. jcgoble3 (talk) 22:16, 20 May 2013 (UTC)

Yes, I did mean since last login. I tried the gadget (and thank you everyone for responding!) and it is not bad but to me it would be nice to know what has happened since my last visit. Such a feature chains nicely and doesn't repeat itself. Since I would like it, maybe others would like it, too. Thanks again. --Ring Cinema (talk) 23:37, 20 May 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Jcgoble3, the gadget you describe is in a sense the opposite of what I'm interested in. Instead of clueing me in at the time I sign in about changes, it only lets me know about changes since I logged in. I want to know about changes since my last login -- or better yet, since my last session ended. Isn't it obvious how useful this would be? --Ring Cinema (talk) 17:30, 21 May 2013 (UTC)

Labeled section transclusion

Help:Labeled section transclusion has been started. --  Gadget850 ^talk 17:36, 20 May 2013 (UTC)

That looks hugely powerful, thanks! ~ Amory (u • t • c) 21:09, 20 May 2013 (UTC)

Something's wrong again

Resolved

The dropdown menus aren't working, Twinkle isn't showing up and some of the edit interface is missing as well (and I already tried bypassing my cache). AutomaticStrikeout  ?  18:16, 20 May 2013 (UTC)

I'm having the same technical problem too. Wesley♦Mouse 18:19, 20 May 2013 (UTC)

• Ditto and when you start typing in the search box no hints come up either. Carlossuarez46 (talk) 18:22, 20 May 2013 (UTC)

Javascript is broken somewhere: Uncaught TypeError: Object #<Object> has no method 'hook', somewhere in http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController%7Cext.postEdit%7Cext.wikimediaShopLink.core%7Cjquery.client%2Ccookie%2CmwExtension%7Cmediawiki.action.view.postEdit%7Cmediawiki.cldr%2CjqueryMsg%2Clanguage%2Cnotify%2Cutil%7Cmediawiki.language.data%2Cinit%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.startup&skin=vector&version=20130520T181903Z&*. Of course, it does work in debug mode... — Edokter (talk) — 18:23, 20 May 2013 (UTC)

• In my situation, Twinkle does not show up, but search box hints do come up. smileguy91^talk 18:27, 20 May 2013 (UTC)

(ec) I'm getting a console JavaScript error "Uncaught TypeError: Object #<Object> has no method 'hook'". This seems to come from a piece of code "mw.hook('wikipage.content').fire(util.$content);". I haven't yet been able to figure out where that code is coming from. When I append ?debug=true to the URL, the error disappears and everything works fine. Ucucha (talk) 18:28, 20 May 2013 (UTC)

• This appears to be a Vector-only problem; no errors in Monobook, but when I switch to Vector, it shows up. Writ Keeper ⚇♔ 18:29, 20 May 2013 (UTC)

• • I think you're right that it's Vector, switching to Monobook appears to have fixed the problems I was seeing (no clock-purge widget, no RefTools "cite" button, etc.) --j⚛e decker^talk 18:32, 20 May 2013 (UTC)

It is being looked at now by devs. During deploy, a user was able to hit a mixed state, which then got cached. —TheDJ (talk • contribs) 18:40, 20 May 2013 (UTC)

Seems to be fixed now. — Edokter (talk) — 18:45, 20 May 2013 (UTC)

Yes. If you're still having problems, you may need to clear your cache. Ucucha (talk) 18:46, 20 May 2013 (UTC)

JavaScript is "mostly" working but seems to be running on some kind of fallback because I've noticed some of the icons being used aren't the same as was there half an hour ago. Anyways, fallback is fine for me! Technical 13 (talk) 18:50, 20 May 2013 (UTC)

Should be fixed for everyone shortly, thanks to Krinkle. If you're still seeing brokenness, clear your cache like Ucucha says. Steven Walling (WMF) • talk 18:51, 20 May 2013 (UTC)

• Thanks and job well done to whoever fixed it! AutomaticStrikeout  ?  18:53, 20 May 2013 (UTC)

Formatting toolbar not appearing

Formatting toolbar is not appearing (checked from two browsers)! --Tito Dutta (contact) 18:35, 20 May 2013 (UTC)

Vector appears to be broken, see "Something's wrong again" above. --j⚛e decker^talk 18:37, 20 May 2013 (UTC)

apparently it's not broke in debugging mode (aka Heisenberg bug), so as a workaround you can add "&debug=1" to the address line after you hit "edit" to regain the toolbar. this is very poor replacement, and specifically i do not think you can use it once you hit "preview" or "show changes", but in some cases it might be better than nothing... peace - קיפודנחש (aka kipod) (talk) 18:43, 20 May 2013 (UTC)

• Fixed Working! --Tito Dutta (contact) 18:50, 20 May 2013 (UTC)

DISPLAYTITLE is not working

I put a DISPLAYTITLE template at the top of Kalai's 3^d conjecture to make it display as Kalai's 3^d conjecture. Obviously to leave it as Kalai's 3^d conjecture would be barbaric. But the template isn't working; the title still appears as Kalai's 3^d conjecture. What's wrong? Michael Hardy (talk) 18:33, 20 May 2013 (UTC)

That's probably because DISPLAYTITLE only works with titles that are still the same as the original when layout is removed. Try deleting the ^ from the title. Ucucha (talk) 18:35, 20 May 2013 (UTC)

I reverted your move with reason "3d is wrong. 3^d means something else. Categories, search pages and many other places will display the actual pagename and not the DISPLAYTITLE".[7] I then fixed DISPLAYTITLE to display as 3^d by hiding ^ with "display:none".[8] Diffs don't display the DISPLAYTITLE but the revision [9] does. PrimeHunter (talk) 22:42, 20 May 2013 (UTC)

• Updated Template:DISPLAYTITLE doc for superscript/subscript: This topic is an excellent issue for the documentation pages, so I have expanded the examples to include superscripts and subscripts. Although magic word {DISPLAYTITLE:} is recommended, the template doc page also shows some examples, and I added title "E sub 0" as "E₀" as another example:

"E sub 0" as:   E<span style="display:none"> sub </span ><sub>0</sub>

So, "Kalai's 3^d conjecture" is the example now in Template:DISPLAYTITLE for superscripts. In general, many solutions here can be used to update the documentation or help-pages which are read 500x per month (or 540 pageviews for {DISPLAYTITLE} in April). -Wikid77 13:43, 21 May 2013 (UTC)

I have found that none of five tested browsers include the non-displayed ^ when copy-pasting 3^^d. This goes against WP:DISPLAYTITLE which says: "Under the present software configuration, only limited modifications can be made: the displayed title must still resolve to the true name of the page (i.e. if the displayed title is copied and pasted into a wikilink, the link should point to the original page)." bugzilla:26547 suggested to ignore "display:none" in DISPLAYTITLE. Copy-pasting the displayed title of Kalai's 3^d conjecture gives Kalai's 3d conjecture which at least redirects to the right article, but it will look bad if people make a copy-pasted link saying Kalai's 3d conjecture in other articles. 3d and 3^d have completely different meanings. Should we avoid using "display:none"? Is there a reasonable way to write a copy-pastable ^ in a way readers usually don't notice? A tiny font in white is accepted by DISPLAYTITLE but Kalai's 3<span style="color:white; font-size:1%;">^</span><sup>''d''</sup> conjecture to produce "Kalai's 3^^d conjecture" seems like an ugly hack. PrimeHunter (talk) 14:59, 21 May 2013 (UTC)

• For 10 years "display:none" hid copy/paste text in IE browsers: The problem is with the primitive new browsers, so tell people, "Copy the title in IE then paste into their browser to see it", or perhaps some other "display:xxx" setting could be used first, as both together "display:xxx; display:none" where IE would ignore the "xxx" but still process "display:none" and work fine. Anyway, we will find something that works, and don't worry about "ugly hack" because most all computers today are ugly hacks, where most people can no longer tell the difference. I mean even Google cannot directly search for "2+2=4" because it does not know it is an equation, but Google can auto-respell about 500 million words, yet remains clueless about "=" equal sign, so tell me that is not an ugly hack to ignore beginner math (arithmetic) when searching text. The mind boggles, as with cars which auto-lock the doors if started with door open, driver steps out to get package, and the door autolocks with engine running. If $multi-billion corporations can provide such crapnology, for years, then I think we can use "font-size:1%" if needed. Anyway, thanks for noting yet another problem with the new browsers. -Wikid77 06:43, 22 May 2013 (UTC)
  • That's what display: none; is intended to do. Use position: absolute; top: -9999px; to have the text display, but offscreen. That said, I suppose $wgRestrictDisplayTitle is set to true for a reason, and it allowing display: none; is definitely a bu – this setting should also probably strip (almost) all CSS from the displaytitle values. Matma Rex talk 08:02, 22 May 2013 (UTC)
  • I have just submitted a MediaWiki code change for review that would disallow display: none; and several similar values which break $wgRestrictDisplayTitle: [10]. If you were using this anywhere else, please stop, since (assuming the change is merged) it will soon stop working. Matma Rex talk 09:04, 22 May 2013 (UTC)

The display:none; property "causes an element to not appear in the formatting structure". If the element is not in the formatting structure, any text which it would have contained is not present in the rendered page, so is not copypasteable. If IE permitted such text to be copypasted, that is simply another deviation from the standard by Microsoft. --Redrose64 (talk) 10:34, 22 May 2013 (UTC)

I've been keeping an (albeit intermittent) eye on dubious uses of DISPLAYTITLE for a few years now. The tool I've been using to do so is available on the Toolserver for anyone else who'd like to assist with the task - http://toolserver.org/~tb/ODT. - TB (talk) 08:43, 22 May 2013 (UTC)

You might want to look at the gerrit change linked above and see if I missed something else that shouldn't be allowed :) Thanks. Matma Rex talk 09:04, 22 May 2013 (UTC)

Until recently, Firefox would copy display:none; text as well. This was often an issue on the Wikimedia error message page, where users would copy the entire page contents, rather than just the displayed text. (Also, the abuse potential of the enhanced-but-restricted DISPLAYTITLE goes beyond a few missing characters.) --Splarka (rant) 08:16, 23 May 2013 (UTC)

Problem with translation

I can't translate from english to greek. Does anything happen? Nothing change in User:Xaris333/vector.css. Xaris333 (talk) 18:34, 20 May 2013 (UTC)

Vector appears to be broken, see "Something's wrong again" above. --j⚛e decker^talk 18:37, 20 May 2013 (UTC)

• Also some "Cannot find server" of other-language wikipedias: There were temporary periods (such as near 14:00, 21 May) where clicking interwiki links led to Cannot-find-server of the German WP (dewiki) or Greek WP (elwiki) websites. However, interwiki access has been restored. -Wikid77 (talk) 14:22, 21 May 2013 (UTC)

General Cleanup Service for Bots

Problem

There are lots of "minor" things wrong in articles. These include things like too much/little whitespace, things in the wrong place, and incorrect use of wiki markup.
These "minor" fixes do not warrant an edit of their own (unlike "major" fixes), so they accumulate until somebody comes along looking for them, and happens to find another "major" fix to do at the same time.

The Proposed Solution

1. Make a service (probably with an HTTP API) that takes in wiki markup, cleans it up and returns it.
2. Make it ridiculously easy for bot operators to add
3. Convince mainspace bot operators to use the service.

Why Would it Work?

• Whenever a bot makes an edit to an article, it would be fixing a load of problems within the article.
• We would have a central base for these fixes, rather than the fragmented efforts we have at the moment.

Well Why Haven't You Made it Yet?

I can't do this on my own, this needs a framework for collaboration.

What needs to be done?

• We need to build a service that would take in the wiki markup and pass it around to a medium number of modules in an efficient manner, returning the cleaned version within a number of seconds.
• We need efficient modules that take the wiki markup, run a particular minor fix and pass it back/on.
• We need some way of letting people make modules and submit them for approval. Socially approved via BAG? Even if so, still need technical collaboration on modules.
• We need to run it somewhere. The labs perhaps?
• We need bot operators to be willing to use this service.

I can help!

Excellent! What can you help with?

---

930913(Congratulate) 18:42, 20 May 2013 (UTC)

Discussion

Technical Discussion

How could we make it?

This Sounds Awesome!

Please encourage us

This will Never Work

Please elaborate on your critique.

A real edit conflict

What happened here? It seems to have completely wiped the previous edit. — Edokter (talk) — 18:46, 20 May 2013 (UTC)

• That example does appear to be a failure of two cases of "New section" at wp:ANI, where the 2nd overrides the 1st, 3 minutes later (18:39, 20 May 2013), and both edit-summaries said "new section". Perhaps there is a prior Bugzilla ticket for this. However, sometimes people force the new content, to override an edit-conflict with their new message erasing the prior one, which has happened to me twice (yet another reason to auto-correct edit-conflicts rather than give users the option to erase the conflicting text). It is also likely someone edited a prior thread and just completely replaced it with new ==Header== and contents (which I have almost done twice, forgetting I was tagging onto a prior message), and that would be a nice warning as a new feature, during edit-preview (as: "Warning: Edit replaces prior contents"). But I won't insist the evil "Edit-conflict" made them resort to hijacking the contents of a prior thread. -Wikid77 (talk) 23:18, 20 May, 11:24, 21 May 2013 (UTC)

Diff links when a revision's been suppressed

See the recent history of my talk page; a user edited while logged out, and the diffs were oversighted for privacy purposes. As a result, we can't click on some of the radio buttons, but it's still possible to reach redacted versions of diffs by going to older or newer diffs and clicking (prev) or (next). For example, this is unreachable directly from the history page. It's always been this way in my memory, but why? Why can't the link be displayed and simply give us the "You cannot view this diff because one or both of the revisions has been suppressed" message? Nyttend (talk) 18:59, 20 May 2013 (UTC)

That is what the link is giving me. — Edokter (talk) — 19:09, 20 May 2013 (UTC)

No, that's not what I mean; sorry. On the history page, you get something reading

(prev)

Why can't it instead say

(prev)

instead? Why can't we have 13:27, 20 May 2013 instead of 13:27, 20 May 2013 It's not a big deal, but it would seem to me to help navigation without causing problems. Nyttend (talk) 19:39, 20 May 2013 (UTC)

Tech news — 2013, week 21

Latest Tech news from the Wikimedia technical community. Please inform other users about these changes.

Recent software changes

(Not all changes will affect you.)

• The latest version of MediaWiki (version 1.22/wmf4) was added to non-Wikipedia wikis on May 13, and to the English Wikipedia (with a Wikidata software update) on May 20. It will be updated on all other Wikipedia sites on May 22. [11] [12]
• A software update will perhaps result in temporary issues with images. Please report any problems you notice. [13]
• MediaWiki recognizes links in twelve new schemes. Users can now link to SSH, XMPP and Bitcoin directly from wikicode. [14]
• VisualEditor was added to all content namespaces on mediawiki.org on May 20. [15]
• A new extension ("TemplateData") was added to all Wikipedia sites on May 20. It will allow a future version of VisualEditor to edit templates. [16]
• New sites: Greek Wikivoyage and Venetian Wiktionary joined the Wikimedia family last week; the total number of project wikis is now 794. [17] [18]
• The logo of 18 Wikipedias was changed to version 2.0 in a third group of updates. [19]
• The UploadWizard on Commons now shows links to the old upload form in 55 languages (bug 33513). [20]

Future software changes

• The next version of MediaWiki (version 1.22/wmf5) will be added to Wikimedia sites starting on May 27. [21]
• An updated version of Notifications, with new features and fewer bugs, will be added to the English Wikipedia on May 23. [22]
• The final version of the "single user login" (which allows people to use the same username on different Wikimedia wikis) is moved to August 2013. The software will automatically rename some usernames. [23]
• A new discussion system for MediaWiki, called "Flow", is under development. Wikimedia designers need your help to inform other users, test the prototype and discuss the interface. [24].
• The Wikimedia Foundation is hiring people to act as links between software developers and users for VisualEditor. [25]

Tech news prepared by tech ambassadors and posted by Global message delivery • Contribute • Translate • Get help • Give feedback • Unsubscribe • 19:10, 20 May 2013 (UTC)

•  Comment This is partly a follow-up to Wikipedia:Village pump (proposals)#Developer's Noticeboard. Feedback is greatly appreciated. guillom 19:26, 20 May 2013 (UTC)

Smaller watchlist arrows

Usage of arrows in the interface of Vector and MediaWiki in general.

Is this the source of the apparently smaller "expand changes" arrows in watchlists? Is there some rationale for making them smaller and harder to click than ever before? Is there some CSS I can use to force them back to what they were before? Elizium23 (talk) 20:38, 20 May 2013 (UTC)

Yes, this was changed in this deployment. The clickable area of the arrows is not smaller; only the image has changed to resemble the icon used throughout the Vector skin and the new editing toolbar interface. (For any confused readers: this only applies to the "enhanced" watchlist and recentchanges you can enable in preferences.) Matma Rex talk 20:52, 20 May 2013 (UTC)

OK, so the clickable area is the same. I don't know about other users, but personally, I attempt to actually touch the control with the pointer before I click on it, so the reduction in graphic size does effectively reduce the clickable area for my own use pattern. Got some CSS to repair it? Elizium23 (talk) 22:37, 20 May 2013 (UTC)

I first noticed this change with the #Something's wrong again fix above which makes me assume that this was part of some kind of fallback fix... Matma Rex, you're telling me this is unrelated? I'm not sure I like it myself... Technical 13 (talk) 23:18, 20 May 2013 (UTC)

Yep, it's entirely unrelated. The icon is already used throughout the interface, and this change was simply done for consistency – see the screenshot on the right (it's from the Vector skin, but also applies for the other ones). I suppose it could be possible to come up with some custom CSS, but it would be quite an ugly hack. Matma Rex talk 21:11, 21 May 2013 (UTC)

The new arrows are too small to reasonably expand them on my brand new Samsung Galaxy phone. Technical 13 (talk) 19:43, 23 May 2013 (UTC)

Yet another uneeded change that wasn't asked for and doens't benefit the ones doing the actual work. I never used to misclick the wrong arrow for an article but it seems to be pretty common now. BTW, I don't really like the vector skin eithe so making these arrows match the vector skin is not an improvement. It would be nice if the developers could work on some of the projects we have been begging for over the years rather than practice their craft on non problems like this. Kumioko (talk) 19:50, 23 May 2013 (UTC)

URI schemes

I don't see that the new URI schemes link:

• ftps://example.org/
• urn:isbn:0451450523
• geo:37.786971,-122.399677

--  Gadget850 ^talk 20:08, 21 May 2013 (UTC)

Re geo: see Template talk:GeoTemplate#Mobile/Future Standard for Location and bugzilla:48688. --Redrose64 (talk) 20:48, 21 May 2013 (UTC)

I think this change is not deployed yet; it will be included in the next deployment, per the roadmap. Matma Rex talk 20:55, 21 May 2013 (UTC)

It isn't listed on the 1.22/wmf4 changelog, so I'm guessing this is actually in 1.22/wmf5. --  Gadget850 ^talk 12:06, 22 May 2013 (UTC)

Need help with navbox

Template:Billboard Music Award categories shows correct Wlinks when in edit mode, but when I tried to click on a link I got sent to the wrong place. I assumed it was related to the problem causing "{{Navbox" to appear before the navbox, but my attempt to fix both problems seems to have just made a mess.— Vchimpanzee · talk · contributions · 20:17, 20 May 2013 (UTC)

I think I solved the problem. Looking at the history, I found vandalism and merely restored the template to what it looked like before the edits by the vandal, and removing brackets that should not have been closed.— Vchimpanzee · talk · contributions · 21:04, 20 May 2013 (UTC)

Not sure why you need both Template:Billboard Music Award categories and Template:Billboard Music Awards? Plastikspork _―Œ^(talk) 03:00, 22 May 2013 (UTC)

Weird problem in adding categories to an article

For two days I've been trying to add a category (Category:Social movements, or new Category:Social movements in South Korea) to article New Community Movement. I was trying to use HotCat (which I use commonly, and which still seems to work perfectly fine on all other articles I've tested) but each time I tried to save the edit to the NCM page, I'd lose connectivity to Wikipedia in all my browsers for ~1 minute or so. I was unable to replicate this issue in any other article, and I was able to add the category without any problems using wiki syntax regular editing. Any ideas what is causing this problem? It's not a browser issue (happens in Firefox and Chrome), nor is it an accidental server downtime (I was able to replicate it numerous times over the last 24h). I haven't yet had the time to try it out on another computer (HotCat requires log in). Oh, the block or whatever that is affects all wikipedias (I can't access pl or ko) but I can access other WMF sites (meta, wikibooks, etc.) Can anyone else replicate this? I can still replicate this with other categories in that article (just tried to add Category:1970 establishments in South Korea to that article and got the same ~1 minute can't access wikipedia servers). --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 03:05, 21 May 2013 (UTC)

I encountered no problem in Chrome. Ruslik_Zero 19:35, 21 May 2013 (UTC)

wild hypothesis: this has something to do with the upgrade to 1.22wmf4. basically, whenever there is an upgrade, it is possible that the browser still keeps one of the old JS files in cache, and from then on, stuff can happen.

usually the remedy is a full flushing of the cache. in the "big 3" under windows (ff/ie/chrome), this is done by Ctrl+⇧ Shift+Delete (not to be confused with the Three-finger salute) and selecting "Empty the cache" or "Delete temporary files" or simply "cache".

The fact (guess, actually) it's caused by "stray file" in your browser, is the reason why others can't reproduce: they do not have same "leftover files" as you do. please clear the cache and retest. peace - קיפודנחש (aka kipod) (talk) 21:15, 23 May 2013 (UTC)

How does MediaWiki know a redlink is a redlink?

The Transhumanist 03:40, 21 May 2013 (UTC)

That's a pretty vague question. Could you specify where you're wanting to take this discussion? — This, that and the other (talk) 09:47, 21 May 2013 (UTC)

It has code in Linker.php ([26]) that decides whether to add class "new" to links (which makes them red through CSS). The check goes through the LinkCache ([27]), which ultimately (line 227) looks in the page DB table for a page with the given name. Ucucha (talk) 11:56, 21 May 2013 (UTC)

ogg files in Firefox

File:A through Z in Morse code.ogg when played in Firefox cuts off the "Z" at the end and it is not heard. Confirmed with other users, it is not just me. Any ideas what's going on here? SpinningSpark 04:57, 21 May 2013 (UTC)

The file description page lists it as a 38-second file, yet playing it in Chrome shows that it is actually 40 seconds long. Firefox cuts it off at the stated 38 seconds. Possibly a bug with MediaWiki's handling of the file? jcgoble3 (talk) 06:17, 21 May 2013 (UTC)

So what can be done about this - if anything? SpinningSpark 11:02, 21 May 2013 (UTC)

First, file a bugreport at bugzilla. Then, as an intermediary step, re-encoding the file might help. Probably, there is some inconsistency in the timestamping of the audio packets, that the Server side parser is not able to handle properly. Re-encoding the file might realign those timestamps, and cause the file to work. —TheDJ (talk • contribs) 11:52, 21 May 2013 (UTC)

Avoiding aliasing (of SVG files when rendered as PNG)

Hi, I'd want to avoid aliasing of generated SVG files and would like to know which native resolution of the SVG file would least likely be subject to aliasing. I'm free to specify native height and width for the svg file. I asked this question at a less frequently used page before Help_talk:Visual_file_markup#Avoiding_aliasing. Additional info (and links to SVG images which show aliasing after conversion to PNG) is there and it was suggested to bring up the topic here. Thanks! --HeWhoMowedTheLawn (talk) 21:04, 21 May 2013 (UTC)

This is the same thread that I mentioned at #Image preparation advice forum above. --Redrose64 (talk) 22:31, 21 May 2013 (UTC)

"From Wikipedia, the free encyclopedia" bug

I have noticed today that for any article I visit, instead of just saying From Wikipedia, the free encyclopedia below the title, it says teSub">From Wikipedia, the free encyclopedia. Is this affecting anyone else?  Liam987(talk) 02:15, 22 May 2013 (UTC)

I don't see a problem. It sounds like something got cut off, since the id for that element is siteSub. Are you still having a problem? Plastikspork _―Œ^(talk) 02:52, 22 May 2013 (UTC)

@Liam987:. It's a bug in the wikitrust script that you had installed. I have disabled the script for you. You also had two other script loading issues that I corrected. You might want to consider using the AFC gadget from your preferences and disabling that script in your common.js. Also, you load at least igloo twice (once from your common.js and once from your vector.js). —TheDJ (talk • contribs) 20:11, 22 May 2013 (UTC)

Ref template problem

In the notes section for 1987 Eastern Michigan Hurons football team, there is a problem with the display of the date in which the note was retrieved. This should not be hard to find, seeing as there is only one note. AutomaticStrikeout  ?  02:46, 22 May 2013 (UTC)

Fixed it. Two column referencing is not a good idea for only one reference :) Thanks! Plastikspork _―Œ^(talk) 02:50, 22 May 2013 (UTC)

Thank you. I should have checked that. AutomaticStrikeout  ?  15:42, 22 May 2013 (UTC)

Template:Factiva

{{Factiva}} appears to no longer be working, in that it links to a non-existent offsite location. Does anyone know if there is another resource available that links directly to a Factiva resource so that users can click through and verify its validity? Lankiveil ^{(speak to me)} 11:46, 22 May 2013 (UTC).

Odd link not clickable

Tracked in Bugzilla
Bug 48725

Resolved

As pointed out on Talk:Plastic number by another user, in the infobox in Plastic number, the Continued fraction link and the adjacent reference are not clickable in Firefox. I can’t see anything in the code that would distinguish it from the other links, which work fine, and it also works fine in Opera. Can anyone explain this weird behaviour?—Emil J. 12:22, 22 May 2013 (UTC)

It is probably javascript related: the link is clickable (in Chrome) for a fraction of second before the page is fully loaded. Ruslik_Zero 12:54, 22 May 2013 (UTC)

It is also related to template {{Irrational numbers}}: if it is removed the links become clickable. Ruslik_Zero 13:13, 22 May 2013 (UTC)

If the template is replaced with nonempty text, it is still not clickable, so I don’t think it is directly related. On the other hand, removing the entire table row with the template makes Algebraic form nonclickable. It would seem that the loss of clickability only affects the fifth row of a table.—Emil J. 14:17, 22 May 2013 (UTC)

It has to do with the <math> in the main text, to the left of the table. When the math is rendered, after the initial display of the page, extra vertical space is needed. All the links (or parts of links) on the same height as this inserted space are not clickable. I would guess that's because the links are now at a location that didn't exist when the browser scanned for clickable areas. No idea how to to fix this, except for avoiding <math> next to links. — HHHIPPO 14:39, 22 May 2013 (UTC)

(edit conflict) My console is telling me that it is a jax.js error when the link stops being clickable... Researching more. Technical 13 (talk) 14:44, 22 May 2013 (UTC)

Okay, so I "fixed" it by wrapping the <math>...</math> in a <div style="display: inline-block; width: 300px;">...</div> so that it would prevent the math from taking to whole width of the screen and limiting it to what it needs to display the formula. This should probably get someone to submit a bug report. Probably could even skip the div and insert the style into the math tag, not sure... Technical 13 (talk) 14:51, 22 May 2013 (UTC)

From the conversation, I'm assuming you all have MathJax enabled in your preferences ? —TheDJ (talk • contribs) 19:33, 22 May 2013 (UTC)

I can't speak for the others, but I do. Technical 13 (talk) 19:42, 22 May 2013 (UTC)

I filed a bugreport and will also file it upstream —TheDJ (talk • contribs) 19:46, 22 May 2013 (UTC)

Disabling the position: relative; rule for .MathJax_Display seems to fix the problem without any adverse effects. In fact, we might as well kill display: block;, as it is already embedded in a block level element (<dd>). — Edokter (talk) — 19:49, 22 May 2013 (UTC)

bad gateway

I've gotten occasional sporadic "Bad Gateway" returns from the API in my own bots the last few days, and entirely separately from the WP:AFC script. So, I'm pretty sure something's wrong on the server side, anyone have any clue? --j⚛e decker^talk 17:37, 22 May 2013 (UTC)

I've had about a dozen or so Bad gateways over the last week. Don't know what it's from though. 64.40.54.104 (talk) 01:45, 23 May 2013 (UTC)

Where are the skins?

Why are there now only four skins in the preferences page? What happens if I want a custom skin? --Nathan2055^{talk - contribs} 17:53, 22 May 2013 (UTC)

They were deprecated and removed. See Turning off outdated skins on meta for more information.--Jorm (WMF) (talk) 18:29, 22 May 2013 (UTC)

Also Wikipedia:Village pump (technical)/Archive 110#Classic skin and CSS; I think other places too. --Redrose64 (talk) 18:38, 22 May 2013 (UTC)

.texhtml revisited

In September 2012 there was a proposal to redefine the default typeface for class="texhtml", but there was little interest in it (as I realize now, because of conservatism of WP:WikiProject Mathematics and too narrow venue (MediaWiki_talk:) for the final proposal). Later I occasionally noticed that when MathJax downloads its fonts, they can be reused by class="texhtml" (with such declarations as in user:Incnis Mrsi/common.css) in the absence of locally-installed fonts, at least in Firefox. Now I found a case where this hack could be rather useful: the article has both <math> and class="texhtml" formulae, but a user without locally-configured fonts with angle brackets sees them with MathJax, but does not see them in {{math}} because my proposal of 2012 was rejected. Incnis Mrsi (talk) 20:05, 22 May 2013 (UTC)

There is no guarantee that this works with {{langle}} and {{rangle}}; it may not have those characters at the same unicode positions. I'm willing to set up a testcase, but I'm still opposed to the inconsistent behaviour it will introduce depending on the presence of any <math> tags on the page. Either that, or the font should be loaded for .texhtml by default. I don't know if we want that; font-download may go through the roof. — Edokter (talk) — 22:11, 22 May 2013 (UTC)

Assuming a good faith in Edokter’s “it may not have those characters at the same unicode positions”, I resort to conjecture that he did not enable MathJax. Yes, these have the same code points: U+27E8 ⟨ and U+27E9 ⟩ . Incnis Mrsi (talk) 06:23, 23 May 2013 (UTC)

I do have MathJax enabled (Nageh's script). I did some tests with both the MathJax_Main (Computer Modern) and STIX fonts: They look horrendous inline (though STIX looks slightly better). The math template main goal is legibility; using webfonts for inline formulae negates this. So I'm still opposed to introducing this wholesale to solve a single problem. — Edokter (talk) — 20:11, 23 May 2013 (UTC)

When I thought better, I also realized that the solution is faulty because would deprive readers who have neither MathJax nor good fonts. IMHO, a more global approach has to be considered. Incnis Mrsi (talk) 20:38, 23 May 2013 (UTC)

Data inclusion from Wikidata by labels is now available

I just wanted to let you know that it is now possible to include data from Wikidata using the property's label (not just the ID). So in essence this means that you can for example use {{#property:continent}} instead of {{#property:P30}} if you don't want to remember the ID there. Both of these would return "Europe" if used in the article about Spain for example. --Lydia Pintscher (WMDE) (talk) 21:58, 22 May 2013 (UTC)

Errors from simple "exact phrase" searches

(From a question at Help talk:Searching...)

Searching for the "exact phrase" "passed away" is getting false-positives, e.g. the articles Cast Away and Whitney Houston are the 3rd and 4th results. The word "passed" does not appear anywhere in those articles (including the html source code), nor in recent revisions (from any of the last month). However, those do appear to be the only false positives, in the first 200 results.

Does anyone know what is causing this anomaly? Thanks. –Quiddity (talk) 23:45, 22 May 2013 (UTC)

Searches can be affected by the displayed term in piped links. Sparkle (2012 film)#Soundtrack says "recorded by Houston before she [[Whitney Houston#Death|passed away]]". There may be a similar link to Cast Away but I haven't found it. PrimeHunter (talk) 00:34, 23 May 2013 (UTC)

The closest I can get is List of film spoofs in Mad#2000s which says in a table:

| ''Passed Away''

| ''[[Cast Away]]''

I wonder whether the search feature could have misinterpreted that as a piped link. PrimeHunter (talk) 00:43, 23 May 2013 (UTC)

That makes sense. Thanks for investigating and clearly explaining, PrimeHunter. –Quiddity (talk) 22:44, 23 May 2013 (UTC)

Marquee element

Hello! I want to know how Marquee element of HTML can be used on Wikipedia. If not that particular one, how can we get the text to scroll up/down/right/left?

<marquee behavior="scroll" direction="up">This doesn't work! :( </marquee>

I don't know anything about coding. But i tried this one above and its not working. Can someone help? §§Dharmadhyaksha§§ {T/C} 07:59, 23 May 2013 (UTC)

You can't; it's a blacklisted element, and not just because it's distracting and has accessibility problems. It was a Microsoft idea, which was never part of the formal HTML standards (HTML 2.0; HTML 3.2 or HTML 4.01) and is not part of HTML5 either. --Redrose64 (talk) 11:05, 23 May 2013 (UTC)

Oh okay! Well... not that then can such effect be achieved through any other way here on Wikipedia? §§Dharmadhyaksha§§ {T/C} 11:24, 23 May 2013 (UTC)

There are ways to do such a thing, but I'm curious as to why you would want to, where you would want to, and what you expect it to look like? Technical 13 (talk) 11:43, 23 May 2013 (UTC)

I want to use this for a list, where the entries would move from bottom to top or whatever; nothing is yet fixed. You can read the whole proposal here. §§Dharmadhyaksha§§ {T/C} 12:02, 23 May 2013 (UTC)

So, my understanding is that you want a dynamic scrolling list that updates itself as new articles are added, is this correct? If so, you would be looking for a dynamic AJAX Userscript that performs an api request at set intervals and updates your list. Technical 13 (talk) 12:37, 23 May 2013 (UTC)

No! Its going to be a human being who creats a list. What i am looking for is just a dynamic scrolling effect. There is no problem with a static list. But the dynamic list is more attractive one. And now that i am proposing no specific time for updation, a dynamic list is better. §§Dharmadhyaksha§§ {T/C} 16:02, 23 May 2013 (UTC)

Geohack funny again

Geohack has gone funny again. It is showing code as well the links. Simply south...... eating shoes for just 7 years 18:15, 23 May 2013 (UTC)

Nevermind. It seems to have been corrected. Simply south...... eating shoes for just 7 years 18:34, 23 May 2013 (UTC)

I had already fixed it by the time I saw this. It was somewhat similar to this revert which I needed to do a few days earlier. The page seems to attract the attention of IP editors, few of whom make constructive edits, yet there is a discussion on the talk page which suggests that there is no need to protect it. --Redrose64 (talk) 20:02, 23 May 2013 (UTC)

Watchlist question

I just moved BiblioTech to BiblioTech (San Antonio), and marked the new page on my watchlist. However, it doesn't show up in my Watchlist. Like it doesn't exist. I've never had a problem moving files before. I wonder if something has changed in my account to make this one of those tricky things like edits for the non autopatrolled not going through until reviewed by someone else. Please let me know. — Maile (talk) 19:46, 23 May 2013 (UTC)

I have the opposite problem. Once or twice a week, an edit appears in my watchlist and I don't recognise the page at all; and checking the history of the page and its associated talk page, I've never edited either of them. I suspect that somehow, one person's "watch" request is being stored against a different user's name. --Redrose64 (talk) 20:05, 23 May 2013 (UTC)

I have twice experienced something which may be related. Quite embarrassing. See User talk:Moriori#WP:DRN and User talk:Moriori#Could you please explain. I did not make either of the problematic reverts mentioned in those items. Are someone else's edits somehow being attributed to me? — Preceding unsigned comment added by Moriori (talk • contribs) 20:48, 23 May 2013 (UTC)

Moriori, both those edits attributed to you look like accidental rollback clicks to me. I've experienced the same thing a few times, where while scrolling through my watchlist I might accidentally click the rollback button on a random edit. Usually I notice it, but there have been a few times when someone has had to pop round to my talk page to let me know, for one reason or another. The edit summaries match the default rollback edit summary, which for me is pretty conclusive evidence. Now, if you don't have either of those pages on your watchlist, then we have a whole new set of problems... Evanh2008 ^{(talk|contribs)} 20:54, 23 May 2013 (UTC)

Thank you for your response. Each time I visit my watchlist, I scroll down with the cursor on the left, deliberately, to prevent (I thought) accidentally clicking on rollback which is usually on the right, so it seems very unlikely I would accidentally do an involuntary revert. So much for the theory! This morning I see one entry in my watchlist like this:

"(diff | hist) . . Wikipedia talk:WikiProject Templates‎; 06:52 . . (+248)‎ . . ‎Patrick87 (talk | contribs | block)‎ (→‎Dealing with former needed parameters:

re) [rollback]"

so that stymies my theory about being on the right. However, I can't see why I would hit rollback instead of the diff on the line following. I guess I must have become blase, and will need to be more careful. Cheers. Moriori (talk) 21:34, 23 May 2013 (UTC)

Well, I know what you mean, because it's happened to me; once to my certain knowledge, possibly one other time although I don't recall when. I now guard against this by making sure that the watchlist can't flick up or down by one or two lines after it's finished loading. The two main culprits are:

geonotices, which always start off hidden, and expand after loading unless previously dismissed - so if a geonotice appears, I read it, bookmark any links I'm interested in and then dismiss it

watchlist notices, which always start off expanded, and then collapse if I had previously dismissed them - so if a new watchlist notice appears, I read it, click its first link so that it turns to the "visited" colour (which is green for me, because I can't tell the difference between the blue and purple shades that are the defaults around here) but I don't go for its "dismiss" link. The "visited" colour serves as a reminder that I've read it.

In summary: dismiss all geonotices but never dismiss watchlist notices, and the watchlist won't flick up or down after loading. --Redrose64 (talk) 23:14, 23 May 2013 (UTC)

As an aside, why did you move the article? Yes, there may be other BiblioTechs but in the absence of articles about them, I am not sure that a preemptive disambiguating move was necessary.--ukexpat (talk) 20:52, 23 May 2013 (UTC)

OK, Ukexpat, I'm not going to argue that point with you. But this still doesn't tell me why it isn't showing up on my Watchlist. It shows up on my "Contributions", but not Watchlist. I can make the Biblio Tech page show up, but not the one it moved to. Did someone change my user rights without telling me? Another phenomenon, perhaps related (or not) to this. I have Rollbacker rights, which work fine. I can do the regular rollback, an AGF rollback which will be noted as such in the edit summary, and a "rollback (Vandal)". What's changed on that is that I can do a vandalism rollback, but it shows in the edit summary as an ordinary rollback. I thought the edit summary was supposed to say "identified as vandalism". Any clue about that? — Maile (talk) 21:18, 23 May 2013 (UTC)

That change to the Twinkle edit summary was the result of this archived discussion. -- John of Reading (talk) 21:25, 23 May 2013 (UTC)

Thanks, John of Reading. That answers one question. Still open is my original question on why the moved file won't show up on my watchlist. — Maile (talk) 21:30, 23 May 2013 (UTC)

• Well, it hasn't always been this way, but...the file shows up on my watch list if I edit it and save. It just wasn't showing up when I moved it. Go figure. — Maile (talk) 23:12, 23 May 2013 (UTC)

Maybe it got put on somebody else's watchlist, if my earlier suspicion is true. --Redrose64 (talk) 23:14, 23 May 2013 (UTC)

It's funny now that it's working ok again. But a good thing we don't depend on this to pay our bills. — Maile (talk) 23:16, 23 May 2013 (UTC)

Watch-listing and categories

If and editor wishes to follow the information being added to or subtracted from an article that he/she cares about, he/she can add that article to his/her watchlists and track the changes ... but as far as I know there is nothing similar for categorization. There is no way to know when an article has been added or removed from a category we care about. Is there any way to implement some sort of category watchlist? Blueboar (talk) 01:24, 24 May 2013 (UTC)

This would be very useful, if it is feasible. – Philosopher ^{Let us reason together.} 01:32, 24 May 2013 (UTC)

Especially useful for some maintenance categories. GoingBatty (talk) 02:49, 24 May 2013 (UTC)

There is an external tool for that: User:Svick/CW. — HHHIPPO 06:33, 24 May 2013 (UTC)

Page display glitch

Wikipedia:Administrators' noticeboard/Archive248 has some content that appears in the edit buffer that's not displaying in the rendered page. If you click edit and search for "Please remove my ban" you'll see some of it. Seems to have happened here. NE Ent 03:01, 24 May 2013 (UTC)

Fixed, what a difference a closing brace can make! Graham87 05:00, 24 May 2013 (UTC)

A bit more info: The comment in the diff above add an open set of curly braces, which wasn't a problem until this message with a surplus set of closing braces was archived, then the software thought that all the text between the open braces in the first diff and the closing braces in the second diff was all part of one template parameter. I figured out where the problem was by editing the "‎Improper use of speedy deletion ..." section (which was over 400K due to the template glitch) and comparing the displayed text with the text in the edit window. I'm going to remove the unneeded closing braces now, just because I'm paranoid like that. Graham87 05:09, 24 May 2013 (UTC)

Thanks a lot! It was also making load times impossibly huge, which didn't help. :) ·Salvidrim!· ✉ 06:46, 24 May 2013 (UTC)

Technical change in RfA procedure

So I went through the WT:RFA archives to see if the change I'm talking about has already been discussed. But it's not (from as far as I looked). All those proposals only talked about changing the way discussion takes place, and what I'm talking about here is rather a technical change.

Although I'm quite new to RfAs and the only RfA nomination I made failed (though not per WP:SNOW or WP:NOTNOW), I've noticed that the people involved at RfA discussions mostly judge a user by their contributions – what they have done – rather than what they could possibly do if they had the mop (other things are taken into consideration, too, of course, but they've nothing to do with what I'm proposing here), which is not completely fair in my opinion. Sometimes, even candidates who have had a decent amount of experience in administrator-involving fields fail due to other trivial flaws, as the community assumes that since the candidate cannot be careful about those, they can't be trusted with the mop, either.

What I'd rather like to see at RfAs is that a special environment be created for the admin candidate, where they'd be challenged by various things an admin has to deal with. The candidate will temporarily become an administrator inside of this environment alone (it could be at Wikipedia:Requests for adminship/ExampleUser/Challenge and all its subpages, for example). These "challenges" shouldn't be obvious ones, like blocking obvious vandals or trolls, but rather something that could truly demonstrate that the candidate deserves the mop. This "environment" I'm talking about could be similar to (or rather more complex than) the new admin school. These challenges should only be presented when the candidate is a reasonable RfA candidate (i.e., not likely to fail per WP:SNOW or WP:NOTNOW, because if anyone were allowed to take it up, every Tom, Dick and Harry would apply for RfA just for the fun of it, I do understand). Bureaucrats could be given the power to allow temporary access to admin tools to the candidate inside of that environment. I've noticed that some people do this already in the form of questions, but not everyone does and this proposal is more practical than mere questioning.

While it may sound interesting, my proposal is flawed and incomplete since I've missed a lot of things: how the hell will this happen? When should the candidate be allowed to take up this challenge: before the discussion? After the discussion (or maybe along with it)? How exactly would those challenges work (for example: maybe someone would need to 'play' the vandal or the troll, for testing the 'vandalism skills' of the candidate)? (And even this list of questions is incomplete.)

Also note that this proposal is not to replace the existing RfA procedure, but rather to add to it. The discussion will still take place as it does, and even though the candidate 'passes' the challenges and the discussion fails to achieve a consensus in favour of the candidate, the candidate should fail. The discussion should still be given the first priority, since it could be that the only reason the candidate passed this challenge was only that they got lucky or something. The bottomline of this proposal would be: "RfA candidates, in addition to being subjected to the discussion, should also be tested practically." Exactly how: that's what I don't know and what this discussion will (hopefully) clear up (even if this proposal does fail, it would still, at its very worst, make for a good joke for days to come). smtchahal^talk 06:23, 24 May 2013 (UTC)

This would be trivially easy to do if it could be contained to a talkpage and this 'admin testing' didn't come with the unblock right. Candidate creates doppelganger account, bureaucrat adds the 'admintest' flag or whatever, and blocks the user. Testing of tools could take place solely on that useraccount talkpage. No chance of rouge admin running wild.

That being said, I don't think this is a useful idea. Can you provide some examples of what one could test an admin on that isn't just as easily tested for by saying "In situation X, what would you do" ? — The Potato Hose 06:45, 24 May 2013 (UTC)

This admin test thing would, in a sense, make it compulsory for the discussion participants to know how an admin would behave if given the mop, because as I mentioned, not everyone asks these questions, and even the questions of those who do are disregarded by many participants. I mean, if one can just see what the result of that testing thing was, one can't simply ignore it; it could decrease the number of "no experience in admin fields" oppose rationales.

Yes, blocking and unblocking is something to worry about in this testing thing. That is one reason why I myself questioned "how the hell will this happen?". Maybe the blocking and unblocking part is the only one that can't be included in this 'admintest' thing. smtchahal^talk 07:05, 24 May 2013 (UTC)

(edit conflict)I don't think it would be regarded as a joke. No serious suggestions made for changes to the RfA system have been regarded as a joke even if they failed to find consensus. What is frustrating for the proponents for change is that almost anything that might work doesn't garner enough support or even participation in discussions. Add to that, some people are still looking for proof that there is anything wrong with the system and proof that there is admin attrition - things that by now are really abundantly clear. Kudpung กุดผึ้ง (talk) 06:53, 24 May 2013 (UTC)

That is a gross mischaracterization of my position, and you know it. — The Potato Hose 06:57, 24 May 2013 (UTC)

There's a precedent set for this by the BAG. It's how we approve bots. All bots get trialled to ensure they are doing what they should. If it can work for WP:BRfA it should work for WP:RfA. 930913(Congratulate) 07:06, 24 May 2013 (UTC)