Wiktionary:Grease pit/2009/December

December 2009 edit

Search tool idea edit

Do we have, or can someone develop, a tool that word search other language Wiktionaries for pages with a particular name? I can see this as particularly helpful in situations where an unfamiliar word has been requested or discovered without the context of language. Such a tool would allow us to quickly search the other Wiktionaries for a match. --EncycloPetey 05:02, 2 December 2009 (UTC)[reply]

I use Google for that by adding the site:wiktionary.org parameter like this. --Vahagn Petrosyan 09:13, 2 December 2009 (UTC)[reply]
Google isn't friendly for that if there are diacriticals present, or if you are looking for a simple entry name like (deprecated template usage) as. --EncycloPetey 20:44, 12 December 2009 (UTC)[reply]
Interesting. Interwicket has a complete global index. If the entry is there for more than a couple of hours, and there is a match on the others, the entry will pick up iwikis, then you can follow them. So a simple way is to create a stub, and wait a bit. I don't have any simple way of making the DB available now though. (Could be done in various ways.) Robert Ullmann 12:57, 13 December 2009 (UTC)[reply]

Vector skin problem edit

When I'm logged in with the Vector skin (Monobook is fine), headings that are the word "head" float in the upper left of the page (like WT:RFV#head and this simple Sandbox page). It happens in IE 8, Firefox 3.5, and Chrome and even after I comment out my entire User CSS and JS file. Anyone know what could cause this? Something in the master skin files? --Bequw¢τ 20:24, 8 December 2009 (UTC)[reply]

Definitely known and reported already. Vector skin has a CSS instruction which places all objects with id="head" at the top left corner. Headings have a id parameter which is their content, so having a heading called "head" causes a conflict. -- Prince Kassad 21:29, 8 December 2009 (UTC)[reply]
Thanks. It was driving me crazy. --Bequw¢τ 21:58, 8 December 2009 (UTC)[reply]

Knowing how complicated {{context}} is, what happens when there's a context label to replace like {{Star Wars}} and I replace it with {{context|Star Wars}} and delete the template? The template is not orphaned. Seems like quite a unique case, as I've never seen another template that works like this. I should look at the source code, although I suspect I won't understand it. Mglovesfun (talk) 08:42, 9 December 2009 (UTC)[reply]

It will change to read "Star Wars" because that's what you typed as opposed to "Star Wars" because that was the label on the context template (i.e. it will do nothing). Conrad.Irwin 15:00, 9 December 2009 (UTC)[reply]
Will the process associated with {{context}} lead to the recreation of the category? Will it lead to a recreation of the template for "Star Wars". DCDuring TALK 13:47, 13 December 2009 (UTC)[reply]
AFAICT no. Mglovesfun (talk) 23:19, 13 December 2009 (UTC)[reply]

Context template duplicates edit

The ones we are talking about are:

Any suggestions? Mglovesfun (talk) 17:00, 9 December 2009 (UTC)[reply]

Redirect between them? Conrad.Irwin 20:24, 12 December 2009 (UTC)[reply]
We have lots of redirects like this. Is considered a normal part of the design of these templates. Robert Ullmann 12:47, 13 December 2009 (UTC)[reply]
I fixed comics/comic books by the number of transclusions. For the steroids set, yes that's an awful mess, and I know just about nothing about biochemistry. Good luck guys! Mglovesfun (talk) 23:24, 13 December 2009 (UTC)[reply]

Use of images on the English Wiktionary is not picked up by Wikimedia Commons. edit

Hi all. Please note the discussion at commons:Commons:Deletion requests/File:Unicode rightwards arrow (U+2192).svg. It seems that Wikimedia Commons doesn’t pick up when an image is used in an entry on Wiktionary. I, of course, have no idea how to rectify this problem; I bring this hereto so that those more knowledgeable in these matters might know what to do about it.  (u):Raifʻhār (t):Doremítzwr﴿ 03:59, 13 December 2009 (UTC)[reply]

