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

We already have patrolling enabled, and a patroller group (which we don't use as yet, limiting it to sysops). We could set up process for granting patroller to non-sysops, but that was generally thought to be un-needed. Users that aren't sysop or patroller don't see the flags or the links; it is invisible, except that anyone (IIRC) can read the patrol log. Robert Ullmann 13:07, 13 December 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)

The reason for the actions of the "bright sparks" was one of the essential design objectives of Unicode/UCS: That data can be round-trip converted from any of a very wide range of national and international standards into UCS and back, with the result being identical to the input. So if any one of those standards has two different code points for the "same" character, UCS provides two different code points. Then one of those two (or more) is considered to be the normalized form. In a Unicode/UCS "native" application, like the wikis, normalization is standard practice, and the other code points never appear in the (stored) data. At the same time, an application like email can convert a sent message in (e.g.) Big5 to UTF-8, and the receiver can convert it to a desired target code; if that code is Big5, the data is exactly as was sent. So it isn't a "bug", it's a feature ... it was done that way intentionally. Robert Ullmann 11:21, 14 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)

[edit] random entry language?

i'm trying to use the random entry API. it doesn't appear that it honours the site language. for example, if i do,

http://en.wiktionary.org/w/api.php?action=query&list=random&format=json

the word returned can be any language. why doesn't the query honour the site language (http://en.wiktionary...)? is there a parameter i can pass to indicate the desired language? i could not find one.

i also saw the "random entry by language" link on the left here. that's fine, but i need to access this programmtically, through a web service.

any help is appreciated.

No there is no way to do this on-site, which is why the off-site tool was created. What do you need it for? I can provide the lists used to create the indexes in most languages which you can then randomise yourself, if that'd work - otherwise you can try asking User:Hippietrail if his random language by entry supports multiple returns in one request. (It does actually honour the language, this site has "all words in all languages" with definitions in English, compare http://fr.wiktionary.org ) Conrad.Irwin 22:51, 28 November 2009 (UTC)

[edit] December 2009

[edit] Search tool idea

Do we have, or can someone develop, a tool that word search other language Wiktionaries for pages with a particular name? I can see this as particularly helpful in situations where an unfamiliar word has been requested or discovered without the context of language. Such a tool would allow us to quickly search the other Wiktionaries for a match. --EncycloPetey 05:02, 2 December 2009 (UTC)

I use Google for that by adding the site:wiktionary.org parameter like this. --Vahagn Petrosyan 09:13, 2 December 2009 (UTC)

Google isn't friendly for that if there are diacriticals present, or if you are looking for a simple entry name like as. --EncycloPetey 20:44, 12 December 2009 (UTC)

Interesting. Interwicket has a complete global index. If the entry is there for more than a couple of hours, and there is a match on the others, the entry will pick up iwikis, then you can follow them. So a simple way is to create a stub, and wait a bit. I don't have any simple way of making the DB available now though. (Could be done in various ways.) Robert Ullmann 12:57, 13 December 2009 (UTC)

[edit] Vector skin problem

When I'm logged in with the Vector skin (Monobook is fine), headings that are the word "head" float in the upper left of the page (like WT:RFV#head and this simple Sandbox page). It happens in IE 8, Firefox 3.5, and Chrome and even after I comment out my entire User CSS and JS file. Anyone know what could cause this? Something in the master skin files? --Bequw → ¢ • τ 20:24, 8 December 2009 (UTC)

Definitely known and reported already. Vector skin has a CSS instruction which places all objects with id="head" at the top left corner. Headings have a id parameter which is their content, so having a heading called "head" causes a conflict. -- Prince Kassad 21:29, 8 December 2009 (UTC)

Thanks. It was driving me crazy. --Bequw → ¢ • τ 21:58, 8 December 2009 (UTC)

[edit] Template:context

Knowing how complicated {{context}} is, what happens when there's a context label to replace like {{Star Wars}} and I replace it with {{context|Star Wars}} and delete the template? The template is not orphaned. Seems like quite a unique case, as I've never seen another template that works like this. I should look at the source code, although I suspect I won't understand it. Mglovesfun (talk) 08:42, 9 December 2009 (UTC)

