Wiktionary

Wiktionary:Grease pit/2006/October

< Wiktionary:Grease pit
Grease pit archives edit
2024
2023
Earlier years
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006

Display Problem edit

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)[reply]

Not a browser problem. 'Twas {{serial and}} that was wrong. Fixed. — Vildricianus 19:41, 14 June 2006 (UTC)[reply]
Good to hear. --Filip 08:46, 15 June 2006 (UTC)[reply]

Vandalism - blocks edit

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)[reply]

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)[reply]
Also, don't forget to post in the BP once in a while ;-). — Vildricianus 10:12, 13 June 2006 (UTC)[reply]
The vandalism channel(s), not the recent changes channel. --Connel MacKenzie T C 18:11, 13 June 2006 (UTC)[reply]
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)[reply]

Probable copyvios edit

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)[reply]

I think that's a good idea. Why not just {{copyvio}}? — Hippietrail 17:55, 13 June 2006 (UTC)[reply]
'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)[reply]
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)[reply]
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)[reply]
Oh well... I know Muke has been tagging some stuff with {{unreferenced}}, but yes, about 98-99% could do with such a tag. — Vildricianus 08:33, 9 July 2006 (UTC)[reply]

Selective delete edit

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

Error - Python wikipediabot's pagefromfile.py edit

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)[reply]

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)[reply]
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)[reply]

Default charset for edittools edit

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)[reply]

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. — Hippietrail 17:32, 13 June 2006 (UTC)[reply]
Yes, it would be sufficient for me if it simply remembered the last one visited, even per session. ∂ανίΠα 16:36, 14 June 2006 (UTC)[reply]
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)[reply]
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)[reply]
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. — Hippietrail 19:51, 17 June 2006 (UTC)[reply]
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)[reply]

Delete tab and Show changes button have same accesskey edit

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? — Hippietrail 18:17, 13 June 2006 (UTC)[reply]

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)[reply]
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)[reply]
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. — Hippietrail 19:20, 13 June 2006 (UTC)[reply]
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)[reply]
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)[reply]
I'm still wondering how I can remove the accesskeys, though. — Vildricianus 11:46, 14 June 2006 (UTC)[reply]

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)[reply]

Normalization of articles edit

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)[reply]

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? Wiktionary:Normalizing? --Connel MacKenzie T C 17:34, 14 June 2006 (UTC)[reply]
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 Wiktionary:Normalizing. Perhaps that's not necessary. — Vildricianus 18:25, 14 June 2006 (UTC)[reply]

CoCat edit

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)[reply]

Monobooking? edit

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)[reply]

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)[reply]
Done. Restart browser, refresh cache, logout & back in, etc. --Connel MacKenzie T C 22:03, 14 June 2006 (UTC)[reply]
Amazing. — Vildricianus 22:15, 14 June 2006 (UTC)[reply]
Any chance you fix the thing when there are { brackets } in the game? — Vildricianus 21:57, 16 June 2006 (UTC)[reply]
.7B and .7D. You got it... --Connel MacKenzie T C 22:04, 16 June 2006 (UTC)[reply]
Whoops. That isn't right. Rolling back. --Connel MacKenzie T C 22:11, 16 June 2006 (UTC)[reply]
Mmm. Expected something like that. Too bad. — Vildricianus 22:15, 16 June 2006 (UTC)[reply]

WOTD RSS feed edit

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)[reply]

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)[reply]
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)[reply]
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 Wiktionary: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)[reply]
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)[reply]
Possible. Dirty tricks though, and less than desirable. — Vildricianus 17:51, 16 June 2006 (UTC)[reply]
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://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)[reply]
Excellent. So something like Wiktionary: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)[reply]
I copied my RSS experiment to Wiktionary:WOTD.rss so that other people can work on it. That makes its URL
http://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 Wiktionary: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)[reply]
About the small bug: I can't do it any differently, but perhaps someone else can, fiddling with {{SUBPAGENAME}}. — Vildricianus 13:33, 18 June 2006 (UTC)[reply]

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)[reply]


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)[reply]


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)[reply]

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 m:Mailing lists. --Connel MacKenzie 04:47, 7 January 2007 (UTC)[reply]

I just found out that a search API already exists, initially conceived August 2006: m: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:) [1]. For more information on the search API, see: m: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)[reply]
YES!! One step closer!!!--68.126.7.187 06:27, 18 January 2007 (UTC)[reply]
Ugh. You still have to parse templates from that point. (Special:ExpandTemplates can probably just do {{Word of the day}} for you.) --Connel MacKenzie 06:57, 18 January 2007 (UTC)[reply]

More on classes for support of Unicode ranges edit

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:

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

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)[reply]

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)[reply]
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. — Hippietrail 19:11, 17 June 2006 (UTC)[reply]
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
"/* Latin Extended-B" → "/* Latin Extended-B */" --teb728 01:26, 18 June 2006 (UTC)[reply]
Ahhh. I got that one. --Connel MacKenzie T C 05:11, 25 June 2006 (UTC)[reply]

bot approval policy? edit

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)[reply]

This is a very good example of how it works :-D. Ask on the BP. — Vildricianus 10:57, 17 June 2006 (UTC)[reply]
If that's a good example, I'd hate to see a bad one! :-) —scs 16:36, 17 June 2006 (UTC)[reply]
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)[reply]


The new templates: implementation edit

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 {{en-verb}}? 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 {{en-verb}} (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 {{en-verb|itemiz|es}} as well as {{en-verb|itemizes|itemizing|itemized}}. 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)[reply]

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 "{{en-verb|itemiz|ing}}" 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)[reply]

Template problems edit

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)[reply]

Oopsie, yes, that's wrong. There should be .infl-table {display:block} 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)[reply]
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 <div> tag. See {{en-noun}}. — Vildricianus 14:07, 18 June 2006 (UTC)[reply]

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

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)[reply]

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 {{en-noun}}. The verb template still needs the same treatment, but I'm kind of busy right now. — Vildricianus 17:51, 18 June 2006 (UTC)[reply]
OK. I applied your changes to Template:en-noun to {{en-verb}}. Please, anyone, let me know if pages using either template look different from your expectations. Rod (A. Smith) 18:18, 18 June 2006 (UTC)[reply]

StringFunctions edit

I may as well announce this widely: StringFunctions now appear to be available for Wikimedia projects, which means for example that {{vandal}} 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)[reply]

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)[reply]
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)[reply]

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)[reply]

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)[reply]

Bot idea for Webbie edit

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)[reply]

Various things can be done with Webster's 1913. Entries completely from Webster's are supposed to have {{webster}} 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)[reply]
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)[reply]
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)[reply]

Etymology templates edit

Transcluded. — Vildricianus 18:53, 23 June 2006 (UTC)[reply]

Grrr edit

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)[reply]

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)[reply]
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
#wpTextbox1 { font-family: font name !important; }
in your monobook.css. --teb728 02:01, 22 June 2006 (UTC)[reply]
Clear your cache. Do you still have the problems? I see the above things in bold. — Vildricianus 15:25, 21 June 2006 (UTC)[reply]
Widsith, try the change I just suggested on my talk page. (Actually a change I just put in {{Latinx}} may have made my previous suggestion work.) --teb728 22:23, 21 June 2006 (UTC)[reply]
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)[reply]

Magically appearing links edit

I have just added a comment to Wiktionary:Beer parlour#What is the right way to cite a usenet post?, an RFC?, 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)[reply]

Looks like a feature of wiki magic. Davilla 15:11, 21 June 2006 (UTC)[reply]
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)[reply]
MediaWiki:Rfcurl. — Vildricianus 10:52, 22 June 2006 (UTC)[reply]
Also MediaWiki:Pubmedurl. PMID 1 --Connel MacKenzie T C 14:14, 22 June 2006 (UTC)[reply]
And ISBN 000000 of course. — Vildricianus 14:17, 22 June 2006 (UTC)[reply]

Category:Old anonymous user pages edit

We should get rid of the {{old-utp}} 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)[reply]

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)[reply]

