Misplaced Pages

This is an old revision of this page, as edited by Nathan2055 (talk | contribs) at 17:04, 15 October 2012 (→Help request: new section). 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

• Prohibiting the creation of new "T:" pseudo-namespace redirects
• 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)

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)

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)

Changes to the Vector buttons

Hey all

So, as you see discussed above, we've made some changes to the edit window. I'm happy to report that the edit tools will be returning on Thursday (touch wood). We've also got some changes we'd like to make to the "save page" , which we want to run by everyone. It's worth noting that these would exclusively apply to Vector, and can be seen in the mockup on the right. We'll have a prototype to kick around in a bit, but we wanted to get feedback before coding rather than after.

Our rationale is basically this: the current interface doesn't do much to indicate to users what buttons are important or unimportant. Save page, show preview...they're all displayed in the same way, when in fact some are more important than others. We'd like to make this a bit more intuitive and provide some focus and direction by using colour as an indicator. There's research that supports the idea that this is pretty helpful. We've chosen blue because it's wikipedia's "action" colour: links are blue, the 'edit' button is blue, it seems only appropriate that these be blue as well. We will NOT be introducing any color for Show Preview/ Show Changes. We will increase the height because the labels are too small.

At the same time, in line with suggestions by some editors, we've moved the edit summary guide text (Briefly describe the changes you have made) into the edit summary box itself, when that's supported by browsers. This will save space while not actually losing any information.

Questions, ideas, comments? The earlier you give feedback, the sooner we can look at implementing changes to it :). Okeyes (WMF) (talk) 20:58, 2 October 2012 (UTC)

Add a temporary notice to MediaWiki:Wikimedia-copyrightwarning with a link to explain the changes and the dates so that editors understand what is happening. Now I have to figure out how to do button colors to update {{EditOptions}}. ---— Gadget850 (Ed)  21:22, 2 October 2012 (UTC)

Personally, I don't think it is a change that is needed. Aesthetically speaking, it is much worse. Functionality wise, the blue doesn't tell me more importance. I just showed my wife, who doesn't edit Misplaced Pages, the three buttons from a few feet away. She thought the darker "Show Preview" looked to be more important and I think the same way. Having them different colours seems to be a solution looking for a problem. The background of the buttons is the same colour of the rest of the background... having the button background be slightly darker would make them stand out better. Bgwhite (talk) 21:34, 2 October 2012 (UTC)

Personally, the grey button looks 'disabled' to me. But if we want to change Vector button, I have a personal design in use:

(CSS here.) — Edokter (talk) — 21:53, 2 October 2012 (UTC)

Agree with you that the Grey looks disabled. That is a valid piece of feedback.
So the only change would be the Save Button which is consistent with the link colors used today and with the Agora color Pallette.Vibhabamba (talk) 22:21, 2 October 2012 (UTC)

I like this look, better ;) Gonna make em a bit smaller, though.

