text:
Wiktionary:Beer parlour/2010/June

=June 2010=

WT:Abuse reports revamping
Hello. After reviewing the Abuse reports project here at Wiktionary, it seems to me that is has largely died out. The same project on the English Wikipedia (WP:ABUSE) was in the same state before a revamp was done in late 2009. I believe it would be beneficial for the Wiktionary community to revive the project and revamp it. The project has not been revised since 2006, so I would like to gain the permission to revamp it and make it efficient again. I plan to create a better page and integrate it with the English Wikipedia project, but of course Wikitionary's project would stay independent and function by itself. This would be a good time, as the English Wikipedia is currently creating an interface that would make the process much more efficient. An important part of this revamp would be to rename the project to Abuse response, so it may be integrated with the interface and other systems that we already have set up. Any comments/criticisms of this proposal? Netalarm 02:37, 1 June 2010 (UTC)
 * Why integrate it with Wikipedia? That's a completely separate project, with different admins, policies, procedures, goals, etc.  I also find that abuse reports there are often not taken seriously, or else are taken too seriously.  That's not something I'd like to see propogate to here.  In any case, what "Abuse reports project" are you referring to? --EncycloPetey 03:00, 1 June 2010 (UTC)
 * Integration would offer a central interface for Wiktionary to manage cases (one that's already being build at ENWP). Another important reason is that serious abuse is often times cross project, thus requiring intervention from all the projects involved. If Wiktionary was to develop such a project on its own, it would be quite difficult to integrate it into the same project at Wikipedia. I understand that there are reservations regarding integration with Wikipedia, but I believe the nature of the abuse reports project requires that it be cross project. As I have stated, they would operate independently, but with mutual access to information (and the interface, mailing list) so a better response may be formulated against repeat vandals. I'm referring to Abuse reports. Just a note, my main point is that the project here needs revamping, even without integration with Wikipedia. Netalarm 03:13, 1 June 2010 (UTC)
 * As we haven't needed that page since 2006, it seems better to just mark it with and get on with more important things. I disagree with your assertion that most things are cross-project, in reality dedicated vandals mainly target one project (or occasionally a handful), and we are not often in the list.  If it were necessary to have a way of doing global abuse reports, you'd be better to set up a project at meta rather than on wikipedia - perhaps as an extension to Global blocking - so that you could deal with things wikimedia-wide without requiring intervention from everyone. Conrad.Irwin 08:35, 1 June 2010 (UTC)
 * Sounds good to me (what Conrad said). What do our checkusers think? —msh210℠ 15:21, 1 June 2010 (UTC)
 * Ok, sounds good to me too. The original reason for starting up a project at WT was to allow for greater community input and direction, so it wouldn't been seen as a project imposed on WT by WP. And this really wasn't about "global" abuse reports, it was more of a individual project for each project so it may be operated independently by each project. Anyway, thanks for your input and I respect the decisions made here, so there won't be a revamping of this project. Just a friendly reminder, it would be quite difficult for us to integrate new projects once we're done, so please have that in mind when commenting. Thanks. Netalarm 19:31, 1 June 2010 (UTC)

 * I wouldn't call the Abuse Reports inactive per se, we just don't need them often. In the 5 years I have been here we have only had four cases which warranted sending abuse reports to an ISP.  In three out of four of those cases (at least) the abuse was taking place on multiple projects simultaneously, only one of the cases was specific to en.wikt.  There is a lot of inter-project communication which goes on about cross-wiki abuse anyway, on various mailing lists and in various IRC channels; I am not sure that the publication of the abuse reports or the specific details of abuse investigations are necessary or beneficial at this point.  I think that the Stewards who focus on anti-vandal stuff are quite diligent and thorough about it; they have all of the salient details about all of the prolific vandals memorized (seemingly) and I only have to mention a /16 or part of a user name to them and they can tell me which public library computer the vandal favors.  No need to mess with a system that Big Brotherly ;) -  19:54, 1 June 2010 (UTC)

 * This is going to be abused like - oh I really shouldn't say that. So this is going to be abused. Like Michael Vick's dogs. — [ R·I·C ] opiaterein — 15:41, 2 June 2010 (UTC)

Votes/pl-2010-06/WMF jargon accepted when it meets CFI
Forgot about this. Input need, tyvm. Mglovesfun (talk) 20:45, 10 June 2010 (UTC)

What about rollback?
Hi. I got rollback some time ago, after asking on IRC, but it was removed today, I'm not sure what does determines this, but I think I could be very useful using rollback, and I have quickly removed vandalism. So, please let me know what are your policies on this :) --Diego Grez 00:50, 11 June 2010 (UTC)
 * If you're going to be using rollback, the chances are you'll need delete too; though you've perhaps not been round long enough to be made an admin yet. I'd be happy to grant you rollback, and, I think any whitelisted user who asks for it (WT:BP seems the best venue until there's a lot of traffic) - seeing as there are already global rollbackers over whom we have no control it's not as though we need any stringent requirements. Conrad.Irwin 00:56, 11 June 2010 (UTC)

 * Well, I think the point is that, up until Diego, we had no rollbackers, at all. If we're going to start making them, fine, it seems like something that could be useful.  But I'd say we should come up with some system, perhaps another page similar to WT:WL, with more or less the same procedures.  I wonder if just using the BP would be.....inappropriate.  -Atelaes λάλει ἐμοί 01:16, 11 June 2010 (UTC)

 * A page like WL would be a good idea. In the mean time, I've given him rollback again, because there's truly no reason to remove it now that we are discussing it and sentiment has been expressed that users who deserve rollback can have it. --Neskaya contribs–talk? 03:08, 11 June 2010 (UTC)  And oops, I made a typo.  I seem to be good at that today.

 * But we've not discussed who deserves it. I would say that Diego doesn't.  Quite frankly, I sort of wonder if he was given auto-patrol a little early.  He's still quite new.  In any case, I would probably defer a motion for him to be given rollback rights.  Again, this is not because he's a bad editor, he seems to have grasped our syntax rather quickly, and responds to criticisms well.  I just think it's too much, too soon.  -Atelaes λάλει ἐμοί 04:19, 11 June 2010 (UTC)

Prolly. I just forget the Etymology templates ;-b I'm learning, and I learn quickly :-) --Diego Grez 04:39, 11 June 2010 (UTC)

 * Erm, everyone knows that "rollback" is a non-tool tool right? It doesn't do anything other than make an already available action more efficient and its behavior can be entirely implemented in a user's .js file without any sort of user rights change?  As far as I am concerned anyone and everyone can have it.  -  02:31, 19 June 2010 (UTC)

Getting Commons transwiki capabilities
Someone noted some interesting JS they've got at commons here, and so I was going to import it and try it out. However, we don't have Commons enabled for import here, so I'm gonna file a bug report to get it enabled. I figure that this is a fairly trivial thing, so I'm not even going to wait for consensus, but I thought I should at least note it here. I figure everyone with import capability (admins, I presume?) should have the good sense to know what constitutes a valid Commons transwiki and what doesn't (i.e. images shouldn't be transwikied). -Atelaes λάλει ἐμοί 04:48, 11 June 2010 (UTC)

Flood flag
The vote passed and the extension has been installed. I've started WT:Requests for flood flag with what I was the consensus. Please improve the page and even request the flag for some edits (thats how we really iron out the policy kinks). --Bequw → τ 07:52, 11 June 2010 (UTC)

First he illegally deleted the entry [[I have a big penis]] which is still under a RFD with an edit summary: "only people who have a penis may create this entry. sorry, but try again next time"

I asked him to apologize on which he responded: "Umm, stating the truth is shameful?"

Then I raised a one day block. He immediately unblocked himself and blocked me indefinitely in "retaliation".

I urge other admins to review his actions. --Ivan Štambuk 21:49, 14 June 2010 (UTC)

 * I imagine he is frustrated as everyone else at the amount of nonsense being done in the name of the phrase book. I imagine his comment was intended as a joke - as was his block; though we are still lacking a reliable way to indicate this to each other. I suggest an apology on both sides, or just a bit of lightening up... Conrad.Irwin 21:56, 14 June 2010 (UTC)

 * A joke, right...why exactly I'm not convinced. --Ivan Štambuk 22:08, 14 June 2010 (UTC)
 * I don't know why you're not convinced - his deletion comment was clearly intended as humour as it is patently untrue. The response to your request for an apology, as a reference to that comment, must therefore also be humour - albeit in poor taste (much like many perceive the entry itself, perhaps there was humour on two levels). As to a block of 100000 years, given that the canonical method of expressing that intent would be "indefinite" it is obviously intended to be taken less-than-seriously; besides as he has just unblocked himself, he likely expects you to do the same. You might not have enjoyed or understood the joke, in which case he should apologise, as I said, but I definitely don't see a serious problem here. Conrad.Irwin 22:12, 14 June 2010 (UTC)
 * No, you're defending him so that he can gleefully play the same stupid f*** games the next time. --Ivan Štambuk 22:16, 14 June 2010 (UTC)
 * I don't understand you at all, could you please explain why you think this was not intended as a joke? Conrad.Irwin 22:22, 14 June 2010 (UTC)
 * It was an insult on my manhood. Unless he is gay or female, it cannot approve of it. --Ivan Štambuk 22:36, 14 June 2010 (UTC)
 * Ah, I think this is a cultural issue - such things are not considered outrageous among male youths in my country. Conrad.Irwin 22:42, 14 June 2010 (UTC)
 * Psh, if you were upset and someone suggested you get the sand out of your vagina, I doubt you'd find it agreeable. :P — [ R·I·C ] opiaterein — 15:36, 15 June 2010 (UTC)

It very much does seem to have been done on the joking level of interaction, here, from what I understand of this. --Neskaya … gawonisgv? 22:34, 14 June 2010 (UTC)

 * Why is it ok for PK to joke about someone not having a cock, but not ok for Vahag to joke about jews being evil? — [ R·I·C ] opiaterein — 15:36, 15 June 2010 (UTC)
 * Anti-Semetic jokes, no matter what the context, simply aren't okay. I'm sure you understand this, and if you don't understand … well. —Neskaya … gawonisgv? 05:47, 16 June 2010 (UTC)
 * Um...because not having a cock isn't evil? < class="latinx">Ƿidsiþ 15:42, 15 June 2010 (UTC)
 * This has nothing to do with the biological function of a male reproductive organ. By stating that the interlocutor "lacks cock", you're implying that he's a "pussy". In Western cultures with broken societal fabric this probably isn't much of a problem though. You blocked Vahag for a trivial joke, yet you shamefully ignore obvious insults in PK's responses. Unless you're gay or a feminist, that makes you a hypocrite. --Ivan Štambuk 15:51, 15 June 2010 (UTC)
 * I'm really not sure that I understand how any anti-Semetic joke is trivial. Unless of course you are purposefully attempting to trivialise it. —Neskaya … gawonisgv? 05:49, 16 June 2010 (UTC)
 * I'm trying to figure out what exactly was anti-Semitic here, but I can't really see. The funniest jokes are regularly the most politically incorrect ones, made by mocking stereotypes and prejudices. But I agree, that they're not appropriate here, on a public forum. --Ivan Štambuk 13:54, 16 June 2010 (UTC)
 * Well I am a feminist. Anyway, Kassad was wrong to block you indefinitely and his comment has clearly insulted you, which is regrettable. But I don't know what exactly you want the rest of us to do about it. If he continues to make inappropriate comments I'm sure that the community will get increasingly intolerant of it, but I suspect that he didn't realise quite how badly you would take it. Perhaps we can all agree to apologise and get back to work? < class="latinx">Ƿidsiþ 15:54, 15 June 2010 (UTC)
 * It's important to raise awareness so that similar incidents don't escalate in the future. --Ivan Štambuk 15:59, 15 June 2010 (UTC)

In times where people are unable to accept decisions, instead opting to block each other and lose all sanity, people who intend to seriously contribute to a dictionary should look for a different place. -- Prince Kassad 17:29, 15 June 2010 (UTC)
 * What is not sane in Vahagn's contributions? They are irrepræhensible, at least those in the main namespace. The uſer hight Bogorm converſation 17:36, 15 June 2010 (UTC)

Just have each party apologize to each other and let's be done with this instead of raising a big drama fest. Razorflame 17:37, 15 June 2010 (UTC)

 * My point is: Look what you people are doing there. Fighting against each other, creating obvious joke entries to mock the others, entire hate campaigns. That is not what a civilized community should be like. In fact, that's not what any community should be like.

In the last few weeks, you guys have seriously deteriorated. I have no idea why. I don't want to know, either. The point is, somehow people seem to be upset with the current rules, and use that to abuse loopholes (see: Phrasebook). Instead of discussing about the matter in a civilized manner, like what Help:Interacting with humans (hint hint: bookmark that page, it contains lots of valuable information) describes, you block each other to see who has the most power and will to go against everyone else. As well as the Block button, the Delete function is used in excess to push your point of view against everyone else, which results in endless wheelwars. People who oppose will be subject to very vulgar insults by the other people.

It seems to me you have no intention at all to work peacefully with each other. Instead, your sole reason to be here is to destroy the whole heart of this project. We have been giving out the admin rights too quickly and too easily in the past, and this is what it has led to. I wish you would learn from the mistakes and start anew, but I believe all hope is lost. -- Prince Kassad 17:49, 15 June 2010 (UTC)
 * And I thought hitherto I was the staunchest pessimist here. Your depiction surpassed my expectations, though. The uſer hight Bogorm converſation 17:54, 15 June 2010 (UTC)

 * Phrasebook discussion on [[I have a big penis]] was very productive IMHO, despite the entry being repeatedly deleted while the discussion was still ongoing.
 * I have no idea what you mean by "you people", "abusing loopholes", "blocking each other", "vulgar insults" and "destroy the whole heart of this project". These are absurd accusations. If you have issues with my conduct, in particular, you are invited to take it to my talkpage, like I did on yours. --Ivan Štambuk 13:21, 16 June 2010 (UTC)

Phrasebook: Common occurrences
Regardless of which specific entries merit inclusion in the phrasebook, where they should be placed and how incomplete is our related policy, "commonness" and "usefulness" have been considered reasonable criteria for inclusion. This have leaded to some community tendencies and to my questions:

 * Google hits have been consistently used as proof of commonness. Are they enough? The fact that "I've been raped" yields 921.000 Google results makes it deserve to be defined in I've been raped (or Phrasebook:I've been raped, etc.)? Should I'm allergic to milk be deleted simply because I've found only 51.400 hits?
 * In addition, personal experience has been used as proof of usefulness. If a person believes that allergy to milk is common, it may be an argument in favor of keeping I'm allergic to milk. Apparently, if a Wiktionary editor was shot yesterday, he may want to use this fact as argument to keep I've been shot.

I am pondering on the possibility that usefulness and commonness be comproved by third-party researches, if possible. Since we have I'm allergic to milk, do we want to know the twenty most common allergies to define their related phrases? Since we have I've been raped, do we want to know the fifty most common crimes for the same reason?

If we want a phrasebook, and a considerably random list like this says that "Offensive words in public place" and "Trespass on occupied property" are among the most common crimes somewhere, do we want to define I've been offended by words and my property's been trespassed? If not, why not? --Daniel. 03:03, 15 June 2010 (UTC)
 * I think part of the answer to this will come from the answer to one of the questions I proposed earlier, which has so far not had any response. The question is "Who is the target audience?" If the target audience is tourists or business travellers, then "my property has been trespassed" is not something that will be useful for almost all tourists. If the target audience is invading foreign military soldiers, then it wont be at all useful. If the target audience are language learners, then I can see an argument being made for its usefulness (e.g. for ex-pats). Until we know who we are aiming at then I don't think we can start working out exactly what our criteria are, let alone what objective measures we use to back them up. Thryduulf (talk) 08:07, 15 June 2010 (UTC)

 * I believe that pages to help tourists are already being created and maintained, like do you accept American dollars, where does this train go and Appendix:English phrasebook/Travel. As as exception, entries about specific places, like can you direct me to the Louvre, have not been created yet and apparently will not be.

 * For language learners, the most natural entries that I think of are simple sum-of-parts, like I am, you are, he is, she is, it is, we are, they are, I have, you have, he has, she has, it has, I do, she does and so on. --Daniel. 13:43, 15 June 2010 (UTC)

 * I think the target audience should be: Everyone, everywhere. — [ R·I·C ] opiaterein — 15:32, 15 June 2010 (UTC)
 * Things like Sorry for the mess, I couldn't control the guinea pigs are quite conceivably useful to someone somewhere, but they are clearly not useful to enough people to include. Everyone, everywhere is a naive approach that will not work. Conrad.Irwin 15:35, 15 June 2010 (UTC)
 * I can see merit in this highly subjective suggestion of a phrasebook for "everyone, everywhere". However, would it have limits? Or do you want to introduce a set of infinite sentences? --Daniel. 15:45, 15 June 2010 (UTC)
 * I say include every meaningful conversational phrase that has >50k hits on top 5 search engines for the respective language. --Ivan Štambuk 15:55, 15 June 2010 (UTC)
 * "he's not dead", for example? --Daniel. 16:02, 15 June 2010 (UTC)
 * We do have he's unconscious. — <font face="Lucida console">[ R·I·C ] opiaterein — 16:23, 15 June 2010 (UTC)
 * Yes. All of the "emergency speech" should be inside phrasebook by default. --Ivan Štambuk 16:42, 15 June 2010 (UTC)
 * It's pretty easy to introduce a requirement for simplicity without making up some ridiculous examples of what we might have otherwise...lol. — <font face="Lucida console">[ R·I·C ] opiaterein — 16:23, 15 June 2010 (UTC)
 * Correct. The requirement of "simplicity" is already stated at PB, therefore "sorry for the mess, I couldn't control the guinea pigs" is not desirable due to its complexity; on the other hand, "I'm sorry" is simple enough to be defined here. --Daniel. 16:40, 15 June 2010 (UTC)
 * Is this quantifiable? I'm sorry for the mess doesn't seem any more complicated than I need a sanitary napkin to me. Conrad.Irwin 16:41, 15 June 2010 (UTC)
 * In my opinion, I'm sorry for the mess is more complex (and not more complicated) than I need a sanitary napkin, because the former has a preposition. --Daniel. 16:51, 15 June 2010 (UTC)

