Wiktionary:Grease pit/2006/October

Display Problem
I'm taking Hippietrail's suggestion and reporting it here. The template "xsee" doesn't display the space before "and" for me. Other spaces work fine. I'm using Mozilla Firefox 1.0.7. --Filip 18:38, 12 June 2006 (UTC)


 * Not a browser problem. 'Twas that was wrong. Fixed. — Vildricianus 19:41, 14 June 2006 (UTC)


 * Good to hear. --Filip 08:46, 15 June 2006 (UTC)

Vandalism - blocks
Just a note to other admins: when you see vandalism, simply deleting the entry is a good thing. But issuing a short term block is also very helpful, as that user is then added to other automatic watchlists and subsequent contributions are flagged as likely problems. --Connel MacKenzie T C 20:23, 12 June 2006 (UTC)
 * There are 101 different types of vandals. Sometimes it's highly superfluous to block someone. When it's not, I block, usually for 1 day. But, which watchlists are these? — Vildricianus 10:10, 13 June 2006 (UTC)
 * Also, don't forget to post in the BP once in a while ;-). — Vildricianus 10:12, 13 June 2006 (UTC)
 * The vandalism channel(s), not the recent changes channel. --Connel MacKenzie T C 18:11, 13 June 2006 (UTC)
 * Right. People won't know this and the BP is more likely to reach more admins. Perhaps we need something like a noticeboard only for such short messages. — Vildricianus 18:36, 13 June 2006 (UTC)

Probable copyvios
We should probably have a separate template (similar to rfc, rft, rfd) for probable copyvios like palpation. I did my routine searches and did not find it, but the formatting (well, the lack thereof) leads me to suspicion. --Connel MacKenzie T C 23:23, 12 June 2006 (UTC)


 * I think that's a good idea. Why not just ? &mdash; Hippietrail 17:55, 13 June 2006 (UTC)


 * 'Cause that's used when one knows it is a copyvio, not when one merely suspects it is. --Connel MacKenzie T C 18:02, 13 June 2006 (UTC)


 * Whatever you find suitable for it then. RFI (investigation)? I have a gut feeling that it should be used sparingly, though. — Vildricianus 18:41, 13 June 2006 (UTC)


 * Well, I'm thinking more of something for adding a subtle category to suspicious looking entries, only. If an entry doesn't cite its sources (via =References=) it could potentially be marked as suspect.  (Currently, 98+% of our entries could be tagged as insufficiently referenced.)  --Connel MacKenzie 08:23, 9 July 2006 (UTC)


 * Oh well... I know Muke has been tagging some stuff with, but yes, about 98-99% could do with such a tag. — Vildricianus 08:33, 9 July 2006 (UTC)

Selective delete
The technique for selectively deleting a revision of an entry is spelled out at WT:DEL / Sysop tools. --Connel MacKenzie T C 05:10, 13 June 2006 (UTC)


 * AFAIK, it could be much simpler: you just delete the page and restore everything except the bad edit. No need for moving and deleting redirects.


 * Also, this should be done with restraint. Actually, it should only be done when an edit inserts personal information, which if not removed from the page history, can at all times be viewed.


 * Also, large pages (e.g. Beer parlour) will be difficult to restore selectively, because of the history size. Developer intervention is necessary then. If we are really going to experience difficulties with such edits, we should request the oversight permission thingy that they're now testing at WP.


 * Another thing is of course preventing the issue instead of dealing with it. We should very much encourage people, certainly sysops, not to reveal any personal information. — Vildricianus 10:06, 13 June 2006 (UTC)


 * Your last comment, what? Most personal information that ends up here is a result of vandalism.  A healthy reminder is probably in order, for the issue you mention, but I don't see that as the issue at hand.  --Connel MacKenzie T C 18:08, 13 June 2006 (UTC)


 * Well, if people post their phone numbers online, then sooner or later some vandal will catch it and do something with it... that's what I mean. What is the issue at hand then? Or, for what reason other than removing personal information would you consider this "selective delete" technique worth applying? — Vildricianus 18:45, 13 June 2006 (UTC)


 * One doesn't have to publish information about themselves for information about them to become spread over the internet. But yes, this technique should be applied primarily to personal information vandalism.  --Connel MacKenzie T C 18:03, 14 June 2006 (UTC)


 * That first sentence: of course not, but then, you choose to associate it with your wiki username if it happens to be your real name :-). — Vildricianus 19:34, 14 June 2006 (UTC)

Error - Python wikipediabot's pagefromfile.py
I've been trying to use python wikipediabot's pagefromfile.py to batch upload, but I've been experiencing some errors. Any ideas?

After I tried to login I got the following response:

Checked for running processes. 1 processes currently running, including the current process. Password for user sesotho.web.za on wiktionary:st: Logging in to wiktionary:st as sesotho.web.za Traceback (most recent call last): File "C:\Python24\login.py", line 218, in ? main File "C:\Python24\login.py", line 214, in main loginMan.login File "C:\Python24\login.py", line 167, in login cookiedata = self.getCookie File "C:\Python24\login.py", line 119, in getCookie conn.request("POST", pagename, data, headers) File "C:\Python24\lib\httplib.py", line 804, in request self._send_request(method, url, body, headers) File "C:\Python24\lib\httplib.py", line 827, in _send_request self.endheaders File "C:\Python24\lib\httplib.py", line 798, in endheaders self._send_output File "C:\Python24\lib\httplib.py", line 679, in _send_output self.send(msg) File "C:\Python24\lib\httplib.py", line 646, in send self.connect File "C:\Python24\lib\httplib.py", line 630, in connect raise socket.error, msg socket.error: (10060, 'Operation timed out')

JAK --82.198.250.67 07:37, 13 June 2006 (UTC)


 * It looks like you are going to the wrong url - sesotho.web.za instead of http://sesotho.glwb.info/? Could you paste your 'user-config.py' here please.  Also, is your robot's skin set to Monobook?  Lastly, what version of MediaWiki is that running?  Also, is that dictionary GFDL?  Can we glom them into here?  --Connel MacKenzie T C 17:47, 13 June 2006 (UTC)


 * See the user-config.py below. Please note that 'sesotho.web.za' is just a username. The word list was compiled by myself so there ought not be any copyright issues. I've also posted the same content on http://sesotho.glwb.info/

mylang = 'st' family = 'wiktionary' usernames['wiktionary']['st'] = 'sesotho.web.za' console_encoding = 'utf-8'


 * JAK --82.198.250.72 09:50, 14 June 2006 (UTC)

Default charset for edittools
Is there a way to make another set than Latin/Roman displaying by default? I'd like IPA, because it's the only set I use from the Edit tools. — Vildricianus 10:55, 13 June 2006 (UTC)


 * The proper way would require either cookies or a hidden form element - but both of those require support from the server side. The absolute best way would probably also provide a field in the user preferences. All of these require changing the MediaWiki code as far as I can tell.
 * The hack way is to write yourself a custom JS function which sets it to your preferred field - but even a custom JS function can't get it to remember which set you used last.
 * There are people working on developing the whole thing over on commons. I posted what needs to be done to make it perfect and got no response. Maybe you can add to that thread.
 * I've also considered filing a bugzilla feature request to ask that the whole thing be integrated into MediaWiki and done properly. &mdash; Hippietrail 17:32, 13 June 2006 (UTC)
 * Yes, it would be sufficient for me if it simply remembered the last one visited, even per session. ∂ανίΠα 16:36, 14 June 2006 (UTC)


 * Done. Report bugs here, please.  (Remember to refresh cached Javascripts first, clear cookies, restart browser, etc., first.)  --Connel MacKenzie T C 20:30, 14 June 2006 (UTC)


 * Sorry, what are we supposed to look for? Should the charset be remembered? No, that's not working then. I don't have any other cookies than the standard ones. — Vildricianus 20:59, 14 June 2006 (UTC)


 * Bug report: This doesn't do anything for me. Tested on at least 3 machines all running Windows XP but with different browsers: IE, Firefox, Opera. &mdash; Hippietrail 19:51, 17 June 2006 (UTC)


 * Found one bug - tested on WinXP/IE, FC5/FF, Netscape. Didn't get it working in lynx, but then, I wasn't expecting that to work.  --Connel MacKenzie T C 05:05, 25 June 2006 (UTC)

Delete tab and Show changes button have same accesskey
I posted to the dev list about this too but maybe somebody here knows.

Wikipedia uses 'd' for the Delete tab and 'v' for the Show changes button. We use 'd' for both. Many of these accesskeys are set in MediaWiki:Monobook.js - but not Save page, Show preview, or Show changes. Does somebody know where these are set? &mdash; Hippietrail 18:17, 13 June 2006 (UTC)


 * I've been digging for this since, what, late January? So far, I've discovered that they are hardcoded into the system and not up for customization. If they had been, that would have saved me many a premature save, as I would have removed them. — Vildricianus 18:50, 13 June 2006 (UTC)


 * Say what? I use ALT-V on almost every edit.  ALT-P (Preview) works for me, also.  --Connel MacKenzie T C 18:53, 13 June 2006 (UTC)


 * Oddly enough, we're both right! Alt-v does indeed work, but as you'll see by hovering your mouse over the Show changes button, it very clearly states "Show which changes you made to the text. [alt-d]". It could be set in two places with one overriding the other. &mdash; Hippietrail 19:20, 13 June 2006 (UTC)


 * That text (which I just corrected) was in MediaWiki:Tooltip-diff which I found from Special, System Messages. --Connel MacKenzie T C 21:53, 13 June 2006 (UTC)


 * The error seems to come from the distribution. It is fixed in Wiktionary and Wikipedia. It is still wrong in Wikibooks, Wikinews, Wikisource, Wikispecies, Wikiquote, Common, Meta-wiki, and Mediawiki. --teb728 02:53, 14 June 2006 (UTC)


 * I'm still wondering how I can remove the accesskeys, though. — Vildricianus 11:46, 14 June 2006 (UTC)

Something like this javascript used to do something about the tooltips: function removeSubmitTitles { document.getElementById("wpSave").setAttribute("title",""); document.getElementById("wpPreview").setAttribute("title",""); document.getElementById("wpDiff").setAttribute("title",""); } if(window.location.href.indexOf("action=edit")!=-1) addOnloadHook(removeSubmitTitles); But I'm not sure what it did. Probably removes them. — Vildricianus 19:25, 13 June 2006 (UTC)

Normalization of articles
User talk:Connel MacKenzie/Normalization of articles

Rather than keeping it included here, I'll just leave it linked to. I think most has been said about it, and all it does is cluttering up the TOC. We can still decide what to do with it: keep it as an archive or starting point for a renewed discussion, or summarize it and present it on the BP. Whichever we come up with, it should probably be moved out of Connel's user talk space into Wiktionary: but I don't have a clue whereto. — Vildricianus 11:56, 14 June 2006 (UTC)


 * That's fine. I tried including it here, as the purpose seems to have been lost, and I wasn't at all sure how to re-ignite interest in it.  Perhaps one item at a time?  Normalizing?  --Connel MacKenzie T C 17:34, 14 June 2006 (UTC)


 * I think we should split it up: 1/ items that are clearly done with and 2/ items that need further discussion. Most of the purely aesthetical stuff (e.g. blank lines) won't need anymore. Perhaps we can stuff it somewhere as an extended version of WT:ELE, as a reference. Continued debate should go on either here or in the BP. I'd like to see some more items being tackled, but probably after a pause of some weeks. I don't know whether we should set up a separate battleground at something like Normalizing. Perhaps that's not necessary. — Vildricianus 18:25, 14 June 2006 (UTC)

CoCat
Found this tool mentioned on Commons... http://tools.wikimedia.de/~voj/cgi-bin/cocat?wikilang=en&wikifam=.wiktionary.org

--Connel MacKenzie T C 17:24, 14 June 2006 (UTC)

Monobooking?
Should I add this to MediaWiki:Monobook.js, or leave it in my personal monobook (because I am the only one bothered by it):

// edit-section still doesn't return to correct spot. function goToRightSection { if (/\.5B/.test(window.location.href)) { var url=window.location.href.replace(/.5B/g, "").replace(/.5D/g, ""); window.location = url; } }

--Connel MacKenzie T C 21:37, 14 June 2006 (UTC)


 * If it fixes a bug, then general. What does it do? Oooh, does it fix the bug when section titles are wikified ? Get this at MW:Monobook.js right now please! — Vildricianus 21:53, 14 June 2006 (UTC)


 * Done. Restart browser, refresh cache, logout & back in, etc.  --Connel MacKenzie T C 22:03, 14 June 2006 (UTC)


 * Amazing. — Vildricianus 22:15, 14 June 2006 (UTC)


 * Any chance you fix the thing when there are { brackets } in the game? — Vildricianus 21:57, 16 June 2006 (UTC)
 * .7B and .7D. You got it...  --Connel MacKenzie T C 22:04, 16 June 2006 (UTC)


 * Whoops. That isn't right.  Rolling back.  --Connel MacKenzie T C 22:11, 16 June 2006 (UTC)


 * Mmm. Expected something like that. Too bad. — Vildricianus 22:15, 16 June 2006 (UTC)

WOTD RSS feed
OK, brainstorming time. There seems to be significant support for the concept of reusing Wiktionary's WOTD on other sites. Random sites are much more likely to put a handy WOTD link on their page than the Wiktionary logo, I'd guess.

If we do nothing, someone will figure out how to scrape it off our Main Page for us.

But, if instead, we provide some kind of "approved" way we'd like it done, we'll be able to influence the layout, wording, minimal GFDL-compliant backlinks, etc.