div.editButtons input
{
 padding: 8px 15px;
 font-weight: bold;
 line-height: 1;
 color: #444;
 border: none;
 background-color: #fff;
 -webkit-border-radius: 23px;
 -moz-border-radius: 23px;
 border-radius: 23px;
 text-shadow: 0 1px 1px rgba(255,255,255,.85);
 background-image: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#fff), to(#bbb));
 background-image: -moz-linear-gradient(0% 100% 90deg, #bbb, #fff);
 -webkit-box-shadow: 0 1px 2px rgba(0,0,0,.5);
 -moz-box-shadow: 0 1px 2px rgba(0,0,0,.5);
 box-shadow: 0 1px 2px rgba(0,0,0,.5);
}

needs the other states, of course… Br'er Rabbit (talk) 21:52, 2 October 2012 (UTC)

Oh please don't do that. my that's ugly. —TheDJ (talk • contribs) 18:45, 3 October 2012 (UTC)

I'm not sure that the colour of the buttons makes much difference. What I would like to see in another colour, or format, is the text at the top of an editing page: "Content that violates any copyrights will be deleted. Encyclopedic content must be verifiable. Work submitted to Misplaced Pages can be edited, used and redistributed by other people at will." It would be better if this was more conspicuously different from the text of the article: perhaps boxed or on a coloured background? PamD 22:21, 2 October 2012 (UTC)

Can you go into why you'd want different style more? Is it for more emphasis (to make it "jump out"), or is it just to make sure that it is visually apparent that it is different than the other text on the page? Either reason is valid, I just think clarifying why might help make a design decision. The only potential conflict with using a box with background or border is that it would be in addition to any editnotice templates on a page (such as MediaWiki:Anoneditwarning). Steven Walling (WMF) • talk 22:58, 2 October 2012 (UTC)

Arbitrary break, and two things:

1. Oliver, you're on holiday. Go away.
2. The buttons should really match the other buttons - unfortunately since none of the other ones match each other anywhere, I have absolutely no idea if they do or not in that example. But really, all the buttons in vector should be using the same style, including in preferences, various forms, etc, and the ones AFT5 uses look nice in vector... which probably means that isn't the right style, doesn't it? Damn. -— Isarra ༆ 22:31, 2 October 2012 (UTC)

   (edit conflict) Er, not AFT5, the new pages feed... the former uses Agora, as Vibha said this is supposed to be above, and which they should all be using, but the latter uses something else that actually matches the skin and doesn't result in all the secondary buttons appearing disabled. But while I just don't like Agora's current appearance, a random mish-mash of styles is even worse. -— Isarra ༆ 22:58, 2 October 2012 (UTC)

   Having all buttons be the same size and style would only make sense in a world where all buttons are equally important. They're not. Different buttons have different functions and relevance to users, which is why styling like this is used all across the modern web. Steven Walling (WMF) • talk 22:52, 2 October 2012 (UTC)

   They can be consistently styled with interfaces on the rest of the wiki with individual buttons having emphasis. That was my point, not anything about the individual ones here. -— Isarra ༆ 22:58, 2 October 2012 (UTC)

   You're right that we need consistency across the encyclopedia, that why we have to start with a few limited places. Reality is we dont have the developer resources to change a lot of different areas at the same time. This one is critical since its a first touchpoint for new editors. Vibhabamba (talk) 23:02, 2 October 2012 (UTC)

   Yes, 100% internally consistency is good, but not always possible or even a reality in Vector at the moment. The point of incremental changes such as this is to gradually move to a new style without trying to redesign the entire site all at once. Making the argument that no change should be made in order to comply with an old style that is less functional doesn't make much sense. Steven Walling (WMF) • talk 23:08, 2 October 2012 (UTC)

   Please don't put words in my fingers, Steven Walling. This proposal is to style the editform buttons - while already styled buttons are out of plausible scope, is there any reason this cannot extend to all input buttons currently defaulting to system style, as these do? Same change, different selectors. -— Isarra ༆ 23:33, 2 October 2012 (UTC)

Er, nevermind about the whole agora/not agora thing; I got a little confused, as apparently AFT5 and NPF are both agora, as is this. This variant looks fairly good, though the secondary buttons should probably not be an average colour so similar to the background. -— Isarra ༆ 00:20, 3 October 2012 (UTC)

The other two buttons will stay as is, exactly the way are they styled right now although they will increase by a few pixels in height. Ignore anything other than the Save Button. Thanks! Vibhabamba (talk) 00:36, 3 October 2012 (UTC)

That will not work - the way they are currently styled is not at all, which means they are defaulting to the system theme of the window manager or operating system of the user. As different window managers and operating systems can have very different themes (compare various ubuntu themes with the style used by OSX, for example), specifically styling (changing) only one button will just result in a complete mismatch of button styles on many systems. -— Isarra ༆ 03:14, 3 October 2012 (UTC)

Good Point. Lets see what it looks like once we have it prototyped. I will try and get a live screenshot on this page. We may not be able to accommodate styling of everything for this iteration. Vibhabamba (talk) 03:45, 3 October 2012 (UTC)

Remember aqua buttons in pre Mac OS X Lion ? That's why you can't style just one button. Either style nothing and let defaults take care, or style everything. —TheDJ (talk • contribs) 18:45, 3 October 2012 (UTC)

• Comment: Frankly, I'd rather see the buttons rearranged. For readers of English, and I would guess, other left-to-right, top-to-bottom languages, the eye wants to start at upper left and progress to lower right. These buttons should follow that convention. It has always bothered me that they don't. Buttons gain importance relative to their position with regard to the other buttons. Save page is most important so position it rightmost. Show changes is the least important so position it leftmost.

By using a positional hierarchy that doesn't conflict with user expectation, other mechanisms that indicate relative importance are unnecessary. In the buttons on this editor page that I'm using, the Save page button uses a bold font to identify it as the most important button. Were they flipped around and positioned on the right, then that bold font would not be necessary nor would the blue color. Blue as a color for the most important button doesn't relate to any real world indicators of importance that I can think of – red and green? yes, blue? no.

Of course for readers of right-to-left languages the position of the buttons is correct. Don't break the editor page for them.

–Trappist the monk (talk) 00:43, 3 October 2012 (UTC)

No, emphasising the save would be necessary either way - nevermind what seems logical, what people are used to will still play a huge part into where they expect the button to be. So for instance anyone used to using windows, facebook, or google will probably expect the main button to be on the left just because that is what those do.

That said, I agree it is backwards and strange, but to put the save on the right the entire row of buttons would probably need to be aligned with the right side of the textarea for it to really make sense, and the way the rest of the stuff in the area is currently laid out, that would just look weird. Would need some major rearranging to work well, but it would be doable. -— Isarra ༆ 03:14, 3 October 2012 (UTC)

+1 Isarra. Color Coding is absolutely essential and is a rule of thumb in any visual design exercise.

Blue is an action for continuity on many community driven sites and is widely employed for information design. The sites you cited (Windows, Google, Facebook), they all use color coded call to actions along with icons. We are pretty sparse on iconography. References: http://www.paulolyslager.com/call-to-action-buttons-psychology-color/ Eliminating color is not an option, we need clues other than color for accessibility concerns.

Hope that helps. 67.164.99.159 (talk) 03:32, 3 October 2012 (UTC) Vibhabamba (talk) 03:35, 3 October 2012 (UTC)

I made another mockup of a possibility of how it could look including using right-oriented buttons with styles I found in Commons' css. Not all of the mockup would apply here, but regardless I don't think the general gist would go over too well, even if only because button position is just hard to get used to. -— Isarra ༆ 21:09, 3 October 2012 (UTC)

That's one huge mouse move between "This is a minor edit" and "Save page". --Redrose64 (talk) 21:45, 3 October 2012 (UTC)

A very good point - may even be a primary blocker for ever doing this sort of thing... -— Isarra ༆ 06:29, 4 October 2012 (UTC)

Some legal issues with this: We cant disconnect Save from the legal copy. Thanks for taking a crack at this, its going to be slow and incremental. What are you thoughts on making this area persistent? So it never scrolls below the fold? Vibhabamba (talk) 00:08, 4 October 2012 (UTC)

Which area, and what do you mean by persistent? -— Isarra ༆ 04:06, 4 October 2012 (UTC)

The Entire Box Field Carrying the Edit Summary, Terms of Service and Slew of actions > Save, Preview, Changes, Cancel. 67.164.99.159 (talk) 06:58, 4 October 2012 (UTC)

What do you mean by 'persistent'? -— Isarra ༆ 16:39, 4 October 2012 (UTC)

And why do you say there would be legal issues with this? How is it a disconnect between those elements any more than the current has? -— Isarra ༆ 06:29, 4 October 2012 (UTC)

Well Because the Legal copy and the Save action are in different quadrants on the Page. Editors could easily say that they didnt read the TOS before hitting Save which has massive legal implications for us. This is a very different mental model than users are used to right now. Changing the order of the actions is also not trivial. We could get severe community lashback for that.

67.164.99.159 (talk) 06:58, 4 October 2012 (UTC)

The comment on Legal copy + Save action was added by Vibhabamba (talk) 08:07, 4 October 2012 (UTC)

The copyright warning is right above the buttons in this same as has been in mw1.20 (the buttons in the wikiEditor toolbar would at most be a gadget, unless someone wants to yoink the entire VE save dialog and add it to wikiEditor), although editors could just as easily say they're not reading the thing now, either, but they're still agreeing to it regardless by saving. And yes, that folks probably wouldn't take kindly the reverse of button order was kind of my point here. They might accept it, if given time to discuss and come to terms with it, but that would be quite the undertaking were any somewhat representative portion of users to be involved and certainly out of the scope of anything we could do. -— Isarra ༆ 16:39, 4 October 2012 (UTC)

These comments apply to Editor Isarra's mockup and the concerns about legal issues arising from the legal notice being too far away from the save page button.

1. leave the Save page button where it is
2. move Show preview and Show changes up and to the right so that Show preview is directly above Save page
3. move the legal text down and right so that it is adjacent to the Save page button
4. enclose both the legal text and the Save page button within their own box – perhaps a thin line or a change in background color around the text and the button to clearly show that they are connected
5. delete the Cancel button – it serves no purpose (as I've ranted on before)
6. move the Minor edit and Watch checkboxes right so they are near the Show changes and Show preview buttons
7. delete Editing help link – it should be a button on the toolbar (all toolbars) (Editor Isarra has pointed out that the Help link has been removed from his mockup)

Left-to-right and top-to-bottom hierarchy leads the editor through the process. Save page button and the legal text clearly associated with each other. Requires no more room than is required now. Special colors not required.

—Trappist the monk (talk) 13:15, 4 October 2012 (UTC)

Thank you for your input, however breaking things up in the manner you suggest would unfortunately detriment the flow of the page even more. -— Isarra ༆ 16:39, 4 October 2012 (UTC)

Oh isn't is wonderful to be dismissed out-of-hand by our betters? I have said nothing to you that deserves a reply like that. Do me the courtesy of a reply that shows how what I have suggested is detrimental to page flow.

—Trappist the monk (talk) 17:11, 4 October 2012 (UTC)

My apologies - it would seem that by trying to avoid insulting you I wound up insulting you in the process, but unfortunately the changes you suggest just don't make a whole lot of sense. I'm not entirely sure which version they are based on, for instance, since you refer to things that shouldn't appear together in any of them (such as the editing help and the cancel button), so saying to leave the 'save page' where it is is ambiguous at best. The relative positioning of all the pieces also seems a bit odd... but here. I've done my best to make a mockup based on what you describe - is that at all what you meant? -— Isarra ༆ 04:40, 5 October 2012 (UTC)

Brilliant! That is exactly what I meant. The only really obvious change I would make to your mockup is to remove the line break ahead of "You agree that a hyperlink ..."

This mockup is the one to which I referred. I'm not clear about what you mean when you say that I "refer to things that shouldn't appear together in any of them (such as the editing help and the cancel button), so saying to leave the 'save page' where it is is ambiguous at best." Clarify?

Does this button layout still seem detrimental to page flow?

With the minor change that I noted above, I think that you should publish your mockup as an image rather than a link so that others can see it. I fear that left as a link, others who read this part of the discussion will presume that we are having an argument and ignore whatever else is said.

Thank you.

—Trappist the monk (talk) 13:07, 5 October 2012 (UTC)

The linebreak is in the system message and would need removing there, there hasn't been a help link since before the first batch of changes, and putting the buttons all in the corner like that makes it harder to get to any of them, makes it easier to misclick, and deemphasises the relevance of the lot while also resulting in an awkward piece of white space where one would expect there to be stuff. And I have now added the image as a thumb. -— Isarra ༆ 08:17, 6 October 2012 (UTC)

I agree with removing the line break ahead of "You agree that a hyperlink ...". Turning those two sentences into a paragraph will improve the use of screen space. Nurg (talk) 09:45, 6 October 2012 (UTC)

See here for why the sentences were broken up in the first place. -— Isarra ༆ 02:45, 7 October 2012 (UTC)

Ah, you're right about the help link; not sure now where I got that so I've struck it from my list.

If misclicking is an issue, is it not also an issue with the Edit summary link above the summary text field and the minor edit link in the minor edit check-box label? I know that I've misclicked the minor edit link often enough but rarely get the Edit summary link. Of course if I just remembered to use the tab key more often that wouldn't be a problem.

Yeah, that blank space is blank. But is it really awkward space? Blank space isn't necessarily a bad thing. The eye is attracted to things, so the blank space enforces the eye's tendency to move to the minor edit and watch check-boxes. I suppose that we could move the summary text field label into that space, or move the minor edit and watch check-boxes back to the left side, or use the space to remind editors that the Tab ↹ and ⇧ Shift+Tab ↹ cycle to the next or previous input field, or leave it blank.

How does the layout "deemphasise the relevance of the lot"? I'm not sure what you mean by that.

—Trappist the monk (talk) 13:22, 6 October 2012 (UTC)

Mon, please, I have said what I could; I have neither the time nor the energy nor the neuroscience background to go into the details of the whys of the whys. -— Isarra ༆ 02:45, 7 October 2012 (UTC)

I am disappointed and confused. Neither the time nor the energy yet you devoted time and energy to create an accurate mockup of my suggested layout. It isn't clear to me that anyone needs a neuroscience background to expand upon or clarify for others their own fully-formed thoughts and opinions. Sigh.

—Trappist the monk (talk) 14:23, 7 October 2012 (UTC)

• Another comment - now that I've had a chance to sit down and read the thing in full, I have a couple more questions.
  1. "We will increase the height because the labels are too small." - Too small for what? They're not any bigger in the mockup, either.

     The height of the button is 17px and the labels "Save/ Preview/ Show changes" in the current type size make small target areas. The buttons need to go up in height by a few pixels and the type size needs to go up by a notch just to match type size on the rest of the page. The mocks are not an exact representation. Vibhabamba (talk) 17:29, 3 October 2012 (UTC)

     The specific height is relative to the system scheme, but indeed specifying something generally larger would make sense. -— Isarra ༆ 21:26, 3 October 2012 (UTC)

  2. In the previous thread, it was established that using a placeholder text for the edit summary field would only work when editing the entire page (not a section) for technical reasons. What are your plans to get around this?

     If an editor is editing a section, the section title will appear in the Edit Summary box. The reasoning is that if the editor knows that they can edit specific sections they dont need the basic guide test of what an edit summary is. Vibhabamba (talk) 17:29, 3 October 2012 (UTC)

     This might be a flawed argument. There have been indications in the past, that new users actually find it easier to find the edit section links, then the main "edit" tab at the top. I'm not saying it is so, but you probably want to check if the experience bias really is as much as you assume it to be, with this edit section links. —TheDJ (talk • contribs) 18:39, 3 October 2012 (UTC)

     Carrying guide text within the input fields is a pattern we are establishing. this will also be seen in the new signup experience. For the short term, the guide text will not appear if you edit a section. Vibhabamba (talk) 20:52, 3 October 2012 (UTC)

     html5 doesn't support that, and for good reason - even if you make a js version of the placeholder attribute, people still probably won't notice it at all since the field is already filled in to their eyes.
     And meantime many folks do indeed seem to catch on pretty quickly about section editing, judging from a lot of the test edits I've found myself having to revert. This is good, since editing most full pages at once would be kind of overwhelming. -— Isarra ༆ 21:23, 3 October 2012 (UTC)

  3. There are some other interesting styling changes in the mockup, namely to the edit summary field (including the placeholder text font size) and the grey area (both width and shadow); are these intended changes as well, either with this or future builds? -— Isarra ༆ 04:45, 3 October 2012 (UTC)

     Those are not intended changes in this iteration. Vibhabamba (talk) 17:29, 3 October 2012 (UTC)

• My original request, above, was:-

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

You have almost done the opposite - removing everything except the linked part of "Edit summary", and keeping that immediately above the Edit summary box, at the beginning of the line.

What we have done here is not solving or exacerbating the problem you mention. We are looking into a pattern where any type of label might carry a help hook or a whats this link next to it.

Also the reason you hit the label is because the edit field is not a proper target size, it is below the standard height of an input field. We will increase the height of the field by a pixel or two. Vibhabamba (talk) 20:52, 3 October 2012 (UTC)

• Request - can there be a way to ensure that, for a simple edit, the "save page" "show preview" "show changes" buttons will be on the screen, without scrolling down, whatever (reasonable) screen resolution is being used, and whatever messages appear at the top:- "Welcome to the Village pump for technical issues" like this page, BLP warning etc. as scrolling down is a nusance and new editors may be unaware of buttons off the screen, causing frustration. I've already had to cut the size of my editing window down to 12 rows with the current changes and this layout looks no shallower measured vertically from the toolbar to the buttons. - Arjayay (talk) 08:44, 3 October 2012 (UTC)

Arjayay, you bring up a very critical point. making the Edit Summary/ Save persistent is key in improving the UX for new editors. We havent quite considered it for this iteration. But Ill work with Okeyes to evaluate this for the next one. If the save area persists and never goes below the fold, we need to accommodate View Templates and View Hidden Categoires so they are easily discoverable. Those sections are used by a lot of editors. Any thinking or comments here would be useful. We will propose the behavior and gather feedback from the community. Thanks for raising. Vibhabamba (talk) 17:21, 3 October 2012 (UTC)

• Use of contrast, grey: The contrast between light-on-dark and dark-on-light buttons feels jarring. I'd feel more comfortable with say, charcoal grey "default" buttons (with white text) and blue for the "important" one(s), and that might also avoid the issue people have identified with grey buttons feeling "greyed out" and inactive. Grey buttons work well on a white background, where their inherent contrast helps mark them as active, but the edit-button area currently has a grey background: the lower contrast worsens the "greyed out" effect. {{Nihiltres|talk|edits|⚡}} 19:16, 3 October 2012 (UTC)

  Aye, better contrast is definitely needed. Using the appropriate button styles should help, but if not I′m sure the background can be adjusted accordingly. -— Isarra ༆ 06:29, 4 October 2012 (UTC)

  We're going to try increasing the shading in the other buttons to make more clear "this is a button". I'll let y'all know when we've got something to show you on the live prototype :). Okeyes (WMF) (talk) 14:24, 8 October 2012 (UTC)

  Are you not using the agora library? -— Isarra ༆ 15:11, 8 October 2012 (UTC)

• I like the color of the Save button, the other buttons might need some work though. One more thing with the placeholder. I'd argue that if it is in the textfield, it will not need the (). —TheDJ (talk • contribs) 07:32, 4 October 2012 (UTC)

  Good point; we're including it now :). Okeyes (WMF) (talk) 14:24, 8 October 2012 (UTC)

  • I absolutely the current layout, it's far less clunky and everything is easily accessible. The moving and inclusion of the note at the top is a great idea, although I'd go for a more direct cautionary note. Also, in the new interface: "This is a minor edit" has the last two words have been omitted leaving behind a somewhat meaningless string which might confuse some. Is it just something on my end or was it an error in the code? I also prefer the design in the mockup, the buttons as they are look out-of-place. Great work, though! :D James • 9:43am • 23:43, 4 October 2012 (UTC)
    • That shouldn't be happening (and isn't for me) but if you can email me a screenshot/OS/browser info I'll try and get it looked into :). Okeyes (WMF) (talk) 14:24, 8 October 2012 (UTC)
    • It's because you're setting display:none on #minoredit_helplink in User:M.O.X/vector.css. See MediaWiki talk:Minoredit#Hiding the link for details and new CSS to remove the link without leaving the checkbox label as "This is a". Anomie⚔ 16:27, 8 October 2012 (UTC)

