Wikipedia:Village pump (technical)

Policy

Technical

Proposals

Idea lab

WMF

Miscellaneous

• Table of contents
• First discussion
• End of page
• New post

Shortcuts

• WP:VPT
• WP:VP/T
• WP:TECHPUMP
• WP:PUMPTECH

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.

view · edit Frequently asked questions (see also: Wikipedia:Technical FAQ) Click "[show]" next to each point to see more details. If something looks wrong, purge the server's cache, then bypass your browser's cache. This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown. No, we will not use JavaScript to set focus on the search box. This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences. No, we will not add a spell-checker, or spell-checking bot. You can use a web browser such as Firefox, which has a spell checker. If you have problems making your fancy signature work, check Help:How to fix your signature. If you changed to another skin and cannot change back, use this link. Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem. If an image thumbnail is not showing, try purging its image description page. If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear. For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

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

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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[reply]

• 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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

{{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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

(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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

#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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

• 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)[reply]

  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)[reply]

• 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)[reply]

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)[reply]

• 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}} → 6815

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)[reply]

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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

Ah. Well, when I tried relisting them myself, I got the same result... - The Bushranger _{One ping only} 18:03, 24 May 2013 (UTC)[reply]

I just relisted Wikipedia:Articles for deletion/Network Chorley (2nd nomination), and while it did properly transfer from one log to the other, the 'View log' link remained pointing to the original log, not the relisted one. - The Bushranger _{One ping only} 18:25, 24 May 2013 (UTC)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

"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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

(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)[reply]

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)[reply]

$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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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".[3] I then fixed DISPLAYTITLE to display as 3^d by hiding ^ with "display:none".[4] Diffs don't display the DISPLAYTITLE but the revision [5] does. PrimeHunter (talk) 22:42, 20 May 2013 (UTC)[reply]

• 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)[reply]

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)[reply]

• 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)[reply]
  • 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)[reply]
  • I have just submitted a MediaWiki code change for review that would disallow display: none; and several similar values which break $wgRestrictDisplayTitle: [6]. 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

User:Wikid77's argument about not worrying about ugly hacks is a classic WP:OTHERSTUFFEXISTS argument. The existence of other ugly hacks is no reason to tolerate or encourage further hacks. Be careful about increasing our technical debt.

Also, missing features in Google can hardly be called ugly hacks – it is functioning as designed. Because it doesn't do what you want doesn't make it a hack – treating equations differently from other search terms would be more of a hack. Having said that, Google does give special treatment to "2+2=". – PartTimeGnome (talk | contribs) 14:28, 26 May 2013 (UTC)[reply]

• Confirmed text positioned off-screen can copy/paste in new browsers: To continue the sophisticated formatting of superscript/subscript titles in {DISPLAYTITLE}, I think hiding the "sub" or caret "^" text is fine using span-tag attributes "<span style="position: absolute; top: -9999px;">^</span>" as a browser-independent technique. The prior method using "display:none" does not work to hide copy/paste text in newer versions of Firefox, although it worked for over 10 years in older versions of MSIE. The wiki world is ready for more sophisticated titles, such as "E₀=mc²" to explain the level of energy (E) at velocity zero (0). -Wikid77 (talk) 22:17, 24 May 2013 (UTC)[reply]

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)[reply]

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

• 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)[reply]

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

• 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)[reply]

•  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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

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)[reply]

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

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)[reply]

It has code in Linker.php ([22]) that decides whether to add class "new" to links (which makes them red through CSS). The check goes through the LinkCache ([23]), 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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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

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

{{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).[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

(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)[reply]

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)[reply]

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

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

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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

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)[reply]

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)[reply]

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 ⟨ MATHEMATICAL LEFT ANGLE BRACKET and U+27E9 ⟩ MATHEMATICAL RIGHT ANGLE BRACKET. Incnis Mrsi (talk) 06:23, 23 May 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