Those tools you were linked to on the deletion discussion seem to work, and anyway, when they delete a file from commons, it gets deleted from here by User:CommonsDelinker, in the current debate they just want to replace it by File:U+2192.svg which looks the same, and the CommonsDelinker bot will replace it on wikt like here, so there's no problem. Conrad.Irwin 13:13, 13 December 2009 (UTC)[reply]
Thanks for that. Stuff has been resolved now.  (u):Raifʻhār (t):Doremítzwr﴿ 22:55, 13 December 2009 (UTC)[reply]

Viewing diffs of deleted pages edit

Just a tiny niggle: if you delete a page and then try to view one of its "diffs" (from another earlier browser tab, for example), it comes up with "Sorry: the page title you requested is not supported by our software." That doesn't seem like the appropriate error message. Equinox 06:23, 13 December 2009 (UTC)[reply]

Meant to post this ages ago; there is a way used on fr:Modèle:catégorie redirigée to have the page sub-categorize categories that are not empty, or are redirects to a page that does not yet exist. Seems like a good idea. Also, do we have any policy over which of these categories to keep, or not? On fr.wikt there are something like 600 of these, but we have about 60. I tend to think it's worth keeping the ones that are not misnamed, such as alternative names for languages (Old Occitan/Old Provençal) but should be deleted when it's just a mistake. Mglovesfun (talk) 23:18, 13 December 2009 (UTC)[reply]

Dit it myself; Category:Category redirects which are not empty. Mglovesfun (talk) 11:02, 17 December 2009 (UTC)[reply]

Character support for Mahjong Tiles edit

Hi all. Does anyone know where I can obtain character support for Mahjong Tiles?  (u):Raifʻhār (t):Doremítzwr﴿ 05:39, 14 December 2009 (UTC)[reply]

[1] -- Prince Kassad 05:59, 14 December 2009 (UTC)[reply]
Hmmm. Thanks for that. Unfortunately, though I’ve copied that to my Fonts folder, it doesn’t seem to have worked. For example, viewing w:Mahjong#Mahjong in Unicode, I still only see boxes. Do you have any ideas what might be wrong?  (u):Raifʻhār (t):Doremítzwr﴿ 06:11, 14 December 2009 (UTC)[reply]
Some browsers need to have the font enforced because they fail to select it by default (IE and Opera instantly come to my mind). If the font is installed correctly it should show up in BabelMap. -- Prince Kassad 21:04, 14 December 2009 (UTC)[reply]
Yup, that seems to work. Thanks. Now, how do I “enforce” Symbola?  (u):Raifʻhār (t):Doremítzwr﴿ 18:43, 15 December 2009 (UTC)[reply]
Using a template, à la {{musical}}... -- Prince Kassad 05:50, 17 December 2009 (UTC)[reply]
Hmmm. One seems already to exist as {{Zsym}}… Thanks for your help, nevertheless.  (u):Raifʻhār (t):Doremítzwr﴿ 21:53, 17 December 2009 (UTC)[reply]

Request, for anyone who knows how to do it edit

Was thinking that one main way I could help the project is to complete, where I can, Old French words used in etymologies. But how to find them? Anything using {{term||lang=fro}} would be a good start. Btw I only enter words I've seen in use, I don't just "guess" as the risk/reward is too low. Mglovesfun (talk) 11:05, 15 December 2009 (UTC)[reply]

