• This conversation is lifted from WT:BP#Internet slang. DAVilla

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}}}|...|sub=class name}} where class name could be region, formality, etc. If template such as {{slang}} sets, in this example, formality=slang, then {{context class|internet|slang|sub=formality}} returns Template:context class 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)

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. —Ruakh_TALK 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., .—msh210℠ 16:28, 3 June 2008 (UTC)

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

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" ;-)

• (Received Pronunciation, noun) ...
• (Received Pronunciation, 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)

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 "" 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)

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)

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)

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. :-) —Ruakh_TALK 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 —Ruakh_TALK 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(n²). 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)

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)

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 —Ruakh_TALK 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. :-(   —Ruakh_TALK 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)

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)

• 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 . 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)

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)

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)

• 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)

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)

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)

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)

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)

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. --EncycloPetey 01:24, 22 June 2008 (UTC)

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)

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)

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)

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)