Wiktionary:Grease pit/2008/April

Do we need both category:Medicine and category:Medical? The former is more populated with a reported 1,218 pages and 95 sub-categories versus 22 pages and 2 sub-categories (category:gd:Medical and category:zh:Medical). Thryduulf 16:49, 1 April 2008 (UTC)

Note: this is not a technical question, and should have been listed at WT:RFDO. I believe "medicine" is the more common context tag and therefore more commonly linked as a category. We could probably delete Cat:Medical. --EncycloPetey 17:29, 1 April 2008 (UTC)

Just saying, that actually sort of was a technical question, so...yeah... — This unsigned comment was added by 74.140.218.179 (talk) at 04:08, 10 April 2008 (UTC).

The following suggestion is intended to help users who visit visiting the Wiktionary site simply for word definition, and, secondarily, is detailed in a none technical manner...

I am an English language user so have the following URL bookmarked as my Wiktionary landing page: http://en.wiktionary.orghttps://dictious.com/en/Wiktionary:Main_Page

The issue is that, unlike www.wiktionary.org/ this page does not have a focus for immediate text insertion in either of the 'Search' fields. Although it is only a mouse drag and click away, this is mildly irritating: I like to paste in words I don't know (as I do post/zip codes in www.streetmap.co.uk/ search field, which has the type of focus I am requesting).

If this can be achieved with little coding effort, and if you know that this is the function that the majority of users landing on this page wish to perform then please, please add this. Usability will have been improved and people will thank you.

BTW: it is already tremendous, so congratulations to the myriad serious contributors.

— This unsigned comment was added by Overland (talk • contribs) at 16:04, 2 April 2008 (UTC).

That falls into the category of things that are easy to do, but not as easy to do well. A lot of sites with auto-focus don't auto-focus until the page has finished loading, at which point the user may already have started doing something else and the auto-focus will interfere with that. Even so, this is probably useful enough that it's worth figuring out a decent way of doing it. —Ruakh_TALK 23:06, 2 April 2008 (UTC)

As Wiktionary's front page is a bit bigger and served more slowly than, say Google's, waiting for the whole page to load allows too much time for the user to click somewhere else before we force it to the search box. Could we set the focus right after the HTML form element is loaded (so we don't have to wait for all other files to be loaded)? Is it possible to inject after the form (or anywhere else the get's called before the whole document is loaded), something like.. <script>document.bodySearch.bodySearchIput.focus();</script>? --Bequw → ¢ • τ 16:16, 10 April 2008 (UTC)

Re: your first sentence: yes, sorry, that's what I was trying to say. :-P   Something like you describe would work — specifically, I think <script type="text/javascript">document.getElementById('searchInput').focus();</script> should work in most halfway-modern browsers — but firstly, I can't think of any way to get that into the HTML, and I can't think of any way that an external JavaScript could do this, short of repeatedly polling for the existence of document.getElementById('searchInput'); and secondly, even if we could do that, the search form is near the end of the HTML (at least in Monobook), so I rather doubt that for most users it loads that much earlier than the rest of the page. —Ruakh_TALK 00:04, 11 April 2008 (UTC)

I don't know how to get it in the page either :( As for your second point, though, onload="" waits for the whole window to load not just the HTML file. So even if it's near the end of the HTML file, it could (depending on threading and browser) get triggered before the other files finish loading (CSS, JS, and images). --Bequw → ¢ • τ 15:41, 15 April 2008 (UTC)

Please don't mess with my focus!

It's an appropriate thing to do on a fast-loading search page, but not on a site's home page. Google doesn't even do it on their search results.

If there's anything other than search to do on a page, then changing the focus confuses the reader. It makes me mental that any time I load dictionary.com, I look at the search field, there's no cursor there, I hit tab again and again, and I can't find the focus because the site put it into the search field a split second after I looked.

To move the focus to the first field all the reader has to do is hit the tab key once. This works on 99.9% of the Web, so why break it on Wiktionary? —Michael Z. 16:55, 15 April 2008 (UTC)

I think the plain text comment feedback system should be scrapped. Counting the mouse clicks is one thing - but the caliber of comments on WT:FEED leave something to be desired. Those that were looking at them occasionally, don't seem to be now. --Connel MacKenzie 07:15, 3 April 2008 (UTC)

I do look at it now, and look at most of the entries that are commented on. I just don't make many comments on the page. Yes, the signal to noise ratio is low, but not so much that its impossible to use. Thryduulf 07:45, 3 April 2008 (UTC)

I don't know, but I hypothesize that people are taking (slightly) more interest in WT:FEED than they are in the list of clicks - though you'll no doubt be able to see how many page views they are getting. Is it possible for you to publish the list of pages that have been marked as needing improvement so far? Conrad.Irwin 08:33, 3 April 2008 (UTC)

Gee, I hadn't thought that we would want to kill it. I find that some of the entries mentioned with negative comments really need improvement and have attempted to make those improvements. We have vast numbers of entries that need improvement in some way, but this gives us insight into what improvements users seem to want. Why spend our time cleaning up what no one uses or believes needs work? We know next to nothing about our ultimate client base. The clicks are important too, but need basic analysis (counts of hits (by different users)), totals by type of complaint, overlap with other lists (rfc, frequency, etc.) DCDuring TALK 10:31, 3 April 2008 (UTC)

It is also possible that we move the text comments over to toolserver as well, cause a click on "leave a note" to pop up an input box above whatever page they were viewing, allow them to type their comment (we can also add a mini-poll to the bottom via radio/check boxes) and then have them submit the form to a DB. The obvious problem is that it would not be as obvious that someone has left feedback without checking the publication page, there are ways to publish the results here (manually every so often, bot every so often, etc) but I am not so sure that would improve the tone of the comments. Another option would be to have the form generate a new subpage for each comment left, Feedback/{timestamp}, which might make it easier to delete the crap more quickly, but it is also harder to watch since Watch doesn't cascade (as far as I know). - DaveRoss 10:29, 4 April 2008 (UTC)

I always thought that we were trying to provide a resource for the young, non-native speakers, the not-so-well-educated and so on as well as the intellectually curious, witty, and well-educated polylingual. I don't expect them to be making erudite comments. If we could reliably collect grunts that would be valuable. We will rarely get insightful comment in Feedback, but, if we take the Feedback seriously, we might ourselves get some insight into users. "Feedback" is particularly useful to ground newer sysops (like me) in the reality of who the user base actually is. Until we get superior means of getting feedback we should treasure and exploit what we have what we have. I am still wondering how to measure the success of what we are doing by means other than counting complaints and the ratings. But total traffic certainly seems quite low for the amount and quality of content that we have and the WP-generated traffic seems to be a large share of our total. DCDuring TALK 14:27, 4 April 2008 (UTC)

Well, when it comes to raw clicks on the poll, we have collected a little over 15,500 poll responses since implementation...that is not a trivial number. That is between all four wikis which implement it, but en.wikt is the largest wiki which uses it and has the vast majority of responses. I will see if I can give a little breakdown of what the results to date look like, but it will take a little while to generate. - DaveRoss 20:51, 4 April 2008 (UTC)

Thanks. At your convenience. Much appreciated. Any entries with hits from multiple users would be interesting. Is it hard to filter out multiple hits from same user? or same IP address within same hour or day? Frankly any results that could be analyzed by others would lead to a realistic assessment of what kind of periodic processing would be most useful to clean the data. A simple dump grouped by namespace and sorted by page name (and UTC, if possible) would be a good start. DCDuring TALK 23:36, 4 April 2008 (UTC)

en.wikt specific stats:

• Feedback count: 12322 (77% of feedback is for en.wikt )
• Unique IPs: 10714 (1.15 feedback per IP)
• Unique pages: 8735 (1.41 feedback per page)
• Distribution: chart of top 500

Also of note is that IPs are only counted once per minute, so someone clickspamming wouldn't be effective, but someone giving feedback while browsing should still be able to do so on every page. There is a 3/4s done feedback results page, I have been distracted with a few other projects since I was working on this one but you can fool around with the results at this page.] There are a bunch of parameters passed via URL to change what data is included and how it should be sorted, I can elaborate but it isn't done and is subject to change. - DaveRoss 04:38, 5 April 2008 (UTC)

