Wikipedia:Village pump (technical): Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 19:15, 10 October 2012

Table of contents
First discussion
End of page
New post

Shortcuts

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (How to report a bug). Bugs with security implications should be reported to security

wikimedia.org.

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

view · edit

Frequently asked questions (see also: Wikipedia:Technical FAQ)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.

No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an `accesskey` property on it (default to `accesskey="f"` in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.

If you have problems making your fancy signature work, check Help:How to fix your signature.

If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.

If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

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

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

Moving what is currently the first line of text under the edit window "content that violates any copyrights..." (MediaWiki:wikimedia-copyrightwarning) above it.
Rationale: This line is primarily composed of guidance as to what sort of content is appropriate for Wikipedia. (Several projects moved such guidance here from MediaWiki:Edittools when this message was introduced after the license switch.) Having it below the edit window almost ensures that people will only read it after they have tried to make changes - it is of little use. On the other hand, if we move it above the edit window, we have an opportunity to educate people about what is or is not appropriate before they start writing.
Removing the reference to a help page.
Rationale: At first glance, this might appear counterintuitive. The logic is that the advanced editing toolbar (which all new users are presented with by default) already includes a link to a "cheat sheet" of markup. The help page linked in the text, on the English Wikipedia, is a similar cheat sheet, creating duplication and taking up unnecessary space.
Removing half of the "if you do not want your writing..." line (MediaWiki:wikimedia-editpage-tos-summary) – that bit concerned with the Terms of Use – and moving the other half above the edit window.
Rationale: Again, the message (even the legal text) has been customised by the English Wikipedia and several projects added here information/warnings previous shown in the edittools; the advice will be of most use if it is shown to a user before they have contributed. At the moment, this text is not only after the edit window but also after the "save page" button – people may not even see it before submitting their changes. The text relating to the Terms of Use is a duplication of the existing disclaimer, and one that Legal concludes serves no purpose.
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.
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.
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)[reply]

Comments

Looks good. No major issues that I can see. IRWolfie- (talk) 20:45, 5 September 2012 (UTC)[reply]

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

Looks good to me too. Bring on the Naysayers and doom and gloomers! :-) Kumioko (talk) 20:54, 5 September 2012 (UTC)[reply]

Discussion of impact on other wikis Okeyes (WMF) (talk) 20:06, 20 September 2012 (UTC)[reply]

Is this only for English wikipedia, or why is this linked to a mediawiki page? Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 20:57, 5 September 2012 (UTC)[reply]
At the moment, this is only going to be deployed on enwiki; we don't want to fling the change out everywhere because it's a pretty big thing to be altering for every project. We'll hopefully ramp it out over time - first to other projects that request it, then to a wider userbase, then stick it as the default, so on, so forth. The location of the team page (MediaWiki.org) is because the team's projects overall are hopefully going to be for a much wider range of our wikis, and so it's not that appropriate to host it on an individual "in use" wiki. I appreciate this makes it slightly harded to follow the conversations - I'm looking for ways around this :S. Okeyes (WMF) (talk) 21:01, 5 September 2012 (UTC)[reply]

(OK. Once you get to other wikipedias, please keep in mind removing the edit-toolbar is in many cases a bad idea. Going through the list of all possible letters just to find the one you need each and every time is tedious, and typing Cherokee and Inuit is impossible without it. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 21:06, 5 September 2012 (UTC))[reply]

Heh; noted :). Does the enhanced toolbar not include that functionality? I can imagine it wouldn't for the particularly obscure characters (or those in non-westernised languages) but, generally-speaking, what is the "special characters" tab missing? Okeyes (WMF) (talk) 21:08, 5 September 2012 (UTC)[reply]

I'd note that Siebrand's team is working on mw:Universal Language Selector, which may help somewhat. Okeyes (WMF) (talk) 21:17, 5 September 2012 (UTC)[reply]

What you'd call obscure :P American letters, for example >> Ꭰ Ꭱ Ꭲ Ꭳ Ꭴ Ꭵ Ꭶ Ꭷ Ꭸ Ꭹ Ꭺ Ꭻ Ꭼ Ꭽ Ꭾ Ꭿ Ꮀ Ꮁ Ꮂ Ꮃ Ꮄ Ꮅ Ꮆ Ꮇ Ꮈ Ꮉ Ꮊ Ꮋ Ꮌ Ꮍ Ꮎ Ꮏ Ꮐ Ꮑ Ꮒ Ꮓ Ꮔ Ꮕ Ꮖ Ꮗ Ꮘ Ꮙ Ꮚ Ꮛ Ꮝ Ꮜ Ꮞ Ꮟ Ꮠ Ꮡ Ꮢ Ꮣ Ꮤ ᐊ ᐃ ᐅ ᐋ ᐄ ᐆ ᐸ ᐱ ᐳ ᐹ ᐲ ᐴ ᑉ ᑕ ᑎ ᑐ ᑖ ᑏ ᑑ ᑦ ᑲ ᑭ ᑯ ᑳ ᑮ ᑰ ᒃ ᒐ ᒋ ᒍ ᒑ ᒌ ᒎ ᒡ ᒪ ᒥ ᒧ ᒫ ᒦ ... etc. (can you even see those?) Instead of flooding the special characters-thing, just keep the edit toolbar. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 21:18, 5 September 2012 (UTC)[reply]

I can, yep :). Would the language selector not help? Okeyes (WMF) (talk) 21:22, 5 September 2012 (UTC)[reply]

I doubt it. It just wouldn't be worth it to this for the <200 people who'd actually use it. Just don't switch it off all of the sudden, that's all I was worried about. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 21:26, 5 September 2012 (UTC)[reply]

We'll try not to :). Like I said, we're not planning on scaling it out immediately - and when we do scale it out more widely I'm sure we can try to work together a CSS hack or opt-out for wikis that are going to struggle. Okeyes (WMF) (talk) 21:30, 5 September 2012 (UTC)[reply]

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

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

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

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

Accessibility concerns (now patched) and suggestions for future expansion. Okeyes (WMF) (talk) 20:06, 20 September 2012 (UTC)[reply]

I'm all for it. But with the following notes.
1. Should nicely deprecate my User:TheDJ/usagecollapse.js script. But did you take into account file usage and global file usage lists on edit pages ? See File:Name.jpg for an example of that horribleness.
  Does global file/account file useage appear in the edit window? I've never seen it, but I don't spend that much time around images. Okeyes (WMF) (talk) 21:30, 5 September 2012 (UTC)[reply]
  Unfortunately not, they are the same problem though. —TheDJ (talk • contribs) 21:37, 5 September 2012 (UTC)[reply]
  Sounds like an excellent target for our next improvement, then! :). Okeyes (WMF) (talk) 21:44, 5 September 2012 (UTC)[reply]
2. I would suggest finding an alternative for the pipe chars in the warnings however, and that whole bit should probably be an .hlist (en.wp specific css, which we really should add upstream btw).
  Agreed; the pipes are something we're looking into (when I showed it to my boss, he thought it was a capital I. Not a good sign!). Okeyes (WMF) (talk) 21:30, 5 September 2012 (UTC)[reply]
  
  Agree that the pipes in italics look strange. How about if just use periods or Bullets. Vibhabamba (talk) 23:32, 5 September 2012 (UTC)[reply]
  Bullets sound good to me. TheDJ/anyone else? Okeyes (WMF) (talk) 00:01, 6 September 2012 (UTC)[reply]
  
  I myself am fond of bullets: • --Jorm (WMF) (talk) 22:24, 5 September 2012 (UTC)[reply]
  Bullets are read out by screenreaders. The reason we don't use them in hlists anymore. —TheDJ (talk • contribs) 07:00, 6 September 2012 (UTC)[reply]
  
  +1 for hlist. BTW: I've requested its inclusion on MediaWiki at bugzilla:40062. Helder 20:53, 6 September 2012 (UTC)[reply]
  Going to simply employ a period after each sentence here. That is just enough for the job and works from an accessibility perspective. — Preceding unsigned comment added by Vibhabamba (talk • contribs) 22:37, 7 September 2012 (UTC)[reply]
3. I'm also not sure if it's a good idea to change the appearance of categories on the edit page. Inconsistent representation of the same data set might not be a good idea.
  What do you mean, sorry? Okeyes (WMF) (talk) 21:30, 5 September 2012 (UTC)[reply]
  Strike that, i'm confused with livePreview of the edit window, which copies categories as the view page has them.—TheDJ (talk • contribs) 21:37, 5 September 2012 (UTC)[reply]
4. I see light gray... Please think about contrast, our users with accessibility issues will appreciate that. —TheDJ (talk • contribs) 21:26, 5 September 2012 (UTC)[reply]
  An excellent point :). Okeyes (WMF) (talk) 21:30, 5 September 2012 (UTC)[reply]
  Thanks for bringing this up DJ. The grey was the most amount of contrast we could afford without making it compete with other elements on the page.

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

The darkness already competes with the rest of the screen in the vector skin. -— Isarra ༆ 17:23, 6 September 2012 (UTC)[reply]

Wider discussion about future changes Okeyes (WMF) (talk) 20:07, 20 September 2012 (UTC)[reply]

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

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

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

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

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. Monty ₈₄₅ 23:26, 5 September 2012 (UTC)[reply]

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

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

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

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

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

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

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

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

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

See Wikipedia:Village_pump_(proposals)#Message_on_search_results_page for something that is clicked often, yet not really helping along users. A way to measure this is a good idea, but we need a different metric in that case I think. —TheDJ (talk • contribs) 22:05, 5 September 2012 (UTC)[reply]

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)[reply]
I do not object, which is surprising. Evanh2008 ^{(talk|contribs)} 23:13, 5 September 2012 (UTC)[reply]
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)[reply]
The changes should only impact on Vector, yep. What preferences are you referring to? Okeyes (WMF) (talk) 00:30, 6 September 2012 (UTC)[reply]
"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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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

