Wiktionary:Grease pit/2007/November

Category:English nouns
"There are 186 entries in this category." Of course there are a lot more entries than that in the category. Would it be possible for the number to be all of the entries in that category, rather than just what's on the first page? Nadando 16:52, 3 November 2007 (UTC)
 * This is a problem across all of Wikimedia. Every category page, whether here or Wikipedia, or Commons, etc.  all give that same blurb with the number of items shown on the current page.  I don't think anyone here has the means to fix the problem. --EncycloPetey 22:14, 3 November 2007 (UTC)


 * The blurbs are translatable, though; doesn't that suggest that they're editable somehow without resorting to a software patch, even if it's something we need a bureaucrat for? (Caveat lector: I really have no idea how localization works in MediaWiki.) —Ruakh TALK 22:48, 3 November 2007 (UTC)


 * Yes. MediaWiki:Categoryarticlecount is the system message.  What should it say?  Rod (A. Smith) 23:28, 3 November 2007 (UTC)


 * Thanks. And, no clue. It seems that we can't distinguish between the case that all $1 pages are shown, the case that the first $1 pages are being shown but more exist, and the case that some $1 pages are being shown but they're not the first $1, unless we want to go JavaScript-y with it (and even then we need a sensible default). Would "Shown here are $1 entries in this category" be too silly? (And whatever we do, I guess we need to do it with MediaWiki:Subcategorycount as well.) Maybe the best approach is simply to blank out these messages until such time as they can be made accurate without sounding silly; I don't see that they're terribly useful, anyway. At least, blanking-out can be the default behavior, with JavaScript converting it to the appropriate message. (Something like, I mean, with JavaScript hooks.) —Ruakh TALK 03:25, 4 November 2007 (UTC)


 * I find the counts useful, so I'd rather not see them blanked out entirely. Here is what WP uses for their message: "There are $1 pages in this section of this category". --EncycloPetey 14:08, 4 November 2007 (UTC)


 * Sounds good to me; I've been bold and switched to that message. (If anyone objects, it's easy to switch back.) —Ruakh TALK 16:30, 4 November 2007 (UTC)

1212 H. (talk) 13:53, 7 November 2007 (UTC)


 * There's always this. Unfortunately, the "&offset=" thing starts at the next one, so this probably can't be linked easily from every category page.  --Connel MacKenzie 18:12, 11 November 2007 (UTC)

Indices
Hi, the current status of the index Namespace is a little bit haphazard, it doesn't look like there is a bot that is responsible for these - is it an automatable task? I would have thought that it could just merge all s and s etc. into an alphabetical list - but no doubt that wouldn't work that well...

The other alternative for indexing would be to use the Special:Allpages/ Special:Prefixindex, however, as they list all the redirects as well, they are not that great. Conrad.Irwin 18:45, 6 November 2007 (UTC)


 * The Indices were a tool of the early days, now gone. The namespace isn't used much of late, mostly because there hasn't been much interest.  Personally, I think they serve a useful purpose (or would if they were handled right), but it's going to take someone seriously dedicated to improving them. --EncycloPetey 03:29, 7 November 2007 (UTC)

Hieroglyphs
I found , ox’s head, will make this appear on a new line. Can someone solve this, or point out a solution? H. (talk) 13:42, 7 November 2007 (UTC)


 * Have you seen 𐤀 (but don't know if it helps)? SemperBlotto 13:46, 7 November 2007 (UTC)


 * I was playing with this before when someone was adding some Egyptian entries. It isn't newlines, it is generating an HTML table. The images come from (e.g.) '/w/extensions/wikihiero/img/hiero_F1.png'. It would be nice if someone did a better job with that extension. I don't know if these images are also on commons? If so, they could be inlined with the text. Robert Ullmann 14:01, 7 November 2007 (UTC)


 * Do note that the table does specify "display:inline", but that this isn't actually supported by the CSS spec (at rev ?) and browsers do not generally do what they ought to. (lots of gotchas in handling blocks and frames ;-) Robert Ullmann 14:08, 7 November 2007 (UTC)


 * But since the browsers can't handle the table displayed inline, one might always wrap a div  around it, so it is inside a frame that will. (:-) Eh? Robert Ullmann 14:16, 7 November 2007 (UTC)

Links with image as linktext
Hi, does anyone know if it there is a nice way of creating an audio link with only the speaker. (I know I am being fussy). At the moment, it seems that I could use which asks me not to use it unless unavoidable - so probably shouldn't be on main page? Or which is also a bit of a rendering nightmare I would think... The reason for asking is that I have an idea for a new main page and to go with it, a new (backwards compatible) wotd template - is there any solution to this problem; i.e. a way to create  using mediawiki? Conrad.Irwin 21:26, 8 November 2007 (UTC)


 * Like  this? Robert Ullmann 00:21, 9 November 2007 (UTC)


 * Well - I said I was being fussy... The problem with that is that there is nothing in the  tags, and so a browser may legally ignore it as an empty tag. Also, as there is no link text there is nothing for those who don't get pictures to see (a picture with alt text would give them something at least). Just tell me to get stuffed if I am being awkward. Conrad.Irwin 00:41, 9 November 2007 (UTC)

Template:pluralonly
uses. To me, that suggests it is intended for use in definition lines. In accord with recent suggestions to move grammar details from definition lines to headword/inflection lines, though, should we support something along the lines of ? Rod (A. Smith) 21:32, 8 November 2007 (UTC)

User:Keenebot2
OK, so I have a new bot account, and a new hard drive. I'm wanting to get my Keenebot working (please bear in mind that I'm a complete beginner with bots. Absolutely completely a beginner)! Here's what I've done so far, as suggested in an email conversation by SemperBlotto in July.


 * 1) I've downloaded the Python software
 * 2) I've got the correct user-config.py
 * 3) I've made a text file called fr-er.txt, which is the model of all the conjugated forms of French verbs, as used in Wiktionary; and a fr.txt file which gets changed for each verb.
 * 4) I made a frfromfile.py, which SB sent me, which apparently works and uses data from fr.txt, which has all the data I fr-er.txt
 * 5) I downloaded the pywikipedia zip file, and expanded it.

I need now to get the "login.py" thing going, but I don't know how to do that. I'm not sure what to change in the code. Please help me with this, and if you think I should post codes here, or in an email to users who know this stuff, then I'll do that. If you think IRC might be a good place to discuss it, let me know and I'll sign up to IRC. Regards, --Keene 23:17, 8 November 2007 (UTC)


 * I'll be glad to help. But why "Keenebot2"? Isn't there still "KeeneBot"? ;-) Robert Ullmann 11:36, 9 November 2007 (UTC)

Tbot entries
I've been working on the code in Tbot to create entries that are missing. It uses the t template information to create new entries.

All of the entries created are in Category:Tbot entries and it doesn't add language sections to existing entries. So we can always strip everything (remaining) out of that cat if there is a problem. That is why I am fairly comfortable just plowing ahead with this. Several entries have already been checked by other editors.

The entries also go into per-language categories, e.g. Category:Tbot entries (Esperanto). The entries are only created for a language if the category exists, and if it is "full" (presently 200 entries), Tbot won't generate any more; so if no-one is working on the language it will stall. If someone does check entries, and removes the tag (which see ;-), then there will be room for more.

This isn't part of the present bot flag vote; I anticipate probably another vote, after you have something to look at and some discussion. I have been doing repeated debugging runs over the last few days, and there is probably (um, always) more. Robert Ullmann 11:36, 9 November 2007 (UTC)


 * (one additional note) Tbot is throttled to no more than one page edit/create every 70 seconds, and in practice runs more slowly. When it is running, Rat Patrol is also always running (e.g. my net connection in Kenya is working ;-) so they will be patrolled. Robert Ullmann 11:39, 9 November 2007 (UTC)

A basic intent with this is to create entries that new(er) users feel comfortable adding to/correcting. I've noted that they will add translations and update existing entries. Creating new entries, not so much. (Not counting "xxx is teh gay" entries.) So this may be very good. Several regular editors have already expanded entries and removed the tag. Robert Ullmann 05:40, 10 November 2007 (UTC)


 * I heartily approve of this product and/or service. Cynewulf 05:42, 10 November 2007 (UTC)


 * Word; I think it's great. :-) —Ruakh TALK 05:47, 10 November 2007 (UTC)


 * The bot seems to work perfectly, and is useful in spotting bad (or poor) translation entries. SemperBlotto 11:57, 16 November 2007 (UTC)