It seems really weird that a unique IP count on less than 12,000 rows would break anything. Mike Dillon 05:12, 5 April 2008 (UTC)

I was probably hasty with my algorithm, but just generating a list of unique pages takes ~10sec...the toolserver isn't terribly speedy, nor is PHP. - DaveRoss 23:53, 5 April 2008 (UTC)

I have updated the above stats to include unique IPs, and a current count as of posting. DaveRoss 17:01, 6 April 2008 (UTC)

In case people want to look at the data themselves: stats generator and feedbacks version one and two. - DaveRoss 02:41, 9 April 2008 (UTC)

Is it possible to get a sort of the data by entry for principal namespace in en.wiktionary only. That would allow me to determine, without having to wade through the vast numbers of special and WT pages:

1. whether multiple hits for a given entry were probably from same person
2. whether there were multiple negatives (probably not from the same person) for the same entry.

My hope is to generate a shortlist of entries that users have actually looked at and which more than one person has found wanting. It would be interesting to see if it corresponds to any lists that we have (frequency or rfc, for example) or if there are any common characteristics for the entries (multiple languages, etys, PoSs, senses, for example). DCDuring TALK 03:48, 9 April 2008 (UTC)

I don't seem to be able to see all of BP. Is that a technical limit specific to IE7? Does some of the BP discussion need to be archived or moved elsewhere. DCDuring TALK 21:19, 3 April 2008 (UTC)

IE7 has no trouble with BP on my computer. RJFJR 14:44, 4 April 2008 (UTC)

Whatever my problem, it seems to have been transitory. I have had other problems with IE7 relating to refreshing (It locks up completely.), so I am quick to blame it. DCDuring TALK 16:21, 4 April 2008 (UTC)

The IRC link at the top of each page returns a 404 Not Found error. --EncycloPetey 04:48, 4 April 2008 (UTC)

They've moved things around a bit - should be fixed now if you ctrl+alt refresh. Conrad.Irwin 10:44, 4 April 2008 (UTC)

That doesn't do anything on my Mac ;) I'm no longer getting a 404 error, but my computer will not connect. It displays the URL and "favicon", but the attempt to connect just hangs and never completes. --EncycloPetey 19:37, 5 April 2008 (UTC)

I have been unable to use the wikizine chat this afternoon at all - though when it is back I hope the irc link will work. Have you tried using http://mibbit.com - which is also IRC over HTTP with no plugins needed? Conrad.Irwin 22:08, 5 April 2008 (UTC)

Someone brought this up on BP, and it has been on the to-do list for AutoFormat for a while. So I've added the code, it wasn't too hard to do. There are an interesting number of cases where someone has missed alpha order by a little bit. Some points to what it is doing:

• only sections marked with {{trans-top}} (including those converted on the same edit)
• balancing is based on the wikitext lines
• nested sections (using *: for subsequent lines) are, of course, kept together, and counted correctly
• languages within them (such as Chinese languages) are not sorted
• {{trreq}} is read correctly
• ill-formatted lines, including comments by themselves, prevent sorting
• the code guesses when a long line will wrap, and should be counted as two or more; it can't do this exactly because the rendering depends on details of template expansion, browser, platform, user fonts, and user window size ...
• the vertical spacing of the lines varies a bit with the sub-sections (*: lines), some fonts, and {{t}} uses

