MediaWiki talk:Edittools

To hide the various subsections, insert any of these lines into your user css page (help). Note: Hiding these will not make the edit form load any faster (see bug 11130)

#edittools_main {display:none;} /* For the main "Insert" section */
#edittools_name {display:none;} /* For the "Sign your name" section */
#edittools_characters {display:none;}
#edittools_greek {display:none;}
#edittools_cyrillic {display:none;}
#edittools_ipa {display:none;}
#edittools_symbols {display:none;}
#edittools_wikimarkup {display:none;}

To change the font size of any of the sections, replace display:none; in any of the above properties with font-size: and then the desired size. For example

#edittools_characters {font-size:12px;}

will make the "Characters:" section display at a size of 12px.

{{subst:PAGENAME}}

Would anyone object if I added {{subst:PAGENAME}} to the editing toolbox? It might prove useful at times. --Ixfd64 22:14, 5 November 2006 (UTC)

I don't think it's necessary. {{subst:PAGENAME}} just produces the page title, which can just be copy/pasted from the page title visible on the editing screen. —Mets501 (talk) 22:48, 5 November 2006 (UTC)

Well, that's true. However, doing so will overwrite one's clipboard data. Users working on articles with complicated titles might have other data in their clipboards that they want to save. For example, many articles on minerals are very similar to each other in structure, except for having different data. In practice, users could copy the contents of one such article and modify the data in order to start another article. As many minerals have names that are fairly hard to type, this is where the {{subst:PAGENAME}} button would come into play. --Ixfd64 23:53, 5 November 2006 (UTC)

Good point. Let's see what other's say. —Mets501 (talk) 00:49, 6 November 2006 (UTC)

Reducing the overwhelming size - use Commons version?

I just noticed commons:MediaWiki:Edittools, which compresses the prolific options quite nicely. Might using/combining that style here be an option? (ie. Is it accessible to 99% of browsers?) Probably leaving "Wiki markup:…" and maybe "Symbols:…" as the default viewed selection.

It would make it easier to add further options, whilst reducing the overwhelming current selection, which I think distracts people from the various tips and warnings above and below it. —Quiddity 22:05, 23 December 2006 (UTC)

First, as discussed at the top of this page, you can limit which of the edit options you get. Perhaps including a link to a page that explains how to limit the option (this page or maybe another specifically targetted page) would be useful. Second, I use a lot of the options regularly that are on this version that are not in the commons version. Third, I don't buy the "distraction from other tips" argument. After a few times you don't read the other text anyways, and the first time I don't see where the expanse of symbols and characters is going to draw more attention that plainly worded text. —Doug Bell ^talk 05:34, 2 February 2007 (UTC)

On your 2nd point, I wasn't suggesting replacing ours with the commons selection, but rather using their "drop-down box" functionality to access our own selection.

If anything, we'd be able to add more options (character sets and symbols).

On the 3rd point, it's the first-time editors and computer-illiterates that I'm suggesting might be overwhelmed, or skip reading the notices, because of all the "obviously irrelevant to them" stuff in the middle. (I do limit my selection with user.css, it's the new editors I'm trying to help)

The majority of the editors here will never use the IPA/Cyrillic/Greek/etc characters, and as I mentioned above, if the list were compacted we could then add in the other sets like Vietnamese/Arabic/Yiddish/etc, and make room for things like this proposal below: #Edit page link to useful tags and templates. --Quiddity 21:50, 5 February 2007 (UTC)

And as demonstrated by some editors making their own page, because of what this one lacks, e.g. User:TEB728/temp. --Quiddity 20:29, 7 March 2007 (UTC)

Agreed 100% with adding the drop-down. Asking regular people to edit their personal CSS as if it were a user interface is completely unacceptable. Reducing the size of this box will make the page much less cluttered and make it more likely that people will read the license information. — Omegatron 15:52, 21 May 2007 (UTC)

Allow users to not swollow it down the phone lines in the first place

Gentlemen, can we permit advanced users a way to not download MediaWiki:Edittools on every edit in the first place?

Remember that some users have stylesheets turned off anyway, so the solution at the top of this page won't work (so it should mention what to do then). Also we don't go around all day with javascript turned on either. Indeed, we feel it is a waste for advanced users to have to download all these bytes in the first place, modem or ADSL. Jidanni 01:58, 31 August 2007 (UTC)

Edit page link to useful tags and templates.

(From WP:VPR, following comment by Quiddity)

How often editing some article does one want a quick popup page for the right template?

Can this line be added to the pages and inserts that are quickly accessible from an edit page:

Templates: general headers | maintenance | cleanup | talk page | user talk | all (all open in new window)

Note that dispute, source and similar templates which can be gamed or abused, are not directly listed (WP:BEANS). They're quickly found under "all" if needed, though. FT2 ^{(Talk | email)} 00:33, 6 February 2007 (UTC)

Request

{{editprotected}}

Could someone add <tt></tt> to the list (in the Wiki markup section)? --AAA! ^(AAAA) 03:48, 8 May 2007 (UTC)

It would make the list much longer. Are you sure that this is a desirable change? What do others think? --ais523 11:41, 8 May 2007 (UTC)

Personally I never use it. --Steinninn 12:39, 8 May 2007 (UTC)

I actually use it alot. We could remove <nowiki>, as that is covered by the toolbox above the edit window (see the "W" with a cross-like symbol through it). --AAA! ^(AAAA) 23:18, 21 May 2007 (UTC)

I don't think this is appropriate to include for all users. However, I do think this is another opportunity to look at Alex Smotrov's proposal to move the bulk of the Edittools code into pure JavaScript. Since the insertion of characters depends on JavaScript anyways, there is no loss of functionality caused by moving the creation of the toolbox into JavaScript as well. This would allow for a mechanism where users could easily extend the tool box for themselves, allowing the default to only have things that a large number of users will actually use. I can't find Alex's proposal in the archives of MediaWiki talk:Common.js, but here is a permanent link to his original proposal. Mike Dillon 15:02, 8 May 2007 (UTC)

I've disabled {{editprotected}} for the time being while discussion is ongoing. --ais523 15:47, 8 May 2007 (UTC)

I strongly support Alex Smotrov's proposal. Is there anything we can do to help move that idea along?

See also the thread above that got buried, #Reducing the overwhelming size - use Commons version? for another possibility to simplify this page's display. Thanks. --Quiddity 17:36, 8 May 2007 (UTC)

Please don't call it my proposal. The idea is floating around for ages, and there is at least one older similar proposal. I simply offered my version. As for Commons Edittools, it simply takes less space on the screen (and imho it's not very convenient). The main point behind «Javascript generated Edittools» is to reduce the amount of data (currently around 40 kbytes) that the browser has to download from Mediawiki server on every edit/preview page. P.S. Mike, those old discussions can be found at MediaWiki_talk:Common.js/Archive_index Alex Smotrov 21:43, 8 May 2007 (UTC)

