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)

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 ].​—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)

​—msh210℠ (talk) 14:07, 6 July 2010 (UTC)

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)

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 ]  :-) .​—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)

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)

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.orghttps://dictious.com/en/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.orghttps://dictious.com/en/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 (nautical) or (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 (nautical) , (aviation), (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)

(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}}{{context|poker|lang=und}}. 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 τρέχω (trékhō) (it doesn't, actually it's from Afrikaans). Let's also assume that Ancient Greek τρέχω (trékhō) has most of the same senses that Greek τρέχω (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 τρέχω (trékhō, “run”)". I'm assuming that most folks aren't going to know what τρέχω (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 . 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)

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)

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

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)

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|-}}? {{subst:da}}? 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)

Sorry about all those guys. It was a shorthanded method of generating the language name (e.g. English, Latin, etc.) w/o having to write it out. For these, could we not simply substitute the {{da}} with text (i.e. "Danish"). This would isolate these instances from all others while producing the same results. Leasnam 21:49, 13 September 2010 (UTC)

Ironically, 'Danish' and {{da}} are both 6 characters... —CodeCat 23:24, 13 September 2010 (UTC)

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

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

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)

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)

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)

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 .

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

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 , I changed it myself two days ago, when I read Ethnologue book , 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)

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)

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)

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.

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)

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)

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)

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)

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 .​—msh210℠ (talk) 18:11, 2 August 2010 (UTC)

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

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|]}}), and shouldn't be re-linkified (since ]#English|]]] works about as well as you'd expect). A better test is {{#if:{{isValidPageName|{{{1|}}}}}}}. —Ruakh_TALK 00:10, 31 July 2010 (UTC)

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)

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)