text:
Wiktionary:Grease pit/2008/April

category:Medicine vs category:Medical
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...

Focus for first input by normal user (i.e. text string in search field)
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.org/wiki/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.

 * 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..  ? --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   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  ; 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,  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)

Feedback overload?
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). -  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. -  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 [16023 total])
 * 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. -  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. - 23:53, 5 April 2008 (UTC)
 * I have updated the above stats to include unique IPs, and a current count as of posting. 17:01, 6 April 2008 (UTC)

 * In case people want to look at the data themselves: stats generator and feedbacks version one and two. - 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:
 * whether multiple hits for a given entry were probably from same person
 * 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)

How big a page is too big for IE7
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)

Latest IRC problem
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)

Sorting and re-balancing translations
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 (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
 * 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 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 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 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 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. timely: under 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)

Problem with ttbc?
It looks like any translations using are being sorted to the end because "{" comes after the alphabet in ASCII order. See independent where  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, 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 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 on the previous line. It would be good if it could either deal with these as normal or convert ¶ to. Thryduulf 10:57, 30 April 2008 (UTC)

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

Wikipedia has added Google search. Would be good to add it here too.
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 - This is great for searching for phrases, as opposed to words; trying to get near to the word you want.
 * MediaWiki search
 * Google search within Wikipedia
 * Yahoo
 * Windows Live
 * Wikiwix
 * Exalead

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

 * 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? - 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). - 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. -  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. -  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)

Refresh crashes IE7
Following up User talk:Conrad.Irwin. 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

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)

Citations pags
I reckon it would be a good idea to have 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, 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 or an equivalent template is added to link to the Citations pages for users who do not have javascript - until we get 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 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? -  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)

Folding broken for me
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)

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

Fixed wandering [edit] tags
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 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 <tt>class</tt> attribute, but — having more than one <tt>class</tt> 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 [edit] 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 "[edit]") 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  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)

WT:PREFS randomly injects code into edit field
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.

.mention-gloss-single-quote { display: inline !important; }

title: Wiktionary:Grease pit/2008/April


text:
Wiktionary:Grease pit/2008/May

missing edit link
Looking at the table of contents at you, "Determiner" appears to be a standard L3 header. Yet it has no edit link and it is editable with the preceding L4 translations section. The markup looks to be fine as well - I'm confused as to what's happening. Thryduulf 17:30, 1 May 2008 (UTC)

 * Well, I'm seeing it on the TOC, and I'm not seeing it when I edit the preceding L4, however, I too am without an edit link for the particular header. -Atelaes λάλει ἐμοί 17:50, 1 May 2008 (UTC)

 * The "editsection" code isn't being generated. (It is in the edit of the preceding L4, but I kept having trouble finding it because there is so much stuff ;-) Very odd. Robert Ullmann 18:02, 1 May 2008 (UTC)

 * Further, if you manually tweak the section-edit URIs to the right numbers (10 and 11 for the "Determiner" L3 section and its "Translations" subsection), you get a "No such section" error. —Ruakh TALK 23:03, 1 May 2008 (UTC)

 * Very odd. I did find some problems with {checktrans-top} matched with a {trans-bottom}, but fixing that did not correct the problem. --EncycloPetey 00:30, 2 May 2008 (UTC)

 * I'd be mighty surprised if that affected anything as is just a redirect to, which itself is one of our simplest templates as it just ends the table and closes two divs. Thryduulf 00:45, 2 May 2008 (UTC)

 * Fiddling with this in userspace, I find that the problem is solved if I comment out or remove the second translation table ("object pronoun: the person being addressed"). However, I can see nothing there but standard templates and standard formatting.  -- Visviva 03:20, 2 May 2008 (UTC)

 * Eureka! With Visviva's info I tracked down the problem.  The Finnish translation line had two unclosed  templates. --EncycloPetey 03:31, 2 May 2008 (UTC)

 * Well done! And I imagine the reason the problem continued only into the ===Determiner=== ====Translations==== section is that that section has a bunch of unpaired s. I guess the software no longer generates edit-links for headers inside templates; which is probably a good thing, because it used to generate them wrongly. (To us it's obvious that  contains one header, but the parser can't tell that, at least not until it expands  and finds that its  ends up in the result exactly once.) —Ruakh TALK 11:33, 2 May 2008 (UTC)

 * I remember on wp a couple of years back there was cleanup of unbalanced parentheses, square and curly brackets, etc (w:Wikipedia:WikiProject Wiki Syntax). Would it be of benefit to do something similar here? Or perhaps add some code to AF that notifies us when it finds an error? Thryduulf 12:08, 2 May 2008 (UTC)

 * A code and cleanup category sound like good ideas to me. --EncycloPetey 18:07, 2 May 2008 (UTC)

 * Before looking at what AF might do, the first thing would be to do some analysis of the dump, and see what can be found; that can generate a cleanup list. Something like User:Robert Ullmann/Mismatched wikisyntax perhaps? (It has you with the problem noted; but who would have ever found yttrandefrihet? ;-) Robert Ullmann 12:00, 3 May 2008 (UTC)

 * I've started working on that list, removing entries after I've fixed them (or ascertained they've already been fixed). I've also added sections to the page to make it a little more workable. Thryduulf 16:31, 3 May 2008 (UTC)

 * Um, the sections are going to get overwritten in a few minutes, as the code finishes re-checking everything against the "live" DB and re-writes the report. If we want sections to edit/strike, I'll have to put it in the code. I figure on re-running it as things get fixed. (as it only reports 10% of the issues now; and I've been improving the filters.) Robert Ullmann 16:42, 3 May 2008 (UTC)