WT:RFC edit

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)[reply]

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)[reply]

Search special page correction edit

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)[reply]

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)[reply]
Status: {{urlencode:$1}} does not work. At all. --Connel MacKenzie T C 19:19, 24 June 2006 (UTC)[reply]
Are you sure? We need a place to test it without disrupting Noexactmatch. — Vildricianus 19:30, 24 June 2006 (UTC)[reply]
Bah. {{urlencode:$1}} 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)[reply]
Have you tried {{newtemp|$1}} where Template:newtemp contains {{urlencode:{{{1}}}}} ? --teb728 22:22, 24 June 2006 (UTC)[reply]
Doesn't work. Newtemp contains %7B%7B%7B1%7D%7D%7D. Urlencode is too strong, it just encodes {{{1}}}. — Vildricianus 22:27, 24 June 2006 (UTC)[reply]

To summarize: we need to edit $1 using a preloaded template. The closest I got thus far was using //en.wiktionary.org/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 {{urlencode:just this}}. {{urlencode:$1}} doesn't work, though, which is the problem

Quite close again was {{SERVER}}/w/index.php?title=:<includeonly>{{urlencode:</includeonly>$1<includeonly>}}</includeonly>&action=edit&preload=Template:new_en_basic, but not good enough either. — Vildricianus 22:38, 24 June 2006 (UTC)[reply]

Oh, I forgot to try using <nowiki>$1</nowiki>...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)[reply]
OK, how about {{newtemp|$1}} where Template:newtemp contains <includeonly>{{urlencode:</includeonly>{{{1}}}<includeonly>}}</includeonly> ? Essentially that works as expected at User:TEB728/temp2 --teb728 23:35, 24 June 2006 (UTC)[reply]
Result: we end up editing "{{{1}}}", which gives an error. — Vildricianus 10:46, 25 June 2006 (UTC)[reply]

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

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)[reply]

rfvpassed merge edit

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 Wiktionary:Requests for verification/archive, right? Cheers. — Vildricianus 16:07, 22 June 2006 (UTC)[reply]

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

No bot needed: just edit {{rfvpassed}}, then wait 5 minutes, right? --Connel MacKenzie T C 19:02, 24 June 2006 (UTC)[reply]

Strange problems with non-breakig spaces in {{italbrac}} edit

Please see the discussion in the template's talk page, and look at computer for an example. — Hippietrail 02:38, 28 June 2006 (UTC)[reply]

Wiktionary:Project- pseudo namespace edit

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)[reply]

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)[reply]

Moving of indexes edit

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 Wiktionary: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)[reply]

Most moving done now... Chinese and Finnish remain. — Vildricianus 15:21, 1 July 2006 (UTC)[reply]

Template:subpages edit

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

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

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)[reply]
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)[reply]
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)[reply]

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. {{Special:Allpages}}, {{Special:Newimages}}, {{Special:Newpages}}, {{Special:Prefixindex}}, {{Special:Recentchanges}} all generate the desired results. Not very useful now (except for this template), but perhaps later on. — Vildricianus 11:01, 2 July 2006 (UTC)[reply]

Newarticletext redirection edit

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)[reply]

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)[reply]
I've always used {{see}} 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)[reply]

Slow grease pit? edit

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)[reply]

There is no page of this size. I'll calculate its size and report back. — Vildricianus 17:42, 3 July 2006 (UTC)[reply]
It's only 285 kb. The BP has been bigger at times. — Vildricianus 17:53, 3 July 2006 (UTC)[reply]

Wiktionary User Preferences redux edit

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 Wiktionary: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)[reply]

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)[reply]
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)[reply]
Which "ugly foriegn language conjugation tables" ?? Talking about mine? — Vildricianus 09:41, 4 July 2006 (UTC)[reply]
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)[reply]
These are all mine, yes. — Vildricianus 08:35, 5 July 2006 (UTC)[reply]
No, I was thinking of the Spanish conjugation templates. --Connel MacKenzie T C 07:30, 7 July 2006 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
Various updates:
  1. I'm not going to have separate files for each CSS customization. Each item will be a document.write() which can't seem to transclude templates, other pages or anything.
  2. One hideously ugly javascript subpage (hideously ugly in concept, not appearance) will do the manipulation of the Preferences page. This does the klugyest parts of it all, to effect the onClick() stuff.
  3. One MediaWiki:Monobook.js subpage will do the document.write()s, based on the cookies. It seems to work, for hiding the sitenotice, so my concerns about sequence of iteration seems moot.
  4. Using buttons is ugly. If anyone things of a better way, please let me know.
--Connel MacKenzie T C 01:43, 7 July 2006 (UTC)[reply]
  • Update: IE seems to be much pickier. Technique is not working there. But other browsers seem to be OK? Cleanup on the page/buttons is welcome. Other ideas on how to do this are even better. --Connel MacKenzie 04:59, 10 July 2006 (UTC)[reply]

Is this working for anyone besides me? I'd rather not have it go a month, with no one noticing that it may be broken (again.) --Connel MacKenzie 10:05, 11 July 2006 (UTC)[reply]

Archiving this page again edit

Becoming quite big, with more and more inactive topics. I've done some things now:

  1. Large discussions with high revisitability get their own subpage. They're listed in the topmost section #Archived topics. Discussion won't likely proceed on those pages, but at least similar topics or followups should be archived there, not anywhere else. So this topic, when archived, will end up at /Archiving this page. Purpose is to have a set of clearly defined subpages that will serve the purpose of archiving this page by topic instead of chronologically, which is the only way to save its archives. Please keep this in mind, and give any topic you start here a decent and clear title (like this one)!
  2. Small topics go to /Various topics. But not if they could end up on any of the above-mentioned subpages. And not if a number of them could form their own topic on a new subpage. May be revisited at all times, but here please, not there.
  3. Stupid topics get removed (the emulator thing? wtf?)
  4. All subpaged stuff is visible and browser-searchable at /All topics. This will become so inordinately large that we could start a cross-wiki contest for biggest page. Please don't subst: the rubbish in there, as that would defeat its purpose.

— Vildricianus 10:30, 4 July 2006 (UTC)[reply]

Disclaimer: none of the idealism presented above has been worked at yet. I haven't even thought about sorting out which should go where. That'll be for another day, so don't bother if you see most subpages dealing with the very same topic. — Vildricianus 10:35, 4 July 2006 (UTC)[reply]

WOTD edit

How are the WOTDs holding up? I haven't seen an update on whether this is working (well) or not, in a while. --Connel MacKenzie T C 01:40, 5 July 2006 (UTC)[reply]

Trust them to be fine as long as you don't hear about them :-). — Vildricianus 08:29, 5 July 2006 (UTC)[reply]
Though I've been busier off-line (and correspondingly scarcer here), I've made sure that we're always running with a queue two to five weeks ahead of the current date. Right now, we're set through the end of September. I'm planning to put up a personal essay on my user page concerning WOTD. --EncycloPetey 01:41, 24 July 2006 (UTC)[reply]

Template:cattag reform edit

Davilla seems to be absent right now, but I'd rather not let {{cattag}} linger around in its current shape. The longer we use it this way, the harder it'll be to overhaul it, which is actually quite necessary. In this post, I'll restate what {{cattag}} needs to do, and what I've already been doing to greatly simplify its processes.