So, anyone know where to begin? --Connel MacKenzie T C 07:23, 16 June 2006 (UTC)


 * Beginning by looking at what happens with WP's "Today's featured article". I have no idea what. IIRC people can subscribe to some mailing list getting a daily copy? — Vildricianus 10:16, 16 June 2006 (UTC)
 * http://en.wikinews.org/wiki/Main_Page has a RSS feed. I don't know how they did it though. Kipmaster 11:55, 16 June 2006 (UTC)
 * Hrmm. Routing through http://www.feedburner.com.  :-(


 * Waitasec. Is an RSS feed the way to go?  It will update once a day only.  Perhaps we should have a WOTD that includes the template inside a frame without the sidebar nor top row, or something?  --Connel MacKenzie T C 16:26, 16 June 2006 (UTC)


 * Through CSS fiddling I could try making something without a frame yes. Try, that is. I don't know how possible it is though. Testing soon. — Vildricianus 17:27, 16 June 2006 (UTC)


 * Possible. Dirty tricks though, and less than desirable. — Vildricianus 17:51, 16 June 2006 (UTC)


 * CSS isn't the answer: It works on the browser side, inhibiting the display of text which the server sends. What is needed is a server-side solution; so that the server sends only the RSS with no additions of any kind. As a first stab, I created User:TEB728/temp.rss. Try adding http&#58;//en.wiktionary.org/w/index.php?title=User:TEB728/temp.rss&action=raw to your aggregator. It doesn't quite work, but it's a start. --teb728 23:54, 16 June 2006 (UTC)


 * Excellent. So something like WOTD could work, transcluding only the portions of the WOTD it wants?  Oh wait, no templates.  Hrm.  Closer, anyhow.  --Connel MacKenzie T C 00:02, 17 June 2006 (UTC)


 * I copied my RSS experiment to WOTD.rss so that other people can work on it. That makes its URL http&#58;//en.wiktionary.org/w/index.php?title=Wiktionary:WOTD.rss&action=raw (Maybe someone knows a less ugly way of addressing a raw page.) As it is, it hard links to today's and yesterday's WOTD. (Maybe someone knows how to do an automatic update.) It uses subpages Word of the day/Month_date, which have a small bug in that the table header always displays today's date. --teb728 23:11, 17 June 2006 (UTC)


 * About the small bug: I can't do it any differently, but perhaps someone else can, fiddling with . — Vildricianus 13:33, 18 June 2006 (UTC)

As mentioned in BP, do we need to state that this is the English word of the day? Davilla 04:14, 20 June 2006 (UTC)


 * Note Wiktionary talk:Word of the day. — Vildricianus 15:51, 20 June 2006 (UTC)
 * I see that the wiki news print edition includes the word of the day but how could you get this on lets say a personlized google home page? So far ive learned that one way of creating an rss feed for the wiktionary word of the day is to screen scrape the site http://en.wiktionary.org/wiki/Wiktionary:Word_of_the_day. I don't know enough about screen scraping to do it on my own, however, so I used feed43 to do it and came up with this feed http://feed43.com/wwotd.xml. - Eric 23:49, 3 November 2006 (UTC)


 * Darn, this conversation is hard to find. Perhaps this should continue in a fresh section of WT:GP?  --Connel MacKenzie 20:18, 4 November 2006 (UTC)

One idea is to create a web service, and host it on a server that can handle a very huge load. The web service can be backed up by something as simple as a Java servlet. This raises the question, what kind of web server and software is providing Wiktionary? The interface for the web service is published to the world (remember, simpler is always better), a few judicious operations are exposed (getMessageOfTheDay, getWord), each having a few judicious arguments (much like the search box is essentially one argument besides the language).

Can one of the system administrators or developers who is managing the servers on which Wiktionary runs be willing to discuss admitting new interfaces besides a web interface? Modern design now is concerned about rending the same information to a web browser, to a PDA, and through a web service. If you build, they will come, assuming it's simple and well done. --Caswick 02:28, 7 January 2007 (UTC)


 * Everything in the MediaWiki trunk is written in PHP. You can talk to developers directly at irc://irc.freenode.net/mediawiki or on the foundation Mailing lists.  --Connel MacKenzie 04:47, 7 January 2007 (UTC)


 * I just found out that a search API already exists, initially conceived August 2006: API/Wikimania_2006_API_discussion. Fortunately, this means you can get the word of the day directly, as in this example that returns in XML format (click to test:) .  For more information on the search API, see: API.  Note that to drill down to the actual day (instead of getting just the template "wotd"), you must supply the month and day as in "Wiktionary:Word of the day/January 15".  --Caswick 03:10, 16 January 2007 (UTC)
 * YES!! One step closer!!!--68.126.7.187 06:27, 18 January 2007 (UTC)


 * Ugh. You still have to parse templates from that point.  (Special:ExpandTemplates can probably just do  for you.)  --Connel MacKenzie 06:57, 18 January 2007 (UTC)


 * Please help test out http://tools.wikimedia.de/~cmackenzie/wotd-rss.php. Feedback is appreciated.  --Connel MacKenzie 05:42, 29 January 2007 (UTC)

More on classes for support of Unicode ranges
I had thought there was consensus that my proposal on classes for support of Unicode ranges should be implemented. I hope that moving it to a transcluded page does not mean it will receive even less attention than it has received recently. Implementing it would have three benefits: Wikipedia has a Template:Editprotected, which draws attention of sysops to a proposal to change protected pages. Maybe we need something like that here. --teb728 19:36, 16 June 2006 (UTC)
 * Solving the problem that IPA and some Old English characters are not displayed on IE6 in the edit & special chars box.
 * Imposing font lists only on IE6. (Presently they are imposed on all browsers.)
 * Enabling users to set their own font preferences and other personal styles for the classes.


 * I myself am hesitating because I was wrong on previous points. I had hoped that Hippietrail would correct them, as per your proposal.  --Connel MacKenzie T C 21:36, 16 June 2006 (UTC)


 * I'm sorry it took me so long. As you might know I'm travelling through Central America on a low budget and don't always have loads of Internet time every day. But I finally made the changes you suggested. &mdash; Hippietrail 19:11, 17 June 2006 (UTC)


 * Thank you, thank you, thank you! One more thing: I neglected to close the comment on Latin Extended-B for Mediawiki:Common.css; so please change " " → " --teb728 01:26, 18 June 2006 (UTC)


 * Ahhh. I got that one.  --Connel MacKenzie T C 05:11, 25 June 2006 (UTC)

bot approval policy?
Do we have a formal bot approval policy? I have a new bot, scsbot, that I should probably get approved. (Unless, of course, people want to see all its changes in recentchanges -- currently, adding Rhymes: entries to lots and lots of Pronunciation sections.) —scs 05:46, 17 June 2006 (UTC)
 * This is a very good example of how it works :-D. Ask on the BP. — Vildricianus 10:57, 17 June 2006 (UTC)
 * If that's a good example, I'd hate to see a bad one! :-) —scs 16:36, 17 June 2006 (UTC)
 * Meh, we don't have a BAG here. It makes life easier.... if it isn't gonna screw things up it's good :) -- Tawker 04:06, 14 October 2006 (UTC)

The new templates: implementation
Now they're here, hopefully to stay, how are we going about making them widespread, replacing the old templates, normalizing stuff across all English entries? I expect a bot is going to tackle the conversion from Uncle G templates to ? Any other ideas or concrete plans yet? I'm willing to do some manual stuff, but it'd be nice to have something automatically replacing things. Also, in a later stage, it'd be helpful if someone compiled lists of entries that have =Verb= statements but no (and same for nouns).

Secondly, is there any need for having a standard in which parameters should be filled in? Currently, there's the possibility to do either as well as. Should we prefer one over the other or doesn't it matter at all? Perhaps the bot could do this as well?

Furthermore, is any work being done yet about the adjectives? — Vildricianus 21:58, 17 June 2006 (UTC)


 * I have been working on a bot framework specialized for English Wiktionary. It is still a bit of a fledgeling, but it is able to traverse wiki lists like Special:Whatlinkshere/Template:en-verb, analyze each linked page, and recommend changes, including the normalization of inflection template parameters. I've been using it to assist my editing but I would hope, when I get its important features implemented, to give it a specific goal like "normalize calls to Template:en-verb". Of course, we still need to agree on the best syntax and I'll need to request bot status for it.


 * We should make a complete list, but I recommend that our normalized parameters for en-verb be the ones that are succinct and obvious. I.e., for English verbs like "itemizes" that drop their "-e", I think " " is the most obvious because it's not obvious that the "-e" actually drops in the other tenses. Rod (A. Smith) 22:32, 17 June 2006 (UTC)

Template problems
Hello techy people! I am having a problem with the inflection templates. I have always used en-noun|singular|plural, because I like the table layout. Recently the default output of this template changed changed, in line with the new inflection templates (or something). So I added the relevant lines to my monobook. But now the output of en-noun looks awful - the tables are tiny and cramped and appear right next to each other. Have I done something wrong, or has someone else?? Widsith 08:56, 18 June 2006 (UTC)


 * Oopsie, yes, that's wrong. There should be  instead of inline. When you have that, you still don't get the correct width for the table and cells, but that'll be in the template itself. I'll have a look. — Vildricianus 13:54, 18 June 2006 (UTC)


 * Solved. Correction: doesn't matter whether it's inline or block.


 * Note for Rod: the thing doesn't work when the class specifications are included within the table. It should be in an external  tag. See . — Vildricianus 14:07, 18 June 2006 (UTC)

Great, thanks – looks much better again now! Widsith 15:19, 18 June 2006 (UTC)

Thanks for fixing the styles, Vild! Should I still be looking into cell width/padding/spacing or is that resolved now? Rod (A. Smith) 17:41, 18 June 2006 (UTC)
 * No, the width was OK. At first I didn't understand what was bugging, but then figured out that the entire table needed to be included in the class specification. Also, I only tweaked . The verb template still needs the same treatment, but I'm kind of busy right now. — Vildricianus 17:51, 18 June 2006 (UTC)
 * OK. I applied your changes to Template:en-noun to . Please, anyone, let me know if pages using either template look different from your expectations. Rod (A. Smith) 18:18, 18 June 2006 (UTC)

StringFunctions
I may as well announce this widely: StringFunctions now appear to be available for Wikimedia projects, which means for example that now works correctly. Not necessary to use under_scores anymore for vandal names.