I have improved User:Robert Ullmann/Mismatched wikisyntax to add convenient sections to work on, and improved the filters. The number of problems has been reduced from 2500+ to 1407. Please help if you'd like. Thryduulf has done a number of them, tx. Robert Ullmann 13:28, 9 May 2008 (UTC)

Interwiki dysfunction/ bot question
The way interwikis are added seems somewhat dysfunctional to me.
 * 1) It is irritating to have to type something like example example example when the pages all have exactly the same name, which is the same name as the English page to begin with. Couldn't some code be added to make a simpler option?
 * 2) Why do we have to add these manually at all? On Wikipedia, there are bots which flesh out manually added interwikis, because obviously a bot can't find the correct corresponding encyclopedia entry. Given that Wiktionary interwikis go to the same word, why not just have omniscient interwiki bots that do it automatically? This would of course solve the previous problem also. -Oreo Priest 18:58, 2 May 2008 (UTC)

 * There are bots who does exactly this. See e.g. User:VolkovBot and User:Interwicket. On other wiktionaries are additional bots running. \Mike 19:15, 2 May 2008 (UTC)

 * It's got a good point though, it should be doable completely automagically in much the same way as unified login. Conrad.Irwin 19:17, 2 May 2008 (UTC)
 * Yeah, that's exactly what I meant, but didn't specify very clearly. Just like the unified login, we shouldn't have to chase down the page in every language, either by a bot or automagically, it should just happen. -Oreo Priest 19:30, 2 May 2008 (UTC)

 * Never fear, the bots will get round to it - but in this world of instant gratification why not make the WMF servers do it! Conrad.Irwin 19:34, 2 May 2008 (UTC)
 * So will these bots do what I meant? My impression was that VolkovBot at least only does the same matching of incomplete interwikis as on Wikipedia. -Oreo Priest 19:55, 2 May 2008 (UTC)

 * Not sure about VolkovBot, but Interwicket does exactly what you're describing (adding interwiki links to a;; pages of the same name on other wikts). I believe it crawls the pagetitles dump on a semi-regular basis; the last run finished on April 24, and I don't think there's been a fresh dump since then.  Poke User:Robert Ullmann for more info. -- Visviva 05:53, 3 May 2008 (UTC)

 * Awesome. Thanks! -Oreo Priest 08:12, 3 May 2008 (UTC)

