Wiktionary:Grease pit/2007/October

October 2007

Special:Wantedpages

Any idea why Special:Wantedpages says updates for it are disabled and it won't be updated? RJFJR 02:41, 1 October 2007 (UTC)

No idea. But this usually gets updated after each XML dump, in the meantime. Perhaps it should be linked from MediaWiki:Wantedpages-summary? --Connel MacKenzie 19:20, 6 October 2007 (UTC)

Colon missing

In WT:PREFS, I had the only reasonable option selected, of removing the parenthesis and adding a colon, before definition qualifiers. The colon has now disappeared. Where did it go? --Connel MacKenzie 18:14, 4 October 2007 (UTC)

I was not aware that anyone could ever choose a preference to add or remove colons after sense qualifiers. Please indicate a specific entry where you used to see a colon but now you do not and I will investigate. Rod (A. Smith) 19:10, 4 October 2007 (UTC)

Hmm. You said, "before definition qualifiers". Does that mean in the output of {{context}}? Rod (A. Smith) 19:17, 4 October 2007 (UTC)

{context} never had the colon with CSS used in {{italbrac-colon}} ({{sense}}). I don't know what Connel means. Robert Ullmann 14:51, 5 October 2007 (UTC)

Yes, I am talking about {{context}}. Yes, the option worked in the past, when it removed the silly parenthesis. Now it only removes the parenthesis, but no longer adds the colon. The example I just say a moment ago was weights with the context tag {{weightlifting}} which had the extra colon in the entry, from back in the days before WT:PREFs allowed the colon to be added correctly. --Connel MacKenzie 19:53, 5 October 2007 (UTC)

I don't see anything in the edit history Template:context that ever allowed a colon to follow the tags. Are you sure you aren't thinking about {{italbrac-colon}}, which is now {{sense}} and is supposed to be used in sense qualifiers outside of definitions? Rod (A. Smith) 20:07, 5 October 2007 (UTC)

By the way, I'm not suggesting that it would be wrong to allow readers to see {{context}} tags with a colon instead of parentheses. If you'd like, I figure out a way to allow readers to see a colon instead of parentheses, but I just don't see that it was ever done that way. Rod (A. Smith) 20:11, 5 October 2007 (UTC)

Yes, I am certain it was a thing that WT:PREFs accomplished for me, for context tags (long before {{context}} existed.) I know it worked at some point. I remember it being problematic, to not also add it to italbrac-colon qualifiers. I would appreciate that feature being restored. (I'm still baffled, as to why it isn't the default, but that is nothing new; it was very much an issue for some, in the past.) --Connel MacKenzie 19:11, 6 October 2007 (UTC)

OK. So that I can be sure I implement the desired feature, please confirm or correct my understanding of the requirements:

• All readers will see a colon after sense qualifiers (from {{sense}}, indicating the sense to which a usage note or a comma-separated list of -onyms applies).
• By default, readers will see parentheses around all qualifiers (from {{context}}, {{sense}}, {{a}}, {{qualifier}}) but will not see a colon after definition qualifiers (from {{context}}), nor after miscellaneous list item qualifiers (from {{qualifier}}, {{a}}, etc., used before a pronunciation, -onym, or similar list item).
• Readers who select an option in WT:PREFS will see a colon after and no parentheses around all qualifiers, including definition qualifiers (from {{context}}), sense qualifiers (from {{sense}}), and miscellaneous qualifiers (from {{qualifier}}, {{a}}, etc.).
• All readers will see parentheses around and no colon after miscellaneous italicized parenthesized text (from {{ib}}, {{italbrac}}, {{i}}, etc., used to add an inline parenthetical note that the editor feels should be italicized).

Is that accurate? Rod (A. Smith) 20:20, 6 October 2007 (UTC)

Almost; the 4th item you list above should add the parenthesis only conditionally, not for all readers. If a separate line in WT:PREFS is needed to implement it, so be it. The first three look OK. --Connel MacKenzie 14:52, 7 October 2007 (UTC)

If your suggestion is implemented, it will strip parentheses that I think should not be stripped: (unindenting)

