Misplaced Pages

This is an old revision of this page, as edited by PartTimeGnome (talk | contribs) at 21:00, 18 October 2012 (→File:Inkscape 0.48.2.svg not rendering properly at small sizes: Snap!). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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

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

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

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

Village pumps

policy

tech

proposals

idea lab

WMF

misc

• Refining the administrator elections process
• Blocks for promotional activity outside of mainspace

• view
• edit
• history
• watch
• archive
• talk
• purge

Upcoming changes to the edit window (please read)

Proposal

Hey all :).

So, the new Micro Design Improvements team has been looking at various things to tweak to try and make Misplaced Pages'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:

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 Misplaced Pages. (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 Misplaced Pages, 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 Misplaced Pages 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)

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)

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)) 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 Misplaced Pages: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 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[REDACTED] 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 Misplaced Pages! 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 " 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:

<input type="hidden" value="53c8a195abb99a05ed87d1b7e2590baa+\" name="wpEditToken" /> (from this editor)

<input type="hidden" value="+\" name="wpEditToken" /> (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 Misplaced Pages 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.

<link rel="stylesheet" href="//bits.wikimedia.org/en.wikipedia.org/load.php? ... modules=ext.gadget.ReferenceTooltips%2Ccharinsert%2C ...

<script>if(window.mw){mw.loader.implement("user.options",function() ...,"gadget-charinsert":1, ... // settings from my preferences

<script>if(window.mw){mw.loader.load([...,"ext.gadget.charinsert", ...

In the source for the new editor, there isn't an apparently equivalent <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) Template:J 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: . 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 Misplaced Pages: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 Template:J and copywarn2/copywarn3 lines, and it suppressed the entire "By-clicking-Save" blurb, so the "" button is only 4 lines (not 13) below the edit-window. Best improvement to Misplaced Pages in 4 years! (after the 2008 recursive descent parser for templates). -Wikid77 (talk) 22:50, 7 September 2012 (UTC) Template:J

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 Misplaced Pages: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)

• If a browser supports 'placeholder' attribute, we could move the "Briefly describe the changes you have made" there perhaps ? —TheDJ (talk • contribs) 12:15, 6 September 2012 (UTC)

  As a complete non-techie; what does that refer to, sorry? :). Okeyes (WMF) (talk) 12:31, 6 September 2012 (UTC)

  Link, see the search field of vector for example. —TheDJ (talk • contribs) 12:34, 6 September 2012 (UTC)

  Aha. So, as proposed above? See "One idea that..." Okeyes (WMF) (talk) 12:36, 6 September 2012 (UTC)

  But if the text disappears as soon as you click on it, presumably it can't include the link to Help:Edit summary, which is the bit I find a nuisance, because it would disappear when clicked on, not act as a link? - Arjayay (talk) 13:13, 6 September 2012 (UTC)

  Depends how we implement it. So, we could have "Edit summary" above the box, with a link there, and then the text that normally follows it within the box. At the moment we're just playing around with ideas :). Okeyes (WMF) (talk) 13:20, 6 September 2012 (UTC)

  One problem that I see with this idea concerns section editing. When you edit any non-zero section, the edit summary is pre-filled with the section title, enclosed in C/Java comment markers /* ... */ (except that there is a MediaWiki bug where that breaks if there is a HTML comment after the section header). Presumably this pre-filled edit summary cannot coexist with the placeholder attribute, which only appears for an empty <input /> item. --Redrose64 (talk) 15:43, 6 September 2012 (UTC)

  This totally misses my orginal point - you're proposing to keep the "Edit summary" link, which is the only bit I would like moved, immediately above the box, and fiddle with what goes in the box - I agree with Redrose64 this creates problems with section editing without addressing my problem. - Arjayay (talk) 08:22, 7 September 2012 (UTC)

  What would your suggestion be, then? :). Okeyes (WMF) (talk) 16:18, 7 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 Misplaced Pages: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 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. 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)

Drop down box and javascript

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 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 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)

• Nice move! Looks great! --Tito Dutta ✉ 18:07, 24 September 2012 (UTC)

  Thanks! :). Okeyes (WMF) (talk) 20:25, 24 September 2012 (UTC)

Header when editing

In the header above the edit window, there is the text "... Work submitted to[REDACTED] can be edited, used and redistributed by other people at will." Should Misplaced Pages 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)

Links and templates

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'm not one of those complaining; to those who have complained, I merely offered a solution based upon what I have used for years (MonoBook skin and RefToolbar 1.0). --Redrose64 (talk) 21:00, 2 October 2012 (UTC)
    • See, this is why timezone differences suck; I'm expected to work sensibly at 10 in the evening ;p. My apologies - I meant RedSox! Okeyes (WMF) (talk) 21:07, 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! --Nathan2055 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? --Nathan2055 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... --Nathan2055 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)

• Please also give back the find and replace option. 76Strat  da _Broke da (talk) 04:00, 28 September 2012 (UTC)

  What find and replace option? Okeyes (WMF) (talk) 04:02, 28 September 2012 (UTC)

  It use to sit near the top of the right side bar of the edit pane. 76Strat  da _Broke da (talk) 04:06, 28 September 2012 (UTC)

  It is still there. You need to have the advanced tab open. Ryan Vesey 04:11, 28 September 2012 (UTC)

  Thank you Ryan; Have you seen the new teahouse? 76Strat  da _Broke da (talk) 04:29, 28 September 2012 (UTC)

  Yep, I'm not sure that I love it though. Ryan Vesey 20:05, 28 September 2012 (UTC)

• Is the editing palette (the one that was at the bottom with the drop-down menu) supposed to be missing? I miss having them all concentrated in one place. Specifically, I was looking for the paired tags that are an essential part of the wiki markup and that I use almost in every edit. Sure, the entire edit window is much cleaner. but let's face it they are not all 'advanced' functionalities but basic ones. It's now like somebody has cleared away my desk and put my keyboard and pens somewhere that's more cumbersome for me to locate each time I need them. -- Ohconfucius  04:22, 28 September 2012 (UTC)

  As said; we're restoring it :). In the long-term, I want to put them in the "special characters" section (it's silly that they aren't there already). So, to use your analogy; we're giving you your keyboard back, and then swinging by to install one of those roll-out shelve things in a few weeks :). Okeyes (WMF) (talk) 04:48, 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. Brandmeister 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:

became

Insert a picture galleryInsert block of quoted textInsert a reference

The others were unchanged. --Redrose64 (talk) 12:55, 28 September 2012 (UTC)

Looks better now, the entire advanced set appears uncollapsed. Brandmeister 13:29, 28 September 2012 (UTC)

• Wait, where are all the menus that used to be at the bottom? diactritics; wiki mark up codes, etc. I'm sort of at a loss now, Shawn in Montreal (talk) 19:57, 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; Misplaced Pages: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 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)

• An awfully long time has passed. Any word yet on when the fixes will finally be deployed? --Tryptofish (talk) 18:23, 7 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)  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 {
	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)

• Misplaced Pages:2012 main page redesign proposal/Br'er Rabbit <br /> 04:51, 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 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 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 Misplaced Pages: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)

Copyright notice basically invisible

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> --Nathan2055 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 ...

Ignore the other stuff, but the line of buttons would look something like on this: http://commons.wikimedia.org/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 Misplaced Pages 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 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 16:14, 7 October 2012 (UTC)

My android based phone internet browser now crashes consistently with Misplaced Pages

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 Misplaced Pages 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 Misplaced Pages 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)

Informal RfC: help design a great mobile watchlist and page history view

The WMF mobile team is interested in developing more editor-centric features for the Misplaced Pages mobile site, and two of the things we're currently looking to create mobile-friendly versions of are watchlists and the page history view. Before we start development, though, it would be tremendously helpful to get a quick round of Wikipedian brainstorming on how (or if...) these particular features might be useful. If you'd like to help, please take a moment to answer the following questions:

• How do you currently use your watchlist? (e.g., just to track changes to articles/discussions you care about, to patrol & revert, something else..?)
• What kinds of information and functionality would be most important for you to have on a watchlist that you could access on a phone or tablet? (e.g., just article name/username/edit comment, diff view, something else..?)
• How do you currently use article history pages?
• What kinds of information would be most important for you to have on a page history that you could access on a phone or tablet? (e.g., list of top contributors, first/last edit date and username, something else..?)

If you have other comments/suggestions, feel free to give them! Looking forward to hearing your thoughts on this :) Maryana (WMF) (talk) 19:24, 2 October 2012 (UTC)

1. Watchlist page: Mostly used for checking/verifying changes & reverting vandalism, tracking discussions, reminder to work on an article, reminder to learn about a topic.
2. diff/hist/article name/username/byte-change/edit comment - those are all very useful for me. (username linked to special:contribs not to userpage)
3. History pages: I most often use them to find out if the vandalism I'm about to revert is more extensive. I regularly use them for a quick glance to get an overview of any ongoing disputes or recent large-changes.
4. prev/date/username/byte-change/edit comment - those are the bits I click or read the most. Links to "earliest diff" and "top contributors" are handy when needed, but not essential (for me). —Quiddity (talk) 01:20, 3 October 2012 (UTC)

The navigation popups gadget is an invaluable tool for inspecting watchlist changes. But it only works with the mouseover/hover event, so is not compatible with touch-based devices, even though Misplaced Pages can be edited fairly easily on an iPad.

Could the gadget javascript be enhanced to provide change the mouseover events to click events on touch-based platforms? Even though the gadget has a lot of JavaScript, I think this would be a fairly simple change for someone familiar with JQuery.

Indeed, perhaps many mouse-based editors are unaware of navpops and would enjoy editing more if the existing gadget were promoted more prominently.

— Richardguk (talk) 01:56, 3 October 2012 (UTC)

This might also save bandwidth for users on low-data allowance plans. (Popups is glorious. Definite wishlist.) —Quiddity (talk) 02:15, 3 October 2012 (UTC)