How could the Phrasebook look like - a proposal
First, a few notions:
 * 1) A user of a Phrasebook would most likely be interested in finding translations from English to one language and vice versa at a time.
 * 2) This is an English dictionary. We do not necessarily need to serve e.g. the Albanian - Finnish - Albanian translation needs on this Wiki.
 * 3) The user of a Phrasebook is likely to search phrases on a topical basis, not alphabetically.
 * 4) There are so many ways of expressing the idea of e.g. wanting a cup of coffee that we probably don't want a Phrasebook that accommodates them all.
 * 5) There are so many things that a person may want, need or have that it's impossible to produce a manageable (=useful for the purpose of finding what you need) Phrasebook that fits them all in.

One possible approach could be this:
 * 1) First, a list of the English entries that we want in Phrasebook should be compiled, divided in sections and subsections according to the context. Let's call it "mother list". And, referring to the discussion on "I have a big penis" - yes, there would be a section for sex.
 * 2) When the mother list looks good enough, say, after a few months, it should be locked and new entries would only be allowed through similar process that we now have for verifying and deleting entries - same type of process, but reversed.
 * 3) Then 350+ (the number of languages in English Wiktionary) "daughter tables" would be created, each with two columns, the one on the left for English and the other for another language. The system should be designed so that an addition to the mother list automatically creates a new row to each of the daughter tables and adds the English text to the left column.
 * 4) Last, the foreign language editors would fill in the translations into the daughter tables.

I realize that this isn't necessarily a simple programming task, but we may have wizards out there somewhere who can do it. --Hekaheka 17:35, 15 June 2010 (UTC)

 * As Daniel and I have been working on, you can currently look up phrasebook entries both alphabetically and by topic. I don't like your idea of limiting the phrasebook. We didn't draw up any kind of plan for normal entries as far as I'm aware. Just let the phrasebook grow reasonably. — <font face="Lucida console">[ R·I·C ] opiaterein — 00:35, 16 June 2010 (UTC)

 * I support the development of a "mother list", since I can understand it as an effort to gather information on how to maintain, improve and limit the phrasebook. However, I believe that the mother list shouldn't ever be effectively "locked". Apparently, that action would be a long-term contract stating that needs, languages, crimes, etc., as recognized by different cultures and Wiktionary editors, would not change over time, which would be an evidently incorrect assumption. --Daniel. 02:02, 16 June 2010 (UTC)

 * Weren't we already developing such a list? lol — <font face="Lucida console">[ R·I·C ] opiaterein — 12:33, 16 June 2010 (UTC)

 * Topical categorization seems reasonable. Phrases that pertain to the same topic should appear on the same page. However, I'd like to see it implemented in a way that enables a user to choose a destination language from a drop-down list, and only translations in the chosen language are displayed inline. That way we get both the centralized management and the multilingual clutter reduction.
 * And please let us dispense with the sexist term mother list. --Ivan Štambuk 13:40, 16 June 2010 (UTC)

 * I'm slightly confused by this, but it gives me the idea to link to non-English appendices through the template in the same way that (for example) Category:Albanian nouns links to its sub-categories. Like Appendix:English phrasebook/Religion will have a list of other language's appendices if they exist. Tada~aa — <font face="Lucida console">[ R·I·C ] opiaterein — 23:09, 16 June 2010 (UTC)

 * Actually, we can already choose translation languages for all translations, regardless of whether they're phrasebook or not. See User:Atelaes/Customization/Translations.  It's not quite ready to be fed to all users yet, but I suspect we can get it there in relatively short order.  Also, I don't think "mother list" is really sexist.  "mother" as a collocating term is often used in a variety of contexts to describe something which contains or is greater than.  -Atelaes λάλει ἐμοί 13:50, 16 June 2010 (UTC)

Archiving.
I noticed that all of May got archived recently (Daniel, I think). While I appreciate that someone's doing archiving besides my occasional use of the archive script, it's still June. Some of those discussions were still active, and I think one or two of them were even useful. I'd like to ask that no one do that mass-archiving of a month in the future until at least the end of the next month (let's not be too hasty), so if you were going to archive discussions from May, you'd archive them at the very end of June or the beginning of July, and so on and so forth. This is a basic amount of time to make sure that all editors who maybe only sign on once to twice a month get to at least read all the discussions which they wish to. Individual discussions that close in the time between each archiving can of course be archived with the script in admin prefs, but if we can give each month at least the entirety of the following month, I feel it would be a positive step. Incidentally, I do use the Beer Parlour archive script to archive discussions, and should be able to continue doing this for the foreseeable future. This means that I'm volunteering, once again, to do the archiving of the Beer Parlour, and I shouldn't disappear this time. Last time, I got sick and had the semester, but the situation has changed. Although I rarely participate in discussions, archiving them has been one of the ways I make myself actually keep up with said discussions. —Neskaya … gawonisgv? 05:42, 16 June 2010 (UTC)
 * I've been wondering the same thing myself, and I agree with your suggestion. In the worst case, we might be archiving a discussion started on 31 May a day later... —CodeCat 09:38, 16 June 2010 (UTC)

 * What'd be nice is if we had a bot which could tell when the last comment was posted on a discussion, and archived it perhaps a month later. Occasionally, conversations can go on for quite some time.  Also, I don't really like monkeying with the "archive" button on every thread.  Props to Conrad for some sweet coding, but I think a bot is a better approach to this task.  -Atelaes λάλει ἐμοί 12:28, 16 June 2010 (UTC)
 * w:User:ClueBot III operated by w:user:Cobi does exactly this for the English Wikipedia. Rather than reinventing the wheel it would probably make sense to use it (or a copy of it run by a local bot operator) here as well. Thryduulf (talk) 16:22, 16 June 2010 (UTC)
 * Nice find, Thryduulf! Just what we need. —CodeCat 19:45, 16 June 2010 (UTC) Repositioned and reindented to be under Thryduulf. —msh210℠ 19:53, 16 June 2010 (UTC)
 * Yep. With source, too! Can we use (some modification of) this? Please? —msh210℠ 19:53, 16 June 2010 (UTC)

 * Not archiving until after the month after the discussion started (what Neskaya said) sounds good. Not archiving for a month after the last post to a discussion sounds even better. —msh210℠ 15:03, 16 June 2010 (UTC)

 * Mainly, I want to make sure that if someone only signs on occasionally they don't end up missing whole chunks of discussion. If someone wants to run a bot here that can actually archive discussions a whole month and a bit after they end, that'd be great. --Neskaya … gawonisgv? 20:44, 16 June 2010 (UTC)

 * I am happy to run a bot, though I prefer the javascript solution in WT:PREFS which adds archive links beside the edit links for each section on this page. Obviously, there's not much to do here for a few months yet. Conrad.Irwin 14:01, 17 June 2010 (UTC)

 * As I said, I have the javascript solution turned on and am more than happy to deal with the archiving for the forseeable future, so I figure that works. If it does turn out that it's more of a responsibility than I can handle, I'll definitely let someone know.  And oops, I keep forgetting to sign my name to things.  I don't think that I've had enough coffee yet. --Neskaya … gawonisgv? 20:19, 17 June 2010 (UTC)

Whatever method we use for archiving (and I generally support the bot option), when it comes to archiving the tearoom we need to remove the tag on the entry under discussion. At present these hang around long after the discussion either reaches a conclusion or fizzles out (if it even started, unlike a couple of discussions I've initiated recently) - for example yardstick: was discussed in the tearoom in April 2008 but the tag saying the entry is under discussion stayed until I removed it yesterday. Where entries don't clearly come to a conclusion (on any of the discussion boards) I think they should be relisted somehow until they do, rather than archived having achieved nothing. Thryduulf (talk) 00:26, 21 June 2010 (UTC)

Formal proposal on foreign contractions.
Pursuant to the ongoing deletion discussion of n'avais, I propose the following: The reason is that someone seeing the contracted form might look up the word (e.g. fubar) sans internal punctuation, and come to the wrong word by mistake; whereas, someone looking up a word sans punctuation for which no such word exists (e.g. fubarangina) will merely get a results list with the redirect to ubarangina on top. In the case at issue, since there is no word navais, we would redirect n'avais to avais, while we would keep n'ai because there is nai. Perhaps exceptions could be made on a case by case basis where the foreign contraction is very similar to a common word, but off by a letter somewhere, or where the foreign contraction is so highly compounded that it would be difficult for the English-speaking reader to figure out what the contraction means from looking at the definition of the foreign root (as with n'y a-t-il). Cheers. <i style="background:lightgreen">bd2412</i> T 15:50, 16 June 2010 (UTC)
 * 1) Wherever a foreign contraction containing punctuation f'ubar could be confused with single unpunctuated word fubar, we include the contraction (presuming, of course, that the contraction itself meets the CFI).
 * 2) Wherever a foreign contraction containing punctuation f'ubarangina has no single unpunctuated word fubarangina with which it could be confused, we redirect f'ubarangina to the foreign root ubarangina.

 * What you propose might be applicable to contractions including an apostrophe, but not to contractions such as du in French or no in Portuguese. And, obviously, when a contraction, even with an apostrophe, is considered as a word in the language, it must be kept as a normal page (e.g. presqu’île). Lmaltier 19:58, 16 June 2010 (UTC)
 * I agree completely. I'll amend the proposal accordingly. <i style="background:lightgreen">bd2412</i> T 20:34, 16 June 2010 (UTC)
 * Perhaps we could limit the application of this proposal to foreign contractions formed by adding one initial letter to a word? The idea is to avoid having simple collocations like mother's, as reflected in words like j'apprendre and n'avais. I do think these should appear as examples on apprendre and avais. <i style="background:lightgreen">bd2412</i> T 20:40, 16 June 2010 (UTC)
 * As I see it, problems only really occur if one of the elements of such a contraction is part of speech that contains a relaitvely large number of words, and can be easily replaced by many other words from that type of POS. That is, nouns, adjectives, verbs, adverbs and so on. If the number of replacements is small (as with prepositions, conjunctions, pronouns and such) it's not as much of an issue to list them all here. So that gives us an easy and impartial rule that makes perfect sense to anyone using any language. —CodeCat 22:08, 16 June 2010 (UTC)
 * Note that j'apprendre does not exist, and that j'apprends or n'avais are not words, they are always considered as composed of two words (unlike du, entr'apercevoir or presqu'île, which are contractions, but these contractions are words). Lmaltier 16:54, 17 June 2010 (UTC)
 * I'd argue that defendernos is not a word either, it just looks like one. So does j'apprends. It would be lovely if it were that simple, then this conversation would not exist! Mglovesfun (talk) 17:53, 17 June 2010 (UTC)
 * For a dictionary aimed at English speakers, defendernos is a word in the practical sense that a reader trying to understand something in a foreign language will perceive it as a word. We should cater to that perception. For things such as j'apprends or n'avais, with no potential japprends or navais to muddle it with, the English speaker's needs will be met by being redirected to apprends (if an example on the page shows how j'apprends means "I learn") and avais (if an example on the page shows how n'avais means the negation of having). <i style="background:lightgreen">bd2412</i> T 14:29, 18 June 2010 (UTC)

Look of references
(Sorry this is not about phrasebooks:) When listing references, the tag, and it might even encourage them to use the correct brackety template. The main problem would be that some would be green, while others would remain blue; as they are links. Conrad.Irwin 10:24, 22 June 2010 (UTC)

 * I am for green without brackets. We can keep italic non-green with brackets format for such context tags as (of an industry or other field) in big. --Vahagn Petrosyan 10:54, 22 June 2010 (UTC)

 * I'm definitely against green without brackets as distinguishing things solely by colour is really not a good idea for anyone who is colour blind, uses a screen reader, uses a monochrome display, etc. Thryduulf (talk) 11:25, 22 June 2010 (UTC)
 * There wouldn't be much of a difference for them, would it? Anyway, these people constitute insignificant minority, and we could set up a PREFS option especially for them. The defaults must be visually optimized for people with normal visual abilities. --Ivan Štambuk 12:18, 22 June 2010 (UTC)

 * I'm sorry, ~20% of the global population is 'an insignificant minority'? (That's about 1.2 billion people--hardly insignificant.) --Preservation 17:35, 24 June 2010 (UTC)

I support the weak, faint color + balloon (bubble help) like in the Russian Wiktionary, see e.g. the meaning (8.) in the word ru:маленький. There is some small difference in colors: one for predefined labels, another color is for free text labels. -- Andrew Krizhanovsky 11:56, 22 June 2010 (UTC)

 * +1. I'm very accustomed to green context labels from my much beloved Oxford Advanced Learner's. Moreover, italic is then superfluous. --Ivan Štambuk 12:18, 22 June 2010 (UTC)
 * Italic is also needed for (1) monochrome devices or (2) peoples with disabilities. :( -- Andrew Krizhanovsky 12:53, 22 June 2010 (UTC)
 * Not if we keep the brackets. Conrad.Irwin 12:54, 22 June 2010 (UTC)
 * I'd like to cast a (tentative) vote for the Russian approach of using a colored background against the template (like the "highlighter" feature in Microsoft Word). And I also like the sophistication of potentially using different hues (e.g light green vs. light blue) for different types of context templates... --达伟 19:12, 23 June 2010 (UTC)

 * Coloured backgrounds can be bad for a lot of people. Not only people with visual impairments, but people prone to migraines, people with epilepsy … I would prefer at least at first that this become a pref for people who want it.  I would definitely at least prefer the green to having something hilighted though, but we have to remember that colourblindness is not a small and insignificant portion of the population.  We should at least try for the least inaccessible option, yeah? —Neskaya … gawonisgv? 02:03, 24 June 2010 (UTC)

 * You have a point there but I vote for the green colours. Green colour is soothing. If we could make it much darker, then it won't affect eyes of people with visual impairments but still different from the surrounding text. It can't be that bad, anyway, otherwise people wouldn't use Internet and in particular Wiktionary at all - there's always plenty of colour on web pages. What about blue links? Aren't they coloured. --Anatoli 02:11, 24 June 2010 (UTC)

In general, anything involving colour should be user-defined, not hard-bound to a specific colour like this proposal suggests. WT:PREFS would be a good place to locate such a preference, at least for now. My biggest issue with the current proposal, aside from colour, is that people seem to think accessibility is inconsequential (it's not) and thus not worth bothering over (it is entirely something that needs to be addressed). Unfortunately, I think a number of people here wouldn't realise just how important accessibility is until they lost an eye. Preservation 03:04, 24 June 2010 (UTC)

 * I think that consistency trumps all other considerations. As long as we have a large number of hard-coded context labels, we cannot achieve a high degree of consistency. Thus, we do not have the luxury of discussing this as if it were a change that was purely esthetic for us. We need to first convert all hard-coded contexts and context-like grammar coding to the context tag. Also, do we really want grammar information (eg, "with bare infinitive", "usually with to ") to be treated the same as register contexts, regional contexts, and special technical contexts. I also tend to sympathize with those who have visual impairments or low-quality visual devices, who may represent a larger share of our user base than of the user base of a more commercial reference. DCDuring TALK 18:42, 24 June 2010 (UTC)

Chinese languages nesting
Hi everyone, I'm asking you here to discourage some users' attempt to nest all Chinese languages, due to the following reasons: Thanks. --Symane 15:40, 22 June 2010 (UTC)
 * 1) The community didn't make any related official policy nor authorize anyone to do so.
 * 2) The nesting is to discriminate against minority languages and get them marginalized. This uneqal treatment rudely goes against Wiki values.
 * 3) It's unsightly to see a long list under one entry that possibly contains dozens of subgroups. And these subgroups (various languages with separate language codes) also have numerous dialects.
 * 4) It makes new contributions difficult since it creates excessive categories.
 * 5) The fact that some users, considering they've made great contributions, presume to impose a self-made convention on other users without any authorization is totally a contempt of Wiktionary and  an abuse on everyone.

 * FWIW we always put language sections in alphabetical order. I say do so with translations as well. We put Old Armenian under Armenian and Ancient Greek and Modern Greek under Greek, but Old English, Middle English, Old French and Middle French just get alphabetical listings. My personal preference would be purely alphabetical listing. Mglovesfun (talk) 15:54, 22 June 2010 (UTC)

 * If the Chinese-editing community came to a consensus to nest Chinese languages, then that's what happens. It doesn't matter whether anyone bothered to add it to WT:AZH. --Yair rand (talk) 17:45, 22 June 2010 (UTC)

Re: "We put Modern Greek under Greek": No, we don't. We don't use the term "Modern Greek" here, but rather, we refer to Modern Greek as simply "Greek". See About Greek. —Ruakh <i >TALK</i > 18:57, 22 June 2010 (UTC)
 * Re: "We put Old Armenian under Armenian and Ancient Greek under Greek": Are you sure? I've never encountered such nesting. In my experience they're listed separately.

 * Well, I've seen it before. Perhaps it was an exception rather than a rule. Apparently people get distracted by my examples and miss the point so I'll just say I prefer all languages in alphabetical order, including all the "Arabics". Mglovesfun (talk) 19:00, 22 June 2010 (UTC)

 * I don't think languages should be nested, either — scripts yes, languages no — but the last time we had a poll on the topic, I was in a small minority. Maybe we should start a new straw poll, or maybe even a !vote, to determine if the last poll still has consensus? —Ruakh <i >TALK</i > 19:09, 22 June 2010 (UTC)

 * For some relevant past discussion, see Beer parlour archive/2009/May, which included a straw poll showing overwhelming support for nesting. (Does anyone object to my updating About Chinese accordingly?) —Ruakh <i >TALK</i > 18:52, 22 June 2010 (UTC)

 * Ruakh, yes, please update About Chinese. That was the consensus, which only maintained status quo - the way Chinese translations were treated. Thanks for digging it up. BTW, Symane's global contributions are all about his regional/dialectal boost. I don't expect good contributions and hard work from such a person. Starting his activity here by causing trouble and demands is not nice either. We had this before, didn't we? --Anatoli 21:24, 22 June 2010 (UTC)

 * Indeed, this has been discussed before at length and it was decided to nest the Chinese languages under one heading. If anything, this make it easier to find them. Wiktionary is not the place for discussion about linguistics, but a tool for defining and translating words. It has nothing to do with discrimination, nor does it makes new contributions difficult; the dialects still get their own language codes at any rate. Lastly, if you think users are imposing "self-made" conventions on others feel free to point out where you think this is occurring. Believe it or not it is these users - aka myself, and about four of five other regular contributors - who have turned this Wiktionary's Mandarin coverage from laughable to almost useful. Believe it or not, it is us who should have the biggest say in how Chinese is dealt with on Wiktionary, and not a newbie user like yourself who, it would seem, just wishes to stir up the pot without contributing anything useful. I would love to be proven wrong though. ---> Tooironic 00:15, 23 June 2010 (UTC)
 * I've stricken the last sentence as I believe its tone is inappropriate here. Conrad.Irwin 00:21, 23 June 2010 (UTC)
 * Shrugs. Strike it all you like, I stand by what I said. ---> Tooironic 00:24, 23 June 2010 (UTC)

 * I have updated the About Chinese page to reflect the vote and the current practice. --Anatoli 01:50, 23 June 2010 (UTC)

 * I'm extremely ashamed to work here with such a dictatorial person like User:Tooironic and astonished by his existence on Wiktionary.
 * User:Atitarev: Could you please show me where's the vote? --Symane 08:09, 25 June 2010 (UTC)
 * Atitarev is referring to Beer parlour archive/2009/May. And I don't think it's dictatorial on Tooironic's part to say that decisions should be made by the group of people who have actually been making useful contributions. You can join that group … by making useful contributions. —Ruakh <i >TALK</i > 17:36, 25 June 2010 (UTC)
 * I agree with Ruakh. Someone has to at least initiate changes, or in this case, step forward to defend them, for things to get done. Once that happens, a debate can take place. Otherwise it's complete diffusion of responsibility.--达伟 17:36, 26 June 2010 (UTC)

