MediaWiki talk:Edittools/Archive 8

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

The new arrangement make it very difficult to distinguish this two letters ( Serb,Croat,... Đ from Icelandic&Faroese Ð ). The minors đ and ð are not a problem, but the others are so equal that is really hard to know which is which. This problem I issued first at Wikipedia talk:WikiProject Football but, it should be better also issued here. I find some people saying that natives of those languages may probably not have problems, but I as a Serb, find it extremely difficult, and I beleve everybody will. In the previous arrangement, as the letters were next to the minors, that wasn´t a problem (the Serb Đ was next to Serb đ), but now it is. This problem will certainly create a lot of misspelling and breaking of links. My sugestion was to see if there was the possibility of merging the two Đ&Ð, only them, not the minors, of course (like the Portuguese and Turkish Ç , it has different use, but is the same letter). FkpCascais (talk) 03:36, 26 January 2010 (UTC)

Mixed case ordering and character identification

• As a more general point, would it not be better to have every lowercase letter sorted immediately after its uppercase equivalent? As well as ameliorating the Đ/Ð problem above, this order would correspond more closely to the underlying alphabetical ordering which is (mostly) intuitive to editors.
• Could a tooltip be added to each character with, say, its full unicode name?
• Should the heading "Characters:" be renamed "Latin:" to make it equivalent to the headings for Greek, Cyrillic and IPA?
• Finally, is there a reason why ß appears three times in the current list?

— Richardguk (talk) 04:27, 26 January 2010 (UTC)

FkpCascais and Richardguk: Regarding having each lower-case letter immediately after its upper-case equivalent: If you guys do the hard work to make a full example here with that order then we can see if that is more or less readable. And then we can copy and paste that into the code.

Adding a tooltip to each character would be lots of work, and would probably make the code large to download.

I was just about to say: "Eh, there's no heading 'Characters:', the Latin section is already named 'Latin:'." In MediaWiki:Edittools.js that heading already is "Latin:", so that is what most of us see. But on closer inspection I see that in the plain text MediaWiki:Edittools that heading indeed is named "Characters:". I changed that to "Latin:" so the two edittools match each other and since as you point out it is the more logical choice.

Yeah, having ß three times might seem silly. At least in the S-group it is probably enough if ß is shown after the lower-case characters. On the other hand it shows that ß is used as both upper and lower-case, something that non-German users might not know so they might wonder why there is no "upper-case ß".

--David Göthberg (talk) 05:32, 26 January 2010 (UTC)

I consider the present new order to be adequate. There are five varieties of upper-case D (D Ď Đ Ḍ Ð) and five varieties of lower-case d (d ď đ ḍ ð). It seems reasonable to assume that the third variety of upper-case D (Đ) corresponds with the third variety of lower-case d (đ), and that the fifth variety of upper-case D (Ð) corresponds with the fifth variety of lower-case d (ð).

As for the ß, see what Noetica said above, at 07:28, 19 January 2010 (UTC): "Some characters intentionally appear twice: ß Ð ð Þ þ Ə ə. They appear once in the strict sequence, and again at the end. (There may be no certain base character, or an editor may not know it; once more, a gain in utility, and no loss.)"

-- Wavelength (talk) 05:55, 26 January 2010 (UTC)

I know the third upper-case correspond to the third lower-case, but initially wasn´t as close as clear it is now, and I can assure that many young and unexperienced editors will make a enormous amount of misspellings with this two Đ/дs. Also, there is going to be a problem finding all the wrong ones... Wrong redlinks will appear, doubled articles... Hmmm, not the best future. So, it is impossible to merge the upper-case Đ/Р? FkpCascais (talk) 07:14, 26 January 2010 (UTC)

Thanks for the feedback. For what it's worth, I've shown below how the lists might look if sorted alphabetically. (I've used Word 2003 to determine the order but please don't hold that against me! It seems cognizant of everything except Ȳ and ȳ which I've placed intuitively.) The seven quasi-Latin characters appear again at the end of the alphabet.

For the sake of completeness, I've also applied the same rules to the Greek list, which is already alphabetical but with diacritic characters sorted separately. I've no knowledge of Greek collation so the existing order may be better or worse than the one below.

I haven't attempted to change the Symbols and IPA lists, nor the Cyrillic list, which seems already to be sorted in broadly the way I have suggested for Latin.

I've also shown the lists again with tooltips added in the form <span title="capital letter AE with macron">Ǣ</span>, for the limited purpose of providing a demonstration on this page. The character descriptions are taken directly from the current Unicode NamesList.txt[1] but made lowercase except for the names of capital base characters, and with the prefixes "LATIN" or "GREEK" deleted as these are indicated by the headings.

Note that I've added Ṝ (Latin capital letter R with dot below and macron) as this seems to be missing from the existing list. This may be an accidental omission so you might want at least to add that one character, even if the ordering and tooltips don't gain consensus.

— Richardguk (talk) 08:31, 26 January 2010 (UTC)

Richardguk: Ah, thanks for making the examples. Now that I see the mixed case ordering of the Latin characters I agree, it seems better. As you have pointed out, in some cases the lower case characters are easier to distinguish thus telling us which is which of the upper case ones, and in some cases the upper case ones are easier to distinguish (after all they are larger) thus aiding in picking the right lower case character. And it is consistent with how we do in the Greek and Cyrillic groups.

The Greek ordering we can handle the usual way: We can simply leave messages over at some Greek related WikiProjects asking the Greek speaking users there to come here and tell us how they prefer the Greek ordering to be. But let's handle that in a separate section on this page.

And man, you are crazy (in a good way). Adding all those tooltip codes to the third example must have been really hard work! But I am sorry, I think that causes too much code, it is slow to load and render on older computers like the one I use. And the code becomes hard to manage. So I am opposed to using the tooltips. We could perhaps just add tooltips to Đ and Ð and some other such characters that can't be told apart visually. Adding the tooltips to MediaWiki:Edittools is easy, but adding them to MediaWiki:Edittools.js takes a javascript expert (which I am not). Most users have javascript enabled so they see the output from Edittools.js.

Fixed - I see that MediaWiki:Edittools.js already have both the upper and lower case "Ṝ", and MediaWiki:Edittools already have the lower case "ṝ". So right, it seems to be an accidental omission. So I have added "Ṝ" to MediaWiki:Edittools. Thanks for finding that bug.

--David Göthberg (talk) 17:42, 26 January 2010 (UTC)

Thanks for the comments (in a good way!). Just noticed three further accidental omissions or duplications in the existing text:

• Ì (Latin capital letter i with grave) is missing (wikitext only)
• ḷ (L with dot below) is missing as lower case but appears twice as upper case Ḷ (wikitext and javascript)
• Ḹ and ḹ (Latin capital/small letter with dot below and macron) each appear twice (wikitext and javascript)

I've only checked for Latin or Greek characters that are unpaired or appear more than once. Sorry for not noticing these at the same time as Ṝ – I've since checked the text programmatically, and evidently my visual proofreading noticed only 1 out 4 inconsistencies.

— Richardguk (talk) 02:04, 27 January 2010 (UTC)

Fixed - Oh, good catches. I have fixed both the wikitext and javascript versions. And I too have now checked the Latin version programmatically. I checked all the Latin characters and I found no more errors (except a mistake I did when doing this fix :)). Of course, there might be omissions of entire pairs, that I can't check automatically. I also (partly programmatically) compared the wikitext and javascript versions, they seem to list the same Latin characters.