I use my watchlist to track changes, watch for vandalism, and since its in my Bookmark's Bar, I often use it to jump to other pages, like my Talk page or my sandbox. I'd like the watchlist to show the article name, the user (a red userpage is always suspicious), and a link to the diff and an undo button. I use article history to check to see if there are other edits since I last edited and what they did (I'm a bit protective over some articles). I also like checking the Page View Statistics. • Jesse V. 15:55, 4 October 2012 (UTC)

• Thanks for weighing in, everyone! This is very helpful as a starting point. Maryana (WMF) (talk) 17:10, 9 October 2012 (UTC)
• Howdy. I've put together a quick demo mobile watchlist view. What do you, and people, think? It's pretty basic, but I'd happily use it if it looked like that. It should easily support being modified to add more features as well. — Hex (❝?!❞) 10:18, 10 October 2012 (UTC)

P.S. It currently uses generic CSS3 but browser-specific properties could of course be added. — Hex (❝?!❞) 18:47, 12 October 2012 (UTC)

The quick demo is nice. Suggestion: maybe add a small left padding to the text below the title (section, summary, editor). Eran (talk) 07:36, 12 October 2012 (UTC)

Thanks. Done; any better? I also tweaked the styling for improved contrast. — Hex (❝?!❞) 18:45, 12 October 2012 (UTC)

I read on my phone and regret I cannot easily remove vandalism - I wouldn't feel safe editing on a small phone screen. Secretlondon (talk) 22:19, 14 October 2012 (UTC)

Headings in javascript

On Wiktionary Common.js there is code to allow wiki style editlinked headings on javascript pages (search for "Turn headings" to find it). It imports the code from here. I have tried importing it into my monobook.js page here, but I can't get it to work. I tried pasting it directly but that fails as well. Any ideas? SpinningSpark 16:47, 6 October 2012 (UTC)

Anyone? SpinningSpark 11:24, 13 October 2012 (UTC)

new edit window makes me a) wanna leave[REDACTED] or b) I will just deliver sloppy work from now!!

For a few days now when I want to edit at the bottom of the edit window is a grey box instead of the wiki-markup! What? Where is the wiki markup menu? When I click on edit, the markup menu actually appears for an instant, but then disappears! and going through my preferences I can not find any way to change this; and as editing is a annoyingly difficult without the wiki markup tools at the ready, I would like to know what the hell the person in charge was thinking! no wait - not thinking!!! Are we now supposed to know all the markups by memory? What is with new editors?? yeah - every person on the planet knows all the wiki syntax by birth! I am not gonna reference anything anymore - I will just but it into for someone else, who has memorized the syntax to come along and do a proper ref! This is utter garbage! "wikipedia is on a quality drive!" oh yeah! so lets remove all tools required to properly reference, layout and edit an article! if WMF thinks is is helpful, then know this: I am not bothering to edit until I get the wiki markup menu back!!! even the ~ I have to type by hand now!! WTF??? hey - whoever had the great idea to remove even the four ~ come here and do it for me! — Preceding unsigned comment added by Noclador (talk • contribs) 18:08, 6 October 2012 (UTC)

Until the markup comes back, you can get it by either changing your skin or going to Preferences → Editing Then uncheck Enable Advanced Editing Toolbar. Ryan Vesey 18:13, 6 October 2012 (UTC)

thank you!!! thank you!!! I got the markup back!!! I was writing on a huge well referenced section today with over 20 refs and in the end I became so furious! ah - now it is much better!!! thanks again, noclador (talk) 18:22, 6 October 2012 (UTC)

Yes, thanks from me too. I missed many special symbols which don't seem to be duplicated in the set of special characters above the edit window. Thanks × 2, or should I say, thanks ∞ ? StuRat (talk) 18:31, 6 October 2012 (UTC)

Sorry about this, guys :(. We're meant to be re-enabling this today: I'll find out what's happening with it. Okeyes (WMF) (talk) 17:42, 11 October 2012 (UTC)

note that the "re-enable" did work partially: the edittools is back there if you use IE, but not if you use a sane browser (chrome/ff).

peace - קיפודנחש (talk) 18:58, 16 October 2012 (UTC)

WP:Copyright_problems hitting Post-expand include size

Y RESOLVED: see WT:Copyright_problems. -Wikid77 16:07, 12 October 2012 (UTC)

Looking at Misplaced Pages:Copyright_problems template substitution breaks about half way through as it seem to be hitting Post-expand include size: 2048000/2048000 bytes. Is there anything which can be done?--Salix (talk): 08:25, 8 October 2012 (UTC)

Yes -- start clearing the backlog. MER-C 12:55, 8 October 2012 (UTC)

• Split page to separate at 2 months prior (August): I think the post-expand include-size limit will restrict the total page to about 45 days, not 3 months of days. So, I see 2 options: either split prior month data to page 2, or list months in reverse order so that August data truncates (not October data). Consider moving the 2-month prior days to a separate page; in this case, all of the August 2012 entries should be moved into a separate page, then in November, move the remaining September days out. However, if the current October+September entries were not partially cleared soon enough, then they would total over 45 days, although so far, it seems the backlog kept September (prior month) to less than 20 days now, allowing to fit 25 days of October (subtract 45-20). I am not sure who to contact, and how to coordinate, but it would be a trivial task to edit all the August days into a separate page, as long as "everyone" knows to split the entries in that manner at the end of each month. I agree that losing direct display/search of 8-day prior entries is horrible, and would prefer August days truncated instead, so another (easy) option is to simply re-display whole months in reverse order (but keep day order), so that month of August is at bottom of list. Anyway, splitting 2-month prior (August) data into a separate page, might be easiest solution for all, perhaps as page "Misplaced Pages:Copyright_problems_older" and tell everyone about that planned split. Those are 2 easy solutions to the very annoying problem. -Wikid77 (talk) 12:45, 10 October 2012 (UTC)

• Numerous Template:La can be reduced almost half to allow 70 days: Another option, as suspected earlier, is to optimize the heavily used Template:La, repeated hundreds of times to link article names & edit/history/watch, to be 40% smaller. That would make the size of each day's article links smaller, to allow perhaps 70 days to fit in the overall WP:Copyright_problems, so that 25 more days could be fully displayed. -Wikid77 (talk) 15:09, 10 October 2012 (UTC)

I have to ask: the problem is very annoying to whom? Is it actively discouraging anyone who is otherwise willing to work on clearing the copyvio backlog, since that's who the page is largely targeted at. Others who visit the page shouldn't actually need to see the contents of the latest pages anyways. I think splitting the page or forcing reworking pages at the end of every month would just be making more work for the few who already spend their time there.

The listings at CP proper don't use {{La}}, those are the listings at the {{SCV}} subpages. The listings at CP are already using {{subst:Article-cv}}, so maybe MadmanBot/CorenSearchBot/VWBot can be set up to substitute something as well, although some other optimization of the template certainly seems a reasonable step.

All that said, I'm with MER-C on this one, clearing the backlog is really the best and only long-term solution. That of course requires more editors and admins with the time, skills, and interest to deal with them all. VernoWhitney (talk) 18:02, 10 October 2012 (UTC)

There reason it is annoying is for people who want to submit a new copyright problem, thats how I came to the page. You can't actually see the todays as the Misplaced Pages:Copyright problems#New listings is not transcluded correctly. Perhaps the easiest thing to do would be to put the new listing first, so these would be visible. The broken page did discourage be from listing two problems, but I did manage to sort them out myself.--Salix (talk): 19:20, 10 October 2012 (UTC)

That's an issue with the documentation then, rather then a technical problem. The technical issue certainly isn't helping the situation, but you shouldn't have been put in the situation of needing to scroll to the bottom of that page in the first place.

If you read from the top of the page you get to "Instructions for listing text-based copyright concerns". Both that section and the instructions on the {{subst:copyvio}} template link directly to today's subpage where new taggings are listed, bypassing the whole template-transclusion-overload problem.

This is getting away from the technical issue, but what made you go looking down the page by hand (so to speak) to try and figure out how/where to list a copyright problem in the first place? How could we make it clearer/easier for you or others in the future? VernoWhitney (talk) 22:01, 10 October 2012 (UTC)

• Template:La/x cut size 3x smaller and can omit redlinks: The new Template:La/x is being used to make article link-menus 3.3x times smaller than {La}, and so the overall page is almost 3x smaller as well. Also, there is still the option to split the page, but maintenance editors are accustomed to seeing whatever will fit before the size-limit truncates later days. Also, there is talk of changing some Bot programs to remove redlink entries of copyvio pages which were deleted, to reduce overall page size by about half for the prior week. Discuss at WT:Copyright_problems. -Wikid77 16:07, 12 October 2012 (UTC)

Problem on Special:UserLogin?

I just noticed that when I logged in just now, and clicked on the 'Return to...' link, it sent me to https://, the secure server, instead of the normal en.wikipedia one, when the page I had been on before clicking login was in fact the http:// link. This seems like it should be addressed? - The Bushranger _{One ping only} 02:13, 9 October 2012 (UTC)

It might be a bug in the MediaWiki code. I'm investigating it right now. PleaseStand (talk) 05:11, 9 October 2012 (UTC)

It is. See the Bugzilla link for details. A patch has been posted on Gerrit but has not yet been reviewed, merged, or deployed. PleaseStand (talk) 05:37, 9 October 2012 (UTC)

Bring back the Cite function

It was a bad idea to get rid of the Cite function. WP:VERIFY is a policy that states that information should be verifiable. This means we need citations. This can't happen if there is no user friendly function for it. I propose that the Cite function be put back in or maybe a place down where the "Insert", "Wiki Markup", "Symbols", etc are. Kingjeff (talk) 16:53, 9 October 2012 (UTC)

The cite function wasn't gotten rid of, there are occasionally some problems that make it disappear, I don't know what those problems are. I suggest going to Preferences → Editing and unchecking enable enhanced editing toolbar. There is a cite button there that works even better than the current one. Ryan Vesey 17:01, 9 October 2012 (UTC)

That doesn't look very user friendly. Am I only suppose to put the link there and nothing else? Kingjeff (talk) 17:10, 9 October 2012 (UTC)

If you click the cite button, it gives you all the buttons the normal editing toolbar gives you and more. Maybe the cite button is missing from both toolbars? Note that the cite button should be on the far right and it has two left curly brackets on the top, the word CITE in the middle, and two right curly brackets on the bottom. Ryan Vesey 18:33, 9 October 2012 (UTC)

This one: --Redrose64 (talk) 18:45, 9 October 2012 (UTC)

I think it is just a bug: MediaWiki talk:RefToolbar.js#Error: mw.usability is undefined. Helder 17:17, 9 October 2012 (UTC)

I see both cite functions in both the enhanced and unenhanced now. But if a bug is an issue, it might be better to have a reference options where "Insert", "Wiki Markup", "Symbols", etc are. I know I had to referesh my page a few times before because it wasn't there. Kingjeff (talk) 02:08, 10 October 2012 (UTC)

• No link Most probably you don't get that "Cite" link in unenhanced toolbar when you can not find cite link in enhanced toolbar. Yesterday when Ryan suggested me to click on cite link I did not see any (see my thread above). Now my cite link is back in enhanced toolbar and I can see the extra buttons in unenhanced toolbar too! Very useful I must say, but, it'll be helpful too if it is found when needed!--Tito Dutta ✉ 05:56, 10 October 2012 (UTC)
• Or on a second thought, are both the cite links getting affected at the same time? --Tito Dutta ✉ 05:57, 10 October 2012 (UTC)

• I haven't had a Cite button on my enhanced toolbar for at least two days, if not more.  —  Maile66 (talk) 13:16, 10 October 2012 (UTC)

The Cite button had gone missing on my toolbar this past week also. This morning, I reset all my preferences to default, and then went page by page to add variations, and now the Cite button has re-appeared in my toolbar by magic. Just suggesting to give it a try... --Funandtrvl (talk) 15:44, 10 October 2012 (UTC)

OK, thanks. Tried it. Changed skins, too, and changed back. Nothing worked. Cite button still not there.  —  Maile66 (talk) 19:15, 10 October 2012 (UTC)

You could go to Preferences → Pending changes and check the box under the section "Editing" and check the box to enable ProveIt. I'm not a fan of it as a reference tool, but I usually use it when the normal cite button is missing. Alternatively, you could use Google Books for all of your sources and use this reference maker. Ryan Vesey 19:19, 10 October 2012 (UTC)

By the way, thanks for mentioning the Google Books reftag maker. I didn't know about this and use Google Books a lot, although not exclusively. Still don't have my cite button back. Goodness knows, I have tried unchecking and checking everything. It's just one of those things. — Maile (talk) 15:41, 13 October 2012 (UTC)

Yeah, boy! I've had Provelt as a backup since this first started acting funky months ago. The citation template from the Cite button is somewhat easier in that it doesn't hog my entire screen while I'm working in it. The Provelt offers more options. It's just nice to know I can use either one, depending...but this is not one of those times. Thanks for mentioning Provelt. — Maile (talk) 22:10, 10 October 2012 (UTC)

Is it possible when editing as an IP to have the "rollover" feature available?

The reason I got an account was becasue I really like the "roll over" feature that previews stuff. I still like to edit as an IP. Is there any way to have this feature as an IP? I hope this makes sense for my first village pump post. Thank you. --Malerooster (talk) 20:13, 9 October 2012 (UTC)

I guess you mean Navigation popups at Special:Preferences#mw-prefsection-gadgets. Misplaced Pages:Tools/Navigation popups#Installation says: "You must have a user account in order to install and use the Navigation popups feature. If you do not have an account, you will need to create one and log in." PrimeHunter (talk) 22:28, 9 October 2012 (UTC)

I think we should make the popups something readers can use. It's a great feature and it is better for readers than it is for editors. We could save if someone wants it on or off using a cookie. We'd need to make some modifications, I'd say take all of the editing tools out of the reader one. Ryan Vesey 22:31, 9 October 2012 (UTC)

Is popups expensive on the servers? PrimeHunter (talk) 22:52, 9 October 2012 (UTC)

Thank you and yes, it would be very nice for IP readers to be able to use this feature as well. --Malerooster (talk) 00:42, 10 October 2012 (UTC)

PrimeHunter - No more expensive than an API call. Osarius - Want a chat? 14:24, 16 October 2012 (UTC)

See

• bug 29301 - gadgets for anonymous users (WONTFIX)

Helder 01:00, 10 October 2012 (UTC)

I wouldn't see this as specifically excluding the second idea. There's a difference between enabling gadgets for ip editors and creating one gadget that can be used to increase Misplaced Pages's utility to the readers. (There's an easy justification for not allowing ip editors to use these in that using these gadgets is a benefit of creating an account) This might be something that would need to be a WMF project though. On that note, perhaps promoting the existence of this gadget would cause readers to create an account just to use the gadget. Once the account is created, some of them might be more likely to contribute. Ryan Vesey 02:17, 10 October 2012 (UTC)