I guess I should reiterate the pros and cons that I see about making this change:

Pros

1. Easily configurable by the user
2. Cuts down download size of edit/preview page by moving edittools code into a separate download that is cached by the browser
3. If JavaScript is off, there will not be a bunch of broken links in the edittools box

Cons

1. Changes to DHTML generated portion of will require more repetition of the WP:BYPASS mantra.
   • Note: this is only an issue if we pass smaxage when the script is loaded from Common.js. Otherwise, MediaWiki sends a "Last-Modified" header that causes the browser to send an "If-Modified-Since" header that is handled at the Squid cache layer with HTTP status code 304 and there is no bypassing needed to receive updates. We should only add "smaxage" if the developers ask for it. (Updated: 15:08, 9 May 2007 (UTC))
   • I just noticed that the server sends a Cache-Control header, so WP:BYPASS is needed... (Updated: 15:22, 9 May 2007 (UTC))
2. I've only tested my code in Galeon and Firefox on Linux (I'm pretty sure it will work just fine in IE)
3. Characters are not available for easy copy/paste for users with JavaScript turned off (Updated: 15:08, 9 May 2007 (UTC))

I think it's pretty clear that my opinion is that the Pros outweight the Cons, since I spent a couple of hours on this. I just wanted to lay out both sides as I see them. Mike Dillon 06:10, 9 May 2007 (UTC)

New prototype

I've looked through all of these discussions and at the version of Edittools on Commons and came up with my own version: User:Mike Dillon/Scripts/edittools.js. This version provides the following:

• Ability to create new groups (Edittools.createGroup(name, label))
• Ability to remove existing groups (Edittools.removeGroup(name))
• Ability to remove all groups (Edittools.removeAllGroups())
• Ability to add the following elements to groups:
  • Inline labels (group.addLabel(label))
  • Text insertion links (group.addInsert(open, close, sample))
  • Lists of character insertion links with space separation (group.addInsertList(chars))
  • Non-breaking spaces (group.addGap())
  • Bullets (group.addBullet())
  • Wiki links (group.addWikiLink(page, label))
• Ability to use Commons-style compact presentation (Edittools.style = "compact")
• Ability to control whether the existing children are cleared from the target container (Edittools.clear = false)

The tools are installed by calling Edittools.install(id or DOM element) in an onload hook. The script relies on normal CSS rules to create the border on the first group (instead of a horizontal rule) and the small text on the subsequent groups, although my current version inserts defaults for these rules in a style element in lieu of the rules being put in a CSS file. – All of the details need to be drawn up into some coherent documentation, but I think that the implementation fulfills all of the requirements I've seen. On top of that, I believe that the JavaScript is smaller than the currently generated HTML code for Edittools; it's about 12k total, but 7k of that is configuration to populate the edittools to look like the current version. The only things I've thought of that I didn't implement are 1) the ability to insert a new element into an edittools group (instead of append), since I didn't see a good way to specify the insertion point, and 2) the ability to wrap some of the element in arbitrary spans (there are a couple of these in the current version of Edittools). Also, I think the code for the compact v. full presentation could be a little more succinct, but this is just a prototype.

Let me know if you have any questions, either here or on my talk page. Mike Dillon 05:32, 9 May 2007 (UTC)

If I remember correctly, Wikipedia sends this sort of content gzipped, so the Javascript is likely to end up bigger due to having less repetition. However, seeing as the script would only be sent once, this would seem to be good for the server. What would need to be done to add it to MediaWiki:Common.js and produce a Commons-style dropdown with all these tools? What would happen for people who don't have JavaScript (who might still want to copy-and-paste the cahracters around)? --ais523 09:21, 9 May 2007 (UTC)

Gzip is only helped by repetition within a single payload, so the tradeoff is really 0 bytes for every edit/preview versus the gzipped equivalent of the 40k that the current edit tools take. My JavaScript version is about 1/4 the size of that, so it's gzipped size would be smaller than any potential compression of the 40k inline version. The only server load would be on the Squid servers having to deal with an If-Modified-Since/HTTP 304 cycle, which could be mitigated if we fetched the script with "smaxage". However, using "smaxage" introduces the need for WP:BYPASS. (The server sends Cache-Control with a max age of 31 days, so WP:BYPASS is needed...)

As for producing a Commons-style dropdown, all that would need to be done is to set Edittools.style = "compact". With the current code, this would need to be done from an imported script as well, not in Common.js itself because it would have to happen after Edittools.js was loaded. It would be pretty easy to change the code to allow the style switch to be done in Common.js (i.e. before the imported script actually executes), but I was anticipating the style switch to be done in user JavaScript where the timing problems are moot. If a site-wide change was desired, I would recommend doing it in Edittools.js itself.

Regarding people who don't have JavaScript, they would not see anything except an empty box (or whatever the "editpage-specialchars" div contained by default, which could be a warning message or a link to a page with characters to copy and paste). They would not have the characters on the page at all. If maintaining the 40k of inline code is desired to support this segment of users, the Edittools.js script could be modified slightly to allow the current behavior of specifying all of that code inline while using the script only for extension and switching the style from full to compact. Mike Dillon 15:07, 9 May 2007 (UTC)

For those who would like to test this, you should be able to load the script on demand while viewing the editing page by typing the following into your address bar:

javascript:function addOnloadHook(f){f()};importScript('User:Mike Dillon/Scripts/edittools.js')

That way it will load for the current page without having to modify monobook.js. Mike Dillon 03:41, 10 May 2007 (UTC)

I forgot to point out how you can know that the script has done its thing, since the intent was to exactly reproduce the existing Edittools box. The only difference you should see is that there are now tooltips on the insertion links that say "Insert text: ...". Other than that, there shouldn't be any difference. If you haven't bypassed your cache lately, you'll also see that {{DEFAULTSORT:}} was missing, but that was not intentional. Mike Dillon 16:00, 10 May 2007 (UTC)

I'd definitely support the change, but there are two possibilities to consider as to what to change to: either add the box entirely with JavaScript, or send Edittools as normal and use JavaScript to collapse them for uses if needed. I'm not sure what we should do about collapsed/not collapsed; collapse by default unless the user's .js is changed? Annoy the devs by asking them to add a new preference? Keep it looking exactly as it is by default with users being able to expand it in .js? Collapse it by default and have a link on the page to expand it? ais523 16:06, 10 May 2007 (UTC)

I actually don't like the collapse functionality, I just wanted to cover all bases. I think something like that would need to go through WP:VPR. I implemented it in case the user wanted a Commons-style presentation. Mike Dillon 16:20, 10 May 2007 (UTC)

Only problem I see is the first ndash appears to be broken somehow (Image:Edittools-symbol-problem.png), and the same thing with the very last IPA character (Image:Edittools-character-problem2.png) in linux/firefox; clicking to insert the characters works properly (creates just the appropriate character, not the error square/glyph), and the problem isnt visible in the htmlsource, so I don't know why that is happening?