Comment: I like that the Save / Show preview / Show changes buttons are moved up. With the current design I'm always scrolling down to them which means moving the mouse out of the edit window and then scrolling with the mouse wheel. What I'd really like is for all of the edit controls, the submit buttons, edit summary, etc to be fixed all in one place (preferably at the top of the screen) so they never move while the rest of the page can be scrolled.

Missing is the box with the dashes and other common symbols and wiki markup links currently below the edit window. I rather use that a lot. The symbols that I use most commonly are the –, —, ×, and §. Don't make me hunt through the Special characters toolbar for them. I never use the Signature and timestamp button in the main toolbar (in fact, I don't use any of the options there.)

Because this is an edit page, the normal Wiki advert at the top of the page should be disabled (right now it's Participate in the world's largest photo competition and help improve Wikipedia! I'm editing, I don't need to see that and even with fast internet it slows page load; I'm not going to risk losing my work to go look at the advert. (I usually ignore it anyway even when I'm not editing). Yeah, I know this is probably outside the scope of this proposal.

—Trappist the monk (talk) 16:19, 25 September 2012 (UTC)[reply]

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

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

Here's an idea. It's not been tried before for this specific feature (AFAIK) but something similar has worked for other problems connected to visibility of other features. Go to Preferences → Gadgets, and under the "Editing" heading, locate "^(D) CharInsert: add a toolbar under the edit window for quickly inserting wiki markup and special characters (troubles?)", which should be switched on but might be off. If it's already switched on, switch it off and save. Then, whether or not it was previously switched on, switch it on and save. This should persuade the settings to update themselves. --Redrose64 (talk) 13:36, 26 September 2012 (UTC)[reply]

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

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

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

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

According to Help:Minor edit, "Users who are not logged in to Wikipedia are not permitted to mark changes as minor because of the potential for vandalism." Anomie ⚔ 14:29, 27 September 2012 (UTC)[reply]

So the real reason that I can't see the Edittools is because I'm not logged in? In the source for this editor there are three instances of the term Charinsert.

&lt;link rel="stylesheet"  href="//bits.wikimedia.org/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)[reply]

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

We're fixing this now. Okeyes (WMF) (talk) 00:27, 28 September 2012 (UTC)[reply]

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

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

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

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

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

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: [Hide instructions]. Anyway, thanks for discussing the issues, even if the screen cannot be improved very much. People have talked about having custom edit-windows which would be better for veteran editors who get dizzy from all the unnecessary up/down scrolling to get the "Show changes" button. -Wikid77 (talk) 03:39, 6 September 2012 (UTC)[reply]

New editors need to be shown those warnings. Established editors can make them disappear, using the code at Wikipedia:Tip of the day/November 22, 2008 -- John of Reading (talk) 07:25, 6 September 2012 (UTC)[reply]

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 "[Show preview]" button is only 4 lines (not 13) below the edit-window. Best improvement to Wikipedia in 4 years! (after the 2008 recursive descent parser for templates). -Wikid77 (talk) 22:50, 7 September 2012 (UTC) Template:J[reply]

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

Note no one is talking about any sort of site-wide CSS hack to hide it, or even a gadget. Just individual users, presumably knowing what they're doing, editing their Special:MyPage/common.css. See Wikipedia:Village pump (proposals)/Archive 69#Reducing boilerplate below edit box for a representative past discussion. Anomie ⚔ 17:13, 6 September 2012 (UTC)[reply]

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

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

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)[reply]
As a complete non-techie; what does that refer to, sorry? :). Okeyes (WMF) (talk) 12:31, 6 September 2012 (UTC)[reply]
Link, see the search field of vector for example. —TheDJ (talk • contribs) 12:34, 6 September 2012 (UTC)[reply]
Aha. So, as proposed above? See "One idea that..." Okeyes (WMF) (talk) 12:36, 6 September 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
What would your suggestion be, then? :). Okeyes (WMF) (talk) 16:18, 7 September 2012 (UTC)[reply]

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

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

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

This, we are fixing :). Okeyes (WMF) (talk) 00:32, 13 September 2012 (UTC)[reply]

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

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

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

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

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

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

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

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

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

The latter. Okeyes (WMF) (talk) 19:27, 7 September 2012 (UTC)[reply]

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

I requested that last month at Wikipedia:Gadget/proposals#Edit tools. No replies so far... Helder 18:08, 10 September 2012 (UTC)[reply]

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

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

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

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

The box shown at MediaWiki:Edittools is called the "edit tools". --Redrose64 (talk) 15:25, 5 October 2012 (UTC)[reply]

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

Fantastic! Thanks! • Jesse V.^(talk) 00:26, 17 September 2012 (UTC)[reply]

Okay; next Monday ;p. We had a couple of patches to get in. Okeyes (WMF) (talk) 19:31, 19 September 2012 (UTC)[reply]

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

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

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

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

I'd appreciate if there was an option to show the two lists uncollapsed per default. --Eleassar ^{my talk} 22:13, 22 September 2012 (UTC)[reply]

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

Ok, great. Thanks. --Eleassar ^{my talk} 19:11, 27 September 2012 (UTC)[reply]

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

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

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

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

What font? The font looks the same in the prototype. -— Isarra ༆ 18:11, 21 September 2012 (UTC)[reply]

Ignore me; just clarified with Rob and Vibha. Okeyes (WMF) (talk) 18:43, 21 September 2012 (UTC)[reply]

Nice move! Looks great! --Tito Dutta ✉ 18:07, 24 September 2012 (UTC)[reply]
Thanks! :). Okeyes (WMF) (talk) 20:25, 24 September 2012 (UTC)[reply]

Header when editing

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

Makes sense; I'll change it now :). Okeyes (WMF) (talk) 23:13, 27 September 2012 (UTC)[reply]

Now done! Okeyes (WMF) (talk) 23:14, 27 September 2012 (UTC)[reply]

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

What do you mean, sorry? Okeyes (WMF) (talk) 22:46, 28 September 2012 (UTC)[reply]

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

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

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

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

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

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

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

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

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

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

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^{talk - contribs} 16:27, 29 September 2012 (UTC)[reply]

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

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

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^{talk - contribs} 21:18, 8 October 2012 (UTC)[reply]

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^{talk - contribs} 14:00, 10 October 2012 (UTC)[reply]

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

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

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

Short-term fix is now in gerrit and awaiting review and deploy :). Okeyes (WMF) (talk) 00:24, 28 September 2012 (UTC)[reply]

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

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

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

You can always use the param wizard in the section below. Ryan Vesey 02:29, 28 September 2012 (UTC)[reply]

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

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

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

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

A known bug; my apologies :(. We should have the patch for that by Tuesday. Okeyes (WMF) (talk) 03:03, 28 September 2012 (UTC)[reply]

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

Please also give back the find and replace option. 76Strat ^String da _Broke da (talk) 04:00, 28 September 2012 (UTC)[reply]
What find and replace option? Okeyes (WMF) (talk) 04:02, 28 September 2012 (UTC)[reply]
It use to sit near the top of the right side bar of the edit pane. 76Strat ^String da _Broke da (talk) 04:06, 28 September 2012 (UTC)[reply]
It is still there. You need to have the advanced tab open. Ryan Vesey 04:11, 28 September 2012 (UTC)[reply]
Thank you Ryan; Have you seen the new teahouse? 76Strat ^String da _Broke da (talk) 04:29, 28 September 2012 (UTC)[reply]
Yep, I'm not sure that I love it though. Ryan Vesey 20:05, 28 September 2012 (UTC)[reply]
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 ^{ping / poke} 04:22, 28 September 2012 (UTC)[reply]
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)[reply]

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^talk 09:52, 28 September 2012 (UTC)[reply]

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

Even though the only way to actually save is to scroll past that box? Okeyes (WMF) (talk) 17:21, 28 September 2012 (UTC)[reply]

It's not though. Alt+⇧ Shift+S works for me. --Redrose64 (talk) 18:35, 28 September 2012 (UTC)[reply]

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

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

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

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 text

Insert a reference

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

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

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

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

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

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

Oh, perfect. That's solved it, thanks. Shawn in Montreal (talk) 20:54, 28 September 2012 (UTC)[reply]

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

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

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

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

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

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

Thank you; that makes a lot of sense, and is a lot more productive than our earlier discussion :). So, traditionally the development process went "come up with idea, develop, deploy, fix bugs in one big swoop and then declare it done and wander off". With our newer stuff, I've actually pushed people to do exactly what you've described; Wikipedia:Page Curation was live as a non-replacement for the existing process the moment we had a prototype that didn't explode and throw cogwheels out the moment anyone looked at it, and I think our development process went a lot smoother because of it.

I'd love to do the same thing with these kinds of tweaks, and for future projects and iterations, I agree that this approach should be something we look into on a case-by-case basis, but - just for context - I think it would have been a challenging thing to work into this project, though. These changes came as the first project of the new Micro-Design Improvements team, which has Vibha Bamba doing design, Benny Situ and Rob Moen coding, and me sort of tidying around the edges. Sounds like a lot of bodies - until you realise that we only get Benny and Rob one day a week each (and they're neither sequential nor simultaneous days) which seriously limits what we can do, and that both Vibha and I are on other projects which demand substantial time. This slows down how quickly we can make alterations (although we actually have a fix for this problem already developed , and are just waiting for it to be deployed).

Obviously this is no excuse, but it means we strain to repair the problems instantaneously. Because of all of these factors, I can't offer an immediate change to our approach for this project - but I can promise that we'll get better at this. As depressing as it is, the fact that we're having this conversation at all is indicative of a shift in how the WMF approaches software deployments: hopefully further improvements will be coming down the pipeline soon, and I'll try to integrate your feedback into our thinking :). Okeyes (WMF) (talk) 01:24, 29 September 2012 (UTC)[reply]

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

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

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). David 1217 ^{What I've done} 01:55, 29 September 2012 (UTC)[reply]

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

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

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

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

CSS

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

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

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

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

Thank you. -— Isarra ༆ 03:11, 29 September 2012 (UTC)[reply]

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

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

Wikipedia:2012 main page redesign proposal/Br'er Rabbit <br /> 04:51, 29 September 2012 (UTC)[reply]

Different font and size in edit mode

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

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

Hi Steven, thanks for the reply. I use Firefox and in my WP preferences I had ticked "sans-serif font." When I saw your post I changed it to "browser default," and that has restored the font I had before this recent change. It also got rid of the boldface. Thank you for pointing me in the right direction. SlimVirgin ^(talk) 17:36, 2 October 2012 (UTC)[reply]

Glad it worked. :) Steven Walling (WMF) • talk 17:41, 2 October 2012 (UTC)[reply]

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

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

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

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

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

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. --No unique names 18:20, 29 September 2012 (UTC)[reply]

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

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

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

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

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

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

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^{talk - contribs} 16:58, 30 September 2012 (UTC)[reply]

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

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

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

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

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

