MediaWiki talk:Edittools

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Auto-insert selected text[edit]

Instead of

<charinsert>[[Category:]]</charinsert> ·
 <charinsert>#redirect [[_]]</charinsert>

an admin should insert:

<charinsert>[[Category:+]]</charinsert> ·
 <charinsert>#redirect [[+]]</charinsert> 

The selected text will then correctly inserted into the code-tags. --Katpatuka (msg)

Done. What about the »_« entry? Also, the #redirect [[+]] didn't work, so I reverted it. User:dbenbenn 23:23, 12 January 2006 (UTC)[reply]
<nowiki>#redirect [[</nowiki>+<nowiki>]]</nowiki>

should work, tested on de.wp --BLueFiSH ?! 13:24, 5 February 2006 (UTC)[reply]

This page is breaking validation[edit]

I believe this page is breaking XML validation on all edit pages (which makes it impossible to do advanced javascript, for one thing). It currently renders as:

 div class="plainlinks"
   p
   small
   /p
   p
   /p
   /small    
 /div

So the p and small tags are mismatched. They should be:

 div class="plainlinks"
   small
     p
     /p
     p
     /p
   /small    
 /div

I'm not an admin so I can't modify it to get rid of the problem. — Omegatron 19:24, 20 February 2006 (UTC)[reply]

Heh, I was looking for this, and you already found it :) It's because Mediawiki inserts the P tags due to the newlines. One way to fix it is to wrap the paragraphs separately using <small>, another is to remove the newlines (there's already a &br/>). Quarl 2006-02-21 03:02Z
I think it's fixed now. User:dbenbenn 14:20, 21 February 2006 (UTC)[reply]
The Code: section is still mismatched. Doesn't the site go through an XHTML validator before rendering? — Omegatron 20:26, 21 February 2006 (UTC)[reply]
Not for interface messages it doesn't. [1] – Minh Nguyễn (talk, contribs) 04:37, 23 February 2006 (UTC)[reply]

I think one more minor change is necessary: move the second </small> before the newline, right after the </charinsert>, so instead of:

 <charinsert><nowiki>#redirect [[</nowiki>+]]</charinsert>
 </small></div>

it looks like:

 <charinsert><nowiki>#redirect [[</nowiki>+]]</charinsert></small>
 </div>

Quarl 2006-03-22 06:15Z

Fixed now. User:dbenbenn 08:56, 22 March 2006 (UTC)[reply]

Bug[edit]

@Arnomane: this was not really good. the [[+]] is very ugly. the previous version worked better. Instead of <nowiki>[[+]]</nowiki> you should write <nowiki>[[</nowiki>+<nowiki>]]</nowiki> or simply as it was before [[+]]. --BLueFiSH  16:32, 16 April 2006 (UTC)[reply]

Well I have fixed this now together with several other things. The code was nonetheless totally broken before I touched it. There is a nasty bug with {{ }} inside "nowiki" in MediaWiki namespace (it still expands to the template). Arnomane 16:55, 16 April 2006 (UTC)[reply]
By the way I have seen how you made the nice dropdown thing in de.wikipedia. I have made a remark at Commons:Help page maintenance/Wikimedia Commons interface. There is some problem with internationalisation of the Javascript that needs to be sorted out until we can use this cool thing here as well. Arnomane 16:58, 16 April 2006 (UTC)[reply]
thank you, you were really fast =)
I assume there are problems with the onload-functions: in commons i have to use "window.onload". in de.wp i use "aOnloadFunctions[aOnloadFunctions.length]" but this does not work here. --BLueFiSH  17:17, 16 April 2006 (UTC)[reply]
The problem is with the text displayed in the dropdown box (the onload function would be a small change AFAIK). You can't use the standard local names there as in other places in Commons. For example with German interface you still want "Griechisch" in that particular case and not the the greek name written in greek in order to find the greek letters quickly. So one solution is making it in English only for the time being (probably the easiest solution) or make some internationalisation with variables like in MediaWiki:Extra-tabs.js but the problem is that here are so many variables and not only a hand full. Arnomane 19:03, 16 April 2006 (UTC)[reply]

please add[edit]

even it is duplicated the [[]] are very useful when uploading images... --BLueFiSH  22:52, 8 May 2006 (UTC)[reply]

I removed them as they're as well in the upper icon tool menu, which is not at image upload. Hm. Arnomane 00:09, 9 May 2006 (UTC)[reply]
"which is not at image upload" this is the point .. =) --BLueFiSH  00:37, 9 May 2006 (UTC)[reply]

Message from the inventor[edit]

Hey thanks for picking up my project! I posted my suggestions for making this perfect with the support of MediaWiki or extension developers over on the Village pump. Let me know if you have any problems - though I'm not the only one who has hacked it now. I don't log on to Common regularly but you can always find me on the English Wiktionary. — Hippietrail 17:35, 26 May 2006 (UTC)[reply]

Thanks for your nice script a well. :-) The only invention that would come into my mind is a translation of the language names according to user settings. It is technically quite easy to do so, see for example MediaWiki:Extra-tabs.js but in this case it would be hard to maintain because of the large list of text variables. Thatfor I didn't do it. Arnomane 14:35, 24 June 2006 (UTC)[reply]

