Wiktionary:Grease pit

July 2010

Pop up windows

Some Wiktionary pages are now generating popup windows for me. This is irritating and probably means something is miscoded. Example: this revision of (deprecated template usage) dactyloscopie. The pop up window gives Wiktionary's base URL along with the text: "fpl-plural". Once I close the popup, the accelerated links turn from red to green, so this may have something to do with acceleration of one of the templates on the page. I have a similar problem on (deprecated template usage) pingre, though it uses different templates. --EncycloPetey 04:22, 1 July 2010 (UTC)

Additional experimentation: This seems to happen only with French inflection line templates, and not with Galician, Dutch, or Spanish. --EncycloPetey 04:36, 1 July 2010 (UTC)

Sorry, that was my fault. Now fixed. Conrad.Irwin 08:41, 1 July 2010 (UTC)

Extant, I think.​—msh210℠ (talk) 15:43, 1 July 2010 (UTC)

The problem is indeed corrected for me at this point. --EncycloPetey 04:12, 5 July 2010 (UTC)

template:quote-hansard

Please could someone adapt the English Wikipedia's w:template:cite-hansard template to a template:quote-hansard template here. It will need "passage" and "quotee" parameters adding (these should do the same as they do in {{quote-book}}, thanks. Thryduulf (talk) 11:24, 1 July 2010 (UTC)

That's [[w:template:cite hansard]].​—msh210℠ (talk) 12:17, 1 July 2010 (UTC)

I tried doing so. I haven't tested it; please let me know if there's any problem. Also let me know if any other parameters (besides the current year and house) should be made optionally numbered: this is easy, but I didn't know which are the most useful parameters. (Or, obviously, do it yourself.)​—msh210℠ (talk) 20:15, 2 July 2010 (UTC)

It looks to work. Parameters for "speaker" (the person speaking, not the speaker of the house), "debate" (the title of the debate) and "quotee" (who the speaker is quoting) would be good too. Thryduulf (talk) 13:55, 6 July 2010 (UTC)

[Insert here repetition of comment just above.]​—msh210℠ (talk) 14:07, 6 July 2010 (UTC)

Expanded translation sections

This is no longer to be found in preferences, and suddenly I cannot manage to keep my translation, conjugation and inflection sections open. They keep closing on me as though it is a default that can’t be changed. It’s very inconvenient. —Stephen 20:52, 1 July 2010 (UTC)

Click "Show translations" in the sidebar on any entry with a translations table. --Yair rand (talk) 20:56, 1 July 2010 (UTC)

I did that, but when I went on to a new entry, it was closed again. Sometimes I’m far down in a page and have to scroll all the way to the top to find the open menu, then find where I was at when I encountered the closed section problem. Sometimes I have to bob up and down, over and over, opening translations, opening conjugations, opening inflections, and so forth. What was wrong with having a preferance? I never want any sections or tables closed, I only want them always opened. This past month, beginning about June 1st and culminating with this closed-section problem, editing Wiktionary has become much, much more difficult. Random page no longer works, some of my most used templates have disappeared, and now this. There should be some way to keep them open if I want to. —Stephen 23:34, 1 July 2010 (UTC)

That's very strange. Random page works perfectly for me, and translation tables are open on all pages if "Show translations" is ever clicked for me. --Yair rand (talk) 23:56, 1 July 2010 (UTC)

Random page works for Roman languages such as English, Spanish, Romanian, and German, but not for non-Roman languages such as Russian, Armenian, Thai, or Georgian. So when you click "Show translations" one time, they remain open for you from then on? Starting today, I have to click "Show translations" on each page, and if I edit and preview, then I have to do it again, and if there are declensions, I have to open them again and again on each new page or after clicking preview. Nothing stays open for me anymore. —Stephen 00:15, 2 July 2010 (UTC)

I've restored the WT:PREF that keeps everything displayed (you may need to {{clear your cache}}) - though I'm very surprised to hear that the sidebar links are not working for you. Which browser/operating system are you on?. As for the Random Page tool, I think it has fallen victim to some toolserver configuration changes, but as I can't log in as hippietrail I'm not sure how to go about fixing it. Which templates have dissappeared? Conrad.Irwin 00:31, 2 July 2010 (UTC)

I’m using Firefox 3.6.6 in Windows XP Pro. A lot of the templates I used to set categories, such as {{bird}} or {{birds}}. I think it has to do with context versus analog or something like that, a distinction that makes no sense for me. —Stephen 01:53, 2 July 2010 (UTC)

The difference has to do with categorization vs context. Take duck for example. It is a bird, and so merits being included in Category:Birds (or one of its subcats). However, the word is not only used in ornithology, nor does it have a special meaning in ornithology. It's an everyday word which is used by normal people and ornithologists alike, with the same meaning. Contrast this to tertial, which is not a word used in everyday speech, but is generally limited to bird specialists. It's been decided that context tags should be reserved for contexts, and not for categorization. Unfortunately, we haven't come up with a great system for editors to input this type of information. An editor's first instinct is to put something right there in the def line to indicate the categorization, and yet you can't do that. You have to scroll all the way to the bottom of the entry, add the category by hand, and then scroll back up to keep working. So, in my opinion, the idea is right (reserving context tags for actual contexts), but the implementation is somewhat flawed. It's unintuitive and way too much work for editors. Also, the whole entry duck is added to the category, including the verb (which is not a bird), when only that specific definition (or at least only the Noun section) should be added. There are a number of folks working on improving the editing interface (most notably Conrad and Yair), but we have to balance this against the user interface (my interest at the moment). We need to make Wiktionary easy and intuitive to edit, but also easy and intuitive to read. -Atelaes λάλει ἐμοί 02:14, 2 July 2010 (UTC)

Yes, I thought it was something like that. It’s not the way I think, so it makes no sense to me. I can’t use logic to figure out which templates will still work and which ones won’t, so I don’t add categories or contexts anymore. The header entry itself adds a category for the part of speech and I let it go at that. —Stephen 02:21, 2 July 2010 (UTC)

Editors can add categories on the definition lines. AF will I think move them. If it doesn't, that's fine too, AFAICT (even better actually).​—msh210℠ (talk) 06:59, 2 July 2010 (UTC)

I'm having the same problems as Stephen: the visibility box on the left sidebar won't remember my preference in Opera 10.54 and Firefox 3.6.3. It works in IE 8. I have Windows 7. A couple of says ago everything was normal. --Vahagn Petrosyan 10:25, 2 July 2010 (UTC)

Could someone affected by this please type: javascript:alert(document.cookie); into the URL bar of a Wiktionary page and copy the result to here? Conrad.Irwin 10:43, 2 July 2010 (UTC)

This is what I get:

WiktPrefs=0.1-1-0-0-0-0-0-0-0-0-0-1-0-0-0-0-0-0-0-1-0-0-0-0-0-0-​0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-1-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-; edittoolscharsubset=5; preferencesEditorJs=%26more-display%3Dblock%26curlang%3Dnv; Visibility=%3Bdeclension%3B; WiktionaryPreferencesShowNav=false

—Stephen 11:04, 2 July 2010 (UTC)

I get this in Firefox:

dismissSiteNotice=2.0; WiktionaryPreferencesShowNav=true; WiktPrefs=0.1-1-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-​0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-1-0-0-; edittoolscharsubset=0; Visibility=%3Bother%20boxes%3B; preferencesEditorJs=%26labeller%3Dtrue%26more-display%3Dnone%26curlang%3Dhy; hidesnmessage=1

--Vahagn Petrosyan 10:56, 2 July 2010 (UTC)

Hmmm....you've both got the cookie which is supposed to be remembering your visibility preferences. Stephen, you should have all declension templates shown by default. Try going to film#Crimean_Tatar, and see if it starts unhidden. Then, go to the top of the entry and click the 'hide translations' button under 'Visibility', and then run that same code snippet and let us know what you get. Vahagn, you're autoshowing bother boxes......whatever the hell those are......try the same thing I gave Stephen, except the declension table on film#Crimean Tatar should be hidden for you. -Atelaes λάλει ἐμοί 13:03, 2 July 2010 (UTC)

When I went to film#Crimean Tatar, translations were hidden, declensions were open (except that only the Azeri and Tatar declensions were open...the Hungarian declensions were closed). I clicked hide declensions and this is what I got:

WiktPrefs=0.1-1-0-0-0-0-0-0-0-0-0-1-0-0-0-0-0-0-0-1-0-0-0-0-0-0-0-0-0-​0-0-0-0-0-0-0-0-0-0-0-0-1-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-; edittoolscharsubset=5; preferencesEditorJs=%26more-display%3Dblock%26curlang%3Dnv; Visibility=%3B; WiktionaryPreferencesShowNav=false

—Stephen 13:36, 2 July 2010 (UTC)

(unindenting) The Hungarian tables are coded incorrectly, and are consequently showing up as "other boxes". The visibility program appears to be recording your preferences as you go along, just as it should. I've no idea why it wouldn't be working for translations, unless perhaps you were clearing your cookies/switching browsers or something. Conrad, as the author, knows the code better, so perhaps he'll have some ideas. Sorry. -Atelaes λάλει ἐμοί 14:07, 2 July 2010 (UTC)

I'm sorry - I can't find anything. From your cookies it appears as though it's working... If I ever stumble across a windows computer I'll try it for myself. Conrad.Irwin 19:03, 4 July 2010 (UTC)

Main namespace sandbox

Is there someway that we can get a sandbox that acts like (or is in) the main namespace? Many of our templates alter behavior depending on the namespace, which makes it harder to test things. --Bequw → τ 17:49, 2 July 2010 (UTC)

This doesn't answer your question, but for many things one might want to test, it's sufficient to test on preview, which can be done on any page.​—msh210℠ (talk) 17:51, 2 July 2010 (UTC)

I'm always worried I'll hit the wrong button:) There's also Special:ExpandTemplates, but you can't share a link with that one either. Some things even condition off of preview mode? --Bequw → τ 18:08, 2 July 2010 (UTC)

Things can (and there's a discussion now in the BP that certain things should), but FWIW I haven't heard of anything that does.​—msh210℠ (talk) 18:12, 2 July 2010 (UTC)

Yeah I always add NAMESPACE stuff to templates. Preview is one way, or just use an actual entry. Or you could create iohuiewfh do some tests on it, and delete it. None of these are ideal, that's for sure. Mglovesfun (talk) 10:18, 5 July 2010 (UTC)

...or [[vnjdkbkdjeh]]  :-) .​—msh210℠ (talk) 22:48, 5 July 2010 (UTC)

What about having something like sandbox/sandbox? --Bequw → τ 22:25, 5 July 2010 (UTC)

It would show up in indexes, in the counts, AF and other bots would count it as a regular page and edit it, and probably a zillion other problems. What we need is a page that is both in the mainspace and not in the mainspace. Hmmm.... --Yair rand (talk) 22:32, 5 July 2010 (UTC)

We could have a special sandbox, which has a page-specific JS which changes the wgNameSpace variable to zero. It wouldn't get put in indeces or counts, and bots would almost certainly treat it as a non-mainspace entry, but templates might get fooled, if the variable was changed early enough in the load. -Atelaes λάλει ἐμοί 22:56, 5 July 2010 (UTC)

The templates that rely on namespace rely on {{NAMESPACE}} not wgNameSpace, I think. (Unless the former is defined in terms of the latter? I find that very hard to imagine.)​—msh210℠ (talk) 23:37, 5 July 2010 (UTC)

Template:rfconj

I can't get the l= working in the {{{lang}}} sections. Other than that, someone might want to put it in a little box, although I'm as happy with simple text as anything else. Cheers! Mglovesfun (talk) 10:16, 5 July 2010 (UTC)

Striking: I think it should be fine now. Otherwise unstrike.​—msh210℠ (talk) 22:53, 5 July 2010 (UTC)

Stable identifiers for meanings

Hi, we are currently working on converting Wiktionary to w:RDF like we did with Wikipedia in the w:DBpedia project. Nevertheless we are facing quite a challenge, which WordNet RDF also didn't yet manage to tackle (I talked to Jacco v. Ossenbruggen about it).

It is currently not possible to create good links in form of URIs to identify and link the content within a Wiktionary page. There are several word entries for different word classes and etymologies. So we can not have a unique URI. For example: http://en.wiktionary.org/wiki/bank#Noun_2 might change anytime to #Noun_3 or #Noun_1 (Stable identifiers are important, so links from outside (and also from the inside) remain valid over time).

Personally, I think it would be the best to get a unique and stable identifier for the Word sense entries. This could also improve accuracy of links from the Wikipedia space to Wiktionary (see Wiktionary link on http://en.wikipedia.org/wiki/Bank (on the bottom), it would be better (more precise), if it could be linked to Ethymology 1, Noun, Definition 1) .

Do you have any ideas how to best approach this issue? Maybe, we could make a template that keeps the order fixed or produces an html anchor. I'm quite new here. Was this topic discussed before? SebastianHellmann 13:30, 5 July 2010 (UTC)

I have no idea what you're talking about, sorry. Mglovesfun (talk) 13:37, 5 July 2010 (UTC)

I tried to improve some of what I have written above. Here is an example: If you have a sentence like "He was going to the bank" and you want to teach a computer what the meaning of "bank" is, you could help him by annotating "bank" with a link (URI). With Wikipedia this works quite well, as you could either use bank or bank. With Wiktionary it is currently not possible to create such a disambiguation as you can not link to bank Etymology#1, Noun, Meaning 1, 2 or 3. The possibility to create such links would be quite useful. SebastianHellmann 14:15, 5 July 2010 (UTC)

Since definitions can be added and removed at any time, your unique identifier would need to be a combination of two things: the ordinal index of the sense (e.g. number 2), and the entry revision number of the article in Wiktionary's history. Equinox ◑ 14:37, 5 July 2010 (UTC)

I agree, Equinox, although I believe Sebastian is not actually looking to link to a point in history but rather to a unique 'word sense identifier'. This is something which has not yet been developed for Wiktionary due to constraints in the way Mediawiki stores information, and the lack of anchors.

Does anyone know if it is possible to place an html anchor tag via a template? If we could have autoformat (for example) place a {{sense_anchor|lXXeXsX}} template at the front of each sense, where lXX = the language, e = the number of the etym, and s = the unique number of the word sense. It would be even better if we could create a table with unique word senses, each with unique identifiers of course. The table would need constant maintenance, as would the word sense anchors. - Amgine/^talk 15:51, 5 July 2010 (UTC)

It is possible to place an HTML anchor with a template, yes. That is, in fact, precisely what {{anchor}} does.​—msh210℠ (talk) 22:55, 5 July 2010 (UTC)

We would need sense anchors of the kind Amgine mentions above. (Not necessarily by number, and in fact by number might be a bad idea, since the number and order of senses can change, and why number the anchor in a way that will be confusing to later editors when the numbers are out of order? No, by some other identifier.) The problem — or a problem — with doing this is that senses often split or combine. A sense of tie, "To attach or fasten with string", was split into four distinct senses, and appropriately so. If the sense had had an identifier, what would come of it when it was split? It can be done with subidentifiers, I suppose, of the en, en-US, en-GB sort, but it's something to consider (and you'd actually need subsubidentifiers, in fact potentially infinitely many levels, in case senses are further split). And two senses are often combined (sometimes from distinct parts of speech or even distinct languages!): should the new sense have both identifiers? All that said, I think the general idea is a good one (and will aid in linking between senses and their related data such as 'nyms and translations). Note that there is already an experiment in place to do this: see {{jump}}.​—msh210℠ (talk) 17:28, 5 July 2010 (UTC)

As a matter of fact, I just brought this issue up about a month ago, in response to the needs of another one of our downstream users. Unfortunately, I did not pursue the issue properly. There are a great many reasons why we absolutely need to have a way of linking to individual senses, which I outline in the preceding section, and the more I think about it, the more I think it's a large, and yet feasible task. Senses should have gloss type identifiers, so that the definitions in bank etymology #2 might have bank#river edge, bank#sea floor gradient, etc. Each definition should have a template encapsulating or preceding its definition (preceding is probably easier) which produces some html element with the id of the gloss. For the time-being, that's all we need. First-hand users of our site would immediately have a usable feature, and downstream users and our own future projects would have a hard-coded identifier. The beautiful thing is that we already have and use a great many of these glosses already, even though you might not realize it. Any entry with a translation table or a semantic relational marker (such as synonym) should already have it, used to match up the information with its sense. So, again using the definitions at bank etymology #2, the current second sense already has the gloss "an underwater area of higher elevation, a sandbank", and the fourth sense has the gloss "incline of an aircraft", which are used in their translation tables. So, if we had a bot running through our entries and creating these gloss tags, the first thing it would do is find all such glosses, create {{senseref}} templates with those glosses, and attach them to the appropriate definitions. Conrad already has some code which is pretty good at this at User:Conrad.Irwin/parser.js. The bot would then have to look at all the definitions which subsequently lack {{senseref}} templates (I just made up that name by the way, I think it's a good one, but perhaps someone might come up with something better), and create glosses for all of them. Creating good glosses is probably an AI-complete task, but creating usable ones can be easily done with regex. The rules for doing so would be something along the lines of "take all the raw text from the beginning of the definition up to the first significant punctuation mark (comma, semicolon, period). If this produces a string, which is unique in the set of all other strings produced by the same rules for all definitions on this entry, go with it". Will such an approach produce some really stupid glosses? You bet your ass it will. However, in general, users won't really be seeing the glosses overmuch, except as the hash in their address bar. Over time, human users can sift through the plethora of glosses, and the more prominent entries will have better glosses made. However, this is a feature we need now (i.e. within the next six months), and it'll take years for human editors to produce the critical mass of glosses by hand. Now, for the longevity of such glosses. Generally, glosses will provide a fairly robust and long-lived link. Senses are quite often shuffled around, and yet their meanings are rarely changed dramatically enough that a gloss that used to work no longer works. Concerning the splitting of definitions, which does happen, the resulting supersense should generally retain the id of the old definition, and the new subsenses should be given new glosses. Oh, did I mention that we need to start using subsense organization? Well, we absofuckinglutely do, however, that's a-whole-nother issue, so please don't start debating it in this thread. Merging senses is trickier, and I don't think we want to leave legacy glosses lying around, so the merging of two senses would probably kill a gloss. So, ultimately, I think we have to recognize that we can't, and shouldn't attempt to, create links which are indefinitely stable. With sense mergings and by-hand gloss improvements, we have to recognize that these are going to change over time. However, they would provide a highly stable link, and updating the links would probably prove a manageable task. However, at least we would have links of some sort to update. As previously stated, we need a bot for this. I don't think that the code would be inordinately complex, but it would be some work to write, nonetheless. If there are any folks reading this with bot experience, a volunteer would be very sincerely appreciated. If it comes down to it, I think I'd be willing to give it a go, but my programming skills are still rather limited, and I've never run a bot before (though it's something I've been meaning to get into at some point), so it would almost certainly take me more time to get it moving than someone who's done this before. If someone with bot experience is willing to help just a little bit, perhaps just get me up to speed and provide a basic framework for going through entries, analyzing their content, and making a few edits, I'd be more than happy to do the task-specific Python coding. -Atelaes λάλει ἐμοί 20:37, 5 July 2010 (UTC)

Too Long but Did Read:) @Amgine, I don't think we need to include the etymology number in the target as the glosses aren't that similar across ety's for the same language. @Atelaes, we should definitely include the language in the target (otherwise pizza wouldn't have any unique targets). So we'd get targets like bank#en-river edge. I think sense-level linking is great, but it'll mean an increase in manual labor both upfront and in maintenance. Therefore, we should have some tools to make sure that this effort is not squandered. Ideas:

1. We shouldn't have duplicate glosses in an entry. We should check on save hopefully (or in dumps regularly) if an editor has created a duplicate gloss.
2. If we start with auto-generated glosses, then we need an efficient system for editors to clean these up. An editor should be able to edit a gloss with a JS tool (not the edit screen) in one place and have it update glosses on that page (easy?) and links from other entries (hard, we'd need an index of links, but this might be good for other things as well).
3. We should provide an easy way to use the glosses in links and when creating things like synonym lists or translations. It would be great if the editing interface allowed the user to pick from the glosses available rather than requiring the user to look them up and hand-type them in. There could be many tools here.
   1. We could have an insert link button in the edit tools dialog box that would query for the glosses of an inputted term and allow the user to select one.
   2. For English entries, we could provide an enhanced User:Conrad.Irwin/editor.js that would allow (force?) someone to choose a translation gloss from the existing set.
   3. We could have {{senseref}} display a small icon that shows the gloss of the given sense.
4. We should allow editors to start with entries that have stable senses. Other entries may require cleanup from a definition-expert before starting to use this system. We should therefore provide a tool that looks at the history of pages to see which entries get edits, but whose number of sense hasn't changed that much recently.

--Bequw → τ 01:05, 6 July 2010 (UTC)

• sigh*.....yeah, it all comes back to that, doesn't it. I will admit that such a gloss linked format would add a great deal of burden upon our already tech-burdened editors. Our editor interface is just too clunky. It works great for 'pedia, but not for us. I've been meaning to create a new graphical editing interface, along the lines of Yair rand's, but significantly more powerful and more detached from the wiki-code, along the lines of Conrad's translation adder. I've been stalling on it, as it's just been too complex a thing for my meager skills, but I'm now getting to the point where it's within my grasp. I suppose this feature might just have to wait (as so many others do) until that gets up and running. -Atelaes λάλει ἐμοί 01:37, 6 July 2010 (UTC)

RFI: Please confirm that sense = meaning/use/'sense' of a term and gloss is the explanation/definition of that 'sense'. —Saltmarsh^{απάντηση} 08:21, 6 July 2010 (UTC)

RFI²: perhaps expanding the above gloss = short unique identifier of 'sense' and definition = long/clear explanation of 'gloss'. (I'm just trying to get my head around the subject AND can these terms be put in Wiktionary:Glossary?) —Saltmarsh^{απάντηση} 08:27, 6 July 2010 (UTC)

I don't know if these terms are stable enough to merit inclusion in any glossary. As I'm using the terms here, sense is the numbered component, definition is the full description, and gloss is a shortened version, often used on the translation tables. So, if you look at the first etymology on bank, for sense #1, the "definition" is "An institution where one can place and borrow money and take care of financial affairs.", and the gloss is "institution", which can be seen on the translation table. However, I think I've been a bit sloppy. A gloss should be meaningful on its own, whereas the identifiers don't need to be. So, two senses of "bass" might have the two identifiers "fish" and "pitch", which don't really explain the two main senses of "bass", but do a great job identifying the senses. -Atelaes λάλει ἐμοί 12:56, 6 July 2010 (UTC)

I agree that it might not be the easiest task, but it seems like quite a central issue: Currently: 1. no sense linking is possible, 2. There are a lot of doublettes (like the chess definition of castle and rook , 3. Translations are either imprecise (see Turm) or will result in doublettes (repeating definitions). Some definitions also already have domain markers in place, which could be considered a pseudogloss or identifier (at bank there are senses with Template:nautical or Template:aviation (I really don't understand, why they are in curly brackets like templates and some seem to be links and others not? )). Wikipedia has pages and therefore identifiers for 3 million things, so it could be used as a sense inventory for identifiers (editors would then choose the Wikipedia article, which best sums up the meaning like w:Chess ), this is just an idea I had... Another good thing like Amgine said would be to have a lookup table, including all senses and identifiers, which is integrated into an editor interface and suggests definitions to editors. Of course, there is the trade-off between having a working solution now (maybe not an optimal one) or have a good solution later (around a year or two or the Monday after Saint Glinglin's Day). Some options for creating identifiers (please add more) are:

1. (as Atelaes suggested) take the definitions, remove stop words, filter some more things and then concatenate, check for doublettes on the same page

2. match it to Wikipedia articles (which is a more difficult task, but would somehow be comprehensive)

3. use other Wiktionary entries like Template:nautical , Template:aviation, Template:chess (also difficult, but a little bit easier imho as just the "best/most appropriate" word from the definition can be used). Actually the list of selectable entries could be narrowed down at first to have a controlled vocabulary (maybe down to two or three thousand entries (something else could be used here also)). Later this could optimize the lookup table.

4. ???

We (Christian and I ) could also chip in some of our time to create nice identifiers (it is an interesting problem). Depending on the programming language the bots that run here could make HTTP request to a web service, we provide, for identifiers (or that we implemented and it's running on the tool server or so) BTW: Correct me if I'm wrong, but synonyms might also be generated automatically by {{senseref}} and then in the long run also the translations table. SebastianHellmann 10:49, 7 July 2010 (UTC)

I feel fairly confident that my approach is the best one (I've been thinking about this problem for some time). The problem with #2 is that Wikipedia and Wiktionary have vastly different selection processes for articles/entries. Their articles would not line up one to one with our entries at all. When they do line up we often include a link to the appropriate article, but we certainly can't rely on them for indexing our content. The words you're seeing at the beginning of some definitions are context tags. They identify a certain context (such as a register (slang) or discipline (medicine)) in which a sense is used or used differently from other senses. Some of them could probably serve as useful identifiers in entries in which they only occur once. For example, I think that nautical is a reasonable identifier, but slang probably isn't. However, they sometimes occur on multiple senses, in which case they wouldn't work as identifiers. In any case, we can't rely on them for our identifiers. As I think about it, Bequw's reservation about creating additional work on editors is a valid point, but I realize now it doesn't really throw the whole program, as we could have a single bot sweep, and then perhaps additional sweeps periodically. Even if editors never add identifiers on their new creations, we would probably hit most of the important English words (which already exist now), which are what most desperately need the identifiers. When we get a better editing interface up and running, it could automate the addition of identifiers, and so future bot sweeps would be unnecessary. So, a few things remain. We need to iron out the technical details of the implementation. I think I've laid down a fairly concrete proposal, so if anyone has any ideas why it wouldn't work they should point them out. I'll try to create {{senseid}} (which I think is better than "senseref"), and perhaps place it on a page so people can see it in action. Additionally, we would have to get wider community feedback and, ultimately, consensus to proceed, as with all major changes to the site. Finally, and perhaps most problematic, we need a bot. As I stated earlier, I have zero experience with running a bot, and so it would take me awhile to get it going. As I also stated earlier, if anyone with bot experience is willing to work with me, I'd definitely be willing to help with the code. I propose we leave this topic stew here for another week or so, and make sure we get technical details ironed out, and then propose it to the wider community at the BP. -Atelaes λάλει ἐμοί 13:27, 7 July 2010 (UTC)

Sounds good. Also it would be great to have a cleanup list of places where we still have numbered sense glosses in use. --Bequw → τ 16:16, 7 July 2010 (UTC)

An image caption seems to be the most common offender I've seen lately.​—msh210℠ (talk) 16:26, 7 July 2010 (UTC)

@Atelaes: Yes, I think your way is how it should be. I was just wondering, if there will be identifiers or glosses in the end. In case it will be identifiers they could just be cryptic like bank#en-e1-n1 . They will be generated automatically once and after that move along with the definition (hardly any additional burdens for editors, they just have to watch that the identifier stays with the entry after the #). In case it will be glosses, the creation and maintenance task gets more difficult, that is all I'm saying. So there is the trade-off: the smarter the identifiers, the more work it takes(for editors as well as code-wise). Is there a place (maybe an extra page) to make a collection of what can be achieved easily and what seems more difficult. We could then prototypically implement it and test it on these. Also we should just start to design some templates (BTW Is there a template sandbox somewhere or can I just use any template page to try Template:shMyTemplateExperiment ). I think, the bot would have to be run on a separate server and it needs to be something else than javaScript. I have written a bot for MetaWiki in java, the code could be exploited, or maybe piggyback it on Autoformat (which is python) ? All in all, I'm really not sure what would be the best solution, as I need more info, some experimental results (just to see, if acceptable glosses can be produced by simple means). Also lots of criteria to consider (additional work for editors / maintenance / initial creation / easily parseable by downstream users), maybe we can break it down somewhere? SebastianHellmann 16:35, 8 July 2010 (UTC)

Another problem with "meaningful" identifiers (glosses) is that well-meaning but ignorant (of what the identifiers are for) editors may change them ("no, a better gloss would be...").​—msh210℠ (talk) 17:27, 8 July 2010 (UTC)

+1 or they could gloss a def "dont care something something" if forced to enter one, but the gloss isn't shown on the page. Maybe there could be both an identifier giving identity and a gloss as kind of a short definition label, which can be displayed to users SebastianHellmann 18:11, 8 July 2010 (UTC)

Well, there certainly must be a gloss (and it must be human-readable and sensible): we need it for a visual connection between a sense and its related data (translations, etc.). The identifier, even if gloss-like, would have to be different from it, so that it can be constant while the gloss can be bettered at will.​—msh210℠ (talk) 18:20, 8 July 2010 (UTC)

So we need:

• A template to add a gloss anchor for the definition line, preferably with as short a name as possible. (I would suggest a single letter, but the only 1-letter template names left are e, h, j, k, o, r, u, v, x, y, and z, and none of those can really stand for "gloss" or any variation afaik.) Something of the format like {{_templatename_|en|river edge}} producing a #English-river edge anchor would be best IMO, as it makes it clearer what the beginning stuff is for.
• A way to link to specific senses. My preference would be just adding an extra parameter to {{l}} and similar templates, rather than creating a whole new template or linking directly.
• Something to clearly indicate which sense was being linked to other than just scrolling the page would be useful. Maybe something like how the ref tags highlight the linked-to area. Doesn't sound like it would be too difficult.
• Some way to tell on-sight whether the linked-to sense exists as well as an equivalent of whatlinkshere for senses would be helpful, though not completely necessary.
• A bot to add glosses to senses that don't have them. IMO this should not be run until all the other components are ready and have been in use in some entries for a while.

So, I think we should start this off somewhat slowly, adding gloss templates to a few pages and linking to them before trying to mass-produce glosses for all entries in Wiktionary. --Yair rand (talk) 22:41, 11 July 2010 (UTC)

Along the lines Bequw has pointed out, we need to harness the energy of human editors to bring up the rear. As he mentioned we have translation tables which refer to numbered senses. It is a tedious project to determine whether the translations correspond to the current senses. We might also want to check on whether the glosses used in synonyms match those used for translations. That might lead to improvement of glosses in entries deemed worthy of both translations and synonyms, which may be more important words. That should improve the effectiveness of any senseid-creating effort. We also have many entries that have no translations or synonyms sections. If they do not have one-word definitions, they are candidates for improvement by the addition of trans tables with glosses.

Finally, the question arises: should entries or sections or senses within entries be marked up as worthy of translation and other effort and reliance by our users, both wholesale and retail? DCDuring TALK 23:31, 11 July 2010 (UTC)

After I've read through the whole discussion, I think Yair rand pointed out the most important steps that needs to be done. To ensure that everyone is talking about the same thing, I've experimented how this could be look like in the end, see boat#poker. This could also serve as a basis for further discussion. -- ChristianMeyer 20:18, 12 July 2010 (UTC)

Using {{sense}} instead of {{poker}} leads to the entry not being put into Category:Poker, not the result we want. DCDuring TALK 20:54, 12 July 2010 (UTC)

I was thinking that the definition gloss could be invisible, as it doesn't really help the readers. (A pref to make it visible might be useful for editors, though.) Also, highlighting sections other than the def line doesn't seem like it would be helpful. The yellow coloring seems a little bright, I think we'd be better off using something along the lines of the Wikipedia reference color, or maybe an outline. --Yair rand (talk) 21:05, 12 July 2010 (UTC)

Stable identifiers for meanings — AEL 1

(unindenting) I'm going to use the term "id" instead of gloss, as I think this will clarify our discussion a bit. Ultimately, I think that id and gloss are two different things. A gloss is used when the editor assumes that the reader is unlikely to know what the word means and shouldn't have to look it up. The id is used to differentiate different senses of a word. They might sometimes be the same, but they serve different purposes, and thus will sometimes be different. I agree with Yair that the id should not show up for the reader (but might indeed be useful for editors). Also, the yellow is a bit much. The light blue would be an improvement. It wouldn't be too difficult to have a little javascript which reads the hash and, if it corresponds to a definition, highlights the appropriate def. Also, the id is different from the context. As I said earlier, we might sometimes simply use the context for the id, but not always. In any case, the id should be invisible, but the context should not. So, the code running before the second definition of boat should run something like # {{senseid|poker}}{{poker}}. I don't think we can hijack {{sense}}, as it's a template which already exists and has a specific function, which we don't want to alter. -Atelaes λάλει ἐμοί 21:36, 12 July 2010 (UTC)

Any objections to using {{x}}/x= as the standard for codes relating to sense identifiers, or whatever you want to call it? (No particular reason for x, other than that it's unused, afaik.) --Yair rand (talk) 21:42, 12 July 2010 (UTC)

Well, I've written {{senseid}}. You can see it in use at User:ChristianMeyer/TestBoat#en-poker. I'm not dead opposed to using the one-letter templates, but I think they'll be utterly confusing....to everyone. I recognize the convenience factor with only using one character, instead of seven, but, quite frankly, I don't think anyone will do this by hand. We really will have to automate this. I'll start working on some highlighting JS. -Atelaes λάλει ἐμοί 21:47, 12 July 2010 (UTC)

I'm more worried about having to type out "senseid=" with every use of a link template or anything else that might be related to these, rather than just x=. Full language names would be more helpful than just the code in the anchor, IMO (and, unless I'm mistaken, would also make it work better with tabbedlanguages, no?). Also, I think it would be better if the template didn't include < /span>, as MW closes open spans at the end of the line, which would make highlighting the definition simpler, I think. --Yair rand (talk) 21:56, 12 July 2010 (UTC)

Well, you wouldn't have to type out senseid when linking to a def. You just put it in the hash. For templates like {{term}} and the like, we'd probably name the parameter "id" or "def" or something. You might have a point with using the full language name instead of the language code. It would indeed be easier to code that into tabbed languages. Letting MW close the span is also a good idea. I'll start working the changes in. -Atelaes λάλει ἐμοί 22:02, 12 July 2010 (UTC)

Link is now User:ChristianMeyer/TestBoat#English-poker. -Atelaes λάλει ἐμοί 22:35, 12 July 2010 (UTC)

Also, User:Atelaes/highlightSense.js is now written. It's just a concept script at the moment, and would certainly need some work before it gets pushed anywhere remotely public, but it appears to work. -Atelaes λάλει ἐμοί 22:42, 12 July 2010 (UTC)

Sounds good. I agree that the yellow is kind of heavy, I just wanted to start something visible. To sum up, there are two "things" for a word sense (i.e. a meaning of a word): (i) the gloss, which is the definition text of the word sense, and (ii) the sense id, which is a short form of the gloss and the word's language. The latter is unique for each article page and defined using the new senseid template. The sense id is used for the association of translations, synonyms, etc. entries using the sense or trans-top template (no changes needed here, just some cleanup). The sense id also allows to link a certain word sense, which will then be highlighted using a JS file. The sense id should remain stable as long as possible - surviving reordering, reformulation, and splitting to subsenses. Unless I've forget something there are three steps pending by now:

1. Try the new system in practice for a couple of entries (manually).
2. Explain the new system/template in the help pages.
3. Come up with an automatic method to generate senseid templates (this is of course the hardest part).

I guess it's necessary to gather more details on the third step, there are some ideas around, but IMO not operationalized enough to implement it directly. ChristianMeyer 08:11, 13 July 2010 (UTC)

@Atelaes, If the id and gloss are different, where do we use each? The id, I imagine, would be used whenever we link to the term from other entries. Wouldn't the id also be used inside the entry to allow jumping back to the definition (like {{jump}})? When would we use a gloss? --Bequw → τ 13:02, 13 July 2010 (UTC)

Gloss would be in {{sense}} tags at the start of 'nyms lines, in translation-table headers, etc. Even with the feature of jumping to the appropriate section, we will still want visual identification of which sense has which other data ('nyms, etc.).​—msh210℠ (talk) 15:42, 13 July 2010 (UTC)

That's the problem. If we want to allow jumping directly to the definition, then we'll need the id in {{sense}}/{{trans-top}} meaning we'd have both id and gloss as parameters. This seems like overkill. --Bequw → τ 17:47, 13 July 2010 (UTC)

Not to me. Note that sometimes an adjective sense and an adverb sense, or an adjective sense and a noun sense, have the same gloss. (I can't think of any offhand, but I have seen them.) So I really do think we need both.​—msh210℠ (talk) 17:59, 13 July 2010 (UTC)

Perhaps I should note that msh210 and I are defining our terms rather differently here. I would consider the identifying information which is present in translation tables and synonyms as id's, not glosses. The place where I most often see glosses used are in etymology sections. As an example, let's assume that the English word trek comes from Ancient Greek (deprecated template usage) τρέχω (trékhō) (it doesn't, actually it's from Afrikaans). Let's also assume that Ancient Greek (deprecated template usage) τρέχω (trékhō) has most of the same senses that Greek (deprecated template usage) τρέχω (trécho) does, and they simply aren't noted (this is probably a correct assumption). In the etymology, I would probably write "from Ancient Greek (deprecated template usage) τρέχω (trékhō)". I'm assuming that most folks aren't going to know what (deprecated template usage) τρέχω (trékhō) means, and so I put down a very brief general description of it. "Run" works perfectly in this case, as it sums of most of the important definitions, and allows the reader of the etymology to grasp the semantic connection between the Ancient Greek and English word. However, "run", as most of you can probably guess, would make an absolutely horrid id, because all the definitions mean "run". Thus, in my opinion, a gloss sums up definitions as best it can, and an id differentiates them. -Atelaes λάλει ἐμοί 23:40, 13 July 2010 (UTC)

Then there are three distinct thingamabobs attached, or to be attached, to each definition: a gloss for use in etymologies or the like ("run", or something more specific as needed), a human-readable thing to differentiate the senses (which I've been calling "gloss" also, and which appears in translation-table headers), and a machine-readable thing ("ID", for use in {{senseid}}). I don't think we have any fundamental difference of opinion about this, Atelaes, but maybe I'm wrong.​—msh210℠ (talk) 16:34, 14 July 2010 (UTC)

? Why would the human-readable identifier need to be different from the machine-readable identifier? --Yair rand (talk) 20:58, 14 July 2010 (UTC)

Because the intent is that the machine-readable identifier be stable (i.e., that they never change), and that the human-readable identifier be part of the interface, helping users to match onyms and translations to definitions, which requires them to change when definitions do. —Ruakh_TALK 21:16, 14 July 2010 (UTC)

I extended {{senseid}} with some imho necessary features (see {{testingx}}). 1. the link has to be shown somehow to mouseover, right-click and copy, so you can post the link somewhere else. 2. the part after the hash is an id now and additionally a gloss can be given. 3. context is included into the template, so there needs to be only one usage. See the templates here User:ChristianMeyer/TestBoat#en-craft, User:ChristianMeyer/TestBoat#en-fullhouse, User:ChristianMeyer/TestBoat#en-cychex. Note that each definition is twice on the page now, I just renamed the ids to differentiate them to the second section while the glosses actually would overlap. User:Atelaes/highlightSense.js works already, but not dynamic, so if you click on some of the sense links the script will not redraw highlighting. SebastianHellmann 09:21, 15 July 2010 (UTC)

I FWIW do not like those line-initial links. The purpose for their existence (that they link to the sense itself not elsewhere) and the intent of their wording are both not clear to the reader. I think that, if it's desired that we have a thing on each definition line that will allow a user to copy the direct URL (which I do not consider a priority, but can see the benefit of), then we should have a small symbol that users will recognize from other Web sites which provides that. For example, Google Maps uses a thing that looks like links in a chain.​—msh210℠ (talk) 16:07, 15 July 2010 (UTC)

yeah, I tried to just let the standard Wikipedia symbol appear, but it doesn't come standalone... I corrected the link and put an @ there. Left blank, it will show numbers [1]. It might be possible to only show the image. Anyhow, the {{senseid}} or {{testingx}} seem the right place to define the id AND the gloss. It is yet unclear, how the gloss can be reused directly (technically), as e.g. in translation tables. Ideally, you would define everything once in a template and then just use the id later, JavaScript or MediaWiki would do the rest. (side node: one solution would also be to create a namespace just for definitions and then make one page per definition and include them in mainspace) SebastianHellmann 19:38, 15 July 2010 (UTC)

+Idea: A button to the left of each definition that opens a dropdown menu with things like "Link to this definition", "What links here", and a whole bunch of editing tools that'll probably be a lot easier to make once we have id's for each sense ("add synonym", "add example sentence", etc.). Side note: I really don't think it makes sense to have human-readable identifiers and computer-readable identifiers separate. --Yair rand (talk) 19:48, 15 July 2010 (UTC)

Whatlinkshere sounds very difficult. But I'm no programmer. Human-readable identifiers are needed in our translation tables and 'nyms lists as currently configured. (Do you disagree with that part, Yair, or with the following?) They'll be visible and should be "good" (a good English summary of the definition, as opposed to the machine-readable identifier which need not be a good summary at all but need only be unique: it can be k2wh4dt), and having them stable means they can't be improved.​—msh210℠ (talk) 20:04, 15 July 2010 (UTC)

I don't understand why we can't use human-readable identifiers (what's currently used in trans tables and 'nym lists) for everything and still allow them to be modifiable. As for Whatlinkshere, maybe we could have link templates include invisible redlinks so that the regular whatlinkshere page could be used? --Yair rand (talk) 21:25, 15 July 2010 (UTC)

human-readable goes along with improvable and correctable and loses the property stable. Let's say I link to User:ChristianMeyer/TestBoat#en-cycohexane_rings. If cycohexane_rings is the human readable as well as the computer-readable identifier then there will be a big problem. The choice then is to improve the spelling to User:ChristianMeyer/TestBoat#en-cyclohexane_rings resulting in thousands of updates (on Wiktionary, Wikipedia and external sites) or live with the bad spelling. So it's better to have one like User:ChristianMeyer/TestBoat#en-cycohexane (maybe one word) and the human-readable gloss can be changed at will to "cyclohexane" , "cyclohexane rings" or "cyclohexane rings (chemistry)" SebastianHellmann 05:42, 16 July 2010 (UTC)

(unindent) Glosses are changed extremely infrequently, and with tools to let people know which links need fixing, I think it could be easily manageable. Having machine-readable and human-readable glosses separate would make adding links more difficult by not having the relevant gloss visible. It would also make page sources far more confusing, the system far more difficult to understand, and a huge amount of confusion about the purpose of senseids. It really doesn't seem like it would make sense to have them separate. --Yair rand (talk) 20:47, 18 July 2010 (UTC)

I agree with Yair, if it's too cumbersome, editors won't use it. Let's come up with guidelines for human-readable glosses so that they are more likely to be stable and unique. --Bequw → τ 01:23, 19 July 2010 (UTC)

I also agree with Yair. We can write programs to check what id's are being changed, and publish it for any interested parties to use in changing their links. Ultimately, expected anything on Wiktionary to be reliable into infinity is unreasonable, and, quite frankly, is not something we want to promise. I rather doubt that these id's would be changed all that frequently anyway. -Atelaes λάλει ἐμοί 03:52, 19 July 2010 (UTC)

I guess this will also work in the long run (lot's of changes at first, after a year or two there will be stable links, a change log would be necessary though, later). As for the guidelines, I think there might be some characters, that can not be used for technical reasons, such as #?& and also whitespace. I'm going to have a look into parser functions, if a workaround is possible. If the guidelines are fixed, will there be an automatic swoop over the whole wiktionary to create initial glossids? We could use some NLP tools, for this. SebastianHellmann 06:33, 19 July 2010 (UTC)

Perhaps AF, in its reading recentchanges, can undo, or (probably better) least mark for attention, any change to a gloss in an anchor ({{senseid}}, or whatever) tag? (Not addition of a new gloss, but change to an existing one, which people may undertake not realizing the havoc it can wreak.)​—msh210℠ (talk) 15:42, 13 July 2010 (UTC)

Needless to say, you'd have to ask Robert about that; but from what I understand, AF isn't designed with the assumption that it will see all changes. Rather, it tries to follow changes, but it also checks the dumps. (And even when it does see a change, it doesn't seem to have any concept of "what's changed?", only of "is there anything for me to do now?"; but I'm guessing that's an easier limitation to overcome.) —Ruakh_TALK 17:10, 14 July 2010 (UTC)

I just read this - some of you probably still know me, I was quite active within the Wikimedia Foundation. One of the reasons I did not go ahead working on Wiktionaries was: you can get data in, but you cannot get it (easily) out. For the langauges we deal with, that is mainly less resourced ones, it simply did not make sense, there's not enough workforce to do things multiple times. And as much as I love wikis: I had to choose where to invest my time best. Now if we get this going our projects, like the creation of terminology for ABC-Books, lists of "learner's terminology" for educational material and some collections of technical terminology could be maintained here. Wouldn't it make much more sense to co-operate by having people edit here and us being able to use the data provided through dbpedia? I believe yes, it would be a great win-win situation. Let's go for it ... --SabineCretella 16:19, 30 August 2010 (UTC)

Hotcat display tweak request

Would it be possible to reduce the size of the hotcat controls in teh category display (the (+)(±) etc) - perhaps make them superscript or a smaller font size, as they take up a significant amount of room and are distracting from the prominence of the actual categories. Thryduulf (talk) 09:28, 7 July 2010 (UTC)

Sounds easy in theory. Just get it to add a <span class="Hotcat"> or some such around them and then you could shrink it in your monobook.css. This lets any users with bad eyesight to keep it as it is. I would do that if I knew JS... Maybe ask at commons:MediaWiki talk:Gadget-HotCat.js. —Internoob (Disc•Cont) 19:53, 10 July 2010 (UTC)

Good idea, see commons:MediaWiki talk:Gadget-HotCat.js#Request: smaller (+) (-) etc links. Thryduulf (talk) 22:34, 10 July 2010 (UTC)

Lupo has kindly enabled this. His comments at the Commons page are copeid below:

The class name is "hotcatlink" and is applied to the span encapsulating all the links. To reduce the link size, you can use the following CSS:

.hotcatlink {
  font-size: 80%; /* Or some other value */
}

Thryduulf (talk) 17:16, 12 July 2010 (UTC)

Actually this doesn't having an effect. Does the local copy of hotcat need updating to include this? Thryduulf (talk) 17:20, 12 July 2010 (UTC)

Yes. —Internoob (Disc•Cont) 17:28, 12 July 2010 (UTC)

 Done. —Internoob (Disc•Cont) 17:35, 12 July 2010 (UTC)

Excellent, thank you. Thryduulf (talk) 19:00, 12 July 2010 (UTC)

String processing in templates

Can wiki templates do string processing? e.g. Remove the last character of the headword (and add another) (See template talk:io-noun for such a request). SemperBlotto 15:33, 7 July 2010 (UTC)

Short answer: Sorry, no. (Longer answer: There's an extension that adds parser-functions that could do this, but it's not installed, and likely never will be. Even without the extension, Wikipedia has some ugly hacked-up stuff that does this sort of thing, and that currently happens to work, but it is not worth it.) —Ruakh_TALK 15:39, 7 July 2010 (UTC)

Template {{io-verb}} seems to use this sort of logic. Is that OK to copy? (Not that I have the time, or inclination to fight through all the brackets!) SemperBlotto 15:54, 7 July 2010 (UTC)

Specifically, it uses the ugly hacked-up stuff Ruakh mentioned: {{str len}}, a direct copy (seemingly without attribution? copyvio?) of the enWP template of the same name: see the latter's page for warnings.​—msh210℠ (talk) 16:01, 7 July 2010 (UTC)

So sad. Yair, if you're reading this page, consider yourself very glared at. Fortunately, we can easily revert his changes to {{io-verb}}, {{eo-verb}}, and {{eo-conj}}, and use AWB or a bot to fix any entries that need to be fixed. —Ruakh_TALK 18:26, 7 July 2010 (UTC)

Sorry, I didn't know there was a problem. str len is too heavy to be usable? --Yair rand (talk) 01:33, 8 July 2010 (UTC)

I don't know if it's too heavy to be at-all usable, but I definitely think it's too heavy, and messy, to be worth using. At least for something like this. (From what I understand, all of the template calls get evaluated only when a page changes; so we don't want tons and tons of pages using {{str len}}, because then someone adds {{documentation}} to [[Template:term]] and suddenly all of those pages get reevaluated, but it might be O.K. to use {{str len}} in a small number of pages.) That said, if you feel strongly that the template should work without editors having to add the stem as a parameter, then we can create a bot that will add it (so that, at any given time, only a small number of pages will be missing the stem parameter), and we can code the template in such a way as to do all these evaluations only if the parameter is missing. (Even then, I imagine we'd want to use a subtemplate that receives the stem as a parameter, and an outer wrapper template that just computes the stem if necessary and passes it to the subtemplate: otherwise something like {{eo-conj}} involves fifty gazillion {{str len}} invocations.) —Ruakh_TALK 01:59, 9 July 2010 (UTC)

Fiddling with right hand TOC

I've removed the "display" parameter on the right hand TOC code. The problem with it is that it makes right-handed TOC's unhideable. For example, I've got the TOC hidden by default, but showable with the Visibility toolbox on the left, on my tabbed language script. However, this doesn't work if the right-hand TOC gadget is enabled. I do occasionally like to see the table of contents, but when I see it I like it to be on the right. As far as I can tell, removing this parameter shouldn't affect the table of contents at all. Then again, as far as I can tell, including it should break the TOC, which it clearly doesn't, so it's possible I'm missing something. If anyone starts having problems with their TOC's please note so here or just revert the changes I've made to MediaWiki:Gadget-WiktPreviewRightTOCs.css. However, if you do revert, it would be greatly appreciated if you could note here why you did it, i.e. what was going wrong, and what your browser is, so that perhaps we could work towards a solution which preserves a working right-hand TOC while making it hideable. Many thanks all. -Atelaes λάλει ἐμοί 01:18, 8 July 2010 (UTC)

ISO templates in etymologies

User Leasnam have been adding bare ISO templates like {{da}} into the text of etymologies, where they should not be used. Could someone with a suitable bot please correct all of these? It wouls take to long to search tham down and correct by hand. --EncycloPetey 21:52, 8 July 2010 (UTC)

What should they be fixed to? ({{etyl|da}}? {{etyl|da|langcode}}? {{etyl|da|-}}? {{da|subst=subst:}}? Or does it vary?) —Ruakh_TALK 22:22, 8 July 2010 (UTC)

I don't know. It may vary. I've no idea how long the problem has been going on, but just spotted another user doing the same thing. --EncycloPetey 22:34, 8 July 2010 (UTC)

From what I've seen we should be safe replacing them all with {{etyl|xx|-}}, as long as the search is confined to etymology sections. Nadando 22:55, 8 July 2010 (UTC)

Perhaps, but I've now seen edits where they've been used in "Etymology 1" sections and in "Descendants" sections. We may need Robert to create another automatically generated cleanup page. --EncycloPetey 22:57, 8 July 2010 (UTC)

This also seems like a good candidate for Autoformat, if you aren't in a hurry to get these fixed. Nadando 23:07, 8 July 2010 (UTC)

Preventing {{infl}} from linking

Currently, {{infl}} automatically creates a page link from every other parameter. However, I'm wondering if I can prevent this behaviour, so that it shows a parameter in bold but without a link (this is useful for periphrastic constructions). Is this possible? —CodeCat 10:18, 9 July 2010 (UTC)

Yes, it's possible. Before linkifying and applying the script template, {{infl}} does a bit of a test to see if the parameter is a valid page-name; if not, then it just outputs the parameter without modifying it. So something like {{infl|en|foo|bar|{{Latn|baz|lang=en|face=bold}}}} is equivalent to {{infl|en|foo|bar|baz}}, just without the link to [[baz#English]]. And if you don't care about the script template and the XHTML lang= and xml:lang= attributes, you can do the slightly-simpler {{infl|en|foo|bar|<nowiki/>'''baz'''}}.
That said, if there's a specific language and POS you have in mind that will always require this, then I think it's better to create a dedicated inflection template for it.
—Ruakh_TALK 12:06, 9 July 2010 (UTC)

Well actually, I was thinking the Dutch inflection line templates could be changed so that they simply include {{infl}} with the proper parameters. That way there's less duplication of code, and only one template needs to be changed if we decide to ever change the entry format. But {{nl-adj}} has a special 'peri' setting that shows a periphrastic phrase for the comparative/superlative, as in English. —CodeCat 14:29, 9 July 2010 (UTC)

I see. That's a good idea, and it's doable; but I'm not sure whether the end result is really worth it, since {{nl-adj}} would still have to handle the various special cases (predicative-only, non-comparable, multiple comparatives, etc.). Either you'd need several calls to {{infl}}, with a switch or series of if's to control which call ends up being displayed, or you'd need to test some of these parameters several times (because they affect multiple separate parameters; -, for example, affects the label for the comparative, the comparative itself, the label for the superlative, and the superlative itself). And either way, you could end up with a situation whereby changes to {{infl}} require changes to {{nl-adj}} as well, obviating the effort. —Ruakh_TALK 17:05, 9 July 2010 (UTC)

Teaching your script all about languages

I've been meaning to add a category sorting feature to my tabbed languages script, but I realize that, in order to do so, the script has to be able to translate language names into language codes. Conrad solved this in his editor script with a JSON object/value ordered array/whatever containing all , but the thing's pretty damned huge. Also, Conrad's does language code to language, which would be rather inefficient going the other way, so I'd have to write my own from scratch. If that's the only way, then it's the only way, but I was wondering if anyone had any ideas on a more lightweight implementation. Thanks. -Atelaes λάλει ἐμοί 02:10, 10 July 2010 (UTC)

Do you mean that his script uses an associative array (JavaScript type Object) mapping from language-codes to language-names? (Note that var foo = { bar: 'baz', bip: 'qux' }; is just a special notation for initializing an object.) If so, it's pretty simple to write a function that reverses the associations:

function reverse_associative_array(o)
{
    var ret = new Object();
    for(var key in o)
        ret[o[key]] = key;
    return ret;
}
var langnames2codes = reverse_associative_array(langcodes2names);

Does that answer your question? —Ruakh_TALK 13:51, 10 July 2010 (UTC)

Well, I was actually wondering if anyone had any ideas on how such a thing could be done without an associative array containing every language. -Atelaes λάλει ἐμοί 13:58, 10 July 2010 (UTC)

So what you need is, in any given entry, to form associations between L2 headers (which contain language names) and corresponding categories (some of which use language-code prefixes)? In the general case, there's nothing in our entries' generated HTML that you could use. Some inflection templates wrap inflected forms in spans with class lang-xx (used by Conrad's form-of creator), but you can't rely on that. If you don't want to use a pre-built associative array, I think you'd have to use AJAX. (But if you're worried about the size of the associative array, you could split the difference by pre-loading a rather small array consisting only of languages with a fair number of entries shared with other non-English languages; then you can fall back on AJAX when you encounter a language that's not in that array. Heck, if you want to go all-out in supporting many code-paths, you can have an intermediate check where you look for the aforementioned spans.) —Ruakh_TALK 15:08, 10 July 2010 (UTC)

Actually, on second thought — we really should be more consistent about tagging things with lang= and xml:lang=. If you can make that happen, you'd be able to grab the language-code off of headwords. —Ruakh_TALK 22:14, 10 July 2010 (UTC)

Yes, I had thought about including only a small (perhaps 150 languages) object initially, and then having the script import something more comprehensive as needed. My concern was that, long-term, it would end up taking just as much cache space for our editors (who presumably will stumble upon one of the less common languages at some point in their journeys). However, it would probably take up less for casual viewers, and would at least break up the loading, so having tabbed languages turned on wouldn't mean downloading all languages upon every cache refresh. It might also speed things up a bit, as most of the checks would be done with the smaller object. I had considered looking at the entry itself for evidence of the code, but as you've said, it's just too inconsistent and unreliable. Yes, there are a number of things wrong with the html output of our entries, which is something I hope to address eventually, but now is not the time (for me, at least; I certainly wouldn't stand in the way of anyone else attempting to do so). Thanks for the thoughts. -Atelaes λάλει ἐμοί 22:54, 10 July 2010 (UTC)

Just incidentally, re Ruakh's "should be more consistent about tagging things with lang= and xml:lang=": If we tag something with <span lang="...">, the MW software will add xml:lang. We needn't.​—msh210℠ (talk) 18:31, 12 July 2010 (UTC)

? Why does category sorting require translating language names into language codes? Are there any kinds of entries that don't have the language name as the first part of the first non-derivations category? Can't it just sort them based off of that? --Yair rand (talk) 03:18, 11 July 2010 (UTC)

Most entries should have at least one category with the full language name (the POS cat), but it's not necessarily the first or the last. Take cure (which I've been using as my easy test case for tabbed languages) for example. The French section does indeed have a category starting with "French", namely "French nouns". However, it's first cat is "fr:Latin derivations", and its last is "fr:Religion". If the script did not know that "fr" = "French", it would not sort those properly. -Atelaes λάλει ἐμοί 03:56, 11 July 2010 (UTC)

It's always the first after derivations cats, I think. cure is correctly sorted by this (though I imagine for a working implementation you'd want to pull the categories off of the contents of the catlinks box rather than wgCategories). --Yair rand (talk) 04:22, 11 July 2010 (UTC)

I'm struggling to think of a counter example.....I know there must be one, but it's not coming to me. cure is indeed properly sorted by your deceptively simple script. I'll go ahead and just drop your code into mine, until such time as I find a page which it doesn't work on (or, as is more likely, you find a page it doesn't work on). It's about as lightweight as possible, which I really like. -Atelaes λάλει ἐμοί 05:09, 11 July 2010 (UTC)

Code's in place. I still feel like the code is too simple, and it'll blow up in someone's face, but here's hoping. Let me know if any bugs show up. Also, it breaks rather spectacularly if a language section is missing its POS cat. As tabbed languages is currently only available from WT:PREFS, and thus, in my opinion, only available to editors, I see this as a benefit, not a problem. Any language sections which don't have their POS cats need them, and this provides a not-so-subtle reminder to fix them (see the history of in, where I was not-so-gently alerted to the fact that a number of the sections were missing their cats). If anyone decides to push this site-wide, we'll have to fix it. -Atelaes λάλει ἐμοί 07:53, 11 July 2010 (UTC)

English context category's are often misplaced at the end of the page rather than the end of the section (see house). This should be cleaned up anyways. I thought AF did this, but can anyone make a cleanup? --Bequw → τ 21:27, 12 July 2010 (UTC)

Hm, there is a format of page where it doesn't work. Where there are multiple etymologies in the same language with the same part of speech where the last etymology has a previously unused derivations category and no further topic or pos categories after it, the script will not work. See ballyhoo. I have no idea how it could be fixed (not counting changing ELE so that etymologies go under pos headers, as it doesn't look like that's going to happen anytime soon). --Yair rand (talk) 21:13, 13 July 2010 (UTC)

Did I call that or what? I'll start working on a code --> language name converter shortly. I already have some of the workings set up. -Atelaes λάλει ἐμοί 23:26, 13 July 2010 (UTC)

Introducing colour.css

This is my idea to add more colour to Wiktionary entries. Tell me what you think of it. —Internoob (Disc•Cont) 21:15, 10 July 2010 (UTC)

oppose unless it is renamed to color.css.
Jokes aside, I think all those images and colors that other Wiktionaries use look terrible. We at least look like a good and reliable dictionary, the sister projects look more like personal "I'm bored and want to make my own web page" projects. -- Prince Kassad 21:45, 10 July 2010 (UTC)

I agree with Prince Kassad on this. Artistic use of color has some value. Google's clever use of changing color images on the search page is an outstanding example. But most of Google's presentation is "boring". In contrast I strongly favor the use of color drawings, photos, and, perhaps, simple animations to improve wiktionary content. DCDuring TALK 22:00, 10 July 2010 (UTC)

I agree with DCDuring. Colour (which is properly spelt with a u ;) ) for colour's sake is the antithesis of good design imho. Colour drawings, photos, animations and movies that illustrate and/or help define terms are of significant benefit to Wiktionary though and should be very strongly encouraged. Thryduulf (talk) 22:23, 10 July 2010 (UTC)

I for one support the idea of making our site more aesthetically pleasing, and creating custom CSS files is an excellent way to do that. I will admit that this particular setup doesn't do much for me now (I assume it will continue to be developed for some time?), but the idea behind it allows users to make the things look the way they want, which provides some good fodder for thinking about ways to make it look better for everyone. And yes, our logo is terrible, and confusing, and gets complaints every week, and I join you in your confusion as to why anyone would argue for its continued existence in the face of better alternatives. -Atelaes λάλει ἐμοί 23:08, 10 July 2010 (UTC)

What about drawing people's attention to the definition line? Is there a nice way to do that? --Bequw → τ 05:25, 11 July 2010 (UTC)

Probably. I'll think about it. —Internoob (Disc•Cont) 16:37, 11 July 2010 (UTC)

FWIW I use colors to detect untemplated {{sense}} and {{context}}. I wouldn't be opposed to discreet use of colors or icons (I utterly loathe the fr:ickin fr:wikt technique that almost all the section uneditable), but these looks too... just too. Circeus 03:23, 20 July 2010 (UTC)

Mobile browsers

Are there any customizations that we can make for "modern" mobile browsers (iPhone and Android phones)? Two things I wish we could do are:

1. Remove the left-hand side column. I think the iwikis can go entirely, but some of the other links could be moved up top.
2. Making <pre> boxes scrollablee (long lines screwup automatic text resizing).

Relatedly, does anyone know if all sites will get the mobile interface that Wikipedia has? If so, we should probably talk about how our pages can look good on that interface as well. --Bequw → τ 21:59, 14 July 2010 (UTC)

Started Help:Mobile access. --Bequw → τ 15:48, 20 July 2010 (UTC)

Implemented the above ideas in User:Bequw/mobile.js which is now at WT:PREFS (search for "mobile"). Please contribute any ideas you have. If people like it, we can push it site-wide for mobile viewers. --Bequw → τ 02:12, 30 July 2010 (UTC)

TOCs and the visibility thingy

Could we make TOCs collapsed by default and then put a side bar link to expand them by default like we do with quotations and things? —Internoob (Disc•Cont) 03:38, 15 July 2010 (UTC)

That's backwards. They should be collapsible by choice, not by default. --EncycloPetey 03:46, 15 July 2010 (UTC)

I agree with EP, the TOC should be should be expanded by default. Otherwise we will get lots of people complaining they can't find the bit they want. Thryduulf (talk) 09:07, 15 July 2010 (UTC)

If you want the ToC more out of the way for yourself you can have it placed on the right-hand side, where it makes use of much of the white space to the right of the Pronunciation section and the inflection line.

If you are thinking about unregistered users, for most entries the absence of a ToC may not be sufficient to show any definitions (due mostly to Ety and Pron sections) and any more than the L2 header for one language after the top one. DCDuring TALK 14:31, 15 July 2010 (UTC)

I'm just remembering a certain vote (or maybe a BP discussion) wherein some people (don't remember how many) thought that the TOC would be best collapsed by default to avoid long scrolling. But anyway, since we already have a cookie for collapsing, could we perhaps integrate that with the other things? —Internoob (Disc•Cont) 17:40, 15 July 2010 (UTC)

Mwera vs. Mwera languages

There are two languages: Mwera (with code mwe) and Mwera (with code mjh) in the table Wiktionary:Index to templates/languages.

Mwera (mwe) has alternate names: Chimwera, Cimwera, Mwela, see [2].

Mwera (mjh) has alternate names: Kinyasa, Nyanza, Nyasa, see [3].

I think that we should select and use one of alternate name, in order to differ, to discern languages. -- Andrew Krizhanovsky 09:12, 17 July 2010 (UTC)

Agreed. mjh is the smaller one so let's use one of the alternative names for it. How about, Kinyasa. --Bequw → τ 21:20, 17 July 2010 (UTC)

Done.

LOL :), because I look at the history [4], I changed it myself two days ago, when I read Ethnologue book [5], and I forgot about it. Sorry. -- Andrew Krizhanovsky 08:01, 18 July 2010 (UTC)

Do we have any other language templates with duplicate names? Maybe somebody could do a search for these. Nadando 19:23, 18 July 2010 (UTC)

There are very many, actually. For example, we have two languages called Tonga, and three languages called Manda. I can't remember the codes right now but they all appear on water so refer to that page. -- Prince Kassad 19:34, 18 July 2010 (UTC)

So, is this a problem that needs to be fixed, or can we forget about the language names and simply differentiate by codes? Nadando 19:51, 18 July 2010 (UTC)

AutoFormat chokes on it, so it probably needs a fix. My ugly and hackish way utilizes invisible Unicode characters to differentiate the language names, but there must be a better way. -- Prince Kassad 20:35, 18 July 2010 (UTC)

List of language codes with duplicate names:

• Aromanian: {{roa-rup}}, {{rup}}
• Asu: {{aum}}, {{asa}}
• Ayi: {{ayx}}, {{ayq}}
• Bada: {{bhz}}, {{bau}}
• Baka: {{bkc}}, {{bdh}}
• Bali: {{bcp}}, {{bcn}}
• Belarusian: {{be-x-old}}, {{be}}
• Beli: {{blm}}, {{bey}}
• Bemba: {{bmy}}, {{bem}}
• Bena: {{bez}}, {{yun}}
• Bodo: {{boy}}, {{brx}}
• Boko: {{bqc}}, {{bkp}}
• Cantonese: {{zh-yue}}, {{yue}}
• Fang: {{fak}}, {{fan}}
• Kami: {{kmi}}, {{kcu}}
• Karo: {{kxh}}, {{arr}}
• Kol: {{ekl}}, {{biw}}
• Konda: {{knd}}, {{kfc}}
• Literary Chinese: {{zh-classical}}, {{lzh}}
• Luwian: {{hlu}}, {{xlu}}
• Manda: {{mgs}}, {{mha}}, {{zma}}
• Mara: {{mec}}, {{mrh}}
• Min Nan: {{nan}}, {{zh-min-nan}}
• Nyiha: {{nyr}}, {{nih}}
• Purepecha: {{pua}}, {{tsz}}
• Sangu: {{sbp}}, {{snq}}
• Serbo-Croatian: {{hbs}}, {{sh}}
• Syriac: {{syc}}, {{syr}}
• Tamasheq: {{tmh}}, {{taq}}
• Tonga: {{toi}}, {{tog}}

Some of these are not separate languages. We seem to have 2 current methods of differentiating these currently- with country name qualifiers and with invisible unicode characters. Both have their problems, but I would definitely prefer the first. Nadando 05:52, 19 July 2010 (UTC)

Six of these (Aromanian, Cantonese, Literary Chinese, Min Nan, Serbo-Croatian, and Võro) are duplicate codes for the same language kept around because of Wikimedia. Wouldn't it be fine to redirect the wikimedia code to the ISO code like we redirect ISO 639-3 codes to 639-1 codes? --Bequw → τ 12:48, 19 July 2010 (UTC)

Nope, that breaks things. --Bequw → τ 20:18, 21 July 2010 (UTC)

Several older editors (e.g. Robert U) have told me to avoid parenthetically distinguishing language names. I believe this is to avoid confusion with situations where you'd want to qualify the language name - e.g. English (Canadian) - and have it be clear you are talking about a dialect and not a separate language. We can prepend the country name usually. --Bequw → τ 12:55, 19 July 2010 (UTC)

We probably want to also figure out what to do with the ISO codes that weren't imported because the language names had parentheses (first section of this list). --Bequw → τ 13:03, 19 July 2010 (UTC)

I dealt with some of the identical ones (ones w/o parentheses):

• yun → Binna (alternative name)
• kfc → Konda-Dora (ISO name)
• mgs → Nyasa (alternative name); zma→Australian Manda; mha → Manda (removed the qualifier). To avoid duplication I made mjh → Nyanza (alternative name)
• mrh → Mara Chin (ISO name)
• tmh → Tamashek (ISO name)
• tog → Siska (alternative name)

Questions

1. Ivan's the expert on Luwian, so I've asked him. done. --Bequw → τ 12:58, 20 July 2010 (UTC)
2. fak is less common than fan but has no alternative names. We could make fak → Cameroonian Fang or use one of fans alternative names (but fan already has w:Fang language).
3. w:P'urhépecha language seems to group both codes together. We could do that or change pua → Western Highland Purepecha (full ISO language name)
4. syr is a macrolanguage. Not sure if we should treat the group as a single language or it's subdivision. We could also rename syc → Classical Syriac (full ISO language name)

--Bequw → τ 16:56, 19 July 2010 (UTC)

Umm, tmh and taq are one and the same language. (tmh is a macrolanguage, the other is a subdivision). They probably should redirect to each other. -- Prince Kassad 19:50, 19 July 2010 (UTC)

quotations

Hello. I like the feature that quotations are hidden by default, however, there seems to be something wrong with it on the page acorralándole where the Spanish quote is hidden, but the English translation is not? Is there someone in particular I should ask about this? Thanks, ~ Logodaedalist | Talk ~ 01:24, 18 July 2010 (UTC)

You can use the translation= parameter to specify translations, at least with {{quote-book}}. Nadando 01:30, 18 July 2010 (UTC)

Oh, okay. ~ Logodaedalist | Talk ~ 01:38, 18 July 2010 (UTC)

Transliteration in citations

Currently our quotation templates only allow a transliteration parameter for the passage (when in non-Latin script). Should we allow for transliteration of the other parameters (author, title, etc.) since those also could be in non-Latin script? If so, how do we format them? --Bequw → τ 00:37, 19 July 2010 (UTC)

I've seen various inflection tables using mouse-over popups for transliteration. This would get around the space limitations, but I'm not sure if there are browser considerations we need to keep in mind. Nadando 00:39, 19 July 2010 (UTC)

Moving CMS to Javascript

Part 1: I'd like to switch the preference of showing "English glosses for mentioned terms in single quotes" to be implemented in Javascript rather than CSS. Using CSS causes problems that have been noted before. The main work would be done by User:Bequw/singleQuote.js, though there'd be some cleanup in the affected templates ({{term}}, {{onym}}, {{en-term}}, and {{deftempboiler}}). The JS should work in browsers IE 6 or better (I've test with the current versions of IE, FF, and Chrome). Assuming everything goes well, part 2 of using JS for our CMS needs will deal with the "Hide parentheses around glosses" preference. --Bequw → τ 18:18, 25 July 2010 (UTC)

Done. If you had hand-coded the CSS visibility into your skin's CSS file, you'll have to remove that and either include the JS file manually, or just use the PREFS. --Bequw → τ 18:35, 26 July 2010 (UTC)

I think lynx qualifies as "IE 6 or better".​—msh210℠ (talk) 18:59, 26 July 2010 (UTC)

Part 2: I'd like to do the same thing for the "Hide parentheses around glosses" preference. JS code is at User:Bequw/HideGlossParens.js and affected templates are {{term}} and {{deftempboiler}}. --Bequw → τ 22:25, 26 July 2010 (UTC)

Done. Let me know if you see any problems.

How come

none of the POS templates are displaying for me anymore? Is it because I have the inflection-tables turned on in PREFS? Ƿidsiþ 20:27, 25 July 2010 (UTC)

Sorry, refresh your cache and it should be turned to the highlighting (used the same PREFS slot). --Bequw → τ 22:13, 25 July 2010 (UTC)

PREFS

Anyone know what's wrong with WT:PREFS? The "Change the bullets in unordered lists to be round." pref won't save, and when I tried to add a pref to the end a few days ago, it wouldn't save either. Anyone know how to fix it? --Yair rand (talk) 20:43, 26 July 2010 (UTC)

Fixed. The numbers weren't consecutive (gosh we need to make that code more manageable). You can add yours again to the end. --Bequw → τ 02:10, 30 July 2010 (UTC)

Crossover list request

Might someone here have the wiki fu to generate a crossover list of red links currently listed on both User:HippieBot/Entries in Encarta online not in Wiktionary and User:Brian0918/Hotlist? Cheers! bd2412 T 01:19, 28 July 2010 (UTC)

id into the templates

I didn't find any reason for which we couldn't user some "id" into our templates. For example, {{computing}} would allow this link. JackPotte 22:46, 28 July 2010 (UTC)

Like es:masculino#Gramática & fr:roi#échecs. JackPotte 22:49, 28 July 2010 (UTC)

One problem is that we'd have to distinguish between similar ids in various languages. You can't assume that people will only want to link to English definitions. —CodeCat 23:04, 28 July 2010 (UTC)

Even worse, sometimes in the same language section there will be duplicate context tags for different definitions. --Bequw → τ 03:05, 29 July 2010 (UTC)

Thanks for this scope statement, we're going to think about it also in French and in Spanish. JackPotte 09:07, 29 July 2010 (UTC)

Template:nl-verb-form

My last edit(s) do not seem to do what they should. I wanted to remove the starting ‘The’, which was not consistent with other similar templates, such as {{past of}}. But ucfirst: doesn’t seem to go inside links or switches? It would be tiresome to do the test in each and every possible first word. H. (talk) 13:38, 29 July 2010 (UTC)

...which is why 'the' was there in the first place. :P —CodeCat 08:54, 30 July 2010 (UTC)

I can see that, but it is inconsistent and looks bad. H. (talk) 15:00, 30 July 2010 (UTC)

I think this problem probably shows up in a lot more form-of templates than just this one. I can think of a solution but I'm not sure it won't break a few entries. Basically it means limiting the possible combinations so that the amount of different cases is easier to deal with. It still would result in rather ugly coding. —CodeCat 16:10, 30 July 2010 (UTC)

FYI, the current code has it that if nocap=1 then the whole description of what form the word is is omitted.​—msh210℠ (talk) 16:29, 30 July 2010 (UTC)

Okay, I've fixed that, but without fixing the problem (that stuff does not get ucfirsted).​—msh210℠ (talk) 16:33, 30 July 2010 (UTC)

If we have stuff like lcfirst, couldn't we just do something like this: {{lcfirst:{{nl-verb-form|blablabla}}}} ? Then we could get rid of the parameter altogether. —CodeCat 19:16, 30 July 2010 (UTC)

No (see my comments, below, of 19:20, 30 July 2010 (UTC)).​—msh210℠ (talk) 19:20, 30 July 2010 (UTC)

The problem with this is that you can't have l/ucfirst: preceding a link, as it considers the bracket as the first character 9and renders it as a bracket, of course). (You can have it preceding a template call, I believe, as it applies the l/ucfirst to the results of that call.) The only way that I know of around this in this case is to apply the l/ucfirst inside each link in the switch. (This is not really such a big deal: there are not so many cases.) Maybe someone else has another workaround, though.​—msh210℠ (talk) 19:20, 30 July 2010 (UTC)

Seems to me that the current implementation of ?cfirst isn't well-suited to wikis. That ought to be fixed upstream, really. —CodeCat 19:24, 30 July 2010 (UTC)

@msh210: Rather than duplicating the l/ucfirst code nine times, and making the whole p=-switch relatively opaque, I think it would be clearer to have two copies of the whole p=-switch, one for each case, and not use l/ucfirst at all. . . . But even that won't really fix everything, because p= is only used for present-tense singular forms, so it's actually the n= that usually comes first, and for participles it's the t=. So the only simplest workaround is probably just to dispense with the links . . . —Ruakh_TALK 00:04, 31 July 2010 (UTC)

I agree it would be easiest to dispense with the links, but the nl editors have to decide if that's something they want to do.​—msh210℠ (talk) 16:07, 2 August 2010 (UTC)

In the long term I think it would be best to file this as a bug report in the extension that provides the ucfirst/lcfirst functions (anyone know which/where?). Such a function, especially when designed for a wiki, should be able to handle text in links. In the meantime, just revert the template to its original state with the 'The' until it's either fixed upstream or someone has a better idea. —CodeCat 17:18, 2 August 2010 (UTC)

It doesn't seem to be an extension: see mw:Help:Magic words#Parser_functions. A bug can be filed, I suppose, at [6].​—msh210℠ (talk) 18:11, 2 August 2010 (UTC)

Posted [7] —CodeCat 18:56, 2 August 2010 (UTC)

Template:past participle of

This template is borken - see rimorso as an example. SemperBlotto 14:45, 29 July 2010 (UTC)

It all looks fine to me. How is it broken for you? Thryduulf (talk) 14:56, 29 July 2010 (UTC)

It is now - gloves has backed out the latest edit. SemperBlotto 15:01, 29 July 2010 (UTC)

The server seems to recover very quickly from these things. Anyway, I left the user a message explaining why I reverted. Mglovesfun (talk) 15:30, 29 July 2010 (UTC)

Oops, sorry. Um, what was wrong and why? And can somebody do the change I intended without breaking anything? That is, I see absolutely no reason why the infinitive should not be linkified if unexistent: we want red links, right? H. (talk) 14:49, 30 July 2010 (UTC)

The template assumes — mostly correctly — that if the parameter is not an entry-name, then it's probably a link to an entry (as in {{past participle of|[[foo]]}}), and shouldn't be re-linkified (since [[[[foo]]#English|[[foo]]]] works about as well as you'd expect). A better test is {{#if:{{isValidPageName|{{{1|}}}}}}}. —Ruakh_TALK 00:10, 31 July 2010 (UTC)

Citing forewords, press reviews

What is the correct way to cite the foreword of a book (using {{quote-book}}) written by someone different to the main author? See for example the 2002 cite at Snickometer.

What is the correct way to cite meta-content of a book, e.g. press reviews, blurb by the publisher about the author, etc, when you don't have the original it came from, just the portion on e.g. the back cover of a book? (I don't have an example of this - I decided to pick a different source that was easier to attribute!) Thryduulf (talk) 22:28, 30 July 2010 (UTC)

Template:rfconj (2)

Can we now deprecated the individual conjugation request templates? This are mainly used by Tbot (talk • contribs) when it creates verb entries. I have to say I was a bit surprised to find we had no generic template to request conjugations until a few weeks ago. Mglovesfun (talk) 14:06, 31 July 2010 (UTC)

I'd prefer a more generic Request for inflection template, so that the same template can be used for nouns, adjectives and other inflected words as well. —CodeCat 14:28, 31 July 2010 (UTC)

There is that, though perhaps it would be nice to specify which inflection, if there is a specific one, such as conjugation or declension. Or is that just superfluous complication? Mglovesfun (talk) 14:33, 31 July 2010 (UTC)

I imagine that if there is a request, anyone looking to fulfill it would just add any inflections that are missing. No need to specify, really. —CodeCat 16:36, 31 July 2010 (UTC)

Um, Tbot does what?! I'm not aware of it adding any request for conjugation when creating verb entries? Tbot entries do show up on lists that Rising Sun et al have asked me to create of verbs that lack conjugation.

Should Tbot add something? Agreeing with CodeCat: it doesn't need to be specific, the conjugation/declension/inflection would—of course—be added as appropriate. (Just make {rfinfl} and {rfdecl} redirects to the same thing? ;-) Tbot can be taught which POS in which languages should have inflection requests; should it? Robert Ullmann 17:19, 31 July 2010 (UTC)

Yeah, it'd need a sort of list for that. But some languages such as English have default forms that work most of the time but not always. {{en-noun}} for example defaults to a plural in -s. So in that case it would only need to be verified that it is correct. Unless, of course, Tbot doesn't even use language-specific templates (but it ought to, really). —CodeCat 19:45, 31 July 2010 (UTC)

Perhaps I've wrongly linked the French Tbot entries I check with {{frconjneeded}} which is often used on French Tbot verb entries. (after checking) Indeed neither Tbot nor Robert Ullmann is the author of that template. Right. Mglovesfun (talk) 21:09, 31 July 2010 (UTC)

Having said that, see this diff. Mglovesfun (talk) 21:11, 31 July 2010 (UTC)

August 2010

Edit protected request

Are there any templates here that resemble the editprotected template at en:wp? It seems to me that Wiktionary:Criteria for inclusion could stand to have a few commas added, but I can't find an editprotected template to make a request on the talk page. As well, I can't find something similar to the administrators' noticeboards at en.wp and Commons. Nyttend 22:21, 2 August 2010 (UTC)

I'm not aware that we have any editprotected templates. Just make a request on the talk page, here, the information desk or on the talk page of an active administrator. We don't have any direct equivalent of the administrators' noticeboards of en.wp, what we have are the primary discussion pages

• Wiktionary:Tearoom for words and lexical discussions
• Wiktionary:Beer parlour for policies, procedures and the like. User problems that aren't clearly vandalism usually go here.
• Wiktionary:Grease pit for technical discussions
• Wiktionary:Etymology scriptorium for discussions about etymology
• Wiktionary:Information desk for general questions and things that don't fit into any other room

Just pick one that fits what you want, and don't worry too much about getting it right every time. We are a much smaller community than en.wp so we don't have the need (or resources) for as much specialisation as that project has. Thryduulf (talk) 00:00, 3 August 2010 (UTC)

Okay, thanks; I've asked Yair rand for help. Being so unfamiliar with Wiktionary, I hadn't realised that pages like this were appropriate for such requests, let alone that there weren't pages such as an administrators' noticeboard. Nyttend 01:00, 3 August 2010 (UTC)

It would be helpful if you could make a note of things like this so we can produce a more comprehensive guide to Wiktionary for those familiar with Wikipedia than the current brief welcome template (which reads quite negatively). I've made a very, very brief set of notes to start the ball rolling on seach a guide at Wiktionary talk:Beginner's guide to the English Wiktionary for experienced Wikipedians (ideas for a better title are more than welcome as well!). Thryduulf (talk) 01:48, 3 August 2010 (UTC)

In this guide page, could you address the "new messages" feature that appears next to the "my contributions" button? Yair rand replied on his/her talk page, causing me to get a "new messages (1)" notice; although I looked at the message and replied, I still have that "new messages (1)" notice. Nyttend 04:02, 3 August 2010 (UTC)

That problem is the result of a talk page that uses "Liquid Threads". It's a known bug with the LT, and there's not anything that can really be done about it unless you "unwatch" Yair Rand's talk page. It will go away eventually on its own, but not as quickly as it ought to. --EncycloPetey 04:17, 3 August 2010 (UTC)

Messages don't count as "read" until you click "mark as read" on Special:NewMessages, even if you've replied to them. --Yair rand (talk) 05:02, 3 August 2010 (UTC)

Aha. Button clicked, and message is gone. I've never before seen LiquidThreads on any WMF wiki, so it was difficult to figure it out. Nyttend 13:38, 3 August 2010 (UTC)

Template:audio displays awkwardly

When you click on the "More..." it's replaced by a div that contains some useful links. However, the div is set to 50px and the contents inside are set to 40px, at least for me in both Firefox and Chrome. It ends up being a very thin column and the contents are difficult to read. The one on wikipedia.org that it is modeled from uses the respective values 200 and 190. I'm not sure where the numbers are coming from exactly. It looks fine, though not quite the same as on Wikipedia, on Firefox and Chrome if you just take out the width restrictions, though this may potentially cause problems in other browsers. — This unsigned comment was added by Redbmk (talk • contribs).

Comments in templates

Templates can be pretty inscrutable. Commenting out newlines/linefeeds in templates makes them more readable:

  {{#switch:{{{g}}}<!--
    -->|m={{m}}<!--
    -->|f={{f}}<!--
    -->|n={{n}}<!--
    -->|p={{p}} ...

Is this deprecated? Is the overhead too great? If used should they be removed after development? —Saltmarsh^{απάντηση} 05:15, 3 August 2010 (UTC)

I think the overhead isn't very significant. One of the first things the parser does is strip out all comments, but that's just a matter of search-and-replace, which is a fairly cheap string operation. It does that even before it does any transclusion, I suspect. And in any case, any small overhead is worth having readable templates, I think! —CodeCat 09:09, 3 August 2010 (UTC)

{{subst:PAGENAME}} minus the last two letters

How do I insert the page name in the middle of the text like {{subst:PAGENAME}}, then take off the last two letters? I'm trying to automate some verb conjugation. ~ heyzeuss 21:29, 3 August 2010 (UTC)

You can't. The closest thing would be to add a parameter to the template, called verb_stem or something similar, which would be the verb without the last two letters. Nadando 21:55, 3 August 2010 (UTC)

I found one method, but I have to drag some new templates over from Wikipedia: w:Template:Trunc and w:Template:Str len. It worked when I tried it over there. A more elegant solution would be quite welcome. Now I'm going to bed.

{{Trunc|{{subst:PAGENAME}}|{{#expr:{{Str len|{{subst:PAGENAME}}}} - 2}}}}

~ heyzeuss 22:36, 3 August 2010 (UTC)

See the recent WT:GP#String processing in templates. We generally do things the way Nadando mentioned. --Bequw → τ 02:18, 4 August 2010 (UTC)

I believe it is possible, with some effort, to create a page User:Heyzeuss/cut2 such that {{subst:User:Heyzeuss/cut2}} on page named foobar results in the wikitext foob. It's not trivial to do, because template substitution is a bit finicky, but it's possible. I think. You don't want to just import the Wikipedia templates, because they're very server-intensive, and don't support substitution, so we'd end up with a lot of server-intensive pages; but you can use them as your starting-point. (Actually, feel free to modify {{str len}} to get it to support substitution. It's not currently used anywhere, so don't worry about breaking it.) —Ruakh_TALK 02:34, 4 August 2010 (UTC)

I imported the most recent version of {{str len}} from WP, which does support substitution. Any problem with just using this substituted? ({{subst:padright:|{{subst:#expr:{{subst:str len|{{subst:PAGENAME}}}}-2}}|{{subst:PAGENAME}}}}) --Yair rand (talk) 02:57, 4 August 2010 (UTC)

Thanks, that works really well! ~ heyzeuss 06:24, 4 August 2010 (UTC)

Kudos! (It's interesting that they updated {{Str len}} to support substitution, but not {{Trunc}}.) —Ruakh_TALK 11:32, 4 August 2010 (UTC)

US audio files in Old English sections

There seem to be a lot more than you might thing, see diff. Mglovesfun (talk) 09:40, 4 August 2010 (UTC)

unsupported titles

I've created User:Msh210/unsupp.js, which is meant to replace the ugly "Appendix:Unsupported titles/Colon hyphen right paren" in the =first header= at [[Appendix:Unsupported titles/Colon hyphen right paren]] with ":-)". It works in my browser (FF). Can others please make sure it works, too? (You can use

importScript('User:Msh210/unsupp.js');

in your skin .js file, usually monobook.js, to test it.) If it works, I propose we make it part of the default script for the site; what think you all?​—msh210℠ (talk) 18:50, 6 August 2010 (UTC)

Works in Chrome 5 and IE8. --Yair rand (talk) 21:19, 6 August 2010 (UTC)

Okay, then I propose we make it part of the default script for the site; what think you all?​—msh210℠ (talk) 17:46, 12 August 2010 (UTC)

I'm a bit confused. The linked script contains this comment of yours:

  // This currently goes through these manually.  We should instead
  // have a template {{unsupportedpage|:}} which generates
  // <span id="unsupportedpage" title=":" />, and then use here
  // string=document.getElementById('unsupportedpage').title; .
  // There'd be a problem when the title includes a "; is there
  // a fix for that?

Why are you asking for people to test this script, and why are you proposing adding this script to the site-wide JS, if this isn't the actual implementation you want. Is it just that the comment is obsolete, and you now do prefer this implementation?
(By the way, I support the concept. It's a good idea, and I agree that something implementing it should be added to the site-wide JS.)
—Ruakh_TALK 18:18, 12 August 2010 (UTC)

The current script works. It does go through the list manually, which is ugly from a scripting standpoint, but that ugliness is invisible in the result. I have no plan to improve the script, simply because the only improvement I can think of has a problem (as described n the comment you quote). I left the comment there in case someone can improve it, but it's good as is.​—msh210℠ (talk) 18:21, 12 August 2010 (UTC)

I too would prefer the <span> solution. Currently there aren't any titles that use a ";" but if need be you could use a custom escape-scheme.--Bequw → τ 21:51, 12 August 2010 (UTC)

Re: "Currently there aren't any titles that use a ';'": The problem that the comment refers to is not with ';', but with '"'. (Confused me, too.) We don't really need a custom escape scheme, in that " would already work fine. —Ruakh_TALK 11:53, 13 August 2010 (UTC)

Meaning, &quot;, right? Yeah, that'll work.​—msh210℠ (talk) 17:50, 13 August 2010 (UTC)

Okay. I've created {{unsupportedpage}} and modified [[User:Msh210/unsupp.js]] accordingly. Works here, but others' (re)testing would be helpful.​—msh210℠ (talk) 17:50, 13 August 2010 (UTC)

I'd like to hear Conrad or others as well. Should implementation be put off until after the new usability changes September 1? DCDuring TALK 17:56, 12 August 2010 (UTC)

I can't see why the changes should affect this (or be affected by it), but someone who knows more about them may.​—msh210℠ (talk) 17:50, 13 August 2010 (UTC)

It seems to work well, except that (in the Vector skin) some style is applied to #firstHeading to ensure that the sub-page navigation looks correct. I suspect the easiest solution is just to do document.getElementById('firstHeading').innerText = document.getElementById('unsupportedpage').innerText; I assume you didn't to avoid breaking anything that relies on that having the correct text, but I can't think of anything that would when wgPageName and wgTitle are available. Otherwise, we can just copy the CSS rules around a lot. Conrad.Irwin 10:11, 15 August 2010 (UTC)

Okay, I effected that solution. It works here (FF, monobook); other-browser testing, yet again, would be appreciated. Then can we make it site-wide?​—msh210℠ (talk) 17:26, 18 August 2010 (UTC)

It works for me in Chrome 6.0 beta, FF 3.6.8, and IE 8.0 (all on MS Vista) in both Vector and Monobook. Go for it. --Bequw → τ 21:12, 18 August 2010 (UTC)

Effected. Thanks, all.​—msh210℠ (talk) 18:13, 19 August 2010 (UTC)

Extra blank lines

I'm trying to edit user-fixes.py so that my changes don't leave too many blank lines, but it's not working and autoformat is coming right behind me to clean up.

(r'\n{3,}', u'\n\n'),

~ heyzeuss 16:42, 7 August 2010 (UTC)

Update: It works with a Windows carriage return line feed \r\n. That just seems really strange to me. ~ heyzeuss 12:17, 8 August 2010 (UTC)

IPA for affixes

I've been wondering how one would transcribe an affix in IPA/enPR/SAMPA, specifically the affixing part. From the examples I've seen, almost all of them have used an em dash in the transcription, which is a probem because the em dash is an illegal character in SAMPA (not to mention it's visually indistinguishable from the plain dash in the monospace font we use for SAMPA). I would have thought you don't spell the connecting dash and therefore it should not appear in the phonetic transcription, but I don't know what others think. -- Prince Kassad 12:22, 8 August 2010 (UTC)

Why write a dash if you don't actually pronounce it as anything? I say leave it out. —CodeCat 21:51, 8 August 2010 (UTC)

Omit it IMO.​—msh210℠ (talk) 15:10, 9 August 2010 (UTC)

Exactly. Over and over- are exact homophones. Mglovesfun (talk) 14:04, 10 August 2010 (UTC)

Template:gem versus Template:etyl:gem

Following this discussion, I'm trying to create a proper category structure for Proto-Germanic entries and templates. The only problem is that the boiler templates don't seem to work as they require the language to be specified as etyl:gem. That's not a problem as such, but {{etyl:gem}} returns 'Germanic' even though the proper name of the language in question is 'Proto-Germanic'. I imagine this makes sense for etymology templates, but now that we want to treat Proto-Germanic as a 'language' rather than a family, we need a different solution. I was thinking of creating {{gem}} (with content 'Proto-Germanic') but as it has been deleted previously I thought I'd run it through here first. —CodeCat 11:35, 10 August 2010 (UTC)

Well, we don't want valid-looking language templates for invalid languages, because we use those templates in lots of ways: they're not just a convenience for people who don't want to type out Germanic or whatnot. (By invalid languages, I mean languages that we don't create mainspace entries for, languages that can't be used in (X)HTML lang="" attributes, and so on.) In which contexts exactly do you want this "Proto-Germanic" template to be used for? Is it just for use in {{etyl}}? If so, then I'd suggest creating something like {{etyl:Proto-Germanic}}, or maybe something like {{etyl:proto:gem}} if you expect that we'll only be interested in proto-languages of ISO-coded entities. —Ruakh_TALK 13:39, 10 August 2010 (UTC)

We'd want to use them in all the contexts that other language templates are used in. So for example in {{infl}}, {{langcatboiler}} and friends, {{compound}} and so on. We would be treating Proto-Germanic as a proper, albeit theoretical and reconstructed, language, and would have entries in the Appendix namespace. I actually ran into the problem in the first place because {{langcatboiler|etyl:gem}} doesn't work for Category:Proto-Germanic language. I propose we use templates prefixed with proto: for such languages, i.e. {{proto:gem}}. That would destinguish it from {{etyl:gem}} which would indicate the language family as a whole and be used in etymologies rather than Proto-Germanic appendix entries. —CodeCat 14:52, 10 August 2010 (UTC)

I think this requires a bit more thinking through. Templates such as {{infl}} and {{compound}} and {{term}} and {{l}} and {{onym}} don't just use the language-code to determine the language-name; they also use it in generating (X)HTML lang="" attributes. We don't want to be generating <span lang="proto:gem">. And they also generate links to main-namespace entries, not appendices. Maybe we should have templates like {{proto-infl}} and {{proto-compound}} and so on, which then make use of language-code templates like {{proto:gem}} and generate (X)HTML like <span lang="gem-x-proto"> and link to appropriate appendices? —Ruakh_TALK 19:42, 10 August 2010 (UTC)

We also don't want to make duplicate sets of templates if unnecessary. Does it always work to put "Proto-" in front of a w:ISO 639-5 language family name? Are there cases where no proto language exists for a family, or cases where there's a proto-language for which no family code is (or will be?) assigned? --Bequw → τ 20:57, 10 August 2010 (UTC)

Re: "Are there cases where no proto language exists for a family […] ?": No, but ISO 639-5 includes not just language families but also language "groups" such as artificial languages ({{etyl:art}}), North American Indian languages ({{etyl:nai}}), and so on, and those don't have proto-languages. (Well, and technically some real genetic groupings don't have proto-languages in that they descend from attested languages — Proto-Romance is a form of Vulgar Latin.) But I don't see that that's a big problem; we don't have to use the codes that we don't want or need to. —Ruakh_TALK 21:24, 10 August 2010 (UTC)

To pick this discussion back up... As far as I can see, the problem is that we want to emit xml:lang= attributes but with values that aren't valid languages in any ISO 639 standard. However, from what I found, the xml:lang= attribute allows possibilities for private-use extensions, beginning with x-. So maybe we could settle on something like x-gem or x-pgem? We could also use the art-x- prefix, used for constructed languages and such. Proto-languages, while real in the sense that they were actually spoken as a proper language at a certain time, are still constructed languages in the modern sense because they are not attested by native speakers, but created (from evidence, but nonetheless) by linguists. So we could also go for art-x-gem or art-x-pgem or similar, although the names do become rather long then. —CodeCat 11:35, 25 August 2010 (UTC)

Well, that's what I suggested above, but again, it's just one small part of the problem. The big problem is that the language templates are designed to be used with a whole host of other templates (as you write above, "{{infl}}, {{langcatboiler}} and friends, {{compound}} and so on"), and none of those other templates supports anything like what you want. There's the "language templates for constructed languages" part of the problem, and there's the "all other templates that use language templates: using them for constructed languages" part of the problem. The latter is much bigger. —Ruakh_TALK 12:00, 25 August 2010 (UTC)

But what exactly is the latter problem in this case? As far as I can see the main objection is breaking ISO 639 compatibility. But with the suggestions I've made that should be fixed, right? —CodeCat 14:45, 25 August 2010 (UTC)

Your suggestion, like my suggestion, addresses the issue of ISO 639 compatibility. But you apparently want {{infl}} to link to appendices. How will it know to do that? —Ruakh_TALK 14:51, 25 August 2010 (UTC)

I don't think it needs to. I'm more interested in the automatic categorisation and additional boilerplate text that many templates provide (standardisation is a good thing, after all). And that won't change, as long as the language template correctly expands to 'Proto-Germanic'. But right now there is no such language template. —CodeCat 14:56, 25 August 2010 (UTC)

So you don't want appendix-links, fine, but does that mean you're O.K. with the mainspace-links? For example, you want {{compound}} to display redlinks that we don't want linkified? —Ruakh_TALK 16:35, 25 August 2010 (UTC)

Well, just take a look at this: . So it seems to work just fine in any namespace, and the only issue there is the hard-coded naming of proto-terms ({{proto}} being mandated and all to prevent that). But I believe that's fixable with some puzzling, and it's not a big issue to just forego using those templates anyway until a proper fix is found for that problem. —CodeCat 17:33, 25 August 2010 (UTC)

Ugh. I agree with your statement that "standardisation is a good thing", but I disagree with your implication that {{compound|Appendix:Proto-Germanic *langaz|alt1=*langaz|Appendix:Proto-Germanic *tīnaz|alt2=*tīnaz}} promotes standardization! —Ruakh_TALK 18:21, 25 August 2010 (UTC)

That wasn't my implication at all, actually the opposite, and it's why I suggested that it's a workaround at best and needs a proper fix, and not to use that template preferably until there is a fix. —CodeCat 22:22, 25 August 2010 (UTC)

Information Desk rhs ToC

The text of the page does not flow around the rhs ToC. Is that the result of something erroneous in Wiktionary:Information desk/header? DCDuring TALK 19:28, 10 August 2010 (UTC)

I'm guessing it has something to do with the either the archive search box or a failure to have some code for the floating text. Wiktionary:Grease pit/header seems to have it right, with archive search. DCDuring TALK 19:36, 10 August 2010 (UTC)

What do you see exactly? For me it flows around the RHS ToC until it reaches the long link (which isn't wrapped) in Wiktionary:ID#HTML_entity_for_.3D pushing everything below that to below the bottom of the ToC. Archive that section (or make your window wider) and it should flow continuously. --Bequw → τ 20:52, 10 August 2010 (UTC)

For me it is much worse: there is no flow-around. The ToC and the text simply overlap so some of the text is illegible. I don't remember it happening except at ID. It may be that I need to clear out my monobook pages, as most of what was there is now implemented in "my" or "Wiktionary" preferences. Then we could reduce the likelihood of it being simply idiopathic. DCDuring TALK 21:06, 10 August 2010 (UTC)

I cleared out both monobook.js and monobook.css, logout and in and cleared the cache. The problem at WT:ID changed. The text and ToC don't overwrite each other. But the page is several times wider than my screen, so I have a horizontal scroll bar. The ToC extends just off the right hand side of the page. IOW, there is probably something defective in the WT:ID header page code that I could live with, but my give someone else worse heartburn. The monobook clear out was long overdo. I had some CM stuff in there. DCDuring TALK 21:24, 10 August 2010 (UTC)

Oh, and I have lost rhs ToC on non-entry pages, except WT:ID. I had gotten used to them on the right for all pages, but don't really need them. WT:ID just is different from the other "high-volume" discussion pages. Why should it be? BTW why don't all of them have an archive search box? DCDuring TALK 21:32, 10 August 2010 (UTC)

BTW, I now have a horizontal scrollbar for other discussion pages that I don't recall having. DCDuring TALK 21:39, 10 August 2010 (UTC)

I've cleaned some format issues on the page. Does it look OK now? --Bequw → τ 04:56, 20 August 2010 (UTC)

Thanks, yes. The ToC now appears on the right and the pagewidth is no longer ~3 times my screen width. I still have a horizontal scrollbar (apparent page width ~1.1 times my screen width), but that also appears on WT:BP and WT:GP (apparent page width ~1.6 times my screen width). In contrast, WT:TR and WT:ES have no scroll bar. On all but WT:ID the ToC appears on the left.

The horizontal scrollbar is more significant than the RhS ToC for non-entry pages like this IMO. DCDuring TALK 09:25, 20 August 2010 (UTC)

BTW, among clean-up pages, WT:RFD alone has the 1.6 times apparent page width and associated horizontal scroll bar. DCDuring TALK 09:40, 20 August 2010 (UTC)

Ah, I see that in FF but not in my standard Chrome. In the ID, RFD, BP and part of the GP it was due to wide content in <pre> tags which can be (and should in the future) fixed by using <pre style="overflow: auto;"> instead of just <pre> (you can see at WT:CUSTOM#More how to always view <pre>-tags that way). In the GP it was due to FF not word-breaking at hyphens in <tt>-tags. I've inserted some zero-width spaces (&#x200B;) to force breaks at certain points. How does it look now? --Bequw → τ 19:22, 20 August 2010 (UTC)

Thanks. All four pages seem good with respect to page width. I hope the changes don't cause something else to come unglued for some browser setup. DCDuring TALK 19:53, 20 August 2010 (UTC)

Wouldn't you know it: the page-width problem occurs at Help:Customizing your skin! DCDuring TALK 19:57, 20 August 2010 (UTC)

Searching wiki markup

How can I search wiki markup? I want to search by template parameter. ~ heyzeuss 13:33, 12 August 2010 (UTC)

I'm not sure if that's possible. I've often solved it by modifying the template to add the page to a special hidden category (something like 'CodeCat's test category') depending on the parameters. Obviously not a good solution at all, but it worked well for more elaborate projects. I'm sure someone else would have a better idea though. —CodeCat 16:25, 12 August 2010 (UTC)

If you are comfortable with parsing XML you can download the most recent dump here and search for your template. Or just ask here and I'd be happy to do the search for you. Nadando 17:24, 12 August 2010 (UTC)

I'm going to try these suggestions, although I will have to learn how to do both of them. I figured out how to parse a dump, but I don't know how to search with a regex string in python. Here's what I have:

import xmlreader

for entry in xmlreader.XmlDump('enwiktionary-20100812-pages-articles.xml.bz2').parse():
  if 'fi-conj-tulla' in entry.text:
    print entry.title

and here's what I have now, with regex capability. ~ heyzeuss 18:31, 13 August 2010 (UTC)

import re, xmlreader
dump=xmlreader.XmlDump('enwiktionary-20100812-pages-articles.xml.bz2')

for entry in dump.parse():
    if re.search(r'fi-conj-tulla\|.*?\|.*?\|tt', entry.text):
        print entry.title.encode('utf-8')

As for adding categories, I'm trying this, but it's not working yet.

<includeonly>{{#ifeq:{{{3}}}|tt|[[Category:Finnish tulla-type verbs/consonant gradation t-tt]]}}</includeonly>

I don't know anything about how to read the dumps (though I'd love to), so can't help you with that, but the code for including a category, above, won't work, as it has <includeonly> around it (which means that it'll only add the category to a page that transcludes the page you're adding it to). By the way, you should also use subst:#ifeq rather than #ifeq.​—msh210℠ (talk) 17:11, 18 August 2010 (UTC)

Script error on every page

Is there a problem with the server or is someone testing out something that's broken? I'm getting a script error on every Wiktionary page once I log in, including the "successfully logged in" page and edit windows. I have to respond to a dialog box each time to stop the script that's slowing down page loads, and then refresh the page. --EncycloPetey 23:03, 5 May 2010 (UTC)

Not seeing it in FF 3.6.3. DCDuring TALK 23:09, 5 May 2010 (UTC)

I was seeing it in IE for about 30 minutes, but in the time I've been away on Wikisource (where there was no problem), it seems to have cleared up. --EncycloPetey 23:35, 5 May 2010 (UTC)

I had the same problem yesterday. Mglovesfun (talk) 11:27, 7 May 2010 (UTC)

For future reference, if you do get an error message, it's useful if you can copy/paste it into WT:GP (along with Browser and version). Particularly in this case, I've no idea what might have caused the problem. There should never be any javascript error messages, so please do report those that you see. Conrad.Irwin 13:45, 7 May 2010 (UTC)

It's still pretty frequent, and I experienced it a few minutes ago. It only affects my IE, FF works fine.

This might be related to the problems (it could also be useless for all I know :-D) (it's translated by me, so some technical words might have been given a poor translation):

Details on website error

User agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; ImageShack Toolbar 4.3.5; .NET CLR 1.1.4322; WWTClient2; InfoPath.1; .NET CLR 3.0.30729; .NET4.0C) Time: Mon, 5 Jul 2010 12:32:01 UTC

Message: The object does not support specified property or method Line: 218 Sign: 5 Code: 0 URI: http://en.wiktionary.org/w/index.php?title=-&action=raw&gen=js&useskin=monobook&283l

I have never experienced it on any Wikipedia, but I think I experienced it on the nn wikt after copying the MediaWiki:Common.js and MediaWiki:Common.css pages here and pasting them there. --Harald Khan Ճ 12:46, 5 July 2010 (UTC)

I downloaded the file above and opened it in my Python editor, where line 218 was part of the following code:

===[[MediaWiki:Youhavenewmessages]] to display differently for non-newbies with JS than for others===
*/
if (wgUserGroups && wgUserGroups.join("").indexOf("autoconfirmed") > -1)
{
  addCSSRule(".msgfornewbies", "display: none");
}else{
    addCSSRule(".msgfornonnewbies", "display: none");
}
/*

The actual line 218 is addCSSRule(".msgfornonnewbies", "display: none");. I removed this section from the nn wikt, while I was experiencing the error there, since it's not supposed to be there anyway. When I hit "save", the problem was still there, but upon pressing ALT + F5 it disappeared, though it was also gone on the en wikt when I returned there, where the problem had run in parallell. Could this be it? --Harald Khan Ճ 09:53, 13 August 2010 (UTC)

Frame to tabs

Currently at least 5 Wikipedias and 2 Wiktionaries propose it. JackPotte 20:43, 17 August 2010 (UTC)

But what is it? I can't read Catalan or French so the links don't help me in that regard. Are you suggesting we do or don't implement/approve/install/whatever it? Why? Thryduulf (talk) 00:00, 18 August 2010 (UTC)

It lets you create a little frame with tabs. If you go to [[fr:Modèle:Cadre à onglets#Exemple d'utilisation]], there's an example, showing both the wikitext to call the template, and the resulting tab-frame. I assume that JackPotte is suggesting we add the relevant CSS, JS, and template, so that editors can add such tab-frames to pages here; I can't speak to "why", though. —Ruakh_TALK 00:12, 18 August 2010 (UTC)

Could this help (or merge with) WT:GP#Tabbed language browsing? --Bequw → τ 00:59, 18 August 2010 (UTC)

Yes, it could help the design of this extension. Moreover fr.w uses it only in the "User" namespace, it.wikt at the bottom of its main page, and I've suggested on fr.wikt to use it to separate the languages in the translations paragraph. If we want to install it here, we have to import the template and a little common.css and .js stuff. JackPotte 05:34, 18 August 2010 (UTC)

Ok, I can now see what it does in terms of producing a frame with tabs. But I still don't understand what the benefits of using it would be? I've only had a quick play with tabbed language browsing (because I find the one-page layout preferable) but that seems to do something very similar without adding reams of complicated wikicode to the page? Exactly what do the other projects use it for and what advantages does it bring over any other method of doing that? Thryduulf (talk) 16:27, 18 August 2010 (UTC)

Actually if I'm allergic to the Korean characters (it's all Greek for me) I can avoid to see them without clicking on their tabs. JackPotte 20:39, 18 August 2010 (UTC)

Requests for appendix expansion

Since we have a considerable number of uncomplete appendices (and being "completeness" such a subjective but worthy goal), I feel we need a way to formally request for their expansion and point out where it is necessary.

The most natural choice would be, of course, using a template for that. After reviewing the existing templates, I've concluded that they're not good enough:

For instance, Template:attention is too subtle; Template:rfc implies there's something wrong or badly formatted, as opposed to simply uncomplete; and Wikipedia "stub" templates, if used in Wiktionary appendices without much conversion, would likely indicate that said appendices are short in contents, which would not always be true. Then, I created a brand new template for that, Template:rfexp.

It is formatted specifically for appendices, because entries already have similarly named ones like rfdef, rfap, rfe for virtually every section. Although, rfexp could foreseeably be used in Help:, Rhyme: or other namespaces eventually if necessary. --Daniel. 03:20, 20 August 2010 (UTC)

Language codes or names

I've recently created the template {{lang}}. I believe its purpose is quite simple and understandable as explained at its documentation.

However, it lacks a function that I believe is very important. Can that template be upgraded to work if , alternatively, someone types names of languages instead of their codes? Some examples that should work properly after such an upgrade would be {{lang|English}} and {{lang|German}}. --Daniel. 05:15, 20 August 2010 (UTC)

I believe existing templates perhaps do that by checking whether Template:{{{1}}} is an existing page, given that {{{1}}} is a language code. —CodeCat 21:18, 20 August 2010 (UTC)

I think you're misunderstanding what Daniel. (talk • contribs) wants. The difficulty is not in recognizing whether the argument is a language code or a language name; that can be done using #ifexist:, as you suggest, or (as {{langname}} does) by checking if the argument is all-lowercase, in which case it's presumably a language code. Rather, the difficulty is in actually converting a language name to the corresponding code.

By the way, I don't think {{lang}} is a good name for this template.

—Ruakh_TALK 22:12, 20 August 2010 (UTC)

Worry diff

diff, it seems that {{present participle of}} no longer accepts language names instead of codes, it simply showed Template:French which isn't a template. Surely it should use some sort of {{#ifexist:Template:{{{lang}}}}}. Mglovesfun (talk) 14:19, 21 August 2010 (UTC)

Form-of templates are supposed to use language codes, not language names. I would much prefer having a bot fix up the entries to use codes rather than changing the template to accommodate the entries. --Yair rand (talk) 21:23, 23 August 2010 (UTC)

It's probably tied to the changes being done to {{lang}} in the discussion above. —CodeCat 21:51, 23 August 2010 (UTC)

??? {{lang}} isn't used in {{present participle of}}. {{lang}} was only created a few days ago. I don't see how this could be related. --Yair rand (talk) 22:07, 23 August 2010 (UTC)

It looks like Daniel. (talk • contribs) broke that with his {{deftempboiler}} stuff. —Ruakh_TALK 22:31, 23 August 2010 (UTC)

Or one could say that I broke it by not using {{langname}} in {{wlink2}}. There are currently 904 entries broken (see Special:WhatLinksHere/Template:French), all created by User:Keenebot2, I think. Could someone run a bot through them? --Yair rand (talk) 23:02, 23 August 2010 (UTC)

I agree with Yair on the statement "Form-of templates are supposed to use language codes, not language names.", mainly for preemptive conveniency: it is evidently easier to change a language name if all related form-of templates use language codes.

As for the diff of "servant", indeed, {{wlink2}} was affecting {{langname}} and causing codes similar to {{present participle of|whatever|lang=Portuguese}} to not work. I could change it quickly, so the code of Template:present participle of (and similar templates) now allow any language name as a value for the parameter lang. I wouldn't blame you, Yair, mainly because I remember how {{wlink2}} happened to be useful when I was developing {{deftempboiler}}. You saved me some effort and I saved you some effort; then I believe we're even on this subject. --Daniel. 02:24, 24 August 2010 (UTC)

By the way, I also agree that we should be using language-codes exclusively. Language-names let us link to the right section and add the right category, but they don't let us mark up the HTML correctly, select the right default script, and so on; and not all templates can support them, since sometimes the category name includes the language-code, which means that we have a confusing mess when lang=French works in some templates and not others. But, we need to change the entries that rely on language-name support before we change the templates to remove it. —Ruakh_TALK 13:23, 24 August 2010 (UTC)

Problem with context and/or transitive and intransitive templates

Browsing the entry for (deprecated template usage) keep on my phone earlier using Wapedia [8] I noticed that when an entry is marked "transitive" or "intransitive" and something else, e.g. "archaic" or "cricket", then it gets marked as, e.g. "(transitiveSpecial, archaic)". I've not got time to hunt down where this problem is (could be {{transitive}} or {{context}} at a guess) let alone what it is. Thryduulf (talk) 22:22, 23 August 2010 (UTC)

I think it's because Wapedia doesn't expand templates perfectly (note the "safesubst" stuff that appears above where it tries to parse {{proto}}s). Not sure exactly where it fails, though. Some more links for the curious: uncle and blow. Some thoughts from eyeballing things: (a) It's not just (in)transitive, (b) it appears to rarely affect the last parameter, and (c) sometimes it appears before a label and sometimes after. I wish we could play around with their parser. --Bequw → τ 00:04, 24 August 2010 (UTC)

Declension tables

My declension tables and other tables are closing again. Opening them once isn’t setting them to "open" anymore. I still use Monobook. I tried to tick the expand-box option under Preferences, but it no longer accepts ticks. —Stephen 12:23, 25 August 2010 (UTC)

Fixed it. Deleted history and cookies and it’s working again. —Stephen 13:50, 25 August 2010 (UTC)

Some scripts

Some javascript tools I've been working on, available in WT:PREFS (and hopefully to be enabled by default at some point):

• User:Yair rand/wsedit.js ('Enable Wikisaurus editor.' in PREFS): For adding synonyms, antonyms, etc. to Wikisaurus entries. Also can edit glosses.
• User:Yair rand/usexeditor.js ('Enable example sentence editor.' in PREFS): For editing existing example sentences.
• User:Yair rand/adddefinition.js ('Add "Add definition" and "Add image" buttons to the toolbox.'): Adds "Add definition" and "Add image" buttons to the toolbox.

Some feedback would be great. --Yair rand (talk) 00:48, 27 August 2010 (UTC)

1. The example sentence editor didn't display text to the right of a comma in the edit box.
2. The +/- character is not suitable if this ever were to become some kind of default capability. DCDuring TALK 13:42, 2 September 2010 (UTC)

Template problem

Whenever the template {{de-verb form of}} is combined with another template which is put before it, no space is displayed between these two (here's an example, no space between "(colloquial)" and the form-of template). How can this be fixed? Longtrend 10:14, 27 August 2010 (UTC)

Damn, that's new to me, I can look but I suspect you'll need a more experienced user than me. Mglovesfun (talk) 22:20, 30 August 2010 (UTC)

Though having said that, perhaps it's to do with the categories. I'll vandalise a page and see what happens. Mglovesfun (talk) 22:22, 30 August 2010 (UTC)

Yes, put the categories after the form-of text. Mglovesfun (talk) 22:26, 30 August 2010 (UTC)

Yeah, I think that's the best approach in general. But in this case, I didn't want to mess too much with a functional, existent template, so I just "cheated": I changed Category:German verb forms (before which MediaWiki drops any linear whitespace) to <nowiki/>Category:German verb forms (before which it does not). —Ruakh_TALK 13:52, 31 August 2010 (UTC)

Thank you! Longtrend 14:07, 31 August 2010 (UTC)

French conjugation bot

Now that Wonderfool has been blocked... again, there's no French conjugation bot on Wiktionary. Could anyone (notably SemperBlotto, Nadando, Codecat and/or Prince Kassad) help me make one? I know there's a help file Help:Conjugation bot but that's about all I have right now. That and my brain. Mglovesfun (talk) 10:24, 30 August 2010 (UTC)

I've written MewBot to be easy to adapt to another language. If you know some Python, you should give it a try. If not, then I don't really know, other than trying to learn it... —CodeCat 14:57, 30 August 2010 (UTC)

Categories: "pages are in this category" should be "entries are in this category"

In Category:English idioms, for example, the following appears:

Entries in category “English idioms”

The following 197 pages are in this category, out of 6,116 total.

The term "pages" is confusing here, since it appears that it is referring to 197 pagefuls of idiom entries, when in fact it refers to the 197 entries being displayed on the current page. Thus "entries" would be a better choice of words than "pages", and would also be consistent with the lead-in text "Entries in category". Facts707 14:25, 30 August 2010 (UTC)

The text can be changed at MediaWiki:Category-article-count. Having it always say "entries" might cause some problems for categories of templates, project pages, or users, though. --Yair rand (talk) 20:43, 30 August 2010 (UTC)

Maybe There are $2 entries in this category, including the following $1.? Or heck, maybe just There are $2 entries in this category.? —Ruakh_TALK 22:11, 30 August 2010 (UTC)

Entries is a term we use for dictionary entries; using it for category entries (members of a category) would be confusing IMO. (Not all categories have only dictionary entries, of course.) Perhaps (based on Ruakh's suggestion above) "There are $2 members of this category, including the following $1:"?​—msh210℠ (talk) 15:12, 1 September 2010 (UTC)

Wiktionary wildcard search

Hi. I've noticed that both OneLook and Merriam-Webster have wildcards enabled in their search features, that is, * stands for a string of characters and ? for one character. Is there a way it could be implemented here? Thanks, ~ lexicógrafo | háblame ~ 14:43, 30 August 2010 (UTC)

They have wildcard search for headwords. I assume that such restricted wildcard search is what you have in mind. Next steps would be wildcard searches limited by language and by language and part-of-speech header or PoS category, or by language-PoS category. DCDuring TALK 15:09, 30 August 2010 (UTC)

Well yes, for headwords only. Although M-W at their unabridged site also has the ability to search with wildcards in definitions, etymologies, quotes and usage notes, if you so choose. ~ lexicógrafo | háblame ~ 15:17, 30 August 2010 (UTC)

For wildcards at the end (e.g. super*) you can use the Special page "All pages with prefix". Otherwise, there is no obvious facility. SemperBlotto 15:24, 30 August 2010 (UTC)

I wonder whether there is something on the toolserver at least, something analogous to CatScan. DCDuring TALK 15:44, 30 August 2010 (UTC)

Solution against the broken external links: back up the Internet

For two years, http://wikiwix.com allows the French Wikipedia to read the external sites, which URL are in its article, even if they're stopped, thanks to a link [Archive] after each URL. Today they're proposing to extend their backups to us, and it's working on the French Wiktionary. Could we please get a consensus to install it here? JackPotte 21:26, 31 August 2010 (UTC)

I *think* it sounds interesting and useful. Can you give us an example of what it looks like on fr.wikt? --Bequw → τ 03:59, 3 September 2010 (UTC)

Sure, do you see the reference at the bottom of fr:welcome? I've just added it and the archive link is already available. JackPotte 12:13, 3 September 2010 (UTC)

September 2010

Template talk:deftempboiler#"dot" parameter doesn't work properly.

—Ruakh_TALK 13:37, 1 September 2010 (UTC)

Beta

Unless I've made a bad click, Wiktionary has switched to beta, like Wikipedia has been for ages. Just a warning, last time I tried WT:ACCEL stopped working. Mglovesfun (talk) 19:00, 1 September 2010 (UTC)

For those of you have been doing so, you'll need to update the code to hide your logo and bring everything wlse upward to

#p-logo{display:none;}#mw-panel{top:0 !important}/*no wikt logo*/

and move your monobook.css/js files to vector.css/js.​—msh210℠ (talk) 19:51, 1 September 2010 (UTC)

Updated WT:PREFS. (FWIW I've haven't seen any ACCEL problems in my Vector usage.) --Bequw → τ 23:12, 1 September 2010 (UTC)

I have been getting warnings about losing my edits if I navigate away from the page, as when using wikilinks from a preview. (Which I do often.) That is new. Moreover, it seems to occur even when I turn off the new features. DCDuring TALK 23:23, 1 September 2010 (UTC)

Special:Preferences -> Editing -> Advanced -> " Warn me when I leave an edit page with unsaved changes ", right at the bottom. Every modern browser will remember what you typed in the box, making the preference somewhat pointless. Conrad.Irwin 23:28, 1 September 2010 (UTC)

Thanks. I hadn't remembered getting those warnings before or checking the box. DCDuring TALK 23:43, 1 September 2010 (UTC)

Yes, it's another new thing. Conrad.Irwin 23:44, 1 September 2010 (UTC)

• One effect of this on my setup is I lose one line or so of content in exchange for some white space at the top of the page. Does it work that way for everyone? I have spent an awful lot of time trying to squeeze content onto the first screen a user sees. DCDuring TALK 00:04, 2 September 2010 (UTC)

  Yes, for everyone. The sacrifices made in the name of aesthetics... Conrad.Irwin 00:07, 2 September 2010 (UTC)

  Do you mean the space below the "Personal tools" (my talk, my prefs, etc.) and above the tabs (Discussion, Edit, ...)? If so, yes. --Bequw → τ 05:52, 2 September 2010 (UTC)

Yes. I don't see the aesthetic benefit for Wiktionary. It seems OK for WP. DCDuring TALK 07:52, 2 September 2010 (UTC)

I'm sure it's possible to change it (at [[mediawiki:Vector.css]]), but I've fiddled with it just a little and haven't figured out how.​—msh210℠ (talk) 14:58, 2 September 2010 (UTC)

We could shorten the gap by 1 line (em) in Vector by adding

#left-navigation {top: 1.5em;}
#right-navigation {margin-top: 1.5em;}
/* Could also use #mw-page-base below */
#mw-head-base {height: 4em;}

What do people think? --Bequw → τ 03:38, 3 September 2010 (UTC)

Thank you. Looks good. I've added it to my own stylesheet, but definitely think it should be added to the sitewide Vector.css.​—msh210℠ (talk) 15:04, 3 September 2010 (UTC)

Implemented. --Bequw → τ 16:23, 3 September 2010 (UTC)

If anyone knows why the #p-tb and #p-lang links start farther to the right (have a wider left margin, or padding, or whatever) than the #p-navigation links do, or how to change that, I'd love to know, please.​—msh210℠ (talk) 15:50, 2 September 2010 (UTC)

Ah, it's from http://bits.wikimedia.org/w/extensions/UsabilityInitiative/css/combined.min.css, and I undid it with #mw-panel .portal .body {margin-left:0 !important}.​—msh210℠ (talk) 18:07, 2 September 2010 (UTC)

monospace fonts and beta

In beta with Firefox, the fonts in <source> tags fonts seem to be about 80% of the size they are in IE/monobook. Why?

Compare this

to this

I corrected it in my vector.css but what about the unregistered users? —Internoob (Disc•Cont) 22:04, 1 September 2010 (UTC)

If others agree with you that it's too small (as I do (Firefox)), we should be able to fix it in [[mediawiki:Vector.css]].​—msh210℠ (talk) 15:00, 2 September 2010 (UTC)

I have a hack now that targets every browser except any version of IE (up to and including IE8 for future reference):

pre[class]:not(#ie8-asdfasdfasdf) { font-size: 125%; /*Every browser but IE8 and less*/ }

It should work so long as no one does

<pre class="something" id="ie8-asdfasdfasdf">

=P

Could I have confirmation that users with Opera or Chrome experience this text shrinking? —Internoob (Disc•Cont) 19:33, 2 September 2010 (UTC)

MediaWiki:Vector.css is all well and good, but we should probably file a bug report, no? —Ruakh_TALK 23:08, 2 September 2010 (UTC)

It's already at Bug 20706. —Internoob (Disc•Cont) 16:31, 3 September 2010 (UTC)

FWIW, I see no difference in text size in Safari. --EncycloPetey 01:45, 3 September 2010 (UTC)

In my Safari 5 for Windows I can... —Internoob (Disc•Cont) 16:26, 3 September 2010 (UTC)

Duplication with enhanced editing toolbar

Anyone feel like tackling the duplication between the "enhanced editing toolbar" (Special:Preferences→Editing) and MediaWiki:Edittools? There's lots of overlap in symbols included in both. One solution would be to move all the symbol stuff up into the toolbar (which we can add to) for those that have it enable (can check a users wgWikiEditorPreferences variable). Stuff like "Templates" and "Headers" could then stay in the bottom, and are hopefully different enough than the symbols to avoid confusion. --Bequw → τ 23:50, 1 September 2010 (UTC)

Template:was wotd

The {{was wotd}} template is no longer displaying in the top right corner as it should. It displayed correctly in the Preview window, but not in pages themselves. See roil for an example where the template is displaying below the top line, alongside the TOC for the entry. This is likely a problem created by the new skin. --EncycloPetey 03:42, 2 September 2010 (UTC)

Should be OK now in both monobook & Vector. I've moved the styling to Mediawiki:Common.css and Mediawiki:Vector.css if someone wants to change the pixel offsets a bit. --Bequw → τ 05:04, 2 September 2010 (UTC)

It's still below the line in IE, and is now on the left side of the screen instead of the right. We've had it in the top right corner in the past; it's now on the left, below the headword and above the TOC. --EncycloPetey 18:43, 2 September 2010 (UTC)

As I changed a few files, I saw this exact behavior (in IE 8 & FF 3.6) transitionally until my browser finally got all the new files. This *should* go away once the caches (browser & possibly servers) are refreshed. --Bequw → τ 20:15, 2 September 2010 (UTC)

Should it? It's displaying in the wrong location in Safari now as well. It wasn't in that location before, so the cache has changed, presumably, but is not correct. --EncycloPetey 01:42, 3 September 2010 (UTC)

What skin are you using? Is it there when you're logged out? Do other people see this problem? If so, what's your setup (skin & browser) and do you see it logged-out as well. --Bequw → τ 03:06, 3 September 2010 (UTC)

Bot for disambiguation "see also" links

Does anyone have the skill (and time) to write a bot that would complete (and keep complete) all disambiguation "see also" templates. For example, (deprecated template usage) kare points to several other entries, but (deprecated template usage) käre doesn't. SemperBlotto 11:01, 2 September 2010 (UTC)

We should form a consensus on what characters merit disambiguation first. I've created Wiktionary:Character disambiguation, starting with the data Unicode gives on decomposition. Once everyone is happy with the list a bot can be run. Nadando 19:27, 2 September 2010 (UTC)

I'm not sure its best that necessarily if A links to B then B links to A. The purpose (if I understand it correctly) of {{also}} is to get people to the page they meant rather than the page they types: i.e., for mistypings, whether accidentally or due to a lacking keyboard. But will anyone ever type in cười when he means cuoi? If not, then why link to [[cuoi]] atop [[cười]]? (But we do need the link in the other direction.)​—msh210℠ (talk) 17:29, 3 September 2010 (UTC)

skin customization question

How do I make it so that links show up better? I just switched to the Modern skin and the links are almost the same color as the rest of the text. — lexicógrafo | háblame — 17:06, 3 September 2010 (UTC)

Edit [[special:mypage/modern.css]], adding stuff like

a{color:#002bb8}
a:visited{color:#5a3696}
a:active{color:#faa700}
a.new,#p-personal a.new{color:#ba0000}
a.new:visited,#p-personal a.new:visited{color:#a55858}
#bodyContent a.extiw,#bodyContent a.extiw:active,#bodyContent a.external{color:#36b}

There, the first line is for links, the second for visited links, the third for links while they're being clicked, the fourth for links to pages that don't yet exist, the fifth for visited links to pages that don't yet exist, and the sixth for links to outside of English Wiktionary. The color is specified as #XXXXXX (or #XXX) for X a hexadecimal digit; fiddle with colors until you find what you like. Google:rgb color can help you decide. (The colors above are from the "monobook" skin.)​—msh210℠ (talk) 17:21, 3 September 2010 (UTC)

thanks — lexicógrafo | háblame — 17:23, 3 September 2010 (UTC)