Typo on a protected page
There's a typo in Criteria_for_inclusion (last paragraph of Idiomaticity: exmples should be examples), but the page is protected as well as its discussion page. Is there a proper way to request a change in a situation like this? Malhonen 18:28, 9 November 2007 (UTC)


 * The discussion page is only protected from editing by anonymous/non-logged-in editors; so, you could have logged in and posted a message there. (To be honest, though, I'm not sure why even that protection is in place.) At any rate, I've fixed that typo now, thank you. :-) —Ruakh TALK 18:43, 9 November 2007 (UTC)


 * No, I was logged in. Maybe it's because I just registered my username here... Thanks for the fix! Malhonen 18:52, 9 November 2007 (UTC)

DynamicPageList
Does anyone know how to identify the version of this we have (it is a MW extension). It does not match the current version or documentation, which is incompatible. (so very hard to use ...) Or can we somehow get the current version? Or at least the doc for the version we have? Robert Ullmann 05:06, 10 November 2007 (UTC)


 * It looks like we have the version documented at mw:Extension:DynamicPageList/old. —Ruakh TALK 05:34, 10 November 2007 (UTC)

vs
The only difference I can see between these templates is that calls a whole load of subtemplates  to insert words with formatting. Which one should be used, and should we phase out the other? Conrad.Irwin 14:57, 10 November 2007 (UTC)


 * {see} expects its parameters to not be wikilinked, it links them; {xsee} expects the parameters to be linked, alt-linked, scripted, whatever, and uses them as given. Robert Ullmann 15:02, 10 November 2007 (UTC)


 * {see} simply includes the "serial and" CSS span(s) directly, while {xsee} puts that in a sub-template, it should probably just do it as see does. Robert Ullmann 15:11, 10 November 2007 (UTC)
 * I have updated - hope it works. Conrad.Irwin 16:49, 10 November 2007 (UTC)

