Definition from Wiktionary, a free dictionary

Start a new discussion

A grease pit

Welcome to the Grease pit!

This is an area to go with the Beer parlour and the Tea room. Its purpose is specifically for discussing the future development of the English Wiktionary both as a dictionary and as a website.

It is a place to discuss how to solve technical problems such as templates, CSS, JavaScript, the MediaWiki software, extensions to it, the toolserver, etc. It is also a place to think in non-technical ways how to make the best free open online dictionary of all words in all languages.

It is said that while the Beer parlour is a place for people from all walks of life to talk about politics, news, sports, and picking up chicks, the Grease pit is a place for mechanics, engineers, and technicians to talk about nuts and bolts, engine overhauls, fancy paint jobs, lumpy cams, and fat exhausts. That may or may not make things clearer... Others have understood this page to explain the "how" of things, while the Beer parlour addresses the "why".

Permanent notice

• Tips and tricks about customization or personalization of CSS and JS files are listed at WT:CUSTOM.
• Other tips and tricks are at WT:TAT.
• Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with "tips-n-tricks" are to be listed here as well.
  
  

[edit] March 2009

[edit] Wiktionary for automated lookup of translations and synonyms

Hi, I'm building a software which needs to look up information about words and I'm not sure if Wikitionary is the right source for it.

It's not a dictinory-like software for users specially interested in words. Think of it like a search engine where the user enters a word like dog and it asks him if he means an animal or a morally reprehensible person and may also search for hound, canine or cad, bounder, blackguard, fool, hound, heel, scoundrel depending on his choice. It should also offer translations, e.g. seach for the german words Hund, Köter, Töle automatically. It's not excactly what I am building, but it's the easiest way to describe my needs, so please don't debate if it is reasonable to build this piece of software...

So my question is: Do you think wiktionary is the right source for that kind of information? Are there any other digital dictionarys which may be better suited to that problem? If wiktionary is the right source, are there any APIs that are recommended for those lookups and give me structured output in XML, or should I just get the unprocessed wiki text and parse it?

thanks in advance for your answers, Prauch 13:42, 3 March 2009 (UTC)

I'm afraid Wiktionary isn't quite there yet (though we're working on it, and you'd be welcome to help). It sounds like WordNet would be more suited to your needs, at least in terms of synonyms. You could then try to integrate that with the translation data from Wiktionary, I suppose. -- Visviva 14:25, 3 March 2009 (UTC)

Thanks, that's looking very promising. Too bad that WordNet is only available in english, while Wiktionary is multilingual. Maybe I have a try at your advice to combine the two. Prauch 10:18, 5 March 2009 (UTC)

I'm also wanting to get some of the wiktionary data into a database (I'm working on a word quizzer as a hobby project) and am wondering if there are any good parsers out there. If not I'll write my own, but I'd rather use one that's out there already if possible. Could anyone let me know how people are currently doing this? Thanks in advance. --Gyroidben 06:10, 22 August 2009 (UTC)

I have some parsers, and I have access to a particularly good one (in python) for Translations written by User:Polyglot (who seems to be afk at the moment) which, although not quite finished can extract translations from many of the Wiktionaries. I have some guess-work parsers that extract translations (python), synonyms and derived terms, and some methods to determine whether definitions are form-of (awk/perl) or not (all used in the indices). If you let me know what you're interested in doing, I'd be very happy to help - mapping dictionary data to a relational database is something I've tried and failed at several times - my latest Idea was to have a go using Neo4J which is a graph database, but I haven't had the time yet. (While the simple stuff is reasonably easy, a lot of the annotations I feel we should have structured too end up exploding in size). Conrad.Irwin 21:07, 22 August 2009 (UTC)

Cool. I'm interested in getting as much of the data out into a database as possible. I'd rather go with a conventional database rather than Neo4J, since I don't have any experience with that. A few months ago I made a simple parser for the dewiktionary xml dump which worked by simple pattern matching but wasn't very robust and got stumped on a significant fraction of the words. I thought this time I'd like to try something that was a bit more reliable and could be easily extended to different languages. It sounds like there's nothing out there already that does exactly what I want so I'll have a crack at it myself. Do you wiktionary guys have a preferred site to host code? If not I'll default to code.google.com. I'd be interested in seeing any of the parsers you've got and, if the authors don't mind, building upon them. Are they available online? I'll send you an email with my email address. Cheers, Gyroidben 19:35, 23 August 2009 (UTC)

I think all the stuff I use for indexing, which includes some guess-work translation extraction is at http://jelzo.com/indexing.zip and a checkout of the svn repository containing Polyglots stuff and some other misc wiktionary stuff is at http://jelzo.com/svn.zip . There's also User:Conrad.Irwin/parser.js, which deals mainly with the HTML parsing instead of wikitext, but only at a high level. It's all one huge mess, so you may be better writing your own. Conrad.Irwin 22:38, 23 August 2009 (UTC)

Thanks a bunch. Will let you know when I make some progress. Gyroidben 03:05, 24 August 2009 (UTC)

[edit] Converting Wiktionary data to MDF/Shoebox format

Has anybody worked on converting slices of Wiktionary into MDF format? I vaguely recall somebody mentioning something about this, but can't remember where it was. I was thinking of doing this, mostly to take advantage of that sweet Lexique Pro interface.[1] Seems like a great deal of reprocessing will be required, particularly where templates are involved, but it should be doable... -- Visviva 06:12, 5 March 2009 (UTC)

For what it's worth, many MDF codes don't work in Lexique Pro. I don't remember all the details since it's been about a year that I fiddled with it (I was doing conlanging at the time), but I doubt it'd be easy to automatize it. Circeus 04:23, 13 March 2009 (UTC)

Well, my initial test on the Italian-English slice of Wiktionary went OK, except that Lexique Pro insisted on inserting question marks as spacing characters between the headword and the definitions (very weird and unsatisfactory; can't figure out why that happened or how to make it stop). However, I was only using definitions and POS's. You're probably right that anything more advanced would run into problems.

Lately I've been looking at the LIFT XML format as a better alternative. There aren't many applications that support it natively (aside from the 3.0 beta of Lexique Pro, which seems to have all the same issues as the stable version), but there are lots of generic XML parsers, so if Wiktionary data could once be ported to LIFT (even imperfectly), it would be trivial for downstreamers to extract specific information of interest. Haven't yet found the time to make a serious attempt at this, though. -- Visviva 10:29, 13 March 2009 (UTC)

Usually it's an anon wondering why we do things the way we do, then throwing up their hands and leaving, thinking our little project won't get anywhere useful. DAVilla 04:43, 23 March 2009 (UTC)

Generally, the reason we use mere wikitext and templates can be summarised in saying that using a "proper" dictionary information encoding format would increase the complexity of even a simple entry above and beyond what the average wiki user is willing to go to. Plus we'd still need to figure a way to convert between that and wiki markup, or have a MediaWiki extension made. Circeus 14:18, 23 March 2009 (UTC)

[edit] LST limits?

Hi all,

Does anyone know what the limits on the proper use of Labeled Section Transclusion are, particularly how many labeled sections it is wise and/or possible to have on a page? I'm wondering specifically how far I can go with something like User:Visviva/Linkeration (where the relevant section is transcluded in the edit-intro when you click on the "edit" link). How many sections of this kind can there be on one page before the burden on the server to process the page becomes unacceptable, or the extension just stops working? Any guesses?

I glanced over mw:Extension:Labeled_Section_Transclusion and its talk page, but didn't see anything informative. -- Visviva 18:42, 6 March 2009 (UTC)

In answer to my own question, whatever the system limit is, it is quite high; even a 600-KB page with hundreds of labeled sections is processed smoothly. And I suppose, assuming the extension uses a regex match or similar, the server load would actually be minimal (less than rendering the source page in the first place). Nothing to see here, move along. :-) -- Visviva 03:58, 8 March 2009 (UTC)

I wouldn't expect any particular limit on the page with the tagged sections, those tags have no effect on the page itself when rendered, so just disappear during parsing. On the page doing the transcluding, I'd expect the usual 2Mb limit to apply. Robert Ullmann 14:20, 12 March 2009 (UTC)