Word usage example
It is VERY helpful but rarely given here for some reason. Look at Russian Wiktionary - it is mandatory there, plus they use very nice formatting, color highlighted green&italic font and it given on the same string as definition - so it is space efficient. Plus they use "◆" for visual separation from definition and it is done using template... TestPilot 05:35, 3 May 2008 (UTC)

 * Rarely done here? We have bajillions of them.  Can't say I care for the Russian layout myself; our standard layout at WT:ELE seems much crisper. The idea of making them mandatory doesn't sit well with me either -- there are plenty of obsolete and technical terms for which a made-up example would only generate confusion. -- Visviva 05:47, 3 May 2008 (UTC)

 * Really? Look here is Word of the day for March. Majority definitions lack it! And thous that actually have it - represent them different ways of formating. Examples: dearth, superlative and so forth and so on. Plus there is no color highlighting plus it take more space. And sure, usage is not 100% mandatory, but in 99 cases out of 100 it helpful. But look around, check random articles or articles from your watchlist, most of them do not provide examples for majority of meanings. Plus in case of template actual styling choice could be easily improved/changed anytime later. TestPilot 06:12, 3 May 2008 (UTC)

 * In a community of volunteers, no-one can force anyone to do anything. I try to add example sentences to all the definitions that I write, but there are a lot of times when, for one reason or another, these sentences haven't been written. The only thing I can really think of to propose is . Though I did have an idea for using javascript to make the addition of examples easier, maybe I'll have to give it another go... In terms of formatting all the sentences should be written as described in WT:ELE - it is (should we want to) customizable using CSS - and as the format is so standardized we could get a bot to change things drastically if we wanted. The Russian Wiktionary to me (probably because I can't understand the words) looks messy and confusing, as space isn't that much of an issue I think the extra line break adds a lot of clarity. Conrad.Irwin 09:03, 3 May 2008 (UTC)

 * Personally I never bother with WOTD, because the words there are invariably too common to be interesting and too rare to be important. It would certainly be nice if the WOTDs all had example sentences. -- Visviva 14:56, 5 May 2008 (UTC)

lang= parameter in templates
Is there a reason why the "lang=" parameter of some templates requires the language name, yet for others the same parameter requires the iso code of the language? Should we standardise on one or the other?

See maiks for the completely non-obvious juxtaposition of the two forms on a single entry. Thryduulf 14:26, 5 May 2008 (UTC)

 * The difference is in the function for which the template calls the parameter. In, the lang= parameter is used to generate a topical category name, which requires the ISO code.  In the case of , the lang= parameter is used to generate a grammatical category, which reuqires the full English name of the language.  Now, some templates like  have been cleverly engineered to accept the ISO and from this generate the language name.  However, this requires extra coding that has not been put into the older templates. --EncycloPetey 17:58, 5 May 2008 (UTC)

 * Many users (even experienced) ones get tripped up between topical/grammatical categories, one using the lang code and one using the full name. (Thank you EP and others for correcting the mistakes). I would prefer helping out the user and retro-fitting all templates to accept the lang code and place the entry in the correct category (like ). Would other agree? --Bequw → ¢ • τ 18:41, 5 May 2008 (UTC)
 * How about including something like this (pseudocode) in each template? If is on this list (of two- and three-character codes), then read it as a language code; otherwise, read it as a language name. That is the user-friendliest solution imo.—msh210 ℠ 18:50, 5 May 2008 (UTC)

 * I've already proposed dual behaviour at Template talk:plural of some time ago. The only possible problem would be when there's two or three-letter language name that differs from it's ISO code, but the only two examples I can think of (Lao and Ido) don't do that. Ideally, if there are no drawbacks, this would be incorporated into itself (the template that does ISO code -> language name conversion), so that it works transparently on the templates that already use it. --Ivan Štambuk 19:23, 5 May 2008 (UTC)
 * Ewe, the language, has codes  and  ; I don't know which we use.  or  or whatever can assume that anything in lowercase matching an entry on the list of codes is a code, and anything containing uppercase or not matching an item on the list is a name. No?—msh210 ℠ 19:44, 5 May 2008 (UTC)

 * Both are valed, so algorithm would expand e.g. or  to Ewe, not to something else. Two-letter codes don't collide with language names, so all of the two-letter codes would be expanded to proper language name. Te point is to first check whether there is the template name with the passed value of lang, if not, then treat it as language name and not as ISO code. So suppose Ewe had -3 code 'abc' and someone did lang=abc, and there's another language called just that - "abc", there'll be no way to distinguish those.
 * I don't think that making some predefined list would be scalable enough, given that there are thousands of ISO codes (both ISO 639-2 and -3), the new ones are being defined every once in a while, and that still many of them are not present in the Template: namespace to be used by {infl} and others. The trick of checking the first letter for uppercase/lowercase sounds good, but wouldn't account for cases where users mistype language name in lowercase (not that there are many of those...probably none ^_^). --Ivan Štambuk 20:37, 5 May 2008 (UTC)

 * This code works, IMX: .  I think this should only be used for legacy templates where we want to keep language-name support, though; I think we're much better off using language codes across the board. -- Visviva 23:42, 5 May 2008 (UTC)

 * If this is to be implemented inside {language}, and thus have this dual behaviour being propagated to all the other templates that use {language} to generate language name out of their own's lang= parameter, it shouldn't suppose to call itself, right?--Ivan Štambuk 14:50, 6 May 2008 (UTC)

 * I think that adding this feature to would be a very bad move. If people start adding the full language name then we suddenly have two problems, firstly people could misspell the language name (not that much of a problem as it's easy to fix and quite noticeable with red categories), secondly people can easily add the wrong name for a language. For example the recent West Frisian/Frisian divide. If the name of the language has to be typed manually it is entirely possible that they'll put Frisian where we want West Frisian - I'm sure there are similar situations with other languages (like Norwegian ;). It also makes the syntax more complicated as it is more varied. The language codes are neat and easily understandable, so I would much prefer to deprecate all instances where the full language name is being passed. Conrad.Irwin 14:59, 6 May 2008 (UTC)

 * If people use misspelled/wrong/obsolete language names they would got red categories too (try using lang=Frisian now that there's no Category:Frisian language).
 * It's exactly the same thing if all the templates like {plural of} that support lang= would be extended with Visviva's above snippet (how many of them are there anyway?), or if they called newly written {language} itself and let it take care of it transparently. It's just that the latter solution is more elegant ;)
 * {plural of} is used on tens of thousands of pages, and it's support for full language name is not going away anytime soon. It should be handled one way or another.
 * More varied syntax will hopefully force a number of templates that just expand   to be rewritten to call {language} properly, and just forget about this issue altogether.
 * I do agree that full language names should be considered deprecated behaviour for lang=, for the most prominent reason of when there are multiple English names for the same language ("Slovene" vs. "Slovenian" and similar). --Ivan Štambuk 15:36, 6 May 2008 (UTC)

 * It hadn't occurred to me that this would be implemented in . I don't think that would be wise -- if name2code functionality is even workable, it should be in a separate template for reasons of maintainability, elegance, and those situations where people want to use the code2lang functionality of  specifically.  I was just thinking of this as a backwards-compatibility patch for the various older templates that still require the full language name, and which nobody feels much like going around and fixing.  -- Visviva 16:13, 6 May 2008 (UTC)

 * Ivan, I wouldn't consider full language names to be deprecated. The problem we run into is that some languages do not have an ISO code, but we do have entries for them.  This is most noticeable among the Australian Aboriginal languages.  There are some situations where a full language name is preferred, albeit in a minority of cases. --EncycloPetey 16:19, 6 May 2008 (UTC)
 * Good point; recently I poked Robert Ullmann about this issue of languages that don't have ISO codes (especially historical ones - e.g. Old Polish), and that therefore cannot be used with {infl}, {etyl}, all the templates that support lang= (including all context labels). So I guess until that is resolved we're not going anywhere towards the goal of standardising upon ISO codes..
 * But ideally, once this is resolved, lang= would always accept ISO codes and the templates themselves would decide whether to expand them into language names or not, for the purposes of categorization. --Ivan Štambuk 16:57, 6 May 2008 (UTC)
 * Where we deal in languages that have no ISO code, would it be of benefit for us to devise a non-conflicting code for our own purposes that could be easily converted to an ISO code when/if one is assigned? Perhaps something like Wplo for old Polish, as an example. Thryduulf 17:40, 6 May 2008 (UTC)

 * The ISO standards includes rules for creating internal use codes so that they'll be consistent and non-conflicting. We might want to assemble a list of languages for which no code exists, but for which Wiktionary has need of one.  Then we can figure out the codes we want to use all at once, instead of piecemeal. --EncycloPetey 19:44, 6 May 2008 (UTC)

 * +1. —Ruakh TALK 00:04, 7 May 2008 (UTC)
 * Making a central place to put this pseudo-codes sounds like a good idea. Possibly incorporating proposals from the discussion at WT:BP, to make sure that some dialects on conlangs don't get suddenly promoted more than their deserve. --Ivan Štambuk 01:27, 7 May 2008 (UTC)

 * Do the ISO standards for language codes include the notion of the "x-" prefix like a lot of other such standards? If so, we could assign our own private codes until such time as a real code becomes available. Mike Dillon 02:14, 7 May 2008 (UTC)

 * Yes, and what's more, they include the notion of a non-initial -x- to separate standard subtags from private-use subtags (so that e.g. <tt>en-US-x-Illinois-Chicago</tt> means "some privately recognized form of U.S. English"). The W3C i18n article "Language tags in HTML and XML" is a good introduction to the structure and use of modern language tags; BCP 47, currently RFC 4646, is a more official document about them. —Ruakh TALK 03:00, 7 May 2008 (UTC)

 * As a starting point I've created Languages without ISO codes initially as a place to collate the languages that need codes and then to become a reference to the codes we generate. I've added all the languages from WT:ETY/TEMP that don't have codes, but there are more than likely others that need to be added. Thryduulf 10:11, 7 May 2008 (UTC)

 * The ISO standards do not include x- or -x-; that is the IETF extensions for using tags (not codes) in HTML etc. ISO provides for codes starting with "q"; but not enough for out purposes. WMF uses codes extended from an ISO -1 or -3 code, e.g. fiu-vro. Note that we do not pass our language codes as HTML script tags, we explicitly use a set of script templates and classes. The x- or -x- convention does not apply. What we need is to add codes as WMF does, using a -1 or -3 code with an extension, e.g. for Old Polish use "pl-old" (or whatever). The WMF language committee does this, but only when they need the code for a new wikipedia, so we we need more of our own, they should then be documented somewhere where other wikts can use them if desired. Robert Ullmann 12:42, 7 May 2008 (UTC)

AEL
As an interim solution, we could redirect Template:lang:English to Template:lang:en, Template:lang:French to Template:lang:fr, and so on. Then we can switch these templates to expect language codes with no problem. (Perhaps Robert would be willing to have AF gradually replace all the language-names-as-codes with the right codes?) —Ruakh TALK 00:02, 7 May 2008 (UTC)

 * I've implemented an interim solution at which is now being used in . This allows using the language codes without breaking support for the full language names, though I think we should not add support for full language names to templates that currently only accept the codes. Conrad.Irwin 10:05, 7 May 2008 (UTC)

 * Um, I updated (which was using a massive switch ;-). Was going to to this last night. The problem with {fullLanguage} is that it creates a huge number of references to Template:English (and lang:English) and relies on that template not existing. Not too good. It also calls the language templates needed or not.

 * I set up {langname} to use the fact that all codes are lc, and all language names contain at least one uc letter; I think this is good as it doesn't "cover for" various errors. {plural of} can then use <tt> </tt> and it won't reference {language} or the en or en:lang templates in the default case. I think this is better? And we don't need to be in too much of a hurry to eradicate uses of the full name. Robert Ullmann 13:42, 7 May 2008 (UTC)

 * Earlier, I had made a list of templates that use . Could we retrofit them, like we did to ? List:, , , , , , , , , , , , , , . --Bequw → ¢ • τ 19:54, 7 May 2008 (UTC)

 * Yes, a good idea. But I would suggest letting it sit for at least a few days or so while we look at it. Then we might add rules to AF to convert lang=(recognized language) to lang=(code) ... but not force a transition, taking care for occasional editors and so on. While still continuing to allow exceptions; exception are not bad, they tell us what we may need to extend. Robert Ullmann 23:32, 7 May 2008 (UTC)

Gentium is an unacceptable Cyrillic font
Gentium is the second font choice for all Cyrillic-alphabet languages, not just Russian. Gentium should be removed, because it only supports Russian, and is lacking characters required for almost every other language.

Specifically, it appears in the font list for class="RU" in MediaWiki:Common.css, and in template:Russian fonts [sic], which is used in template:Cyrl.

Lucida Grande, the big Mac Unicode font, also installed on Windows with Safari, could also be added to these font specs, probably before Code2000 which is a serif font, and not very attractive.

And is there any reason not to move the template to an accurate name, like template:Cyrillic fonts or template:Cyrl fonts, and start transitioning the CSS class name to .Cyrl in place of .RU? —Michael Z. 2008-05-05 17:51 z

 * This illustrates why we shouldn't force any fonts on our readers. For everyone apart from IE 6 and down the browser will automatically find the closest matching font for any character. I have removed the use of from  and have removed "Gentium" from the font list for old browsers. Conrad.Irwin 15:23, 6 May 2008 (UTC)

 * Thanks.

 * I agree that it's usually best not to mess with the display in non-broken browsers, especially when we have class names assigned to allow customization. —Michael Z. 2008-05-06 17:48 z

Wiktionary Augmenting Unicode and others
Unicode, does some wonderful work. Not only do they provide code-points for all our characters, but also the Unicode Collation Algorithm (UCA) for sorting and the Common Locale Data Repository for locale info. But Unicode makes certain trade-offs in their works. When dealing with text, they favor rule-based approaches that are *mostly* correct and don't meddle too much in specific words that are exceptions. One example is their work on Text Segmentation, which lays out what code-point sequences constitute user-expected letters are (e.g. the Spanish digraph 'ch' or the Hungarian trigraph 'dzs' are single letters in those locales). Unicode takes a rule-based approach, with no dictionary of exceptions, and in ambiguous situation doesn't always get it right. In Hungarian, kö nny ű is spelled 'k'ö' ny'ny 'ű' (due to contraction on the digraphs) whereas tize nny olc is spelled 't'i'z'e' n'ny 'o'l'c'. Hyphenation, as defined by their Line Breaking Algorithm, is another area. They take this rule-based approach for several reasons, to limit the scope of their work, to make their algorithms more efficient, etc. Providing the list of exceptions is "beyond the scope" of their projects. But, it's probably not beyond the scope of our project. We at Wiktionary would seem to have a wonderful opportunity to help provide a more complete solution, by creating and maintaining banks of exceptions to the algorithms that Unicode (and possibly others) provide. Two projects that spring to mind are:

1) To provide explicit spellings for words that Unicode's algorithm parse incorrectly.

2) To provide hyphenation information for words. We already do this to some extent. Unicode doesn't define very much how to hyphenate inside a word, so we could outline language specific algorithms and word-specific exceptions. (TeX's hyphenation algorithm is a good one starting point for English.) This appears infeasible. TeX's algorithm doesn't use pre-existing rules, it derives thousands of "patterns" from an existing hyphenation dictionary, just to save space. --Bequw → ¢ • τ 19:30, 7 May 2008 (UTC)

