This is an archive of past discussions about MediaWiki:Edittools. 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.
On the IPA tab, there is no space between əɚ so when you click on it, it enters both characters. Can that be fixed please? CodeCat (talk) 15:07, 19 January 2013 (UTC)
Wow, that is weird and confusing. For <references /> you need a ".". For <ref name="+" />, you need "_" because it's in the part after the "+" (but the space between "ref" and "name" needs a ".", because it's before the "+"). Anomie⚔20:55, 2 February 2013 (UTC)
And yet, "Sign_your_posts_on_talk_pages" uses "_" and has no "+", which I found out is the place the cursor will be inserted. These tokens should be documented. — Edokter (talk) — 23:38, 2 February 2013 (UTC)
Maybe it's just me, but I can't always type ' and " and it would be really nice if there were something I could click on to insert them. Closest things on there that I could find are ′ and ″, which just aren't the same. -— Isarra༆04:37, 4 March 2013 (UTC)
On a PC keyboard, the apostophe ' is normally on the middle row, two keys to the right of the letter L; the double quote " is either on the same key as ⇧ Shift+' (USA layout), or on the top row as ⇧ Shift+2 (British layout). The characters generated by the fourth and fifth items in the "Insert" and "Wiki markup" selections are ″ and ′ which are Unicode U+2033 "Double Prime" and U+2032 "Prime" respectively; these do not count as valid quotation marks. --Redrose64 (talk) 18:44, 4 March 2013 (UTC)
Yeah, keys are there, but they doesn't always work. Seems to only be a problem when I'm on windows, though, so it's not likely to come up for others (my windows configuration is a little odd). It's just that there are so many other things here, just not what I seem to most often wind up needing. -— Isarra༆02:39, 6 March 2013 (UTC)
My Windows/Firefox combination does occasionally behave strangely. My keyboard is UK layout, like this (but black, not coloured), and for no apparent reason Firefox can suddenly decide that my keyboard is the USA layout, and remaps the keys - those marked ¬"£@~# actually generate ~@#"|\ and (no kidding) it has actually flipped over to the other mapping whilst posting this. If I switch to a different application, the mapping is correct; switch back to Firefox, the mapping is wrong again. Closing and restarting Firefox always fixes this; it has sometimes fixed itself with no apparent intervention (let's see if that happens today). --Redrose64 (talk) 12:55, 6 March 2013 (UTC)
Again and again, new users get confused by the mention "Sign your posts on talk pages: ~~~~ " just below the edit box. So we get plenty of signatures in mainspace or in edit summaries. There is no need to have this displayed in mainspace. In wiki markup, this can be achieved by {{#ifeq:{{NAMESPACE}}|{{ns:0}}
|
| '''Sign your posts on talk pages:''' ~~\~~
}}; but I don't know if this also works for MediaWiki:Gadget-charinsert.js, which replaces MediaWiki:Edittools when js is on.
In addition, in the mention '''Cite your sources:''' <ref></ref>, "cite" may link to the tutorial on citing sources, I also don't know how to link in js. Cenarium (talk) 20:35, 2 June 2013 (UTC)
TTO, I'm thinking you'll have to test it on test.wikipedia because of the way the fallbacks work. I'll see if I can test it there. What result exactly is your modification suppose to accomplish? Technical 13 (talk) 13:44, 7 June 2013 (UTC)
I tried to test it on testwiki (it's the gadget "This, that and the other's test gadget" at the bottom of the gadgets list) but couldn't get it to work. I don't think the code's broken... but...
Basically the idea is that any token beginning with that weird Unicode character (I chose it because I didn't think anyone would ever want to insert it) will not be displayed in namespace 0. — This, that and the other (talk)00:58, 8 June 2013 (UTC)
I copied there edittools, edittools.js, Gadget-charinsert.js with your modification and Gadget-charinsert.css, and it seems to work (gadget is last from test mode, enabled by default, same as here). What do you think of also linking to the tutorial on citing sources ?
The "signature and timestamp" box in the newer editing help box (at the top of the edit window) should also likewise be removed from mainspace. However, this doesn't seem to be handled at our level, but at the wmf level. Thanks, Cenarium (talk) 15:19, 8 June 2013 (UTC)
@Cenarium: By newer editing box, do you mean Wikipedia:RefToolbar? That should lead to the needed talkpage for js-tweaking requests.
I'd wholeheartedly agree with replacing the "Sign your posts on talk pages ..." messages, in mainspace, with a link to that citations tutorial. (Possibly it should be in a new tab/window/target, like how the "Editing help (opens in new window)" works.) –Quiddity (talk) 18:17, 8 June 2013 (UTC)
We can totally disable all 3 versions, by turning off "Show edit toolbar (requires JavaScript)" and "Enable enhanced editing toolbar" in Special:Preferences#mw-prefsection-editing. ;)
I'm not sure what shows up for IP users with javascript completely turned off, my tests with Opera's F12 toggle were inconclusive (RefToolbar 2.0b was present and seemed fully functional). –Quiddity (talk) 20:09, 8 June 2013 (UTC)
Yes, I mean the toolbar which shows up by default to editors at the top of the edit window (registered or not). The toolbars that can be activated from options aren't the same (icons are not in the same order and no cite section / reftoolbar). The icon , which stands for "Signature and timestamp" likewise gives the four tildes, which isn't needed in mainspace. Okay, I'll ask at MediaWiki:Common.css then.
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
In Symbols and IPA (English), "⟨+⟩" should be replaced with {{angle bracket}}. There are accessibility issues and occasional changes that are better handled from a centralized location. — kwami (talk) 07:49, 18 December 2013 (UTC)
kwami has requested that ⟨+⟩ be replaced with {{Angle bracket|+}} on this page in the IPA (English section) as well as the matching section on MediaWiki:Gadget-charinsert.js on or about line 43 in the code. I support this change based on my understanding of what the template does. He or she would also like ° ″ ′ reordered to ° ′ ″, but I agree with Rose that these should stay as they are because of the way they are correctly used to represent degrees, minutes, and seconds respectively. Thank you for your consideration. Technical 13 (talk) 02:13, 18 January 2014 (UTC)
Actually, Rose agrees with me, as they are currently out of order (degrees, seconds, minutes).
To clarify my position: I agree with Kwamikagami that ″ and ′ are in reverse order. I've not amended it because (out of the two pages to edit MediaWiki:Edittools and MediaWiki:Gadget-charinsert.js), I have never edited the script itself; and I was rather hoping that either MZMcBride (who created it) or Anomie (who has made the most edits to that script in the last two years) would have offered an opinion, either on why it was done like that, or why it should remain as is.
I have no opinion on the angle brackets.
@Technical 13:: if you attempt to ping somebody but it fails because you got the casing wrong (in this case spelling Redrose64 with two capital R), amending the post won't trigger a ping. The (correct) link to the other user and your sig need to go on in the same edit. But I would have seen it anyway, because of watchlist. --Redrose64 (talk) 09:59, 18 January 2014 (UTC)
The angle brackets now present under Math and logic are U+27E8⟨MATHEMATICAL LEFT ANGLE BRACKET and U+27E9⟩MATHEMATICAL RIGHT ANGLE BRACKET, so they should remain there. There are also the generic ⟨ and ⟩ (⟨ ⟩) as used in {{angle bracket}}, which could be included under symbols. — Edokter (talk) — 12:48, 18 January 2014 (UTC)
I swapped ″ and ′ (also in gadget), so that part Done. I'll note that Edittools needs a big deal of updating to be in sync with the gadget. — Edokter (talk) — 12:56, 18 January 2014 (UTC)
I can't seem to paste in the 'normal' punctuation version of the angle brackets; they keep getting converted to the CJK related bracket upon saving/previewing, and I don't know what's causing it. Is there another way to put in 〈 and 〉 (&x2329; / &x232A;), with some sort of escape sequence? — Edokter (talk) — 23:38, 18 January 2014 (UTC)
In that case, it's best to leave these in. What is the compelling reason to replace it with the template using the HTML entities? — Edokter (talk) — 03:53, 19 January 2014 (UTC)
Because those brackets do not display on all browsers. We set up a template because some readers insisted on using greater-than and less-than signs, or Chinese brackets; the template uses the consensus form, and can be changed as consensus evolves. We are slowly going through WP and replacing all instances of the brackets with the template, except in mathematical formula. It's not useful to have the edit window working at crossed purposes with that consensus. Also, if we decide to format them differently, or change which brackets we use, we only have to change the template and all articles will be in sync. — kwami (talk) 06:02, 19 January 2014 (UTC)
My testing on XP and all 4 major browsers show that only IE has trouble displaying the angles, both using the numerical entiries and the &am;lang;/⟩ entities. Opera and Chrome show all the original assigned characters, and Firefox substitutes the deprecated x23xx characters for the mathematical x27xx ones. The template now use the named entities (with the unicode font), but the conclusion there is also that there currently is no universal solution. — Edokter (talk) — 12:15, 19 January 2014 (UTC)
For as long as I remember, the "Wiki markup" set has begun by repeating the whole of the "Insert" set apart from the boldface instructions to "Sign your posts on talk pages:" and "Cite your sources:". The text "Insert:" and "Wiki markup:" is added to the "Wiki markup" set, presumably so that you can see which symbols are common, and which are extra. --Redrose64 (talk) 15:42, 18 January 2014 (UTC)
That seems very redundant, not to mention confusing. I think we should avoid such duplication by either separating or merging them. — Edokter (talk) — 16:29, 18 January 2014 (UTC)
I would prefer not to separate, since I use both sets: I leave the dropdown on "Wiki markup" pretty much all the time, since I know that I can get to both sets without fiddling with menus. I think that the "Insert" set is on a separate option in order not to confuse the less experienced by offering things like <pre></pre> which they will hardly ever need to use at first. --Redrose64 (talk) 17:54, 18 January 2014 (UTC)
I'd actually like to see a couple new sets added for things like "Template code" "JavaScript code" "CSS code" etc... But, I'll open a separate edit request for that once I have a sandbox version created. Technical 13 (talk) 21:36, 18 January 2014 (UTC)
You can kill it yourself; you have to disable "Show edit toolbar (requires JavaScript)", (which is the old toolbar the edittools are linked to) under Editing options and the "CharInsert" gadget. — Edokter (talk) — 13:17, 27 February 2014 (UTC)
Why is this loaded for readers?
MediaWiki:Gadget-charinsert.js has no use when reading the articles, so there is no reason to load all this code when action is not "edit" or "submit". Consider spliting it into a small "loader" and a "core" module which would be loaded only when needed. Helder.wiki12:38, 4 March 2014 (UTC)
I de-obsfucated the link; I thought you talked about this message (MediaWiki:Edittools). But I agree the gadget should load conditionally. — Edokter (talk) — 13:04, 4 March 2014 (UTC)
Edokter, yes, I missed that "default" in the first version of the code, which should be removed. Not that it would make any difference, because no user has the (non-existing) right "hidden". So, it would be loaded by default, for no one ;-).
Is the edit page detection soundproof? Upload pages also have an edit form. I also suggest keeping the name "charinsert" for the loader as to not mess with users current settings (for those who disabled it). — Edokter (talk) — 13:54, 5 March 2014 (UTC)
By the search results, I don't think it is in use on English Wikipedia. But it could be imported from some other wiki? Maybe add a mw.log.deprecate() call for a few days/weeks and then it can be deleted (if that is what you want to do). Helder.wiki14:45, 5 March 2014 (UTC)
If other wikis are importing edittools.js, it is broken now anyway. Importing cross-wiki scripts is highly unreliable. — Edokter (talk) — 18:15, 5 March 2014 (UTC)
That doesn't tell me if any are linked to the enwiki copy. Can you do a search for "//en.wikipedia.org/w/index.php?title=Edittools.js"? — Edokter (talk) — 20:36, 5 March 2014 (UTC)
Or even better, since the script uses textSelection, just add the module "jquery.textSelection" to the list of dependencies of the gadget on its definition:
OK, I'm never doing this again until I see fully working code on test.wiki. Please don't place edit requests until your code is tested. — Edokter (talk) — 17:59, 5 March 2014 (UTC)
Recent CharInsert changes breaks certain customizations
Edokter Hi there - long time fan but mostly try to keep Wikisource up to date with your latest WP changes/advances...
Long story short - with the changes to CharInsert over the past 2 or 3 days, certain custom templates added via my common.jsthat also happen to be set to "hidden" using the Entries prefixed with ␥ (U+2425 SYMBOL FOR DELETE FORM TWO) will not appear in the article namespace (namespace 0) "trick" no longer insert properly nor are reflected correctly in the toolbar. They still "hide" from display in the mainspace as always. Any idea how to restore the previous behavior? -- George Orwell III (talk) 01:09, 8 March 2014 (UTC)
George Orwell III, I don't understand what is the problem. Could you provide a small example of what happens now and what was happening before? Helder.wiki14:33, 8 March 2014 (UTC)
Note in the 2nd example the plus symbol(s) should have been dropped all round and the lack of a 2nd piped parameter (first 2 templates) or closing quote (last 2 tags) when applied in the textarea field under edit mode (non ns-0).
To repoduce, just copy my common.js onto the test site and try inserting any of the 4 templates prefixed with ␥ (U+2425 SYMBOL FOR DELETE FORM TWO) in any namespace other than the main. -- George Orwell III (talk) 21:42, 8 March 2014 (UTC)
Helder.wiki, Confirmed over on Wikisource - this past week's changes do not induce the behavior so it is quite possible I missed the "change" that caused this oddity altogether. Sorry for pointing fingers prematurely.
Nevertheless, I'm sure this was not always the case - it did "work" as desired at some point in time. I've removed the prefix-character from templates for now, though I'm not savy enough to troubleshoot the issue any further.
One other question (and forgive me if this is obvious to experts) but why does Gadget-charinsert-core.js need the additional dependency of mediawiki.action.edit under the revised gadget? Wasn't the whole point of creating the "loader" enough to insure that? (or shouldn't mediawiki.action.edit be a dependent when loading Gadget-charinsert.js rather than Gadget-charinsert-core.js if anything?)
p.s. - if you ever get bored, we sure could use your skills to review/improve en.wikisource's .js/.css/gadget "scheme". I have always admired Wikibooks approach to all that compared to what we got stuck with but my skill set is way below what is needed to make those kind of tweaks/improvements/overhauls and, thanks to that, voicing those long needed changes to the "community" largely falls on deaf ears.
I can answer that. The -core gadget needs mediawiki.action.edit because it uses one or more funtions in that module. The loader is there for one thing only; to load the -core only when an edit page is loaded. This saves loading a lot of javascript when it is not needed. — Edokter (talk) — 11:28, 12 March 2014 (UTC)
adjustment
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Under Latin, could we have both Ə ə and Ǝ ǝ? (Make sure that the lower-case letters are matched correctly!) They're used in different alphabets.
Under Arabic, "transcription" should really be "transliteration".
Perfect. (Maybe the opposite order, so the caps go from more similar to less similar, but that's not important.) — kwami (talk) 17:32, 23 April 2014 (UTC)
Oh they still work (see Wikipedia_talk:Notifications#Typos too). Edokter you seem to have set '...DontMove' to 'true' (Why anyone wants tools below the terms of use disclaimer I'll never know) when it should have been 'false' plus you left out if(window.updateEditTools) window.updateEditTools(); as well.
Anyway, we had it "loading high" for awhile on Wikisource using something along the lines of....
... but that would up going flakey for some users after one the those core wmf upgrades. Now it just does it by itself (see here) in just one namespace!
I see charinsertDontMove isn't working reliably anymore, sigh. I use the option because I don't want it intruding between the edit box and the summary and submit buttons (and "below the terms of use disclaimer" doesn't matter to me considering I hide that with CSS). Anomie⚔13:54, 19 October 2014 (UTC)
(ec) I didn't change anything here, I just tested the options in my common.js to see what they did... nothing in my case. So why would they not work for me? -- [[User:Edokter]] {{talk}}13:58, 19 October 2014 (UTC)
... with little trouble for quite some time now. I thought the highlighted line made customization & the load order "agreeable". Other than the usual 'need to purge cache' issues, applying the above seems to work everybody either way - old style under the edit form box or stuck in between the textarea and the start of the edit summary - it works both ways.
What "we" were looking for was a third way (to load above WikiEditor) as Wikisource does a lot of transcribing (scrolling around just leads to losing the focus if you follow my drift). -- George Orwell III (talk) 14:19, 19 October 2014 (UTC)
@Edokter: I think it's "user", although whether depending on that would work I don't know.
@Anomie:, editToolsRecall = true; should enable ↕ as clickable pseudo-button to the left of the drop down menu. This lets you toggle between the current set selected and the previous set used in an editing session with only a single click opposed to having to open the drop-down and scroll back & forth or between two character sets over and over again.
Not sure why charinsertDontMove = false; isn't allowing CharInsert to load between the editing field and the edit form for you but I assure folks it is possible as it has been working for me for months now. -- George Orwell III (talk) 23:53, 20 October 2014 (UTC)
Listing user as a dependency seems to work on testwiki, so I will do so here. I'll see if the 'top' option works on testwiki as well. -- [[User:Edokter]] {{talk}}11:09, 20 October 2014 (UTC)
fwiw... the only difference I can nail down between the Wikipedia and the Wikisource approaches to the "editing tools" app scheme is that WS stopped bothering with the javascript-browser enabled (Edittools.js ?) part some time ago. Not only has the overall coding development moved away from supporting such javascripting but it would always load regardless of the condition at hand (e.g. the controlling css simply adds display: none; to the div container to "hide" the constant loading of MediaWiki:Edittools' content; just review the html source of any article already opened to edit mode to see what I'm talking about). Other than that, I'm not sure why generating the CharInsert bar "in between" works for some folks but not others. -- George Orwell III (talk) 23:53, 20 October 2014 (UTC)
@Edokter:, an additional update -- after also adding the dependency on 'user' over on Wikisource and re-adding ...
I will experiment. May I suggest renaming the option to window.charinsertMoveTop; "high" is not a common term used in programming. -- [[User:Edokter]] {{talk}}09:09, 21 October 2014 (UTC)
When I first saw "LoadHigh" in this thread, I was reminded of the MS-DOS command LOADHIGH. This was used when invoking a TSR program to persuade it to load in a segment between A000:0000 and FFFF:000F - otherwise it would reduce the memory available for real-mode user programs. --Redrose64 (talk) 09:36, 21 October 2014 (UTC)
Problem: The current (wikisource) MoveTop only works with the enhanced toolbar enabled. It also gains a blue background as a result of being part of the enhanced toolbar. Are these traits intended? -- [[User:Edokter]] {{talk}}10:19, 21 October 2014 (UTC)
The blue background (actually ghostWhite) for all 3 possible positions is new on WS because the original inherited "blue" upon using LoadTop over there was visually irritating - I don't know if the same holds true here or has any color inherited here on WP at all. I'm not so sure the blue was being inherited from WikiEditor; at any rate if "we" can plain old white back somehow, I'd make the switch for all 3 possible positions.
If we can get it to load above the Classic toolbar, that would be great too -- but not a deal breaker for us.
Its obvious VisualEditor is to be the future default for sites as "big" as Wikipedia while WikiEditor seems to be to be geared more towards the "lesser" wikis such as Wikisource. The Classic toolbar is going to be more trouble than its worth some point in the future. Still, some folks swear by it so it would be neat if could be done too.
Its hard to get folks to accept simple facts like that - things such as the popularity/need for the RefToolbar here translates to a big honkin' waste of resources elsewhere. I wish the developers would just come up with one interface (a single blank toolbar) and let folks plug in (buttons or menus) what they want after that. -- George Orwell III (talk) 13:21, 21 October 2014 (UTC)
I tend to be conservative when adding options; there can be too many. And the perfectionist that I am, I'd have to fix the CSS as well to adapt all the borders. I'm not ready to add it just yet... I'd like to see some demand from the community for a top loading charinsert. Perhaps you can organize a small RfC. -- [[User:Edokter]] {{talk}}18:01, 21 October 2014 (UTC)
Edit request
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I don't think that it's necessary. It's already in "Insert" and "Wiki markup" (third link from the left, between em-dash and single prime); and also in "Math and logic" (fifth from left, between the dot operator and the asterisk operator). --Redrose64 (talk) 21:26, 5 November 2014 (UTC)
Is it possible for an editor to customize this for individual use without replicating all the .js files? Alternatively, would it be possible to get a combined <code><nowiki></nowiki></code> option in the list of tools? I find I use this combination quite frequently; since the tool doesn't maintain focus on the selected text once it is wrapped, I have to re-select the desired text to apply the second wrap.
Also, just a quibble, but is there a way to wrap pairs in the tools so that they don't split across lines? Currently, in my browser, there is a line break between <s> and </s>. Thanks for any assistance you could provide!—D'Ranged 1VTalk01:47, 30 June 2014 (UTC)
But, I'm also curious about the initial question. Is there a way for individual editors to easily customize CharInsert? Eg. I'd like to add {{ping}} and {{u}} and a few others, at various wikis... and Slimvirgin is asking about those at Wikipedia talk:Notifications#Typos... If not, I'll have to ask about RefToolbar custom buttons... Thanks. Quiddity (talk) 02:27, 18 October 2014 (UTC)
I support PrimeHunter. This would be very useful. Even better would be a single template, but it might not be technically possible. --Mrjulesd(talk)12:59, 28 November 2014 (UTC)
More Greek letters
While I'm at it (I didn't realize this place existed!), I'd suggest including a few more items in the Greek menu: Ϝϝ (digamma, used in some early Ancient Greek words), υ̯, and ι̯ (upsilon and iota with combining inverted breve below, used to represent the sound of digamma and a consonantal y), ᾹᾱᾸᾰῙῑῘῐῩῡῨῠ (Greek vowels with macrons and breves, used to show vowel length when necessary), and ΪϊΐῒῗΫϋΰῢῧ (letters with diaereses). I would put the digamma and iota-with-diacritic at the end of the alphabet (they're consonants not usually included in the alphabet), the letters with macrons and breves after all of the accented letters (they are strictly speaking not usually used, except in grammars and dictionaries), and the letters with diaereses with the iotas and upsilons in the lineup of accented letters. Perhaps these things have been suggested and refused, though. — Eru·tuon09:58, 30 December 2014 (UTC)
Inclusion of more templates
I posted in Village Pump regarding {{Polytonic}}, which till recently was included in the special character inserter below the edit box. This template is now deprecated, and I have been adding {{lang|grc|}} as a replacement for it in articles on Ancient Greek (which is where polytonic Greek is used). I suggested that this template should be added in the character inserter (if that's what it's supposed to be called), since {{IPA}} and {{Unicode}} are included in the IPA and Unicode menus. User:Edokter mentioned the fact that if this template is to be included, other language templates will have to be as well (perhaps {{lang|ar|}}, {{transl|ar|DIN|}}, {{transl|ar|ALA|}}, for instance, in the Arabic menu), and suggested I post the suggestion here. So here it is. — Eru·tuon09:28, 30 December 2014 (UTC)
In case you didn't know -- you can add characters/simple templates to existing menu-sets as well as add your own new set(s). See the top section on this page for more but this should help start you on your way....
To add custom entries, adapt this code, and place it in your common.js:
// Add or modify CharInsert entrieswindow.charinsertCustom={"Greek":' {\{lang|grc|+}}',"Arabic":' {\{lang|ar|+}}'};
Thanks! I don't have much knowledge of Javascript, and the code works for me (though escaping the bracket seems to be unnecessary). — Eru·tuon00:16, 1 January 2015 (UTC)
I don't why they insist on redirecting to this talk-page (EditTools is DoA, CharInsert is its replacement) so I tweaked the edit-request to point to the desired character sets.
And fwiw - when I take the IPA character proposed for addition and run a find with it in my browser on the CharInsert-core.js page, the results say its already present (next to what looks to me like an upside down letter 'w' [ʍ]). I figure better to mention it than wind up adding a duplicate or something. -- George Orwell III (talk) 03:48, 1 January 2015 (UTC)
Oh, yeah — I also searched ᶣ in MediaWiki:Gadget-charinsert-core.js, and found the non-superscript version, ɥ, which is already in the IPA menu. My Chrome find-function is incapable of distinguishing the superscript and normal versions of the character, as it is incapable of distinguishing ú and ǔ, but they are separate Unicode characters. — Eru·tuon04:48, 1 January 2015 (UTC)
I believe MediaWiki:Edittools renders when the Javascript in a browser fails to work, because I have seen this text-based list occasionally. Presumably my browser, for whatever reason, decided not to be able to use Javascript, and thus the Javascript-based list was replaced with the purely text one. (Speaking in rather non-scientific terms, since I know very little about these things.) — Eru·tuon16:19, 18 January 2015 (UTC)
It's also the fallback for when Javascript is enabled, but the bits server is acting up and fails to yield all of the Javascript and CSS that is necessary for this to work. --Redrose64 (talk) 17:37, 19 January 2015 (UTC)
I think MediaWiki:Gadget-charinsert-core.js and MediaWiki:Edittools are different in other ways as well. For instance, the Greek menu in the latter only has the standard Greek alphabet and Greek vowels with acute accents, but not all the other accented Greek characters (polytonic and ones with diaereses) that are in the former. There may be other differences in other menus. Could an editor with proper permissions compare MediaWiki:Gadget-charinsert-core.js and MediaWiki:Edittools, and where these are different, paste the list from the Javascript page to the other page? When that is done, we can update Help:CharInsert with the missing characters. — Eru·tuon19:50, 18 January 2015 (UTC)
diff Happened when we made the Charinsert gadget the default, and disabling it, hides this. Seems it has been sort of uncontroversial so far, but it is a tad weird I guess. —TheDJ (talk • contribs) 22:15, 26 January 2015 (UTC)
I was trying to go here the other day on this point. Long story short: you can stick anything you like in MediaWiki:Editools and it will become a descendent of the div element with the class of mw-editTools (which is located [semantic] document-structure wise after the edit options "field" made available during every single edit / preview session you open or re-submit) all by design.
To further detail the nuance in play here -- you don need no stinkin' .js or .css (no MediaWiki:Edittools.js, no stinkin' MediaWiki:Gadget-Edittools.js, no stinkin' java or css tweak of any kind ) in order for whatever it is that currently resides in MediaWiki:Edittools to automatically populate itself under that <div class="mw-editTools"> div container. Whether or not you actually see anything with your eyeballs [renders] in your browser is after the fact and irrelevant to the point at hand here.
No script that throws up a banner telling users to blah... blah... blah... will stop that auto populating thing from happening. No script that tries to "divert" you away by holding the core bits needed to start separate from the bulk of an actual gadget will stop that auto populating thing from happening. All we're doing is "wasting" a perfectly good, built-in div container that's made available during each and every edit / preview session with stuff nobody neither wants to cut & paste from when better crippled freeware variants exist (and Work!) nor bets they'll ever find themselves in a real life-or-death, cut & paste character emergency in there remaining lifetimes as well (remember! Edittools is still being processed on every single edit or submit for every single User: -- once again -- by design).
Stop the madness; fish or cut bait already & clean house. We can keep CharInsert as a gadget and just the way it is [if you like] but at least blank that MW message if folks are still against "freeing that div up completely". I'm sure somebody can find a more positive use for it. -- George Orwell III (talk) 17:11, 27 January 2015 (UTC)
I'd like to request additions to the Greek menu: characters with diaereses, macrons, and breves, the letter digamma, iota and upsilon with the non-syllabic diacritic (an inverted breve) under them, and the templates {{lang|grc}} and {{lang|el}}, which are used to correctly style Ancient and Modern Greek text. The diaeresis is used in both Modern and Ancient Greek, while macrons, breves, digamma, and the iota and upsilon with a diacritic are used occasionally in Ancient Greek.
The characters Ϝϝυ̯ι̯ should be added after the last block of the plain Greek alphabet (after Ωω) because they're consonants, but rare or historical ones. Characters with diaeresis, Ϊϊΐῒῗ Ϋϋΰῢῧ, should perhaps be added at the end of their respective blocks: iota with diaeresis at the end of the iota block (after Ἷἷ) and upsilon with diaeresis at the end of the upsilon block (after Ὗὗ). I would add the macroned and breved characters ᾹᾱᾸᾰῙῑῘῐῩῡῨῠ as a new block at the very end (after ᾯᾧ), and {{lang|el|+}} {{lang|grc|+}} as a new block after that.
If my instructions are too hard to understand, here's what the code for the Greek menu should look like:
Other editors may want to rearrange the order of the letters, but the whole Greek menu needs reorganization, I think. After this edit is done, MediaWiki:Edittools needs to be updated, but I can submit a separate request for that.
— Eru·tuon22:38, 14 April 2015 (UTC)
Still visible on my end (Chrome and IE8). The only possibility (though highly unlikely I think) is the nowrap I added to the links. Can anyone else confirm this might affect rtl links? -- [[User:Edokter]] {{talk}}09:57, 19 October 2014 (UTC)
fwiw...It could just be my settings in particular. When I disable 'background-color: #f9f9f9' in IE's DOM explorer (in effect restoring 'transparent' instead of a color), the characters re-appear. I can live with it but if other folks see the same you might need to re-address this.
Moved from MediaWiki talk:Gadget-charinsert-styles.css
_QWERTY_UK.svg){kind=link}