# {{countable}} A domesticated [[species]] {{qualifier|Felis silvestris}}  of [[feline]] animal commonly kept as a house [[pet]].
# [[#English|cat]] {{qualifier|domestic feline; member of Felidae}}
# [[#English|winter]] {{qualifier|the season}}
*: {{enPR|''th''ə}}, {{IPAchar|/ðə/}}, {{X-SAMPA|/D@/}} {{qualifier|but see notes below}}
*Italian: {{t|it|il|m}}, {{t|it|lo|m}} {{i|depending on the initial sound of the word following: see [[lo#Italian|lo]] for details}}, {{t|it|la|f}}; {{t|it|i|m-p}}, {{t|it|gli|m-p}} {{i|depending on the initial sound of the word following: see [[gli]] for details}}, {{t|it|le|f-p}}
# [[#Noun|orange]] {{qualifier|the fruit}}

Default styles:

1. (countable) A domesticated species (Felis silvestris) of feline animal commonly kept as a house pet.
2. cat (domestic feline; member of Felidae)
3. winter (the season)

enPR: thə, /ðə/, Template:X-SAMPA (but see notes below)

• Italian: il m, lo m (depending on the initial sound of the word following: see lo for details), la f; i m pl, gli m pl (depending on the initial sound of the word following: see gli for details), le f pl

1. orange (the fruit)

View for parenthophobes under my above proposal:

1. countable: A domesticated species (Felis silvestris) of feline animal commonly kept as a house pet.
2. cat (domestic feline; member of Felidae)
3. winter (the season)

enPR: thə, /ðə/, Template:X-SAMPA (but see notes below)

• Italian: il m, lo m (depending on the initial sound of the word following: see lo for details), la f; i m pl, gli m pl (depending on the initial sound of the word following: see gli for details), le f pl

1. orange (the fruit)

View for parenthophobes if we include miscellaneous templates {{i}}, {{italbrac}}, and {{i}}:

1. countable: A domesticated species Felis silvestris of feline animal commonly kept as a house pet.
2. cat domestic feline; member of Felidae
3. winter the season

enPR: thə, /ðə/, Template:X-SAMPA but see notes below

• Italian: il m, lo m depending on the initial sound of the word following: see lo for details, la f; i m pl, gli m pl depending on the initial sound of the word following: see gli for details, le f pl

1. orange the fruit

I don't think that would be acceptable, but please correct me if I'm wrong. Rod (A. Smith) 18:09, 7 October 2007 (UTC)

That last option seems to match the format I prefer, the best. That is to say, similar to Webster's 1913, m-w.com, dictionary.com, Cambridge, FOLDOC, AHD, urbandict, etc. That's why I think it should be the site-wide default. Meh. As long as it works for me, (like your third example above) it would be nice. Parenthophobes?  :-) More like typography consistentists.   --Connel MacKenzie 14:54, 9 October 2007 (UTC)

That doesn't seem accurate. m-w.com uses parentheses for parenthetical notes [1]. Dictionary.com uses parentheses quite a bit [2] but in many situations, they use commas to show parenthetical pharases [3]. AHD uses parentheses [4]. FOLDOC uses parentheses without italics [5]. I would be very surprised for any dictionary to use only italics to distinguish any geniune parenthetical note. Doing so creates results like *“A domesticated species Felis silvestris of feline animal commonly kept as a house pet.” That's ungrammatical, so again, I hesitate to have any option strip such parentheses. I do understand the desire to remove parentheses from definition context tags and from other list item qualifiers, and my proposal above should accomplish that. Note, also, that the extended grammar information in translation tables should not even be there, but moved into the foreign word's main entry. If we do that and migrate list item qualifiers to {{a}}, {{context}}, {{sense}}, and {{qualifier}}, entries should appear the way you want them. Rod (A. Smith) 18:30, 9 October 2007 (UTC)

With the commas, it isn't a grammar error (but no, I'm not suggesting the preference, nor the template, add commas.) I'm certain I was looking at different examples than you for dictionary.com, AHD and FOLDOC. As I said, that is why I think it shuold be the site-wide default, but I'm not worried about that. As long as I can eliminate the parenthesis somehow, when I view it...  :-)   --Connel MacKenzie 03:26, 12 October 2007 (UTC)

OK. User:Hamaryns requested an option to remove parentheses from {{term}}, which I originally opposed for this same reason. With two editors requesting a similar option, I just went ahead with it. See “Hide the maximal amount of parentheses” in WT:PREFS or “Parentheses can be hidden aggressively” in WT:CUSTOM#Qualifiers and italicized parentheses. Rod (A. Smith) 08:17, 12 October 2007 (UTC)

Moving inappropriate pages out of categories

I’ve just taken a shot at moving the (four) inappropriately categorised pages out of Category:Hebrew prepositions; I managed with three of them, but can’t figure out how to remove the fourth: Template:he-prep-sing. Could someone with a better knowledge of templates take the fourth page out please? † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 11:44, 8 October 2007 (UTC)

The problem is that {{he-prep-sing}} transcludes {{he-prep-inflection}}, so just wrapping the category in <includeonly> tags won't do the job. We have a number of really skilled coders here who can probably come up with something more elegant, but I would personally be inclined to replace this line:

</div><includeonly>[[Category:Hebrew prepositions]]</includeonly><noinclude>

With this line:

</div>{{#ifeq:{{NAMESPACE}}|Template||[[Category:Hebrew prepositions]]}}<noinclude>

... thus shutting off the category iff the template is called from within Template: space. Actually, heretofore I don't think we've worried too much about the odd template turning up in a category. (I agree it's better to prevent this, though).-- Visviva 11:59, 8 October 2007 (UTC)

The NAMESPACE=Template conditional is what is used in {{context}}; it isn't a lot of overhead. I'd go ahead and use that. Robert Ullmann 13:09, 8 October 2007 (UTC)

I’ve done as you suggested; however, it has not worked. Any other ideas? † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 14:13, 8 October 2007 (UTC)

Yes, it has, you just had to wait for the job queue to catch up to the other template. Look now. Robert Ullmann 14:17, 8 October 2007 (UTC)

Oh; so it has. Thanks. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 23:46, 8 October 2007 (UTC)

As observed on BP, this would be generally useful so we can use examples on talk pages and documention pages, rather than

<includeonly>[[Category:...]]</includeonly>

use

{{#if:{{NAMESPACE}}||[[Category:...]]}}

which cats only in NS:0, it is very small additional overhead, but no SQL queries or anything like that. Could be used generally. Robert Ullmann 14:39, 9 October 2007 (UTC)

{{bible}} moved to {{books of the bible}}

The template {bible} ought to be a context template (redirect to/from {{biblical}}), likewise {Bible}.

"Books of the Bible" is the title of the float box and the category. Robert Ullmann 12:29, 9 October 2007 (UTC)

done, {bible} and {Bible} are now context templates (redirects to {biblical}) Robert Ullmann 14:32, 9 October 2007 (UTC)

Good catch; elegantly fixed. Erm, shouldn't that have been {{book of the Bible}} (singular)? --Connel MacKenzie 14:59, 9 October 2007 (UTC)

Wikipedia has an article about Acts Wikisource has the full text of various Bibles Wiktionary has a list of other books of the Bible Wiktionary has an Appendix listing other books of the Bible

There is a problem with the "Previous/Book/Next" part of the template (see Acts). Once you get some way into the Bible the books start to vary between versions. I would propose changing to the non-denominational template shown here. —Saltmarsh^Talk 06:12, 11 October 2007 (UTC)

Wouldn't an appendix link be better than a category link, for ordered lists? --Connel MacKenzie 07:24, 11 October 2007 (UTC)

Yes, a much better idea. —Saltmarsh^Talk 10:15, 11 October 2007 (UTC)

No, because this isn't an ordered list. That is, various sects of Christianity have different lists of included items, and list them in different orders. Some groups don't even use the same names for books; some books have multiple versions of the title; there are also multiple abbreviated forms. Consider Samuel, 1 Samuel, I Samuel, 1 Sam. Given this mess, a Category makes sense. --EncycloPetey 10:59, 11 October 2007 (UTC)

I think the Wikipedia table (that does show the different orders) is a better approach. The category guarantees that information (sequence) is lost. --Connel MacKenzie 11:02, 11 October 2007 (UTC)

So, will you be making such tables for each language on Wiktionary? A category permits parallel organization across all languages and can be added to one entry at a time. An Appendix page requires that all items be known from the outset. --EncycloPetey 13:53, 12 October 2007 (UTC)

Put the table in the category text? Or an appendix. Do steal it. (or link w:Books of the Bible directly from the box, which more wikilike ;-) Robert Ullmann 11:05, 11 October 2007 (UTC)

I am workinbg on this and will welcome suggestions. It should eventually have a table of comparisons plus separate lists for each "bible". —Saltmarsh^Talk 12:39, 11 October 2007 (UTC)

How will you accommodate all the various systems of abbreviation? --EncycloPetey 13:53, 12 October 2007 (UTC)

(1) Criticism of Appendix:Books_of_the_Bible will NOT be taken amiss! I have done more or less as much as I initially intended. (2) There was no objection to my objection (above) to the numbering of Books in the articles bearing their names - I propose to go through articles changing the old version (see Lamentations) to the new (see Acts) - I hope that this will be alright. —Saltmarsh^Talk 11:13, 13 October 2007 (UTC)

Your list of abbreviations wil need to expand to include other variant abbreviations. There is not a single agreed upon standard, though there is standard practice (mostly) when citing chapter and verse. Will we have similar versions of the Appendix in each language? Or will we be keeping the Category for that? That is, we will still need a topical category for entries of these words and abbreviations in other languages. --EncycloPetey 15:49, 13 October 2007 (UTC)

All I need are other sources. —Saltmarsh^Talk 05:14, 14 October 2007 (UTC)

new auto-patrol

I've written a new auto-patrol program in Python, to update/replace Connel's javascript and give use some more function. (It is fine to have both running at the same time, especially because at present any network interruption in Kenya/Iconnect will stop the patrolling; this not an infrequent event ;-)

It monitors RC, starting with unpatrolled edits going back 30 days/5000 edits, and then following current. (polling on an adaptive timer) It reads the whitelist from Connel's code directly, so that is still the "official" whitelist. (see WT:WL)

One new function (and the primary impetus for this), is when an entry is edited by a sysop/admin (i.e. someone who can mark edits patrolled), it automatically marks previous edits as patrolled going back 30 days. This means you can clean up a new entry without thinking about the patrol flags. (It will however miss edits if the page is moved.)

I've found this makes patrolling old edits much more interesting: go to the RC list and start at/near the bottom. Instead of clicking on (diff) and mark patrolled, look at the history from the last "trusted" edit to current, and then edit current, either to undo a problem or to make some improvements (most pages can use something; if all it needs is a bit of formatting, just add "{{rfc-auto}}" somewhere), and the autopatrol program will mark all of the edits.

It patrols as me; there was a discussion on IRC where the name "Rat Patrol" was suggested, and much liked. (see w:The Rat Patrol). It doesn't matter too much, the user name doesn't show up in RC or page histories.

Any ideas, etc. please comment. The WT:WL talk page is a good place to go into details. Robert Ullmann 12:17, 11 October 2007 (UTC)

Oh, one thought: patrolling is restricted to sysops, but this isn't usually a problem because someone with the level of trust and knowledge and participation required will be a good candidate for sysop anyway. But there are people who like doing anti-vandal things that aren't; and it would be possible to have a list of them; this code could then treat them as sysops for the function noted above: when they edit an entry, patrol all prior edits as well. (But I think they still can't see the patrol flags? Does hidepatrolled on RC work?) Robert Ullmann 12:24, 11 October 2007 (UTC)

Also, see WT:WL/transient Robert Ullmann 13:46, 11 October 2007 (UTC)

Sounds very good! Is it running already? H. (talk) 10:04, 12 October 2007 (UTC)

Yes, running now; has been fairly stable for the last 36 hours or so. Robert Ullmann 10:31, 12 October 2007 (UTC)

When we first had patrolling turned on, TheDaveRoss and I kept it almost completely patrolled for the first couple months. Time constraints and volume won out though. I think this improvement was precisely what was needed to restore "patrolling" as a viable, helpful method. Very well done, Robert!

Thank you ;-) It did seem to work well for a while, then got bogged down; it is easy to burn out when you have to go through an endless series of pages and tabes. See below ... Robert Ullmann 10:18, 16 October 2007 (UTC)

At some point in the past, a pit-in-the-sky discussion considered having another class of users - "trusted to clean up an entry" therefore similar to the way RatPatrol treats sysop edits. With the subpage concept, I think such a thing could be implemented without the hassle of creating a WMF userclass. Anyone have thoughts on how such a thing would work, (e.g. voting people in as "trusted" - not just "whitelisted", without being sysops.) Or should we continue with the lack of distinction, opting instead to run people through a sysop vote? Or should that concept be avoided, as we (perpetually) need more sysops? --Connel MacKenzie 19:59, 12 October 2007 (UTC)

Isn't it fair to let sysops who deal with patrolling decide which users to be trusted for this task or not, since they better know what it takes to be trusted in this sence and they are the ones who would patrol the edits unless they trusted other users to work along them? It seems voting would be too bureaucratic and non-flexible and also include too few users. ~ Dodde 16:12, 15 October 2007 (UTC)

The "voting" in question, when used for the whitelist, (see WT:WL) consists of nomination by one sysop, and approval by another. Very lightweight. Robert Ullmann 10:18, 16 October 2007 (UTC)

We perpetually need more sysops. Who would you nominate as trusted that you would not trust as a systop? The only case I could imagine is a good user turning down sysop. DAVilla 23:58, 16 October 2007 (UTC)

Well, the approval process for this would presumably be a lot faster than that for sysops; we might even just take as a given that any user with a few sysop "support" votes is trusted, even before waiting for the voting period to close. —Ruakh_TALK 00:33, 17 October 2007 (UTC)

Rat Patrol

This is a program written in Python, inspired by Connel's patrolled.js ... it does both automatic and manual patrolling (at the same time).

In automatic:

• reads RC, first going back as far as it can (5000/30 days/unpatrolled, 5000/7 days/patrolled), and then watching current
• if user in whitelist WT:WL, marks edit
• if user in transients WT:WL/T and active, marks edit
• if user in syops, mark all previous edits to title
• if page in whitelist of pages, marks edit
• if user modifying own talk page, user page, or user subpage, marks edit

it displays stats (number of sysops/transients/WL, edit, unpatrolled edits, marked so far). It also displays the title, user, edit summary, and a very simple diff for the oldest unpatrolled edit. You can then use the buttons:

• mark edit as patrolled
• skip
• open diffs in new Firefox tab
• open page in new Firefox tab preloads the diffs ahead of presenting them, and does the patrol marks after, so you can go clickety-clickety through a bunch without waiting for the net (;-). If you want to just run auto, just ignore the buttons. (It only preloads a few until you start marking things.)

Needs Python + Tkinter + pwikipediabot framework. (Tkinter comes with Python on Windoze, you may need a separate package get on Linux.) If you are interested, send me mail, and I'll send you ratpatrol.py; it still has a number of rough edges. (is only 4 days old ;-). It would be best if you don't send it to anyone else, this version is too new. I'll post it when it has more testing and I've fixed a few things I already know about. I've used it to mark 1200+ edits in the last 12 hours, both auto and manual. Robert Ullmann 10:18, 16 October 2007 (UTC)

Looks like Wiktionary:Whitelist/Pages and Wiktionary:Whitelist/Users should probably be protected. Mike Dillon 02:12, 17 October 2007 (UTC)

Werdna created those a while ago, they are not the current versions. The code reads the current list from Connel's .js file, which is protected. Yes, if we put the list on pages like that, we'll protect them ;-) Robert Ullmann 10:04, 17 October 2007 (UTC)

enhanced patrolling

I have enhanced patrolling turned on, with the ‘expert mode’. This is fine, but one doesn’t see whether one has clicked a mark? link already. Isn’t there a way to make them change color if they are clicked (i.e. instead of the pop-up box)? H. (talk) 10:06, 12 October 2007 (UTC)

That is a good suggestion; I normally refresh frequently enough that it isn't an issue (after marking a series of four or five) but it really ought to change color or something. I'll see what I can do...maybe replace (mark) with (marked) when clicked. --Connel MacKenzie 19:50, 12 October 2007 (UTC)

Template modification

Could someone modify Template:policy so that it will allow for a specification of sorting in Category:Wiktionary policies? Right now, the template places all Wiktionary policies alphabetically under "W", which doesn't help. For the "About X" language pages, I'd like to see them grouped (for the purposes of this category) under "A". --EncycloPetey 15:44, 13 October 2007 (UTC)

Ruakh has done this. Robert Ullmann 09:55, 16 October 2007 (UTC)

Thanks, Ruakh. That helps enormously. --EncycloPetey 04:41, 19 October 2007 (UTC)

template for back-formations

(Just fyi.) I have created a new template, {{back-form}}, for back-formations' respective etymology sections. Its main purpose (and effect) is to categorize such entries into category:Back-formations; it also provides a link to the glossary entry for back-formation and makes the older word a {{term}}.—msh210℠ 20:38, 17 October 2007 (UTC)

Might be a good idea to provide for language classification. Circeus 03:56, 19 October 2007 (UTC)

Ruakh's added that (thanks, Ruakh!) in the form category:he:Back-formations. Wouldn't category:Hebrew back-formations be more usual, though?—msh210℠ 05:09, 19 October 2007 (UTC)

My understanding is that if the English is [[Category:Foo]], then the Hebrew is [[Category:he:Foo]] (and likewise with other languages), and if the English is [[Category:English foo]], then the Hebrew is [[Category:Hebrew foo]] (and likewise with other languages). I can never really tell which of these two systems is appropriate, so was just following your lead; if you'd like to change it, I've no objections whatsoever. —Ruakh_TALK 05:24, 19 October 2007 (UTC)

Looking at Special:Allpages/Category:de:, it seems that the "he:" format is used for referent categories (Animals, Religion) whereas the "Hebrew" format is used for word categories (Nouns, Adjectives). (There seem to be some exceptions; nevertheless,) I guess then that the "Hebrew" format would be more appropriate here. (I can figure out how to do it, maybe, but certainly not now.)—msh210℠ 18:25, 19 October 2007 (UTC)

This is similar to, e.g. "idioms", and should probably use the full name. Circeus 22:00, 22 October 2007 (UTC)

Issue with Logo?

I am not a normal Wiktionary contributor, I spend most of my time on enwiki. However, an e-mail came through OTRS that I thought the community here might need to see. I probably won't check in on this discussion again, I just wanted to drop a note and see what needed to be done. ^demon 17:06, 19 October 2007 (UTC)

On the main page, and in the upper left corner of subsequent pages, the
phonetic spelling of "wiktionary" is incorrect.

Current: wɪkʃənrɪ
 
Correct: wɪkʃən(ə)rɪ

See WT:BP#Logo and WT:BP#Refocusing the logo discussion and several dozen (at least) outdated discussions and I think somewhere there's even an FAQ on the subject explaining why neither is correct in the U.S. DAVilla 20:12, 19 October 2007 (UTC)

FAQ is here. But this is a new complaint. Apparently the RP IPA is wrong, and they want to put in... RP IPA(!) I think our current RP IPA in Wiktionary is misleading. Do we use parentheses anywhere else in the IPA? My understanding is that there are two RP pronunciations, the three-syllable one in the logo, and the four syllable one, wɪkʃənərɪ. We should list them separately. Dmcdevit·t 21:46, 19 October 2007 (UTC)

Yes, I hope they would all be listed separately in Wiktionary. I could see using parentheses for liasons, when the word varies pronunciation based on context, but I don't think that's even documented on Frech Wiktionnaire. DAVilla 06:51, 28 October 2007 (UTC)

Somebody else using my account

I have started using this account again. I'd forgotten the exact name and have just found it.

Idly having a look at what I last did I've discovered a strange set of entries in 'contributions' made at a time when I was not editing Wiktionary. All but one are Transwiki entries (I'm not 100% clear what these are). In most cases they follow on from an edit made by a robot 'SmackBot' around April. All bar one occur around the end of a month (July-August and August-September) and all are suceeded by an edit by Connel MacKenzie one or two days later.The entries do not appear to be vandalism but as the compare function does not work in quite the same way for this type of entry (as far as I can make out) I can't quite see what the edits have done.

Mainly I'd like to know how someone was able to use my account and why they chose to do so.

I have never told anyone the password to the account. Moglex 10:31, 21 October 2007 (UTC)

• Do you have an account (with the same name) on Wikipedia? Transwiki items have come from there by a semi-automatic route and will have carried their history with them. SemperBlotto 10:35, 21 October 2007 (UTC)

There does appear to be an account on Wikipedia in that name, but it does not have the password I would use and there is no email address associated with the account. Further, I have absolutely no knowledge of the words that occur, I definitely have not edited Wikipedia with that account this year, and the entries do not appear to have been done by a robot because they have different comments (that look as if they were each added by hand), that actually relate to moving things from Wikipedia to Wiktionary. In one case the comment is "Wikt can have this shit too" which is not something I would have put in the comment field. Moglex 12:08, 21 October 2007 (UTC)

These are transwikis, carrying their history from the 'pedia. So the "other" Moglex shows up as you. (Can we please have unified login? Like not next year, like it always is? ;-). Connel's edits(s) are cleaning up the twikis. That's why you see them related to moving things. Robert Ullmann 12:57, 21 October 2007 (UTC)

At least have the transwiki function add a "w:" (or "b:" etc.) to the username ([[w:User:Foo]] instead of [[User:Foo]]) so that the links in the history points to the correct project? That shouldn't be that immensely difficult to add, I'd guess? \Mike 14:34, 23 October 2007 (UTC)

I'll ask Brion if that is feasible. When you or my TW bot does a Special:Import the MediaWiki software does a considerable amount of magic just to get the entry "over the wall." I haven't filed a bugzilla feature request for this yet - have you? --Connel MacKenzie 17:02, 31 October 2007 (UTC)

Update to {{context}}

I cleaned up several things that had been there while working with the older context label templates (mostly mixed case language codes); simplified a few other things, there should be no more reference to {{context 0}}. {{context x}} will go away presently, as it is removed from the label templates.

Also only categorizes when used in NS:0, or in NS:template (10). So you can use context label templates in examples etc on talk pages.

Tell me if you note any odd behavior. (by the template, not me ;-) Robert Ullmann 14:17, 21 October 2007 (UTC)

{context 0} has now been completely dereferenced; I'm going to start removing the references to {context x}, which was also part of a transition mechanism. Will go slowly, editing a series of templates causes the job queue to go nuts ... ;-) FYI: the change is that label templates start with {{context {{{sub|}}}|... rather than {{context {{{sub|x}}}|... {context x} is now just a redirect to {context} Robert Ullmann 10:50, 24 October 2007 (UTC)

{context x} is also completely dereferenced. Robert Ullmann 13:32, 25 October 2007 (UTC)

Gender and number templates

(see discussion at Wiktionary:Requests for deletion/Others#Template:m.pl.)

To deal with a profusion of templates: {{mf}}, {{fm}}, {{mpl}}, {{m.pl.}}, {{nm}}, and others, the simple templates have been modified so that one can simply write these combinations: This is done very simply, and the templates don't reference any template not used. Robert Ullmann 12:38, 22 October 2007 (UTC)

Does this apply to {{c}} as well? --EncycloPetey 13:43, 22 October 2007 (UTC)

Yes, just didn't happen to include it in an example. {{cpl}}: Template:cpl can be replaced:

with the standard abbreviation of plural. Robert Ullmann 14:02, 22 October 2007 (UTC)

A more complete table, I tried to find all of the templates and redirects in use: there may be more out there ... ;-) Robert Ullmann 14:21, 23 October 2007 (UTC)

Deleted {S} and {P} redirects; only one use, in grass. Working on sorting the others. Robert Ullmann 14:11, 25 October 2007 (UTC)

Deprecated {m.pl}, {mpl.}, {f.pl}, {fpl.}, {n.pl}, {npl.}; will be automatically fixed if used. Deleted {n.} not used anywhere. {f.} and {m.} still need to be orphaned. {mf.pl.} was used in one entry plus, deleted. Robert Ullmann 14:59, 25 October 2007 (UTC)

Deprecated {m.}, {f.}, {pl.} will be automatically replaced. Robert Ullmann 15:56, 25 October 2007 (UTC)

Deprecating/fixing the rest of [mfcn]p. Robert Ullmann 23:02, 25 October 2007 (UTC)

Minion (I would say slave, but he/she/it complains when I watch cricket whilst, um, he/she/it "works", must be nice) is munching through the mpl, fpl, npl entries, which were moved for some reason to {{m.pl.}} etc ... fixing Robert Ullmann 00:27, 26 October 2007 (UTC)

Found some problems with extraneous spaces, fixed. Working on slowly crunching existing uses of {mf}, in pages and templates. Robert Ullmann 23:20, 29 October 2007 (UTC)

Status: all of the templates in the RHS of the table above have been replaced and deprecated, if used they are automatically replaced by AutoFormat. The completely useless and unused I have deleted, some (mpl, fpl, etc, and mf) need to stay for a while as lots of people are familiar with them. Robert Ullmann 14:50, 3 November 2007 (UTC)

"and" or "or"

Separate question: {{mf}} used to say "and", it was changed to "or" in July. "and" makes much more sense to me; one says that a given form is both the masculine and the feminine form rather than it is one or the other.

Also, we need to be able to write:

• {{f}} ''or'' {{m-p}}: f or m pl

In which one does want to say "or", as distinguished from the other case. Robert Ullmann 12:38, 22 October 2007 (UTC)

This is because Jon Harald Søby changed {{no-noun-c}} to use {mf} instead of {c}, and then four minutes later, changed {mf} to use "or" instead of "and", disregarding the other thousands of use of the template. So a non-issue. (And the no-noun-c template ought to go back to {c}, and it someone wants {no-noun-mf} that's fine. Robert Ullmann 23:20, 29 October 2007 (UTC)

serial comma

Does anyone care? (the serial comma in "a, b, c, and d" is the last one before "d"). Can be fixed, but really picky! (and overhead on every page render) Robert Ullmann 00:27, 26 October 2007 (UTC)

I care. We can do it so why not do it. Is it broken now? MediaWiki only renders it when something on the page changes it then keeps it cached the rest of the time. — Hippietrail 00:35, 28 October 2007 (UTC)

Broken? Because it doesn't yet have an arcane feature? Humph. Unlike {{see}} which adds a few extra spans to a page, this can add hundreds. Done. Robert Ullmann 12:17, 28 October 2007 (UTC)

order of genders

As noted in the table, Hippietrail created a couple of templates that are out of the "canonical" order m, f, n, c; is there any reason for this? Robert Ullmann 00:27, 26 October 2007 (UTC)

He said he was just following the order in (some) entries. I don't see or know of any reason not to always use the canonical order. Robert Ullmann 13:41, 26 October 2007 (UTC)

I haven't done any research but there must be cases like these:

1. All of the Spanish speaking world uses f for a certain word, but El Salvador alone uses m.
2. A certain word was m up until the 19th century but now it's f.
3. It's technically okay to use n with a certain word but in reality 90% of people use f.
4. m is used for in poetic, literary, or some other style of writing, but generally n is used.

Naturally I would advise that all such terms have a mandatory Usage notes section. Maybe a good idea would be to use a bot to put them all in a category requesting usage notes to explain the multiple genders. — Hippietrail 00:04, 28 October 2007 (UTC)

What about professeur? If I remember my French correctly, historically it's only masculine, but now that the gender barriers are dropping you can find uses of google:"la professeur" (though it seems to be morphing into professeure). I think it would be fine to use canonical order in translation tables, but require usage notes in actual entries. Cynewulf 00:11, 28 October 2007 (UTC)

In ancient times, Hebrew (deprecated template usage) שֶׁמֶשׁ (shémesh) could have either gender, but by modern times it's become exclusively feminine. Currently our entry sidesteps this issue by not mentioning its gender, but that's not really a solution. I don't know that "f and m" would really be much better than "m and f", though; something like "f-but-see-usage-note", only less ridiculous, would probably be best. —Ruakh_TALK 01:13, 28 October 2007 (UTC)

Does "usually" cover all of these cases, e.g. usually f for 1-3 and usually n for 4? We should only be marking what's prevelant anyway, and it's a flag to see the usage note. DAVilla 06:38, 28 October 2007 (UTC)

{fm} is presently used in 9 entries, {nf} in 2. You added {nf} to raclette. You created şanţ, changed "f and m" to {fm} in juice, 90.149.7.137 added Norwegian with {fm} to 4 entries, Barmar added Dutch to wheelbarrow with {fm} (6 months before the template was created ... ;-), you changed f/m to {mf} in visitante. None of these need usage notes. (The ones in the trans tables don't in any case, the note would go in the entry of course.) I think they can just go away. Trying to explicate frequency of usage, or modern vs old, or region etc by ordering these isn't useful anyway. Robert Ullmann 12:48, 28 October 2007 (UTC)

I'm just deprecating/replacing these for now. Robert Ullmann 23:55, 28 October 2007 (UTC)

{{infl}} and {{t}}

Both updated to work well with these. Robert Ullmann 13:41, 26 October 2007 (UTC)

Invariant number

Spanish dictionaries list nouns which do not change form for singular vs plural as, for example, m inv. Should we add i along with p and s? And should it expand to "invariant" or "inv."? — Hippietrail 05:00, 5 December 2007 (UTC)

well, {{i}} is busy being short for italbrac/qualifier. We already have {{inv}} (which was "invariable", somewhat oddly), I fixed its class and category, using "inv" and the conditional full stop. The entries that already use it (Italian, and Italian in trans tables) look better already. It plays nicely with the above {{m|inv}}: (removed)

good? (note that "inv" is not an ISO 639-3 code presently assigned, burn that bridge if we come to it) Robert Ullmann 08:15, 5 December 2007 (UTC)

Citations: namespace?

Since the vote passed in July, how long does it take to get NS:114 and Citations talk: NS:115 (now: "Citations" and "Citations talk")? Who needs to be prodded? (and make sure they understand it is "Citations", not "Citation" ;-) Robert Ullmann 13:37, 22 October 2007 (UTC)

I never asked anyone because it wasn't urgent, but if you're willing to move the /Citations subpages in batch then SB or any of the other bureaucrats should be able to do it. DAVilla 06:31, 28 October 2007 (UTC)

It is a change to LocalSettings.php, needs a developer. Robert Ullmann 11:39, 28 October 2007 (UTC)

Is the moving basically as simple as “pagename/Citations” → “Citations:pagename”, or is it more complex? Explain it to me, and I’ll do it. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 11:58, 28 October 2007 (UTC)

Yes, but you have to wait until the namespace exists. And then there is some magic to handle the existing Citations:xxx pages so they actually get into that namespace; probably they should be moved back to xxx/Citations for now. (oh, and do use Citations:pagename, not Citations:PAGENAME like DAVilla has been, supposedly because the capitalization hasn't been determined or some such thing.) Robert Ullmann 12:55, 28 October 2007 (UTC)

OK; I’ll do the moving back to the subpages then. I could only find two — Citations:ABIDINGPLACE and Citations:SPACEDOCK — though undoubtably there are more; where could I find them? I had wondered about the ALLCAPS format I’d seen; what’s that about?

BTW, my revision to prevent {{citation}} from auto-catting the wrong pages seems to have broken the template (except for, curiously, its transclusion on Template talk:citation). Does that revision need to be reverted? (–That is, did I do something wrong?) † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 14:36, 28 October 2007 (UTC)

See Special:Prefixindex/Citations:. —Ruakh_TALK 15:10, 28 October 2007 (UTC)

There were only seven (of which one was already a redirect); they’re all done now. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 16:53, 28 October 2007 (UTC)

Your change put the category on the line before the ==. With the includeonly tags, the next characters are treated as the start of a line if they are formatting characters. Just an odd little detail. Of course in any other namespace, there is no cat, so it works ;-) Robert Ullmann 15:16, 28 October 2007 (UTC)

Interesting. Yeesh! There are so many nuances to coding! † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 16:53, 28 October 2007 (UTC)

This one is an odd side effect, that kind of corner case should not exist. Hakuna matata. Robert Ullmann 23:08, 28 October 2007 (UTC)

We also need to be sure that template links (as from {{seeCites}} ) to the current citations pages are appropriately redirected; preferably by editing the necessary templates in conjunction with the page moves. --EncycloPetey 16:20, 28 October 2007 (UTC)

Wiktionary:Namespaces doesn't seem to reflect the fact that this namespace exists, now. --Connel MacKenzie 18:31, 30 November 2007 (UTC)

Patrolling?

I've been wondering who is working on this, besides Connel and myself.

A week or so ago, RC + &days=30&limit=500&hidepatrolled went back about a day; now after running Rat Patrol for that time, clicking through manual marks, it goes back to October 1st. (And would be ~September 22 when today's are done.)

If we are going to do this, we need several people to clear that list and keep it clear. It is useful; I've reverted vandalism (mostly graffiti) from several weeks back. There must be much more that has been getting lost.

What say you? Robert Ullmann 13:46, 25 October 2007 (UTC)

I haven't had much time for Wikt lately (admittedly by choice - I'm trying to see the country before the weather gets... well, worse!), so I've basically been patrolling when I get a chance. It doesn't amount to much, but it makes me feel better than ignoring the project completely. Apologies! Medellia 00:06, 26 October 2007 (UTC)

My patrolling this time of year is sporadic. I usually try to hit all the edits between UTC 20:00 and 24:00, but haven't been regular on that the past few months. --EncycloPetey 23:24, 27 October 2007 (UTC)

I am reducing my wikitime and patrol only occasionally, I am afraid. H. (talk) 11:52, 29 October 2007 (UTC)

Geneva Convention

Geneva Convention has an RFD template from July 28th, but the discussion has been aged off. Does anyone remember the result without having to search the history? RJFJR 04:28, 26 October 2007 (UTC)

Wiktionary:Requests for deletion/Archives/2007/07#Geneva_Convention ... keep. Robert Ullmann 11:20, 26 October 2007 (UTC)

Minor formatting change to be programmed into User:AutoFormat

It has been suggested here that AutoFormat add a space between the wikicode uses of asterisks and the visible text which follows them. Is everyone OK with this (very minor) change being made? † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 21:30, 27 October 2007 (UTC)

Note that AF would not be going around looking for pages to tweak, this is "minor spacing" only done when doing something else. AF doesn't do this now, except it adds a space after a single #, and any space after * in a translations section disappears because AF takes apart and reassembles the lines. This was/is following the discussion in normalization of articles as well as observing existing practice. The examples in WT:ELE show spaces after *, except for the translations section.

Doremítzwr is observing that as a result AF is essentially enforcing no-space in translations sections; it should either remember and restore a space if present, or (better and simpler) just always format with one space. Robert Ullmann 13:08, 28 October 2007 (UTC)

I'm going to try this; as long as it isn't buggy, it won't affect rendering. Robert Ullmann 23:53, 28 October 2007 (UTC)

{{rfv}} needs to change.

Dumping all RFV material on one page doesn't scale. We're currently generating 200-250k of stuff on RFV every month, and it looks like it's accelerating.

Some ideas:

• Split RFV into subpages by time period: one month, one week, one day. We can then turn RFV itself into something like WT:VOTE itself, only including subpages; links will still work through the magic of templates. This would require either rfv to be subst-only or something like AutoFormat to stick a date on RFV tags. We could use the date on the RFV tag to see what's more than 30 days old.
• Use one subpage per spelling, and use transclusion as above to make things linkable. We could then use categorization of the subpages for dating and figuring out what hasn't been closed.

Any more ideas? Last time nothing really got done, probably due to the complexity of a bot archiver, which is why I'm proposing self-archived subpages. If somebody wants to write a bot that'll handle everything, that'll be great, but I can't do it myself. Cynewulf 19:00, 28 October 2007 (UTC)

I’m for the first idea, coupled with stricter adhærence to the one-month deadline. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 21:29, 28 October 2007 (UTC)

As I see it, the main problem is that people will frequently comment on a word to say, "this is real", and then never actually cite it. (Nothing against those people — I'm one of them sometimes — but it makes it difficult to close an RFV, because you don't want to delete something that a fellow editor says is real, but you also don't want to mark something "RFV passed" if you've never heard of it, it's not been cited, and it doesn't seem to be in clearly widespread use.) I think the solution is three-fold: one, to delete entries much more quickly if no one's spoken up for them (if an English entry's been on RFV a week and no one says so much as "this seems very plausible", it's probably nonsense or a protologism or spam), two, to move resolved discussions to the month-by-month archives so they're not bogging down the page (and if you think about it, there's no need for a month archive to be pretty; this can be a pretty dirty cut-and-paste and I don't think anyone will care), and three, to pester people who say "this is real" to put their quotations where their mouths are. —Ruakh_TALK 23:37, 28 October 2007 (UTC)

{{context}} skey oddities

I noticed in 宇宙線 that the sort key on context tags behaves differently depending on how the tag is written. (Japanese categories get sorted by hiragana)

• {{context|astronomy|physics|lang=ja|skey=うちゅうせん}} uses the sort key on neither cat.
• {{astronomy|physics|lang=ja|skey=うちゅうせん}} uses it on astronomy but not physics.
• {{astronomy|lang=ja|skey=うちゅうせん}} {{physics|lang=ja|skey=うちゅうせん}} uses it on both.

So, it looks like the skey isn't being passed to templates beyond the first expansion. Could this be fixed? Cynewulf 20:09, 28 October 2007 (UTC)

Also, it would be nifty if AutoFormat could automatically pull the sort key from the POS template's hira or hidx parameter. Cynewulf 20:11, 28 October 2007 (UTC)

In the meantime, this revision seems to have done the trick. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 21:32, 28 October 2007 (UTC)

How the frack did I miss that? Fixed! Thank you, thank you! Robert Ullmann 23:05, 28 October 2007 (UTC)

{{i}} inside {{en-verb}} (and others)

I noticed that using {{i}} inside other templates does not seem to work. I tried to use it in the verb inflection line of label, but then only the American forms are rendered. How come and is there a solution for this?

As a side note: is there a convention on how to format verbs whose inflection is different in American an British spelling? I’d rather prefer it to be on two lines instead of how it looks there. H. (talk) 11:49, 29 October 2007 (UTC)

AFAIK, you’ve almost got it, except the abbreviations UK and US are used instead of “British” and “American”, and the variant forms are divided by an italicised “or”, so that you get this:

to label (third-person singular simple present labels, present participle labelling (UK) or labeling (US), simple past labelled (UK) or labeled (US), past participle labelled (UK) or labeled (US))

Nota also that using {{term}} inside {{i}} displays neither. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 12:24, 29 October 2007 (UTC)

Template:i and lots of others use CSS with span tags, they use class="something". See the =? If you try to use any of them as positional parameters, the = will get the string interpreted as a named parameter. If you use one in a named parameter, you are fine, since it already has the =. (In most cases you're trying to do something you shouldn't anyway.)

The way you do it is to use (e.g.) 2=(...) instead of just the second positional parameter (which is named "2" ;-). Then you hope that with a template like en-verb that has sub-templates that the person who wrote it knows all this for the calls it makes. See label, seems to be okay. Robert Ullmann 12:27, 29 October 2007 (UTC)

The transatlantic variants should really be separated with ''or''s, not commas. Either that, or each verb form should be separated from the others with a semi-colon. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 12:59, 29 October 2007 (UTC)

Yes, missed that. Edited it before reading your comment supra. Robert Ullmann 13:10, 29 October 2007 (UTC)

Template:onym and Template:l

Two similar templates, {{onym}} and {{l}} seem to need to be merged. They both link an entry from a list section (synonyms, antonyms, derived terms, etc.), providing a language section link, scripts, transliterations, and glosses. Such is a very frequent need, so it seems to make sense to use one of the few one-letter template names for that feature, and so to merge {{onym}} into {{l}}. Does anyone have any reason not to use the one-letter template name {{l}} for this feature?

By the way, should this template also accept {{{g=[grammatical gender and/or number]}}}? Rod (A. Smith) 07:53, 30 October 2007 (UTC)

Yes, if they provide the same functionality (and now they apparently very much do :), they should definitely be merged together. Shortening the template name as much as possible could save significant space when used in large lists (Swadesh, language indices, list of derivations from proto-terms in Appendix namespace...).

For usage in such listing scenarios, when no particular meaning is referred to, I don't think it makes sense to add anything besides ISO 639 code and a lemma to dispatch to. So gloss and transliterations shouldn't be used for list of derived terms, descendants and such. For a meaning-specific dispatch they should be obligatory. --Ivan Štambuk 09:56, 30 October 2007 (UTC)

Like here and here - what sense does it make to add a transliteration when the article itself or the article {onym} links to is the transliteration itself? Transliterations and meaning gloss should come in pairs - much like they're used now in Etymology and Translations sections. --Ivan Štambuk 10:06, 30 October 2007 (UTC)

In general, we do transliterate every non-Latin term into the Latin script, regardless of whether it has an accompanying English gloss. I appreciate your position with regard to Serbian alternative spellings, though. Maybe the Alternative spellings section is a good place to make an exception to the “always transliterate” rule when the spelling varies only by script. (Hopefully this conversation will result in a thorough update to Wiktionary:Transliteration.) Rod (A. Smith) 19:06, 30 October 2007 (UTC)

Declension and conjugation tables, language indices and Swadesh lists are also a natural example for exemption (I don't think I've seen transliterated terms in any of these yet). As for the synonyms/antonyms/hypernyms/hyponyms/meronyms/holonyms/troponyms - WT:ELE suggests using by line meaning separation using something like {{sense}}, which renders gloss parameter of {{onym}} redundant. --Ivan Štambuk 19:28, 30 October 2007 (UTC)

Yes, the gloss would certainly be redundant after {{sense}}. Good point. As for declension and conjugation transliterations, see 하다 (hada) or anything else at Special:Whatlinkshere/Template:ko-conj-verb or Special:Whatlinkshere/Template:ko-conj-adj. Rod (A. Smith) 20:08, 30 October 2007 (UTC)

Why aren't transliterations provided for tables of inflected forms of lemmas of other languages not using Latin script as well (Greek, Russian..)? I really wonder is Korean an exception or rather an exemplar for this "transliterate always" rule. One thing is certain - for inflected forms of nominal words in a language with 6 cases times 3 genders times 3 numbers (*3 for adjective comparatives/superlatives) the amount of information to be shown in a declension table of 9 columns would amount to quite a lot. Maybe some "Show/Hide transliterations" button could be made similar to those of Show/Hide in Translations section? I really don't mind having them, as long as it's visually satisfying. --Ivan Štambuk 13:27, 31 October 2007 (UTC)

Korean conjugation transliterations are present only because Visviva and I are under the impression that this project requires every non-Latin script word to be followed by a transliteration. I didn't realize that Greek and Russian conjugation tables lack transliterations. I guess I should ask BP readers whether non-Latin script conjugation tables should include transliterations. Rod (A. Smith) 16:50, 31 October 2007 (UTC)

Where ever did you get that idea? It is usual to include a transliteration on headword lines, and ELE says they should be included in translations tables, but mostly no-where else except in running text (Etymologies) where useful; people have added them to -onyms and derived/related terms in some cases. There is no requirement that they be used anywhere except the "do add" in translations in ELE. Certainly not in conjugation tables; they are big enough as it is. Go to the entry. Robert Ullmann 11:42, 4 November 2007 (UTC)

Which might be reasonable, if the entries in question existed. I do hope to have a semi-automated system for generating well-formed Korean form-of entries running sometime this year, but for now if the information isn't present in the lemma page it won't be present at all ... which would be something of a disservice to the reader. -- Visviva 03:26, 7 January 2008 (UTC)

Exemplar, I would say. This is the English Wiktionary. Our FL entries exist to serve those without a solid grasp of the language (and possibly the script) in question. But whatever. -- Visviva 03:26, 7 January 2008 (UTC)

Yes but, where exactly would transliterations fit in, for example, declension teble of παραλυτικός (paralutikós) ? I'd say that logogram-based scripts are entirely different category. If we were to assume that user browsing, say, Russian entries has only very basic knowledge of Cyrillic script (i.e. is too lazy to spent half an hour learning it), I'd say that the lack of transliterations in inflection tables is the least of his problems. --Ivan Štambuk 04:29, 7 January 2008 (UTC)

According to the {{onym}} documentation, it is only for use with non-Latin scripts. So why is it now being used with Latin scripts? It isn't intended to provide a gloss; it's intended to provide a transliteration. --EncycloPetey 13:00, 31 October 2007 (UTC)

According to the {{onym}} documentation, “If this template is adopted, it will be used to list a term or phrase that is written in a non-Latin (non-Roman) script or should be followed by an English sense gloss within a list section (====Synonyms====, ====Antonyms====, ====Related terms==== (“paronyms”), etc.).” I suppose that wording should be made a bit more clear, but the intent of the template is to provide typographic consistency with respect to scripts, transliterations, and sense glosses. Synonyms and antonyms don't need such a gloss because they should follow {{sense}}, but sense glosses seem helpful for some other list section links. Recently, I noticed that the undocumented {{l}} is used as a shorthand way to write language-specific Latin script list section links without English sense glosses. This conversation will hopefully shed some light on whether such a usage is desirable and on the best name for the merged template. Rod (A. Smith) 16:50, 31 October 2007 (UTC)

Common headword template parameter name: "head"

I like the name {{infl}} uses for the headword-specifying parameter: {{{head}}}. In the interest of consistency, we should probably add support for that parameter name to {{en-noun}}, {{en-verb}}, {{en-adj}}, etc. Initially, {{{head}}} can be just a preferred alternative for {{{sg}}}, {{{inf}}}, {{{pos}}}, but eventually those older parameter names should be deprecated. Comments? Rod (A. Smith) 18:55, 30 October 2007 (UTC)

The older parameter names are more informative for the specific templates in which they appear. "Head" has too many possible meanings in English for use so broadly. I would rather see the precision retained. --EncycloPetey 13:03, 31 October 2007 (UTC)

I don't see why - as it is, they are very difficult to keep track of. You're talking about displaying the headword of an entry with formatting/link tweaks. I'd much rather see consistent terminology for this, than have to guess for each one...then go edit that template when I (invariably) guess wrong...then find that {{temp}} left me on the talk page, which doesn't give an example, so I have to then go to the template page and edit it to see what the real parameter name is. Javascript helps me not have to memorize all the differences, but I can't fathom how other people keep track of all those variations. --Connel MacKenzie 22:51, 8 November 2007 (UTC)

Well said. —Ruakh_TALK 03:16, 9 November 2007 (UTC)

{{{pos}}} is already used wrongly in some templates, such as {{en-prep}}. I strongly support eliminating all this confusing inconsistency and using {{{head}}} exclusively for all such templates, or at the very least, supporting {{{head}}} as an alternative for all such templates. —Ruakh_TALK 18:30, 31 October 2007 (UTC)

Cf. Wiktionary:Votes/2007-10/Lemma_entries and Wiktionary:Votes/2007-10/Lemma_entries/words. If we have inflection lines for plurals, we'll want the headword to be the plural, I assume, and the singular mentioned elsewhere on the line. One step in that direction might be to use head instead of sg. (An alternative step would be to use a different template.)—msh210℠ 18:42, 31 October 2007 (UTC)

Good idea. H. (talk) 13:56, 7 November 2007 (UTC)