Testing new account creation page

This is a heads up that we're going to be doing a trial of a new version of the account creation page, starting today.

How we're testing it

This is going to be run as an A/B test for a few weeks. That means trying to see it via creating test accounts is both a hit-and-miss strategy and could muck with the results. If you do so anyway, it would help us if you marked them with {{User alternative account}}, so we can find them.

For account creators: if you're already logged in and you visit Special:UserLogin, nothing should change. Account requests in general should be unaffected, since both interfaces still include the necessary link.

Why

Our accout creation page is pretty old, to be frank, and it's almost certainly one of the reasons why registrations have declined over the years. You might remember that back in summer 2011, that there was a past account creation improvement project, which conducted some tests of their own (that are now over).

The goal of that project was to increase the number of newly-registered people who made edits. While my team—editor engagement experiments—is also aimed at increasing the number of active editors, for this launch we're just focused on making the account creation page something that gets out of the way of new people. There are also some secondary goals, like making the design comply with other work from the design team, and making the interface much more usable on mobile browsers.

What happens after the test

After the test, we will use data such as how many people created an account and how many were blocked (especially for username policy violations) to get an idea of whether it was more or less successful at helping people register. There's more about how we're collecting and analyzing the data on Meta. If you're curious, there is more about our goals and fancier things we might do in the future in these docs, which you're welcome to comment on.