Category:English nouns - Nov 2007
Template en-noun puts words in to Category:English nouns, or it can be done manually. But a lot of words don't use the template(s) and don't do this categorizing. Does anyone see a way to run a bot or offline processing to build a list of words that have English noun sections but don't categorize? (Or if the templates is the new standard, to determine which entries don't use the templates?) RJFJR 20:54, 10 November 2007 (UTC)


 * Generating a list is a fine idea. I'll see what I can do.  I know Rod A. Smith did a significant amount of work in this realm, in the past.  Automating them is a Bad Thing at this point, as most that aren't in the category are intended to be marked as "uncountable."  I'll have to download the categories thing (which I don't normally do) then split out entries that have ===Noun=== anywhere in their ==English== sections, then list them if they don't appear in the category.


 * I'm not certain the template is the new standard. I think that should/could be a follow-up list generated, if the former list ever reaches zero.  (Assuming the first list is easy to generate, that is...)  --Connel MacKenzie 21:07, 10 November 2007 (UTC)


 * I've gone through several de- and re-installations of Python, but with that toggle currently at "Python not installed", I'm not in a position to help at the moment. My cleanup approaches started from categories or deprecated templates, anyway, so I'm not sure how much help I'd be. Rod (A. Smith) 22:27, 10 November 2007 (UTC)


 * Quick question: precisely how would you correct the inflection on exuviae? --Connel MacKenzie 00:58, 11 November 2007 (UTC)


 * That's supposed to be a plural entry with the singular noun entry as exuvia:, right? If so,  seems right on the singular page, and  seems right on the plural page.  Rod (A. Smith) 01:39, 11 November 2007 (UTC)


 * I'm glad I asked. Using  does seem appropriate, but I wasn't making that assumption.  (I was guessing there was a mode in  that handled it, but no one ever did come up with a clever way of doing that - and  is far too complicated already.  Hrm.  So exuviae gets an explicit category ref, right?  --Connel MacKenzie 17:18, 11 November 2007 (UTC)
 * Remind me not to post without a cup-o-coffee. OK, so  sets the category based on the explicit parameter plural of.  Is that a sub-cat of Category:English nouns?  (Hrm, so what, if it is.  I wasn't thinking of checking sub-cats.  Prolly better to check just those two explicit categories, right?)  --Connel MacKenzie 17:22, 11 November 2007 (UTC)
 * Ouch, 14 sub-categories? And none of the sub-category members with dual-citizenship in Category:English nouns?  Ugh!  --Connel MacKenzie 17:25, 11 November 2007 (UTC)
 * Category:English plurals is a subcategory of Category:English nouns. What are the 14 sub-categories to which you refer?  Rod (A. Smith) 20:57, 11 November 2007 (UTC)
 * RFJFR's original question. --Connel MacKenzie 08:12, 14 November 2007 (UTC)


 * Some numbers, as the last XML dump


 * there are 616437 entries in the wikt, of these 99340 appear to be English nouns
 * of those, 43708 use template en-noun, 55632 not
 * of those with the template, 159 have a redundant English nouns cat
 * of those without the template, 606 have an explicit English nouns cat
 * of those without the template, 26926 contain 'plural of', 28706 do not
 * of the ones that do not, 3424 end with -s, 25282 do not


 * With the caveats: it did not check if the Noun section was inside the English section, did not check if the template or the string 'plural of' (including ) was inside the English noun section, and&mdash;of course&mdash;'ends with -s' is not a valid is-plural predicate, but is probably useful as a first approximation. Robert Ullmann 07:45, 11 November 2007 (UTC)


 * (updated the text above to add cats, better numbers) It would be fairly easy to go through and remove the redundant cat from those 159 entries, and add Category:English nouns that lack inflection template to the 606 that have the cat and not the template. That still leaves about 25K entries. There are also 15 entries that have an explicit English nouns cat, but no English noun section ... (I will investigate those, probably proper nouns or typos) Robert Ullmann 08:35, 11 November 2007 (UTC)

A few days ago, I proposed (with a link from the beer parlour) a few improvements to, including one change that would require updating any existing pages that used the template correctly (though N.B. a number of pages — I don't know how many — were previously using the template incorrectly, in a way that would be fixed by said change); one editor commented in favor, and one editor commented rather neutrally, suggesting this process would be obsoleted by a future change, but not (so far as I could tell) actually objecting. Not wishing to wait for said future change (especially since there will likely be an ugly argument between now and then), I waited a few days and then made the change, and set about updating those of the existing pages that had previously been using the template correctly (since these were now the pages using it incorrectly).

I then received an angry-sounding comment from an editor who had seen the previous discussions and participated in an aside, but who hadn't objected to the changes I'd proposed. After said angry comment, there was some back-and-forth, the upshot of which is that he feels I should revert the changes I've made so far, and apologize here to all bot owners for my supposed misrepresentation of bot-owner-kind.

I'm not about to issue a blanket apology — an apology requires feeling that one did something wrong, and right now it doesn't seem that I did — but if you're a bot owner (not counting the above-mentioned angry-sounding commenter) and feel hurt or offended by my supposed misrepresentation of our common ilk, it certainly wasn't my intent to cause you such feelings; let me know (whether here, or at my talk-page, or via e-mail) and I'll apologize to you personally.

—Ruakh <i >TALK</i > 00:13, 12 November 2007 (UTC)

P.S. I'm not going to revert existing changes, unless I get input from other people who think I should. Likewise, I plan to resume my automated-fixing run in a few days, unless there are any further objections. —Ruakh <i >TALK</i > 00:13, 12 November 2007 (UTC)


 * Assuming you really see things the way you say you do (which frankly, is beyond incredulous,) I object to you characterizing my comments as "angry." They were not.  They could be misinterpreted as such, but only if you neglect WT:AGF.
 * Your perverse misrepresentation of the feedback you got on WT:BP is inexplicable.
 * --Connel MacKenzie 00:32, 12 November 2007 (UTC)


 * Thanks for your reply. I've fixed my comment accordingly. —Ruakh <i >TALK</i > 00:48, 12 November 2007 (UTC)


 * Incidentally, inferring anger does not violate AGF; if someone acts angrily, it's AGF-ing to assume that they're genuinely angry, and not, say, trolling. I'm starting to see why you opposed AGF: you didn't (and don't) understand it. —Ruakh <i >TALK</i > 01:20, 12 November 2007 (UTC)
 * For God's sake Ruakh, what has gotten you so upset? ;-) <i style="background:lightgreen">bd2412</i> T 01:49, 12 November 2007 (UTC)


 * I assume you've seen some of the follow-up WT:BP conversation by now. (See?  It isn't just me.)  Running bot-changes has always come under much greater scrutiny than regular edit (usually, to my chagrin.)  It took years to build up enough community trust to get bots functioning with moderate community support.  When you blithely run a change that you want, despite objections, you erode that trust very quickly.  No, running changes that don't have solid agreement is not OK, especially when the conversation surrounding such changes is just barely started (and already receiving lots of negative feedback.)  When you arrive on the scene and erode trust that has taken me (and others - well, only me that first year,) years to build up, yes, I expect an apology.
 * At WT:BOTS, it is very clear that responsible bot owners will be ready to roll back their changes. You have yet to correct the error you had Rukhabot propagating.  You need to roll those back.  To quote WT:BOTS: "We expect that a bot owner will run a bot carefully so that it does not run amok.  We expect that a bot owner will clean up after the bot if it does run amok or if it has made edits which the community decides in retrospect were unwarranted.  Most importantly, we expect that a bot owner will use a bot to perform only those edits which there certainly is or would be good consensus for."  That fact that you haven't applied for official bot status for Rukhabot is no exemption.
 * Since it is all inter-related, your notion that individual templates only brings back the problem of having the list of templates be open-ended. Having only  (singular or plural) inherently prevents external links to "Martha's transmission service and bakery" type web links.  At the same time, "new" sister projects like Wikiversity can be added easily.  Finagling the templates to do things like moving the required formatting outside the template (which is exactly what Rukhabot was doing when it was blocked) in support of an alternate solution is just inexplicable.  Converting time-tested templates to some other format, just because you think it should be that way, isn't helpful.  Having the bullets in the template prevents the templates from being misused elsewhere - not a prolific error, to be sure - but not a hypothetic newcomer error, either.   has incorrectly shown up in =see also=, POS, =usage notes=, section 0, =etymology= and other sections.  The more the error stands out, the sooner it is fixed.
 * --Connel MacKenzie 21:56, 12 November 2007 (UTC)


 * Sigh. Connel, the code for the various sister projects has to be in separate templates so they can be selectively invoked. Else you get the kind of expansion I showed on the BP.
 * The individual templates I moved the code to will not be used directly on a page. (Try putting in an entry.)
 * Using in no possible way can prevent someone from creating Template:MarthaTransBakery.
 * Having the "*" inside the template(s) cannot magically prevent someone from putting it/them in the "wrong" section.
 * You have consistently argued that "#" for definitions must be in the wikitext for application parsing, the same is true here.
 * What Ruakh was doing is right; although converting "pedialite" to "projectlink" would be better.
 * Robert Ullmann 10:09, 16 November 2007 (UTC)


 * Should also be observed that there was not "lots of negative feedback". The only tangential objection was DmcDevit saying it was pointless to improve pedialite when projectlinks should be used. No one but Connel has objected to having the "*" wikiformat consistently outside the templates, and he did not raise that objection in the BP, saying only that he wanted things consolidated into projectlinks; he did say that he didn't want it split up so that people can't do non-standard things "like numbering eternal links". (Which no-one will do anyway, AF will automatically convert "#" to "*". So what?) The BP discussion is there for all to see. There was no opposition whatsoever to what Ruakhbot was doing. Robert Ullmann 10:25, 16 November 2007 (UTC)

projectlinks update

 * Moved from WT:BP DAVilla 05:41, 17 November 2007 (UTC)

I think some changes to are in order, and have listed them at its talk-page. If you have any objections, personal attacks, or requests for other changes to be made at the same time, please make them there; otherwise I'll make the changes in a few days. —Ruakh <i >TALK</i > 04:42, 9 November 2007 (UTC)


 * already does the same thing as pedialite, but with more options, including some of the things you are looking for too. pedialite should eventually be deprecated in favor of projectlinks, in my opinion. Dmcdevit·t 06:44, 9 November 2007 (UTC)


 * Thanks for the info. :-)  Unless you're suggesting deprecating it within the next few days, though, I'd still like  to be all that it can be, so to speak. (And to be honest, while I don't feel nearly so strongly as Robert seems to, I must admit that I'm not a huge fan of, either; I think something like a hypothetical  would actually be easier to use, and would allow for more flexibility in a lot of regards. I mean, in theory  should be almost as flexible as any  — worst case, you could use one  for each link, and the only feature you'd lose is the ability to have other text on the line — but in practice, something like that strongly encourages all the sister-project links to be grouped together with nothing between them, even if there might be a good reason to put something between them, such as a   header or something.) —Ruakh <i >TALK</i > 07:56, 9 November 2007 (UTC)


 * I don't know, it looked like several of your ideas except the second require going through the articles and updating the template. That's why I thought it would be counterproductive to do that if a deprecation were to occur anyway. (I'm not quite sure the distinction you are making between and ; as you say, it works just fine with only one line, and so you can use it multiple times to make what you're suggesting.) Dmcdevit·t 08:02, 9 November 2007 (UTC)


 * Well, I just don't see the benefit of having a multiline template at all; there are some minor down-sides to using it for just one line: (1) you still have all the parameters being named, (2) it's designed to make it seem like there should only be one per entry; you can't incorporate it into an existing list (for example, there are cases where it might make sense to have the 'pedia-link under a definition — cases where 'pedia has an article about the actual word, you know — and  simply can't do that). There's no one big reason not to have a multiline template, but there are a bunch of little reasons, and I don't see what the reason to have one is. I see what you're saying about counterproductiveness, but it doesn't look like this template is going to be deprecated any time soon, or if it is going to be, it's not at all obvious yet what it'll be deprecated in favor of, so I think we might as well fix it up now. —Ruakh <i >TALK</i > 17:25, 9 November 2007 (UTC)


 * I think you may be misunderstanding my point. What I'm saying is that the current is identical to the hypothetical  but just with more options. The primary reason for  is not because it is multiline, but because it is a single template that can be used for any (and all) the sister projects. The issue with the parameter names is one that's easily fixed, not a downside to the whole idea. As for your second point that it can't be incorporated into a single list, I'm not sure I understand that. It sounds like you might simply be asking for the asterisk to be moved outside of the template so it can go at any level in the list, which is also an easy fix.  isn't anything novel, it's just all the "lite" templates together and able to be called with a single template, plus a couple other optional things. Dmcdevit·t 20:03, 9 November 2007 (UTC)


 * Re: "The primary reason for is not because it is multiline, but because it is a single template that can be used for any (and all) the sister projects.": Yes, agreed. That's why I find it annoying that it's multiline; it doesn't need to be, and in fact doesn't seem to derive any benefits from being multiline, only downsides. Re: "What I'm saying is that the current  is identical to the hypothetical  but just with more options.": I don't follow. Could you give an example of an option that  supports but that a hypothetical  could not? —Ruakh <i >TALK</i > 20:43, 9 November 2007 (UTC)


 * (by far the most common use it will see) is one line. It can be more lines for other projects only if you want it to be. That's the only difference I thought you seem to be suggesting between a and, so I don't see what downsides you are talking about. Dmcdevit·t 21:42, 9 November 2007 (UTC)


 * The * list format should be in the page text, not in the template. We should have separate templates for each project, a common one just ends up with a switch, and the only way to make that acceptable is to call "helper" templates anyway, so it is just another layer. I'd suggest using, , , , , , , (note that {pedia} should be orphaned in its present form, {quote} is RfD as it should be, {commons} can be converted to this), with each designed to follow the "*" on the line, and permit other text to follow. That loses the "lite" bit, which is, um, illiterate. Then we can migrate {pedialite} to * {pedia} and so forth. The UI is simple (doesn't require looking at the doc), they can be ordered as desired, not hard to add another one in between (painful with {projectlinks} ;-), and the performance is fine. You could start by changing the existing uses of {pedia} to {wikipedia} and implementing {pedia} with all of your suggestions. Robert Ullmann 08:29, 9 November 2007 (UTC)


 * Consider what you are trying to accomplish, first. Currently, we have more than five incompatible ways of "linking" a Wikipedia article from a Wiktionary entry.  I think  is a comprehensive way of unifying and incorporating precisely the features we've agreed to allow, in exactly the place they belong (in an ===External links=== section.)    While it does have "performance" concerns, it has considerable advantages.  Unifying all the strange formats we have that have been popular in their day, into the one format we do want, is desirable.  I don't think it is worth-while to try splitting  up, just so that the format can be de-standardized, presumably to do other erroneous/undesirable things, like numbering external links.  Yes,  should be deprecated along with .  But I do not agree with your premise, that individualized  lines would be a benefit - that would be a return to a free-for-all external links format, which is exactly what  was created to prevent.  --Connel MacKenzie 17:15, 10 November 2007 (UTC)

I don't care who writes it, and I don't care what it or they are called, but for inline project links I'd like to be able to do this:

<tt> </tt> <tt> </tt> <tt> </tt> <tt> </tt>

or this:

<tt> </tt> <tt> </tt> <tt> </tt> <tt> </tt>

instead of:

<tt> </tt>

DAVilla 00:37, 12 November 2007 (UTC) (Edited DAVilla 04:48, 12 November 2007 (UTC))


 * Word. Personally, I prefer the second version, as I think it would help ensure better consistency/parallelism, but I do understand the arguments for the first and have no objection to it. (Though really, my preference would be for the asterisks to go outside the template call, as that way strikes me as clearer and cleaner. *shrug*) I don't understand, in the most literal sense, the arguments for the third; it seriously looks to me like the whole argument is roughly, “the downsides aren't too bad”, but from the comments above I'm sure there must be benefits that I just haven't picked up on. —Ruakh <i >TALK</i > 01:01, 12 November 2007 (UTC)


 * I'm am completely befuddled. The second set of examples is exactly what "projectlinks" does right now, as long as you use it more than once. This is what I have been saying. Your interpretation of the current template (with page1= ) is wrong; if it's linking to the page name, you don't need that parameter. "projectlinks" is this hypothetical projectlink, the only difference is that it can also be used in the way you showed in the third set (but that is by no means "instead of," they are the same template). I've been trying to communicate this point above already. Your portrayal of the single-template method is also a bit slanted (putting multiple parameters on the same makes it look less clear, only because you could have also written it more clearly.) Dmcdevit·t 01:28, 12 November 2007 (UTC)


 * Re: "The second set of examples is exactly what "projectlinks" does right now, as long as you use it more than once.": But that's obviously not how you're intending it to be used, so that won't usually be how it's used. To take your example, at United States: yes, that's very simple. But suppose I need to modify one of those; I'll have to count out the lines, and add the correctly-numbered parameters. If someone else later wants to insert a link above the one I've modified, they'll have to edit all the parameters I added — even though what they're doing bears no connection to what I did. Is this a huge deal? No. But it's a downside, not a benefit. If you could outline just one benefit, that would significantly change my attitude toward it. —Ruakh <i >TALK</i > 01:56, 12 November 2007 (UTC)


 * So don't use it that way; it already does what you want, with the additional option to do it all in one template use. It will be used however the people who use it use it. Also, I don't know what you mean by "If someone else later wants to insert a link above the one I've modified, they'll have to edit all the parameters I added"&mdsash;all you have to do is add the parameter "page2 = foo" or whatever. Clearly you aren't asking for "just one" benefit, as they have been mentioned before. It's a single consistent format and emphasizes uniformity. It already does everything you are asking for; the difference appears to be that you want even the option of putting more than one link in the same template call edited out. I don't see why you think that is worth arguing over. Dmcdevit·t 04:29, 12 November 2007 (UTC)


 * I just don't see how this is any more consistent or emphasizes uniformity any better than a one-link-per-template approach. *shrug* I guess we'll just have to agree to disagree. (Which is to say, you're right: it's not worth arguing over.) —Ruakh <i >TALK</i > 05:19, 12 November 2007 (UTC)


 * Dmcdevit: if entry uses {projectlinks] for (say) 5 links, with page4= and page5= used, and I want to add a new one after the first, I would have to carefully renumber, changing page4 to page5 and page5 to page6.


 * Any reasonable implementation of a one-line {projectlink} would have to call a subtemplate named by the first parameter, so it becomes just an extra layer of overhead. If the style is preferred, that's fine, but we must have a template per-project anyway, so it seems reasonable (and clearer) to just use them. Robert Ullmann 06:23, 12 November 2007 (UTC)


 * Out of the 40,000 uses of alone, the amount of articles with six sister project links is infinitesimally small. I just don't think that is a significant issue here, and, since the issue is only the changing of some parameter names in the even more unlikely cases that one of these articles with multiple links needs another one added, it's not a huge deal. Dmcdevit·t 09:08, 12 November 2007 (UTC)


 * Oh, sorry. I guess I just couldn't make heads or tails of the documentation. I did look and try to figure it out. My comment above is now modified. DAVilla 04:48, 12 November 2007 (UTC)


 * I've a question about the wording you used, DAVilla...you said "inline". You do mean for non-boxy single line ===External links=== section listings, right?  An inline link to Wikipedia for each of the sister projects (and other language projects) is already native MediaWiki syntax.  --Connel MacKenzie 16:34, 12 November 2007 (UTC)


 * Yeah, the first is what I meant. I was talking strictly about the non-boxy things and how the template wikitext should look to an editor. Boxes, which are even more controversial, I only support in certain circumstances, but hey, one issue at a time. DAVilla 03:19, 13 November 2007 (UTC)

For anyone who doesn't think performance is an issue, consider this. The call

  generates this:

Wikipedia has an article on “ w: ”. Wikipedia

while   generates this: (don't worry the text isn't on this page, but do make sure you scroll all the way right! ;-)

See? If it accomplished something, maybe. But as it is just an utter waste of resources? Robert Ullmann 07:59, 13 November 2007 (UTC)


 * You didn't really have to make your point by dumping the text here. I halved that easily just now by removing most of those repetitions; a maximum number of links of 5 is plenty. If you are really concerned about performance, there are other efficiency issues we can improve, like removing the #switch from , and instead use a separate template for each project so instead of  , we'll have  . And removing the ... , make the project names case-sensitive. Even as it is now, it's not going to break the servers. I think performance is a non-issue, and a distraction. w:Wikipedia:Don't worry about performance. Dmcdevit·t 09:12, 13 November 2007 (UTC)


 * (I was on #wikimedia-tech when you were making your comments about me, eh? And as Tim pointed out, it is bad. Maybe 50% as bad as it was? so?) Robert Ullmann 14:27, 13 November 2007 (UTC)


 * Another point: writing <tt> {{#switch:{{lc:{{{project}}}|pedia|wikipedia=...|species|wikispecies=... </tt> to try to be "helpful" by allowing all sorts of forms is counter-productive: it allows (pedia, Pedia, wikipedia, Wikipedia, WikiPedia, WIKIPEDIA, wikipedIA ...) which then makes the wikitext much less consistent, much less tractable to parsing, and makes things that much harder to change. Multiple ways of naming the same option is not helpful. Robert Ullmann 10:49, 14 November 2007 (UTC)


 * From w:Wikipedia:Don't worry about performance: "Citing this page in response to a sysadmin noting poor performance on some level or forbidding some behavior (as has been done with past incarnations) completely misses the point: performance is an issue, just not one that will typically come up for users, and not one that anyone not involved with Wikimedia server administration on a continual basis (you know who you are) is fully qualified to speculate about." [emphasis mine]. This was a problem that did need to be fixed. Robert Ullmann 09:43, 17 November 2007 (UTC)

Pfui. I realized around lunchtime that it was going to take a lot less time to fix this than to discuss it.


 * DAVilla: the (pedia, source, books, quotes, news, versity, species, commons) lite templates work as you suggest above. We can change the names to something other than xxxlite if desired.
 * Template works as you suggest above.
 * Template works as before (I added 3 back in, so it will do 8), and is 8 lines with zero parser functions. It generates only one extra null template call beyond what is needed to render the text.
 * Connel: Each sister project link is generated by exactly one template (of these) so there isn't a problem keeping different calls consistent. This can be improved further if required. (Like generating the text for the boxes with the same code ;-)
 * {projectlinks/link} which produces most of the cruft above is entirely orphaned now.
 * The "*" format character is in the wikitext, except when using {projectlinks}.
 * The HTML unordered list structure is unbroken, even if you use {projectlinks} (!).
 * The sc= parameter provides a script template instead of the default bold, in all forms of all the calls.

Sigh. Robert Ullmann 14:27, 13 November 2007 (UTC)

More details: I hadn't added in the displayed page/article name in the link on the LHS (in Monobook), which is something {projectlinks} did. Done now, although a little bit simpler. It displays the label {2} or {1} if it is not the same as the pagename (case independent match). Also you don't have to specify {1}, so at eBay, one can use  {{pedialite||eBay}} '.

I'd like to see these named PL:something rather than xxxlite; the "lite" bit is not very literate (-) and unless one understands it vis-a-vis the RHS float boxes, it doesn't make much sense. "PL:" for Project Link parallels R: for Reference. I'm going to do some moves and create a few redirects to set this up, and you can look. Also PL:pedia can be a redirect to PL:wikipedia (or the reverse), then one can use pedia or wikipedia in {projectlink} and {projectlinks}.

I haven't yet done anything with "disambig" or "cat". (Which ought to be something like PL:wikipediadab and PL:wikipediacat ...) Or "meta". Robert Ullmann 08:27, 14 November 2007 (UTC)

Okay. It is using PL:... templates which are "internal", shouldn't really be in the page wikitext. (And they won't be! Did you know that the RQ: templates only work because there is no RQ language code? ;-) Use like so:

* {{projectlink}} &#32; &#32;
 * {{projectlink|quote}}
 * {{projectlink|pedia||eBay}}
 * {{projectlinks}}
 * {{projectlinks|pedia|quote|page2=Beer Places}}
 * {{sourcelite}}
 * {{sourcelite}}


 * {{projectlink}}
 * {{projectlink|quote}}
 * {{projectlink|pedia||eBay}}
 * (each uses {2} as title if not {PAGENAME}, {3} as label if not {2} or {PAGENAME})


 * {{projectlinks}}
 * {{projectlinks|pedia|quote|page2=Beer Places}}
 * (etc, as documented there)


 * {{pedialite}}
 * {{projectlink}}
 * (each uses {1} as title if not {PAGENAME}, {2} as label if not {1} or {PAGENAME})

So the xxxlite templates work as before (they redirect to the correct PL: form), {projectlink} does one without requiring named parameters, {projectlinks} works, and isn't horrid even in the degenerate case. Note you should use "*" before {projectlinks} and it does work. The actual code to generate each link is in one place for each project. (And variants like "dab" and "cat", which I haven't set up quite yet.)

All forms take lang= (or langn= for {projectlinks}), all take sc= for the display script. Robert Ullmann 10:49, 14 November 2007 (UTC)


 * Oh, and note that which is used in a few pages, is also redirected to Template:PL:pedia; we could parallel this with, , , etc although these are very generic,  might be a context template, but {{temp|taxonomy}} is better (-) , ,  which is a float box now. Robert Ullmann 11:03, 14 November 2007 (UTC)


 * added cat/category, dab/disambig/disambiguation, meta/metawiki (not that the last was used anywhere, it certainly wasn't tested)


 * {{projectlinks|cat|dab|meta}}
 * completes my checklist. Robert Ullmann 13:27, 14 November 2007 (UTC)

Uh, it makes sense to move Template:PL:pedia back to Template:pedia and likewise with the handful of others. There would still be glue redirecting from all the <tt>PL:</tt> templates.

How are we to distinguish between Wikipedia disambiguation pages that are marked with " (disambiguation)" from those that aren't? My suggestion was a relic of a design where such distinction wasn't necessary. Maybe <tt> (disambiguation) </tt> would still have to be passed in the first case. How unfortunate! DAVilla 06:07, 17 November 2007 (UTC)


 * I don't see why it would make sense to move {PL:pedia} "back" to {pedia} (which it never was), when we apparently want to move toward {projectlink}/{projectlinks}?


 * the "dab" key links to an explicit "(disambiguation)" page, without passing that to the template as a parameter. The fact that wikipedia is inconsistant about whether pages are named with "(dismabiguation)" shouldn't really be our problem. If a dab page isn't named that way, just use the "pedia" key, we don't have to say it is a dab page. (I'd like to see our text for a dab page just say "articles on" but I was (at least initially) just copying what was already there. "disambiguation page" is WP jargon.) (oh, and thanks for moving this) Robert Ullmann 09:15, 17 November 2007 (UTC)


 * Are we want to allow a mixture of two systems or are {{temp|pedia}} et al. going to be deprecated?
 * I don't think of a disambiguation page as an encyclopedia article. They more closely represent dictionary entries. Even apart from proper nouns, sometimes the disambig pages have more definitions than we have here. And occasionally those are even correct. DAVilla 07:09, 18 November 2007 (UTC)


 * Just to add my input to this long debate, I think that the whole reason for templates is to provide a quick way of inserting useful information. Thus I am very much in favour of having {pedia} or {wikipedia} (perhaps one could be a box and the other inline), which are much more intuitive than {projectlinks|pedia} or {PL:pedia} which you can only come to know if you have been here for a while. Conrad.Irwin 23:08, 23 November 2007 (UTC)

Tbot entries 2
Tbot creates new entries from the translations tables it is updating.


 * Note that the concept of "translation" as commonly understood is rarely correct. The naïve question "What is the word in X for Y?" is unanswerable in the general case, languages don't work that way. English speak, talk, chat, gossip "translate" to Swahili kunena, kusema, ongea, but not one-to-one. Almost all combinations of those are possible. (All but gossip to kunena which would never be correct). Then there is announce, proclaim, declaim; and further enunciate and so on.

Even technical terms that one would think are 1-to-1 are often not. (English high voltage, French haute tension, but English high tension)

What we call "Translations" is, and can only be, "words that correspond in some way in the other language."

That said, it is usually useful to create an entry for the FL word, "defining" it as the English word, with the translations gloss. Most of the results are useful, if not entirely correct. Some are amusing, see the original version of אסלה; apparently throne appears in the database before toilet. Even so, the entry as Tbot created it does give you the definition you wanted. (Along with the humour.)

Languages
The languages that Tbot will create entries for are controlled by the existence of the language category, for example Category:Tbot entries (French). Tbot only creates entries until the category is "full", and then will not until someone checks one or more entries and removes the tag.

The limit for each category is set by the limit= parameter in the boilerplate text template for these cats,. The limit may be set to zero (one doesn't want to delete the cat if there are entries).

Some languages may have more reliable translations than others; it may be necessary to set limit=0 for a very unreliable language. The initial set of languages I picked was based mostly on what I think active editors are interested in (including Swahili and Kinyarwanda, with limit=1000 because I want to go through all of them). Some dozen people have already looked at a few.

Scripts
Tbot recognizes words in various scripts, and adds them to {t} and {infl} when creating an entry. The scripts it knows now are Greek, Cyrllic, Armenian, Hebrew, Syriac, Arabic, Devanagari, Bengali, Georgian, and all the CJKV scripts and variants (including Han Extension B on plane 2). For Arabic, it uses fa-Arab, ur-Arab, and pa-Arab as appropriate, also Hayeren for Armenian, and polytonic for Ancient Greek.

Issues, current status
(a number of the restrictions are temporary, as a starting point)


 * Tbot only updates entries that already have {t} templates, or have section references or explicit FL.wikt references that would be good to fix.
 * It only converts a line to use {t} if the (local) word exists, or if it can create it.
 * It doesn't add the template or create an entry if the language is not in the set of 170 that have wikts.
 * It doesn't add language sections to existing entries; this makes it easier to remove bad entries.
 * It only recognizes transliterations for Cyrillic, Arabic, a few in Hebrew etc. It doesn't do this yet for things like Kanji and Hanzi (although it does for kana). If it can't recognize the transliteration, it won't modify the line because it can't know whether the text in parenthesis is the transliteration or a qualifier.

Also see User:Tbot/tbot entry.

Comments
This is experimental, there is just about enough there for people to look at. (And do please look before just thinking, "oh, that can't work", most of the entries are helpful). It is very important that these entries are tagged and checked; generating un-tagged entries would be a problem.

I think it is helpful to make it easier for users (old to newbie) to check and edit entries. (A new user I'd never seen before did some of the Esperanto entries.) Do feel free to add language cats or change the limits. Robert Ullmann 09:34, 16 November 2007 (UTC)


 * Hungarian should be set at a low number, if not zero. Most of the Hungarian translations were given by Drago (aka, You-Know-Who) who does not speak Hungarian. --EncycloPetey 18:39, 19 November 2007 (UTC)

Coders, your next project has arrived!
Coders, your next project has finally been decided. You are to program it so that when someone posts a question or observation in a discussion page, the page gets listed at a special "Discussion pages awaiting reply" category until they are replied to.

Your reward will be 50 cool points and I'll introduce you to a hot girl of your choice.

Language Lover 08:46, 19 November 2007 (UTC)


 * I don't think categories would be the right way to approach that. (WT:BP/WT:TR/WT:ID would just have permanent markers?)  I've never found a particularly good way of accomplishing that task - Request pages/Recent changes was one attempt, trying to use "Related changes".  In practice, the sheer volume is overwhelming, so I've given up trying to maintain that list (a long, long time ago.)  (Check out the other subpages around there, too...some of it half worked - other stuff didn't work at all, without the full extensions being installed - which Brion said he will never do.)
 * Meta: has that "mark pages as visited" thing, that might be helpful on a per-user basis. --Connel MacKenzie 20:25, 30 November 2007 (UTC)


 * Connel obviously already has a hot girl. I on the other hand have been toiling on this night and day. Okay, I'm kidding. But what are the "full extensions" that would need to be written? 70.112.121.70 07:43, 1 December 2007 (UTC)


 * Sorry for that ambiguity - I meant the other version of DynamicPageList. There were a couple versions floating around, but the one that did what I wanted it to, had too great a performance penalty, IIRC.  Maybe approaching the problem from a different direction (i.e. a recentChanges bot) might help.  --Connel MacKenzie 05:16, 3 December 2007 (UTC)

Template:fr-noun
Can someone add an extra parameter in Template:fr-noun, so that nouns with numerous parts to them can link to their components, e.g. at belle-de-jour, which would be like {fr-noun|f|singular=belle-du-jour|plural=belles-du-jour} I would, but is preotected. Thanks --Rural Legend 13:59, 19 November 2007 (UTC)


 * That template already supports that functionality, using its  parameter; I've edited belle-de-jour so you can see how that works. (Really, though, that template is a bit of a mess. Circeus asked me a while back to add support for noun-count nouns/singularia tantum, and I just couldn't find a decent way without breaking existing functionality. We might have to take a multi-step approach, involving both edits to the template and a run of bot-assisted edits to all pages currently using it.) —Ruakh <i >TALK</i > 20:07, 20 November 2007 (UTC)

Spam websites in edit summaries
I noticed a lot lately anons putting spam websites into edit summaries. See az, Playboy, anarchia for example. Is that a problem? Is there any way to erase edit summaries when rolling back edits? sewnmouthsecret 19:36, 19 November 2007 (UTC)


 * Well, technically you can delete the entry and restore the last pre-spam version; but I don't know if it's worthwhile. I don't think anyone's going to accidentally copy-and-paste those URIs and visit the pages, and I'm fairly sure non-linkified URIs don't affect search engine results. (If you want to put in the effort to do it, though, I certainly won't object, as long as we're not losing newer, positive contributions as a result.) —Ruakh <i >TALK</i > 20:11, 20 November 2007 (UTC)


 * It's simpler just to put a month block on spamming anon IPs. --EncycloPetey 20:32, 20 November 2007 (UTC)


 * I did block them; I was just concerned about search engines picking up the spam links, which isn't affected. sewnmouthsecret 20:34, 20 November 2007 (UTC)


 * I don't see any way that a search engine spider would pick up edit summaries (even the current one). If they had, I'm sure the Google techs would have prevented it for wikis by now ... seems like useless spamming. (blanking the page is particularly silly, as it just ensures a revert; I think they are just blindly posting) Robert Ullmann 10:10, 21 November 2007 (UTC)

template:he-adjective
Fyi: I've created, copied nearly wholesale from. Knowing my template-coding skills, it probably needs a bit of help. I've used it on two pages — קל and קלה — so far.&mdash;msh210 &#x2120; 19:38, 19 November 2007 (UTC)
 * Same for he-plural-noun.&mdash;msh210 &#x2120; 16:02, 20 November 2007 (UTC)

Salishan
I was planning on putting in a few Salishan words I found, but several of them use superscripts for some of the letters (usšnéʈxw). Is it possible to have superscripts in the article title? What should I use as the title if it isn't possible? Nadando 23:42, 19 November 2007 (UTC)


 * Normalize to the closest page name that MediaWiki accepts, e.g. usšnéʈxw:, then, in the headword line, show the proper orthography. Rod (A. Smith) 00:15, 20 November 2007 (UTC)


 * This is an IPA transcription (the language not being written), so the superscript w is an IPA character U+02B7: &#x02B7; and you should use it in the page title. This entry should be usšnéʈxʷ Robert Ullmann 10:48, 20 November 2007 (UTC)


 * Salishan is not a single language, but is a group of 23 languages, so you'll have to determine which of the Salishan languages is appropriate in your entry for the language header. --EncycloPetey 13:33, 20 November 2007 (UTC)

The size of Greek text
The appearance of Greek characters using the templates and  is smaller than the surrounding text, viz: παρευρίσκομαι. Is it possible to enlarge this? (The use of seems to achieve a more even appearance, viz: παρευρίσκομαι .) Is this small size an artifact of my system? If not would it be possible for someone to modify the appropriate templates? The use of in other templates, such as  might make this unstraightforward? —SaltmarshTalk 14:43, 22 November 2007 (UTC)


 * It's possible, yes; does this, for example. By how much should it be enlarged? Here are some samples:
 * current size: παρευρίσκομαι παρευρίσκομαι
 * 5% bigger: παρευρίσκομαι παρευρίσκομαι
 * 10% bigger: παρευρίσκομαι παρευρίσκομαι
 * 15% bigger: παρευρίσκομαι παρευρίσκομαι
 * 20% bigger: παρευρίσκομαι παρευρίσκομαι &larr; same as, generally
 * (As you might have noticed, not all of those necessarily look different on all computers.)
 * —Ruakh <i >TALK</i > 07:33, 23 November 2007 (UTC)


 * 15% seems about right (on my screen). So can I "just" add the  font-size: 1.15em  property to (as in )? —SaltmarshTalk 12:22, 23 November 2007 (UTC)


 * Yups. :-)  —Ruakh <i >TALK</i > 18:42, 23 November 2007 (UTC)


 * Sorry to be awkward, but normal is right for me&hellip; (I am using Linux+Firefox) Also, shouldn't we take the "style" property out of these templates and just use the CSS, as the templates are generally protected due to use on the main page this doesn't really affect the openness and it allows people to override the values in their own monobook.css if they wish. Conrad.Irwin 22:39, 23 November 2007 (UTC)


 * Same here, the z in "viz" and the pi in "pareuriskomai" are both 6 pixels tall. I think it's a font issue -- Linux fonts are usually completely different. Also, the 10-15-20% are the same size for me. I don't really mind the enlargement since it's only 1-2 pixels. Cynewulf 23:21, 23 November 2007 (UTC)


 * The current size and 5% look the same and are not unreadable for me. 10% also looks reasonable. 15% and 20% are large in comparison to the regular text. I do like large, but I would rather everything be as large, not disproportionately so. DAVilla 18:29, 24 November 2007 (UTC)


 * On my system with Windows XP and Firefox the normal size looks right for the Greek and all the others actually look bold. Also the Hebrew without the script template is the right size whereas the Hebrew with the script template is too big. It was me who made the original script templates for Arabic and Thai based on an IPA script template I found on Wikipedia if I recall correctly. At the time I could only think of a way to do it which required the font name in one template and the font size increase in another. But I wonder if there's a way now with parser functions to tie them together in a better way. &mdash; Hippietrail 09:01, 25 November 2007 (UTC)


 * Note that on that platform (XP/Firefox) if you uncheck "allow pages to specify fonts" (or something like that), then it uses all your own selections, and the defaults are the same size. (I.e. the Greek looks exactly right with the Latin script.) It is the WM/Monobook font and font size for running text that is specified "bigger", which is what we see as a problem. It is good to have the default look good for readers (of course!), but don't forget (if you are using Firefox) that you can turn all of the server-specified font selection off and choose whatever you want.


 * It may be that what we should do is match the point size of Greek etc to the Monobook Latin font point size? (I think it isn't because that size is specified only for the Latin font? Something like that ;-) Robert Ullmann 09:27, 25 November 2007 (UTC)


 * Some of the preceding comments are above my head. My Monobook.CSS is empty and I guess that this will be the case for the average user. (1) I tried editing  without any noticeable effect - I'm not confient about trying anything else. (2) on my screen (in WinVista) Firefox and Explorer show the same difference in font size. —SaltmarshTalk 10:19, 25 November 2007 (UTC)

For those who liked the normal sized Greek text (before this) adding .EL {font-size: 1em !important}; to your <tt>monobook.css</tt> seems to work nicely. Conrad.Irwin 02:14, 4 December 2007 (UTC)


 * Straw poll: See the Greek text link to the Greek Wiktionary at the bottom of the Main Page? How many of you see it in a font size significantly larger than all the others? --EncycloPetey 02:21, 4 December 2007 (UTC)


 * Well me obviously :) Conrad.Irwin 10:48, 6 December 2007 (UTC)

Server Side maintainence scripts
Sorry for the newbie question, but I have seen these referred to in WT:RFDO, and I was wondering what they actually do? It seems very unusual to slow down humans because a computer has to do something. Conrad.Irwin 00:21, 25 November 2007 (UTC)


 * The note at the top of the page was added in June 2006 by Connel MacKenzie. There is also an exchange later in the page history between Vildricianus and Connel about the fact that this particular job is now done by the job queue. I'm not sure if there are other server-side tasks that are relevant to deletions, but the one they're talking about has to do with updating pages that use a template to make sure that their  list is correct.


 * I agree with you that it's weird to slow down humans to wait for a computer, but in this case the idea was to allow Special:Whatlinkshere to update so that the humans would be basing their decision on accurate information. Mike Dillon 00:38, 25 November 2007 (UTC)


 * Ok. I was under the impression that the job queue did all name spaces, and there is certainly nothing in the documentation about it being limited to ns:0, I tried asking on wikimedia-tech but they ignored me :( . Conrad.Irwin 19:09, 25 November 2007 (UTC)


 * AFAIK it does do all the namespaces; it would be much more difficult not to. (what would finish updating the link table?) The point is that the "wait a week" note was written before this was done by the job queue; it was done by a twice-weekly script. Now, all one needs to do is wait for the queue shown in Special:Statistics to go to zero (or be clear that it is doing something else, it is usually a small non-zero number). Then you know what-links-here is giving a complete result and you can go ahead and delete without breaking a desired link. We might fix the note ... Robert Ullmann 14:49, 26 November 2007 (UTC)


 * Well I will comment it out, so that if this is a mistake in can be put back without reverting. Conrad.Irwin 00:05, 27 November 2007 (UTC)


 * It may still be good to wait a week so that everyone can see the template, or category especially, marked as deprecated. DAVilla 08:09, 28 November 2007 (UTC)


 * I agree with Mike Dillon, that the other maintenance tasks (I'm not going to hunt them all down now, but certainly the specialpages that deal with categories, double-redirects, etc.) do still run only twice-weekly. So this I think should be undone.  The main point is that NS:0 is handled in a straight-forward manner, but all other namespaces have side issues that a one-week delay will compensate for.  It isn't like the backlog is in any danger of reaching one week anyhow.  Trying to spell out the numerous differences in caution-delays for templates vs. categories vs. custom namespaces seems silly...but having a blanket one-week caution covers them all, nicely.  If that can be reworded more succinctly or more clearly, then so be it - but removing the notice seems unwarranted.  --Connel MacKenzie 20:03, 30 November 2007 (UTC)


 * Also, that edit messed up the Lupin-popups preview (see WT:PREFS to turn it on, then hover mouse over WT:RFDO.) It also places the shortcut wrong for smaller (800x600) screen displays.  --Connel MacKenzie 20:06, 30 November 2007 (UTC)


 * P.S. I also agree with DAVilla, that a human-factor one-week delay is advisable, just because. --Connel MacKenzie 20:08, 30 November 2007 (UTC)


 * (On a technical note - to my eyes anyway - the edit made WT:RFDO look the same as WT:RFV in popups, ditto with the 800x600 display) The wording would need to be changed if we were going to put the note back, there is easy way of telling for how long a template has been orphaned. I don't think that the sysops need reminding to wait on contentious issues, they are supposed to be trusted; and forcing them to wait for uncontentious issues just clutters up that vast page even more. On a related issue, how is the page supposed to be archived? Conrad.Irwin 02:05, 4 December 2007 (UTC)

Iwiki factoid
Our iwiki bot has finished its run based on the last XML; it took a week, added iwikis to 21,877 entries. There are now 2.82 million unique titles in the union index of all 170 wikts. (172 -tokipona, -klingon) We have 659K (in the same terms of reference, including redirects) so the en.wikt has about 23% coverage. Robert Ullmann 14:49, 26 November 2007 (UTC)


 * Can you add a section to WT:STATS that describes this, from now on? Very cool stuff!  --Connel MacKenzie 20:09, 30 November 2007 (UTC)

How about a way to watch a talk page without watching the entry itself?
It sucks watching the talk pages for popular words, then having your watchlist spammed by hundreds of bots adjusting various tags constantly. Language Lover 17:35, 27 November 2007 (UTC)


 * Hundreds of bots? ;-) You do have "Show bot edits" turned OFF? (In user preferences, checkbox ...) Robert Ullmann 11:04, 28 November 2007 (UTC)


 * One of the issues may be that AutoFormat doesn't have a bot flag - so this doesn't completely abolish the problem - though it would probably help considerably. By the way, is there a reason that AutoFormat doesn't have a bot flag set? Conrad.Irwin 13:08, 28 November 2007 (UTC)


 * I figure LL is probably more concerned with Interwicket and Tbot, which do lots of little changes. AF changes are probably of more interest; it is authorized to have the flag, but the impression I have had had is that people do want mostly to see what it is up to on entries that they have watchlisted or whatever. But it certainly can be flagged if desired. Robert Ullmann 13:13, 28 November 2007 (UTC)


 * I for one would prefer it to be flagged - if people are interested in watching it they can do that through it's contributions page, or just by watching all bots. However if people prefer it unflagged it isn't too much of a problem. Conrad.Irwin 13:48, 28 November 2007 (UTC)


 * Is there a way that AutoFormat revisions can be made visible, but whilst still ignoring the other bot revisions? <font style="color:darkred">†  ﴾(u):Raifʻhār (t):Doremítzwr﴿ 19:39, 29 November 2007 (UTC)


 * I, too, would prefer it flagged, but it's not a big deal.&mdash;msh210 &#x2120; 20:01, 29 November 2007 (UTC)


 * I agree - it would probably be more helpful to flag it as a bot, now. --Connel MacKenzie 18:33, 30 November 2007 (UTC)


 * has a flag now Robert Ullmann 06:30, 4 December 2007 (UTC)

blocked DerbethBot
Very sad.

I questioned whether the bot was handling multiple etymologies properly, and was told that dealing with our entry format was "insane", and that Derbeth had tried to fix it and "hoped" it worked. I.e. it was not tested.

It did do cs and sv correctly at bit, but malfunctioned fairly badly at theater.

Must, unfortunately, remain blocked until bot runner explains that the issues and malfunction are understood, corrected, and tested. If anyone else would like to look at this, please do. (User talk:DerbethBot, User talk:Robert Ullmann) Robert Ullmann 13:06, 28 November 2007 (UTC)


 * Robert, are you sure the issue isn't one of translation/communication? Certainly, to someone familiar with the other Wiktionary's formats, (without understanding the history) the en.wikt format must seem counter-intuitive.  The fact that theater is/was already non-ELE-compliant has to be a mitigating factor of some sort.  And <tt>  </tt> is, admittedly, pretty screwy.  If the color/colour approach had been taken there, instead...  --Connel MacKenzie 18:48, 30 November 2007 (UTC)


 * Oh, I pretty sure the issue is communication. Yes, our format is more complicated; but calling it "insane" and plowing ahead without understanding it and testing it is a problem. All I said (initially) is that we needed Derbeth to tell us that the issue was understood and tested. And at theatre/theater with one Pron section already there, adding another one indicates some problem ... as you say mitigated by the already broken format, but still something to stop and look at, as the 'bot should never be adding a new Pron section if there is one anywhere in the language section (should either add to that, or do nothing). Robert Ullmann 13:40, 3 December 2007 (UTC)


 * No, I was saying that because almost none of the actual content for theater/theatre is in the entry (subpage only) it is reasonable to chalk that one up as a one-time exception. No other page follows that experiment, that I know of.  --Connel MacKenzie 18:44, 3 December 2007 (UTC)


 * True, I hadn't realized it was that messed up. (I suppose I thought it was like colour/color. We have learned not to put headers in templates/transclusions, haven't we ;-). Robert Ullmann 06:35, 4 December 2007 (UTC)

class="NavFrame Shown"
I feel that this would be useful but abusable, It would be useful for my new idea for transcluding Wikisaurus entries into Wiktionary entries, so that the Wikisaurus page could have expanded tables, while the Wiktionary page could have closed tables. It would also allow the creation of which could hold the translation table open by default for very short lists of translations. To implement this the following (tested for my unaltered setup) changes would need to be made to Mediawiki:Monobook.js

Conrad.Irwin 23:17, 28 November 2007 (UTC)


 * As to "however the disambiguation is sorted out", it would probably be at Wikisaurus:enrage since the use of disambiguation has been turned down and Wikisaurus:anger would be for the primary definition, a noun. DAVilla 22:49, 29 November 2007 (UTC)


 * Thanks :) Conrad.Irwin 12:08, 30 November 2007 (UTC)