Its why I got an account :). I actually prefer to edit as an IP, that is why I asked. --Malerooster (talk) 02:40, 10 October 2012 (UTC)

There's nothing conceptually wrong with enabling gadgets for all readers - for example, the "cite" buttons in the edit bar are functionally a gadget enabled for everyone, AIUI. However, would this involve setting it up for all readers and then saving a "turn off" cookie? I can imagine this being quite unpopular... Andrew Gray (talk) 18:02, 12 October 2012 (UTC)

I would assume it would work that way. Although, it is entirely possible to have a turn-on cookie. Leave a link in the sidebar or at the bottom of every page. When it is rolled out, a message can be displayed at the top of the screen informing readers of the change and allowing them to turn it on if they wish. Ryan Vesey 14:28, 16 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) . 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 _words 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)

Something weird with POTD (need quick response before POTD is changed)

Hope you have both FF and IE. Have a look at my userpage (User:Rehman). You see a different POTD on each browser... Some coding issue with POTD? Rehman 13:00, 10 October 2012 (UTC)

Same phenomena with DYK and ITN as well... Rehman 13:04, 10 October 2012 (UTC)

I flushed your userpage, forcing the server to update its cache. They now display the same. Reaper Eternal (talk) 13:11, 10 October 2012 (UTC)

Thanks :) Rehman 13:14, 10 October 2012 (UTC)

For information on how to do that, see Misplaced Pages:Purge. Graham87 09:52, 11 October 2012 (UTC)

what is the purpose of { { Citation | } }

on this page, Vlad (musician), under discography, there is such a format: {{Citation| last =] | title =Euphoria | year =2012 |publisher=] }} : what is the purpose of it and where is it explained please - 62.203.78.121 (talk) 15:01, 10 October 2012 (UTC)

The purpose is to provide a citation to a source that supports the information in the Misplaced Pages article. That particular method of producing a citation is explained at Template:Citation. Jc3s5h (talk) 15:03, 10 October 2012 (UTC)

• {Citation} formats a cite with commas: The Template:Citation will format a citation, with parts separated by commas, but with no ending dot "." as in the following example:

• {{Citation |last=] |title=Euphoria |year=2012 |publisher=] }}

Result:   Ruslana (2012), Euphoria, EMI

The alternative Template:Cite_book will format a similar line, but with dots "." (not commas) between the parts, plus putting a final dot "." at the end. -Wikid77 (talk) 16:21, 10 October 2012 (UTC)

thanks. i understand the word "citation" as "enumeration" here, right?, BUT, in the mentioned article (vlad), what is the reference, what supports the information? 83.78.52.112 (talk) 07:47, 11 October 2012 (UTC)

The {{citation}} template appears to be being used here merely to format the discography rather than provide a reference. In other words, the material is unreferenced. SpinningSpark 09:19, 11 October 2012 (UTC)

The word "citation" here means "citing a source to verify the text" but it appears the album Euphoria by singer Ruslana is being mentioned, not a text source. Perhaps run Google Search with "Ruslana * Euphoria" to see if "Vlad" is connected with Ruslana in the text of those webpages. -Wikid77 (talk) 09:33, 11 October 2012 (UTC)

thanks all of you 62.203.206.171 (talk) 07:25, 12 October 2012 (UTC)

Reduce Template:La size

We should improve Template:La to be much smaller, to allow pages using {la} to be much larger (see: Template:La/sandbox2). For months, there have been questions about the page WP:Copyright_problems breaking on the final day-entries, as exceeding the post-expand include-size limit of 2,048,000 bytes (2,000 kb). As suspected earlier, a possible fix is to optimize the heavily-used Template:La, repeated thousands of times to link article names & edit/history/watch, to be much smaller. But we were thinking: It couldn't be that simple a fix. Well, yes, it could. That would make the size of each day's article links smaller, to allow perhaps 70-80 days to fit in the overall WP:Copyright_problems, so that 25-35 more days could be fully displayed. I propose to condense {la} by embedding the markup from Template:Lx and optimize the combined markup, as in Template:La/sandbox2. The results:

• {{La | Continual improvement}} Template:Nb10 → Continual improvement (edit | talk | history | protect | delete | links | watch | logs | views)
• {{La/sandbox2|Continual improvement}} → Continual improvement (edit|talk|history|links|watch|logs)
• {{La | 80/20 Rule}} Template:Nb10 → 80/20 Rule (edit | talk | history | protect | delete | links | watch | logs | views)
• {{La/sandbox2|80/20 Rule}} → 80/20 Rule (edit|talk|history|links|watch|logs)
• {{La | better Than Ever}} Template:Nb10   → Better Than Ever (edit | talk | history | protect | delete | links | watch | logs | views)
• {{La/sandbox2|better Than Ever}} → Better Than Ever (edit|talk|history|links|watch|logs)

Of course, the results should be tested with secure-login "https:" because we do not want to risk an accidental link to http-protocol URLs. However, let's try to improve this template soon. It would make numerous article-maintenance pages almost 2x smaller (60%) and faster to process. Sometimes, the simplest changes can have the greatest impact, when used in "200,958" pages. However, we still want editors to reduce the size of large maintenance pages, in the future, but this quick change should give them another year (or 2) before seeing the current size problems again. -Wikid77 (talk) 16:21, 10 October 2012 (UTC)

• Submitted {editprotected} after checked for secure https: I verified all options will work during a secure-login session with "https" and there were no objections here, so I submitted the formal update request at the related talk-page Template_talk:Ln. Meanwhile, I verified how reducing {La} will solve the include-size error in page "WP:Copyright_problems" by using {La/x}, which handles article-link menus as 3x smaller. -Wikid77 (talk) 10:01, 11 October 2012 (UTC)

Problems with templates and tables at the bottom

Hi,

I hope that this is the right place for posting this.

Time and again I see articles on which templates, usually at the bottom, are not displayed correctly. Sometimes it's a bug in the template and sometimes it's a bug in a table that appears on the same page.

When I see it, I try to fix it. I managed to fix it myself in the articles Moscow State University and Isobel; I couldn't find how to do it in Untitled Korn album, but it seems fixed now.

Isn't there some automatic way that would detect it? For example, an invalid table as appeared in Moscow State University before I fixed it, should be reasonalby easy to detect, and then a warning could be shown to the editor who tries to save it. --Robkirwan (talk) 09:04, 11 October 2012 (UTC)

