WORD BY LETTER : English CROSSWORD SOLVER and others things ...
Words starting with : 
Words ending  with : 
Ledger Nano S - The secure hardware wallet
Find a definition : 

definition of the word Wiktionary:Grease_pit

by the Wiktionnary

IC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> Wiktionary:Grease pit - Wiktionary

Wiktionary:Grease pit

Definition from Wiktionary, a free dictionary

Jump to: navigation, search

Wiktionary > Discussion rooms > Grease pit

Nuvola apps chat.png Start a new discussion
Welcome to the Grease pit!

This is an area to go with the Beer parlour and the Tea room. Its purpose is specifically for discussing the future development of the English Wiktionary both as a dictionary and as a website.

It is a place to discuss how to solve technical problems such as templates, CSS, JavaScript, the MediaWiki software, extensions to it, the toolserver, etc. It is also a place to think in non-technical ways how to make the best free open online dictionary of all words in all languages.

It is said that while the Beer parlour is a place for people from all walks of life to talk about politics, news, sports, and picking up chicks, the Grease pit is a place for mechanics, engineers, and technicians to talk about nuts and bolts, engine overhauls, fancy paint jobs, lumpy cams, and fat exhausts. That may or may not make things clearer... Others have understood this page to explain the "how" of things, while the Beer parlour addresses the "why".

Permanent notice
  • Tips and tricks about customization or personalization of CSS and JS files are listed at WT:CUSTOM.
  • Other tips and tricks are at WT:TAT.
  • Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with "tips-n-tricks" are to be listed here as well.

Grease pit archives
All subject headings


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)

I use Google for that by adding the site:wiktionary.org parameter like this. --Vahagn Petrosyan 09:13, 2 December 2009 (UTC)
Google isn't friendly for that if there are diacriticals present, or if you are looking for a simple entry name like as. --EncycloPetey 20:44, 12 December 2009 (UTC)
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)

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)

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)
Thanks. It was driving me crazy. --Bequw¢τ 21:58, 8 December 2009 (UTC)

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)

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)
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)
AFAICT no. Mglovesfun (talk) 23:19, 13 December 2009 (UTC)

The ones we are talking about are:

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

Redirect between them? Conrad.Irwin 20:24, 12 December 2009 (UTC)
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)
  • But notice that the second set are all different in terms of what they display and how they categorize. --EncycloPetey 15:24, 13 December 2009 (UTC)
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)

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)

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)
Thanks for that. Stuff has been resolved now.  (u):Raifʻhār (t):Doremítzwr﴿ 22:55, 13 December 2009 (UTC)

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)

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)

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

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)

[1] -- Prince Kassad 05:59, 14 December 2009 (UTC)
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)
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)
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)
Using a template, à la {{musical}}... -- Prince Kassad 05:50, 17 December 2009 (UTC)
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)

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)

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)
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)
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)
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)
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)

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)

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)
Now done. Conrad.Irwin 19:22, 15 December 2009 (UTC)

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

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

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)

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)
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)
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)
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)
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)
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)

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)

It seems very beneficial to me. Can we accelerate the discovery of the errors? DCDuring TALK 02:07, 19 December 2009 (UTC)
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)
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)
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)
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)
I support this wrapping. Maybe we should re-look at rhstoc after it is done. Conrad.Irwin 12:45, 19 December 2009 (UTC)
I strongly oppose RHSTOC. --EncycloPetey 13:02, 19 December 2009 (UTC)
Any particular reasons? DCDuring TALK 13:05, 19 December 2009 (UTC)
Yes. When that discussion starts (again), we can drag them all out (again). --EncycloPetey 13:11, 19 December 2009 (UTC)
I just hope we can have pages look fine for both options. --Bequw¢τ 20:59, 19 December 2009 (UTC)
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)
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)
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)
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)

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))

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)

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)

The categories are of very large size, low utility, and incomplete coverage. No rush. DCDuring TALK * Holiday Greetings! 10:36, 21 December 2009 (UTC)
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)
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)

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)

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)

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)
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)
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)

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)

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)

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)

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)
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)
But no way to have them show up on my watchlist. OK, just wondering... L☺g☺maniac 15:00, 1 January 2010 (UTC)

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)

{{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)
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)
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)
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)
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)
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)
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)

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)

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)

{{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)

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)
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)

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)

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)
Anyone object to that? Mglovesfun (talk) 17:06, 28 December 2009 (UTC)
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)
But use __HIDDENCAT__ as [[Category:Requests for deletion]] probably should do. Mglovesfun (talk) 17:37, 28 December 2009 (UTC)
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)
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)
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)
How is this better than http://en.wiktionary.org/wiki/Special:WhatLinksHere&target=Template:en-noun&namespace=0 ? --Bequw¢τ 18:51, 28 December 2009 (UTC)
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)

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:

Cquote1 black.svg
Windows cannot complete the extraction.
The destination file could not be created.
Cquote2 black.svg

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)

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)

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)

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)

When I click on the audio file for vociferation @ Wiktionary:Word_of_the_day/Archive/2010/January it comes up with Permission error... The action you have requested is limited to users in the group: Administrators. Tooironic 08:02, 1 January 2010 (UTC)

