Visit the forum if you have a language query!

Dictionary:Grease pit

Definition from Dictionary, a free dictionary
Look up, laugh loud, talk big, keep the color in your cheek and the fire in your eye, adorn your person, maintain your health, your beauty and your animal spirits.
William Hazlitt
Jump to: navigation, search
A grease pit
Welcome to the Grease pit!

This is a new area to go with the Beer parlour and the Tea room. Its purpose is specifically for discussing the future development of the English Wiktionary both as a dictionary and as a website.

It is a place to discuss how to solve technical problems such as templates, CSS, JavaScript, the MediaWiki software, extensions to it, the toolserver, etc. It is also a place to think in non-technical ways how to make the best free open online dictionary of all words in all languages.

It is said that while the Beer parlour is a place for people from all walks of life to talk about politics, news, sports, and picking up chicks, the Grease pit is a place for mechanics, engineers, and technicians to talk about nuts and bolts, engine overhauls, fancy paint jobs, lumpy cams, and fat exhausts. That may or may not make things clearer... Others have understood this page to explain the "how" of things, while the Beer parlour addresses the "why".

Permanent notice
  • Tips and tricks about customization or personalization of CSS and JS files are listed at WT:CUSTOM.
  • Other tips and tricks are at WT:TAT.
  • Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with "tips-n-tricks" are to be listed here as well.

Grease pit archives
2006
2007
2008
All subject headings

Contents

Archived topics

These topics have been inactive for a while and have been archived, i.e. moved out of the pit to separate subpages. Discussion should continue there. See all subpages



April 2008

{{term}}

{{term}} seems not to work correctly anymore, although it hasn’t changed itself. So either someone meddled with CSS or Javascript, or my browser (FF) is messing up. I have the WT:PREF set to show single quotes, no parentheses around glosses, but parentheses around italicized transliterations. Already on the templates talk page, I see:

From {{term|sc=Grek|λόγος|tr=lógos||word}} + ...

being rendered as

From λόγος (lógos “word” + ...

Though funnily enough, if I copy it over from the page, I get

From λόγος (lógos), “‘word’”) + ...

which is, however, wrong as well. Can someone have a look at this? H. (talk) 12:42, 17 April 2008 (UTC)

I haven't noticed any change in how it displays for me, but I haven't set preferences for how the term template displays. --EncycloPetey 13:16, 17 April 2008 (UTC)
This seems to be only on Windows, with Firefox. H. (talk) 15:05, 8 September 2008 (UTC)

June 2008

Internet slang

It would be nice to redesign the context labels to carry information such as formality and region. Yes, {{internet slang}} could expand, as you say, but why shouldn't{{context|internet|slang}} classify it under all three categories? DAVilla 06:53, 7 April 2008 (UTC)

Is that doable with template:context?—msh210 19:00, 9 April 2008 (UTC)
Yes, it is. I've just created a draft of {{context class}} that could be used as {{context class|{{{1}}}|{{{2}}}|...}} where class name could be region, formality, etc. If template such as {{slang}} sets, in this example, formality=slang, then {{context class|internet|slang}} returns Template loop detected: Template:context formality which could then be used by {{internet}} for special categorization. I think I would let Robert decide how propogation should take place, since the context that determines the class (slang in this case) could come before or after the context label that does the categorization (internet in this case). It's possible to do in one direction, maybe both, without changing any of the context templates, but an extra parameter would be a cleaner design. I may also be generalizing the problem too much, but I think it's better than passing parameters like formality= and region= because if we then think of a new class to test for (like gender or something) then all of the context labels would have to be changed. Ideally by using {{context class}} you would only have to set up a single template, {{context gender}}, to redirect to {{context class}}, and then the new class name could be checked for universally. DAVilla 02:33, 1 June 2008 (UTC)

Template problem

There is something wrong with {{Icelandic formal personal pronouns}}. See it used at vor. It somehow causes the ---- and the L2 language header of the following Old High German to disappear from sight. —Stephen 20:34, 2 June 2008 (UTC)

I'm not sure why that happened, but I've fixed it by removing the float: left; from the table's CSS. —RuakhTALK 23:46, 2 June 2008 (UTC)
Thanks. :) —Stephen 00:00, 3 June 2008 (UTC)
For future reference, as a temporary fix, you can use {{-}} after the template. See, e.g., [1].—msh210 16:28, 3 June 2008 (UTC)

template:a

The accent template {{a}} normally produces italic text in brackets, e.g. (RP).

For most uses this is exactly what is required, however where there are further qualifiers (for example at postulate) and it seems unnecessary to have the parentheses. So could a template wizard add an option to the template to accomplish this. Cheers Thryduulf 18:54, 3 June 2008 (UTC)

Do note that you can use:
* {{a|RP|noun}} ... 
and that it is designed to work that way. (barring someone discovering an obscure dialect called "noun" ;-)
  • (RP, noun) ...
  • (RP, verb) ...
An alternative is to use ; Noun and then list the relevant things, then ; Verb and those; this kind of separation is more general. (Sort of what the badly formatted version before your edit was trying to do.) Robert Ullmann 19:10, 3 June 2008 (UTC)

IPA font too small

Recently (within the past few weeks), something has changed with the way my linux firefox displays IPA fonts. They now use a font that is about too points smaller than previously (and what my windows firefox uses) making some of the symbols difficult to read. The same font is used in the IPA edittools and in the display from the {{IPA}} and {{IPAchar}} templates, but not for IPA symbols used elsewhere.

Does anyone else have this problem? If so can it be fixed? If not, how can I fix the display at my end? Thryduulf 01:42, 4 June 2008 (UTC)

I haven't noticed this problem using Safari. --EncycloPetey 01:44, 4 June 2008 (UTC)
You can apply a custom style sheet in your browser, and change the formatting for the class, for example:
.IPA { font-size: larger; }
 Michael Z. 2008-06-04 02:41 z
That sounds good - how do I apply a custom style sheet? Thryduulf 09:03, 4 June 2008 (UTC)
I have the same problem, due to the fact that I don't have the fonts listed in MediaWiki:Common.css and it falls back to something silly, ugly and tiny - it annoys me just a tiny bit. Thrydulf: just add .IPA { font-family: DejaVu Sans } to Special:Mypage/monobook.css. (If you just want to make that font larger, then use the code above instead of the code which uses DejaVu Sans). Conrad.Irwin 09:16, 4 June 2008 (UTC)
Thanks. Thryduulf 10:27, 4 June 2008 (UTC)
A couple of days, several hard refreshes, a couple of browser restarts, a computer restart and a clearing of my cache later and what is in my monobook.css still isn't what I'm seeing. I do use the monobook skin. Does anyone have any ideas what is going wrong? Thryduulf 18:03, 6 June 2008 (UTC)
There's a dot at the start of the code. .IPA { font-family: DejaVu Sans }. At the moment you have only IPA { font-family: DejaVu Sans }. By the way I think we need to discuss this font issue further, I've seen other editors trying to fix it by putting Arial into their stylesheets, so it is clearly not right for a number of people. Conrad.Irwin 18:06, 6 June 2008 (UTC)
It's still not working, nor is the right-floating TOC code doing anything (nor has it ever done anything now I think about it). Thryduulf 18:06, 10 June 2008 (UTC)
Are you using the Monobook skin? It's the default one when you are not logged in - you can check in Special:Preferences. Conrad.Irwin 18:09, 10 June 2008 (UTC) Whoops, you said above.
Do any of the WT:PREFS work? Conrad.Irwin 18:10, 10 June 2008 (UTC)
I only use the option to display the UTC time, but that does work. Thryduulf 20:13, 10 June 2008 (UTC)
You had an extra semi-colon in your monobook.css, I have removed it. The code that you have there floats the "[show]" buttons to the right, and has nothing to do with the TOC (though there is a WT:PREF for that which I would highly recommend). Conrad.Irwin 20:19, 10 June 2008 (UTC)
Thanks, that semi-colon removal has fixed it. Thryduulf 20:09, 11 June 2008 (UTC)

JavaScript handling changes

It looks like improved support has been added at the MediaWiki level for importing scripts and stylesheets, along with an improved addOnloadHook function. The SVN changeset, applied two weeks ago, can be seen here: http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=35064. It might be worth taking at look at the code we have here, although there are some differences between the wikibits.js version and what we have here in MediaWiki:Common.js. Mike Dillon 03:15, 4 June 2008 (UTC)

I don't know of any scripts using importStylesheet, and I notice that their importScriptURI is identical to our importExternalScript so we should probably deprecate that. The version of importScript they provide is missing a lot of the creeping featurism that we have in ours, so that'll have to stay. The changes to addOnloadHook were the result of a bug I filed which should make WT:PREFS work on the first page load for everybody (the race condition is removed). They also provide an appendCSS function which could be used by addCSSRule, although it doesn't even bother trying the CSS DOM and so it's probably nicer to leave it as it is. Conrad.Irwin 12:58, 6 June 2008 (UTC)

Broken pages

Hi everyone, bugzilla:14406 documents a problem I'm having with Index:English/a (and a slightly different problem I'm having with Index:English/b). Just try adding {{Index:English/a/2}} to the page if you wish to replicate the issue. I'm a bit perplexed, as the length of the page is considerably less than our discussion rooms, for more details see the bug report. If anyone with communication skills would like to rewrite/comment on the bug I'd appreciate it. Conrad.Irwin 23:50, 6 June 2008 (UTC)

High time we subcategorize Category:Context labels

Category:Context labels currently contains some 800 labels. Given that these can be very different, it's time we categorize those. Here's my fairly simple proposal:

  • Grammar context template are moved from this and Category:Grammar templates to a category of their own (simultaneously giving making the non-context tags easier to find).
  • "empty" combining templates (e.g. "mostly") get a category.
  • geographical templates (or "dialectal" so ) get one (more simply, do not liss stuff in both Category:Regional templates and Category:Context labels; make the former a child of the latter).
  • Stylistic (slang, literary, etc.) templates get one.
  • The topical tempates are split roughly between "sciences", "arts and humanities", "hobbies and crafts". Or whatever best split we can think of.

Circeus 00:00, 7 June 2008 (UTC)

Sounds like a good idea. to me. Here is a more detailed (but not comprehensive) version of the same proposal based on library cataloging and on what I know of our context tags:
  • Category:Context qualifier tags
  • Category:Usage context tags
  • Category:Grammar context tags
  • Category:Geography context tags
  • Category:Topical context tags (with subcategories added as needed)
    Category:Humanities context tags
    Category:Natural sciences context tags
    Category:Sports context tags
    etc.