New style[edit]

I think the edit tools looked better when they did not use this new button style. Maybe some better looking buttons can be made? But the centering of the text is not good at all. It makes the drop down menu jump around when you select another option, that needs do be changeged back to left alignment. /82.212.68.183 13:17, 9 June 2007 (UTC)[reply]

Your comment is not specific enough to make a modification. You my want to discuss the point at the village pump? Michelet-密是力 18:59, 19 July 2007 (UTC)[reply]
To stop the drop menu from jumping around, the only thing that has to be done is to remove "text-align: center;" from the style attribute. Then the text will be left aligned and the menu will stay in its place. (this change will not affect the button style for the links.) /90.229.135.239 10:41, 8 August 2007 (UTC)[reply]

Extended menu[edit]

I think it would be nice to have a "extended" option from the drop-down with buttons for various things that some of us use a lot, especially in template building. I'm glad to see the <noinclude> and <includeonly>s, but there's still many things I would like to have down there. Just a few things off the top of my head:

  • <!-- + -->
  • <code>+</code>, <tt>+</tt>, <pre>+</pre>
  • ≈ ≠ ≤ ≥ ± ÷ ← → £ © (various symbols; take a look at en.wp's)
  • {{subst:+}}
  • {{PAGENAME}}, {{NAMESPACE}} __NOTOC__, etc. (other popular m:magic words)
  • {{#language:+}}, {{#switch:+}}, etc.
  • and maybe some formatting ones like <span class="plainlinks">+</span> or <div style="clear:all;" />

I don't know how useful these will be to the majority of people, but maybe some should go in the standard menu? Rocket000 11:45, 25 March 2008 (UTC)[reply]

All right, I've added a bunch of these in their own subsections for symbols, tags, and template items. You're an admin, aren't you? You could fill in the rest yourself, then. Lupo 12:18, 25 March 2008 (UTC)[reply]
Wow, thank you. I was hesitant to edit it myself.. Is there any reason some entries end with a ' ·' and some don't? And how come &#123;&#123; is used for {{ in {{DEFAULTSORT:}} but not {{+}}? I don't like trail and error in the MediaWiki namespace :) Rocket000 15:22, 25 March 2008 (UTC)[reply]
The ' ·' is a separator, it makes the links (or if you have Javascript enabled—which you should, as it won't work at all otherwise—the buttons) be separated a little bit at that point. Also note that there's a trailing blank on all <charinsert> lines. I didn't check whether that is really needed. The &#123;&#123; is legacy code; I don't know why it was done that way. Lupo 15:43, 25 March 2008 (UTC)[reply]
Oh, I see. Yeah, I noticed the trailing spaces, I removed some and it worked fine in the preview, but it's not a big deal so I'll just leave them. I think some more can go on the "standard" one. Even with 800x600 it doesn't look crowded at all. Rocket000 17:46, 25 March 2008 (UTC)[reply]

Catalan characters[edit]

{{Editprotected}}

Character set for Catalan is not correct. It can verified at ca:MediaWiki:Edittools. Correct ones should be:

À à Ç ç É é È è Í í Ï ï Ò ò Ó ó Ú ú Ü ü · Ŀ ŀ

--V.Riullop 16:32, 3 June 2008 (UTC)[reply]

Done. — Richie 23:36, 5 June 2008 (UTC)[reply]

Is Template:Information in here somewhere? It seems like it should be, to make it easy to add. Superm401 - Talk 01:27, 31 August 2008 (UTC)[reply]

No templates are. The problem with add {{Information}} or anything like that it would be a really big button with all the params and newlines. Everything you see is exactly what you get. I don't how we would make the button text different. I'm sure there's a way, but I'm not the person to ask. An alternative is to add a custom toolbar button to your monobook.js. Personally, I hardly ever type out the info template with upload form suppling it automatically and the "Add Information" gadget which converts or adds it to pages when your not uploading. Rocket000(talk) 07:54, 31 August 2008 (UTC)[reply]
I guess I'll try the Gadget for now. Thanks. Superm401 - Talk 19:49, 1 September 2008 (UTC)[reply]

&nbsp is not working[edit]

Hi!

The button for instert a non-breakable space is currently inserting a normal space instead. How do we correct this? Helder 21:12, 4 July 2009 (UTC)

Fix it. Thanks. Rocket000 (talk) 22:22, 4 July 2009 (UTC)[reply]
Thank you! By the way, what means "amp;"? Helder 11:33, 5 July 2009 (UTC)
&amp; is the HTML character reference for ampersand (&) which escapes the character to prevent it from being interpreted as the beginning of another character reference, in this case &nbsp;. And if you look at the code of this comment you'll see I was able to write it literally by writing &amp;amp; (and &amp;amp;amp; for that, ad infinitum). Rocket000 (talk) 01:10, 6 July 2009 (UTC)[reply]
Thanks! =) Helder 10:11, 6 July 2009 (UTC)

Tildes[edit]

{{editprotected}}

Please add four tildes to the standard view. It simplifies signing for those that don't use the toolbar.

<charinsert>~~~~</charinsert>

Thanks. -- User:Docu at 17:05, 28 August 2009 (UTC)[reply]

Yes, it would be great! :) JoolzWiki (talk) 21:05, 28 August 2009 (UTC)[reply]

Where do you guys want it? I can't decide if it should be first or last on the first line. Rocket000 (talk) 21:42, 28 August 2009 (UTC)[reply]

Last? It is really cumbersome to type tildes. -- User:Docu at 12:49, 29 August 2009 (UTC)[reply]
[[ ]] is with, ~~ ~~ is more cumbersome than that at least. JoolzWiki (talk) 22:16, 29 August 2009 (UTC)[reply]
What? I didn't ask why you wanted it. I simply couldn't make up my mind where the best place for it would be. BTW, I'm probably one of the few who actually prefer to type it out. I've done it so many times it's not cumbersome anymore. I barely even think about it. I even signed an email that way one time by accident. :-) Rocket000 (talk) 03:48, 30 August 2009 (UTC)[reply]
I figured ;) I didn't use them in the past, but apparently we have to, now. Some admins had troubles finding my user page. -- User:Docu at 06:24, 30 August 2009 (UTC)[reply]
✓ Done Rocket000 (talk) 04:00, 30 August 2009 (UTC)[reply]
Thanks. -- User:Docu at 06:24, 30 August 2009 (UTC)[reply]