Thanks! Steven Walling (WMF) • talk 21:57, 4 October 2012 (UTC)

I love the new design. Great work. --Meno25 (talk) 08:29, 6 October 2012 (UTC)

Aye, it looks good. Should certainly be interesting to see the results of this, too, among other things comparing effectiveness of full descriptions to mere links... -— Isarra ༆ 08:39, 6 October 2012 (UTC)

It does look nice, yes, although if we were to keep it, could we have "(recommended)" instead of "(optional)" for email addresses -- we do get a lot of password reset cases we can't do much about with it. On a general point, Steven, you link to the previous tests: did these factor into your present trial at all? - Jarry1250  09:27, 6 October 2012 (UTC)

Loving it, but I support Jarry1250's comment with regard to 'recommended' —TheDJ (talk • contribs) 11:22, 6 October 2012 (UTC)

Yeah, when we thought about the language here, we realized that if we really think people should be providing an email address so they can recover their account, we should just think about making it required in the future. You can already turn off all ways to receive email from other editors or automated email. Obviously this would not be a spur of the moment decision though, since it would require an update to the privacy policy. Steven Walling (WMF) • talk 00:43, 7 October 2012 (UTC)

I always have difficulty with input boxes that have already populated "help" text in them. I think it is the wrong place to put such text. Firstly: because before I start typing I have to manually erase the text (without JS the text does not vanish when I select the box), and secondly: because once I manually erase the text there is no way to get it back again (without a full page reload) in case I forgot what it said. I think it could be improved if there is no text in the input boxes (keep them blank upon load) and instead the help text is placed either above, below, left or right of the box. HumphreyW (talk) 12:27, 6 October 2012 (UTC)