• Error detection and correction requires specific rules: Wiki-markup is a hodge-podge of different language formats, not easily predicted or explained to the user. Looking for the end-table marker "|}" is only one of many problems, because a wikitable could also be ended by "</table>" as in HTML. However, there are warning messages issued for undefined reftags "<ref name=xx>" or for reftags not used but defined within {Reflist|refs=...}. Previously, in major computer languages, the keywords or "tokens" have been specifically chosen, by the language designers, following a context-free grammar, to spot errors in logic and suggest, or auto-correct, the logic to continue checking the rest of the source code. Those languages have clever features; for example, an if-structure uses tokens if-else-endif, so when the word "else" appears outside "endif" then a warning can be issued. To locate an error, then line numbers should be used to pinpoint the problem, such as: Found "if" at line 456 but no matching "endif". Some older languages lacked unique keywords, such as LISP, which was clueless to how simple errors could go undetected, over and over, with a syntactically boring language. Note also, how wiki-markup does not use a clever plan, and instead, everything is a blitz of curly braces "{{{1}}}" and vertical bars (pipes: "|") with few or no keyword-tokens to indicate a structure of following clear rules. Because the wiki-markup does not follow that logical format, then detection or rejection of "errors" might be rejecting some editor's pet peculiarisms of markup. There is an old saying in computer software, "One man's bug is another man's neat feature". For years, many computer systems have stopped issuing "error messages" because what seems like a bug or misspelled word, today, might be an optional feature, or a new enhancement next year, or even some poor soul's desperate way to force the spastic markup language to choke out some half-baked result.

  

Of course, for people who have experience with error-reporting systems, then the lack of feedback just seems like hack-software from some novice tinkerer. Consequently, there are systems which provide optional "warning messages" perhaps at the request of each user, but again, unless the markup language was developed by educated people who knew about mnemonic token keywords, context-free grammar, and production rules, then most warning messages are likely to be misleading, as not really related to the peculiar cockeyed squirrelling of the spastic languages features.
For example, a wikitable can be coded with leading spaces before the "{|" or indented by leading colons ":::{| class=infobox" but if there is a space after the colons ("::: {|xxx"), then the table becomes literal text "{|xxx" after the leading space, even though leading spaces can precede a wikitable when no colons are present. For that, thank the wikitable squirrel (). The rules change because the space followed the colons "::: " whereas leading spaces would format the table as expected. For decades, convoluted source code has been called "spaghetti code" and templates can be so peculiar that I call them "spaghetti-plates". So, anyway, I hope that helps explain why obvious problems with tables are not detected with warning messages. -Wikid77 (talk) 11:33, 11 October 2012 (UTC)

"View history" link moved into a javaterror submenu

On 10 october I found that using the default skin, the link has been deported into some messy java drop-down-box using Firefox. Despite using Ctrl+0 and with no option in preferences to fix it. Could someone revert these changes to the last working version?, in addition the javascripts has been causing "Busy javascript - " for at least many months by now. This is indeed counterproductive. Perhaps my contributions over the years are not valuable, but there's likely other that are affected by these counterproductive javascript "additions". If javascript shall be used, it better be done right or it will just cause trouble. Electron9 (talk) 12:43, 11 October 2012 (UTC)

I replied with a possible solution at Misplaced Pages:Help desk#History link deported into javascript hell. As mentioned, many things can affect how many tabs there are room for. If there is not room for the "View history" tab in the default Vector skin then it's moved. Or do you have plenty of room for a wide tab but still get it in the drop-down-box? PrimeHunter (talk) 15:04, 11 October 2012 (UTC)

I'm reading using a 9" screen so there's plenty of space between the Talk and Read tabs. And there was plenty of space before too. I tested now to disable javascript and clear cache, then it works like it should. Please have wikipedias javascript programmers to correct their wrongs. This doesn't work out. Electron9 (talk) 15:19, 11 October 2012 (UTC)

Do you have the "Add page and user options to drop-down menus on the toolbar" gadget enabled, per chance? EVula // talk // ☯ // 15:35, 11 October 2012 (UTC)

It's unchecked (Add page and user options to drop-down menus on the toolbar. Works in Vector, Monobook and Modern skins) Electron9 (talk) 02:28, 12 October 2012 (UTC)

I checked the Atari ST article just to test how things works now, and with javascript enabled. Seems someone has put "View history" back. Thanks for whoever fixed this. I certainly didn't change anything. Electron9 (talk) 02:34, 12 October 2012 (UTC)

I visited the article Ammonium chloride and it first showed "View history" and when the javascript had started to run it disappeared. So obviously it has not been fixed, or reverted. Please someone remove this bullshit from the javascript code! Electron9 (talk) 11:24, 13 October 2012 (UTC)

It's part of the Vector skin that if the JavaScript detects there isn't proper room for the tab then it moves to the drop-down box (in other skins some users have to scroll right to see tabs there wasn't room for). If you don't want this to happen in any circumstances then select another skin at Special:Preferences#mw-prefsection-rendering. If you want to keep Vector and avoid the tab moves then please answer the questions at Misplaced Pages:Help desk#History link deported into javascript hell. As I keep telling you, it depends on many things, for example the number of tabs on a given page, the amount of text on each tab, the font size, and the precise width of the browser window. If the tab sometimes moves for you then it doesn't imply that any code is broken. PrimeHunter (talk) 12:25, 13 October 2012 (UTC)

Making it easier to clean up the Feedback Dashboard

Hey everyone. I just wanted to drop a quick note here that, per discussion at Misplaced Pages talk:New editor feedback, we've enabled to two changes to Special:FeedbackDashboard today:

1. There is now a delete function available to sysops. Because this is not content, but is ephemeral feedback, there is no undelete. This should pull double duty as a tool for dealing with content would otherwise be a candidate for oversight or revdeletion.
2. The "hide" function is available to all autoconfirmed editors. This isn't dangerous, since it can be unhid by the same group. We should now be able to use hiding to remove feedback which is completely incomprehensible or otherwise very low quality, in order to narrow down the list of feedback comments to respond to.

I've tested these new features out, but please speak up if you see any bugs. We also deployed a fix, so that preview of your response works again. Thanks, Steven Walling (WMF) • talk 22:38, 11 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 Misplaced Pages 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)

Tool to rank editors by number of contributions

Is there a tool that quickly lists the editors of an article by number of edits? So if I wanted to alert editors about an article, or maybe ask for assistance with a similar article, I could see at a glance who'd be the most interested? Obviously number of edits doesn't equate to amount or quality of editing, but it seems like it would be a useful metric. ▫ JohnnyMrNinja 00:43, 12 October 2012 (UTC)

Go to the history page, and there will be a list of external tools near the top. "Contributors" will give you exactly what you want. jcgoble3 (talk) 00:51, 12 October 2012 (UTC)

Wikichecker is supposed to do this. It only seems to work at the moment for the last 500 edits to the article, but that should be all you need for your purpose. Someguy1221 (talk) 00:57, 12 October 2012 (UTC)

Great, thanks! ▫ JohnnyMrNinja 01:38, 12 October 2012 (UTC)

Also WikiSense/Contributors; view the page history, then select External tools: Contributors. ---— Gadget850 (Ed)  09:33, 12 October 2012 (UTC)

That's precisely what I suggested. jcgoble3 (talk) 19:14, 12 October 2012 (UTC)

Yeah, but people believe it more when Gadget says it --SPhilbrick(Talk) 20:30, 12 October 2012 (UTC)

---— Gadget850 (Ed)  22:08, 12 October 2012 (UTC)

Can't add image to infobox

When an editor moved the image of Modern Age (periodical) to the infobox, it disappeared. I tried to correct it by omitting the prefix, brackets and other extra info, but it still doesn't show up on the screen. The article about the American Conservative uses the same syntax as I used. What is wrong? --Jonund (talk) 09:16, 12 October 2012 (UTC)

 Fixed The template {{Infobox magazine}} uses |logo=, not |image=. When template does not work as expected, check the documentation. There are no proscribed standards for template parameters. ---— Gadget850 (Ed)  09:30, 12 October 2012 (UTC)

The documentation at {{Infobox magazine}} states "logo A logo relevant to the magazine. ... image_file An image relevant to the magazine. (Usually the cover).". The image concerned is not a logo, but the cover; therefore a better choice of parameter would be |image_file=Modern age magazine cover.jpg. That /doc page is very out of date since it does suggest that "The image parameter is available for backwards compatibility, but is deprecated" - the reality is that |image= is unrecognised, and has been since this edit; it's had no visible effect since August 2008. I shall get onto that /doc page right now. --Redrose64 (talk) 22:19, 12 October 2012 (UTC)

?updated since my last visit?

in some page histories I am starting to see "updated since my last visit".

What is the rationale for this notation? What is being implemented here?

What triggers the annotation? Is the color of the annotation supposed to be meaningful?

Do all editors see this? --Ancheta Wis   (talk | contribs) 11:23, 12 October 2012 (UTC)

It's always green. If a page is on your watchlist and you view the page history without having viewed the current page version then all versions since the last one you have viewed will get the annotation. If you want to remove it then add this to Special:MyPage/common.css (applies to all skins) or Special:MyPage/skin.css (your current skin):

span.updatedmarker{display:none;}

PrimeHunter (talk) 11:40, 12 October 2012 (UTC)

Thank you for the explanation. --Ancheta Wis   (talk | contribs) 15:15, 12 October 2012 (UTC)

PC protection revisions and GoogleBot

A serious issue has been raised about PC protection that the devs need to fix. The purpose of PC protection is to prevent unreviewed revisions from being seen yet the API lets the latest revision get pulled. This GoogleBot can see the unreviewed version of a PC protected article. The API should only be allowed to pull the latest unreviewed version to reviewers only while releasing the stable version of the article who does not have access to approve revisions.—cyberpower _Online 14:26, 12 October 2012 (UTC)

Do you have any reason to believe that GoogleBot is using the API? Delicious carbuncle (talk) 14:55, 12 October 2012 (UTC)

See this.—cyberpower _{Limited Access} 15:19, 12 October 2012 (UTC)

File a bug? - Jarry1250  15:29, 12 October 2012 (UTC)

Quite frankly I don't know how because I never had to at this point. I also don't think it's appropriate because the tool is still being developed.—cyberpower _{Limited Access} 15:33, 12 October 2012 (UTC)

Pending changes is not in development for everyone, it's in permanent use on a number of wikis. To file a bug, you register an account at //bugzilla.wikimedia.org (if you don't have one already) and then follow the instructions. - Jarry1250  17:47, 12 October 2012 (UTC)

I saw that. I didn't find it very illuminating. I suspect this may be a conflation of the API and RSS feeds, but time will tell. Delicious carbuncle (talk) 15:43, 12 October 2012 (UTC)

@Cyberpower: once you find out how/where to alert the developers, please let me know. There are other problems that need fixing as well. For instance, having PC on a page roughly doubles page loading times, making it unusable for longer articles. ~Adjwilley (talk) 17:41, 12 October 2012 (UTC)

@Adjwilley: There are no active developers for PC atm and issues go where they always go, namely bugzilla:. I have reported this one. —TheDJ (talk • contribs) 14:30, 13 October 2012 (UTC)

Symbols shortcut row gone

