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 Wiktionary: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 {{inactive}} 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 meta: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 ;) - DaveRoss 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. — opiaterein — 15:41, 2 June 2010 (UTC)

Forgot about this. Input need, tyvm. Mglovesfun (talk) 20:45, 10 June 2010 (UTC)

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. - DaveRoss 02:31, 19 June 2010 (UTC)

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)

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)

{{look}}

First he illegally deleted the entry ] 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 — 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? — 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? Ƿ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? Ƿ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 ] 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)

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

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

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 (deprecated template usage) 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)

Pursuant to the ongoing deletion discussion of n'avais, I propose the following:

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.

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. bd2412 T 15:50, 16 June 2010 (UTC)

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. bd2412 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. bd2412 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). bd2412 T 14:29, 18 June 2010 (UTC)

(Sorry this is not about phrasebooks:) When listing references, the tag <references /> includes an initial "* Notes:" This looks awkward when put in =References= sections. From what I gather, it appears that this text was added because editors weren't using standardized headers above the references list. I propose that we remove this preamble, improving the look of correct entries, and instead make cleanup lists of where they were improperly used. Are others annoyed by this? --Bequw → τ 06:09, 17 June 2010 (UTC)

I would like to see "* Notes:" removed. I have found "* Notes:" disturbing before, but have let it be. I tend to support your proposal.

In the discussion User talk:Ruakh#Cite references prefix, two reasons have been mentioned by Robert Ullmann why the bullet and the text are needed, though. --Dan Polansky 08:43, 17 June 2010 (UTC)

The other reason mentioned was to provide a transition between parts of a list that were unordered (*'s) and ordered (#'s). We could come up with formatting rules for how to deal with sections that have both. In absence of that, we could have a bot put "* Notes:" explicitly in the appropriate places. --Bequw → τ 17:39, 17 June 2010 (UTC)

I've been working on a script which allows the user to pick a language (or languages), and have any translations in that language(s) show up in the header bar (the part which is displayed before pressing "show") of a translation table. I've seen a number of folks noting the need for such functionality, especially in the context of phrasebook entries, and so I thought I'd let everyone know that it exists. I also think it would be of value to the many people who focus on one or a few languages and are interested in adding and verifying translations. To try it out, simply go to WT:PREFS, and check the "Enable targeted translation sections" option (towards the bottom, under the "Experiments" section), and then go to User:Atelaes/Customization/Translations to set your language(s). Any and all feedback is appreciated, as well as any bug reports, as this hasn't been tested well in different browsers. I think that a lot of users could greatly benefit from this ability, and would like to see it pushed to our general audience at some point in the future, so please keep that in mind as you try it. Many thanks. -Atelaes λάλει ἐμοί 11:58, 17 June 2010 (UTC)

I'm currently using this and really, really liking it. One of my big projects right now is adding translations from foreign languages that currently lack them (Bulgarian nouns, and Hiligaynon, and whatever else we don't have the translations linked in English for) and being able to set the targeted language quickly tells me whether or not I need to add the translation or whether I can go on to the next page. Thank you for this, Atelaes. —Neskaya … gawonisgv? 21:31, 17 June 2010 (UTC)

It's a nice little feature, well made. However, because all the text is shown in the same font (bold, same font size, etc.) it looks a bit messy if there are a lot of translations listed. Maybe the translations could be unbolded? —CodeCat 21:40, 17 June 2010 (UTC)