Conversion script redirects

 * low priority issue

If you run stats as much as I do, you become aware of a lot of redirects in the database.

These are the result of "Conversion script" which ran in June 2005, to convert wikipedia case to properly cased entries as we use now.

A number of the left-over redirects have been deleted, essentially at random.

There are (20 November 2007) 42,865 left.

Sawa.

Deleting them with some automation is not hard, but it must be sure on several points:


 * the last edit was user "Conversion script"
 * it is a precise redirect from an uppercase (first letter) form to lower case
 * it is still the same redirect
 * it has no links to it; any other references to it must preclude removal.

But there are 43K of these.

I have code (pleasant after work, pre-dinner task ;-), but what do we want to do? If I delete all of them at one every 10 minutes, it will be done in 297 days ... they tell me that bot deletes show in RC. Robert Ullmann 23:23, 28 November 2007 (UTC)

Are these useful for anything? As I said, it is good to munch on them for a while? Robert Ullmann 23:23, 28 November 2007 (UTC)


 * Sounds like a good idea to me, and then (eventually) everything will be nice and standard. However, I am not particularly fond of the javascript redirects in their current form - they don't add "Redirected from Wherever", and don't respect the <tt>&redirect=no</tt> option. The second problem is easy to fix, but the first would need more thinking about. (Possibly avoiding Special:Search in the URL and using a <tt>?redirecter_from=</tt> parameter). Conrad.Irwin 00:13, 29 November 2007 (UTC)


 * If we enable <tt>$wgRedirectSources</tt>, we can use <tt>?rdfrom=</tt>. But someone has to look closely at this. E.g. 3339 which has been open for two years. Robert Ullmann 16:23, 29 November 2007 (UTC)
 * In a bored moment, I decided to have an attempt at reimplementing the function, the results of which are at the top of my monobook.js, this solution circumvents 3339, but wouldn't solve it :( Conrad.Irwin 00:36, 30 November 2007 (UTC)