I realize from skimming through the top of this page that this has been discussed extensively, but it's too chaotic to make out whether (a) there's a plan to return the symbols shortcuts that used to be near the edit summary window, or (b) if it's been decided that that the shortcuts are gone for good. One recurring suggestion offered for those who opposed the removal of the easy access to the symbols has been change the preferences such that the citation templates bar and the other things at the top of the editing window are disabled and then the symbols reappear at the bottom near the edit summary window. Question is, Is there a way to preserve the citation templates bar at the top and the symbols shortcuts near the edit summary window at the same time?—Biosketch (talk) 16:40, 12 October 2012 (UTC)

Also beware other editors think the edit-window is too slow, with extra tool buttons, JavaScript, and whatever numerous CSS sub-sub-sub-classes being processed. -Wikid77 (talk) 16:59, 12 October 2012 (UTC)

There's a way to configure the preferences to restore the row of symbols near the edit summary window, but that's not the problem. It's that there doesn't seem to be a way to configure the settings to make the row of symbols and the "Advanced/Special characters/Help/Cite" bar at the top appear together.—Biosketch (talk) 17:49, 12 October 2012 (UTC)

Raise include-size limit to 3 mb

After further analysis, I have concluded that, for processing templates, the post-expand include-size limit (now 2,048,000 bytes) should be increased to 3 megabytes or more. For a cautious approach, the limit could be raised by increments, such as +300,000 bytes each week/month. The reason the limit of 2,048,000 bytes has been far too small, for practical use, is because the way the include-size is counted, for each template, causes templates to artificially double the include-size bytes. The generated page stays the same size, but the include-size can be counted double when a template is used inside another nested template. The suggested limit of 3 mb was chosen to allow current templates to fit within the limits, but avoid encouraging slow pages which would exceed the 60-second formatting limit with wp:Wikimedia Foundation error, which might conceal the page actually running too long due to excessive include-size usage. It is better to show a specific error message for size, rather than have the page die totally as a fatal time-out error with no specifics. Currently, multiple templates which would all fit within 3,145,000 bytes have been formatting within 30-45 seconds, so still comfortably short of the 60-second timeout. Anyway, the post-expand include-size limit should be raised to 3 mb, by weekly or monthly increases, due to the current 2,000 kb limit not allowing for the doubly-counted size of templates within other templates. Of course, alternatively, the partial counting of include-size for each template could be changed to not double in nested templates, but I think just raising the include-size limit to 3 mb would be far easier, and simpler to control. -Wikid77 (talk) 16:54, 12 October 2012 (UTC)

That seems like a very bad idea. All it would do would be make it easier for excessively long and excessively templated articles and pages to exist. If editors took note of the raised limits and started expanding articles then it would lead to more large, slow and difficult to edit articles existing. The proper approach is take that limit not just as a hard limit but also an indication that the article or page has other problems. Probably it is too long: too long to read, too long to comfortably edit. Maybe it overuses templates: instead of a lot of single line templates it could be organised into a table or tables which provide the structure the templates did. Maybe there too many references or links. It could on project pages be an indication of another problem such as a backlog. On a talk page it might mean archive settings need adjusting.

It might be worth considering articles which have this problem. Barack Obama is one but it's also a very long article - it appears on the first page of Special:LongPages so is among the longest 0.01% of pages, the longest 0.005% of non-list pages. The obvious thing to do with that and other long pages is make them shorter, much shorter, by splitting, moving more content into sub-articles, or better editing. The template limit is a hint to do this but it shouldn't be needed: editors should have noticed it's excessive length already.--JohnBlackburne_deeds 00:51, 13 October 2012 (UTC)

• There is always a Cite_quick: Using some technical template-usage limit is not a substitute for policy to reduce the size of articles. What would happen is the creation of other short, quick templates to bypass the limit, and allow some editors to create large pages anyway. Hence, after months of development, the new Template:Cite_quick was able to the rescue the major article "Barack Obama" to no longer crash on the bottom 14 templates (3 navboxes, {Persondata}, Authority control, and the wp:FA/GA interwiki links to the other-language wikipedias). That is a prime example, because {cite_quick} not only allowed all prior "405" of the current citations to be formatted 9x times faster, it also allows another 500 more. In fact, I tested the use of {cite_quick} by copying the text of article "Barack Obama" doubled in the edit-preview, and it formatted all 810 uses of {cite_quick} in 20 seconds, as only half the time used by {cite_news} or {cite_web} to process just 405 cites and crash the article navboxes. If an editor wanted to edit-preview two U.S. president articles combined, then Misplaced Pages could do it, when using quick templates. A template-processing limit should not be used as a substitute for article-size policies, because some people will find a work-around (eventually), to bypass the limit more than 200% double or triple. Again, a huge, huge article with no large templates, but 25 images, can be reformatted within 2 seconds to redisplay with any default image size. That is the power of Misplaced Pages. For large maintenance pages, Misplaced Pages has the capacity to show lists of the past 5 months of activity (to allow top-to-bottom searches), but even quick templates can experience the unfair double-counting of include-size bytes when used inside other templates of a maintenance page. Currently, the larger, longer website URLs can crash the wp:CS1 cite templates, and we do not want people to "shop" for only sources with short URLs or tell others that long newspaper names violate size limits. So, I recommend raising the include-size limit higher, to 3 mb, to avoid artificial limits of page size. -Wikid77 (talk) 09:12, 13 October 2012 (UTC)

Absolutely not. John makes the exact point I was going to--raising the limit will just cause people to make larger and more uneditable articles that take even longer to parse. With Lua on the horizon, I especially can't see us doing this. ^demon 12:14, 15 October 2012 (UTC)

Unwatch link in my watchlist?

Can a genius who frequents VPT tell me if it is possible to add something to my common.js page to add unwatch links to pages in my watchlist? Thanks to anyone who can do this. Ryan Vesey 19:12, 12 October 2012 (UTC)

You should try this script: User:Js/watchlist. Works like a charm.--ukexpat (talk) 19:24, 12 October 2012 (UTC)

It works beautifully, thank you! Ryan Vesey 19:31, 12 October 2012 (UTC)

No problem.--ukexpat (talk) 00:25, 13 October 2012 (UTC)

See mw:Snippets/Unwatch from watchlist. Helder 19:50, 15 October 2012 (UTC)

Why no table of contents at Talk:Racial identity of Tutankhamun

I tried to fix this, what am I doing wrong? Thanks. Dougweller (talk) 05:47, 13 October 2012 (UTC)

According to WP:TOC, a table of contents only appears if a page has at least 4 headings. On that page, there are currently only 3. — Richardguk (talk) 07:13, 13 October 2012 (UTC)

I've added a TOC. DH85868993 (talk) 07:23, 13 October 2012 (UTC)

Thanks. All these years and I didn't know two wasn't enough. Shame on me. Thanks. Dougweller (talk) 08:28, 13 October 2012 (UTC)

Where is the css for diff view?

I am trying to change the colour of the diff view highlighting in my personal css but cannot find the variable names. The links on Misplaced Pages:Catalogue of CSS classes to diff.css and diff.js are deadlinks (as are numerous others in the Page/action specific section. Where is this css really kept? SpinningSpark 09:24, 13 October 2012 (UTC)

It's in the core of MediaWiki, more specifically in /core/resources/mediawiki.action/mediawiki.action.history.diff.css. — Edokter (talk) — 09:30, 13 October 2012 (UTC)

ta SpinningSpark 10:34, 13 October 2012 (UTC)

Sort in tables

I have been trying to improve Athletics at the 2012 Summer Paralympics – Men's discus throw. I show { using ( here. I've been adding ((sort|0|x)) and ((sort|0|-)). But the actual numbers sort alphabetically rather than numerically so we get 1,10,11,2,21,22,3 etc.

Is there a parameter that I can give the table to say sort numerically or do I have to put every number in every table in as ((sort|008.35|8.35)) etc? Is there a limit on the number of ((sort))s in a page? -- SGBailey (talk) 10:57, 13 October 2012 (UTC)

Please notice and report glitches - backend changes coming

On Monday we start deploying a new version of MediaWiki, 1.21wmf2, to the wikis, starting with mediawiki.org and 2 test wikis -- see mw:MediaWiki_1.21/Roadmap for more. English Misplaced Pages gets the update on October 22nd. 1.21wmf2 will have 3 big new backend things in it and we need your help to test now to see if there are any really critical bugs, especially bugs that affect your bots and gadgets.

The three biggest changes

1. The new ContentHandler might affect handing of CSS and JavaScript pages, import/export (including PDF export), and API stuff, especially when rendering and editing. Also look out for issues in template rendering, images and media handling, localisation, and mobile device access. (merged on Oct 9)
2. High-resolution image support. This work-in-progress will try to give higher-res images to high-density screens that can support it, like new Retina displays (more info). One of the bigger risks of the high res stuff is load-based, since we may see substantial new load on our image scalers. So *all* image scaling might be impacted. (merged on Oct 11)
3. "Sites" is a new backend to represent and store information about sites and site-specific configuration. This code is meant to replace the current interwiki code, but does not do so just yet. Still, keep an eye out for site-specific configuration or interwiki issues.

Please test on the beta sites, report defects, and look out for these issues on your sites in the weeks ahead. (Right now the version of MediaWiki on the beta sites dates from 9 Oct and thus has ContentHandler but not the high-res image support or Sites.) These test plans give some ideas on how to find errors.

Thanks! With your help we can find bugs early and get them fixed before they affect lots of readers and editors. Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) 12:40, 13 October 2012 (UTC)

The new code is now deployed to mediawiki.org, test.wikipedia.org, and test2.wikipedia.org. So if you want to test it there, please feel free. Two additional notes:

• The ContentHandler changes may affect diff rendering, so please especially keep your eyes open for that.
• The CologneBlue skin has been refactored, so if you use CologneBlue and notice problems, please let us know.

Thanks. Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) 23:55, 15 October 2012 (UTC)

So, here's a better list of what to watch out for. If any of the following functionality breaks on your site after the deployment on 22 October, please report it as soon as you can:

• revision diffs
• templates
• CSS and JavaScript pages (like user scripts)
• bots
• PDF export
• images, video, and sound, especially scaling sizes
• the CologneBlue skin

If you notice any problems, please report problems at our defect tracker site. You can test for possible problems at test2.wikipedia.org and mediawiki.org, which have already been updated.

Thanks! With your help we can find problems fast and get them fixed faster.

Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) 05:43, 16 October 2012 (UTC)

Main Page hiding its h1 outside of ?action=view

Discussion is here: MediaWiki talk:Common.css#Main Page hiding its h1 outside of ?action=view. --MZMcBride (talk) 15:31, 13 October 2012 (UTC)

Watchlist: Editors are invited to comment on the following:

This now appears on my watchlist (in green) with a list of items. I don't have a problem with that, but even if I dismiss all the items, the green phrase remains; it shouldn't.--Bbb23 (talk) 17:09, 13 October 2012 (UTC)

• Indeed, I was just going to say the same. How was this introduced? Fut.Perf. ☼ 17:12, 13 October 2012 (UTC)
  • It was done here. It's already gone too. — Edokter (talk) — 17:17, 13 October 2012 (UTC)
    • Yes, it's now gone from my watchlist.--Bbb23 (talk) 17:22, 13 October 2012 (UTC)

MD5/SHA hash of page version

Hello!

I was wondering if it were possible to easily access an MD5 (or SHA-2, etc.) hash of a particular page version? I could, of course, compute the hash myself; this would require downloading the entire page, and would put a greater load on resources.

Thank you for any help; figuring out a clever way to do this would be of aid in my research (on the nature of collaborative/decentralized editing -- please see my userpage for details).

Sincerely,

Simon DeDeo Dedeo sfi (talk) 17:19, 13 October 2012 (UTC)

You can use the API to retrieve a precomputed SHA-1 hash for any revision, which has been possible since MediaWiki 1.19. Just specify rvprop=sha1 when making an action=query&prop=revisions query. You can try it out at Special:ApiSandbox, and more information about the API (including documentation and our usage guidelines) is available at mw:API:Main page.

If you use your unprivileged user account to query the API, each query can return up to 500 SHA-1 hashes. Bot and sysop accounts have the "apihighlimits" user right, which allows requesting 5000 hashes at a time. PleaseStand (talk) 18:34, 13 October 2012 (UTC)

Thank you, again, PleaseStand. Dedeo sfi (talk) 18:37, 13 October 2012 (UTC)

Accounts in the "researcher" group also have the "apihighlimits" user right, as well as the ability to view deleted history entries (but not the actual deleted text), though that requires special approval. PleaseStand (talk) 18:42, 13 October 2012 (UTC)

Thanks -- this is very helpful. Is there a standard procedure for requesting "researcher" user status? I dropped Dario a line, following this suggestion, last week, and have not yet heard back. Perhaps there is a more standard request form for this technical change? Dedeo sfi (talk) 18:53, 13 October 2012 (UTC)

Well, m:Research:Access to non-public data does say "Requests submitted to the RCom usually take 1-2 weeks to be reviewed", although I can't find a page about your research project on Meta-Wiki. Perhaps you could create one at m:Research:Projects and send the link to him to help him review your research project. You can log in to Meta-Wiki using your Misplaced Pages user account. PleaseStand (talk) 19:11, 13 October 2012 (UTC)

Terrific, thanks. Let me ask an additional, technical question -- is it possible for the API to return the total number of revisions made to a page? I can't seem to find this (seemingly simple) option at the API listing. Dedeo sfi (talk) 19:24, 13 October 2012 (UTC)

Not unless you count them yourself; see bugzilla:17993. On the server side, it is currently not possible to count the number of revisions in an efficient way. (It is not even possible using the API to find reliable edit counts of users, although in most cases, action=query&list=users&usprop=editcount yields a useful approximate value that includes "edit-like actions". This led to the development of Toolserver tools such as X!'s edit counter, which work using a replicated copy of the database.)

The number of "intermediate revisions" between two specified ones is available on diff pages (e.g. here's one for Barack Obama). Automatically requesting diffs to old revisions, however, burdens the servers, so try not to do that. Instead, try to get WMF assistance if the API does not meet your needs. PleaseStand (talk) 21:02, 13 October 2012 (UTC)

The recently-enabled action=info URL parameter states "Total number of edits". For example, http://en.wikipedia.org/Wikipedia:Village_pump_(technical)?action=info or http://en.wikipedia.org/search/?title=Misplaced Pages:Village_pump_(technical)&action=info — Richardguk (talk) 21:43, 13 October 2012 (UTC)

(drifting offtopic, but) Actually, I'm reasonably certain that action=query&list=users&usprop=editcount contains only edits, and does not contain the dummy revisions added by various log actions. But it also doesn't get decremented if the page gets deleted. Anomie⚔ 22:21, 13 October 2012 (UTC)

Indeed. However here's a minor correction to the history presented above; the edit count field, which was introduced in December 2006, while the first edit counting tool – Kate's tool – was released in late 2004 IIRC, though I can't find the link for that off-hand and I'm in a bit of a rush. Graham87 03:32, 14 October 2012 (UTC)

Kate's edit counting tool dates from some time earlier than December 2004 per this discussion. Graham87 03:56, 14 October 2012 (UTC)

redirect ambiguities

I think it was a couple of years ago that someone explained on some Misplaced Pages discussion page---maybe it was this very page---how to find a comprehensive list of instances of the following kind of thing.

"Xmith's hypothesis" redirects to A

"Xmith's Hypothesis" redirects to B

"the Xmithian Hypothesis" redirects to C

The three are synonymous but A, B, and C are _different_ articles, and it's absurd that synonymous terms with minor spelling differences should redirect differently.

From time to time I come across that situation. After that discussion two or three years ago, I clumsily failed to save for future reference the means by which the comprehensive list was found. Can anyone identify it? Michael Hardy (talk) 18:00, 13 October 2012 (UTC)

A toolserver query could identify some potential duplicates by listing redirect pages with different destinations where the titles are nearly identical (apart from upper/lower case or punctuation), as in your first two examples. But this would not identify "the Xmithian Hypothesis" in your third example.

Toolserver database queries can be requested at Misplaced Pages talk:Database reports.

But I don't see how a more comprehensive list could be compiled automatically.

— Richardguk (talk) 21:58, 13 October 2012 (UTC)

Thank you, Richardguk. Michael Hardy (talk) 23:00, 14 October 2012 (UTC)

Template limit

I was editing a fairly large userspace page (over 270,000 bytes) with an extensive {{Reflist}} with almost 400 individual citations when I got the following editnotice: '''Warning:''' Template include size is too large. Some templates will not be included. After my latest edit, {{Reflist}} no longer displays and is instead a link to the template (which does help since it is a list of citations, not a static template). Under what circumstances does the template limit kick in? Is there are work around for this? – Zntrip 19:26, 13 October 2012 (UTC)

See Misplaced Pages:Template limits#Post-expand include size. PrimeHunter (talk) 19:46, 13 October 2012 (UTC)

• Template:Cite_web exceeding limit: The typical wp:CS1 templates are limited to about 400-500 instances per page. The new Template:Cite_quick allows over 800 citations, in the same CS1 format; however, some people dislike {cite_quick}, so it is intended for rare, large articles, such as yours, to reduce the edit-preview, or reformat, time from 40 seconds to within 10 seconds. Another (older) fast option is to switch to Template:Vcite_web as the Vancouver style of cites. However, the current use of {cite_web} requires that you reduce to fewer than 400 {cite_web} templates, or else change to another cite template. -Wikid77 (talk) 23:23, 14 October 2012 (UTC)

How about you stop canvassing for your template, and get that damned thing working properly? This is getting ridiculous. AndyTheGrump (talk) 23:30, 14 October 2012 (UTC)

• Well, other editors have had no problems using {cite_quick} for 300-400 citations, so I agree the complaints do seem "ridiculous" on balance. However, when considering the bugs in the {cite_web} or {cite_journal} templates, then it is easy to see why many people imagine other templates are "perfect" when they contain far more problems, due to their greater complexity. For example, consider using {cite_journal} to show a journal's volume & issue number:

• Parameters: {{cite journal|author=John Doe|title=Article ABC|volume=3|issue=11|date=8 May 2012}}
• Cite_journal result:  John Doe (8 May 2012). "Article ABC". 3 (11). {{cite journal}}: Cite journal requires |journal= (help)
• Cite_quick result:     Template:Cite quick

Older template {cite_journal} is broken, as unable to show the issue number "11" whereas newer template {cite_quick} still shows issue "11". Other people have incorrectly claimed {cite_quick} was broken, even though it shows more data than the so-called "perfect" {cite_journal} template. Some people even claimed a template "broke" articles when those articles actually used incorrect parameters for the template (articles were broken before the template was added). In general, beware skewed complaints, as not representative of broader reality. -Wikid77 (talk) 04:32, 16 October 2012 (UTC)

{{cite journal}} only appears "broken" here because you're misusing it. You have not provided the parameter |journal= (or one of its aliases |work= |newspaper= |magazine= |periodical=). An issue number is meaningless unless you state exactly which journal it is an issue of.

• Parameters: {{cite journal|author=John Doe|title=Article ABC|volume=3|issue=11|date=8 May 2012|journal=A Journal}}
• Cite_journal result:  John Doe (8 May 2012). "Article ABC". A Journal. 3 (11).
• Cite_quick result:     Template:Cite quick

The displayed output is almost identical (the space between the journal name and the volume is plain for {{cite journal}}, but   for {{cite quick}}); but {{cite quick}} completely lacks the COinS metadata. --Redrose64 (talk) 15:30, 16 October 2012 (UTC)

{{Cite quick}} works well on the page. Thanks! – Zntrip 00:38, 15 October 2012 (UTC)

Yes, I see using {cite_quick} reduced that article include-size to 46%, over 2.1x times smaller, while also much faster. -Wikid77 (talk) 04:32, 16 October 2012 (UTC)

So you are still promoting your unapproved and buggy template, in spite of the clear consensus that it shouldn't have been deployed in its present state? AndyTheGrump (talk)

1) What is your alternative, leaving the page broken? Stop citing sources? 2) Lua is coming. Franamax (talk) 05:20, 16 October 2012 (UTC)

Commons:Template:GFPLM-image-full

I'm trying to nest commons:Template:GFPLM-image into commons:Template:GFPLM-image-full, but the empty params seem to be showing through. Can someone let me know what's wrong with the code? This template will be used by commons:Commons:Gerald R. Ford Presidential Library and Museum. (Originally posted at Commons:Village_pump#Template:GFPLM-image-full.)Smallman12q (talk) 00:05, 14 October 2012 (UTC)

I added pipes between the template parameters. Does it do what you want now? And how dumb do you feel now? ;-) PrimeHunter (talk) 00:48, 14 October 2012 (UTC)

Hehe. I guess I was staring too long at a whitespace indented language. Thanks again!Smallman12q (talk) 01:40, 14 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.

 

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)

Connectivity issues over IPv6 from 2a02:3d8::/32

Hi,

I am the admin for an ISP and we are now deploying IPv6 to some customers

bits.wikimedia.org is failing over IPv6 from the the range 2a02:3d8::/32

the routing is broken upstream of our primary IPv6 provider between tele2.net and wikimedia so it may also be affecting other ip6 address ranges