The following situations should be efficiently dealt with by {{cattag}}:

  1. Template:cattag A simple parameter that is already a template.
    {{cattag|transitive}} (This should equal {{transitive}} exactly.)
  2. Template:cattag A simple parameter that is not yet a template, and which needs to show up red in order to define whether it takes a category or not.
    {{cattag|tramplitive}} (This should also equal {{tramplitive}} exactly.)
  3. Template:cattag Multiple parameters that already exist as templates.
    {{cattag|transitive|obsolete}}
  4. Template:cattag Multiple parameters of a mixed nature (some exist, some don't).
    {{cattag|tramplitive|obsolete}}
  5. Template:cattag Multiple parameters that not yet exist as templates.
    {{cattag|tramplitive|oprolete}}

As is clear, the current problem with {{cattag}} is that it's a) far too complicated to perform these simple actions, and that it calls way too many other templates to do so; b) that it doesn't display new or unseen parameters as red. In the above case "tramplitive" appears to be an accepted term, which it is not of course.

Main problem is then that cattag independently determines which parameters link to a category and which don't. By default, any new parameter like "tramplitive" takes no category. It is not easy to find out how to make "tramplitive" link to a category.

The proposed scheme is in an embryonic stage at one of my infamous subpages: User:Vildricianus/PageX/19. I've reworked the idea to let this template, which intends to replace cattag sooner or later, take the parameters as templates; i.e. {{{1}}} displays simply as {{{{{1}}}}}.

Example: {{User:Vildricianus/PageX/19|tramplitive}} gives (Template:tramplitive). Now {{User:Vildricianus/PageX/19|transitive}} currently doesn't display properly, because the {{transitive}} contains the entire cattag/italbrac thing, which doesn't work with my scheme. In stead, it should simply contain 

transitive

If it were to have a category, that would be: 

transitive<includeonly>[[Category:Transitive]]</includeonly>

The italbrac stuff is done by the PageX/19 template itself, severely simplifying the entire thing.

Disadvantages: few. Each parameter has to be a template, but this makes everything controllable. I think Davilla's idea was to eliminate all the individual templates, but I don't think that'll prove very efficient. KISS is the Wiki principle to adhere to.

Note that I haven't been able to experiment fully with it, because all templates are occupied by the italbrac/cattag madness currently. Note also that I don't want to recklessly undo Davilla's work. I'm for starters not going to touch the thing before he has commented here.

Furthermore, this overhaul may, but not necessarily, involve a change in {{italbrac}}. That one is currently involved in the cattag process, taking parameters et al, which it shouldn't. It should merely put the brackets around the contents. If people are reluctant to have {{italbrac}} changed, I'll use my own "clean and simple" version (User:Vildricianus/PageX/italbrac) for it.

DISCLAIMER: neither tramplitive, nor oprolete are valid terms, and are by no means intended to ever be so.

Thoughts, ideas, comments, brainstorming etc. is welcome, required, and necessary. — Vildricianus 15:27, 7 July 2006 (UTC)[reply]

Just because User:Davilla is not as rabid as we are, does not mean he's absent. Other than that, I strongly agree with everything you indicated above. I've made many of the same observations (less eloquently) in his talk page and here. For {{cattag}} and {{italbrac}}, KISS should be the overriding principle...particularly with regard to the list of "Templates used on this page:" below an edit box. --Connel MacKenzie T C 17:41, 7 July 2006 (UTC)[reply]
By all means use {{italbrac}} if it helps simplify things, but if it complexifies things, then just use italbrac's CSS tags in an identical way and all will be well and good. — Hippietrail 19:44, 7 July 2006 (UTC)[reply]
Actually I have been absent, as I have been busy with work for the last couple of weeks. I do agree that cattag is much too complicated as it is now. In fact the primary reason for being so complex is to avoid multiple parenthesis!! Vild's example of {{cattag|transitive|obsolete}} should read as "(transitive, obsolete)" rather than {{transitive}} + {{obsolete}} = "(transitive) (obsolete)". Hence this will be greatly simplified with string functions.
In the meantime I will try to roll in as many of the templates as I can, including italbrac if that format has been settled upon. Unfortunately calling other functions (templates) is one way to make code more transparent, and the fuss about all the extra templates listed, particularly subroutines (subpages), puts the two aims at odds with each other.
A third reason the cattag code is so complicated is that it does exactly what Vild suggests above. I had not intended to delete all of the individual templates; in fact they are used when they exist. If {{cattag|tramplitive|oprolete}} appears on a page, then the page will automatically be categorized once the templates {{tramplitive}} and/or {{oprolete}} are defined. Furthermore if {{tramp}} expands to "tramplative" then {{cattag|tramp}} should too.
The one thing I haven't incorporated is linking. The style had been inconsistent, with some tags linking and others not. What should a tag link to when the template exists? the dictionary definition? the category? What should it link to when it doesn't? the non-existant template? I disagree with the latter since I'd want to be able to do {{cattag|physics|by analogy}} without having a red link on "by analogy". This might require some discussion.
When I have time I will be very interested in looking at Vild's suggestion, especially how he incorporates cattag with italbrac. 59.112.36.72 18:28, 11 July 2006 (UTC)[reply]
My solution will actually handle most of the stuff in the same manner, except for that last bit. {{cattag|physics|by analogy}} will display Template:by analogy, redlinked of course. I've been wondering whether we should have a finite set of that kind of modifiers, like "hence", "specifically", etc. — Vildricianus 20:37, 11 July 2006 (UTC)[reply]
The problem, as I see it, is that {{cattag}} should never not link the category requested. It needs to provide the red link. Once that correction is made, most of the complexity of the current cattag is sidestepped. --Connel MacKenzie 22:03, 11 July 2006 (UTC)[reply]
Eh? That's what my proposal proposes, right? — Vildricianus 06:58, 12 July 2006 (UTC)[reply]
Correct. It is also the opposite of what User:Davilla said just above. --Connel MacKenzie 04:13, 13 July 2006 (UTC)[reply]
Hmm, I thought I asked more questions than anything. I also thought Vild was linking the template rather than the category. Anyways the change would be made at {{cattag/category}} if you could clear this up for me. 59.112.45.45 18:16, 18 July 2006 (UTC)[reply]

Perhaps a compromise would be to add nine parameters: italibrac parameters: i1=, i2=, i3=... Is that better or worse? --Connel MacKenzie 07:24, 13 July 2006 (UTC)[reply]

Perhaps. — Vildricianus 07:46, 13 July 2006 (UTC)[reply]
No, that's pretty much a good idea, Connel. Look at User talk:Vildricianus/PageX/19, that's how it would go. Pretty good. — Vildricianus 08:10, 13 July 2006 (UTC)[reply]

One difficulty Davilla pointed out is that {{transitive}} should continue to be used on its own. That's not possible with my proposed technique. Although this could be sidestepped by changing all {{transitive}} into {{cattag|transitive}}.... ? — Vildricianus 09:44, 19 July 2006 (UTC)[reply]

Etymology template? edit

Does a template for producing
====Etymology====
i.e., four equals signs, "Etymology", four more equal signs, and a carriage return? And something that does not make you type out "Etymology", something like {{e}} or {{ety}}--Allamakee Democrat 21:37, 7 July 2006 (UTC)[reply]

I'm not sure I fully understand your question, but we don't use that kind of templates here. — Vildricianus 21:46, 7 July 2006 (UTC)[reply]
We don't use section heading templates (as most of the other language Wiktionaries do) as that breaks section editing, counter-intuitively. Most contributors here rely on section editing, so turning it off (even for a single entry) is not viable. --Connel MacKenzie 23:37, 7 July 2006 (UTC)[reply]

Non-English interface and Monobook.js edit

I have my preferences set to use Swedish as interface language. When trying to access an non-existing article, Connel has just fixed it so that the previously broken (used a template) version of MediaWiki:Noexactmatch/sv works. However there is a remaining problem that seems to be related to the Monobook.js file.

The input boxes should be hidden, but are not. When adding &uselang=en to the url, I get the English buttons, but still with the input boxes visible. Changing user preferences to use English as interface language, both plain Noexactmatch and with &uselang=sv shows up correctly, i.e., with hidden input boxes.

Now there is no local version of MediaWiki:Monobook.js/sv, and what is shown in the system messages list is the svn version, which does not have the java snippet that is used to hide the input boxes added.

This leads me to a few perhaps erronous conclusions:

  1. uselang is not respected afa .js is concerned
  2. the fallback line for .js files is: local language dependant (not found), central language dependant (found, used), local English file (correct, but never reached)

I tried to test if my conclusions were correct by adding the missing js-snippet to my User/monobook.js, but that did not solve my problems, and is what makes me doubt my conclusions (or I just added it wrongly to my file...). :(

I hope someone here can help me sort this out, and if what is necessary is to simply copy the existing MediaWiki:Monobook.js to MediaWiki/Monobook.js/sv, then help me out by doing so. *smile* --sanna 08:48, 8 July 2006 (UTC)[reply]

Your conclusions were correct: if another language is specified in the userprefs, MediaWiki:Monobook.js doesn't load. I've written MediaWiki:Monobook.js/sv to import the code of the central JS file. — Vildricianus 09:23, 8 July 2006 (UTC)[reply]

I'm flummoxed edit

O.K. How do I link this {{rfvfailed}} to this WT:RFVA. I haven't a clue. Can anyone help? Thanks Andrew massyn 14:07, 9 July 2006 (UTC)[reply]

When I was doing RFV cleanup, the method was top copy the archived text to a sub-page of WT:RFVA, and put the monthly summary on WT:RFVA itself. Template {{rfvfailed}} was only used when senses failed the process, and was added to the talk page of the kept entry. --Connel MacKenzie 05:02, 10 July 2006 (UTC)[reply]
Thanks. I'll work on it. Andrew massyn 17:22, 10 July 2006 (UTC)[reply]

Statistics work-arounds edit

Two things that are counted "incorrectly" (in my opinion) on en.wiktionary are "* Common misspelling of..." and "plural of ...". Developers have expressed a desire to eliminate these statistics, rather than correct them. Rather than push that issue, I'd like to work around these defects as so:

  1. For entries that exist only as a "soft" redirect for a common misspelling, that exist in the form of a one-line entry that looks like * Common misspelling of ... I'd like to replace them all (via 'bot from my my account or something) with {{misspelling|description|term}} with the template adding the [[ ]] around term to prevent them from being counted in the statistics.
  2. For entries that exist as "stub" entries for a plural of... form, I'd like to change the template to no longer wikify the term. So, instead of {{plural of|bed}} I'd 'bot change them to {{plural of|[[bed]]}} so that they are counted in the statistics (currently they are not.)

If no one disagrees, I'll create {{misspelling}} and change {{plural of}} on Friday, (2006/07/15) and effect these changes.

--Connel MacKenzie 16:13, 10 July 2006 (UTC)[reply]

  • I'm still confused by the Misspelling treatment... ==English== statement or not? ===POS=== statement or not? A true descriptive dictionary doesn't treat misspellings as misspellings I'd say. — Vildricianus 12:03, 12 July 2006 (UTC)[reply]
  • Me too. Connel very strongly feels that the ==English== heading defines everything under it as a member of the set of correctly spelled English words. I feel very strongly that it defines nothing and is merely useful for grouping. I do not believe any official discussion or vote ever took place to put Connel's point of view on the matter into practice. I have expressed my strong feeling that this approach is inconsistent as "ghost words" such as dord are also not members of the set of correctly spelled English words yet for some inexplicable reason those do get an ==English== heading. — Hippietrail 19:30, 12 July 2006 (UTC)[reply]
  1. While it is true there certainly was never a vote about it, I am not opposed to one. I think it was discussed however, prior to our discussion about it on your talk page last year.
  2. That aside, how is progress on the "multi-level" dictionary concept? This seems to be a minor subset of that philosophical shift.
  3. If, for pragmatic reasons, or as the result of a vote, they become =English= heading entries, I still think that "{{misspelling of}}" type entries should not be included in the statistics. Therefore, those templates should do the wikification. On the other hand, {{plural of}} type entries, IMHO should be included in the statistics (they currently are not) therefore should not do the wikification.
--Connel MacKenzie 19:45, 12 July 2006 (UTC)[reply]
I agree 100% that no matter what is decided as far as language headings and misspelling entries that no kinds of non-words should be counted statistically as words, including both misspellings and ghost words. I haven't done any real work on the multilevel dictionary concept as I'm in the very last days of my trip and that has my highest priority right now - but soon I'll be back in the real world with lots of spare nerd time! — Hippietrail 20:06, 12 July 2006 (UTC)[reply]
I have a strong feeling that (even though I supported) this workaround might not be the best way to do it. Have you already asked brion whether he could adapt the code or fix something? If not, we might want to do that first. — Vildricianus 19:56, 12 July 2006 (UTC)[reply]

tool for filling the missing articles edit

Hi everybody, I'm from Slovak Wiktionary and I have developed a tool to make wiktionaries larger and more complete. It works this way. Take an article, for example marriage. In the translations, there are few missing links (more or less, it depends on article). In the marriage article, there are at this moment these "red links": for czech, finnish, italian, portuguese and other languages. My program aides wiktionarians to make pages for these links. The pages are quite simple, they should look like this: 

==Slovak==
===Noun===
'''svadba'''
# [[marriage]]


-so, there is name of the language, word type, the word itself and finally the meaning. In the program, you give it the link to desired article (in our case it is en.wiktionary.org/wiki/marriage, but you may use integrated browser to navigate there), then it finds "red links", and for each one you can select which language is it, which word type is it, then it generates the wiki text, copies it into clipboard and navigates you to new page, where you may paste the text and save changes. So, instead of you having to spend much time to create pages for example 20 missing translations for some word, with this tool you just click some 20-60 times and the pages will be generated.

The thing I am asking is, would anybody be interested in using it? Because it is a time-saver, and it helps the wiktionaries to expand.

Just comment here.

Regards, Sedimin 16:13, 10 July 2006 (UTC)[reply]

The discusstions regarding User:TranslationBot were very heated on this topic. Without adding the gloss, the approach you suggest is not workable. With the gloss, there is still violent, militant opposition, much to my dismay. --Connel MacKenzie 16:27, 10 July 2006 (UTC)[reply]
Why this is not workable? And what do you mean by without adding the gloss? No offence, I'm just curious. I have read the discussion... 195.28.142.198 10:23, 11 July 2006 (UTC)[reply]
Wiktionary:Beer parlour archive/March 06#Request for bot status: TranslationBot. --Connel MacKenzie 21:29, 11 July 2006 (UTC)[reply]

New special characters set in Edittools edit

What about adding all useful templates in a submenu "Template" in Edittools? I'm specifically thinking about {{plural of}} and friends, which are a hassle to type. Two clicks is way more efficient, certainly with the cookie that remembers the right set. — Vildricianus 16:38, 10 July 2006 (UTC)[reply]

I've held off from doing such a thing, as I think a toolbar approach for them would be better. But rather than wait forever for me, why don't you Be Bold with it. It is a good idea. --Connel MacKenzie 16:40, 10 July 2006 (UTC)[reply]
Of course, the conversation above (regarding the same family of templates) is somewhat relevant. These can be changed at that time, as well. --Connel MacKenzie 16:42, 10 July 2006 (UTC)[reply]
The toolbar is not perfect. It's too intrusive for people who don't need it, certainly on 800x600 screens where more than 15 additional buttons need a second line. That's why I thought the edittools thing might meet less opposition than changes to the toolbar. — Vildricianus 16:48, 10 July 2006 (UTC)[reply]
Perhaps. I'm still undecided, and open to other ideas on this one. --Connel MacKenzie 20:40, 10 July 2006 (UTC)[reply]
Done (last menu option). I've only made a small selection, but more can be added of course. — Vildricianus 17:11, 10 July 2006 (UTC)[reply]
Well done, thank you. --Connel MacKenzie 20:40, 10 July 2006 (UTC)[reply]
I suppose the other benefit of them being JS buttons is that you could also have the "<root-form>" also placed in there, auto-selected. --Connel MacKenzie 20:43, 10 July 2006 (UTC)[reply]
Pardon? — Vildricianus 20:45, 10 July 2006 (UTC)[reply]
With an image button you could insert {{plural of|<root form>}} with the characters "<root form>" pre-selected. A bit more intuitive, that way. --Connel MacKenzie 20:49, 10 July 2006 (UTC)[reply]
P.S. The Russian Wikipedia had a way of allowing ^Z to work for these things, too. --Connel MacKenzie 20:51, 10 July 2006 (UTC)[reply]
Mm. Yours to be bold with the button idea then. Although the cursor should end up at the right spot now as well. I just discovered that it doesn't in IE. Also, people who don't know that they have to insert the root form there should use the preload templates anyway. — Vildricianus 21:00, 10 July 2006 (UTC)[reply]
Well, while you're there, are you adding the various inflection templates as well?  :-)   --Connel MacKenzie 09:50, 11 July 2006 (UTC)[reply]
Should I move the templates set to the very first position? That might encourage people to use the right templates. — Vildricianus 10:05, 11 July 2006 (UTC)[reply]
I'd think not, but I'm willing to listen to other opinions. --Connel MacKenzie 10:15, 11 July 2006 (UTC)[reply]
I'll do it anyway and see what reactions it evokes. — Vildricianus 07:00, 12 July 2006 (UTC)[reply]
Perhaps rename the cookie too, to indirectly reset everyone's cookies? It just defaulted me to Welsh! --Connel MacKenzie 19:35, 12 July 2006 (UTC)[reply]

Two thoughts: 1) can "Templates" and "Latin/Roman" be combined into one, called "Default"? 2) Can we rename the cookie, so everyone is dropped into "Default" for their next edit, please? --Connel MacKenzie 07:18, 13 July 2006 (UTC)[reply]

