Wiktionary:Grease pit/2007/April

Grease pit archives edit
2024 January February March April May June July August September October November December 2023 January February March April May June July August September October November December
Earlier years 2022 January February March April May June July August September October November December 2021 January February March April May June July August September October November December 2020 January February March April May June July August September October November December 2019 January February March April May June July August September October November December 2018 January February March April May June July August September October November December 2017 January February March April May June July August September October November December 2016 January February March April May June July August September October November December 2015 January February March April May June July August September October November December 2014 January February March April May June July August September October November December 2013 January February March April May June July August September October November December 2012 January February March April May June July August September October November December 2011 January February March April May June July August September October November December 2010 January February March April May June July August September October November December 2009 January February March April May June July August September October November December 2008 January February March April May June July August September October November December 2007 January February March April May June July August September October November December 2006 October November December

Better, more, faster archiving

As broached at WT:BP#Review process, the pages WT:RFV, WT:RFC and WT:RFD desperately need automated archiving.

For each of those pages, sections are identified as "ready for archiving" by striking out the section heading.

At the End of January, we'll know how well the WT:BP archiving works, using WerdnaBot. The WT:GP page currently is archived quite nicely by Werdnabot, retaining links this way and that.

But problems arise for the "Requests for" pages. Here is my understanding of what is supposed to happen (manually or automated) under our current systems (triggered not only by the strikeout, but also in combination with one week's inactivity):

1. Requests for deletion
   1. RFD redlink: The section is moved to WT:RFDA/month year and the section heading is listed in WT:RFDA.
   2. RFD bluelink: The section is moved to the respective talk page and linked as "kept" in WT:RFDA
2. Requests for cleanup
   1. RFC: Section is moved to the respective talk page.
3. Requests for Verification
   1. RFV redlink:
      1. Section is moved to WT:RFVA/month year
      2. moved section is linked from WT:RFVA
      3. Moved section is linked from Appendix:rfvfailed/1st character Alphabetically, hopefully.
   2. RFV bluelink:
      1. If failed sense:
         1. Section is moved to WT:RFVA/month year
         2. moved section is linked from WT:RFVA#Failed senses
         3. moved section is linked from Appendix:rfvfailed/1st character Alphabetically, hopefully
      2. If rfvpassed:
         1. Section is moved to respective talk page

Now, there is a little bit more than meets the eye here. There is the notion of a "speedy" resolution. For such critters, the "Wernabot special" tag <!--Werdnabot-archive--> can be added to such a section if and only if there is no controversy whatsoever, and the section has had a day or two for comments.

I currently have a copy of Werdna's Perl script in my directory on toolserver. I plan to fork it, and create a version for RFC first. If I can figure it out, that will make creating another version for RFD a bit easier. If I can figure that out, then we'll need another magic tag to distinguish a failed RFV sense from an RFVpassed. (Perhaps just check for the string "rfvfailed" or "rfvpassed"?) When I've finished creating that fork, I'll throw the whole mess back to Werdna, and see if he wants to integrate any of those features, or otherwise clean up my sloppy Perl code.

Sound like a reasonable approach? --Connel MacKenzie 22:36, 31 December 2006 (UTC)

---

Interim stop-gap measure

Taking a step back, since the WT:BP conversation was more about interim solutions, here goes:

For WT:RFD, WT:RFC and WT:RFV, turn on Werdnabot archiving to the subpages:

Wiktionary:Requests for deletion/purgatory

Wiktionary:Requests for cleanup/purgatory

Wiktionary:Requests for verification/purgatory

and use monthly section header breaks on those pages as needed. On the three respective pages, tag any item that is 1) struck out and 2) Inactive for a week with the <!--werdnabot-archive-->. Leave the werdnabot expiration at 365 days or so, so that only inactive items get sent to purgatory.

Someone can then take on the smaller task of clearing out the purgatory pages manually (and gee, instructions can be retained on the top of those purgatory pages.)

When the software branch becomes available, the purgatory pages can simply be merged into the parent page, and the remaining items will then get the full magic treatment (since they would still be inactive for more than seven days, and still be struck out.)

This much of it, anyway, I can turn on later today, if no one objects. --Connel MacKenzie 19:35, 1 January 2007 (UTC)

Ya know, why don't we have "disposition" templates? I.e. {{process-deleted}}, and {{process-kept}}, {{process-sense-failed}}, {{process-sense-kept}}? That would make the distinction (for bots) quite a bit easier. --Connel MacKenzie 18:43, 3 January 2007 (UTC)

How about simplifying your archiving outline by (1) always keeping any discussion in an archive if there is one (i.e. for RFV and RFD but not for RFC), (2) always keeping any discussion on the talk page if the page exists, using a generic {{process|template name}} on the request list to close the request, e.g. {{process|rfv-passed}}. This is extensible since new decision outcomes e.g. for new processes can be implemented with new templates without modifying the bot archiving code. (By the way, junk the comment tag if you use these disposition templates.) DAVilla 19:11, 3 January 2007 (UTC)

Sounds good. Care to set that up then? --Connel MacKenzie 19:19, 3 January 2007 (UTC)

Actually, I wanted separate process tags, so they could have a stupid logo (a la the voting logos.) Do what you think will work, and lets see a couple examples on each page, OK? --Connel MacKenzie 19:21, 3 January 2007 (UTC)

I've set up {{process}} and put up three examples commented "This is a test". DAVilla 20:22, 3 January 2007 (UTC)

Drat. For the un-modified Werdnabot to recognise them, they'll need <!--Werdnabot-archive--> subst'ed in. --Connel MacKenzie 00:36, 4 January 2007 (UTC)

It sounds like it would be more difficult to set up the un-modified archival than it's worth. The instructions would have to be written and then re-written, or if we're the ones doing it then do we really need Werdnabot this one time? How soon are you looking at modifying the code? At minimum all you have to do is change the magic words. 04:03, 4 January 2007 (UTC)

Writing Perl is trickier than reading Perl. I might have something working by the end of February, at this rate. Anyone have other ideas on better manual archiving? --Connel MacKenzie 18:18, 24 January 2007 (UTC)

#

I noticed we don't have an entry for the number symbol, #. It seems, however, that to make one, one would have to do some actual hardcode change to Wiktionary. Maybe one of you super wiktionary people can figure out a way to make a # entry :-)

Incidentally, what led me to notice the above, was my attempt to make a #2 pencil entry which would redirect to number 2 pencil. Seems the number sign is not liked as a starting character for entry names in general.. whoever can figure out how to make the #2 pencil entry, will win the unofficial Wiktionary super user of the month award :-) — This comment was unsigned.