It will change to read "Star Wars" because that's what you typed as opposed to "Star Wars" because that was the label on the context template (i.e. it will do nothing). Conrad.Irwin 15:00, 9 December 2009 (UTC)

Will the process associated with {{context}} lead to the recreation of the category? Will it lead to a recreation of the template for "Star Wars". DCDuring TALK 13:47, 13 December 2009 (UTC)

AFAICT no. Mglovesfun (talk) 23:19, 13 December 2009 (UTC)

[edit] Context template duplicates

The ones we are talking about are:

• {{comics}}, {{comic books}}
• {{steroid}}, {{steroid hormone}}, {{steroid drug}}, {{steroids}}

Any suggestions? Mglovesfun (talk) 17:00, 9 December 2009 (UTC)

Redirect between them? Conrad.Irwin 20:24, 12 December 2009 (UTC)

We have lots of redirects like this. Is considered a normal part of the design of these templates. Robert Ullmann 12:47, 13 December 2009 (UTC)

• But notice that the second set are all different in terms of what they display and how they categorize. --EncycloPetey 15:24, 13 December 2009 (UTC)

I fixed comics/comic books by the number of transclusions. For the steroids set, yes that's an awful mess, and I know just about nothing about biochemistry. Good luck guys! Mglovesfun (talk) 23:24, 13 December 2009 (UTC)

[edit] Use of images on the English Wiktionary is not picked up by Wikimedia Commons.

Hi all. Please note the discussion at commons:Commons:Deletion requests/File:Unicode rightwards arrow (U+2192).svg. It seems that Wikimedia Commons doesn’t pick up when an image is used in an entry on Wiktionary. I, of course, have no idea how to rectify this problem; I bring this hereto so that those more knowledgeable in these matters might know what to do about it. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 03:59, 13 December 2009 (UTC)

Those tools you were linked to on the deletion discussion seem to work, and anyway, when they delete a file from commons, it gets deleted from here by User:CommonsDelinker, in the current debate they just want to replace it by File:U+2192.svg which looks the same, and the CommonsDelinker bot will replace it on wikt like here, so there's no problem. Conrad.Irwin 13:13, 13 December 2009 (UTC)

Thanks for that. Stuff has been resolved now. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 22:55, 13 December 2009 (UTC)

[edit] Viewing diffs of deleted pages

Just a tiny niggle: if you delete a page and then try to view one of its "diffs" (from another earlier browser tab, for example), it comes up with "Sorry: the page title you requested is not supported by our software." That doesn't seem like the appropriate error message. Equinox ◑ 06:23, 13 December 2009 (UTC)

[edit] Template:movecat

Meant to post this ages ago; there is a way used on fr:Modèle:catégorie redirigée to have the page sub-categorize categories that are not empty, or are redirects to a page that does not yet exist. Seems like a good idea. Also, do we have any policy over which of these categories to keep, or not? On fr.wikt there are something like 600 of these, but we have about 60. I tend to think it's worth keeping the ones that are not misnamed, such as alternative names for languages (Old Occitan/Old Provençal) but should be deleted when it's just a mistake. Mglovesfun (talk) 23:18, 13 December 2009 (UTC)

Dit it myself; Category:Category redirects which are not empty. Mglovesfun (talk) 11:02, 17 December 2009 (UTC)

[edit] Character support for Mahjong Tiles

Hi all. Does anyone know where I can obtain character support for Mahjong Tiles? † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 05:39, 14 December 2009 (UTC)

[2] -- Prince Kassad 05:59, 14 December 2009 (UTC)

Hmmm. Thanks for that. Unfortunately, though I’ve copied that to my Fonts folder, it doesn’t seem to have worked. For example, viewing w:Mahjong#Mahjong in Unicode, I still only see boxes. Do you have any ideas what might be wrong? † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 06:11, 14 December 2009 (UTC)