It does do a regex on the "target" page (which is why generating the section tags with #tag or other templates doesn't work). For the gory details look here. The code is pretty fragile, you have to get the section tags just right. All of which is to say that what you are doing is perfectly reasonable (:-) Robert Ullmann 14:28, 12 March 2009 (UTC)

[edit] Hidden content in Navframe's

In an effort to get collapsible boxes to "play well" with right-hand side elements, I removed the 'style="clear:both"' attribute from the div tags in some collapsible box templates. They predictable then, shared the width with R-side elements. The problem is that these boxes aren't scrollable, so that when content is wide relative to the usable area, some content is hidden and unretrievable. This was always a problem, but now it's more of a problem since sharing the width with R-side elements means less width for the content frame. Is there a good solution to this? Can we make these boxes scrollable? I don't think the final solution should be to insert the 'clear' styles again as this display problem will still affect people with small displays and pages with really wide tables (though this can be mitigated by re-formatting tables), plus we'd leave many pages unsightly if the collapsible boxes and R-hand sides can't share the page horizontally. --Bequw → ¢ • τ 21:24, 7 March 2009 (UTC)

Can you post an example? AFAICR, when I happen to have the browser window set very narrow, the nav content just wraps. -- Visviva 04:01, 8 March 2009 (UTC)

It's noticeable when there's a table in the box. See circumvenio where there's not much to wrap, so when it get's shrunk it just clips content. For boxes that share the width with right-hand side elements, see for instance botar with the right-side ToC preference. There were more obvious examples with the Latin conjugation boxes before EP put back in the 'clear' style attribute. --Bequw → ¢ • τ 05:05, 8 March 2009 (UTC)

I think I've got something that works. I've added the style "overflow:auto;", and it seems to allow the navframe to scroll. To see the difference, alternate expanding each of the conjugation templates below. The second one should allow you to scroll right to see the hidden content, while the top one won't.

Wikipedia has an article on:

Grease pit

Wikipedia

It works with for my setups (IE 7, Firefox, and Chrome on Vista), does it not work for anyone? Assuming this works, would this be useful to add to all the collapsible boxes, so that no content is ever hidden? --Bequw → ¢ • τ 04:08, 12 March 2009 (UTC)

Yes, while thinking about it in the middle of the night (I don't get normal sleep since a drug given to me years ago...) I realized that the behaviour noted must mean that there is an "overflow:hidden;" somewhere, and there is (was). I've fixed the style sheet, so they should all work properly (probably breaking your example ;-) It ("overflow:auto;") should not be in individual templates. Robert Ullmann 14:10, 12 March 2009 (UTC)

(Oh, and just for the record: I'm the one who introduced this bug in the first place ;-) Robert Ullmann 14:14, 12 March 2009 (UTC)

[edit] automated adding of pinyin to Chinese entries

I have noticed there is heaps of work to do regarding the Chinese entries and perhaps not so many editors adding; so perhaps it would be good to focus on what computers/programs cannot really do, like adding definitions [while they can be imported too, that wouldn't still provide present-day words, unless somebody would donate his or her book, and good books are hard to find anyway.]

Once say a transliteration is provided, the corresponding IPa can be created automatically [not that I would know how to practicallydo it, but I do can think and understand what computers can do], which would work the other way too, only the transliteration is easier to giv in. Actually, already from the characters, a computer could make an educated guess about the transcription systems'specific forms, apart from characters which have several pronunciations, but still he could guess from context, in the opposite way say mypinyin input system for Chinese characters works

The reason I ask is that as a newcomer, having spent substantial amounts of time. looking at the wiki code, it is a really pains staking effort to even just create one single entry, even with the simplest of entries. likesay for a country name, as I did for a gabon[Chinese entry, layout was improved by an experienced Wikipedian

A related thing would be to have a bot adding things like the animated stroke order diagrams , which are a tremendous help to people starting to learn Chinese[So that's one I am not asking for myself]-- I recognized the corresponding wikicode, it's relatively straightforward andsimple, but I really don't think. Especially me with my RSI inflicted arms should even start adding that template to 10,000 character entries or so.

as they say in Chinese. I'm throw in a "brick" crude in tha way of anot refined/inperfect remark in the hope of getting back JAde from people more knowledgeable with computers than I am smiley

I do feel that IpA is one of the single most most helpful tools learning a new language, and often overlooked and or presented in a confusing way 'n here once again wictionary could make such a difference!! Thank you in advance219.69.81.128 03:56, 10 March 2009 (UTC) I somehow got logged out, sorry史凡 04:00, 10 March 2009 (UTC)

the same could be done for Japanese and Korean from which I do would benefit IP a wise

giving in Chinese entries, nnumberd pinyin. I could givin/input with my speech recognition; the version of it diacritical signs I cannot, and it is quite cumbersome to do the latter in my search mask. ; after having giving in each special symbol I have to again click on the mask to givin the regular letters--such might not matter too much for healthy arms for me with my RSI. It pushes my arms over the edge, making the difference between potentially quite a few edits daily to just one or two to keep the pain in my arms and check. So please please, could somebody figure out a bot or macro or so to say after me having giving in the numberd pinyin have the regular pinyin and IPA appear? [. My speech recognition right nownow works halfway decent, it's almost a breeze geving diz'in/dictateing thissmiley]史凡 16:56, 11 March 2009 (UTC)

[edit] [[foo#bar|]]

Unless my memory is playing tricks on me at one time [[foo#bar|]] could be used as a shortcut to enter [[foo#bar|foo]] (foo). Now [[foo (bar)|]] works as a shortcut for [[foo (bar)|foo]] (foo), but that isn't much use here on Wiktionary. If my memory is correct and it once worked, anyone know why support for [[foo#bar|]] was dropped? It certainly would be a less burdensome to the server alternative to {{l|bar|foo}} in many instances where {{l}} is being used primarilly to ensure that both foos are identical. (For those not aware of this trick, if one uses [[foo (bar)|]], [[foo (bar)|foo]] is what is saved in the wikitext.) Carolina wren 02:34, 20 March 2009 (UTC)

I thought it was requested but never implemented (the feature request I read, if memory serves, asked initially that [[foo#bar|]] was expanded into [[foo#bar|bar]] (again more useful on the 'pedia) but this didn't happen because elsewhere the other way round would be preferred. Conrad.Irwin 15:47, 20 March 2009 (UTC)

Yes, see bugzilla:845 (and also bugzilla:14734, bugzilla:17675), the section anchor was the preferred display, not the article name. Robert Ullmann 17:33, 20 March 2009 (UTC)

[edit] Bug: case translation in search box

If you type WT:RFD#cooperation into the search box, you are taken to the expected subsection, but if you type wt:rfd#cooperation, you are not. In converting wt:rfd to WT:RFD, the search box also (incorrectly) capitalises the anchor to COOPERATION. Equinox ◑ 15:37, 20 March 2009 (UTC)

Yes. But can't be fixed, as the UC: string function applies to the whole string. If this particular case is irritating, you might create WT:rfd to redirect to the same target. Robert Ullmann 16:59, 20 March 2009 (UTC)

Re: "But can't be fixed, as the UC: string function applies to the whole string.": Searching uses the UC: string function? —Ruakh_TALK 21:13, 20 March 2009 (UTC)

Um, assuming that it is the result of autoredirection from the "didyoumean" generated possibilities, via the javascript. But it did say "the search box" ... I was thinking of http://en.wiktionary.org/wiki/wt:rfd#cooperation but that in fact loses the section link (!)

Yes, the search function tries case as given, all lc, all uc, initial cap, and title case (in two variants), but pays no attention to treating a section link differently. You might add it to bugzilla. Robert Ullmann 08:08, 22 March 2009 (UTC)

Gory details: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/SearchEngine.php?revision=47776&view=markup Robert Ullmann 08:31, 22 March 2009 (UTC)

[edit] when a page needs attention by someone versed in a particular field

It would be nice to have a way to say "this needs attention from someone who knows [e.g.] mathematics", much as we have {{attention}} to say "this needs attention from someone who knows [e.g.] French". Doing it by categories, as we do it for languages, is unwieldy at best, as there would be numerous such possible categories (shall I keep an eye on the math category? the topology one? the algebra? arithmetic? geometry?). It would be nice to have some other solution, though. Perhaps this is one: Add {{{topic}}} parameter to {{attention}}, and have a bot list on some page all the pages so tagged, along with what they're tagged with, arranged by topic, with the topics as headers, and with FORCETOC set. This will enable people to galnce down the list to see what's needed. Thoughts?—msh210℠ 17:34, 20 March 2009 (UTC)

Watching a parent category would go some way toward solving the problem of numerousness. For example, Trigonometry is a subcategory of Mathematics, and Marketing (IIRC) a subcategory of Business. I don't know to what extent this is possible: whether watching a category is just like watching one page, or whether viewing alerts for all the subcategories could work. Equinox ◑ 21:20, 20 March 2009 (UTC)

I'm with Equinox on this one. Watching cats is the way to go, but it really needs to be automated by the software. There are so many categories that I want to watch, but there is no practical way to do it, other than checking related changes for each one (and I'm far too lazy to do that on any kind of regular basis). Are there any programmers who could institute such a change in the software? If this is not possible, then I'm down with a bot doing it. -Atelaes λάλει ἐμοί 22:00, 20 March 2009 (UTC)

Are we saying something like recent changes by category? That would be great. I'd sign up for a few. DCDuring TALK 22:53, 20 March 2009 (UTC)

While this is certainly off-topic, I was struck by a typo msh made, and decided to check Google to see how common it was. I put my results on Talk:galnce. Hope this isn't a problem! 75.214.219.198 (really, User:JesseW/not logged in) 22:29, 20 March 2009 (UTC)

Since there is no means of watching cats, I've effected the suggestion I made above, or something similar. See template talk:attention for more info, but, roughly, {{{topic}}}, used in {{attention}}, now adds the entry to category:Entries needing topical attention, and a bot can patrol that category (or special:whatlinkshere/template:attention) for pages that use {{{topic}}} and list the pages by topic on Wiktionary:Entries needing topical attention. A bot that can do so, using pywikipedia, is at Wiktionary:Entries needing topical attention/bot code. Since I have no permanent connection to the Internet, I cannot promise to run that bot periodically (which is one reason I posted the code: so others may run it) — but I do hope to run it from time to time. Please fix anything you see wrong, or that can be better, of course. (That's the other reason for posting the bot code.)—msh210℠ 20:53, 25 March 2009 (UTC)

I've added the topic= parameter to the templates rfc, rfv, rfv-sense, and rfdef, in addition to attention.—msh210℠ 19:24, 1 June 2009 (UTC)

[edit] edit toolbar problem

The customized edit toolbar has a problem with its enhancement for BOLD:

I suspect was was intended was that it would produce when nothing was selected:

'''{{subst:PAGENAME}}'''

but instead it is substituting PAGENAME too soon, producing for this page:

'''{{subst:Grease pit}}'''

which does nothing as the parser is apparently smart enough to avoid this basic level of recursion. Carolina wren 04:29, 24 March 2009 (UTC)

[edit] Overlapping content in Chrome

While trying to adjust "1" (removing a large blank space shown by Firefox and Chrome), I came across a rendering inconsistency that became apparent in another page of the page. I made a simple example here that uses just a right-hand side image and a table that specifies a width of 100% (like {{top3}}). IE 8 and Firefox both put the table below the image, whereas Chrome puts it behind the image (covering up content). Neither is great, but arguable Chromes presentation is more problematic (I'm not sure if one layout is "wrong" or not). I've seen this problem on other, "mature" pages with lots of content. Is there a simple fix? Why do the {top*} templates force a width of 100% (which causes the problems)? Is it just so that the columns of one table match up with others vertically? --Bequw → ¢ • τ 05:14, 25 March 2009 (UTC)

[edit] April 2009

[edit] Need an option so that searching is not so sensitive to accents

I think it would be extremely useful if an option could be set so that accent marks on letters are ignored when searching for a word.

For example if I type in "elementaire" in the search bar I will receive no search results even though I am intending to search for "élémentaire".

I think for many people (particularly English speakers learning a language) it can be much easier for them to type without accents, and it can be a huge annoyance that the search box is so sensitive to accents.

All the best.---

I believe our new search is better, but we have to wait until the admins enable it here - it's already on the English Wikipedia if you want to test it. Conrad.Irwin 21:36, 2 April 2009 (UTC)

[edit] older changes to watchlist

, I wasn't here since March 16 and would like to see the changes tothe edits I madejust before leavin as I learn a lot from them-- is there a way2 See them?--史凡 10:43, 3 April 2009 (UTC)

• Just click on "my contributions" near the top right. Seems to be edits to the beer parlour. SemperBlotto 10:47, 3 April 2009 (UTC)
  • Or do you mean subsequent changes made by other people following your edits? SemperBlotto 10:49, 3 April 2009 (UTC)

If you click on the "all" link in the watchlist options box, it will show changes for the last 30 days. So it will go back to March 4th as of now. Robert Ullmann 11:15, 3 April 2009 (UTC)

[edit] Talk:opposable

At Talk:opposable, there's an ominous looking "loop detected" flashing about on the page - any idea why it doesn't just show {{context}}? --Jackofclubs 15:08, 5 April 2009 (UTC)

:Not at me. I use FF/Win. I have a few misc. Wiki prefs, too. DCDuring TALK 18:17, 5 April 2009 (UTC)

[edit] {context}

Context is acting all screwy this morning, complaining about loops it never complained about before. Did the MediaWiki software get an update this morning to cause this? — Carolina wren discussió 15:38, 5 April 2009 (UTC)

Should now be fixed. See next two sections. Conrad.Irwin 16:34, 5 April 2009 (UTC)

[edit] “Template loop detected: Template:context 1”, whatever that means…

Seems to be causing problems, as, for example, here and here. Just FYI. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 16:18, 5 April 2009 (UTC)

• Also happens with {{context 2}} - see dog as an example. SemperBlotto 16:27, 5 April 2009 (UTC)

Should now be fixed. see next section. Conrad.Irwin 16:32, 5 April 2009 (UTC)

[edit] Recursive templating

Thanks to recent software upgrades the trick of using redirects to get around the recursion filter no longer works. I have fixed Template:context, if there are other recursive templates they need fixing too. Conrad.Irwin 16:31, 5 April 2009 (UTC)

It is insane (and utterly incompetent from a professional POV) how "they" break things as if it doesn't make the slightest difference that we have to scramble to fix them. With no notice whatsoever. And this was not a "trick": it is (was) the standard, recommended method of doing various things. (see meta:Help:Template#Repetition_within_a_page.

May (as would be typical) be a side-effect of some "helpful" change to the code. Some of the people making changes seem much more concerned with gratuitous re-factorings and cosmetic changes that then break things right and left. Robert Ullmann 13:08, 9 April 2009 (UTC)

Nope, on asking in #wikimedia-tech I was told that this was done deliberately. I believe they found a way to do infinite recursion with it, and so decided it wasn't so much fun anymore. Conrad.Irwin 13:34, 9 April 2009 (UTC)

(the point of having numbered redirects was so that it couldn't be infinite?) That is then much worse: they broke existing function on purpose without announcing it in advance? If they worked for me their asses would be fired. It really is appalling sometimes. What do they propose replacing it with? (never mind, very silly question)

I'm not aware of anywhere else we are using this. But the other wikts that use {context} are going to be broken, and justifiably pissed. And other non-WMF wikis will break as well (of course, if they are smart, they avoid updates as long as possible ;-) Robert Ullmann 13:53, 9 April 2009 (UTC)

[edit] use file: namespace in {audio}?

I think it's safe to move from media: and image: for this template now. Circeus 18:42, 8 April 2009 (UTC)

Has been safe for a while. But do note that "image:" is not deprecated, it will permanently be an alias for file:, and note that media: doesn't mean the same thing. (;-) Robert Ullmann 13:10, 9 April 2009 (UTC)

[edit] .Orya

This class should have a font size of 125%. My eyes bleed from trying to recognize the consonants, and similar scripts like .Deva and .Beng already have a font size increase. -- Prince Kassad 20:32, 14 April 2009 (UTC)

[edit] Recent changes oddity

Special:Recent changes (with patrolled edits hidden) jumps from the end of the 14th April to the start of the 16th. SemperBlotto 07:30, 16 April 2009 (UTC)

[edit] donger and entrée as Australian French?

For some reason (I assume a screw-up with {{context}}), both donger and entrée are categorized in Category:Australian French. --Jackofclubs 16:52, 16 April 2009 (UTC)

Yup. Both {{Europe}} and {{Africa}} assume a default of French and it propagates to later context markers in the series unless an explict lang=en is given. Fixed, but we now have redlink categories in Category:African English and Category:European English. — Carolina wren discussió 17:53, 16 April 2009 (UTC)

I think you could say that there is no such thing as "European English" (cf. in Quebec, what is taught is not "Quebec English", nor is English taught in Japan "Japanese English"). It's fairly safe to assume Europe follows mostly British usage. Circeus 06:03, 6 May 2009 (UTC)

[edit] Showing image

On the page Ⅎ I can't seem to show an image that works perfectly on w:Letterlike Symbols. What am I doing wrong? --Bequw → ¢ • τ 18:09, 16 April 2009 (UTC)

It was only on Wikipedia not Wikimedia commons, now it's on both. Conrad.Irwin 18:27, 16 April 2009 (UTC)

Thanks. --Bequw → ¢ • τ 19:43, 16 April 2009 (UTC)

[edit] More broken template stuff

At the top of each page I visit I'm seeing things like <centralnotice-template-wikimania_scholar> and <centralnotice-template-licensingvote> rather than the usual boxes. Is this related to the template issues above or is it something else? Equinox ◑ 22:16, 17 April 2009 (UTC)

It's a bug with mw:Extension:CentralNotice. The sysadmins will fix it eventually, one presumes. Conrad.Irwin 22:19, 17 April 2009 (UTC)

[edit] Wiktionary:Random page, worth keeping on the sidebar?

In the last week or so, I've tried using the Wiktionary:Random page function (random page by language). However, each time it fails. I recommend this link be removed from the sidebar, until it works again, as it could frustrate some users. I assume only administrators can change the sidebar and interface, right? --Jackofclubs 12:37, 19 April 2009 (UTC)

It should be gone in a minute or two (when the message cache purges the sidebar). Conrad.Irwin 20:31, 19 April 2009 (UTC)

[edit] Latin irregular verb conjugation

Was looking over a few irregular verbs for a general idea of the Latin language and came across do#Conjugation, and was wondering why Firefox renders the tables with something like this:
style="background: rgb(251, 252, 228) none repeat scroll 0%; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"
It isn't in the wiki-text... Also, should this be templated and/or converted to CSS? -- 203.171.195.168 18:07, 21 April 2009 (UTC)

Default style aren't in the wikitext, they're in the site's higher css material. Furthermore I'm fairly sure some of those are Firefox internal default css (yes! Firefox has an explicit default css it applies to everything, and you can actually edit it IIRC). Circeus 19:55, 21 April 2009 (UTC)

Yes but CSS is done separately, they shouldn't be editing the page source (?). I think Wiktionary is configured to generate differently for Firefox. -- 203.171.195.168 20:09, 21 April 2009 (UTC)

It's not in the page source. I'm guessing that you copied that from a DOM inspector (or the like)? If so, you're apparently seeing the CSS that Firefox is providing, not anything that Wiktionary is sending it. —Ruakh_TALK 20:18, 21 April 2009 (UTC)

Ah you're right. I didn't know it did that. Thanks -- 203.171.195.168 20:27, 21 April 2009 (UTC)

[edit] Snippets in search results

I've noticed that when searching for a word in Google or Yahoo, you have to click on the link to get the definition in most dictionaries. It would be much more convenient to have wiktionary somehow let the search engine put the definition in the snippet that comes with the listing.

Using the word transcendent as an example, Google and Microsoft fail-

http://www.google.com/search?q=transcendent

http://search.live.com/results.aspx?q=transcendent

Yahoo/Altavisa do a reasonably good job-

http://search.yahoo.com/search?p=transcendent

http://www.altavista.com/web/results?q=transcendent

I don't know if it's technically possible, but it would be nice if Wiktionary gave the search engines some kind of hint of what to include in the listings.

[edit] IP block exempt

I see that admins now are able via special:userrights to set someone as IP block exempt (i.e., that he is exempt from IP blocks, as admins and I think bots are). This is, I think, new(ish). Just thought I'd point it out here.—msh210℠ 21:25, 28 April 2009 (UTC)

[edit] Wikisaurus bot idea

An idea that occurred to me: how hard would it be to make a bot that would go through the Wikisaurus: namespace and add the appropriate template to terms in the "synonyms" section(s)? Circeus 23:43, 28 April 2009 (UTC)

[edit] May 2009

[edit] Must have.

Dictionary of Americanisms, 2nd ed. enlarged. bd2412 T 03:42, 6 May 2009 (UTC)

[edit] Green links on Spanish adjectives

Hi. When I click on the green links in a Spanish adjective entry, the new entry forms as a noun. Am I doing something wrong? -- ALGRIF talk 14:59, 8 May 2009 (UTC)

I think fixed this problem yesterday. If you clear your cache (ctrl+shift+F5) it should work correctly again. Conrad.Irwin 15:28, 8 May 2009 (UTC)

[edit] Error on page

Lately, all Wiktionary pages give me a little yellow triangle at the bottom left (IE7), Clicking on it gives this error message - Line:1058 Char: 17 Error: Expected identifier, string or number Code: 0 - Any ideas? SemperBlotto 09:58, 11 May 2009 (UTC)

Should be fixed now (clear your cache (ctrl+shift+F5)), yay for internet explorer having it's own Javascript syntax rules... (though I should have spotted the problem by eye). Conrad.Irwin 14:30, 11 May 2009 (UTC)

Thanks. By the way, I'm back on IE7 after a brief use of IE8 - paging went through the roof when I had multiple tabs open (typically two Wiktionaries, it.Wikipedia, two Italian dictionaries and a Google). SemperBlotto 07:06, 12 May 2009 (UTC)

[edit] contextification request

Can someone who knows how please convert template:no longer productive to a context template?—msh210℠ 19:13, 21 May 2009 (UTC)

Thanks for asking for it. DCDuring TALK 19:49, 21 May 2009 (UTC)

Er, you're very welcome, if there's, indeed, anything to thank me for. (?)—msh210℠ 19:53, 21 May 2009 (UTC)

Thank, you, Ruakh.—msh210℠ 19:47, 21 May 2009 (UTC)

Thanks for doing it. DCDuring TALK 19:49, 21 May 2009 (UTC)

Oh, and now, after all that, I just realized that it was one, and I could have simply reverted.—msh210℠ 19:53, 21 May 2009 (UTC)

Well, the last time it was a context template, {{context}} didn't yet have the tcat= parameter, so if you'd just reverted, {{no longer productive}} would have ended up in Category:Topical context labels. There's been a full iota of progress in the past year. Maybe even 1.5 iotae. :-)   —Ruakh_TALK 20:42, 21 May 2009 (UTC)

[edit] Bad links to Wikipedia -- bot run.

I have come across several links to Wikipedia where the Wikipedia article in question does not exist. I don't think there is a predefined script for removing these in PWB but a custom one shouldn't be too tricky. - TheDaveRoss 22:49, 24 May 2009 (UTC)

[edit] {{topic cat}}

Why do Category:nl:Indonesian_derivations and Category:th:Indonesian_derivations add a category like Category:nl:Indonesian_language? After all, it is not needed and Category:th:Chinese_derivations and similar templates do not add it. —Stephen 13:59, 28 May 2009 (UTC)

That's a good question. {{topic cat parents/Chinese derivations}} has explicit code to check if the current language is English, and adds its caller Category:Chinese language iff so; but {{topic cat parents/Indonesian derivations}} uses a helper template that doesn't draw that distinction. I suppose we should simply remove Indonesian language from {{topic cat parents/Indonesian derivations}}, and manually add Category:Indonesian language to Category:Indonesian derivations? —Ruakh_TALK 16:08, 28 May 2009 (UTC)

I put explicit code checking into {{topic cat parents/Indonesian derivations}}. It seems to be working okay now. —Stephen 22:51, 28 May 2009 (UTC)

[edit] June 2009

[edit] 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)

[edit] 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)

[edit] {{nl-verb}}

This was redirected to {{nl-verb-conj}}, 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 {{nl-verb}} 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)

[edit] {{fr-infl-noun}}

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)

[edit] 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)

[edit] 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: {{lookfrom}}. 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)

[edit] 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:

1. {{etyl|he}} → Hebrew
2. {{etyl|heb}} → Modern Hebrew
3. {{etyl|hbo}} → Classical Hebrew

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)

I think the consensus has been to treat it as one language for {{heb}} purposes at least: I'm not sure about for {{etyl|heb}} 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 {{VL.}} or {{NL.}} to specify temporal periods of the language. --EncycloPetey 19:08, 17 June 2009 (UTC)

That approach is obsolete, as of February, when Bequw edited {{etyl}} to add support for {{etyl:…}}. We should replace {{VL.}} and {{NL.}} with, say, {{etyl|la-x-vulgar}} and {{etyl|la-x-new}} (though I'd welcome your thoughts on the naming). Similarly, we could create {{etyl:he-IL}} and {{etyl:hbo}} to support what Doremítzwr describes. (Note the he-IL rather than heb; he and heb 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)

[edit] 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 {{langcatboiler}}. 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)

[edit] Category:English verbs which are their own past participle

Can't this be populated automatically by {{en-verb}}? Add something like {{#if:{{{3|}}}|{{#ifeq|{{{4|{{{3}}}}}}|{{PAGENAME}}|[[Category:English verbs which are their own past participle]]}}}} 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 {{homophones}} 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 {{#ifeq:{{{lang|en}}}|en|[[Category:English homophones]]}}, 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)

[edit] 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)

[edit] 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 clear your cache (ctrl+shift+F5) 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)

[edit] 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)

[edit] 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 '''-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)

[edit] 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)

[edit] Shortcut to Wiktionary:About Serbo-Croatian

Shouldn't the shortcut to Wiktionary:About Serbo-Croatian be WT:ASH? --Daniel. 08:27, 25 June 2009 (UTC)

Right, corrected. --Ivan Štambuk 12:38, 25 June 2009 (UTC)

[edit] 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.

[edit] Problems with section-linking when using Template:temp

When {{temp}} 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 {{temp}}? 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 {{chiefly}} > {{mainly}} and {{markedly}} > {{very}}: [2]). † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 12:16, 25 June 2009 (UTC)

Seems to be fixed when you clear your cache (ctrl+shift+F5). 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 {{temp| or {{template| in the edit summary, and changes them to plain {{. 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)

[edit] 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)

[edit] 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 {{attention|grc}} 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)

[edit] 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)

[edit] 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 #editpage-copywarn{display:none!important} to their monobook.css. (Untested, but should work.)​—msh210℠ 15:24, 6 July 2009 (UTC)

[edit] Miscategorisation of præserves

Does anyone have any idea why the entry for præserves 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: {{first-person singular of}}, {{second-person singular of}} and {{third-person singular of}}. 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 -(e)st forms with thou). The way that these verb forms are now categorised lumps together I abide, (thou abidest,) you [sg.] abide, and he/she/it abides in the first category, whilst listing together he/she/it abides with they abide 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. swam in the irregular conjugation of swim) and English verb archaic second-person singular simple past forms (strong-conjugation verbs (and some weak-conjugation monosyllabic verbs) suffix -est in the second-person singular simple past; e.g. tookest, thoughtest, madest, walkedest, &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 Wiktionary:Beer parlour#Verb form categories. --Daniel. 07:57, 9 July 2009 (UTC)

[edit] disclike

I'm trying to work out why this isn't categorising correctly. The syntax looks okay to me {{suffix|disc|like}}, 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] Category:Dutch_weak_verbs won't update

User:CodeCat has temporarily switched off Category:Dutch weak verbs from appearing in pages with the {{nl-verb-weak}} 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 {{nl-verb-weak}} 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)

[edit] 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)

[edit] 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 = &#x0 651;&#x0 64E; • shadda+kasra = &#x0 651;&#x0 650; • shadda+dhamma = &#x0 651;&#x0 64F; (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 {{ar-dia}} 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 + M₁ + M₂ should be the same (look the same when rendered) as L + M₂ + M₁
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 יְרוּשָׁלִַם (y'rushaláim), “‘Jerusalem’”) into the incorrect יְרוּשָׁלִַם (y'rushalíam). 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 bugzilla: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 Mzajac (talk • contribs), 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 <span class="Arab"> 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)

[edit] 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)

[edit] 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)

[edit] 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)

#searchmenu-new-preload { display: none; }

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

[edit] Numbering of definitions

war#Noun and rhubarb#Noun 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)

[edit] 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 {{rel-top}}, {{rel-mid}} and {{rel-bottom}}. --EncycloPetey 21:29, 14 July 2009 (UTC)

[edit] 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)

[edit] Missing categories

• [[Category:Spanish verb affirmative forms]]
• [[Category:Spanish verb negative forms]]

What actually are these? I guess they come from a bad use of <includeonly>, 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 Wiktionary:Beer parlour#Verb form categories. --Daniel. 09:43, 15 July 2009 (UTC)

[edit] Template:see-conj

In a similar way to {{trans-see}}, I just created mettre au monde which uses the conjugation of mettre, something like {{see-conj|mettre|lang=fr}} would be good, and would link to mettre#French. 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===
* see {{term|mettre|lang=fr}}

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)

I think "see mettre" is not quite clear enough and should be something like "Conjugated forms are those of mettre, with au monde 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 {{trans-see}} 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_TALK 01:34, 16 July 2009 (UTC)

[edit] 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 edittoolscharsubset cookie exists and is nonzero — 0 being the index of "Templates", which is set by default — and if not, it sets it to 22, 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 0 by default — we should leave it blank by default, and just treat blank the same as 0 — 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 findEdittoolsSection function, and the addOnloadHook block underneath it. It should be obvious how to customize it for whichever sections you want to copy up.)

—Ruakh_TALK 03:48, 20 July 2009 (UTC)

Thanks.​—msh210℠ 19:51, 20 July 2009 (UTC)

[edit] {{weather|lang=zh-tw}}

wotdoesthis do pl?tw here4trad.?

• ps:{{tt}}=?--史凡 - Please also use skype: sven0921 as I suffer RSI and thus cannot type very well! 18:16, 20 July 2009 (UTC)

{{weather}} 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 {{context}} tags with the same content, say "operations", eventually a category and the associated specific context template {{operations}} 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)

[edit] 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 [[w: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_TALK 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. † ﴾^(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 ital= parameter to our various inflexion templates to allow for this italicisation of inflexion lines’ headwords? † ﴾^(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., helluo librorum) — they would also warrant the ital= parameter. † ﴾^(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? † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 22:28, 27 July 2009 (UTC)

I was noticing this very problem at beta#Noun where there is confusion relating to Beta. I don't think most users think to look at other capitalizations, especially after the {{also}} 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.

• 1. If we were to recognize italics in headers, would we then have to allow for attestation both with and without italics?
  2. How does this help users?
  3. 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_TALK 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

[edit] 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)

[edit] 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)

[edit] 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)

xcl is a language code for Old Armenian, defined here in the template {{xcl}}. 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)

[edit] translations

{{trans-top|}} {{trans-mid}} {{trans-bottom}} <'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 Wiktionary: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 Wiktionary: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 Wiktionary:About Dutch. —Ruakh_TALK 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)

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

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)

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)

• irw+ruak+ep:iread'boutDutch'>f+m[i/that order]=their solution[iwas rash'bove,tho theesenceofit stands;)--史凡 -[[User talk:史凡|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!!]

--史凡 voice-MSN/skypeme!RSI>typin=hard! 04:00, 30 July 2009 (UTC)

[edit]  :lang

CSS' built-in :lang 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.[3] 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

[edit] dab/mul=?

{{wikipedia|dab=creed (disambiguation)|mul=Creed}}--史凡/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 {{wikipedia}}'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 {{trans-mid}}, 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 {{trans-top|gloss of definition}} - 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--史凡 -[[User talk:史凡|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)

[edit] {LSJ}

Now there we have a nice template, but something is going wrong there: it doesn’t substitute the {{{1}}} 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 {{{i)w}}} (like {{{lang}}} in other templates). Conrad.Irwin 20:00, 29 July 2009 (UTC)

[edit] i/transl-section:{{trreq|Dutch}}

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)

[edit] August 2009

[edit] "Occuring"

I've just noticed (by searching) that there are very many entries — probably dozens — that use the misspelling "occuring" in their definitions. Perhaps somebody has a bot that could deal with these cases? (Watch out for the actual misspelling-entry occuring though, where it should remain!) Equinox ◑ 16:27, 2 August 2009 (UTC)

[edit] Jumpy page anchors

What the hell is up with the page anchors lately? Whenever I edit a section, the page loads, then my browser (Safari/Mac) jumps to about 3 lines below the heading I was editing, completely losing the context. Even though it's happened dozens of times, I still sometimes randomly scroll up and down or just sit dumbly wondering what I am looking at. This is supremely fucking annoying. Does the stupid top notice have a new behaviour again? —Michael Z. 2009-08-04 17:31 z

Could it relate to MediaWiki:Common.js?diff=6887404, discussed at #Problems with section-linking when using {{temp}}? —Ruakh_TALK 18:42, 4 August 2009 (UTC)

I don't know what that is, but I removed all instances of {temp} in headings on this page, the problem hasn't gone away on this page. If I turn off Javascript, the brokenness goes away.

Who here has control over the sitenotice? —Michael Z. 2009-08-08 03:56 z

Hm, looks like the problem probably isn't in MediaWiki:Sitenotice, but in the three javascripts which are wrapped around it. Really, some basic functionality is broken here and constantly reminding me that someone is messing with our site without sufficient testing, and without being present here. How do we remove their crap until they get it right? —Michael Z. 2009-08-08 04:17 z

I've identified the behaviour better, by loading short pages and jumping to anchors right at the top of pages. It's easier to see when my machine is slowed with a busy CPU (but just as intolerable when its not).

The Wikimedia vote notice and our site notice both show up at the top of every page load, complete with "dismiss" buttons (even though I dismissed both a long time ago). Then the page loads (which can take several seconds on these talk pages), then my browser window jumps to an anchor, and only then the site notices disappear, making the body content shorter by about 75px. So after I jump to a heading, the page contents jump up by about 75 px. Sometimes there is a noticeable flash of heading, and other times it appears to take zero time, appearing as if the anchor jump was going to a random part of the page.

I'd rather look at the advertising than have the page jump in my face every time I do an edit. How do I un-dismiss the site notices?? Please. —Michael Z. 2009-08-08 16:21 z

I use in .css: #siteNotice { display:none; } and I don't see js doing anything (dismissed or not). Mind you I think it might still be jumpy but I haven't noticed anything that was enough to bother me. Might work for you.Robert Ullmann 16:36, 8 August 2009 (UTC)

I'll try that. But that would just hide the problem from me.

Now how do we go about eliminating the brokenness? I can try deleting MediaWiki:Sitenotice, but I can't locate where the global notice text comes from. —Michael Z. 2009-08-09 01:34 z

[edit] looking for a template

Hi everyone, I am looking for the template which one uses when you are wanting to make a big change to a page and don't want to get into an edit conflict. Could someone please tell me what this is. Thank you :) L☺g☺maniac chat? 15:03, 5 August 2009 (UTC)

{{inuse}}.​—msh210℠ 17:55, 5 August 2009 (UTC)

Thanks! :D L☺g☺maniac chat? 18:25, 5 August 2009 (UTC)

[edit] {BCSM} template as a language name for Serbo-Croatian

I've created {{BCSM}} that could be hopefully used as a substitute for L2 Serbo-Croatian. Should have done this long time ago. Anyhow, some of the question for tech-savvy folks:

• Would it pose a problem to have L2 language name as a template, for the bots and stuff? I imagine that the possible fixes would be pretty much trivial..
• Would it be hard to add the customization support? E.g. by default it would list "BCS" or "Bosnian, Croatian, Serbian" or whatever we decide it would list, but by customizing monobook or WT:PREFS option it could display e.g. Serbo-Croatian? :D I assume that this might introduce inconsistency in the alphabethic ordering for the folks who do so, but that is not a big deal anyway..
• Serbo-Croatian as a macrolanguage has a reserved code {{hbs}} we might use instead if necessary. Would it be a problem with section-linking (lang=) and stuff if {{BCSM}} were used? If necessary, we could agree on using the L2 ===BCSM=== only via {{BCSM}}, and linking to actual sections via {{hbs}}. --Ivan Štambuk 23:19, 6 August 2009 (UTC)

I don't like this proposal, as it introduces an inconsistency with everywhere else on Wiktionary for no benefit I can see. I am not sure what problem it solves, and in answer to your specific points:

1. Not a huge problem, though it would be irritating, At the moment every language heading is a good enough label for that language, with BCS I'd have to add an explicit "change BCS to <something else>" if I wanted to display things to users (WT:RAND is an example of this). Alphabetic ordering would become harder, for pretty much the same reason, and if you allow its output to be customisable then people are likely to make the mistake of sorting it under the label they can see rather than the default label. The alphabetic ordering is a useful feature on pages like a with lots of languages and anywhere else (like on many categories) that we have a large list of languages.
2. Not hard, but not terribly desirable - what would be the advantage of such customization? - the people who "get offended" by whatever heading is chosen will still know that the incorrect heading is being shown to everyone else.
3. If we were to stick to using only the templates for titles and links there would be no problem, but making people stick to that is probably difficult unless they are established BCSM contributors, they won't notice or will forget that this heading is different from the other ~660 languages on Wiktionary.

Conrad.Irwin 08:14, 8 August 2009 (UTC)

Well this is a very specific case, and I think that the issues (and "issues") solved by this greatly outweigh all the potential technical and practical drawbacks. OK, let's drop the header-customization entirely.

So the only problem would be a special if-clause in the bot code to handle {BCS} when parsing the database, and people possibly forgetting that we are using a special {BCS} header.

We could also drop the template completely, and force it simply as a wikilink [[BCS]] (like we do now for some obscure languages) in the L2. Now that I think about it, I like this option the best. (we can always change it later if there is a need).

So the proposal is L2 ==BCS== (always wikilinked), with {{hbs}} language code. Thoughts? --Ivan Štambuk 10:43, 9 August 2009 (UTC)

BCS, BCSM, BDSM are all confusing for an average mortal user. We need a simpler header that will not make such user's head explode, and an agnostic one at that, not implying those languages are the same (this way it can pass the vote, unlike the "Serbo-Croatian" L2). So think, Štambuk, think. --Vahagn Petrosyan 11:54, 9 August 2009 (UTC)

How about ==Bosnian/Croatian/Serbian== L2s, and BCS in the translation tables (to reduce space usage)? It's a bit cumbersome, but it looks the most neutral to me. --Ivan Štambuk 12:02, 9 August 2009 (UTC)

How would someone looking for the Serbian translation of fox know it’s under some BCS? Not gonna work. By the way, you may be interested what dbachmann thinks of the situation (at the bottom). --Vahagn Petrosyan 13:42, 9 August 2009 (UTC)

You're killing me. How about making the Bosnian/Croatian/Serbian translation as sth like " *Serbian: see BCS ? We could generate them by a bot (or javascript?) in every translation box that has a BCS translation.

Dbachmann's comment are deeply insightful, as always. I am very glad that he started editing here again! --Ivan Štambuk 14:14, 9 August 2009 (UTC)

That may work. But are you sure BCS would be acceptable for the opposing party? I mean, c'mon, If you're putting things under one header you automatically say they are the same language, be it Serbo-Croation or BCSian. You could catch one of those nationalists and experiment on him, for starters. As sad as it is, we must convince/manipulate Ullmann’s minions to agree, otherwise they can always sabotage the vote. --Vahagn Petrosyan 14:43, 9 August 2009 (UTC)

For starters, it would be one less "genocidal term" to worry about, which appears to be hopelessly politically contaminated and concordantly manipulated by some of the opposers. The proposed policy even now does not claim or discuss anywhere whether they are "the same language" or not - it is only on formatting the 3 standards at one language header (the difference is subtle, but important because that way we evade accusations for "Yugounitarism"). As for the evidence on whether the 3 standards are one language in a non-sociolinguistic sense (Mir Harven: "languages have nothing to do with linguistics"), I've collected some testimonies by professionals that will doubtless shed some affirmative light on that issue. --Ivan Štambuk 15:06, 9 August 2009 (UTC)

I'd have thought that something like "Bosnian, Croatian, Serbian" would be more palatable than "Bosnian/Croatian/Serbian"; the former implies only that all are covered in the section, whereas the latter implies that these are three names for the same thing. (An implication which, mind you, is not accurate: even if you accept that BCS are one language, that doesn't mean that "Bosnian", "Croatian", and "Serbian" are actually equivalent names for it. English is one language, but "American English" and "British English" are not synonymous.) —Ruakh_TALK 15:08, 9 August 2009 (UTC)

L2s can be "Bosnian, Croatian, Serbian" and the translations can be separate and, yes, duplicated; but all three could point to the same "Bosnian, Croatian, Serbian" header. I can imagine this being acceptable to the opposers of the current policy. --Vahagn Petrosyan 15:21, 9 August 2009 (UTC)

That would be acceptable to me too. Duplications at the translation tables are far less of a problem than the duplications in the main namespace entries, as you just edit them once. --Ivan Štambuk 15:26, 9 August 2009 (UTC)

Plus, three translations would link to three wiktionaries (sr.wikt, hr.wikt and bs.wikt), like now. Also, if we kept only Serbo-Croation, some users looking for Croatian or Bosnian may not think of looking under "S" and go away disappointed. --Vahagn Petrosyan 15:33, 9 August 2009 (UTC)

Yay, one less problem to worry about! Now we have to wait that the vote expires so that I can rewrite the draft policy. It will be a bit weird to have categories such as Category:Bosnian, Croatian, Serbian language, but what can one do.--Ivan Štambuk 15:44, 9 August 2009 (UTC)

Why does it have to be Category:Bosnian, Croatian, Serbian language? The {{hbs-noun}} or {{sh-noun}} or whatever, could put the word automatically in all three Category:Bosnian language, Category:Croatian language and Category:Serbian language. This kind of duplication will not require any effort from you whatsoever and will show that we do not merge the languages. --Vahagn Petrosyan 16:13, 9 August 2009 (UTC)

But then we'll have to add a special case for all the other automatic-categorization templates such as context labels, {proto}, {etyl}, {suffix} etc, that would sort the lang=hbs/sh to all the 3 corresponding categories. Also, there could be some "principal" problems with adding Croatian-only words/spellings to Serbian language cat, or Serbian Cyrillic spelling to Croatian cat... Unless we add a set of special parameters (e.g. "b|c|s") that will denote which of the (standard) languages the word belongs to, which should be possible but it'll be quite annoying in practice. --Ivan Štambuk 16:33, 9 August 2009 (UTC)

[edit] Burmese

Anything in Burmese ("my") just appears as boxes; what font am I lacking? Mglovesfun (talk) 12:53, 14 August 2009 (UTC)

Quoth [[MediaWiki:Common.css]]:

    .Mymr {
        font-family: Padauk, Myanmar3, Myanmar2, Myanmar1, ParabaikSans, MyMyanmar, sans-serif;
        font-size: 130%;
        }

—Ruakh_TALK 15:11, 14 August 2009 (UTC)

[edit] Words with hyphens don't appear listed in categories?

Entry Fus-ha won't appear listed in Category:Languages under letter F. I wonder why? Anatoli 11:34, 16 August 2009 (UTC)

I figured it out, no worries. Anatoli 12:01, 16 August 2009 (UTC)

[edit] http://en.wikipedia.org/wiki/Sotavento_Islands

cansuchTRANSLATIONSbe importedfrom wp?[itsthere i/danishetc.-iwasafterthe ptWINDWARDS,word wt nohav--史凡>voice-MSN/skypeme!RSI>typin=hard! 01:11, 17 August 2009 (UTC)

Possibly, but you need to be very careful which words you try, the wikipedia interwiki is very crude and not really reliable enough to trust without another source. Conrad.Irwin 22:43, 17 August 2009 (UTC)

Exactly. For example, an interwiki link may be between a singular and a plural, or between words with slightly different meanings. This technique is safer for proper nouns such as this one, but it's not 100 % safe, especially when you don't understand the script at all. Lmaltier 21:26, 22 August 2009 (UTC)

[edit] Mapping word differences

I thought about an idea to help Wiktionary generate original research on differences in words and wondered if others have had this idea as well. Would there be a way to combine a mapping system (like m:WikiMiniAtlas) with a database (perhaps at toolserver) to produce and display word differences on a map like the one at popvssoda.com? Not only would geographic differences in synonym usage be interesting but also finding where different pronunciations or senses of a word are used. I'm sure there's more possible uses as well. If it could be designed, it would provide another way for casual users to improve the dictionary without having to edit a page. --Bequw → ¢ • τ 07:30, 17 August 2009 (UTC)

[edit] pellekes

how2NOT hav"(plural , diminutive , diminutive plural s)"displayd?--史凡>voice-MSN/skypeme!RSI>typin=hard! 10:21, 17 August 2009 (UTC)

Better now?​—msh210℠ 16:39, 18 August 2009 (UTC)

• coool,ta!:)
• etyl:somuch2learn+'dbe directlyfromLatin2,no ref.books here:/
• 'dBrab. bemade i/aCATEGORY?--史凡>voice-MSN/skypeme!RSI>typin=hard! 05:00, 19 August 2009 (UTC)
  • Don't see why not. We have other dialectical categories, such as European French (a subcategory of Regional French), British English (a subcat of Regional English), and Regional Dutch, so....​—msh210℠ 19:56, 23 August 2009 (UTC)

[edit] Bot for adding audio

Can you review latest edits by DerbethBot before I run it normally? --Derbeth ^talk 11:40, 23 August 2009 (UTC)

[edit] Template:grc-cite

I'm attempting to create this template to be used for example quotations in Ancient Greek entries. However, I've run across a problem, which I'd like some input on. It doesn't seem to take on the level in which it is used. For example, the hollowing doesn't work:

# sense
## subsense
## {{grc-cite|stuff....}}

In this case, the template puts the quote and everything else to the left, as if there were no number signs preceding it. I was thinking that there could be a "level" parameter, which would place the number signs inside the template itself. However, this would require code like:

# sense
## subsense
{{grc-cite|stuff....|level=2}}

This does work (I've tried it), but I was wondering what folks thought about it, and if there's perhaps a better solution. Many thanks. -Atelaes λάλει ἐμοί 01:43, 26 August 2009 (UTC)

One option is to move the * out of the template and into the entry's own wikicode, and to replace the template's : wiki-markup with the corresponding HTML-style markup. With that approach, the template's source would then look something like this:

{{#if:{{{year|}}}|'''{{{year}}}''', <nowiki/>|}}
{{#if:{{{1|}}}|{{{1}}}, <nowiki/>|}}
{{#if:{{{2|}}}|''{{{2}}}'', <nowiki/>|}}
{{#if:{{{3|}}}|{{{3}}}, <nowiki/>|}}
<dl><dd>{{polytonic|{{{4}}}}}
   {{#if:{{{5|}}}|<dl><dd>{{{5}}}</dd></dl>|}}
</dd></dl>

only without all the whitespace that makes it readable. It makes the template-code rather ugly, but I think it would make the entry-code quite readable, which is probably more important (provided the template is well documented). —Ruakh_TALK 03:29, 26 August 2009 (UTC)

Your solution is basically what I ended up doing for the {{cite meta}} family, although for Citations etc. I found it was best to just pass the whole first-line indent as a parameter, e.g. {{grc-cite|level=##*}} or {{grc-cite|level=**}}, etc. I do think that the first-line indentation should also be in the straight wikitext. Unfortunately, that does result in some ugliness: ##*{{grc-cite|level=##*}}. But not doing this makes the wikitext significantly less readable for both machines and humans, IMO. -- Visviva 04:05, 26 August 2009 (UTC)

[edit] Error: session data

I started getting the following error message with attempted edits:

Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in.

I tried logging out and then back in, but to no avail. Is this just a minor hiccup that will be corrected soon? Bendono 13:48, 26 August 2009 (UTC)

Strike that. Seems to have fixed itself now. Bendono 13:58, 26 August 2009 (UTC)

I've had that problem in the past, but usually a simple repeat of the save was sufficient. More recently I have had to log and log in. Today even that wouldn't help. I'd love to know if there is a way of reducing the likelihood of this repeating or whether it is a symptom of a problem with my set up. DCDuring TALK 14:12, 26 August 2009 (UTC)

I get it if I write an entry before logging in, then open another tab and log in there, and finally try to save my original entry. Equinox ◑ 23:51, 30 August 2009 (UTC)

I'll look out for a comparable condition the next time it occurs. Thanks. DCDuring TALK 01:05, 31 August 2009 (UTC)

[edit] font size in {{infl}}

At Wiktionary talk:About_Hebrew#font_size_with_vowels, two of the main Hebrew editors (there are only a few more than that) agreed on a change to template:infl that affects Hebrew entries; now we want someone else to do the work for us, please.  :-)  Specifically, the headword is in a larger font, and the inflected forms should be, too, to increase legibility. Anyone feel up to this?​—msh210℠ 18:53, 26 August 2009 (UTC)

(Specifically, each thing that looks like this:

'''{{wlink|w={{{6}}}}}'''

needs to be changed to look like this:

{{{{{sc|Xyzy}}}|{{wlink|w={{{6}}}}}|lang={{{1}}}|face=head}}

.) —Ruakh_TALK 20:12, 26 August 2009 (UTC)

O.K., I've made the changes, after some testing. Hopefully nothing explodes. —Ruakh_TALK 21:21, 27 August 2009 (UTC)

BTW, I'm pretty sure that either the job queue is broken, or Special:Statistics reports it wrong. —Ruakh_TALK 21:23, 27 August 2009 (UTC)

The job queue is run by several servers within the partition (en.wikt is in p2); the report is the queue on the server that happens to gen the page. So it isn't entirely useful. Robert Ullmann 15:11, 29 August 2009 (UTC)

This should almost certainly be face=bold, leaving it to the font template do to the right thing (bold, or a bit larger, or both). {{Hebr}} does "big" for both head and bold.

More seriously, this introduced doubled calls to Xyzy or the script template in some cases (which do exist):

{{infl|ru||sc=Cyrl|link a|foo|link b|{{l|ru|foo|sc=Cyrl}}}}

Grease pit (link a foo, link b foo)

Wait a second, that shouldn't even work! There are two calls to Xyzy (and Cyrl) nested. They've changed the recursion rules again? (sigh). It does produce some bad results, as in the following:

{{infl|he||link a|foo|link b|{{l|he|foo}}}}

Grease pit (link a foo, link b foo) (with infl "fixed", note the second link does exactly what is called for)

Which wraps the link in big tags twice. All of which explains why I've been thinking about this since setting up infl but not doing anything about it.

The best thing to do I think is leave it as is now, (except for using face=bold instead), and I'll work out a subfunction to do it "right". Robert Ullmann 13:15, 30 August 2009 (UTC)

I created {{slink}} as a subfunction (note it incorporates {wlink}—it has to—so it is more efficient, not less ;-). This does mean that some nasty tricks, like using |attribute|foo''' or '''bar| will not work (should just be |attribute|foo|or|bar anyway ;-) will get broken. Maybe I should go hunt for them?

Oh, and you get section links now. Robert Ullmann 15:01, 30 August 2009 (UTC)

[edit] y (lowercase) with umlaut and acute accent

I am trying produce the character formed from a y with an umlaut and an acute accent (as shown for u in ǘ), this is a transliteration of the Greek ΰ. Can anyone help please? —Saltmarsh^{απάντηση} 14:59, 29 August 2009 (UTC)

ÿ́ or ÿ́ like so? Robert Ullmann 15:06, 29 August 2009 (UTC)

thanks —Saltmarsh^{απάντηση} 06:30, 30 August 2009 (UTC)

For what kind of user is such a transliteration a help? If they are learners past having bought their first textbook, they should not need the gloss. Who would know how to use the gloss? DCDuring TALK 19:56, 29 August 2009 (UTC)

This is for the transliteration of Greek words here - I am not sure that ΰ exists in the Greek language but if it occurs in a word it should be Romanised. —Saltmarsh^{απάντηση} 06:30, 30 August 2009 (UTC)

Yes, it exists: πραΰνω (“‘mitigate’”). —Stephen 00:11, 31 August 2009 (UTC)

[edit] Template:palæontology

Just looking at the recent changes, we have three of these! Template:palæontology, Template:palaeontology and Template:paleontology. I'm assuming this is a classic redirect situation? Mglovesfun (talk) 15:58, 29 August 2009 (UTC)

Okay, done, two of them were unusued anyway, false alarm. Mglovesfun (talk) 16:02, 29 August 2009 (UTC)

Understandably, this looks weird. My rationale for bringing up this issue can be found hereat. This follows on from our general tendency to allow individual entries to diverge as much as is natural, possible and favourable. I think that this tendency is best accommodated by accommodating such policy/spelling reforms. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 01:32, 30 August 2009 (UTC)

Ok, a couple things. First of all, let me point out that none of these templates should be used in any of the entries noted. This is completely incorrect use of contags. The word "archeopteryx" (and all of its spelling variants) is used outside of the field of paleontology. Discipline contags like this are supposed to be used when a word is used in a specific and unique way only in a certain field. Ultimately, these words could perhaps be categorized as something (maybe "paleontology, but I think "birds" would be better). In any case, Doremítzwr, I think you're mistaken about our tendency to allow entries to vary as much as possible. Quite the contrary. In fact, I think it would be far more accurate to say that we generally want entries to conform to strict standards as much as possible, and grudgingly permit them to vary when they absolutely must. In any case, Mglovesfun's solution is acceptable, in that it makes the contags all display and categorize identically, but an even better solution would be to change the template calls in all the entries to be identical (that is, if the templates were appropriate to be used at all), so that even the code was conformant. -Atelaes λάλει ἐμοί 02:53, 30 August 2009 (UTC)

OK, but if we’re going to allow only one spelling, then it ought to be {{palaeontology}}. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 23:19, 30 August 2009 (UTC)

At COCA "paleontology" gets 258 hits to 3 for "palaeontology". I was unable to do a search for the ligature form since they don't include ligatures. This is a superior source to b.g.c. for current usage because the results are not distorted by current reprints of books that use rare, obsolete, and archaic spellings. Even on date-unrestricted search bgc favors paleontology over palaeontology by a 5 to 1 margin. What would the facts in support of the "ae" spelling be? DCDuring TALK 23:39, 30 August 2009 (UTC)

The British National Corpus: palaeontology, 50 vs. paleontology, 16. Obviously, COCA will yield more hits for the spelling that’s common in America, whereas BNC will yield more hits for the spelling that’s common in Britain. Besides, the etymological arguments are more important than appeals to usage frequencies IMO. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 23:49, 30 August 2009 (UTC)

Also, FWIW, the OED’s entry for “palaeo- | paleo-, comb. form” includes this parenthesis on the paleo- and pale- forms:

• (now chiefly N. Amer.)

They’re Their research, it seems, conflicts with yours. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 00:05, 31 August 2009 (UTC)— Edited to remove a stupid error; thanks DCDuring.

Actually, Wiktionary policy (might not be written policy, but nonetheless) is that whenever there's conflict between American and British spellings, the first editor to edit the thing in question uses whatever is most comfortable to them, and we stick with that. So, the spelling should be "paleontology", as it was the first template created. -Atelaes λάλει ἐμοί 00:28, 31 August 2009 (UTC)

So much the worse for "they're research". Their UK bias/preference is showing. If there were a good large, publicly available contemporary corpus of non-US English (It would be nice for other matters if it also included spoken material.), it would be easier to resolve such matters without the arbitrary first come, first served rule. I am only grateful that ligatures can rarely be justified in the UK. DCDuring TALK 01:01, 31 August 2009 (UTC)

On re-rereading Doremtizwr's comment, I note with alarm his proposed introduction of etymological considerations into choice of form. It would seem to be a form of prescriptivism that has no home here under our current practice and values. DCDuring TALK 01:14, 31 August 2009 (UTC)

I meant considerations such as the homography of pale- (from the Ancient Greek παλαιός (palaios), “‘old’”)) with pale- (from the Latin palea (“‘chaff’”)). This happens a fair bit with spellings that reduce æ/ae and œ/oe to e. The best example of the confusion wrought by this is ped- (from the Ancient Greek παῖς (pais), παιδ- (paid), “‘child’”)) vs. ped- (from the Ancient Greek πέδον (pedon), “‘~soil’”)) vs. ped- (from the Latin pēs, ped- (“‘foot’”)). I don’t see how taking such considerations into account could, by any stretch of the imagination, be alarming. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 01:36, 31 August 2009 (UTC)

I alarmed by the introduction of the irrelevancy of etymology into matters of current usage and usability. It is yet another form of prescriptivism, whose rejection is one of the values of this enterprise that I most cherish. DCDuring TALK 02:19, 31 August 2009 (UTC)

Well then, it seems that we disagree irreconcilably. Consider, as it seems is your wont, whether a wholly permissive dictionary which eschews all prescription is what our user base actually wants. Usage guides are popular and logomachies are common for a reason. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 02:35, 31 August 2009 (UTC)

Such things have their uses. Let a thousand flowers bloom. They are not suitable for the ambitions of WMF projects, however. I cannot see how any one POV on such matters can be acceptable. It is certainly not consistent with the value system. But perhaps adherents of some tendentious points of view can capture control of this free resource and run it as they will. DCDuring TALK 03:32, 31 August 2009 (UTC)

In simple Internet usage, paleontology is used more than six times as frequently as palaeontology (10,200,000 vs. 1,650,000). —Stephen 02:16, 31 August 2009 (UTC)

But the very idea that such facts are relevant seems to be what is in question. I had thought that the weight of evidence was what mattered. Perhaps I was misinformed. DCDuring TALK 03:32, 31 August 2009 (UTC)

I think we should be descriptivist in what we present to users, but there are a range of considerations in how we ourselves write. If an editor wanted to delete the entry for ain't, I'd object; and if an editor used ain't in entries, I'd also object. If paleontology is the more common spelling, I think that speaks mainly to the general predominance of American spellings; and so far, we've followed a "keep-the-peace"–type practice of ignoring said predominance, and instead treating American and British spellings as equally acceptable. As such, I agree with Atelaes that {{paleontology}} should be preferred because it was created first (and not because it's more common on the Web), and the other ones should ideally be deleted. (Though admittedly, this does make it a bit awkward when this tag is added to a sense-line whose definition uses British spellings.) —Ruakh_TALK 17:01, 31 August 2009 (UTC)

The choice of spellings communicates more than one thing to users. It constitutes a kind of recommendation. It can be interpreted as how we position ourselves in terms of formality or UK/US orientation or egg-headedness. Letting our impact on users be determined by our "reward" system for volunteers (I'd rather have cash, Amazon credits, health benefits, or even barnstars.) is an example of the absence of user focus that seems to pervade our choices. We do not control how users react to these things (nor do they). According to Google News, the paleo- spelling is on all fours with the palaeo- spelling in UK and Australia. The paleo-spelling is overwhelmingly dominant in US and Canada (9:0). It even might be more common in India (small sample: 3:1).

I wonder if there is a reasonable way of marking a word that we might use in definitions, context tags, or elsewhere which is subject to a significant regional difference. Also, how could we invite users to note such things? DCDuring TALK 18:29, 31 August 2009 (UTC)

(from the left) palæontology is of course very difficult to type on a keyboard anyway. More templates make it more difficult for novice editors, that's the reason why we try and avoid making new ones when something to do the same job already exists. As I always say, you're free to go on another website, or use your own user page for personal projects, but we are trying to establish a good quality dictionay here. PS

"This follows on from our general tendency to allow individual entries to diverge as much as is natural, possible and favourable."

Who is this? Mglovesfun (talk) 18:36, 31 August 2009 (UTC)

[edit] Allowing users to toggle spelling

(also from the left) It would be possible to do something in JavaScript; attach a suitable class to the occurrences of such words/phrases, and then render them differently depending on a) browser language detected via navigator.language / navigator.userLanguage (so as to display differently for en-US, en-UK, etc.); b) user selection via some unobtrusive little JS menu, maybe up in the top right corner; c) settings for logged-in users done in some other way. How much resistance there would be to putting that in the default skin I don't know. -- Visviva 11:53, 5 September 2009 (UTC)

Great! That was the kind of thing I was hoping for. I like ‘b)’; what do you make of the box to the right? Is that suitable? Presumably it can be set up only to display applicable toggles, so that if the only variably-spelt word an entry contains is, say, center/centre, then the only toggle in the box will be  -er • -re — right? It’s also probably unnecessary to have two different toggles for the ae–æ–ai–e and e–oe–œ–oi tetrachotomies or for the e-e–ee–eë and o-o–oo–oö trichotomies, since it’s unlikely that a person will want to see amœba but encyclopaedia (and not encyclopædia), or whatever. Yeah, this could definitely be the way to go. The spellings could be changed through templates named something like {{S:xion}} and {{S:ize}} (with S: standing for spelling just like the R: in our many such named templates stands for reference). Does all that seem practicable and a good idea to you? † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 00:07, 10 September 2009 (UTC)

My principal concern is with the default presented to anons and those registered users who have yet to have been clued as to the workings of WT:PREFS or the more obscure customization possibilities. It would be nice if we used some IP type information to customize spellings of definitions, contexts, usage notes and also, help pages, Wiktionary pages, etc, by default for anons, but principal namespace is the first priority. DCDuring TALK 01:10, 10 September 2009 (UTC)

The real value of this would be if it could be instituted for our un–logged-in users. If that could be done, then there would almost certainly be far less of the perennial tension surrounding spellings (at least from me). TBH, if this flexibility only worked through the PREFS, it would be but a minor improvement. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 01:15, 10 September 2009 (UTC)

Most English language browsers will give "en-US" or "en-UK" as the navigator.language. (I was surprised that these are the only variants available for Firefox). So we wouldn't have to actually sniff their IP (which people might find unnerving, or annoying if they were e.g. using a US-English browser in Hong Kong), we can just get the browser language information, and if not English, default to whatever. -- Visviva 07:14, 10 September 2009 (UTC)

Well, IMO anything that goes beyond a standard regional difference is beyond what we could plausibly handle in the default skin. So I was thinking in terms of a little dropdown menu with just "US", "UK", "Australia", "Canada" etc. Obviously this would result in "-ise" spellings being shown even to "-ize"-favoring British types, but there's no straightforward way around that that I can see. I very much doubt if you could get consensus for a menu such as shown (though it might be interesting to try :-P ). -- Visviva 07:14, 10 September 2009 (UTC)

What are the problems with that kind of toggle box, exactly? There are plenty of problems with choosing spellings by region… † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 23:44, 10 September 2009 (UTC)

I very much like this idea. Would it be implemented only for context templates, or would we try to use it in running text as well (like we have {{,}})? We could, for instance, create {{s:center}} and {{s:centre}} so that whichever is used in the running text of a definition line, the display would be how the user (or the navigator's language) desires it. --Bequw → ¢ • τ 14:09, 11 September 2009 (UTC)

I reckon in running text, too. That way we avoid stupid stuff like “molluscs/mollusks”, as in the first definition of octopus. IMO, {{S:er}} or {{S:re}} (with one as a redirect to the other) would be a better idea, since most of these spelling differences fall into patterns, and such nomenclature avoids the bewildering proliferation of S:-prefixed templates (so we’d write “centre” as cent{{S:re}}). What do you think? † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 14:43, 11 September 2009 (UTC)

Yeah, that's better. I like it. --Bequw → ¢ • τ 14:47, 12 September 2009 (UTC)

[edit] Improving glosses

Using the automated translation boxes, sometimes an error message shows up: "Could not find translation table...Please improve glosses." What do I do? Should I add the translation manually? Ailurophile 17:55, 29 August 2009 (UTC)

• Yes, the error occurs because two of the translation boxes have the same, or a very similar, title (so you could improve the glosses by making them more distinct). I hope to fix this issue at some point, but for now it serves as a reminder that each gloss should match only one definition (and they should thus not be overly similar to each other). Conrad.Irwin 14:16, 30 August 2009 (UTC)

  Conrad, is it possible to generate a clean up list for these? DCDuring TALK 18:44, 30 August 2009 (UTC)

Urm, probably, but I'll have to think about it. Conrad.Irwin 22:58, 6 September 2009 (UTC)

I wish I could think of a way to estimate how many of these there are. Have there been many questions about this? DCDuring TALK 23:17, 6 September 2009 (UTC)

I can't recall ever having seen this issue raised before. --EncycloPetey 23:45, 6 September 2009 (UTC)

It's come up four-five times, probably split between here, the early WT:BP chat, my talk page and WT:EDIT. I am totally at fault for it causing issues as I should not have taken the lazy way out to start with. (Although in an ideal world all the glosses would be unique). Conrad.Irwin 23:49, 6 September 2009 (UTC)

You might call it lazy or you might call it economical. If the numbers are that low, we can address the problem as it arises. The glosses so identified can stand improvement. There are lots of things you can productively spend your time on that are more important than this. DCDuring TALK 00:42, 7 September 2009 (UTC)

[4] should help. Please let me know if you get the new message ("Glosses should be unique"). Conrad.Irwin 01:03, 11 September 2009 (UTC)

[edit] Template:Things to do

In order to canalize good willings I propose to deploy a template like w:Template:Navigation_things_to_do or in French fr:Annexe:Quoi_faire_sur_Wikimédia. JackPotte 23:53, 29 August 2009 (UTC)

Wiktionary:Things_to_do needs a some work before that template will be useful. Conrad.Irwin 14:36, 30 August 2009 (UTC)

[edit] September 2009

[edit] Extra curly brackets in a template?

Consider, if you will, {{given name}}. A nice, simple template -- by Wiktionary standards, anyway -- one that seems to contain no complex magic, nothing fancier than some basic ParserFunctions. The template is used widely and functions well, having gone for almost a year now with no edits. Yet the template wikitext contains 64 opening curly brackets and 66 closing curly brackets. Specifically, at the end of the template there are 4 closing brackets, but only one ParserFunction is open. Furthermore, if you remove the last two closing brackets -- as I did, when safely back in userspace -- the template breaks. So this isn't just MediaWiki being tolerant of error; those "extra" two brackets are actually needed.

So, basically, two questions: a) what the heck is going on?, and b) how common is it? I only noticed {{given name}} because it was one of a handful of templates I was specifically trying to get my little script to handle -- and I'm happy to say that it now handles it perfectly, except that there is an extra "}}" at the end.

I expect this will prove to be horribly obvious, but if anyone can point me towards some answers, I'd be much obliged. -- Visviva 10:05, 5 September 2009 (UTC)

There are two parser functions "open" at the end, and those }'s are correct. You are quite right, there are 2 extra, but they don't show up unless the call uses the or= option. Then it generates a bad category name with two }'s in it. Fixed now. Robert Ullmann 15:31, 5 September 2009 (UTC)

Aha! That would make sense. Thanks. -- Visviva 15:49, 5 September 2009 (UTC)

[edit] hide/show translations

how2change pref. pl?--史凡>voice-MSN/skypeme!RSI>typin=hard! 02:20, 8 September 2009 (UTC)

Go to WT:PREFS. Second group of check boxes gives you some choices. All of the checkboxes are worth looking at. Just remember that most users never get the benefits of the choices. Our Wiktionary is better than theirs. DCDuring TALK 03:30, 8 September 2009 (UTC)

ta![iwas stuk atMyPrefs,sigh--史凡>voice-MSN/skypeme!RSI>typin=hard! 11:48, 8 September 2009 (UTC)

[edit] http://en.wiktionary.org/w/index.php?title=verlopen&action=submit

wotgoes rong w/nrs pl?--史凡>voice-MSN/skypeme!RSI>typin=hard! 10:57, 8 September 2009 (UTC)

¿Qué? I have no idea what you’re talking about. May I suggest acquiring a dictation program such as Dragon NaturallySpeaking? Voice-recognition technology is now good enough to make such uses viable. Your RSI, regrettably, is a considerable barrier to communicative comprehension. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 12:43, 8 September 2009 (UTC)

I HAV'IT,butmyCOMP.IS2SLOW4it[orthink urdealin'w/a moron?

• ifthisplace'dbe moreTECHNOLOGY-FRIENDLY,VOICE MSGs'dbe left[gotit?-same idea/principl;furthamore,entrySPEAKS4ITSELF.[butrather putime i/SHOWIN'OFur fancypants'ritin'skils eh?!
• n'avin'aBABELBOX,'d itbe an idea wa?--史凡>voice-MSN/skypeme!RSI>typin=hard! 15:01, 8 September 2009 (UTC)

There's no need to start shouting at Doremítzwr for making a well-intentioned suggestion. He has a valid point that your shorthand writing can be difficult to parse at times. However, if that's your best option, then it's your best option, and is generally readable (especially with a bit of practice). Yes, your question can be determined simply by looking at the entry, but not everyone will pick up on it. The question and answer has already been discovered (and implemented) by SB. The issue was that you had a newline within the quotation. SB removed the newline, and everything seems to be working as you intended it. -Atelaes λάλει ἐμοί 15:40, 8 September 2009 (UTC)

[edit] Proposal for the simplification of the code for linking the component words in inflexion lines

Nota these templates, which display the parameter that allows the linking of the component words of the inflexion lines they create:

{{en-noun|sg=[[noun]] [[phrase]]}}

{{en-verb|inf=to [[multi]]-[[task]]}}

{{en-adj|pos=[[multi]]-[[word]]}}

{{infl|head=[[phrasal]] [[whatever]]}}

It would be simpler and it would make the learning curve less steep if all these parameters were similarly named. ATM, for English, nouns take sg= (for singular), adjectives pos= (for positive), and verbs inf= (for infinitive), all of which make perfect sense. {{infl}} meanwhile, being a universal inflexion template, takes head= (for headword). Since head= is universally appropriate, can that be made the component-words–linking parameter name for all templates (for the sake of less experienced users)? We needn’t get rid of sg=, pos=, inf=, &c., AFAIK, but head= should at least be made to work as they do. That seem fair to y’all? Are there any problems with this that I have not foreseen? † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 22:41, 9 September 2009 (UTC)

This is mainly the result of tradition, as the folks who initially wrote those templates probably weren't looking that far into the future, and simply chose the most appropriate parameter label for the template in isolation. I think it could be done, but the code inside the templates might get a little complicated, at least for awhile, as we would have to account for the plethora of entries which use the current parameters, which couldn't be changed in an instant. That being said, I support this proposal, as I agree that it would make the use of these templates easier, especially for newcomers, if it admittedly would probably cause some confusion to veterans who are used to these templates in current form. -Atelaes λάλει ἐμοί 23:12, 9 September 2009 (UTC)

Support effort to make it work as Doremitzwr has proposed, grandfathering the old parameter names, but encouraging the use of "head=" for all templates, where needed. DCDuring TALK 00:08, 10 September 2009 (UTC)

Support --Vahagn Petrosyan 05:50, 10 September 2009 (UTC)

Support, much needed. Note, however, that the templates in question are kind of a pain to edit (which is probably why this hasn't been done until now). -- Visviva 06:21, 10 September 2009 (UTC)

I, too, support.​—msh210℠ 19:48, 10 September 2009 (UTC)

Of course we should do this. At some point we should also completely remove support for the tabular inflection line format, I don't care whether it looks nicer, the negligible proportion of users who use it cause unknown suffering on the template maintainers. Conrad.Irwin 19:47, 10 September 2009 (UTC)

Now would be a good time  :-) .​—msh210℠ 19:49, 10 September 2009 (UTC)

Yeah, seems good :) 50 Xylophone Players talk 20:32, 10 September 2009 (UTC)

Done {{en-noun}}, {{en-verb}}, {{en-adj}}, {{en-adverb}}, {{en-proper noun}}. Conrad.Irwin 22:18, 10 September 2009 (UTC)

[edit] Adding the nocap= and nodot= parameters to {{simple past of}}

Hi all. I tried adding the nocap= parameter to {{simple past of}} (I couldn’t work out where the nodot= parameter should go), but it doesn’t seem to have had any effect. Could someone please add those two useful parameters to that template, please? Thanks. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 15:01, 10 September 2009 (UTC)

{{form of}} is not well suited for use in other templates, I've just replaced the contents with the same as {{plural of}}. Incidentally, I think {{{nocap}}} and {{{nodot}}} should be considered deprecated in favour of {{{dot}}} and {{{cap}}}:

• {{simple past of|thingy|dot=|cap=s}} simple past of thingy
• {{simple past of|thingy|nodot=1|nocap=1}} simple past of thingy —This unsigned comment was added by Conrad.Irwin (talk • contribs) 19:46, 10 September 2009 (UTC).

Thanks; that seems to have worked. Do the cap= and dot= parameters work identically with nocap= and nodot=? † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 20:06, 10 September 2009 (UTC)

The two different syntaxes are just above (see my previous reply). The dot= and cap= parameters are slightly shorter to use, and allow you to (for example) use {{{dot=,}}} to replace the ".". Conrad.Irwin 22:24, 10 September 2009 (UTC)

OK, noted; thanks. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 11:55, 12 September 2009 (UTC)

[edit] seeCite template - modification, e.g. with pipe syntax

(I started this question on Info Desk but was told it's more of a Grease Pit question.) I want to make the template say "For more examples of the usage of this term see the citations page" (instead of "For examples of the usage of this term see the citations page") on the cuckold entry. Would there be an easy enough way to make this happen? (Perhaps make it work like e.g. en-verb where you can use pipe syntax where & when necessary?) Thanks very much.--Tyranny Sue 17:42, 12 September 2009 (UTC)

If it were just a question of sometimes added "more", then it would be speed typing to just have "more" be a parameter. How else can we imagine using pipe syntax with this? DCDuring TALK 17:55, 13 September 2009 (UTC)

Is there a more ambiguous term that we could use in all cases? Maybe "supplemental examples"? -- Visviva 01:08, 14 September 2009 (UTC)

Err... we use "examples" to mean "made up sentences", so I'd prefer that we avoid using that terminology. --EncycloPetey 01:16, 14 September 2009 (UTC)

Well, I meant just replacing "more" with "supplemental": "for supplemental examples of the usage of this term see the citations page". "Supplemental" could mean either supplemental to the entry, or supplemental to the citations already in the entry, so it would be correct in both cases. There might be a better word, though. -- Visviva 01:26, 14 September 2009 (UTC)

[edit] Monobook.js has been emptied

I have moved everything to MediaWiki:Common.js, as with the new Vector skin we need to test everything there too. Conrad.Irwin 22:05, 13 September 2009 (UTC)

As a user of Vector, thank you very much. Is a similar process planned for moving common content from MediaWiki:Monobook.css → MediaWiki:Common.css? I notice that MediaWiki:Vector.css is currently empty. --Bequw → ¢ • τ 01:02, 14 September 2009 (UTC)

I moved the NavFrames stuff across yesterday, and yes the rest should probably be moved too, however unlike the javascript, there is no guarantee that the user will be given coherent versions of the stylesheets, so they will have to remain in both for a month. Conrad.Irwin 01:11, 14 September 2009 (UTC)

So, now that it's been moved, I can't seem to use accelerated entry creation. What must I do? --EncycloPetey 02:18, 14 September 2009 (UTC)

The problem now seems (mostly) transitory. I never used to see "junk" when I used the accelerated feature of {{en-noun}} to create the plural, but I got a fine mess when I created pine nuts (admins will have to look at the deletion log). I now see the junk briefly, but it then shifts to the "correct" page content. --EncycloPetey 02:43, 14 September 2009 (UTC)

In terms of javascript nothing should have changed, the software [view-source:http://en.wiktionary.org/w/index.php?title=-&action=raw&smaxage=0&gen=js&useskin=monobook outputs] the two as one file anyway (though I've been here long enough to know that even such non-changes can break things...) . I sometimes notice that the junk takes forever to be replaced by the real values when it is slow in loading something else - hippietrail's nearby pages is a particular culprit, though it could be caused by almost anything (including the citations tab script). Conrad.Irwin 23:47, 15 September 2009 (UTC)

[edit] Rat Patrol 2009

Everyone's favourite topic: patrolling edits ...

We've been successfully using the autopatrol group, (see WT:WL etc) for a while. But I think most everyone has stopped doing any manual patrolling of the rest. As with a lot of chores, if everyone does a bit, it is quite easy. If only one or two, then it is onerous.

At the moment, we are letting about 300 edits a day go un-patrolled, and some serious crap is getting through. Still, that isn't very many to check, and we should now be able to get them all, without anyone having to do a lot of work

I've re-written the Rat Patrol program from a couple of years ago, and tested it with the current "framework" and Python 2.6. Please see User:Robert Ullmann/Rat Patrol. It is fairly easy to use, and you can mark edits very quickly (it does the network traffic in the background).

At the moment, it finds 9000+ un-patrolled edits; we can run that down very quickly, and should be able to keep up. With many fewer un-patrolled, those people who want to use the other methods (RC and tools) will also find it more productive. Please try it out if you can. Robert Ullmann 09:29, 15 September 2009 (UTC)

Every time that I logon, I patrol recent changes from the time that I logged off. On average, it takes half an hour every morning and is a drag. I just wish other sysops did the same thing. SemperBlotto 07:34, 16 September 2009 (UTC)

I've checked and marked 3000+ in the last 24 hours or so, in between doing work. A fast tool makes a big difference. In a few days we should have the backlog reduced to a manageable number of things to look at. See [5] which should be kept (nearly) clear, but at present only goes back just into August with the 5K limit. Whichever tools people use or don't use, would be good to have more doing it. Robert Ullmann 17:34, 16 September 2009 (UTC)

All I'm getting are 0's -- that is, it never seems to fetch any actual changes. 'Course, I can always patrol by hand, and have been doing a little. But is there a trick to it? -- Visviva 09:15, 17 September 2009 (UTC)

[edit] Index in category:Latin verbs

I'd like to have an index on top of the category latin verbs. thank you. --Diligent 11:38, 15 September 2009 (UTC)

Done. -Atelaes λάλει ἐμοί 12:00, 15 September 2009 (UTC)

thank you ! --Diligent 16:52, 15 September 2009 (UTC)

It used to have one. Seems it was removed in June, although I don't know why. --EncycloPetey 12:59, 15 September 2009 (UTC)

[edit] Auto Redirect

Our software currently auto-redirects queries, for example from capitalized versions to uncapitalized versions. My impression was that it was partially native MW programming and partially some custom JS specific to Wiktionary, but I'm not really sure. I was wondering if it was possible to modify this behaviour, specifically to add equivalences. On WT:RFV# philerast I suggested that certain non-meaningful ligatures should be disallowed, and the software auto-redirect any user query with them, and I was wondering if this was possible. Many thanks. -Atelaes λάλει ἐμοί 22:21, 15 September 2009 (UTC)

Not without some reasonably significant effort. This is the kind of thing that the search should work for, and we just have to encourage people to use/fix that. Conrad.Irwin 23:42, 15 September 2009 (UTC)

What kind of significant effort are we talking about here? -Atelaes λάλει ἐμοί 00:01, 16 September 2009 (UTC)

Re: "My impression was that it was partially native MW programming and partially some custom JS specific to Wiktionary, but I'm not really sure": You're quite right. We use wiki-code on the server side to identify which alternate capitalizations, if any, are bluelinks (see {{alternate pages}}, which is ultimately transcluded in MediaWiki:Noarticletext), then JS on the client side to redirect if one is (see the Did you mean ____ redirects part of MediaWiki:Common.js). (We also use normal MediaWiki redirects in cases of internal capitals — for example, no wiki-code transformation will generate United States from any other capitalization besides united States, so we bluelinkify [[united states]] as a redirect, in order to "catch" any other capitalizations.)

For other transformations besides capitalization, the native MW programming won't help us; so, we either have to use Ajax code to check for bluelinks — which would take a fair bit of effort to get right, and could pretty quickly get out of hand (how many different possibilities to check?) — or we have to apply some sort of definitive normalization process, then redirect "blind" (i.e., without knowing whether the redirected-to page is a bluelink). That sort of "blind" redirect approach wouldn't be hard at all IMHO. (N.B. In either case, this would only work for JS-enabled browsers, unlike the capitalization stuff, which at least produces prominent links in non-JS-enabled browsers.)

Personally, in the case of something like [[philerast]], I wouldn't really mind redirecting "blind" to [[philerast]], since even if the latter is also a redlink, it's a better redlink. The only page we should ever have with st in its title is [[st]] itself. But I wouldn't want to do it without running it by the BP to make sure people are O.K. with going down that road.

—Ruakh_TALK 02:08, 16 September 2009 (UTC)

[edit] Template:topic cat parents/Fictional characters

How do we make this template categorize Category:hy:Fictional characters into Category:Armenian proper nouns and not Category:hy:Proper nouns? --Vahagn Petrosyan 11:44, 16 September 2009 (UTC)

I don't think it should do either one, should it? I think English Smurf probably belongs in Category:Fictional characters, but not in Category:English proper nouns. It seems wrong to try to mix the topic-category hierarchy with the part-of-speech–category hierarchy. —Ruakh_TALK 17:06, 16 September 2009 (UTC)

That was my first thought too. I'm gonna go ahead and remove that part of categorization. --Vahagn Petrosyan 18:26, 16 September 2009 (UTC)

I would have thought that Smurf would properly belong in Category:Fictional beings rather than Fictional characters, but no such category exists. Are we not missing a key distinction here? -- Visviva 04:23, 23 September 2009 (UTC)

It is possible to do what was originally wanted by having the category added via Template:topic cat description/Fictional characters by including [[Category:{{{langname|English}}} proper nouns]] in it. It's a kludge, but it does work. — Carolina wren discussió 04:48, 27 September 2009 (UTC)

[edit] {{misspelling of}} with wikified parameter

The {{misspelling of}} template doesn't seem to like the parameter being wikified. See forgiveable as an example. Can this be brought into line with other templates (such as {{alternative spelling of}} please? SemperBlotto 08:55, 17 September 2009 (UTC)

[edit] Category:All sign languages

It seemed logical enough to me to go with the example of Category:All languages because of Category:ja:Sign languages. Don't we need a topic cat template to go with this now? Cheers, Mglovesfun (talk) 13:47, 17 September 2009 (UTC)

[edit] Template:ga-adj

I'd like to request three templates, similar in style to the {{ga verb conj 2}}, but for adjectives.

Template {{ga-adj-1}} would cover the first declension:

1. First Declension Masculine -- broad consonantal endings:
   • gensg=slender
   • vocsg=slender
   • datsg=broad
   • nompl=broad +a
   • (weak noun) genpl=nomsg
   • (strong noun) genpl=nompl
   • vocpl=nompl
   • comp, sup=slender +e
2. First Declension Feminine -- broad consonantal endings:
   • gensg=slender
   • vocsg=slender
   • datsg=slender
   • nompl=broad +a
   • (weak noun) genpl=nomsg
   • (strong noun) genpl=nompl
   • vocpl=nompl
   • comp, sup=slender +e
3. First Declension Dual-Gender -- slender consonantal endings (except -úil):
   • gensg=slender
   • vocsg=slender
   • datsg=slender
   • nompl=broad +a
   • (weak noun) genpl=nomsg
   • (strong noun) genpl=nompl
   • vocpl=nompl
   • comp, sup=slender +e

Template {{ga-adj-2}} would cover the second declension:

1. Second Declension -- slender consonantal ending in -úil:
   • mgensg=slender
   • fgensg=broad +a
   • vocsg=slender
   • datsg=slender
   • nompl=broad +a
   • (weak noun) genpl=nomsg
   • (strong noun) genpl=nompl
   • vocpl=nompl
   • comp, sup=broad +a

Template {{ga-adj-3}} would cover the first declension:

1. Third Declension -- vocalic ending:
   • all forms unchanged

There would be a parameter in all three templates to change the comparative/superlative form for irregular adjectives, such as beag (small, comp. lú) or fada (long, comp. faide or sia).

The end result should look like this:

(First Declension example (second Declension would be identical))

Third Declension would look like this:

This is only a first idea, but I hope some fine tuning will make this feasible. Thanks. Corey (talk) 15:25, 17 September 2009 (UTC-5)

May I suggest you leave a note with User:Angr. He's the one who set up the verb template, and his combined knowledge of Irish morphology and MW template syntax makes him the ideal choice for this task. -Atelaes λάλει ἐμοί 12:46, 18 September 2009 (UTC)

I beg to differ on the MW template syntax part. Getting those verb templates set up cost me a lot of blood, sweat, and tears, and I'm still not sure how I managed to do it. But if I have some time this weekend maybe Corey and I can put something together. —Angr 15:59, 22 September 2009 (UTC)

[edit] Special:Import

Could somebody tell me the file names that enable Special:Import and make it work? I am trying to get it to work for the Navajo Wikipedia (w:nv:Special:Import), but I’m really out of my element. Any help gratefully accepted. —Stephen 20:36, 17 September 2009 (UTC)

I don't seem to recall any special file name requirements for importing. May I ask what's going wrong? -Atelaes λάλει ἐμοί 11:33, 18 September 2009 (UTC)

In our Special:Import, you get a complete dialog box. But if you look at w:nv:Special:Import, it’s a blank page. There must be templates or .ccs pages or .js files that create the text and textboxes that should go there. —Stephen 12:16, 18 September 2009 (UTC)

Hmmm....looking at the decision section of Wiktionary:Votes/2009-03/Transwikis_from_other_Wiktionaries, it would appear that the text for our Special:Import is written at MediaWiki:Import-interwiki-text. However, it also appears (from the same section of that vote) that this is a feature which is not automatically set, but must be put in place by a developer. You may want to Ruakh's assistance, as he set up the vote and filed the bug report, and will undoubtedly know more about this. -Atelaes λάλει ἐμοί 12:43, 18 September 2009 (UTC)

Thanks, sounds like a step in the right direction. Hope Ruakh understands how it is set up. —Stephen 13:06, 18 September 2009 (UTC)

Unfortunately, I don't know of a way to determine whether nv.WP has transwiki-importing enabled, with one or more transwiki-import sources set up; but I'm guessing that it probably doesn't, and that's probably the only issue. If so, only a developer can fix it — it involves a config change. To address this, you should first gather consensus on-wiki, through a vote or a discussion or whatever process nv.WP has (I'm not sure how essential that step is — if you just need transwikis from nv.wikt and the like, the developers will probably take it for granted that that's O.K. — but it can't hurt). Then, open a Bugzilla ticket, in the "Wikimedia" product, "Site requests" component. In your ticket description, state exactly which sources you want to be able to import from, and provide a link to the vote/discussion/whatever that demonstrates the consensus. (See bugzilla:18519 for the general idea; that's the ticket I opened when we voted to allow transwiki-importing from other Wiktionaries. That case was slightly different, in that we already had transwikis from other projects, so I knew that the overall feature was enabled and functional; but the overall idea is similar.) —Ruakh_TALK 22:44, 19 September 2009 (UTC)

Thanks, that gives me a good direction. —Stephen 18:20, 20 September 2009 (UTC)

w:nv:Special:ListGroupRights should list whether transwiki importing is in effect, I'd think. (But I haven't checked it.)​—msh210℠ 18:35, 22 September 2009 (UTC)

[edit] {{sh-decl-noun}}

I wanted to wikify {{sh-decl-noun}}, such that all entries should be linked. My approach seems too simple in 2 ways:

• the template is entered everywhere with a newline after the plural entries. The newline is taken to be part of the parameter, and thus the links do not work (you get stuff like [[avatari

]])

• Some words (e.g. te#Serbo-Croatian) have links or more complex stuff already inside them, so some more intelligence is needed (I suppose {{isValidPageName}} would do it here?).

I don’t really feel like putting more time in this, maybe someone more tech-savvy can have a look at this? (Or tell me how to do it.) H. (talk) 09:44, 19 September 2009 (UTC)

MediaWiki strips the newlines from named args, but not from anonymous args. (I believe there is a good reason for this annoying behavior, though I can't recall what that reason is.) So one simple solution would be to just have {{wlink|1={{{parameter}}} }} everywhere. Like this: avatari. HTH, -- Visviva 04:20, 23 September 2009 (UTC)

[edit] MediaWiki:Previously deleted entries

In case anyone hasn't noticed, there's no need for this to be prefixed with MediaWiki because it's not used on other pages like MediaWiki:Edittools. When you rename pages, you can rename up to 100 subpages as well, so I was just thinking of Wiktionary:Previously deleted entries. It shouldn't be an appendix because it's not a lexical topic, it's an administrative one. Any thoughts or objections before I just go ahead and do it? Mglovesfun (talk) 13:05, 20 September 2009 (UTC)

Go for it. The original reason for it being there was so that it wasn't indexed by the search, but I've always thought that was unconstructive. Conrad.Irwin 23:26, 20 September 2009 (UTC)

[edit] ow2make myfirefox3.5.3 display alda hanzi pl?

http://en.wiktionary.org/wiki/Index:Chinese_radical/%E7%81%AB fe da3rd char.at"+0strokes"/the1. 2at"+2strks"=nr'd boxes--plpl helpme display nsavor my beluvd chin.!!--史凡>voice-MSN/skypeme!RSI>typin=hard! 14:03, 22 September 2009 (UTC) how to make my Firefox 3.5.3 display all the hanzi please?: for example the third character at "+0 strokes" / the first two characters also at "+2 strokes" = numbered boxes - please please help me display and savor my beloved chinese!!
translation by L☺g☺maniac chat? 21:38, 25 September 2009 (UTC) ta!--史凡>voice-MSN/skypeme!RSI>typin=hard! 13:33, 26 September 2009 (UTC)

Yeah, I have a problem with the third +0 strokes character, too. You may find something useful hereat or somewhere similar. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 14:05, 26 September 2009 (UTC)

[edit] eo templates

(I'm not sure if this is supposed to go in the BP or here. If I put it in the wrong place please tell me.)

I've noticed that Template:eo-noun-form,Template:eo-verb-form, and Template:eo-adj-form all work very differently than most of the other language forms templates, looking basically like this:

(template:) manĝis (past tense of manĝi)

1. ate

as opposed to the normal form templates which go in the definition line like:

manĝis

1. (template:) past tense of manĝi, (optional:) ate

This is problematic, mainly because the definition line is often not really correct, and that the current system is impossible to be accelerated. So, would anybody object if I were to change the templates to the second way as in User:Yair rand/eo-verb-form, User:Yair rand/eo-noun-form, and User:Yair rand/eo-adj-form and change all of the places where the templates are used? Or maybe a bot could do it... --Yair rand 04:09, 23 September 2009 (UTC)

[edit] Hovering tooltip or Wiktionary search box

n:fr:User:Otourly was wondering if it would be possible to add a tool for fr.wn readers to quickly look up words in Wiktionary, since many readers are FSL and often need to look up terms and translations. With some brainstorming, it seems like a javascript which looks up the word over which the cursor is hovering for a number of seconds would be the best solution - perhaps posting the first words similar to the IRC bot, and allowing a click-through to the wiktionary. But also a search box form that could be included, perhaps in the left menu, would be very useful if that's possible in the current MW setup?

This seems like an excellent cross-project tool which could bring in a lot of readers and potential contributors. - Amgine/^talk 17:53, 23 September 2009 (UTC)

It looks like https://addons.mozilla.org/en-US/firefox/addon/7675. JackPotte 18:10, 23 September 2009 (UTC)

Only for FF users... :( Otourly 19:39, 23 September 2009 (UTC)

The current evolution is in w:fr:Utilisateur:JackPotte/monobook.js. JackPotte 22:43, 26 September 2009 (UTC)

There are additional developments as well - there is an alpha testing on en.wikinews as a gadget, available under user preferences Gadgets->Browser->Experimental... This is not a production version, but it shows the potential. - Amgine/^talk 01:58, 27 September 2009 (UTC)

Hello. Nice gadget:) Few thoughts. 1) Wouldn't it be nice to read audio for thous who learning En/Fr/Ru etc? May be not as default option(it is possible that users read and look up definitions in quiet environment, i.e. baby sleeping same room or at work). Not sure what would be the best way to handle options(so user have no need to mess up with profile js file), but one way would be adding same gadget with audio enabled. Here is example code, it should work in any modern browser but IE. Or adding button into iframe, that play audio on click (also fairly easy with HTML5). 2) It is very annoying, even for English when software define words like "added is a simple past of add", "apples is a plural of apple" etc and so on. Like user could not figure that out by him/herself. I'm saying this from real life experience of using early version of WL:) And, if you think in a bigger scope, English is relatively ok, only every 5th definition go that way. But for example in case of Ukrainian that would be like 7 look-up out of 8 defined that way. This problem quite solved in WL for En.Wikt but not at all for other Wiktionaries. 3) Minor thing. I saw regex there, I think [a-zA-Zа-яА-Яà-žÀ-ŽΑ-ῥԱ-ևぁ-ヶ促-杁ㄱ-하ⁿßſ] should cover much more languages, but there is comment that regex might not be needed, so this just a suggestion. 4) And very minor thing. Gadget claims that Wiktionary hold copyright on info shown. Which is totally misleading. Only ones who have copyright, it probably those contributors who wrote article from scratch. If articles were modified later, no one could claim copyright over modified versions (they either GFDL or CC-BY-SA-3.0). Not to mention, if copyright is claimed, it should be organization(such as Wikimedia Foundation) or person. Not a web site. But once again, this is the least important thing. TestPilot^{talk to me!} 07:42, 12 November 2009 (UTC)

Thank you very much for the review! I'll pass these ideas on to the person who is currently leading the development.

1. I really like the sound file idea. I'm learning another language, so it would be a great help.
2. I'm not sure there is an easy solution for this one, except in cases where plurals and conjugations are created by bots. The script is now working with English, French, Italian, Nederlands, and Spanish, and is nearly complete for German and Russian Wiktionaries.
3. Thanks for the regex!
4. I believe Wiktionary is the agent designate for the CC-by-sa license under the US region of the license, but I will certainly clarify this.

Thanks for giving your time to such a thoughtful review!

2) This code should work for en.wikt, and probably with some modifications MIGHT work for some other languages.

var pattern = 'of <span class="mention">'; var a = html.indexOf(pattern); if (a!=-1) { word=html.substring(a+pattern.length, html.indexOf('" title="',a)); word=word.substring(word.lastIndexOf('/')+1, word.length); }

It would work only for forms of that declared using templates, but it should even pick "alternative spellings of" and such.

5) This idea is on todo list for WL. There is an awesome(really awesome!) project Simple English Wiktionary. I want to add an option to pick definitions from it first, and only if word not found there, then look up en.Wikt. And that should really help those who's knowledge of English are limited(and even kids). TestPilot^{talk to me!} 21:36, 12 November 2009 (UTC)

Thank you for your suggestions. I'll be sure to implement them soonish. As for the regex with all the letters with accents, its inheireted from older versions of the script. Since than the way the script selects words has changed, so its unclear if it is actually needed. In most cases it is not needed, but i'm not sure if thats true in all cases. In any case improving that specific regex is definitly on my todo list (along with quite a few things). I like the idea of an option for sound. I think the button would be better, as i'd imagine having my computer speak to me every time i look up a word would get annoying. Definitly something to look into. Thanks. Bawolff 18:10, 19 November 2009 (UTC)

[edit] Wiktionary_Hover: a JavaScript on double-click

Wikinews proposes a script to display the Wiktionary definition in a small board, when one double-click on a word. It's already been installed in the following Wiktionairies gadgets: in French and in Italian. The interface of the board depends on the user's language preferences.

To add it here, we should vote for an administrator, in:

1. MediaWiki:Gadget-dictionaryLookupHover.js, copies without the guillemets : "importScriptURI('http://en.wikinews.org/w/index.php?title=MediaWiki:Gadget-dictionaryLookupHover.js&action=raw&ctype=text/javascript');"
2. MediaWiki:Gadgets-definition, adds "* dictionaryLookupHover|dictionaryLookupHover.js"
3. MediaWiki:Gadget-dictionaryLookupHover, describes the gadget. JackPotte 15:30, 15 November 2009 (UTC)

It's today activated on more than 14 sister projects. You can test it individually by copying my User:JackPotte/monobook.js into yours. JackPotte 23:41, 21 November 2009 (UTC)

Easier to go to WT:PREFS and, under "Preferences relating to navigation and editing." tick "Allow lookup of unlinked words on double click" (in addition to the "use the preferences set on this page" button). Conrad.Irwin 23:54, 21 November 2009 (UTC)

[edit] Special database fields

Hi folks,

I wanted to ask/propose: is there any chance that specific fields, for well defined items, could be created/added to Wiktionary "articles"? For example, could we add an IPA field, a part of speach field, or even a language field for all items (optional, of course)?

I should say that I know that this is technically possible (it would require adding table(s) to the underlying database), so I guess that the question should be phrased "can we get special fields added for Wiktionary?" And also "what fields should be added?"

The need for this in a dictionary (as opposed to an Encyclopedia) seems somewhat obvious to me. Dictionary entries generally contain discreet items of information rather then prose, so a series of text items seems much more useful and appropriate here then would be true in Wikipedia. Ohms law 06:39, 24 September 2009 (UTC)

Perhaps through the use of sub-articles? For example Beijing/IPA? Ohms law 19:29, 24 September 2009 (UTC)

The problem is that single spelling can be used in multiple languages, and within a language, it can correspond to multiple pronunciations and multiple parts of speech, so the fields that you describe don't apply to whole entries. There's really no flat structure that can accomplish what you want; hierarchical structuring is the only workable approach. Sorry. —Ruakh_TALK 19:50, 24 September 2009 (UTC)

It is currently mimicked by using templates, the information is not seperate, but when it has been put into a template it can be parsed out of the page more easily. In the general case the data in wiktionary is very hard to model with a concrete structure, sometimes words are pronounced differently depending on which meaning is being used, in addition to regional variations. I submitted a proposal at http://strategy.wikimedia.org/wiki/Proposal:Dictionary_extensions that included an outrageously simple API idea - once we have something simple that works, then we can work on something more useful. Conrad.Irwin 20:59, 24 September 2009 (UTC)

Sounds like a plan. I didn't know about the strategy.wikimedia.org page prior to this, so thanks. Ohms law 19:04, 26 September 2009 (UTC)

[edit] Allowing users to opt out of etym.-template auto-catting

{{etyl}} allows users to opt out the autocategorisation it performs when its second parameter is left blank, by using a hyphen instead, thus: {{etyl|[lang]|-}}. However, the same is not true of {{ML.}} nor, I imagine, of the other dialectal etymology templates we still have; inputting {{ML.|-}} causes it to try to categorise an entry in Category:-:Mediaeval Latin derivations. Could someone add this necessary functionality to those templates please? Thanks. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 16:46, 26 September 2009 (UTC)

If someone does this, could they also add support for the sort parameter at the same time? — Carolina wren discussió 14:57, 2 October 2009 (UTC)

Done. Check out Wiktionary:Language codes#Dialects for the list of all the old dot-style etymology templates that now work have etyl:* versions that work with {{etyl}}. --Bequw → ¢ • τ 03:28, 6 October 2009 (UTC)

[edit] Is there a simple way to get the equivalent of .. to work in template calls relative to the template, not relative to the page that calls the template

I'm currently working on improving the Catalan conjugation templates.

In hopes of obviating the need to make further edits when they get moved, I'm using some relative paths.

Originally I had User:Carolina wren/ca-conj-car making a call to {{../ca-conj-ar}}, which as expected was picking up User:Carolina wren/ca-conj-ar.

Then on the talk page I was calling {{{{SUBJECTPAGENAME}}|tren|head=trencar}} to generate an example of usage. This generated a complaints of a looping error in User:Carolina wren/ca-conj-car and an inclusion of User talk:Carolina wren/ca-conj-ar.

Hardcoding ca-conj-car to use {{User:Carolina wren/ca-conj-ar}} fixed the problem, and I think I understand why. The .. was being interpreted relative to the page that called the the template, not to the template itself. Is there a simple way to do what I want done?

{{BASEPAGENAME}} is not suitable, since once moved into template space, a call to {{{{NAMESPACE}}:{{BASEPAGENAME}}/ca-conj-ar}} would be the same as {{Template:ca-conj-car/ca-conj-ar}} instead of {{Template:ca-conj-ar}} as desired. Even if {{BASEPAGENAME}} did return blank, it still wouldn't work as it would invoke {{Template:/ca-conj-ar}}.

I could generate some overly complicated template code to do what I want, but the complexity would be such that hardcoding the path and editing before or after the move would be simpler. — Carolina wren discussió 04:28, 27 September 2009 (UTC)

Hardcoding the path is the only easy way I know of. Conrad.Irwin 11:02, 27 September 2009 (UTC)

[edit] Removal of fam= from langcatboiler

The parameter fam= from {{langcatboiler}} has served the purpose of adding a language category to a language family category. For example, Category:English language uses {{langcatboiler}} to be in Category:West Germanic languages. I removed this parameter, it is no longer working. Instead, language categories are automatically added to language family categories through a separate list at {{langfamily}}. So, from now on, please use the list instead of the parameter. This removal was done for two reasons: (1) because the separate list facilitates reviews and editions in high quantity, such as when cleaning up categories and (2) because the relationshionship between languages and families matters in other places than language categories. --Daniel. 04:59, 28 September 2009 (UTC)

By the way, I would highly appreciate if any bot removed the parameter fam= from all language categories that use {{langcatboiler}}, which are listed at these two links: 1 and 2. If no bot shows up, I'll remove them manually. Thanks in advance. --Daniel. 04:59, 28 September 2009 (UTC)

[edit] trreq

cantheypl autom.incl./display da iso-code?[sohard2 findit,c bo at Gangtok fe-also,ithink4newbs weneed2spel out wewant thatcode i/the 1st input-blank,no? Can they please automatically include/display the ISO-code (so hard to find it, see bo (Tibetan) at Gangtok for example - also, I think for newbies we need to spell out that we want that code in the first input blank, no?
L☺g☺maniac chat? 13:34, 28 September 2009 (UTC)

[edit] Updating a category

I have just modified {{rfe}} and {{etystub}} to file entries only into language-specific categories. However, the change of the template has not yet taken effect. Is there a way I can let entries in a given category updated? Or will all these entries get updated, meaning recategorized, after some time automatically, after the server catches up? --Dan Polansky 11:32, 29 September 2009 (UTC)

They will update eventually; it's just a matter of how much other stuff is in the job queue, I believe. -- Visviva 14:15, 29 September 2009 (UTC)

[edit] The "compound" template

Hello.

I have an idea - sometimes it is more useful to have in the etymology section something that looks like that:

Compound of Zeit "time" + Schrift "writing".

Instead of something that look like that:

Zeit +‎ Schrift. "writings of the time"

The second result is what given by using the compound template. Maybe there's a simple way to extend the compound template, such that syntax like that will be optional:

{{compound|Zeit (time)|Schrift (writing)|lang=de}}

but that might be too complex to make; if so, maybe something less comfortable like:

{{compound|Zeit|Schrift|t1=time|t2=writing|lang=de}}

What do you think? Peleg 14:09, 29 September 2009 (UTC)

You mean like this?

Zeit (“‘time’”) +‎ Schrift (“‘writing’”)

Don't thank me, just send money. ;-) -- Visviva 14:13, 29 September 2009 (UTC)

Danke!! :) Peleg 23:56, 29 September 2009 (UTC)

[edit] Telugu

Telugu translations suddenly break horribly since today, see for example eye. I have no idea how it happened and why it happens, but it should be fixed. -- Prince Kassad 15:50, 29 September 2009 (UTC)

Ack! ugh. committed bad typo. fixed. sorry ... Robert Ullmann 16:06, 29 September 2009 (UTC)

[edit] ‘dwe import w:CC-CEDICT?

no pos there,but~100,000entrys〉our chin. 'dget functional!!licens as ours--史凡>voice-MSN/skypeme!RSI>typin=hard! 06:29, 30 September 2009 (UTC)

No parts of speech there, but approximately 100,000 entries - our Chinese would get functional!! licensed as ours
100%,ta![sv1.10.9]

L☺g☺maniac chat? 14:02, 30 September 2009 (UTC)

Looks fantastic, and absurdly easy to import except for the POS issue (the fact that all their verb definitions start with "to" will be some help). But I do wonder if the fact that Wikt contributions are technically licensed under CC-BY-SA and GFDL might be problematic... that is, I'm not sure if being dual-licensed means that we can import from either license, or only from other dual-licensed works. It would suck to create 100,000 entries and then have to delete them, so I'd want to run that by someone who knows something -- particularly the Foundation, if they don't just blather about community self-determination like they usually do. -- Visviva 07:17, 30 September 2009 (UTC)

ic,ta--btwCEDICT4ja[4ko iduno

• isugested sync2'em2,but i/their gen.entry coment sectn[ihate doin'it manualy--w/theireaderMDBG,ican takl chin.texts!:p--史凡>voice-MSN/skypeme!RSI>typin=hard! 12:25, 30 September 2009 (UTC)

I see, thanks, - by the way w:EDICT, the original database, does the same for Japanese, 130,000 entries (for Korean I don't know)

• I suggested automated synchronisation (with en.wt) to them too, but did so in their general comment section in an entry (I hate doing it manually by copy/paste as today with Atitarev's beautiful 援助交際 entry!) -- with their w:MDBG-reader, , I can actually tackle Chinese texts! :P)
  

L☺g☺maniac chat? 14:02, 30 September 2009 (UTC) +--史凡>voice-MSN/skypeme!RSI>typin=hard! 16:27, 30 September 2009 (UTC)

I think that's w:CEDICT, not "c dict", in this case -- correct me if I'm wrong. I can't speak to the situation in Japanese, but I'm fairly sure that no such project exists for Korean. There are a few PD Korean "dictionaries" floating around, but they are a) very small, and b) not very good. I had assumed CEDICT would be similarly deprived, but wow, was I wrong. -- Visviva 14:30, 30 September 2009 (UTC)+i lnkd--史凡>voice-MSN/skypeme!RSI>typin=hard! 17:24, 30 September 2009 (UTC)

Oh, sorry, I didn't know of that. L☺g☺maniac chat? 18:00, 30 September 2009 (UTC)

The licensing change happened while I was off-wiki and not really paying attention, but looking around a bit I found m:Licensing update/Questions and Answers. Judging from this, it should be fine to import CC-BY-SA content as long as the licensing status is noted in the version history. I trust we would want to have some sort of attribution template in the entry as well.

Their data is extremely portable; I expect I could have something running, at least for the verbs, in less than 15 minutes... but it would be good if we could get some additional feedback from the Chinese specialists as to any potential issues. Plus there will need to be a bot vote, of course. I'll see what I can do about running a little test in my userspace. (If anyone else would prefer to handle the botting, please feel free.) -- Visviva 14:30, 30 September 2009 (UTC)

fuly fnctnl chin db/dict~200,000entrys igues,due2al the abr.+slang[cedict stil sux w/tw news, fe fashion:V溝/decollete nothere,fact i/genrl which ihad2tel'em ofcors i/my frustration,me withmy zijn hart op zijn tong dragen,but w/the w:zh.wp-articls itried the reader-facilitatd use oftheir db works wondrs!],so1/2way there!!:D[sofar my3G shrthnd(c i lisn2fb guys!?),vois-uploadin'ison my2do list..

• ta4carin'lm+visv.!:)--史凡>voice-MSN/skypeme!RSI>typin=hard! 17:24, 30 September 2009 (UTC)

Fully functional Chinese database/dictionary about 200,000 entries I guess, due to all the abbreviations and slang (w:CEDICT still sucks with Taiwanese news, for example fashion: V溝 / decollete not there, fact in general which I had to tell them of course in my frustration, me with my zijn hart op zijn tong dragen, but with the w:zh.wp - articles I tried the reader - facilitated use of their database works wonders!) so halfway there :D (So far my third-generation shorthand (see I listen to feedback, guys!?), voice-uploading is on my to do list .... thanks for caring Logomaniac and Visviva! :)

Don't thank me, please. L☺g☺maniac chat? 18:00, 30 September 2009 (UTC)

[edit] Sound template bot

Hello all,

I have a question about creating a bot. I would like to create a bot for the Dutch Wiktionary (nl.wiktionary.org) that adds a sound template if a sound file is available on Commons. It also removes a sound template if the link is red (also: the sound is not available on Commons). I saw you are running bots that do this, like this one. Now I have the following question: can someone tell me how to make a bot that does this (or if it's possible with and AWB plugin, how do I make one?). Thanks in advance for more information!! Kind regards, Tvdm 16:11, 30 September 2009 (UTC)

[edit] the "de-noun" template

Hello.

I suggest to extand the de-noun template to allow a female form at the end of the line. For example, the calling of

{{de-noun|g=m|pl=Kellner}}

will now present:

Kellner m. (genitive Kellners, plural Kellner)

I suggest that one will be able to enter

{{de-noun|g=m|pl=Kellner|f=Kellnerin}}

so he will get:

Kellner m. (genitive Kellners, plural Kellner) (female: Kellnerin)

What do you think? I see it written in many places, without the use of a template, which might make it easier and more standard. Peleg 18:45, 30 September 2009 (UTC)

I think we could even create a completely new template for that. -- Prince Kassad 19:03, 30 September 2009 (UTC)

Maybe this output is better:

Kellner m. (genitive Kellners, plural Kellner, female Kellnerin)

Peleg 12:55, 1 October 2009 (UTC)

You could even put the female plural in hat same line. That way we don't need to create the same entry for male and female, but one for the male and a "form of" for the female. Obviously, female-only words like Hebamme would be excluded. -- Prince Kassad 15:04, 1 October 2009 (UTC)

I am not sure how to edit that template, but I'll have a look. Peleg 20:48, 2 October 2009 (UTC)

Ok, this is too complex for me... sorry... Peleg 21:40, 2 October 2009 (UTC)

It also might be a good idea to add the dative plural (-en suffix) into the template. --Volants 12:42, 16 October 2009 (UTC)

[edit] October 2009

[edit] Unicode 5.2

FYI: Some may known already, but Unicode 5.2 was finalized and released earlier today. Of particular interest to lexicographers, it adds seven new scripts as well as many supplemental characters to existing ones for a total of 6,648 new characters. See Unicode 5.2.0 for details. Bendono 23:59, 1 October 2009 (UTC)

[edit] Adding Template:Navbox CSS to MediaWiki:Monobook.css

I used Template:Navbox for the new style of Template:index/American Sign Language, but I had to transfer it from the other wiki. As a result, only the base code came, and it relied on classes which don't exist here. As a result, I had to add them manually as element:styles, the result of which is at best an ugly hack. Can we have the relevant classes from w:MediaWiki:Monobook.css copied to our version so that the navbox can use the classes instead (and therefore be customizable, like the rest of our interface, &c, &c.)? —Di gama (t • c • w) 07:18, 2 October 2009 (UTC)

[edit] issues with multiple right-floating things

When more than one right-floating elements (e.g. {{wikipedia}} and an image) are included in an entry, they often leave visually unattractive blank spots (see here). It's sometimes possible to displace it by moving the images around, but that gets harder with every additional image. What can be done about this? —Internoob (Talk•Cont.) 19:15, 3 October 2009 (UTC)

Some elements such as the old non-hidden tables {{top}} and {{rfp}} (or {{rfap}}?) don't play nice with rhs floating elements and should be fixed to do so. The sister project boxes can be replaced by the less conspicuous PL items (eg, {{pedialite}}) under "See also". Except possibly for a {{wikipedia}} that take a user to a disambiguation page (serving a function like {{also}}), I don't think sister project boxes should ever be above the first language header. Nor should images usually. DCDuring TALK 19:54, 3 October 2009 (UTC)

The problem seems to be limited to IE, or at least I don't see it in FF 3.5.3. —Di gama (t • c • w) 03:30, 4 October 2009 (UTC)

The problem is indeed limited to IE. It isn't a problem in Firefox, Opera, or Safari. --EncycloPetey 15:39, 4 October 2009 (UTC)

I didn't look at the specific Sandbox demo. In the particular case, replacing the "wikipedia" template with a "pedialite" template shortens the rhs by ~3/4" and lengthens the lhs by 3/8" reducing the imbalance by ~1". Usually we don't have more than one image. The vertical stacking of multiple rhs objects in a short entry can only be definitively addressed by some kind of placement conditional on the length of the page. I wonder if that is something that can be done via Javascript. Conditional rendering seems like a high price to pay for a problem limited to short entries with large stacks of images and sister project boxes, especially since the sister project boxes can readily be placed in "See also", as many here prefer.

I wonder whether we could allow for {{also}} to include a link to a WP page, especially to disambiguation pages there. WP has vastly more complete coverage of proper nouns than we do (and should, for that matter, IMHO) and sometimes user may be looking for them. DCDuring TALK 13:45, 4 October 2009 (UTC)

That isn't always a solution. Consider the page for needle, which has images of both sewing and medical needles, and which really does need both to be illustrated. The vertical stacking will cause a problem in IE unless Windows 7 has fixed this problem. --EncycloPetey 15:39, 4 October 2009 (UTC)

For longer entries the appearance problem isn't as ridiculous, at least. I use FF 3.5.3 I have some layout problems with {{top}} which can be addressed by substituting {{rel}}. I have made the substitution and also deployed {{xsee}} instead of {{wikipedia}} at needle. Does that help with IE? DCDuring TALK 18:03, 4 October 2009 (UTC)

Urgh. That also has problems. For one, it doesn't identify the language of the linked Wikipedia. If a page has more than one language entry on it, that becomes a real problem. Including the language would make the link even messier, though. --EncycloPetey 04:01, 5 October 2009 (UTC)

I fixed that problem by using {{xsee}} to apply {{pedialite}}. Since it's inline, there aren't any visible rendering problems. I did have to suppress xsee's tendency to bold its parameters, though. This solution allows for other languages too. —Di gama (t • c • w) 04:12, 5 October 2009 (UTC)

P.S. A problem I just noticed with this method is that I can't remove the terminal full stop, so it would only look good at the end (of the see also list), so more than one WP link wouldn't work. Of course, the full stop could always be removed or made conditional. —Di gama (t • c • w) 04:18, 5 October 2009 (UTC)

 Zorse on Wikipedia

Wikipedia

I think langauge-specific links should be kept inside the language headers (not used in {(x)see}). What about using a slimmer version of {{wikipedia}}, such as the one to the right? —This unsigned comment was added by Bequw (talk • contribs).

Now at {{slim-wikipedia}} for people to play with. --Bequw → ¢ • τ 17:35, 8 October 2009 (UTC)

The slimmed one is certainly an improvement, especially for near top-of-the-entry use. Questions remain.

1. Should any WP template appear above the first language line? I would argue that we should have a link to a en.WP dab page that contained links to Proper nouns that en.wikt does not have (by policy or otherwise). From a user perspective I think such a link is very like the {{also}} or {{xsee}} links which we have above the first language header.
2. Should we try to minimize the space taken by top-of-the entry material by keeping it to the left of the rhs ToC, images, {{examples-right}}, and the other sister project links. That is, should we use {{xsee}} to contain any top-of-the-page link to WP?
3. Should we deprecate the large sister project boxes altogether?
4. Should the See also heading (the home for sister project links if sister project boxes are deprecated) continue to appear after translations. DCDuring TALK 19:44, 7 October 2009 (UTC)

[edit] hav'otha ppl2 probs w/FF353?

its ofn'not respondin'..--219.69.83.119 02:51, 6 October 2009 (UTC)

When did the problems that you have begin? --EncycloPetey 02:53, 6 October 2009 (UTC)

sins igotit~somweeks ago-2day4restarts onmy slowlaptop[took 2hrs!,butnow usinOpera2rite this[which dontdo dropdowns+has brite diff-screens,argh!--史凡>voice-MSN/skypeme!RSI>typin=hard! 03:17, 6 October 2009 (UTC)

That's around the time that MW did a major software update (Sep 16/17). It broke a lot of the bots too. I don't know what solution to suggest (I don't use FF), but it's probably not a problem limited to just you. --EncycloPetey 03:29, 6 October 2009 (UTC)

u use?btw,i'd/had2re-input'wt;pref'i/Op.-=not browser-INdep?sory4spelin,ta4repls!

• o-thisFFvsn also dsnt restablishmy tabs onrestrt>probs=notjust w/wt,but genrl..--史凡>voice-MSN/skypeme!RSI>typin=hard! 04:06, 6 October 2009 (UTC)

Which one do you use? By the way, I had to re-input WT:PREFS in Opera - such not browser-independent? Sorry for my spelling, thanks for replies! Also, this FireFox version also doesn't reestablish my tabs on restart > problems not just with Wiktionary, but of general nature...

L☺g☺maniac chat? 13:34, 6 October 2009 (UTC) +--史凡>voice-MSN/skypeme!RSI>typin=hard! 14:25, 6 October 2009 (UTC)

[edit] Wiktionary mobile

Wiktionary on mobile is shocking or doesn't load at all, I tried on different mobile phones. Logging in requires an extra page load to get to the page you want originally. Any plans to make it friendlier on mobile phones? Not that one could contribute much on mobile phones but reading answers or checking watchlists would be good to have, more importantly - simply using for users. --Anatoli 03:44, 6 October 2009 (UTC)

Is this a Wiktionary-only problem, or does it happen with Wikipedia as well? --EncycloPetey 03:47, 6 October 2009 (UTC)

Wikipedia is OK but I only looked at articles, not special pages. On my Nokia 6700, the main frame gets really narrow, breaking short words in half, so that my watchlist (with many suppressions) looks incredibly long (from top to bottom). Anatoli 04:03, 6 October 2009 (UTC)

[edit] Category:Min Nan

This whole lot needs to go into the correct category here. If anyone thinks they can correct the related templates (starting with nan) please do, then these whole lot will be in the right category. For the subcategories like nan-tw:Conjunctions, as dialects, these are wrongly named too, right? Mglovesfun (talk) 17:15, 8 October 2009 (UTC)

Yes, these were misnamed, but we never sorted them out. The issus with (e.g.) "nan-tw" is that it is not a dialect, but a script difference (Min Nan in traditional script) and we didn't sort out naming of these. (We = me, A-cai, and a few others.) Does need sorting, these are, of course, not topic categories. Robert Ullmann 01:06, 10 October 2009 (UTC)

Subcategories moved into Category:Min Nan language. There's still much to cleanup, but at least it's all in the same place. --Bequw → ¢ • τ 04:02, 13 October 2009 (UTC)

[edit] tbot, and various stuff

I've been doing work on Tbot (which you may have noticed). And fixing some other things. I had a flaming power strip yesterday morning, you might have noticed some service interruption ;-)

Tbot is eliding script parameters when not needed (and mostly when doing other things). I've also added a bit to the {{t-sect}} optimization. (Which, as a reminder, should only be used with {{t}}.)

Tell me if you see any anomalies. If I'm not apparently around, send SMS +254 722 929 463.

Should be okay :-) Robert Ullmann 01:03, 10 October 2009 (UTC)

[edit] Templates

Is there any guide somewhere to whatever the language is that templates are written in? I have never really understood all the #ifs and #eqs, and those seemingly endless iterations of curly brackets. But I would rather not have to ask someone every time I want to create a new one of any level of complexity. Ƿidsiþ 12:22, 10 October 2009 (UTC)

http://www.mediawiki.org/wiki/Templates is a good starting point, and you'll also want to read up on http://www.mediawiki.org/wiki/Help:Parser_functions_in_templates and http://www.mediawiki.org/wiki/Help:Extension:ParserFunctions, for even more stuff there's http://www.mediawiki.org/wiki/Help:Magic_words . Conrad.Irwin 12:27, 10 October 2009 (UTC)

Thanks. That's helped a lot. Ƿidsiþ 13:05, 10 October 2009 (UTC)

[edit] Trennbare Verben

I have added the template {{de-trennbar}}, to allow a prettier representation and categorization of trennbare Verben, such as anmelden.

I'd like to hear your opinions. Thanks, Peleg 10:22, 14 October 2009 (UTC)

I've added {{de-verb-strong}} to allow this nicely for strong verbs (such as ansehen) as well. Peleg 12:13, 14 October 2009 (UTC)

[edit] etw. jmdn. etc.

I've added the templates {{etw}} and {{jmdn}} (as examples) to use it in a proper way with the <abbr> tag. I find it nice and useful. Look here: interessieren and tell me what you think. Thanks! Peleg 12:15, 14 October 2009 (UTC)

[edit] "WT:" become equivalent to "Wiktionary:"?

The English Wikipedia (and maybe other Wikipedias too, I don't really know) has an interesting feature which makes typing "WP:" in the search bar be identical to typing "Wikipedia:", meaning that typing in "WP:Administrators" into the bar brings you straight to "Wikipedia:Administrators" and even has "Wikipedia:Administrators" appear in the dropdown list as it's being typed. Is there any way this could be implemented on Wiktionary, so that "WT:" appears as "Wiktionary:"? I know that most pages in the Wiktionary namespace have shortcuts, but quite a few don't and those that do aren't the easiest things to remember... --Yair rand 00:03, 15 October 2009 (UTC)

But you can already use Special:AllPages for that. I find the search window tool more useful as it currently stands, allowing me to quickly determine whether there is a page beginning with that sequence of letters. I can understand the utility on an encyclopedic site like Wikipedia, but on Wiktionary, where every word should eventually have an entry, that kind of redirect could lead to problems, especially if there are abbreviations beginning with "WT:" in any language. --EncycloPetey 01:48, 15 October 2009 (UTC)

But we already have wt: as a dedicated namespace, so we already can't really use it for entries, in that it won't show up in main-space dumps and therefore won't show up on mirrors, won't get handled properly by interwiki-bots, etc. I agree with Yair rand that there's no reason it should be its own namespace, rather than an alias for the project namespace, now that the software supports that sort of aliasing. (Dunno what we have to do to make that work, though.) (But it looks like we'd need to have a developer make the change: mw:Manual:$wgNamespaceAliases.) —Ruakh_TALK 02:20, 15 October 2009 (UTC) edited 02:25, 15 October 2009 (UTC)

I did not realize that WT: was its own namespace, in which case my concerns are moot. --EncycloPetey 02:22, 15 October 2009 (UTC)

Yeah, it's kind of the "bastard child" of namespaces. —Ruakh_TALK 02:25, 15 October 2009 (UTC)

So how does one request that a developer make a change like that? --Yair rand 12:36, 16 October 2009 (UTC)

And if we do change that, we might as well also change WS: to be equivalent to Wikisaurus: as we have no simple way to go to those pages. --Yair rand 23:01, 20 October 2009 (UTC)

[edit] Template that uses Special:Index

What's that tidy template that allows you to find all your subpages and uses the page above as a base? Cheers. Mglovesfun (talk) 14:27, 16 October 2009 (UTC)

Well, there's Special:PrefixIndex. Is that what you were looking for? L☺g☺maniac chat? 15:03, 16 October 2009 (UTC)

It is, but I'm talking about a template I have seen before. Mglovesfun (talk) 15:19, 16 October 2009 (UTC)

oh. Well that I don't know. :) L☺g☺maniac chat? 15:25, 16 October 2009 (UTC)

{{subpages}} Conrad.Irwin 17:42, 16 October 2009 (UTC)

[edit] Insertable templates not working?

The insertable items in the "templates" section when editing an entry seem to be broken. (I'm using Opera 9, and always was.) Since a few weeks ago, each space-delimited word is separately clickable and inserts itself alone, e.g. {{alternative spelling of|}} is three separate links that just insert their own text, rather than being a single link that is inserted as a whole template. Why has this changed? Equinox ◑ 20:12, 17 October 2009 (UTC)

They're working for me in Safari on a MacBook. It may be a Preferences issue, or else Opera-specific. --EncycloPetey 01:58, 20 October 2009 (UTC)

The odd thing is that I haven't upgraded my Web browser or (as far as I recall) changed my preferences. Equinox ◑ 03:49, 20 October 2009 (UTC)

*sigh* because browsers hate me? The culprit is (presumably) my edits to MediaWiki:Edittools. It seems that there are more differences than I expected among various browsers in handling of non-breaking spaces. (I've already had to make changes to the code to address discrepancies between Safari and Firefox.)

It should work again now. I'll have to decide whether I want to (1) download Opera to figure out exactly what its issue is, (2) take a different approach entirely, or (3) give up.

—Ruakh_TALK 03:49, 20 October 2009 (UTC)

Yes, it works again. Thanks. As far as I know, Opera is generally very standards-compliant and should have a decent JavaScript/ECMAScript implementation. But if you would like me to try any particular mini-script to diagnose this issue, feel free to contact me. Equinox ◑ 03:51, 20 October 2009 (UTC)

[edit] Schönfliess

I was putting in some crystallographic term at nl.wikt like nl:draaispiegelas. When doing that you easily get into the notations for point and space symmetry groups like S₄ or I4₁/amd or so. Although I am not looking forward to putting in all 230 space groups or so, I do think an article explaining what a symbols like S₄ stands for would be nice. Problem is: how do you get a superscript into an article name? Is there a way to do that? Jcwf 20:48, 17 October 2009 (UTC)

We seem to have used the characters ₂,₃,₄ on occasion (e.g. H₂O), but it doesn't seem ideal and I don't know whether they go up to 9. Equinox ◑ 20:58, 17 October 2009 (UTC)

Thanks Equinox, actually if there is a six that would pretty much do for most crystallography, although some symbols have _{h, v or d} Jcwf 22:03, 17 October 2009 (UTC)

They do go up to nine. Appendix:Unicode/Superscripts and Subscripts There's also a subscript v, but none of the other letters you mentioned. (However, they will be encoded in Unicode 6.0 which will be released in 2011, so you might want to wait until then) -- Prince Kassad 22:42, 17 October 2009 (UTC)

[edit] Shorthand for "capitalise first letter of link"

Considering how often it comes up — any time you want to link the first word of a definition — I think it would be good to have a shorthand for a link whose first letter is to be capitalised in the display, e.g. [[\sulphuric acid]] might produce [[sulphuric acid|Sulphuric acid]]. Is it practical, desirable? Equinox ◑ 19:14, 19 October 2009 (UTC)

I can't imagine the developers doing anything to wikisyntax at this point that would cause existing good links to go bad just to add a shortcut, so it probably would have to be a parser function which wouldn't be that much of a shortcut. The only alternative I can think of would be to give a purpose to the redundant [[|sulphuric acid]] which currently gets saved as [[sulphuric acid]], so it wouldn't affect direct coding, tho it might affect a substitutable template that made use of that redundancy. — Carolina wren discussió 00:27, 20 October 2009 (UTC)

It ought to be possible to set up a simply-named template like: {{1|F|f|irst}}. That is, if a template name can begin with a numeral, we can set up a template that swaps the first letter out for the link/text. We need the template rather than automation. Relying on automation could send the user to a German noun by mistake. --EncycloPetey 01:56, 20 October 2009 (UTC)

If we go with a template, there wouldn't be any need to specify both the lower and upper case letters as separate parameters. [[{{{1}}}|{{ucfirst:{{{1}}}}}]] would be the simplest code version of this, sans any bells and whistles such as non-Latin script or foreign language entry support, and needs only one parameter, the entry to be linked to. — Carolina wren discussió 05:28, 20 October 2009 (UTC)

If a template is created, it should always be used with subst: (otherwise, it would make the contents less readable and loading the page would be slightly longer, without any good reason). Lmaltier 19:31, 20 October 2009 (UTC)

Template:1's been created. Please tweak as needed.​—msh210℠ 14:24, 29 October 2009 (UTC)

[edit] Creating pages on ar.wiktionary

I have no trouble creating or editing pages on ar.wikipedia and no trouble editing pages on ar.wiktionary but every time I try to create a new page on ar.wiktionary, I end up downloading some index.php . There are other Arabic Wiktionarians who do not have this problem. I have tried different browsers and computer systems but I still get the same results. Can anyone explain what is going on? :)--Thecurran 09:21, 20 October 2009 (UTC)

Does anyone on English Wiktionary also edit on Arabic Wiktionary? :)--Thecurran 15:40, 25 October 2009 (UTC)

You should provide a link to an example of this. Nobody knows what you mean. —Stephen 22:42, 31 October 2009 (UTC)

Could your browser be misconfigured? It should be displaying the page content of index.php rather than prompting you to save it to disk. Equinox ◑ 22:52, 31 October 2009 (UTC)

In Arabic, the creation link for ألبانيا is http://ar.wiktionary.org/w/index.php?title=ألبانيا&action=edit or without diacritics, البانيا is http://ar.wiktionary.org/w/index.php?title=البانيا&action=edit . In English, Albania- is http://en.wiktionary.org/w/index.php?title=Albania-&action=edit . In Spanish, Albania- is http://es.wiktionary.org/w/index.php?title=Albania-&action=edit . In French, Albanie- is http://fr.wiktionary.org/w/index.php?title=Albanie-&action=edit . In Russian, Албания- is http://ru.wiktionary.org/w/index.php?title=Албания-&action=edit . In Chinese, 阿尔巴尼亚 is http://zh.wiktionary.org/w/index.php?title=阿尔巴尼亚&action=edit or in Traditional, 阿爾巴尼亞 is http://zh.wiktionary.org/w/index.php?title=阿爾巴尼亞&action=edit . I thought I would be able to create all of these pages if I was logged in. Of course, I would not create the ones that end in hyphens or nine. Can you two or anyone else trigger the Arabic links appropriately once you're logged in to the Arabic Wiktionary? :)--Thecurran 13:36, 1 November 2009 (UTC)

In Arabic Wikipedia, ألبانيا9 is http://ar.wikipedia.org/w/index.php?title=ألبانيا9&action=edit . In English, Albania- is http://en.wikipedia.org/w/index.php?title=Albania-&action=edit . In Spanish, Albania-http://es.wikipedia.org/w/index.php?title=Albania-&action=edit . In French, Albanie- is http://fr.wikipedia.org/w/index.php?title=Albanie-&action=edit . In Russian, Албания- is http://ru.wikipedia.org/w/index.php?title=Албания-&action=edit . In Chinese, 阿尔巴尼亚- is http://zh.wikipedia.org/w/index.php?title=阿尔巴尼亚-&action=edit . :)--Thecurran 14:32, 1 November 2009 (UTC)

Is there anything that bars editors from creating articles in a wiki before doing other types of edits there? :)--Thecurran 14:36, 1 November 2009 (UTC)

[edit] Wikisaurus

I have long wondered why certain Wikisaurus entries (like Wikisaurus:machine) have odd blue dotted lines halfway across the page from all the words. Recently, while using the Firefox browser instead of my usual Google Chrome, I noticed that the lines actually appear under the words in that browser. Anyone know why it messes up in Chrome and how this can be fixed? --Yair rand 19:21, 20 October 2009 (UTC)

Seems to be an obvious css bug on Chrome's part, though I do not know how we can fix it. For the record, the dotted line indicates the presence of a tooltip giving a short definition. Circeus 04:55, 20 November 2009 (UTC)

[edit] User:Visviva's preloadText into site JS

Now that preloadText is being used by creation.js (only for esperanto at the moment, but probably for more languages as time goes by) and by various other projects we have - would it make sense to put a version of it into Common.js? Conrad.Irwin 00:26, 23 October 2009 (UTC)

[edit] Polish ł

Is it possible, for the Polish letter ł to appear in the search results when I type l? It would be cheaper, than to buy me a Polish keyboard. --Volants 13:30, 23 October 2009 (UTC)

Buy a Polish keyboard. (In other words, no, it's impossible) -- Prince Kassad 13:35, 23 October 2009 (UTC)

Shame. Maybe I can petition the WMF who can buy one for me, as a scolarship of something. They do that sort of thing, don't they? Or get some free software, I'll look for it... --Volants 13:41, 23 October 2009 (UTC)

I'm wondering why you can't use the Polish keyboard layout with your US (?) keyboard. -- Prince Kassad 13:43, 23 October 2009 (UTC)

Try WT:PREFS "show a special character input (like the one beneath the edit field) for the search field). Conrad.Irwin 14:35, 23 October 2009 (UTC)

You can install Polish Keyboard layout in Control Panel if you are using Windows. Maro 22:16, 23 October 2009 (UTC)

I've chosen Conrad.Irwin's suggestion. Thanks. This money I've saved will now be spent on something better. Maybe for a microphone. --Volants 12:14, 26 October 2009 (UTC)

[edit] Edittools

Currently, the Latin/Roman section is sorted by diacritic. While this is pretty nice, I think it would be much more intuitive and easier to search through if all the letters were simply sorted alphabetically. That way you don't have to look through the entire section to find your character, but just snap to where the base character appears and look in there. Any comments? -- Prince Kassad 18:33, 24 October 2009 (UTC)

The sorting by diacritic serves two purposes: it helps you find the character you're looking for, and it lets you know what a given character is. Your suggestion might help the first purpose, but I think it could significantly harm the second one. (I don't think I could reliably distinguish ǎ from ă, for example, at normal font sizes.) —Ruakh_TALK 06:54, 25 October 2009 (UTC)

Hm, this is an interesting point. The problem is that currently nobody uses the Latin/Roman section simply because it's so counter-intuitive, so it should be redone in some way. If differentiation is an issue, maybe we should make the section a table. -- Prince Kassad 14:20, 25 October 2009 (UTC)

Or in a larger font.​—msh210℠ 14:15, 29 October 2009 (UTC)

That would look horribly ugly. -- Prince Kassad 18:39, 29 October 2009 (UTC)

[edit] Template:frm-noun

Could someone please add an f= and fp= parameter for this (with an #if) for adding feminine singular and plural form. See this edit if you're unsure of what I'm on about. Mglovesfun (talk) 11:36, 27 October 2009 (UTC)

Huh? You mean like adding {{#if:{{{f|}}}|, ''feminine singular'' '''[[{{{f}}}]]'''}}{{#if:{{{fp|}}}|, ''feminine plural'' '''[[{{{fp}}}]]'''}} before the end bracket? --Yair rand 15:48, 27 October 2009 (UTC)

I'm not exactly sure if that's what you meant, but I added it to the template. Should I also add m= and mp= parameters to it? I notice that on amye you just added (m: amy) at the end of line. --Yair rand 16:22, 27 October 2009 (UTC)

I'd say no; we don't do that with other templates like fr-noun. Mglovesfun (talk) 17:53, 27 October 2009 (UTC)

[edit] Python bot broken?

Hello. I'm planning to rerun User:Dawnraybot, but the bot isn't working. According to Metawiki all bots are Wikimedia bots are broken since September. But I've seen other bots working here. What to do? --Rising Sun 09:54, 29 October 2009 (UTC)

• SemperBlottoBot is working normally. What are the symptoms? SemperBlotto 09:56, 29 October 2009 (UTC)
  • I try to login using login.py, and it flashes with somehting like "runtime error. Bad magic number in .pyc file" (but it is hard to read, because it flashes for a millisecond). My updated user-config.py is:

use_api = True
mylang='en'
family='wiktionary'
usernames['wiktionary']['en']='Dawnraybot'
console_encoding = 'utf-8'
put_throttle = 0

Also, when I try to run the frfromfile.py, error message is

Traceback (most recent call last):
  File "pywikipedia\frfromfile.py", line 37, in <module>
    import wikipedia, config
ImportError: Bad magic number in G:\WT\pywikipedia\pywikipedia\wikipedia.pyc

The question is, what is a magic number, and how do I make it a good magic number? --Rising Sun 10:04, 29 October 2009 (UTC)

• SemperBlottoBot doesn't use "use_api = True" - so try using the old technology. SemperBlotto 10:09, 29 October 2009 (UTC)
  • OK, I took out that line. This time I've got this error message.

Traceback (most recent call last):
  File "G:\WT\pywikipedia\pywikipedia\user-config.py", line 3, in <module>
    usernames['wiktionary']['en']='Dawnraybot'
NameError: name 'usernames' is not defined

I remember this one from the first time I tried to set up - but I don't remember what I did when that happened before.--Rising Sun 10:16, 29 October 2009 (UTC)

You probably need:

usernames = {}
usernames['wiktionary'] = {}
usernames['wiktionary']['en'] = 'Dawnraybot'

or equivalently:

usernames = {'wiktionary': {'en': 'Dawnraybot'}}

Conrad.Irwin 11:24, 29 October 2009 (UTC)

Tried those, same error. I might just reinstall everything from scratch instead. --Rising Sun 12:28, 29 October 2009 (UTC)

Can be fixed somehow; I'm using stuff; let me sleep any try to catch you in my daytime ;-) Robert Ullmann 01:01, 30 October 2009 (UTC)

Bad magic number means the .pyc file wasn't compiled with the same version of Python (or was corrupted somehow). Normally Python will automatically recompile if the magic number is an older version. Did you downgrade the Python version? You can always just delete the offending .pyc file and let it rebuild it.

Re-syncing the pybot framework from SVN is probably a good idea. The "use_api" setting shouldn't (can't) be messing up the "usernames" (is just somehow masking it with an earlier error).

You certainly don't need to create the usernames array; config.py does that, and then execs user-config.py. You might try excuting config by itself, as a main program it should dump out all the settings, including what is in user-config. If it faults, that will be interesting. Robert Ullmann 16:33, 30 October 2009 (UTC)

I see you've gotten it working ;-) Robert Ullmann 12:24, 31 October 2009 (UTC)

[edit] Service interruption

For some unknown (and previously unseen) problem service is down here; this affects AF, Tbot, Interwicket. All of which recover normally from problems of less than 48 hours, and eventually from problems of any duration.

My apologies. It is 4AM here, I will chase this in a few hours when everyone (else) is awake! Robert Ullmann 00:56, 30 October 2009 (UTC)

Should be normal now. Robert Ullmann 16:17, 30 October 2009 (UTC)

[edit] Create a Template:wrong script (or not)

I was thinking of alter kaker which is "Yiddish", apart from Yiddish doesn't use the Latin script. Why not create a {{wrong script/box}} per {{nolanguage/box}}. Either that, or it's possible to merge the three ({{notenglish/box}}) but I can't think of any decent reason to do so. Mglovesfun (talk) 16:26, 31 October 2009 (UTC)

[edit] November 2009

[edit] Page Wiktionary:All Wikisaurus pages WT:WSI needs a technical fix

This page has some sort of script to display all the pages in Wikisaurus. However, since the number of Wikisaurus entries now exceeds the number that can be displayed on one page, the list runs out at G.

Anyone know how to get this page to list all the Wikisaurus entries ? --Richardb 22:46, 1 November 2009 (UTC)

Someone "merged" the code for Special:AllPages and Special:PrefixIndex a while ago, in the mistaken idea that they were improving things; they broke a number of things in the process, and now no-one seems to be interested in fixing any of them. You could go enter a bug asking that the two functions be separated again, and proper function restored, but don't expect anything to happen ... Robert Ullmann 15:31, 4 November 2009 (UTC)

Can anyone give me a pointer or link to "enter a bug" ?--Richardb 00:38, 14 November 2009 (UTC)

Try bugzilla: -- Prince Kassad 11:13, 14 November 2009 (UTC)

[edit] New RC patrolling concept

Hello, is there any needs to add the site in https://bugzilla.wikimedia.org/show_bug.cgi?id=21517? JackPotte 13:03, 15 November 2009 (UTC)

I don't think we trust people enough to let anyone patrol edits, particularly given how stringent we are over formatting. Conrad.Irwin 13:36, 15 November 2009 (UTC)

I'd prefer this system to flagged revisions, simply because we can see a ! directly into the RC list. Moreover, it's already used in fr.w, and it.wikt. JackPotte 19:31, 15 November 2009 (UTC)

[edit] Couple of things

1. There's been a request that {{fr-noun}} have a p2 option (2nd plural) like businessman has the plural businessmen or businessmans.
2. {{cite-book}} and other citations templates should have a translation parameter, right? See Citations:seignor.
3. There was a third thing, but I can't think of it right now

Mglovesfun (talk) 10:18, 20 November 2009 (UTC)

[edit] Chinese Cantonese and Mandarin use the same alphabet

Chinese Cantonese and Mandarin use the same alphabet, aside from trends that have resulted of illiteracy. All Chinese references should be grouped under one group.

So do German and English, should we group those two under ==Germanic== ? --Ivan Štambuk 13:28, 20 November 2009 (UTC)

Indeed. Mglovesfun (talk) 12:13, 21 November 2009 (UTC)

Non sequitur. Cantonese and Mandarin is not written in an alphabet. They both use a single logosyllabary, the Han script. 124.214.131.55 15:44, 21 November 2009 (UTC)

[edit] subbing western angle brackets w CJK

It appears that our angle bracket articles, 〈 and 〉, use CJK brackets (U+3008/9) rather than Western ones (U+2329/A). This appears to be a technical problem, because I'm taken to the same page regardless of which I enter into the search window, and when I tried correcting them at Template:punctuation, it didn't even register as an edit.

Unicode deprecates U+2329/A for mathematical use because of their "canonical equivalence" to CJK punctuation U+3008/9. Could this be the source of the problem? There are non-math uses, such as in epigraphy, and SIL IPA fonts support U+2329/A but not the math bra-ket angle brackets, so this Unicode's note does not mean they are obsolete. kwami 02:45, 24 November 2009 (UTC)

I've run across this with the Greek semicolon (U+037E) being converted to the regular semicolon ';' (U+003B). Is this due to the Unicode standard or the mediawiki implementation? Is there a list somewhere of the ones that are automatically converted? This list should be public. It would be similar to Appendix:Unsupported titles. --Bequw → ¢ • τ 05:05, 25 November 2009 (UTC)

This is due to MediaWiki normalizing everything to NFC (see w:Unicode equivalence#Normalization). It is a "feature" designed to cope with the fact that unicode has multiple ways of representing the same character (i.e. á could be U+00E1 or U+0061 U+0301 — either an accented A, or an A and an accent). Sadly, some bright sparks decided that some characters are so similar that they should have the same canonical form, which really begs the question of why they exist in multiple places in the standard anyway (as far as unicode is concerned the characters are identical). This lose matching of characters behaviour was supposed to be defined by NFKC which is compatibility decomposition, in which ¹ and 1 are considered to be equivalent, as they represent pretty much the same thing, or as close as makes no odds. MediaWiki's policy of converting to NFC is based on Unicode recommended practice, and helps our pages conform to the other 99.98%1 of the internet that uses NFC, so this bug is definitely a Unicode one. Conrad.Irwin 21:49, 8 December 2009 (UTC)

Started Appendix:Unicode normalization. I remember Stephen(?) talking about other "issues" with normalization (maybe involving diacritics). If there are, please note them. --Bequw → ¢ • τ 22:43, 9 December 2009 (UTC)

[edit] Template:fro-decl-noun

This and the corresponding Template:fro-decl-adj seem to have a bug. See caitif (as of today's date) as it swallows up the following section in the box, although it shouldn't. Help please! Mglovesfun (talk) 13:24, 25 November 2009 (UTC)

fixed now, I think. Conrad.Irwin 16:16, 25 November 2009 (UTC)

[edit] Category:American English English

Hands up, who broke that? Mglovesfun (talk) 17:27, 26 November 2009 (UTC)

[edit] {{welcomeip}}

Can this be made so that the wikipedia paragraph is optional? I know nothing about templates L☺g☺maniac chat? 17:42, 26 November 2009 (UTC)

How about this? wp=no eliminates the Wikipedia paragraph. --Yair rand 17:51, 26 November 2009 (UTC)

Thank you very much! L☺g☺maniac chat? 01:46, 27 November 2009 (UTC)