Block succeeded page edit

This page has problems with it's link to #2 block log and #3 IP blocklist again. MW software must have changed the behavior for $1 again? Someone fix please, or remind me to. --Connel MacKenzie 23:09, 12 July 2006 (UTC)[reply]

Whoever fixed it: thank you. --Connel MacKenzie 03:17, 13 July 2006 (UTC)[reply]

Various MediaWiki:Monobook.js cleanups edit

Looking at zh:MediaWiki:Monobook.js I am in awe. (fr:, de:, he: ain't so shabby either.) I'd like to synchronize the various features that are growing in the other language Wiktionaries into ours. Any objections? One thing that should be standardized across the language wikt:s is zh:'s excellent cross-browser method of moving Hippietrail's edittools selection thing to the top of the edit box, where it belongs. Another, would be adding the 10-15 additional toolbar buttons that everyone should have. (I'll leave my inflection buttons out of it, for some time to come.)

I haven't looked into how other language Wikts deal with skins. But my gut feeling is that it is moot - that 99% of the active users (and all of the unregistered users) use Monobook.

I'd also like to add an "auto-format" button that calls all of the A) uncontroversial and B) completely programatic formatting changes that Vild and I have developed in our personal monobooks. (E.g., 1) wikify or de-wikify languages, 2) correct "==noun==" to "===Noun==="; "==Further reading==" to "===Further reading=== ", 3) "{{-nl-}}" to "==Dutch==" etc.)

Comments? --Connel MacKenzie 07:09, 13 July 2006 (UTC)[reply]

Lots of comments. Too many to post them all at once, but I'd like you to keep in mind a couple of things when you're working at it:
  1. Extra toolbar buttons are good, but remember that from 15 onwards, they produce a second line (which is ugly and space-inefficient unless you add 40 more then. So 14 would be a good number to start with. I can recommend User:Vildricianus/editbar.js as a good starting point.
  2. Careful with the autoformat. Things like wikify/dewikify don't seem to deserve universal implementation. Perhaps I'll try to make some selection of replacements that are good candidates later today.
  3. Additional ideas: probably the most useful thing my JS does is adding a UTC clock. Making this easily available (perhaps through /Preferences then) would be great. Also, if MediaWiki:Monobook.js could contain some functions and frames that make it much easier to add links to the navbar, toolbox and personal bar, that'd be great as well.
Good luck. — Vildricianus 08:03, 13 July 2006 (UTC)[reply]

Wiktionary:Bot policy edit

I've thrown up a tiny embryonic start of a policy page for bots, but the prose is horrible. And I can't remember Richardb's template naming scheme for policies. Please help out if you can. --Connel MacKenzie 19:34, 13 July 2006 (UTC)[reply]

New logos? edit

Could someone please figure out, and implement, a way to replace our current logo with an animated GIF or something, of all the new logos (or just your favorites)? TIA --Connel MacKenzie 07:33, 15 July 2006 (UTC)[reply]

Header vs Category tool edit

Question 1- Is there any tool available (or would any of you be interested in designing one) that would allow someone to find entries with given headers, without appropriate category tags? Id est, a tool that would figure out if there are any words with the headers ==English== and ===Noun===, for which none of the category tags include the words "English" (or "en") or "nouns". Then, the user could figure out whether the entry needed to be tagged (or if it happened that the header was 'Slovene' and the tag was 'Slovenian nouns', the entry didn't really need a tag, asf), and what to tag it with. Beobach972 16:21, 15 July 2006 (UTC)[reply]

If you know anything about programming or databases, there's an XML dump available at http://download.wikimedia.org/enwiktionary. Lots of useful stuff can be done with it. If you're not a computer geek, perhaps someone will show up to fiddle with the dump and provide some list or the like of entries that fullfil or don't fullfil any criteria. — Vildricianus 16:53, 15 July 2006 (UTC)[reply]
Oh, cool. I'll poke around in it. Beobach972 17:06, 15 July 2006 (UTC)[reply]

Old Prussian template name scheme edit

Question 2- I'm not quite sure how to make sense asking this, but I'll give it a shot. Connel MacKenzie suggested I ask this here : is there any naming scheme for templates? What is it? I have asked EncycloPetey to delete all of the old Old Prussion templates; because they need to be rehauled totally, format, layout, consolidation, etc, including the names. (I've seen all the fuss over the Swedish and Finnish templates, but because EncycloPetey, my brother, and I are the only ones on here who speak Prussian, I think we can get away with taking the direct route.) Connel Mackenzie suggested that the template names should include a prefix of the ISO code. (The ISO-639-2 code for Prussian is 'bat', the ISO-639-3-DIS code is 'prg'.)

In shorter words, tell me what they should be named when they're rebuilt : eg, Prg-n-01-m (where N stands for Noun and M for Masculine) etc, or what? Beobach972 17:06, 15 July 2006 (UTC)[reply]

Yes, language-specific templates should include (and usually start with) the ISO language code. The main "part of speech" templates (a.k.a. "inflection" templates) should then have a dash and a clear indicator (in English) of the part of speech. The whole word "noun" should be spelled out, because "n" may appear to mean "neuter" to the uninitiated. What does the "01" component mean? Rod (A. Smith) 18:23, 15 July 2006 (UTC)[reply]
Also, to be clear, you are talking about the template that is used immediately after the "===Noun===" heading, right? That template shows only the headword and a few key inflections. If you're instead talking about a complete declension template, e.g. for use in a "===Declensions===" section, it would be helpful to insert "-decl" after the language code. Rod (A. Smith) 18:26, 15 July 2006 (UTC)[reply]
Ok, sounds good. I'm referring to both ("noun-header" and "declension-header"), by the way. So, the "noun-header" ones will be something to the effect of Prg-noun-m-01, Prg-noun-m-02; Prg-noun-f-01; etc (?). The "full" (declension-header) ones will be Prg-decl-noun-m-01, etc (?). In full, Prg-noun-m-01 means this : the word is Prussian (the Prg component), it is a noun (noun), the dictionary-form is masculine (m), and it is the "first" declension (01). (Now, since there is no official language regulation, which declension gets labelled as the "first declension" is purely volitional -- but it won't hurt anyone.) That will be (unless you know of a better way of doing this) further specified as "01", "01mf", "01mn", or "01mfn". (01 meaning that it occurs only in the masculine. 01mf meaning that, though the dictionary/base form is masculine, it can also be declined into the feminine; etc.) Beobach972 21:24, 15 July 2006 (UTC)[reply]
For verbs, I assume thus Prg-verb-XXXX (where XXXX is the ending-type / verb-type, eg ntun, itun, twei, etc) for the basics that go directly on the page, and ... what should the "full" template that'll go on the "/conjugation" part be called? (See this for the basics (though actually in this example it's a bit too long) & the "full" conjugation). How about Prg-verb-XXXX-full? And adjectives and all the other parts of speech will be named similarly? Beobach972 21:24, 15 July 2006 (UTC)[reply]
Browsing Category:Conjugation and declension templates, one finds that each language seems to choose a different style. To some extent, that makes sense since, e.g. considering that certain classes of Japanese adjectives have conjugations (not declensions). Anyway, for verbs (of conjugation-rich Indo-European-descended langauges), the conjugation template pattern that seems to be emerging, and the one that matches recommended the section headings, yields "prg-conj-XXXX". The important convention to follow is to begin conjugation templates with the ISO code followed by "-conj" and to begin declension templates with the ISO code followed by "-decl". Following "-conj" and "-decl", however, it may make sense for each language to choose its own template name components. Rod (A. Smith) 22:07, 15 July 2006 (UTC)[reply]
(BTW, I'd be happy to lend a hand if you'd like.) Rod (A. Smith) 22:10, 15 July 2006 (UTC)[reply]
Alright, that should be easy enough (to figure out what to call a declension and what to call a conjugation). Nouns, pronouns, 'enclitics' (which do not actually join to other words, despite the name), and adjectives decline. Verb participles decline masc/fem, but I think that the forms should be included as part of the extended verb templates (see this). Verbs conjugate. Adverbs ... hmm, I'll ask Vy about adverbs. And, thank you! You mean help organise/name it all, or help make the layouts/formats? Either way, thanks. For the old layouts (the ones about to be deleted), I "stole" templates from the German wiktionary. Beobach972 20:33, 16 July 2006 (UTC)[reply]

another silly question edit

Hello, techies! (Asking a question here is like coming down to the basement to talk to the IT department.) Anyway – my fonts have changed suddenly. Specifically the level 2 header font which I set in my CSS has abruptly stopped working. Has there been some change to account for this which I wasn't aware of, or shall I put it down to random silliness on the part of my laptop? Widsith 19:49, 16 July 2006 (UTC)[reply]

I too have noticed that the fonts/headers are different. I think someone must have upgraded the site. But no, it's not your laptop (or if it is your laptop then it must be a similar fluke effecting my computer too). Beobach972 20:02, 16 July 2006 (UTC)[reply]
Assuming you use the monobook skin, I would guess that you're seeing the results of Vild's test to change header sizes to make them better balanced. I think the test is an attempt to fix the level 6 header, which was too small. Rod (A. Smith) 20:15, 16 July 2006 (UTC)[reply]
Very weird. Using Widsith's CSS, I don't see anything unusual, and the level 2 headers have the other font as is specified. Try setting h2 { font-family: "Zapfino", serif !important }, which may solve it. Anyone else sees undesired results? — Vildricianus 08:30, 17 July 2006 (UTC)[reply]

Swahili noun inflection line template edit

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)[reply]

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 [[Category:Swahili nouns]] to the file. —Stephen 18:25, 18 July 2006 (UTC)[reply]
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)[reply]
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).[reply]
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)[reply]