(Copy-pasted from above, WT:BP#Translating Sarkozy and Berlusconi, since this is clearly a separate issue.--Makaokalani 12:15, 17 June 2010 (UTC))

I have a proposal, though I'm sure it will be shot down by evil Wikitionarians. I propose to treat given names/surnames like animals, cities and colours, i.e. put them in topical categories. This way my last name can be treated like this:

• Պետրոսյան (Petrosyan) can be under ==Armenian==, use the code {{surname|lang=hy}}, be categorized under Category:hy:Armenian surnames
• Petrosyan (English transliteration) can be under ==English==, use the code {{surname|lang=en|transl=hy}}, be categorized under Category:Armenian surnames
• Петросян (Petrosjan) (Russian transliteration) can be under ==Russian==, use the code {{surname|lang=ru|transl=hy}}, be categorized under Category:ru:Armenian surnames

Of course, {{surname}} does not support transl=xx part yet; we should hire someone to do it. --Vahagn Petrosyan 01:37, 8 June 2010 (UTC)

Thanks, Vahagn, we have {{temp|surname|from=Armenian}}, please check Петросян (Petrosjan), it generates Category:Russian_surnames_from_Armenian. --Anatoli 02:25, 8 June 2010 (UTC)

Yes, I know about from=, but 'from=' categorizes Петросян into Category:Russian surnames from Armenian, i.e. Russian surnames, when it's not a Russian surname, but a Russian transliteration of an Armenian surname. That's why I think we need an additional parameter transl= for such cases. --Vahagn Petrosyan 02:54, 8 June 2010 (UTC)

It must be OK the way you suggest, just to fix some (?) existing entries then. --Anatoli 03:22, 8 June 2010 (UTC)

This is basically a good solution to the category problem, but it would be simpler if it were possible to have Category:en:Armenian surnames. Otherwise we'll have to move all existing names to new categories, and how will anybody guess that Category:Armenian surnames actually means English forms of Armenian surnames? Tooironic has created categories like Category:zh-cn:English male given names, and I've been waiting if somebody will cry out, "This is forbidden!" (The from= parameter refers to etymology, not usage, and some transliterations are placed in Category:English surnames from Russian for want of a better category - like Category:en:Russian surnames .)--Makaokalani 12:43, 9 June 2010 (UTC)

Makaokalani, please change a name entry as an example. It might be a good idea, if this is OK with other contributors. --Anatoli 00:15, 10 June 2010 (UTC)

The transl= parameter does not exist yet, and none of us three seem to be capable of creating it (?), so examples are not possible. To show the difference from Vahagn's proposal:

• Պետրոսյան (Petrosyan) can be under ==Armenian==, use the code {{surname|lang=hy}}, be categorized under Category:Armenian surnames (the existing system)
• Petrosyan (English transliteration) can be under ==English==, use the code {{surname|lang=en|transl=hy}}, be categorized under Category:en:Armenian surnames
• Петросян (Petrosjan) (Russian transliteration) can be under ==Russian==, use the code {{surname|lang=ru|transl=hy}}, be categorized under Category:ru:Armenian surnames

This proposal would not remove anything from the existing category system. It would be so simple and short. The problem is that "en:" isn't acceptable for category names. Could personal names be an exception? The logic is that personal names cannot be defined through English, like vocabulary words are, so English names don't deserve special treatment. Does somebody object to this proposal? If not, could somebody fix the transl= parameter? If the use of "en:" gets shouted down , it's still a good idea to make transliteration categories into topic categories, like Category:Transliterations of Armenian surnames for English, and Category:ru:Transliterations of Armenian surnames for Russian.--Makaokalani 13:12, 11 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

OK, I have moved the discussion here. I meant the difference between a topic category and a part-of-speech category. Personal names are obviously parts of speech, so I don't support Vahagn's idea in full. But transliterations can be called topics. Petrosyan is not an English surname or an Armenian surname; it's the way an Armenian surname appears in English, an English word about Armenian surnames. I will soon start creating topic categories for transliterated surnames and given names, like Category:en:Armenian surnames, if nobody protests about them.--Makaokalani 12:15, 17 June 2010 (UTC)

This seems like an improvement over the current arrangement, so no objections here. However, I still think the business of treating FL surnames as if they were words in each language in which they are used is painfully wrongheaded. Pronunciation is an obvious red herring (pronunciations of FL names are notoriously disparate), and inflection alone is scarcely reason enough for an entry. But if we're going to have these, we may as well do as best as we can with them. -- Visviva 14:51, 17 June 2010 (UTC)

Visviva, I completely agree with you. Just as I've explained in #Translating Sarkozy and Berlusconi, surnames are used in a translingual way; they are genuine words only in those languages where they are borne by native speakers. Category:fi:English surnames would be madness because every English surname is spelled and pronounced in Finnish just like in English (or at least Finns make a brave attempt at pronouncing them so). I will only create categories for transliterations - when the script changes. But this category system leaves room for other interpretations.--Makaokalani 12:06, 18 June 2010 (UTC)

Okay, I think I see what you mean: Petrosyan is categorized as a spelling used in English and transliterated from Armenian. Is this merely an orthographic–etymological categorization? If so, is it applied to all transliterated or transcribed words (the distinction may be indeterminate), or just proper names, or just personal names? First names too, or just surnames? —Michael Z. 2010-06-17 16:36 z

Only surnames and first names, never place names or vocabulary words.--Makaokalani 12:06, 18 June 2010 (UTC)

fr.wikt solves the problem by not using categories such as Noms français (French names) anymore, because they are ambiguous (this is a good example). fr.wikt now uses categories names such as Noms en français (Names in French). I would suggest to do the same (Surnames in English, etc.), which would include all surnames used in English texts (including names such as Putin), and to add subcategories in addition when useful, e.g. by origin, or transcribed surnames... Lmaltier 17:03, 17 June 2010 (UTC)

Support. Seems like the perfect solution. --Yair rand (talk) 17:47, 17 June 2010 (UTC)

Strong oppose. It would be just a cosmetic change; we would still argue about the language statements. Also against our rules: the French wiktionary entry for Poutine is in "Catégorie:Noms de famille russes en français". That works because in French you can add an adjective to a noun. In English it would be "Category:Russian surnames in French", which means the word should be Russian - and surely we all agree that Poutine is not a Russian word? This kind of category names (like "Armenian surnames in English") have been discussed before and abandoned because the language statement would be wrong.--Makaokalani 12:06, 18 June 2010 (UTC)

What would be wrong with calling it "Surnames in French from Russian"? --Yair rand (talk) 17:56, 18 June 2010 (UTC)

Like Vahagn explains above, we use from= to categorize names by etymology. French wiktionary makes no difference between etymology and transliteration - so they have "solved the problem", that is, they haven't noticed it yet.--Makaokalani 11:37, 19 June 2010 (UTC)

To clarify what I mean, I proposed to use in Language in all language-dependent categories, without any exception (not only for surnames), i.e. to always use the language name, never the adjective. This clarifies the meaning in many cases (e.g. you can have categories such as French towns in English, where French relates to France, not to the language). Using this rule in a systematic way would make things clearer for users. Lmaltier 20:18, 18 June 2010 (UTC)

You are suggesting such a huge category change that the discussion really belongs somewhere else. I have always found our surname and given name categories easy to understand, and the new transliteration categories make them much more accurate than the French ones. In general, I don't see why the order of words in category names is so important. It has no effect on the content of the entries, and changing names every year is much more confusing than the names themselves. I think we could spend our energy on something more useful. --Makaokalani 11:37, 19 June 2010 (UTC)

Could we have a list of all of these? Or a name for a topic category? __meco 12:24, 17 June 2010 (UTC)

Toponymic prefixes (is that along the lines you're talking about?) —Saltmarsh^{απάντηση} 17:29, 17 June 2010 (UTC)

Country prefixes. __meco 09:51, 20 June 2010 (UTC)

Well, we have Appendix:Nationality prefixes, which I think is a good identifier. --Bequw → τ 03:51, 21 June 2010 (UTC)

I've been setting up rhyme pages for refractory and obscure rhymes, and some of these have been inflectional derivations. Encyclopetey tells me that the rhymes tables were not set up for that, but that was before we started adding such forms as entries.

I'm not interested in taking on a massive expansion of the rhyme tables myself, but is this something we'd want to do? Should it be possible to add the rhyme to every entry on WT, or should non-lemmata entries be off limits? Or maybe should we take a middle road, allowing expansion if there's an interest in doing so (say, for mulcts, which has no rhyme, despite the fact that its lemma mulct does), without trying to provide universal coverage?

I may not see answers here, depending on how long it is before I log on again, so if you decide not to allow non-lemma rhymes, please let me know on my talk page or by email. kwami 00:01, 18 June 2010 (UTC)

I think that the utility of rhymes varies greatly based on language. Ancient Greek would not benefit from a rhymes section, and I would hastily lob empty threats at anyone who tried to add them there. I think that, in general, highly inflected languages, like Ancient Greek, don't take much stock in rhyming, because it happens so very often, whereas languages with minimal inflection, like English, do. Consequently, each language should decide whether rhymes are appropriate for it. However, there are other metrics which can be analyzed besides rhyming. Ancient Greek poetry used metre instead of rhyming, and I have idly considered organizing Ancient Greek words based on their metrical footprint, similar to how English words are organized based on their rhyme. -Atelaes λάλει ἐμοί 00:09, 18 June 2010 (UTC)

For English, at least, I would be fine with allowing non-lemmata to be listed. I do think that however we decide, we should apply that decision consistently (at least in English). This might mean sending a bot in to remove the existing comments in the English Rhymes pages that discourage the addition of non-lemmata. --EncycloPetey 00:16, 18 June 2010 (UTC)

I can certainly see summing up non-lemmata with a comment like "also rhyme with plurals of X" on the rhyme page, rather than actually listing them. However, I don't see a problem with linking to a rhyme page, with the 'rhymes' template, from entries for non-lemmata. kwami 00:34, 18 June 2010 (UTC)

At least for English and Welsh (where inflections can completely change the stress pattern), I think that all words (including inflections) that have a rhyme should have this noted in the pronunciation section of its entry. As for tables of rhymes, I don't think that these should contain links to every word with that rhyme. Rather the pages should contain a selection, typically of the most common and/or most useful, and link to a category that contains all the words. This is the model used for gallery pages and image categories at Commons. Thryduulf (talk) 08:38, 18 June 2010 (UTC)

And that's one of the things I find most irritating about Commons. It won't work well for rhymes, because the link to the entry should be language-specific. We can't control that in a category listing. A ctageory links to the page. This would also require that an entry exist before the rhyme could be listed, so we'd end up de-listing a lot of our current rhymes. Category-based Rhymes listings are not a viable option. --EncycloPetey 16:48, 18 June 2010 (UTC)

I'm sorry but I don't understand that comment at all. Categories would be in the form of Category:Rhymes:English:-ɪʃ, Category:Rhymes:German:-ən (or similar) not mixing any languages. A brief scan of a random sample of 10 English rhymes pages shows no redlinks, and anyway I would not propose removing any that do exist (although clearly the best thing to do when you find one is to write an entry) - categories are not a replacement for pages but a supplement to them. Indeed, it would probably benefit for the category description pages to be transclusions o f the rhymes namespace pages. Categories would be very easy to populate by modifying the {{rhymes}} template to additionally do the categorisation. This would make rhymes much easier to find, as currently you have use the unsorted and (afaik) unsortable special:whatlinkshere tool and then filter it by namespace to find all the rhymes, not just the ones an editor has added to the page (which varies from all to a tiny fraction). Thryduulf (talk) 23:10, 18 June 2010 (UTC)

I've been setting up rhyme pages for refractory and obscure rhymes, and some of these have been inflectional derivations. Encyclopetey tells me that the rhymes tables were not set up for that, but that was before we started adding such forms as entries.

I'm not interested in taking on a massive expansion of the rhyme tables myself, but is this something we'd want to do? Should it be possible to add the rhyme to every entry on WT, or should non-lemmata entries be off limits? Or maybe should we take a middle road, allowing expansion if there's an interest in doing so (say, for mulcts, which has no rhyme, despite the fact that its lemma mulct does), without trying to provide universal coverage?

I may not see answers here, depending on how long it is before I log on again, so if you decide not to allow non-lemma rhymes, please let me know on my talk page or by email. kwami 00:01, 18 June 2010 (UTC)

I think that the utility of rhymes varies greatly based on language. Ancient Greek would not benefit from a rhymes section, and I would hastily lob empty threats at anyone who tried to add them there. I think that, in general, highly inflected languages, like Ancient Greek, don't take much stock in rhyming, because it happens so very often, whereas languages with minimal inflection, like English, do. Consequently, each language should decide whether rhymes are appropriate for it. However, there are other metrics which can be analyzed besides rhyming. Ancient Greek poetry used metre instead of rhyming, and I have idly considered organizing Ancient Greek words based on their metrical footprint, similar to how English words are organized based on their rhyme. -Atelaes λάλει ἐμοί 00:09, 18 June 2010 (UTC)

For English, at least, I would be fine with allowing non-lemmata to be listed. I do think that however we decide, we should apply that decision consistently (at least in English). This might mean sending a bot in to remove the existing comments in the English Rhymes pages that discourage the addition of non-lemmata. --EncycloPetey 00:16, 18 June 2010 (UTC)

I can certainly see summing up non-lemmata with a comment like "also rhyme with plurals of X" on the rhyme page, rather than actually listing them. However, I don't see a problem with linking to a rhyme page, with the 'rhymes' template, from entries for non-lemmata. kwami 00:34, 18 June 2010 (UTC)

At least for English and Welsh (where inflections can completely change the stress pattern), I think that all words (including inflections) that have a rhyme should have this noted in the pronunciation section of its entry. As for tables of rhymes, I don't think that these should contain links to every word with that rhyme. Rather the pages should contain a selection, typically of the most common and/or most useful, and link to a category that contains all the words. This is the model used for gallery pages and image categories at Commons. Thryduulf (talk) 08:38, 18 June 2010 (UTC)

And that's one of the things I find most irritating about Commons. It won't work well for rhymes, because the link to the entry should be language-specific. We can't control that in a category listing. A ctageory links to the page. This would also require that an entry exist before the rhyme could be listed, so we'd end up de-listing a lot of our current rhymes. Category-based Rhymes listings are not a viable option. --EncycloPetey 16:48, 18 June 2010 (UTC)

I'm sorry but I don't understand that comment at all. Categories would be in the form of Category:Rhymes:English:-ɪʃ, Category:Rhymes:German:-ən (or similar) not mixing any languages. A brief scan of a random sample of 10 English rhymes pages shows no redlinks, and anyway I would not propose removing any that do exist (although clearly the best thing to do when you find one is to write an entry) - categories are not a replacement for pages but a supplement to them. Indeed, it would probably benefit for the category description pages to be transclusions o f the rhymes namespace pages. Categories would be very easy to populate by modifying the {{rhymes}} template to additionally do the categorisation. This would make rhymes much easier to find, as currently you have use the unsorted and (afaik) unsortable special:whatlinkshere tool and then filter it by namespace to find all the rhymes, not just the ones an editor has added to the page (which varies from all to a tiny fraction). Thryduulf (talk) 23:10, 18 June 2010 (UTC)

Picking up on the subject of whether user examples should be shown or hidden, discussed in this thread "Hideable stuff revamp": I really liked how I only saw definitions, having both example sentences and quotations hidden. I am not saying what the default should be for anonymous users; it could be better to show example sentences and quotations by default, or not--I don't know. IMHO those among quotations whose main purpose is to attest rather than illustrate should be placed to Citations namespace anyway, so the definition section of the mainspace should only host quotations that are as interesting as example sentences. For me, it makes most sense to always hide both example sentences and quotations or none. Above, having example sentences shown while quotations get hidden seems to have been supported by EncycloPetey, msh210, Vahagn, and Ruakh, though. --Dan Polansky 18:02, 21 June 2010 (UTC)

Replying here as I'm not sure where my comment fits in the above section, but I'm firmly in the example sentences should be shown by default camp. Particularly where a definition is complex, and for language learners, they are invaluable in understanding the definition. I'm not a regular reader of feedback, but when I do example sentences are usually either praised or requested. I wouldn't object to making them hideable, but leave them shown by default. Thryduulf (talk) 08:26, 22 June 2010 (UTC)

I recently rewrote much of the NavBar stuff which has been loitering in our javascript for rather a lot of time now. I've made one intentional change, and if you spot any other differences, please let me know. The change you should notice is an additional toolbox - in which different categories of objects can be persistently (per-web-browser) hidden or shown. If this is a reasonable success, then Atelaes and I intend to enable his hideable quotations javascript (see WT:PREFS) for everyone. I've tested this in monobook on IE6 and in monobook/vector on firefox and chrome. It would be good to get explicit notification of success or failure in other combinations and versions. Conrad.Irwin 02:39, 18 June 2010 (UTC)

Hideable quotes is now live and being fed to all users. The WT:PREFS option has been disabled, and those of you who've been testing it up to this point may have to refresh your caches. Any feedback or bug reports are more than welcome. To those of you who've been itching to add lots of good quotations, now's the time. -Atelaes λάλει ἐμοί 14:42, 18 June 2010 (UTC)

Unfortunately, this means that quotes are hidden for everyone, with 'no option to show them. This is wrong. People who work with quotes should be able to opt out of this. --EncycloPetey 16:45, 18 June 2010 (UTC)

Click "Show quotations" in the sidebar under "Visibility". --Yair rand (talk) 17:46, 18 June 2010 (UTC)

The link to show the hidden quotes is way too small. It should be at least one notch larger. -- Prince Kassad 16:53, 18 June 2010 (UTC)

I have a dumb question: can the default option for certain languages be set to "show quotations"? Ever since you implemented this thing I have been afraid users may not suspect there are plentiful and nice usage examples in my entries like հարկանեմ (harkanem) and miss them. If I understand correctly, the purpose of hideable quotes is reducing clutter on pages but for obscure languages with zero (literally, zero) resources on the net overfeeding information is not a concern. PS. The "Show quotes" button can be bigger. --Vahagn Petrosyan 16:55, 18 June 2010 (UTC)

Additional problem: The hideable quotes "Feature" is also hiding the example sentences, which are a near-essential bit of information on some entries for understanding the difference between senses. I thought only quotes were going to be hidden. The problem is additionally that the exampes sentences are hidden behind a tag that says "quotations". We already have confusion about the distinction between example sentences and quotations; this will compound that problem. --EncycloPetey 17:40, 18 June 2010 (UTC)

It seems that there are two possible solutions, either show the example sentences all the time, or add a button just for examples. A few definitions will then have two buttons - would either be acceptable? Conrad.Irwin 18:01, 18 June 2010 (UTC)

I would like example sentences to always be visible. When I need to learn a new word in English, I find short examples even more helpful than a definition. Long quotations, on the other hand, do clutter the page and are found in large encyclopedias of language like OED and Webster's Unabridged: never used by me to learn the meaning of a word. --Vahagn Petrosyan 18:11, 18 June 2010 (UTC)

Personally, I think showing example sentences all the time is the way to go. The example sentences on tener (Spanish) are very, very useful. We tend to remove/reduce example sentences once we have a good selection of quotations. I agree with Vahagn that the quotations usually given in dictionaries are not helpful for learning the word (Lewis & Short's Latin quotations are so compressed I often can't tell anything from them), but I try to choose quotations that will aid in understanding, then put the remainder in the Citations namespace. Quotations can be as useful as example sentences when they are carefully selected. --EncycloPetey 18:16, 18 June 2010 (UTC)

I think it would be better if example sentences are hidden by default, with there being two separate buttons to show/hide quotations and examples. A large amount of example sentences really stretch out the page, and having them hidden at the start allows many more examples to be given without adding tons of clutter. --Yair rand (talk) 18:17, 18 June 2010 (UTC)

I think usexes should be shown by default (or always) per Vahagn's and EP's arguments.​—msh210℠ 18:26, 18 June 2010 (UTC)

Also, example sentences visually separate sense lines from each other, which I find useful for some reason. --Vahagn Petrosyan 18:30, 18 June 2010 (UTC)

Usexes are not hidden for the moment according to the opinions of EP, msh210, Vahagn and me. Conrad.Irwin 19:12, 18 June 2010 (UTC)

+me. :-)   —Ruakh_TALK 19:28, 18 June 2010 (UTC)

Hm, having example sentences hidden would allow for tons of helpful example sentences to be added, but keeping them displayed by default also has its advantages. So how about this possibility: One example sentence per sense is shown by default, with a "more examples" button on the right for displaying the rest. Does that sound like a good idea? --Yair rand (talk) 20:16, 18 June 2010 (UTC)

Not to me. We anyway only have as many usexes as needed to show how the word is used (e.g., how it collocates with prepositions, if it's an English verb), so I think showing them is important.​—msh210℠ (talk) 20:19, 18 June 2010 (UTC)

Yes, but with some usexes hidden we have the opportunity to allow more example sentences than absolutely necessary, to have five or more examples per sense, which we certainly can't do with all of them displayed by default. --Yair rand (talk) 20:23, 18 June 2010 (UTC)

Even five or more usexes, assuming that they satisfy WT:USEX, should be shown by default IMO. (And if they don't meet WT:USEX, they shouldn't be there at all.)​—msh210℠ (talk) 20:27, 18 June 2010 (UTC)

I think that the default should be don't hide anything (neither examples, nor translations...). Requiring too many clicks to be able to get all information is a serious problem with many Internet dictionaries. Users are too lazy, or not curious enough, and many users are not quite aware of how much information is available (e.g. they might imagine there are one or two translations, where there are translations to 100 or 150 languages). But providing a way to hide some parts is OK: if somebody chooses to hide something, he must be aware that it's available... Lmaltier 21:03, 18 June 2010 (UTC)

Well, a lot seems to have happened since I last signed on. I maintain that my original setup was preferable, for a few reasons. First, I agree that example sentences are useful, but I've always considered them a cheap placeholder for an actual quote. If we can't find a real example of usage that illustrates a sense as well as the example sentence, then we probably got the example sentence wrong. The whole point of hideable quotes is to make our entries more navigable. The simple fact is, right now, our entries are obscenely ugly, and on entries with a decent amount of information, are nearly impossible to parse. Consequently, while this may be counterintuitive, hiding information can actually add information, as a typical user is far more likely to be able to comprehend the entry and navigate it. Respectfully, Lmaltier, not hiding any information is absurd. On many entries it would mean forcing a user to wade through pages and pages of text. I'm not quite sure why, but we seem to be under the impression that all of our users are somewhere between chimps and neanderthals, which I think is incorrect. I think the vast majority of our users will find a clearly labelled button, sitting next to the text they're already looking at, to be an intuitive and easy thing. I won't revert what appears to be the consensus, but I beg you all to reconsider your positions. -Atelaes λάλει ἐμοί 00:10, 19 June 2010 (UTC)

I consider my own experience, and I don't consider myself somewhere between chimps and neanderthals. This has nothing to do with intelligence. What is of interest to users is different for each user (definitions? pronunciation? translations? anagrams?). It's very easy to skip a part of no interest and you should not forget the table of contents, it's something very important for navigation. Lmaltier 05:35, 19 June 2010 (UTC)

Agreed. Users are using the site for different purposes. However, I think that hidden content is the best way to serve that. Hidden content is now configured so that Wiktionary tells what people are looking at, and shows them that, and only that, automatically. I think that TOC's are not a good approach in a dictionary context. -Atelaes λάλει ἐμοί 05:40, 19 June 2010 (UTC)

I strongly agree with every point that Atelaes has made above, except the throwaway about usage examples being a poor substitute for citations. Many citations are only useful for attestation (eg, demonstrating that something is a true adjective). Sometimes minimally different usage examples are necessary to illustrate grammatical points. Thus there may still be good reason to keep quotations in citation space. DCDuring TALK 00:40, 19 June 2010 (UTC)

While most citations currently don't provide good examples of typical usage, there is no a priori reason they can't. Perhaps it would be ideal to have a special style for those citations that have been chosen specifically to satisfy WT:USEX -- then these could be shown whenever invented usexes are shown. I have come across far too many outright misleading and wrong examples to have any faith in our ability to invent satisfactory examples out of whole cloth. -- Visviva 03:23, 19 June 2010 (UTC)

There is so much that goes into selecting a really excellent quotation that it is very difficult and time-consuming to do. Even though I've added more than a few quotations, there are only perhaps a half dozen of those where I would rate the quotations I selected so highly. This becomes even more challenging when working in a foreign language that must then have the quotation translated. For tuly common words, a made-up example allows a faster, cheaper way to express usage in a concise way. Finding something of equal value in a quotation takes many, many times longer. Compare the results of examples used on tener (Spanish) with the quotations on quattuor (Latin). The tener examples are short and to the point, without lots of additional grammar or translation to sift through. The quotations at quattuor, while carefully selected to show meaning in context, and to cover a wide range of dates, require a lot more reading and parsing to interpret. It might be possible to find shorter quotations, but that could very well sacrifice the illustration of grammar or the demonstration of the meaning from context. Quotations have to do a lot more than example sentences do, and this heavier burden of responsibility often makes them harder to use in place of examples for simple or common words. --EncycloPetey 03:50, 19 June 2010 (UTC)

I agree. There are many conflicting goals for quotations — early attestation, late attestation, counting toward CFI, clear meaning, clear construal, typical context, etc., etc. — and while is-a-decent-usex is definitely a good goal, I don't see why it should win out over all the others. And honestly, when I'm citing an entry with a lot of senses, I usually perform searches based on collocations that I expect will turn up a given sense; this is slightly better than making up a usex out of whole cloth, but it still means I end up with the quotations that most closely resemble the usex I would have written, rather than the quotations that most accurately reflect the most common usage. (Hopefully the distance from one to the other is not so great, but none of us has his finger perfectly on the pulse of the entire English language.) —Ruakh_TALK 06:19, 19 June 2010 (UTC)
That said, I do like Visviva's idea of somehow indicating that a given citation can be presented as a usage example. I just don't think we should expect too much. (And even a perfectly usexy citation has all that bulky metadata, unless we can figure out a clean way to hide that while still making clear it's a quotation.) —Ruakh_TALK 06:23, 19 June 2010 (UTC)

I am in the hide as much as possible camp, if I arrive at an entry I want to see Language, Part of Speech and as many definitions as possible without scrolling. Everything else I want available on investigation but if definition lines or additional parts of speech are being pushed off the bottom of the page (at 1920x1200 no less) then we are doing it wrong. I would estimate that dictionaries are being used for the following reasons in order of commonality: definition > spelling > translation > etymology > trivia. We ought to make the top options as accessible as possible. While we are not a paper dictionary, we ought to learn some basic web design principles, namely that screen real estate has value and we are often wasting it on parts of entries (ToC *cough*) which don't add much value to the entry. I guess I am agreeing with Atelaes too. - DaveRoss 02:16, 19 June 2010 (UTC)

Each time this issue arises, the same empty arguments about "real estate" are regurgitated and then statistics are invented or pulled out of the air. We've had plenty of comments left now in Feedback from people who specifically came here for pronunciation (which I assume you place under "trivia" as you didn't list it at all) or for translations, so "estimating" those items to be of little importance is flat-out wrong. We can't (and shouldn't) be guessing at what's important or making sweeping decisions based on those self-invented ideas. The fact that we have so many regulars balking at the idea of hiding quotations for everyone by default should show that it's not such a simple issue. --EncycloPetey 03:50, 19 June 2010 (UTC)

Well, unfortunately, I don't think we have any idea of what our users are like at all. We don't know what they're coming here for, how they're using our site, what format issues are problematic for them, anything. I think we all agree that we want to make this site as useful as possible for as many people as possible, but we all have different ideas of what that would look like. Unfortunately, until we get some hard data (no idea how to do that), all we have to throw around is empty, baseless assertions. However, I think we should be careful about assuming that the status quo is somehow intrinsically better. Oh, and just to fend this off ahead of time, let me be quite clear that WT:PREFS is completely fucking worthless to our average users. The only people who use it are us, Wiktionary's regular editors. No one else. So please, no one start going on about how we should allow everyone to set things up how they like. So, unless a function automagically picks up a user's preference (like the new hiding mechanism potentially can), user prefs don't exist. We have to make the default the best option. Our feedback page can give us a very foggy glimpse, but the selection bias is just far too strong for me to even consider the possibility that it's a representative sample. Oh, and I'm pretty sure that we get a whole lot more comments on there about "I can't find anything" than anything else. This combined with my own intuition is what makes me think our entries are currently unparsable. -Atelaes λάλει ἐμοί 04:02, 19 June 2010 (UTC)

Re "what format issues are problematic for them, anything.... until we get some hard data (no idea how to do that)...": We do have the feedback buttons, and although WT:FEED clearly shows that some users press the wrong button (can we add a "oops I pressed the wrong button" button for after the feedback is sent, which wil add a line to the feedback table indicating that the preceding line on that entry is wrong, or something?), I think we can safely assume that the vast majority press exactly what they mean. We also have hard facts about entries: how many levels of nesting of headers each has, how many languages, how many POSes, how many senses, whether it contains right-hand boxes ({{wikipedia}}, images), whether it has a counterpart that should be linked to via {{also}}, whether it has a counterpart that is linked to via {{also}}, whether it has quotations in the page (and how many), whether it has usexes, whether it has a citations: page, etc., etc., etc. We can run statistical analysis on the data, try to find what correlates with good/bad feedback.​—msh210℠ (talk) 16:34, 21 June 2010 (UTC)

Why should we not guess? Why should we not estimate? We make determinations all of the time about what is important and what is not, that is what our entire CFI and layout are based on. In my opinion, as was clearly indicated by the phrasing of my above statement, our use of screen space is not good. I refuse to believe that a page which, when loaded, shows only the sidebar and the first half of the ToC is as useful as a page which, when loaded, shows the first 3 parts of speech and 12 definitions. The company I work for sells stuff, and we use several media to accomplish that goal. Two are catalogs and a web site. One of the most common statistics I hear when talking to the people who do the development for those two things are the cost per square inch and the value of placement. Stuff at the top left of the web page sells MUCH better than stuff at the bottom right, and stuff which requires scrolling down sells much worse than either. The concepts of "above the fold" and "below the fold" are huge to the people who use websites for selling. We use a website to promote information, we can adopt similar concepts. And I apologize for missing pronunciation (and several other things) it is probably right in there with spelling. We could also make a proper poll for our users to communicate what they are looking for in a dictionary. - DaveRoss 11:52, 19 June 2010 (UTC)

How do I turn it off, so that inline quotations are not automatically auto-hidden? --Ivan Štambuk 11:57, 19 June 2010 (UTC)

Simply press the show all quotes button on the left hand toolbar once, and it should remember your preference. -Atelaes λάλει ἐμοί 14:39, 19 June 2010 (UTC)

The soon-to-be-adopted vector skin has a standard w: disclosure widget style, visible in the left sidebar. It's a grey triangle that points rightwards into the heading where the collapsed content is hidden, and then rotates down to point at the expanded content. The reveal also has a slick animated transition, which makes the change less jarring, and potentially less confusing.

Shouldn't we adopt a similar style, for consistency? I can see no advantage in having two interfaces for one kind of control. Perhaps we can save redundancy by making use of vector's graphics and JavaScript.

Also, our control's text is a noun, while our our translations sections' control has a verb. (I don't get why the edit button for glosses reads “±”, when “minus” is not an option.)

(See also Wiktionary:Beer_parlour_archive/2010/May#New_and_improved_hideable_quotes.) —Michael Z. 2010-06-22 04:31 z

If you are using something from vector, make sure it also works on monobook. Vector has a huge amount of issues about not working properly on even slightly obscure systems and there are plenty of people (me included) who will continue to use monobook as they find it aesthetically superior and more user friendly (not least because of the vastly superior page load time). I don't have a problem with using the vector style, just make sure it works. Thryduulf (talk) 08:18, 22 June 2010 (UTC)

If you can design an interface that is as easy to use as the current one, and that is consistent with vector, I'd be happy to try and implement it. My design skills are not up to the task. That said, I personally detest Vector's use of animation, it's slow and distracting. I'm also convinced no-one except Usability experts has ever looked at buttons with different parts of speech and found them inconsistent - whereas we changed Vector's "View history" tab back to "History" a long while back so that every tab was a single word - much more consistent :). "show" has always been show, not sure how to change that given the wide variety of uses - though we could remove the word entirely as it adds no more information that then triangle - while "quotations" is needed to explain what the button is for. The edit button for glosses was chosen because I wanted a symbol (instead of which does something else, or which is overly large for such a minimal function), and I've seen that symbol used in place of "edit" before (you can + and - individual words to your hearts content), maybe it should be a pen instead? Conrad.Irwin 10:21, 22 June 2010 (UTC)

This is vaguely related to above, but we have an interesting (and long) conversation running there, and I didn't want to muddle it with this. There was a minor bug with the navbars, which caused them to break when doing a "Show Preview". It has since been fixed. However, having gone through an uncharacteristic editing spree of late, I recognized the merits of having hidden content shown when previewing. I think that, all too often, hidden content remains hidden for us editors, and this can lead to that content undergoing less scrutiny than it should. For example, take the history of σπάθη, where I neglected one of the variables of the inflection template. A minor error, but one which almost certainly would have been caught, had the content been shown when I hit "Show preview", which being a good editor, I always do. So, I propose that we force the terrible burden of all that hidden content onto the Wiktionary editors. Now, to head off the rants about the evils of hidden content, I dare any of you to try and use water with all the hidden translations showing, or to open up all the inflections in ἐξίστημι, and then see if you can get to the references before your page down button and scrollwheel both break. Let's be clear, showing all hidden content is a nightmare, one which we should never impose on our poor readers, but should perhaps subject ourselves to for their sake. -Atelaes λάλει ἐμοί 12:08, 19 June 2010 (UTC)

I chose to view everything and I found errors in translations in water (at least for the alphabetical order, see last languages). I would have missed them with a hidden content (hiding info also hides errors...). I find that long lists of translations are quite impressive, that this is a good thing, and that the scroll bar is sufficient if you want to skip them efficiently. Lmaltier 20:17, 19 June 2010 (UTC)

Certainly I'd be in favour of showing hidden content when previewing (I mightn't have had to make this edit if the quotations hadn't been hidden by default on a preview). I would also find it useful when viewing a diff to have hideable content shown by default, but other than that I don't want all stuff always shown, so I'd like more control than simply always shown or always hidden. Thryduulf (talk) 12:22, 19 June 2010 (UTC)

No, no, I wasn't proposing that it all be shown always, not even for us. I was simply proposing that all hidden content be shown by default on previews. -Atelaes λάλει ἐμοί 12:30, 19 June 2010 (UTC)

I make a lot of typos and other blunders. It would certainly benefit entries I work on if it worked that way. DCDuring TALK 13:58, 19 June 2010 (UTC)

The old translation tables were always when editing a section, I think that is a good compromise as there should be a manageable amount of stuff. Conrad.Irwin 19:58, 19 June 2010 (UTC)

It frequently happens that a book will claim that it's telling a true story, but it's still hard to believe that all dialogue is 100% accurate. Normally I don't worry about it too much — even if the book is wrong, it at least demonstrates that the author uses this word, more or less. In the relatively few cases where the author is a speaker of Standard English quoting a speaker of, say, AAVE, and for whatever reason I'm suspicious that maybe the author got the speaker's grammar wrong, I'll usually just pass up on the quotation, on the principle that the book can't be considered a reliable source. So, while slightly frustrating, that's not really a problem. But there are still a few problems I encounter that I don't have good solutions for:

• Sometimes the book is written many, many years after the conversation took place, and the quotation is based on the speaker's recollection (or the recollection of an acquaintance whose dialect is likely to be trustworthy). Here the only real problem is the date: the quotation is putatively from a certain date, but the book is from a much later one, and there's no specific reason to believe that the word really existed at the time of the quotation, as opposed to the time of recollection. People frequently remember familiar expressions as having been around for much longer than they actually have.

• Sometimes the context surrounding the quotation is really essential to understanding the quotation. For example, the quotation might consist of just a predicate, along the lines of:

  Taylor says that the two groups “just don't see eye to eye.”

  Or it might consist of the entire utterance, but the utterance doesn't really make sense without context; see ] and ] for some examples. But if we attribute the cite to "so-and-so, quoted by such-and-such", then I'm not sure it really makes sense for the cite to contain that context (since the context is from such-and-such, not from so-and-so).

How do y'all handle these cases?

—Ruakh_TALK 00:58, 20 June 2010 (UTC)

I use the quotee parameter, like so:

• (Can we date this quote?), Sum Young-Guy, quoting Sum Old-Guy, Read Meeee, page 3456:

  Blahde blah blah blah

The wording of the template is probably not optimal; it might be preferable to have "Sum Old-Guy as quoted by Sum Young-Guy". On the other hand, the "quoting" phrasing does allow for context if needed. -- Visviva 01:50, 20 June 2010 (UTC)

Hmm. I greatly prefer "quoted by" (or "as quoted by", as you suggest); but in cases where the context is necessary, and where the quoter's date isn't so far off from the quotee's date, maybe I'll start using "quoting". Thanks! —Ruakh_TALK 02:16, 20 June 2010 (UTC)

Created as a way to more easily coordinate etymology sections. Useful? Not useful? Any suggestions on formatting would be welcome as well. Nadando 07:53, 20 June 2010 (UTC)

Looks allright, but 'proto-German' is certainly a new one to me! —CodeCat 08:40, 20 June 2010 (UTC)

Brilliant idea. Although I see some problems in Index:Proto languages/Semitic with the display of cuneiform characters. --Ivan Štambuk 08:44, 20 June 2010 (UTC)

I would like to see redirects in the appendix namespace be grouped under the same node, together with the destination page, and also wikilinked if they exist, and not separately as they are now. E.g. on Index:Proto_languages/Indo-European we have separately *snígʷʰs, *sneygʷʰ- and *snoygʷʰós, none of which is wikilinked, but all of these ultimately point to the same page (Appendix:Proto-Indo-European *sneygʷʰ-). --Ivan Štambuk 09:16, 20 June 2010 (UTC)

We could use this method to generate appendices which would list all words in a particular language descending from a particular proto-form (and their variants), similar to the way AHD has an appendix of PIE and Semitic lexical roots with their reflexes in English. These appendices would ignore inherited/borrowed distinction, and would appropriately nest (through indentation) various levels of inheritance/borrowing. This would require all the etymologies in the target language to be complete, all the way to the proto-form (regardless whether it's inherited or borrowed), or for the generating program to extract additional levels of inheritance/borrowing from middle etymons if they're present only in their respective etymologies. For example, suppose that the English etymology at December only has up to "from Latin decem (“ten”)". The program would then look at the etymology of Latin decem, and figure out that it descends from the same PIE root as English ten, and would thus generate a node:

• PIE: *déḱm̥t
  • Latin: decem
    • Latin: december
      • Old French: decembre
        • Middle English: decembre
          • English: December
  • Proto-Germanic: *tehun
    • Old English: tīen
      • English: ten

And similar for dozens of other modern English words that ultimately stem from the PIE *déḱm̥t or its variants. These lists could serve as an excellent mnemonic device for memorizing etymologies and word meanings. This would be particularly useful for languages with many layers of borrowings such as English. Some of these are already used in the current PIE appendices, but they get lost in the immense clutter. --Ivan Štambuk 10:00, 20 June 2010 (UTC)

That sounds easier than it really is. The etymology of a word rarely lists every single stage along the way. For example, many English entries list only their Old English ancestors, skipping Middle English. Can an automated system catch this and correct it, rather than assuming that English and Middle English are both direct descendants of Old English? —CodeCat 15:24, 20 June 2010 (UTC)

The program doesn't need to understand parent-child relationship of languages at all, only parse typical natural language constructs in our etymology sections such as "From X aaaa, from Y bbcc, from bb + cc < from Proto-Z dddd, blah-blah variant of Proto-Z eeee." grouping it all under Proto-Z *eeee under appropriate hierarchy. The point is solely in grouping of cognate (and "cognate") words together. But yes, it wouldn't be easy thing to do. Perhaps it should all be done manually. It's just an idea if someone is willing to pursue it. --Ivan Štambuk

It's definitely incomplete, as I'm seeing Latin entries that are missing, such as unus, which comes from *óynos. The latter PIE root is listed, but not all its descendants that use the {{proto}} template. --EncycloPetey 02:47, 21 June 2010 (UTC)

Yes, my first run-through had plenty of mistakes. I've re-generated the data and I'll finish uploading it in the next 24 hours. Nadando 09:35, 22 June 2010 (UTC)

I've noticed over my time here that a lot of etymology sections list Dutch as a descendant of Old Saxon. For example, slæpan does this. So does Appendix:Proto-Indo-European *dwóh₁. And bindan even lists Dutch as a descendant of Middle Low German. I'm wondering what was the thought behind this. Dutch does not descend from any form of Saxon over the course of its history. The later descendants of Old Saxon are Middle Low German, and in modern times Low German (aka Low Saxon). Dutch, meanwhile, descends from Middle Dutch, while that descends from Old Dutch (aka Old Low Franconian).

It is true that Old Saxon and Old Dutch share many similarities, but they were not the same language and there are clear and systematic differences between the two. One example is the change ô > uo, which affected Dutch and High German but not Low Saxon. In some cases these kind of differences lead to confusing results, such as sound changes that seem to reverse themselves: Proto-Germanic gaitiz > Old Saxon gêt / Old Dutch geit > Dutch geit. —CodeCat 15:41, 20 June 2010 (UTC)

Well, in all these etymologies, it is not explicitly stated that Dutch is a descendant of Old Saxon. I think the reason for all this is that there are many similarities between Dutch and Low German, both of old and today (even though there are important differences) and the fact that modern Dutch is much more used than Low German, whereas Old Saxon is much better preserved than Old Franconian, and therefore the editor of some printed source that some Wiktionarians have been using decided to list them together in a small, concise list of cognates, as there are space restrictions in such a printed medium. I think we should definitely be more professional here, since we have plenty of space and all kinds of options not available in printed dictionaries; especially in the Appendices of reconstructed roots and elsewhere, where descendants are listed, we should take care to always classify correctly, by genetic node. – Krun 16:31, 20 June 2010 (UTC)

There is also variation in the older literature as to the names of various Germanic languages. "Old English" and "Anglo-Saxon" don't always mean the same thing in some old dictionaries, even though they're synonymous today. Modern texts consider Dutch to descend from "Old Low Franconian", but there are several other names for that language/dialect, and it is quite possible that some source that was used to create those entries considered OLF a synonym of Old Saxon. Some scholars in the past have made less of a distinction between Middle Low German and Middle Dutch than most modern linguists do, and I can understand the problem. Dutring the Medieval period on Europe, those two languages / dialects were more-or-less mutually intelligible (as was Danish at the time), so that members of the Hanseatic League could trade over a large area without the need for a translator. So, some of the problems you're seeing may come from changes in terminology over time, and some may be the result of changing opinions about the relationship of languages. That doesn't rule out error itself, but I wouldn't jump to blaming error, in the light of the aforementioned points. --EncycloPetey 02:44, 21 June 2010 (UTC)

You have a good point. In this case political arguments often come up as well. German linguists tend to classify various regional languages differently from the Dutch linguists. Case in point being Limburgish which seems to be either Low Franconian or Central German depending on which way the wind is blowing. That said, I think it's good to set up some kind of standard 'tree' for languages and a bit of policy, so that we can refer people who get it wrong to that. Would be useful for the proposal above (previous section) as well. —CodeCat 10:14, 21 June 2010 (UTC)

I've been working on a javascript tool for adding new entries, available in WT:PREFS (click "Enable New Entry Creation Wizard" at the bottom of the "Experiments" section). I'm hoping that this might be linked to from MediaWiki:Searchmenu-new by default at some point; it would probably be more helpful for newbies than the entry templates currently linked to from the search page. Some feedback, bug reports, suggestions, etc. would be great. --Yair rand (talk) 18:42, 20 June 2010 (UTC)

I like the idea of a wizard. It doesn't work with the "Advanced Search" option or with Google Chrome on MS Vista (my default browser). --Bequw → τ 04:09, 21 June 2010 (UTC)

Now works with advanced search. I've tested it on Chrome in XP and Windows 7 and it works, I wonder what could be different about it on Vista... --Yair rand (talk) 04:35, 21 June 2010 (UTC)

Thanks for the fix. The other problem was an odd setup that I've changed. --Bequw → τ 05:17, 21 June 2010 (UTC)

Good work. Now you just need to create one for Chinese entries. ---> Tooironic 23:51, 21 June 2010 (UTC)

Sure. What options should be available, and what should they produce? --Yair rand (talk) 23:57, 21 June 2010 (UTC)

The Russian Wiktionary uses a New Entry Creation Wizard (you will see "создать страницу с таким названием" - create a page with such a name). For new Russian entries it lets you select - gender, animate/inanimate, part of speech/expression, a similar wizard exists for foreign languages. A language code (not a word) needs to be added manually instead of -xx-. I remember there WAS a wizard here, not sure what happened to it. (You can experiment to see how it works but don't create dodgy entries, you can always preview). --Anatoli 00:14, 22 June 2010 (UTC)

I've enabled it in the site js, I hope nobody minds. --Yair rand (talk) 00:59, 22 June 2010 (UTC)

Not bad. Should new entries made with this be pt in an invisible maintenance category for a while (week, month) to detect any problems and improvement opportunities? DCDuring TALK 01:08, 22 June 2010 (UTC)

One thing that springs to mind - could you guess the head= parameter on multi-word terms? Conrad.Irwin 01:15, 22 June 2010 (UTC)

Done. --Yair rand (talk) 01:47, 22 June 2010 (UTC)

Why do I not see this at all? Am I looking in the wrong spots? I've checked http://en.wiktionary.orghttps://dictious.com/en/vfdv and http://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=vfdv&action=edit.​—msh210℠ (talk) 17:24, 23 June 2010 (UTC)

See http://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=Special:Search&search=vfdv&go=Go. --Yair rand (talk) 17:45, 23 June 2010 (UTC)

Thanks. I like the idea. Can it be added to http://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=vfdv&action=edit also? I do not think the "Advanced" boxes should be there, because they don't specify in what way they are advanced. That is, they don't say what sort of format of text should go in them, and no one will know except regular editors. I think drop them altogether (or show them only for whitelisted users and label them Wikicode or something rather than Advanced).​—msh210℠ (talk) 18:26, 23 June 2010 (UTC)

• Regarding Chinese entries, check out User:Tooironic/Chinese entry basic, it lists all the basic things needed to create a properly formatted Mandarin entry. ---> Tooironic 00:19, 23 June 2010 (UTC)

Now that Daniel is gone, can we finally abolish all that stuff like {{topic cat}}, {{poscatboiler}}, {{langfamily}}, etc. and go back to our old practice? -- Prince Kassad 20:53, 20 June 2010 (UTC)

If that's actually a serious suggestion, it's completely ridiculous. --Yair rand (talk) 21:38, 20 June 2010 (UTC)

I found Daniel's approach ridiculous for many purposes in English. Much of the top material was too long. In some cases the wording was inappropriate, in which case I removed the template, copying the useful bits of the wording and inserting what I needed.

I would imagine that something like what Daniel has done, edited down, could be useful as a default. Did he leave documentation, by any chance? DCDuring TALK 22:39, 20 June 2010 (UTC)

What's wrong with current practice? I find these templates very useful and wouldn't want to see them removed. Just documented a bit better. —CodeCat 23:30, 20 June 2010 (UTC)

Why not simply change the template? —Internoob (Disc•Cont) 23:45, 20 June 2010 (UTC)

Agreed. We absolutely want this standardization. Some of it might be a bit wordy, but we can change it, and change it for every category which uses it fairly easily. I don't see why this had to wait until Daniel left. I generally found him pretty open to discussion. -Atelaes λάλει ἐμοί 23:48, 20 June 2010 (UTC)

His user page seems to indicate that he'll only be gone for a few days. Any changes to the system should wait until he gets back. Personally, I don't see any problems with the templates, and I don't think they need any changing. --Yair rand (talk) 00:57, 21 June 2010 (UTC)

I didn't (and don't) like every aspect of his templates, but I totally agree with Atelaes and Yair rand that this is a discussion we can have with him. Pointedly having the discussion while he's gone seems counterproductive at best. I'd ask, Prince Kassad, that you consider removing this discussion. If I went away for a while and came back to find this sort of halfway-behind-my-back discussion about my contributions, I would certainly feel very hurt, and it would likely impair my ability to work constructively on any issues raised. (I assume that you aren't actively trying to drive Daniel. away?) —Ruakh_TALK 01:25, 21 June 2010 (UTC)

Perhaps. But the mode in which the changes were perpetrated the changes was quite sub rosa. Discussions mentioning the question were not taken up. I have come to expect any such dramatic changes to get more discussion. I had assumed that there was some sort of dirigiste cabal to rationalize aspects of how Wiktionary worked. Though I think the heading for this discussion should be changed, the issue could well bear this belated discussion. DCDuring TALK 02:33, 21 June 2010 (UTC)

Specific templates should be discussed individually; I have some beefs (beeves?) with {{poscatboiler}}, for example, that I would gladly share if someone started a section for that. And we could discuss, in that same section, whether it's better to improve the template, or to get rid of it. (Or, perhaps, to leave it be: I suppose I can't take for granted that everyone minds it.) But the general issues mentioned here — his templates overall; his apparently having installed these templates without having consulted the community; and so on — absolutely cannot be discussed without him, not just because it's hurtful and rude, but also because a fruitful discussion requires dialogue. This discussion should be removed, and then we can proceed with better ones. —Ruakh_TALK 02:51, 21 June 2010 (UTC)

I completely agree. --Yair rand (talk) 03:01, 21 June 2010 (UTC)

The templates share common design and deployment features and were apparently part of an overall reform scheme. They could easily be discussed as a group. Now that the subject has been broached it needs to be addressed. I see no reason to close or prematurely archive (let alone delete) this discussion. I look forward to Daniel.'s return so the discussion can be brought to a fruitful conclusion. DCDuring TALK 10:48, 21 June 2010 (UTC)

Some of this is great for keeping noobs from messing with our stuff. Heck, I've been here for around three years, and I truly have no idea how to edit the text at the top of half of Wiktionary's category pages. I usually just add more text below the template, even if it's contradictory, or post a request at the BP. (“Open Content,” tee hee.) —Michael Z. 2010-06-22 04:07 z

Daniel.'s a potentially good editor, but he's more interested in testing himself as a programmer than creating things the Wiktionary needs. {{topic cat}} adds too many categories - look at ], it wants the editor to created two categories as parents for it, then those needs parents, and so on, so you can create twelve categories for one entry. Hence why I either use topic cat and don't create the whole category tree, or I just write the categories out.

{{poscatboiler}} is becoming too big, even with my connection which is pretty quick. It takes 30 seconds to load up ] (as an example) and sometimes I have to restart my browser.

Overall I think I was harsh but fair with Daniel.. I think he was potentially a brilliant editor, but just didn't seem that interested in Wiktionary. Mglovesfun (talk) 13:06, 22 June 2010 (UTC)

I think you're completely incorrect. Where did you get the idea that he's not interested in Wiktionary? --Yair rand (talk) 17:27, 22 June 2010 (UTC)

Yes, I agree. And I actually like the automatic category tree to be honest. The categories it adds are relevant and standardized. —Internoob (Disc•Cont) 20:33, 22 June 2010 (UTC)

Your problem with Category:French nouns does not seem to be affecting anything at my end. That category loads almost instantaneously for me. Your difficulties may be the result of something else. --EncycloPetey 19:10, 22 June 2010 (UTC)

Some of these are from way back, but IMO still deserve a shot. Since votes should not be called for on vote pages, and the discussions in some cases may be long archived, I've decided to put this message here."Translations for lemmas only" seems like a good place to start. Some however will be so outdated that they can't be opened, such as when a policy has already superseded the one they wish to replace. Mglovesfun (talk) 09:52, 21 June 2010 (UTC)

The specific vote you mention probably shouldn't be in that category as it is marked as "withdrawn" on the vote page. The desysop request (due to inactivity) was created by the now-banned user:Rising Sun and so can probably be speedily archived. Thryduulf (talk) 12:21, 21 June 2010 (UTC)

I believe Portuguese Wiktionary uses a green font for the context tags (e.g. UK, slang, vulgar, legal); this seems both functionally and aesthetically effective. More clearly separates the "content" text from this kind of meta-entry stuff in a way that might be more pleasing to users. Does this seem like something we'd be able to do on English Wiktionary (if, of course, a sufficient majority liked it)?--达伟 23:49, 21 June 2010 (UTC)

Usage and grammatical labels are already differentiated by the brackets and italics. Using a third method doesn't add missing functionality, only gaudiness. —Michael Z. 2010-06-22 04:56 z

I too don't see the need for it, but I wouldn't object to a WT:PREFS option to display like that (assuming this is relatively simple to implement). Thryduulf (talk) 08:15, 22 June 2010 (UTC)

It would, I'd hope, make people less likely to try and hard-code the (''brackets''), 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)

Hi everyone, I'm asking you here to discourage some users' attempt to nest all Chinese languages, due to the following reasons:

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.

Thanks. --Symane 15:40, 22 June 2010 (UTC)

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 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.
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 Wiktionary:About Greek.
—Ruakh_TALK 18:57, 22 June 2010 (UTC)

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_TALK 19:09, 22 June 2010 (UTC)

For some relevant past discussion, see Wiktionary:Beer parlour archive/2009/May#A modest request, which included a straw poll showing overwhelming support for nesting. (Does anyone object to my updating Wiktionary:About Chinese accordingly?) —Ruakh_TALK 18:52, 22 June 2010 (UTC)

Ruakh, yes, please update Wiktionary: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 Wiktionary: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 Wiktionary:Beer parlour archive/2009/May#A modest request. 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_TALK 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)

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#Hot Cat, 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 {{rfc-auto}}, 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)

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?" - DaveRoss 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. - DaveRoss 20:04, 23 June 2010 (UTC)

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#CFI. — opiaterein — 18:24, 23 June 2010 (UTC)

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)

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)