HotCat
Would anyone mind if we added HotCat to WT:PREFS? The only problem might be that if a lot of people use it, it would increase AF's work load because it has to sort the new categories under the right language heading. (Does anyone have a good way to make HotCat do that on its own, by the way?) —Internoob (Disc•Cont) 20:41, 22 June 2010 (UTC)
 * We had a discussion about this recently (WT:GP, and I think answer was that there isn't a simple way without importing quite a bit of AF's category sorting code. Simpler for HotCat to put everything added to the bottom and leave everything changed where it is.
 * If possible, it would probably be a good idea for AF to teat "using HotCat.js" (or whatever) in the edit summary as an implicit, but without the need to make an edit to remove a tag. I'll poke Robert Ullmann again.
 * In explicit answer to your question - please add it! Thryduulf (talk) 21:40, 22 June 2010 (UTC)
 * This seems like a good tool for newbies. We could make it more widely accessible by adding it as a gadget to Special:Preferences. --Bequw → τ 21:45, 22 June 2010 (UTC)
 * If this tool were fixed up a bunch so that it autosorts categories, doesn't show change/remove buttons for categories that aren't mentioned directly in the wikitext (transcluded through templates), and doesn't capitalize the category (was this fixed already?), then I would support enabling this by default. For now, a gadget and pref seem like a good idea. --Yair rand (talk) 21:50, 22 June 2010 (UTC)
 * The autosort thing still needs to have the bugs worked out, but it already didn't show buttons for categories transcluded in templates (this version of HotCat is quite sophisticated), and the capitalization was fixed at our request. —Internoob (Disc•Cont) 22:14, 22 June 2010 (UTC)

 * I don't know how to edit Special:Preferences or WT:PREFS. —Internoob (Disc•Cont) 22:21, 22 June 2010 (UTC)
 * Thanks Yair rand for adding it to Special:Preferences. --Bequw → τ 03:26, 23 June 2010 (UTC)

Instant-click feedback
There's been a lot of talk about not knowing what our readers think lately - however we have the perfect tool to "ask" them already. I've just re-created the server-side aspect of the feedback tool, so we can monitor who clicks which buttons on which pages and when. http://toolserver.org/~enwikt/feedback/?action=results&wiki=en.wiktionary&week=2010-W25 is slowly filling up. (For privacy reasons, it only records the hour, page title, and feedback comment, which are displayed aggregated as shown on that page)

The question that thus remains is, what do we want to ask them? In light of the recent hidey things change, how about: "What should pages display between definitions by default: 1) quotations and example sentences, 2) example sentences only, 3) quotations only, 4) nothing". Anyone else have questions they want answered by the people who use Wiktionary on a regular basis? We can get it to show one of a number of questions on each page (at random), so there's no need to wait. Conrad.Irwin 00:36, 23 June 2010 (UTC)

 * I guess I could reactivate my toolserver account if anyone wants the several hundred thousand responses which have been given over the past years. As to the questions we should ask, I don't really think this type of poll is the ideal mechanism for finding out people's thoughts on layout.  We are seriously limited in the scope of questions we can ask which means we will be shading their answers no matter how neutrally we try to ask them.  I think the best course of action would be to generate a complete survey website on the toolserver and request participation in a banner.  This could be much more complete and allow people to look at examples, give written feedback and also give more detail about how they actually use Wiktionary.  The poll is nice for targeted, simple response questions like "What do you think about this particular page?" but not so good for "How ought we format this site?" -  00:41, 23 June 2010 (UTC)

 * If we were to do a longer poll I would like to know what users mainly want to find on the site {definitions, pronunciations, inflections, grammar, etymology, synonyms, etc.}. That would would be helpful in all layout decisions. --Bequw → τ 04:02, 23 June 2010 (UTC)

 * I'd be interested in analyzing feedback about English headwords. The first set of questions in my mind is whether there are any distinguishing characteristic of entries that generated complaints, which would require reexamining the entry at the time of the feedabck. Is there a way of augmenting the data with a link to the version of the entry at that time?
 * Another important question is whether hidable quotes have changed the mix of complaints. I'm not sure that we yet have enough data to assess this.
 * It would help if we could analyze the data knowing more about what the users saw and if we had baseline data about which entries/types of entries were actually visited.
 * I am skeptical about the value of surveys. We are more interested in actual behavior than what people are willing to articulate. Simple facts such as how long a user is at an entry and whether the user pages or scrolls down or jumps to something using the ToC would be more helpful. DCDuring TALK 10:12, 23 June 2010 (UTC)

 * It is very possible to record all kinds of facts about usage, I am not sure whether we are allowed to though. - 20:04, 23 June 2010 (UTC)

Phrasebook CFI
If anyone would like to actually work on this and not just whine that there are no criteria for this, plx comment: Wiktionary talk:Phrasebook. — <font face="Lucida console">[ R·I·C ] opiaterein — 18:24, 23 June 2010 (UTC)

Three categories for the same thing?
We seem to have three different categories used for the same things (i.e., words for numbers):

 * Category:Cardinal numbers
 * Category:Numbers
 * Category:Numerals

Can we please consolidate these? There seems to be no rhyme or reason which language uses which category.

71.66.97.228 02:36, 25 June 2010 (UTC)

 * There are differing views on the meaning/usage of "numeral" v. "number" and whether the categories should exactly map to entry section headers. This has been a known inconsistency for years:( --Bequw → τ 23:37, 25 June 2010 (UTC)

Can we please fix this? The application of these categories across languages has no rhyme or reason. 71.66.97.228 08:14, 26 June 2010 (UTC)

 * There are two problems with "fixing" this issue.
 * First, Category:Numbers currently includes symbolic forms of numerical script elements, like 1, 2, 3, while Category:Numerals is currently the main part of speech listing, under which words that function as cardinals, ordinals, fractionals, adverbials, distributives, etc. are placed So, these two categories cover different sort of things.
 * Second, Category:Cardinal numbers (versus Category:Cardinal numerals is part of a debate that has gone on for years. There are people who favor each name, and every discussion or proposal to stanadradize to one or the other has resulted in highly vitriolic debate.  No solution seems likely at any point in the near future. --EncycloPetey 04:33, 6 July 2010 (UTC)
 * I don't follow the first of those two problems. I don't see the difference between '1' and 'one'. Both are numerals, i.e. representations of numbers. I mean, one is translingual and the other is English, but aside from that I don't see the difference. (That said, I have no opinion/solution for what the category for them should be called, nor whether it should be prefaced with Langname or langcode .) —msh210℠ (talk) 04:45, 6 July 2010 (UTC) (Sorry, we had a vote on Langname vs. langcode. I forgot. —msh210℠ (talk) 04:49, 6 July 2010 (UTC))
 * The first is the issue of numerical systems. What we call "Arabic numerals" are the individual symbolic components. They are distinct from words in the same way that "&" / "and" are distinct.  We categorize the former as a symbol and the latter as a conjunction.  Likewise, the letters "h" and "a" are distinct from any words constructed using those letters.  We need a separate category for the components as opposed to the larger units constructed from those components.  This does not imply exclusivity, so "1" could potentially be listed as a number (symbolic) and a numeral (word), just as "a" is both a letter (component) and a word. --EncycloPetey 05:11, 6 July 2010 (UTC)
 * Good point. We do have subcats of Symbols, so I suppose this is another valid one. Incidentally, we have both Symbols and Translingual symbols. (Sigh.) —msh210℠ (talk) 05:18, 6 July 2010 (UTC)

Labels (informal, colloquial and ...)
I am searching for a context label which corresponds to the substandard vocabulary, i.e. the label for low colloquial, popular words, which are used usually by illiterate and uneducated peoples. I have looked at Category:Usage context labels, but I can't decide which of these labels pick up...

P.S. And explain, please, the difference between labels informal and colloquial. Both of these words are translated into Russian as разговорный. -- Andrew Krizhanovsky 04:35, 25 June 2010 (UTC)
 * . (And I don't know the difference between informal and colloquial, though perhaps you'll be able to pick up some difference — I cannot — from our definitions at [[Appendix:Glossary]].) —msh210℠ (talk) 17:31, 25 June 2010 (UTC)
 * Archaic and obsolete overlap a lot as well. For me, something that was last used in 1970 cannot be archaic because it's not been out of use long enough. So if I use archaic, it's been out of use for longer than something I tag with obsolete. Mglovesfun (talk) 19:48, 25 June 2010 (UTC)
 * I don't think archaic means out of use at all: it means in use, but archaic-sounding. Like thee: people use it even now, but it sounds archaic. Obsolete means out of use. Maybe my understanding doesn't match everyone else's, though. —msh210℠ (talk) 19:50, 25 June 2010 (UTC)

 * That seems to be the prevailing usage of "archaic" here, but it makes little sense to me; surely it would only apply to the very small number of terms, like thy and ye, that can be documented in pseudo-archaic speech or writing. Given the multiple meanings of "archaic", I would prefer a separate  if that is really called for.  I had been using archaic in the meaning of "really obsolete", for things like Elizabethan usages, with the idea of a three-part system:  dated < obsolete < archaic.  However, I've seen other editors change these "archaic" labels to "obsolete" on various entries, so am thinking the simplest thing is to just use "obsolete" for everything that's no longer in current use. -- Visviva 20:36, 25 June 2010 (UTC)

 * To me "archaic" means "people will understand it, but will consider it archaic", whereas "obsolete" means "people will not understand it, because it has completely gone out of use". Thou and ye, by the way, are found today not only in pseudo-archaic speech or writing, but also in various proverbs, fixed expressions, Biblical allusions, Shakespeare quotations and misquotations, and so on: "Judge not, lest ye be judged"; "honor thy father and thy mother"; "O ye of little faith"; "the desire of thy heart"; etc., etc., etc. —Ruakh <i >TALK</i > 22:49, 25 June 2010 (UTC)

 * Obsolete also gets used (correctly or incorrectly) to note when the meaning of the word (thing, concept) is obsolete, but the word is still in current use to describe the obsolete concept, e.g. in historical contexts. Compare East Berliner: and abreast: (sense 5). Thryduulf (talk) 20:44, 25 June 2010 (UTC)

 * I think that's a mistake. Those should be . —Ruakh <i >TALK</i > 22:49, 25 June 2010 (UTC)
 * Yep. Mglovesfun (talk) 20:29, 1 July 2010 (UTC)
 * Actually, that abreast: def. is correctly noted as . Circeus 21:01, 5 July 2010 (UTC)
 * Yes, that was the point: Thryduulf was contrasting the current-term-for-obsolete-thing with the obsolete-term . (When I said "those", I meant "the uses that Thryduulf is describing", not "the uses at [[East Berliner]] and [[abreast]]". Sorry if that was confusing. Deixis works better when you can see what I'm pointing at. :-P   ) —Ruakh <i >TALK</i > 17:02, 19 July 2010 (UTC)

 * FWIW I've repeatedly attempted to have and  merged, but there is a persistent clique insisting that there is a very valid distinction, the shadow of the tail of which I've never seen. Circeus 20:27, 1 July 2010 (UTC)

time-sensitive "+" links in the RFV/RFD/... templates
I've twice recently noticed people saving new sections in the RF* pages instead of contributing to old ones, due to clicking the "+" links instead of the big links in the templates as displayed. The templates can be caused to display the "+" only for a limited time after they are transcluded (see (which is a temporary link due to its transclusion of templates that will eventually disappear), substing [[User:Msh210/Sandbox3]]), or can be caused to have the "+" appear in a CSS style caused by JS to be visible only to established editors. Or neither. Any preference? —msh210℠ (talk) 19:15, 25 June 2010 (UTC)

 * Maybe the "(+)" should only be visible on edit-preview? That way it's easily accessible to editors — especially the editor who's adding the template — but not so obtrusive to readers. (Note: I believe this would require JS.) —Ruakh <i >TALK</i > 19:39, 25 June 2010 (UTC)
 * Great idea! The displayed text being previewed seems (unless I'm misreading it) to be in a <div id="wikiPreview">, which would mean it should be doable using CSS alone. —msh210℠ (talk) 19:53, 25 June 2010 (UTC)
 * Yes, it works. (I tested it with : see its history.) But I'm not going to make the changes unless those who request verification/deletion/cleanup don't mind them. Can people chime in, please? —msh210℠ (talk) 17:32, 28 June 2010 (UTC)
 * IMO leave them as permanent links. Sometimes users tag them and forget to list them. I sometimes add them to RFV/RFD months or even years after being first tagged. Equinox does the same. Mglovesfun (talk) 17:34, 28 June 2010 (UTC)
 * No, see, this conversation, in its short life, switched from being about my original suggestion that thse "expire" to being about having the "+" links be visible only on preview. It will take getting used to, and, if you're not the one adding the tag, will require an extra step, but the objection you just raised, Martin, doesn't apply. —msh210℠ (talk) 17:39, 28 June 2010 (UTC)
 * Hmm, so if I tag an entry, forget to click the +, what happens next? Mglovesfun (talk) 17:58, 28 June 2010 (UTC)

 * Then you have to go into the editing window and hit show preview for the '+' button to appear again. -Atelaes λάλει ἐμοί 18:25, 28 June 2010 (UTC)
 * Or follow the link to page and add the section manually, whichever you prefer. Thryduulf (talk) 19:40, 28 June 2010 (UTC)

 * Could we not make the "+" smarter and have it redirect to existing conversations if one exists? - 19:47, 28 June 2010 (UTC)
 * No. (Well, I assume we could do that using JavaScript (and one of our scripters can confirm if so), but you'd need the script to load the whole RFV/RFD/whatever page to see whether such a section exists.) —msh210℠ (talk) 20:26, 28 June 2010 (UTC)

 * I'm still rather new at this, but I'm pretty sure that msh210's right, mostly. You could actually just load the headers, which I suspect would be sufficient, but it'd still be a pretty slow thing (there are a lot of headers on the RFX pages), so I don't think such an approach would be practical.  It'd be a good solution if it was, though.  -Atelaes λάλει ἐμοί 20:38, 28 June 2010 (UTC)
 * Would a separate page listing only the titles (in alphabetical order) make it any more practical? Such a page could easily be maintained by a bot. Maybe one page per initial letter, so that on, say, staithe, the javascript would only need load the page Tea room headers/s? I'm an ideas man, not a coder, so I've no idea whether this would actually help or not! Thryduulf (talk) 21:52, 28 June 2010 (UTC)

(unindenting) Yes, you could do that, and it probably would help. However, I strongly suspect the thing would still be slower than we'd like. And maintaining 26 pages for every RFX page, and writing some fairly advanced JS seems like rather more cost than the feature is worth. -Atelaes λάλει ἐμοί 22:01, 28 June 2010 (UTC)

 * Word. I just don't see the need for that: if you click on the regular, non-plus-sign link, and you find that it doesn't take you to a specific section (because the section doesn't exist yet), then that means you're still at the top of RFV (or RFD or whatnot), in perfect position to click the plus-sign tab. The only additional thing that a JS solution could do is find out beforehand whether the section exists, and show or hide the in-entry plus-sign link; but how useful would that really be? (Especially if it depended on subsidiary pages that would always be at least slightly out of date?) —Ruakh <i >TALK</i > 23:21, 28 June 2010 (UTC)

Okay. My proposal got a little lost in the length of the thread, so let me restate it: I propose that the "+" links in the rfd/rfv/... templates that link to new-section creation be visible on preview only. Anyone okay with that? Anyone not? —msh210℠ (talk) 18:15, 2 July 2010 (UTC)
 * I'm weakly in favour of it - I can see it being a small inconvenience in some circumstances but I can't think of a better way to do it. Thryduulf (talk) 13:21, 6 July 2010 (UTC)

Screwing around with user interface
Who is playing around with the user interface? A newbie doing this would be directed to the sandbox by nice folks or blocked by other folks.

These changes {tabs for Language sections, disabling navigation by the ToC are clearly not ready for prime time and should require a vote or at least conspicuous notice. DCDuring TALK 16:52, 27 June 2010 (UTC)
 * user:Atelaes. See WT:GP where notice was given of it being added as an option to WT:PREFS was given. "Also, a few folks who were using hidden quotes before it was pushed site wide might have it fed to them without their consent. To any who suffered this, I sincerely apologize". Thryduulf (talk) 17:09, 27 June 2010 (UTC)

Category:Pastry
There is a lonely singleton in Category:Pastry. A new Category:Cakes and pastries might fill a gap in the Category:Foods and provide a more popular successor for Pastry. Looking at other languages shows minimal usage of this category anywhere. — Saltmarsh απάντηση 09:18, 28 June 2010 (UTC)
 * Sounds sensible to me. Thryduulf (talk) 12:47, 28 June 2010 (UTC)
 * Yeah move. BTW WT:RFM is moving veeeery slowly. Mglovesfun (talk) 17:35, 28 June 2010 (UTC)
 * I agree. Pastry is over-specific. Equinox ◑ 17:36, 28 June 2010 (UTC)
 * This doesn't seem contentious and the number of affected articles is small - I'll go ahead. — Saltmarsh απάντηση 04:10, 4 July 2010 (UTC)

Signpost discussion
Hi all! Just a note to let you know that over on Wikipedia, contributors to the Signpost community newspaper are discussing, amongst other ideas, expanding the project to cover more news from Wikipedia's sister projects and/or other language wikis. If you would be interested in writing up news from Wikitionary or have any other comments, your input would be very welcome. Thanks, Pretzels 15:22, 3 June 2010 (UTC)
 * I've volunteered to be the voice of Wiktionary --Soleil levant 09:54, 4 June 2010 (UTC)
 * Soleil levant/Wonderfool, this is no longer possible, because you have been blocked here indefinitely. The uſer hight Bogorm converſation 19:16, 6 June 2010 (UTC)
 * Shame. WF's been here long enough to be a good voice of enwikt.</tongueincheek>. —msh210℠ 17:07, 7 June 2010 (UTC)

Conjugated preposition templates
Some languages, such as Irish, have conjugated prepositions. This means that the prepositions inflect depending on their antecedent. Take a look at for an example. As you can see, there is an inflection template and it's listed in an 'inflection' section. That's all fine, but now I'm trying to figure out how to categorise the template itself. is for verbs, but is misleading. And of course (where it currently is) is really for inflection line templates. Any ideas? —CodeCat 10:14, 4 June 2010 (UTC)

 * Why is Category:Irish declension templates misleading? My impression was the declension covered all nominals, including nouns, pronouns, and adjectives.  -Atelaes λάλει ἐμοί 23:50, 5 June 2010 (UTC)

 * Oops! Sorry! I mis-typed. I actually meant conjugated prepositions! Silly me... —CodeCat 09:34, 6 June 2010 (UTC)

 * One of my Hebrew-English dictionaries has an appendix with the "declensions" of various prepositions. It's not the best term IMHO, but it works. —Ruakh <i >TALK</i > 21:59, 8 June 2010 (UTC)

 * What is the established name for this phenomenon in Irish, though? Declension, conjugation, or something else? It seems that a Google search for 'conjugated prepositions' gives almost only hits related to Celtic languages on the first page. A search for 'declined prepositions' seems to return more hits related to Hebrew. —CodeCat 16:18, 9 June 2010 (UTC)

 * May I ask if Irish prepositions inflect in a way similar to any other parts of speech?  -Atelaes λάλει ἐμοί 16:25, 9 June 2010 (UTC)

 * They inflect for person and number, like a verb. But they don't have tenses or moods or anything else like that. Essentially it's just that the preposition and a following personal pronoun fuse together to form a new distinct form. There is one such fused form for every preposition+personal pronoun combo. See, , etc. for some examples. —CodeCat 16:47, 9 June 2010 (UTC)

Translating Sarkozy and Berlusconi
On Tuesday Widsith and Yair rand reverted my edits to Sarkozy and Berlusconi, and Widsith suggested a BP discussion. My point is that Sarkozy and Berlusconi are not English words, so they cannot have a translation table. Instead, the transliterations should be listed as ====Descendants==== in the French and Italian entry, and any "translations" of Sarkozy as "Sarkozy" should be removed, since they are erratic. Personal names are not translated: they have transliterations and cognates. About given names and surnames specially mentions Sarkozy as an example of a name that is not English, but French. The name bearer is a Frenchman, and in any language the name is correctly pronounced as in French. In an ensuing discussion Yair rand argued that if an English Michael is mentioned in Italian text, his name becomes an Italian word, but nobody supported his view. By that logic, all names would occur in all languages, and language statements would become worthless. It would be impossible to tell apart names that are genuinely used in several languages, like Anna or indeed German and Danish Michael.

This problem only occurs in foreign personal names that use Roman script. English transliterations such as Putin are English words (though arguably not English surnames), and the translation table correctly gives the transliterations of Russian Путин in various other languages. Also, place names are topics - "specific entities" - and have genuine translations. But we should not pretend that Sarkozy is an English surname just in order to have a translation table. The transliterations can be perfectly well presented like this. Genuine cognates can be mentioned in the etymology section, or in ===See also===. The only drawback is that the tbot links disappear. But if that's a serious problem, surely some of the technical people here can think of a solution.--Makaokalani 12:01, 4 June 2010 (UTC)

 * Ish.....surnames are, I think, the only thing more slippery than given names. What possible standard could we come up with to determine what language a surname is?  There are some interesting criteria listed at About given names and surnames.  I think that they're good criteria, in an absolute sense, but terrible criteria in a practical sense, as of course, they're nigh impossible to use in practice.  I suppose that, in the absence of any kind of consensus, it is a bit over-bold of you to delete the English entry.  Of course, there is zero possibility that we will come to any kind of consensus on this issue, as it's just so damned slippery, and we don't have the infrastructure nor the conversation structure to deal with it.  *sigh*  -Atelaes λάλει ἐμοί 13:10, 4 June 2010 (UTC)

 * But I did explain how it can be dealt in practice. There have not been serious objections except from Yair rand whose view of names (also place names) is different from everybody else's. I'd say most people just don't stop to think about it. And there aren't many entries like this yet. They can be changed. The categories are getting messed up too: now Sarkozy is listed in Category:English surnames from French. If being a president means rules can be changed, we'll end up with "English" entries for Halonen, Ahtisaari, Koivisto, you name it.--Makaokalani 13:32, 4 June 2010 (UTC)

 * Ummmm.....it looks to me like that conversation was a rambling clusterfuck that was hit by a bus and then exploded. Most people didn't have any ideas (by idea I mean a cohesive proposal to address the issue), but rather noted important difficulties with names.  I'm not saying that this is a huge problem, or that anyone involved should be blamed.  What I am saying is that it's a bit silly to act as though there was some resolution which was accepted.  Based on that discussion and the ones happening at Wiktionary talk:About given names and surnames, I would say there is zero evidence that any two editors on this project are looking to treat names of any sort exactly the same way.  Again, this is acceptable, as it's a remarkably difficult issue, and I don't think anyone, ever, anywhere, has resolved it to the level that we need for a cohesive policy.  However, in the absence of consensus on the issue, I don't think it's prudent to start deleting content.  We haven't yet agreed on...well....anything regarding names, and so it's still kind of a free-for-all, which means that we can't really say, "this doesn't belong here, I'm going to remove it."  I'm not saying it's hopeless, even if my previous comment might have implied that.  I very much welcome, and plan to participate in, any discussion about the treatment of given names, surnames, place names, etc.  However, that discussion needs to lead to a consensus before we start touting "policy".  -Atelaes λάλει ἐμοί 13:52, 4 June 2010 (UTC)

Usage is our benchmark. If an includable term, or name, is used in English, then it needs an #English section. Joe Anglophone doesn't become a French or Hungarian-speaker every time he mentions the French head of state. (If crème brûlée can be English, why not Sarkozy?)

Yeah, with names it's not exactly the same as with other terms. Other terms must surpass a threshold of usage to be considered accepted, but even then they may be not fully naturalized and chiefly italicized. In one sense a name is translingual—French and English Sarkozy is still the same name Sarkozy—but the #English section in the entry in this descriptive dictionary describes its usage in English: its English pronunciation, spelling variants, any English conjugations and inflections (pl. the Sarkozys, poss. Sarkozy's, etc.). Of course, the fact that it comes from French and originates in Hungarian belongs in the etymology. —Michael Z. 2010-06-04 20:47 z

 * Sorry, Makaokalani. I haven't replied on my talk page but other people have. I didn't have an answer straight away. It doesn't mean that I don't care or I ignored your message. This is one of the topics where there are different unreconcilable opinions. I haven't found a definite Wiktionary policy but it probably doesn't exist. The names are certainly verifiable in English. It doesn't make them English (by origin) but perhaps others can help. I saw User:Vahagn Petrosyan has been using the template with "lang" for some surnames with a summary "redefining as a surname, lest someone delete it". I will ask Vahagn what he meant. --Anatoli 03:19, 7 June 2010 (UTC)

 * Aren't proper names of persons when used as proper names (not in the CFI attributive-use sense) essentially translingual? They often have transliterations into other scripts or appear with altered diacritical marks, which does not fit into our concept of Translingual. AFAICT, we never addressed the logic of this. I am unaware of any multiscript reference work that addresses proper nouns of the various types that we allow or may allow in the future, but perhaps there are some other online resources that do. DCDuring TALK 10:46, 7 June 2010 (UTC)
 * Everything's translingual. We get hung up on labelling something as an “English” term, but the threshold is arbitrary: once there are three attestations in three years, we can document how it's used in English, no matter how unnaturalized and foreign it seems to anglophones. But the possessive form Sarkozy's appeared in 1872, and I don't think you'll convince me that that is French or Hungarian. —Michael Z. 2010-06-08 23:05 z
 * I could create impressive Finnish declension tables for every single name on earth; that does not make them Finnish. Names are labels, copy-pasted from language into another. They don't mean anything so normal CFI rules don't apply, and they aren't translingual because of pronunciation. --Makaokalani 12:43, 9 June 2010 (UTC)

 * (A section of this discussion has been copy-pasted below, in WT:BP, because it is clearly a separate issue.--Makaokalani 12:29, 17 June 2010 (UTC))

 * “personal names cannot be defined through English, like vocabulary words are”—What does that mean? Either Sarkozy or crème brûlée is used in English, in an English manner (e.g. with ’s for a possessive) and with an anglicized pronunciation. What is the difference, and why does it require a different name for a category? —Michael Z. 2010-06-11 14:57 z

 * What exactly does “Armenian surname” represent, for example, if we're talking about a name of Hungarian origin in English usage? A name can be passed around through any number of languages between its origin and its current use, each one influencing the pronunciation or orthography greatly, or not at all. —Michael Z. 2010-06-10 21:33 z

Cf. Sarkozyism (after Fr. sarkozysme). —Michael Z. 2010-06-09 00:56 z

 * Yes, Sarkozyism and crème brûlée are English common nouns, and Sarkozy's has been recorded in English in 1872. What does that prove about the language of the surname? Names of foreigners are used all the time in all languages. If the script changes, they are called transliterations, and need a separate entry. If the script stays the same, they are copy-pasted and used in a translingual way, with the original pronunciation. All the information can be given in the original language entry. Are you saying that an Anglophone won't know how to create a possessive of Sarkozy unless we tell him? How will he manage to use all the translingual taxonomic names then? The language of the surname means the mother tongue of the name bearer (provided he is not forced to take a foreign name for political reasons). That's the rule in the multi-lingual Oxford Dictionary of Surnames, for example, and in 99.9 % of our entries. It's a common sense rule. I have never found it "slippery" or "impossible to use in practice". It's easy to find surname statistics in the web, too.
 * Your proposal would fill up all entries about names with useless repetitive stuff, just for the sake of principle. Visitors would be bewildered. It's difficult enough to understand that a name like Anna really occurs in several languages. It's also an invitation for sloppy thinking. If you are too lazy to check the statistics of a name, call it any language you want. If you want to raise your edit count by 15,000, just pick any language - Albanian, for example - and add to every name: ==Albanian== 1.A French surname, ==Albanian== 1.An English male given name, ==Albanian== 1.A German female given name. It's difficult to find a Western name that has not been mentioned three times in Albanian.
 * A dictionary should be as simple and effective as possible. I'm the main contributor to given name entries here, and if I waited for consensus about names, I would never get any work done. Every time I try to discuss a practical problem about names in the BP I find myself in a Kafka-like philosophy club.--Makaokalani 12:29, 17 June 2010 (UTC)

I've been raped
We currently have at least three phrasebook entries for victims of particular crimes: I've been robbed, I've been raped and I've been shot.

Since the deletion of the rape version was requested and our phrasebook policy is still under development, I'd like to know if there are opinions on this particular branch: Should we add and maintain entries for crimes such as these?

I suggest that we do so for emergencies: For example, there are places in Brazil where the possibility of being robbed is particularly high, so the ability to say afterwards "I've been robbed" in Portuguese may prove useful, perhaps to call the police minutes after. I believe that a person who was raped or shot would also need help as soon as possible. --Daniel. 00:18, 6 June 2010 (UTC)

 * I would suggest Appendix:Phrase book/emergencies, and either redirecting, or using for any English titles. I don't think the entries are productive. Conrad.Irwin 00:51, 6 June 2010 (UTC)

 * While I agree that all phrasebook entries should be appendicized, I'm confused as to why these entries would be singled out (if that's what you're saying). -- Visviva 01:29, 6 June 2010 (UTC)
 * I was just replying to the specific question. I agree with your sentiment. Conrad.Irwin 01:35, 6 June 2010 (UTC)
 * I don't think any entries should be appendicized (assuming by "appendicized" you mean having no mainspace entries and only existing in appendices). What we really need for the phrasebook to be useful is an efficient category structure and some appendices making the entries easy to find. Individual entries per phrase can work, so long as we make them easy to find, and it's not like we have any space limitations for this. --Yair rand (talk) 03:17, 6 June 2010 (UTC)
 * Visviva, singling out sets of phrasebook entries is apparently the most common and convenient way to discuss about them in Wiktionary. In my message, I tried to ask "Would people want to use those specific phrasebook entries?" That question works for other phrasebook entries as well. Their existence in the entry namespace or only in appendices is a separate issue. --Daniel. 14:29, 7 June 2010 (UTC)

 * I'm beginning to agree with the sentiment that Phrasebook entries should be in an appendix. Otherwise we'll end up with a ludicrous mess of entries with meaningless translations.  Will we have an entry for Can you direct me to the Louvre?  Will it have a Mandarin translation?  Tagalog?  Wolof?  Why? --EncycloPetey 17:12, 7 June 2010 (UTC)
 * [[can you direct me to the Louvre]] would definitely be out of scope, IMO. Same with all of msh210's ideas below, with the possible exception of some variation of "I've been assaulted". --Yair rand (talk) 17:21, 7 June 2010 (UTC)
 * Out of scope? why?  Surely this is a common useful travel phrase (at least for the many tourists in Paris). --EncycloPetey 17:31, 7 June 2010 (UTC)
 * It would be useful for English-speaking tourists in Paris looking for the Louvre. That's it. Not particularly helpful IMO, and not necessary often enough to be in the phrasebook. The phrasebook, however large it will end up, will need a limited size, otherwise it will be unmanageable. (I'm thinking somewhere in the range of 1000-3000 entries max.) --Yair rand (talk) 17:39, 7 June 2010 (UTC)
 * Some might say that's hypocritical from the phrasebook's biggest advocate. How is that less useful than I don't speak Old High German? Mglovesfun (talk) 17:42, 7 June 2010 (UTC)
 * Well, it doesn't look like we are ending up keeping I don't speak Old High German and co, but my first thoughts about those phrases were, if we're having words in dead languages, then the languages should probably be treated equally with other languages throughout Wiktionary. As it is, apparently we're not, at least within the context of the phrasebook. Not really a problem. --Yair rand (talk) 17:49, 7 June 2010 (UTC)
 * gives me zero hits. This is not attestable, hence not a CFI-meeting phrasebook entry. I guess you can find a similar example that is attestable and makes your point, though. --Dan Polansky 20:38, 7 June 2010 (UTC)
 * Actually, I got two b.g.c. hits for the Louvre phrase, so I'd be surprised if more could not be found. --EncycloPetey 20:43, 7 June 2010 (UTC)
 * I have zero for, and I have two for . The first is unattestable, the second is uncommon hence outside of phrasebook. --Dan Polansky 20:49, 7 June 2010 (UTC)
 * What would we need for it to be "common"? On a whim, I tried "direct me to Piccadilly" and got 9 b.g.c. hits, which is two more than I get for "direct me to the train station". --EncycloPetey 20:55, 7 June 2010 (UTC)
 * I think, currently, around 500 b.g.c. hits would establish that a phrase is common; 50 seems too low; 100 could already be in a gray zone. This number would have to be calibrated based on the number of Google books hits for, and similarly very common phrases. When a phrase would be found is several real phrasebooks, this Google hits requirement could be relaxed. But less than 50 b.g.c. hits seems really low to me, in either case. --Dan Polansky 21:04, 7 June 2010 (UTC)
 * Just thinking aloud here... [[I've been defrauded]], [[I've been assaulted and battered]], [[I've been harassed]], [[I've been defamed]], [[I've been falsely imprisoned]]. —msh210℠ 16:54, 7 June 2010 (UTC)
 * [[I need a blowjob]]. Now that I've red linked that, someone will probably create it. Seriously, How feasible is my iea of auto redirects from I need a hammer to Phrasebook:I need a hammer? Mglovesfun (talk) 17:19, 7 June 2010 (UTC)
 * Phrasebook entries need to be both attestable and common. gives me two hits, hardly an evidence of commonness. --Dan Polansky 20:41, 7 June 2010 (UTC)
 * As regards "I've been raped", let us see: has 632 hits, and  has 927,000 hits. A clear keep. --Dan Polansky 20:44, 7 June 2010 (UTC)
 * Attestable and common is necessary, but certainly not sufficient, not by a long way. Conrad.Irwin 20:59, 7 June 2010 (UTC)
 * Agreed. The phrase (a) seems useful (subjective assessment, untraceable), (b) is attestable (objective CFI criterion), and (c) is common (criterion that uses an arbitrary threshold of commonness). --Dan Polansky 21:08, 7 June 2010 (UTC)
 * And the particular phrase is on the safe side through (d) its being found in real phrasebooks in Visviva's search . See also a particular page in one of these phrasebooks in Google books. --Dan Polansky 21:24, 7 June 2010 (UTC)

Welcome template
I have absolutely no idea why, since I haven't edited there, but I just got a welcome on the Portuguese Wiktionary. I think it would be quite nice for our welcome template to have a few simple icons like that one. Nothing too gaudy. Just makes it less intimidating and quicker to skim to find something. Equinox ◑ 01:15, 6 June 2010 (UTC)
 * In the Portuguese Wiktionary, people apparently receive a welcome message simply after creating their account, rather than only after making actual contributions. --Daniel. 01:22, 6 June 2010 (UTC)
 * It can actually be more intimidating if you visit a site, make no edits, and still get a welcome message in a language you're unfamiliar with. This often happens to me on various sites because I have a global account. I'd prefer it if the message were sent only after an edit was made. —CodeCat 11:09, 8 June 2010 (UTC)

Numbers in the table of contents
There were a lot of discussion and votes about the table of contents format a few months ago, ending in totally no changes to the way the ToC works, because no one could agree on what's the best way to format it. However, there is one thing that I think everyone agrees on: The numbers on the left side of the ToCs are completely useless.

So, does anyone have any objections whatsoever to removing the numbers? Holding a vote to remove them seems like a waste of time, so if nobody objects to removing them within the next week or so, I'm just going to add the code to Common.css. Okay? --Yair rand (talk) 03:17, 6 June 2010 (UTC)

 * Sounds good to me. -Atelaes λάλει ἐμοί 03:21, 6 June 2010 (UTC)

 * To the contrary, the numbers begin to make at least a little sense of things when dealing with what is indented how much. I'd prefer they be kept. --Neskaya contribs–talk? 06:25, 6 June 2010 (UTC)

 * 1) [[Image:Symbol oppose vote.svg|20px]] Oppose   -- Prince Kassad 08:09, 6 June 2010 (UTC)
 * 1) [[Image:Symbol oppose vote.svg|20px]] Oppose   -- Prince Kassad 08:09, 6 June 2010 (UTC)

 * Not entirely sure how I feel about this. Equinox ◑ 12:12, 6 June 2010 (UTC)

 * Why wouldn't the display of numbers in the ToC be controlled by the checkbox in "my preferences" that controls their display before headers? Maintaining correspondence between ToC and headings seems like an essential for usability. I use to numbers in headings to help me detect mis-structuring.
 * Unregistered users might prefer the less cluttered look of without numbering. We have no way of knowing about unregistered user preference and militantly ignore any general principles of Web design on the grounds that we are different. As a result personal preferences, whimsy, and unverifiable beliefs govern many aspects of our entry design. DCDuring TALK 12:17, 6 June 2010 (UTC)

 * I use the numbers as well, so this motion is highly premature. --EncycloPetey 14:51, 6 June 2010 (UTC)

 * While I don't see the purpose in them either (I'd be interested to know what you use them for EncycloPetey), there is no argument presented here that persuades me they are harmful. I imagine the literate human reads a numbered list without even noticing the numbers - we should also assume users have basic literacy. Luckily I think the bloodline ended with Baldrick. Conrad.Irwin 15:19, 6 June 2010 (UTC)

Okay, scrap this idea entirely. I had been expecting no objections to this at all, and I assumed that it could just go through without anyone having a problem with it. The numbers are completely trivial, and certainly not worth wasting a huge amount of time over. --Yair rand (talk) 17:26, 6 June 2010 (UTC)

Why the heck do we have HTML unordered lists here, and then add literal numbers and a complex hash of class names? Let's convert these to ordered lists, and let everyone number them to taste using their style sheet. This shouldn't be an issue if it were done right in the first place.

Anyone know where in MW this is set up? Can it be changed? —Michael Z. 2010-06-06 18:56 z

 * AFAIK, the reason for this is you can't do stuff like "1.1", "1.2", "1.2.1", etc. with HTML ordered lists. -- Prince Kassad 19:13, 6 June 2010 (UTC)

 * Actually, you can, using the CSS2 nested-list stuff; see http://www.w3.org/TR/CSS2/generate.html#scope. But not all browsers support it; for example, IE7 doesn't. —Ruakh <i >TALK</i > 21:27, 8 June 2010 (UTC)

 * The following CSS duplicates the TOC numbering in Wiktionary. Of course, if you're numbering the TOC items, you could put corresponding numbers on the actual headings.  (Seems to work on Safari 5/Mac, Firefox 3.6/Mac, Firefox 2.0.0.14/Mac, Opera 10.10/Mac.) —Michael Z. 2010-06-08 22:23 z

<dl><dd><dl><dd><dl><dd><dl><dd><pre style="overflow: auto;">
 * 1) toc ul { counter-reset: toc-h2; }
 * 2) toc ul ul { counter-reset: toc-h3; }
 * 3) toc ul ul ul { counter-reset: toc-h4; }
 * 4) toc ul ul ul ul { counter-reset: toc-h5; }
 * 5) toc ul ul ul ul ul { counter-reset: toc-h6; }

 * 1) toc ul li { counter-increment: toc-h2; }
 * 2) toc ul ul li { counter-increment: toc-h3; }
 * 3) toc ul ul ul li { counter-increment: toc-h4; }
 * 4) toc ul ul ul ul li { counter-increment: toc-h5; }
 * 5) toc ul ul ul ul ul li { counter-increment: toc-h6; }

