Wiktionary:Grease pit

Wiktionary discussion rooms (edit) see also: requests
Information desk start a new discussion | this month | archives Newcomers’ questions, minor problems, specific requests for information or assistance.	Tea room start a new discussion | this month | archives Questions and discussions about specific words.	Etymology scriptorium start a new discussion | this month | archives Questions and discussions about etymology—the historical development of words.	Beer parlour start a new discussion | this month | archives General policy discussions and proposals, requests for permissions and major announcements.	Grease pit start a new discussion | this month | archives Technical questions, requests and discussions.

All Wiktionary: namespace discussions 1 2 3 4 5 – All discussion pages 1 2 3 4 5

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.
  
  

January 2009

McBot and XML dumps

McBot is busy removing a useless template and doing a couple of other things, editing at a very high rate (at one point I noted nearly 100/minute ;-). There are a lot of them; at one time yesterday there were 94000+ remaining, after it had already done at least 20K. All good, but it floods the daily dump update; I had to fix it after Conrad.Bot clobbered it on a previous occasion.

The simple version is: the dump for today is posted, but does not reflect most of the McBot edits. They (and other 'bot) edits will be integrated into the dump over the next several days.

The gory details (if you care ;-): the process effectively prioritizes the updates it is doing, and limits the total number of updates in each run. That way it doesn't try to load 100K pages from the servers in one pass. It runs 3 times a day, and the run at ~09:00 UTC is posted. The priorities are:

1. templates (all)
2. new pages (max 17000, an arbitrary non-infinite number ;-)
3. edits by non-bots from RC (max 5000)
4. edits by 'bots from RC (max 5000)
5. others found on revision cache refresh (max 3000)

The priorities are not a strict sequence, it always does all templates, and then some from each step. Under normal conditions, it completes all of the updates in each step anyway. At the moment, the fourth group is not being completed. The cache of revision id for each page id is refreshed from the servers at least once in every 7 days (21 runs). Robert Ullmann 11:07, 1 January 2009 (UTC)

Ah, should also note that all deletions needed are done on each run; however it won't do more than 5000 because it just reads the last 5K from the deletion log. This would only be a problem if more than 5000 entries were deleted in 8 hours. (Not very likely.) Robert Ullmann 19:24, 1 January 2009 (UTC)

Thanks for keeping us posted! Although it's tempting (for me at least ;) to whinge a little about delays of a few days, it's nothing compared to waiting for a few months as was the previous situation. Thank you again. Conrad.Irwin 02:01, 2 January 2009 (UTC)

Karibu. Note that the delay only matters if your use for the dump is affected by the un-updated entries; in this case edits to Spanish verb forms and a a few AF and VolkovBot edits. There is still a new dump posted every day. Today's has 36,203 updates not done. Robert Ullmann 11:32, 2 January 2009 (UTC)

New script templates

These have been added recently, and I'd like to migrate the font specifications to the style sheet MediaWiki:Common.css, standardize the class names, etc:

• {{Cham}} – add fallback font-family: sans-serif
• {{Copt}} – add fallback font-family: sans-serif
• {{Geor}} – change class name from script-Geor to Geor
• {{Latf}} – change class name from LA to Latf; add fallback font-family: sans-serif
• {{Thaa}} – change class name from Mahal DV to Thaa
• {{Tale}} – add fallback font-family: sans-serif

Any comments or objections? —Michael Z. 2009-01-02 22:14 z

Do we have a guide somewhere for our users that (1) lists the various scripts and fonts, (2) offers help for users who have trouble displaying certain scripts, (3) points to templates and other tools for editors who want to work in these scripts? --EncycloPetey 05:03, 12 January 2009 (UTC)

1 no, except for category:Script templates, and the style sheet MediaWiki:Common.css documents itself. 2 no. 3 just the templates' own documentation: {{term}}, {{t}}, {{infl}}, {{form of}}, etc. I have started WT:SCRIPTS to document these templates, but it is not a help page for general readers of the dictionary. —Michael Z. 2009-01-12 06:19 z

Tibetan font declaration

Currently, the Tibetan font declaration is identical to the generic Unicode one, which is problematic since none of the Unicode fonts support Tibetan. IE (and most other browsers) ignores these fonts (so there's no problem with Tibetan failing to show up even if the fonts are installed), but the declaration in the Common.css should still be changed to something that makes more sense, like

.Tibt { font-family:Jomolhari,'Tibetan Machine Uni','Microsoft Himalaya',sans-serif; }

-- Prince Kassad 14:57, 3 January 2009 (UTC)

Should this be made an MSIE-only declaration by using the comment trick? Safari on my Mac seems to display Tibetan. —Michael Z. 2009-01-03 15:15 z

I think it should be made global. Firefox would greatly benefit from it, since it uses Arial Unicode MS as the default font for Tibetan, even though Arial Unicode doesn't support Tibetan. IE supports Tibetan on its own anyway. -- Prince Kassad 15:18, 3 January 2009 (UTC)

Okay, I'll make the change to the style sheet. I notice that Tibetan doesn't seem to display in either MSIE or Firefox in my vanilla Win XP system, with or without this font spec, so I assume that a font download is required. Is it the same on Vista?

FYI: both Safari 3.2.1 and Firefox 3.0.4 seem to display Tibetan without any help on a default install of Mac OS X 10.5.6. Adding the above CSS doesn't seem to affect the display in these browsers. —Michael Z. 2009-01-03 21:44 z

Done. —Michael Z. 2009-01-03 21:46 z

To answer your question, Vista ships with the Microsoft Himalaya font which supports Tibetan. It's at the end of the font list because it's awfully small. -- Prince Kassad 22:00, 3 January 2009 (UTC)

Oops, I have also updated the template now, which was overriding the style sheet. Look better? —Michael Z. 2009-01-04 00:26 z

Yes, it works now. -- Prince Kassad 17:27, 4 January 2009 (UTC)

Adding "no plural" and "no singular" parameters to {{hu-decl}}

I am trying to add two new named parameters (ns - no singular, np - no plural) to hu-decl which is the main layout declension template for Hungarian nouns. Sometimes nouns do not have plurals, occasionally singulars. The current template generates both. I tried the following in {{hu-decl-test}} (my test template) but did not work:

{{#ifeq:{{{ns|}}}|1|–|[[{{{1|–}}}]]}}

{{#ifeq:{{{np|}}}|1|–|[[{{{2|–}}}]]}}

The other test template that goes with this is {{hu-decl-ok-test}}. The hu-decl template is the layout template for several other templates. It seems a better idea to put the ns and np parameters here rather than in the subtemplates. They are already complex and I would have to modify several templates instead of one. Could someone please help? Thanks. --Panda10 21:25, 4 January 2009 (UTC)

In my opinion, the best solution for this is to use multi-layer templating, as is done on Ancient Greek inflection templates and others (I believe the original credit for this goes to Robert Ullmann, but am not sure). I will set up an example. Give me perhaps a half hour. -Atelaes λάλει ἐμοί 00:06, 5 January 2009 (UTC)

Ok, take a look at User:Atelaes/Sandbox, where {{grc-test}} is a modified version of {{hu-decl-k-back}}, and shows a singular only version of the inflection of kutya. It doesn't work perfectly for the nominative and essive-formal, because of the PAGENAME calls, but I imagine you'll get the idea nonetheless. -Atelaes λάλει ἐμοί 00:19, 5 January 2009 (UTC)

I'd like to keep the two-column format. If there is no plural, each cell would contain a dash. Is that possible with your solution? --Panda10 01:01, 5 January 2009 (UTC)

Take another look now. -Atelaes λάλει ἐμοί 01:09, 5 January 2009 (UTC)

Sorry, I don't see any change. It looks the same to me. The code, too. --Panda10 02:01, 5 January 2009 (UTC)

Press edit, and then show preview. The changes are apparently lost in the job queue for now. -Atelaes λάλει ἐμοί 02:36, 5 January 2009 (UTC)

Thanks! --Panda10 15:04, 10 January 2009 (UTC)

Ampersands in messages

It looks like MediaWiki now escapes ampersands in certain messages, which breaks the display of those messages if they use HTML entity references or numeric character references; I just fixed MediaWiki:Previousrevision and MediaWiki:Nextrevision, but I don't know if any other messages are affected. Does anyone know more about this? —Ruakh_TALK 23:55, 4 January 2009 (UTC)

template:rfc-archive

Can someone please tell me what's wrong with this template that causes the following errors to occur? 1, 2, 3. Thanks.—msh210℠ 22:24, 8 January 2009 (UTC)

@ was an unbalanced attempt at a link and has been fixed. I suspect others will be similar. I'll work on them. -Atelaes λάλει ἐμοί 22:27, 8 January 2009 (UTC)

I'm not sure about this, but I suspect that the other two require the 1= bit because there are equal signs in the running text (for 2 it's your name, for 3 its in the link that Robert gave). My guess is that the template is taking everything before the = to be a parameter name, and everything after to be the content of that parameter (a parameter which isn't used, and so isn't displayed). So, I suspect that, for every rfc discussion containing an =, you'll have to do the 1= trick. -Atelaes λάλει ἐμοί 22:34, 8 January 2009 (UTC)

Hm, thanks. is there a way to allow a template to accept a parameter value that includes [[foo] or the like?—msh210℠ 22:36, 8 January 2009 (UTC)

Not that I'm aware of (though I'm certainly not the most technically proficient person on this project). My experience is that anytime you have misbalanced brackets of any sort nested inside other brackets (a necessary condition for inclusion in a template), things just go all screwy. -Atelaes λάλει ἐμοί 22:46, 8 January 2009 (UTC)

If you wrap it in <nowiki> tags (as you did just now), or otherwise modify it so that the software doesn't get confused by mismatched brackets — [&#x5B;foo] and [<nowiki/>[foo] both work — it should be fine, but AFAIK there's no way to do it without modifying the comment. If we want to be really precise about such things, we can create {{rfcarchive-pre}} and {{rfcarchive-post}}, turn {{rfcarchive}} into basically just {{rfcarchive-pre}}{{{1}}}{{rfcarchive-post}}, and use {{rfcarchive-pre}} and {{rfcarchive-post}} directly in situations where {{rfcarchive}} would be a pain … personally I wouldn't worry about it if I were the one doing the archive, but since I'm not, you can totally be my guest to be as precise as you like. :-)   —Ruakh_TALK 05:08, 9 January 2009 (UTC)

Template:ca-noun-form

This is a very simple template, but it does need to do one thing that I don't know how to set up. It needs to check the values of {{{g}}} (or {{{1}}}) and {{{g2}}} (or {{{2}}}) to see whether they are valid for gender / number. Can someone help? I could certainly set up something using #switch, but I seem to recall there's a bit of code out there that I could simply call from this template, and have that pre-written code do the work. The problem is that I don't know where the code is or how to call it. --EncycloPetey 04:59, 12 January 2009 (UTC)

To begin with, I strongly suggest that the dual input be dropped. Have gender be a named or a numbered input, but not both! I'm not aware of any sort of pre-written code which could be utilized for this, but it is a fairly simple switch. -Atelaes λάλει ἐμοί 06:52, 12 January 2009 (UTC)

I'm standardizing now, and have only used unnamed. However, the template is set to prefer {{{g}}}, and when this is lacking it uses {{{1}}}. The dual input options shouldn't hurt anything, and allows for users who forget whether this particular template uses one coding method or the other. I often get confused myself between all the various templates I use, some of which take the gender as an unnamed parameter, and some of which require {{{g}}}. --EncycloPetey 06:58, 12 January 2009 (UTC)

Ok. Well, what are the accepted genders? Also, what should it do if the gender isn't valid? I guess my first assumption would be to not display any gender, and simply tag the entry with {{ca|attention}}. Also, you mentioned something about number, but I'm not seeing any number stuff in the template. -Atelaes λάλει ἐμοί 07:04, 12 January 2009 (UTC)

The {{{g2}}} is intended to be an optional sg or pl from values of "s" or "p" (or "sg" or "pl"). The value of {{{g}}} should be "m", "f", or "mf" (with "c" as equivalent to "mf"). If the gender isn't valid, it shouldn't display and should request attention, as you guessed. I'm undecided about whether {{{g}}} should be required; it would certain simplify coding if it were mandatory. --EncycloPetey 07:14, 12 January 2009 (UTC)

Ok, give it a shot and let me know if it works. -Atelaes λάλει ἐμοί 07:20, 12 January 2009 (UTC)

"Other pages to be deleted"

When a page is deleted, we now get some text telling us that the {{delete}} template may be deleted. I don't believe this to be true. SemperBlotto 15:27, 16 January 2009 (UTC)

It would seem more helpful to leave the tag in the deleted page, if that's what you are suggesting. DCDuring TALK 15:32, 16 January 2009 (UTC)

Sorry - didn't understand that - I was asking a question, not making a suggestion. SemperBlotto 15:38, 16 January 2009 (UTC)

I've taken the liberty of <includeonly>'ing the category tag in the template. This had been proposed before, to general indifference, but this change to the software made it a bit more important IMO. -- Visviva 16:29, 16 January 2009 (UTC)

I have to admit this is my fault. See my changes to the text that is displayed. (I figured we may as well list them there as there are never very many and it makes them easier to find. I also transcluded the top of recent changes so that there is often a link to the talk page of the contributor which greatly facilitates leaving them a note. (Saves me having to look at Deleted revisions to find it). As with anything wiki this can of course be reverted if it is causing issues for people. (I intended to add recent changes to the post-"patrol" and "rollback" pages as well, if this is wanted). Conrad.Irwin 01:44, 19 January 2009 (UTC)

Images in translations

There are certain situations where one might want to use an image in a translation, mainly when the language is written in a script which is completely unsupported by Unicode. Currently, though, Template:t does not allow images to be used and breaks, even when I use an imagemap as a workaround (see water). Would it be possible to add some kind of parameter to Template:t to allow for images? -- Prince Kassad 21:52, 16 January 2009 (UTC)

Don't try to force it into {{t}}. The template is only useful for languages with FL wikts (presently 167), and mostly pointless for the other 7000+ languages. ({{tø}} was only created to give Tbot something to do with {t} templates added for non-existant FL wikts, as a slight improvement over just converting them to ordinary links.) Robert Ullmann 13:57, 17 January 2009 (UTC)

Using Template:t is useful even for the other languages, since it automatically links to the correct section and allows you to use script templates, transliteration and gender. Also even without Template:t, using images does not work (again, see water) -- Prince Kassad 19:10, 17 January 2009 (UTC)

You might ask RodASmith about this. He has been using ASL images in Tranlsations tables with some success. --EncycloPetey 19:23, 17 January 2009 (UTC)

lang tags

See: User_talk:Robert_Ullmann#lang.2FHans

See: Wiktionary:Requests_for_deletion/Others#Template:lang

We should be generating HTML/XHTML lang tags for a number of bits where we have the information, to allow the browser font selection and CSS styling to work as designed. Please read the two sections above. Nbarth makes a good point, in that trying to convert languages to script (ala {{lang2sc}}) is mostly pointless, as it is the language that is wanted. We only want the script in a limited number of cases (e.g. Hant v Hans), and to add classes (for IE; without the customary IE brokenness there would not be much point ...)

Just to explain what this looks like; we want a bit of text in Japanese to look like:

<span lang="ja" xml:lang="ja" class="Jpan">言葉</span>

The class being only for our CSS and for IE<8, other browsers can style on the lang "psuedo-class".

Nbarth also points out that writing |lang=ja|sc=Jpan is annoying. Especially when the "Jpan" script selection isn't really the point: the browser setup works on the lang attribute.

Somewhere above, we proposed passing lang= and face= to the various script templates. The templates can then do the right thing. The language is the code, the face is one of [bold, head, ital, term] so the template can apply the desired HTML tag for the script (some scripts we want bold, some not; likewise for italic). head tells the template this is a headword (from {infl} or whatever) possibly made larger (Han, Arabic). term says this use is by {term}, to be italic in some cases.

(The script templates should use b for bold, and i for italic, not "em" and "strong", to be consistent with the WM s/w generated code for double and triple apostrophes.)

In standard use, the script codes are not used in most language tags, for example "zh-Hant" is used, but "fr-Latn" is not, "Latn" is the (supressed) default for "fr". Script codes by themselves are meaningless: lang="Hant" is not allowed (ignored), as it isn't a language tag. This is why the script templates need the lang= from caller, although they can sometimes default reasonably ({{Kore}} defaults to language "ko"). So the templates will suppress the script for a set of languages, default the language when reasonable, and in the case of Latn, suppress the script in all languages except a specific list: lang="sr-Latn" makes sense and is used.

What is then needed is a bit of magic, a script template that can be used by default. Other templates that take lang= and sc= can then do something like:

{{ {{{sc|Xyzy}}}|lang={{{lang|}}}| (content) }}

Nbarth suggested {{Xyzy}}; I had been thinking {{xyzzy}} (;-) we can name it whatever. This bit of magic must be very concise, it will get used a lot; hundreds of thousand of times. It provides a small set of script templates for common languages, and otherwise Does the Right Thing.

The set of languages with scripts supplied by the magic is:

code	script template
ar	Arab
fa	fa-Arab
hy	Armn
be, bg, mk, ru, uk	Cyrl
sa, hi	Deva
el	Grek
grc	polytonic
he, yi, arc	Hebr
ja	Jpan
ko	Kore
ta	Taml
te	Telu
th	Thai

(Yes right now you are thinking, but what about ? This list must be very short to work; other languages will simply have to specify the script. Of course we can revise this list, but making it more than a small bit longer is unworkable.) Are we still using {{polytonic}} for Ancient Greek, or it is now the same template/class?

Time for Man U/Bolton, must go now ... Robert Ullmann 14:48, 17 January 2009 (UTC)

RSS Feed

OTRS has gotten a couple of reports that "The Word of the Day RSS feed hasn't been updated since December 23, 2008.", Not sure how to fix this... --Versageek 01:36, 19 January 2009 (UTC)

AFAIK, Connel is the only one who knows how to work that magic. --EncycloPetey 01:44, 19 January 2009 (UTC)

User talk:Connel MacKenzie#WOTD RSS Feed. Conrad.Irwin 01:52, 19 January 2009 (UTC)

page load error trying to open ventana

When I try to open the page ventana I get a page load error. This problem exists a least since one weak. Has someone an idea what happens? Matthias Buchmeier 14:28, 19 January 2009 (UTC)

No problems here [Tried with latest Firefox, Chrome, and IE7 all on MS Vista]. --Bequw → ¢ • τ 06:38, 20 January 2009 (UTC)

American Sign Language language

The categories ase:Etymology and ase:English derivations use {{topic cat}}, which causes them to be included in Category:American Sign Language language, which is properly redlinked, as it exists at Category:American Sign Language. Would it be possible to fiddle with that template (or the responsible subtemplate) so that it treats ase as an exception and categorizes properly?—msh210℠ 20:43, 19 January 2009 (UTC)

That's not so hard — just a one-line fix to {{topic cat parents/default}} if I'm following the code right — but is this something we might want to do for other languages as well? For example, do we want "____ Creole language", or just "____ Creole"? Maybe we should add support for a langdesc= parameter that defaults to language name language? —Ruakh_TALK 22:01, 19 January 2009 (UTC)

Not too active around here any more, but I saw a note about this from msh210. I haven't looked at this code in a while, but I'd probably lean toward doing this in some variation of Template:langname. Currently, I basically call langname and append "language" unconditionally. If there were a template like langname that knew whether or not to include the word "language", that would help here.

That being said, I was never really sold on the idea of using the topic category templates for the etymology and derivation categories. It always seemed to me that there should be something more sophisticated for these cases, but I don't recall whether I had any better ideas on how to approach it. I don't actually recall the details of how langname itself works right now, so that probably doesn't help :) Mike Dillon 23:27, 19 January 2009 (UTC)

P.S. I think you'd probably be dealing with Template:topic cat parents/Etymology, not Template:topic cat parents/default. Mike Dillon 23:29, 19 January 2009 (UTC)

I believe I've fixed this. I had to touch both {{topic cat parents/default}} and {{topic cat parents/Etymology}}. I only did it for "ase". Mike Dillon 05:34, 7 February 2009 (UTC)

Looking at the diffs for my changes ([1], [2]), it's pretty obvious to me in retrospect that a better way to do this would be to make the {{language}} template respond to a parameter that tells it to append the word "language", omitting it for the language codes that already have "Language" in them.

This change should not affect everywhere that {{language}} is currently used since they wouldn't be passing this new parameter, but I'm still not willing to make that change given my recently low level of activity. Seems like something up Robert's alley, but the changes I made should work for this one case. It just sucks to have to change three pieces of markup if anyone wants to add a language to this exclusion list. Nevermind extending it to other cases besides Etymology if they arise. Mike Dillon 05:18, 11 February 2009 (UTC)

Interwicket update

I've taken some of the code from the iwiki bot that updates the entire wikt in one pass, with a global index, and written something that looks at RC on the various wikts and finds things to add here.

I did this more because I wanted to gather more information about the activity on other wikts, not because I wanted to speed up additions of iwiki links; but it is useful. I've noted over time that when I have reason to go look at FL wikts, often there is very little activity (RC last 100 shows several days' worth); but sometimes quite a bit. This way I get to "see" a lot of it. I've noted that the total NS:0 creation rate (not including bots) for all of the FL wikts put together is about the same as the en.wikt rate. For bots, I don't know yet, but looking at the statistics timelines for number of entries one can draw some conclusions.

The practical effect (assuming I or someone keeps running it ;-) is that when entries are added to other wikts that have an en.wikt entry, the iwiki will be added here in some smallish number of minutes (up to 6 hours if the FL wikt is usually very quiet, thus not looked at frequently). When a new entry is added here, it will add any iwikis it finds, like this. It doesn't do an exhaustive search in this case, so some may be left to be found later in a complete pass. It looks at a few large wikts, plus the wikts for the language(s) in the entry, plus any that have iwikis added by the creator.

It also checks sort order whenever looking at entries; if someone adds an entry to an FL wikt, and then adds the iwiki here, the bot will re-check it and sort it in correctly if needed. So it isn't necessary in almost any case to tell well-meaning editors not to add iwikis. They very often want to add an iwiki to the en.wikt, because the "standard" bot relies on hints like that to get started.

So you'll see more edits by Interwicket, comments welcome of course. Robert Ullmann 12:06, 25 January 2009 (UTC)

I've added code to add the reciprocal iwiki link to the FL entry, pointing back to the English. This is desirable for iwiki bot-like things, but runs into the rather large problem of getting bot flags/permissions/(non-denials :-) from 170 wikts... it operates in a test mode, doing a very limited number, unless bot-flagged (or blocked ...). I would like feedback from wherever. Robert Ullmann 14:22, 26 January 2009 (UTC)

StringFunctions

moved from BP

I think it is more logical to 'exploit' the consistencies between language conjugations than rely on users learning to use hard-to-understand templates, for example the Dutch verbs are more or less consistent when split in groups: regular/irregular (some exceptions) with the help of the StringFunction extension we could literally have verb conjugations done within the template instead of using e.g {{templatename|conj1|conj2|conj3|...}} etc. here's a rough sample:

[[{{#sub:{{PAGENAME}}|0|{{#expr:{{#len:{{PAGENAME}}}}-4}}}}{{#switch:{{#sub:{{PAGENAME}}|{{#expr:{{#len:{{PAGENAME}}}}-4}}|2}}|aa=a|ee=e|ii=i|oo=o|uu=u|={{#sub:{{PAGENAME}}|{{#expr:{{#len:{{PAGENAME}}}}-4}}|2}}}}{{#switch:{{lc:{{#sub:{{PAGENAME}}|{{#expr:{{#len:{{PAGENAME}}}}-3}}|1}}}}|f=v|s=z|={{#sub:{{PAGENAME}}|{{#expr:{{#len:{{PAGENAME}}}}-3}}|1}}}}en]]

there are some errors in this, but with a few tweaks it could be used to get the infinitive from a stem of a regular Dutch verb, it is by no means limited to the infinitive of a verbs stem/infinitive, or even verbs. Plural noun forms are pretty consistent, and it would be a ton more user friendly. There is of course the odd exception where this would not work, of which the errors can easily be negated by adding a param.. (note: since the wiki does not currently have the extension installed it would not work right now) 120.16.131.29 12:39, 25 January 2009 (UTC)

on second thought maybe this belongs @ Wiktionary:Grease pit?

The extension will not be installed on any WM project; Tim and Brion think (and I concur), that it is poorly designed and written, and leads to people trying to "program" the template language far beyond what should be done. Combinations of string function and #if and #switch lead to painful performance levels. In our case, the templates can extend easily when provided with the stem (common letter-string, sometimes in a couple of forms), although some do this better than others, some not at all. (did you just drop in to ask this, or are you doing something here?) Robert Ullmann 12:48, 25 January 2009 (UTC)

Kinda, yeah. I saw all this was done manually and thought this was a better alternative and thought I'd suggest it while here, I did not think it was bad performance-wise. As for the templates without the string function, it does work efficiently for some, but unfortunately a lot of the dutch words (for example) with long/short vowel sounds breaking when conjugating them would make the spelling inaccurate. (well, this at least explains the sudden performance drop of an off-site wiki, I guess..) 120.16.131.29 13:06, 25 January 2009 (UTC)

Wouldn't substituting remove the 'performance issue' then? 120.16.131.29 13:20, 25 January 2009 (UTC)

Perhaps, but it would then cause an editing issue. Most users wouldn't know how to read all that code and change the right bit if they found an error. It would also mean that if we decided to change the template format, we couldn't do so without changing every page that had its code substituted. The purpose of a template is to allow control of format from a single location, and substituting eliminates that utility. --EncycloPetey 16:29, 25 January 2009 (UTC)

template:diff

I've created {{diff}} for the display of diff URLs (on discussion pages, naturally). If I missed something, please tweak.—msh210℠ 23:11, 29 January 2009 (UTC)

February 2009

change brite white bak ground to blue/green/gray-ish

since weeks now I am trying to accomplish this. so I can use W.ictionary longer without getting migraine headaches.

I'v managed to make it change in my messenger, but it seems I have to do something in what might be your source language I suppose to have this same background color change on any W.ictionary pages I visit

As this change would have such a tremendous impact in my comfort levels in using your resources, I greatly anticipate any reply in this matter!!

Please disregard any spelling idiosyncrasies, my speech recognition has been playing up dictating this, and since I rely on it to make any corrections, apart from moving the mouse and the occasional tap on my pad, it is not always easy to make it letter perfect -- Thank you so much for your understanding!--史凡 02:12, 12 February 2009 (UTC)

PS. I finally figured out how to make a screen snapshot,, but I don't know how to in clude that word document here, so for now. I cannot graphically illustrate what I tried to express in the above, so much for a picture is worth a thousand words sad smiley

You can change this by adding some code to Special:Mypage/monobook.css. The following code worked for me. I suspect that our resident wizards can come up with something better, but this seems to do the job except for a few leftover islands of white:

body,#content,#wpTextbox1,#toc,.pBody  {
  background-color : #cccccc;
}

(That's for medium-gray; for other colors, replace "CCCCCC" with your hex color of choice.) I never minded the white, but having tried this out, I kind of like it. -- Visviva 03:54, 12 February 2009 (UTC)

Dear Visviva, thank you so much for such an incredibly fast and helpful reply!!

Since I have my monitor 's brightness and colors in the properties down regulated as much as I could, it appears as dark gray to me, but it is definitely a major improvement, so. sincerely thank you once again!!I tried one o ther color, having read again about text colors in Wikipedia[aren't these media fantastic, poor me growing up without them LOL], but that was a garish affair called "orchid", hurtful to the eyes in more than one way, and sins the adaption takes my computer quite a bit each time, apart from the clicking strain on my arms, for now I am happily going to leave it black in gray as it were, thank you so much again!!!--史凡 05:20, 12 February 2009 (UTC)

PS Would it be an idea to repose your help on the tat -- page?; others might find it as helpful as. I did, . Ideally it would just be a Click on the button in the preference page I feel, But I wouldn't know how to do that myself, the latter thing. Thanks again!!--史凡 06:16, 12 February 2009 (UTC)

If you are using FireFox (highly recommended), you can go to Tools/Options/Content/Colors... choose a background colour, and uncheck the box that says "Allow pages to choose their own colors...". This will help you on most sites, not just the Wiktionary. (And it does work here.) Robert Ullmann 10:06, 12 February 2009 (UTC)

Dear Robert, thank you so much for your reply; I am not very knowledgeable about computers, though I do like the technology and opportunities they provide, and when explaind step-by-step i normally manage to use it, at least in the end -- 1 reason I feel so much for an educationally sound approach to things,whether one is talking about writing a scientific article, sharing one's professional knowledge. or, in this case, helping [well, trying to in my case. huh]to make a revolutionary dictionary! .

Is Firefox a web browser like I'm using Opera? I like howOpera remembers my opened windows when restarting my computer, but otherwise don't feel strongly about it, I mean emotionally attachment wise -- if my assumption is right,. how does one get Firefox, from the Internet? [That's why the first paragraph immediately above, shy smiley]; does it help an older laptop [Dell Inspiron, about five years]as myne runs smoothly?

I did see the "skin" -- preferences part on this project. [Or wiki media in general, I really wouldn't know for sure,tho I started this account on wictionary],. But I didn't readily see the background color change I was after, a few days ago that was.

I did manage before to do a similar change to my messenger background, but at least for me. that was not a very straightforward exercise, though I managed under clear the email guidance from a friend, so sure, a more dummy/user friendly interface, or whatever the exact technical word for that, I do would happily embrace!!

Thank you in advance and already for your responses, remaining sincerefully,--史凡 10:41, 12 February 2009 (UTC)

Go to http://www.mozilla.com/firefox/ and take a look; yes it is a browser like Opera and Chrome and that other one. You should be able to run it (although you didn't say what OS version you are on): the website will sort it out for you. I think you automatically get the correct download matching your system when you visit that page. Is free, cost you nothing to check it out. And it does remember tabs and windows between sessions. Robert Ullmann 17:04, 12 February 2009 (UTC)

Dear Robert, Only today I checked here again[I tend to put of such things out of frustrations with computers endured in the past,till as today. My body plays up and basically puts the knife against my throat...] and downloaded the browser successfully!it was indeed very straightforward and fast-- I changed the color settings as explained clearly by you: system colors, giv me my previous messenger background, only a shame this system/Firefox doesn't seem to allow you/1 to define the hex colors at wil!my speech recognition seems to be doing relatively fine (struggling with it is one reason I might be slow in replying generally.) I tested Yahoo and Hotmail, everything seems to be fine! Early around today I had tostopp using the computer because of the bright background screens were causing me troubles/headaches, so once again. Thank you so very much!!!

PS, I dID see Mozilla Firefox software on my computer before, after I got a new hard drive installd by the local ex-pat computer expert here, but not knowing any better, I assumed it just had something to do with my computer security, Internet -- wise , though the antivirus program is AVG-- as you notice it's all a little confusing to me, computer things. bythe way, I think my OS is, windows XP, but even that I'm not sure of shy smiley

Thank you once again!!!--219.69.81.128 11:58, 18 February 2009 (UTC)

By the way Numbertwo, could you perhaps referr me to a passage in greasepit or so (I noticed people mentioning it, but didn't find exactly how to do it) that spells out to me how to get my Toc/table of contents to the right, whith the text wrapping around it to the left -- I tried a couple of times before, but it never worked out sad smiley...

You are welcome! For TOCs on the right, go to WT:PREFS (the extended preferences for the wiktionary) check the top box and the box next to "Put the table of contents onto the right of entries." (last pick in the first section) and click on "save settings".

worked! So cooll, I'm getting more things done with a computer in the last fortnight than in my previous computer life altogether, so thank you (and the others)very much!!!new paragraph, new paragraph.

Iwas told before about options isaw on that list, but look for them in my personal preferences, in my account /related. I mean.

I now realize I could have looked withde control f. functionfor TOC in the grease parlor, but before, and that might have been opera, the search box would cover the actualkeyword, forcing me to drag the box a waymost of the time, exactly 1 of the movements that is poison for my RSI arms, but I promise to check out if like before, on the other" (that is techno-slang for the Microsoft one right?) browser, the box automatically moves away -- most things I ended up asking. I try to find before, but unsuccessfully, computer mor on me said smiley...史凡 15:27, 20 February 2009 (UTC)

Oh, and you can set the background colour in hex in FF, but you have to go a level deeper: type about:config in the URL line; you will then get a warning message (;-), continue, and find the line that says browser.display.background_color double-click on that line (or right-click/modify) and you can put in a hex color. You can also really mess up some things by changing options at this level so have fun! Robert Ullmann 17:19, 18 February 2009 (UTC)

I notice, I can get my customize background color via changing the properties by right clicking on the desktop. So for now I'm going to leave it by that and passed out on the fun. LOL.thanks for explaining clearly though my intention is to come back to your description. Whenever I feel brave enough to give such thing a try!

perhaps a couple of things I noticed on Firefox:

An annoying one: the cursor seems to have the same color as the rim of my windows, and as such is really hard to see on the easy on the eye background colors; I'm talking about the Roman capitalized Council. "I" shaped cursor, like in the editing box ; I tried in the properties where I initially changed the background color of my messenger to locate anything that governs the color of the cursor. But in vain-- would you know how to do this, I mean, how this can be done?

For now I have to move the mouse in circles looking for the cursor. And that's exactly 1 of the movements that make my arms hurt -- right now my speech recognition is working a bit slowly but reliably, but if that software starts playing up. In addition, to me. It's baneful arms having to move my mouse all the time. Already that can push me over the edge, meaning I have to stop trying to redact a post or edit sad smiley

Another thing isthat "red links" now show plain blue as the actual "blue links" meaning that I have to use the mouse cursor, sliding over at the links to see which ones are actually existing entries (and if I get up to speed with Chinese to add more entries smiley)-- would there be a fix for this?

Last thing would be That on Operather wasa feature called "speed dial" or soenabling me to display up to nine favorites websites(and of course wiki media projects were heavily represented smiley) and to go there just by single click -- for nowit has proven to be quite a bit more click intensive to open those twentysomething windows as is might wontshies smiley; do you know about a similar trick for Firefox?

I would like to apologize for the length of the above; thought I' tryd to restrictto wat would make editing on wiki media(I haven't found the trick yetto have my speech recognition display "wictionary", annoying)more feasible to me given my disabilities, I do realize and understand that lengthy posts are a bit/rather frowned upon; since I'm in the habit of blaming my speech recognition for everything, as it's working smoothly, for once, the above will likely read Chatty-- of course I realize, that is not da program but me-- now I just lost my endingto dis post, I guess Dragon speech 9.0 could do with an upgrade sigh -- could it be my Dell Inspiron 5160 is also too slow for such software? I'm a bit isolated here in Kaohsiung Taiwan, and how to find out such info on the web, I'm just not to experienced...

anyhow I just hope to have plenty of practice time with a slick functioning software package in the next days and weeks, so I come to an appropriate posting style and size, as well as to be able to comfortably edit. Thank you so much for your contributions to such!!!史凡 16:06, 20 February 2009 (UTC)

Template parameter expansion for labelled section names

So the line of code is <section begin="etymology"/>, and I want to encapsulate this "etymology" string into a parameter, say {{{section}}}, with the default value of "etymology", so I write <section begin="{{{section|etymology}}}"/>, but as it turns out playing around with Special:ExpandTemplates, this addition does not get expanded, but is left "as is". I thought that MediaWiki was "expand everything first, then evaluate", so how can I get back the desirable behaviour, or work around this issue? :) PS, the template in question is {{etymology-discussion-begin}} --Ivan Štambuk 16:05, 15 February 2009 (UTC)

Things don't get expanded inside extension tags (unless the extension itself does it). But there is an obscure magic parser function, so you can write {{tag:section|begin={{{section|etymology}}}}} which then is expanded (say section isn't defined) to <section begin="etymology"/>. However I'm not sure this works with LST, depending on how it finds the sections to include (is it looking for tags in the wikitext, or does it do some parsing?). "tag", BTW, is the magic for using parameters inside math, hiero, etc tags. Robert Ullmann 11:48, 16 February 2009 (UTC)

Doesn't seem to work...{{#tag:section|begin={{{section|etymology}}}}} in Special:ExpandTemplates expands to <section>begin=etymology</section> instead of the expected <section begin="etymology"/>..? --Ivan Štambuk 12:55, 16 February 2009 (UTC)

I didn't get it quite right, it needs an explicit empty content: {{#tag:section||begin={{{section|etymology}}}}} and then it generates <section begin="etymology"></section>, the question then being whether that is equivalent to the desired tag. (It should be, by the definition of the syntax, but that does not of course mean that it is ;-) Robert Ullmann 08:37, 17 February 2009 (UTC)

Apparently they're not equivalent.. Too bad, we now have to stick with the ugly markup ˘_˘ --Ivan Štambuk 09:31, 17 February 2009 (UTC)

'clear' style in templates

With the ToC on the right-hand side, some pages have elements (e.g. some collapsible boxes) that want to span horizontally the whole content area and have to be below the ToC. Depending on length of the ToC and the position of these elements, this can leave a large, ugly white space in the content area. It happens with {{es-conj-ar}} but not {{rel-top}} for instance. Not knowing too much web stuff, I was guessing it's the style="clear:both;" that's causing the problem. Is there some reason this is needed, or can this be removed with out trouble from templates? Are there exceptions? Thanks.--Bequw → ¢ • τ 06:04, 16 February 2009 (UTC)

They shouldn't be using clear:both. "wanting" to span the whole width is wrong anyway, as (e.g.) es-conj-ar only takes up half of my screen width, the rest is wasted horizontally. The NavFrame et al classes have the correct style(s). (width:auto) Robert Ullmann 11:40, 16 February 2009 (UTC)

Watchlist questions

I seem to remember the watchlist as formerly including all the changes on a page, not just the most recent one. It doesn't seem to do so any more. I haven't run any experiments even on the current state of affairs. But for at least several weeks I find that when I go to the discussion pages, there are comments I missed on discussions that I would have wanted to participate in (not to mention Votes).

Questions:

1. Is my memory correct that formerly the watchlist worked differently?
2. Is my understanding that the watchlist only has the most recent change correct?
3. If there has been a change, what caused it?
4. How should I have found out?
5. What can I do to not miss comments on discussions? Do I have to check history for each discussion page? DCDuring TALK 15:40, 17 February 2009 (UTC)

Special:Preferences -> Watchlist -> Expand watchlist to show all applicable changes, is this what you want? -- Prince Kassad 15:44, 17 February 2009 (UTC)

Yes, indeed!!! Thank you! I had missed it on three looks at that page. Has there been any change in that or was my problem self-inflicted? DCDuring TALK 17:06, 17 February 2009 (UTC)

This has been the default watchlist behavior for as long as I can recall ... My guess would be that you had changed the setting earlier, and inadvertently changed it back? (I think I have inadvertently reset my preferences to default once or twice, though I don't remember how it happened -- possibly something to do with changing my password.) -- Visviva 17:57, 17 February 2009 (UTC)

I remember doing some experiments, didn't remember that change in particular, and simply didn't see it even when I was specifically hunting for a switch. D'oh. DCDuring TALK 21:38, 17 February 2009 (UTC)

Template:top, Template:mid

I added Papantla Totonac and Mandaic translations to water. However, these don't work because of their language codes (top and mid, respecticely), which are already in use. As these templates have up to 8,000 inclusions and are used varyingly (which rules out bots and the like), I'm asking if there's any workaround to the problem. -- Prince Kassad 20:32, 21 February 2009 (UTC)

Those templates are (slowly) being phased out. In Translations sections, {{trans-top}} and {{trans-mid}} should be used. In other sections, {{top2}} or {{top3}} (and corresponding "mid" templates) should be used. Unfortunately, the change is a very long one to implement. --EncycloPetey 06:08, 24 February 2009 (UTC)

Papantla Totonac could just be entered as plain wikitext, without using {{t}}. In fact that's probably preferable for most languages that don't have their own wikt. Not sure what to do about Mandaic, as it requires {{t-image}}. -- Visviva 06:56, 24 February 2009 (UTC)

Something is wrong with the Mandaic {{t-image}} (water), but there are no instructions for using the template. —Stephen 20:29, 22 March 2009 (UTC)

Yeah, it tries to use the contents of Template:mid as a piped link. But since Template:mid is not a language template, it fails at creating the link and instead prints an error message. And yes, I should probably write some instructions on using t-image, currently only I know how it works. -- Prince Kassad 20:45, 22 March 2009 (UTC)

Maybe it would work if we made {{lang:mid}}. That’s what I did with {{lang:top}} and it works for Papantla Totonac now. —Stephen 21:00, 22 March 2009 (UTC)

Removed that crap again. It is hard enough to fix things without re-breaking things. Robert Ullmann 01:59, 23 March 2009 (UTC)

t-image uses a different code from Template:t. I believe it would only work if you set the language parameter in the template to lang:mid too. -- Prince Kassad 21:08, 22 March 2009 (UTC)

I don't know if that's a good solution. {{mid}}, {{see}}, and {{top}} are the only remaining templates which are in the way of language templates, and are already in the process of being phased out. It seems silly to introduce code into a widely used template ({{t-image}}) just for this one situation. Couldn't we just do a subst hack of some sort for the time-being? -Atelaes λάλει ἐμοί 21:24, 22 March 2009 (UTC)

We used that in the beginning, but it confused AutoFormat. -- Prince Kassad 21:36, 22 March 2009 (UTC)

Note that not everything has to be FORCED into {t}. Especially if you have to break something else. Just write out the link normally?

That said: {t-image} is not "widely used" (:-), it is used in water and nowhere else. Yes, the intent is to use it more widely, but there is also an easier way to do it (;-). But in any case, we can (and I have) hacked "mid" = "Mandaic" into it for now. That solves the singular case we have. (It doesn't require some ever-growing switch; and wouldn't be absolutely terrible to leave for a fairly long time.) I also fixed {t-image} to display in-line without using a table and on the same line; this will still show extra line breaks on some older browsers. See the first table at water.

As to replacing top with trans-top; this was to be done automatically, when found in trans sections, but DAVilla complained violently about that flooding the category for missing trans glosses. (AF has the code, it takes putting one regex back to what it was.) Then the remaining top/mid/bottom can be automatically changed to top2/mid2/bottom. We could also change top in trans sections to (say) {old-top}, and the others to {top2}, and then proceed as now with the slower process of adding glosses.

I might mention here that if you add a gloss to {top}, AF will quickly pick that entry up and change the template names to the trans- names, you don't have to do that yourself. Robert Ullmann 01:59, 23 March 2009 (UTC)

warning, contains unmarked snark: One more thing, even though the birds are telling me to sleep now: the {{tø}} template was only created so that Tbot could turn off the t/t+/t- functions for all the languages without wikts (where t's primary function is pointless) without just expanding back into piped link syntax. If you suffer from OCD, and will be in personal pain if you can't use {t} everywhere, note that tø has no use for the code whatever. Just do this: e.g at water

{{tø||chuchut|xs=Papantla Totonac}}

or you can put "top" in if you really want to (we care about your pain). It won't matter either way. (Ha!) Good night (morning) to all, Robert Ullmann 03:00, 23 March 2009 (UTC)

Let's change the {top}s in trans sections to {old-top} (and mid too). Then we could decouple the translation-gloss problem from the this-language-has-no-lang-template problem. We would all sleep better I think. --Bequw → ¢ • τ 03:28, 23 March 2009 (UTC)

Yes, certainly. There are (as of yesterday morning) 7431 uses in 7276 entries within translations sections, and 34 uses under other headers. I'm working on changing all (NS:0) {top} to {old top}, {mid} to {old mid}; but to top2/mid2 in those other sections. We will have to then see what use there is outside NS:0 (I haven't looked yet ;-). There are, however, hundreds of recent uses, so it may take a little while; people are still creating entries with {top}. These could be automatically fixed by AF going forward for a while? Would end up in that fix category. Robert Ullmann 00:27, 25 March 2009 (UTC)

Noted on Wiktionary:News for editors. Nadando 00:42, 25 March 2009 (UTC)

Much better I think to do it this way: AF has been converting {top} to {trans-top} when a gloss is present. It was converting all of them, but DAVilla complained that Category:Translation table header lacks gloss was getting "flooded" while he was trying to work on it. That was two full years ago. It is high time we put the remaining 7K entries and any new ones in that category to get cleaned up. All I need do is un-comment one line in AF, and editors need not do anything differently from what they (should ;-) already be doing. Much simpler. And I'll go fix the uses outside trans sections now. Robert Ullmann 01:25, 25 March 2009 (UTC)

Thanks. --Bequw → ¢ • τ 02:10, 25 March 2009 (UTC)

Serious magic ... "top" and "mid" will work in the various templates like {t}. The codes won't work on their own (but then we seldom do that), but are also not subst'ble. When we complete the process, they will be ordinary code templates. Robert Ullmann 05:38, 27 March 2009 (UTC)

Minor auto-redirect bug?

Visit this URI for example, where a user's name is "misspelled" only in being miscapitalised: [3] The automatic redirect says "(Auto-redirected from User%3AdavidFarmbrough)". I think the colon should not be escaped here. Is it a small bug? Equinox ◑ 23:30, 22 February 2009 (UTC)

Fixed, thanks. (Hard-refresh //en.wiktionary.org/w/index.php?title=-&action=raw&smaxage=0&gen=js&useskin=monobook, and/or wait a month, to see the change.) —Ruakh_TALK 00:51, 23 February 2009 (UTC)

The American illustrated medical dictionary

For your consideration, The American illustrated medical dictionary. Published in 1922, so this is from the last year for works automatically falling into the public domain. A brief review suggests that the definitions are nonetheless generally current (and even those that are not should be included here as obsolete forms). Can we import this? And if so, can someone with the requisite magic wiki-fu do the deed? Two caveats, btw, a small number of the entries are proper names, and some of them (those containing commas) indicate multiple spellings of the same word. Cheers! bd2412 T 00:11, 24 February 2009 (UTC)

No preview available? -- Visviva 01:36, 24 February 2009 (UTC)

Huh? Should be. It has the [View page images] link, and the entire book is there. I just don't know how to import it. bd2412 T 05:06, 24 February 2009 (UTC)

Nope, it's fully invisible here in Korea. Maybe it can be only be viewed within the US? At any rate, if all we have to go on is an OCR'd PDF, it's likely going to be quite a lot of work (proofreading, basic formatting) to get it into wikifiable condition. The nice thing about Webster is that it had already been prepared in a proofread HTML format, and just needed some relatively mechanical conversion. -- Visviva 06:59, 24 February 2009 (UTC)

Perhaps we could import it into a temporary space? I'm really most concerned with words in the work that are missing altogether here, which is probably a small subset of the whole. bd2412 T 17:03, 24 February 2009 (UTC)

Can't be seen from here (UK) either, does it have the PDF download, and if so, could you put it somewhere? Conrad.Irwin 20:39, 24 February 2009 (UTC)

Very temporarily at http://dax.wustl.edu/~msh210/AIMD.pdf.—msh210℠ 22:24, 24 February 2009 (UTC)

Ironically enough, I can't open the pdf. But does it matter, as long as someone with the appropriate skills can see it, and can pluck out the definitions that we are missing? bd2412 T 20:59, 26 February 2009 (UTC)

Actually after the last posting I was able to access and download it through Circumventor/Glype. (Hurrah for proxies!) But it seems that the OCR'd text is not actually included in the PDF. So either we need someone with a good OCR program, or we need an extremely patient person (or persons) to cut and paste each individual page from b.g.c. into a text editor and wikify the headwords. I did this for column 2 of page 17 and both columns of page 18, see User:Visviva/AMID1 (or see here for the original dump before any manual edits). I don't think this could be importable -- not without much better OCR, anyway -- but it would be a useful guide to missing entries/senses. -- Visviva 09:38, 27 February 2009 (UTC)

If a patient human could do that page-by-page cut and paste job from Google Books, surely a program could do the same? bd2412 T 01:15, 28 February 2009 (UTC)

Yes. In fact, the "View plain text" option doesn't use AJAX or anything — the text is just in the bare HTML, the whole page is a single HTTP request. —Ruakh_TALK 02:54, 28 February 2009 (UTC)

That program would need to be in US, though, or using a more forgiving proxy than Glype. Because it's intended to forestall censorship at both ends (I guess?), Glype hashes all the URLs so that there is no way to extract a pattern from them. I don't know enough about proxies to find a way around this. -- Visviva 05:49, 28 February 2009 (UTC)

Could someone outside the US write the program and send it to someone in the US with instructions on how to run it? bd2412 T 07:01, 28 February 2009 (UTC)

Actually, here's what I would do, from the Duct Tape school of not-exactly-programming: 1. Get the pattern for the text URLs.. This should be something like "http://books.google.com/books?id=0Di6AAAAIAAJ&pg=PAxx&output=text" where xx is the page number. 2. Make an HTML or wiki page of links to all the text pages (they should come in increments of 5); a spreadsheet is handy for this. 3. Use any of various link-downloading programs (such as DownThemAll for Firefox, or Linky if you don't actually want to download) to fetch all the links. 4. At this point you have all the pages; you can either do some fancy program-y thing to extract the text and strip out the tags, or just C&P 240 times (if you use the pasteboard in NoteTab Light this can go surprisingly quickly). -- Visviva 07:35, 28 February 2009 (UTC)

Since it looks like the solution is going to be copy-and-paste, shall I put these under User:Visviva/AMID(x), or in Wiktionary space? bd2412 T 18:15, 4 March 2009 (UTC)

Webster 1913: classified as spam

I am trying to add a link to Webster 1913 using the template "* {{R:Webster 1913}}". But upon saving the addition of the template, I get the following message:

Spam protection filter

The page you wanted to save was blocked by the spam filter. This is probably caused by a link to a blacklisted external site.

The following text is what triggered our spam filter: http://machaut

Return to designate.

Can someone knowledgeable please fix this issue? --Dan Polansky 11:03, 26 February 2009 (UTC)

Adding to designate? I didn't see any problem. Sometimes there is existing text (links) on the page that have since been added to the blacklist. Robert Ullmann 11:11, 26 February 2009 (UTC)

There aren't any links to http://machaut in the wikt (now); but that isn't even a complete link? I dunno. Robert Ullmann 11:18, 26 February 2009 (UTC)

Hmm. The issue is no longer there. Thanks for having looked at it, anyway. --Dan Polansky 16:48, 26 February 2009 (UTC)

easy way of giving in IpA and pinyin?

dear Greece pit,I discovered in WT:prefs the edit tools -- addition, I stumbled upon it as it were, under my search box,and happily further discoveredthat finally with that additionI can give in, what I mentioned in da headline; to my surprise, I didn't see such edit tools When actually editing in wiktionary, so I had to, a bit in acumbersome way and notvery good for myRSI arms, to then giv in the IpA say,in the search mask,. And then cut and paste itto the actual editing mask--is there a more elegant and ergonomically sound, wayto the same effect Available please?thank you in advance--史凡 15:39, 26 February 2009 (UTC)

PS source language-- dummy me, could somebody explain to me how com the "{{" around the IPa notation -- is that to link it to something like a categoryor so.?

The "{{" is there as a way of transcluding the template {{IPA}}, which helps to ensure that everything displays correctly.

I'm afraid I really couldn't understand your first question. If you're asking whether there is a way to have IPA available without having to navigate the dropdown, I think the answer is yes, but it's a bit tricky. There was something going on with customizable edittools that I haven't heard much about lately... maybe someone else can fill in the gaps. -- Visviva 05:53, 28 February 2009 (UTC)New paragraph.

dear vis Viva, I'd just sow your reply, thank you so much!!I'll work through the various points: sign.

Please let me rephrase: sign. I can now give in IP a [ and pinyin should be possible too, just didn't try it out yet.] in my search mask, using " editing tools" and then copy it from ther in the edit mask-- is their a way of doing this directly, givin the IP a in the edit mask?

. I just spent four hours reading up technical Internet terms on Wikipedia,, but unfortunately I have stilno idea what is colon sign transcluding? Navigate the drop down?

My writing style colon : rereading it myself. I often cringe, but as it is now, I will have to work with an imperfect set up, including a trickiespeech recognition. I do appreciate your and other peoples efforts to nonetheless, answer medeeply though!!

I did manage to get my cursor visible again when editing through again changing the background color. What should be red links still appear as regular blue links thoin the user pages sat smiley.New paragraph

[. I think I can provide screenshots by now, I think I know how to do that. But am not sure whether such would be appreciated by the community, so I won't for now].

r categorys is vital? It seems so from the random reading I did,at least in some posts, but unfortunately, to me. Having these appear in respective entries is something I still have to learn -- is there a trickto do this ?

[For example, I finally made another new entry about Mandarin today, imperfectly, for now, on the other hand. It's such a high frequency word. It pains me not to see it in yet, in your dictionary I mean, confused smiley]

I do not expecta written out reply to each of the points I mentioned; I am more than happy to read concerning wiki documents, but I have a little problem locating them just by myself sad smiley

Thank you so much again for your answer!!!--史凡 15:41, 6 March 2009 (UTC)

A way of tracking a specific language

Hi all,

I'm still working out some of the kinks in this, but I thought I'd mention it here, as it may be useful for people who want to keep an eye on a specific language or languages: [4]. Basically the idea is to provide a pseudo-RC list for all non-bot changes to a specific language's language sections and translations. Caveats: note that the lists don't substitute for either RC itself or a robust watchlist, as they lack most of the patrolling bells & whistles; they also ignore talkspace and topline edits, which a person with an interest in a particular entry would want to know about. Also, since this currently runs on my desktop (the output then being FTP'd to the server), occasional outages should not come as a surprise. ;-)

If you do make use of this, please let me know if you encounter any fresh bugs. Note that any false positives from before roughly now -- 16:05, 26 February 2009 (UTC) -- have probably been fixed at the source, and are just working their way through the system. Oh, and if anyone has any bright ideas about formatting, lay 'em on me. :-) Cheers, -- Visviva 16:05, 26 February 2009 (UTC)

Incidentally, it's fun to note that the (entirely unscientific) list of most active languages recently went from "English, Translingual, Italian, Spanish, French" to "English, Finnish, Lithuanian, Spanish, Egyptian". There's more going on around here than meets the eye -- kudos to Hekaheka, Opiaterein and Strabismus for their yeomanly labors. -- Visviva 12:32, 27 February 2009 (UTC)

This is really cool!. Have you considered getting a toolserver account to run things from there? Conrad.Irwin 13:08, 27 February 2009 (UTC)

I did, but it looks like they have a very long backlog (e.g. the request made by our own TheDaveRoss in Feb. 2008 is still pending), so I figured I would just muddle through on my own. :-) -- Visviva 13:14, 27 February 2009 (UTC)

I've been wanting to see such a feature for some time now. Thanks Visviva for doing it. I wonder, though, if such a thing might possibly be incorporated into the MW software itself, either as an option for rule based watchlists, or qualifications to a user's view of RC or something. No idea if this is feasible. -Atelaes λάλει ἐμοί 21:03, 27 February 2009 (UTC)

It would certainly be very cool if it could be built in; but that seems unlikely to happen until we get our own dedicated software (ha!). Prove me wrong, devs, prove me wrong...

Then again, while playing around with RSS, I discovered that it is possible to do something like this with the MediaWiki RC feed in Google Reader -- because the RC feed includes the diffs, you could set your subscription to filter out any diffs that do not include specific words or phrases (such as a language name). This is clunky, though, since it would exclude e.g. edits within a language section that don't happen to include the language name in the diff or summary. On the other hand it would include pertinent edits in other namespaces, which might be useful. On the third hand, the RSS feed seems to have a very low job priority, and often updates slower than my hand-rolled lists.

A third possibility might be to home-roll a setup for rule-driven watchlists feeding off the API (with an x-minute update cycle). Not sure if either Devtionary or Toolserver would work for this, as there needs to be a setup for normal-user accounts. (... or does there? maybe all rule-driven watchlists could be public.) -- Visviva 05:24, 28 February 2009 (UTC)

Awesome! :-D   —Ruakh_TALK 02:49, 28 February 2009 (UTC)

March 2009

Wiktionary for automated lookup of translations and synonyms

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

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

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

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

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

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

Converting Wiktionary data to MDF/Shoebox format

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

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

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

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

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

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

LST limits?

Hi all,

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

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

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

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

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

Hidden content in Navframe's

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

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

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

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

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

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

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

automated adding of pinyin to Chinese entries

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

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

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

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

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

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

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

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

[[foo#bar|]]

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

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

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

Bug: case translation in search box

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

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

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

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

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

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

when a page needs attention by someone versed in a particular field

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

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

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

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

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

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

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

edit toolbar problem

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

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

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

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

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

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

Overlapping content in Chrome

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

April 2009

Need an option so that searching is not so sensitive to accents

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

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

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

All the best.---

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

older changes to watchlist

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

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

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

Talk:opposable

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

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

{{context}}

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

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

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

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

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

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

Recursive templating

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

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

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

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

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

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

use file: namespace in {{audio}}?

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

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

.Orya

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

Recent changes oddity

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

donger and entrée as Australian French?

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

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

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

Showing image

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

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

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

More broken template stuff

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

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

Wiktionary:Random page, worth keeping on the sidebar?

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

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

Latin irregular verb conjugation

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

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

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

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

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

Snippets in search results

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

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

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

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

Yahoo/Altavisa do a reasonably good job-

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

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

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

IP block exempt

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

Wikisaurus bot idea

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

May 2009

Must have.

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

Green links on Spanish adjectives

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

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

Error on page

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

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

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

contextification request

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

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

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

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

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

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

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

Bad links to Wikipedia -- bot run.

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

{{topic cat}}

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

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

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

June 2009

Numbering problem caused by Template:quote-book and Template:quote-news

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

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

Hyperlink has changed

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

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

{{nl-verb}}

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

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

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

{{fr-infl-noun}}

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

Unexpected response from wiki server

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

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

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

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

Special:PrefixIndex

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

This would be "prefix" in the computing sense, not the linguistic one. We can change the text fairly easily, by creating MediaWiki:prefixindex (default: "All pages with prefix"), MediaWiki:prefixindex-summary (default: ""), and/or MediaWiki:allpagesprefix (default: "Display pages with prefix:"). Changing the name would be more difficult; it's internationalizable (e.g. on French projects it's called "Spécial:Index"), but I believe that's basically baked into the code.

We shouldn't really be sending readers to Special:PrefixIndex, since it's not part of our content per se. It's useful for editors, and sometimes as a kludge we might point readers there, but if we're worried that it might confuse readers, then the problem is that readers are seeing it, and the solution is to remove the need for readers to see it.

—Ruakh_TALK 14:15, 12 June 2009 (UTC)

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

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

Hebrew: Old and New

Hello. Could someone who knows how please change our use of the ISO 639-3 codes heb and hbo to read Modern Hebrew and Classical Hebrew, respectively? At present, they and he (Hebrew’s ISO 639-1 code) all yield Hebrew. It would be useful for the display to be as follows:

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

Ideally and intuitively, there would also be the autocategories Category:Hebrew derivations (which we have) for Hebrew, Category:Modern Hebrew derivations for Modern Hebrew, and Category:Classical Hebrew derivations for Classical Hebrew.
My thanks to whomever. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 13:21, 15 June 2009 (UTC)

I think the consensus has been to treat it as one language for {{heb}} purposes at least: I'm not sure about for {{etyl|heb}} purposes.​—msh210℠ 16:40, 15 June 2009 (UTC)

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

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

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

Template:langcatboiler

Currently, you can only use 38 of the 58 possible country parameters because this Template exceeds the MediaWiki template limits. Is there any way to fix this problem? There are some languages spoken in more than 38 countries, including but not limited to English. -- Prince Kassad 19:39, 15 June 2009 (UTC)

This doesn't answer your question, but a hack is of course to catgeorize manually. (That's all adding those parameters does, anyway.)​—msh210℠ 20:09, 15 June 2009 (UTC)

To me, the sort key appended to all country categories seems rather useless since it does not change the sort order at all, but I don't know much about templates. -- Prince Kassad 20:22, 15 June 2009 (UTC)

You can use up to sixty country parameters now, and the sort keys were removed. Of course, the manual categorization is working as well. It's up to you choose manual categorization or the {{langcatboiler}}. However, I'd prefer the latter for consistency, because as they're both accepted, I'm doing my best to add this template to all language categories, then check all the parameters for countries, language families and interwikis. --Daniel. 21:38, 15 June 2009 (UTC)

Category:English verbs which are their own past participle

Can't this be populated automatically by {{en-verb}}? Add something like {{#if:{{{3|}}}|{{#ifeq|{{{4|{{{3}}}}}}|{{PAGENAME}}|[[Category:English verbs which are their own past participle]]}}}} perhaps?​—msh210℠ 20:12, 16 June 2009 (UTC)

Probably, but is the added strain to the server worthwhile? It must be a very, very limited set of English verbs that have this property. Adding an extra if check to every English verb entry on Wiktionary seems to more than counterbalance a desire to save on adding the category. It also wouldn't catch the verbs like (deprecated template usage) burst that optionally have the same past participle and have had explicit multiple forms added. --EncycloPetey 20:23, 16 June 2009 (UTC)

For one point of view, see w:wp:don't worry about performance.​—msh210℠ 21:58, 16 June 2009 (UTC)

Wikipedia makes far less use of these sorts of templates, and so seldom has to consider them. In cases like this, the effects have been measurable and considered before on Wiktionary. And there is still the second point I raised, which would not be solved by a template change. Further, any addiitonal variant forms of past participles added in a verb's template would de-catagorize it under the proposal. I think tracking down the verbs and categorizing them by hand (or by a bot given the list) is a smarter move. --EncycloPetey 22:08, 16 June 2009 (UTC)

Okay, fair enough. I suppose a bot could even track them down. (It shouldn't be too hard to find even those that list more than one past participle, I imagine.)​—msh210℠ 22:39, 16 June 2009 (UTC)

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

Wiktionary:Votes/pl-2009-06/Add en: prefix to topical categories

Sort of realised that 24 hours later nobody has commented on this - perhaps I posted it to the wrong place? Anyway, please add your two cents if you feel like it. Mglovesfun 18:57, 17 June 2009 (UTC)

You didn't get comment because the vote page isn't properly formatted, nor was it ever added to the WT:VOTE page. See the instructions at the top of that page to see how to initiate a vote. --EncycloPetey 19:03, 17 June 2009 (UTC)

Assisted translation entries with commas

Every day somebody adds two or more words, separated by commas, using the excellent assisted translation system. Of course, it produces a single, red-linked entry instead of the multiple separate entries intended. Could the system be modified to either produce the multiple entries, or to give a warning message? SemperBlotto 11:39, 18 June 2009 (UTC)

If you clear your cache (ctrl+shift+F5) you should see the new version that will produce one of two error messages (by default everyone will see "You can only add one translation at a time. If this is one translation that contains a comma, you can add it by clicking here." and nothing will happen. However if they have previously clicked on that message they will see "Please click undo if you were trying to create a list of translations in one go, this is currently not supported." and the translation with a comma will be added. When they click on the second message, the system will default back to the first behaviour). Conrad.Irwin 02:38, 19 June 2009 (UTC)

MediaWiki talk:Edittools

This page is now over 26K, which is too large. The entire thing has to download each time you open an edit window, and there are some machines I use where I may have to wait 20 seconds for the edit window to open now. How can we shrink the size of this overgrown monster? Ruakh seems to have done some work, but can we do more? --EncycloPetey 15:05, 18 June 2009 (UTC)

I think the next step would be removing unneeded letters. For example, the plain Latin letters (A, B...) in the Yoruba section are not needed as they're on everyone's keyboard. -- Prince Kassad 15:13, 18 June 2009 (UTC)

I've just now finished my changes; all told, I've brought the edit-tools down from 172KB to 27KB, without actually changing anything. 27KB is still a lot — it's more than half the page, bit-wise — but it should reduce your wait-time by a factor of roughly 4. Next up, we should consider changes that do actually change things:

• removing the plain Latin letters that Prince Kassad mentions.
• removing, or at least merging, the duplicate Latin/Roman sections. I understand that it's a pain to use the huge "Latin/Roman" section for languages with just a few diacritics, but then, it's also a pain to navigate a huge list of identical languages.
• removing "heavy" sections, such as sign languages, and creating a way for interested editors to re-add them as a customization.
• removing little-used sections. I don't know which these are, but we can probably get statistics on which languages aren't really active. (I think Visviva can help with this.)
• removing some of the excessive explanations, both in-line and in tooltips (hover-text). Does every single edit-page on the site the "approximately equals" tooltip?

—Ruakh_TALK 16:25, 18 June 2009 (UTC)

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

Well, we already are using JavaScript. Heavily. I assume you mean we should move the actual characters into an external JavaScript page? If so, I agree, but there are some things to keep in mind:

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

All told, I don't think someone should just "[do] it before [you] get round to it" — details need to be hammered out, preferably with input from BP-izens.

—Ruakh_TALK 15:28, 19 June 2009 (UTC)

I am not sure there is a connection, but I have twice today had the same problem. Selecting the alt spellings template from edittools led to the non-recognition of the template on saving. I would guess that there was a look-alike character in there. This is the problem version cut and pasted: "alternative spelling of". Cutting and pasting from the template headword or typing generated the expected response. DCDuring TALK 18:05, 19 June 2009 (UTC)

Does this happen each time you use the Edittools for that template, or just intermittently? It worked just fine for me a moment ago. --EncycloPetey 18:26, 19 June 2009 (UTC)

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

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

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

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

Search box

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

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

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

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

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

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

Yes, I had. —Ruakh_TALK 19:33, 14 July 2009 (UTC)

That's a relief. DCDuring TALK 19:35, 14 July 2009 (UTC)

Talk:فروردین

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

In the header of this section, you link to the talk-page for Template:fa-Arab, with the second-to-last letter being U+06CC ARABIC LETTER FARSI YEH. In that talk-page, you link in turn to the talk-page for Template:fa-Arab, with the second-to-last letter being U+064A ARABIC LETTER YEH. These two letters seem to be indistinguishable, or nearly so, in the middle of a word, but at the end of a word the former lacks the two dots of the latter, as you can see by inserting a space after each: Template:fa-Arab vs. Template:fa-Arab. (The exact details might depend on your fonts: I'm not sure how well the various fonts reflect the different forms of Arabic letters at their various positions in a word. Since I can't read the script, I've never had occasion to worry about it.)

If you have JavaScript enabled, I recommend using the edit-tools instead of Character Map. Right below the "Save page" button, you should see a drop-down menu; if you choose "Arabic", you'll get a list of links to insert Arabic letters into the edit-box. The Persian-specific letters are well indicated.

—Ruakh_TALK 02:54, 25 June 2009 (UTC)

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

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

Jcwf 13:47, 25 June 2009 (UTC)

Shortcut to Wiktionary:About Serbo-Croatian

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

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

Problems with section-linking when using {{temp}}

I include this subtitle to allow functioning section-linking to this discussion. My initial post should exemplify this problem.

Problems with section-linking when using Template:temp

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

Seems to be fixed when you clear your cache (ctrl+shift+F5). Conrad.Irwin 20:51, 25 June 2009 (UTC)

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

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

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

Another possibility might be to add something like

addOnloadHook(function () {
  if(wgAction != 'edit')
    return;
  if(! /[?&]section=\d/.test(window.location.href))
    return;
  var wpSummary = document.getElementById('wpSummary');
  if(! wpSummary)
    return;
  if(! /^\/\*.*?\/\* $/.test(wpSummary.value))
    return;
  wpSummary.value = wpSummary.value.replace(/\{\{temp(late)?\|/g, '{{');
});

What this does is, if the user is currently editing a numbered section, and the edit-summary looks "fresh" — we don't want to mess with an edit-summary the user has already touched — then it finds all instance of {{temp| or {{template| in the edit summary, and changes them to plain {{. This won't work when the user is creating a new section (and can't be made to work in that case, because the same field serves both as the edit-summary and as the new section header), and it won't work for pre-existing edit summaries; but then, it doesn't have to replace Conrad's code. The two aren't mutually exclusive.

I'll wait a day or so, and if no one objects, I'll make the change.

—Ruakh_TALK 01:27, 29 June 2009 (UTC)

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

Word of the day

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

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

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

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

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

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

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

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

I notice that you have made the chnage to the WOTD template, but not to the entry for the word itself, which was the source of the definition. Yuo are always welcome to update the selected entries before their definitions are copied into the WOTD templates. --EncycloPetey 14:54, 25 June 2009 (UTC)

Ah, now that's what I was looking for. It's academic now because we have a different word of the day now, but thanks for the information. — Paul G 13:05, 26 June 2009 (UTC)

Babel template?

Hi. I was wondering if someone could please create the template grc-0 (so I can put it on my userpage)?  :) I know a few roots from ancient Greek (from studying word etymologies) and Latin and there is a lt-0, de-0 and fr-0 but I don't want it to look like I know Greek better than the others. Thanks! Logomaniac 22:23, 27 June 2009 (UTC)

Generally, the X-0 templates aren't very useful here, and we tend to discourage them. It would be better to describe your minimal skill in a text portion of your user page, appropriately labelled, rather than advertise in your user box that you don't understand that language. --EncycloPetey 00:01, 28 June 2009 (UTC)

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

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

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

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

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

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

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

Not that I can tell.​—msh210℠ 17:35, 29 June 2009 (UTC)

Search: where did the preload templates go?

It looks like the Mediawiki people or somebody else has mucked around with the search so that instead of helpful preload options for a new entry when an non-existent entry is entered in the Search box, a barebones search page comes up instead. — Carolina wren discussió 04:12, 2 July 2009 (UTC)

Not only that, but this means that the "near"-spelling search that used to happen automatically now requires a user to initiate a seacond search to actually get the search to occur! That's silly. Instead of getting a list of the closest matches, it returns only a single "did you mean"? That may be fine for an encyclopedia, but it's counterproductive and harmful to a multilingual dictionary. --EncycloPetey 15:27, 4 July 2009 (UTC)

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

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

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

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

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

Other MW mucking

On a related note, it seems that additional legal warnings have been added to the edit window. I now have to scroll down each time I need to insert certain special characters, then scroll back up to see the edit window. Specifically, I now get:

By saving, you agree to irrevocably release your contribution under the Creative Commons Attribution/Share-Alike License 3.0 and the GFDL. You agree to be credited by re-users, at minimum, through a hyperlink or URL to the page you are contributing to. See the Terms of Use for details.

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

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

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

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

There's a new WT:PREFS option "Hide the copyright warning in the edit window." you might want to try out. -- Prince Kassad 18:27, 4 July 2009 (UTC)

It would seem to make sense to combine the two boring paragraphs into one that more people will hopefully read. (it particularly irks me how they expand "Creative Commons Attribution/Share-Alike License 3.0" but leave "GFDL" condensed) Conrad.Irwin 19:53, 4 July 2009 (UTC)

Thanks. That WT:PREFS option helps enormously! --EncycloPetey 20:16, 4 July 2009 (UTC)

Thanks. PrinceK. DCDuring TALK 21:57, 4 July 2009 (UTC)

Those who wish the pref to follow their account rather than their computer can add #editpage-copywarn{display:none!important} to their monobook.css. (Untested, but should work.)​—msh210℠ 15:24, 6 July 2009 (UTC)

Miscategorisation of præserves

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

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

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

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

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

I see. I still think that the categorization system in question (i.e., separating various characteristics of verbs into different categories, such as Dutch verb singular forms) is appropriate for many languages, so I'd like to keep my edits in the three templates above. I agree that this is not appropriate for English, though. Then, I also propose these watertight categories for the few possible English conjugated verb forms:

• English verb forms
  • English verb irregular forms
    • English irregular past participles
  • English verb simple past forms
  • English verb archaic second-person singular present indicative forms
  • English verb third-person singular present indicative forms
    • English verb archaic third-person singular present indicative forms
  • English past participles
    • English irregular past participles
  • English present participles

--Daniel. 19:14, 5 July 2009 (UTC)

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

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

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

disclike

I'm trying to work out why this isn't categorising correctly. The syntax looks okay to me {{suffix|disc|like}}, surely like is a suffix, it's not a combining form, is it? Mglovesfun (talk) 21:14, 5 July 2009 (UTC)

Hmm, putting lang=en seems to solve it, although English is supposed to be the default anyway. I'll have a look at the coding. Mglovesfun (talk) 21:16, 5 July 2009 (UTC)

It looks as though User:Opiaterein had done a test edit on the template that broke its categorization function. I've alerted him. --EncycloPetey 04:59, 6 July 2009 (UTC)

Search box special characters

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

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

ionly c cifredbox>hwo2display?

Hanzi

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

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

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

When deleting an article

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

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

Category:Dutch_weak_verbs won't update

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

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

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

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

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

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

Quite so. Running ... (:-) Robert Ullmann 15:12, 12 July 2009 (UTC)

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

Collapsing boxes not working

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

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

Ah, so it happened because I switched to the Vector theme (from monobook). Changed it back and everything works fine again. Is there something people who use non-monobook themes have to do to enable this (and possible other js things)? --Bequw → ¢ • τ 17:52, 12 July 2009 (UTC)

I suppose the best way would be the refactoring of MediaWiki:Monobook.js → MediaWiki:Common.js. While very useful I understand that that has been put off for some time. Including MediaWiki:Monobook.js from my user Vector.js works, but leaves things a bit ugly (probably because it's lacking some of MediaWiki:Monobook.css). --Bequw → ¢ • τ 23:38, 12 July 2009 (UTC)

Problem with arabic shadda's

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

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

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

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

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

The function in my User:Beru7/monobook.js seems to work. I don't know if it can be included in the wiki's common.js or not. Beru7 13:56, 13 July 2009 (UTC)

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

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

Got that? (:-) Now onto Arabic:

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

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

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

Ah, so I guess Arabic is bit different from Hebrew. In Hebrew, the order does matter in some cases. (Full explanation: there are a few places in the Masoretic Text, such as Lamentations 1:8, where a single consonant has two vowels underneath it. Those two vowels need to be in the right order, but Unicode specifies that the order doesn't matter, and (for example) normalizes the correct (deprecated template usage) יְרוּשָׁלִַם (y'rushaláim) into the incorrect (deprecated template usage) יְרוּשָׁלִַם (y'rushalíam). This is a bug in Unicode.) Even aside from that, the combining classes are weird for Hebrew (e.g. the vowels sort before the dagesh, even though the dagesh is actually part of the consonant), but most browsers nowadays seem to handle it O.K. —Ruakh_TALK 13:16, 13 July 2009 (UTC)

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

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

You say "solution", I say "workaround", but that does seem to work: Template:Hebr. Thanks! (Though for some reason it confuses Firefox into thinking the text is really tall, heh.) Hey, I wonder if we can get MediaWiki to handle this for us automatically? —Ruakh_TALK 14:16, 13 July 2009 (UTC)

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

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

The concept of your solution is definitely good, but I worry that replacing the innerHTML of the entire body might be problematic (e.g., likely to conflict with another script running at the same time; also, likely to take a long time on large pages on slow or low-memory computers, since it involves fully serializing and then fully deserializing the page). I wonder if it would be better, or worse, to go through the page and specifically target spans of classes Arab, ku-Arab, etc.? (Thanks to Mzajac (talk • contribs), our script templates are very consistent in using this sort of class, so aside from classed text, the only things we'd need to touch are the page's title and its H1 header.) Maybe I'm just worrying too much, though. —Ruakh_TALK 03:53, 14 July 2009 (UTC)

For what it's worth, replacing .innerHTML of the body can break event handlers that have been attached to the document dynamically (i.e. our [show] buttons), so should not be done. Iterating over all nodes with a specific class will be much easier when we get jQuery installed (which is I believe in the pipeline for MediaWiki). Conrad.Irwin 07:11, 14 July 2009 (UTC)

You are right the collapsible boxes weren't working anymore ! I modified my function (User:Beru7/monobook.js) so it only replaces text within <span class="Arab"> tags. Tell me if it needs more work - or if I should just drop it for now ! Thanks. Beru7 14:50, 14 July 2009 (UTC)

Yes, it's the Unicode defined standard workaround. As I said, I'm not blaming MediaWiki. :-)   —Ruakh_TALK 03:53, 14 July 2009 (UTC)

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

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

Ubiquity command

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

Error message from Assisted Translation

Now getting message "Could not find translation table for 'it:scitico'. Please improve glosses" when trying to use Assisted Translation system (browser = Google Chrome (don't ask!)). SemperBlotto 21:41, 12 July 2009 (UTC)

Assuming this was on Scythian, I have improved the glosses and it should now work. (I will at some point fix it to match up all translation tables taking ordering into account as well as relying on finding unique headings.) Conrad.Irwin 07:40, 13 July 2009 (UTC)

Disabling preload templates

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

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

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

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

Numbering of definitions

war#Noun and rhubarb#Noun show that definition numbering is failing with some or all being numbered 1. I haven't spent long looking for other examples - what's wrong? —Saltmarsh^{απάντηση} 05:59, 14 July 2009 (UTC)

fixdrubarb1/2;)--史凡/ʂɚ˨˩fan˧˥/shi3fan2 (歡迎光臨/Welcome! 請也用/Please also use skype: sven0921為我/since I suffer RSI!) 06:22, 14 July 2009 (UTC)

=noblank lines![i/the wikicode]:)--史凡/ʂɚ˨˩fan˧˥/shi3fan2 (歡迎光臨/Welcome! 請也用/Please also use skype: sven0921為我/since I suffer RSI!) 08:33, 14 July 2009 (UTC)

q

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

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

See (deprecated template usage) January for an example of a page where the Derived terms are hidden using {{rel-top}}, {{rel-mid}} and {{rel-bottom}}. --EncycloPetey 21:29, 14 July 2009 (UTC)

how2movesth /discussion]fromsay talkpp.2here?

--史凡/ʂɚ˨˩fan˧˥/shi3fan2 (歡迎光臨/Welcome! 請也用/Please also use skype: sven0921為我/since I suffer RSI!) 06:37, 14 July 2009 (UTC)

Edit that page, select all the text, copy, edit this page, paste it here, save, delete it from there, and save. Make sure when you paste it here you indicate where it came from, so as to allow someone to determine the citation (who said what) as required AFAICT by the GFDL. (IANAL.)​—msh210℠ 15:59, 14 July 2009 (UTC)

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

Missing categories

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

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

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

Template:see-conj

In a similar way to {{trans-see}}, I just created (deprecated template usage) mettre au monde which uses the conjugation of mettre, something like {{see-conj|mettre|lang=fr}} would be good, and would link to mettre#French. Does this already exist? If so, I can't quite think where to look for it. Mglovesfun (talk) 18:12, 15 July 2009 (UTC)

That is an improper name. Templates prefixed with "see-" should be for the Seneca language. I would expect a template named see-conj to display the inflection line of a Seneca conjunction. Why do we need a template for this? --EncycloPetey 20:28, 15 July 2009 (UTC)

Well how would you link to the conjugation of mettre? My initital instinct was

====Conjugation===
* see {{term|mettre|lang=fr}}

I was more or less anticipating that someone would correct me on this, so I tried to preempt it by suggesting a template myself, even though it can be replaced by simple text. Mglovesfun (talk) 20:34, 15 July 2009 (UTC)

I think "see (deprecated template usage) mettre" is not quite clear enough and should be something like "Conjugated forms are those of (deprecated template usage) mettre, with (deprecated template usage) au monde appended.". <half-jokingly>Perhaps we should templatify that?</half-jokingly>​—msh210℠ 22:03, 15 July 2009 (UTC)

Clear enough, yes, but it different people will end up doing different things. I'm not particularly for it as I think it can be done by hand, I just thought other people might be for it. Mglovesfun (talk) 14:27, 16 July 2009 (UTC)

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

MediaWiki:Edittools

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

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

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

Yes, but no very smooth way, since you probably wouldn't want to remove the ability to set it to something different on a given computer. (For example, if you switched it to "Arabic" to edit a certain page, you probably wouldn't want it to switch back the instant you hit the "Show preview" button.) The best/simplest approach I can think of is something like this:

var edittoolscharsubset_value = parseInt(getCookie('edittoolscharsubset'));
if(edittoolscharsubset_value == 0 || isNan(edittoolscharsubset_value))
  setCookie('edittoolscharsubset', '22');

in the case of "Hebrew". (That checks if the edittoolscharsubset cookie exists and is nonzero — 0 being the index of "Templates", which is set by default — and if not, it sets it to 22, which is the index of Hebrew.) The main problem is, every time the index of Hebrew changed, you'd have to edit Special:Mypage/monobook.js to match. And the "Templates" value would never stick. (Really, I think it's kind of a mistake that we set the cookie to 0 by default — we should leave it blank by default, and just treat blank the same as 0 — but I suppose it doesn't matter much for most purposes.)

That said, I use a completely different approach, which you might want to try; User:Ruakh/monobook.js has a bit of code that basically copies the "Misc.", "Hebrew", "Latin/Roman", "IPA", and "enPR" sections up into non-collapsed <p>s. (The relevant code is the findEdittoolsSection function, and the addOnloadHook block underneath it. It should be obvious how to customize it for whichever sections you want to copy up.)

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