Wiktionary:Beer parlour

Wiktionary > Discussion rooms > Beer parlour Wiktionary:Beer parlour/header

June 2010

I've been raped

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

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

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

I would suggest Appendix:Phrase book/emergencies, and either redirecting, or using {{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)

[[can you direct me to the Louvre]] would definitely be out of scope, IMO. Same with all of msh210's ideas below, with the possible exception of some variation of "I've been assaulted". --Yair rand (talk) 17:21, 7 June 2010 (UTC)

Out of scope? why? Surely this is a common useful travel phrase (at least for the many tourists in Paris). --EncycloPetey 17:31, 7 June 2010 (UTC)

It would be useful for English-speaking tourists in Paris looking for the Louvre. That's it. Not particularly helpful IMO, and not necessary often enough to be in the phrasebook. The phrasebook, however large it will end up, will need a limited size, otherwise it will be unmanageable. (I'm thinking somewhere in the range of 1000-3000 entries max.) --Yair rand (talk) 17:39, 7 June 2010 (UTC)

Some might say that's hypocritical from the phrasebook's biggest advocate. How is that less useful than I don't speak Old High German? Mglovesfun (talk) 17:42, 7 June 2010 (UTC)

Well, it doesn't look like we are ending up keeping I don't speak Old High German and co, but my first thoughts about those phrases were, if we're having words in dead languages, then the languages should probably be treated equally with other languages throughout Wiktionary. As it is, apparently we're not, at least within the context of the phrasebook. Not really a problem. --Yair rand (talk) 17:49, 7 June 2010 (UTC)

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 [1], 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... [[I've been defrauded]], [[I've been assaulted and battered]], [[I've been harassed]], [[I've been defamed]], [[I've been falsely imprisoned]].​—msh210℠ 16:54, 7 June 2010 (UTC)

[[I need a blowjob]]. Now that I've red linked that, someone will probably create it. Seriously, How feasible is my iea of auto redirects from I need a hammer to Phrasebook:I need a hammer? Mglovesfun (talk) 17:19, 7 June 2010 (UTC)

Phrasebook entries need to be both attestable and common. 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)

Numbers in the table of contents

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

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

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

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

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

Wiktionary:Redirections/Other namespaces

Needs some input from someone better than me. Mglovesfun (talk) 14:22, 7 June 2010 (UTC)

Well, you misspelled vice versa, but I'd have to think about some of the implications and such. The first point could benefit from additional articulations giving explicit reasons why the examples are acceptable / unacceptable. --EncycloPetey 14:35, 7 June 2010 (UTC)

I would change #1 to "Redirects within the template namespace should not be ambiguous or misleading." The reason is that we already use WT:A for WT:Administrators, not WT:Announcements; and WT:ES for WT:Etymology scriptorium, not WT:About Spanish or Help:Edit summary; and we use disambiguation on those pages whcih seems to work fine. —Internoob (Disc•Cont) 22:32, 7 June 2010 (UTC)

Sound good? —Internoob (Disc•Cont) 01:18, 9 June 2010 (UTC)

Accelerated Nested Translations

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

What should be nested?

It currently uses the following table:

	

	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}}
*: [[Egyptian Arabic]]: {{tø|arz|ايه|tr=eeh|sc=Arab}}
*: [[Moroccan Arabic]]: {{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 [2] (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 他[ta] in Mandarin with 佢[koey] in Cantonese for he, 箇[go] in Gan with 茲[jit] in Minnan for this, or 立[lih] in Wu with 企[ki] in Hakka, 站 in Xiang[zan] for stand?

I refuse to contribute any more entry before this change be reverted. --Symane 16:19, 8 June 2010 (UTC)

These typical examples represent 1 to 5% of modern written Chinese and can fit into nested translations quite nicely, see the he#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 他[ta], 伊[i], 佢[koey], 其[ki], etc. in different languages and the example I listed above are all defined as basic words in Swadesh list. And you may know that Mutual Lexical Intelligibility among Chinese languages varies from 19.8% to 46.1%, in comparison, German and English are 60% lexically similar. So this is your so-called "1 to 5%"?

And I hope that you are the only one here that contemns minority languages or less-contributed users, since this behaviour goes rudely against values that Wiki holds.--Symane 11:16, 9 June 2010 (UTC)

First of all, you should keep in mind that we do treat the Chineses as different languages. We recognize that Chinese is not a language, but rather a language family, with a great deal of differences between the languages in that family. However, the trick is that most of our users are not going to look up Mandarin or Cantonese, rather they'll look up "Chinese". Nesting the languages together is a pragmatic approach, based on what we expect users to look things up by, and should not be interpreted as meaning "these are all the same language". That being said, your abrasive tone does not help the matter. -Atelaes λάλει ἐμοί 11:50, 9 June 2010 (UTC)

It is possible, if you want to, to stop it from nesting by deleting Chinese from the "Nesting:" box under More. As this seems to be against Wiktionary formatting conventions, it's probably a bad idea - but there's no technical enforcement, just encouragement. Conrad.Irwin 12:04, 9 June 2010 (UTC)

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

How to support orthography?

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

Dangerous? O_o — [ R·I·C ] opiaterein — 22:34, 7 June 2010 (UTC)

I am not sure why Serbo-Croatian needs to be nested but this has been the practice. Would a flag (Cyrillic/Roman) suffice? Same for Bokmål/Nynorsk, Mongolian (Cyrillic/Mongolian). Just my opinion. There must be a way to differentiate the scripts, though. We are not using much to point users what is Traditional Chinese and Simplified Chinese. The translations simply follow each other - trad. followed by simpl.

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

cmn/zh

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

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

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

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

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

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

Analysis of phrasebook discussions

Currently, there are various simultaneous conversations about a phrasebook entry, a particular set of phrasebook entries or the phrasebook as a whole. Here is how they apparently have been mostly discussed:

• Argument: The [other phrasebooks; Google; Google Books; lack of policy; sheer nature of a dictionary] says that it should [be kept; be deleted; be kept in appendices].
• Response: Your reasoning is [right, let's do exactly what you said; totally wrong, shut up and go back to doing actual work].

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)

Suggestion for sorting

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

somethin that looks like this, I guess. — [ R·I·C ] opiaterein — 21:05, 8 June 2010 (UTC)

Something that looks like...? Then, done. See I don't speak French and I've been robbed. Although, I think it will eventually be messed up when placed in pages where a table of contents exist. --Daniel. 05:50, 9 June 2010 (UTC)

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

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

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

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

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

The banner is the only thing that visually separates phrasebook entries from standard entries... — [ R·I·C ] opiaterein — 13:50, 9 June 2010 (UTC)

Recursive meaning

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

Take (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. Template:uncountable A particular species of worm, Template:spelink. 2. Template: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 [the nationality] has no singular). The Oxford Companion to the English Language (1992:813), says that “Nationality nouns (Americans, a New Zealander, the Japanese) lie on the borderline between proper and common nouns.”

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

Bird name capitalisation

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

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

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

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

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

Also, we are not a regulatory body. Our goal and purpose is not to be an advisory authority on the "correct" way things should be done, nor to give a "stamp of approval" or weed out "untenable discrepancy". Our purpose (as with any good dictionary) is to describe usage that actually exists in the language, and not to tell people which forms they ought to be using. English is different from many other European languages in that respect; it has no governing regulatory agency making lists of acceptable words or telling people how they should use the language. --EncycloPetey 15:07, 9 June 2010 (UTC)

But see The Queen's English Society who want to do/be just that. SemperBlotto 15:12, 9 June 2010 (UTC)

That's not the impression I have from reading their site. It's also highly unlikely they will have significant impact on the use of English in the United States at any point in the forseeable future. --EncycloPetey 15:19, 9 June 2010 (UTC)

The finer distinction between reply and response

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

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

I, differently, expect to find such explanations in the 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

Wiktionary:Votes/pl-2010-06/WMF jargon accepted when it meets CFI

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

What about rollback?

Hi. I got rollback some time ago, after asking on IRC, but it was removed today, I'm not sure what does determines this, but I think I could be very useful using rollback, and I have quickly removed vandalism. So, please let me know what are your policies on this :) --Diego Grez 00:50, 11 June 2010 (UTC)

If you're going to be using rollback, the chances are you'll need delete too; though you've perhaps not been round long enough to be made an admin yet. I'd be happy to grant you rollback, and, I think any whitelisted user who asks for it (WT:BP seems the best venue until there's a lot of traffic) - seeing as there are already global rollbackers over whom we have no control it's not as though we need any stringent requirements. Conrad.Irwin 00:56, 11 June 2010 (UTC)

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

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

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

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

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

Flood flag

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

Phrasebook: Common occurrences

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

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

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

If we want a phrasebook, and a considerably random list like this [3] says that "Offensive words in public place" and "Trespass on occupied property" are among the most common crimes somewhere, do we want to define I've been offended by words and my property's been trespassed? If not, why not? --Daniel. 03:03, 15 June 2010 (UTC)

I think part of the answer to this will come from the answer to one of the questions I proposed earlier, which has so far not had any response. The question is "Who is the target audience?" If the target audience is tourists or business travellers, then "my property has been trespassed" is not something that will be useful for almost all tourists. If the target audience is invading foreign military soldiers, then it wont be at all useful. If the target audience are language learners, then I can see an argument being made for its usefulness (e.g. for ex-pats). Until we know who we are aiming at then I don't think we can start working out exactly what our criteria are, let alone what objective measures we use to back them up. Thryduulf (talk) 08:07, 15 June 2010 (UTC)

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

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

I think the target audience should be: Everyone, everywhere. — [ R·I·C ] opiaterein — 15:32, 15 June 2010 (UTC)

Things like Sorry for the mess, I couldn't control the guinea pigs are quite conceivably useful to someone somewhere, but they are clearly not useful to enough people to include. Everyone, everywhere is a naive approach that will not work. Conrad.Irwin 15:35, 15 June 2010 (UTC)

I can see merit in this highly subjective suggestion of a phrasebook for "everyone, everywhere". However, would it have limits? Or do you want to introduce a set of infinite sentences? --Daniel. 15:45, 15 June 2010 (UTC)

I say include every meaningful conversational phrase that has >50k hits on top 5 search engines for the respective language. --Ivan Štambuk 15:55, 15 June 2010 (UTC)

"he's not dead", for example? --Daniel. 16:02, 15 June 2010 (UTC)

We do have he's unconscious. — [ R·I·C ] opiaterein — 16:23, 15 June 2010 (UTC)

Yes. All of the "emergency speech" should be inside phrasebook by default. --Ivan Štambuk 16:42, 15 June 2010 (UTC)

It's pretty easy to introduce a requirement for simplicity without making up some ridiculous examples of what we might have otherwise...lol. — [ R·I·C ] opiaterein — 16:23, 15 June 2010 (UTC)

Correct. The requirement of "simplicity" is already stated at PB, therefore "sorry for the mess, I couldn't control the guinea pigs" is not desirable due to its complexity; on the other hand, "I'm sorry" is simple enough to be defined here. --Daniel. 16:40, 15 June 2010 (UTC)

Is this quantifiable? I'm sorry for the mess doesn't seem any more complicated than I need a sanitary napkin to me. Conrad.Irwin 16:41, 15 June 2010 (UTC)

In my opinion, I'm sorry for the mess is more complex (and not more complicated) than I need a sanitary napkin, because the former has a preposition. --Daniel. 16:51, 15 June 2010 (UTC)

How could the Phrasebook look like - a proposal

First, a few notions:

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

One possible approach could be this:

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

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

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

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

Weren't we already developing such a list? lol — [ R·I·C ] opiaterein — 12:33, 16 June 2010 (UTC)

Topical categorization seems reasonable. Phrases that pertain to the same topic should appear on the same page. However, I'd like to see it implemented in a way that enables a user to choose a destination language from a drop-down list, and only translations in the chosen language are displayed inline. That way we get both the centralized management and the multilingual clutter reduction.

And please let us dispense with the sexist term mother list. --Ivan Štambuk 13:40, 16 June 2010 (UTC)

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

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

Archiving.

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

I've been wondering the same thing myself, and I agree with your suggestion. In the worst case, we might be archiving a discussion started on 31 May a day later... —CodeCat 09:38, 16 June 2010 (UTC)

What'd be nice is if we had a bot which could tell when the last comment was posted on a discussion, and archived it perhaps a month later. Occasionally, conversations can go on for quite some time. Also, I don't really like monkeying with the "archive" button on every thread. Props to Conrad for some sweet coding, but I think a bot is a better approach to this task. -Atelaes λάλει ἐμοί 12:28, 16 June 2010 (UTC)

w:User:ClueBot III operated by w:user:Cobi does exactly this for the English Wikipedia. Rather than reinventing the wheel it would probably make sense to use it (or a copy of it run by a local bot operator) here as well. Thryduulf (talk) 16:22, 16 June 2010 (UTC)

Nice find, Thryduulf! Just what we need. —CodeCat 19:45, 16 June 2010 (UTC) Repositioned and reindented to be under Thryduulf.​—msh210℠ 19:53, 16 June 2010 (UTC)

Yep. With source, too! Can we use (some modification of) this? Please?​—msh210℠ 19:53, 16 June 2010 (UTC)

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

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

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

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

Whatever method we use for archiving (and I generally support the bot option), when it comes to archiving the tearoom we need to remove the tag on the entry under discussion. At present these hang around long after the discussion either reaches a conclusion or fizzles out (if it even started, unlike a couple of discussions I've initiated recently) - for example (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)

Look of references

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

Targeted Translations

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)

Categories for transliterated names

(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:

• (deprecated template usage) Պետրոսյան (Petrosyan) can be under ==Armenian==, use the code {{surname|lang=hy}}, be categorized under Category:hy:Armenian surnames
• (deprecated template usage) Petrosyan (English transliteration) can be under ==English==, use the code {{surname|lang=en|transl=hy}}, be categorized under Category:Armenian surnames
• (deprecated template usage) Петросян (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 (deprecated template usage) Петросян (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:

• (deprecated template usage) Պետրոսյան (Petrosyan) can be under ==Armenian==, use the code {{surname|lang=hy}}, be categorized under Category:Armenian surnames (the existing system)
• (deprecated template usage) Petrosyan (English transliteration) can be under ==English==, use the code {{surname|lang=en|transl=hy}}, be categorized under Category:en:Armenian surnames
• (deprecated template usage) Петросян (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. (deprecated template usage) 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)

sino-, franco-, and so on

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)

Vote Closure Rubric

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

Type	Min. Support Votes	Pass (>=)	Min. Duration	Max. Duration	Notes
User Rights (simple)	10	2/3	7	28	Sysop, Bot, 'Crat
User Rights (meta)	25	4/5	7	28	CheckUser, etc. (any right which has Foundation mandated criteria)
User Rights (removal)	10	>1/2	28	28	-
Modification/Extension	10	2/3	7	28	Anything which requires a bug be submitted or major changes to appearance/functionality via global js or CSS.
Policy	10	2/3	7	28	Formatting, Inclusion, etc.
Straw Poll	1	N/A	N/A	28	Any vote which is to gauge opinion on an issue rather than affect a change.

— This unsigned comment was added by TheDaveRoss (talk • contribs) at 20:50, 17 June 2010 (UTC). That was a secret :( - [The]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. - [The]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. - [The]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. - [The]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. - [The]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. - [The]DaveRoss 02:35, 19 June 2010 (UTC)

Hideable stuff revamp

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 (deprecated template usage) հարկանեմ (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 (deprecated template usage) 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 (deprecated template usage) tener (Spanish) with the quotations on (deprecated template usage) 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)
[follow-up] 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. - [The]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. - [The]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)

Hideable stuff - user examples

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)

Hideables: Appearance and vector.css

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 [quotations▼] control's text is a noun, while our our translations sections' [show ▼] 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 [edit] which does something else, or [edit gloss] 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)

Hidden content and previews

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)

"quoted by"

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 [[Zionazi]] and [[shitter#Adjective]] 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:

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)

Index:Proto languages

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 (deprecated template usage) December only has up to "from Latin (deprecated template usage) decem". 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 (deprecated template usage) 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)

Dutch as a descendant of Old Saxon?

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)

New Entry Creation Wizard

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.org/wiki/vfdv and http://en.wiktionary.org/w/index.php?title=vfdv&action=edit.​—msh210℠ (talk) 17:24, 23 June 2010 (UTC)

See http://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.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)

Daniel.

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 [[Category:fro:Colors]], 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 [[Category:French nouns]] (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)

Category:Votes that have not been opened

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)

Green color for context phrase

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)