</dd></dl></dd></dl></dd></dl></dd></dl>
 * 1) toc ul li:before { content: counter(toc-h2) ". " }
 * 2) toc ul ul li:before { content: counter(toc-h2) "." counter(toc-h3) ". " }
 * 3) toc ul ul ul li:before { content: counter(toc-h2) "." counter(toc-h3) "." counter(toc-h4) ". " }
 * 4) toc ul ul ul ul li:before { content: counter(toc-h2) "." counter(toc-h3) "." counter(toc-h4) "." counter(toc-h5) ". " }
 * 5) toc ul ul ul ul ul li:before { content: counter(toc-h2) "." counter(toc-h3) "." counter(toc-h4) "." counter(toc-h5) "." counter(toc-h6) ". " }

 * Yair, I think it would be almost certainly be a good default for unregistered and non-contributing users because it looks cleaner. I don't know how many contributing users take advantage of the numbering but their preferences could be accommodated. Personally I'd be willing to forego entirely my accustomed usage of the numbering in the interest of a cleaner look for unregistered users. DCDuring TALK 20:42, 6 June 2010 (UTC)

I, personally, would prefer that, instead of the current section numbers that respect level headers (1, 2, 3, 3.1, 3.2, 4, 4.1, 5...), the actual section numbers that appear in URLs when one chooses to edit a section were displayed (like 1, 2, 3, 4, 5, 6, 7 without respecting level headers). That would make editing discussions easier, at least for me. --Daniel. 10:03, 8 June 2010 (UTC)

 * The following CSS will do so. —Michael Z. 2010-06-08 22:40 z

 * 1) toc > ul { counter-reset: toc-h2; }
 * 2) toc ul li { counter-increment: toc-h2; }
 * 3) toc ul li:before { content: counter(toc-h2) ". " }

