MediaWiki talk:Edittools/Archive 3

From Wikipedia, the free encyclopedia

You have new messages (last change).
Archive 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.
← Archive 2 |
Archive 3
| Archive 4 →


Contents

Revert

I apologize for putting you through this trouble, but I have reverted all recent changes because, on WP:AN, several people complained that the menu severely increases page load time for a number of symbol sets that most editors don't use in the first place. I'll admit that the menu is a nifty trick, but people with slower connections don't really appreciate it. We should stick to listing frequently used symbols (and FORCETOC and 'noinclude' are hardly frequently used, indeed most editors don't even know what they are).

Perhaps some kind of MONOBOOK functionality can be used to only give the multi-symbol menu to people that actually want it. Radiant_>|< 21:10, 19 January 2006 (UTC)

Finally! I by no means can complain that my connection is slow, but even for me the increase in page load time was noticeable. A couple more days of that, and I'd be complaining here myself. Thank you for removing this menu.—Ëzhiki (ërinacëus amurënsis) 21:13, 19 January 2006 (UTC)
(After two edit conflicts) Perhaps you could suggest this drop-down character menu at MediaZilla, and it could be implemented as an optional feature into MediaWiki?  Denelson83  21:15, 19 January 2006 (UTC)
Good riddance. It was nice to have, but took forever to load editing pages (and I have a very fast connection). It would be nice to have some way for those who still want it to be able to use it. --LV (Dark Mark) 21:17, 19 January 2006 (UTC)
Oh wait... There's already a suggestion about this at MediaZilla: http://bugzilla.wikimedia.org/show_bug.cgi?id=1785 -- Besides, I actually liked that menu-style character palette, but I guess I'm in the minority here.  Denelson83  21:18, 19 January 2006 (UTC)
I liked it as well, for what it's worth. —Locke Cole • t • c 21:59, 19 January 2006 (UTC)
I thoroughly liked it as well. --King of All the Franks 03:27, 20 January 2006 (UTC)
As did I. I used it constantly. — 0918BRIAN • 2006-01-20 03:36

<copied from AN>I don't know if an admin added this feature or the devs, so I'm posting it here. The new dropdown thing beneath the edit box is very nice, but it means gallons of javascript code that most people will never use. Is it really useful to make people on dialup drink so much (to them) redundant HTML? Surely not. <end copy> I also see above discussion about making larger still; that really isn't the way to go. The whole world does not have broadband. I think removing it as Radiant has done was a good move, if an unfortunate one. -Splashtalk 23:14, 19 January 2006 (UTC)

Once the languages are split into their own javascript files, which are only downloaded on demand, then this can be re-added. — 0918BRIAN • 2006-01-19 23:57