For future reference, here's the code I used to do the check:

{{#ifeq:L Ĺ Ŀ Ľ Ļ Ł Ḷ Ḹ 
|  {{uc:l ĺ ŀ ľ ļ ł ḷ ḹ }}
| equal
| different
}}

The magic words {{lc:}} and {{uc:}} are a good way to get the lower-case or upper-case version of a character. Note that the "İ ı" pair is a special case so "fails" the above test.

All this goes to show that the new proposed "mixed case ordering" is better, since then we would probably have visually discovered these mistakes long ago.

--David Göthberg (talk) 11:22, 27 January 2010 (UTC)

Richard: I manually sorted the current wikitext version, and then programmatically compared it with your examples above to see if we have any errors.

I noticed that your examples above had the same bugs as you just reported. (Not your fault, since you took the data from here.) I updated your "sorted" and "tooltip" versions above to avoid the bugs from being reused.

I also noticed that your version has two differences from the main sort order of the current wikitext, in the "i" group and the "ß Ð ð Þ þ Ə ə" group at the end. I think the current main sort order in the wikitext is more human readable, so I suggest we use that. Thus this is the Latin version I prefer:

A a Á á À à  â Ä ä Ǎ ǎ Ă ă Ā ā à ã Å å Ą ą Æ æ Ǣ ǣ   B b   C c Ć ć Ċ ċ Ĉ ĉ Č č Ç ç   D d Ď ď Đ đ Ḍ ḍ Ð ð   E e É é È è Ė ė Ê ê Ë ë Ě ě Ĕ ĕ Ē ē Ẽ ẽ Ę ę Ə ə   F f   G g Ġ ġ Ĝ ĝ Ğ ğ Ģ ģ   H h Ĥ ĥ Ħ ħ Ḥ ḥ   I i Í í İ ı Ì ì Î î Ï ï Ǐ ǐ Ĭ ĭ Ī ī Ĩ ĩ Į į   J j Ĵ ĵ   K k Ķ ķ   L l Ĺ ĺ Ŀ ŀ Ľ ľ Ļ ļ Ł ł Ḷ ḷ Ḹ ḹ   M m Ṃ ṃ   N n Ń ń Ň ň Ñ ñ Ņ ņ Ṇ ṇ   O o Ó ó Ò ò Ô ô Ö ö Ǒ ǒ Ŏ ŏ Ō ō Õ õ Ǫ ǫ Ő ő Ø ø Œ œ   P p   Q q   R r Ŕ ŕ Ř ř Ŗ ŗ Ṛ ṛ Ṝ ṝ   S s Ś ś Ŝ ŝ Š š Ş ş Ṣ ṣ ß   T t Ť ť Ţ ţ Ṭ ṭ Þ þ   U u Ú ú Ù ù Û û Ü ü Ǔ ǔ Ŭ ŭ Ū ū Ũ ũ Ů ů Ų ų Ű ű Ǘ ǘ Ǜ ǜ Ǚ ǚ Ǖ ǖ   V v   W w Ŵ ŵ   X x   Y y Ý ý Ŷ ŷ Ÿ ÿ Ỹ ỹ Ȳ ȳ   Z z Ź ź Ż ż Ž ž   ß Ð ð Þ þ Ə ə   {{Unicode|}}

--David Göthberg (talk) 12:39, 27 January 2010 (UTC)

Looks good to me, thanks for your work on this. (By way of explanation for the remaining minor difference in our proposed orderings: The dotted/dotless Turkish letters İ/ı are conceptually unaccented characters and so closer in identity to ordinary I/i than the various accented letters I/i; the accents then follow in the same order as they do for the accents with letters A/a etc. The seven quasi-Latin characters were sorted to match their relative order in the main alphabetical list but I can see that eth and thorn do make sense together, as in your refinement.) Thanks for taking the trouble to set out your alternative so clearly. — Richardguk (talk) 13:23, 27 January 2010 (UTC)

I have thought more about this, and your arguments have convinced me. You are right, the sort order "I i İ ı Í í Ì ì" is the correct one. So here then is what I think both us now is suggesting:

A a Á á À à  â Ä ä Ǎ ǎ Ă ă Ā ā à ã Å å Ą ą Æ æ Ǣ ǣ   B b   C c Ć ć Ċ ċ Ĉ ĉ Č č Ç ç   D d Ď ď Đ đ Ḍ ḍ Ð ð   E e É é È è Ė ė Ê ê Ë ë Ě ě Ĕ ĕ Ē ē Ẽ ẽ Ę ę Ə ə   F f   G g Ġ ġ Ĝ ĝ Ğ ğ Ģ ģ   H h Ĥ ĥ Ħ ħ Ḥ ḥ   I i İ ı Í í Ì ì Î î Ï ï Ǐ ǐ Ĭ ĭ Ī ī Ĩ ĩ Į į   J j Ĵ ĵ   K k Ķ ķ   L l Ĺ ĺ Ŀ ŀ Ľ ľ Ļ ļ Ł ł Ḷ ḷ Ḹ ḹ   M m Ṃ ṃ   N n Ń ń Ň ň Ñ ñ Ņ ņ Ṇ ṇ   O o Ó ó Ò ò Ô ô Ö ö Ǒ ǒ Ŏ ŏ Ō ō Õ õ Ǫ ǫ Ő ő Ø ø Œ œ   P p   Q q   R r Ŕ ŕ Ř ř Ŗ ŗ Ṛ ṛ Ṝ ṝ   S s Ś ś Ŝ ŝ Š š Ş ş Ṣ ṣ ß   T t Ť ť Ţ ţ Ṭ ṭ Þ þ   U u Ú ú Ù ù Û û Ü ü Ǔ ǔ Ŭ ŭ Ū ū Ũ ũ Ů ů Ų ų Ű ű Ǘ ǘ Ǜ ǜ Ǚ ǚ Ǖ ǖ   V v   W w Ŵ ŵ   X x   Y y Ý ý Ŷ ŷ Ÿ ÿ Ỹ ỹ Ȳ ȳ   Z z Ź ź Ż ż Ž ž   ß Ð ð Þ þ Ə ə   {{Unicode|}}

It seems we are about 3 editors for this "Aa Bb" sorting, and one editor against. I think we should deploy this.

FkpCascais: You wanted to solve the "Đ Ð" problem. So I assume you find our new sorting better, right?

But I agree with you, the best would be if the two "Đ Ð" were treated as one single character by MediaWiki, at least in page names and links. But that would need an update to the MediaWiki software. We have the same problem with hyphens and dashes in page names "- – —", so I think there is a bugzilla: request about that. We should add the "Đ Ð" problem to the same request.

