Wiktionary:Grease pit/2007/December

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 {{en-noun}}, {{en-adj}}, {{en-verb}}, and {{en-adv}}, but {{fi-form of}}? 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)

I've noticed that everywhere the {{see}} 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 {{see}} 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)

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('<script type="text/javascript" src="https://en.wiktionary.org/w/index.php?title=User:Conrad.Irwin/format.js&action=raw"></script>');

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=== {{en-verb|astonishes|astonishing|astonished}} # ], ]

Nadando 03:00, 4 December 2007 (UTC)

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#Hungarian. 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('<script type="text/javascript" src="https://en.wiktionary.org/w/index.php?title=User:Conrad.Irwin/structure.js&action=raw"></script>');

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. 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#English, 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)

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('<script type="text/javascript" src="https://en.wiktionary.org/w/index.php?title=User:Conrad.Irwin/parser.js&action=raw"></script>');

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)

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 T 01:48, 7 December 2007 (UTC)

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)

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)

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 {{inflreq}}. I based it on my earlier {{trreq}}, 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? — Hippietrail 21:56, 7 December 2007 (UTC)

What should it be doing differently? It seems to work the same as {{trreq}}, except that the latter has special formatting applied by MediaWiki:Common.css. —Ruakh_TALK 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! — Hippietrail 01:32, 17 December 2007 (UTC)

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! bd2412 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 Wiktionary:Project - Spanish and Wiktionary: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)

I took the time to linkify all the verb forms in the output of {{es-conj-ar}}, {{es-conj-er}}, {{es-conj-ir}}, 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 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). – Mike.lifeguard | ^@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)

The differences between the two are that this one

• Will check to see if &redirect=no is present in the url, and will then not redirect.
• Sets &redirect=no to prevent MediaWiki (and itself) from double redirecting.
• Sets &rdfrom so that the redirect can be reported to users.
• Checks for &rdfrom 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)