This is best done using XMLHTTP. Superm401 | Talk 01:01, 20 January 2006 (UTC)
Yeah, this is what I was pursuing as well, but haven't had the time to make anything worthy of showing off (and it's also why I stopped working on User:Locke Cole/edittoolstest.html). The big problem I saw with using XMLHTTP (aka AJAX) was that it lost the ability to format each character sets display as is done now (er, pre-revert anyways). Most charsets don't need any kind of special formatting (just display each character and make it clickable to insert into the textarea), but some benefitted from some formatting (the math/tex entry for example, as well as a few RTL character sets). I'm not saying it'd be impossible, and we should work towards this, but it just looks like a pain. =) —Locke Cole • t • c 01:17, 20 January 2006 (UTC)
Is there any way to split the language <p> groups to their own separate spaces (not in .js) and to have them be {{template}}d into the space, and have javascript somehow control switching what is templated, and get it to refresh that little block after the template is switched? So the block would contain {{MediaWiki:SomeCharacterSet}}, and the javascript would switch that to {{MediaWiki:SomeOtherSet}}, and then refresh the block so that the new content is templated in. — 0918BRIAN • 2006-01-20 01:31
Not that I'm aware of, no. If you grab the raw entry (using &action=raw) MediaWiki doesn't parse the <charinsert> tags. If you grab it without using the raw action, you get everything; donation links, etc. You could possibly parse the fetched XHTML and isolate it to the actual article XHTML, but in my limited testing this proved painful (Wikipedia may be well-formed XHTML, but the XML DOM chokes on it (at least it did in my limited testing)). Again though, I'm no expert. You may want to inquire on WP:VPT.
The solution I think may be worthy of exploration is creating a seperate .xml file for each charset (e.g. - MediaWiki:Charsets/Roman-Latin.xml), and having the code here at MediaWiki:Edittools (or in MediaWiki:Monobook.js) grab each .xml file on an as-needed basis (using &action=raw), then emit the appropriate HTML/javascript at runtime (calls to insertTags, etc). It's possible we could format the xml such that it would hold formatting info (is this a right-to-left character set? ; do we need to break groups of characters into sections? ; etc.), but it would likely be a lot of work/testing (not a bad thing, just saying). This is what I was interested in exploring (and if I have more time, will try to explore). —Locke Cole • t • c 02:01, 20 January 2006 (UTC)
  • Would not a bit of javascripting in your personal config files take care of this? Radiant_>|< 02:03, 20 January 2006 (UTC)
    • I think the goal here is to increase the usability for everyone, not just people who are aware of their userspace javascript files. —Locke Cole • t • c 02:05, 20 January 2006 (UTC)
      • I was thinking of it as useful extra functionality, along the lines of the Popup Tool. Radiant_>|< 02:13, 20 January 2006 (UTC)
        • It can be useful for everyone while still being smaller than half the junk in MediaWiki:Monobook.js that nobody uses. — 0918BRIAN • 2006-01-20 02:14
          • I think it's throwing the baby out with the bathwater. Wikipedia is and always has been slow to load regardless of what edit tools we have available. I too have noticed that edit pages are slow to load over the last several days, but you know what? They're just as slow now with the old insert box as they were yesterday! Why don't we solve the real problem instead of eliminating a useful tool? --Angr (tɔk) 06:03, 20 January 2006 (UTC)

Thank you for restoring the table of diacriticized letters! Now I can work normally again on every computer. logologist|Talk 06:29, 20 January 2006 (UTC)