Category redirect[edit]

{{Editprotected}}

Per this discussion, please change:

<charinsert><nowiki>#REDIRECT&#32;[[+]]</nowiki></charinsert>

to:

{{#ifeq:{{NAMESPACE}}|{{ns:14}}|<charinsert><nowiki>{{Category redirect|+}}</nowiki></charinsert>|<charinsert><nowiki>#REDIRECT&#32;[[+]]</nowiki></charinsert>}}

It works at test. It replaces "#redirect" with the {{Category redirect}} when displayed in category namespace. -- User:Docu at 16:15, 3 May 2010 (UTC)[reply]

✓ Done. – Kwj2772 (msg) 09:11, 4 May 2010 (UTC)[reply]
Thanks. Seems to work here too. (I still don't believe that it does, but it does). -- User:Docu at 09:20, 4 May 2010 (UTC)[reply]

Outdent + others[edit]

{{Editprotected}}

The include/noinclude tags aren't of much use outside template namespace, thus I'd limit them to this namespace.

{{Outdent}} is sometimes useful on talk pages, especially VP and other Commons namespace pages. A few others are also useful in specific namespace. Thus I'd replace the part about include/noinclude with the following:

{{#ifeq:{{NAMESPACE}}|{{ns:10}}|<charinsert><includeonly>+</includeonly></charinsert>
<charinsert><noinclude>+</noinclude></charinsert>}}
{{#ifeq:{{NAMESPACE}}|{{ns:4}}|<charinsert><nowiki>{{outdent|+}}</nowiki></charinsert>}}
{{#ifeq:{{NAMESPACE}}|{{ns:6}}|<charinsert><nowiki>{{rename|+|no reason}}</nowiki></charinsert>}}
{{#ifeq:{{NAMESPACE}}|{{ns:6}}|<charinsert><nowiki>{{rotate|+}}</nowiki></charinsert>}}
{{#ifeq:{{NAMESPACE}}|{{ns:14}}|<charinsert><nowiki>{{move|+|no reason}}</nowiki></charinsert>}}

The functioning would be similar to the redirect template above. As it doesn't really remove any functionality, I'd implement it first and then ask for feedback on VP. We can then further improve it.  Docu  at 09:53, 29 July 2010 (UTC)[reply]

I don't really understand where I should replace this, can you put some more info or give a example please? Huib talk 10:40, 29 July 2010 (UTC)[reply]
It would replace:
<charinsert><includeonly>+</includeonly></charinsert>
<charinsert><noinclude>+</noinclude></charinsert>
BTW, good to see that you are back. Welcome back!  Docu  at 10:46, 29 July 2010 (UTC)[reply]

Yes, it's true certain buttons aren't that useful in certain namespaces, but that's no reason to remove them. People get use to a certain interface and want things they click on always in the same place (especially if you got them mapped out in your mind and use them almost without thinking; a minor change throws you off). Adding a button or two or replacing something like #REDIRECT with {{category redirect}} (great idea, btw) is fine but please don't change it anymore than that from one namespace to another. I also don't think we should be encouraging things like {{Outdent}} (which isn't common enough to be put in here). I removed the "no reason"s because they just take up room (and are monolingual). Rocket000 (talk) 04:30, 3 August 2010 (UTC)[reply]

I copied your comment to Commons:Village_pump#noinclude.2Fincludeonly_on_edittools and responded there.  Docu  at 11:39, 3 August 2010 (UTC)[reply]
Thanks. I didn't see that earlier. Rocket000 (talk) 12:05, 3 August 2010 (UTC)[reply]

Rumänisch: Ș ș & Ț ț statt Ş ş & Ţ ţ[edit]

Copied from Commons:Forum:

Moin! Bitte bei MediaWiki (o. ä.) den Zeichensatz für Rumänisch bei Wikimedia, Wikipedia, Commons usf. auf Ș ș Ț ț statt Ş ş Ţ ţ korrigieren! Anschließend möchte ich noch auf folgende Seiten verweisen (insbesondere auf die Disks. des Portals Rumänien der deutschsprachigen WP):

Vielen Dank für Rückmeldungen und Umsetzung(en)! Herzlich liebe Grüße Jens Liebenau (talk) 18:02, 13 August 2010 (UTC)[reply]


Translation: Jens Liebenau asks to change Ş ş Ţ ţ to Ș ș Ț ț in the special characters list as these are the correct Romanian characters. He links several German pages where this problem is described more in-depth. --ireas :talk: 07:03, 16 August 2010 (UTC)[reply]

Buttons[edit]

Hey, guys. I like the way you guys forged the edit tool here at Commons, I was trying to model my Wikipedia's edit tool after this one, but nothing seems to work. The buttons aren't visible, even though I entirely copied MediaWiki:Edittools.js. Could somebody tell me how is this manageable? --Zack (talk) 20:57, 19 September 2010 (UTC)[reply]

Did you add:
  importScript('MediaWiki:Edittools.js');
to your Common.js? Rocket000 (talk) 21:26, 21 September 2010 (UTC)[reply]
No I didn't; thank you loads! Zack (talk) 10:52, 22 September 2010 (UTC)[reply]

Duplication of special characters[edit]

{{Editprotected}}

Hi!!

Is there any reason to keep the Latin, IPA, Symbols, Greek, etc... characters in the Edittools since the enhanced toolbar has a section "Latin" under Special characters, which allow the users which want them to load these buttons? Shouldn't we also move other sections from edittols to edit toolbar "Special characters" section? (see usability:Toolbar customization). Besides the resulting interface simplification, the buttons from toolbar looks prettier than the current edittools buttons.

Se also this post. The previous objections doesn't seems to be valid anymore: the toolbar is shown by default even for anon users.

I suggest avoiding duplication and removing the characters from Edittools. Helder 14:16, 25 September 2010 (UTC)

I have to agree with that. How about the following: For all users with the modern edittools, move the remaining special chars into the relevant section; and only display the old edittools if they disabled the new editbar--DieBuche (talk) 10:08, 26 September 2010 (UTC)[reply]
And for users that don't use the editbar at all? Personally, I think at least the ones in the "standard" view should remain.  Docu  at 05:04, 6 October 2010 (UTC)[reply]
I'm not sure if I understand: why would anyone stop using the buttons just because they were moved to the toolbar, above the editbox? Or, supposing that somebody disable the toolbar, why would he/she still use edittools? If it is because the buttons from edittols are more useful that those from toolbar, moving them to toolbar solves this and still give us a less cluttered interface. Besides, anyone can completely reorganize the toolbar, so that it contains only the useful buttons (e.g. those from standard section of edittools). Helder 14:12, 7 October 2010 (UTC)
Edit toolbar is activated separately not not necessarily that useful for more experienced users.  Docu  at 17:01, 7 October 2010 (UTC)[reply]
I could say the same about the edittools. Unfortunately, it seems that currently we can't avoid it from being loaded for those who doesn't use it (as you can with the toolbar, and we could do with the advanced section of the toolbar to where this buttons would be moved): see bugzilla:11130. Helder 02:25, 17 October 2010 (UTC)

I de-activated the edit request template above as this seems a bit stale. --  Docu  at 13:11, 9 January 2011 (UTC)[reply]

Actually, the request is still pending: since we still get lots of unnecessary code sent to all editors, even if they can't use JavaScript, it is needed to at least remove the sections of this page which duplicates sections of the toolbar.
Besides this, I would like to know if there is any progress on moving this stuff to a separated page to be loaded via AJAX as in English Wiktionary? I've suggested this to DieBuche, but he may have forgotten. This would make it possible to move the content of this page to a page which is not sent to those users who can't use it. Helder 19:12, 9 January 2011 (UTC)
I think you might have missed the section just below (#Disappeared). --  Docu  at 19:19, 9 January 2011 (UTC)[reply]
Not really, I've participated there too =)
In the that section we solved the problem with the part of the script which moves the code of edittools (after downloaded) to the toolbar (if this is not disabled on Special:Preferences). But the duplicated sections are still sent to users via MediaWiki:Edittools: Latin, IPA, Symbols, Greek, ... should be removed. Helder 20:00, 9 January 2011 (UTC)
AFAIK, it's only sent to the users activating edittools and it's not really a duplicate if you don't use the toolbar. --  Docu  at 04:38, 11 January 2011 (UTC)[reply]
Try to edit any page after disabling the Javascript in your browser. The code from Edittools will be there, below the edit box! Note that although it is only shown the first section, the others are sent and downloaded as well (just look at the HTML source code of the page).
So, all this it is sent to users who can't use it at all! This is what bugzilla:11130 is about. Helder 12:18, 11 January 2011 (UTC)

Disappeared[edit]

Fixed

Somehow it went missing. I'm missing the link for the tildes now. -- User:Docu

You might have lost your cookie: Are they above the editfield? To move them back activate "use old edittools" in your prefs--DieBuche (talk) 15:35, 10 November 2010 (UTC)[reply]
I wasn't aware of the new? preference settings. It works now. Thanks.  Docu  at 17:46, 10 November 2010 (UTC)[reply]
It seems that the preference isn't stored. This is really not conveniant. Please revert it to the original version. -- User:Docu
How do you mean? It's stored as a cookie on your browser. So it will be gone if you erase your cookies or use another browser. For a more permant setting use: JSconfig.keys['oldEdittools'] = true; in your vector/monobook.js --DieBuche (talk) 12:10, 11 November 2010 (UTC)[reply]
The idea of Special:preferences is that they are more permanent than just a cookie. The one you added is the only one that doesn't work in the normal way.
As it's probably not that easy to add a (general) preference setting for this, maybe edittools should be made a gadget (or activated by default as it was before). -- User:Docu
This is the idea, yes. But there's currently no way to natively create preferences using javascript. The alt. method has been in use since 2005 and edittools is not the only one using it, but the following as well:
  1. Use new upload form logic
  2. Use new upload form layout
  3. Custom AJAX suggestion box width:
  4. Show a Subpages link in the toolbox

--DieBuche (talk) 11:12, 12 November 2010 (UTC)[reply]

I don't use "Custom AJAX suggestion box width", but none of the others keep disappearing. Is there a bug in Edittools? In any case, edittools shouldn't disappear if one doesn't start storing cookies. -- User:Docu
You can't even login w/o cookies... What do you mean with disappear? Do you not see this?--DieBuche (talk) 13:23, 13 November 2010 (UTC)[reply]
The cookie for this isn't set each time one logs in, it set only if you click "save" on Special:Preferences and isn't present anymore next time one logs in. -- User:Docu

{{Editprotected}} Please restore the unbroken version (version of 17:41, 2010 October 23). No consensus for change. See also Commons:Village_pump#Character_insert_tool. -- User:Docu

These are two different issues. Could you provide the following details, so that the cookie bug can be fixed: Browser and version, Operation system and version, skin used etc. In the meantime you can still put JSconfig.keys['oldEdittools'] = true; in your vector/monobook.js --DieBuche (talk) 12:51, 14 November 2010 (UTC)[reply]
Let's restore it first, you can later try to fix it. As you obviously disagree with reverting your own edit, you shouldn't remove {{Editprotected}}. -- User:Docu
Do you actually have a technical problem, or why do you never answer my questions?--DieBuche (talk) 13:00, 14 November 2010 (UTC)[reply]
I don't bother repeating once more if you don't read it. -- User:Docu
If you want to discuss EditTools as a whole, do it at the VP. If you got a technical error unconnected to that discussion, please provide some minimum details. And I already provided you with a workaround twice for the meantime--DieBuche (talk) 13:08, 14 November 2010 (UTC)[reply]
You can't really expect users to edit their whatever subpage, because a preference setting you added doesn't work as people would expect it to. The workaround is really simple: restore the original version or make it into a gadget. -- User:Docu
Did you clear your cache after the last updates? Before that, the behavior was somewhat broken as you've said, but after the updates everything is working as expected when I access the preferences or the edit box. When I'm not logged in it also works.
So the question remains: in which case (OS/browser/skin/page) is it broken? How can we reproduce it so that it can be fixed? Helder 17:20, 14 November 2010 (UTC)
Please clear your cache once more and confirm that it still works. -- User:Docu

Confirmed: it is working. I've made the following:

  • Deleted the cookie jsconfig_oldEdittools in Firefox, logged out and edited this talk page: the edittools was shown in a section of the toolbar, and its buttons were working.
  • Logged in and edited this page: still working as before
  • Enabled the preference "Use old edittools" and edited this page: the tools were moved to the old style, in the bottom of the edit box, and were working;

What happens for you when you do that?

Note also that reverting the edits made in MediaWiki:Edittools since 17:41, 2010 October 23 would not affect the script MediaWiki:Edittools.js, so the behavior of cookies and preferences would not change at all... Helder 17:43, 14 November 2010 (UTC)

Not sure if you noticed, but "save" on Special:Preferences keeps preferences across browsers.
Apparently it doesn't work correctly as other preferences as you shouldn't need to go through "Use old edittools" once more.
=> bug confirmed by Helder. Are there other ways to fix it than to revert? -- User:Docu
Just a note: I've confirmed that the edittools is working, not that there is a bug.
I don't know if the options which are added via jsconfig were any time crossbrowser persistent. The other preferences - those which are not created by jsconfig - are stored by the server, not stored by the browsers, and as such they persist when changing from one browser to another.
I've made also the following test:
  • Deleted all jsconfig cookies in both SeaMonkey and Firefox, logged out, cleared the cache, logged in, defined "old edittools" in the preferences, and then edited this page with SeaMonkey: the "jsconfig" cookies (jsconfig_oldEdittools, jsconfig_UploadForm_loadform, jsconfig_subPagesLink and jsconfig_UploadForm_newlayout ) were created.
  • Logged in Firefox and none of the cookies are there.
Wasn't this always this way? Or this is the mentioned bug? Helder 18:41, 14 November 2010 (UTC)
If you select any option in Special:Preferences, it remains there. Apparently, in your test setup you had to return to "old edittools" each time which means it doesn't work as the other preferences. Call it whatever you want, but compared to the way the edittools worked before it's a bug. -- User:Docu
Note: all these configs are made by JS, probably as an workaround to Bug 13742:
  • Use old edittools
  • Use new upload form logic
  • Use new upload form layout
  • Show a Subpages link in the toolbox
So, the current "Use old edittools" option works exactly as the other above options above.
Nonetheless, the remaining options of Special:Preferences are stored by the server, and as such are persistent across browsers. In order to have the edittools as an option like these, it is needed to vote on the following:
Bug 11130: Preference to toggle edit tools
There is also this related bug:
Bug 20151 - Preferences for anonymous users
Helder 19:09, 14 November 2010 (UTC)
It worked just a couple of days ago. Let's fix it for this one and see what we can or need to do about the other ones later. -- User:Docu

About the persistence of jsconfig options, I've made a suggestion at MediaWiki_talk:Common.js#Easy_configuration. I think implementing something like that would have the effect desired by Docu (cross browser persistence of options). Helder 19:39, 14 November 2010 (UTC)

It seems to work correctly now. Thanks for fixing it.  Docu  at 07:07, 15 November 2010 (UTC)[reply]
yep, I implemented Helders idea. Sorry that my tone got a bit tense before--DieBuche (talk) 08:54, 15 November 2010 (UTC)[reply]
No problem. I was a bit annoyed that half of the editing interface was gone .. BTW, the solution makes one want to move around some of the other gadgets ;)  Docu  at 05:34, 16 November 2010 (UTC)[reply]

onlyinclude[edit]

{{editprotected}} Please add

<charinsert><onlyinclude>+</onlyinclude></charinsert>

just after the line for "includeonly".  Docu  at 11:07, 4 December 2010 (UTC)[reply]

✓ Done (Like everyone would be using that every day.) --Mormegil (talk) 16:56, 23 December 2010 (UTC)[reply]
Thanks. One tends to keep forgetting it ;) --  Docu  at 13:10, 9 January 2011 (UTC)[reply]

Category for gallery[edit]

{{editprotected}} Please change

<charinsert>[[Category:+]]</charinsert>

to

{{#ifeq:{{NAMESPACE}}|{{ns:0}}
|{{#ifexist:Category:{{PAGENAME}}|<charinsert>[[Category:{{subst:PAGENAME}}| ]]</charinsert>
|<charinsert>[[Category:+]]</charinsert>}}
|<charinsert>[[Category:+]]</charinsert>}}

This makes it easier to add, e.g., Category:Barack Obama to Barack Obama. --  Docu  at 13:10, 9 January 2011 (UTC)[reply]

✓ Done Your code could not possibly work, for many reasons. I replaced with something which _seems to_ work. (For the record: I hate this bloated crap, this should be left for user JS/gadgets, but what can I do…) --Mormegil (talk) 14:48, 2 May 2011 (UTC)[reply]
Great. Works fine now. --  Docu  at 05:32, 12 June 2011 (UTC)[reply]

Sending edit tools only if JS is enabled[edit]

Hello!

I would like to suggest an update like this to the script so that the page MediaWiki:Edittools can be moved (without redirect) to MediaWiki:Edittools2 (or any other name you like) in order to stop sending the HTML of edit tools for people who can not use it at all: those who can't use JavaScript.

This kind of modification was previously suggested in some places:

Helder 21:41, 17 January 2011 (UTC)


Header[edit]

Please replace

</p>

<p class="specialbasic" id="Symbols" style="display:none">

with

{{#ifeq:{{NAMESPACE}}|{{ns:6}}
|<charinsert>=={{int:license-header}}==</charinsert>
}}
</p>

<p class="specialbasic" id="Symbols" style="display:none">

This would simplify cleaning up file description pages by allowing to insert the section header in one click. --  Docu  at 05:32, 12 June 2011 (UTC)[reply]

There is already a #swith: section for ns:6 just above. It makes much more sense to put the line in there instead of using a seperate #ifeq:. Edokter (talk) — 13:54, 16 June 2011 (UTC)[reply]

Good point. Thus let's replace

{{#switch:{{NAMESPACE}}
|{{ns:14}}=
<charinsert>{{move|+|}}</charinsert>
|{{ns:6}}=
<charinsert>{{rename|+|}}</charinsert>
<charinsert>{{rotate|+}}</charinsert>
}}

with

{{#switch:{{NAMESPACE}}
|{{ns:14}}=
<charinsert>{{move|+|}}</charinsert>
|{{ns:6}}=
<charinsert>{{rename|+|}}</charinsert>
<charinsert>{{rotate|+}}</charinsert>
<charinsert>=={{int:license-header}}==</charinsert>
}}

Thanks. --  Docu  at 15:10, 16 June 2011 (UTC)[reply]

✓ Done. – Adrignola talk 18:05, 16 June 2011 (UTC)[reply]
Great. Thanks. --  Docu  at 11:44, 17 June 2011 (UTC)[reply]

Published for file description talk pages (namespace = 7)[edit]

{{Editprotected}} To make it easier to add {{Published}} to talk pages for file description pages, please replace:

{{#switch:{{NAMESPACE}}
|{{ns:14}}=
<charinsert>{{move|+|}}</charinsert>
|{{ns:6}}=
<charinsert>{{rename|+|}}</charinsert>
<charinsert>{{rotate|+}}</charinsert>
<charinsert>=={{int:license-header}}==</charinsert>
}}

with:

{{#switch:{{NAMESPACE}}
|{{ns:14}}=
<charinsert>{{move|+|}}</charinsert>
|{{ns:6}}=
<charinsert>{{rename|+|}}</charinsert>
<charinsert>{{rotate|+}}</charinsert>
<charinsert>=={{int:license-header}}==</charinsert>
|{{ns:7}}=
<charinsert>{{published|url=+|title=|date=|journal=}}</charinsert>
}}

Thanks. --  Docu  at 11:44, 17 June 2011 (UTC)[reply]

filedesc[edit]

We have the licensing button, why not include a int:filedesc button too? Aavindraa (talk) 20:30, 8 April 2012 (UTC)[reply]

I agree that =={{int:filedesc}}== should be added. It does seem silly to include one section header, yet omit the other. Senator2029 18:09, 9 October 2013 (UTC)[reply]

Georgian Alphabet[edit]

<p class="specialbasic" id="Georgian" style="display:none">
<charinsert>ა ბ გ დ ე ვ ზ თ ი კ ლ მ ნ ო პ ჟ რ ს ტ უ ფ ქ ღ ყ შ ჩ ც ძ წ ჭ ხ ჯ ჰ</charinsert>
<charinsert>ჱ ჲ ჳ ჴ ჵ ჶ ჷ ჸ ჹ  ჺ ჻ ჼ</charinsert>
<charinsert> Ⴀ Ⴁ Ⴂ Ⴃ Ⴄ Ⴅ Ⴆ Ⴡ Ⴇ Ⴈ Ⴉ Ⴊ Ⴋ Ⴌ Ⴢ Ⴍ Ⴎ Ⴏ Ⴐ Ⴑ Ⴒ Ⴣ Ⴓ Ⴔ Ⴕ Ⴖ Ⴗ Ⴘ Ⴙ Ⴚ Ⴛ Ⴜ Ⴝ Ⴞ Ⴤ Ⴟ Ⴠ Ⴥ </charinsert>
</p>

please add Georgian Alphabet in mediawiki--David1010 17:35, 9 June 2012 (UTC)[reply]

Arabic[edit]

{{Edit request}}

Arabic does not work for me. Google Chrome 21 under Windows 7 vector skin using English as interface language. --Meno25 (talk) 14:13, 12 August 2012 (UTC)[reply]

Fixed. -- Rillke(q?) 12:04, 13 August 2012 (UTC)[reply]

HTML5[edit]

Hi,

Is it a good idea to suggest <tt></tt> and <s></s> as these markups don't exist any longer with HTML5? They can be replaced by <code></code> and <del></del>. ftiercel (talk) 06:57, 7 January 2013 (UTC)[reply]

http://www.w3.org/TR/html-markup/s.html suggests that we can continue using it; perhaps we have to add a style rule but all in all usually you strike though text that is no longer valid and not because you like horizontal lines. As for the tt tag, I don't know how to proceed. There were attempts from Daniel Friesen to magically transform deprecated tags in MediaWiki into valid ones. -- Rillke(q?) 16:35, 23 May 2013 (UTC)[reply]
+1 for tt tag, a short info to proceed de:WP:HTML5. PS: Although I'm not sure, the big tag is therefore in the standard Edittools and I'm also a friend of tags instead of CSS.User: Perhelion (Commons: = crap?)20:42, 27 July 2014 (UTC)[reply]
PPS: I think the W3C recommendations/ depreciations are needless for us. As we can see for example the center tag and font tag are since 15 years marked as deprecated but this are still very widely used. The same for the s tag, it was deprecated in HTML4, but nobody cares in Wikimedia (rightly so).User: Perhelion (Commons: = crap?)21:03, 27 July 2014 (UTC)[reply]

New and the old same time[edit]

It would be nice is there is an option to do so!? -- Perhelion 13:06, 19 May 2014 (UTC)[reply]

Like in the English Wikipedia[edit]

Can you please put (the old) Toolbar direct under the Edit-textfield (like in the English Wikipedia). It is annoying to scroll (up and down) for each crap click. Thanks -- Perhelion 13:34, 19 May 2014 (UTC)[reply]

Text-size of the buttons[edit]

The size of the buttons (14 or 16 px) is to big, it is annoying the scroll again and again the dropdown field. Please made it smaller like:

$(".pages .page-Edittools1").css("font-size","12px");

or in the MediaWiki:Edittools.css. User: Perhelion (Commons: = crap?)16:00, 2 October 2014 (UTC)[reply]

I using now this cumbersome code in my userspace:

$(function () { // [[Mediawiki:Edittools]] smaller (HACK) if (mw.toolbar) $.when(mw.loader.using('ext.wikiEditor.toolbar'), $.ready).then(mw.util.addCSS(".page-Edittools1.page-characters {font-size:11px}")); });

User: Perhelion (Commons: = crap?)  20:59, 28 April 2015 (UTC)[reply]

Whitespaces in headlines with multilingual tags[edit]

I think there is needed a consensus. As we can see there is an conflict (and reverting) in practice and with scripts to do so. I personally favour the practice without whitespaces (in contrary with normal text headlines). But as we can see, the UploadWizard also does it without whitespaces (but this should be only an secondary argument). I mentioned this conflict in Magog_the_Ogres cleanup script (which add whitespaces).User: Perhelion (Commons: = crap?)  20:59, 28 April 2015 (UTC)[reply]

I don't mind with or without spaces, but it doesn't work with spaces. Regards, Yann (talk) 08:04, 30 April 2015 (UTC)[reply]
Strange. <!-- --> that is also inserted via MediaWiki:Edittools does have spaces. --Leyo 08:09, 30 April 2015 (UTC)[reply]
Hm* I don't understand your both arguments.???User: Perhelion (Commons: = crap?)  17:03, 30 April 2015 (UTC)[reply]
What exactly don't you understand? My argument covers the technical aspect only. I was expecting a reply by Yann. --Leyo 15:27, 7 August 2015 (UTC)[reply]
Sorry, I have no idea why it doesn't work with spaces. Regards, Yann (talk) 16:18, 7 August 2015 (UTC)[reply]
I feel it's rather obvious (or maybe it's just me), having just looked at the code of this page: Space is considered as seperator between the character sequences to be inserted (obvious in the lines with multiple single characters) and the plus sign is the position of the cursor (obvious in the quotation marks). <!-- --> works because of the trickery with nowiki. So you propably want the first of the lines in question to be <charinsert><nowiki>== {{int:filedesc}} ==</nowiki></charinsert>. --Nenntmichruhigip (talk) 04:00, 28 January 2016 (UTC)[reply]
Thank you. I did it as you suggested and it works. --Leyo 11:33, 28 January 2016 (UTC)[reply]

Translation tags[edit]

{{Edit request}}

Please replace two items

<charinsert><tvar|+></charinsert>
<charinsert></></charinsert>

to single item

<charinsert><tvar|>+</></charinsert>

Please also add

<charinsert>{{#translation:}}</charinsert>

--Kaganer (talk) 16:54, 16 June 2016 (UTC)[reply]

@Kaganer: seems fine? I don't see a benefit in changing it. Is there consensus to use {{#translation:}} on commons? Please note that we must respect commons existing category system (we don't have /de etc. subpages and we don't have cat in the TA system). --Steinsplitter (talk) 10:46, 23 June 2016 (UTC)[reply]
Steinsplitter, See meta:MediaWiki:Edittools, as example (as prolect with widely using this option). This item is often used for "wrapping" text, that should be excluded from the translation. This text should be between <tvar|> and , and he never needed inside <tvar|>. I just can not imagine a case for using <tvar|>. They do not happen ever. --Kaganer (talk) 19:39, 23 June 2016 (UTC)[reply]
@Kaganer: Done. --Steinsplitter (talk) 10:32, 24 June 2016 (UTC)[reply]

Add geogroup template[edit]

{{Edit request}} I add {{Geogroup|level=1}} to a lot of categories and I'm sure other people do too. I would find it really helpful to have it as a button next to the {{Wikidata Infobox}} button in the edit tools. Thanks. --Hjart (talk) 05:01, 28 March 2021 (UTC)[reply]

✓ Done Awesome! Thank you! —‍Mdaniels5757 (talk • contribs) 17:02, 29 October 2022 (UTC)[reply]

tvar[edit]

{{Editrequest}} The syntax for the <tvar> has changed. Please change line 43 from this:

<charinsert><tvar|>+</></charinsert>

to this:

<charinsert>+</charinsert>

Thank you! Jon Harald Søby (talk) 16:47, 8 May 2021 (UTC)[reply]

@Jon Harald Søby: OK Raymond 17:36, 8 May 2021 (UTC)[reply]
@Jon Harald Søby and Raymond: nope, it doesn’t work. It should be
<charinsert><nowiki>&lt;tvar name=1></nowiki>+&lt;/tvar></charinsert>
with a <nowiki>, otherwise it’s split at the space, resulting in two (each useless) buttons. —Tacsipacsi (talk) 17:39, 8 May 2021 (UTC)[reply]
@Jon Harald Søby Fixed. Does it work now? Raymond 17:41, 8 May 2021 (UTC)[reply]
@Raymond and Tacsipacsi: Yes, seems to work. Thanks both of you! Jon Harald Søby (talk) 17:43, 8 May 2021 (UTC)[reply]
@Tacsipacsi Sorry, I pinged Jon Harald, not you. Raymond 17:45, 8 May 2021 (UTC)[reply]

MyLang[edit]

{{Ep}}

<charinsert>Special:MyLanguage/</charinsert>

Please add this line between line "tvar" and languages tag. Stang 23:25, 22 February 2022 (UTC)[reply]

✓ Done --Minorax«¦talk¦» 11:42, 21 September 2022 (UTC)[reply]