Interesting bit of data: there were originally about 64K of these: "A bit of crumpet" is DBID 107098, "Wiktionnaire" is DBID 170010. So about 20 thousand have been deleted along the way, or moved back to the capitalized form (or have become German nouns ;-) Robert Ullmann 17:18, 29 November 2007 (UTC)


 * Delete away! And also the ones that were moved back to their capitalized forms, leaving an untouched redirect at the lowercase. Preferential order: longest titles first. DAVilla 22:42, 29 November 2007 (UTC)


 * I was just going in ID order, which begins with A at about ID 107000 (the script apparently went in alphabetical order). The other point didn't occur to me either. Good idea, should think that through. (One step is harder though, the XML dump gives the last contributor, these have username = "Conversion script". The ones moved back will not, either on the redir or the entry.) Robert Ullmann 23:42, 29 November 2007 (UTC)


 * The task list is now sorted by decreasing length, and alpha order within length. "Lopad..." (the absurdly long coined "Greek" word) is first ... the other redirects may not be too hard to catch in lot of cases: username="Jonathan Webley", edit summary = "incorrect decapitalization" ;-) (thank you David) Robert Ullmann


 * Cool. Aside from those cases, the other point might be easier to do with a more general bot, if there were a way to tell which redirects we'd want to keep. No need to worry about it now. 70.112.121.70 07:32, 1 December 2007 (UTC)


 * Yes. If we can clear most of these, then it becomes interesting to identify all the redirects that don't seem to fit the ones provided for in policy. Robert Ullmann 13:51, 3 December 2007 (UTC)


 * I had approval to do this at one point, but when I started running it, it was immediately apparent that it was much worse than I had anticipated (due to all the German links that rightfully should be pointing to the upper-case non-existent entries.) If you can figure it out, go for it, please!  --Connel MacKenzie 08:24, 30 November 2007 (UTC)


 * Hopefully a number of those are now the German nouns... I have code that produces the "missing" list for Project - Spanish from the en.wikt and es.wikt entries, with a very small change I could produce a list of all redirects that should be German words, so we can sort those. In the meantime, anything linked-to will be left undisturbed. Robert Ullmann 12:23, 30 November 2007 (UTC)


 * Connel: I blanked your "kill list" page, as it was linking a lot of "A" words, that thus can't be deleted ... ;-) I don't want to start trying to filter "cleanup" pages out of Whatlinkshere (yet), it just uses the presence of absence of "No pages link to" in the reply. I've also blanked various cleanup lists from 2005, same issue (of course they are uselessly out of date anyway ;-) Robert Ullmann 13:05, 30 November 2007 (UTC)


 * See User:Robert Ullmann/CS redirects with links if you care to. Robert Ullmann 14:03, 30 November 2007 (UTC)


 * No, I don't particularly care about that list. But nominating it on WT:RFDO is probably a good way to not forget about it.  --Connel MacKenzie 15:21, 30 November 2007 (UTC)