Good point - support for that varies; some browsers won't even show the text at all. And while this can be worked around with js, aside from the captcha they all seem mostly redundant anyway, so perhaps just moving the captcha explanation and the email '(optional)' or '(recommended)' (I'd prefer the latter as well) into the labels would be better? -— Isarra ༆ 20:43, 6 October 2012 (UTC)

Having tested it prior to launch, I can say that the number of browsers and users who won't see the text is relatively small. We're mostly talking IE6, maybe very old versions of Firefox or Opera, and some mobile browsers. In the majority of browsers that visitors to Misplaced Pages use, the text works just fine, and does not require manually erasing the text. What are you using Humphrey? Steven Walling (WMF) • talk 00:36, 7 October 2012 (UTC)

My comment was intended to be general since I don't know where your test page is to try it. My past experience with these boxes preloaded with text has always been frustration and annoyance. If you have done some sort of non-JS magic then I would like to test it. Do you have a link to a page where the test page is used? HumphreyW (talk) 01:39, 7 October 2012 (UTC)

The test is delivered only 50% of the time, and once you visit it remembers you if you're using the same browser, so it might be a bit of a pain. Anyway, it's a good thing for us to make sure that we don't launch a permanent version that makes people remove the suggestion text just to type in the fields. It is very annoying. Steven Walling (WMF) • talk 02:09, 7 October 2012 (UTC)

I disabled and cleared existing cookies but I only ever see the old page. I reloaded it 30 or 40 times but still I see the same thing. Am I using the wrong link? HumphreyW (talk) 02:20, 7 October 2012 (UTC)

That's the right link. If you want to force seeing the UI of the new version, just enter mw.e3.acux.modifyPage() in your browser console. Disabling cookies makes it impossible to get put into the test, because that's how login sessions are remembered. Steven Walling (WMF) • talk 17:01, 8 October 2012 (UTC)

Umm, I don't have JS so that means I don't have a JS console either. If I enable cookies and then I always get the previous version. HumphreyW (talk) 00:40, 9 October 2012 (UTC)

Not having JS turned on is another reason why you wouldn't see it, since the test version requires JS. If you're not a user that has JS turned on, the future permanent changes will really be only skin deep, as in changes to the size and color of fields and buttons you can just see in the screenshot. Steven Walling (WMF) • talk 05:30, 9 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)

Highlighting disambiguation links

Hello, in many language WPs (e.g. in my german home WP) I can choose highligthing of links to disambiguations in personal preferences, but I can't find this here in en:WP. Do I need new glasses or really isn't such a possibility here? Thanks for help, eryakaas (talk) 19:29, 6 October 2012 (UTC)

Try User:Anomie/linkclassifier.js. Add this to Special:Mypage/skin.js (your current skin) or Special:Mypage/common.js (all skins):

importScript('User:Anomie/linkclassifier.js'); // Linkback: User:Anomie/linkclassifier.js

PrimeHunter (talk) 19:34, 6 October 2012 (UTC)

Does that line work by itself? The example at User:Anomie/linkclassifier#Usage follows this with a second line

importStylesheet('User:Anomie/linkclassifier.css'); // Linkback: User:Anomie/linkclassifier.css

-- John of Reading (talk) 19:53, 6 October 2012 (UTC)

Right. You also need that if you don't make your own color selections in Special:Mypage/skin.css or Special:Mypage/common.css. PrimeHunter (talk) 20:06, 6 October 2012 (UTC)

Thanks! Now I see a lot of colours ;-) eryakaas (talk) 20:11, 6 October 2012 (UTC)

I don't yet have anything in Special:Mypage/skin.js. Can I create with this one addition? Thanks. Martinevans123 (talk) 20:20, 6 October 2012 (UTC)

I hadn't it before too ;-) eryakaas (talk) 20:29, 6 October 2012 (UTC)

Thanks! Martinevans123 (talk) 20:41, 6 October 2012 (UTC)

@Martinevans123: if you don't have a Special:Mypage/skin.js, it's probably best to put the code into Special:Mypage/common.js; that way it will operate regardless of the currently-selected skin. If you don't have Special:Mypage/common.js either, just create it with both of the lines referred to above (and shown in the first dotted box at User:Anomie/linkclassifier#Usage). --Redrose64 (talk) 21:21, 6 October 2012 (UTC)

Thank you Redrose64, that's really very useful. Martinevans123 (talk) 22:55, 8 October 2012 (UTC)

Diff view

What happened to diff view? It is completely unusable. Improved diff view works fine though. Ryan Vesey 05:23, 7 October 2012 (UTC)

What do you mean by "diff view", the built-in diff feature or a script or gadget? How is it unusable? PleaseStand (talk) 07:12, 7 October 2012 (UTC)

The built in diff feature. There are no colors in the diff so it is very hard to see what is being changed. Consider this diff. When you don't know that yes is being changed to no (and one no is being changed to yes) it is almost impossible to read. I didn't figure it out until I went to the improved diff view using the gadget. It's much easier on something like this because you can tell there was an addition, but when there are just changes and no modifications it is worthless. Ryan Vesey 14:59, 7 October 2012 (UTC)

Consider the appearance of this screenshot I uploaded. It is extremely difficult to tell what occurred just from looking at the diff because all of the color is gone. Ryan Vesey 15:10, 7 October 2012 (UTC)

Looks like you are missing some CSS. Try by passing your browser cache. —TheDJ (talk • contribs) 15:12, 7 October 2012 (UTC)

