text:
Wiktionary:Grease pit/2009/June

=June 2009=

Numbering problem caused by Template:quote-book and Template:quote-news
These templates are screwing around with the numbering in our entries - see the [[charcoal]] page, and the numbering goes 1, 2, 1, 2. --Jackofclubs 06:25, 6 June 2009 (UTC)

 * I reverted a change made June 5 in template:cite meta that seemed to have been the problem and notified the contributor. I hope that is all that is required. DCDuring TALK 09:37, 6 June 2009 (UTC)

Hyperlink has changed
I was wondering if anyone would be willing to help out on what should be a rather simple find/replace procedure. I have cited an online Chinese-English Dictionary in hundreds of Wiktionary entries. I provided the hyperlink in the template as well. Unfortunately, the hyperlink has changed. Instead of http://www.dreye.com/index_en.html, it should simply be http://www.dreye.com/ (see: 豁達 for example). Is there an easy way for someone to check the references section for all Mandarin entries that cite Dr. eye, and remove /index_en.html from the URL? Thanks. -- A-cai 14:34, 6 June 2009 (UTC)

 * User:Opiaterein has a bot called Inflectobot who can do that. Ask him. --Vahagn Petrosyan 15:59, 6 June 2009 (UTC)

This was redirected to, with the result that all Dutch verbs now have an entire conjugation table as an inflection line. Could this be fixed please? Nadando 18:33, 7 June 2009 (UTC)

 * The problem is that plenty of Dutch verbs are currently using as their actual conjugation table (like, in a ====Conjugation==== section). This will require some sort of sorting-out, probably by a bot … 19:08, 7 June 2009 (UTC)

 * I'll take a look at this (and put Inflecto to work) when I have some extra time. Should be fun — [ R·I·C ] opiaterein — 21:27, 8 June 2009 (UTC)

Is there a compelling reason for this to be in a floating box? If not, would someone with template knowledge convert to be like other inflection line templates? Nadando 03:44, 10 June 2009 (UTC)

Unexpected response from wiki server
While running FitBot the past few days, I've gotten numerous messages of "Pausing 5 seconds due to database server lag". sometimes I get this every 5 seconds for a full six minutes before the page can be created. Today, the problem has been especially bad, and several times I've gotten "Unexpected response from wiki server" with the following text dumped on my screen:

 * 17K message excised since problem seems fixed. Message can be seen in this older version of the page.

Why is this being dumped at my bot? Please, can someone stop it from happening? When this happens, I have to figure out which page(s) wasn't created and do it manually. --EncycloPetey 05:52, 11 June 2009 (UTC)

 * Note: This information posted here, in part for discussion on #wikimedia-tech, where a "conflicting read lock" because of srv76 was noted as the problem. --EncycloPetey 06:12, 11 June 2009 (UTC)

Special:PrefixIndex
The above page generates misleading text. Indeed, even its name is misleading. It is used for lists of terms that begin with a set of characters that need not be a prefix. Can this conveniently be changed to something more accurate? Does this need BP discusssion? DCDuring TALK 13:56, 12 June 2009 (UTC)

 * This would be "prefix" in the computing sense, not the linguistic one. We can change the text fairly easily, by creating MediaWiki:prefixindex (default: "All pages with prefix"), MediaWiki:prefixindex-summary (default: ""), and/or MediaWiki:allpagesprefix (default: "Display pages with prefix:"). Changing the name would be more difficult; it's internationalizable (e.g. on French projects it's called "Spécial:Index"), but I believe that's basically baked into the code.
 * We shouldn't really be sending readers to Special:PrefixIndex, since it's not part of our content per se. It's useful for editors, and sometimes as a kludge we might point readers there, but if we're worried that it might confuse readers, then the problem is that readers are seeing it, and the solution is to remove the need for readers to see it.
 * —Ruakh TALK 14:15, 12 June 2009 (UTC)

 * Then we should kill the template that uses it: . Though I haven't used it, I thought it affords some advantages: It allows parts of our derived terms list to be constructed on the fly so that it is not out of date and the content does not have to be down-loaded as often. Would it be possible to get the same advantages some other way? DCDuring TALK 16:04, 12 June 2009 (UTC)

 * I don't know. —Ruakh TALK 18:29, 29 June 2009 (UTC)

Hebrew: Old and New
Hello. Could someone who knows how please change our use of the ISO 639-3 codes heb and hbo to read Modern Hebrew and Classical Hebrew, respectively? At present, they and he (Hebrew’s ISO 639-1 code) all yield Hebrew. It would be useful for the display to be as follows: Ideally and intuitively, there would also be the autocategories Category:Hebrew derivations (which we have) for Hebrew, Category:Modern Hebrew derivations for Modern Hebrew, and Category:Classical Hebrew derivations for Classical Hebrew. My thanks to whomever. †  ﴾(u):Raifʻhār (t):Doremítzwr﴿ 13:21, 15 June 2009 (UTC)
 * 1)  → Hebrew
 * 2)  → Modern Hebrew
 * 3)  → Classical Hebrew
 * I think the consensus has been to treat it as one language for purposes at least: I'm not sure about for  purposes.    —msh210  ℠  16:40, 15 June 2009 (UTC)

 * Why a link with the face "Classical Hebrew" and the target "Biblical Hebrew"? Just a thought. (On the same token, we seem to have favored Old Armenian over Classical Armenian, Ancient Greek over...whatever else. etc.) — [ R·I·C ] opiaterein — 18:55, 15 June 2009 (UTC)

 * The ISO templates are designed to match language section headers. So, unless you are proposing to dismantle Hebrew entries into different periods (which would be a massive policy change), the templates should stay as they are.  You could, as an alternative solution, use Webster-style templates as we do for Latin.  All Latin entries are treated under a uniform "Latin" language header, but for etymologies we use templates like  or  to specify temporal periods of the language. --EncycloPetey 19:08, 17 June 2009 (UTC)

 * That approach is obsolete, as of February, when Bequw edited to add support for <tt></tt>. We should replace  and  with, say,  and  (though I'd welcome your thoughts on the naming). Similarly, we could create  and  to support what Doremítzwr describes. (Note the <tt>he-IL</tt> rather than <tt>heb</tt>; <tt>he</tt> and <tt>heb</tt> are supposed to be synonymous, and even if we don't use them exactly the way they're supposed to be used, I don't think we should try to distinguish them.) This isn't going to be perfect — English and Classical Hebrew never existed at the same time, so words that entered English from Classical Hebrew either came via European languages, or were influenced by Medieval Hebrew (in the form of the Masoretic vocalization) — but it should at least help distinguish words like sabra: and kibbutz: from words like seraph: and behemoth:. —Ruakh TALK 20:52, 17 June 2009 (UTC)

Template:langcatboiler
Currently, you can only use 38 of the 58 possible country parameters because this Template exceeds the MediaWiki template limits. Is there any way to fix this problem? There are some languages spoken in more than 38 countries, including but not limited to English. -- Prince Kassad 19:39, 15 June 2009 (UTC)
 * This doesn't answer your question, but a hack is of course to catgeorize manually. (That's all adding those parameters does, anyway.)   —msh210  ℠  20:09, 15 June 2009 (UTC)
 * To me, the sort key appended to all country categories seems rather useless since it does not change the sort order at all, but I don't know much about templates. -- Prince Kassad 20:22, 15 June 2009 (UTC)
 * You can use up to sixty country parameters now, and the sort keys were removed. Of course, the manual categorization is working as well. It's up to you choose manual categorization or the . However, I'd prefer the latter for consistency, because as they're both accepted, I'm doing my best to add this template to all language categories, then check all the parameters for countries, language families and interwikis. --Daniel. 21:38, 15 June 2009 (UTC)