Also it's missing the entries for <!-- --> and .

Apart from that, strongly support. --Quiddity 18:09, 10 May 2007 (UTC)

The HTML source is the existing code. The version created by the JavaScript is purely in memory.

The weird character you're seeing is 0x034F, the Unicode combining grapheme joiner (CGJ). It is supposed to be a blank character that you can use to make the positioning of a diacritic glyph show up in the right position without an actual character to place it on. It is the result of code that I put in explicitly to deal with that IPA diacritic at the end. I'm not sure why it is appearing before the en dash, but I guess it must be considered a combining diacritic. I could either change the character that is placed before diacritics to a non-breaking space or something, or I could just remove that code entirely. I added the code because I was not seeing the final IPA diacritic without increasing my font size and I thought it was a rendering problem. The frequency of needing to insert pure diacritics is pretty low for most character blocks.

As for the missing <!-- --> and , I've added them back. It was another thing that was unintentionally left out of the code. Thanks for noticing. Mike Dillon 19:00, 10 May 2007 (UTC)

I figured out the en dash thing. I had accidentally copy/pasted en dashes into the regex to find diacritics where there should have been hyphens. I've fixed that. As for the IPA character problem (Image:Edittools-character-problem2.png), it actually looks correct to some degree in that the diacritic is being properly positioned under the box. I'm not sure why you don't have a font that knows that the CGJ should be a blank, but you probably won't be the only one with that problem. I'm thinking that using a non-breaking space may be more compatible that using the CGJ, despite not being purpose-specific for displaying diacritics. Mike Dillon 19:12, 10 May 2007 (UTC)