Note that the present strategy for not flooding RC (since deletion log entries appear regardless) is to do 20 of them, and then sleep for a longish time (5-90 minutes) and do it again. Robert Ullmann 15:53, 30 November 2007 (UTC)

If interested, you can look at User:Robert Ullmann/CS/A (to Z and beyond ;-) to see the present state of affairs. Note there is a bit of trickiness to keep these pages from adding links to the entries.


 * Useful link: Special:Prefixindex/User:Robert Ullmann/CS/ ... Robert Ullmann 14:38, 3 December 2007 (UTC)

Transwiki entries with links these are the most common case of links to the redirects, as the transwiki pages come from the wikipedia, and have capitalized links. Rather than skip these, I've arranged to correct any links in the Transwiki: namespace to link to the correct page, and continue with deleting the redirect if that removes all of the links. (This also helps out whomever eventually edits the transwiki page.) Robert Ullmann 13:51, 3 December 2007 (UTC)


 * Whoa, I'm not sure that's a good idea. I thought you were sticking to NS:0?  Transwiki links are pretty crucial for the Wikipedia-side links (which usually point to the upper-case flavor.)  Likewise, the WP pages often link to the capitalized NS:0 page initially.  --Connel MacKenzie 18:35, 3 December 2007 (UTC)


 * I'm not deleting redirects from Transwiki: or changing the entry name to lc, I'm changing Transwiki pages that point to the UC redirects in NS:0 (i.e. used to point to WP titles) to link correctly to the lc entries in our NS:0 See? E.g. like this or this Robert Ullmann 06:26, 4 December 2007 (UTC)