I'm sure that are other ways we can augment the information about languages that Unicode and others provide. Eventually we could provide ways to extract this information from Wiktionary to help text-processing systems that can spare a bit of RAM/CPU to consult a dictionary. Any other ideas, or has this been discussed before and I'm late to the party? --Bequw → ¢ • τ 20:21, 5 May 2008 (UTC)

 * This is an interesting idea, we could perhaps have something like - though I'm not sure which section this would be best to put it in, though that doesn't really matter. It should probably be as a Note of some kind near the bottom. We already seem to have  - so feel free to use it - though perhaps a region parameter should be added for I am aware that US and UK hyphenate same things differently  vs. . If we wanted to have an Appendix:English hyphenation or any other language for that matter, I'm sure we could - though I don't know who could write it. Conrad.Irwin 18:44, 6 May 2008 (UTC)

 * I've made . The name isn't great as the information could be used for other purposes besides collating, but a name like {spelled as} seems unclear. For now I've put it in the ===Usage Notes=== section. See dzsungel for an example. --Bequw → ¢ • τ 19:30, 7 May 2008 (UTC)

 * Does this have to be visible to the user? I accidentally deleted your template from tizennyolc because I did not realize what it was for and I was working on standardizing Hungarian numbers. Your idea could be tested with the code Conrad used a while ago to build the Hungarian index. --Panda10 12:30, 8 May 2008 (UTC)

 * See the newly formed Project - Text Processing Information (and please help). --Bequw → ¢ • τ 05:26, 29 May 2008 (UTC)