This occasionally happens to me (I'm using the blue and yellow diff colors), but reloading the page always seems to fix it. David1217 16:18, 7 October 2012 (UTC)

It also happens for me (I use Google Chrome). Helder 12:51, 8 October 2012 (UTC)

common.css file

Add the following code to your Special:Preferences#mw-prefsection-rendering skins Custom common.css CSS file ]

table.diff, td.diff-otitle, td.diff-ntitle {
        background-color: white;
        border: 1px solid gray;
        font-family: Arial, san-serif; font-size: 12pt;
}
td.diff-addedline {
        background: #cfc;
        font-size: smaller;
}
td.diff-deletedline {
        background: #ffa;
        font-size: smaller;
}
td.diff-context {
        background: #eee;
        font-size: smaller;
}
.diffchange {
        color: red;
        font-weight: bold;
        text-decoration: none;
}
td.diff-deletedline span.diffchange {
        background-color: #FFD754; color:black;
}
td.diff-addedline span.diffchange {
        background-color: #73E5A1; color:black;
}
.d{
        overflow: auto;
}

Will take your diffs from trying to spot a fish in water to a clear display. Regards, Sun Creator 18:24, 7 October 2012 (UTC)

This has nothing to do with colors, and everything with failing connections causing incomplete CSS being cached by the browser (or a router or ISP). Adding another set of colors won't help. Getting a stable internet connection and a good browser is better advice. BTW. you should use ] these days for anything that is not skin specific. —TheDJ (talk • contribs) 18:31, 7 October 2012 (UTC)

Good point on common.css. Regards, Sun Creator 18:39, 7 October 2012 (UTC)

Hmm,I bypassed my cache and then reset my computer when that didn't work. I've got a good internet connection and I'm using chrome. Still nothing. Perhaps adding the css above will override whatever isn't working? On the note of which page to add it to, I usually link people to Special:MyPage/common.css or Special:MyPage/common.js Ryan Vesey 18:41, 7 October 2012 (UTC)

My diffs are working beautifully, there's some poor formatting with the twinkle options, but everything else is great! Thanks for the css Sun Creator. I'm still curious why I seem to be the only one affected here though. Ryan Vesey 18:43, 7 October 2012 (UTC)

Ryan, you're not the only one having this problem. I have recently encountered it multiple times. In each case, reloading the page successfully loads the CSS. This time, I opened View Page Source and found the URL the relevant CSS was supposed to load from:

<link rel="stylesheet" href="//bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&amp;lang=en&amp;modules=mediawiki.action.history.diff&amp;only=styles&amp;skin=vector&amp;*" />

I clicked the link and got this message: "Scripts should use an informative User-Agent string with contact information, or they may be IP-blocked without notice." After reloading the page, reopening View Page Source, and clicking the link again, I did see the CSS. I was using Firefox 15.0.1 on Ubuntu Linux 12.04 (with a few browser add-ons) to access the new secure server. Hopefully this information will help in diagnosing the problem. PleaseStand (talk) 07:38, 8 October 2012 (UTC)

Really ? That is NOT supposed to happen. Perhaps such an error state got stuck in squid or something, causing all users with a similar config to get a cached copy or something. I'll try to find a sysadmin to ponder this problem. —TheDJ (talk • contribs) 13:05, 8 October 2012 (UTC)

I filed a bug report about this. —TheDJ (talk • contribs) 13:19, 8 October 2012 (UTC)

Buffering

Sometimes i press my edit count button it just buffers and doesn't direct to the edit count page. Is this a glitch? Pass a Method talk 11:18, 7 October 2012 (UTC)

There can be many reasons for this, but for me most often it means my internet connection is just below par. —TheDJ (talk • contribs) 15:15, 7 October 2012 (UTC)

I guess you refer to the "Edit count" link at the bottom of user contributions. This is an external link to http://toolserver.org/~tparis/count. Toolserver links are frequently slow or non-responsive in my experience, independent of my connection speed to Misplaced Pages itself which is at wikipedia.org. The two sites are run differently. Special:Preferences here at Misplaced Pages is fast but only has a total "Number of edits" field with no details. PrimeHunter (talk) 22:19, 7 October 2012 (UTC)

A toolserver query such as X!'s Edit Counter may take a long time due to the number of database rows which need to be retrieved. Sometimes, when toolserver load is high, the query may time out or even be "killed" for consuming too many resources, such as memory or CPU cycles. When this happens, it's normally worth waiting an hour or so before retrying, to let other activity be completed. --Redrose64 (talk) 14:20, 8 October 2012 (UTC)

Is there something I can add to my js or css page to hide links in the toolbox?

It's rather crowded, especially on user pages, and I'd like to hide some links that I never use. Is it possible? - Purplewowies (talk) 23:15, 7 October 2012 (UTC)

Yes. Look in the HTML source for the page, and you'll see it looks something like this:

<li id="t-whatlinkshere"><a href="/Special:WhatLinksHere/Wikipedia:Village_pump_(technical)" title="List of all English Misplaced Pages pages containing links to this page " accesskey="j">What links here</a></li>
<li id="t-recentchangeslinked"><a href="/Special:RecentChangesLinked/Wikipedia:Village_pump_(technical)" title="Recent changes in pages linked from this page " accesskey="k">Related changes</a></li>
<li id="t-upload"><a href="/Wikipedia:Upload" title="Upload files " accesskey="u">Upload file</a></li>
<li id="t-specialpages"><a href="/Special:SpecialPages" title="A list of all special pages " accesskey="q">Special pages</a></li>

The bit at the beginning of each line is what you need (e.g. <li id="t-specialpages">). Just take the id value for whichever ones you want to hide, and add appropriate rules to your common.css, e.g.

#t-specialpages { display:none; }

HTH. Anomie⚔ 01:16, 8 October 2012 (UTC)

You can do it with code from mw:Manual:Interface/Sidebar#Add or remove sections (JavaScript) in Special:MyPage/common.js or Special:MyPage/skin.js. You can omit the link parameter in "remove" calls of form ModifySidebar("remove", "toolbox", name), where name is the displayed name for a link, for example "Upload file". PrimeHunter (talk) 01:29, 8 October 2012 (UTC)

Huh, well. I've been trying to hide "Upload file" since it's technically a duplicate of a new link I added to the toolbox, and I cannot for the life of me get it to hide with either method. I've only been trying the css method (though I did see the other page, but missed the other method Facepalm). I have managed to successfully hide "Permanent link", though (but it won't hide through css... if it's alone). Why can't I get the upload one to hide at all? - Purplewowies (talk) 02:54, 8 October 2012 (UTC)

How about just removing the logo and some links above to give you more room? Regards, Sun Creator 03:10, 8 October 2012 (UTC)

/* ********** REMOVE ELEMENTS IN THE LEFT HAND SIDEBAR ********** */
/* Gets rid of the Misplaced Pages logo in the left hand sidebar */
div#p-logo
{ display: none; }
/* Move up text to where the logo was */
div#mw-panel
{ top: 0; }
/* Remove "Donate to Misplaced Pages" */
li#n-sitesupport
{ display: none; }
/* Remove "Misplaced Pages Shop" */
li#n-shoplink
{ display: none; }
/* Remove "About Misplaced Pages" */
li#n-aboutsite
{ display: none; }
/* Remove "Contact Misplaced Pages */
li#n-contact
{ display: none; }

I don't really want to do that, mostly because it's the box itself that's bothering me. There's just a lot of links in it on a user page. That and the redundant upload buttons bother me. - Purplewowies (talk) 03:37, 8 October 2012 (UTC)

You had correct code in , but $('.mw-rollback-link a').text('rollback'); in the above line is meant for your js and not your css. If you want to use mw:Manual:Interface/Sidebar#Add or remove sections (JavaScript) then copy the whole code and change the ModifySidebar calls in CustomizeModificationsOfSidebar. PrimeHunter (talk) 12:35, 8 October 2012 (UTC)

Gah. Facepalm. Removing the js code seems to have solved the problem of the css not working. I'm successfully hiding it all. - Purplewowies (talk) 01:44, 9 October 2012 (UTC)

Try adding an important:

#t-upload { 
	display: none !important; 
}