In general, if you see comments like "put A to I here" and "put J to Z here", kill them (that isn't quite right anyway ;-); comments on a specific language should be on the end of that line, so it is clear what language they belong to. A comment immediately after {{trans-top}} I will arrange to recognize and leave there; sometimes there is a comment like "put only colloquial forms here".

Any other ideas or comments? And please of course tell me if you see something odd. Robert Ullmann 09:35, 4 April 2008 (UTC)

You can see the nested section and long line wrap counting at work in the first table at bus Robert Ullmann 12:00, 4 April 2008 (UTC)

Very, very nice. Is there anything like this for "rel" tables, either in operation or to come? Is it possible to bot-convert the old-style tables to the collapsed ones? DCDuring TALK 17:22, 4 April 2008 (UTC)

Sticking to trans for now, but balancing rel-top would be an obvious variation. AF does convert {{top}} to trans-top if it has a gloss, either on the previous line with ; or ''' or as a parameter to the template. If you see a {top} template that needs a gloss, just add it, and AF automatically picks up that entry and converts the template, sorts, balances, does your laundry, cooks ... Robert Ullmann 12:44, 6 April 2008 (UTC)

Now if we could just get it to improve Webster 1913-based entries.... DCDuring TALK 12:54, 6 April 2008 (UTC)

I'm not sure we would always want something like {{rel-top4}} to be autobalanced. For instance, in a "Derived terms" section for a common word, having one column for one-word derivations, one column for polywords in which the headword comes first, and one column for polywords where another word precedes the headword can make for a much easier-to-scan list than simple alphabetization. -- Visviva 13:06, 6 April 2008 (UTC)

Right; there are a number of things like this. And they aren't like the translations tables, which are edited by a large numer of people over time, typically adding one language in each edit. So a you say I'd think not. Robert Ullmann 13:26, 6 April 2008 (UTC)

Although no one seems to care, I believe this is a good division to make, and I had once proposed doing it under another header and now just as separate tables under Derived terms (as I've seen others do for phrasal verbs). That's because those terms that are derived with affixes or especially stem changes should be much more prominent, e.g. (deprecated template usage) timely under (deprecated template usage) time. However, I would want to deprecate making such distinctions with the use of columns precisely because it would be much nicer to have these automatically balanced by bot. What would you recommend looks best for splitting them out into maybe two separate tables? DAVilla 15:57, 7 April 2008 (UTC)

In the future, another thing that could be done as far as tabular data is concerned is to split listings that are divided by a slash, comma, etc. into two line items, e.g. theater / theatre as a related term, since these are supposed to be alphabetized. I mention this here not because it's a priority (clearly not) but because it may not be clear that this is the correct thing to do. DAVilla 15:57, 7 April 2008 (UTC)

Two thumbs up! :-D —Ruakh_TALK 22:44, 4 April 2008 (UTC)

I'm curious, since I brought it up in the Beer Parlour not too long ago, how AutoFormat handles the listing of Chinese. Does it correct the name in some cases, e.g. "Chinese Mandarin" to something else? Does it split the indentation under "Chinese" into a line item for each of Mandarin, Cantonese etc.? I assume it's basically laissez fair, and if you're happy with that then so am I, or if you'd like more direction a vote can be proposed. DAVilla

It sorts a block starting with a language (or putative language ;-) followed by either *: or ** lines as a unit, under the language name, and doesn't break it over columns. It doesn't try to sort the sub-lines. From looking at quite a number of these, I note that often if the sub-lines are languages, someone has used **, while if they are something else (such as the persistent Serbian case), they use *:. That seems very reasonable: something looking for languages could treat * and ** alike, and ignore *: lines. Robert Ullmann 12:47, 11 April 2008 (UTC)

By the way, I like the A to I and J to Z split because then at least it's predictable where the language name will show up in the list, and in all but the most exceptional cases I think that is more important than having it look even. Balancing by the number of lines doesn't always work anyways because sometimes a language will have an unusually large number of translations that fill into several lines depending on how wide the browser window is. But as long as the community is open to considering one option versus the other I'm very happy that AF is empowered to make such changes. More than what the standard is, what's important to me is that there is one. DAVilla 15:57, 7 April 2008 (UTC)

(setting aside the issue that A-I and J-Z is wrong ... look at iron and butterfly and note that Japanese is only halfway down the first column, the split is somewhere in M ;-) If there are a very small number (1-4 say), they can all end up in the 2nd column, which does look really bad. Balancing by lines is (as you say) only approximate, although it usually can be done very well (note that long lines are accounted for), but is (as you say), not important to have it perfectly even. Robert Ullmann 12:47, 11 April 2008 (UTC)

For what it's worth, the A-I/J-Z split is something I introduced a long time ago. It was thought to be a good thing for a while, but it is now obsolete and deprecated. — Paul G 09:29, 3 June 2008 (UTC)

It looks like any translations using {{ttbc}} are being sorted to the end because "{" comes after the alphabet in ASCII order. See independent where {{ttbc|Persian}} was sorted to the end. Is the the desired behavior? Mike Dillon 02:54, 28 April 2008 (UTC)

{ttbc}'s aren't supposed to be in those tables, they should be always under checktrans. So the entry is faulty to start with. Of course, AF could certainly be taught to note this rather than sorting. It doesn't bother sorting the checktrans table, so doesn't have a rule for parsing the {ttbc}s. It does parse {{rfc-trans}}, and sort it. I've been thinking of having it flag anything in the table that it doesn't understand. Robert Ullmann 07:15, 28 April 2008 (UTC)

Doing this now. Robert Ullmann 08:50, 28 April 2008 (UTC)

AF is tagging {{trans-top}} sections it can't parse well enough to sort, with a simple set of expectations. Is finding a few. See Category:Entries with translation table format problems which documents what it thinks it should be seeing. Robert Ullmann 10:46, 29 April 2008 (UTC)

It also seems to be tagging as problems ttbc's in trans-top sections with the manual title "Translations to be checked" (in various capitalisations) following a {{checktrans}} on the previous line. It would be good if it could either deal with these as normal or convert {{checktrans}}¶ {{trans-top|Translations to be checked}} to {{checktrans-top}}. Thryduulf 10:57, 30 April 2008 (UTC)

I have prepared a list of audio files waiting to be added to entries. You can add them gradually on hand and remove done entries from the list or write a bot which will insert these files to entries (good luck). Because I find any further cooperation with people on English Wiktionary impossible, I also would like to request the removal of bot flag from account DerbethBot - it won't be used any more. --Derbeth ^talk 19:25, 5 April 2008 (UTC)

It is really too bad; I had blocked DerbethBot because (initially) it did not handle our entry structure correctly. On review, Derbeth's attitude was (approximately) that our structure was too hard (not like other wikts), but that Derbeth had fixed something and hoped it would work correctly. If Derbeth could've/can say "Yes, I understand the format, yes, I have properly coded for it, yes, I have tested it carefully, and I will continue to check it for mistakes." — then there would be no problem. Haven't heard anything like that. Last time I looked at this, I left it blocked. Any admin is free to review that and change it. Robert Ullmann 07:38, 6 April 2008 (UTC)

Actually I have tested the bot based on information about entry structure here I have learned from your official policies and from few hints you have given me (within one month of the vote for the bot flag). I was sure that it was working well, under the assumption that you follow your own rules of making entries. Suddenly it occured that those schemes weren't even the half of different entry layouts that can be met here and noone can guarantee that even more crazy ideas (like tranclusion of parts of page via template-like syntax or something even more weird) won't pop out. Because Robert Ullman ignored any steps towards solving the situation (by simply not responding to my messages) and noone is able to say precisely, what the bot should be prepared to meet in entries, it seems that I'm simply wasting my time here. Only thing that I can add is that on Wiktionaries that follow any rules in writing entries, the bot worked "out of the box" and added 4000 files in German and 1700 files in Polish Wiktionary. I have never heard any complaints about its work there and some people have even bothered to say "thanks". --Derbeth ^talk 08:53, 6 April 2008 (UTC)

sigh. If others would kindly refer to User talk:DerbethBot you will see that 'I have responded in detail to every message, and laid out very precisely what the algorithm should be. As to "on wiktionaries that follow any rules"? What can I say, we have rules for well-formed entries, they are just one level more complicated. The only problem here is attitude. I would be very much happier if this was run by someone who wanted to participate, instead of insisting that what they have done elsewhere must be right, and thus we must be somehow wrong. As I have said repeatedly, it is a crying shame that Derbeth's attitude is the only thing in the way of doing this. Robert Ullmann 13:01, 6 April 2008 (UTC)

You are starting off-topic here. The algorithm given by you does not work, because it cannot deal with entries which theatre. How can you guarantee that cases like theatre are not common? In my opinion, you've run into a mess you don't have any control on. Again, you are free to try your hand in writing a better bot, you can also have fun adding all these files manually. It's an EOT for me. --Derbeth ^talk 13:40, 6 April 2008 (UTC)

Could you clarify your use of the verb theatre#verb or did you mean "like the entry theatre"? DCDuring TALK 15:23, 6 April 2008 (UTC)

I have said very clearly that it is not a problem if the bot mishandles malformed entries like theatre/theatre of which there are a handful, where someone experimented, and just left the experiment to rot. They are not common. Robert Ullmann 17:49, 6 April 2008 (UTC)

In WikiPedia, if you don't find an entry directly, you are presented with the Search page, as here. But a big difference is they add other search options -

• MediaWiki search
• Google search within Wikipedia
• Yahoo
• Windows Live
• Wikiwix
• Exalead

This is great for searching for phrases, as opposed to words; trying to get near to the word you want.

Can we get into Wiktionary a.s.a.p. Please.--Richardb 00:46, 6 April 2008 (UTC)

Good idea. added. Hard refresh and it should be there. - DaveRoss 01:11, 6 April 2008 (UTC)

Hard refresh freezes my IE7, so I restarted IE, but don't see the google search. Do I have to turn off features that I've selected? DCDuring TALK 15:58, 6 April 2008 (UTC)

If you visit Special:Search/nonexistententry, right above the "No page text matches" header, you should see a text-input field that says "nonexistententry", a drop-down that defaults to "MediaWiki search", and a button that said "Search". It's the dropdown that gives you the option to Google-search instead.

However, restarting IE probably won't be enough; if you can't do a hard-refresh, you might want to clear your on-disk cache (your "Temporary Internet Files" folder) and then restart IE.

—Ruakh_TALK 16:04, 6 April 2008 (UTC)

I hadn't deleted those files in a while. Thanks for the ancillary benefits. Unfortunately, I see MediaWiki, Google, Yahoo, and Windows Live search, but not Google search of wiktionary or mediawiki sites. — This unsigned comment was added by DCDuring (talk • contribs) at 16:56, 6 April 2008 (UTC).

Oh! We've been miscommunicating, sorry. The one labeled "Google" is specifically a Google site-search of the English Wiktionary. —Ruakh_TALK 17:09, 6 April 2008 (UTC)

It bore the label "Web" once the search had run. I thought such Google site-specific searches had a lable indicating that they were restricted. The advanced search link there did not show any site restriction either. DCDuring TALK 17:34, 6 April 2008 (UTC)

OK. never mind. I expected better labelling, but I see how it works in WP for the restricted site search and it is similarly under-labelled. It must be working. DCDuring TALK 17:40, 6 April 2008 (UTC)

We can change things to make them clearer, what were you expecting? - DaveRoss 17:42, 6 April 2008 (UTC)

Yeah, I guess that Google only shows you that you're searching within a site if there are actual hits; like, try Special:Search/foo. (It still says "Web" — as opposed to "Books" or something — but when it describes your search at top right, it mentions the site restriction.) —Ruakh_TALK 17:45, 6 April 2008 (UTC)

(Edit conflict) I see now that the problem only arises when the Google search doesn't produce any results. It then doesn't say what it has done and allow user to change your search terms. Perhaps Google does this by design. If the screen at least gave an indication of what had been attempted, then a single back-button click would get user back to a place from which a useful search could be conducted. (Basically what Ruakh said.) DCDuring TALK 17:52, 6 April 2008 (UTC)

It should also appear on Special:Search, and any page which transcludes that page (including the above mentioned). - DaveRoss 16:29, 6 April 2008 (UTC)

Cool! And I notice that now, if you don't type anything in the sidebar search-box, and just click the "search" button, you get the advanced-search content of Special:Search. This is a big improvement over how it used to be. :-D   —Ruakh_TALK 16:50, 6 April 2008 (UTC)

Is there a chance that there is some kind of propagation delay at server level? I still dont' have this. DCDuring TALK 17:04, 6 April 2008 (UTC)

You won't be getting it (unless we figure out some fancy hack) on the sidebar search, it is only on Special:Search. If you aren't seeing it there yet you should clear your cache (.js cache and page cache) and restart your browser. - DaveRoss 17:06, 6 April 2008 (UTC)

I'm hoping I'm not missing something obvious. Clearing the .js and page caches is accomplished from the SunJava console or from where? DCDuring TALK 17:18, 6 April 2008 (UTC)

Is there any way to override the presentation of Special:Search in the MediaWiki space? The layout of the page is absolutely horrid. DAVilla 15:21, 7 April 2008 (UTC)

We can make it look however you want (kind of), what did you have in mind? You can also change it somewhat using Monobook.css. - DaveRoss 02:45, 9 April 2008 (UTC)

Thanks to all, for the suggestion, for the rapid implementation, and, especially for bearing with me. DCDuring TALK 17:56, 6 April 2008 (UTC)

Following up User talk:Conrad.Irwin#Show on left and IE7 freezing. Thank you very much to DCDuring and Robert Ullmann. It was been noted that IE7 will crash and try and consume all system resources after a page refresh on Wiktionary. It seems that this behavior is only triggered when the popups.js WT:PREF is enabled - which makes it not urgent. In an effort to try and fix this we need to narrow down what exactly is causing it to crash - I sadly don't have IE7 so all I am asking is that those interested in getting this irritation fixed play around a bit, as and when they have time. Two things that would be good to check first are:

• Try WT:PREFS with only Paper view, or other large intrusive extension enabled (though nothing is nearly as big as popups).

• Try adding the following to Special:Mypage/monobook.js and turning off all prefs

    document.write('<script type="text/javascript" src="' 
             + 'http://en.wikipedia.orghttps://en.wiktionary.org/w/index.php?title=User:Lupin/popups.js' 
             + '&action=raw&ctype=text/javascript&dontcountme=s"></' 
             + 'script>');
    document.write('<script ' 
            + 'type="text/javascript" src="https://en.wiktionary.org/w/index.php?title=User:Connel_' 
            + 'MacKenzie/mess-with-popups.js&action=raw&ctype=text/javascript"><\/' 
            + 'script>');

Let's have some collaborative javascript debugging fun! Conrad.Irwin 14:45, 7 April 2008 (UTC)

Using WT:Prefs: Lupins alone freezes IE; Paperview alone does not. DCDuring TALK 15:22, 7 April 2008 (UTC)

Turning off WT:PREFS: above monobook does not lead to freeze of IE7 on refresh. DCDuring TALK 15:36, 7 April 2008 (UTC)

This gives me vastly better performance on popups. I may return to patrolling. DCDuring TALK 15:40, 7 April 2008 (UTC)

It froze again on referesh, without Lupin checked at WT:PREFS but with the above in monobook. DCDuring TALK 17:05, 7 April 2008 (UTC)

It might have been made better by the recent update of WT:PREFS, otherwise I'm afraid it looks like there is a problem with IE+popups.js, possibly because it is coming from a different url and makes lots of changes to the DOM - some of which the security filters seem to block, others which don't. The only the thing I can think of to test is to try including a different 'pedian script - but I'm not sure how to do that. Conrad.Irwin 00:13, 13 April 2008 (UTC)

Is it at least reported as a bug to MS, to MediaWiki, and to popups author? It is not a show-stopper bug (well, it is, but it's not that hard to avoid). It just makes me experiment-shy. DCDuring TALK 13:17, 13 April 2008 (UTC)

I reckon it would be a good idea to have {{citation}} automatically added to each page in the citations namespace, but I've no idea which MediaWiki page to change to do that. I don't see any reason why any Citations: page would not benefit from having it, even those without an NS:1 entry. Keene 15:12, 7 April 2008 (UTC)

Automatic by bot might be better, since there are cases where we'd want to add alternative forms. Also, we haven't had too many cases where discrimination of senses is necessary, so you probably haven't seen any alternatives to {{citation}}, but they are necessary and the format has not been hashed out. DAVilla 15:17, 7 April 2008 (UTC)

The other thing that we need to ensure is that {{seeCites}} or an equivalent template is added to link to the Citations pages for users who do not have javascript - until we get bugzilla:13228. Conrad.Irwin 17:09, 7 April 2008 (UTC)

I am pretty sure there is no way to have default text inserted by namespace (unless the js kids get to work, I bet the can do some trickery where the editbox checks to see if they are making a new page and sticks {{citation}} in at the top if so...) so for now we can have AutoFormat stick it in when missed or whatever. Are there many citations pages which lack that template? - DaveRoss 02:48, 9 April 2008 (UTC)

(Edited your comment.) For any entries with a citations page, that's the way is should be. Since Citations pages are more or less "behind the scenese", I don't see any reason to force it as TheDaveRoss suggests. Those of us who don't have javascript, if that even applies to anyone, should know to check the Citations page before deleting an entry. DAVilla 16:06, 9 April 2008 (UTC)

Since today morning (CET), the folding of translations and related terms is broken for me. I have had such a problem before, and it had been fixed then. The problem was related to my user setting: editing using right mouse-click on the headings. Put differently, the changes performed by people to the code of the folding worked fine in the standard setting, but not in the one I had. --Daniel Polansky 07:48, 8 April 2008 (UTC)

Sorry, same problem as last time - It should now be fixed such that it won't happen next time. Conrad.Irwin 11:03, 8 April 2008 (UTC)

It is working again; thanks. --Daniel Polansky 12:20, 8 April 2008 (UTC)

I haven't changed my preferences, so why are all items for the Deletion log now listed separately, instead of together the way my Preferences are set? --EncycloPetey 04:10, 9 April 2008 (UTC)

Having listened one time (or several times) too many to whining about RHS float boxes and images messing up the edit tags and RHS toggles for translations tables, and since no-one else would just go fix it:

They shouldn't wander around anymore, or appear underneath or over images etc.

See saxophone. (make sure you refresh cached CSS)

I think I still have to hide it from IE though; it has no idea. There is a little more trickiness that could be applied.

The trans tables (NavFrame) is more a matter of not forcing them to 100%. Robert Ullmann 16:19, 9 April 2008 (UTC)

IE can't do anything right, can it?

FF, etc work fine. Robert Ullmann 16:26, 9 April 2008 (UTC)

IE works better, there is something else to fix. Robert Ullmann 17:05, 9 April 2008 (UTC)

The edit tag placement now works in Safari as well. --EncycloPetey 22:53, 10 April 2008 (UTC)

Ah, someone added classes to {{wikipedia}} by wrapping it with two extraneous levels of div tags, which is not harmless (in IE). (They didn't know a div can have more than one class=, or more that one class name in class=?) There are probably some others that will need to be fixed. Robert Ullmann 17:40, 9 April 2008 (UTC)

I'm with you on the having more than one class-name in the class attribute, but — having more than one class attribute? That would be ill-formed XML (and therefore ill-formed XHTML), and I'm fairly sure that it would be ill-formed SGML (and therefore ill-formed HTML) as well. More to the point, MediaWiki will only let through the last one, so even if browsers allow it, we can't use it. —Ruakh_TALK 19:00, 9 April 2008 (UTC)

And for your next trick, could you get translation tables to play nicely with pictures - see user:Thryduulf/bassoon (cf. bassoon)? Thryduulf 16:43, 9 April 2008 (UTC)

Yes, that is coming. Works in FF now, I keep switching browsers ;-) You shouldn't need the two column table hackery to make this work correctly (and use full width when the pix aren't there.) Robert Ullmann 17:05, 9 April 2008 (UTC)

Okay. Done ;-) see bassoon Robert Ullmann 17:45, 9 April 2008 (UTC)

Excellent, that's working in Firefox in windows (the only browser I've got available to test with atm). Now, if only I could remember the 2 or 3 other articles I used this two-column hack on... Thryduulf 18:33, 9 April 2008 (UTC)

I don't understand how you did that, but thank you! :-) —Ruakh_TALK 20:35, 9 April 2008 (UTC)

Um, wow. Ditto. (HTML/CSS has become a lot more complicated than the HTML2 stuff I used to write by hand) Cynewulf 03:08, 10 April 2008 (UTC)

Gory technical details: you will note the tags were floating in some cases quite a distance from the header, you'd expect them to stay on the same line, eh? So: floating boxes float within the parent container.

The "editsection" class object (that has content "") is within the h1, h2, etc tags. But they were clearly floating within <body>, not within the headings. The reason for that is then seen to be "simple" (ha!): headings are not containers they are simply inline text boxes.

Solution is to make h1, h2, etc into containers, by giving them one or more container attributes. Declaring "overflow:hidden" will do that; but IE (*sigh*) won't do it unless either width or height is also specified. So I added "width:auto", and we are good.

Similarly, I added "overflow:hidden; width:auto" to NavFrame to size it as a container within the space available (not 100%), and removed the "clear:right" from {trans-top} and friends to keep it from being pushed down.

All float right boxes should use class="floatright", and not use "clear:right", "float:right" or "margin". This way they will all play together. Some use margin .5em, some 1em, this way they will all be the same, and the same as class="thumb tright", used for pictures. Robert Ullmann 15:07, 10 April 2008 (UTC)

Do we have to specify "right"? I thought things were set up so that right was the default and so that we weren't having to put so much format information into the pages. Is this fix dependant upon images specifying "right", then? --EncycloPetey 22:55, 10 April 2008 (UTC)

Specify "floatright" in templates for boxes etc, not in pages. Images should always just say "thumb", not "thumb|right". You are correct, the "right" indication should never be in pages. Robert Ullmann 12:30, 11 April 2008 (UTC)

I don't suppose you'd happen to have any relevant links? h1, h2, etc. are block-level, not inline, at least in Firefox (and Appendix D to the CSS 2.1 candidate-spec informs us that that's typical). I can't dispute that adding overflow: hidden to a heading's CSS apparently causes the heading to narrow and any child floats to jump inside it (and it to grow vertically to accommodate them), but I can't account for this result by reference to the CSS specs. What am I not seeing? —Ruakh_TALK 23:13, 10 April 2008 (UTC)

Yes, sorry, block, not inline. But neither is a "container" with which I will use scare quotes because that term is not in the spec. Without overflow ("overflow:visible") the "box" (used loosely) is just around the text, and any float (or absolute position, etc) is simply displayed outside; the float element floats within body. Any other overflow attribute includes any contained element, and the box is expanded as possible ("width:auto") and the element floated right inside. No, this is not laid out explicity. Robert Ullmann 12:30, 11 April 2008 (UTC)

Confusing! Thanks for explaining. :-) —Ruakh_TALK 18:12, 12 April 2008 (UTC)

I have checked a few options in WT:PREFS, and now in about 1 out of 10 edits this block of code is randomly injected into the edit field when I preview.

I preview a lot when I edit, and this gets very disruptive. It seems to drop in at a random place, sometimes in the middle of a word. Here's a diff where it snuck by me: .

At least WT:PREFS is letting me review its edits, but I'd rather it just get its own user account if it wants to contribute. —Michael Z. 00:08, 12 April 2008 (UTC)

What browser are you using and what PREFs do you have checked? - DaveRoss 00:15, 12 April 2008 (UTC)

Oops, I meant to include that. Safari/Mac 3.1. Checked the following:

• Hide the horizontal separator line before language headings
• (Experimental) Color links orange instead of blue, if target language is missing (translation tables only.)
• Hide the logo in the upper left corner for more left-column buttons
• Show English glosses for mentioned terms in single quotes. (Default is in double quotes.)
• Add an "IRC" link to the right of "log out"

—Michael Z. 00:23, 12 April 2008 (UTC)

I am having a similar problem using Safari in MacOS X, and have been having this problem since January. Random portions of html coding appear on the screen and mess up the display. Also, any time I save edits, the new version of the page is 50% likely to display incorrectly. When I edit at work (where I have a slow connection), preview becomes worthless, and I can't tell whether my edits are correct until I've saved and then refreshed following the save. --EncycloPetey 00:24, 12 April 2008 (UTC)

Yikes. Come to think of it, I have occasionally noticed random bits of code in other parts of the page, when previewing—could be because this stuff is getting stuffed into some other part of the page. —Michael Z. 00:54, 12 April 2008 (UTC)

This is quite probably because WT:PREFS was written a while ago and was badly in need of making DOM compliant. I have tried to do that without breaking the existing functionality - I'm hoping that if you hard refresh (ctrl+shift+F5) these problems will go away and PREFS will keep working. If you notice that I have broken some or all of them in the process please revert me and I'll have another go ;). NOTE: I have not tested in IE7 or Safari as I don't have them but this works (as far as I can tell) in Firefox 2, Opera9, IE6, Konqueror 3.5. Conrad.Irwin 23:57, 12 April 2008 (UTC)

I haven't noticed this happening since. —Michael Z. 2008-04-24 15:48 Z

Likewise. It seems to be OK now. --EncycloPetey 21:29, 24 April 2008 (UTC)

Hi, could someone go to Template:nominative plural of and Template:genitive plural of and arrange it so the display starts with a capital letter, the way (for example) Template:genitive of does? The syntax of all three templates is too esoteric for me. Thanks! Angr 06:34, 12 April 2008 (UTC)

See Template talk:inflection of#Upper case. I agree that these should all be capitalized and dotted for consistency, but apparently some editors do not. —Ruakh_TALK 18:13, 12 April 2008 (UTC)

Thanks for pointing me to that discussion. I don't much care whether they're all capitalized and dotted or all uncapitalized and undotted, but they should all be consistent. At the moment, they aren't, as a glance at fir#Irish will show. Angr 22:28, 12 April 2008 (UTC)

I just created a reference template for Norwegian entries, Template:R:Dokumentasjonsprosjektet, however, I have been unable to make it work with words containing diacritics-containing letters. I think there is something with {{urlencode:}}. Please see serøs to study present behaviour. the ø is supposed to be coded as "%F8" for the site to accept the query, however, presently this letter is coded as "%C3%B8". I hope someone can make the necessary modifications so that it will work. __meco 12:28, 14 April 2008 (UTC)

The site is using IS-8859-1 (the 8-bit code that covers most Western European). We use IS-10646/UTF-8, which of course covers everything. (just about). There is no template magic you are going to be able to do. URLENCODE always encodes the 8 bit values of UTF-8. You'll have to give the template an optional parameter, to use instead of PAGENAME. For this site, you might want to add &alfabet=o, and have the template parameter use aa, oe, ae. Robert Ullmann 12:49, 14 April 2008 (UTC)

Not the answer I was hoping for, obviously. But I was considering that solution, and I'll make the necessary changes. __meco 16:29, 14 April 2008 (UTC)

Translation bars started to float well with Mozilla Firefox but Internet Explorer is leaving blank, for example on magnetite there's white space next to the picture. Best regards Rhanyeia♥♫ 15:48, 14 April 2008 (UTC)

I can confirm this is happening with IE6. Also the category bar is floating over and obscuring the yellow-bordered disclaimers bar.

In Firefox the Wikipedia box is partly floating over and obscuring the green-backed translations below need checking blurb. Thryduulf 17:34, 14 April 2008 (UTC)

I thought this was fixed; saxophone floats the boxes properly. There is some subtle difference between the image float and the other boxes I haven't found. ("yellow bordered disclaimers bar"? oic: no idea about that!). Robert Ullmann 13:45, 17 April 2008 (UTC)

Is only giving trouble when the wikipedia box follows the image, not the other way around. Sigh. Robert Ullmann 13:58, 17 April 2008 (UTC)

I changed {{checktrans}} a bit to make it a bit better; but both FF and IE have trouble when the next RHS element is wider, and it has already sized the LHS box.

The problem here is that people have been trying to "fix" the links by distributing images and wikipedia templates and so on down through the wikitext. (as in magnetite) They should be simply stacked inside the top of the language section, and the browser will do the right thing.

If you put one or more further down (as has been the habit), the IE browser will do what you are asking for, leave vertical white-space on the left until both sides are clear so it can line up the subsequent box as you are requesting! (FF is smart enough to realize you really didn't mean that ;-) Robert Ullmann 15:26, 17 April 2008 (UTC)

Thank you very much. :) I did to xenotime what you did to magnetite and I wonder why it didn't work at first , only when I changed {{top}} to {{trans-top}}. Best regards Rhanyeia♥♫ 14:02, 18 April 2008 (UTC)

On olivine the Wikipedia box goes over the translation bar, both with Mozilla firefox and Internet Explorer. Best regards Rhanyeia♥♫ 12:18, 19 April 2008 (UTC)

Expanded translation sections are not wrapping completely correctly with pictures. See the Scottish Gaelic translation at greenhouse for example, where the masculine m marker is underneath the picture. Adjusting the window size and preview tests with a string of random characters appended to the word show that this is not just an issue with the {{m}} template. The same behaviour is displayed by Firefox 2.0.0.14 and Konqueror 3.5.8 (both on Kubuntu linux). I'll test firefox and IE6 on Windows later. Thryduulf 18:09, 25 April 2008 (UTC)

Can't see this on Windoze. Works okay. (in any case would have nothing particular to do with {m}, when the entry uses {t} there will be a no-break-space, but that isn't going to be different) I moved the RHS stuff up to stack under the language header, this where it almost always should be. Robert Ullmann 10:01, 27 April 2008 (UTC)

It's working OK now on linux too, I suspect it was an artefact of the css or whatever being reset to default (see lower down this page). Thryduulf 20:18, 27 April 2008 (UTC)

Another issue is that, at least for wikipedia boxes in Firefox on linux (I've not tested further), where the first item in a list wraps for a box, all subsequent items in the list wrap at the same point - even if there is nothing that needs wrapping for. See Heinz 57 for an example. Thryduulf 20:03, 25 April 2008 (UTC)

(note that this isn't stated quite correctly; what is happening is that the first item in the # list is getting the margin, and everything contained within it—the * list—uses that margin)

This is true for images etc as well, the lists acquire a right margin and continue it, instead of flowing around the image or box. The first # list item acquires the margin, and the * list items and : dd's are contained within it. The browser is doing the right thing, but maybe we could see if we could tell it something different. Robert Ullmann 10:01, 27 April 2008 (UTC)

Gory details: What we'd really like to do is make "li" use { display: inline } instead of creating a box to contain the content. However, the default display attribute is list-item which does two things: creates the box for the content, and an in-line box for the "1." or bullet. (If right about now you are saying: "Arrghh! It does TWO things? Gaak!" You have it exactly. ;-) So to get the treatment of the item with numbering, bullets, etc (list-item-style) we get the block that we don't want. So the list item text doesn't flow around the image or whatever.

Does this mean the design of HTML/CSS is broken here? Yes. Robert Ullmann 11:02, 27 April 2008 (UTC)

Yet another issue, this time with boxes in categories. Were the vertical space needed to display all the boxes is less than the height required to display the textual information, the top section of the category isn't expanded to fit, and the list of pages/sub-categories in the category takes no account of them, meaning the boxes obscure part of the listing. See Category:Australian rules football for example. (Tested only in firefox on linux). Thryduulf 11:48, 28 April 2008 (UTC)

Because there is additional text added to what is generated from the wikitext. Fix is to put {{-}} at the bottom. Robert Ullmann 11:58, 28 April 2008 (UTC)

Is there a way to see the longest words in Wiktionary by character? sewnmouthsecret 18:13, 16 April 2008 (UTC)

You could download the pagetitles dump and sort by character length. But I don't think we have Special:Longtitles or anything like that. -- Visviva 10:42, 17 April 2008 (UTC)

Does anyone know what the story is with this diff? I rolled back that edit, then later realized that the diff was wrong; so I undid my rollback, i.e. restoring that edit. But the diff of my edit doesn't have this weirdness, even though my edit should be exactly the same as his. —Ruakh_TALK 00:37, 17 April 2008 (UTC)

Another example. —Ruakh_TALK 14:59, 26 April 2008 (UTC)

Seems to have been a problem with the diff engine as those links all look normal now. Conrad.Irwin 12:19, 29 April 2008 (UTC)

Indeed. Ah, well, whatever; hopefully the problem is now fixed in general, rather than just no longer affecting those specific diffs. :-) —Ruakh_TALK 20:27, 29 April 2008 (UTC)

So I've been fiddling around with User:Visviva/head (which please feel free to edit), trying some of DCDuring's and Thryduulf's notions about subsenses and some random ideas of my own. I'm interested in some feedback on one of those ideas, User:Visviva/jump (and User:Visviva/jump-sense). The idea of this proto-template is to enable 1-click navigation among the various parts of an entry that relate to a specific sense. This seems to work fairly well, although it's certainly not close to ready for prime time. I'm interested in:

1. Acceptability: Does this seem like something that people could live with, in some form or other, for those entries where the definitions alone occupy a screenful or more?

2. Accessibility: For now, I'm using single letters for the links ("s" for synonyms, "t" for translations, etc.). Obviously this is obscure -- at best -- to non-regulars, but I'm not sure what a better way would be. The full words are too long, images can't link to anything but themselves, and AFAIK there is no way to manipulate link titles in MediaWiki.

Also, for this to work, the different lines in the entry need to be kept synchronized, and any mismatched glosses need to be flagged. I'm thinking that coding a bot for this purpose will be difficult, but not fiendishly so; can any of the more experienced coders here tell me if I am deluding myself? -- Visviva 10:37, 17 April 2008 (UTC)

In terms of acceptability it is (unfortunately ;) likely to be much higher than actually solving the problem that this tries to cover (namely putting the sense-related information next to each sense). I like the idea quite a lot but accessibility is low at the moment, it took me a minute or two to work out what was going on - though this could be made, at least a little, better quite easily - by using slightly longer blurbs for links, by highlighting (with javascript) the relevant section etc.etc. . Editability is also a problem, but I haven't had any ideas about that yet. It is definitely possible (quite easy ;) for bots to pick up missing sections/broken links - and in many cases it may be possible (though harder) to get the bot to fix it. As a neat side-effect of this you are implementing the long-requested "link to specific definitions" feature, so this is definitely something worth pursuing. Conrad.Irwin 11:26, 17 April 2008 (UTC)

Thanks. What I was specifically thinking about was a script where if someone entered a usage note for the "top" sense with just the label {{jump|u|top part}}, the script would update all of the "top part" jump templates in the entry accordingly. I guess this would fall into the possible-though-harder category?

Re highlighting: Adding the line font:target { background-color: #DEF } to my monobook.css was enough to highlight the template text (or the entire line in the case of User:Visviva/jump-sense). That's not really optimal, but it looks like anything more would require some fancy JS stuff. Speaking of JS, I was wondering if it would be theoretically possible for a super-fancy Popups-style script to use the information provided by this template to reorganize the page (i.e., to sort everything by sense on the client side). Not that I would expect such a tool to actually be written (by myself or anyone else) anytime soon, just curious if this might be a possibility.

Agree about editability, but am clueless as to solutions. I wouldn't think this would make the editability situation too much worse, anyway. -- Visviva 13:56, 17 April 2008 (UTC)

Wow! Very interesting. This seems like a vital experiment. It might be better to separate the subsense experiment from the other. I'm not sure that they are very synergistic. To me the question is whether it does a good enough job for first-time visitors. For many (what percentage ?) of our visitors, a blue link will be seem as an invititation to click. For others and a smaller percentage with increasing age (on average) they will be mysterious. For some they will be too small to get the pointer on conveniently. The one-letter abbreviations seem too terse, both in terms of meaningfulness and as a pointer target. Is it possible to have 2,3, or 4 letter targets ? Could those who can find "my preferences" be allowed to select fewer letters? DCDuring TALK 11:38, 17 April 2008 (UTC)

A simple expedient like "More: syn tran" with each element getting an explanatory hover box might help with my stated concerns. Relying on customization would mean that we need to make it easier for users to be logged in (pan-MW login addresses that, I suppose) and to find "my preferences". DCDuring TALK 11:46, 17 April 2008 (UTC)

Well, Ruakh was kind enough to add tooltip text, which might be enough to address your concerns; at the moment I've switched it over to full-word descriptions ("image synonyms translations") but will probably switch back to "i s t"-style soon, as the long form seems rather gunky. The halfway solution ("img syn tran") seems kind of wishy-washy, but perhaps it is the best approach. -- Visviva 13:56, 17 April 2008 (UTC)

I think it's great! Where do I vote? :-P —Ruakh_TALK 12:26, 17 April 2008 (UTC)

There is an interesting idea on http://www.websters-online-dictionary.org which also has long pages for entries. I'm sure you've seen it. It's an icon on the right side, depicting a half-opened book, Index written above it. As you scroll down the page, the icon moves, too. If you put the cursor above it, a TOC pops up and the user can select which section to go to. Could this idea be used here? I don't know how to code it, I'm just asking. So instead of listing the options after each entry, a list would pop-up. And this would reduce the number of links added. --Panda10 21:47, 17 April 2008 (UTC)

Yes, I would think it could, but coding it would be far beyond the competence of any but a couple of users here (of whom I am definitely not one). Also I may be wrong, but isn't that a full-entry TOC, linking to sections like etymology even if they contain no material relevant to a specific sense? If so it fills a somewhat different niche (but would nonetheless be a very interesting concept to explore). -- Visviva 12:35, 19 April 2008 (UTC)

• I've tentatively moved this live, to {{jump}}. Will test cautiously in a few suitable entries and report back. Improvements and other feedback welcome. -- Visviva 12:35, 19 April 2008 (UTC)

{{term}} seems not to work correctly anymore, although it hasn’t changed itself. So either someone meddled with CSS or Javascript, or my browser (FF) is messing up. I have the WT:PREF set to show single quotes, no parentheses around glosses, but parentheses around italicized transliterations. Already on the templates talk page, I see:

From {{term|sc=Grek|λόγος|tr=lógos||word}} + ...

being rendered as

From λόγος (lógos “word” + ...

Though funnily enough, if I copy it over from the page, I get

From λόγος (lógos), “‘word’”) + ...

which is, however, wrong as well. Can someone have a look at this? H. (talk) 12:42, 17 April 2008 (UTC)

I haven't noticed any change in how it displays for me, but I haven't set preferences for how the term template displays. --EncycloPetey 13:16, 17 April 2008 (UTC)

This seems to be only on Windows, with Firefox. H. (talk) 15:05, 8 September 2008 (UTC)

This is related to Wiktionary:Grease_pit#Misuse_of_markup_and_CSS. It is probably due to missing CSS support, or caching, or whatever, so I think this can be archived and forgotten. Is this done automatically, or how does archiving work here, actually? H. (talk) 13:10, 15 December 2008 (UTC)

I download wiktionary definitions for analysis using the python library urllib2.

Recently, I requested the content for the definition of corruption. I received a stream of data that was perhaps encoded or compressed rather than the xhtml that I have recieved in the past. I normally get what one can see by right-clicking and selecting "View page source" with Firefox. In fact when I do just that with the "corruption", firefox displays xhtml text.

So at this point I can only impertinently ask, "what's up?". Perhaps another http header is required? Doesn't feel like that's the problem because so many other requests work just fine without it.

Same deal with the words accessing and sound.

To be clear, out of about several thousand requests, these three pages come back in a form I can't decipher even though "view page source" shows a normal xhtml page for all three. Makearney 00:15, 21 April 2008 (UTC)

The only encoding that it's likely to be is gzip. It certainly wasn't encrypted. Not sure why you would get gzip'd content unless you were sending the Accept-Encoding header with a value of "gzip" (in which case your client should be able to detect and handle it). Mike Dillon 00:38, 21 April 2008 (UTC)

I'm on Windows XP. Changing the file's extension to gz allows powerarchiver to think it can open the file. And it gets a CRC error when it tries to decode the file. All that only indicates that power archiver couldn't decode the file as gzip. My stuff should be ported to linux before long. Once I get there I'll try again. Makearney 13:37, 21 April 2008 (UTC)

Odd, today the page for are is now returning non-xhtml content, and yet according to the history there have been no changes to the page since I last tried it. Makearney 18:23, 22 April 2008 (UTC)

Have you considered getting the database dumps instead? Conrad.Irwin 18:43, 25 April 2008 (UTC)

Considered? yes. Researched? no. My superficial understanding is that a database dump allows one to keep the whole beast locally. But then one needs a process for keeping synchromized with the global source. I don't want to give up the benefit of regular updates/corrections that I believe is a primary virtue of the wiktionary community. Any particular analysis application that I have in mind requires a very small bit of wiktionary data, and I'd prefer to minimize what I keep and maintain locally. While we're on the topic, I'd like to allow local proprietary modification of wiktionary, for application specific jargon, that is not interesting or appropriate to the larger community. Of course that is a standard source management problem that may already be implemented in wikis and wiktionary. These ideas are probably not original so I'd appreciate any ready pointers/links to related discussions. Makearney 14:37, 29 April 2008 (UTC)

Add explicit and subset to the list of words now exhibiting the problem I describe. I accessed them w/o problem before; now the downloads seems corrupted. It's an interesting list: corruption, accessing, sound, subset, explicit, are. I can almost create a sentence describing the problem from the words that exhibit the problem. Weird. I hope it is coincidence. Makearney 14:37, 29 April 2008 (UTC)

And now later in the day, only subset is showing the problem. 71.174.54.216 17:50, 29 April 2008 (UTC) (claiming attribution Makearney)

Symptoms still occurring. This week, different,linked,individual are returning non-xhtml pages. As in prior examples, these pages were fine just a short while ago, and I expect will be ok again soon for whatever reason. Makearney 14:36, 15 May 2008 (UTC)

Symptoms still occurring. As usual different words are involved. Perhaps someday I'll be smart enough to detect/debug what is going on. Makearney 15:52, 20 May 2008 (UTC)

Nearly all calls to this template should instead be calls to the template {{ablative}}. The 3-letter templates are reserved for ISO language codes. --EncycloPetey 03:01, 22 April 2008 (UTC)

I've fixed all the Latin conjugation templates that included it. Once those clear the job queue, there should be a lot fewer. (However, those templates are still using {{nom}}, {{dat}}, {{acc}}, etc. I guess I should have fixed those at the same time. :-/  ) —Ruakh_TALK 03:11, 22 April 2008 (UTC)

O.K., so there are still a bunch. I fixed a few — and could easily bottize the rest — but I'm wondering, are these pages really using these templates appropriately? A lot of them are using them mid-sentence, and I'm just not sure that italicizing every occurrence of the word "ablative" is the way to go. —Ruakh_TALK 21:58, 22 April 2008 (UTC)

Can you give specific examples? --EncycloPetey 23:00, 22 April 2008 (UTC)

Oh, sure, sorry. I'm thinking of ones like sine die and e pluribus unum, but even deo seems strange to me. —Ruakh_TALK 23:35, 22 April 2008 (UTC)

OK. Those should not be using the tamplte. It really only exists for inflection template uniformity, as far as I know. --EncycloPetey 18:16, 25 April 2008 (UTC)

Someone has adjusted a master template or setting. As a result of this change, the various collapsible boxes that hold Translations, Conjugations, Related terms, etc, are now invisible (at least in IE7). This is VERY BAD. --EncycloPetey 18:09, 25 April 2008 (UTC)

Something major has just happened to the software, as a result all the pages in the MediaWiki space were reset to the default. They all need null editing, it's going to take a while... If anyone wants to help let us know which pages you've done so we can avoid them (as null edits don't show up in RC). I've done all the sidebar related ones, and have got to the Accesskeys, heading downwards alphabetically. Conrad.Irwin 18:23, 25 April 2008 (UTC)

Yay, brion very kindly ran some php to do it all for us. Things should now be back to normal. Conrad.Irwin 18:41, 25 April 2008 (UTC)

Nope, the boxes are still invisible in IE6. And no, updating isn't a solution because most US schools are atill using IE6. We can't require all the US schools to update because that would cost money. --EncycloPetey 17:59, 28 April 2008 (UTC)

Just checked with IE6 on WinXP -- boxes seem to be coming through fine. -- Visviva 18:03, 28 April 2008 (UTC)

Hmm, that is quite serious then - by "invisible" I am assuming you mean the state that they were in after the last software update (i.e. the only visible bit was a tag floating on the left hand side with no grey bar ). If this is the case then there is nothing we can do, it is the WMF cache serving the WMF broken software update results. If there is a different problem then it might be something we've done, but I don't think anyone has edited that area of code in a while. I would advise a hard refresh (Ctrl+shift+refresh) Conrad.Irwin 18:06, 28 April 2008 (UTC)

Hard refresh did indeed resolve the problem here, but it shouldn't have been necessary since this computer I'm currently at was shut down all weekend and I don't have it remember my identity. Any idea how long this problem is likely to be around for the masses before the server cache rolls over? --EncycloPetey 21:38, 28 April 2008 (UTC)

Anyone who happened to download the CSS file during that half/hour period (maybe a thousand or so people) may keep the file for something like the next three months. This is why there is a really strong feeling that being able to manually purge the site CSS/Javascript for everyone would be a very very good thing - though it would have the possibility of placing a massive load on the servers as everyone downloaded the new one. Conrad.Irwin 09:26, 29 April 2008 (UTC)

(<-margin) There are 3 levels of caching:

1. the WMF squids
2. a (possible) proxy either on the user's site or in network
3. the user's own machine

The squids will serve out a new version fairly rapidly, but it seems that some subset will do it immediately, and some take days, I don't know where the timing comes from. We could and should have a way to purge these on demand.

The caches will keep CSS for 30 days from when retrieved, so any proxy or user that fetched them during that window will have them for a month. There isn't any way to fix this after the fact. (Short of patching the s/w to use "common2.css" or some such ;-) Some caches may misbehave with respect to remaining time, but nothing we can do about that. I myself get routed through an ISP cache on which I can't force a purge; so I get a new common.css once a month. (User's own .css and .js have different cache retention.) Robert Ullmann 10:39, 29 April 2008 (UTC)

The mechanism I've seen proposed for flushing the user caches of the CSS file is to append the timestamp of the latest update to the CSS file to the URL used to fetch it. Something similar is done for the built-in CSS for the skins, except that the query string is configured by $wgStyleVersion instead of being a timestamp. Mike Dillon 02:08, 30 April 2008 (UTC)

I created {{R:W}}, to refer to Wikipedia articles in a References section (where {{PL:pedia}}'s "has an article" seemed wrong). —Michael Z. 2008-04-26 06:34 Z

I agree that {{R:W}} is better formatted than {{projectlink|pedia}} for reference sections, but I'm not sure we should be using Wikipedia articles as references. We don't use other Wiktionary entries as references, and Wikipedia articles don't use each other as references; I think this falls into the same general category. —Ruakh_TALK 14:44, 26 April 2008 (UTC)

A non-wiki reference would be preferable, but I've cited Wikipedia in a few occasions where a WP article does a good job of explaining something in more detail than would be appropriate for Wiktionary, or provides a better summary than other individual sources. This seems especially useful in cases where other references are offline or otherwise not easily accessible.

I admit I have also simply used Wikipedia as my source as well, when I haven't been able to find the information elsewhere. I'd rather cite WP so you can read and evaluate the source, and perhaps its sources in turn, than simply write a long usage note with no context. Perhaps one day I or another will locate the more primary sources and improve the entry, but I can't do it today.

Examples in the usage notes for Eskimo, Inuit, and Aboriginal. —Michael Z. 2008-04-26 21:45 Z

I think this template is good insofar as it pushes for intellectual honesty in terms of where information comes from. On the other hand we shouldn't really be relying on another open wiki for any assertions of fact. IMO purely "further reading"-type Wikipedia links should be in ===See also=== rather than References, and should use {{pedialite}}.

I suggest that this template should do two things: 1. clearly distinguish Wikipedia references from references that are considered reliable. 2. Place the entry into a (hidden?) cleanup category, Category:langcode:Entries citing Wikipedia or similar, to facilitate future cleanup. -- Visviva 09:18, 28 April 2008 (UTC)

We also have to face the issue of prescriptivism here. Claims like "is considered offensive in Canada and Greenland," are staying awfully close, and really, the best reason we favor primary source quotations over secondary sources is that ought to adequately describe how people use words, not how they are supposed to. The same holds true for usage notes. I would prefer a primary source example of "Eskimo" being used or understood pejoratively to a reference to Wikipedia, or anyone else, saying that it is. As long as there are quotations, then I'm not really worried whether they were inspired by Wikipedia or anyone else—that's how Wikipedia is supposed to be used, as a general reference to orient further research. Dmcdevit·t 09:58, 28 April 2008 (UTC)

Fair enough, but I don't see how that is specifically relevant to citing Wikipedia. A reference to a published usage guide or dictionary would have the same problem. On the broader issue, I don't entirely agree; individual citations are seldom enough to back up any sort of global assertion about usage; a balanced mix of primary, secondary, and tertiary sources is optimal. -- Visviva 11:03, 29 April 2008 (UTC)

For the specific cases, I haven't used Wikipedia as an only reference, but preferring "See also" sections may be a good suggestion.

Regarding prescriptivism, I think it's fair or even important for usage notes to help keep one from accidentally insulting another's heritage, even if they temporarily have to rely on Wikipedia (but in these cases I have referred to dictionaries for that). Obviously, we have all kinds of information which is waiting for references, as well as information citing the gamut of irrelevant, through crappy, through excellent published references—citations of Wikipedia articles which are in turn referenced fall somewhere within that range. —Michael Z. 2008-04-30 21:37 Z

I am writing a book and need the author of TAKE TIME AND SMELL THE ROSES.

Does anyone know?

Many thanks!!!

Sources:

• Google; w:Google
• Amazon; w:Amzazon
• LoC; w:Library of Congress

DCDuring TALK 17:38, 29 April 2008 (UTC)

I know this may be a random and unspecific question but I was wondering if there was anyone that knows if there are any theories about different ways of getting a case of the goosebumps. Such as theories of spiritualism or such that have been thought of to give someone a case of the goose bumps.

This is way outside the scope of this page and this project. Maybe the Wikipedia article on w:Goose bumps can shed some light on your questions. - DaveRoss 02:00, 30 April 2008 (UTC)

Need some help with this. I'm an admin on English Wikipedia and am unifiying my Wikimedia accounts. I couldn't remember my password here and the password reminder hasn't gone to either of the accounts I'd logically expect it to. There's only a handful of edits under Wiktionary's User:Dweller account and I'm happy for the account to be binned so I can restart it. No idea if this is possible, or if it causes GFDFL problems etc. Could someone knowledgable about this please contact me at my English Wikipedia talk page? Many thanks. --194.176.105.39 11:25, 30 April 2008 (UTC)

Not sure how this is handled, but I note that there are no actual edits by that accout. The edits at Special:Contributions/Dweller all predate the account's creation, and are actually revisions by the Wikipedia account brought over via transwiki. -- Visviva 12:17, 30 April 2008 (UTC)

Contact a bureaucrat on WT:MV and they will determine the necessary verification for you. --Connel MacKenzie 20:45, 30 April 2008 (UTC)

C'mon now I haven't been gone that long. Alt-R should jump to recent changes, but no longer does. Alt-F still goes to the search box, so not everything is broken. Anyone know what changed recently to break the shortcut keys? It isn't just my account, as the behavior is the same when logged out. --Connel MacKenzie 20:50, 30 April 2008 (UTC)

I don't think anything like that has been changed since I broke and then refixed all the other "entry" tag's Alt-shortcuts. Though there was a big MediaWiki update that borked the whole MediaWiki: namespace - so maybe something happened then. Conrad.Irwin 13:37, 1 May 2008 (UTC)

Alt-X doesn't work; Alt-E and Alt-P (the latter in edit mode) does work... :? \Mike 12:54, 2 May 2008 (UTC)

Well, they are positively still broken... --Connel MacKenzie 08:06, 6 May 2008 (UTC)

I can only assume that they have been removed from MediaWiki itself as they are not specified on Wiktionary. As I never used them I can't add them back - though I assume something could be done with the object at the bottom of Mediawiki:Monobook.js. Conrad.Irwin 10:18, 6 May 2008 (UTC)

As with Connel, alt-x and alt-r no longer work for me at Wiktionary, though they still work fine at Wikipedia. Dmcdevit·t 11:30, 6 May 2008 (UTC)

See MediaWiki:Accesskey-recentchanges. I haven't a clue why this shouldn't work. Conrad.Irwin 14:51, 6 May 2008 (UTC)

Interesting thing is that MediaWiki:Accesskey-recentchanges exists locally, while MediaWiki:Accesskey-save and MediaWiki:Accesskey-preview don't, so they bring up the default (and I get these shortcuts to work!). By some reason, when I tried to delete -recentchanges, I never got to see any default value.... Is there any connection? \Mike 15:07, 6 May 2008 (UTC)