Chinese languages nesting

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

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)

Instant-click feedback

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

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

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

Phrasebook CFI

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

ISO language codes (again)

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 [jv] specifically because it would be easy to search for. These are the not the problems. The problem is that no one appears to use these terms in natural language. --Bequw → τ 21:39, 29 June 2010 (UTC)

The issues is not about symbols overall, it's about unattested terms that people think merit *special* inclusion (we had the same debate about unattested metric units). And no, the CFI doesn't explicitly allow symbols as that words isn't even on the page. The use-mention distinction works just fine for symbols (most mathematical symbols could be easily attested). CFI is therefore still the policy that governs these terms. If you want to change it, get a vote passed. As above, consensus is not needed for RFV (where thankfully logic still prevails). ----Bequw → τ 21:37, 29 June 2010 (UTC)

I genuinely do think you're missing the point. Nobody actually tried to cite it. I could RFV headlight and if nobody cited it in 30 days I could delete it. In all seriousness, I think I could RFV quite a few things that exist and get them deleted, despite knowing that they exist. Mglovesfun (talk) 21:43, 29 June 2010 (UTC)

I tried to cite them and couldn't. These were not submitted nefariously. Lack of willingness to cite is accounted for by the RFV process. They are deleted upon failure after 30 days and re-entered once they're cited. --Bequw → τ 21:49, 29 June 2010 (UTC)

"Lack of willingness to cite is accounted for by the RFV process". Hmm. That's ambiguous. If you mean "the problem with RFV is nobody bothers to cite things" I agree. FWIW I didn't know you'd tried to cite them, I think that's honorable. IMO if you try and cite an RFV, always say so, so that the person who ends up deleting the entry knows that somebody has tried. Mglovesfun (talk) 22:18, 29 June 2010 (UTC)

Look up. "http://en.wiktionary.org/wiki/Wiktionary:Beer_parlour". Are you denying that they exist? Are you denying that they have been used in durably archived works? Are you denying that they are "terms"? Certainly it wouldn't be too difficult to find these used, but what is "usage" is completely unclear. Personally, I would not consider "I speak jv" to be usage, because it is clearly using it as though it is an English term, and because it does not have the same meaning as the one we give. I would consider things like "jv: Javanese", "Section jv", "from http://jv.wiktionary.org", "jv=Javanese", "Javanese: jv/jw | jav/jaw", "[jv]", "ISO code for Javanese: jv", "Java (jv: Jawa)", "Select language: en, fr, jv", etc. all to be perfectly good cites. Am I missing something here? How would you cite .com, #, Q, :-(, ☽, ^N, ␁, { etc.? --Yair rand (talk) 22:26, 29 June 2010 (UTC)

(unindent) Well I do doubt en#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)

Three categories for the same thing?

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

• Category:Cardinal numbers
• Category:Numbers
• Category:Numerals

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

71.66.97.228 02:36, 25 June 2010 (UTC)

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

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

There are two problems with "fixing" this issue.

First, Category:Numbers currently includes symbolic forms of numerical script elements, like 1, 2, 3, while Category:Numerals is currently the main part of speech listing, under which words that function as cardinals, ordinals, fractionals, adverbials, distributives, etc. are placed So, these two categories cover different sort of things.