Thanks for pointing this out. The problem is that if a given media file doesn't exist, then [[Media:filename]] redlinks point to Special:Upload — but we don't use Special:Upload, we use commons:Special:Upload. I think the right solution is this:
  • {{WOTD}}, in its call to {{audio}}, should pass in some sort of allow-red=no parameter.
  • {{audio}} should check if the file exists (using {{#ifexist:Media:filename}}), and if it doesn't, then it should check the value of allow-red=. If yes or unspecified, then it should create a link to commons:Special:Upload; if no, then it should not produce any output.
(alternatively, it could just always produce no output, under the theory that we never want any media redlinks; however, I think editors might find it useful to be able to insert the {{audio}} template and then use the redlink to upload a pronunciation file).
RuakhTALK 17:47, 3 January 2010 (UTC)
That is this bug. #ifexist also does not work for media files hosted on commons. Conrad.Irwin 18:51, 3 January 2010 (UTC)
Re: #ifexist: I don't know what you mean. It seems to behave exactly as I'd expect: {{#ifexist:Media:en-us-vociferation.ogg|blue|red}} {{#ifexist:Media:en-us-smudge.ogg|blue|red}} produces red blue. —RuakhTALK 17:14, 7 January 2010 (UTC)
Ah, interesting, using File: instead of Media: doesn't work (which makes sense I suppose). Conrad.Irwin 17:24, 7 January 2010 (UTC)

There doesn't appear to be a "reclamatory" usage context label for a word sense where a formerly pejorative word has been adopted or reappropriated as one with an acceptable or positive meaning for people who would self-apply it, possibly but not necessarily with the intention of making it acceptable for others. E.g. Yankee, queer. Should there be, or would this be problematic? Incidentally, I note no entries for reclamatory or reappropriation, though there are reclaim and reappropriate; something for me to work on, maybe. Peptonized 19:39, 1 January 2010 (UTC)

I think we have something at nigger that is exemplary in at least one sense.
  1. You could hand-make one {{context|reclamatory}}.
  2. Could a non-linguist (or even the majority of linguists) be sure what you meant? We already have intelligibility problems with headings for semantic relationships (meronyms, coordinate terms, hyponyms, etc) and some other context tags like "modal", "speech act", etc for adverbs.
  3. I don't recall that we permit in context labels the wikilinks that would put the definition of a problematic term just a click away.

We usually put such things in usage notes. Admittedly, we have to then add some words to establish the link to the specific sense, but it does let us make the point. If the usage notes uniformly contain a word like "reclamatory", then we could readily make such notes, senses, and entries as consistent as was appropriate. DCDuring TALK * Holiday Greetings! 20:17, 1 January 2010 (UTC)

There might be a better term for it. Your example does apparently automatically link the usage context "vulgar" to Appendix:Glossary#vulgar. Peptonized 20:49, 1 January 2010 (UTC)
Incidentally, a number of the Category:Usage context labels seem to overlap. What's the distinction between avoidance and euphemism? If ethnic slur needs to exist separately from derogatory, should it perhaps be a subcategory? Peptonized 22:48, 1 January 2010 (UTC)

Is there a page that goes into more detail about "sum of parts" than the glossary? It makes sense that one would not bother to define every combination of words, but the point at which the sum becomes different might not always be clear, I'd think.

Also, and perhaps related, I was wondering with regard to the comment I left on the requests "give a rat's ass" at Wiktionary:Requested entries:English#G 2009 how Wiktionary handles that. Pretty much all, if not all, "(not) give X" expressions are basically the same, whether positively or negatively expressed, and however imaginative the X might be. Peptonized 22:40, 1 January 2010 (UTC)

We should either have [[a rat's ass]] or [[give a rat's ass]] imo if it's attested (as I suspect). (The other can redirect to it.) WT:CFI discusses sums of parts, in the section on idiomaticity. There are vast differences of opinion among regulars over what is worthy of inclusion (with respect to idiomaticity), and there is unlikely to be consensus on that point for the foreseeable future. WT:SURVIVOR has some "case law".​—msh210 16:11, 4 January 2010 (UTC)

Derived and related are not defined in the Appendix:Glossary. In e.g. monster, the related terms seem like they could have been called derived ones. Peptonized 22:52, 1 January 2010 (UTC)

We have pretty much dispensed with the hobgoblin of consistency. You should find some statement of what we mean by these terms at WT:ELE and linked pages. As I understand it, "derived terms" are supposed to only be terms in the same language that are derived from the headword other than by inflection. That list could include blends. Related terms are cognates in the same language, again excluding inflected forms. Terms from which the headword is descended are supposed to be in the etymology section. Formerly, the trivial morphological derivations were not shown in an etymology section, so etymological ancestors sometimes appeared in related terms. Now, the use of the templates {{prefix}}, {{suffix}}, and {{confix}}, which put the headword into categories of terms derived from the affixes, makes that practice undesirable. DCDuring TALK * Holiday Greetings! 23:49, 1 January 2010 (UTC)
Hmm, Wiktionary will take some getting used to... I also find it peculiar that there's separate entries for things like to-day and today whereas the OED handles those in a single entry. Peptonized 00:26, 2 January 2010 (UTC)

nav is the ISO 639 code for Navajo, but we use nv because we use 2 letter codes when one exists. However, I've replaced it on the last three pages that use it with {{topic cat}} which is much easier to use. Is there any reason to rename it to something like {{nav.}}, or {{navigation}}? Mglovesfun (talk) 14:12, 2 January 2010 (UTC)

Do bot request go directly here, or nowhere in particular? I was thinking of having someone to a concordance of some Old French texts on Wikisource, which might be a quicker way to find out which words are most widely used/needed. Mglovesfun (talk) 16:33, 2 January 2010 (UTC)

Wiktionary:Bots/Tasks exists, but I don't know whether anyone reads it. Otherwise, I guess this is the page. Or the talkpage of a particular user who you know has run a similar bot in the past.​—msh210 18:18, 7 January 2010 (UTC)

{{etyl}} does not categorize into categories suffixed with ":mul". I can't think of a good reason for this. Some 20 months ago the special treatment of translingual terms by was discussed briefly by EP and Atelaes on the talk page for the template. Per that discussion, I am asking whether there is any reason for the special treatment. DCDuring TALK * Holiday Greetings! 12:56, 3 January 2010 (UTC)

Seems to me like ":mul" isn't special in this regard. --Bequw¢τ 07:08, 4 January 2010 (UTC)

I had an interesting conversation with a friend recently. I was showing him Wiktionary and its benefits, and asked him if he was likely to use it. He basically said maybe, but he was more likely to use a print dictionary. Why? Because in flipping through the pages to look for a word of which he has a vague idea, he can come to a page with a lot of words on it, and perhaps see above or below the word he thought he was looking for, the one that he actually needed to find. So, can we make Wiktionary do this, display entries on a "page" with nothing but dozens of words and the definitions themselves, which can be scrolled through, and then simply clicked through upon the discovery of the "right" word? bd2412 T 17:02, 3 January 2010 (UTC)

Are you suggesting some extension to the "Index" pages? --Yair rand 19:05, 3 January 2010 (UTC)
I think it would have to be, yes. Looking at the list of "all pages" for example does not give definitions. What I'm thinking of is something where Wiktionary could be "flipped through" like a printed dictionary (sorted by language, or perhaps other parameters set by the user, such as templated legal terms or sports terms):

Página Tesoro.jpg

bd2412 T 21:25, 3 January 2010 (UTC)

for WT:TODO, all the pages using the wrong script. I tend to speedy delete these. Mglovesfun (talk) 23:03, 3 January 2010 (UTC)

That seems exceptionally wasteful, why not transliterate them and hope? Conrad.Irwin 23:07, 3 January 2010 (UTC)
Nine times out of ten, there is no usable content. And for most of us, transliterating the page name in the hopes of hitting on the correct one just isn't feasible. --EncycloPetey 23:58, 3 January 2010 (UTC)
I speedy deleted some Bengali nouns using the Latin script last night. In most cases, we either already have it in the right script or we have no way of knowing what the correct script version would be. For example άλφα can be transliterated alpha, álpha, alfa or álfa. Mglovesfun (talk) 16:11, 4 January 2010 (UTC)
Have created Template:wrongscript to deal with this. Mglovesfun (talk) 17:11, 4 January 2010 (UTC)
I've someone can run that request, we can tag them and let someone attempt to clean them up. Mglovesfun (talk) 06:48, 5 January 2010 (UTC)

Could someone create template:quote-magazine along the lines of {{quote-journal}} et al.

I've cited a magazine in the new entry for Chrismahanukwanzakah, which uses all of the following parameters except coauthors, so if you change any names please make the adjustment in that entry.


I've had a look at the source for both {{cite-magazine}} and {{quote-journal}} and the former needs much expansion and the complexity of the latter is far above my skill level, so I'm not confident to just do it myself. Thryduulf 13:57, 4 January 2010 (UTC)

I've copied {{quote-journal}} across and changed it to take magazine= instead of journal=. As such it uses date= where you used issue_date= and issue= where you used number=. Conrad.Irwin 16:54, 4 January 2010 (UTC)
Excellent, thank you. Thryduulf 17:54, 4 January 2010 (UTC)

Do we always protect ISO 639 templates like {{pcd}}, even when not much used? There's not much to them that needs changing; you just write out the name of the language. Mglovesfun (talk) 15:22, 4 January 2010 (UTC)

Protecting 7,000 templates just because they exist seems like overkill to me. -- Prince Kassad 16:22, 4 January 2010 (UTC)
Looking through the last few years of protect log your spree today was the major cause of protection of these templates. There is no need to gratuitously protect templates, it just irritates people who can't edit them (even if they don't want to - I know it irritated me). All the script templates seem to be protected, I don't understand that either. If it's not used on a few thousand pages, it doesn't need protecting. Conrad.Irwin 16:45, 4 January 2010 (UTC)
Most script templates are used on the Main Page which explains their protection. -- Prince Kassad 17:01, 4 January 2010 (UTC)
I don't mean protecting literally every language template, but that *in theory* it's a good idea to protect all of them. I was surprised for {{fro}}, which must have no less than 10 000 transclusions, most of them in English entries. Mglovesfun (talk) 06:33, 5 January 2010 (UTC)

When creating a Citations page, could a link to the policy page WT:CITE be added? Currently the “creating page” text reads:

Wiktionary does not yet have a citations page for <Foo>.
  • To start the citations page, type in the box below and click "Save page". Your changes will be visible immediately.

…but linking to policy would be helpful.

Thanks, greasers!

—Nils von Barth (nbarth) (talk) 21:07, 6 January 2010 (UTC)
I added the notice, but I don't know if it's correctly worded. -- Prince Kassad 21:29, 6 January 2010 (UTC)
Thanks Prince Kassad!
The wording is a bit strong:
WARNING! Please read the Wiktionary policy on Citations pages before creating a Citations page.
I don’t know if “WARNING!” is necessary, particularly as the policy is not terribly picky or contentious, but otherwise the wording is fine, and the link quite useful – thanks again!
—Nils von Barth (nbarth) (talk) 08:00, 13 January 2010 (UTC)


I am exploring the use of the wiktionary database for populating words in the open source educational game called 'anagramarama'. I have various ideas which all start with 'First I need lists of words in languages from around the world'. Wiktionary might help in that regard.

This would be good thing since anagramarama is already an excellent game, but its dictionary is much too advanced for children. What the game needs is easier play for younger kids and harder play for older people. To achieve this, I am thinking...

(1) Read-only access to the wiktionary database could be provided to each game (probably too much stress on your servers), or to an external proxy that in turn would provide the data to the games (probably the better solution). This may involve an application programming interface (API) or database queries. As a bonus, an API or queries might help other software developers create other games.

(2) The difficulty level would be adjustable by adding or removing less commonly used words. Actually, I have many ideas on this, but they are not important now.

Thank you in advance for any help, comments or suggestions.

-Mark Mitchell

You can download all of Wiktionary at http://download.wikimedia.org/enwiktionary/, and you are free to do as you like (well, almost, see CC-SA-3 and GFDL); there is also an API to download entire entries, see the software documentation. If you are looking to run the game in many languages, you may also wish to download their versions of Wiktionary (found in a similar place), each language version aims to define "all words in all languages" using definitions written in the home language. For finding common words, I suggest you look for Swadesh lists, we have a few in Category:Swadesh lists, but seem to be missing an English one (oops). If you want simple stuff for English, there is also a version of Wiktionary. (We have thought about writing a more useful Wiktionary API, but the technical structure of Wikimedia is very Wikipedia-centric, so trying to get anything done is quite tricky) Conrad.Irwin 11:00, 7 January 2010 (UTC)

Hi there all. When in the editing window, there is that drop down menu that allows you to select languages and IPA, enPR, SAMPA from a list and you see a whole bunch of symbols that are otherwise not very easy to type in using a regular keyboard. I would appreciate it if someone could add the two symbols listed at User:Razorflame/EO Pro to the IPA list of symbols because they are used very often in Esperanto pronunciation. Thanks, Razorflame 22:33, 12 January 2010 (UTC)

Can someone work out how to get the columns sorted out on Transwiki:Annexe:Pays et leurs gentilés en français (see letter B)? That's all I need, although other help is of course welcome. Mglovesfun (talk) 14:38, 14 January 2010 (UTC)

Did some work which I abandoned after an edit conflict. I used the format from w:Charlotte Uhlenbroek#Synopsis, in particular the line breaks between column entries. However, this introduced a new problem of occasional missing horizontal lines. That looked like a bug, perhaps a version difference from Wikipedia. Pingku 18:19, 14 January 2010 (UTC)

Hi all

Since about 3 hours ago, I have been having issues creating new pages and editing existing pages with the Edit link at the top of the page (editing in-line seems to work). What happens is whenever I create a new page, the browser starts to prompt me to save index.php file. Now I examined the php header of the page creation link as below, which is very different from normal. It only occurs with this account incidentally. I have tried different browsers and different PC's,and different connections to no avail. Works like a gem when I create pages anonymously and when I use a different account.

[Process] Type=Edit text Engine=MediaWiki Script=http://en.wiktionary.org/w/index.php Server=http://en.wiktionary.org Path=/w Special namespace=Special [File] Extension=wiki URL=http://en.wiktionary.org/wiki/User:Jamesjiao&action=edit&internaledit=true

UPDATE: it seems that if I attach &internaledit=true to the end of the edit/create link, it stops the browser prompt.
Go to Special:Preferences, Editing, and uncheck "Use an external editor by default". Conrad.Irwin 11:19, 16 January 2010 (UTC)
Stroke of genius. Thanks Conrad. I stil haven't a clue how it got turned on in the first place. JamesjiaoT C 23:52, 16 January 2010 (UTC)

I was thinking about merging some of the code for the right-hand side navigation boxes (not conjugation tables). This would ease editing, keep new editors from creating extraneous templates, make the overall layout look more consistent, and allow for better management of color selections (in case someone ever worries about this in the future). As a first step I was thinking that {{enum}} could be extended to be the base, formatting template for {{Zodiac}}, {{ru-Zodiac}}, and {{elements}}. Some of these template would continue to exist as convenient front-ends while others might not be that useful in the long-run (eg {{ru-Zodiac}}). In the future, maybe {{cardinalbox}}, {{ordinalbox}}, {{hu-daybox}}, and {{hu-monthbox}} could be combined somehow as well. Does the first step, however, sound fine? --Bequw¢τ 22:35, 16 January 2010 (UTC)

It is a good idea, I personally prefer the horizontal format to the {{enum}} format and have created a meta-template at {{sequence box}} which resembles {{hu-monthbox}} and {{ordinalbox}} and that class of templates. When used with only the sequence parameters, it can resemble {{elements}}, but without the purple (colours, eww!). I think this box format lends itself to more purposes than {{enum}}'s; it does not require the "previous" and "next" labels, they can be added in by the template that calls this; nor does it require that the "current" is represented by an image/symbol (though obviously it would be easy to create a middle-man template that calls this and provides those features). What are your thoughts? Conrad.Irwin 00:45, 17 January 2010 (UTC)
I like the idea of having a simplified central code for most of these boxes, but I think the temporal sequence ones ought to be combined first (e.g. months, days, zodiac). I'm not sure that combining the elements into the same format is advisable, since the three chemical symbols could then be more easily confused and the names of some elements are quite long. As a result, I don't think a horizontal sequence would work well for the elements. I'm also skeptical about combining {{cardinalbox}} and {{ordinalbox}}, since they specify several optional parameters and display parameters. Trying to patch that into a single master template for a pair of templates that (in principle) could appear on every numeral entry in every language could generate a lot of additional server strain with little or no benefit from the merger. --EncycloPetey 04:26, 17 January 2010 (UTC)

Pr: Praseodymium Nd: Neodymium Pm: Promethium

Chemical elements






We can even mimc the empty grey box at the bottom of the cardinal/ordinal template (It's possibly more aesthetic with it).
Days of the week
←  Monday Tuesday Wednesday  →
The only option not supported by this is the {{ordinalbox}} form where no numerals are given. This could be added to this template trivially, or be done by using the name of the previous and subsequent ordinals, leaving the top two boxes blank, or by not using this template. That form of that template fails to be the correct width, three of the longest chemical elements juxtaposed fit with just a minor stretch, though if they were much longer the template would get wider to cope. I hope this addresses some of your concerns, obviously it would be possible to have more than one style of list; but I am a huge fan of uniformity. Conrad.Irwin 12:39, 17 January 2010 (UTC)
Well no, because you seem to be advocating that we link from the chemical symbol, which logically should be an article about the symbol, not about the word. It also doesn't address what happens for users whose poor vision requires them to use a larger font size, as many of our users do. And, no, the ordinal symbols cannot be added trivially because there are languages that do not use symbols for ordinals or which have no single set that is standard. You've simply opened additional cans of worms to look at. --EncycloPetey 16:38, 17 January 2010 (UTC)
Chemical elements






Latin Ordinal Numbers
septimus octāvus novenus
Cardinal: octō
Adverbial: octiēns
Distributive: octōnī
As always you pick on the details of the examples, not the proposal. I will resay what I have said with hopefully more clear examples: There is no obligation to force all templates to use this as a meta template (i.e. if you personally don't want it, don't use it). The ordinals idea, which I did not express clearly enough, was to use the words not the symbols. My revised proposals are on the right; the advantage here is that to create the proposals, I didn't have to faf around with wikitables, floating right, colours or anything, just filled in the arguments to a general purpose box - this is the advantage of using the meta-template. I am not proposing that "all lists must look like this", merely that it would be useful to have a backend for lists (which was Bequw's proposal originally). I claim that {{sequence box}} is more useful, flexible, and in my opinion aesthetic, than the originally proposed {{enum}}, but it does not have to be used everywhere. Conrad.Irwin 22:24, 17 January 2010 (UTC)
I did not miss commenting on the proposal. You seem to have missed my lead comment (the most important one): "I like the idea of having a simplified central code for most of these boxes." That was my response to the proposal, then I fretted over some details in the original suggestions. One concern I have with {{sequence box}} is that it would have to be channeled through more specific templates becuase we would otherwise have non-uniform titles / formatting in the boxes. As you have noted in comments, including the text in the main box of the ordinals template is "ugly", because (as I noted) there are many optional parameters involved, which is messy.
Whatever we do will also require ISO code support, which is not presented in your examples; how technically feasible is that? It looks like it might be messy to include, and would have to be done individually in every template rather than supporting it in {{sequence box}}, since there will be optional display forms possible in many languages (Arabic, Hebrew, Latin, etc.). --EncycloPetey 23:48, 17 January 2010 (UTC)

Days of the week
← Monday Tuesday Wednesday →
Sorry, yes. For a more directly useful template you could create something like {{sequence}} and then use
{{sequence|en|Days of the week|Monday|Tuesday|Wednesday}}
The problem with this is that you need to write the same caption in all entries; thus creating a template per-sequence seems sensible (but we should be able to re-use the per sequence templates in many languages). It may be the case that many of the sequences can use {{sequence}} instead of {{sequence box}} if they want to take advantage of that format. I would intentionally leave {{sequence box}} as devoid of logic as {{maintenance box}}, its only purpose is to define the layout.Conrad.Irwin 00:50, 18 January 2010 (UTC)
{{Zodiac}} now uses {{sequence box}} and {{ru-Zodiac}} uses {{sequence}}. Look okay? --Bequw¢τ 03:22, 27 January 2010 (UTC)
Yes. Conrad.Irwin 20:12, 27 January 2010 (UTC)

== I am asking this 'community' about what is thought about the word / term "anthropomorphic" in terms of its application to inanimate natural objects such as mountains, trees, lakes, etc.

I understand that the term applies to the figurative 'humanization' of animals especially in children's stories. But is the term commonly extended to the religious notions of, say, spirits that are said to live in natural objects?


You may wish to post your question in the Tea Room. This discussion page is for technical issues and software-related discussion. --EncycloPetey 05:30, 18 January 2010 (UTC)

Can you review the latest edits of DerbethBot? I want to make a full normal run of it soon, but I don't track changes in English Wiktionary policies. --Derbeth talk 13:47, 20 January 2010 (UTC)

As far as I can tell, the changes that your bot is making are very good. Audio files are very much so requested (and there are a lot of entries that could use audio files), so anything that your bot can do to help us add audio files to entries correctly would be very appreciated. Looking through the last 100 edits made by your bot, I could find no outstanding issues with the edits, although my opinion might not be the only one you should get before you make the run. I would suggest waiting for another person's input before going ahead with the full normal run of your bot. Cheers, Razorflame 13:52, 20 January 2010 (UTC)

Two questions:

  1. Assuming that the vote to set ToCs to be on the right by default passes, does anyone know if there's any way to make the side boxes that would otherwise be in that place to float to the left of the ToC instead of below it?
    You could edit all the templates to do this; but don't people have screens too narrow for it to be pretty. Conrad.Irwin 09:35, 21 January 2010 (UTC)
    We could benefit from a BP discussion to check for agreement on the desired appearance (including vertical (or, not to prejudge horizontal) order) of elements. Once consensus is established we might amend WT:ELE. DCDuring TALK 14:57, 21 January 2010 (UTC)
  2. After reading this, I tried to fiddle around with the edit buttons using my monobook.js, and although adding new buttons worked, I couldn't figure out how to modify the existing buttons. Does anyone know whether it's possible to change the buttons, and if so, how?
    I don't know of any existing functions, but it's just DOM manipulation, what were you wanting to do? Conrad.Irwin 09:35, 21 January 2010 (UTC)

Thanks. --Yair rand 07:18, 21 January 2010 (UTC)

Nasa has a DICTIONARY OF TECHNICAL TERMS FOR AEROSPACE USE from 2001. It has a good few thousand terms that aren't in wiktionary...and being that its from nasa, its in public domain. Anybody care to write a bot to add these in?Smallman12q 01:28, 23 January 2010 (UTC)

No. Definitions should be our own, not copied directly from another source, even if there are no copyright issues. Also, there are quite a few spelling mistakes in the definitions - they need to be checked by a human. SemperBlotto 11:37, 23 January 2010 (UTC)
How about adding them, but making use of a template like {{webster 1913}} for them?  (u):Raifʻhār (t):Doremítzwr﴿ 11:45, 23 January 2010 (UTC)
See User:Conrad.Irwin/nasa (if you've got accelerated creation enabled). THis should get you started, but all of them need extensive copyediting. Conrad.Irwin 12:14, 23 January 2010 (UTC)
I would prefer to make use of something like the webster 1913 template, and have a human go through them when they get the chance.Smallman12q 14:27, 23 January 2010 (UTC)
The formatting of the definitions is far too unreliable for that, sorry. Conrad.Irwin 14:30, 23 January 2010 (UTC)
I made a start at defining terms found in this resource. But I have found so many dictionary-only words that I am going to stop. It is very unreliable. SemperBlotto 22:31, 25 January 2010 (UTC)

The following was added by an IP on Wiktionary talk:Announcements several years ago:

I noticed that when I type "define word" on Yahoo or on Google, I get definitions from their dictionaries, but Wiktionary pages do not come up. Traffic might be increased to Wiktionary if all pages had <meta name=keywords content="word, define word">. Just a suggestion.
If this is not the right place to make the suggestion, where should it be done. It's not obvious. —The preceding unsigned comment was added by (talkcontribs) 17:47, 19 January 2006 (UTC)

Is this correct, that Wiktionary would somehow come up more on search engines if this was done? If so, how could we go about doing this? --Yair rand 05:06, 25 January 2010 (UTC)

They used to be there, and were removed because most search engines completely ignore the keywords meta tag. -- Prince Kassad 05:49, 25 January 2010 (UTC)
Not exactly true, see this bug report which I filed to fix the problem, and got (as usual) completely blanked by the admins. Conrad.Irwin 16:21, 25 January 2010 (UTC)

A plea to anyone who wants to do it, or just make a list so that I and other can do it. Categories should not be used as redirect in the form #REDIRECT[[:Category:Name of the category]] because {{movecat}} is much more functional. There are probably quite a few cases where the categories could easily be speedy deleted, or worse, they contain entries while they are redirects, which causes all hell when you click on the category and it redirects to something unexpected. Mglovesfun (talk) 05:42, 25 January 2010 (UTC)

Wiktionary:Todo/redirected categories. --Bequw¢τ 19:12, 25 January 2010 (UTC)

New template: {{phrasecatboiler}}.

Example: [[Category:English phrases]].

--Daniel. 16:16, 25 January 2010 (UTC)

Should our templates that print right-to-left text (eg {{Hebr}} and {{Arab}}) use the &rlm; "right to left marker" like w:Template:Rtl-lang does? --Bequw¢τ 19:27, 25 January 2010 (UTC)

Logically, there should be no need for it, since the dir="rtl" subsumes it. Are there any cases in which any browsers behave differently with it as without it? If so, I'm pretty sure that's a browser bug, and the only way to decide whether to include the &rlm; would be to examine the behaviors with and without it and decide which seems preferable. I don't think we can decide it in the abstract. (If I'm wrong, and there is in fact a case where a browser would be correct in treating the two cases differently, someone please speak up and correct me.) —RuakhTALK 20:48, 25 January 2010 (UTC)
AFAIK you're right, Ruakh. I've found myself adding LRM (sic), though, around Hebrew-script stuff in running English text (because of a bidi-neutral adjacent character). Perhaps template:Hebr should include an LRM at either end?​—msh210 17:47, 26 January 2010 (UTC) 18:32, 26 January 2010 (UTC)
Yes, good idea. —RuakhTALK 21:12, 27 January 2010 (UTC)
I tried it, but it messed up {{term|עד|עַד|sc=Hebr}} {{term|כאן|כַּאן|sc=Hebr}} {{term|לשונו|לְשׁוֹנוֹ|sc=Hebr}} (which exists at [[עכ״ל]]), and similar. Reverted.​—msh210 16:37, 1 February 2010 (UTC)
I tend to think that such cases should be fixed, since the mention isn't of each of those words individually, but rather, of the three-word phrase they compose. So, it should be {{term||[[עד|עַד]] [[כאן|כַּאן]] [[לשון|לְשׁוֹנוֹ]]|until here [is] his language|lang=he|tr=ad kan l'shonó}}. But it doesn't seem very urgent to fix every entry using that pattern, especially since it seems non-trivial to find them all. —RuakhTALK 18:54, 4 February 2010 (UTC)
Such should be fixed, yes. I don't see how the ease of a task affects its urgency, but I agree that this is not urgent: but IMO Hebr can't be fixed until these cases are.​—msh210 19:03, 4 February 2010 (UTC)
Re: ease vs. urgency: touché. :-)   Re: Hebr being fixed: Yes, I agree. —RuakhTALK 19:27, 4 February 2010 (UTC)
Please note that some scripts need to be enforced the right-to-left order (using right-to-left override) because operating systems are not aware of their direction. See, for example, {{Khar}}. -- Prince Kassad 17:51, 26 January 2010 (UTC)
I don't follow. In such cases, why is it better to use an RLO than to specify dir="rtl"? —RuakhTALK 21:10, 27 January 2010 (UTC)
For some reason, browsers ignore the dir="rtl" when text in this script is written. -- Prince Kassad 21:22, 27 January 2010 (UTC)

