Wiktionary:Grease pit/2007/December

Threshold for template protection
I can agree that it is a good idea that the most commonly transcluded templates are permanently protected. This is the case with such inflection templates as, , , and , but ? I think this threshold level of protecting comes at a cross with the wiki spirit. Being able to edit protected pages should not be a incentive for aplllying for adminship. __meco 14:29, 3 December 2007 (UTC)


 * It is based on the number of entries that can be vandalized at once, not on the "importance" or some such measure. fi-form of is used in a lot of entries. Robert Ullmann 14:40, 3 December 2007 (UTC)


 * Granted, but it makes the threshold for collaborative improvements a lot higher also. Would your judgment based on the risk of vandalism versus the imminent response such vandalism of a high-volume template would receive and the experience with/likelihood that foreign language template vandalism occurs and said hindrance to non-administrators editors making edits, support the continued practice of pre-emptive protection based on the criterion mentioned. Personally, whenever I stumble across such hindrances I find that it takes away some of my encentive and enthusiasm towards doing editing work. And I am particularly troubled by the thought that some people might find ease of doing editing work an incentive for applying for adminship, __meco 15:01, 3 December 2007 (UTC)


 * A change to one of these templates creates a huge server update backlog in addition to the vandalism. We already discussed the problem before we implemented the protection. If you would like to reverse the community consensus, I'd say put it to a vote.   --EncycloPetey 15:05, 3 December 2007 (UTC)


 * We needn't be too concerned about the jobqueue, it is O(1) in the long term, and so by the end of the day it makes very little difference. The vandalism is also pretty much a non-issue, as our level of template vandalism is virtually non-existant. I have to say that I was going to post something like this about two weeks ago, it isn't that I want to edit the templates - I just don't like to be told I can't. Conrad.Irwin 23:25, 3 December 2007 (UTC)


 * The reason it's virtually non-existant is that the templates are protected. We had a run of several people taking it upon themselves to deface the templates or "improve" them against community consensus and despite warnings.  That is one of the reasons they are now protected. --EncycloPetey 01:04, 4 December 2007 (UTC)


 * Now you are commingling two issues that really ought to be seen in complete separateness, in my opinion. And this is another reason to maintain a high level of alertness about having a rock solid rationale for such austerities as this. The vandalism argument is completely valid, when applicable. The temptation to apply this form of restriction as a means to control "rogue" editors is another cause altogether. This has deep-seated bearings on the democratic spirit – the wiki spirit – and opens up insidious paths which tend to creep their way toward elitism and aristocracy. Such problems should never be solved with pre-emptive, blanket or purely technical solutions, but must always be addressed through the oftentimes tedious process of consensus-building and subsequent enforcement of the established consensus with means directed specifically towards this. __meco 10:25, 4 December 2007 (UTC)


 * If it were individual pages, I might agree with you. However, the discussion in the aftermath raised the issue of server time updating both the effect of the initial "rogue" edit by a new user and the subsequent doubling of that time the server spends following the reversion.  The "rogue" edit was made following discussion and against community consensus.  The decision made was community consensus.  So, you are arguing for community consensus in an attempt to overturn the very community consensus you purport to be arguing for.  --EncycloPetey 14:55, 4 December 2007 (UTC)