{{nonstandard}}. (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 ].)​—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 {{archaism}} 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_TALK 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 (deprecated template usage) East Berliner and (deprecated template usage) abreast (sense 5). Thryduulf (talk) 20:44, 25 June 2010 (UTC)

I think that's a mistake. Those should be {{historical}}. —Ruakh_TALK 22:49, 25 June 2010 (UTC)

Yep. Mglovesfun (talk) 20:29, 1 July 2010 (UTC)

Actually, that (deprecated template usage) abreast def. is correctly noted as {{obsolete}}. Circeus 21:01, 5 July 2010 (UTC)

Yes, that was the point: Thryduulf was contrasting the current-term-for-obsolete-thing East Berliner with the obsolete-term abreast. (When I said "those", I meant "the uses that Thryduulf is describing", not "the uses at ] and ]". Sorry if that was confusing. Deixis works better when you can see what I'm pointing at. :-P   ) —Ruakh_TALK 17:02, 19 July 2010 (UTC)

FWIW I've repeatedly attempted to have {{colloquial}} and {{informal}} 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)

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 diff (which is a temporary link due to its transclusion of templates that will eventually disappear), substing ]), 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_TALK 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 {{rfv-sense}}: 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? - DaveRoss 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 Wiktionary: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_TALK 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)

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#Tabbed language browsing 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)

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)

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)