$ tracepath6 bits.wikimedia.org
 1?:                         0.017ms pmtu 1500
 1:  gw6.mayo.lan                                          0.178ms 
 1:  gw6.mayo.lan                                          0.146ms 
 2:  2a02:3d8:1:ffff::1:1                                  0.757ms 
 3:  brendan1-brendan2.westnet.ie                          0.983ms 
 4:  isl-kw-brendan1.westnet.ie                            1.766ms 
 5:  2a02:3d8:ffff:104::1                                  2.549ms 
 6:  ktm12-kw.westnet.ie                                   4.917ms 
 7:  piglet-eth2v3006.westnet.ie                           5.308ms 
 8:  mole-ge2.westnet.ie                                  12.328ms 
 9:  2001:978:2:60::3:1                                   11.503ms 
10:  te3-7.ccr01.dub01.atlas.cogentco.com                 27.049ms asymm 17 
11:  te1-4.ccr01.man01.atlas.cogentco.com                 26.786ms asymm 17 
12:  te1-6.ccr02.lhr01.atlas.cogentco.com                 26.927ms asymm 17 
13:  2001:978::112                                        27.599ms asymm 17 
14:  peer-as174.cbv.tele2.net                             27.216ms 
15:  cbv-core-2.gigabiteth4-4.tele2.net                   29.172ms 
16:  cbv-core-3.tengige0-0-0-0.tele2.net                  35.459ms !N
     Resume: pmtu 1500

— Preceding unsigned comment added by 2A01:7B8:2000:A6:0:0:0:10 (talk) 13:49, 14 October 2012 (UTC)

I forwarded your message to the wikitech-l mailing list. — Edokter (talk) — 16:19, 14 October 2012 (UTC)

Your range doesn't look very healthy at RIS. Are you sure your transit providers are accepting it etc? Multichill (talk) 17:08, 14 October 2012 (UTC)

Are there any setting to let template show specific content after specific time?

Do someone study it before? Asiaworldcity (talk) 17:59, 14 October 2012 (UTC)

Have a look at #time parser functions. — Edokter (talk) — 18:34, 14 October 2012 (UTC)

{{Show by date}} does it for a date. PrimeHunter (talk) 18:59, 14 October 2012 (UTC)

I mean, such as after I put a template 70 days on the page then show specific content automatically. Is it use #time +70 days to input at {{Show by date}}? Asiaworldcity (talk) 19:18, 14 October 2012 (UTC)

{{#time:format|+70 days}} will give you the date 70 days from the current date – i.e. always in the future. To get the date 70 days from when you add the text, you must substitute it – e.g. {{subst:#time:format|+70 days}}.

Also, {{Show by date}} takes the date as separate year, month and day parameters, so need to use #time three times. Like this: {{Show by date|{{subst:#time:Y|+70 days}}|{{subst:#time:m|+70 days}}|{{subst:#time:d|+70 days}}|before text|after text}}. – PartTimeGnome (talk | contribs) 20:39, 14 October 2012 (UTC)

Thankyou very much! Asiaworldcity (talk) 11:41, 15 October 2012 (UTC)

Redirected page not redirecting

So if I go to Dispensing Assistant I see the content of the page; however, another editor redirected it to Optometry. I've purged the page using ?action=purge and nothing happened. If I go to edit the page, it shows a redirect. If I look at the page source, it shows that the page is in the mediawiki class of redirect, but it still shows content. What's going on? Ryan Vesey 18:49, 14 October 2012 (UTC)

It redirects properly for me. It sounds like your browser is giving you a cached version of the page with the URL ending "/Dispensing_Assistant". You could try bypassing your browser cache on that page. ctzmsc3|talk 19:38, 14 October 2012 (UTC)

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)  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)

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 Misplaced Pages:Lists of popular pages by WikiProject. Bgwhite (talk) 23:39, 14 October 2012 (UTC)

I log all Misplaced Pages 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)

Vector script stops responding in Firefox 15-16

I've been getting messages like this one for the last few months:

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete. Script: http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20121009T222616Z:11

It doesn't seem to affect anything as I can edit that page(s) without any problem, but it's annoying because the message overrides my currently selected tab and takes me to that one. Has anyone else had this problem or seen anything else like it?

Currently Firefox 16.01, Mac OS 10.6.8.--Sturmvogel 66 (talk) 02:11, 15 October 2012 (UTC)

Do you have any gadgets enabled? If so, which ones? PleaseStand (talk) 06:42, 15 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 Misplaced Pages, it also watches it on Commons or vice versa? --Philosopher  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  07:30, 16 October 2012 (UTC)

Help request

I know this sounds odd, but I really need developers for WP:AFCH. It's a huge script but only has two active developers, one of which is on indefinite wikibreak. If anybody is JavaScript inclined and want to give me and hand, I can use all the help I can get. Thanks, Nathan2055 17:04, 15 October 2012 (UTC)

Weird rendering

Anyone know why the article Minister of Justice (Sweden) is rendering a list of colour codes, and how to get rid of them? Ezeu (talk) 22:36, 15 October 2012 (UTC)

It can be fixed by encoding # in the used templates as in . I will fix the rest of the templates. PrimeHunter (talk) 22:52, 15 October 2012 (UTC)

Done. PrimeHunter (talk) 23:01, 15 October 2012 (UTC)

Thank you. Ezeu (talk) 23:08, 15 October 2012 (UTC)

Help needed - Misplaced Pages AutoEd

This discussion started at the Help desk. It was briefly at the VPT talk page. I've copied it here to get more attention. – PartTimeGnome (talk | contribs) 22:59, 15 October 2012 (UTC)

I have been using Misplaced Pages:AutoEd since June 28, accessing it from the link at the top of the article page and/or the edit page. Now neither are available. I wonder if this has anything to do with the recent changes to editing Misplaced Pages earlier this month. Can anyone advise? -- Gareth Griffith-Jones/GG-J's Talk 09:11, 13 October 2012 (UTC)

Try asking at WP:VPT.— Vchimpanzee · talk · contributions · 21:14, 15 October 2012 (UTC)

Okay. Thanks. -- Gareth Griffith-Jones/GG-J's Talk 21:23, 15 October 2012 (UTC)

You should try replacing the document.write(...) lines in User:Gareth Griffith-Jones/vector.js with just importScript('User:Kbh3rd/whackamole.js');. The lines in question contain a JavaScript syntax error, and AutoEd seems to work fine for me when I make that substitution. A syntax error anywhere in your user JS page prevents all scripts you have installed from working. PleaseStand (talk) 23:26, 15 October 2012 (UTC)

Glitched logs

Is anybody else having glitches with the pending changes log, as at here? I see:

• 16:36, 14 March 2011 Dabomb87 (talk | contribs | block) configured pending changes settings for <a href="/Jeff_Foxworthy" title="Jeff Foxworthy">Jeff Foxworthy</a> (Violations of the biographies of living persons policy) (hist)

Thanks! Reaper Eternal (talk) 00:01, 16 October 2012 (UTC)

I see that broken markup too, using Vector and Firefox 15.--Jasper Deng (talk) 00:25, 16 October 2012 (UTC)

(edit conflict) I see it as well with Firefox 16.0.1, using both Vector and Monobook. jcgoble3 (talk) 00:36, 16 October 2012 (UTC)

Where the log displays

<a href="/Jeff_Foxworthy" title="Jeff Foxworthy">Jeff Foxworthy</a>

the HTML source says

<a href="/Jeff_Foxworthy" title="Jeff Foxworthy">Jeff Foxworthy</a>

Something was encoded where it shouldn't have been. PrimeHunter (talk) 00:35, 16 October 2012 (UTC)

The change that broke the log view is gerrit:24420; in particular, the new wfMessage() function automatically HTML escapes the second argument, in contrast to the deprecated wfMsgHtml() function it replaced. (In line 21 of frontend/FlaggedRevsLogView.php, wfMsgHtml( "stable-logentry-{$action}", $titleLink ) became the incorrect wfMessage( "stable-logentry-{$action}", $titleLink )->escaped().) The fix is, of course, simple and obvious, and therefore, it should happen soon, as everyone who reviewed the change should have gotten an email about MaxSem's comment. By the way, one reason the developers introduced the new functions and deprecated the old ones is for security – would you really want vandals to be able to insert malicious JavaScript into Misplaced Pages because of a comparable oversight? PleaseStand (talk) 00:59, 16 October 2012 (UTC)

This seems to have been fixed in gerrit:27846. The patch apparently is still awaiting deployment to Wikimedia sites. PleaseStand (talk) 01:37, 16 October 2012 (UTC)

Article title

A few days ago, all article titles (at the top of the page) disappeared from Misplaced Pages - 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 . 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)

New template: need to change either / or 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 / 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; / comes from Common.js and / 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:

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)

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 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. Misplaced Pages 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)

VPT watchlist section links not working

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://en.wikipedia.org/Wikipedia:Village_pump_%28technical%29#Top_10.2C000_articles, but below correct for the following sections starting with http://en.wikipedia.org/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)

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 Misplaced Pages, 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 Misplaced Pages's autocomplete was querying Google search instead of Misplaced Pages'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. 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. 23:32, 16 October 2012 (UTC)

Next time this happens, try purging the page. Graham87 07:02, 17 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 Misplaced Pages: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: . 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 Misplaced Pages, 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)

• Note that the template that Wikid77 is promoting is contentious, and almost certainly broken. Don't use it... AndyTheGrump (talk) 19:29, 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)

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.--JohnBlackburne_deeds 14:27, 18 October 2012 (UTC)

Small new feature coming on Thursday

TL;DR: this is to announce a small new addition to the editing experience, based on previous testing.

What it is, and when it's going live:

This is a confirmation message that will tell all editors, anonymous or registered, that "Your edit was saved". It only appears for two seconds and then fades out, and is also dismissable via close button.

It looks like the screenshot to the right, and will work in most skins and browsers. Since it is supposed to consistently tell editors that their contribution was saved, it will appear on all edits, except page creations (since the message refers to an edit, which could be confusing use of the term when referring to page creation).

We're going to deploy this on Thursday, pending any last minute bug fixes, and it should go live shortly after.

Why we're launching it:

Confirming to someone that the contribution they just made was successful is a very common usability enhancement. It is used by most major Google products (Gmail, Maps, YouTube, etc.), Twitter, and innumerable other sites, like Dropbox. It is not used by sites like Facebook or Google Docs, where contributing is visually obvious 100% of the time, though clearly that's not the case when editing Misplaced Pages.