So far the announcement. One thing I find weird is that they don't work when the allegedly correct # syntax is used. Compare: — Vildricianus 21:53, 18 June 2006 (UTC)
 * http://en.wiktionary.org/w/index.php?title=
 * http://en.wiktionary.org/w/index.php?title=


 * I am very pleased to see this finally implemented. I'm doing my little happy dance, now.


 * Coinciding with those changes, apparently "Nogomatch" was changed to some other name, so that they don't have to mess around with the leading ":" sillyness in $1 anymore. Unless someone beats me to it, I'll reinstate Nogomatch to wherever the new name is, with whatever simplifications are needed.  We probably won't need to use buttons for this functionality anymore.  Yay!  --Connel MacKenzie T C 22:36, 18 June 2006 (UTC)


 * I have an explanation for the mysterious syntax of the "urlencode" function, but you're not going to like it. StringFunctions aren't actually installed. Instead, the syntax above is a lesser used "colon function". (Remember, don't shoot the messenger.) Rod (A. Smith) 01:26, 19 June 2006 (UTC)

Hrm. MediaWiki:Noexactmatch seems to be the new name...without the preceeding colon before the page name anymore? --Connel MacKenzie T C 07:32, 19 June 2006 (UTC)


 * Well, letting de.wikt: experiment first, I've now followed their lead (thanks Birdy!) and moved the page to retain the edit history. I do have plans on condensing that table of buttons (to not have buttons) but the urgency is quite small.  --Connel MacKenzie T C 15:45, 20 June 2006 (UTC)

Bot idea for Webbie
What about a bot checking for entries in Webster's 1913, and if positive, adding a reference to it in the corresponding Wikt entry? — Vildricianus 11:18, 19 June 2006 (UTC)


 * Various things can be done with Webster's 1913. Entries completely from Webster's are supposed to have  at the top to identify them as needing updating.  A bot task to add ===References=== would be nice.  A bot task to add missing etymologies would be nice.  Even though the general task of dealing with Webster's is on my todo list I hold no exclusive claim on it - I'd be delighted if someone else got to it before me.  --Connel MacKenzie T C 17:17, 19 June 2006 (UTC)


 * I would, if only I had more technical proficiency to run a bot. Then I would do the reference thing certainly. Bot-importing content would assist expanding Wiktionary, but is not recommendable. Etymologies perhaps, but not definitions. Anyway, that was not the topic. — Vildricianus 17:49, 19 June 2006 (UTC)


 * I think you are underestimating your own capabilities, with regards to http://sf.net/projects/pywikipediabot. Python runs on essentially all platforms that run web browsers...Windows (3.11, 95, 2k, Me, XP etc.), *nix, Macs, VAX/VMS, S/360.  If you're not running one of those, I'd be quite interested in knowing how you are posting anything here at all!  --Connel MacKenzie T C 18:57, 24 June 2006 (UTC)

Etymology templates

 * Transcluded. — Vildricianus 18:53, 23 June 2006 (UTC)

Grrr
I am having some display problems, which seem to be linked to a discussion happening further up this page about Unicode characters, a discussion which I don't fully understand.

I have always used Template:Unicode to display bold characters with macrons. Thus: ā ē ī ō ū. This is because just putting them in bold looked rubbish (a blurry on-the-fly boldening). Recently User:TEB728 changed all these to Template:Latinx for some reason. The result for me is that bold ǣ no longers displays as bold. And now Template:Unicode has apparently been changed as well, so that the bold characters with macrons look horrible – i.e. they look the same as they do without the template. Also, Template:IPA seems to look worse than it did before (more cramped). What is going on?? I'm using mainly Safari, also Firefox. Widsith 08:16, 21 June 2006 (UTC)


 * Whatever's been done, please don't reverse it without thinking. For the first time, I can see all IPA characters in the "special characters" box (though still not in the edit box). Enginear 13:05, 21 June 2006 (UTC)


 * Enginear, see if you can find a font on your system that gives good coverage of IPA characters--very preferably a monospaced font. If you find one you want to use for the edit box, enter font name in your monobook.css. --teb728 02:01, 22 June 2006 (UTC)


 * Clear your cache. Do you still have the problems? I see the above things in bold. — Vildricianus 15:25, 21 June 2006 (UTC)


 * Widsith, try the change I just suggested on my talk page. (Actually a change I just put in may have made my previous suggestion work.) --teb728 22:23, 21 June 2006 (UTC)


 * Hurrah, that's much better. Vil – FWIW, I was seeing the characters above in bold, but not ‘proper’ bold - it was all blurry and rendered on the fly, rather than having clear separate macrons.  Anyway, all better now.  Widsith 07:57, 22 June 2006 (UTC)

Magically appearing links
I have just added a comment to Beer parlour, which included the phrase "(say from RFC 1024 )" with no linking.  RFC 1024  had been used (and internet-linked) by someone else above, and my occurence magically became a link, both in the preview and the saved edit, even though there is still no link in the raw text. It's doing it here too. I've opened another instance of Wiktionary (not logged in) and it appears there too. Do you see it, or is it just my computer? Is this a known "feature"? Enginear 13:18, 21 June 2006 (UTC)
 * Looks like a feature of wiki magic. Davilla 15:11, 21 June 2006 (UTC)
 * Indeed. See http://www.mediawiki.org/wiki/Manual:RFC and the related http://www.mediawiki.org/wiki/Manual:ISBN. —scs 16:23, 21 June 2006 (UTC)
 * MediaWiki:Rfcurl. — Vildricianus 10:52, 22 June 2006 (UTC)
 * Also MediaWiki:Pubmedurl. PMID 1  --Connel MacKenzie T C 14:14, 22 June 2006 (UTC)
 * And ISBN 000000 of course. — Vildricianus 14:17, 22 June 2006 (UTC)

Category:Old anonymous user pages
We should get rid of the practice. It's unnecessary I think. We could use a bot like w:User:Tawkerbot to blank stale IP talkpages. — Vildricianus 21:15, 23 June 2006 (UTC)


 * I agree. That experiment got a bit out of hand...even if it was useful in developing "the" method of categorizing pages by date.  Not needed anymore, I do agree.


 * Should we just kill off the user talk pages over 1 year old? I think if the user has has not contribs in a year, they'd almost expect us to have forgotten about them, right?  (Then again, should we keep some from 2003? :-)  --Connel MacKenzie T C 05:17, 25 June 2006 (UTC)

WT:RFC
There's a backlog here, growing more rapidly than shrinking I think. I'd propose to deprecate the entire page, and instead use the category solely. Explanations can be given through the template as parameter 1, and discussion can go on the talk pages. Ideas? — Vildricianus 22:03, 23 June 2006 (UTC)


 * A lot of people check the WT:RFC page to find out about what needs attention. It is a pretty useful chat area.  With the method you suggest, there is no easy way of finding which ones have activity.  Is there?  Can DynamicPageList add a transclusion for each talk page?  Even if it could, it still wouldn't show the history of which one(s) had recent activity.  I don't think we're ready to nix WT:RFC just yet.  --Connel MacKenzie T C 16:41, 2 July 2006 (UTC)

Search special page correction
This comment may not be appropriately categorized, but it is unclear where to place it. On the search special page that appears upon entering a nonexistent page name in the search box and pressing the go button, the entry template table contains two periods after non-sentences: "Expert blank template" and "When she crosses". I would correct these errors myself, but I can't edit special pages. The periods should be removed. 24.5.197.121 06:48, 24 June 2006 (UTC)


 * MediaWiki:Noexactmatch right? We've had significant trouble trying to transclude User Interface things like this to user namespace editable templates, in the past.  As I disagree with your assessment, I'll let someone else change it.  :-)
 * The mechanism for doing the preload templates has always been necessarily goofy - but with the recent addition of new MediaWiki syntax, this has the potential of being simplified to normal Wikilinks, instead of the strange-looking input box buttons. In fact...I think I attempt that now...
 * --Connel MacKenzie T C 18:48, 24 June 2006 (UTC)


 * Status: does not work.  At all.  --Connel MacKenzie T C 19:19, 24 June 2006 (UTC)


 * Are you sure? We need a place to test it without disrupting Noexactmatch. — Vildricianus 19:30, 24 June 2006 (UTC)
 * Bah. does what it has to do: it encodes "$1" into %241 instead of encoding the parameter... Can anyone think of a dirty trick to avoid this? — Vildricianus 20:07, 24 June 2006 (UTC)
 * Have you tried where Template:newtemp contains  ? --teb728 22:22, 24 June 2006 (UTC)
 * Doesn't work. Newtemp contains %7B%7B%7B1%7D%7D%7D. Urlencode is too strong, it just encodes  . — Vildricianus 22:27, 24 June 2006 (UTC)

To summarize: we need to edit $1 using a preloaded template. The closest I got thus far was using /w/index.php?title=:$1&action=edit&preload=Template:new_en_basic, which works for single words but doesn't allow multiword entries. Multiword entries like just this need to become just_this or just+this, which would be done by. doesn't work, though, which is the problem

Quite close again was /w/index.php?title=: &action=edit&preload=Template:new_en_basic, but not good enough either. — Vildricianus 22:38, 24 June 2006 (UTC)


 * Oh, I forgot to try using $1  ...or whatever the trick was in the page you see after moving a page.
 * Nevermind. Didn't work.  --Connel MacKenzie T C 23:12, 24 June 2006 (UTC)


 * OK, how about where Template:newtemp contains  ? Essentially that works as expected at User:TEB728/temp2 --teb728 23:35, 24 June 2006 (UTC)


 * Result: we end up editing " ", which gives an error. — Vildricianus 10:46, 25 June 2006 (UTC)

Can't we try to use javascript magic via MediaWiki:Newarticletext? — Vildricianus 10:55, 25 June 2006 (UTC)


 * Hrm. Well, conceptually, I'd really prefer to have it all "happen" on the page where it is happening.  Javascript is notoriously poor in "lynx" browser; this is a good check (for me at least) of what sort of things should be happening server-side vs. client-side.  In the example you list above, $ lynx http://en.wiktionary.org/wiki/buenos_Aires lists the link to Buenos Aires even though the Javascript magic doesn't happen.  But right now (surprisingly,) the table of preload templates does appear for lynx.  And it seems to function correctly!  --Connel MacKenzie T C 05:41, 27 June 2006 (UTC)

rfvpassed merge
Can someone merge Category:Survived verification with Category:RFV result as per the annexed discussion?
 * Here's a system predating yours: Category:RFV result with Template:rfvResult. Could you merge some stuff or else delete it? Failed RFVs should be in Requests for verification/archive, right? Cheers. — Vildricianus 16:07, 22 June 2006 (UTC)

Many thanks. Andrew massyn 18:50, 24 June 2006 (UTC)


 * No bot needed: just edit, then wait 5 minutes, right? --Connel MacKenzie T C 19:02, 24 June 2006 (UTC)

Strange problems with non-breakig spaces in
Please see the discussion in the template's talk page, and look at computer for an example. &mdash; Hippietrail 02:38, 28 June 2006 (UTC)

Wiktionary:Project- pseudo namespace
Something about this naming convention has bugged my subconscious for a long time now. "Project" in all of Wikimedia software, is the main name of the wiki-flavor. Here, "Project" is translated (via LocalSettings.php) to be "Wiktionary". On our sister projects, it is, for example, "Wikipedia" or "Wikisource" or "Wikibooks" or "Bugzilla" etc.

If the "normal" translation rules were applied to these, they'd become "Wiktionary:Wiktionary-Nogomatch" (for example.) I think we should be avoiding the "Project" keyword a little more diligently.

The purpose of this pseudo-namespace is to allow autoconfirmed users access to MediaWiki user interface stuff...to make minor edits whenever needed. For only a small number of things, is this appropriate.

Recent software changes have made template transclusion somewhat more problematic for the MediaWiki namespace. Perhaps we should rethink our general approach?

--Connel MacKenzie T C 04:44, 29 June 2006 (UTC)


 * I don't like the idea of having these pages editable for everyone. Enough technically proficient sysops around. If people want to propose changes or discuss the matter, they should do so here. — Vildricianus 08:31, 29 June 2006 (UTC)

Moving of indexes
Now the Index: space is here, we'd better move all Wiktionary:n index pages to Index:n. I've done the first few already, but it's a boring job. I came up with the practice of putting letter pages like Aragonese index e at subpages like Index:Aragonese/e, which I guess is a good practice. However, if someone could come up with a bot or a script to do this... Look at the Chinese and Finnish indexes, that's a lot of moves to make. — Vildricianus 19:46, 29 June 2006 (UTC)
 * Most moving done now... Chinese and Finnish remain. — Vildricianus 15:21, 1 July 2006 (UTC)

Template:subpages
Small announcement: is a very nice trick to make maximal use of the subpage system via Special:Prefixindex. Example for this page:  Fine, works, but let's not overuse it. — Vildricianus 14:16, 5 July 2006 (UTC)

That is, until the Subpages extension is available. — Vildricianus 16:33, 30 June 2006 (UTC)


 * Brion taught me an even better trick, look now. Too bad there's a line break at the beginning, but it's still highly usable. — Vildricianus 10:26, 2 July 2006 (UTC)


 * Note. If you use it on a talk page, you get talk pages of all subpages of the article, not all subpages of the particular talk page. SemperBlotto 10:38, 2 July 2006 (UTC)


 * That's how talk pages of subpages work in general. User talk:SemperBlotto/100 random pages is both a subpage of User talk:SemperBlotto as the talk page of User:SemperBlotto/100 random pages. The case is further complicated by the absence of subpages in the main namespace. Talk:and/or is considered to be a subpages of Talk:and, while and/or isn't a subpage of and. — Vildricianus 10:52, 2 July 2006 (UTC)

This template seems to rely on the fact that the "live" special pages (not the ones updated through the maintenance scripts being run by the devs) are capable of being transcluded. ,, , , all generate the desired results. Not very useful now (except for this template), but perhaps later on. — Vildricianus 11:01, 2 July 2006 (UTC)

Newarticletext redirection
I can't find the previous conversation about uppercase/lowercase auto-redirecting, so here goes.

MediaWiki:Newarticletext has some magic in it to automatically display case variants with "Did you mean...". The nice thing, is that when Monobook.js sees that, it slams the user over to the search page as if they just pressed the [Go] button.


 * NOTE: This does not happen for internal links, only for external links.

I got some positive feedback recently, that it suddently started working (when I fixed a particular typo.)

Mentioning it to Brion, he noticed an exploit (a la WoW) and suggested I lock it down a bit. I've done that, but would appreciate people testing it with various browsers, and reporting back here with the ones that don't work (besides 'lynx'.) Note also, this is for (the default) Monobook skin only. Other links coming from outside won't have a registered user (nor their cookies) set, so it shouldn't matter, for the other skins.

Buenos Aires - buenos Aires - http://en.wiktionary.org/wiki/buenos_Aires

Thanks in advance, --Connel MacKenzie T C 07:25, 1 July 2006 (UTC)


 * What we will need in order to let this work efficiently is something that allows users to quickly go to the lower/uppercase version when on an upper/lowercase page. The only way to go and define buenos Aires is by using a red link - the Go function automatically finds the uppercase page, and urlbar typing auto-redirects. Some fiddling with the sidebar or toolbox may help here. The desired thing would be to have a link to http://en.wiktionary.org/w/index.php?title=buenos_Aires&action=edit on the page for Buenos Aires. — Vildricianus 11:06, 2 July 2006 (UTC)


 * I've always used to give me that link - and all such entries are supposed to have that template on line one.  I agree that that method is not obvious, but I don't see a way of doing it otherwise, without interfering with dictionary readers use of Wiktionary.  --Connel MacKenzie T C 15:45, 2 July 2006 (UTC)

Slow grease pit?
Has anyone else noticed that this page seems to load noticiably slower than other similarly sized pages? --Connel MacKenzie T C 17:33, 3 July 2006 (UTC)
 * There is no page of this size. I'll calculate its size and report back. — Vildricianus 17:42, 3 July 2006 (UTC)
 * It's only 285 kb. The BP has been bigger at times. — Vildricianus 17:53, 3 July 2006 (UTC)

Wiktionary User Preferences redux
Now that the cookie for the Edittools seems to be working well, can we consider using cookie for all general preferences? I've thought about adding a tab (via Javascript) to Special:Preferences, but the more I think of it, the more that seems like a Bad Idea. If we keep Wiktionary preferences entirely separate in something like Preferences (with perhaps a conspicuous link to it, from Special:Preferences) we would stand much less chance of interfering with base Wikimedia software, and be less sucesptible to bugs introduced by upgrades.