I suggest entering the string {{term||lang=fro}} in search. It seems to give some good results. Someone with access to the database could probably do a lookup which would be more convenient, but until then... -- Prince Kassad 11:43, 15 December 2009 (UTC)[reply]
Some Etymologies contain the words "Old French" without the template. They offer the potential for multiple improvements. Scanning a simple search for "Old French" for the pattern that yields what you want can be fairly rapid.
Also Hippietrail has been doing useful dump SQL searches on headwords, headings and categories. I don't know what the next step in extending that is, but you might ask him once more instantly available means stop yielding results. Perhaps HT, RU, Conrad or someone else can create lists of redlinked term words by lang (including those with no lang parameter for further cleanup).
Latin, ancient Greek, Middle English, Anglo-Norman, and the various older Germanic languages are all of great importance for English. In some cases the glosses don't match the full range of meanings of the word in these older languages. DCDuring TALK 13:04, 15 December 2009 (UTC)[reply]
I don't really know why Anglo-Norman has its own ISO code, I was taught that it's one of the major dialects of Old French. Mglovesfun (talk) 13:08, 15 December 2009 (UTC)[reply]
Me neither. All I know is that some references make the distinction and thence we inherit it. Also some entries have "Old North French" (lang=?), "Middle French" (lang=frm), and "Frankish" (lang=?). Resolving Old North French into fro, xno, or whatever would be useful if you can figure that out at some point. Similar with Frankish. They may not be "resolvable", but perhaps could be supplemented by additional etymology using languages with ISO codes. DCDuring TALK 13:20, 15 December 2009 (UTC)[reply]
I don't know what Old Northern French is, but Middle French is a separate language (frm) and Frankish (frk) even more so as it's a Germanic language brought in by the tribes invading France during Roman rule. I'm not actually sure it's well enough attested to have entries here, a bit like Transalpine/Cisalpine Gaulish, which have ISO codes but aren't really recorded in writing. Mglovesfun (talk) 13:55, 15 December 2009 (UTC)[reply]

This failed RFD and has been recreated. However using lang=vro in {{wikipedia}} doesn't take you to the Võro Wikipedia, it takes you to nothing, because Wikipedia does not use the correct ISO 639 code. So is this a keeper after all? Mglovesfun (talk) 17:26, 15 December 2009 (UTC)[reply]

No, it should be added to https://bugzilla.wikimedia.org/show_bug.cgi?id=8217 and to the template as an exception. Conrad.Irwin 18:58, 15 December 2009 (UTC)[reply]
Now done. Conrad.Irwin 19:22, 15 December 2009 (UTC)[reply]

The dynamic list has suddenly got much wider and is totally screwing up the spacing. Mglovesfun (talk) 12:28, 17 December 2009 (UTC)[reply]

Fixed by closing the discussion about lukkedoerendunandurraskewdylooshoofermoyportertooryzooysphalnabortansporthaokansakroidverjkapakkapuk. Conrad.Irwin 13:38, 17 December 2009 (UTC)[reply]

English translation lines edit

Could the assisted translation adding system prevent the addition of English translations of English words. Seems to be used by vandals rather than accidentally. SemperBlotto 08:15, 18 December 2009 (UTC)[reply]

I've noted perhaps a half a dozen of these starting about a month ago while addressing rfc-trans table tags. I don't know whether it should be fixed. If a vandal claims the translation is Yoruba, how would I know? It is much easier for the bot to detect and for me to correct vandalistic translations if the language is English. I don't routinely put a ttbc tag on something I make conform to trans-table standards. Do we need a procedure for marking and checking anon-added translations (either all or just those to empty language section)? DCDuring TALK 12:03, 18 December 2009 (UTC)[reply]
It can be fixed easily, and probably should be. I also have thought about a way of making it easier to check added translations. Either the translation thing could append the word to a per-language list somewhere (ideally with rollback and patrol links), that some dedicated person could then sift through; or it could get added to (yet-another) request category. Neither of these solutions seem particularly amazing, though maybe if we allow each language to "opt-in" to the system only if we know we have someone who will actually bother reviewing them, it wouldn't be so bad. Conrad.Irwin 14:33, 18 December 2009 (UTC)[reply]
From my (en-N, other languages 0.5) perspective, the language-list idea seems good, even if there is a big backlog. Checking and correcting translations might be a good starter/restarter task for new/occasional contributors with a specific language skill. But opt-in seems like a good way to start in any event. Should they just go into ttbc if added by anon and link to absent language section? DCDuring TALK 15:28, 18 December 2009 (UTC)[reply]
The problem with putting them into ttbc is that someone needs to edit every entry to remove them, the idea behind an explicit list was so that all edits by X could be easily removed from the list in one go; a big problem with such a page is that it would double the size of recent changes, but I suppose it could be collated on the toolserver as it would not be publishing any information that isn't already available (providing it was limited to anonymous users). Conrad.Irwin 15:56, 18 December 2009 (UTC)[reply]
But Semper's point is about people adding a translation line of "* English: [[garbagetext]]". These can and should be vetted by bot, since we never have English translation listings in English translation tables. --EncycloPetey 05:01, 19 December 2009 (UTC
The volume of "English" that I see at rfc-trans which is what the bot catches is low. At least some of it seems like a kind of typing error. It is sometimes a recoverable translation with the wrong language. If the linked word is blue, I follow the link, confirm that the translation is right and insert the language. I find it simple to do in the course of correcting the other things that impede the operation of assisted translations. There are perhaps as many as half a dozen items a day, usually fewer. No language skills are required, except for the refractory cases, which look to remain on the list for months if not years.
If the bot finds problems of this "English" type, is that not evidence of likely problems in other languages? Perhaps this warrants a test of some kind. How many translations are added by anons in each of a sample of languages over a month? How many are vandalism? How many are erroneous (script, language, other)? How many can bear improvement? Is it usually a single contributor? If the process as originally implemented is ineffective or inefficient, it could be improved or abandoned based on that information. DCDuring TALK 10:52, 19 December 2009 (UTC)[reply]
I have stopped the addition of English through the assisted tool, which should lead to fewer mistakes when a user put the wrong language code in (assuming they did it through the tool). It should not be that hard to set up a system that extracts most assisted edits from recent changes (except the ones that the edit summary disappears on), it'd be slightly harder to work out what % of those get undone or rolled-back, or that have transliterations etc., though it should be doable. Conrad.Irwin 12:53, 19 December 2009 (UTC)[reply]