What do you mean, "on every computer"? The only reason it wouldn't work is if Javascript wasn't enabled, and then the whole table blows up anyways without Javascript. As the plan is to reintroduce code similar to what was being used before, it would help greatly to know where it broke or what issues people had with it. —Locke Cole • t • c 06:35, 20 January 2006 (UTC)
I never had difficulty using the table that disappeared about a week ago, and that has now returned. When it was replaced by the drop-down, it was available on one computer I used and not on another. Where it was available, it was unstable, and I had to relocate my alphabet with each individual letter that I wanted to insert. logologist|Talk 06:48, 20 January 2006 (UTC)
Please list your operating system, browser, etc. — 0918BRIAN • 2006-01-20 06:52
I have Javascript enabled. When I installed the monobook page as I was required to do, I got the menu (and the extra blank menu). However, it didn't work. It would display the options but clicking on the menu item, like say, "Cyrillic", wouldn't do anything at all. Nothing, nada. Even if it had worked, it is a burden to new users, and a bother to experienced users. Good riddance. Hu 07:11, 20 January 2006 (UTC)
You were never required to install anything in your userspace monobook.js, it simply worked (or, in your case I guess, didn't work). As with Brian0918 above, could you provide some information on the operating system and browser you were using (the more details, the better)? Thanks! —Locke Cole • t • c 07:14, 20 January 2006 (UTC)
I most certainly was required. The menu was blank. There were a few characters in the box, but not the diacriticals and accented characters and there was a bunch of less useful stuff like TOCleft. There was a little link that said something about help with the menu, so I followed it (to Edittools, I think) and I followed the instructions there, whichever page it was I can't remember, that said to copy the code into my monobook.js page, which I did and you can see it still there. After doing that, a second menu appeared in front of the blank one, and it had the selection of languages to choose from. But when I clicked on any selection, nothing happened. I have Javascript turned on, and I'm running Netscape 7.2 on Windows XP. Hu 07:36, 20 January 2006 (UTC)
Thanks for the info, regarding the requirement, I'll correct myself: you were required if you were using a skin other than Monobook. Are you using Monobook? Or were you using another skin (such as Classic or CologneBlue)? If you were using Monobook, then it simply should have worked. The advice to copy things into your userspace <skin>.js were, IMO a bad idea (since any additions would automatically make them go out of sync; the code was very "brittle").. to be fair though, the intentions were sincere. —Locke Cole • t • c 07:56, 20 January 2006 (UTC)
It clearly said in bold to copy it into your userspace only if you were not using monobook. It should have worked fine if you were using monobook. Everyone on the site saw the link for help with the menu, and only a couple users have followed that link here to complain that their menus didn't work, so please do not act as though it was a broken feature. People do not complain about what works fine for them (well, unless they just don't like it; again, only a handful have complained to that effect). — 0918BRIAN • 2006-01-20 08:05
Actually, not everyone experiencing problems would complain or even know where to complain, or even that they should complain, when things are that unstable, since most people would assume good faith as I did and hope that it would be resolved sooner or later, as it was later by reversion. Not all users are eager to engage in debate and talkbalk and having to defend themselves, no matter how skilled, trained, educated, or experienced they may be. I only lucked into complaining (and applauding the revert) because I stumbled across some complaints (and praise of the restoration) when looking at the Admin Noticeboard, as an experienced Wikipedian dealing with a recalcitrant user. Not everyone, not even the majority of editors, is a hyperactive plugged-in Wikipedian like yourself, Brian0918. Absence of evidence is not evidence of absence.
You are completely disrespectful and arrogant to use phrasing like "do not act like it was a broken feature". It was broken. The menu did not work at all, before I did anything (and Javascript has always been enabled): it was empty from the moment it began appearing. So there definitely was a problem not of my making, i.e. it broke without my touching it. Any system of menus and such that requires people to follow a chain to copy and paste and install, or follow the chain and get to a point to where they have to decide whether or not to copy / paste / install, is a mistake when you have a huge user base like Wikipedia. My monobook.js page did not exist when I read the instructions. I took that to mean that I wasn't using monobook.js and since the menu thingy was not working (was blank), I followed the instructions to install. Since my monobook.js page did not exist I created it and installed it like I was told. After I installed, it worked a bit better, at least to the point of showing the language choices, but when I clicked on any item nothing happened. No characters, no change in the character insertion box, no error messages, no further explanation on the help page or the install page, nothing. You can look down on me all you want, Brian0918, but that won't make me unskilled, untrained, uneducated or inexperienced.
I do not doubt the intentions were sincere, but the fact that the system was being changed several times over the course of a week points to a fundamental flaw in the process: Something that is so prominent and so useful must not be jerked around like that. For-profit companies, who know that user interfaces are extremely important, don't do things like that. They test and test and then roll out one version change (major or minor). If it works, they don't roll out another version for months. On the other hand if the change fails in some way, they revert ASAP and they do not push out another version two hours later, hoping it works. Stability does not become a useless concept just because some well-intentioned but skillful Wikipedians with their hands on the levers are used to installing and un-installing things. Stability counts. Hu 15:25, 20 January 2006 (UTC)
Amen. logologist|Talk 15:46, 20 January 2006 (UTC)
I beg to differ with the assertion that the "insert box" as it was before Brian's changes or as it is now since Radiant!'s revert is any way, shape or form "useful". It's poorly organized and has barely a fraction of the characters I actually need. I spend so much time hunting down the character I'm looking for, only to find half the time the one I want isn't there anyway, it's more efficient for me to just type in the decimal code, hit preview, and then copy the character out of the page and paste it back into the edit box. --Angr (tɔk) 15:51, 20 January 2006 (UTC)
A bit overdramatic, but that's alright. It appears this menu doesn't work in Netscape, as I recall another user of Netscape who couldn't get it to work. Logologist: are you also using Netscape? If so, it should be possible to have the current version display for users of Netscape (I think), and the more comprehensive version (once it is finished) display for everyone else. — 0918BRIAN • 2006-01-20 16:37
Ridiculous. It worked in the vast majority of browsers (Internet Explorer and Firefox being that majority). And this is the first I've heard of there being issues in Netscape (which is really weird, since my understanding of Netscape was that it used the same Gecko engine Firefox uses). Even more weird is your claim that it started working when you placed code in your userspace monobook.js (even though the code you placed there is identical to the code that was in use at MediaWiki:Monobook.js). So forgive me for being just a little skeptical of your assertions. And as Brian0918 says, there was a direct link for people who couldn't get the menu working, and it was in place for a few days at least; surely if it was as broken as you claim the number of complaints would be much more than what we'd seen?
I'll certainly look into your problem more if/when I get a chance to redesign this to be smaller (bandwidth-wise), but a number of your claims simply do not add up. —Locke Cole • t • c 01:28, 21 January 2006 (UTC)
Of course it doesn't add up, that's why it's a bug! If it all added up, then all the aspects would be completely understood, it would have been fixed already, and the stability wouldn't have been so slipshod. I assumed good faith so I didn't complain, initially. You are not assuming good faith, but instead jump to accusing me of fabrication. I gave an honest and straightforward account of my experience. I have "no dog in this fight", as the saying goes, meaning that the menu thing sounds like a fine idea to me, but if it doesn't work or is unstable or is introduced onto the server in an amateurish way, then that is a problem. I doubt that you can project or simulate or know all the failure modes of bugs in the code or their interactions with different browsers and operating systems. That is why a properly designed testing matrix is one of the basics, as is bug reporting. You need bug reports. Absence of evidence is not evidence of absence. Dismissing an honest bug report just sweeps the bugs under the carpet from whence they may return later. Or we may both get lucky and never see them again. But dismissing bug reports now, saying "Ridiculous", is not the way to get more in the future. No wonder people are reluctant to complain!
Think what you want, but read carefully what I wrote. Stability is a separate issue from bugs. Code should be introduced in a professional way, which means only when thoroughly tested. Instead we were subjected to a series of many dozens of edits strung out over five days, though often in groups of four within the space of fifteen minutes, and without the use of the Edit Summary field, which seems to be fit only for mere mortals and not the likes of Brian0918. He and others are undoubtedly well intentioned, but need to take this a little more seriously and test it thoroughly before replacing the production version of code that users see. When you have a situation where Brian0918 writes as one of his rare edit summaries that he is fearfully directing users to this talk page where they might actually report bugs, then you know something is seriously wrong. Joking he might be, but it is a nervous joke if it needs to be made at all, especially if it is mid-process and not making the link available at the beginning. If the developers are not confident enough in the quality of their work and humble enough to eagerly accept bug reports, then the process is broken. This is all volunteer work I know, but still there are some basic things that really need to be handled in a more professional manner than has been up till now. The basics of testing and rolling out "product" are not really that hard. Hu 08:57, 21 January 2006 (UTC)
This line of "discussion" is counterproductive, so I would suggest that nobody continue down this path of personal arguments, and instead focus on actually fixing the thing. — 0918BRIAN • 2006-01-21 16:44
Fine. You can fail to address the issues now, calling them "personal arguments" if you like. But if you don't fix the process you'll run into the same issues again and again. Hu 17:08, 21 January 2006 (UTC)
I suggest Brian0918 not be involved in this project at all, since there are clearly bugs and he has admitted he knows absolutely nothing about javascript. Leave the fixing to people who know what they are doing and can test on multiple browsers, not to someone who just knows how to copy and paste from the French wiki. pfahlstrom 17:53, 23 January 2006 (UTC)