--David Göthberg (talk) 16:04, 27 January 2010 (UTC)

Many thanks for having in consideration my opinion. I think the problem I issued here regarding the Đ&Ð, is definitly fixed this way. For now, I don´t see any further problems coming up, if I spot any, I´ll adress it here. Thanx again. FkpCascais (talk) 16:14, 27 January 2010 (UTC)

• I'm so pleased to see that this is going ahead! Many thanks to David Göthberg. Tony (talk) 07:11, 28 January 2010 (UTC)

Tony: Nah, I am just a gnome around here. It was FkpCascais who identified the problem, and Richardguk who came up with the solution.

Everyone: I have been looking in the history of these pages and the above sections. We used to sort the upper and lower-case variants of each character together, until 19 January (nine days ago). On 19 January the diacritic order was greatly improved, see sections Arrangement of... and Rational and friendly ordering... above. But at the same time the upper and lower-case characters were separated. We still sort the upper and lower-case characters together in the Greek and Cyrillic scripts. So I think changing "back" to that sorting probably is uncontroversial. But we of course keep the new much better diacritic sorting from 19 January.

Y Done - So I have now deployed this.

--David Göthberg (talk) 14:09, 28 January 2010 (UTC)

Alphabetical versus accent ordering

Why was this (the alphabetical ordering) done in the first place? This is extremely non-user friendly. For example: I write articles mainly on German topics, and it's damned irritating to have to hunt down all of the characters with umlauts. I'm never going to need any of the characters with carons or thorns, and editors who use those regularly probably aren't going to need those with umlauts. Yet we all have dig through the list to find the specific characters we need. It was much more efficient when the characters were arranged by type, so all of the special characters for specific languages were in one spot. What's the likelihood of this being changed back? Parsecboy (talk) 00:12, 4 March 2010 (UTC)

I note that you've been referred to the above sub-section from Wikipedia:Village pump (technical)#Special characters. The change discussed in that sub-section was mostly limited to mixing uppper and lower case letters. I think the aspect to which you are objecting (primary sort by accent instead of by base character) was proposed on this page on 19 January 2010 in the section #Rational and friendly ordering for the Latin characters above, where User:Noetica explained the reasoning and several editors expressed support. Rather than hop about again, I've inserted a new sub-section heading before your comment so discussion can continue here with minimal confusion.

As to the point you make: there is clearly a balance to strike in addressing the conflicting needs of editors who use or are familiar with none, one or many languages with special characters. As Noetica said, alphabetical ordering is at least widely understood, whereas there is no standard accent ordering that is well known and consistent across many languages. Indeed, the repertoire of accented characters varies greatly and inconsistently from one language to another. Though the status quo is imperfect, there are also drawbacks to the alternatives. Clearly major changes are disruptive for regular editors, but it's not technically hard to change it back, so long as the reasons justify the (further) disruption to people's expectations. But it would be helpful first if you'd set out your thoughts on the points previously made.

— Richardguk (talk) 00:59, 4 March 2010 (UTC)

In regards to alphabetical ordering being the only "standard" ordering, what is non-standard about grouping by accent mark? It seems much more rational to have "Á á Ć ć É é..." than "À à Â â Ä ä..." While there is overlap between characters in different languages, it's easier for those writing in a specific one if the characters for that language aren't scattered throughout the list.

Here's an idea: can this be made into a preference option? The current system could be left as the default to minimize disruption and those who preferred the old system could choose it instead. That might be the best way to go to keep everyone happy. Parsecboy (talk) 01:19, 4 March 2010 (UTC)

It's not that the current approach is necessarily more of a standard than your preferred approach, simply that the primary order ABC...XYZ is (with locally-known exceptions) widely understood, whereas it's unlikely that most editors would agree on how to order the accents acute, breve, caron, circumflex, diaeresis, grave, macron, ogonek, tilde, etc. So making the alphabet the primary sort key, and the accents the secondary one, is useful as a universal starting point for beginner and expert alike in most languages.

For example, if I want to insert à, I know in the current ordering that a will be near the beginning. But under the alternative ordering, I'd need to know first where to find `. Personally, I'd have no idea whether that would belong near the beginnning, middle or end.

The current order broadly reflects the Default Unicode Collation Element Table. If you've examples of standards in use elsewhere, it would be helpful to let us know.

It would be possible to have separate lists for different language groups (as we already do for non-Latin scripts). But there are many Latin-based languages, and most accented characters are used in several of them, so this too would involve compromising simplicity, non-duplication or comprehensiveness.

Preference options are not so easy to create. But anyone can override the current settings with custom Javascript in their user pages. Unfortunately, this would be a bit technical for many editors.

— Richardguk (talk) 02:58, 4 March 2010 (UTC)

I don't think the order of the accents is all that important. Once a system is set up, one needs only a few uses to remember where on the list the characters s/he needs are. And the problem you highlight with knowing where the specific accents are is also present in the current version. For instance, I needed a "u" with umlaut for this edit; I had to dig through the list of "u"s to find the one I needed, because I didn't know if the umlaut would be at the beginning, middle, or end. Parsecboy (talk) 13:57, 5 March 2010 (UTC)

But that is a rather a "common symbol" point of view. There are many more accents outside the 5 most used. And putting those in a rather arbitrary order, like they used to be, was a problem for editors that actually needed to use them. I think this is a much more logical ordering. The problem you are posing is, do we put the western European editors "ease" in priority over that of the other editors that use symbols that are the most difficult to enter. —TheDJ (talk • contribs) 15:15, 5 March 2010 (UTC)

I'm only using the example of umlauts because that's what I use here on en.wiki. I could personally care less where the umlauted letters were located. You could put them last or in the middle or wherever you please—as long as they're all together it's much easier for me (and presumably others who use any given accent set in regular editing). And moreover, who said anything about putting the Western European accents first? Also, I'm confused by your assertion that some of the accents more difficult to enter. You just click the letter you want, and there you have it. Parsecboy (talk) 22:02, 5 March 2010 (UTC)

I would like to add a basic table code to my Edittools. However space and returns don't work well (they get separated as individual buttons).
I found the solution by going through the Extension:CharInsert page: replace spaces with <nowiki> </nowiki> and new lines with 

Here is the line you should add to Edittools: (see source for the actual text to copy/paste)

{| class="wikitable sortable"�|-�! Header1 || Header2�|-�| a || b�|-�| c || d�|}

Fabricebaro (talk) 18:06, 1 February 2010 (UTC)

To get the EditTools object to work with the Usability Initiative's Beta features, the following code needs to be added to the top of the EditTools.insertTags function. Any other wikis that have copied this code need this patch as well.

if ( typeof $j != 'undefined' && typeof $j.fn.textSelection != 'undefined' ) {
 $j( '#wpTextbox1' ).textSelection(
  'encapsulateSelection', { 'pre': tagOpen, 'peri': sampleText, 'post': tagClose }
 );
 return;
}

--

Deployed, seems to work. Good work Trevor. —TheDJ (talk • contribs) 11:04, 9 February 2010 (UTC)