To use cookies for preferences seems much less harmful than trying to auto-edit people's Monobook.js/Monobook.css. My concern with that method is that I'm not sure how dynamic CSS is.

For each preference via cookie, I see three possibilities: System default, On or Off. MediaWiki:Monobook.js could then have a Preferences cookies section, exiting immediately if no cookie preferences are set, then for each cookie, using document.write(s) to load either the "on" or the "off" css (or skipping if set to system default.)

Of course, this would need a moderately elaborate bit of Javascript for the preferences page itself (to create the widgets for setting the different cookies.) There should also be a "master" cookie the "use preferences" vs. "use all system defaults."

Naming conventions: verbose. WiktionaryPreferencesMaster, WiktionaryPerferencesSerialComma, WiktionaryPreferencesInflectionTables, WiktionaryPreferencesSeeAlsoIndented, etc.

This seem coherent? For each WT:CUSTOMization, we'd need e.g. MediaWiki: Preferences/SerialComma/on.css and MediaWiki: Preferences/SerialComma/off.css (unless someone thinks of a better naming convention.)

Once this aspect of it all works, we could then start bringing the ugly foriegn language conjugation tables into the fold.

Comment please, or I'll start being bold! --Connel MacKenzie T C 18:00, 3 July 2006 (UTC)


 * I'm excited about simplifying Wiktionary personalization, but a bit disappointed that the best approach (the cookie-based one) will lose preferences when users change clients. Is that a significant concern or should I lower my expectations? Rod (A. Smith) 05:21, 4 July 2006 (UTC)


 * I seriously doubt this is anywhere near "the best approach." Better would be the thing that User:Scs was talking about doing.  Better than that, would be to have an extension.  Still better would be to have all the cutomizations we want, built into the Wikimedia software.  Even better than that, would be to have bonafida dictionary software with super custom stuff needed for dictionary building.  One important thing I should remember, as I proceed is that nothing I do with regards to this should be "set in stone," but instead should be as flexible as possible.  --Connel MacKenzie T C 03:31, 5 July 2006 (UTC)


 * Which "ugly foriegn language conjugation tables" ?? Talking about mine? — Vildricianus 09:41, 4 July 2006 (UTC)


 * I don't run across them often, but November/December 2005 I started seeing a lot of table-oriented conjugation tables, so I don't they are yours. Have you added similar ones?  --Connel MacKenzie T C 01:42, 5 July 2006 (UTC)


 * These are all mine, yes. — Vildricianus 08:35, 5 July 2006 (UTC)


 * No, I was thinking of the Spanish conjugation templates. --Connel MacKenzie T C 07:30, 7 July 2006 (UTC)


 * A couple of considerations:
 * 1) On Wikipedia (I presume Wiktionary is the same) not all skins have JS files. So they had to back off from an improvement to Edittools that required JS support. If your change is only an enhancement rather than a vital feature, perhaps it would be OK not to support all skins. (Or perhaps most Wiktionary users use Monobook.)
 * 2) I hear they are developing a common WiktionaryZ to replace the various xx.wiktionarys. The prospect of conversion may limit the amount of work you put into the user interface. --teb728 04:06, 5 July 2006 (UTC)


 * From what I know, only Eclecticology uses something else, but I don't understand why as there's simply nothing worse here at Wikt than using a different skin than the default one. Our pages look horribly incomprehensible on anything else than Monobook.


 * No, WiktionaryZ isn't meant to replace any Wiktionary. Besides the fact that it may last quite some time before WZ is online and workable, I don't see it replacing en:wikt for a couple of years, if ever. — Vildricianus 08:35, 5 July 2006 (UTC)


 * But TEB728 has an excellent point: we probably shouldn't be operating in a manner to make the other skins "more broken" than they already are. We may need to revisit the concept of moving the contents of Monobook.js to Standard.js or Common.js (or wherever it is, that it truly belongs.)


 * Wikipedia:Catalogue of CSS classes lists the JS files activated for the various skins on Wikipedia. It shows that for the Standard, Cologne Blue, and Nostalgia skins, http://en.wikipedia.org/skins-1.5/common/wikibits.js is the only JS file activated (except for user/ files). And inasmuch as wikibits.js is outside the namespace system, changes to it are probably not preserved. (Mediawiki:Cologneblue.js exists but is not activated.) --teb728 23:16, 5 July 2006 (UTC)


 * I see WZ as a complementary project focusing more on translations, while Wiktionary will focus more directly on definitions. But we'll see how that all pans out.  I agree that systemic changes seem years away.


 * So far, great comments. Should this experiment be started soon?  I've noticed that no one has chosen to be bold yet...  --Connel MacKenzie T C 15:24, 5 July 2006 (UTC)


 * Starting Being Bold at User:Connel MacKenzie/monobook.js --> User: Connel MacKenzie/custom.js + User: Connel MacKenzie/Preferences. Initial tests show that the Javascript document.write will do the CSS tricks I was looking for, conditionally on a cookie.  The bad news is that I can't figure out a decent way to set the cookies on the Preferences page.  (I used a known cookie for my preview tests.)  Any ideas?  There must be some way to put radio buttons or a selection box on a MW site's page.  Anyone?  --Connel MacKenzie T C 06:50, 6 July 2006 (UTC)
 * Um, nevermind. I'll just use, which may solve it. Anyone else sees undesired results? — Vildricianus 08:30, 17 July 2006 (UTC)

Swahili noun inflection line template
We have a new template, Template:sw-noun, created from Template:en-noun. (So give Rodasmith most of the credit.) There is documentation on the talk page and examples of usage linked from there.

Swahili (like other Bantu languages) has noun classes, and forms plurals by changing the prefix. So there is (e.g.) an M-WA class, singular mtoto, plural watoto. There are also many nouns that are not classed and don't have plural forms; the same word is used: mbuzi goat, mbuzi tatu three goats. And there are a few irregulars.

Robert Ullmann 12:15, 18 July 2006 (UTC)


 * Is there any way to have it not insert a line ending? I like to include a noun-class remark on the same line, but the template includes a line ending which prevents this. I’d like to write, for example:
 * ada (plural: ada) (nc 9/10)
 * but the template breaks it into two lines (see kitabu). I looked at the template to see if I could fix it, but it’s too complex for me.
 * Also, it would be very useful (and simple) to have the template add to the file. —Stephen 18:25, 18 July 2006 (UTC)


 * Some editors like their headword/pos/inflection templates to apear in a table instead of on a line. This template and the English templates support that desire by showing whichever format the editor configures in his or her style sheet. Unfortunately, wiki tables require subsequent text to move to the following line.


 * Regarding the pos class, I'd love to see it in the template, but EC reverted my adding of Category:English nouns to the English noun template, so I took that to mean that such categories are not wanted. I'd welcome discussion (probably best in WT:BP) about whether that is the general consensus or whether language-pos categories are acceptable. Rod (A. Smith) 19:02, 18 July 2006 (UTC)


 * It’s not that categories are not wanted, but he probably reverted it for two reasons: (1) for foreign words, we have to indicate "Swahili noun", "Russian verb", etc., but for English, since this is the English wiki, we only need write "Noun", "Verb", and so on; (2) but the main reason, I’m sure, was that, this being the English wiki, the number of "Nouns" will be in the hundreds of thousasnds, which is really too many for a category. Eventually this will be the case for many foreign languages as well, once we have many entries, and then we’ll need to remove the "Category:Xxx nouns" in favor of more specific categories. Having this placed in a template will make it very easy to remove the category at a later date; at the same time, adding such categories to templates, even temporarily, facilitates searches for terms that you wish to select for narrower categories, after which the broad "Noun" category can be removed again. When you have to search through hundreds of minor subcategories, many deeply embedded, to find terms for your category project, it’s really impracticable.
 * But in the short term, the number of Swahili nouns will be small, and a noun template is a tremendous help.
 * As for headword/pos/inflection tables, I really don’t know what to do with Swahili nouns. I suppose I could just indent the second line and let it go at that:
 * ada (plural: ada)
 * (nc 9/10)
 * —Stephen 21:02, 18 July 2006 (UTC).


 * What is the reference for the numbers you are using? All of the references I have call the classes M-WA, KI-VI, N, etc. Is there some standard? And how is 7/8 somehow more helpful than KI-VI (which is apparent?). There is some numbering used in various course material, but mostly it is copied from other course material. And isn't consistant. Robert Ullmann 22:11, 18 July 2006 (UTC)

Shakespeare and Bible template
While I don't know how to write a template, I use them and see what they can do. I suggest a KJV bible and Shakespeare template. The interesting thing is what they could do for piped categories.

would generate as part of supercat

would generate category

would generate

These last two would be in supercat

And considering how much the Bible and Shakespeare are quoted, one could set a robot to collect all the references for scrutiny, and then set another robot to add the template, very nicely filling up a category.

I suspect someone would have to pre-create the categories for all the Shakespeare books, and all the books of the bible.--Allamakee Democrat 00:49, 19 July 2006 (UTC)


 * I like the end result of what you suggest: i.e. almost like an automatically-orderd concordance of Shakespeare and of the Bible books. I would suggest that the template also output the text for the book/chapter/verse/act/scene as well, e.g.:
 * The above would produce this:
 * a place of residence for nuns
 * 1601: Shakespeare, Hamlet Act 3, scene 1
 * Get thee to a nunnery, why wouldst thou be a breeder of sinners?
 * (Example picked at random&mdash;I am not picking on nunneries; I hear they can be quite lovely) As you say, it would also categorize the term ("nunnery" in this case) into Category:Hamlet indexed by the act and scene. Rod (A. Smith) 01:29, 19 July 2006 (UTC)
 * It occurs to me this might leave a lot of redlinked cats, but a robot could manage this too (or is this a part of the magic of a template?). But yes, a concordance, which, with time, leads to further wikiverse works. I do understand categories. --Allamakee Democrat 02:06, 19 July 2006 (UTC)
 * Get thee to a nunnery, why wouldst thou be a breeder of sinners?
 * (Example picked at random&mdash;I am not picking on nunneries; I hear they can be quite lovely) As you say, it would also categorize the term ("nunnery" in this case) into Category:Hamlet indexed by the act and scene. Rod (A. Smith) 01:29, 19 July 2006 (UTC)
 * It occurs to me this might leave a lot of redlinked cats, but a robot could manage this too (or is this a part of the magic of a template?). But yes, a concordance, which, with time, leads to further wikiverse works. I do understand categories. --Allamakee Democrat 02:06, 19 July 2006 (UTC)


 * Hmmm. So category:Hamlet would be a subcategory of category:Shakespeare?  I thought we had something like category:Shakespeare already, somewhere?


 * We do have category:Books of the Bible already - the book categories, as you suggest, might fit nicely as sub-categories. But, why are we concerned suddenly with categorizing quoations?  Would we upset anyone over at Wikiquote:?  Or is this meant as a method of syncing Wiktionary/Wikiquote?


 * I guess I'm unclear on the concept. --Connel MacKenzie 02:13, 19 July 2006 (UTC)


 * Isn't a nunnery a whore-house? --Connel MacKenzie 02:14, 19 July 2006 (UTC)


 * This is Beer parlour, not Grease pit material.


 * I've had this idea long time ago, and deemed it useless. We're not wikiquote, and the quotes we use are used to illustrate our entries, not provide quotes for the sake of quotes. If people want to find all quotes from Hamlet or the Authorized Version, they can find them through Special:Whatlinkshere/Template:RQ:Authorized Version. Quotes should appear in great quantity on every page, so categorizing them is a bit like categorizing English nouns, or arguably much worse. It's also quite pointless when the quotes are on subpages. Furthermore, if people want Hamlet quotations, they're better off reading the play rather than browsing through a huge category here. — Vildricianus 09:18, 19 July 2006 (UTC)


 * See also Template:Shak.. — Vildricianus 09:21, 19 July 2006 (UTC)

Transwiki to commons:
Do we transwiki to commons:? I.e. Special:Unusedimages? --Connel MacKenzie 02:18, 19 July 2006 (UTC)

Automated requests for cleanup
As I'm adding headword part-of-speech / inflection templates to entries, I often encounter words whose key inflected forms I do not know. For various reasons, I cannot always research the inflected forms properly as I'm performing my cleanup review, but adding the term to WT:RFC seems like a bit too much overhead for everyone.

So, as an experiment, I created Category:Nouns with undetermined plurals as a subcategory of Category:Requests for cleanup. I'm not sure that's the best approach, though. Can anyone think of an improved way to manage our cleanup efforts? Rod (A. Smith) 03:09, 19 July 2006 (UTC)


 * RFC is in the process of being automated, or at least partially. See Requests for cleanup/List. — Vildricianus 09:08, 19 July 2006 (UTC)


 * Could you have   add it to that category?  --Connel MacKenzie 16:58, 20 July 2006 (UTC)


 * In fact, adding a parameter with the value "?" for param 1 or 2 (or 3?) should simply add  ? . Right?  --Connel MacKenzie 17:04, 20 July 2006 (UTC)


 * In the interests of KISS, perhaps a named parameter would be better; q=? or something? Then it could be added to the other inflection templates in a uniform manner.  --Connel MacKenzie 17:07, 20 July 2006 (UTC)


 * Nice. Unless anyone objects or comes up with another solution, I'll plan to implement that. Rod (A. Smith) 19:11, 20 July 2006 (UTC)

WOTD update on main page?
What updates the word of the day displayed at http://en.wiktionary.org/wiki/Main_Page? It seems to be showing yesterdays entry at the moment. RJFJR 12:39, 20 July 2006 (UTC)
 * Have you emptied your cache? I see what seems to be today's word, and it should be, as it is automagically updated (through some clever template tricks) :) \Mike 13:19, 20 July 2006 (UTC)


 * Note also, that the day "boundary" is GMT/UTC. --Connel MacKenzie 16:56, 20 July 2006 (UTC)