The template's odd new behavior
I've noticed that everywhere the template appears at the top of pages, it now ends with a (diff) link in blue that compares the last edit made to that page. WHY? I don't see any change to the template itself, so it must be a software change that's causing this. It is very confusing and serves no purpose. Ssee definition, where it was especially confusing, but also it appears on ser, ma, canton and every other page that uses the template. --EncycloPetey 15:02, 3 December 2007 (UTC)


 * You enabled WT:PREFS without checking the box to suppress this. Yes, it is badly designed, default is backwards. Robert Ullmann 15:07, 3 December 2007 (UTC)


 * But this has never appeared before, and I haven't changed my PREFS in a very long time. This is a change in what I'm seeing. Why? --EncycloPetey 15:16, 3 December 2007 (UTC) And why would anyone set this up as an option at all?  It displays a difference in the last edit for a page, but only if that page has similarly spelled other pages link from the "see" template?  It makes no sense whatsoever!


 * This is why I don't use WT:PREFS. There are three of them that are automatically selected when you set them up. The cookies that store the WT:PREFS expire after 30 days, so it may be that your cookies have just expired. I agree, it would make a lot more sense to turn these three options off. It might irritate people a little for 30 days, but I think it would be worth it. Conrad.Irwin 23:20, 3 December 2007 (UTC)


 * The (DIFF) links were broken by a mediawiki software change a while back. The diff links used to work - now the software needs to find both REVIDs for it to work right - which requires a bit more overhead (and an http hit for each link) so it should be completely disabled, rather than "fixed."  Sorry for the confusion.  If I don't get around to disabling it soon, someone remind me (or just do it.)  --Connel MacKenzie 17:16, 4 December 2007 (UTC)


 * Which are the other two? Robert Ullmann 16:24, 5 December 2007 (UTC)
 * I think Connel turned them off. There are two lines of CSS added in }else{ blocks which shouldn't be necessary I don't think they are doing any harm either. Conrad.Irwin 08:23, 11 December 2007 (UTC)

For the adventurous wiktionarydev look
Following from a lengthy discussion on IRC, I have started to implement a Javascript parser for wiktionary. At the moment it has got to the stage where it divides up the languages (like on http://wiktionarydev.leuksman.com/ ) and although only 0.1% of the total way there, I liked the results so much that I decided to share this in its current form with anyone interested. If you add document.write(' '); to your monobook.js and refresh your browser, you will see what I mean. I would welcome any bug reports/feedback either here or on my talk page. (known to work (well enough) in Ff2,Op9,Kq3,IE6,IE5 would love confirmation about IE7) Conrad.Irwin 02:27, 4 December 2007 (UTC)


 * It's taking out the definitions of some words for me, such as astonish (it removed

Verb
Nadando 03:00, 4 December 2007 (UTC)
 * 1) surprise, flabbergast
 * Thanks for your input! I have fixed this bug. Conrad.Irwin 10:18, 4 December 2007 (UTC)


 * It works in IE7. And, I'm sure you know this already, but it is incompatible with language-specific links, e.g. test.  Rod (A. Smith) 17:45, 4 December 2007 (UTC)
 * I was in two minds of whether to fix the links before I moved on. As there may be more interest in this display that I anticipated, I may fix the links and split the two projects. Conrad.Irwin 22:28, 4 December 2007 (UTC)
 * Language links are now fixed, as are issues with it trying to parse divs. Thanks to User:Hippietrail for reporting those bugs on my talk page. Conrad.Irwin 00:02, 6 December 2007 (UTC)

Onto phase two, the Javascript will now attempt to split the translation sections across definitions. This really needs testing, as it currently relies on heuristics that will need tuning. I am also not sure how to include the edit links, or even if the view looks acceptable as it is. In order that the reasonably stable language tabs continue to work, to use this new feature, you should remove the format.js directive (if you still use it ;) and add document.write(' '); I would really love some comments on this, (particularly links to pages which should work but don't), if anyone has a few spare minutes :). My intention is to try and move all sections around into the same place as the yellow translation tabs, but I am not sure if this is the best (or the nicest) way to do things. [The reason I am trying to make this look logical as well as nicely split up the data is so that it is easy to visualize what is going on under the hood] Conrad.Irwin 23:46, 6 December 2007 (UTC)


 * After a lot of experimenting, it turns out that this is totally incompatible with Hippietrail's experimental WT:PREF, so please turn that off before trying this out :). Conrad.Irwin 01:44, 7 December 2007 (UTC)


 * In Firefox (2.0.0.10, WinXP), it resizes the browser window on each page load, from maxed to non-maxed. Does look pretty good ;-) Also, if I am looking at cat/Scottish Gaelic and follow the link cat, I don't go anywhere? Robert Ullmann 10:07, 7 December 2007 (UTC)


 * Well the resizing problem was simple to solve (I was using window.moveTo instead of window.scrollTo :) but the link problem is more severe, I can't think of a nice way to get round that at all at the moment. Thanks for your input. Conrad.Irwin 11:32, 7 December 2007 (UTC)

Third time lucky :)
Working on the mistakes I made in the previous versions, I have built a massive Wiktionary parsing machine. It divides the whole page into sections, matches the sections to homonyms and then shows only the definitions with toggles to get the rest of the information. Feedback would be adorable, though I do know that the "#Language" links do not yet work :(. I appreciate you are all probably bored of this enterprise by now, but i'm not yet :).Conrad.Irwin 01:00, 15 December 2007 (UTC) document.write(' ');


 * For anyone following this read, this is now a WT:PREF! "Conrad.Irwin's buggy paper view" or something similar, which is easier to tick than getting your hands dirty in your javascript. Conrad.Irwin 11:29, 25 December 2007 (UTC)

List for appendices.
I've been churning out appendices of variations of words (mostly two letter combinations such as Appendix:Variations of "ma", but occasionally hitting three letter combinations such as Appendix:Variations of "man"). I've been finding appropriate cases by hunting and pecking, but would like a more efficient path. To this end, I would like if someone could generate a list of every instance where a word has a substantial number of variations.

By "substantial", I mean eight or more (the "see" template runs up to nine, but I suspect that for many combinations with eight variations, a ninth is out there waiting to be made, perhaps in a language like Vietnamese which has unusual diacritics). By variations, I mean any circumstance where one ordered set of letters yeilds multiple entries based on different capitalization (e.g. man, Man, and MAN), diacritics (e.g. ca versus çã), or the addition of any form of punctuation (e.g. co-, co., .co, c/o).

Now, my friends, who among you can generate for me such a list?!?! bd2412 T 03:10, 4 December 2007 (UTC)


 * Are you aware of Category:Limit of template reached? DAVilla 05:40, 5 December 2007 (UTC)
 * The category only shows instances where the variations have been plugged into the template itself (and I've fairly exhausted those, but for the ones where the bulk of variations plugged in are redlinks). Cheers! bd2412 T 16:43, 5 December 2007 (UTC)


 * would need some table that translates all of the forms of (say) 'C', to 'C'. I might know where to find such a thing. ;-) Robert Ullmann 16:22, 5 December 2007 (UTC)
 * That would be neat - thanks! bd2412 T 16:43, 5 December 2007 (UTC)


 * User:Robert Ullmann/Variations should be a good start Robert Ullmann 11:55, 6 December 2007 (UTC)
 * Sir, I bow to you! bd2412</i> T 01:48, 7 December 2007 (UTC)

Bot voting in progress
Please cast your vote at Wiktionary:Votes/bt-2007-12/User:MalafayaBot for bot status. Thanks!, Malafaya 14:25, 5 December 2007 (UTC)


 * We have a bot that updates all of the interwiki links in the English wikt, in one pass, without reading individual pages in other wikts. See User:Interwicket and User:Interwicket/code. The only case where we would want a pybot framework interwiki.py bot writing iwikis here is if it is updating from new entries in one or more wikts of interest. (and User:VolkovBot does this)


 * In general, you should be reading the en.wikt, and updating home or local wikt(s). If you want to get all of the iwikis updated in a given wikt, interwiki.py will never get you there. (Change rate over all the wikts is way too high; there are 2.6 million titles, and 100K/week (WAG) new entries.) Robert Ullmann 16:20, 5 December 2007 (UTC)

Index talk:Chinese total strokes/11
Would anybody be willing to write a quick script to fix this problem? Thanks. -- A-cai 12:09, 6 December 2007 (UTC)


 * Nanshu originally generated these not broken up into sections; someone partly "improved" this entry. Yes, it would be good to rewrite the indexes at some point. Robert Ullmann 12:27, 6 December 2007 (UTC)

Inflection requests
Last night I was doing some Hebrew translation using Wiktionary. I don't know much Hebrew but I know there are two main ways to make a plural: -im and -ot. I found the Hebrew translation here for the word I was looking for but I needed the plural. So I tried to make. I based it on my earlier, which in turn was based on a template by somebody else. But since it was late at night I didn't get it working. Would anyone care to tinker with it? &mdash; Hippietrail 21:56, 7 December 2007 (UTC)


 * What should it be doing differently? It seems to work the same as, except that the latter has special formatting applied by MediaWiki:Common.css. —Ruakh <i >TALK</i > 22:46, 16 December 2007 (UTC)


 * You're right it does work now. It must've been some weird caching issue at the time. Thanks for looking! &mdash; Hippietrail 01:32, 17 December 2007 (UTC)

Keeping up with the Joneses.
Can we hire a bot to maintain a list of new pages added to other language wiktionaries for entries that we don't have? I wouldn't suggest we go so far as to automatically make a stub page for other Wiktionary entries (as I think some of the others do for ours) but at least to know what's been added there so we can keep up here. Cheers! <i style="background:lightgreen">bd2412</i> T 15:13, 8 December 2007 (UTC)


 * There are ~2.6 million unique titles in all wikts combined; and 600K here. So we have something on the order of 2M to go ... ;-). It would be useful to maybe track particular wikts for new entries in that language itself if someone is interested here. See Project - Spanish and Project - German for lists of missing entries that include entries from the FL wikt. (I.e. all the headwords in de.wikt for German words, that don't occur here with German sections.) Bulgarian has a very large set of words, of which we have relatively few. Robert Ullmann 15:48, 8 December 2007 (UTC)


 * In that case, I recommend we have such lists for all the regular languages edited here: Finnish, French, German, Italian, Japanese, Latin, Serbian, and Spanish at least. It might also be a good idea to watch each of those same wiktionaries for English entries we don't have. --EncycloPetey 23:08, 8 December 2007 (UTC)


 * We need to keep up with redlinked entries of frequency lists, not with other wiktionaries. --Ivan Štambuk 23:50, 8 December 2007 (UTC)
 * Different editors look to edit in different ways. The more varied opportunities we have for editors to locate useful contributions, the better. --EncycloPetey 00:27, 9 December 2007 (UTC)

Category:Spanish conjugation templates
I took the time to linkify all the verb forms in the output of, , , but it turns out there are bunch more such templates in Category:Spanish conjugation templates, so that the template output in, for example, conferir, is just a bunch of unlinked text. Des anyone have an automated way of doing it? Dmcdevit·t 04:40, 9 December 2007 (UTC)
 * I don't, but a related comment. Could you make those links be #Spanish language links? --Bequw 14:07, 9 December 2007 (UTC)

Does Toolserver have enwikt dump?
Does Toolserver have enwikt XML database dumps available on it (e.g. those from here http://download.wikimedia.org/enwiktionary/latest/)? If so, I'd look into getting an account. --Bequw 20:32, 9 December 2007 (UTC)
 * The toolserver does not use dumps. That copy of the database is created by replication (hence the listings of replag you see all over toolserver tools). Replag varies by server cluster, but is more up-to-date than the dumps (ie S3 has replag=3s currently). – <font color="Indigo">Mike .<font color="Indigo">lifeguard  &#124; <font color="Indigo">@en.wb 12:19, 10 December 2007 (UTC)


 * P.S. http://tools.wikimedia.de/~leon/stats/replag/page.php --Connel MacKenzie 07:12, 21 December 2007 (UTC)

Improved "did you mean" redirects
The differences between the two are that this one
 * Will check to see if <tt>&redirect=no</tt> is present in the url, and will then not redirect.
 * Sets <tt>&redirect=no</tt> to prevent MediaWiki (and itself) from double redirecting.
 * Sets <tt>&rdfrom</tt> so that the redirect can be reported to users.
 * Checks for <tt>&rdfrom</tt> and creates an "Auto-redirected from" subheading, that matches the Mediawiki "Redirected from"
 * Is much longer and more complicated :(

This has been mentioned a few times on IRC, and is pretty well tested. If you want to test it further, then copy and paste the code into your monobook.js, it should override the current version. I think that this should be put into "Mediawiki:Common.js" to get that file started, or "Mediawiki:Monobook.js" if we want to stick with current practice. Conrad.Irwin 18:46, 10 December 2007 (UTC)

Complete Code Listing


 * Very good ... users often complain that they can't get "back" to the form they are trying to create. But it isn't working for me? (I don't see the redirected from link). FF 2.0.0.11/XP Robert Ullmann 07:34, 14 December 2007 (UTC)
 * Does Firebug give you an error? Is it setting an <tt>&rdfrom=</tt> in the title bar? Creating the link works for me on FF2/Linux, Opera9/linux Konqueror. There is a slight bug in IE6/linux which means that I only get the new redirects if I refresh the page, which is I think caused by having the function definition in a different file. Conrad.Irwin 09:13, 14 December 2007 (UTC)


 * It works if I go to a URL, and I see the rdfrom. But if I type a word in the LHS "Go" box, it just goes to the page with no redirect-from? (what is doing that?) Robert Ullmann 09:50, 14 December 2007 (UTC)


 * I think that is the MediaWiki case insensitive search feature, so there is no easy way for us to handle that with js, see Bug 8245. Conrad.Irwin 10:22, 14 December 2007 (UTC)

User list
Hi. Any reason why we keep thousands of red linked non users in the users list? Can they be removed? It makes the list pretty useless as a users list :) - Algrif 18:00, 12 December 2007 (UTC)
 * Assuming you are talking about Wiktionarians there don't seem to be that many red links, and it would be fairly offensive to kick people off it. So I think we should leave it as is for now, though perhaps links to talk pages would improve it. Conrad.Irwin 18:32, 12 December 2007 (UTC)
 * I mean the user list (Special:listusers) that links from there at the bottom of the page. - Algrif 18:42, 12 December 2007 (UTC)
 * You mean kill everyone called "!!!!!" etc. wouldn't it be good, unfortunately there is no way to do this through the Mediawiki interface, we would have to get a dev to manually run a query on the database, maybe they will be able do that as part of the Unified login improvements. There is a more blue, yet equally useless list of uesrs, then Special:Allpages/User: and Special:Allpages/User talk:, but again it is 90% junk - though I suppose it could be trimmed, if someone was bored enough. (By the way if you think we have it bad, 'pedia has almost 50000 Usernames starting with punctuation or numbers :) Conrad.Irwin 23:15, 12 December 2007 (UTC)


 * Bureaucrats can rename users (presumably all to User:Badusername or somesuch) but AFAIK, there is no desire for them to do so. When a typical flurry of new (bad) user accounts are being added, e-mailing a checkuser can get them checked and blocked.  But the MediaWiki software has some weird stuff for keeping the pointers intact, for attribution.  It would be nice to have indef-blocked users excluded from Special:Listusers, but I don't think anyone has made that request on bugzilla yet.  (Seems pretty low priority, to me.)  --Connel MacKenzie 20:22, 13 December 2007 (UTC)

Template:en-verb
Do you reckon it would be worth adding more variables to the above template, to accomodate for archaic inflections like -est and -eth? Adding a bit of test for e.g. at bounce like |archaic3rd person=bounceth|archaic2ndperson=bouncest. Or would this be spurious? --Keene 20:08, 13 December 2007 (UTC)


 * The headword/inflection line should only show a few key forms of the word. To show other inflections, including archaic ones and regular constructions like the imperative, the first person singular future, and the second person plural past progressive, a separate ====Conjugation==== section is preferable.  Rod (A. Smith) 17:59, 14 December 2007 (UTC)

Site notice - donations
Who maintains this? It has claimed that 24,923 people have donated for some time. Click Hide this message and the short version claims that 39,876 people have donated. Wikipedia claims the number is 29,034, and the French wikitionary thinks its 34,300. No wonder we have a reputation for inaccuracy. Jonathan Webley 09:11, 14 December 2007 (UTC)


 * I see 36,860 on this page right now ... Robert Ullmann 09:16, 14 December 2007 (UTC)


 * That is very odd indeed, I have copied this to the Fundraiser talk page and replied there. Conrad.Irwin 09:33, 14 December 2007 (UTC)

Problem with Unicode beyond BMP
I did a minor edit to black and found that the Gothic word, which had looked like a bunch of boxes, had turned into numbers, presumably surrogates (I haven't checked). I'm running Konqueror 3.5.5. Unicode points within the BMP don't give this error. Which program or library has the bug? PierreAbbat 22:23, 16 December 2007 (UTC)


 * I don't know, but it looks like your last edit may have done something to the section above (I've since reverted that change). Mike Dillon 22:28, 16 December 2007 (UTC)


 * I just fixed black too. It looks like you're correct that you're edit turned each of the SMP Unicode characters into the HTML entity representation of their surrogate pair equivalents (it turned 4 characters into 8 entities and the one entity that I checked was in the surrogate range). Since I was able to successfully change the characters back using my browser (Mozilla Seamonkey 1.0.8), I think it's probably your browser doing it. Mike Dillon 22:32, 16 December 2007 (UTC)


 * Yes, "on the wire" (as transferred over the net), these characters are in UTF, as multibyte characters; they often get converted to 16 bit unicode, (UTF-16, which is a horrible hack) and they turn into pairs of 16 bit characters (starting at 00D8). Python does this, which is annoying, but at least it converts them back correctly ;-). If Konquerer converts to HTML entities, it should be converting each character to one entity, but apparently not. (Even FF can't handle entity numbers > 65536 ;-. Too bad it (K) won't do something reversible. Robert Ullmann 06:34, 17 December 2007 (UTC)

Wonky French sorting
Why, under Category:Latin adverbs, does the listing for facile sort under left curly bracket, i.e. {? From poking around, it seems to be a problem with Template:fr-adj, since there are a large number of entries sorted this way in that category, and also since this is the only template appearing on the page for facile that uses DEFAULTSORT. Could someone attend to this template? --EncycloPetey 04:33, 17 December 2007 (UTC)


 * So here's a failed attempt: see . Close (winds up sorting in the right place in the category) but no cigar (extra '}' at the end othe infleciton line, see coquin for an example). Anyone else want to try?  ArielGlenn 06:21, 17 December 2007 (UTC)


 * Pretty good, you just needed to provide an else, something like <tt> </tt>, but as noted, we don't want to use DEFAULTSORT anyway. Robert Ullmann 06:51, 17 December 2007 (UTC)


 * It (fr-adj) was badly modified by user "Rural Legend" (Wonderfool sock). DEFAULTSORT takes effect even when in the unused branch of a conditional. (And we don't want the side effect on other languages on the page anyway.) Fixed now. Robert Ullmann 06:43, 17 December 2007 (UTC)


 * Thanks to both of you for sorting this out. --EncycloPetey 15:25, 17 December 2007 (UTC)

remnant of Wikipedia
The tabbing bar atop each page calls our entries articles, which must be a remnant of Wikipedia, Wikimedia's firstborn child. A dictionary doesn't have articles: it has entries. Is there a way to change this? (Has this been discussed before?)&mdash;msh210 &#x2120; 21:43, 18 December 2007 (UTC)
 * This could be changed very easily by any administrator editing the MediaWiki space, I think. However, I'm not sure I agree with you. I tend to call them articles, and that's because the other words that people use for dictionaries, like "definitions" aren't adequate for Wiktionary; we do so much more. With meaning + etymology + pronunciation + translations + related/derived words + quotations + any number of other sections most dictionaries don't include, I think it might be safe to call it an article. Of course, I'm not quite sure that there is the distinction that you are drawing between "entry" and "article" but "article" at least implies much more strongly a full-fledged, um, article. Dmcdevit·t 23:22, 18 December 2007 (UTC)
 * A minor point against article is that someone might (unlikely, I admit) think it means a, you know, an article. Like the.&mdash;msh210 &#x2120; 22:31, 20 December 2007 (UTC)


 * It can be changed by editing MediaWiki:Nstab-main. This will only affect the default view when English is the display language. If "uselang" or a language preference is being used, then that language's default will still show (e.g. MediaWiki:Nstab-main/de which says "Seite"). Mike Dillon 23:10, 18 December 2007 (UTC)


 * Perhaps a poll could be done to see what people prefer (or even have a preference)? --EncycloPetey 03:05, 19 December 2007 (UTC)


 * I've (for several years now) used entry not article to clarify context. (I do forget now, which old-timers cleared up my confusion of the distinction.)  We don't call them articles here (except for occasional errors) so I can't imagine why this wouldn't be fixed immediately.  --Connel MacKenzie 20:39, 20 December 2007 (UTC)


 * The distinction between articles and entries may be useful in discussion allowing us to refer to a WP article as "the article" and WT's entry as "the entry". We could also detect newbies more easily. &:-) DCDuring 21:01, 20 December 2007 (UTC)


 * I also try to use "entry" not "articles" on Wiktionary. Conrad.Irwin 22:20, 20 December 2007 (UTC)

Is there any interest or opposition to this change? I support it, and will implement it if there is no opposition. Conrad.Irwin 16:09, 5 January 2008 (UTC)


 * Go ahead. (For the record, the OED says in its entry for -t:, "See the article -ED suffix1", so I don't think this is a misuse of the term "article". But the term "entry" is preferable, if only to help distinguish us from Wikipedia.) —Ruakh <i >TALK</i > 17:47, 5 January 2008 (UTC)

Mediawiki:Longpagewarning
Currently advises people to split pages, probably not something we want people to do here. We could perhaps remind people about the [Citations:] namespace, and advise them to edit only sections if they are having problems. Conrad.Irwin 11:24, 25 December 2007 (UTC)


 * Sounds good to me. —Ruakh <i >TALK</i > 17:47, 5 January 2008 (UTC)


 * Done this one, I'll leave the "article"->"entry" for another day or so. Conrad.Irwin 00:00, 6 January 2008 (UTC)


 * Meh, they're not like templates; they don't go into the job queue for ages or anything. (Extreme boldness is bad, obviously, but this was discussed and seemed generally to have support, and isn't a change most people will even notice.) So, I've made the change; if anyone complains, I'll revert. —Ruakh <i >TALK</i > 00:22, 6 January 2008 (UTC)


 * On second thought, I've reverted myself; since it wasn't like this had unanimous and enthusiastic support here, and since it will affect every single page in the main namespace, it should probably be at least mentioned at WT:BP before being done. —Ruakh <i >TALK</i > 00:31, 6 January 2008 (UTC)

ImageMap extension
I recently saw that wiktionary has the Extension:ImageMap. This reminded me of the Visual dictionary idea, so I mocked up a page showing the solar system where you can click on the planets and go to their entries. I tried to make it a template so that someone could pass in planet names aside from English ones but had some trouble. With a little work, and 2 seperate templates I got this to work in Special:ExpandTemplates:

But the strange thing is that on any page it gives the error "
 * to your [User:Username/monobook.js] or whichever skin you wish. You will then need to create I will shortly be adding a bit of documentation to User_talk:Conrad.Irwin/edittools.js to show you how the various pages should be formatted, an example of personalised user sections can be found at User:Conrad.Irwin/edittools. Conrad.Irwin 21:57, 28 December 2007 (UTC)
 * I'm testing this and failing. I suspect I'm not formatting the edittools replacement correctly (probably an illegal id or something). Care to take a look at User:Circeus/edittools? Circeus 00:30, 29 December 2007 (UTC)


 * Hmm, it works for me. User:Conrad.Irwin/edittools. If nothing at all is happening you may need to Refresh harder. Conrad.Irwin 00:50, 29 December 2007 (UTC)


 * That was caused by a bug in Firefix 3b2, which I have patched for the moment. I now know this works in Opera9, Firefox2+3, IE6, Konquerer 3.5. If you want to try this out, and it works (or doesn't) in a different browser, please let me know. Conrad.Irwin 13:29, 29 December 2007 (UTC)


 * Indeed, it works now, and looks great! I,ll toy around it some more. Circeus 17:00, 29 December 2007 (UTC)


 * Works great in IE7 too! --Ivan Štambuk 17:55, 29 December 2007 (UTC)


 * It's working for me in Safari, though it took a while to "kick in". --EncycloPetey 19:06, 29 December 2007 (UTC)

There have been a couple of unadopted proposals for JS versions of edittools on Wikipedia. You may want to take a look at these links:


 * w:MediaWiki talk:Common.js/Archive Apr 2007
 * w:MediaWiki talk:Edittools

I seem to remember seeing a more recent one as well, but I can't find it... Mike Dillon 02:59, 29 December 2007 (UTC)
 * They seem to be different approaches to a similar problem. To be honest I prefer the Javascript based solution for its neatness, however it is much harder for users to edit and create their own sections (and also the javascript becomes much longer when you are adding in the handling for sections selectable by drop down box, versus labels between sets of letters in the section - also mentioned on IRC was the ability to have a different label from the character inserted (For vowel modifiers in Arabic etc.) It is possible that we could move on to doing something like this in the future, but I am not sure if it is worth it for the moment. Conrad.Irwin 13:29, 29 December 2007 (UTC)
 * I just wanted to point those attempts out so that the work could be reused if a decision was made to do something along these lines. I've long since divested myself emotionally from whether that code gets used or not. I personally don't use the edittools stuff one way or the other, so I don't have a huge interest in the outcome of this discussion. For what it's worth, my prototype code already handles the section v. dropdown stuff and the alternate display labels, so even though the code is indeed much longer with that support, at least the code doesn't necessarily have to be written from scratch. Mike Dillon 15:52, 29 December 2007 (UTC)

Migrating Edittools to use this
This seems to work well for people's personal Edittools (see above), but that was only intended as a bonus feature :). The main reason for having this would be to greatly reduce the 163kb that are currently added to every edit page by MediaWiki:Edittools (See for how much that is uncompressed (though it should be gzipped normally)).

The way I would envisage shortening edittools would be to only initially load a few sections, perhaps English Templates, Accented Latin, and IPA. The other sections would then be got using the XmlHttpRequest object when they are requested (Either all the unloaded sections together, or each section separately - or maybe some happy medium, when the links are selected in edittools). The idea behind this is to make things easier on both the clients and the servers, so while I believe that the requests are fully cached, we would need to be sure that both the "action=render" function of MediaWiki caches, and also that the XmlHttpRequest in all browsers cache, to be sure of any advantage.

The reason I would prefer to load each template separately is that it means that people can set a cookie of which sections to load at the start, without having to set up their own edittools page. This might lead to four or five seperate (cached) requests each page load, but lacking any real knowledge of how these things work I can only conjecture as to what would be best. Does anyone with a better idea of how things work want to point this in the right direction. Having looked along the links that Mike Dillon gave, it seems that kk.wikipedia used to use a similar idea, but stopped - and I can't work out why. Conrad.Irwin 22:28, 29 December 2007 (UTC)


 * I didn't notice that kk.wikipedia.org was using something like this, but they are still using a version of the JS code I linked to above. They recently moved it to w:kk:МедиаУики:Gadget-edittools.js when mw:Extension:Gadgets was enabled on Wikipedia. Mike Dillon 00:52, 30 December 2007 (UTC)
 * Ah, thank you, there internal links pointed me to the wrong place. By a similar idea I meant, taking the edittools out of the edit page. Conrad.Irwin 10:18, 30 December 2007 (UTC)

Category:Katharevousa
What's Category:Katharevousa about? --Keene 23:49, 29 December 2007 (UTC)
 * It's about Katharevousa, of course! But why are you asking that question in the technical issues forum? --EncycloPetey 00:07, 30 December 2007 (UTC)
 * Indeed. Have categorised thus. Sorry for putting it in wrong place --Keene 00:08, 30 December 2007 (UTC)