Making tables play well with RHS elements edit

I'd like to make a change so that our table templates play better with right-hand side elements. We have two main classes of table templates:

  1. Plain: {{top}}, {{top2}}, {{top3}}, {{top4}}, {{top5}} (and their "bottom" templates)
  2. <div>-wrapped: {{rel-top}}, {{der-top}}, {{trans-top}}, {{checktrans-top}}, {{reqtrans-top}}, {{ttbc-top}} (and their "bottom" templates).

When there's a right-hand side element next to these tables, the latter type stay in place vertically and just span the horizontal space available whereas the former type jump below the right-hand side elements (creating a gap in the page) so that they can actually span 100% of the content area. As this gap creates horrible layout, I'd like to fix this by wrapping the former type in a <div> tags (probably <div style="width:auto;margin:0px;overflow:auto;"> in the "top"s and </div> in the "bottom"s). This would create the following side-effects:

  1. People who don't realize that {{bottom}} != "|}" would use the template to close a hand-inputted wikitable and cause a spurious </div>. While technically invalid, it doesn't really cause any rendering problems that I know about. I scanned a en.wikt dump and found that this only happened two times currently.
  2. People often erroneously close {{trans-top}} with {{bottom}}. The way things currently are, this causes the rest of the page to be hidden (because there's two missing <div> tags), an easily overlooked error. With the proposed change, the rest of the page would be visible, but styled like the translation table (there'd only be one missing <div> tag). This would be an obvious error and more likely to be fixed immediately rather than waiting for someone to scan for mismatched templates. At last scan, I fixed about a 100 of these errors, so it's much more common than #1.

I think #1 is so minor as not to worry about, and #2 is an ancillary benefit to the proposed change. Does this sound like a feasible and beneficial change? --Bequw¢τ 01:10, 19 December 2009 (UTC)[reply]