Tooltips for standard headings
I've just hacked up a proof of concept JS function at User:Hippietrail/headingtooltips.js to add more detailed information to level-3 Synonyms headings as exists for standard Monobook elements like the tabs and navigation bar entries.

A proper solution needs to ignore the heading level and build a list of all h3, h4, and h5 headings. It then needs to iterate through them and for each in the set of standard headings, add a standard tooltip text. For all other headings it should add a text saying "This is not a standard Wiktionary heading" or somesuch.

A very good solution would make use of document.write to get the texts from the MediWiki: namespace where all could be edited and improved by anyone.

A fantastic implementation might make use of something akin to MediaWiki:Sidebar (MediaWiki:StandardHeadings) to store the list of standard headings and associate them with a MediaWiki namespace page containing the tooltip text.

Note that most of this could also be achieved by turning all standard headings into templates including HTML TITLE fields. I'm assuming this solution would be less popular.

Why is this needed? Because it's classy; makes Wiktionary UI elements more like Wiki UI elements; helps users to learn the difference between Derived terms, Related terms, and See also; and helps to clarify more advanced new headings to come that deal with inherited or borrowed terms in ways not easy to make clear in a succint heading label alone. &mdash; Hippietrail 23:06, 20 July 2006 (UTC)


 * As a complement to this proposal, how about we add another Edittools section that spits out valid headings? --Connel MacKenzie 00:07, 21 July 2006 (UTC)


 * Personally I feel that Edittools is going through successive waves of bloat and that some other UI element should be developed for things like templates and headings as well as trimming down the number of standard alphabet sections and making the others personalizable through creative use of document.write, the MediaWiki: namespace, and a further file similar to MediaWiki:Sidebar.
 * But that all can come later with Edittools being used as a stopgap. &mdash; Hippietrail 00:28, 21 July 2006 (UTC)


 * Please fill out the list. Things like ===Verb=== show up as not being standard headings, last time I looked.  --Connel MacKenzie 05:54, 23 July 2006 (UTC)


 * Verb is handled. The variations that have been deprecated are treated as nonstandard. The code is clear and easy for at least us techs to edit so please give it a go. It's inevitable that I won't think of everything. &mdash; Hippietrail 06:07, 23 July 2006 (UTC)


 * Currently everything but h2 shows up as being non-standard headings. — Vildricianus 10:43, 23 July 2006 (UTC)


 * It works for me in Explorer, FireFox, and Opera on 2 different Windows computers. Have you refreshed your cache? Which OS and browser? Can you cite me a specific article and specific headings? &mdash; Hippietrail 11:05, 23 July 2006 (UTC)


 * It is the "auto-number headings" option in Special:Preferences which makes it work/not work. When it's on, it doesn't work. — Vildricianus 11:21, 23 July 2006 (UTC)


 * Aha! Thanks. I'm on it... &mdash; Hippietrail 11:48, 23 July 2006 (UTC)
 * Please try the new improved version and let me know your success. &mdash; Hippietrail 13:09, 23 July 2006 (UTC)


 * Success confirmed. — Vildricianus 13:57, 23 July 2006 (UTC)

Preferences now working
Much thanks to User:Rodasmith for JS debugging.

Everyone can now set their preferences at:


 * User:Connel MacKenzie/Preferences

and the technically inclined can add more things from WT:CUSTOM to User:Connel MacKenzie/custom.js.

--Connel MacKenzie 03:31, 21 July 2006 (UTC)


 * Addendum: with Brion's nagging, I figured out the remaining missing puzzle pieces; now all functions work as advertized. You do not need to be logged in.  Cookies are browser specific, and are not saved to your Special:Mypage/cookies file at this time.  --Connel MacKenzie 05:42, 21 July 2006 (UTC)

Category delete mini-flood
First note - I'll be damned, no wonder I couldn't find my Old Prussian template discussion anywhere ... I keep confusing this page with the Beer Parlour. Now, what I was going to say -- heads up to you all, I'm going through the list of orphan categories as best I can and cleaning it up, either categorising them, or, in the case of empty ones that have been moved to other places, creating a 'mini-flood' of deletion nominations. (Just wanted to let you know so that no one mistakes it for a spam flood.) Beobach972 03:52, 23 July 2006 (UTC)
 * PS- you know how Latin interjections go in Category: la:Interjections? Could one of you find out what two-letter-code I should use for Kurdish, so I can do the same with those entries? Beobach972 03:57, 23 July 2006 (UTC)


 * http://www.wiktionary.org/ says it is "ku" as does Wiktionary (for future reference, and anyone else reading this, wondering the same thing.)


 * Regarding the mass 'category clean-up;' go for it, please! --Connel MacKenzie 05:35, 23 July 2006 (UTC)
 * Be aware of Template:catred tho.

CSS to hide wikification?
I had an interesting question posed on my talk page, regarding http://www.yawiktionary.com/. Reviewing that site, it occurs to me that I've heard that complaint before (over wikification/why not give subtle links to all terms.)

Could someone please work out a WT:CUSTOM thing to dewikify (or at least make terms appear to be dewikified) all terms on a page? If someone works out the CSS, I'll add it to User:Connel MacKenzie/custom.js.

When things quiet down next month, I'll write a JS function to hyper-link all terms on the page (via right-click?) and add that to the user preferences thing as well. (Of course, Rod or Scs may just write it long before I get around to it; who knows?) This is not meant as a snub to yawikt, on the contrary; it is something we should have done a long time ago when people first asked for it. Of course, even with that JS, there is no way to tell if the word is defined in Wiktionary, so the yawikt will still have that advantage (and others.) But it is still something that is good enough for us to emulate, I think.

--Connel MacKenzie 05:51, 23 July 2006 (UTC)

suggested improvement for categories
If a category contains less than 200 words, the exact number of words in the category is displayed (ex. Category:100_English_basic_words contains 99 entries). However, if the category goes over 200 words, you're out of luck. For example, Category:1000_English_basic_words currently contains 722 entries, but you are only told that it contains 198 entries. In order to find out the true number of words in the category, you have to click on "next 200" until you get to the end (and then add everything together). Is it possible for someone to remedy this? My preference would be something like "200 - 400 of 722" A-cai 18:16, 26 July 2006 (UTC)


 * This is a known bug I've wanted fixed for a long long time. &mdash; Hippietrail 18:37, 26 July 2006 (UTC)


 * We could JavaScript a link to the toolserver tool (that actually works) to fix this. Vild?  --Connel MacKenzie 18:46, 26 July 2006 (UTC)


 * Next lifetime, when I have spare time, for my spare time, I'll add the link for http://tools.wikimedia.de/~voj/cgi-bin/cocat?wikilang=en&wikifam=.wiktionary.org&cat=*Topics somewhere userful. In the meantime, please bookmark this tool.  --Connel MacKenzie 21:36, 26 July 2006 (UTC)


 * Perhaps the code used to generate the number of members in Special:Categories can be reused for this purpose.

A-cai 23:00, 26 July 2006 (UTC)


 * That suggestion needs to be added to 1212 at some point. I like it a lot.  --Connel MacKenzie 19:24, 28 July 2006 (UTC)

zh
On zh wikt:, it has both "login" and "signup" links on the top right, when logged out. Anyone know where that magic hides here? --Connel MacKenzie 21:25, 26 July 2006 (UTC)

Latin template orthography
I noticed today, as I was creating entries (eg ocare) using the Latin templates, that they do this : present ocō infinitive ocāre  perfect ocāvī  supine ocātum Problem is, they do it exactly like that -- they include the macron marks in the link! Now, the macron marks are supposed to be included in the appearance, to show stress, and so forth, and so on, that is proper form. However they are not supposed to be included in the actual link. (It is the difference between ocō (bad), and ocō (eg ocō - good).) Anyone know how to make this work correctly? I'd like to get it to work and have it link to the non-macron form like it's supposed to, and still show the macron in the link - anybody know how to revise the template to do that? Or do we have to resort to just not including the macron at all? Beobach972 21:14, 28 July 2006 (UTC)


 * PS- I always confuse this place with the Beer Parlour, so if I'm asking this in the wrong place - sorry. Beobach972 21:14, 28 July 2006 (UTC)


 * I noticed the same problem some time ago, and have been formulating how I would like the issue resolved. I have actually just finished drafting specifications for the proposed new  template.  They are on the talk page for the grossly insufficient version of the template I set up as a starter.  I do not have the technical expertise to write the required template, but believe I have clearly laid out the techincal requirements with enough samples that someone totally ignorant of Latin (but skilled in template writing) could do the job now.


 * Part of the probelm with the current set of templates in Latin is that there are too many of them. There are about a dozen noun templates, and a hideously large number of verb templates.  I hope someone can help consolidate them, the way Rodasmith did for the English templates.  Once the nouns are done, the adjectives, pronouns, and adverb templates will be a piece of cake.


 * The verb templates are considerably more difficult, not the least reason is that there are four principle parts of each verb, and all textbooks list them in a standard order and they are called the "first principle part" and so on. All of the current verb templates list the four parts in a different order, so I get horribly confused every time I try to enter a new Latin verb entry (which is why I have avoided doing them much thus far).  Latin verbs also have more bizarre irregulars than nouns and other parts of speech do.  Worse, I don't understand verbs to the degree I would need to to write up specifications the way I have done for nouns.  I hope we can fix the verbs too, but I think the other parts of speech would be better handled first. --EncycloPetey 04:29, 30 July 2006 (UTC)

Extension to split and link to components of multi-word entries
The syntax for the inflection line of multi-word entries is cumbersome. It looks something like this:

Better would be this:

String functions are unavailable here, so I created a tiny MediaWiki extension that does the work for us. Its syntax is this:

If it were installed on English Wiktionary, the above tag on this page would produce this:
 * Grease pit

To install it here so it can be used by and other inflection templates,   would need to be copied into English Wiktionary's   directory and loaded from , i.e.:

Does this sound like a good thing? Should I add the (trivial) change that would make it also split up dash-separated components, e.g. "Grease-pit"->"Grease-pit"? Rod (A. Smith) 03:54, 3 August 2006 (UTC)


 * I've looked at the .php and don't understand it quite well enough to answer this myself: can you make it split 人, 儂 ? (or is another single character a good idea? maybe / ? The idea is to say "人 or 儂" and wikify them. (these are alternate traditional forms of "person"). Then I can solve a similar bit of cruft in the Chinese templates. Oh, but it only works on the page title, you don't have a parameter. Sigh. Robert Ullmann 15:27, 3 August 2006 (UTC) I should start with the IsValidPageName business anyway. Then it may not matter much. Do you have any idea where IsValidPageName is documented? Or where I might find out just how it works? en-noun uses it to conditionally wikify ... is there a better way? (It would be great to have something called wikify that takes a parameter and wikifies it if not, much better than a lot of conditionals.) Robert Ullmann 15:45, 3 August 2006 (UTC)


 * I read isValidPageName ... didn't realize it was (just) a template. Gee, quite a hack ;-) I suppose it would be possible to create a template to wikify things using isValidPageName? (not as a subroutine, just a copy with the appropriate changes so there isn't yet another level?) Seems pretty simple? ? Robert Ullmann 16:00, 3 August 2006 (UTC)


 * "wiki" is way to ambiguous/generic here. Needs a better name. See next topic. Robert Ullmann 19:46, 3 August 2006 (UTC)


 * It should also split on hyphens. Excellently done.  You tested it on your wiki already?  --Connel MacKenzie 18:39, 3 August 2006 (UTC)


 * Yes, I tested it on my mw 1.8 wiki (the same version that runs en.wikt). Rod (A. Smith) 20:05, 3 August 2006 (UTC)

URGENT: template:figurative in cheerleader
Anyone know what experiment is was, that has gone awry? The entry for cheerleader currently uses with quite disastrous results! --Connel MacKenzie 16:29, 6 August 2006 (UTC)

See also climb up - seems to be "italbrac" SemperBlotto 16:33, 6 August 2006 (UTC)


 * Changes in the parser. Template probably needs to be rolled back to earlier versions. — Vildricianus 17:05, 6 August 2006 (UTC)


 * Hmmm. Does this mean  will now suddenly start working again, too?  --Connel MacKenzie 17:40, 6 August 2006 (UTC)


 * It's probably broken somewhere. — Vildricianus 17:49, 6 August 2006 (UTC)


 * By the way, characterizing Tim's change as a Wiktionary internal issue seems quite harmful. If dev's don't know they've broken something, how can they fix it?  --Connel MacKenzie 17:43, 6 August 2006 (UTC)


 * I hadn't heard of using their admin log to report bugs. I guess the best (only?) option is to talk to them through IRC. — Vildricianus 17:49, 6 August 2006 (UTC)

Transwiki - new procedure?
With yesterday's addition of the Import: capability, I think our whole Transwiki scheme needs some fundamental adjustments.


 * About the new feature:
 * Wiktionary sysops now can go to Special:Specialpages and at the very bottom, select "Import." Entering the name of an existing Wikipedia entry then pulls the entry over to Wiktionary's Transwiki namespace (or any namespace, actually) with the full edit history intact.
 * The function works similar to deletion restore. Multiple imports of the same entry can be done, creating duplicate edits.  If this happens, delete the wikt:Transwiki entry, and re-import.  (Note that there is some time-delay when you do this - about two minutes.)
 * Stub users are pseudo-created here for each user that has only a Wikipedia account. They can still come here and create a proper account, and the new account will have their previous contributions that were imported from Wikipedia.
 * Imports currently are from Wikipedia only. If others are ever needed, they can be added by Brion.