German nouns I ran the same code that I used to create a missing entry list for Project - Spanish, collecting all of the German nouns (amongst other things) from the de.wikt. See Project - German (placeholder that links the subpages of the list). So any CS redirect that is a (fairly common) German noun will have link(s), and turn up in the exception list; some may have been improperly moved to lc. Robert Ullmann 16:34, 5 December 2007 (UTC)


 * OK, well, thanks for addressing my earlier concerns. Can you please remove the throttling now?  The deletion notices are confounding one of the anti-vandalism tools I use - the sooner the flood is over, the better.  --Connel MacKenzie 19:53, 5 December 2007 (UTC)


 * If I do that, the "flood" will last 34 days. I think that would annoy people? And I don't have the personal bandwidth to check the exceptions at that rate (1000+ deletions/day). What (specifically) is getting confounded? Robert Ullmann 12:42, 6 December 2007 (UTC)


 * I've changed the pattern to only do 5 at a time, but more often. Is it the IRC channel? (SWbot won't listen to even a status command from me ;-). Would adding me to the SWBot WL help? Or would it still report the deletes? Need information. Can't just let it run "unthrottled" unless (as I said) you want a month long flood that will irritate everyone, and at least several other peopl work the exceptions. A this says at the top. this isn't a high priority task, I want to just shove it into the background and let it munch. Robert Ullmann 23:23, 7 December 2007 (UTC)