I assume that the removal of &nbsp; from the Wiki markup section[2] was unintended. — Emil J. 11:32, 9 February 2010 (UTC)

A bug in the new editor apparently. Scheduled to be fixed later today. —TheDJ (talk • contribs) 12:38, 9 February 2010 (UTC)

That bug is fixed now. I also fixed up the code in Edittools.js and the example above so it doesn't cause a JS error for users that don't have beta enabled. --Catrope 19:14, 9 February 2010 (UTC)

Users might notice a problem that after inserting a char, the cursor moves to position 0 in the texteditor. According to Trevor this is an issue with encapsulateSelection() that is also the cause for bugzilla:22477 and bugzilla:22492. —TheDJ (talk • contribs) 22:56, 12 February 2010 (UTC)

Was something modified in this such that if you click one of the links, it automatically sends the line you are adding it to to the top of the edit window? It never seems to have done this before tonight.—Ryūlóng (竜龙) 04:59, 14 February 2010 (UTC)

See the last sentence above your post :D —TheDJ (talk • contribs) 10:40, 14 February 2010 (UTC)

Aha.—Ryūlóng (竜龙) 11:06, 14 February 2010 (UTC)

Has it already been fixed? I don't see the problem. I even tried logging in with my other account that doesn't have any extra settings and turning of my adblocking of the usability scripts etc. But I still can insert characters as usual, without my cursor moving anywhere. (I use monobook, Firefox 2.0 and WinME.)

--David Göthberg (talk) 23:38, 14 February 2010 (UTC)

The problem only presents for users with the Beta enabled. —TheDJ (talk • contribs) 23:59, 14 February 2010 (UTC)

Yeah, it seems to have been fixed now.—Ryūlóng (竜龙) 01:14, 15 February 2010 (UTC)

Oh wait, the iframe editor was disabled late friday. So encapsulateSelection is not used atm. —TheDJ (talk • contribs) 01:20, 15 February 2010 (UTC)

Okay, I this suggestion may be shot down instantly, but can we have a new section for smileys and/or emoticons. These are harmless and on a text-only interface can help to reduce tension and clarify an editor's meaning. — Martin (MSGJ · talk) 14:12, 23 February 2010 (UTC)

You mean like these

WP:EMOTE? Can't see it happening as except for three (the three worst) they're images, which you don't want loading every time you edit a page. Personally can't see much use for them: this is not Facebook, and anything you want to write that needs a "just kidding" graphic to reduce tension probably shouldn't be written. Just write what you mean clearly and neutrally in the first place.--JohnBlackburne^words_deeds

14:57, 23 February 2010 (UTC)

Smileys are evil (evil!). See the TFDs for the deleted

=)}}. Sigh. Little yellow heralds of AOL doom. -- Quiddity (talk

) 18:47, 23 February 2010 (UTC)

Of course. That's this "usability initiative compatibility" thing. Seems to me that should be called only if the active text input is wpTextbox1. Maybe Trevor, who suggested that broken code, could fix it, too. Lupo 13:01, 5 March 2010 (UTC)

Proposed fix. Usability Initiative's jquery.textSelection.js is only supposed to work with textareas, but as far as I can tell it works just as well with input fields. Anyone sees a problem with that? Works here for me in FireFox. Amalthea 15:57, 12 May 2010 (UTC)

I've put it live. Amalthea 11:59, 18 May 2010 (UTC)

Just noticed that the angle brackets in the maths set of tools are wrong. I noticed it a while ago but only just realised what the problem is and how to fix it.

The brackets at the moment are "〈" and "〉", Unicode 3008 and 3009, which are far wider than they should be. This is as they are CJK brackets, i.e. from the "CJK Symbols and Punctuation" block, and so are the width of Chinese or Kanji characters. It may also explain why some editors are having trouble seeing them, as has come up at

The proper mathematical symbols, from the "Miscellaneous Math Symbols A" block, are "⟨" and "⟩", Unicode 27E8 and 27E9 respectively. These are common symbols - or at least occur in dozens of fonts that I have, including a system font, Code 2000 and Junicode. But more importantly they are clearly more appropriate than the Chinese punctuation there are the moment.--JohnBlackburne^words_deeds 12:20, 10 June 2010 (UTC)

Y Done, thanks! Amalthea 12:33, 10 June 2010 (UTC)

I added a line specifically for the IPA symbols used at

Put stress up front, as people tend to use apostrophes. Ordered ŋ-ɡ for ease of entry. Added ər after ə to help separate ɵ, which looks like ə at small font sizes. Added ɑr, ɔr so people don't have to delete the length sign. — kwami (talk) 01:49, 24 June 2010 (UTC)

Is there a way to make the text "When you click Save, your changes will immediately become visible to everyone." dependent on whether it actually will, or instead will pend? Rich Farmbrough, 20:06, 28 June 2010 (UTC).

At the moment, I don't think so. But with bugzilla:24004 implemented, it should be possible. Editpages aren't cached anyways, so it wouldn't be a huge performance penalty or anything. —TheDJ (talk • contribs) 20:44, 28 June 2010 (UTC)

Why don't we just make a slight modification to the text? Copying my post from here...

My suggested text until the trial is over (and then restored if, later, this is fully implemented) would be something like this:

• When you click Save, your changes will immediately become visible to everyone.
• Some pages will require edit approval before being visible in the article.
• If you wish to run a test, please use the Sandbox instead.

That way the expectation is there that the edit may not be there immediately, which is good in case any other script saying such doesn't work and the wrong expectation is delivered. Optionally, we can state that it applies generally to anonymous users. I've kept the two original lines already there (I just split it into two lines) and added the middle one, but the wording is by no means finalized and if something is better, use it. =) CycloneGU (talk) 21:30, 28 June 2010 (UTC)

Pending changes articles already have "Note: Edits to this page are subject to review (help)" message above the edit box. Technically it's possible for JavaScript to check for the presence of that message, although it would be a very ugly hack. — AlexSm 14:46, 29 June 2010 (UTC)

Ah, I did see this. I guess the information at the bottom just conflicts with the top, perhaps the suggesting editor wants to move it to the bottom. I dunno...CycloneGU (talk) 17:36, 29 June 2010 (UTC)

Maybe we should simply change the word "immediately" to "generally"? Rich Farmbrough, 18:32, 29 June 2010 (UTC).

That would be one option. =) Or even "within a few minutes". CycloneGU (talk) 19:15, 29 June 2010 (UTC)

One reasonable way is to simply remove the text "When you click Save, your changes will immediately become visible to everyone" on edit pages when Pending protection is in place. Another is to modify the script so that, e.g. when Level 1 is engaged, for non-autoconfirmed users the text is replaced with something like

"Edits to this page by anonymous or newly registered users are subject to review before becoming visible to everyone"

With Level 2 just use an appropriate variation. For example,

"Edits to this page are subject to review by a reviewer or administrator before becoming visible to everyone."

... Kenosis (talk) 12:18, 1 July 2010 (UTC)