Some browsers need to have the font enforced because they fail to select it by default (IE and Opera instantly come to my mind). If the font is installed correctly it should show up in BabelMap. -- Prince Kassad 21:04, 14 December 2009 (UTC)

Yup, that seems to work. Thanks. Now, how do I “enforce” Symbola? † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 18:43, 15 December 2009 (UTC)

Using a template, à la {{musical}}... -- Prince Kassad 05:50, 17 December 2009 (UTC)

Hmmm. One seems already to exist as {{Zsym}}… Thanks for your help, nevertheless. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 21:53, 17 December 2009 (UTC)

[edit] Request, for anyone who knows how to do it

Was thinking that one main way I could help the project is to complete, where I can, Old French words used in etymologies. But how to find them? Anything using {{term|lang=fro}} would be a good start. Btw I only enter words I've seen in use, I don't just "guess" as the risk/reward is too low. Mglovesfun (talk) 11:05, 15 December 2009 (UTC)

I suggest entering the string {{term|lang=fro}} in search. It seems to give some good results. Someone with access to the database could probably do a lookup which would be more convenient, but until then... -- Prince Kassad 11:43, 15 December 2009 (UTC)

Some Etymologies contain the words "Old French" without the template. They offer the potential for multiple improvements. Scanning a simple search for "Old French" for the pattern that yields what you want can be fairly rapid.

Also Hippietrail has been doing useful dump SQL searches on headwords, headings and categories. I don't know what the next step in extending that is, but you might ask him once more instantly available means stop yielding results. Perhaps HT, RU, Conrad or someone else can create lists of redlinked term words by lang (including those with no lang parameter for further cleanup).

Latin, ancient Greek, Middle English, Anglo-Norman, and the various older Germanic languages are all of great importance for English. In some cases the glosses don't match the full range of meanings of the word in these older languages. DCDuring TALK 13:04, 15 December 2009 (UTC)

I don't really know why Anglo-Norman has its own ISO code, I was taught that it's one of the major dialects of Old French. Mglovesfun (talk) 13:08, 15 December 2009 (UTC)

Me neither. All I know is that some references make the distinction and thence we inherit it. Also some entries have "Old North French" (lang=?), "Middle French" (lang=frm), and "Frankish" (lang=?). Resolving Old North French into fro, xno, or whatever would be useful if you can figure that out at some point. Similar with Frankish. They may not be "resolvable", but perhaps could be supplemented by additional etymology using languages with ISO codes. DCDuring TALK 13:20, 15 December 2009 (UTC)

I don't know what Old Northern French is, but Middle French is a separate language (frm) and Frankish (frk) even more so as it's a Germanic language brought in by the tribes invading France during Roman rule. I'm not actually sure it's well enough attested to have entries here, a bit like Transalpine/Cisalpine Gaulish, which have ISO codes but aren't really recorded in writing. Mglovesfun (talk) 13:55, 15 December 2009 (UTC)

[edit] Template:fiu-vro

This failed RFD and has been recreated. However using lang=vro in {{wikipedia}} doesn't take you to the Võro Wikipedia, it takes you to nothing, because Wikipedia does not use the correct ISO 639 code. So is this a keeper after all? Mglovesfun (talk) 17:26, 15 December 2009 (UTC)

No, it should be added to https://bugzilla.wikimedia.org/show_bug.cgi?id=8217 and to the template as an exception. Conrad.Irwin 18:58, 15 December 2009 (UTC)

Now done. Conrad.Irwin 19:22, 15 December 2009 (UTC)

[edit] Wiktionary:Requests for deletion

The dynamic list has suddenly got much wider and is totally screwing up the spacing. Mglovesfun (talk) 12:28, 17 December 2009 (UTC)

Fixed by closing the discussion about lukkedoerendunandurraskewdylooshoofermoyportertooryzooysphalnabortansporthaokansakroidverjkapakkapuk. Conrad.Irwin 13:38, 17 December 2009 (UTC)

[edit] English translation lines