Special:Log/import now partially fills the role that WT:TW formerly did. But not completely. The automatic import log only shows that it was imported, not that it was deleted or adapted.

I'm not convinced that the automatic import log is sufficient for the task. The point of having WT:TW is that a Wikipedia contributor can go there to find out what became of their entry. Since the majority of Transwiki entries ultimately are deleted, it doesn't seem helpful to abandon WT:TW.

During the interim period, where some entries are on WT:TW and some are on Special:Log/import, much confusion is likely to arise. We have a couple thousand existing Transwiki entries to clear, before this problem even can go away.

Another curiosity is that a user who is blocked on en.wiktionary can have their Wikipedia contributions imported. The numerous Primetime sockpuppets make this a possibility, but I'm not sure we need to do anything more than we currently do, to remove such cruft.

Sysops who do use this functionality, must update w:WP:TL with each entry they import. Optionally, you can tag the wikipedia entry with ...or let the Wikipedians do that part.


 * One idea tossed out, is to create a new user class of users capable of doing this Import:. To me, this seems like an excellent idea.

Moving right along, I could see the following as the new Transwiki way:
 * 1) En.wikt: sysop imports an entry that is on w:CAT:MtW.
 * 2) En.wikt: sysop adds line to w:WP:TL.
 * 3) En.wikt: sysop moves entry to NS:0 then adds RFD or RFV or RFC or wikify tag (or whatever) and removes Wikipedia templates.
 * 4) * For existing entries, sysop first deletes target entry, moves Transwiki entry, restores target entry, and promotes correct version.
 * 5) Periodically, en.wikt: sysops look at Special:Allpages/Transwiki and for every entry that is a redirect, add a line to WT:TW and deletes the redirect.

Does this new method seem reasonable? Comments, brainstorming are greately appreciated...

--Connel MacKenzie T C 16:33, 2 July 2006 (UTC)


 * Here's a first draft of my idea (as mentioned on IRC):
 * Entry A gets transwikied, deemed unreasonable, deleted (not adopted). Result:red link in Log/import, so anyone checking could see that it has not been kept.
 * Entry B gets transwikied, deemd fine and gracious, adapted into entry and moved to main namespace. Redirect Transwiki:B -> B is kept, showing a blue link in Log/import. Very first entry in Special:Log/import is example.
 * This method also prevents double/triple/etc. transwikis, i.e. importing B again after it had already been transwikied in the past. Transwiki can't happen because redirect is in place. New user class with Import abilities is not a sysop and can't delete redirect. No possibility of duplicating. — Vildricianus 17:03, 2 July 2006 (UTC)


 * Hrm. And what about errantly deleted redirects?
 * Actually, that would require some advertizing to let people know that we shouldn't delete Transwiki redirects anymore. How long should the redirects remain?  A month?  A year?  Three months?  --Connel MacKenzie T C 21:55, 2 July 2006 (UTC)


 * We should probably solicit specific comments from SemperBlotto and Paul G on this one. --Connel MacKenzie T C 18:03, 3 July 2006 (UTC)


 * Scenario: raison d'être exists. I replace Transwiki:Raison d'être with a redirect.  Is that correct, or should the target be deleted, TW moved, and original target resored?  What should happen to Transwiki talk:Raison d'être?  --Connel MacKenzie T C 19:16, 5 July 2006 (UTC)