Shakespeare and Bible template edit

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.

{{Shakespeare|Hamlet|2,3}} would generate [[Category:Hamlet|act 2, scene 3]] as part of supercat [[Category:Shakespeare quotes]]

{{Exodus|2:1-10}} would generate category [[Category:Exodus|2:1-10]]

{{John|3:16}} would generate [[Category:John|3:16]]

These last two would be in supercat [[Category:KJV Bible quotes]]

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)[reply]

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.:
# a place of residence for [[nun]]s
#*'''1601''': {{Shakespeare|Hamlet|3|1}}
#*:Get thee to a '''nunnery''', why wouldst thou be a breeder of sinners?
The above would produce this:
  1. 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—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)[reply]
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)[reply]
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)[reply]
Isn't a nunnery a whore-house? --Connel MacKenzie 02:14, 19 July 2006 (UTC)[reply]
  • 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)[reply]

Transwiki to commons: edit

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

Automated requests for cleanup edit

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)[reply]

RFC is in the process of being automated, or at least partially. See Wiktionary:Requests for cleanup/List. — Vildricianus 09:08, 19 July 2006 (UTC)[reply]
Could you have {{en-noun|?}} add it to that category? --Connel MacKenzie 16:58, 20 July 2006 (UTC)[reply]
In fact, adding a parameter with the value "?" for param 1 or 2 (or 3?) should simply add [[Category:Nouns with unverified plurals]][[:Category:Nouns with unverified plurals|<sup>?</sup>]]. Right? --Connel MacKenzie 17:04, 20 July 2006 (UTC)[reply]
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)[reply]
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)[reply]