Thanks for the informative reply :) Just fyi: I'm using FreeSans as my default font in Ubuntu/Firefox; there are 3 other glyphs that it's always had problems with, as seen in Image:Wikipedia-wordwrapped-line-height-problem.png (from the #GFDL thread above). It's still way better than the dozens of broken glyphs I had when using win98 though! *twitch* --Quiddity 00:13, 11 May 2007 (UTC)

See code realised on kkwiki kk:MediaWiki:Edittools.js This approach based on code thanks Mike Dillon in en:User:Mike Dillon/Scripts/edittools.js, added a lot of improvings and fixed some bugs in compact mode. --AlefZet 20:44, 27 May 2007 (UTC)

On talk pages, please sign your comment by typing four tildes

Isn't there a talk page-specific mediawiki message we could move this to? The less cluttered this message, the better. — Omegatron 16:04, 21 May 2007 (UTC)

It's already on MediaWiki:Talkpagetext. —METS501 (talk) 02:06, 31 May 2007 (UTC)

Suggestion for talk pages

For the sentence 'On talk pages, please sign your comment by typing four tildes (~~~~).' proper place is Mediawiki:Talkpagetext this key shows only if you edit talkpage.--AlefZet 11:41, 31 May 2007 (UTC)

2 threads saying the same thing. Can we get the mention here removed, as it's already in its appropriate location? --Quiddity 23:17, 18 September 2007 (UTC)

{{editprotected}}

I removed it. — Carl (CBM · talk) 22:12, 20 September 2007 (UTC)

Nono! The line we wanted removed was:

* On [[Wikipedia:Talk page|talk pages]], please '''[[Wikipedia:Signatures|sign your comment]]''' by typing four tildes (<code><nowiki>~~~~).</nowiki>

Please revert the last edit, and remove the above line instead. Thanks. --Quiddity 01:11, 21 September 2007 (UTC)

{{editprotected}}

I removed that. — Carl (CBM · talk)02:13, 21 September 2007 (UTC)

Thanks. (I fixed your sig). Whilst I have your attention, could you possibly comment on the thread below? It needs some momentum to get consensus for a change... --Quiddity 05:16, 21 September 2007 (UTC)

GFDL notice - twice now?

Is this really needed in the light of MediaWiki:Copyrightwarning? — Alex Smotrov 22:17, 4 May 2007 (UTC)

I can't see that it hurts to make it clear. What's the word, emphesise, or however you write that. --Steinninn 22:36, 4 May 2007 (UTC)

I think having it twice is terribly redundant. One of the instances ought be removed. Please remove the 1st line added in this diff

{{editprotected}}

The footnote about GFDL (linked from MediaWiki:Copyrightwarning) also seems superfluous, might that be removed too? (crossposted to MediaWiki talk:Copyrightwarning#Wordwrap)

All in the interests of not overwhelming the editpage foot-instructions... We're used to its size (or hide it with css) but it's really quite overwhelming for new editors, as is, and every reduction helps: Example screenshot. --Quiddity 03:43, 5 May 2007 (UTC)

Please gain consensus first; this page is incredibly visible. Cheers. --MZMcBride 19:01, 13 May 2007 (UTC)

Please remove the second, redundant notice. Saying the same thing twice just ensures that half as many people will actually read it. — Omegatron 15:52, 21 May 2007 (UTC)

4 times now?

a highlighted screenshot

crossposted to MediaWiki talk:Copyrightwarning#4 Gnus

I'm wondering if we could reduce the 4 references to the GFDL in the editingfooter?

Anything that can be done to simplify and shorten this large instruction set, would be good. --Quiddity 05:57, 10 June 2007 (UTC)

Anyone? --Quiddity 23:17, 18 September 2007 (UTC)

I've cut one as noted above - David Gerard 19:41, 9 November 2007 (UTC)

Oops :). I guess that explains why I added it, eh? I completely forgot I hid that, so I saw nothing saying "You agree to license" anywhere. Carry on. Prodego ^talk 17:38, 10 November 2007 (UTC)

I'm confused. Are you going to re-remove the line you just replaced?

As background, see this mailing list post, which is why David Gerard had just removed it.

Even better, would be to reduce the 4 times to only 2 times. Can someone with the relevant knowledge make that decision and change? It appears 3 times in this template and once in MediaWiki:Copyrightwarning. Thanks. --Quiddity 18:51, 10 November 2007 (UTC)

Whoops. I didn't realize I saved that. Reverted. Prodego ^talk 22:02, 10 November 2007 (UTC)

Add another input

How to add Arabic script input into this box? I'm an administrator in the Malay Wikipedia, and I intend to add another section for Arabic script plus Jawi script, which is also used to write Malay for certain purpose, especially religious purpose. Please answer in my talk page besides answering here, either in this Wikipedia or in the Malay (Bahasa Melayu) Wikipedia. Thanks! --Edmund the King of the Woods! 20:09, 8 August 2007 (UTC)

CharInsert block below the Save Button

I'm not sure why, but on my wiki, there's a line break between the checkboxes for Minor Edit/Save this page, and then another for all the buttons (save page, etc.) So the CharInsert box is all the way down at the bottom. Is there a way to get it to look like it is here on Wikipedia, closer to the bottom, or perhaps even ABOVE the edit box? Thanks.--TheSweet 18:26, 30 August 2007 (UTC)

Move non edit tools into another message

I strongly believe that Edittools should not be filled with some copyright warnings. These should be in the correct system message, namely; MediaWiki:Copyrightwarning. could someone move it? --Steinninn 14:06, 18 September 2007 (UTC)

No, considering the huge amount of copyvio's we get a double message is not overkill. See the backlog at Wikipedia:Copyright problems and the neverending supply at Wikipedia:Suspected copyright violations‎. Garion96 (talk) 20:56, 18 September 2007 (UTC)

Considering the fact that Edittools is below the "Save page" button I think that moving this text to Copyrightwarning that is above the "Save page" would decrease the amount of suspected copyright violations. I'm not talking about taking anything away, I'm talking about moving it to the correct system message. --Steinninn 21:46, 18 September 2007 (UTC)

Characters show up / don't show up - strange bug

I've embedded CharInsert in my own MediaWiki. But there's a strange bug. I copied all the characters from Wikipedia's Edittools to my Edittools. A few characters show up as � outside of the edit window. But inside the edit window they look just fine, also after saving. So why are they actually present but can't be rendered in the actual CharInsert box? I got that behavior on different installations on different servers. It's always the same characters like ≠ † ɠ à and some more. —Preceding unsigned comment added by Mooncrater (talk • contribs) 23:50, 5 October 2007 (UTC)

Cyrillic

Hallo!!! I'm requesting for major thinks could be usefull for editing pages, where Cyrillic is used.

1. There are no accented Cyrillic latters in Unicode, so if we use accent, it is placed using combining " ́ " chracter. As accent is used in Russian and other languages only in academical texts, there is no this characted on the standart Russian keyboard. So, I think there is enough plase in "Cyrillic" line to place {{subst:Add accent}} there. It's a whole problem to insert accent in other way.
2. Cyrillic line contains only Slavic Cyrillic, but there are major non-Slavic languages, using Cyrillic. So, their additional letters are represented in the last versions of the most popular fonts, like Times and Arial. Those letters are: ӘәӨөҒғҖҗҚқҜҝҢңҮүҰұҲҳҸҹҺһ. This addition is needed. For example, when someone who originates from Russia and has a statdart Russian keyboard, he cant add Kazakh letters, so the Kazakh spelling appears fool of mistakes in the article.
3. My third proporsal is not so needed, but if there is enough place in Cyrillic line, I think it could be realized: some additional Cyrillic letters are used rarely on the www, but they represent major languages, to be potentially developed, such as Tajik. However, unlike the p.2 they are not so frequently used. ҔҕӢӣӮӯҘҙҠҡҤҥҪҫӐӑӒӓӔӕӖӗӰӱӲӳӸӹ Ӏ

Is it possible to use hidden lines, such as in some templates? If it is realible, the rest letters are: ҞҟҦҧҨҩҬҭҴҵҶҷҼҽҾҿӁӂӃӄӇӈӋӌӚӛӜӝӞӟӠӡӤӥӦӧӪӫӴӵ

I hope you realize at leat two of my proporsals! --Üñţïf̣ļëŗ (see also:ә? Ә!) 15:50, 22 November 2007 (UTC)

Edittools is already oversized. My browser has to get approx. 60KB from the server so I'm able to enter some characters that I never use. I suggest you show support for Wikipedia:Village pump (proposals)#Adding user scripts to Special:Preferences and then any extra set of editttols characters can be implemented as a gadget and easily added by a user in personal preferences ∴ AlexSm 16:03, 26 November 2007 (UTC)

Where is the button bar

Where is the code for the button bar (the bar of buttons above the edit box, and how does someone install it on their wiki? It isn't done with mw:Extension:CharInsert is it?

I want to add a redirect button to my wiki. T (talk) 13:44, 10 December 2007 (UTC)

I believe that's in MediaWiki:Common.js; just search the code there for "redirect" and you'll find it. —Disavian (^talk/_contribs) 13:56, 10 December 2007 (UTC)

Adding parserfunctions

I think this is a good idea, if we were to add some of the more used PFs. Thoughts? -- Anonymous Dissident^Talk 15:29, 6 January 2008 (UTC)

Looking at the size of Edittools (and I mean the size in HTML, and the fact that it's not cached), I don't think it's a good idea. On the other hand, you can use #switch to check the namespace, so these PF only appear when editing templates, in that case I don't mind ∴ AlexSm 18:35, 6 January 2008 (UTC)

Now that Special:Preferences-Gadgets has been implemented, can we move some of the current character-sets to there, as Alex suggested 2 threads above? Optional instead of default, would help reduce the overwhelming size, and make it easier to add more sets such as those we don't currently list but commons:MediaWiki:Edittools does. -- Quiddity (talk) 19:21, 6 January 2008 (UTC)

Idea

Since these require javascript anyway, would it be possible to implement most of these as gadgets and only leave a few on by default? —Random832 21:44, 14 January 2008 (UTC)

I agree. I also think this should be done simultaneously with full conversion to JavaScript, which has been suggested at least 3 times already. Also, unregistered users should have a JavasScript link that would load the rest of Edittools with Ajax (and probaly remember this state in a cookie) ∴ AlexSm 23:23, 14 January 2008 (UTC)

Strongest possible "Yes, freaking please!" I don't have a supercomputer at hand and the massive JS overload coupled with Firefox' tendency for JS-caused leaks forces me to restart my browser every 10-20 edits. See also User:Cyde/Saving bandwidth, where I proposed a possible solution (which however only worked in Firefox) quite a while ago. Миша13 23:37, 14 January 2008 (UTC)

I've written a function that takes an array of characters (or of more complex objects for the opening/closing-tag links) and creates a section... I'll work on this more later tonight. —Random832 20:13, 17 January 2008 (UTC)

Incidentally, the way it's written also allows it to take a string and it will turn it into a section full of single-character links. —Random832 20:25, 17 January 2008 (UTC)

Can someone test this in IE? Everything in my monobook, from "function simple_inserttext" downward. —Random832 20:26, 17 January 2008 (UTC)

new code in my monobook, current version, won't be editing for a while. —Random832 15:55, 18 January 2008 (UTC)

Hiding siteSub header with monobook.css?

How to hide "From Wikipedia, the free encyclopedia"? - Neparis (talk) 18:08, 24 February 2008 (UTC)

#siteSub {display:none;} -- Quiddity (talk) 19:41, 24 February 2008 (UTC)

Thanks. I tried that earlier today, shift-reloaded to clear the cache, and it wasn't working, but when I tried again just now, it did work, so I guess there was a cache problem afterall. Sorry to waste your time! - Neparis (talk) 20:17, 24 February 2008 (UTC)

Modification in the style of fr.wikipedia.org

The French version of this page not only shortens the second section of the message (the section that begins "Wiki markup"), but also provides more special characters that can be inserted than does the English version. Are there any disadvantages to switching formats, to the French approach?

(Note: I'm not proposing to have only a single section, as the French do - that seems excessively radical - but rather just improving the second section.) -- John Broughton (♫♫) 21:52, 16 March 2008 (UTC)

It is an interesting approach. I am thinking though that in some situations it could be quite significantly slower and more annoying to use than the current layout. For example, when I am editing technical articles, I frequently need to use mixtures of math, Greek, and wiki special characters. With the French layout, I would be continually switching that menu to display whichever set of special characters — math, Greek or wiki — I needed for the next edit. The menu is an extra step that would slow down the speed of editing. Over long editing stretches it would be very tedious and wretched. The enwiki layout doesn't have so many characters in total, but at least all the math, Greek and wiki ones it has are displayed together, available to use at a single click.

The French approach is very compact in displaying only one set of special characters at a time, but what might be more useful in certain cases would be to display as many sets at a time as the editor chooses.

Perhaps Special:Preferences could offer a choice of displaying as many of these sets of special characters to display as the editor prefers. I would probably choose to display three sets simultaneously: wiki, Greek, and math. - Neparis (talk) 23:26, 16 March 2008 (UTC)

This is exactly what I was trying to suggest at the thread way above, #Reducing the overwhelming size - use Commons version?.

I'd support almost anything that reduced the current size/complexity! Whatever works out best for the most users on all the diverse systems we need to support (whether using dropdowns, preference-gadgets, etc). -- Quiddity (talk) 00:31, 17 March 2008 (UTC)

I hadn't thought about someone who used a variety of things. But I think that's easily handled. For those who like the current set of insertable items, there could be a pull-down option of "Standard" that would show what is now shown (or even more, because a longer list wouldn't impact all editors).

And to avoid making a editor constantly have to choose "Standard" from the pulldown menu, there could be an option in User Preferences as to what the starting set would be, with the default being (as in the French setup) the most commonly used (small set).

Regarding the comment by Neparis, I agree that this gives the most flexibility (or, if you will, is the most powerful). I do worry that developers would balk at providing this level of granularity in User Preferences (as opposed to choosing a single starting point, just one more parameter in the Editing tab). So a technical question - could Javascript (user script) be used to set the editor preference? -- John Broughton (♫♫) 13:16, 18 March 2008 (UTC)

A Wikipedia:Gadget could probably be written to let users pick the style they want. It's likely done with JavaScript anyway. — Omegatron (talk) 01:23, 21 May 2008 (UTC)

Time to fix this page

There have been various suggestions over the past year or so about what to do with this page. The options are:

• Just add drop-downs (similar to Commons)
• Strip out most of the tools and move them to gadgets
• Make the tools dynamically-loaded (test.wikipedia.org does this currently)
• Leave it as-is

The tools are, for the most part, not necessary when editing. However, they're loaded with every page edit. So, making them dynamically loaded or moving some of them to gadgets would be ideal. We'll need a bit of cross-browser testing, which is simple enough. So... thoughts? Volunteers? --MZMcBride (talk) 04:32, 12 May 2008 (UTC)

I saw another wiki that used buttons instead of tiny links. I liked that a lot. Do you know if this is possible here? —Remember the dot ^(talk) 04:44, 12 May 2008 (UTC)

Certainly. --MZMcBride (talk) 04:46, 12 May 2008 (UTC)

Found it: fy:MediaWiki:Summary. Could I go ahead and change, say, the top line that has the most frequently used tools to use buttons instead of the tiny links? —Remember the dot ^(talk) 04:57, 12 May 2008 (UTC)

Just going to make the page bigger, no? I'd rather implement one finalized solution than constantly edit the page. I think buttons are fine, but I'm far more concerned about the sheer size of the damn thing at the moment. --MZMcBride (talk) 04:59, 12 May 2008 (UTC)

OK. Actually, looking at commons:Mediawiki:Edittools, I see that they actually change the links to buttons using JavaScript, so it may not be possible to use buttons directly at all. We should consider using simple CSS to make the links look and behave like buttons. —Remember the dot ^(talk) 05:06, 12 May 2008 (UTC)

Splarka pointed out to me that Gadgets will hurt anonymous users (as they can't have preferences / Gadgets). So, that should be taken into consideration. --MZMcBride (talk) 04:46, 12 May 2008 (UTC)

I would support dynamic loading. Edittools is a lot of crap to load that isn't used very much (AFAIK). Mr.Z-man 05:00, 12 May 2008 (UTC)

I would support any sort of drop-down system like what the Commons uses. —Remember the dot ^(talk) 05:06, 12 May 2008 (UTC)

What about a combination of drop-downs and have it be dynamically-loaded, e.g., test.wikipedia? And it can use buttons. --MZMcBride (talk) 05:27, 12 May 2008 (UTC)

Yes please, that works excellently (test at testwiki:Sandbox). They deleted their testwiki:MediaWiki:Edittools in January 2007 (summary: "No longer required"), and I don't know how the current system works there.

I'd like to see that, combined with leaving the first line we currently use here ("Insert: – — … ‘ “ ’ ” ° ... Sign your username: ~~~~" ) for those of us with the edit toolbar switched off. -- Quiddity (talk) 06:23, 12 May 2008 (UTC)

I've killed it in my .css, so I'd definitely support dynamic loading to get rid of it entirely. The only thing I miss is the charinsert for the backwards-pointing arrow, which I used to use for outdents :D. Is there anything I can add to my monobook.css to display a custom toolbar in place of the default one? Happy‑melon 09:32, 12 May 2008 (UTC)

Some of the past suggestions have involved the ability for individual users to customize the display of the edittools via variables in their monobook.js files. I think that is important enough to be included in whatever final solution is implemented here. —Dinoguy1000 16:30, 12 May 2008 (UTC)

I really like what they use on test.wikipedia.org. I have two things to add to that however. The way to open the tools should be more obvious (especially for the anon/newb users). and we need to remember that users without javascript will not be able to use them. The code they use are the following items btw: the tools and the loader --TheDJ (talk • contribs) 19:31, 12 May 2008 (UTC)

On the one hand, I really like the way testwiki's implementation works. We should, however, make sure that it is obvious to users to activate it (I would suggest that by default it appear with the wiki markup screen, which is the most useful for newbies), and that it is, broadly-speaking, compatible with all browsers. We may, however, expect, broadly speaking, users to be able to use JavaScript, since the current edittools is dependent on JavaScript itself and I don't think there's an easy alternative that would allow insertion of characters or expressions. Nihiltres^{t.l} 22:49, 12 May 2008 (UTC)

Anything would be an improvement to the current huge set of insertable characters being displayed, the vast majority of which are used by virtually no one, and which display for everyone except the few that know how to use personal javascript to hide them.  And I think there is little risk here in being bold and making changes, after some discussion and an advance notice pointing to what the proposed change is (screenshots are nice, I'd argue).  I'd suspect that the very few editors who have problems with any particular change would be happy with a gadget that changes things back (as with being able to change the "new section" tab label back to "+").  So, rock on, please!  -- John Broughton   (♫♫) 02:32, 13 May 2008 (UTC)

I am definitely in favor of reducing load time.  Can gadgets be enabled for anonymous users?  If not, it might be nice to have it load for anons by default, since many are here for interwiki related cleanup.  For registered users, I would love to have the option to never to have load the edittools at all (dynamically or otherwise). JackSchmidt (talk) 03:23, 13 May 2008 (UTC)

Ok, so it seems we want Commons-looking buttons, dynamic loading, drop-down menus, and (at least) a bar that's always there. Here is a mock-up-esque design. Having the bar always present allows for copy-pasting and helps newbies. Also, you'll notice that the "load edittools" button is bold to draw attention to it. What I'm hoping is possible is that this bar will allows show, and then if the load button is clicked, the drop-down menu will appear below it.

I also created MediaWiki:Editpage.js and MediaWiki:Edittools.js (both "imported" from test.wiki). The next step is to write a bit of JS to allow the usage of two edittools at once (appending a div mwEdittools2 and modifying Edittools.js should work). And, of course, updating test.wiki's version to match ours. Perhaps we'll test more at test.wiki first and then port to en.wiki... --MZMcBride (talk) 06:22, 14 May 2008 (UTC)

Good idea. I have created a reduced version of MediaWiki:Edittools, in User:TheDJ/Sandbox2. It has a span with id "edittools_more" this is the span where MediaWiki:Editpage.js (to be loaded from Common.js), will add the "Load edit tools"-link, which I propose we will call "More symbols..." instead. The other element is a div with id "edittools_main2". This is the place where the new elements from commons will be loaded. This is my sandbox Editpage.js implementation. And a similar edited User:TheDJ/Edittools.js. Seems simple enough. I say, lets test on test.wikipedia.org (whose an admin out there? ) :D --TheDJ (talk • contribs) 13:03, 14 May 2008 (UTC)

(Although I created testwiki version), I strongly oppose drop-down menus. They are simply inconvenient and should be a separate gadget for those who want them. —AlexSm 15:13, 14 May 2008 (UTC)

Importing a 2nd list in the style of what we currently have, or the "commons-style", shouldn't matter much technically, I don't care what people pick, I won't use either of them. If you want to, we could make it skin-able !!! (sarcasm) :D --TheDJ (talk • contribs) 15:43, 14 May 2008 (UTC)

The edittools should all be migrated to javascript so that people who do use them will have them cached in their browser, and people who don't use them can disable them in Special:Preferences (or by setting some variable to "false" in their personal monobook.js) and completely forget about them, and people who don't even have javascript won't puzzle over at least 100 buttons that don't do anything. I suppose the dynamically-added version should be "on" by default, for the benefit of anon. editors who can't set their own prefs but most people will never anything other than the arrows and the em/en dashes. See also bugzilla:11130. — CharlotteWebb 13:45, 14 May 2008 (UTC)

People forget one thing here, there is a difference between the edittools, and edittools MediaWiki page (the latter also contains a shitload of en. specific warning messages). That will make it even harder to get this implemented in the standard wikimedia distribution. --TheDJ (talk • contribs) 15:43, 14 May 2008 (UTC)

Caching issues

While I support the transition to JS, there are some caching issues that we have to keep in mind. First, when this is implemented, for some time (up to a month) we'll have to keep both old MediaWiki:Edittools and the new script, and the script would have to clean the edittools box before recreating the links. Second, any change to JS Edittools would not be effective for users immediately. We can either live with that or make the script self-updating. This means the MediaWiki:Edittools would have a hidden span with ID or class equal to script "version". When there is an important change, admin changes this "version" both in this span and in the script, then the script detects that and reloads itself, with something like &nocache=Math.random(). —AlexSm 16:17, 14 May 2008 (UTC)

If I understand the problem correctly, could we not just add a placeholder that says something to the effect of "missing your edittools? try refreshing your browser cache..."? — CharlotteWebb 16:24, 14 May 2008 (UTC)

Unfortunately, refreshing cache (reloading the page) in the edit window means losing all the changes that you could have made to the text by this point. We'd have to craft a complex message like "please save your changes now, and when you start editing something next time immediately refresh your cache". —AlexSm 16:46, 14 May 2008 (UTC)

Ah, yes. Would that be too complicated or rude? — CharlotteWebb 16:55, 14 May 2008 (UTC)

For the initial phase, we could have the old box, and add the new span and div into it, keep it like that for a full month, and then change to the "reduced version". If we want to, we can even add a check on the old IDs to the javascript loader to make sure we don't have "duplicate" edittools in that first month either. For the normal maintenance. I don't see the problem. Common.js doesn't even have such safeties, and it should be much more important than the edittools javascript right? --TheDJ (talk • contribs) 18:46, 14 May 2008 (UTC)

Just some implementation notes: I'd probably be better to include the version number from the ID in the URL rather than using Math.random(), and to do so unconditionally rather than just whenever a mismatch is detected. Something like the following (warning: untested code), added to MediaWiki:Common.js, ought to do it:

addOnloadHook(function () {
    var versionElem = document.getElementById("edittools-version");
    if (!versionElem) return;
    var match = /(?:^| )edittools-version-(\d+)(?: |$)/.exec(versionElem.className);
    if (!match || !match.length) return;
    var url = wgScript + '?title=MediaWiki:Edittools.js&action=raw&ctype=text/javascript&nocache=' + match[1];
    // rest of the code copied from importScript():
    var scriptElem = document.createElement( 'script' );
    scriptElem.setAttribute( 'src' , url );
    scriptElem.setAttribute( 'type' , 'text/javascript' );
    document.getElementsByTagName( 'head' )[0].appendChild( scriptElem );
});

Then we can include something like <span id="edittools-version" class="edittools-version-1234"></span> in MediaWiki:Edittools to enable the code, and change the number after each update to the Javascript to purge caches. —Ilmari Karonen (talk) 17:35, 16 May 2008 (UTC)

Test implementation

I've set up a test implementation of Javascript-based edit tools, based on Alex Smotrov's code at mediawiki.org. To try it out, add the following lines to your monobook.js:

importScript("User:Ilmari Karonen/edittoolstest.js");
window.testJsEdittools = true;

My implementation differs somewhat from Alex's: besides some minor adaptations to the peculiarities of our local MediaWiki:Edittools (so that, e.g., the GFDL link isn't turned into a button), it also implements the version-numbering scheme I describe above, so that, once everything is set up, any changes to the javascript can be deployed immediately.

The "hook" code, along with deployment instructions, is currently at User:Ilmari Karonen/edittoolstest.js. The actual code creating the new edit tools is at User:Ilmari Karonen/edittools.js. If this implementation looks okay, we can move the former code to MediaWiki:Common.js and the latter to MediaWiki:Edittools.js. There will then have to be (at least) a 30-day waiting period, during which time the code will only be active for users who have set window.testJsEdittools = true in their monobook.js. After that, it can be fully deployed by removing "test" from the class name of <div id="editpage-specialchars"> in MediaWiki:Edittools and deleting its content. —Ilmari Karonen (talk) 14:36, 20 May 2008 (UTC)

I added the code to my monobook.js page, bypassed my cache, and it's either not working or I'm noticing no difference whatsoever. Tested on FF3b5 and Safari 3 for Mac. --MZMcBride (talk) 22:00, 20 May 2008 (UTC)

Same here, on IE 6 and 7. —Dinoguy1000 23:00, 20 May 2008 (UTC)

The previous version worked on my Firefox, but broke on Konqueror; I just fixed it so it now works on both, did that help anyone else? (I also bumped the version number in MediaWiki:Edittools to test the autoupdate: if it works, you shouldn't need to bypass your cache to get the updated version.) —Ilmari Karonen (talk) 23:11, 20 May 2008 (UTC)

...also removed an extraneous comma that Opera was choking on. —Ilmari Karonen (talk) 00:21, 21 May 2008 (UTC)

(unindent) Without the extraneous comma, Opera now works. However, both FF3b5 and Safari 3 for Mac fail. There's a screenshot here.

Also, AlexSm pointed out to me that drop-downs are rather annoying. I was thinking that having a link at the bottom that loads the entire box of edittools (like test.wikipedia, but without the drop-downs) would be best. And then we can have Gadgets for drop-downs. Something similar to this, as mentioned in previous sections, seems like a better route. Thoughts? --MZMcBride (talk) 00:49, 21 May 2008 (UTC)

Hmm... well, it's mostly his code, so he's certainly free to write a dropdown-less version — I'm definitely not attached to them in any way. The version on testwiki is kind of clunky, though, with no edittools available until one finds the link in the corner, clicks it and waits for the script to load. Something like your mockup could indeed work best: provide a small selection of tools by default and a wider selection behind a show/hide (or should that be "more"/"less"?) toggle. It shouldn't be hard to implement, either, but I'll let it wait until tomorrow — right now I need to get some sleep. —Ilmari Karonen (talk) 01:15, 21 May 2008 (UTC)

Well, after bypassing my cache, IE 6 displays the empty div and the dropdown box, but when I try to select any of the dropdown options, the browser just complains about an unsupported property or method on line 151, and nothong comes up in the div. *grumbles about Microsoft* —Dinoguy1000 16:07, 21 May 2008 (UTC)

*scratches head* By my count, line 151 says if (token == '' || token == '_'), so I'm sure the error isn't actually there (though it almost certainly is in the same function). I don't suppose you could convince IE to tell which property or method (and on what object) it doesn't support? Meanwhile, I managed to test the script in IE7: it works, but not the first time(!). No error message, either, even with "report all errors" enabled. I suspect a race condition, but I'm not sure what it might be racing; the code I copied from Commons already runs late, in an onload handler, to avoid IE-related issues. Pfft. I'm thinking maybe I should just rewrite the whole thing from scratch. —Ilmari Karonen (talk) 18:49, 21 May 2008 (UTC)

If it helps any, IE shows a script error on any page edit, not just when using the dropdown menu - sorry about that. It reports the problem seperately for every list item selected. The full error text is as follows (in case it helps you at all):

Line: 151
Char: 2
Error: Object doesn't support this property or method
Code: 0
URL: http://en.wikipedia.org/w/index.php?

As for the line, my count (in a Notepad source view) puts the error squarely in the middle of the edit textbox. I'm not sure how I would go about squeezing the specific property or method out of IE, but I'm on a library computer and am locked out of the "Internet Options" dialog box, so I don't think I can do much. —Dinoguy1000 19:12, 21 May 2008 (UTC)

I made some changes to the code, including changing the for-in loop in createTokens() to a for(;;) loop. Did that make any difference to anyone? —Ilmari Karonen (talk) 08:49, 23 May 2008 (UTC)

Wa-ha-ha, I've got edit tools now, and IE doesn't complain about script errors anymore! Excellent work, especially going off of my vague error description... ;) That being said, the Devanagari options overlap some vertically, but nothing else does. I have a feeling it's because of the wierd character heights or something. —Dinoguy1000 17:27, 23 May 2008 (UTC)

It now works for me in FF3 and Safari 3 for Mac. \o/ I think adding the hook code to Common.js would be best right now. And then we figure out whether to have drop-downs or buttons (or both or neither), etc. --MZMcBride (talk) 18:45, 23 May 2008 (UTC)

I've just checked in IE 7, it seems to be working fine here too. —Dinoguy1000 22:20, 23 May 2008 (UTC)

At least no-one seems to have any problems with the hook code in User:Ilmari Karonen/edittoolstest.js. That's the critical part, since as long as the hook works fine, we'll have 30 days to tweak the rest of the code even after the hook has been added to Common.js, and we can always update it easily and without caching delays if we find more bugs in it. —Ilmari Karonen (talk) 18:58, 21 May 2008 (UTC)

I think we can add that loader script now. We got 30 days to figure out the rest. --TheDJ (talk • contribs) 10:57, 24 May 2008 (UTC)

MediaWiki:Common.js/edit.js would be the most appropriate page for the loader code, I think. --MZMcBride (talk) 23:42, 25 May 2008 (UTC)

Done. I also copied the new actual implementation from [[User:Ilmari Karonen/edittools.js] to MediaWiki:Edittools.js, so it's ready for testing. —Ilmari Karonen (talk) 23:09, 27 May 2008 (UTC)

Insert characters into any input field

Any chance of making it work in all textareas and text input fields of a form, like the one at the Commons? Lupo 15:12, 20 May 2008 (UTC)

I moved this into separate section because it seems like unrelated enhancement that can be implemented independently of the above JS Edittools proposal. The code that redefines insertTags() is located at commons:MediaWiki:Edittools.js. —AlexSm 15:38, 20 May 2008 (UTC)

I've added that feature to my test script (see previous section). Seems to be working fine. —Ilmari Karonen (talk) 21:04, 20 May 2008 (UTC)

JS edittools launch approaching

So 8 more days, and the JS version should be ready for launch. I was taking a look over the old and new version, and I notice that there is quite some differences in the amount of symbols available in the new version compared to the old version. Is this something we might want to take a look at before this goes live ? --TheDJ (talk • contribs) 09:51, 20 June 2008 (UTC)

Absolutely. As far as I know, we didn't actually decide on any particular style, we just added the loader code as it was the piece that was going to take the longest. I'm in favor of a hybrid solution, that allows editors to have easy access to very commonly-needed tools, and only loads the less commonly-need tools with a separate click. Something similar to this. The key point I want to have in the new edittools is some sort of dynamic-load system so that the vast majority of edits aren't forced to download hundreds of lines of code that they don't need. --MZMcBride (talk) 19:18, 20 June 2008 (UTC)

Strongly concur. -- Quiddity (talk) 00:43, 21 June 2008 (UTC)

The delayed loading isn't really nearly as important if the tools loaded entirely via JavaScript, since the JS is only loaded once and then cached for subsequent edits. Besides, out of the code currently in MediaWiki:Edittools.js, the fraction of bytes saved by removing all the non-standard buttons would only be about 25%; most of the code is shared, while the button definitions themselves are given in very compact form in the "charinsert" array. —Ilmari Karonen (talk) 11:47, 21 June 2008 (UTC)

Aesthetics

edittools new

edittools old - (reduced set via my monobook.css)

The style of graphical buttons will obviously vary per browser/OS, but I'm currently getting some very large and ugly output (in Firefox 2, under Ubuntu, at 1024x768). Can the button size be slightly reduced? (though not as small as it was before). Also, can we try to get the linewrap to work gracefully at 1024? After adding all the other characters and sets that still need to be included, of course. :) -- Quiddity (talk) 00:43, 21 June 2008 (UTC)

I like the larger size! One of the biggest flaws in the old system was that the default size was far too small to be of practical use. If you're inserting IPA diacritics (ʲˠ) or even the length mark (ː) the old system was very hard to use. ☸ Moilleadóir ☎ 01:06, 27 June 2008 (UTC)

I've been using the 'new' edittools for a month now (even though i hardly use them at all), and I like them. They are definitely less annoying than actual HTML buttons (which also just vary too much between the different browsers), and I think they will be easier to use and understand for newbie editors. I do notice however that we need to avoid using "newlines" in this new format in order to avoid something like seen in the first screenshot of this section. But splitsing symbols and wikisyntax into 2 sections should probably fix that. --TheDJ (talk • contribs) 10:48, 27 June 2008 (UTC)

Thirty days!

Thirty days has passed since the JS was added to /edit.js. We can now safely switch to a JS implementation of the edittools. So... after chatting with a few people, some aren't going to like the buttons and drop down menus. Which means we should probably, for the moment, port the current edittools to Edittools.js and then we'll have to hold a vote of some sort to decide if we want to change it, and if so, to what. I took a look at the current Edittools.js and couldn't make heads or tails of it.... --MZMcBride (talk) 21:13, 28 June 2008 (UTC)

I've been meaning to do more or less that for some time, but I've been quite busy with other stuff and will be so for some time yet. It shouldn't be too complicated: just removing the silly CSS tricks that make the links look like buttons ought to leave something that looks not entirely unlike the current non-JS version. —Ilmari Karonen (talk) 22:25, 28 June 2008 (UTC)

Wot's... Uh the Deal? I was eagerly waiting for some way to permanently disable this from being loaded (loaded invisibly isn't good enough). Is any more progress being made here? — CharlotteWebb 19:55, 9 August 2008 (UTC)

User-added functions to edittools

Hello all- I get the impression from a search Wikipedia:Help_desk that I should pose this question here. Please direct me otherwise if this isn't the best place.

Is there a way for a user to customize edittools in the user preferences? I would like to add a function that places {{SharedIP}} at the top of a page (for anonymous talk pages). As an aside, it took a while to find the term edittools. I think the term should be mentioned and defined somewhere, but I'm not sure where--maybe at Wikitext or Wikipedia:How_to_edit_a_page? -Eric ^talk 13:39, 28 July 2008 (UTC)

As far as I know, there's currently no way to customize the edittools other than via a script in your monobook.js (or equivalent file if you use a different skin). This is a feature I'd really like to see implemented, though... Maybe if we raise a big enough stink, someone will get around to working on it. ;) —Dinoguy1000 20:41, 28 July 2008 (UTC)

Thanks for the response. Let me know if you have an idea and I'll set aside a ripe Stilton for the occasion. -Eric ^talk 21:06, 28 July 2008 (UTC)

With the new edittools implementation live, you can add custom edit tools using window.charinsertCustom. For example, try adding the following code to your monobook.js:

window.charinsertCustom = {
  "Insert": "{\{SharedIP}}",  // The backslash is there to keep your monobook.js from being categorized as a shared IP
  "Smileys": ":-) :-( :-D :-/ :-P ;-)  :) :( :D :/ :P ;)"
};

This should give you a link to add {{SharedIP}} tags in the main tab as well as (just as an example) an extra tab for some smileys. —Ilmari Karonen (talk) 19:04, 20 August 2008 (UTC)

Why not use Special:MyPage/Edittools?

Is there any reason the MediaWiki software couldn't check for User:xxx/Edittools and use it in place of MediaWiki:Edittools if it's found? Then people who want to delete the tools could delete them, and people who want to add buttons could add them, and people who want a reduced and reorganized set of buttons could do that. Even someone who doesn't understand Javascript or MediaWiki could easily do any of these things by aping the form of what's already in the document. -- BenRG (talk) 15:11, 20 August 2008 (UTC)

Okay, it's live!

I've just turned on the new all-JavaScript edittools. An announcement has been posted to Wikipedia:Village pump (technical)#New edit tools enabled for everyone. As with any highly visible interface change, expect lots of panic and complaints. :-) If you encounter any actual breakage (and it's not something you can easily fix by yourself), let me know ASAP. —Ilmari Karonen (talk) 18:51, 20 August 2008 (UTC)

Requests

Request for these 3 additions to the "Wiki markup" section, to bring it in line with the old version:

[[Category:+]] #REDIRECT [[+]]  

(Code untested) Thanks again :) -- Quiddity 01:20, 21 August 2008 (UTC)

It might also be a good idea to add the <ref>+</ref> option to the default "Insert" set? That's probably the most commonly used one, for a lot of us. (I've added it to my own set with your from instructions above). -- Quiddity 04:32, 21 August 2008 (UTC)

 Done. I also added an "inert" version of the old edit tools back into MediaWiki:Edittools: it doesn't take that many bytes with all the links removed, and that way users without JavaScript can still copy and paste the symbols. —Ilmari Karonen (talk) 13:45, 21 August 2008 (UTC)

Palettes

Well, I assume that this is useful for many, especially the changes that I (who don't use Java) don't see. But the drop-down menu "palettes" are actually a pretty disruptive change - ALL the ones I seem to use are on the "Wiki markup" palette, so you've just added two extra mouse actions to every edit I seem to make. Unhappy with that, to be honest :-(

Couldn't one at least add a "preferences" menu selection as to what palette is selected by default for every user? Thanks. Ingolfson (talk) 07:31, 21 August 2008 (UTC)

Mmmmph. Even in the palettes, the "redirect" and "category" options have now apparently been removed. Now I have to painstakingly type them in by hand. What gives, why this reduction in functionality? Would be great if they could be re-added. Thanks. Ingolfson (talk) 10:32, 21 August 2008 (UTC)