Editor Isarra has identified this issue as a bug. In his description of the bug this:

For consistency, when editing, the 'Cancel' link should really be a button along with the other buttons on the line, since it is an action like the rest of them even if it isn't directly tied to the form itself.

The help link ... [off-topic so excluded here]

Ignore the other stuff, but the line of buttons would look something like on this: http://commons.wikimedia.org/wiki/File:Enwp_edit_20120917_with_even_less_stuff.png

This description ignores the fact that the Cancel link doesn't actually cancel anything – all it does is link the editor to the current unedited copy. In the description and in subsequent conversation with other editors at the Bugzilla page, Editor Isarra doesn't state what a Cancel button should do. This somewhat implies that a button version of the link would perform the same action as the current link.

It seems to me that a true Cancel button might do either of a couple of things:

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

Charinsert not working

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

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

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

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

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

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

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

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

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

One more gripe from a disgruntled editor, yes great so we can get our very handy edit tools window back ONLY by turning off the enhanced editing toolbar, leaving us with a bunch of clunky looking buttons above the edit window that I am in no way familiar with, and which, when inserting a wikilink, will not automatically propose the relevant wikipage, or a box to add text that is different.

Have to agree with several users above that having wiki markup in a drop-down box is a godsend and improves the editing experience a bazillion times, with which I can do this {{}}, {{Reflist}}, <ref name=""/> in a few clicks, thus facilitating my life as an editor and increasing the rapidity with which I can edit.

So, charinsert and enhanced editing toolbar please, as it was before, "I would have gotten away with it, too, if it hadn't been for you meddling kids!" CaptainScreebo ^Parley! 16:08, 7 October 2012 (UTC)[reply]

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

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

1/6 3/5 "Symbols"

Hi all, under "Special Characters" can someone add or link to a 1/6 or 3/5 as a single character? Thanks so much! Marketdiamond (talk) 06:32, 6 September 2012 (UTC)[reply]

⅗⅙ HumphreyW (talk) 07:32, 6 September 2012 (UTC)[reply]

Excellent!! Thanks much! Marketdiamond (talk) 08:06, 6 September 2012 (UTC)[reply]

Note that MOS:FRAC says: "The use of the few Unicode symbols available for fractions (such as ½) is discouraged entirely, for accessibility reasons among others." I'm not sure we should even keep the current Unicode fractions ½ ⅓ ⅔ ¼ ¾ ⅛ ⅜ ⅝ ⅞ at MediaWiki:Edittools.js and elsewhere. ½ is the only which is easily readable to me. PrimeHunter (talk) 10:13, 6 September 2012 (UTC)[reply]

Indeed, as a screen reader user, I can confirm this is a problem. FWIW the characters for ½, ¼ and ¾ read out fine here as they're part of ISO/IEC 8859-1, but the others certainly don't. Graham87 09:51, 7 September 2012 (UTC)[reply]

Eh, how does your screen-reader not understand say Unicode ⅔? I'd expect exactly that is not a problem. -DePiep (talk) 00:37, 10 September 2012 (UTC)[reply]

If Graham87 (talk · contribs) says that his screen reader has problems with these characters, I believe him without question. Just because a character has a Unicode character encoding, it doesn't necessarily imply that it is universally recognised.

To take a visual example: my PC has Windows XP, as does my mother's laptop; yet they each have problems displaying certain Unicode characters, but the problems differ. My PC displays certain Asian text, including Chinese and Japanese text, without problem, but fails to display part of one of the signatures on this page (specifically, the talk page link in Anomie ⚔) - to me, it's a square containing the characters 2694. Conversely, my mother's laptop displays that talk page link, which is a pair of crossed swords, but won't display either Chinese or Japanese - these both show as rows of numbered squares.

Since it has been proven that different machines (with the same operating system) do not recognise the whole Unicode set, I don't expect that all screen readers will necessarily recognise the whole Unicode set either. --Redrose64 (talk) 12:17, 10 September 2012 (UTC)[reply]

I understand MOS:FRAC mentions accessibility because the fractions are likely illegible in regular fontsize. A screen reader does not use fontsize, so that aspect cannot be in play with Graham87. The other aspects mentioned (not picked up by a screen reader, and Unicode character not recognised by an OS/font setup) is not specific to these fraction characters. If it were that, there would be a more general restriction on Unicode characters. -DePiep (talk) 18:41, 10 September 2012 (UTC)[reply]

There are MANY characters that screenreader software does not understand (does not have an audio fragment for), this has nothing to do with them being unicode or not. Supporting all possible characters would probably be cost prohibitive and not to mention create a program of a dozen or so gigabytes. —TheDJ (talk • contribs) 22:14, 11 September 2012 (UTC)[reply]

If that were the reason to mention these characters in WP:FRAC, it would be far too limited (too few prohibitions), then WP:ACCESS should mention this. Since this is not in WP:ACCESS at the moment, I maintain that the access-problem is the visible character: too small to read. -DePiep (talk) 20:55, 17 September 2012 (UTC)[reply]

Indeed, there is a patch for my screen reader, JAWS to teach it the audio representations for almost all Unicode characters, but every time I've tried to use it, it's ground my system to a halt (even when I copied it to the correct folder per the instructions on the site). Specialised sets of Unicode audio representations for things such as IPA and mathematics work much better, but I don't think they're widely used by general screen reader users. Graham87 07:27, 12 September 2012 (UTC)[reply]

So what is the lowest common denominator that Wikipedia should support? I don't mean to be nasty here, but is it possible that JAWS is not the best option for a screen reader? Perhaps we are not encouraging its development by stagnating upon the set of characters that we a permitted to write with? Or is it that JAWS is the best-of-breed and we just have to live with such restrictions? I really don't have any experience here so these are genuine questions I have. HumphreyW (talk) 22:42, 12 September 2012 (UTC)[reply]

I can't speak to the advantages or disadvantages of different screen readers (I assume Graham would know more about that), but JAWS (screen reader) is one of the most popular (the most popular?) screen reader in the world. We could also stop supporting IE because it sucks balls, but that wouldn't be fair to all the IE users out there. But as to what we should actually be doing, ½ was the only fraction I could read off the bat, and barely. I had to toggle the font higher three times before I could read most of the fractions at a comfortable distance. Someguy1221 (talk) 23:03, 12 September 2012 (UTC)[reply]

JAWS is one of the best Windows screen readers around, especially for working on the Internet. I'm not familiar enough with other operating systems to comment on them. Graham87 09:20, 13 September 2012 (UTC)[reply]

This page which is linked from the "On this day..." box has three occurrences of -->   <--. For me that renders as a box with 202F inside. Is there a policy or guide page that states which characters are considered acceptable, or not acceptable, to put into an article? HumphreyW (talk) 07:17, 13 September 2012 (UTC)[reply]

That character is a narrow no-break space, which is disallowed on Wikipedia for exactly that reason. I've replaced it with a regular non-breaking space. Ironically, although I'd copyedited that article earlier in the day, I didn't notice anything wrong with the characters, ironically because JAWS read them out as "space". I don't think there's a centralised list of allowed and disallowed characters; I think they're just mentioned in the various sections of the Manual of Style (e.g. non-breaking spaces, quotes, etc). Graham87 09:20, 13 September 2012 (UTC)[reply]

That could be related to the UDL blacklist: such a space could show a misleadding IDN address (one cannot discern that it is an irregular space), and so is banned from IDN addresses. Technically, that does not apply to page content, but those "some browsers" might not know that. Interestingly, ½ and other vulgar fractions are blacklisted too, but I cannot test whether the WP disallow-rule and associated errors occur with these characters. -DePiep (talk) 20:49, 17 September 2012 (UTC)[reply]

I have suggested to remove all fractions except ½ from MediaWiki:Edittools. Discussion at MediaWiki talk:Edittools#Proposal to remove fractions. PrimeHunter (talk) 22:32, 13 September 2012 (UTC)[reply]

Test for comparison:

Unicode, normal size: ½ ↉ ⅓ ⅔ ¼ ¾ ⅕ ⅖ ⅗ ⅘ ⅙ ⅚ ⅐ ⅛ ⅜ ⅝ ⅞ ⅑ ⅒ ⅟

Unicode, zoomed in: ½ ↉ ⅓ ⅔ ¼ ¾ ⅕ ⅖ ⅗ ⅘ ⅙ ⅚ ⅐ ⅛ ⅜ ⅝ ⅞ ⅑ ⅒ ⅟

Template, normal size: 1⁄2 0⁄3 1⁄3 2⁄3 1⁄4 3⁄4 1⁄5 2⁄5 3⁄5 4⁄5 1⁄6 5⁄6 1⁄7 1⁄8 3⁄8 5⁄8 7⁄8 1⁄9 1⁄10 1⁄

Double sharp (talk) 02:54, 23 September 2012 (UTC)[reply]

0/3? What a silly thing to write. --MZMcBride (talk) 18:30, 25 September 2012 (UTC)[reply]

I guess you don't keep score in baseball matches then. I don't either: but see here under "Comments". --Redrose64 (talk) 18:45, 25 September 2012 (UTC)[reply]

For me the template generates the clearest rendering.

Also, in the edit window the "Symbols:" section has many square boxes with hex codes. If an editor decides to use a symbol from the list on a page then I would not know what it is meant to be. The current list is this:

~ | ¡ ¿ † ‡ ↔ ↑ ↓ • ¶ # ∞ ‘ ’ “ ” «» ¤ ₳ ฿ ₵ ¢ ₡ ₢ $ ₫ ₯ € ₠ ₣ ƒ ₴ ₭ ₤ ℳ ₥ ₦ № ₧ ₰ £ ៛ ₨ ₪ ৳ ₮ ₩ ¥ ♠ ♣ ♥ ♦ m² m³ ♭ ♯ ♮ © ® ™

The boxed symbols in my browser are between: ¤ & ฿, ฿ & ¢, ƒ & ₭, ₧ & £ and £ & ₨. That is five symbols that, if used on a page, would just be meaningless boxes to me, and presumably other readers also. HumphreyW (talk) 04:34, 28 September 2012 (UTC)[reply]

If you can read what it says inside the boxed-hex code, you can determine what any character is supposed to look line. Go to http://www.fileformat.info/info/unicode/char/xxxx/index.htm where xxxx is the hex value from inside the box. The characters that you have difficulty with are: ₳ ₵ ₴ ₰ and ៛ (follow the links to see what they should look like). Of these, the first four display properly for me, but the last one is the fallback boxed-hex code. This goes to show that not everybody has the same set of Unicode characters available to them. --Redrose64 (talk) 12:44, 28 September 2012 (UTC)[reply]

Are you suggesting that each time a symbol like those is used that it should link to the external site? If so, then I think that is the wrong way to solve the problem. For some of the mathematics symbols WP can generate images, perhaps it could do the same for these non-universal Unicode glyphs. HumphreyW (talk) 01:11, 29 September 2012 (UTC)[reply]

No, not at all. What I'm saying is: if you're curious, this is how to find out what they look like. I was curious to know what "៛" looks like, so I checked. It's not a symbol that I am likely to need in future, so I'll almost certainly forget about it again.

But mainly I'm saying not every user has every possible Unicode symbol among their computer's installed fonts. --Redrose64 (talk) 12:05, 29 September 2012 (UTC)[reply]

Sure, I think we can agree on that point. But what would be a way to solve the problem? Does generating an image, as is done for some of the mathematics symbols, help? I'm not sure how users like Graham87 would be able to deal with images. HumphreyW (talk) 04:18, 30 September 2012 (UTC)[reply]

Images that substitute for unicode symbols, such as {{eqm}}, should have alt text so that screen reader users can make sense of them. Graham87 10:54, 30 September 2012 (UTC)[reply]

Now that the one-half character has been removed from the edit symbols box does that mean that it is officially not valid/allowed? Do I have to go back and edit pages where I have previously put the one-half character and replace them with the frac template? HumphreyW (talk) 07:31, 1 October 2012 (UTC)[reply]

Not allowed is to big a word. 'discouraged' I would say. —TheDJ (talk • contribs) 12:04, 6 October 2012 (UTC)[reply]

My android based phone internet browser now crashes consistently with Wikipedia

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

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

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

It should be Android 2.3 (Gingerbread) per this. Biosthmors (talk) 15:35, 4 October 2012 (UTC)[reply]

Browser version 2.3.4. Biosthmors (talk) 21:26, 8 October 2012 (UTC)[reply]

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

Bizarre edit history

Tracked in Phabricator
Task T41062

The user contributions for blocked ip editor 65.28.248.135 have five blank entries. Elen of Roads said on ANI [1] they are not oversighted. Nobody Ent 22:33, 28 September 2012 (UTC)[reply]

The API only returns three results. Bugzilla time, perhaps? — This, that, and the other (talk) 05:29, 29 September 2012 (UTC)[reply]

Yeah, definately need to go to bugzilla... Although first we need to figure out what the bug in the rendering engine actually IS (It's not a bug in the API obviously...) and if it can be recreated or if it's just a one-off thing. Barts1a / Talk to me / Help me improve 23:11, 29 September 2012 (UTC)[reply]

Reported in Bugzilla. --Meno25 (talk) 08:39, 6 October 2012 (UTC)[reply]

Extreme loading times and errors due to scripts.

It's getting worse by the day and I can assure you that plenty of potential or existing editors will leave or at least do less work, like myself, since I'm not clicking on article changes if not really sure there is something more or less important to do. One editor I asked about the problem (Wikid77) taught me a new word: "Wirth's Law". That might apply to some commercial sites but sure shouldn't be needed to use in connection with Wikipedia. Not everybody has a state of the art computer available and even my quite decent laptop can't always keep up with what I call a Wiki overload of unneeded software (or whatever you profs wanna call it).
I think it's time to change this and go back in time, to a time where things were working just fine.TMCk (talk) 00:01, 29 September 2012 (UTC)[reply]

Try switching to Chrome. I was having achingly bad problems with scripts hanging, but not no more.-- Dianna (talk) 00:18, 29 September 2012 (UTC)[reply]

Using adblock plus to block geoiplookup and miniatlas.js helps with both speed and privacy. 67.117.130.72 (talk) 02:51, 29 September 2012 (UTC)[reply]

Every browser has an option to disable javascript. you can consider using it. You will get a whole lot less functionality, but there will always be a trade off. —TheDJ (talk • contribs) 13:03, 29 September 2012 (UTC)[reply]

Those are all nice meant suggestions but my question is not what can I do to make wiki work better but what should wiki do to be again more user friendly. Once again, the problem is not the user but wiki.TMCk (talk) 13:36, 29 September 2012 (UTC)[reply]
Indeed, there is a lot more js in use here than is necessary, and many aspects of it are less than optimal (nevermind in combination with other aspects), but given that what we have is a bastard combination of mediawiki js, wikimedia js, extension js, wikipedia js, gadget js, and user js, what can we actually do about it, realistically speaking? -— Isarra ༆ 20:10, 29 September 2012 (UTC)[reply]
We can either remove many tools, or further optimize. But this is not an easy task. It requires many experienced JS developers to review all the code out there. So the alternative is to remove tools. Good luck with that RfC :) —TheDJ (talk • contribs) 17:34, 4 October 2012 (UTC)[reply]

I agree with TMCk. It is frustrating to have to respond to prompts to stop scripts running. I tried Dianna's suggestion of using Chrome but navigation around the edit box is not as good as it is in IE. I know virtually nothing about JS but I find it hard to believe that there aren't just a few scripts that are causing the worst problems. Don't review all the code; start by just identifying the most problematic one or two scripts and optimize or remove them. Nurg (talk) 20:20, 5 October 2012 (UTC)[reply]

Is there an image-specific alternative to Template:Media

Category:Warhammer media is being speedily renamed to Category:Warhammer images.

However, it is populated by {{media|Warhammer}}, and I can't find an alternative template to put the images in the image category. Does anyone know what template should be used? --BrownHairedGirl (talk) • (contribs) 12:49, 2 October 2012 (UTC)[reply]

Don't we usually go the other way in renaming? Anomie ⚔ 19:51, 2 October 2012 (UTC)[reply]

I'm only the clerk. --BrownHairedGirl (talk) • (contribs) 13:58, 3 October 2012 (UTC)[reply]

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

Watchlist page: Mostly used for checking/verifying changes & reverting vandalism, tracking discussions, reminder to work on an article, reminder to learn about a topic.
diff/hist/article name/username/byte-change/edit comment - those are all very useful for me. (username linked to special:contribs not to userpage)
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.
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)[reply]

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

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

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.^(talk) 15:55, 4 October 2012 (UTC)[reply]

Thanks for weighing in, everyone! This is very helpful as a starting point. Maryana (WMF) (talk) 17:10, 9 October 2012 (UTC)[reply]
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)[reply]

VisualEditor/Parsoid fortnightly update - 2012-10-01 (MW 1.21wmf1)

Hey all,

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

VisualEditor

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

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

Beyond this API work, we added a few updates. Firstly, you can now set the 'annotation' where the caret is, without a selection — i.e., you can click somewhere, type Ctrl+B (or press the 'Bold' icon) and start typing with the text appearing bold (33140). We also now switch around the order of the undo and redo buttons for right-to-left languages (38548). Finally, we fixed a bug where applying a link to some text would remove any other 'annotations' (such as bold or italics) already set on it (40337).

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

Parsoid

JavaScript implementation:

Many improvements to template round-tripping and DOM source range calculations
Reworked paragraph wrapping to be more bug-for-bug compatible with the PHP parser
Many small tokenizer and round-trip fixes
Added many new parser tests
603 round-trip tests passing, 218 to go

C++ implementation:

Basic token transformer skeletons with boost.asio integration is hooked up
New XML DOM abstraction interface for the separation of DOM-based code from used DOM library; Using PugiXML DOM backend for performance and memory footprint
Takes back seat to JavaScript prototype implementation due to resource constraints

The full list of Parsoid commits is available in Gerrit.

Hope this is helpful! As always, feedback gratefully received.

Jdforrester (WMF) (talk) 19:49, 2 October 2012 (UTC)[reply]

This is going very nicely team, well done and keep going strong. !!! —TheDJ (talk • contribs) 11:06, 3 October 2012 (UTC)[reply]

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

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) ^talk 21:22, 2 October 2012 (UTC)[reply]

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

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

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

Here's how it could look

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

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

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

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

Arbitrary break, and two things:

Oliver, you're on holiday. Go away.
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)[reply]
(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)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

leave the Save page button where it is
move Show preview and Show changes up and to the right so that Show preview is directly above Save page
move the legal text down and right so that it is adjacent to the Save page button
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
delete the Cancel button – it serves no purpose (as I've ranted on before)
move the Minor edit and Watch checkboxes right so they are near the Show changes and Show preview buttons
~~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)[reply]

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

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

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

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

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

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

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

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

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

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

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)[reply]
  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)[reply]
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)[reply]
  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)[reply]
  
  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)[reply]
  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)[reply]
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)[reply]
  Those are not intended changes in this iteration. Vibhabamba (talk) 17:29, 3 October 2012 (UTC)[reply]

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

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

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

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)[reply]
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)[reply]
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)[reply]
Are you not using the agora library? -— Isarra ༆ 15:11, 8 October 2012 (UTC)[reply]
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)[reply]
Good point; we're including it now :). Okeyes (WMF) (talk) 14:24, 8 October 2012 (UTC)[reply]
- 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 ^{(Talk • Contribs)} • 9:43am • 23:43, 4 October 2012 (UTC)[reply]
  - 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)[reply]
  - 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)[reply]