/**
 * doRedirect will redirect if a did you mean box is found, and create a 
 * "redirected from X" if a rdfrom is passed in the get parameters
 * The first half is an ugly workaround for Bugzilla:3339, :(
 * The second half is an ugly workaround for not having serverware support :(
**/
function doRedirect() {
   var dym = document.getElementById('did-you-mean')
   var from= window.location.href.replace(/^(.+rdfrom=(+).*|.*)?$/,"$2");
 // REDIRECTED FROM
   if(from){ 
     var insertPosition= document.getElementById("siteSub");
     var div=document.createElement("div");
     if(insertPosition){
       div.setAttribute("id","contentSub");
       var tt=document.createElement('tt');
       var lnk =document.createElement('a');
       lnk.setAttribute("href",wgArticlePath.replace("$1",from)+ '?redirect=no');
       lnk.appendChild(document.createTextNode(decodeURI(from)));
       tt.appendChild(lnk);
       div.appendChild(document.createTextNode("(Auto-redirected from "));
       div.appendChild(tt);
       div.appendChild(document.createTextNode(")"));
       insertPosition.parentNode.insertBefore(div,insertPosition.nextSibling);
       }
 // DID YOU MEAN
     }else{
       if( dym 
           && !window.location.href.match(/redirect=no/)
           && (getCookie('WiktionaryDisableAutoRedirect') != 'true')
         ) {
       var target = dym.firstChild.title;
       var pagetitle = document.getElementsByTagName('h1').firstChild.nodeValue;
       
       if( pagetitle != target 
           && pagetitle.toLowerCase().replace(//g, "") == target.toLowerCase().replace(//g, "")
           && pagetitle.search(/Editing /g) == -1
           && !document.getElementById('contentSub').innerHTML.match("Redirected from") // does contentSub always exist
         ) {
         document.location = wgArticlePath.replace("$1",encodeURIComponent(target.replace(/\ /g, "_")))
                           + '?rdfrom=' + encodeURIComponent(pagetitle.replace(/ /g,"_"))
                           + '&redirect=no';
       }
     }
   }
 }

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 &rdfrom= 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)

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

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)

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)

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 #Hieroglyphs 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)

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 {{fr-adj-2}}. 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 {{ {{#if:{{{cat|}}}|DEFAULTSORT|#if}}:{{{cat}}} }}, 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)

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?)—msh210℠ 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.—msh210℠ 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 (deprecated template usage) -t, "See the article -ED suffix¹", 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_TALK 17:47, 5 January 2008 (UTC)

Currently advises people to split pages, probably not something we want people to do here. We could perhaps remind people about the 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_TALK 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_TALK 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_TALK 00:31, 6 January 2008 (UTC)

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:

{{User:Bequw/template5}}
{{User:Bequw/template4|Mercurio|Venus|Tierra}}

But the strange thing is that on any page it gives the error "<imagemap>: must specify an image in the first line" (See User:Bequw/solar_system). Any ideas? Is there anyway to pass parameters inside the imagemap tags? --Bequw → ¢ • τ 22:43, 18 December 2007 (UTC)

You can't use parameters inside < > tag type extensions. (math, heiro, etc). The reason it works in Special:expand is that it is expanding the templates first, and then reparsing it again for the preview. If you pasted the expanded result into a page, it would also work. Sorry. You aren't the first person to find this extremely frustrating. Robert Ullmann 13:31, 19 December 2007 (UTC)

Two problems:

1. Apparently, this template assumes that all comparative forms are forms of adjectives. This is not the case. Latin diūtius is a comparative form of an adverb. Is there a way to let the template know that it should not include the adjective category? or to tell it the correct POS? --EncycloPetey 04:46, 19 December 2007 (UTC)
2. See (deprecated template usage) albior. The template is doubly-categorizing this page; once to the correct category (Latin comparative adjectives, red-linked), and once to an incorrect category (Latin adjective comparative forms, blue-linked). --EncycloPetey 04:48, 19 December 2007 (UTC)

By providing the POS=Adverb argument to {{comparative of}}, then it will put it in the Adverb category. The other categorisation comes from the use of {{la-adj-comparative}}, which has the Adjective category hard coded in. I have taken the liberty of creating a new template {{infl form}} which can be used in place of {{la-adj-comparative}} in this case, and in other places if it gains approval. (I have used the category naming scheme from {{comparative of}}, (Latin comparative adverb forms) instead of the possibly nicer (Latin comparative adverbs) for the moment because that is easier for computers to implement.) Conrad.Irwin 22:17, 20 December 2007 (UTC)

But that is wrong. For adjectives, the main comparative form should be in the category Latin comparative adjectives. The various inflections of the comparative should be in Latin comparative adjective forms. Latin adverbs ought to be in Latin comparative adverbs and Latin superlative adverbs. Saying "comparative adverb forms" is misleading because the comparative adverb does not inflect (unlike comparative adjectives, which do).

In any case, the inlfection line is not the problem here, it's the "comparative of". If necessary, we should just be able to switch off the categorization it does, since it will apparently always be wrong for Latin. --EncycloPetey 23:48, 20 December 2007 (UTC)

Ah, I see what you mean now about the categories. I thought that the "comparative of" should be in the inflection line, as it is not what the word means (though it does seem that this isn't done at the moment). I do see that I was talking drivel before, so bear with me if I am again. What I think we want are two templates, one that allows {{----|la|comparative|adverb|diu}} and one that allows {{----|la|genitive plural|diutius|comparative|adjective|diu}} in the inflection line (giving "diutius comparative of diu and albiōris genitive plural of albior comparative of albus ). I can't believe that Latin is the only language that runs into this problem. Conrad.Irwin 12:57, 21 December 2007 (UTC)

Ok, you're closer now to grasping the enormity of the problem, but still a couple of missing pieces. The examples you've given sill include the name of the referring page, which it should not. The inflection line template for non-lemma typically includes only the form discussed on the page. The link to the lemma and all the grammatical information are placed in-line as part of the "definition". This also does not address the issue of not including the category. Also, in Latin the nominative singular comparative adjective acts as a kind of lemma, and will need its own definition, in addition to the grammatical information. One problem not yet pointed out is that the target lemma will not have macrons in the pagename, but we will want to have macrons in the display form in the link. Perhaps it is best just to not use {{comparative of}} for any Latin entries. --EncycloPetey 14:02, 21 December 2007 (UTC)

I certainly agree that there is no reason to use {{comparative of}} as it makes it harder to do what you want (though it should be edited to take argument CAT= like {{infl}}), however I don't think that it does the right thing at all. It seems to me that grammatical information should not be considered as part of the definition, which is what this does. I will have to read all the discussion linked to Wiktionary:Votes/2007-11/Lemma_entries_2 and see if I can work out a clearer way to say what I think. Conrad.Irwin 19:11, 21 December 2007 (UTC)

Apologies if this isn't the place to put this, but I can't find an equivalent of enwiki's list of mirrors. Has anyone seen wikitionary.biz? (I won't link directly to it, for similar reasons to those used on WP:MIRROR). It appears to be a mirror of Wiktionary (notice the "wiki" in the title, as well as the top-level domain difference), except with lots of ads, and all occurrences of the word "Wiktionary" simply removed. "Wiktionaries", "Wikipedia" and the like seem to be fine. I don't know what policies you have here with regards to them if any, so I'll just leave it here. I just found that the name seems to be intended to ape that of Wiktionary, and may therefore be breaking some rule or other. Apologies once more if this isn't the right place. --88.104.189.238 12:50, 19 December 2007 (UTC)

Oh, a quick Google search reveals this discussion on Nabble. That was a month back though, and the mirror is still using trademarked images and the like... --88.104.189.238 12:57, 19 December 2007 (UTC)

• Please list them at meta:Live mirrors. --Connel MacKenzie 21:03, 20 December 2007 (UTC)

I know about Special:Prefixindex. What I want is Special:EndsIn so I can find all words ending in .... (in this case, "other").

Thanks, User talk:GarrieIrons (just created account) GarrieIrons 09:45, 21 December 2007 (UTC)

• No, the best we have is individual suffix entries. See -logy for an example with a long list. SemperBlotto 10:05, 21 December 2007 (UTC)
• Have you looked at Rhymes:English:-ʌðə(r)?— This comment was unsigned.
  • Since that list is hand-maintained, it's always a good idea to look at the likely longer list Special:Whatlinkshere/Rhymes:English:-ʌðə(r), available by following the "What links here" link on the page Rhymes:English:-ʌðə(r). (It doesn't seem to be longer in this case, but for next time....) (Why, incidentally, do we hand-maintain these? Iff we're willing to part withthe number-of-syllables info, it should be easy enough to bot-maintain. Alternatively (and again iff we're willing to part with the number-of-syllables info), is it possible to convert the Rhymes ns into a category-like ns, so that the info appears inline in the page, but categorization is automatic? I mean, does MW allow such a thing?)—msh210℠ 18:29, 27 December 2007 (UTC)

• I was thinking also — and others have suggested iIrc — that it'd be nice to have a reverse index: alphabetical by last letter of the word, then by second last, etc.—msh210℠ 18:29, 27 December 2007 (UTC)

  I agree, though setting it up as a series of static pages would not be my preference. The problem, however, is how to do it without static pages so that one can look by specific language(s). There is a world of difference between Engllish words ending in ar' and Spanish words ends in ar (and all words anding in ar). --EncycloPetey 18:33, 27 December 2007 (UTC)

There appear to be two Extensions that would allow this: mw:Extension:LuceneSearch and mw:Extension:Wildcard search. I don't know if en.wikt has experimented with different search capabilities (maybe on the dev version) but they can probably say if it's feasible or worth it. --Bequw → ¢ • τ 23:15, 27 December 2007 (UTC)

Could someone please see MediaWiki talk:Edittools#Hebrew and edit Mediawiki:Edittools according to the last suggestion there (which was seconded at User talk:Ruakh#edittools)? Thanks.—msh210℠ 06:25, 25 December 2007 (UTC)

Done. Thanks.—msh210℠ 23:17, 3 January 2008 (UTC)

What happened to http://wiktionarydev.leuksman.com ? It's not answering HTTP requests. Rod (A. Smith) 21:48, 27 December 2007 (UTC)

According to someone on IRC, they are decommissioning the server that it runs on. It should, I believe, be put back up on a different server. Conrad.Irwin 10:44, 28 December 2007 (UTC)

Could somebody with more knowledge of the workings of templates add a lang= parameter, so that (for example) {{notred|oui|lang=fr}} will output ]? If so, that would be badasslyawesome :) — opiaterein — 21:13, 28 December 2007 (UTC)