You know what, this is never going to get done unless we go ahead with the vote. I've started Votes/2010-06/Hiding numbers in the table of contents, which starts in three days. Those who want to keep the numbers can use WT:PREFS to keep them available for themselves. As per DCD, a cleaner look for unregistered users is important. --Yair rand (talk) 07:18, 11 June 2010 (UTC)

Redirections/Other namespaces
Needs some input from someone better than me. Mglovesfun (talk) 14:22, 7 June 2010 (UTC)
 * Well, you misspelled vice versa, but I'd have to think about some of the implications and such. The first point could benefit from additional articulations giving explicit reasons why the examples are acceptable / unacceptable. --EncycloPetey 14:35, 7 June 2010 (UTC)
 * I would change #1 to "Redirects within the template namespace should not be ambiguous or misleading." The reason is that we already use WT:A for WT:Administrators, not WT:Announcements; and WT:ES for WT:Etymology scriptorium, not WT:About Spanish or Help:Edit summary; and we use disambiguation on those pages whcih seems to work fine. —Internoob (Disc•Cont) 22:32, 7 June 2010 (UTC)
 * Sound good? —Internoob (Disc•Cont) 01:18, 9 June 2010 (UTC)

Accelerated Nested Translations
Dear All, as has been politely asked for, and loudly demanded for some time: it is now possible to add nested translations using WT:EDIT. By default the new box (Nesting) is hidden under the "More" button, and I hope that it is pre-filled with the correct value. I've given a few questions I need people's help with below - if what I've said makes no sense, let me know too. Conrad.Irwin 22:03, 7 June 2010 (UTC)

What should be nested?
It currently uses the following table: <pre style="overflow: auto;">