• By the way, this was discussed recently at
  WP:VPPR#This sentence is no longer valid and didn't seem to obtain a consensus to change. — Martin (MSGJ · talk
  ) 12:46, 1 July 2010 (UTC)

Thanks. I'll post my same comment there. Something along these lines should be a simple enough fix for the WP programmers. ... Kenosis (talk) 15:07, 1 July 2010 (UTC)

• I am trying to modify some edit tools on Urdu Wikipedia. First I found out that the file Edittools.js does not even exist there. After I copied from here, it looks like the file is not loaded. I do not know how to cause it to load. Will some php files need to be modified? Can anyone help me in this regards? It will be greatly appreciated. --کاشف عقیل (talk) 02:46, 30 July 2010 (UTC)

I propose to re-order the Greek polytonic characters so that, for a given letter all iota-subscripted forms are grouped together and follow the unsubscripted forms:

'Greek': 'ΆάΈέΉήΊίΌόΎύΏώ ΑαΒβΓγΔδΕεΖζ ΗηΘθΙιΚκΛλΜμ ΝνΞξΟοΠπΡρΣσς ΤτΥυΦφΧχΨψΩω ᾺὰᾶἈἀἉἁἌἄἊἂἎἆἍἅἋἃἏἇ ᾼᾳᾴᾲᾷᾈᾀᾉᾁᾌᾄᾊᾂᾎᾆᾍᾅᾋᾃᾏᾇ ῈὲἘἐἙἑἜἔἚἒἝἕἛἓ ῊὴῆἨἠἩἡἬἤἪἢἮἦἭἥἫἣἯἧ ῌῃῄῂῇᾘᾐᾙᾑᾜᾔᾚᾒᾞᾖᾝᾕᾛᾓᾟᾗ ῚὶῖἸἰἹἱἼἴἺἲἾἶἽἵἻἳἿἷ ῸὸὈὀὉὁὌὄὊὂὍὅὋὃ ῤῬῥ ῪὺῦὐὙὑὔὒὖὝὕὛὓὟὗ ῺὼῶὨὠὩὡὬὤὪὢὮὦὭὥὫὣὯὧ ῼῳῴῲῷᾨᾠᾩᾡᾬᾤᾪᾢᾮᾦᾭᾥᾫᾣᾯᾧ {\{Polytonic|+}}'

Currently the iota-subscripted forms are mixed in with the unsubscripted forms and precede them, which somehow makes it hard for me to find the letter I'm looking for. I've had one reaction from other editors: "I don't really have a problem with the present form, but separating the iota subscript does indeed make sense."  --Lambiam 00:44, 1 August 2010 (UTC)

I'd agree with that one comment. I don't have any problem with the status quo, but your proposed change would be fine too. +

gr

07:07, 1 August 2010 (UTC)