Some languages, such as Irish, have conjugated prepositions. This means that the prepositions inflect depending on their antecedent. Take a look at ag 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_TALK 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 ag, do, le etc. for some examples. —CodeCat 16:47, 9 June 2010 (UTC)

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.

Wiktionary:About given names and surnames#The language statement of a name 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 Wiktionary: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 {{surname}} 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#Categories for transliterated names, 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)

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 {{only in}} 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)

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

google:"can you direct me to the Louvre" 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 google books:"can you direct me to the Louvre", and I have two for google books:"direct me to the Louvre". 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 google books:"I love you", google books:"what is your name" 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... ], ], ], ], ].​—msh210℠ 16:54, 7 June 2010 (UTC)

]. 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. google:"I've been assaulted and battered" 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: google books:"I've been raped" has 632 hits, and google:"I've been raped" 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 google books:"I've been raped" intitle:phrasebook. See also a particular page in one of these phrasebooks in Google books. --Dan Polansky 21:24, 7 June 2010 (UTC)

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)

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. 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_TALK 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

#toc ul { counter-reset: toc-h2; }
#toc ul ul { counter-reset: toc-h3; }
#toc ul ul ul { counter-reset: toc-h4; }
#toc ul ul ul ul { counter-reset: toc-h5; }
#toc ul ul ul ul ul { counter-reset: toc-h6; }