Category:English verbs which are their own past participle
Can't this be populated automatically by ? Add something like  perhaps?  —msh210  ℠  20:12, 16 June 2009 (UTC)

 * Probably, but is the added strain to the server worthwhile? It must be a very, very limited set of English verbs that have this property.  Adding an extra if check to every English verb entry on Wiktionary seems to more than counterbalance a desire to save on adding the category.  It also wouldn't catch the verbs like burst: that optionally have the same past participle and have had explicit multiple forms added. --EncycloPetey 20:23, 16 June 2009 (UTC)
 * For one point of view, see w:wp:don't worry about performance.   —msh210  ℠  21:58, 16 June 2009 (UTC)
 * Wikipedia makes far less use of these sorts of templates, and so seldom has to consider them. In cases like this, the effects have been measurable and considered before on Wiktionary.  And there is still the second point I raised, which would not be solved by a template change.  Further, any addiitonal variant forms of past participles added in a verb's template would de-catagorize it under the proposal.  I think tracking down the verbs and categorizing them by hand (or by a bot given the list) is a smarter move. --EncycloPetey 22:08, 16 June 2009 (UTC)
 * Okay, fair enough. I suppose a bot could even track them down. (It shouldn't be too hard to find even those that list more than one past participle, I imagine.)   —msh210  ℠  22:39, 16 June 2009 (UTC)

Along the same lines, is there any reason with language not set (or set to English) should not categorize in Category:English homophones? (Here, there's no big waste of server use, since the #if will be true and executed in the vast majority of cases that the template is used, so, while it'll be server use, it won't be waste of server use.) Something like, perhaps? (I'd recommend this for all languages, but English is the only one with a category at this time.)   —msh210  ℠  22:47, 16 June 2009 (UTC)

Wiktionary:Votes/pl-2009-06/Add en: prefix to topical categories
Sort of realised that 24 hours later nobody has commented on this - perhaps I posted it to the wrong place? Anyway, please add your two cents if you feel like it. Mglovesfun 18:57, 17 June 2009 (UTC)
 * You didn't get comment because the vote page isn't properly formatted, nor was it ever added to the WT:VOTE page. See the instructions at the top of that page to see how to initiate a vote. --EncycloPetey 19:03, 17 June 2009 (UTC)

Assisted translation entries with commas
Every day somebody adds two or more words, separated by commas, using the excellent assisted translation system. Of course, it produces a single, red-linked entry instead of the multiple separate entries intended. Could the system be modified to either produce the multiple entries, or to give a warning message? SemperBlotto 11:39, 18 June 2009 (UTC)
 * If you you should see the new version that will produce one of two error messages (by default everyone will see "You can only add one translation at a time. If this is one translation that contains a comma, you can add it by clicking here." and nothing will happen. However if they have previously clicked on that message they will see "Please click undo if you were trying to create a list of translations in one go, this is currently not supported." and the translation with a comma will be added. When they click on the second message, the system will default back to the first behaviour). Conrad.Irwin 02:38, 19 June 2009 (UTC)

MediaWiki talk:Edittools
This page is now over 26K, which is too large. The entire thing has to download each time you open an edit window, and there are some machines I use where I may have to wait 20 seconds for the edit window to open now. How can we shrink the size of this overgrown monster? Ruakh seems to have done some work, but can we do more? --EncycloPetey 15:05, 18 June 2009 (UTC)
 * I think the next step would be removing unneeded letters. For example, the plain Latin letters (A, B...) in the Yoruba section are not needed as they're on everyone's keyboard. -- Prince Kassad 15:13, 18 June 2009 (UTC)

 * I've just now finished my changes; all told, I've brought the edit-tools down from 172KB to 27KB, without actually changing anything. 27KB is still a lot — it's more than half the page, bit-wise — but it should reduce your wait-time by a factor of roughly 4. Next up, we should consider changes that do actually change things:
 * removing the plain Latin letters that Prince Kassad mentions.
 * removing, or at least merging, the duplicate Latin/Roman sections. I understand that it's a pain to use the huge "Latin/Roman" section for languages with just a few diacritics, but then, it's also a pain to navigate a huge list of identical languages.
 * removing "heavy" sections, such as sign languages, and creating a way for interested editors to re-add them as a customization.
 * removing little-used sections. I don't know which these are, but we can probably get statistics on which languages aren't really active. (I think Visviva can help with this.)
 * removing some of the excessive explanations, both in-line and in tooltips (hover-text). Does every single edit-page on the site the "approximately equals" tooltip?
 * —Ruakh TALK 16:25, 18 June 2009 (UTC)

 * The correct solution to this is to use javascript (I think w:User:Mike_Dillon has some already written, or we can write our own). That way the size does not matter, it will only be downloaded once per month, the first time a user edits the page, it also means we can plug it into other places (like translations and search). The one downside would be that all edittools would need rewriting (including all the customised ones). I'm not sure how much time I have at the moment, but this is third on my "tofix" list after the bug-reports to editor.js and the indexing on my talk page (though obviously if someone else does it before I get round to it, that suits me best :p) Conrad.Irwin 00:02, 19 June 2009 (UTC)

 * Well, we already are using JavaScript. Heavily. I assume you mean we should move the actual characters into an external JavaScript page? If so, I agree, but there are some things to keep in mind:
 * We're down to 27KB for now. As I said above, that's a lot — it (slightly) more than doubles the section-edit page I'm currently editing — but even on low-end dialup connections, we're talking less than 1.5 seconds of download time. All told, it's small enough that I think it's worth examining the advantages and disadvantages of external JavaScript.
 * A too-big edit-tools has other problems besides just download time. There are also technical issues (the eating up of browser resources — not a big deal if you're editing from a modern PC, but potentially an issue for users editing from older computers, from phones, etc.) and usability issues (the list of languages/scripts is pretty long to scroll through, and within some of the scripts there are just so many characters). This is potentially an argument for external JavaScript, done right — done in a way that only presents the languages/scripts that a user wants to see — but it's definitely an argument against external JavaScript, done wrong — done in a simplistic way that just preserves the current problems, but also adds a big neon sign telling admins that it's now O.K. to add lots of bloat.
 * Currently, the edit-tools degrade somewhat usefully for an editor with JavaScript disabled. (My recent changes were actually an improvement in this regard: instead of non-functional links, they get plain text that's easy to copy and paste out of.) I'm loath to completely remove that.
 * The more we externalize, the harder/slower it is to make changes, because of the way external JavaScript-s are cached. However, we can mitigate this by storing version/revision information in the edit-tools proper, so that whenever there's a change that needs to propagated immediately for whatever reason, we can do so.
 * All told, I don't think someone should just "[do] it before [you] get round to it" — details need to be hammered out, preferably with input from BP-izens.
 * —Ruakh TALK 15:28, 19 June 2009 (UTC)

 * I am not sure there is a connection, but I have twice today had the same problem. Selecting the alt spellings template from edittools led to the non-recognition of the template on saving. I would guess that there was a look-alike character in there. This is the problem version cut and pasted: "alternative spelling of". Cutting and pasting from the template headword or typing generated the expected response. DCDuring TALK 18:05, 19 June 2009 (UTC)
 * Does this happen each time you use the Edittools for that template, or just intermittently? It worked just fine for me a moment ago. --EncycloPetey 18:26, 19 June 2009 (UTC)

 * Thanks for letting me know. The code that changes non-breaking spaces to spaces must not be working properly in all browsers; for now, I've switched the headers and the templates back to <charinsert> (bringing the size back up to 30 KB). I thought I'd tested that, but I must have missed something. I'll look into it. Thanks again! —Ruakh TALK 18:44, 19 June 2009 (UTC)

 * FWIW, I use FF 3.0.11. OK just now. DCDuring TALK 19:20, 19 June 2009 (UTC)

 * OK, I've now fixed the underlying issue. However, since it was in MediaWiki:Monobook.js, which gets cached, we'll have to wait a month before restoring the <span class="charinsert">'s for those. (Not a big deal; it's just two of the sections. We're still at 30 KB, which isn't as good as 27 KB, but is loads better than the 172 KB we started off at.) Thanks again for letting me know! —Ruakh TALK 19:27, 19 June 2009 (UTC)

 * From what I can see, the French and Spanish sections add nothing that isn't already in the Latin/Roman section, apart from the upside down exclamation and question marks. Mglovesfun (talk) 17:46, 4 July 2009 (UTC)

Search box
We have just deleted a term an old hand at, which seemed appropriate. I had assumed that a search for "an old hand at" or "old hand at" would find [[old hand]], especially because the term appeared in Derived terms and in a usage example. It didn't put it on the first page anyway (I didn't search all 2000+ pages offered). When I quoted the term it didn't find it at all.

[[old hand]] has been in the system in its current for for a little more than two years, so an indexing delay doesn't seem like an acceptable excuse. Is there something about the entry that makes search ineffective? If search is normally so ineffective, what adjustments, crutches, or kludges can help overcome its shortcomings? DCDuring TALK 16:03, 18 June 2009 (UTC)

 * From poking around, I get the impression that the search is getting thrown off by the <tt> ''' </tt>-s. If that is indeed the case, I don't have a suggestion how to improve matters. —Ruakh TALK 17:02, 18 June 2009 (UTC)

 * But it also didn't find the redlinked an old hand at (now deleted) in [[old hand]], though it did find it on other pages. The exact way this works and its potential for remediation should effect how he propose to handle some common collocations that don't meet WT:CFI. Should we put in many more redirects, omit bolding of headwords in usage examples (amend WT:ELE, or amend WT:CFI (heaven help us!) to allow more collocations that are no so idiomatic so that users have a chance of finding the true idioms. DCDuring TALK 00:23, 19 June 2009 (UTC)

 * It seems to be working now. I'm not sure what changed; maybe they improved the search functionality? Regardless, [[old hand]] is now the first hit for "an old hand at" (with or without quotation marks, with or without the "an"). —Ruakh TALK 18:43, 14 July 2009 (UTC)

 * Indeed. You had replicated the earlier problem, right? Or could I have been wrong about it? I hate to be a leading exemplar of the wisdom of fallibilism. DCDuring TALK 19:09, 14 July 2009 (UTC)

 * Yes, I had. —Ruakh TALK 19:33, 14 July 2009 (UTC)
 * That's a relief. DCDuring TALK 19:35, 14 July 2009 (UTC)

Talk:فروردین
There seem to be subtle differences in the farsi/arabic script that I cannot detect but that lead to the creation of pages that the wiki system considers different. Can someone help me understand waht is going on and advide how to avoid this kind of problems? All I have to write this script is the Windows character map. Jcwf 23:39, 24 June 2009 (UTC)

 * In the header of this section, you link to the talk-page for فروردین, with the second-to-last letter being U+06CC ARABIC LETTER FARSI YEH. In that talk-page, you link in turn to the talk-page for فروردين, with the second-to-last letter being U+064A ARABIC LETTER YEH. These two letters seem to be indistinguishable, or nearly so, in the middle of a word, but at the end of a word the former lacks the two dots of the latter, as you can see by inserting a space after each: فروردی ن vs. فروردي ن. (The exact details might depend on your fonts: I'm not sure how well the various fonts reflect the different forms of Arabic letters at their various positions in a word. Since I can't read the script, I've never had occasion to worry about it.)
 * If you have JavaScript enabled, I recommend using the edit-tools instead of Character Map. Right below the "Save page" button, you should see a drop-down menu; if you choose "Arabic", you'll get a list of links to insert Arabic letters into the edit-box. The Persian-specific letters are well indicated.
 * —Ruakh TALK 02:54, 25 June 2009 (UTC)

 * Right. Until Unicode, there was no difference in initial or medial Arabic and Persian yeh. Arabic also has an undotted yaa’ called alif maqsura, and this was always the letter that Persian used for final and isolated yeh. In Unicode, it was decided to differeniate, and now Arabic has ي and ى, while Persian has only ی, different from either Arabic letter. It’s not unusual for a Persian to use an Arabic keyboard and therefore use the Arabic yehs, so both spellings are found. —Stephen 05:04, 25 June 2009 (UTC)

 * Thank you very much for the explanation. I might add that for some of the months of the Persian calender pronunciation files do exist but their name at commons contain the Arabic yeh.

Jcwf 13:47, 25 June 2009 (UTC)

Shortcut to Wiktionary:About Serbo-Croatian
Shouldn't the shortcut to About Serbo-Croatian be WT:ASH? --Daniel. 08:27, 25 June 2009 (UTC)
 * Right, corrected. --Ivan Štambuk 12:38, 25 June 2009 (UTC)

Problems with section-linking when using {temp}
I include this subtitle to allow functioning section-linking to this discussion. My initial post should exemplify this problem.

Problems with section-linking when using Template:temp
When is used in section-header fields, the → links produced for section-linking which appear in one’s watchlist (well, in mine, at least) do not take one to the desired section, but rather only to the top of the page (which is a pain for the main fora WT:ID, WT:TR, WT:BP, WT:GP, WT:RFV, WT:RFD, WT:RFC, &c., which are all large pages and require a lot of scrolling otherwise). I noticed that the same problem was caused by other code in the past, but that this functionality problem has since been rectified. Is there any hope that the same can be done for ? I presently eschew its use in headers (except in this case, where I use it to exemplify the problem), but it is used by others (e.g., by Michael Z. in the Beer Parlour sections >  and  > : ). †  ﴾(u):Raifʻhār (t):Doremítzwr﴿ 12:16, 25 June 2009 (UTC)

 * Seems to be fixed when you . Conrad.Irwin 20:51, 25 June 2009 (UTC)

 * Great! Thanks for fixing this persistent problem so quickly. †  ﴾(u):Raifʻhār (t):Doremítzwr﴿ 21:30, 25 June 2009 (UTC)

 * Thanks! That's always driven me crazy. BTW, when viewing a diff, the section-link in the edit summary is similarly nonfunctional. That's a bit harder to fix — you'd have to isolate the link and alter its href — but if you're in a fixitive mood, it would be appreciated. :-)  —Ruakh TALK 01:26, 26 June 2009 (UTC)

 * Oh, actually, it’s not yet working perfectly. ATM, section linking is sending me, conversely, to the bottom of the page now. That’s not much of a problem for this discussion or for new discussions, and is an improvement on the old problem, but it still isn’t ideal. Any idea why it’s switched to this new behaviour? †  ﴾(u):Raifʻhār (t):Doremítzwr﴿ 09:26, 26 June 2009 (UTC)

 * Another possibility might be to add something like addOnloadHook(function  {
  if(wgAction != 'edit')
    return;
  if(! /[?&]section=\d/.test(window.location.href))
    return;
  var wpSummary = document.getElementById('wpSummary');
  if(! wpSummary)
    return;
  if(! /^\/\*.*?\/\* $/.test(wpSummary.value))
    return;
  wpSummary.value = wpSummary.value.replace(/\{\{temp(late)?\|/g, '{{');
});  What this does is, if the user is currently editing a numbered section, and the edit-summary looks "fresh" — we don't want to mess with an edit-summary the user has already touched — then it finds all instance of <tt>{{temp|</tt> or <tt>{{template|</tt> in the edit summary, and changes them to plain <tt>{{</tt>. This won't work when the user is creating a new section (and can't be made to work in that case, because the same field serves both as the edit-summary and as the new section header), and it won't work for pre-existing edit summaries; but then, it doesn't have to replace Conrad's code. The two aren't mutually exclusive.  I'll wait a day or so, and if no one objects, I'll make the change.  —Ruakh TALK 01:27, 29 June 2009 (UTC)

 * Done. (I ended adding slightly different code from what I listed here, but the functionality is the same.) —Ruakh TALK 14:12, 30 June 2009 (UTC)

Word of the day
How do I edit the word of the day? I clicked on "edit" and changed it, but the changes didn't come through on the main page, even after I clicked refresh.

Here's what's wrong with today's definition:

prolix: Tending to use large or obscure words, which few understand.

1. Grammatical error: the comma means we are stating that few people understand long or obscure words, as if the definition read: "Tending to use large or obscure words (which few understand)." This is not what is meant.

The intended sense is "Tending to use large or obscure words understood by few people". This requires the removal of the comma, and, if we want to be really clear, the replacement of "which" by "that", giving "Tending to use large or obscure words that few understand."

2. Vocabulary error: "THE" in 120-point letters is a large word but everyone who speaks English understands it. "Large" should be "long".

— Paul G 14:21, 25 June 2009 (UTC)

 * The Main Page displays via a template. So, you make the changes but the display on the Main Page will not change until (a) you clear your cache, and (b) the system gets around to updating all calls to that template.  This may take several minutes to much of an hour.

 * I notice that you have made the chnage to the WOTD template, but not to the entry for the word itself, which was the source of the definition. Yuo are always welcome to update the selected entries before their definitions are copied into the WOTD templates.  --EncycloPetey 14:54, 25 June 2009 (UTC)
 * Ah, now that's what I was looking for. It's academic now because we have a different word of the day now, but thanks for the information. — Paul G 13:05, 26 June 2009 (UTC)

Babel template?
Hi. I was wondering if someone could please create the template grc-0 (so I can put it on my userpage)? :) I know a few roots from ancient Greek (from studying word etymologies) and Latin and there is a lt-0, de-0 and fr-0 but I don't want it to look like I know Greek better than the others.  Thanks!  Logomaniac 22:23, 27 June 2009 (UTC)
 * Generally, the X-0 templates aren't very useful here, and we tend to discourage them. It would be better to describe your minimal skill in a text portion of your user page, appropriately labelled, rather than advertise in your user box that you don't understand that language. --EncycloPetey 00:01, 28 June 2009 (UTC)

 * Yes, I know that . . . it has been discussed elsewhere. So then should I delete all of my xx-0 Babel boxes? and is that a no for creating the grc-0 template?  Logomaniac 01:15, 28 June 2009 (UTC)

 * I would say so, yes. If we started listing xx-0 templates for languages we know only a little, Stephen, I, and others would have a huge list in our Babel templates.  In my case, I've studied Spanish and Latin formally, have independently studied Galician, have watched PBS programs teaching French, have pored over Romanian grammars, and as a result have a rating between 0 and 1 for most Romance languages.  That doesn't consider the fact that I've picked up a slght bit of Polish from working with medieval records that contain Latinized Polish, and have done the same with Hungarian.... you get the idea.  Stephen is even more eclectic, having worked in many scripts and as a translator.

 * It would make more sense, and be more use if that kind of information were briefly summarized as userpage text, rather than reducing it to a cryptic "0" rating. Such a rating could just as easily mean that you don't know the language at all. The only truly suitable I know of for an xx-0 is for people who work across multiple Wiktionaries in such areas as interwiki linkking, where a person may wish to indicate that the local language is one he doesn't know. --EncycloPetey 03:17, 28 June 2009 (UTC)

 * OK, I'll delete my lt, grc, fr, and de Babel templates. :)  One question tho - why the heck does Wiktionary even have xx-0 templates?  It's been puzzling me . . . . . . . . Logomaniac 18:55, 28 June 2009 (UTC)

 * Primarily because users copy them over from Wikipedia, where they sometimes are useful, such as when a person works on many Polish history pages, but does not speak Polish. --EncycloPetey 20:25, 28 June 2009 (UTC)

 * But can't that also happen here? For example, someone with Ancient Greek knowledge might edit a lot of etymologies (going where leads), but not speak the relevant languages. If said editor finds himself (or herself) frequently editing entries in some specific languages (say, [Modern] Greek), the zero-level Babel might be useful, no? —Ruakh TALK 01:35, 29 June 2009 (UTC)

 * I do understand what you're talking about, but editing etymologies that come from Ancient Greek isn't my specialty (at the moment, at least). I don't speak it either though. :)  I will now delete xx-0 boxes from my Babel - I hadn't gotten around to it before.  You two can drop the subject if ya want to.  Logomaniac 17:04, 29 June 2009 (UTC)
 * Not that I can tell. —  msh210  ℠  17:35, 29 June 2009 (UTC)

title: Wiktionary:Grease pit/2009/June


text:
generatoro

Noun

 * 1) generator

Noun

 * 1) generator

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

title: generatoro


text: generatoroj

title: generatoroj


text: generatoron

title: generatoron


text: generatorojn

title: generatorojn


text:
Citations:gunty

 * 1888: Table Talk, volume 3, page 289
 * He was well thought of at the Bank, and the other clerks called him “ Gunty,” a nickname which may safely be left to the logomaniac for explanation of its evolution.
 * 1959: Sidney John Baker, The Drum: Australian Character and Slang, page 130 (1st ed.; Currawong Pub. Co.)
 * no good to gundy: No good at all. Sometimes, no good to gundybluey and no good to gunty.
 * 1969: Eve Pownall, Mary of Maranoa: Tales of Australian Pioneer Women, page 11 (2nd ed.; F.H. Johnston)
 * “Little fella gunty,” exclaimed Kitty, a lubra on the Costellos’ station, “Valley of Springs,” on the Limm River, when she saw her mistress and daughters open parasols under the Gulf Country sky in the 80’s. Years later they recalled her astonishment at the swiftness with which the little ‘gunty’ (house) was erected, and her delight as she ran in and out of the parasol’s shade.

title: Citations:gunty


text:
User talk:24.85.143.195

--EncycloPetey 23:34, 23 December 2009 (UTC)

title: User talk:24.85.143.195


text:
कोरिया

Etymology
, from.

Proper noun

 * 1) Korea ; the Korean Peninsula
 * 2) South Korea or North Korea

title: कोरिया


text:
เกาหลี

Etymology
From. Cognate with 🇨🇬 or 🇨🇬.

Proper noun

 * 1) Korean
 * 1) Korean
 * 1) Korean
 * 1) Korean
 * 1) Korean
 * 1) Korean

title: เกาหลี


text:
Wiktionary:Grease pit/2009/July

= July 2009 =

Search: where did the preload templates go?
It looks like the Mediawiki people or somebody else has mucked around with the search so that instead of helpful preload options for a new entry when an non-existent entry is entered in the Search box, a barebones search page comes up instead. — Carolina wren discussió 04:12, 2 July 2009 (UTC)
 * Not only that, but this means that the "near"-spelling search that used to happen automatically now requires a user to initiate a seacond search to actually get the search to occur! That's silly.  Instead of getting a list of the closest matches, it returns only a single "did you mean"?  That may be fine for an encyclopedia, but it's counterproductive and harmful to a multilingual dictionary. --EncycloPetey 15:27, 4 July 2009 (UTC)

 * I've restored the preload options - we can probably modify hippietrails previous and next page script to show alphabetically close words on failed search, though it won't help with misspellings. Conrad.Irwin 19:53, 4 July 2009 (UTC)

 * Maybe, but diacriticals don't alphabetize correctly unless you force them to with fancy code. That is, "ábellarde" would come not after "abellarde", but after "zyzyxy", unless a code resequenced the listing. (examples are wholly invented) --EncycloPetey 20:14, 4 July 2009 (UTC)

 * Thanks. We missed you. DCDuring TALK 21:59, 4 July 2009 (UTC)

 * Is this fixed? I couldn't get the preload options to appear today.  I'd particularly like to get this fixed on ga:wikt as it cuts down on manual correction which is pretty much down to me.  If someone could give me a clue (like are we being sent to a new MW page and what is it?) I could make a start on it.  Thanks.  ☸ Moilleadóir ☎ 04:45, 6 July 2009 (UTC)

 * No, the software no-longer passes the failed search as a parameter to the message, so you can only create lots of entries at $1, I reverted my change. Conrad.Irwin 07:33, 6 July 2009 (UTC)

Other MW mucking
On a related note, it seems that additional legal warnings have been added to the edit window. I now have to scroll down each time I need to insert certain special characters, then scroll back up to see the edit window. Specifically, I now get:
 * By saving, you agree to irrevocably release your contribution under the Creative Commons Attribution/Share-Alike License 3.0 and the GFDL. You agree to be credited by re-users, at minimum, through a hyperlink or URL to the page you are contributing to. See the Terms of Use for details.

 * If you do not want your writing to be edited and redistributed at will, then do not submit it here. If you did not write this yourself, it must be available under terms consistent with the Terms of Use, and you agree to follow any relevant licensing requirements.

Now, I can undersatnd alerting anons or new contributors, but for the frequent editors, it is extremely irritating to have all this text pop up in every single edit window, thereby necessitating scrolling just to edit Latin entries. Is there any way to customize this portion of the edit window to collapse it / hide it, so that it doesn't interfere with editing? --EncycloPetey 16:41, 4 July 2009 (UTC)

 * Where are Conrad and Robert? They sometimes can figure out how get more reasonable results. Can't Javascript be used to allow more control over this aspect of screen appearance. Hippietrail has been active lately on preference-related matters. DCDuring TALK 16:46, 4 July 2009 (UTC)

 * Conrad has been busy off-line. Robert hasn't been around much lately. --EncycloPetey 16:48, 4 July 2009 (UTC)

 * There's a new WT:PREFS option "Hide the copyright warning in the edit window." you might want to try out. -- Prince Kassad 18:27, 4 July 2009 (UTC)
 * It would seem to make sense to combine the two boring paragraphs into one that more people will hopefully read. (it particularly irks me how they expand "Creative Commons Attribution/Share-Alike License 3.0" but leave "GFDL" condensed) Conrad.Irwin 19:53, 4 July 2009 (UTC)

"By saving you irrevocably give anyone the right to distribute and modify your work under the terms of the CC-SA license and the GFDL as described in the Terms of Use. Do not submit copyrighted work here, it will be deleted unless it is available under a suitable free license."

 * Thanks. That WT:PREFS option helps enormously! --EncycloPetey 20:16, 4 July 2009 (UTC)
 * Thanks. PrinceK. DCDuring TALK 21:57, 4 July 2009 (UTC)
 * Those who wish the pref to follow their account rather than their computer can add  to their monobook.css. (Untested, but should work.)  —  msh210  ℠  15:24, 6 July 2009 (UTC)

Miscategorisation of præserves
Does anyone have any idea why the entry for is being miscategorised into Category:English verb third-person forms and Category:English verb singular forms? †  ﴾(u):Raifʻhār (t):Doremítzwr﴿ 00:53, 4 July 2009 (UTC)

 * User:Daniel. has been making category name changes like this for all parts of speech. I suspect he might know why. --EncycloPetey 14:45, 4 July 2009 (UTC)

 * I’ve brought the matter to his attention and referred him hither. †  ﴾(u):Raifʻhār (t):Doremítzwr﴿ 16:06, 4 July 2009 (UTC)

 * This change ocurred because I edited the three main templates responsible for dealing with singular simple present indicative forms in various languages:, and . Initially, this was done to prevent the existence of a excessive number of highly-detailed categories in German language (such as Category:Spanish informal second-person imperfect indicative forms). --Daniel. 17:20, 4 July 2009 (UTC)

 * Hmm. I don’t think that this is appropriate for English verbs. The third-person singular simple present indicative form is the only verb form regularly marked differently from the rest of the English verb forms (excepting the archaic forms with ). The way that these verb forms are now categorised lumps together undefined:, (undefined:,) undefined:, and undefined: in the first category, whilst listing together undefined: with undefined: in the second category; this essentially means that virtually all English verbs should be members of both categories. (Granted, our naming of the former category was never watertight — it elliptically allowed subjunctives and past forms, in theory.) Even if we are to let it be assumed that these abbreviated category names only allow third-person singular simple present indicative forms, we should not have redundant, duplicate categories for these forms. †  ﴾(u):Raifʻhār (t):Doremítzwr﴿ 18:25, 4 July 2009 (UTC)

 * I see. I still think that the categorization system in question (i.e., separating various characteristics of verbs into different categories, such as Dutch verb singular forms) is appropriate for many languages, so I'd like to keep my edits in the three templates above. I agree that this is not appropriate for English, though. Then, I also propose these watertight categories for the few possible English conjugated verb forms:
 * English verb forms
 * English verb irregular forms
 * English irregular past participles
 * English verb simple past forms
 * English verb archaic second-person singular present indicative forms
 * English verb third-person singular present indicative forms
 * English verb archaic third-person singular present indicative forms
 * ''English past participles
 * English irregular past participles
 * ''English present participles
 * --Daniel. 19:14, 5 July 2009 (UTC)

 * Sounds good. May I suggest that you also include English verb irregular simple past forms (e.g. in the irregular conjugation of ) and English verb archaic second-person singular simple past forms (strong-conjugation verbs (and some weak-conjugation monosyllabic verbs) suffix  in the second-person singular simple past; e.g., , , , &c.). Except for modals and other irregulars, that’s all of them, I think. †  ﴾(u):Raifʻhār (t):Doremítzwr﴿ 20:34, 5 July 2009 (UTC)

 * As this is a significant category renaming, I suggest posting in the BP to be sure there is general support for restructuring the names. There may be a problem in some language categories with renaming in this way.  The restructured names do look a little odd to me, since some of the descriptive terms follow the primary noun, but some of them preceded the noun.  This has the potential to make for inconsistent category naming.  --EncycloPetey 04:55, 6 July 2009 (UTC)

 * I agree with the Doremítzwr's suggestion of adding these two English verb categories and made a few changes in my proposals, including clarification of the naming structure. They are now posted at Beer parlour. --Daniel. 07:57, 9 July 2009 (UTC)

disclike
I'm trying to work out why this isn't categorising correctly. The syntax looks okay to me, surely like is a suffix, it's not a combining form, is it? Mglovesfun (talk) 21:14, 5 July 2009 (UTC)
 * Hmm, putting lang=en seems to solve it, although English is supposed to be the default anyway. I'll have a look at the coding. Mglovesfun (talk) 21:16, 5 July 2009 (UTC)
 * It looks as though User:Opiaterein had done a test edit on the template that broke its categorization function. I've alerted him. --EncycloPetey 04:59, 6 July 2009 (UTC)

Search box special characters
For several days, at least, I have not had the use of special characters in the search box. The edittools pull-down appears, but no special characters appears after the selection. I thought I had made the right selections at WT:PREFS}}. If I am making a mistake in using "my preferences" or [[WT:PREFS, it is one I persist in making. Today I deleted my wiktionary cookies and started again without improving anything. Can the problem reside at another level? DCDuring TALK 21:23, 6 July 2009 (UTC)

 * Thanks, Ruakh. If anyone else has the problem, see my talk page for a fix by Ruakh. DCDuring TALK 22:51, 11 July 2009 (UTC)

ionly c cifredbox>hwo2display?
Hanzi

㑉 (pinyin sù (su4), Wade-Giles su4)

http://en.wiktionary.org/wiki/%E3%91%89

skyp: sven0921--史凡 01:22, 9 July 2009 (UTC)

When deleting an article
When you delete an article, what's the MediaWiki page that you see? I want to copy the code for the French Wiktionary as it would be handy (like special:whatlinkshere/deleted article). Reply here, or to my talk page. Mglovesfun (talk) 21:34, 11 July 2009 (UTC)

 * Presumably you want the completion message? MediaWiki:Deletedtext Robert Ullmann 02:28, 12 July 2009 (UTC)

Category:Dutch_weak_verbs won't update
User:CodeCat has temporarily switched off Category:Dutch weak verbs from appearing in pages with the template, in order to obtain a list (a to-do list, as it were) of pages with Dutch weak verbs which do not yet have the  template. Anyway, the problem is, that after having done that, Category:Dutch weak verbs will not update. For example, the article for aaien currently shows only Category:Dutch verbs and not Category:Dutch weak verbs, but Category:Dutch weak verbs still lists aaien. Does anyone know what is going on, why the category won't update? —AugPi 02:14, 12 July 2009 (UTC)

 * It depends on when the job queue gets to it. If things are not busy, it happens quickly; if they are, it takes a while. At the moment there are a lot of cache invalidates, and the P2 partition (en.wikt, 14 wps, common and meta) is constantly lagged 10-30 sec). It may take some time. Robert Ullmann 02:24, 12 July 2009 (UTC)

 * The edit was done something like 10-12 hours ago, and only about 200 out of over 1000 articles have disappeared from the category, most are still there. So whatever 'some time' means, it seems to be an awfully long time. I guess I'll just have to wait. --CodeCat 09:09, 12 July 2009 (UTC)

 * CodeCat, please do null edits to the affected pages (i. e. adding a space somewhere). This causes the pages to disappear from the erroneous categories. -- Prince Kassad 13:53, 12 July 2009 (UTC)

 * A "null edit" can be just that; don't change anything, just edit/save. It won't show in the history (as there is no change), but it will force the page cache invalidate, and re-parsing. And note the job queue is seriously behind; the server lag on partition 2 (which has the en.wikt among other things) is "lagged" seriously. It was slowing down Interwicket seriously, I improved its timer handling this morning. (It should back off enough, but not really far. ;-) Robert Ullmann 14:14, 12 July 2009 (UTC)

 * I know that would work, but we're talking over 1000 pages here, so that's not exactly doable. And besides, isn't that kind of repetitive task what we have software for, in the first place? :p --CodeCat 14:51, 12 July 2009 (UTC)

 * Quite so. Running ... (:-) Robert Ullmann 15:12, 12 July 2009 (UTC)
 * I noticed you cleaning up the leftovers ... it took a while to run because p2 is/was overloaded. You might want to look at User:EncycloPetey/Verbos, it is fairly easy to do similar things. Robert Ullmann 08:19, 13 July 2009 (UTC)

Collapsing boxes not working
All of a sudden the {trans-*} collapsing boxes aren't working (they are stuck open with no show/hide link). I'm on MS Vista with IE8, FF3.5 and Chrome.

 * Not a general problem (others don't see it); did you turn off Javascript intentionally or by accident? Robert Ullmann 14:16, 12 July 2009 (UTC)

 * Ah, so it happened because I switched to the Vector theme (from monobook). Changed it back and everything works fine again. Is there something people who use non-monobook themes have to do to enable this (and possible other js things)? --Bequw → ¢ • τ 17:52, 12 July 2009 (UTC)
 * I suppose the best way would be the refactoring of MediaWiki:Monobook.js → MediaWiki:Common.js. While very useful I understand that that has been put off for some time. Including MediaWiki:Monobook.js from my user Vector.js works, but leaves things a bit ugly (probably because it's lacking some of MediaWiki:Monobook.css). --Bequw → ¢ • τ 23:38, 12 July 2009 (UTC)

Problem with arabic shadda's
There is a problem with shaddas when writing in arabic script. A shadda and a diacritic one after another always get inverted. Like this: شَدَّة. Here I typed a shadda then a fatha which should have given this: شَدة. It works when using unicode codes. Any idea what is happening ? It is is bothersome because it makes the wiki-code harder to read, and also it is impossible to enter words with shaddas using the translation edit tools. Beru7 20:05, 12 July 2009 (UTC)

 * This is the Nikkud bug, the result of normalization (I think that is the word they used). The Foundation "normalized" input so that even if people enter certain kinds of text in different orders, it will always be saved in the same order, so that searches will be more dependable. It creates problems with right-to-left scripts like Arabic. I reported it several years ago and it was never fixed, so apparently it won’t be. You cannot type two Arabic diacritics in a row or they will be improperly inverted. The work-around is to type it this way: shadda+fatha =  • shadda+kasra =   • shadda+dhamma =   (without spaces): لستنَّ إنـِّى الطـُّولى —Stephen 21:45, 12 July 2009 (UTC)

 * From what I understand, it's not so much a bug in MediaWiki as in Unic�de itself. It's arguably a bug that MediaWiki is enforcing a buggy standard, but until Arabic countries have the kind of political clout that would get the Unic�de C�ns�rtium to violate its policy on incompatible changes, I don't think we can expect improvement. (It also affects Hebrew, but is only problematic in some really, really rare cases — like, a few times in the Bible, and never anywhere else.) BTW, I think Beru7 was already aware of your approach (it's what (s)he means by "using unicode codes"). Also BTW, to produce an ampersand, type . So, shadda+fatha =   • shadda+kasra =   • shadda+dhamma =  . —Ruakh TALK 22:44, 12 July 2009 (UTC)

 * I don’t know the fine details but it used to work fine from 2002 through 2004. Then in 2005, Wikimedia flipped a switch somewhere, enabling "normalization". That’s when the Nikkud bug made its appearance. I made two reports at bugzilla, and reports were also filed by some Hebrew editors, but nothing was ever done about it. —Stephen 11:38, 13 July 2009 (UTC)

 * Yes I was aware of how to display things correctly and even modified to get the right result more easily. So thanks to your pointer Stephen I have found and read much more about the subject. From what I understand it is not really a bug in unicode. The unicode normalization standard C indeed dictates that the order is fatha + shadda and not shadda + fatha. However the real problem is that windows displays fatha + shadda differently than shadda + fatha. It shouldn't and from what I gather Service Pack 3 fixed the bug for hebrew nikkud but, unfortunately, not for arabic diacritics. So for now we have to use the codes, which makes life harder for editors and also breaks search. It is too bad because it would be really easy to fix, but it would mean deviating just a little bit from the unicode normalization standard and that is not acceptable to the foundation apparently. Now, what I am wondering is, couldn't we fix this ourselves with a little javascript that would replace fatha+shadda with shadda+fatha right before page display ? Beru7 12:10, 13 July 2009 (UTC)
 * The function in my User:Beru7/monobook.js seems to work. I don't know if it can be included in the wiki's common.js or not. Beru7 13:56, 13 July 2009 (UTC)

The problem did (or would have, it makes sense) appear when normalization was turned on. But the actual bug is not in Unicode, it is in the rendering. It is like this:

 * 1) Unicode provides for "decomposed" characters, base character + modifier + modifier ...
 * 2) Thr order of modifiers is in most cases not significant, e.g. L + M1 + M2 should be the same (look the same when rendered) as L + M2 + M1
 * 3) where there is a difference in rendering, the modifiers are given the same "combining class" to indicate that they interact
 * 4) otherwise, they get different combining classes
 * 5) normalization sorts them on combining class, using a stable sort, so modifiers in the same class are not re-ordered, but those that are in different classes are
 * 6) this means equivalent strings will compare equal when normalized

Got that? (:-) Now onto Arabic:

A given letter + shadda + fatha should render the same way as letter + fatha + shadda. (As defined by the standard.) The problem is an interaction between two things:

 * 1) the font rendering in the browsers etc do not treat the two orders the same, in spite of the standards requirement that they do, and
 * 2) the combining class assignments for the Arabic modifiers were given unfortunate combining classes: shadda is 33, and fatha is 30, so the sort is the reverse of the expected linguistic order

Now (2) shouldn't be a problem, except for (1), which is a bug. Robert Ullmann 12:24, 13 July 2009 (UTC)

 * Ah, so I guess Arabic is bit different from Hebrew. In Hebrew, the order does matter in some cases. (Full explanation: there are a few places in the Masoretic Text, such as Lamentations 1:8, where a single consonant has two vowels underneath it. Those two vowels need to be in the right order, but Unicode specifies that the order doesn't matter, and (for example) normalizes the correct into the incorrect . This is a bug in Unicode.) Even aside from that, the combining classes are weird for Hebrew (e.g. the vowels sort before the dagesh, even though the dagesh is actually part of the consonant), but most browsers nowadays seem to handle it O.K. —Ruakh TALK 13:16, 13 July 2009 (UTC)

 * Links: w:Wikipedia:Niqqud, Unicode normalization considerations and 2399 Beru7 13:30, 13 July 2009 (UTC)

 * The correct solution for Hebrew (e.g. your example) is to insert U+034F (Combining grapheme joiner, CGJ) in the sequence, which prevents reordering. So for example the points patah + hiriq can be written patah + CGJ + hiriq and they won't be reordered into hiriq + patah. Robert Ullmann 13:42, 13 July 2009 (UTC)

 * You say "solution", I say "workaround", but that does seem to work: יְרוּשָׁלִַם. Thanks! (Though for some reason it confuses Firefox into thinking the text is really tall, heh.) Hey, I wonder if we can get MediaWiki to handle this for us automatically? —Ruakh TALK 14:16, 13 July 2009 (UTC)

 * It is the Unicode defined standard way to force modifiers into a specific order other than combining class where/when strictly required, and specifically in this case. So it isn't a "workaround", but rather the recommended standard method for these cases in Hebrew. MW is doing normalization properly ... (:-) Robert Ullmann 23:40, 13 July 2009 (UTC)

 * Yes normalization is properly done, and the unicode standard isn't broken, but Windows XP still doesn't display correctly some arabic diacritics in normalized texts (I tested with Firefox on Ubuntu today and it works well). Since most users actually use Windows, something should be done about it. Right now we are polluting our pages with things like this  to work around this problem. I have proposed above a small javascript function that would simply swap some characters on page load so that everything is correctly displayed. I would like to know if such a solution is acceptable or not. Beru7 23:49, 13 July 2009 (UTC)

 * The concept of your solution is definitely good, but I worry that replacing the innerHTML of the entire body might be problematic (e.g., likely to conflict with another script running at the same time; also, likely to take a long time on large pages on slow or low-memory computers, since it involves fully serializing and then fully deserializing the page). I wonder if it would be better, or worse, to go through the page and specifically target spans of classes Arab, ku-Arab, etc.? (Thanks to, our script templates are very consistent in using this sort of class, so aside from classed text, the only things we'd need to touch are the page's title and its H1 header.) Maybe I'm just worrying too much, though. —Ruakh TALK 03:53, 14 July 2009 (UTC)
 * For what it's worth, replacing .innerHTML of the body can break event handlers that have been attached to the document dynamically (i.e. our [show] buttons), so should not be done. Iterating over all nodes with a specific class will be much easier when we get jQuery installed (which is I believe in the pipeline for MediaWiki). Conrad.Irwin 07:11, 14 July 2009 (UTC)
 * You are right the collapsible boxes weren't working anymore ! I modified my function (User:Beru7/monobook.js) so it only replaces text within tags. Tell me if it needs more work - or if I should just drop it for now ! Thanks. Beru7 14:50, 14 July 2009 (UTC)
 * Yes, it's the Unicode defined standard workaround. As I said, I'm not blaming MediaWiki. :-)  —Ruakh TALK 03:53, 14 July 2009 (UTC)

The js sounds like a good thing. It should operate on elements with class "Arab" or "xx-Arab" (e.g. "fa-Arab"); using "*Arab" to match the class name is probably just about right.

FYI: FireFox 3.5 has known issues with editing Arabic and also Hebrew Niqqud, where characters get detached; is apparently very annoying. This is fixed in 3.5.1. (I recommend 3.5+, it is noticebly faster.) Robert Ullmann 05:04, 18 July 2009 (UTC)

Ubiquity command
I was wondering if anyone knows of a Ubiquity script which can be used to access Wiktionary directly from firefox using the popular 'Ubiquity' add-on? Found nothing with a google search. Andipi 21:24, 12 July 2009 (UTC)

Error message from Assisted Translation
Now getting message "Could not find translation table for 'it:scitico'. Please improve glosses" when trying to use Assisted Translation system (browser = Google Chrome (don't ask!)). SemperBlotto 21:41, 12 July 2009 (UTC)
 * Assuming this was on Scythian, I have improved the glosses and it should now work. (I will at some point fix it to match up all translation tables taking ordering into account as well as relying on finding unique headings.) Conrad.Irwin 07:40, 13 July 2009 (UTC)

Disabling preload templates
Can I customize preload templates to my needs? I liked it when they were broken; the search page looked neat and clean. I want to disable those or at least create and see only ones I choose. --Vahagn Petrosyan 23:07, 12 July 2009 (UTC)

 * Add the following to your monobook.css page. Conrad.Irwin 07:29, 13 July 2009 (UTC)

 * 1) searchmenu-new-preload { display: none; }

Thanks, it worked. --Vahagn Petrosyan 08:57, 13 July 2009 (UTC)

Numbering of definitions
war and rhubarb show that definition numbering is failing with some or all being numbered 1. I haven't spent long looking for other examples - what's wrong? — Saltmarsh απάντηση 05:59, 14 July 2009 (UTC)
 * fixdrubarb1/2;)--史凡/ʂɚ˨˩fan˧˥/shi3fan2 (歡迎光臨/Welcome! 請也用/Please also use skype: sven0921為我/since I suffer RSI!) 06:22, 14 July 2009 (UTC)
 * =noblank lines![i/the wikicode]:)--史凡/ʂɚ˨˩fan˧˥/shi3fan2 (歡迎光臨/Welcome! 請也用/Please also use skype: sven0921為我/since I suffer RSI!) 08:33, 14 July 2009 (UTC)

q
== can longlists ofcompounds[i/hanzi entries,ex.下] be hidden

w/'show'-button?[like w/'translations']?---史凡/ʂɚ˨˩fan˧˥/shi3fan2 (歡迎光臨/Welcome! 請也用/Please also use skype: sven0921為我/since I suffer RSI!) 06:02, 14 July 2009 (UTC)

 * See January: for an example of a page where the Derived terms are hidden using, and . --EncycloPetey 21:29, 14 July 2009 (UTC)

how2movesth /discussion]fromsay talkpp.2here?
--史凡/ʂɚ˨˩fan˧˥/shi3fan2 (歡迎光臨/Welcome! 請也用/Please also use skype: sven0921為我/since I suffer RSI!) 06:37, 14 July 2009 (UTC)
 * Edit that page, select all the text, copy, edit this page, paste it here, save, delete it from there, and save. Make sure when you paste it here you indicate where it came from, so as to allow someone to determine the citation (who said what) as required AFAICT by the GFDL. (IANAL.) —  msh210  ℠  15:59, 14 July 2009 (UTC)

oh-sure![ithought there 'dbe aspecific function4that,my bad！:)--史凡/ʂɚ˨˩fan˧˥/shi3fan2 (歡迎光臨/Welcome! 請也用/Please also use skype: sven0921為我/since I suffer RSI!) 16:57, 14 July 2009 (UTC)

Missing categories

What actually are these? I guess they come from a bad use of, I'll try and eliminate them. Mglovesfun (talk) 09:21, 15 July 2009 (UTC)

 * Thank you for bringing these two categories into attention. I've created them now. They are being discussed at Beer parlour. --Daniel. 09:43, 15 July 2009 (UTC)

Template:see-conj
In a similar way to, I just created mettre au monde: which uses the conjugation of mettre, something like  </tt> would be good, and would link to mettre. Does this already exist? If so, I can't quite think where to look for it. Mglovesfun (talk) 18:12, 15 July 2009 (UTC)
 * That is an improper name. Templates prefixed with "see-" should be for the Seneca language.  I would expect a template named see-conj to display the inflection line of a Seneca conjunction.  Why do we need a template for this? --EncycloPetey 20:28, 15 July 2009 (UTC)
 * Well how would you link to the conjugation of mettre? My initital instinct was

====Conjugation=== I was more or less anticipating that someone would correct me on this, so I tried to preempt it by suggesting a template myself, even though it can be replaced by simple text. Mglovesfun (talk) 20:34, 15 July 2009 (UTC)
 * see mettre:
 * I think "see " is not quite clear enough and should be something like "Conjugated forms are those of, with undefined: appended.". <half-jokingly>Perhaps we should templatify that?</half-jokingly> —  msh210  ℠  22:03, 15 July 2009 (UTC)
 * Clear enough, yes, but it different people will end up doing different things. I'm not particularly for it as I think it can be done by hand, I just thought other people might be for it. Mglovesfun (talk) 14:27, 16 July 2009 (UTC)

 * I'm not sure a template would be very useful for this. We might want to templanate it eventually, but I think we'd first want to try out a few different pages, and see what kinds of flexibility the template would need to have. Translations are split by sense, so we have a bunch of adjacent fancily formatted translation boxes, which fits in with; but conjugations are rarely like that (and when they are, as with fleurir: or ressortir:, we need clarifying text anyway). Though I see that we're actually missing one of the conjugations of fleurir:! —Ruakh <i >TALK</i > 01:34, 16 July 2009 (UTC)

MediaWiki:Edittools
How come on the French Wiktionary, every time you edit a new page you have to re-select the sub-section you want, but on here it uses the last page you chose. What parameter does this? Mglovesfun (talk) 22:29, 17 July 2009 (UTC)

 * In Mediawiki:Monobook.js, you'll find it sets a cookie ("edittoolscharsubset") when you choose one. (in "chooseCharSubset") So it persists. Should be easy to copy. Robert Ullmann 05:11, 18 July 2009 (UTC)

 * Is there something to add to my monobook.js (or elsewhere) to make it follow the user rather than the browser? —  msh210  ℠  21:00, 19 July 2009 (UTC)

 * Yes, but no very smooth way, since you probably wouldn't want to remove the ability to set it to something different on a given computer. (For example, if you switched it to "Arabic" to edit a certain page, you probably wouldn't want it to switch back the instant you hit the "Show preview" button.) The best/simplest approach I can think of is something like this: var edittoolscharsubset_value = parseInt(getCookie('edittoolscharsubset'));
if(edittoolscharsubset_value == 0 || isNan(edittoolscharsubset_value))
 setCookie('edittoolscharsubset', '22'); in the case of "Hebrew". (That checks if the <tt>edittoolscharsubset</tt> cookie exists and is nonzero — <tt>0</tt> being the index of "Templates", which is set by default — and if not, it sets it to <tt>22</tt>, which is the index of Hebrew.) The main problem is, every time the index of Hebrew changed, you'd have to edit Special:Mypage/monobook.js to match. And the "Templates" value would never stick. (Really, I think it's kind of a mistake that we set the cookie to <tt>0</tt> by default — we should leave it blank by default, and just treat blank the same as <tt>0</tt> — but I suppose it doesn't matter much for most purposes.)
 * That said, I use a completely different approach, which you might want to try; User:Ruakh/monobook.js has a bit of code that basically copies the "Misc.", "Hebrew", "Latin/Roman", "IPA", and "enPR" sections up into non-collapsed <p>s. (The relevant code is the <tt>findEdittoolsSection</tt> function, and the <tt>addOnloadHook</tt> block underneath it. It should be obvious how to customize it for whichever sections you want to copy up.)
 * —Ruakh <i >TALK</i > 03:48, 20 July 2009 (UTC)
 * Thanks. —  msh210  ℠  19:51, 20 July 2009 (UTC)

wotdoesthis do pl?tw here4trad.?
 * ps: =?--史凡 - Please also use skype: sven0921 as I suffer RSI and thus cannot type very well! 18:16, 20 July 2009 (UTC)

 * is an example of a topical context template. It provides the visible context label (weather) and adds the entry to Category:Weather. The lang=zh-tw parameter specifies that it is the category for Chinese language entries Category:zh-tw:Weather, presumably of the "tw" variety. If one were to add enough tags with the same content, say "operations", eventually a category and the associated specific context template  would be magically created. I'm not sure what it takes for the category magic to occur in each language as entries are labeled with the various lang= parameters. DCDuring TALK 18:46, 20 July 2009 (UTC)

italic titles
Pages on Wikipedia about genera, species, latin phrases, etc. are being italicized with Template:Italictitle which I copied here. Should we do this? Pzrmd 08:28, 22 July 2009 (UTC)

 * Technically: (gaak! ;-) I thought I'd seen some terrible things, but that one is one of the worst. It uses templates that try to do what the (poorly designed, hence not installed) string functions extension does, in turn using a bug in the padleft parser function, with layers and layers of iteration. If we want to, we'll do it a far better and simpler way!

 * Desirability: I'm pretty sure people will not want this. And note that when an entry has multiple languages it may not be in the group where italics might be appropriate for the title for all languages, unlike in the 'pedia with one topic. (for example Erica) Robert Ullmann 10:59, 22 July 2009 (UTC)

 * Italicization is language-specific, so it shouldn't be applied to page titles. It probably shouldn't be anyway.

 * It might be applied to headwords, but in some cases it may be sense-specific. It would be more valuable to apply a label or usage note explaining why a word is italicized: unnaturalized borrowing, scientific name, title of a major work, etc. —Michael Z. 2009-07-22 13:11 z
 * I agree with RU and MZ: it's language-specific, sometimes sense-specific, so should not be used on the h1. —  msh210  ℠  17:10, 22 July 2009 (UTC)

 * I agree with the other editors, except for RU's "technically" paragraph. On Wikipedia, it's terrible — incredibly so — because they have tons of ugly, expensive code to check for parenthetical disambiguation labels not to italicize (e.g. at <tt>w:</tt>Hydra (genus)]]); but we don't use such labels, so if we wanted something like this template, we could jettison all that code. But I must say, their ugly, expensive code is kind of brilliant. They should be perversely proud of it. —Ruakh <i >TALK</i > 17:36, 22 July 2009 (UTC)

Also have a look to the following page title: fr:Mme. I agree with above comments: if you want to add Mme for a different language (with a normal typography), it has to be removed anyway. Lmaltier 18:04, 22 July 2009 (UTC)

Whilst this is a very good idea for inflexion lines’ headwords (i.e., the lines immediately below POS headers), it isn’t for page titles because of the issue of inconsistent italicisation translingually; however, if say, a species name, is italicised in every language in which it appears, then perhaps, in such cases, italicising their page titles would be OK, though such a thing is of questionable desirability. <font style="color:darkred">†  ﴾(u):Raifʻhār (t):Doremítzwr﴿ 18:13, 22 July 2009 (UTC)

 * Yes. But it cannot be made systematic. Better be consistent, and keep to principles. But, of course, it's very important to use a correct typography inside the page. Lmaltier 18:39, 22 July 2009 (UTC)

 * Would it be possible to add an <tt>ital=</tt> parameter to our various inflexion templates to allow for this italicisation of inflexion lines’ headwords? <font style="color:darkred">†  ﴾(u):Raifʻhār (t):Doremítzwr﴿ 20:32, 25 July 2009 (UTC)

 * It might be simpler to just have a specially dedicated inflection line template for all the genera and species. Since they will all be translingual proper nouns, a single template would work for all of them. --EncycloPetey 20:58, 25 July 2009 (UTC)

 * But such italicisation is appropriate not only to the cant of botanical Latin — in English, for example, many “foreignisms” are marked out by italics in edited prose (e.g., ) — they would also warrant the <tt>ital=</tt> parameter. <font style="color:darkred">†  ﴾(u):Raifʻhār (t):Doremítzwr﴿ 03:36, 26 July 2009 (UTC)

 * Note that man scientific names correspond to common names, although we seem to put them in separate entries, just because the capitalization varies, or to confuse the reader, or something. Examples: geranium and Geranium, aster and Aster, orca and Orcinus orca, E. coli, etc. —Michael Z. 2009-07-26 16:48 z

 * What kind of user are we helping by taking a lexical approach to typographic variation in entry titles for search or display? Of course we have no facts, but I don't think that the overwhelming majority users expect typography to be matter of concern in the search and display process. We probably provide adequate service to those who are concerned about typography when we give them information on typographic practice in various contexts. The variation in typographic practice only imperfectly maps to inflection line or even sense line. Although there may be cases where there are good reasons to place typographic information at the inflection line or the sense line, it seems more like appendix material than lexical entry material. Where links to such appendices might be placed is an interesting design question. DCDuring TALK 17:15, 26 July 2009 (UTC)

 * The COD and some other dictionaries indicate unnaturalized foreign terms using italicization of the headword. This is very sensible: it's a lexical quality, indicated in the dictionary the same way it is indicated in normal writing.  The information is descriptive, being based on Oxford's citations database.  It gets the information across using zero extra characters, symbols or labels; it is self-explanatory to anyone who cares about it, and doesn't bother anyone who doesn't.  It also serves a practical function for the reader, conveying this bit of writing advice for the entire surveyed corpus without forcing her to find a style manual.

 * But capitalization and italicization are attributes of a word or sense, not always differentiators of meaning, typically secondary, optional, or only in nuance. They should be indicated for the reader as usage, but we shouldn't use them to remove these non-spelling variations of words to separate web pages.  This places a burden on the reader to actually figure out  what is the significant difference between liberal and Liberal, or aboriginal and Aboriginal, for example, to guess whether we've actually addressed these differences adequately, or even realize that there is another entry important to their query. —Michael Z. 2009-07-26 18:16 z

 * Sorry, I didn’t quite follow here; your first paragraph seems to argue in favour of such inflexion-line italicisation, whereas your second seems to argue the opposite — which is it? <font style="color:darkred">†  ﴾(u):Raifʻhār (t):Doremítzwr﴿ 22:28, 27 July 2009 (UTC)

 * I was noticing this very problem at beta where there is confusion relating to Beta. I don't think most users think to look at other capitalizations, especially after the content goes off the screen. A user looking for the Brave New World "Betas" would not find them at "beta". There is not much reason for giving users this problem in English.
 * OTOH, I may just be confused about the specificity of what we attest to and how it relates to what we present to users. We often seem so punctilious as to have completely forgotten about "imbecilic" users, even when they strongly resemble ourselves, perhaps some time ago. DCDuring TALK 21:21, 26 July 2009 (UTC)

 * We have case, so we naturally started using it (gosh forbid we should get hammers). Nobody stopped to think that in a print dictionary, the other version is always right there, while in a web page it can't be seen at the same time!   This is a bad situation for the readers, but unfortunately it's mainly editors who are making the dictionary.

 * A solution is to never split up an etymology or part-of-speech subheading between separate entries due to capitalization. Do we have a chance in hell of agreeing on something like that? —Michael Z. 2009-07-27 03:21 z

 * Well, you've got my vote on that. I'd like to make sure that I get all the implications, but it seems like the right direction. I fear that it is likely that someone will feel that some potential ox of theirs might get gored. DCDuring TALK 03:36, 27 July 2009 (UTC)

 * For terms not Translingual, I thought this is a simple problem in logic under WT:CFI. By convention the use of italics to mark a passage in running text marks it as not English and defines where the non-English passage begins and ends. We are not supposed to be accepting such passages as evidence of use in English. If a phrase of originally non-English text is "borrowed" whole into English and appears without italics, we could and often do include it as an English entry. It could also appear as a whole in its original language, in which case it also does not appear in italics.
 * If Translingual terms are italicized, but the corresponding English term is not we have created extra entries, to no useful purpose that I can see.

 * If we were to recognize italics in headers, would we then have to allow for attestation both with and without italics?
 * How does this help users?
 * How many extra nanoseconds of delay for every search?
 * It is hard for me to see any real benefit from such a change based on the information provided so far. DCDuring TALK 23:38, 27 July 2009 (UTC)

 * Headword italicization seems not-very-useful, in that most people wouldn't notice it, or if they did, wouldn't know how to interpret it. (In a print dictionary, you see a bunch of headwords at once, so you notice if one is italicized while the rest are not. On Wiktionary, for all you know it's our custom to italicize headwords.) I mean, we should do it, but it's not a complete solution. (But as for the suggestion to merge Uppercase and lowercase entries, I heartily support.) —Ruakh <i >TALK</i > 02:58, 28 July 2009 (UTC)

 * You're right about italicization. I tried to figure that out quite a long time ago, but the results were unsatisfying.  It would be nice, but I can't think of any way to accomplish it that's not too much effort for the gain.

 * I'm glad to see that unifying alternate capitalizations might have support. I'll propose it in a bit. —Michael Z. 2009-08-07 05:24 z

French without conjugation
Hello. U ppl r normally gd at manipulatin the dump. Is it possible 2generate a list of all French Wikt entries sans conjugatn? 'd B gd, coz I'm always findin these entries + addin conj 2 entries. Maybe 2 put at User:Rising Sun/Sans conj? Ta --Rising Sun 18:35, 22 July 2009 (UTC)
 * To aid the anglophones around here, I'll translate: "Hello. You people are normally good at manipulating the dump. Is it possible to generate a list of all French-Wiktionary entries sans conjugation? It would be good, because I'm always finding such entries and adding conjugation to [them]. Maybe [you could be convinced] to put such a list at User:Rising Sun/Sans conj? Ta." —  msh210  ℠  22:20, 22 July 2009 (UTC)

inserting direct links from HT's page

 * Sorry I am cancelling this request because.I could formulate the link I wanted.Mahitgar 05:39, 24 July 2009 (UTC) I have requested a help at Wiktionary talk:Random page simmiller request seems to have been made early this month by another wiktionarian too.Thanks and Regards.

Mahitgar 05:32, 24 July 2009 (UTC)

how2luk up 'xcl' pl?
itrydwt:iso language code2no avail:(--史凡 -Pl also use MSN/skype as I suffer RSI and so cannot type very well! 08:33, 24 July 2009 (UTC)
 * <tt>xcl</tt> is a language code for Old Armenian, defined here in the template . We don't have "about page" (WT:AXCL) for it yet. --Ivan Štambuk 12:27, 24 July 2009 (UTC)

tx:)-isthere alist ofthose codes ivan?--史凡/Sven - Pl also use MSN/skype as I suffer RSI and so cannot type very well! 17:14, 24 July 2009 (UTC)
 * The usual reference is the SIL/ISO website, where one can search both the codes and language names. They define xcl as "Classical Armenian", but we chose the name Old Armenian to be in conformance with the Wiktionary naming scheme used for other ancient languages (such as Old English, Old Church Slavonic etc.). --Ivan Štambuk 17:23, 24 July 2009 (UTC)

ta!!:D--史凡/Sven - Pl also use MSN/skype as I suffer RSI and so cannot type very well! 17:38, 24 July 2009 (UTC)
 * We have an official list and AF's list. RU has a list of existing L2 headers, which is not all languages we recognize. (Well, maybe it is, but it certainly needn't be.) —  msh210  ℠  17:32, 27 July 2009 (UTC)

translations
<'dthat be aded byboti/al those entrys?
 * dutch:often m/f we takem2gether[4got term4that..]as~ubergender>canbe acomodated i/mask?--史凡/Sven - Pl also let me use voice-MSN/skype 2clarify as I suffer RSI and so cannot type very well! 11:43, 27 July 2009 (UTC)

 * You mean the Dutch common gender? We use c for "common", m for "masculine", f for "feminine", n for "neuter".  Note, however, that "common" is not the same as "masculine and feminine".  A common gender noun is neither specifically maculine nor feminine.  So, while Dutch has a common gender, it also has some masculine and some feminine nouns.  Spanish has nouns that may serve as either masculine or feminine, but these are not common gender nouns, because they may take masculine or feminine adjectives or complements.  Spanish has no common gender. --EncycloPetey 13:06, 28 July 2009 (UTC)
 * According to About Dutch, Dutch doesn't have a common gender as far as we're concerned. From a linguist's standpoint, it's valid to talk about the common gender in some forms of Dutch, but that's not the approach Dutch dictionaries take, including the Dutch Wiktionary. I think any proposal to use c for Dutch should be discussed at Beer parlour and/or Wiktionary talk:About Dutch — or if there's already been such a proposal, and people supported it, then it needs to be documented at About Dutch. —Ruakh <i >TALK</i > 20:11, 28 July 2009 (UTC)

<thatp.=DEAD!!-'d aluk recently?hardly any[butcontenshes]topics,DEADdisc-p.[notevisvivayear-old pertinentq.],unsigndcoments,noprfesionality-butkeepmefromcontributin,sure: ( nthe"taalunie"4me=DEAD2,patronising institution!--史凡/Sven - Pl also let me use voice-MSN/skype 2clarify as I suffer RSI and so cannot type very well! 06:32, 29 July 2009 (UTC) y!:D but no c i/asisted transl.. :/--史凡/Sven - Pl also let me use voice-MSN/skype 2clarify as I suffer RSI and so cannot type very well! 13:52, 28 July 2009 (UTC)
 * imFlemish[antwerp],butoften ican onlytell'its de[def.art.]',andnotwhether its'hij/zij'[replacin'pers.pronoun]+thelatter difrence got explicitlyignored in/atour schools[quote instructor>students:"dontbother'boutit"].['een/ne' ican,buthatbrab.!
 * dutchdict.[as mentiond2ep begin2009:] r1. userhostile[as chin.1s r]+2.useles[1reason im here at wt!:)3.they rprescriptivn',esp.inthe"south"patronising[asmade by som rc"paterkes"[cary that def?but oh-itssubstanderd dutch,nice label huh+althe ethnic slursihad2enduretryin2work inUtrecht,y,sotoleranttwas,nthatswhy ppl,lik'me,want theirownregionacknolidgd,inthehopeofgetin'treated asequals,n wt 'dreal-really not wade inthere,lumpin2gether,referin2the inpart politicalstuf unprofessional dict[asvandaele,quoteme onthat!]keep regurgitatin',copyinatinfinitum] inthe "good"[?]ol'days,[n]pov guarenteed[but isthat cultural bakground known??i morethanonce raised"why is brabantian,myrealnativtongue'n'thebasis4moderndutch,disalowd?"[o-hasnoholyiso-code{an'i am1 4internat.standardisation,butbasd onreason}n'wot'bout flemishsensu strictu,frisian,etc-dialects,which'v shady[political!!] borders w/languages i/general anyway['gain,does wt need2wade'inthat??], r swept underthe carpet unles like inex-yugosl.therehasbeenawarorhav somvocalproponents??]w/o ever getin'ananswer[brab]-'du like2bediscriminatedcosutalk amE,rp etc??-y,we'vfiercediscusionsboutbcms,buthatmightbeso4areason,ie. wemightbedoin'sthquitewrongi/how wedeal w/minoritys,linguisticaly andbeyond[y,imreferin2mydisability-lik'it ornot,wt aintnobubbledetachd fromtherealworld-ialsofeel inowgetsomcos startedthe aoth propernouns-thread[y,they romissions-isthat rmission??[pun intended] 'n' ask2many inpart,nnotalways knowingly,thorny qq[hows wt gonaimprove:just bythe10sth hardworking[true;)old guard or alsoby beininclusivn'say havea1000new editors/y contributing 100entrys each[as me>c myentryspl]??-n'y,thisisarant=cropd upfrustration,may i ask2pl bear w/it.:)[n'igues this'dbemovd>bp,buthen,oh,myspelin-imsuch adisgrace'n'blotch on wt blazon-ikknowordslikethat justcos'imstupid,uno..]--史凡/Sven - Pl also let me use voice-MSN/skype 2clarify as I suffer RSI and so cannot type very well! 04:56, 29 July 2009 (UTC)
 * Just tick "common gender" - or is that not what you want? (It will only appear when a language that requires it is specified, so type "nl" into the box, and then you can get it). Conrad.Irwin 19:29, 28 July 2009 (UTC)

y,butnotthere+seemscontentiousasper abov..:/--史凡/Sven - Pl also let me use voice-MSN/skype 2clarify as I suffer RSI and so cannot type very well! 04:56, 29 July 2009 (UTC) --史凡 voice-MSN/skypeme!RSI>typin=hard! 04:00, 30 July 2009 (UTC)
 * irw+ruak+ep:iread'boutDutch'>f+m[i/that order]=their solution[iwas rash'bove,tho theesenceofit stands;)--史凡 -voice-MSN/skype!me-[[RSI>typin=hard!'']] 09:12, 29 July 2009 (UTC)
 * ruak:tx4"wt:bout dutch"[tho i object2that designation!!]-ineverfindsuch expl.pp. whenluking4'em:/
 * http://en.wikipedia.org/wiki/Dutch_dialects#Flanders
 * i'dlike2alsobe abl2giv'inmyown language so itgetsdocumentedu no-c afmotten+how2make acategory4it pl?[as ic no other solution4now2ad mynativspeak2wt!!]

:lang
CSS' built-in  selector is not now supported by MSIE. Am I correct in supposing that if and when it is supported by whatever browsers then comprise most of the market (or whatever supermajority we're comfortable with), we'll be able to get rid of (most of) our script templates (including Xyzy)? — msh210  ℠  17:28, 27 July 2009 (UTC)
 * I doubt it, given that it's actually per-script that we want to change font, and there is no one-to-one mapping between the two. Conrad.Irwin 10:37, 1 August 2009 (UTC)

I'd say yes and no—we should eventually use lang selectors as the primary method of formatting languages and scripts, but it is currently some script templates which insert lang attributes. Certainly the language attribute is where this information lives in a web page. But don't hold your breath until MSIE 6 and 7 are gone—we'll need a supplementary class name to support that shit for a long time.

Our whole optional brackets framework for labels is a broken mess, and I fail to see the reason for a non-standard "face" mechanism, so some significant changes are still needed. —Michael Z. 2009-08-01 15:43 z

dab/mul=?
--史凡/Sven - Pl also let me use voice-MSN/skype 2clarify as I suffer RSI and so cannot type very well! 04:35, 29 July 2009 (UTC)
 * Read 's documentarion. These parameters are very rarely useful. Conrad.Irwin 07:45, 29 July 2009 (UTC)

tx![hard2find bymyself..
 * creed:iget'pl improv gloses'again..:/[hapens~30%when/after i ad 'tr-box'+save2an entry--史凡 - voice-MSN/skype! I'v RSI > typin=hard!!:('' 09:04, 29 July 2009 (UTC)
 * The main problem was there was a space " " after, which caused it not to find it (I will fix this, it is a bug), the other problem was that you missed out the parameter to - which is not optional. Conrad.Irwin 20:45, 29 July 2009 (UTC)

i1.just hadthepipe|'there[as only1def]which ithought workdbe4,then itook it/thepipe/out tryin2getit2work-tx4carin!!:D--史凡 -voice-MSN/skype!me-[[RSI'>typin=hard!'']] 02:58, 30 July 2009 (UTC)
 * itdont lik'the/aspace after-top|xyz}}either>'du fixit pl?--史凡 >voice-MSN/skypeme!RSI>typin=hard! 13:54, 30 July 2009 (UTC)

{LSJ}
Now there we have a nice template, but something is going wrong there: it doesn’t substitute the parameter. Why? See ἰῶτα. Also, is there a trick to pass parameters to Special:ExpandTemplates? H. (talk) 08:20, 29 July 2009 (UTC)
 * See Atelaes' fix. The issue was that, because the "i)w=ta" contains an equals sign, it thought you were giving it the named parameter (like  in other templates). Conrad.Irwin 20:00, 29 July 2009 (UTC)

i/transl-section:
where2find thatlist ofwords so2helpout?--user:史凡 voice-MSN/skypeme!RSI>typin=hard! 09:14, 30 July 2009 (UTC)
 * It is Category:Translation_requests_(Dutch), for some reason I don't understand this category has been classified as a "hidden category" which means it won't show up on pages unless you go to Special:Preferences -> Appearance -> Andvanced Options and tick "show hidden categories". (Why on earth people want to hide categories, I do not know). Conrad.Irwin 10:36, 1 August 2009 (UTC)

title: Wiktionary:Grease pit/2009/July


text: dinamoj

title: dinamoj


text: dinamon

title: dinamon


text:
zeur

Etymology 1
From.

Noun

 * 1) a (female) sour or whiny person

title: zeur


text: dinamojn

title: dinamojn


text:
dinami

Etymology
From.

Noun

 * 1) force, power

title: dinami