Was my intermediate-header issue addressed?...

Tracked in Phabricator
Task T42763

Long tables with a lot of individually low-information entries (like the Vampire Traits page) could really use intermediate headers or framing or something to help people keep track of what's going on, but if you insert them manually it messes up sorting. Any help for that?... — Preceding unsigned comment added by Tamtrible (talk • contribs) 22:14, 2 October 2012 (UTC)[reply]

Your old section is at Wikipedia:Village pump (technical)/Archive 103#adding extra headers to a table... PrimeHunter (talk) 22:47, 2 October 2012 (UTC)[reply]

So, the only available solutions are my clumsy ideas that should kindasorta work? Tamtrible (talk) 15:32, 3 October 2012 (UTC)[reply]

Or someone needs to improve the tablesort software, to repeat headers automatically or at least understand them. It's possible, but will require some work. —TheDJ (talk • contribs) 07:26, 4 October 2012 (UTC)[reply]

'k. (I am not that someone, I have no programming know-how). If someone could do that, that'd be cool... I'll try to keep an eye out here to see if someone's done that... Tamtrible (talk) 09:39, 4 October 2012 (UTC)[reply]

I filed a feature request in 40763 but it might take quite long for someone to get around to it. —TheDJ (talk • contribs) 10:38, 4 October 2012 (UTC)[reply]

HTML 4.0 introduced the THEAD, TFOOT and TBODY elements; the idea was that in a table, the header row(s) would be enclosed in the <THEAD>...</THEAD> and each group of data rows would be enclosed in a <TBODY>...</TBODY>. This way, browser features could be written in such a way that if the rows enclosed by one of the <TBODY>...</TBODY> were manipulated in some way (by scrolling, sorting, collapsing, etc.) the rows enclosed by <THEAD>...</THEAD>, <TFOOT>...</TFOOT> and other <TBODY>...</TBODY> would remain static. Additionally, when printing, the rows enclosed by <THEAD>...</THEAD> could be repeated at the top of each new page, and those enclosed by <TFOOT>...</TFOOT> would be printed at the bottom of each page.

The MediaWiki software doesn't emit these elements, so a Wikipedia table is essentially a single <TBODY>...</TBODY>. I don't know of any browsers that make use of these elements except as grouping elements intermediate between DIV and SPAN (i.e. for applying class or style). --Redrose64 (talk) 15:46, 4 October 2012 (UTC)[reply]

Despite the lack of support in wikitext, the current tablesorter javascript (activated with table class "sortable") automatically converts mediawiki output to wrap header rows in <thead>...</thead>, and footer rows in <tfoot>...</tfoot> (presumably to identify them as non-sortable), with everything in between wrapped in <tbody>...</tbody>. The routine seems to identify header/footer rows as the row(s) at the beginning/end containing <th> and no <td> elements (or the wikitable markup equivalent). — Richardguk (talk) 16:54, 4 October 2012 (UTC)[reply]

Correct. it's not 100% perfect, but good enough for sortable tables. —TheDJ (talk • contribs) 23:20, 4 October 2012 (UTC)[reply]

Thanks for filing the feature request. Though, basically, there might be another way to handle it... there doesn't necessarily need to be a fixed header at the top, if there's a way to insert new headers but have them ignore sorting. Either a way to make the table automatically repeat the header every 20 (or whatever) lines, or a way to make manually inserted headers ignore sorting. The header doesn't need to be at the top for you to be able to follow it, it just needs to be *somewhere* that you can see it without scrolling up 3 pages. That might be easier than a header that stays at the top of the screen regardless of where in the table it is, since it only involves fiddling with how the table is *created*, rather than how it displays. I don't have an account on Bugzilla, so if you'd be willing to write a note to that effect (feel free to copypaste my note), that would be lovely... Tamtrible (talk) 17:50, 4 October 2012 (UTC)[reply]

I started an initial attempt with User:TheDJ/jquery.stableTableHeaders.js it works, but it needs more work to nicely co exist with sortable tables. —TheDJ (talk • contribs) 23:20, 4 October 2012 (UTC)[reply]

Edit buttons in Monobook

Some of the buttons (small and subscript) seem to have disappeared from the edit window in monobook. Is there some reason for this. I am using the old style edit window. Spinning Spark 23:09, 2 October 2012 (UTC)[reply]

Krinkle made some change and it seems he accidently missed those two buttons. I added them back. A purge of your browsercache should bring them back. —TheDJ (talk • contribs) 11:03, 3 October 2012 (UTC)[reply]

Thanks, I just could not work out where that was. I found Monobook.js but did not think to look at Common.js. I had assumed that the old editor was special to Monobook. Spinning Spark 10:35, 4 October 2012 (UTC)[reply]

What is Required to Release a Photo Under a Creative Commons 3.0 Attribution License?

Hi All,

I have a friend who has a very bad photo of herself posted on her Wikipedia page. She has provided me with a better photo, to which she owns the rights, and she has indicated that she would be willing to release it under a Creative Commons 3.0 Attribution license. However, she doesn't have a Flickr account or an account on another photo hosting site that would allow her to release it in that manner. She is not highly technical. What is the easiest way for her to release the photo? Can she do so via an email to me? Via a signed letter? Is there somewhere on the web she can post the photo, without having to create an account under her own name, and release it? Any help would be greatly appreciated. Thanks! Ebikeguy (talk) 03:46, 3 October 2012 (UTC)[reply]

She should follow the process set out at WP:IOWN to e-mail her permission to Wikipedia.--ukexpat (talk) 03:57, 3 October 2012 (UTC)[reply]

(edit conflict) You can upload the photo to Wikimedia Commons using the old upload form at commons:Special:Upload, putting {{OTRS pending}} in the "Permission" box as described on that page. Have her fill out our WP:CONSENT form (including the URL or filename of the uploaded image) and send it to permissions-commons@wikimedia.org. A volunteer will review the form, and if everything is OK, he or she will confirm the permission on the image's description page.

By the way, this forum isn't really the proper place for these sorts of questions; if I didn't know the answer, I would have asked at Wikipedia:Help desk. PleaseStand (talk) 04:11, 3 October 2012 (UTC)[reply]

Or at WP:Media copyright questions.--ukexpat (talk) 12:56, 3 October 2012 (UTC)[reply]

Help needed to remove default to placeholder image

Template:Infobox named horse (edit | talk | history | links | watch | logs) will default to an ugly placeholder image if no image is added to the infobox. Everybody (well ok - two editors) want the placeholder removed. See the talk page. Placeholder images tend to be frowned upon in many situations. -- Alan Liefting (talk - contribs) 09:12, 3 October 2012 (UTC)[reply]

I think this edit worked. -- John of Reading (talk) 09:53, 3 October 2012 (UTC)[reply]

Yep. That's done it. See Dream Flyer. Cheers. -- Alan Liefting (talk - contribs) 09:55, 3 October 2012 (UTC)[reply]

I removed an extra }} you left in there.[2] PrimeHunter (talk) 10:02, 3 October 2012 (UTC)[reply]

Is there a usable monobook .js skript

Hi, I'm searching for some usable skipts for monobook, as I have in german wp. --WSC^® 10:15, 3 October 2012 (UTC)[reply]

Well, there are many user scripts here, and I think you should be more specific in what you want a script to do, but you can find some useful scripts in the corresponding WikiProject. --intforce (talk) 13:34, 6 October 2012 (UTC)[reply]

Is Toolserver down?

For at least the last 90 minutes, I've been unable to connect to both these two on Toolserver

Initially, it was just its usual "Waiting for Toolserver". Then I was getting a Timed Out message. Then it said Unable to Connect. Another message was "500 Internal Server Error nginx/1.0.4" And right now, the message for the last hour is that the connection was reset and is temporarily unavailable. Maile66 (talk) 14:09, 3 October 2012 (UTC)[reply]

The links seem to be working now.

See http://status.toolserver.org/ for current status of the various Toolserver services.

For Toolserver resourcing issues, see Wikipedia:Wikipedia Signpost/2012-10-01/Technology report#WMF and the German chapter face up to Toolserver uncertainty and discussion.

— Richardguk (talk) 16:29, 3 October 2012 (UTC)[reply]

Thanks. I had read that in the Signpost. What a coincidence this morning. Maile66 (talk) 19:29, 3 October 2012 (UTC)[reply]

Suggestion for programmers - finding images

Copied from the Help Desk of October 3:

Title: Suggestion for programmers - finding images

I was searching for an image and I tried the following terms in the search box...

488824530.jpg
File:488824530.jpg
File:Vol 488851659.jpg
File:Ap cov 488824530.jpg
Image:Bott 488824530.jpg

Could the programmers at Wikipedia make the search process a little more intuitive and forgiving?

Or has this image actually been deleted? In that case, wouldn't it be more helpful to tell the user? And more important, shouldn't old images be preserved (even if not used in an article) so that prior copyrights can be examined?

Last questions: where to put suggestions for Wikipedia programmers? Do they read this page? (posted by me)

File:Ap cov 488824530.jpg was deleted because of a copyright violation. All the intuitive and forgiving programming in the world cannot find an image that does not exist on a website. BTW, you can search for a filename at http://www.google.com/advanced_search?hl=en by entering the file name in the search field and specifying en.wikipedia.org in the domain field. As for "preserving" old images, that depends on why they may have been deleted. Images that have copyright restrictions and not licensed for use by Wikipedia cannot be kept for legal reasons. (posted by user Cresix)

And to answer your last question, see WP:VPT for adding suggestions for the Wikipedia programmers. (posted by user Dismas)

Helpful response, thank you. Cresix, your answer goes to my point that the Wikipedia interface should return *something. You must have had a magical way of knowing that 488824530.jpg was deleted. How does a typical user know this? Wikipedia must store this information somewhere and it really should be reported to a searcher. I will post this issue to Village pump (technical). By the way, an advanced Google search for "488824530.jpg" in the W ikipedia domain returns no results. (posted by me)