Given that this is nominated for deletion, probably not until that is resolved ;). Conrad.Irwin 11:07, 30 December 2007 (UTC)

Copied from the Beer Parlour

When you edit a page, the language drop down includes templates for English only- the other languages just have special characters. Would it be possible to include language specific templates in there too? For example, Spanish would have {{es-noun-m}}, {{es-adj}}, {{es-conj-ar}}, etc.? Nadando 19:06, 27 December 2007 (UTC)

That is possible to do, but MediaWiki:Edittools' size is a significant factor. --Connel MacKenzie 19:16, 27 December 2007 (UTC)

I recently asked for them on the Edittools talk page and someone immediately requested French ones as well. It would be nice if the basic templates for all active en.wikt languages were there. It would probably help newbies make more standard articles. Is there anyway to keep the size in check and still do this? --Bequw → ¢ • τ 22:21, 27 December 2007 (UTC)

No. There are just way too many templates in too many languages. Is there a way to customize the Edittools? Say, to have an optional section that pulls up a user-generated list of items from a specified subpage dependant on the editor's username? --EncycloPetey 23:14, 27 December 2007 (UTC)

That is a great idea. We could even add languages to WT:PREFs, to make it easy for people to check the ones they need. (I really dislike the enormity of edittools). Conrad.Irwin 23:23, 27 December 2007 (UTC)