{{

My workaround for this is either manually add the <references /> tag to the bottom of the section I'm previewing, to see what the references look like, or to edit the whole page (sometimes closing the section edit and opening a full page edit to do so) to see e.g. references which are used in multiple sections. I notice a couple of JS solutions in that bug thread too, which I've not looked at. It seems more like the sort of thing that should be a user option, e.g. an optional gadget, but I'm not sure the bet way of getting something like this added.--JohnBlackburne^words_deeds 18:24, 7 August 2010 (UTC)

The only JS solution offered creates a box that basically says "there are ref tags here, and this is what they say" in preview, without rendering them. I would like them rendered in preview.   —

G.  ツ

18:38, 7 August 2010 (UTC)

Is there an actual solution presented to this problem ? If so, I don't see it. Someone can create a 'fix' and then we can consider applying that fix here. —TheDJ (talk • contribs) 19:51, 7 August 2010 (UTC)

The potential solution is to simply add <references />. I'm trying to get it tested here.   —

G.  ツ

21:38, 7 August 2010 (UTC)

I already tested it here and it doesn't work. I wouldn't be logical to work. There is a very clear separation between content and interface. The Edittools are part of the interface of the website. —TheDJ (talk • contribs) 21:52, 7 August 2010 (UTC)

I figured that would happen. So it looks like the way for people to test reference appearance is to just stick <references /> into the text before preview and remove it afterwards. Interface hacks aren't going to help here. Reach Out to the Truth 22:42, 7 August 2010 (UTC)

The userscript at user:js/ajaxPreview provides a <references /> preview when editing sections. Possibly the code there, or someone at its talkpage, could help here? HTH. -- Quiddity (talk) 21:16, 9 August 2010 (UTC)

If you really care about references, user:Anomie/ajaxpreview.js does much more, it even checks for named references from other sections. Of course, JavaScript solutions have nothing to do with Edittols. — AlexSm 22:03, 9 August 2010 (UTC)

Thanks for both of those!   —

G.  ツ

03:38, 13 August 2010 (UTC)

In the line: 'Please do not copy and paste from copyrighted websites – only public domain resources can be copied without permission.'

If we change 'website' to 'sources', this covers a wider variety of media, should probably change 'resources' to 'material' at the same time to avoid repetition of 're/sources'. Lee∴V (talk • contribs) 23:23, 25 August 2010 (UTC)

Agree that "material" is more readable than "resources". But I think the word "websites" is helpful to retain because, though your revised text is more logical, websites are especially vulnerable to inadvertent infringement because of the ease of copy-pasting combined with the likelihood that many new editors are used to thinking of the internet as "free". How instead keeping the word "websites" but replacing the dash after it with a full stop? "Please do not copy and paste from copyrighted websites. Only public domain material can be copied without permission." With two sentences, we avoid the non sequitur. — Richardguk (talk) 23:42, 25 August 2010 (UTC)

Yes, that'd be good enough ... and I think that's the first time I've understood non sequitur, I do believe that was my problem with the sentence in the first place :) ! Lee∴V (talk • contribs) 23:55, 25 August 2010 (UTC)

Hi!!

Is there any reason to keep the Symbols, Latin, Greek, IPA, etc... characters duplicated 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. Helder (talk) 13:00, 22 September 2010 (UTC)

Possible reason, because some editors have the toolbar turned off, by unmarking Preferences->Editing->"Show edit toolbar". (I did until a few weeks ago. I only turned it back on to test out the reftools gadget). — I'm not sure how many editors have turned it off though? If it were a tiny number, or if we could technically turn that Preference-option into a "switch" (whereby turning one off, would turn on the other), then that might be worth it. HTH. -- Quiddity (talk) 16:15, 22 September 2010 (UTC)

We could at least use the interface toolbar for users which have it enabled, as suggested by DieBuche: 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. Helder (talk) 14:14, 7 October 2010 (UTC)

Do note that although the toolbar can be turned off, the edittools can not (bugzilla:11130).

So, currently, the only way to let the users to disable the unnecessary tools is moving them to a place where it can be enabled/disabled easily by anyone: a section of the toolbar. Helder (talk) 02:52, 17 October 2010 (UTC)

I added a couple to markup, including {{#tag:ref|...|group="note"}}. The "note" part may not be what everyone wants, but I figured it would be common, and no harder to change than to add s.t. from scratch. Anyway, you can use it for footnotes with embedded ref markups, as at Rongorongo#Notes, a valuable bit of code for a well-ref'd article, and one that took me a long time to find. — kwami (talk) 07:53, 30 September 2010 (UTC)

The curly quotation marks (‘’ “” ″ ′) should be removed from the Insert toolbar. According to

I agree. Remove them. JIMp _talk·cont 03:53, 13 June 2011 (UTC)

Agree absolutely. But put them in at Symbols, because they are far more common than, say, ₴, ₥, ₰, or ₪! They can do little mischief relocated there – and separated rather than paired. Noetica^Tea? 04:50, 13 June 2011 (UTC)

Yes, having them in Symbols would be fine, I think. InverseHypercube 21:25, 15 June 2011 (UTC)

Jimp, being an administrator, can you fix it? There seems to be consensus. InverseHypercube 09:08, 25 June 2011 (UTC)

I can edit protected pages but I'm not quite sure what to do. I tried deleting them but their still there. I'm reverting myself for now. JIMp _talk·cont 02:47, 26 June 2011 (UTC)

I think you have to edit this one: MediaWiki:Edittools.js. InverseHypercube 03:01, 26 June 2011 (UTC)

I did but there was no change. Perhaps I did the wrong thing. I'm not familiar with the code but I suppose I could learn it. JIMp _talk·cont 15:39, 26 June 2011 (UTC)

I believe that you need to amend both MediaWiki:Edittools and MediaWiki:Edittools.js. --Redrose64 (talk) 15:47, 5 August 2011 (UTC)

See earlier discussion at Wikipedia:Village pump (technical)#Arabic character-entry tool --Redrose64 (talk) 21:00, 5 August 2011 (UTC)

Adding some common transliteration characters to the Arabic character-insert tool could be a good idea. However, the list includes ǧ, which is not part of standard English-language transcriptions of the Arabic language, and whose use to transcribe Arabic words should not be encouraged (unless perhaps in a very limited way to transcribe Egyptian-dialect forms only). I would highly recommend the removal of ǧ. Thanks... AnonMoos (talk) 20:50, 5 August 2011 (UTC)

One of the core points of

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

"When you click Save" => "When you click Save page". The button is labelled "Save page" nowadays, right? Sada Abe (talk) 00:06, 16 November 2011 (UTC)

Done Anomie⚔ 02:09, 16 November 2011 (UTC)

Can we change it to "Please

Write powers of unit symbols with html e.g. 5 km² not Unicode superscripts and subscripts. Html superscripts are easier to read.

Wikipedia:Manual_of_Style/Mathematics#Superscripts and subscripts says

Do not use special characters like ² (²) for squares. This does not combine well with other powers, as the following comparison shows:

1 + x + x² + x³ + x⁴ (with ²) versus

1 + x + x² + x³ + x⁴ (with <sup>2</sup>).

So why do we have them here? JIMp _talk·cont 16:21, 4 December 2011 (UTC)

Check the archives for previous discussions. There is a discussion somewhere— probably

WP:MOSNUM —that concluded these characters are useful in tables and templates. ---— Gadget850 (Ed) ^talk

13:25, 7 December 2011 (UTC)

MOSNUM now states "The use of the few Unicode symbols available for fractions (such as ½) is discouraged entirely, for accessibility reasons among others." Wikipedia:Manual of Style/Accessibility states "Screen readers without Unicode support will read a character outside Latin-1 as a question mark." -— Gadget850 (Ed) ^talk 14:50, 7 December 2011 (UTC)

Maybe they should be removed, then. — Carl (

CBM · talk

) 18:44, 7 December 2011 (UTC)

Coming from the math project, I can say that the Math MOS is only intended to deal with math - not with superscripts that might appear elsewhere (and even units I would count as "elsewhere"). So Math MOS on its own would not prohibit the use of these symbols in a text setting. — Carl (

CBM · talk

) 14:27, 7 December 2011 (UTC)

I've been working on a user script where the obvious thing to do is add a new entry to the Edit Tools. I see this can be done easily enough by setting window.charinsertCustom, except that I would need to be able to have my new 'tool' link do something more complicated than just call insertTags(). It turns out this is easy to make possible. Would anyone have any objection to my making that change? Anomie⚔ 19:14, 11 December 2011 (UTC)

When I select "Wiki markup", and click on #REDIRECT [[]] I get #REDIRECT.[[]] - note the period. If the target page is added to that, and the page saved without removing that period, the redirection fails. Removal of the period fixes it. Why is this happening now? MediaWiki:Edittools.js didn't generate a period a week or two back, and I don't recall it ever doing so. I'm not much of a javascript coder myself, but I think that this line:

	tagOpen = tagOpen.replace(/\./g,' ');

is not working properly. --Redrose64 (talk) 20:06, 12 December 2011 (UTC)

My fault. Should be fixed momentarily. Anomie⚔ 20:43, 12 December 2011 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Could Please post only [[Wikipedia:Wikipedia is an encyclopedia|encyclopedic]] information be changed to Please post only [[Wikipedia:Wikipedia is an online encyclopedia|encyclopedic]] information to avoid the redirect. Cheers, Jenks24 (talk) 06:35, 2 February 2012 (UTC)

 Done Thank you for reporting it Petrb (talk) 15:22, 2 February 2012 (UTC)

For the symbols window "IPA (English)" we have all the letters that aren't on a keyboard (ɹ is curiously absent), followed by a pre-made list of non-keyboard vowels and diphthongs. That's all fine. But for the full IPA window, the order goes like this: "plosives, fricatives, nasals, approximants, trills/taps, co-articulated sounds (?), implosives, clicks, vowels, superscript modifiers, several letters with diacritics in no apparent order, three affricates, tonal symbols, two more letters with diacritics, and the {{IPA|}} template". I think that menu could really be improved; I don't tend to think of the type of articulation, but of the place. In addition, there are no combining diacritics other than the pre-made ones (which I've never found useful), so occasionally I've had to open a word-processing document to get those diacritics. Interchangeable|talk to me 23:26, 16 February 2012 (UTC)

meta:MediaWiki:Edittools can insert <code><nowiki></nowiki></code> in a single step. I suggest the same here. They often go well together but people frequently omit one of them or mess up the order or syntax. PrimeHunter (talk) 13:40, 30 March 2012 (UTC)

Hello, I've been trying to implement this on My home wiki and cannot seem to find all of the css / javascript / or something and it is not working as intended.. Can someone point me in the right direction? -- Technical 13 (talk) 21:39, 6 April 2012 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

The variables defined in the following part of the script

if (typeof (EditTools_set_focus) == 'undefined')
   var EditTools_set_focus = true;
 
if (typeof (EditTools_set_focus_initially) == 'undefined')
   var EditTools_set_focus_initially = EditTools_set_focus;

are never used in the script. (The script comes from User:Ilmari Karonen/edittools.js, which included code from commons:MediaWiki:Edittools.js, and the variables were used only on Wikimedia Commons)

Please remove these lines.

Also, consider moving this and the loader code from

There actually are people who have it disabled ? —TheDJ (talk • contribs) 21:06, 29 June 2012 (UTC)

Well...

not documented (I wasn't aware of it until I started reviewing the portuguese version of this script and come here to check what the EditTools_set_focus was used for) and default gadgets

were created to make these settings easier.

One more thing: I think this should really be loaded minified by Resource Loader, and as soon as

Helder

21:32, 29 June 2012 (UTC)

Partly done: Useless variables removed. Gadgetizing edittools is a but much for an {{

editprotected}}, so that part is not done. Take that to Wikipedia:Gadget/proposals. Anomie⚔

20:58, 1 August 2012 (UTC)

'Please do not copy and paste from copyrighted websites'??? But that's often an excellent idea, where the copied content is free...--Elvey (talk) 16:50, 20 July 2012 (UTC)

If it's copyrighted, it's not free. --Redrose64 (talk) 17:19, 20 July 2012 (UTC)

You're ignorant of the facts. Read the first three sentences of the CC license! Sentence 2 begins, "THE WORK IS PROTECTED BY COPYRIGHT."--Elvey (talk) 16:14, 20 August 2012 (UTC)

Editrequest Copyright notices

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Can we change the one that says 'Please do not copy and paste from copyrighted websites – only public domain resources can be copied without permission' to "Please do not

Not done: Sorry, but I don't really see any consensus to change this text in those discussions. The version you are proposing here is slightly different than the ones in the discussions, and this text could have legal ramifications for the WMF. I suggest starting an RfC at the village pump with a few different options that people can comment on. Best — Mr. Stradivarius ^{(have a chat)} 19:57, 22 August 2012 (UTC)

Groan. Those discussions show that feedback has been solicited and obtained from WMF legal counsel - see comment by Stephen LaPorte (WMF)! The village pump is a great place to get feedback from folks who know hardly anything about copyright or policy. And I did get consensus support for the essential change there. --Elvey (talk) 00:54, 14 September 2012 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Can we change the one that says 'Please do not copy and paste from copyrighted websites – only public domain resources can be copied without permission' to "Please do not

I also welcome feedback on any tweaks.--Elvey (talk) 01:00, 14 September 2012 (UTC)

 Done — Martin (MSGJ · talk) 20:49, 19 September 2012 (UTC)

Thank you for making the important clarification of policy I identified and have been battling to fix for so long.--Elvey (talk) 02:28, 20 September 2012 (UTC)

After a discussion at Wikipedia:Village pump (technical)#1/6 3/5 "Symbols" I suggest to remove all fractions except ½. All other fractions are hard to read for many (most?) people. The currently listed fractions are: ½ ⅓ ⅔ ¼ ¾ ⅛ ⅜ ⅝ ⅞ (1/2 1/3 2/3 1/4 3/4 1/8 3/8 5/8 7/8). Wikipedia:Manual of Style/Dates and numbers#Fractions says: "The use of the few Unicode symbols available for fractions (such as ½) is discouraged entirely, for accessibility reasons among others." I'm divided about ½. PrimeHunter (talk) 22:30, 13 September 2012 (UTC)

• Unless there is a general prohibition of their use at MOS, I would say leave them in the palette. I actually believe fractions are preferable: '⅔' is certainly a lot less ambiguous universally than '2/3', and a lot less cumbersome than '²/₃'. -- Ohconfucius ^{ping / poke} 03:27, 18 September 2012 (UTC)
  • I forgot about {{
    frac}}, so I would support deprecation of listed fractions. The latter would be rendered too small to be legible inside infoboxes anyhow. However, I would suggest that {{frac}} be included in the 'symbols' palette at the same time as the withdrawl of the listed fractions. -- Ohconfucius ^{ping / poke}
    09:09, 20 September 2012 (UTC)
• There is archived discussion here and at MOSNUM. I think one of the MOSNUM discussions concluded that Unicode fractions are useful for tight spacing such as tables, navboxes and the like. ---— Gadget850 (Ed) ^talk 03:30, 18 September 2012 (UTC)
• Support removal ("½" included) They're hard to read. For consistency replace them with {{frac|}} ({{
  frac}} isn't particularly cumbersome). The line from Wikipedia:Manual of Style/Dates and numbers#Fractions quoted above ("The use of the few Unicode symbols available for fractions ...") is a general prohibition of their use at MOS. "divided about ½", nice pun, ditch this one too (obscure pun). JIMp _talk·cont
  08:09, 18 September 2012 (UTC)
• Remove all My eyesight isn't perfect (partly due to age, but it never was brilliant), and unless I really concentrate, or zoom in by about three levels, I don't immediately see a difference between ½ and ⅓, or between ⅓ and ⅛. There are other pairs which I have difficulty in distinguishing, but I won't bother cluttering this discussion: suffice to say that the only one which is obvious at first glance is ¼ and even then I always type {{
  frac|1|4}} which displays as 1⁄4. --Redrose64 (talk
  ) 12:51, 18 September 2012 (UTC)