(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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Marquee is not part of HTML but part of CSS3. -sarvajna (talk) 10:52, 24 May 2013 (UTC)[reply]

Dharmadhyaksha is talking about the marquee element, which was devised by Microsoft and first incorporated into Internet Explorer 2 (November 1995), and since it is invoked as <marquee attributes>...</marquee>, it is a form of HTML although it has never been part of the formal HTML standard. IE2 predates CSS by over a year, and CSS couldn't be used from HTML until HTML 4 (December 1997). CSS 3.0 (but no earlier versions) does have what it calls a "marquee module", which I have deliberately refrained from giving details for. --Redrose64 (talk) 14:03, 24 May 2013 (UTC)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

• 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)[reply]

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

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)[reply]

For example, this edit appeared in my watchlist today. I don't recognise the name, and I can't find myself in the history of either the talk or the article. But somehow it's on my watchlist. --Redrose64 (talk) 12:24, 24 May 2013 (UTC)[reply]

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)[reply]

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

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

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

Thanks HHIPPO... that is good to know. Any way to make it an internal tool? Blueboar (talk) 11:50, 24 May 2013 (UTC)[reply]

this is a very old bug in bugzilla (7148). apparently, implementing this functionality is far from trivial. peace - קיפודנחש (aka kipod) (talk) 15:25, 24 May 2013 (UTC)[reply]

I wonder if one could use something like Extension:CategoryWatch, but with notifications instead of e-mails. On the other hand, to do it properly the feature should be integrated in the watchlist, which would need modified or added database tables. Indeed, far from trivial. — HHHIPPO 17:59, 25 May 2013 (UTC)[reply]

we could lobby to include this extension on wikimedia wikis, but i suspect the reason why this was not done already is not because nobody noticed this extension exists... i haven't read/reviewed the extension code, but my guess is that either the code itself does not pass muster, or that it was judged to be too expensive from performance point of view (or both). i looked into it some time ago, and as far as i remember, the functionality that the extension provides is not _exactly_ the desired functionality, but it comes pretty close.

some time ago i suggested this as a "mediawiki google summer of code (aka gsoc)" suggested project, but it was deemed to be a little more than a reasonable gsoc project, and it was practically shot down (btw, this is briefly discussed in the linked bugzilla bug). peace -קיפודנחש (aka kipod) (talk) 19:48, 25 May 2013 (UTC)[reply]

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)[reply]

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

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)[reply]

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

Here, passing many large parameters to a run-away template becomes exponentially slower, as the bar/pipes add 2 more parameters at each signature, and the parser struggles to prepare the massive 400 kb parameters, likely rescanning the earlier parameters to see if they have the same parameter name/number as the next run-away parameter gobbled into the template. -Wikid77 22:51, 24 May 2013 (UTC)[reply]

Thanks ... thought it was prob something like that. NE Ent 09:58, 24 May 2013 (UTC)[reply]

Moved to Wikipedia:Village pump (idea lab) § Technical change in RfA procedure

 – There doesn't seem to be much point in proposing something that isn't very clear. Hence, the idea lab would be better to decide how this thing will work, or if it will at all; rather than subjecting it to supports and oppositions already. smtchahal^talk 09:17, 25 May 2013 (UTC)[reply]

Moved from Wikipedia talk:Village pump (technical) § Sandboxes at the Afc

 – Redrose64 (talk) 15:19, 24 May 2013 (UTC)[reply]

Dear Tech people:

Earlier today over 100 sandboxes, all with different users, appeared in the Afc submission list, with submission dates as much as 19 days old, although they were not there yesterday. None of them are finished articles. The reviewers have been marking them for deletion, but no one knows what has caused this. Each appears to have been submitted by the proper user. Is there some kind of technical experiment that could be changing submission dates or adding submission templates with old dates to people's sandboxes inadvertently? I am worried that people may wake up today and find their half-finished projects gone. —Anne Delong (talk) 11:46, 24 May 2013 (UTC)[reply]

Please give a link to the list you refer to, and an example page. PrimeHunter (talk) 13:42, 24 May 2013 (UTC)[reply]

See WT:WikiProject Articles for creation#Backlog just increased for details. Technical 13 (talk) 14:47, 24 May 2013 (UTC)[reply]

I don't see a link to a list there. I guess it's actually a category but I don't see a link to a category either. If you ask outsiders for help then you shouldn't make them work just to figure out which page you want help with. But it appears the insiders have worked it out. Maybe "the Afc submission list" meant Category:Pending AfC submissions (one of many categories with AfC submissions). PrimeHunter (talk) 18:41, 24 May 2013 (UTC)[reply]