Recent software update?
Did we just get some sort of MediaWiki upgrade? Suddenly, the parser has changed how it treats comments. <tt>UNIQ7dc9e09f311bbadb-nowiki-00000091-QINU</tt> used to be synonymous with <tt>UNIQ7dc9e09f311bbadb-nowiki-00000092-QINU</tt>, but now the former shows test while the latter shows test. What gives? Rod (A. Smith) 19:30, 29 November 2007 (UTC)


 * Looks like, yes. Took some collateral damage here... I think I fixed it all. Cynewulf 19:42, 29 November 2007 (UTC)


 * Interesting. Thanks for the thorough yet careful reverts, Cynewulf.  Rod (A. Smith) 20:00, 29 November 2007 (UTC)

Odd pluralization bug (?) for some noun entries
Would someone please take a look at white trash and cracker. On these pages, I'm seeing what looks like a problem processing the template's plural form. As best I can tell, it just started within the past hour. -- WikiPedant 19:50, 29 November 2007 (UTC)
 * I also saw it on Muggle and muggle. sewnmouthsecret 19:53, 29 November 2007 (UTC)


 * I don't see it any more, there was an update a few minutes ago; read the previous section. Cynewulf 19:55, 29 November 2007 (UTC)


 * Ya I saw that; but I still see the "bug",even after clearing cookies, temp files, cache, etc. sewnmouthsecret 19:58, 29 November 2007 (UTC)


 * I still see it too. I logged off of Firefox, started IE and logged on again and it's still showing. -- WikiPedant 20:02, 29 November 2007 (UTC)


 * There's some server-side caching, try editing the page and hitting preview. Cynewulf 20:06, 29 November 2007 (UTC)


 * Yes, Cynewulf, that did it. Damn computers. -- WikiPedant 20:19, 29 November 2007 (UTC)


 * Now I'm getting the same problem with whistle (both verb and noun) - as long as I'm logged in, I see no inflection forms whatsoever (neither in IE nor FF) but when I log out, they are there (in both browsers). And then I still did edit the page to try to flush the caches... and do the &action=purge... Well, at least my .css wasn't the guilty part here... \Mike 13:43, 30 November 2007 (UTC)


 * I'm seeing them okay (logged in, Firefox) Robert Ullmann 13:55, 30 November 2007 (UTC)


 * I see them now too. As far as I can tell, it seems as the links which were missing were the ones which should, according to my preferences, have that special "stub" color. \Mike 10:46, 1 December 2007 (UTC)