• Remove all They're too small and hard to read, especially in edit mode. (At least the fifths and sixths, which are even more illegible, aren't there. Did Unicode ever encode sevenths or ninths?) {{
  frac}} should be added under "Symbols" (which should immediately put text like {{frac|numerator|denominator}}). Double sharp (talk
  ) 14:42, 22 September 2012 (UTC)
  • Partially: ⅐ and ⅑ - but apparently there are none where the
    numerator is not unity. Full (?) list here. These two don't display properly for me, so I can't comment on their legibility: but this implies that they're not widely supported, so their use is even less accessible than ⅓ etc. --Redrose64 (talk
    ) 21:56, 22 September 2012 (UTC)
• Is there any chance of getting adding something intermediate in size between the unicode characters and the output of {{
  frac}} which would be more suited to infoboxes and such while remaining accessability friendly?Nigel Ish (talk
  ) 20:35, 22 September 2012 (UTC)

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

If the {{

frac

}} template does not increase line height, there is no need for reducing size at all:

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod

temporincididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation
ullamco 1⁄2 laboris nisi ut aliquip ex ea commodo consequat.
Duis auteirure dolor in reprehenderit in voluptate velit esse cillum
dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident

-DePiep (talk) 09:25, 25 September 2012 (UTC)

Edittools has vanished from the new editing interface. Can it be rescued or is it gone for good? Manually signing with four keystrokes Wbm1058 (talk) 01:38, 28 September 2012 (UTC)

It's affected by changes to the edit window and should soon come back. See Wikipedia:Village pump (technical). PrimeHunter (talk) 02:08, 28 September 2012 (UTC)

If you turn off "Enable enhanced editing toolbar" in your preferences, it should come back. Although it is currently moved from its old position below the "Save page" and other buttons to between the main textarea and the edit summary. Anomie⚔ 03:02, 28 September 2012 (UTC)

MOSNUM says

Write powers of unit symbols with HTML e.g. 5 km² not Unicode superscripts and subscripts. HTML superscripts are easier to read.

I therefore propose we remove "m²" and "m³". JIMp _talk·cont 16:12, 18 September 2012 (UTC)