Wait a minute -- Why don't we just write a similar "character palette" script in PHP, so we could simply dispense with the use of JavaScript?  Denelson83  00:40, 21 January 2006 (UTC)

  • How would that work? — 0918BRIAN • 2006-01-21 00:59
    • I'd be interested in this as well, but I don't really see how PHP would help anymore than client-side AJAX/XMLHTTP (and in fact, it would likely place stress on the servers instead of on the clients). But I'm interested in hearing alternate ideas on how to tackle this. =) —Locke Cole • t • c 01:28, 21 January 2006 (UTC)

Vietnamese IME

In the very rare event that any misses the Vietnamese section of the character pallete, the Vietnamese Wikipedia community has developed a JavaScript-based IME that you can install under your userspace here (documentation in Vietnamese):

  1. Copy the contents of m:User:Mxn/him.js to a new "him.js" file in your userspace.
  2. Copy the contents of m:User:Mxn/monobook.js to your user JavaScript file, replacing any occurrence of meta.wikimedia.org with en.wikipedia.org and any occurrence of User:Mxn with User:Your_user_name.
  3. Under the /* Vietnamese Input Method - Wikipedia tiếng Việt */ section, you can optionally change the values of the variables to your preferences, as documented at vi:Wikipedia:Gõ tiếng Việt.
  4. Copy the contents of m:User:Mxn/monobook.css to your user stylesheet.