It seems very beneficial to me. Can we accelerate the discovery of the errors? DCDuring TALK 02:07, 19 December 2009 (UTC)[reply]
The layout errors cause by RHS elements' interaction with the "plain" table templates would be completely fixed by the proposed addition of the div tag. As for errors caused by editors mismatching the template, I scan the dumps every once in a while and fix them. --Bequw¢τ 06:37, 19 December 2009 (UTC)[reply]
What right-hand elements (other than images) are a problem with the tables? Most such items are misplaced in the entry, in my experience. --EncycloPetey 04:58, 19 December 2009 (UTC)[reply]
It happens frequently with right-hand side ToCs. That's how I browse so I see it a lot. It's usually when there's a plain top-style table in the upper part of a long page. Because of frequent layout problems I changed {{mul-numberchart}} (which originally used {{top3}}) to use just a plain table. It would look better using a div-wrapped {{top3}}. --Bequw¢τ 06:37, 19 December 2009 (UTC)[reply]
If an entry requires a ToC, RHS ToC improves the value of any language section that appears at the top of the entry by enabling context, especially definitions, to appear on the initial screen a user sees. Were it possible for the ToC to be rhs by default (with opt-out for registered users), we could enhance the value of Wiktionary relative to the other choices that users have. DCDuring TALK 11:01, 19 December 2009 (UTC)[reply]
I support this wrapping. Maybe we should re-look at rhstoc after it is done. Conrad.Irwin 12:45, 19 December 2009 (UTC)[reply]
I strongly oppose RHSTOC. --EncycloPetey 13:02, 19 December 2009 (UTC)[reply]
Any particular reasons? DCDuring TALK 13:05, 19 December 2009 (UTC)[reply]
Yes. When that discussion starts (again), we can drag them all out (again). --EncycloPetey 13:11, 19 December 2009 (UTC)[reply]
I just hope we can have pages look fine for both options. --Bequw¢τ 20:59, 19 December 2009 (UTC)[reply]
I support the change. Maybe we should even add another stray <div> in there, and make all the different "bottom" templates redirect to {{bottom}}. —RuakhTALK 16:40, 19 December 2009 (UTC)[reply]
I thought about this. It would make things cleaner. We aren't worried about the extra bits sent with the second div tags are we? --Bequw¢τ 20:59, 19 December 2009 (UTC)[reply]
And if we do add it, should the top part be <div><div style="width:auto;margin:0px;overflow:auto;">? --Bequw¢τ 22:03, 19 December 2009 (UTC)[reply]
I don't see the need for the first <div>, and any extra </div> will be stripped by HTML tidy after the parser has finished. Conrad.Irwin 22:20, 19 December 2009 (UTC)[reply]

"not to be confused with" edit

Is there a template something along these lines? Something similar to {{also|来|徠}} to go at the top of an entry? I think it would be useful for Chinese words which can be switched around, of which there are many (蜜蜂 & 蜂蜜, 合适 & 适合, 现实 & 实现, 来自 & 自来, etc). These are a common source of confusion for many Chinese learners. Tooironic 04:53, 19 December 2009 (UTC) (P.S. And no, I don't think the "see also" template is explicit enough to serve this purpose. Tooironic 04:55, 19 December 2009 (UTC))[reply]

There isn't a template, and those ought not to appear at the tops of pages. When we do identify words often confused, we tend to do it either in a "See also" section at the end (without comment, which isn't particularly helpful), or in a "Usage notes" section to point out the confusion. There are lots of reasons that two words can be confused, and it isn't just the result of character reversal. --EncycloPetey 04:57, 19 December 2009 (UTC)[reply]

Transitivity categories edit

We have the context templates {{transitive}} and {{intransitive}}, but related categories such as Category:English transitive verbs are populated by hand. These templates could do that job. --Daniel. 09:37, 21 December 2009 (UTC)[reply]

The categories are of very large size, low utility, and incomplete coverage. No rush. DCDuring TALK * Holiday Greetings! 10:36, 21 December 2009 (UTC)[reply]
There's also a very bizarre category loop that needs fixing, involving a redirect that isn't empty. But yes, we have fr:Catégorie:Verbes transitifs en anglais in French, but almost any verb can be used transitively and intransitively. Some can't, I grant you, but unfortunately categories become of very little use when they are very small or very large. But I see no reason to delete them (or not create them). Mglovesfun (talk) 22:45, 23 December 2009 (UTC)[reply]
The more interesting categories would be "ambitransitive" or others for verbs that can take clausal or phrasal complements of various types. I don't think we've done much of that work yet, putting us far behind the Longmans dictionaries, which do the best job I've noticed,, showing 12 types of verb complement classes at the sense level in my edition. DCDuring TALK * Holiday Greetings! 00:17, 24 December 2009 (UTC)[reply]

