MediaWiki talk:Edittools/Archive 3

message: 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):
#Copy the contents of m:User:Mxn/him.js to a new "him.js" file in your userspace.
#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.
#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.
#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)
replies: text: Could this be extended for any language, in addition to Vietnamese?  Denelson83  00:47, 21 January 2006 (UTC)
thread_title:  Vietnamese IME 

message: 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)
replies: text: Cool. =) How are you retrieving the XML file? action=raw? Or something else? —Locke Cole • t • c 05:21, 21 January 2006 (UTC)
thread_title:  XMLHTTP 

message: 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 * ~~~~. Crotalus horridus  17:46, 24 January 2006 (UTC)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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  14:21, 4 February 2006 (UTC)
replies: text: Probably.  Exactly what were you trying to do, just get rid of it? Superm401 - Talk 01:59, 5 February 2006 (UTC)
thread_title: Custom versions of edittools?

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

message: At present, in the part of this box following []  I see:
:
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)
thread_title:  Bug? 

message: 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)
replies: text: 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)

text: 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)
replies: text: 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)

text: With XMLHTTP, you can create a plaintext list of characters at, say, MediaWiki:Charinsert IPA, call "", 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)
replies: text: 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)

text: I totally agree with Cesarb. It is not necessary for that. --Siva1979Talk to me 15:56, 19 February 2006 (UTC)

text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Replacing charinsert with dynamic JavaScript 

message: 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)
replies: text: 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)
replies: text: 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)

text: With XMLHTTP, you can create a plaintext list of characters at, say, MediaWiki:Charinsert IPA, call "", 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)
replies: text: 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)

text: I totally agree with Cesarb. It is not necessary for that. --Siva1979Talk to me 15:56, 19 February 2006 (UTC)

text: 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)
replies: text: 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)
replies: text: 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)
thread_title: Comments

message: 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)
replies: text: 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)
replies: text: That's a good point. However, why does it work then when the leading space is added? — mark ✎ 14:15, 31 March 2006 (UTC)
replies: text: Perhaps because then it's combining with the space. --cesarb 12:55, 6 April 2006 (UTC)

text: 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)

text: It doesn't :(   — mark ✎ 09:03, 19 April 2006 (UTC)
thread_title:  How to insert combining diacritics 

message: Although I agree that this talk page needed archiving, one of the archived sections contained additions a week old and also a . I hope the  doesn't get lost in the archive. --teb728 03:25, 13 June 2006 (UTC)
replies: text: Sorry, replacing below. -Quiddity 04:22, 13 June 2006 (UTC)
thread_title:  Recent archive 

message: Would it greatly disconcert anybody if I SUBSTituted  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)
replies: text: 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 ... 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)

text: 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)
replies: text: 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)

text: 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)
thread_title:  &#x7B;&#x7B;unicode&#x7D;&#x7D; 

message: 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.  --Doradus 18:40, 7 May 2006 (UTC)
thread_title:  Fractions 

message: Its a pain looking up templates when editing. Could a link to common templates (in separate window), or the main template finder, be added to Edittools? FT2 (Talk) 23:38, 18 May 2006 (UTC)
thread_title:  Link to "common templates"?