— Preceding unsigned comment added by User:3dimen (talk • contribs) 15:04, 3 October 2012 (UTC)[reply]

Well it's likely that you also uploaded the image you ask questions about. As such Cresix probably looked at your talk page first. Here is a notification (so you WERE notified of deletion) of the upcoming possible deletion of the file File:Ap cov 488824530.jpg. When you click that redlink to the file, you get a page with "A page with this title has previously been deleted". However I think it might be a good idea if users were able to find back their OWN deleted contributions straight in their user contributions list. Would make it a bit easier. Someone can file a request in bugzilla. —TheDJ (talk • contribs) 18:33, 3 October 2012 (UTC)[reply]

I can say with some certainty that that change has been (at least informally) RFCd in the near past, with a large number of people not supporting the change for anti-vandalism reasoning (at the very least). --Izno (talk) 22:40, 3 October 2012 (UTC)[reply]

I'm surprised. As an administrator, I often wish that I could search for deleted pages because I need to see deleted revisions for one reason or another, and it's sometimes hard to remember precise page names. The problem in question would be resolved if non-admins had the ability to view a list of deleted contributions. Imagine if admins and non-admins had the same list of deleted contributions, except that non-admins couldn't see any of the content or edit summaries for the deleted edits, and admins could check a box to prevent a page from appearing on the list if necessary, e.g. for Hagger-style pagemove vandalism. It wouldn't risk the dangers that WMF counsel mentioned would arise if we permitted universal access to all deleted content, since only page names (many of which are already mentioned on user talk pages already) and metadata such as oldids, dates, and numbers of bytes added or removed would be publicly visible. Nyttend (talk) 01:00, 4 October 2012 (UTC)[reply]

Dear people: As the original poster of this problem over on the Help pages, I have been getting a lot of advice on how to find the names of the deleted files. But everybody is missing the point. Please allow me to summarize my final thoughts which I posted over there...

* Point taken that the names of my photos were not useful. It was four years ago and I thought I had assigned proper names but apparently I hadn't.

* All of the above discussion results in very limited information: basically who deleted the file and why. This is not what I am ultimately looking for. In my original post, I tried to communicate that I want to look at the prior copyrights (meaning the original licensing information that I provided way back then). I feel my hands are tied because this information is apparently not available to me without going to an administrator. I was hoping the Deletion log would provide this but apparently not.

* To be precise, clicking the red link on my user page takes me not to the deletion log, but to a Creating file page, which indicates the page once existed but has been deleted. No links to the original File: page.

* Again, to be precise, looking at a previous version of the article and clicking on the file name only gives me a File Upload Wizard. Again, no links to prior licensing information.

* I must stand by my claim that this is not user friendly. If Wikipedia feels they need to delete an image, OK, but just delete the jpg itself and keep the rest of the File: page that was associated with it. The only price Wikipedia is going to pay is that a unique file name is used up - no big deal. Also make sure the main search box and the Deletion log "search box" point to this page.

How do I know if an RFC is filed on this? Thank you for listening. 3dimen (talk) 08:53, 4 October 2012 (UTC)[reply]

'want to look at the prior copyrights' this is a valid point, but unfortunately that information is not kept separate from other information at the moment so we cannot avoid it being deleted. However ANY administrator will gladly provide this information to you. There have been plans to separate license information for images from the other images, but it is a very complex task to implement this properly in the software and migrate all existing copyright information into this. In this particular case, you indicated "cc-by-3.0". This probably matched the flickr license indication back then, however this image is a clear case of 'flickr washing'. So a flickr user marking a file with the wrong license, stating it is free while it is clearly not a freely licensed image and often it is very unlikely that the flickr user owns the image.
'clicking the red link ... indicates the page once existed but has been deleted' As I stated indeed. For me this page also includes the deletion log of the file. It does not for you ?
'clicking on the file name only gives me a File Upload Wizard' Unfortunately a case where one improvement leads to problems for other users. The upload wizard is something specific to the English Wikipedia. When the 'normal' but less friendly upload process is used, you DO get a warning that this file has previously been deleted.
'this is not user friendly' I don't think anyone disagrees with you. The issue is to create proper plans to fix it, actually finding someone ABLE to implement the plans and then guiding it all trough the system towards it's final deployment, then dealing with all of the users who will get angry because 'something changed'. That's a lot of work and someone has to do it. And as you most people here are volunteers :D —TheDJ (talk • contribs) 10:33, 4 October 2012 (UTC)[reply]

Filed a feature request to make the list of deleted contributions visible if the creator == the logged in user. That might at least partially help. —TheDJ (talk • contribs) 17:49, 4 October 2012 (UTC)[reply]

Special:Log includes upload logs for deleted files, for example Special:Log/3dimen. The "uploads" link on user contributions pages goes to Special:ListFiles where deleted files are not shown, for example the empty Special:ListFiles/3dimen. By the way, a deletion tag log was recently added. Special:Log/pagetriage-deletion shows deletion tagging, also for deleted pages, but only since the log was created in September. PrimeHunter (talk) 22:40, 4 October 2012 (UTC)[reply]

Layout problem when printing references with long URLs.

A user described to me a bug (on a private mailing list) that when he printed Metric_system and Gaussian_units, they printed in different sized fonts. I was able to reproduce this behavior on my Mac in Chrome and Safari, but not Firefox. Eventually, I was able to track this down to a very long URL in a reference. It looks like Chrome and Safari just keep shrinking the font (for the entire page) until the URL can fit on a line.

I was able to generate a minimal test case (http://en.wikipedia.org/w/index.php?title=User:RoySmith/Metric_system&oldid=515805875)

I'm not quite sure if this is a wikipedia style sheet bug, or a browser bug, or a webkit bug, or even an intentional behavior. Any ideas?

-- RoySmith (talk) 16:01, 3 October 2012 (UTC)[reply]

Better now ? I added a line to tell it to forcefully break URLs if they don't fit. —TheDJ (talk • contribs) 18:21, 3 October 2012 (UTC)[reply]

Cool, thanks! -- RoySmith (talk) 18:54, 3 October 2012 (UTC)[reply]

RSS/Atom Feed

Hi, when I am on my watchlist, in the toolbox to the left is an atom feed. My blackberry has a feed application so is there a way to get my watchlist on my blackberry feed? I tried puttin a whole bunch of urls but I kept getting error messages. Any help?--Dom497 (talk) 20:20, 3 October 2012 (UTC)[reply]

Can you specify the error message? The URL should look something like https://en.wikipedia.org/w/api.php?action=feedwatchlist&allrev=allrev&wlowner=Dom497&wltoken=d234567f456789e098765a56789b&feedformat=atom (token is indeed incorrect), so maybe you didn't copied not the full URL? Does Blackberry support Atom feeds? Maybe it only supports RSS web feeds! mabdul 06:38, 5 October 2012 (UTC)[reply]

Inline linking offsite images

Resolved

I'm pretty sure that I've read that our code enabled inline linking of images at one time, but it was disabled because of the potential for abuse of copyright, shock images, etc. Can someone provide me with a link that shows how it worked, either a MW help page or a diff of a page that was set up to do this? I'm active on a small wiki whose version of MW enables inline linking of Google Maps with a <googlemap> extension that we don't have here, and I'm wondering if such an extension might be related to an inline linking extension. I was going to ask User:Manning Bartlett, since he should remember, but he's not been very active lately. Nyttend (talk) 00:53, 4 October 2012 (UTC)[reply]

See mw:Manual:$wgAllowExternalImages. mw:Manual:$wgEnableScaryTranscluding may also be of interest. PrimeHunter (talk) 01:07, 4 October 2012 (UTC)[reply]

A quick page test shows that the wiki in question doesn't permit inline linking, which is too bad, since I have tons of images on Commons that would be useful over there, and it's not part of the WMF family. Thanks for the help! Nyttend (talk) 01:45, 4 October 2012 (UTC)[reply]

I just started to wonder — what if something could be turned on at the small wiki to make it display Commons images as if they were locally uploaded, just like we do here. Is that something that could be done with a little code change at the other wiki? Or would Commons (and/or some other WMF site) need to enable this type of linking? It might help if you could point me to a page explaining how the various WMF sites are set up to use Commons images. Nyttend (talk) 01:48, 4 October 2012 (UTC)[reply]

Never mind; I found mw:InstantCommons. Nyttend (talk) 01:50, 4 October 2012 (UTC)[reply]

I don't know their settings or policies but mw:Manual:$wgEnableImageWhitelist may also be relevant if it's already enabled and only requires an admin to whitelist Commons. PrimeHunter (talk) 01:56, 4 October 2012 (UTC)[reply]

All I was meaning was "is it technically possible". I've contacted the Jimbo equivalent to ask for the feature to be turned on, since he's the sole developer. Nyttend (talk) 02:42, 4 October 2012 (UTC)[reply]

(edit conflict) There is absolutely no relationship between core MediaWiki's external image linking feature and the Google Maps extension. The two even run during distinct phases of the parsing process. (Tag extensions run during preprocessing, the parsing stage in which template expansion takes place. In contrast, external links are processed much later, although the extension does manipulate the fully rendered HTML after that is done.) PleaseStand (talk) 02:05, 4 October 2012 (UTC)[reply]

... although in MediaWiki 1.17, an option was added to allow HTML img elements. PleaseStand (talk) 02:15, 4 October 2012 (UTC)[reply]

Picture posting problem

I am trying to post a JPG photo on Wikipedia but only the name of the file appears - not the actual image.

Any ideas of what I am doing wrong?

Thanks — Preceding unsigned comment added by Barkerpj (talk • contribs) 06:22, 4 October 2012 (UTC)[reply]

Posted by Barkerpj (talk · contribs)

Your uploads are File:Greg Flynn.jpg and File:Greg Flynn - author.jpg. Earlier you had an upload File:Greg Flynn Berlin Cross.jpg which was deleted because the picture was moved to commons. I don't know what happened to that. I updated the image name to your new upload. Graeme Bartlett (talk) 11:38, 4 October 2012 (UTC)[reply]

Semi-protected articles and new editors

A new (non-auto-confirmed editor) asked me to help her with the Nina Burleigh article which she could not edit. I found the following:

Looking at the article, it doesn't appear to be semi-protected. The lock icon is not displayed (her experience too).
When one clicks on "Edit", it is apparent that the article is semi-protected, as the following message is displayed:
- Note: This page has been semi-protected so that only autoconfirmed users can edit it. If you need any help getting started with editing, see the New contributors' help page.
This message is, however, not helpful at all because non-auto-confirmed editors can't see it - they can't click on "Edit" in the first place.
As a consequence, one would expect new editors to be confused and possibly frustrated because the article's status is unclear, and it is not apparent what - if anything - could be done to remedy the situation.

Is something broken here, or I'm missing something? GregorB (talk) 13:21, 4 October 2012 (UTC)[reply]

The lock symbol is added manually with {{pp-semi-blp}} or another protection template. It was removed in this edit. Users who cannot edit a page see a "View source" tab instead of "Edit". Log out to see it. "View source" has the same url as "Edit". Users will see MediaWiki:Protectedpagetext if they click it, but the tab name "View source" does not encourage clicking if you want to edit and don't know the system. PrimeHunter (talk) 13:37, 4 October 2012 (UTC)[reply]

Thanks - makes sense now... You are right about "View source" - it works, but it's far from obvious. I've reinserted {{pp-semi-blp}} - looks ominous, but new editors are definitely confused without it. The entire mechanism looks a bit crude to me. This is food for thought: it can be really hard for the newcomers, even in such straightforward situations, and 99% of established editors (myself included) are unfortunately not fully aware of this fact. GregorB (talk) 14:05, 4 October 2012 (UTC)[reply]

The tab name "View source" could be changed at MediaWiki:Viewsource, or on a ~~namespace~~ skin basis at for example MediaWiki:Vector-action-viewsource. There is old discussion at MediaWiki talk:Viewsource. PrimeHunter (talk) 14:15, 4 October 2012 (UTC)[reply]

Oh, so it did read "View source" beforehand? Interpreting the comments above to mean that something was wrong with the display, I unprotected it and immediately self-reverted. Nyttend (talk) 14:44, 4 October 2012 (UTC)[reply]

Yes, MediaWiki automatically chooses between displaying MediaWiki:Viewsource and MediaWiki:Edit (I haven't seen reports of bugzilla:27978 since MediaWiki 1.18 was introduced in the English Wikipedia 5 October 2011). The only error was the missing protection template. Non-protected pages with a protection template are shown in Category:Wikipedia pages with incorrect protection templates and sometimes fixed by User:DumbBOT and maybe other bots. I don't know an automatic way to find protected pages with no protection template. Maybe a tool could compare Special:ProtectedPages (MediaWiki-generated) to subcategories of Category:Wikipedia page protection (usually template-generated), but it sounds expensive. PrimeHunter (talk) 15:16, 4 October 2012 (UTC)[reply]

"The only error was the missing protection template." Quite correct. Still: 1) since forgetting to include it may lead to unpleasant experiences for new editors (and possibly a degree of confusion to others), it would be nice to try and prevent this error in some fashion, and 2) including it does the job in a rather inelegant and visually unappealing way; maybe the interface should warn you the article is protected, rather than its content. GregorB (talk) 18:13, 4 October 2012 (UTC)[reply]

