Jump to content

Wikipedia:Village pump (technical)/Archive 104

Add links
From Wikipedia, the free encyclopedia
Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217

My Preference Gadgets: an idle tab remains

I have switched on My preferences | Gadgets | Appearances, Add a "Purge" tab to the top of the page, which purges the page's cache when followed. It produced an extra tab with drop down menu "Purge" (all right). A day later I unmarked that option. Purged. Now the Purge button has disappeared OK, but the tab is still there with no menu item (it does not open). Any ideas? -DePiep (talk) 20:17, 14 October 2012 (UTC)

Try a skin reset: change to another skin and save, then change back to your desired skin and save. Let us know if that works. ---— Gadget850 (Ed) talk 04:09, 15 October 2012 (UTC)
Did so (twice): from Vectro to Classic and back, from Vector to Cologne and back. In between aso did clean the cache. No effect: it is still there (a downward arrow). Two other such tabs are present and fine (page etc.). I'm using FF on WinXP. -DePiep (talk) 11:33, 15 October 2012 (UTC)
FWIW: the idle tab is not present on pages with permanent protection. -DePiep (talk) 10:30, 16 October 2012 (UTC)

Script for watching pages both here and on Commons?

Is there any way to modify my .js or .css so that when I watch a page in the File: or File talk: namespace here on Wikipedia, it also watches it on Commons or vice versa? --Philosopher Let us reason together. 15:06, 15 October 2012 (UTC)

I think User:Yair rand/interwikiwatchlist.js will do the job. Bgwhite (talk) 06:46, 16 October 2012 (UTC)
No, that's not quite it. Basically, when I watch the "same file" on both en.wikipedia and commons. So that if I want to watch File:Iowa.jpg, it will add the en.wikipeida file with that name to my en.wikipedia watchlist and the commons file with that name to my commons watchlist. --Philosopher Let us reason together. 07:30, 16 October 2012 (UTC)

Article title

A few days ago, all article titles (at the top of the page) disappeared from Wikipedia - at least on the Monobook I am using and the server. Is there a way to get them back? I see that they're still there on other servers. All Hallow's Wraith (talk) 07:53, 16 October 2012 (UTC)

It works for me. What do you mean by "the server"? Are you examining the bottom of the html source to see which of Wikimedia's servers are serving a page? It usually varies between each page view. Or are you just guessing that you hit different Wikimedia servers when the page looks different to you? Or are you referring to your own normal computer compared to other computers? Try to clear your entire cache. What is your browser? Does it have extensions you can try to disable? PrimeHunter (talk) 11:56, 16 October 2012 (UTC)
By server I mean Internet explorer vs. Mozilla firefox. Explorer is what I use. All Hallow's Wraith (talk) 22:04, 16 October 2012 (UTC)
It's called a browser. Monobook and Internet Explorer 9.0 works for me. I haven't seen other reports of this so it's probably an issue at your end. Did you try to clear your entire cache in Internet Explorer? Did you examine extensions? See [1]. PrimeHunter (talk) 22:57, 16 October 2012 (UTC)

Math parsing error

Hi,

I get a math parsing error on the page Dense subgraph, but only when viewing the article directly, not when using 'preview' after editing it. Any idea what is going wrong here? 62.245.183.130 (talk) 13:49, 16 October 2012 (UTC)

Fixed by saving again without changing anything. Maybe some caching issue? Thanks anyway. 62.245.183.130 (talk) 13:51, 16 October 2012 (UTC)

Notability question

I was browsing a wiki page (North Highlands, California) and noticed it mentioned a Mr Pidcock as being a notable person from there. I grew up in that town and have never heard of him. On the talk page another resident mentioned they also had never heard of him. A web search comes up with nothing on Mr. Pidcock.

I'm wondering if there is a template to mark that reference as being of questionable notability. I found {{notable}}, but it is designed for a list, not a single inline reference.

Any ideas? Donpayette (talk) 14:38, 16 October 2012 (UTC)

Try adding {{rs}}. It adds an inline note like this[Unreliable source?] Ryan Vesey 14:53, 16 October 2012 (UTC)
Thanks, that's close, but this one is un-sourced. So you gave me the idea of using {{citation needed}}, which is a bit closer. But I would still kinda like a {{notnotable}}. I'll keep looking. Donpayette (talk) 15:48, 16 October 2012 (UTC)
I removed the material. If someone is listed as a notable citizen of a town or member of the group, and they don't have an article, they should almost always be removed. Wikipedia assumes that if you haven't received the notability threshold for an article you should not be mentioned as a notable member. There's obvious exceptions like listing the mayor of a town or superintendent of a school board etc. The material was probably introduced by someone as a joke. Ryan Vesey 16:10, 16 October 2012 (UTC)
FWIW, it was added by an anonymous user with this edit. Ryan Vesey 16:14, 16 October 2012 (UTC)
Yes agreed, just remove rubbish like that, don't mess about with templates. We get this all the time, people writing themselves or their friends into the encyclopedia. But to answer your original question {{dubious}} is more appropriate than {{cn}} as it implies the tagger does not believe the information whereas {{cn}} is an agf request for sourcing. SpinningSpark 16:21, 16 October 2012 (UTC)
There is also {{disputed-inline}}. SpinningSpark 16:24, 16 October 2012 (UTC)
Thanks all. I learns something new every time I ask a question. Thanks, again. Donpayette (talk) 18:17, 16 October 2012 (UTC)
{{notability-inline}} --Redrose64 (talk) 18:38, 16 October 2012 (UTC)

When clicking on a link to go to the section in my watchlist for VPT, I am being delivered to the wrong section. What's going on? It isn't doing nothing, like what happens when there is a template in the section heading, I end up a couple sections above where I want to be. Ryan Vesey 19:01, 16 October 2012 (UTC)

Such things are browser dependent. The watchlist and the TOC has the same url. Your browser tries to place you at the anchor given in the url but may miscalculate the size of elements which change during page load, for example collapsed boxes. Some browsers may reposition you after the initial guess. If you click in the TOC then the page is already fully loaded so the browser knows exactly where to place you. Watchlists, page histories, user contribtuions, and anyhting else coming from another page has the same challenge. You can usually be repositioned accurately by clicking in the browser address bar and pressing Enter (I have to do that twice in Firefox because it reloads the first time). I don't know exactly why but in Firefox I currently get positioned correctly up to http://wiki.riteme.site/wiki/Wikipedia:Village_pump_%28technical%29#Top_10.2C000_articles, but below correct for the following sections starting with http://wiki.riteme.site/wiki/Wikipedia:Village_pump_%28technical%29#Vector_script_stops_responding_in_Firefox_15-16. To test this you probably have to open the links in a new tab. Otherwise it would be like clicking in the TOC. PrimeHunter (talk) 00:46, 17 October 2012 (UTC)

Other users claim non-display of image

Can anybody please assist with the alleged problem at Template talk:Country data South Korea#Display (Template talk:FlagIOCathlete#Edit request on 16 October 2012 may be related). I don't see any problems, but apparently others do. --Redrose64 (talk) 20:52, 16 October 2012 (UTC)

VisualEditor/Parsoid fortnightly update - 2012-10-15 (MW 1.21wmf2)

Hey all,

Below is a copy of the regular (every fortnight) update on the VisualEditor project and its cousin the Parsoid so that you all know what is happening (and make sure you have as much opportunity to tell us when we're wrong, as well as help guide the priorities for development and improvement).

VisualEditor

The VisualEditor was updated as part of the wider MediaWiki 1.21wmf2 branch deployment on Monday 15 October.

In two weeks since 1.21wmf2, the team have again spent most of their time working on re-designing how the code integrates together, providing clean interfaces between them so new developers can re-use and extend VisualEditor to support new 'node types' like categories or tables when we work on these later.

Beyond the API work, we have entirely re-written the selection system (33058, 34095, 37814, 37833, 37834, 38000, 39465, and 39965), part of which included us adding IME support back in to the VisualEditor (33076). We also fixed some bugs including selections not being restored correctly on undo/redo (40538), backspace not always deleting the right character (40416), pre-annotations (40677), and fixing a JavaScript error when using Internet Explorer 10 (37851).

A complete list of individual code commits is available in the 1.21/wmf2 changelog, and all Bugzilla bugs closed in this period on Bugzilla's list.

Parsoid

JavaScript implementation:

  • Many improvements to template round-tripping and DOM source range calculations
  • Added many new parser tests
  • Test runner now runs various round-trip test modes based on parser tests
  • Wikitext to wikitext round-trip tests up to 618 from 608. Total 1343 tests passing
  • Set up continuous integration with Jenkins, runs parser tests on separate virtual machine on each commit
  • Created round-trip test infrastructure on full dumps with classification into syntactic-only / semantic diffs, adding distributed client-server mode to speed it up
  • Big articles like Barack Obama are now close to round-tripping without semantic differences

C++ implementation:

  • Generalized pipeline interfaces
  • Implemented HTML5 tree builder with XML DOM backend
  • Designed and implemented token stream transformer APIs with usability improvements on the JavaScript version
  • Added Scope class (~preprocessor frame) and simplified expansion logic vs. JavaScript implementation
  • Parses simple wikitext all the way to XML DOM

The full list of Parsoid commits is available in Gerrit.

Hope this is helpful! As always, feedback gratefully received, either here or on the centralised feedback page.

Jdforrester (WMF) (talk) 21:00, 16 October 2012 (UTC)

Upcoming changes to the edit window (please read)

Proposal

Hey all :).

the current editing interface

So, the new Micro Design Improvements team has been looking at various things to tweak to try and make Wikipedia's interface less clogged with stuff. One of these is improvements to the "edit" window, which I want to give you all a bunch of advance notice of - obviously, everyone uses it, and so I don't want to just drop it on enwiki without letting anyone know :). A couple of important disclaimers - first, if you're on anything other than vector, you won't get the collapsible lists for categories/templates. If you are on vector, but don't have the enhanced editing toolbar switched on, you'll see some changes, but one of them (removing the edit tools at the bottom) won't take effect. You'll only get the full package with both vector and the enhanced toolbar. With that in mind, here's a TL;DR bit on the changes that are part of this:

A mockup of the changes we are making (note; "watchlist this page" will still actually appear, the mockup is just slightly off).
  1. Moving what is currently the first line of text under the edit window "content that violates any copyrights..." (MediaWiki:wikimedia-copyrightwarning) above it.
    Rationale: This line is primarily composed of guidance as to what sort of content is appropriate for Wikipedia. (Several projects moved such guidance here from MediaWiki:Edittools when this message was introduced after the license switch.) Having it below the edit window almost ensures that people will only read it after they have tried to make changes - it is of little use. On the other hand, if we move it above the edit window, we have an opportunity to educate people about what is or is not appropriate before they start writing.
  2. Removing the reference to a help page.
    Rationale: At first glance, this might appear counterintuitive. The logic is that the advanced editing toolbar (which all new users are presented with by default) already includes a link to a "cheat sheet" of markup. The help page linked in the text, on the English Wikipedia, is a similar cheat sheet, creating duplication and taking up unnecessary space.
  3. Removing half of the "if you do not want your writing..." line (MediaWiki:wikimedia-editpage-tos-summary) – that bit concerned with the Terms of Use – and moving the other half above the edit window.
    Rationale: Again, the message (even the legal text) has been customised by the English Wikipedia and several projects added here information/warnings previous shown in the edittools; the advice will be of most use if it is shown to a user before they have contributed. At the moment, this text is not only after the edit window but also after the "save page" button – people may not even see it before submitting their changes. The text relating to the Terms of Use is a duplication of the existing disclaimer, and one that Legal concludes serves no purpose.
  4. Moving the "by clicking Save Page..." text to below the edit summary window.
    Rationale: The action is related most closely to "save page". Under the current workflow, someone is presented with it, then presented with unrelated options (edit summaries), and only then given the "save page" button. Moving it more closely ties the advice to the action it relates to.
  5. Putting the lists of templates and hidden categories under small drop-down menus.
    Rationale: both elements have some use cases (for example, identifying subtle template vandalism), so we certainly don't want to remove them, but they're not much use for most editors: they just take up space and present users with a lot of text and links that serve (to them) no clear purpose. A nice middle ground is to stick them under dropdown menus: if they're wanted, they can easily be found – if not, they don't take up as much space.
  6. Removing the "edit tools" toolbar after "save page" (MediaWiki:Edittools).
    Rationale: A lot of the functionality here is duplicated in the enhanced editing toolbar, which has been enabled by default for new accounts for quite a while for a long time. In addition, its current placement makes it of little use: people are only presented with it after they've made their changes. This change won't appear if you don't have the enhanced toolbar on.

The screenshots to the right may provide a more useful comparison of "before" and "after"; again, most of you won't notice a change :). We also have it deployed on a prototype server here, which you may want to create an account on so you can see how it works in practice. If you've got any feedback, I'd love to hear it, be it positive or negative, and if you've got any more ideas for improvements we could make you can drop them here, on the Micro Design Improvements talkpage, or on my talkpage. We're probably not going to be deploying until the week of the 17th of September, to allow both community discussion and feedback and some time for browser testing, which is a good time to note (nice segue, Oliver!) that if you find any issues you should let me know, and I'll do my best to get them fixed. Thanks! Okeyes (WMF) (talk) 20:23, 5 September 2012 (UTC)

Comments

Looks good. No major issues that I can see. IRWolfie- (talk) 20:45, 5 September 2012 (UTC)
  • Thanks! :). A quick note that I want to let as many people know about this as possible - if people can think of venues I should post notifications at that I haven't, let me know. Okeyes (WMF) (talk) 20:53, 5 September 2012 (UTC)
Looks good to me too. Bring on the Naysayers and doom and gloomers! :-) Kumioko (talk) 20:54, 5 September 2012 (UTC)
Discussion of impact on other wikis Okeyes (WMF) (talk) 20:06, 20 September 2012 (UTC)
  • Is this only for English wikipedia, or why is this linked to a mediawiki page? Choyoołʼįįhí:Seb az86556 > haneʼ 20:57, 5 September 2012 (UTC)
    At the moment, this is only going to be deployed on enwiki; we don't want to fling the change out everywhere because it's a pretty big thing to be altering for every project. We'll hopefully ramp it out over time - first to other projects that request it, then to a wider userbase, then stick it as the default, so on, so forth. The location of the team page (MediaWiki.org) is because the team's projects overall are hopefully going to be for a much wider range of our wikis, and so it's not that appropriate to host it on an individual "in use" wiki. I appreciate this makes it slightly harded to follow the conversations - I'm looking for ways around this :S. Okeyes (WMF) (talk) 21:01, 5 September 2012 (UTC)
(OK. Once you get to other wikipedias, please keep in mind removing the edit-toolbar is in many cases a bad idea. Going through the list of all possible letters just to find the one you need each and every time is tedious, and typing Cherokee and Inuit is impossible without it. Choyoołʼįįhí:Seb az86556 > haneʼ 21:06, 5 September 2012 (UTC))
Heh; noted :). Does the enhanced toolbar not include that functionality? I can imagine it wouldn't for the particularly obscure characters (or those in non-westernised languages) but, generally-speaking, what is the "special characters" tab missing? Okeyes (WMF) (talk) 21:08, 5 September 2012 (UTC)
I'd note that Siebrand's team is working on mw:Universal Language Selector, which may help somewhat. Okeyes (WMF) (talk) 21:17, 5 September 2012 (UTC)
What you'd call obscure :P American letters, for example >> Ꭰ Ꭱ Ꭲ Ꭳ Ꭴ Ꭵ Ꭶ Ꭷ Ꭸ Ꭹ Ꭺ Ꭻ Ꭼ Ꭽ Ꭾ Ꭿ Ꮀ Ꮁ Ꮂ Ꮃ Ꮄ Ꮅ Ꮆ Ꮇ Ꮈ Ꮉ Ꮊ Ꮋ Ꮌ Ꮍ Ꮎ Ꮏ Ꮐ Ꮑ Ꮒ Ꮓ Ꮔ Ꮕ Ꮖ Ꮗ Ꮘ Ꮙ Ꮚ Ꮛ Ꮝ Ꮜ Ꮞ Ꮟ Ꮠ Ꮡ Ꮢ Ꮣ Ꮤ ᐊ ᐃ ᐅ ᐋ ᐄ ᐆ ᐸ ᐱ ᐳ ᐹ ᐲ ᐴ ᑉ ᑕ ᑎ ᑐ ᑖ ᑏ ᑑ ᑦ ᑲ ᑭ ᑯ ᑳ ᑮ ᑰ ᒃ ᒐ ᒋ ᒍ ᒑ ᒌ ᒎ ᒡ ᒪ ᒥ ᒧ ᒫ ᒦ ... etc. (can you even see those?) Instead of flooding the special characters-thing, just keep the edit toolbar. Choyoołʼįįhí:Seb az86556 > haneʼ 21:18, 5 September 2012 (UTC)
I can, yep :). Would the language selector not help? Okeyes (WMF) (talk) 21:22, 5 September 2012 (UTC)
I doubt it. It just wouldn't be worth it to this for the <200 people who'd actually use it. Just don't switch it off all of the sudden, that's all I was worried about. Choyoołʼįįhí:Seb az86556 > haneʼ 21:26, 5 September 2012 (UTC)
We'll try not to :). Like I said, we're not planning on scaling it out immediately - and when we do scale it out more widely I'm sure we can try to work together a CSS hack or opt-out for wikis that are going to struggle. Okeyes (WMF) (talk) 21:30, 5 September 2012 (UTC)
What are you using to generate the dropdown menus and what does it look like rendered in FF, Chrome, IE, etc? Protonk (talk) 21:12, 5 September 2012 (UTC)
This is a question for Rob Moen; I'll get him in here :). It renders very nicely in Firefox - I invite any and all to test the prototype and see!
Rob reports he wrote a jQuery module for it; it's at /trunk/extensions/Vector/modules/jquery.footerCollapsibleList.js :). Okeyes (WMF) (talk) 00:29, 6 September 2012 (UTC)
Do we really need to create yet one more script for collapsing things? Why not to use (improving if needed) the jQuery.makeCollapsible which is already available on MW? Helder 21:30, 6 September 2012 (UTC)
Aye, there are too many already. It's kind of scary, and makes getting fixes for any one only that much harder. -— Isarra ༆ 08:07, 7 September 2012 (UTC)
Accessibility concerns (now patched) and suggestions for future expansion. Okeyes (WMF) (talk) 20:06, 20 September 2012 (UTC)

Dark Grey Text on light grey backgrounds or fills is considered accessible and easy to read. If we go any darker the color will compete with the left navigation bar and the text will be hard to read. So that was a bit of a constraint. See: http://uxmovement.com/content/when-to-use-white-text-on-a-dark-background/ Also here is the color pallete that is being used by the foundation: http://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Color_Usage. We are are looking at testing this a little bit.Vibhabamba (talk) 00:13, 6 September 2012 (UTC)

The darkness already competes with the rest of the screen in the vector skin. -— Isarra ༆ 17:23, 6 September 2012 (UTC)
Wider discussion about future changes Okeyes (WMF) (talk) 20:07, 20 September 2012 (UTC)

Some thoughts:

  • Overall this is much simpler and a nice improvement in terms of usability. Yay!
  • 'Cancel |' between two buttons looks weird.
  • That grey is annoyingly dark.
  • While I like the collapsing of the templates and hidden categories lists (and indeed have been using a version for awhile already, though it doesn't work nearly as well as I'd like either), I have some nitpicks with the particular implementation here.
    • The collapsing/uncollapsing animation is probably slower than it needs to be, but why does it need to be animated at all? This is technical stuff, which if we want to see it at all, probably want to see it immediately.
    • Remembering the collapsed/uncollapsed state with a cookie may not be the best approach, given how very many templates a lot of things have and that even if on some pages or in some cases the list merits uncollapsing, on most it really doesn't and just gets in the way. As such I would put forward that by default they should always start collapsed, regardless of how it was left on the last one. A UPO to have them start out open or maybe disable the collapsing entirely would be useful for some people, though.
    • There are times when it would be useful to have the list headers say how many things there are, so instead of 'View templates in this Page', it might say 'View 59 templates used on this page' or some such.
    • When there are only one or two templates on a page (or any random number <5), is it really worth collapsing them by default?
  • Geese.
  • I'm not sure moving the warning line to the top will make it less likely to be ignored; since the buttons are at the bottom it seems like people may pay more attention there, especially when there is less clutter there.

-— Isarra ༆ 21:33, 5 September 2012 (UTC)

I really like the remember of collapsed state. And given past experience with the sidebar and collapsibility, I think most other users would prefer remembering this as well. —TheDJ (talk • contribs) 21:42, 5 September 2012 (UTC)
I agree about remembering with the sidebar, but that is also effectively the same sidebar on every page; the same cannot be said for specific content. Different pages can have very different templates/hidden categories, and the remembering is not page specific - having uncollapsed the list on someone's talkpage does not mean one wants to see the list of every component template included in a content page's infobox. -— Isarra ༆ 22:59, 5 September 2012 (UTC)
Excellent point :). I'm going to add "remembering with the sidebar" to our to-do list as part of a greater "sticky settings" project for non-context-specific menus. Okeyes (WMF) (talk) 23:18, 5 September 2012 (UTC)
Cookies are really not helpful for me, as my browser clears them regularly. There needs to be an account setting or gadget to make the template info fully visible to troubleshoot template issues before this goes live, or dealing with them will be pain. Troubleshooting templates can often involved checking templates on multiple pages, and constantly unhiding them would be a pain. Monty845 23:26, 5 September 2012 (UTC)
Totally agreed :). So, we've now actually got two ways of remembering a setting; 1, cookies, which have a lot of problems, or 2, "sticky settings". These are basically hidden preferences options. So, for example, we could implement sticky settings here and it would remember it as a 'preference' - not one that appears in "my preferences", but something ever-present that doesn't go away when you clear your cookies. Okeyes (WMF) (talk) 23:57, 5 September 2012 (UTC)
The suggestion with the count on the collapsed header seems wonderful, we should probably implement that in core however. The animation should be removed in my opinion yes. —TheDJ (talk • contribs) 21:42, 5 September 2012 (UTC)
Your suggestion seems to be one more use case for the request to allow disabling interface animations.
I also like the idea of displaying the number of templates in the page when the list is collapsed. Helder 21:30, 6 September 2012 (UTC)
Hi Issara Thanks for your feedback. I helped Oliver out with this feature. Could you explain a bit more why the Cancel is feeling weird? Is it just visual or is it a workflow issue? We wanted to clearly separate the Save + Cancel from the Preview + Show changes. From some data analysis we have seen that quite a few users (both new and advanced) are using the preview feature. Eventually we hope to improve the workflow by moving the Preview to a more contextually appropriate position in the workflow. Also is the grey fill (bottom of the edit field) distracting? The reason we introduced a fill is that it lends finality to the edit workflow. Would be helpful to understand why its annoying. Thanks Vibhabamba (talk) 23:32, 5 September 2012 (UTC)
The cancel button just looks really weird like that, randomly between two buttons and with a sinlge | for no apparent reason. Don't know if it would affect workflow aside from maybe causing people to accidentally hit that instead of the preview button since that's where the preview button normally is, but on the other hand, what is contextually inappropriate about where the preview button is normally?
And when there is that much of it, the 'fill' is just too dark for the page. The colour itself ain't inherently bad, but that much of it results in a domination of the space of the page when the object in question should be no more dominating than the edit box itself. Look at a screenshot and zoom out; it becomes more immediately apparent when the details aren't present. -— Isarra ༆ 08:07, 7 September 2012 (UTC)
I agree that the Cancel Button looks a little strange. From instrumenting this page we have learned that both new and advanced users extensively use the Preview Button. Currently it comes after the Save action and falls below the page fold. If we create a clean grouping for save and cancel, eventually we can move Preview closer to the edit field, so a user can access preview without wandering away from the edit window. Do you have feedback/ suggestions around this..? Thanks Vibhabamba (talk) 22:35, 7 September 2012 (UTC)
We also want to upgrade to a simpler keyboard shortcut for it. Can you think of better (one? Vibhabamba (talk))
Suppose we did turn on the side-by-side preview and publishing things, it could look something like this. Nice, simple, and elegant. -— Isarra ༆ 03:40, 9 September 2012 (UTC)
The cancel button should really be just that - an actual button button, probably at the end of the others, since that way it would be (and is currently, for that matter) opposite in position from the edit button, the one from which it is technically the opposite. And I don't see why the buttons should be split up at all - they are all actions that can be taken with the open page, so reasonably they should be together so people can see what all their options are in one place, though that should be closer to the editbox itself, indeed. Something to consider might also be to repeat them at the top of the editbox - such that the page, from top down, might go something like this:
  • (preview or diff)
  • (any relevant editnotices)
  • short copyright etc disclaimer thing if needed
  • save cancel buttons
  • editbox
  • (charinsert edittools)
  • short further disclaimer/notes thing if needed
  • edit summary field and description, all on one line
  • (minor edit and watchlist checkboxes)
  • save preview diff cancel buttons
  • (transclusions list)
  • (hiddencats list)
Where parentheses indicate things that may show up depending on action taken, user preferences, who is editing, and the page in question. Aside from the extra disclaimer at the top (do we really need that anyway?), this is basically what you get with a default MediaWiki install (and even more so when the side-by-side preview and publishing labs features are enabled, which are pretty cool and also something we might want to consider here) when not cluttered up with an overabundance of warnings and disclaimers and 'Please note's. Frankly our main problem here is simply that we have so much stuff everywhere, which is unfortunately a problem with the entire project, manifesting not just in the interface, but in policies, templates, processes, even in the way people communicate. Nevermind everything else; one thing we really need to do is look into getting rid of all that extra clutter that has been added over the years, because nearly all of that is redundant and/or not actually helpful. -— Isarra ༆ 00:46, 9 September 2012 (UTC)
The side-by-side concept is a very nice I would definitely support although some might accidentally click on "Cancel" (because the Preview button was there previously). --intforce (talk) 21:48, 19 September 2012 (UTC)
  • I understand the rationale behind removing the editing help button; however, I'd like to see a study performed to see if the button is being used before doing that. We could do the rest of the changeover and leave that in if we need time. I think it could work to do a 30 or 60 day study and (unless there's a better way to do it) turn that link into a new redirect to the intended page. Then count the visits to the redirect. In addition, removing the editing tools would be a mistake. The enhanced editing toolbar is enabled on my account and there are things that are not duplicated. I use the editing tools toolbar for a few things. Em dashes, nonbreaking spaces, and {{#tag:ref||group="nb"|name=""}}. I would support adding a new dropdown for wiki markup to the toolbar as an alternative. Ryan Vesey 21:43, 5 September 2012 (UTC)
    Expanding on the special characters is probably a good idea :). I disagree on the "if the button is being used" point, though. So, it's possible that some people are clicking it. That doesn't show it's a good thing - it just shows that we're presenting them with the option and they're taking advantage of it. When they click it, they're sent to a page that doesn't include anything that the "help" tab doesn't, doesn't include a few things the "help" tab does, and is in a much longer format (and requires to to go away from the edit window). I do like the idea of maybe turning it into a redirect to the help function in the toolbar, if we can do that and if there's a use case. Okeyes (WMF) (talk) 21:50, 5 September 2012 (UTC)
    I'm really not convinced that removing the help link is a good idea. It strikes me as rationalisation for the sake of it. I think the link should be kept for the time being - the space involved is negligible, really - and some effort should be made to think through what such a link should run to. In this kind of area (and face-to-face training shows this) it is very easy to overestimate the savvy of new users, and I'm concerned that the reasoning given just slides past the actual difficulties. In any case I see this as a serious design point, worthy of a discussion in its own right. Charles Matthews (talk) 12:50, 26 September 2012 (UTC)
    I'd echo Charles' reasoning above. When training, it's often useful to let trainees open the Cheatsheet for continual checking throughout the session. The dropdown for help on the toolbar is compact and is probably the first choice for editors who have some experience, but I'd prefer to have an obvious link to a separate help page for absolute beginners. As a small point, referencing is the single most difficult topic for new editors and the Cheatsheet has links to Cheatsheet for citing a website or publication and Referencing for beginners that are not available from the dropdown help. --RexxS (talk) 15:50, 26 September 2012 (UTC)
    See Wikipedia:Village_pump_(proposals)#Message_on_search_results_page for something that is clicked often, yet not really helping along users. A way to measure this is a good idea, but we need a different metric in that case I think. —TheDJ (talk • contribs) 22:05, 5 September 2012 (UTC)
    It is already possible to customise the WikiEditor's edit toolbar to add the buttons you need. And I think this is a better approach than not providing a way for users who do not use it to be able to remove that content (bug 11130, open since 2007). Helder 21:30, 6 September 2012 (UTC)
  • I do not object, which is surprising. Evanh2008 (talk|contribs) 23:13, 5 September 2012 (UTC)
  • Question about preference gadgets - There are at least a handful which interact with the html you are changing. Have you gone through and tested this will all the gadgets offered in Preferences? Also, how are you changing this just on Vector? Is there a way to override these interface messages just on one skin without changing them on the others? —Cupco 00:28, 6 September 2012 (UTC)
    The changes should only impact on Vector, yep. What preferences are you referring to? Okeyes (WMF) (talk) 00:30, 6 September 2012 (UTC)
    "Add two new dropdown boxes below the edit summary box with some useful default summaries" seems the most likely to be affected. —Cupco 10:43, 6 September 2012 (UTC)
    That, I haven't checked; I will :). But I think we're going to be horribly restrained in the future if we can only act when there's no conflict with any gadget anyone has created and got consensus on. Okeyes (WMF) (talk) 10:55, 6 September 2012 (UTC)
  • Very Good Nice clean layout and well organized. It gives priority to the text that needs it. It also fixes the wall-o-text that confuses less experienced users. Thanks to all involved. Good job. 64.40.54.83 (talk) 03:41, 6 September 2012 (UTC)
  • Support I am in complete agreement. This will look much more professional and easy to read than the current design. Jsayre64 (talk) 23:35, 20 September 2012 (UTC)
  • Not a huge fan, but... I never like the prospect of changes. There's a good chance in 4 months I'll think it was a terrrific idea, so take my opinion with a grain of salt. Go Phightins! (talk) 20:17, 23 September 2012 (UTC)

Everything looks really great except Moving what is currently the first line of text under the edit window "content that violates any copyrights..." (MediaWiki:wikimedia-copyrightwarning) above it.. Disagree with rationale. I believe most people's attention will skip anything above the edit box (especially anything using the same font as the "redirect" messages), since the edit box is extremely large and is the primary focus of the page and of the user's intended action, then after editing, attention will be shifted further down the page to the action buttons. If this notice is to be placed above the edit box, perhaps it should be in a noticeable font, e.g. red (but it should *not* be in a notice box, since I think many people are also trained to skim over those from normal wikipedia articles). --JAC4 (talk) 13:22, 24 September 2012 (UTC)

It is going to be visually distinctive compared to other text - I have to say I think red is likely to induce "agggh! warning!" reactions in newbs. Interestingly the reaction I've got from a lot of editors is the other way around; they completely gloss over stuff below the edit box. Okeyes (WMF) (talk) 15:01, 25 September 2012 (UTC)
  • Comment: I like that the Save / Show preview / Show changes buttons are moved up. With the current design I'm always scrolling down to them which means moving the mouse out of the edit window and then scrolling with the mouse wheel. What I'd really like is for all of the edit controls, the submit buttons, edit summary, etc to be fixed all in one place (preferably at the top of the screen) so they never move while the rest of the page can be scrolled.
Missing is the box with the dashes and other common symbols and wiki markup links currently below the edit window. I rather use that a lot. The symbols that I use most commonly are the –, —, ×, and §. Don't make me hunt through the Special characters toolbar for them. I never use the Signature and timestamp button in the main toolbar (in fact, I don't use any of the options there.)
Because this is an edit page, the normal Wiki advert at the top of the page should be disabled (right now it's Participate in the world's largest photo competition and help improve Wikipedia! I'm editing, I don't need to see that and even with fast internet it slows page load; I'm not going to risk losing my work to go look at the advert. (I usually ignore it anyway even when I'm not editing). Yeah, I know this is probably outside the scope of this proposal.
—Trappist the monk (talk) 16:19, 25 September 2012 (UTC)
It's strange that you've lost the symbols etc. - I assume that you mean these. For me, they've moved to a more obvious position - directly below the edit box, and just above the edit summary. Try a WP:BYPASS; if not, which skin are you using? For me, it's present in both MonoBook and Vector. --Redrose64 (talk) 17:00, 25 September 2012 (UTC)
Yes, Edittools. Google Chrome 22.0.1229.79 m. Default skin. No change when I WP:BYPASS. As the page is loading I can see the character sets for a brief moment and then they're gone. I can also see the Edittools when I view the page source. My screen looks very much like the mockup image which also is missing the Edittools.
—Trappist the monk (talk) 18:42, 25 September 2012 (UTC)
Here's an idea. It's not been tried before for this specific feature (AFAIK) but something similar has worked for other problems connected to visibility of other features. Go to Preferences → Gadgets, and under the "Editing" heading, locate "(D) CharInsert: add a toolbar under the edit window for quickly inserting wiki markup and special characters (troubles?)", which should be switched on but might be off. If it's already switched on, switch it off and save. Then, whether or not it was previously switched on, switch it on and save. This should persuade the settings to update themselves. --Redrose64 (talk) 13:36, 26 September 2012 (UTC)
No change. I know that unchecking Charinsert made the toolbar go away on "this" editing page – I checked that before I went to the new editor. Rechecked the check box and now I have the tool bar here but not there. Bypassed the cache when I reloaded just to be sure. Since that toolbar is visible and usable here, and presumably is the same toolbar that is used there, then the problem can't be me but must be in the new editor's page right?
Also, the minor edit and watch check boxes aren't present. Does that offer a clue?
—Trappist the monk (talk) 03:23, 27 September 2012 (UTC)
Just for Curiosity's sake, I looked into the source for this editor and the new editor. I haven't made a careful inspection to compare the code of one to the other but I did notice this in what I suspect is the first line of the Charinsert part:
&lt;input type="hidden" value="53c8a195abb99a05ed87d1b7e2590baa+\" name="wpEditToken" /&gt; (from this editor)
&lt;input type="hidden" value="+\" name="wpEditToken" /&gt; (from the new editor)
—Trappist the monk (talk) 03:33, 27 September 2012 (UTC)
That wpEditToken of "+\" indicates that you're not logged in there, which also explains why the minor edit and watch checkboxes are missing there. Anomie⚔ 10:47, 27 September 2012 (UTC)
Ok, thanks. But shouldn't a non-logged-in editor still be able to mark an edit as minor? If not, then why is that function reserved for logged in editors?
–Trappist the monk (talk) 13:22, 27 September 2012 (UTC)
According to Help:Minor edit, "Users who are not logged in to Wikipedia are not permitted to mark changes as minor because of the potential for vandalism." Anomie⚔ 14:29, 27 September 2012 (UTC)
So the real reason that I can't see the Edittools is because I'm not logged in? In the source for this editor there are three instances of the term Charinsert.
&lt;link rel="stylesheet" href="//bits.wikimedia.org/wiki.riteme.site/load.php? ... modules=ext.gadget.ReferenceTooltips%2Ccharinsert%2C ...
&lt;script&gt;if(window.mw){mw.loader.implement("user.options",function() ...,"gadget-charinsert":1, ... // settings from my preferences
&lt;script&gt;if(window.mw){mw.loader.load([...,"ext.gadget.charinsert", ...
In the source for the new editor, there isn't an apparently equivalent &lt;link rel="stylesheet" .... The mw.loader.implement() function lists a lot of "options" that are off but doesn't include Charinsert and mw.loader.load() function doesn't load any gadgets.
I think this explains why I don't see the Edittools. Am I right?
—Trappist the monk (talk) 16:11, 27 September 2012 (UTC)
Nope, as the new version has prematurely gone live, and I'm logged in, and I can see the Edittools in the page source, the new editor is broken. Not impressed.
—Trappist the monk (talk) 00:24, 28 September 2012 (UTC)
We're fixing this now. Okeyes (WMF) (talk) 00:27, 28 September 2012 (UTC)

I have the same issues as Trappist (Vector skin, Firefox 15.0.1, CharInsert checked on my gadget preferences). I find Edittools useful because it's one-stop shopping for HTML tags and Unicode (unlike the top toolbars), and I haven't yet memorized everything I need to know :-). Thanks and all the best, Miniapolis (talk) 19:11, 28 September 2012 (UTC)

Try this: go to Preferences → Editing and switch off "Enable enhanced editing toolbar". That seems to have helped other users. --Redrose64 (talk) 19:55, 28 September 2012 (UTC)
Thanks very much; just hope I can someday have both the enhanced editing toolbar and Edittools (again). For now, this will do. All the best, Miniapolis (talk) 22:18, 28 September 2012 (UTC)
  • Support Latecomer here, so won't offer suggestions of changes. This looks to be an overall improvement, with a fairly healthy discussion beforehand. Nice work! -- Trevj (talk) 09:35, 27 September 2012 (UTC)

I like it. I think it is better than the old one and I think some new users will find it easy to use. --Jesant13 (talk) 22:32, 28 September 2012 (UTC)

Save/Preview buttons should be higher

Currently, the position of the Save/Preview buttons, as below the rule-spam blurb, "By clicking the Save Page..." is extremely irritating for the amount of up/down scrolling needed to reach them. Instead, they should be just 2 lines below the edit-summary field, with blurb at end:

Edit summary (Briefly describe the changes you have made)
  [___________________________________________________________________]
  Preview of edit summary: (/* Upcoming changes to the edit window)
  [] minor edit    [Save page]   [Show preview]   [Show changes]    By clicking the "Save Page" button, you agree to the Terms of Use, and you irrevocably agree to release your contribution under the CC-BY-SA 3.0 License and the GFDL. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.

In general, when designing a computer interface, avoid putting common menu items "78 miles" away from the input/edit areas. To avoid accidental clicks, then 2 lines away is sufficient. Currently, the Save/Preview buttons are about 13 lines(!) away from the edit-area, which is like "79 miles" travel in the computer-mouse world. In fact, I had to scroll the screen several times just to view those buttons while writing this text. I understand that rule-spam is needed, at first, to explain the rules to people who read everything on a screen before clicking any buttons, but for the rest of the world, all those rule-spam blurbs are, well, spam cluttering the screen. Perhaps there could be a button: [Hide instructions]. Anyway, thanks for discussing the issues, even if the screen cannot be improved very much. People have talked about having custom edit-windows which would be better for veteran editors who get dizzy from all the unnecessary up/down scrolling to get the "Show changes" button. -Wikid77 (talk) 03:39, 6 September 2012 (UTC)

New editors need to be shown those warnings. Established editors can make them disappear, using the code at Wikipedia:Tip of the day/November 22, 2008 -- John of Reading (talk) 07:25, 6 September 2012 (UTC)
  • Suppressed "clicking-Save" blurb by Special:MyPage/common.css: Thank you, I edited Special:MyPage/common.css (for my username) and added those "#editpage-copywarn1 { display: none; }" and copywarn2/copywarn3 lines, and it suppressed the entire "By-clicking-Save" blurb, so the "[Show preview]" button is only 4 lines (not 13) below the edit-window. Best improvement to Wikipedia in 4 years! (after the 2008 recursive descent parser for templates). -Wikid77 (talk) 22:50, 7 September 2012 (UTC) --- --- --- --- ---
We can't actually put the disclaimer under the "save page" button; it's not a disclaimer :). That text is the formal release that allows us to use the content you're posting, and allows everyone else to use it, too - and so it has to go above the "save page" button (we had looked into simplifying it and legal said no). Having it below the save page buttons complicates whether or not it's actually been accepted if someone's hit save: they may not have (or could argue) that they didn't see it. I would strongly recommend against using a CSS hack to remove this, for those reasons. I'll give Legal a poke and see if they have any additional clarification or comment they can add here :). Okeyes (WMF) (talk) 10:31, 6 September 2012 (UTC)
Note no one is talking about any sort of site-wide CSS hack to hide it, or even a gadget. Just individual users, presumably knowing what they're doing, editing their Special:MyPage/common.css. See Wikipedia:Village pump (proposals)/Archive 69#Reducing boilerplate below edit box for a representative past discussion. Anomie⚔ 17:13, 6 September 2012 (UTC)

Any chance of moving the linked part of the "Edit summary" text, immediately above the Edit summary box, away from the beginning of the line? - I'm forever accidentally clicking the link when trying to enter an edit summary. - Arjayay (talk) 11:30, 6 September 2012 (UTC)

That's something we hope to look into in a second round of improvements :). One idea that people have suggested is trying to include that text in the edit summary box itself. So, the box would have grey text of "explain what changes you have made" in it that vanish as soon as you click it/start typing text in/whatever. Random idea, not fully thought-out yet; opinion? :). Okeyes (WMF) (talk) 11:47, 6 September 2012 (UTC)

I really dislike changes 1 and 6. Putting a disclaimer above the edit window strikes me as being more clutter rather than less. Just put it under the license line, like it was before. As for change 6, I much prefer the "edit toolbar" to the advanced toolbar for many functions. The advanced toolbar is great for citations, but when I need wikitext, I hate it because it requires a ton of very careful scrolling just to get anywhere, whereas the edit toolbar just requires selecting the proper dropdown menu and then no scrolling. It's much, much easier to use. Sven Manguard Wha? 02:48, 7 September 2012 (UTC)

I think I agree, if what you're saying is you like mw:Extension:CharInsert and don't want to see it removed. Hereabouts a lot of folk probably won't have much use for it, but some certainly do, and it is an effective interface for what it does. Frankly I'd say the approach Commons took to that is a good one - if folks want it, they can enable it with a gadget or some such. Otherwise there is no need to clutter things up. -— Isarra ༆ 08:07, 7 September 2012 (UTC)

Having such a huge gap between the editing box, the edit summary and the save / preview / show changes is really annoying. I'm used to click on "minor changes" and save by barely moving the mouse. No I have to find the buttons well below. Perhaps you could put both the "By clicking the "Save Page" button, you agree..." and "Please note: When you click Save page..." above the editing box. --NaBUru38 (talk) 19:40, 12 September 2012 (UTC)

This, we are fixing :). Okeyes (WMF) (talk) 00:32, 13 September 2012 (UTC)
Can I suggest that the "Cancel" button is moved further away from the "Save changes" button. On the proposed layout it is just too easy to accidentally hit the wrong button and, if you have made a major edit, the whole thing is lost. If the "Show preview" etc buttons are placed next to the "Save changes" buttons, and the "Cancel" button is placed at the end, this is much less likely to happen. Skinsmoke (talk) 06:10, 21 September 2012 (UTC)
Yeah, my apologies; the mockup is slightly outdated. Those changes won't come into effect, as seen on the prototype :). Okeyes (WMF) (talk) 07:23, 21 September 2012 (UTC)

Stupid question about other projects

Why exactly is this only for one skin on one wiki? Making technical changes like this, if they do not scale in the first place, seems like they would only confuse people further when moving between languages and projects, and the inherent complexity between the lot of them is already problematic.

And the rest just seems like it could be done by changing the relevant interface pages on-wiki, and maybe adding another for the top if need be? With the text itself under the editbox, removing as much as possible is always a good thing, but just moving it around likely won't help much. And putting some of it at the top won't help here anyway when some pages around can have up to three (or possibly even more) editnotice boxes there already, though on other projects which do not use editnotices, that could indeed be an improvement.

The template and hidden category collapsing, on the other hand, is not something enwp actually needs that much. It doesn't hurt, but in particular Commons comes to mind as one that really does need it - this sort of thing is entirely the norm, and it's not even due to badly-made or overly complicated templates, but instead just that everything needs to be templates in order to translate. The system works surprisingly well, but it also makes a bit of a mess of the transclusion lists, as you can see. The rest of text under their editbox is actually quite clean, however. Perhaps an example we might want to follow here? -— Isarra ༆ 17:23, 6 September 2012 (UTC)

It's for one skin on one wiki because we don't want to rock the boat at the moment :). To rephrase what you're asking; "why are you not applying changes that seem logical given the enwiki setup to a vast number of other projects doing their own thing?" If this is uncontroversial and people are interested in seeing it expanded, we can look into doing that. But deploying everywhere without letting the vast majority of people who are affected know is very much How We Used To Do Things and also How We Should Not Do Things. I'd like to see my team acting more responsibly than might be expected when it comes to keeping people in the loop, but this means a more gradual rollout. Always a tradeoff. Okeyes (WMF) (talk) 19:04, 6 September 2012 (UTC)
Okay, so there may be cause to wait to apply relevant changes to core, but these are still general interface changes on this wiki and the framework already exists for making such changes directly across all skins on the wiki end; any admin could do that following an RfC or whatever garnering sufficient community support. Why reinvent the wheel to tack them on top of the existing framework as a javascript override for just one skin when we could instead polish the wheel we have, change the actual text, and improve the general interface? Not only does the proposed approach take more work to implement and maintain (and time to load), it would also make it that much harder for folks to change anything in the future, especially since then changes will then be needed in two places - one in the js for this, and one in the interface messages for the other skins - assuming local admins will even have access to both. -— Isarra ༆ 08:07, 7 September 2012 (UTC)
If you can get widespread support to have these changes applied to every skin, I'm happy to polish the wheel. Until then, it has to be a gradual rollout. What I'm thinking is that as soon as we iron the bugs out, we have an RfC on "turn this on for everyone?" and see how it plays. Okeyes (WMF) (talk) 16:27, 7 September 2012 (UTC)
So why does cross-skin require a consensus, but one skin not? And how is a rollout of everything at once to one skin at a time better than a cross-skin rollout of one change at a time, with discussion of each individually? I only count four distinct changes here - refactoring the text, changing the colours, making the transclusion and category lists collapsible, and figuring out what to do with the charinsert edittools - so they could reasonably all be listed together, just as separate sections, perhaps, acted on individually? But with the approach of bundling the changes, the comments about each individual change are winding up all over the section, making following it quite difficult (and locating a specific thing in the middle of all this wikitext so as to reply to it even harder), and only doing it with vector seems like it would just lead to excluding the potential for in-progress feedback from the subset of users who don't use vector, which doesn't seem like it would make things any smoother. -— Isarra ༆ 00:46, 9 September 2012 (UTC)

Edit tools

So, I've seen a lot of commentary for people who don't want the edit tools (but don't have the enhanced toolbar and vector) or do want the edit tools, but do have that setup. I can see a couple of solutions:

  • Someone gadgetises the edit toolbar and we turn it off by default for new users, but on for existing users. We then just remove it from the MediaWiki namespace entirely. This has the advantage of requiring relatively little time at our end (which means it can be done fast). Alternately we can turn it off by default for everyone, but display a message in place of where it currently sits for a week or so in order to let people to know how to re-enable it.
  • We build "do you want this?" into the preferences menu. This is my least-preferred option; preferences are already highly cluttered, and we're looking at slimming them down, and it'll require more dev time at our end.

Opinions and thoughts? Okeyes (WMF) (talk) 16:27, 7 September 2012 (UTC)

Which edit tools/toolbars are you referring to here? Is it the Help:Edit toolbar or the mw:Extension:CharInsert box? The former, though it is generally called the 'edit toolbar', already has an option in the preferences to disable it, hence why I'm asking. -— Isarra ༆ 19:22, 7 September 2012 (UTC)
The latter. Okeyes (WMF) (talk) 19:27, 7 September 2012 (UTC)
Not that this really helps anything now, but we may want to figure out what to do with the edit toolbar on the editbox itself before worrying about the charinsert edittools, which exist as possibly redundant and possibly not depending on what happens with the toolbar. -— Isarra ༆ 00:46, 9 September 2012 (UTC)
I requested that last month at Wikipedia:Gadget/proposals#Edit tools. No replies so far... Helder 18:08, 10 September 2012 (UTC)
I've asked User:YuviPanda if he could gadgetise it; if and when he does I think we can WP:BOLDly stick it in :). Okeyes (WMF) (talk) 23:48, 11 September 2012 (UTC)
Thanks! If I didn't miss anything, the steps I provided there should be sufficient to implement this as a gadget. Helder 21:36, 12 September 2012 (UTC)

Can we have edit tools back? I can't see Cite on Firefox 15.0.1--Redtigerxyz Talk 12:46, 29 September 2012 (UTC)

We're talking about the box of insertable characters and strings of characters which were to be found under the edit box but have been disappearing and reappearing recently. You mean this disappearance isn't some sort of glitch that we can hope goes away when whoever it is gets things sort out but that this someone actually imagines it would be a good thing to do away with them? Set me straight if I'm putting these comments in the wrong section, but ditching this would make editing WP extremely tedious (How would you insert IPA, mathematical symbols, Greek letters, etc. etc.?) to the point where many would just give us ("No multiplication sign, the letter 'x' will do; no minus sign, use a hyphen; IPA, forget it, just use a respelling ... or are we going to see the return of SAMPA?). Terrible idea. JIMp talk·cont 07:10, 5 October 2012 (UTC)
The box shown at MediaWiki:Edittools is called the "edit tools". --Redrose64 (talk) 15:25, 5 October 2012 (UTC)

Deployment coming up

Hey all :). My apologies in advance (first for the short notice, and second for the inaccuracy of this compared to the public statement we made) but we'll be deploying this in probably the next couple of days. TL;DR, a misunderstanding about where and when things deploy meant that we have substantially fewer opportunities to throw out new code. I'll let people know as soon as changes are live (if they don't notice themselves). We'll get better at this, I promise :). Okeyes (WMF) (talk) 03:29, 13 September 2012 (UTC)

Fantastic! Thanks! • Jesse V.(talk) 00:26, 17 September 2012 (UTC)
Okay; next Monday ;p. We had a couple of patches to get in. Okeyes (WMF) (talk) 19:31, 19 September 2012 (UTC)
I'm also afraid to report that most of the changes will, in fact, hit everyone :S. I'm terribly sorry about this. Okeyes (WMF) (talk) 21:14, 19 September 2012 (UTC) (who is swiftly discovering that a 336:1 days on:days off ratio is a poor'un).
So, in order:
  • All users will see the MediaWiki messages move around (one to above the edit window, for example) and the tweaks/copyedits to them;
  • Edit tools will continue to appear for non vector/enhanced editing toolbar users;
  • Only vector users will see the colour changes and suchlike.

So I may have misspoke when I said "most of the changes" :P. But there will be changes for everyone. Okeyes (WMF) (talk) 20:03, 20 September 2012 (UTC)

I may have missed it in skimming the above, but I have 2 concerns.

Is the "drop down box" holding transclusions and hidden cats still going forward?

If so I think I would be opposed to this as it could affect those who have javascript blocked.

The same goes for anything else in this proposal which would affect those without javascript. - jc37 00:13, 21 September 2012 (UTC)

As I understand it, if javascript isn't enabled it'll just display as two distinct (non-collapsed) lists - but I'll make sure. Okeyes (WMF) (talk) 03:38, 21 September 2012 (UTC)
I'd appreciate if there was an option to show the two lists uncollapsed per default. --Eleassar my talk 22:13, 22 September 2012 (UTC)
There will be; it remembers whether you want them open or closed, and deals with them accordingly. If you opened them up, they'll be open on any other page, too. Okeyes (WMF) (talk) 01:20, 23 September 2012 (UTC)
Ok, great. Thanks. --Eleassar my talk 19:11, 27 September 2012 (UTC)

Preferences option?

I like this, but for those people who may not like it, could there be a preferences option to use the old layout? Although this is certainly easier for new users (who, for example, previously might not have found the list of templates and categories on the page – I only realised its existence after I'd been here for one and a half years(!)), we certainly don't want to lose any current constructive editors, who may have become somewhat attached to the old layout (probably mostly because of the font, which is what everyone will notice) after having used it for a long time. Double sharp (talk) 08:46, 21 September 2012 (UTC)

Well spotted - font isn't mentioned above but it's in the screenshots. I've asked Oliver to clarify. Andrew Gray (talk) 11:08, 21 September 2012 (UTC)
I assume the font you all are referring to is inside the edit window (textarea). That's already configurable at Special:Preferences#mw-prefsection-editing ("Edit area font style"). --MZMcBride (talk) 15:28, 21 September 2012 (UTC)
And at the same time, the font itself should only change for people on Vector :). I'm sorry it's so confusing and multi-faceted: part of our efforts to try and only hit a small group with the biggest changes. It also means we've got a lot of different permutations of the changes :S. Okeyes (WMF) (talk) 16:28, 21 September 2012 (UTC)
What font? The font looks the same in the prototype. -— Isarra ༆ 18:11, 21 September 2012 (UTC)
Ignore me; just clarified with Rob and Vibha. Okeyes (WMF) (talk) 18:43, 21 September 2012 (UTC)

Header when editing

In the header above the edit window, there is the text "... Work submitted to wikipedia can be edited, used and redistributed by other people at will." Should Wikipedia be capitalized? Chris857 (talk) 23:10, 27 September 2012 (UTC)

Makes sense; I'll change it now :). Okeyes (WMF) (talk) 23:13, 27 September 2012 (UTC)
Now done! Okeyes (WMF) (talk) 23:14, 27 September 2012 (UTC)

Is there a way to insert links and templates automatically without copypasting from Help like in the previous version?Tintor2 (talk) 21:25, 28 September 2012 (UTC)

What do you mean, sorry? Okeyes (WMF) (talk) 22:46, 28 September 2012 (UTC)
If I want to insert a wikilink like "[[]]" I have to copypaste it from the option "Links" located in "Help". In the previous version I could directly insert them with the tools located below "Save page" that also contained the signature with timestamp as well as other useful things. Now there is nothing below Save page other than "View hidden categories on this page." To make it simpler its the lack of MediaWiki:Edittools which helped me a lot. Regards.Tintor2 (talk) 00:50, 29 September 2012 (UTC)

The old window had a box full of special symbols...

I'm not really sure what they all were, but below the edit window used to be a box of all these symbols, you'd click on one, and, boom, there it would be in the edit window. I used this feature all the time for the insertion of em- and en-dashes, but now I don't see it anywhere. Is it still part of the window? If not, I feel it should be reincorporated somehow as I utilized that feature a heck of a lot and it's easier than copying and pasting the dashes, in my opinion.--RedSoxFan274 (talk~contribs) 04:45, 29 September 2012 (UTC)

As mentioned elsewhere on this page, try going to Preferences → Editing and switch off "Enable enhanced editing toolbar". That has helped other users. --Redrose64 (talk) 12:22, 29 September 2012 (UTC)
Can't the two remain at the same time? The new one offers an automatic way to write citations but with the old one had all the special symbols that could be added just by clicking rather than copypasting.Tintor2 (talk) 14:08, 29 September 2012 (UTC)
Seconding this. I used the "find and replace" function all the time when tweaking tables and the like, and would like to keep the enhanced edit window so I can continue to use it, but simply put, the upkeep of MOS:DASH really needs those simple dash buttons retained to stay consistent. You can't expect a house style relying on relatively obscure punctuation to be stuck to if most editors have to jump through hoops to do it. Disabling useful functions just to save myself from copy-pasting dashes thirty or forty times in an article isn't going to cut it; there's no reason that bar of one-click symbols can't be re-added. GRAPPLE X 05:36, 1 October 2012 (UTC)

Oppose the new changes unless I can keep the "wiki markup box" (as mentioned by Red above) and the enhanced editing toolbar. Right know to restore the first I have to turn off "Enable enhanced editing toolbar" in user preferences. No thanks. This is a dumbed down interface. Most important of all, there is no <ref></ref> tag readily available anymore, discouraging users from improving articles quality.

This unwarranted and unasked for changes are annoying, wasting the precious little time I have for editing.--Sum (talk) 08:56, 29 September 2012 (UTC)

Thanks, Redrose, the wiki markup box has returned for me now. In spite of this, however, I personally still feel that I must second the grievances which Sum rightly brought up.
RedSoxFan274 (talk~contribs) 00:06, 30 September 2012 (UTC)
  • We're restoring the edit tools this Thurday (touch wood). Redrose Redsox, Summer, we advertised these changes for weeks, accepted feedback (and incorporated that feedback) and did so after sticking out a watchlist notice to all users. Can you point me to how we can improve on this process? Okeyes (WMF) (talk) 20:33, 2 October 2012 (UTC)

I never saw any watchlist notice. I just came here after a few days frustration with the intermitant disappearance of the edit tools box which I had been using all the time. Thinking it was some kind of glitch I came to ask when things might be sorted out and the box be returned. I was rather shocked to find that this was actually intensional, that those in charge thought it a good thing to remove this useful box. And, no, the enhanced editing toolbar up the top is no substitude; it lacks a lot of the stuff that the bottom box has, includes a lot of stuff that consensus at WP:MOS discourages and makes you wait a few seconds before you can edit. Thank you, Redrose, for pointing out how to turn this thing off and thank you, Okeyes, for putting the edit box back. JIMp talk·cont 07:55, 5 October 2012 (UTC)

It went up with these three edits and came down again with this edit. --Redrose64 (talk) 16:10, 5 October 2012 (UTC)

Uh, what the crap happened.

So, I was told we would be getting a new edit window on October 1st. It's the 29th and I'm already being forced to use the new edit page. I completely oppose the changes as they make the interface hard to read, especially on pages with editnotices. Please somebody make a revert gadget! --Nathan2055talk - contribs 16:27, 29 September 2012 (UTC)

Can you explain in more detail what makes the text hard to read? I apologies for the slight alteration of plans - it was that or the 8th, quite frankly, which is much further away from the 1st. Can I ask why the 1st rather than the 29th would have been more advantageous? I had this thread open for weeks, and advertised it with a watchlist notice: you could have given your feedback at the time :). Okeyes (WMF) (talk) 20:36, 2 October 2012 (UTC)
As I read it, Nathan seems to be saying that these changes should be made the later the better, i.e. never, a sentiment with which I agree. JIMp talk·cont 07:30, 5 October 2012 (UTC)
Yeah. What exactly is improved by this? It seems like a lot of stuff is actually damaged by these changes. For example, the subject headline box upon creating a new talk page message looks strange. I'm sorry if I seemed upset with my original post, but this is an unwarranted change which it seems like half the community agrees with me on the fact that we don't need. I repeat, what is fixed by this? --Nathan2055talk - contribs 21:18, 8 October 2012 (UTC)
Here's a picture of changes that would actually benefit editors instead of simply moving around legal stuff. This really just seems like an unwarranted update that just clutters everything. Why not modify what we have and make it easy to use, such as adding links to help pages for noobs or various other things like that. Just a thought... --Nathan2055talk - contribs 14:00, 10 October 2012 (UTC)

Edit window changes

As discussed above, we've made some changes to the edit window, which are now live - slightly ahead of schedule! :). I hope people are happy with them: if something is causing a problem (I am predicting "where are the edit tools?" - and we're going to fix that), let us know and we can start dealing with it :). Okeyes (WMF) (talk) 23:08, 27 September 2012 (UTC)

Yeah, were are they? :) Specifically, I really appreciate having ndashes easily available like the edit tools provides. Chris857 (talk) 23:28, 27 September 2012 (UTC)
As do I! We're working on a big-ass proposal right now that'll include a load of changes, but also talking about a short-term (read: either this evening, or pretty soon after) to restore. Okeyes (WMF) (talk) 23:44, 27 September 2012 (UTC)
Short-term fix is now in gerrit and awaiting review and deploy :). Okeyes (WMF) (talk) 00:24, 28 September 2012 (UTC)
Good work. This is definitely an improvement. I agree about the special symbols though, in particular endashes and mdashes are critical. Jason Quinn (talk) 00:39, 28 September 2012 (UTC)
Thanks! I'll pass the compliments back to the team :). And, agreed. We've actually got the fix written, we're just waiting on the deployment. Okeyes (WMF) (talk) 00:51, 28 September 2012 (UTC)
I need my double curly brackets for templates! Don't want to have to manually type them; highlighting the text was just too easy. I'd be content if they, along with the various types of dashes and other special symbols, were added to the advanced editing toolbar above the editing window.--Sturmvogel 66 (talk) 02:26, 28 September 2012 (UTC)
You can always use the param wizard in the section below. Ryan Vesey 02:29, 28 September 2012 (UTC)
I posted a minor issue about "Save Page" differing from the actual button's "Save page" at MediaWiki_talk:Wikimedia-copyrightwarning#"Save_Page" should be "Save_page" to match the button that would be a one-second fix for somebody who can edit the page. In general, I think that the idea behind mw:Micro Design Improvements is a very good one. I see the project lists the edit toolbar as a possible future undertaking. If they are refering to the RefToolbar, I think it would be an excellent candidate. I have recently posted some ideas to MediaWiki_talk:RefToolbar.js#Tweaks to make tool better that give specific goals that could be accomplished. It seems like the new editor engagement initiative has also identified the Reftoolbar as needing some attention as a "smaller project" (see mw:New editor engagement/Smaller issues. Jason Quinn (talk) 02:29, 28 September 2012 (UTC)
Actually, we mean the newer one (the "enhanced editing toolbar"). So, one of the improvements I particularly like the idea of is sorting out the Special Characters section as Sturmvogel suggests above - the fact that it doesn't include wiki syntax (but does force me to load 15 character sets to hunt for wiki syntax) is silly, and we should improve it. Okeyes (WMF) (talk) 02:38, 28 September 2012 (UTC)
Ah. Well, the RefToolbar is another good thing to consider. I will maybe post on the project page about that. Jason Quinn (talk) 03:24, 28 September 2012 (UTC)

I don't know about anyone else, but it doesn't always load/render at once, and will kick me out of the edit window. With a very small page/section, I'll click the mouse in the window and start typing, and then suddenly I'm using Firefox's "type to search" feature, meaning I no longer have the edit window selected. Also the screen bounces around while the "View hidden categories" sorts itself out. I like the changes OK, but it would be nice if they were HTML-coded instead skinned-on afterward. I can still see the original edit window when I first load the edit screen. ▫ JohnnyMrNinja 02:56, 28 September 2012 (UTC)

A known bug; my apologies :(. We should have the patch for that by Tuesday. Okeyes (WMF) (talk) 03:03, 28 September 2012 (UTC)
It wouldn't stop me coming back to WP, but it is nice to know someone's working on it. ▫ JohnnyMrNinja 03:37, 28 September 2012 (UTC)

I recently found that it's generally unhandy to click on the Advanced button each time the redirect is needed. Not all users, particularly newcomers, remember #REDIRECT [[]] wikicode and it could be an obstacle. So I think it would be more convenient if we move the redirect button from Advanced set to the main set on the left (getting just one click instead of two). Even if you remember the redirect code, it would be more convenient to just press the directly visible redirect hotkey, rather than typing the code in. Brandmeistertalk 09:52, 28 September 2012 (UTC)

What happened to the non-breaking space? By the way moving the Edit Summary box down from the edit window box is not really a good idea as it is no longer visible without scrolling down so we will end up with less use of edit summaries. Keith D (talk) 11:25, 28 September 2012 (UTC)

Even though the only way to actually save is to scroll past that box? Okeyes (WMF) (talk) 17:21, 28 September 2012 (UTC)
It's not though. Alt+⇧ Shift+S works for me. --Redrose64 (talk) 18:35, 28 September 2012 (UTC)
The 0.5% of folks who actually know about that shortcut (and it's very handy, don't get me wrong) really should know about edit summaries and when to provide them... I don't think it has much impact. —TheDJ (talk • contribs) 13:37, 29 September 2012 (UTC)

The "Insert special characters" line only appears on about 40% of screens (IE8 Vector)
IE's "Find" facility only works on about 60% of screens - so finding spelling errors is a nightmare. Arjayay (talk) 11:37, 28 September 2012 (UTC)

On returning to "Search Results", having corrected a typo, about 30% of the time it jumps to the top of the list, rather than staying on the point in the list where the last page was selected - which it always has done until today.Arjayay (talk) 12:35, 28 September 2012 (UTC)

  • Here's an odd one. On clicking any "edit" link, the spinny thing in the browser tab (Firefox 15.0.1 under XP SP3) doesn't stop, suggesting that some CSS or JS page is taking a while to come through. Despite this, I can edit. However, on one occasion, three of the last six buttons above the edit window (I use RefToolbar 1.0) were suddenly replaced by their hidden captions:
Insert hidden CommentInsert a picture galleryInsert block of quoted textInsert a tableInsert a referenceInsert Citation
became
Insert hidden CommentInsert a picture galleryInsert block of quoted textInsert a tableInsert a referenceInsert Citation
The others were unchanged. --Redrose64 (talk) 12:55, 28 September 2012 (UTC)
Looks better now, the entire advanced set appears uncollapsed. Brandmeistertalk 13:29, 28 September 2012 (UTC)
  • They have the fix but haven't deployed it yet. I'd still prefer to have them on the bottom, but the changes override any personal javascript or css so I don't think there is any way to do it (aside from discontinuing to use vector skin). Ryan Vesey 20:05, 28 September 2012 (UTC)
  • So at some point these functions will return, then? Good. For me, the advanced editing mode (if that's right term) isn't so good, because it also makes cutting and pasting text without bizarre formatting changes impossible; it also tends to add spaces between lines that makes layout more difficult. So, anyway, long story short, I've really come to rely on these menus for no-wiki markups, dashes, foreign language characters and the like. I do hope it comes back. thank you, Shawn in Montreal (talk) 20:23, 28 September 2012 (UTC)
Try this: go to Preferences → Editing and switch off "Enable enhanced editing toolbar". That seems to have helped other users. --Redrose64 (talk) 20:33, 28 September 2012 (UTC)
Oh, perfect. That's solved it, thanks. Shawn in Montreal (talk) 20:54, 28 September 2012 (UTC)
(after e/c) Thank heavens - that works for me. But what's gone wrong with the communication system, that this change gets introduced so that the edittools disappear, leaving me having to try and remember the exact syntax for "Defaultsort" or "nowiki" and type it in manually? How many thousands of other editors are currently digging around the system trying to work out how to get back the tools on which they rely? I asked at the helpdesk, then found this discussion, and then - after quite a while - got down to this practical advice! PamD 21:03, 28 September 2012 (UTC)
Yeah, it's not perfect; I'll be the first person to admit this :). I consider the fact that we're having this conversation (and the fact that the changes were made after a wider discussion advertised via a watchlist notice) evidence of progress, though - as is the fact that we're making the necessary changes to bring that stuff back :). As both an editor and (recently) as a staffer, I've seen too many development processes that run "build it, don't ask anyone, deploy it, don't ask anyone, release it and hide under the desk until people stop being annoyed". Okeyes (WMF) (talk) 22:48, 28 September 2012 (UTC)
Notices that I recall indicated that it would only be Vector users that would see changes not all skin users. Keith D (talk) 22:51, 28 September 2012 (UTC)
At the time, that was the case; I stuck out an update in multiple venues as soon as I found out different.
You're getting paid for this? Shame on your boss. You have a lot of unfixed issues here. Revert to the last known good working version, fix the problems that have been identified. Then, publish an alpha test. Offer all editors the option of using the new version with a link from the known good working editor. Collect editor experience from that until you are confident that enough issues have been resolved and then publish for real. This isn't rocket science.
—Trappist the monk (talk) 23:05, 28 September 2012 (UTC)
That's precisely what we did The repeated weeks with offers to use a prototype version - those weren't noticed? The issues that were raised before the point of no return have been fixed; the issues afterwards are being fixed as we speak. No software release is bug free, and we are operating under particularly unique constraints. Okeyes (WMF) (talk) 23:33, 28 September 2012 (UTC)
If this posting is what you mean by "repeated weeks with offers to use a prototype version", then I have failed to communicate what I meant. Offering the prototype for inspection and experimentation is wholly different from offering the prototype as an alternative editor. Those of us who stumbled upon the the Upcoming changes notice (I'm not even sure how I got here) may have spent a few moments playing with the prototype, but none of us could use it for any substantive work.
The process I wanted to convey was this: Create a new prototype version of the editor. Publish that prototype wherever it is that you would publish the final release but don't overwrite the current known-working editor. Editors who create and maintain articles click on the edit link at the top an article page. That link takes them to the currently released version of the editor. There, they will get a notice that offers to let them use the new prototype editor (along with the necessary warning that the prototype is a prototype so things may not work as they might be expected to work). If the editor chooses to use the new editor, s/he clicks the link and can now edit the article with the prototype editor. Maybe after the page is saved, the editor might get a prompt asking if there were any problems. Or maybe there is a Report-problems-with-the-prototype-editor link on the new editor page.
Perhaps this whole process becomes the standard way you do things - all new features and enhancements are always available for any editor to actually use in the real world with real articles. Much more better than spending a few distracted moments playing with a prototype that one can't actually do anything with. Am I making any sense?
—Trappist the monk (talk) 00:29, 29 September 2012 (UTC)
Thank you; that makes a lot of sense, and is a lot more productive than our earlier discussion :). So, traditionally the development process went "come up with idea, develop, deploy, fix bugs in one big swoop and then declare it done and wander off". With our newer stuff, I've actually pushed people to do exactly what you've described; Wikipedia:Page Curation was live as a non-replacement for the existing process the moment we had a prototype that didn't explode and throw cogwheels out the moment anyone looked at it, and I think our development process went a lot smoother because of it.
I'd love to do the same thing with these kinds of tweaks, and for future projects and iterations, I agree that this approach should be something we look into on a case-by-case basis, but - just for context - I think it would have been a challenging thing to work into this project, though. These changes came as the first project of the new Micro-Design Improvements team, which has Vibha Bamba doing design, Benny Situ and Rob Moen coding, and me sort of tidying around the edges. Sounds like a lot of bodies - until you realise that we only get Benny and Rob one day a week each (and they're neither sequential nor simultaneous days) which seriously limits what we can do, and that both Vibha and I are on other projects which demand substantial time. This slows down how quickly we can make alterations (although we actually have a fix for this problem already developed , and are just waiting for it to be deployed).
Obviously this is no excuse, but it means we strain to repair the problems instantaneously. Because of all of these factors, I can't offer an immediate change to our approach for this project - but I can promise that we'll get better at this. As depressing as it is, the fact that we're having this conversation at all is indicative of a shift in how the WMF approaches software deployments: hopefully further improvements will be coming down the pipeline soon, and I'll try to integrate your feedback into our thinking :). Okeyes (WMF) (talk) 01:24, 29 September 2012 (UTC)

A warning to all that as of now I'm actually on my first holiday - it turns out that 345 days on, 1 days off as a work/life balance is a poor idea. This holiday seemed a lot better timed when I organised it :S. I'll be following things from my volunteer account, and hopefully the patch will be deployed soon. Okeyes (WMF) (talk) 01:27, 29 September 2012 (UTC)

It might be a good idea to inform editors with citenotice after patch is deployed because many people switched off "enhanced editing toolbar" in order to get edit tools back, but would like to have "enhanced editing toolbar" also.--Antidiskriminator (talk) 23:13, 30 September 2012 (UTC)

A different bug I found: when I preview (or show changes) on a page, the collapsible templates/hidden cats menus go away, and instead show all of the templates and categories. I'm using live preview (Preferences → Editing). David1217 What I've done 01:55, 29 September 2012 (UTC)

The live preview gadget is something of a hack, so it's not surprising there are issues... It's probably something do with interaction with the JavaScript that enables the preview as well as hides the templates/categories. Steven Walling (WMF) • talk 20:23, 30 September 2012 (UTC)
  • Comment:Here is something that I have discovered is rather a nuisance. Part of the checkbox label "This is a minor edit" is a link. One of the nice things about checkbox labels is that one can click on the label and change the state of the checkbox – it makes for a much larger target than the checkbox itself. Since this new editor has been active, I have several times missed the checkbox part of the label and gotten the help link part. I think that the help link should not be part of the minor edit checkbox label – the checkbox label "Watch this page" label doesn't (and shouldn't have) a similar link.
—Trappist the monk (talk) 15:38, 1 October 2012 (UTC)
There's no way to keep the link in there and have it not be part of the label, and that wouldn't really help with the misclicking problem anyway. And for new users' sake, I doubt we'll be able to remove the link entirely. But if you want to hide it using your common.css, see MediaWiki talk:Minoredit#Hiding the link. Anomie⚔ 16:34, 1 October 2012 (UTC)
Per comments above, they were supposed to be restored ten days ago. When editors complain, we are just telling them to turn off the enhanced editing toolbar. ---— Gadget850 (Ed) talk 21:49, 14 October 2012 (UTC)

CSS

If it at all helps, instead of using js to restyle the editoptions under the edit window, which results in a bit of a jump as it loads and also apparently has the potential to mess up people's scripts, the following css could be added to the vector skin/extension for the same effect: 

.editOptions {
	background: #F0F0F0;
	border: 1px #c0c0c0;
	border-style: none solid solid solid;
	padding: 1em;
	margin-bottom: 1em;
}
.editButtons > input[type="submit"] {
	font-size: 110%;
	margin: 0px 0.33em;
}

If folks feel it is an issue, I would strongly urge using that instead. -— Isarra ༆ 01:39, 29 September 2012 (UTC)

Yep; as promised when we last had this conversation, that's being done. Rob reckons he'll have it finished on Tuesday of next week. Okeyes (WMF) (talk) 01:44, 29 September 2012 (UTC)
Thank you. -— Isarra ༆ 03:11, 29 September 2012 (UTC)
See User:Br'er Rabbit/common.css for much more re-styling of that stuff. I wanted stuff gone and more compact; idea is more space for the editbox. 2Oliver: The emitted markup should not use explicit <br> and <hr>; just set the appropriate styles. nb: better to use 120% or similar than 14px in the above. <br /> 03:22, 29 September 2012 (UTC)
Right, defining in terms of px isn't very good practice. And you're very minimalist, aren't you?
Tangentially, I'd also recommend making the templates and catlist stand out more and be more easily clickable, perhaps with something along these lines:
.templatesUsed .collapsible-list, .hiddencats .collapsible-list {
	background: #f0f0f0;
	border: solid 1px #c0c0c0;
	padding: .4em .5em .3em .5em ;
	margin-bottom: .5em;
	display: block;
}
They're so very tiny and unnoticeable scrunched up down there the way they are. They don't need to take up all that much space, but they can be useful. -— Isarra ༆ 04:04, 29 September 2012 (UTC)

Different font and size in edit mode

I now have a different font in edit mode, different size (it's larger than it was), and it's in bold. It is making harder to edit because I see a much smaller portion of the page in edit mode. I can zoom in, but then I have to zoom out again whenever I preview, so it's very inconvenient. Is it possible to adjust preferences to return the old view? SlimVirgin (talk) 03:30, 30 September 2012 (UTC)

Hmm, that's a bit strange, since it should not have changed anything in the edit input box. What skin are you using and do you have anything custom set in your CSS and/or browser font prefs? You should be able to set your preferred font for the edit window at Preferences → Editing in the "Edit area font style" dropdown. Steven Walling (WMF) • talk 20:20, 30 September 2012 (UTC)
Hi Steven, thanks for the reply. I use Firefox and in my WP preferences I had ticked "sans-serif font." When I saw your post I changed it to "browser default," and that has restored the font I had before this recent change. It also got rid of the boldface. Thank you for pointing me in the right direction. SlimVirgin (talk) 17:36, 2 October 2012 (UTC)
Glad it worked. :) Steven Walling (WMF) • talk 17:41, 2 October 2012 (UTC)

Where did the signature icon and other advanced features of the talk page options go?

I have noticed that as of today I no longer have any advanced feature icons on talk pages, no icons for signing, no bold icons, no italic icons etc etc, just the three icons submit, preview and show changes. What happened to all of those? --Saddhiyama (talk) 00:13, 29 September 2012 (UTC)

See #Edit window changes above. Chris857 (talk) 00:19, 29 September 2012 (UTC)

Oppose. This is a unilateral change, has not been up to a vote, and users are baffled by the absence of a warning about the change. There is no option to keep the previous interface. Most important of all, there is no <ref></ref> tag readily available anymore, discouraging users from improving articles quality.

This unwarranted and unasked for change is annoying, wasting the precious little time I have for editing.--Sum (talk) 08:56, 29 September 2012 (UTC)

If you have the new editing toolbar, you can use the open-book-with-red-bookmark icon to get <ref>...</ref>. — This, that, and the other (talk) 10:12, 29 September 2012 (UTC)
You find it unwarrented. Personally I welcome it dearly. You see, there is no way to figure things like this out, without actually TESTING what it does. We could stick every character in the world into that box and some people would still LOVE that. But that doesn't make it a good idea. Almost all the elements are available in the toolbar, and if we really have a problem, then we can always switch back (nothing is set in stone). —TheDJ (talk • contribs) 12:57, 29 September 2012 (UTC)

Actually, I like it better now. Of course, I use ProveIt and some other tools, but the edit summary is in a better place, and it just seems to flow better. --Nouniquenames 18:20, 29 September 2012 (UTC)

I note that, far above, the rationale for "Removing the "edit tools" toolbar after "save page" " is "A lot of the functionality here is duplicated in the enhanced editing toolbar,...", and above we see "Almost all the elements are available in the toolbar". Yes, "a lot", or "almost all", but what about the rest? For me, the useful missing stuff is Comments, Strike-out, and Defaultsort (I do a lot of stub-sorting, and always fix the Defaultsort where necessary - eg if the title starts with "The "). For other people it's other things. Could the missing items please be added into the toolbar, without too many clicks to get at them? PamD 19:14, 29 September 2012 (UTC)

We are re-deploying on Thursday to re-add the edit toolbar until we can add the functionality to the "real" toolbar :). My apologies for this :(. Okeyes (WMF) (talk) 20:39, 2 October 2012 (UTC)
The words "until we can add the functionality to the 'real' toolbar" are very disappointing. So, you intend eventually push through with this. Your "real" tool bar is a real pain: including stuff against WP:MOS, missing a lot of useful stuff the lower one has (you say you'll add it back), as far as I know we (ordinary users) have no control over it (as we have with the lower box) and when you open an edit window you have to wait for this "real" tool box to expand itself to its glorious size (I've often gone to edit only to find that I'd clicked one of this box's buttons which hadn't been there a second before). I've just turned the "real" box off. It's nice to be rid of it and nice to have the unreal box back. JIMp talk·cont 08:28, 5 October 2012 (UTC)
my favorite example of the anti-MOS stuff is the provisions for big and small text, something we very strong deprecate. They are still there, I thin 5 years after I first complained about it. There continues to be a disconnect between those who know the MOS and those who design the interface. DGG ( talk ) 02:53, 11 October 2012 (UTC)
@Okeyes It's a week past Thursday now and Wikipedia:RefToolbar 2.0 (aka "Enhanced tool bar") users still do not have MediaWiki:Edittools back. This thread has gotten overly complicated to follow but if I'm reading things right it seems like there are no plans to use put Edittools back for those users. Is that correct? If so, why? Jason Quinn (talk) 20:07, 11 October 2012 (UTC)

Squeezing in a subtle, fine-print notice about copyright at the very tippy-top of the page seems like a step backwards. When it was placed by the submit button, at least it was in a place where people's eyes would reasonably be drawn. But this new location? Might as well be non-existent. If you're going to put it at the top of the page, at least make it noticeable. At least in Monobook the notice is in black font colour. Grey words might as well not be there at all. ~~ Lothar von Richthofen (talk) 18:16, 7 October 2012 (UTC)

Well, the intention is merely to place it more logically. It wasn't so much by submit as it was after it - which sort of defeats the purpose (by the time someone finds it, they've typed whatever it is they planned to type). Having said that, we can certainly look into making it more prominent. Okeyes (WMF) (talk) 06:53, 15 October 2012 (UTC)

Collapsed list of templates

I'm no great fan of this but I can understand how collapsing the template list would be a welcome reduction of clutter for most editors. At least it hasn't just been deleted. I wonder, though, whether there might be some way to add an option to the prefs not to collapse the list. JIMp talk·cont 08:28, 5 October 2012 (UTC)

We're actually going to hopefully transition it over to a "hidden" preference. If you click it to open it, it'll remember you like it open, and keep it that way in future pages until told otherwise :). Okeyes (WMF) (talk) 06:54, 15 October 2012 (UTC)
perfect JIMp talk·cont 02:34, 18 October 2012 (UTC)

Cite function

Having switched off the "enable enhanced toolbar" in order to get back the edit tools, I now find that the "Cite" facility is much better in this state because I can preview a reference before adding it. Particularly when editing a section, it's been a constant irritation that I couldn't preview the effect of any reference without saving my edit and then looking at the whole article. I hope that the final version we're going to have will include this very helpful "preview citation" facility! PamD 22:13, 2 October 2012 (UTC)

My complaints

My last comment wasn't noticed, so I'll try again. Here's the current issues I have with this:

  • The big line of text under the edit window is annoying. It should be moved back where it belongs, near the save page button.
  • We never got our save page button at the top of the screen, my favorite of the many suggested changes in this topic.
  • Cancel still isn't a button. I'd look a little better if it was turned into a button rather than a link.
    Tracked in Phabricator
    Task T42601

However, my biggest complaint is still that this was pushed on me without telling me two days early. The watchlist notification still says the changes will be pushed on the first. I wish there was protection against stuff randomly changing on a day to day basis. </rant> --Nathan2055talk - contribs 16:58, 30 September 2012 (UTC)

I would prefer that Cancel remain a link like it is now. I often begin an edit, then open the Cancel link in a new tab to get another look at what the original problem is. That's impossible if it becomes a button. jcgoble3 (talk) 18:03, 30 September 2012 (UTC)
The "Read" tab at the top of the page can be used for the same purpose. Additionally most browsers allow you to Ctrl or middle click the back button to open the previous page in a new tab. the wub "?!" 19:56, 30 September 2012 (UTC)
But those options require scrolling back to the top of the page (for the "read" tab) or moving the mouse cursor all the way up into the corner of the screen (annoying when I normally operate the back/forward buttons with the extra physical buttons on my five-button mouse). The Cancel link is close to the edit box and is far easier and more convenient than either of those options. Although now that I think about it, it may not matter for me personally since I use wikEd, which overwrites the default buttons with its own, but others that don't use wikEd may feel similarly. jcgoble3 (talk) 21:27, 30 September 2012 (UTC)
It isn't clear to me why the link is called "Cancel". It doesn't actually Cancel anything – all it does is open the current version of the unedited article that you are editing. Want to uncancel after a cancel? Want to just cancel? Same answer for both: use your browser's back button. Editor jcgoble3's use of the link seems to me the most useful. The change that I would make would be to rename the link and have it open the article in a new window – much like the "Editing help" link does. (Shouldn't there be an icon for links that open in new windows à la external links?) Perhaps the "Cancel" link could be renamed: "Current article version" or "<article title> (current)" or some such. No reason to make "Cancel" a button.
The "Read" link at the top left of the page is the same as "Cancel". Both links, since they point to the same place, should have the same name thus neutralizing the work of that notorious Hobgoblin, Inconsistency.
–Trappist the monk (talk) 16:08, 1 October 2012 (UTC)
Extremely per Trappist. I have never used the Cancel link to actually cancel an edit. I use the back button for that. jcgoble3 (talk) 16:41, 1 October 2012 (UTC)
Editor Isarra has identified this issue as a bug. In his description of the bug this:
For consistency, when editing, the 'Cancel' link should really be a button along with the other buttons on the line, since it is an action like the rest of them even if it isn't directly tied to the form itself.
The help link ... [off-topic so excluded here]
Ignore the other stuff, but the line of buttons would look something like on this: http://commons.wikimedia.org/wiki/File:Enwp_edit_20120917_with_even_less_stuff.png
This description ignores the fact that the Cancel link doesn't actually cancel anything – all it does is link the editor to the current unedited copy. In the description and in subsequent conversation with other editors at the Bugzilla page, Editor Isarra doesn't state what a Cancel button should do. This somewhat implies that a button version of the link would perform the same action as the current link.
It seems to me that a true Cancel button might do either of a couple of things:
  1. Bounce back to the page where an edit link was clicked (an article page or a Difference between revisions page or other if there is other) and simultaneously remove the editor page from the browser's history;
  2. Remain on the editor page but revert all edits to the unedited state – essentially force an editor page reload.
I don't particularly care for either of these actions. Best, I think is to remove the Cancel link; or, if it must be kept, rename it so that it actually reflects what it does. If it is simply renamed, then it and the Read link at the top of the edit page must have the same name since they link to the same place.
—Trappist the monk (talk) 14:19, 2 October 2012 (UTC)
That makes sense :). I'll see if we have any data on its use. Okeyes (WMF) (talk) 06:56, 15 October 2012 (UTC)

Charinsert not working

Sorry, I know this is already discussed a bit above but this whole thing is tl;dr. All I want is for the CharInsert extension to work again, the way it's supposed to. I have it turned on in preferences, I've even tried unchecking then re-checking it & re-saving. No dice. I've waited a week now, hoping it's kick back in eventually, but it still hasn't. I use it all the time, & the fact that the recent changes to the edit window have caused it not to work is detrimental to me as an editor. I no longer have handy links to insert endashes, emdashes, wiki markup, etc. These tools are not available in the menus above the edit window. I have no objection to the changes made to the edit window, but I strongly believe they should not be implemented if they are known to break an existing Wikipedia feature (the charinsert extension is, I believe, turned on by default for registered users, so its sudden disappearance is likely felt by many more than just me). If a solution cannot be found to make charinsert work in a timely manner, then I respectfully request that the changes be rolled back until such a time as they can be implemented without affecting the charinsert extension. We should not be depriving editors of such a useful tool in order to quickly implement what are, to me eyes, semantic changes. --IllaZilla (talk) 04:31, 4 October 2012 (UTC)

Have you noticed any of my comments concerning Preferences → Editing (switch off "Enable enhanced editing toolbar")? No apparent complaints from those who did that. --Redrose64 (talk) 14:51, 4 October 2012 (UTC)
I already complained. That solution means you can have either CharInsert or everything else; and given how vital CharInsert is to maintaining MOS (en- and em-dahses don't appear on standard keyboards and extra steps to ensure writing is "right" are always going to result in failure) it's not really a workable solution for editors. GRAPPLE X 15:00, 4 October 2012 (UTC)
Slight side-issue that the en-dash em-dash hyphen stuff really is bollocks of the highest order. I mean, really, who gives a fsck whether the line is slightly longer or slightly shorter. Indeed, how many people even know what the "rules" are in this space? It seems to me to be a distinctly USian and pointless obsession. --Tagishsimon (talk) 16:42, 4 October 2012 (UTC)
Opinion aside, it is the way things are mandated by MOS:DASH; this is certainly not the venue to be discussing the merits of an already-extant guideline. GRAPPLE X 16:47, 4 October 2012 (UTC)
Note mw:Extension:Charinsert and MediaWiki:Gadget-charinsert.js are different things, although similar in intent. I don't know that the former was ever in use here. Anomie⚔ 16:32, 4 October 2012 (UTC)
Hm, I tried switching off "Enable enhanced editing toolbar". This gave me back charinsert, but changed the toolbar above the edit window to a row of buttons I remember from several years ago (same general functionality as the enhanced editing toolbar, but an older design). Like Grapple X, I'm unsatisfied with this: All I want are the same editing tools I had 2 weeks ago. These changes were not intended to affect these tools and should not have done so. Since it's obvious the changes break the editing tools, the changes should be reverted until the bug is fixed. They can then be re-implemented without taking tools away from editors. --IllaZilla (talk) 21:38, 4 October 2012 (UTC)
I have to agree with some of the above sentiments - the changes broke CharInsert, so they should be rolled back until they can be implemented without breaking a widely-used sets of tools. I'd have thought this would be common sense and standard practice. (Emperor (talk) 00:26, 6 October 2012 (UTC))
Confirmed on Google Chrome 22.0.1229.79: it only works if I disable the enhanced toolbar (and, as expected, only if I enable the gadget). Helder 04:18, 6 October 2012 (UTC)
One more gripe from a disgruntled editor, yes great so we can get our very handy edit tools window back ONLY by turning off the enhanced editing toolbar, leaving us with a bunch of clunky looking buttons above the edit window that I am in no way familiar with, and which, when inserting a wikilink, will not automatically propose the relevant wikipage, or a box to add text that is different.
Have to agree with several users above that having wiki markup in a drop-down box is a godsend and improves the editing experience a bazillion times, with which I can do this {{}}, {{Reflist}}, <ref name=""/> in a few clicks, thus facilitating my life as an editor and increasing the rapidity with which I can edit.
So, charinsert and enhanced editing toolbar please, as it was before, "I would have gotten away with it, too, if it hadn't been for you meddling kids!" CaptainScreebo Parley! 16:08, 7 October 2012 (UTC)
I've been equally bothered by this. When removing excess & duplication, its very easy to getthese things wrong, and it takes a trial to see the problems. DGG ( talk ) 02:48, 11 October 2012 (UTC)
Thanks for understanding :). I've just sent off a rather ornery email asking when this'll be fixed: I'm thinking probably Thursday, but I might be able to squeeze it in earlier. Okeyes (WMF) (talk) 06:57, 15 October 2012 (UTC)

Blockquote, nowiki etc

Apologies if I have missed something about this, but where have the links gone that enabled one to apply blockquote, nowiki, comment-out etc with one click? Is there a way to get them back? JohnCD (talk) 23:16, 5 October 2012 (UTC)

See above section for explanations, and while we're at it, what's with the changing "Common edit summaries" drop-down box? In the time I wrote the above comment they've been tweaked to "Reply, Comment, Suggestion", not really handy seeing as most people just use abbreviations like r, rep, cm or cmt to preface their ES, at least what was there before made some sense (even if very generic). Oh I see, different edit summary options depending on whether we're in article space or not, glad I worked that one out. CaptainScreebo Parley! 16:14, 7 October 2012 (UTC)

New changes to edit window?

Today, the edit window has changed rather strangely for me. I'm not sure whether it's due to my having upgraded Firefox to version 16, or to some new deployment of the software here, or a combination thereof, but it's very odd, and not to my liking. (I've made no changes in my preferences today.) The icons at the top of the edit window (with things like the signature button and special characters) are gone. Within the edit field, the font size looks smaller. Below the edit field are the good, new, buttons for saving, viewing preview, and viewing changes. But below them is an area with a great many special characters, simply displayed with instructions to copy and paste them into the edit field, instead of the ability to insert them by clicking on them. It's nice to have n-dashes and m-dashes again, but otherwise this strikes me as worse than what I had yesterday. Is anyone else seeing this? What is the reason for it? --Tryptofish (talk) 21:04, 9 October 2012 (UTC)

Addendum: I just uninstalled the current version of Adobe Flash Player, and replaced it with an earlier version of Flash Player (recent versions sometimes make Firefox crash for me, and that happened shortly after I made the comment above) [2]. And that restored the edit window to the way it was for me before! Everything I described above is a function of which version of Flash Player I have as a plug-in. Interestingly, those copy-and-past characters are gone for me now. --Tryptofish (talk) 21:19, 9 October 2012 (UTC)
I think it was me reverting the RefToolbar plugin to an earlier state (which was still broken, but less broken than the one I created earlier today it seems). —TheDJ (talk • contribs) 21:51, 9 October 2012 (UTC)
Thanks. Perhaps it is useful for those of you who (unlike me!) work on the inner workings of the interface to know how the way the edit window displays varies very much as a function of the Flash Player version. --Tryptofish (talk) 22:42, 9 October 2012 (UTC)
Oh, wait. Sorry, maybe I'm just being slow (not the first time...), but are you saying that the change I saw in my addendum was due to your reversion, and not to my changing my Flash Player version, which just happened at about the same time by coincidence? --Tryptofish (talk) 22:45, 9 October 2012 (UTC)
Exactly. just overlapping in time by coincidence. —TheDJ (talk • contribs) 07:27, 10 October 2012 (UTC)
Good, thanks! --Tryptofish (talk) 19:44, 10 October 2012 (UTC)
I'm on Chrome and don't have any of the Wiki markup I used to below the edit window. doktorb wordsdeeds 07:54, 10 October 2012 (UTC)
If you turn off the enhanced editing toolbar in your preferences you'll have them back. It was all supposed to be brought back, but apparently the new change didn't get rolled out. Ryan Vesey 18:43, 10 October 2012 (UTC)
Are they planning to? It's probably the most useful thing on the window, and we have to give up the enhanced editing toolbar to get it. This has not been a good trade, and the communication on its status has been less than stellar. BlueMoonset (talk) 18:50, 10 October 2012 (UTC)
They told me it was being returned to us a week ago. I don't know what happened. In the future, it seems like they plan to make it part of the dropdown menu on top. I don't like that idea at all, but I guess I could live with it. Ryan Vesey 19:14, 10 October 2012 (UTC)
I asked about the timing recently in #Edit window changes, above, and no one has replied. I'd like to know the answer. I hope that someone in the know will see this discussion, and let people here know. --Tryptofish (talk) 19:44, 10 October 2012 (UTC)

I'm using IE8 and intermittently getting one of the problems Tryptofish described - below "save page" etc I get various characters and tags that I am told I have to copy and paste, rather than being able to click on them, as usual. I note that on the occasions when I refresh the page and the clickable links do appear, the unclickable stuff appears briefly first. So it seems as though something fails to happen as it should. There doesn't seem to be any pattern to the intermittency. I believe it has started happening only in the last few weeks. I have "Enable enhanced editing toolbar" turned off, FWIW. Any ideas? Nurg (talk) 08:21, 17 October 2012 (UTC)

What happened to autocomplete search?

Gaahhh! I stepped away for a few minutes, then came back and clicked on a link in my watch list, then tried to input something in the search box at the top right (vector skin).

What happened here? The auto-complete has been rendered useless. It used to show pages on Wikipedia, including redirects, as I typed. Now it shows... nothing useful anymore.

Changing the settings don't seem to stick. I don't see anything in my user preferences about it.

How can I get back the functionality I had a few hours ago? ~Amatulić (talk) 23:10, 16 October 2012 (UTC)

What does "nothing useful" mean? Do you mean it shows nothing, or that it shows something totally irrelevant (and if so, what?)? --Carnildo (talk) 00:27, 17 October 2012 (UTC)
This also happens to me off and on, varies through the day with no rhyme or reason. Sometimes auto complete works. Sometimes it doesn't. Sometimes I could input something like "Provo, Utah", and it would show me a list on the auto complete. Sometimes it does nothing, so I'd input "Provo, Utah" and have to manually click "Search". Then, rather than taking me to the obvious page, it goes to the "Special Page" of where Provo, Utah would be the top selection, but other results are listed below that. Been going on a few weeks. — Maile (talk) 00:43, 17 October 2012 (UTC).
Which browsers (versions) is this occuring, which skin are you using and do you have any gadgets enabled ? —TheDJ (talk • contribs) 08:14, 17 October 2012 (UTC)
autocomplete works through ajax. this means that whenever you type a new character, a query is sent to the server, and when the response arrives, the drop-down menu is shown/filled.
because most of the time this works pretty fast, people tend to think of this as an immediate operation, but in reality the query/response round trip takes an indefinite amount of time (well, there *is* a limit - eventually something will time-out, so the response can't really arrive after 2 weeks. it's "indefinite" in the sense that i do not know what is the upper bound, but it's at least several seconds).
so do this experiment: type in the beginning of the article name, and then count to 10. if you still see nothing, then it's probably a real bug/problem. if something appears before you reach 10 but later then you expected, it basically means that either the network is slow, or the WP server was slow. solving either of these issues is outside the scope of enwiki village pump. if it takes a long time consistently, it's probably a network and not a server issu: if it was server, everybody would feel it. if it take a long time intermittently, and if more people report similar issue, then most probably the server(s) had a bad day.
peace - קיפודנחש (talk) 15:44, 17 October 2012 (UTC)
Well, thank you. This is the clearest (for me) explanation. Counting to 10 is a longer wait than most of us who expect results in a fraction of a second. But I'll think about that the next time it happens. — Maile (talk) 15:59, 17 October 2012 (UTC)
קיפודנחש: Your explanation, while informative, does not address the problem I initially posted about. Apologies for not being clearer.
Carnildo: "Nothing useful" means that autocomplete displays something but it's totally irrelevant to what I am looking for. For example, I type in "WP:BLA" and expect it to show me among the choices WP:BLANKING which is what I'm looking for. Instead it does not show me any article titles whatsoever, but rather I see a bunch of irrelevant search strings like "w.p. black scholarship".
It looked as if Wikipedia's autocomplete was querying Google search instead of Wikipedia's database.
It didn't matter if I shut down my browser (Chrome, in this case). Or opened new pages. I got the same odd autocomplete behavior.
Today, it's working. Any idea what happened before? ~Amatulić (talk) 01:52, 18 October 2012 (UTC)

ClueBot NG warning is not displaying on user talk page

My watchlist showed that ClueBot NG left a warning on User talk:209.66.200.155. Yet, when I go to that user talk page, I don't see the new warning.

I have never seen this problem before.

What's going on?

Thanks, --A. B. (talk • contribs • global count) 23:14, 16 October 2012 (UTC)

The page just hasn't been recached in a while. Someguy1221 (talk) 23:17, 16 October 2012 (UTC)
OK, I see it now. Thanks for the explanation. --A. B. (talk • contribs • global count) 23:32, 16 October 2012 (UTC)
Next time this happens, try purging the page. Graham87 07:02, 17 October 2012 (UTC)

Infobox maps in general

I noticed the default map on Infobox Mountain was changed to a relief map, which is really impressive. How does a person get the default map on any infobox changed to relief? Or get that as an option? Would I have to go type by type? I'm only thinking about Texas, because it's large and looks impressive in relief. Hawaii would not, probably. In Texas, there's probably an argument to be made that the current default showing the outline of all its 254 counties is also impressive. To put in such a request, how would I state it properly, and would I put the request on the infobox sandbox, or just infobox template itself? Posting this on the largely inactive Wikiproject Texas would not generate much.— Maile (talk) 13:29, 17 October 2012 (UTC)

Assuming that the infobox map goes through the generic {{Infobox map}}, and also assuming that a relief map exists with the same projection and corner coordinates as the normal map, then an edit like this will make the relief map available, but not as default setting. Another edit would be required to the code in the infobox itself to specify |relief=1 . --Redrose64 (talk) 16:25, 17 October 2012 (UTC)
This got me part way there. Somebody added the relief map to the Texas location map a couple of days ago. So, I could make the relief map of Texas come up in Loyal Valley, Texas. But then because it is no longer a push pin map, the pushpin label goes away. Map dot label does not substitute. The map is useless without the map dot and label. Got a suggestion? — Maile (talk) 17:01, 17 October 2012 (UTC)
I presume it's using Template:Location map. Locationmap can use relief maps and should be pushpins. Secretlondon (talk) 17:14, 17 October 2012 (UTC)
It's Template:Location map USA Texas. But, possibly because it is not the default on the Infobox Settlement template, putting the relief map in the pushpin map renders the whole infobox askew with "Expression error: Unrecognised punctuation character", etc. etc. — Maile (talk) 17:32, 17 October 2012 (UTC)
So this is Template:Infobox Settlement calling Template:Location map USA Texas as pushpin_map? It looks like they've set up the template to only use the first map but I can see you've asked on Template_talk:Infobox_settlement where people familiar with that template should hang out. Secretlondon (talk) 18:12, 17 October 2012 (UTC)
  • Infobox_settlement pushpin image is pushpin_image=File:map. To display the Texas relief map, as the background pin-dot map in {Infobox_settlement}, then use options:
| pushpin_map = USA Texas
| pushpin_image = File:Relief_map_of_Texas.png
However, I am not sure enough editors think the relief map is a significant improvement for locating a dot. I prefer locating a town within a map showing the nearby major cities and highways, such as showing Katy, Texas on the west side of Houston, along I-10 (the Katy Freeway, see roadmap: File:Katy.gif). Hence, also consider showing that relief map as a smaller image in a section about a town's "Geography" if the mountains, or desert areas, would make a difference. Otherwise a map for Galveston or Port Arthur, Texas would just be about the coastal areas. -Wikid77 04:49, 18 October 2012 (UTC)

New template: need to change either [show] / [hide] or [expand] [collapse] tags

Hello guys, I have a bit of a problem. have searched through all the navbox template parameters I have found; i even fell across this very helpful test page that helped me get rid of the V.T.E links...

Still I need to switch the [show] / [hide] tags (for collapsing the boxes) into other words and possibly arrow symbols but i cannot find out how to do that, if i have to i will modify the existing one into a new template, i just need someone to point out the way...

thanks Eli+ 14:14, 16 October 2012 (UTC)

Those tags are generated by javascript; [show]/[hide] comes from Common.js and [expand]/[collapse] are defind in MediaWiki:Collapsible-collapse and MediaWiki:Collapsible-expand. They cannot be changed from any template. — Edokter (talk) — 16:18, 16 October 2012 (UTC)
They could, if the migration of the templates to the plugin jQuery.makeCollapsible from MW 1.18 were complete (see discussion from 2011). Example:
Hello world!
Here, I've used the attributes "data-expandtext" and "data-collapsetext" to define the text. Helder 22:36, 16 October 2012 (UTC)
thank you guys, these parameters should be published for all to see somewhere around the help pages, i still find it hard to find technical articles even after 6 years of editing here.

i found the parameters here before i read Helder's response. Eli+ 12:26, 18 October 2012 (UTC)

2011–2012 Egyptian revolution templates are not working

Non of the templates at the bottom of the page are working – they simply link to the template's page. Is the article too large and the templates can't load? I've tried making edits and purging the page, but neither has worked. –– Anonymouse321 (talk • contribs) 06:05, 17 October 2012 (UTC)

Yes; the HTML source contains this line: "Post-expand include size: 2048000/2048000 bytes". Therefore the size of all the templates on the page is above the 2MB limit. See Wikipedia:Template limits, and consider splitting the article further using summary style. Graham87 07:10, 17 October 2012 (UTC)
As a temporary partial fix I replaced the Reflist template by a non-template version: [3]. At least this currently displays the first 450 of 466 references instead of 0. A real fix will have to avoid exceeding the limit so all references and following templates are expanded. PrimeHunter (talk) 12:40, 17 October 2012 (UTC)
Thank you – it's going to be relatively difficult to manage that large article, but we can do it. –– Anonymouse321 (talk • contribs) 15:40, 17 October 2012 (UTC)
Further comment: It looks like the original editor that brought this up (User:P3Y229 / talk) removed about 46,000 bytes from the page that were already on another page, and the templates are now working. However, the page is still very long. –– Anonymouse321 (talk • contribs) 15:43, 17 October 2012 (UTC)
  • Cite_quick can reduce some or all cites: That article "2011–2012 Egyptian revolution" is one of several which are reaching the template include-size error, plus at times exceeding the 60-second timeout to cause "wp:Wikimedia Foundation error" because {cite_news} or {cite_web} is too slow/large to be used over 350-400 times per page. Another article is "Arab Spring". Currently, new Template:Cite_quick can be used to reduce the size/speed problem, coded as {{cite quick |news|...}}. Months ago, I had tried to resolve those problems (in early July), but there were so many edit-wars, hostile comments, unfounded accusations, or wp:TfD debates, that progress ground almost to a complete halt. Now, 2 of the major opponents are gone from the English Wikipedia, while other editors have come to support progress, and we can again begin to streamline those huge articles. Next year, when the Lua script cites are installed, then the {cite quick|news} usage can be edited to remove "quick|" and use the new, faster Lua-based {cite_news} which seems to run about as fast and small as {cite_quick}. -Wikid77 (talk) 19:25, 17 October 2012 (UTC)
Andy, now you are claiming "almost certainly broken" whereas before you seemed more confident it was "broken" so I guess you have been testing it and realize that it handled all cases as documented. Perhaps you think it is "contentious" because it runs 9x times faster than {cite_web}, but I consider it "conscious" of speed and size problems, because it also runs 2.1x times smaller. -Wikid77 (talk) 20:15, 17 October 2012 (UTC)
Has anyone considered getting rid of the citation templates on these two articles? Just replace the templates with full written-out citations, and you'll suddenly have far fewer transclusions. Nyttend (talk) 13:46, 18 October 2012 (UTC)
That is an option many people dislike, due to the work to rewrite 350-450 tedious footnotes, while knowing the Lua script cites (Spring 2013) will be faster, and people prefer to click the "Cite" button to enter footnotes, and meanwhile, the hand-coding of citations requires prior consensus, per WP:CITEVAR, for drastically different footnote contents. That is why I developed {cite_quick}, as a compromise, to have fast footnotes match the format of wp:CS1 cites, but allow mixture with {cite_web} or {cite_book} from the "Cite" button, and then in 2013, editors can easily unrename each "cite quick" to use the faster Lua cites (same parameters). -Wikid77 (talk) 01:18, 19 October 2012 (UTC)
No it's broken, as others keep pointing out and you keep ignoring. You don't need to look far: simply look at the documentation of {{Cite quick}} and the only side-by-side example there has different text, different HTML to the working example next to it. And that's an example you've constructed yourself: the errors in citations written by others are far worse. No doubt you'll fix this one example now it's been pointed out to you, but as before you'll ignore all the other errors in the template and keep insisting there are no problems with it.--JohnBlackburnewordsdeeds 14:27, 18 October 2012 (UTC)
  • Thanks for comparing results, also used to improve Lua cites: I know you are frustrated to be suggesting improvements, but each example, which you have given, is also used to improve the Lua script cite templates on test2.wiki (with test2:Module:Citation). For example, the prior Lua cites had also incorrectly swapped the url and archiveurl parameters in "Archived from the original". So, your efforts to suggest improvements, to {cite_quick}, are helping to improve the long-term Lua-cite technology as well. I just hope you realize your comments are very much appreciated, anyway. -Wikid77 (talk) 01:18, 19 October 2012 (UTC)

Essay WP:Recheck / WP:Illusion / WP:Pilot

I have created a short WP essay, "WP:Recheck before posting" to explain the need to recheck text, images or templates before posting remarks. After recent comments about Template:Cite_quick, which processes common wp:CS1 template parameters 9x faster than {cite_web}, I have seen the pattern where people mis-read the results and jump to the wrong conclusions. One editor even commented about a "buggy template", but I am a highly experienced computer scientist, and I have never written a "buggy" anything, in over 13 different computer languages. Then, I remembered: the first priority in user complaints or questions is: wp:Recheck the data. So the essay notes, "Are you absolutely sure?" There was a prior incident where people were blaiming a new template used in article "India" but, after 3 weeks, the reality was found to be prior invalid template parameters, not the new template, was the cause of problems; article "India" had a few pre-existing errors long before the new template. Now, when people seem to have misinterpreted the results, then we can ask them to beware a "wp:Illusion" where what they think they see is not the actual reality. The essay also has shortcut WP:PILOT, with a warning about "pilot error" in general. Feel free to revise that essay (WP:RECHECK), to add more situations, or general examples. Then when questions arise, remind other people to wp:Recheck the data. -Wikid77 (talk) 17:26, 17 October 2012 (UTC)

What wrong conclusions did I jump to? --Redrose64 (talk) 19:16, 17 October 2012 (UTC)
I thought you backed your opinions with precise examples, so I think that is fine, even though I prefer not to hide some parameters ("issue=") when a different one is omitted ("journal="). Anyway, the observation of the specific results seemed fine. -Wikid77 20:28, 17 October 2012 (UTC)
Hmmm, wondering why this was so important it ended up in Watchlist notices reading "Please note that a small post-edit confirmation message will be enabled Thursday. [dismiss]" CarolMooreDC 20:56, 17 October 2012 (UTC)
That would be the section two above.Blethering Scot 21:01, 17 October 2012 (UTC)
OK, it probably would help if it started with something like "Regarding Upcoming changes to the edit window (please read) etc" so it wouldn't confuse less technically inclined editors who hope you guys are all doing the right thing :-) CarolMooreDC 21:05, 17 October 2012 (UTC)
The watchlist notice goes to the correct section; but then the lengthy collapsible bits in #Upcoming changes to the edit window (please read) collapse, pulling the rest of the page up; which leaves you looking at the bottom thread (this one). --Redrose64 (talk) 21:53, 17 October 2012 (UTC)
  • Wow, I guess now there are a lot of people notified to wp:Recheck their text, images or templates before posting remarks! Next time, I will beware of posting messages, so close, below a "Notice" thread. -Wikid77 04:59, 18 October 2012 (UTC)

Proof of correctness is transcendental: Yes, but in this case, there are 43 parameters, as 43 "independent variables", and many people do not understand that just testing the parameter combinations is a transcendental problem. In combinatorics, ignoring parameter values, the simple configuration of 43 parameters is 43! (~=6.0415263063373835637355132068514e+52). Even speed-reading 5 test-cases per second, would exceed, by trillions of times, the age of the universe (4.339 ± 0.035 ×1017 seconds). That is why I barely mentioned problems in the current {cite_web} or {cite_journal} templates, because they are also so-called "broken" and cannot be proven ("error-free") by human test-cases, with a staggering 230 parameters, or 230! minimal combinations (~=7.7585e+444). Hence, where mathematical induction fails, I tested {cite_quick} by using logical deduction by re-proofreading the markup logic, with some statistical sampling of test-cases. As a teenager, I had proofread my college textbooks (almost all contained errors), but unaware, during those years, that logical proofreading of source code (or markup) would be faster than running test-cases, except in financial calculations (commercial loan origination), where the numerical values cannot be "proofread" because they vary too much in total range of 18 independent variables, and must be sampled in hundreds of cases, and modules must be duplicated as identical forks in small subsystems, so that changing one module does not require re-running all testcases for weeks, just those cases using one duplicate fork of a common module. Anyway, you get the idea. Sorry to go all Descartes on the epistemology, "Cogito, ergo sum" and all that. However, that is why {cite_quick} works so well. -Wikid77 (talk) 09:03, 18 October 2012 (UTC)

New feature for nav popups: show lead only

Hi all. I recently added a proposal for a new feature of nav popups: show lead only (code included), but the gadget's discussion page seems not to have many watchers. Anyone interested, please provide some feedback here. Thanks! --Waldir talk 00:27, 18 October 2012 (UTC)

  • I thought there was already a pop-up to show an article lede paragraph, and that is why they asked us not to use Template:Convert in the first phrases, but rather hand-code the resulting conversion, such as "Town X is 55 kilometres (34 mi) north-west of London". -Wikid77 05:11, 18 October 2012 (UTC)
    The popup does show the beginning of the article, but currently we can only limit it by number of characters or sentences. This can be different for each user, but will be the same for all articles viewed by that user. The lead has variable size, however, and it would make sense to use the excerpt that authors feel summarizes the topic, rather than arbitrarily displaying a portion of the article with section headers stripped off. --Waldir talk 13:40, 18 October 2012 (UTC)

File:Inkscape 0.48.2.svg not rendering properly at small sizes

These thumbnails of an SVG vector image are not rendering properly. The first one is 250px (renders only the top portion), second one 300px (does not render some objects at the bottom) and the third one is 350px (fully rendered), however, even at 350px and larger sizes, there are some text rendering problems as noted on the image description page. I want to use the image in the Inkscape article and also nominate it for Wikipedia:Featured picture candidates, but this will not be possible without these technical issues being fixed first. See also: http://commons.wikimedia.org/wiki/Commons:Graphics_village_pump#File:Inkscape_0.48.2.svg_-_only_partially_rendered_at_small_sizes_and_some_text_rendering_bugs

Note: Do not fix any of the text rendering bugs by converting them into paths! By doing so, the text cannot be indexed by search engines or translated into other languages (which is important because the file is on Commons), and it will also unnecessarily increase the file size. There should be other alternatives using the <text> and <tspan> tags.

-- jfd34 (talk) 12:21, 18 October 2012 (UTC)

Sounds the ame as #Other users claim non-display of image. ---— Gadget850 (Ed) talk 12:38, 18 October 2012 (UTC)
I don't think that it's exactly the same - at #Other users claim non-display of image I could see the "problem" images just fine, whereas with the three above, I see problems on the first two, just as described by Jfd34 --Redrose64 (talk) 20:52, 18 October 2012 (UTC)
I'm not so sure... I looked at the earlier issue and found an HTML error page being served in place of the image if viewed at certain sizes. In this case, a real image is rendered, but it's incomplete. I won't rule out the possibility that these cases are related, but the symptoms are certainly different. – PartTimeGnome (talk | contribs) 20:55, 18 October 2012 (UTC)
Heh... Looks like I and Redrose64 were thinking something similar at the same time... – PartTimeGnome (talk | contribs) 21:00, 18 October 2012 (UTC)
One more note: the full image is also displayed at very small sizes (110px or less) as shown on the right jfd34 (talk) 10:23, 19 October 2012 (UTC)

View count not from yourself

Repost from the Help Desk

Is there a way to determine the number views of a page not from yourself (views only from other users)? I already know that these page view statistics for this page (the Village pump – technical) show everyone's views, including my views, but I want to know the number of views not including mine. –– Anonymouse321 (talk • contribs) 22:02, 18 October 2012 (UTC)

If we log who views a page, that would have privacy concerns. Your government may well do this, but I don't think that Wikipedia does. --Redrose64 (talk) 23:36, 18 October 2012 (UTC)
No, I meant number of views from other users total. Something like this: Your views:## Other users:## Sorry if I was not clear, but is the answer the same?
The reason I am trying to do this is so I can tell if other users are reading what I have created/edited/etc. –– Anonymouse321 (talk • contribs) 23:46, 18 October 2012 (UTC)
The answer is the same. In order to show correct results to everyone, the identity of every single person who views the page must be logged. That's the only way to separate a user's own views from everyone else and be able to do that for any single user. jcgoble3 (talk) 00:05, 19 October 2012 (UTC)
That's true. I guess that information is not available (or even possible at this point), but Thank you both anyway. –– Anonymouse321 (talk • contribs) 00:16, 19 October 2012 (UTC)
if the number of views of a page is so low that you think your own accesses might be significant then pretty much no one is reading the page. SpinningSpark 10:21, 19 October 2012 (UTC)
  • Read page by edit-preview to avoid pageview counter: When checking to read the latest version of a page, then using an edit, followed by edit-preview, will display the current contents without adding to the stats.grok.se counter. For other pageview statistics, trying edit-preview of a very rare article, during several days, to confirm the edit-preview did not count as a "pageview". I think after an edit is saved, then a pageview is triggered afterward, but not sure. -Wikid77 (talk) 01:01, 20 October 2012 (UTC)

Pop-up box when edit saved

Overnight, a pop-up box with a big green tick saying 'your edit was saved!' appears every time I edit - can I change preferences to get rid of it please? It's quite annoying. Regards, GiantSnowman 09:58, 19 October 2012 (UTC)

See Wikipedia:Village pump (technical)/Archive 105#Small new feature coming on Thursday above. ---— Gadget850 (Ed) talk 10:08, 19 October 2012 (UTC)
I suspected it was linked, but it's TLDR and I just need to know how to turn it off if possible... GiantSnowman 10:11, 19 October 2012 (UTC)
Um, you know that bit above that was formatted like code? Yeah, that's what you need to turn it off - it's even made to stick out so you can find it. --Philosopher Let us reason together. 10:42, 19 October 2012 (UTC)

how to use API (or other means) to determine total number of edits (revisions) to an article

I have been reading through the wikipedia API, which has a very rich featureset, and some nice ways to get up to speed.

Oddly (or perhaps not!) -- I can't see how to get the total number of edits for a page (directly). Have I missed something in the documentation?

Or, conversely, is there perhaps a reason why this question is ill-posed or problematic in either a technical (too hard to answer using the database structure?), scientific ("number of revisions" becomes ill-defined in some important situations?), or policy (knowledge of this might have unintended harmful effects?) sense?

Many thanks for any help,

Simon DeDeo Dedeo sfi (talk) 20:09, 19 October 2012 (UTC)

This tool will do it.--Gilderien Chat|List of good deeds 20:44, 19 October 2012 (UTC)
And ?action=info at the end of the "index.php" URL will return information including number of edits (discussed at #MD5/SHA hash of page version, above). — Richardguk (talk) 20:50, 19 October 2012 (UTC)
Thank you both very much; I had not noticed the development of the comments further up the page on MD5, but this is terrifically helpful, and I'm very grateful. Yours, Dedeo sfi (talk) 23:23, 19 October 2012 (UTC)

Page ratings

I have an issue with the Page ratings feature. I've noticed that the ratings are not reset (set to 0) after an edit. The ratings reflect the readers' opinions of the content on the page at the time of viewing. After the page is edited the content changes, invalidating the previous ratings in the process. This consolidation of ratings across edits conveys a false sense about the content, in my opinion. The true picture regarding the readers' opinions would perhaps be obtained by displaying the ratings for each edit in the "View history" page for an article, for instance. --Winnietpooh (talk) 17:24, 19 October 2012 (UTC)

Then rejoice; they're on their way out over the next couple of months to be replaced by Wikipedia:Article Feedback Tool/Version 5. --Tagishsimon (talk) 17:28, 19 October 2012 (UTC)
mw:Article feedback/FAQ#How are the averages calculated? says: Average ratings for each article are calculated based on an arithmetic average of all the ratings submitted against the last 30 revisions of the article (i.e., all "unexpired" ratings). The idea behind this calculation is to balance the need to reflect changes in the article (e.g., different revisions may have different qualities) with the fact that some articles receive very few ratings. PrimeHunter (talk) 20:50, 19 October 2012 (UTC)
Thank you both for your replies. The information you provided was very useful. --Winnietpooh (talk) 15:26, 20 October 2012 (UTC)

Search for resources

There are various pages where wikipedians can list resources which they are willing to exchange such as (scans of) books, scientific articles, access to online libraries, etc. These resources are listed for instance at Wikipedia:WikiProject_Resource_Exchange/Resource_Request, at project pages or in the user space. So far so good, but when I am looking for a specific book, do I need to look at all those different pages or is there a way to do a single search limited to these resource pages? bamse (talk) 09:46, 20 October 2012 (UTC)

New look?

Is that a new look? At least in my computer pretty much everything (infoboxes etc.) has gained a show-hide template, and also the "talk", "view history" etc. tablets have been "lowered". Also, that line at editing with special characters etc has disappeared too.94.65.35.192 (talk) 11:05, 20 October 2012 (UTC)

I'm having the same situation here. Seems like some massive bug. Toccata quarta (talk) 11:13, 20 October 2012 (UTC)
This is how it's looking to me at the moment - everything squeezed up and I also find I can't highlight the page title (useful for creating links).

Also appear to have lost Charinsert as well. NtheP (talk) 11:13, 20 October 2012 (UTC)
Yikes! Same here (UK) - main page, everything. Ghmyrtle (talk) 11:14, 20 October 2012 (UTC)

Blank pages

Can anyone explain why I can no longer see wikipedia in Internet Explorer? The page flashes up for a brief moment and then blanks. Commons and other language sites are unaffected. I can see the page in Firefox. DrKiernan (talk) 11:07, 20 October 2012 (UTC)

It must be related to my problem (just the post above you).94.65.35.192 (talk) 11:09, 20 October 2012 (UTC)
My two cents (Firefox 16, Windows 7):
Infoboxes are now hidden by default. Please restore.--Ymblanter (talk) 11:13, 20 October 2012 (UTC)
I do not see the citation wizard (or whatever it was called) above the editing window - the one which helped compile the citation. Please return.--Ymblanter (talk) 11:13, 20 October 2012 (UTC)
I think something must have been done to the CSS. I can see pages in Firefox but the formatting is screwed, with the tabs at the top moved up to partially obscure the page title and some templates not displaying. Phil Bridger (talk) 11:15, 20 October 2012 (UTC)
(edit conflict) It looks like this edit was what broke things - it has been reverted now. Is anyone still experiencing issues? — Mr. Stradivarius (have a chat) 11:17, 20 October 2012 (UTC)
Seems to be back now--Ymblanter (talk) 11:17, 20 October 2012 (UTC)
Yup, seems OK to me. Ghmyrtle (talk) 11:18, 20 October 2012 (UTC)
Looks good for me too. Phil Bridger (talk) 11:19, 20 October 2012 (UTC)

Snafu

Actually, it was this edit that broke the site. It messed up some code closures somehow. I completely take responsibility. — Edokter (talk) — 11:26, 20 October 2012 (UTC)

Whack! Regards, — Moe Epsilon 11:45, 20 October 2012 (UTC)

Masses_of_messages_from_Wikimedia_UK_clogging_up_watchlist

Sorry for the crosspost, but wasn't sure the best place to put this. If you might be able to help, please visit MediaWiki_talk:Watchlist-details#Masses_of_messages_from_Wikimedia_UK_clogging_up_watchlist Thanks --Dweller (talk) 18:55, 20 October 2012 (UTC)

Lua cites nearly identical to templates

20 October 2012: The current status of the conversion of {cite_web} and {cite_book} (etc.) to use Lua script, for the Spring 2013 release, is starting to show identical results on test2.wiki (except for the sequence order in the embedded COinS metadata). I am still updating the Lua test2:Module:Citation, to get all the results to match, but it is tedious data-processing chore, at this point. I am planning to re-organize the Lua COinS metadata (in Module:Citation), to match the same order as with enwiki {cite_news} or {cite_journal} (etc.), so then checking the hidden span-tag title (class="Z3988") will be an easier, one-for-one comparison of data items, in the same sequence. I posted this notice, now, to confirm that extensive progress has been made to run these fast Lua-based cites (8x-10x faster than Citation/core-based), soon after Lua is installed on enwiki. Not all 25 cite-template forks, such as {cite video} or {cite_document} (etc.), need to be upgraded when Lua arrives, but the "big 4 cites" (web/news/book & journal) should be upgraded as a top priority, because they will make editing of most major articles 2x-5x faster in edit-preview. I am also checking to see if I can make Lua run even much faster, while the detailed testing of citation formats is helping to pinpoint any differences, during the total rewrite of the whole cite-template design. Meanwhile, updates to the old cite templates should still be implemented, to provide multiple ways to have faster citation templates. -Wikid77 19:50, 20 October 2012 (UTC)

Twinkle is not working

My Twinkle is not working. I am unable to see any twinkle options in any wikipedia page. What version of Java is required for this twinkle to perform normally. I am using Version 6 Update 20. I cannot update it because it is a corporate computer and I have limited permissions. I am using twinkle for about five months and it is still checked under Gadgets. I tried unchecking and rechecking it. Now I am using IE8 andthe OS is Win XP SP3. (It is working in my home PC.) — Preceding unsigned comment added by Jayabharat (talk • contribs) 02:46, 21 October 2012 (UTC)

First, Twinkle runs on JavaScript, not Java. The two are totally different. Second, Twinkle does not work on Internet Explorer 8 or earlier, which is your problem. jcgoble3 (talk) 04:27, 21 October 2012 (UTC)
You can copy-and-paste template code from WP:CSD (for speedy deletion templates) and WP:TM/UTN (for the user warnings and welcome templates) when you can't use Twinkle. Put those links at the top of your user page for easy access, or just bookmark them. PleaseStand (talk) 04:34, 21 October 2012 (UTC)

Invoking a single template by multiple names

Two templates that are forks of a third were recently nominated for deletion. They have survived that process, though the possibility of renomination remains. These three templates are editor typing shortcuts that produce slightly different renderings of the supplied parameters:

{{sclass}}: Valiant-class tugboat
{{sclass2}}: Valiant-class tugboat
{{sclass-}}: Valiant-class tugboat (same as {{sclass}} but for hyphenated article titles)

That nomination discussion led me to wonder about somehow combining them into a single template, even though I argued in the deletion discussion that I saw no real reason why combining them would necessarily be better than three simpler templates.

So I wonder: Is there a way that a template can know the name by which it was invoked? Is it even possible to invoke a template by more than one name? or does redirection prevent a template from receiving the name by which it was invoked. At the risk of over-explaining what I mean, assume that the template is {{sclass}}. If an editor wanted the {{Sclass}} functionality then he would write {{Sclass|Valiant|tugboat}} which would redirect to {{sclass}}. At {{sclass}}, the template would see that the invokation came from the {{Sclass}} redirect and execute accordingly to produce the correct {{Sclass}} output.

Am I making any sense?

—Trappist the monk (talk) 13:20, 18 October 2012 (UTC)

There is no way to know which redirect was used to invoke a template. The usual solution if common template logic is desired is to make a template Template:Sclass/core which takes an extra parameter determining the format, and then instead of being redirects {{sclass}} and so on will call this core template with the input parameters and the appropriate format parameter. Anomie⚔ 15:10, 18 October 2012 (UTC)
Would complicate more if combined: Each of those templates is so bizarre, where just the hand-coded format text would be preferable, so combining unusual templates together is likely to just confuse people even more. In cases like this, we should add more doc-text to the {documentation} section of each template, to at least help explain why those format options 1-2-3-4-5 are needed. No wonder people wanted to delete those templates– and it helps to explain how people have created "millions" of templates, for whatever tiny format option. It would be like creating a template {ody|1}, {ody|2}, {ody|3} which displays "of the day" or "of a day" or "of that day". We do need to have "template regulations" which deter creating those types of templates. -Wikid77 (talk) 00:47, 20 October 2012 (UTC)
"We do need to have "template regulations" which deter creating those types of templates." There is the guideline Wikipedia:Template namespace#Usage, which states, "Templates should not do the work of article content in the main article namespace; instead, place the text directly into the article." It would seem to me that these violate that rule. jcgoble3 (talk) 04:42, 20 October 2012 (UTC)
Although redirect information would not pass though to a common template you could make the other named template a deprecated template and pass through those the parameters plus an additional parameter. See as example Template:WikiProject Ohio. --Traveler100 (talk) 05:21, 20 October 2012 (UTC)

This does seem like an exceedingly stupid template unless the intention is to subst every instance. Actually, someone should probably just run through and subst the whole lot of their transclusions. Although with 16,000 transclusions, there should be a consensus first. Someguy1221 (talk) 05:25, 20 October 2012 (UTC)


I took Editor Anomie's comment to heart and have created a template that combines the three variants. See: {{sclass/sandbox}}, {{sclass2/sandbox}}, {{sclass-/sandbox}}, {{sclass/core/sandbox}}, and {{sclass/core/testcases}}.

More complicated than three simple templates? Yeah, I think so. So complicated that other editors would have problems maintaining it? Probably not – after all, this editor, who freely admits that he doesn't know what he's doing, has managed to somehow make it work. From an editor's point of view, this core-based version is no different from the three independent versions; the editor types the same thing and gets the same result.

Could the documentation be better? Most assuredly. I'll work on that. Helpful comments in that regard welcome.

"Templates should not do the work of article content in the main article namespace; instead, place the text directly into the article." Not sure that I agree with Editor jcgoble3's assertion that that quote applies. If it did apply, then shouldn't all of the {{convert}} and {{citation}}-family templates, to name but two, also be deleted? After all, they only format information that editors provide in a consistently repeatable manner. That consistency and repeatability is good both for the reader and for the editor. The same applies to the {{sclass}}-family of templates. If all of these templates should be substed as Editor Someguy1221 suggests, then shouldn't the {{convert}} and {{citation}} templates also be substed?

—Trappist the monk (talk) 18:17, 20 October 2012 (UTC)

Actually, I have done that at WT:SHIPS TfD notification though perhaps not as clearly as you have.
—Trappist the monk (talk) 14:19, 21 October 2012 (UTC)

Edit Counts Help

I wanted to make a section for User:TruPepitoM/EditCounterOptIn.js but I need to make sure there won't be any malicious content when I make it. Any ideas? Please help. TruPepitoMTalk To Me 05:30, 20 October 2012 (UTC)

As a .js subpage editable only by the subpage owner, there won't be any malicious content unless you add it yourself. →Σσς. (Sigma) 05:34, 20 October 2012 (UTC)
"Unless"? (shudders) TruPepitoMTalk To Me 05:37, 20 October 2012 (UTC)
By the way, WHAT'S the code? TruPepitoMTalk To Me 05:39, 20 October 2012 (UTC)
You just need to create it with some text for the counter to accept it. Nothing you type in will actually load into your interface. Legoktm (talk) 05:40, 20 October 2012 (UTC)
Just add the letter "a" and you'll have no problem, or type "opting in" like I did. Ryan Vesey 05:41, 20 October 2012 (UTC)
 Ryan Vesey's idea helped. Thanks. TruPepitoMTalk To Me 06:22, 20 October 2012 (UTC)
I put mine inside JavaScript comment markers /* ... */ just in case somebody did decide that the page should be executable. --Redrose64 (talk) 14:17, 21 October 2012 (UTC)

Lua not always much faster

I have noticed that Template:Italic_title, which runs {DISPLAYTITLE:...} to show italics in an article title, has been entirely rewritten in Lua on test2.wiki (with test2:Module:Title), but is only slightly faster (10%?) than enwiki {{Italic_title}} (which already runs 1,000 per second), despite the Lua module containing highly complex, intricate features of Lua. Many small templates run 500 per second, and tiny templates can run 2,400/second. So, in many cases, it is just not worth all the complication of orchestrating the Scribunto interface to a Lua pattern-matching module with Lua-encoded "regular expressions", as in this case, where eventually, parser function {DISPLAYTITLE:...} must be run anyway, and consumes about 85% of all processing time. However, in these early months, every working example of a Lua module, performing some well-known Wikipedia operations, can provide valuable lessons to other editors ready to write more Lua source code. And a major lesson in this case: after they wrote a highly-intricate Lua module, which was mind-bogglingly complex for the task, the result was only slightly faster, but could be used to develop some other task. Meanwhile, beware that the vast, vast majority of templates can probably be made "fast-enough" by small changes within them. I think we will see Lua mostly used for very complex tasks, which were never thought possible in templates, such as detecting several grammar errors in text, or other tasks which could use Lua's ability to scan through a string of over 1 million characters of text. More later. -Wikid77 (talk) 19:50, 20 October 2012 (UTC)

  • Tests of {italic title} not adding up: There might be some cache-type shortcut happening or early exit, with tests of enwiki {italic title}, because it should run only about 5x per second (not 1,000/sec.), coded as a template with Template:Str_find, while faster Template:Strfind_short runs over 38 per second, or almost 6x faster than {str_find}. I guess another lesson here: the total timing of template operations is not always easy to measure, when some templates might take a shortcut path to exit faster. -Wikid77 (talk) 22:52, 20 October 2012 (UTC)
  • I think one of the biggest problems (perhaps even the biggest problem) with the current version of Scribunto is a lack of functions designed for processing UTF-8 strings (T41646). This isn't a problem for {{italic title}}, but it is for {{lowercase title}}. Creating a minimal set of such functions (at least the ulen, ulower, and usub functions described at mw:Extension:Scribunto/API specification) would be necessary for using Scribunto on Wikipedia without nullifying any possible performance gain by using existing parser functions for these purposes. PleaseStand (talk) 23:31, 20 October 2012 (UTC)
  • Lua string functions handle diacritics: Currently, the typical accented letters in titles, or other diacritical marks, are processed correctly, and can be searched in strings. The {italic title} shows correctly for:
  • {italic title} for "Anäme Çord Éston (film)" → "Anäme Çord Éston (film)"
  • Searching:   string.find("Anä Ço És ÉéÈèĖėÊêËë", "Êê") ) → matches "Êê".
So, I think we are close to supporting full character sets, in many ways, with the Lua string functions. However, I think using templates with {lc:ABCDEF} to get "abcdef" is fine, and Lua-based templates could be mixed with markup-based templates. -Wikid77 (talk) 17:59, 21 October 2012 (UTC)

Editpage-head-copywarn

editpage-copywarn is controlled by MediaWiki:Wikimedia-copyrightwarning. What MediaWiki message corresponds to editpage-head-copywarn? Thanks. —Lowellian (reply) 21:21, 20 October 2012 (UTC)

That would be editpage-head-copy-warn. By the way, you can see the names of system messages (instead of their contents) by adding ?uselang=qqx or &uselang=qqx at the end of any page's URL. If the message you were looking for were used inside another, the feature would not have helped, yet that will change once 1.21wmf2 is deployed. See mw:Manual:System message#Built-in system messages. PleaseStand (talk) 21:59, 20 October 2012 (UTC)
Why is editpage-head-copywarn tagged by its class attribute when editpage-copywarn, editpage-copywarn2, and editpage-copywarn3 are all tagged by their ID attributes? If there's no good reason for the inconsistency, editpage-head-copywarn should be changed to be tagged by its ID attribute for consistency. —Lowellian (reply) 18:27, 21 October 2012 (UTC)
I believe it was added more recently than the others and thus that may be why the pattern wasn't followed, just an oversight or something, especially if someone new was adding it, as there doesn't appear to be any practical reason for it. Whatever the case you can search for or file a bug about this, but as concerns go this isn't a technically major one. -— Isarra ༆ 19:29, 21 October 2012 (UTC)

Restoring dismissed watchlist notices?

Please see question at Wikipedia talk:Watchlist notices#Restoring dismissed watchlist notices?. --Redrose64 (talk) 15:23, 21 October 2012 (UTC)

Thanks, closed there. --Lexein (talk) 19:48, 21 October 2012 (UTC)

Alt-text for text

Just a thought that occurred to me the other day reading an article. More and more technical articles are using more and more acronyms. They may be defined once near the beginning, but if the page is 60kB long it gets really boring going up and down. It would be great is we were able to insert alternate text for the acronyms from time to time in the articles. I tried a couple of work arounds/hacks. You can make a red link to the non-existent page, but that could be a problem if there just happens to be a page that matches the acronym. A blank image works, but very limited in scope, and not good for server time, I'm sure. My first thought would be identical to a Wiki-link but with alt= or perhaps quotes to distinguish it from a page link. Example --  :- ) Don 18:26, 21 October 2012 (UTC)

{{abbr}} does this, for example {{abbr|abbr|abbreviation}} → abbr. --Redrose64 (talk) 18:59, 21 October 2012 (UTC)
That should work, and it doesn't display as a link. Even better. I will try it. Thanks. -- :- ) Don 20:24, 21 October 2012 (UTC)

Wikimedia Public Domain Only Button

Hi, Searched and didn't see an idea to add a prominent "public domain materials only" button to the Wikimedia site. It would be a great addition to the site. I understand I can put "public" in the search box to achieve this, but the status quo misses out on at least three benefits: 1) easier for user, 2) would help to discourage re-posting of copywritten material, and 3) would encourage content owners to go public (since their content would become less likely to be viewed with the change). Thanks for considering, Mark — Preceding unsigned comment added by 142.129.137.118 (talk • contribs) 18:40, 21 October 2012 (UTC)

Where did you think the button should go and why? Almost nothing on Wikipedia is in the public domain, with the most common exceptions being very old images. Someguy1221 (talk) 21:38, 21 October 2012 (UTC)

Infobox trouble

When looking up any random article, infoboxen aren't shown up as floats at the right as usual, but are instead inserted in the text as non-floats without a white background. Examples: GIMP, Songs from The Screen, Vasile Maftei. I suspect something's up with Template:Infobox, or maybe some JavaScript is removing the style from Template:Infobox. What's happening? Rursus dixit. (mbork3!) 20:02, 21 October 2012 (UTC)

Oddly enough, the problem is only visible on the non-secure server, not on the secure. I'll try to logout and login to see what happens. Rursus dixit. (mbork3!) 20:19, 21 October 2012 (UTC)
Problem solved by myself: something in my browser cache went weird, for some unknown reason. Solution: Wikipedia:Bypass_your_cache, in my Mozilla-case Ctrl-Shift-R. Rursus dixit. (mbork3!) 20:23, 21 October 2012 (UTC)

How do I put the same message on several hundred user talk pages?

Hi.

At Wikimedia Medicine we want to send a notice to all members of Wikiproject Medicine (listed here). I believe there's an automated way of doing that. Could someone please point me to it? --Anthonyhcole (talk) 04:55, 22 October 2012 (UTC)

User:EdwardsBot, operated by User:MZMcBride. --Jayron32 04:59, 22 October 2012 (UTC)
Thank you! --Anthonyhcole (talk) 05:01, 22 October 2012 (UTC)

Article feedback watchlist sort order

I originally posted this under Making it easier to clean up the Feedback Dashboard. However, article feedback is not related to the feedback dashboard, so I've separated this into a separate section. – PartTimeGnome (talk | contribs) 16:17, 13 October 2012 (UTC)

I guess this would be related to why I saw the initial sort order of my feedback watchlist switch from ordered by date to ordered by "relevance" last night. Was this intentional? For a watchlist, sorting by date makes more sense. The relevance sort seems to be pretty random order. – PartTimeGnome (talk | contribs) 23:05, 12 October 2012 (UTC)
This feature has nothing to do with the Article Feedback Tool or the related watchlist. These are comments asking for general help, from new registered editors only, viewable at Special:FeedbackDashboard. Perhaps we need a name change to make this less confusing... Steven Walling (WMF) • talk 07:57, 13 October 2012 (UTC)
My apologies; there are so many different uses of "feedback" at Wikipedia that I got a little mixed up. Perhaps the feedback dashboard could be called "New editor feedback" to make it distinct from article feedback?
My initial confusion aside, I'm still wondering why the default sort order changed, since order by date makes more sense for a watchlist. (I'm really not sure when order by "relevance" would ever make sense.) I've now figured out that I can get the original behaviour back by appending "?filter=comment" to the URL, and have updated my bookmarks accordingly. Ideally, this should be the default; if anyone wants the new behaviour, a user preference would be friendlier than having editors hack the URL. – PartTimeGnome (talk | contribs) 16:17, 13 October 2012 (UTC)
Oh well... mw:Thread:Talk:Feedback Dashboard/ArticleFeedback and MoodBar dashboard names. Helder 19:46, 15 October 2012 (UTC)
I'm having the same problem with https://wiki.riteme.site/wiki/Special:ArticleFeedbackv5Watchlist?ref=watchlist - some times it sorts by Newest (which I want), but sometimes it sorts by Relevance (which is not helpful to me). I don't really care what the default (although I think Newest is more consistent with my watchlist) I just wish it would remember my settings (cookie or in my preferences). Mitch Ames (talk) 09:24, 22 October 2012 (UTC)
I haven't noticed any specific trigger.
  • It forgets perhaps every few days or so - I usually check my watchlist and the feedback at least once a day (often more)
  • I am normally logged in ("Remember me" is ticked), so I don't explicitly login each time. I typically close the browser (Firefox 12.0) between sessions, but typically don't log off my computer (Windows 7)
  • I just rebooted my PC now, and when I check the feedback list it was sorted newest first (ie no problem)
  • I also just logged out of Wikipedia and then back in, and the feedback list was still sorted newest first
  • I couldn't swear to it, but I think the problem does not only occur if I clear browser cookies. Occasionally I clear browser cookies using CCleaner, but it has wikipedia and wikimedia listed as "cookies to keep". If the wikipedia/wikimedia cookies are cleared I'd notice because I'd have to log in.
I'll try to note if there's anything out of the ordinary next time it does forget.
Where is the setting stored anyway - is it a cookie? Mitch Ames (talk) 12:50, 23 October 2012 (UTC)
It is - it'd be much more sensible for us to just switch over to using a "hidden" preference of some sort. I'll see what I can do. Okeyes (WMF) (talk) 17:11, 23 October 2012 (UTC)

Turning the CharInsert gadget off by default

As many of you are probably aware by now, the character insertion toolbar at the bottom of the edit interface was recently moved into a gadget. There has been some consensus established that perhaps it should be turned off by default, but the discussion was not exactly conclusive, and nor does there appear to be any good way to do this without affecting current users' preferences, as changing an existing gadget's default from on to off turns the gadget off in everyone's preferences, including those who were using it already and even those who had previously explicitly turned it on.

Does anyone know of a good solution to this? Perhaps an appropriate warning before turning it off, or not turning it off at all for the time being, or maybe changing the Gadgets extension so that changing a default doesn't affect existing preferences and if an admin really does want to reset everyone's preferences, uninstalling the gadget entirely and then reinstalling it would be required? -— Isarra ༆ 19:40, 21 October 2012 (UTC)

I think a new (default off) gadget would have to be created, and the old (default on) gadget would have to be deprecated. The two would have to be designed to not interfere with each other; I would make the old gadget load the new one (using mw.loader.load()) in addition to displaying a notice of the change. PleaseStand (talk) 09:12, 22 October 2012 (UTC)
Aye, I suppose that could work, though it would be messy. Would also need to add a createpage requirement so it would only show up for registered users the duration of the transition, but that would be doable... -— Isarra ༆ 15:15, 22 October 2012 (UTC)

Problem with edit conflicts

Tracked in Phabricator
Task T43280

On en.wiktionary, we have a problem with edit conflicts. If you edit a section of a page and an edit conflict occurs, the bottom textarea will only contain the section you edited. If you copy-paste that into the top textarea, you will actually delete the entire page except for the section you were editing. This worked fine before, so there seems to have been a regression. Is this known, and if yes, will it be fixed? -- Liliana-60 (talk) 22:43, 21 October 2012 (UTC)

It has always been like that. The top one contains the 'current' (with the edit made at the time between you opening your edit window and saving your edit) and the bottom dialog contains the state as you had desired to save it (but is not possible because an edit conflict occurred). —TheDJ (talk • contribs) 08:53, 22 October 2012 (UTC)
In such situations, English Wiktionary uses the default system message:
'Someone else has changed this page since you started editing it. The upper text area contains the page text as it currently exists. Your changes are shown in the lower text area. You will have to merge your changes into the existing text. Only the text in the upper text area will be saved when you press "Save page".'
Note particularly the fourth sentence 'You will have to merge your changes into the existing text.'
Something very similar appears in MediaWiki:Explainconflict, which is the equivalent message customised for use on English Wikipedia. This (to my mind) has a better explanation of what to do about it (the four numbered items at the bottom). ---Redrose64 (talk) 13:16, 22 October 2012 (UTC)
No, it has never been like that. It used to show the entire page in your textbox, and not just the section you edited. With the way it is now, we've had it happen very often that users inadvertently deleted the entire page like this. The folks at Commons are having the same problems. It seems to work just fine in German Wikipedia, so some server configuration must be wrong. -- Liliana-60 (talk) 18:11, 22 October 2012 (UTC)
Thanks everybody. I've forwarded this into the issue tracker at https://bugzilla.wikimedia.org/show_bug.cgi?id=41280 --Malyacko (talk) 21:18, 22 October 2012 (UTC)
It looks like a bug to me. I am looking in to this now . Will try to get this fixed shortly and deployed soon as possible. Cheers. --Aude (talk) 07:40, 23 October 2012 (UTC)
This is fixed [4] but awaits approval and deployment by one of the lead developers, probably when SF people wake up in several hours. --Aude (talk) 09:58, 23 October 2012 (UTC)

Counting usage of templates parameters

Hello, is there any way, any tool or whatever to find out how many times is a specific parameter of a selected template in use or if at all, please? I've searched both Wikipedia and Toolserver but I've failed.

For example, a template "Template1" has a parameter "Parameter1" and it's transcluded in three articles. I'm not interested in substitutions. In first and second one the parameter is used, in third it's not.

  • First article: {{Template1|Parameter1}}
  • Second article: {{Template1|Parameter1}}
  • Third article: {{Template1}}

So the number I'm looking for is 2 as the Parameter1 is used in 2 articles. Thank you in advance! --Loupeznik (talk) 23:37, 21 October 2012 (UTC)

About the only way is to have the template add the page to a tracking category when "Parameter1" is used. Anomie⚔ 03:25, 22 October 2012 (UTC)
You need more, maybe example code? -DePiep (talk) 19:14, 23 October 2012 (UTC)

using API to get time-line of page protection status

Is it possible to use the API (or some other means) to get a time-line of page protection?

I've been told that the Protection Log is only partly reliable, since users had to record their actions "by hand" in some cases.

For example, is there a way to formulate an API query to say "give me a history of page protection actions on George W. Bush"? Do we know how far back that history goes? (e.g., I have been told that "more ancient" protections may not have been logged at all, or only manually.)

Thank you for any help you might be able to provide.

Sincerely,

Simon DeDeo Dedeo sfi (talk) 18:00, 22 October 2012 (UTC)

The old protection log wasn't created manually; the only major difference between the old logs and the new ones are that the former were placed on Wikipedia namespace pages by the software while the latter were not. The old protection log was created in November 2003. Older protections, back to March 2003, can be found in the history of Wikipedia:Lists of protected pages (then Wikipedia:Protected page); that page was indeed updated by hand. Graham87 07:04, 23 October 2012 (UTC)
Thank you, Graham87. When (for example) the old protection log says "23:05, 15 May 2004 MykReeve protected Flag of Lithuanian SSR" is there a (automatic) way to determine whether this was move protection, or edit protection, or both? My understanding is that semi-protection was introduced on 12/2005 (which is also when the log becomes more explicit about what is happening and things become reasonably simple to work with.) Dedeo sfi (talk) 20:35, 23 October 2012 (UTC)
As far as I can tell, move-protection was introduced sometime before the end of 2004 (see the bottom of [5]), but there's no way of automatically identifying when it was used. --Carnildo (talk) 00:37, 24 October 2012 (UTC)
Based on Wikipedia_talk:Lists_of_protected_pages/Archive_2#Protection_against_page_moves, it appears that move-protection was introduced in December 2004. jcgoble3 (talk) 01:00, 24 October 2012 (UTC)
Indeed; it was introduced at the same time as the modern logs that use special pages. Both were new features of MediaWiki 1.4, which was deployed to the English Wikipedia on 23 December 2004 (UTC). Graham87 05:43, 24 October 2012 (UTC)         

script problems...

Hi, I am having problems with my script at User:Mdann52/common.js (Basically a dump of various scripts I've found!) The only way I've managed to do to make any of it work it to add no wiki tags to it. Any advice?? Mdann52 (talk) 19:13, 22 October 2012 (UTC)

<nowiki> tags just make the entire user JS page invalid, disabling everything. Perhaps you could instead remove all the duplicate entries, scripts that are of no use for anyone but admins, and scripts you can add as Gadgets (see diff). After doing that, install one script at a time, so that if any script causes problems, you know which one it is.
You also should not install any scripts you have no particular use for. This is especially true for the linkclassifier script, as it makes tons of non-cacheable API requests (and your installation of that script was incomplete anyway – see User:Anomie/linkclassifier).
Also, each user script you install puts you at risk for compromise of your Wikipedia account. As little knowledge as I have of computer hacking techniques, I know a definite way, possible partly because of the widespread use of user scripts, in which I could compromise the accounts of Wikipedia administrators, bureaucrats, checkusers, and oversighters in a manner that leaves little or no public evidence. However, of course I'm not going to. (Then again, can you really trust me?) PleaseStand (talk) 22:47, 22 October 2012 (UTC)
(I, for one, welcome our new javascript overlord. — Richardguk (talk) 22:55, 22 October 2012 (UTC))
My advice would be to stop making a somewhat random collection of all kinds of scripts and start trying to actually use the scripts, one by one. When you've figured out which ones you like to use you can try combining them, some are incompatible with others. I would recommend giving AWB a spin BTW. Have fun! They (talk) 22:59, 22 October 2012 (UTC)
Seconded. If you don't know when you are doing, it's better to stay away from them and limit yourself to gadgets. When you do use scripts, use them one by one, slowly building your collection and try to learn a bit about the basics of JS while you are extending your usage of them. —TheDJ (talk • contribs) 08:33, 23 October 2012 (UTC)
 Done Thanks for the advice :) Mdann52 (talk) 08:39, 23 October 2012 (UTC)

Strikethrough and the digit 4: font selection issue?

In reviewing edits made today, for well publicised reasons, to List of career achievements by Lance Armstrong, I though that whoever had stricken his Grand Tour record had overlooked the 1998 Vuelta. But no: the positioning of the strikethrough and the shape of the digit 4 are such that they co-incide almost perfectly. Compare the output of <s>4</s>, 4, with 4, the unadorned digit. It is obviously an issue that will only arise very occasionally, but is there a simple solution available, like raising the strikethrough a few pixels? Could it at least be logged for raising as an issue if the default font is ever under review. Kevin McE (talk) 20:23, 22 October 2012 (UTC)

Trivial and unimportant. Laughably so. There is bound to be other digits either side which will show the whole thing is struckthrough, and even if not, there should be additional text to provide explanation/context. doktorb wordsdeeds 20:29, 22 October 2012 (UTC)
I've acknowledged that it is a rare issue, and your comment about context makes it evident that you haven't bothered to review the issue in situ. I merely asked whether there is a low impact solution and that it be noted as a minor issue that might be borne in mind if there is a wider review. So why the extraordinarily rude tone of your reply? Kevin McE (talk) 20:54, 22 October 2012 (UTC)
You could strike surrounding spaces like  4 , or thin spaces like  4 . PrimeHunter (talk) 20:50, 22 October 2012 (UTC)
Thank you: ininitely more constructive than what preceded it. Kevin McE (talk) 20:54, 22 October 2012 (UTC)
The strikethrough position is browser-dependent; and in any case, the position of the horizontal line in the figure 4 is not consistent between fonts. Both of these can ultimately only be set at the client end, not here. --Redrose64 (talk) 21:03, 22 October 2012 (UTC)
On another point, <s> is now obsolete; you can use {{strikethrough}}, but that won't change the appearance. ---— Gadget850 (Ed) talk 16:10, 23 October 2012 (UTC)
<s> isn't obsolete - <strike> is though. Don't know why they should be treated differently, since both were deprecated in HTML 4.01. --Redrose64 (talk) 20:36, 23 October 2012 (UTC)

Insert feature back at bottom of edit window; thanks!

Many thanks to whoever restored the insert panel (with wiki markup and lots of other useful stuff—think it's called "Edittools" or similar) at the bottom of the edit window. While I was slowly learning to live without it, having it back makes my WP life much easier. All the best, Miniapolis (talk) 02:21, 23 October 2012 (UTC)

I too am glad that it is back. However, I notice that it is slightly narrower in Chrome than the edit box and grey box below. Minor quibble, but it is back. Chris857 (talk) 02:30, 23 October 2012 (UTC)
Actually, it's the editor and gray box that is too wide I believe. This has been a known issue for a while, though I can't find the ticket right now. —TheDJ (talk • contribs) 08:41, 23 October 2012 (UTC)

+1. Jenks24 (talk) 16:16, 23 October 2012 (UTC)

Resolved

Next the message that says "Remember that this is only a preview; your changes have not yet been saved!", there used to be a link that said "Continue editing", but it no longer appears. This was a very useful feature that was especially important in large articles – it allowed us to get to the edit box without having to scroll through all the content. Why did it disappear?

Safari 6.0.1 on OS X 10.8.2

–– Anonymouse321 (talk • contribs) 04:01, 23 October 2012 (UTC)

Huh, me too. Never noticed it was gone. I've got Safari 5.1.7 on OS X 10.6.8. David1217 What I've done 04:16, 23 October 2012 (UTC)
It's apparently supposed to come from MediaWiki:Continue-editing. I don't know why it's missing. It was removed from MediaWiki:Previewnote in [6]. We could get it back by reverting that edit but it might suddenly cause a duplicate if MediaWiki:Continue-editing is displayed. PrimeHunter (talk) 04:29, 23 October 2012 (UTC)
Fixed [7] and expect it to be deployed later today. --Aude (talk) 12:00, 23 October 2012 (UTC)
 Fixed Looks fixed to me! Thank you –– Anonymouse321 (talk • contribs) 16:04, 23 October 2012 (UTC)

While on discussion of this feature, there is a pending change [8] in wording of the "continue editing" link to "'Go to editing area". Of course, English Wikipedia can override that if wanted, but is the new, proposed wording good? Cheers. --Aude (talk) 19:29, 23 October 2012 (UTC)

  1. Support – It's good to clarify what that link does. –– Anonymouse321 (talk • contribs) 20:08, 23 October 2012 (UTC)

About Template

In the Template:Finance links you would see an Eg. of a company, their if u click the "Hoover's" link you would find nothing except it says "Page Not Found". Something is wrong either we modify the url or "hoover" has to be replaced by other. I think the new page doesn't really provide enough information to bother having such links at all, and we should probably simply remove support for Hoover's from finance links entirely. Instead we should put Bloomberg Businessweek or MSN Money link in the template. Could you please do that it would be really helpful.--♥ Kkm010 ♥ ♪ Talk ♪ ߷ ♀ Contribs ♀ 04:36, 23 October 2012 (UTC)

"Business data" at General Electric#Video clips has an example with a currently dead link to http://www.hoovers.com//--ID__10634--/free-co-factsheet.xhtml. Here is how it once looked: http://web.archive.org/web/20070929133424/http://www.hoovers.com//--ID__10634--/free-co-factsheet.xhtml. The corresponding free page today is apparently http://www.hoovers.com/company-information/cs/company-profile.General_Electric_Company.8e594783fd3e6c6e.html. Wikipedia talk:WikiProject Companies would be a better place to discuss which links should be in the template. If Hoover's is kept then both the template and all calls of the template with the hoovers parameter would probably have to be changed. PrimeHunter (talk) 05:17, 23 October 2012 (UTC)
I would say "hoovers" should be removed completely, since it doesn't provide enough information about a company. And replace with either Bloomberg Businessweek or MSN Money providing correct link. As far as companies which have "business data" its not going to be a big problem, overtime hoover link shall be replaced either by bot or some other editors.--♥ Kkm010 ♥ ♪ Talk ♪ ߷ ♀ Contribs ♀ 10:51, 23 October 2012 (UTC)

"Cite" does not automatically insert date retrieved

When using the "cite" button, the access date is automatically filled in for "web" and "news" items, but not for "book" and "journal" items. I got so used to it being automatically filled in, that I am unwittingly omitting it when I cite a book or journal. Is there some reason for this or is it a bug? --MelanieN (talk) 10:03, 23 October 2012 (UTC)

"Access date" is only for online sources because they can go dead or change content. Books and journals are often offline and shouldn't have an access date in those cases. I guess you have disabled "Enable enhanced editing toolbar" at Special:Preferences#mw-prefsection-editing. I have it enabled and don't get an automatically filled access date for any of the citation templates but there is an icon to insert current day, except for Cite book which has no field for access date in that toolbar. PrimeHunter (talk) 12:36, 23 October 2012 (UTC)
OIC. So it's not a mistake - they meant to do it that way and it's OK. ("It's not a bug, it's a feature.") Thanks for the explanation. --MelanieN (talk) 18:29, 23 October 2012 (UTC)

Tech help needed at another thread

Hi, at [9] an argument is being made that saving bytes in the database (by reducing article size) is a good reason for creating dozens of templates, and shunting bits of article content into those. Though there may be other reasons for creating the tenplates in question, I think the space-saving one is nonsense (the gains, within the context of Wikipedis as a whole, being utterly minuscule and irrelevant). Assuming I'm right, it would be beneficial for someone with technical expertise to knock that idea on the head once and for all in that thread, as it doesn't seem to be going away. Also, the question was raised at that thread as to whether Wikipedia saves a complete copy of a page every time a change is made, even if only one byte. I have said I think it does, but again perhaps a techie person could confirm or correct that at the aforementioned thread. 86.160.208.15 (talk) 17:28, 23 October 2012 (UTC)

Anybody know the coding to restore the old wiki logo?♦ Dr. ☠ Blofeld 19:09, 23 October 2012 (UTC)

If you just need it to work for one person on one computer with one browser you could do a dirty CSS hack like:
<div style="position:absolute !important; left:-170px; top:-123px; z-index:1436;"> [[File:Wiki_logo_Nupedia.jpg]]</div>
Javascript is a cleaner but slower solution. They (talk) 21:48, 23 October 2012 (UTC)
Or maybe you want another old logo at Wikipedia:Wikipedia logos. PrimeHunter (talk) 22:50, 23 October 2012 (UTC)

page editing problems

Advice and help are needed here regarding a page that uses dozens of (cite book) templates. Any and all help would be greatly appreciated and is urgently needed. Thanx, -- Gwillhickers (talk) 20:05, 23 October 2012 (UTC)

need some carpentry done on a table

We've been discussing a mass article merger at Wikipedia talk:WikiProject Lego. Participation was not what I had hoped for but I believe it was sufficient to say there is a consensus to perform the merges. What would be involved would be taking about 65 articles and merging them into one big sortable table, or possibly two or three if it seems to large for one page. I have no idea how to make sortable tables and from the looks of it neither does anyone else involved Inthe discussion. Posting here in the hope that there is somebody who can at least help us get started with doing this. any help appreciated. Thanks. Beeblebrox (talk) 20:32, 23 October 2012 (UTC)

Follow the pattern shown in the example at Help:Table#Sorting. --Tagishsimon (talk) 20:36, 23 October 2012 (UTC)

I'm just wondering if a "Print Edition" could me created for some pages, as sometimes it may be helpful to have the option of printing out the information (eg the rules to a game, like Four Square http://wiki.riteme.site/wiki/Four_square) so that you take the information somewhere else, in order to put it to use? — Preceding unsigned comment added by Axeliz (talk • contribs) 23:29, 23 October 2012 (UTC)

See Help:Printable. They (talk) 23:49, 23 October 2012 (UTC)
See also the Book Creator. Now you can compile a games compendium. --Tagishsimon (talk) 00:13, 24 October 2012 (UTC)
The user also asked this question at Wikipedia:Help desk#Print Edition. PleaseStand (talk) 00:47, 24 October 2012 (UTC)

New mobile site design

The WMF mobile and design teams have just released some design improvements to the Wikipedia mobile gateway. Included in the release are a new navigation and language selection system, as well as improved typography and spacing for better readability. Check it out and let us know what you think!

You can also now opt in to the Beta mobile site, a testing ground for experimental features, directly from the mobile site settings – if you're interested in keeping up with and testing out new editor-focused features as they're built and prototyped, please sign up for the mobile Beta testing team and help us make the mobile Wikipedia experience better for you. Maryana (WMF) (talk) 03:36, 24 October 2012 (UTC)

Tell when someone is editing a page?

Per a question at Wikipedia talk:Page Curation#Could the tool detect if some one else is editing the article?, is there any way to program a tool to know if somebody has the edit window open for a page? Ryan Vesey 14:36, 22 October 2012 (UTC)

You could let browsers with JavaScript 'ping back' at regular intervals to some api (has some potential privacy issues) but not impossible. In theory we could do it with the toolserver and a default gadget, though doing it in core+extension would be preferred. Of course it would never provide more than an 'indication', you should never overly rely on information like this. (ppl might have JS disabled or leave the window open while they go on a vacation). —TheDJ (talk • contribs) 14:56, 22 October 2012 (UTC)
Could the indicator disable itself if the person hadn't typed anything in five minutes, say? David1217 What I've done 22:15, 24 October 2012 (UTC)

"containing..." goes straight to matching page

Resolved
Tracked in Phabricator
Task T43292

Clicking "containing..." in the drop-down box below the search box is supposed to always give a search results page. I currently go straight to a matching page name in all five tested browsers and all tested searches, for example on "cat" in Firefox. It doesn't matter whether I'm logged in. I can only get a search results page by first making a blank or non-matching search and then use the second search box in the search page http://wiki.riteme.site/w/index.php?search=&title=Special%3ASearch. PrimeHunter (talk) 00:23, 23 October 2012 (UTC)

Yes, I can reproduce this issue. There've been some JavaScript changes to the search box recently and this may be further fallout. We'll investigate. Eloquence* 01:55, 23 October 2012 (UTC)
This issue should be fixed now. PleaseStand (talk) 06:52, 23 October 2012 (UTC)
Thanks very much for the fix, PleaseStand. :-) --Eloquence* 07:27, 24 October 2012 (UTC)

Problem with "Africville" article

I do not understand why it is impossible (at least for me) to reach the history of the Africville article. When I click on that tab, I get this error message:

[2d33bdbf] 2012-10-23 01:32:33: Fatal exception of type MWException

This has been going on all day. I have not encountered a similar problem with any other article. Can anyone fix it?Kelisi (talk) 01:37, 23 October 2012 (UTC)

It works for me. I get the url http://wiki.riteme.site/w/index.php?title=Africville&action=history. PrimeHunter (talk) 01:58, 23 October 2012 (UTC)
Nope! That link still gives me the error message. What's going on? Why does it only happen with this article? Kelisi (talk) 02:01, 23 October 2012 (UTC)
After you get to that page with the error, what happens if you WP:BYPASS your cache? (essentially hard refresh the page) Chris857 (talk) 02:17, 23 October 2012 (UTC)
Or what about another url like http://wiki.riteme.site/w/index.php?title=Africville&offset=&limit=50&action=history? PrimeHunter (talk) 02:25, 23 October 2012 (UTC)
Refreshing does no good. Using the "action-purge" parameter does no good. However, PrimeHunter's link does it. I have also just discovered that I can reach the history of the Africville article if I log out, but once I log in again, it's back to the old problem. Is it something to do with my account? Kelisi (talk) 04:31, 23 October 2012 (UTC)
Have you cleared the entire cache as described in WP:BYPASS? PrimeHunter (talk) 04:51, 23 October 2012 (UTC)
I have just tried reloading, and also reloading and bypassing the cache, as laid out in the instructions for my browser (Google Chrome, by the way). Nope, the problem still persists. Kelisi (talk) 16:23, 23 October 2012 (UTC)
And now I have just tried clearing the cache, and still the problem persists. Kelisi (talk) 16:29, 23 October 2012 (UTC)
I'm not quite sure why you are getting the error. Can you view the history while logged out? what about in another browser? --Aude (talk) 08:59, 24 October 2012 (UTC)
I'm using Google Chrome and have discovered that I can reach History only if I log out. I have just tried Internet Explorer and have found that I get the same kind of error message there, until I log out, and then there's no problem. What am I to make of that? Kelisi (talk) 00:27, 25 October 2012 (UTC)

French language error messages

Tracked in Phabricator
Task T41094
Moved from WT:VPT § French language error messages

On this version of Femen france, the author entered references with <ref>...</ref> tags, but neglected to include a reflist. The normal error message that would occur on such a page is:

Cite error: There are <ref> tags on this page, but the references will not show without a {{Reflist}} template or <references/> tag; see the help page.

but on this page, the error was rendered as:

Erreur de référence : Des balises <ref> existent, mais aucune balise <references/> n’a été trouvée.

Why would the reference error message show up in French? WikiDan61ChatMe!ReadMe!! 20:11, 23 October 2012 (UTC)

Huh! The problem seems to have cleared itself up. Some glitch! WikiDan61ChatMe!ReadMe!! 20:11, 23 October 2012 (UTC)
This happens when an somebody whose Preferences → User profile → language is not set to en - English makes an edit following which an error situation exists. When this happens, the non-English message is stored in the cached copy of the page, and the fix (assuming that your own language setting is English) is to either edit the page or WP:PURGE it. --Redrose64 (talk) 22:02, 23 October 2012 (UTC) amended Redrose64 (talk) 13:52, 24 October 2012 (UTC)
Yup a known issue. —TheDJ (talk • contribs) 08:27, 24 October 2012 (UTC)

Apparent bug causing massive text loss when saving

Tracked in Phabricator
Task T43352

{{tracked|41280}}

There appears to be a new bug that sometimes causes massive loss of text when attempting to save a page, without any apparent error on the part of the editor. See this page history and this page history for examples. This is the same problem reported above in the section titled #page editing problems. Looie496 (talk) 22:41, 23 October 2012 (UTC)

According to this discussion, there has been a Bugzilla report filed about it. --Tryptofish (talk) 23:23, 23 October 2012 (UTC)
This is a serious bug – I have seen at least 7 instances today alone in various places, including this page. –– Anonymouse321 (talk • contribs) 00:31, 24 October 2012 (UTC)
From the discussion referred to: Bugzilla:41280. — Richardguk (talk) 00:52, 24 October 2012 (UTC)
It should be fixed now and the fix deployed some ~12 hours ago. If anyone still sees anywhere that this still happens, please report it here (ideally with some details of what you were doing / how it happened). I'll be checking here. [btw, edit conflict when saving this and it looks like it works correctly :)]--Aude (talk) 08:32, 24 October 2012 (UTC)
@Aude#[btw]: Didn't the software previously avoid most edit conflicts by automatically merging simultaneous edits to different sections? I think there may be a more subtle ongoing regression. — Richardguk (talk) 10:34, 24 October 2012 (UTC)
Hmm.... I can poke at the code more and try to figure that out. --Aude (talk) 12:22, 24 October 2012 (UTC)
Here's one which occurred this morning, after Aude's message. That wasn't mine; but yesterday, whilst attempting to save this edit, I got an e/c - so I followed my usual policy in such situations:
  1. copy my text to clipboard;
  2. use the "back" button to return to the normal page view;
  3. go for the section's [edit] link again in order to get a fresh session ID
  4. paste in my text and hit "Save page"
This triggered a second e/c, so I did steps 2-4 again, and it saved. I then checked the page history to see whether somebody had been editing the same section as me, or editing the whole page - but they weren't: every edit for the previous fifteen minutes (longer than I had been typing) was to a different section. --Redrose64 (talk) 13:46, 24 October 2012 (UTC)
Okay, thanks for reporting this. Looking into this now. --Aude (talk) 13:54, 24 October 2012 (UTC)
Here is one just now, looks like the same issue. Was editing just the last section. Didn't click preview, if that matters. —  HELLKNOWZ  ▎TALK 17:22, 24 October 2012 (UTC)
Ironically, another editor reported finding this bug, and, in so doing, almost blanked the page. Reaper Eternal (talk) 18:01, 24 October 2012 (UTC)
Yea, it was this edit that I wanted to report—cyberpower OfflineTrick or Treat 18:10, 24 October 2012 (UTC)
here is another one that happened earlier today, well after the supposed fix which Aude indicates should have happened at approximately 20:30 23 October. This one is some time after that. I didn't even know I had done this, until someone pointed it out and fixed it. --Jayron32 18:06, 24 October 2012 (UTC)
Thanks everyone for reporting and the details. I was able to reproduce this on my test wiki so hope a fix is along shortly. --Aude (talk) 18:48, 24 October 2012 (UTC)
I've found that it's not confined to logged-in users - anons do it too, see here. --Redrose64 (talk) 19:01, 24 October 2012 (UTC)
And on the main page. Resolute 20:17, 24 October 2012 (UTC)
As Redrose has said, I have noticed, upon awareness of this issue, several instances of right after IPs making an edit, an article is blanked like here. SassyLilNugget (talk) 20:21, 24 October 2012 (UTC)
Here's a report at ANI. • Jesse V.(talk) 20:27, 24 October 2012 (UTC)
Okay, I think this fixes it and expect it to be deployed in a few minutes. Sorry about the problem and not being able to fix it quicker. :( Cheers. --Aude (talk) 20:39, 24 October 2012 (UTC)

New image parsing functions?

I recently noticed that the images no longer parse grainy on my retina display for my iPad. Software update? It looks really good. Now we just need a higher quality Wikipedia logo to make retina display friendly.—cyberpower OfflineTrick or Treat 11:26, 24 October 2012 (UTC)

You can thank Brion Vibber who added support for that. —TheDJ (talk • contribs) 11:47, 24 October 2012 (UTC)
Give him my thanks. It looks amazing. Just add a high resolution Wikipedia logo and we're good to go.—cyberpower Limited AccessTrick or Treat 12:34, 24 October 2012 (UTC)

You're welcome. :) It still needs some more work, and as you note things like the logo still need improvement, but it's a start! We've got it partially working on the mobile site too for phones, still a bit experimental there. --brion (talk) 20:06, 24 October 2012 (UTC)

Citation template reveals date and quotation marks within visibly text

The date of the citation is visible, and the title has quotation marks. Seems strange to me. Observed at: http://wiki.riteme.site/wiki/Interaction_Design_Institute_Ivrea?oldid=518846527

Markup

Its exhibition design unit (E1) was spun off to form an independent company, {{cite web|url=http://www.interactiondesign-lab.com/ |title=Interaction Design Lab |accessdate=2009-10-04}}, currently operating in Milan. Among the academic advisors of Interaction Ivrea were leading practitioners and theorists like [[John Maeda]], [[Ranjit Makkuni]], Joy Mountford, [[John Thackara]], [[Bill Verplank]], {{cite web|url=http://www.nathan.com/ |title=Nathan Shedroff |accessdate=2009-10-04}}, [[Bill Moggridge]] (co-founder of [[IDEO]]) and [[David Liddle]] (co-founder of [[Interval Research]]).

Screenshot

Bug - Citation template reveals date and quotation marks within visibly text

— Preceding unsigned comment added by PutzfetzenORG (talk • contribs) 15:25, 24 October 2012 (UTC)

Hi there. The problem is that you're using a template for the wrong purpose. The {{cite web}} template is used for producing formatted citations for the bottom of an article - see Wikipedia:Citing sources. It looks like you want to make links to external websites. That's done with square bracket syntax, like this.
Please note that links to other websites than Wikipedia are usually put in an "External links" section just before the end of articles, not main article text; see Wikipedia:Manual of Style/Layout. Please also have a look at Wikipedia:External links for information about what links we consider suitable to include in an article. — Hex (❝?!❞) 15:46, 24 October 2012 (UTC)

Intersection of categories for medical articles needing cleanup

Hi, I'm trying to produce a list of medical articles needing cleanup, or even better a list of medical articles needing cleanup ordered by their Importance. I've looked at the Category intersection template but it's not working for me:

{{Category intersection|Medical articles in need of cleanup|Cleanup templates|WikiProject Medicine|}}
Medical articles in need of cleanup

I don't know which tool is best for this, or which specific categories to cross-reference. I remember a tool that could generate a list for the intersection of two categories but I'm not sure where to find it, or which categories will work best. Any ideas? Thanks! Ocaasi t | c 16:12, 24 October 2012 (UTC)

Ok, I found a tool that looks like it works, Magnus' of course: https://toolserver.org/~magnus/category_intersection.php. But I'm still not sure which categories to use. Ocaasi t | c 16:15, 24 October 2012 (UTC)
Also http://toolserver.org/~magnus/catscan_rewrite.php, but still not sure which categories to use. Ocaasi t | c 16:44, 24 October 2012 (UTC)

Improving communication between editors and "tech people"

Hi. I'm posting this as part of my job for the WMF, where I currently work on technical communications.

As you'll probably agree, communication between Wikipedia contributors and "tech people" (primarily MediaWiki developers, but also designers and other engineers) hasn't always been ideal. In recent years, Wikimedia employees have made efforts to become more transparent, for example by writing monthly activity reports, by providing hubs listing current activities, and by maintaining "activity pages" for each significant activity. Furthermore, the yearly engineering goals for the WMF were developed publicly, and the more granular Roadmap is updated weekly.

Now, that's all well and such, but what I'd rather like to discuss is how we can better engage in true collaboration and 2-way discussion, not just reports and announcements. It's easy to post a link to a new feature that's already been implemented, and tell users "Please provide feedback!". It's much more difficult to truly collaborate every step of the way, from the early planning to deployment.

Some "big" tech projects are lucky enough to have Oliver Keyes who can spend a lot of time discussing with local wiki communities, basically incarnating this 2-way communication channel between users and developers. The $1 million question is: how do we scale up the Oliver? We want to be able to do this for dozens of engineering projects with hundreds of wikis, in many languages, and truly collaborate to build new features together.

There are probably things in the way we do tech stuff (e.g. new software features and deployments) that drive you insane. You probably have lots of ideas about what the ideal situation should be, and how to get there: What can the developer community (staff and volunteers) do to get there? (in the short term, medium term, long term?) What can users do to get there?

I certainly don't claim to have all the answers, and I can't do a proper job to improve things without your help. So please help me help make your lives easier, and speak up.

This is intended to be a very open discussion. Unapologetic complaining is fine; suggestions are also welcome. Stock of ponies is limited. guillom 14:17, 23 October 2012 (UTC)

Enable and create a process at village pump technical where, after it is vetted (as needing the tech person involved or informed) it goes to the appropriate technical person. This requires having a few folks at VPT who have the info on who to send what to. This would create the much-needed link without burying the tech folks with stuff. North8000 (talk) 14:44, 23 October 2012 (UTC)
Wikipedia:MediaWiki/DeveloperMemo was my attempt to better organise communication between editors and developers, back in 2009. Didn't get very far... Rd232 talk 15:00, 23 October 2012 (UTC)
That's very interesting; I wasn't aware of such an initiative. It seems that a similar process would benefit from being tried out, to see if we could make it work, perhaps with better tools and/or more involved editors and developers. Thank you for sharing that. guillom 12:48, 25 October 2012 (UTC)
Above, I started a thread. I would appreciate a reply saying who is working on it, its priority level, and when it might be fixed. That kind of communication seems like it should be normal. Biosthmors (talk) 16:42, 23 October 2012 (UTC)
In a project that is not to a large degree volunteer based perhaps. Unfortunately that is not the case. So almost all bugs are in the state of limbo until someone randomly decides to pick it up (because that's how volunteers operate). In your case, it's not even reported as a bug yet, since no community member went to bugzilla to file a bugreport. Remember, this page is an English Wikipedia discussion forum, not a tracking system for bugreports. This is part of the reason why I suggested we improve integration with bugzilla. That opens us up to a second problem however, that sometimes people seem to think that bug trackers are discussion forums :D —TheDJ (talk • contribs) 17:19, 23 October 2012 (UTC)
Tracked in Phabricator
Task T24629
Tracked in Phabricator
Task T29001
Some open bugs related to this allowing bugs to be created/changed via email and MW Bugzilla integration extension. Helder 23:59, 23 October 2012 (UTC)
With the current infrastructure there isn't a whole lot anyone can do that wouldn't be completely insane or just plain not very effective. Frankly the best I can think of would be to put the stuff on meta or mww depending on what it is and then just have some way that it can be announced globally and also watched globally by anyone who wishes to be involved. A better tie together for all the projects so they stop seeming so much like random myriad sites that visiting others takes conscious effort would go a long way, and isn't there work being done on exactly that?
That said, nothing will ever get great involvement from everyone; even community-made major changes to a single small project will inevitably take at least some users by surprise... -— Isarra ༆ 16:51, 23 October 2012 (UTC)
Yes, there is some work being done on better crosswiki integration, and notifications. I agree that they should improve the situation, but not only are they not available yet, but I doubt they'll be enough. There's probably room for incremental improvements and/or complementary tools or processes that we could try out in the meantime. guillom 12:48, 25 October 2012 (UTC)
  • Part of the problem actually is that we have too much information. Oliver is a human filter on that. What we need is something that is good at finding the information that is relevant. Like a tech search engine that has some understanding about latests changes and is able to find relevant blog posts, bugzilla tickets and projects based on that context.
  • Account integration with bugzilla (loggin in with your wikimedia account) is another small thing that probably would help. (would send replies to wikimail, not publicize your email address on bugzilla)
  • Make 'tracked' an extension, put the info in a DB table and use it from bugzilla to link back to the wiki's so developers can more easily find all the wiki comments. (and again make it searchable)
  • Try to find a way to do more with 'assigned'. (unassign automatically)
  • For WMF issues, perhaps add a state 'scheduled' + date
  • Make a stricter separation between WMF and non-WMF items in bugzilla.
  • Expose the 'state' information trough the 'tracked' extension.
  • Make it possible to 'watch' an issue trough the 'tracked' extension (would email user if the issue is fixed, or if new comments are posted in bugzilla)
  • Create a 'simple' report a bug page. These issues are filed in a special category, and then sorted by volunteers + bugmeister into the proper component, priority, closed as duplicate etc. Will have explanation that all feedback is welcome but that we don't have the resources to get back to everyone personally. Possibly also integrateable right into the mediawiki website by use of a gadget. Could easily gather UA info, mediawiki version info etc automatically.
Will list more when I think of it. —TheDJ (talk • contribs) 16:54, 23 October 2012 (UTC)
Thank you, that's very helpful. More integration with other sites and tools is indeed a recurring theme. Other points you make particularly resonate with me, for example the separation between WMF and non-WMF items (in 2012, I wrote "Wikimedia projects and MediaWiki are separate products and they should be acknowledged as such: as a consequence, the separation between bugs in the MediaWiki software, and Wikimedia-specific operations & configuration requests should be made more explicit."). I'm going to make a list of all suggestions, and also discuss this with Andre Klapper, our new Bug management person. Hopefully, we can make progress on this front. guillom 12:48, 25 October 2012 (UTC)
Allow multiple means of accessing developer/editor discussions:
  • wikitech-l (and the other mailing lists) are isolated from Wikipedia. Subscribing and registering is a barrier to editors posting. Mailing lists are hard for casual readers to follow discussion threads; or to catch up with all new posts without having to re-read every thread or read discussions unthreaded.
    • It should be easy to create a bot that automatically cross-posts from the mailing list to a specially-created wiki project page (with autoarchiving in the normal way; though the bot would need to remove quoted paragraphs which are extensively re-posted on the mailing lists).
    • With a little extra effort, a new bot could also post editor comments on the wikipage to the mailing list, removing the barrier to editors having to sign up to a separate list and making dialogue convenient by either method.
    • All mailing lists should have RSS feeds, preferably two feeds for flexibility: with and without full content alongside the message headers.
  • better still, improve RSS generally across wikis, so that editors can subscribe to summary and/or full feeds or changes to VPT and indeed any wiki page (the present watchlist RSS is a start, but does not allow subscribing to pages independenly of adding them to the watchlist, and does not provide details of the text changes).
  • improve watchlist email notifications so that editors can choose between:
    • summaries (as now, but with the option for subsequent emails if there are subsequent changes before the page is viewed) and
    • the full text of any changes (diffs, as though it were a mailing list).
As mentioned previously in recent months, MediawikiWiki is a remote forum for most editors, as the watchlist is not integrated into the enwiki list. But long-term lengthy discussions should not be crowded on to a single page like en:VPT or VPP. So restrict VPT to ephemeral discussions and brief pointers to pages (on enwiki or on mw?) where bigger issues are discussed at greater length. But do also ensure that the initiator posts regular brief feedback to VPT (or site notices), at least weekly, so people do not miss out on discussions which change focus over time. (For example, I often reluctantly abandon discussions announcing test prototypes, because they are initially too buggy to comment on constructively. But it would be useful to be reminded when projects move from alpha to beta or to RC so that editors can engage in meaningful pre-implementation testing. For technical or policy proposals, it is helpful to know first whether many other editors have begun taking them seriously before commenting, as no one can take a close interest in every vague or speculative proposal.)
(I've assumed above that enwiki is the best or least-worst forum, because in practice it is by far the most active wiki. Of course, it would be better still to integrate other languages and projects, but with MediawikiWiki so isolated from most editors, enwiki is probably more useful, so that the unattainable "best" does not become the proverbial enemy of "the good". A cross-wiki watchlist would go a long way to avoiding this conflict.)
— Richardguk (talk) 17:01, 23 October 2012 (UTC)
A lot of excellent points and ideas, thank you. Centralizing or integrating discussion venues is a recurring theme, and one I also believe will be integral to successfully establishing an ongoing dialogue between editors and developers. I'll keep all your suggestions in mind when exploring options to do that. guillom 12:58, 25 October 2012 (UTC)
The problem I have with the page mw:Wikimedia Features engineering is that changes to the mentioned projects do not appear on watchlist, so I would have to watch each of the individual pages. Helder 23:59, 23 October 2012 (UTC)
Perhaps this could be solved with a gadget? There's already one in place to facilitate the addition and editing of status updates for engineering activities. It seems conceivable to expand that gadget to also include a button to "Watch all projects on this page", or something similar. guillom 12:58, 25 October 2012 (UTC)

More generally, why not introduce Reddit-style in-place replies on talk pages? (The wikitext could be restricted to a simple subset, and it would ensure contributions were signed. The existing section-based method would remain available.) That would make feedback much more appealing to new editors (avoiding the need for the separate "Article Feedback" mechanism), might prevent edit conflicts, and would avoid having to load a lengthy section of wikitext when editors simply want to append or insert a brief comment. — Richardguk (talk) 17:08, 23 October 2012 (UTC)

  • In my experience, pointing out things that don't work well and suggesting improvements on Village Pump (or any other Wikipedia forum) is a complete waste of time. Maybe there's a response or two, then in a few days the thread scrolls off into archive oblivion, with nothing done or ever likely to be done, and one might as well not have bothered. I'm not of course suggesting that all proposals can or should be implemented, or that developers have time to address every issue raised. However, it is frustrating that proposals from ordinary editors seem not to be even considered by or looked at by anyone who might have any influence in scheduling developers' work. Pages such as those at VP would provide a much more satisfying user experience if someone at least said "thanks, yes, we'll put that on the list for consideration" or something. 86.160.208.15 (talk) 17:18, 23 October 2012 (UTC)
    • I think this is true to some degree. But remember that even the official list (bugzilla) is already well over 40000 issues (with multiple feedback items) over just the last 10 years and even there developers don't have the time to keep up with everything, the amount of feedback troughout the entire community is a number in the hundreds of thousands I suspect. We need to find ways to aggregate information better automatically. As the community has a problem consuming information, so do the developers have a problem consuming the huge amounts of feedback (often duplicate) of the community. And we need to do a better job in pointing out to people that much of the website by the nature of our organization, is simply NOT under active development or maintenance. There simply aren't enough people to do the work that the community would like the developers to do. We should point out that there submission is important and will be used eventually. —TheDJ (talk • contribs) 17:40, 23 October 2012 (UTC)
Tracked in Phabricator
Task T2148
Incidentally, I do recall in one discussion, a long time ago, that I was advised to register with that "Bugzilla" thing, but there was some suggestion that it listed people's email addresses in full plain text on publicly accessible Internet pages, which obviously is a complete no-no, so I never did. Is that still the case? Or maybe it was never the case and I got hold of the wrong story. 86.160.208.15 (talk) 20:34, 23 October 2012 (UTC)
See bugzilla:148. Helder 23:59, 23 October 2012 (UTC)

Not that Gerrit is very nice, but there is bit of a barrier for ordinary people to comment on changes there... Logged out folks cannot comment and review there, nor are accounts linked with Wikipedia accounts so login isn't simple. The register link on gerrit goes to the Developer access page on mediawiki.org --Aude (talk) 19:37, 23 October 2012 (UTC)

Gerrit is the last place we want ordinary people going (I could go into why, but suffice to say IT'S POOP). Point is, if we don't want to scare people way, we should really push for the average folks to stick to bugzilla. -— Isarra ༆ 20:19, 23 October 2012 (UTC)
That's true, and yet there's also a lot of information in gerrit, which brings us back to better integration / centralization of technical discussions; this seems to be the cornerstone of this problem. guillom 12:58, 25 October 2012 (UTC)

In my experience, pointing out things that don't work well and suggesting improvements to Oliver is simple and it works well. Have we tried cloning Oliver yet? If that is impossible, we could try to find some more people like him who can function as a human filter between the community and the devs. A lot of valuable dev-time is wasted if we don't filter the communication. They (talk) 20:14, 23 October 2012 (UTC)

Thanks to all who have already commented; there's a lot of useful information in there. Please continue to add your thoughts and spread the word about this discussion; I'm watching it with a lot of interest! guillom 14:27, 24 October 2012 (UTC)

Update Template:Taxobox/taxonomy

Still need /sandbox installed at Template_talk:Taxobox/taxonomy. Been waiting over 2 weeks for {editprotected} of 7 October 2012. Some admin please update, or discuss there. —— The update should reduce maintenance category:

Within an hour after updating the template, that category should have less than 4,000 pages (current live count: 4 pages). Note that some taxobox articles will still be listed in that category, due to other problems in related templates not yet fixed. Thanks. -Wikid77 11:09, 24 October 2012 (UTC)

Done, and reverted. —TheDJ (talk • contribs) 11:39, 24 October 2012 (UTC)
  • Revised /sandbox as noted, so try again: I need an admin to install the changes from the /sandbox again, as I have refined the proposed change to {taxobox/taxonomy}, to handle higher taxon levels as in article "Cetacea" but without showing the extra infra-taxons.
After the update, I will check the above Category, to see how many articles are fixed by that update. Thanks. -Wikid77 (talk) 18:57, 25 October 2012 (UTC)

Email

Using Template:You've got mail you can notify email recipients for sending them email. Is there a way to done this automatic? I mean, can i put a template in my talk page, that notify me that a/some user/s send my an email from wikipedeia? Xaris333 (talk) 15:36, 24 October 2012 (UTC)

If you want an easy way to add the {{you've got mail}} template, you can enable Twinkle in Preferences → Gadgets (click the TB link once Twinkle is installed). If you want a way for people to easily email you, you can use the {{mail}} template. David1217 What I've done 21:52, 24 October 2012 (UTC)
I don't think that's what the user was asking. I think he/she was asking whether there was an onwiki system for automatically notifying users when they get new mail through the "Email this user" feature. The answer to that question is no. Graham87 08:20, 25 October 2012 (UTC)

Table

Is there a way, the first column of a table to give automatic numbering; Like using tha symbol #. Xaris333 (talk) 15:44, 24 October 2012 (UTC)

No. ---— Gadget850 (Ed) talk 01:31, 25 October 2012 (UTC)
Hey, be nice. — Hex (❝?!❞) 18:48, 25 October 2012 (UTC)
  • There is {autocol} to number across all columns: I recently developed a browser-independent template to generate a multiple-column table, as Template:Autocol, with or without auto-generated numbers, using the wikimarkup language, and get this: I did it without losing my sanity over the bizarre newline restrictions in templates, which work differently than newlines with inline #ifeq-structures. So, for example:
  • {{autocol|one|two|three|four|five|six|ncols=3|num=y|wrap=y|n=6}}
    Result: 
    {{autocol|one|two|three|four|five|six|ncols=3|num=y|wrap=y|n=6}}
Now, for the general case of auto-numbering just 1 column in a wikitable, we need a tiny wp:parser function as {{#set:xx|34}}, so that a parameter value can be updated inside the same page, for a row counter, by {{#set:xx: {{#expr:{{{xx}}}+1}} }} So, using a {#set:xx|...} function then the wiki-parser could generate the auto-numbered row numbers in any wikitable. Otherwise, a table must generated, with hand-coded row numbers, but skip the remaining rows when reaching a max-row-count parameter. That is how {autocol} works: the item numbers are already hand-coded inside the template, but it stops at limit n=60 (or such) and does not display the other hand-coded item numbers. That is why {autocol} is so fast; it does not even need to add-up the count numbers, it just displays the canned numbers as the hand-coded values. -Wikid77 (talk) 19:45, 25 October 2012 (UTC)

Edit conflicts with other sections, new issue

Tracked in Phabricator
Task T43352

So, it appears that the issue with the edit conflict system that caused pages to be mostly deleted has been fixed; however, can someone file a new bugzilla report since it is still possible to edit conflict with another section? Ryan Vesey 19:08, 24 October 2012 (UTC)

Actually, the primary issue hasn't been fixed at all. Ryan Vesey 19:17, 24 October 2012 (UTC)
Reported at Bugzilla:41352, which is being tracked above (#Apparent bug causing massive text loss when saving). — Richardguk (talk) 19:38, 24 October 2012 (UTC)
  • Beware ghost edit-conflicts when section not changed: During these past few days, on 4 occasions up to 23 October, I have been notified of "edit-conflict" when running a section-edit of a middle section, but the original section had not been changed by anyone. So, a re-edit with copy/paste was then able to save the section, as only one ghost edit-conflict for each page. -Wikid77 (talk) 19:52, 25 October 2012 (UTC)

Global locking notice in Special:Contributions

When you view the contributions of a blocked user, you're presented with a notice that the user is blocked; see Special:Contributions/WoW for an example. However, the same is not true for users that are globally locked but not presently blocked, as you'll see if you look at Special:Contributions/Omar-Toons. Is there a way that we admins can add such a notice (presumably by having the system check the global log at Meta), or would this be something that only the developers can do? Nyttend (talk) 00:42, 25 October 2012 (UTC)

It is probably possible using Javascript, but ideally developers should do something. The pop-ups gadget sorta serves this purpose (when I mouse over the talk page or user page link for a locked user).--Jasper Deng (talk) 00:51, 25 October 2012 (UTC)
It would also be nice if a "this account is locked" notice popped up in Special:Block when attempting to block a locked account, similar to the way it does with a blocked account. Reaper Eternal (talk) 01:02, 25 October 2012 (UTC)
Locked accounts should still, usually, be blocked, as locking will not trigger an autoblock of the underlying IP. MBisanz talk 01:11, 25 October 2012 (UTC)
It would still be helpful to see such a notice, as if an account were locked, chances are greater that it should be blocked rather than warned.--Jasper Deng (talk) 01:18, 25 October 2012 (UTC)
That makes sense. MBisanz talk 15:58, 25 October 2012 (UTC)

Recent changes from new accounts

See also: WP:Help desk § Recent changes from new accounts

How long do you have to have an account before it stops showing up in the recent changes counter from new accounts? My account was created about a month ago and has plenty of edits (therefore is auto-confirmed), but it still shows my edits at the "User contributions for new accounts" special page. –– Anonymouse321 (talk • contribs) 07:16, 25 October 2012 (UTC)

Taking a quick look at the code, it appears that the "newbie" contribs looks for contributions by the most recent 1% of accounts created. There's also a special check to exclude bots after taking the 1%. Since we have 48,445,352 registered users, the most recent 484,454 (that's anyone with a "User ID" over 47960898) are considered "newbies" for the purposes of Special:Contributions. Anomie⚔ 13:39, 25 October 2012 (UTC)
BTW, for you personally, you'll stop showing up there once we hit 17,766,793 accounts. Anomie⚔ 13:46, 25 October 2012 (UTC)
Wow, that's an interesting way of determining what a new contributor is, but I guess that's the way it is! Thank you So I guess it has nothing to to with your edits/rights. –– Anonymouse321 (talk • contribs) 15:08, 25 October 2012 (UTC)

PDF writer

As an IP has discovered in Oceania, a map on the page causes a huge error when rendering as a pdf. Is there a way to make it pdf friendly, or exclude it from the pdf rendering? I've added it back in for now, as I think web utility trumps pdf utility, but it's not an ideal solution. CMD (talk) 10:32, 25 October 2012 (UTC)

I have added the template that includes this map to Category:Exclude in print, which specifically marks a template such that it is not included in PDF printing. —TheDJ (talk • contribs) 11:49, 25 October 2012 (UTC)
Works great, cheers! Much appreciated. CMD (talk) 15:07, 25 October 2012 (UTC)

Allowing "view source" tabs for individual sections

Well, if we can have separate edit tabs for sections in articles, then why can't we do the same for "view source?" Let's say if an IP wants to view the source of a section of Barack Obama, rather than clicking "view source" at the top and scrolling down to the section, he can just simply click a "view source" tab at the section heading. Would this be a good idea? Narutolovehinata5 tccsdnew 13:14, 25 October 2012 (UTC)

This is technically feasible: for instance, at the section "2010 midterm election", the edit link for registered users is edit. If an unregistered user were to use exactly the same URL, they will get the same section but in "View source" mode - it's headed "View source for Barack Obama", and they see the normal messages (MediaWiki:protectedpagetext, MediaWiki:viewsourcetext etc.) that unconfirmed users see when viewing the whole page source; also, the "Save page" buttons, etc. are absent. So all that's missing are the links at the top of the sections. --Redrose64 (talk) 16:53, 25 October 2012 (UTC)

Watchlist show/hide concept change...

Tracked in Phabricator
Task T11790

The "hide/show" on the Watchlist headbox(?) doesn't seem to do what I would expect it to. For example, if I have the help desk in my watch list and the last non-ip edit occurred and 11:00 and the last ip edit occurred at 11:05, I would expect that clicking "Hide Anonymous Users" would keep the help desk in my watchlist, marked as 11:00 with the non-ip editor's information as if the ip edit did not exist. Instead, it completely removes the Help Desk from what is displayed.


I'm curious as to whether other editors would prefer that the hide/show would work the other way, whether it is technically feasible to do so as a general change and whether it would be possible to have that as a tool/javascript/preference?Naraht (talk) 15:08, 25 October 2012 (UTC)

This is T11790; the big problem there seems to be that the people who are "in charge" of database stuff don't seem to have ever commented on whether the proposals there are efficient enough to be implemented.
Note that you can somewhat emulate this now with the "Expand watchlist to show all changes, not just the most recent" preference under Watchlist. And if someone really wants, they could write a user script to remove all but the first instance of a page; or you could just use the "Group changes by page in recent changes and watchlist (requires JavaScript)" preference under Recent changes. Anomie⚔ 16:28, 25 October 2012 (UTC)
Good to know that there are other people who think the same way that I do, bad that it hasn't been sorted out yet... I did take your advice and try to emulate it in that way, but I think I'll stay with the other way for now.Naraht (talk) 18:04, 25 October 2012 (UTC)
There is a great gadget/script available that does this and more. I forget where it lives but someone with the knowledge will be along shortly. Rich Farmbrough, 21:36, 25 October 2012 (UTC).

Show changes when editing old revisions

Tracked in Phabricator
Task T43409

Apologies if this has been mentioned somewhere else. It seems like "show changes" no longer works properly when editing an old version of an article, for about the past week or so. It now calculates the changes based on the old revision that I've selected, not based on the current version of the article as it should. For example, I made this edit by saving an older revision without making any other changes, but "show changes" showed me nothing at the time. Thanks. --Bongwarrior (talk) 22:39, 25 October 2012 (UTC)

Although I requested a way to get a diff against an old revision of a page (on bugzilla:41307, two days ago), that request didn't receive any comment so far, so I don't think this is someone trying to implement it (which probably should be made by some extra button, or preference, or as in the User:Js/ajaxPreview, which requires you to use SHIFT to get this behavior). Helder 01:00, 26 October 2012 (UTC)
It appears to have been broken in the big ContentHandler merge. Anomie⚔ 01:29, 26 October 2012 (UTC)

watchlist bug

Resolved

I've had a feature on my watchlist which allows a collapsable tree-view, with changes grouped by article and a little toggle to show hide the edit for a page. Upto an hour ago this worked fine, but its stopped now. I think it was a preference or gadget but I can't see anything which corresponds (I do have Expand watchlist to show all changes, not just the most recent checked).

Looking at my error console I'm getting

Exception thrown by ext.articleFeedbackv5.watchlist: Object [object Object] has no method 'stall'

which might be the cause. I've tried this on chrome/safari on OSX.--Salix (talk): 23:28, 25 October 2012 (UTC)

I have the same WP settings on Firefox 16.0.1/Vista, and when I loaded my watchlist a few minutes ago, everything worked fine except the groups didn't collapse. A simple reload fixed it. jcgoble3 (talk) 00:28, 26 October 2012 (UTC)
Back to normal now and the Exception is no longer thrown.--Salix (talk): 00:31, 26 October 2012 (UTC)

My android based phone internet browser now crashes consistently with Wikipedia

Does anyone else with an android smartphone have their browser crash every time they click on an inline citation to see the source? Mine has started doing that lately. I've shut down and restarted multiple times and it still happens. It happens on mobile or desktop versions. I don't know how to check the browser version on my smartphone. Biosthmors (talk) 21:01, 27 September 2012 (UTC)

This may be related to the gadget mw:Reference Tooltips which is enabled by default on this wiki. Helder 00:29, 28 September 2012 (UTC)
The group of Android phones is rather large. It might be helpful if you could report the Android version your phone is using, and even better which browser and browser version you are using. That makes solving this problem considerably easier. —TheDJ (talk • contribs) 13:28, 29 September 2012 (UTC)
It should be Android 2.3 (Gingerbread) per this. Biosthmors (talk) 15:35, 4 October 2012 (UTC)
Browser version 2.3.4. Biosthmors (talk) 21:26, 8 October 2012 (UTC)

Performance

Mental note, MediaWiki:Gadget-ReferenceTooltips.js adds huge anonymous function to each .reference element. That might be a little resource inefficient. We should look into that. —TheDJ (talk • contribs) 13:30, 29 September 2012 (UTC)

since you have the permissions, you can easily fix it yourself by pulling this function out of the "each", giving it a name (it won't leak to the global scope - it's inside a wrapper function anyway), and just use this name with the "each". i.e., let's say you give this anon function the name "doForEachReference()", replace the "each" with
 $(".reference").each(doForEachReference);
whether or not this will actually improve performce/resource use, and by how much, depends on how intelligent is the JS engine in the specific browser, but it's practically guaranteed not to make anything any worse, and some people think the code is nicer this way.
on a side note, this gadget is pretty wasteful anyway: the tip functionality already exists in the included jquery plugin jquery.tipsy, so 95% of the functionality can be achieved using much shorter (and more elegant, if i say so mywself) gadget we use in hewiki: he:Mediawiki:Gadget-CiteTooltip.js. the last 5% can probably be slapped on the hewiki gadget, and still be more economical/compact/simple than MediaWiki:Gadget-ReferenceTooltips.js. קיפודנחש (talk) 18:39, 16 October 2012 (UTC)

My own problems accessing Wikipedia from Android

I use an HTC Hero 200. The software isn't a newer version, either, but it tells me that I'm up to date with what it is running. I realize that I need to upgrade, but in the meantime, I'm having problems. I let my phone service lapse for a matter of weeks, and have been accessing the Internet via WiFi from various locations. Ever since, I'm facing quirks or outright problems when I log in to my account. I use the regular Wikipedia rather than the mobile site, even though at times it is slow as fuck on this phone, even before this recent stuff started happening. For about the past week, I noticed that I was browsing pages on the secure server, even though I didn't log in on the secure server. The past day or two, it tells me that I've logged in successfully, then as soon as I go to access my watchlist, it comes back to tell me that I'm not logged in, over and over. I'm guessing that the servers on here are recognizing that I'm accessing them from a variety of IPs, but I really don't know if that's the cause of this strange behavior or not. Any hints? I could just go to my service provider and pay them and perhaps this will all go away.RadioKAOS (talk) 22:33, 15 October 2012 (UTC)

I had a similar problem last night while logged in from my Android device. My broswer (see above) crashed while doing normal activities while logged in. Biosthmors (talk) 22:42, 15 October 2012 (UTC)
I've just tried with my Andriod Tablet (Nova 7 Aurora running 4.0.3) using the Browser - I can click the inline links, but nothing happens. It seems intermittent depending on device and Andriod version. Osarius - Want a chat? 09:55, 16 October 2012 (UTC)
Thanks all; I'll report this to the mobile team :). Okeyes (WMF) (talk) 15:51, 16 October 2012 (UTC)

I went and paid my phone bill this morning. I'm still having the exact same problem with mobile data, so I don't believe it has to do with accessing this site from numerous WiFi points, especially since I've done that before and never had any problems such as this. Here's the version information from my phone, hope this helps:

  • Phone (as previously mentioned) - HTC Hero 200
  • Firmware - 2.1-update1
  • Baseband - 2.42.01.04.23
  • Kernel - 2.6.29
  • Build and software number - 2.36.556.1

(the kernel and build have additional information appended, but I don't know if this is relevant or if it is at all specific to this phone - I'm not that familiar with the inner workings of Android)

  • Browser - WebKit 3.1 (I'm hoping this is in regards to the default Internet app; I've been using that, as I can disable the mobile site at the browser level rather than at the website level, as has been the case with other browsers I've used)
  • PRI - 1.93_112

I realized that replacing my phone would be a good idea when I noticed that there's now a mobile version of Firefox, which this phone doesn't support. Of course, as with seemingly everything, money is the main sticking point. I had previously downloaded Opera, until I realized that it was taking up too much space. I then downloaded Opera Mini and have been using that to at least be able to log in and access my watchlist, but now I have to deal with a whole new series of quirks, hangups and problems. RadioKAOS  – Talk to me, Billy 21:26, 19 October 2012 (UTC)

As it turned out, I had to replace the phone anyway after two batteries blew up on me in less than four days. Since it is still ARMv6 rather than ARMv7-based hardware, I'm limited in what software I can run. At least I'm able to browse the web like normal again. RadioKAOS  – Talk to me, Billy 00:14, 27 October 2012 (UTC)

"Your edit was saved" problem - yes, I saw the above discussion

Originally, I thought this was a good idea; but it's got a flaw that cripples its value. Namely, it appears constantly, even when not saving an edit.

If I navigate to any Wikipedia page, talk page, project page, etc, the message "Your edit was saved" appears. If I had actually been editing and had just saved something, this would be a useful confirmation. Unfortunately, it appears when I simply navigate to the pages. It also appears when navigating to "special pages" such as Special:LinkSearch, Special:Preferences or even Special:SpecialPages.

This only happens when logged-in, not when logged out. I haven't tried other browsers yet; from this PC I use Google Chrome. I can test from IE and Firefox later tonight from my other system. I am also logged-in via the secure server. Could it be some odd interaction quirk with between the new message code and some other setting or script, or is it an issue with the secure server, or with the browser being used? Is anyone else seeing this issue?

If all else fails, I may just add the code from above that disables the message. --- Barek (talk • contribs) - 20:44, 23 October 2012 (UTC)

We just deployed a fix where the feature was shown multiple times if you refreshed or went back to a page you just completed an edit on. However, I haven't heard of anyone else using Chrome get this error (myself included) on literally every page load. My first recommendation would be to clear your cache, clear your cookies, and then try logging in again (clearing your cookies completely should log you out). If you don't have cookies enabled, this may be related, so let me know. Steven Walling (WMF) • talk 21:20, 23 October 2012 (UTC)
I'd still try clearing your cache and cookies, but there's a secondary issue we're seeing when it comes to detecting post-edit state. It's not particular to Chrome though. Fix is on its way shortly, if we can squeeze it in to a deployment window today. Steven Walling (WMF) • talk 21:43, 23 October 2012 (UTC)
Thanks: I cleared my cache and cookies, then restarted Chrome. That seems to have resolved the issue (or maybe you already snuck in your other patch). Either way, the issue appears to be resolved now - I should have recalled to do that on my own. Thanks for the assist. --- Barek (talk • contribs) - 21:49, 23 October 2012 (UTC)
Any time. Steven Walling (WMF) • talk 22:05, 23 October 2012 (UTC)

I'm still having a bug where the save message displays again for me on the page I visit immediately after saving. Safari 5.1.7 running OS X 10.6.8 on a MacBook Air. David1217 What I've done 22:05, 24 October 2012 (UTC)

Strangely, I can reproduce the same error in Chrome using my staff account, but not in other browsers. It may be a cookie issue. There are some related fixes that will be deployed tomorrow, so I will continue testing, and check in again. Seeing duplicates like this pretty annoying, so thanks for your patience David (and anyone else watching), Steven Walling (WMF) • talk 07:52, 25 October 2012 (UTC)
Okay, we deployed a new version today, so I would clear your cache again and let me know if you're still getting anything broken. Steven Walling (WMF) • talk 22:37, 25 October 2012 (UTC)
It appears to be working correctly now. Thanks Steven! David1217 What I've done 17:53, 26 October 2012 (UTC)

What happened in the last hour? (October 25/26, 2012)

I've been off-line for about an hour. When I left, everything was as it should be. Now all Gadgets are gone - Toolbars, everything. My Sandbox and who knows what else is not showing at the top of the page. The only thing available under Preferences is my login information. Tabs on articles are missing. Can I assume this is something being worked on, or was it some change that went into effect? — Maile (talk) 21:27, 25 October 2012 (UTC)

Discovering more. On navboxes, the collapsed state is no longer working. In the Search bar, it no longer returns any results at all. — Maile (talk) 21:36, 25 October 2012 (UTC)
See if a hard refresh fixes it; the cause appears to have been reverted. -— Isarra ༆ 21:39, 25 October 2012 (UTC)
Doesn't do a thing for me. Neither does logging off and then back on. Neither does closing down my browser completely and re-opening. — Maile (talk) 21:43, 25 October 2012 (UTC)
Could try enabling the gadget mentioned in the section above, I dunno. Wish I had real answers. -— Isarra ༆ 22:23, 25 October 2012 (UTC)
This seems like an issue that is completely separate from what everybody else was experiencing. Can you upload a screenshot? Have you attempted using Wikipedia from another browser? Ryan Vesey 22:28, 25 October 2012 (UTC)
I don't know anything about how to upload a screenshot. And while I understand why you're asking, the multiple issues would take multiple screen shots. But I do believe you might have hit on something. I opened Wikipedia in Opera, and it seemed normal. Bear in mind that I have no issues of any kind on any other website. It is strictly Wikipedia. Even Commons looks like its normal self to me. Wikisource looks normal. Only Wikipedia. I'm using Firefox 16.0.1, but have been for a while. I don't know if the server makes any difference: Served by mw55. I'm accessing Commons by srv247. Opera is accessing Wikipedia on a different server mw52. So, this looks like it might be more server-related. — Maile (talk) 22:57, 25 October 2012 (UTC)
@Maile66: at Wikipedia:Village pump (technical)/Archive 103#Edit summary and Subject/headline funkiness I described how to create and upload a screenshot (search for "here's how I did some of my screenshots"). --Redrose64 (talk) 10:09, 26 October 2012 (UTC)
Well, I use IE, and my editing window has changed two hours or so ago: the tool bar with special characters such as en dash, em dash and tilde has disappeared, and the script I had installed is gone, too. What the heck happened? And is this even the right place to report such things? – ὁ οἶστρος (talk) 23:19, 25 October 2012 (UTC)
This is the right place. And thank you for posting here, so we can at least know it's not just my browser, not just my account. — Maile (talk) 00:09, 26 October 2012 (UTC)
I use the navigation popups gadget, the gadget for the UTC clock and purge link at the top right of the page, and the gadget for an [edit] link for the lead sections of articles. Neither the navigation popups nor the UTC clock are showing up. The lead section [edit] link is showing up, however. I've tried disabling these gadgets, bypassing the Internet Explorer browser cache (Ctrl key + Refresh button in browser), and reenabling, as well as just purging an article I have been reading, to no avail. —{|Retro00064|☎talk|✍contribs|} 01:21, 26 October 2012 (UTC).
I have resolved it on my browser. For some reason, NoScript began seeing the English Wikipedia (and only that one) as potentially harmful and started blocking it. Once I changed the settings, everything corrected. — Maile (talk) 01:24, 26 October 2012 (UTC)
Clarification. NoScript add-on belongs in Firefox. Not aplicable in Internet Explorer. Poeticbent talk 16:11, 26 October 2012 (UTC)
I use Internet Explorer 8. I often browse with InPrivate Filtering on to block ads, but even with that turned off (as it is at the moment) the gadgets are still not working for me.
Internet Explorer does report errors on pages here on Wikipedia. See the below copied report. The "Object doesn't support this property or method" error references the navigation popups JS file and appears to occur every time I move the cursor over a link (which would normally cause a navigation popup to appear), causing the exact same error to occur multiple times in the error report. The below report is one where that error appears only once (because I had not moved my cursor over multiple links when I copied the report).
Extended content
Webpage error details

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; GTB7.4; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C)
Timestamp: Fri, 26 Oct 2012 02:13:02 UTC


Message: Expected identifier
Line: 2
Char: 804
Code: 0
URI: http://bits.wikimedia.org/wiki.riteme.site/load.php?debug=false&lang=en&modules=ext.EventLogging%2CUserBuckets%2CmarkAsHelpful%2CpostEdit%7Cext.Experiments.experiments%2Clib%7Cext.articleFeedback.startup%7Cext.articleFeedbackv5.startup%7Cext.gadget.DRN-wizard%2CNavigation_popups%2CReferenceTooltips%2CUTCLiveClock%2Ccharinsert%2Cteahouse%7Cjquery.articleFeedbackv5.verify%7Cjquery.autoEllipsis%2CcheckboxShiftClick%2CclickTracking%2Chidpi%2ChighlightText%2Cjson%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%7Cmediawiki.api%2Chidpi%2CsearchSuggest%2Cuser%7Cmediawiki.api.watch%7Cmediawiki.page.ready%7Cmediawiki.page.watch.ajax%7Cmobile.desktop&skin=monobook&version=20121025T221751Z&*


Message: Object doesn't support this property or method
Line: 1163
Char: 2
Code: 0
URI: http://wiki.riteme.site/w/index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript&518697159
—{|Retro00064|☎talk|✍contribs|} 02:28, 26 October 2012 (UTC).

In spite of my having re-set the NoScript yesterday, this morning it was once again seeing the English Wikipedia as harmful and was blocking it. I have once again adjusted the settings. Within NoScript options, there is a "white list" of what sites can be permanently alllowed. It's on that list that Wikipedia - and only Wikipedia - keeps being removed when I go offline. Nothing on that list should be coming off without my manually taking it off. This seems to have popped up at the same time as the above-mentioned "New Banner". Too much of a coincidence. I've always had banner ads blocked, so I don't see the ad. But I would bet that something Wikimedia did to send out that "New Banner" is the same thing that keeps meddling in our scripts to mess us up. — Maile (talk) 11:10, 26 October 2012 (UTC)

Things seem to have gone back to close to normal on my side: script link has re-appeared and a similar editing tool bar has also shown up. Dunno, might be possible to change the latter to what it was via the editing options ("My preferences" is still crippled by missing tabs, by the way), but badly labeled, confusing and convoluted as they always have been, I don't feel like noodling around there at the moment – especially not, if I can't be sure things won't be suddenly and arbitrarily reset without warning again by the Wikipeda powers-that-be.
By the way, they let us know of all kinds of Wikipedia-related activities and initiatives via text boxes forced atop of pages, why do they not also announce in advance impending highly disruptive changes to the user interface and their exact nature (i.e., what's gonna change and how to get back to how it was if one prefers that)? – ὁ οἶστρος (talk) 13:38, 26 October 2012 (UTC)
Sometimes they do --Redrose64 (talk) 13:56, 26 October 2012 (UTC)
See also thread below at Wikipedia:Village pump (technical)#What's going on? Pop-ups dead (October 26, 2012) for more reports. Poeticbent talk 15:25, 26 October 2012 (UTC)
So...what can be done to get me my clock back? I'm not interested in being told to abandon IE8. Nyttend (talk) 18:06, 26 October 2012 (UTC)

What's up with the horrible diff display?

Is this another software bug? It seems unable to indicate properly a simple line insertion or deletion, e.g. [10] It causes people to revert, almost blindly. Tijfo098 (talk) 21:40, 25 October 2012 (UTC)

You inserted a line-break as part of your additions, so it's showing the removal of some content from one line and its insertion on the next. - Jarry1250 [Deliberation needed] 22:06, 25 October 2012 (UTC)
...But the diffs are displaying oddly, at least for me (I'm using the old diff view gadget). I remember there being spaces between some of the lines where there are none now. - Purplewowies (talk) 22:43, 25 October 2012 (UTC)
  • Split paragraphs or newline breaks in reftag footnotes: Wikipedia's pattern for comparing diffs relies on matching the newlines, so try to have more newlines, as shorter paragraphs or splitting reftag footnotes to have newlines inside. Otherwise, those large, massive globs of text are difficult to compare, sort of like that literary trend to have paragraphs with one sentence spanning an entire page. Instead, keep sentences limited to 4 prepositions, and seek shorter paragraphs. For easier comparison, use a separate edit to split the long paragraphs or reftag footnotes, then the next edit can be used to add/change text, with easier side-by-side diff views. -Wikid77 (talk) 12:01, 26 October 2012 (UTC)
  • The problem of the diff display flagging huge chunks of an article as having changed when they are identical has been around for as long as I can remember. Every time I can be bothered, which is probably about three times in eight years, I complain about this on some random Wikipedia page. Nothing is ever fixed. 86.177.108.63 (talk) 17:47, 26 October 2012 (UTC)

How do ratings work?

Why don't the ratings follow standard arithmetic? I rated an article that I thought was poorly written as a 2. Apparently all the other raters think the article is a stellar example of clarity, since 50 ratings had averaged to 5. Okeh, no problem there. How-ever, when I re-checked the average, it was 3.5. I don't understand how this can be. Sure, I think my rating is better than the fives, but it should have had only minimal influence: (250+2)/51 = 4.9+ . What gives?Kdammers (talk) 07:51, 26 October 2012 (UTC)

Try asking at Wikipedia:Article feedback. ---— Gadget850 (Ed) talk 13:08, 26 October 2012 (UTC)
I don't understand. I went to that link, but it's just a general discussion. When I went to some articles to see if "Article feedback" could be found there, I didn't see any-thing like that at all.Kdammers (talk) 05:09, 27 October 2012 (UTC)

Tool requests

Where is the best place to request additional tools to be written? In need of a few functions similar to what CatScan and Image checker can do to help with clean-up tasks.--Traveler100 (talk) 11:55, 26 October 2012 (UTC)

Need to slow down on interface changes

The current chaos caused by rampant changes to the display and edit-interface of Wikipedia pages seems to be out-of-control. I think it is time to slow down all these massive changes. There have been complaints about missing "gadgets" and "popups", and meanwhile, I do not even have the title on some pages with monobook skin in Internet Explorer. Let me say that again, for clarity:

  • Sometimes Wikipedia drops the title off the top of some pages.

So, after a redirect, I resort to hovering on the "edit-page" link to see what the page name shows as the probable page title in the URL. Anyway, please slow down on all the massive changes, stop creating all those Cascading Style Sheet (CSS) sub-classes and sub-sub-sub-sub-classes. Instead, please pre-test the proposed changes to the interface for 2 weeks (or such), and start merging and deleting those CSS sub-sub-sub-classes and return to simple formatted text with simple visible attributes in the span-tags or div-tags, rather than one of 87,000 million CSS classes. The system is far too complex to have hourly updates of everything, so tests should be carefully run, for weeks, with each of the major skins, to ensure compatibility. The tactic of using operational increments to continuously improve the system is a good idea, but must have fuller integration testing with prior system features. Of course, I am just saying all this to reaffirm common sense. Some day, I even want the title to display on every page. -Wikid77 (talk) 12:35, 26 October 2012 (UTC)

Gotta second that. Today I have all the problems listed in section #What's going on? Pop-ups dead (October 26, 2012) not far up form here, and the search box fails to drop down with suggestions. The missing popups and search suggestions are especially trouble. The new layout below the edit box looks nice, but it doesn't justify all the trouble we've been having ever since it was rolled out. More stability, please. --Stfg (talk) 15:35, 26 October 2012 (UTC)
To my knowledge they're not linked at all. Are you guys on IE8, by any chance? Okeyes (WMF) (talk) 16:16, 26 October 2012 (UTC)
I'm on IE8, yes. Popups and the dropdown are working again now. These two arose very recently -- they were working 24 hours ago, but the one about "The edit tool box down the bottom has gone to 'copy and paste' mode" has been going on randomly for about a month. IIRC you mentioned at the time that it was known and being examined. --Stfg (talk) 17:23, 26 October 2012 (UTC)
P.S. the "my sandbox" link has reappeared too. Thanks muchly to whoever solved these. --Stfg (talk) 17:25, 26 October 2012 (UTC)
I had disappearing page titles in IE6 (spit) earlier today, fwiw. But very happy with a very frequent release cycle, living in hope that regression testing and maybe A/B testing improves, but on balance willing to live with glitches for the sake of change. --Tagishsimon (talk) 17:28, 26 October 2012 (UTC)

Broken rendering of 'x' in math tags

Noticed on Sinc function, <math>x</math> seems not to be working: it gives an 'Invalid URL' error if you load the image in a new browser window, though the URL looks fine. Compare the three following trivial and near identical math expressions; the first and only the first is broken for me:

  • <math>x</math>:
  • <math>y</math>:
  • <math>z</math>:

--JohnBlackburnewordsdeeds 12:33, 26 October 2012 (UTC)

Everything looks normal for me. The URL for X here: https://upload.wikimedia.org/math/9/d/d/9dd4e461268c8034f5c8564e155c67a6.png HumphreyW (talk) 12:48, 26 October 2012 (UTC)
Seems fixed now for me too now. Very odd (I'm not using the secure server but it's fixed anyway).--JohnBlackburnewordsdeeds 12:54, 26 October 2012 (UTC)
There area apparently some misconfigured nodes. Depending on luck, when I edited math today sometime I got a big red message about texvc not installed. Retrying the edit randomly picked another server box and it worked. It happened twice in twenty edits or so. Tijfo098 (talk) 21:39, 26 October 2012 (UTC)

Hotcats stopped working ?

Resolved

Wikipedia:Hotcats has stopped working for me; it's still set in my preferences and I'm using IE8, is it just me? Thanks GrahamHardy (talk) 14:24, 26 October 2012 (UTC)

Possibly due to bugzilla:41428. —TheDJ (talk • contribs) 14:54, 26 October 2012 (UTC)
Indeed. Quick update that Engineering is on it - hopefully I'll hear something soon. When I do, this is the first place I'm coming to. Okeyes (WMF) (talk) 16:15, 26 October 2012 (UTC)
Is this the same bug that's preventing pop-ups from working? If so, it's definitely not limited to IE (I'm using Safari). Whatever the cause, going through my watchlist without pop-ups is sort of like doing 20-digit long division without a calculator—extraordinarily laborious and prone to errors. If there's any chance this is due to the new "page saved" message (or whatever it says), I suggest just turning that off; it's such a light gray and disappears so quickly that it vanishes by the time I even notice it's there. Rivertorch (talk) 16:24, 26 October 2012 (UTC)
Added: Pop-ups appear to be working again. Yay. Just as I'm about to log out. A huge wet sloppy bucketful of WikiLove to whoever made the fix. Rivertorch (talk) 17:05, 26 October 2012 (UTC)
Indeed; tis now fixed :). Okeyes (WMF) (talk) 17:39, 26 October 2012 (UTC)
All pop-ups are back to normal, thanks guys. Poeticbent talk 17:58, 26 October 2012 (UTC)
Great to hear! I'll pass everyone's thanks on to the responsible dev :). Okeyes (WMF) (talk) 20:39, 26 October 2012 (UTC)

Tooltips on references

If I point at a reference number (one of the superscript blue numbers in square brackets), a tooltip appears with the content of the note. Just as it has for the last few weeks. But now the tooltip does not disappear I point elsewhere. So if I move the mouse around the page, much of it gets covered with tooltips, and I cannot read the article. How do I make them disappear? I am using IE8. JonH (talk) 18:12, 26 October 2012 (UTC)

Probably just another problem that a recent update caused for us IE8 users. I've had a bunch of features disappear, as well. See the threads up above, such as "What happened in the last hour? (October 25/26, 2012)". Nyttend (talk) 20:47, 26 October 2012 (UTC)

Special:ArticleFeedbackv5

I thought that there was a recent announcement telling us that admins could permanently delete abusive comments. Did I remember wrongly? I've just found one (2.125.111.139 on Help:Page History), but all I could figure out was how to hide it, and it's un-hideable. Nyttend (talk) 20:50, 26 October 2012 (UTC)

The recent announcement was about Special:FeedbackDashboard. Steven Walling (WMF) • talk 21:08, 26 October 2012 (UTC)

New pages

Is there a way to find the new pages of a specific day? For example the new pages created on 4th March 2011? Xaris333 (talk) 18:23, 26 October 2012 (UTC)

Pages created in the last month are listed at Special:NewPages; but page creations are not permanently logged, otherwise it would be a simple matter to filter Special:Log. --Redrose64 (talk) 18:57, 26 October 2012 (UTC)
Thx!! — Preceding unsigned comment added by Xaris333 (talk • contribs) 20:20, 26 October 2012 (UTC)
Is there a particular day you want? 67.119.3.105 (talk) 22:14, 27 October 2012 (UTC)
4th March 2011 Xaris333 (talk) 23:41, 27 October 2012 (UTC)

"My sandbox" in my user toolbar

I updated my preferences just now. There is an option to enable "My sandbox" in my personal toolbar at the top of the page. I believe this was new since I last updated the preferences, because it just suddenly appeared in the toolbar one day, and I left it enabled. My problem is this: the sandbox defaults to /sandbox, whereas I already had an entire sandbox tree set up at /Sandbox. I don't see anything where I can change the default location, so that I could click on "My sandbox" and it would take me to my actual sandbox, as opposed to the "other" sandbox. Or am I to gather from this that the capitalization is discouraged and I should go about renaming all of those pages? RadioKAOS  – Talk to me, Billy 00:14, 27 October 2012 (UTC)

It's optional what to call your sandboxes. Help:My sandbox shows a way to make a link to /Sandbox. PrimeHunter (talk) 00:31, 27 October 2012 (UTC)
If I were you, I'd just redirect the /sandbox to your /Sandbox. Ryan Vesey 00:33, 27 October 2012 (UTC)
"My sandbox" is an edit link so it would still edit the redirect at /sandbox. PrimeHunter (talk) 00:59, 27 October 2012 (UTC)
You could move the page from "/Sandbox" to "/sandbox". –– Anonymouse321 (talk • contribs) 01:03, 27 October 2012 (UTC)
A page move should do it. This feature was added to the gadgets list on 15 February 2012 and was switched on for all users right from the start.
Regarding capitalisation: most templates have a documentation subpage; and many also have a sandbox subpage. The /doc page will automatically link to the /sandbox (see, for example, the second line of the second green box at Template:Cl) provided that it is lowercase - any /Sandbox is ignored. I expect that the choice of lowercase Special:MyPage/sandbox was for consistency with the templates. --Redrose64 (talk) 12:58, 27 October 2012 (UTC)

Back button sometimes blanks edit summary

Edit an article, press "Show preview" or "Show changes", use the browser's back button (or Alt+left arrow or equivalent) and on returning to the editing page, the edits are still there, but the edit summary is blanked. Note: if detected before pressing "Show preview" or "Show changes" again, edit summary can be retrieved by going forward to the other page with alt+right arrow, copying the edit summary, going back a alt+left arrow, and pasting the edit summary where it belongs. This is a new bug over approximately the past two weeks. —Anomalocaris (talk) 06:43, 14 October 2012 (UTC)

I rarely use the back button after Preview or Show changes but the edit summary is still there for me in Firefox. It's your browser which should remember it. Which browser is it? PrimeHunter (talk) 13:24, 14 October 2012 (UTC)
For me the back button kills all the changes. I'm on FF12 myself, and have it set to specifically keep things (which it does 98% of the time). ♫ Melodia Chaconne ♫ (talk) 14:58, 14 October 2012 (UTC)
Firefox 16.0.1. —Anomalocaris (talk) 15:08, 14 October 2012 (UTC)
I also have Firefox 16.0.1 without problems. Does it happen when you are logged out? Which skin do you have at Special:Preferences#mw-prefsection-rendering? And why do you go back after Preview or Show changes? PrimeHunter (talk) 15:37, 14 October 2012 (UTC)
I have not reproduced the error when logged out, but maybe I didn't try enough times. Note that if I use the back button when logged out, I get this dialog box:
Are you sure?
The page is asking you to confirm that you really want to leave - data you have entered may not be saved.
[ Leave Page ]   [ Stay on Page ]
My preferences
  • Skin: MonoBook
  • Disable browser page caching: not checked
  • Enable collapsing of items in the sidebar in Vector skin: checked
  • Exclude me from feature experiments: not checked
I use the back button a lot because I edit and inspect, edit and inspect, and I like to get back to where I was before editing, keeping the edit history "tight". It's also convenient because the back button returns me to the same state of editing window. Also, when Show changes reveals several editing errors, it's useful to go repeatedly back and forward, correcting mistakes and finding the next one.—Anomalocaris (talk) 18:30, 14 October 2012 (UTC)
I'm unable to reproduce the problem with those settings. I haven't heard of your edit routine before. If Preview or Show changes reveals multiple problems with my edit then I usually try to fix all of them and then click Preview or Show changes again. PrimeHunter (talk) 01:02, 17 October 2012 (UTC)
It's still happening, sporadically. I am not the only Wikipedian who temporarily leaves the edit page comes back to it, as evidenced by a discussion a year ago here when a similar bug, in addition to blanking the edit summary, was sometimes removing all editing changes, on going back to the editing page from any other page. —Anomalocaris (talk) 06:48, 22 October 2012 (UTC)
Even a Wikipedian who would routinely continue editing from the Preview page rather than clicking back to the Edit page might well click on an internal or external link on the Preview page. On going back to the Preview page, neither edits nor the edit summary should be lost. Yet, sporadically, the edit summary is lost. Therefore this is a matter of concern to all Wikipedians. —Anomalocaris (talk) 17:48, 29 October 2012 (UTC)

Watchdog templates with Lua searches 183,000x faster

Lua strings are not just lightning-fast, they are "greased lightning". So a template based on a Lua script module could scan an entire article section, for typos or trivial grammar errors, within a fraction of a second. I have created some string-search operations in a Lua module to compare search-speed performance, especially because the markup templates, such as {str_find}, are so slow. Even template {strfind_short} is 6x-7x faster than old {str_find}. However, while {strfind_short} can match about 30 strings per second (within length 20), the Lua-based template can match over 500 strings per second (within a length of 22,000 characters). So, if I calculated the math right: it is 500 x 22,000 v. 30 x 20, or 11,000,000 / 60 = 183,333x times faster using Lua rather than markup templates. For testing, the large text in template parameter 1 was over 22,000 characters as 35 paragraphs of text. Now, a parameter {{{1}}} can pass over 160,000 characters of text (~300 paragraphs), but I think there might be some run-time limits for Lua processing activity, so every so often, the result is "Script error" while at other times, the Lua module can scan the 22,000 characters for 50 different phrases.

Finally, with such rapid scanning of character strings, I think we have entered the era of "watchdog" templates, which could scan a section of text to warn of improper new contents, as well as report missing data considered vital to the article. If the watchdog template scanned 5 upper paragraphs, to check for 50 crucial phrases of basic data, or rumors to avoid, then it could perform the watchdog scan in about 1/50 of a second (3x faster than a single {cite_web} template). The tactic would be to leave it active inside an article, to scan those "5 paragraphs" during every edit-preview of that section, and warn about missing phrases, or added "rumors" and advise to discuss the proposed changes first. In many cases, the watchdog might just link a maintenance category, to warn other editors that crucial data items had been removed, or questionable text was now contained in a list of articles. It is far better to have a template run, every time for 1/50 second, to advise an editor not to re-add rumor text or peacock "greatest" phrases, than to have that unwanted text saved and require a revert, plus issue a user-warning about such types of editing. In extreme cases, the watchdog section might cover 35 paragraphs, depending on various essential data items, or related rumors, and run within 1/10 second. In a sense, some watchdog templates would act as per-article, per-section "content filters" but allow the text to appear during edit-preview, rather than totally disrupt the page in the manner of rejecting black-listed websites. If the watchdog activities became too tiresome, then they could be reduced to shorter sections, or have fewer warning phrases, as needed. -Wikid77 (talk) 07:19, 22 October 2012 (UTC)

Does lua properly support character encodings, most importantly multibyte characters and possibly variable length characters? I was under the impression lua has byte-only seeking and comparing. —  HELLKNOWZ  ▎TALK 09:10, 22 October 2012 (UTC)
Not as part of the standard library; see above. A custom C library for UTF-8 string processing was implemented, and Tim Starling chose not to deploy it because of certain objections to the specific design (see the Bugzilla page). That particular library provided no pattern matching functionality, as the plan was to use an existing regex library like PCRE for that. PleaseStand (talk) 09:33, 22 October 2012 (UTC)
  • Letters vary as 1-2 bytes but diacritics work: When running Lua "string.sub(mydata,2)" to omit the first character of a string, I found that accented-letter characters (and other diacritics) use 2 bytes, and I had to omit the first 2 as "string.sub(mydata,3)" and start at the 3rd "letter" to remove the first accented-letter. However, that tactic is working (in October 2012), and I am able to compare the Greek or accented-letters to change to lowercase letters, one letter at a time. Note, as mentioned above, function "string.lower(mydata)" only translates plain letters to lowercase, leaving the accented letters in the string to remain uppercase, so that required extracting each character to compare values. Currently, the searches work to allow regular expressions (regex) to match accented-letters within a string, even though characters have the mix of 1-2 bytes. So, an action of a "watchdog template" could include watching for removal/addition of diacritic spellings, where the issue had reached consensus to use one format, and not re-edit a page to constantly change the accented letters. -Wikid77 14:02/17:03, 22 October 2012 (UTC)
    • It sounds like a workaround that is not consistent. To be honest, I'm not comfortable with such a solution being deployed. For example, what happens when a script fails to detect a character and offsets the remaining text by 1 byte? Suddenly you have a string of gibberish. I don't really know the specifics of this case, but I know what happens when regex/string/encoding aren't being supported/standardized. Our string templates are workarounds, because we don't have any kind of "pure" string function extension enabled afaik, which is really the way we should go. —  HELLKNOWZ  ▎TALK 17:15, 22 October 2012 (UTC)
A chopped diacritic letter affects no others: Lua modules would be used to allow rapid substring, search, compare, and string-length operations. Also, only each accented-letter, split by string.sub(mydata,2), would show a gibberish "[]" character, while the remainder of the text would still be readable; for example "ãfton Åhlens title 'Æther' " would lose only the first "ã" and pinpoint where the text glitch occurred, to direct efforts to fix that word. So, in actual use, all the text is handled properly because any problems are pinpointed so quickly. -Wikid77 08:20, 23 October 2012 (UTC)
  • This sounds hackish. Ignoring whether it's ultimately a useful feature, why should we use templates for functionality that could presumably be migrated to MediaWiki itself? The core issue here is a "watchdog" feature. Some of that functionality may already exist through the edit filter. Improving the edit filter's capabilities would make far more sense than encapsulating huge chunks of article content in {{easily breakable watchdog templates|. {{Nihiltres|talk|edits|⚡}} 17:57, 22 October 2012 (UTC)
  • Watchdog templates/modules easier to update than MediaWiki: In terms of the time-delay logistics, a template or Lua script module can be updated in minutes, or days, compared to the weeks, or months, waiting for the next release of the MediaWiki software. When watchdog scanning of article text is done by a template, then only some portions of an article would be checked, rather than all text, and also, a template could detect improper text coming through a trancluded section of text, while an edit-filter scan might just limit the restriction to text entered at the keyboard for the specific article. A watchdog template would scan all text within a designated section, even when coming from another template. For example, a watchdog template might restrict the measurement units, such as wanting "inch" rather than "centimetre" and catch that word coming from Template:Convert, whereas an edit filter might look only for the input text, with unit-code "in" for inches, and not catch the conversion which puts "centimetre" into the article text. In general, a watchdog template might warn of the spelling "-metre" in articles using American English (with spelling "-meter"), and warn the editor to change spellings before the first SAVE of the edit. Also, there could be several styles of watchdog templates, where editors could choose the style most-effective for their article sets, or switch to a different watchdog template. That allows quick updates to watchdog features, or choosing a separate watchdog style for each article section. As for breakable template markup, there are many ways to "break" an article, and saving a rumor phrase, with no watchdog warning (or category link), could be even worse. -Wikid77 08:20, 23 October 2012 (UTC)
  • We shouldn't do this in wikitext. But the idea is not without merit. Tim suggested yesterday (and if memory serves me well actually suggested it before) that Lua modules might make sense for abuse/edit/tagfilters. Such a thing is not currently planned, but if anyone cares to work on it.... —TheDJ (talk • contribs) 08:28, 23 October 2012 (UTC)
Alerts for grammar/content must be done in wikitext: There have been numerous other discussions, about methods to pre-screen "all" content outside of the wikitext format, but unfortunately, the use of direct quotations in articles requires that the rules must be selectively turned on, or off, multiple times per article, to allow exact quotations, even with misspelled words or grammar errors, to appear in text without pre-screening by edit-filters. We even have Template:sic (" [sic]") to defend misspelled words. Each article, section-by-section, should decide what words or phrases must, or must not, be used in each part of the article. For direct quotations, almost anything is allowed, and so a watchdog template must not be used to reject quoted text from the original quotation. Another crucial point we learned from the slow cite templates: people will still edit articles even when checked for 200 non-used cite parameters in 250 citations, where the time to check for those 50,000 rare parameters was tolerated, even to wait over 20 seconds for an edit-preview of a page. Although 99% of citations can be coded using only 30 title, author, journal, volume, page, date and url parameters, the cite templates always check to allow another 200 alias parameter names. So, by comparison, the idea of waiting to search for just 50-100 specific phrases will seem "instantaneous" compared to the cite templates always checking for those 50,000 unused cite parameters in a major pop culture article. -Wikid77 12:46, 23 October 2012 (UTC)
  • Watchdog for reminders not policing of text: There have been concerns that the "watchdog templates" would be used for so-called policing of text, to lock-out changes until approved by an admin or such. No, instead, the idea is that the watchdog parameters of "watch phrases" could be changed by any user, but act as reminders for what the text should, or should not, contain at that section of the article. For example, years ago, an editor reset the "landfall time" for Hurricane Katrina, as several hours different from the official reported landfall time, and naturally, even though the page was edited numerous times per day, the incorrect landfall time went "undetected" (unnoticed) for 11 days. Now, consider if a watchdog template had been set to check the landfall time, then the changed time would have generated a warning to the initial editor, in edit-preview, and an alert to all readers of the article when saved. Rather than being overlooked for 11 days, every minute the page was viewed, there would be a warning which showed that specific landfall time-of-day as "missing" from the related section. Even novice readers would see the prior time stated, as considered by the watchdog as the important text to show, rather than the adjusted time in the same section. To stop the warning, any user could either restore the landfall time, or change the watchdog text to match the new time. There would be no "policing" of text but rather, just reminding people that the important landfall text had been changed. -Wikid77 11:41, 29 October 2012 (UTC)

What's going on? Pop-ups dead (October 26, 2012)

Last time I came to mention what seemed like a glitch I found that the change had been intentional. I wonder whether I'll be similarly dismayed this time. I found three glitches tody.

  • Pop-up seem to be dead.
  • The edit tool box down the bottom has gone to "copy and paste" mode.
  • The link to my sandbox has disappeared.

What's going on? JIMp talk·cont 03:03, 26 October 2012 (UTC)

Is this the same thing as #What happened in the last hour? (October 25/26, 2012) above? jcgoble3 (talk) 03:18, 26 October 2012 (UTC)
It seems to be, thanks. JIMp talk·cont 04:59, 26 October 2012 (UTC)
Pop-ups are absolutely not working. I've done various troubleshooting routines to no avail. Rivertorch (talk) 08:26, 26 October 2012 (UTC)
Same here. No pop-ups, since yesterday. And NO Edit toolbar. I thought, it was my computer. Now I know it wasn't. Poeticbent talk 15:18, 26 October 2012 (UTC)
Ditto I was using IE8 at the time. Swap to Firefox 16, no problems. NtheP (talk) 16:20, 26 October 2012 (UTC)
My wild guess is that this is related to https://bugzilla.wikimedia.org/show_bug.cgi?id=41428 which was already fixed in the codebase and only affects Internet Explorer. --Malyacko (talk) 11:53, 29 October 2012 (UTC)

fatal exception

I'm trying to save an edit on Functional programming and am getting the error message

[392cc69f] 2012-10-26 21:10:42: Fatal exception of type UsageException

Someone else was getting a similar error further up. The hex number changes across different attempts to save. Something is broken...

67.119.3.105 (talk) 21:11, 26 October 2012 (UTC)

Filing a bug report (see https://www.mediawiki.org/wiki/How_to_report_a_bug ) in bugzilla.wikimedia.org with good steps and info is welcome. --Malyacko (talk) 11:55, 29 October 2012 (UTC)

Fatal exception of type UsageException

I just temporarily created Talk:Internet Archive/FatalException after getting repeated error messages when trying to save Internet Archive. The messages were all of the form:

[63beb818] 2012-10-28 03:08:51: Fatal exception of type UsageException
[5b877839] 2012-10-28 03:10:59: Fatal exception of type UsageException
[12bd8bd6] 2012-10-28 03:16:12: Fatal exception of type UsageException

I may have to try to submit my changes in piecemeal fashion, but I thought I'd ask about the error first. Obviously, there are a lot more checks going on when an edit is submitted to article space than to talk space, more so when they are submitted by an IP editor, so I assume there's a problem with one of those checks. 72.244.206.55 (talk) 03:25, 28 October 2012 (UTC)

I thought that with 2400+ page watchers I might be able to get some advice or help with this. Since I didn't, I worked around the problem. 72.244.206.55 (talk) 05:43, 28 October 2012 (UTC)
This sort of error seems to only originate from within the API, so I can't understand why it would be appearing from normal editing. It looks very strongly to be the fault of an extension, although that still doesn't really solve any problems.
Is the error only occurring when editing long pages? When editing a section? When making substantial changes? Does it appear in your web browser as plain text, or within a normal Wikipedia interface with logo/sidebar/tabs etc?
Perhaps jump on IRC #wikimedia-tech connect next time this happens. — This, that, and the other (talk) 06:51, 28 October 2012 (UTC)
Same as I wrote above under "fatal exception": Filing a bug report (see https://www.mediawiki.org/wiki/How_to_report_a_bug ) in bugzilla.wikimedia.org with good steps and info is welcome. --Malyacko (talk) 11:56, 29 October 2012 (UTC)

Unicode displays as blanks

Don't know what am doing wrong. Unicode displays as blanks, e.g., at Knight (chess), the first sentence: "The knight (    )". The corresponding wikicode looks like this for me: "The '''knight''' ({{unicode|   }} {{unicode|   }}". My WP Preferences are set to browser default font. I set my Mozilla Firefox browser default font to MS PGothic (since that font successfully displays all the chess symbols at this site). I must be missing something basic, can someone help identify what? Thanks! Ihardlythinkso (talk) 07:09, 28 October 2012 (UTC)

I see "The knight (♘ ♞)". The unicode template only works on IE on XP and should yield the default font on other browsers ("The knight (♘ ♞)"), but they all display fine for me. What is your OS? — Edokter (talk) — 09:13, 28 October 2012 (UTC)
Thanks for replying. I have XP Home. Yes I think things changed when I went with Mozilla Firefox recently when IE was going goofy and MSFT had no upgrade for IE after IE ver 8 for XP system. I don't know whether you can see the unicode icons or not, I assume you can, because when you try and display for me what you see, I will see different here (I still see blanks in everything you specified). So is there a way I can see the icons under Firefox? (Or if what you said, "the template only works on IE on XP", means there's no way under Firefox, that's probably my answer, but please confirm, since that is bad news then for me!) Thank u. Ihardlythinkso (talk) 09:24, 28 October 2012 (UTC) p.s. And just thinking about this ... If displaying the icons is a matter of font access, it seems weird that that would change between browsers? (Is there something big in the designs which block application of font interpretation of unicode between browsers? Do you know how that [doesn't] work? (In other words, do you know why the template goes browser-dependent?) Thx. Ihardlythinkso (talk) 09:32, 28 October 2012 (UTC) p.p.s. Okay I just brought up IE ver 8 and see that you can see the icons. If the template doesn't work under Firefox & XP (is it just Firefox & XP, or Firefox & other OSs too?), then doesn't that affect lots of users just not me? Thx. Ihardlythinkso (talk) 09:46, 28 October 2012 (UTC)
The template only targets IE on XP by design, as it has limited support for unicode, whereas other browsers have sufficient unicode support built in. I see the the chess characters in all my browsers on XP, including Firefox. Firefox should map unicode to XP's defaul unicode font, which is Lucida Sans Unicode, in case the character is not present in the default browser font (usually Arial). Check if Lucida Sans Unicode is present on your system. — Edokter (talk) — 10:28, 28 October 2012 (UTC)
Thx for your reply. Yes, I have Lucida Sans Unicode. My Firefox is rel. 16.0.2, and I change the default font by Tools -> Options -> Content -> Default font. When I change to either Lucida Sans Unicode or Arial, the icons are still blank. I cleared my cache a couple ways just in case. (I'm a little confused, because at this site, chess symbols are blank with either Lucida Sans Unicode or Arial too. MS PGothic is one of the few or only that give me symbols at that test site.) The WP "My preferences" look like they can't select font or even default to browser font at second look ... under preferences it is just "Editing" -> "Editing area font style" that I chose "Browser default" (but, I think it means the editing window only; am I overlooking a WP font specification?). So the Q is, why is my result under Firefox diff from yours? Thx for any help! Ihardlythinkso (talk) 11:27, 28 October 2012 (UTC)
To be honest, I have no idea. Language settings in your browser may also affect unicode, as well as the 'Character encoding' setting (under View), which should normally be set to UTF-8. — Edokter (talk) — 11:40, 28 October 2012 (UTC)
I also have Windows XP (Service pack 3) and Firefox 16.0.2, where the default font is Times New Roman. I don't think that I've ever altered this, because the vast majority of web pages these days (Wikipedia not excepted) explicitly set the base font for the page. Within "The knight (♘ ♞) is" I see two chess knights: the first white, the second black. The appearance of these is similar to the images although not identical. --Redrose64 (talk) 14:03, 28 October 2012 (UTC)
Wikipedia does not set a base font; it only sets it to 'sans-serif'. If you click the 'Advanced' button next to the default font, you will see which font Firefox uses for sans-serif (which is most probably Arial). — Edokter (talk) — 14:32, 28 October 2012 (UTC)
Ok, I played around and finally got it! My (Firefox) View → Character Encoding has always been Unicode (UTF-8), so that wasn't it. But when I unclicked the box at Tools → Options → Content → Advanced → "Allow pages to choose their own fonts", I finally get to see the chess symbols. (But my Content → Default font → must be MS PGothic, MS Gothic, or MS Mincho [I couldn't find any others on my sys where the chess symbols would show, e.g. if set to Arial nor Times New Roman then it's back to blanks.])
So I'm back in business, thank you Edokter. And thank you too Redrose64. Ok, Ihardlythinkso (talk) 06:21, 29 October 2012 (UTC)

Are we really using Unicode chess glyphs in prose now? I suppose the chess project should be commended for finding yet another way to reduce the accessibility of their articles. Chris Cunningham (user:thumperward) (talk) 15:08, 29 October 2012 (UTC)

"Now"?! Those glyphs were added to the Knight (chess) article on June 26, 2007. (I don't know dates regarding other chess piece articles, I haven't checked.) My first edit to Wikipedia was September 2, 2010. The pros or cons of using glyphs is not a topic for this thread or board. Why don't you take your opinion or comments or advice to a proper forum for that, rather than leaving snide comments here? (You are an Admin? And like to leave snide comments here because it makes you feel good? Good grief. Grow up.) Ihardlythinkso (talk) 19:18, 29 October 2012 (UTC)

Bug in jsMsg()?

This fairly new notification system has apparently a bug, or I'm doing something wrong. When calling it twice in succession (which can be triggered by going to http://wiki.riteme.site/wiki/Sandbox?withJS=blah.js&withCSS=blah.css, but works with any page), the second instance immediately cancels the first one. They should appear stacked. Can someone provide some insight? — Edokter (talk) — 16:27, 28 October 2012 (UTC)

I was going to suggest using mw.notify but when I tested the following in the console I got the same problem:
mw.notify('foo', {tag: 'test' });
mw.notify('bar', {tag: 'test' });
Helder 17:41, 28 October 2012 (UTC)
Er... just remove the ", {tag: 'test' }" part and it works: mw.notify('foo'); mw.notify('bar');. Helder 17:48, 28 October 2012 (UTC)
Right. jsMsg probably maps to the deprecated mw.jsMessage anyway. Using mw.notify instead. Thanks. — Edokter (talk) — 18:09, 28 October 2012 (UTC)
The point of the tags is indeed to show only one notification of a certain type at a time. A bit more on the supported options here.--Eloquence* 00:29, 30 October 2012 (UTC)

WP 1.0 bot - new maintainer needed

I am going to step down as the maintainer of the WP 1.0 bot at the end of November. A new maintainer for the bot is needed. More information can be found here. — Carl (CBM · talk) 17:10, 28 October 2012 (UTC)

Huggle activation

What should I do to activate Huggle? Oh, I also need the code for User:TruPepitoM/huggle.css. TruPepitoMTalk To Me 05:56, 29 October 2012 (UTC)

Could you clarify what you mean by "activating"? https://wiki.riteme.site/wiki/Wikipedia:Huggle doesn't cover this? --Malyacko (talk) 11:57, 29 October 2012 (UTC)
"Activating" meaning enabling it on my account through the user configuration page, plus adding the code to enable Huggle in huggle.css. TruPepitoMTalk To Me 12:14, 29 October 2012 (UTC)
I think it needs to say "enable:true". See, for example User:ParisianBlade/huggle.css or this list of other examples. -- John of Reading (talk) 12:18, 29 October 2012 (UTC)

Template problems

Could someone with developer rights please look at the NCAA Division I FBS football ranking movements templates. When I try to view any of these I wait ages and get a timeout message: "Sorry, the servers are overloaded at the moment. Too many users are trying to view this page. Please wait a while before you try to access this page again. Timeout waiting for the lock." Specifically, I was trying to delete template:NCAA Division I FBS football ranking movements/testcases coloring. I managed to move it to template:NCAA Division I FBS football ranking movements/tt but I cannot delete it. — RHaworth (talk · contribs) 10:26, 29 October 2012 (UTC)

I deleted it without any problems. Ruslik_Zero 19:11, 29 October 2012 (UTC)

Mine Talk Page Doth Be Glitching!

I've had people try to post on my talk page, but nothing seems to be showing up. Any ideas of what to try? I've purged and it still won't show. Hamtechperson 15:52, 29 October 2012 (UTC)

Somebody had added unclosed <ref> tags, which I have now removed. Reaper Eternal (talk) 15:57, 29 October 2012 (UTC)

JavaScript not loading on my Watchlist?

For some reason, JavaScript isn't loading on my Watchlist. This morning it worked fine, but in the past few hours JavaScript has not been loading on my Watchlist. For instance, I use "Enhanced recent changes", so diffs should be collapsed, but at the moment they are all expanded. I'm also using the Monobook skin. I see no errors appearing in my JavaScript Console in Firefox. JavaScript works fine on all other pages. At the moment my guess is that something was changed in the JavaScript for Watchlists, such as a new variable, that could be conflicting with one of my scripts, so no error is given but something is still broken. I emptied my JS and CSS pages, and still the same problem on my Watchlist, so something seems to be broken on Wikipedia's end. Gary King (talk · scripts) 18:48, 29 October 2012 (UTC)

Link Classifier wasn't working for me on my Watchlist after I read your post, but I just manually reloaded it and it then worked. I would suggest that, and then emptying your browser cache if it doesn't work.--JohnBlackburnewordsdeeds 18:56, 29 October 2012 (UTC)
I already did a hard refresh and cleared my cache. Here's what I narrowed it down to. It appears that one of the pages in my watchlist is breaking the JavaScript in my watchlist, which sounds crazy but it appears to be the case. I have a second test account, which has an empty watchlist. I watched a few pages, and Enhanced Recent Changes works fine there (with about five articles in the watchlist). I then copied my own watchlist to the test account. Then the JavaScript breaks on the watchlist. It also does not appear to be skin-related because I tried Vector and it breaks there too. Gary King (talk · scripts) 19:03, 29 October 2012 (UTC)
It seems that any page that I have resolved feedback using the Article Feedback Tool (it's the thing where new editor can comment on the quality of an article, with a green smiley face, a red sad face, etc.), if I remove those pages from my watchlist, then my watchlist JavaScript is fixed. Gary King (talk · scripts) 19:15, 29 October 2012 (UTC)
Okay I'm pretty sure I figured this out. This one page that I'm watching has unmoderated comments (comments that are awaiting an action, such as hiding it). Since this is the case, Wikipedia usually gives a message saying something like "one of the pages you are watching have unmoderated comments". It seems that this message, as of very recently (six hours ago or so), breaks the Watchlist's JavaScript. I know this because moderating all comments or removing the page from my watchlist fixes the Watchlist. I've already sent an email to hopefully the right person with regards to the AFT. Gary King (talk · scripts) 19:24, 29 October 2012 (UTC)
You are absolutely correct. This is a reoccurrence of the same bug that we saw with this tool last week. I have already pinged the foundation developers (and informed them that this simply should not happen 6x a week). —TheDJ (talk • contribs) 20:02, 29 October 2012 (UTC)
Thanks and thanks; we're on this :). Ironholds (talk) 20:39, 29 October 2012 (UTC)
Fix hopefully in; can someone clear their cache and test? Okeyes (WMF) (talk) 20:58, 29 October 2012 (UTC)

WebCite error

When I try to archive a url with WebCite or try to retrieve a previously archived one, I get

Warning: mysql_pconnect() [function.mysql-pconnect]: Too many connections in /home/webcita/public_html/lib/adodb/drivers/adodb-mysql.inc.php on line 367 DB Connection failed

Now of course WebCite is not a Wikimedia site, but it nevertheless affects my editing of Wikipedia, since I just wanted to cache a url used as a citation in an article. So lets hope this will be fixed soon. -- Toshio Yamaguchi (tlk−ctb) 20:30, 29 October 2012 (UTC)

Perhaps you could try contacting them? ^demon[omg plz] 21:42, 29 October 2012 (UTC) 21:42, 29 October 2012 (UTC)

WP page editor changes

Where does one go to discuss recent changes to the WP page editor? Contact Wikipedia is not much help. Does anyone know who the individual(s) is that adds or removes features to the WP page editor? i.e. pop up message telling editors 'Your edit was saved' is annoying and sort of insults the intelligence of those who have edited on Wikipedia for more than ten minutes. Is this the beginning of more pop-up messages? IMO this graphic pop-up image/message is a waste of server resources. -- Gwillhickers (talk) 19:10, 27 October 2012 (UTC)

There is a section above announcing the feature and explaining why it was enabled. If you don't want to see it, just add .postedit { display: none; } to your personal CSS. Steven Walling (WMF) • talk 00:56, 30 October 2012 (UTC)

I've never posted in the teahouse but it's in my contributions

And I can't find where I posted when I get there.

I've never been there because it seemed confusing when I was used to a certain setup. I see now it's like the Help Desk but in reverse order.— Vchimpanzee · talk · contributions · 19:15, 29 October 2012 (UTC)

No, but you have posted to Wikipedia:New contributors' help page/questions, which yesterday was moved to Wikipedia:Teahouse/questions. --Redrose64 (talk) 19:53, 29 October 2012 (UTC)
Then where is my edit?— Vchimpanzee · talk · contributions · 20:15, 29 October 2012 (UTC)
Okay, this might be a clue. My contributions say "Teahouse/questions" but that sends me to a redirect page with the correct capitalization. There are about two weeks that are not archived.— Vchimpanzee · talk · contributions · 20:23, 29 October 2012 (UTC)
(edit conflict) Your several posts were removed with this edit, which appears to be the first half of a WP:CUTPASTE violation - I can't find the second half (i.e. the place where this text was pasted to). I suggest you take it up with AnnaHendren (talk · contribs); when the destination is located, it may be necessary to file a request at WP:REPAIR so that Anthony Appleyard (talk · contribs) can see if it can be rescued in a proper manner. --Redrose64 (talk) 20:29, 29 October 2012 (UTC)
Thanks. I may not be the only person this happened to. Fortunately, I was attempting an answer, not asking a question.— Vchimpanzee · talk · contributions · 20:42, 29 October 2012 (UTC)
I archived the last two weeks questions and answers to Wikipedia:New contributors' help page/Archive/2012/October. See Wikipedia talk:Teahouse#Change from NCHQ to here for more discussion about what happened and what should be done next. -- John of Reading (talk) 21:02, 29 October 2012 (UTC)
Aha, so this edit is the second half of the WP:CUTPASTE. --Redrose64 (talk) 21:17, 29 October 2012 (UTC)
Can we get any c/p problems undone, please? AnnaHendren has been responsible for a number of questionable actions this week and in light of her apparent lack of desire to explain them the obvious course of action would be to revert them. Chris Cunningham (user:thumperward) (talk) 00:31, 30 October 2012 (UTC)
The background to this can be found at Wikipedia talk:Teahouse where a possible merger with the help desk pages was being discussed but certainly hadn't been fully resolved. The move and redirect are premature and should be reverted. 07:52, 30 October 2012 (UTC)
Any admins about here? The content and history at Wikipedia:Teahouse/questions (the redirect, not the Wikipedia:Teahouse/Questions page) needs to be moved back to Wikipedia:New contributors' help page/questions. -- John of Reading (talk) 08:03, 30 October 2012 (UTC)
Well, I'm an admin; but I don't have any experience of fixing WP:CUTPASTE problems, which is why I suggested Anthony Appleyard (talk · contribs) who has plenty of experience. --Redrose64 (talk) 08:08, 30 October 2012 (UTC)
I don't think this is a cut+paste problem. Someone needs to undo AnnaHendren's edits to Wikipedia:Teahouse/questions, and an admin needs to move it back to Wikipedia:New contributors' help page/questions over the redirect. The history of the noticeboard page needs to stay with the noticeboard, so this is just an ordinary page move. -- John of Reading (talk) 08:39, 30 October 2012 (UTC)
I've done this, this and this, so as far as Wikipedia:New contributors' help page/questions is concerned, it's back to how it was at this point. --Redrose64 (talk) 09:06, 30 October 2012 (UTC)
...and I have reverted the changes to the WP:NCHPQ redirect page and the links from Wikipedia:New contributors' help page/Header. Gandalf61 (talk) 09:48, 30 October 2012 (UTC)
Thank you, I think WP:NCHQ is back in business, at least until the merge discussion is closed. -- John of Reading (talk) 09:36, 30 October 2012 (UTC)
AnnaHendren's talk page has been archived. So that tells us how cooperative she will be.— Vchimpanzee · talk · contributions · 22:07, 30 October 2012 (UTC)

Wikipedia is messed up

Is anyone else experiencing something very messed up with the Wikipedia appearance? The layout of reading and editing screens is messed up. My initial guess is it's something wrong with CSS, but it's also very slow. I've had this happen before but refreshing the page fixed the problem. This time refreshing does nothing. I'm running windows 7 and the problem exists on Chrome. I've also tested on IE9; however, I'm unable to open Wikipedia in that browser. Scratch that, opening it took about 5 minutes and I have the same problem. I haven't gotten the file upload wizard to work so here are some links to screenshots. VPT reading window, VPT edit window, main page. It would be great if someone responding could ping me on my user page since the watchlist is difficult to use. Ryan Vesey 02:03, 30 October 2012 (UTC)

That is a missing bits server. Remember that Sandy is still ongoing and also right now we are seeing some issues with cross-atlantic connections if I read the IRC channel correctly. Remember that there are major internet exchange points in that area, it is not unexpected to see some spotty connectivity today because of that. The operations staff seems awake and trying to deal with it. —TheDJ (talk • contribs) 08:14, 30 October 2012 (UTC)
I've also experienced Wikipedia to be very slow the last couple of days (beginning Sunday or Saturday, before Sandy), also on Windows 7 and Chrome. When reverting or editing large articles it often times out, but then when I try again it says I did make the edit after all. --Saddhiyama (talk) 10:36, 30 October 2012 (UTC)
Wikipedia is working fine for me now, but the part I found interesting was that I had an excellent signal so there was nothing wrong with my internet connection. Ryan Vesey 15:01, 30 October 2012 (UTC)
Your internet connection goes only as far as the neighborhood distribution point. From that point starts the web and many more things can go wrong that are not really visible to you. If someone would cut your line at the neighborhood distribution point, you would still have perfect signal, there just wouldn't be any place you can reach. There are millions of those points and every single one that you 'happen' to cross and that is damaged might destabilize a small part of your connection. Many times when you can't reach 'a part' of the internet, it's neither you nor the destination that is to blame. It's one of the thousands of points that are between those two. A storm like sandy is disruptive by definition. The internet will survive (because it's designed like that), but it will almost certainly create hinder. —TheDJ (talk • contribs) 17:15, 30 October 2012 (UTC)

A Halloween Trick?

Why have devil faces appeared in the last few DYKs on my DYK page?--Gilderien Chat|List of good deeds 00:58, 31 October 2012 (UTC)

You guessed it: Because it's halloween.[11] The devil faces are only displayed 31 October (UTC). PrimeHunter (talk) 01:53, 31 October 2012 (UTC)

Windows 8 DID YOU KNOW?

Hey where the @%#% did the Did you Know section go? It's integral to this Wikipedia and I'm appalled that it hasn't been included in the app for windows 8. boo. (urns)142.30.225.226 (talk) 01:47, 31 October 2012 (UTC)

Is this about Wikipedia:Mobile#Windows? The first "Read more" at [12] says "Send us your feedback on Twitter @WikimediaMobile." PrimeHunter (talk) 02:01, 31 October 2012 (UTC)
Hey breh, I need my hand held, I'm not sure what you were trying to tell me. I need my Did you Know dawg! Where can I like, stir it up and have it added to the Win8app? tyty — Preceding unsigned comment added by 142.30.225.226 (talk) 02:05, 31 October 2012 (UTC)
I posted where you can send feedback on Twitter. I haven't seen the app but I guess from your post that it removed Template:Did you know and possibly other parts of Main Page to make it more friendly for small screens. Maybe you can see it at Template:Did you know, or see a full main page at for example Wikipedia:Main Page/1. It may not be synchronized with all Main Page changes but the Did You Know box should be the same. PrimeHunter (talk) 02:22, 31 October 2012 (UTC)

Wikipedia skins

Please, please some wiki tech guru design a new skin or two, the skins we have are getting boring. We should have the choice to design our own skins or at least have more choice. Presentation of information and graphics is really important. Foundation people, please get a designer to create some new ones.... ♦ Dr. ☠ Blofeld 14:33, 29 October 2012 (UTC)

Sorry but this has been found to be technically impossible. They tried, but they couldn't get the skins thin and hypersensitive enough to match the personality of a typical Wikipedian.... ;) Zad68 14:42, 29 October 2012 (UTC)
Couldn't find a "dramatic" enough design eh?♦ Dr. ☠ Blofeld 15:08, 29 October 2012 (UTC)
Instead, there are plans to remove several old skins:) Max Semenik (talk) 15:27, 29 October 2012 (UTC)
Well Vector, Monobook, Cologne and Modern are of course the better ones but if they're going to throw out those old skins at least create some new ones which are up to date graphically.♦ Dr. ☠ Blofeld 18:11, 29 October 2012 (UTC)
I don't think it should be the Foundation's responsibility to create a slew of themes for the site. The fact that they allow multiple themes is weird, in my opinion; what other major website allows that level of customization? The existing themes are "boring" because we see them day in, day out; there's a certain benefit to keeping things consistent, especially considering how much time it would take to introduce multiple themes and make sure every bug is ironed out. EVula // talk // ☯ // 18:42, 29 October 2012 (UTC)
If folks are interested in pushing for more modern skins, I think there are designers at the Foundation who would agree. I would check out some of the ideas here, for instance. However, the question of designing new skins has less to do with whether it's our responsibility, and more to do with how we prioritize projects for the year. For a broad roadmap to compare skin work to, I'd look at Wikimedia Engineering/2012-13 Goals. Steven Walling (WMF) • talk 19:12, 29 October 2012 (UTC)
New skins doesn't sound like something the foundation should be working on. Perhaps they should instead create a simple gallery where people can submit CSS pages so others can easily try them out and install them? I agree that no other major website offers so much custom CSS, which they shouldn't because design should focus on the best consistent experience, not on dozens of different skins which each could present their own problems. Too much of a headache to support. But if the skins were done by community members, then it would be better. Gary King (talk · scripts) 19:30, 29 October 2012 (UTC)
"New skins doesn't sound like something the foundation should be working on." Just to be clear: we agree, right now. The Athena stuff is not an upcoming new skin. The 2012-13 roadmap doesn't include release of a new skin, though of course there will be design updates and new features on desktop and mobile. Steven Walling (WMF) • talk 18:20, 30 October 2012 (UTC)
Just a clarification about my earlier statement: I don't think think it should be the Foundation's responsibility to have a plethora of styles for users to choose from, but making the default theme that the projects use visually pleasant and engaging is something that the Foundation should concern itself with. I'm thrilled with the UI modifications you guys have been pushing out lately. EVula // talk // ☯ // 22:51, 31 October 2012 (UTC)
This looks awesome Steven! Something which puts a panorama image across the top looks great. I'm sure many of the ideas would prove popular Steven. ♦ Dr. ☠ Blofeld 19:35, 29 October 2012 (UTC)

Info boxes need to know how to count

Spinoff: Template_talk:Infobox_person. -Wikid77 11:01, 31 October 2012 (UTC)

The info box for a famous person includes "spouse(s)" in the list. It should be either singular or plural. The quantity is not ambiguous. The wiki markup field is labeled "spouse". The person I looked up has had only one spouse. The wiki rendering of the template is insulting in that it anticipates the possibility of a divorce. That is not encyclopedic. Whether a person had none, one, or multiple spouses is a fact discernible by the software. Please make it so. - 71.179.117.235 (talk) 03:23, 30 October 2012 (UTC)

It is not easy to discern this automatically...as a quick check, I saw multiple spouses listed as separate lines, with commas, with semicolons, and with spaces (using parentheses to list each one's years), but also separate lines, commas, and parentheses used for other reasons there. I think it's also fairly difficult (or at least expensive) using current software to find arbitrary text in a field value (crazy, no?) even if everyone agreed that "semicolon separates consecutive spouses". Better to leave it to editors, who don't need to guess what is meant...have separate "spouse" vs "spouses" fields for these two separate cases? On the other hand, you might be seeing a moral problem where none exists...fact is famous people do get divorced and remarried often, but also spouses die and the survivor gets remarried. DMacks (talk) 04:18, 30 October 2012 (UTC)
  • Two parameters for spouse/spouses would be fastest: If checked by a "gated-if" structure, then the overhead would be about 1.2x (only 20% slower in that 1 option) to check for both parameters:
  • {{#if:{{{spouse|{{{spouses|}}} }}} then #if {{{spouse|}}} singular, else plural.
If the spouse/spouses parameters were commonly used, rather than rare, it would be faster to check each separately, as if 2 unrelated options. Anyway, checking for both would likely be 30x faster than a semicolon search, and much faster than also searching commas or "<br>" tokens in the spouse parameter data. I think the option to avoid form "spouse(s)" sounds reasonable, and much better than "spouse(s) or live-in(s)"! Anyway, for some people who think "mate for life" then there is only one spouse, ever. -Wikid77 (talk) 05:01, 30 October 2012 (UTC)
You didn't note which template,so we can't give a specific answer. Please discuss on the template talk. See how {{Infobox WorldScouting}} handles |founder=. ---— Gadget850 (Ed) talk 05:55, 30 October 2012 (UTC)

DMacks correctly identifies this as a matter of the field being freeform in some (but not all) cases. We can't change the label until existing transclusions are updated. As such, this is something which needs to be driven on a per-template basis: the actual technical fix is, as Wikid77 demonstrates, trivial once that's done. Chris Cunningham (user:thumperward) (talk) 10:55, 30 October 2012 (UTC)

  • Plan for "spouses=" or "spouse=" or "spouse1=": I have submitted a plan to allow all 3 parameters, in Template_talk:Infobox_person, where original "spouse=" would auto-detect the plural as a break-wrap "<br...>" (with {has_char} ) but allow "spouse1=" to force label as "Spouse" singular, such as re-marrying the same one. Plus, for over 5 years, editors have been using unsupported parameter "spouses=" (plural) which displays nothing at all, as used in 3% of those articles (about 2,800 of 89,000). Hence, the fix also allows the 3rd option as "spouses=" plural. Join discussion at:
Depending on the outcome there, then other infoboxes could be enhanced to auto-detect the singular/plural "spouse=" and allow new parameters "spouses=" or "spouse1=" singular. -Wikid77 11:01, 31 October 2012 (UTC)

Translation tool (or better: language comparison tool)

I've been busy with a translation and i found myself navigating wikipedia pages and their correspondent in other languages for learning the translation of specific words or definition. When it comes to technical topics, this is the only tool that i found that is reliable and universal at the same time

So, i thought it would be nice if wikipedia had its own "translator tool" The features included would be:

  • selection of two languages
  • one search box for each language
  • visualization of 2 wikipedia pages simultaneously side by side, one for each chosen language
  • capability of normal navigation through links in each side page
  • a linked / not-linked options to determine wether or not one side page has to be update every time the other changes
  • when the linked option is on, every time a page is visited on one side, in the other side appears the correspondent page in the other language if exists. if it doesn't exist appears a blank page
  • when the linked options turns on, the newer side page remains and the older gets updated
  • disambiguations pages get "translated" if possible
  • search results don't get "translated", and a later page visit on the other side overrides them (when sides are linked)

minor features:

  • keyboard shortcut for the linked / not-linked option

i'm sorry that i'm proposing this, hoping that somebody will accept it and realize it, but right now i wouldn't now when and where to start, even if it seems to me that can be created as an outside tool that merely uses wikipedia pages and tools — Preceding unsigned comment added by Dragomang87 (talk • contribs) 15:52, 30 October 2012 (UTC)

Links to start: mw:Extension:Translate and mw:Help:Extension:Translate. Some have also found wm2012:Submissions/Cross-lingual Wiki Engine interesting. --Nemo 11:12, 31 October 2012 (UTC)
On Wikisource they use a script to show two versions of a text side by side. Take a look at this and this example or find a work with interlanguage links and click in the "⇔" shown in the sidebar.Helder 00:35, 1 November 2012 (UTC)

Rollback and edit conflicts

When I try to rollback an editor and get an edit conflict, the "Return to page" message links to the Main Page instead of the page I rollbacked. The message links to the proper page in other situations. I have never seen that "edit conflict" message in rollback until recently. Is the Main Page -linking a limitation of some sort or is it just an oversight? I'd just point this out, as it doesn't really bother me, as I can use the tabs in the top of the page to navigate. Klilidiplomus+Talk 21:00, 30 October 2012 (UTC)

Might be due to some recent changes. Could you file a report in the issue tracker at https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki&component=History/Diffs if possible? --Malyacko (talk) 13:42, 31 October 2012 (UTC)

Notice: editing enabled on mobile Beta site

Just a quick FYI that the WMF mobile team is trying out a very early developer prototype of a mobile-friendly editing feature on the Beta Wikimedia mobile site, so if you see some odd-looking edits with edit comments containing the phrase "via mobile" in recent changes, don't panic :)

To limit usage, we've restricted this to logged in users only for now. If you have an account, you can try it out for yourself, but please use caution – this feature is still highly experimental, but your changes are going live on Wikipedia, and some issues are likely to crop up (such as this newline bug I just encountered). If you do happen to test it out and notice any bugs, please report them on the talk page on Meta. Thanks! Maryana (WMF) (talk) 01:10, 31 October 2012 (UTC)

Great progress! I left some feedback :) 155.201.35.58 (talk) 16:39, 31 October 2012 (UTC)
Thank you! We hit a major content-removal bug right away that we're working on fixing, so it should look work better soon! Maryana (WMF) (talk) 16:56, 31 October 2012 (UTC)

Coordinates are now dropping behind text

Latest problem. Windows XP, Firefox 16.0.2, Modern skin - This issue did not exist an hour or two ago. It's new. Coordinates that used to be at the upper right hand top of the window, are now dropping down to Infobox level. Depending upon the infobox, those coordinates are dropping behind text and being obscured, such as in Civilian Conservation Corps Camp in Koke'e State Park and Mesa, Arizona or they're dropping down to hover just above the infobox, such as in Binghampton, New York. — Maile (talk) 18:41, 31 October 2012 (UTC)

I'm on Vista, Firefox 16.0.2, and Vector skin, and I'm not seeing this. All three articles you linked appear fine to me. Can you post a screenshot of what you're seeing? jcgoble3 (talk) 18:57, 31 October 2012 (UTC)
Actually, I see it now that I look at it in Modern. So it appears to be a skin issue. Vector and Monobook are fine, while Modern is broken. I haven't checked any other skins. jcgoble3 (talk) 19:00, 31 October 2012 (UTC)
Yes, you are correct - it's the skin. If I change to MonoBook, it's fine. Modern skin is the problem— Maile (talk) 20:29, 31 October 2012 (UTC)
Please ALWAYS state if you are using a skin other than Vector when you report a problem. Can someone help me remember where exactly the coordinates should be rendered for modern ? Then we can fix it by adapting our MediaWiki:Cologneblue.css, since this is en.wp specific styling. —TheDJ (talk • contribs) 20:59, 31 October 2012 (UTC)
Well, OK, but I did start out by saying I was using Modern skin. Anyway, I'll have to tell you from memory where it should be. This is when coordinates are supposed to be in the title. There's a gray bar across the top that contains something like "A C-class article from Wikipedia, the free encyclopedia" on the left-hand side. Within that same bar - but with a right-hand alignment is where the coordinates had always been. As I say, I'm telling you from memory. The coordinates might have been on the bottom of that bar but tight enough to have no space between the coordinates and the bar. Now they've slipped down into the Infobox, behind the title that's right above the image or map. — Maile (talk) 21:07, 31 October 2012 (UTC)
No idea what caused it, but I adjusted the top position for #coordinates in MediaWiki:Modern.css, so it should display properly now. — Edokter (talk) — 21:40, 31 October 2012 (UTC)
Yes! Thank you! — Maile (talk) 21:42, 31 October 2012 (UTC)
Tracked in Phabricator
Task T43342

There seems to be something odd going on with the search box within the last week or so. I type in a search term, and one or more relevant items might appear, but when I move the cursor into it, often I get a different list. As an example, I typed "the beatles", and at first it showed items beginning with "the beatles", then it jumped to all items starting with "the be". This kind of thing happens on both home and work PC's. Any idea what's going on with this? It never used to do this. What changed in the last week or two? It started happening when the word "Search" started to appear in the search box, instead of normally being blank. ←Baseball Bugs What's up, Doc? carrots→ 04:42, 24 October 2012 (UTC)

I could not reproduce this.  Hazard-SJ  ✈  05:14, 24 October 2012 (UTC)
Everything seems fine with Safari 6.0.1. What browser(s) and version(s) are you using? –– Anonymouse321 (talk • contribs) 05:28, 24 October 2012 (UTC)
IE 8, for both home and office. ←Baseball Bugs What's up, Doc? carrots→ 05:30, 24 October 2012 (UTC)
I've asked the editor Marnette, who experienced a similar problem, to come here and comment. ←Baseball Bugs What's up, Doc? carrots→ 05:33, 24 October 2012 (UTC)
Tracked in Phabricator
Task T43349
My search box is currently not showing any suggestions, just standard auto-complete entries.--Atlan (talk) 06:38, 24 October 2012 (UTC)
Created a ticket. There have been some changes to the search drop down over the last weeks, so I guess one of those changes is tripping up IE8. —TheDJ (talk • contribs) 08:08, 24 October 2012 (UTC)
As for my problem, it occurs in Cologne Blue skin. It always appears to me bug-fixing Cologne Blue is no more than an afterthought to the programmers.--Atlan (talk) 09:40, 24 October 2012 (UTC)
This is correct. The only truly supported skin is Vector. The monobook skin is actively maintained. The others, usually only see changes if there is feedback about problems. There is also a discussion atm to remove some of the skins, because no one ported them to the new structure (in over 7 years of time). CologneBlue was on that list, but then someone ported it. This is also the reason why you are currently seeing some of the changes in cologneblue. —TheDJ (talk • contribs) 11:14, 24 October 2012 (UTC)
Okay, thanks for the info. Should I file this problem as a bug or can I expect this to be fixed in the near future? I happen to like Cologne Blue so I'd rather not switch. :) --Atlan (talk) 11:42, 24 October 2012 (UTC)

This is belated as I have only just logged back on. After months have having anything that I typed in the search box bring up a list that kept refining itself as I continued typing - which was very useful BTW - that function completely stopped two days ago. I hope that it get restored. MarnetteD | Talk 14:49, 24 October 2012 (UTC)

  • FYI, I see this glitch occasionally, and I have no customisations of any sort. 86.160.216.252 (talk) 20:08, 24 October 2012 (UTC)
  • The search suggestions script used by the vector skin recently replaced the generic script used in other skins, hence why the suggestions may be acting a little differently than folks are used to, but from what I can tell it's working as intended where it's working at all (such as in monobook). That it isn't working in cologneblue is a bug, however not necessarily one with much priority to fix as the entire skin is currently undergoing an overhaul as part of a drive to remove or update all legacy skins. -— Isarra ༆ 21:20, 27 October 2012 (UTC)

Force update of articles in a category

A little challenge with the administration of clean-up pages. I am looking at editing an article clean-up template so that it checks if the article has a talk page or not. If there is no talk page it will add the article to a maintenance category. It is working how I would expect it to work but not exactly how I want it to. If you add the template to the article page and there is no talk page it is added to the category. If you then create the missing talk page the template output on the article page will update by simply refreshing the page. However the article will not be removed from the category until you force an update to the article by editing it. Is there another way to force an update of the article so that the category correctly reflects the status of the talk page without editing the article page? --Traveler100 (talk) 11:46, 27 October 2012 (UTC)

You can wait some time, usually a few hours. Ruslik_Zero 11:57, 27 October 2012 (UTC)
Not sure this will happen as purge does not update categories.--Traveler100 (talk) 16:42, 27 October 2012 (UTC)
I know this technically involves editing the article, but a Null edit will do the trick. Graham87 13:51, 27 October 2012 (UTC)
Would work on a single page but really want to do it on all the pages in a category (about 400). Could null edit the template but as over 170,000 articles use it. This would not make me popular. --Traveler100 (talk) 16:42, 27 October 2012 (UTC)
The job queue should handle it. --Redrose64 (talk) 18:33, 27 October 2012 (UTC)
I'd say do this on toolserver rather than adding another template. 67.119.3.105 (talk) 19:26, 27 October 2012 (UTC)
That was my first preference, this solution is second choice. I have asked for a tool to list all articles in a category that have no talk page in a number of locations (does not appear to be an official location), but no one has come forward to help. Anyone willing to assist or explain how I can create such a tool? --Traveler100 (talk) 19:30, 27 October 2012 (UTC)
There is a template (and image cache, etc) update routine through the API, see also Wikipedia:Bots/Requests for approval/Joe's Null Bot. mabdul 20:03, 27 October 2012 (UTC)
Thanks, but I was think more along the line of a tool something like Image checker or CatScan that could be places as a link in the category page and dynamically check which do not have a talk page.--Traveler100 (talk) 20:20, 27 October 2012 (UTC)
Is there a particular category for which you want this? If the number of categories and articles is not too large, then yeah, an API client would be straightforward. Otherwise you'd be better off running SQL queries on toolserver. (I don't know if this is the right place to ask for someone else to write a toolserver script, if you're not up to doing it yourself).

Why do you want it anyway? I've never understood why some editors consider it important that every article have a nonempty talk page, if there hasn't been any active discussion. Talk page page tabs used to be redlinked all the time, and a bluelink in the tab meant there was some possibly-relevant discussion there. If the link was red you knew there was no discussion so there was no need to cick it. Now the bluelink doesn't mean anything (because talk pages often have wikiproject templates with no discussion) and you have to actually click the link and wait for the page to load, to find out if any discussion has taken place. 67.119.3.105 (talk) 20:31, 27 October 2012 (UTC)

I am look for a way to easily list articles in a category that do not have talk pages as part of a collection of techniques to reduce the very large backlog of articles needing clean-up. In particular I am looking at orphaned pages. With over 170,000 it is a task not possible for a small group of people to address, the task needs to be distributed though-out the Wikipedia community. If you look at a recent month of tagged Orphaned articles 30% of the articles do not belong to a WikiProject or even have a Talk page. Here is a snapshot from a couple of days ago that took some time to manually build. The idea is to easily identify these pages then add a WikiProject to them, this will bring the articles to attention of subject experts who hopefully can better address the clean-up requests. --Traveler100 (talk) 04:41, 28 October 2012 (UTC)
You can request Toolserver queries through its query service. Graham87 08:10, 28 October 2012 (UTC)
  • The way to fix a list of articles is to submit them as an active list of articles to fix by people who actively fix articles, not create a WikiProject-tagged talk-page for each one: If the goal is to truly fix a set of articles, then those articles should be edited, rather than creating and tagging their talk-pages. If a WikiProject should be involved, then write a note to the WikiProject members who actively edit those types of articles, and either link to a category of pages, or just list all the pages to be edited for improvement. Just putting notes in a talk-page can have little impact, for years and years. -Wikid77 (talk) 15:35, 28 October 2012 (UTC)
  • To find pages in a category with no talk page, fire up your illegal version of AWB, make the list of pages in the category, convert (rt click the list and select the option) to talk pages. Now run "preparse" mode with all changes turned off, logging off, and "skip if exists" turned on. You will end up with a list of non-existent talk pages. You can use this or convert back to subject pages. Rich Farmbrough, 23:56, 1 November 2012 (UTC).

Deploying Timed Media Handler here on October 31 November 1

Hi everyone, we plan to deploy mw:TimedMediaHandler to this wiki at 16:00 UTC on October 31, pending fixes to all known blocking issues. TimedMediaHandler is a new open source video player which will result in a vastly better video playback experience than what is currently available using our current video playback system. If you'd like to see this in action or otherwise help test, visit the TimedMediaHandler page on test2.wikipedia.org. For more information about the development and deployment of this extension, visit the TimedMediaHandler page on mediawiki.org -- RobLa-WMF (talk) 06:38, 30 October 2012 (UTC)

Update: we're postponing the deployment a day while we sort out issues. New deployment time is November 1, 16:00 UTC. -- RobLa-WMF (talk) 01:08, 31 October 2012 (UTC)
This is now complete... 109.224.134.228 (talk) 18:02, 1 November 2012 (UTC)

GregU's superb dash script is suddenly gone!

Colleagues, thanks for your prompt and excellent assistance in response to my occasional requests here.

The dash script has been up and running for three years. It's widely used by scores of gnoming editors to change hyphens to en dashes where indicated by MOSDASH and the major style guides on both sides of the Atlantic (except appositional usages that can't be done automatically ... no problem, humans fix that). It's one of our most successful scripts, with very few false positives, and gives en.WP a professional look for sentence-level interruptors, year ranges, and list separators. Importantly, it also allows Windows users to get around the absence of the dash from their keyboard.

Since Friday or Saturday, the button for the script (in both display and edit modes) no longer appears on the tab – usually the tab that includes "Move" and "help, please". Instead, we now see "auto ed" rather than the dash symbol.

GregU hasn't been active since last year, and doesn't have email enabled, so I don't know whom to ask for assistance. I wonder whether someone could assist. Many editors would be appreciative. (I'm a tech dummy.) Tony (talk) 09:31, 30 October 2012 (UTC)

I raised this on AotoEd's talk page but have had no response as yet. Keith D (talk) 23:17, 30 October 2012 (UTC)
I noticed that a little while ago. I was a little shocked until I realised that the "auto ed" link did exactly the same thing as the old script. I have no idea what has caused the link title to change; the page history for the script does not shed any light on this issue. Graham87 11:23, 31 October 2012 (UTC)
It doesn't work at all in Firefox, though. As Graham noted, it's not that anyone has fiddled with the script, it's that one of the new MediaWiki updates appears to have wrecked it. It would be really appreciated if anyone who knows how to write scripts could take a look at it. Jenks24 (talk) 11:37, 31 October 2012 (UTC)
I think it should now be fixed, after this change. Might require purging your browser cache. —TheDJ (talk • contribs) 15:23, 31 October 2012 (UTC)
Thanks that appears to have fixed the problem. Keith D (talk) 18:06, 31 October 2012 (UTC)
My thanks as well, DJ. Jenks24 (talk) 09:17, 1 November 2012 (UTC)

Lose login on secure server when jumping to new page

When I'm logged in on the secure server and jump to another page, I have to log in again (which is especially inconvenient since I have to remember the page I was on). This doesn't happen on the regular server. Is this a known problem (I use XP, and my browser is Firefox 16.0.2)? Thanks and all the best, Miniapolis (talk) 14:25, 31 October 2012 (UTC)

There are two base URLs for the secure server - the current one is https://wiki.riteme.site/wiki/Main_Page and the old one is https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page - which are you using? It changed just over a year ago, and the old one does not have all the features of the current secure server. --Redrose64 (talk) 08:55, 1 November 2012 (UTC)
More specifically, you should absolutely stop using the old secure.wm.o server and use the normal domains with SSL. If you've got bookmarks to the old server, I suggest updating them. ^demon[omg plz] 11:58, 1 November 2012 (UTC)
Thanks; I have the current secure URL bookmarked to take me directly to the login screen. The problem seems to have resolved itself, and I didn't know you could be logged onto the normal and secure servers simultaneously. Thanks again and all the best, Miniapolis (talk) 17:44, 1 November 2012 (UTC)

Can we have a category/policy around animated GIFs?

I feel like a lot of the time when there is an animated GIF I want to edit it out of an article because many make it difficult for me to read a nearby paragraph and unfortunately browsers do not come standard with an image hiding / ad stopping context menu option.

Can all animated GIFs please be added to a category. Maybe a bot could do it. And can all animated GIFs (animations in general) have a hide button added to them for accessibility sake? I'm surprised this has never been brought up and would be more surprised if anyone thinks this is a bad idea --184.21.215.174 (talk) 16:27, 31 October 2012 (UTC)

The category thing could be tricky, since most images are on Commons. Rich Farmbrough, 00:19, 2 November 2012 (UTC).

Wiki "; for definition" markup

At Help:Wiki markup there is an example: ;A defined term: A semicolon at the start of a line is a way of making a definition where the word being defined appears in bold. The definition itself follows the colon and is not rendered bold by default. It is not a heading and does not appear in the table of contents. The words "follows the colon" seemed odd, as there was no colon. I wondered if it meant "on the next line" and thought about posting a query on the article's talk page. However, when I looked there I found this content from 2010 which explains that the idea that the definition will use : markup so that it is indented under ther bolded term. And then Richardguk says:

In practice, semicolons are usually used to make a very minor subheading – one that will not appear in the table of contents. With colons used mostly for simple indentation, this means that they are very rarely paired with semicolons, despite the HTML implying that they should be. But we ought to explain to people what the semicolon does so they understand why some subheadings are formatted very differently from the ==usual== heading styles. In effect, the Wikitext semantics have now diverged from the HTML semantics, despite the Wikitext being converted to <dt> and <dd> when rendered.

I repeat, that was in 2010. Now fast forward to the present. I was just browsing the edit history of WP:MOS, and I noticed a series of recent changes by Gadget850 that are explained as:

  • convert dl markup used to bold a line to bold markup (dl without dd is invalid HTML5)

Gadget850 seems to be saying that because of the way ; is translated into HTML, it is producing HTML that is no longer valid — or perhaps he/she means that this is true in the case where : does not follow it. He/she also considers that ; is "dl markup", i.e. that it promises a particular translation into HTML; that surprised me and is what sent me to the help page in the first place.

I know very little HTML and don't try to be aware of what wiki markup is translated into what HTML, but this seems like something that should be thought about by those who do understand it. We don't want to have wiki markup that can't be used for this sort of reason! On the other hand, if Gadget850 is mistaken, perhaps someone could communicate with him/her.

(I don't intend to pursue this myself, I'm just calling attention to it.) --50.100.189.5 (talk) 10:31, 1 November 2012 (UTC)

Wikipedia previously rendered XHTML, where the <dl> tag was a "definition list" that contained groups of terms and their definitions. As of September 17, 2012 we render HTML5, and the <dl> tag has been redefined as a "description list":

The <dl> element represents an association list consisting of zero or more name-value groups (a description list). Each group must consist of one or more names (<dt> elements) followed by one or more values (<dd> elements).[13]

We use wikimarkup instead of the tags: ; instead of <dl> and : instead of <dd>. The : can appear on the same line as the ; or on the following line. The help page illustrates how these work. A lot of editors have misused the ; without the : to simply bold a line. This worked without problems, but with the redefined markup, the : is required. The line still gets bolded, but when you validate a page, you get validation errors. The MoS page still renders some invalid HTML; see W3C markup validation for Wikipedia:Manual of Style. Some of these require developer fixes and have been reported; the rest are due to the navboxes and have been reported. And yes, Help:Wiki markup needs to be updated.
Now, there are some with a point of view that our output is for browsers, not the validator; or that it works, so don't mess with it. We should never render invalid HTML— it can cause issues with portability and it is just plain unprofessional. And when there are actual issues, then all of these minor problems crowd out any major issues. ---— Gadget850 (Ed) talk 11:04, 1 November 2012 (UTC)

Searching source code

Is there a way to search for source code? My main use of this is when there is a template from either the template or someone's user namespace that has been substituted and I want to figure out what the template was. Ryan Vesey 14:27, 1 November 2012 (UTC)

The MediaWiki search technically does look through the source code, but not perfectly. I recently worked on something like this, and the only way to get a good list (as Magioladitis) did, was to search for uncommon phrases like class="messagebox standard-talk" and use those.
Most templates that are intended to be substituted leave something behind like <!-- Template:Welcome -->, however templates that aren't supposed to be substituted won't do so. Legoktm (talk) 14:36, 1 November 2012 (UTC)
The clean up templates all do (or did), as this allows the subst: to be undone. Rich Farmbrough, 19:33, 1 November 2012 (UTC).
Just occasionally you can see the subst: in the edit summary. Rich Farmbrough, 19:31, 1 November 2012 (UTC).

TimedText template and category

Please assist I noticed that TimedText became active here today (it's been on Commons for awhile) and so I decided to give it a go: I added TimedText:They Are Night Zombies!! - Sufjan Stevens - clip.ogg.en.srt to File:They Are Night Zombies!! - Sufjan Stevens - clip.ogg. I realized that there is no way to categorize audio and video that have (or lack) subtitles, so I also made a rudimentary {{Subtitles}} and Category:Wikipedia audio files with subtitles to be applied to edit notices. In my head, it seems like this template could do a couple of things: 1.) provide a link to the subtitle file itself so that users can edit it and 2.) have a language code option so that we can make Category:Wikipedia audio files with English-language subtitles, Category:Wikipedia audio files with Spanish-language subtitles, etc. I'm just not smart enough to do it. Does anyone want to work with me on this? Thanks. —Justin (koavf)❤T☮C☺M☯ 19:46, 1 November 2012 (UTC)

Looks like fun. Rich Farmbrough, 00:37, 2 November 2012 (UTC).

notifying changes to speaker data

Just saw this edit,[14] which showed up on my watchlist as (Tag: changing height and/or weight). Very handy! Would it be possible to create a similar tag for changes to the speaker data in {{Infobox language}}? Unreferenced population inflation is a chronic problem with our language articles. — kwami (talk) 23:57, 1 November 2012 (UTC)

You can make a request at Wikipedia:Edit filter/Requested but each edit filter takes resources. There are far more infoboxes for people and changes are often WP:BLP problems. PrimeHunter (talk) 00:11, 2 November 2012 (UTC)
Thanks! — kwami (talk) 00:16, 2 November 2012 (UTC)

Use mod_pagespeed

Google developed this to make web pages load faster. It minifies HTML, CSS and JavaScript dynamically and removes unnecessary information from pages, images etc. I suggest we use this on Wikimedia websites. 68.173.113.106 (talk) 20:38, 30 October 2012 (UTC)

We already do those things (in almost all situations), using ResourceLoader —TheDJ (talk • contribs) 22:55, 30 October 2012 (UTC)
An Apache module could be even faster since it's in native code. 68.173.113.106 (talk) 02:45, 1 November 2012 (UTC)
Perhaps for minifying, but it would not suit our needs as well for other things (ResourceLoader does other things like combine stylesheets and javascript for less round-trips the browser has to make). RL also contains modes that will let you un-minify things on demand (very useful for debugging). Additionally, mod_pagespeed would have problems for our caching setup (it varies some output based on user agent, which we absolutely do not want). We discussed this awhile back. It's a good suggestion, but just isn't what we need. ^demon[omg plz] 12:07, 1 November 2012 (UTC)
Of course we shouldn't try to dynamically optimize images. They should be optimized manually using tools like PunyPNG. Perhaps we can minify HTML code with a MediaWiki extension (is that ResourceLoader?). Plus, link URLs should be optimized whenever possible. 68.173.113.106 (talk) 16:48, 2 November 2012 (UTC) (edited)

User:John Vandenberg/Deletion sorting tool

This tool seems to have been broken forever and a half...would someone be able to fix it? Ks0stm (T•C•G•E) 23:39, 31 October 2012 (UTC)

The idea has been to incorporate it into Twinkle, but since I have been particularly busy this year I have not had a chance to sink my teeth into this. However, I believe the tool works for some people...? — This, that, and the other (talk) 06:23, 2 November 2012 (UTC)
I tried it a while back and it didn't work... — Mr. Stradivarius (have a chat) 11:40, 2 November 2012 (UTC)

Malicious code?

I came here via a link from User:MC10/stubtagtab.js.

The page above said:

Code that you insert on this page could contain malicious content capable of compromising your account. If you are unsure whether code you are adding to this page is safe, you can ask at the appropriate village pump. The code will be executed when previewing this page.

My question is: is anyone at Wikipedia patrolling the areas at Wikipedia where vandals can easily insert malicious code? Ottawahitech (talk) 14:24, 1 November 2012 (UTC)

User .js and .css pages cannot be edited by anyone other than administrators. So unless you add malicious code yourself, (or add another user's malicious code), you should be safe. Legoktm (talk) 14:37, 1 November 2012 (UTC)
There are much-transcluded pieces of code, who's owner's accounts are therefore far more tempting targets to evil people. They should be patrolled if possible. Rich Farmbrough, 19:36, 1 November 2012 (UTC).
Sure, but they can still only be edited by administrators or by their creators, right? --Philosopher Let us reason together. 06:15, 2 November 2012 (UTC)
Right, but I think Rich's point is that they should be patrolled for signs of account compromise and subsequent malice, as those accounts will be more desirable for people to hijack. Writ Keeper ⚇♔ 14:52, 2 November 2012 (UTC)

Strange graph

This graph makes it look as if one of the clusters is dead. Rich Farmbrough, 19:31, 1 November 2012 (UTC).

Could you provide some context? Right now it's "Some image might mean something". Is this from a Wikipedia article describing clusters? Is this about some website infrastructure? --Malyacko (talk) 10:48, 2 November 2012 (UTC)
It's a screengrab showing the number of requests handled by pmtpa (Tampa, Florida) and esams (Amsterdam). In fact, I think the bluey-purple is actual "images", and I think what the chart is a change in the way image traffic is handled, rather than any specific issue with a cluster. But I could be wrong. - Jarry1250 [Deliberation needed] 01:22, 3 November 2012 (UTC)

NOINDEX in article space

There was an RfC to use NOINDEX on unpatrolled pages and CSD templates that closed favorably to the ideas. I see that it's been added to db-g10 for example, but the Template:noindex still says it doesn't work in main space. Does it work yet or not? Gigs (talk) 20:13, 1 November 2012 (UTC)

Well, noindex was removed from unpatrolled pages a while back due to some major problems with pages not being patrolled. New changes in the New Page Patrolling process has fixed this issue somewhat; however, the delay in indexing them would affect their google search ranking. I'm unsure how {{noindex}} played in to this because those pages had the noindex in the actual source code (not the wikimarkup). Ryan Vesey 20:22, 1 November 2012 (UTC)
But you are saying the magic word does work in mainspace? Gigs (talk) 20:29, 1 November 2012 (UTC)
That I can't tell you. All I know is that the source code of unpatrolled pages had the following content. Had robots noindex codes. Ryan Vesey 20:38, 1 November 2012 (UTC)
The rendered html for mainspace pages at Special:WhatLinksHere/Template:NOINDEX shows that it doesn't work in mainspace. There is no noindex tag there. For comparison, a tested userspace page had <meta name="robots" content="noindex,follow" />. PrimeHunter (talk) 20:41, 1 November 2012 (UTC)

Wikipedia:Controlling search engine indexing has everything you need to know. If you want NOINDEX to work in mainspace, you'll need to file a bug to get en.wp settings changed. Rd232 talk 20:59, 1 November 2012 (UTC)

So, it doesn't work at the moment - we had some bugs with Special:NewPagesFeed that meant (potentially) old articles, if moved, would register as new, hit it and trigger the software. Now, we can totally re-enable it if you want....but this bug is still present. There will be unforeseen consequences :(. Okeyes (WMF) (talk) 00:20, 2 November 2012 (UTC)
Can't we enable NOINDEX in main without enabling the NOINDEX unpatrolled feature? It would still be useful for speedy deletion templates, and it was suggested to be used for certain high profile controversial articles as they go through a long AfD/DRV process (or maybe just NOINDEX the AfD/DRV template entirely, if there's consensus) Gigs (talk) 01:04, 2 November 2012 (UTC)
If it was merely enabled, without additional development work to prevent abuse, company A would have an incentive to add NOINDEX to the Wikipedia page for their rival company B. See this comment and others at the recent RFC page. -- John of Reading (talk) 07:57, 2 November 2012 (UTC)
Okeyes said there would be a template whitelist to control which templates could use it. That sounds to me like it's separate from the unpatrolled noindex feature. I'll ping him for more technical information. Gigs (talk) 13:18, 2 November 2012 (UTC)
That is indeed the case, and this is made perfectly clear in the RfC John cites. Okeyes (WMF) (talk) 19:47, 2 November 2012 (UTC)
So are you saying we can turn it on with template whitelisting without turning on automatic noindex of unpatrolled? Gigs (talk) 02:22, 3 November 2012 (UTC)

Welcome back CamelCase

Tracked in Phabricator
Task T43692

I am surprised to see the latest namespace is in camel case - "TimedText". How can we get this changed to "Timed text"? Rich Farmbrough, 03:11, 2 November 2012 (UTC).

It was never really gone, since we also had and have the MediaWiki namespace, e.g. MediaWiki:Abusefilter-disallowed. Fram (talk) 14:18, 2 November 2012 (UTC)
I always figured that was just because MediaWiki was the name of the software, not because we were using CamelCase. I believe this namespace exists at Commons too - we probably don't want to end up with a different name than they do, so both or neither should change, imho. --Philosopher Let us reason together. 14:37, 2 November 2012 (UTC)
Yes me too. And it does, quite right. Rich Farmbrough, 19:51, 2 November 2012 (UTC).

Question

Hi All, recently when we edit in eng wikipedia, after saving this edit a window pops up containing text: your edit was saved. How to add this in urdu wikipedia? --محمد شعیب (talk) 06:07, 31 October 2012 (UTC)

See Wikipedia:Village pump (technical)/Archive 105#Small new feature coming on Thursday above; it's an experiment by the WP:E3 team. If it goes well and does what they want for encouraging new editors, they might eventually roll it out to other languages and projects. Anomie⚔ 11:04, 31 October 2012 (UTC)
It is rolled out over other languages. It's fucking annoying - how can you switch it off across all wikis? Lugnuts Dick Laurent is dead 19:44, 31 October 2012 (UTC)
I'm often annoyed, but when I'm on a poor connection, I appreciate seeing it instead of wondering whether my edit went through, so I definitely don't want to get rid of it. That being said, I'd support a feature to allow others to turn it off. Nyttend (talk) 21:30, 31 October 2012 (UTC)
Lugnuts: there is no such thing as global preferences, so even if there was a preference to turn it off, you'd need to hide it on every wiki. Steven Walling (WMF) • talk 18:37, 1 November 2012 (UTC)
Is global preferences anywhere on the roadmap, out of interest? Andrew Gray (talk) 10:21, 3 November 2012 (UTC)
Once this extension is translated, we would be happy to add it to Urdu Wikipedia. The only requirement is that someone needs to do the translation, by signing up at translatewiki.net and looking for "PostEdit". Many thanks for your interest! Steven Walling (WMF) • talk 18:29, 31 October 2012 (UTC)

Request for edit to Template:WikiProject Poland

Moved from WT:VPT § Request for edit to Template:WikiProject Poland

I can't edit this protected template. Can somebody who can remove the requirement to review b6 criteria? If it is not reviewed, but b1-b5 are, it still lists the article in Category:Poland articles with an incomplete B-Class checklist. I am the only one doing reviews in this category, and I don't care about b6 (heck, I don't even understand what is supposed to be - alt text on images?). Milhist doesn't use it, and their criteria are good enough for me, anyway. Thanks! PS. I assume that fixing this will not break the many templates that do use the b6 line, as I've often been check marking it by default (just got annoyed today when I discovered some old reviews didn't have it, and I don't feel like the doing the makework of adding the stupid b6=yes line to many articles... --Piotr Konieczny aka Prokonsul Piotrus| reply here 01:29, 3 November 2012 (UTC)

I've changed the level of protection on the page, you should be able to edit now.--Salix (talk): 02:50, 3 November 2012 (UTC)
BTW you question should really be on Wikipedia:Village pump (technical) rather than the talk namespace.--Salix (talk): 03:05, 3 November 2012 (UTC)
The standard B-class checklist is at WP:BCLASS, but alt text on images (described at WP:ALT) is not part of the B-class criteria. B6 is "The article presents its content in an appropriately understandable way. It is written with as broad an audience in mind as possible. Although Wikipedia is more than just a general encyclopedia, the article should not assume unnecessary technical background and technical terms should be explained or avoided where possible.". Not all WikiProjects take B6 into account: it's the only one of the six which is optional on a per-project basis. --Redrose64 (talk) 10:28, 3 November 2012 (UTC)

Direct transclusions

Special:WhatLinksHere shows all transclusions of any given page. Is there a tool somewhere (on toolserver?) that lists direct translusions (i.e., not via another page) only? — Hex (❝?!❞) 14:08, 3 November 2012 (UTC)

Top 10,000 articles

Is there a list or something of articles by average page hits a week or something? I think it would be good to have to browse through and find some articles I'm interested in bringing up to GA.♦ Dr. Blofeld 22:39, 14 October 2012 (UTC)

I'm aware of Wikipedia:Lists of popular pages by WikiProject. Bgwhite (talk) 23:39, 14 October 2012 (UTC)
I log all Wikipedia hit statistics to a database. Give me a few minutes, I'll run a query that will approximate what you want. Thanks, West.andrew.g (talk) 23:49, 14 October 2012 (UTC)
HERE YOU GO. These are the highest traffic articles over the last ~3 months, quasi-sorted by popularity (I used a heuristic to make this search more efficient, but it should be fairly accurate). Hope it is helpful. Thanks, West.andrew.g (talk) 00:09, 15 October 2012 (UTC)
Yes, very. Thanks. Although the fact that One Direction are even more popular than the United States doesn't exactly say much. They represent everything wrong about today's spoon fed music! And Bieber more popular than sex! Gaaaaa. There will be some decent topics in there, I hope.♦ Dr. Blofeld 10:29, 15 October 2012 (UTC)

I personally am upset that Wikipedia discloses those statistics (IMHO they are a privacy invasion) and there's a lot of pages I avoid reading from the web site because of them. Given that they are there anyway, I don't have any problem with what Andrew West or Dr. Blofeld are doing, but I felt I had to say that not everybody thinks that it's right for Wikipedia to publish this info. 67.119.3.105 (talk) 00:48, 28 October 2012 (UTC)

How is disclosing these statistics a privacy invasion? Whose privacy is invaded? What is the problem? —Anomalocaris (talk) 15:53, 28 October 2012 (UTC)
The only way this could violate privacy is we could deduce who visited what pages based on these numbers, which is impossible, since there are no identifying details and you cannot correlate visits between pages or to any source. —  HELLKNOWZ  ▎TALK 16:13, 28 October 2012 (UTC)
Anomalocaris and Hellknowz, sorry I've been away for a while, but to answer your question, the site is disclosing info about what articles people browse supposedly privately. That the info doesn't happen to include the readers' names doesn't make the rest of it non-private. That's the point of all the expensive presidential polling going on in swing states right now, for example: campaigns want to know (statistically) what people are thinking, so they can use the info to deploy resources and adjust their campaign lies messages, even if poll respondents aren't individually identified. If I don't like candidate X and I want him to lose, I don't want to give any info to his pollsters, including statistical info.

WP's pageview counts give similar info to candidates, marketroids, and other unentitled parties, based on (IMHO) invasive capture of WP readers' activities. By reading articles here, we are participating in a giant opinion poll/marketing survey/whatever for the benefit of every evil (or non-evil, but the distinction is irrelevant) entity in the world, that we didn't opt into. My take is that WP is doing the wrong thing releasing the info. WP should instead seek to give its readers the same level of privacy that the printed Encyclopaedia Britannica did. Reading from the EB's pages was a one-way transfer of information (from the book to the reader). There was no info sent in the other direction, identifiable or not. 67.119.3.105 (talk) 01:39, 5 November 2012 (UTC)

Whups, I started reading this without my tinfoil hat firmly in place.
Nothing to see here, folks. As you were.
Thanks to West.andrew.g for putting the data together! Binksternet (talk) 04:12, 5 November 2012 (UTC)

Change the name of a tab

Is there any way I can use CSS or something to change the name of the page history tab from "View history" to just "History"? On my iPad, sometimes the tabs run out of space and collapse in so you can't click on them. I want to make the tab names shorter to avoid this problem. Thanks, David1217 What I've done 17:09, 26 October 2012 (UTC)

Not possible in CSS, but check the small CompactTabs script on my user page that shortens all tab names. — Edokter (talk) — 19:35, 26 October 2012 (UTC)
Ugh, not more JavaScript. Oh well, the script works, so thanks Edokter. David1217 What I've done 20:24, 26 October 2012 (UTC)
"Possible" in css via dirty dirty trickery:
 #ca-history.collapsible span {overflow:hidden;position:relative;} #ca-history.collapsible span a {position:relative;left:-3em;width:3em;}
--Splarka (rant) 15:12, 27 October 2012 (UTC)
Depending if the browser supports it (it should, these days), you can also do 
 #ca-history a { content:'History'; }
but that's just wrong on many levels. -— Isarra ༆ 03:44, 29 October 2012 (UTC)
"Wrong on many levels"? David1217 What I've done 02:41, 30 October 2012 (UTC)
Philosophical and such levels. (Seriously, though, if you don't use IE it should be fine.) -— Isarra ༆ 04:26, 31 October 2012 (UTC)
... and don't use Firefox either. [15] Though neither IE nor Firefox run on iPads. PleaseStand (talk) 13:59, 2 November 2012 (UTC)
I think I'll just stick with Edokter's JavaScript. David1217 What I've done 20:18, 4 November 2012 (UTC)

New color on the edit tabs?

Monobook, Windows 7, IE 8. I've suddenly noticed that the tabs at the top of the page (regardless of namespace) are mildly darker than the area around the title of the page: it's the normal offwhite everywhere else, but the tabs seem to be mildly light blue. Why did I just notice this — was something changed, or have I just now noticed something that's been in place for a long time? Nyttend (talk) 21:37, 31 October 2012 (UTC)

I see it on Chrome (XP) too. The tabs should be white indeed. I think someone is mucking around with the CSS in core (possibly related to MobileFrontEnd?), see above for another CSS glitch. No changes were made here. — Edokter (talk) — 21:46, 31 October 2012 (UTC)
It could be the edit survey banner that is causing these hickups. — Edokter (talk) — 21:48, 31 October 2012 (UTC)
Eh, are you sure that this wasn't you Edokter ? change. —TheDJ (talk • contribs) 23:47, 31 October 2012 (UTC)
I can't imagine why; I didn't actually change any properties, and none of the code touches the tabs. I did a test-revert though to see if that clears the problem. — Edokter (talk) — 21:59, 1 November 2012 (UTC)
I think it's global, since the change happened on Commons as well. I think there might be a global CSS file, in which case there may not be a diff on enwiki that shows the change. ☮Soap☮ 01:18, 5 November 2012 (UTC)

Not sure if it's related, but there also used to be a horizontal line that separated the tabs from the rest of the page. Now they just blend together with the page. Same thing on Commons. I think this is a recent change, but it's possible that I just never noticed it. I'm using Monobook/Firefox. --Bongwarrior (talk) 23:07, 31 October 2012 (UTC)

We can look at old screenshots and determine that the inactive tabs were always grey, while the border under the inactive tabs has gone missing. The culprit seems to be something in the site css, but I don't know why the file being served doesn't match the file in git. Anomie⚔ 02:10, 1 November 2012 (UTC)

Not to be pedantic, but the lower tab border was never present on all tabs - it was absent for the active tab(s). These active tabs presently have a yellow top, left and right, just as they do in the screenshot linked by Anomie. --Redrose64 (talk) 09:01, 1 November 2012 (UTC)
I've changed my personal CSS to restore the Monobook tabs to how I saw them a few days ago. I had previously applied other styling to the tabs, so how I saw them might differ from what you are used to. Notably, if you don't want the background to go white when hovering over a tab, omit the line containing "background-color: white". I hope this helps. – PartTimeGnome (talk | contribs) 23:32, 1 November 2012 (UTC)
I added
.selected {
position: relative;
top: 0px !important;
background-color: #d0ffff !important;
}
so that it restores the bars only for the non-highlighted tabs, and also colors the highlighted tab differently. However this seems to have some slight effects on other things, such as Page History, so others might not want the color. ☮Soap☮ 20:42, 2 November 2012 (UTC)
I have been told there is indeed a bug in the core CSS, which will be fixed shortly. — Edokter (talk) — 15:29, 4 November 2012 (UTC)

Blank space on Teahouse

I have IE9. If I go to Wikipedia:Teahouse/Questions, it starts out looking okay and then the questions disappear. It turns out I have to scroll down to see them.— Vchimpanzee · talk · contributions · 20:32, 2 November 2012 (UTC)

I also see it in IE9. It only happens when the "Previous questions" box is collapsed. It doesn't happen in Firefox, Chrome, Safari or Opera, and it doesn't happen if compatibility mode is enabled in IE9. Maybe something in Template:TH question page should be tweaked. I have posted to Wikipedia talk:Teahouse#Blank space on Teahouse. PrimeHunter (talk) 21:47, 2 November 2012 (UTC)
That is very strange! Would it work to just uncollapse the previous questions box or move it? heather walls (talk) 23:21, 2 November 2012 (UTC)
I tested it on IE9 with the same view with the question box uncollapsed. NtheP (talk) 11:39, 3 November 2012 (UTC)
The issue appears to lie with how IE9 is treating the {{TOC right}} template on that particular page; for some reason collapsing the archives (previous questions) in conjunction with having a specified width percentage on the following TOC table appears to... confuse it. It was acting even stupider when testing on the template itself (collapse the archives and then the first section would get the space after it instead of before it), but for on the Questions page just removing the collapsiness from the archives should work, aye. I think. Might as well try. -— Isarra ༆ 07:47, 4 November 2012 (UTC)
Tracked in Phabricator
Task T43761

While investigating Wikipedia:Help desk#Weird citation error that appeared independently of edits I discovered that refs are apparently forgotten after a gallery containing an ogg file. A simple sandbox example: [16]. The ref is displayed before but not after the diff. There is another issue with pages containing ogg files in #watching star is out of order for an article. I don't know whether it's related. PrimeHunter (talk) 01:23, 4 November 2012 (UTC)

Filed a report on this issue. —TheDJ (talk • contribs) 11:16, 4 November 2012 (UTC)

Rate this page, displayed as text

I see the rate this page not as a box but as almost plain text (sprinkled with a couple of links and buttons), as you probably can see in the following sample page. Using Opera 11.61, on Linux (OpenSuse 11.1) - Nabla (talk) 12:00, 4 November 2012 (UTC)

It works for me in Opera 12.02 on Windows Vista. Try to completely clear your cache. PrimeHunter (talk) 12:27, 4 November 2012 (UTC)
Cache deleted. Cache disabled. Page pruged. Still the same, all the time. And it has bee so for a couple of days, maybe more. - Nabla (talk) 13:19, 4 November 2012 (UTC)
And the same happens with version 5 - Nabla (talk) 20:07, 4 November 2012 (UTC)
They both work for me. Does it happen when you are logged out? Can you update Opera? PrimeHunter (talk) 23:34, 4 November 2012 (UTC)
The same when logged out. I may update Opera, and I intend to update the OS, which is less young than the browser, but I sure will not do it because of this. It worked just fine a few days ago, it can hardly be a version problem; moreover I do not intend to keep a almost full time job upgrading everything all the time :-) plus this is no big deal in itself. I don't recall changing any WP/browser/OS options recently either... yet I tried to activate all javascript permissions, with no good result either. I also activated Opera's error console, which popped up lots (over a hundred?) of warnings and errors, most (all?) of them seemed like CSS errors (stuff for this-and-that-browser, mostly not a real problem I guess). Pff... Nowadays web pages are a complete mess - WP's are somewhat less messy, probably, but still... Oh, well... - Nabla (talk) 00:02, 5 November 2012 (UTC)

Bugzilla report added for syntax highlighting based on RfC

Tracked in Phabricator
Task T43770
Declined

Hey folks-- given the wide consensus for the implementation of some syntax highlighting by default (per the Village Pump discussion and RfC), I have submitted a report to bugzilla to see if it can be done. You may be interested in participating in or watching the outcome of that discussion here. Thanks, I, Jethrobot drop me a line (note: not a bot!) 18:39, 4 November 2012 (UTC)

Is there a iPhone App to upload pictures and video to Wikipedia?

Is there an iPhone app in development for uploading pictures and/or video from the iPhone to Wikipedia or Commons? I can't believe there isn't a basic app already developed. It'd be incredibly useful. 155.201.35.58 (talk) 21:48, 30 October 2012 (UTC)

No form of content-modification is possible from a mobile phone through any official apps. Maybe there are third-party apps that can do what you ask, but I don't know of any (maybe someone else here does). Increasing the functionality of Wikipedia from mobile phones is one of the projects the Foundation is currently working on. Someguy1221 (talk) 21:53, 30 October 2012 (UTC)
Not quite true, Someguy1221 – this past summer, the WMF created the Wiki Loves Monument app for Android, which allowed for mobile uploads to Commons :) It was built specifically for the Wiki Loves Monuments competition, but we're definitely interested in repurposing the code for more general photo uploads. Maryana (WMF) (talk) 22:20, 30 October 2012 (UTC)
Is there a page where I can get more info on this work? 155.201.35.58 (talk) 22:02, 30 October 2012 (UTC)
  • The mobile team has been focused on getting the design and UI of the main mobile gateway into shape in the past few months, but after the latest release last week (see VPT announcement here), we're definitely thinking of building contributory features like photo uploads. New experimental features tend to go out to the Beta site first for testing before they make it into the official site or an app, so keep an eye on the Beta documentation page if you're interested in staying on top of the latest stuff. Any new apps or features will be announced here, as well, so stay tuned :) Maryana (WMF) (talk) 22:31, 30 October 2012 (UTC)
Can always select "desk top format" and edit at will from a phone.Moxy (talk) 23:11, 30 October 2012 (UTC)
I'll note that I'm developing mw:Commons_Mobile_upload_app now, and it should be in a beta testable state in a short while. It's Android only for now, however :( You can see some of the test Uploads I've done testwikiYuviPanda (talk) 23:27, 30 October 2012 (UTC)
That looks looks great, YuviPanda! You should add it to the list here. Glad to see it can already upload pictures and the mockups look fantastic. I like that it's focusing on the upload portion first (simplicity is great). Hopefully someone can write up a simple one for the iPhone as well. 155.201.35.58 (talk) 16:25, 31 October 2012 (UTC)
I successfully uploaded a photo from my iPhone a couple weeks ago. The photo was sent to me via e-mail, I saved it into my photos on the phone, uploaded it using Safari (choosing a new name) and then completed the upload. I also forwarded the permission e-mail to OTRS and then added the OTRS pending template from my phone. So yes, it can be done. Imzadi 1979 → 00:00, 6 November 2012 (UTC)

Handling of blank lines in Wikipedia syntax

Tracked in Phabricator
Task T43767

Hi all,

I'm a little upset by the way the MediaWiki software handles blank lines in source code. In common markup languages multiple blank lines are just ignored (e.g. HTML) or are interpreted as a new paragraph (LaTeX). In MediaWiki syntax multiple blank lines produce larger spacing between paragraphs which I think is quite unfavorable because it's not intuitive and very prone to errors.

It's often happening that multiple blank lines are typed by error resulting in ugly excessive spacing between paragraphs, whereas I can't imagine a single case, where one actually wants to use multiple blank lines to produce a defined amount of vertical space. Is this behavior of MediaWiki software actually intentional or is there some potential for discussion here (with the possibility of getting it changed)?

Regards — Patrick87 (talk) 01:01, 3 November 2012 (UTC)

  • Thousands of articles use peculiar wiki-markup features: I think most here would agree with your opinion that multiple blank lines should be treated as one; otherwise, when an included template starts with a blank line, and the article has a blank line already, then the result becomes triple-spaced text or such. However, remember any change to formatting, in this 12th year of Wikipedia, must be applied retro-actively to redo all prior pages, where used. Another peculiar problem, in formatting text, is when translating to lowercase letters and getting newline processing of the first character, so consider downcasing a hash-name: {{lc:#NAME - This becomes a NUMBERED LINE in Mid-Text}}, with the result:
  1. name - this becomes a numbered line in mid-text.
Now, where else in the world do people translate a hash-mark name to lowercase and get a numbered newline as the result? (Redacted) -Wikid77 (talk) 09:43, revised for (Redacted) at 12:18, 3 November 2012 (UTC)
Abusive remarks removed Redrose64 (talk) 12:44, 3 November 2012 (UTC)
It's a valid question. Even after ten years of editing, I still find myself occasionally having to fix superfluous spacing caused by this "feature". I'm not sure that I can identify a single instance of an article I've encountered that intentionally did it; I'd be willing to bet that the number of articles relying on this behavior is minuscule compared to that of those which don't. An automated analysis of a non-trivial fraction of mainspace to confirm or deny this would be interesting. — Hex (❝?!❞) 13:32, 3 November 2012 (UTC)
One use is to work around the common malfunction / glitch where a single blank line is ignored & doesn't produce a single blank line, so a double blank line is needed to produce a single blank line. North8000 (talk) 13:44, 3 November 2012 (UTC)
Do you have any examples? Nonetheless keeping a design flaw to workaround a bug doesn't seem quite right to me. ;) -- Patrick87 (talk) 13:50, 3 November 2012 (UTC)
Actually I said it a bit wrong. The common glitch is when a line break is ignored and so two line breaks are needed to make a single line break. I think I've had that happen 50-100 times, but I really don't remember articles by which glitches I had there so I unfortunately can't think of an example at the moment. North8000 (talk) 14:02, 3 November 2012 (UTC)
Outside of Wiki markup, the normal behaviour of pages marked up with HTML is that all line breaks formed using the newline character (&#x000A; &#x000D; or both) are treated as if they were single spaces. Line breaks are only inserted into the rendered page when they are explicitly requested in the markup, such as by use of the <br /> or <p> elements.
Within wiki markup, the essential feature is not the newline character but the blank line. A blank line in plain text forces a new paragraph to be started; a blank line in a list (bulleted or numeric) forces a new list to be started, and so on. Two or more consecutive blank lines will cause an increased amount of blank space between the paragraphs (lists, etc.) but this gap cannot be predicted with any accuracy. I have sometimes seen multiple blank lines (as many as twenty on occasion) added into articles with the intention of making a new paragraph begin after the bottom of an image, but this rarely works as intended because different users have different screen widths, so you don't know just how many blank lines may be required. The safe way of forcing a paragraph to start after the bottom of an image is by using one of the {{clear}} family.
The Manual of Style states to use single blank lines. As far as I am aware, the only place in Wikipedia where the use of more than one blank line is recommended concerns stub templates; see for example Wikipedia:Stub#How to mark an article as a stub "It is usually desirable to leave two blank lines between the first stub template and whatever precedes it". MOS:FOOTERS doesn't mention use of blank lines here though. --Redrose64 (talk) 15:37, 3 November 2012 (UTC)
You're right, actually; I had forgotten that. All the stubs are built around {{asbox}}; if whitespace is an issue, I don't see why it isn't built into that template with CSS, rather than have the MOS mandate the use of a pseudo-feature to achieve a desired appearance. — Hex (❝?!❞) 17:05, 3 November 2012 (UTC)
As I understand it, it's less to do with appearance but more as an aid to automatic processes which organise the footers (categories, stub templates, interlanguage links). If {{asbox}} did add blank lines, and more than one stub template were present (as with Palais Porcia), that would affect the visual spacing between stub templates as well as above; perhaps that would have been undesirable. --Redrose64 (talk) 17:30, 3 November 2012 (UTC)
There has been discussion about that multiple times— check the archives. We fixed the same issue for navboxes with CSS. ---— Gadget850 (Ed) talk 22:25, 3 November 2012 (UTC)

So the consensus on this issue seems to be that a) it often leads to problems with additional but unwanted vertical space due to too many blank lines; b) theres no real use of multiple blank lines to actually control vertical space. If this is the case I'll probably add an enhancement request at the MediaWiki bugtracker and see if its accepted. -- Patrick87 (talk) 23:03, 3 November 2012 (UTC)

  • Thousands of articles use 2 blank lines at bottom stub tags: Let me emphasize, as someone mentioned above, how multiple blank lines are typically discouraged except near the bottom, where the bottom stub-tags "{{..stub..}}" are often surrounded by 2 blank lines, either above or below, and such multiple blank lines are used in many, many thousands of pages. Higher within the text of an article, blank lines are often reduced to just 1 each, but around the stub-tags, near the category-links, those 2 (rarely 3) blank lines have been left in many thousands, and thousands, and thousands, and thousands of articles to "actually control vertical space" around stub-tags. Sorry that issue was not made clearer above. -Wikid77 (talk) 11:39, 4 November 2012 (UTC)
This is tracked in the bug database now: https://bugzilla.wikimedia.org/show_bug.cgi?id=41767 --Malyacko (talk) 10:50, 5 November 2012 (UTC)

The new video play breaks the thumbnail frame code?

Tracked in Phabricator
Task T41014

I upload a lot of videos to Wikipedia and I'm not sure where to complain about this, but could the person who implemented the new video framework be notified that it isn't recognizing the thumbnail selection argument that was in the old player. Several of my videos look quite unattractive with the default thumbnail :( Nesnad (talk) 05:58, 5 November 2012 (UTC)

Thanks for reporting this issue, this should be resolved once mw:TimedMediaHandler is fully rolled out, you can subscribe to the bug report to follow the process. JanGerber (talk) 10:39, 5 November 2012 (UTC)

Two things

Greetings! It seems that Theodore M. Pomeroy is currently Speaker of the House and George Nicoll Barnes is alive.

By the way, the Barnes case may be suitable for Wikipedia:List of hoaxes on Wikipedia --94.65.12.42 (talk) 13:35, 5 November 2012 (UTC)

 Done I fixed up both of them. Thanks for the report! Legoktm (talk) 13:41, 5 November 2012 (UTC)

Monthly Wikimedia engineering report

Hi. As you may know, every month the Wikimedia Foundation's engineering department publishes a report covering the activities and projects they've been working on. I usually only post the link on the Signpost's Newsroom page (and a couple mailing lists), but someone suggested that readers of VPT might be interested as well, so here it is, in wiki version and blog version. As of last month, we're also proposing a shorter and simpler version of this report, that less technically-savvy readers might find useful. Feedback is appreciated. guillom 14:54, 5 November 2012 (UTC)

Citation microformat

I propose that we add microformat-style HTML class names to citation templates, to improve their machine readability; please see Proposal: citation microformat and discuss there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:47, 5 November 2012 (UTC)

Wikipedia site is flaky recently

Hi, Wikipedia has been very slow and flaky for me for the last approximately 24 hours. Sometimes pages come up, but other times I just sit forever looking at IE's little egg-timer. Other websites seem fine, same as usual. Are there any known problems? I am in Southern England, if that makes a difference. 86.146.108.178 (talk) 18:23, 5 November 2012 (UTC)

General slowness and incomplete page loading

Hi, is it just me or is there a problem somewhere as I am having problems over loading pages and general slowness of getting any thing to work. Page histories and diffs are particularly problematic and often never complete loading. Many pages load in chunks with minutes between chunks and never getting to the user scripts/preference loading. Using firefox 3.6.28 on XP if that is of any help. Keith D (talk) 18:23, 5 November 2012 (UTC)

I'm using FireFox 16.0.1 on Windows 7 and I get the same problem. I think it is a server-side lag issue, though. Reaper Eternal (talk) 18:25, 5 November 2012 (UTC)
Sounds like the same thing that I'm getting, reported above, by some flukey coincidence almost to the nearest minute. 86.146.108.178 (talk) 18:31, 5 November 2012 (UTC)
I have Firefox 16.0.2, Mac 10.6.8 - a simple edit is not saved after 7 minutes of spinning - hope this one works.... Ben MacDui 19:38, 5 November 2012 (UTC)
More info that may help to pin point the problem. The show/hide toggles on navboxes do not appear and they are always open. In edit mode the symbols etc all appear below the save button and cannot be clicked. Keith D (talk) 00:30, 6 November 2012 (UTC)
For me it is now quite a lot better. Pages are loading more quickly and reliably. Saving edits is still quite slow, but then that is sometimes the case anyway, problems or no. Hopefully I am not tempting fate with this comment. 86.146.108.178 (talk) 02:40, 6 November 2012 (UTC)

New banner

Is Wikipedia really going to beg me for five bucks on every page? --Bongwarrior (talk) 21:05, 25 October 2012 (UTC)

I'm also finding the banner annoying. I have to click to close it on every page. Can't it please remain closed once I click the X on it once? Calathan (talk) 21:08, 25 October 2012 (UTC)
Yes, there needs to be some way of disabling it once it is viewed. As it is, the need to constantly close it is seriously discouraging me from working on Wikipedia until it is fixed. —David Eppstein (talk) 21:12, 25 October 2012 (UTC)
Agreed. I just donated and it's still bugging me... That's seriously flawed. Biosthmors (talk) 21:13, 25 October 2012 (UTC)
If I could navigate the upload pages I would show a screen dump of the mess it makes in Opera. How do I make it go away? Mr Stephen (talk) 21:21, 25 October 2012 (UTC)
(edit conflict) There is also a display problem with it in Monobook in that it completely covers or hides the toolbar and it makes the tabs above the page disappear. (I know I can click the x to fix this, but whatever is causing it to do this should be fixed as well.) This problem is happening in multiple browsers (IE9 and Opera 12.02). (screenshot of the display problem) - Purplewowies (talk) 21:26, 25 October 2012 (UTC)
(edit conflict) There are at least two different banners. One of them (blue background, no mugshot, text in three columns "Wikipedia is non-profit, but it's the #5 website in the world. With 450 million monthly users, we have the same costs as any top site: servers, power, rent, programs, staff and legal help. To protect our independence, we'll never run ads. We take no government funds. We run on donations: £5 is the most common, the average is about £20. If everyone reading this gave £5, our fundraiser would be done within an hour. Please help us forget fundraising and get back to Wikipedia.") is buggy in Firefox/Monobook skin: it extends all the way to the left; and although it displaces the page content (that part enclosed by <div id="content" class="mw-body-primary">) and the left-margin menu (from "navigation" on) downwards, the puzzleball and the tabs are not moved downward at all - so they also obscure some text. --Redrose64 (talk) 21:24, 25 October 2012 (UTC)
Preferences → Gadgets→"Suppress display of the fundraiser banner" for anyone who doesn't know. Ryan Vesey 21:28, 25 October 2012 (UTC)
I take it someone is looking into the problem of them appearing on every new page seen? Getting questions in many places about the frequency of these pop-up's. Moxy (talk) 21:30, 25 October 2012 (UTC)

It should stay away once it is cleared. This thing of reappearing in their face with every new page is going to piss off people to the point of reducing donations. North8000 (talk) 21:28, 25 October 2012 (UTC)

One of the most annoying things I've seen on the web in a long, long time. :( - TexasAndroid (talk) 21:29, 25 October 2012 (UTC)
Okay, I'm gonna go do something else other than WP. As a Wikignome who makes lots and lots of little edits, this is an annoyance bordering on unusability. :( - TexasAndroid (talk) 21:32, 25 October 2012 (UTC)

This was an accident, someone deployed changes to the website, while at the same time someone was in the progress of reverting some changes to CentralNotice. This caused a broken version of CentralNotice to be deployed. It's being taken care of as we speak. —TheDJ (talk • contribs) 21:37, 25 October 2012 (UTC)

  • Hi all, I'm very sorry for the banner mixup on Thursday. That was a mistake, logged in users were not supposed to see the banners at all. Fundraising banners are supposed to stay closed once you click the close button and we've worked on correcting those errors. Thanks for your understanding and sorry again for the confusion and annoyance. Meganhernandez (talk) 20:42, 27 October 2012 (UTC)

Fund-raising

Odd

Not all is as it should be in the land of Wikipedia. Rich Farmbrough, 21:31, 25 October 2012 (UTC).

Hi Rich, sorry about that. We had some code that wasn't ready to be deployed sitting in the deploy queue -- we were preparing to remove it from the queue when operations did a sync operation which pushed the code. We've disabled all banners until the old/working code can be redeployed. Thing should be back to normal soon. Thanks for letting us know! Jvandavier (talk) 21:39, 25 October 2012 (UTC)

No CSS

Tracked in Phabricator
Task T43751

Most of the time what I see is the text without any formatting as in the screenshot. It then disappears after a few moments. Helder 13:37, 28 October 2012 (UTC)

I just saw it again on ptwiki. The banner is in a div whose id="B12_JimmyBlank", which seems to be defined on Meta (where it is not shown either). BTW: do we really need to create three <style type="text/css"></style> tags inside of the centralNotice div? IE users may have problems because of this. Helder 21:35, 29 October 2012 (UTC)
This is being tracked as Bugzilla #41751 Mwalker (WMF) (talk) 21:48, 3 November 2012 (UTC)

Currency

I'm in London, but the banner is asking for euros. This is possibly because I'm on a corporate network, but I wanted to flag it anyway. 167.247.83.11 (talk) 10:50, 6 November 2012 (UTC)

Origin https://wiki.riteme.site is not allowed by Access-Control-Allow-Origin

See meta:Talk:CentralNotice#Origin is not allowed by Access-Control-Allow-Origin. Helder 19:59, 1 November 2012 (UTC)

Very slow page loading

I thought it was just me, but someone else has reported it here. Any ideas? Ghmyrtle (talk) 16:45, 30 October 2012 (UTC)

It's Talk:Derek McCulloch, and it's taking around 40 seconds for the page to load after saving an edit to it. I can't see anything on the page that would be causing it -- a few citation templates, but not many. SlimVirgin (talk) 17:09, 30 October 2012 (UTC)
Just to add to this point: often, when this happens, the edit has in fact saved – it's just that the page doesn't load after saving. But in this case the edits are not saving either. SlimVirgin (talk) 18:18, 30 October 2012 (UTC)
This is happening to me too, I thought it was at my end but looks as if it might be global? Hiding T 17:21, 30 October 2012 (UTC)
The same thing was happening to me at Jimmy Savile as well. Malign influences at work.... wonder how many people will be out in Savile fright wigs tomorrow night? Ghmyrtle (talk) 17:34, 30 October 2012 (UTC)
WMF Ops is investigating. Kaldari (talk) 23:30, 30 October 2012 (UTC)
Ops said it wasn't there fault, so I did some more digging. Looks like it's a template problem. Specifically on Talk:Derek McCulloch, the {{WikiProject Military history}} call is causing the extreme slowness. Kaldari (talk) 23:58, 30 October 2012 (UTC)
Seems to be related to the class parameter in that template. Kaldari (talk) 00:19, 31 October 2012 (UTC)

Slowness, plus edit window quirks of premature saves, tossing me out of the edit window, or saving oddly

Me, too. Been very, very slow since yesterday afternoon. No pattern on what. One moment something works, the next moment it's like it's caught in a loop and can't do what it's supposed to. Opening a page, saving a page, previewing a page, anything. Just random annoying slowness. I have a secondary issue. While I'm editing, it suddenly decides to do a save without my telling it to. Or, it will throw me out of the edit box altogether and not save anything. And then it saved half of a message where I was typing on a Talk page. When I went back in and (I thought) corrected the half-written message, it saved both versions - the erroneous message and the corrected message - as two separate sections - one right on top of the other. Windows XP, Firefox 16.0.02 Just fix it, please. — Maile (talk) 18:02, 30 October 2012 (UTC)

"Wikimedia Foundation error" -- what to do?

I have been running into that old chestnut, the "Wikimedia Foundation - Error" message ("server overload" it says, but really about template limits; see WP:WFEM) while editing Hockey stick controversy. That article has lots of templates: 185 {{citation}} or {{cite xxx}} templates in the "References" section, a comparable number of {{Harv}} templates in the text, lots of wikilinks, and the usual cast of other suspects. Plus it has the standard climate change block of categories.

Aside from just stripping out a bunch of templates: what can be done?

Strictly speaking the error is triggered when page rendering takes too long (~60 seconds), and I have yet to see that an edit-save is actually lost (though verifying that and getting back to normal is a bit contortious). So perhaps increasing the time-limit and modifying how the message is presented is an adequate fix.

But I do have some concern for server load, and wonder if there are ways of mitigating the problem in either how templates are used, or in their implementation. ~ J. Johnson (JJ) (talk) 22:24, 31 October 2012 (UTC)

  • Use Cite_quick which now supports "ref=" option: The new Template:Cite_quick (from August), which runs 6-9x faster than {cite_web}, has been enhanced to handle the Harvard referencing, or any "ref=xx" id. After months of discussions, {cite_quick|web} has been improved so that it handles all the cites in 3 other huge articles which also had wp:Wikimedia Foundation error (WFE): "Barack Obama" and "Arab Spring" and "Israel". However, it does not support "authorlink=" which must be dropped for "ref=" or otherwise embedded in the "author=[[John Doe|Doe, J.]]" parameter. Because {cite_quick} runs so fast, the total time to reformat an article often drops as 3x-4x times faster, so 40 seconds would drop to 10-second edit-preview. The drawback is that {cite_quick} omits the internal COinS metadata used by DASHBot; however, the rapid speed enables editors to quickly edit and check whatever links DASHBot would have done. To use, change each {cite xxx} to {cite quick|xxx}, but old cites can still be mixed, such as keeping some {cite_journal} which still use "authorlink=" or such. The speed of {cite_quick} is 70-130 per second, compared to {cite_web} as 10-15 per second. -Wikid77 (talk) 07:02, 1 November 2012 (UTC)
You compare {cite quick} with {cite web}, and I suppose any gain is to the better. But we have mostly {citation} templates (for reasons I think are well and good), and I would like to see a comparison there. And I recall a discussion that the heaviest load on the citation templates is processing the WP:COinS metadata; I suspect that leaving that out (or making it optional) would be a tremendous difference for all citation templates.
But is this really a citation/cite problem? It seems to me to be a template problem. Before we rush off to "fix" one or another template we really ought to get some numbers as to where the fixing is most needed. ~ J. Johnson (JJ) (talk) 22:08, 1 November 2012 (UTC)
  • Large templates are problematic, not just cites: I agree that the bigger issue is a general "template problem" with any large template, and especially used multiple times per page. With {cite_web} or {citation}, many major articles have become an astounding 95% cite-related markup, containing just 5% actual "article" text. Each {citation} could be changed to {cite_quick|book|...|ref=harv} or such. Another huge, 4-second example is Template:Infobox_weather, while a tiny template, to show a few characters, can run over 2,300x per second (like {nb5} ). Now, there are several techniques to speed large templates, such as reducing 7 aliases to a few, for example to combine into just "editor-last=" from: editorlast, editor-last1, editor-surname, editor-surname1, editor1-last, editor1-surname, etc. Another tactic is to use a gated-if structure, to check for the presence of rare parameters several at a time, such as:
  • {{#if:{{{aa|{{{bb|{{{cc|{{{dd|{{{ee|{{{ff|}}} }}} }}} }}} }}} }}}|...then...
A gated-if can check for 6 parameters in the same time as 2 regular "#if" structures, which means that it is 6/2, or 3x times faster than using a separate "#if" for each rare parameter. Once inside the gated-if, then each rare option can be tested with a separate if-structure, but the speed advantage comes from rejecting the empty parameters in the one, outer gated-if, rather than 6 separate top-level ifs.

Another tactic is to stop adding hundreds of special parameters to templates, and instead just have a few dozen customizable label parameters, which could handle numerous special data items. A more complex technique is to create a wrapper template for complex, rare cases, such as Template:Convert/spell:
  • {{convert|spell=in |7.45E12|mi|ly}} → seven trillion four hundred fifty billion miles (1.267 ly)
  • {{convert|spell=on |7.45E12|mi|ly}} → seven trillion four hundred fifty billion miles (one point two six seven light-years)
As a wrapper template, {convert/spell} handles the hideous complexity of changing numerals into words, while underneath, Template:Convert was not further complicated to show spellings. To allow the wrapper to function, then the inner base ("/core") template must have general input/output parameters to selectively access the inner template's options. The base /core template should be kept relatively small (unlike many /core today), and the rare parameters would be processed by the wrapper template, with a different wrapper template name used only for those rare cases. Meanwhile, using the base template directly could then be extremely fast, because it would not even check for the peculiar rare parameters known, and formatted, only by the wrapper templates. Next year, there are plans to upgrade some templates to invoke Lua script modules (currently being written) to perform "compiled" processing of parameters, perhaps 20x-100x-100,000x faster in some cases. Anyway, more people are learning those techniques, and many templates are becoming faster already. -Wikid77 (talk) 08:27, 3 November 2012 (UTC)
This is all very interesting, but I still wonder about the higher level aspects. Like, is this "error" condition really a problem? And could the presentation of the message be less drastic? ~ J. Johnson (JJ) (talk) 23:18, 4 November 2012 (UTC)
The wp:Wikimedia Foundation error should probably be changed into a less-scary, timeout-related message, and perhaps state how a prior edit was most-likely saved. However, a reformat time of 60 seconds is really a "hog page" and something major is wrong there, because by comparison, a huge page with no templates, but 25 images, can reformat within 2 seconds (as 30x times faster than a 60-second timeout). Do not be deceived: These articles which run 40 seconds to reformat are grossly, hideously inefficient; as I mentioned elsewhere, to burn 40 seconds of server time, the {cite_web} or {cite_news} or {citation} templates are checking for over 50,000 unused/empty parameter values in one article. We must stop 60-second articles, to insist on sanity in template usage; otherwise it is a terrible waste of server resources, and makes the developers seem incompetent, when in fact a massive article could reformat, entirely, within 2 seconds, because the developers have maintained excellent software for rendering the pages. And there are over 400 file servers to format articles. I regret to sound tyrannical about the speed issue, but when an article could reformat within a few seconds and instead runs to 60-second timeout (no display of article), then that should be a wakeup to not waste resources like a firehose to fill a cup of water. -Wikid77 (talk) 00:32, 5 November 2012 (UTC)
I would tend to agree. But no one else seems interested. Was this the wrong place to ask? ~ J. Johnson (JJ) (talk) 22:31, 6 November 2012 (UTC)
The general sentiment (or at least what I've seen) currently is that mw:Lua scripting will be here soon, and that should fix all the template problems we've been having lately. Since we know that a fix is right around the corner, there isn't much effort being put into finding an interim solution. Legoktm (talk) 22:42, 6 November 2012 (UTC)

Pop-up (and pop-down...)

Sometimes when I've saved things recently, I've caught sight of a tiny pop-up with a green tick and a few words in it at top centre of the screen. By the time I focus on it, the damn thing's gone. I presume it approves of what I've done (and I've not seen one with a red X yet...), but I am curious to know what it is. I'm not asking for it to stay popped up for longer. I'd prefer it not to do it at all. I just want to know what it is. Don't ask for a screen shot - I don't know when it's coming, and it's quick. As usual, I'm on Monobook in classic view XP Pro and Firefox 14. Peridon (talk) 19:21, 5 November 2012 (UTC)

It's the new feature discussed in a section above Wikipedia:Village pump (technical)/Archive 105#Small new feature coming on Thursday: a box that says "Your edit was saved". 19:32, 5 November 2012 (UTC)
Yes, what DrKiernan said. I tested this in XP/FF 14, and it correctly appeared for the two second interval. If you want to hide it, the following should go in your common.css:
.postedit {
   display: none;
}
Let me know if you have any other questions. Steven Walling (WMF) • talk 19:41, 5 November 2012 (UTC)
Yes: why is the text so small? It looks like this and is unreadable and disappears so quickly that I don't have time to drag a mouse over to copypaste the text to somewhere else. I only know what it means because of the announcement at Wikipedia:Village pump (technical)/Archive 105#Small new feature coming on Thursday; I couldn't tell you exactly what it says. --Redrose64 (talk) 20:20, 5 November 2012 (UTC)
It's because of the method we use for scaling the text, plus the fact that Monobook sets body text size small. This is tracked in bug 41404 and we're working on a fix. Steven Walling (WMF) • talk 20:31, 5 November 2012 (UTC)
Thanks for the explanation and the tip - it seems to have gone now. Sorry to whoever spent time creating it - I just don't like what I consider unnecessary frills. (Hence using XP in classic view, and sticking to Monobook, etc...) I know if something hasn't saved (99.5% of the time). Peridon (talk) 11:27, 6 November 2012 (UTC)

Display chess games from PGN data

Hi all.

so there is an extension in mediawiki, called mw:Extension:EmbedChessboard. i liked the idea, but did not like the implementation. this is a very capable software, but it is made of too many files, and the code is less readable than one would wish. it has php part and javascript part, with many files, (the main JS file is some 4000+ lines, 146KB) and many capabilities.

there is no way such an extension will be added to any wimimedia wiki.

it does many things, but the main thing i was interested in is the ability to display chess games, with animation, from data presented in Portable Game Notation format, aka "pgn".

as mentioned, i liked the idea a lot, the implementation not so much. so i developed a script that can do this, which is in use now in hewiki.

this is a 700 lines, 22KB script that displays chess games. we built in hewiki a template around it, that displays chess games from PGN data. the template's page is here: he:Template:pgn. you can view a demo page i created for English speakers in my user space: he:משתמש:קיפודנחש/ארגח 1.

if it's not yet clear, let me clarify: the purpose of this message is to propose adoption of the script and template in enwiki. the script has no specific language strings. the template, if enwiki will decide to adopt it, will require a bit of translation.

peace, קיפודנחש (talk) 22:45, 5 November 2012 (UTC)

Very nice.
  • I miss a "back one move" button < as a companion for "next move" button > (although it is possible to click individual positions to return to them).
  • It would be better if the "play" button turned into the conventional "tape recorder stop" symbol with two vertical bars during playback of a game.
  • The tape recorder idiom is so well understood for these sorts of playback interfaces that providing first- and last-position buttons as well and using the familiar layout would be desirable.
This presentation cannot replace a written-out listing of the game(s), from the point of view of accessibility (there is only a warning about enabling JavaScript if that is not enabled, for example), but would certainly enhance chess game articles. --Mirokado (talk) 23:58, 5 November 2012 (UTC)
i do not see the value of a "back one move" button (as you noted, the reader can go straight to any specific move she wants). if some real chess aficionados will step forward and claim that "back one move" button is important, that can be added.
currently, in hewiki, if javascript is not enabled, we display a message saying something like "to view the games you need to enable javascript in your browser". we could just as well show the actual PGN notation in this case: many chess publications do show chess games in pgn notation or something very similar, and most serious chess hobbyists can read chess games this way. i can't think of anything else that can be done to support accessibility, but if someone will come with a good idea, i will definitely consider implementing it.
right now the question is this: is enwiki interested in using this script/template? if the answer is "yes", or "yes, but we want such and such changes", then we can discuss those changes. if the answer is "enwiki is not interested at this point", that's also cool. if the right place to ask such a question is somewhere else, i'd appreciate some directions.
since this is not my home wiki, maybe i posted this question in the wrong place. is there a "chess club" in enwiki that i can go to and get their opinion on the desirability of this?
peace - קיפודנחש (talk) 15:18, 6 November 2012 (UTC)
It is good user interface practice to provide a back button as suggested in a predictable place, rather than making the user look for the right place to move the cursor each time.
I suggest you notify WP:WikiProject Chess at their talk page WT:WikiProject Chess. Starting the conversation here was quite reasonable though since adding this is a general technical issue as well as involving one particular project. --Mirokado (talk) 16:40, 6 November 2012 (UTC)
thanks. i did just this (actually, in the talk page of the project). as to the "back" button: IMO, playing a single move backward is just as likely as moving back 5 or 12 moves, IOW not very common action at all. chess games are played forward... :)
note that my forte is coding, not chess, so as mentioned above, if some chess experts will claim that a "back" functionality is actually required, or at least useful, i'll re-implement it (it was in the prototype, and removed after some consult).
thanks again for your input and direction, peace - קיפודנחש (talk) 17:26, 6 November 2012 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_104&oldid=1237715602"