Could the assisted translation adding system prevent the addition of English translations of English words. Seems to be used by vandals rather than accidentally. SemperBlotto 08:15, 18 December 2009 (UTC)

I've noted perhaps a half a dozen of these starting about a month ago while addressing rfc-trans table tags. I don't know whether it should be fixed. If a vandal claims the translation is Yoruba, how would I know? It is much easier for the bot to detect and for me to correct vandalistic translations if the language is English. I don't routinely put a ttbc tag on something I make conform to trans-table standards. Do we need a procedure for marking and checking anon-added translations (either all or just those to empty language section)? DCDuring TALK 12:03, 18 December 2009 (UTC)

It can be fixed easily, and probably should be. I also have thought about a way of making it easier to check added translations. Either the translation thing could append the word to a per-language list somewhere (ideally with rollback and patrol links), that some dedicated person could then sift through; or it could get added to (yet-another) request category. Neither of these solutions seem particularly amazing, though maybe if we allow each language to "opt-in" to the system only if we know we have someone who will actually bother reviewing them, it wouldn't be so bad. Conrad.Irwin 14:33, 18 December 2009 (UTC)

From my (en-N, other languages 0.5) perspective, the language-list idea seems good, even if there is a big backlog. Checking and correcting translations might be a good starter/restarter task for new/occasional contributors with a specific language skill. But opt-in seems like a good way to start in any event. Should they just go into ttbc if added by anon and link to absent language section? DCDuring TALK 15:28, 18 December 2009 (UTC)

The problem with putting them into ttbc is that someone needs to edit every entry to remove them, the idea behind an explicit list was so that all edits by X could be easily removed from the list in one go; a big problem with such a page is that it would double the size of recent changes, but I suppose it could be collated on the toolserver as it would not be publishing any information that isn't already available (providing it was limited to anonymous users). Conrad.Irwin 15:56, 18 December 2009 (UTC)

But Semper's point is about people adding a translation line of "* English: [[garbagetext]]". These can and should be vetted by bot, since we never have English translation listings in English translation tables. --EncycloPetey 05:01, 19 December 2009 (UTC

The volume of "English" that I see at rfc-trans which is what the bot catches is low. At least some of it seems like a kind of typing error. It is sometimes a recoverable translation with the wrong language. If the linked word is blue, I follow the link, confirm that the translation is right and insert the language. I find it simple to do in the course of correcting the other things that impede the operation of assisted translations. There are perhaps as many as half a dozen items a day, usually fewer. No language skills are required, except for the refractory cases, which look to remain on the list for months if not years.

If the bot finds problems of this "English" type, is that not evidence of likely problems in other languages? Perhaps this warrants a test of some kind. How many translations are added by anons in each of a sample of languages over a month? How many are vandalism? How many are erroneous (script, language, other)? How many can bear improvement? Is it usually a single contributor? If the process as originally implemented is ineffective or inefficient, it could be improved or abandoned based on that information. DCDuring TALK 10:52, 19 December 2009 (UTC)

I have stopped the addition of English through the assisted tool, which should lead to fewer mistakes when a user put the wrong language code in (assuming they did it through the tool). It should not be that hard to set up a system that extracts most assisted edits from recent changes (except the ones that the edit summary disappears on), it'd be slightly harder to work out what % of those get undone or rolled-back, or that have transliterations etc., though it should be doable. Conrad.Irwin 12:53, 19 December 2009 (UTC)

[edit] Making tables play well with RHS elements

I'd like to make a change so that our table templates play better with right-hand side elements. We have two main classes of table templates:

1. Plain: {{top}}, {{top2}}, {{top3}}, {{top4}}, {{top5}} (and their "bottom" templates)
2. <div>-wrapped: {{rel-top}}, {{der-top}}, {{trans-top}}, {{checktrans-top}}, {{reqtrans-top}}, {{ttbc-top}} (and their "bottom" templates).