Okay, I thought that there had been some sort of error in the protection process. Nyttend (talk) 23:20, 4 October 2012 (UTC)[reply]

I have long been a fan of changing MediaWiki:Viewsource to simply read "Edit". However there is a valid argument to NOT do this and it's that you loose the visual cue that the page is protected, which many people would miss. So we would have to add some styling (append a lock icon?) to that tab in all skins to make it clear visually for those who DO know that the page is locked. If anyone has any bright ideas on that. Oh, and we need a cue for blind users as well... —TheDJ (talk • contribs) 17:09, 4 October 2012 (UTC)[reply]

The flip side is that many, if not most, of our most popular articles don't have an edit button on them for the indefinite future. That's kind of a disaster for communicating to readers that this is the encyclopedia anyone can edit. I would be in favor of a middle ground such as "Contribute", since the alternative methods of an edit request or simple talk page thread is at least potentially a contribution to the article, even if you can't edit. Anyway, copy discussion aside, this is a workflow for entering Wikipedia that my team is paying a lot of attention to right now. When we look at things like the articles that people are coming to account creation from, a decent chunk of them are from semi-protected articles. Steven Walling (WMF) • talk 18:22, 4 October 2012 (UTC)[reply]

Four primes and six primes

Please look at this edit. The display is messed up due to four adjacent primes (twice toggling italics) mechanically inserted but being misinterpreted on display.

I feel that the edit is in fact logical, and that the display of four primes should be changed, so:

one prime: display as prime ['abc']
two primes: toggle italics on/off [abc]
three primes: toggle bold on/off [abc]
four primes: elide (interpret as two sets of two primes: new) ['abc'] (currently: a prime then toggle bold)
five primes: toggle each italics and bold [abc]
six primes: elide (interpret as two sets of three primes: new) ['abc'] (currently: a prime then toggle bold and italic)
seven or more primes: change? (currently: the last five primes toggle bold and italic)

The interpretation of four primes as a prime followed by a bold toggling is of little use, and illogical since the order cannot be swapped. — Quondum 14:11, 4 October 2012 (UTC)[reply]

Meanwhile, I improved AWB's logic to first merge html italics and bold tags and then replace with wikimarkup to reduce this kind of problems. -- Magioladitis (talk) 14:47, 4 October 2012 (UTC)[reply]

Change might impact thousands of articles: Changes such as re-defining the typesetting directives for multiple apostrophes (primes or tics) can have a vast impact, and currently, the treatment of 4 as apostrophe+bold does seem logical in comparison to the common form of quote+bold (" ' ' '), to be unbolded as 3+space+1 apostrophe. In cases where 2 sets of 2 apostrophes coincide, then perhaps separate with a null-nowiki tag ("<nowiki/>"), such as in template parameters which would join together, where each could have double-apostrophe ends. The concept of "continual improvement" does not mean "continually change everything" but rather, to change aspects which would have a significant improvement to overall quality, as prioritized to make the most-helpful changes or enhancements first, where possible. It would be difficult to prove that 4 apostrophes treated as 2 pairs (' ' & ' ') is better, since an accidental 4th apostrophe, after 3, now can be seen as a spurious extra " ' " whereas treating as 2 pairs would make 3+1 seem like a non-functional bold. When seeking improvements, also consider how incorrect usage of the new feature might be more confusing than the prior feature, such as 4-apostrophe form treated as 2 pairs would do nothing rather than show a spurious extra " ' ". Plus, also consider the impact of a proposed change, with retro-formatting, in many thousands of prior articles. -Wikid77 (talk) 23:49, 4 October 2012 (UTC)[reply]

I expected some of this reaction. We actually have no idea of whether there will be many articles affected ("vast impact") without analysing them. The comparison of a bold with a double quote doesn't work at both ends of a quote, as I already pointed out (one single quote will be bold the other not). However, I'm sure there would have to be a demonstrable benefit before a global change would be considered. — Quondum 14:49, 5 October 2012 (UTC)[reply]

This is MediaWiki markup. MediaWiki is used by thousands of wikis. We have no way to tell how many problems it would cause other wikis to suddenly change it. If we could get developers to make a configurable meaning of four primes with a non-default setting in Wikipedia then it would confuse lots of people who edit multiple wikis powered by MediaWiki. Another problem it's hard to determine the scope of: Some pages accidentally have 4 primes instead of 3 to start or end a bolding, but only at one of the ends. This only causes a prime to be displayed now, while your change would often cause a lot of text to be bolded. But if we were designing MediaWiki from scratch then I would still prefer the simple rule that at least 3 primes give a bold, and then the remaining primes can count as other things. It's a common principle that you first try to match as large a part as possible to the syntax rules. PrimeHunter (talk) 15:27, 5 October 2012 (UTC)[reply]

Hmm. Broader than I realized... Suggestion withdrawn. Actually, any primes-only system has inherent ambiguity under general substitutions without considering adjacent symbols; a "consistent" redesign would have to be more sophisticated. — Quondum 21:19, 5 October 2012 (UTC)[reply]

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

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

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

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 ^{[Deliberation needed]} 09:27, 6 October 2012 (UTC)[reply]

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

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

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

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

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

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

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

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

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

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

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

Table shows up in wrong section

At Pete Seeger the table that is placed in the "selected discography" section does not show up there but instead shows up in the "Quotes" section (browser = Firefox). Can anyone figure out / fix? Thanks North8000 (talk) 22:57, 4 October 2012 (UTC)[reply]

Done. GregorB (talk) 22:59, 4 October 2012 (UTC)[reply]

Thanks! North8000 (talk) 13:04, 5 October 2012 (UTC)[reply]

Picture upload problems ?

I'm getting :
'Could not read or write file "mwstore://local-multiwrite/local-public/6/66/SweeneyAstray.jpg" due to insufficient permissions or missing'directories/containers.
Any ideas ?
GrahamHardy (talk) 13:03, 5 October 2012 (UTC)[reply]

According to Ariel on wikitech-l: "We're going to swap out ms7, the current media server fallback, for a netapp. We'll start this on Friday Oct 5 at 11am UTC, to conclude at 2pm UTC or earlier. This will entail turning off uploads to all projects during the switchover. It is possible that ExtensionDistributor and captchas will be affected during this time as well; other services should be fine." Sounds like something is/was not configured right. Is it working OK again? — Richardguk (talk) 13:38, 5 October 2012 (UTC)[reply]

Now OK, Thanks GrahamHardy (talk) 13:46, 5 October 2012 (UTC)[reply]

Note in case of further issues: Friday's server uploading update was cancelled after technical problems but has been rescheduled for 11:00–14:00 (UTC) on Monday. — Richardguk (talk) 03:50, 7 October 2012 (UTC)[reply]

Something wrong with Semi-protected and protected edit request categories as of 2 October

Anyone know what's up at semi-protected edit requests or the edit requests categories? The template usages at the bottom of the page seem to be added correctly, but the boxes at the top that list the request along with reason for protection seem to have stopped updating around 2 October. This disconnect may be part of the reason why edit requests are taking longer than usual to process, which was the subject of an ANI. Sailsbystars (talk) 15:52, 5 October 2012 (UTC)[reply]

The category pages transclude User:AnomieBOT/SPERTable and User:AnomieBOT/PERTable. They have not been updated by User:AnomieBOT since 2 October. I don't know why. You can contact the bot operator at User talk:Anomie. PrimeHunter (talk) 16:07, 5 October 2012 (UTC)[reply]

The OOM Killer on AnomieBOT's server apparently killed some of its processes. I'll have to think about some way to make such problems clearer for myself in the future. Anomie ⚔ 19:33, 5 October 2012 (UTC)[reply]

Recent changes - new pages

I see this has changed. How do I now get a list of new articles I created? I used to be able to filter the article and category space to see a flat-text output of what I've done over the last 7/30 days. Thanks. Lugnuts ^{And the horse} 12:57, 6 October 2012 (UTC)[reply]

Do you have JavaScript enabled and have you clicked on "Set filters" at Special:NewPagesFeed? PrimeHunter (talk) 13:47, 6 October 2012 (UTC)[reply]

Yes and yes. I can get the new-look list for new articles I've created, but I can only search across the main article space and not at category (or template) level. Lugnuts ^{And the horse} 09:17, 7 October 2012 (UTC)[reply]

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? Spinning Spark 16:47, 6 October 2012 (UTC)[reply]

new edit window makes me a) wanna leave wikipedia 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)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

