Wiktionary:Beer parlour/2008/February

February 2008

Is Wiktionary A Legitimate Source

The question of whether Wiktionary is a legitimate source to be used at Wikipedia has come up for the first sentence of the article pornography. The discussion was occurring HERE. It is has been moved here: HERE. Input is being sought, please participate. WritersCramp 14:29, 2 February 2008 (UTC)

Adding New Standard Headers

How would one go about adding new standard headers? This is specifically in regards to Aramaic. Aramaic is written in two main scripts (Syriac and Hebrew) like how Serbian is written in both the Cyrillic and Latin scripts. In Serbian entries, sometimes headers provide a link to the same word in the other script (with the header "Latin/Roman spelling" or "Cyrillic spelling"). Using the headers "Syriac spelling" and "Hebrew spelling", though, the AutoFormat bot flags it as a non-standard header. See ܟܠܒܐ (Syriac spelling) and כלבא (Hebrew spelling) for an example. --334a 17:23, 2 February 2008 (UTC)

I'm afraid the simplest option is to choose one script and to make the other "alternate form"-type entries. Circeus 17:30, 2 February 2008 (UTC)

How about putting it under ==Alternative spellings==? I've used that for Old Church Slavonic, which was written approx. half if Glagolitic, half in Cyrillic script (cf. ⰍⰓⰟⰊ (KRY) and кръі (krŭi)). Yes, it's very bad to have duplicate content, but favoring any script is unfortunately not an option. This comes especially bad in Sanskrit, which can be written in something like 10 different scripts :/ I wish there were some way to transclude content.. --Ivan Štambuk 18:08, 2 February 2008 (UTC)

Yes, there is no reason why both entries can't have full forms. You may also want to make a clarification, such as (Hebrew spelling), to show that this is not a variant, but rather a counterpart in a different script. The argument that Serbian requires a different format has never swayed me. Atelaes 18:16, 2 February 2008 (UTC)

Like Atelaes said, using "alternative spellings" doesn't distinguish between spelling variants in the same script and variants in a different script (see this article for an example of the "alternative spellings" being used for spelling variances in the same script). So why does Serbian warrant its own headers but Aramaic doesn't? Is there absolutely no way to add more standard headers? --334a 02:28, 3 February 2008 (UTC)

Well, first of all, my point was that I don't think Serbian should actually have those headers. Second, I think that entries under the "Alternative spellings" header can be specified by a parenthetical specification, which could look like this:

===Alternative spellings===

• xxx (Syriac counterpart)
• xxx
• xxx

Where the second and third entries are alternative spellings in the conventional sense, but the first the script counterpart. Another option which may work well is to specify it in the POS line:רישא (m) Syriac: xxx. Atelaes 06:43, 3 February 2008 (UTC)

I see what you mean now. That actually would work well to save space (by not making an entire header for a single link). Is it standard to list the alternative spellings in point-form like that, though? Also, are the "Latin/Roman spelling" and "Cyrillic spelling" headers for Serbian still going to be used? It seems a little sloppy that different languages use different methods for the same alternative script problem. --334a 16:51, 3 February 2008 (UTC)

Yes, just list them "point-form" like one by one, as the very first thing, as specified by WT:ELE. Similar situation occurs with "Urdu spelling" and "Devanagari spelling" used for Hindi/Urdu, where there is also duplication of content (cf. पर (par) - "Urdu spelling" repeated 4 times for 4 different etymologies, with the same content every time). I'm not sure how much sense does it really make to cross-link different languages like that (if some Hindi nationalist happens to come across all of those Persian/Arabic loanwords mediated via Urdu, I don't think he'll be too happy with them ^_^). --Ivan Štambuk 17:09, 3 February 2008 (UTC)

I think I'll do that from now on. I forgot to mention one thing though: Aramaic nouns have different "states" (emphatic, construct, and absolute) which kind of work like a Semitic case system. In the different states, words have different spellings. So far I've only created articles in the emphatic ("full") state. If I made articles in other states, how would I link them up? An example of this is אב and אבא: same word, different states. I was thinking I could do something like a conjugation/declension table like for Latin or Greek. I think I saw a Hebrew entry with a construct/absolute table, but I don't remember where. --334a 17:45, 3 February 2008 (UTC)

I think an inflection table would be excellent. By the way, could I please make a request of you. While you're creating Aramaic entries, when you happen to create one on a pre-existing Hebrew entry (I have no idea how often that would happen), would you please give the Hebrew the most basic of formatting (proper L2, proper cat., etc.)? A lot of our Hebrew section is a terrible mess right now. Thanks. Atelaes 19:39, 3 February 2008 (UTC)

Yes, that's fine. I'll try to clean any Hebrew entries I see along the way. --334a 20:54, 3 February 2008 (UTC)

Generally, there are no real guidelines on how to solve the problem of languages expressing more delicate semantic variations of a base meaning in various lemma forms; sometimes contributors just copy content and "adapt" translations (cf. Russian издаваться (izdavatʹsja) and издавать (izdavatʹ) for the reflexive vs. irreflexive infinitive of Russian), sometimes they just ignore variations in semantics and just copy/paste translations (cf. Russian ржать (ržatʹ) and заржать (zaržatʹ) - perfective vs. imperfective aspect), and sometimes, like I've mentioned, contributors find the content duplication unacceptable and just point back (cf. Spanish lavarse). So you can do whatever you like, copying original translation, placing a "emphatic version of"-like message, or adapting the translation. --Ivan Štambuk 20:01, 3 February 2008 (UTC)

I agree that this issue has to be resolved. Serbian does not have a special format. The reason why Aramaic was flagged by the bot and Serbian was not is because this format had been flagged by the bot for Serbian in the past, but it has been decided to leave it as such until an agreement has been reached for the heading. The Serbian entries are simply exempt from the bot's parameters. The issue of the heading has not been resolved. In the past we have thought about using "Alternative spellings" header, but as mentioned that header seems to be designed primarily for English entries to provide for the minor differences in British and American English. It does not distinguish between a same spelling in another scrpit from a minor spelling difference in the same script. I strongly discourage the use of "Alternative spellings" for anything other than its intended use for spelling differences in the same script. I would advise that we come up with a new heading and new rules for languages that are officially written in more than one script.

I must say that we are not here to please any nationalists, Ivan. Please do explain what are those differences (except for the standard scripts) between Hindi and Urdu that you mention so boldly. --Dijan 23:25, 3 February 2008 (UTC)

Well Dijan, I've seen you already heavily putting "Alternative spellings" on some BCS entries when they are pronounced differently, in e.g. halhala, juni, kismet, minut, abdest, aždaja... you already pretty much invalidated there what you claim to be the original purpose of AS section ("minor differences in British and American English"). Your AS's are much more different than -ism/-izm, -or/-our etc. because there is phonemic distinction between those omitted/changed characters of 'minut' and 'minuta', 'abdest' and 'avdest' etc. They're pronunced differently, have different gender and declensional paradigm...I'd rather call them synonyms than "alternative spellings" ;)

For such such differences I usualy practiced using "Alternative forms" section. But I do generally agree, that mixing different scripts and alternative forms of the same script (quite common for times where no orthography existed) in the same header is bad, and should have been solved more elegantly. Maybe an "Alternative scripts" header for the same lexeme in different scripts, "Alternative spellings" for minor orthography variations (but still pronounced (almost) the same), and "Alternative forms" for everything else? That would clutter ever more the amount of content displayed before the definitions (the most important thing), which someone might find distracting, but at least would remove to redundancy of specific POS sections repeating "xxx spelling".

I have no desire to advocate difference (or equality ;) between Hindi/Urdu, but some might (like that great Serb for amidžinca etc.), and they would pretty much have every right to ask for second-grade status of sanskritized Hindi lexemes suddenly becoming "Urdu", or vice versa for Persian/Arabic borrowings introduced for difference purposes into Urdu, pointing back to Devanagari spelling in Hindi. Languages are defined in their vocabulary, no by their grammar. Cross-linking different languages is a practice that should be reserved only for prose discussions in Etymology sections, Usage notes and similar. --Ivan Štambuk 11:10, 4 February 2008 (UTC)

Thank you for pointing out my use of Alternative spellings on halhala and such. The reason for that is that I was not well aware of the usage of "Alternative forms" and if you do come across such "mistakes", please do correct them to what they should be. I do make mistakes. I did not say that I was perfect. :) As for Hindi and Urdu, you might be a little misinformed about them. Sanskritized lexemes of Hindi that I've added as Urdu have not "suddenly" become Urdu nor did Arabicized/Persianized lexemes become "suddenly" Hindi. Please be careful when making such accusations. Pick up a "good" Hindustani (Hindi / Urdu) dictionary and look them up. Yes, every user has a right to second guess terms and definitions here. However, I would not agree with some crazed purist claiming that terms derived from Sanskrit are not at all Urdu. The same applies to a Serb claiming that any Muslim terms are not Serbian. I'm sorry, but there are Serbs that are Muslims and if you do not agree, you are being as ignorant as every other nationalist. --Dijan 13:50, 4 February 2008 (UTC)

The real-world usage of a word only partially reflects it's status in a language. Purists do define what's the standard language (i.e. the one spoken on TV, learned by foreigners..), not the vulgus, or romantic unifiers who would like to erase the state borders. Serb Muslims can speak Ottoman Turkish if they want to, and that's just not standard Serbian. I sincerely doubt that the status of newly acquired Persian/Arabic loanwords in Urdu is the same as in Hindi, but as I said - that's not my problem anyway, but it might be of a problem if some proud Hindu starts asking questions, why does every single Hindu word have "Urdu spelling" at the bottom. We don't have ISO code for language called "Hindustani" which is standardized on two different scripts, but two languages with two different ISO codes. From w:Hindustani language:

While, at the spoken level, Urdu and Hindi are considered dialects of a single language (or diasystem), they differ vastly in literary and formal vocabulary; where literary Urdu draws heavily on Persian and Arabic, literary Hindi draws heavily on Sanskrit and to a lesser extent Prakrit. The grammar and base vocabulary (most pronouns, verbs, adpositions, etc.) of both Urdu and Hindi, however, are the same and derive from a Prakritic base.

So they're not so the same...smells heavily like "Serbo-Croatian" business ;) --Ivan Štambuk 14:41, 4 February 2008 (UTC)

Again, you are mistaken, because only the terms common to both languages have that kind of note. I have not maked any "newly acquired" Persianized/Arabicized term of Urdu as Hindi. Most terms I include are terms common to both languages, not only to Urdu. There are certain terms that I've included that are specifically Hindi-only (due to the newly Sanskritized terms). If Sanskritized terms are used in literary Urdu, only then have I included them and their Hindi spelling. "The grammar and base vocabulary (most pronouns, verbs, adpositions, etc.) of both Urdu and Hindi, however, are the same and derive from a Prakritic base." - You have quoted this yourself. No, every single Hindi (not Hindu) word does not have an Urdu spelling. Many do, yes. But like I said, this is only for the common terms. This is a totally different conversation that can be never ending. You're not familiar with the languages so please let it go. --Dijan 17:05, 4 February 2008 (UTC)

Yes, I'm not familiar, and that's the reason I don't want to push it in individual cases. But when the issue arises (and with these newly-born Ausbau languages it sooner or later will), I just hope you won't be using the same argumentation as with Turkish loanwords into Serbian. Anyway, the problem discussed here are not Urdu/Hindi, but superfluous sections, inherently POS-agnostic (and Etymology-agnostic too!), that both introduce needless redundancy and confuse editors. It would be just horrible for Sanskrit lexemes to put something like 10 sections "Telugu spelling", "Bengali spelling", "Gujarati spelling"... Similar situation occurs with Romanian/Moldavian, where Opiaterein appears to have handled the problem inside the POS-specific template (cf. кынтэрец (kynterec)). For different languages the most natural solution would be to list them in Etymology sections, mentioning the other one as a cognate, and for the same "base" form variations of the same language, mentioning the other ones inside POS-specific template. I.e., in something like arc-noun, adding parameters such as emph=, cons=, abs= that would mutually interlink them. --Ivan Štambuk 21:12, 4 February 2008 (UTC)

I do like Opiaterein's solution. That could be modified to be used in Serbian and Aramaic. --Dijan 00:34, 5 February 2008 (UTC)

I concur. Opiaterein's solution is the way to go. Atelaes 00:42, 5 February 2008 (UTC)

Index:Hungarian/a

How can I move the Table of Contents to the right side of the page in the updated Index:Hungarian/a to make it look like Index:English/a? Thanks. --Panda10 13:55, 3 February 2008 (UTC)

Add {{tocright}} to the top of the page. Actually, it might be easier to add that to {{index/Hungarian}} and put that on the top of each page. Conrad.Irwin 14:11, 3 February 2008 (UTC)

Thanks! --Panda10 14:16, 3 February 2008 (UTC)

Maintaining the Index

Do you keep the English and FL index pages up to date manually or automatically? I've just created the Index:Hungarian, but I can easily see that this is an endless work and never accurate if it's done manually. One could use the time for better things, e.g. adding new entries, translations. Who is using the index? Is it useful at all? I am asking for your help and direction. It is a lot of work to add words manually to the index. Could the index be regenerated every time a dump is created? Thanks. --Panda10 21:37, 3 February 2008 (UTC)

The index is not terribly useful, however it can be interesting to look at, The index could be regenerated every dump, a clever bot (i.e. one that knew what order to sort things - instead of relying on the borked Unicode ordering) could do it fairly trivially. I have been thinking a lot about getting a bot (any bot) working, but something else always comes up first... Conrad.Irwin 22:02, 3 February 2008 (UTC)

That would be great even if the sort order is not perfect. For example, whe you created User:Panda10/Hungarian, the letters á é í ó ö ú ü ő were at the end of the list instead of their appropriate place in the alphabet, but in the case of Index, each letter has its own page. It may be that even within a single page (e.g. page for Letter A) the sort order will not be as expected, but I don't see this as a huge issue. If I can be of any help in this effort, please let me know. --Panda10 22:15, 3 February 2008 (UTC)

The Unicode standard makes it pretty easy to decompose diacritics out of letters, so it's not too hard in most programming languages (eg python). Then you just have to standardize case for dictionary sorting. This could be extended to most languages that have an alphabet based on the latin one. Some considerations have to be taken per language (eg in Spanish 'ñ' is a different letter and sorted independently from 'n' so that mark shouldn't be removed). If we settle on a way for including lang-specific concerns, the same bot (or dump analyzer) could generate the indexes for several languages at the same time.--Bequw → ¢ • τ 16:09, 4 February 2008 (UTC)

I have been having fun in my current favourite language (perl) and it seems that this is reasonably easy to do - it certainly managed to cope with Greek (see User:Atelaes/AGr ) and the Urdu I ran it on looked right to me (RtoL) but I tried to add some features and it is currently badly borked. I am hoping to extend it so that I wrap the default Unicode::Collate sorter in language specific sub routines, so that I can treat characters like sz in Hungarian (Panda10?) and the ñ in Spanish, but I am hoping that there will be as little of that to do as possible.

The next thing I move onto thinking about it the format for the indices. I have decided that the current one column approach looks ugly, and that I prefer the ToC style that I stole from Panda10, along the top of multiple columns - See User:Conrad.Irwin/test (This has been edited by Atelaes to do the bits that will hopefully be programmed in later). Any thoughts about this? Conrad.Irwin 19:28, 4 February 2008 (UTC)

You might want to extract the language-specific lexicographical ordering using the subtemplates of Template:index --Ivan Štambuk 21:20, 4 February 2008 (UTC)

I've found a couple of websites where the Hungarian sorting rules are described for a bug report submitted to MySQL: [1] and with some pearl [2]. I like the multi-column arrangement (I've seen it earlier, it's no longer there), but I also like the other format with no columns at all, words listed next to each other, but separated by a TOC. It all depends how we want to use the Index. Would it be easy to add other statistics, for example number of words in each letter or total words on the top of the page? --Panda10 21:55, 4 February 2008 (UTC)

hi/hai

which is correct?hi or hai?— This unsigned comment was added by Sahaana (talk • contribs) at 15:58, 4 February 2008.

Both are words, so which is correct depends on context. See the entries for hi and hai for details. I hope that this is helpful. In the future, questions such as this belong at WT:ID.—msh210℠ 17:42, 4 February 2008 (UTC)

Semantic relations: user-friendly names

In working on the entries for ZIP Code and variants and postal code, I have finally found some use to semantic relations other than synonymy and antonymy (hypernymy and hyponymy, in those cases). Unfortunately, the headings seem completely unsatisfactory from the point of view of a non-expert user of Wiktionary. Most users would know "synonym", fewer would know "antonym"; almost none would know the other "nyms" (meronymy, holonomy, hypernymy, hyponymy, troponymy) or even "coordinate terms". The recommended format would make these headers. Then, even putting in a link would require breaking the proscription (?) against links in headers. Can these be renamed ? Any thoughts ? DCDuring TALK 20:57, 4 February 2008 (UTC)

I think most people (stateside at least) learn the word "antonym" in grade school and know it. Just my impression.—msh210℠ 21:33, 4 February 2008 (UTC)

It was the ones beyond that which trouble me. "meronymy"? I took three years of Greek and couldn't get those at first three glances. I have a similar problem with "plurale tantum" et al. from the point of view of our users. DCDuring TALK 23:32, 4 February 2008 (UTC)

Wikipedia proscribes header links, but we don't. (Some editors think we should, and they've made some good arguments, but as yet they haven't changed common practice for acronyms and initialisms, at least.) —Ruakh_TALK 01:23, 5 February 2008 (UTC)

If not linking, could we have a template that added a tooltip to some of these terms? --Bequw → ¢ • τ 13:34, 5 February 2008 (UTC)

Another option is to explain it in a collapsible table heading, much like "Terms derived from page name" which is reasonably common despite being more obvious. For instance, instead of just each definition's gloss, translations could be titled with "gloss of definition in other languages". DAVilla 11:12, 7 February 2008 (UTC)

What would the gloss for "meronym" be? DCDuring TALK 12:01, 7 February 2008 (UTC)

The gloss for the translations of meronym would be "part of whole". I've added a translations section to meronym to illustrate that. But I think you meant what the table heading for meronyms would be, which is "part or member of gloss of definition", as I've illustrated on iron. DAVilla 01:15, 10 February 2008 (UTC)

Your edits on iron fully address the question that I had. However, having looked at the entry for iron, I'm pretty sure that full illustration of such semantic relations is not something desirable with the current presentation design or software capability. I am also 100% convinced (only facts could sway me) that the terms themselves would serve to scare away the broad population of users. As a result I will not attempt to make use of the terms in trying to structure the relationships among the various postcode/ZIP code/postal code entries, no matter how accurately they might characterize the relationships. I don't think we have any evidence that supports the idea that links would dramatically change the negative impact on casual users of using such words. I am not surprised that they do not have wide use here or in other dictionaries for lay users. I am surprised that the terms made it into ELE. DCDuring TALK 04:07, 10 February 2008 (UTC)

I think linking is a good idea, if we're to have these headers. (Otoh, I haven't seen the arguments against linking headers.)—msh210℠ 17:50, 5 February 2008 (UTC)

Category:Autonomous Oblasts of the Soviet Union

I think we need to talk about this. -- Visviva 11:40, 5 February 2008 (UTC)

Just like Category:Provinces of Italy, Category:Provinces of Canada, Category:States of India or those others in Category:Political subdivisions. The pages all existed before, i just put them together in category so they were not uncategorized anymore. Currently trying to get Special:Uncategorizedpages smaller. Mutante 11:47, 5 February 2008 (UTC)