poscatboiler, etc. edit

Some people suggested the addition of categories such as Category:English idioms and Category:English phrases to {{poscatboiler}}. Instead, I'm finishing (on my PC, not at Wiktionary yet) a new similar template to organize these possibilities, among others. Supported categories are: abbreviations, acronyms, contractions, initialisms, phrases, phrasebook, idioms, proverbs, alternative spellings, misspellings and obsolete spellings. --Daniel. 01:20, 24 December 2009 (UTC)[reply]

Unicodification edit

WT:AWB states that the option "Unicodify entire article" is probably a bad idea. While unicodification is generally a good idea, as it allows for searching, it would mess up instances where we use character references to display a non NFC Unicode character (which we talked about above). Is this the only reason it's discouraged? If so, then this is so rare that we could just make a template like {{HTML char|hex=...}} (or something better named) that displays the reference (allowing decimal, hex, and entities) but that wouldn't be auto-unicodified by AWB. --Bequw¢τ 09:30, 25 December 2009 (UTC)[reply]

Is there documentation of what exactly unicodification does? Does it translate all character and entity references? Because we sometimes escape wikisyntax metacharacters that way; is the unicodification smart enough not to unescape those, or at least to wrap them in <nowiki> tags? —RuakhTALK 01:03, 27 December 2009 (UTC)[reply]
w:Wikipedia:AutoWikiBrowser/User manual#Options 2 says unicodification skips easily confused glyphs (eg primes and times). Do we escape wikisyntax metacharacters with character references in the main namespace? --Bequw¢τ 06:14, 27 December 2009 (UTC)[reply]
After some testing, AWB doesn't automatically unicodify character references for { } [ ] | nor any inside templates. So one can still do things like [http://w.tf Re: [ADMIN&#x5D; and more] to include brackets in the text of a URL link w/o fearing AWB will destroy it. I've encoded non NFC-characters using {{HTML char}} so they will be AWB safe too. I think we fine to discourage the general use of character references and allow AWB to . --Bequw¢τ 07:24, 31 December 2009 (UTC)[reply]

Auto-creating rhymes pages edit

Interesting to set all the red linked rhymes entries. Couldn't a bot such as Conrad.bot create these using Special:WhatLinksHere? Not only would it avoid all the red links, but anything tagged with the wrong rhyme would be quite visible in such a list. Mglovesfun (talk) 17:53, 25 December 2009 (UTC)[reply]

The Rhymes pages require knowing the language of the entry and that the coding for the link was correctly put in. There are only two or three people here that know the coding system for Rhymes well enough to judge that, and in my case I've usually created the page myself already when there was a valid link. there are experienced editors here whom I have seen add an incorrect Rhymes link because they didn't know our conventions for parenthetical characters, UK weighting, and stress considerations. I don't think a bot could successfully create the entries. A bot also would not be able to sort items into sections by number of syllables, since the syllable breaks aren't always indicated, and aren't always correct. However, it might be worth having a bot generate some sort of list for inspection. --EncycloPetey 16:25, 26 December 2009 (UTC)[reply]

Could there be a way to 'watchlist' a user's contributions? edit