Alphagrams give the letters of anagrams in alphabetical order. This confuses our users and some of them try to "correct" them by replacing them with the word in which they appear. I revert several of these attempts every week (without blocking the user!).

Could we have something, such as an html comment, that only shows up at edit time to tell people not to do this. SemperBlotto 17:17, 26 January 2010 (UTC)

An example. Mglovesfun (talk) 17:21, 26 January 2010 (UTC)
They should certainly show the page name somewhere, otherwise it's a bit confusing. -- Prince Kassad 17:53, 26 January 2010 (UTC)
I can modify it so it includes the paeg name in the list, or we could remove the alphagram from the list, or change the label to "other anagrams of <blah>" - which do people prefer? Conrad.Irwin 19:17, 26 January 2010 (UTC)
Anagrams always refer to existing words (or sentences, etc.). Strictly speaking, a meaningless alphagram is not an anagram of anything, and people trying to correct pages are right. I would remove the alphagram (it does really not provide any info), or, at least, change its line to (alphagram: ...). Lmaltier 20:23, 27 January 2010 (UTC)
I have removed the alphagram from display, seeing as it casuses so much controversy. Anyone can bring it back by editing {{alphagram}} (note that the parameter is linked when the alphgram is a word, and not otherwise). Conrad.Irwin 20:57, 27 January 2010 (UTC)
IsValidPageName means what it says: the parameter is a valid pagename (not an existing one: for that you want #ifexist).​—msh210 20:58, 27 January 2010 (UTC)
isValidPageName is correct - see my note in brackets above. Conrad.Irwin 21:00, 27 January 2010 (UTC)
Yeah, sorry. (Shouldn't have doubted a Template Master.)​—msh210 21:03, 27 January 2010 (UTC)

Is it just me or is anyone else finding that the collapsible sections (using {{rel-top}} and {{trans-top}} and their accompanying formatting templates) have stopped collapsing? Is someone fiddling with the internals? -- WikiPedant 19:37, 26 January 2010 (UTC)

There have been some recent tweaks to the javascript, but none that should have caused this. I assume you don't have the WT:PREF to keep them open checked? If not try clearing your cache (ctrl+shift+F5), maybe you got given the javascript in some inconsistant state. (Failing that, which browser and which version are you using?) 19:44, 26 January 2010 (UTC)
Hello Conrad -- I'm using Firefox 3.5.5. Clearing cache seems to have done the trick; they're collapsing again. -- WikiPedant 19:56, 26 January 2010 (UTC)
Oddly, my didyoumean autoredirects stopped working briefly today, but are back.​—msh210 19:45, 26 January 2010 (UTC)

I just uploaded a gadget to the Wiktionary preferences page (find it under the "Gadgets" tab). It's a small customization that allows timestamps, such as those in discussions, to be displayed in local time rather than UTC time. I think it's a minor improvement. Files created where: MW:Gadgets-definition, MW:Gadget-section-interface-gadgets, MW:Gadget-CommentsInLocalTime, MW:Gadget-CommentsInLocalTime.js and User:Bequw/comments in local time.js.

Gadgets are a bit nicer than WT:PREFS. You only have to set a preference once rather than in each browser. It is integrated into Special:Preferences so newer users will be able to find it easier. Also the interface is easier to understand (it's got a real save button and no global "Use the preferences set on this page" checkbox). For these reasons I think we should encourage its usage. How would people feel about migrating some of the more "stable" and "appealing" customizations from WT:PREFS to gadgets? WT:PREFS could stay as more of a staging ground for alpha-release customizations as well as the repository for more idiosyncratic customizations (eg "Hide the maximal amount of parentheses. [Can cause sentences to appear ungrammatical]"). --Bequwτ 18:41, 28 January 2010 (UTC)

Would make sense, now we need a volunteer to transfer everything across. The disadvantages of gadgets are (still) that it's inefficient for the small tweaks (but if you don't want to transfer them, that's fine) and also that it precludes anonymous users (we have very few of those, though they have been spotted using prefs). Conrad.Irwin 21:08, 28 January 2010 (UTC)
Yes, we've discussed this before; at [[Wiktionary talk:Preferences#Move to Gadgets tab in Special:Preferences ?]]. The general consensus seemed to match your comment — Gadgets is the way to go for a relatively small number of customizations that are stable, thoroughly tested, well documented, and worth supporting — though you may want to read the earlier discussion for some of the more detailed concerns that people raised. —RuakhTALK 22:27, 28 January 2010 (UTC)
Here's the ones that I was thinking of "promoting":
  1. Navigational Popup's (Lupin's)
  2. Clock. Instead of three options I'd have it be just UTC (people have local time on their screen) and always updating.
  3. Add input boxes to pages to assist with adding translations.
  4. Translate sidebar interwiki links to English
  5. Color translation links orange instead of blue if the target language is missing on an existing page.
  6. Show an interwiki link under the language heading when one exists in the sidebar.
Any additions or subtractions? Is ACCEL stable? Do the Next/Previous links cause too much slowdown to add? We should probably also setup a Wiktionary:Gadgets for extra gadget documentation, concerns, etc. --Bequwτ 22:56, 28 January 2010 (UTC)
ACCEL should be stable enough, by adding the translations box as a gadget, do you want to turn it off by default? I'd quite like some of the sysop-only ones (patrolling enhacements, but only expert mode, and show a box if a user is blocked). Conrad.Irwin 23:10, 28 January 2010 (UTC)
It's unclear if we can make the gadgets on by default. Some said that $wgDefaultUserOptions controls this, but I'm not sure what it's set to. Once they're in Gadget space should they be removed from WT:PREFS do avoid duplication? --Bequwτ 00:37, 29 January 2010 (UTC)
Yes, probably. Though we could wrap the entire file in runOnce(function nameOfJavacscript() { }); or something similar to avoid too many problems (where runOnce still needs to be written). It looks like functionality for default gadgets was removed because of a mistake spamming people [2] - gah.... otherwise we could define behaviour toggles in gadgets (but an entire file for that seems a bit nasty to me) or move them to prefs (which I've been meaning to do for a while). Conrad.Irwin 00:56, 29 January 2010 (UTC)
Added most of them (including RHS ToC) as gadgets, except:
  • "Translate sidebar" and "Show interwiki link" both use MediaWiki:langcode2name.js. We could do a runOnce() or maybe we could move the language utility to MW:Gadget-langcode2name.js and let the Gadget dependency solve it (not sure if it can). Resolved!
  • "patrolling enhacements" ("User:Connel_MacKenzie/patrolled.js") gets the "expert mode" option via WT:PREFS so this will have to be re-written or another, optionless version can be made specifically for gadgets.
  • "Color translation links orange" has some disabling logic that should be integrated into the script so that it can degrade nicely in offending browsers (you can't disable gadgets). Resolved
  • "Add accelerated creation links" has some logic dealing with Nav Popups that I think should be integrated into the main script as well. Resolved
Thoughts? --Bequwτ 23:50, 31 January 2010 (UTC)
No real thoughts, but a small anxiety: what can I get rid of in my css and js monobooks? Will anything bad happen if I select a gadget that has duplicate or near-duplicate functionality with what I've gotten used to (one old CM js script "mess with popups", for example) DCDuring TALK 00:34, 1 February 2010 (UTC)
Well, whatever you enable in gadgets can (and should) be removed from your personal javascript, otherwise they will likely conflict. WT:EDIT and WT:ACCEL are "safe" to be loaded more than once (or safe enough for me); other scripts may not be - it's rather hard to tell, unfortunately. Conrad.Irwin 00:53, 1 February 2010 (UTC)
(unindent) I've merged the importScript caching functionality of MediaWiki:Common.js with that in wikibits so it shouldn't matter if you import a script multiple times (whether from Special:Preferences, WT:PREFS, or your own skin.js) it should only get loaded once (unless you specify different versions of the same file). --Bequwτ 19:28, 4 February 2010 (UTC)
This seems fine except when bits.wikimedia.org timesout before giving out wikibits.js, as that breaks quite a lot of things (I assume?) we can probably live with that. Conrad.Irwin 19:56, 4 February 2010 (UTC)

Link. How come it doesn't appear in bold? Only other time I've seen it do that, is when the script name doesn't exist. Mglovesfun (talk) 21:13, 29 January 2010 (UTC)

This bug actually occurs with all script templates (except {{Cyrl}}). I don't know why nobody noticed it until now. -- Prince Kassad 22:03, 29 January 2010 (UTC)
Note that {{el-noun}} works totally ok. Mglovesfun (talk) 23:23, 30 January 2010 (UTC)
It is up to individual script templates to support bolding, italics, neither, or both. Some scripts are really hard to read in bold or italics, so we want different templates to be able to handle cases differently (e.g., by not supporting italics at all, and/or by implementing "bold" by using bigger text rather than bolder text). In the specific case of {{Grek}}, I've started a discussion at Template talk:Grek; please comment there. —RuakhTALK 23:30, 31 January 2010 (UTC)
I've started a similar one at Template:unicode. --Bequwτ 17:09, 21 February 2010 (UTC)

I note this now displays Mandarin, but it used to display "Chinese languages" (at least when used in etymologies). Chinese languages is more accurate isn't it? Mglovesfun (talk) 23:22, 30 January 2010 (UTC)

Isn't that what {{etyl:zhx}} is supposed to do? Nadando 23:25, 30 January 2010 (UTC)
Yes, admittedly that doesn't fully answer my question though. Mglovesfun (talk) 23:27, 30 January 2010 (UTC)
Also with {{question}}, it turns questions about Chinese entries into questions about Mandarin entries. Mglovesfun (talk) 15:05, 1 February 2010 (UTC)

Have you all noticed {{zh-question}}, {{cmn-question}} and {{yue-question}}? It *seems" to be a good idea to me. If so, they should be generalized to {{question}} with a lang parameter (probably just {{{1}}}) so that people can ask questions about *any* language. I don't think it's redundant to {{attention}} as that's for the entries, not the talk pages. Mglovesfun (talk) 15:36, 31 January 2010 (UTC)

Yair Rand's created the template: zh- and yue- were little used so I updated the links and deleted them, while {{cmn-question}} is marked as deprecated and should be replaced wherever it's found. Mglovesfun (talk) 15:05, 1 February 2010 (UTC)

A minor bug: if you enter a word starting in a long ſ, and no entry exists but an entry exists for a term which starts with capital (not small!) S, it will show that entry in the "page not found" box, but it will not cause the auto redirect. This is somewhat weird and I wonder why it happens. (Try, for example, ſänger) -- Prince Kassad 20:52, 31 January 2010 (UTC)

Probably because it's not implemented in the software. Similarly, 𝓐 is not redirected to A. I agree that such automatic redirects would be the best way to deal with this issue. Lmaltier 21:56, 31 January 2010 (UTC)
Interesting! Sänger appears in the "page not found" box because it's the result of {{ucfirst:ſänger}}, but it doesn't cause the auto-redirect, because the auto-redirect code in MediaWiki:Common.js has this check:
pagetitle.toLowerCase().replace(/[^a-z]/g, "") == target.toLowerCase().replace(/[^a-z]/g, "")
which ultimately compares nger to snger and determines that they're not equivalent. We could perhaps improve that check a bit (calling toUpperCase() before calling toLowerCase(), and filtering out non-letters rather than non-ASCII-letters), but instead, I think we should just remove it entirely, and add this check instead:
wgArticleId == 0
That way, we make sure that the user is really viewing a non-existent page (as opposed to a normal entry to which a vandal has added <span id="did-you-mean">[[a disgusting entry]]</span>), and therefore that the displayed entry is pretty much trusted content, rather than having to try to sanity-check what the did-you-mean code produced. —RuakhTALK 23:16, 31 January 2010 (UTC)
Since no one objected, I've been bold and made the change that I described. Revert and/or let me know if you object and/or notice any issues. —RuakhTALK 01:10, 4 February 2010 (UTC)
Sorry to question the question, but why would you ever input ſänger, looking for Sänger? Did German nouns use not to be capitalised? (I couldn’t find ſänger on Google Books, due to the fact that both Sänger and Fänger exist.) I can understand writing sänger, Sanger, or sanger, but not ſänger. Whilst I agree with the theoretical proposition that ſänger, like sänger, should redirect Sänger, I can’t envision a scenario where, in practice, such a thing would be necessary.  (u):Raifʻhār (t):Doremítzwr﴿ 00:13, 1 February 2010 (UTC)

Take a look at, to pick a random category, Category:zh-cn:English derivations. See how the entries are sorted according to the first letter of the first character's pinyin? Well I was thinking, wouldn't it be more useful if the entire pinyin reading for each entry was put on the left too? That would make it easier to navigate larger categories where there a lot of entries with the same first letter. Note that most (if not, perhaps all?) Chinese dictionaries that use pinyin always put at least the full pinyin of the first syllable, if not the entire word. This could also be made possible with the radical/stroke type index used for traditional Chinese entries (e.g. @ Category:zh-tw:English derivations). What does everyone think? Tooironic 11:07, 2 February 2010 (UTC)

Another reason why changing {{zh}} to display Mandarin (incorrect) instead of Chinese or Chinese languages (both somewhat correct) is a bad idea. The list of broken pages is only gonna get bigger, not smaller. Mglovesfun (talk) 19:40, 3 February 2010 (UTC)

Don't use {{zh}} ever. Use {{cmn}} or {{zho}} and magically all problems with the (as you point out broken) ((as others point out unfixable)) {{zh}}. Conrad.Irwin 23:55, 3 February 2010 (UTC)
I'm not familiar with the chinese-related issues, but wouldn't the fact {{zho}} redirects to {{zh}} defeat the point? Circeus 04:18, 27 February 2010 (UTC)

Would it be possible to have a gadget to suppress the wasteful, hideous {{timeline}}. It's fine that we inflict it by default on unregistered users, but why do we have to inflict it on ourselves? DCDuring TALK 11:14, 6 February 2010 (UTC)

On second thought, perhaps the solution is to remove it from any entry for which all the quotations would fit on a single screen. DCDuring TALK 11:20, 6 February 2010 (UTC)
As it doesn't display any new information (just summarizing what in the quotes) it would seem to have value only on pages where one couldn't scan easily and get the same information (pages where the quotes don't all fit on one screen). A similar solution would be to confine it to the citations tab. --Bequwτ 15:12, 6 February 2010 (UTC)
I wouldn't object, but it is conceivable that it could be useful in principal namespace. We have many entries with very long lists of citations in principal namespace under the quotations header. Under that header we seem to be attempting to compete with the OED in showing scholarship, though we don't trouble to separate the quotations by sense. When we don't separate by sense, a timeline has some value as a navigational aid. In such cases, it would even be nice for the date to provide a same-page link to the specific citation.
Personally, I wish we had a more consistent way of presenting quotations that didn't clutter up principal namespace with quotations not usefully illustrative of current usage of current senses. But that would seem to require some way of maintaining consistency of sense structure across namespaces. DCDuring TALK 15:47, 6 February 2010 (UTC)
Try adding #citation-timeline {display: none;} to your Special:MyPage/monobook.css. Circeus 04:16, 27 February 2010 (UTC)
Thanks. That is much better for me. But it {{timeline}} is often mere eye-candy or, worse, contributor self-indulgence in many of its applications. See aflare. DCDuring TALK 12:40, 27 February 2010 (UTC)

Why use CSS to hide obvious mistakes from yourself, rather than fixing them to improve the dictionary for everyone? Isn't {timeline} intended only for large lists in the citation space? don't think the template belongs in the entry space at all, and certainly not where there is only one citation. Michael Z. 2010-03-01 17:22 z

Because I don't have the, umm, confidence, that my view of the obvious is in fact a consensus and it doesn't seem worthwhile either having a vote or making the correction myself. If there had been anyone suggesting that it was evil, and noone disagreeing I might have put it on the cleanup page. As it is, yours is the only comment on its value. DCDuring TALK 18:00, 1 March 2010 (UTC)
What am I, chopped liver? Oh — wait — I see — I didn't actually comment on its value, merely specifying (below) what we might do about it if we think it has no value. Let me clarify my comment, then: I agree with MZ.​—msh210 18:03, 1 March 2010 (UTC)
Add {{#ifeq:{{NAMESPACE}}|{{ns:114}}| at the start of the template?​—msh210 17:32, 1 March 2010 (UTC)

On the Search page, you have Windows Live as an option. This search engine is now called Bing. Could an admin update this? This, that and the other (talk) 01:05, 7 February 2010 (UTC)

Fixed. --Yair rand 01:29, 7 February 2010 (UTC)

Please can a bot change all the single-worded entries in User:Rising Sun/French verbs needing conjugation (or any other pages needing) from {{infl|fr|verb}} to {{fr-verb}}. It looks like a totally harmless procedure --Rising Sun talk? 03:55, 7 February 2010 (UTC)

Also fairly pointless (right now at least) as fr-verb is basically the same as infl|fr|verb right now. Mglovesfun (talk) 10:10, 9 February 2010 (UTC)

If anyone is having problems with the new edit box, go to Special:Preferences → "Editing" and turn off the "Experimental features" on the bottom. See w:Wikipedia:Village pump (technical)#Edit box .26 monospace style changes for details. --Bequwτ 05:08, 7 February 2010 (UTC)

The major problems appear to have been fixed. --Bequwτ 14:13, 11 February 2010 (UTC)

One of the gadgets recently added is "Comments in local time" (w:User:Gary King/comments in local time.js). It reformats dates on discussion pages so that times are displayed in local time rather than UTC. Not only is this more convenient but it makes the display of times consistent between the Watchlist and discussion pages. I think it would be very beneficial for the default user. Is this a good candidate for being integrated into Common.js? If so, is there anything that needs to be done? I was thinking me might want to have a local Wiktionary copy and also to set the defaults so that the display format matches the Watchlist date/time format. Any major problems? --Bequwτ 04:00, 10 February 2010 (UTC)

I, for one, if I want to say I agree with something someone has written, write (for example) "I agree with Bequw (04:00, 10 February 2010 (UTC))" so as to distinguish it from other things you (Bequw) may have written in the same thread, and (even if you've written nothing else) so as to ease others' finding what I'm referring to. Will that be possible if this is done? Aside from that, I personally don't want to see local times in timestamps, so if this is done it there should at most be optional, please.​—msh210 15:36, 10 February 2010 (UTC)
I agree with msh210; I often quote timestamps to clarify to what comments I refer.  (u):Raifʻhār (t):Doremítzwr﴿ 16:10, 10 February 2010 (UTC)
I doesn't change the wikitext in the edit window. So, if you're referring to a timestamp in the same thread (common case), there's no problem with normal copying and pasting. And display shouldn't be a problem (your reference was localized just perfectly in my display). Is it common to refer to timestamps in other threads? Do casual users do this? If it gets put in, there would of course be an option to turn it off. --Bequwτ 17:51, 10 February 2010 (UTC)

Anyone know why RHS elements such as images and {{wikipedia}}s on pages (such as eagle) create big content gaps in IE8 (FF and Chrome look fine to me)? I've tried this on Windows Vista with Vector & Monobook skins. The problem appears to be exacerbated, but not caused by, RHS ToCs. Is it a CSS issue? --Bequwτ 15:16, 10 February 2010 (UTC)

I've played around a bit, and determined that the issue is the clear:right in the definitions for div.floatright. In both FF and IE7, when an element has both clear:right and float:right, said element gets pushed down till after all pre-existing right-floating elements. (This is basically the definition of clear:right.) The difference is that in IE7, later, non-floating elements also get pushed down, whereas in FF, later, non-floating elements are not affected. That is, the combination of clear:right and float:right is a bit special in FF, whereas IE treats the two properties as totally orthogonal. (I haven't consulted the CSS specs to try to determine which one is right, but I'm putting my money on FF.) Unfortunately, I don't really see how we can fix this: if we don't include the clear:right, then our right-floating elements will stack leftward, cutting clear across the page. (But someone else might have an idea. I'm not very knowledgeable about browser quirks.) —RuakhTALK 19:43, 10 February 2010 (UTC)
More specifically in IE 8, it looks like a RHS element (float&clear:right) doesn't push future, non-floating content down to its top level unless there was also such content right before it. See example. Some cleanup can be done then by rearranging the RHS elements. (Since the {{wikipedia}} has a <span> outside the floating div it has to go last.) Applying that to this version of eagle we get something that looks better in IE8. Maybe we should disable RHS ToC for IE8 until a better solution can be found (it's the same on Wikipedia so probably no easy CSS fix). --Bequwτ 17:56, 11 February 2010 (UTC)
Re: " [] unless there was also such content right before it": Good catch. The same is true in IE7. Re: disabling RHS ToC for IE: Are there any good CSS filter hacks that can accomplish this, or would it need to be done in JavaScript? —RuakhTALK 18:08, 11 February 2010 (UTC)
If workable, a more stable option would be to have JS optionally use importStylesheet(). We could look at the User-agent string or use w:Conditional comments. --Bequwτ 21:38, 11 February 2010 (UTC)
For the time being I've updated the gadget to use a CSS filter that is valid CSS. Non-modern browsers (mostly all versions of IE) won't have their ToC put on the RHS. --Bequwτ 21:30, 23 February 2010 (UTC)

When I have the "Show the edit toolbar (requires JavaScript)" preference enabled, and I click one of the char-insert links in the edit-tools, the edit-box will frequently scroll up or down. This is a new problem. Does anyone know what caused it? I'm not too bothered by it, now that I've found that disabling said preference seems to fix it — I never use the edit toolbar anyway — but I'm guessing I'm not the only one affected. —RuakhTALK 21:57, 10 February 2010 (UTC)

Should this be Template:etyl:prv, as prv was the ISO 639 code for Provençal before it got merged into Occitan. Mglovesfun (talk) 14:19, 11 February 2010 (UTC)

Sure, we use other deprecated codes. --Bequwτ 18:03, 11 February 2010 (UTC)

Hi there. Can someone add the interwiki to the Ido Wiktionary's Recent Changes please? Thanks, Razorflame 17:53, 11 February 2010 (UTC)

Done.​—msh210 20:02, 11 February 2010 (UTC)

{{reflexive}}, {{transitive}} and {{intransitive}}. I already add lang parameters to these when I use them, in the hope that one day they will be used. The lang parameters, I mean. Mglovesfun (talk) 23:52, 11 February 2010 (UTC)

Hmm okay, with more clarity this time. Do you agree that these templates should categorize into [[Category:<fulllangname> reflexive verbs]] (for the first one, clearly). If so, a bot would have to add lang= to all the non English entries that use this, which would be quite a lot. Is it worth it? I say yes, why not? Mglovesfun (talk) 16:18, 12 February 2010 (UTC)
Great - give it a shot! --Rising Sun talk? 22:11, 13 February 2010 (UTC)
Support automatic categorization. --Daniel. 18:22, 15 February 2010 (UTC)

Please take a look at 人心思变 and 异类. Can someone please tell me why the Idioms and Colloquial tags for these new entries are in red? Note this is not the case for Mandarin entries created before the big the naming convention change (e.g. 废话), even though they both use the same formatting. User:A-cai has advised me:

Cquote1 black.svg
The problem is with the {{idiomatic}} template. This template makes use of another template called {{zh-cn}}, which simply inserts "Simplified Chinese" into the text. The word "idioms" then gets appended to "Simplified Chinese" by the {{context}} template (the parent template of the {{idiomatic}} template), resulting in a non-existent category Category:Simplified Chinese idioms. In other words, the {{idiomatic}} template does not currently accommodate the new naming convention that everyone voted for recently. Per that new naming convention, the category should be: Category:Mandarin idioms in simplified script, however {{context}} cannot handle this new naming convention. This is one of those unforeseen complications that both of us were worried about when the modification was initially proposed. The solution would be to fix the {{context}} template, but I'm not sure how easy it will be to fix. Perhaps someone at Grease pit can help.
Cquote2 black.svg

So someone please come to our rescue! This is exactly the kind of extra stuffing around I voiced concerned about at the vote. Tooironic 09:02, 12 February 2010 (UTC)

The naming vote isn't at work here. Mandarin Chinese has been using Category:zh-cn:Idioms and Category:zh-tw:Idioms. Since these were named like topical categories ("<lang code>:Idioms") and {{idiomatic}} was designed to put entries in "grammatical" categories("<lang name> idioms") this context tag never worked for Chinese. To put entries in these old categories, A-cai had been using {{context|label=idiom|topcat=Idioms|lang=zh-cn|skey=...}}. I've waited on fixing {{context}} before moving the topical categories to the new naming scheme. Thanks to A-cai for fixing your {{figurative}} problem. --Bequwτ 13:57, 12 February 2010 (UTC)
Oh thank you that works a treat. You can see that context tag in all its beauty at 人心思变 and 好钢用在刀刃上. Cheers! Tooironic 12:03, 14 February 2010 (UTC)

Was there ever a consensus about delinking section headers like Middle French > Middle French? If so, that seems to be a bot job, not a human one. Mglovesfun (talk) 15:24, 12 February 2010 (UTC)

Can you talk in a more active mood please? (same with Templates that should probably categorize above). If you want to propose a change, propose it; if you want to query existing behaviour query it. I am unable to understand the relevance of comments that are written in this style (maybe it's a bug in me, if so sorry). Conrad.Irwin 15:30, 12 February 2010 (UTC)
afaik the language headers are supposed to be never ever linked. -- Prince Kassad 15:49, 12 February 2010 (UTC)
User:Connel MacKenzie/reformat.js, which is a WT:PREF, includes:
//Acid-trip induced formatting of most Volapük entries
txt = txt.replace(/===\[\[Volapük\]\]  \[\[verb\]\]===/gi, "==[[Volapük]]==\n\n===Verb===");
txt = txt.replace(/===\[\[Volapük\]\]  \[\[noun\]\]===/gi, "==[[Volapük]]==\n\n===Noun===");
txt = txt.replace(/===\[\[Volapük\]\]  \[\[adverb\]\]===/gi, "==[[Volapük]]==\n\n===Adverb===");
txt = txt.replace(/===\[\[Volapük\]\]  \[\[conjunction\]\]===/gi, "==[[Volapük]]==\n\n===Conjunction===");
txt = txt.replace(/===\[\[Volapük\]\]  \[\[adjective\]\]===/gi, "==[[Volapük]]==\n\n===Adjective===");
Should we delink the language name, then? (Really, of course, we can probably get rid of that section altogether. There are none of those entries left.)​—msh210 16:15, 12 February 2010 (UTC)
I meant that Razorflame discussed it at the end of last year. I've already read on Wikipedia that linking sections causes some sort of problem. But then, for discussion pages like WT:RFV we always link the header, not never. Mglovesfun (talk) 16:20, 12 February 2010 (UTC)
I think we should delink them. I'm not sure the proper etiquette for editing someone else's JS, though, as CM still does edit a bit. --Bequwτ 16:49, 18 February 2010 (UTC)
My understanding was that we never linkify L2 headers. Until a month ago, Conrad's form-of auto-creation thing was linkifying L2 headers, and I changed that (by editing User:Conrad.Irwin/creation.js/basicNoun and its kin). I thought I was fixing it. Did I have it wrong? —RuakhTALK 16:39, 12 February 2010 (UTC)
My (at least recent) understanding matches yours, Ruakh and PK. There's an old consensus at [[User talk:Connel MacKenzie/Normalization_of_articles]] that we link TOP40 language names but not others: but that discussion only says that these names are linked in the language-code templates, without indicating where those templates were (at the time) used, so I have no idea whether that discussion applies to L2 headers. Note BTW that recent edits to bam (history) show that AF will unlink "English" but not "Volapük", but link neither; this is in line with the description ("wikilinking stripped in L2 headers in WT:TOP40") at [[User:AutoFormat]].​—msh210 17:48, 12 February 2010 (UTC)

For your knowledge: my bot adding audio files has finished its work. The report is available on page User:DerbethBot/February 2010. The report contains a list of pages, where an existing audio file is not added so far and cannot be added automatically. --Derbeth talk 22:51, 12 February 2010 (UTC)

Thanks for the additions. Is it possible to add audio files on some of the pages that have multiple etymologies? The easy case I'm thinking of is when there's a single pronunciation section already at level 3 (not inside any of the etymology sections) such as at bark or blast. Is that possible? --Bequwτ 23:13, 12 February 2010 (UTC)
I've been looking at the French ones that were rejected, which are found on the above-mentioned report page. I played the files, and some of them include an article (e.g. the .ogg file for cale says "une cale"). When adding the subsequent file, I noted that, e.g. in this diff by writing * {{audio|Fr-cale.ogg|Audio (une cale)}}. Is this a reasonable way of doing things, or is there a better way? --Rising Sun talk? 23:25, 12 February 2010 (UTC)
I will test the case of multiple ethymologies and single pronunciation section in the future.
For French files - yes, there is a way to fix; rename file on commons to 'Fr-une cale.ogg'. I am not able to add voice recognition to my bot, especially not the recognition of French ;-) --Derbeth talk 09:45, 13 February 2010 (UTC)
OK, I'll add this to my to-do list. And it's a shame about bots' limitations - I tried to train User:Dawnraybot to make jokes for WT:FUN, but to limited success. The thing with French, is that there are hardly any heteronyms. One of them is boxer, the audio file of which your bot naturally couldn't distinguish. --Rising Sun talk? 11:15, 13 February 2010 (UTC)

I quote myself (timestamp: 14:51, 10 February 2010) from WT:BP#ſ (long s) typographic variants (section 2) (quod vide for more context):

I reckon the best solution would be to have ſ → s autoredirection (as you suggest), and when that happens, to have some kind of notice (similar to the one that is displayed when one’s talk page is edited, except less intrusive) stating something like “You have been automatically redirected from [former pagename], a page title containing the largely obsolete character ſ (the long ess). For an explanation of the origins and rules of use of the long ess, see Appendix:Long ess.” […] Does anyone know how technically feasible this is?

That closing question is what I bring to this forum: Does anyone here know how technically feasible such autoredirection and character-dependent notice-generation is for ſ on Wiktionary? ∿’d: Raifʻhār Doremítzwr 06:08, 15 February 2010 (UTC)

Autoredirecting from ſ to s, specifically, would not be so hard to add to our current did-you-mean system, because there's a case-mapping relationship there that MediaWiki is capable of implementing. (We'd want to add a few {{#ifeq:-type tests to make sure we're not presenting multiple identical links, but that's it.) But most other sorts of character-dependent autoredirection would require that our JavaScript both (1) check for the relevant characters and determine the page to autoredirect to and (2) determine if that page exists before blindly redirecting the user from one redlink to another. This is doable, if we want it, but it's a lot more complex than the current system, and it would always be somewhat limited, in that it could only check for one entry (or, at best, a small number of entries).
The sort of message that you describe would also have to be JavaScript-controlled on a character-by-character basis, but if we want it, it's not so hard.
RuakhTALK 12:53, 15 February 2010 (UTC)
The idea was that it would only apply to ſ (for now, anyway), and that this was the best way of explaining the long ess without myriads of almost-completely-pointless soft-redirect entries with template-generated generic usage notes. AFAIK, both the autoredirection and the notice-generation ought to apply to all inputs of ſ (except for the singular exception of ſ, by itself), whether or not the entry spelt with s exists (the notice as it is currently phrased is neutral as to whether either spelling is a word, and merely points out that the requested entry contains a long ess and that there exists an appendix to explain what it's about). I'm not sure whether you've already addressed that idea, because, TBH, I'm too tired to get my head around something I understand so little! Let me know either way, if you could. Thanks.  — Raifʻhār Doremítzwr ~  · ⓣ  ·  ~ 01:18, 17 February 2010 (UTC)

I have always assumed that users would appreciate our provision of phrasebooks. But our presentation format doesn't seem very useful.

A phrasebook seems to me clearly most broadly useful when it is portable and bilingual (the speaker's native language and the target language), with phrases grouped by situation for rapid use or refreshing of one's repertoire before entering a situation. That is not the format we offer. Nor do we offer a convenient way for a normal user to produce or extract such a usable format from our data. Our entries could be useful as the raw material for generating accessible bilingual phrasebooks in electronic and print form.

From my technically uninformed perspective, it seems that it should be feasible to produce (on-demand ?, periodically ?) bilingual phrasebooks (en-FL) from the entries that we have (or could have). If we were able to offer such phrasebooks there would be much more incentive to develop a comprehensive approach to phrasebook-type entries (inclusion criteria, situational categories, forms [lemma vs common usage forms], etc.).

Can anyone characterize this notion in terms of overall feasibility, level of effort required, skills, tools, first steps? DCDuring TALK 12:53, 15 February 2010 (UTC)

Perhaps see mw:extension:Collection and its implementation on enWP: w:special:book.​—msh210 17:53, 15 February 2010 (UTC)

I'd like an invisible span element to be in the {{attention}} tag, so that people can set up their stylesheets to display something there (using CSS's :before{content:"!"} and [lang|=foo], say) and thus know while looking at a page where attention is needed. (I wonder too whether title="{{{2|}}}" in the span tag would work to make a tooltip over the "!": that'd be really nice.

Well, I tried including empty span elements in a page, but the software gets rid of them in converting to HTML, apparently. (I'm talking about something like <span class="foo" lang="bar"></span> or <span class="foo" lang="bar"/>: both don't work.) Any other way to do it that anyone can think of?​—msh210 18:31, 15 February 2010 (UTC)

*tests a bit* One option is to add an id=, though that would presumably result in invalid XHTML (I don't know of a way to generate unique IDs, and the software doesn't clean up duplicates). Another option is to include a non-breaking space inside, and use CSS to make it display:none by default; not a very pretty solution, but it's a lot less ugly than what we do in templates like {{term}}, and it at least has the virtue of being temporary (in that {{attention}} is a cleanup template). Your personal CSS could then use something like display:inline !important;background:#F00.
But there may well be a better solution. Those are just two possibilities that came to mind.
RuakhTALK 15:32, 16 February 2010 (UTC)
Thanks, Ruakh. The id idea sounds good. (The other idea also sounds good, except that I hate relying on stylesheets to hide content that shouldn't be there in the first place. That's the style vs. content stickler side of me coming out.) If it's id=attentionseeking{{{1|}}}{{{id|}}}, then there won't be much duplication of ids (though there will still be some, due to various templates' calling {{attention}}. I think that's the way to go; and perhaps when other templates call this one they can pass an {{{id}}}, though I won't be making those changes, or at least not now. Now, does anyone mind my doing so? Speak soon or forever hold your peace — or until you have a chance to revert.​—msh210 17:09, 16 February 2010 (UTC)

Effected. I'll go document it at template talk:attention.​—msh210 19:26, 19 February 2010 (UTC)

The LiquidThreads extension is now in use in the strategy wiki and Wikinews, and I think it would be really useful here on Wiktionary for the large discussion rooms and on User talk pages. Now before everyone starts debating in the BP whether/where we should use LQT here, does anyone know if there are any technical reasons why we couldn't use LiquidThreads? --Yair rand 01:30, 16 February 2010 (UTC)

What options does it give us for archiving? Last time I looked it was not very flexible at all and the user-facing documentation seems pretty absent. There are still a lot of bugs and the way it has been implemented means that they will never all be fixed (instead of trying to add niceness to the existing talk pages, it re-implements the entire idea of a page in a totally different way; so absolutely everything that mediawiki supports already has to be re-implemented). I had a look at Wikinews, they don't seem to use LiquidThreads for their water cooler, nor for any of the Talk: pages I visited. They do seem to try to use it on the Comments: pages, but to get this to work, creating new pages is ugly and even for moderately lengthed discussions the page output is much longer and more convoluted than the corresponding output for normal wikitext (and people complain WT:BP is slow for being too long already). Couple that with the issue that people aren't sure how to use it (and while looking for the link to that diff, it breaks history pages) it seems that there are many reasons, both technical and otherwise, not to use Liquid threads. Maybe in another few months. Conrad.Irwin 13:26, 16 February 2010 (UTC)
From what I can see, it archives automatically. Whenever a comment is added to a discussion, it's pushed to the top, and older discussions are pushed down and eventually onto the next page and into the archives. I think the page histories become split when adding LQT, the old stuff goes into the header's history, accessible from the history button at the bottom of the header, and the threads' history is in the new format accessible from the history tab. The bugs don't seem to be causing any major problems, so it seems like it could be usable. Either way, discussion over whether to use it belongs in the BP, not here. Are there any other technical jams that would cause difficulty, before I bring this to the BP? --Yair rand 19:56, 16 February 2010 (UTC)
(And also, after two weeks of BP debate, a month in WT:V, and another two weeks waiting for someone to deal with the bug report and turn it on, most or all of the bugs will probably be fixed.) --Yair rand 21:06, 16 February 2010 (UTC)

Is there a bot or a special page which gives a list of English entries on Wiktionary with absolutely no translations? I think that would be really useful. Tooironic 11:39, 16 February 2010 (UTC)

Yes, lemma forms only (not repaints, repainted and repainting for example). Mglovesfun (talk) 11:43, 16 February 2010 (UTC)
It would be useful to separate terms that have only obsolete and rare English senses. (BTW, wouldn't it be useful to have list of entries-language sections that use obsolete, rare and very low frequency words in the definitions or translations?) DCDuring TALK 13:12, 16 February 2010 (UTC)

Gives me an error: "** ERROR: couldn't open word file for 'English'" Nadando 21:23, 16 February 2010 (UTC)

Fixed. Thanks for the report and thanks cirwin for pointing it out to me. It was caused by the API now requiring a UserAgent field, the dump system breaking due to that fix, and my dump processing script breaking due to a broken dump being announced via RSS. — hippietrail 22:10, 16 February 2010 (UTC)

is there a way to "vet" requested entries (WT:EDH) so that thing such as sum-of-parts entries can be removed and make the list a little shorter? -- 17:43, 17 February 2010 (UTC)

Is there a tool somewhere to generate lists of missing language entries from a certain web page or corpus? I believe SB's used it to fill his sandbox, among other things. How would I generate a list of all missing French entries on e.g. the page w:fr:Botafogo de Futebol e Regatas (today's featured article on le Wikipédia). And can Uppercases be ignored? --Rising Sun talk? 03:13, 18 February 2010 (UTC)

This can be done using, e.g., sed (or your favorite text manipulator). Paste the displayed text (not the wikicode) of the page into your favorite editor, convert every space to a newline, remove certain punctuation (in English you'd remove all initial and final punctuation and then convert hyphens and dashes to newlines, but I don't know French), remove any line that starts with a number or capital letter, and then change each line X to {{subst:#ifexist:X||[[X]]}}. Perhaps someone else can better this, but that would be the general idea.​—msh210 17:12, 18 February 2010 (UTC)

Input please, notably our template experts like Conrad an Daniel. Mglovesfun (talk) 10:38, 21 February 2010 (UTC)

Also, I propose per all of the verification templates to move these to {{rfd-passed}}, not {{rfdpassed}}. Mglovesfun (talk) 12:02, 21 February 2010 (UTC)
I have upgraded the six tempaltes (rfd|rfv)-(passed|failed|archived) to use {{archive box}}. The other two outliers {{rfv-prej}} is similar to {{rfv-pass}} and {{rfdResult}} now chooses to use either {{rfd-passed}} or {{rfv-archived}}. Conrad.Irwin 15:05, 21 February 2010 (UTC)

I don't think MediaWiki:SpecialSearch.js works well with Webkit browsers (Chrome & Safari). Clicking on the external search engines radio elements in these browsers doesn't fire the onFocus() event so attempts to use other search engines fail with the search rerun using the Mediawiki search. Tab-selecting does fire the event (and cause searches to work) but I think few people do this. Anyone have an easy work-around? We could use a dropdown instead of the radio buttons like Wikipedia does. Here's link about a similar "bug". --Bequwτ 06:11, 22 February 2010 (UTC)

I was going through the Category:Mandarin words needing attention then suddenly it emptied itself from 1,805 entries to 69, what happened?! Could it have anything to do with my edits to Template:zh-attention? I was just trying to delink that page from the category. However I reverted those edits and that doesn't seem to have made a difference. What's going on?! Tooironic 22:38, 22 February 2010 (UTC)

Also, all the subcategories have gone! Tooironic 22:39, 22 February 2010 (UTC)
I'm betting you clicked a bad link. It's Category:Chinese words needing attention that has 1,805 entries. —RuakhTALK 22:44, 22 February 2010 (UTC)
Yeah, we have to deal with two languages here - Chinese and Mandarin. --Anatoli 23:57, 22 February 2010 (UTC)
OK, now this is weird, Category:Chinese words needing attention is now displaying "The following 191 pages are in this category, out of 1,491 total." in Firefox but "The following 199 pages are in this category, out of 1,805 total." in Internet Explorer. Again, WTF? Tooironic 09:05, 23 February 2010 (UTC)
clear your cache (ctrl+shift+F5) -- Prince Kassad 13:51, 23 February 2010 (UTC)
I just cleared my entire cache and still Category:Chinese words needing attention displays as "The following 191 pages are in this category, out of 1,490 total. " What is everyone else getting? Tooironic 10:40, 24 February 2010 (UTC)
Chinese has 1489, Mandarin 69. Conrad.Irwin 15:16, 24 February 2010 (UTC)
On 22 Feb I counted 1,805, what happened to those 316 entries all the sudden? Tooironic 22:20, 24 February 2010 (UTC)

The category name is correct and is created by {{prefix}}. But {{prefixcat}} needs reconfiguring to allow for the w:maqaf. Anyone know how, or want to try?​—msh210 17:06, 23 February 2010 (UTC)

Done, I think. Conrad.Irwin 17:13, 23 February 2010 (UTC)
Thanks much. Looks good. Striking.​—msh210 17:58, 23 February 2010 (UTC)

We've got a bunch of obsolete system messages laying around, many of which haven't been usable for several years. Are any of these still useful somehow? Mediawiki tends to use new identifiers for a change, so I don't think it's worthwhile keeping them around to see if the devs will revert somehow. Here's the list:

If they're not useful I'd prefer they were eventually deleted as it causes confusion and makes it slower finding the correct system message. --Bequwτ 18:56, 23 February 2010 (UTC)

I agree, please delete them. And if the deletion summary could indicate what message superseded them (if any), that would be nice. —RuakhTALK 00:42, 25 February 2010 (UTC)

I'd love to know what the advantage of individual attention templates is, like fr-attention, la-attention. Why are they better than {{attention|la}}? Mglovesfun (talk) 18:54, 25 February 2010 (UTC)

Although {{zh-attention}} needs to be kept as {{zh}} currently displays Mandarin, not Chinese. Mglovesfun (talk) 11:08, 26 February 2010 (UTC)
I see none. I think most of the individual ones should be deprecated. --Bequwτ 12:51, 26 February 2010 (UTC)
A bit like {{zh-question}} which existed before {{question}}. Yeah, these were needed at the time, but not now. Mglovesfun (talk) 12:57, 26 February 2010 (UTC)

Hi, I've just created some new entry templates for French, which are designed to be used on the page MediaWiki:Noexactmatch. The new templates are designed for users (especially me) to speedily create new French entries with the proper layout. I can't edit MediaWiki:Noexactmatch, as it is an admin-only page, and wouldn't know how to anyway. There are Spanish (they don't work btw), Swedish (these do work), and ASL (might work - havent tried, ASL's not my thing) entry templates already on that page, in the drop-down menu, and see no reason why French should be emitted - bizzarely there is a page MediaWiki:Noexactmatch/fr, but this is only viewed if one's preference language is French, which seems strange. So I'm asking, please, if someone could add the French bits there? MG maybe - you'll find them very useful too. --Rising Sun talk? 01:42, 27 February 2010 (UTC)

They actually go in MediaWiki:Searchmenu-new. The Spanish ones don't work because no one's made {{es-new-adj}}, {{es-new-noun}}, or {{es-new-verb}} yet. I'm not sure how we want to deal with these entry templates. Do we add all that are available (a big download for every page miss)? Should we limit them to the most popular languages (makes it a bit biased)? I wish we had something like Wiktionary:Administrators' noticeboard which could log sysop requests (such as editing protected pages) and sysop issues (eg WT:BP#User:Opiaterein). --Bequwτ 03:09, 28 February 2010 (UTC)
Actually, they're stored in Mediawiki:Common.js under "Drop-down language preload menu for [[MediaWiki:Noexactmatch]] and [[Wiktionary:Project-Newarticletext]]", not MediaWiki:Searchmenu-new. There also appears to be a problem with these: the categories that entry templates are placed in are added to the entries they're used in, including the noinclude and includeonly tags. --Yair rand 03:20, 28 February 2010 (UTC)
The list of languages that have entry templates is in common.js (it does the selective hidding) but the templates themselves are stored in MediaWiki:Searchmenu-new not MediaWiki:Noexactmatch (I'll fix the incorrect javascript comments). See w:MediaWiki talk:Noexactmatch to confirm that that message is not actively used. --Bequwτ 15:49, 28 February 2010 (UTC)
Maybe it is something we can get for monobook. I'm always keen on things that can make my editting more productive. --Rising Sun talk? 02:55, 1 March 2010 (UTC)

Someone who knows how to write etyl: templates should write template:etyl:pro, as currently {{etyl|pro}} links to the redlinked w:Old Provençal language, whereas it (apparently) should link to w:Old Occitan. Thanks.​—msh210 17:28, 1 March 2010 (UTC)

Fixed with a wikipedia redirect (they're both valid names). {{etyl}} is using the standard language template {{pro}}, and if we change that we might have to change lots of category names. --Bequwτ 20:12, 2 March 2010 (UTC)
SIL gives them both as valid names for the same language. I posted about this once before, and nobody really saw any reason to rename the [[Category:Old Provençal derivations]] give it's listed as a valid name by SIL/ISO 639. Mglovesfun (talk) 13:20, 3 March 2010 (UTC)

There are a lot of comments at WT:FB either requesting etymological information or pronunciations. Would it be a good idea, in the feedback box which anons see at the left of every page, to have an option saying "there's no etymology" and "there's no pronunciation" which would automatically add {{rfe}} or Template:termp to a given page? It also might be an idea to have some kind of link to WT:FB itself because I think most people aren't sure where to go to see if anyone has answered their questions or not. Ƿidsiþ 09:24, 3 March 2010 (UTC)

Just using my Sandbox I've noticed that a lot of major templates don't have a parameter that means they only categorize in the main name space. Do we want to add these to virtually every template or what? For example you can't use them in appendices or talk pages (etc.) without them categorizing, which generally speaking isn't good. Mglovesfun (talk) 13:10, 3 March 2010 (UTC)

If you want to fix a template, one way to do it is to put the categories in an alternative to a parameter, such as {{{demo|[[category:English nouns]]}}} This will make the template categorize unless |demo=| (or the like) is used: and then you use that whenever you don't want to categorize. This is already being done with a number of templates. (Of course, you can do as you said: make sure it only categorizes in mainspace. I'm just offering an alternative.)​—msh210 16:50, 3 March 2010 (UTC)

The templates currently used to display the headword/inflection line for Greek adjectives needed improvement. Examples of the new template {{el-test}} can be seen at Template_talk:el-test. Please could an expert familiar with templates have a look and make sure that I have not committed any howlers. It seems to work with the examples I have given it, but... Thanks —Saltmarshαπάντηση 16:43, 3 March 2010 (UTC)

{{el-test}} is now {{el-adj}}Saltmarshαπάντηση 05:50, 4 March 2010 (UTC)

I think I've got it, can I move this version into the actual template without breaking anything? There has been a request for a {{wlink}} parameter to avoid AutoFormat adding count page at the bottom of pages. Mglovesfun (talk) 10:10, 4 March 2010 (UTC)

Oh, well. I forgot to update this one (while I was editing {{obsolete spelling of}}, {{rare spelling of}}, etc.) to the new format. Thanks for reminding me. (: The {{misspelling of}} is now updated. --Daniel. 10:50, 4 March 2010 (UTC)
Actually, the non-use of {{wlink}} was intentional. We don't want misspellings to be counted; and I'm pretty sure that AutoFormat was already handling it correctly. —RuakhTALK 17:11, 4 March 2010 (UTC)

Why doesn't the file I uploaded here link to wanton? ---> Tooironic 12:26, 4 March 2010 (UTC)

It does, look at the bottom under "Global file usage". Conrad.Irwin 17:01, 4 March 2010 (UTC)

Definition from Wiktionary
Content avaible with GNU Free Documentation License

Powered by php Powered by MySQL Optimized for Firefox