Might help. Or it could just be caching issues or whatever. special:MyPage/common.css, purge, hard refresh, and all that. -— Isarra ༆ 15:35, 8 October 2012 (UTC)

The commons:MediaWiki:IPadSidbarSlider.js might be useful. See also bugzilla:14501. Helder 15:50, 8 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)

link isn't linking

Any idea why the link to International Council on English Braille in the lead of IPA Braille isn't linking? Checked in FF and IE. — kwami (talk) 18:54, 8 October 2012 (UTC)

The link was broken across two lines. -- John of Reading (talk) 18:58, 8 October 2012 (UTC)

Well, now I feel stupid! — kwami (talk) 19:09, 8 October 2012 (UTC)

Left side menu bar

First, has it always been the case that the "navigation" "search" etc. section headers have always been lowercased at the start ("interaction", not "Interaction") or have I only just noticed it? Also is it just me or do the results popping up when you type in the "Search" box now have a smaller font size? - The Bushranger _{One ping only} 22:33, 8 October 2012 (UTC)

Assuming that you refer to the Monobook skin - no, this is not just you: it's changed in the last 24 hrs, presumably to be more like Vector. --Redrose64 (talk) 22:54, 8 October 2012 (UTC)

...changing to be more like Vector would rather defeat the purpose for those of us who use it because, y'know, we don't like Vector... - The Bushranger _{One ping only} 01:59, 9 October 2012 (UTC)

File:Monobook.css.png also shows lowercase in 2008. PrimeHunter (talk) 23:49, 8 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)

The gif width bug？

When the width of the gif file is multiple of 50, the image can't be displayed properly.

http://en.wikipedia.org/User:Xh286286/temp2

--Scoooooorpio（留言） 04:58, 9 October 2012 (UTC)

Loading the image's description page and then adding ?action=purge at the end of the URL (see WP:PURGE) fixed the problem (the GIF thumbnail not animating) for those images. PleaseStand (talk) 05:51, 9 October 2012 (UTC)

Character insert box keeps disappearing

What's going on with the character insert function (the bit below the edit window where you can click on special characters to insert them)? Sometimes it's there (it is as I'm making this edit, for example), but other times it's not. (This is in IE9 on Windows 7.) Victor Yus (talk) 09:09, 9 October 2012 (UTC)

Yes, this happens with me, too. Safari 5.1.7 on OS X 10.6.8. David1217 23:49, 10 October 2012 (UTC)

"Cite" link is not appearing in edit toolbar

The link "Cite" (beside "Help") is not appearing. I have bypassed cache, tried in multiple articles, tried from a browser where I am not signed in. Is anyone else facing this? --Tito Dutta ✉ 11:24, 9 October 2012 (UTC)

Anyone? Or any help? --Tito Dutta ✉ 14:58, 9 October 2012 (UTC)

It is there for me right now. At times it has disappeared on me. There is a similar citation tool if you turn the advanced editing toolbar off at Preferences → Editing. You could try doing that. Ryan Vesey 15:04, 9 October 2012 (UTC)

To be clear, you turn it off by unchecking enable advanced editing toolbar. Ryan Vesey 15:05, 9 October 2012 (UTC)

I have to insert a bunch of references and named references now. For last few hours I have been either adding content without reference and adding the article's titles in notepad to add sources later or using this universal reference formatter. How can I add named reference now (I have unchecked enable advanced editing toolbar) --Tito Dutta ✉ 15:21, 9 October 2012 (UTC)

Is this related to MediaWiki talk:RefToolbar.js#Error: mw.usability is undefined? Have you seen any warnings on your browser's console? Helder 15:26, 9 October 2012 (UTC)

I am using Firefox 14.0.1 Ubuntu 12.04. I have not seen any warning. :-( --Tito Dutta ✉ 15:32, 9 October 2012 (UTC)

At the very right of the new toolbar it gives you is a button that says cite with curly brackets around it. If you click that, you get a new bar directly under that has buttons for web, news, book, journal, named references, error check, more, and cancel More gives you encyclopedia, press release, map, and ref section. It's all pretty awesome really, and way better than the normal toolbar's citation tool. If you choose one of those buttons (say web) there is a field for a named reference at the bottom. Ryan Vesey 15:33, 9 October 2012 (UTC)

Tito Dutta, it happens to me frequently. It's been going on for months, since one or another upgrade happened. Sometimes it's there. Sometimes it's not. I have, and have always had, WindowsXP. I have Firefox browser, but the version has changed and upgraded many times since this issue began. That cite button can be completely absent. And then it will magically be there. It's the nature of the beast.  —  Maile66 (talk) 15:35, 9 October 2012 (UTC)

I am experiencing the same difficulty. This is quite an inconvenience. --Jprg1966  16:44, 9 October 2012 (UTC)

Flagged Revisions and Templates

would flagged revision be suitable for the now high-vis-editprotected templates? That would allow nonadminto make the changes and others then to approve them. Agathoclea (talk) 15:11, 9 October 2012 (UTC)

Unless things have changed since the last time I checked, transclusion always takes the most recent version rather than the flagged version. So this would not work. Anomie⚔ 19:40, 9 October 2012 (UTC)

Citation button on the unenhanced editing toolbar is infiinitely better.

The citation button on the unenhanced toolbar is infinitely better than the citation button on the enhanced editing toolbar. Is there any way to get the latter button on the enhanced editing toolbar? Ryan Vesey 15:35, 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)

Preserve wikilinks when archiving

Is there a way or a proposal or is it at all technically possible to preserve wikilinks to section headers on[REDACTED] (talk) pages when these pages get archived? bamse (talk) 19:45, 9 October 2012 (UTC)

It depends upon the archiving method. Archiving done by ClueBot III (talk · contribs) usually fixes link from elsewhere so that they point to the archive, not to the (newly non-existent) original; but many other archiving bots (such as the MiszaBot II (talk · contribs) family) don't. Where manual archiving is in use, fixing up these broken incoming links is so tedious that most people don't bother. --Redrose64 (talk) 20:56, 9 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)

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)

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)