You mean, like creating an entry for no. 2 pencil, and having 2 pencil redirect to it? --Connel MacKenzie 00:28, 6 March 2007 (UTC)

"#" cannot be used at the start of a Wiktionary entry because it is parsed as an anchor in a URL. No idea how we could get round this, incidentally, but I thought you might like to know why it doesn't work. — Paul G 15:01, 7 March 2007 (UTC)

Translation

Heres an idea of how to make translating easier for contributors.

Categories are a very powerful tool. Is there in some way an invisible category that could alert editors? but not be seen by people who are simply just reading the page?

What could be done with this, is on all english words, add a category that says if it has had a translation yet. If it hasnt, the category of all english words, could be compared against the english words with translations, easily making a quick list of pages that need translations.

Please everybody tell me what you think of this.

Bearingbreaker92 16:33, 3 March 2007 (UTC)

I haven't dont the hiding code for the "Translations to be checked" categories yet. This sounds like a very similiar approach, only a much wider reach. Would such a thing be limited to the top 18 languages, at first? --Connel MacKenzie 00:25, 6 March 2007 (UTC)

Perhaps we should just try out a test language to see how effective this system is. Personally I would choose spanish.

The only problem I can think of is pages with multiple meanings. Like for example, ham would be a very easy word to do this on, as there are very little definitions. But something like well would have alot more translations. Bearingbreaker92 22:39, 7 March 2007 (UTC)

Hebrew Characters

Some work has been started on making inflection templates for Hebrew words. One of the primary issues that I'm grappling with on this subject is the issue of vowel markings. What I'd like to do is have an input of only the three letters of the tri-root, and have the template spit out the full inflection. This may or not be possible. The thing which makes this tricky is the need to attach vowel markings to letters. For example, with the preposition אל, at some points the letter aleph has a tsere attached to it (אֵ), as in the 1st person plural, but at others it has a chatef-patach attached to it (אֲ) as in the 2nd feminine plural. Does anyone know of any way that we could program the template to accept the three letters as the three inputs, and then program it to attach a certain vowel marking to a certain letter at a certain form? Atelaes 22:00, 7 March 2007 (UTC)

Is there anyway to make categories automatically include other categories?

Hi :-) It would be nice if, for example, putting something in Category:English nouns that lack inflection template would automatically also put it in Category:English nouns, and so on. Is there any way to set this up???? Signed, Language Lover

The "custom" tag templates can add as many categories as they need to. Highly used templates, should not be edited much (for job queue concerns) but if it is a one-time edit, I don't see a problem with it. --Connel MacKenzie 02:34, 9 March 2007 (UTC)

Since Category:English nouns that lack inflection template is already a sub-cat of English nouns, what is the point? they will get moved as they are fixed. (If they are actually English nouns...) These entries aren't templated anyway, so Connel's comment doesn't apply), hence the category, eh? Robert Ullmann 15:21, 11 March 2007 (UTC)

American reminder

To convince MediaWiki to use Daylight Savings time, now in effect, go to Special:Preferences on the [Date and time] tab, and click "Fill in from browser." --Connel MacKenzie 10:09, 11 March 2007 (UTC)

Scots Gaelic & Scottish Gaelic

Having established that Scots Gaelic and Scottish Gaelic are the same language (discussion), and that we have a significant number of entries on Wiktionary in the language, but they are divided between the two headers (statistics), I request that a robot be commissioned to standardise the headers to one name or the other (Scottish Gaelic seems to be the preferred name). -- Beobach972 19:37, 7 March 2007 (UTC)

We need to change template {{gd}} to reflect this. There are ~820 entries with headers to change, and ~670 with references in the translations section (later is not based on an exact count). There are also a few other variants. Robert Ullmann 14:49, 8 March 2007 (UTC)

Oh, I meant only that Scottish Gaelic seemed to be the preferred name based on the TR discussion. If it's easier to keep the more numerous references to Scots Gaelic, I personally have no objection to that. (Do you think we ought to hold a vote on which one to use?) -- Beobach972 17:15, 8 March 2007 (UTC)

I also request that the robot (or another robot) standardise the categories to one name or the other. -- Beobach972 17:15, 8 March 2007 (UTC)

The bot code identifies 818 headers, 525 translations, 121 translations to be checked, 23 translations which are Scottish Gaelic and not wikilinked, 231 category references, and 70 section references to be fixed. Ready to go. I'm not sure it needs a vote. (Having one name is policy, not controvesial.) Maybe we just bring it up on BP. Robert Ullmann 15:18, 11 March 2007 (UTC)

Ok, if you're ready to go, go ahead :), whatever the proper procedure for that is. Hurrah for standardising the Wiktionary! -- Beobach972 17:45, 11 March 2007 (UTC)

I (and the discussion so far) prefer Scottish Gaelic for purposes of clarity over using Scots Gaelic. --EncycloPetey 04:03, 12 March 2007 (UTC)

Category:English nouns

Last year's wheel war (which resulted in an absent bureaucrat and one or more sysops and bot operators) left Category:English nouns, Category:English plurals and templates such as {{plural of}} in an inconsistent state. We currently have many foreign-language entries in Category:English plurals. I plan to start bot-cleanup on them, but help meanwhile is appreciated. --Connel MacKenzie 12:06, 11 March 2007 (UTC)

Just remember that outside English, "plural of" does not imply that the word is a noun. Adjectives have plurals in many languages. So, a bot cleanup might have to consider both language and POS. --EncycloPetey 22:01, 13 March 2007 (UTC)

Mismatched Categories

The newly created Category:el:Etymology has somehow acquired a number of stragglers which don't belong there. If you go the the category page, and click on the + to expand the subcats. you'll see a number of subcategories which don't belong there. Category:el:Ancient Greek derivations is listed as a subcategory, as it should be, but the rest should not be in there. None of them are tagged as part of that category. Does anyone have any ideas why they're showing up there? Atelaes 20:28, 13 March 2007 (UTC)

Could be something in the way that one of the etymology templates is configured. --EncycloPetey 21:59, 13 March 2007 (UTC)

Changing AHD to enPR on the edit page

It has been voted to rename Wiktionary's US dictionary style phonemic alphabet enPR. This has yet to be changed in the little special-character-set fold-out menu down the bottom of the edit page. Newcomer might not realise that AHD means "enPR". Jimp 08:14, 16 March 2007 (UTC)

Change in wiki software? Or did I mess up my browser?