The use of "tag" may be modified, but I prefer it to "label", which is more likely to generate a misspelling. --EncycloPetey 01:28, 7 June 2008 (UTC)
"context" qualifier tags, I assume, is intended to describe my "empty" category? While I was unsure about adding a "topical" level at first, it makes the issue of "thorny" placement easier. Circeus 01:36, 7 June 2008 (UTC)
Yes, by qualifier tags I mean "mostly", "only", etc. --EncycloPetey 01:56, 7 June 2008 (UTC)
I created Category:Context qualifier tags but I could not recategorize any of the templates because the Context labels category is applied by Template:context- which I don't know how to edit. Unless we just want to keep everything in Context labels as well as more specific categories? Nadando 04:37, 7 June 2008 (UTC)
I like the way that (all but one of) the suggestions end in "context tags" because it's a little simpler if it's consistent. (The qualifier tags it might be possible to categorize automatically anyway. For the others) I've added a topic= paramter that will categorize under both "Topical" and the topic, and otherwise a type= parameter that will accept usage, grammar, etc. The parameter should go on the first line of the context template's code. For uniformity do not modify the second or third lines. All the labels are marked as "Uncategorized" at present. Although I left it as "label" for now, it could easily be changed to "tag". DAVilla 06:58, 7 June 2008 (UTC)
Re: topic=: I'm not a huge fan of that, because topic categories are part of our content, while templates are part of our infrastructure. The rest of what you did sounds great, though. :-) —RuakhTALK 14:28, 7 June 2008 (UTC)
Ruakh, because {{context}} and its parent currently do not discriminate on namespace for the inclusion of categories, all templates are already sorted topically. They've been for a while. Circeus 14:49, 7 June 2008 (UTC)
It does discriminate on namespace: in NS:0 it cats the entry, in Template (NS:14) it explicitly cats the template with sortkey " " at the top of the topic or region or POS (in the English cat). In any other namespace, it adds no cats. I don't really think the templates should appear in the content cats at all; but at the time I created the new version I was replicating the existing behavior. They probably should be removed from the content cats. Robert Ullmann 15:18, 7 June 2008 (UTC)
Talking about that, is there any reasonable way to prevent stuff like {{en-noun-note countable and uncountable senses}} from showing up in the context labels cat? Circeus 16:57, 7 June 2008 (UTC)
Re: "templates are already sorted topically": I've noticed, but I'm not a huge fan of continuing the practice. :-P —RuakhTALK 16:40, 7 June 2008 (UTC)
That was just an aside, really. the proposal to split templates is really all about making it easier to locate the template you want, when they are often ambiguous or counterintuitive ("What does {{negative}} mean?"). Circeus 16:57, 7 June 2008 (UTC)
(Not sure where to indent this, or under what, but it's a response to RU's comment of 15:18, 7 June 2008 (UTC) and Ruakh's of 16:40, 7 June 2008 (UTC).) I think that the templates should be categorized in the "content" categories, listed first, as they have been, in order that a new editor, who doesn't know how to add an entry to a category (besides by hard-coding it), can, perhaps, learn how.—msh210 19:08, 11 June 2008 (UTC)
I put the context template back. (DAVilla, for the Nth time, would you slow down and wait a week or two to find the best way of doing something; if it was a good idea it will still be a good idea. Otherwise it becomes crap for someone to spend a lot of time cleaning up.)
As Ruakh points out, the Context labels cat is infrastructure, trying to sort it out as content is wrong, (horrendously wrong). There is no reason why a template can't be in more than one cat; there is no reason to "re-organize" the category.
If you want additional cats for groups or whatever, put them in noinclude tags at the end of the desired context label templates. Adding a parameter for {{context}} that it has no other use for is an extremely bad idea. Robert Ullmann 15:00, 7 June 2008 (UTC)
Look, I'm not interested in coming up with ideas that are never implemented because they're put up and described and never discussed. If something were discussed and we were to come to a conclusion, that it wouldn't work or should be implemented another way, then fine, I'm all in favor of the process. But usually the process amounts to trying to explain a new idea that nobody can understand which therefore dies not from lack of fitness but from lack of discussion. That is, process kills ideas. I'm all for killing bad ideas, but not for weeding out the good ones as well. The point of categorizing through {{context}} is simply to make sure that all templates are categorized, which was the purpose of Category:Uncategorized context labels, to locate those templates that are not subcategorized. Maybe Category:Context labels itself is good enough for that, and we don't need a duplicated master list. Fine, done. If topic= is not a good idea, fine, it's out. At first I'd only made a small change, describing topic as a possibility, then went back and decided some of my ideas would be pretty cool, which was dumb considering that you tend to roll back multiple changes wholesale without trying to understand them or considering the merits of any individually, for example this edit in which you rolled back a simplification that you then agreed to, and also hover text that just never got implemented "the best way of doing something" or any way at all, all on account of a single change, a reordering in presentation, commented as experimental in the first place, which I would gladly have undone if anyone came forward with objection. And then your newfound overconfidence rolls back changes like this one in which you're entirely wrong because translations tables should always have a gloss and simply titling it "Translations" isn't an appropriate default, but you win on arguments that it shouldn't be done just yet etc. etc. and I concede and then it just stays that way forever and the problem is never fully resolved. So, so what if I'm bold? You coming by and reverting me is not spening a lot of time cleaning up crap, it's completely ignoring the positive contributions that I've made. Great, you spent a lot of time rewriting {{context}} and {{language}}, and now they're super efficient. Does that make the originals crap? You engineer the code and not the solution and because of that you don't think my contributions are worth paying attention to, but you're wrong about this one as well, about type= not having any other use. If it's a regional label then in the near future we would want to have categories for the intersection of region and formality, e.g. Category:US slang as just one example. And this was by no means tricky code. A parameter for topic was probably going too far, I admit I always go too far, but at least now everyone knows it can work, and how easy it is to do, and in fact how much more can be done that they hadn't even considered. The solution is not just a template that does this and that, it's a template that does and that maintains itself. If you remember how much people hated the error messages on new labels, organization was the principle of the design behind {{cattag}} in the first place. So there's more than enough justification for why this approach is anything but as bad as you say it is. Duh, I do give some thought you know. What you don't like isn't that the deeper points haven't been discussed, it's that it's been done without explaining it all to you, and without your bessing and approval. So for the square root of Nth time, thank you for sharing your knowledge, thank you for your criticism, thank you for keeping me in check, go ahead and capture my queen which I pranced around far too early, but I'm still going to advance and one way or another develop the pieces of this wiki. DAVilla 09:05, 8 June 2008 (UTC)

Sigh. Undoing the changes again. DAVilla: I rollback and undo things because they are broken.

Category:Context labels should, and does, contain all of them. Other categorization of context labels, tags, whatever is properly done in the templates themselves.

Frankly, you don't know enough to be doing this. Do you have any understanding that what you are adding to change cats on the templates causes processing overhead on every mainspace page? It is wrong. The categorization of templates belongs in the templates. (If anything, the Category:Context labels might be removed from {{context}}, but it does seem useful.) You don't think through the conequences of a change, or take anytime whatever to ask what it might be. And someone else (which seems to be mostly me) has to clean it up. I've already spent a number of hours on this, and it looks to be taking a bunch more to get whatever we want done correctly. Robert Ullmann 12:59, 8 June 2008 (UTC)

Also note that Circeus is finding it useful to put some templates in more than one category, which your code did not anticipate, as you didn't stop to think before mucking in with changes. Robert Ullmann 16:59, 8 June 2008 (UTC)
Actually, most of those are borderline cases (combinations of usage and something else, mostly regional templates) that could be easily dealt with one category should it be decided. The only "bad" thing it shows about DAVilla's edit is that it was not quite the most efficient choice implementation method (a {{#:switch}} would have been better and prevented incorrect categories). Circeus 00:27, 9 June 2008 (UTC)
Nothing wrong with adding that later if it's needed. The more I anticipate the more complex the code. Anyways, at least a few of the dual cats should be rethought. It's unbelievable to me that we already know which ones those are. Thanks, Circeus. DAVilla 13:33, 9 June 2008 (UTC)
Others should note this has caused repeated re-processing of every mainspace entry, with no resultant changes to the entry; and the changes would have caused permanent overhead on every instance of {context} on every mainspace entry, just to cat a few templates.
We probably should do away with any categorization of templates by {context} entirely; they should not appear in the content categories, and should have the categories desired in the templates. Circeus has done a great deal of this. (DAVilla, do note I am not precipitously removing the template cat code; it is to be discussed, eh?) Robert Ullmann 16:49, 8 June 2008 (UTC)

Okay, I went through Category:Grammar templates. Can an admin edit {{transitive}} to replace the category? Now going to edit those of the geographical category. Circeus 15:24, 7 June 2008 (UTC)

Nevermind that, I'll just add Category:Context labels to Category:Regional templates for the time being. I'm of the opinion a renaming should be considered, though. Circeus 15:30, 7 June 2008 (UTC)
As you note, we already had Category:Grammar templates, and Category:Regional templates, all that was needed was adding cats for qualifiers and perhaps topic classes in the same manner. Robert Ullmann 15:37, 7 June 2008 (UTC)
I felt a need to separate the grammatical context labels from other grammar tenmplates to make it easier to locate an appropriate non-label templates. When you have {{locative}} and {{imperative}} flaoting around and being completely different types of templates, it becomes very useful. Also helps noticing potential "missing" templates. Besides, Category:Gender and number templates are already separate, so I don't see why a much more distinct category can't be split off. AN example of a template better put in Category:Grammatical context labels cat than Category:Grammar templates is {{of a person}}. If you can think of a better place, feel free. Circeus 16:02, 7 June 2008 (UTC)

I notice we have a Category:Uncategorized context labels, which is actually an oxymoron since, by definition, all its contents are categorized. :P --EncycloPetey 16:43, 7 June 2008 (UTC)

Semantics are relative. Of course "uncategorized" means "not placed in a context labels subcategory". It's just a temporary cache too. Circeus 16:53, 7 June 2008 (UTC)
If we removed the template cat code from {context} where it really does not belong, any template without categorization will show in the specials page, and we can find it in due course. Robert Ullmann 16:49, 8 June 2008 (UTC)

Where we are now: User:Robert Ullmann/Context labels (do note that it doesn't reread or recheck templates that seem to be okay, see the "as of" date.

We could cat most of these by "magic", but we do not need a parameter to do it. The open question is whether we want to have overhead in every single NS:0 expansion to cat the tamplates more specifically? Seems better to put them where we want.

Yes, I realize I am irritating DAVilla once again, but this just isn't rocket science; {{context}} already had what it needs to do this by magic if we are willing to take the overhead. Robert Ullmann 23:36, 8 June 2008 (UTC)

No, you're not irritating me by suggesting consistent positions. With subcategorization, if {{context}} is going to categorize then it might as well subcategorize. If categorization is inappropriate through the template (which I don't agree with) then it might as well not categorize at all. Your suggestion I'd already known was possible with the qualifiers (since that was inherited from the previous design), and it's great that more may be possible. DAVilla 13:33, 9 June 2008 (UTC)

DAVilla, I apologize for all this. I have been exasperated because you do the same thing over and over: you don't slow down and think through all the consequences before plowing in to edit something important. In this case, your second round (type=) does not work correctly, on a template like {{mostly}} if one used "type=qualifier" the template would also appear in the top category because the template recalls {context}. If you had thought it through before adding it, or tested it, you might have found this (and the simple fix). Again, I am sorry for all the invective; but please do slow down, take a few days, think about it, test it? Robert Ullmann 12:05, 9 June 2008 (UTC)


If we do want to have {context} auto-categorize the templates, most can be done without a parameter, the template already knows the "type", as it has the various cat= parameters. If the template uses topcat= it is a topical context label. (Ignoring for the moment the categories that are set up as topics incorrectly. ;-) There are a few other fine points, and at least one bug and another case that needed to be handled.

I set up a test at {{context new}}.

It auto-categorizes into the subcats as Circeus suggested and set up. The subcat can be over-ridden with tcat=, for exaple to identify the grammatical labels (which often do not have cats). I also added cat= for an un-classed cat: for example {{UK}} should be a regional label, but the cat is "UK", not "UK English" (which it probably should become ;-).

I changed a few templates to test {context new}: {{astronomy}}, {{chiefly}}, {{East Africa}}, and {{UK}}. The latter uses cat=UK and tcat=regional.

Have a look? The question is whether we want the overhead (not terrible) on all the mainspace pages, to get the label templates to cat. It does seem useful if done correctly.

We might also do something with "class" as discussed above (re internet slang), but I haven't had time to look at it having spent 2+ days sorting this. Robert Ullmann 12:05, 9 June 2008 (UTC)

If uniformity simplifies the code then I'm all for UK -> UK English. As for {{context class}} that's clearly a lot trickier than something like type or even what you've been working on to solve template categorization, so put that aside. When you have time, though, I'm wondering how to do propogation, e.g. if one of the templates had a value (such as default language or whatever) defined then how could the others use this when ordered either before or after in the context labeling? Normally I would just do two passes, but with the way expressions expand here that would probably lead to O(n2). DAVilla 14:00, 9 June 2008 (UTC)
I'm not sure that UK --> UK English will work, considering the way it's been used in the past. Since it is a geographical qualifier, it has been used like the name of a country, not like the name of a regional dialect. So, I seem to recall uses of mostly UK to indicate that a spelling is primarily found in the UK or that a sense is found there. The expanded form just sounds a bit awkward to me, as would an expanded US --> US English. I've also come across this template used (mistakenly) in the pronunciation section, where it should be {{a|UK}}. Any switch would have to take that into account. I suggest we look at how the template appears in context on the pages where it is used before we make this change; any problems will then have to be found and edited by hand, unless a bot can find context for us. --EncycloPetey 14:38, 9 June 2008 (UTC)
We don't need to address "UK English" and "US English" now, although that would be more consistent with (e.g.) East African English, etc. What {{context new}} fixes is the problem where {{UK}} used to have to use topcat=UK and that leads to {{context|UK|lang=hi}} generating cat "hi:UK" instead of UK. If we do make the cat "UK English" later, then we can use regcat= and properly generate the cat "UK Hindi". And yes, we'd have to have some code hunt through an XML dump for other uses of {UK}, fixing the ones that should be {a|UK} and tagging others not used as definition context. Robert Ullmann 13:00, 11 June 2008 (UTC)

Subcategorization of Category:Topical context labels

First: WOuld someone please add categories to {{grammar}}, {{obsolete}} and {{rare}} please? Leaving the technical aspects of main label categories to the above discussion, should this category be re-divided? If so, should it use double categorization in topical and sub-topical cats? (I personally don't see an issue with things being put in Category:Topical context labels by {{context}} and manually in subcategories)

Roughly we have the following unlumped categories:

  • hard sciences (cf. physical sciences, maths, physics, informatics, biology)
  • humanities (inc. philosophy & religion?)
  • professions (e.g. {{banking}}, {{accounting}})
  • arts & crafts
  • hobbies
  • sports & games

With the science categories candidate for splitting, but bugger me if I can figure how to name these categories, as well as quite a few oddball stuff that are not strictly speaking context labels, but that is for another discussion (I'll say I call those "definitional" or "categorizing" labels, e.g. {{insect}} and {{rivers}}).

The naming issue shows up mostly in how to split and name the last three or four categories. I'm not doing another categorization run right now (let me breath :p), so ideas are very welcome. Circeus 16:46, 9 June 2008 (UTC)

A template like {{insect}} should not exist. We went through this discussion before over the template (time). Definitional templates are incorrect, as any information they provide whould be in the definition only. Circeus, I don't see that any of the categories you've named above need to be subdivided. Some will be larger catgeories, but that's OK. I would go only with the list above, and worry about any splitting once we've recategorized and considered what is missing from the resulting lists. --EncycloPetey 19:46, 9 June 2008 (UTC)
There are _some_ cases where a template also serves for disambiguation in a foreign articles, but that's still incorrect. These templates (some of which I listed at category talk:Context labels) ended up primarily created to provide categorization (some times they are used almost only in one foreign language, such as {{mushroom}} on Finnish page). I intended to start a separate discussion on the topic of what context labels where about once I could collect a proper list, so if we could keep this to the Topical context labels cat, I'd appreciate. Circeus 20:44, 9 June 2008 (UTC)
I think that for the sake of consistency, the subcategorization should follow some established scheme or w:controlled vocabulary like the w:Library of Congress Subject Headings. I don't think it much matters which is chosen, and it should only be carried to one or two levels, but why reinvent the wheel, when really smart professionals have already put so much work into it? Michael Z. 2008-06-10 04:33 z
A context template is not the same as a gloss. Foreign language entries needing disambiguation should use a gloss, if an existing context tag is not available. Glosses should follow the translation/definition, not precede it as a context label does. --EncycloPetey 21:03, 10 June 2008 (UTC)
Templates like {{insect}} certainly should exist. But it should display (e.g.) (entomology) whilst categorising in Insects. Cf. {{star}} which is set up properly now, catting in Stars, a sub-cat of Astronomy, and displaying (astronomy). Robert Ullmann 12:33, 11 June 2008 (UTC)

Lost watchlist

In the course of editing my raw watchlist, I lost it. Is it readily recoverable? DCDuring TALK 02:44, 9 June 2008 (UTC)

Um, no. If you use the Python wikipedia bot framework, then you have a local copy ... but I don't know what it would take to re-load it. It is in the non-public dump, (as of 25 May), but would take serious developer work to extract and re-load. Sorry, not a good answer. Robert Ullmann 12:11, 9 June 2008 (UTC)
Thanks. I was afraid that was the answer. I suppose, I should have made a manual backup. But there was a lot of dreck in mine anyway and the long list was hard to maintain. I would love to set default expiration dates for watch items and have some kind of default that kept me from cluttering it up with non-lemmas, entries where my edit was minor, but kept all of my new entries, lemma or not. I don't usually remember to deselect "watch this page". If this were something fairly straightforward and entertaining for a developer to do, I'd appreciate it. If there were some way to use "my contributions" to create or refresh a watchlist, that would work. I don't know whether there are very many others who share any of these wishes. Any suggestions are welcome. DCDuring TALK 14:34, 9 June 2008 (UTC)
Why do you need to deselect "watch this page" - mine is always deselected, and I have about a dozen items in my watchlist i.e. just the ones that I am particularly interested in. SemperBlotto 14:37, 9 June 2008 (UTC)
There is a possibility to choose a setting "Add pages I (create|edit|move|delete) to my watchlist", and I guess DCDuring has chosen to use one or more of these options. \Mike 15:07, 9 June 2008 (UTC)
What Mike said. I like to keep track of what I'd worked on to check for response to changes, esp for RfV/RfD items. I've found that there are classes that are of low subsequent interest and that the volume of changes drops of dramatically after just one week, two if there is a holiday weekend. Obviously styles differ. Over time I have learned what is likely to generate adverse changes so perhaps my default should change. DCDuring TALK 15:12, 9 June 2008 (UTC)
I have (and like having) thousands of pages on my watchlist (4,497 as I write). What I'd like is to be able to filter out bots except AutoFormat. Thryduulf 22:57, 10 June 2008 (UTC)
Word, except that I'd like to filter out AutoFormat as well. :-P —RuakhTALK 22:59, 10 June 2008 (UTC)
There is an option to filter out all bots, in Special:Preferences iirc. Thryduulf 23:06, 10 June 2008 (UTC)
You're quite right (thanks! I was unaware of that), but it doesn't seem to work properly: it seems to pull the last changes to watched pages and then filter out bot edits, rather than to pull the last non-bot changes to watched pages. The real reason I want to filter out bot edits isn't that they're hard to skim (for me they're not, as I don't watchlist that many entries — right now only 537, and every so often I clear 'em all out), but that they frequently follow on the heels of human edits that I do want to see. Ah, well, I guess can't have everything. :-(   —RuakhTALK 23:29, 10 June 2008 (UTC)
Yes, that's how it works. It irritates me on the 'pedia, where displaying the watchlist shows almost entirely reverts of vandalism, with no indication of whether they were preceded by substantive changes that I want to see. In this case, bot entries will suppress previous edits, and doesn't play well with AF editing something because someone else has and it finds something that needs fixing. For a long while AF wasn't bot flagged, and this worked a bit differently: you'd see the AF edit, but still not the precipitating edit. (A similar thing happens with iwiki bot edits working from new pages.) Would be very hard to fix in the WM s/w. (Well, not that hard; but would then be a much more complex and expensive database operation.) Robert Ullmann 12:41, 11 June 2008 (UTC)
In the Watchlist tab of Special:Preferences there is an option to "Expand watchlist to show all applicable changes". This does what I think you are wanting in that it shows all changes to watched articles rather than just the most recent. Sort of like a recent changes for watched articles only. Thryduulf 20:24, 11 June 2008 (UTC)

WT:PREF as a tab in Special:Preferences

Recently I saw that in meta:Special:Preferences, there is an extra tab ‘Extensions’ with specific functions for Meta, much like our WT:PREF. Wouldn’t it be possible to include that in our Special:Preferences as well? H. (talk) 10:14, 9 June 2008 (UTC)

Oh Frabjous Day!

  • 1871, Lewis Carrol, Through the Looking-Glass, and What Alice Found There
    "And has thou slain the Jabberwock?
    Come to my arms, my beamish boy!
    O frabjous day! Callooh! Callay!"
    He chortled in his joy.

New XML dump ... Robert Ullmann 23:29, 13 June 2008 (UTC)

The last XML dump is four weeks ago. I noted that the June 24 dump of enWikt aborted. Because many others also aborted, I assume that it is not content-related. OTOH, if it is, can we do something to make it more likely the dumps will not abort? Is there an ETA for another effort to get one. There are so many good lists generated from the dumps that surface all kinds of irregularities and improvement opportunities. Perhaps we have to recognize the dump problem and manually update the lists that are dump-dependent so that they are more useful for identifying remaining problems. DCDuring TALK 00:19, 10 July 2008 (UTC)
Various people have been poking Brion; his last note said (approximately) "yup, it's stuck" it has to do with allocation of disk and other hardware apparently. There are parts of things I have cached locally on my laptop as code runs (like Tbot), but nothing generally. Robert Ullmann 10:53, 10 July 2008 (UTC)
I noted that the 7/24 dump aborted. It will be two months by the time of the next dump. All the messages that suggest we don't need to manually update cleanup lists will need to be changed if we can't count on dumps. It is a little hard to understand why the same problem recurs for apparently the same set of dumps every two weeks. DCDuring TALK 11:55, 25 July 2008 (UTC)
It is a fundamental queuing problem, as I have pointed out over and over again, to little avail. Right now for example, there are four threads running. (see status) they are all doing monstrous tasks; en.wp takes weeks.
It is like going into the bank where there is one queue for four tellers, and transactions take either 30 seconds or 10-15 minutes (common at my bank ;-). If there are 50 people in line, you are fine, but if there are 4+ people ahead of you with long transactions, you're screwed. We need to have a fast lane. (my bank uses a deposit-only window, and a window only for deposits/withdrawals in 500s and 1000s notes) I've suggested this: one thread should do only non-pedia or not language in [en, fr, de, ja, zh, (couple more)]. Or two threads with size limits.
They need more fileservers apparently to keep it from failing. So it goes along for a while (days/weeks) we get close to the top, then gets stuck, is restarted, and the order of the queue reset or randomized, and we are half-way down again. This should also be fixed. Brion is just too busy, so we get to just be frustrated and throw things ... Robert Ullmann 12:34, 25 July 2008 (UTC)
Can we get in league with the others that seem to be getting screwed on the same schedule as us? Are there "paying" customers ahead of us in the queue? Is there any thought about not letting the dumps get too far behind. (Ours will be 8 weeks.) There seem to be many that get their dumps every two weeks. Would it not be possible to give some priority to those who have the oldest previous successful dump? Things are getting so bad, we're going to have to start improving our Help just to keep busy. DCDuring TALK 13:24, 25 July 2008 (UTC)

Uploading audio

I've seen talks about a bot that uploads audio in batch mode. Is it still operational? Can it be used for FL audio? Which part is automated: uploading to Common or adding uploaded audio files to a Wiktionary entry? Thanks. --Panda10 21:31, 16 June 2008 (UTC)

DerbethBot will automatically add audio to entries and there is a piece of software called google:commonist that will upload batches of files. If you haven't recorded the files yet, you might want to look at the software that google:shtooka use (if you use IRC and you're lucky enough that he is online, then zMoo can explain everything about how that works). User:Dvortybot is also something audio related, but as far as I'm aware it is far less active than Derbeth's. Conrad.Irwin 15:25, 17 June 2008 (UTC) (fixed links 09:42, 18 June 2008 (UTC))
I've been using Shtooka for a while now, but I was not familiar with the other tools. Wrote a message to Derbeth. Thanks. --Panda10 19:06, 17 June 2008 (UTC)

{{rhymes}}

Something is wrong with the optional language parameter for {{rhymes}}. {{rhymes|nl|ek}} now creates Rhymes: -nl, -ek, that is with :nl: in the link, that should be :Dutch:. I had a try, but that didnt work out, can someone else fix this? Probably a nice time to introduce lang= in there, and get rid of the {{#if|{{{2}}}|, which is ugly. You'd have to review all non-English usages of the template, then, I'm afraid. H. (talk) 15:42, 17 June 2008 (UTC)

It might be possible to reduce the number of manual reviews needed if a bot could detect uses of the {{rhymes}} template in non-English POS sections, and replace any instances of the iso code for that language as the first parameter with a lang= as the final parameter. Any instances of {{rhymes}} in non-English POS sections with only a single parameter could have lang= added as a second parameter. Actually the second of these would be a useful addition to AF's duties. Thryduulf 16:55, 17 June 2008 (UTC)
Oh dear, someone added the language (code) as an optional parameter before the suffix? Urk. Yes, we should have lang= instead. I'll look at hunting them a bit later tonight (e.g. after the Euro 2008 matches at 18:45 UTC ;-) if I can. We have a recent XML dump, so I can search it. Adding lang= to {rhymes} (and {IPA}) in non-English sections might indeed be a useful task for AF. Robert Ullmann 17:13, 17 June 2008 (UTC)
Taken in isolation there is logic to having the language first in the rhymes template, as the output is Rhymes:language:suffix (e.g. {{rhymes|fr|ɔ̃}}Rhymes:French:-ɔ̃). In the context of standardisation with other templates, it makes no sense at all though!
If you are adding lang= to {{IPA}} you should probably also do it to {{SAMPA}}, even though only a few languages are defined with the latter). Thryduulf 21:20, 17 June 2008 (UTC)
See User:Conrad.Irwin/foreign rhymes, generated from the latest dump. There's not that many of them - so maybe I'm missing a trick. Conrad.Irwin 09:37, 18 June 2008 (UTC)

I'd usually wait and think about this a bit more, but since the template is borked already, I've fixed it. Initially to accept either lc|suffix or suffix|lang=lc; and allow language name or code. (E.g. use {{langname}}). I added Category:Rhymes template with 2 parameters if so; it doesn't have to exist to look at it. Robert Ullmann 14:29, 18 June 2008 (UTC)

I've fixed the ones on my user subpage. This might be a good thread to think about the idea of using Categories to implement the rhymes pages (as proposed on WT:BP). The template would accept the rhyme and the number of syllables in the word, and thus generate a list under each number for each rhyme. Any thoughts? Conrad.Irwin 14:35, 18 June 2008 (UTC)
Okay, we'll see if anything else turns up. Cats would seem better. Is the number of syllables that important? (It may be, I have no particular opinion.) Using Category:Dutch rhymes -o etc would be good; the category can always have text like the existing Rhymes: page; it could be hidden and just linked from the template as now? If so, we would be very close to what we are doing now. Robert Ullmann 14:45, 18 June 2008 (UTC)
Thanks for fixing this so fast, great! H. (talk) 19:18, 21 June 2008 (UTC)

Wikisaurus requests:

Bots

  • It would be nice to have a bot that checked to see that entries made in wikisaurus pages had entries in the wiktionary. If they did not and no other source was cited, an error report would be generated. This would give us a starting point for clean-up of pages without actually altering anything.
Now I know we're nowhere near close enough to a usable wikisaurus to do this, but I didn't want it put off til the last minute. I'd forget, sure as shootin' This would give you a heads up on it and give us time to argue through the reasonableness of the bot as well as whether or not we want to have bots in WS or if they're going to be handled separately or any of a hundred other things that are sure to come up.
I've got an objection/exception right off the bat myself. How can we possibly know if another source is cited? Amina (sack36) 06:43, 18 June 2008 (UTC)
  • Most useful would be a bot that checked the list of synonyms and antonyms on a page against head words that have already been made. If they aren't there or on the "to be made" page, the bot would add them to the "to be made" page.
This bot would be needed sooner. There are tons of words already on the request list as well as on the cleanup list so there's no hurry here, either. But I'm on my way with the grunt-work. It'll get gone, don't you worry! Amina (sack36) 08:04, 18 June 2008 (UTC)
I'm not really sure what you're getting at, but it sounds like (in the first request) you want to generate a list of the pages in Wikisaurus that contain words that don't have dictionary entries? That should be reasonably easy to do. The second request, you want a bot to add synonyms and antonyms from the main entries to the Wikisaurus page? This will take some more thought, as we need to decide (or you need to just tell us) exactly how the bot will format these entries. Conrad.Irwin 09:47, 18 June 2008 (UTC)
You're exactly right on the first one. The second one is fairly similar to the first. It will troll wikisaurus entries looking for words that haven't been made into headwords. Then check the list of words that are waiting to become headwords. If the word is on the pending list or a headword, the bot does nothing. If the word is not on the pending list but is a headword the bot does nothing. If the word is not a headword and not on the list the bot adds it to the pending list. If the word is on both the pending and is a headword, it removes it from pending. Is that clearer? Amina (sack36) 15:39, 18 June 2008 (UTC)

Page Deletes

There are some Wikisaurus pages that are both incorrect and types it was agreed we would leave until later. Can some of them be deleted or routed somehow so they don't get referenced until they can be cleaned up? Amina (sack36) 07:10, 20 June 2008 (UTC)

If you want them deleted just replace the page with {{delete}}. If you want the content later on though, just leave them. They'll do no more harm in the interim than they're doing at the moment. Conrad.Irwin 23:17, 21 June 2008 (UTC)

Function

What does {{{2| }}} do? It's not a template is it?68.148.164.166 03:47, 21 June 2008 (UTC)

No, but that syntax is often used in writing templates. It means, "use argument #2, else..." --EncycloPetey 03:51, 21 June 2008 (UTC)

Indic shaping & fonts

I just noticed that applying the {{Gujr}} (Gujarati) script template broke shaping for me so I did a quick fix by adding Shruti and Code2000 before the {{unicode fonts}}. Should this actually be in Common.css though?

{{Deva}} also applies the same list of unicode fonts and although I haven't seen it breaking shaping behaviour, that list might not be optimal.

I noticed the Gujarati problem when using the {{t}} template - is there any reason that template doesn't set lang/xml:lang attributes?

Moilleadóir 09:12, 21 June 2008 (UTC)

Yes it should be in common.css for IE6, however we shouldn't specify the font for other browsers because (as you notice) some fonts break for some people. I'll fix it. Conrad.Irwin 23:14, 21 June 2008 (UTC)
Not sure about the lang= attribute, seems like a sensible thing to do though. Conrad.Irwin 23:15, 21 June 2008 (UTC)

Dynamic Navigation Bars

I've been trying to clean up the Javascript at the Irish Wiktionary and noticed that the Wiktionary code for these is different to the Wikipedia code. It seems to do the same thing but in a different way. Anyone care to enlighten me about the benefits of doing it the Wiktionary way? My talk here or at Vicífhoclóir if you don't want to clog the GP. ☸ Moilleadóir 09:40, 21 June 2008 (UTC)

I don't see a lot of difference in the basic code. Note that the second section of the Wiktionary code comes first on Wikipedia, which makes them look more disparate than they really are. Other than that, there are two differences I see:
  1. Wiktionary uses a visual icon to indicate show/hide rather than text. This resulted from extensive discussion over two concerns: (a) that many of our users don't read/speak English very well, and (b) that even native speakers weren't realizing that the nav boxes were expandable. Using the up/down triangles makes a bigger visual impact for new users.
  2. Wikipedia includes additional code to handle cases where one navigation box occurs following another navigation box. If just one box appears, then the box is displayed in expanded form. If two or more boxes follow each other, they will be displayed initially as collapsed. We've never wanted to do that on Wiktionary, so we don't have code to handle that situation.
--EncycloPetey 19:54, 21 June 2008 (UTC)
As you say, they are very similar, even to the point that some of the comments are still identical on both sites. The Wiktionary NavFrame code is in a right mess (it was copied from Wikipedia in ~2006 and hasn't been touched since) and really needs cleaning up. I had a go at User:Conrad.Irwin/navframes.js, but will have a better go at some point. On second thoughts, are you talking about the difference between Collabsible tables and NavFrames, if so then collapsible tables, use table headers for toggles and table rows for content, while the NavFrames use divs for both. NavFrames are more flexible, though collapsible tables are more accessible (if used correctly). Conrad.Irwin 23:12, 21 June 2008 (UTC)

WT:PREFS

I went to this page and checked the necessary checkboxes to start using it. It seems I can't. It slows down my browser (IE 5.04) rendering it useless. I'd like to uncheck the main checkbox but I can't see them any more. I see only the welcome text and nothing under the horizontal line. A script is running after every click and stops all action for several seconds, then a pop-up reminds me that a script is slowing down the browser. So how do I uncheck the preferences? I cleared the cookies, did not help. --Panda10 19:12, 21 June 2008 (UTC)

You might be able to get a later version of IE for free. Though we need for admins to keep using IE because so many users do, you would probably find Mozilla Firefox better. It works better than IE7 did for me. DCDuring TALK 19:30, 21 June 2008 (UTC)
Mozilla Firefox is free. DCDuring TALK 19:31, 21 June 2008 (UTC)
But in the meantime, we probably should put a warning on WT:PREFS about slowing down IE users. Some folks who use IE do so because they're using a computer that isn't their own and don't have a chhoice about installing a newer version of IE. I've been in that situation many times before, especially when logging on through a school or library computer. --EncycloPetey 19:34, 21 June 2008 (UTC)
Panda10, you may be able to fix the problem by deleting your personal /custom.js. This will delete your preferences file. BUT, please wait for someone who knows more about the technical aspects to verify this, as I am not sure of all the possible ramifications of deleting that file. --EncycloPetey 19:39, 21 June 2008 (UTC)
I installed Firefox and checked WT:PREFS using that - nothing is checked, all checkboxes are unchecked, including the main one. I don't have a custom.js. IE works in other websites, but not in Wiktionary. It still has the 30-second wait after every click and the pop-up reminder. --Panda10 20:46, 21 June 2008 (UTC)
Eek! that's bad, can you remember which PREFS you clicked? You can clear your preferences by clearing your cookies (Internet Explore -> Tools menu -> Internet Options -> General tab -> Delete cookies) - though this will have the annoying side effect of logging you out of all internet sites you are logged into. Conrad.Irwin 23:02, 21 June 2008 (UTC)
I cleared the cookies immediately after this started happening, it did not help unfortunately. I think I checked the main checkbox, the IRC, and the TOC. But if I look at my prefs via Firefox, nothing is checked. So I'm not sure what script is running every time I click anything in Wiktionary, but not on other internet sites. --Panda10 23:48, 21 June 2008 (UTC)
Ok, PREFS are stored in cookies, and none of the javascript is loaded if the cookies aren't set, so you may have visited the PREFS page since you cleared them. (The problem does seem to be with WT:PREFS, though I've not worked out exactly what, clearing cookies fixed it for me) Conrad.Irwin 00:12, 22 June 2008 (UTC)
I have found that IE more or less freezes if I use it to connect to Wiktionary while Firefox has me connected to Wikt. DCDuring TALK 00:30, 22 June 2008 (UTC)
I cleared the cookies again and everything that can be cleared on that IE page, temp files, stored passwords,etc. This solved it. Deleting cookies alone was not enough. Ok, I am all set. Thanks. --Panda10 00:33, 22 June 2008 (UTC)
Let this be a lesson to you about using MS products. [2] --EncycloPetey 01:24, 22 June 2008 (UTC)

Wait, what script am I writing in?

Seeing as we've been standardizing our script templates as of late (i.e. to the ISO 15924), I was wondering if {{polytonic}} should still be used, or if we should simply use {{Grek}} for both grc and el. Ultimately, I am far too naive on the matter to have an opinion one way or the other. I just wanted to get the opinion of my betters. Many thanks. -Atelaes λάλει ἐμοί 01:16, 22 June 2008 (UTC)

The difference is the use of font "DejaVu Sans" in preference (see Mediawiki:common.css), apparently this is needed for Ancient Greek, but not wanted for Greek. See Rod's notes at {{polytonic}}. But as with all these things, they can be usefully revisited as the browsers evolve. Robert Ullmann 15:10, 26 June 2008 (UTC)

Recent changes

On my screen setup the prefix information of "Recent changes" now takes up the entire screen and I have to scroll down to see any action. "Utilities", "Welcome" and "Wanted" each take two lines (each by just a word or two) and the new box around the "Recent changes" options fills the rest. Can anything be done to clean it up? SemperBlotto 07:27, 26 June 2008 (UTC)

  • Thanks to Conrad.Irwin I can now see the latest one and a half changes! SemperBlotto 11:44, 26 June 2008 (UTC)
The "GO" button really ought to be on the same line, doesn't need a line by itself Robert Ullmann 11:58, 26 June 2008 (UTC) (they explicitly use a table to use another line, go figure ...) Robert Ullmann 12:12, 26 June 2008 (UTC)
Add to your monobook.css:
fieldset.rcoptions {
  font-size: 80%;
  }
and it will be smaller. You can even use display:none; to make it go away; but then you have to have your own nav bookmark or whatever as desired. Robert Ullmann 12:12, 26 June 2008 (UTC)

Btw: has anyone else noticed that clicking on "50" (or explicitly putting &limit=50 in the URL) gets you the number of changes specified as your default in preferences, not 50? Or is it just me? If anyone else sees it, I will trouble myself with bugzilla ... Robert Ullmann 11:58, 26 June 2008 (UTC)

Bug confirmed. I tried asking in #mediawiki about moving the "Go" button, but they said moving it breaks some extensions... so we're stuck with it at the moment. Conrad.Irwin 12:03, 26 June 2008 (UTC)
thanks Robert Ullmann 12:12, 26 June 2008 (UTC)
bug 14659 Robert Ullmann 00:12, 27 June 2008 (UTC)

SB: if you put the following in monobook.css, you'll probably be fairly happy :-)

fieldset.rcoptions {
  font-size: 90%;
  margin: none;
  padding: none;
  border: 0px;
  }
fieldset.rcoptions legend { display:none; }
fieldset.rcoptions table { display:none; }

(unless you use the NS selection) Varying the font-size as you please. Robert Ullmann 14:51, 26 June 2008 (UTC)

If you want to lose the horizontal rule as well, also use:

fieldset.rcoptions hr { display:none; }

Robert Ullmann 15:01, 26 June 2008 (UTC)

I do not possess (and never will possess) a monobook.css - I like my Wiktionary to look like that of our users. However, I have poor eyesight and have View => Textsize set to "larger" - so I am not about to reduce font sizes! SemperBlotto 07:39, 27 June 2008 (UTC)
I agree, I do the same; not using monobook.css or WT:PREFS except for experimenting. However, RC is an infrastructure page, not a content page, so I'm not worried about it in this case; I'll probably keep the .rcoptions class changes. Robert Ullmann 16:19, 28 June 2008 (UTC)

FYI: the RC fieldset code has been removed (rev 36523, 21 June) it will go away when the running MW s/w is updated. Robert Ullmann 13:27, 29 June 2008 (UTC)

Newbie question about inflections

Over in the Russian-to-English section of en.wiktionary the veterans are saying that every inflected form needs its own entry, and that we eventually hope to get virtually every Russian word that is in print (or used in speech) into en.wiktionary.

Great, but there are something like 120,000 to 150,000 lemmas in Russian with an average of about 15 parts of speech each. This implies two million entries. In one sense this is an overstatement; for example with (gramatically) feminine nouns the singular prepositional and dative case inflections are usually homonyms. Nevertheless this needs disambiguation, so the workload probably isn't reduced.

If it takes a human ten minutes to set up a minimal entry for an inflected form, the total workload computes to 167 man-years (in addition to the workload of creating lemma entries).

However lemma workups have inflection tables. If the table templates have metadata describing the contents, it seems to me that preparation of entries for inflected forms can be automated, saving that huge amount of scutwork.

If I'm reinventing the wheel here, can someone please direct me to that discussion? LADave 09:11, 29 June 2008 (UTC)

In fact, we often do use bots for that. For example, thousands of Spanish and French verb forms have been added by bots. You just have to learn how to make a bot and get permission to run it. —Stephen 16:21, 29 June 2008 (UTC)

Getting the length of a parameter in templates

Is there are way to get the length of a parameter in a template? I am updating the Hungarian noun declension templates and would need to know when the last latter is a double-letter (still one sound) such as cs since in some cases the last latter is doubled but not fully, only the first character (ccs). I am trying to avoid adding yet another parameter with this. Thanks. --Panda10 20:16, 29 June 2008 (UTC)

I don't think that this is possible with our software- see Template:es-conj-ar (u-ú)- the input can't be broken up, it has to be entered as 2 separate inputs. Nadando 20:19, 29 June 2008 (UTC)
Should be possible with StringFunctions, which we don't have (yet). There are lots of other good things we'd be able to do with StringFunctions, too.—msh210 20:28, 29 June 2008 (UTC)
Tim Starling has stated that he will not install StringFunctions as it is very poorly designed; I concur. It also has the problem that it will result in a lot more people using #if and #switch on the results, with no understanding that all branches of conditionals are fully evaluated. Thus a huge amount of additional parsing overhead. It would be good to design something better. Robert Ullmann 14:57, 3 July 2008 (UTC)

July 2008

Minor AF changes

User Panda10 (new sysop!) noted that AF (at tanti) did not understand

==Hungarian

which should be interpretable. I improved the header parsing a bit, and arranged to make AF save this edit.

Note that the way AF works is by reading the entry, setting the edit summary to blank, and then parsing, adding phrases to the edit summary for each non-"minor" change. At the end, if the edit summary is nonblank, it saves the edit. This keeps it from endlessly fiddling with single blank lines and such.

I've changed it to add to the edit summary, thus saving, in three additional cases: (numbers are entries in 13.6.8 XML)

  • when a header is reformatted (as above and other cases) (5145 plus some not caught in prescreen)
  • when a category link is canonicalized ("category" to "Category", spacing) (6148)
  • when multiple blank lines, enough to affect rendering, are removed (652)

None of these (except the improved header parsing for a few cases) change what AF does in edits, just saving more edits. Robert Ullmann 14:53, 3 July 2008 (UTC)

Dictionary:Wikitext style

Update and write-through of Connel's doc from two years ago. Please read. Robert Ullmann 15:29, 3 July 2008 (UTC)

Subcategory listings

I see that sometime in the past 24 hours, a change has been made in the way subcategories are listed under categories. A parenthetic number after the subcategory name lists the number of sub-subcategories (a nice feature, I suppose). However, the subcategory name also is bolded. This is a problem. It is a problem because some of our Asian-language categories include CJKV characters in the category name, and the names of these categories become unreadable when bolded. Can someone undo this change for us? --EncycloPetey 03:47, 4 July 2008 (UTC)

We can add:
.CategoryTreeLabel { font-weight:normal; }

if wanted. There are a number of nice features; try mousing over the displayed number. It would be better if the displayed number was the number of entries, not sub-cats. Which cat names are a problem? There are a couple in Japanese, but other than that where? We do try to keep category names in English, right? (;-) Robert Ullmann 18:05, 4 July 2008 (UTC)

There are some in Korean as well (Category:Korean adjectives ending in 하다) and there might be some in Chinese. We do try to keep category names primarily in English, but when categories are for words derived from certain roots, or words with a particular inflectional pattern, or words containing a given suffix, etc., then it is not unusual for part of the category name to include said root, a sample word or ending, said suffix, etc. --EncycloPetey 01:53, 6 July 2008 (UTC)

850,000

Entry is taus by Jyril Robert Ullmann 17:29, 6 July 2008 (UTC)

Yeah! Thank you for keeping track of these; I've never gotten the hang of doing so. --EncycloPetey 20:29, 6 July 2008 (UTC)

name and order of scripts in Serbian translations

Serbian is written using two scripts, Cyrillic and Latin/Roman. In translations sections, the format is to have the language name "Serbian" followed by the translation in one script and then the translation in the other script, each on a separate line.

However, there appears to be no standard regarding the order the scripts appear in, although Cyrillic first is more common. Nor does there appear to be convention regarding what the non-Cyrillic script is labelled as, for example in the entry vermilion, the Serbian translation of the colour is labelled "Latin" for the noun sense and "Roman" for the adjective sense.

For the purposes of standardisation, I would like to propose that we agree on one order and label and gradually convert all entries to match it by adding to AutoFormat's existing translation table sorting code (I have not asked Robert Ullman about this, but I presume it would be a simple addition to the code).

Regarding the order, I believe that Cyrillic should appear first both as this is already the most common, and also because it is alphabetically before either Latin or Roman.

I do not have any preference regarding whether it should be Latin or Roman, nor do I have any feel for which is the most common. I do though believe we should pick one and stick to it to avoid situations like at vermilion. Thryduulf 14:30, 8 July 2008 (UTC)

I believe we already had a conversation about naming the non-Cyrillic script, and decided on "Roman" to avoid confusion with the language Latin. All the Serbian inflection templates use "Roman" for the non-Cyrillic script, and Dijan is consistently unsing "Roman" these days. I expect that the uses of "Latin" for Serbian translations are remnants of an earlier time. --EncycloPetey 17:55, 8 July 2008 (UTC)
Yes, IIRC I was asking then about "Latin/Roman spelling" as a header. Roman is a better choice, even given the script is named Latin (e.g. ISO 15924 Latn). The larger question here is why Serbian is using two (three) lines for this; Japanese has three scripts, and the Chinese languages 2-3 (sim/trad/pin), and we (usually) show them on one line.
And yes, I can add some rules to AF; but might be simpler to 'bot any existing ones with 2 regex rules (one to sub/one to sort). Are we seeing new ones, e.g. new "errors"? Robert Ullmann 16:46, 9 July 2008 (UTC)
Yes, the excessive three-line translation is the larger question. When I'm in the mood to clean up translation tables, I reformat Serbian translations to be on one line, e.g.:
* Serbian: {{t|sr|sc=Cyrl|нешто|n}}, {{t|sr|nešto|n}}
It's one of the rare situations where I include a script without a transliteration in {{t}}. It reads pretty clear, no? Rod (A. Smith) 18:44, 9 July 2008 (UTC)
But wouldn't it look silly for Serbian translations lines which list 2-3 translations of the English meaning to consecutively be spelled in alternating scripts? Perhaps modifying {infl}'s logic to support linking Serbian Latin transliterations (like you'd be writing {{t|sr|нешто|tr=[[nešto#Serbian|nešto]]}}) ? --Ivan Štambuk 19:47, 9 July 2008 (UTC)
But the problem is that they're not transliterations; they are actually alternative script spellings. If we put one of the two script forms into parentheses, it will look like a value judgement on our part as to which is the "standard" in Serbian. --EncycloPetey 20:42, 9 July 2008 (UTC)
Well, to me putting them all in one line looks like needless clutter and significantly cuts down the potential space of listing more than one actual translation for a particular meaning. Since there are actually lots of world's languages that are one way one or another (de facto or de iure) written in multiple scripts (usually Latin/Cyrillic in ex-USSR dominated areas, or Latin/Arabic with significant cultural Islamic influence), maybe this idea should be given a little more though outside the confines of ideograms/syllabaries-based scripts where space is less of a practical consideration. Out of billions of pointless and purposeful List ofs on WP, no one apparently seems to have bothered to compile one for languages written in multiple scripts, but wild-guessing the relatively active alphabetic languages on WT this one-line rule would affect Azeri (Latin+Cyrillic), Aramaic (Hebrew+Syriac) and Old Church Slavonic (Early Cyrillic+Glagolitic).
OTOH, I see Japanese translation on house formatted as:
  • Japanese: 家 (いえ, ié)
Isn't this also giving preference to one script over another? --Ivan Štambuk 06:06, 10 July 2008 (UTC)
Not really, since Japanese writing is actually more complicated than that, often with a mix of the two forms of script simultaneously. Only the old words have a short kanji form, and this form is usually preferred as it takes less space, is older, etc. The expanded hiragana and katakana are used for inflectional endings, for words that are rare, and so have unfamiliar kanji to most people, for borrowed words, etc. In other words, this isn't analogous to the kind of situation we're discussing, where the are two complete writing systems, each of which can be used without the other. Japanese requires both systems, often in the same sentence. --EncycloPetey 06:44, 10 July 2008 (UTC)
I think it's just a clarity issue. Having everything on one line (thus effectively removing the script titles) could potentially lead to confusion among readers who aren't familiar with the scripts used by the particular language, not to mention sacrificing quality and clarity for a few lines of extra space. A language like Kazakh, for example, is writtin in three different scripts (Cyrillic, Latin, and Arabic). Taking into account that sometimes the entries include one or more synonyms, the Kazakh entry could see six or more words in the same translation box completely unseparated and unexplained other than the vague "Kazakh" at the start of the line. For (a hypothetical) example:
Either way, it's not a pretty picture. There are currently four words per script for the English word "bicycle" under the Serbian entry. Without the script titles, it would go from looking like this:
to looking like this:
You don't get the full effect of this until you see it with the rest of the translations, but it's enough to want to make you stop reading the apparently endless line of words. --334a 02:48, 12 July 2008 (UTC)
I agree that the long lists of words are off-putting, so I would go the other way to some people here and use the multi-line format for other languages that use more than one script. We're not space limited, so I don't see why we should favour concision over clarity. Thryduulf 12:01, 13 July 2008 (UTC)
It should be done like traditional/simplified Chinese:
DAVilla 10:06, 15 July 2008 (UTC)
Why? I'd say that is actually the worst method suggested here, because it makes it difficult to determine easily where one word ends and the other begins, particularly with unfamiliar scripts. When one link is red and the other blue, yes it can be distinguished, but this doesn't help when both links are the same colour, nor for people who are colour blind, or use alternate colour schemes - on my small XDA screen, it isn't always easy to distinguish between the purple visited link colour and blue existing unvisited links.
Additionally, it doesn't address the comments made by 334a above regarding apparently endless lines of words; it doesn't help the person unfamiliar with the language know which script is which - or indeed make it clear they are in different scripts (which isn't always going to be obvious). or what other difference there is.
I would also not be surprised if it made life more difficult for people using screen readers (although I don't have any evidence of this). Thryduulf 16:03, 17 July 2008 (UTC)
It does address what 334a says, because it is exactly the example s/he gave. Not duplicating information like gender avoids the cluttered look. I would counter that, in contrast, a problem with long lists exists for the split-line version in that the correlations get out of sync, not necessarily wrapping at the same points.
Putting spaces between the slashes, as suggested below, should help a lot. I also like commas except that it overloads that divisor. An example with context (such as regional use) should clearly indicate that the context applies to both forms. DAVilla 06:37, 19 July 2008 (UTC)
I'm not crazy about slashes in general, but I don't think that these should be specific problems. The slash is familiar punctuation in English and other Latin-alphabet languages, it always marks a word boundary, and it works fine with Cyrillic. I don't think locating word endings would be a problem for readers (and I have never heard that screen readers are stymied by slashes either).
Alternatives could be commas and semicolons, interpuncts, dashes, vertical bars, or spaced slashes (but the latter usually represent line breaks):
I also don't mind using brackets. We can make the Latin-alphabet version primary, which is familiar to Wiktionary readers—this would also help differentiate it from transliteration:
 Michael Z. 2008-07-17 21:00 z
The problem with brackets is that it implies the bracketed script is inferior to the non-bracketed one. While for some languages this might be the case, I understand that at least in Serbian neither Latin nor Cyrillic is primary and to say otherwise would not be NPOV.
Slashes usually represent breaks between words in English and presumably at least some other languages that use the Latin script. Is it universal? My uninformed guess is that \ would be a more likely character in right to left alphabetic scripts. Ideographic scripts are not unlikely to use something different. Thryduulf 22:00, 17 July 2008 (UTC)
I concede that brackets do imply some kind of primacy for the first term, and we should be very careful where there may be a national aspect. I would still suggest presenting the Latin first, because it is familiar to en.wiktionary readers, and because the reverse order may imply that it is transliteration rather than an independent orthography. (One of them has to come first, whether on the same line or not.)
We should stick to English punctuation in en.wiktionary, if possible. The unspaced slash represents and/or, but is usually best avoided or expanded into the more graceful A or B, or both. Many readers and writers find it awkward, so they replace it with the spaced slash, which is properly only used to represent line breaks in poetry, lyrics, etc. The backslash (\) doesn't belong in English writing or typography.
Having the two on the same line, with a single gender notation, also helps relate the corresponding spellings—so that in the example it is obvious that dvokolka stands alone. I still think that the comma-semicolon scheme is understandable, unambiguous, and unobtrusive. I'll repeat it, with the Latin first: Michael Z. 2008-07-18 02:25 z

[de-indenting] I think all of these approaches are fine, in that someone looking at these translations will be someone who knows enough of the language to make use of them. I'm not terribly concerned about the reader who can't even recognize the various scripts of the language (s)he's supposedly translating into — but if I were, I think I'd prefer one of the systems that puts the scripts on one line, so that it's obvious which script-A spelling goes with which script-B spelling. —RuakhTALK 00:49, 18 July 2008 (UTC)

Special:Recent changes

When you add a word that has templates within it, "Recent changes" shows an expansion of the template with all the span and other junk. Am I the only one who finds this annoying? You can't see the wood for the trees. SemperBlotto 08:52, 9 July 2008 (UTC)

Yes, just noticed this. It is annoying. (I was about to complain about you subst'ing the it-noun template when I figured it out ;-) I wish we had a much better idea (in general, not just this time) what "they" are fixing or think they're fixing. Robert Ullmann 11:28, 9 July 2008 (UTC)
Or even who "they" are- who controls things like this? Nadando 02:51, 12 July 2008 (UTC)
Seems to have been fixed. Never showed up in Bugzilla to my knowledge. Robert Ullmann 10:13, 12 July 2008 (UTC)

rename&move Special:Random page ?

Does the "random page" link only choose random entries/words? If so, then how about renaming the "Random page" text on the side bar to "Random word" (a la Random article, Random book). Also, it seems to get lost in the middle of all those link in the list too... maybe move to the bottom like in 'pedia and 'books? i hope this is the right spot to write this. cheers. 116.240.241.38 12:17, 9 July 2008 (UTC)

Seems reasonable to me to change its text if it only yields entries. (It's MediaWiki:Randompage, by the way.)—msh210 23:02, 9 July 2008 (UTC)
Done by DAVilla. —RuakhTALK 00:43, 18 July 2008 (UTC)

new colour panel template

hi, i've made a template to help standardise the 'display of colours' in articles for colours. it is Template:Colour panel. the usage instructions are described on that page, and it outputs something like:

vermilion colour:   

it basically creates the panel that was in most of the colours round the traps into a template. sorry but i have no idea where to 'let it be known' that i have done this, so feel free to move this message there, wherever it may be. i don't have time to put it into every single colour (though i did do about 4)...
...but that's why wikis are so-o-o-o good! because now everyone can help everyone else by doing it whenever they feel like it :)

cheerio, 116.240.241.38 12:56, 9 July 2008 (UTC)

Copied to WT:GP. Very nice. Good to move bits of obscure HTML out of the entries into a common template. Thanks. I moved it to {{colour panel}} keeping the redirect. Robert Ullmann 17:00, 9 July 2008 (UTC)
Redirection in place from template:color panel for the benefit of those of us who know how to spell.  ;-) msh210 17:29, 9 July 2008 (UTC)
bloody Yanks Robert Ullmann 22:36, 9 July 2008 (UTC)
hi, thanks for that (lowercase-ification). i've fixed all the existing references to the template in word entries to lower case (just because i am pedantic). p.s. wow, it doesn't take long for the "u"-seless spellers among us to spread their poison, eh?  ;-)  Wanderlust (the artist formerly known as 116.240.241.38) 05:39, 10 July 2008 (UTC)
I should point out that I am originally from Boston (Massachusetts). About "Yankee": to someone outside the US, a Yankee is someone from the US; in the US, it is someone from the North (north of Mason Dixon line); to someone in the North it is someone from New England; to someone from N.E., it is someone from Maine; to a Mainiac, it is a nuclear power plant.
The only people who call themselves Yankees are these guys. Robert Ullmann 11:08, 10 July 2008 (UTC)

default script

Can template:infl and template:term be modified to have a default script based on {{{lang}}}? E.g., in the "else" part of {{#if:{{{sc|}}}|...}} for template:infl, have something like {{#switch:{{{2|}}}|he|yi=Hebr|ru|uk=Cyrl, etc.—msh210 17:45, 9 July 2008 (UTC)

I hope so. At least for some languages, the editor's task in using these templates is redundant and invites error and inconsistency. I don't imagine there are many exceptions where we wouldn't want a language to use its default script.
Thanks. Michael Z. 2008-07-09 18:49 z
There's (currently unused) {{lang2sc}} that was thought for the purpose of providing the default sc= on lang= input, but I think that first the behaviour of {infl} should be discussed as I believe some users have been unsatisfied for un-bolding the Cyrillic headwords (which is what {infl} does with sc=Cyrl). --Ivan Štambuk 19:40, 9 July 2008 (UTC)

favicon

Hey guys. I know this is like ringing up the TV broadcaster to turn the volume down at their end, but can we have a different favicon for Wiktionary?. I use firefox with "faviconize tabs" to save space on the tab-bar, and I normally have at least four wikimedia sites open. It's not a big deal by any stretch, just thought it'd be a good idea. :)

This isn't something that can be changed on-wiki; it needs to be done by the developers. It seems like Dictionary:Beer parlour is a better place to discuss this (and I seem to recall it coming up before). Mike Dillon 02:49, 11 July 2008 (UTC)
Ah. Sorry about that. Cheers for the info
In my humble opinion, Wikipedia should change theirs to the globe. Ours matches our logo :p. Conrad.Irwin 20:01, 15 July 2008 (UTC)

User renames

I'm clearing some of the backlog of user rename requests, many of which are requesting single unified login, but a large number are from unregistered users. Clearly it is not possible to rename a non-existent user (the wiki software rejects the rename request), so what is to be done with these? Is there a procedure here, or do we just contact the users on whatever other wiki they are registered (typically Wikipedia) and tell them just to set up the name they want? Some are usurpation requests, but those are a slightly different matter. — Paul G 10:41, 11 July 2008 (UTC)

Tell the user they are confused. If there is no existing en.wikt user they need do nothing here. Just add that to the CHU page. I suspect that there are confused users asking for usurpation in all sorts of wrong places ... Robert Ullmann 10:02, 12 July 2008 (UTC)

FYI everyone: I am in Kigali, and a bit less accessible. Will be around every day or two though. Robert Ullmann 10:02, 12 July 2008 (UTC)

en-noun

At cargo I added "|-" to add an uncountable use to {{en-noun|'''[[cargos]]''' or '''[[cargoes]]'''|-}} but it isn't showing uncountable, apparently because there are links in the first parameter. I thought this worked. Am I looking at it wrong? RJFJR 16:03, 15 July 2008 (UTC)

obscure case ... you (or somone) is trying too hard with the plural note, instead of using the options: {{en-noun|s|pl2=cargoes|-}} Robert Ullmann 16:56, 15 July 2008 (UTC)
Thank you. I just copied the existing plural into en-noun and added uncoutnable. I need to sit down and really learn the template options like pl2. RJFJR 17:54, 15 July 2008 (UTC)

Bot-assisted addition of Middle Chinese readings of hanzi

Hello, it's been getting a bit slow adding Middle Chinese (specifically Tang Dynasty-era) readings of hanzi (Chinese characters), and I wonder if this could be done assisted by a bot, the way a lot of the CJK data was originally done when the info was dumped into Wiktionary years ago.

The raw data of the Tang pronunciations may be found here:

http://homepages.mcs.vuw.ac.nz/~ray/Chinese/UnihanTang.htm

Two important notes:

1. I just heard via email from the CJK specialist at the Unihan Database that the asterisks that appear next to many of the readings do not (as I had believed, according to standard historical linguistics/phonology practice) indicate that the pronunciations are reconstructed--as apparently they are all reconstructed. Instead, they are used by Stimson to indicate that "a word or morpheme represented in toto or in part by the graph appears more than four times in the 700 poems [of the full Tang corpus analyzed]." The Tang pronunciations are derived from or consistent with T'ang Poetic Vocabulary by Hugh M. Stimson, Far Eastern Publications, Yale University, 1976.[3]

2. The pronunciations, unlike pinyin or Cantonese romanizations, include various IPA symbols such as ɑ (which is not the same as a) and ɛ.

Huge thanks for this; I think that now that we've found the raw data, it shouldn't be too hard for a bot to do a dump of the data into our individual hanzi entries. However, I don't have any idea how to do that.

The bot could be set to overwrite all the entries I've done by hand (a couple hundred at most, I think). I estimate that the raw data list presented above comprises about 4,000 hanzi.

24.29.238.60 19:35, 15 July 2008 (UTC)

Large Arabic entry titles

I just saw this entry at hu:Wikt. The Arabic entry title is very large and easily readable. Is there any possibility that we could similarly enlarge the size of our Arabic entry titles? It would make them easier to read. 24.29.238.60 21:07, 15 July 2008 (UTC)

On further examination, it seems that hu:Wikt has all their entry titles large, as this one. 24.29.238.60 21:08, 15 July 2008 (UTC)

See this discussion aw well. Nadando 04:49, 16 July 2008 (UTC)

Thanks; that seems to be a separate issue, not directly addressing the size of the entry title. 24.29.238.60 07:21, 16 July 2008 (UTC)

new context template

I've moved the version I've been testing and working on for a month+ into place, it fixes a number of things.

  • Does the sub-categorization of context labels as presently set up by default when possible.
  • Does not cat the templates themselves in content categories (user presentation).
  • Fixes missing skey for regional cats.
  • Adds cat= for a fixed category, not modified by language name or code prefix or region. (topcat= has been used for this, sometimes causing odd categories to appear)
  • Does not generate trailing spaces from qualifiers, or spaces before explicit commas. So {{frequently}} is (frequentlyTemplate loop detected: Template:context 1), and {{context|frequently|,|something}} is (Template loop detected: Template:context 1) as it should be.
  • Categories appear in the order specified (they had been inverted by the recursion).

All of the tests in the last weeks have worked, tell me if you observe any anomalies. Robert Ullmann 06:50, 19 July 2008 (UTC)

deitalicizing nonroman scripts in wikipedia template

Whenever we add script calls such as {{Arab}}, {{fa-Arab}}, {{Thai}}, and {{Khmr}} to header templates or etymology templates, they are set up so that they are not italicized or bold. It would be great if someone could figure out how to add the same feature to the {{wikipedia}} templates ({{wikipedia|lang=ar}}, etc.). As it stands, these callouts are often illegible (see for example محمد بن عبد الله). —Stephen 20:25, 19 July 2008 (UTC)

I set it to accept a {{{sc}}} parameter, default Latn. This isn't the best approach, firstly because it doesn't remove the bolding, only the italicizing, and secondly because I'm not sure whether {{Latn}} should really be italicizing its argument; but it was probably the simplest. (In general I think our approach to script templates needs review, but this issue doesn't seem like the best leaping-off point for that.) You can see the new behavior at [[محمد بن عبد الله]]. —RuakhTALK 01:25, 20 July 2008 (UTC)
Thanks, it looks a hundred percent better. The bolding isn’t a very big problem like the italics were. —Stephen 01:29, 20 July 2008 (UTC)
Glad to hear it. :-) —RuakhTALK 02:32, 20 July 2008 (UTC)

Bot requests

Is there a section other than the Grease pit where bot requests may be submitted? Thank you, 24.29.228.33 07:21, 20 July 2008 (UTC)

Well, you could ask a specific user whom you know to be good with bots … but why? Why wouldn't you want to submit your request here? —RuakhTALK 13:55, 20 July 2008 (UTC)

Thank you, I did submit my request here, at Dictionary:Grease_pit#Bot-assisted_addition_of_Middle_Chinese_readings_of_hanzi, with no response. 24.29.228.33 05:06, 21 July 2008 (UTC)

Oh, I see. That probably means that no one felt they had the knowledge necessary to do it. :-/ —RuakhTALK 22:15, 21 July 2008 (UTC)
I, too, have requested bots. Although I received response that the bots would be no problem, no bots were forthcoming. Amina (sack36) 12:52, 24 July 2008 (UTC)

Thank you for sharing your experience. I suppose, like Wikipedia, Wiktionary is a volunteer project and one must expect that individual editors would only do what they feel they're skilled at, or what they enjoy doing. However, at least a response and some projection of how long the task would take from the editors skilled at using bots (which are in fact used on a regular basis here) would be so greatly appreciated. I would propose a "Bot requests" page comparable to that at Wikipedia, where editors skilled in bot operations would evaluate and take care of bot requests in a timely manner, instead of slipping through the cracks, which seems to currently be the case. 24.29.228.33 05:28, 25 July 2008 (UTC)

If you got an account people might be more inclined to consider your requests. Nadando 05:39, 25 July 2008 (UTC)

Thank you for your kind and welcoming suggestion. However, you did not actually address the comment, which would be even more welcome. 24.29.228.33 00:43, 26 July 2008 (UTC)

The Beer Parlor would be an alternate (and perhaps better) place to start a discussion concerning bot status. Once some discussion has taken place a vote needs to happen. However, I think it unlikely that bot status will be granted to a bot without a named owner. -Atelaes λάλει ἐμοί 00:51, 26 July 2008 (UTC)

Thank you. I'm sorry, I was under the impression that some tasks have been done here at Wiktionary via bot. Was I mistaken in this? My request (asking for a bot operator to add all the Tang Dynasty pronunciations for Chinese characters, rather than doing the 4000 by hand) is just above. 24.29.228.33 03:29, 26 July 2008 (UTC)

Oh, I see. My initial impression was that you had a bot, and were asking for permission to use it. However, upon closer inspection, it appears that you are asking someone else to write such a bot. My apologies for not reading carefully enough. While I wish I could offer you a more optimistic appraisal of the situation, my guess is that it's not likely to happen soon. In my experience, bots generally only get written for things that the bot-writer is interested in doing, and are rarely completed per another's request. I hope I'm wrong on this, but I wouldn't hold my breath, if I were you. -Atelaes λάλει ἐμοί 03:39, 26 July 2008 (UTC)

Right, I noted above that Wiktionary seems to operate that way, but I also proposed a new, more efficient manner of operation where bot requests could actually be presented at a new "Bot requests" page, where they would be taken up and implemented in an efficient, expeditious manner, as with Wikipedia. I don't believe there's anything wrong with presenting an idea of how our project could be improved, as that seems to be Wikimedia's manner of operation--constant improvement. Adding all 4,000 characters by hand will take about 100 hours of work. 24.29.228.33 03:53, 26 July 2008 (UTC)

Agreed, the presentation of new ideas is always welcome. However, I think that, in this case, the suggestion is unlikely to work. Here's why: One major difference between Wiktionary and Wikipedia is that Wiktionary has rather more centralized discussions. Nearly all major discussions happen on perhaps a dozen pages of the site. We don't have discussions on the talk pages of entries, but rather bring them to the Tea Room. Nearly all policy type discussion happen in the Beer parlor. Likewise, nearly all technical discussion happens here in the Grease pit. This allows the relatively small number of editors to keep in touch with everyone else. Unlike Wikipedia, we don't have people trying to figure out how to plug into the project, but rather the folks who do put in a significant effort are nearly always swamped simply trying to keep up with the tasks they have already committed to. I feel very confident that if such a page were created, it would simply languish from inattention. -Atelaes λάλει ἐμοί 04:04, 26 July 2008 (UTC)

"Facts"/Trivia articles

I was wondering if there was any desire to get articles created that were about some of the interesting or curious aspects of our language. There are thousands of intelligent minds collected here who have a substantial knowledge of the English language, and they could probably provide the general public with interesting facts that most people wouldn't know. English trivia is not uncommon, but is frequently inaccurate. Just the other day someone tried telling me that the only two words in the English language with all five vowels in order are facetious and abstemious, which as interesting a bit of trivia it may be, it's wrong. With all the knowledge collected here already, I feel like this could be a fun and entertaining endeavor, as well as a quicker process than it may seem. For example, if there was an article listing palindromes, if a fraction of the users here took a minute or two and added whichever ones came to their minds, the article would be quite large in no time. And with time the information will spread and with it a deeper respect for the nuances of the English language to people who may never have thought about it before. Mrdeadhead 05:55, 21 July 2008 (UTC)

I'm not sure what you mean by "articles". On Wiktionary, we are a dictionary and have entries for words. There are a few Appendices out there, but mostly glossaries or pages about pronunciation or grammar. You might create a page in your personal userspace of the kind you have in mind to show us what you mean. --EncycloPetey 08:01, 21 July 2008 (UTC)

MediaWiki:SectionWatchLinks.js

Hey all,

There's been discussion (at Dictionary:Beer parlour#Length and elsewhere) of structuring some of our high-volume discussion pages the way we structure Dictionary:Votes, with the main page being little besides a series of transclusions of individual-discussion subpages. There are various technical issues with such an approach, including the annoyance of watchlisting all the votes at Dictionary:Votes — generally you have to click the section-edit link, then watchlist the page it takes you to.

I've just created MediaWiki:SectionWatchLinks.js, which partly addresses this issue, by automatically adding "watch" and "unwatch" links next to the edit-link of each transcluded section (unless it's a subsection of a section it's already added the same links to); to install it, add importScript('MediaWiki:SectionWatchLinks.js'); to Special:Mypage/monobook.js and then hard-refresh.

Those of you who know JavaScript, please take a look. Feel free to edit it (if you're an admin), or to comment here or at MediaWiki talk:SectionWatchLinks.js.

Whether or not you know JavaScript, please try it out and let me know whether it works for you, how you feel about it, etc. (Once you've installed it, take a look at the [edit] link to the right of the "Install MetaKeywords Extension" header at Dictionary:Votes; it should now be a set of three links, [watch · unwatch · edit].) I've only tested it in Monobook, and only in Firefox 2 and 3, IE 7, and Safari 3.

Possible improvements, if someone's got the itch:

  • A bit of Ajax-iness to identify which transcluded sections are already watchlisted and which aren't, and show only the relevant link. (Unfortunately there doesn't seem to be an API query to see what pages are watchlisted, so I guess the Ajax would have to go after Special:Watchlist/edit or Special:Watchlist/raw?)
  • An all-out MediaWiki:SectionWatchAjax.js that automatically watchlisted every transcluded section of a watchlisted page either automatically, or at the click of a button.

RuakhTALK 17:48, 22 July 2008 (UTC) edited —RuakhTALK 00:45, 23 July 2008 (UTC)

Thank you very much, that alleviates one of the worries I had. It seems to work fine at the moment, but if we're feeling the need for freeping creatures, then I think the first one we need is the "watch all" button. Conrad.Irwin 20:48, 22 July 2008 (UTC)
That's a good idea! I've now stolen it. :-D —RuakhTALK 00:45, 23 July 2008 (UTC)
On second thought, this approach may not be necessary. As may currently (and temporarily) be seen at User talk:Ruakh/Template, we can simply create a new template for such transclusions: rather than putting {{Dictionary:Beer parlour/2019-10-17/title}} in the wikicode directly, we could use something like {{transclude|Dictionary:Beer parlour/2019-10-17/topic}}, which could then add all the links we might want in addition to transcluding the page. (It wouldn't have the locale support that MediaWiki:SectionWatchLinks.js has, and it wouldn't group the links with the edit-button in that convenient way, but who cares? It would work for all users regardless of skin, browser, JavaScript support, etc., which is much more important.) At least this was a fun project, despite its uselessness. :-)   —RuakhTALK 18:07, 24 July 2008 (UTC)

Implementing logged discussion rooms

This is currently only about discussion rooms (WT:BP, WT:GP, (WT:ID)) , request pages (WT:RFD, RFT, RFV) require a bit more thought!


Naming subpages

The bot itself won't care what the subsections are called, allowing people to transclude arbitrary pages from anywhere (for example cross-posting to BP and GP). However the main "option" in naming is whether to include the date before the title of the subpage.

Dictionary:Beer parlour/2008-06-13/Topic one
Dictionary:Beer parlour/Topic two

Depending on which option we select here which type of index (alphabetical or by date or both I suppose) it would be useful to have the bot create. I slightly prefer the second option because it means that if people link to a topic on the beer parlour using the Dictionary:Beer parlour#Title of topic, the archived topic can be found instantly by changing the # to a /, however I know others prefer the idea of prefixing a date. A quick poll might be useful here, or just another opinion. Conrad.Irwin 21:16, 22 July 2008 (UTC)

I prefer the date-based system, since it will reduce the chances of later develioping a duplicate name and the problems that would create. --EncycloPetey 00:54, 23 July 2008 (UTC)
I agree with EncycloPetey. If it's desired for the dateless subpages to exist as well for the reason that you give, then a bot can make those pages be redirects (or date-based disambiguation pages, when topics are duplicated). (I'm actually not sure how much I like an infrastructure that's so dependent on bots, but this is not the detail that worries me.) —RuakhTALK 03:56, 23 July 2008 (UTC)

Current bot behaviour

Well, I thought that a bot to do this would be trivial, but it turns out that there is a lot more to think about than I thought. This is how the current implementation will work (once i've ironed out all the bugs). If someone spots a better way to do anything, please let me know! Conrad.Irwin 21:16, 22 July 2008 (UTC)

  • Sits on irc://irc.wikimedia.org#en.wiktionary and listens for any changes to its configuration page (probably in MediaWiki space for protection).
  • For each page on its configuration page, it will start listening to changes to that page and its subpages.
  • When it hears a change on a subpage that is not on the page it will add a new section to the bottom of the page (adding a new month header if necessary?)
  • In the same edit it will remove any topics that have not been modified for a (configurable by page) length of time.
  • If configured (per page) to do so it will add this page's title to a list of (a configurable number of) "recently archived" topics which can be included at the top of the page.
  • ? It might then (also) add the page's title to a list of "all topics in year or month or an alphabetical index of topics?
  • ? It might then slap an {{archive notice}} on the subpage?
  • To allow for permanent includes on the page, an optional argument can be given on the transclusion.
    {{/The heading | permanent }}
    {{/Notice of pending event | expires=YYYY-MM-DD}}
    However (at the moment) all sections like this will gradually migrate to the top of the page.
    It is also possible to specify a set of pages to ignore changes to on the config page (currently using a regular expression)
  • Every once in a while (probably about 24 hours) it will use the API to reload the ages of all the subpages it is watching, correcting the page as necessary (This is because it is entirely possible that one of the edit messages goes missing). Conrad.Irwin
I think trying to "listen" for changes is trying too hard. It can just run every n hours and look to see what has changed. I'm not still quite sure what the structure is. Presumably a section added to the page (with the + tab) would be moved to a new sub-page?
One way to do the configuration is put that info in the page, including a link to some target page; the bot then looks at Special:Whatlinkshere for the target to find the pages it should be working on. Robert Ullmann 13:00, 24 July 2008 (UTC)

Mouseover

Is there a wiki command that results in a pop-up with mouseover? Wikisaurus is trying to avoid a back-and-forth effect when looking for the right nuance. If we give definitions, what's the use in a dictionary? If we make a link to Wiktionary, it causes the user to go back and forth between the two areas. A mouseover pop-up would be just right. Any info? Amina (sack36) 11:42, 24 July 2008 (UTC)

Do you mean something like this?RuakhTALK 12:38, 24 July 2008 (UTC)
Ooh! Bless you Ruakh! That's just exactly what I was looking for. Amina (sack36) 04:39, 25 July 2008 (UTC)
Hmmm. I'm afraid there's a problem with the mouseover. It only works on comment fields and I need it on a click-able word. Amina (sack36) 05:15, 25 July 2008 (UTC)
So if you use it on the alt text of a link: word eh? What doesn't work? (We can arrange to make it blue again, by taking the colours out of {comment} in a variant template ;-) Robert Ullmann 10:59, 25 July 2008 (UTC)
I've now created {{comment-link}}, modeled on {{comment}}, but I'm actually not very happy with it, because it doesn't respect user stylesheet colors, and it doesn't distinguish visited from unvisited links. Also, I think MediaWiki has an option for redlinks to show with a red question mark following rather than with the whole link red; if so, this doesn't respect that. It might be best to just remove all the specified colors (as Robert suggests), and have the underdotting be black (which looks a bit odd, but isn't too bad: baz; maz). —RuakhTALK 11:56, 25 July 2008 (UTC)
Think you are trying to hard (;-), just take the colours out. The border will be the link colour. foo qoo using the CSS colours. Robert Ullmann 12:15, 25 July 2008 (UTC)
Woah, borders inherit text colors? *is mindblown* Thanks! —RuakhTALK 13:23, 25 July 2008 (UTC)
Yup, the CSS “color” property applies to all foreground elements, including text, borders, outline. Michael Z. 2008-07-25 16:03 z
Note that it isn't inheriting from the text per se, it is that the text and box around it (to which border-bottom: 1px dotted; is applied) are both inside the anchor, within classes a, a.active, and a.new. Robert Ullmann 10:00, 28 July 2008 (UTC)

redirects between case

My automation for deleting the "Conversion script" redirects having crunched through most of the 49,000-odd it was tasked with, I've been looking at what's left. And I have a question:

Do we ever want redirects to an entry that differs only in case?

There are any number of them that are left over from moving conversion script errors back to capitals, or fixing the endlessly recurring new entries with the wrong case (either newbie error, or uncertainty about what should be done).

Should all of them be removed (if not linked-to, of course)? The MW software will take you to an entry from the wrong case from the search box. (e.g. put in "UniTed nATions") What do you think? Robert Ullmann 14:46, 25 July 2008 (UTC)

Yes, I think so, for consistency. Conrad.Irwin 18:19, 25 July 2008 (UTC)
I can't think of any reason to keep them either. --EncycloPetey 20:26, 25 July 2008 (UTC)

Trying some new filters. Will see what it comes up with for a few hours; then I'll let it finish the other run. Robert Ullmann 14:10, 26 July 2008 (UTC)

that was very interesting ... will flood RC for a little while to complete the first task run. Robert Ullmann 22:34, 26 July 2008 (UTC)
Another set of redirects which needs to go away is el/grc words with no diacritics. Bascially, any word composed entirely of Greek characters, containing no diacritics (i.e. accent marks), which is a redirect can safely be deleted. -Atelaes λάλει ἐμοί 01:31, 27 July 2008 (UTC)
Are there many of these? I plan to (after the next XML dump, whenever that is ...) classify all the redirects and see where we are. There are still a number of English redirects of forms hanging out there, as well as any number of things that should be looked at to decide whether they ahould be misspell-of, alt-spell of, or deleted. ATM, I have no handle on how much there is. Robert Ullmann 10:06, 28 July 2008 (UTC)

No, redirects between cases may be needed if the target is mixed case (a capital after the first, but not all caps). The did-you-mean and search engine (go/search) handle it if the target is all caps, all lower, or has the first character "flipped". The search engine also handles Title Case and Title-Hyphen Case for the target. So some redirects are needed (we might consider creating a few as well ;-) an example is that IMDb needs (one of) the imdb and IMDB redirects, else looking up "IMDB" will not find it. Robert Ullmann 14:19, 28 July 2008 (UTC)

Did you mean message

On the page where an entry is not found, when it says "Wiktionary does not yet have an entry for ..."

Where is the code that generate the "did you mean" messages? (I have looked, and I usually know where to look ;-)

It seems to find other entries that are

  • all lower case
  • all upper case
  • given case with first capitalized

but not

  • title case
  • sentence case where given has other capitals

anyone know? Robert Ullmann 13:12, 28 July 2008 (UTC)

MediaWiki:NoarticletextDictionary:Project-Noarticletext{{alternate pages}}{{didyoumean}}. And yeah, it just tries applying each of [lu]c(first)?:. It doesn't even try combinations of these, such as {{ucfirst:{{lc:pagename}}}}; so, [[JAPANESE]] pulls up nothing. —RuakhTALK 15:38, 28 July 2008 (UTC)
Ah, thank you. It would be good to add sentence case in there. Too bad title case can't be generated. (can't get from "united nations" to "United Nations") Robert Ullmann 16:31, 28 July 2008 (UTC)
I added Sentence case, seems to be okay. Robert Ullmann 12:14, 29 July 2008 (UTC)
Cool, thanks! —RuakhTALK 13:41, 29 July 2008 (UTC)

Creating redirects

There are cases, like IMDb, where entries will not be found by either search or links to all UC or all lc, or other reasonable combinations. For example, without redirects, none of "imdb", "Imdb", or "IMDB" would find the entry. Another example it to try linking to "United nations", "united nations", "UNITED NATIONS", none of which work. In this case go/search will work, because the s/w does try Title Case.

It seems to me that we might usefully create redirects in some defined set of cases to make these entries more accessible. Robert Ullmann 12:25, 29 July 2008 (UTC)

It would be better if we got the proper DidYouMean extension working again (as I keep meaning to... ;). This would handle all such cases and more. As an interim measure I don't have a particular problem withe redirects. Conrad.Irwin 11:59, 30 July 2008 (UTC)
Yes, that would be good. I'm just tweaking what exists now (;-). In any case I have set the deletion-process filter to keep any presently useful redirects, i.e. it won't remove anything that will make an existing working link fail. If someone creates helpful redirects (e.g. united nationsUnited Nations then we will keep them for now. (Wish we had TC: for Title Case in the parser functions. ;-)
I might consider creating them on purpose for some titles like van der Waals force and shipshape and Bristol fashion. Robert Ullmann 12:31, 30 July 2008 (UTC)
Well as redirects seem to be acceptable for phrases, I'd go for it. Conrad.Irwin 13:08, 30 July 2008 (UTC)
See User:Robert Ullmann/Entry cases, which has some information about where we are. (or were on 13 June...) The redirects for phrases that we explicitly allow are for variant forms, not variant capitalization. This is issue is orthogonal to phrase/not phrase I think. Anyway, there are 2K+ entries that would not be found by go/search from another capitalization. Robert Ullmann 15:50, 30 July 2008 (UTC)

redirect=no

In the js for didyoumean, the new url uses redirect=no, presumably to prevent looping (in some contrived cases). Since then we've added rdfrom= to the url, and check for it, so it can't loop that way. Meanwhile, if didyoumean finds an entry that is a redirect, the no-redirect keeps the user from arriving all the way at the desired page.

I think it can be removed, and I'm going to try it. Please check this (if this whole thing with js makes any sense at all to you of course ;-) Robert Ullmann 11:55, 30 July 2008 (UTC)

It was deliberately like that to mimic the MediaWiki double redirect behaviour, but feel free to change it if you think it's better changed. Conrad.Irwin 11:57, 30 July 2008 (UTC)
(Hi Conrad!) We have cases where we want to do an auto-redirect and another "ordinary" redirect to get the user to the page. Consider a link to Van Der Waals force, which now works. I think this is okay. (The presentation of the two "redirected from" notes at the top might be tweaked a bit.) This way the dym mechanism can do almost all of what the go/search code does, as it does both steps. (difference is that dym won't find Title Case, unless we provide a redirect) Robert Ullmann 12:17, 30 July 2008 (UTC)

process

To explain the process, what the automation is doing now:

It is looking at all the redirects in mainspace and Talk: using a dump from sometime in March. (That's okay, it has plenty to look at, I'll start it again with a new dump if we ever see one.) The Talk: space really isn't the objective, but not looking at those leaves "orphaned" talk page redirects. It proceeds from longest title to shortest (>3) in alpha (UCS collating) order within each length. (A good idea from DAVilla.)

There are two "cases" it looks at. First: redirects that point to a different case of the same term. Here it checks that the dym (Did you mean) and search/go mechanisms will both find the target if the redirect is removed: i.e. the target is all lower, all upper, the same with first letter inverted, or in Sentence case.

Second: two (or more) redirects to the same target, differing only in case. Here it checks the initial case of the target, preferring to keep a Sentence or all-upper case redirect if the target starts with UC, preferring the all-lower case redirect if the target starts with an lc letter. The same case matching is then applied, to ensure that looking for the redirect form will find the other redirect by dym or go/search.

All this is then re-checked against the current wikt: that the redirect still exists, hasn't changed (or is back to the same), that the other redirect still exists (ditto), that there aren't any internal links that would be broken. Fixing them in some cases, e.g. Transwiki: space and ignoring others (various cleanup lists).

Thus any external link, whether from a sister project, or somewhere else in the net, that was working will continue to work.

It does 5 at a time, and waits an adapted time so that it will be < 10% of RC and not completely flood the deletion log. Also so it does only what I can reasonably look at once or twice a day for possible trouble. You will note that it sometimes turns up entries that were moved to the wrong case, and should be moved back or to a different form. Robert Ullmann 12:46, 2 August 2008 (UTC)

Wikisaurus Template Naming

Background reading: User talk:Sack36#Template:wse-shell.

EncycloPetey has pointed out that the wse prefix in wikisaurus templates such as {{wse-shell}} are probably poorly named, as they seem to imply a language of {{wse}}. Basically, all three letter templates should be reserved for language names, and following that, template names with three letter starts should also be reserved for language specific templates, such as {{grc-verb}}, {{grc-ipa-rows}}, etc. So, Sack36 (who, for those of you unaware, has been forging a major revamp of the wikisaurus pages) is now wondering what the templates should be named, and what the most efficient method of affecting such a change would be. So, to sum up:

Are three letter prefixes on templates like {{wse-shell}} inappropriate (bearing in mind that wse has not yet been assigned to any language yet, that I could find anyway, but conceivably could be in the future)?

general convention

What convention do we want to go with when dealing with this on any similar project?

Since the two and three letter with a dash is used, what if we considered project templates as a whole different critter and use different patterns? e.g.

  1. we could use sequence numbers to designate which project, thus wikisaurus-shell could be either shell1 or 1shell or even 1-shell
  2. we could capitalize instead of separate by a dash
  3. we could make it a suffix, not a prefix
  4. we could make it a four character prefix

convention applied

Poor Wikisaurus gets a new template name... again.

I'm thinking how nice it would be if it were something short and sweet. I'm partial to 01-shell. Amina (sack36) 04:03, 26 July 2008 (UTC)

If so, what would be the most appropriate naming scheme to rename these templates to?
If so, and if so, would any of our resident programmers be willing to save us a whole lot of tedious manual labour and sic one of their bots to the task of implementing these changes at the entry level?

Many thanks. -Atelaes λάλει ἐμοί 03:12, 26 July 2008 (UTC)

Some thoughts: (2) We've generally agreed on Wiktionary not to capitalize templates, so capitalizing would not be the best option. (3) A suffix would spread the templates out in a category, rather than grouping them.
So, what about a 4-char prefix like saur or wksr? --EncycloPetey 05:55, 26 July 2008 (UTC)
I think saur is a good idea. -Atelaes λάλει ἐμοί 06:01, 26 July 2008 (UTC)
Type "sa" 10 times fast and you'll see the reason I'm none too keen on saur. What of the numbered idea? I'm still fond of 1-beginlist or 01-shell. Amina (sack36) 07:27, 26 July 2008 (UTC)
Well, how often would you have to type these templates ten times fast? No, I think it better to keep the templates organized by a sustainable naming system. Rest assured that I have to deal with a few long ones myself, such as {{grc-ipa-rows}}, but it really doesn't amount to much time spent typing in practice. -Atelaes λάλει ἐμοί 07:31, 26 July 2008 (UTC)
it isn't that capitalized names are prohibited so much as that we don't want the Everything Capitalized style of the pedia ... numbers are just meaningless ... people seem to get very fixated on '-' as a separator ... you could just use "ws " as the prefix: {{ws shell}} etc Robert Ullmann 07:41, 26 July 2008 (UTC)
I think we're trying to stay away from the two and three letter prefixes. You have a point about the meaninglessness of numbers. So many of the special characters are used in the wiki language I just don't know what other special characters are open for use.
As for typing these letters fast, it turns out that I will be doing just that. Each synonym and antonym used will have a template attached to it. Since thesauri are traditionally made up of synonyms and antonyms and not a whole lot else, that's going to mount up to a huge toll on my two weakest fingers. If we end up with a finger twister, so be it. I'd just like to avoid it if we can. What about using "roget"? Amina (sack36) 14:18, 26 July 2008 (UTC)
Did you know that it's possible to customize your edittools so that you could input the entire template (including braces) with just one click? So, ease of typing shouldn't concern you, since whatever it is could be entered with a single click. --EncycloPetey 17:16, 26 July 2008 (UTC)
Thanks to you, Petey, I now know that it can be done. I don't, however, know how to do it.
We do seem to be getting a little off topic. From the above discussion it looks like there are five valid suggestions to date:
  1. "saurus"
  2. "roget"
  3. "saur"
  4. "wksr"
  5. use a different separator
Have I left anything out? Does anyone know a separator not in use elsewhere? Amina (sack36) 10:27, 27 July 2008 (UTC)
As I said, just use space as the separator, and use ws or wse or whatever as you please. (It isn't so much that 2 and 3 letter codes as prefixes are reserved, so much as we want languages to use them so that templates for languages aren't all over the name space. There is no 2-letter ws for language, and won't be, since ISO is making no new 2-letter assignments.) Oh, and not "roget". Robert Ullmann 09:55, 28 July 2008 (UTC)

Two letter as in ws shell

Confusion reigns. Wasn't the whole brouhaha about not using two and three letters? EncycloPetey began this thread because "wse-" was a language designation. What am I getting wrong? Amina (sack36) 15:20, 28 July 2008 (UTC)

Robert is saying that you can use ws_name. Don't use ws-name, because then it looks like ws is a language code (even though it isn't, and never will be); and don't use wse_name or wse-name, because wse is a language code. (I mean, I suppose wse_name should theoretically be fine, and Robert's saying it is, but that's just begging people to be confused.) —RuakhTALK 15:42, 28 July 2008 (UTC)
oh! cool! Let's go with ws_name then. Do we need to vote now? Amina (sack36) 16:08, 28 July 2008 (UTC)
Nope, ws_name is the agreed solution. Conrad.Irwin 16:10, 28 July 2008 (UTC)
Not sure where the _ came from? It is just a space (they are the same in entry titles, such as template names. Robert Ullmann 12:27, 29 July 2008 (UTC)
Yeah, they're equivalent in template names (though not, oddly enough, in template parameter names). I wrote spaces here just because ws_name seemed clearer than ws name. (I suppose I could have written {{ws name|…}}, but it didn't occur to me. *shrug*) —RuakhTALK 13:06, 29 July 2008 (UTC)
No biggie. I understood (more or less) what was meant by it. It took a bit for it to sink in, but the job can be done either way with the same results.Amina (sack36) 11:34, 1 August 2008 (UTC)

Help with sign language templates

Hi, all. At Dictionary:About sign languages#Option 2: Hold-move is a description of an academic sign language transcription system and my suggestions for how to convert transcriptions using that system into ASCII strings suitable for entry pagenames. I seek help to simplify the resulting pagenames and to polish the hold-move chart templates. For examples of entry pagenames and hold-move charts using the current (draft version) transcription system, see the sample ASL entries B-In-Vplane-B-Chesthigh-Back Hold Short B-InFinger-Vplane-B-Chesthigh-Back Short B-In-Vplane-B-Chesthigh-Back Short B-InFinger-Vplane-B-Chesthigh-Back Hold (busy), 1-Sfhead-Splane-Claw5-Side-Radial Hold Claw5-MedialSfhead-Hplane-Claw5-Side-Radial RoundHplane-RoundHplane (confused), and OpenA-BackFinger-Mplane-OpenA-Center-Mplane Hold C-Ulnar-Tip-C-Center-Tip Hold 1-Sternumhigh-Vplane Hold (How are you?).

After incorporating your feedback, I hope we end up with a transcription system that is friendly to both editors and readers. If so, I'll request feedback through WT:BP with the intent to finalize and approve Dictionary:About sign languages. Rod (A. Smith) 03:05, 29 July 2008 (UTC)

Firstly, I think this is an amazing achievement thus far. Secondly, I notice that for some of the shorter ones you have sentences describing how to make the sign, yet for the longer ones you have tables - how hard would it be to use the sentences for everything (because I find them much easier to comprehend than the tables). If we are wanting to make the titles simpler, would it be possible to exclude some of the details from it? This might result in a few collisions - as I have no idea about sign language at all, I don't know which detail is perhaps less important. Conrad.Irwin 18:05, 29 July 2008 (UTC)
From the following candidate versions of the pagenames for the three signs above, I've removed the direction both the hands are facing, the location of the weak hand, and the hold segments. Those dropped attributes are crucial phonemes for the proper production of the signs, but they are arguably less important than the ones that remain.
  • B-In-B Short B-InFinger-B Short B-In-B Short B-InFinger-B (busy)
  • 1-Sfhead-Claw5 Claw5-Sfhead-Claw5 Round-Round (confused)
  • OpenA-Finger-OpenA C-Ulnar-C 1-Center (How are you?)
It's something like writing English without spaces, with every second vowel removed, and with b, d, g, v, and z replaced by p, t, k, f, and s. It'ssmethnklikwritnkEnklshwithutspces,wthefrysecntfowlremfet,ntwithp,t,k,f,ndsreplcetpp,t,k,f,ants.Rmofnkthosattrputsmayhfethpenfitfmaknksiknsasertlocte,tspitthefctthatphnemshafpentrppet. Removing those attributes may have the benefit of making signs easier to locate, despite the fact that phonemes have been dropped.
Despite the joke above, dropping the less important phonemes may be the best way to reduce the length of the entry pagenames. In any event, after reviewing several seven ASL dictionaries with native ASL signers, I've learned that their text descriptions and photographs frequently omit or obscure important details. So, while I agree that a text description and photos are important to include, I'm also pretty sure that a structured, detailed hold-move chart is important to include as well. The hold-move templates I've created take up too much space, though, to fit on a standard resolution monitor screen. I'd appreciate any suggestions or help regarding reducing the overall size of the charts, especially their heights. Rod (A. Smith) 02:14, 31 July 2008 (UTC)
And, by the way, Conrad, in case it's not clear, I appreciate your feedback above, too.  :-) Rod (A. Smith) 02:21, 31 July 2008 (UTC)

OK. I've cut down on the attributes represented in entry pagenames. The result almost reads well:

Any other suggestions? Rod (A. Smith) 22:12, 3 August 2008 (UTC)

Inconsistency in latin verbs

Latin verbs should be first-person-sg entries. However, some verbs, like volvo/volvere, just have it the other way round. There's also the case of eo/ire, where both have a conjugation table. Shouldn't they comply to the standard way of dictionarizing Latin verb entries? —This comment was unsigned.

  • Yes. We're working on it. But with so few Latin editors it takes a while. Can you help? SemperBlotto 17:15, 29 July 2008 (UTC)
Note: At this point most entries for first, second, and fourth conjugation Latin verbs have had this problem corrected. Most of the remaining problems are verbs of the third conjugation, like volvō. The problem may be fixed entirely within the next month or so. --EncycloPetey 16:15, 30 July 2008 (UTC)

The API is dead! Long live the API!

The old query API (query.php, as opposed to the newer, but still fairly old, api.php) is being killed at the end of August. I don't think any of our infrastructural scripts are using it, but if anyone knows of any, please say so. For more information, see <http://lists.wikimedia.org/pipermail/mediawiki-api/2008-July/000620.html>. —RuakhTALK 23:44, 30 July 2008 (UTC)

Asterisks in page titles

I was wondering if there is any community consensus regarding asterisks in page titles? My query arose upon realizing that the page f**k had been blocked from creation by Connel MacKenzie with the summary "bad entry title". Discussion with him about it doesn't seem to have gone anywhere (see User talk:Connel MacKenzie#f**k for more information), so could I get some information here? Thanks, --Teh Rote 01:48, 31 July 2008 (UTC)

I would favor complete orthographic freedom, but not at a high cost in terms of technical effort, server utilization, contributor effort, or user confusion. I would need to hear something explicit and specific about the costs to weigh them against the benefit. How many CFI-meeting entries do we believe would be added as a result of allowing asterisks? DCDuring TALK 08:10, 31 July 2008 (UTC)
There be a lot of bowdlerization what goes on, so I'd image that most vulgar slang can be written with asterisks in several places. I have no problem with including asterisks, and can think of no obvious technical restrictions. Conrad.Irwin 08:30, 31 July 2008 (UTC)
I agree with DCDuring and Conrad.Irwin. I think the problems that Connel MacKenzie refers to are mostly downstream problems — problems in mirrors, programs that use our site as a data source, etc. — and while those are definitely worth consideration, overall I think that they should be expected to match our behavior rather than vice versa. (By the way, we do have [[*]] itself, though it's woefully incomplete, and [[*nix]], but until just now, it had formatting problems due to the way {{en-noun}} works, which we can take as a tocsin.) —RuakhTALK 09:48, 31 July 2008 (UTC)
Oh, yeah, and we have [[Category:*Topics]], plus counterparts for many languages. —RuakhTALK 09:49, 31 July 2008 (UTC)
If I understand Connels' concerns correctly, the problem is not so much the presence of asterisks in the pagenamws, but only when they occur in the center of "words", as this throws off searches. So, entries where an asterisk separates two words, or appears before a word, or alone, should not cause the probelm. But, having an asterisk in the middle of a "word" does cause search problems. --EncycloPetey 17:43, 31 July 2008 (UTC)
Asterisks are also used to indicate that a pronunciation is reconstructed. 24.29.228.33 17:53, 31 July 2008 (UTC)
I've created User:Rodasmith/test*asterisk. Mediawiki locates it as expected when I type "User:Rodasmith/test*asterisk" in the search box and click "Go". It fails to locate it when I click "Search", but so what? That hardly seems like a justification for barring an entry if it actually meets CFI. That is, if authors use f**k enough, we should have an entry on it. If some search engines fail to locate the entry, big deal. Rod (A. Smith) 02:34, 5 August 2008 (UTC)
You didn't wait long enough; the search index isn't updated in real time. It works now. (checkbox for User namespace of course). AFAIK know there is no technical problem except as noted above an oddity with template parsing where initial * and # are treated as being at the start of a line. I don't think Connel's use of "bad entry title" was a reference to a technical problem (note that Connel created *nix ;-), but rather the form with the *'s used as a bowdlerization. (a title like "Enterprise (series)" would also be a "bad entry title" here.) Robert Ullmann 14:02, 5 August 2008 (UTC)
Good, so Mediawiki seems tolerant of asterisks, and cuil and google:"f**k" at least suggest that f**k is used frequently enough to merit an entry. I don't know how many of those results are for other strings, e.g. . The results need sifting through to determine how widespread f**k really is, but unless anyone presents a solid reason not to create the entry, process allows anyone to do so. Of course, the creator or anyone else may RFV or RFD it, so it wouldn't hurt to find three decent quotations.  :-) Rod (A. Smith) 03:21, 7 August 2008 (UTC)
To Robert Ullmann: Based on the comments Connel made on his talk page, it seems he was referring to a technical problem. It may have been that he was referring to the googleability of the term, as the asterisk seems to be a "wild card" on the search engine. However, if it's common enough to be included (which seems pretty clear), then an administrator should unprotect the title from creation. Teh Rote 05:19, 7 August 2008 (UTC)
Note that in computer science, "**" is often different from "*", as "\\" differs from "\". When then entry first caused problems with my tools, I looked at it and discovered it was not only garbage, but garbage from a known-bad contributor (User:Wonderfool.) The normal substitution of profanities is some selection of "!@#$%^&*()" but rarely the same character substituted for different letters - so this is an obviously contrived formation. That isn't how one bowdlerizes fuck in English. Before the vandals go creating this entry again, they need to prove that this is more common than "#&$%" and all others. I've re-deleted the entry. --Connel MacKenzie 16:45, 25 August 2008 (UTC)
Wait, wait, wait. Out of process, you knowingly removed a page that contained accurate, relevant content that is appropriate to a dictionary. Who's the vandal, again? (For the record, I agree that f**k is rare, as bowdlerizations go; but unless the tool in question is both (1) particularly important and (2) particularly difficult to fix, that's not a good reason to rule out an entire class of valid entries.) —RuakhTALK 17:04, 25 August 2008 (UTC)
Wow, I haven't been on in a while. There are a few things I would like to say...
  • First and foremost, who is this Wonderfool character? Without the userpage, it's kind of hard to tell.
  • To Connel: I've tried not to interact with you for that past while, but since you got into this discussion, I suppose it's necessary. Now, since when are there rules regarding bowlderization in English? I'd like to see some evidence for this.
  • To Ruakh: f**k is rare? The citations seem to say otherwise. Teh Rote 20:35, 27 August 2008 (UTC)
Perhaps it's not “the normal substitution”, but I've certainly seen uses like f*ck, f**k, f***, s**t, *ss, etc. Looks like Googling "f**k" with or without quotation marks finds plenty of attestations. I don't see why it's necessary to prove that this orthographic form is more popular than some other one. And obviously it is meant for a different purpose: #&$! inserts generic swearing, while f**k seeks to convey a specific word in a less offensive way—I've seen it used in direct quotations.
Please be specific about the technical problem. If your own tools can't handle some legal characters in a Wiktionary entry, then please fix your tools instead of “fixing” the dictionary. Michael Z. 2008-08-27 21:33 z

(removing indent) I agree with Teh Rote above, "f**k" is (at least in the UK, I make no claims about elsewhere) a very common method of bowlderising "fuck" - I'd go as far as saying it is the 1st or 2nd most common method (the other being "f*ck"). As nobody has presented any actual evidence of any technical why we cannot included it in the dictionary, I have to agree with Mzajac and Ruakh regarding Connel's approach to this word. Thryduulf 22:48, 27 August 2008 (UTC)

Requesting unblocks by blocked users

After having informed a user here the other day of their block, I wondered to myself how it was that they would request their unblock if they wanted to contest it. Over on Wikipedia, a blocked user is allowed to edit only their talk page, on which they can ask for unblock. However, their talkpage is protected if they misbehave there, or if they use the template over 3 times.

I wanted to find out if a blocked user here had the same option, so I created a new account, and I asked Conrad.Irwin to block it. Interestingly, once I was blocked on it, and tried to edit a page, I was told that if I contested the block, I should speak to an admin about it. However, when I tried to edit my talk page, it was not possible to do so. How exactly is the user supposed to contact an admin, or anyone for that matter, if they cannot edit their talk page?

Since I understand that Wiktionary doesn't have so much time and labor as Wikipedia, I acknowledge we can't afford to have that degree of leniency to allow them to request unblock 3 times, but I think we should still be at least giving them 1 time - for instance, an administrator is only human, and might think a user is vandalizing even though the user will be able to explain how they weren't, after which only then it would become clear.

Anyway, I am interested to hear responses from other users. User:Nwspel/sig code 11:44, 31 July 2008 (UTC)

When the feature allowing blocked users to edit their own talk page was introduced on en.wp I was not in favour of it. However experience has shown that it is not abused as often as I feared, and indeed abuses do not come near to outweighing legitimate uses. So I would support its introduction here. Thryduulf 14:50, 31 July 2008 (UTC)
The block message says pretty clearly that you can contact the blocking admin by email, explaining that one has to set their own email address in preferences (which can be done) before sending. In two years, I've only had two blocked accounts take the trouble, one I immediately unblocked, the other is a 14-year old in Toronto who sent me an obscene message. If they don't want to trouble to send email, why should we bother? Robert Ullmann 15:00, 31 July 2008 (UTC)
Most administrators don't have their email address written on their userpage, so most of the time, a blocked user is not able to email anyone. User:Nwspel/sig code 15:05, 31 July 2008 (UTC)
They don't have to. From a user page there is a link allowing you to send an e-mail via the WM software without even knowing the receiver's email. --EncycloPetey 17:46, 31 July 2008 (UTC)
How about the options at Dictionary:Contact us? That gives them a mailing list and an IRC channel. Conrad.Irwin 15:12, 31 July 2008 (UTC)
No admin (or anyone else) should have their email address written on their userpage. You use the "e-mail this user" link on the left. All admins are required to have a usable email set in preferences. And blocked users are only prohibited from sending email if that box is checked when blocking, the default is not checked. Robert Ullmann 15:14, 31 July 2008 (UTC)
I will make it clear that users can do this in the blocked template. User:Nwspel/sig code 15:51, 31 July 2008 (UTC)
I've tried to clarify Mediawiki:Blockedtext - does that look good enough or do we want more explanation? Conrad.Irwin 23:32, 31 July 2008 (UTC)
Seems good. User:Nwspel/sig code 08:13, 1 August 2008 (UTC)
This is only good if we actually want unregistered users to be contributing. Given the effort involved in patrolling and the bad PR en.wikt seems to have gotten in handling new users, I'm not sure that, as a community, we really want users to contribute, especially unregistered ones. They tend to make a mess requiring lots of cleanup. They don't read our copious documentation. Perhaps we already have more than enough contributors. Should unregistered users be allowed to edit principal namespace page or, indeed, any pages? Should registered users be required to prove themselves by making proposed changes on talk pages for approval by one or more admins? Should only whitelisted users be granted the privilege of editing principal namespace pages? Do we need votes? DCDuring TALK 18:19, 25 August 2008 (UTC)
I don't think the Wikimedia Foundation would let us make any of the changes you're suggesting — and I wouldn't want it to. There are many models of how a wiki can work, and many (most?) of the world's wikis are restricted in some form or another, and that's totally fine; but the WMF wikis aren't, and I don't think they should be. —RuakhTALK 22:02, 25 August 2008 (UTC)
I think that our current practice isn't broke and doesn't need fixing. Each edit is judged on its own merits. New users make more bad edits that experienced users and their edits tend to be deleted or undone more often than those of experienced users. Users only get blocked if they seem to be deliberately offensive, stupid, disruptive etc - and they know what they are doing so don't need to be pre- or post-warned. Badly formatted or worded edits tend to get fixed more often than rejected out of hand, but most of us haven't got the time or inclination to act as nursemaids to new users. SemperBlotto 18:59, 25 August 2008 (UTC)
I have had users request unblocks in a number of ways, Email this user, OTRS, via a sock on my talk page and on the mailing list. I think we are easy enough to get a hold of. - User:TheDaveRoss/sig 19:26, 25 August 2008 (UTC)
Agreed. However, I strongly feel that the bit about emailing the blocking admin should be reinstated into the block text. Conrad.Irwin took it out recently, but I feel that that's fairly important. -Atelaes λάλει ἐμοί 19:39, 25 August 2008 (UTC)
Making it easy for users to protest blocks is what we need, despite the risk of it being an outlet for trolling. If blockers don't want to get and respond to such e-mails, then users need easy ways to escalate. I would argue that such dialogs ought to be visible for all (or all admins, all checkusers, or some other group). (There is a good argument to be made that such a group ought not to be very big.) Perhaps more than one member of the group should be authorized to respond. The human anger response (by both blocker and blockee) would sometimes make the blocker one of the worst responders to an objection to his block. DCDuring TALK 19:53, 25 August 2008 (UTC)
Sounds a bit like you are describing m:OTRS to me. I've re-added the "E-mail this user" link to the block message, I removed it because I thought it made the message clearer and it doesn't work for anonymous users (who make up a substantial proportion of blockees) Conrad.Irwin 19:55, 25 August 2008 (UTC)
Though I remembering looking at it and even considered volunteering for it, I would even now not know to use it, though, if outraged enough, I would figure it out and be all the angrier for the effort. I guess I am thinking of such a system that operated within en.wikt, though in practice that may be the way OTRS works for en.wikt complaints. Once more I am in the position of offering my own ignorance/memory lapse as an illustration of the problem that many users have. I don't really know how to separate mistaken from malicious users, let alone long-term productive ones from others.
I just have a strong sense that our systems, policies and procedures need to be more accommodating of error by passive users, contributors, admins, checkusers, et al. Accommodating does not mean just shrugging one's shoulders at them but recognizing that they happen and devising mechanisms to limit the cost to all involved.
If the OTRS mechanism is effective, then perhaps we should direct users there instead of to blocking admin e-mails or provide it as an option. We should also recommend that users print out the "how to appeal" instructions so they can use them even if blocked. Veteran trolls already know all about such mechanisms. Newer users would not and would be all the more frustrated at believing that they have no avenue to pursue (even when they have read-only access to all of wiki-world). DCDuring TALK 20:36, 25 August 2008 (UTC)

August 2008

Bot task: Removing the arguments from the citation template

Back in the mists of time, {{citation}} took an argument, rather than relying on the name of the page. There are still some number of examples of this spread around. It'd be good to get a bot to 1) Remove the argument when it's identical to the name of the page. 2) List the uses where it's not identical for human intervention. Any bod herders willing to take this up? JesseW 18:24, 1 August 2008 (UTC)

It is possible to inspect the 1300-1400 pages at a rate of about 10 per minute using popups. I looked at about 100 of them and found one rehi that differed in capitalization. On that page the other citations template had the lowercase form in the citation template. What is the harm from having the redundant headword as an argument in the template, especially since there are not likely to be many. For example, I believe that none or the wikipedia citations added by Ullman have an argument in the template. The ones that I had added that had multiple citations templates were attempting to differentiate among spellings, forms, different senses, etc. DCDuring TALK 00:22, 2 August 2008 (UTC)
It does seem like I should investigate the actual use of the argument more; I'll see what I can hack up with api.php to do that. JesseW 01:34, 3 August 2008 (UTC)

XML dumps stuck again

And based on the track record, when Brion Vibber "resets" them again, we will be on the ass-end again, waiting WEEKS or MONTHS for a dump.

Yes I know there are problems; but these are queuing issues that ARE FUCKING TRIVIAL to fix, but we get NOWHERE. What does it take to get them to ACCEPT HELP?

(shall I declare /rant now? ;-) no, not quite yet ...

Think I should apply for a WMF job? maybe help clear the two+ year queue of bugzilla bugs that haven't been answered?

Dunno. Why can't the Cantonese projects be moved from zh-yue to yue after 19 months pending?

Why can't we get a dump that takes a few hours for two months at a time? Why is the pending complete dump of the en.pedia December 24th 2008, with the date for the 7z complete next [imaginative expletive deleted] northern hemisphere spring?

WTF? Robert Ullmann 23:28, 1 August 2008 (UTC)

you should look at the dumps ... the entire current version took 5 hours 11 min, with all the talk pages etc half a day. With all the history six months? something is wrong. And needs fixing.
(note my SO went to hospital—do not know which—at 9pm, 6 UTC, have heard nothing yet; so I am sitting here at 3am local knowing nothing) Robert Ullmann 00:00, 2 August 2008 (UTC) did get an SMS, okay for now. Robert Ullmann 00:24, 2 August 2008 (UTC)
Brion says they are unpacking some new disks etc and when all that is set up it should be better; but the process still has horrible problems. Robert Ullmann 12:22, 2 August 2008 (UTC)
I noted that the 7 October dump aborted. How wonderful that we have another solution. Thanks RU. DCDuring TALK 11:00, 10 October 2008 (UTC)

Problem with column templates

In the synonyms section of I attempted to distribute the long list spanning three columns. It didn't work too well. Could someone take a look at this? __meco 08:15, 3 August 2008 (UTC)

I've given a shot. Please take a look and see what you think. Also, should the second def be "cease to exist," and not "seize to exist?" -Atelaes λάλει ἐμοί 08:22, 3 August 2008 (UTC)
Both issues are entirely my fault, sorry about that, and thanks for cleaning up the long list with synonyms. I somehow managed to confuse cease with seize; I've corrected it now. Michae2109 13:06, 3 August 2008 (UTC)
"Seize to exist"? I cannot imagine what that would imply. No, it's definitely "Cease to exist". And yes, it looks fine now! __meco 18:10, 3 August 2008 (UTC)

ligatures in Sanskrit text

Hello, I am really embarrassed and anxious because the words I tried to write in Sanskrit do not appear with their proper ligatures - for example for the Sanskrit antecessor of sew - the "च्य" ("vya") should appear as a ligature, i. e. as a sole sign. I noticed a similar bug in the article namaskar too with "स्क". The most flabbergasting, however, is that as I was writing the first word in Wordpad, the two letters did merge and the ligature was available. As soon as I pasted it into the box here, the letters separated and the ligature was gone. I beg you to fix the problem, since ligatures are crucial for numerous languages written in Devanagari, as Sanskrit, Hindi and so forth. (more at Talk:sew) Bogorm 17:01, 7 August 2008 (UTC)

This is more of a Grease Pit issue.--TBC 17:04, 7 August 2008 (UTC)
I am thereby moving it, thank you for the advice. Bogorm 17:18, 7 August 2008 (UTC)
Can you see conjunct consonants here: च्य, स्क, त्त, र्प, क्र ? --Ivan Štambuk 17:44, 7 August 2008 (UTC)
No, they are still separated. I not only do see them as separated, but when I select them, I can select them one by one, which sould not be the case. They should be one characer actually. Thanks for your try to assist. (Blagodarim, is it so in your language?) Bogorm 18:44, 7 August 2008 (UTC)
Then this is an issue with your computer. I see them as unified characters, and can only select them as units. May I ask what browser and OS you're using? -Atelaes λάλει ἐμοί 18:49, 7 August 2008 (UTC)
Unified charactars? only as units? I am really dumbstruck, because that is not the case with me... Well, although I detest all forms of advertisement, this OS and two kinds of browsers - this one and this one. If that can help anyway, I would be grateful... Bogorm 19:10, 7 August 2008 (UTC)
Hmm.....well, I guess I'm not sure. I'm on Vista with FF 3, so it could be the OS, but somehow I think it unlikely. Try taking a look at w:Help:Multilingual support (Indic). There's a lot of good stuff there, including a number of good tests which might help isolate the issue. -Atelaes λάλει ἐμοί 19:58, 7 August 2008 (UTC)
Yes, this problem is in your own browser. The ligatures look fine to me. How about these: च्य, स्क, त्त, र्प, क्र? —Stephen 05:36, 10 August 2008 (UTC)
Well, I had not noticed it until recently, but these ligatures appear properly on this browser, while on the second, which I use predominantly, they are still separated. It is apparently due to the browser how to display them and I can only bewail the users with the second one, however much I am accustomed to it, since they will not be able to behold the Devanagari script properly... (to Atelaes) I do not know whether my second browser is the third version like yours, but perhaps it is not and if in the third version there are no problems I can only be glad for you... Bogorm 09:46, 11 August 2008 (UTC)

Dictionary:Requested entries

"Requested entries" in the navigation box links to Dictionary:Requested articles, which is a redirect to Dictionary:Requested entries, couldn't this be changed so that one doesn't have to be redirected? /Natox 14:15, 8 August 2008 (UTC)

I updated MediaWiki:Requestedarticles-url to fix this. Mike Dillon 14:48, 8 August 2008 (UTC)

template:esbot

There are a large number of Spanish verb form entries edited by user:McBot (owned by user:Dmcdevit, who hasn't contributed since early June) back in April that utilise the apparently non-existant {{esbot:catline}} and also have the balance of square and curly brackets wrong (i.e.
verb=[[{{{verb]]}}}
, which doesn't work and should be one of
verb=[[{{{verb}}}]] or verb={{{[[verb]]}}}
. I'm not certain what the edits were intending to do with these so I don't know how to fix them.

I've only just become aware of them through User:Robert Ullmann/Mismatched wikisyntax#d. Thryduulf 20:26, 8 August 2008 (UTC)

The Spanish verb forms really are a mess. I know I've seen other problems with a few entries formatted by McBot (wrong categories, etc.). Also, no new entries have been created since 2006 when TheDaveRoss created them. So I think we need some kind of new bot (or an old one) to reformat / enter new forms. I don't have the knowledge to do so. Nadando 00:14, 9 August 2008 (UTC)
{{esbot:catline}} got deleted on 22 May 2008 following this "discussion" on RFDO. The discussion doesn't provide much insight on its original purposes. From the examples I checked on User:Robert Ullmann/Mismatched wikisyntax#d, it would appear that in every line starting with {~esbot everything from {~esbot to the end of the line could be deleted without causing any harm to anything. Spanish verb forms would still be a mess but AF could probably improve the formatting quite efficiently. -- Gauss 17:44, 9 August 2008 (UTC)
McBot has fixed a lot of things that were wrong, but also created a few problems; this was a run of "automatic bracket addition" that was not a good idea. When these entries were created I tried over and over to get TheDaveRoss to put in a form-of template that would be left in the entry (e.g. now {{es-verb form of}}), but he added templates for everything else that weren't needed (esbot:catline), and not the thing that was! McBot has mostly fixed that. But as Nandando says, something ought to go recheck all of them. (And not with blind regex rulesets.) In this particular case, the ones in the mismatched report may be the only problem. The "esbot:catline" templates have been removed from others, but since these are badly formatted, they don't result in links to the template, and were missed. Robert Ullmann 17:54, 9 August 2008 (UTC)
Oh, what McBot was trying to do was wikilink the "verb=" parameter in the form of template, so the entry would count in stats, but caught the verb= in the esbot:catline template. (regex not restricted enough) Robert Ullmann 18:02, 9 August 2008 (UTC)

FYI: I have been working for the last day or so on getting AF to hunt down and fix entries with {{{ in them; any number of people over time have not understood that you can't subst: a template with optional parameters unless you use some serious syntax within the template. E.g. is you have a template {new foo} with three parameters, but you don't want to use the third in a particular case, you have to write {{subst:new foo|one|two|}} so the 3rd parameter exists but is blank, else you get {{{3|}}} left in the wikitext. If you want a conditional in the template, it takes much more magic! Go look at the source to {{xhan}} ... but in any case I and AF will be hunting these. (;-) Robert Ullmann 18:21, 9 August 2008 (UTC)

Various entries, including the forms noted, are being collected in Category:Entries with template subst detritus; I think AF can probably fix all of them except a few where someone subst'd a template (King's) that have to be manually redone. Robert Ullmann 14:43, 10 August 2008 (UTC)
AF would be fixing all these, except that the ability to edit a template and have conditionals and categories re-evaluated has been thoroughly broken in the WM software. I suspected as much a few weeks ago, now have essentially confirmed it. (It is also possible the job queue is just solidly stuck, but it seemed to be running down just fine.) Robert Ullmann 17:37, 10 August 2008 (UTC)
Indeed it might have something to do with the job queue, which has always seemed to have some serious structural problems. (How can it wobble back and forth between 96K and 106K, without at the same time getting anywhere?) Robert Ullmann 22:41, 10 August 2008 (UTC)
Apparently I managed to beat on it hard enough (adding and removing text visible on the page may have helped). Or something. Anyway, AF has cleared them, with a little help; anything that it gets stuck on will show up there now. (in Category:Entries with template subst detritus). Is about 1/2 through re-screening the whole DB (as of June 13th, of course). Robert Ullmann 15:23, 12 August 2008 (UTC)

"Anchor points" in definitions

Could someone who knows about such technicalities have a look at User:Sack36's edit to argument and a similar edit to conflict. I don't know what the purpose is, but these edits seem to be forcing inappropriate line breaks in the defns. -- WikiPedant 03:38, 9 August 2008 (UTC)

Presumably the purpose is to enable links like [[conflict#N1]] (which links directly to the first noun definition). I've fixed them to use <span> instead of <div> so they won't cause line breaks, but I'm not sure this is really the best approach, since definition numbers are always in a state of flux. If we want to support that sort of direct-linking to definitions, I think we should discuss how we want to do it. —RuakhTALK 04:14, 9 August 2008 (UTC)
Thanks, Ruakh. Just looks like clutter to me. Maybe an admin should suggest to Sack36 that he cool it in the interim (and also tip him off to the fact that putting 4 tildes in the edit summaries doesn't work). -- WikiPedant 04:46, 9 August 2008 (UTC)

{{polytonic}}

Can anyone tell me why the Ancient Greek characters I see in EditTools look so much sexier than the ones which {{polytonic}} actually displays within an entry? In Edittools they are all curvy and basically look much better; but within real pages the font seems different, much flatter and straighter and just less nice. I'm in Firefox if that makes any difference. Ƿidsiþ 09:37, 9 August 2008 (UTC)

It's because {{polytonic}} has been modified so as to specify fonts only for readers whose browsers have a certain bug, the theory being that browsers without this bug can handle font-selection on their own. (The bug itself actually has nothing to do with poor font-selection, except that both are deemed to be characteristic of Internet Explorer 6.) I don't know whether this theory is valid. —RuakhTALK 17:16, 9 August 2008 (UTC)
Try copying what I've got in User:Atelaes/monobook.css to your own. It's made my Greek characters much less bland, anyway. If that doesn't work, you may want to look at the Ancient Greek section of MediaWiki:Edittools. It's using a font specific formatting, as {{polytonic}} used to. One of the listed fonts is probably the one you're talking about. -Atelaes λάλει ἐμοί 18:31, 9 August 2008 (UTC)

The MSIE bug is described at w:Unicode and HTML#Web browser support, with a couple of references. MSIE picks a font for an entire text block without looking at all of the characters in it. The Wikipedia article hasn't been updated in a while and I haven't been able to do any testing since then, so I have no idea if this still holds true in MSIE 7 or beta 8. Michael Z. 2008-08-09 22:20 z

As far as you're aware, are there any browsers that distinguish passages in polytonic Greek from passages in monotonic Greek — either by recognizing lang="grc" and/or xml:lang="grc", or by noting whether a passage contains any polytonic-only characters — and use appropriate fonts for each? —RuakhTALK 15:09, 10 August 2008 (UTC)
I'm not aware of the specific requirements for polytonic. But I do notice that the three examples at the bottom of Template talk:polytonic have styling which is intended to apply in MSIE only. The three look identical and unbroken in Safari and Firefox on my machine.
I do know that Safari, and usually Firefox, automatically chooses fonts sufficient to display each character on the page, in cases where MSIE displays little rectangles, and drools on its chin a bit. So in Wikipedia and here, even though we have perfectly well-formed and valid HTML pages in Unicode text, we've had to develop, deploy, and maintain a complex array of templates, CSS classes, and categories just to show the letters!
Now some text has to be formatted in a particular font for presentation purposes, like Old Church Slavonic. Well, MSIE is also a bit dim regarding the decade-old CSS 2 standard, so instead of adding a line to the style sheet like :lang(chu) {font-family: <Slavonic font list>;}, we still have to play around with more complex workarounds involving classes and style sheet hacks for MSIE. Michael Z. 2008-08-10 19:34 z
For me (FF3) those three do not look the same. And more generally, I disagree with the view that the purpose of script templates is merely to make characters render; in many or most cases, it's to make to them render readably (and preferably while looking nice, if possible). To take a case that I understand better — many fonts include Hebrew characters, but for most it's impossible to distinguish all the vowels unless you make the text extraordinarily large. (This isn't a problem for most web-sites with Hebrew, because most of them use vowels rarely if ever, but for us it's a problem.) I believe the issue with polytonic Greek is similar; for a reader who wants to distinguish rough breathing from smooth breathing even in the presence of an acute accent, most fonts don't seem to cut it. (This isn't a problem for most web-sites with Greek, because most of them are Modern Greek, which drops the breathing marks, but for us it's a problem.) You accept the need to format Old Church Slavonic presentably, but seem to treat it as an exception, whereas I think it's actually the rule. —RuakhTALK 21:53, 10 August 2008 (UTC)
Maybe there are OS and font issues affecting your display too, I guess. You might try downloading Safari for Windows, and then using the Lucida Grande font for your default (Safari comes with the font, but this Mac guy doesn't know whether it will be available in Firefox or MSIE after installation). Unfortunately, L.G. doesn't have italics. I've found that it renders most international text, including polytonic Greek and Old Church Slavonic characters present in Unicode 5.0. It seems to render everything shown in w:Greek diacritics—I can distinguish the breathing marks, but some are pretty subtle—I'd have to read Greek to tell you whether it is good enough. Turning on font smoothing might help distinguish the breathing marks, depending on the font. Of course, none of this benefits the average reader with default settings in Windows.
Safari/Mac's default rendering of w:Greek diacritics#Lower case (with smoothing for my LCD display). It uses the Lucida Grande font supplied with the OS.
Greek diacritics in Safari.png
I don't know about Hebrew, but w:Hebrew alphabet seems to display nicely, even with all style sheets disabled (I do that using a bookmarklet).
Old Church Slavonic is an exception, because real support for the script only came about in Unicode 5.1 last April, no operating system yet supports it explicitly, and fonts have only started to become available since then. Now there is a real reason to start using the Cyrs script tag. Before that, we didn't use any template for OCS, and it displayed just fine on the Mac. Now we are taking advantage of this to also prefer fonts which include the newly-introduced characters, and also make the display match traditional print typography for OCS.
Regarding the purpose of the script templates, I believe that w:template:Unicode was developed first, specifically to work around MSIE bugs. The framework of templates, categories, classes, and CSS styles and resets were developed from it, and are now implemented separately on many wikiprojects. As far as I can see, every single .IPA, .Unicode, .polytonic, and :lang selector except for .mufi in w:mediawiki:Common.css is intended only to apply to MSIE. From this I presume that display of these kinds of text is acceptable in other browsers but broken in MSIE.
You're right, the script templates don't only make characters render—they also apply the lang and xml:lang attributes, which ought to be placed there for accessibility. But many of our editor hours could have been saved if it had not also been necessary to coddle MSIE. Many megabytes of font specifications could have been left out of web pages, and our style sheets would be simpler and more flexible. Michael Z. 2008-08-10 23:47 z
> From this I presume that display of these kinds of text is acceptable in other browsers but broken in MSIE.
As I said above: that's the theory, but I don't know whether the theory is valid.
As for Hebrew: can you tell the difference between אַ and אֵ? (The former has a line underneath, while the latter has two dots.) How clearly can you make it out? Because without {{Hebr}}, I can't distinguish them at all.
RuakhTALK 00:09, 11 August 2008 (UTC)
At normal text size (13px), they are vaguely distinguishable from each other, but not readable in Safari/Mac. When I hit cmd-plus to bump up the font size by one step to 15px, the dots are perfectly clear. Michael Z. 2008-08-11 00:20 z
Here's what I see (I think the two got transposed when I was cut-and-pasting):
Rendering in Safari/Mac.
  • default size: אַ אֵ
  • <big>: אַ אֵ
  • <span style="font-size:larger;">: אַ אֵ

Conjugation/declension tables for Russian

Why aren't there simpler templates, requiring only what's needed for the conjugation/declension, instead of necessarily requiring the whole table? Most of the verbs conjugate regularly, and most of the nouns/adjectives decline regularly too... The entry for "знать", for example, has every conjugation of the verb in the template ru-verb-1-impf. The Russian entry uses the template Гл1a, which only requires the root зна-. And it gets even uglier for entries like "твой"; here, the whole table is drawn, there isn't even a template...

Shouldn't this template be "imported" (I don't really know how it works) to the English Wiktionary? If it's already accessible, isn't there any way a bot can scan the entries and change them?

Compare the code needed for the declension of "работа":

  • en-wiktionary: ru-noun1|рабо́та|рабо́ты|рабо́ты|рабо́т|рабо́те|рабо́там|рабо́ту|рабо́ты|рабо́той, <br/>рабо́тою|рабо́тами|о рабо́те|о рабо́тах
  • ru-wiktionary: СущЖенНеодуш1a|основа=рабо́т

~> SilvioRicardoC 02:20, 10 August 2008 (UTC)

On the contrary, there is a lot of irregularity in the verbs, and even more in the nouns. Only the adjectives are regular, and even they are unpredictable when it comes to short forms and comparatives. For твой, there are very few words like that, so a template is more trouble than adding a table. And as for the templates used in Russian Wiktionary, they are so difficult and confusing that I can’t work them, and I see a lot of errors there which I cannot fix, since I can’t do the templates. —Stephen 05:29, 10 August 2008 (UTC)
A quick count shows that the Russian Wiktionary has about 368 templates that start with Сущ (=noun?). I don't know anything about Russian declensions, and a don't know to what extent those templates are in use (or just usable) but the figure might indicate that the matter is rather complex. The maintenance of a large number of templates for a similar purpose may also be relatively laborious, and this could greatly reduce the efficiency that may seem to be gained by them. -- Gauss 15:34, 10 August 2008 (UTC)
Similar with Polish. That’s why there is a table in twój rather than a template. —Stephen 16:07, 10 August 2008 (UTC)
Any given language with complex cases should have:
  • a small number of layout templates, one for each table design
  • a reasonable number of templates for regular declensions/conjugations, that use the layout templates
  • one or several templates with a (largish) number of parameters for irregular inflections, that use the layout templates
  • in some cases templates for specific verbs (where there a just a few irregularities) are useful
Under no circumstances whatever should the table syntax be in individual entries. It becomes utterly impossible to maintain. (Suppose you want to change the colour scheme? Suppose you want to change the name of a particular case to point to a glossary entry instead of main namespace; or to a page for that case for that language? Or any of a dozen other things that should be consistent? If someone has subst'd or pasted the table syntax into a bunch of entries to make changes, you are screwed.) Robert Ullmann 17:54, 10 August 2008 (UTC)
That's exaclty what was getting me worried.
Besides the fact that some Russian (and Polish, to some extent) entries are needlessly verbose (there are a lot of russian nouns that conjugate regularly like работа, and, up to now, the existent templates still require the whole conjugation), some entries are laid out in the page itself, without a layout template... It's maintenance hell!
I'm still a newbie here, but it seems like bots are Python programs, right (I mean, they have the whole Turing's Power on their side)? Then, am I right to suppose that a bot could walk through pages and, if well programmed, "templatize" them? Abstracting regularly conjugated words like работа would be reaaally nice. Abstracting tables like the pronoun tables in Russian and Polish (see мой and mój) would be a necessity, as far as I see.
~> SilvioRicardoC 02:09, 11 August 2008 (UTC)
For the record, Polish possessive pronouns use the standard declension table for adjectives now. It is true that there could be more shortcuts for frequent special cases of {{pl-decl-noun}} but this doesn't seem to have discouraged editors to add declensions at all. -- Gauss 16:27, 13 August 2008 (UTC)
Any plans on changing the personal pronouns too? BTW, I was thinking of putting the declension of się in the Polish pronouns appendix, but I wasn't sure if I should put it in the first table (dividing it in singular, plural and reflexive)... Any thoughts on that? Maybe even have the declension tables in every pronoun entries (presence of a declension table in the entry is inconsistent right now: ja vs on)? ~> SilvioRicardoC 20:28, 13 August 2008 (UTC)


Ok, I guess I can create some basic ones. Is there any convention for names I can look at. For example, two common (usually feminine) conjugations are the ones ending in unstressed а (соба́ка, изме́на, мы́шка...) and the ones in stressed а that change root in the plural (зима́-зи́мы, жена́-жёны, теща́-тёщи...). How would these templates be named? ru-noun-f and ru-noun-f2? Of course, things aren't really simple; the biggest problem I can anticipate is ш, щ, г, х, к, requiring the next letter to be и and а instead of ы and я...

The declensions of pronouns could use some love too (the tables are being laid out in the page, no templates). Check out меня, сам, себя, мой, ничто...

~> SilvioRicardoC 20:28, 13 August 2008 (UTC)

Are there any guidelines, or best examples for conjugation and declension templates? I'd like to start working on templates for Ukrainian, but I need a starting point. Michael Z. 2008-08-20 19:04 z

I think that the templates for Polish may be quoted as good examples for declension and conjugation (only pl-conj-ai and pl-conj-ap and their (uncategorised?) shortcuts), at least for the needs of a structurally similar language such as Ukrainian. It seems that there are no guidelines other than the very sensible requirements in this and the following section of this page (mainly by Robert). -- Gauss 16:18, 23 September 2008 (UTC)
Thanks. The Polish example looks like a manageable illustration of the scope of the problem [yikes]. I suppose I'll start with the basic noun declension template first, and perhaps collect wisdom about authoring these templates at Dictionary:Declension and conjugation templates or some such. Michael Z. 2008-09-23 18:22 z

Entries with table syntax rather than templates

split from the preceding section "Conjugation/declension tables for Russian"

  • Not directly related to this - but it would be great if someone could dump the list of all entries sorted by L2 language who use table syntax, for the regular editors to see which entries need clean-up and updating (or that list already exists somewhere?) --Ivan Štambuk 17:38, 14 August 2008 (UTC)
    • Remark to this: I observed that Turkish nouns will need a lot of attention at some point soon (probably more than I could afford anytime soon); they seem to be in a messy state. Quite a few declensions have been added (and subst:ed? or copy-pasted?), very obviously in very good faith. However, discrepancies start already by the number of cases listed and especially their order. Now I don't know anything about Turkish but if someone with at least minimal background could clarify if the figure of six cases (nominative, genitive, dative, accusative, ablative, locative) and their order (listed according to WP) are linguistically correct/standard/accepted ... reformatting could be tackled. Just in case someone feels like it ;-) -- Gauss 18:28, 14 August 2008 (UTC)
The Turkish declension at ev shows the best order. It’s the one I’ve been using and it’s what is used on Turkish Wiktionary. —Stephen 20:47, 14 August 2008 (UTC)
I've now checked all 1000-something entries in Category:Turkish nouns, and none of them is using table syntax any more without being tagged. Quite a few use {{crh-latin-noun}} (a template for Crimean Tatar which has no plural, or no singular) but that's a different cleanup task (where a bot could help a lot). Apart from spurious entries in Category:Turkish declension templates, the problems with Turkish are then mostly fixed or tagged. -- Gauss 17:38, 15 August 2008 (UTC)
    • I'm not completely sure of what you mean by all entries sorted by L2 language who use table syntax, but if you mean "find every entry that uses a subst:ed or copied-pasted table", bots should be the solution. As long as only the inflections were substitued (the table layout remained the same), this should be a pretty straightforward bot job, shouldn't it? Just recognize the table pattern, extract the inflections from it and substitute everything for a template call of the respective language that passes the inflected values as parameters. Now I just don't know who can/will help with this. I suppose there are some policies to use a bot... ~> SilvioRicardoC 20:43, 14 August 2008 (UTC)
Note that this sort of pattern matching isn't trivial; with parser conditionals it isn't just a matter of seeing if the static template text matches the page text. And further: you'd have to look at the version of the template at the time it was subst'd, and then it has to figure out if the current version is still valid (!). The automation would certainly be a lot harder (i.e. more work) than having people who know the language just add the correct template call and trash all the table text in the page. Given that there is an available template. Robert Ullmann 17:50, 15 August 2008 (UTC)
Not bots, but writing a program that will scan for explicit table syntax in XML dump of the database [4] and sort the entries by level-2 ==Language== section on some page for others to see. Technically more inclined folks here regularly do things like that.. (and this should be no problem for any decent CS/E student ;) That way we could see in which languages problem mostly lies, and to what extent bot-replacement is feasible. --Ivan Štambuk 09:09, 15 August 2008 (UTC)
He means something like this:

User:Robert Ullmann/t17

you know, if someone were to write a program to scan the XML dump. Maybe it might look like that? Robert Ullmann 17:22, 15 August 2008 (UTC)
Thank you! Of course this list lists some "false positives" like ucho where the table syntax was intentional to distinguish declension patterns by meaning (same etymology, so it can't be split further up). -- Gauss 17:38, 15 August 2008 (UTC)
Of course it is very much out of date; I noted while randomly checking that you (and others) have fixed a number or them. Now, if we could just nominate smascherino for WOTD. (but no "foreign" words, sadly) Robert Ullmann 18:14, 15 August 2008 (UTC)
Robert, could you generate a page (in my user space) listing all 108 Latin words? Some of these are one-offs, where the inflection pattern is unique to the word, but there are many of these likely to be old additions that need cleanup. --EncycloPetey 19:09, 15 August 2008 (UTC)
Sure, User:EncycloPetey/Latin entries with tables Robert Ullmann 16:07, 16 August 2008 (UTC)

WAP (or other PDA) access to Wiktionary

I was using en.wiktionary.7val for some time to access Wiktionary from my Palm Treo 680.

It was very good, but it seems to have been discontinued.

Does anyone know of a good WAP (or other PDA) interface to Wiktionary?

dda —This unsigned comment was added by Dda (talkcontribs).

I regularly use the standard en.wiktionary.org on my XDA over a GRPS connection without any problems (other than the lack of proper UTF-8 support in the version of Internet Explorer I have to use). Thryduulf 00:01, 12 August 2008 (UTC)


After my initial append (above), I contacted the folks at 7val.

en.wiktionary.7val.com is now fixed and working again.

And to Thryduulf... I guess you may have very cheap data rates, but I pay WAY TO MUCH for data on my phone. Therefore the MUCH smaller pages of en.wiktionary.7val.com and en.wikipedia.7val.com really mean a great deal to me. My phone can handle the full-blown pages just fine... but I don't want to pay for all the extra "guff" that really adds nothing to the experience. ALSO... on a small phone screen, I find the 7val pages much easier to read and navigate. I guess we can just say that we are all very fortunate to have a CHOICE !!!!!!!!!! dda

Use http://ninjawords.com . Conrad.Irwin 08:20, 12 August 2008 (UTC)

RC header links

Gratuitous changes to the links in the RecentChanges page heading in the WM software in the last day or so have broken a number of things, I've tried to keep up. (Of course, there is no warning whatsoever of such things, they are features we should appreciate?) For example, if you have bot edits shown, and click on a number to show, it (now) loses the hidebots flag. The from= (show edits from) is also now broken.

This has broken some of the autopatrol code, and several other things. It is 4AM here, I have fixed what I can, but things keep changing. I will try again when I wake up! Robert Ullmann 01:09, 12 August 2008 (UTC)

Someone was trying to simplify something? Or just restucture code to no point? I don't know; in any case after 2-3 changes over several days, it has arrived back almost where it started. Not quite, to no purpose I can see. Anyway, some automatic patrolling has been broken, if you are/were running Rat Patrol, you need a code fix, replace:
   rclast = re.compile(r'starting from.*?from=(\d*)&amp')

with

   rclast = re.compile(r'starting from.*?from=(\d*)')

and it will work again. Robert Ullmann 13:16, 12 August 2008 (UTC)

iwiki links

Since we have gone an extremely long time without a dump: I am running Interwicket entirely from the same dump, but the current status of the union index of all wikts.

I seriously do not understand what the problem is; Brion said they were waiting on more file servers, but this is a ~1 hour process; even the en.wp all-current dump takes only 1/2 day. There is no reason this can't be done once a week?

Anyway, Interwicket will run (slowly), and perhaps Tbot too. Robert Ullmann 00:55, 16 August 2008 (UTC)

Update: Not running tbot; it is not very effective without a current dump, does a lot of network reads for no useful result. Interwicket is about 65% effective (i.e. ~35% of the reads find entries that were already done), so I am running two threads, about 100 updates/hour. Robert Ullmann 15:13, 18 August 2008 (UTC)

not running someone gratuitously broke Special:Allpages at about 03:00 UTC this morning. (Would it be too much to ask developers to work on the 1500 or so outstanding bugs instead of inventing things to change? *sigh*). Specifically, from=xxx is now broken, lists the all pages page index from that point instead of pages from that point. Robert Ullmann 04:46, 20 August 2008 (UTC)

fixed by changing my copy of the wikipedia python framework to use the API for allpages ... Robert Ullmann 09:06, 20 August 2008 (UTC)

Renaming users

Two users (User:Computer and User:Cool Cat) have requested renames. Currently these pages redirect to the new names, and I get an error saying that the old users do not exist when I attempt the renames. Does this mean they have been done? Does a rename simply move the pages? — Paul G 09:37, 19 August 2008 (UTC)

  • Dvortygirl has already done these. User and user talk pages get moved as part of the process. In this particular case they are a mess, but I don't think the user has any intention of contributing anything. SemperBlotto 10:05, 19 August 2008 (UTC)

I protest the existence of the "sherbert" wiki!

Sherbert is simply not a word!!!!!!!!

Sherbet is a word and in America many people mispronounce the word as if there were an are like "Sure, Burt." The Oxford American Dictionary says clearly "Frequency of misuse has not changed the fact that the spelling sherbert and the pronunciation |ˈ sh ərbərt|are wrong and should not be considered acceptable variants." I don't want to dispute it with them. Sadly, Mariam-Webster has not the same standards and lists the word "sherbert" as a variant of sherbet. However, because en.wiktionary.org treats the entire English speaking community, and only some American dictionaries consider "sherbert" to be a word, and no Oxford dictionary considers it a word (is not the OED the most important dictionary, too?), this wiki should not exist.

This wiki does not even site their source, and yet the allow incorrect English to continue by even considering "sherbert" a word. It's "sherbet" and pronounced "shərbit."

Can I petition the removal of this word from wiktionary please?


-mugwort123456789

First off, en.wikt is a descriptionist dictionary, meaning we don't dictate usage we just catalog it. So when a high percentage of uses are spell or pronounced differently we general note it. If you still feel that sherbert should be removed you may nominate it Request for Deletion. --Bequw¢τ 19:50, 19 August 2008 (UTC)
I have used the word sherbert for about 60 years, and was amazed that the OED doesn't reflect reality. It does have these quotes . . .
  • Under sherbet "1675 COVEL in Early Voy Levant (Hakl. Soc.) 263 Your little sherbert cups and coffee dishes are made often times of the same earth."
  • Under float "A soft drink with a scoop of ice-cream (or sherbert, etc.) floating in it."
  • Under gup "1942 S. HOPE Sea Breezes 36 With little to do except drink sherbert and listen to the gupgossip, which, incidentally, they didn't understand. "
  • Under mocktail "In 12 to 14 champagne or sherbert glasses, arrange fruit..."

SemperBlotto 09:51, 20 August 2008 (UTC)

Tifinagh

Could someone with the know-how please add Tifinagh script to the MediaWiki:Edittools..? Ƿidsiþ 07:50, 20 August 2008 (UTC)

flood flag

Meta is considering adding a "flood flag" capability. In short, this would allow any admin to mark any individual edit as "bot", hiding it from RC. We can, if we wish, do the same, by achieving consensus and begging a developer. WF is one reason not to have such a thing, I suppose. I can't think of another. It would help with old deletions, such as Robert Ullmann's periodic ones. I'm not sure it'd be a good thing, but it's definitely (imo) worth discussion.—msh210 20:54, 20 August 2008 (UTC)

I can't see that this would be all that useful. Most editors likely to "flood" RC already us a bot to do these edits (e.g. Semper and Robert). The only other person who floods RC is Jyril, and seeing those edits are a nice spur to do more. So, is there any real benefit to having this capability? --EncycloPetey 21:03, 20 August 2008 (UTC)
It would not be useful for edits, I agree. It would be useful for deletions and other admin-only tasks that show up on RC (certain moves, for example; but I'm especially thinking of RU's deletions). It would, in short, be a way of allowing an admin to flag himself temporarily as a bot but still be an admin.—msh210 21:15, 20 August 2008 (UTC)
My Italian bot sometimes adds a block of wrong words (operator error) and I have to delete them all. In this case I have always wanted to mark the deletions as minor - to prevent flooding the log. I suppose marking them as a bot would make more sense. SemperBlotto 21:26, 20 August 2008 (UTC)
Hm, actually, what this proposal (on Meta) would do is make a new group, "flood", and allow admins to toggle whether why're in it. Why not just allow admins to toggle admission to the existing "bot" group? Wouldn't that be simpler? Is there a downside to it (relative to the route Meta is taking)?—msh210 21:33, 20 August 2008 (UTC)
Given that some deletions are controversial, I can see a downside to allowing admins to declare themselves a bot... particularly since WF has been made admin not once, but three times. --EncycloPetey 21:35, 20 August 2008 (UTC)
But wouldn't the same downside exist for allowing admins to declare themselves a "flood" (i.e., hidden from RC)? I'm not seeing a difference.—msh210 21:39, 20 August 2008 (UTC)
It would indeed. I don't see any benefit to allowing either declaration, but am seeing downsides. --EncycloPetey 21:40, 20 August 2008 (UTC)
Seems to me this is just a large set of problems waiting to happen. All that is wanted here is "better" filtering of RC, right? Someone added a bug request for a "Hide logs" link in RC, which was shot down as "feature creep" ... it would have accomplished this much more easily. (Has anyone thought about the effect of "flood" on patrolling, etc? Would we need a "show flood" link in RC? ;-) Keep in mind that a block of deletes has to appear in the delete log anyway. If someone has enhanced RC on, it will show as only one line. See no benefit here. I would be surprised if the developers considered it, but then they surprise me all the time. In any event, we should not use it IMO. Robert Ullmann 04:31, 21 August 2008 (UTC)

Broken TOC in Topics

The call to {{categoryTOC-lc}} on the page for Category:*Topics is not displaying properly. I do not know why, since the template itself looks fine, and I'm not familiar with a couple of the items used in the template. --EncycloPetey 05:17, 22 August 2008 (UTC)

Someone has "helpfully" broken PAGENAME in the same way as #switch, so that what it returns is treated as the start of a wikitext line, and parsed. The "*" then creates a list item in the middle of the URL. Robert Ullmann 05:47, 22 August 2008 (UTC)
worked around Robert Ullmann 06:00, 22 August 2008 (UTC)

Template:see

I recently added tistis to en.wikt, which is a Seneca word for woodpecker. The language has ISO code {{see}}, which is of course already taken and is much used. I guess eventually {{see}} will have to be renamed, or maybe merged into {{xsee}}. --Jackofclubs 10:47, 24 August 2008 (UTC)

{{xsee}} works in a slightly different way, (I proposed that they be merged once, for a similar reason, but that did not happen). It seems that we will need to do something about this at some point, and that the current set-up relies on having {{see}} reading Seneca. We have two choices, either change the myriads of templates that use the language-code templates, perhaps to use a prefix such as lang: before the language name. This shouldn't be too obvious to the editors as the language templates should never be used directly anyway. This may be something we want to do anyway, as reserving all short template names confuses those who expect {{tl}} and {{bot}} to work as on Wikipedia (it would also make Special:AllPages/Template: look a bit tidier :). The other solution I can think of is to bot-replace all 42,000 occurances of {{see}} with {{seealso}}. This would take a day or two of intense bot-work. My preferred solution is to bot-replace all occurrences of Template:see soon, and leave a note on the template page explaining the change. Are there any difficulties I have overlooked? Conrad.Irwin 12:09, 24 August 2008 (UTC)
First of all, please note that "language templates should never be used directly" is false: the primary purpose of the templates is in translation tables, where they are to be subst'd, either by the user adding them or by AF. A very large majority of the other wikts use the 2 and 3 letter templates this way, which is why we do the same, and will certainly continue to.
It doesn't have to be that hard. We can use {{iro-sen}} or such for Seneca if we want to (for now). We don't have to worry about iwiki links.
{{see also}} already redirects to {{see}}, this redirect could be inverted. {{xsee}} could be merged in, but is a non-problem.
The last time(s) this was raised the conclusion was to wait until we (someday? finally?) got the Did you mean extension that has been promised forever; which then would mean we could remove most instances of {see}.
There is utterly no urgency, except for [never mind]. We can use iro-sen or something starting right now if we desperately need to code Seneca. Robert Ullmann 12:22, 24 August 2008 (UTC)
One more detail: even if we were to bot-convert "see" to "see also" today, the redirect would have to remain in place for 6-12 months until most editors learn not to use "see" any more; then it could be re-purposed. Otherwise you will drive many people seriously nuts trying to understand why "Seneca" is turning up at the top of the page they are editing. Robert Ullmann 12:33, 24 August 2008 (UTC)
Well, seeing as we have two quite capable bot writers, who have both already completed a task like this, would one of you start attacking {{see}}? I think six to twelve months a bit much. That's something like two or three generations here on Wiktionary. Maybe we could wait a month or two. -Atelaes λάλει ἐμοί 18:28, 24 August 2008 (UTC)
It has nothing to do with how long it takes to do bot-work. It has to do with the simple fact that editors who aren't here every day are going to be turning up over a fairly long period of time, expecting {see} to work. That is, not produce "Seneca". So {see} has to remain a redirect to {see also} (or whatever) for a significant length of time.
Also note that the last time I suggested replacing {see} with {see also} there were objections; I'd suggest waiting to see what others have to say. Adding a convert rule to AF to munch through them, both old and the new ones people will add, is pretty trivial. (And I have another sneaky fix in mind that we could use once most are done.) Robert Ullmann 18:37, 24 August 2008 (UTC)
What about using the new template name {{also}} in place of {{see}}? This would still be intuitive as a name, but would keep the name short and not require remembering whether a space is needed in the template call. --EncycloPetey 00:06, 25 August 2008 (UTC)
I like that. Michael Z. 2008-08-25 06:25 z
Agree. A bot will probably be needed to make the switch, though. Even outright adding instruction to replace it in AutoFormat (because it'll take a while for everybody to really notice, I'd assume) might be a good idea. Circeus 14:06, 25 August 2008 (UTC)
+1, brilliant. —RuakhTALK 14:47, 25 August 2008 (UTC)
I like it. --Bequw¢τ 02:37, 26 August 2008 (UTC)
(my initial reaction to {also} was "yuck", but I know enough to wait a while ;-) Yes, that is pretty good, esp. since one can perfectly well say "also this and that", without the word "see". So it reads well in the wikitext: {{also|Cat|CAT|cāt}} ... we should find out what Hippietrail thinks, he commented before; someone has already left him a note. Robert Ullmann 18:44, 26 August 2008 (UTC)

Process: If we want to convert from {see} to {also}, I'd suggest doing the following:

  • make {also} a redirect to {see}
  • give AF a rule to convert {see} to {also} (and {{see also}} to {also})
  • (forget about it for a while ;-)
  • reverse the redirect (when something like 1/2 done)
  • let AF sort the rest while also handling new additions of {see}
  • somewhere in here, change {see} from a redirect to a bit of magic that returns "Seneca" with no params, and invokes {also} with params (!) we don't want to do this at first, lot of overhead (note that AF will only convert instances with parameters)
  • start using code see for Seneca
  • eventually reduce it to the language template, so that subst'ing it won't make a mess

Along the way, inform people that they should be using {also} instead. But do note that what people see in entries is the most effective way to do this. Robert Ullmann 18:44, 26 August 2008 (UTC)

I am trying this out; created the redirect from {{also}}, and converting some. You can look at the result. (Most amusingly at free which is the first entry in the wikt (mainspace, oldid=23 ;-). Can always go somewhere else. Robert Ullmann 01:52, 27 August 2008 (UTC)
I like the logic of this migration process. So, it wouldn't much matter when a contributor were to switch from using {{see}} to {{also}} as long as it was before the introduction of the magic version of "see". Even then the cost would be limited to the overhead. OTOH, if a user started using "also" it would provide more instances for others to observe and ask about. Cool. DCDuring TALK 02:13, 27 August 2008 (UTC)
It looks like a sound plan to me, but we should also be sure to update style guides to reflect the change. I've updated Dictionary:About Latin and Dictionary:About Hungarian to reflect the change in template name, and Msh210 has done Help:Internal links. --EncycloPetey 03:04, 28 August 2008 (UTC)
Note: AF also has rules for {{see also}} and {{See}} (both redirects to see) Robert Ullmann 12:00, 27 August 2008 (UTC)
Would it be possible to add an sc= capability to {{also}}? At least with grc, a good font is especially important for seeing the difference between the words (which are often only different by some minuscule diacritic). -Atelaes λάλει ἐμοί 02:30, 4 September 2008 (UTC)
Would apply to all the titles, which isn't desirable; often the entire point is that they are in different scripts. Use {{xsee}} and wrap the ones you want with the font template you want. (after linking them) We could merge this into see/also with use of {{wlink}} at some point. (we should probably have {{xalso}} as a redirect to save someone confusion?) Robert Ullmann 12:48, 4 September 2008 (UTC)

missing * before IPA

While working on User:Robert Ullmann/Pronunciation exceptions at the suggestion of Thryduulf, I've discovered a large (12-13K) set of entries that have just the IPA pronunciation, with no * at the start of the line. A lot of them are Romanian entries that Ric added, which do have lang=ro. Quite a few others are French.

I'm teaching AF to add the * if it can match the whole line, and add the appropriate lang= in this case. (not the general case of IPA templates in FL pronunciation sections yet). Robert Ullmann 09:32, 26 August 2008 (UTC)

Ah, here's an oddity: if you use {IPA} with no lang=, or lang=en, it generates a link to w:IPA_chart_for_English, but if you give it a language code not in the small set it "knows", it links to w:English phonology. Which is a bit confusing? I can fix it, but where should it link? Robert Ullmann 16:41, 26 August 2008 (UTC)

w:International Phonetic Alphabet would seem to be a logical destination. Thryduulf 23:48, 26 August 2008 (UTC)
Alternatively, there is Dictionary:IPA pronunciation key. The advantage is that its less wordy than the Wikipedia article. The disadvantage is that it lacks explanatory text altogether. --EncycloPetey 03:02, 28 August 2008 (UTC)
I've added a two sentence introduction to that page. It needs more work though, as for example the ɹ symbol is completely missing from the chart. Thryduulf 12:29, 28 August 2008 (UTC)
I would think our pron key would be the best, it can link WP etc. Robert Ullmann 15:45, 28 August 2008 (UTC)
Sounds good to me. Personally, I would prefer a link to w:lang phonology. In my experience, these often exist, although admittedly not always. -Atelaes λάλει ἐμοί 19:05, 28 August 2008 (UTC)
As I understand it -
  • If "IPA chart for lang" exists it will link there.
  • If the above doesn't exist and "lang phonology" does, it will link to that.
  • If neither exist it needs somewhere to link to. Currently this is w:English phonology, which isn't appropriate, and so the discussion above is to chose a better target. Thryduulf 01:15, 29 August 2008 (UTC)
not exactly; it does this:
  • if the language is English (default) it links to IPA chart for English (in the wikt)
  • if the language is something else in a specific list in the template, it links to w:(language) phonology — note that it can't test for the existence of the WP entry
  • if the langusge isn't in the list, it links to w:English phonology (which is the issue I raised)
we could always link to w:(language) phonology, but we'd have to add some redirects to the 'pedia, and have some way of checking or maintaining them (w/o adding yet another maintenance task that will go on forever ;-) Keeping the list in the template for now is probably fine. (I will improve how it is done ;-) Robert Ullmann 11:40, 29 August 2008 (UTC)

Should translingual pronunciation sections (e.g. that at ) link to the same place? What should the lang= parameter contain for these entries? Thryduulf 23:08, 29 August 2008 (UTC)

I don't think that entry should have a translingual section at all. This is a letter, used by a certain set of languages (e.g. Sanskrit, Marathi, Hindi, etc.). There is no pronunciation in a translingual context, only in a language specific context. -Atelaes λάλει ἐμοί 23:53, 29 August 2008 (UTC)

I'm really thinking we should not rely on this list. I just discovered that grc does not work in {{IPA}}, and so I was thinking of adding it, but then realized what kind of queue that would create. It seems a little silly to do this every time we want to add another language. I think we should simply have it link to [[w:lang phonology]] every time there's a language inputted. Granted, wikipedia does not have a phonology article for every language, but I have to imagine that they intend to, and will, in time. For those languages which don't have articles, we could probably just go over there and create redirects to the main language article, perhaps to the section about phonology, if it exists (and make sure to wash your hands afterwards, before editing Wiktionary again). -Atelaes λάλει ἐμοί 01:37, 30 August 2008 (UTC)

Agreed. If we're worried, we can bring this up at their equivalent of the beer parlour (one of the village pumps, I think) and confirm that they're O.K. with standardizing on [[<language name> language]] and [[<language name> phonology]] as article names (or at least, on offering redirects from those names). —RuakhTALK 02:41, 30 August 2008 (UTC)
From what I understand about redirects, this is a non-issue; there will be no problem creating a redirect where there is no (language) phonology page; it would be encouraged. The issue is somehow checking that we have the ones we need, i.e. have IPA templates that point to them. Robert Ullmann 15:12, 31 August 2008 (UTC)

Other rules

I've added some more rules to AF to handle cases turning up in the exception report. I was going to test them in AWB first, but AWB is not working any more.

Rules are converting RP, UK, and US to the {a} versions in some cases, also some things like "Zhangzhou". And one special rule: there are a large number of entries which look like this:

* foo, /fu/, /<tt>fu</tt>/

which it will convert to enPR, IPA, SAMPA; I've looked at quite a number of them and they are very consistant. Robert Ullmann 15:45, 28 August 2008 (UTC)

This same task would be usefully applied to the Rhymes namespace also - see Rhymes:English:-ɜː(r)l for example. Thryduulf 14:00, 30 August 2008 (UTC)
Erk... I just noticed an example of this format in an Italian section (sei#Italian). When this format appears in a non-Enlgish section, the first portion is not enPR, since that is English-specific. In particular, Italian entries show the "dictionary accented" form that Italian print dictionaries use. This is (again), not enPR, so AF will need to be certain not to consider it so when cleaning up FL Pronunciation sections. --EncycloPetey 00:18, 1 September 2008 (UTC)
Does the dictionary accented form give enough information to be considered a pronunciation guide? Should we create {{itPR}} for it? —RuakhTALK 00:31, 1 September 2008 (UTC)
Not really. All it does is place an accent on the word at the place of stress. That's all. --EncycloPetey 00:33, 1 September 2008 (UTC)
Changed to only fire rules containing "enPR" when section lcode = "en". I've been looking at most of these while doing my usual monitoring of AF, and haven't seen it convert any previously. At some point I should be looking for the general case of enPR outside English sections. (If we ever get an XML dump?) Ah, it has dozen or so of these while I was sleeping; have fixed them will review more in a little bit. Robert Ullmann 14:35, 1 September 2008 (UTC)

Templating rhymes

Also from the pronunciation formatting work, Thryduulf suggests AF could convert un-templated instances:

Rhymes: *\[\[Rhymes:English:-(?P<s>.+?)\|-(?P=s)\]\] → {{rhymes|\1}}

I.e. if the two instances of the IPA suffix match, then replace with the template. This just does English, but it isn't clear that there are any FL language entries that don't use the template. If there are, we'll find them a bit later.

Do read User talk:Robert Ullmann/Pronunciation exceptions if any of this interests you. Robert Ullmann 19:00, 26 August 2008 (UTC)

The coding above is missing an initial asterisk in the output (if I'm reading it correctly). It might also be worth checking to see that the target page exists. I've come across a number of rhymes page calls where the target did not exist. It would be nice to track those, as sometimes it is the result of incorrect IPA characters and sometimes the result of something more seriously wrong. --EncycloPetey 19:06, 26 August 2008 (UTC)
There's no asterisk missing, no. (The above isn't matching the entire line; it's just templatizing the part of the line that it does match. So, it won't touch initial asterisks/bullets, colons/indents, etc.) As for target-page existence, that sounds like a somewhat separate task — maybe it could use the XML dumps to generate something like Special:WantedPages for the Rhymes namespace? —RuakhTALK 19:51, 26 August 2008 (UTC)
yes, this doesn't affect the stackable wikitext formatting preceding it. See December et al. Robert Ullmann 01:55, 27 August 2008 (UTC)
There is quite a bit a lot of work needs to be done on the Rhymes: namespace, as there are literally thousands of words that rhyme that are not included in the rhymes pages. A while back (1-2 months ago?) someone suggested converting the manual rhymes pages we currently have into something that works like categories do, so that every time at word is noted as rhyming with, e.g. -ɒp it gets added to the list of rhymes at that page. Although how the syllable split would be managed I don't know. I don't remember that this discussion ever came to any conclusions (or where it was).
Another problem is that our IPA transcriptions use [ɹ] for the sound represented by the English letter "r" (e.g. car is IPA: /kɑː(ɹ)/) but the Rhymes pages use [r] (e.g. Rhymes: -ɑː(r)). Changing this would require significant bot work.
As noted above, there are also many rhymes pages that don't yet exist. The templatising of the calls to the rhymes namespace will be a useful first step to sorting it all out imho. Thryduulf 23:44, 26 August 2008 (UTC)
with these "templatized", we can then gen up a cat with the missing pages. Robert Ullmann 01:55, 27 August 2008 (UTC)

Also related to the Rhymes, a lot of the Rhyme lines in pronunciation sections were indented with *: rather than the * of the pronunciation transcriptions. The current standard seems to be that this isn't done. Unless anyone objects, I'd suggest that AF removes the : indent from these lines where it finds them. However as this is such a trivial change, I'd set it as one of AF's minor changes so that it doesn't bother saving the edit just for this. Thryduulf 14:09, 27 August 2008 (UTC)

As I understand it, the original rationale for the indenting was that each rhymes link would be tied to a particular pronunciation and indented under it. However, with the current format of the Pronunciation sections this makes no sense, since our pronunciations are grouped geographically (with more than one pronunciation on a line), and since the rhymes are all keyed and named only using the UK phonetic transcriptions. I agree that the colon ought to be removed, and we might see about changing this in WT:ELE as well. --EncycloPetey 02:59, 28 August 2008 (UTC)
Both WT:ELE and WT:PRON say the indent should be :* which is wrong, it breaks the first level unordered list. (Yes, this only affects someone reading the XHTML, but that is done. Javascript or whatever reading the structure should only see one unordered list.) The correct way to indent a bullet within a list is **. Since indents have been used with semantic meaning (as EP notes), I'm a bit reluctant to just remove them automatically, at least until AF is taught more about the entire section, rather than a small set of ad hoc rules. As we munch through the problems list, we can get into more details, eventually flagging any Pron section that cannot be parsed. (I am saying I'm reluctant, but if it really looks okay to do somewhat blindly, okay; I would convert ":* {{rhymes" and "*: {{rhymes" to "* {{rhymes") Robert Ullmann 10:43, 28 August 2008 (UTC)
... and since the rhymes are all keyed and named only using the UK phonetic transcriptions. Um, where did this idea come from? I doubt that kind of UK-centricity would pass. And it hardly addresses other languages. Robert Ullmann 15:15, 31 August 2008 (UTC)
I'm guessing that since a lot of pronunciation differences between the UK and US are predictable (e.g. [ɒ] -> [ɑ]) it was felt that there wasn't any point in maintaining different Rhymes pages for them. Where there are very different pronunciations (either between regions, or between different parts of speech) I've been adding two rhymes templates followed by {{qualifier}} templates. As mentioned in several places elsewhere the Rhymes namespace needs a lot of work (in lots of different respects), and so I'm tempted to leave the status quo as is for the moment and then deal with all the issues in one fell swoop (perhaps we should make a list of the issues somewhere). Thryduulf 10:49, 1 September 2008 (UTC)

Lupin popups

Did something break this? In the last few days they haven't been able to load anything besides the title of the page, at least for me. Nadando 02:40, 28 August 2008 (UTC)

w:Wikipedia:Tools/Navigation popups#Wikipedians who have helped lists, among others, “Yurik - with his fantastic mediawiki BotQuery extension”. Said extension was disabled this past Monday (see [[#The API is dead! Long live the API!]]); apparently Lupin popups didn't survive. —RuakhTALK 02:50, 28 August 2008 (UTC)
Oh, too bad. Made patrolling so much easier. Nadando 02:58, 28 August 2008 (UTC)
It isn't hard to convert to api.php, I've done various things over the last months (from UI calls to API, not from QUERY, but is similar) Lupin is widely enough used on the 'pedia that I expect someone will fix it, if not already. We can then steal. Robert Ullmann 10:49, 28 August 2008 (UTC)
Well, prior, the only that would ever load was the (inexistent) intro anyway, as I commented here. Circeus 18:14, 29 August 2008 (UTC)
The only function I'm currently missing is getting counts of the number of items in categories beyond the first 10. This slows me down on working cleanup lists that often have more than ten refractory items that have taken up semi-permanent residence on said lists. That I still have other functions could be the result of not having flushed a cache I suppose. DCDuring TALK 19:26, 29 August 2008 (UTC)
Re: flushed cache: no, the APIs are strictly server-side. So, it probably means that the functions are being restored and Lupin popups is being converted from using query.php to using api.php. (Unfortunately, I don't use it, and don't know anything about it, so can't give you more information than that.) —RuakhTALK 19:32, 29 August 2008 (UTC)
My popups is working fine... if you've still got problems you might want to try copying these lines from my monobook.js - which import an old version of popups. Conrad.Irwin 00:30, 2 September 2008 (UTC)
popupAdminLinks=true;
popupOnEditSelection=false;
importScript('User:Lupin/popups.js','en.wikipedia.org','114364398');
importScript('User:Connel MacKenzie/mess-with-popups.js');
The one bit of functionality change that I've noticed that persists after inserting the above code is that the count of items in categories is gone if there are more than ten items in the category. DCDuring TALK 03:17, 2 September 2008 (UTC)

September 2008

monobooks.js - can it do this?

Is it possible to automatically expand templates that are collapsed by default? I'm talking in particular about the various Spanish conjugation templates: Template:es-conj-ar, Template:es-conj-egir, Template:es-conj-car, etc, which may all be found at Category:Spanish conjugation templates. By default they're collapsed with a button to show them on the right. I can see how this would be helpful for some people, but I would rather have them expanded automatically. Is there a .js or .css script available to do this? Thanks, FlamingSilmaril 14:26, 1 September 2008 (UTC)

Yes- go to WT:PREFS and check "Alternatively, leave ALL translation sections expanded (and similar hidden sections) - Default is to leave them collapsed". Nadando 16:56, 1 September 2008 (UTC)
Great, thanks! FlamingSilmaril 18:45, 1 September 2008 (UTC)
Perhaps WT:PREFS should include a note on how to rig your monobook.js so that the chosen pref travels with you from computer to computer.—msh210 21:53, 2 September 2008 (UTC)

Template:hy-noun

Opiaterein has disabled the tr= function of this template, making the transcription the unnnamed parameter {{{1}}} instead. How strongly do we care about using tr= to consistently mark transliterations in non-Laitn script templates? --EncycloPetey 17:15, 2 September 2008 (UTC)

Fairly strongly. Certainly if a template already uses tr= for the transliteration, breaking it is unacceptable. (From the note on your talk page, Ric seems to be under the mistaken impression that {1} can't be used for plural form, etc, while leaving tr= as is? Does he not understand that named parameters aren't counted? That in, e.g. {{hy-noun|tr=trans|plur}} that "plur" is {1}? And do note the edit summary please.) In any case, should be put back and extended properly. Robert Ullmann 17:30, 2 September 2008 (UTC)
He understands, but as he notes on his talk page, he prefers the unnumbered linear style. --EncycloPetey 17:37, 2 September 2008 (UTC)
'kay. Just another little mess someone will clean up someday. Robert Ullmann 16:07, 5 September 2008 (UTC)

Template:sense

Circeus has added a space to the end of this template. I don't see why anyone using the template wouldn't follow it with a space anyway. This now means that we get two spaces after the colon (if the template is set up to produce a colon) instead of one; it also suggests that he/she has used it on at least one page and not explicitly followed it with a space, meaning that if we roll this back, we will have missing spaces on those pages. — Paul G 11:28, 5 September 2008 (UTC)

I would think it would be good to place a plain space after the colon to always ensure a space after it.
A non-breaking space is problematic, because it will sometimes create a double space where there is another space after the template. This will give an inconsistent presentation, and modern typography uses single spaces after colons anyway (double spaces are a typewriting convention, and a characteristic of Victorian typography). Michael Z. 2008-09-05 14:11 z
I see no reason to include a space at the end of this template. We don't do it to any other template, and any sane person would put a space between the colon displayed at the end of this template and any folowing words. --EncycloPetey 15:42, 5 September 2008 (UTC)
He was editing angle bracket, added a sense usage without a space, then added the space to the template instead of the entry? Makes little sense to me ;-) There isn't any reason for this; I'm just going to put it back the way it was. Right now, all of our other pages that use {sense} are displaying extra space. (He subsequently added a uses of {sense} to debacle w/o depending on the space ...) Robert Ullmann 16:04, 5 September 2008 (UTC)
There should be one plain space following the colon in the template. In HTML, multiple whitespace characters in the code get rendered as a single space on the page. So even if one editor ever forgets to add a space once, this will still display correctly, instead of having subsequent text set flush with the colon (which is always wrong in English). In all other cases it will have no effect. Michael Z. 2008-09-05 16:57 z
No. It creates the opposite problem: editors leaving out the desired space in the wikitext because it "isn't needed" or they don't notice, or (worst) "it doesn't belong there, it is in the template!". Much more severe problem than the occasional omitted space in the text. Robert Ullmann 17:39, 5 September 2008 (UTC)
I don't see what the problem is—searching in the wikitext for terms which follow the template?
Following the programmer's dictum of being liberal in what input to accept and conservative in what to output, the template may as well prevent that occasional omitted space from ever occurring.
We don't do it for other templates, but other templates don't end with a colon. Come to think of it, offhand I can think of no reason not to add a plain space to context templates and all others in round brackets. Michael Z. 2008-09-07 20:09 z
Normally, I'd make a case for adding a space to the {{context}} derivatives too. However, I think (it would certainly explain why I so rarely runs into it in articles) it is amongst the AutoFormat fixes (and if it isn't it should be easy to add should it be felt a good idea), hence I would tend to agree it is not strictly needed. This was sort of a reverse reflex from Wikipedia, where I am constantly editing tample to remove extraneous whitespace. Circeus 03:38, 8 September 2008 (UTC)

Special:WantedPages

I think it is time that this page was regenerated. A lot has happened here since September 2007, and I for one would like to see a new list there. I understand that there were some performance issues with having this done on a regular basis, but a one-time regeneration would be sufficient for several months. – Krun 16:26, 5 September 2008 (UTC)

Unfortunately, we haven't had an XML dump for many months now (June), so anything generated would already be three months out-of-date. If you can add your voice to those clamoring for an XML dump, it might help push that into happening. --EncycloPetey 18:04, 5 September 2008 (UTC)
Different things. The Special page is generated from the SQL database; the same task queue generates the others (which, note, have been updated twice a week all along). But trying to get it re-enabled will bump you into the same swamped couple of people who can't get the XML dumps going ... (;-) Robert Ullmann 18:41, 5 September 2008 (UTC)
Without a new XML dump, even a workaround like User:Connel_MacKenzie/Wantedpages cannot be regenerated. -- Gauss 11:53, 7 September 2008 (UTC)
Relatedly: Dictionary:Most_missed_articles. Conrad.Irwin 12:00, 7 September 2008 (UTC)
Looking at this last, many seem to be poorly selected, obsolete, and untested links coming from WP. Would there be an easy way to generate a list of bad WP links to Wiktionary? Is there an easy way to do this at WP? I haven't looked there yet. DCDuring TALK 12:58, 7 September 2008 (UTC)

order of templates

How would people feel about changing the order of the templates list during an edit so comparative comes before superlative? RJFJR 00:30, 6 September 2008 (UTC)

That makes loads of sense. Done. —RuakhTALK 01:19, 6 September 2008 (UTC)

Uncategorized pages strangeness

Special:UncategorizedPages includes the Italian noun incidente stradale. This is in Category:Italian nouns, and has been since the entry was created on 31 August. Any ideas? SemperBlotto 10:21, 7 September 2008 (UTC)

p.s. Also scioperi della fame

These two entries don't appear in their respective categories at present. Looks like the cat membership didn't get updated on the save. (I'm noting more and more of this from the WM s/w, not being able to update cats on saves and thing like template edits, I think there is a serious bug out there.) If we purge these two pages, I suspect they will show up in the cats just fine, and not be in the next update of the special page. Robert Ullmann 12:51, 7 September 2008 (UTC)

converting "old" ety templates to Template:etyl

As Atelaes has been asking for AF to convert templates to {{etyl}}, I've done some analysis and set up a list for AF.

AF will then be converting them over time, while also catching new uses by occasional contributors or those that haven't shifted to "etyl" yet. Comments anyone? Robert Ullmann 15:50, 7 September 2008 (UTC)

Am I correct in assuming that the conversion process will not convert the handful of templates that involve "languages" that do not have ISO 639 codes? (New Latin, Late Latin, Medieval Latin, Vulgar Latin are the ones I'm familiar with.) Or is there another way of handling these without losing information? DCDuring TALK 18:14, 7 September 2008 (UTC)
That's what his file says. Just the easy ones. --Bequw¢τ 19:24, 7 September 2008 (UTC)
Right. Late Latin can't be used in {etyl} as it stands now even if we invented a non-standard code, as it would link to w:Late Latin language. The language ages and groups and such we want to refer to in etys have to be done differently. (I have several different ideas. In the meantime, it would be good not to have {{G.}} for German, and {{Ger.}} for Germanic. The first goes to {etyl|de}, the latter to {proto|Germanic} or to a group (w:Germanic languages? Yup.), but we'd have to look at how it is being used. Possibly both ways ... Robert Ullmann 17:48, 8 September 2008 (UTC)

Template:Bolivia

I have just created the Regional template: Template:Bolivia. Although there seem to be the pages pito, pega, cachar using this template, they don't appear in the Category:Category:Bolivian Spanish. Probably I have overseen something, as I am no template expert. Could someone please help to fix this problem? Matthias Buchmeier 10:53, 8 September 2008 (UTC)

(can't edit this page any more)
Too big? Something broken? Anyway, won't load completely. If anyone can combine this section with above?
The Template:Bolivia problem is broken WM s/w: when #ifexists was changed to explicitly add links to the link table, we were told it was so pages could be updated if an entry was added. This, of course, has never actually worked. In the meantime, the ability of the s/w to update categories has been slowly deteriorating. (Note the section two above that one as well.) Only fix is to purge the relevant pages. If you look at Special:WhatLinksHere/Template:Bolivia you will see that they do appear in the links table. Robert Ullmann 16:44, 8 September 2008 (UTC)
I've archived March, and fixed some {{ … }} imbalances that were making MediaWiki be crazy and not show [edit] links for a whole bunch of segments; hopefully one or both of these changes will make you able to edit? —RuakhTALK 17:06, 8 September 2008 (UTC)
Yes, thank you. It would display the whole page, but I have to be able to section edit. And as you note, no links. (And nto even section numbers when I manually put them in the edit URL ;-) Robert Ullmann 17:42, 8 September 2008 (UTC)
Does that mean that it would be sufficient to purge only the template or that all relevant pages including the category and entry pages have to be purged? Do you think there is a chance that future MW versions will fix this problem? Matthias Buchmeier 09:57, 10 September 2008 (UTC)
Purging the pages. Editing the template should work, but almost always does not. Sure, they might fix it someday, but since they broke it essentially on purpose, I wouldn't hold your breath. Robert Ullmann 15:50, 11 September 2008 (UTC)

{{quote-book}} is great, but…

…it needs some work.

  • there is often a comma after the last item on the first line, this should not be
  • it would be great to have a parameter to add additional information (such as the w:Stephanus pagination number for a work of Plato)
  • maybe we should make a second version to be used in the Citations namespace, instead of requiring the strange indent2=*: parameter}}
  • maybe we should include the first indent as well, at least make this more consistent

Someone tech-savvy should have a look at this and then we should be promoting this template actively on WT:" and convert all the {{RQ-templates to use it as well. H. (talk) 15:16, 8 September 2008 (UTC)

Re: comma: Dictionary:Quotations currently mandates that comma. However, discussion at its talk-page suggests that some editors would prefer a colon.
Re: additional information: OMG, abandon all hope. The template is great for typical cases, but I don't think it can cover stuff like this. OTOH, might it be worth creating a special template for quoting from works of Plato?
Re: indents: Another option is to use HTML-style markup (<dl><dt>…</dl></dt>) to achieve the indent, so that the template will work regardless of its context
RuakhTALK 17:02, 8 September 2008 (UTC)
This is a wikipedia import that is already trying to do way too much. The quotation itself should be taken out of the template, and the wikisyntax (*: etc) as well; it should generate only the citation line, like the RQ templates. (And the specific RQ templates should be kept, they often have specific links that are useful.) Trying to "fix" it with crap like the "indent2=" parameter will just create more problems. Robert Ullmann 17:38, 8 September 2008 (UTC)
I use {{cite-book}} in the citations namespace (which is not the same as the clone of wikipedia's {{cite book}} which we also have clogging up the airways), it seems to perform adequately there. Conrad.Irwin 07:46, 12 September 2008 (UTC)
Then should I maybe put a warning on the template that it is not to be used? Or that certain parameters are deprecated (such as passage=)? I think indeed it could do good stuff if we confine it to the citation line only.
I hate that comma.
Note that it needs some additional parameters, such as volume= and chapter-title= (or, alternatively, chapter-number=). H. (talk) 09:27, 15 September 2008 (UTC)

preload templates broken

Seemingly, if someone tries to use a preload template to make a page that has an apostrophe in it, the apostrophe and everything after it get converted to a single ampersand. See Pickett&. Is there anything that can be done about this?—msh210 21:10, 10 September 2008 (UTC)

It isn't the preload templates per se, it is that Mediawiki:Noexactmatch is using <inputbox> to load them, and it in turn is not generating the correct URL. Most cases seem to give a server error at present. Robert Ullmann 14:53, 11 September 2008 (UTC)
Now bugzilla:15564 on Extension:Infobox. Robert Ullmann 15:46, 11 September 2008 (UTC)

Appearance of Wiktionary using Google Chrome

This may not be the best place for this discussion.

Anyway - When you have multiple tabs open under Internet Explorer (IE7) it won't normally let you flip between tabs when you are waiting for a response from one of them (normally Wiktionary). Google Chrome does not have this restriction, but on my screen setup it looks awful. It looks like it has been written on an old typewriter. My font setups are as follows: IE7 (Webpage - Times New Roman, Plain text - Courier New) Page => Text Size => larger. Google Chrome (Serif - Times New Roman, 16 pt, San Serif - Courier New, 16 pt, Fixed Width - Courier New, 16 pt). Poor quality screensots are here => IE7 Google Chrome

Does anyone have any ideas how I could make Google Chrome look like IE7 (which is how I like it). SemperBlotto 09:47, 11 September 2008 (UTC)

I think you've borked something with the font settings. Out of the box, on WinXP/SP2, it looks just fine. Did you import settings from IE7? Note that you say you have set Chrome to "San Serif -- Courier 16 new"; that is not what you want, San serif should be a proportional font, e.g. Helvetica. Courier should only be for fixed width. Running text in the wikt, including the main page, is san-serif. So with the settings you describe, the results are as expected ... (;-) Robert Ullmann 14:46, 11 September 2008 (UTC)
Yes, the Chrome installation copied settings from IE7. I don't seem to have any Helvetica fonts on my machine. After several experements, Microsoft Sans Serif (18pt) gives the closest to my current setup - but I can't get the screen to anything like look the same. Perhaps I will have to wait for IE8. Or be a bit more patient when multi-tabbing. SemperBlotto 16:08, 11 September 2008 (UTC)
Okay... note that with the default settings (which I've been careful not to change) IE7 and Chrome are almost identical. The only difference is that Chrome does a bit better in spacing in some places (as does FireFox). You should be able to set up Chrome witht he same fonts etc as IE7, but that may not be complete yet (being a Beta). One thing I note is that it is slower than FF, and I can switch tabs in FF at times that I can't in Chrome (!). (I only use IE7 to test user presentation; which is also pretty much the only reason I use Windoze at all. ;-) Robert Ullmann 16:29, 11 September 2008 (UTC)
Well, now you mention it, Firefox also looks nasty on my setup - that's why I don't use it. I'm sure that my screen setup is different from most peoples (having bad eyesight) and, as I have been using the Internet since its early days, I have got used to it looking the way I like it. I can remember having to change a few things when I migrated from Netscape Navigator (under Windows 3.1) but I can't remember what I did. P.S. Google Chrome has a built in spellchecker for use when editing - you can set it to UK or US English - or even Italian. SemperBlotto 07:37, 12 September 2008 (UTC)
Setting the SanSerif font to Arial, 18pt will give you the best match to your current settings. 85.12.64.148 14:19, 12 September 2008 (UTC)

The ultimate dictionary

The following list is a suggestion of upgrades for Wikimedia :

1) Black wallpaper with colored fonts, for energy and eyes preservation.

Umm, no thanks! You can customise your Special:MyPage/monobook.css if you really want to inflict that upon yourself.

2) Crossword research.

Could be interesting, maybe start a sample discussion on the Dictionary:Information desk and see what happens, you can always split it off if it generates too much traffic.

Information desk answer = →The ultimate dictionary: remove crossposting (see Grease Pit)

3) Print link for all objects (arrays, pictures, schemes), with translations (eg: foreign meronyms).

Yikes, What are arrays and schemes? We don't host images directly, so that'd be quite tricky, you can get all images from http://commons.wikimedia.org/

4) Link towards articles to achieve and external links to include in the dictionary.

We have WT:RAE and the same for other languages, not sure what a list of external links to include would be for.

5) Photo, sound and video edition interface, with history.

Yes, this would be nice, we need someone with video experience for the sign-language stuff, and more people will microphones to record words.

6) An option for page reading, with several voices at a choice, and the possibility to read some pages with video plugins in addition (karaoke, colored fonts, films, video algorithms). A speech recognition compatibility would be enough ergonomic.

Umm, this is provided by operating systems for those interested, I doubt we could provide anywhere near high enough quality readings of all entries.

7) Download version for PDA and mobile phone with regular updates.

This has been proposed before, User:Hippietrail is probably the best to ask. If you are just looking for a light-weight wiktionary though, see http://ninjawords.com .

There's also Moulinwiki [5]

8) Addition of new models : false-friends, transparent words, and real friends or international paronyms.

This can be done (we don't have structured data, so models is probably the wrong word), just add relevant sections to words as you find they need them.

Sorry, model is a French false friend, actually I meant useful template.

9) Listing requests from definitions, eg: hyponyms of horse in 2 selected languages, all English + French + Spanish false friends, all etymologies of the words ending with the -logy suffix, ordered by alphabetic order, word occurrences in the selected language, or year of appearance in all languages. JackPotte 21:41, 13 September 2008 (UTC)

Umm... We'd need well-structured data to do stuff like that. Wiktionary is all in a plain text format (for better and for worse). Conrad.Irwin 22:16, 13 September 2008 (UTC)

JackPotte 20:58, 17 September 2008 (UTC)

10) Bar showing degrees of holonymy, meronymy, hypernymy et hyponymy. For instance, horse [6] would be the 2nd degree meronym of equidae [...] and the 14th degree of animal. JackPotte 22:23, 20 September 2008 (UTC)

MediaWiki:Blockedtext

This is missing several of the provided parameters, including in particular $6 which is the expiration time of the block. Random832 00:20, 14 September 2008 (UTC)

This is omitted on purpose. Most blocks here are vandals, and we don't wish to advertise to vandals how long they have to wait to vandalize again. --EncycloPetey 00:24, 14 September 2008 (UTC)
What are the other parameters? (And how do you know? I mean, where can you check what they are?)—msh210 16:29, 15 September 2008 (UTC)
See [[mw:Manual:Interface/Blockedtext]]. (Not all pages in the MediaWiki: namespace are very well documented — or were last I checked — but many are.) —RuakhTALK 01:02, 16 September 2008 (UTC)

#

How can I create an article on the symbol #? It currently links to the main page. I have added info to octothorpe, where the symbol is discussed, but have been repeatedly reverted.

Thanks, Kwamikagami 02:13, 16 September 2008 (UTC)

As that character is not allowed for Wikimedia pages titles, we put information about that character (and others) in Appendix:Unsupported titles. You should be able to link to one of the subheadings there. --Bequw¢τ 05:29, 16 September 2008 (UTC)
Ah, I couldn't figure out how to link to it without getting an error. We can't link to subsections, though, correct?
Another possibility would be to use the Chinese double-wide characters, such as . Would that not be appropriate? Kwamikagami 05:43, 16 September 2008 (UTC)
It would be a horrible hack; it might not display correctly in some contexts and would cause confusion for those trying to input the symbol (copy and paste would be "broken", typing wouldn't type it). The double-width characters are seperate code-points, and so it is best to treat them as distinct characters. (We now have to have a note on \ because someone in the deep-dark-distant past though it would be a good idea to overload a code-point). A better solution would be (in my opinion) to use U+0023 as the title, though that's fairly ugly too. Conrad.Irwin 07:40, 16 September 2008 (UTC)
Well, now that I understand how to link to it, it's no longer really an issue. Kwamikagami 08:41, 16 September 2008 (UTC)
I don't think [[Appendix:Unsupported titles]] is a very good long-term solution. That page is already fairly large, but it covers just the tiniest part of what we need it to. I think we should have separate appendices for all these characters, and then [[Appendix:Unsupported titles]] can link to those. —RuakhTALK 14:04, 16 September 2008 (UTC)

I added some hidden anchors, so for now at least you can link to, e.g., Appendix:Unsupported titles#octothorp.

In terms of written presentation, the headings on this page are not very useful to say the least (a space as the header text?). Can't we just pick a representative name for each symbol, for example “# (octothorp)”? Michael Z. 2008-09-16 15:58 z

Is there some kind of theorem that says that some types of programming languages must have keywords that limit content? DCDuring TALK 16:21, 16 September 2008 (UTC)
First, this is a markup language, not a programming language. And no, there is no requirement that "content" be restricted. (For the answer for programmings languages, note that PL/I is an example of an ordinary language with no reserved keywords.) Look at HTML (also a markup language): the reserved characters (< > &) have escapes (&lt; and of course &amp; itself). The issue is that Wikitext doesn't provide a full escape mechanism for page titles (it does for content); the page titles are supposed to be encyclopedia entry titles; using them as exact spellings of dictionary entries is stretching it a bit. It does not allow &#35; as a page title. (note that that also contains "#" ... and HTML doesn't provide a named entity for # because it isn't a syntax character in HTML except inside a numerical reference ...) Robert Ullmann 16:44, 16 September 2008 (UTC)
Thanks for the helpful reply to a poorly expressed question. Is there a prospect for there being such an escape mechanism for headwords? If not, could we have a work-around that allowed searches to work using the various reserved characters as they might be entered, with some kind of substitution table for the offending reserved characters? As it is now the special characters entered in the search box do not lead users to the appropriate appendix or, indeed, any pages at all. So that appendix is mostly useful to editors as a reminder of what characters must be excluded. How hard this is, where this fits in as a priority, and on whose plate it would fall are all questions beyond my paygrade.
As a byproduct of some approaches to addressing this, we might get the ability to search for wikitext that contains special characters for maintenance purposes, a particularly useful capability in those intervals between dumps. DCDuring TALK 17:25, 16 September 2008 (UTC)

XML dumps

The last XML dump that that "they" have managed to produce is 3 months old: 13 June 2008

I don't know the specifics for other people, but I myself have spent several hundred hours coding various compensations for the severely stale dump. In hindsight, I would have done far better to build a local mirror in July.

This is also an extreme breach of the purpose of the WikiMedia Foundation; it is not to produce a live encyclopaedia or dictionary website, it is to produce re-useable content under GFDL. The website(s) don't cut it, live mirrors are prohibited. The XML dumps are the GFDL publication of the content.

That aside, to continue: I think we will have to build our own (non-"live") mirror, keep it up to date, and produce compatible XML files. Any ordinary box with a gig of disk can start from the 13 June XML, catch up quickly (hours), and stay current with minimal network traffic; it can then spin a new XML dump every 24 hours and upload it somewhere. (Could do every 2-3 hours, but I don't think that is needed?)

(In case you are wondering about the update rate, my laptop running AF reads all the patrolled edits, with a very small fraction of the rather limited bandwidth and latency I get here; it could probably run this with no trouble ;-)

I don't knwo why Brion and Tim can't get this together, but after many, many complaints we should find an alternative. My time alone spent compensating is at least 20 times what it would take to fix the problem for WMF. (Another idea is for me to just rent a machine with a Tbyte or two from an ISP somewhere, and maintain XMLs for the whole project set ... maybe that would be too much load on the servers? Dunno. Would take less of my time than what I am doing now. I am not volunteering to do this!)

Anyone have other thoughts or ideas? Robert Ullmann 01:19, 17 September 2008 (UTC)

If relatively little effort or other resources are required, then it would seem that there must have been some kind of decision not to do the XML dumps, either so that they are not available to some specific class or classes of dump user or to free up resources for other very high-priority purposes. Could anyone be getting XML dumps by some other means? Could this be part of some kind of hardball negotiation process? Do we have any idea of what the WMF techs are working on? Is this a matter for airing on one of the WMF mailing lists? DCDuring TALK 02:00, 17 September 2008 (UTC)
(see for where it was left on 1 August) I have no idea what priorities they may or may not have; but (as I noted above) this or some other re-useable GFDL publication of the data is mission critical, and 3 months (for the en.wikt) or 45+ days (at least, for everything else) is completely beyond any acceptable operational problem resolution time. You can complain where-ever you want, AFAIK, it has been raised many times, by many people, it every forum they can locate or think of. My question is what we do about maintaining our project ... 02:13, 17 September 2008 (UTC)
Our own fundraising? I'm reluctant to recommend that those providing their time and skills also be hit up for funds. Would any of the folks using Wiktionary content commercially let their servers be used for the updating? I would think they might value it for any modest lead-time advantage (hours, days, certainly not weeks) they could get over others who use our content. Having the wear and tear be on someone else's server and communications lines would be desirable. Is there any reason that couldn't or shouldn't be done? DCDuring TALK 02:34, 17 September 2008 (UTC)
If anyone is inclined to contribute funds, they should send them to WMF, with a note asking that this be fixed. (;-) Finding the resources to do updates, upload, etc is not a problem (for en.wikt only). I am wondering if anyone can come up with other approaches? Robert Ullmann 18:18, 17 September 2008 (UTC)
195,337 pages have changed/been added since that dump - I can get a list of them using SQL on the toolserver; so we can get the dump up to reasonably-in-date. Once we have the dump within the limit of recent-changes (about a month), then we may be able to use a script by User:ArielGlenn which uses recent changes to update the dump in batches. All that remains now is to find a host - though I believe Amgine may have a spare server if we were to ask nicely. Conrad.Irwin 19:29, 20 September 2008 (UTC)
Ok, we have the beginnings of a plan. At the moment I am running User:ArielGlenn's script on User:Amgine's server. This will give us (in a couple of hours) all the information necessary to construct an up-to-date dump; though whether we can persuade the too dumps to merge themselves painlessly remains to be seen. Conrad.Irwin 00:46, 21 September 2008 (UTC)
I've been experimenting with creating a new dump. It can be done, and I have made two; however they are both wrong; the first has too many pages, as it contains all the pages that were deleted after the old dump and before the new. The second has too few, because I have a bug in the script that compared the xml dump with the list of current pages. The dump was generated something like this:
  1. Get a list of changed pages "SELECT DISTINCT page, namespace FROM pages, revisions WHERE rev_page = page_id AND rev_timestamp > 2008062200000"
  2. Cat it through some sed's to convert namespace into the prefix and some greps to remove Talk: space etc.
  3. Run an awk script to "merge" the dumps, reads each page from each and then prints all the page-titles using the xml fragment with the highest timestamp
  4. (Get a list of all pages)
  5. (Run the dump and pagelist through a similar awk script that removes all pages not in the list - seems to delete too many pages, but i can't work out why)
Most of this stuff in very raw form can be found at http://devtionary.info/w/dump/updater/ (with too many pages is enwiktionary-pages-articles-20080921.xml , and with too few (I think) is enwiktionary-deleted.xml. Ideas and suggestions would be more than welcome, as once we have an accurate and reasonably current dump (which it might be easier to just generate using the all pages list, now I think about it again) the atglenn has a magic script which will get the list of changed pages from recentchanges and merge it into the dump. This is all a bit Heath Robinson at the moment, so some ideas would be useful. Conrad.Irwin 00:19, 26 September 2008 (UTC)
My thoughts were aomething like this:
  • set up a local db, key=pageid, record=(revid, content, the other attributes in the present XML format)
  • load the last XML dump (13 June) all-pages-current (not just NS:0)
  • for pageid from 1 to current, do API queries like this (with more than 10, perhaps a few hundred at a time, current is about 1.2 million, so perhaps 500 or so queries along the way)
  • if pageid is missing, make sure row is deleted from local db
  • if pageid not in db, or revid different from db (not higher, different, latest rev may have been deleted!) then get current content (in batches of 20-50, same sort of query with rvprop=content|etc)
  • at end, write the XML (can do both NS:0 and all, or the NS:0+(Template, Wiktionary, Help) of the existing pages-articles) in pageid order, so just as the existing one
after the first run (the 197K pages), this should only take 30 minutes or so (depending on lots of things ;-) So run every 24 hours. I would just do this here, but my net connection has a lot of latency and shared bandwidth, so it would take a while, and then the dumps would be on the wrong end of the same link, so would have to upload somewhere anyway. It might track RC, but might be just as good to simply read all of the present revids for each pass. Robert Ullmann 09:35, 26 September 2008 (UTC)
Question: do we have to/ahould we duplicate the WMF download format exactly, or is something compatible with the python dumpparse module good enough? (I suppose the site header can just be copied, but there are other details like including the edit restrictions on page and such.) Should we make an NS:0 only dump? Do we want any more than that? Robert Ullmann 10:08, 26 September 2008 (UTC)
I've written an XML dump updater that reads a dump, adds/updates/removes entries to get (closer) to current. With nearly 200K updates from the last dump, it would/will take quite a while. If we can get up to date, we can then stay there, producing a new dump every day. Do we have something close, in pageid order?Robert Ullmann 15:46, 28 September 2008 (UTC)
Thanks so much for doing this. I would have thought that most of the value comes from NS:0, at least if we will ever regular dumps again on the every-two-week basis. Is there anything about doing only NS:0 that would make it difficult to go back and do the rest later, should it prove necessary? Is there any risk of two processes (NS:0 and all other) getting out of sync? DCDuring TALK 19:25, 28 September 2008 (UTC)
It is a one-filter in the update program, currently set to '0' and '10' (the namespace number is a string at that point). If it is changed, the update will automatically add and drop pages as needed. The data file is in page-ID order, regardless of namespace. (I.e. "namespace" is just a minor attribute of each entry, they aren't stored separately or such.) Robert Ullmann 13:09, 1 October 2008 (UTC)

OK: where should I run this? Which namespaces other than 0 and 10 (Template) might be be needed? The location needs to be able to sustain a reasonable number of downloads. What o you use them for? Code is ready. 23:27, 29 September 2008 (UTC)

As to the last question. I'm a big fan of your "Missing", "Not counted", and non-std. header analysis pages, and CM's similar pages, all NS:0, AFAICT. DCDuring TALK 00:23, 30 September 2008 (UTC)
Agreed. And it would be nice to update at least the first and third sections of Dictionary:Statistics, so we have an idea of where we stand WRT recent work in various languages. --EncycloPetey 00:29, 30 September 2008 (UTC)

Conrad has set me up with an account on Amgine's server (devtionary.info), and I've retested and run the update program. Some notes:

  • the software updates a limited number (some thousands) of entries on each run, so it will take a while to catch up
  • in the mean-time, each successive dump improves on the present 13 June dump, picking up edits and new pages
  • the first update (20080930) includes about 5K page updates, and all of the templates to current
  • the dump includes namespace 0 and namespace 10 (template), this is what is needed to interpret/reuse/analyse content
  • the dump is not a snapshot; it is page versions over a period of time; at present that is over nearly 4 months, but that will be reduced to a few days
  • I will be adding code to pick up revision info from RC, so when the dump is near-current it will be very close to a snapshot
  • I'm not planning on archiving old versions; if you want to capture it once a week/month whatever please do
  • I plan to run it once a day

See http://devtionary.info/w/dump/xmlu/. Remember, right now this is just a small increment on the 13 June dump. Robert Ullmann 17:31, 30 September 2008 (UTC)

notes: there is some issue with characters not on plane 0; I'm looking for it; python on that system tests as a "wide" build, i.e. UCS4; but there is still some problem. Other issue is that I've added the RC support, but this causes a (very bad!) effect: when someone adds a bad entry ("Mr. X in the history department is a gay [redacted] and likes to [redacted]" :-) it gets picked up with celerity, but not deleted until cache expiry ... as I said, not good. Will fix this. Robert Ullmann 23:36, 1 October 2008 (UTC)
was a bug buried fairly deep (but this being Ubuntu Linux, one can look at everything ;-) shelve uses pickle with protocol=0, which mishandles wide unicode in this case. Fixed by using protocol=2 (better/faster anyway). Did not affect data. Program also reads the deletion log, but that doesn't show the ID that was deleted, only the title, so it doesn't work as well as I'd like. (can still be improved)
process has current updates, and has caught up to about 1/5 of the stuff from the last 4 months; new dump in a little while. Robert Ullmann 15:31, 2 October 2008 (UTC)
Many of us are looking forward to a usable dump and, especially, the many useful lists that such a dump enables. And, just as washing a car is thought to be one of the best ways to end a drought, the successful completion of your efforts and your strong mojo are likely to cause WMF dumps to get back on schedule. DCDuring TALK 15:58, 2 October 2008 (UTC)
IIRC, the WMF intended dump schedule isn't as good as RU's, anyway. ;-)   —RuakhTALK 16:11, 2 October 2008 (UTC)
They are supposedly installing the new servers today, and may start running dumps soon. But there is no indication that they will fix the queueing problems that often see the 90-minute en.wikt dump we want stuck behind a the 6-week long en.wp all-history dump. If they do manage to produce new dumps every few weeks, fine; we can then easily continue to spin dailies. (2 Oct available in an hour or two.) Robert Ullmann 16:21, 2 October 2008 (UTC)

credit where due while I have spent a dozen pleasant hours writing and tweaking code, credit must go to Amgine for providing a platform and Conrad for setting up access etc. Robert Ullmann 00:12, 3 October 2008 (UTC)

Devtionary use for live mirroring?

I have no problem providing bandwidth and platform for Devtionary, and was wondering if it might be useful/possible to set it up to livemirror en.wiktionary?

template:temp and lang=

Would it be possible to adjust {{temp}} so that when it receives a "lang=" parameter it displays it as text rather than interpreting it as a parameter? e.g. {{temp|legal|lang=fr}} would display as {{legal|lang=fr}} rather than as {{legal}}. Thryduulf 16:06, 17 September 2008 (UTC)

You do know the general way to do this? Write {{temp|legal|2=lang=fr}}. In general, use explicit n= if the parameter contains an "=". Works with all templates. (And it is good to remember that the script templates typically generate strings containing =, so if you use one within a numbered parameter in another template, you will need this.) Robert Ullmann 18:11, 17 September 2008 (UTC)
That's how I do it, but it's not perfect, since you if you do it for one parameter, you have to either do it for all the parameters after it, or precede it with a dummy empty parameter that gets overridden. By which I mean, {{temp|foo|2=bar=baz|bip}} produces {{foo|bip}}: the bar=baz gets overridden by bip by virtue of the latter being the actual second unnamed parameter, and appearing after it; so one has to put either {{temp|foo|2=bar=baz|3=bip}} (which produces {{foo|bar=baz|bip}}) or {{temp|foo||2=bar=baz|bip}} (which produces {{foo|bar=baz|bip}}). The whole thing almost defeats the point of using unnamed parameters (which is why I mostly avoid them in templates I create). Another approach that I've seen someone use — either Conrad.Irwin or Mzajac, I think — and which people might find more intuitive is to use <nowiki>=</nowiki>, e.g. {{temp|foo|bar<nowiki>=</nowiki>baz|bip}} (which produces {{foo|bar=baz|bip}}). Similarly, one can use a numeric character reference, as in {{temp|foo|bar&#x3D;baz|bip}} (which produces {{foo|bar=baz|bip}}). Unfortunately, neither of these approaches works for the situation you describe with the script templates. —RuakhTALK 01:55, 18 September 2008 (UTC)

merging Template:see (also) and Template:xsee (aka xalso)

I'm putting together a template that will do both, so we don't need two variants (sometimes in the same entry). Presently at User:Robert Ullmann/t.

My intent is to make this the new {{also}}, and then continue converting {see} to {also}, and also convert {xsee} to {also}. I still need to check all the uses of {xsee} to make sure it is understood. Robert Ullmann 18:15, 17 September 2008 (UTC)

Decided this was a bad idea. Technically not a problem, but there are only a small number (couple of hundred) pages that use {xsee}, and 10's of thousands that use {see}/{also}. So not worth the overhead. (For now, if we could get a wlink: parser function that would be different.) Robert Ullmann 16:22, 8 October 2008 (UTC)

Navigation issues

The navigation box doesn't seem to be working- Mainpage-url doesn't go anywhere, nor does Discussionrooms-url. Teh Rote 16:15, 18 September 2008 (UTC)

Could this be related to some odd changes in RC? I noticed today that (1) The "Main page" link there no longer works; the link says "Mainpage-text" and points to [ttp://en.wiktionary.org/wiki/INVALID-TITLE], which it didn't do yesterday. (This problem seems common to every page) (2) There is no longer a runing count of the number of entries on Wiktionary in the header text. --EncycloPetey 19:25, 18 September 2008 (UTC)

Amgine has been doing something with the sidebar text; I'm not sure what. Robert Ullmann 19:30, 18 September 2008 (UTC)
Amgine is on in the IRC. I'll ask. --EncycloPetey 19:32, 18 September 2008 (UTC)
Neither Amgine nor Brion kows what is causing the problem. --EncycloPetey 19:33, 18 September 2008 (UTC)
the problem is the "null" edits Amgine made to the URLs. Adding a blank line above the expected line is not a "null edit"! Rolled those back, so the links work. Now we need to fix the text. Robert Ullmann 19:35, 18 September 2008 (UTC)
Don't know why MediaWiki:Mainpage-text isn't getting picked up again? So we are getting "Mainpage-text" instead of "Main Page"? Robert Ullmann 19:41, 18 September 2008 (UTC)
I deleted the sidebar/en copy that Amgine had added; but that isn't fixing it; it all looks right now (the configuration, not the result!). Caching? Does everyone else still see "Mainpage-text" and "Discussionrooms" (with no space)? Or is it fixing itself? Robert Ullmann 19:45, 18 September 2008 (UTC)
Still looks wrong for me, but that may be related to caching, as you say. --EncycloPetey 19:47, 18 September 2008 (UTC)
Wrong for me as well. I'm annoying #-tech with trying to get it fixed, and they have been doing something which they are not confiding to a mere plebe such as myself. - Amgine/talk 19:56, 18 September 2008 (UTC)
Ah, purging those messages themselves seems to have worked nicely ;-) Robert Ullmann 19:58, 18 September 2008 (UTC)
<grumbles about calling the cavalry> Thanks Robert. - Amgine/talk 20:01, 18 September 2008 (UTC)

Recent Changes

Up until today, the current page count displayed in Recent Changes. It no longer does. --EncycloPetey 20:11, 18 September 2008 (UTC)

Should be fixed now. Robert Ullmann 23:47, 18 September 2008 (UTC)
It is. Thanks. --EncycloPetey 00:21, 19 September 2008 (UTC)

substantialis

This page was obviously deleted by someone, but there are no entries in the deletion log- anyone know what's causing this? Nadando 20:39, 18 September 2008 (UTC)

  • I deleted it. It read "I need help". SemperBlotto 21:24, 18 September 2008 (UTC)
    Do you recall when? It should appear in the Delete logs regardless. --EncycloPetey 21:25, 18 September 2008 (UTC)
  • This morning. About 8 o'clock UK time (07:00-ish). SemperBlotto 21:34, 18 September 2008 (UTC)
It does not appear in the delete log. Something odd going on. Robert Ullmann 05:29, 21 September 2008 (UTC)

MediaWiki:Noarticletext

It used to be that when I'd visit a redlink, I'd see the contents of [[MediaWiki:Noarticletext]]. How come that's no longer the case? It still seems to work for Wikipedia.

Also, unrelatedly except that I discovered it while trying to look through Wikipedia's MediaWiki pages, how come [[Special:PrefixIndex]] copies from to prefix when the latter isn't specified, rather than assuming an empty string? That's a bug, right?

RuakhTALK 17:13, 20 September 2008 (UTC)

I dunno, I tried &action=purge on the page and it seems to be back now. Probably just an issue with the message cache. Conrad.Irwin 17:57, 20 September 2008 (UTC)
Cool, thanks. MediaWiki seems to have gone downhill in this regard. —RuakhTALK 19:16, 20 September 2008 (UTC)
Indeed, someone apparently tried to combine PrefixIndex and AllPages in some way about a month ago, and succeeded only in severely breaking both; despite repeated requests they have not been restored. The people "working" on the s/w seem to be spending their time making things "neater", or adding "features", breaking things as they go; fixing the 1000's of outstanding bugs is not a priority. With volunteers doing things, this will tend to happen, it takes project direction to control it. Robert Ullmann 05:21, 21 September 2008 (UTC)

Extension:Nuke

Fyi: There has been a decision at m:Metapub (link to old version) to add mw:Extension:Nuke to all WMF wikis that don't opt out of it. I know nothing more (not, e.g., when it will be implemented, or how the opt-out procedure will work).—msh210 19:06, 24 September 2008 (UTC)

I would hope that there would be an option to mass restore as well as delete if this were implemented. Nadando 21:52, 24 September 2008 (UTC)
There is no "mass restore". I'd say quite strongly that we want to opt-out; we have not had any serious need for something like this; if we did we have the technical ability to script it when needed (e.g. I essentially have the code; others can do it). And there is no need for a steward to use it to clean up here, we take care of ourselves. (I don't suppose I need point out the downsides of WF aquiring this?) Why it is not restricted to stewards and 'crats is beyond my comprehension. Robert Ullmann 06:32, 25 September 2008 (UTC)
If there is no mass restore, and insufficient restriction as Robert has noted, then I agree solidly with him that we should opt out. We don't have a need for this, and there is too much potential for harm. --EncycloPetey 06:35, 25 September 2008 (UTC)
I, too, feel a bit of apprehension at such a thing. I see no benefit, and a decent amount of risk involved. Please, let's opt out. -Atelaes λάλει ἐμοί 06:38, 25 September 2008 (UTC)
I'm not involved in such technical aspects of working on this project, but I am sympathetic to the concerns raised by other, more experienced editors (Robert Ullmann, EncycloPetey, Atelaes). __meco 08:03, 25 September 2008 (UTC)
I'm with meco: opt out!—msh210 17:45, 25 September 2008 (UTC)
Should we start a !vote to opt out, or should we wait until we know how the opt-out procedure will work? —RuakhTALK 11:02, 25 September 2008 (UTC)
The question has been asked on Metapub by ru.wp and by me. There doesn't seem to be a list or such yet. Robert Ullmann 11:14, 25 September 2008 (UTC)
Is there an implementation date scheduled? DCDuring TALK 11:18, 25 September 2008 (UTC)

Now there is an opt-out list. We are listed on it, but as unconfirmed (it says "link?", apparently seeking a link to where we voted to opt out). I haven't time to draft a vote page for this.—msh210 16:47, 7 October 2008 (UTC)

RC - current nummber of entries

The count seems frozen right now. Normally, it climbs as new "good" articles are added, but it's not changing right now. Is this related to the slow response and numerous server errors today, or is it perhaps a separate problem? --EncycloPetey 21:40, 24 September 2008 (UTC)

Addendum: On the IRC, Nadando indicated that this was a deliberate disabling while MW fixes happen. --EncycloPetey 06:36, 25 September 2008 (UTC)
If anyone is interested in some of the gory detail, see this. One thing to note is that when the counter runs again, it will have missed the new entries in the meantime until an update is run. So don't expect it to jump immediately to the correct value when it starts moving. Robert Ullmann 11:03, 25 September 2008 (UTC)

Seems to be working again, although the count is still off (how often are updates run?) Nadando 07:10, 28 September 2008 (UTC)

The update is a one-off run, done when something has caused to counter to be in error. Don't know when they will run it. The problem may not be fixed yet. Robert Ullmann 15:39, 28 September 2008 (UTC)

{{topic cat parents/Persian derivations}}

Hello, User:CyberSkull has created this template and edited Category:Persian derivations with some strange results, for example at Category:arc:Persian derivations. I would really appreciate it someone could explain to me the purpose of it and the new format or structure for the etymology categories, and if this could be fixed, thanks. Pistachio 12:28, 25 September 2008 (UTC)

I have corrected the template to match other Derivations categories. --EncycloPetey 04:24, 26 September 2008 (UTC)
Thanks :-D How could I edit the new wording 'The following is a list of Aramaic words related to etymology of the Persian-derived words', from Category:arc:Persian derivations and stop it from adding words into Category:arc:Persian language and Category:arc:Iran? Pistachio 07:37, 26 September 2008 (UTC)
I'm not sure about the answer to the first question. The documentation for the topic cat setup has never been properly documented, so I usually have to dig around each time something like this happens. I expect that wherever the text is located, the category problem can be fixed from that location as well. --EncycloPetey 07:41, 26 September 2008 (UTC)
The topic cat templates were never really "officially" changed, although it seems like there has been a pretty substantial shift toward them. If there are specific areas that the documentation is lacking or if you have ideas for some sort of unifying document, I'd be willing to work on it. I think that Template talk:topic cat was the closest I ever came to documentation, but one thing I never did was do a walkthrough or use case-type document. Mike Dillon 04:30, 1 October 2008 (UTC)

Smoothing out page titles

Please create MediaWiki:Pagetitle-view-mainpage with the text "Wiktionary, the free dictionary". This will cause the title bar on Dictionary:Main Page to read simply "Wiktionary, the free dictionary" instead of "Dictionary:Main Page - Wiktionary". The title bar on all other pages will remain the same. —Remember the dot (talk) 22:47, 26 September 2008 (UTC)

That's pretty cute, now all we need to do is stop this "page-contents is stuff that is spelt like the title" idiocy that's so omnipresent :). Conrad.Irwin 22:54, 26 September 2008 (UTC)
Thanks for creating the page for me! What do you mean by "'page-contents is stuff that is spelt like the title' idiocy"? —Remember the dot (talk) 23:02, 26 September 2008 (UTC)
WElll... It's an irritation here that color is a seperate page from colour, that a has so many different sections that are not really related, etc. etc. It'd be nice to do something better, but I've yet to come up with a grand super-plan that didn't have a major flaw. Conrad.Irwin 23:04, 26 September 2008 (UTC)
Ah, I can definitely see how that would be a point of conflict. I hope you guys get it all worked out.
By the way, have you considered using Firefox? It has spell-check built in, so it'd help you avoid common spelling mistakes like "seperate". —Remember the dot (talk) 23:10, 26 September 2008 (UTC)
Spell-checks are only useful if you type common words in a single language. Wiktionary is multilingual and uses extensive coding. --EncycloPetey 23:14, 26 September 2008 (UTC)
True. Spell-check is more useful when leaving comments on discussion pages than when writing dictionary entries. —Remember the dot (talk) 23:29, 26 September 2008 (UTC)

Automate ise/ize variants?

I sometimes create missing ise/ize variant entries manually. In the absence of any wiki mechanism for indicating "this s can be a z" within one article, would anyone appreciate a bot to look at existing English ise/ize words, check for the alternative in some popular word list (or even Google, taking a large result set to mean it's probably a word), and create the "alternative spelling" article if appropriate and missing? Although I'm a fairly competent programmer and wouldn't mind attempting such a project, I haven't worked on a wiki bot before, so somebody of more experience might be able to put it together in minutes. Just an idea. Equinox 00:03, 7 October 2008 (UTC)

Template:en-adj-notcomp

It's time we orphaned and deleted this template. --EncycloPetey 18:13, 8 October 2008 (UTC)

Agreed. -Atelaes λάλει ἐμοί 19:05, 8 October 2008 (UTC)

Should terms used and linked in a defn be listed again in "Synonyms" or "Related terms" or "See also"?

I dislike redundancy and avoid listing a term as synonym or in other subsections if that same term has already been used and linked in the definition. An example I noticed today is epistemological. Defn1 for epistemological contains the term epistemology. Today an editor also added epistemology to the "Related terms" subsection. Another example is simian, where the definition includes the terms ape and monkey (both linked) and the "Synonyms" section also includes ape and monkey. Do we have a preferred practice here? Should terms like these be double-entered or is one usage in the definition all that we need? -- WikiPedant 19:52, 9 October 2008 (UTC)

For long entries (more than one screenful), I'd think that the duplication factor is not as important as the navigation factor. Duplicating near the bottom what appears at the top gives the user a chance to find something good to jump to on another page without having to scroll up or remember to scroll up. For such a short entry I wouldn't have put it below. I wouldn't get into a wheel war about it, one way or the other. DCDuring TALK 20:53, 9 October 2008 (UTC)
Since we're not paper, of course. If a related word is only in the definition, a future editor that rewords the definition, removing the related word, might forget to add it to one of the lower section. In addition, one might want to analyze our entries in a more structured way (eg pulling out synonyms and antonyms). This is only possible we list related terms in the lower sections regardless of their inclusion in definitions. --Bequw¢τ 04:30, 10 October 2008 (UTC)

Should separate entries be created for 2-word (adj + noun) expressions where the adjectival entry already contains an applicable definition?

Today I was contemplating creating an entry for loaded question, but I noticed that loaded already has a sense {{context|of a question}} tailor-written for this expression. I also notice that there is a tailor-written sense of loaded for loaded dice but that we do have a separate entry for loaded dice. Do we have a preferred practice in this sort of situation? On the one hand, I don't like to create a redundant--or sort-of redundant--entry, but, other other hand, a user might try to look up the expression "loaded question." What to do? -- WikiPedant 20:02, 9 October 2008 (UTC)

We could stand to have both, but the word always seems the more important to me for searching. If the sense of the word is really specific to that one idiom (if indeed it is an idiom), I'd favor a minimal sense and a "See" link to the idiom. If it is not limited to the idiom, but the idiom is very common, I'd favor a usage example including the idiom. Less common: 2 usage examples. If there is something special about the idiom, usage note, date, context, attestation, etc., then the user should be encouraged to go to the long idiom entry instead of settling for something short at one of the component words. Just an opinion, though. DCDuring TALK 21:02, 9 October 2008 (UTC)

Misspelling template

So, I've had a few problems getting the code to work with it. Upon bracketing the target word, {{misspelling of|[[raspberry]]}} comes out as "Common misspelling of [[raspberry|raspberry]]." Could someone tech-savvy fix Template:misspelling of? Teh Rote 22:02, 10 October 2008 (UTC)

This is deliberate- we don't want wikilinks on a misspelling page because we don't want it to count in the total number of pages. Nadando 06:02, 11 October 2008 (UTC)
Huh? The template hard-codes a link... I'm not sure what you're talking about. Mike Dillon 06:34, 11 October 2008 (UTC)
The entry-county software counts any entry with double brackets as real. Misspellings are supposed to be outside the count. The appearance that you obtain is intended to discourage cheating the counting system. After all, one could claim that huba, buba, etc were all misspellings of tuba and thereby inflate the entry count, but not the value of Wiktionary. DCDuring TALK 12:53, 11 October 2008 (UTC)
Are you saying that only pages with literal wikilinks in them (not inside a template) are counted toward the entry count? That's pretty cheesy... Mike Dillon 19:14, 11 October 2008 (UTC)
It is even cheesier than that: it is entries with "[[" in the wikitext somehere! Robert Ullmann 12:14, 13 October 2008 (UTC)
Maybe I am missing the point but ... why would you want to write {{misspelling of|[[raspberry]]}} when you can achieve the desired outcome (an internal link to raspberry) by simply writing {{misspelling of|raspberry}}? It can't have anything to do with counting, right, Robert? -- Gauss 23:41, 12 October 2008 (UTC)
I think Teh Rote is just used to linking the parameter for form of templates, and is surprised that this one (intentionally) doesn't allow that. The answer is, just don't link it.
Would be much better if the s/w would just count main namespace entries that did not contain __NOCOUNT__ or some such. There are multiple bugs entered for this, no sign of anything happening. Robert Ullmann 12:14, 13 October 2008 (UTC)

It gets worse: the current count is updated (incremented/decremented) based on the presence of brackets vs the previous version of the page. But the updateArticleCount script uses "actual" outgoing links. So when they ran the script recently after server problems caused the counter to stop for a while, it overcounted by some amount.

In fact, there are 986,887 entries in NS:0 as of a few minutes ago; the counter reads 972,692. Robert Ullmann 12:48, 13 October 2008 (UTC)

If this is correct, am I right in saying we are now over 1 million? (14 k plus the current count). Nadando 05:04, 16 October 2008 (UTC)
As of yesterday's XML dump (15 Oct) we were just short. Today may be over 1M. Robert Ullmann 11:55, 16 October 2008 (UTC)

template:homophones

Could someone with the necessary skills adjust the {{homophones}} template to add optional qualification parameters in the template. Currently it just takes up to 5 positional parameters that link to other entries. This works fine where up to 1 needs qualification, as this is just placed last and the {{qualifier}} template is used. However it doesn't work where more than one link needs qualification, e.g. at wicker the following is needed:

* {{homophones|whicker}} {{qualifier|in accents with the [[wine-whine merger]]}} 
* {{homophones|Wicca}} {{qualifier|in [[non-rhotic]] accents}}

giving the less than ideal

What would be better would be something like:

* {{homophones|whicker|q=in accents with the [[wine-whine merger]]|Wicca|q=in [[non-rhotic]] accents}}

to give:

Actually, as these are the most used qualifications, it might be worth standardising them somehow, maybe something like:

* {{homophones|whicker|w-wh=1|Wicca|nr=1}}

to produce the same as above. Obviously Wicca and whicker are homophones of each other non-rhotic accents with the wine-whine merger, so Wicca might get

* {{homophones|whicker|nr+w-wh=1}}

to give

Thryduulf 10:50, 11 October 2008 (UTC)

As there is no way of telling in which order named parameters are given, this could be very tricky. It might be better to have a seperate template (maybe {{homophone}}) that can be appended after {{homophones}}:
* {{homophones|whicker|r=w-wh}} {{homophone|Wicca|r=nr}}
* Homophones: {{homophone|whicker|r=w-wh}} {{homophone|Wicca|r=nr}}

Using the r= parameter to give a short-hand reason. Conrad.Irwin 13:41, 11 October 2008 (UTC)

Broken categorization?

I have added Categories to the pages collar, marisco, mariscos, mariscal about 30 minutes ago, however the pages still not appear on the Category pages. Might it be that categorization is broken somehow or is the server just to slow? Matthias Buchmeier 19:50, 12 October 2008 (UTC)

The entries appear now in their categories, at least for me. So it was probably a consequence of the major server problems we had today. -- Gauss 23:54, 12 October 2008 (UTC)

New messages template won't go away

Why is it that the new messages template won't go away even when I check my IP talk page? Could the fact that the school district uses three different proxies on completely different IP ranges that alternate at random have anything to do with it? 169.139.98.194 11:52, 13 October 2008 (UTC)

You shouldn't get any given one more than once; but you might see several different ones. Simplest thing would be to create an account? Robert Ullmann 12:05, 13 October 2008 (UTC)
I once made the mistake of editing wikipedia anonymously from a friend's AOL account. I think I went through about 20 message pages before I worked out what was happening. Thryduulf 16:57, 14 October 2008 (UTC)

Han character formatting

Just a note re what I am doing; I, or UllmannBot, have been lax in keeping up with the set of entries for Han characters. I hadn't run the problems report since January, and it went from ~900 to ~2100. A large number of these are from an IP-anon (the one who refuses to use his login) adding Vietnamese without using the template (which he knows perfectly well). Another large set are Korean added w/o the "stub" definition line.

I am running some automation to go through User:Robert Ullmann/Han/Problems and fix the things it has been taught to. It is also adding sort keys to {{defn}} calls, which makes those cats a bit easier to deal with (else each character is listed under itself, not terribly useful ;-). Robert Ullmann 14:18, 17 October 2008 (UTC)

redlink categories?

Is there a report that lists non-empty categories that don't have a category page? RJFJR 14:44, 22 October 2008 (UTC)

Special:WantedCategories Robert Ullmann 14:47, 22 October 2008 (UTC)

Some automation broken at 04:30 UTC this morning

If something of yours stopped working, this is the explanation:

They made a change to the MW software to require the wpSection field be supplied on an HTTP POST to edit a page, even if nil (as it would always be if not section editing. This was a completely gratuitous change.

Worse: it does not return an error when the field is omitted; it just returns the preview page, as if action was preview. So it is very non-obvious what has happened.

So if post (edit) operations that worked before today are now failing, this is likely the problem. If you need help fixing this, please ask me. If you are using a sync'd version of the python wikipedia framework, re-sync it; they have patched the problem.

Sigh. Robert Ullmann 14:32, 25 October 2008 (UTC)

  • Hi Robert. SemperBlottoBot has stopped working - How do I "re-sync" it? (or otherwise fix it) SemperBlotto 16:26, 25 October 2008 (UTC)
If you used svn checkout to get it in the first place, do it again. (After making sure it won't overwrite any modified files in place; e.g. if you modded pagefromfile.py without changing the name.)
If you downloaded a zip file or something, do that again.
Or: edit wikipedia.py and look for lines like this:
   predata = [
            ('wpSave', '1'),
            ('wpSummary', comment),
            ('wpTextbox1', text)]
this will be the first occurrence in the file of predata, in a routine called putPage in older versions, and _put in newer versions. Change it to add wpSection:
   predata = [
            ('wpSave', '1'),
            ('wpSummary', comment),
            ('wpTextbox1', text),
            ('wpSection', '')]
this is in older versions, in newer versions, it is a dict, and it should look like this:
   predata = {
            'wpSave': '1',
            'wpSummary': self._encodeArg(comment, 'edit summary'),
            'wpTextbox1': self._encodeArg(text, 'wikitext'),
            'wpSection': '' }
this should give you some idea of just how crappy the change they made was: it is failing because you aren't supplying an un-needed parameter with a null value. Pfui. Ought to simply be fixed on the WM side. (If you can just edit in the patch, I'd recommend that way of fixing it, as everything else you have is working; no point breaking it. ;-) Robert Ullmann 17:12, 25 October 2008 (UTC)
I have editied wikipedia.py as above (first version) and saved it. When I reran the bot it rebuilt wikipedia.pyc (with no errors) but the bot gets the same errors when it tries to add a page. (Just to prove that the edit was good, here is the part of wikipedia.py copy/pasted)
        text = text.encode(self.site().encoding())
        predata = [
            ('wpSave', '1'),
            ('wpSummary', comment),
            ('wpTextbox1', text),
            ('wpSection', '')]
        # Except if the page is new, we need to supply the time of the
        # previous version to the wiki to prevent edit collisions
        if newPage:
 

Any ideas? SemperBlotto 18:01, 25 October 2008 (UTC)

Hmmm, that's the only change I made. The only difference I can think of is that I'm editing pages and you are creating them. Let me check this out a bit. Robert Ullmann 18:22, 25 October 2008 (UTC)
Good news and bad news: the good news is that that is the difference; creating pages still fails for me; the bad news is that I don't know why yet ... Robert Ullmann 18:36, 25 October 2008 (UTC)
See bugzilla:1181 and r42037, they added a gratuitous check, just as I thought. It breaks page creation for everyone, even with the current pybot. The problem had already been solved by re-ordering the form. Should have the other part of the patch for you in a few minutes. (testing) Robert Ullmann 19:38, 25 October 2008 (UTC)
Okay: a few lines below that, change to:
   if newPage:
            predata.append(('wpEdittime', '1'))
            predata.append(('wpStarttime', '1'))
that is, change the null value to "1". This will work if the page never existed; if it has, and has been deleted, you will get an edit conflict. We'll see what real fix "they" come up with. Robert Ullmann 19:53, 25 October 2008 (UTC)
Better: eliminate the test for newPage, always set the parameters as in the else case:
        predata.append(('wpEdittime', self._editTime))
        predata.append(('wpStarttime', self._startTime))
that was the change added to the framework a few hours ago.
meanwhile Brion is raging once again about people using the GUI instead of the API. Never mind that the edit API has only been available for a few weeks. (*sigh*) So there are many thousands of people out there with this code.
he is taking the superfluous checks out of the MW s/w, but that will take a while to commit and install. Robert Ullmann 20:27, 25 October 2008 (UTC)
Thanks - I went with your latest suggestion (without the check) - everything now works again. SemperBlotto 21:31, 25 October 2008 (UTC)

Editing from two different userids at the same time.

For some time I had been convinced that two of our regular users were manifestations of our old friend Wonderfool. Then I noticed both of them editing at the same time, including two new terms added within seconds. So I tried an experiment. I had two sessions open in Internet Explorer, and logged off one of them and then logged on as a second user (SB2). At my next usage of the other session it had changed from SemperBlotto to SB2 - so use of two userids at the same time was obviously impossible. I then fired up Google Chrome (Firefox would probably have worked as well) and logged on as SemperBlotto. I was then able to edit as SB2 on Internet Explorer and as SemperBlotto on Chrome at the same time, and added two terms within seconds.

I can't think of any way of preventing this, as the two pieces of software seem to hold their own versions of the same cookies. SemperBlotto 10:08, 27 October 2008 (UTC)

I could run FF, IE, and Chrome with 3 different logins. One can also have multiple copies of FF or Chrome, or have multiple log in sessions on the same machine, each with its own cookies. (And I edit as me, UllmannBot, AutoFormat, and Interwicket at the same time ;-). Robert Ullmann 14:28, 27 October 2008 (UTC)

Template:cs-verb

In Template:cs-verb, I want to add a parameter so that if that if all displayed is just {{cs-verb}}, then it would add to a category Category:Czech verbs not classified as perfective or imperfective. I managed to add a parameter to divide them in 2 categories for perfective and imperfective, but I'm having trouble with this newer one. --Ro-manB 15:21, 27 October 2008 (UTC)

It can be done with nested #ifs as you were trying to, but easier to use #switch again, and just put that cat in the default case. I did that, and also wrapped it in a check for namespace 0; take a look, I'm sure you'll understand what I did. Cheers, Robert Ullmann 15:33, 27 October 2008 (UTC)

System crashes trying to go to WT:LOP

Trying to get to WT:List of protologisms (or the link to WT:LOP on the edit screen that opens for the red link) pretty reliably crashes Fedora core 6 running Firefox 3.0.3 here, leading to the Fedora user login screen. After restart, Firefox successfully reinstates the session when asked to do so. So far that's the only page I've tried to get to that does that. __Just plain Bill 18:03, 29 October 2008 (UTC)

In the absence of a set of qualifications for addition to that list, the thing just keeps growing. I move we delete the whole thing. It adds nothing to a respectable, usable dictionary. Perhaps UD would like a transwiki of it. -Atelaes λάλει ἐμοί 19:31, 29 October 2008 (UTC)
Is UD under the GFDL? Thryduulf 21:56, 29 October 2008 (UTC)
I do believe everything on Wiktionary is GFDL. -Atelaes λάλει ἐμοί 05:58, 30 October 2008 (UTC)
I think you misread Thryduulf's question? As you say, everything on Wiktionary, including LOP, is GFDL; so UD can only take a transwiki of LOP if UD is GFDL-compliant. —RuakhTALK 18:59, 30 October 2008 (UTC)
Clearly I should have spent an additional microsecond reading that comment. Sorry. UD does not appear to be GFDL, so no, I don't think they could take a transwiki (I was being largely sarcastic in that comment anyway). -Atelaes λάλει ἐμοί 03:54, 31 October 2008 (UTC)
I think a lot of users do make good use of LOP; the problem is with a few users who go crazy, e.g. adding 50 million "go the way of [] " expressions or 50 million "red/blue [] " expressions (with red=Republican, blue=Democrat) or 50 million adjectives in "-orse" and "-orst" (opposite of "-er" and "-est"). It would sadden me a bit if we deleted a widely-used project page just because of a few users who don't play well with others. (But you're probably right that the page doesn't really add anything, and I'm not prepared to fight for it.) —RuakhTALK 18:59, 30 October 2008 (UTC)
I'm curious as to what "good use" would be. If, by good use you mean adding words in reasonable numbers that they've spent a little time thinking about, then I would be prepared to concede. However, I would respond by asking what good such good use does. I think that the vast majority of words on that list are words with virtually no usage. Now, they might be creative and interesting (and quite frankly, most of them aren't), but they're not descriptive of the language. If WT:LOP had some sort of criteria, say a third of CFI, that might be interesting and useful, as it would be a list of words that have a decent shot at getting into the main namespace in a few years, and thus words to keep an eye on. It would be an efficient way of keeping Wiktionary on the cutting edge of language, something I support. However, as it stands, I think it don't do no one no good. -Atelaes λάλει ἐμοί 03:54, 31 October 2008 (UTC)

This issue may not be specific to WT:LOP since now trying to go to WT:GREASE from the main page crashes my Fedora session. __Just plain Bill 02:16, 30 October 2008 (UTC) and, it may be a corrupt user account at this end; only seems to happen with the one. __Just plain Bill 03:43, 30 October 2008 (UTC)

As Atelaes alluded to, I think it has to do with how huge the pages in question are. —RuakhTALK 18:59, 30 October 2008 (UTC)

{{suffix}}

I tried to make {{suffix}} use term, which worked reasonably well (I only needed 3 edits yet :-) ), but there is one thing that I do not manage: to make the second transliteration show up. Can someone have a look at this? I think simply removing the ss parameter will be the easiest to do and I don’t think it is that useful anyway.

I there a way to specify template arguments in Special:ExpandTemplates? That would make it unnecessary to save changes just to look what the result looks like. H. (talk) 14:08, 30 October 2008 (UTC)
You shouldn't be experimenting on the live template at all. Create {{suffix new}} (or ... 2 or whatever, and try to make it work. In this case, it should be restored to the working version. Then consider whether using term is a good idea: IMHO, almost certainly not. Is already overloaded. Robert Ullmann 18:01, 30 October 2008 (UTC)
While I acknowledge it is better to create a temporary template for experimenting (hadn’t thought of that, sorry), I do not agree that it should be restored. I think it is an elegant solution to delegate to a template that was made for this. H. (talk) 09:20, 31 October 2008 (UTC)
  • As a result of this change, there are loads of new suffixy categories which need to be added - see WantedCategories. How should these new categories be categorised? --Borganised 11:22, 6 November 2008 (UTC)
  • Actually, these changes are independent, although I made them both. Why don’t you go ahead and make some template (not necessarily a wiki template, just a sketch, I mean) for one of those categories, which can then be copied to the others? Something like “This category contains words that end with the suffix ‘-X’. See {{suffix}}, Category:English suffixes.” but with some more layout. H. (talk) 11:43, 6 November 2008 (UTC)
  • Would it be too late to as that the quote marks be removed? They are untypable, ugly and unnecessary. Conrad.Irwin 01:44, 12 November 2008 (UTC)

{{plural of}}

This template does not take full advantage of language or script arguments. For example, in {{plural of|dom|lang=pt}}, the link it creates is simply dom, not dom#Portuguese/dom. And if there is a script argument, it has no effect on the appearance of the link...for instance, {{plural of|كتب|lang=ar|sc=Arab}} (which produces "Plural form of كتب." instead of the expected "Plural form of كتب"). —Stephen 16:48, 5 November 2008 (UTC)

Even for English, it should section-link to English#Noun (or possibly English#Etymology n (where n not equal to 1). DCDuring TALK 17:00, 5 November 2008 (UTC)
Note this is not possible. You can't link to (name) a nested section, e.g. #English#Noun, and linking to a numbered header will just break when the target page is changed. Robert Ullmann 18:03, 6 November 2008 (UTC)
For English it's possible, I think, as it can just link to #Noun. Wouldn't work for other languages.—msh210 06:46, 7 November 2008 (UTC)
Yes, that's what I do by hand. English uniquely has the advantage that it can be omitted. DCDuring TALK 08:24, 7 November 2008 (UTC)
The problem is that people are encouraged to use this template as {{plural of|[[word]]}} in order to increase the page count. This prevents it from doing clever tricks. We should stop doing this for that reason. Conrad.Irwin 01:04, 6 November 2008 (UTC)
That just requires a bit more magic. Yes, at present linking the referenced form prevents/would prevent the section link from being added, but it won't keep the lang= param from categorizing (as it does now), and won't interfere with implementing sc= if desired. Now, if I could extract a #unlink parser function from the developers, there is lots we could improve. But it is hard enough to keep them from steadily breaking things, so I have no hope of getting an enhancement. Eh? (Even tho' simple and useful, and about zero overhead.) (I also find the section linking to be supremely annoying, and wish I could figure out magic (short of JS) to turn the effing things off! For me. I just want the page, not some seemingly random position within. Maybe if it worked properly?) The demand for section linking does make quite a number of things enormously more complex. It accounts for at least 70% of all of our template code complexity, direct and including the side effects. But people endlessly want it ... (;-) Robert Ullmann 17:59, 6 November 2008 (UTC)
The section linking to PoS OR Etymology (never both, I know) only matters for long English sections. It matters less for {{plural of}} than for the verb form templates, like {{past of}}, because verb lemmas often appear last in entries with multiple English PoS. I sometimes do it by hand. DCDuring TALK 20:00, 6 November 2008 (UTC)
Because we have no other, more relevant metric, the entry count has assumed great and probably unwarranted importance. We could well stand to pay greater attention to other figures of merit. Our share of visitors relative to other dictionary sites is not a figure of merit. We need a few measures that more directly connect to the efforts of contributors: number of PoSs by language, number of lemmas (one-word, hyphenated, and other), number of non-stub etymology and pronunciation sections, number of non-conforming (WT:ELE) entries are non-user-based measures. The fact that we have no model of how these measures contribute to whatever service objectives enwikt may be said to have merely affects the effectiveness of our efforts. The measures could still show progress (or its lack) and possibly spur effort (or thought as to direction or new initiatives). DCDuring TALK 05:45, 6 November 2008 (UTC)
It's more than just our metric. WM considers a page with no explicit wikilinks to be "bad" and it gets added to a list of pages that don't link out. If we eliminate linking from within templates like these, then we can't find those pages that truly do need to have wikilinks added to improve them. The links are one of the key ways in which an electronic dictionary improves over a print dictionary. --EncycloPetey 20:17, 6 November 2008 (UTC)
I agree that other metrics are also important. I would just like to have more of them so that the few we have don't take on unwarranted importance. As you know I would like to have measures of success with respect to users (repeat visits, visit counts relative to competitors) and quality measures for the first screen a user hits (how many pagedowns/scrolls to find what they want OR screen-inches to first definition). I wish I knew how to do these things myself, instead of wishing on a star. DCDuring TALK 21:06, 6 November 2008 (UTC)

{{es-conj-er (c-zc)}}

I see that there is a problem with this Spanish template. The reflexive imperatives are missing accent marks. In parecerse, it incorrectly shows: parecete, parezcase, parezcámonos, pareceos, parezcanse...it should read like this: parécete, parézcase, parezcámonos, pareceos, parézcanse. The template is far too complex for me, someone else needs to fix it. —Stephen 04:35, 6 November 2008 (UTC)

Fixed. --Bequw¢τ 09:53, 6 November 2008 (UTC)

Template:ro-decl-adj hides red links

I think it unfortunate that Template:ro-decl-adj shows red links in the normal text color. I did not find a way to undo this, it is probably a CSS issue, I think with class inflection-table. Could someone change this such that red links are red again? H. (talk) 11:17, 6 November 2008 (UTC)

Most inflection templates hide red links. Many people find it ugly to have loads of red links in a table. Having the links present but in normal text color was the compromise found between those who wanted links to exist for entries not yet created and those who didn't want their tables all full of red. Angr 11:29, 6 November 2008 (UTC)
There was a lot of argument about this. See this discussion and others similar. If you want to fix it for yourself, put the following code into Special:MyPage/monobook.css and do the cache-clearing rigmarole. Finding a globally accepted is unlikely to happen. Conrad.Irwin 14:01, 6 November 2008 (UTC)

<source lang="css">

.inflection-table a.new { color: #CC2200; }

</source>

This should be moved to WT:PREFS, so that those who have conniptions when they see red links in inflection tables can select it, and everyone else defaults to the correct behaviour. Conrad, I thought you were going to do this; I was surprised to see it show up in the common css? Requiring users who want standard behaviour to add custom CSS is no good. (I hardly need to tell you that ;-) Robert Ullmann 17:46, 6 November 2008 (UTC)
I thought I was going to do that too, but I think I got moaned at by people who insisted I shouldn't change how things worked without a vote. Conrad.Irwin 01:39, 12 November 2008 (UTC)
It wasn't broken decided by a vote in the first place, and was hardly "resolved". Just do it right. Seriously non-standard wiki behaviour must be opt-in, not opt-out. Robert Ullmann 17:17, 12 November 2008 (UTC)
If you like you can start a vote to overturn the last decision. That way, those of us who agree with this practice can quickly vote it down and not have to endure another long and fruitless discussion on this resolved issue. --EncycloPetey 20:19, 6 November 2008 (UTC)
Agree with EP and Robert Ullmann. This should remain as is, but a WT:PREFS bit would be nice. -Atelaes λάλει ἐμοί 20:52, 6 November 2008 (UTC)
The options are,
  • "No links in inflection tables" (what's the point in linking to form-of entries anyway)
  • "Red links in inflection tables" [with a WT:PREF to go black] (as people won't create the pages if they don't know they don't exist)
  • "Black links in inflection tables" [with a WT:PREF to make it red] (as inflection tables are hard to read if full of red links)
  • "Blue links in inflection tables" (and set up a nifty bot-like thing that will automatically create inflections for trusted users - though there will still be a few "other" links hanging around)
  • "Green links in inflection tables" (and give people accelerated form of creation everywhere - though they may not use it)
  • "Octarine links in inflection tables" (which change both the caption of the link and the link title at random to amuse people like me)
Shall we vote on it, do a bit more bikeshedding, or just choose the obviously correct answer? :p Conrad.Irwin 01:39, 12 November 2008 (UTC)
Just take the line out of common css so we get the correct (default) behavior, and add WT:PREFS to turn them black for people who want that. (and check it against the standard prefs option on displaying "red" links) I thought you were going to do this? Robert Ullmann 17:09, 12 November 2008 (UTC)
See my reply above... Conrad.Irwin 17:11, 12 November 2008 (UTC)
None of this would be a problem if you'd just done it right in the first place (and you know this :-). Please just do that, and then there will be nothing left to vote on. Please? Robert Ullmann 17:30, 12 November 2008 (UTC)
What about the Italian option. Red links in inflection and conjugation tables and a bot to create the forms automagically. SemperBlotto 10:09, 12 November 2008 (UTC)

XML dumps

FYI:

WMF is finally running the XML dump of the en.wikt: http://download.wikimedia.org/enwiktionary/20081112/

The daily for today is done: http://devtionary.info/w/dump/xmlu/en-wikt-20081112.xml.bz2

Tomorrow's daily will be built from the WMF dump, and then proceed forward day by day as usual. Robert Ullmann 17:25, 12 November 2008 (UTC)