WOTD update on main page? edit

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)[reply]

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)[reply]
Note also, that the day "boundary" is GMT/UTC. --Connel MacKenzie 16:56, 20 July 2006 (UTC)[reply]

Tooltips for standard headings edit

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. — Hippietrail 23:06, 20 July 2006 (UTC)[reply]

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)[reply]
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. — Hippietrail 00:28, 21 July 2006 (UTC)[reply]
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)[reply]
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. — Hippietrail 06:07, 23 July 2006 (UTC)[reply]
Currently everything but h2 shows up as being non-standard headings. — Vildricianus 10:43, 23 July 2006 (UTC)[reply]
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? — Hippietrail 11:05, 23 July 2006 (UTC)[reply]
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)[reply]
Aha! Thanks. I'm on it... — Hippietrail 11:48, 23 July 2006 (UTC)[reply]
Please try the new improved version and let me know your success. — Hippietrail 13:09, 23 July 2006 (UTC)[reply]
Success confirmed. — Vildricianus 13:57, 23 July 2006 (UTC)[reply]

Preferences now working edit

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)[reply]

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)[reply]

Category delete mini-flood edit

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)[reply]

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)[reply]
http://www.wiktionary.org/ says it is "ku" as does m:Wiktionary#List of Wiktionaries (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)[reply]
Be aware of Template:catred tho.

CSS to hide wikification? edit

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)[reply]

suggested improvement for categories edit

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)[reply]

This is a known bug I've wanted fixed for a long long time. — Hippietrail 18:37, 26 July 2006 (UTC)[reply]
We could JavaScript a link to the toolserver tool (that actually works) to fix this. Vild? --Connel MacKenzie 18:46, 26 July 2006 (UTC)[reply]
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)[reply]
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)[reply]

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

zh edit

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)[reply]

Latin template orthography edit

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 [[oco|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)[reply]

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)[reply]
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 {{la-noun}} 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)[reply]

Extension to split and link to components of multi-word entries edit

The syntax for the inflection line of multi-word entries is cumbersome. It looks something like this:

{{en-noun|sg=[[Grease]] [[pit]]}}

Better would be this:

{{en-noun}}

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

<split/>

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 {{en-noun}} and other inflection templates, /split.php would need to be copied into English Wiktionary's /extensions directory and loaded from /LocalSettings.php, i.e.:

require("extensions/split.php")

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)[reply]

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)[reply]
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? {{wiki|parameter}}  ? Robert Ullmann 16:00, 3 August 2006 (UTC)[reply]
"wiki" is way to ambiguous/generic here. Needs a better name. See next topic. Robert Ullmann 19:46, 3 August 2006 (UTC)[reply]
It should also split on hyphens. Excellently done. You tested it on your wiki already? --Connel MacKenzie 18:39, 3 August 2006 (UTC)[reply]
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)[reply]

URGENT: template:figurative in cheerleader edit

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

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

Changes in the parser. Template probably needs to be rolled back to earlier versions. — Vildricianus 17:05, 6 August 2006 (UTC)[reply]
Hmmm. Does this mean {{cattag}} will now suddenly start working again, too? --Connel MacKenzie 17:40, 6 August 2006 (UTC)[reply]
It's probably broken somewhere. — Vildricianus 17:49, 6 August 2006 (UTC)[reply]
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)[reply]
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)[reply]