I should maybe clarify that my concern is not with the category itself, but with its contents. (I guess you weren't involved with that; sorry for the misunderstanding.) Particularly with the fact that these are all formal official names; to me this seems more like having an entry for City of Chicago than having one for Chicago. NB, one of these did pass RFD previously, but it did not receive much attention at the time. So I'm wondering ...

1. Are we comfortable with having this kind of material in Wiktionary mainspace?

2. Is there any reason to think that anyone, anywhere, will ever want to look these terms up in a dictionary? -- Visviva 12:43, 5 February 2008 (UTC)

1. Personally it would not make me uncomfortable.

2. Somebody writing an article about the history of the Soviet Union?

But yes, i did not create those pages, just the Category itself to group them together. Mutante 12:46, 5 February 2008 (UTC)

But why wouldn't they use an encyclopedia instead? Wikipedia articles typically provide some information on pronunciation and name origins anyway; what else can we plausibly hope to add? -- Visviva 10:32, 6 February 2008 (UTC)

Per the Chicago analogy, we should have single Oblast names such as Chuvash and Oyrot. The larger versions are, however, the official names of the places. bd2412 T 10:37, 6 February 2008 (UTC)

They are, which to my mind makes them inappropriate for us. Whether we should or should not have an entry for Microsoft may be in dispute, but I don't think anyone would support having an entry for Microsoft Corporation or Nintendo Co., Ltd. Regarding Chuvash, Oyrot et al., we definitely should have them, since they are ethnonyms in most if not all cases; perhaps a link from the ethnonym entry to the pedia article for the relevant oblast would be sufficient? -- Visviva 15:18, 6 February 2008 (UTC)

English truncations

Are we supposed to have entries for English truncations with or without periods (fullstops), or both? I mean, misc, misc., or both? (I'm not asking specifically about things like Mr, which are also a pondian issue.) Seems to me people will look up both forms.—msh210℠ 17:48, 5 February 2008 (UTC)

{{Abbreviation}}. Circeus 15:13, 6 February 2008 (UTC)

I don't understand this response.—msh210℠ 21:05, 6 February 2008 (UTC)

I think this is a good case for redirection. Having separate entries at "Foo" and "Foo." is inevitably going to lead to confusion, and things will get added to one that should probably be added to the other; in consequence users will have an unnecessarily difficult time finding what they need. I suggest that we should have a general policy of redirecting all word forms ending with a period to their period-free variant; we can then provide usage notes concerning which uses are always, sometimes, or never accompanied by a period.-- Visviva 15:14, 6 February 2008 (UTC)

I agree with Visiva that redirects are a good idea, redirecting from the "." means that there is less chance more than one term would exist, and eliminating the need for soft-redirects. Conrad.Irwin 15:31, 6 February 2008 (UTC)

Sounds good to me.—msh210℠ 21:05, 6 February 2008 (UTC)

Excellent point. —Ruakh_TALK 00:51, 7 February 2008 (UTC)

What about U.S., US, and U.S? DAVilla 11:00, 7 February 2008 (UTC)

I think there may be a case for allowing titles with periods for alphabetisms (although it seems like U.S. would be better served by a redirect). That's a subtly different issue than raised by msh210. -- Visviva 11:20, 7 February 2008 (UTC)

Ambiguous etymologies

So what do you do when a word has an etymology that can be expressed in two or more ways? For example, a modern English word which can be traced historically from Latin through Old French to Middle English and modern English, but which can also be described as a direct combination of a Latinate root and suffix in modern English... Or a modern Korean hanja-based word which can be considered either directly composed of its parts, or descended from the Middle Korean version... What is the optimal approach? There is no real issue of right or wrong in most cases. I'm thinking that the etymology should be presented in both ways (compositionally and historically), but have not yet found a simple and user-friendly way of doing so. Anyone found a good solution to this? -- Visviva 15:38, 6 February 2008 (UTC)

Specifically, for English I'm thinking of cases like topography, simulation, and so forth. -- Visviva 15:56, 6 February 2008 (UTC)

You can provide etymology expressing

1. morphology (xx-form-of, compound of x+y, etc.)
2. semantics ({{diminutive of}}, {{reflexive of}} and alike; deverbative, dedjectival, denominal PoS...) - those end up in most cases in definition lines because editors don't want to duplicate maintance effort, of modify existing definitions. Usually semantics is implicit in morphological derivations, so whenever you use e.g. {{simple past of}} in definition line you're just being lazy providing the real definition, but instead rely on the assumption that reader knows how to the derive the meaning of {PAGENAME} from the linked lemma.
3. inheritance - inherited, borrowed, coined..

You can even have etymology section expressing all 3 relationships. Inheritance from ancestor language should generally have precedence, and compositionality (usual morphology or "sum of parts") should be discussed at the earlist point the term was coined/used, in whatever language. Otherwise you're going to end up combining terms diachronically or across language boundaries, saying for example that topography = Ancient Greek τόπος (tópos) + -graphy --Ivan Štambuk 17:24, 6 February 2008 (UTC)

Ivan seems to say it all. However, a morphological etymology, even one violating linguistic principals, is an improvement over no etymology unless it is points to words not at all related to the entry etymologically. We certainly don't want to have complex full etymologies at every entry ending in "-isation" and "-ly". DCDuring TALK 17:46, 6 February 2008 (UTC)

I also like glosses in the etymologies that indicate waystations in the evolution of the meaning of words. This is not a substitute for a full set of entries for Old French, Middle French, Middle English, OHG, etc. with all the polysemy, but helpful. DCDuring TALK 18:02, 6 February 2008 (UTC)

I believe I agree with everything said thus far. My primary aim in writing etymologies is twofold: To track the word through time, and to find out what it is composed of. A simple "From grc xxx + xxx" is acceptable, in that it's certainly not incorrect and distinctly better than nothing. But an etymology which tracks the word through multiple languages and incarnations is distinctly superior. Atelaes 18:18, 6 February 2008 (UTC)

I worked up topography a bit, to give a feel for how I like to do things. It might be useful if we treat these two words as case studies and work on them til we're all satisfied. That will give us a much more concrete view of things. Atelaes 19:01, 6 February 2008 (UTC)

Ok, they're both done as well as I can do them. Please take a look and modify, expand, whatever. One thing of note, the first attestation dates are.....well....wrong. I'm just going off the date which all the sources offer. However, I don't think that they're distinguishing spellings as we are (I wonder exactly what they're distinguishing sometimes). At least going off of the OED cites, the specific spelling (for both words) was not attested til later. Sadly, at this point, we just don't have the corpus searching powers that the OED has, and so a better first attestation date will probably have to wait til Wiktionary evolves a bit. Atelaes 00:39, 7 February 2008 (UTC)

From the point of view of completeness, one might wonder whether the millennium between the Latin and the Middle English didn't have some intermediate form(s) in Old French, Anglo-Norman, Middle French, Medieval Latin. Or did an English classicist get it directly from a Latin work? And when did it pick up the meaning of not just a description of features, but the features themselves? I'm not sure that there is any specific value from knowing that from the point of view of Modern English, but there might be some value for interpreting readings that use the word and its ancestors over the centuries. DCDuring TALK 01:06, 7 February 2008 (UTC)

An excellent point. However, the sad fact is that most etymological sources are silent on this issue, and we don't have anyone specializing in early Romance languages. So, it'll just have to remain incomplete for the time-being. Atelaes 01:09, 7 February 2008 (UTC)

It seems that one w:Gerald of Wales (1146-1223) wrote in Latin a Topographia Hibernica (1188) and that the spelling "typographye" appears in w:John Trevisa's 1387 translation into ME of the Polychronicon of w:Ranulf Higdon (1280-1363) that referenced the Topographia. That would make it seem plausible that the word came from English monks who knew their Latin well. DCDuring TALK 01:52, 7 February 2008 (UTC)

This is some very impressive work. Thanks! -- Visviva 16:31, 7 February 2008 (UTC)

But I couldn't also say that topography is composed of topo- +‎ -graphy, or that simulation is simulate +‎ -ion? That seems oddly unhelpful, although perhaps listing this information under "Related terms" would be sufficient. -- Visviva 01:56, 7 February 2008 (UTC)

No. The reason is that typography wasn't put together in English from English suffixes and prefixes. So, for example, telescope is not telo- and -scope, because it was handed down to us as a complete word. On the other hand, we created periscope in English (although it was admittedly modeled after a German word), and so the etymology should be from peri- + -scope. Atelaes 03:14, 7 February 2008 (UTC)

This bothers me. By this logic, smoothness#Etymology should simply say "From Middle English smothenesse, from smothe + -nesse." That's useful information, but it is also useful and relevant to note that smoothness is composed of smooth + -ness in modern English. -- Visviva 11:23, 7 February 2008 (UTC)

You're on to something. Because we don't necessarily have good entries for all the words we cite in our etymologies from Middle English, Anglo-Saxon, Old and Middle French, Old Norse, Late Latin, Anglo-Norman, MHG, OLG, Old Dutch etc. we can have redlinks in our etymologies. In those cases especially, a morphological etymology that got you to smooth would be useful, because it has a good etymology. Any link in the entry that got you to smooth would be good, but perhaps we need to make sure that there is one in the etymology as well as in one of the senses or in related terms. We just needs links to entries with "good" etymologies. If we don't have blue links of good quality in our historical etymology, then perhaps we should consider the morphological "etymology" "mandatory". DCDuring TALK 11:49, 7 February 2008 (UTC)

In the case of smoothness, the morphological etymology tells us less than the vacuous sense line. That it gets us back to an Anglo-Saxon word at smooth suggests that we have a fairly irreducible atom of meaning. Putting in some etymology (even conjectural) beyond that might be useful if illuminating cognates in other modern languages are not obvious. DCDuring TALK 11:57, 7 February 2008 (UTC)

The solution I have used is to say "corresponding to" smooth + -ness, and leave the Middle English elements on the smoothenesse page. Widsith 17:02, 7 February 2008 (UTC)

• What do people think about separating the different aspects of etymology/morphology with bullet points? I don't really like this, as I like to think of the Etymology section as the last refuge of coherent text on Wiktionary. But we use bullets and numbers in every other section, after all. So we could have something like:

• Composition: Template:en-term + Template:en-term
• From Middle English smothenesse, from smothe + -nesse.

This allows the two kinds of information to coexist without stepping on each other (which was my problem before). -- Visviva 16:31, 7 February 2008 (UTC)

My only concern is that it will sometimes lead to an additional line above the inflection line, further exacerbating the undesirable squandering of such space forcing casual users to hit page-down, which I posit as having a negative impact on their Wiktionary experience. It is fully analogous to the problems of long ToCs, Pronunciation sections, and even Alternative spellings sections. Perhaps we need additional namespaces for Etymologies and Pronunciations to address that part of the initial-screen-space issue. DCDuring TALK 16:49, 7 February 2008 (UTC)

No, we can't do that. This isn't about presentation, it's about accuracy. Either smoothness was made from smothenesse, or it was made from smooth + -ness. It can't be both. An etymology is about the word's history, it's origins, not a morphological analysis. It might be useful to include glosses on the red-linked words and it may be useful to cite cognates, but if the word did not come from smooth and -ness, please don't lie and say it did. And please DCDuring, no conjecturing. If you can't find an etymology (or a certain part of an etymology) in a respected reference, leave it blank. We don't do original research here. I realize it's frustrating to have a less than perfect etymology, but we're going to have those from time to time, because some words are simply mysterious. Atelaes 18:11, 7 February 2008 (UTC)

I agree completely. We can, though, write "From {{ME.}} smothenesse (“smoothness”), from smothe (“smooth”) + -nesse (“-ness”)", if it's correct. And, of course, the headword can be written as smoothness. These will show the user the split into morphemes sufficiently, I think.—msh210℠ 18:35, 7 February 2008 (UTC)

It certainly must be about presentation. We won't have the chance to survive long enough to make "accurate" etymologies if we don't provide our current users and the vastly larger population of potential users with information that they want or that helps them in a form that is user-friendly. We have an awful lot of clean-up to do to get rid of all the etymologies that violate the policy that you seem to be promulgating. I have mostly learned by example due to the absence of policy and documentation. Are you saying that morphological etymologies are bad? DCDuring TALK 18:36, 7 February 2008 (UTC)

I would suggest something similar to Widsith and msh210. Namely, we say something like "From ME. smothenesse, from smothe + nesse; see smooth and -ness." (or "related to" or "equivalent to" or whatever, but I like "see") I don't like the -ness ("-ness") thing because it conflates translation and cognate. It'd be like transcribing τόπος as "place"; not strictly the same thing, you understand, but I hope it illustrates my point. They are separate beasts. --Wytukaze 03:55, 8 February 2008 (UTC)

Good grief! It's not lying; it's entirely accurate to say that "smoothness" is composed of "smooth" and "ness" just as "blahness" is composed of "blah" and "-ness" and "uppitiness" is composed of "uppity" and "ness" (to name two words that I'm fairly sure were coined in their modern forms). There may be a historical distinction, but there is no morphological one. I don't think it's reasonable to exclude this information from the entry, or hide it in the inflection line where only regulars will understand that the blue link indicates something unusual. -- Visviva 06:16, 9 February 2008 (UTC)

This is a delayed response, some two months later, but I'm responding now because Visviva, further down on the page s.v. #Placement_of_terms_consisting_of_multiple_words, noted that this section "seemed to reach the... conclusion" that morphological analysis should be given in etymology sections even though the word is actually derived form an older version of the same word, and was not composed of its parts. I maintain that smoothness is (assuming that it's derived from an earlier form) not also derived from smooth and -ness. (Here's an argument: If it were, then half the people would say smoothity instead, since you can tack on -ity just as easily as -ness, and they have the same meaning.) No, uppitiness may well be derived from uppity and -ness, but not so for smoothness. See comments of Atelaes 18:11, 7 February 2008 (UTC), above.—msh210℠ 17:53, 9 April 2008 (UTC)

This is a valid concern, but needs to be kept in perspective; the basic morphology for most words adds only one line of text. In comparison, an "Alternative spellings" section with one item adds five or six lines of dead space, and the TOC frequently takes up more than a screenful. As our layout problems go, I don't think this is very serious... also, morphological information frequently helps to clarify the definition and arguably deserves a measure of prominence. -- Visviva 06:16, 9 February 2008 (UTC)

Ok, I have an idea. Take a look at the etymology I wrote for overshadow. This presents us with a problem similar to smoothness. I think that the way I wrote it takes care of both of our interests here. Perhaps the gloss of sceadwian could be switched to "shadow". I wouldn't have a problem with that (although Widsith should be contacted about that, as the entry only says "shade"). What does everyone think? Atelaes 05:41, 8 February 2008 (UTC)

That looks great, but it's a bit of a different case. If the word "overshadow" did not already exist, it is difficult to imagine anyone coining it with its current meaning. That is, it is not really composed of over- + shadow. On the other hand, "smoothness" and "simulation" really are sum of parts in modern English, as is borne out for example by the way that new meanings acquired by smooth (e.g. "suave") are automatically transferred to "smoothness." This information needs to be included somewhere in the entry, and preferably in a way that is transparent to both humans and bots. Even though it may not be strictly etymological, I don't see any better place for this information to go than under ===Etymology===, segregated somehow from the true/historical etymology. -- Visviva 06:16, 9 February 2008 (UTC)

Ah, I finally see your point (sorry it took so long). I suppose that, in a way, smoothness does not derive from smothenesse at all, but is constantly derived from smooth and -ness (in whatever forms they take). And yet, there is a connection between smoothness and smothenesse. That's a tough one. I suppose the best route to take on that is to say "From smooth + -ness. Earlier variants include smothenesse, etc." Atelaes 06:59, 9 February 2008 (UTC)

Whew! I was starting to think I'd finally gone round the bend. Glad I finally managed to articulate what was bugging me. Your proposal makes a lot of sense, and I can't think of any case where that approach wouldn't be satisfactory. -- Visviva 08:00, 9 February 2008 (UTC)

This seems OK to me too. (This is one of the many reasons I dislike Middle English being in etymologies, since it's much more helpful to treat the ME forms as obsolete Alternative Spellings.) Widsith 08:08, 9 February 2008 (UTC)

Derived terms of foreign origin

• Sorry to keep belaboring this, but I'm finding it difficult to apply Atelaes' excellent solution (above) to cases such as simulation, where the putative etymon is a loanword rather than a direct ancestor. Consider scandalous, which I just came across. It is surely accurate to say, as the entry did, that this is from Template:en-term + Template:en-term. But it would not be right to describe the French and Latin versions as "earlier variants"; and I can't think of any explanation that would not be unnecessarily wordy. I fell back on the bullet-point approach here, as it seemed like the least-bad option; your mileage may vary. -- Visviva 12:28, 11 February 2008 (UTC)

Thought: if having this in the etymology is considered intolerable, another option would be to put this information in the inflection line, i.e. "{{en-adj|pos=[[scandal]] + [[-ous]]}}." I'm afraid some people might consider that template abuse, though. -- Visviva 12:34, 11 February 2008 (UTC)

If having this in the etymology is considered intolerable, what's wrong with {{en-adj|pos=[[scandal]][[-ous|ous]]}}?—msh210℠ 17:57, 9 April 2008 (UTC)

Perhaps where the etymology isn't simply English word (e.g. scandal) + English suffix (e.g. -ous), it would make sense to include these in the See also section? Thryduulf 18:39, 9 April 2008 (UTC)

??

This will not come up on my computer. Why?

You don't see the question marks? -- Visviva 11:26, 7 February 2008 (UTC)

Lack of {{unblock}} or other recourse

I'm not a regular contributor to this project, I bear no pretension of knowing all wiktionary policies and my post is not an attempt to spit in anyone's soup. Earlier today I was alerted to a block precipitated by aninnocuous mistake foolishly committed by a well-meaning kid. My first instinct was to suggest to the blocked user to apologize for making the mistake and ask for an unblock, but to my considerable surprise, wiktionary has no unblock template. I was further disappointed to see that the blocking admin, Connel MacKenzie, doesn't even bother to inform users when they are blocked. I'm an admin on en.wiki, I understand the importance of allowing for wide discretion in blocking potentially harmful users, but this block was just careless. A reversion and reprimand would have sufficed, even if it meant that Connel had to take the extra ten seconds to add a user warning template. If it is all right with wiktionary administrators, I'd like to import en.wiki's unblock template to allow for at least some level of oversight for unexplained blocks. Anetode 04:55, 7 February 2008 (UTC)

Importing that template would be more than useless; blocked users cannot comment on their talk pages here. That is custom 'pedia software. I understand you can't see, or didn't notice the deleted redirect that caused the block. Misspelling vandalism might be good for Wikipedia, but doesn't have a place here. A one day block. Your realize you are going on and on about a one day block, right? --Connel MacKenzie 05:10, 7 February 2008 (UTC)

If blocked users cannot comment on their talk pages here, is there at lest a notice built in to MediWiki that alerts them to the Wikimedia unblock e-mail address? Anyway, as I said, I'm not fully familiar with how blocks work around here, the suggestion to implement an unblock template made sense in the context of my experience with en.wiki administration. If such implementation is not technically feasible, then my suggestion is moot. Thanks for the explanation. Anetode 05:22, 7 February 2008 (UTC)

The current content of MediaWiki:Blockedtext is less than ideal, though I'm not sure what to put there. Given our zero-tolerance blocking culture here (which is at least in part a legitimate response to our astronomical articles-to-editors ratio), it would indeed be good to provide a more transparent form of recourse. -- Visviva 07:33, 7 February 2008 (UTC)

That's interesting. It might be worthwhile to create some form of recourse that blocked users can take to bring their situation to the attention of other admins, if they feel mistreated. The user had received no instruction on their talk page, and marshmellow is an attested misspelling. That doesn't mean that I agree with the user's actions, I think deleting the redirect was the best way to go, but I will say that I think the block a bit overly hasty. Atelaes 05:26, 7 February 2008 (UTC)

Speaking of recourse, could someone please take a look at User_talk:Connel_MacKenzie#Hair-trigger_block. I was under the assumption that all users with administrator privileges on a Wikimedia project were expected to abide by basic standards of civility. Anetode 05:43, 7 February 2008 (UTC)

I have watched the conversation unfold. I believe both of you may have misinterpreted each other's remarks a bit. How about we let the convo drop for a bit. Eh? Atelaes 05:56, 7 February 2008 (UTC)

Don't worry, I've absolutely no desire to engage this user in further discussion. I accept that my initial complaint of the block was made without full knowledge of the deleted redirects and I apologized for not taking that possibility into account. However I think it's difficult to misinterpret Connel flat out telling me, "fuck you", and I would appreciate an apology from him or a reprimand for resorting to such gross incivility when addressing a valid administrative concern. Anetode 06:13, 7 February 2008 (UTC)

No. --Connel MacKenzie 06:26, 7 February 2008 (UTC)

And we wonder why we have so few contributors... -- Visviva 07:33, 7 February 2008 (UTC)

Since we're here, let's have a beer and talk about this thing. On the merits of this case, which resembles a number of other blocks imposed by some of our best admins, there simply does not seem to be any intelligible rationale. Creation of redirects in the mainspace is discouraged, yes; however, this is a common misunderstanding for those who come here from pedia, is relatively harmless, and hardly merits a block. While the assertion that marshmellow is a common misspelling of marshmallow may seem absurd, it is horrifyingly accurate; in fact, judging from b.g.c., this misspelling appears to be slightly more common in print (1/6) than it is on the web (1/7.3) (however, there may be a scanno effect). It is even considered important enough to merit special mention in various usage and spelling guides. I'm just not seeing the vandalism here. If this is the sort of editing we're systematically treating as vandalism, we really need to reexamine that. -- Visviva 07:54, 7 February 2008 (UTC)

As I see it, the original edits were mistakes insofar as (1) they do not conform to our layout, including redirect conventions, and (2) they masqueraded a misspelling as an alternative spelling.

I could not believe that anyone would issue a block over the first point without having informed the editor, indeed without having informed them with the relevant information prior to such consideration. The conventions were not knowingly ignored as the user was not even made aware of them until being welcomed the day after the block. Therefore, the only reasonable grounds for the block, in my view, are the second point.

However, we do not have any criteria for distinguishing between misspellings and alternative spellings, and this misspelling is so common that the very question must be raised. Looking at the editor's history in addition, I am satisfied that the mistakes were innocent, and that even a reprimand, that is, a threat to block, was not warranted, let alone an actual block. What was necessary was a correction in the form of a note to the contributor and/or edits to the entries.

That this is not by any means the first time that Connel has taken questionable actions against newcomers does not bother me. He has been fighting vandalism for some time. The fact that the block was issued is neither a detail that concerns me. As Connel says, it was only a one-day block, which is almost too short to correct. But while it flows off a vandal's back like water on a duck, a one-day block and even a reprimand can really sting a well-intentioned individual. It saddens me that anyone, let alone a checkuser, would treat a block as a problem he doesn't have to concern himself with, if only to determine that it was a mistake.

I can understand taking a hard line against vandalism and even the most innocuous of foolery, but are we supposed to strike out well-meaning contributors after three innocent mistakes? How would we judge how to escalate future action against the editor, considering the way the block log is used as a blacklist? I have seen the number miscounted for reasons as simple as unblocking to allow re-blocking for a different time span. If nothing else, it matters to the editor to know that we welcome his or her contributions. Do editors even know for how long they will be blocked?

Instead, Connel characterizes the editor after the fact as "a misspellings vandal". This is the most telling and most troubling of any of his actions. I have not seen the v-word thrown around in that matter for some time, but I know its curtailed usage does not reflect a change in the way Connel views reputation, or for that matter, much of anything else: black, white, and if you try hard enough to convince him otherwise, just a smidgen of gray. More than likely I'm being too broad with the last comment, but I'm not trying to prove the point. I'm saying that this is my impression of Connel, who I very much value as a contributor with a great stake and a leading role in this project, but who I do not trust with matters of diplomacy.

The harsh words he used against Anetode do not faze me only because I have grown used to them even as they are thrown against me. I am confident enough to defend myself, Anetode mature enough not to try. The other option is to yell obscenities back, but everyone who has done that to date has been branded and blocked. Maybe it's just as well we didn't have that sort of person here in the first place? But then there are also people like Ncik, Keffy, and Richardb who get turned away. I am not fazed, but I am definitely saddened.

And I think it's time that we did something. I would suggest anything from a one-day block, which apparently isn't that big a deal anyway, to a vote of confidence on his status as checkuser. If this brands me for life in his eyes, then so be it. Connel is a much more valuable contributor to this project than me, and I have other dreams. DAVilla 10:51, 7 February 2008 (UTC)

Re: "I would suggest anything from a one-day block, which apparently isn't that big a deal anyway, to a vote of confidence on his status as checkuser": Your range of suggestions stops well short of where mine would. —Ruakh_TALK 02:05, 8 February 2008 (UTC)

DAVilla, it doesn't surprise me that you'd suggest spelling is not important to a dictionary. Not with any warning that it's a misspelling of course...no, only entered in as misleading a way as possible.

What foresight you have to know that's exactly what I was leading to! "Masquerad[ing] a misspelling as an alternative spelling" is an innocent mistake, therefore dictionary spelling isn't important. Right.... Like I said, black and white. DAVilla

Let's review, shall we?

Someone who has in the past made questionable edits here, comes along suggesting a misspelling as a valid alternate. (Note that about half their previous contributions are spam links to external sites, on their user page.)

The "spam" links are very obviously resources that the contributor relies upon to interpret anime, a few interesting bits of which constitute her contributions here, if you connect the dots. I don't find that content all that objectionable, and in the main space the prior edits were in no way questionable. DAVilla

They then add 'pedia-style redirects.

She had never been told otherwise, never even been welcomed in the first place. DAVilla

This same person gets their stuff undone, with a short term block.

This same person whines to their Wikipedia cabal.

Sure, she probably wondered what on earth she had ever done to deserve such a harsh treatment. So does everyone else here. DAVilla

A Wikipedian appears on my talk page with treats and attacks.

You skipped a few steps. First the Wikipedian asked a question that's worth repeating. "Do admins on wiktionary even bother warning well-meaning kids when they make silly mistakes, or do you just show them the door?" Very applicable to this case, I would say, and mighty light as an attack in comparison to a lot of stuff you say, for instance your response in which you suggested this was harassment that warranted a block, which is an absolutely absurd idea. I'd like to see you find someone to take up that cause. And to think that you'd threaten others for pointing out mistakes you've made. More threats and the petty power games are in the record, by the way, between yourself and Ncik, yourself and Keffy, yourself and Richardb, all of whom have left this project because of you. DAVilla

That same Wikipedian appears here, pushing their agenda for (more) inappropriate warnings.

I would mention any talk page conversation here that resulted in a "fuck you". DAVilla

I try to be nice at first.

Your very first response included the words "I wouldn't be surprised if another sysop blocked you". That's your idea of being nice? DAVilla

The lost Wikipedian screams "AGF" never having even read our policy (which informs him/her to AGF for sysop activities, here. Nevermind that they've already blown that.)

The Wikipedian (using effective troll tactics, indeed) continues baiting me, as if s/he knew I was busy elsewhere.

That Wikipedian (who started with threats in the first place) accuses me of threatening him/her.

Realizing this is all a bullshit agenda, based on a short term block I tell him/her to fuck off.

---

You have a different views on things, to be sure. I am unquestionably outspoken by Wikipedia standards. If you would prefer the total decay to Wikipedia troll-fest status (yeah, yeah, black/white, no gray, blah, blah, blah,) then attacking CU status (entirely unrelated in this matter) is fine with me. {{support}}. (I don't recall being subtle about CU being a much larger PITA than imaginable.) I don't see how that helps your agenda for turning Wiktionary into Wikipedia2.0.(rev.troll) unless you are ascribing status that doesn't exist, to being a CU. It's a technical thing. But hey, whatever.

For the record I am not at all comfortable having you as a checkuser, and it's ironic that you don't really enjoy it because it's impossible to nominate anyone else given that we don't need any more checkusers. If there is someone else you have in mind to train on the technical aspects, why don't you just announce your planned retirement? Or if you wouldn't want to train anyone, just give it up and concentrate on work that doesn't make you so grumpy. DAVilla 10:09, 8 February 2008 (UTC)

Or, if you (plural - the Wiktionary community) wish to block me for a day, for being right, well, I don't know what to say. That would be a pretty clear invitation to the bad elements of Wikipedia, no doubt about it. --Connel MacKenzie 12:01, 7 February 2008 (UTC)

I don't think that the unblock template serves any useful purpose here except so that people can reprimand sysops for not using it. Please do not import it; we do not have enough admins to make pandering to WT:blocked users practicable; though I know that User_talk:Connel MacKenzie gives an email address that they can contact him on and I have been considering doing the same. <Irrelevant commenting>In regards to this specific block, as the conversation seems to have changed, please note that "repeated stupidity" is a valid reason for blocking people here, simply because we don't have the manpower to continually mop up after them. I wouldn't have blocked looking at the contributions, however I am convinced that Connel felt he was doing the right thing. I think that the personal attacks being thrown in all directions are off-topic, uncivil and detrimental to the community spirit</ugly buzz-sounding words>. I think that Connel should be blocked for a token period, his responses are (in my opinion) markedly less civil than everyone elses, though I also feel that no-one involved with this thread has the right to do so, as I can see personal attacks (some more snide and subtle than others) from all sides.</Irrelevant commenting> Conrad.Irwin 12:37, 7 February 2008 (UTC)

If referring to Connel as "one of our best admins" is taken as a snide and subtle personal attack, this makes it difficult to think that anything constructive can be achieved in this discussion. This is unfortunate, because I think that this problem is both cultural (i.e. not specific to any particular admin) and of critical importance for Wiktionary's long-term health. Perhaps we can resume this discussion in a week? -- Visviva 12:59, 7 February 2008 (UTC)

I am sure Connel felt he was doing the right thing, which is why the short block itself is not what worries me. What concerns me is that he still feels it was the right thing to do, or at least doesn't think it's worth reconsidering because it was so short. What, no apology?

If {{unblock}} is not a template we want, it should at least redirect to MediaWiki:Blockedtext, which may need rewriting per Visviva's request. DAVilla 10:25, 8 February 2008 (UTC)

I've attempted to disengage, but I cannot allow Connel's account of events to stand unchallenged as it is skewed, self-serving, and disingenuous. A young editor (read: school-age child) was distressed over the rude treatment she received over at Wiktionary and contacted me on Wikipedia. I checked her problematic edits and discovered that they were met with a swift and unexplained block. Since Connel appeared to be an experienced and knowledgeable wiktionary admin, I asked him why he bit the newbie. Connel's response was understandably defensive, but went too far in accusing me of harassment (in a passive-aggressive sense, "I wouldn't be surprised if anther sysop blocked you for this harrassment"[3]). I openly accused him of threatening me, to which he responded with succinct profanity. I am not proud of the exchange, especially of getting annoyed at Connel's accusation of bad faith on my part, but I will not allow him to misrepresent my actions or insult me further in this thread.

In the above list he has accused me of threatening, attacking, pushing some unnamed agenda, acting on behalf of a cabal and trolling. Despite his claim, he made no attempt to extend any sort of collegiate courtesy. I don't much care about Connel's status here, it does not excuse his immaturity, baseless insinuations and outright insults.

As for the nature of this thread, I thought it might be a good idea to suggest an unblock process that would fill the need for administrative oversight. I only meant to offer my help, I see now that vandalism management on Wiktionary is handled far differently than at other Wikimedia projects. (e/c) Anetode 13:13, 7 February 2008 (UTC)

I'm baffled that you'd expect and demand politeness when the first (and last and middle) words from you are attacks. "[Bite] [much]? Do admins on wiktionary even bother warning well-meaning kids when they make silly mistakes, or do you just show them the door? Disappointedly yours, Anetode 04:15, 7 February 2008 (UTC)" Putting that aside, I do wish to point out Anetode, that you seem to be mistaken on a major point: it is the English Wikipedia that is far different from almost all other projects (except perhaps meta.) While the English Wiktionary probably takes the brunt of the spillover, it is hard to call normal procedures here atypical, for WMF. This is your first time posting on an wiki other than en.wikipedia, no? Lastly, I am still suspicious of your jumping here before waiting for a response. If your intent were as innocent as you suggest, you might've waited for an answer to that first query, no? Alas, you instead poured on more attacks here, citing inapplicable Wikipedia warning rules (etc.) Am I supposed to be pleased with your set-up? I take some blame for feeding the troll (these threads) to be sure. So far, the only thing I've seen in that "well-meaning kid"'s defense is Visviva's research (and its "horrifyingly accurate" result.) But that didn't account for proper nouns, surname, etc. Visviva also portrayed incorrectly (I assume for the sake of diplomacy) the Wiktionary position on redirects (anything, but "harmless.") Visviva even had a helpful suggestion (reexamining WT:REDIR) mixed in there. I still see nothing in your defense, just cries of victim-hood for being told off (rudely.) Sorry, but no, that does not exonerate your behavior. --Connel MacKenzie 14:15, 7 February 2008 (UTC)

My defense? Exoneration? My only "crime" was to have questioned your judgment. I never endorsed vandalism or disruption of this project, I supported corrective action for the user you blocked. The only thing I regret so far is the bad luck of running into you. Yes, I have substantial experience in contributing to Wikimedia projects other than en.wiki, and yes, I intend to contribute this one. Anetode 00:41, 8 February 2008 (UTC)

Fun stuff. I'll try to be succinct (something I'm bad at): First, should the user have been blocked? I say no. I'm actually somewhat off the norm for this project, in that I generally can't be bothered to block for just one bad edit. I don't complain, of course, if someone else wants to do it. But regardless, this was not a bad faith edit, IMO. Secondly, did Anetode jump in, guns blazing, Cabal hood sticking out of their sleeve? No, but damn, someone draw me a picture of that. I'm a bit off with the whole riding-in-from-'pedia thing, but I think that this was brought to our ('the community's') attention after the, er, intellectual debate got a bit heated was the right response. Thirdly, should Connel be blocked for a token period? No, I don't see how that'd help, but Connel, I think you need another Wikibreak. I can see people jumping in here (hey, that's me!) and this whole thing getting worse, and maybe sitting out for a while to avoid that would be a good idea. Voluntary is much better than mandatory, I reckon, and I hope everyone would agree with that. Finally, yes, gimme a marshmellow very common misspelling page and let's not (re)define the difference between a misspelling and an alternative spelling right now, but soon might be good.

Damn, that wasn't very succinct, now, was it? --Wytukaze 03:35, 8 February 2008 (UTC)

A block, even a token one, would indicate that the community finds this behavior unacceptable. If symbolism doesn't float your hypothetical boat and you want it to actually accomplish something, consider that future infractions could lengthen the time, just as blocks of vandals are escalated. If it is not done, then it indicates our continued complacency and ambivalence. And what else to do? Something silly like asking for an apology isn't going to work. I have wondered if a few of Connel's apologies were sincere, and I have not been moved by any to my recollection.

Whether Connel wants to take a wikibreak is his business. As far as I care, his block for a day can wait for his return. He needs to realize that we mean this sincerely, and that with the adoption of AGF the period of free reign has come to an end. DAVilla 10:52, 8 February 2008 (UTC)

Point of order, without any particular opinion on the issue: Any block imposed on an admin requires the blockee's consent, because blocked admins can unblock themselves at will. At least that's the case on WP, and I believe it is a basic restriction in the software. If the community feels that an admin has seriously betrayed his/her trust, which is a very serious question, the correct action would not be blocking but desysopping. -- Visviva 16:07, 8 February 2008 (UTC)

Well, I already said that I would if the community's desires are clear, Visviva. However, I remain convinced I did nothing so inexcusable. The short term block was appropriate to begin with. The initial hostility of Anetode was not appropriate, nor my response, nor his troll here, nor my response to that. For you to be feeding the troll out of a dislike of me is understandable, but unwise. --Connel MacKenzie 16:41, 8 February 2008 (UTC)

My initial hostility was based on a lack of knowledge of Wiktionary guidelines, several editors have been kind enough to offer civil explanations of the flaws of my assumptions. Your persistent insults are an inappropriate and immature defense mechanism to dealing with criticism. I am not a member of the Wiktionary community and I do not have a substantial record of contributions here, but I have several years of experience in contributing to other WMF wikis and I would appreciate a modicum of respect. ˉˉ^anetode╦╩ 08:56, 9 February 2008 (UTC)

Your "initial hostility" set the tone for which all else followed. Had I been using my normal venting outlet, my reaction would have been more subdued. But your insistence on violently inflicting Wikipedia norms is still inappropriate. You might have gotten some respect had you shown anything other than threats and accusations. While this particular thread is tremendously one-sided, I have received significant support elsewhere from many of the Wiktionary regulars. The only people I see commenting here, are people who have a bone to pick; apparently everyone else is too wise to engage is such pointless nonsense. Once again, I am appalled at your brazen inversions. You directly, personally insult me five times and demand a "modicum of respect" in the same breath? No. If you are such an experienced editor, you'd recognize that fallacy. Have you yet read our AGF that you so errantly called on initially? --Connel MacKenzie 09:39, 9 February 2008 (UTC)

Your appraisal of my intent is skewed by an apparent vendetta against Wikipedia and its practices. I think that Wiktionary editorial policies have been successful in allowing editors to compile a valuable reference source. On the other hand, I think that the current Wiktionary block policy does not allow for sufficient oversight to address potential abuse. On this we differ and I defer to the community consensus. You are hypersensitive to criticism and misinterpreted my disapproval of your block as malicious harassment and endorsement of vandalism. I appreciate the friendly and civil explanation you offered on your en.wiki talk page to the kid you blocked. I'm also glad that you have a support group to placate you and offer you a chance to vent. I am willing to ignore our initial exchange and bury the hatchet if you are willing to stop assuming bad faith on my part. ˉˉ^anetode╦╩ 12:08, 9 February 2008 (UTC)

Right, I would not vote to desysop unless Connel did not consent to the block, assuming it's decided formally that he should be. DAVilla 17:10, 8 February 2008 (UTC)

::::What about the Check-User facility? I know that his actions had nothing to do with CheckUser, but having that Check-User privilige facility is a result of having lots of trust from fellow Wiktionairians, and relieving Connel of it might be a strong sign that there's no longer this level of trust and respect for him. --Keene 17:21, 8 February 2008 (UTC) - Sorry, this has been mentioned above already. --Keene 17:25, 8 February 2008 (UTC)

DAVilla, it is in very poor taste, that you too, call on "AGF" - when the main point here is that the WT:AGF we have, says pretty damn clearly that someone like Anetode must not make the bad assumptions he did, from the very, very start. The fact that he called on the policy without ever having read it, is itself evidence of his/her bad intentions here. I think your dislike of me personally might be unrealistically skewing your comments, unwisely. --Connel MacKenzie 16:41, 8 February 2008 (UTC)

I'm not sure if I like you or not. I don't cast my support on that basis. Our personalities are complete opposite in that I only see gray, and some of the arguments we have are actually very constructive. What I dislike is to have one person who will not concede when it's clear that the argument is one-sided. That's not a trait unique to you, or one that defines you entirely, but you've had some really lopsided ones here. On the other hand, the mother of all lopsided arguments goes to Eclecticology, who had been absent for some time before it. Change is difficult to accept.

No one here is scrutinizing Anetode's actions but you. And to be clear, I did not mean that the block itself was a violation of AGF. The violation was when you called the blocked user a "misspellings vandal" in your refusal to review the block. DAVilla 17:33, 8 February 2008 (UTC)

Now that really throws me. By reviewing the block, you mean immediately capitulating to unreasonable demands/threats? Of course I reviewed the block. That's when my incredulity began. The block itself was valid and correct. Calling the type of behavior "misspelling vandalism" was the best characterization of that behavior...it wasn't like the edit was in any way trying to warn people that it was a misspelling ("horrifyingly" common) but rather that it was trying to pass off a very blatant error as being correct! So, do I get this right - you are suggesting I should be voluntarily blocked for 24 hours for using the "v-word" to describe particularly mendacious behavior? Or because you're grasping at straws, for other disagreements you mentioned above? --Connel MacKenzie 17:52, 8 February 2008 (UTC)

The editor wrote, "Sometimes spelled as marshmellow." Connel is convinced that was an attempt to vandalize this project, so he doesn't understand why calling the newbie a vandal is an assumption of bad faith. His stance here is very consistent for him. I would support any effort to educate him about granting the benefit of the doubt, but I've been here long enough to know he will stand his ground. Rod (A. Smith) 19:00, 8 February 2008 (UTC)

My error: you did review the block, but you still got it wrong. Of course the edits in question were incorrect. Even if it were an accepted alternative, "Sometimes spelled as marshmellow" does not belong in the etymology. No one is denying that they had to be corrected. But the user should not have been blocked, and the user is not a vandal. Your assumption that she is, even continued until now, is in violation of AGF. The "v-word" does not describe behavior, it describes a person's intentions. Intentions are not always clear-cut; they have to be guessed at. Your assumptions of her intentions go over the line. DAVilla 05:54, 9 February 2008 (UTC)

I think this is a significant point. What did I get wrong? I still see nothing regarding that block that is remotely incorrect; certainly nothing outside normal day to day RC patrolling. The spelling itself is so obviously wrong, it was inconceivable to me that it could be attested (nor "horrifyingly" attested.) But that has nothing to do with how we treat redirects here. We expend enormous resources simply on cleaning up redirects of valid spellings that differ only by case. We expend enormous time and energy eliminating (otherwise) bad main namespace redirects. The fact that is was a blatant misspelling only compounds the transgression. (The follow-up edit that Rod points to, is just icing on the cake.) The user's previous edits were all questionable and the block in question was a short-term block! What did I see that you're not seeing; or what are you seeing that I am not? What (in your opinion) did I do wrong with that block? It was a valid, correct block. --Connel MacKenzie 09:39, 9 February 2008 (UTC)

(Since you asked.) Regarding the review, you're wrong because you still somehow think that the editor intended to damage this project, when instead the editor just made some innocent mistakes. More severe, though, was this edit, where you called that well-meaning contributor "A misspellings vandal" and threatened Antedote. Despite your confused grumblings about Antedote's understanding of WT:AGF, you're the only person in situation who actually violated it. Rod (A. Smith) 19:49, 9 February 2008 (UTC)

It was—past tense—inconceivable that it could be attested, but by now it should be conceivable, no? I'm not claiming it isn't a misspelling, but it seems like that case could be made as well. The redirect was flat out incorrect. But no one is saying that the user didn't make bad edits. What we are saying is that the edits were not in poor faith. We assume that the user believed that the variation was a valid spelling for marshmallow, possibly after having seen it in print. If you felt that the user's previous edits were questionable then a short-term block was the correct thing to do. However, when informed of the mistake, you didn't review those edits as well as you could have. You didn't do the "research" that Visviva did. You didn't give the user the benefit of the doubt, wondering if the links on the user page might be useful to her in relation to this project. At the very least you could have passed the request off to another admin since you don't speak Japanese. Instead you insisted that a one day block does not matter. If the community agrees, I would like to show you exactly how much it does. Not because I want you to leave the project, not because I want you to stop fighting vandalism, not because I want to count up every tiny mistake in the long history thereof, but because I want you to understand that your view of this case after the fact is in conflict with the norms that we have agreed upon, and because I would wish for you to change your behavior when you are questioned about such matters, for the sanity of fellow volunteers as well as for the benefit of those wrongly accused. DAVilla 01:56, 10 February 2008 (UTC)

Forgot something! The thing in the title. That is, x-ly, no to an {{unblock}} template. Uncool. Or rather, ain't gonna work, bub. Someone give me brevity lessons! --Wytukaze 03:39, 8 February 2008 (UTC)

arbitrary section break

I had hoped this discussion would die down because I don't really like discussing other editors like this. But for reasons that are largely historical and bigger than this one incident, and for which Connel should know, the community wants to have this discussion. I think there is widespread (looks like unanimous, actually) agreement on the particulars of this case. Connel's block was excessive because it assumed that the editor was being malicious when it was more reasonable to assume they were simply new and imperfect. That user understandably asked a WP admin for help, and that WP admin understandably contacted Connel to dispute the block. Anetode was a bit more abrupt than necessary at first, but Connel was downright offensive. It reflects poorly on Wiktionary as a project. Connel, we as a community appreciate your work here immensely. It's not out of spite that people are discussing this. I think the collective response here is more about quite a few people that are concerned. The wider issue here is that there is no reason that the work you do can't be just as effective without assuming the worst about people, especially new people, and without treating this dictionary like a battleground, even with fellow admins and established users who are most certainly not acting in bad faith (any yes, maybe even Wikipedia admins, too ;-) ). I think a definitive statement from you that you will try to make this change would go a long way. Dmcdevit·t 06:00, 10 February 2008 (UTC)

Well, Rod doesn't think so - at least, I can't promise to change any behavior, when I don't understand what is wrong (DAVilla's last explanation helps, in that regard.) It is beyond conceivable that on February 6th, a one-day block for "misspelling [hmm, no v-word...ok, how's this then:] stuffing" could somehow be considered inappropriate. I maintain that it was an egregious breech of AGF for a Wikipedia sysop to arrive here with accusations and threats, suggesting that it was not (in 100% ignorance of Wiktionary norms.) This is exactly the concern that EncycloPetey raised here that became a cornerstone of that Wiktionary policy. "...about newcomers assuming good faith on the part of sysops who delete entries, experienced users who edit entries, or users who give insruction and advice about Wiktionary standards and formatting conventions...Newcomers (and trolls) should have notice in a policy document like this that "good faith" means making an effort to learn and practice community norms, not simply have "good feelings" and "helpful desires"..." It is disingenuous of Rod to claim that the visiting Wikipedians (both, actually) didn't comply, with his rewording of that.

For the larger "community concerns" that Dmcdevit observes, I'm not sure what I can do, other than to avoid patrolling (as I've done for the past two days) almost entirely. I will say that I've found my time spent on programming issues more satisfying. But I don't (conceptually) understand why it is OK for people who never patrol, to dictate how patrolling should be done (or rather, that it should not get done at all.) I also don't understand the immediate capitulation of DB-crap-loading of userwarn templates held by people who don't normally patrol. I do understand that most people consider my initial response rude (and everyone considers the subsequent response rude.) But I am alarmed at the rationale for accepting the Wikipedian's initial hostility, simply because it was directed at me...I think that is very, very foolish. --Connel MacKenzie 17:10, 10 February 2008 (UTC)

Maybe this will, ironically, result in something you have always wanted, which is to have more contributors patrolling, if you are not so consistent on that task. You had plugged the holes before, but the Wiktionary watershed is growing, and sometimes there is no choice but to open the dam. Have faith that it will be caught downstream. DAVilla

I do wish to point out that although there has been a wonderful stepping-up of other sysops these last two days, the lost continuity also has a price. The "downstream" you speak of, is, for the most part, my "/todo" cleanup lists - which is precisely why I've historically spent so much time patrolling Special:Recentchanges! Stopping a flurry means you clean up two or three errors, instead of two or three hundred (at a time.) --Connel MacKenzie 01:28, 11 February 2008 (UTC)

Thank you for your civility. I hope that everyone sees this. Never mind about the next part on anons. DAVilla 01:36, 11 February 2008 (UTC)

I want to be clear in that I have always valued the work of those who patrol edits, even before we had the collaborative patrolling system we have now. When I first came to Wiktionary I didn't understand why edits could be made anonymously. The only reason we do, as I understand it now, is because of the large number, expecially of translators, who make sporadic edits without logging in, if they even have accounts. If it would help, we could consider disallowing that. I would insist that it must apply to all edits though, not just new entries, as had been proposed before. Perhaps this is a discussion that will win more support after others have done a couple of months of patrolling themselves. DAVilla

In the last year, I've seen a dramatic improvement in anonymous edits. The only problematic anon IPs are open proxies, or K-12 school districts. Short term-blocks on those have been effective in building history that a patrolling sysop can see almost immediately...much faster, than, say, reading a 40KB talk page of repetitious warnings. --Connel MacKenzie 01:28, 11 February 2008 (UTC)

Your last point I've touched on in reply to the new vote. DAVilla 18:00, 10 February 2008 (UTC)

Did you? The point is that, not knowing anything about Wiktionary (or me,) he accused and threatened. That's why I keep repeating that your bias against me seems unwise (and much farther reaching than you seem to think.) At least with that vote started, an end is in sight. --Connel MacKenzie 01:28, 11 February 2008 (UTC)

I'm confused by the above, It is disingenuous of Rod to claim that the visiting Wikipedians (both, actually) didn't comply, with his rewording of that. Do you think I claimed that the visiting Wikipedians violated WT:AGF? Or, are you perhaps saying that I disingenuously (“deceptively”) reworded one of EncycloPetey's contributions to WT:AGF? If I understood your meaning, perhaps I could address your concerns. Rod (A. Smith) 03:07, 11 February 2008 (UTC)

So much for proofreading. I meant "did" not "didn't" but I'm not sure 'disingenuously' was the word I was looking for. (A spellcheck left me on a tangent discussing the spelling of that word with Widsith, nevermind that the definition we have doesn't match my understanding of the word. I was looking for a word that conveyed that it seemed like an odd coincidence. I was not trying to offend.) I was not saying that your rewording was so poor, just reminding you (and everyone) precisely the quote I thought expressed it best: a random Wikipedian charges in at the drop of a hat, demanding that all things Wiktionary be identical to the poisonous atmosphere of Wikipedia...without even reading the Wiktionary equivalents of what he accused and threatened with, nor the one he called on when he started this thread. You may not like how I reacted to his threats and accusations - but to say the initial block was irregular, or outside the norm, or incorrect, is wrong. --Connel MacKenzie 05:14, 11 February 2008 (UTC)

In what follows, please forgive my apparent newbie presumption that I can truly grasp what's on the mind of people I've never met and who almost entirely communicate on public fora or private ones subject to public viewing.

What is the purpose of blocking? Is it to discourage contributors who are 80% or more likely to not make a positive net contribution (net of correction effort)? Or is it to prevent directly destructive behavior? The latter seems to be the WP model. There are whole subject areas of silliness, much like a magazine store that carries fanzines, comic books, and porn, next to Nation, The Times and The Economist. If the former, there is also a vision of what Wiktionary can be that is needed. I'm not sure that that vision is well communicated. To the extent that WT is to be the creation by a small group of amateurs and academics of an "open-source OED", it is radically different from the reality of WP. Is that reality consistent with the overall vision of Wikimedia? Is that what the on-line world wants and needs?

I bring this up because Connel has stated that he does not see anything wrong in the block. I take this not as cussedness, but as a possible reflection of difference in values with respect to Wiktionary. His view of the user in this case seems to me to have been premised on the view that WT should not have fanzine-like entries and therefore a person likely to make such entries should be discouraged. Connel was, I think, protecting the unstated/unvoted-on vision that this is a place where we all worked/played toward an "open-source OED", free of the enormous expenditure of resources to police and edit new entries that the OED wouldn't have. This vision may not be sustainable and consistent with Wikimedia policy. If it forces us to exclude innocent, but low-value users, it may not be consistent with Wikimedia policy or the values of the larger community on which we depend. DCDuring TALK 11:33, 11 February 2008 (UTC)

I think that is a very interesting way of looking at this, from my point of view it seems that we can either build a dictionary or provide a site for the entertainment of the masses. As you say, 'pedia tends towards providing fun and entertainment - however as 'pedia shows, this is not the most productive way to build a reference resource. I am not saying these goals are mutually exclusive, however I feel that Wiktionary is correct to concentrate on building a useful resource rather than allowing more people to have fun. Conrad.Irwin 11:51, 11 February 2008 (UTC)

Here is a list of all the new pages this contributor had created before being blocked:

• neugeboren, German for newborn
• 鎮火する, Japanese for be extinguished
• kaen, Japanese romanji for flame and for garden
• オニダルマオコゼ, Japanese for stonefish
• 暗黒, Japanese for darkness

I don't think it's an offense for people to have fun when they're being constructive. DAVilla 15:43, 11 February 2008 (UTC)

I don't know Japanese, but this looks very good for someone new. Thanks for making the evidence so easy to examine. I can see no reason there for blocking at all. Quite to the contrary. To block based on the appearance of a userpage doesn't seem right. To block based on honest mistakes also seems wrong. Almost everyone new will make mistakes (not to mention the mistakes that veterans make when trying something new). DCDuring TALK 16:53, 11 February 2008 (UTC)

IMO it's critically important that we distinguish content we don't want (of which there's a lot) from contributors we don't want (of which there are very few). Ours is an enormous task, and we cannot afford to lose even one potential helper. However, Wikipedia offers numerous cautionary lessons in the unintended effects of being too tolerant of certain kinds of borderline content. -- Visviva 16:13, 11 February 2008 (UTC)

We may need to do something better in terms of handling newcomers: documentation, more structured help, "personal" contact, to accelerate their becoming net-positive contributors. The hardball screening approach seems likely to keep out both most bad vandals but some good contributors. Also, do we need a play-pen namespace that has a more urbandictionary/WP flavor? DCDuring TALK 16:53, 11 February 2008 (UTC)

No, no playpen space. However, I think the real crux of the problem lies in two points.

One point is articulated by you in that we need to do a better job of handling newcomers. We really need well-written, up-to-date, and easy-to-browse policy documents targeted for newcomers. We also need more admins patrolling regularly and trained to deal with situations that typically arise. We need more admins watching newcomers in order to advise and assist with formatting and community norms. Consider that most people won't notice a newcomer unless that newcomer is either editing heavily during the time a regular user is logged on, or unless that newcomer is editing repeatedly in a language that a regular user edits. In other words, a newcomer who edits Japanese entries is likely to go unnoticed unless one of our two regular Japanese contributors happend to be editing at the same time and day as the newcomer. People editing in other languages are likely to simply ignore what the newcomer is doing since it's outside their area of expertise.

The second point is articulated by Connel near the outset of this section, and ties into the first point closely. We have many people with strong opinions who aren't getting their hands messy in the actual implementation of the ideals being espoused. One of the best ways to alleviate situations like the current one is for people to take a regular hand in activity that will keep them from happening. We need more of our experienced users regularly patrolling and commenting. I have done patrolling irregularly of late, but I still do it. I do it because I see potentially great newcomers, and I do it because I see some of the ridiculous nonsense that other patrollers sometimes miss. The more people who contribute regularly in such efforts, the less likely we are to have a situation like the current one. --EncycloPetey 18:55, 11 February 2008 (UTC)

Absolutely, where do I sign up for the quick course in how to do it right, how to recognize a problem above my pay grade, and what to do with said problem. At my current state of knowledge, only English, sadly. DCDuring TALK 19:06, 11 February 2008 (UTC)

Well, presumably you know that Translations in the table should be wikilinked. That's something that occurs in English entries, but often isn't commented on to new users. Perhaps we ought to start a list somewhere of the most frequent (simple) problems noticed in patrolling, with examples of how an experience user might respond constructively to them? This could serve eventually as a tutorial for both newcomers and patrollers. --EncycloPetey 20:42, 11 February 2008 (UTC)

That sounds like an excellent idea. Because DCDuring is fairly new, he should have fresh eyes in helping to edit what the regular patrollers see as the most common problems. Incidentally, I want to say that I do not consider adding translations without linking them to deserve the status of being an error, as I have never known anyone who refused to do so when told. The point is that the contributor is adding content which, if nothing else, a dictionary user could simply copy and paste into the search box, and that [[]] is a correction so simple that even a bot could take over. In fact, the bot we have is adding a lot more than that, using {{t}} with coloring. I would completely leave it off the page, and focus on misconceptions like the conflation of transliterations with pronunciation, and the use of "Chinese" as a language name. DAVilla 22:01, 11 February 2008 (UTC)

We can also reveiw Help:FAQ (and why is that abbreviated?) DAVilla 00:03, 12 February 2008 (UTC)

Note that I carefully avoided the word "error" when I wrote my preceding comment. There are a number of things we always want to see, that frequently are omitted by newcomers: language headers, POS headers, and wikilinks are among the most frequent omissions I recall seeing. Very well, based on your support, I shall start a page called Wiktionary:Frequent Problems (The obvious shortcut would be WT:FP, but I'll not create that in case we decide to rename the page.) --EncycloPetey 22:09, 11 February 2008 (UTC)

The vote on whether to reprimand Connel MacKenzie is currently in progress. DAVilla

Blocking

I'm a bit concerned that "stupidity" is listed as one of the reasons for making blocks. What kind of edits does that mean? Can those edits be described with some other words, and replace "stupidity" with some description? Does it mean continuos nonsensical edits? Best regards Rhanyeia♥♫ 16:23, 8 February 2008 (UTC)

You are personally able to use whatever comment you'd like, when you block. --Connel MacKenzie 17:54, 8 February 2008 (UTC)

It is shorthand for "Oh my God, when will all these fatuous edits end? Have they got nothing better to do with their time? Why can't they leave me alone to get on with building a better Wiktionary?" - but "stupidity" is quicker to type. SemperBlotto 22:28, 8 February 2008 (UTC)

Understandable, of course. We just need something to select that works better for the occasional well-meaning would-be contributor. Maybe more of us need to participate in patrolling to get a better feel for it. DCDuring TALK 22:50, 8 February 2008 (UTC)

Thank you, I try to come up with some idea how Wiktionary:Blocking policy could be rewritten on that line. "Fatuous" isn't much better than "stupidity" however. :) "Continuos silly and nonsensical edits?" I'd greatly appreciate any ideas about this. :) Best regards Rhanyeia♥♫ 08:55, 9 February 2008 (UTC)

I think fatuous is much better (primarily because people who are stupid enough to make a series of silly and nonsensical edits will be left scratching their heads wondering what it means. Then they might actually have to look it up, and realize that the dictionary is a useful thing after all. bd2412 T 23:21, 9 February 2008 (UTC)

While fatuous should certainly be an option of its own on that list, replacing stupidity was unwise; sometimes it is ordinary stupidity, not outright fatuousness. Using "fatuous" was a joke that was funny for about a day. Now, it is tired, hackneyed and overused. --Connel MacKenzie 04:13, 10 February 2008 (UTC)

"Stupidity" is very problematic, calling someone "stupid" may get the user more angry than just a block would do, and that may result to more vandalism. The blocking policy states distinctly vandalism and stupidity for reasons for blocking, so I guess they mean different things. How would be "continuos silly edits?" The tone of the word "silly" isn't as bad as "stupid" but it still has a quite similar meaning. Best regards Rhanyeia♥♫ 09:20, 10 February 2008 (UTC)

From what I've seen, that simply is not true. Those who were blocked for "stupidity" were people entering nonsense in the first place. Beating around the bush eggs them on much more. But thanks for sharing your theory. --Connel MacKenzie 05:46, 11 February 2008 (UTC)

I agree; describing people's contributions as "stupid" or "fatuous," while often true, serves no real purpose except to create anger and hard feelings. -- Visviva 16:06, 11 February 2008 (UTC)

I have another concern too. I hope on Wiktionary:Blocking policy there could be "Editors should not be blocked for making mistakes unless they have been advised about the matter first." That Wiktionary doesn't have much contributors may have a lot of reasons and I don't know how much these things have to do with it, but blocking a newbie or anyone after one or two mistaken edits is very unwelcoming. Also one spam edit can still be a mistake. What happens on editor's screen when they are blocked? Does some message appear there? Best regards Rhanyeia♥♫ 08:58, 9 February 2008 (UTC)

A screen appears which displays the reason for the block and links to the blocking admin (I blocked myself once to see what it looked like). A blocked user will know who blocked him and why, and have an easy way to email them. Atelaes 09:20, 9 February 2008 (UTC)

Thank you. :) Do you remember does the message also say how long they are blocked? Best regards Rhanyeia♥♫ 09:21, 10 February 2008 (UTC)

See MediaWiki:Blockedtext. The length of the block will not normally appear. I expect this is to prevent vandals and trolls from gaming the system by returning the moment their block expires. (Of course, miscreants who understand MediaWiki can just go look at the block log, but fortunately most are not so savvy.) -- Visviva 16:06, 11 February 2008 (UTC)

Could someone point out to me a case in which "stupidity" (or fatuousness, stupidité, 笨, or whatever language you want to put it in) was used as the block reason and none of the other options ("nonsense", "Intimidating/harassment") were applicable? Cynewulf 16:48, 11 February 2008 (UTC)

Excuse me, but "Nonsense" is not one of the drop-down options for blocking. --EncycloPetey 19:10, 11 February 2008 (UTC)

"Inserting nonsense/gibberish into pages", pardon me for abbreviating. Also "Intimidating behaviour/harassment", but you apparently figured that one out. Cynewulf 20:17, 11 February 2008 (UTC)

Right. The point is that the item specifies insertion of nonsense/gibberish, which doesn't cover some cases. Sorry, I can't find a specific case at the moment, but I know there have been times where I selected "Stupidity" over "Insertion..." for precisely that reason. --EncycloPetey 20:39, 11 February 2008 (UTC)

OK, there's also "Removing content from pages" for page blanking. "Insertion..." is for filling up pages with junk. That leaves out modifications, such as replacing a definition of bush with .. well, something else. Personally I would consider that "insertion of nonsense after deleting content". My point here is that we should be able to enumerate a set of classifications that would cover everything "Stupidity" is used for, which would both help admins understand what's worth blocking, and would be less likely to needlessly antagonize users. Cynewulf 21:50, 11 February 2008 (UTC)

Do you really think we should concern ourselves over "needlessly antagonizing" users who create an account and immediately make edits like this [4]? --EncycloPetey 23:05, 11 February 2008 (UTC)

Well, we don't need to, right? Just "Removing content" for that. The people on those "dumbest criminal" shows aren't arrested for stupidity, but for breaking and entering or whatever their exact actions were. Also, it's not only the blocked user who may be antagonized; other users tend to take offense and jump up and down on the admin's talk page, and that gets old. Cynewulf 23:51, 11 February 2008 (UTC)

I don't think the reason for blocking makes any difference to whether people will oppose the block, it is much quicker for us to be able to block for stupidity rather than get bogged down in the lawyering of trying to work out exactly which offense they should be blocked for. I am not saying that stupidity is the best word for it, however if it is replaced it must be by something equally broad. Trying to block for a specific reason, and getting that reason wrong, is going to lead to people saying "you blocked her for removing content but she didn't therefore she shouldn't be blocked". Vandal patrol is never going to be about customer service, they are blocked generally because we don't want them to contribute - yes we shouldn't aim to hurt them, but repelling them from the site is a good thing. Giving a totally bias and subjective term like "Stupidity" gives us the upper hand, there is no excuse or way for people to try and argue their way out of it.Conrad.Irwin 00:03, 12 February 2008 (UTC)

But appearance matters to prevent lots of brouhahas as volume goes up and appeals occur. We can't expect there to be no appeals process and no lawyering. The really strong hand would be if there could be a well-defined list of offenses with agreed-upon criteria, easily applied penalties that covered many (50-95%) of the cases. It can't always depend on the personality and mood of the patrollers. Bots for some of the easier cases wouldn't hurt either, if they aren't already in place. Our defenses must be layered, polite in appearance at every point that it is possible that there might be a valuable contributor or someone gathering evidence of rudeness on our part. Firmness should co-exist with "politeness". During the period someone is "new" or learning maybe they need to have someone specifically watching over their shoulder (assigned to them?). DCDuring TALK 00:37, 12 February 2008 (UTC)

Some suggestions for alternatives to "Stupidity". inanity, humbug, irresponsibility. I must admit that, while some blocks I have happily labelled as "Stupidity", others I have waivered, as it did not seem to be really correct, even to the point of using "Inserting nonsense" even though it was a new page entry. -- Algrif 13:24, 12 February 2008 (UTC)

I've observed that a large number of the times I've used "stupidity" the correct reason should be "user has unresolved problems with his own homosexuality" ... but "stupidity" seems kinder ;-) Robert Ullmann 13:54, 12 February 2008 (UTC)

What are "drop-down options for blocking" mentioned above? Best regards Rhanyeia♥♫ 17:42, 12 February 2008 (UTC)

Here are the reasons listed as I see them. And I'd like to go on record as saying that I like the option of stupidity. Generally, admins are fairly forgiving to users who make an honest attempt (admittedly not always). For those who don't, this is a serious project, not a self-help seminar. I have no problem with rudely shoving out of the way people who interfere (and Robert makes a good point about how "Stupidity" can be kinder than the truth). Atelaes 18:42, 12 February 2008 (UTC)

• Re-adding previously deleted entries
• Inserting false information
• Removing content from pages
• Spamming promotional material
• Spamming links to external sites
• Inserting nonsense/gibberish into pages
• Intimidating behaviour/harassment
• Inserting/creating nil entries
• Abusing multiple accounts
• Suspected open proxy
• Unacceptable username
• Stupidity
• Vandalism
• Copyright violation

If "stupidity" can't be removed, could it still be reworded please? It's uncivil, and although some of those users may have been uncivil themselves, there's no need to follow their example. If the drop down option was "silly or nonsensical edits" that would leave the user to wonder was it silly or nonsense. :) On the Wiktionary:Blocking policy that could then maybe be:

• continuos silly or nonsensical edits: Even though one or two nonsensical edits may be test edits and usually don't warrant a block, users making continuos silly or nonsensical edits may be blocked.

Or is this option something you are using already after one edit? Can one edit be stupid without being vandalism (or any of those other options) so that it's already a reason for blocking? Best regards Rhanyeia♥♫ 19:06, 12 February 2008 (UTC)

Generally the "stupidity" option is for revisions like this, and I can't imagine that the person who decided to add that to walrus was then affected in any way by the wording of the block as displayed in Recent Changes. Who exactly are we trying to protect with this? - [The]DaveRoss 21:28, 12 February 2008 (UTC)

Or the bad puns. The pages where the content is not quite nonsensical (as in "asdfaf" or "green flying cheese"), but obviously created with the sole purpose to try to make us move it to BJAODN or similar. To make us believe they are hilariously funny. (Well, 'for a given value of "funny"', at least...) And such pages are not necessarily "nonsensical" or "irrelevant" in the same manner as they would have been in wp. \Mike 22:05, 12 February 2008 (UTC)

Renamed Urectum? Yeah, I remember that joke. It was pretty lame. My response would have been, "come back in a thousand years and prove me wrong". DAVilla 01:06, 13 February 2008 (UTC)

I don't think we're going to get admins to stop using "stupidity" just by removing it from the default options; and if we do, we might find that one-off substitutes are even worse! If you think "continuous silly or nonsensical edits" is an apt substitute for "stupidity", then I'd like to suggest adding it right above "stupidity", so that admins about to select "stupidity" might think for a second and decide that "continuous silly or nonsensical edits" works just as well. This will give us a fairly objective measure of how good a substitute it is. (Personally, I've generally chosen "stupidity" when none of the options fit perfectly, and I was too lazy to think of a better one-off message. It's a good catch all for a large proportion of block reasons. So with me at least, you'd get more success eliminating "stupidity" by adding options that do fit perfectly.) —Ruakh_TALK 00:42, 13 February 2008 (UTC)

If administrators use words like "stupidity" on a general basis that could reflect poorly on Wiktionary. That phrase in a drop down menu doesn't have a good effect, I noticed that even some administrators I thought wouldn't use it have done it, and those who see it later and don't know about the drop down menu would think that the administrator used his or her own words. At least the administrators would have to write it from the keyboard if it was removed from the options. I think that to remove would be the best, but if there has to be something on its place, "silly edits" or "silliness" would apply to same cases. But I think even those could be typed from the keyboard, so that you'd first look at the other options and try to choose from them. Then at least no one would use it as the first option if being tired or in a hurry. Best regards Rhanyeia♥♫ 09:09, 14 February 2008 (UTC)

It is mainly a case with admins getting very very tired of continually undoing the same stupid `contributions` that get made over and over again; it is not necessarily a comment about the contributor, it is a comment (as it should be) about their contributions. Silliness is pretty much the same as stupidity, and I would be happy to use it as a substitute - it implies doing things without thought, as opposed to with wrong thoughts. To have to type these manually is not a good idea, depending on the mood of the patroller these could end up as downright insulting, to have a reasonably safe fallback that can be used nomatter when is a very good thing. This is not because our sysops are naturally angry or snappy people, but once you've seen the same class of stupid edits repeated almost daily for months at a time, you do get very very tired of dealing with these people. Would anyone object if I added silliness to the drop down to see if it can actually be used as a substitute? Conrad.Irwin 12:52, 14 February 2008 (UTC)

Re: "it is not necessarily a comment about the contributor, it is a comment (as it should be) about their contributions": Oh! I always took it about the contributions, such that until reading this sentence, I didn't really understand what all the fuss was about! I see now how it could be taken as a comment about the contributor. To avoid that, we could add a parenthetical "no stupid editors, but lots of stupid edits". ;-) —Ruakh_TALK 00:21, 15 February 2008 (UTC)

Or, to be more accurate: lots of stupid editors making lots of stupid edits, but there is a small chance that you aren't one of them...maybe. - [The]DaveRoss 00:43, 15 February 2008 (UTC)

The block summary "stupidity" sounds that it's about the person. Although "silliness" may not be perfect it's better than that, and it sounds more that it's about what someone did. Best regards Rhanyeia♥♫ 10:00, 17 February 2008 (UTC)

Conrad.Irwin have you added "silliness" above "stupidity" in the menu to try it? Could "vandalism" be moved after "Inserting/creating nil entries" because it's probably more common than some other reasons please? Best regards Rhanyeia♥♫ 09:17, 23 February 2008 (UTC)

I have added Silliness before Stupidity for a short trial period, but have left the rest of the list as it is - I know where things are on it at the moment :). Conrad.Irwin 23:45, 23 February 2008 (UTC)