Over the last couple of days, I've noticed in that the AfD template the link to the discussion page (with the phrase "this article's entry") is in red instead of the usual blue. I (and at least one other editor) assumed the link was broken, but it still works when you click on it; however, when you hover over it you see "(page does not exist)". Although it still "works", the red color is confusing. Thanks and all the best, Miniapolis 14:02, 24 May 2013 (UTC)[reply]

• Agree the redlink is confusing and should link overall title: So, an admin should update the protected Template:Article_for_deletion/dated, to provide a stand-alone blue-link:

• Old: '''[[Wikipedia:Articles for deletion/{{{page|{{PAGENAME}}}}}|this article's entry]]'''
• New: '''[[Wikipedia:Articles for deletion<includeonly>/{{{page|{{PAGENAME}}}}}</includeonly>|this article's entry]]'''

By having the conditional <includeonly> tag, then the former redlink would become a valid blue-link in stand-alone mode showing the template blurb, as link "this article's entry" to be less confusing for users who are not familiar with using that template. Using <includeonly> runs within 1/2000 second and would not affect performance of the AfD template. -Wikid77 (talk) 15:10, 24 May 2013 (UTC)[reply]

See Wikipedia:Village pump (technical)/Archive 108#Link to AfD discussion in template incorrectly displaying as redlink and Wikipedia:Village pump (technical)/Archive 110#Redlink to AfD debate. --Redrose64 (talk) 15:12, 24 May 2013 (UTC)[reply]

Thanks for the help. Since the problem seems browser-dependent (forgot to mention I'm using Firefox 21.0), I'm more comfortable purging the cache than making my first edit to a protected template at this time :-). All the best, Miniapolis 15:26, 24 May 2013 (UTC)[reply]

First let me say I'm not a programmer, so don't beat me for suggesting something infeasible. :) But anyway, he's my thought:

Consider the article Maimonides for instance. At the bottom, via {{Authority control}}, it is connected to this GND/DNB profile (DNB as in Deutsche Nationalbibliothek). As you can see, the DNB profile lists a couple of dozens of alternative spellings of Maimonides' name. So I was thinking how great it would be if the Wikipedia software would automatically extract these name variants and create redirects to the actual article (not just to Maimonides, of course, but to all Wikipedia articles with GND identifiers). The data is also available in RDF format, so machine readability shouldn't be an issue here (again I'm not a programmer).

Is it possible to do this? Because it would save Wikipedia editors a lot of time and energy not having to create all those redirects manually. --bender235 (talk) 16:52, 24 May 2013 (UTC)[reply]

• Sourced variant names are interesting but WP overrun by variants: That suggestion, to use the Deutsche Nationalbibliothek profiles (or other) to generate redirect titles is an interesting idea, but there are just too many thousands (over 280 thousand?) of redirects, and we need to restrict (remove) to only have the high-use variants. The best place to list numerous variant spellings is within an article's footnotes, and then a wikisearch (Search:[______]) for those rare spellings would match to whichever articles contained them. Meanwhile, we really need a Bot to sift through over 280 thousand current redirects as "improbable redirects" to delete them. For example, a variant of "New York" might include "Newe Yorke" as a reasonable spelling, as stylized from the archaic word "newe" used in other town names; however, some/many people have gone wild and created zillions of bizarre redirects, in the style of "Nuew Yorkke" or "Nue Yorrk" or "Nu.YoRK." or even "N.w Y.rK" or similar bizarro redirects (the mind boggles, see: 65,500 titles in "Category:Redirects from alternative names"). So, in a sane world, then auto-creating historical variant spellings would make sense, but WP is currently overrun, overwhelmed with "redirect hoarding" of certainly many thousands of useless redirects, often many variations of corporation names. However, long-term, perhaps most redirects would be auto-removed unless listed in profiles of variant spellings, so the initial idea might be used, in the future, to prune away thousands of unsourced spellings. -Wikid77 (talk) 01:58, 25 May 2013 (UTC)[reply]

Dude, redirects are cheap. I don't see a problem with the proposal, but if one of the alternative titles was already a blue link or redirected somewhere else, this would obviously require human review. Graham87 03:46, 25 May 2013 (UTC)[reply]

And it can all go into WikiData. —TheDJ (talk • contribs) 08:19, 25 May 2013 (UTC)[reply]

The best place to list numerous variant spellings is within an article's footnotes, and then a wikisearch (Search:[______]) for those rare spellings would match to whichever articles contained them.

Maybe. But then again, this would be manual labour, too, wouldn't it? The point of my proposal was to do this automatically. --bender235 (talk) 11:42, 25 May 2013 (UTC)[reply]

Does anyone know why this template, which is categorized into two speedy deletion categories, seems to be missing from both of them? I tried purge but it didn't help. GregorB (talk) 18:35, 24 May 2013 (UTC)[reply]

note the words in the category page

"This list may not reflect recent changes (learn more)."

the last two words in this sentence are a link - use it. peace - קיפודנחש (aka kipod) (talk) 19:01, 24 May 2013 (UTC)[reply]

Null edit made... Feeling a little bitey and annoyed with people today kipod? It's all good, everyone has their days. Technical 13 (talk) 19:07, 24 May 2013 (UTC)[reply]

absolutely not. pointing the fact that something is explained (somewhere) and suggesting the person might want to read the explanation is not like saying "RTFM" - it's more like giving someone the link to "TFM". the assumption is that the person was not aware of the this piece of documentation, and pointing to it is doing them a service. peace - קיפודנחש (aka kipod) (talk) 22:21, 24 May 2013 (UTC)[reply]

I know sometimes changes are not propagated instantly, but it's been three weeks since the template was added. It was supposed to be a speedy deletion, however the template got stuck in nowhere land, so the admins couldn't see it. I was about to try the null edit as suggested, but you just beat me to it. Problem solved, thanks! GregorB (talk) 19:15, 24 May 2013 (UTC)[reply]

I actually had the same problem with Template:Matlock and am now thinking that maybe Joe's Null Bot by Joe Decker should be put to work here as well since these are suppose to be speedies... Technical 13 (talk) 19:48, 24 May 2013 (UTC)[reply]

• Category links are MediaWiki design flaw so use null-edit bypass: The failure to update category links, even after 3 weeks, is a massive failure of the MediaWiki software, and imagine how intensely the developers have had to struggle to overcome all the bizarre, convoluted quirks of the initial MediaWiki versions (think: "MediaWacky"). However, accurate categories are important, and so the tactic of using a null-edit bot to "knock some sense" into the MediaWiki database links is a reasonable option. In this age, of layer upon layer of software modules, it is becoming nearly impossible to keep pace with problems; however, the potential for "crowd-sourcing" or "expert-group-sourcing" might resolve problems faster, as more people work together to solve vast numbers of software problems. In fact, it might make sense to have "null-edit backlog drives" to encourage hundreds of editors to help correct category links in some high-priority categories, perhaps in articles about medical treatments or such. However, the future seems clear to me: "Everyone worry about performance" (versus the archaic wp:PERF), and together perhaps we can quickly find the causes of the massive software bugs in the Wikipedia software or else, help to manually (or Bot-wise) circumvent the problems to lessen their impact. Perhaps some day we might look back on the list of "Top 20 appalling MediaWiki software problems" and remember why it took so long to fix some of them. But keep looking for solutions. -Wikid77 (talk) 21:54, 24 May 2013 (UTC)[reply]

Resolved

 – Thanks for fixing. -- Toshio Yamaguchi 21:12, 25 May 2013 (UTC)[reply]

In my draft page at User:Toshio Yamaguchi/Main page redesign proposal, all of a sudden the boxes are all messed up. It looked OK the last time I looked at the page yesterday. In particular, the second round-cornered box is supposed to sit below the FA box. Since I didn't make a change that could have caused this (at least not that I am aware of) I guess that a change was made somewhere else. What can be done so that it appears as intended again? The FA box is supposed to be a separate box above the box containing In the news, Did you know and On this day. -- Toshio Yamaguchi 10:59, 25 May 2013 (UTC)[reply]

Today's featured article Wikipedia:Today's featured article/May 25, 2013 has an unclosed "div". -- John of Reading (talk) 11:19, 25 May 2013 (UTC)[reply]

Fixed. Ucucha (talk) 13:19, 25 May 2013 (UTC)[reply]

The Czech Wikipedia namespaces its maintenance categories, for example Category:Tracking:Missing coordinates or Category:Error:coordinates greater the 360 degrees. Any reason we shouldn't do likewise? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:52, 25 May 2013 (UTC)[reply]

The former: Category:Articles_needing_coordinates. The latter we have: Category:Pages_with_malformed_coordinate_tags. —TheDJ (talk • contribs) 13:37, 25 May 2013 (UTC)[reply]

Thank you; I'm familiar with both of those. I'm not asking for new categories, I'm suggesting that we change how we name them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 05:53, 26 May 2013 (UTC)[reply]

My response fell into the category of don't post while your are half drunk at a Hackathon :D —TheDJ (talk • contribs) 18:41, 26 May 2013 (UTC)[reply]

They aren't namespaces. They are just names with a colon. For example, cs:Kategorie:Systém:Skryté kategorie is a category called "Systém:Skryté kategorie". "Systém:" is the first 7 characters of the name and doesn't have any of the namespace features. PrimeHunter (talk) 14:02, 25 May 2013 (UTC)[reply]

Not in the MediaWiki sense, perhaps, but in the general sense they are. The Czech guys do clever stuff with them. I'll invite one to comment here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 05:53, 26 May 2013 (UTC)[reply]

This does seem rather useful to me. Especially with Special:PrefixIndex, you can do a few interesting things, that are simply not possible with our current tree based structure. It does raise the question about why this isn't actually possible with the core software, but i'd be in favor of actually trying this out with at least our error categories. —TheDJ (talk • contribs) 18:41, 26 May 2013 (UTC)[reply]

Hi all; some of you (esp. First Light, Davidgothberg, TheDJ) may remember this problem concerning non-display of {{BLP editintro}} when editing a section. The problem was resolved; but I have just noticed that the old behaviour has returned: {{BLP editintro}} is only displayed when editing the whole page, not when editing a section. I've looked at recent changes in MediaWiki:Common.js but I've had to go back more than five months to find anything that might be relevant. Could it be this edit? What is the significance of a triple-equals in a test like

if ( cats[i].title === 'Category:Living people' || cats[i].title === 'Category:Possibly living people' ) {

and how does it differ from the double-equals that I'm familiar with in C? --Redrose64 (talk) 13:23, 25 May 2013 (UTC)[reply]

 Fixed Was broken due to the recent rename of the editsection class. diff —TheDJ (talk • contribs) 13:34, 25 May 2013 (UTC)[reply]

In revision history listings of pages on my watchlist, the highlighting of edits since I last visited the page doesn't work anymore (using Monobook). Thanks for any help... AnonMoos (talk) 19:50, 25 May 2013 (UTC)[reply]

Today, I'm having a similar problem in Vector. For me also, the green highlighting in edit histories is gone, and I would very much like to have a way to get it back. Instead, what I see now is a small bullet point at the beginning of each entry, and the point changes from green (new) to blue (previously visited), with these dots also on my watchlist. For me, it's fairly difficult to see the difference in color of the small dot. --Tryptofish (talk) 20:21, 25 May 2013 (UTC)[reply]

Thanks for mentioning the green dots (I could have gone a looong time without figuring that out for myself). I need to put my face up close to the screen and squint to make use of them, so I agree there definitely needs to be a change... AnonMoos (talk) 21:07, 25 May 2013 (UTC)[reply]

I noticed it 2+1⁄2 hours ago; I was wondering how long it would take people to complain. This is the edit; there is a link in the edit summary to the relevant discussion. --Redrose64 (talk) 21:11, 25 May 2013 (UTC)[reply]

(edit conflict) Yes, they are indeed difficult to see (in terms of color). I don't mind, however, if the change remains in place, just so long as there is an opt-in workaround for those of us who would like to put something in our preferences that restores the green-font "changed since your last visit" notice on the edit history pages. --Tryptofish (talk) 21:14, 25 May 2013 (UTC)[reply]

(edit conflict) (edit conflict) (edit conflict) it's because of this edit. i did not see it discussed anywhere, and i think it should be reverted, or at least discussed. for now (i.e., until it's reverted), you can undo it for yourself by adding to Special:MyPage/common.css the following line:

span.updatedmarker { display: inline; }

i do not think it's an acceptable solution, though. i think this edit should just be reverted. IMO it is borderline sabotage (although i'm sure this was not the intention). peace - קיפודנחש (aka kipod) (talk) 21:16, 25 May 2013 (UTC)[reply]

