Open main menu

February 2010Edit

Indexing Mandarin entriesEdit

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)

Category:ru:Chinese derivationsEdit

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)
I didn't mean to sound snappy. I thought the consensus was to only have up to about three quotations per sense in the entry, and any more than that properly belongs in citations space. I also inferred that the timeline is not useful in the entry. I'm not 100% sure this is correct. But if so, then we can routinely remove timelines from entries, and, time permitting, move additional quotations to citations space. If this is so, then hiding timelines is counterproductive. (I know someone who broke up with a former partner, partly because he insisted he “couldn't see dust,” and so never shared the housekeeping.) Michael Z. 2010-03-04 23:09 z
I also don't think {{timeline}} adds much value to my experience of any page of any entry. Perhaps if it took up less vertical space I would appraise it differently. The template is also not a reliable marker of excessive numbers of quotations in principal namespace. We would probably benefit from some simple counts of quotations per sense or per PoS from one of the dumps. I would very much like to move many citations to citation space, especially quotations more than a century old for a current sense. Our quotation format is also very extravagant in its use of space with the citation information often longer than the passage itself. Quotations useful for attestation often fail to illustrate important collocations or other grammatical points. DCDuring TALK 00:11, 5 March 2010 (UTC)
Is {{timeline}} supposed to be used with the quotations for each individual sense? If quotations in citation space are organized by sense, how often do we have so many citations for an invidual sense that we need "timeline"? If the citations are not organized by sense, shouldn't they be? DCDuring TALK 00:16, 5 March 2010 (UTC)
Add {{#ifeq:{{NAMESPACE}}|{{ns:114}}| at the start of the template?​—msh210 17:32, 1 March 2010 (UTC)

Windows Live -> BingEdit

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)

User:Rising Sun/French verbs needing conjugationEdit

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)

Editing problemsEdit

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)

Comments in local timeEdit

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)

RHS elements in IE8Edit

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)

Char-inserts causing scrolling?Edit

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)

Recent Changes interwikis?Edit

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)

Templates that should probably categorizeEdit

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

Context tags not working in Mandarin entriesEdit

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:


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.


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)

Section headersEdit

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)

Audio botEdit

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)

ſ → s autoredirection and notice generationEdit

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)

Category:Phrasebook and bilingual phrasebooksEdit

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)

invisible spanEdit

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)

entries with no translationsEdit

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)

Random entry by language brokenEdit

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)

requested entriesEdit

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)

tool to create missing language entries from web pagesEdit

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)

Template talk:rfdResultEdit

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)

External search enginesEdit

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)

WTF happened ?Edit

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)

Category:Hebrew words prefixed with ל־Edit

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)

Obsolete system messagesEdit

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)

Category:Cleanup templatesEdit

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)

some new templates which could be usefulEdit

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)