Since about half an hour, whenever I edit a page which contains non-Latin1 characters and ask for a preview, all those characters get replaced by their HTML entities. I cannot remember having done something to my Firefox 2.0.0.2 that would cause this. Do others experience this same problem? The same happens on Wikipedia. H. (talk) 12:01, 8 March 2007 (UTC)

I’m using the latest Mozilla Firefox browser, and I have not had this problem. —Stephen 16:56, 8 March 2007 (UTC)

It was a bug in Firefox: bug 373319. H. (talk) 16:38, 18 March 2007 (UTC)

{{isValidPageName}}

This template returns valid for arguments like '''test'''. I think it shouldn’t. This messes up {{en-adj}}, for example (see widescale, which would be fixed if one gave most widescale as second param). Can someone fix this or explain me why it isn’t so and in that case fix {{en-adj}}? H. (talk) 11:49, 16 March 2007 (UTC)

Why did you change the calls in en-adj? You've broken the general case (no params). It was working fine. And gives the correct result for widescale as far as I can tell? Blank parameter has to test valid. (I put it back) What is it you were trying to get it to do? (And '''test''' is a valid page name ... ;-)

And note that in general if something refers to its own pagename, using [[page]] is preferable to '''page''' since it will display correctly, (bolded), but also work as the link if copied/moved elsewhere. In this case write '''most [[widescale]]'''. Mind you it should be handling the case of the second parameter null better somehow? Robert Ullmann 13:49, 16 March 2007 (UTC)

Absolutely not. That "trick" is only used when templates are used to share content between pages. The convention is to not use [[wikification]] to embolden text. Evar. --Connel MacKenzie 16:12, 16 March 2007 (UTC)

No default case for blank for the switch on parameter 2. I'll fix it ;-) Robert Ullmann 13:49, 16 March 2007 (UTC)

Fixed, should be less surprising to users. Robert Ullmann 13:49, 16 March 2007 (UTC)

Thanks for the answers and the fix (though I think I have to study it a bit more...). H. (talk) 16:44, 18 March 2007 (UTC)

Stop the presses

Wait just a minute. Take back a major premise. The German versions of de:Template:trad and de:Template:trad- and the French version of fr:Template:trad and fr:Template:trad- are compatible, but they are also very simplistic at the moment, taking only two paramters. No script, no gender or number, or the like. The Germans actually use de:Template:Ü which works with two parameters, but with three parameters shuffles them around, which is a Bad Thing™. The three-parameter version has a section link as the second parameter, including the #, so would be completely incompatible with us. Then they have a number of other templates, the most complete of which is de:Template:Üxx5, including alternate text (we use alt= instead) and even the transliteration. The German template de:Template:t is merely a redirect to de:Template:Ü for compatability sake, with us I believe. In fact the French template fr:Template:t has a completely different purpose. So I think it would be entirely possible to redefine our {{t}} as everyone agrees would be best, and then write {{trad}}, {{tradmême}}, {{Ü}}, {{Üxx2}}, etc. here, calling {{t}} in a way that is compatible with the corresponding templates on the FL wikis. The robot, if it identified these strange templates, would only have to subst: them to get the correct {{t}} code. DAVilla 18:16, 6 April 2007 (UTC)

My concern above was only that the use not be suprising; I don't think we actually need to have compatible templates under those names. (we have trad and trad- because those existed before t, and are a no-brainer. ;-) Robert Ullmann 15:16, 11 April 2007 (UTC)

Bot replacement needed

The 3-letter template names {{nom}}, {{dat}}, {{gen}}, and {{acc}} all need to be replaced by a bot. Someone (at some point) decided to use them for grammatical templates, but they conflict with ISO language codes for which they are resevred. If it were only a few pages that called them, I'd do it by hand, but the {{nom}} in particular shows up in a huge number of Greek pages. Either these templates need to be replaced with hard-coded text or swapped out for new (as yet uncreated) templates. --EncycloPetey 17:13, 1 April 2007 (UTC)

Would we still need to reserve this space if {{#language:xx|en}} is implemented? DAVilla 17:33, 1 April 2007 (UTC)

Yes, the primary purpose is so that people can subst: them and get the standard language name. Note there are other conflicts, rfc, rfd, rfv, top, mid, etc. are all in the 3-letter space; I looked at them all a while ago, and didn't see any troublesome conflict. There are conflicts: top is Papantla Totonac, mid is Mandaic (500 speakers ;-), nom is Nocamán, an extinct language that had 3 speakers in 1925. I wouldn't worry too much for now, but it/they may need fixing presently Robert Ullmann 17:42, 1 April 2007 (UTC)

The template {{nom}} is the only one that's been widely used up until now, but there is a contributor for Faroese entries who is making heavy use of the templates. It would be better to address the problme now for gen, dat, acc while there are still relatively few uses. --EncycloPetey 18:19, 1 April 2007 (UTC)

What about {{mf}}? DAVilla 18:11, 1 April 2007 (UTC)

There is no such ISO code, so it isn't a problem. It's the three-letter combinations that are wholly reserved for language name use. Two-letter combinations are only reserved when the combination was used for an ISO code. --EncycloPetey 18:14, 1 April 2007 (UTC)

Theoretically, {{mpl}}, {{fpl}}, {{npl}}, and {{cpl}} should be reserved, but unlike nom & co. only {{mpl}} currently exists as an ISO code with an SIL entry (Middle Watut spoken in New Guinea). --EncycloPetey 18:17, 1 April 2007 (UTC)

Move to {mp} {fp} {np} and {cp} possible? Or what about a different syntax like {m/f} etc.? DAVilla 19:12, 1 April 2007 (UTC)

What about renaming the grammar templates to {{-nom-}}, {{-acc-}}, and so on? Then we might also have {{-mpl-}}, {{-fpl-}}, if needed. ArielGlenn 01:36, 2 April 2007 (UTC)

Connel pointed out to me that on most wikts the leading hyphen means that the template generates a section heading, which we probably don't want. So much for that idea... ArielGlenn 03:17, 2 April 2007 (UTC)

How about using a period? {{nom.}} {{acc.}} are obvious, either {{m}} or {{m.}} should work, and any of {{mpl.}}, {{m.pl.}}, or {{m.pl}}. DAVilla 09:17, 11 April 2007 (UTC)

Why not just move {{nom}} to {{nominative}}, then do the bot replacements? --Connel MacKenzie 03:40, 2 April 2007 (UTC)

More... {{pos}} can probably be deleted or moved to a different space. What about {{law}}? Can we not label anything contextually with three lower-case letters? DAVilla 20:13, 5 April 2007 (UTC)

I think {{law}} is a pretty special case. But now that you've mentioned it (well, yes, it was incorrect from the start) I fully expect Muke, Vlad or Hippietrail to run over to Ethnolog and report the new language "Lawathoosian" they discovered.  :-)

Sigh. Yes, {{law}} should be moved to {{legal}} and $ python replace.py -ref:Template:law "{{law}}" "{{legal}}" should be run. --Connel MacKenzie 20:48, 5 April 2007 (UTC)

You would also have to replace {{context or cattag|...|law|...}} with {{context|...|legal|...}} or we could at least check the "What links here" for Template:law and do it manually, unless you want me to incorporate that as an exception to {{context}}. DAVilla 13:06, 7 April 2007 (UTC)

It's the little things that count

Has anyone looked up linking on MediaWiki?

A pipe '|' immediately before the closing bracket pair ']]' creates a piped link which hides the first prefix of the link and the part in parentheses when it is displayed.

The example given is [[w:a (b)|]] => a displays as w:a (b) right now but should be just a the next time the software is updated.

Yes, I'd noticed that the Germans are already making use of this feature in their interwiki translation templates. --EncycloPetey 17:22, 1 April 2007 (UTC)

Actually, you just forgot the pipe, I added it, and see what happens! H. (talk) 09:47, 5 April 2007 (UTC)

For as long as I can remember, Wiktionary has vehemently avoided the "Wikipedia disambiguation-style" link described above. What good would that do to have turned on here? --Connel MacKenzie 03:36, 2 April 2007 (UTC)

The parenthesis are not too useful, but how often do you have to hide the prefix? I find it really frustrating to have to do in batch or to include in code when the arguments are really long and then have to be repeated. I'm hoping that the section link following # will also be hidden. DAVilla 06:38, 2 April 2007 (UTC)

It is already working, e.g. [[w:minuscule|]] becomes minuscule. Section links do not work, however: [[WT:GP#Parameters in template calls|]]. H. (talk) 09:47, 5 April 2007 (UTC)

Definition templates as sentences; question about templates

Is it appropriate that the definition templates (those you get when selecting "Templates" from the pull-down menu under the edit window) should give full sentences ending in full stops (periods)? This makes them inflexible when extra information needs to be added.

For example, see Euro (the English section). The definition reads "Alternative spelling of euro (the currency and coin)", but in order to get the gloss to fit neatly alongside the definition, I had to replace the template {{alternative spelling of}} with its expansion, or else I would have got the ugly-looking "Alternative spelling of euro. (the currency and coin)". The gloss is needed, by the way, because "euro" has a homograph with an entirely different meaning.

Not the first time this issue has been mentioned. But since you raised it this time and not me maybe someone will listen, minor though it may be. DAVilla 16:55, 2 April 2007 (UTC)

An unrelated issue... I have never seen it explained anywhere what the templates [[lang:lexeme]] seen at the bottom of many pages are for. What do they do? Are they place-holders for words that have not yet been translated into the specified language? — Paul G 15:56, 2 April 2007 (UTC)

Paul - these generate the interwiki links that show up in the "in other languages" section over on the left at the bottom. SemperBlotto 16:00, 2 April 2007 (UTC)

(First issue:) because the gloss should always come first in the wikt style:

1. (currency and coin) Alternative spelling of euro.

and in some cases should be a context tag. Robert Ullmann 21:58, 2 April 2007 (UTC)

Robert, that is not my understanding of our format for glosses, but that seems to work well for this example. The difference Paul seems to be describing is broader, though. European (or just British?) dictionaries seem to avoid complete sentences like the plauge. The theory I've heard described is that the definitions given (in that style of dictionary) are meant to replace the defined word, in any sentence, no matter how incomprehensibly long the definition is. To accommodate the "replace-the-word" style, would require a "gloss=" parameter in each of those "form-of" templates. For me, I'd normally write the qualifier as a separate, complete second sentence. --Connel MacKenzie 05:40, 3 April 2007 (UTC)

It wouldn't require a gloss parameter. Just take the period out of the templates. DAVilla 06:51, 3 April 2007 (UTC)

Doing that would require a bot-run, first. That seems ridiculous. --Connel MacKenzie 20:44, 5 April 2007 (UTC)

It may have been more feasible in May 2006 or even June 2006, but no one thought it was a major issue then. And guess what? It still isn't. You don't have to run a bot since this isn't a priority update. It could be rolled into AutoFormat or the like. DAVilla 13:00, 7 April 2007 (UTC)

I also strongly wish this to be changed. There are innumerate damn, what’s the right word again, ‘an infinite number’ is so long and slightly exaggerated cases where the full stop is just annoying. I don’t have them in my head, but can make a list of them when I stumble upon them. H. (talk) 15:05, 11 April 2007 (UTC)

Innumerable? Numerous? — Beobach972 01:47, 1 June 2007 (UTC)

I agree, the . should be removed from the templates. This is not related to substituting words into sentences, it is related to adding qualifiers without having to use choppy sentences to do it. In that sense, it has more to do with substituting templates into sentences. — Beobach972 01:45, 1 June 2007 (UTC)

Are you prepared to run a bot change to all ocurrences of the template, and add the period to those entries, before changing the template? If not, then the propsal is moot. --Connel MacKenzie 07:17, 1 June 2007 (UTC)

Changing ls= to lang= in t/t-/trad/trad-

Connel requested that I use lang= consistently with many other templates. It also makes one use more explicable, using lang= when you don't know the code and leave it blank. Robert Ullmann 22:04, 2 April 2007 (UTC)

Remember that your bot can determine the language even of simple links just by looking at the beginning *Language: information. I'm not sure leaving the language code blank in {t} would ever be of much use since the interwiki link can only be provided when the language code is known, and within the template it's completely impossible (sorry for the sarcasm) to determine the language code from the full language name. So in the majority of cases using {t} without a language code doesn't do that much more visually than a simple link would. DAVilla 07:03, 3 April 2007 (UTC)

Yes, the only immediate thing is the template has the section link; but it also makes for a simple(r) case for the bot where it can be fairly complicated. *language: {t...} is easy, but when six different languages are listed under "Chinese", it gets a bit more complex: the code has to remember the group tag (for the Serbian/Roman/Cyrillic case), and then look at the sub-tag (for the Chinese/Cantonese/Hakka/Wuu whatever) case, and then decide what it should do. At present it is just looking at the template. Robert Ullmann 10:38, 3 April 2007 (UTC)

There are an unlimited number of requests that we can make for a bot, and if figuring out the language code within the template itself is the first necessary step, then it has to be so. DAVilla 11:48, 3 April 2007 (UTC)

Parameters in template calls

I should have noticed this a while ago, but it just dawned on me in the last few days: do people realize that you can pass blank parameters to a template?

For example, en-adj and en-verb go through amazing convolutions to handle different numbers of parameters. It would have been a lot easier if, say for en-verb, it just gave the form or ending for each irregular form in a fixed sequence, with the others left blank?

Take {{t}}, four parameters: code, word, gender, number.

Do you get that:

{{t|fr|chat|m}}
{{t||jakuma}}
{{t|sw|watoto|p}}

produces:

chat m
watoto pl

While, to be a bit silly:

{{t|3=m||chat||||1=fr}}
{{t|2=jakuma}}
{{t|1=sw|2=watoto|3=p}}

produces ... ah ...

chat m
watoto pl

See? you don't need to specify "xx" or something for a skipped parameter. You just skip it with ||. (The use of numbers is a bit much, but there are some declension templates where the calls might very well.) Robert Ullmann 23:28, 2 April 2007 (UTC)

Yes, of course. It's even possible to test for a blank parameter, e.g. the difference between {{t}} and {{t|}}. DAVilla 07:06, 3 April 2007 (UTC)

Oh, I get it. That blank parameters are possible wasn't apparent because they weren't allowed in {{temp}}, just as they aren't allowed on w:Template:tlx, the lame Wikipedia version. I've now modified {{temp}} to display blank parameters correctly. DAVilla 23:42, 4 April 2007 (UTC)

Little bug discovered!

I noticed if you are editing something and someone else edits it first, you'll get a special screen to deal with that appropriately. Our programmers sure rock :-D *high fives all around* Right now the same does not happen if someone reverts or deletes the entry while you're editing. In that case, your edit will go through. Even if that means re-creating the article. Recently for example someone deleted an article at the same time someone else was requesting it for speedy deletion. This caused the article to be instantly recreated (but with the deletion tag added). Hehe, silly :) Language Lover 02:17, 5 April 2007 (UTC)

Well, I guess that is something for MediaZilla, the bug tracking system, why don’t you add it? See WT:BUG. H. (talk) 09:43, 5 April 2007 (UTC)

I don't know about reversions, but I thought I'd gotten a notice about deletion before. May have been a different case though. DAVilla 13:48, 5 April 2007 (UTC)

I don't see this as a "bug". What is happening is that the page is deleted, then someone else "recreates" it. You can't generate an edit conflict message if the target article doesn't exist because it was deleted. If we did that, then every "new" article with a previous deletion would generate that message, and currently that feature is reserved for sysops. --EncycloPetey 14:09, 5 April 2007 (UTC)

No, you can generate a message based on the time that the edit started and the time that the last change (save, deletion, or what have you) took place. I just tried it and in fact I got a message stating "User DAVilla (talk) deleted this article after you started editing with reason: no longer needed Please confirm that you really want to recreate this article." Included was a check box labeled "Recreate" and unchecked as a default, the usual GFDL notice, plus the edit summary and buttons, and, oddly enough, the drop-down character menu.

However, Language lover is correct that a rollback does not produce an edit conflict and probably should. DAVilla 20:29, 5 April 2007 (UTC)

Hmmm. I could be wrong, and if so then forgive me!!! :) It seems it would just be a matter of keeping track of when the contributor hit "edit" (which it must already do anyway since it gives the edit conflict messages) and only check for deletes which occurred between that time and when the contributor hits "save page".  :-) Language Lover 14:28, 5 April 2007 (UTC)

Incidentally, I don't think the deletion logs are reserved for sysops? Unless I misinterpreted you. I can see the deletion logs by going to the "view history" and then clicking "view logs". It also shows move logs and patrol logs. :-) (If the article doesn't exist, you can still do this by doing it for an existent article and then manually altering the URL. See [1] for an example) Our programmers seem to have thought of everything!!! :D Language Lover 14:30, 5 April 2007 (UTC)

Yes, the logs are accessible even to anons, e.g. from Special:Logs, but rather indirectly. They don't show form the page itself if you're registered on a non-sysop account. DAVilla 20:40, 5 April 2007 (UTC)

I wasn't referring to the Deletion logs, but to the sysop message indicating that there are previous deletions when a sysop attempts to create a page that has been previously deleted. I don't believe this message appears for non-sysops, since it is phrased as a "Do you wish to restore?" question. --EncycloPetey 00:18, 6 April 2007 (UTC)

Yes, that is correct. DAVilla 06:38, 6 April 2007 (UTC)

As User:H. pointed out above, please report this on bugzilla. --Connel MacKenzie 20:43, 5 April 2007 (UTC)

Thanks Connel, unfortunately I don't know what bugzilla is. (At the time I'm writing this, that link is red) Hopefully someone else will help out by making the report, thanks everyone! :D Language Lover 23:05, 5 April 2007 (UTC)

This is bugzilla Tim Q. Wells 06:44, 6 April 2007 (UTC)

Serial comma

How does one get this comma to display? I can't find it in any of the preferences, either the tab on top or on WT:PREF. DAVilla 11:47, 6 April 2007 (UTC)

WT:CUSTOM#Serial commas? --Connel MacKenzie 19:41, 6 April 2007 (UTC)

Good lord. Okay, in {{context2}} a full stop (.) now indicates a serial comma. Do I need to wrap this with <span class="ib-comma"> or is <span class="serial-comma"> sufficient? DAVilla 20:57, 6 April 2007 (UTC)

Serial comma? WTH does that have to do with the price of tea in China? --Connel MacKenzie 05:01, 7 April 2007 (UTC)

• Two things:
  1. You can edit the "custom.js" thing to also do serial comma as a WT:PREF. Remeber to turn on Firebug and make sure you roll back any harmful changes quickly.
  2. The serial comma is completely inappropriate for what Paul was asking about elsewhere. Adding a "g=" or "gloss=" parameter (or even an positional parameter) would do the trick much more elegantly.
• --Connel MacKenzie 05:03, 7 April 2007 (UTC)

Thanks. I don't think I'll be editing custom.js, I'm too scared, but the serial comma could be useful some day, couldn't it? Or should I just leave it out of everything I do?

My question was unrelated to Paul's. I was rewriting {{context}} to fix Special:Wantedpages. DAVilla 11:38, 7 April 2007 (UTC)

I agree that "serial comma" should be in WT:PREFS & /custom.js.

I know things change pretty quickly, when they do change here, but am I missing something? It looks to me like the biggest culprit for Special:Wantedpages now, is {{nav}}, right? --Connel MacKenzie 15:49, 11 April 2007 (UTC)

What a headache! How are we ever going to maintain a topical hierarchy that has to be exactly replicated for each of several hundred languages? Shouldn't {{nav}} and even subcategorization be restricted to the unprefixed category name? DAVilla 01:16, 12 April 2007 (UTC)

Quite the opposite, I'd think. The "invalid prefix" categories (e.g. Category:en:Slang) can easily be entered as redirects (and that is a much, much smaller number of categories!) The others remain black text (unlinked) if the category in question doesn't exist. --Connel MacKenzie 05:20, 14 April 2007 (UTC)

New bug; BIG display problem

Sometime in the past 12 hours or so, some sort of change was made that is affecting all the Word of the Day entries with more than one definition line. Instead of displaying them as a concise numbered list, the list skips from 1 to 3, with no 2 in between. We therefore have a bad format displayed on the Main Page, which makes us look bad.

Example:

There haven't been any recent edits to the {{wotd}} template, so I don't know what's causing the problem. The problem does not seem to affect normal definitions lists, so it must be some code or template called by {{wotd}} that was changed. --EncycloPetey 15:34, 6 April 2007 (UTC)

Tim Starling updated "tidyhtml" on all servers yesterday. I suppose the problem (for multi-line items) is the SPAN I put in there for the RSS feed, crossing boundaries of numbered list items, confusing the heck out of tidyhtml. --Connel MacKenzie 15:44, 6 April 2007 (UTC)

Yes, I noticed that the first # occurs before the span but the second # occurs within. The result of closing HTML tags such as <dl> and <span> in the wrong order is undefined. This is not very clean, so it may be contributing to the problem. DAVilla 15:46, 6 April 2007 (UTC)

• http://lists.wikimedia.org/pipermail/wikitech-l/2007-April/030790.html

Any ideas on how to get the span before the "#"? --Connel MacKenzie 15:51, 6 April 2007 (UTC)

Note that any RSS stuff I do automatically happens one minute after midnight UTC - the rest of the day, the RSS page is static. So I can fix that later. --Connel MacKenzie 15:55, 6 April 2007 (UTC)

It is the span (removing it fixes the problem), but not just that:

{| cellpadding="0" cellspacing="0" width="100%" style="border:1px solid #aaa"
|
{| width="100%" cellpadding="2" style="background:#f9f9ff"
| colspan="4" valign="top" |
# <span id="foo-bar">one
#two.</span>
|-
|}
|}

one two.

Putting it inside one table seems to be okay; inside two nested tables and lookee what happens! Robert Ullmann 16:19, 6 April 2007 (UTC) Oh, and it doesn't matter if the first # is inside or outside the span. Robert Ullmann 16:21, 6 April 2007 (UTC)

Replaced with single table. Robert Ullmann 16:31, 6 April 2007 (UTC)

• Fixed, sortof. --Connel MacKenzie 16:42, 6 April 2007 (UTC)

Robert, don't change the #$%^ing example above. Repeat it as needed, but don't change it as I'm looking at it, please.

(okay, sorry) Robert Ullmann 16:50, 6 April 2007 (UTC)

Sorry I yelled; I was discussing it in #wikimedia-tech, and someone was actually looking at it (miracle!) when you changed it. --Connel MacKenzie 05:05, 7 April 2007 (UTC)

At this point, I wish to strangle w3c. A "span" used to be valid anywhere, now can no longer surround block elements. Jerks. --Connel MacKenzie 16:45, 6 April 2007 (UTC)

{| width="100%" cellpadding="2" style="background:#f9f9ff"
| colspan="4" valign="top" |<span id="foo-bar">
# one
#two.</span>
|-
|}

one two.

and then:

<span id="foo-bar">
# one
#two.</span>

1. one
2. two.

Indeed. Not the table. At least the table is simpler now ... Robert Ullmann 16:50, 6 April 2007 (UTC)

Many thanks to those who helped sort out the problem! --EncycloPetey 22:13, 6 April 2007 (UTC)

Note: RSS is still dysfunctional as a result of this "fix." --Connel MacKenzie 05:07, 7 April 2007 (UTC)

form of templates

Did anyone ever go through the form of templates and add "lang=" consistently to them all?

Using them en-masse tonight, I've noticed the "lang=" parameter usually means "language name" not "language code" as I thought it did. We should probably have better consistency somewhere in there.

--Connel MacKenzie 05:09, 7 April 2007 (UTC)

To destiguish them, how about using lang= for the full language name and l= for the language code, or vice versa? The first case would require checking and updating calls to {{context}} and any context template. The second case would require checking and updating calls to {{form of}} and any form-of template. In both cases all templates themselves are due for an overhaul very shortly anyway.

Besides the sister project templates, I don't know of any other major class of templates that use these. {{t}} is still being developed and everything else is pretty minor at the moment, e.g. there are very few neologisms, never mind foreign-language ones.

Benefits of lang=cryptic code are that the paramter is clear as a language, whereas l=full language name is already clear. Benefits of l=code are that it's short when the parameter is supposed to be short, and lang=language name is going to disappear some day anyway. Incidentally, I don't think lc= is any less cryptic.

On the other hand, there's no reason not to conflate the two if we're aiming toward lang=code in the long run, when {{#language:__|en}} is available for English. At that time it would be very easy, in less than one line of code, to allow either the code or the full language name whenever the full name is needed, with no weird template calls or anything. DAVilla 12:09, 7 April 2007 (UTC)

The {{nav}} template already uses lang= for the ISO code and langname= for the spelled out English name of the language. Why not just follow suit? --EncycloPetey 22:25, 8 April 2007 (UTC)

Any change is going to be difficult, but considering that {{nav}} is a major template, yours is one of the easiest. It would require updating all of the form-of templates, similar to the "vice versa" scenario above. Are you sure you're okay with {{t|langname=full language name}} in a table of translations?

On the other hand, if we decided to use either in {{nav}}, that is, {{{langname|{{{l}}}}}}, then this would allow the "vice versa" option above without having to change all the pages that use {{nav}}. We would still have to update all of the form-of templates, in this solution to l= in contrast to your solution.

Because of {{nav}}, I wouldn't consider l=code to be an easy solution to implement. DAVilla 05:32, 9 April 2007 (UTC)

Having thought about this a bit more, it seems we are currently very inconsistent already. {{nav}} is possibly the one place it is used consistently, but due to {{language}}, has blitzed Special:Wantedpages into oblivion. So I don't think we should hold up {{nav}} as an ideal to strive towards.

Was the above proposal to use l=language code and lang=language name? That does seem reasonable to my little brain. --Connel MacKenzie 15:35, 11 April 2007 (UTC)

DAVilla, no, that proposal is backwards. The general trend is towards "lang=" to mean language code. "ln=" seems like a reasonable "language name" template variable...but "l=" is ok, too, I suppose. --Connel MacKenzie 15:39, 11 April 2007 (UTC)

Okay, well it was both proposals at once really, but I'm really trending toward the one you say is in use. Although lang=code some day is all we will ever really need, I don't see any rush to standardize the others. They could easily be backwards-compatible for a while, documenting the new and deprecating the old.

The only cases that use both language name and code, so far as I know, are {{nav}} which is okay and {{t}} which was recently changed from ls= and now needs to be changed again. To what exactly? Usually "ln" means lane, line, but really anything will do since it should be pretty obvious from the value. How about something crazy like Ł? :-P Or maybe just uppercase, to make it more legible? DAVilla 00:58, 12 April 2007 (UTC)

I recommend against using ln. As a mathematician I interpret that as natural logarithm. It also is the ISO code for Lingala, which is a rather important language. Why aren't we just using "ISO=" for the ISO code, or is that solution too obvious? --EncycloPetey 01:20, 12 April 2007 (UTC)

Either l or ISO is fine with me (I wanted to add a more useful comment, but then it turned out I was looking at an old version :-p). Although lang=code and language=language are even more reasonable. But I tend to like short param names (saves typing). H. (talk) 11:50, 12 April 2007 (UTC)

Connel, you asked me to change ls= to lang=(name) in {t}, now that is backwards?

• {{nav}}: lang=(code), langname=(name)
• {{wikipedia}} and sisters: lang=(code)
• {{context}}: lang=(code)
• {{interwiktionary}}: code=(code)
• {{ethnologue}}: code=(code)
• "form of" templates: lang=(name)

lang=(code) seems fine, so what do we call language name in {t}? (not langname, just too long) that's why I was using ls (language section), as observed it should eventually go away. Maybe just l? it is really only the 'bot that will be messing with it most of the time; although some users will inevitably add it. I think ln is okay too in this particular case. Robert Ullmann 13:52, 12 April 2007 (UTC)

Since it affects other templtes, it's worth making sure we're consistent for our later sanity (even if sanity right now gets a little strained). Looking at the examples you've set forth, why note just go with lang=(name) and code=(code)? --EncycloPetey 17:15, 12 April 2007 (UTC)

Because code=xx is cryptic. With Greek or Mandarin as a value it doesn't really matter what we call it, but with el or cmn we'll have editors scratching their heads. lang=xx is both reasonably short and reasonably clear. I wouldn't mind ISO=xx either except it isn't in use anywhere, and would require changing absolutely everything. DAVilla 19:31, 12 April 2007 (UTC)

parameters in translation lists

This might have bearing on the {{t}} discussion above. Do we really want to replicate gender and number every place a word appears in a translation list, instead of putting them once in the entry proper? ArielGlenn 07:47, 8 April 2007 (UTC)

Not instead of, but also. ~ Dodde 07:50, 8 April 2007 (UTC)

Instead of putting them in *only* once, in the entry proper. My bad, that I left that one word out. ArielGlenn 21:49, 9 April 2007 (UTC)

I meant I disagree with your proposal. I like gender information both in the translations lists and in the translation's article entry. I feel gender information is very strongly connected to how to use the translation correctly in context. ~ Dodde 06:07, 12 April 2007 (UTC)

I don't mind them as parameters if we can be reasonably certain that the list is complete. However, judging from the most recent edit, this doesn't appear to be the case. I would recommend taking two, possibly three gender parameters as one part of any resolution. That would mean putting the number first—unless there is a user-friendly version, in which case that template would do all the checking and the server-friendly versions would do none whatsoever. There is also the option of leaving gender and number out entirely, but that has implications on uniformity, not just with present but with potential future style. DAVilla 15:44, 8 April 2007 (UTC)

I'm arguing that we ought not to include gender and number in the translation lists at all. What were you thinking about the impact on uniformity? ArielGlenn 21:49, 9 April 2007 (UTC)

Because I like to try to think of everything. Or if that was more of a pragmatic question, uniformity can be controlled more easily if there is a centralized, regulated syntax. For instance, rearranging the order of the interwiki link with all those pieces, possibly including traslitterations, is more feasible from a template than from a bot unleashing. But it can also be too restrictive, which is why in this case I'm more inclined to take your side. DAVilla 05:52, 10 April 2007 (UTC)

It seems you misinterpret ArielGlenns proposal. The question he rises is not whether to give gender in the {t} template or outside, he suggest that the gender information has no place in the translations lists at all. ~ Dodde 08:03, 10 April 2007 (UTC)

Indeed I did misinterpret. Well, if we decided not to use gender and number, it would be easier to turn them all off as parameters to {t}, but that's not a direct response to the question of whether they should be present. DAVilla 13:58, 10 April 2007 (UTC)

I indeed think that information should not really be there. It is an inheritance of paper dictionaries, that give the information for the word, so that you don’t have to look it up. But here, the translation is always a link to the word, which will contain the wanted information. It really is only one click away, instead of doing an alphabetical search in a 1000-page tome. But this discussion belongs on WT:BP. H. (talk) 12:01, 12 April 2007 (UTC)

Special:Wantedpages

Is there any way of sorting out Wantedpages - none of the entries listed there have any inward links to them. --Keene 09:34, 9 April 2007 (UTC)

This is my fault. I'm working on it now. DAVilla 10:21, 9 April 2007 (UTC)

Looks like the Special page was just refreshed (happens only twice weekly) and is still overwhelmed by the clutter. What is the solution you are pursuing? --Connel MacKenzie 04:16, 14 April 2007 (UTC)

I assume that question was directed at me - I'm not sure, I'm not really a tech-head, but I'm sure template:nav is the culprit! --Keene 18:52, 21 April 2007 (UTC)

Latest IRC problem

Someone has made bad changes to the IRC interface (available from the upper right corner of the screen). I can no longer access the IRC because my browser "can't find the server". --EncycloPetey 03:21, 10 April 2007 (UTC)

The server http://chat.wikizine.org/ seems to have gone away. Not sure if the domain name was hijacked, or what, right now. --Connel MacKenzie 15:43, 11 April 2007 (UTC)

It's back for now. --Connel MacKenzie 03:22, 14 April 2007 (UTC)

Proposed order for see also template

Moved to Wiktionary:Beer parlour#Proposed order for "see also" template. Cheers! bd2412 T 23:47, 10 April 2007 (UTC)

Firefox and edit conflicts

Firefox has a feature where if you navigate away from a page with a textbox, then come back with "back" button, what you entered in that box will still be there. This messes up the edit conflict code. Example: at 12:00 I start editing "cat" and make some changes but before saving them, I navigate to recent changes. At 12:00:05, person B edits cat, makes some changes, and saves them. At 12:00:10, I use "back" to return to cat, and Firefox fills the textbox with the text that was there before I navigated away, *BEFORE* person B did their thing. I save changes, and Wiktionary thinks I did all my editing AFTER person B, hence no edit conflict and I overwrite person B's work. Language Lover 02:38, 11 April 2007 (UTC)

One possible fix (this is pure speculation, I could be way off) would be to store the time editing started in an invisible textbox instead of however it's currently stored. Then with any luck, Firefox would do the same thing for that invisible textbox too. Not sure though. Language Lover 02:41, 11 April 2007 (UTC)

Actually, I could be wrong about this entirely, I realized the methodology I used to test it wasn't perfect. It could use more testing :) Maybe I'm wrong :) Language Lover 02:44, 11 April 2007 (UTC)

• Please check your caching preferences in Special:Preferences. There are lots of different browsers out there, with radically different behavior - the preferences page works around those general differences. A mechanism very similar to what you describe is already in the MW software. WorksForMe. --Connel MacKenzie 15:22, 11 April 2007 (UTC)

BUG: {{trans-top}} does not allow floats next to it

See parrot: there is no sensible way to place the image such that it does not push down the translations box. The box should be made flexible somehow. H. (talk) 11:15, 11 April 2007 (UTC)

Can't. The translations box is full width. Robert Ullmann 15:11, 11 April 2007 (UTC)

I use {{-}} before the translations sections, in cases like that. --Connel MacKenzie 15:19, 11 April 2007 (UTC)

Well, the obvious answer is to expand the entry! Load the page with quotations, synonyms, usage notes, related and derived terms, thereby padding the space between the definitions and the translations! (SEG) --EncycloPetey 15:52, 11 April 2007 (UTC)

Hate to be a copycat, but yes, that is a better approach.  :-)   --Connel MacKenzie 16:05, 11 April 2007 (UTC)

Take a look at the entry now. No more spacing woes. Petey wanna cracker! --EncycloPetey 16:18, 11 April 2007 (UTC)

Great. Now do the same for place mat. Or leave as is, without the quirky translations box. DAVilla 00:33, 12 April 2007 (UTC)

Wait... wow! You really did a lot! DAVilla 00:39, 12 April 2007 (UTC)

I decided that it would make a good model page, and so went to town on it. --EncycloPetey 01:02, 12 April 2007 (UTC)

Although you left out the most important bit. :-) Robert Ullmann 12:33, 12 April 2007 (UTC)

Sigh. I've put {{-}} onto place mat rather than starting in with setting, place setting, etc. --Connel MacKenzie 03:02, 14 April 2007 (UTC)

Agent noun

I've created a template:-er to easily add the etymology of agent noun ending by "-er". (example: to dance → dancer). Template:-or can be created on the same pattern. 16@r 12:37, 12 April 2007 (UTC)

depuration

Moved to the Tea Room. - [The]DaveRoss 23:11, 12 April 2007 (UTC)

Add {{trans-X}} to templates.

Could somebody please add {{trans-top/mid/bottom}} to the list of templates one can choose from if the drop down box below the edit box is ‘Templates’? Or explain me how to do it? Cheers! H. (talk) 14:04, 14 April 2007 (UTC)

I'll add it to MediaWiki:Edittools now...done. --Connel MacKenzie 04:35, 29 April 2007 (UTC)

Wikisophia: music notation?

Is this turned off here? I wanted to add an example to C for the note. H. (talk) 11:23, 20 April 2007 (UTC)

Could you please describe what you mean, a little better? Perhaps a link? --Connel MacKenzie 04:36, 29 April 2007 (UTC)

template:nav

I recently made an edit, getting rid of template:nav. I'm not a fan of template:nav, and am probably not the only person who isn't. It's probably that template that has buggered up Special:Wantedpages too. Can we just get rid of it? --Keene 18:49, 21 April 2007 (UTC)

Or, perhaps, I just won't use it. --Keene 18:50, 21 April 2007 (UTC)

I find the template useful, but then again I only use it for topical categories. I would never include that template on a grammatical category. --EncycloPetey 22:39, 21 April 2007 (UTC)

It is undeniably the template that (in conjunction with a WM software change) has destroyed the effectiveness of Special:Wantedpages. I too, am inclined to throw the baby out with the bathwater, at this point, regarding this template. I assume that would be unpopular. I am still unclear why it is malfunctioning. --Connel MacKenzie 04:41, 29 April 2007 (UTC)

OK, I've narrowed one of the main problems affecting Special:Wantedpages down to Template:context/checklabel, but as esoteric templates go, this one is quite esoteric. DAVilla, can you explain your "Xx" stuff to me? In 20,000 words or less? Please? Also, for repetitive testing, do we have that template copied anywhere, used by only a single test entry so that we don't have to clog and wait for the job queue? --Connel MacKenzie 19:40, 14 May 2007 (UTC)

I think Robert Ullmann said it best: "The kludge to use the lang param to prevent recursion is dreadfully poor engineering practice, and must be removed." I have fixed this with the experimental {{context2}}, but I haven't looked into it or any other templates recently, including {{language}} which is dangling half-modified at this point. And by the way, I'm looking at starting a two-month vacation this week. That's not the best time to implement any far-reaching changes, though I could probably fix {{language}} in the rare cases where it's needed.

By the way, you don't always have to wait for the job queue to clear to see the effect of a change in templates. You can sometimes preview a page that uses the template, and the software forces the use of the most recent code. Unfortunately I think this only applies to direct template calls, not nested template calls, but it avoids the mistake of thinking that you haven't made any effective change whatsoever, only because the template includes a dirty version of itself or some such nonsense. Probably doesn't apply to {{nav}}, but worth testing. DAVilla 21:33, 14 May 2007 (UTC)

(see also WT:BP#Template:nav) Cynewulf 20:18, 14 May 2007 (UTC) <edit conflict> Man, you are consistenly one step ahead of me today. That's the link... --Connel MacKenzie 20:58, 14 May 2007 (UTC)