WikiProject discussion pages ranked by liveliness

How would I get a list of discussion pages of WikiProjects (so I'm talking about pages called "Wikipedia talk:WikiProject Whatever") ranked by the frequency with which they are edited---in effect the most active WikiProjects listed first? Michael Hardy (talk) 01:27, 7 October 2012 (UTC)[reply]

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

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

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

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

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

This occasionally happens to me (I'm using the blue and yellow diff colors), but reloading the page always seems to fix it. David 1217 ^{What I've done} 16:18, 7 October 2012 (UTC)[reply]

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

common.css file

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

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^(talk) 18:24, 7 October 2012 (UTC)[reply]

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 [[User:<Your User Name>/common.css]] these days for anything that is not skin specific. —TheDJ (talk • contribs) 18:31, 7 October 2012 (UTC)[reply]

Good point on common.css. Regards, Sun Creator^(talk) 18:39, 7 October 2012 (UTC)[reply]

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

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

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

Tracked in Phabricator
Task T42856

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

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

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

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

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 Wikipedia itself which is at wikipedia.org. The two sites are run differently. Special:Preferences here at Wikipedia is fast but only has a total "Number of edits" field with no details. PrimeHunter (talk) 22:19, 7 October 2012 (UTC)[reply]

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

Problems saving and using preview

Just noting here that I'm having problems today using preview and saving. Preview and diffs are painfully slow and I'm getting lots of time-outs (Wikimedia error messages). I've also had the error messages when I've tried to save. SlimVirgin ^(talk) 17:36, 7 October 2012 (UTC)[reply]

There have been some server issues with database access. Leslie was looking at it (from the airport) and it seems to have stabilized a bit. —TheDJ (talk • contribs) 17:44, 7 October 2012 (UTC)[reply]

Same problem here, been going on for several hours. Watchlists loads normally for some reason as does access via WP:AWB. Regards, Sun Creator^(talk) 18:10, 7 October 2012 (UTC)[reply]

I got the error page repeatedly on trying to save an edit, although in checking the page history now I see that my changes were saved. I got the error page again when I tried to log back in an hour later (about 10 minutes ago). Saves are taking an unusually long time and pop-ups are hardly working at all, but everything else seems to be loading normally. Rivertorch (talk) 18:13, 7 October 2012 (UTC)[reply]

Opening my preferences and many other pages is oftentimes slow too. I just enabled "Use live preview (requires JavaScript) (experimental)". In hopes of faster previews. But I don't notice anything with it. What am I missing? I clicked Ctrl-Shift-R also. Still see no difference in previews.

After a Google search I found this: User:Js/ajaxPreview. It says this at the bottom of the page: Option "Use live preview (requires JavaScript) (experimental)" in preferences does AJAX preview/changes (using standard buttons at the bottom) but it requests the whole HTML page from the server (no traffic savings there).

So I guess I will have to try the other choices listed there in order to avoid traffic to the server. --Timeshifter (talk) 18:16, 7 October 2012 (UTC)[reply]

Currently having timeouts on previewing and submitting edits as well. Silverseren^C 18:18, 7 October 2012 (UTC)[reply]

I'm having problems with slow server function too. --Tryptofish (talk) 18:20, 7 October 2012 (UTC)[reply]

This is almost the exact same problem I'm having, it takes forever and times out a lot. Go Phightins! (talk) 18:21, 7 October 2012 (UTC)[reply]

We had issues with our old fallback media storage server (the one we're replacing on Monday), causing cascading issues on the cluster. The outage affected editors and readers viewing uncached pages. Everything should be back to normal.--Eloquence * 20:05, 7 October 2012 (UTC)[reply]

It is back to normal for me. Thanks. --Tryptofish (talk) 22:28, 7 October 2012 (UTC)[reply]

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

Resolved

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

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

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

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

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

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

/* ********** REMOVE ELEMENTS IN THE LEFT HAND SIDEBAR ********** */
/* Gets rid of the Wikipedia 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 Wikipedia" */
li#n-sitesupport
{ display: none; }
 
/* Remove "Wikipedia Shop" */
li#n-shoplink
{ display: none; }
 
/* Remove "About Wikipedia" */
li#n-aboutsite
{ display: none; }
 
/* Remove "Contact Wikipedia */
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)[reply]

You had correct code in [4], 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)[reply]

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

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

The commons:MediaWiki:IPadSidbarSlider.js might be useful. See also bugzilla:14501. Helder 15:50, 8 October 2012 (UTC)[reply]

Non existing template linking issues!

In last 3 days I have seen 3 non-existing template issues. Any recent changes? Or old problem?
Go here G._Sankara_Kurup#External_links and click on the "V" at the templates' upper left corner. The template does not exist, actually editors have made some errors in template (title etc) I think! If you can not see any problem, see older version, someone has fixed error in between. --Tito Dutta ✉ 23:18, 7 October 2012 (UTC)[reply]

Template vandalism, I fixed it. Ryan Vesey 23:22, 7 October 2012 (UTC)[reply]
Excellent! But the view, edit, talk should be linked to page URL and not page title, so that it does not get broken even after changing the title etc. Is not it? --Tito Dutta ✉ 23:34, 7 October 2012 (UTC)[reply]

There is no automatic way to get the right link with the current software. When the template code is transcluded in G. Sankara Kurup, it doesn't know that it was transcluded from Template:Jnanpith Award. That's why the template has the line name = Jnanpith Award (which is independent from the title displayed by the template). I have thought about making a bot request to periodically check and fix name parameters in navigation boxes which should link to themselves. PrimeHunter (talk) 00:58, 8 October 2012 (UTC)[reply]

WP:Copyright_problems hitting Post-expand include size

Looking at Wikipedia: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)[reply]

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

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

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

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

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

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

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

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

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

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

File:Monobook.css.png also shows lowercase in 2008. PrimeHunter (talk) 23:49, 8 October 2012 (UTC)[reply]

Problem on Special:UserLogin?

Tracked in Phabricator
Task T42789

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

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

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

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/wiki/User:Xh286286/temp2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This one:

--Redrose64 (talk) 18:45, 9 October 2012 (UTC)[reply]

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

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

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)[reply]
Or on a second thought, are both the cite links getting affected at the same time? --Tito Dutta ✉ 05:57, 10 October 2012 (UTC)[reply]

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

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

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

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 wikipedia (talk) pages when these pages get archived? bamse (talk) 19:45, 9 October 2012 (UTC)[reply]

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

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

I guess you mean Navigation popups at Special:Preferences#mw-prefsection-gadgets. Wikipedia: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)[reply]

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

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

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

See

bug 29301 - gadgets for anonymous users (WONTFIX)

Helder 01:00, 10 October 2012 (UTC)[reply]

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

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

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

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

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

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

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

Exactly. just overlapping in time by coincidence. —TheDJ (talk • contribs) 07:27, 10 October 2012 (UTC)[reply]

I'm on Chrome and don't have any of the Wiki markup I used to below the edit window. doktorb _words^deeds 07:54, 10 October 2012 (UTC)[reply]

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

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

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

Logging in on mobile is broken

Attempting to log in at http://en.m.wikipedia.org/w/index.php?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)[reply]

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

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

Mobile wikipedia

I am experiencing a problem using wikipedia 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)[reply]

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

Do you use Opera Mini? I've had issues with the Android app for that on mobile wikis running MediaWiki like Wikipedia (except not Wikipedia itself because I use the desktop version). - Purplewowies (talk) 01:56, 10 October 2012 (UTC)[reply]

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? Reh man 13:00, 10 October 2012 (UTC)[reply]

Same phenomena with DYK and ITN as well... Reh man 13:04, 10 October 2012 (UTC)[reply]

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

Thanks :) Reh man 13:14, 10 October 2012 (UTC)[reply]

what is the purpose of { { Citation | } }

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

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

{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=[[Ruslana]] |title=Euphoria |year=2012 |publisher=[[EMI]] }}

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

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

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

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

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

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

@@ Line 1,484: / Line 1,484: @@
 }} 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... --[[User:Funandtrvl|Funandtrvl]] ([[User talk: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. &nbsp;—&nbsp; {{User-multi
+ |doc=yes
+ |User=Maile66
+ |1=t
+}} 19:15, 10 October 2012 (UTC)
 == Preserve wikilinks when archiving ==