You should be good to go. The original him.js script was developed by Đặng Trần Hiếu, and none of the files I've mentioned above reference any external files – it's all located within your userspace – so there should be no security issues involved. The IME does store some cookies that allow it to remember your preferences across each page, but they don't contain any personally identifiable information.

If anyone's interested, we can translate the Vietnamese documentation into English.

 – Minh Nguyễn (talk, contribs) 02:45, 20 January 2006 (UTC)

Could this be extended for any language, in addition to Vietnamese?  Denelson83  00:47, 21 January 2006 (UTC)

XMLHTTP

It shouldn't be that hard to keep the formatting using XMLHTTP. You put the actual code for each paragraph in a separate XML file, which is then called upon selection of an option. I'm working on some code for it... Superm401 - Talk 04:59, 21 January 2006 (UTC)

Cool. =) How are you retrieving the XML file? action=raw? Or something else? —Locke Cole • t • c 05:21, 21 January 2006 (UTC)

Custom versions of edittools?

Is it possible to utilize the userspace Javascript files to create a custom version of the insertion tools? I'd like to make it so that I don't see some of the foreign-language characters that I never use, and also add some macros for commonly used functions like *{{subst:test1}} ~~~~. Crotalus horridus (TALK • CONTRIBS) 17:46, 24 January 2006 (UTC)

My suggestion is to use the code #editpage-specialchars { display: none; } to hide the main one then copy the code from the main one over to your own css file and butcher it mercilessly as you see fit (making sure to remove or change the div id) and that should in theory at least give you your own custom special-chars box. JtkieferT | C | @ ---- 01:45, 26 January 2006 (UTC)
You'll need to generate it in a .js file, not css, but Jtkiefer's basically right. Superm401 - Talk 01:10, 28 January 2006 (UTC)
hmm, I got it to hide in css, but it makes sense that you'd need to do the new one in js. JtkieferT | C | @ ---- 02:45, 28 January 2006 (UTC)
Right. That's what I meant. If you're just getting rid of it, you shouldn't need anything but CSS. Superm401 - Talk 03:17, 28 January 2006 (UTC)
It doesn't seem to work for me whether I put it in the CSS or JS file. Is actual JS coding needed? Crotalus horridus (TALK • CONTRIBS) 14:21, 4 February 2006 (UTC)
Probably. Exactly what were you trying to do, just get rid of it? Superm401 - Talk 01:59, 5 February 2006 (UTC)

Trademark symbols

Hi! Could someone add the two trademark symbols: ® and ™ in the message? Thanks very much. --Eleassar my talk 15:34, 31 January 2006 (UTC)

Bug?

At present, in the part of this box following [] [[]] I see:

<span style="font-size: larger; border: 1px dashed #344455;">{{{1}}}</span>

with each space resulting in a new link. This is very weird; has something gone belly-up elsewhere? -Splashtalk 13:58, 17 February 2006 (UTC)

Replacing charinsert with dynamic JavaScript

Currently, the special characters part of MediaWiki:Edittools has 18 kilobytes after being parsed. This is more than half of the size of an edit page's interface (without considering the size of the wikitext to be edited).

Since the current implementation of charinsert depends on JavaScript, the whole special characters box could be replaced by an empty box filled dynamically via a script. I've created a proof of concept code, which has been pasted below. It's designed to be added to the site's global javascript, but also works when added to the user javascript (which is how it was developed).

Advantages of my proof of concept code over the current static version:

  • The 18 kilobytes of the special characters box do not have to be sent every time an edit page is sent.
  • It's very easy for users to change the contents of the special characters box, by simply copying one array to the user javascript (editpage_specialchars) and editing it.
  • It's very easy for users to add new characters to the special characters box, by simply adding one array to the user javascript (editpage_specialchars_extra). The proof of concept code has a sample use of this feature.

Disadvantages of my proof of concept code over the current static version:

  • There's a very small flicker while the characters are being added to the special characters box.
  • It shows as a strange empty box if you have JavaScript disabled on your browser.
  • It's untested in anything but Mozilla Firefox 1.5.0.1 on Linux