Second, Category:Cardinal numbers (versus Category:Cardinal numerals is part of a debate that has gone on for years. There are people who favor each name, and every discussion or proposal to stanadradize to one or the other has resulted in highly vitriolic debate. No solution seems likely at any point in the near future. --EncycloPetey 04:33, 6 July 2010 (UTC)

I don't follow the first of those two problems. I don't see the difference between '1' and 'one'. Both are numerals, i.e. representations of numbers. I mean, one is translingual and the other is English, but aside from that I don't see the difference. (That said, I have no opinion/solution for what the category for them should be called, nor whether it should be prefaced with Langname or langcode.)​—msh210℠ (talk) 04:45, 6 July 2010 (UTC) (Sorry, we had a vote on Langname vs. langcode. I forgot.​—msh210℠ (talk) 04:49, 6 July 2010 (UTC))

The first is the issue of numerical systems. What we call "Arabic numerals" are the individual symbolic components. They are distinct from words in the same way that "&" / "and" are distinct. We categorize the former as a symbol and the latter as a conjunction. Likewise, the letters "h" and "a" are distinct from any words constructed using those letters. We need a separate category for the components as opposed to the larger units constructed from those components. This does not imply exclusivity, so "1" could potentially be listed as a number (symbolic) and a numeral (word), just as "a" is both a letter (component) and a word. --EncycloPetey 05:11, 6 July 2010 (UTC)

Good point. We do have subcats of Symbols, so I suppose this is another valid one. Incidentally, we have both Symbols and Translingual symbols. (Sigh.)​—msh210℠ (talk) 05:18, 6 July 2010 (UTC)

Labels (informal, colloquial and ...)

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

P.S. And explain, please, the difference between labels informal and colloquial. Both of these words are translated into Russian as разговорный. -- Andrew Krizhanovsky 04:35, 25 June 2010 (UTC)

{{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 [[Appendix:Glossary]].)​—msh210℠ (talk) 17:31, 25 June 2010 (UTC)

Archaic and obsolete overlap a lot as well. For me, something that was last used in 1970 cannot be archaic because it's not been out of use long enough. So if I use archaic, it's been out of use for longer than something I tag with obsolete. Mglovesfun (talk) 19:48, 25 June 2010 (UTC)

I don't think archaic means out of use at all: it means in use, but archaic-sounding. Like thee: people use it even now, but it sounds archaic. Obsolete means out of use. Maybe my understanding doesn't match everyone else's, though.​—msh210℠ (talk) 19:50, 25 June 2010 (UTC)

That seems to be the prevailing usage of "archaic" here, but it makes little sense to me; surely it would only apply to the very small number of terms, like thy and ye, that can be documented in pseudo-archaic speech or writing. Given the multiple meanings of "archaic", I would prefer a separate {{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 (deprecated template usage) East Berliner with the obsolete-term (deprecated template usage) abreast. (When I said "those", I meant "the uses that Thryduulf is describing", not "the uses at [[East Berliner]] and [[abreast]]". Sorry if that was confusing. Deixis works better when you can see what I'm pointing at. :-P   ) —Ruakh_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)

time-sensitive "+" links in the RFV/RFD/... templates

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

Maybe the "(+)" should only be visible on edit-preview? That way it's easily accessible to editors — especially the editor who's adding the template — but not so obtrusive to readers. (Note: I believe this would require JS.) —Ruakh_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? - [The]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)

Re-thinking etymology format

Ivan Štambuk expressed a desire above to be able to generate a node-like structure from the raw text of an etymology section. This is going about the problem backwards- we should start with an easily parseable format, which can then be modified to whatever other format is wanted. In addition, many pages have dense paragraphs of text that, although they have a lot of information, probably intimidate casual users. My proposal is at User:Nadando/etymology. Notice that although it would be nearly impossible for an algorithm to go from etymology 1 to etymology 2 (for every page in Wiktionary), it is very easy to go from 2 to 1, or something resembling 1. Anything underlined is a gloss, which is clearly distinguishable from the root words. This would also let us add even more information to etymologies without being completely overwhelming, such as lists of cognates. One thing that concerns me about structured etymology sections, however, is the loss of flexibility- does anyone have an example where this format would absolutely not work? Nadando 06:33, 26 June 2010 (UTC)

Generally I like the second format, however I don't think you have the indentation quite sorted. Most of the first block of discussion (first used...) reads as though it is about the Middle English word (deprecated template usage) forest but the outline makes it appear to be about the Medieval Latin (deprecated template usage) 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 (deprecated template usage) [etyl] Late Latin phrase (deprecated template usage) forestem silvam" looks excessive, the "from" (bold) "Late Latin" (linked), "forestam silvam" (linked, italicised), and "the outside woods" (in brackets) are all sufficiently clearly set-off already that "the" and "phrase" being highlighted feels completely unnecessary and detracts from reading the whole sentence as a single piece of information. As it's such a simply structured sentence and they're such basic words, they're also not confusable with any other bit of information the setence contains.

Conversely in "Akin to English door. More at foreign.", you need to set off "door" and "foreign", ideally including linking to them (it also doesn't explain why "foreign", although that's nothing to do with the layout). Ditto the cognates and "more at" words in the sentence starting "Cognate to Old High German forst (“‘forest, wooded country, pine wood’”)".

Overall a good start, and an overdue improvement, but it needs refinement. Thryduulf (talk) 09:23, 26 June 2010 (UTC)

This is a good thought process, but I agree with Thryduulf that it needs refinement. The trick to making a robust etymology format is to have highly structured data. We can do a lot more when information like what the first etymon is, what language it's from, what the cognates from that particular etymon are, etc. are actually coded into the data. I've been thinking about a couple approaches to etymologies. First, I think we should avoid going too far back. In this case I don't know if we really want to go back past the Old French, certainly not past Latin. Quite frankly, I wonder if the best approach is to only go back to the most recent etymon we have an entry for. Going back further creates redundancies and maintenance problems. What would be nice is if we had some JS which could take the most recent etymon, and elaborate by looking up the most recent etymon's most recent etymon, and so on. This is not beyond our technical capacity, though it's not necessarily easy. Additionally, I think that the default etymology we present to users should be simple, just a list of etyma, with perhaps a few highly relevant notes; no dates, no cognates, nothing more. We have an expand button which shows etymology nerds all the extra info we have available. With all the languages, which span all the times which we have here, some good tools could make our etymological capacity outstrip other sources by orders of magnitude. With the data that we already have, if we had the right software, we could map the progress of the majority of the English language, showing the major inputs, time periods, all kinds of things. We just have to iron out some technical issues. Truth be told, a lot of our shortcomings come from poorly structured data, though we are rightly hesitant to increase the complexity of the Wikicode, as we already have so many complaints about its current complexity. -Atelaes λάλει ἐμοί 12:15, 26 June 2010 (UTC)

I agree with the thoughts about providing too much information. Some of our entries really go overboard, particularly with lists of cognates and I've been idly wondering about a hideable (and by default hidden) "cognates" section, organised by etymon.

Regarding how far back we go, I think we might benefit from defining certain "classes" that we present, e.g. "Greek", "Greek via Latin", "Latin", "Old English", "Celtic","Germanic" "Old English", "French", "Unknown", "Unknown with possibilities", "compounds in modern, Middle or Old English", "Suffixes in modern, Middle or Old English", "Anglo-Norman", "other modern Language", "Modern English coinings", "Old Norse". For each class we would have a defined limit as to what levels we show by default. For example, the "Latin" class would not show anything earlier than the Latin by default, the "other modern language" would show only as far back as that language, e.g. "Polish" or "Japanese".

Indeed I think there would be benefit in providing a [i]very[/i] basic level , "bite-size" etymology, containing no more than three elements, (with an element being either a language name or an etymon) and a small list of linking words ("from", "via", "unknown", "probably", "possibly", "and", "or", "replaced"). So for example, (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 (deprecated template usage) cwm", (deprecated template usage) hola "Hawaiian (deprecated template usage) hola", (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 [foo] (from Latin foobar)". Locking all the etymology information in the English entries deprives other descendants of an English etymon of useful knowledge. --Bequw → τ 16:30, 26 June 2010 (UTC)

I agree with Bequw.​—msh210℠ (talk) 17:24, 28 June 2010 (UTC)

One issue with off-loading older etymological information to separate terms is that it would remove the original term from older-language derivational categories. I don't think this is too bad as I don't see much sense in English terms being in Category:Proto-Indo-European derivations (as most would be). If, however, others find this useful, we could come up with an invisible mode for {{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)

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)

Screwing around with user interface

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

These changes {tabs for Language sections, disabling navigation by the ToC are clearly not ready for prime time and should require a vote or at least conspicuous notice. DCDuring TALK 16:52, 27 June 2010 (UTC)

user:Atelaes. See WT:GP#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)

Category:Pastry

There is a lonely singleton in Category:Pastry. A new Category:Cakes and pastries might fill a gap in the Category:Foods and provide a more popular successor for Pastry. Looking at other languages shows minimal usage of this category anywhere. —Saltmarsh^{απάντηση} 09:18, 28 June 2010 (UTC)

Sounds sensible to me. Thryduulf (talk) 12:47, 28 June 2010 (UTC)

Yeah move. BTW WT:RFM is moving veeeery slowly. Mglovesfun (talk) 17:35, 28 June 2010 (UTC)

I agree. Pastry is over-specific. Equinox ◑ 17:36, 28 June 2010 (UTC)

This doesn't seem contentious and the number of affected articles is small - I'll go ahead. —Saltmarsh^{απάντηση} 04:10, 4 July 2010 (UTC)

Userbox discussion

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

July 2010

Unifying 'alternative forms/spellings' headers

A recent ELE discussion sparked my curiosity about the usage of both "Alternative forms" and "Alternative spellings". I made a list of pages using both, one right above the other. It seems to me that the dual headings should be unified, probably under the more general "forms" header. If so, should we provide any sort of qualifier to distinguish the two. More broadly, should we just use the more general header always? This would ease the constant confusion among editors about which one to use. --Bequw → τ 21:44, 1 July 2010 (UTC)

My preference would be the standardisation of everything to a single "Alternative forms" header, with "Alternative spellings" being deprecated and automatically changed (probably on an ongoing basis) to "Alternative forms" by some automation or other. I think we'd just need a few notes in places that people are likely to look (ELE, anywhere else?) that "Alternative forms" includes forms that are alternative spellings. I've never understood why we have both. Thryduulf (talk) 22:37, 1 July 2010 (UTC)

Re: "I've never understood why we have both": Originally we only had "Alternative spellings"; later, some editors started using "Alternative forms" for cases where "Alternative spellings" didn't work. (And there were some objections to that. As I recall, some editors felt that "forms" implied "inflected forms".) Before now, I don't remember ever seeing anyone suggest the wholesale elimination of "Alternative spellings". Maybe it's just never occurred to anyone? But personally, I never use both on the same page, preferring "Alternative forms" whenever "Alternative spellings" doesn't cover all listed items, and I'd be fine with your suggestion of never using "Alternative spellings" at all. —Ruakh_TALK 23:23, 1 July 2010 (UTC)

There was an earlier discussion on the topic about a month or two ago, but I can't remember where it was. Someone proposed using alt spelling only for pairs with identical meanings and pronunciations, and alt forms for everything else. However, I'd be ok with simply using either for all entries. Whatever the outcome, standardization is a higher priority for me. -Atelaes λάλει ἐμοί 23:25, 1 July 2010 (UTC)

FWIW I, too, am fine with Thryduulf's suggestion of sticking to "forms".​—msh210℠ (talk) 07:12, 2 July 2010 (UTC)

I think it is important that we have wording that is satisfactory for all languages. Either would work for English. But if "forms" introduces some ambiguity among users who are not native English speakers or for English speakers learning inflected languages, it might not be satisfactory. This might be a good use for a straw poll. BTW, the previous discussion included "synonyms" in the header, which may indicate the full extent of ambiguity. DCDuring TALK 10:11, 2 July 2010 (UTC)

Strong support for unifying and redirecting {{alternative spelling of}} to {{alternative form of}} --Vahagn Petrosyan 10:12, 2 July 2010 (UTC)

I've started WT:Votes/pl-2010-07/Alternative forms header as this would have to change a line in WT:ELE. --Bequw → τ 05:15, 3 July 2010 (UTC)

• I have some concerns. It might be ambiguous, as it has been pointed out. For any entry with alternative forms, how will we know whether the listed entries are just two spellings of the same word or slightly different words (ie. they represent different pronunciation)? Should we list the latter as synonyms? —Internoob (Disc•Cont) 18:55, 3 July 2010 (UTC)
  • To some extent alternative spellings, alternative forms and synonyms overlap. I'd be inclined to keep all three, but manage them well. Mglovesfun (talk) 22:24, 3 July 2010 (UTC)
  • And homophones. Does that make a difference between "alt spelling" and "alt form"? Ie, is an alt spelling an alt form that is also a homophone? In contrast, words like (deprecated template usage) buoyance and (deprecated template usage) buoyancy might be alt forms. DCDuring TALK 22:51, 3 July 2010 (UTC)
    • That's the way I understand it, yes. —Internoob (Disc•Cont) 03:04, 4 July 2010 (UTC)

It's not ambiguous in that we are blurry previously distinct concepts. We don't have (and I haven't seen elsewhere) a clear policy for what is an alternative form and which is an alternative spelling (some say similar/equivalent pronunciation, some bring in etymology too). Readers would probably care more that we provide the necessary tools for them to assess the relationships between terms themselves rather than for us to invent an additional phrase of jargon. That's why we should unify the headers.

It would also be good for Wiktionary to eventually have an idea of what should go in this section. I don't care too much about the specifics. It could be a heuristic like "similar etymology, pronunciation, and meaning" (with variants for foreign languages). But I think that is a slightly separate issue. --Bequw → τ 03:13, 4 July 2010 (UTC)

Wouldn't it be better just to have alternate forms/spellings work something along the lines of {{also}} right under the language headers? I don't really see the need for either alternative forms or alternative spellings to have headers (though I do think that unified alt form headers is still better than what we currently have). --Yair rand (talk) 03:19, 4 July 2010 (UTC)

One reason for including an "Alternative whatever" heading is that it allows us to include additional info about the relationship between the entry and the alt, such as dialect or register in which each is found. Also, I generally see the {{also}} stuff as information which is not actually related to the entry. There is no real relationship between act and ACT besides the coincidental similarity of their spelling. We include the {{also}} stuff as a convenience to the reader, yet it is not information about any particular word, and consequently is not placed inside any language header. Conversely, there is a very real relationship between the English words color and colour, and this is why that info is placed inside the English section. -Atelaes λάλει ἐμοί 03:41, 4 July 2010 (UTC)

I think it could work if additional text is allowed next to the word (Alternative forms: color (US)). --Yair rand (talk) 05:04, 4 July 2010 (UTC)

But it couldn't make language level distinctions. If "foo" is a word in English, with the alt "bar" and also a French word with the alt "baz", then we'd have a problem encoding this. -Atelaes λάλει ἐμοί 05:31, 4 July 2010 (UTC)

That would only be a problem if we put it at the top of the page, as opposed to right below the language headers, as I had suggested. --Yair rand (talk) 05:36, 4 July 2010 (UTC)

Oh, I missed that bit. Sorry. I guess I've run out of smarmy counter-arguments then. -Atelaes λάλει ἐμοί 05:47, 4 July 2010 (UTC)

I prefer that data about the entry always be included under some header idnetifying the nature of the information. We do have relative frequency data, wikipedia links, and images already placed directly under the language header. I fear allowing more information there os other types will create an impossible-to-edit jumble. If the alternative forms are under a specific header, then a bot can at least recognize what that information is supposed to mean. Without a header, it's random content. Further, alternative forms are sometimes listed at L4, when the forms apply only to one POS or one etymology, etc. So, removing the header when the information appears at a different location again introduces inconsistency to the data structure that both editors and bots will have troublw with. --EncycloPetey 04:23, 6 July 2010 (UTC)

FWIW I only ever use alternative forms. Mglovesfun (talk) 08:54, 5 July 2010 (UTC)

"Alternative forms" would be confusing for given names and surnames. Some editors may think that, for example, Cathy, Catriona and Kathleen are alternative forms of Catherine. Right now they are listed in "Related terms" and "Alternative spellings" only includes forms pronounced like Catherine, such as Katherine and Kathryn. "Alternative forms" would also make their pronunciation uncertain.--Makaokalani 14:04, 7 July 2010 (UTC)

We could spell extra policy out at WT:Alternative forms (maybe merging with some info from WT:Alternative spellings?). Or all the forms you mention could be listed in the section with an "alternative spellings" qualifier in front of the ones that are pronounced the same. I think this is similar to other Latin script issues. Given names in other scripts (eg Asian ones), I'd imagine would be more happy with "Alternative forms". --Bequw → τ 15:51, 7 July 2010 (UTC)

Can I get rollback?

I have it at both en-wikipedia (where I also have reviewer) and simple-wikipedia Purplebackpack89 ^{(Notes Taken) (Locker)} 16:22, 3 July 2010 (UTC)

Give it a while. Our formatting is finicky. Don't take getting rolled back personally. Also, see red hot and red-hot#Noun. DCDuring TALK 17:10, 3 July 2010 (UTC)

"Printable version"

Every page links to a "printable version" of the page in the toolbox section of the sidebar. Is this really necessary? Can it be removed? --Yair rand (talk) 06:21, 4 July 2010 (UTC)

Quite frankly, most of the stuff in the toolbox is utterly worthless and irrelevant. Clicking "related changes" gives me a bunch of discussion room edits, and we don't upload files to this project, and all the "special pages" are distinctly unspecial. Could we do some general trimming here? -Atelaes λάλει ἐμοί 07:23, 4 July 2010 (UTC)

"Related changes" can be useful from categories, and "Upload file" links to the Commons upload page, which can be useful. "Special pages", on the other hand, is totally useless, IMO. --Yair rand (talk) 05:04, 5 July 2010 (UTC)

We do have some uploads, for illustrative purposes. —CodeCat 08:20, 4 July 2010 (UTC)

I find "printable version" quite useful for, well, printing. I had assumed it was generated on the fly, rather than periodically. I use it when I would like to make extensive revisions of an entry or provide some benighted non-user of the web some information from en.wikt. I find it alarming that some users here don't grasp such potential use. DCDuring TALK 12:15, 4 July 2010 (UTC)

I think the print link should be somewhere at least. You can hide it. --Bequw → τ 15:26, 4 July 2010 (UTC)

Word moves

I noticed that we have role-playing game, but not roleplaying game (or role playing game). I went to Wiktionary:Requests for moves, mergers and splits to propose a move, but it says "Out of scope merging entries which are alternative forms, spelling or synonyms such as color/colour or traveled/travelled. Unlike Wikipedia, we don't redirect in these sort of situations." That's wonderful; it might be a little useful if it told me what we do do in these types of situations. Should I do a cut and paste from role-playing game to roleplaying game? Surely there's a saner solution...--Prosfilaes 14:53, 10 July 2010 (UTC)

Whoops, we do have role playing game. Though it's just wrong, in claiming that it's a misspelling; in my pile of roleplaying games I assembled here, I think there's more that describe themselves as role playing games than role-playing games.--Prosfilaes 14:56, 10 July 2010 (UTC)

In such cases we usually create an entry for them as "alternative spellings", using {{alternative spelling of}}. We also add a heading for "Alternative forms" (or "Alternative spellings", though there is now a vote to eliminate that header in favor of "Alternative forms" at the main entry. We try to avoid having duplicate content for entries that only differ by spelling or form in this way. HTH. DCDuring TALK 15:35, 10 July 2010 (UTC)

Is this better? DAVilla 05:09, 11 July 2010 (UTC)

Value of the Quotations header?

Now that we have hideable quotes up and running, I'm wondering whether there is any value in continuing to have the "Quotations" header in entries. These days we (de facto) prefer to have quotations either inline (and optionally hidden) following the sense they relate to or on the separate citations: page, rather than in their own section between the definitions and translations.

On the other hand, having a quotations section in the new entry templates is a very explicit way of showing that they are a requirement of a good entry. Changing from the quotations section to the inline quotations format is not a big job (at least when there is only one sense), and may be automatable (1. delete Quotations header line, 2. prepend # to any lines starting * or *:, 3. remove any blank lines between the definition line/example sentence and the first line starting #*, 4. remove any blank lines between lines starting #* or #*: ). This is work that has to be done though.

In summary, I'm not certain whether there is more value in keeping or removing the Quotations header. Thryduulf (talk) 15:00, 10 July 2010 (UTC)

I have seen cases where I could not determine which single sense (if any) was the illustrated by the citation snippet. Though I would think that is prima facie evidence that the citation fails to serve as a good usage example (or that our definitions are inadequate), I am loathe to eliminate the quotation or move it to citation space, especially if authored by one of the sainted members of the literary canon. Thus, on an exceptional or temporary basis I retain the header. DCDuring TALK 15:41, 10 July 2010 (UTC)

The header is also an excellent visual cue to users for the "See more quotations on the Citations page" template. Time and again, new users have not understood that the Citations page existed, or have misunderstood what that page was intended for. That's a reason in addition to DCD's points. --EncycloPetey 16:28, 10 July 2010 (UTC)

In my opinion, that's more an argument for Thryduulf's point. Ƿidsiþ 15:54, 11 July 2010 (UTC)

We should have an alternative location for {{seeCites}} (or similar message). It looks silly to have it in an empty Quotations section. What about putting it at the bottom of the PoS, below definitions, but before subsections? We could even make it a right-hand side message. I think we should treat the header as a cleanup task (over 5k page) per DCDuring's reasons. --Bequw → τ 15:13, 14 July 2010 (UTC)

See abstemious for a look of how {{seeCites}} has already been used at the bottom of the main PoS section. I like it.--Bequw → τ 21:31, 14 July 2010 (UTC)

I have personally treated Quotations headers as cleanup tasks, but have been defeated often by my inability to match hallowed literary quotations with our senses, when the senses did not seem to be at fault. I would be in favor of allowing a Quotations header to be replaced with an "Ambiguous quotations" for such quotations if we can't bring ourselves to desecrate them by moving them to the citations page, which would be my preferred choice.

The implication of my experience with quotes and the excessive respect given literary quotations (single citation used as sole justification for a sense; ambiguous and dated literary citations providing sole usage examples) is that it may not be possible to fully eliminate the quotations header, though that is my preferred choice. DCDuring TALK 16:03, 14 July 2010 (UTC)

I agree with DCDuring and EncycloPetey. That said, WT:ELE currently implies that we shouldn't have multiple quotations under a given definition, and doesn't even mention the possibility of a citations page, so I'd support modifying it to better reflect current practice. —Ruakh_TALK 17:14, 10 July 2010 (UTC)

I support getting rid of "Quotations" altogether, since we are not Wikiquote. We include quotations not for the purpose of extolling the pithiness of a turn of phrase, but to show how and when a particular word is used. bd2412 T 15:58, 14 July 2010 (UTC)

Perhaps we should consider more regularly using a {{wikiquote}}, or better, {{quoteslite}} template under See also, to direct folks to other quotations sources, which we could even supplement with some of the ones we have. Such templates would make Bequw's cleanup process more productive. DCDuring TALK 16:35, 14 July 2010 (UTC)

Remove autopatrol after long blocks

Thinking about the RazorFlame discussion at user talk:msh210, I think we should keep a closer eye on the contributions of those users who return after a lengthy block. The easiest way I can think of to make this more likely to happen is to remove their autopatroller status, such that every edit should be reviewed by at least one other person. The existing WT:WL procedure should I think be sufficient to ensure they get it back when it's clear they aren't immediately returning to the behaviour that got them blocked. Thryduulf (talk) 22:16, 10 July 2010 (UTC)

ps: I forgot to add that I was thinking about defining a "lengthy block" for these purposes as 3 months or more, but that's just a figure plucked out the air. Thryduulf (talk) 22:18, 10 July 2010 (UTC)

That sounds pretty reasonable to me. Quite frankly, I would argue that any block merits greater scrutiny of the editor's edits, and thus de-auto-patrolling. The whitelist process is pretty lightweight and consequently it's easy to reinstate if the editor in question returns to good editing. What we really should have is an addition to the "blocked banner" that notes that the user is autopatrolled, so that the blocking admin remembers to do so. -Atelaes λάλει ἐμοί 23:12, 10 July 2010 (UTC)

Good idea. DCDuring TALK 01:05, 11 July 2010 (UTC)

I agree. Trust is something that is quite rightly easier to lose than to gain, and there's no harm in encapsulating that principle in procedures. I think people will understand. Pingku 17:59, 11 July 2010 (UTC)

Is this something that would need a vote to implement or can it just be written up as a policy page and promulgated somehow? Thryduulf (talk) 23:33, 11 July 2010 (UTC)

Esperanto hyphenation

I see a lot of changes in Esperanto hyphenation. Hyphenation is hard; it's rare enough that standards are hard to detect. But as I wrote at RFV

If there is any such evidence, it'll be hard to find, especially as hyphenating after one character is bad typesetting even if it isn't formally wrong. But eohyph.tex says "ebligu tranĉon post la vokaloj" (enable breaking after vowels), and all automated Esperanto hyphenation systems a quick Google shows me seem to be derived from it.--Prosfilaes 02:55, 25 April 2010 (UTC)

Is there any reason not to accept this code as best practices in Esperanto hyphenation? If there is, what is our source for Esperanto hyphenation?--Prosfilaes 13:16, 11 July 2010 (UTC)

We try and source these things manually simply because there is no "perfect" algorithm - indeed (at least for English) you can find dictionaries that provide different hyphenations for words. I imagine a good deal of the existing ones have been added by editors looking for easy things to do - so it may be worth running a comparison against the algorithm, but I'd advise not blindly believing either. I suppose the question could come down to "is the probability of human error higher than the probability of the algorithm failing?" - that I don't know the answer to. Conrad.Irwin 07:53, 12 July 2010 (UTC)

Certainly with English the hyphenation is a complete mess, with some recording how a word should be hyphenated, some showing every possible place it could be hyphenated, others being an attempt to show pronunciation, stress and or syallabation. Other than saying that hyphenations that contain different letters and/or capitalisation to the headword are not representations of how to hyphenate the headword, I don't know of any way to tell the difference other than manually. I don't know about other languages, but I imagine the same could be true for these as well. Thryduulf (talk) 08:16, 12 July 2010 (UTC)

Razorflame (and blocking more generally).

So, there's been a lot of discussion of Razorflame's block in places, and via media, that don't really strike me as the best places and media for it — msh210's talk-page, other talk-pages, e-mails, ACARS, and Rayleigh waves, to name a few. In a way, this has been a discussion of just the one editor, but it's also been a discussion of our blocking policies in general, so I think it's worth bringing here.

In short: a number of editors want him gone, and a number of editors don't. Indeed, I'm not sure any of the blocks against him, even the relatively short ones, have had real consensus.

The problem is, there seems to have developed a notion that unblocking is rude, so the former group seems to "win", even if it's in the minority. I think that's a serious problem. (Full disclosure: I share the blame for this; if nothing else, I once let an unjustified one-month block against Doremítzwr stand rather than risk wheel-warring with an admin whom I like.) I've even seen comments that seem to imply that, if it came to a vote, there would need to be a consensus to overturn the block. I happen to agree with this specific block, but I think that the general idea is, frankly, ridiculous.

But I don't have a good solution. Should we have a discussion-page for discussing contested blocks? Should such discussions come here? Should they be held on the blocked user's talk-page (perhaps with links from here or another page)? Should it be like RFD, with bold Block for 1 week and Don't block and Comment and so on? And, how should we resolve such discussions? Does it require a majority to uphold a block, or to overturn a block, or what? What happens if the discussion lasts longer than the block itself?

We should also have procedures to archive such discussions for future reference, whether or not there's a single forum for them. Recently Sven came back up, and we were basically dependent on the recollections of involved admins. It would have been nice if we'd had some links handy to demonstrate his unacceptable comments.

—Ruakh_TALK 02:15, 12 July 2010 (UTC)

Oh — and though I'm raising broader issues than just Razorflame, I might as well mention my thoughts on him specifically, which are:

• I don't like the de facto validation we've given to his promises. I'd rather block him for a very bad Ido edit than for a slightly-bad Persian edit.
• That said, I think the Persian edit is a bit worse than people have been acknowledging; I realize that transliterations, as factual information in a non–editor-specific format, are not copyrightable by editors, and therefore not actually restricted by GFDL and CC-BY-SA when copying within Wiktionary, but it's part of a general pattern on Razorflame's part of not giving attribution to his sources (and in many cases this has meant copyright violation).
• I've actually seen fairly few examples of his adding incorrect information. I have seen some, but I've also seen cases where he was wrongly accused of adding incorrect information (e.g., [[generalismo]]), and cases where he was blocked for making an edit without regard for whether it was actually correct.
• All told, given that he's basically a troll, albeit probably unintentionally so, I personally don't really mind his being blocked for a year; we can urge him to return to the Simple English Wiktionary (it seems to have a shortage of editors, and as a fairly-well-meaning, highly-productive editor with apparent native-level proficiency in English, he should be able to help there a good deal, without as much risk that he'll make edits based on knowledge he mistakenly thinks he has), and after a year, we'll have a basis to see how much he's matured as a Wikimedian.

—Ruakh_TALK 02:15, 12 July 2010 (UTC)

This seems a reasonable proposal. I'd like to note that, inasumch as I appreciate that it's not good to have users stay blocked simply because the folks who oppose the block are too timid, I think it's also not good to have wheel wars with blocks, or simply to have blocks overturned out of hand and out of process. In any case, having a formal procedure for having these sorts of discussions would likely increase participation and generally alleviate both problems. I would prefer a centralized place for these discussions. User talk pages sometimes get archived, but sometimes also simply get cleared, and my experience is that folks are less reliable in archiving discussions they'd rather forget. Also, this would make for a watchlistable page, which would encourage broader participation, and allow admins to keep up with what we're blocking for and what we're not blocking for, which might help move us away from "blocked because I'm grumpy", which we sometimes fall into. Concerning Razorflame specifically, I've already given my position....several times, probably, and so won't repeat it in detail. Suffice to say that I generally agree with Ruakh's assessment. -Atelaes λάλει ἐμοί 02:34, 12 July 2010 (UTC)

I am not going to comment about Razorflame any more than I have already done so at msh210's talk page. I do think we as a community are large enough now that we need some formal discussion place regarding blocks - the ad hoc way we currently do it was probably fine back in the day but was never going to scale well and it s long overdue for replacement. We also need somewhere to discuss editing restrictions other than blocks, so page name like perhaps Wiktionary:Blocks and restrictions would seem appropriate. Such a centralised discussion place would likely help admins who are not involved keep abreast of what is happening - for example I knew very little about the Razorflame situation until he emailed me. As such I think it would be useful to create a factual, dispassionate record (sort of case notes) about an individual dispute that summarised and linked to previous discussions. Thryduulf (talk) 08:08, 12 July 2010 (UTC)

I do not find banishing Razorflame to the Simple English wiktionary particularly enticing, especially for an edit which could be considered correct by the transliteration standard of Persian used in April 2007 (when the stuff he copied was created), nay I find any punishment for this particular edit unnecessary. For a contributor like Razorflame, two weeks without any transgression can be seen as an improvement of his behaviour and the block is far from delivering the due encouragement. That said, I am no fan of Razorflame, but I consider it accurate to evaluate the edits he makes per se and not the contributor as a whole. Even though he is not entirely unshent, I cannot concur with blocking him (or any other contributor, e. g. Sven’s tentative return) on the basis of his record. The uſer hight Bogorm converſation 08:17, 12 July 2010 (UTC)

I would be very much against trying to use numerical superiority to decide the issue of blocks. Currently the blocking policy is fairly general - but it would seem very acceptable for a block to be revoked (without fuss) if it was made without justification that the block is preventing harm to Wiktionary's progress. I think it's important to note that the policy is not worded to exclude cases where, in addition to harm, there is a lot of good - it certainly shouldn't be the case that being a good editor most of the time exempts you from being blocked if you behave idiotically occasionally, though again it comes down to a large grey area in the middle.

The reason it is considered rude to "unblock" is because it says "I don't trust your judgement" - as it seems that Wiktionary is too big for us to trust each other anymore, it may be the case that we need to create a higher authority to appeal to. I really don't like the idea, at all. Perhaps we could try adding a single safety buffer. If a contester wishes to undo an admins block, in the first instance they should ask for more explanation from the admin, if still wishing to contest, they should ask a second admin (of their choosing) to perform the actual unblock. This should allow the second admin a freeer hand, as the admittance of lack of trust has already been made. Obviously the selection of the second admin is the weakest link in the process, perhaps it should be at random, or selected from a shortlist of the contester by the blocking admin. Once a user is unblocked, I think they should remain unblocked until such a time as new proof of their casuing harm to Wiktionary is revealed. Conrad.Irwin 08:38, 12 July 2010 (UTC)

Perhaps we should have a requests for comments type system. If one user wants to discuss or challenge a block or similar action, they should first contact the admin who made the decision. If that discussion does not result in an outcome acceptable to both parties (which could be the status quo, after the challenger better understands the reasoning), then they could come to the RfC page where both parties would make a brief factual statement and invite wider community review. The consensus of that discussion should be considered binding.

As admins are only human, it should be fine to make the occasional error as long as when they make errors they are prepared to admit they were wrong and make amends for it (typically by apologising and undoing their actions). If they are not prepared to do this, or the mistakes are more frequent than acceptable, or are on several occasions completely at odds with policy and the general consensus of users then we as a community should be reviewing whether we still trust that user to be an administrator. If general consensus of users is at odds with policy then we should review the policy. Thryduulf (talk) 14:21, 12 July 2010 (UTC)

As I and SGB and now Ruakh have pointed out, we have no real process other than respecting a blocking admin's decision, and I agree that we need one. Like Ruakh, I don't know what process that would be, but I would not want it to be initializable by the blocked party (unlike on enWP, where it is). Perhaps have an admin request an explanation (on the admin's talkpage) formally, using a special template that seeks a clear one-time explanation (so the blocking admin knows to make a complete case), and if that satisfies the requester then fine, and if not then he should insist on an unblock. If the blocking admin denies it, then perhaps a vote (on some page devoted to such) among admins, to be decided either by simple majority or by a (preferably uninvolved) b'rat (in the latter case with weight given to arguments)?​—msh210℠ (talk) 19:55, 12 July 2010 (UTC)

And perhaps this process should only be in place for long-range blocks (say, longer than a fortnight). Anything less is usually not worth the bureaucracy, I think.​—msh210℠ (talk) 17:17, 13 July 2010 (UTC)

Request for bot status: ArathVerbFormBot

I formally request community approval of running the bot from the account User:ArathVerbFormBot.

Purpose: Create Bulgarian verb forms. Arath 13:39, 12 July 2010 (UTC)

I (personally approve). Is there any chance we could skip the vote all together? I mean we know exactly what the bot does. Mglovesfun (talk) 13:41, 12 July 2010 (UTC)

The description confuses me. It seems to imply that Bulgarian entries are split by pronunciation, and that verb sections go within pronunciation sections? —Ruakh_TALK 14:09, 12 July 2010 (UTC)

The bot does not do anything if the entry does not have a Pronunciation section. In entries that have only one pronunciation, the verb section goes after the pronunciation, not within (Example: грабиш). In entries that have more than one pronunciation, the verb section goes within the pronunciation section (Example: граби). The bot takes account of that. You can see in the history of граби.

• First, the bot created the entry and the Verb section was after the Pronunciation section.
• Then, there was another verb form that is spelt the same but pronounced differently. The bot didn't find a matching pronunciation. It moved the existing Verb section as a subsection of the Pronunciation section, added a number to the name of the Pronunciation section, and added a new pronunciation section with the other verb form.
• Then, there was another verb for that is spelt and pronounced the same. The bot found a matching pronunciation. Since the pronunciation was numbered the bot knew that there were more than one pronunciation section, and therefore it should search for a verb section withing the matching pronunciation section. It found a verb section and added the verb form at the end of it.

The bot will treat entries that are split in any other way, for example in Etymology sections, as entries that have no pronunciation, because it searches for pronunciation sections only in level three headers (=== ===). Arath 15:02, 12 July 2010 (UTC)

O.K., I think I understand. Thanks for explaining. :-)   —Ruakh_TALK 16:44, 12 July 2010 (UTC)

• thanks to Arath's bot's we have surpassed French Wiktionnaire's article count. --Volants 12:19, 16 July 2010 (UTC)

Pronunciation section format

The current standard pronunciation section format is a mess. It's unnecessarily huge, it's disorganized, it's constructed by a mess of templates, it's unclear, and did I mention that it's unnecessarily huge? Nothing associates the various elements with each other, other than the inconsistent indentation, so it's difficult to tell which parts are connected with which, and where new material should go. So, I think we need to change it to use just one box per accent, containing all the content related with that accent, preferably using a single template. (Maybe something like this, except built by someone who knows how to make things look not messy.) Thoughts? --Yair rand (talk) 20:48, 14 July 2010 (UTC)

Except for the button being a little big and, consequently, two lines being necessarily taken up for each item with audio, it looks like a big improvement over what would otherwise appear once one had "opened" the show-hide. DCDuring TALK 21:19, 14 July 2010 (UTC)

How about some JS to only show your preferred accent line(s)? If your preference isn't available it could show all of them. This would of course require some standardization on content. Also, usually hyphenation differences are closely related to pronunciation differences but this isn't necessarily true (US and UK hyphenation rules differ, and there could conceivable be a word pronounced equivalently that is none the less hyphenated differently). --Bequw → τ 21:25, 14 July 2010 (UTC)

I like the idea of trying to tidy up the pronunciation sections, but this is not the answer as it just produces a compressed block of text that's difficult to pick a single thing out of, and doesn't look like it would cope well with entries that are more complicated. Before we can clean up pronunciations sections, we need to firmly decide several things, including but probably not limited to:

• How should we show entries with multiple pronunciations?
  • Do we want Pronunciation N headers?
    • If so, how should they be organised? How do we nest them with entries that have multiple etymologies? How do we show entries where different regions split pronunciations differently?
    • If not how do we tie pronunciations with sense? '''bold POS headers'''?, ''italic POS headers''?, {{a|accent templates}}?, ::indentation?, ;definition lists?, ====L4 sub-headers of Pronunciation====?, ====L4 sub-headers of POS headers?====, other? What about where a pronunciation represents more than one POS?
• How do we handle sub-national region pronunciation differences (e.g. (deprecated template usage) moor is one syllable in southern England and two in Northern England)
• Do we show rhymes only for British English pronunciations when the US pronunciation varies in a regular fashion such that the rhymes are the same (e.g. /ɒ/ vs /ɑ/)?
  • If so, how do we show this? How do we note on rhymes pages which aren't rhymes in both varieties of English when the difference isn't regular?
  • If not, how do we synchronise rhymes pages?
• Do we want to show all regions always?
  • If not -
    • How do we set the preference to take account of the variety of accent labels like "UK", "RP", "US", "Northern England", "Anglicised", "Anglicized", "Francophone", "Original French", "AusE", "Australia", "Western Australia", "Welsh", "local", "standard", "rhotic" (I've seen all of these at least once)?
    • What about for non-English pronunciation regions (e.g. many Portuguese words are pronounced differently in Brazil and Portugal)?
    • What about when a pronunciation is shared between regions - e.g. if a person wants to view only British pronunciations, do we show them pronunciations that are marked as "UK, US" and do we hide the fact that it's also the US pronunciation?
    • What about pronunciations that are not marked for a region?
    • What about pronunciations that have the PoS marked in the accent template (e.g. "{{a|verb}}, {{a|South Africa|noun}}")
    • Do we show usage notes that are not relevant to the region(s) users have expressed a preference to see? How do we link usage notes to regions? What about usage notes that contrast regional differences?
    • What about when we have the preferred region for one POS but not another (e.g. UK and US exist for noun, only UK exists for verb)?
  • If so, how do we stop the sections taking over the page?
• How do we want to associate items like hyphenation (currently a real mess, but a separate thing to sort out), rhymes, homophones with regional pronunciations?
• How do we show which rhymes, hyphenation, homophones, etc relate to all regions and which relate only to some of them?
• How do we show that some rhymes/homophones relate only to some pronunciations within a region (e.g. (deprecated template usage) poor and (deprecated template usage) pour are homophonous in some southern English accents but are not in Northern English accents)?
• How do we show historical pronunciations, non-standard pronunciations, pronunciations that are affected, pronunciations that indicate age, social class, education level, etc?
• How do we do all this without excluding those on mobile browsers? those without javascript? those without UTF-8 support?
• How do we tie audio pronunciations to specific transcriptions? How do we do it when there isn't an associated? transcription when the audio is added? How do we associated two or more audio files to one transcription (e.g. rhotic and non-rhotic)?
• What do we do when we have both phonemic and phonetic transcriptions of the same sense, region, etc?
  • Can users elect to see only one of these if both exist? If so, how do we tie an audio file to a hidden transcription?

As you can hopefully see, what is needed is major structural decisions being taken and implemented rather than just decoration at this point. Thryduulf (talk) 23:03, 14 July 2010 (UTC)

The enormous potential for (appropriate) expanded content makes it all the more important that Pronunciation (and Etymology) not squeeze other content off the landing page (pace MZ), especially for unregistered users (Problem 1). Selective display partially address the display problem for registered users (Problem 2). As there has been less productive discussion let alone movement on the structural problems of pronunciation than on many of our other structural issues, sweeping the mess under the rug pending a grand solution seems like an appropriate step. The Pronunciation N header question has been Exhibit A. DCDuring TALK 00:07, 15 July 2010 (UTC)

I disagree that sweeping it under the rug in this manner will be a net benefit as every change we make will likely need to be made again. What we have now could be much better, but equally it could be much worse, so I'm very tempted to say now is the time to tackle the big question - teh longer we leaveit the more work we will have to do, as new content is added all the time. For the short term, this particular proposed layout doesn't seem like an improvement to me as it compresses everything so that it's hard to see any one thing. Also it has far too many things undefined (e.g. everything relating to different pronunciations for different parts of speech, and for transcription:audio correspondences that are not exactly 1:1) . Thryduulf (talk) 00:48, 15 July 2010 (UTC)

I'm thinking of the pronunciations going in something like the HTML <fieldset> element, one per dialect, with the {{a}} in the <legend> when there is one, template-generated, and including all the information relevant to that dialect with the stuff that applies to each dialect either outside or repeated in each one, which I would demonstrate to you if I knew how to get the MediaWiki software to accept the tag. It would look almost like the one in the box, but with a <legend> and perhaps more CSS. The length of some of the sections could be made less of a problem if we put them after the definitions, like they do on Wiktionnaire, but I seem to recall that people were not very keen on that. I don't really like the idea of using JS to hide all the dialects except one's own because it won't apply for most unregistered users, who are the main audience. —Internoob (Disc•Cont) 02:15, 15 July 2010 (UTC)

The proposed revision versions and releated discussion suggestions all have a number of problems. (1) We often have IPA for one region but audio for another, or have unspecified audio, or have unspecified IPA with specified audio. So, we often don't have all the matching parts. (2) Sometimes there is more than one pronunciation for a single word in a single region. The proposed formats would look hideous if we tried to cram all the various IPA and audio for one region into a single block. (3) Hyphenation has nothing to do with pronunciation. It's placed in the pronunciation section because we've been too lazy to put it someone appropriate. It should not be consolidated into other items that do pertain to pronunciaiton. (4) The rhymes pages are only keyed to the UK standard pronunciations. We have no Rhymes pages set up for any other region's IPA because (in nearly all situations) it would duplicate the UK content. So, the Rhymes are currently listed after the regional pronunciations because they go with all of them, and not just one. The proposal does not seem to take that into consideration. (5) Rhymes often need qualifiers added to them. The proposal does not take this into account. (6) Some entries have pronunciations listed according to part of speech or sense. The proposed revisions do not allow for that. (7) The proposed new verions are ugly. (my opinion) --EncycloPetey 03:44, 15 July 2010 (UTC)

(1) How is this a problem? (2) (I don't understand what you mean, sorry.) (3) Hyphenation sure seems like pronunciation information to me. Does anyone else think that hyphenation isn't pronunciation information? (4) I don't know where you got that idea from, but it's completely incorrect. (5) Why would you assume that adding qualifiers would be impossible? (6) Why not? (7) I agree with you on this one, which is why I was hoping someone would build a similar one that looks less messy. Maybe something using Internoob's idea... --Yair rand (talk) 21:37, 15 July 2010 (UTC)

Some of your responses do not make sense to me. I assume you did not understand my original comments and are not familiar with common content in the Pronunciation section (based on your responses I do understand). I am correct about (4); that's how the Rhymes were set up. Denying it is silly. It's the reason we have pages like Rhymes:English:-əʊl but not Rhymes:English:-oʊl; the former is the UK pronunciation IPA and the latter is US IPA for the same words.

As for (3), I have no idea why people seem to think hyphenation is about pronunciation, or why I have to keep explaining that it isn't. We go through this every six months or so. That's why we have some written explanation at Wiktionary:Pronunciation#Hyphenation.

Hyphenation is about breaking written language at the ends of lines for typographical reasons. Pronunciation is about what spoken language sounds like. Why on earth do you think they're at all related? One deals with writing, while the other pertains to speaking. Note that syllable breaks and hyphenation breaks often occur at different places as a result of this enormous difference. A simple example is axis. This word is so short that it is seldom hyphenated, but when it is, the break occurs as ax·is. The syllable break in the spoken language occurs as /ak.sis/, which is not the same. To hyphenate that way, the break would have to split the letter x in half. There are also situations where the standard hyphenation is the same in the UK and US, but where the spoken syllable breaks occur in different places. For example, the word (deprecated template usage) spasmodic has different spoken syllable breaks in the UK and US because of the difference in vowel pronunciation, but the hyphenation is the same in both countries. This happens because hyphenation is based on the breaks between written roots of words, and not on the pronunciation. Additionally, some words are pronunced the same in the US and Canada, but dictionaries sometimes differ on the hyphenation, which is an editorial choice.

Can everyone please remember this time that hyphenation has nothing to do with pronunciation, so I don't have to keep explaining this over and over? --EncycloPetey 22:01, 15 July 2010 (UTC)

Unfortunately for your sanity, I don't hold out any hope of that happening until we move hyphenation outside pronunciation section. Thryduulf (talk) 22:17, 15 July 2010 (UTC)

(@YR) (1) is a problem for grouping them together by accent. You would have to determine what the unspecified part represents. (@EP) (2) Then we just have to find a format that doesn't look hideous for the most part (easier said than done, I know) and accept that we probably won't appeal to everyone's tastes. As for (3), I understand what EP means and agree that that probably needs to be fixed one way or another. I don't know how, though. (4) See DMZ. But for most, yes, it will have to either be duplicated a bunch of times or go at the end. Perhaps we should redirect oʊ to əʊ? —Internoob (Disc•Cont) 01:14, 16 July 2010 (UTC)

Rhymes pages are mess currently (but a different one). I've suggested before somewhere (I can't remember where though, but possibly somewhere related to the pronunciation exceptions stuff?) about making the Rhymes namespace work similarly to the Category namespace, with the existing pages becoming like category description pages giving the pronunciations, and some common/otherwise important/useful rhymes. The remained would just appear as they do in the current category. As I remember it got a little bit of attention with some negative comments from people who apparently didn't understand it properly (I'm not suggesting deleting the current pages) and some "sounds a good idea but meh about doing anything about it now" comments). If this were done then having both /-əʊ/ and /-oʊ/ would become much less of a maintenance problem. My attitude for some time though has been to just leave the rhymes namespace in the mess that it's in currently until after we've sorted out (or at least agreed how to sort out) the pronunciation sections in the main namespace). Redirecting /-oʊ/ to /-əʊ/ is not a bad idea in the meanwhile though. Thryduulf (talk) 01:32, 16 July 2010 (UTC)

They use us but doesn't cite us

While researching upcoming WOTD (deprecated template usage) spasmodic, I noticed that "Webster's Online Dictionary" lists our definitions (see). However, they credit Wikipedia as the source rather than Wiktionary. So technically, they are violating our license, yes? Does anyone see how (1) to contact them, and (2) whether this site really has any connection to Webster's or is just ausing the Webster's name. --EncycloPetey 19:13, 15 July 2010 (UTC)

Hm? I see "Wiktionary" listed next to the definition, not "Wikipedia". --Yair rand (talk) 19:21, 15 July 2010 (UTC)

But it doesn't say the definition is from Wiktionary; it just gives Wiktionary as the "domain", with a link to a bunch of translations of the word (deprecated template usage) Wiktionary. The "references" link goes to a page that implies that the information is from Wikipedia. IMO, neither one gives enough information for a user to track down our entry. —Ruakh_TALK 19:29, 15 July 2010 (UTC)

YR: follow the link that says "References" at the end of each definition. It's a page listing all of Wikipedia's licensing information, but doesn't mention us. I wouldn't have guessed (without knowing) what "domain" means, since one of them just says "Health". --EncycloPetey 19:31, 15 July 2010 (UTC)

Re: (1): There's an off-domain e-mail address at the bottom of http://www.websters-dictionary-online.org/credits/editor.html. Re: (2): The name "Webster's" is not protected. Anyone who wants to name their dictionary "Webster's" can legally do so. I feel confident that this site is not affiliated with any Webster('s), such as Merriam-Webster, that we're otherwise familiar with. —Ruakh_TALK 19:37, 15 July 2010 (UTC)

Wikipedia also uses a different licence than we do, so they aren't even doing that right... —CodeCat 21:04, 15 July 2010 (UTC)

5 times, baby

Woop!!!! Wonderfool's just managed to get adminship and delete the main page 5 times. See you all next year! --Volants 12:25, 16 July 2010 (UTC)

I told you this was Wonderfool, nobody listened to me. --Vahag 12:39, 16 July 2010 (UTC)

"Next year"? Meaning not sooner? Meaning I'm not WF? :( I was so hoping I was. —Internoob (Disc•Cont) 17:46, 16 July 2010 (UTC)

Just because he says next year, it doesn’t necessarily mean next year. It could be tomorrow. Or he could already have an active sock here. And it could be you. You can’t take him at his word, since he delights in going back on his word. —Stephen 18:11, 16 July 2010 (UTC)

Volants

WTF just happened? Does this mean Volants is Wonderfool? Mglovesfun (talk) 12:42, 16 July 2010 (UTC)

Gloves, you should work at Scotland Yard :) --Vahag 12:43, 16 July 2010 (UTC)

Ha, and he nominated himself for admin, then supported himself. Rude words. Mglovesfun (talk) 12:47, 16 July 2010 (UTC)

We need to set up a mainpage monitoring service. A bot with sysop privileges (not necessarily with a bot flag, just a script sitting dormant) that would check deletion log every minute, restore the mainpage if deleted and block future WF socks deleting it. It would also log onto IRC and notify the active stewards of the necessity of immediate account desysop. That wouldn't be hard to code (I volunteer if necessary). There is no hurry though, I think we're safe for the rest of this year. --Ivan Štambuk 12:51, 16 July 2010 (UTC)

There are two users I suspect of being Wonderfool still with active accounts. I've passed those two names onto to other admins by email, but I'd rather not say them openly to avoid embarrassement if I'm wrong (PS I'm not one of those two ;o)). Mglovesfun (talk) 12:54, 16 July 2010 (UTC)

Or so you would have us believe. DCDuring TALK 13:35, 16 July 2010 (UTC)

Can someone chronicle the various users who have been Wonderfool (those with extreme certitude)? I forget who they all were. Maybe using the system mentioned above, like at Wiktionary:Blocks and restrictions/Wonderfool? --Bequw → τ 13:59, 16 July 2010 (UTC)

[4] can get whoever wants to do that started: search through that page for the string 'wf' or 'wonder' (case-insensitive). I can't think of any benefit of having such a list, though.​—msh210℠ (talk) 15:24, 16 July 2010 (UTC)

How about User:Wonderfool rather than a Wiktionary prefix? Create it and fully-protect it. Mglovesfun (talk) 15:45, 16 July 2010 (UTC)

And the reason would be he gets mentioned a lot on WT: pages and people who don't know anything about him (like me a year or so ago) have nowhere to look directly. Mglovesfun (talk) 15:48, 16 July 2010 (UTC)

True, but see also [[w:WP:DENY]].​—msh210℠ (talk) 15:57, 16 July 2010 (UTC)

Exactly, just ignore it -- he deletes the main page, we undelete it -- so what? It's five minutes of hassle and makes zero difference to anything, yet everyone always seems to act like Al Qaeda has infiltrated the White House. Ƿidsiþ 16:07, 16 July 2010 (UTC)

Proven WFs so far (those that I can remember) :- Wonderfool, Dangherous, Keene, Jackofclubs, Borganised, Volants. SemperBlotto 15:50, 16 July 2010 (UTC)

Rising Sun, Soleil Levant. Mglovesfun (talk) 15:53, 16 July 2010 (UTC)

See also m:User:Dangherous --Ivan Štambuk 16:25, 16 July 2010 (UTC)

I'd much rather we didn't chronicle it - it's too much like a hall of fame. Conrad.Irwin 16:40, 18 July 2010 (UTC)

Bulleted references

Should bulleted references, like at unvaluable, be treated as a cleanup issue? This style, makes it seem like we copied the entry entirely from the referenced dictionary. When only parts of the entry were copied or reworded, we should reference those parts with footnotes (<ref> tags). When the entry was copied entirely from a public domain work, we should improve the entry to the point where we can again use footnotes. Is there any reason to not convert these bulleted references and keep them as they are? --Bequw → τ 13:42, 16 July 2010 (UTC)

I have not interpreted Wiktionary's use of "References" as being the same as WPs. Just as COPYVIO works differently (hard to think of how an exact copy of a large portion of a copyrighted definition could be "fair use"), I think of References as being useful for helping contributors and users look at alternative wordings, registers, usage examples, or sense division. I often insert {{R:OneLook}} for that purpose. We have the Webster tag for the cases where the wording is painfully close to the original Webster 1913 copy. The wording of the copyright-free definitions is almost always awkward and date, if not obsolete. DCDuring TALK 14:01, 16 July 2010 (UTC)

If the links are just provided to allow users to compare our entry versus that of other dictionaries (which is great), then they should be in =External links=. If they are used to support claims in our entry, we should cite which parts they are for. This also helps with formatting, =References= use #'s and =External links= uses *'s. As an aside, we really should have more material on this (the ELE was all I could find). --Bequw → τ 17:08, 16 July 2010 (UTC)

"External links" is not sanctioned in the text of WT:ELE whereas "References" is. Both are mentioned in an the example.

In any event, I almost always refer to (reference ?) other dictionaries when working on the substance of an entry. Isn't that what "References" is for? We may need different template display wording if we have simply copied content, presumably from copyright-free sources. DCDuring TALK 18:01, 16 July 2010 (UTC)

IANAL but a mention in an ELE example seems acceptable. I'm sure most everyone refers to other dictionaries when crafting entries. I think we should <ref>-tag parts that were added just because of another dictionary and without separate supporting material (eg quotations or audio files). Entries start out looking more like copies of other dictionaries' entries but as we build up separate supporting material, the link to other dictionaries because less general and more specific (for example, getting limited to just the etymology section). --Bequw → τ 02:41, 17 July 2010 (UTC)

I have been acting on my vague memory that in some conversation on this page someone said that external links was a less-than-desirable heading. I don't see any use to it except for those cases where we link to, say, Ethnologue. I have also found external links to be a fairly rich source of dead links. DCDuring TALK 03:15, 17 July 2010 (UTC)

The most common thing I see in external links sections is links to Wikipedia, very often to articles that are conceptually related to the term rather than directly about the word/subject (which links end to be inline). Thryduulf (talk) 09:18, 17 July 2010 (UTC)

I couldn't find the BP discussion you were think of, but I did stumble across Wiktionary:Beer parlour archive/2007/September#References, where EP makes my same argument. I think we should have a Wiktionary: page about each of the heads so that we can record some of the common practices about each. This would augment the ELE. --Bequw → τ 21:12, 17 July 2010 (UTC)

Not a bad idea. I had meant to add "Dictionary notes" to the list of overlapping headings in this grouping. The end product might be a matrix (or set thereof) laying out the use of headings with specific types of content, possibly by language. DCDuring TALK 21:32, 17 July 2010 (UTC)

Gutenburg rankings

Over at Wiktionary talk:About English#Placement of Gutenberg rankings I suggested moving the {{rank}} templates from the top of English entries into a Trivia section. Since I'm not sure of how many watch WT:AEN (hint please do in order to remove BP clutter), I thought I bring it up here before going ahead. I want to move it because this information is too insignificant to have more prominence than pronunciations and definitions and so should be moved lower. Trivia seems better than See also, which is more for other things (semantically related terms, wikimedia links, etc.). --Bequw → τ 20:47, 17 July 2010 (UTC)

I've replied there. Thryduulf (talk) 22:54, 17 July 2010 (UTC)

Winning words at a spelling bee

(deprecated template usage) sanitarium and other words contain a trivia section that includes a note that it was the winning word at a spelling bee. Regardless of how notable or otherwise the spelling bee is, this is just encyclopaedic cruft about that contest and so imo it should not appear in our entries. A list of winning words might be appropriate for the Wikipedia article about the spelling bee, or perhaps some appendix here (although I'm not convinced of that). If others agree with me, then I think this should just be deleted from any entries where it appears. Thryduulf (talk) 09:30, 18 July 2010 (UTC)

Note previous discussion at Wiktionary:Beer parlour archive/2009/September#Scripps National Spelling Bee winning words. --Bequw → τ 16:07, 18 July 2010 (UTC)

I agree with Thryduulf that these bits of trivia have no place in entries, and should be deleted on sight. bd2412 T 16:44, 18 July 2010 (UTC)

Had Logomaniac not been so charming, we probably wouldn't have allowed it. Would a See also link to an Appendix of such words be better? It would at least be hidable under {{rel-top}}. Or should we simply exclude this kind of metadata from principal namespace. I wouldn't mind putting it all (anagrams, frequency, folk etymologies?, WOTD-hood) in another namespace, possibly called "metadata", including new information about entry characteristics, like readability scores, maintenance information, etc. DCDuring TALK 17:15, 18 July 2010 (UTC)

I'm weakly in favour of anagrams remaining in the main namespace, as Equinox put it in the previous discussion they are "an objective property of the word". Folk etymologies I think should definitely be in the main namespace so as to both educate readers about their inaccuracy and discourage editors from adding them as a real etymology (or indeed replacing the real etymology with the folk one, although I have no evidence of this actually having happened). Dictionaric meta information about the words is something that we need to be able to handle, although we should do it in a way that allows us to include information at the entry level (e.g. frequency of the word (deprecated template usage) run over all senses), at the PS level (e.g. frequency of (deprecated template usage) run as a verb vs (deprecated template usage) run as a noun) and at the sense level (e.g. comparative frequency of "drug running" vs "drug smuggling"). Thryduulf (talk) 19:09, 18 July 2010 (UTC)

I agree we don't need WOTD-hood or spelling-bee-winning-word-ness. Frequency is useful information about how a word is used, and should be kept. Anagrams should also be kept, though I can't put my finger on why. Folk etymology, if so etymologized by enough folk, should be kept just to show that we're repudiating rather than ignoring it.​—msh210℠ (talk) 16:27, 21 July 2010 (UTC)

I don't like the spelling bee information, it isn't lexicographical at all. Anyone who wants to know what the words were could look it up on wikipedia. ~ verbalista | talk ~ 18:23, 21 July 2010 (UTC)

As far as I can tell, every entry that contains this spelling bee cruft is listed at User:Thryduulf/spellingbee. If there are no objections in a few days I'll go through and delete them all. Thryduulf (talk) 17:10, 21 July 2010 (UTC)

Well, I wouldn't mind. But where are the people who stood up in favour of the spelling bee information last time I raised this? Equinox ◑ 17:13, 21 July 2010 (UTC)

Once Logomaniac left, her spell on us was broken. DCDuring TALK 18:04, 21 July 2010 (UTC)

Trivia

Following a short discussion at user talk:Bequw, it is clear that we hold very different opinions about the merits of trivia sections and the inclusion of trivia generally.

The ELE says only, "Other sections with other trivia [in contrast to anagrams] and observations may be added, either under the heading "Trivia" or some other suitably explanatory heading. Because of the unlimited range of possibilities, no formatting details can be provided."

I'd like to completely revoke this section and prohibit the inclusion of trivia altogether. Trivia sections are being used to hold various things including:

• Encyclopaedic notes about one or more of the senses - if it isn't part of the meaning, usage notes or etymology then this should be a Wikipedia.
• Cruft relating to the appearance of the word in spelling bees (see section above), and other appearances of the word in other bits of popular (or not-so-popular) culture. These should simply be deleted imho as they add no value to the entry.
• Notes about uses of the word in various literary works. Unless the use satisfies the CFI as a separate sense, the notes should just be deleted or moved to the Wikipedia article about the work.
• Notes about pronunciation, rhymes, etc. - these should be moved to a usage notes sub-section of the pronunciation section if they are actually impart useful information, otherwise they should be deleted.
• Notes about the spelling, e.g. weird#Trivia notes that it is one of the most common exceptions to the "I before E except after C" heuristic. If it can be verified that it is indeed one of the most common (it isn't cited at the entry, and I've not looked) then it might be worth including in a section about the orthography of the word (which would also be a good place for hyphenation information and maybe also anagrams). If such notes can't be verified, or impart no useful dictionaric information then they should be deleted.

As a general rule of thumb, our entries should contain only:

• Dictionaric information about the word being defined (definitions, alternative spellings, pronunciation, etymology, usage notes, links to etymologically, semantically and orthographically related words, notes related the word as a wider part of the language, etc)
• Quotations and other references to verify the dictionaric information
• Links to dictionaric or encyclopaedic information about the word or its meaning hosted elsewhere.

If a trivia section contains any of this, then it is not trivia and should be moved to a more appropriate part of the article. If it contains none of these things, then it should just be deleted. Thryduulf (talk) 09:55, 18 July 2010 (UTC)

I'd like to delete the lot, yes. Mglovesfun (talk) 22:12, 18 July 2010 (UTC)

"Obsolete" and "archaic" ?

Hello. What are the tags "obsolete", "archaic", "dated", etc. generally taken to mean here? [Category:Obsolete] says "Words, phrases or usages no longer in current use, but found in older texts." and [Category:Archaic] says "Archaic terms are no longer widely used or understood, but will be found in older texts." Those two explanations don't seem that different. I know Merriam-Webster says obsolete means "no evidence of standard use since 1755" and archaic "standard after 1755 but surviving in the present only sporadically", but different dictionaries have different terms. ~ Logodaedalist | Talk ~ 22:11, 18 July 2010 (UTC)

Yes, on Wiktionary they're essentially interchangeable. Mglovesfun (talk) 22:14, 18 July 2010 (UTC)

Should they be? ~ Logodaedalist | Talk ~ 22:19, 18 July 2010 (UTC)

We had a discussion about this recently, see #Labels (informal, colloquial and ...) further up this page. The difference as expressed there is that "archaic" terms survive in fixed expressions, faux-archaicisms, etc, and will generally be understood but sound very old fashioned; while "obsolete" terms on the other hand generally will not be understood. Personally I think there is another aspect to it, in that "archaic" terms drifted out of use, whereas "obsolete" terms have been replaced/superceded more decisively. However, "obsolete" does get used where "historical" should for instances where the word isn't obsolete but the thing or concept it refers to is (e.g. modern technology has generally rendered lamplighters superfluous, and so the profession is obsolete, but the term (deprecated template usage) lamplighter is not obsolete, as it is still the current term used to refer to the profession. Thryduulf (talk) 22:51, 18 July 2010 (UTC)

After edit conflict, not too much different from Thryduulf.

In almost all dictionaries, "archaic" means it is still understandable in the sense so labeled, but is unlikely to be used outside of a relatively specialized, often literary, context. "Obsolete" means that the sense is likely to be not understood or misunderstood by a native speaker. This is standard lexicographic usage, which hard-core dictionary users understand, though not so many others. If some (most?) users confuse the two, little harm is done.

For example, (deprecated template usage) address might be considered "archaic", whereas (deprecated template usage) address would be considered "obsolete". I think that, if any other dictionary (or one from each side of the Pond) calls something either "obsolete" or "archaic", we can rely on it. But we can find contemporary usage that might take something out of "obsolete" and put it in "archaic" or even take it out of either category. DCDuring TALK 23:07, 18 July 2010 (UTC)

Really just repeating what I've said before, but an archaic term has to be really old, whilst a term that's been used as recently as 1970 can't be archaic, as that's too recent. Mglovesfun (talk) 23:26, 18 July 2010 (UTC)

No. A term can be in limited current use, especially literary, and still be archaic. The archaic spellings (deprecated template usage) shoppe and (deprecated template usage) olde are obvious examples. DCDuring TALK 00:51, 19 July 2010 (UTC)

Wouldn't shoppe and olde be more of faux archaic? ~ Logodaedalist | Talk ~ 01:34, 19 July 2010 (UTC)

Yes. Sadly the faux usually has good publicists. DCDuring TALK 02:41, 19 July 2010 (UTC)

Hmm. But there aren't any dates attached to either one, then. So you say the only difference here is that "archaic" means it still would be understood although not used, and "obsolete" wouldn't be understood or used? ~ Logodaedalist | Talk ~ 23:47, 18 July 2010 (UTC)

That's what I'm saying. I think it's close to what Thryduulf is saying. He is also going beyond what I was saying to discuss "historical", which might deserve wider use. We also have {{dated}}, which seems to be used for terms that are or have been used by some living speakers and are understood, but are out of fashion. DCDuring TALK 00:51, 19 July 2010 (UTC)

OK, that makes it a little more clear.... How does one determine whether a term is in current use, or would be understood by other speakers, then? ~ Logodaedalist | Talk ~ 01:34, 19 July 2010 (UTC)

Your questions have forced me to make my own thinking explicit. I may be mistaken about some aspects and nuances of this.

Perhaps by looking using the date-range capability of Google Books. If books with modern publication dates (excluding the numerous reissues) have a lot of usage not in historical novels and fantasies, then it is at least in literary use. One might be able to make a crude estimate of the frequency of the term in question relative to a term of constant frequency over modern and former times. In that way one could test for a decline in relative usage frequency and not be fooled by the absolute number of occurrences. Google news, COCA, and BNC can provide evidence of wider usage (The latter two also include literary usage.). DCDuring TALK 02:41, 19 July 2010 (UTC)

Mm-kay, I'll check out those sites. Thanks for the responses! ~ Logodaedalist | Talk ~ 11:42, 19 July 2010 (UTC)

• It's not a matter of how old they are. Most words go from being common to being rare (I often tag {{context|now|_|rare}}) to being obsolete. At that point they are no longer used. Archaic is a different thing altogether, that is where an old word stays in limited usage but with a specific effect of "sounding old". Being archaic can often stop a word from becoming obsolete – for a while. (A similar branching-off happens with historical words, which are still in use, but only to describe things or concepts which we no longer use.) Ƿidsiþ 11:48, 19 July 2010 (UTC)

• +1. —Ruakh_TALK 12:22, 19 July 2010 (UTC)

I'm still a little confused, but okay. So archaic just means it sounds old, while obsolete means it really is old? And could a word be rare without quite being obsolete? ~ Logodaedalist | Talk ~ 14:57, 19 July 2010 (UTC)

Obsolete tends to correlate with age, but need not. There are a number of 19th century American and Victorian coinages (ie, not very old, but not merely "dated") whose meanings are all or mostly obsolete (ie, unintelligible or analogous to "false friends": misleading). If a word is rare, but all the citations are 20th century or later, it would be hard to justify calling it obsolete instead of just {{rare}}. DCDuring TALK 16:17, 19 July 2010 (UTC)

@Logodaedalist: Not quite. Both terms mean that a word is old. The difference is that (deprecated template usage) archaic means it's old, and has now mostly fallen out of use, but is still understood, it just sounds old now, whereas (deprecated template usage) obsolete means it's old, and has now fallen out of use, and is no longer understood. For example, (deprecated template usage) thy is archaic — when we encounter it, we process it as roughly "old-fashioned word for 'you'" — whereas (deprecated template usage) Japonia is obsolete — when we encounter it, we can guess from its form that it means something like “Japan and its environs”, and in context we might do better, but we don't recognize it, and without context we couldn't guess that it's simply a no-longer-in-use name for Japan. —Ruakh_TALK 16:58, 19 July 2010 (UTC)

Yeah, I think that's kinda what I meant. Is there also a tag for faux-archaisms? ~ Logodaedalist | Talk ~ 23:02, 19 July 2010 (UTC)

ISO-639 NDS not "Low Saxon"

Not sure if this is the right discussion room for this, but I noticed on the translations for water, language ISO-639 nds shows up as "Low Saxon." NDS is the code for "Low German," of which Low Saxon is a variety. Other languages, language groups, & dialects under nds include:

• nds: Nedderdüütsch [Low German] (N DE & E NL) < ‡latn-gml: Middle Low German (1100–1600; Hanseatic League)‡ < ‡latn-osx: Old Saxon/Old Low German (8th ha–1100 CE; NW DE & DK; <qin)‡
  • Nedersaksisch [Dutch Low Saxon] (NE NL)
  • Plattdeutsch [E Low German] (NE DE)
    • latn-nds.b: Brandenburgisch [Brandenburgish/Markish] (Brandenburg, DE)
      • latn-nds.b: N Markish (Stendal, Wittenberge, & Prenzlau, DE)
      • latn-nds.b: S Markish (Brandenburg anna Havel [Brandenburg an der Havel], DE)
    • latn-nds.v: Mecklenburgisch-Vorpommersch (Mecklenburg-Vorpommern, DE)
      • latn-nds.m: Mecklenborgsch/Mäkelborgsch [Mecklenburgish] (Mekelnborg [nds: Mecklenburg], DE)
      • latn-nds.z: Strelitzisch (Mecklenburg-Strelitz, DE)
      • latn-nds.w: Westpommersch (Vörpommern [nds: W Pomerania])
    • latn-nds.l: Niederpreußisch [deu: Low Prussian] (E Prussia)
      • latn-pdt: Plautdietsch [Mennonite Low German] (>16th ha; Prussia)
    • latn-nds.p: pommersch Platt [Pomerianian Low German] (Pommern [Pomerania])
  • W Low German (NW DE)
    • latn-frs: E Frisian Low Saxon (E Frisia)
    • latn-nds.e: Eastphalian (Oostfalen [Eastphalia], DE)
    • latn-nds.s: Noordneddersassisch [nds: N Low Saxon] (N DE)
    • latn-wep: Westphalian (Westfalen [deu: Westphalia], DE)

(copied from my personal notes, qqq.x notation is not ISO and just for my personal use) Nicoleta 01:59, 19 July 2010 (UTC)

Not sure if this helps, but we have codes from Old Low German and Middle Low German, not just "Low German" on its own. Mglovesfun (talk) 12:31, 19 July 2010 (UTC)

We use Low Saxon for nds (an acceptable alternative by both Ethnologue and ISO) because we use Low German ({{etyl:gmw-lge}}) to refer to the whole history of: "modern Low German"/"Low Saxon" ({{nds}}), "Middle Low German" ({{gml}}), and "Old Low German"/"Old Saxon" ({{osx}}). It's not ideal since Low Saxon can be ambiguous (see w:Low Saxon). Complicating the issue is that we avoid having "Modern" in a language name. --Bequw → τ 13:13, 19 July 2010 (UTC)

I was always under the impression that they are the same thing. The modern descendant of Old Saxon. What exactly is the difference, if there is one at all? —CodeCat 13:29, 19 July 2010 (UTC)

Re Bequw, yes sorry I later realised this but forgot to correct myself. Mglovesfun (talk) 20:32, 20 July 2010 (UTC)

Translations in Translingual section

How about ===Translations=== section for Translingual "words"? Is this allowed? WT:ELE says that "Translations are to be given for English words only". See for example [[!]]. I think if a word is "translingual", it is the same in all languages and translations are needless. Maro 20:35, 19 July 2010 (UTC)

Translingual doesn't necessarily mean "panlingual" as in "all languages", just the same in several historically different languages (true panlingualism would seem impossible since no script is even used in all languages). Translations, therefore, *could* work, but I haven't seen many (any?) good examples. The translations at [[!]], for instance, should be symbolic, which the current ones aren't. --Bequw → τ 02:44, 20 July 2010 (UTC)

Some languages, such as Hebrew and I think Finnish, have their own scientific names for taxa. For example, the family (deprecated template usage) Felidae in Hebrew is (deprecated template usage) חתוליים (khatuliyím). That said, (deprecated template usage) Felidae is also often used in Hebrew contexts — it may even be more common — such that Template:Hebr is as much a "Hebrew-specific synonym" as a "Hebrew translation". Even so, I plan to add it to [[Felidae#Translations]], not to [[Felidae#Synonyms]]! —Ruakh_TALK 12:17, 20 July 2010 (UTC)

Are there any languages that don't use certain scientific names at all? As far as I known, Felidae is not used at all in Dutch, the proper translation is katachtigen. —CodeCat 12:47, 20 July 2010 (UTC)

I think that, for scientific names used in biology (i.e. names in scientific Latin), translations should be the common name in each language. This is the ideal place for gathering vernacular names in all languages, because (in principle) a scientific name cannot be ambiguous, while vernacular English names are often ambiguous. Lmaltier 19:46, 20 July 2010 (UTC)

Translingual words are often used in English (not surprising) so we could add an English section to Felidae and cite it, it would just be redundant to the Translingual section. So when Translingual words/terms are used in English, cut out the middle step and add translations directly to the Translingual sections. Per Maro, ELE should reflect this. Mglovesfun (talk) 20:31, 20 July 2010 (UTC)

Yes, but I would keep the English/French/etc. sections nonetheless, only when useful (for pronunciation in the language, gender in the language (as opposed to gender in Latin), citations, etc. But my proposal was mainly relevant for species, not families. Lmaltier 05:46, 21 July 2010 (UTC)

I may add that, for families, there may be a translation (adaptation to the language), e.g. Felidae may be used in French, but often becomes félidé (singular), félidés (plural). This is a general rule in French for all families. Lmaltier 05:50, 21 July 2010 (UTC)

Request for bot status: QuasiBot

I hereby formally request community approval for running the bot QuasiBot (talk • contribs), whose purpose is to create Latin verb (and participle) forms.   AugPi 11:13, 21 July 2010 (UTC)

Does it do anything FitBot doesn't? — [ R·I·C ] opiaterein — 15:28, 21 July 2010 (UTC)

It would have a public feed-me page... and EP said on my talk page that he hasn't set up FitBot to conjugate 2nd conjugation verbs: he said I could handle (in his words: "blaze trails" with) those. And, anyway, is there a rule that inflectobots have to have a monopoly over the languages whose verbs they conjugate? Because the format which I use to create (articles for) Latin verb forms is exactly the same as the format used by FitBot: there wouldn't be an incompatibility or "dissonance."   AugPi 18:19, 21 July 2010 (UTC)

He said that he set up his bot to conjugate 1st and 3rd conjugation verbs, so that I should concentrate on 2nd and 4th conjugation verbs.   AugPi 18:21, 21 July 2010 (UTC)

Inflection-line tables - again

I'd like to bring up the topic of removing inflection-line tables again (previous discussion). In addition to the problems discussed before, I've just seen some problems with several mobile gateways and apps (even those designed for newer phones). As you can see from viewing house through wapedia and Sevenval, these sites show both the inflection line and the table (not selectively hiding one). This looks pretty ugly. In the previous discussion, the one dissent to removing the tables was that they helped draw attention to the PoS section and therefore definitions. Is there a way that we can do this without the inflection-line tables? What about something like:

.infl-inline { background-color: #ADFFD6; }

as an option at WT:PREFS? The color is obviously up for debate. Or does anyone else have another suggestion? --Bequw → τ 03:37, 21 July 2010 (UTC)

Do mobile devices not have some way of identifying themselves and possibly device characteristics (bandwidth, screen width)? If there were something simple we could do with the information, that would be generally helpful. I would not want us to be wasting our development talent on what the gateways should be doing, but, if a gateway is doing only something relatively trivial, we need not protect them by refusing to minimally facilitate direct access from mobile devices. DCDuring TALK 11:17, 21 July 2010 (UTC)

We're limited here to doing the client querying in JS (don't think you can get bandwidth though). But that's slow and clunky as it that means the client still downloads all the normal site files and at the end the JS can reformat things. This is why the gateways and apps are nice (smaller download and pre-formatted for a small screen). Wikipedia has a new & better system where they detect and redirect mobile users to http://en.m.wikipedia.org/ but they haven't said if/when they'd roll it out to the other wikis. --Bequw → τ 13:09, 21 July 2010 (UTC)

Sounds good to me. In fact, just name the cookie for imposing the background identically to the one now showing tables, so no one even needs to change his PREF.​—msh210℠ (talk) 16:24, 21 July 2010 (UTC)

Done. As the previous display option wasn't at PREFS, I've held off on putting the highlighting one there as well. Shout out if you'd like it to be and I'll do it. Also, a related problem exists for {term}, which I'll try and work out a solution for next (probably implementing the customization in JS). --Bequw → τ 18:11, 24 July 2010 (UTC)

I'm apparently blind. It's in PREFS now in the same slot. --Bequw → τ 22:14, 25 July 2010 (UTC)

angrams, word play, false friends, extensive lists of cognates, etc

Following on from the discussion at WT:AEN about frequency lists, and related to the discussions above about Trivia sections, I think we need to decide where (if anywhere) in the entries the following should be placed.

• Frequency rankings
  • Currently suggested at WT:AEN to move the existing Gutenberg rankings to the Usage notes sections. I'm not sure this is the best, especially if we get additional rankings (e.g. it might (with varying degrees of likelihood) be possible to get rankings from national corpuses, wikipedia, wikisource, google books, etc).
• Anagrams
  • Currently in the Anagrams section, but it has been proposed to move them to Trivia - given my stance on Trvia sections I obviously disagree with this, but it might be better to group them with lists of other words connected only by the orthography
• Word play
  • Currently where this exists, it's in Trivia sections. Going through these I've seen notes about words that use every vowel in alphabetical order (currently covered by a category), words that form a sequence of other words when letters are left off each time, words that are "notable" due to the position they occurr in $dictionary, words that are the "longest" (of a certain type) in common usage in $language, etc. Do we even want these? If so, where? I'm aiming to get rid of all the Trivia sections as they attract meaningless trivia that we really don't want (e.g. appearances of words in $popular_culture/$book/etc).
• Scrabble
  • Notes about words that are particularly high scoring, or were used in record breaking games, etc. This seems more encyclopaedic about Scrabble than lexical about the words, but this is appearing currently in Trivia sections. If we want it, where should we include it?
• Spelling bee winning words
  • See separate section further up this page.
• False friends
  • This currently appears in Trvia sections and Appendix:Glossary of false friends. Bequw suggested at WT:AEN that these should go in the Etymology section, although I'm not convinced of that.
• Extensive lists of cognates
  • Currently these appear in etymology sections, but they can get truly excessive and take up huge amounts of screen estate and make the actual etymons harder to sport.

One suggestion I made at the AEN discussion was a separate per entry namespace companion page to hold this information, possibly with a tab in the same style as Citations. What do others think of all this? Thryduulf (talk) 11:32, 21 July 2010 (UTC)

If you read Wiktionary:Feedback, the most common complaint is that definitions are hard to find, so cutting back on 'other stuff' seems good to me. Dare I say it, we have a format that pleases the editors more than the readers. We don't (IMO) have a client-centered approach. I'm not mad about anagrams as I consider them mathematical (an I'm a former tournament Scrabble player). I'd keep homophones as they're a sort of "disambiguation" feature (you've typed in feet - did you mean feat?) But certainly I'd like to see cognates used more in appendices and less in entries, and no Scrabble/spelling bee stuff at all. Mglovesfun (talk) 11:39, 21 July 2010 (UTC)

Proposal for a new namespace: "Sign Gloss:"

Following up this discussion, I would like to propose a new namespace called "Sign Gloss:". The purpose of this namespace would be to make it easier for novices to read and write sign language entries.

The current sign language policy requires that entries have names and headwords like "OpenA@Palm-ThumbUp-FlatB@CenterChesthigh-PalmUp OpenA@Palm-ThumbUp-FlatB@CenterSternumhigh-PalmUp". This name can be understood as a phonemic spelling of the sign itself, using a format that, while specific to Wiktionary, is closely derived from work in sign linguistics.

This "movement encoding" format provides valuable information for sign language entries, but requires substantial linguistic knowledge to write or decode. For this reason, many (perhaps most) sign language dictionaries are indexed by sign gloss. The sign gloss for a sign is essentially a semi-standardized translation into a written language, but it is used as the name of the sign.

A "Sign Gloss" category on Wiktionary would allow the above 97-character string to be identified as "Sign Gloss:HELP". A speaker of American Sign Language could create such a page, maybe with a video demonstrating the sign and a usage example, without having to learn Wiktionary's encoding system. A student of ASL could more easily find such a page, or recognize its meaning from the URL. "Sign Gloss:HELP" might redirect to the longer title in the main namespace, or it might be a stub definition page of its own if no movement encoding has been contributed for this sign. If a gloss corresponds to multiple signs (e.g. in different sign languages), then the page might provide links to each of them.

There are certainly many questions to answer about how exactly a Sign Gloss namespace should work, but I don't think we need to resolve all of them before the namespace can be created. At worst, it should do no harm. At best, it might help Wiktionary to become a much better dictionary for sign languages. Bemasc 19:30, 21 July 2010 (UTC)

I think this is a good idea. I'm not certain about redirects though, as I'm pretty sure most if not all sign languages would have a sign for "help". Would it be possible to structure it like the main namespace, ie. have an L2 section for "American Sign Language", another for "British Sign Language", etc? Thryduulf (talk) 20:54, 21 July 2010 (UTC)

Thanks. I agree; if a gloss corresponds to multiple signs in different sign languages, it should definitely not be a redirect. I think L2 sections as you describe would be a good way to structure a page in that case. Bemasc 04:17, 22 July 2010 (UTC)

I also like the impetus. Two main questions. (1) Would this be a true namespace (independently searchable) or a pseudo-namespace (entry titles with a standard prefix that looks like a namespace)? Or do you care? (2) Would sign languages originating in "foreign countries" use an English GLOSS, or a foreign one? --Bequw → τ 03:14, 22 July 2010 (UTC)

Thanks. (1) I've been told that making it a true namespace would be better in order to make clear that the pages are subject to slightly different policies from the main namespace. I didn't know about searchability; that seems like a nice bonus. Personally, I think a true namespace just makes sense, because sign glosses truly are a different "space of names" from spellings.

As for (2), I don't know enough about the field to give a strong opinion. This book from 2007 says "Note that some of the contributing authors give all glosses in English, irrespective of the sign language, while others decided to gloss sign language examples in the surrounding spoken language (e.g. in German for a German Sign Language example) in order to distinguish sign languages from each other." I would welcome further input, but I hope that discussion doesn't hold up the whole namespace. I think we are likely to start with ASL and BSL on EN Wiktionary, so we do not have to resolve the issue immediately. Bemasc 04:17, 22 July 2010 (UTC)

Thanks for initiating this and bringing it here, Bemasc. I strongly support the creation of such a namespace.

(I don't think Mediawiki namespaces are case-sensitive, but if they are, our naming conventions here would prompt the capitalization as "Sign gloss", with a lower-case "g".)

—Rod (A. Smith) 16:13, 22 July 2010 (UTC)

I second all that Rod said. Like Bemasc, I don't think that indecision over how to name pages for glosses of e.g. Israeli Sign Language should affect the creation of the namespace. Namespace names are case-sensitive: You can type wiKtiOnAry:BP into your browser, but there's a canonical capitalization that you'll be redirected to (I'm guessing via HTTP 3xx).​—msh210℠ (talk) 16:30, 22 July 2010 (UTC)

I don't like ASL entries in the mainspace, as the page title should be identical to the written form. Thus, I support a new namespace. Mglovesfun (talk) 16:33, 22 July 2010 (UTC)

No, I think you're misunderstanding the proposal. It is that SL entries remain with their current titles in mainspace (as voted on, BTW) but that there are redirects to them from this new namespace (or, essentially, disambiguation pages, if one gloss is used for ≥two signs). The new namespace can also be used as a holding area for contributed entries whose proper pagetitles are unknown at the time of contribution.​—msh210℠ (talk) 16:43, 22 July 2010 (UTC)

So far everyone who's written seems to support the creation of a "Sign gloss:" namespace ... so what do I do now? Bemasc 19:07, 27 July 2010 (UTC)

Request at [5] that someone add the namespace, referring, in your request, by URL, to this conversation (as they'll want to see enwikt consensus for the namespace creation).​—msh210℠ (talk) 19:15, 27 July 2010 (UTC)

FYI, y'all, that's now been filed at bugzilla:24570 (not by me).​—msh210℠ (talk) 15:23, 28 July 2010 (UTC)

Request for bot status: User:NadandoBot

I request formal approval to run User:NadandoBot, the purpose of which is to fix broken links in {{form of}} after this edit by Msh210. Code and test edits are on the bot's userpage. I will create a voting page after discussion here. Nadando 00:20, 24 July 2010 (UTC)

While we're changing the template, can we make it have the same parameter structure as {{term}}? Couldn't we get rid of the wikilinked parameter entirely and go from specifying abaisser#French|abaisser|lang=French to just abaisser|lang=French (rather than [[abaisser#French|abaisser]]|lang=French). If the target is different than display_term#language, let's have it be a different parameter. --Bequw → τ 03:10, 24 July 2010 (UTC)

I support this idea; if someone will edit the template, I will modify the bot code to fix it. Nadando 04:30, 24 July 2010 (UTC)

No we can't, because of Wiktionary:Page count. -- Prince Kassad 08:46, 24 July 2010 (UTC)

I think using the {{count page}} template is better than making content templates suboptimal just for the sake of a statistic - indeed reading Wiktionary:Page count it seems that avoiding the need to kludge other templates is one of the reasons it was introduced. I support the change to make it work the same as {{term}}. It would be good if the bot could add the {{count page}} where required as a result of its edits though. Thryduulf (talk) 11:22, 24 July 2010 (UTC)

Yeah, or just leave it for AF, which already adds {{count page}}. --Bequw → τ 11:36, 24 July 2010 (UTC)

Go for it. SemperBlotto 08:51, 24 July 2010 (UTC)

Alright, since there apparently isn't consensus for further changes to form of, and there are currently 30,000 broken links, I've created a voting page. Nadando 16:23, 24 July 2010 (UTC)

Open bot request

I think it's about time that the Swedish templates be brought into line with the rest of our declension and conjugation templates (they currently float to the right) but before I edit the templates to sit on the left, I need someone to move them from their various positions in entries to ====Inflection==== or ====Conjugation==== sections.

Here's the ones I can find that need fixin'. (I think there might be some instances of some that are already under =Inflection= headers, so that's something to watch for)

• Template:sv-adj-reg
• Template:sv-verb-reg-er
• Template:sv-verb-reg-ar
• Template:sv-verb-irreg
• Template:sv-noun-unc-irreg-n
• Template:sv-noun-unc-irreg-c
• Template:sv-noun-reg-r-n
• Template:sv-noun-reg-r-c
• Template:sv-noun-reg-or
• Template:sv-adj-abs
• Template:sv-adj-peri
• Template:sv-noun-c-zero
• Template:sv-noun-n-zero
• Template:sv-noun-irreg-c
• Template:sv-noun-irreg-n
• Template:sv-noun-reg-ar
• Template:sv-noun-reg-er
• Template:sv-noun-reg-n
• Template:sv-noun

— [ R·I·C ] opiaterein — 17:49, 20 July 2010 (UTC)

Support standardising declension tables. Mglovesfun (talk) 20:24, 20 July 2010 (UTC)

These Swedish templates are wild. They encroach upon other language sections. See e.g. this. --Vahag 20:34, 20 July 2010 (UTC)

Please do. I couldn't come up with a fully-automated way of sorting the templates. Sometimes they're not in the PoS section and it's confusing especially when there are several (and sometimes several PoS's in different etymologies). I did it by hand for a while but got burnt out. Maybe we can have a bot tackle the easy ones (where the template is in a PoS already) and then cleanup the rest by hand.--Bequw → τ 21:44, 20 July 2010 (UTC)

Not sure if I can help, but I can try, as my coding skills are 'decent'. While you're at it though, you might want to rethink the naming scheme for the templates as well. The general scheme with lang code, hyphen, then part-of-speech is usually reserved for inflection-line templates (i.e. the ones that show the headword in bold). Conjugation and declension templates are usually named xx-conj and xx-decl. Take a look at [[Category:Dutch declension templates]] and [[Category:Dutch conjugation templates]] to see what I mean. —CodeCat 23:39, 20 July 2010 (UTC)

Missing etymology

Why do we have two different templates that both denote a missing etymology? See, for example, کس, which uses both of them. -- Prince Kassad 20:06, 25 July 2010 (UTC)

I think I noted this as Wiktionary:RFM. Mglovesfun (talk) 20:13, 25 July 2010 (UTC)

A perfect opportunity for me to say that page (ideally) needs more input. A lot of the move requests pass with a 2-0 consensus. Mglovesfun (talk) 11:59, 26 July 2010 (UTC)

Wiktionary:Votes/pl-2010-06/Number vs. numeral

Much as I'd like to forget about it, that's not going to solve anything. I set the vote for 3 weeks, starting July 29. Any questions? If this goes right, we can lay the whole thing to rest. Mglovesfun (talk) 12:36, 26 July 2010 (UTC)

Can we have an option «Use "Numeral" as level 3 headers»? --Vahag 12:49, 26 July 2010 (UTC)

Ah I forgot those, "numeral" and "number" on their own. Yes of course, as people might vote them. Mglovesfun (talk) 12:51, 26 July 2010 (UTC)

Please discuss at Wiktionary talk:Votes/pl-2010-06/Number vs. numeral. Mglovesfun (talk) 13:02, 26 July 2010 (UTC)

Idea: Best terms that don't exist

Browsing through RFV, I can't help but notice that while a lot of terms fail verification, the terms themselves are sometimes quite brilliant. I often think 'if these don't exist, they certainly should!'. So for the purposes of posterity and humour, I propose that we keep the best entries that fail verification in a list of some sort. —CodeCat 09:46, 27 July 2010 (UTC)

• We already have Wiktionary:Bad jokes and other deleted nonsense. SemperBlotto 09:48, 27 July 2010 (UTC)

I know, but the difference here is that the idea I'm proposing would contain terms that are actually useful in a certain setting. I.e. they are not 'nonsense', just 'unattested'. —CodeCat 09:59, 27 July 2010 (UTC)

Isn't that what Wiktionary:List of protologisms is for? Thryduulf (talk)

Yep. Equinox ◑ 12:35, 27 July 2010 (UTC)

The term "best" is an indication that this might be a matter of personal taste. It would seem best to have one's personal list of favorites on a user page and perhaps put the empty page on one's watchlist to monitor any interest expressed by others. DCDuring TALK 14:32, 27 July 2010 (UTC)

MediaWiki talk:Common.css#Non-gloss definitions

What does everyone think of this? I am reconsidering whether it's worth it, but more input would be good. —Internoob (Disc•Cont) 01:37, 28 July 2010 (UTC)