#toc ul li { counter-increment: toc-h2; }
#toc ul ul li { counter-increment: toc-h3; }
#toc ul ul ul li { counter-increment: toc-h4; }
#toc ul ul ul ul li { counter-increment: toc-h5; }
#toc ul ul ul ul ul li { counter-increment: toc-h6; }

#toc ul li:before { content: counter(toc-h2) ". " }
#toc ul ul li:before { content: counter(toc-h2) "." counter(toc-h3) ". " }
#toc ul ul ul li:before { content: counter(toc-h2) "." counter(toc-h3) "." counter(toc-h4) ". " }
#toc ul ul ul ul li:before { content: counter(toc-h2) "." counter(toc-h3) "." counter(toc-h4) "." counter(toc-h5) ". " }
#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

#toc > ul { counter-reset: toc-h2; }
#toc ul li { counter-increment: toc-h2; }
#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 Wiktionary: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)

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)

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)

It currently uses the following table:

	

	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: {{t-|ar|ماذا|tr=maadhaa}}, {{t+|ar|ما|tr=maa}}
*: ]: {{tø|arz|ايه|tr=eeh|sc=Arab}}
*: ]: {{tø|ary|اشنو|tr='ashnuu}}

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 {{clear your cache}} 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, {{pfl}} and {{sxu}} 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 他 in Mandarin with 佢 in Cantonese for he, 箇 in Gan with 茲 in Minnan for this, or 立 in Wu with 企 in Hakka, 站 in Xiang 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#Translations, 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#Translations for example, húwwain Egyptian Arabic with húwa in Arabic, он in Cyrillic with on in Roman, while under Chinese there are distinct 他, 伊, 佢, 其, 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.

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 — 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.

 {{t-|cmn|漢字|sc=Hani}},  {{t-|cmn|汉字|tr=hànzì|sc=Hani}} 

Only the latter has the Pinyin transliteration. Please consider this as well when programming for script differences. --Anatoli 23:23, 7 June 2010 (UTC)

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

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:

• Argument: The says that it should .
• Response: Your reasoning is .

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)

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

1. Do we want a phrasebook at all?

   I'd say the general consensus is that we want at least some phrasebook entries

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

3. 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

4. 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.

5. 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 <foo>?" of any benefit, but all groups would be likely to use "How do you say <foo> in <language>?".

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:

1. You can't see any translations without clicking, and even then they are poorly layed out.
2. 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)
3. 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)