var nesting = { apj:'Apache',apm:'Apache',apw:'Apache', xcl:'Armenian',axm:'Armenian', // ang:'English',enm:'English', don't nest English (Encyclopetey) fro:'French',frm:'French', oge:'Georgian', gmh:'German',goh:'German',gsw:'German',ksh:'German',pfl:'German',sxu:'German', grc:'Greek/Ancient',gmy:'Greek/Mycenaean', //el:'Greek/Modern', don't nest modern greek (Atelaes) sga:'Irish',mga:'Irish', nb:'Norwegian/Bokmål',nn:'Norwegian/Nynorsk', mhr:'Mari',mrj:'Mari', cmg:'Mongolian', sro:'Sardinian',sdn:'Sardinian',src:'Sardinian',scd:'Sardinian', dsb:'Sorbian',hsb:'Sorbian', osp:'Spanish', owl:'Welsh',wlm:'Welsh', zh:c,yue:c,dng:c,gan:c,hak:c,czh:c,cjy:c,cmn:c,mnp:c,cdo:c,nan:c,czo:c,cpx:c,wuu:c,hsn:c,lzh:c, // c == 'Chinese' arq:a,aao:a,bbz:a,abv:a,shu:a,acy:a,adf:a,avl:a,arz:a,afb:a,ayh:a,acw:a,ayl:a,acm:a,ary:a, // a == 'Arabic' ars:a,apc:a,ayp:a,acx:a,aec:a,ayn:a,ssh:a,ajp:a,arb:a,apd:a,pga:a,acq:a,abh:a,aeb:a,auz:a } Obviously, as I don't actually write Wiktionary entries, I need the help of the community to work out what else should be here (perhaps dialects of Arabic?). This is mainly a policy issue (and from previous discussions a controversial one). If you want to edit the table directly in User:Conrad.Irwin/editor.js please do, otherwise ask me to make changes here, and I will (providing it's clear what people want). Conrad.Irwin 22:03, 7 June 2010 (UTC)

 * This sounds excellent to me. It'd be nice if Robert could be involved with this, so that AutoFormat is not undoing the nesting that the transadder is doing, and perhaps even that AF is generally conforming other entries to the standard set by transadder, so that we have consistency across articles.  I'm sure there are a million and one places where folks will disagree with what should be nested and under what, but I think the primary thing is that we're consistent about whatever we do.  Perhaps a central page could be created, where people can propose nesting, and from which the two of you could draw your respective code.  I'm also a bit concerned with the handling of Greek.  While it's true that Greek is somewhat unique in that its dead version arguably has as much or more fame as its modern version, I still think it would be better if it was treated in a congruent manner to other languages with dead versions like English and German.  In other words, I am suggesting that "Greek" be in the <li> and Ancient and Mycenaean be in the <dd>/<dl> .  -Atelaes λάλει ἐμοί 22:59, 7 June 2010 (UTC)

 * I'll make the argument that Old English (and Middle English) be listed separately, since there should never be an "English" translation in a table. I don't see the various flavors of Arabic listed above, and they're fairly common here.  We also have two variants of Sardinian, at least. --EncycloPetey 23:03, 7 June 2010 (UTC)

 * Dialects of Arabic could be nested as well, e.g. ary, arz, etc. I don't remember all the codes but here's an example with two Arabic dialects:

 * Arabic: ,
 * Egyptian Arabic:
 * Moroccan Arabic:
 * There are too many dialects, which can be described as country-based, region-based (more on Arabic dialects) and not all may be codified so if someone needs to add a word in their small area, they would need to do it manually. --Anatoli 23:29, 7 June 2010 (UTC)

 * I've added the list of Arabic dialects from (thanks Vahagn), and Sardinian. Making Greek consistent with other languages makes sense to me, but then making English inconsistent doesn't - I think in terms of entries at the moment, there are more with nested Greek and unnested English, but I've not counted. Conrad.Irwin 00:14, 8 June 2010 (UTC)

 * Thanks but what do you mean added? I have just tested, the nesting is not implemented yet? --Anatoli 00:25, 8 June 2010 (UTC)
 * Should work if you Conrad.Irwin 00:28, 8 June 2010 (UTC)

 * Wow, thanks. Arabic dialects work OK. Chinese - I have tested adding "zh" followed by "yue" and got an error on the 2nd translation - Could not find translation entry for 'yue:test'. Please reformat. They work OK individually but not with more than one language/dialect. --Anatoli 01:20, 8 June 2010 (UTC)

 * Overall, it's great! Thank you very much. This enhancement is a big time-saver even if you can't fix the bug. This error has been common when for example, a Japanese or Korean translation follows a Chinese (zh). Not sure why and why exactly this order caused the problem. --Anatoli 01:39, 8 June 2010 (UTC)
 * It was caused by "zh" using a classname of "trans-zh-Hani" instead of the expected "trans-zh". Now fixed. Conrad.Irwin 09:57, 8 June 2010 (UTC)

I don't know why we have Kölsch and Swiss German but none of the other German dialects under German. At the very least, and  should also go there. Probably some others too. -- Prince Kassad 09:23, 8 June 2010 (UTC)
 * They were the ones on water - as I said I really have no idea. Conrad.Irwin 09:26, 8 June 2010 (UTC)

 * Thanks again! The nested translations are working well now. --Anatoli 14:41, 8 June 2010 (UTC)

 * ?_?
 * Who committed the automatic categorization in putting all Chinese/Sinitic languages under Chinese, wouldn't you like shoving all Germanic languages, even all European languages together? Do not you find it queer that one "language" offers so different translations, while 他[ta] in Mandarin with 佢[koey] in Cantonese for he, 箇[go] in Gan with 茲[jit] in Minnan for this, or 立[lih] in Wu with 企[ki] in Hakka, 站 in Xiang[zan] for stand?
 * I refuse to contribute any more entry before this change be reverted. --Symane 16:19, 8 June 2010 (UTC)

 * These typical examples represent 1 to 5% of modern written Chinese and can fit into nested translations quite nicely, see the he, even if the written differences were larger. Most contributions are in Mandarin, anyway. The way we handle Chinese dialects/languages has been discussed ad nauseam and this is the final compromise everybody agreed on. Sorry, your contributions are too few to demand. --Anatoli 22:56, 8 June 2010 (UTC)

 * Nicely? Where do you find a language which offers so different entries? Let's take your he for example, húwwain Egyptian Arabic with húwa in Arabic, он in Cyrillic with on in Roman, while under Chinese there are distinct 他[ta], 伊[i], 佢[koey], 其[ki], etc. in different languages and the example I listed above are all defined as basic words in Swadesh list. And you may know that Mutual Lexical Intelligibility among Chinese languages varies from 19.8% to 46.1%, in comparison, German and English are 60% lexically similar. So this is your so-called "1 to 5%"?
 * And I hope that you are the only one here that contemns minority languages or less-contributed users, since this behaviour goes rudely against values that Wiki holds.--Symane 11:16, 9 June 2010 (UTC)

 * First of all, you should keep in mind that we do treat the Chineses as different languages. We recognize that Chinese is not a language, but rather a language family, with a great deal of differences between the languages in that family.  However, the trick is that most of our users are not going to look up Mandarin or Cantonese, rather they'll look up "Chinese".  Nesting the languages together is a pragmatic approach, based on what we expect users to look things up by, and should not be interpreted as meaning "these are all the same language".  That being said, your abrasive tone does not help the matter.  -Atelaes λάλει ἐμοί 11:50, 9 June 2010 (UTC)
 * It is possible, if you want to, to stop it from nesting by deleting Chinese from the "Nesting:" box under More. As this seems to be against Wiktionary formatting conventions, it's probably a bad idea - but there's no technical enforcement, just encouragement. Conrad.Irwin 12:04, 9 June 2010 (UTC)

 * Thanks for your information and I appreciate much your attitude. As we don't nest all Germanic languages together, why would we like to do such a thing on Chinese ones? Frankly, Germanic words' comparison is very essential in etymologic studies. I agree that most of users often look up Mandarin entries, so why don't us simply define Mandarin as Chinese? As when we talk of Chinese in daily life, we're usually referring to Mandarin.

How to support orthography?
For languages that have multiple alphabets (Old Church Slavonic), it's currently common to see nesting used for the different alphabets. This can be done at the moment, you just need to set "Nesting:" to "/Cyrillic" or "/Latin" (and change the "Script:" correctly too). Is there demand for it to guess (for those languages) the correct Script and Nesting based on the alphabet of the translation provided - or is that too dangerous? Conrad.Irwin 22:03, 7 June 2010 (UTC)

 * Dangerous? O_o — <font face="Lucida console">[ R·I·C ] opiaterein — 22:34, 7 June 2010 (UTC)

 * I am not sure why Serbo-Croatian needs to be nested but this has been the practice. Would a flag (Cyrillic/Roman) suffice? Same for Bokmål/Nynorsk, Mongolian (Cyrillic/Mongolian). Just my opinion. There must be a way to differentiate the scripts, though. We are not using much to point users what is Traditional Chinese and Simplified Chinese. The translations simply follow each other - trad. followed by simpl.,  Only the latter has the Pinyin transliteration. Please consider this as well when programming for script differences. --Anatoli 23:23, 7 June 2010 (UTC)

cmn/zh
Because of the nesting under Chinese, problems occur if you add a translation for "zh" (Mandarin) and then a translation for "cmn" (Mandarin). This could be resolved by converting all uses of cmn to zh and vice versa - is that a good or a bad thing to do? Conrad.Irwin 22:03, 7 June 2010 (UTC)

 * Bad thing... Zh = parent for all chinese, cmn= Mandarin, yue=cantonese... there are others, but those are the "important" ones. — <font face="Lucida console">[ R·I·C ] opiaterein — 22:32, 7 June 2010 (UTC)

 * For example, if someone says "Can I add a translation for 'zh' please?" should I add a translation for 'cmn' on their behalf? Or just refuse to do anything? Or just break? Conrad.Irwin 22:42, 7 June 2010 (UTC)

 * We have been using 'zh' for assisted translations. Although it stands for Chinese and we agreed that we need to have *Chinese followed by nested *:Mandarin, *:Cantonese, *:Min-Nan, etc. Using cmn adds a "ø" {{temp|tø|cmn|... to translations, thus it doesn't link to zh:wiki. Conrad, if you convert a zh translation into a nested translation like this:

 * Chinese:
 * Mandarin: {{t|cmn|達爾貝達|sc=Hani}}, {{t|cmn|达尔贝达|tr=Dá'ěr-Bèidá|sc=Hani}}

 * It would be fine, if "zh" is used instead of "cmn" is OK with me too. Bots change zh to cmn, anyway (as above in Casablanca) but they don't add a "ø" symbol. Obviously, there is no Mandarin (cmn) Wiktionary, since Mandarin = Standard Chinese. I'm happy that you finally addressing the nested translations. We still have many translations where it's just Mandarin (without Chinese) in translations, so automation will make this more consistent. --Anatoli 23:12, 7 June 2010 (UTC)

Analysis of phrasebook discussions
Currently, there are various simultaneous conversations about a phrasebook entry, a particular set of phrasebook entries or the phrasebook as a whole. Here is how they apparently have been mostly discussed: I suggest exercizing creativity and refraining from those repetitive arguments (unless accompanied by further context, like other arguments: discussions about the reliability of Google Books or the "nature" of a dictionary would hopefully be useful) and responses. They are well-known already and apparently rely on the inexact assumptions that there are established rules or inherent actions to be done in any such situation. --Daniel. 06:07, 8 June 2010 (UTC)
 * Argument: The [other phrasebooks; Google; Google Books; lack of policy; sheer nature of a dictionary] says that it should [be kept; be deleted; be kept in appendices].
 * Response: Your reasoning is [right, let's do exactly what you said; totally wrong, shut up and go back to doing actual work].

 * It is only natural that editors repeat those reasons in each RFD request which they find decent temporary criteria for inclusion. Recently, you have been adding phrasebook entries that are rather uncommon, without apparently knowing what you were doing. I would suggest you stop, and first get an idea of at least one necessary criterion that a phrasebook entry has to satisfy to be included. --Dan Polansky 09:46, 8 June 2010 (UTC)
 * (after edit conflict) I think we need a centralised discussion to agree on a few core things related to the phrasebook before we can get any sort of coherent answer regarding individual entries (my opinions are in italics, numbers are for ease of reference only) -
 * Do we want a phrasebook at all?
 * I'd say the general consensus is that we want at least some phrasebook entries
 * If so, should they be in the main namespace, an appendix or their own (pesudo-) namespace?
 * ''I'd say the jury is still out on this one, but my vote would be for their own (pesudo-) namespace, set to be included in searches by default (thus making them as easily searchable as currently, but with a clear grouping to show they are not standard dictionary entries)
 * Should phrasebook entries be subject to the same CFI as standard entries or different ones?
 * Personally, I'd say different ones as the main criterion should be usefulness not simply attestation
 * If they should be held to different criteria, what should they be?
 * as above, I think usefulness is a key criterion. I had a school friend who always claimed to be able to speak only three phrases in Croatian; "Where are the toilets?", "I'm sorry, I've run over your cat" and "My finger is stuck in your toaster.". These are extreme examples, but I think everyone who thinks we should have phrasebook entries would agree that the first should be included but the latter two shouldn't. Where we draw the line is a more difficult question though.
 * Who are the target audience? Tourists? Business travellers? Language students? Invading military personnel?
 * Answering this will help shape the Phrasebook CFI (if different) - if it is only aimed at tourists then "I've got an appointment with the managing director" is not a useful phrase, if it's only aimed at business travellers, "How do I get to the beach?" wouldn't be much help. Equally, language students will likely be the only group who find phrases like "What is the etymology of ?" of any benefit, but all groups would be likely to use "How do you say in ?".
 * Once we can answer these questions, then we can work on how to deal with individual entries. Thryduulf (talk) 09:48, 8 June 2010 (UTC)
 * Thank you for your comments and opinions, Thryduulf.
 * I, too, think that general consensus is that we want at least some phrasebook entries and that usefulness is a key criterion for its entries. In my opinion, the main namespace is both good enough and harmless for them to be completely defined, translated and formatted like other entries. The current CFI alone is not good enough for phrasebooks, so I suggest using WT:PB (or an improved version of PB) as the dedicated extension of it. --Daniel. 10:13, 8 June 2010 (UTC)

 * The main namespace is absolutely atrocious for a phrasebook entry. (And, could you please stop starting new discussions without resolving old ones.) It has several problems:
 * You can't see any translations without clicking, and even then they are poorly layed out.
 * You have to load a new page for every single phrase (providing you have a mechanism for finding what the English for that phrase is, which you don't at the moment)
 * And the chances are that no-one's translated that phrase into your language yet.
 * There is no point, at all, in putting all languages on the same page - when on earth is anyone going to need to use a phrasebook without knowing the target language.
 * The current CFI is not good enough because "phrasebook" entries as we currently discuss them are only those that don't fall under CFI, most phrase books would also include things like hello, which we have a dictionary entry for.
 * I strongly suggest a structure that is divided first by target language, and then by thematic subdivision - this is how most phrasebooks are done, and unless there are compelling reasons to ignore them, we shouldn't.
 * As I said above, it would be better for both phrasebook users and editors if they were to contribute to existing free online phrasebook projects. That way the phrasebooks get better faster, and we don't have to waste a lot of time re-inventing the wheel. Conrad.Irwin 10:31, 8 June 2010 (UTC)

 * Conrad, I personally considered this new discussion as the better way to convey my thoughts; and I'm glad for the responses to date. On the subject of editing other free (and open source) online phrasebooks, I haven't find any with IPA, lists of translations from English, occasional antonyms and lots of nice links to dictionary terms, so I'm inclined to edit Wiktionary rather than them. --Daniel. 11:26, 8 June 2010 (UTC)
 * Just one small point re Conrad's "You can't see any translations without clicking": Since a phrasebook entry will typically have at most one definition and minimal other stuff (etymology, homophones, etc.), I don't think that — if we wind up keeping phrasebook entries as entries — we need to use collapsible translation tables in them. They can be an exception to that rule. —msh210℠ 17:45, 8 June 2010 (UTC)

Regarding the suggestion for "a structure that is divided first by target language, and then by thematic subdivision", do you see that as something like Phrasebook:French:Shopping (with entries like "How much is that?" and "Where can I buy a loaf of bread?"), Phrasebook:Italian:Accommodation ("Where is the nearest hotel?", "I want a double room for <x> nights?", etc, or am I misunderstanding? Thryduulf (talk) 12:00, 8 June 2010 (UTC)
 * I wholeheartedly agree with what Conrad has said. A further reason to add to the list he provided is that our entries are set up to provide definitions, whereas most phrasebook phrases are not supposed to be defined but rather translated. This means that we end up giving ludicrously circumlocutary ways of "defining" phrases to avoid repeating the headword, like saying that "I have been shot" means "the speaker was hit by a projectile from a firearm". This is embarrassing and wrongheaded. < class="latinx">Ƿidsiþ</> 11:35, 8 June 2010 (UTC)
 * Widsith, your specific example of "I've been shot" meaning "[...] hit by a projectile from a firearm" does need at least one definition for disambiguation. Otherwise, that could probably be confused with "I've been photographed". --Daniel. 12:48, 8 June 2010 (UTC)
 * True enough. Although it can mean that too, of course. < class="latinx">Ƿidsiþ</> 13:04, 8 June 2010 (UTC)
 * The definition of "I've been shot" can read "I've been hit by a projective from a firearm". While it does not add much to "I've been shot" beyond what is already given at shoot, I don't find it embarassing at all. --Dan Polansky 19:13, 8 June 2010 (UTC)
 * Yup. That way it becomes possible to look up phrases by semantics rather than in alphabetical order (though we could provide an index too). It would also allow grouping of common vocab, if we wanted. 12:12, 8 June 2010 (UTC)
 * That looks like a good organisational system then, and far better than anything we could do in the main namespace. Thryduulf (talk) 12:19, 8 June 2010 (UTC)
 * I know that Daniel. has made some "appendix only" templates that would be perfect for this sort of thing. I don't think anyone is dead against the phrasebook in itself, just the current structure and content. Mglovesfun (talk) 12:29, 8 June 2010 (UTC)
 * I surely may direct my attention to the creation of templates for a possible "Phrasebook:" namespace if people can describe how it would look like and/or what functions it would have. I'm not sure if the templates that I created to date would serve this purpose. --Daniel. 14:16, 8 June 2010 (UTC)
 * I don't have any ideas about how it should look, but perhaps we should do some mockups of possible layouts. I'm wondering if looking at some wikibooks layouts, and the layouts of some dead-tree phrasebooks may give some inspiration. 14:43, 8 June 2010 (UTC)
 * Would something like Appendix:I don't speak/full be a reasonable start? I was going to fix our javascript so that the translation tables are open by default on that page, and pronunciation and other usage notes can come between the language header and the trans table. I have a script to import lists of pages into Appendices like this if we want to use it. Conrad.Irwin 22:33, 14 June 2010 (UTC)
 * I haven't got time currently to give this all the attention it deserves, but my initial thought is that the "add a translation" should be collapsed to a single line by default as it takes up too much screen estate. Thryduulf (talk) 08:11, 15 June 2010 (UTC)

Suggestion for sorting
It's a pretty rough idea, but I was thinking that a sort of banner could go across the tops of phrasebook entries that link to some kind of appendix that organizes links back to main namespace entries by situation, like a "normal" phrasebook. I also think it would be better to sort the appendices by subpages (like subpages of our user pages) instead of with colons, as someone suggested above. — <font face="Lucida console">[ R·I·C ] opiaterein — 16:49, 8 June 2010 (UTC)

 * somethin that looks like this, I guess. — <font face="Lucida console">[ R·I·C ] opiaterein — 21:05, 8 June 2010 (UTC)
 * Something that looks like...? Then, done. See I don't speak French and I've been robbed. Although, I think it will eventually be messed up when placed in pages where a table of contents exist. --Daniel. 05:50, 9 June 2010 (UTC)

 * I knew you'd be able to do it :D The only thing I'd change is the text in the middle part, but I can't think of anything to put there that would be better suited somewhere else... — <font face="Lucida console">[ R·I·C ] opiaterein — 12:31, 9 June 2010 (UTC)

 * A possibility is removing the middle text entirely, if people aren't supposed to be reminded of the "phrasebook project" when reading every entry. --Daniel. 12:58, 9 June 2010 (UTC)

 * This is excellent, IMO. If these are going to remain in mainspace, it's important that there be clear visual distinctions between the regular entries (and the rules affecting them) and the phrasebook with its unique rules. -- Visviva 13:09, 9 June 2010 (UTC)

 * I intensely dislike this - as no doubt expected. The "I don't speak French" page contains one useful piece of information which is not displayed by default, and is utterly dwarfed by a whole load of useless junk even when you expand the translation table. The yellow banner is particularly obnoxious - but I suppose it doesn't matter because it will be ignored by almost everyone. Why is the only interesting thing it has to say in the smallest font... Conrad.Irwin 13:31, 9 June 2010 (UTC)

 * I'm taking note of the suggestions: changing middle text, augmenting the size of the "interesting thing", keeping a visual clue on phrasebook entries, removing the banner completely... --Daniel. 13:49, 9 June 2010 (UTC)

 * The banner is the only thing that visually separates phrasebook entries from standard entries... — <font face="Lucida console">[ R·I·C ] opiaterein — 13:50, 9 June 2010 (UTC)

Recursive meaning
Some adjctives can apply to a pretty wide array of words at several levels, which technically cannot be quite covered by the same definition. I've generally been assuming a modicum of logic when defining such terms, but I'd like to gather some opinion.

Take monadelphous:, it can be applied to the stamen, to an organ formed by stamen fusion ("monadelphous column"), to a flower with such stamen, to a plant whose flowers (or at least those with stamen) are monadelphous, to any group or taxon defined by monadelphy etc. And this applies to all the derivatives of adelphy: as well as to a variety of plant anatomy terms (and likely to a lot of terms with similar semantic relations in the science in general). Circeus 21:26, 8 June 2010 (UTC)

 * I've seen definitions along the lines of "of, pertaining to, having, being, or resembling a ____ or ____s". They're not great, but they have two nice virtues:
 * they tend to be very complete, whereas if we try to give a separate definition for each kind of subject, we're likely to miss a bunch.
 * they make it easy for the reader to see the commonality between the various senses — and if there are also some completely different senses that are listed separately, it makes it easy for readers to see that.
 * One approach that I often like is the use of subsenses: the top-level is a catch-all sense, and the subsenses indicate different types of subjects.
 * —Ruakh <i >TALK</i > 22:59, 8 June 2010 (UTC)

 * There comes a point at which a definition can be too precise. The word grass can mean (1) an individual plant, (2) a large area of such plants, (3) a particular species of such plants, (4) a particular strain or variety of such plants, (5) a picture or representation of an individual plant of this sort, (6) a picture or representation of a large area of such plants, etc.  At some point you have to say that the various senses should be understood to be part of the same thing to a reader.  The easiest way to express this is to provide citations showing the nuances of use.  If you can include a sourced quotation that uses monadelphous to describe a plant, an organ, a species, etc. then the reader will have access to that information without your having to distill it into a cumbersome definition. --EncycloPetey 02:32, 9 June 2010 (UTC)

 * +1 on the citations thing. Though unfortunately, a lot of people don't like having citations between definitions, and proposals to accommodate such people have generally been such as to lessen the usefulness of that approach. :-/  —Ruakh <i >TALK</i > 13:00, 9 June 2010 (UTC)

 * I'm not familiar with this term, but from the information you provide it seems like something like "pertaining to or exhibiting monadelphy" might do the job. (Possibly followed by a gloss of "monadelphy".) -- Visviva 03:11, 9 June 2010 (UTC)
 * That merely shift the burden of proof to "monadelphy": monadelphy in a species, is monadelphy of each individual flowers that have male parts (not necessarily every flowers, not every individual plants...). If I define as "having all its stamen fused", then there is something really odd about a "monadelphous plant"... Plus with many morphology and anatomy terms, the adjective comes before the noun semantically. I find it much harder to define "monadelphy" than "monadelphous", if only because "monadelphy" is significantly less common and usually discussed in different context (i.e. evolutionary or taxonomic discussion, not description of plants), and logic dictates that words are defined based on more common/easier words.
 * Many, many morphological adjectives have no noun corresponding to them, or the noun is merely the adjective+noun expression (cf. tracheid:). As far as I know the actual semantic flow for, say, "sagittal" is not "along a vertical plane " -> sagittal plane:, but "sagittal plane" defined and "sagittal" meaning "along a sagittal plane". Note that sagittal axis: defines far more intuitively in the latter than the former paradigm, since you don,t have to accomodate two significantly differing meaning of "sagittal": instead you relate sagittal to both the axis and plane separately, and can then base your axis definition on the plane one. Right now IMO the adjective and noun are at best poorly related to each others.Circeus 16:57, 9 June 2010 (UTC)
 * Furthermore, you can talk about "monadelphous stamen", but I just realise need to adjust all the -adelphy compounds whenever I got time because they actually mean "Presence of X-elphous stamens", that is these words do not quite have the same application rage as the adjectives, anotehr reason why the definition is on the adjectival side here. Circeus 17:28, 9 June 2010 (UTC)
 * The same issue comes up with some nouns, such as common names of species (or genera, varietals, breeds, whatever). Peacock worm, for instance, is currently defined as "1. A particular species of worm, . 2.  A worm of this species.". I think that that's appropriate, but am willing to be convinced otherwise. —msh210℠ 17:34, 9 June 2010 (UTC)
 * That identical distinction applies to dog, cat, mouse, rat, parrot, sparrow, swallow, tern, ostrich, etc. ...as well as to petunia, violet, marigold, zinnia, daisy, etc. (although for the latter group there is an additional sense of "the blossom of this plant") The only difference among these is whether the uncountable definition refers to a species, subspecies, genus, or other taxon rank.  In any event, a countable/uncountable pair will exist for every entry that names a kind of living thng.  The uncountable is simply the common noun being used as if it were a weak proper noun, where a representative member stands in for the whole.  This choice potentially affects more than a million entries. --EncycloPetey 15:52, 10 June 2010 (UTC)

 * I think that every uncountable noun has a plural, which can be used to denote a type or member or something else. I kind of wish we could come up with sort of formula so that we didn't have to make separate definitions when they don't really exist.  -Atelaes λάλει ἐμοί 17:40, 10 June 2010 (UTC)

 * This also includes the nationality nouns, which come in several variations and are inconsistently documented in Wiktionary. We tend to split them up by proper noun & common noun as a result of our classification system, but many English dictionaries treat them as one lexeme with one definition (and indeed, in use their properness is often incomplete, ambiguous, or indeterminate). E.g., they may define Russian as “a native of Russia,” and let the reader understand that it represents the plural, common collective noun, proper (metonymous?) singular, and proper collective/national noun (or whatever; e.g. a Russian, Russians were coming and going, the Russians are coming, the Russian is a resourceful type, the Russians are a resilient people). Also, nationality vary in their natural singular or plural expressions (e.g., a Chinese sing. n., Inuit has collective and pl. inuit or inuits, First Nations [the nationality] has no singular). The Oxford Companion to the English Language (1992:813), says that “Nationality nouns (Americans, a New Zealander, the Japanese) lie on the borderline between proper and common nouns.”

 * And yes, encompassing definitions like “of, relating to, or having” are often useful or absolutely required, since some adjectives are frequently used with a truly indeterminate object, wherein the speaker or writer may not even have chosen one specific sense that is being expressed. —Michael Z. 2010-06-16 17:31 z

Bird name capitalisation
I just came across a strange incongruity between Wiktionary and Wikipedia with regards to the naming convention of bird species in English. Here, in the Wiktionary bird names are not capitalised, however in the Wikipedia they are. There this is rooted in the naming convention on birds. Why aren't these two projects harmonized on this issue, or perhaps more poignantly: why doesn't Wikipedia follow the wisdom of Wiktionary? __meco 12:14, 9 June 2010 (UTC)

 * WP says "The common name of a species is always capitalised to differentiate it from more general terms", giving the example of common starling, and cites a book that presumably says the same thing. However, if you search Google Books for common starling, you will see it's frequently not capitalised; it occurs in both forms with the same meaning. We have to go by actual usage. (So perhaps we should have it capitalised and uncapitalised? But that seems rather redundant.) Equinox ◑ 13:28, 9 June 2010 (UTC)

 * Whatever we use, the convention should be equally well thought out, or surpassing that compared with Wikipedia. A community of lexicographers should be a higher authority than any community of topic specialists on the spelling of that discipline's nomenclature. By that I mean that they may of course develop their nomenclature, but we have to evaluate it for lexicographic consistency and give our stamp of approval, or, indicate where an untenable discrepancy with the greater field has been identified. __meco 14:20, 9 June 2010 (UTC)

 * Our main entries are capitalized according to the vagaries of English usage, and we also have secondary entries with every attested variation of capitalization, hyphenation, diacriticalization, and spelling. They are essentially a summary of an ambitious research project. Although Wikipedia's titling convention is based on the “most common name,” principle, their articles, in contrast, have formal titles with an initial capital, and subject to editorial oversight and consistent according to a large style manual. There's no reason for the two projects to be consistent in this way.

 * Of course, they could make use of us in gathering evidence to determine the most common name of a thing. —Michael Z. 2010-06-09 15:00 z

 * Also, we are not a regulatory body. Our goal and purpose is not to be an advisory authority on the "correct" way things should be done, nor to give a "stamp of approval" or weed out "untenable discrepancy".  Our purpose (as with any good dictionary) is to describe usage that actually exists in the language, and not to tell people which forms they ought to be using.  English is different from many other European languages in that respect; it has no governing regulatory agency making lists of acceptable words or telling people how they should use the language. --EncycloPetey 15:07, 9 June 2010 (UTC)
 * But see The Queen's English Society who want to do/be just that. SemperBlotto 15:12, 9 June 2010 (UTC)
 * That's not the impression I have from reading their site. It's also highly unlikely they will have significant impact on the use of English in the United States at any point in the forseeable future.  --EncycloPetey 15:19, 9 June 2010 (UTC)

The finer distinction between reply and response
I often struggle picking which one of these two to use. What do the experts say? I think this problem of mine is probably shared by so many people that we might consider a section on usage notes common to both entries discussing this... __meco 14:53, 9 June 2010 (UTC)

 * I have long thought that notes explaining such distinctions belonged at Wikisaurus, but I'm not sure how they would fit in the framework that is there now. DCDuring TALK 15:25, 9 June 2010 (UTC)

 * I, differently, expect to find such explanations in the <tt>Usage notes</tt> section of each entry. Like what is done in the current English biannual. --Daniel. 15:35, 9 June 2010 (UTC)

 * If we are only talking about pairwise comparisons, that isn't so bad. But many dictionaries have much more extensive ones, comparing a half dozen words or more. To avoid further overburdening our already overlong English entries, I would have thought WS to be the prefect location. Keep the material in one place facilitates good maintenance. NOT putting such usage notes in templates facilitates contributions from more contributors. DCDuring TALK 15:46, 9 June 2010 (UTC)

 * I tend to agree with you about not wanting templates for usage notes. Perhaps the addition of a simple "Usage notes" section in Wikisaurus pages would be a reasonable alternative, but it would be rather unreadable in a page with many hyponyms, holonyms, etc. like WS:person. --Daniel. 16:15, 9 June 2010 (UTC)

 * I have no problem with using templates for usage notes. We should make our stuff for readers accessible to as many people as possible. Our stuff for editors need not be. It should be comprehensible — templates should have documentation — but need not be very accessible at the expense of utility. Having boilerplate usage notes is fine IMO. —msh210℠ 17:17, 9 June 2010 (UTC)

 * I did some research, but could find no viable distinction between the two words. However, searching for undefined: on Dictionary.com yields these usage notes:
 * Dictionary.com: " Reply usually refers to a direct or point-by-point response to a suggestion, proposal, question, or the like: a reply to a letter. A response  often suggests an answer to an appeal, exhortation, etc., or an expected or fixed reply: a response to inquiry; a response in a church service."
 * American Heritage® Dictionary: "Answer, respond, and reply,  the most general, all mean to speak, write, or act in response: Please answer my question. Did you expect the President to respond personally to your letter? The opposing team scored three runs; the home team replied with two of their own. [¶] Respond  also denotes a reaction, either voluntary ( A bystander responded to the victim's need for help ) or involuntary ( She responded in spite of herself to the antics of the puppy )."
 * I hope that helps.  — Raifʻhār Doremítzwr ~ (U · T · C) ~ 18:10, 9 June 2010 (UTC)

 * That's good. Specifically, reply implies a purposed communication or part of a dialogue, while response is more general, including things like a medical condition responding to therapy, a chemical or mechanical phenomenon, an animal or plant. However, the two are often interchangeable and useful for creative effect, e.g. “her reply to his suggestion was a punch in the nose.” —Michael Z. 2010-06-13 15:55 z

Vote Closure Rubric
I am proposing this now for two reasons: there are no hugely contentious or pivotal votes going on right now (except the penis vote) and this question has come up so many times recently that we ought to take the opportunity when it might not be swayed as much by a specific vote to get this settled. We ought to establish some form of guidelines for what constitutes a successful vote and what constitutes a failed vote. I will propose my ad hoc numbers and then we can debate them until we all hate each other. I broke down the types of votes, as different guidelines are appropriate to different types of votes. Obviously which categories of vote types should exist is another to argue about. Anyway, here is my proposal, have at it.

That was a secret :( - 21:02, 17 June 2010 (UTC)

 * Why should a demotion poll need less than two thirds support? -- Prince Kassad 21:24, 17 June 2010 (UTC)

 * It looks rather decent to me. I'm assuming that the less than two thirds support for demotion … wait, I'm actually unsure enough about this that I cannot even speculate a good reason.  Though mayhaps because demotion has the potential to be more serious?  I look forward to seeing what TDR says about why he chose that.  But other than that, this looks decent.  I'd also like to suggest that votes be closed by someone who is more or less impartial about it, rather than someone who was arguing strongly towards support or oppose, and of course this does take into consideration the judgment of the person closing.  —Neskaya … gawonisgv? 21:35, 17 June 2010 (UTC)

 * The minimum of 10 support votes for a bot is a bit excessive IMHO. --Ivan Štambuk 21:55, 17 June 2010 (UTC)

 * >1/2 is actually lenient, I was thinking initially that it should only require 1/3. If you think about it in the reverse, in order to gain whatever right the person could not be unacceptable to more than 1/3 of the community, if they become unacceptable to more than one third then they would not pass a user rights promotion vote.  Frankly if you can find a group of more than five or six regular contributors who have legitimate complaints about your behavior with whatever rights you possess you ought to consider whether or not you should have those rights.  User rights come with an understanding that they will be used for the promotion and furtherance of the project; they are a statement of trust by the community.  If a large chunk of the community doesn't trust you then there is a problem.
 * Impartiality of the person closing the vote might be a good consideration, although sometimes the only people who are paying attention to a particular vote are the ones who are invested in it. I think that with a decent set of guidelines to rely on there wont be a huge issue on most votes, and on votes which are especially contentious the parties involved can stop back and bow to impartiality when that is called for.
 * @ Ivan: For some votes I am pretty strongly in favor of the minimums, especially sysop/crat and major policy changes, perhaps the bots don't need to be lumped in the sysops, not certain about that. My main reason for the minimums was to ensure that the vote was "advertised" well enough and of sufficient duration that everyone who might wish to make a statement or weigh in on a matter has the opportunity.  Perhaps it should be ten total voters, including abstentions, which also proves that a number of people participated without requiring such a large number of voters. -  22:02, 17 June 2010 (UTC)
 * Bot votes usually don't get 10 votes even in total, and folks simply ignore them because bots usually perform a very specific function that not many people are interested in. I think that it would be safe to lower the bar to 5 supporting votes for bots. --Ivan Štambuk 22:15, 17 June 2010 (UTC)

 * I agree that abstentions should count toward quorum. (Logically, I also think that "oppose" votes should; but I don't want someone to be in the position of trying to guess whether their "oppose" could actually cause a vote to pass that would otherwise have failed for lack of quorum.) —Ruakh <i >TALK</i > 00:58, 18 June 2010 (UTC)
 * A solution to that problem (that votes in opposition should count toward the quorum but people may be loath to vote in opposition) may be to have a vote sans quorum remain open indefinitely (adding 72 hours at a time, perhaps) rather than fail. Then an opposer need not worry that his vote will cause a vote to not fail — at worst his vote will cause it to not remain open. —msh210℠ 17:14, 18 June 2010 (UTC)

 * I have a bunch of thoughts:
 * I support the general idea. In fact, I think it's more important to have this sorts of guideline than that the guidelines be perfect.
 * I don't see the point of having separate minimum and maximum durations for most of these types of votes. For policy votes I can readily see that sweeping-er and fundamental-er changes need longer than minor ones (though overall, I can't say that vote-starters seem to do a very good job of setting durations), but why should one sysop vote last for four times as long as another?
 * Rather than having a separate category for CheckUser and other WMF-regulated votes, why not just say that WMF regulations, where applicable, supersede our own?
 * I notice that this table makes no explicit provision for how to handle multiple-option voting (approval voting, Condorcet voting, etc.). Is it intended that all multiple-option votes be followed by plebiscites to accept the result?
 * Where do votes such as Votes/pl-2010-01/Number categories and Votes/2010-03/Renaming requested entry pages fit into this? Neither of those actually required a vote, but the votes nonetheless took place; with guidelines such as these, I think we need to either (1) explicitly indicate that the guidelines do not cover all possible vote types or (2) explicitly indicate that other types of votes are not appropriate.
 * —Ruakh <i >TALK</i > 00:56, 18 June 2010 (UTC)

 * I really like that this is being raised as a discussion, rather than a poll. Thanks TDR!
 * I have no comments regarding the suggested guidelines; the issues I was interested in have already been raised. However, one of the underlying concepts this is supposed to address is "What constitutes a consensus?" We want to agree (have consensus) as to when something passes or fails (consensus either to pass or reject.) This is why we should take this discussion very seriously: we will be bound by it in the future. - Amgine/talk 03:37, 18 June 2010 (UTC)

 * I think these votes are premature. We still have one of the most liberal of eligibility requirements for voting of any of the Wikimedia projects, and with important issues on policy such as these, we will again be overrun with extremist meatpuppets from other projects. Somehow we need to protect ourselves from outside manipulation before we vote on this.
 * If these should come to a vote, user's rights removal in particular should require a 2/3 majority, and only admins should be eligible to vote another admin out. If we allow the removal of an admin with a mere 51%, and count all possible voters, the Croatian Wiktionary and Wikipedia will quickly and easily pick off each one of us who is against their interferring here, beginning with Ivan. If we let that happen, it will be the end of us and the Croat Nationalists will only allow a staff of quislings and novices to hold admin status here as their puppets. English Wiktionary will go moribund.
 * I don’t have ready solutions to these problems at the moment, but I know that passing the above rules as written will be our downfall. —Stephen 07:53, 18 June 2010 (UTC)
 * I agree with your objections wholeheartedly. What do you think of elevating the voting threshold to, let us say, 200 content contributions and introducing the requirement of 3, 4 or 5 months having elapsed since the first edit? I think this approach could fairly easily beat off nationalists intent on huddling on our voting pages and could also bring us up to date with the current voting requirements on other major Wikimedia projects. The uſer hight Bogorm converſation 08:13, 18 June 2010 (UTC)

 * I think that is much more in line with what most of the other projects do and brings a realistic level of protection. Activity during a recent period is especially important. The people who do the work here and contribute to develop our project should be the ones to decide our issues. —Stephen 08:21, 18 June 2010 (UTC)

 * I agree that those issues are important, but I don't see that it's a prerequisite to resolving these. I'm not worried about meatpuppets coming in and effecting changes: they can stymie our process by making it hard to pass votes, but if they come in and start supporting changes that don't have support from actual en.wikt editors, they're going to have a hard time getting us to effect those changes. In particular, none of our Bureaucrats is about to de-sysop anyone just because a bunch of BCS nationalists came in trying to force them to. —Ruakh <i >TALK</i > 14:21, 18 June 2010 (UTC)

 * I want to reiterate that this isn't a vote, nor are the numbers and categories listed above up for approval/rejection. I intended those as a jumping off point and would love to see/hear counter-proposals and alternatives.  I made that chart in about 3 minutes and it should be taken with a grain of salt.  The concern about meatpuppetry are really a concern about voting criteria, which is not actually being considered here.  We just had a debate about that and made changes concerning that, but here I hope we can settle an entirely different issue without getting bogged down in that debate again.  Obviously the fail safe for all of our policy decisions is that the people who make the edits have the final say, as Ruakh pointed out.  If we want to institute a different mechanism for how votes are weighted or who can vote we need to start another discussion.  We might also have to invest in new HDDs for archiving it. -  19:53, 18 June 2010 (UTC)

 * I very much like this "only admins should be eligible to vote other another admin out" condition. Given the history of outsiders interfering with community policies, even in votes of rather trivial importance (such as the logo vote), it's reasonable to assume that the same thing could happen again. You and your 10 buddies make 50 edits to translation tables in half an hour, and you can pretty much desysop anyone under 1/3 pass. --Ivan Štambuk 08:25, 18 June 2010 (UTC)

 * I have a big problem with the concept that user rights in some way make a contributor more or less important. I have said many times and I will say it again: the fact that a user has certain tools available to them does not change their value to the project nor does it change the relevance of their opinion nor does it change whether or not they should be heard.  We have this idea that only people with sysop tools matter, that is patently untrue, it is even damaging to the project as a whole.  There are good contributors who do not want to be sysops, that doesn't mean they don't have valid opinions.  There are people who are sysops whose opinions on certain matters are entirely counterproductive.  Being a certain "class" of user should have absolutely no bearing on whether or not a person can participate in any process within this project.  If you are talking about community members vs. outsiders then you will have to find a better measuring stick than user rights.  If you want to go by numbers of contributions then no matter what line you draw, people will be able to exploit it.  If 50 edits can be made trivially then so can 250.  I am agreed that we don't want random people creating accounts in order to influence voting in favor of a minority opinion, but we also don't want to exclude quality contributors merely because they have not chosen to become a sysop.  All that being said, it has no bearing on the current discussion, that is about the voter criteria not vote closure policy. -  19:41, 18 June 2010 (UTC)

 * Two points about the minimum time for votes bother me. Why are we allowing some policy votes to run for only 7 days?  Should be minimum of 14 in my opinon.  Likewise, are we really going to force every removal action to drag on for a minimum of 28 days?  They've never run that long in the past. --EncycloPetey 16:50, 18 June 2010 (UTC)
 * I agree. —msh210℠ 17:18, 18 June 2010 (UTC)

 * My bad, the intention of the minimum column was not to indicate a minimum established duration for a particular vote, but the minimum amount of time a vote must be open before a WP:SNOWBALL type pass can occur. I had envisioned that all votes would have an established run time of 28 days.  There are really three occasions when user rights are removed: when a user opts out of them, when there is gross misconduct and when a no-confidence type vote occurs.  The voting is only applicable in the third case, and when this type of situation arises I think that ample opportunity to weigh in is called for.  There may be a procedural vote to uphold a decision made on the gross misconduct demotion, but that is generally after the action has occurred and therefore the duration is not as important. -  19:32, 18 June 2010 (UTC)

 * I think that most de-sysop votes have actually been for inactivity. Or does that count as "no confidence"? —Ruakh <i >TALK</i > 21:46, 18 June 2010 (UTC) —Ruakh <i >TALK</i > 21:46, 18 June 2010 (UTC)

 * I think those should be summary, as in after one year of inactivity user rights are removed without prejudice. This concept has been debated in the past without resolution but I don't think we ought to vote on them.  Either leave retired people with their rights or remove rights summarily, no need to vote every time. -  02:35, 19 June 2010 (UTC)

ISO language codes (again)
There's another debate about ISO language codes (eg jv) going on at WT:RFD about their unresolved verification. In that it appears everyone is treating them like a class I believe the discussion should be here. I propose a compromise in that the unverified entries (currently all) be treated like other Appendix-only term (unattested metric units, dictionary only terms, etc.) and be converted to. This would allow our main namespace to stay descriptivist (current CFI) and allow helpful redirection to readers. For the curious, the most recent, failed vote has links to previous discussions. --Bequw → τ 22:06, 24 June 2010 (UTC)

 * That seems promising. How would "de" (and other ISO codes that have translingual sentions with other content) be presented? As a link under a See also header? As an above-all-language-sections item like items? DCDuring TALK  22:20, 24 June 2010 (UTC)

 * I created the vote, there was no consensus to keep these. So if unattested, I think they should be deleted. I personally felt that after the vote this *had* been resolved for the short term, just not as short as this. Mglovesfun (talk) 22:25, 24 June 2010 (UTC)
 * We have always worked on the principle that a consensus is required to delete, rather than to keep entries. That is one of the fundamental principles of the entire Wikimedia project. <i style="background:lightgreen">bd2412</i> T 23:19, 24 June 2010 (UTC)
 * The vote more specifically was to keep these whether attested or not. It failed, they're not attested. I suppose the ridiculously obvious solution would be to re-run the vote with exactly the same parameters, and looking at this, it would pass. Further proof that democracy is arbitrary and unpredictable. Mglovesfun (talk) 23:29, 24 June 2010 (UTC)
 * Consensus is only needed at RFD, not RFV. We don't ignore rules like Wikipedia does. --Bequw → τ 23:46, 24 June 2010 (UTC)
 * True. I move that we include the presence of ISO codes in Wikimedia project urls as citations for the purpose of meeting the CFI. <i style="background:lightgreen">bd2412</i> T 00:13, 25 June 2010 (UTC)
 * I assume this was a joke. Please ease my mind by confirming. —msh210℠ (talk) 17:27, 25 June 2010 (UTC)
 * It was not a joke, but I didn't expect it to be taken up either. Still, why not? The Wikimedia Foundation has chosen to assign projects by language more or less by ISO code, which by itself is a usage suggesting that the codes have a meaning, that being the language to which they correspond. On the other hand, I've expressed support for moving these to an appendix in the RFD, and I think the presence of the codes in WMF urls supports that also. <i style="background:lightgreen">bd2412</i> T 19:53, 25 June 2010 (UTC)
 * URLs aren't natural language. --Bequw → τ 23:47, 25 June 2010 (UTC)
 * I would be fine with it in the Translingual section or above it. Whatever we do it should be standard for all of our Appendix-only links. --Bequw → τ 23:49, 24 June 2010 (UTC)
 * From a consistency perspective, top-of-the-entry is best, IMO. I don't think that we will clutter it up too much, until we get more than one appendix link for the same headword. It should appear on the same line as and  or  (for WP disambiguation pages). DCDuring TALK  00:34, 25 June 2010 (UTC)

I've tried out the compromise on the three different types of pages: jv (no other entries), ave (other non-translingual entries), and am (other translingual entry). I used for the first one and  for the latter two (with more informative appendix titles). What do people think? --Bequw → τ 18:33, 29 June 2010 (UTC)
 * That is ridiculous. Those were perfectly good entries. The issue with symbols is much larger than just ISO codes, and dealing with it by semi-deleting ISO codes' entries is not a solution. --Yair rand (talk) 18:43, 29 June 2010 (UTC)
 * They are absolutely gorgeous entries, but not words in any natural language or even in an invented one. They were only here because some contributors chose to enter them without attestation (or, apparently, attestability) and for a time no one challenged whether they met our basic attestation standards. If you can attest any individual ones, of course, they can be entries in the language(s) of attestation. With enough such attestation they could be translingual. DCDuring TALK 20:43, 29 June 2010 (UTC)
 * The issue here is what do we do with symbols overall. CFI allows symbols, but the problem is that the use-mention distinction does not work for symbols, and CFI gives no indication for how symbols should be attested. So, we have no policy about these. What we do have is consensus that they should be kept, and even if we didn't, we require consensus to delete entries, not to keep them. --Yair rand (talk) 21:16, 29 June 2010 (UTC)
 * I tried arguing the same about + and =, and Prince Kassad replied with 2 + 2 = 4. Genius. But seriously, the main reasons that jv would be difficult to cite is because nobody seems to know what use/mention means in this context. I don't doubt for a second that it is attestable, simply that citing it would be very difficult. This problem is underlined by RFVing words with a very common sense and other less common ones, namely man, Irish and archaic (right now I mean) where even something with 100 uses on Google Books would be hard to cite, due to half a million cites to dredge through. Mglovesfun (talk) 21:32, 29 June 2010 (UTC)
 * On the RFV page we gave examples of what attestation could look like (eg "I speak jv"). I choose [jv] specifically because it would be easy to search for. These are the not the problems. The problem is that no one appears to use these terms in natural language. --Bequw → τ 21:39, 29 June 2010 (UTC)
 * The issues is not about symbols overall, it's about unattested terms that people think merit *special* inclusion (we had the same debate about unattested metric units). And no, the CFI doesn't explicitly allow symbols as that words isn't even on the page. The use-mention distinction works just fine for symbols (most mathematical symbols could be easily attested). CFI is therefore still the policy that governs these terms. If you want to change it, get a vote passed. As above, consensus is not needed for RFV (where thankfully logic still prevails). Bequw → τ 21:37, 29 June 2010 (UTC)
 * I genuinely do think you're missing the point. Nobody actually tried to cite it. I could RFV headlight and if nobody cited it in 30 days I could delete it. In all seriousness, I think I could RFV quite a few things that exist and get them deleted, despite knowing that they exist. Mglovesfun (talk) 21:43, 29 June 2010 (UTC)
 * I tried to cite them and couldn't. These were not submitted nefariously. Lack of willingness to cite is accounted for by the RFV process. They are deleted upon failure after 30 days and re-entered once they're cited. --Bequw → τ 21:49, 29 June 2010 (UTC)
 * "Lack of willingness to cite is accounted for by the RFV process". Hmm. That's ambiguous. If you mean "the problem with RFV is nobody bothers to cite things" I agree. FWIW I didn't know you'd tried to cite them, I think that's honorable. IMO if you try and cite an RFV, always say so, so that the person who ends up deleting the entry knows that somebody has tried. Mglovesfun (talk) 22:18, 29 June 2010 (UTC)
 * Look up. "http://en.wiktionary.org/wiki/Wiktionary:Beer_parlour". Are you denying that they exist? Are you denying that they have been used in durably archived works? Are you denying that they are "terms"? Certainly it wouldn't be too difficult to find these used, but what is "usage" is completely unclear. Personally, I would not consider "I speak jv" to be usage, because it is clearly using it as though it is an English term, and because it does not have the same meaning as the one we give. I would consider things like "jv: Javanese", "Section jv", "from http://jv.wiktionary.org", "jv=Javanese", "Javanese: jv/jw | jav/jaw", "[jv]", "ISO code for Javanese: jv", "Java (jv: Jawa)", "Select language: en, fr, jv", etc. all to be perfectly good cites. Am I missing something here? How would you cite .com, #, Q, -(, ☽, ^N, ␁, { etc.? --Yair rand (talk) 22:26, 29 June 2010 (UTC)
 * (unindent) Well I do doubt en is used in natural language, given that I RFV'ed it:) The other snippets from the URL are terms that are used on their own in natural language and seem fine. Most of your 'jv' phrases you cite seem to be mentions, not uses (see Use-mention distinction). We haven't dealt previously with URLs embedded in text, but I don't think they'd be allowed as otherwise it would mean that practically every website could have an entry here. Your "Select language: en, fr, jv" seems good. Where is it and does it conform to our citation guidelines? I've now provided usages for .com, #, Q, -(, and { (examples for the obvious ones, otherwise citations). It's not full verification but it should be sufficient for you to see that it is possible and necessary to cite symbols. Several symbols incorrectly had their name, instead of their meaning, as the definition (I admit having done this earlier). I was unable to cite ☽, ^N, ␁. This may be because the characters are technically hard to search for, or that, more likely, people don't use these terms in natural language. They probably should be RFV'ed. --Bequw → τ 05:43, 30 June 2010 (UTC)

For what it's worth, I also agree with Bequw on nearly every point. These are technical specifications, not words. If they can be cited occurring in natural language, then, by all means, include them. Until then, an appendix is quite reasonable, as we do use them a lot, and might need to refer to them. Mediawiki uses all kinds of things consistently in its code. However, I don't think we should start making entries for /wiki, wgNamespace, or h2. -Atelaes λάλει ἐμοί 12:35, 30 June 2010 (UTC)

I have appendicified them. --Bequw → τ 04:39, 6 July 2010 (UTC)
 * I think that was entirely inappropriate. I think that the previous vote quite clearly showed that there is no consensus for the removal of ISO codes. --Yair rand (talk) 06:41, 6 July 2010 (UTC)
 * The vote showed there was no consensus for their inclusion, meaning the current CFI stands. If there is consensus to add the class, vote on it. If individual entries can be attested, do it an re-enter the terms. --Bequw → τ 13:15, 6 July 2010 (UTC)
 * We do not require consensus to keep entries, we require consensus to delete them. In RFV, it is assumed that the consensus-supported CFI is a good indication of an existing entry's includability, and no discussion is necessary, but in this situation, there is clearly not consensus for deleting these. (I notice that you have modified WT:AMUL so it supports your own views and actions, which was also inappropriate, IMO.) @Atelaes: /wiki and wgNamespace are used exclusively in Mediawiki wikis and are clearly not terms in any languages, and h2 exists in a single constructed programming language rather than being translingual, and thus belongs only at Appendix:Hyper Text Markup Language/H rather than in a mainspace entry. --Yair rand (talk) 03:48, 11 July 2010 (UTC)

 * Yes, clearly "/wiki", etc. do not merit entries, but that's exactly my point. The consistent use of something in urls (or other technical workings) does not qualify a thing for inclusion, not according to CFI, nor according to good sense.  The language codes may well merit inclusion (I personally think they do not), but their inclusion in Wikimedia markup is not a valid argument for their existence.  There may still be other, valid ones.  Also, I wonder if we should, perhaps think long and hard about what "translingual" means.  Biological names do exist, and are used in a number of languages, in a truly translingual way.  I agree with their inclusion here.  Any of them could easily be attested in a wide host of languages.  However, if we cannot cite something appearing in natural language (any of them), I don't think we should be using translingual as a  sort of "other" category.  Quite frankly, I almost wonder if we should simply give biological names their own L2, as in a very real sense it is its own distinct language, which, while never used in isolation, is integrated into other languages with its own very distinct set of rules and vocabulary.  But, getting down to brass tacks, why doesn't someone simply cite a few of the language codes?  If someone could cite, say five or ten of them, that would make for a very convincing argument that they're all citable, even if we don't really want to go through the trouble of citing them all.  -Atelaes λάλει ἐμοί 04:07, 11 July 2010 (UTC)
 * The CFI is not just a "good indication of an existing entry's includability", it contains the explicit criteria for includability. The attestability criteria are pretty cut and dry with no room for subjectivity in interpretation.
 * My merely clarified that it would be a misreading to think that WT:AMUL (a think tank) superseded the CFI (voted on policy). I thought it obvious that a term must first pass the CFI for individual languages before the merits of consolidation under a "Translingual" header could be considered (see  similar discussion), and especially clear after this was clarified once. Only in response to you bringing it up again did I edit the page. It is perfectly appropriate to clarify confusion during a debate. --Bequw → τ 06:15, 11 July 2010 (UTC)

Re-thinking etymology format
Ivan Štambuk expressed a desire above to be able to generate a node-like structure from the raw text of an etymology section. This is going about the problem backwards- we should start with an easily parseable format, which can then be modified to whatever other format is wanted. In addition, many pages have dense paragraphs of text that, although they have a lot of information, probably intimidate casual users. My proposal is at User:Nadando/etymology. Notice that although it would be nearly impossible for an algorithm to go from etymology 1 to etymology 2 (for every page in Wiktionary), it is very easy to go from 2 to 1, or something resembling 1. Anything underlined is a gloss, which is clearly distinguishable from the root words. This would also let us add even more information to etymologies without being completely overwhelming, such as lists of cognates. One thing that concerns me about structured etymology sections, however, is the loss of flexibility- does anyone have an example where this format would absolutely not work? Nadando 06:33, 26 June 2010 (UTC)
 * Generally I like the second format, however I don't think you have the indentation quite sorted. Most of the first block of discussion (first used...) reads as though it is about the Middle English word but the outline makes it appear to be about the Medieval Latin.
 * Also I'm also not convinced that having so much underlined is good. I generally like the setting off, but I think if you have multiple formats you need more than just two. The underlining in "from the Late Latin phrase " looks excessive, the "from" (bold) "Late Latin" (linked), "forestam silvam" (linked, italicised), and "the outside woods" (in brackets) are all sufficiently clearly set-off already that "the" and "phrase" being highlighted feels completely unnecessary and detracts from reading the whole sentence as a single piece of information. As it's such a simply structured sentence and they're such basic words, they're also not confusable with any other bit of information the setence contains.
 * Conversely in "Akin to English door. More at foreign.", you need to set off "door" and "foreign", ideally including linking to them (it also doesn't explain why "foreign", although that's nothing to do with the layout). Ditto the cognates and "more at" words in the sentence starting "Cognate to Old High German forst (“‘forest, wooded country, pine wood’”)".
 * Overall a good start, and an overdue improvement, but it needs refinement. Thryduulf (talk) 09:23, 26 June 2010 (UTC)

 * This is a good thought process, but I agree with Thryduulf that it needs refinement. The trick to making a robust etymology format is to have highly structured data.  We can do a lot more when information like what the first etymon is, what language it's from, what the cognates from that particular etymon are, etc. are actually coded into the data.  I've been thinking about a couple approaches to etymologies.  First, I think we should avoid going too far back.  In this case I don't know if we really want to go back past the Old French, certainly not past Latin.  Quite frankly, I wonder if the best approach is to only go back to the most recent etymon we have an entry for.  Going back further creates redundancies and maintenance problems.  What would be nice is if we had some JS which could take the most recent etymon, and elaborate by looking up the most recent etymon's most recent etymon, and so on.  This is not beyond our technical capacity, though it's not necessarily easy.  Additionally, I think that the default etymology we present to users should be simple, just a list of etyma, with perhaps a few highly relevant notes; no dates, no cognates, nothing more.  We have an expand button which shows etymology nerds all the extra info we have available.  With all the languages, which span all the times which we have here, some good tools could make our etymological capacity outstrip other sources by orders of magnitude.  With the data that we already have, if we had the right software, we could map the progress of the majority of the English language, showing the major inputs, time periods, all kinds of things.  We just have to iron out some technical issues.  Truth be told, a lot of our shortcomings come from poorly structured data, though we are rightly hesitant to increase the complexity of the Wikicode, as we already have so many complaints about its current complexity.  -Atelaes λάλει ἐμοί 12:15, 26 June 2010 (UTC)
 * I agree with the thoughts about providing too much information. Some of our entries really go overboard, particularly with lists of cognates and I've been idly wondering about a hideable (and by default hidden) "cognates" section, organised by etymon.
 * Regarding how far back we go, I think we might benefit from defining certain "classes" that we present, e.g. "Greek", "Greek via Latin", "Latin", "Old English", "Celtic","Germanic" "Old English", "French", "Unknown", "Unknown with possibilities", "compounds in modern, Middle or Old English", "Suffixes in modern, Middle or Old English", "Anglo-Norman", "other modern Language", "Modern English coinings", "Old Norse". For each class we would have a defined limit as to what levels we show by default. For example, the "Latin" class would not show anything earlier than the Latin by default, the "other modern language" would show only as far back as that language, e.g. "Polish" or "Japanese".
 * Indeed I think there would be benefit in providing a [i]very[/i] basic level, "bite-size" etymology, containing no more than three elements, (with an element being either a language name or an etymon) and a small list of linking words ("from", "via", "unknown", "probably", "possibly", "and", "or", "replaced"). So for example, pound: would be "Old English, from Latin via Proto-Germanic", dog: "Old English ,from Proto-Germanic", cwm: "Welsh ", hola: "Hawaiian ", ciao: "Italian", confess: "Middle English, from Latin". All of them giving options for more information, an intermediate level giving all the languages up to the top of the class, with some key etmymons and a couple of cognates at most, perhaps with the ultimate origin language but not the ultimate etymon; and an advanced level giving everything (but better presented than currently. Actually it might be better to display the intermediate by default with the bitesize in a box beside it (displayed by defaulytbut hideable). I don't know how automatable setting the levels will be, unless perhaps we given each item in the etymology a prominence field (perhaps 1-3, with bitesize etymologies displaying level 1 items only, intermediate showing 1 and 2 and advanced showing all three levels). These are all just off-the-top-of-the-head ideas so they may or may not be desirable or workable, I'm just putting them out there. Thryduulf (talk) 14:01, 26 June 2010 (UTC)
 * I wholly support only showing etymologies back to the most recent term we have an entry for (or something similarly "bite-sized"). Since we'd be referencing a particular etymology of the etymon entry we could provide a gloss. That would provide information actually going back at least 2 steps. For example, "From Old French [foo] (from Latin foobar)". Locking all the etymology information in the English entries deprives other descendants of an English etymon of useful knowledge. --Bequw → τ 16:30, 26 June 2010 (UTC)
 * I agree with Bequw. —msh210℠ (talk) 17:24, 28 June 2010 (UTC)
 * One issue with off-loading older etymological information to separate terms is that it would remove the original term from older-language derivational categories. I don't think this is too bad as I don't see much sense in English terms being in Category:Proto-Indo-European derivations (as most would be). If, however, others find this useful, we could come up with an invisible mode for . --Bequw → τ 22:43, 5 July 2010 (UTC)
 * I think this goes back to my cut-off point idea above. Say an English word has the etymological path PIE -> Proto-Germanic -> Old Norse -> Middle English -> English, then I think it should be in the derivational categories for Old Norse and Middle English. For PIE -> Latin -> Old French -> Anglo-Norman -> English then "Latin", "Old French" and "Anglo-Norman" categories would be good. Perhaps the simplest way of making the level explicit would be to include Proto languages only if there are fewer than two more recent etymons. Thryduulf (talk) 13:28, 6 July 2010 (UTC)
 * Good points (Bequw, Thryduulf). Perhaps the criterion (to be applied with sense) should be that we list the immediate ancestor (like Middle English of English if known), and then any other from which the language is not considered to have descended as a whole. —msh210℠ (talk) 13:35, 6 July 2010 (UTC)
 * Well, needless to say, I favour the complete etymology up to the entry language (as I am probably the most-to-blame perpetrator of lengthy etymolgies), excepting perhaps words recently borrowed (as in the case of Polish and Japanese above). I know this is a nightmare, but when I am looking for the origin or a word, the last thing I want is to have to click 10 times through 10 pages to find the answer. I want it all there at one time. That's just me perhaps. The alternative just feels like being lost on some wild goose chase, and God help you if a link gets moved or deleted. Leasnam 20:39, 21 September 2010 (UTC)
 * Relatedly, when an etymon is not a lemma, why note the lemma in the Etymology section when that etymon has an entry that already spells this out (see nada)? --Bequw → τ 18:42, 1 July 2010 (UTC)
 * I very much like the idea behind the structured presentation of etymological information. The structure does need to provide for the problematic cases, such as derivations involving misconstruction and converging "influences".
 * Also at every stage in the evolution of our display of etymological information a user should be able to see the Latin and Greek etymons with at most a single click. My observation of user behavior suggests that if such is not visible, some users will feel compelled to correct the entry by providing those etymons. Thus, we will be spending a lot of time removing the ones that users add and explaining why.
 * Contrary to Atelaes I think date information, though it would be redundant in an entry that is fully cited with early attestations or with Widsith's dated senses, is useful in entries that don't fully meet either standard, ie, virtually all of our actual entries.
 * Finally, often the evolution of senses would be of great interest. The apparent evolution of the senses of tram: and trolley: are examples (See Talk:trolley. How would that be presented? It does not often fit in the predominantly cross-language conceptual structure under discussion. DCDuring TALK 15:04, 6 July 2010 (UTC)
 * Re users compelled to add etymons from Latin and Greek. We could have a template like that says is like  but also displays "see further history at that entry". --Bequw → τ 22:09, 6 July 2010 (UTC)
 * There should probably be language-specific allowances for how far back an etymology should go on a single page. For English, saying that the Latin or Greek etymons shouldn't be more than a click away seems good, but other languages could have their own rules-of-thumb. --Bequw → τ 02:42, 9 August 2010 (UTC)
 * I would be happy with just getting cognates under control for now. The problem with limiting depth in English is that we often miss entries for Middle English, Anglo-Norman, Middle French, Old French, Medieval Latin, New Latin, and many middle and old intermediaries along the Germanic line. I suspect this is true of a few modern European languages. Today I ran across libertarian, with a fairly extensive discussion of sense evolution. I just hid it under . Something similar could be done with the most egregiously long cognate lists, pending a grand solution. DCDuring TALK 03:32, 9 August 2010 (UTC)

Userbox discussion
Please see Wiktionary talk:Usernames and user pages. --Yair rand (talk) 05:12, 30 June 2010 (UTC)

title: Wiktionary:Beer parlour/2010/June