(edit conflict)(sorry about all the ecs) Per Redrose's link, there was "discussion" here: WP:Village pump (proposals)#"Updated since last visit" markers, where I'm about to make a cross-notice. --Tryptofish (talk) 21:19, 25 May 2013 (UTC)[reply]

yes, i had so much trouble saving my edit that i did not read carefully the previous addition to the section. i now read the discussion, and i could not find anywhere in the proposal a mention of "oh, and by the way, i am going to hide the updatemarker". all i saw was a discussion of blue vs. green dots, to which i am pretty agnostic. peace - קיפודנחש (aka kipod) (talk) 21:22, 25 May 2013 (UTC)[reply]

to clarify: the actual edit did some things which were not at all discussed in the proposal. only those things (i.e., hiding the green "changed since your last") should be reverted, not necessarily the whole edit. peace - קיפודנחש (aka kipod) (talk) 21:26, 25 May 2013 (UTC)[reply]

Gazillions of ECsTo restore it like it was, add the following to Special:Mypage/common.css:

span.updatedmarker {
    display: inline;
    font-style: italic; /* if desired */
    background-color: transparent; /* this makes the text colored (not highlighted); use if desired */
    color: #006400; /* green, not black */
}

But I agree that User:Edokter didn't really have consensus, and (like with the orange bar and Notifications) it wasn't clear that this new feature would remove the old one. I thought it would only change the color of the dots. Ignatzmice•talk 21:30, 25 May 2013 (UTC)[reply]