When there's a right-hand side element next to these tables, the latter type stay in place vertically and just span the horizontal space available whereas the former type jump below the right-hand side elements (creating a gap in the page) so that they can actually span 100% of the content area. As this gap creates horrible layout, I'd like to fix this by wrapping the former type in a <div> tags (probably <div style="width:auto;margin:0px;overflow:auto;"> in the "top"s and </div> in the "bottom"s). This would create the following side-effects:

1. People who don't realize that {{bottom}} != "|}" would use the template to close a hand-inputted wikitable and cause a spurious </div>. While technically invalid, it doesn't really cause any rendering problems that I know about. I scanned a en.wikt dump and found that this only happened two times currently.
2. People often erroneously close {{trans-top}} with {{bottom}}. The way things currently are, this causes the rest of the page to be hidden (because there's two missing <div> tags), an easily overlooked error. With the proposed change, the rest of the page would be visible, but styled like the translation table (there'd only be one missing <div> tag). This would be an obvious error and more likely to be fixed immediately rather than waiting for someone to scan for mismatched templates. At last scan, I fixed about a 100 of these errors, so it's much more common than #1.

I think #1 is so minor as not to worry about, and #2 is an ancillary benefit to the proposed change. Does this sound like a feasible and beneficial change? --Bequw → ¢ • τ 01:10, 19 December 2009 (UTC)

It seems very beneficial to me. Can we accelerate the discovery of the errors? DCDuring TALK 02:07, 19 December 2009 (UTC)

The layout errors cause by RHS elements' interaction with the "plain" table templates would be completely fixed by the proposed addition of the div tag. As for errors caused by editors mismatching the template, I scan the dumps every once in a while and fix them. --Bequw → ¢ • τ 06:37, 19 December 2009 (UTC)

What right-hand elements (other than images) are a problem with the tables? Most such items are misplaced in the entry, in my experience. --EncycloPetey 04:58, 19 December 2009 (UTC)

It happens frequently with right-hand side ToCs. That's how I browse so I see it a lot. It's usually when there's a plain top-style table in the upper part of a long page. Because of frequent layout problems I changed {{mul-numberchart}} (which originally used {{top3}}) to use just a plain table. It would look better using a div-wrapped {{top3}}. --Bequw → ¢ • τ 06:37, 19 December 2009 (UTC)

If an entry requires a ToC, RHS ToC improves the value of any language section that appears at the top of the entry by enabling context, especially definitions, to appear on the initial screen a user sees. Were it possible for the ToC to be rhs by default (with opt-out for registered users), we could enhance the value of Wiktionary relative to the other choices that users have. DCDuring TALK 11:01, 19 December 2009 (UTC)

I support this wrapping. Maybe we should re-look at rhstoc after it is done. Conrad.Irwin 12:45, 19 December 2009 (UTC)

I strongly oppose RHSTOC. --EncycloPetey 13:02, 19 December 2009 (UTC)

Any particular reasons? DCDuring TALK 13:05, 19 December 2009 (UTC)

Yes. When that discussion starts (again), we can drag them all out (again). --EncycloPetey 13:11, 19 December 2009 (UTC)

I just hope we can have pages look fine for both options. --Bequw → ¢ • τ 20:59, 19 December 2009 (UTC)

I support the change. Maybe we should even add another stray <div> in there, and make all the different "bottom" templates redirect to {{bottom}}. —Ruakh_TALK 16:40, 19 December 2009 (UTC)

I thought about this. It would make things cleaner. We aren't worried about the extra bits sent with the second div tags are we? --Bequw → ¢ • τ 20:59, 19 December 2009 (UTC)

And if we do add it, should the top part be <div><div style="width:auto;margin:0px;overflow:auto;">? --Bequw → ¢ • τ 22:03, 19 December 2009 (UTC)

I don't see the need for the first <div>, and any extra </div> will be stripped by HTML tidy after the parser has finished. Conrad.Irwin 22:20, 19 December 2009 (UTC)

[edit] "not to be confused with"