If the current special characters box were to be replaced with a script, it's possible to avoid the flicker by using slightly more complex code (the characters itself would be sent, without the links that are the largest part of the bloat, and dynamically converted into links).

--cesarb 18:16, 17 February 2006 (UTC)

Proof of concept code

var editpage_specialchars = [
  ['[', ']', ''],
  ['[[', ']]', '']
];
var editpage_specialchars_extra = [];

function editpage_specialchars_escape(str)
{
  return str.replace(/\\/g, "\\\\").replace(/'/g, "\\'");
}

function editpage_specialchars_insert(box, char)
{
  box.appendChild(document.createTextNode(" "));

  var a = document.createElement("a");
  a.href = "javascript:insertTags('"
    + editpage_specialchars_escape(char[0]) + "','"
    + editpage_specialchars_escape(char[1]) + "','"
    + editpage_specialchars_escape(char[2]) + "')";
  a.appendChild(document.createTextNode(char[0] + char[1]));
  box.appendChild(a);
}

function editpage_specialchars_onload()
{
  var box = document.getElementById("editpage-specialchars");
  if (box === null)
    return;

  // Empty the edittools box
  while (box.firstChild !== null)
    box.removeChild(box.firstChild);

  // Recreate edittools box contents
  box.appendChild(document.createElement("small"));
  box = box.firstChild;
  box.appendChild(document.createTextNode("Insert:"));

  // Insert the new contents
  for (var c = 0; c < editpage_specialchars.length; c++)
    editpage_specialchars_insert(box, editpage_specialchars[c]);
  for (var c = 0; c < editpage_specialchars_extra.length; c++)
    editpage_specialchars_insert(box, editpage_specialchars_extra[c]);
}

addOnloadHook(editpage_specialchars_onload);

// Sample use on user javascript
editpage_specialchars_extra = [
  ['ç', '', '']
];

Comments

Sounds like a good idea; is there a demo I can try without adding this to my monobook.js? Which browsers does it work with?

I have added CSS to my monobook.css to completely hide the current charinsert. It's just a waste of screen space, since it doesn't work in my browser (Safari), and the Mac OS comes with a much better character palette built in. I would be in favour of anything to improve or eliminate the current charinsert, or make it optional. —Michael Z. 2006-02-17 20:22 Z

Yes, sort of: you can add this to your monobook.js, but don't save it. Instead, press preview; there's code on MediaWiki which previews user javascript pages by inlining them (in fact, it's how I developed the code; notice I never saved my monobook.js where this was developed). However, your CSS hiding code will probably hide the output of this code also, so you'd have to disable it to be able to see my code working. --cesarb 20:26, 17 February 2006 (UTC)
I don't totally understand this. Because the characters are stored in a simple javascript array, wouldn't the page still have to include all of them for the dynamic loading to work for all characters (I understand that they can be in user monobook, but most people don't use these)? I tried to come up with a similar solution, but got bogged down trying to use XMLHTTP to load the characters from separate files. Superm401 - Talk 00:00, 18 February 2006 (UTC)
The site JavaScript is not included inline on the page. It's on a separate file, which can be cached. --cesarb 00:49, 18 February 2006 (UTC)
With XMLHTTP, you can create a plaintext list of characters at, say, MediaWiki:Charinsert IPA, call "http://en.wikipedia.org../../../raw/MediaWiki%7ECharinsert_IPA_fe51", and parse from there. That way you wouldn't have to parse an entire Wikipedia page for the characters you're after. – Minh Nguyễn (talk, contribs) 04:27, 19 February 2006 (UTC)
Yes, but there's no need for that, when you can simply add the list of characters to the very same JavaScript file where the functions are. That file is already separate from the page, and thus can be cached, so the cost would happen only once. It also works in more browsers. --cesarb 13:58, 19 February 2006 (UTC)
I totally agree with Cesarb. It is not necessary for that. --Siva1979Talk to me 15:56, 19 February 2006 (UTC)

Will this actually work for all skins? Monobook is the only one that seems to have a wiki-editable javascript page. —Cryptic (talk) 16:47, 21 February 2006 (UTC)

Looking at the code, I can see about half of the skins have a wiki-editable javascript page (all the ones that are based on Monobook; see Wikipedia:Catalogue of CSS classes for the list). The other ones (based on Classic) don't. However, we can always ask the developers to add code to get wiki-editable javascript pages to the other skins, or (even better for this particular case) ask them to add code to get a wiki-editable common javascript. But I would prefer to first see support for this bandwidth-saving scheme before bothering the developers with a request to implement something that might not be used. --cesarb 18:22, 21 February 2006 (UTC)
That's not true. They all have editable javascript. Classic, for example, uses standard.js. See WP:POP#Installation. Superm401 - Talk 15:16, 20 March 2006 (UTC)
No. While it's true that all have editable user javascript, only half of them have editable global javascript (I made a list of all the JavaScript pages used by all the skins, check it at Wikipedia:Catalogue of CSS classes). Changing the edittools to be generated by javascript requires the use of global javascript (you cannot depend on all users to add code to their user javascript pages; if there is a decision to use my proposed changes, it's easier to simply ask one of the developers to change all skins to call a global MediaWiki:Common.js, like is done with the CSS). --cesarb 16:27, 20 March 2006 (UTC)

How to insert combining diacritics

At the Yoruba Wikipedia I'm trying to adapt yo:MediaWiki:Edittools to make it easier to add diacritics used in the Yoruba orthography. However, I found out that MediaWiki doesn't show combining diacritics like COMBINING DOT BELOW (Unicode #0323, as in ọn, ẹn) if put between <charinsert>'s. The only way I can get it to work currently seems to be by adding a leading space so that the text isn't reformatted by MediaWiki. That might be a clue to the solution, too, but I don't know where to look or how to solve this. Can anyone help me? — mark ✎ 08:55, 31 March 2006 (UTC)

I doubt this is mediawikis fault. i've discovered that browsers often don't display combining diacritics if there is nothing for them to combine with. i suspect the charinsert extention will need to be changed to allow specification of a base character for showing combining diacritics on. Plugwash 13:58, 31 March 2006 (UTC)
That's a good point. However, why does it work then when the leading space is added? — mark ✎ 14:15, 31 March 2006 (UTC)
Perhaps because then it's combining with the space. --cesarb 12:55, 6 April 2006 (UTC)
Ah, probably. I'll try using the unicode-code for space together with the dot, see if that works. Thanks! — mark ✎ 17:53, 6 April 2006 (UTC)
It doesn't :( — mark ✎ 09:03, 19 April 2006 (UTC)

Recent archive

Although I agree that this talk page needed archiving, one of the archived sections contained additions a week old and also a {{Editprotected}}. I hope the {{Editprotected}} doesn't get lost in the archive. --teb728 03:25, 13 June 2006 (UTC)

Sorry, replacing below. -Quiddity 04:22, 13 June 2006 (UTC)

{{unicode}}

Would it greatly disconcert anybody if I SUBSTituted {{unicode}} into the appropriate parts of this? My browser seems to be using a different font to display that area of the page, so I can't see characters here which display perfectly well further up. I've had a quick look using the preview feature, and nothing appeared broken, but that obviously is not exactly the same :-). I'm proposing SUBSTing the template so as not to impose further strain on the server. HTH HAND —Phil | Talk 16:00, 16 January 2006 (UTC)

  • I'm not sure that would work. — 0918BRIAN • 2006-01-16 16:03
    • What would stop it working? {{unicode}} is coded as <span class="Unicode">{{{1}}}</span><noinclude>{{protected template}}

[[Category:MSIE font fix templates |Unicode]] [[de:Vorlage:Unicode]] [[hr:Predložak:Unicode]] [[it:Template:Unicode]] [[mk:Шаблон:Уникод]] [[nl:Sjabloon:Unicode]] [[pl:Szablon:Unicode]] [[ru:Шаблон:Unicode]] [[vi:Tiêu bản:Unicode]] [[zh:Template:Unicode]] </noinclude>, so SUBSTing it simply places <span class="Unicode">…</span> around the parameter. So long as we put it around the <charinsert> tags rather than inside them, surely this would work? Sorry, I'm not able to test this out: I'd try it out over on test if I were an admin over there, but I'm not, so I can't…except that this facility hasn't been ported over there either. HTH HAND —Phil | Talk 09:38, 17 January 2006 (UTC)

      • I don't think it would work because the charinsert tags get converted into javascript that inserts characters into the editor. By being outside of the charinsert tags none of the unicode templates code would get placed in the editor. —Locke Cole • t • c 09:43, 17 January 2006 (UTC)
        • AAAAHHH!!! Misunderstanding!!! I'm not after having {{unicode}} automatically included: I want to have the items for selection in a Unicode-class span so that I can read them. When I'm in edit mode, if I select "Greek" from the drop-down, I get two lines of legible greek characters, a line of little boxes, {{polytonic}}, then 8 lines of more little boxes. I want to know whether I can have these displayed properly if I put {{unicode}} into MediaWiki:Edittools. I'm wanting to know whether <span class="Unicode">…</span> will still work even in that special area below the "Save"/"Show…" buttons. Sorry, am I making myself clear now? —Phil | Talk 11:25, 17 January 2006 (UTC)

I think what is needed is to enclose the <charinsert>s above Ə in {{latinx}} and those after ω in {{IPA}}. Like this:

Insert:{{latinx|
<charinsert> Á á Ć ć É é Í í Ĺ ĺ Ń ń Ó ó Ŕ ŕ Ś ś Ú ú Ý ý Ź ź </charinsert> &nbsp;
...
<charinsert> Æ æ Ø ø Å å </charinsert> &nbsp;}}
...
{{IPA|
<charinsert> ʈ ɖ ɟ ɡ ɢ ʡ ʔ </charinsert> &nbsp;
...
<charinsert> ˈ ˌ ː ˑ </charinsert> &nbsp;}}

I have tried this in the sandbox, and it displays correctly on MSIE. ({{latinx}} is better than {{Unicode}} for some Latin characters.)

{Editprotected}

Can someone please do it? --teb728 02:09, 22 May 2006 (UTC)

Oh, Phil, you said that you couldn't test this: The way that I tested it was to copy the source, paste it in a sandbox, and click "Show preview." (Since you are an admin, you can skip the part about copying to a sandbox.) That way you can see that it displays correctly. And by hovering over a character, you can see that it still expands to the normal javascript:insertTags. Perhaps your idea of using <span>...</span> is better than my use of templates, but do use the classes "latinx" and "IPA" instead of "Unicode": They give better fonts in the Latin and IPA ranges. --teb728 07:43, 22 May 2006 (UTC)
There's another request for IPA characters to be displayed correctly in the Edittools (and a temporary per-user solution until it is fixed) over at Wikipedia:Village pump (proposals)#Insert box below edit panel should force IPA supporting font. The Arial Unicode MS font-family setting allows both accented and IPA characters to display fine in Internet Explorer, except for the two (combined?) forms Ȳ and ȳ. So is it possible for a developer to maybe add the relevant CSS into the IE6-specific include at "/skins-1.5/monobook/IE60Fixes.css" ? --Cedderstk 17:39, 5 June 2006 (UTC)
It can't be just a change in the css file. (Nor is the problem only in IE6; I understand it is also in older versions of IE.) The problem is that IE users need different fonts for Latin Extended-B and IPA, because of the Wikipedia preferred fonts none covers both well. So I believe a change is needed here in Edittools to mark different character ranges with different classes. That being done the css file can specify appropriate fonts for the class. --teb728 01:34, 6 June 2006 (UTC) If they add polytonic characters they will need to specify a class for that too. --teb728 01:41, 6 June 2006 (UTC)

On 06:10, 13 June 2006 User:Splash removed {{Editprotected}} with the comment "rm editprotected; should not be done until actually confirmed to be stable"

What kind of confirmation would satisfy you? The proposed changes affect only the fonts used in parts of the Edittools box. In particular it does not affect the ability to revert the change in the extremely unlikely chance it didn't work right. --teb728 20:06, 16 June 2006 (UTC)

After today's changes—it's OK to archive this again (and the note above). Thanks, teb728 20:50, 22 June 2006 (UTC)

Fractions

Where did all the fractions go? If the fractions are problematic, can we at least put ½ back in? I imagine it's the most commonly used fraction. --P3d0 18:40, 7 May 2006 (UTC)

Retrieved from "http://en.wikipedia.org../../../e/d/i/MediaWiki_talk%7EEdittools_Archive_3_6bd1.html"