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)

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!

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)

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

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

{{en-verb|inf=to ]-]}}

{{en-adj|pos=]-]}}

{{infl|head=] ]}}

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)

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

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

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 (deprecated template usage) 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 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)

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

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)

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 ] 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 ], I wouldn't really mind redirecting "blind" to ], 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 ] 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)

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 ] in it. It's a kludge, but it does work. — Carolina wren discussió 04:48, 27 September 2009 (UTC)

The {{misspelling of}} template doesn't seem to like the parameter being wikified. See (deprecated template usage) 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)

• Still not fixed. SemperBlotto 10:57, 1 January 2010 (UTC)

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)

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)

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)

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: Template:wlink. HTH, -- Visviva 04:20, 23 September 2009 (UTC)

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)

http://en.wiktionary.orghttps://dictious.com/en/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)

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

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

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.orghttps://en.wiktionary.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)

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.orghttps://dictious.com/en/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)

{{etyl}} allows users to opt out the autocategorisation it performs when its second parameter is left blank, by using a hyphen instead, thus: {{etyl||-}}. 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)

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)

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)

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)

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)

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)

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)

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!

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

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)

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

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)

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)