Thanks, both of you, very much! For me, the second of these fixes (the one from Ignatzmice) is the one that most exactly restores what I wanted back. Also, if one uses Vector, I think it's the "vector.css" file, rather than "common.css" that needs to be edited. --Tryptofish (talk) 21:37, 25 May 2013 (UTC)[reply]

Thanks, I always like trying to figure out these kinds of things! Common.css changes it for all of your skins; the specific ones change it only for that specific one. So long as you only use one skin, it's six of one, half-dozen of the other. Ignatzmice•talk 21:40, 25 May 2013 (UTC)[reply]

Woops, thanks. I changed both (12?). Anyway, I'm happy again. I'll also point out for future readers here that your instructions include "optional" parts, and I included those to get the same font color and format as before. --Tryptofish (talk) 21:44, 25 May 2013 (UTC)[reply]

(edit conflict) regarding the style, you are correct that "my" snippet does not restore it exactly to the way it was, while Ignatz's snippet does. "mine" actually restores it to the way i see it on other wikis, which i prefer personally. but this is really splitting hair - the main thing is to restore the message itself. as to vector.css vs. common.css: since the sabotage was done on Mediawiki:Common.css, i think it makes more sense to override it in the personal common.css. peace - קיפודנחש (aka kipod) (talk) 21:48, 25 May 2013 (UTC)[reply]

Ok, for the non techies like me, what's the code to remove the dots (of any colour), please? NtheP (talk) 22:46, 25 May 2013 (UTC)[reply]

/* Hide reset button */
#mw-watchlist-resetbutton {
    display: none;
}
/* Restore default bullets */
.skin-cologneblue li.mw-changeslist-line-watched,
.skin-cologneblue li.mw-history-line-updated {
    list-style-type: disc;
}
.skin-monobook li.mw-changeslist-line-watched,
.skin-monobook li.mw-history-line-updated,
.skin-modern li.mw-changeslist-line-watched,
.skin-modern li.mw-history-line-updated {
    list-style-image: url(/w/skins/monobook/bullet.gif);
}
.skin-vector li.mw-changeslist-line-watched,
.skin-vector li.mw-history-line-updated {
    list-style-image: url(/w/skins/vector/images/bullet-icon.png);
}

— Edokter (talk) — 22:59, 25 May 2013 (UTC)[reply]