Parenthesis and preferences
Either something was broken recently, or someone that loves parenthesis is pushing them again. I have "hide maximal [sic] parenthesis" checked (and others) but usually they appear for qualifiers. What gives? --Connel MacKenzie 08:11, 6 May 2008 (UTC)

 * WT:PREF was reset recently, presumably by accident. -- Visviva 09:15, 6 May 2008 (UTC)

Piped link behaviour
Is it just me, or when I type in Appendix:Invented phobias it expands it to Invented phobias during the save process? Conrad.Irwin 16:36, 8 May 2008 (UTC)

(test: hinder )

 * Yes, it is during the save process (like subst and ~ . It removes the first xxx: string, and anything in parens at the end. They call it the "pipe trick". meta:Help:Piped link Robert Ullmann 17:36, 8 May 2008 (UTC)

 * I thought that previously the wikitext was left unaltered -maybe I just never paid enough attention before. Conrad.Irwin 17:42, 8 May 2008 (UTC)

Brackets in parameters
Putting brackets in and  produces odd results; see novias and novios. These are templates that should be compatible with brackets in the parameter, since they may be the only definition line text. Can someone fix them up? Dmcdevit·t 07:35, 14 May 2008 (UTC)

 * Fixed. (I don't understand what those entries are trying to say — either novios: and novias: are the plurals of novio: and novia:, respectively, or they're the masculine and feminine plurals, respectively, of novio:, and I don't think it works to split the difference this way — but either way I agree that argument-bracketability is a requirement for these templates.) —Ruakh TALK 23:53, 14 May 2008 (UTC)

Foreign terms
I've made an initial proposal to add a parameter to all inflection templates,, which identifies foreign terms that are usually italicized, italicizes the term, and adds a category. Please review and comment at WT:BP. —Michael Z. 2008-05-14 19:34 z
 * I understand, based on the BP discussion, that this parameter would be added to English-language inflection templates, not those of other languages. It could also be added to form-of templates, if the BP discussion so decides.—msh210 ℠ 19:42, 14 May 2008 (UTC)

 * I'm just thinking about whether that is possible. It may be useful to identify and categorize foreign terms in every language, and might even be doable, but the convention of italicizing should probably only be used in English words. —Michael Z. 2008-05-14 20:01 z

 * I think we should use the convention of the language that is using the foreign term, e.g. for an English term used in French we should follow the French convention, etc. Thryduulf 20:10, 14 May 2008 (UTC)

 * There may be some issues.
 * It will be a long time until we can establish what these conventions are for the 100+ languages represented. Some may not have such a convention.  In the meantime, we should either have a neutral convention to represent this for every occurrence (like a context tag or a symbol), or simply make use of the category and not indicate this in the entry.
 * I'm hesistant to inject foreign editorial conventions into en.Wiktionary. This is an English-language document which refers to many foreign terms, but not a multilingual document.  It may be okay to observe normal foreign orthography even if it's not understood by English-language readers, as long as it doesn't add confusing, contrasting, or clashing conventions.
 * I think it would have to be considered case-by-case, for these reasons.
 * Do you know what the convention is for French or any other language? Perhaps we could use italics in other languages which do so, although many scripts simply don't have italics.  I'd prefer not to  add e.g., a mix of «guillemets», « spaced guillemets », and small caps to various headwords. —Michael Z. 2008-05-14 20:50 z

Regional language vs regional topics
I'm proposing a clear definition of the distinction between regional English language, and regional topics. This would slightly change the way regional context templates are used, and clearly separate language categories such as Canadian English from regional topics such as Canada. Please review and comment at WT:BP. —Michael Z. 2008-05-14 19:39 z

Template:lister
Created this template. Purpose: Meta-template to support consistent, default-hidden, bulleted lists of the words in a small semantic set. Example:. Please use, modify, improve, ignore, or delete, as appropriate. -- Visviva 05:47, 17 May 2008 (UTC)

Template:given name
Having wanted to use this without having to use its very odd syntax (at Barack) I have fixed it:

 * Language is lang=(code) as with other templates. It used to have 3rd parameter "lc:", with the ":" included.
 * Origin is from=(language). It used to be 2nd parameter, with "from" included: <tt> ...|from Greek|... </tt>
 * Documented or= and gender= which were already there.
 * Corrected documentation that said extra |'s were required at the end, which of course they are not.

The old forms still work, as I haven't updated any pages at all. This would be a good bot run is we can ever get a new XML dump. Robert Ullmann 14:48, 17 May 2008 (UTC)

 * There seems to be something (minor) wrong with it; Barack has a stray space. —Ruakh TALK 16:45, 17 May 2008 (UTC)

 * Just so: a stray space before the noinclude tag. (And thanks to Stephen for the Arabic forms ;-) Robert Ullmann 23:10, 17 May 2008 (UTC) (Ullmann kicks himself, having known perfectly well where Mubarak comes from, but not once making the connection!) Robert Ullmann 23:13, 17 May 2008 (UTC)

I've added a couple of rules to AF to change parameters. (with one very bad false start, see history for Agnes if you like; I'll blame it on being 3AM). Please do comment. No hurry. Robert Ullmann 01:10, 18 May 2008 (UTC)

Statistics
Statistics is now over two months old. Does anyone other than Connel know how to update it? SemperBlotto 21:44, 17 May 2008 (UTC)

 * WE NEED a new XML dump! (*sigh* will try to ask if Brion can fix it will let someone fix it or we will create a dyn mirror or something else that is atrocious because—Ullmann fails at creating an half-way impressive run-on sentence) Robert Ullmann 23:07, 17 May 2008 (UTC)

 * You might ask Connel if he's taken action already on this. I had noted this problem to Connel directly a few weeks ago, and he cited the problem with the XML dump.  It is possible he has set something in motion in the meantime. --EncycloPetey 02:06, 18 May 2008 (UTC)
 * Now updated by Connel. SemperBlotto 21:21, 22 May 2008 (UTC)

Slow WT response times?
Is it just me or has anyone else been experiencing painfully slow response times working with Wiktionary over the last day or so? If it's not just me, does anyone know what's going on? -- WikiPedant 19:23, 22 May 2008 (UTC)

 * Not too bad for me, East Coast US. XML dumps? DCDuring TALK 19:30, 22 May 2008 (UTC)

 * Its much slower than Wikipedia t open pages for edit - I work mainly in Microsoft ^Internet^ Explorer, via DSL. Each time I hit the "edit" button it takes about 40-60 seconds to pull up the page. I notice it is 2-3 times faster if I go to the library so maybe my configuration. Can someone technical can give advice, such as recommended browser, and Windows configurations? Goldenrowley 01:37, 27 May 2008 (UTC)

 * I used to use IE7. Had problems, including freezing when trying to refresh. I switched to Firefox and get better overall performance by a bit and no freezing on refresh. We really need for Wiktionary to work better for IE so we can not discourage potential recruits. DCDuring TALK 01:43, 27 May 2008 (UTC)
 * Thanks for the tip... I will try switching to Firefox! Goldenrowley 02:01, 27 May 2008 (UTC) OMG that makes such a HUGE difference in speed I have already done three edits, and its like 10 times faster!! .... you would think the browser would not be so important.Goldenrowley 02:14, 27 May 2008 (UTC)

 * Whatever was going on when I made the original posting in this section has cleared up. My response times are back to normal (at least normal for Wiktionary).  I too use Firefox 98% of the time.  For me, Firefox doesn't seem any faster than IE, but it is reputed to be much less vulnerable to spyware, adware, and assorted malware.  In general, Wiktionary is known to be slower than many other sites on the web (apparently, resource problems on the WT mothership).  Goldenrowley, your library computers are likely faster simply because, like the networks at many institutions, they are plugged into bigger bandwith commercial lines than we normal folks can get at home with DSL (the computers at my university workplace are also much faster on the web than my DSL-connected home computer). -- WikiPedant 02:37, 27 May 2008 (UTC)

"in other languages" links
"Anglo Saxon" should be hyphenated in the "in other languages" links in the left margin. Any idea how to fix this? — Paul G 09:45, 23 May 2008 (UTC)
 * Why should it say "Anglo-Saxon" at all? That's neither the native name of the language nor the standard modern term for it (which is "Old English"). --EncycloPetey 17:31, 23 May 2008 (UTC)
 * At any rate, that isn't something Wiktionary-specific. Those language names are uniform across all Wikimedia projects. I think you'd have to file a bug report on Bugzilla to get a developer to change it. Angr 13:33, 25 May 2008 (UTC)
 * Thanks for that. I reported it and it's now been fixed. — Paul G 08:52, 28 May 2008 (UTC)

Project links templates broken?
For some reason, generates: instead of The same is true of I assume this is something to do with the prefix being a sister-project interwiki link. Is this intentional to stop people using them in deference to or do we actually need to fix this before further software changes break it worse? Conrad.Irwin 10:05, 23 May 2008 (UTC)

 * I'm guessing neither: it probably wasn't intentional (since, who cares if you use instead of  or ?), but it probably isn't a problem, either (since, who cares if you can't use  instead of  or ?) —Ruakh TALK 12:19, 23 May 2008 (UTC)

 * It's treated as a cross-wiki transclusion by MediaWiki. There is a flag to control whether that functionality works and it's turned off for WMF wikis. Mike Dillon 14:31, 23 May 2008 (UTC)

 * Cross-wiki transclusion... wow... how do we get that turned on? -- Visviva 13:02, 25 May 2008 (UTC)

 * Well, we'd have to convince someone to turn on $wgEnableScaryTranscluding and and go set  on the interwikis we wanted it to work for. I expect that would be a hard case to win :) Mike Dillon 20:44, 25 May 2008 (UTC)

