Wiktionary:Grease pit/All topics

This page is no longer active. It is being kept for historical interest.

No discussion is needed to revive this page; simply remove the {{inactive}} tag and bring it up to date.

Customization templates to provide both UK and US spellings edit

Here's an idea I've had for a while, and I think it may have come up on Wikipedia once upon a time.

We could have a template which takes both the UK and US spellings of a word and gives each a CSS class. In the gobal (not just monobook) CSS file we would make probably the US spelling the default just for numbers. In the how to customize page we show how to make UK the default. We hope and pray for a way to have a real prefs setting for this so that regular people don't have to get dirty and touch their CSS file themselves.

The template would never be ok to use in sections like headword, alternative spellings, etc - it only belongs in places such as the definition and usage notes where the spelling of a word not under the scope of the article is not important.

Adding a 3rd variant will not be easy since then a decision must be made about which to use when the preferred one is absent. Any ideas?

Doing the same for other languages, ie Portuguese for Brazil and Portual would be easy.

Both templates and CSS class names must clearly indicate their function - 3-letter names for either is almost always a bad idea.

I'm going to implement a first version to encourage discussion... — Hippietrail 20:37, 27 May 2006 (UTC)[reply]

I think \Mike knew of a way to honor the &lang= url parameter. en-us vs. en-uk could conceivably just come from user preferences. Having a bureaucrat add those two options to en.wiktionary's LocalSettings.php file would then tell the MediaWiki software to look for (to use Main Page as an example) either Main Page/en-us or Main Page/en-uk and default to Main Page if the preferred page did not exist. That was my understanding of how that setup ("the MediaWiki way") would work, anyhow. Could someone confirm or deny this theory for me please? --Connel MacKenzie T C 21:21, 27 May 2006 (UTC)[reply]

Another thoughts is whether the same templates should be used for regional synonyms as well as regional spelling such as UK shop and US store. Or an similar template could be made with -syn- in place of -var- — Hippietrail 22:48, 27 May 2006 (UTC)[reply]

1st draft edit

{{spelling-var-en-uk-us}} The template name indicates it's for spelling variants, that it's for the English language, and that it allows a 2-way choice between UK spelling first, and US spelling second.

There are 3 CSS classes. A wrapper class spelling-var-en-uk-us takes the same name as the template and allows the contained classes to be manipulated only in certain contexts if that's what the user wants. The two options have class names var-en-uk and var-en-us. Their names indicate that they belong to the surrounding class, that they deal with English, and that deal with a specific national variety.

To use: I want the {{spelling-var-en-uk-us|colour|color}} in the {{spelling-var-en-uk-us|centre|center}}.

results in:

I want the Template:spelling-var-en-uk-us in the Template:spelling-var-en-uk-us.

US spelling is the default. To choose UK spelling, put this in your CSS file:

.spelling-var-en-uk-us .var-en-uk { display: inline !important }
.spelling-var-en-uk-us .var-en-us { display: none !important }

— Hippietrail 20:53, 27 May 2006 (UTC)[reply]

I've made the one I just mentioned for regional synonyms such as spanner/wrench, shop/store, tap/faucet etc now too:

To use: I bought a {{regional-syn-en-uk-us|spanner|wrench}} from a {{regional-syn-en-uk-us|shop|store}} so I could work on my {{regional-syn-en-uk-us|lorry|truck}}.

results in:

I bought a Template:regional-syn-en-uk-us from a Template:regional-syn-en-uk-us so I could work on my Template:regional-syn-en-uk-us.

The US word is the default. To choose the UK word, put this in your CSS file:

.regional-syn-en-uk-us .syn-en-uk { display: inline !important }
.regional-syn-en-uk-us .syn-en-us { display: none !important }

NOT ACCEPTABLE !!! edit

So now you seriously expect us to live with US spellings for everything ! Unless we happen to be a tech head who understands (or even has the time and inclination for) CSS ! I don't think so. This is a TOTALLY UNACCEPTABLE approach. . Expect to be ambushed constantly if this is implemented in this way. It is just not acceptable! (Is my position clear enough ?)--Richardb 11:43, 29 May 2006 (UTC)[reply]

Hey I don't like US spelling either but I'd get the same reaction if I made UK spellings the default. Teh "tech head" problem is solvable if we can get the devs to give us a setting on the preferences page. Or is a user setting via the standard GUI still too technical? I would like to hear your proposal for a non-technical solution that satisfies both groups. Your emotion is clear enough, your understanding is not clear enough. — Hippietrail 20:35, 29 May 2006 (UTC)[reply]

I am from the UK. If someone here writes color or faucet, I want to see it! I don't want it ‘translated’ into British for me. We have to acknowledge and deal with all spellings, not find a way to remove one or the other depending on where we're from. Widsith 13:24, 29 May 2006 (UTC)[reply]

I saw this as a way to "acknowledge and deal with all spellings". It might be possible to expand on the idea with "always show me the first option". I know how to do this quite easily. Also with a "show both options" option that would display "color / colour" and "faucet / tap". I am curious to know why you prefer to see an arbitrary spelling or word even on unrelated articles though. Also this would not be automatic at all - it requires a page to be edited - there is no proposal to make them global. — Hippietrail 20:35, 29 May 2006 (UTC)[reply]

I tend to agree with Widsith here. I don't think it's a problem to anyone whether color or colour is used in a definition line or explanatory note (or, for instance in {{colour}}. The compromise there is that it is Template:colour but Category:Colors. I'm sure such compromises will be sufficient for reasonable folks. Aren't the shared contents (whichever they are, I tend to agree with Connel that it is only the translations) of color & colour and friends the real problem? —Vildricianus 14:05, 29 May 2006 (U T C)

Perhaps you haven't seen some of the emotional yelling in various fora of Wiktionary? There are some very vocal people who are not happy at all. — Hippietrail 20:35, 29 May 2006 (UTC)[reply]

HALLELUJAH! The Brits finally see that it is a POV issue! Took what, three years? I'm going to go do a little happy dance now. Yes, both en-GenAm and en-Brit (and en-Can, en-Australia, en-India, etc.) all need to be broken out and distinguished! The interplay of which are considered valid where, need to be spelled out somehow on individual entries! Even though it is only two Brits so far, I am very encouraged to finally see progress! --Connel MacKenzie T C 18:07, 29 May 2006 (UTC)[reply]

Do you call me a Brit? Even though I drink a lot of tea, that doesn't make me a Brit! :-) I use British spelling yes, but surely you know that I'm the main proponent of de-POVing US vs. UK issues! —Vildricianus 18:40, 29 May 2006 (U T C)

I was under the assumption that "Brit" is the friendly way to say "one of British origin or nationality", and no, I was referring to Richardb and Widsith admitting that they see the light. --Connel MacKenzie T C 20:53, 29 May 2006 (UTC)[reply]

Mmm, I thought Rich was an Aussie. Must have skipped the UK bit. —Vildricianus 20:58, 29 May 2006 (U T C)

Or more simply, my mistake, regarding Richard's origin. --Connel MacKenzie T C 22:10, 29 May 2006 (UTC)[reply]

Please Connel, this isn't about Brits vs Yanks. In response to Hippietrail – yes, there has been yelling, but I think it's better to create the site with reasonable folk in mind rather than creating policies to appease the shouters. The reason I favour ‘arbitrary’ spellings is that I like to see what people have actually written. There may be little difference between color and colour, but tap and faucet could have different connotational shades of meaning, as may spanner/wrench. They certainly do to my ears. They are only tiny differences but they are important – different words have different sounds, impacts etc....I know I'm talking about tiny differences but they're an important part of language and if any site should be concerned about them it's this one. The nice thing about the internationalism of the Internet is that we all gain exposure to, and familiarity with, different kinds of English, and the proposed policy would neuter that diversity. Widsith 20:54, 29 May 2006 (UTC)[reply]

A few responses:

"I think it's better to create the site with reasonable folk in mind rather than creating policies to appease the shouters"

I think we can please both the reasonable people and the shouters. I for one want the shouters appeased because they sometimes get me angry and I do not like losing sleep over Wiktionary.

"I like to see what people have actually written". This seems to be a non-dictionary taste. You might be interested in the writers but the majority of people are interested in the definitions. It would seem quite a shame to rob the larger group of an improvement due to the tastes of a much smaller groups.

"tap and faucet have different connotational shades of meaning". When you find somebody blurs these shades in an article then you edit it and leave only the specific word. The proposed solution is not intended for such cases and that would need to be stressed in the documentation. — Hippietrail 22:28, 29 May 2006 (UTC)[reply]

I'm glad to hear that the US vs. UK template proposal is not about "Brits vs Yanks." Um, what? If the British contingent hadn't been so overwhelmingly intent on thwacking GenAm entries, there would be no color/colour debate; they would simply co-exist, as they should. --Connel MacKenzie T C 22:10, 29 May 2006 (UTC)[reply]

Please Connel (and others), I hope it's only by accident that this sounds like the kind of language sometimes labelled here as "attacking" or "fighting" or whatever. It certainly doesn't seem to helping the discussion along. Can we stick to technical stuff. — Hippietrail 22:28, 29 May 2006 (UTC)[reply]

Did it sound like I was fanning the flames? If so, then I am sorry. That was not my intent. --Connel MacKenzie T C 01:26, 30 May 2006 (UTC)[reply]

(Side comment from the peanut gallery: it would have been better, then, if you had left out the words "If the British contingent hadn't been so overwhelmingly intent on thwacking GenAm entries". –Scs 03:07, 31 May 2006 (UTC))[reply]

There is no ‘British contingent’, there are only individual contributors. Widsith 07:26, 30 May 2006 (UTC)[reply]

Apparently, you missed the last several flame wars. The fact that the very real "British contingent" exists is masked by their relative silence recently. I assure you, I have good reason to assume the relative quiet is temporary. --Connel MacKenzie T C 07:03, 31 May 2006 (UTC)[reply]

This individual has personal tastes on the matter similar to Widsith -- If I want important information from a book, and I can understand the language of the original, I prefer to read that rather than a translation. Indeed, perhaps stupidly, I've consulted the Hebrew version of the Bible on occasion, even though I only know Hebrew from a dictionary.

I've no objection in principle to WT providing translations to the en used in US, Can, Jam, UK, SAfrica, many other Af countries, India, Aus, and any of the other places I've left out, provided an untranslated version remains available for those who care about accuracy more than politics. I know the difference between Jamaican en or Indian en and Brit en is in many ways much larger than US - UK. It's merely that there are numerically more argumentative/bigotted users in US & UK (and I suspect a higher proportion too). Why not more users from the one billion plus in India many (over 100M and growing fast) of whom speak en -- because we don't serve their needs? Frankly, I would have more patience if it was the Js & Is who were complaining, but so long as what we do is generalisable to them, I think it will be a good thing. (If it was purely UK/US, I would say only do it if the time taken is less than the aggro saved, but we ought to address India, etc before too long, so UK/US could be a good test bed.)

I would suggest that we start with spelling differences rather than tap/faucets, that/which, wrench/spanners, machine/plant rooms, &c/etc ;-) as I think it will give more bangs per buck (well there's some things, as also the apocryphal headline Nut bolts, screws washer that just can't be said as well in UK en!). I suppose I mean that I foresee loads of edit wars as I revert items which people have changed inappropriately (possibly in bulk by bots). None come immediately to mind, but to take examples from gender issues, there are such beauties as personholes, Personchester, singing hyrs and karels, Awomen.

At least we already give pronunciations, so we don't have to worry about visitors to US heading for Ark-cans-as or San Joe's, or to Europe heading for K-nares-bor-oogh (in Yorkshire) or the Champ's Ailie-says (in differently-oriented Paris) [honestly, those were from a friend's father and another friend's mother, so they must be true]. I do worry about equally ignorant people translating between US & UK, but hey, it's a wiki, and it's survived well so far.

--Enginear 01:48, 31 May 2006 (UTC)[reply]

Regarding your last paragraph, Wow! I was shocked by the three-syllable Wiktionary, but those examples are incredible. If the majority of British English speakers really mangle pronunciations that badly (worse than the mostly-fictional/ joking/ stereotypical Texas accent) then perhaps it is a good thing we have seen so few en-uk-*.ogg files! :-) Joking aside, it would be good to have more uk audio files. --Connel MacKenzie T C 07:03, 31 May 2006 (UTC)[reply]

I think the pronunciations of Knaresborough and Champs Élysées are urban myths, and though they were attributed to Americans (by a Yorkshireman and a Parisienne) it could just as well be Brits. Indeed, I have heard the CÉ from an English teenager who knew no French. The Arkansas, San Jose, and indeed the Sea Ooks native Americans and co-lor/col-lor, I made up about 3 years ago for use the next time an American told me that their spelling was better because it was phonetic. :-) But no one ever has. Having said that, I can imagine quite a lot of Brits using them -- after all, the change from Kansas to Arkansas is almost as unfair as the Scottish trick used against primary school children: "Pronounce MacKenzie, Macauley, mackintosh,... macadam, machine". It doesn't help that there are many Londoners, including professionals, who cannot understand broad Scotish Highlands/Islands, Glasgow, Black Country or Geordie accents -- I don't know whether there is such a range of US accents. Maybe, one day, we'll give regional accents too in pronunciation, but as a Londoner who can (usually) understand them, it's not my bag!

I will learn one day how to do .ogg files but it's not a priority for me. --Enginear 23:09, 6 June 2006 (UTC)[reply]

[Talk re display of IPA characters broken out to a new thread below (Wiktionary:Grease pit#Problems displaying IPA in edit & special chars boxes) for convienience.]

I have mislaid a long ?80 line bit of doggerel containing a few hundred non-homophonic homonyms, said to have been issued by a British embassy for advanced TEFL, but did find the attached, which may amuse you [[1]]. --Enginear 12:14, 31 May 2006 (UTC)[reply]

For anyone that still reads this, I did find the aforementioned doggerel English is tough stuff at some point, but checking just now, the site is unavailable. But now knowing the name and Googling it, I see the rhyme is now at MIT, amongst other places [2] and on YouTube, someone has made a reasonable attempt at reading it. --Enginear 13:38, 14 April 2023 (UTC)[reply]

2-level dictionary edit

History edit

It seems that all along there have been 2 camps of people working on Wiktionary. a) Those who wanted to build a free open online dictionary of all words in all languages that works just like a traditional dictionary such as those produced by Oxford, Websters, or The RAE; and b) Those who wanted to build a free open online dictionary of all words in all languages that is not constrained by tradition in any way shape or form and wants to broaden the scope to include inflections, misspellings, word combinations that might be too transparent for traditional dictionaries, video game characters, etc.

I've been thinking of such a dictionary for years before somebody came along and created Wiktionary. All along I thought the world needed a free OED or Webster's that they could add to and improve. While I expected that contributors to such a free project would be amateurs untrained in lexicography or linguistics, I also thought they would fall mostly into camp a) with another groups who wanted to promote their own invented words (protologisms) who we would need to dissuade. Somehow though I never invisaged camp b).

It's only in the last couple of days after fighting with various degrees of energy since the time I discovered Wiktionary that the majority of contributors, at least up till now are actually in camp b). How foolish I was!

So now I will no longer fight against entries that I wouldn't accept in a traditional dictionary, indeed I will mostly stay out of debated on RFD. But what I will do is mention the benefits of becoming a 2-level dictionary that works for both camps since I feel there is a very large camp a) out there who have never looked at Wiktionary but will in the course of time.

I think I've been pretty vocal about my opinions for inclusion... I hope not too much so, though the CFI talk page could almost be construed as yelling. I'm interested in knowing which camp you think I fall under, or which one I'm closer to anyways. Davilla 14:15, 3 June 2006 (UTC) (re-signed)[reply]

What the Grease pit can do edit