Erm, what? Where would you add them then and how would &uselang= toggle it? You'd only be making it still larger and hiding random subsets? --Connel MacKenzie 23:35, 27 December 2007 (UTC)

Not if it's set up to generate a personalized list and only call that personalized list. I imagine a version of Edittools that only loads the items a user has checked off as wanting to use, plus a personalized section listing things not normally found. I, for example, never need the Arabic, Hebrew, and Welsh sections (for example), so having it always load every time is wasteful. But there are editors who find those sections very useful. On the other hand, I'd like to be able to plug in the Latin inflection, declension, and conjugatioin templates so that I don't always have to go look them up for unusual forms. Very few other editors would find these templates useful, but if I could have a customized version, then no one else would be bothered. Now, I'm not fluent in how the Tools are coded and loaded, so I couldn't say whether any of this is truly feasible, but it seems that there ought to be a way to have (1) A customizing tool, drawing from standard list sets as currently in the Tools, (2) A standard way and place to save the customized content in the editors user namespace, and (3) Set the Edittools to call the customized content if it exists, or else fall back on the default content (which could be set much smaller). --EncycloPetey 01:58, 28 December 2007 (UTC)

Hmmm. Separate http ajax requests for each Edittools section? Might be a bit too much, both for broadband connections and for the poor WMF servers. (Ajax requests generally are not cached at all - so they'd reload for every page load.) Even 13 or so supplemental Edittools pages (by language family) would be enormously taxing. (You can see part of that problem, if you turn on the WT:PREF for "Allow special characters to be input into the search box" - which does use ajax that way on the single Edittools page.) Move this (soft-linked) to WT:GP? --Connel MacKenzie 20:02, 28 December 2007 (UTC)

Not exactly what I was thinking. Not a separate request for each section, but the option to create a single file per user (with internal sections) that is then called when that user begins to edit. The user would have one section of the file reserved for personally desired items not in the master template from which all such user files are originally generated. That is, there would be a huge master file (never called), which would have an associated tool from which an editor could "shop" for those sections he or she would find most useful. The tool then saves only those sections to the user's personal Edittools, and this personalized version is what gets loaded. This would only apply to registered users who have an account. Is something like that feasible? --EncycloPetey 20:29, 28 December 2007 (UTC)

Hmmm. Stored as text within a user Javascript page (kindof like the patrolling JS) might cache better. If/when wiktionarydev comes back, it might be worth an experiment or two.  :-)   --Connel MacKenzie 21:08, 28 December 2007 (UTC)

I actually think it'd a really good idea, if we weren't trying to throw in every single template for whatever particular language it is. It might help with people using the wrong templates, or not using them or whatever. — opiaterein — 00:52, 28 December 2007 (UTC)

That would be a great idea, not just for language-specific templates, but also for various (generally) rarely used scripts that are not likely ever to make it to Edittools (e.g. Early Cyrillic, Glagolitic, cuneiform syllabograms, Lycian, Lydian..). At present, average contributor finds 90% of MediaWiki:Edittools content completely useless. BTW, is there a way to disable loading Edittools when editing pages? It sucks up bandwidth ^_^ --Ivan Štambuk 21:01, 28 December 2007 (UTC)

I have created one possible solution to this. It involves at least one further AJAX call per edit page, to User:Username/edittools. From initial experiments it seems this is cached to some extent, as I was receiving "304 Not Modified" headers from the servers. The other thing it does (at the moment), is that if the section is not in Mediawiki:Edittools or User:Username/edittools, it looks for Mediawiki:Edittools/sectionname - though it maybe best to have all the non-default sections in one place, so that a maximum of one (huge) call needs to be made.

If you wish to experiment with this then you can add

document.write('<script type="text/javascript" src="https://en.wiktionary.org/w/index.php?title=User:Conrad.Irwin/edittools.js&action=raw"></script>');

to your 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#Proposal: Editpage.js
• w:MediaWiki talk:Edittools#New prototype

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)

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)

What's Category:Katharevousa about? --Keene 23:49, 29 December 2007 (UTC)

It's about w: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)