Note: we seem to have a backlog (on the WP side) now. --Connel MacKenzie 08:23, 24 July 2006 (UTC)


 * Backlog cleared. I wrote a script (GPL if anyone wants it) to do the imports.  Right now it is very ugly, and doesn't work right, without some finagleing.  I'll try and document it.  And clean it up a bit, then drop it on the toolserver.  For now, the import list has to be reformatted before running.  But step one is done anyhow.  (Next would be to make sure I don't ever re-import anything, then perhaps auto-generate the Transwiki:Log for it.)  Until then, I think this is covered.  Now we need a Transwiki: task force to clear out all the Transwiki entries...perhaps one of these a day: Special:Randompage/Transwiki.  --Connel MacKenzie 09:06, 12 August 2006 (UTC)

Extention for regularly inflected lemmata
I would like to create an " " extension that builds regular inflections using configurable, language-specific rules stored in the MediaWiki namespace. All of the inflection templates (English and others) would use it when calling pages indicate that the word is regularly inflected (i.e. by passing no parameters). Within the inflection templates, the extension would have this syntax:

So, pages for regular singular English nouns would call with no arguments, which would create the inflection line as " . The extension would apply the appropriate inflection rule for the lemma to get its plural. In the above case, it would read regular expressions from "MediaWiki:infl-en-noun", which encodes English rules for regular noun inflections like this:    ^(.*(s|x|ch|sh))$     <pl>\1es</pl>    ^(.*[aeiou]y)$     <pl>\1s</pl>    ^(.*)y$     <pl>\1ies</pl>    ^(.*)um$     Latin     <pl>\1a</pl>    ^(.*)$     <pl>\1s</pl>

Note that pages can still override the plural the way they do now, i.e. by specifying the irregular plural as the parameter to, but when the noun is regular, the highly configurable set of rules makes regular lemma entries nice and clean in all languages, even those that require stripping prefixes etc.

Seeking feedback, Rod (A. Smith) 05:33, 4 August 2006 (UTC)


 * On this and the above: if you have the power to write good extensions and to have them installed on the WM farm, I trust you have the best view on which to develop and how to use them. Please go ahead. — Vildricianus 08:20, 4 August 2006 (UTC)


 * Do be aware that this won't work for Latin. The genitive singular form is the one that determines the inflection pattern, not the nominative singular which is the main entry form.  Thus, any noun template for Latin will require the genitive to be entered as a parameter.  There will also have to be a parameter for the gender, since the ending is not a reliable guide for this.  The particular inflection pattern may still have to be specified, since the inflection can also depend on the word's etymology, for example many words of Greek origin have a separate inflection pattern from Latin origin words.  Latin also requires a macron-handling script (as outlined on the Talk page for the proposed la-noun template) if you want to reduce the number of parameters (as I think you and I both desire).  --EncycloPetey 04:56, 6 August 2006 (UTC)


 * You beat me to the punch, EncycloPetey. Since the above post, I have refined the design to accomodate such declension and conjugation patterns . The new (and unless someone suggests otherwise, feature complete [ feature complete] ) extension also accepts an "inflection class" to differentiate between declension forms. I know it hardly demonstrates the utility well, but note that MediaWiki:infl-en-noun now has a rule for an "inflection class", if you will, for Latin-derived English nouns ending in "um". Latin, likewise, could have an "inflection class" to indicate a specific declension class and a specific conjugation class. Is "inflection class" the best name for that parameter? Rod (A. Smith) 05:29, 6 August 2006 (UTC)


 * Um...no. There are inflection classes in Latin, but they require knowing the genitive form and the etymology to create them. Have you looked at the Talk page for la-noun? I'm not sure we're communicating fully on this. --EncycloPetey 05:36, 6 August 2006 (UTC)


 * Grr. I did miss that. And the marcron issue. Not sure how because I do know Latin enough that I should have understood. I'm going back to the drawing board and will emerge when I have this right. Rod (A. Smith) 05:39, 6 August 2006 (UTC)


 * Cool. Be aware that I am (right now) adding some additional information to the la-noun specifications that I forgot to add previously. --EncycloPetey 05:41, 6 August 2006 (UTC)

Status update: I finally completed the work to let the " " extension apply well to lemmata, non-lemmata, English, Latin, and every other use and regular inflection system that I can immagine. In order to let it play well with inflection templates (e.g., ), I had to tweak MediaWiki's parser to give extensions access to template parameters.

Anyway, since this change will be my first commit to the MediaWiki code base, and since the new extension needs that change, I'm not sure how long it will take for the changes to be accepted and become available. Rod (A. Smith) 04:51, 14 August 2006 (UTC)

DynamicPageList (again)
Do people like the right-column 'list of entries in the category' thing I added to WT:RFV? Should the same be added to RFC and TR? --Connel MacKenzie 17:43, 20 July 2006 (UTC)


 * Since I've gotten such an overwhelming response, I think I'll wait for Vild to be bold with this. --Connel MacKenzie 18:49, 26 July 2006 (UTC)


 * Out of the two people that read this page... Well, I told you it was good, so be bold yourself. It's a great application of DPL. Use it. — Vildricianus 18:53, 26 July 2006 (UTC)


 * It's correctly placed on the page, looks quite useful for maintenance purposes. DAVilla 07:42, 16 August 2006 (UTC)

template:wlink
Minor Ogg moment -- you know -- Ogg: "Rock round. Round rock roll. (very long pause) Me make wheel!"

Every use of I've seen (not that it is a huge number), is to decide whether to wikify the parameter of a template, or whether that has already been done, with other text, or in some multiple form. So:



Methinks it has a problem with a purely undefined parameter(s) though, see:



Hmm. I'll bet someone could fix that. If it needs fixing ... Robert Ullmann 19:43, 3 August 2006 (UTC)


 * As you said above, is a total hack. I had to introduce it to compensate for the lack of string functions here. A better solution would be a simple MediaWiki extension, e.g. one used like this:
 * : word
 * : word
 * A simple extension could easily just use the existing mw parser to determine whether the tag's contents already contain the markup. I'd be happy to write such an extension if it would be useful. If so, there are two different options for how it should handle multi-word contents:
 * : multiple words
 * : multiple words
 * Which would be better? Note: if the former is preferred, I'd abandon  and just use , having it default to linking the current page title only if no contents are given. Rod (A. Smith) 20:01, 3 August 2006 (UTC)


 * As long as one can use a parameter inside (having found that
 * word (plural words)


 * I don't know the best display format or template syntax for plurals. One option is this (e.g. on "scissors"):
 * scissors (plural)
 * scissors (plural)


 * That format and syntax presents consistency problems, so I welcome any improvements. Before we go too far, though, let's be sure we deliberately choose whether to format non-lemmata like lemmata. Rod (A. Smith) 05:15, 10 August 2006 (UTC)


 * How about using the double dash for the singular form in the table format? The in-line format would require additional tweaking though.  Perhaps marking a noun as plural in the template could produce:


 * scissors (plural only)
 * scissors (plural only)


 * This way, only the in-line version looks tweaked, which seems an easier thing to deal with. The table format would work out the same. --EncycloPetey 06:25, 16 August 2006 (UTC)

En-Noun needs another option
I just discovered that does not have a way to deal with plural nouns. That is, nouns that exist only in the plural with no singular form, such as wheels or triceps. Could someone add code to the template (and accompanying talk page explaining how it works)? --EncycloPetey 23:58, 9 August 2006 (UTC)


 * But both of those English pluralia tantum do have singular forms. --Connel MacKenzie 05:13, 10 August 2006 (UTC)


 * The word triceps has a singular back formation, which is not the same thing. The meanings given for wheels as a noun do not have singular forms, any more than scissors or pants would. --EncycloPetey 06:19, 16 August 2006 (UTC)


 * We need to determine how to display both pluralia tantum and non-lemmata plurals. Please help do so in, immediately above. Rod (A. Smith) 05:20, 10 August 2006 (UTC)

subst:PAGENAME in templates
Can someone have a look at Template:fprp. In its current state, when it is used (after "subst"ing), then comes out. How can I get to come out of it every time instead? --Bottletoground 00:01, 15 August 2006 (UTC)


 * If you can guarantee that it is always subst:'d, (i.e. it is used only as a preload template) then there is a trick you can do to accomplish it. But, since you can't guarantee substitution, it is better to wait for the PAGENAME's to get cleared after each monthly XML dump.  See User:Connel MacKenzie/PAGENAME for the generated list.  I use Javascript to subst: them semi-automatically; I'll attend to these sometime soon.  --Connel MacKenzie 08:35, 15 August 2006 (UTC)


 * I've made the requested change and also added this to MediaWiki:Noexactmatch/fr. Are there any other templates that should go there?
 * Could someone please translate "browse nearby pages" to French? Thanks! DAVilla 06:39, 16 August 2006 (UTC)

WOTD audio license info
I posted a concern about the WOTD mainpage template a while ago, but still have received no reply. The issue was the lack of a link to license information for the audio files on the mainpage. I would love to fix the template myself, but I'm simply not that good with wikicode to figure it out.

Peter Isotalo 08:23, 12 August 2006 (UTC)


 * Is this entirely necessary? The license should be in the audio file information. DAVilla 17:56, 16 August 2006 (UTC)

automatic case-variant redirects
[See also Beer parlour, where this discussion originally appeared and has been moved from. —scs 13:35, 16 August 2006 (UTC)]


 * I've encountered a small problem trying to add a new entry with capitalisation different from an existing entry. Let's say (as an example) that I wanted to add an entry for Ye gods, but ye gods already exists; I have roughly a second to click the 'edit' button before I'm automatically redirected to ye gods. Although this can be easily circumvented, it's likely to confuse a new user much more than it confused me. A simple solution is to add a wikiML-redirect-style " (JavaScript-redirected from [ Ye gods]) " under the page title, and have the script recognize 'redirect=no' in the URL. // Pathoschild (editor / talk) 14:51, 15 August 2006 (UTC)
 * The idea was that entries like that would have links from the one to the other, IIRC.  --Connel MacKenzie 16:11, 16 August 2006 (UTC)
 * Don't you normally start new entries through redlinks or via search ? — Vildricianus 15:06, 15 August 2006 (UTC)
 * I don't know about Pathoschild, but I normally start them via the address bar or the Go button, so I have the same problem, and I'd say it's more than "small".
 * The auto-redirect works exactly like the Go button. In fact it works by clicking the Go button so perhaps you think the problem is bigger than you state. &mdash; Hippietrail 23:33, 15 August 2006 (UTC)
 * No, the problem is as I state, and it's unchanged by your observation about how the redirect is implemented. See below. —scs 00:16, 16 August 2006 (UTC)
 * I remember when we added the other-case convenience links to the "page not found" page, and that made sense, and I remember when Connel experimented with a way of "automating" it, but I didn't remember we'd decided to make it official. Personally, although it's a cute trick, I can't say I like the way it works in practice.  (Sorry I didn't say so earlier.) It makes it a real nuisance to add new case-variant entries: there used to be five or six ways to do this, and today all but one or two is cut off, and it can be a challenge to find the one or two that still work. —scs 15:23, 15 August 2006 (UTC)
 * (edit conflict) For me it works great. You enter a term, hit search, and you get the red link at the top of the page. What I find weird is that this feature has been around for at least two months now, and that these are the first comments on it. Haven't you created any entries in the last months?
 * Boatloads. (Say, that's one of them! :-) ) But I guess there weren't too many case variants among them.  (And like I said, I meant to comment on it earlier...) —scs 16:45, 15 August 2006 (UTC)
 * BTW, there are three options. Via search, via redlinks, and via the urlbar where you append <tt>?action=edit</tt>. Agreed that it's far from accessible. — Vildricianus 15:27, 15 August 2006 (UTC)
 * In fact you can't just append "?action=edit" unless your URL begins "en.wiktionary.org/w/index.php?title=xxx". URLs for a normal page view will instead begin "en.wiktionary.org/wiki/xxx" to which you cannot append &foo=bar type arguments. &mdash; Hippietrail 23:33, 15 August 2006 (UTC)
 * To clarify what I meant when I said "I normally start them via the address bar or the Go button" and "there used to be five or six ways to do this" -- here are the ways I can think of right now to start a new article:
 * follow redlink
 * type word into search box, hit "Go"
 * type word into search box, hit "Search"
 * type word into browser address bar, i.e. "<tt> http://en.wiktionary.org/wiki/word </tt>" (and various options)
 * manually construct edit link in address bar, using <tt>action=edit</tt> (various options)
 * (There might be one or two more. And it's true, some of those are pretty much the same, especially 2 and 4).
 * Today, though, for a word which already has an other-case sense, most of those don't work, or don't work directly. I just repeated the experiment, as if I was trying to create Tamper.  #1 works, but is an option (for me) only if such a redlink is already in front of me.  (I'm not going to create a redlink in a sandbox somewhere just so I can create an article.) #2 takes me straight to tamper.  #3 gives me search results and no "did you want to create it?" link.  #4 takes me straight to tamper. #5 works, if I construct the URL "<tt> http://en.wiktionary.org/w/index.php?title=Tamper&action=edit </tt>".  (I never thought of that one before.  So I was wrong -- there are three or four ways that still work, not two.)
 * The last time I tried this, a week or two ago, the only ways I could find to create Tamper were, after some searching, (a) turn off Javascript or (b) do #3, and click on the red link in "You searched for Tamper". It was way harder than it should have been.  (Someone suggested you have 1 second to do something before Connel's autoredirect kicks in, but these days, for me, Connel's autoredirect is instantaneous; I don't even see a flicker of the old "no such page; did you mean..." page.)
 * On a related note, why doesn't it say "Would you like to create it?" on the search results page? Didn't it used to?  Or is that only for searches that yield 0 results? —scs 00:14, 16 August 2006 (UTC)
 * Hrm? I create redlinks in a sandbox all the time to create articles. Created a bunch of German redlinks earlier today, just so I can be sure that all the forms in a family of words turn blue. <i style="background:lightgreen">bd2412</i> T 02:45, 16 August 2006 (UTC)
 * chacun à son goût. :-) —scs 02:49, 16 August 2006 (UTC)
 * It seems to me that a preference should be added. This will be easy with Connel's cookie prefs and I'll add it to my list for the extra Wiktionary-specific preferences tab I've been working on. For dictionary users this is certainly a good thing. For editors it is apparent some will want to turn it off. &mdash; Hippietrail 23:33, 15 August 2006 (UTC)
 * Indeed. (I look forward to it!) —scs 00:14, 16 August 2006 (UTC)
 * OK, I've added an extra option on User:Connel MacKenzie/Preferences. Tick "Disable automatic redirect". Please try it out. &mdash; Hippietrail 01:15, 16 August 2006 (UTC)


 * Now that I've played with it I find that it doesn't work like the Go button after all. With the Go button I can enter "buenos aires" and arrive at "Buenos Aires". With autoredirect on and entering "buenos aires" in the URL I unexpectedly get nothing! I assumed this feature worked by clicking Go with the current article name but upon reflection this would cause a 2nd page load every time an article is not found via the URL. Connel's code instead tries a small handful of case variations and hits the Go button for the first one. This can also cause another unexpected result - going to a redirect rather than an actual article. I can think of ways to improve this with the toolserver or to a lesser degree with JavaScript to generate some case variants that might be impossible or difficult using just parser functions. &mdash; Hippietrail 01:38, 16 August 2006 (UTC)
 * The test case is "buenos Aires" with a capital "A". Perhaps a better example could have been picked.  I'm not sure I understand the complaint about selecting a redirect as a target.  That situation would be analogous to any double-redirect situation we currently enjoy.  :-)  And it would take an obscene number of CPU cycles on the client and server to prevent.  --Connel MacKenzie 15:52, 17 August 2006 (UTC)

(edit conflict) First: That was quick! Thanks very much for this option.

Second: thanks too to Connel for the whole, magic, WT-specific preferences page, which is a project I'd once wanted, but didn't manage, to contribute to. Nice work.
 * Your welcome. Thank you.  Please add to it, your favorite customization/hack.  --Connel MacKenzie 15:52, 17 August 2006 (UTC)

Third: there's something new and different going on with the Go button. Just now, with your new "Disable automatic redirect" preference, I can get to the (nonexistent) Tamper page by typing its name in the address bar (my method #4 above). But method #2 still goes immediately to tamper, and it does so even if I turn JavaScript off. So I'm getting the impression that MediaWiki must have implemented, down at a lower level, the same sort of "do the right thing" behavior we've been playing with here. (That's a project I did some work on, too, in fact I even had it implemented and working back in May, but I never submitted the code. I worried about the cross-case creation problem then, but it looks like whoever else implemented it, didn't.)

(Side note: when I enumerated my five ways above, I half-expected someone to tease me, and to assure us that methods 2 and 4 were identical. I would have argued the point, because while I knew they ought to be identical, I can't prove it.  And now we see they're actually far from identical, after all...)

—scs 02:11, 16 August 2006 (UTC)


 * OMG. I saw in edit history when this was moved a day or two ago, from Grease pit to here, but didn't get a chance to look at BP until now.  I've read chapters one two and three of the above novels.  Can we have some brevity here?  PRETTY PLEASE?  :-)
 * Regarding Go vs. JavaScript: yes, since the June 2005 case-sensitivity changes, the [Go] button does some non-obvious case redirection magic. Things like "wt:bp" [Go] become "WT:BP".  Things like "FOOBAR" become "foobar".  Also similar transforms are checked on the first character.  The Javascript looks for the existence of those other varieties, then triggers the [Go] button in some circumstances (with limits, to prohibit the possibility of looping.)


 * Sorry for the longwindedness; it's in my nature. But which "June 2005 case-sensitivity changes" are you talking about here?  Yours?  What you may have missed is that there appears to be something else going on, completely separate from your JavaScript DWIM feature. (See Hippietrail's paragraph beginning "it doesn't work like the Go button after all" and mine beginning "there's something new and different going on with the Go button".) —scs 13:04, 16 August 2006 (UTC)


 * I normally refer to that event as "The decapitation of Wiktionaries." At the time, concensus was against decapitation; in fact, arguments against it were still building.  But, the conversion was done, and the recent backups were pooched (we would have had to roll back to a version from two months prior, or so.)  When all the headwords were converted to lowercase-first-character, certain changes were made to the [Go] button logic to accomodate normal searching/user expectations.  That is the June 2005 magic I was talking about.  It has never really been satisfactory, but slowly (with JS tweaks, perhaps,) it is getting better.  The pandemonium of those first two weeks was rather impressive.  --Connel MacKenzie 06:43, 17 August 2006 (UTC)


 * Okay, got it. But I think there may have been a June 2006 change, too, because the behavior of the Go button seems to have changed since last May.
 * In May 2006, if you typed "Tamper" into the Search box and clicked "Go", you got a page that said "Wiktionary does not have an entry for this exact word yet." Then we tweaked that page to say "Did you mean tamper?"  Then we (you) tweaked the behavior to assume that you did mean tamper, and to magically redirect there via some funky JavaScript a fraction of a second later.
 * That was last May. Today, if you type "Tamper" into the search box and click "Go", you go immediately to tamper, and it appears to have nothing to do with the Connel magic auto JavaScript redirect trick.  It's very different behavior.  Since no one else here has noticed this or knows what I'm talking about, I'd better go ask on Wikitech-l about it, or call myself crazy. —scs 12:10, 17 August 2006 (UTC)


 * I do understand that it is confusing. But that change really did go in, in June 2005.  Honest.  Talk to Brion about it; the external syntax has behaved very differently from the [Go] button since June 2005.  The difference is the same as the difference between http://en.wiktionary.org/wiki/Tamper vs. http://en.wiktionary.org/wiki/Special:Search?search=Tamper&go=go behavior.  --Connel MacKenzie 15:37, 17 August 2006 (UTC)


 * Also, could you please post the archive links to the wikitech-l messages that you post? Some (like me, for example) refuse to subscribe to yet-another-mailing-list.  --Connel MacKenzie 15:41, 17 August 2006 (UTC)


 * The original purpose of doing this, was twofold:
 * Auto-redirect casual first-time visitors, getting here from a link from "about.com" or "open-dictionary.com" or "thefreedictionary.com" or any of our other mirrors.
 * to prevent having duplicate entries created by visiting Wikipedians (e.g. Froth vs. froth)
 * I think this can be further enhanced, to use a cookie to identify that the [Go] button was auto-clicked. Should I pursue doing so?  I could then add the "Redirected from" links asked for above, and propetly link the edit page.  Is this desired?  (I think I'm hearing yes, but then I wasn't expecting to read and answer chapters of questions here.)
 * Is it possible to use JavaScript to check the referring page, and only redirect from foreign websites? Does the above accomplish that? DAVilla


 * OMG, now my response is two edit-screens long. Please move the lively discussions about preferences to WT:GP.
 * --Connel MacKenzie 07:16, 16 August 2006 (UTC)

[This did get pretty long and tech-y, didn't it? Done. —scs 13:35, 16 August 2006 (UTC)]

Thank you. Where should the 'preferences' discussion start? I think that brief mention on the beer parlour quadrupled the number of people that have seen and tested it now. (P.S. Everyone please add your favorite WT:CUSTOM dohickey to User:Connel MacKenzie/custom.js.) --Connel MacKenzie 06:43, 17 August 2006 (UTC)

Appendices
Is Appendix real namespace like Category? --Andrejj 05:56, 17 August 2006 (UTC)


 * Yes. For about three weeks now, it (and a few others) have been "real."  --Connel MacKenzie 06:24, 17 August 2006 (UTC)

Tnx. How can namespaces in other Wiktionary became "real", we would like to use Dodatek (Appendix) and few others in Slovene Wiktionary?--Andrejj 06:32, 17 August 2006 (UTC)


 * By filing a "change request" on that links back to the Slovene's beer parlour (that shows either a vote or strong consensus for it.)  Each namespace needs also a talk namespace and the numbers must start at 100.  It is best to add all the namespaces you want, all at once.  (We may have done too many, I think.)  Note: <tt>product=wikimedia, componenet=site requests, platform=all, os=all, priority=normal, severity:enhancement.</tt>  Be sure to register your user there, first.  Sometimes it takes a day or two for the devs to get to it, so please be patient.  If all else fails, try irc://irc.freenode.net/#wiktionary (friendly) or #wikimedia-tech (hostile) to speed it up.  --Connel MacKenzie 23:56, 17 August 2006 (UTC)

Template:given name
I think that this template should be altered; to either
 * 1) have categorisation not default (as it does at present) to Category:Given names, but rather allows a user to insert the word into one or both of the categories Category:Female given names, Category:Male given names, by some parameter.
 * 2) establish more specific templates for  (which is to categorise to this category),  (to categorise the this category), and  (to categorise entries into both categories : in the case of names such as Ashley and others which are given names for both males and females).

I am most certainly willing to design the latter templates; and I could probably figure out how to do the first option, too, if someone were to explain parameters to me. Does anyone oppose this or have any suggestions, though? Beobach972 19:17, 10 August 2006 (UTC)


 * Ahhh, memories. The state you see Appendix:Names in currently was my first real cleanup project here (and apparently, Wiktionary's first directed cleanup effort of any sort.)  :-)     Times and methods have certainly changed since then, though.
 * My main objection to categories for names is how they look. That is, the current pages are not nearly as sloppy as the categories will be.  Having links from/to the Category/Appendix might be useful.  I understand that the navigation bar for giagantic categories has been improved, but they'll still look like, well, categories.


 * For you'll want it to be something like : <tt> A  given name.  </tt> and you'd have on the definition lines <tt>  </tt> or <tt>  </tt>.  Commingling surnames into the same template would make it needlessly more complicated: I recommend using a separate template for them.  Note that you can all bicker over the precise typography (which is not something I particularly care about, anymore.)


 * You might also want to check in with some 'bot operators (erm, such as myself or Rod) for replacing the ones that do pretty much conform to the standard format, automatically. --Connel MacKenzie 00:26, 11 August 2006 (UTC)


 * See what you think so far : Template:given name. Beobach972 20:03, 11 August 2006 (UTC)


 * So, we're grouping all the given names regardless of language? One of my hobbies is onomastics, and the incredible complexity of writing a dictionary entry for a name has kept me from attempting to clean up anything here. Names are messy.  Even a simple name like Jack has a hideously complex etymology, which is usually hard to find the details of.  (The best discussion of the origin of the name Jack dates from about 400 years ago, and is largely speculation!) --EncycloPetey 06:16, 16 August 2006 (UTC)


 * It looks to me like this should be two templates, and . Anyways, where is it used, and why isn't  sufficient?DAVilla 06:56, 16 August 2006 (UTC)


 * I keep forgetting about the cattag template. That sems like the best solution.  --EncycloPetey 02:01, 19 August 2006 (UTC)

oddity
I added an additional meaning to the noun form of coat using the uncountable form of. It has formatted strangely, and I can't reproduce the behaviour in the sandbox. Any ideas? SemperBlotto 21:51, 11 August 2006 (UTC)


 * That is odd. Since and others usually appear immediately after the POS headers (e.g. " "), I had never tested them immediately following a wiki list. It obviously doesn't work well there. For now, I added a second "===Noun===" header above the second  on that page. Usually, in these situations, we have two etymologies, each with its own "===Noun===", but not in this case. Should two occurrences of  be allowed inside a single "===Noun===" section? Rod (A. Smith) 00:04, 12 August 2006 (UTC)


 * We used to allow that, if they were one after the other. But the situations that was needed for no longer seem to be a problem.  For  though, the qualifier should only be at the start of the line, in this case.  So no, this one should not have two separate inflection lines.  --Connel MacKenzie 09:09, 12 August 2006 (UTC)


 * I can't think of any cases for English but for languages with optional marks it is possible that several forms exist under the same POS and etymology differing only in optional marks. There are such pages for Hebrew and the same is definitely possible with Arabic and perhaps possible with Latin, Old English, and Turkish. &mdash; Hippietrail 15:59, 12 August 2006 (UTC)


 * I don't think that should happen for Latin, since the diacriticals change the meaning substantially enough that it would be a different part of speech in most cases. It might be true in Greek though. --EncycloPetey 06:12, 16 August 2006 (UTC)


 * What are you talking about? In Latin most of the endings for the different parts of speech do not overlap, so adding or removing a macron couldn't change it. --Ptcamn 06:35, 16 August 2006 (UTC)


 * Check līber (adj, "free") versus liber (n, "book, bark") versus Līber (prop. n., "deity of planting"). Check pactus (adj, "agreed, settled") versus pāctus (part. of pangō "fasten").  It is often root words that overlap..  And by the way, the endings of nouns and adjectives overlap considerably, and they make up a majority of Latin words. --EncycloPetey 01:59, 19 August 2006 (UTC)

Moving POS categories into POS templates
From WT:BP comes a good reason to allow POS templates like to categorize their clients into very general POS categories like Category:English nouns. The argument I have always seen against doing so is that such categories are "useless" because they have too many members. Since there is now a use for such categories, they are, by definition, not useless. Following is the approach I will employ to categorize entries into general POS categories through the existing POS templates:


 * 1) Replace Category:English nouns with Category:English nouns that lack inflection template.
 * 2) Remove Category:English nouns that lack inflection template from pages that use.
 * 3) Add Category:English nouns to.
 * In :
 * 1) Repeat the above for adjectives, verbs, and adverbs.
 * In :
 * 1) Repeat the above for adjectives, verbs, and adverbs.
 * 1) Repeat the above for adjectives, verbs, and adverbs.