The PL: templates are all subtemplates; they should not be used directly on a page. Either use or use  and so on. It wasn't intentional, but there was no intent that the PL: templates be anything other than subtemplates shared between projectlink/projectlinks/pedialite/sourcelite, etc etc. Robert Ullmann 23:50, 25 May 2008 (UTC)

Templates overwriting each other
On the mudra page to templates presently in the top right corner of the page overwrite each other. I attempted to fix this by using the code from w:Template:Clear to no avail. __meco 09:50, 25 May 2008 (UTC)

 * seems to be misbehaving; when moved down below the TOC it overwrote the definition text.  I adopted a low-tech solution; feel free to revert. -- Visviva 13:01, 25 May 2008 (UTC)

 * should always be inside the language section it structurally refers to (i.e. the English section for the default). The horrible "cosmetic fix" of putting it above the English header if there were enough sections to cause a TOC was because no-one treated the wandering [edit] links as a bug, and got them fixed.

 * Stack whatever templates/images for a language immediately after the language header, and it will render fine. When you find an entry that was corrupted by someone trying to "fix" it, just put it back the way it should be, in the section it belongs to. Robert Ullmann 00:06, 26 May 2008 (UTC)

 * In Firefox 2.0.0.14, with right-floating TOC, the pediabox is still partially overwriting definition text. This does not occur in Opera.  This is the same behavior I mentioned in the TOC discussion earlier; I'm clueless as to the cause. (maybe just an FF bug?) -- Visviva 02:13, 26 May 2008 (UTC)

 * Right-floating TOC will break lots of things; if you want to use it for yourself okay, but you'll have to put up with it. Robert Ullmann 21:46, 27 May 2008 (UTC)

 * Actually this is the only problem I've seen so far. I wouldn't switch back for the world... but still don't understand why the pediabox is behaving this way. -- Visviva 00:16, 28 May 2008 (UTC)

 * I'm not sure what you're saying. :-/  If you're suggesting that right-floating elements (using , or — in the case of the TOC — copying the   CSS) don't interact properly with the beginning of a language section, then surely that's something that needs to be fixed? Even if everything is structurally in the right language section, sometimes it will extend for some users into the beginning of the next one. —Ruakh TALK 01:49, 28 May 2008 (UTC)

 * I suppose mudra was not a good example, but IMO most entries that have should have, because they are about words that do not map neatly onto a single concept.  "Mudra" is a bad example of this because although it has two senses, these are both covered in the linked article. Where a word refers only to a specific encyclopedic concept, it may make sense to give prominent billing to WP, just as WP gives prominent billing to Wiktionary on entries that are about specific words as such.  But in most cases the link should be relegated to "See also," just as the corresponding link would be on the pedia.   -- Visviva 02:13, 26 May 2008 (UTC)

:
I've been around on Wiktionary for a long time, but I've never worked out what the links : (for example, normal on the page for normal) are for. I'm guessing they are place-holders for missing entries in the specified language on that page - is this right? (The power of posting... it had not occurred to me that this is what they might be for until I started writing this question.) — Paul G 08:19, 31 May 2008 (UTC)

 * Those are the interwiki links, allowing users to see the same entry in other language wiktionaries. -Atelaes λάλει ἐμοί 08:26, 31 May 2008 (UTC)

 * That is the code that creates the interwiki links that appear on the left-hand side of the entry page. --EncycloPetey 20:10, 31 May 2008 (UTC)

 * Oh, I see. Thanks for that. — Paul G 09:22, 3 June 2008 (UTC)

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Wiktionary:Grease pit/2008/May