So the job for me and anybody who understands the point I'm trying to make, is to come up with the technical ways of bringing about a 2-level dictionary so that tradition users can either see just what would be in a traditional dictionary or at least be able to tell visually which entries and which senses would be in a traditional dictionary and which are part of the extended scope of Wiktionary.

Here are some of my ideas:

Come up with a set of templates, or something else, which can be inserted into an article at the language entry level, to mark the whole entry as an extended entry.
As above but to mark individual senses.
As above to mark entries or senses by type: encyclopedic, misspelling, transparent combination, fictional character, etc.
The default behaviour of these should be to do nothing at all. The typical user will see just what they always saw. But there will be a CSS class which can be accessed by some new skin or by people who choose to customize. They can be used to show types of entries by colour, or to hid types of entries (or senses)
More difficult problems include how to handle links to these in Related terms or the disambiguation see also section at the top of pages, or how to improve search results to indicate which results would be for extended entries. These could be solved with more advanced methods such as toolserver with its own database of which articles are marked in which way - in some ways similar to Connel's Random article by language work.

Rough poll edit

It might help to get an idea of how people feel about these issues:

a) I think it's all stupid and want nothing to do with it
b) I've always been in camp b and didn't know there was a camp a
c) I've always been in camp a and never understood camp b
d) I'm in camp a personally but always understood that most Wiktionarians were in camp b
e) I'm firmly in one camp but can see that Wiktionary would be much better if it worked for both camps
f) I'm firmly in camp b and don't want Wiktionary to change but I'm still interested in what you guys think
g) all kinds of other positions that haven't come to mind right now

Ok. So let's hear peoples' thoughts... — Hippietrail 22:40, 27 May 2006 (UTC)[reply]

Vild's thoughts edit

I'm for option h): I oppose polarization and antagonism, and would like to single out any attempt at moving towards such status. Besides, none of your poll's points apply to me. I'm not certain everyone here - apart from the most idealist among you - feels they are 100% in one camp. At least, I'm not in any, and I'll always refuse to think in such terms.

I do understand your position, Hippietrail, and of course you have way more experience here, but one thing I'd gladly avoid is creating "camps" of ideologically different contributors. Such differences, of course they exist, but do we really need to encourage and endorse them? Why can't we have a unified purpose, with one set of criteria and one set of guidelines? Sure both parties will have to give in some of their ideas, and both will have to conform. That's no big deal, is it? It has worked for a couple of years now without too many problems, and even though it's becoming obvious that we'll need some adjustments to our systems somewhere in the near future, there's no reason to overhaul the most basic and fundamental reasoning behind Wiktionary.

I don't think your proposals will solve anything. I could be wrong, but I expect them to divide the community to a great extent. Fine, there may be two camps. Let's make one dictionary for both. Don't get me wrong, if it seems that such a solution is beneficial, then by all means good luck with it. But I'm highly sceptical. —Vildricianus 23:45, 27 May 2006 (U T C)

I was under the impression that Hippietrail's proposal is to quell the opposition between the two camps. There may not be a clear dividing line between the two camps, but at the very least we can say that some contributors are more inclusive than others. By allowing purists to mark terms "not fit for inclusion" as such, they can have their voice and can filter the resulting Wiktionary without being bothered by seeing anything "brillig" to "undigital". Others, likewise, can enter terms that they feel are vital to define here without getting their good faith efforts trampled over. I don't see how the proposal is divisive. Rod (A. Smith) 00:06, 28 May 2006 (UTC)[reply]

I agree with Vild. In essence, this is a political problem much not a technical one...technical remedies sometimes help, but not without TREMENDOUS amounts of PR and cheerleading. --Connel MacKenzie T C 14:31, 28 May 2006 (UTC)[reply]

Yes please edit

I am very strongly in support of this proposal. I want wiktionary to provide me with both kinds of dictionary. For example "owl" means "message" in the Harry Potter books. This is way too much information if I wasn't looking for it, and when I saw it I thought "Yuck, get this fancruft out of my face". However, if I was trying to read a HP book in a foreign language, this kind of thing would be incredibly useful to me. One reason I almost always vote with camp b is precisely because it is possible to create two-level dictionary which caters to almost any kind of need, so no-one has to be let down. Another point it that it should be very easy to get concensus on most terms and thus not require any actual voting, which is divisive and seems to have semi-random results. Kappa 01:20, 28 May 2006 (UTC)[reply]

Two-level too arbitrary, I think edit

My goal (though I tend to be somewhat blue-sky on this sort of thing) would be to try to describe an entire continuum of word/term notability, from absolutely-accepted to jargon to fancruft, with all sorts of gradiations in between.

And, in fact, there's not a single axis here; but several:

technicality: from "every English speaker knows" to "particular to a field" to "very specific jargon or techspeak known only within a field"

formality: of usage: stilted, formal, normal, informal, slang, vulgar slang, unacceptable

regionality: how widely is the term known or used: worldwide, national, regional

notability: what group considers this term important: everyone, those in some field or large community, those in some small or very specialized community

minutae: whether every derived and inflected term exhaustively, explicitly listed (or only the "interesting" ones)

Obviously, we capure many of these characteristics already, in somewhat ad-hoc ways, generally with tags such as {{mathematics}} or {{slang}} or {{US}} (which of course is just what real dictionaries tend to do, too). Me, I'd rather be more systematic about this sort of thing, but the ad-hoc tags do work pretty well. My holy grail (which may be exactly what Hippietrail was getting at) would be, not a two-tier system, but one in which rather than deleting terms which failed to meet some arbitrary, binary threshold of "notability", we could instead tag and then filter things so that the horrendously obscure or "non-notable" terms are effectively invisible to those who don't care about them.

–Scs 13:50, 28 May 2006 (UTC)[reply]

Minor gripe: We don't speak of notability here, except to point out to Wikipedians that this is not Wikipedia...attestation is our rule here, not notability. (More relevant comments later, when I've digested this more properly - looks good, though.) --Connel MacKenzie T C 14:23, 28 May 2006 (UTC)[reply]

The CFI is an arbitrary limitation, arbitrarily set by an arbitrary group of people. It is far from immutable. It is precisely to overcome these arbitrary limitations that we are discussing these ideas.--Richardb 10:47, 29 May 2006 (UTC)[reply]

A few terms that I've added to Wiktionary are non-standard interpretations of English words, labeled as such. So when I first read this, tagging was an immediately obvious way that we already make some of these distinctions. Thank you for spelling out the idea more fully. -Davilla 59.112.52.124 17:20, 28 May 2006 (UTC)[reply]

Here's another big distinction I forgot:

reality: real-world terms versus terms from fiction (e.g., the recent debate over veritaserum)

Yet another one is

status: archaic / obsolete / current / neologism / protologism

–Scs 14:02, 29 May 2006 (UTC)[reply]

See also Wiktionary:Beer_parlour#Classification_of_slang. —scs 00:29, 10 September 2006 (UTC) (That's as of 9/2006; eventually it'll be archived and that link will stop working.)[reply]

How is progress on the next version of Wiktionary software going? edit

Some of these ideas would be so much easier to implement if we have a proper database version of Wiktionary. It might be worrth waiting for that next version if it's really in prospect.--Richardb 10:47, 29 May 2006 (UTC)[reply]

See reply below. —Vildricianus 14:18, 29 May 2006 (U T C)

Connelthoughts edit

I like all that I've read here, so far. I confess that when I found Wiktionary, I assumed it was a "camp A" type dictionary. After a short time, I learned it was a "camp B" dictionary, and got with the program. (I didn't think of it in those terms, then, of course.)

I do strongly agree with Eclecticology's disproval of the vulgar nonsense that often creeps in. The more ridiculous stuff we allow, the less likely it is that Wiktionary will ever be considered a "respectable" resource. To me, the problem has always been one of distinguishing between "valid camp B stuff" and vandalism/peruile nonsense.

OTOH, we already have branched out far away from traditional dictionaries. To a newcomer, there may be little distinction. That is why I find myself falling into "camp A" on occasion, even though I know that "camp B" is the goal that Wiktionary is heading towards.

Reading Scs's thoughts, I really like the multi-level approach. But that is clearly me thinking as a bit-head, and not as a dictionary user.

I guess the biggest problem I have, is that "All Words In All Languages" is inherently incompatible with "camp A". Due to the unrecognized camp A/camp B conflict that has gone one for the past couple years, we don't do "camp B" properly either.