I know one is able to watch a user's talk and userpage, but could there be a way to have all of that user's contributions show up on the watchlist? ('twould only be useful for very new or iffy users (i.e. users listed on WT:VIP but not blocked as vandals), of course...) L☺g☺maniac 02:54, 26 December 2009 (UTC)[reply]

AFAICT you can't favorite special pages, nor can you have redirects towards them. But you can have explicit links towards, put them in your favourites or on your user page (Special:Contributions/Tbot for example). Mglovesfun (talk) 09:53, 26 December 2009 (UTC)[reply]
Or you can subscribe to an RSS feed of one's contributions. The link is in the toolbox on the left of e.g. Special:Contributions/Tbot. --Vahagn Petrosyan 12:19, 26 December 2009 (UTC)[reply]
But no way to have them show up on my watchlist. OK, just wondering... L☺g☺maniac 15:00, 1 January 2010 (UTC)[reply]

lang= in templates edit

Any idea how to replace things like {{etyl|la}} with {{etyl|la|langname}} and {{sports}} with {{sports|lang=langname}}. A lot of non-English words are categorized in English categories for this reason. Mglovesfun (talk) 10:11, 26 December 2009 (UTC)[reply]

{{etyl}} already has a language code as its second parameter, so for a Spanish word of English origin, type {{etyl|en|es}}. {{sports}} also has a lang= parameter. It's just a matter of people remembering to use them. —Angr 15:22, 26 December 2009 (UTC)[reply]
Sorry, maybe I was unclear. Templates that are already in our entries, but categorize in English, as English is the default for almost every template. So you get Japanese, Russian (etc.) words in English categories. I'd have thought this would be pretty damn machine readable. Mglovesfun (talk) 15:27, 26 December 2009 (UTC)[reply]
According to User:AutoFormat, AF already does fix context labels; have you seen evidence of that not working? As for {{etyl}}, we might want to ask Robert to add that to AF as well, though there's the complication that (for example) {{etyl|ar}} in a ==Hebrew== section is more likely to be an error for {{etyl|ar|-}} than for {{etyl|ar|he}} (though both are quite possible). I suppose the safest thing to do would be {{etyl|ar|-}}{{attention|he|some sort of message here about what happened}}. (Though with {{etyl|la}} in a ==Spanish== section that's a bit of a waste, since it's almost certainly supposed to be {{etyl|la|es}}.) —RuakhTALK 15:49, 26 December 2009 (UTC)[reply]
This would probably be better done as a manual search from a generated list. As Ruakh indicates, there is no safe assumption about what is correct without looking at the entry. --EncycloPetey 16:21, 26 December 2009 (UTC)[reply]
See WT:CDPR#Correcting etymological categories for generated cleanup lists. There's about 1,600, so once they're cleaned-up, maybe AF can mark new ones with {{attention}}. --Bequw¢τ 06:00, 27 December 2009 (UTC)[reply]
Wow, thanks for attacking those lists. For a related list of entries that are incorrectly hand-categorized into English topical cats, see the new WT:CDPR#Incorrect topical categorizations. --Bequw¢τ 02:06, 29 December 2009 (UTC)[reply]
As for {{context}} with no language given, AutoFormat can correct this, but it only checks the recent changes, so pages that aren't updated (excluding bots like Interwicket) will continue to categorize in English, even when not so. Mglovesfun (talk) 11:55, 28 December 2009 (UTC)[reply]

It might be interesting from a formatting point of view to see which entries don't use {{plural of}} and eventually remove the overt written [[Category:English plurals]] from entries, as AFAICT all plurals should use plural of. This could later be extended to some other languages, but not all of them. Mglovesfun (talk) 16:24, 26 December 2009 (UTC)[reply]

How are the boundary cases handled? For example, plural-only nouns. I would guess that they should only be in their own category with the category being included in English plurals. What about redlinked plurals? More vexing are words that are in contemporary general usage in one sense (or more) as plural only, but not in other senses (often, but not always, dated or technical). (See hackles.) Might these cause trouble for the (desirable) process you seem to be advocating? DCDuring TALK * Holiday Greetings! 16:51, 26 December 2009 (UTC)[reply]

Edit in {{trreq}} edit

{{trreq}} was designed to add categories such as "Translation requests (French)" to entries. As it's commonly done for other templates supposed to be only used in entries, I'll edit {{trreq}} to not automatically add categories to pages outside the main namespace. --Daniel. 01:42, 28 December 2009 (UTC)[reply]

Yes, that's good. Can we make a list of all the templates that still need this change? --Bequw¢τ 06:40, 28 December 2009 (UTC)[reply]
I'm not thinking of a way to list them automatically right now. Perhaps it's simply better to edit them when such change becomes necessary. --Daniel. 02:23, 31 December 2009 (UTC)[reply]

Template proposal edit

If we don't already have one, something like {{obsolete template}} for templates that have been replaced or have failed RFD, but can't yet be deleted as they are still used on pages. It could also have with includeonly the hiddencat [[Category:Pages using an obsolete template]]. Any thoughts? Mglovesfun (talk) 11:53, 28 December 2009 (UTC)[reply]

We have the {{deprecated}} and the [[Category:Deprecated templates]]. A second category [[Category:Pages with deprecated templates]] might be useful. --Daniel. 17:00, 28 December 2009 (UTC)[reply]
Anyone object to that? Mglovesfun (talk) 17:06, 28 December 2009 (UTC)[reply]
Let me see if I understand correctly by restating the proposal, as it stands. You want to add a second category to {{deprecated}}, but make the new category "visible" in the sense that it will categorize the pages into [[Category:Pages with deprecated templates]] when they contain that tagged deprecated template. Is that correct? --EncycloPetey 17:20, 28 December 2009 (UTC)[reply]
But use __HIDDENCAT__ as [[Category:Requests for deletion]] probably should do. Mglovesfun (talk) 17:37, 28 December 2009 (UTC)[reply]
Sounds like a possible idea, but what would the purpose of the category be? If each template were tagged one at a time, I could see it being a useful tool. However, it's more likely that the catgeory will contain a mix of many pages containing many different deprecated templates. So, anyone using the category would have to spend time figuring out which template on the page is deprecated, where it is, and what to do about it. It doesn't seem like having the category would produce a useful payoff. --EncycloPetey 17:54, 28 December 2009 (UTC)[reply]
Then, I'll propose a more specific and useful categorization. Supposing that {{en-noun}} becomes deprecated and has {{deprecated|{{subst:{{PAGENAME}}}}}} in it, pages containing {{en-noun}} are added to [[Category:Pages with deprecated templates (en-noun)]]. --Daniel. 18:20, 28 December 2009 (UTC)[reply]
If editors don't mind the headache of creating and deleting the resultant categories as templates are deprecated and then cleaned away, then it sounds like a feasible plan to me. --EncycloPetey 18:35, 28 December 2009 (UTC)[reply]
How is this better than http://en.wiktionary.org/w/index.php?title=Special:WhatLinksHere&target=Template:en-noun&namespace=0 ? --Bequw¢τ 18:51, 28 December 2009 (UTC)[reply]
The problem is that even if a template is not very widely transcluded, a change to the template can take a while to get through the job queue (depending what else is on the queue at the same time), so the category won't necessarily get populated very quickly. WhatLinksHere, on the other hand, is normally up-to-date, or at least closer to it. (It, too, is affected by the job queue, but using it doesn't require editing the template.) —RuakhTALK 19:56, 28 December 2009 (UTC)[reply]