• what about "²" and "³"? -- Ohconfucius ^{ping / poke} 09:28, 20 September 2012 (UTC)

Yes, no, they don't belong here either. JIMp _talk·cont 06:24, 21 September 2012 (UTC)

I have deleted these. JIMp _talk·cont 08:04, 28 September 2012 (UTC)

You forgot to also delete them from MediaWiki:Edittools. Fixed. Anomie⚔ 14:53, 28 September 2012 (UTC)

...for when the js fails to load or when a user turns off js, making it match the js one may not be the best idea as this stuff is not collapsible. Ideally it would be a lot smaller, so perhaps we should consider what all it is people actually need and then toss the rest of it? -— Isarra ༆ 18:41, 28 September 2012 (UTC)

There actually are already a number of things that are in the JS version but not in here: some of the wikitext entries, some of the Greek and Cyrillic, all the Hebrew and Arabic, all of the "math and logic" symbols, and some of the IPA symbols. The problem comes in trying to decide which things these non-JS users "actually need", since we have no way to know who they are or any way to really ask them. Anomie⚔ 19:30, 28 September 2012 (UTC)

We could try randomly guessing and adding a Complain here link to the bottom - then just update it as people complain. -— Isarra ༆ 20:14, 28 September 2012 (UTC)

While we're on the subject,

MOS:QUOTEMARKS recommends against the use of typographic quotes (single and double), yet both of these are available in edittools ‘’ “” between the em-dash — and the degree °. --Redrose64 (talk

) 19:54, 22 September 2012 (UTC)

I just found the place where I first brought up this subject - Wikipedia:Village pump (technical)/Archive 68#Quote style. --Redrose64 (talk) 21:14, 30 October 2012 (UTC)

• Oppose removing the music symbols "♭", "♯", and "♮". That recommendation at
  WP:MOS). Since there are rare legitimate uses of ‘ ’ and “ ” (as in discussion of typography), they should still be available: but in the Symbols set below, and not in the Wikipedia markup set. And definitely not in the privileged Insert set, where these deprecated forms have absurd prominence, in third and fourth position!
  ♫♪
  Noetica^Tea?
  22:07, 22 September 2012 (UTC)
• Agree with Noetica. I use the smart quotes fairly often, but they should not be displayed so prominently. — kwami (talk) 07:15, 23 September 2012 (UTC)
• Agreed with Noetica also-- both about the music symbols, that do have several uses, and are needed, and the typographical quotes, which almsot never are: it's time to get these well hidden to avoid error--those who need them will find them. DGG ( talk ) 03:59, 26 September 2012 (UTC)
  • The typographic quotes were removed from the "Insert" and "Wiki markup" groups (but left in the "Symbols" group) as part of the 25 September 2012 changes. --Redrose64 (talk) 13:19, 26 September 2012 (UTC)
    • Excellent! Thank you. Noetica^Tea? 13:29, 26 September 2012 (UTC)
• Comment: The template {{music}} returns the Unicode defined characters "♭", "♯", and "♮", be it in a different font. -DePiep (talk) 01:29, 30 September 2012 (UTC)
  • Yes, but apparently on some versions of IE the accidentals do not display properly without {{music}} (IE8 and IE9 don't seem to have this problem, though.) Double sharp (talk) 08:26, 2 October 2012 (UTC)
    • The whole of IE is an accident. They can't seriously expect us to believe it was designed, can they? --Redrose64 (talk) 16:18, 2 October 2012 (UTC)

Still, Double sharp has a point I missed: using template {{music}}, even though it produces the Unicode chararcter all the same, adds a font selection that helps showing the glyph in AnyBrowser. Removal from the list is relevant. (Best option: template-link in this edittool list). -DePiep (talk) 21:09, 2 October 2012 (UTC)

• Comment – Not everyone is a super-sophisticated wiki-editor and computer programer like those of us who read and comment on this page—and who's decisions will affect editors of all skill levels. I think it's fair to say that the "average editor" is one who's skill set doesn't include using a template (what's that?, they ask) with various parameters to input a simple symbol. So yes, while it's good to strive to make things technically correct and compliant, I think it's also important to bear in mind those who will have to it. The technical complexities of HTML/Wikicode are indeed a roadblock for us acquiring new editors. Senator2029 • talk 12:08, 17 October 2012 (UTC)

The non-breaking space symbol appears to have been removed from edittools - as this is probably one of the most important and heavily used items on the toolbar, can someone restore it?Nigel Ish (talk) 08:41, 1 October 2012 (UTC)

It's actually still there, but invisible: under "Wiki markup" there is an extra-wide gap between #REDIRECT [[]] and <s></s>; similarly under "Math and logic" there is an extra-wide gap between {{

frac||}} and − - these gaps contain the  . Move your mouse into the gap and the pointer should change when you reach the invisible link. --Redrose64 (talk

) 14:25, 1 October 2012 (UTC)

Reported as

Clear your cache and it should be showing for you now. Anomie⚔

14:35, 1 October 2012 (UTC)

Could someone tell me how to add custom edit tool options using personal css or js? 64.229.0.191 (talk) 02:26, 2 November 2012 (UTC)

In the JS version of the tools, "Sign your posts on talk pages:" and "Cite your sources:" are bolded. There is no reason to do this, as they are not the most important actions in the information hierarchy of the page and the emphasis is quite annoying for those of us who don't use the tools. On talk pages, there are already edit notices which advise users to sign posts, and the same goes for articles when it comes to citing sources. I would remove the bolding myself, but can't see where in the JS/CSS it is occurring... Steven Walling • talk 20:08, 11 November 2012 (UTC)

All of the "subsection headings" are bolded, not just those. I find that the bolding helps find the subsections in the midst of all the links.

If the tools annoy you so much, why not turn them off entirely? Anomie⚔ 23:02, 11 November 2012 (UTC)

Ah, I see now that it's actually different in the non-JavaScript version. In the JS version which most people see, a dropdown is used, so only the two items I noted are bolded. I think consistency in the non-JS version makes sense, so bolding should be all or nothing, but would still like to see it changed in the JS-enabled version.

The reason I bring it up is not that it personally is very annoying. I know how to hide things with personal CSS/JS. It's that it is distracting and unnecessary for new users, who have a hard enough time finding their way around the edit window. Steven Walling • talk 04:56, 12 November 2012 (UTC)

Anyway, just figured out that the addBold function is what's doing it. Steven Walling • talk 05:04, 12 November 2012 (UTC)

<!-- This div gets automatically replaced with the actual edit tools by the code in [[MediaWiki:Gadget-charinsert.js]]. Please make any changes there as well. Any content is this div is only shown to users with JavaScript turned off (or unsupported). -->

should be changed to

<!-- This div gets automatically replaced with the actual edit tools by the code in [[MediaWiki:Gadget-charinsert.js]]. Please make any changes there as well. Any content in this div is only shown to users with JavaScript turned off (or unsupported). -->

:) Cheers!···

True,  Done --Redrose64 (talk) 18:52, 17 December 2012 (UTC)

Thank you! ;) ···

_Talk」

20:18, 17 December 2012 (UTC)