• NtheP seemed to be asking how to remove any dots. I would imagine that could be achieved with list-style-image: none;, but that's not working for me.... Ignatzmice•talk 23:05, 25 May 2013 (UTC)[reply]
  • That would restore the default HTML bullets. I do think he asked how to restore the original bullets. — Edokter (talk) — 23:11, 25 May 2013 (UTC)[reply]

(edit conflict) (edit conflict) (trying to answer the question: how to remove the dots in history. not sure if it's the same as Ignatz's answer, but if so, i guess it won't work...)

try

ul#pagehistory { list-style: none none; }

this comes with zero guarantee...  : ( peace - קיפודנחש (aka kipod) (talk) 23:08, 25 May 2013 (UTC)[reply]

• I'm trying to make the newly appeared neon green dots on the watchlist go away and have tried several pieces of code above but none seems to work. Which script to use to make them disappear on the watchlist only? Victoria (talk) 23:15, 25 May 2013 (UTC)[reply]
  • You put the entire code in your User:Victoriaearle/common.css. — Edokter (talk) — 23:19, 25 May 2013 (UTC)[reply]
    • Got it thanks. Victoria (talk) 23:34, 25 May 2013 (UTC)[reply]

Yes thanks for that code to remove those stupid green dots. Lugnuts ^{Dick Laurent is dead} 09:16, 26 May 2013 (UTC)[reply]

Getting rid of any dots would be great but it's enough for me to be able to reset them to black and unchanging. Edoktor, thanks for posting the code. NtheP (talk) 09:23, 26 May 2013 (UTC)[reply]

Edokter, why did you change none; to none none; here? I would have thought that it had no effect. Is this some new syntax for CSS 3, rather like !important? --Redrose64 (talk) 10:42, 26 May 2013 (UTC)[reply]

list-style is a shorthand for list-style-type, list-style-image and list-style-position. In order to disable the bullet completely, the first two need to be set to none. Because there are two properties that accept none as a value, you need to specify it twice in the shorthand notation for both properties to be set. — Edokter (talk) — 11:09, 26 May 2013 (UTC)[reply]

I agree that list-style is a shorthand for the other three, it's in the CSS 2.1 documentation; but that documentation says nothing about the first value applying to the type, the second to the image and the third to the position. The general principle with CSS properties that accept multiple values is that the order that they are specified is unimportant.

That doc page states "A value of 'none' within the 'list-style' property sets whichever of 'list-style-type' and 'list-style-image' are not otherwise specified to 'none'. However, if both are otherwise specified, the declaration is in error (and thus ignored)." very near the bottom of the doc, and then explicitly states "a value of 'none' for the 'list-style' property sets both 'list-style-type' and 'list-style-image' to 'none'", with an example of such use. --Redrose64 (talk) 15:19, 26 May 2013 (UTC)[reply]

Is that the correct version, and is it still current? I've seen this fail in both Chrome and Firefox if only one none is specified. I also think that otherwise means being set to anythinng else the "none". — Edokter (talk) — 15:30, 26 May 2013 (UTC)[reply]

I can't seem to reproduce the bug though; one "none" seems to work (but two isn't an error). — Edokter (talk) — 15:38, 26 May 2013 (UTC)[reply]

It's the latest recommended version. At the W3C All Standards and Drafts list, there is a link Cascading Style Sheets (CSS) Snapshot 2010, which does yield a list of properties, but in there the entry for list-style points straight to the doc that I linked at 15:19, 26 May 2013.

There is CSS Lists and Counters Module Level 3, dated 24 May 2011, but that's described as a "Working Draft", so it's not final. It does give a better explanation of the none value. --Redrose64 (talk) 18:54, 26 May 2013 (UTC)[reply]

On a related note, is there some code that would get rid of the green highlighted "updated since my last visit" that appears in the history?--十八 10:53, 26 May 2013 (UTC)[reply]

.updatedmarker { display: none; }

— Edokter (talk) — 11:09, 26 May 2013 (UTC)[reply]

Thanks.--十八 20:52, 26 May 2013 (UTC)[reply]

What happened to the List of national anthems? Screenshot is taken in IE with Monobook; I've reloaded the page multiple times without noticing any differences. Nyttend (talk) 22:23, 25 May 2013 (UTC)[reply]

Hmm, looks OK for me in Firefox 21 and IE 10. Maybe a caching problem on your side? The only glitch I noticed are the empty source fields for many anthems, which should probably contain at least a   to not produce empty cells. --Patrick87 (talk) 22:40, 25 May 2013 (UTC)[reply]

Looks fine to me (Monobook on Safari on OSX). Maybe clear out your cache? Ignatzmice•talk 22:42, 25 May 2013 (UTC)[reply]

It's fine for me (Firefox 21 under Windows XP in Monobook skin). However, it does take a very long time to load, so your setup may have a memory issue. Regarding the last (Source) column: it's not necessary to put   into those, just make sure that there is a cell-start marker (single pipe on a line of its own, or double pipe at the end of the cell for the audio file) for that column on every row without a source. --Redrose64 (talk) 23:08, 25 May 2013 (UTC)[reply]

OK, thanks for the information. I'm not too familiar with Wikitables (I never now were to put styles, how many pipe characters I need, etc. Actually I'd prefer to do them in pure HTML if I could . Either way I already changed the tables before, but I suppose a &nbsp; doesn't harm either. --Patrick87 (talk) 23:18, 25 May 2013 (UTC)[reply]

There are several tools available to convert HTML to wiki syntax, see Wikipedia:Tools/Editing tools#From HTML. Thryduulf (talk) 17:06, 26 May 2013 (UTC)[reply]

Instead of two different-color bullets, it ought to be a bullet vs. no bullet. It'd be much easier to make out the difference. —Designate (talk) 14:33, 26 May 2013 (UTC)[reply]

Per Wikipedia:Redirects for discussion/Log/2013 May 18#ƀ, the redirect at ƀ (note not the uppercase Ƀ) needs deleting. Neither I nor the closing user (JohnCD) can actually manage to do it though as every time the autocapitalisation kicks in and asks you whether you want to delete the uppercase page, even when manually specifying ƀ in the URL. I don't know whether there is some way to directly access the lowercase version via the bot API or something, but if not I guess then we'll need to ask a developer to directly tweak the database? Thryduulf (talk) 17:01, 26 May 2013 (UTC)[reply]

There is no redirect; what you see is MediaWiki auto-coverting the lowercase letter to uppercase. Notice there is no "Redirected from..." mesage when you go to http://en.wikipedia.org/wiki/ƀ, and it is also not listed on Special:DoubleRedirects. Pretty much all of these articles (see navbox) exhibit this behaviour. — Edokter (talk) — 17:21, 26 May 2013 (UTC)[reply]

From this page, for the lower-case ƀ, clicking any of "Edit" or "View history" or "Delete" gets you to the corresponding page for upper-case Ƀ. Even odder, from the previous version of ƀ, "View history" and "Delete" still get the upper-case version, but "Edit" actually gets the lowercase one. JohnCD (talk) 17:32, 26 May 2013 (UTC)[reply]

http://en.wikipedia.org/w/index.php?title=%C6%80&curid=7046002&action=history is a url to its page history. If a query url contains a revision id then the title is ignored so http://en.wikipedia.org/w/index.php?title=anything&curid=7046002&action=history gives the same result. It appears that MediaWiki currently, but not always in the past, treats ƀ as a lower case Ƀ when the first character in a pagename is automatically capitalized. It's also conceivable that something depends on the server like the situation ɱ (LATIN SMALL LETTER M WITH HOOK) versus Ɱ (LATIN CAPITAL LETTER M WITH HOOK) at Wikipedia:Village pump (technical)/Archive 105#Link in history says user does not exist. PrimeHunter (talk) 17:53, 26 May 2013 (UTC)[reply]

What happens if you try this delete link (admins only)? I can't try it myself, not being an admin. – PartTimeGnome (talk | contribs) 20:57, 26 May 2013 (UTC)[reply]

It originally sends you to the deletion dialog for ƀ, then as soon as you click "delete this page", MediaWiki shows you the deletion dialog for Ƀ. No deletion actually occurs. Titoxd^{(?!? - cool stuff)} 21:03, 26 May 2013 (UTC)[reply]

 Done. I looked up the page id with ?action=info, and then used that in a request through Special:ApiSandbox. Legoktm (talk) 21:12, 26 May 2013 (UTC)[reply]