Code 2000 installation problem! edit

Hey, guise [sic]... I have Windows 7 and have tried on several occasions and through several methods to install Kass' Code2000 font with no success. I have already successfully installed his Code2001 with no problems. But when I try to install Code2000 by clicking on it, I get the message:

 

Windows cannot complete the extraction.
The destination file could not be created.

 

I have also tried dragging it to the Fonts folder. Does anybody know what I should do? I NEED this font!!!! Thank you.—Strabismus 22:29, 28 December 2009 (UTC)[reply]

Use different unZIPper. 83.7.242.254 15:22, 1 November 2010 (UTC)[reply]

Diminutive noun forms edit

I've added a pos= parameter to the templates {{augmentative of}} and {{diminutive of}}, so they can categorize entries to POS-specific categories such as [[Category:Spanish noun diminutive forms]]. For example, see the entry gatito. --Daniel. 02:20, 31 December 2009 (UTC)[reply]

Spelling categories edit

My project of cleaning up spelling categories is virtually done, as you can see at Category:English spellings. This scheme works for other languages as well, in case new categories such as [[Category:Catalan nonstandard spellings]] are created. There are also categories for specific characters, such as [[Category:English terms spelled with À]]. --Daniel. 14:52, 31 December 2009 (UTC)[reply]

I don't think the category should be in Category:Orthography, since "English spellings" is not a topical category. -- Prince Kassad 14:58, 31 December 2009 (UTC)[reply]