Transwiki - new procedure? edit

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 {{db-transwiki}}...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.
    • For existing entries, sysop first deletes target entry, moves Transwiki entry, restores target entry, and promotes correct version.
  4. 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)[reply]

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 w: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)[reply]
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)[reply]
We should probably solicit specific comments from SemperBlotto and Paul G on this one. --Connel MacKenzie T C 18:03, 3 July 2006 (UTC)[reply]

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

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)[reply]

Extention for regularly inflected lemmata edit

I would like to create an "<infl/>" 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:

<infl lang="LANGUAGE_CODE" pos="PART_OF_SPEECH" generate="FORM_TO_GENERATE">LEMMA</infl>

So, pages for regular singular English nouns would call {{en-noun}} with no arguments, which would create the inflection line as "'''<wlink>{{PAGENAME}}</wlink>''' (''plural'' '''[[<infl lang="en" pos="noun" generate="pl">{{PAGENAME}}</infl>]]'''). 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: 

<inflections>
  <rule>
    <entry>^(.*(s|x|ch|sh))$</entry>
    <pl>\1es</pl>
  </rule>
  <rule>
    <entry>^(.*[aeiou]y)$</entry>
    <pl>\1s</pl>
  </rule>
  <rule>
    <entry>^(.*)y$</entry>
    <pl>\1ies</pl>
  </rule>
  <rule>
    <entry>^(.*)um$</entry>
    <key>Latin</key>
    <pl>\1a</pl>
  </rule>
  <rule>
    <entry>^(.*)$</entry>
    <pl>\1s</pl>
  </rule>
</inflections>

Note that pages can still override the plural the way they do now, i.e. by specifying the irregular plural as the parameter to {{en-noun}}, 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)[reply]

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)[reply]
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)[reply]
You beat me to the punch, EncycloPetey. Since the above post, I have refined the design to accomodate such declension and conjugation patterns [2]. 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)[reply]
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)[reply]
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)[reply]
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)[reply]

Status update: I finally completed the work to let the "<infl/>" 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. {{en-verb}}, {{la-noun}}), 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) [reply]

DynamicPageList (again) edit

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)[reply]

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)[reply]
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)[reply]
It's correctly placed on the page, looks quite useful for maintenance purposes. DAVilla 07:42, 16 August 2006 (UTC)[reply]

template:wlink edit

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

Every use of {{isValidPageName}} 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)[reply]

As you said above, {{isValidPageName}} 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:
  • <wlink>word</wlink>: word
  • <wlink>[[word]]</wlink>: 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:
Which would be better? Note: if the former is preferred, I'd abandon <split/> and just use <wlink/>, having it default to linking the current page title only if no contents are given. Rod (A. Smith) 20:01, 3 August 2006 (UTC)[reply]
As long as one can use a parameter inside (having found that <hiero> was a real pain, it is on some deep level!) Probably should wikify the words separately. Robert Ullmann 20:22, 3 August 2006 (UTC)[reply]
Sorry, but doing that would be crazy. It would be needlessly complicating the syntax, for no gain at all. If he were going to write a "wlink" extension (which I sincerely hope he is not doing,) the only reasonable output would be the second one he listed above. --Connel MacKenzie 01:46, 11 August 2006 (UTC)[reply]
What what what? Why hasn't this template been deprecated in deference to {{#ifexist:{{{1|}}}|[[{{{1}}}]]|}} yet? --Connel MacKenzie 01:42, 11 August 2006 (UTC)[reply]
{{isValidPageName}} doesn't check to see whether a given text is the name of an existing page, but whether the given text is a legal name for a hypothetical page. That is, it will succeed for the text "text that could be a page name" but it will fail for the text "text that [[could not]] be a page name". Rod (A. Smith) 04:32, 11 August 2006 (UTC)[reply]
A few things to help clear up my confusion, please:
  1. If a term should have an entry here, it should be wikilinked, right? Otherwise, Special:Wantedpages doesn't work as well.
  2. Could you please explain/document the template on Template talk:isValidPageName?
  3. Why would you want to use this template? I can' think of any use for it, that wouldn't be the "wrong" approach.
Thanks in advance, --Connel MacKenzie 07:57, 11 August 2006 (UTC)[reply]
It says: wikilink this if it isn't already wikilinked or otherwise marked up. You want to do this whether the page exists or not. It is only useful inside another template, that doesn't "know" if its parameter already has markup. There it is essential. For example in en-noun and the other inflection templates. Rod A. Smith hasn't decided yet whether to do this or <wlink/>. If he does that, we will delete this template. Robert Ullmann 12:08, 11 August 2006 (UTC)[reply]

Support because it's much cleaner than the hack {{isValidPageName}}. How about essentially the same idea, except that we should rely on [[ ]] to do this rather than <wlink/>. For instance:

  • [[ word ]] = word
  • [[ [[word]] ]] = word
  • [[ some [[word]] ]] = some word

Right now [[ some [[word]] ]] = [[ some word ]]. DAVilla 07:28, 16 August 2006 (UTC)[reply]

Connel, look at the entries for sû-tián, lâng, and Template:nan-noun, which they use, the calls are:
  • {{nan-noun|p|pojt=su5-tian2|sim=辞典|tra=辭典}}
  • {{nan-noun|p|pojt=lang5|tra=[[人]] or [[儂]]|sim=[[人]] or [[侬]]}}
Now, how is the template going to handle the tra parameter? In almost all cases it needs to use [[{{{tra}}}]] but in the case of lâng, the parameter already has wiki markup, and it can't wrap another set of brackets around it. (which would generate [[人 or 儂]]) So it has to conditionally wikilink, and that is what wlink does. Template:en-noun does the same with IsValidPageName, in a more complicated way. Robert Ullmann 11:55, 16 August 2006 (UTC)[reply]

En-noun categories - just for the record edit

Just for the record (and I apologise if this belongs on the Beer Parlour, I still cannot tell these two apart), I strongly support having the en-noun and en-proper-noun templates automatically categorise those entries accordingly. I am absolutely horrified by the number of uncategorised pages on here (I saw something on meta that said 36 % of our entries were categorised, is that right?). I understand that such categories as 'English nouns' are exceedingly large, but they are nevertheless useful, even if only to keep the Special cleared out! On the French wiktionary, I (and probably others) use the Special:UncategorisedPages as an anti-vandal tool -- vandalism that isn't immeadiately caught will show up on there whenever the Speical is updated, because whether a vandal blanks a page or you creates a nonsense entry, chances are, he/she doesn't put it in a category. Beobach972 18:44, 9 August 2006 (UTC)[reply]

If that's enough to horrify you, I'd love to see your reaction to a reviewing some WT:LWM entries. :-)
When the category migration bot (see above) finishes its work, entries using the POS (inflection) templates will be categorized. Since we only have POS templates for lemmata, though, there will still be a large gap. How about we create POS templates for inflected forms (non-lemmata) as well? E.g.: {{en-noun-pl}} Rod (A. Smith) 19:31, 9 August 2006 (UTC)[reply]
Ahh! So, in other words, you're saying en:wikt is just a total mess?  :-p
I tried going through a few on there but I couldn't figure out how I was supposed to check off what I'd checked. But hey, if you want my help cleaning that out too; I'm probably willing to help -- feel free to explain on my talk page what I ought to do, if I can be of service. Beobach972 19:17, 10 August 2006 (UTC)[reply]
I agree; we definately should create templates for the inflected forms. I would help on that, but my template-making skills stop abruptly at the point where "parameters" and "if X, do Y" become involved. Beobach972 19:17, 10 August 2006 (UTC)[reply]
Since we already have {{plural of}}, wouldn't it be easier and more time-effective to add a component to that? It might require specifying the language with a lang=X parameter so that the template can be used for other languages, but it would be further reaching without introducing another template.
And Beobach, keep in mind there are two sets of categorization. There's (1) by POS and grammar, as well as (2) by Topic. The Topic categorizations are far behind the grammatical categorization, but I personally know that Cat:Time and its subcategories have been well worked over. Many more are in very sorry shape. As for the grammar categories, some languages need more work before the words can be categorized. For example, instead of throwing all Latin nouns into Cat:Latin nouns I'd rather see them divided by declension pattern (e.g. "Cat:Latin noun:first declension") or some such. To make this effective, we need the templates first. --EncycloPetey 23:52, 9 August 2006 (UTC)[reply]
Of course -- not only categorising entries; but sorting the categories and subcategories. Beobach972 19:17, 10 August 2006 (UTC)[reply]
Our mission ("all words of all languages") encourages us to format non-lemmata like lemmata. This sounds like a good time to evaluate that assumption. If we do choose to format non-lemmata like lemmata, {{plural of}} would be a poor choice for the POS/headword/inflection line of plural entries.
{{plural of}} is a {{form of}} template, so it displays like a definition. The POS/inflection templates, however, are made for the POS/headword/inflection area, which shows as tables for some users. A plurale tantum is a lemma, so it seems obvious for its POS/headword/inflection area to match that of a singular lemma. So, assuming we should format the POS/headword/inflection area of plural lemmata like that of plural non-lemmata, we must restrict {{plural of}} to definition lines.
To minimize the number of templates, we could consider changing {{en-noun}} so that the it displays well for plural entries. Consider its use on singulars like "word" (both inline and table formats shown for discussion):
{{en-noun}}
word (plural words)

