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? Tooironic11:07, 2 February 2010 (UTC)[reply]
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)[reply]
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? DCDuringTALK11:14, 6 February 2010 (UTC)[reply]
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)[reply]
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. DCDuringTALK15:47, 6 February 2010 (UTC)[reply]
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. —MichaelZ. 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. DCDuringTALK18:00, 1 March 2010 (UTC)[reply]
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)[reply]
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.) —MichaelZ. 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. DCDuringTALK00:11, 5 March 2010 (UTC)[reply]
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? DCDuringTALK00:16, 5 March 2010 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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.) —RuakhTALK19:43, 10 February 2010 (UTC)[reply]
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)[reply]
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? —RuakhTALK18:08, 11 February 2010 (UTC)[reply]
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)[reply]
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. —RuakhTALK21:57, 10 February 2010 (UTC)[reply]
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)[reply]
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.
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)[reply]
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.Irwin15:30, 12 February 2010 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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. --Derbethtalk22:51, 12 February 2010 (UTC)[reply]
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)[reply]
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 Suntalk?23:25, 12 February 2010 (UTC)[reply]
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 ;-) --Derbethtalk09:45, 13 February 2010 (UTC)[reply]
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 Suntalk?11:15, 13 February 2010 (UTC)[reply]
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 (deprecated template usage)ſ (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?
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.
The idea was that it would only apply to (deprecated template usage)ſ (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 (deprecated template usage)ſ (except for the singular exception of ſ, by itself), whether or not the entry spelt with (deprecated template usage)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)[reply]
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.).
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)[reply]
*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.
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)[reply]
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 rand01:30, 16 February 2010 (UTC)[reply]
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.Irwin13:26, 16 February 2010 (UTC)[reply]
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 rand19:56, 16 February 2010 (UTC)[reply]
(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 rand21:06, 16 February 2010 (UTC)[reply]
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. Tooironic11:39, 16 February 2010 (UTC)[reply]
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?) DCDuringTALK13:12, 16 February 2010 (UTC)[reply]
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. — hippietrail22:10, 16 February 2010 (UTC)[reply]
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? --152.3.128.17817:43, 17 February 2010 (UTC)[reply]
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 Suntalk?03:13, 18 February 2010 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
I agree, please delete them. And if the deletion summary could indicate what message superseded them (if any), that would be nice. —RuakhTALK00:42, 25 February 2010 (UTC)[reply]
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 Suntalk?01:42, 27 February 2010 (UTC)[reply]
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 rand03:20, 28 February 2010 (UTC)[reply]