Is there a template something along these lines? Something similar to {{also|来|徠}} to go at the top of an entry? I think it would be useful for Chinese words which can be switched around, of which there are many (蜜蜂 & 蜂蜜, 合适 & 适合, 现实 & 实现, 来自 & 自来, etc). These are a common source of confusion for many Chinese learners. Tooironic 04:53, 19 December 2009 (UTC) (P.S. And no, I don't think the "see also" template is explicit enough to serve this purpose. Tooironic 04:55, 19 December 2009 (UTC))

There isn't a template, and those ought not to appear at the tops of pages. When we do identify words often confused, we tend to do it either in a "See also" section at the end (without comment, which isn't particularly helpful), or in a "Usage notes" section to point out the confusion. There are lots of reasons that two words can be confused, and it isn't just the result of character reversal. --EncycloPetey 04:57, 19 December 2009 (UTC)

[edit] Transitivity categories

We have the context templates {{transitive}} and {{intransitive}}, but related categories such as Category:English transitive verbs are populated by hand. These templates could do that job. --Daniel. 09:37, 21 December 2009 (UTC)

The categories are of very large size, low utility, and incomplete coverage. No rush. DCDuring TALK * Holiday Greetings! 10:36, 21 December 2009 (UTC)

There's also a very bizarre category loop that needs fixing, involving a redirect that isn't empty. But yes, we have fr:Catégorie:Verbes transitifs en anglais in French, but almost any verb can be used transitively and intransitively. Some can't, I grant you, but unfortunately categories become of very little use when they are very small or very large. But I see no reason to delete them (or not create them). Mglovesfun (talk) 22:45, 23 December 2009 (UTC)

The more interesting categories would be "ambitransitive" or others for verbs that can take clausal or phrasal complements of various types. I don't think we've done much of that work yet, putting us far behind the Longmans dictionaries, which do the best job I've noticed,, showing 12 types of verb complement classes at the sense level in my edition. DCDuring TALK * Holiday Greetings! 00:17, 24 December 2009 (UTC)

[edit] poscatboiler, etc.

Some people suggested the addition of categories such as Category:English idioms and Category:English phrases to {{poscatboiler}}. Instead, I'm finishing (on my PC, not at Wiktionary yet) a new similar template to organize these possibilities, among others. Supported categories are: abbreviations, acronyms, contractions, initialisms, phrases, phrasebook, idioms, proverbs, alternative spellings, misspellings and obsolete spellings. --Daniel. 01:20, 24 December 2009 (UTC)

[edit] Unicodification

WT:AWB states that the option "Unicodify entire article" is probably a bad idea. While unicodification is generally a good idea, as it allows for searching, it would mess up instances where we use character references to display a non NFC Unicode character (which we talked about above). Is this the only reason it's discouraged? If so, then this is so rare that we could just make a template like {{HTML char|hex=...}} (or something better named) that displays the reference (allowing decimal, hex, and entities) but that wouldn't be auto-unicodified by AWB. --Bequw → ¢ • τ 09:30, 25 December 2009 (UTC)

Is there documentation of what exactly unicodification does? Does it translate all character and entity references? Because we sometimes escape wikisyntax metacharacters that way; is the unicodification smart enough not to unescape those, or at least to wrap them in <nowiki> tags? —Ruakh_TALK 01:03, 27 December 2009 (UTC)

w:Wikipedia:AutoWikiBrowser/User manual#Options 2 says unicodification skips easily confused glyphs (eg primes and times). Do we escape wikisyntax metacharacters with character references in the main namespace? --Bequw → ¢ • τ 06:14, 27 December 2009 (UTC)

[edit] Auto-creating rhymes pages

Interesting to set all the red linked rhymes entries. Couldn't a bot such as Conrad.bot create these using Special:WhatLinksHere? Not only would it avoid all the red links, but anything tagged with the wrong rhyme would be quite visible in such a list. Mglovesfun (talk) 17:53, 25 December 2009 (UTC)