Please feel free to object, question, or comment here. Rod (A. Smith) 23:15, 6 August 2006 (UTC)

I'm in favour. I used to be against such categories but a couple of months ago I realized that such vast categories along with some new "Random article in this category" feature would be a very good thing for browsing and maintenance. &mdash; Hippietrail 02:19, 7 August 2006 (UTC)


 * (Thanks, Hippietrail.) The test migration went swimmingly. There are around 200 entries per huge POS category, so I'll skip the bot request. Migrating.... Rod (A. Smith) 05:51, 7 August 2006 (UTC)


 * Support --Connel MacKenzie 05:55, 7 August 2006 (UTC)
 * Support with suggestion : Since the POS template recognizes the major patterns of forming the plural, can it subdivide the category by pattern of plural formation? (Regular, adds S; Regular, adds ES, Adds EN, etc) --EncycloPetey 23:55, 9 August 2006 (UTC)
 * Absolutely. The way works today, it would be easy to support the "adds s", "adds es", "no plural", and "all others" categories. When my extension work is complete (set back a bit in attempting to incorporate macro fun in Latin declensions when I discovered that MW doesn't yet expose template parameters to extensions), it will be able to categorize according to pretty much any pattern we declare. Please create the desired categories so I know exactly what names to use. Rod (A. Smith) 04:02, 10 August 2006 (UTC)

Way way back, about nine or ten months ago, there was some discussion about POS categories. The larger ones were not wanted, but the category names for English parts of speech were also a hot topic. These categories never should have had "English" in their titles, as this is the English Wiktionary. (Other languages use the ISO-639 prefix format, with matching names, e.g. Category:bs:Nouns.) --Connel MacKenzie 05:32, 10 August 2006 (UTC)
 * Comment:


 * That doesn't quite match current practice. Remember that we have two types of categorization on Wiktionary: Grammatical and Topical.  The way current practice looks, all the Grammatical Categories are similarly structured (e.g. English nouns, Spanish nouns, German nouns).  Topical categories are where the ISO-639 prefix is not only being used for non-English categories, but where it becomes essential.  Consider the following:
 * Category:Architecture contains English words dealing with architecture
 * Category:English architecture would contain English words dealing with English architecture
 * Category:Italian Architecture would contain English words dealing with Italian architecture
 * Category:it:Architecture would contain Italian words dealing with architecture
 * Category:it:Italian architecture would contain Italian words dealing with Italian architecture
 * The radical differences in meaning and possibility for confusion necessitates this distinction. So, if we mandate the category it:Nouns, would this be Italian words pertaining to nouns, or would it be Italian words that are nouns?  I favor the former interpretation, and much prefer keeping current practice for Grammatical categories such as Italian nouns for words that are Italian nouns. --EncycloPetey 06:36, 16 August 2006 (UTC)


 * Is that the current practice, or just a couple people's errors? --Connel MacKenzie 07:48, 16 August 2006 (UTC)


 * While there are exceptions, it's the pattern I've seen across a wide diversity of languages, so it's not just a few people. It's also been my practice to date. I haven't seen a page stating clearly what the policy was, so I went with what seemed to be current practice after looking in on lots of Language Categories.  --EncycloPetey 02:04, 19 August 2006 (UTC)


 * Where do I start? Right now, nouns in Min Nan (Chinese) are categorized in nan:nouns, nan-tw:nouns, and nan-cn:nouns, depending on the script (POJ, traditional, simplified; respectively) They should be in Min Nan nouns, but then what do we do with the three different scripts. (They could be categorized together, in a couple of different ways, but this seems to cause coniptions for some people ;-). The related question is what we do with a topical category: nan:Architecture is easy, but then we have the same problem? I'm working on the nan-noun template right now, so I can make it do what is desired. This also applies to Mandarin (zh-tw, zh-cn), Cantonese (yue-hk, yue-cn), Japanese, Korean, Vietnamese, and other languages with different scripts. I am all for categorizing them together, with sort keys that bring the related forms together in one sequence. Robert Ullmann 14:17, 16 August 2006 (UTC)


 * Robert, I finally found my way to this discussion on grease pit! I had raised an issue in Beer Parlor that touches on many of the same themes.  I laid out my thoughts on the subject in detail, including a suggestion about how to deal with part of speech categories.  Here is the link for those who may not have seen it:


 * WT:BP


 * A brief synopsis of what I said there: we should not have two different categorization schemes: one for POS and one for topical, because POS categories ARE topical. They are subcategories under Category:Parts of speech <- Category:Grammar <- Category:Linguistics <- Category:*Topics.  I proposed to fix the problem by using both ISO 639 codes and plain English descriptions (ex.  <tt>  </tt> instead of the current <tt>  </tt> or <tt>  </tt>).

A-cai 12:10, 20 August 2006 (UTC)

Balancing simplified and traditional Chinese

 * This is semi-related to the above topic, I would like to have a way to eventually know: how many Mandarin words do I have in a given category? How many of them are written in simplified script?  How many are written in traditional script (and how many that are both simplified and traditional)?  If I have 230 words in traditional but only 225 in simplified, how do I go about finding which five need a simplified entry (or vice versa)?


 * In other words, could a bot be written that would slap a tag on traditional entries, and vice versa?  The tag would place that entry in category such as <tt>  </tt> or <tt>  </tt>.  I would then create the missing entry by hand.

A-cai 12:10, 20 August 2006 (UTC)

Limited number of templates?
Not sure if I'm asking this in the right place, but here it is anyway. Recently on the Romanian Wiktionary we've started experiencing a strange problem. It appears that when the number of templates in an article exceeds a certain limit (about 20), the templates stop working as they should, and their titles get displayed instead of their contents. Does anyone know why this happens?

See for yourselves for example the article ro:alfabet (but the same happens on all pages with many templates). The list in the section "Traduceri" (meaning translations) works fine down to about its middle, but then all subsequent templates in the page stop responding properly.

The funny thing is that nobody touched any of the templates directly or indirectly involved in these pages.

If you know how I can solve this, please drop me a message at ro:Discuţie Utilizator:AdiJapan. Thanks. --AdiJapan 15:49, 19 August 2006 (UTC)


 * I haven't yet looked at the entry to which you linked but it could be related to a recent MediaWiki change where the total transclusion size has been limited. I don't remember the maximum size, but it's important not to have templates work by including significant amounts of text and filtering that text back down. Rod (A. Smith) 16:42, 19 August 2006 (UTC)


 * Yes, that’s right. We don’t use templates so heavily here in en.wiktionary, so it’s not a problem for us. But your template is limited to approximately 17 instances per page. If you also have a lot of other templates on the page, it won’t even accept 16. —Stephen 20:59, 19 August 2006 (UTC)


 * The culprit has got to be was ro:Format:LR and ro:Format:LL which are were massive switch statements that only determine the name of the language given a code. Use many different templates instead, one for each langauage code. By the way, why re-invent ro:Format:switch? DAVilla 21:19, 19 August 2006 (UTC)

Does anyone know how to make my computer speak Chinese?
You may recall that I am a technopeasant, and my computer is as dumb as me. I have spoken to it sternly,and have threatened to take away it's electricity, but it is ignoring me. I am using Office 2003 and Windows XP. Help. Andrew massyn 20:11, 19 August 2006 (UTC)


 * you need to load the East Asian language support. Go to Control Panel, pick Regional and Language options, pick tab Languages, check box for Install Files for East Asian languages, and OK. Robert Ullmann 20:19, 19 August 2006 (UTC)
 * Many thanks Andrew massyn 20:24, 19 August 2006 (UTC)

Madly templating CJKV languages
I've been doing lots of things, like making ja-noun real, and making POS templates for Mandarin and Min Nan, Cantonese soon. The objective is to make these languages like all our others without all the "special" things that were invented by Nanshu et al, while making the entries and categories very useful in the English Wiktionary. Please tell me if you have any issues, suggestions, criticisms, etc. Robert Ullmann 20:34, 19 August 2006 (UTC)
 * I have made three suggestions, regarding the use of italics and two forms of puncuation that I believe will make the templates eminently more clear and readable (as is the standard in China-related articles at English Wikipedia), here, with examples. Badagnani 08:22, 26 November 2006 (UTC)

Word of the day "sound" problem
When I click on the "sound" icon next to word of the day, it first says I must be a member to "upload" files (which does not make sense) and then (after I joined :-) ) it says I must be a "Sysop" to perform the action! I think that the link to the "play sound" icon must be incorrect folks!


 * I've not been able to reproduce this problem. Anyone else?  --Connel MacKenzie 17:51, 23 August 2006 (UTC)


 * I had this happen to me once, but not since. I never did figure out what might be the cause. --EncycloPetey 02:24, 24 August 2006 (UTC)

pre-ordained links out... live smart links in.
I am dismayed by the notion that hyper-links should be pre-ordained, manually produced, a-priori, hard wired, static, dead, etc.

These Wiki entities are living breathing things... why should the links be so static, and dead?

Solution: active searches and links produced and displayed as such at the time a chunk of content (word, story, media, etc.) is requested/visited. The search algorithms that map said links should be powered by various matching algorthms that keep track of user focus as well as the morphing shape of the data space itself (I hope the data space is more alive than the contribution and navigation space).


 * Because...we're not Wordnet? --Connel MacKenzie 17:49, 23 August 2006 (UTC)
 * Reason 2 : Because the pagename and link form do not always match.
 * Reason 3 : Because the link is sometimes specific to a language or part of speech. --EncycloPetey 02:22, 24 August 2006 (UTC)