Singular
word

Plural
words

I don't know the best display format or template syntax for plurals. One option is this (e.g. on "scissors"):
{{en-noun|pl}}
scissors (plural)

Plural
scissors

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)[reply]
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:
{{en-noun}}
scissors (plural only)

Singular
- -

Plural
scissors

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)[reply]

En-Noun needs another option edit

I just discovered that {{en-noun}} 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)[reply]

But both of those English pluralia tantum do have singular forms. --Connel MacKenzie 05:13, 10 August 2006 (UTC)[reply]
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)[reply]
We need to determine how to display both pluralia tantum and non-lemmata plurals. Please help do so in #En-noun categories - just for the record, immediately above. Rod (A. Smith) 05:20, 10 August 2006 (UTC)[reply]

subst:PAGENAME in templates edit

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

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)[reply]
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)[reply]

WOTD audio license info edit

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)[reply]

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

automatic case-variant redirects edit

[See also Wiktionary:Beer parlour#Redirects, where this discussion originally appeared and has been moved from. —scs 13:35, 16 August 2006 (UTC)][reply]

  • 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)[reply]
    Don't you normally start new entries through redlinks or via search ? — Vildricianus 15:06, 15 August 2006 (UTC)[reply]
    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. — Hippietrail 23:33, 15 August 2006 (UTC)[reply]
    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)[reply]
    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)[reply]
    (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)[reply]
    BTW, there are three options. Via search, via redlinks, and via the urlbar where you append ?action=edit. Agreed that it's far from accessible. — Vildricianus 15:27, 15 August 2006 (UTC)[reply]
    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. — Hippietrail 23:33, 15 August 2006 (UTC)[reply]
    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:
    1. follow redlink
    2. type word into search box, hit "Go"
    3. type word into search box, hit "Search"
    4. type word into browser address bar, i.e. "http://en.wiktionary.org/wiki/word" (and various options)
    5. manually construct edit link in address bar, using action=edit (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 "http://en.wiktionary.org/w/index.php?title=Tamper&action=edit". (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)[reply]
    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. bd2412 T 02:45, 16 August 2006 (UTC)[reply]
    chacun à son goût. :-) —scs 02:49, 16 August 2006 (UTC)[reply]
  • 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. — Hippietrail 23:33, 15 August 2006 (UTC)[reply]
    Indeed. (I look forward to it!) —scs 00:14, 16 August 2006 (UTC)[reply]
    OK, I've added an extra option on User:Connel MacKenzie/Preferences. Tick "Disable automatic redirect". Please try it out. — Hippietrail 01:15, 16 August 2006 (UTC)[reply]
  • 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. — Hippietrail 01:38, 16 August 2006 (UTC)[reply]
    • 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)[reply]

(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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
The original purpose of doing this, was twofold:
  1. 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.
  2. 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)[reply]

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

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) [reply]

Appendices edit

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

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

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)[reply]

By filing a "change request" on bugzilla: 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: product=wikimedia, componenet=site requests, platform=all, os=all, priority=normal, severity:enhancement. 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)[reply]

Template:given name edit

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 {{male given name}} (which is to categorise to this category), {{female given name}} (to categorise the this category), and {{given name}} (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)[reply]

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 {{given name}} you'll want it to be something like: A {{{gender|{{{1}}}}}} given name.<includeonly>[[Category:{{ucfirst:{{{gender|{{{1}}}}}}}} given names]]</includeonly> and you'd have on the definition lines {{given name|female}} or {{given name|male}}. 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)[reply]
See what you think so far : Template:given name. Beobach972 20:03, 11 August 2006 (UTC)[reply]
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)[reply]
It looks to me like this should be two templates, {{male given name}} and {{female given name}}. Anyways, where is it used, and why isn't {{cattag|given name}} sufficient?DAVilla 06:56, 16 August 2006 (UTC)[reply]
I keep forgetting about the cattag template. That sems like the best solution. --EncycloPetey 02:01, 19 August 2006 (UTC)[reply]

{{en-noun}} oddity edit

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

That is odd. Since {{en-noun}} and others usually appear immediately after the POS headers (e.g. "===Noun==="), 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 {{en-noun}} 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 {{en-noun}} be allowed inside a single "===Noun===" section? Rod (A. Smith) 00:04, 12 August 2006 (UTC)[reply]
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 {{uncountable}} 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)[reply]
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. — Hippietrail 15:59, 12 August 2006 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

Moving POS categories into POS templates edit

From WT:BP#unnecessary adjective senses? comes a good reason to allow POS templates like {{en-noun}} 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.
    category.py move
  2. Remove Category:English nouns that lack inflection template from pages that use {{en-noun}}.
    category.py remove
  3. Add Category:English nouns to {{en-noun}}.
    In {{en-noun}}:
    [[Category:English nouns]]
  4. 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)[reply]

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. — Hippietrail 02:19, 7 August 2006 (UTC)[reply]

(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)[reply]
  • Support --Connel MacKenzie 05:55, 7 August 2006 (UTC)[reply]
  • 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)[reply]
    Absolutely. The way {{en-noun}} works today, it would be easy to support the "adds s", "adds es", "no plural", and "all others" categories. When my <infl/> 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)[reply]


  • Comment:

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)[reply]

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)[reply]
Is that the current practice, or just a couple people's errors? --Connel MacKenzie 07:48, 16 August 2006 (UTC)[reply]
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)[reply]
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)[reply]
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:
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. [[Category:zh-cn:Mandarin nouns]] instead of the current [[Category:zh-cn:Nouns]] or [[Category:Simplified Mandarin nouns]]).

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

Balancing simplified and traditional Chinese edit

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 {{missing simplified entry}} tag on traditional entries, and vice versa? The tag would place that entry in category such as [[Category:simplified words lacking a traditional entry]] or [[Category:traditional words lacking a simplified entry]]. I would then create the missing entry by hand.

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

Limited number of templates? edit

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)[reply]

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)[reply]
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 {{trad|}} 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)[reply]
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)[reply]

Does anyone know how to make my computer speak Chinese? edit

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)[reply]

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)[reply]
Many thanks Andrew massyn 20:24, 19 August 2006 (UTC)[reply]


Madly templating CJKV languages edit

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) [reply]

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)[reply]

Word of the day "sound" problem edit

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! — This unsigned comment was added by Craisin (talk • contribs).

I've not been able to reproduce this problem. Anyone else? --Connel MacKenzie 17:51, 23 August 2006 (UTC)[reply]
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)[reply]

pre-ordained links out... live smart links in. edit

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). — This unsigned comment was added by Randallreetz (talk • contribs).

Because...we're not Wordnet? --Connel MacKenzie 17:49, 23 August 2006 (UTC)[reply]
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)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Grease_pit/2006/October&oldid=75380368"