I think that no matter where this conversation goes, Wiktionary should address the "All Words In All Languages" paradox. That is, if we were to ever get to that point, we would be so far from what people expect when finding a dictionary, the effect might be the same as if we included all Urbandictionary vulgarities. (And recently, even Urbandictionary seems to have expunged much of last year's nonsense.)

I don't know what the "right" answer is. Throwing up my hands and saying "time will tell" may be true, but not very helpful. I'd like to see how Scs' ideas pan out, as I think they hold the most promise.

I recognize the danger that Vild pointed out regarding the use of "camp foo" vs. "camp bar" labels, but I hope it is clear that no one falls 100% into one abstract concept nor the other. It may be worthwhile to drop the labels.

--Connel MacKenzie T C 15:48, 28 May 2006 (UTC)[reply]

Richardb view edit

I must admit that as a non-linguist I am somewhat despairing of Wiktionary progressing anywhere positive for the "general public" user. It has a huge volume of words, but does not cover the basic words well (Many of the most basic words are barely improved from the Webster importation), becuase everyone follows their special interest, which is not often around the most basic words. Nor does it handle the capture of new words/meanings well (variously deleting them, consigning them to a list of Protologisms etc). But it does have a huge number of totally obscure words in obscure languages (Old English). WikiSaurus is not exactly a roaring success yet, though it would seem some form of Word-Relationships capture is needed. --Richardb 11:18, 29 May 2006 (UTC)[reply]

I guess one reason for the "neglect" of the basic stuff is because it's more difficult to describe accurately? I don't think it's a big problem, though, it'll get fixed over time. Remember there's only a handful of contributors here. —Vildricianus 13:51, 29 May 2006 (U T C)

So, somehow, we need to capture everything we can (be totally inclusionist), but categorise what we capture (technicality, regional etc), so that users can tailor their view to limit the content to what they want to see normally. I don't think we can do that realistically with the current software. How close is the next version, with full database capabilities, where we can apply all these different types of dimensions to words, spellings, meanings, relationships etc ? --Richardb 11:18, 29 May 2006 (UTC)[reply]

What is that, "inclusionist"? Allowing things like big red bus? Or all the dubious content and spam we get daily? I believe that we can work this out, provided we put a lot of effort in it, and that a unified CFI is possible. —Vildricianus 13:51, 29 May 2006 (U T C)

In the absence of new, purpose built software, I think we will be defeated. If the new software is not really going to happen, perhaps we need to form some sort of relationship with another online dictionary which can better support our efforts. My view is that the software used by www.thefreedictionary.com would be a better starting point for us. Perhaps we could form a relationship with them (as Wikipedia seems to have done), so that we get free use of their software, and they get free use of our content. Are there other candidates we should consider ? --Richardb 11:18, 29 May 2006 (UTC)[reply]

The new software (you might want to take a look at (http://wiktionaryz.org) is under development, yes, but I don't think it'll soon replace en.wiktionary completely. It might take over our non-English content, yes, but I don't recommend counting on it for a big solution for our internal problems. Not yet, that is. I'm not sure whether we should count on yet another new software proposal, though. —Vildricianus 13:51, 29 May 2006 (U T C)

I also feel we are going to end up needing some sort of voting software (which I think Urban Dictionary has) to vote on the applicability of the various tags we put onto words. eg: Is "gay = happy" a current usage or not. But even this would be complicated - A vote of 10-20 year olds would probably be 99% saying it's dated. A vote of over 65's would be probably be 75% or more still saying it's current. --Richardb 11:18, 29 May 2006 (UTC)[reply]

Then just make sure everyone's complete information is entered, including age, and the system will churn out the perfect tag, in this case somewhere between "dying out" and "outdated". Like "fogly" or something. :-P Davilla 13:11, 29 May 2006 (UTC)[reply]

Voting? No thanks! Honestly, I can't imagine anything worse than that. You want to let people decide how language is used? That's not very far from prescriptivism, right? Unless I'm mistaking, that's not what Wiktionary is about. It would be too easy for one group to dominate the other. Whether gay means happy is not up for decision or voting; it has to be examined "in the field" and proven. —Vildricianus 13:51, 29 May 2006 (U T C)

Sorry if I missed your joke, but to me, allowing "voting" sounds very much like descriptivism, not prescriptivism!

Seriously, one kind of "voting" I've thought about would be not for definition accuracy, but rather, simply for notability/usefulness/reality/existence of an entry. It would be an implicit kind of voting, based just on... hit counts. Pages that never get viewed in N months might not be words and so might be candidates for automatic deletion or relegation to some less-visible category of "really obscure" words.

(With that said, I certainly concede that there would be significant difficulties. It would be easy for suupporters of favorite nonce words to keep their word supported through false clicks. There might be genuine words which are so obscure that they never happened to get a visit in N months. But it's interesting to think about all the same.)

–scs 21:43, 31 May 2006 (UTC)[reply]

Pardon me if this sounds as POV pushing from my part, but I don't have the slightest idea of how this would work. Neither by means of voting nor by counting page views. The proposed system would be highly susceptible of real POV pushing and, contrary to how you view it, would be prescriptivism incarnate. I wasn't joking this time - I try to limit that to my signature. Heck, voting is such a controversial issue for policies and proposals, so let's please not consider this as a means to attest a word's usage. Contrary to what often is displayed at WT:RFV, we do have our methods and means of doing so properly, it's just that we still need to shape it and fix it according to what suits best for Wiktionary. I guess we will forever be refining it, and it'll never be completely error-free, but at least it'll be a working system. —Vildricianus 21:58, 31 May 2006 (U T C)

But, in the end, maybe Wiktionary will never really work perfectly. Wikipedia works because on each topic the "experts" eventually take over and win the debates. But in Wiktionary we are all "experts" on current usage of words, and are not going to easily agree on common definitions, synonyms, even pronunciations. We can't even agree on spelling half the time! Maybe a dictionary still does need an editor/publiosher, to be the final arbiter, if it is going to have consistency. --Richardb 11:18, 29 May 2006 (UTC)[reply]

What's perfect? Do we need it to work perfectly? Do you think Wikipedia works perfectly? Far from! I dare say we're on tracks - we still need to work out a huge number of bugs and hitches but the concept is working, albeit slowly. —Vildricianus 13:51, 29 May 2006 (U T C)

I view WZ as a branch, not a continuation. The goal seems to be quite different. The emphasis is in translations, not so strong on description in a given language. Wiktionary has instead the ability to describe terms in the reader's language of choice, with language-specific subtleties emphasized. I hope I am ultimately wrong about WiktionaryZ, but it will take a lot more software development to get there. The notion that a word can be described in localized terms only makes the ultimate goal of WZ laudable. But for 10,000+ languages, it may be a little too "pie-in-the-sky."

Yes. And very long-term. Did you know, the biggest dictionary in the world is the "Dictionary of the Dutch language" (way bigger than OED), and it took 147 years to complete. For one language. —Vildricianus 20:28, 29 May 2006 (U T C)

Partnerships with entities are great, but I think the notion of using software from http://www.thefreedictionary.com/ is silly. They have amalgamation software, not data-entry/data-conversion software.

My long term goal for Wiktionary has been to consolodate the level three headings. If we can come up with a finite set of "valid" third level headings, the ability to convert our plain-text representation to a data model are greatly improved. (Level two headings are currently language headins, barring the occasional newbie mistake.) If we ever *do* come up with a finite set, we can then use Javascript to enforce "better" data entry (to combat the "garbage-in; garbage-out" syndrome.) So far, the thorniest issues I've seen are with things like "Gismu" (in the Lojban language,) "Romaji" (Japanese) and "Letter"/"Character"/"Symbol" (Interlingual.)

Add to the confusion the assinine practice of using different levels depending on the number etymology descriptions, and it gets much messier. (My philosophical POV regarding etymology sections is that they should have the same style "disambiguation" as translation sections. They should also be relegated to secondary headings, in my opinion. Currently, Wiktionary gives them superior status, even when "unknown.")

Will language Wiktioanry content ever be used in WZ? I don't know. I do hope so, but then, I see the current formatting problems as being insurmountable for automated import issues there.

Similarly, I don't think the emphasis on POS is beneficial at all. In my philosophical POV, a ===Definitions=== section is all that is needed, with individual meanings described by tags like {{pos_n}}, {{pos_a}}, {{pos_v}}, {{pos_vt}}, {{pos_vti}}, etc.

Taking that one step farther, it would be nice to have software do the "dismabiguation" of all the various other third level headings. Maybe a mechanism similar to the "references" keyword used in Wikipedia. The ultimate goal would be to have just the definitions appear, with links to all other information being in collapsed/hidden "collapsible" sections, linked to each definition (not to a spelling.) E.g. "(etymology +)", that when clicked would display that meaning's etymology. Or "(translations +)" which when clicked would expand the translation for that meaning.

Again, I don't that is the direct that WZ is headed in. Again, I hope I am wrong, thinking so.

I think our best bet for developing the next generation of Wiktionary software is something that will be done, right here; not on WZ, not using freedictionary, nor anything else.

I think Richardb's goal of focusing on "Basic" words and drastically improving them is laudable, but is not something that I am particularly good at, myself. On one hand, all entries need improvement. On the other, the most commonly viewed entries should be "improved" first. It is very reasonable to assign priority to which entries to target, for that improvement.

--Connel MacKenzie T C 20:09, 29 May 2006 (UTC)[reply]

Widsith thoughts edit

The only way for a dictionary to be respected and respectable is to cite usage. That is the levelling criterion which does away with debate over what is and isn't proper or vulgar or whatever. If a word can be seen to be used we should include it and define it – and otherwise we shouldn't. Hippietrail, you want to retire from RFD discussions, but I wish you wouldn't. I think by and large the community works well here. Debate is important and if decisions have not gone the way you would have liked, I don't think it's a good response to walk away and suggest splitting the dictionary in two. Although we argue over details, most people accept the CFI and we should use that as common ground for moving forward, not start talking about dividing content. Personally, I have my own ideas about what things should not be part of a dictionary (video game characters among them), and I will continue to argue that way in RFV discussions, and I invite those of you who disagree to argue back. I have conceded many points in the past and had my opinion changed on several matters, and I hope I've changed other people's minds about things too. We have to work towards consensus, and not abandon it in favour of division. Widsith 13:48, 29 May 2006 (UTC)[reply]

Well said. I think, though, that the major points of disagreement for Hippietrail are the vintage cars and such. It's not easy to determine to what extend we can/can't/should/shouldn't include such terms, but difficult is not impossible. —Vildricianus 13:56, 29 May 2006 (U T C)

Widsith, I think you misunderstand me. I don't at all want to "divide" Wiktionary in two. What I want is to make everybody happy and still keep it in one place. If I fail in this then the only solution will inevitably to really "divide" Wiktionary by forking the database to some other site and removing all but the "conservative" entries and stating policies to match. That would be a bad bad thing. My proposal is about "tagging" content, not about division. Division is what I don't want. But sooner or later, especially when we have decent browsing features, the number of people unsatisfied with all the "cruft" in the index when they're just looking for plain old everyday words, will get to the point where somebody will say "We need another free dictionary without all this stuff in it". That would be division. It has happened to Wikipedia in the past and it can happen here too. Also, I'm sick of arguing. — Hippietrail 22:45, 29 May 2006 (UTC)[reply]

Well said, too. However, you're going to have to argue much more if you want this made clear to the broader public outside of the Grease pit. This is not "arguing", by the way, it's discussion and feedback, which is what you wanted. Your idea is quite revolutionary and may have many consequences and implications. People are conservative and afraid of drastic changes. That rule applies to Wiktionary as well. In my initial comments I was sceptical - I still am, but also see the benefits of your proposal and the possible solutions it may offer. I'm willing to experiment with it to prove its values, but will keep in mind what I've said above. —Vildricianus 10:20, 30 May 2006 (U T C)

Couple comments:

I'm not suggesting throwing open the floodgates to any and all contributions, and dismantling RFD, but as a thought experiment: how big a problem is it if there's "cruft in the index"? Under what circumstances would people be dissatisfied with this? Simplistically, it seems to me that an entry for some hopelessly obscure term is either useful to a user who does happen to search for it (and to whom it is therefore, almost by definition, useful), or is effectively invisible to everyone else. By "decent browsing features" do you mean ways of scrolling through alphabetical lists of all our entries? That seems unworkable even if we don't have cruft! (But it is true that people might be bothered by cruft if it happened to be spelled the same as the real word they were looking for, or nearby and shown to them by some automatic "did you mean?" function.)
At any rate, this seems very much like a Beer Parlour topic, not one to have off in this nuts'n'bolts gearhead room, where presumably we'd talk about how to implement new mechanisms after the policies which required the new mechanisms had been decided. Trying to invent the mechanisms first, or having the mechanisms drive the policy, is arguably wrong (though of course it happens all the time, because having the tail of implementation wag the dog of policy is sometimes the best one can do).

Anyway, all armchair philosophizing aside, I'm in complete agreement with you, HT, that some solid tagging mechanisms will be vital so that users can get useful views into some subset of an otherwise overwhelming corpus. –scs 22:30, 31 May 2006 (UTC)[reply]

Mmm, I followed this reasoning a couple of days - when I was only starting out here. Many reasons, here are a few:

Respectability - what sort of dictionary would we be? We're trying to become a reliable source.
Random paging - would lose its function; cruft would quickly outnumber the good stuff.
Space - wiki is not paper, but wiki is not just a storage for random strings of words either, which it would become if we started to allow all this nonsense.
Honour! - I wouldn't feel comfortable among the cruft, but that's probably more personal. Still, I guess the majority of regulars thinks this way.

And many more reasons, probably Wikimedia policy as well. Your idea is really a non-starter, but I guess it has to be spelled out from time to time.

Besides, it's very much Grease pit talk - working out a concept, predominantly technically. Presenting it on the BP is for a later stage, I guess. Also, from what I've learned here, policy comes after the solutions and decisions have been made. First comes the technical bit, a thought or two, then someone is bold; see for instance the creation of the Grease pit. If it appears to work, it will become common practice, and in a later stage, someone writes it down as policy. I know things are done completely different at Wikipedia. —Vildricianus 22:59, 31 May 2006 (U T C)

I agree with Widsith and would also welcome Hippietrails input which I feel is very valuable. I am developing a proposal at present not fit for public consumption yet which can be seen in my playpen (if anyone can find it - I think there is a link from my talk page) If anyone is really upset with what I am proposing please let me know. Andrew massyn 20:19, 29 May 2006 (UTC) [3][reply]

Standardized customizable inflection templates

In Category talk:Conjugation and declension templates/Inflection, conjugation, and declension template names, I have proposed that we standardize the names, purpose, and display style of three types of templates used in Wiktionary.

My interest in that topic is now renewed because of {{fr-infl-adj}} (used on "digital" and other entries). {{fr-infl-adj}} displays like a floating declension table (with the added property of showing pronunciation) but is named like {{en-infl-reg-other-e}} et al., which are used on the "inflection" line (immediately following the POS heading) to show the headword and its main inflections. Is there yet a preferred pattern for naming and display styles of the two types of templates?

Also, the existence of two sets of English inflection line templates ({{en-noun-reg}} and {{en-noun2}}) leads me to believe that editors have agreed to disagree about inflection line display style. If so, some CSS magic can let everyone have his or her way just as it does with {{cattag}}. Would anyone object to standardizing the inflection template display in a way that allows each reader to choose his or her inflection line display style? (Should I move this to WT:GP?) Rod (A. Smith) 19:39, 27 May 2006 (UTC)[reply]

I think a good place to start would be to come up with some standard CSS classes. We would need one SPAN or DIV (depending on whether it's inline or creates some kind of box or table) as a wrapper for the whole thing, and another SPAN for the actual inflected words. All templates should use the same classes so that people can say select italics for the body of the section and bold for the actual words - or however they like it.
The next step would be to come up with a flexible template that uses whatever it takes to please all the camps and produce an inline version or a version in a box or table etc. That's a lot more work and the place to do it is over in the Grease pit. — Hippietrail 22:05, 27 May 2006 (UTC)[reply]

Yes, standard CSS class names are key. At ~~the test site's "word" entry~~Template talk:en-noun, I have an example entry that uses the very simple test template ~~en-noun~~{{en-infl-noun}}. (BTW, I don't know how to wikilink across both language and project. Is it possible?)

Obviously, to see the table format, use this .css:

.infl-inline {display:none}
.infl-table {display:inline}

~~Likewise, this .css~~by default, it shows the inline format because the following is in MediaWiki:Common.css:

.infl-inline {display:inline}
.infl-table {display:none}

I somewhat hastly chose the CSS class names "infl-inline" and "infl-table". I'm sure there's plenty of room to improve that naming scheme. Since I think that inflection lines should look fairly consistent in each language section, I left the ISO language component out of those two CSS class names.

Regarding the name of the template itself, I don't know whether "{{en-infl-noun}}" would be better, but I have the feeling that short names are better since the Category:Inflection templates should eventually be nearly ubiquitous. Thus "{{en-noun}}". Rod (A. Smith) 23:28, 27 May 2006 (UTC)[reply]

Rod, I assume you weren't around during the last flame and edit wars about them? The thing has died down a bit, fortunately, so this may be the time to restart thinking about them. Also, with the new ParserFunctions, I'm sure someone can devise the final English inflection templates. Please be bold and show us some good stuff! —Vildricianus 23:56, 27 May 2006 (U T C)

I was lucky enough to miss those arguments and edit wars. I took your advice and built out {{en-infl-noun}}. I won't use it in any main namespace entry until it sounds like it has enough support for a trial run. Besides, we need to agree on some CSS class names and get those classes into the main monobook in order to prevent multiple inflection styles from displaying for everyone. Check it out, modify your Special:Mypage/monobook.css, and tell me what you think! Rod (A. Smith) 03:07, 28 May 2006 (UTC)[reply]

Looks great up to now. ~~I'm not sure whether the box style is more popular than the single-line style, though, but that's easy to change whenever it suits us.~~ Oh wait, I must have missed the CSS bit. Perfect! —Vildricianus 06:58, 28 May 2006 (U T C)

You've obviously done a lot of work on this, thanks! My first thoughts were that there's a hell of a lot of options which I for one and certainly most newcomers will be hard pushed to remember. I think we only really need two paradigms - {en-noun|singular|plural} which wikifies automatically, and {en-noun2|"[singular]”|either “[this]” or “[that]”} where you can include more detailed disambiguation. That doesn't include info about whether or not it's countable, but it isn't necessary since that has to go on the def lines anyway. Widsith 16:20, 28 May 2006 (UTC)[reply]

Yes, the template must be easy to use, read, and remember. I tried to make sure it would please everybody, so it supports several equivalent ways to show the same thing. That doesn't mean everyone needs to use every option, just as not everyone needs to know every MediaWiki parser function to write a good entry.

I think it's easiest to show usage options with concrete examples. So, assuming that your example applies to irregular plurals, e.g. "cactus/cacti", the template can be used in either of the following ways on the "cactus" entry:

{{en-noun|cact|i}}
{{en-noun|cacti}}

Or, to specify multiple plurals, either of the following:

{{en-noun|cacti|pl2=cactuses}}
{{en-noun|''Either'' '''[[cacti]]''' ''or'' '''[[cactuses]]'''}}

To me, the styles seem terse, natural, and flexible, and depending on one's background, at least one will easy to remember because it reads like some dictionaries. Would you prefer a different syntax for irregular plurals or are you talking about regular plurals? Those are even easier.

As for countability, It would be difficult to convince everyone to stop indicating countability on the inflection line, so the template must support it, right? Or was there some decision not to show countability in inflection lines?

Either way, I'll clean up the usage notes so it doesn't look so complicated. Rod (A. Smith) 17:33, 28 May 2006 (UTC)[reply]

That looks great. If it works out, this could solve one of the longest-running disputes on Wiktionary. Widsith 18:43, 28 May 2006 (UTC)[reply]

It looks really really good to me though I haven't played with it. One minor thing is I think every template name should start off with it's function, thus I would prefer infl-en-noun. We probably need another topic just on template naming - I think it's one of the reasons many users dislike them and a few vehemently hate them.
A bigger problem is languages with a lot more inflections. The Russian tables are surprisingly concise, but those for Spanish and Swedish for instance are a whole different kettle of fish. Maybe it's possible to have a brief and expanded version where the brief version includes only the forms that from which all other forms can be derived. I think some dictionaries for some languages do this - I think Latin is one. The full version will be more like what you see in verb table books. — Hippietrail 19:12, 28 May 2006 (UTC)[reply]

It certainly looks great. Here's my thoughts:
- I think the templates should be as concise as possible and contain only the necessary. If there are obsolete plurals and things like that, they can be noted in the template, but the main explanation of how and when should go in its own section, probably =Usage notes=. Usually, things like US only or obsolete except Scotland are hardly useful. A short paragraph describing history and such is more what Wiktionary should be about.
- Whether countability is used on the inflection line or on the definition line doesn't matter much now. We can remove or re-add it as we please if we have a stable and universal template.
- About the naming: I don't think the function should come first. Actually, pretty much all templates have the language first. I'd really stick with {{lang-pos}} for the inflection line templates, to keep them as simple and concise as possible, but that's of course open for discussion.
- I think the intention is to have concise inflection-line templates versus extended own-section table templates.
- The Russians are concise because it's way too complicated and bombastic to create 88 different templates, some of which would be used for only a handful of verbs. Therefore, the noun and verb templates are merely containing the ugly table syntax so that users are not confronted with these. They have little to do with "real" inflection templates, actually. —Vildricianus 19:44, 28 May 2006 (U T C)

Yes, in fact, "infl" would be a misnomer for parts of speech that don't inflect (e.g. EN adverbs, JA nouns, ZH verbs). We say "inflection line" and "inflection template" as loosely as we say "part of speech". I hope to have a single template for each language-pos combination.

The key features of an "inflection line" at Wiktionary seem to be showing the emboldened headword and its key forms (e.g. some important inflections, transliteration, or diactitics). Each language-pos combination has a fixed but possibly incomplete set of key "inflections" (e.g. de-noun has nom/gen/pl, en-adv has only the headword, es-adj has m/f/mpl/fpl, ja-noun has kanji/kana/romaji).

For more details, optional conjugation and declension templates can show everything from archaic EN 2nd-sing, to EN possessives, ES future, and RU instrumental, all nicely organized in a table in separate level 4 section, consistent across languages.

In case it's not painfully clear, I'm striving for consistency. This model seems applicable to all parts of speech in all languages. Rod (A. Smith) 07:30, 29 May 2006 (UTC)[reply]

I'd like to be bold and create a default style in MediaWiki:Common.css for the customizable universal inflection templates, but this seems like politically dangerous ground. There appear to be many more entries using the inline inflection templates (i.e. "type A") than using the table templates (i.e. "type B"), so the least-impact choice would seem to be to use inline inflection style as the default. Should I open the topic up at WT:BP? Please offer any suggestions on how to approach this potentially explosive decision. Rod (A. Smith) 16:56, 29 May 2006 (UTC)[reply]

I guess you can be bold here. The main proponent and creator of the box styles is more or less absent now, but I think he wouldn't oppose making inline the default, as long as he can have his boxes for himself. I think the inline styles are more popular and certainly much older than the boxes, and from my experience with them, have shown much more flexibility layout-wise, so that the majority of users should see them instead of the boxes. —Vildricianus 18:29, 29 May 2006 (U T C)

Lurking is different than absent. --Connel MacKenzie T C 18:57, 29 May 2006 (UTC)[reply]

He's at all times free to comment here or elsewhere. No voice, no choice. —Vildricianus 19:56, 29 May 2006 (U T C)

Lurking indeed. Ncik 16:22, 30 May 2006 (UTC)[reply]

Yes, indeed. You are still welcome to contribute to these conversations. Please do so! Discussing things before going off on your own tangent is much more productive. --Connel MacKenzie T C 20:14, 31 May 2006 (UTC)[reply]

The larger problem of consolidating the verb templates, is the non-standard order of parameters that Ncik used in his templates. That order is still incorrect, as it does not allow for the logical (simple) combination of past and past participle via template defaulting. Also, the pointed reordering from the standard used for a long time prior, (particularly in Uncle G's templates) is a point of confusion for Wiktionary readers.

Now that the color of the boxes has been rectified, I'm much more favorable towards them - but I'd still like to see the wording corrected to match the original templates. The original templates' wordings were discussed at length; the Ncik templates' wordings were not. I know some contributors object to the problems the boxes cause for image placement, but I do not see that as an insurmountable obstacle.

Rectifying that situation I see as a two-step cleanup process. The first step would be to have temporary templates with correct ordering. The next would be to have them 'bot corrected to reorder the parameters into the new template name.

Eclecticology objected to any such improvements in the past, citing template "ownership" or something. As a result, we've been stuck in a sort of detente where Ec considers conversion of one template style to the other a non-NPOV edit.

--Connel MacKenzie T C 20:14, 31 May 2006 (UTC)[reply]

It sounds like there isn't yet any objection to {{en-infl-noun}} or to the consolidation of inflection templates in general, so I'm quite hopeful for the prospect of a universal English verb inflection template. To make sure that consolidation is not viewed as POV, I have asked for opinions regarding {{en-infl-noun}} from Ncik, the only person who has so far been identified as strongly advocating table-style inflections. When all the technical challenges have been answered, the recommendation to deprecate the redundant inflection templates and to move the universal templates to "en-adj", "en-noun", "en-verb", etc. will of course move to WT:BP for approval. Rod (A. Smith) 22:12, 31 May 2006 (UTC)[reply]

To make it easier to move {{en-infl-noun}} and {{en-infl-verb}} to their logical homes (i.e. "en-noun" and "en-verb"), I temporarily added "legacy syntax support". I.e., if the first parameter matches the pagename, the templates behave compatibly with the legacy templates. That support lets us (1) move the new templates directly over top of "en-noun" and "en-verb", (2) gradually convert legacy syntax to the new syntax, (3) train editors to use the new syntax, and (4) eventually remove the legacy syntax support.

I realize we haven't yet simplified CSS editing, but the only identified table-format advocate doesn't object to consolidation, so unless anyone has any remaining technical points to address, I'll request approval on WT:BP. Rod (A. Smith) 22:47, 3 June 2006 (UTC)[reply]

Well done. I guess the majority will keep the default anyway. Those who complain will get personal assistance if they don't want to/can't edit their CSS files. In general, (it was I who raised the question of making it more user-friendly) I had in mind to find a solution in the long run, for our expected thousands of users anywhere in the near future. It's not pressing at all, as long as we have such a small community.

Q: What do you mean by "gradually convert..."? This is still planned for a bot, right? — Vildricianus 23:19, 3 June 2006 (UTC)[reply]

I said "gradually convert" to indicate that it's OK if the first bot pass mistakenly treats lots of "regular" nouns and verbs as "irregular". E.g. the bot may see "{{en-verb|dry|dries|dried|drying}}" and not be able to figure out that "dry" is actually a regular verb. It would be OK for it to leave the entry alone and let us change it later to "{{en-verb|dr|i|ed}}". Rod (A. Smith) 00:48, 4 June 2006 (UTC)[reply]

Um, Yes. Can we have some more discussion on the direction this is going first, please? I do not think this is quite ready to start, just yet. I'm sorry that I haven't kept up with this conversation so far - it seems like it is moving a little faster than it should. --Connel MacKenzie T C 00:56, 4 June 2006 (UTC)[reply]

To be a little less vague, I thought the longer-term concept was to have the {{en-noun}} and {{en-verb}} the the "real" versions, containing all the forms as User:Polyglot indicated a year ago, (with past and past part. as the last two, so that one can be left off if they are the same.) Proceeding from that point, the "Uncle G" templates would then be used only to assist in the various "preload" templates, resulting in the expanded {{en-noun}} and {{en-verb}} forms (when saved, with "subst:".) This would allow for the host of "preload buttons" on new pages. To most users, it would then look like we no longer use the "Uncle G" templates, when in fact, they would be heavily exercised with each new entry.
Reading all of the above, it is not clear to me, that that goal is still in sight. Have I misread it? --Connel MacKenzie T C

I wasn't here for Polyglot's proposals a year ago, but I gather from your comments that an earlier plan was to consolidate all verb templates. Good. You mention that the earlier plan was to use the form "{en-verb|start|starts|starting|started}". Note that the new template allows the parameter order you describe but it also allows simply "{en-verb}". I'd be happy to review the conversation you mentioned so that I can gather any useful recommendations from it. Where can I find the conversation? Rod (A. Smith) 02:30, 4 June 2006 (UTC)[reply]

Goodness, that template test:w:Template:en-noun looks extravagant! That must've taken an enormous amount of effort, and wow, does it look thorough. --Connel MacKenzie T C 01:18, 4 June 2006 (UTC)[reply]

Let me know if I can help answer any of your questions. Remember, the conversation is here to work out technical details. It will later move to WT:BP for approval before any conversion begins. Rod (A. Smith) 02:30, 4 June 2006 (UTC)[reply]

I want to propose the following on WT:BP:

Get approval of {{en-infl-noun}} and {{en-infl-verb}}.
Move them over top of {{en-noun}} and {{en-verb}}.
Wait a week for additional feedback.
Migrate from and deprecate all the other English noun and English verb inflection templates.

Please let me know how much more time you would like to review the technical details before I post the proposal to WT:BP. Rod (A. Smith) 21:11, 8 June 2006 (UTC)[reply]

As for me, please go ahead. I trust you've got them technical tricks worked out (massive work!). The sooner this can get standardized, the better. — Vildricianus 21:16, 8 June 2006 (UTC)[reply]

OK, on to WT:BP! (Shouldn't there be some scene change music for these transitions?) Rod (A. Smith) 07:33, 9 June 2006 (UTC)[reply]

Latin templates edit

I'd have come into this discussion sooner if I hadn't had such limited access for the past month (and coming few weeks). I applaud the attempt to do all this, and am eager to work with you on standardizing the Latin templates sometime soon (well, not the verbs yet). While I have the grammatical knowledge, I've held off for making any changes because I wasn't up on all the possible formatting and structuring issues, which seem to be on your mind. If you don't hear from me in a month or so, contact me directly, please. Also, there is a list of exisitng Latin templates in my Laboratorium, so that you can get a sense for the complexities of a language with numerous conjugational forms. --EncycloPetey 02:19, 16 June 2006 (UTC)[reply]

Thanks. I'm very much looking forward to working with you on the Latin templates. I will be sure to contact you directly at that time. By the way, would you recommend that Latin be the language to follow English in this effort? If not, any suggestions on what language to tackle next? Rod (A. Smith) 02:24, 16 June 2006 (UTC)[reply]

Spanish would be a logical choice. It's got inflections, but few of them and they're regularized (even the "irregular" ones in some situations). Hippietrail might be able to help with that -- he seems to have a much larger vocabulary than I do, at least. I have several big grammars and dictionaries that might help as well, if you keep me posted (and are patient, as I currently don't have access from home). From Spanish, it will be easier to go into Latin and other Romance languages. The advantage is that it's much easier to get good information on Latin as aroot language than it is in other language families, so it's easier to figure out what's going on historically with conjugational irregularities. Oh, and keep in mind that SemperBlotto speaks Italian. --EncycloPetey 03:15, 16 June 2006 (UTC)[reply]

I'll keep those points in mind. Spanish seems like a good next victim. It doesn't have much in the way of adj/noun declension, so we can primarily focus on the POS ("inflection") line and on the conjugation tables. I personally like the way {{fr-noun-reg}} takes the noun's gender as a parameter and would like to do something similar with the noun templates of all languages where gender is key. A fresh WT:GP topic is probably in order for that, though, so maybe I should wait to open that can of worms when the English templates are in place. Rod (A. Smith) 04:57, 16 June 2006 (UTC)[reply]

*Cough* Dutch *Cough* :-) — Vildricianus 09:22, 16 June 2006 (UTC)[reply]

Duly noted, but you really should have that cough looked at. :-) Rod (A. Smith) 18:19, 16 June 2006 (UTC)[reply]

Rodasmith, I would very much appreciate it if you could kindly look at Wiktionary talk:Swedish inflection templates#Naming conventions and templat layout and give any comment you may have. (Oh, and if I do get a goahead from the community, I will most likely need to bother you about template syntax details too *smile*) --sanna 15:11, 9 July 2006 (UTC)[reply]

Request for unknotting/New RFD page edit

Connel suggested that categories and templates be given special treatment in the deletion process because of their deep-rooted linking in the actual process of deletion by those "privileged" with the task. Would this be a request for removal/extraction/what? Presumably on a page distinct from RfD. Probably wouldn't apply to Thesaurus: when it's up and running under whatever name. What about Wiktionary: and other namespaces? Would speedy deletes still be possible? Davilla 18:24, 27 May 2006 (UTC)[reply]

Wow, did I really mangle the spelling that badly somewhere? --Connel MacKenzie T C 21:14, 27 May 2006 (UTC)[reply]

No, a joke about admin duties, with my misspelling (privilaged, bleh!). Sorry for the implication, unintended. Now fixed. Davilla 05:39, 3 June 2006 (UTC)[reply]

No idea. I agree, though, with Hippietrail that the RFx processes may not continue to run smoothly, if they ever did, due to size, activity and complication. We may need to revise things. Come to think of it, it is perhaps not a bad idea to keep RFD for main-namespace entries only. —Vildricianus 18:33, 27 May 2006 (U T C)

There's a fine line I haven't tied down yet for the Grease pit but my feeling is that this topic is about policy rather than development and that policy belongs on the Beer parlour. But I'm not sure.

~~I would submit that policies regarding format are BP material, and policies regarding process are GP material.~~ Anyways this topic I placed in GP because it concerned the development of a template {{rf?}} and involved admin stuff that I'm not eager to get my hands into. Davilla 19:00, 27 May 2006 (UTC)[reply]

I don't really have much to say on this other than I noticed that Wikipedia has a distinct process for deleting categories since my pet category w:Category:Tonal languages is currently being wiped from the face of the earth )-: — Hippietrail 18:36, 27 May 2006 (UTC)[reply]

I do think this is the sort of conversation the GP is for. It is part policy, part mechanics. That is, if deemed to be a good enough concept, how would they be split out? NS:0 vs. all other, or separate sections for each namespace? Should the old RFD style be retained for the new (experimental?) page, or should the sub-page concept be used? Or, should we proceed to Wikipedia-style sub-page-subpaging by date? The GP seems like a great place to work out the details of how to do it, so it can return to the BP when the kinks are worked out, and perhaps the pros and cons of the different approaches. --Connel MacKenzie T C 21:14, 27 May 2006 (UTC)[reply]

All non NS:0 mingled together for now seems best. There aren't all that much nominations after all for those. But I'd indeed like to experiment with a different approach. Should we ask someone from Wikipedia to say whether their system is really working? BD2412? —Vildricianus 14:15, 29 May 2006 (U T C)

Getting it to work right isn't a question of enforcing it. Coding things correctly, the same rfd template can be used linking to the correct deletion page depending on {NAMESPACE}. I think this might be a good idea because of the differences in rules. I suggest calling one Requests for elimination, or something that suggests that the word will be forever stricken, and the other Requests for depreciation (deprecation?), suggesting disuse. Davilla 05:49, 3 June 2006 (UTC)[reply]

Renamed topic because it took me ten minutes to find it. I'd like to be bold for just once, and create this in a style similar to the GP's creation. But besides being stuck on a name ("Requests for unknotting"? "Requests for deprecation"? "Requests for non-main-namespace pages for deletion"? "Requests for anything that really can't go in RFD because technical aspects may differ and therefore consideration for deletion or phasing out must be viewed differently - also to relieve the main RFD page"?), I'm also stuck on the desired process. Is it going to be RFD part II, with casual nominations and ensuing argumentative disagreements? Or were we going to experiment again on something fancy? I think I'll just go for the RFATRCGIRFDBTAMDATCFDOPOMBVD-ATRTMRFDP suggestion I just made. — Vildricianus 22:39, 3 June 2006 (UTC)[reply]

I already want to comment that I don't think WP-style subpages are beneficial. WP gets dozens of AFDs a day, we'll be happy to fill our page with those few templates and categories. On the other hand, we have real discussion, whereas WP has just votes. I guess the aspect of the new page will be focused on exactly that, as I have a gut feeling the first nomination will be some kind of policy page or whatever controversial issue up for deletion. Perhaps the old-style RFD process is not that bad. Another gut feeling tells me that because of its very nature, this page and that one will be kind of related, and I don't think we'll have to put our oncoming efforts into keeping discussion to a minimum there (as I feel is sometimes done on RFD, even if by the length of the page). It may be beneficial for some people to have the room to get their age-old woes about some templates off their chest. — Vildricianus 22:51, 3 June 2006 (UTC)[reply]

New RFD page edit

I'm going to be bold one of these days. Suggestions for a name? I'm clueless. Perhaps Wiktionary:Requests for deletion/Non-main namespace? A bit long though. Wiktionary:Requests for deletion/Other? I think having it on a subpage of RFD will make it more accessible. Perhaps, ns:0 RFD should also go on a subpage, with RFD itself then leaving links, explaining policies and processes or something like that. — Vildricianus 15:10, 16 June 2006 (UTC)[reply]

The dictionary entries do deserve their own page. The terms can be listed for deletion because they are encyclopedic or non-idiomatic, or have failed or would obviously fail verification. I would avoid using "main namespace" as it's rather technical and cryptic. In the future these may be further divided by language. It might be too difficult to enforce classification according to the reason for deletion.

Thesaurus entries will require tools similar to Wikipedia. Besides deletions, there will be splits and mergers.

I still like Requests for deprecation for templates and categories, maybe also mediawiki and Wiktionary policy pages. The question is where to throw all talk pages (or should it only depend on the PAGESPACE?) and the much less common appendix, user, image, and help. Davilla 06:23, 17 June 2006 (UTC)[reply]

I'm going to experiment a bit. The new page will be a subpage of RFD, perhaps one subpage for each namespace. — Vildricianus 15:56, 20 June 2006 (UTC)[reply]

WT:RFDO

Comments and suggestions welcome (here). — Vildricianus 18:18, 20 June 2006 (UTC)[reply]

Comment: Thank you. --Connel MacKenzie T C 08:09, 21 June 2006 (UTC)[reply]

Wiktionary:Grease pit/Problems displaying IPA + Classes for support of unicode ranges

User CSS vs. real MediaWiki preferences edit

One of the major hurdles facing our customization efforts is that most users want nothing to do with "monobook.css". We need a way to let users select CSS options through Special:Preferences. I think we need a developer liaison to help us with that task, right? Rod (A. Smith) 17:23, 29 May 2006 (UTC)[reply]

See User talk:Hippietrail#WT:CUSTOM. Had this page existed back then, I could have asked here :-). —Vildricianus 18:20, 29 May 2006 (U T C)

Thanks. My summary of that conversation follows. Please fix any mistakes in my paraphrasing:

[It would be ideal to make customization easy without fiddling with CSS or JS, something like Special:Preferences, or something that can be made via a small developer intervention.] —Vildricianus 21:01, 21 May 2006 (U T C)

Like, having separate skins? :-) --Connel MacKenzie T C 21:16, 21 May 2006 (UTC)[reply]

[...] Without opening a gateway between the Wiktionary hackers[...] and the actual MediaWiki hackers, there is no way for us to add features or customize besides Javascript, CSS, templates, and connecting via those to offline sites such as Connel's site where the random code is. It's true this is not user-friendly for non-hackers but there are several things we can do:
1. We can use JS to add extra prefs pages which generate the code which can then be copied and pasted into the users's CSS and JS pages.
2. We can coordinate a group of JS/CSS/Template hackers, possibly some of us can start hacking MediaWiki on our own machines or on a public site with CVS access for us, with another group of nonhacker Wiktionarians who can use and promote our changes to the MediaWiki devs etc, thereby opening a dialog so that when we have patches we want added to just en.wiktionary.org that we won't be ignored and won't be just 2 or 3 lonely voices
3. There may be a lot more we can do with JS if the devs give us just the power to define a few cookies of our own - that would make possible adding JS/CSS customization directly from a new prefs page to the user's custom JS and CSS pages, among many other things.
I think we need to continue with what we're doing, provide much more documentation and encouragement for non-hacker Wiktionarians to use our work, accept it, get used to communicating with us on improving it, help them to understand how we are held back by not having developer access to our own project, and getting such users to support our efforts on the way to either some of us becoming MediaWiki devs, or sustaining a reliable open chanel with the MediaWiki devs, or getting MediaWiki to split off to a certain degree en.wiktionary.org in some way that allows some of us to be devs just on it so that we can develop it into a dictionary-specific MediaWiki with our own extensions, etc.
I think that's the short-term and long-term visions[...]. — Hippietrail 00:14, 23 May 2006 (UTC)[reply]

Excellent. Now if "preload" could be allowed to work with existing pages, we could enable finely-detailed, easy configuration of Special:Mypage/monobook.css, e.g. by having JS in Special:Preferences expose something like http://en.wiktionary.org/w/index.php?action=edit&preload=Template:custom-monobook-mentionBold-inflectionTable-serialcommaHidden&title=Special:Mypage/monobook.css , based on users selecting preference options. Rod (A. Smith) 20:04, 29 May 2006 (UTC)[reply]

Even nicer, would be to have the "Preferences tabs" (and content therein) modifyable in Special:SystemMessages. The dev's might think that is a bit heretical, as all preferences would need corresponding software/extensions. --Connel MacKenzie T C 20:26, 29 May 2006 (UTC)[reply]

This might not solve all the problems. It will give us the tabs but how will it let us invoke the actions that fiddling with the tabs should invoke? What might work is a feature request specifically for Preference tabs which manipulate only CSS - perhaps with a new CSS page that is not editable by hand - there are already several levels of CSS. I encourage you to talk to the devs on IRC which I cannot do, or file a feature request, and I will join in. — Hippietrail 21:25, 29 May 2006 (UTC)[reply]

As a first step, I have posted Bug 6134, "The possibility of creating and manipulated cookies via JavaScript". — Hippietrail 22:38, 29 May 2006 (UTC)[reply]
Sad to say, Brion has closed this one as invalid with only the comment "You might want to check a general JavaScript reference". I don't find that helpful at all. Is there anybody here who knows enough JavaScript to explain the problem? — Hippietrail 23:09, 29 May 2006 (UTC)[reply]
Don't know Javascript but enough to know that you can add cookies via Javascript. That would require adding Javascript to a page, and the MediaWiki where it allows it I don't know well enough, but I suppose it must if e.g. TOC is collapsible. Davilla 16:04, 31 May 2006 (UTC)[reply]
- I take that as encouragement that they are allowed (via Javascript.) I'll have to try soon. --Connel MacKenzie T C 23:58, 29 May 2006 (UTC)[reply]

I'm on a roll so I also posted Bug 6135, "A way to manipulate CSS-based preferences via the GUI". Please participate in these bugs reports if you can. I fear a lone voice may well be ignored. — Hippietrail 23:03, 29 May 2006 (UTC)[reply]
Shouldn't we ask if these things are already possible before writing them as requested features? Or maybe this is just my reaction to seeing these and requests from other folks labeled as "bugs". If it's odd to me, it's a form of dialogue anyways. Davilla 16:33, 31 May 2006 (UTC)[reply]
I try to file a request before I'm pretty certain there's not a way to solve it already. If there is a way it's only a minor embarassment and the request will be closed. Bugzilla covers bugs and feature requests, each item is marked as one or the other but for Bugzilla purposes only, feature requests are a subtype of bug. Nothing to worry about, just jargon. — Hippietrail 17:19, 31 May 2006 (UTC)[reply]

I haven't followed all this, and I don't have my head fully wrapped around CSS and skins yet, so pardon me if I misstate, but let me see if I've got the basic picture.

We need a way to set our own (per-project) cookies, to affect behaviour in our per-project CSS. (I presume we're already in charge of our per-project CSS and that there's no other big problem there.)
The right way to get those cookies set would involve new questions and checkboxes on the Preferences page.
Therefore, what we need is a way to add per-project extensions or other customizations to the Preferences page.

I don't think it would be out of the question to devise a mechanism which would allow such extensions, and if implemented reasonably, I doubt the MediaWiki devs and WikiMedia admins would object.

If this is a reasonable track to go down, I'll look into the feasability of such an extension mechanism (I'm becoming somewhat familiar with the mediawiki software), and ask on the Wikitech mailing list whether they think this is a reasonable track to go down. –scs 21:34, 31 May 2006 (UTC)[reply]

Unless I've missed something, I don't think cookies have anything to do with the challenge. Instead, I think we need the ability for users to modify their Special:Mypage/monobook.css file through selections in Special:Preferences. Rod (A. Smith) 21:46, 31 May 2006 (UTC)[reply]

"Users to modify their monobook.css file"? What user monobook.css file? I don't have my own monobook.css file, do I?
(/me finally gets around to trying that special link)
Oh! Lookit that! I do potentially have my own monobook.css file, and pretty easy to get to, at that!

Anyway, all the talk about cookies (here in this subthread, that is) made me think someone was talking about having the site-wide CSS script adjust its own behavior, based on simple cookies, so that users wouldn't have to mess with per-user CSS at all (which, convenient though I now see the Special/Mypage link is, is still pretty far from what we'd want the average user to have to mess with). But come to think of it, there probably isn't a way to have CSS look at cookies. (Now where did I get the idea someone was saying there was?) –scs 22:56, 31 May 2006 (UTC)[reply]

I was wondering whether you are still considering devising a temporary solution via preload templates? —Vildricianus 22:00, 31 May 2006 (U T C)

The "preload" solution would probably be a single line of code for developers and flexible for us, so I hoped that would be easy for us to get. I don't know whether they will approve that request, though. Rod (A. Smith) 23:11, 31 May 2006 (UTC)[reply]

I don't get the "preload" business to solve this - can somebody explain it a little? — Hippietrail 02:11, 1 June 2006 (UTC)[reply]

My proposal is to use JS on Special:Preferences to create CSS and to preload it over Special:Mypage/monobook.css. The user would then preview and save the generated css. Each Special:Preference option would correspond to a display preference like "bolded mention" or "gender period visibility". Rod (A. Smith) 04:16, 1 June 2006 (UTC)[reply]

If you type in a non-existant term in the search box, and press [Go], you are given a table of various "preload" templates that can be preloaded when you edit that entry. Once an entry exists, the preload capability no longer functions. So the "Buttons" concept is, IMHO, quite superior...see User:Vildricianus/monobook.js for examples. Using Javascript, we could be completely evil, and shrink the edit box size down to very small (or hide it entirely) when editing Monobook.js/monobook.css...and fill the screen with button options. That would be very evil though. And the Javascript would have to be pretty advanced, to be able to check and uncheck boxes. Additionally, since we can tack on goofy no-op parameters onto the URL, we could still enable raw editing under certain conditions. Of course, these ideas go far beyond "klugy" into the realm of "sinister" and I would not be comfortable doing such a hideous thing. Didn't I say something like that about the LC/UC redirects? --Connel MacKenzie T C 22:35, 1 June 2006 (UTC)[reply]

Tricky templates Part I edit

What's going on with the entire italbrac and cattag stuff? These templates are becoming ever more complicated, each one calling another couple of templates. Are you guys sure that's all necessary? Keep in mind to keep it as simple as possible; people who come after us should still be able to understand what we're doing. If it's really necessary, then please document it thoroughly. I'm afraid saying "documentation is on meta" is not sufficient.

Here's the list of templates called for the simple tag {{chemistry}}:

Template:cattag
Template:cattag/category
Template:cattag/pass1
Template:cattag/standard
Template:chemistry
Template:foreach
Template:foreach/pass1
Template:italbrac
Template:italbrac/pass1
Template:x0

Although it's an amazing job what you guys are doing there, I'm sure this can be simplified. — Vildricianus 15:06, 5 June 2006 (UTC)[reply]

It could be simplified ten times if the wiki syntax had some basic functionality built in that it doesn't. The template foreach is documented on meta but it should really be a built-in construct, avoiding some of the hacking that has been done with special symbols and resulting in less literal evaluation. In fact on meta it's carried out to 150 arguments, which I considered to be a ridiculously excessive means to approach the problem. Recursion is also problematic because it isn't allowed explicitly, but it is allowed if you use redirects. In fact these were not implemented with forward thinking because some limited recursion is not necessarily evil and could be accomplished much more cleanly. As it is they've tried to avoid problems by limiting capability, which doesn't do anyone any favors. Nonetheless I think I may have discovered a way to perpetually slow down the servers that of course I don't want to test. That would perfectly exemplify why it's better to use a clean approach.

Then it's difficult to keep the code itself looking clean because extra spaces are often translated into the output. In general there is a confusion of code and data that produces too many special cases. In fact I'm taking advantage of this as the only way in my case to know the level of recursion. If there were a simpler construct such as a static variable or a way to check the call history then this would not be necessary. Of course I'm not asking for that functionality because it would just make the whole system that much more of a mess. All of this in fact is jumping through hoops to get around a bug that reassigns passed variables when undeclared variables are checked for. This system of variable passing is itself a rather nasty concoction, relying on old call by name (rather than value) and text replacement principles that have been eliminated in modern languages, whatever the meta site might claim. Davilla 07:00, 6 June 2006 (UTC)[reply]

I empathize with you, Davilla. Since we are building increasingly tall large towers from our stone knives and bear claws, it is becoming increasingly important to be able to verify template functionality after even minimal changes.

To that end, I've drafted a rudimentary functional testing pattern (with use instances at Template talk:en-infl-verb/test and Template talk:en-infl-noun/test) about which I'd appreciate any comments. The pattern is to create a test suite as one or more subpages of the template's talk page that exercise the template's functionality in a human-verifiable format. Each test obviously needs to show both expected behavior and actual results.

Immediately obvious deficiencies include caveats about namespace and pagename evaluation as well as the need for manual verification. The former is ugliness we can probably cope with and the latter can be addressed via external tools. In any event, if we improve and follow a template testing pattern, we should simplify the maintenance tasks for ourselves and for those who follow us. Rod (A. Smith) 08:17, 6 June 2006 (UTC)[reply]

It could be simplified ten times if the wiki syntax had some basic functionality built in that it doesn't.

There's a good reason MediaWiki doesn't allow much of this sort. Recursion, passes, variables and loops are beyond me I'm afraid - maths has never been my thing - but I'm talking about a general idea here.

There's also a good reason why {{foreach}} has been deleted from Wikipedia. These things do pose a strain on the servers, not yet for us, but for bigger sites with more visitors. Perhaps we get better servers, or better software before we're big enough to have problems, though. Please continue with experimenting and expanding the templates, but also keep in mind some of this stuff. — Vildricianus 18:33, 6 June 2006 (UTC)[reply]

Server strain is a perfectly good reason why foreach should be a language construct rather than a text-based evaluation. Ideally a single parameter would be treated as a single parameter and not 150 like the foreach on meta requires. When I copied it I doubted we'd ever have need for more than nine arguments to any template, so that should avoid some of the overload that Wikipedia experienced. But that could create an arbitrarily low limit as well. I'll take a look at foreach and see if there's any way to streamline it.

Unfortunately cattag is rather complicated and there's not much I can do to eliminate the extra templates. In fact I would like to create more because there's so much shared code which would be easier to read as subroutines, but I've refrained as per your request. I'll see if I can reduce the number of calls to category from four or five down to two, which will make inlining that template feasible, but that's about all that can be done. A higher priority right now is making sure that the categorization is completely functional.

As for italbrac and italbrac-colon, they seem simple enough to be rolled into cattag and other functions once they've been proven and weather tested. In fact I sort of had to do that already, but opted to split italbrac into several parts (first, inner, separator, and last, in addition to pass1) to allow them to be customized. If I had hard-coded it into cattag I don't think anyone would have wanted to touch it. But I'll roll them in eventually. Davilla 19:13, 6 June 2006 (UTC)[reply]

Thanks for considering it. I'm merely concerned with 1/ complexity of things (i.e. if the few people here that understand it decide to leave all of a sudden, everyone else is stuck); 2/ server strain (per below); 3/ possible vandalism targets (see also below). Other nuisance is the list of templates used on a page getting ever bigger, making it harder to find out which are actually used.

Also of note, if we're going to keep this the way the tag templates work, all their meta-templates will have to be protected, if not fully, then at least semi. Once these templates become more widespread, any change to any of their meta-templates will create a job queue of a couple of hundred thousand articles. — Vildricianus 09:42, 7 June 2006 (UTC)[reply]

Agreed, agreed, agreed. I'm afraid though that once cattag is established the only way to make any changes will be to replace the system in full. The reason it has to be so complicated is that it relies on the existence of other templates to know what the parameters should expand to. Because of language limitations this isn't an easy task. I'll take a fresh look at cattag to see if it can't at least be simplified, maybe reducing the strength of some of the error checking. I'm used to the typical input/compute/output model and there's a strange way of looking at wikicode that allows functions to be inserted mid-sentence. In some cases if it's done right then separate sections can be combined, avoiding duplicity or eliminating the need for subroutines, and making the code more readable and therefore editable. I'm also open to suggestion on how to format without stripping out all extra whitespace. Davilla 15:58, 7 June 2006 (UTC)[reply]

Have you considered Rod's <!--

--> trick ? That allows spaces and blank lines. — Vildricianus 19:31, 7 June 2006 (UTC)[reply]

I feel pretty strongly that Rod's suggestion above is most relevant. cattag should not be doing all this verification - that should be done offline.

I am alarmed to see so many separate calls. Even if the optimization is as good as people say it is (which I can believe, but choose to doubt) there are still that many recursive calls for each page edited. This should be subst:'ed up into their parent template(s) wherever possible. Where not possible, offline verification should be considered.

On the other hand, I do like the clever features I see being added. It is a pretty tough call, but I think we can get this back into one single template if we put our collective intelligence to it. --Connel MacKenzie T C 05:45, 9 June 2006 (UTC)[reply]

cattag edit

I've been trying to get cattag to work so that if {{lex}} produces {{italbrac|lexicography}} then {{cattag|lex|dated}} produces {{italbrac|lexicography|dated}. Right now I use {{cattag|lex}} at template:lex and have a magic list at cattag/standard that substitutes lexicography for the parameter lex. But the magic list I think is troublesome because it has to be maintained. What I'd like to do is use the label templates themselves as magic lists. That is, if a template exists, for instance {{math}}, and if the content is different from the template name, in this case mathematics, then use the content of the template rather than the abbreviated parameter. But the content of the template is actually {{cattag|mathematics}} unevaluated and (mathematics) evaluated, and I don't know how to strip the parenthesis or any of that other junk off. Davilla 17:05, 3 June 2006 (UTC)[reply]

added two SA words, kaalgat and gatvol with the catagory, but it hasn't shown up on the catagory page. Any ideas why? Andrew massyn

Categories take up to five minutes to refresh, some times. Also, kaalgat does not seem to use the cattag template. --Connel MacKenzie T C 19:14, 4 June 2006 (UTC)[reply]

If you use cattag, as you should for more than one label, or if you use any of the label templates that (should) call cattag, then the category will not be added if the category does not exist! This is meant to avoid the creation of categories that might duplicate ones alternatively worded, such as Category:South African English instead of Category:South Africa. I am working out some kinks with abbreviations as in the above text, and then I will document how to indicate categories when the name differs. Davilla 14:31, 5 June 2006 (UTC)[reply]

Okay I've found a crazily complex work-around and rolled in this new version. Using {{cattag|label1|label2|etc.}} will produce the same result as {{label1}} + {{label2}} + {{etc.}} whenever the templates exist, provided they call cattag themselves, and just the plain text otherwise. Oh, plus categories when they exist as well. Try out the new system and see how well it works and if there are any special considerations that should be addressed. Davilla 19:26, 6 June 2006 (UTC)[reply]

This is a crazy thing, I'm tellin' ya. What's the difference between {{cattag|chemistry}} and {{chemistry}}? — Vildricianus 19:28, 14 June 2006 (UTC)[reply]

Tricky templates Part II edit

This is the list of templates "in use" when I use one of the new verb templates (in the form of {{en-verb|itemiz|es}}). Page tested is User:Vildricianus/PageX/4, which has only said template.

es
itemiz
valid
Template:,
Template:ARchar
Template:Arabic font size
Template:Arabic fonts
Template:bottom
Template:en-infl-verb/getPast
Template:en-infl-verb/getPastP
Template:en-infl-verb/getPres3rdSg
Template:en-infl-verb/getPresP
Template:en-infl-verb/isValidPageName
Template:en-verb
Template:gender period
Template:isValidPageName
Template:m
Template:mid
Template:n
Template:see
Template:seeCites
Template:serial and
Template:top

This is not to criticize the work that has be done, hardly so. On the contrary, I'd like to find out how we can preserve it by making the above list shrink. "Shrink", that is, both physically and visually.

Physically: how the heck do I get ARchar, m, mid, seeCites and friends used by {{en-verb}}?
Already found: because of es. Why is es said to be a template here? It's a parameter. Is there any way they could be excluded from that list?
Visually: could there be any way that the "templates in use on this page" is trimmed, displaying only the templates primarily used on the page, so not the secondary ones like /getPast etc.? Should I attempt this at bugzilla? — Vildricianus 21:39, 17 June 2006 (UTC)[reply]

Yes, that's an annoyingly long list of templates. The "es" and "itemiz" seem stange. It looks like they could be the result of some bug in {{en-verb}}. I will look into that. As for the others, I split up the functionality of {{en-verb}} into subroutines because I think that makes the template itself easier to read, but if the editor community desires, I could flatten the subroutines into the top level template. Rod (A. Smith) 22:40, 17 June 2006 (UTC)[reply]

What would be a real solution is if there were a software-based enhancement for it. If it's not going to happen (likely), I don't think it's really necessary to re-include the subtemplates into the main one. It's up to you. — Vildricianus 23:00, 17 June 2006 (UTC)[reply]

The easiest way to do this would be to give templates subpages, and simply not list the subpages if the template itself is listed. Davilla 12:07, 18 June 2006 (UTC)[reply]

That's the reaction I've gotten as well, which is unfortunate because subroutined do make the code easier to read. A lot of your calls are only made once, so they would be very easy to roll in. What does isValidPageName do? I don't see any comments in the code. Davilla 12:07, 18 June 2006 (UTC)[reply]

I really like the suggestion that the MediaWiki software not list sub-templates.

I should have commented "isValidPageName". FYI, it determines whether its argument is a valid page name. It fills a gap missing from our lacking StringFunctions. The inflection templates use "isValidPageName" (or they would use "StringFunctions" if they were available) to determine whether an argument includes markup. They then wikilink valid page names and do not wikilink others. So, "{{en-verb|'''[[has]] '''or, archaic,''' [[hath]]'''|having|had}}" automatically links "having" and "had" but leaves the "'''[[has]] '''or, archaic,''' [[hath]]'''" text unadorned. Rod (A. Smith) 17:41, 18 June 2006 (UTC)[reply]

I recommend filing a feature request aksing for different CSS classes around directly included template names and indirectly included template names. That way we can for example globally hide the indirect ones and people who want them all can have them all and other wikis which don't want anything changed won't see any changes. Somebody could even trivially come up with a JS extension that provides a button to hide/show the various levels. — Hippietrail 02:38, 20 June 2006 (UTC)[reply]

For this situation I think there's probably a more direct solution. The cattag mess will also be completely revamped when string functions are available to extract a tag from its parenthesis. Davilla 04:05, 20 June 2006 (UTC)[reply]

Etymology templates edit

From BP edit

I see ever fewer instances of these. How come? Does everybody endorse them or are they not really accepted? Note: I'm only talking about the "derivations" templates, like {{LL.}} and such. I think they're very useful for etymologies. — Vildricianus 12:27, 13 June 2006 (UTC)[reply]

Personally I hate them. The main reason is that I don't like wikified language names, especially in Etymology sections. It makes everything looks very messy and cluttered and basically hard to scan; when only the etymons are wikified, they stand out much better. On the other hand the good thing about the templates is that they add the Category:Words of x Language Origin, but I just tend to add that bit by hand. Widsith 15:00, 13 June 2006 (UTC)[reply]

Yes, actually, that's what I meant. The languages shouldn't be wikified, it's the categories which are their main advantage. — Vildricianus 15:03, 13 June 2006 (UTC)[reply]

What we really need is a standardized format for etymologies. Once it's standardized it can be personalized. Personally I really dislike language-name-templates because it requires memorozing a long list of abbreviations to use them. But a standardized format would be best if all language names were in one certain style, all foreign forms were in a second certain style, and all glosses of foreign forms into English were in a third certain style. — Hippietrail 18:40, 13 June 2006 (UTC)[reply]

I don't understand. Why use the Webster abbreviation instead of the language code, maybe followed by a dot or something? Which one is easier to remember? Or just use the full language name, or some combination (using redirects for the templates). ∂ανίΠα 19:04, 13 June 2006 (UTC)[reply]

Is there a code for Late Latin? — Vildricianus 19:15, 13 June 2006 (UTC)[reply]

Hmm... strange shortcoming. Adding a dot suffix for late, middle, etc. doesn't seem like it would simplify anything. Oh well. 59.112.50.163 21:55, 15 June 2006 (UTC)[reply]

I would prefer to use the full names of the languages as template names. Each template can include some CSS that can allow setting to bold or italics or whatever depending on where it is used and can be personalized. For languages with multiple names, those can all redirect to one template per language. This way article editors can use whichever language name or spelling they are used to, and everybody will see the same thing. It would even be easy for people to choose say Burmese or Myanmar, Byelorussian or Belarusan for each language. — Hippietrail 20:15, 13 June 2006 (UTC)[reply]

Good idea. Sounds very flexible. Sounds also quite easy to apply to existing etymology sections (just enclosing in brackets). — Vildricianus 20:30, 13 June 2006 (UTC)[reply]

Having them in place, means that Webster imports are not stymied. If such strong objections exist, then the templates use can be "subst:"'ed. But the notion of prohibiting them (as some are implying) is a very non-wiki philosophy. On the other hand, having them in place as templates means they still can be "corrected" without too much fuss. Every few months or so, the decision seems to waffle between linking internally vs. linking to Wikipedia; then back again, some time later. Having them as templates lets those changes occur without too much database interaction. Whereas if they were all subst'ed, a bot would have to run each time the wind changed. Template redirects seem reasonable at first glance. --Connel MacKenzie T C 16:13, 14 June 2006 (UTC)[reply]

Why should they be subst:'ed? — Vildricianus 16:45, 14 June 2006 (UTC)[reply]

They shouldn't be; I was suggesting that as a kind of potential compromise. --Connel MacKenzie T C 23:19, 15 June 2006 (UTC)[reply]

I guess they need some grease pitting and brainstorming after today's business (mainly inflection templates) is settled. Topic deferred. — Vildricianus 18:59, 16 June 2006 (UTC)[reply]

Grease pitting edit

An idea of mine: how about creating 1 template which takes a parameter. Something like {{etym|par}}, or perhaps even shorter. A finite set of parameter checking could then determine which category to add. ISO codes as parameters would be OK for me, but do Late Latin, Middle English, Old French etc. have codes? I'd prefer the current abbreviations which are easy and memorable, to be used as parameters. — Vildricianus 20:19, 19 June 2006 (UTC)[reply]

Rod just made {{etymon}}. Combining the above and this one creates a template taking two parameters: 1/ language, 2/ etymon. As such it could become quite useful. Any ideas? — Vildricianus 20:19, 22 June 2006 (UTC)[reply]

Template:etymon edit

(or, "More templates than you can shake a stick at")

As discussed at User talk:Rodasmith#Infl, we have not yet standardized the style for etymons. Candidate styles include the use of quote marks, italics, emboldening, wikilinking, and combinations thereof. Recent conversations have highlighted some editors' distaste for and some legibility problems with using italics in general. Fully aware that the current template palette for Wiktionary's "perfect entry" includes more templates than you can shake a stick at, I introduce {{etymon}}.

Before proposing adoption of {{etymon}} on WT:BP, I would like feedback here to ensure that the proposal is appropriately flexible and technologically consistent with Wiktionary's collective vision.

Similar to {{en-noun}} and {{plural of}}, {{etymon}} should address the following needs:

Wiktionary should display etymons consistently.
The community can choose and change the default style of rendering all etymons.
Readers can choose their preferred display style for etymons.

Because it may be desirable to display non-Latin script etymons with a different style from Latin script etymons, I seek feedback on whether we should use any of the following language-specific or script-specific extensions of {{etymon}}:

Add the ISO language code as a required first parameter, e.g. on "artel":
From {{etymon|ru|артель}}.
Add the ISO language code as an optional second parameter, e.g. on "artel":
From {{etymon|артель|ru}}.
Add the ISO code for the script as an optional parameter, e.g. on "artel":
{{etymon|артель|cyrl}}

Option 1 above is a direct implementation of the "From BP" proposal above, but is perhaps problematic for etymons whose languages lack ISO language codes. Options 2 and 3 allow the language-neutral/script-neutral uses of the template to show a default style.

Options 1 and 2 allow the template to show the name of the language, to categorize words according to their language derivations, and to wikilink to the language section appropriate for the etymon, e.g. "{{etymon|артель|ru}}" can wikilink to [[артель#Russian|артель]].

From Russian "артель".

Options 1 and 2 also allow us to specify a language code of "-" to indicate that the etymon is hypothetical and should not be linked, e.g. on "word":

From Proto-Germanic {{etymon|*wurða-|-}}.

From Proto-Germanic "*wurða-".

Your feedback is much appreciated. Rod (A. Smith) 23:46, 22 June 2006 (UTC)[reply]

Very neat, but needs some more functionality. The language parameter should be required, so we'll need templates for Late Latin etc. The template should also include Category:Xyz derivations, but this won't with the language template structure. Perhaps you'll need to incorporate a parameter-checking infrastructure, adding categories depending on the parameter. — Vildricianus 14:11, 23 June 2006 (UTC)[reply]

OK. Uses of the template read best if the language code is the first parameter anyway. (I.e. "From {{etymon|ru|артель}}." and "From {{etymon|proto-de|*wurða-}}." seen to read naturally.) Is there an extension of ISO language codes that includes abbreviations for Middle English, Late Latin, Proto-Germanic, and Proto-Indo-European? Does Wiktionary accept entries, language headers, and "Category:Xyz derivations" for each? Rod (A. Smith) 16:28, 23 June 2006 (UTC)[reply]

From Wiktionary talk:Index to templates/languages edit

The following text from Wiktionary:Index to templates/languages does not appear to be true:

These link to the extended Wikipedia articles, so that finer points of congjugation, etc. can be referenced without too much hastle.

Were links to Wikipedia entries an old convention or am I missing something? Rod (A. Smith) 17:14, 23 June 2006 (UTC)[reply]

Looks like a bad place to post things. I usually spot these edits, but in general these will go unnoticed.

On topic: these templates are bad. They're the old convention to use in =Translations= sections instead of the plain language names. Recently we got rid of them through downright subst'ing everything. They're still being kept for the reason that people will post translations using them, in which case have to be tracked and subst'ed again.

We could still use them as our own method for getting {{#language:}} but with local names. Where they link to was a matter of where we linked to in translations sections. — Vildricianus 17:27, 23 June 2006 (UTC)[reply]

Thanks for the reply. (I will move this to BP or GP if you think the increased visibility would be helpful.) Per your GP post, I plan to modify {{etymon}} to determine whether an etymon is a valid Wiktionary link target. It already expands the language code argument using these templates, but an additional option is to determine whether the etymon is a valid link target based on whether its language argument is the name of one of these templates.

Anyway, I wanted a complete list of these templates for reference. I thought categorizing them as something like "Category:Language names" might help. It seems I don't need to do so, though, since this template listing page appears to be complete (despite its confusing note about Wikipedia links). Rod (A. Smith) 18:40, 23 June 2006 (UTC)[reply]

form of edit

{{plural of}} and {{alternative spelling of}} aren't giving me the default bolding, although {{form of}} with the same code is. What's going on? ∂ανίΠα 19:14, 17 June 2006 (UTC)[reply]

Because "form of" has hard-coded bolding, which it shouldn't. — Vildricianus 19:17, 17 June 2006 (UTC)[reply]

Ah, thanks for fixing it. So bold isn't the default though? ∂ανίΠα 19:33, 17 June 2006 (UTC)[reply]

No. Should it? Paul raised the issue earlier today as well. Perhaps there should be some BP discussion on it (again!!), but don't count on me for starting it :-). — Vildricianus 19:42, 17 June 2006 (UTC)[reply]

What is the default supposed to be? Looks like it is plain text: "Plural of foot". Now, my objection to this is twofold:

The grammatical term should be wikified, IMO, as we often do for "comparative". Of course, almost everyone knows what a plural is, but many people don't know what a comparative is. Although someone could guess what a comparative is by looking at the definition, such as "thicker: comparative of thick", it is possible that someone with very little knowledge of English grammar might guess wrongly: it's just (note, just) possible that someone reading "flatter: comparative of flat" might guess that this means the verb "to flatter" and that "better: comparative of good" means someone who bets, despite the part of speech headers. Unlikely, but possible. So I think that "comparative", etc, should be wikified in these templates to aid the reader.
I'm not too bothered whether or not we do that, but I think it would be helpful to some readers. However, one thing that I do feel strongly that we must do, especially if we decide to wikify the grammatical term, is to show that the term in the cross-referred is being referred to and not being used.

Here's an example of the second issue (a slightly contrived one, but it illustrates my point very well):

"older: comparative of old"

As there is no typographical distinction between "comparative" and "old", this reads in the same way as "comparative of old", as it would appear without the wikification (for example, in a print dictionary). Now, written in that way, that means "a former comparative; a comparative used in olden times", which is not at all the intended meaning.

The adjective being compared must therefore be typeset in some way that indicates it means we are referring to it rather than using it. This can be done with quotation marks or, better still, because we have it available, with typography. This could be emboldening (compare Chambers), italicisation or small capitals (compare the OED and some US dictionaries). For myself, I think emboldening is ideal as this suggests a headword, since headwords appear in bold in Wiktionary.

So my personal choice would be for bold text to be the default, as I think this works best. It is however my personal choice, so I'm not going to force it on others.

So the formats can include "comparative of old", "comparative of old", with variations in capitalisation, etc, but what I feel we must not allow as the default or even as an option is unadorned text, for the reasons I give above. No print dictionary would give "comparative of old", "plural of foot", etc, and neither should we. — Paul G 07:01, 18 June 2006 (UTC)[reply]

No, a print dictionary would certainly use ‘Comparative of old.’ That's because wikification is a typographic distinction, and the fewer used, the better. However, you're right that if we wikify the grammatical term, then the referrant needs an extra level of distinction (I agree with you that bold is the best choice). But I personally think it's cleaner and neater without wikifying the ‘comparative’ bit. Widsith 06:42, 19 June 2006 (UTC)[reply]

If I am not mistaken, the practice of using links as a form of "highlighting" words has been discouraged in HTML since its early days and is furthermore specifically discouraged on Wikis. — Hippietrail 02:56, 20 June 2006 (UTC)[reply]

Sounds like sound policy to me, considering how easily things are linked (e.g. future wikification) or unlinked (e.g. in printing). Davilla 04:10, 20 June 2006 (UTC)[reply]

Compare [4]. With the new possibilities, there's no need to repeat that, fortunately. Bold is a reasonable idea, which I've stated before. Not allowing unadorned text doesn't sound very wiki, and is technically not possible (but who cares anyway what people prefer through their css files?). — Vildricianus 14:12, 18 June 2006 (UTC)[reply]

Do we need to have another vote for default bolding of sub-class mention? The primary objections were for non-Latin scripts. Is there any way to determine the script and only bold the Latin ones? Davilla 04:10, 20 June 2006 (UTC)[reply]

That last one sounds like a bad idea to me. But if it's the only possible solution, fine then. For that part, either italics or bold is bad in non-Latin. Underlined doesn't work either of course. Strike-through perhaps? :-) — Vildricianus 10:57, 20 June 2006 (UTC)[reply]

Why is there a need to do anything with non-Latin scripts? They stand out enough as it is on their own. Davilla 16:12, 20 June 2006 (UTC)[reply]

What? That I don't get at all. — Vildricianus 16:18, 20 June 2006 (UTC)[reply]

The use/mention distinction that Paul raised above. Introducing inconsistency merely because something is not in the set [a-z,A-Z] is a bad idea. When "Printer friendly link" is clicked, we do need to still distinguish between use and mention. Wikification of the term is ignored (entirely) on the "Printer friendly link." I'd prefer double quotes (ASCII, not Microsoft quotes) since we have syntactic problems with every other choice, except perhaps bold. I think the quotes convey the distinction much better than bolding them. --Connel MacKenzie T C 16:28, 20 June 2006 (UTC)[reply]

Who said anything about [a-z,A-Z]? There are many more Latin-based characters than that! The point that had been raised during the plural-of bot discussions was that Chinese, Japanese, Russian, Greek, Arabic, Hebrew, etc. did not consistently conform to being bolded or italicized, but that it didn't matter because the use-mention distinction was pretty clear in these cases. Now if you want to put quotations around Chinese characters because you're not sure where the distinction between use and mention might occur, then you can go ahead and find a CSS solution for that. My only point is to narrow the argument down to those scripts for which all of the proposed solutions could actually apply. Davilla 08:14, 21 June 2006 (UTC)[reply]

Sorry to say, but this sounds really like an ugly reasoning. The fact that something is in a non-Latin script doesn't mean we shouldn't distinguish use/mention anymore. I don't bother too much about the whole u/m thing, but one thing I'd like is to keep things consistent across languages. — Vildricianus 12:43, 21 June 2006 (UTC)[reply]

I disagree completely. The fact that a mentioned word in an English sentence is in a non-Latin script does mean we don't need to mark it explicitly as mentioned. The following examples illustrate:

Mentioning a Latin-script word:
- Blend of spice and ham.
- Short form of foxterrier.
Using a Latin-script word:
- Blend of spice and ham.
- Short form of foxterrier.
Mentioning a non-Latin-script word:
- Blend of 辣 and 火腿.
- Short form of терьер.

Note that there is no need to italicize (or otherwise to make distinct) non-Latin-script words. Doing so actually obscures the mention because italics have undesirable affects on non-Latin fonts:

Undesirable effects of italicizing non-Latin fonts:
- Blend of 辣 and 火腿.
- Short form of терьер.

The Chinese words are practically illegible and the Russian word looks completely different from what was intended. Use-mention distinction in English Wiktionary need only apply to Latin fonts and, if we use italics (the standard wiki way of mentioning words) we should do so only for Latin script words. Rod (A. Smith) 16:08, 21 June 2006 (UTC)[reply]

How about this:

Accusative of HTML-код. Latin or Cyrillic?
Genitive of paca. Latin or Cyrillic?

— Vildricianus 17:06, 21 June 2006 (UTC)[reply]

Good points. I hadn't even considered mentioning text of mixed scripts or the fact that Latin script text can appear to be Cyrillic, so I retract my "I disagree completely" statement. :-) Those problems combined with the illegibility of italic hanzi/kanji make italicization problematic. Should we always use quote marks? Rod (A. Smith) 19:25, 21 June 2006 (UTC)[reply]

That seems (to me) to be the only viable option. --Connel MacKenzie T C 19:32, 21 June 2006 (UTC)[reply]

No, italics can't go for said reasons. Bold is slightly better but still bad. Underlining is a non-starter. Small caps? Mmm, same problems. Well I can't think of anything else than quotation marks then, indeed. I certainly don't like them but it seems there's no other option. — Vildricianus 20:27, 21 June 2006 (UTC)[reply]

Present participle of edit

Connel brings up a good point below regarding {{present participle of}}. Perhaps it's time to define our long-range scheme for English and non-English "form of" templates. [The following is copied from User talk:Rodasmith:]

Is {{present participle of}} as intended? Not all p.p. are gerunds (although they can be, not all are.) Is there a separate template for normal p.p. without the gerund thing? --Connel MacKenzie T C 18:25, 20 June 2006 (UTC)[reply]

Hmm. I guess I didn't thoroughly think that template through. After creating the "form of" templates, I realized that there actually needs to be a distinction between the "form of" templates for English and for other languages, at least in the case of verbs. The problem you cite is but one of the issues. The other is that with English verbs, we want "to" to appear in the output, but obviously not with verbs of foreign languages. I'd be quite happy to see them changed, but I haven't thought of the best convention for the template names. Any thoughts? A suggestion to resolve the "pres part/gerund" issue is to have a "ing form of" (or some other short-named) template for "present participle and gerund of to..." since that's by far the most common in English. Then "present participle of" could be used for the exceptions where the verb has no gerund. That doesn't address the English ("to") vs. non-English issue, though. I welcome any improvements. Rod (A. Smith) 18:33, 20 June 2006 (UTC)[reply]

"to" should indeed remain part of the template, as we may want to remove and re-add it from time to time :-)
Templates for other languages are necessary, but don't need to affect the English ones. We'll need to use ISO codes then, e.g. {{fr-present participle of}} or whatever.
I'd recommend keeping all names obvious, as they are now (so nothing like {{pp}} or the like).
I'd also recommend to leave out the "verbal noun" thing or anything else, since these forms aren't likely to appear under a =Verb= heading. Or are they?

Cheers! (Feel free to copy this discussion over on the GP, it'll need more ideas there and I think there's already a thread on it). — Vildricianus 18:39, 20 June 2006 (UTC)[reply]

Extra note: ideally, we'd have an exhaustive list of "form of"-templates and corresponding definitions, which we should stick to, in order to remain consistent across all entries. — Vildricianus 18:53, 20 June 2006 (UTC)[reply]

This is the ugliest wording and it has to come to this basic point to get rid of it. In case any of you forgot, English verbs are defined from the base form, not the infinitive. I actually taught from a storybook last year in which all of the verbs were listed in the glossary under "to", can you imagine!? So if you wanted to look up "reach", you'd have to know it was a verb under the 't' section because you wouldn't find it under 'r'. There were other problems with the book by the way. And there are some problems with Wiktionary in this respect. Under reach I find "to reach", "reaches", "reaching", and "reached". Nowhere is the plural and first/second-person singular "reach" listed.

Back to the templates. The solution to this problem is very simple. Just get rid of "to" and the templates can be shared across languages. {{present participle of|word}} should be used whenever the page name is a present participle of word, period. Davilla 08:02, 21 June 2006 (UTC)[reply]

Is anyone here familiar with the "&uselang=" thing? I'm pretty sure that \Mike used to use it for MediaWiki:Nogomatch/sv by setting the default language in his user preferences? (BTW, that should move to MediaWiki:Noexactmatch/sv right?)

Would the better long-term plan be to have {{en-noun/sv}}, {{en-noun/zh}} etc.? Whenever the language-specific sub-page doesn't exist, the MW software is supposed to just give the English version of the page, right?

I won't suggest {{en-noun/en-uk}} for adding spurious "u"s, just yet. --Connel MacKenzie T C 19:43, 21 June 2006 (UTC)[reply]

I don't get it. Please clarify where you would expect to apply "en-noun/sv" and "en-noun/zh". Rod (A. Smith) 20:49, 21 June 2006 (UTC)[reply]

Main Page edit

The last time I (painfully) reduced my screen size to 800x600 and viewed it, it looked good, but right now it is atrocious. The imbalance is lessened on larger, more normal display sizes, but I don't currently have a 1024x768 display. Is it OK at least in that mode? Why don't fr.wiktionary.org and even en.wikipedia.org have the same imbalance issues? --Connel MacKenzie T C 15:46, 6 June 2006 (UTC) P.S., http://commons.wikimedia.org/ seems to have the same issue, but their imbalance manifests towards the bottom of the page, instead of the topish-middle. --Connel MacKenzie T C 15:50, 6 June 2006 (UTC)[reply]

Usually that sort of thing is the product of CSS values which are px or other fixed scales rather than percentages. We need to strive to use only % values when we are making new sections, even though px values are oftentimes much easier. - TheDaveRoss 16:06, 6 June 2006 (UTC)[reply]

I don't know when or where, but our main page has started looking shitty again. The second section, in particular, at one point was supposed to be equally balanced, left-right, 50%, 50%. It is almost understandable that that went away.

No, actually, it is not understandable at all. WTF. If you've got imbalanaced sections, add them as separate sections, width=100%, not screwing everything else up. The two 'most-similar looking blocks are "WOTD" and "About Wiktionary", so they should be side-by-side 50%/50%. The rest of the junk needs some shuffling around...e.g. "Browse Wiktionary" = 50% paired with "Selected entries" + "Things to do" = 50% ? Has anyone played with this extensively?

I guess the biggest question is, how did it change, without getting tested in 800x600 mode?

--Connel MacKenzie T C 15:57, 6 June 2006 (UTC)[reply]

The bug there is that everything changes depending on WOTD size. One day it's as thin as the Browse Wiktionary box, the other day it's as big as the Selected Entries thing. And ever since your addition of the audio link the WOTD width has been unbalanced. I don't feel like doing it, since I'm not entirely fond of the Main Page syntax. I could redesign it, but I doubt that'd be any better. You should ask Dangherous. — Vildricianus 18:25, 6 June 2006 (UTC)[reply]

Interesting. I don't know how I could have changed the size when I didn't change the number of lines. But then, if I knew, I wouldn't be asking. :-) Still, I don't see how my change could have had that effect. --Connel MacKenzie T C 19:43, 6 June 2006 (UTC)[reply]

The fact that WOTD is wider makes that the Selected Entries are longer. At least on 800x600, that is. — Vildricianus 19:51, 6 June 2006 (UTC)[reply]

Testing some new tricks at User:Vildricianus/PageX/MP. Refresh cache first. — Vildricianus 11:37, 7 June 2006 (UTC) Main Page code is bad. WOTD implementation is not that good either. Spent too much time on it today, and I've got enough of it. — Vildricianus 13:22, 7 June 2006 (UTC)[reply]

Trying anew with a different code at User:Vildricianus/Main page. Is this what you mean Connel? — Vildricianus 13:47, 7 June 2006 (UTC)[reply]

Wow, yes. That's what I was saying. --Connel MacKenzie T C 14:23, 7 June 2006 (UTC)[reply]

Ready. User:Vildricianus/Main page. The one thing still to be worked out is the audio thing. — Vildricianus 19:52, 7 June 2006 (UTC)[reply]

Could perhaps go live. WOTD audio isn't going to be solved right now. — Vildricianus 11:30, 8 June 2006 (UTC)[reply]

I like it a lot. Of course, that is just one person's opinion. Anybody else? Horrid? Beautiful? Orchid or Onion? --Connel MacKenzie T C 05:16, 9 June 2006 (UTC)[reply]

The only problem with the audio was the one day, where Dvorty refused to do a pronunciation in a language she doesn't speak. Who is populating the WOTDs these days, anyhow? I think having the audio, right there, for all to hear, is really a very, very good thing. So we should be able to shuffle things around. Any words that don't have audio at their designated time can be sent to the end of the line. Or is it not so simple? --Connel MacKenzie T C 05:16, 9 June 2006 (UTC)[reply]

Put it in place now. Perhaps no one will notice. Note that whichever box we put next to WOTD, it will never fit well. The thing to do now is find some more links to add to Browse Wiktionary. It should become more of a mini-index to Wiktionary. — Vildricianus 19:14, 9 June 2006 (UTC)[reply]

Archiving this page? edit

Gah! Already 80 kb! —Vildricianus 10:33, 30 May 2006 (U T C)

Looks like quite soon, this page will need to get archived just as much as the Beer parlour. We can use the opportunity to experiment or brainstorm a bit about how to do it better, i.e. topical instead of chronological archival? A kind of categorization of discussions on separate archive pages? For instance, one archive for template discussions, one for CSS, one for general development etc. —Vildricianus 13:18, 29 May 2006 (U T C)

Gods, yes! I absented for a day, and came back to several chapters of comments on this page. I am stunned at how popular this conversation area is. I think it indicates that many lingering conceptual problems should have been dealt with sooner, that were never addressed on WT:BP. Also, the recent addition of Vild, Scs, Partick, and Rod, seemed to have given Wiktionary the needed critical-mass for technical improvements. Hard to say which is more relevant.

That said, branching Grease Pit from Beer Parlour was a valuable branch: perhaps further sub-division would be the way to go? There are philosophical improvements, and technical improvements...but perhaps they are, as HT suggests (by creation of this page,) far too intermingled to coherently separate?

I wonder...could we have "live" archive areas, rather than end-of-conversation-never-to-be-mentioned-again archives?

--Connel MacKenzie T C 18:24, 29 May 2006 (UTC)[reply]

Please elaborate on that as I don't have a clue what that would mean.

Regarding "new rooms", I was thinking the same, after seeing the GP's popularity. Perhaps we should make the same move for what HT mentioned somewhere on RFD: a mid-area RF* page where entries can be discussed for reasons other than deletion, verification or cleanup? —Vildricianus 18:36, 29 May 2006 (U T C)

I was being cagey only to not insist on my names for the concepts, but rather to encouarge thoughts on what appropriate subdivision might be named. I was under the impression that the multi-word-entry controversy was not a particularly "technical" discussion. At least, not technical in regard to how the wiki software deals with the issue. Perhaps something like "Grease pit (linguistics)" and "Grease pit (technical)"? Then again, maybe it would be better if the multi-word discussion were moved to Wiktionary:Language considerations/English? Or is it truly better off staying right here?

I think the Tea room is the best place for the "in-between" requests. With RFD/RFV/RFT/RFC, I think we have all the general possibilities covered, these days. --Connel MacKenzie T C 16:06, 31 May 2006 (UTC)[reply]

I thought about having a room for technical aspects of words, linguists, and lexicography, rather than computer programming. But in reality, how many people do we have who have any training or have read many books in these fields? I think the Tea room might be best re-labelled as a place to discuss words and language generally as well to answer question regarding the articles on particular words. This would slightly different to our current "if it covers more than one word put it in the Beer parlour" policy but we could rework that also by saing the Beer parlour is about policies, which headings to use, which orders to put them in etc rather than "further vs farther" or "is data plural or uncountable". How does that sound? — Hippietrail 17:25, 31 May 2006 (UTC)[reply]

Regarding the Tea room, that's how I and I think most other Wiktionarians already saw the concept, so it's probably best to spell that out more clearly. I'll take a look at how to reword Wiktionary:Tea room/header.

Also, I've dug up what Hippietrail said on RFD (it's here now):

Further, I think it might make a lot of sense to carry out the disputes on the articles' talk pages rather than here (or RFV) - these pages can be instead lists of links with perhaps a line of text indicating the current status of each dispute. Disputes which involve more than one page might be better off here than in the talk pages.

Anyone still wants to consider that? I don't know what is has to do with archiving this page, though. The Grease pit is more like a part of the Beer parlour – I expect most its atmosphere to be the same – whilst the Tea room is in 99% of the cases specific talk. If we would take full advantage of the Talk: namespace, we should carry out such specific conversations there, or at least, once they have been concluded, move discussions over there rather than to the Tea room archives. If we would follow that proposal, the Tea room could become more congruous to the BP and the GP as a discussion room for general Wiktionary talk, and be more what Connel described as the "Grease pit (linguistics)". —Vildricianus 18:20, 31 May 2006 (U T C)

Are you saying we should make all of the tea room be just template-header-style links to the appropriate talk pages, so it in effect, becomes just a page of links? I like that concept a lot, actually. It would allow for much greater retention time before archiving the TR. That, in turn, would give much greater continuity, especially for seemingly unrelated discussions. --Connel MacKenzie T C 19:42, 31 May 2006 (UTC)[reply]

Something like that, yes. Actually, what I was saying is that we should make a new page as a "link depository", while keeping the Tea room strictly for broader discussions that don't belong on article talk pages. Or the other way round; don't know what would be the least confusing. —Vildricianus 20:16, 31 May 2006 (U T C)

Note: the Grease pit is now one week old... I guess we'll need its first archiving in about ten days. — Vildricianus 20:00, 2 June 2006 (UTC)[reply]

Another idea: how about moving large discussions (more than three screens) to subpages when they are archived, and linking to it from a page very much alike Connel's Beer parlour archive index. Three lists perhaps: alphabetical, chronological and topical. We should definitely maintain such list if we just archive this page the "old way" as well. — Vildricianus 12:08, 5 June 2006 (UTC)[reply]

I think it'd be wise to keep large chunks of related topics on subpages. For instance the entire italbrac and cattag stuff (part of which is also in the BP archives) should be grouped together. — Vildricianus 16:35, 8 June 2006 (UTC)[reply]

I like the subpage ideas. Lots. But how to do them is quite an issue. My offline tools are offline. I need to take two or three weeks to just sit down and learn Python for real - but I won't have that kind of time for the next couple years.

Maybe something like User:Ingoolomo's talk page auto-subpager javascript would help?

--Connel MacKenzie T C 06:11, 9 June 2006 (UTC)[reply]

I don't see the issues. When the archiving time of a topic has come, you put it on a subpage. Also, see #Active subtopics; it could happen well before archiving time. As a matter of fact, perhaps "archiving" is not really applicable here. Ideas will always return, and it's better if they do so within an existing context than started again from scratch. Well-developed and discussed ideas, like the ones I mentioned above and probably a few more, should be subpaged and linked to from the top of this page, probably in a big pink intrusive box to annoy you :-). — Vildricianus 20:03, 10 June 2006 (UTC)[reply]

Archiving - a fresh idea edit

I don't think the idea of sub-paging by month was known when the BP archiving method was set up. But for WT:GP, I'd like to make one subpage for each month. This page would then become a list of the last three months (or less) sub-page things. The subpages would have a level ONE heading. And the "Add new topic" link at the very top could use {{CURRENTMONTH}} (or whatever is in fashion these days) to get to the proper sub-page. This page would then be edited only about once a month, while each month's conversations would have that entire month's history. Unlike the BP, no protection of the archive pages would be needed, as each conversation an (with a clever back link here or there) remain active as long as needed.

Whaddaya think? Can I start messing around with this idea? --Connel MacKenzie T C 20:17, 10 June 2006 (UTC)[reply]

Clever. Please clarify that last bit. "Each conversation remains active as long as needed" ? Because the pages are shorter? Hmm. That means we have to remain on the lookout for posts to pages of months long gone by? — Vildricianus 22:05, 10 June 2006 (UTC)[reply]

Support. I also suggest we acknowledge and support the option mentioned above for any resulting month page to fork off indexed topic-specific pages when their length so justifies. Rod (A. Smith) 22:01, 10 June 2006 (UTC)[reply]

Ah, yes, that would make it work, I think. --Connel MacKenzie T C 07:30, 11 June 2006 (UTC)[reply]

Well, sounds fine, except for one major disadvantage which I had in mind for this page, namely that things will be archived by date instead of by topic. — Vildricianus 15:11, 16 June 2006 (UTC)[reply]

This page is no longer active. It is being kept for historical interest.

No discussion is needed to revive this page; simply remove the {{inactive}} tag and bring it up to date.

Active subtopics edit

(Since this is the Grease pit, perhaps we can dog food the suggestion of aggregating active conversations through inclusion. Rod (A. Smith) 23:34, 27 May 2006 (UTC))[reply]

Absolutely! --Connel MacKenzie T C 23:44, 27 May 2006 (UTC)[reply]

Hrm, editing this section, I see a minor problem already with doing that. (Edit it yourself, and see.) While I agree that we should be eating our own dogfood, it does also imply that someone will hover over this page and sub-subpage every section as sections are added. And/or that the sub-sub-paging will be somehow automated. Or both. --Connel MacKenzie T C 14:26, 28 May 2006 (UTC)[reply]

Mmm. We'll need double headers then. Or, 1 header, here, and just an edit link to the subpage. —Vildricianus 15:02, 28 May 2006 (U T C)

I think so, but I'm not sure of the "best" top level headers arrangement, nor how to get back here after editing a sub-page. --Connel MacKenzie T C 15:15, 28 May 2006 (UTC)[reply]

Getting back works with the "subpage of" link right below the pagetitle, right? —Vildricianus 15:19, 28 May 2006 (U T C)

Another point: no quick viewing of histories, which is darn useful. —Vildricianus 17:10, 28 May 2006 (U T C)

Actually, I see this last point as a major disadvantage. I'm used to following things by their history, which gives me a clear view on who said what and when, regardless of post disruption later on. This is completely impossible with the subpage system. As a matter of fact, I'm not sure whether it's still necessary. I'm highly enthusiastic about our new rooms and the new system; it looks like there's more breathing room now (pun?). For these reasons, most of what has been said on Wiktionary talk:Beer parlour#Revamp is now less necessary (actually, #2 is more or less what happened, and we can still extend it if we need yet another room in the future). With more frequent archiving, though, the BP should become more manageable. Therefore, let's consider subpages for discussion unnecessary for now. We can still use it for more extensive discussions if required, much like what happened with User talk:Connel MacKenzie/Normalization of articles. Anyone else agrees? —Vildricianus 19:13, 28 May 2006 (U T C)

That sounds quite reasonable. I'll subst in and delete the below subpage. Rod (A. Smith) 20:15, 28 May 2006 (UTC) (Done)[reply]

Thanks Rod. —Vildricianus 21:51, 28 May 2006 (U T C)

I would like us to give this a test run before withdrawing it. A big help towards "following things" would be to link to a diff to the point in the main page where the conversation broke off. That would mean you don't have to search through ancient pages. If it still doesn't work then we'll know by experience. It could also be that it doesn't work at first but we'll think of ways to improve it. That's not going to happen if we don't try it. If we try it and it really does fail then we can always get rid of it safe in the knowledge that we gave it our best shot. — Hippietrail 22:49, 29 May 2006 (UTC)[reply]
Absolutely, we should still consider it for larger discussions. The one below was, however, started in a subpage position, IIRC, which I think is confusing. Breaking of larger topics that were started here and leaving behind a link to the history page is indeed workable, I guess. —Vildricianus 10:23, 30 May 2006 (U T C)

I have another idea: if we list all transcluded subpages at the very top (below the roombox) of this page, that would assist quick history viewing. — Vildricianus 12:05, 5 June 2006 (UTC)[reply]

I've been working out this last one, and I think it's not a bad idea. The idea behind the Beer parlour is to move possible policy discussions and such to separate Wiktionary: pages to work them out further. We could do the same here, but instead of moving them to untraceable locations, we can use subpages of the GP. With this option, they can first remain transcluded, and after a while be left out of this page to make it shorter, and listed in a section or box at the top of this page. People should then make a habit of check those pages once in a while. With any new groundbreaking ideas, a new thread can be started here. I think for instance that this is already applicable to the #2-level dictionary, #Standardized customizable inflection templates and #Customization templates to provide both UK and US spellings topics here. Any thoughts? This probably goes hand in hand with the archiving proposals below. — Vildricianus 19:57, 10 June 2006 (UTC)[reply]

Implemented suggestions above above, as /Standardized personalizable inflection templates is destined for the archives. Let's see how it works. Rod (A. Smith) 03:32, 14 June 2006 (UTC)[reply]

Thanks, very good idea to list them in that section. I've reordered things a bit, so that there are two level 1 sections here. I've altered MediaWiki:Monobook.css so that on subpages, the link to the basepage is more visible. Instead of using "return to WT:GP" each time, this link will do the job.

I've also moved three more topics to subpages. I'd like to see how well this works but I think this is exactly what we need. — Vildricianus 13:05, 14 June 2006 (UTC)[reply]

Even more functionality. What do you guys think about the {{/template}} magic and the history, edit and watch links? — Vildricianus 18:38, 14 June 2006 (UTC)[reply]

Thanks, Vild. Well done. {{/template}} is very convenient, though perhaps confusingly named. Do you think "{{/subtopic}}" be any better? Rod (A. Smith) 19:49, 14 June 2006 (UTC)[reply]

~~Sure~~, I was first going to make a general one in the Template: namespace but figured out it would be simpler this way. Keep in mind to have a lowercase thing. (I'd say that all subtopics should start with uppercase.) — Vildricianus 20:55, 14 June 2006 (UTC)[reply]

No, actually not. The name "template" should be clearly distinguished from the others in Special:Allpages/Wiktionary:Grease pit, and "subtopic" is ambiguous in that context. — Vildricianus 15:19, 16 June 2006 (UTC)[reply]

Template:italbrac and Template:italbrac-colon edit

Earlier today I adapted the code from {{see}} to allow these to also take up to 9 parameters. They will be separated by simple commas but those have a CSS class of .ib-comma. I'm out of time now but haven't been able to test all the ways of displaying especially {{italbrac-colon}} - I think it may not be possible to hide a span but display a span within it - even with important. If anybody cares to look at it I'd appreciate it. — Hippietrail 03:13, 29 May 2006 (UTC)[reply]

Sorry, I threw out a lot of your work when I edited {italbrac} using {foreach}. I would have changed {see} as well except for the special end conditions. For now italbrac-colon is basically just italbrac plus a stylized colon, but if you need to change the style just substitute the call to italbrac with its contents. Davilla 13:16, 29 May 2006 (UTC)[reply]

Nice! The only problem is that you took away the possibility of having the colon inside the brackets. It's probably best though since only 5 articles put it inside.

Anyway I've realized I used a bad design for the CSS classes. I was being too clever. Instead of having both inner and outer brackets and hiding one and always having the italics, I should have: a) class for the brackets which can be set to italic or plain, b) a class for the content, c) a class for the commas, and d) a class for the colon.

I'm going to simplify it that way now and post the change on the Beer parlour. If anybody really wants the possibility of putting the colon insider, speak up and I can add it. By the way, the simplification will solve the buglet of cutting and pasting resulting in two sets of brackets. — Hippietrail 19:59, 29 May 2006 (UTC)[reply]

At any rate, to clarify: is {{italbrac}} intended for ad-hoc definition tags such as (slang)), (colloquial), (engineering), (southwestern U.S.), etc.? And if the answer is, "Yes, but if they're recognized categories you should use {{cattag}} instead", where's the definitive list of recognized tagging categories? And if the answer is "Yes, but when predefined tagging templates such as {{US}} and {{slang}} exist, you should use those instead", where's the definitive list of those? —scs 15:30, 8 June 2006 (UTC)[reply]

Don't understand your question completely, but italbrac is also used for {{transitive}} and friends, which don't need a category. — Vildricianus 16:33, 8 June 2006 (UTC)[reply]

Here's the question in a non-hypothetical nutshell: was my use of {{italbrac|colloquial}} on boneyard sense 1 appropriate? —scs 16:58, 8 June 2006 (UTC)[reply]

No. You should just use {{colloquial}}. — Vildricianus 17:26, 8 June 2006 (UTC)[reply]

Right. Next question: How am I (or for that matter any editor) supposed to know that? Is there a canonical list? —scs 18:54, 8 June 2006 (UTC)[reply]

You aren't. You're supposed to ask us, so that we can feel important. No, really, there is a category. There is also supposed to be a index to templates...

Aha! Got 'em. Thanks. —scs 19:48, 8 June 2006 (UTC)[reply]

...which is unfortunately horribly outdated and far from exhaustive. I quit working on my own list of templates as well, perhaps I'll restart that. So many things to do. — Vildricianus 19:13, 8 June 2006 (UTC)[reply]

Now that I'm thinking of it, that's not very useful actually. The usefulness of the category it adds entries to is a bit dubious. I haven't looked very thoroughly at the {{cattag}} code itself to see how and what, but could we abrogate all the label templates and use {{cattag|colloquial}} instead? With a list of things to check it could determine which tags it should add categories for as well (transitive, no; chemistry, yes etc.) — Vildricianus 17:26, 8 June 2006 (UTC)[reply]

In one sense, {{colloquial}} gives us the most flexibility, because it can be easily and individually redefined to do whatever we want. But on the other hand, {{cattag|colloquial}} could conceivably (as you suggest) check the actual value of the tag and make decisions accordingly, and that would make things easier at another level, because random editors wouldn't have to remember whether to use {{colloquial}} versus {{cattag|colloquial}}, or {{Capitol Hill district of Seattle really localized slang}} versus {{cattag|Capitol Hill district of Seattle really localized slang}}. (In other words, they wouldn't have to know the answer to my question above about the location of the canonical list; they could just use {{cattag|foo}} for any tag foo, without having to know whether {{foo}} or Category:foo exists. And no, I don't know of any words that need to be tagged as "Capitol Hill district of Seattle really localized slang".)

But if we did make {{cattag}} smart enough to only populate categories for certain of its argument tag values, we might want to think about renaming it from "cattag" to, perhaps, "defntag". —scs 18:54, 8 June 2006 (UTC)[reply]

Let Davilla work it out first. I'm sure he's doing something like this. Not really sure though. — Vildricianus 19:13, 8 June 2006 (UTC)[reply]

And it looks like the existing {{tag}} fills about the same need I was speculating "defntag" could be for. —scs 19:48, 8 June 2006 (UTC)[reply]

Wiktionary:Grease pit/Various topics/01

Wiktionary:Grease pit/Various topics/02