Checkusers

There seems to be these two checkusers, and Dmcdevit is quite busy and has duties elsewhere. This means that Connel MacKenzie has to take care of this big responsibility almost alone. Even if there are only a small amount of checks to be made it's still something which needs to be shared. There has been votes, for example the checkuser vote for BD2412, the checkuser vote for Versageek, the checkuser vote for Rodasmith and the checkuser vote for Stephen G. Brown, and more on Wiktionary:CheckUsers/Archive. Could we pick one or two active Wiktionarians from these and make them into checkusers please? I have an experience, not only from the internet but from RL too, that when people are too stressed up with many duties they may become unfriendlier than they mean to be. Best regards Rhanyeia♥♫ 09:08, 9 February 2008 (UTC)

I am active and ready to pitch in. In fact, I have more CheckUser experience than anyone on any Wikimedia project. ;-) While my edit rate is down, it's not for lack of being around and available, just that I'm involved at other wikis and other WMF stuff that's not public, so I may look inactive when I'm not. :-) Dmcdevit·t 14:40, 9 February 2008 (UTC)

Er, to clarify, I'm not saying we couldn't use another CheckUser, especially if Connel wants to step down (note that we must have two per Foundation policy though, for oversight), just not four one ones, as was proposed before. Dmcdevit·t 14:53, 9 February 2008 (UTC)