As part of editor engagement experiments, we tested this change with several thousand new registered editors, and comparing them to a control group, we found a significant increase in the volume of their edits — 23% in the short term — without an associated increase in how often they were reverted or deleted. (There's more about the results in our recent blog post.)

This data backs up the experience you see if you teach someone to edit. I've personally heard first time editors ask things like, "So what happens now?" and "When does it go live?" after saving. This message answers that question.

Please give it a try:

I realize that this may seem unnecessary for everyone is a very active editor already, and has thus learned that a successful save just means the page reloads in read mode. But since we've designed this feature to have as minimal an impact as possible, and because it has made a very measurable difference for people who are less experienced, I am asking everyone to give it a try for a week or two before making a final judgement about it. It's pretty easy to have a small, fast notification like this disappear from your attention after going about normal editing for a bit.

We've not immediately added a preference or gadget to remove this, for three reasons:

1. No other website allows you to permanently disable small notifications that confirm a contribution. This includes existing Misplaced Pages notifications like the watch/unwatch bubble message. They only exist on screen for a few seconds, and are dismissable in case they obscure any content. We're not making this dissappear after something like 100 edits, because once you start to expect it, not seeing it might look like the system sis broken. For new people especially, who will be expecting to see this from their first edit on, consistency is extremely important.
2. The preferences tabs are totally bloated with checkboxes for single features, and there is already discussion about how to remove cruft. If in a while, the feature continues to be extremely distracting, then we can talk about adding a preference to opt out.
3. Personal CSS or JS can't hide this, because of the speed at which it appears and the order in which personal styles are loaded compared to the rest of the site. Update: It looks like we missed this, because the test environment we use didn't have personal styles enabled. Thanks to Yair rand below, the following CSS might work to hide the feature...

#postedit-container {
   display: none;
}

Thanks for reading all that, and of course please speak if you have questions/comments. Steven Walling (WMF) • talk 09:55, 17 October 2012 (UTC)

Good feature! I'm the sort of experienced user who will not benefit, but I'm glad that the inexperienced user is being considered. Binksternet (talk) 19:46, 17 October 2012 (UTC)

I second that. This will (probably) not bother me too much (I'll just have to remember that the box fades out in a few seconds), and I think it's going to be a very effective feature to tell first-time/new editors in a quick and clear way that they have actually edited a page. I know how lots of people wonder: so did it save my changes or not? Jsayre64 (talk) 22:48, 17 October 2012 (UTC)

Please give it a try: Interesting wording. Unless I'm misunderstanding something, since we can't turn it off, if we still want to edit we will be forced to try it. So why say please? I'm not saying the "feature" is bad, I'm just saying you probably could have chose better wording.--Rockfang (talk) 20:12, 17 October 2012 (UTC)

I used that language in the context of Jimbo's request at Wikimania in 2011 to give the WMF some more room to deploy things, give them a try, and then give us feedback. The assumption is that this will be permanent because we previously tested it, but that definitely doesn't mean we're not open to feedback and changes in the future, including an opt-out. I just didn't want to start the conversation with an assumption that we don't want to ever change things for existing community members, and instead want to request an open mind about it. I realize that's not as simple as it sounds, but I watch VPT and other forums pretty closely, so we're not just going to dump new software on the site and run. Steven Walling (WMF) • talk 20:54, 17 October 2012 (UTC)

"...so we're not just going to dump new software on the site and run". From my observations, from big projects to small things, decisions made top-down by WMF fiat seem to be get implemented, "discussed" for a while until opposing users lose interest, and then forgotten about. Jason Quinn (talk) 00:17, 18 October 2012 (UTC)

• Question Will there be a way to turn it off? I don't want this kind of confirmation. I am not saying it is a bad idea, but I prefer to have it the way it is right now. Also I am sure if I wouldn't ask, someone else will do later. -- Toshio Yamaguchi (tlk−ctb) 20:18, 17 October 2012 (UTC)

  Question seconded. It really needs a "disable permanently" option. Deryck C. 20:30, 17 October 2012 (UTC)

  See the section above about a preference to disable. Steven Walling (WMF) • talk 20:38, 17 October 2012 (UTC)

• Another question: is it deployed on Vector only? Deryck C. 20:30, 17 October 2012 (UTC)
  • No, not Vector only. I've tested in on Monobook and older skins except Classic. It works with those skins, and is smart enough to scale to the correct text size, etc. I'm not opposed to suppressing it for older, non-Vector skins if people want to propose it or submit a patch though. Steven Walling (WMF) • talk 20:38, 17 October 2012 (UTC)
• "Personal CSS or JS can't hide this, because of the speed at which it appears and the order in which personal styles are loaded compared to the rest of the site." What? User CSS is loaded before the visible content even starts. I doubt that the box is going to be done with entirely inline styles, so there must be a class or id attached to it, so users will be able to do a simple display:none; to hide it easily. --Yair rand (talk) 21:00, 17 October 2012 (UTC)
  • My understanding is that because the feature is presented dynamically with JavaScript, you can't use personal CSS to hide it, regardless of the speed issue. Yair, you're a developer right? I can show you the Labs instance where we're testing this. We tried to think of a userscript or style that wasn't an extremely nasty hack, but were unable to find one. Steven Walling (WMF) • talk 21:14, 17 October 2012 (UTC)

    Being presented dynamically with javascript doesn't at all stop elements from being hidden by user CSS. (Am I a "developer"? I thought that generally referred to WMF employees, which I am not. I just fiddle with JS and CSS here and on Wiktionary...) A link to a Labs instance where I could test it would be great, thanks. --Yair rand (talk) 22:47, 17 October 2012 (UTC)

    CSS code is #postedit-container{display:none;}. Works fine. --Yair rand (talk) 22:55, 17 October 2012 (UTC)

    Hmm. Doesn't seem to work for me on Labs, when applied to my Vector or Common CSS. Steven Walling (WMF) • talk 23:08, 17 October 2012 (UTC)

    MediaWiki has $wgAllowUserJs by default set to false. —TheDJ (talk • contribs) 07:59, 18 October 2012 (UTC)

    • AdBlock Plus is your friend. They (talk) 22:12, 17 October 2012 (UTC)
    • en.wikipedia.org##DIV#postedit-container They (talk) 23:28, 17 October 2012 (UTC)
• Interesting. I suppose all questions will be answered in a few hours when it goes live. SilkTork 21:36, 17 October 2012 (UTC)

• Alternative suggestion - This required the reloading of the page twice, which is impractical. All the sites you mentioned also make use of AJAX and javascript functions to display temporary messages on loaded pages. A bar that appears then disappears is much more practical to a whole page. - Floydian  _¢ 21:46, 17 October 2012 (UTC)
  • Where did you test it? This does not require users to reload the page, and does in fact use JavaScript to display it as a temporary message for a couple seconds. As for adding the notification after complete page load... I'm not sure that's less annoying than having the message appear along with page reload post-edit. Steven Walling (WMF) • talk 22:02, 17 October 2012 (UTC)
    • My bad, I completely misread the image :S - Floydian  _¢ 23:47, 17 October 2012 (UTC)
      • No worries. Steven Walling (WMF) • talk 23:52, 17 October 2012 (UTC)

• Question – What time (exactly?) are you going to release this change? It's already Thursday in UTC and in my time zone. –– Anonymouse321 (talk • contribs) 05:06, 18 October 2012 (UTC)
  • Sorry, I mean Thursday afternoon PST. There is no exact predetermined time, because deployment is a process that's not immediate. Steven Walling (WMF) • talk 06:45, 18 October 2012 (UTC)

• What is the effect, if any, on high-speed editing like bots or (in my case) AWB edits? Does it in any way slow down or obstruct such editing? Fram (talk) 07:57, 18 October 2012 (UTC)
  • None, if the edits are made via the API like I assume AWB and most bots do. If there is a bot or other tool that makes an edit in a semi-automated fashion but doesn't use the API, it's possible but unlikely. This a very small feature, and we've already put some performance hacks in place to make it snappy, so we don't anticipate problems. Steven Walling (WMF) • talk 08:07, 18 October 2012 (UTC)
    • Thanks. Fram (talk) 08:13, 18 October 2012 (UTC)

• nagware I kind of like keeping browser scripting turned on, on sites like this, where presumably the scripting is non-harmful (actually, it's not, every year or so I have to create a new browser profile to fix various "bugs" that seem to come from "somewhere"). While I can't think of the[REDACTED] name offhand, the editor which color codes the editing window separating text from code is kind of nice to use, but I guess I can turn it off, it just is slightly more tiring to use, and takes a little longer to make edits. That's the side effect of stopping these popups. Maybe someday the foundation will decide that encyclopedia content shouldn't be visible unless scripting is turned on, like some sites do now. It's almost humorous, follow a link to read something and find a Blank Page unless scripting is allowed. Can't serve a page until ID is shown. Show us your papers! Gzuufy (talk) 15:28, 18 October 2012 (UTC)
  • "Maybe someday the foundation will decide that encyclopedia content shouldn't be visible unless scripting is turned on, like some sites do now." Doubtful. Unlike some participatory sites, many of which require login and other stupid requirements to just read content, job number one for us is to give away the encyclopedia to as many people as possible. For readers, we are actually are moving in the opposite route of what you describe, enabling features such as optionally disabling images on the mobile site to speed up page load times for those on slow connections. Reading != editing when it comes to browser requirements. Steven Walling (WMF) • talk 17:48, 18 October 2012 (UTC)

Thanks Steven. Gzuufy (talk) 19:27, 18 October 2012 (UTC)

So, if I have Javascript disabled in my browser, can I still edit? And will I see this message? InedibleHulk (talk) 19:13, 18 October 2012 (UTC)

InedibleHulk, I just submitted this message with scripting off. I don't know if it is limited to disabling only javascript, I'm using Noscript. The editor appears slightly different. It opens quicker, probably due to the limited speed of my connection. I haven't seen those messages yet, once they appear, we'll know what, if anything, works to block them. Gzuufy (talk) 19:27, 18 October 2012 (UTC)

Yes, you can edit without JS. And no, you won't see this message if you have JS disabled. Steven Walling (WMF) • talk 19:40, 18 October 2012 (UTC)

Cool, thanks. No objections here, then. InedibleHulk (talk) 20:09, 18 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)

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. " 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)

• "I am a highly experienced computer scientist, and I have never written a "buggy" anything". Famous last words... AndyTheGrump (talk) 05:04, 18 October 2012 (UTC)

• I'm a highly experienced computer programmer, and I've written buggy things loads of times! That's what test suites are for. — Hex (❝?!❞) 07:43, 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 ×10 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 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 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 Misplaced Pages:Featured picture candidates, but this will not be possible without these technical issues being fixed first. See also: http://commons.wikimedia.org/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)  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)

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-}}: Template:Sclass- (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)

• Misplaced Pages noticeboards
• Misplaced Pages features
• Pages automatically checked for accidental language links