The Rhymes pages require knowing the language of the entry and that the coding for the link was correctly put in. There are only two or three people here that know the coding system for Rhymes well enough to judge that, and in my case I've usually created the page myself already when there was a valid link. there are experienced editors here whom I have seen add an incorrect Rhymes link because they didn't know our conventions for parenthetical characters, UK weighting, and stress considerations. I don't think a bot could successfully create the entries. A bot also would not be able to sort items into sections by number of syllables, since the syllable breaks aren't always indicated, and aren't always correct. However, it might be worth having a bot generate some sort of list for inspection. --EncycloPetey 16:25, 26 December 2009 (UTC)

[edit] Could there be a way to 'watchlist' a user's contributions?

I know one is able to watch a user's talk and userpage, but could there be a way to have all of that user's contributions show up on the watchlist? ('twould only be useful for very new or iffy users (i.e. users listed on WT:VIP but not blocked as vandals), of course...) L☺g☺maniac ☃ 02:54, 26 December 2009 (UTC)

AFAICT you can't favorite special pages, nor can you have redirects towards them. But you can have explicit links towards, put them in your favourites or on your user page (Special:Contributions/Tbot for example). Mglovesfun (talk) 09:53, 26 December 2009 (UTC)

Or you can subscribe to an RSS feed of one's contributions. The link is in the toolbox on the left of e.g. Special:Contributions/Tbot. --Vahagn Petrosyan 12:19, 26 December 2009 (UTC)

[edit] lang= in templates

Any idea how to replace things like {{etyl|la}} with {{etyl|la|langname}} and {{sports}} with {{sports|lang=langname}}. A lot of non-English words are categorized in English categories for this reason. Mglovesfun (talk) 10:11, 26 December 2009 (UTC)

{{etyl}} already has a language code as its second parameter, so for a Spanish word of English origin, type {{etyl|en|es}}. {{sports}} also has a lang= parameter. It's just a matter of people remembering to use them. —Angr 15:22, 26 December 2009 (UTC)

Sorry, maybe I was unclear. Templates that are already in our entries, but categorize in English, as English is the default for almost every template. So you get Japanese, Russian (etc.) words in English categories. I'd have thought this would be pretty damn machine readable. Mglovesfun (talk) 15:27, 26 December 2009 (UTC)

According to User:AutoFormat, AF already does fix context labels; have you seen evidence of that not working? As for {{etyl}}, we might want to ask Robert to add that to AF as well, though there's the complication that (for example) {{etyl|ar}} in a ==Hebrew== section is more likely to be an error for {{etyl|ar|-}} than for {{etyl|ar|he}} (though both are quite possible). I suppose the safest thing to do would be {{etyl|ar|-}}{{attention|he|some sort of message here about what happened}}. (Though with {{etyl|la}} in a ==Spanish== section that's a bit of a waste, since it's almost certainly supposed to be {{etyl|la|es}}.) —Ruakh_TALK 15:49, 26 December 2009 (UTC)

This would probably be better done as a manual search from a generated list. As Ruakh indicates, there is no safe assumption about what is correct without looking at the entry. --EncycloPetey 16:21, 26 December 2009 (UTC)

See WT:CDPR#Correcting etymological categories for generated cleanup lists. There's about 1,600, so once they're cleaned-up, maybe AF can mark new ones with {{attention}}. --Bequw → ¢ • τ 06:00, 27 December 2009 (UTC)

Wow, thanks for attacking those lists. For a related list of entries that are incorrectly hand-categorized into English topical cats, see the new WT:CDPR#Incorrect topical categorizations. --Bequw → ¢ • τ 02:06, 29 December 2009 (UTC)

As for {{context}} with no language given, AutoFormat can correct this, but it only checks the recent changes, so pages that aren't updated (excluding bots like Interwicket) will continue to categorize in English, even when not so. Mglovesfun (talk) 11:55, 28 December 2009 (UTC)

[edit] Category:English plurals

It might be interesting from a formatting point of view to see which entries don't use {{plural of}} and eventually remove the overt written [[Category:English plurals]] from entries, as AFAICT all plurals should use plural of. This could later be extended to some other languages, but not all of them. Mglovesfun (talk) 16:24, 26 December 2009 (UTC)

How are the boundary cases handled? For example, plural-only nouns. I would guess that they should only be in their own category with the category being included in English plurals. What about redlinked plurals? More vexing are words that are in contemporary general usage in one sense (or more) as plural only, but not in other senses (often, but not always, dated or technical). (See hackles.) Might these cause trouble for the (desirable) process you seem to be advocating? DCDuring TALK * Holiday Greetings! 16:51, 26 December 2009 (UTC)

[edit] Edit in {{trreq}}

{{trreq}} was designed to add categories such as "Translation requests (French)" to entries. As it's commonly done for other templates supposed to be only used in entries, I'll edit {{trreq}} to not automatically add categories to pages outside the main namespace. --Daniel. 01:42, 28 December 2009 (UTC)

Yes, that's good. Can we make a list of all the templates that still need this change? --Bequw → ¢ • τ 06:40, 28 December 2009 (UTC)

[edit] Template proposal

If we don't already have one, something like {{obsolete template}} for templates that have been replaced or have failed RFD, but can't yet be deleted as they are still used on pages. It could also have with includeonly the hiddencat [[Category:Pages using an obsolete template]]. Any thoughts? Mglovesfun (talk) 11:53, 28 December 2009 (UTC)

We have the {{deprecated}} and the [[Category:Deprecated templates]]. A second category [[Category:Pages with deprecated templates]] might be useful. --Daniel. 17:00, 28 December 2009 (UTC)

Anyone object to that? Mglovesfun (talk) 17:06, 28 December 2009 (UTC)

Let me see if I understand correctly by restating the proposal, as it stands. You want to add a second category to {{deprecated}}, but make the new category "visible" in the sense that it will categorize the pages into [[Category:Pages with deprecated templates]] when they contain that tagged deprecated template. Is that correct? --EncycloPetey 17:20, 28 December 2009 (UTC)

But use __HIDDENCAT__ as [[Category:Requests for deletion]] probably should do. Mglovesfun (talk) 17:37, 28 December 2009 (UTC)

Sounds like a possible idea, but what would the purpose of the category be? If each template were tagged one at a time, I could see it being a useful tool. However, it's more likely that the catgeory will contain a mix of many pages containing many different deprecated templates. So, anyone using the category would have to spend time figuring out which template on the page is deprecated, where it is, and what to do about it. It doesn't seem like having the category would produce a useful payoff. --EncycloPetey 17:54, 28 December 2009 (UTC)

Then, I'll propose a more specific and useful categorization. Supposing that {{en-noun}} becomes deprecated and has {{deprecated|{{subst:{{PAGENAME}}}}}} in it, pages containing {{en-noun}} are added to [[Category:Pages with deprecated templates (en-noun)]]. --Daniel. 18:20, 28 December 2009 (UTC)

If editors don't mind the headache of creating and deleting the resultant categories as templates are deprecated and then cleaned away, then it sounds like a feasible plan to me. --EncycloPetey 18:35, 28 December 2009 (UTC)

How is this better than http://en.wiktionary.org/w/index.php?title=Special:WhatLinksHere&target=Template:en-noun&namespace=0 ? --Bequw → ¢ • τ 18:51, 28 December 2009 (UTC)

The problem is that even if a template is not very widely transcluded, a change to the template can take a while to get through the job queue (depending what else is on the queue at the same time), so the category won't necessarily get populated very quickly. WhatLinksHere, on the other hand, is normally up-to-date, or at least closer to it. (It, too, is affected by the job queue, but using it doesn't require editing the template.) —Ruakh_TALK 19:56, 28 December 2009 (UTC)

[edit] Code 2000 installation problem!

Hey, guise [sic]... I have Windows 7 and have tried on several occasions and through several methods to install Kass' Code2000 font with no success. I have already successfully installed his Code2001 with no problems. But when I try to install Code2000 by clicking on it, I get the message:

Windows cannot complete the extraction.
The destination file could not be created.

I have also tried dragging it to the Fonts folder. Does anybody know what I should do? I NEED this font!!!! Thank you.—Strabismus 22:29, 28 December 2009 (UTC)