Thank you for the message. :) Could there be at least one new checkuser? (Is TheDaveRoss no longer a checkuser? He's still listed on Wiktionary:CheckUsers, but not on Special:Listusers/checkuser.) You may be available mostly, but you have a lot of things to do, and also does Connel MacKenzie. If one has to get 25 supporting votes for becoming a checkuser, Rodasmith would be closest. And if Connel MacKenzie stops being interested in doing checkusering maybe there could be two new checkusers? It's probably something one may start to feel lonely with, and if one has a bad day or week it may be relaxing to know that someone else is likely to take care of it. Best regards Rhanyeia♥♫ 09:34, 10 February 2008 (UTC)

At the moment I am not a CU, if I stop being lazy and fax my driver's license to WMF I can be again, so maybe... - [The]DaveRoss 21:16, 12 February 2008 (UTC)

Spanish verb templates and categories

Currently, Template:es-verb-ar, -er, and -ir do not include Category: Spanish verbs, only Category:Spanish verbs ending in -ar. Do the templates need to include this? I am asking because of all of the words in Category: Spanish verbs. Do we really need this category or should they all just go in the respective -ar -er -ir categories? Either they all need to go in Category: Spanish verbs or none of them. Nadando 23:13, 7 February 2008 (UTC)

I don't think it's good practice to categorize a page in both parent and child categories, so I would prefer them to only be in the sub-categories (there's others too, like reflexive and non-infinitive forms). I think the parent Category:Spanish verbs should still exist, just as an umbrella category (and to handle appendix pages and such). --Bequw → ¢ • τ 23:49, 7 February 2008 (UTC)

In the past people have argued that all words should appear in the primary POS category. I never completely understood why; I am merely pointing out that people argued for this when the POS categories were initially set up and the inflection templates developed. --EncycloPetey 00:09, 8 February 2008 (UTC)

Hmm... nice but in my mind a bit overwhelming. FYI, I was taking my categorization cues from 'pedia: w:Wikipedia:Categorization#How to categorize an article --Bequw → ¢ • τ 19:55, 9 February 2008 (UTC)

Categorization here is not done for the same reasons or with the same goals as Wikipedia. We are usually more concerned with semantic relations, for one. You cannot rely on their categorization principles as a guideline for categorizing here. --EncycloPetey 22:37, 9 February 2008 (UTC)

Translation bars

The discussion moved from the archive to the beginning of the next month since it was still unfinished, at the moment it's on Wiktionary:Beer parlour#Translation bars. Best regards Rhanyeia♥♫ 15:09, 14 April 2008 (UTC)

Vandalism warning

I received two vandalism warnings on my user page from Rtghhh because I added gloss to the translation table. Is this vandalism? --Panda10 21:44, 8 February 2008 (UTC)

Of course not, the user's being silly. --Keene 21:46, 8 February 2008 (UTC)

Right. Rtghhh has been blocked for attempted intimidation. Rod (A. Smith) 21:52, 8 February 2008 (UTC)

Can someone please take a look at what HotTea is doing? Archiving user pages and reverting recent changes? Thanks. --Panda10 20:14, 9 February 2008 (UTC)

Agree. --HotTea 20:17, 9 February 2008 (UTC)

It is needed. --HotTea 20:18, 9 February 2008 (UTC)

Please block that troll!!! Jcwf 20:29, 9 February 2008 (UTC)

• Please remember to use WT:VIP for these. (Sysops, please remember to watchlist that page.) --Connel MacKenzie 00:30, 10 February 2008 (UTC)

en-noun|- and category:Uncountable

There was discussion at the grease pit on modifying template en-noun so it would automatically categorize it into the category:Uncountable when it displayed uncoutnable because the plural was marked as "-". There was no objection. Is there any objection here to doing this? RJFJR 22:46, 9 February 2008 (UTC)

Is it possible to find out how many instances of "{{en-noun|-}}" and "{{uncountable}}" (or, better, entries with {{uncountable}}) there are in en.wt? I am also wondering what an orderly way to review the {{en-noun|-}} entries might be. Thoughts? DCDuring TALK 22:57, 9 February 2008 (UTC)

From grepping the xml dump, I found 8784 {{en-noun|- and 1596 {{uncountable of which 1507 appeared to be English (they lacked a lang= parameter). Conrad.Irwin 08:32, 10 February 2008 (UTC)

Thanks. And there must also be literal "uncountables" too, not necessarily in the uncountables category. Those would probably have the highest total payoff from hand editing, wouldn't they? Can I use search to make my own maintenance list or do I need to get help? If I would need to refresh myself on grepping, that would not be impossible and has other payoffs. DCDuring TALK 10:32, 10 February 2008 (UTC)

Nothing should ever be placed in Category:Uncountable, since that is a badly-named category. The correct category should be Category:English uncountable nouns, specifying both language and part of speech. --EncycloPetey 22:08, 10 February 2008 (UTC)

I agree with EncycloPetey, and the {{countable}} and {{uncountable}} templates need to be updated to use context in a way similar to {{idiom}} so that they give: Language uncountable nouns etc.--Williamsayers79 12:48, 11 February 2008 (UTC)

Was a decision reached on this? RJFJR 13:10, 6 March 2008 (UTC)

User:Keenebot2 for bot status

Hi all, I finally managed to make a working bot - I've been trying for months, but now it's fine... I've given the bot 4 verbs to feed on so far, and have checked every entry, and tweaked the code each time to stop it from looking funny. I think it's "perfect" now, but want approval (from Pythoneers, ELE-heads and French grammarians mainly) to check I haven't missed anything. I could add feminines and plurals to the present and participles sections, but apart from that, it's all looking ready, and I guess the next step is to give it approved bot status, for which I'll start a vote soon. Anyway, I won't run it again until I get bot status or additional tests need to run--Keene 23:17, 9 February 2008 (UTC)

Looks good, though I have always been iffy with links in "form of" templates. I'd also appreciate if it could use {{fr-verb-form}} (even though it partly duplicates the category of {{fr-def-verbform}}, which I assume you use, if there is ever a decision to reformat these entries, having it already applied would be a boon). Circeus 01:10, 10 February 2008 (UTC)

{{form of}} doesn't do anything much different than using non-templated writing, but it saves a bit of time when writing the code. As for {{fr-verb-form}}, I'll add that into the file instead of {PAGENAME}[Category:French verb forms]. As for {{fr-def-verbform}}, there's no wiklinks in it so I'm not so keen on using it (or I could just wikify that template, but it wouldn't make much of a difference because it has to be subst's anyway. --Keene 09:45, 10 February 2008 (UTC)

On second thought, it's true that {{fr-def-verbform}} does not readily work for generation from a given page, and only works for the basic conjugation (I think you could take a separate list of endings and feed the verb to the bot and get the result, but I don't know enough about programming to tell how practical that is). The point is really that (a) I fail to see the point with links in "form of" templates, especially given that multiple identical links are very common in your format because of many homographs in all conjugations (the only time were I can see a case is for "past historic"), and (b) we have 2 completely different automatically generated styles for verb forms (e.g. 1st- and 3rd- or 2nd-person are merged to a single line if they are identical in my format). Circeus 17:53, 10 February 2008 (UTC)

Separating them makes it possible to add examples for each sense. Lmaltier 21:03, 10 February 2008 (UTC)

This is true, but be aware that I'm not going to add examples. That's so incredibly far off the scope of what this bot was meant to do. Of course, in the future others might add examples, but not me. --Keene 21:56, 10 February 2008 (UTC)

I'm with Keene on this. Whetehr or not to change the current non-lemma entries is irrelevant to my points. Circeus 23:21, 10 February 2008 (UTC)

Does your bot work for all verbs, or only the 1st group? Also note that:

• present participles have no plural or feminine forms. Past participles have plural and feminine forms, but not for all verbs.

  Replied at User talk:Lmaltier. --Keene 09:45, 10 February 2008 (UTC)

  I've added 3 more sections to the end of the code, so they can easily be removed if necessary - see matée, matés and matées. --Keene 10:27, 10 February 2008 (UTC)

• many verbs follow special rules (e.g. -cer, -ger, -ayer, -oyer, -eter, -eler, -é.er and e.er... verbs)

  I understand that, and recently users have been tagging all the French verbs with these templates, which can be found at Wiktionary:French inflection templates. My first run will be for all pages that link to {{fr-conj-er}}, and then I'll work my way through the other templates (changing the bot code to get the right spelling/grammar etc. each time of course). When it comes to the extremely irregular verbs, I'm not sure what I'll do...but we'll worry about that later. --Keene 09:45, 10 February 2008 (UTC)

• you could add pronunciations

Lmaltier 09:03, 10 February 2008 (UTC)

• Not yet. That'll be a whole new project altogether, so unless someone writes me the code for that I'll skip it this time round. someone else wrote the bulk of the code for Keenebot2's first mission anyway. --Keene 09:45, 10 February 2008 (UTC)

Another problem found - see matas, where the French section is after the Spanish section - what extra code would I have to add to sort that out? --Keene 10:11, 10 February 2008 (UTC)

You would need to read the page, sort it alphabetically by language and then add the French at the correct position, its probably just easier to get the bot to tell you when a page exists and do these manually. Possibly the easiest way to get the pronunciation is to read the fr.wikt version of the page, but again it would require some coding Conrad.Irwin 14:23, 10 February 2008 (UTC)

You don't need to do anything to get the language sections sorted, look at matas now. The magic is that the code you already have adds {{rfc-auto}} when it is appending a language section ;-) Robert Ullmann 14:29, 10 February 2008 (UTC)

Awesome. Me and AutoFormat make a good team. Even less work for me, hooray! (which, of course, is the main reason for this bot - ironically, to give me less work to do, although I guess it will give me a lot more work to do, but that work will not take as long). --Keene 15:55, 10 February 2008 (UTC)

• I started a vote, hopefully not prematurely, at Wiktionary:Votes/bt-2008-02/User:Keenebot2 for bot status. --Keene 10:38, 10 February 2008 (UTC)

WordNet license

As far as I can tell this issue has not been actively discussed since 2004. However, people keep trying to add WordNet stuff here, and WordNet is strong in a number of areas where we are currently quite weak. For those who don't know, WordNet [5] is a world-class lexical database with professionally-written definitions and example sentences. I had been operating under the assumption that the WordNet license was incompatible with the GFDL, but upon looking closely at the WordNet 3.0 license, I'm not sure that's true. On the other hand, the license would require us to link any Wordnet-derived entries to a verbatim copy of the license terms (at least that's how I read it). So, questions:

• 1. Is the Wordnet license compatible with the GFDL, and with our preferred way of doing things on Wiktionary?
• 2. If so, what is the best way of labeling Wordnet-derived entries in a license-compatible way? (I'm assuming a {{from wordnet}} footer or some such)
• 2a. If not, what is the best way of locating and annihilating the Wordnet copyvios that are lurking around the project (which I would guess are in the hundreds)?

Note: Well-formed entries submitted with a mismatched example sentence (i.e. where the example sentence is actually for a synonym of the word) are very likely to have been lifted from WordNet. If not deleted, these definitely need to be tagged somehow so we can keep track of them. -- Visviva 08:08, 12 February 2008 (UTC)

According to someone on IRC their license isn't actually compatible with the GFDL as they demand copyright be given to them in perpetuity, so any contributors would not get any rights in the way of the GFDL. However I do think that this would be a good idea if we can find a way to make it work. Conrad.Irwin 12:39, 14 February 2008 (UTC)

Number translations

I think you should number each translation of a word, according to each definition. --Jorge Moraleh 200.86.56.124 21:05, 12 February 2008 (UTC)

Unfortunately, the numbers can change (though it happens rather rarely). Instead we usually have a heading around each section of translation for each sense. See for example beetle which has a section for each of the three noun definitions. RJFJR 21:08, 12 February 2008 (UTC)

It would be easier to find the translation you need if they had numbers... it's more complicated in words with a lot of definitions. And in the case you add some definition, you should change the numeration too. --Jorge Moraleh 200.86.56.124 00:24, 13 February 2008 (UTC)

We used to have numbers, it didn't work very well. That was why we decided to use the glosses - even if the definitions change a bit, or move around a bit they are still recognizable. With numbers, one edit can break the whole page accidentally. Conrad.Irwin 00:27, 13 February 2008 (UTC)

And if we had numbers and glosses? --Jorge Moraleh 200.86.56.124 00:43, 13 February 2008 (UTC)

Then the glosses would always be right, and the numbers would sometimes be wrong. DAVilla 01:10, 13 February 2008 (UTC)

See also Help:How to check translations. DAVilla 01:08, 13 February 2008 (UTC)

Block reason: stupidity

What is the procedure to have "stupidity" removed as a reason from the dropdown? Discuss it here and then have a vote? RJFJR 21:14, 12 February 2008 (UTC)

See the discussion under #Blocking above. It seems possible that it will go to vote, though if we can get consensus here first it won't be necessary. Conrad.Irwin 21:20, 12 February 2008 (UTC)

Compound tenses in conjugation templates

I've noticed that {{fr-conj}} includes various compound tenses in the table, which increases the length of the table while adding information which does not change from verb to verb. Of the other major Romance languages, only the Italian templates have a similar behaviour, while the templates for Portuguese, Spanish, Catalan and Romanian are restricted to simple tenses. Given that Romance languages have a fairly large number of simple tenses (8–10) and relatively complicated conjugations, I would propose that the templates only include simple tenses and that information about most compound tenses be relegated to an Appendix for each language. Wadda people think? Physchim62 17:09, 13 February 2008 (UTC)

Have you seen {{fr-conj-er}}? That has loads more tenses, including the subjunctive surcomposed pluperfect which pretty much doesn't exist at any level in French. As for whether to include all compound tenses, I reckon it doesn no harm to do that - I'd rather see all Romance languages having as much information as possible in the templates, than to cut information out of a couple so they're the same size as others. --Keene 17:22, 13 February 2008 (UTC)

An appendix explaining how, when, where... each tense is used would be helpful. But I feel that the {{fr-conj-er}} is OK. All reference books list compound tenses in their conjugation tables (generally fewer tenses, but it is useful to be as complete as possible here, with an exception for forms such as être sur le point de ..., venir juste de ..., etc. (they can be considered as tenses, but they are very easy to use, and are never listed in conjugation tables). Lmaltier 21:52, 13 February 2008 (UTC)

While it's on my mind, {{en-verb}} could be modified to add compound tenses? In theory we could add present perfect, past perfect continuous, future perfect, present continuous, all the passives to {{en-verb}}...and why not the archaic -eths and -ests and -t suffixes too, just for good measure? --Keene 22:03, 13 February 2008 (UTC)s

The fact that reference books for verb conjugation list compound tenses has more to do with the economics of distributing deadtree information than on the usefulness of that information—it is proportionally more expensive to produce small books than slightly larger ones. French dictionaries, where space is at more of a premium, do not list compound tenses for each verb. {{fr-conj-er}} is, IMHO, ridiculous: the table is so large that it becomes difficult to find, say, the present subjunctive. It also incorporates the OR definition of the conditional as a separate mood. All templates translate the French gérondif (always regular in its formation from the present participle) as the English gerund when it has a completely different grammatical function. Quite frankly, it's a mess. Physchim62 14:45, 14 February 2008 (UTC)

Including every compound tense form of a word in a conjugation table isn't necessary in conjugation templates, although they should definitely all be somewhere (like appendices). They aren't useful in templates that appear for every word for beginners, because they probably won't know how to use them. They won't be useful for advanced speakers because they'll already know how to make the compound tenses.

The French "gérondif" shouldn't really be included in templates. It's just the present participle with en. — [ ric ] opiaterein — 20:36, 14 February 2008 (UTC)

Well, compound tenses are very usual in French (more than in English), especially passé composé, and usual compound tenses are taught in schools, it's not an economic issue. I don't know the right term to be used in English for en aimant. In conjugation tables, this form is much less useful than compound tenses. Lmaltier 21:12, 14 February 2008 (UTC)

en aimant is gerundive, aimant is the present participle. (I'm about 90% sure on this) — [ ric ] opiaterein — 00:40, 15 February 2008 (UTC)

Aimant is certainly a present participle (though it's sometimes — rarely — called a "gerund"), but I don't think there's one standard English term for what en aimant is. "Gerund" and "gerundive" seem to be the leading candidates. I'm pro-"gerundive", personally, as it's the most like the French. —Ruakh_TALK 01:30, 15 February 2008 (UTC)

"en aimant" is a construction of a preposition with the present perticiple: note that its formation is completely regular once you know the present participle. It is called a gérondif in French, but has a grammatical function which is quite different from that of the gerund in English or Latin. It is a waste of space in these tables. Physchim62 12:00, 15 February 2008 (UTC)

For your consideration: two existing templates, {{fr-conj}} and {{fr-conj-er}}, and my proposition for a more rational conjugation table. Physchim62 12:00, 15 February 2008 (UTC)

   Conjugation table: chanter (fr-conj)

		simple			compound
infinitive		chanter			avoir chanté
gerund		en chantant			en ayant chanté
present participle		chantant
past participle		chanté
person		singular			plural
		first	second	third	first	second	third
indicative		je (j')	tu	il	nous	vous	ils
simple tenses	present	chante	chantes	chante	chantons	chantez	chantent
	imperfect	chantais	chantais	chantait	chantions	chantiez	chantaient
	past historic	chantai	chantas	chanta	chantâmes	chantâtes	chantèrent
	future	chanterai	chanteras	chantera	chanterons	chanterez	chanteront
	conditional	chanterais	chanterais	chanterait	chanterions	chanteriez	chanteraient
compound tenses	present perfect	Use the present tense of avoir followed by the past participle
	pluperfect	Use the imperfect tense of avoir followed by the past participle
	past anterior	Use the past historic tense of avoir followed by the past participle
	future perfect	Use the future tense of avoir followed by the past participle
	conditional perfect	Use the conditional tense of avoir followed by the past participle
subjunctive		que je (j')	que tu	qu'il	que nous	que vous	qu'ils
simple tenses	present	chante	chantes	chante	chantions	chantiez	chantent
	imperfect	chantasse	chantasses	chantât	chantassions	chantassiez	chantassent
compound tenses	past	Use the present subjunctive of avoir followed by the past participle
	pluperfect	Use the imperfect subjunctive of avoir followed by the past participle
imperative		-	tu	-	nous	vous	-
		—	chante	—	chantons	chantez	—

   Conjugation table: chanter (fr-conj-er)

		present			past
infinitive		chanter			avoir chanté
gerund		en chantant			en ayant chanté
participle		chantant			chanté
					ayant chanté
person		singular			plural
		first	second	third	first	second	third
indicative		je (j')	tu	il (elle)	nous	vous	ils (elles)
simple tenses	present	chante	chantes	chante	chantons	chantez	chantent
	imperfect	chantais	chantais	chantait	chantions	chantiez	chantaient
	simple past	chantai	chantas	chanta	chantâmes	chantâtes	chantèrent
	simple future	chanterai	chanteras	chantera	chanterons	chanterez	chanteront
compound tenses	composed past	ai chanté	as chanté	a chanté	avons chanté	avez chanté	ont chanté
	pluperfect	avais chanté	avais chanté	avait chanté	avions chanté	aviez chanté	avaient chanté
	past anterior	eus chanté	eus chanté	eut chanté	eûmes chanté	eûtes chanté	eurent chanté
	future anterior	aurai chanté	auras chanté	aura chanté	aurons chanté	aurez chanté	auront chanté
surcomposed tenses	surcomposed past	ai eu chanté	as eu chanté	a eu chanté	avons eu chanté	avez eu chanté	ont eu chanté
	surcomposed pluperfect	avais eu chanté	avais eu chanté	avait eu chanté	avions eu chanté	aviez eu chanté	avaient eu chanté
	surcomposed past anterior	eus eu chanté	eus eu chanté	eut eu chanté	eûmes eu chanté	eûtes eu chanté	eurent eu chanté
	surcomposed future anterior	aurai eu chanté	auras eu chanté	aura eu chanté	aurons eu chanté	aurez eu chanté	auront eu chanté
conditional		je (j')	tu	il (elle)	nous	vous	ils (elles)
simple tenses	present	chanterais	chanterais	chanterait	chanterions	chanteriez	chanteraient
compound tenses	past (1st form)	aurais chanté	aurais chanté	aurait chanté	aurions chanté	auriez chanté	auraient chanté
	past (2nd form)	eusse chanté	eusses chanté	eût chanté	eussions chanté	eussiez chanté	eussent chanté
surcomposed tenses	surcomposed past (1st form)	aurais eu chanté	aurais eu chanté	aurait eu chanté	aurions eu chanté	auriez eu chanté	auraient eu chanté
	surcomposed past (2nd form)	eusse eu chanté	eusses eu chanté	eût eu chanté	eussions eu chanté	eussiez eu chanté	eussent eu chanté
subjunctive		que je (j')	que tu	qu'il (elle)	que nous	que vous	qu'ils (elles)
simple tenses	present	chante	chantes	chante	chantions	chantiez	chantent
	imperfect	chantasse	chantasses	chantât	chantassions	chantassiez	chantassent
compound tenses	past	aie chanté	aies chanté	ait chanté	ayons chanté	ayez chanté	aient chanté
	pluperfect	eusse chanté	eusses chanté	eût chanté	eussions chanté	eussiez chanté	eussent chanté
surcomposed tenses	surcomposed past	aie eu chanté	aies eu chanté	ait eu chanté	ayons eu chanté	ayez eu chanté	aient eu chanté
	surcomposed pluperfect	eusse eu chanté	eusses eu chanté	eût eu chanté	eussions eu chanté	eussiez eu chanté	eussent eu chanté
imperative		-	tu	-	nous	vous	-
simple tenses	present		chante		chantons	chantez
compound tenses	past		aie chanté		ayons chanté	ayez chanté
surcomposed tenses	surcomposed past		aie eu chanté		ayons eu chanté	ayez eu chanté

  Conjugation of chanter (proposed)

infinitive	chanter
present participle	chantant
past participle	chanté
person	singular			plural
	first	second	third	first	second	third
indicative	je (j')	tu	il	nous	vous	ils
present	chante	chantes	chante	chantons	chantez	chantent
imperfect	chantais	chantais	chantait	chantions	chantiez	chantaient
past historic	chantai	chantas	chanta	chantâmes	chantâtes	chantèrent
future	chanterai	chanteras	chantera	chanterons	chanterez	chanteront
conditional	chanterais	chanterais	chanterait	chanterions	chanteriez	chanteraient
compound tenses	Use the appropriate tense of avoir followed by the past participle
subjunctive	que je (j')	que tu	qu'il	que nous	que vous	qu'ils
present	chante	chantes	chante	chantions	chantiez	chantent
imperfect	chantasse	chantasses	chantât	chantassions	chantassiez	chantassent
imperative	-	tu	-	nous	vous	-
	—	chante	—	chantons	chantez	—

Note that the second header contains a link: you'd never guess it, would you? (Edited. DAVilla 18:17, 16 February 2008 (UTC))

If you think that everything you propose to remove is useless, you must speak French better than me. But it may help all normal users. It could be possible to keep everything, but to change the order to make it easier to consult. Lmaltier 18:08, 15 February 2008 (UTC)

I am all for including everything, there was a similar discussion about Ancient Greek verbs and it was decided that we need a more selective way of showing/hiding parts of table. This would make the default view earier and smaller, but the rest of the word could be shown by expanding again. (GP: As of yet there has been no work on the javascript that would be needed, but I think we would have to add a class name to sections of the table and show/hide by dynamically adding rules to the stylesheet - instead of iterating over the DOM) Conrad.Irwin 11:42, 17 February 2008 (UTC)

E-mails to inactive users

• See also: Wiktionary:Votes/2008-02/Reprimand of User:Connel MacKenzie#Email DAVilla

This issue has come up in the context of a vote to reprimand someone because a number of us were e-mailed to solicit our input. The importance of this goes beyond that specific reprimand vote. Wikimedians tend to drift from one project to another for a number of often benign reasons. It can be for as simple a reason as becoming involved in a lengthy personal task on a sister project. That we thus become involved in the other Wiki's culture does not mean that we have abandoned Wiktionary altogether.

Some may view such notices as spam, but those individuals should have the opportunity to opt out. To those who would oppose such mailings as canvassing for votes, sending out a general notice that is neutrally worded to a pre-determined list of people is certainly preferable to sending out to a select list of those whom one believes to have compatible opinions.

Another advantage of such mailings is that it could encourage experienced wiktionarians back into participation. The simple act of commenting on the then current issue, rather than just casting a simple evil vote, can, by the one-thing-leads-to-another principle, draw people into editing other articles that may have nothing to do with that current issue.

I agree that the notice should go to all who have given an e-mail address, and particularly to inactive bureaucrats and administrators since this group tends to have a deeper understanding of the project. Any with a long term ban for cause would naturally be excluded. In the early days a boilerplate statement could be attached telling the recipient how he may opt out. This is preferable to using the mailing list because the number of those subscribing to the mailing list. Even the high-traffic wiki-en list only has a tiny fraction of the Wikipedia admins participating.

I don't believe that every vote should be advertised. It would be pointles for an inactive person to vote on the adminship of a person that he knows nothing about. The same could be said of most disciplinary issues, but as has been the case with this recent incident, the inactive users may be able to provide some insights when the discipline is sought to be applied to a person with a very long history in the project. Major policy decisions should certainly have the broader participation; decisions with a limited impact should probably not. Nevertheless it is nearly impossible to establish a clear demarcation line. Perhaps if any five Wiktionarians irrespective of the side of the then issue that they support want something brough to that wider community that would be enough. Yes, there are opportunities for abuse in that, but I would be loath to presume that abuse until it becomes an actuality. Eclecticology 19:45, 13 February 2008 (UTC)

I dislike this idea in principle; that is, I think people should be invited to join in an important discussion, but once that discussion has gelled to a point where voting is prudent, there is no particular value in inviting people who are disengaged from the project to come and pass judgment. On the other hand, the consequences of the current vote have been ... interesting, and perhaps even constructive. So this may be an OK idea, really. -- Visviva 03:49, 14 February 2008 (UTC)

---

• Moved from here. DAVilla 03:28, 14 February 2008 (UTC)

I don't have a large concern about the mechanism of setting up a new mailing list; I trust that it would be done in a reasonable manner, presumably as a function of the WMF mailing list architecture that we already have. (Wiktionary-en-votes-l, right?) Whether a new list is set up or not, I still think the fact that we haven't been announcing them (all) on wiktionary-l is a little embarrassing. Certainly, every vote held is relevant to that list's subscribers. And it would greatly increase the trust we have in these votes, if we had more participation. If a new list is created, its first subscriber should be mailto:wiktionary-l. That is, one list would be "votes only (opt-in)" while the other would be already is "all things Wiktionary, also including votes (opt-in)." --Connel MacKenzie 05:36, 13 February 2008 (UTC) (edit) 20:16, 13 February 2008 (UTC)

I disagree with emailing people in general, we should be able to make up our minds without needed to call in reinforcements - in cases of close call input from others may be valuable, but the chances are that there is a better solution that hasn't yet been found. If we are going to have such a mailing list, then it should be en.wiktionary specific, we shouldn't spam all of the other Wiktionarians with what is going on here by sending it to mailto:wiktionary-l Conrad.Irwin 12:36, 14 February 2008 (UTC)

I wouldn't call them "reinforcements" unless the proposed technique is being misused to push a point of view. Chances are indeed that a better solution has not been found, and the missing better solution is not limited to close-call situations. If the herd instinct sets in better solutions are often ignored. Of course the new list should be en-wiktionary specific. Other Wiktionaries are autonomous and set their own policies, which will often be quite different. It would essentially be a closed notification list. If a recipient has a comment he would put it on-wiki at a page to which he would be given a link.

A votes only notification that would invite only a bare yes/no vote would defeat the purpose of the idea: getting different perspectives on an issue. Notices would need to be sent well before the issue got to the voting stage. Subscribing the existing mailing list is fine. Despite being inactive I have maintained my subscription to it, but the traffic these is very var removed from what I would call spam. Eclecticology 07:27, 15 February 2008 (UTC)

Overenthusiastic patrolling

I notice that I don't need to mark nearly as many edits as patrolled lately. Sysops are generally doing a fine job. However, it is important not to mark bad edits as patrolled - that way rubbish will creep in to the wiki. I just found a patrolled entry (prusik) that didn't even have a ==language== heading. (Will barnstars make the situation worse or better?) SemperBlotto 22:17, 15 February 2008 (UTC)

I was under the impression that patrols are simply verifying that the patrolled edit is not *vandalism*, have we started to use them in some other way? - [The]DaveRoss 22:20, 15 February 2008 (UTC)

My understanding is that marking an edit as patrolled means that it looks reasonable, and no other sysop needs to bother to look at it. But if there are obvious errors (either of fact, formatting or whatever) and the sysop can't or hasn't the time to correct them, then he should just leav it unmarked. SemperBlotto 22:25, 15 February 2008 (UTC)

I second that, though I tend to mark foreign language and translation edits as patrolled if they are formatted correctly even though I have no easy way to verify the factual accuracy. That shows up an interesting thing with RatPatrol though, as it has re-marked the edit as patrolled due to your (as a sysop) trusted 'fix' - even though the edit had been previously patrolled and it was not fixed. Conrad.Irwin 22:31, 15 February 2008 (UTC)

How difficult would it be to add a checkbox at the bottom of the edit page for admins, that would allow the admin to mark or unmark (edit:) not mark all previous edits as patrolled, with the default specified in a preference? Could that me made to work at least for admins who are running rat patrol, if not all admins? DAVilla 01:00, 16 February 2008 (UTC)

Not overly, though it is quite an intensive process for javascript, first the history has to be loaded and then each necessary patrol link visited, so doing it in the background while the user is editing is probably preferably, though then again if wikt is being slow and the user being fast it still won't finish. Conrad.Irwin 16:08, 16 February 2008 (UTC) Oops, misread, it is not at all possible to unmark edits as far as I know. Conrad.Irwin 16:11, 16 February 2008 (UTC)

What platform does rat patrol run on? Could the javascript simply inform rat patrol of the setting? I.e. rat patrol would not simply assume that the page has been checked in entirety, but would rely on information that the admin provides via the checkbox, which could default to either preference. DAVilla 18:04, 16 February 2008 (UTC)

Rat patrol was written in Python by Robert Ullmann, I am sure we could have a list of sysops for ratpatrol not to auto-patrol if they wanted it, but it is a very useful feature. Conrad.Irwin 18:20, 16 February 2008 (UTC)

My question is this: we have several mechanisms for verifying the proper formatting of an entry, checking the language heading and section headings, why are we using the patrol feature for that task as well? - [The]DaveRoss 22:42, 15 February 2008 (UTC)

For things that they do fix, it is fine to mark as patrolled - but there are some things which they can't work out by themselves. Conrad.Irwin 22:51, 15 February 2008 (UTC)

It doesn't matter whether they can fix the error, only whether they can recognize it (assuming they add cleanup categories to entries with recognizable errors). That said, I don't mark changes patrolled unless they were O.K., or their problems have since been fixed, or their problems have since been tagged; I'd rather not rely on our tools hitting every single edit. —Ruakh_TALK 23:26, 15 February 2008 (UTC)

Agreed. If a sysop sees a glaring error in the entry, they should either fix it, rfv it, rfd it, etc, or leave it unmarked. Generally with foreign language entries, I've been marking them if the format is reasonable, having no way to validate the information (however, as I think about it, when we have a sysop covering a specific language, it might be best to let them look at it instead). That being said, I think I may have marked the entry in question, actually. I just didn't notice the lack of language header (in my defense, I did do a quick google search to verify that the definition was a reasonable one). Sorry about that. :( Atelaes 23:33, 15 February 2008 (UTC)

Wasn't you, according to the log. (Special:Log/patrol can be filtered by page.) But your contrition is appreciated. :-) -- Visviva 04:31, 16 February 2008 (UTC)

• This sounds to me like normal growing pains - we've all made similar errors along the way. But yes, such an entry should have {{subst:nolanguage}} added (or better: fixed) before it is marked as patrolled. --Connel MacKenzie 18:03, 17 February 2008 (UTC)

  (what's with using * on comments? I see it more and more) If an entry with no language header is patrolled, AF will add the {nolanguage} box (unless it already has {wikify}. Robert Ullmann 16:58, 18 February 2008 (UTC)

  (My comments were not in response to any individual comment, but to the whole topic more broadly. So a ":" didn't really make sense this time. --Connel MacKenzie 05:25, 22 February 2008 (UTC))

Constructed languages straw poll

At the moment, we have two constructed languages which seem to be reasonable contenders for inclusion in Wiktionary. These are Lingua Franca Nova and Toki Pona. Both languages have a number of terms currently in the main namespace, though Toki Pona does not have an ISO code. I'd like to find out what community feeling is on possible inclusion of these languages without the rigor of going through a vote at this time. If it looks like we have consensus one one or both languages, then we can have a quick vote to amend WT:CFI accordingly, and if not then we'll have a sense for how people want to handle these languages.

For each language, you can: give Full Support for inclusion in the main namespace (like we do for Lojban and Novial); Restrict the language to an appendix (as we do for Klingon and Quenya); Oppose inclusion at all; or Abstain (though preferably stating whether you're undecided, don't care, or would just go along with whatever everyone else says). --EncycloPetey 04:21, 16 February 2008 (UTC)

I'm not sure "oppose" would have any meaning here - CFI is purposefully vague about Appendixes. --Connel MacKenzie 17:55, 17 February 2008 (UTC)

Poll on Lingua Franca Nova

• Abstain, as in I'll go along with whatever the community feels; I have no strong opinions either way. --EncycloPetey 04:21, 16 February 2008 (UTC)
• Restrict Atelaes 05:14, 16 February 2008 (UTC) As well as Lojban and Novial. To be honest, I wouldn't have a problem with putting Esperanto in an appendix, but I think I'm in the minority on that one. Atelaes 09:11, 16 February 2008 (UTC)
• Restrict. Nothing against either of these, but I think our mandate of all words in all languages is quite broad enough, without including invented languages. I'm not sure we really need Lojban or Novial in the mainspace either, frankly. Having these in the mainspace just adds to the already heavy burden on maintenance work, and distracts us from our core mission. -- Visviva 05:19, 16 February 2008 (UTC)
• Restrict. (also Lojban or Novial) - SemperBlotto 08:04, 16 February 2008 (UTC)
• Full Support Wiktionary could quite easily become the ultimate reference for such languages, lets encourage them. Conrad.Irwin 12:12, 16 February 2008 (UTC)
• Permit per Conrad.Irwin, but it goes without saying that we're not going to loosen CFI to help such languages get coverage. If the LFN word for "desk" isn't used in three books, it has no place in Wiktionary. (In fact, I'd be O.K. with treating LFN words as having already failed RFV once — as in, if we came across an LFN word without enough quotations to prove it meets CFI, we'd delete it on sight.) And it goes without saying that if only three books have been written in LFN, we're not going to copyvio the heck out of them to extract every single word we can. —Ruakh_TALK 15:37, 16 February 2008 (UTC)

  I like this idea; I could definitely live with allowing conlang words iff they are already fitted out with three durable citations for each sense. I think that would actually be tantamount to "Restrict" in these cases, but if not, so much the better. -- Visviva 16:01, 16 February 2008 (UTC)

  That would be the same as full inclusion, since the three citation rule applies in such cases anyway. All I'm looking into with this straw poll is whether we might have consensus on whether to include/exclude (and how). Right now CFI says of LFN that it has "not yet been approved for inclusion", and says that "There is no apparent consensus for including" Toki Pona. I'd just rather we had a position on these languages than a lack of position. --EncycloPetey 16:59, 16 February 2008 (UTC)

  It would be the same as full inclusion, except that we don't normally require that three citations already be present in an entry in order to avoid immediate deletion. There is a de facto presumption of innocence for words that are otherwise unsuspicious; as I understand it, Ruakh is suggesting that conlang entries be presumed guilty. This makes sense to me, since it is a lot harder to tell the difference between "invented" and "real" words when one is dealing with an invented language. If we can be sure (or as sure as we ever are) that words in a conlang have actually been used communicatively, then the distinction between conlangs and real languages becomes less important. However, for me to support including constructed languages on this basis, the distinction would need to be written into policy somewhere, presumably the CFI. -- Visviva 04:57, 18 February 2008 (UTC)

  That's how I read Ruakh also, and I don't like it. I have no (strong) opinion on including or not including words in these languages, but I think speedily deleting any that has no cites is almost tantamount to rejecting inclusion of these languages outright: the vest, vast majority of editors will not add cites with their first edit, if at all, even to words that are perfectly acceptable (to the extent these languages are acceptable at all, I mean).—msh210℠ 17:40, 20 February 2008 (UTC)

  Fair enough, though TBH, newbie editors who don't know our policies and are just coming to promulgate their favorite conlang probably aren't going to be following RFV (unless you think the usual verifiers will try to verify words in conlangs?). —Ruakh_TALK 00:38, 21 February 2008 (UTC)

• Abstain I'll go along with whatever (for both langs). --Bequw → ¢ • τ 16:38, 17 February 2008 (UTC)
• Abstain I care what the community concludes, but could care less whether we have it or not. --Connel MacKenzie 17:55, 17 February 2008 (UTC) Well, except for copyvio concerns, that is. --Connel MacKenzie 17:57, 17 February 2008 (UTC)
• Full Support as per Conrad Irwin above. I was going to go for Restrict, but this was based on discussions from a long, long time ago. Our current CFI should quite nicely weed out inconsequential conlangs and leave us with those with enough use to merit our attention. In which case, I'd also (hesitantly) move for inclusion of (at least) Klingon and (maybe) Quenya in the main namespace under those conditions - it evens things up better, IMO. Of course, these would have to be citations of the language in use, not descriptions of the language, which will probably be very hard to find in print for these two (and for most conlangs), and thus I'm happy with it. --Wytukaze 03:29, 18 February 2008 (UTC)
• Restrict. An appendix is encouragement enough. bd2412 T 12:41, 25 February 2008 (UTC)

Poll on Toki Pona

• Full Support --EncycloPetey 04:21, 16 February 2008 (UTC)
• Restrict Atelaes 05:14, 16 February 2008 (UTC)
• Restrict Visviva 05:19, 16 February 2008 (UTC)
• Restrict. (also Lojban and Novial) - SemperBlotto 08:04, 16 February 2008 (UTC)
• Full Support I think Wiktionary would benefit from including as much as possible. Conrad.Irwin 12:12, 16 February 2008 (UTC)
• Abstain I care what the community concludes, but could care less whether we have it or not. --Connel MacKenzie 17:55, 17 February 2008 (UTC) Well, except for copyvio concerns, that is. --Connel MacKenzie 17:57, 17 February 2008 (UTC)
• Full Support as with LFN above. --Wytukaze 03:29, 18 February 2008 (UTC)

original words

warning wild speculation and spurious reasoning in use

From the origin of utterance to the meaning of meaning. Hey was probably the first spoken word of my laaguage. I have reasoned this out and will attest to this theory. Still with me? In not so sure bout this but, the next was not you, I think that came later in our evolution of thought. It may have been guys, or guise, since both meanings are relevant to the situation that would require a hey in the forst place. Could this be a case of a homonym predicating the etymology of word. do you like to think?

Plese cross post if you know anywhere this conversation would like to happen.TRKritzer 08:16, 17 February 2008 (UTC)

It is probably better suited to the Tea Room, but to be honest I an struggling to follow what you say. Hey, as it says in our etymology is likely to be a natural human sound, as it does occur in a lot of places. I think that the guys/guise is likely to have been much later - though we don't have an Etymology for either. Conrad.Irwin 11:38, 17 February 2008 (UTC)

perhaps I have taken the name beer parlour too literally.

) to continue, Hate was probably one of the earliest words, considering my language uses a hard ending so sometime after the domestication of the dog an before agriculture, our caveman ancestors sat around a fire and cooke meat. one member of the tribe was out, but his dog was there. As the dog sidled up to a peice of untended meat, the owner of that meat yelled hey to scare him off. When the dogs master returned, he was told "I heyed your dog, I hate him."TRKritzer 00:07, 18 February 2008 (UTC)

early word theories welcome.

Proposal: Protect Policy Pages (and Templates)

I propose that Official Policy Pages and Policy Templates be locked, as these pages should (as far as I understand) never be modified without a vote, or at the very least discussion.

Quoting the lede to Category:Wiktionary policies:

Minor spelling corrections to these pages, without prior discussion, may result in a one week block.

Thus, specifically, I suggest that:

• the official policies in Category:Wiktionary policies (note that many entries here are drafts or think tanks), and
• all the templates at Wiktionary:List of Policy Templates

be placed in Wiktionary:Protected titles, specifically a subpage which I propose calling Wiktionary:Protected titles/Policy pages and templates.

How does this sound?

Nbarth (email) (talk) 14:26, 17 February 2008 (UTC)

While I can agree with semi-protection (for policy pages) I am not so sure about sysop only protection. I am wary of this because the more of that we have the more we are saying "to do anything meaningful here you must become a sysop, and not everyone wants to be. We should maintain the highest degree of editable content we can, and reserve protection for what it was intended for, preventing vandalism. No one should get a 1 week block for fixing typos anywhere, often times lines like that exist simply because the person who wrote it wanted it to be inflammatory enough that other users discussed and edited the policy (I have done this myself). As for templates, many templates do deserve and are protected due to their widespread inclusion and the technical issues which arise from such inclusion, if you noticed other which probably deserve such protection please mention them here or on a sysop's talk page and they can be dealt with. I am toning down the language of that warning, reflecting more accurately the sentiment which it was intended to convey. - [The]DaveRoss 15:05, 17 February 2008 (UTC)

TheDave, as we discussed elsewhere, please undo that, or correct it. --Connel MacKenzie 17:43, 17 February 2008 (UTC)

Thank you. That wording works for me. --Connel MacKenzie 17:51, 17 February 2008 (UTC)

Per above changes to lede of Category:Wiktionary policies, should we make sure the wording in Template:policy accords, and/or is linked? For reference, the Category:Wiktionary policies lede reads:

Do not modify these pages without a prior discussion on WT:BP, followed by a (minimum) one month WT:VOTE. Even subtle or seemingly inconsequential changes to these pages may result in a block, so please discuss all changes prior to implementation.

...while the wording on Template:policy is:

This is a Wiktionary policy, guideline or common practices page. It should not be modified without a VOTE.

I suggest that "It should not be modified without a VOTE." be changed to "It should not be modified in any way without a VOTE. (policy)"

Nbarth (email) (talk) 18:43, 17 February 2008 (UTC)

I oppose this strongly. The entire concept of immutable policies is anti-wiki, and as can readily be seen it leads to having "policies" that are hopelessly out of step with current practice. This in turn contributes to the opacity of the project, which is already a very serious problem. Suggest {{policy}} should read "it should not be modified substantially without community discussion" instead. There is no reason that the wiki process cannot work just as well for policy pages as it does for everything else we do. -- Visviva 05:04, 18 February 2008 (UTC)

Concur, at least in part... It may be reasonable to semi-protect them temporarily in the case of vandalization, but other than that all participants should be able to fix typos, grammar (being careful not to alter meaning), some cases of format etc. Also, when a change has been discussed and agreed or non-controversial, anyone in the discussion should be able to update them. Further, a very reasonable way to be specific about a change (e.g. setting up a precise vote) is to make the change, and revert it, thus creating a version in the history and diff that can be referred to. I would use the word "materially" rather than "substantially", very small changes may be quite radical. Conversely, at least one recent change to ELE was made to reflect current practice, with no issues arising. Robert Ullmann 16:47, 18 February 2008 (UTC)

I feel that the current situation is adequate, the wording is fine: If I read a page that says "Do not modify without a WT:VOTE" then that is what I do (or don't do). Though I would like to improve the appearance of the templates a little, grey border round blue is "so last year" Conrad.Irwin 17:13, 18 February 2008 (UTC)

Transwiki

Wikibooks has some stuff for import: b:Special:Prefixindex/Common phrases in various languages. I don't think you have it already. Please let us know when the import is done. – Mike.lifeguard | ^@en.wb 16:45, 18 February 2008 (UTC)

(would you kindly use the + tab on the top of the page when adding a section, instead of editing the last section? I just got a totally unnecessary edit conflict. And it won't like like a contrib to that section in the history. Thanks.) Robert Ullmann 16:49, 18 February 2008 (UTC)

Looks to me like this one got skipped over? – Mike.lifeguard | ^@en.wb 05:00, 5 March 2008 (UTC)

Lies, Damned Lies, and Statistics

I'm not one to overly value the article count shown for a wiki, or be too concerned about the race between en.wikt and fr.wikt. It is best to keep such things in perspective.

That said, I have noted while running many scans through XML dumps, recording statistics, that there are what appear to be discrepancies at first glance. The total number of entries in namespace 0 is well over 700K, yet we have 682K entries?

The differences are:

• redirects don't count (30K+)
• entries without links that are "soft" redirects for things like misspellings don't count (as Connel argues, they probably shouldn't)
• some entries that are sub-minimal "form of" redirects don't count (Jyril[Bot] has created 11K+ of these on the way to being filled in)
• some entries simply have no wikilinks in definitions or categories, and need help

This last class numbers just a bit over 2000 right now (2015), and each could use some TLC. Wikilink the definition lines, add appropriate templates and categories, and it adds one to the count.

Okay—you don't care about that—they can still use that help: User:Robert Ullmann/Not counted

Thank you for your time and attention. Robert Ullmann 02:06, 19 February 2008 (UTC)

I've started on some of those. Oddly enough, I had already touched up 'cos back in December. Circeus 05:32, 19 February 2008 (UTC)

There is another phenominon that affects languages that use non-western scripts. In Chinese for example, the same word may be written in either simplified or traditional script. If both forms were to receive separate entries (the current recommended practice), wiki statistics would count those as two distinct words, making it appear that Wiktionary has far more Chinese words than is actually the case. -- A-cai 11:47, 19 February 2008 (UTC)

Yes ... but the count isn't "words" anyway. It is entries with unique spellings. If one were to count words, the entry at do should count as 24 words, but it counts as one entry. Robert Ullmann 12:07, 19 February 2008 (UTC)

If one counts language sections, there are 780,013 in the en.wikt. Robert Ullmann 11:52, 21 February 2008 (UTC)

When was the list last run? To clarify, simply being in a category, for example, as a product of {{en-noun}} doesn't help, only "hard-coded" categories, right? DCDuring TALK 11:58, 19 February 2008 (UTC)

It was run on the 13 February XML dump. The wiki statistics count entries that contain "[[". (!) So a directly coded link or cat will make it count. I think this list is a bit more important in that most of these entries can use some help one way or another, whether they count or not. Robert Ullmann 12:07, 19 February 2008 (UTC)

Almost all the lists have that characteristic, even old WOTDs!!! I use templates to help me standardize entry appearance (human and bot PoV), but sometimes forget about WLs and sometimes remove redundant categories, so I may add to the list!!! No more. DCDuring TALK 12:16, 19 February 2008 (UTC)

If [[ is what does it, then how about adding <!--[[--> to form-of entries?—msh210℠ 16:52, 19 February 2008 (UTC)

In the purported words of a former PoTUS: "We could do that, but that would be wrong." We should try to add at least some value in the course of improving the numbers. Is there a useful categorization of alt. forms? Should be add skip-some-clicks direct links to lemma forms or to related words with root etymologies? DCDuring TALK 17:23, 19 February 2008 (UTC)

Mostly it is about wikilinks in definitions, of which there should always be at least one. Robert Ullmann 11:52, 21 February 2008 (UTC)

Feedback: Simplicity and Metadata

One of the early indications from the Feedback from the anons would seem to be that some of them find some of our definitions unhelpful because they are too complicated. I'm sure there are many factors that make for the perceived complication, but one aid in reviewing entries for their complexity would be some metadata about the entry that was readily searchable of, alternatively, a number of lists of entries that seemed to score high on "complexity" measures. Some of the metrics might article length in bytes, number of English PoSs, number of senses, number of etymons, number of L2, L3, L4, L5, and total headings. Finally something like a readability index for each sense or PoS. This would enable us to correlate feedback with metadata possibly and would enable us to structure lists of problem entries based on "simplicity scores".

I've also noted that print dictionaries (Macmillan comes to mind) sometimes have tiers of complexity in the same entry, with compact gloss-like simple definitions. Are there any "understandability" indexes for English words that suggest what portion of users are likely to have a firm grasp of a word used in a definition? DCDuring TALK 13:14, 20 February 2008 (UTC)

If the ToC were actually useful in itself as a meaningful summary of the entry as well as allowing one-touch expansion, we would have an information interface that was superior in user info-gathering efficiency to the current interfaces of the other on-line dictionaries. Since the meaning necessarily starts with the definitions, it would certainly force the data to be presented at DAVilla has organized. Cosmetic changes, such as variable (on average, shorter) bar lengths and larger "show" click targets would be important, but apparently easy. Pictures would have to be hidden to increase compactness. Why wouldn't both passive users and wiktionarians likelove this ? DCDuring TALK 11:12, 21 February 2008 (UTC)

I've noticed that there are some English entries with 9 definitions which are all incredibly similar to each other. That might have been part of what they were talking about with the definitions being too complicated. (Then that complication gets carried over to translation tables. Makes a mess.) — [ ric ] opiaterein — 13:43, 20 February 2008 (UTC)

I think we need to be more rigorous in keeping sub-senses into one line. For example balloon defs 2 and 3 are just examples of def 1, though they are worthy of note they aren't really seperate meanings. Conrad.Irwin 13:54, 20 February 2008 (UTC)

Is there a role for something like the rel templates to by default hide length and complexity (long definitions, sense-specifc synonyms, usage notes, and even translations). I wonder how much of the perceived complexity is because we still force users to run their eyes over a lot of text (sometimes multiple screens) to find whether what they want is on the page. And, once they have found a sense that corresponds to what they are looking for, they have to jump elsewhere to see whether we have synonyms and antonyms and translations. A user would have to either be highly motivated or expert to do all that. I would think that once a user has found a sense that might be what was wanted, then all of the sense-specific information should be in close proximity. DCDuring TALK 15:13, 20 February 2008 (UTC)

I agree with that, part of the motivation behind the WT:PREF (Conrad's buggy paper view), I would like to integrate something like that into wikt by default - but it needs improvements, (I would like specific ideas, instead of generalizations though :). Ideally we could be doing that through php, and have an inverse processor to allow editing to happen more comfortably. Conrad.Irwin 15:20, 20 February 2008 (UTC)

Yeah, I'd really like definitions to come first. Even kill or alter the TOC so you don't have to scroll down. And put everything related to a sense together, as in this example. DAVilla 04:11, 21 February 2008 (UTC)

I really like the idea of having the definitions big like that, would it work having them in the headings themselves, so that the table of contents becomes, in effect, the summary of definitions, and then people can click on them to find out more (we might need to play around with the CSS to make it looking a bit better, but it should be doable). Conrad.Irwin 10:15, 21 February 2008 (UTC)

If the ToC were actually useful in itself as a meaningful summary of the entry as well as allowing one-touch expansion, we would have an information interface that was superior in user info-gathering efficiency to the current interfaces of the other on-line dictionaries. Since the meaning necessarily starts with the definitions, it would certainly force the data to be presented at DAVilla has organized. Cosmetic changes, such as variable (on average, shorter) bar lengths and larger "show" click targets would be important, but apparently easy. Pictures would have to be hidden to increase compactness. Why wouldn't both passive users and wiktionarians likelove this ? DCDuring TALK 11:14, 21 February 2008 (UTC)

I'm in favor of a reorg generally, but I can think of at least two reasons not to be thrilled with this: 1) This would require every existing entry to be rewritten, and I expect any attempt to automate the process would run into serious problems. It would therefore leave the project in format limbo for a period of several months at the very least. 2) The section titles would be unstable; every time someone revised a definition any old links pointing to that definition would become invalid. The basic idea here is good, but I'm not sure this is exactly the best approach. -- Visviva 11:21, 21 February 2008 (UTC)

Yes, it would take a couple of months, however I am fairly sure [from experience] this could be successfully automated in 99.5% of cases - (still leaving us with a couple of thousand to do by hand :( ). However, I think that some kind of change is going to be necessary, and so little more needs to be said about the "We apologise for the inconvenience" stage - though the casual visitor may not notice, .

How to handle links to specific definitions is still a problem we have not yet solved, and is unlikely to be solvable by using the inbuilt headings. What we should be able to do is have a {{keyword|Link Keyword}} Template:keyword in defintions see(#Link Keyword created in this fashion), and then allow links to #keyword. This would be doable however our entries are formatted. By allowing the keyword to be hidden if the definition is changed, the links can remain consistent - though the hope would be that a keyword would be an essential part of the definition. (Maybe this should be broken into a seperate section) Conrad.Irwin 12:01, 21 February 2008 (UTC)

Yeah, break this one off.

One important factor would be to incorporate the language in the anchor. Often words can have synonymous meanings between different languages, so there would be no other means to distinguish them anyway. Another useful utility would be to have more than one way to access the definition line, so that rather than always substituting one label for another, changes are for the most part cumulative.

There are various ways I could see to link the definitions. One would be to have a standard set of keywords, much like we have a standard set of context labels—in fact the two may overlap. I could link to #English (finance) or #English (person) or #English (company). The problem with linking part of the definition, like money, is that it is, and should be, subject to change. AHD defines principal as "The capital or main body of an estate or financial holding as distinguished from the interest or revenue from it." No money. On the other hand, there may be several definitions to which "finance" or "person" or "company" apply.

Another possibility is to use synonyms, particularly those that apply to only one sense, e.g. #English: capital, #English: headmaster or #English: superintendent working equally well, and #English: representee or whatever the appropriate term is. The main problem here is that the substance of the anchor is provided below the definition line, not at the same point to which it should lead. On the other hand, it is worth working the technical issues out since it could be broadened to allow other words that narrow down the definition, e.g. #English: money and #English: administrator.

It's worth testing these ideas out independently and narrowing down the options because allowing compound labels like #en: (finance) investment could lead to several hundred or more labels for a single definition line. DAVilla 17:13, 22 February 2008 (UTC)

I would love to see an example page that has definitions in the TOC and employs CSS rather than hacking the wikitext to achieve the desired result. I'm not afraid of selecting a design in the end that requires even an extension to the software, e.g. to count {{{#}}}'s in order to number the definitions. In fact, there are a number of software extensions I can think of that would already be useful, such as obtaining the level-2 header. DAVilla 17:23, 22 February 2008 (UTC)

• You remember lead/experiment2 right? Going from today's ELE to DAVilla's proposal would be too large of a shock to the existing automation tools in use. While the "Definitions" section of lead/experiment2 is different, it has a lot of benefits: existing tools are not at disrupted, new users can enter definitions even when they don't know the POS (making it easier for others to clean up) and the essential structure is close to today's format. The notion of interleaving the sub-data within the definitions can only lead right back to where we are today: pages of intervening noise. Having glosses as headings, mean that other pages can reference the gloss they mean exactly. But including the part of speech in the gloss is unwise and misleading. Having some Javascript that floats up related expansion boxes (related terms, synonyms, translations, etc.) is a SMOC, if (and only 'if') someone prefers that alternate view. --Connel MacKenzie 05:11, 22 February 2008 (UTC)
• P.S. DAVilla did something weird to clip the glosses from the TOC by crushing it into a too-small space on the right...I think that is very, very unwise. And strange. And really, inexplicable. If you are going to use the TOC, then do something that exaggerates its benefits, not its deficiencies. --Connel MacKenzie 05:11, 22 February 2008 (UTC)

The problem is that the existing layout would flunk a user-oriented web-design course if offered by a student as a project. It succeeds fine from the point of view of experienced active contributors. If the TOC actually provided gloss information for all senses, then it would accomplish all that was required. lead/experiment2 at the moment does not offer the important part of end-user improvement. DCDuring TALK 10:07, 22 February 2008 (UTC)

<rant>Firstly I find this constant "we must not annoy the bots" very irritating, if we continue down that line we will never go anywhere - and I think most people agree that what we do now isn't perfect. I also find people attacking minor details about good proposals a bit petty, though in some cases it is much harder to describe the real underlying issues.</rant>

To not match the information and the definitions together means that the bots must try and match them up by guesswork. Though this is normally very successful even when the glosses no longer match exactly it can fail badly. Having all the information in sense related sections also means that the reader knows instantly what information we have about each sense, for example - with lead/experiment2 once I am reading a definition there is no way to get to the translations without heading for my scrollbar, hoping I can remember the gloss and trying to find the right translation table to open.

One `possible` issue might be that the senses are pushed apart as the amount of information increases, however if the definitions are in the table of contents then that can be used as a summary of the definitions, and clicking on the definition gives you the rest of the information. This will not work (just like the glosses will not work for inter-page linking, as these are very tempting to change. For the same reason I don't know whether the keyword idea above will work).

We are not going to achieve any form of consensus over what looks best, as there is no way that everyone agrees on what looks nice (see the Logo debate :( ), however I think that we can do better than lead/experiment2 and better than DAVilla/trunk - though both of those are "much" better than vanilla Wiktionary. Let us not forget that a lot of the written Feedback we have got thus far has said SIMPLIFY.

One issue that isn't handled well by either experiment is the handling of pronunciation and etymology and inflection; or sections that can be applied to more than one sense, but not necessarily all senses. We have two choices, we either try and do it hierarchically like the current system (which works well though looks very ugly), or we try and link from each sense to the appropriate section (or transclude the appropriate section) - which doesn't work that well and probably looks just as ugly. If we can find a nice looking easy solution to this problem then (imo) we have solved Wiktionary. Conrad.Irwin 12:34, 22 February 2008 (UTC)

My thoughts on the matter are that our structure (as seen from the edit window) is actually quite good. It makes for an orderly arrangement, with a lot of nested information. It has been refined over a long period of time, and can handle a great deal of diversity from various languages (obviously a requisite for a multilingual dictionary). I see no reason to alter it. What we need to alter is not the structure, but rather how that structure is translated into the user view. The problem with DAVilla's example is that it does not take a complex, difficult to read entry and make it into an elegant and simple entry, but rather it takes an already simply entry, cuts out a lot of good information (what happened to all but the one definition?) and puts it in a useless structure without any benefits in usability as far as I can see. As far as the arguments about bot readability go, I think that we need to maintain a structure which bots can read (although not necessarily that "current" bots can read). Quite simply, bots do far too much work for us to simply let them die. I think that Conrad.Irwin's paper view is really the way we should be heading (although it still needs some work). I think that it will quickly get us to the point where we have no need of TOC's. In short, the solution (in my view) is to work with the existing structure and work on how we translate that structure into the view the user sees. -Atelaes λάλει ἐμοί 14:04, 22 February 2008 (UTC)

How would we know that it is good from the point of view of someone other than us?

A wiki is designed to facilitate content entry from people like us. It so happens that the vanilla wiki framework works reasonably well for encyclopedic context. The required structure is not very elaborate and is not very technical. Many people can make contributions or at least feel as if they are making contributions.

In contrast, we have a lot of structure which is not as easy to learn and, partially for that reason, we have we have a very small number of active contributors. So the net result is that we have this amazing resource which is great for us, but is not likely to be working very well for normal users.

1. Our user numbers are quite small compared to WP,
2. Many of our users come from there.
3. We have little evidence that our small base of normal users is happy and
4. Our interface violates received principles for what normal users would need.

If we only want a resource for us, then we don't need to change. It is only if we want to serve a larger user base that we would need to change. DCDuring TALK 15:22, 22 February 2008 (UTC)

Alexa shows a gradual growth rate, and yes, most Wiktionarians first experience Wikipedia. I think Conrad.Irwin's recent demonstration (WT:PREFS paper view) show that as we achieve data consistency, more presentation niceties can be added. The next level, is to add input wizards. But our internal formats still are too inconsistent. --Connel MacKenzie 01:48, 2 March 2008 (UTC)

Regarding lead/experiment2 - I stopped at "show the way" as I figured it showed enough of the concept...yes, the intent is to have all the glosses in the TOC. Shall I revisit it and finish that for the sake of completeness? --Connel MacKenzie 01:48, 2 March 2008 (UTC)

en-verb for when simple past and past participle are identical

Can we have {{en-verb|foos|fooing|fooed}} expand to to foo (third-person singular simple present foos, present participle fooing, simple past and past participle fooed) instead of to to foo (third-person singular simple present foos, present participle fooing, simple past fooed, past participle fooed)?—msh210℠ 07:51, 5 February 2008 (UTC)

• Support. Rod (A. Smith) 17:23, 5 February 2008 (UTC)

Preceding was moved from template talk:en-verb.—msh210℠ 23:09, 20 February 2008 (UTC)

Isn't that more common than the alternatives? - [The]DaveRoss 23:29, 20 February 2008 (UTC)

• Support. One less visual redlink per en-verb for most verbs and verb phrases. DCDuring TALK 23:33, 20 February 2008 (UTC)

Support. —Ruakh_TALK 00:33, 21 February 2008 (UTC)

I agree that this should be, but I can't offer to do it myself - sorry. Conrad.Irwin 10:54, 21 February 2008 (UTC)

Anything that simplifies entries has my Support. -- Algrif 18:06, 21 February 2008 (UTC)

Support -- Thisis0 05:29, 22 February 2008 (UTC)

Support. Am I late to the party? bd2412 T 03:24, 28 February 2008 (UTC)

This has now been implemented, so if you notice that it isn't working... Conrad.Irwin 00:31, 29 February 2008 (UTC)

Language categories as topics

I've been trying to clean up Category:Japanese language for the last few days and I wanted to get a second opinion on something. Most of the things I've removed from Category:Japanese language were clear-cut errors or seeming holdovers from an earlier way of doing things. However, I've also run across some things that are actually words about the Japanese language itself, like ローマ字 (rōmaji). I've changed a few of these by putting them into Category:ja:Grammar or Category:ja:Linguistics, but I wanted to get some opinions before doing all of them.

I poked around language categories for a couple other language and didn't see any other examples of this, but I could see something like Great Vowel Shift belonging in a topical category about the English language (for example). I guess my personal feeling is that the existing language categories are not topic categories, but I also feel that the whole situation with language v. topical v. functional/lexicon categories is a bit confusing right now. I'd kind of like to see topical categories completely split from language/functional categories, including putting the English topical categories under "en:*", but I haven't fully made up my mind what I think should happen. Mike Dillon 03:15, 21 February 2008 (UTC)

I agree with your position as I understand it. However, if there are a lot of such terms, it might be best to create a special Category:ja:Japanese linguistics, which would be a subcategory of Category:ja:Linguistics. —Ruakh_TALK 03:19, 21 February 2008 (UTC)

Stephen has argued that the full name of a language should be used. One idea would be to put the English word romaji in Category:Grammar (English) and Category:Japanese grammar (English), and the Japanese words ローマ字 and rōmaji in Category:Grammar (Japanese) and Category:Japanese grammar (Japanese). Thames would go in Category:English rivers (English) and its translation 日本語テムズ川 in Category:English rivers (Japanese). DAVilla 04:43, 21 February 2008 (UTC)

The translation of Thames is テムズ川, apparently. 日本語 is the Japanese word for the Japanese language :) That being said, I don't really have a strong feeling one way or the other about changing the prefixes to parentheticals... I guess it makes it more approachable for people without a background in computing or linguistics, which is probably most of our readership (I have both, so the ISO codes don't really phase me). Mike Dillon 04:54, 21 February 2008 (UTC)

Woops, how'd I manage to do that? DAVilla 23:30, 22 February 2008 (UTC)

I don't for the life of me understand why this is so confusing to people. (e.g. DAVilla's comment, in which he completely misses Stephen's point, that "ru:Idioms" is wrong, it should be "Russian idioms", while "Russian mountains" would be mountains in Russia, and Category:ru:Mountains is mountains in Russian). It is absolutely crystal clear. Category "Japanese nouns" is nouns in Japanese. "ja:Nouns" would be Japanese words about nouns. ローマ字 goes in Japanese nouns (it is a noun) and ja:Linguistics (it is a Japanese word about a lingustics topic). (Please don't create ja:Japanese linguistics, it will confuse the f--k out of everyone; ja:Japanese prefectures is bad enough. You couldn't just do ja:Prefectures?) テムズ川 can go in Category:ja:Rivers, we don't need to do encyclopaedic categorization, now do we? If it must be done, it would go in "ja:English rivers", but this is not Wikipedia. Robert Ullmann 11:44, 21 February 2008 (UTC)

Hey now, I'm not putting words into Stephen's mouth. I didn't say that what I wrote was his idea, only that he'd argued for using the full names and not the codes. The point you make I don't remember who came up with, but anyways what on earth is wrong with addressing it the way I did? DAVilla 23:36, 22 February 2008 (UTC)

Hmm... Category:ja:Prefectures? What about Category:US States and children? Should they just be Category:States or is that OK because "US" can't be confused with a language? Would you prefer Category:ja:Prefectures of Japan, or should these all just collapse into Category:Political subdivisions or Category:Place names? I'm being slightly facetious and I agree that we don't need to be encyclopedic about this, but Category:ja:Japanese prefectures makes sense to me.

Before I started cleaning up that particular mess, we had Japanese words in Category:Japanese prefectures and we had a dozen subcategories with less than 10 words a piece for prefectures in individual areas of Japan... At least now we can put the English names in Category:Japanese prefectures, although I'm thinking more and more that we should call this Category:en:Japanese prefectures and do the same with all topic categories. The only thing holding me back from adopting this opinion is that I think all of this language code stuff is overly nuanced and unapproachable for casual users of Wiktionary. Mike Dillon 16:43, 21 February 2008 (UTC)

Well, you could call it Category:Prefectures of Japan, couldn't you? We made a deliberate and conscious decision long ago to never have en: in our category names, because this is the English Wiktionary. So there's one more thing that should be holding you back from creating that category. --EncycloPetey 04:46, 22 February 2008 (UTC)

Yeah, when I saw you taking 名詞 (noun) out of the Language cat, I got to thinking and realized we don't really need to have any actual words in there. Thanks for your hard work. Cynewulf 04:45, 21 February 2008 (UTC)

Yes, is good to at least get the words that aren't related to the Japanese language itself out; when I started in on this almost all of the words were in this cat (if catted at all ;-). Thanks. Robert Ullmann 11:44, 21 February 2008 (UTC)

Latin infinitives

There is a project underway to move the major description of Latin verbs from the infinitive to the first person singular present tenss. I don't mind that. But shouldn't the infinitive be properly formatted? Most often it is marked for deletion (see vitare as an example). That can't be right, surely. SemperBlotto 22:24, 21 February 2008 (UTC)

See a previous discussion where this seems to be the feeling also. Conrad.Irwin 22:27, 21 February 2008 (UTC)

We now have {{conjugation of}} for these pages. See amare#Latin for an example in use. --EncycloPetey 18:02, 1 March 2008 (UTC)

Examples for other sources of quotations

It would be nice if the section on Quotations contained some examples of quotations from magazines and other periodicals. The examples there now are limited to books. - dougher 08:24, 22 February 2008 (UTC)

Many of our quotations come via the Google book search. But ALL printed material is acceptable as a source of quotations - if you can find them. SemperBlotto 14:08, 22 February 2008 (UTC)

Further to SB's point, Google News and Google Scholar both have a lot of material from periodicals, but gaining sufficient access to determine context when required often requires a subscription or a payment. As a result we use these sources and usenet mostly when gutenberg, wikisource, and google.books.com fail us. DCDuring TALK 15:29, 22 February 2008 (UTC)

Personally, I don't shy away from using blogs if it gets me good citations. Circeus 16:02, 22 February 2008 (UTC)

I thought they were deemed not "durably archived". Though they are a good indication of some leading-edge uses. DCDuring TALK 16:05, 22 February 2008 (UTC)

I assume if a blog posting dates from 2004 and is still around, it's archived durably enough. Should the post vanish, the quotation can always be taken out AFAIAC. Circeus 00:47, 24 February 2008 (UTC)

Absolutely not. As a blog's life-expectancy is inversely proportional to its age. Similarly, raw web pages drop off, after having been around for years. Published texts, OTOH, are archived reliably. --Connel MacKenzie 02:03, 2 March 2008 (UTC)

I assume that Doug Hockin actually refers to the help page. As the format cannot be exactly the same, I support his suggestion: examples would be helpful. Lmaltier 21:27, 22 February 2008 (UTC)

Yeah, and add to that a play and a Usenet quote. And even the ones from books should push the envelope a bit: sources where the exact year isn't known, or which were translated into English, or which are quoted within another source. DAVilla 23:12, 22 February 2008 (UTC)

Muke made the assertion that Google's archive of Usenet (not being Evil, and all that) should constitute "durably archived." In the past two years that we've accepted them, I've seen a lot of really questionable material entered here, from Usenet. The intent originally was to have editorially reviewed publications, which Usenet obviously is not. It's a bit late to close the barn door now, but I'd still like to see all such entries (passing RFV only by merit of Usenet citations) tagged somehow as being restricted to very informal contexts. --Connel MacKenzie 02:03, 2 March 2008 (UTC)

Agree, this would be a good idea. There is sort of a grey scale of dubiosity, from terms attested only on Usenet to those where two solid book citations are supplemented by one Usenet cite; but all such terms should probably be flagged in some way. -- Visviva 04:20, 8 March 2008 (UTC)

No, I wouldn't want to completely turn back from Usenet, but I have suggested that, although the citations my support existence of a term, because that source is not edited, at the vary least it shouldn't count toward a particular spelling. The whole point of this someday upcoming vote was to tighten the criteria by weighing quotations on reliability, with Usenet coming in at or near the bottom. I had put that in terms of "print", but "reviewed" is also a good measure if it can be defined well. DAVilla 04:54, 7 April 2008 (UTC)

A lot of newspapers have durably archived, free to use, searchable data bases on the net. I use them a lot, as their entries are up-to-date and relevant. -- Algrif 18:47, 29 February 2008 (UTC)

The trick with that, is knowing which web-searches return results for actual printed newspapers. Many websites have news feeds that evaporate just as quickly as regular web pages. Even searching NYTimes is problematic, as some articles are "web-only." --Connel MacKenzie 02:03, 2 March 2008 (UTC)

I'm afraid maintaining the red line between print and electronic media is going to become impossible within a few years; it is already extraordinarily difficult, since we must rely primarily on electronic editions of print media in our verification work. Sooner or later, we will need to revisit exactly what is meant by "durable" (and "edited"). Certainly some electronic media are as durable as (or more durable than) some print media. -- Visviva 04:20, 8 March 2008 (UTC)

I have drafted {{quote-newsgroup}}, which uses the same basic approach as {{quote-book}} while following the rough framework of w:Template:cite newsgroup. At this writing it is used only in the 1997 quote in galactophagous. Since we haven't had a clear guideline for Usenet cites, I have gone along with the ways that I have observed people modifying Usenet citations that I have added in the past. Modifications from template and style mavens are welcome (since I am neither). -- Visviva 04:20, 8 March 2008 (UTC)

WT:BOT

After reading WT:BOT, I wasn't 100% sure about something. For a bot to be flagged, does the botmaster have to set up a vote for every single task it is doing? According to the vote for User:Keenebot2, the vote was only for auto-adding French verb forms. If I were to branch out in the future into other languages, would I have to set up and pass a new vote for each language whose verbs I plan to add conjugated forms of? --Keene 09:15, 23 February 2008 (UTC)

Once you've proven your bot's worth with French verb-form entries, I think you could set up a more general "Now that I've proven my bot's worth with French verb-form entries, I'd like permission to do the same with other languages and other parts of speech" vote. As long as you had some sort of plan in place for making sure that your bot is behaving correctly with languages you don't speak, I'd support that. (A completely different task would require a separate vote, though. And might be better done by a separate bot.) —Ruakh_TALK 14:02, 23 February 2008 (UTC)

Merriam Webster's "Open dictionary"

Anybody saw this? Basically, it's their urban dictionary, but although it does get some genuine aditon, 90% is just people throwing in random portmanteaus and stuff (e.g. "swellow", "ediot", "belaborate"). Circeus ~

Looks almost exactly equivalent to our List of protologisms, though longer and better UI. Conrad.Irwin 11:14, 25 February 2008 (UTC)

Except it's clearly not supposed to be. Circeus 19:07, 25 February 2008 (UTC)

redirections (for example, should Italian phrase entries redirect to the corresponding contraction entry?)

Suggestion from a newbie: I believe the as-yet-unwritten Italian così che entry (for example) should simply redirect to the existing Italian cosìcche entry. The existing così detto entry should redirect to the existing cosiddetto (or vice versa) so there's only 1 entry to maintain in each case. — This comment was unsigned.

• That's not the way we work here. Every word (or term) gets its own entry. (There a few exceptions for idiomatic phrases that can take multiple persons). SemperBlotto 22:22, 26 February 2008 (UTC)

Personally, I think the current setup is ideal. così detto is simply a soft redirect to cosiddetto. This means that important information is given at così detto, and yet the entry doesn't really need to be maintained. -Atelaes λάλει ἐμοί 22:26, 26 February 2008 (UTC)

Descriptions on Template:nav

Caveat: I know some people simply hate {{nav}}, but please restrain yourselves if you're just going to vent about that....

The category descriptions created the {{nav}} template are sometimes a bit awkward depending on the category name. User:Jyril and I recently added a "description" parameter to override the generated description for these cases. For example, without the override, the description for Category:Automotive was "The following is a list of $LANGNAME words related to automotive" (until I changed it). After giving a few awkward categories alternate descriptions, I'm happy with the new functionality, but I've found I have to repeat myself on every language subcategory.

Not being one to repeat myself unnecessarily, I'd like to fix this situation. Here's what I propose:

1. If a non-empty "description" is passed, it is used for the description without any further ado.
2. Then, {{nav}} does a check for a "/description" subpage of the base topical category, e.g. Category:Automotive/description.
3. If this subpage exists, it is assumed to be a template that accepts the "langname" and "current" parameters and it is called by {{nav}}, passing along those parameters.
4. If the subpage doesn't exist, {{nav}} does what it currently does.

This allows the description for the base topical category and the language-specific categories to be handled in one place instead of having to be copied/updated for each language. As an example, I would make the content of Category:Automotive/description something like this:

The following is a list of {{ #if: {{{langname|}}} | [[{{{langname}}}]] | }} words
related to [[automotive]] topics.

If people like this idea, I'll implement it and take a look at the existing uses of the "description" parameter. Mike Dillon 04:15, 27 February 2008 (UTC)

I just realized that this description template needs to be outside of the "Category" namespace or else it will be treated like a category itself. So the proposal needs to put them in the "Template" namespace with a similar naming convention, but the idea is the same. Mike Dillon 04:41, 27 February 2008 (UTC)

Thinking about this a little more, many of the variant cases could be covered by this variant on the default wording:

The following is a list of {{ #if: {{{langname|}}} | [[{{{langname}}}]] | }} words
related to {{#ifexist:{{lcfirst:{{{current}}}}}|[[{{lcfirst:{{{current}}}}}]]|{{lcfirst:{{{current}}}}}}} topics.

If that is indeed the case, then most of the "variants" could be template redirects to a shared alternate format, further decreasing maintenance. Mike Dillon 04:18, 27 February 2008 (UTC)

I shall refrain from simply "venting." The main problems with {{nav}} revolve around how brittle this "solution" is - it seems that every time the slightest little thing on the MW software side, something else breaks because of nav. Drastically increasing its complexity doesn't seem like a good idea; eliminating it does. --Connel MacKenzie 06:36, 27 February 2008 (UTC)

I don't think {{nav}} is particularly useful for navigation either, but I do think it is useful for keeping some consistency between potentially dozens of copy-cat per-language categories. I'd probably go so far as to make it so that both the description and the parent categories are centralized in one place in the ideal solution. I could take or leave the navigation element of the template, but I also hate having to repeatedly do the same work for category parentage and for customizing descriptions. Don't repeat yourself... Mike Dillon 16:22, 27 February 2008 (UTC)

I wonder if this should be on the Grease Pit, on the grounds that I have no idea what you're saying. Widsith 09:14, 27 February 2008 (UTC)

Perhaps. Feel free to move it, but I've found the Grease Pit can be a little too cloistered. The bottom line is that I'm proposing a mechanism to avoid repeating myself for each language when maintaining descriptions for topic categories. Mike Dillon 16:24, 27 February 2008 (UTC)

And while you're at it - could you (or anybody else) please also add the default value for langname= parameter to be transcluded from {{language|{{{lang}}}}}. --Ivan Štambuk 15:53, 27 February 2008 (UTC)

I was thinking this too. Mike Dillon 16:24, 27 February 2008 (UTC)

I can't say that I care one way or the other about {{nav}}'s existence, but if we're going to have it, your idea sounds like a good one. I say go for it. —Ruakh_TALK 01:40, 28 February 2008 (UTC)

I created Template:nav description, Template:nav description/default, Template:nav description/default with the, and Template:nav description/default with topics. They are demonstrated at User:Mike Dillon/nav description test. Mike Dillon 05:45, 28 February 2008 (UTC)

Here's a more complete demo of the behavior of an updated {{nav}} with lang-to-langname mapping and the description functionality: User:Mike Dillon/nav test. Mike Dillon 08:00, 28 February 2008 (UTC)

Well<rant>, if we've got to have silly templates everywhere,</rant> this is not a bad suggestion. <rant>I don't believe for a moment that it will actually be used but, ho hum, it's not dangerous or destructive. <rant level=higher>I would point out that, as things stand, xx:*Topics is not a root category, it is an alphabetical listing of all topic categories for a given language.</rant></rant> Physchim62 16:28, 28 February 2008 (UTC)

It's a good thing you bring up the flattening thing. Currently, Category:*Topics does not have all of the sub-topics flattened into it, but the language-specific ones do. I personally think the flattening kind of sucks, but I don't know whether this arrangement was the result of a past consensus. As it stands, my prototype code treats Category:*Topics the same as the language-specific ones, so they will all be flattened. It's easy enough to make things go the other way, but I can't see any reason for there to be a distinction in the parent/child structure between the language-specific and English/root Category:*Topics category. Mike Dillon 17:36, 28 February 2008 (UTC)

The flattening is a result of lack of clear decision on exactly how xx:*Topics should be structured. I'm not sure we've had a discussion on that issue in the past three years. --EncycloPetey 18:01, 1 March 2008 (UTC)

Heh - I was going to say 2.5 years. IIRC, the "flattening" concept wasn't even floated, at the time. --Connel MacKenzie 02:07, 2 March 2008 (UTC)

I think the foreign-language flattening into "Category:lang:*Topics" happened recently, but before that foreign language topic categories were flattened into "Category:LANGNAME language". Mike Dillon 02:52, 2 March 2008 (UTC)

Topic category flattening

I just wanted to add a couple of data points about flattening. I wrote some code to pull the entire tree of categories under *Topics because I was curious to see what it looks like. After adding in some "stop categories" for things that seems like incorrect structure to me, like "Languages" -> "Extinct languages" -> "Latin language" or "Countries" -> "Canada" -> "Languages of Canada" -> "English language", I was left with something on the order of 1000 English/base topical categories. Limiting to a depth of 3, it's somewhere around 600. It seems like a distinctly bad idea to me to flatten all of these into Category:*Topics. On the other hand, our current category graph, insofar as it's possible to visualize it, is about 8 levels deep and very wide. I may try using another graphing package to see if I can get a decent radial graph of it. Not sure if I have a point, I just wanted to give some info since I don't anyone has a very clear picture of the totality of these categories. Mike Dillon 18:01, 2 March 2008 (UTC)

Category:Alphabets

And it's supracategory Category:Letters, symbols, and punctuation are a mess. I really feel uncomfortable seeing names such as Category:Phoenician alphabet or Category:Ugaritic alphabet (they're really pure abjads). There's no need to enforce loosley-defined meaning of alphabet of "a writing system" when one can use more precise linguistic terminology

So I was thinking of something like this:

• There's no need to use "X letters" for scripts used to write one language only; i.e. Category:Armenian alphabet should be used instead of Category:Armenian letters
• For language-agnostic scripts, it's OK to have "letters" or similar designations in title, so Category:Cyrillic letters, Category:Braille letters or Category:Devanagari are fine.
• Make Category:Syllabaries, Category:Logograms, Category:Abugidas Category:Abjads and classify other categories into them (basically mimicking the hierarchy of w:Template:Writing systems)

Questions arise such as:

• Do we really need to make distinction between the Category:Greek letters and Category:Ancient Greek letters, or should they be just mergeed into Category:Greek alphabet ?
• Should Category:Hebrew letters be instead Category:Hebrew abjad or Category:Hebrew alphabet (just like Category:Arabic alphabet)? --Ivan Štambuk 16:42, 27 February 2008 (UTC)

And Category:Romanian alphabet - should language-specific alphabet categories be allowed, if they don't have their own writing systems (i.e. just use Latin like Romanian)? The approach used for various other Latin-based and Cyrillic-based languages (where one letter has multiple =Language= sections), is just to categorize their master category (Category:Latin letters, Category:Cyrillic letters in these cases]) into Category:X language. --Ivan Štambuk 16:57, 27 February 2008 (UTC)

I think you’re going the right track here, go ahead. One thing I don’t like is your suggestion to make Armenian alphabet, because it is only used in that language. I prefer consistency there, having Armenian letters (why not?) H. (talk) 15:14, 16 March 2008 (UTC)

Wiktionary:CommonsTicker

Should we be checking each change to each Commons file to make sure it doesn't mess up our pages? (Connel, are you doing that? That seems to be what WT:DW says, but I'm not sure I'm reading it right.) If so, then should whoever checks the files be deleting them from the WT:CT page, or striking them through, or something, to show that they're done?—msh210℠ 22:29, 27 February 2008 (UTC)

Well, it wasn't working for so very long, that I'd all but forgotten about it. OTOH, CommonsDelinker has been working (quite well, at that) so CommonsTicker is now mostly (if not entirely) redundant. If you wish to strike them through or mark them complete/resolved/whatever, then by all means, please feel free. --Connel MacKenzie 02:11, 2 March 2008 (UTC)

Translation tables

Would it be technically feasible to create an empty translation table with a gloss when a new English entry is added to Wiktionary? One table for each sense, when the Save button is clicked. I've been working on adding glosses, trans tables, checktrans, ttbc, and I was just hoping that there is a solution to reduce this type of work. Thank you for your thoughts. --Panda10 13:46, 29 February 2008 (UTC)

Personally I would prefer that we not have such empty tables at all, and have been in the habit of removing them when I come across them; IMO translation tables should be present only when there are actual translations.

Aside from this, I would argue -- very strongly, although I'm afraid some of my fellow professional translators may disagree -- that there are many word senses for which it is not reasonably possible to have "translations" even in our usual rudimentary sense; we should not encourage translations sections to be added to entries such as like a cat on a hot tin roof. -- Visviva 14:01, 29 February 2008 (UTC)

Thanks for the feedback, Visviva. I hate to say this but I've been creating a lot of empty translation tables lately while trying to reduce the items on the Category:Requests for translation table cleanup. How should I go about this? Regarding the translations, I see it differently. If I am translating a text from English to another language, I would very much like to have the translation of expressions. I would even go further. I would like to see the translations of titles (books, movies) because they are not always translated literally and can be very helpful to a translator. --Panda10 14:20, 29 February 2008 (UTC)

I also create empty translation tables. The format is neither intuitive nor simple for non-English speakers who drop in only occasionally or just once to ass a translation. It is much better to have the tables ready for them, or we'll just have to mark the translation as "to be checked" later. That makes for unnecessary work and loses the wiki-power of many of our occasional contributors. --EncycloPetey 17:56, 1 March 2008 (UTC)

I think empty translation tables are good, but a little misleading. Perhaps stubbing in {{trreq|French}}, {{trreq|German}}, {{trreq|Spanish}} and {{trreq|Italian}} would work? (What are the top 18 languages that publishing houses typically target? TOP40 would be way, way, way too much. One or two would be too few.) --Connel MacKenzie 02:28, 2 March 2008 (UTC)

I could add those four in the future but this will mean the request for translation category for those languages will grow. Back to the original question, though: Would it be technically feasible and would it make sense to you to create these empty trans tables with code when a new English entry is saved? --Panda10 14:27, 2 March 2008 (UTC)

If memory serves, someone already wrote a subst-able template to do just that. However, I cannot remember what it was called. --EncycloPetey 21:55, 2 March 2008 (UTC)

You're probably thinking of {{trans11}}, though Special:Prefixindex/Template:trans shows some other like-minded ideas. (Can you think of an easier-to-remember name, though? The "11" refers to the maximum number of tables it supports, which doesn't strike me as its main characteristic.) —Ruakh_TALK 23:08, 2 March 2008 (UTC)

Excessive quotations

See equipoise. This seems to me like an excessive number of quotations and the timeline is over the top. It clutters up the entry. Am I alone? - dougher 03:36, 1 March 2008 (UTC)

I don't mind the number of quotations — without them it would be less clear that sense 1 is almost two separate senses — but agree about the timeline. And the whole thing would take significantly less space if the quotations were sorted under their respective definitions. —Ruakh_TALK 03:47, 1 March 2008 (UTC)

I agree with Ruakh's suggestions and have made these edits to this entry. As for how many quotations is enough, it's sort of like the old question "How long is a string?" My own rule of thumb (often not reliable) is to try to find one telling quotation from each century in which the word can be show to have been used. -- WikiPedant 04:09, 1 March 2008 (UTC)

Collecting lots and lots of quotations makes the entry more valuable for people coming for information about the word. However, they do clutter up the entry. That's why we have a separate namespace for situations where the lists grow too long. See listen for an example of a page with a separate Citations:listen page for the many quotations. --EncycloPetey 17:52, 1 March 2008 (UTC)

Agreed with sending citations to the citations namespace and linking them visibly. An example sentence per definition is appropriate, citations in NS:0 just take up lots of space. - [The]DaveRoss 18:08, 1 March 2008 (UTC)

I greatly dislike the separate subpages for quotations, because the practice violates one of the basic rules of good database management -- Do not create redundant fields in separate records. When subpages are used, the various senses have to be duplicated on a separate page and the senses in the main entry and the subpage then need to be kept in sync as updates occur (which becomes less and less likely as time progresses). What's really needed is an enhancement to the Wiktionary program code which will allow windows to be opened and closed in the space between senses (not possible right now). When and if we ever get this capability, translations should be distributed into separate windows under each sense as well. -- WikiPedant 19:08, 1 March 2008 (UTC)

Actually we can create collapsible sections, but the purpose of the Citations page isn't to clarify individual usage (that is the purpose of the example sentence) but to show usage over time of all senses. Our main concern should be usability and clarity of the information on the page. A huge number of quotes in the midst of the definitions makes it harder to see the information which is relevant there. - [The]DaveRoss 19:14, 1 March 2008 (UTC)

I agree with both Wikipedant and TheDaveRoss. If we are ever to become a serious dictionary, we need to make a habit of including masses of quotations. However, if we are ever to become a usable dictionary, all those quotes are going to make our entries long and difficult to read. Expanding and collapsing sections is a highly important feature currently in development. Until we get to that point, the Citations namespace is a useful compromise. -Atelaes λάλει ἐμοί 19:25, 1 March 2008 (UTC)

Another consideration is the recent sectional transclusion which makes us able to keep them on the Citations page and then, when it makes sense, transclude them in the appropriate places. - [The]DaveRoss 19:27, 1 March 2008 (UTC)

Actually, assuming I'm understanding you right, the collapsible-section thing works fine; see User:Ruakh/quotations for some example ideas of how it could look. However, when I brought it for discussion, one editor objected very strenuously, and only two commented in support, so I didn't take it any further. (You can see that discussion here if you're interested.) —Ruakh_TALK 20:13, 1 March 2008 (UTC)

Looks more like two opposed, two in support (in ignorance of how the Citations namespace is supposed to work, perhaps?) I'm sorry that you have misread my technical critiques as "very strenuous." But by "just fine" do you really mean "despite horrific, complicated syntax bound to ensnare anyone trying to decipher it" or "impossible to be parsed offline" or "breaks the majority of Javascript extensions available from Conrad.Irwin, Rod A Smith and Hippietrail in WT:PREFS" or just "likely to break randomly with WMF software changes?" Interleaving those items where you suggest is a bad alternate to the Citations: namespace. All "footnote" information about a definition (synonyms, antonyms, etymology, translations, examples, citations, trivia, derived terms, etc.) could be nested, but is not. It isn't something randomly happened upon; no paper dictionary does it that way, nor does any online dictionary. That type of interleaving is avoided fairly consistently because it is not intuitive to the reader. WikiPedant's complain about duplication is obtuse - that same duplication would (does) exist in every proposed solution so far, yet remains flexible if kept in the Citations: namespace. In the Citations: namespace, the citations can be free-form collections, or ordered by gloss, or prettified with timelines. --Connel MacKenzie 03:00, 2 March 2008 (UTC)

Well, if you want to be technical, it was something like two opposed, four or five in support (because I supported it, as did one or two editors who commented on user-talk pages but didn't join the BP conversation after your comments), but the reason I didn't take it further was specifically your very-strenuous-sounding objection, so that's what I mentioned here. (Incidentally, if your comments here don't represent strenuous objection, then I don't know what does. Your comments seem almost as strenuous as comments can get while remaining polite.) I never said "just fine", only "fine" — and yes, so far as I'm aware, it works fine, in that if we want to do this, we can. Your technical claims about it don't strike me as very plausible, to be honest, but as no one is re-proposing this, arguments for and against would seem to be academic at this point. —Ruakh_TALK 07:06, 2 March 2008 (UTC)

This is yet another "entry layout is borked" thread. At least the third in as many weeks. It seems to me that we want as many citations as possible, these allow people to see the word in use, giving context and credence to our definitions. Example sentences can only give context, and can seem obviously constructed in our search for brevity. Being a dictionary our primary aim should be to provide people with definitions, because this is, as far as I am aware, what a dictionary should be for. This implies, I think, that we should not have too much beyond definitions in the definitions section. We have the =Quotations= section and the Citations: namespace for putting them in, however the problem then is that they are not easily associable with the definitions they are supposed to be supporting. Of all the solutions proposed I actually like Ruakh's the best. (I think that the technical "problems" that were mentioned were fairly inconsequential, re-writing code is much quicker than rewriting Wiktionary, people are already accustomed to using templates - and the nonsense about W3C... We should surely fix our HTML so that we are using definition lists for definitions before we worry about pretending it is "right because it validates"). The Citations pages need to be linked more prominently, I would like to see the citations tab PREF turned on for everyone and for it to add a tab back to the entry. The =Quotations= section suffers the same problem as the rest of the page, it relies on the ugly glosses to tie itself together, there is no linking between them so when reading definitions their is no indication that Quotations are below.

Conrad.Irwin 12:33, 2 March 2008 (UTC)

Well, if we're proposing solutions, let me just mention -- again -- that if citations were uniformly formatted using templates which also assign a CSS class or classes, it would be easy for them to be hidden by default, or hideable by preference, without any disruption to existing entry layout conventions. And although I personally think that definitions without citations are perilously close to worthless, I have seen enough of the "if-three-is-good-then-ten-must-be-better" school of thought here that I am very sympathetic to those who would like to get them out of the way. . -- Visviva 13:09, 2 March 2008 (UTC)

Like Conrad.Irwin and Widsmith and others, I love Ruakh's proposed template, which creates collapsible sections between senses. Greatest thing since sliced bread, and I'm sorry I missed the original discussion last November. I prefer the formatting example #2 at User:Ruakh/quotations. I also agree with Visviva that a set of uniform formatting templates is desirable (and Visviva has created at least one, which formats citations from books). Ruakh's template should be moved out of his own user subpages and into the public portion of Wiktionary. -- WikiPedant 16:30, 2 March 2008 (UTC)

An addendum -- Connel MacKenzie's statement above, that no paper or online dictionary uses this sort of interleaving is false. The online OED, which many (include me) regard as the gold standard, displays quotations as well as the quotation timeline directly beneath each sense and it is by far the most intuitive style for the reader. The particular senses come from usage and there is nothing better than quotations to verify and clarify usage. -- WikiPedant 19:29, 2 March 2008 (UTC)

If you wish only to make personal attacks, you should check your facts first. Your statement is completely false, s is your assertion about what I said. The version of the OED online you seem to be talking about, lists a separate tab, not displayed by default. No online OED copy that I have access to (such as The Oxford Dictionary of English (2nd edition revised)) does anything quite so idiotic as you suggest...I haven't seen one yet that displays the quotations. Which, by the way, completely ignores real dictionaries...none of which provide the quotations of use, to anyone except their internal staff. --Connel MacKenzie 20:40, 2 March 2008 (UTC)

No, no, you are not paying close attention to your statements or to mine. Your statement above pertained explicitly to interleaving information under each sense, not to defaults. I didn't say that the quotations in the OED display by default. (They don't). The point is that, if you press the online OED's (2nd ed.) "quotations" button, then the quotations display in interleaved format (i.e., separate quotations for each sense). Ruakh's template works in a similar way -- If you press "Show," for any given sense, then the quotations will display immediately beneath that sense. What could be more intuitive for the reader? Respectfully -- WikiPedant 20:56, 2 March 2008 (UTC)

Odd: for me the OED Online (the real one) does show quotations by default, though when I turn them off (which I rarely do, but anyway) it notes that in a cookie and hides them for a while. At any rate, doesn't the physical OED also put quotations between senses? I always assumed it did. Certainly that's what Webster 1913 does. —Ruakh_TALK 21:50, 2 March 2008 (UTC)

I don't know about the latest edition, but the first edition certainly placed the quotes after each sense (whether numbered or lettered). However, they were also selective in their use of quotes, limiting them to only a handful per sense to minimize clutter. --EncycloPetey 21:53, 2 March 2008 (UTC)

Can we get away from what the OED does and continue discussion what it is WE should do? The whole idea behind the ELE/layout is not to have something to argue about (contrary to popular belief) rather to clearly define what we have decided will make Wiktionary the most accessible resource possible. Whatever we can do to further that is good. - [The]DaveRoss 21:54, 2 March 2008 (UTC)

Sure, that's easy. What we should do is implement Ruakh's template so that a collapsible quotation box can be placed after each pertinent sense in an entry. I've never really followed the voting around here, but is this the sort of thing Wiktionarians should vote on? -- WikiPedant 22:22, 2 March 2008 (UTC)

Personally I think it is quite early for a vote on this particular issue, especially in light of the recent discussion of wholesale changes to layout in general, and the effect that these changes would have on the quotations/citations. For the time being it is certainly appropriate to add citations to the Citations namespace, and no one will yell at you for building the collapsible section for quotations and putting it on a few pages for example purposes, etc. - [The]DaveRoss 23:22, 2 March 2008 (UTC)

• Addendum: Further to my point on CSS classes above, note that this bookmarklet can be used (in Opera/Firefox) to make all citations implemented with {{quote-book}} et al. disappear. Quite handy for readability in some entries, and with the added advantage that no actual change in entry layout is necessary. Unfortunately that's about the limit of my Javascripting ability; but perhaps there is some way (down the road) we could have a toggle-quotations link as part of the default skin? Posting this here 'cause I assume everyone is tired of this topic at the moment, so it would be silly to start a new discussion. Actual further discussion should probably go to WT:GP, or at least to a new thread. -- Visviva 13:33, 14 March 2008 (UTC)