Logging in on mobile is broken

Attempting to log in at http://en.m.wikipedia.org/search/?title=Special:UserLogin is failing (submitting form returns you to form). Tested on a mobile device using IE 9 Mobile and a PC using Chrome 21.0.1180.79. — Hex (❝?!❞) 21:08, 9 October 2012 (UTC)

There's not yet anything you can do while logged in on the mobile interface, so that's ok for now. ;) We're retooling the mobile login as we're working on support for watchlists and such, so it'll come in the next couple weeks (at least for beta mode). --brion (talk) 22:05, 9 October 2012 (UTC)

Okay, cheers :) — Hex (❝?!❞) 09:28, 10 October 2012 (UTC)

Mobile wikipedia

I am experiencing a problem using[REDACTED] on mobile phones. I am now only getting subject headings which when selected do not open up the relevant text. Please help — — Preceding unsigned comment added by 86.146.144.73 (talk) 21:30, 9 October 2012 (UTC)

What kind of phone is this? What browser? --brion (talk) 22:00, 9 October 2012 (UTC)

This problem is occurring on various phones using different system. My phone is a Nokia C3. Up to a couple of weeks ago the access was perfectly normal!

Do you use Opera Mini? I've had issues with the Android app for that on mobile wikis running MediaWiki like Misplaced Pages (except not Misplaced Pages itself because I use the desktop version). - Purplewowies (talk) 01:56, 10 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)

Unable to access Wikimarkup (symbols, diacritics, Latin, etc.)

I have to raise this here because it is seriously impacting my editing abilities and my ability to sign any comments I make. Over the last week to two weeks, at least, I have been unable to access wikimarkup (with symbols, diacritics, Latin, etc.) I left some stuff unsigned hoping the Sign-bot would do it but of course it didn't. It isn't the computers, because it's like this in Internet rental places, at public libraries, etc. Most pages do not automatically have the wikimarkup where it used to be. Some do, most do not. Just thought I'd let you know. There is a note that says "View hidden categories on this page" but that has nothing to do with this problem. Unable to sign, so .... User:Rms125a@hotmail.com

Are you referring to the edit toolbar? Make sure you have javascript enabled on any browser you use. (If that doesn't work, try disabling any firewall you might have in place.) --regentspark (comment) 17:54, 10 October 2012 (UTC)

The markup was taken away with the changes to the edit window. It might be coming back; however, it is likely to be in a new place. You can get it back if you go to Preferences → Editing and uncheck enable enhanced editing toolbar. Ryan Vesey 18:46, 10 October 2012 (UTC)

I guess it's the edit toolbar. I am at the library now and it does not appear, although it does say: "View hidden categories on this page". I am on a library computer and I couldn't remove Javascript even if I knew how. Why would they take away the markup?? How can anyone sign anything or use diacritics, etc.??

Well, signing things isn't incredibly hard. As far as diacritics are concerned, you can find out how by doing a google search for alt codes for (language) if you're using a PC and a search for mac codes for (language) if you're using a mac. Alternatively, there is a special characters dropdown menu from the toolbar that can deal with the diacritics. That being said, I unchecked the enhanced editing toolbar and I actually like the cite function on the toolbar better (it was the only thing I used on the old one), and I have my wikimarkup back so everything is good. Ryan Vesey 18:56, 10 October 2012 (UTC)

Signing in is impossible if you don't have the symbols you need. As per your advice, I went to preferences but did not see anything called "enable enhanced editing toolbar". I am not a computer whiz and everything is not good with me.

OK, I found it. Thanks!! Quis separabit? 19:07, 10 October 2012 (UTC)

There are other ways of signing posts if you don't have the Edit tools: see WP:SIGHOW. I normally use the "type four tildes (~)" method. --Redrose64 (talk) 20:24, 10 October 2012 (UTC)

Backwards twinkle rollback buttons?

Anyone else seeing the twinkle rollback buttons backwards at the first edit at Special:Contributions/Σ? (as (‮) (top)

Looks like some bizarre left-right movement glitch (like Arabic text?)? Or am I missing something that makes this like this? Just curious as I've never seen this before... – Connormah (talk) 23:49, 10 October 2012 (UTC)

Yup, me too. Not the only crazy contributions page reported here; see #Bizarre edit history. David1217 23:53, 10 October 2012 (UTC)

The edit summary for that edit contains U+202E, the right-to-left override character. Anomie⚔ 00:41, 11 October 2012 (UTC)

That would make sense - should these controls be affected by it though? – Connormah (talk) 00:44, 11 October 2012 (UTC)

Probably not. It could be mostly avoided by wrapping the comment text in a span with dir="auto", but that apparently causes problems in a buggy browser (e.g. Template:Bug, Template:Bug). Anomie⚔ 01:02, 11 October 2012 (UTC)

Images

For about fifteen minutes now images haven't been loading for me at all: any of them, the Misplaced Pages logo, images in articles, the wee Commons symbol on image pages. I see no images at Commons either. Am I alone here?  _.:τ 00:52, 11 October 2012 (UTC)

... and now they are back.  _.:τ 00:57, 11 October 2012 (UTC)

Still gone for me... – Connormah (talk) 01:08, 11 October 2012 (UTC)

Queer.  _.:τ 01:35, 11 October 2012 (UTC)

A large scale cache purge (performed by WMF to clean up some stale URLs) caused a temporary overload of the image scalers / storage cluster (whenever a page is purged, thumbnails are re-generated); this should be fixed now. Eloquence* 02:55, 11 October 2012 (UTC)

Yeah, looks fine now. – Connormah (talk) 03:16, 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)

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)

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)

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)

{{Cite quick}} works well on the page. Thanks! – Zntrip 00:38, 15 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)

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)

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)

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)

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