• 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. Ƿ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. Ƿ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)

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)

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)

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. — opiaterein — 16:49, 8 June 2010 (UTC)

somethin that looks like this, I guess. — 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... — 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... — opiaterein — 13:50, 9 June 2010 (UTC)

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 (deprecated template usage) 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 (deprecated template usage) 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_TALK 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_TALK 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. (deprecated template usage) tracheid). As far as I know the actual semantic flow for, say, "sagittal" is not "along a vertical plane " -> (deprecated template usage) sagittal plane, but "sagittal plane" defined and "sagittal" meaning "along a sagittal plane". Note that (deprecated template usage) 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. {{uncountable}} A particular species of worm, Sabella pavonina. 2. {{countable}} 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 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

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)

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 Usage notes 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 (deprecated template usage) answer 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

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.

— This unsigned comment was added by TheDaveRoss (talk • contribs) at 20:50, 17 June 2010 (UTC). That was a secret :( - DaveRoss 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. - DaveRoss 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_TALK 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 Wiktionary:Votes/pl-2010-01/Number categories and Wiktionary: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_TALK 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_TALK 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. - DaveRoss 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. - DaveRoss 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. - DaveRoss 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_TALK 21:46, 18 June 2010 (UTC) —Ruakh_TALK 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. - DaveRoss 02:35, 19 June 2010 (UTC)

There's another debate about ISO language codes (eg jv) going on at WT:RFD#ISO language codes 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 {{only in|Appendix:ISO 639-1/3/5}}. 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 {{also}} 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. bd2412 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. bd2412 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. bd2412 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 {{also}} and {{slim-wikipedia}} or {{wikipedia}} (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 {{only in}} for the first one and {{also}} 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 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", "", "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#Translingual 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 w: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#h2 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 edit to WT:AMUL 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)

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 forest but the outline makes it appear to be about the Medieval Latin froresta.

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 forestem silvam (“the outside woods”)" 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 very 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, (deprecated template usage) pound would be "Old English, from Latin via Proto-Germanic", (deprecated template usage) dog "Old English ,from Proto-Germanic", (deprecated template usage) cwm "Welsh cwm (“valley”)", (deprecated template usage) hola "Hawaiian hola (“love”)", (deprecated template usage) ciao "Italian", (deprecated template usage) 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 (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 {{etyl}}. --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#Spanish)? --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 (deprecated template usage) tram and (deprecated template usage) 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 {{etymon|foo}} that says is like {{term}} 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 Template:termp. Something similar could be done with the most egregiously long cognate lists, pending a grand solution. DCDuring TALK 03:32, 9 August 2010 (UTC)

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