Wiktionary:Beer parlour/2006/May

Beer parlour archives edit
2024 January February March April May June July August September October November December 2023 January February March April May June July August September October November December
Earlier years 2022 January February March April May June July August September October November December 2021 January February March April May June July August September October November December 2020 January February March April May June July August September October November December 2019 January February March April May June July August September October November December 2018 January February March April May June July August September October November December 2017 January February March April May June July August September October November December 2016 January February March April May June July August September October November December 2015 January February March April May June July August September October November December 2014 January February March April May June July August September October November December 2013 January February March April May June July August September October November December 2012 January February March April May June July August September October November December 2011 January February March April May June July August September October November December 2010 January February March April May June July August September October November December 2009 January February March April May June July August September October November December 2008 January February March April May June July August September October November December 2007 January February March April May June July August September October November December 2006 January February March April May June July August September October November December 2005 January-March April-June July-September October-December 2004 January-March April-June July-September October-December 2003 January-March April-June July-September October-December 2002 December

Numerical accuracy

We should be careful when giving approximate values in the definitions of terms. A dictionary serves to define words, but many times values are measurements, which must always be rounded at some point, and are therefore superfluous information, even if useful.

absolute zero is by definition zero on the Kelvin scale, so this is appropriate to note in the definition. However, the Celcius and Fahrenheit values are approximates since those scales are based on the freezing and boiling points of water. The values should be provided only as additional information.

A year is defined as exactly 365.25 days in scientific terms, but the more common meaning is defined astronomically. In fact any value given would not only be approximate but is in fact slowly changing over time.

I've also noted that the elements, which are defined according to atomic number, have included atomic mass in the definitions, but the latter is also measurement. Worse, it's based on specific isotopes, so I'm not certain it's at all correct to place the information there. More descriptive defintions could include information about valence, which directly relates to the charge of the nucleus.

I'm not saying that informative descriptors should be excluded from definitions in every case. What's important is to make a clear distinction between what information defines a term, and what information can only additionally illustrate it. Davilla 23:52, 1 May 2006 (UTC)

I was unable to find the previous discussion about this. The topic is which: colloquial vs. scientific? Or the accuracy of scientific measurements, as reported by Wiktionary? --Connel MacKenzie T C 06:40, 5 May 2006 (UTC)

Nor can I. Maybe it was on WiktionaryZ? Anyways, are my comments out of line? Davilla 17:31, 8 May 2006 (UTC)

Not at all...I am trying to suggest that this topic still needs further discussion, as it was unresolved that last time it was mentioned, IIRC. --Connel MacKenzie T C 18:40, 8 May 2006 (UTC)

---- hidden between articles in view mode

This has come up often and I think I'v come up with the definitive solution thanks to some help. I have modified the global monobook CSS page to hide the extra horizontal line but to increase blank space between language sections in its place. A small extra benefit is that only one blank line before and after ---- in the wiki source will result in nice formatting. If anybody thinks the amount of space needs adjustment or finds any problems please comment here. If it's controversial we may need to vote as to whether the standard is to have the extra line with a per-user option to hide it, or vice versa. Please not that skins besides monobook are entirely unchanged. If you would like this change for another skin please also comment here.

Those monobook users who would like to retain the old look can insert this code into their custom CSS file:

.ns-0 #bodyContent hr { visibility: visible }

Those who don't want extra space between language entries add this: .ns-0 #bodyContent hr { margin-top: auto }

— Hippietrail 22:28, 2 May 2006 (UTC)

Perfect! —Vildricianus 16:00, 4 May 2006 (UTC)

The first three times I read this, I misunderstood it to be the inverse of what you actually wrote. Why would you blank these from the default view? I'm sorry, but that just doesn't make sense to me. --Connel MacKenzie T C 20:29, 4 May 2006 (UTC)

Connel has reverted this without commenting either here, the custom CSS talk page, or my tak page. In his edit comment he merely decides: "rv HT's line-blanking thing for personal monobook.css's"

Does anybody beside Connel not like it and is anybody in favour of dropping the "be bold" guideline? — Hippietrail 20:27, 4 May 2006 (UTC)

I'm sorry if you felt that I was stepping on your toes. I honestly thought what you did was a simple error when I saw it (finally) in Monobook.css. NOTE: Please see the conversation below, in the section acout the broken Main Page as to why what you've proposed is not a workable solution. It still has some promise, but still has big kinks that need to be worked out. --Connel MacKenzie T C 20:35, 4 May 2006 (UTC)

It has promise, yes; where are the kinks beside on the main page? —Vildricianus 22:00, 4 May 2006 (UTC)

Well, I for one (perhaps the only?) thought that this was a discussion about personal monobook.css customization from the very start. I do feel that if something is in an entry, something visible on the rendered page should correspond to it. The "kinds" I was referring to were that all HRs were invisibe-ized by this change, not just the ones above the headings - but also the ones below. I don't think that is the desired effect, is it? --Connel MacKenzie T C 00:29, 5 May 2006 (UTC)

P.S. Evil site-wide code restore to functionality. --Connel MacKenzie T C 01:10, 5 May 2006 (UTC)

Actually, maybe we never had lines underneath 3rd level headings. I thought we did, but I guess not. --Connel MacKenzie T C 01:17, 5 May 2006 (UTC)

• Ok everybody, I've cooled down again although I missed my bus before. Connel and I are still friends. I finished testing my CSS that gives the usual result for ---- on Main page, and the result I thought (almost) everybody wanted on other articles. I'm not a CSS guru though and I don't feel it's elegant enough so please take a look. The ---- is definitely visible but I'm not 100% sure the spacing is as it was before. I'd appreciate any comments.
• By the way the line before the level-2 heading was an HR, the line after it is produced magically by the monobook core CSS and just looks like an HR. I'm not aware of any other horizontal lines anywhere but please let me know if I missed some so that I can make exceptions for those too.
• Also, if anybody really does hate this change please share your feelings here. We can always vote on it or revert it but I was honestly under the impression that all Monobook users wanted such a fix. For now please test it though and comment. Thanks for your patience. — Hippietrail 01:29, 5 May 2006 (UTC)

I don’t think the extra space with no visible line is appealing. Typographically, it doesn’t yield a sharp, clean look to the page. A better idea would be to give it the double spacing preceding the ---- just as you’ve done it, but keeping the ---- visible. That way, typing a single HR, then ----, then another HR, would produce professional-looking margins and virtual page boundaries. —Stephen 21:48, 6 May 2006 (UTC)

Try putting this in your custom CSS, then refresh your cache (CTRL+F5):

.ns-0 #bodyContent hr { visibility: visible !important; }

Others please try this too and comment here. We can make whichever is more popular default, and the other optional. — Hippietrail 21:53, 6 May 2006 (UTC)

Ah, much better! Thanks. —Stephen 22:42, 6 May 2006 (UTC)

OK, I think perhaps the visibility:visible is more proper as default mode. —Vildricianus | t | 18:21, 7 May 2006 (UTC)

If the power doesn't go out again I'm going to turn the line back on by default and update the customization page with how to hide it. Is everybody happy with the amount of space? — Hippietrail 16:50, 8 May 2006 (UTC)

Stats

Hi, I was wondering about this page. How does one get it updated? I'd like to know where I am on this list. --Dangherous 18:14, 3 May 2006 (UTC)

It is updated based on the DB dumps, but the person who does the updating (Author:Erik Zachte Mail:###@chello.nl (<nospam> ### = epzachte </nospam>)) seems to have skipped the last few. - TheDaveRoss 04:43, 4 May 2006 (UTC)

I asked about this on #wikimedia-tech. The host name stats.wikimedia.org resolves to albert, which is part of the core server cluster. So someone there may be inclined to run it when the last of the XML dumps finish. Who knows - maybe they'll automate it. Or maybe just ignore it. Hard to guess. --Connel MacKenzie T C 06:46, 5 May 2006 (UTC)

Hey, it's just been updated! Congrats to SemperB, the top non-mechanical contributor...though sometimes I wonder.. Widsith 17:45, 14 May 2006 (UTC)

Related words in other languages

Suppose you are an English speaker trying to learn Spanish, and you come across the word "tener" (to have). It is easier to remember if you recognise related words in English such as "contain".

Would it be possible to collect such related words? It would probably have to be done for pairs of languages. —This unsigned comment was added by 70.50.115.35 (talk • contribs) 19:59, 3 May 2006.

It is not an exact cognate, but there is no reason why you couldn't add ‘Compare English contain, retain, etc.’ to the =Etymology= section. As long as you have a clear understanding of what the relationship is there is no problem. Widsith 20:09, 3 May 2006 (UTC)

Well, it looks to me as though it might be better in a section like the translations into other languages. Perhaps under a title like "Cognates, near cognates and false cognates." (False cognates are known as "falsos amigos" in Spanish.) It might be like the translations by having a sub-section for each language.

I guess I am also asking two questions simultaneously. Roughly, could this be organised and would people be so kind as to make the necessary entries.

I do have a book on false cognates between English and Spanish, but I have never seen anything on near cognates (in this sense). —This unsigned comment was added by 65.95.116.102 (talk • contribs) 21:20, 3 May 2006.

The Etymology section is the section for cognates; that is where they belong. Near-cognates may be added as well if they are helpful (but not all of them will be: Latin tenere, in your example from earlier, has several score descendants in English alone). False cognates between different languages might be best placed in a Usage note (‘not to be confused with...’) where the words are false friends, otherwise they can also appear in the Etymologies (‘Not related to...’). Widsith 21:33, 3 May 2006 (UTC)

There was preliminary discussion a couple months ago about a ===Miscellaneous=== heading at the end of an entry. A subsection under that might be ====Cognate mnemonics====, if I understood what you are saying correctly. But I don't think I'd vote for inclusion of those items in Wiktionary. Maybe write a book on Wikisource on the topic? We're trying to build a dictionary, but we aren't even close to having the basic language covered just yet. Ooops, the same argument can be used against {{rank}}s. Hmmm. --Connel MacKenzie T C 01:35, 4 May 2006 (UTC)

Ranks are very useful for translators browsing through the basic entries. In general, I'd vote no for this proposal. As Connel points out, we're already having a hard time doing the basics for English. —Vildricianus 15:59, 4 May 2006 (UTC)

We had something similar on fr:, because someone proposed two sections: "derived terms in other languages" and "related terms in other languages". It appeared that the second would be too difficult to fill (in a multilingual dictionary), considering that every words (in every languages) related should have that same section with a link to the other words (that can be huge, and the information would be repeted several times). So, we proposed to gather all those informations in the article of the etymon, in a section "derived terms in other languages". For example, the page fr:bellum contains links to the French fr:belliqueux and the English belligerent. I think it is the most logical way to handle this. - Dakdada 18:35, 4 May 2006 (UTC)

Hmmm... a reverse etymology, of sorts. Fery interestink. There's at least one Wikibook I've seen on amigos falsettos, by the way. Davilla 19:39, 4 May 2006 (UTC)

Reconsidering. What if it really is critical, as in the French for pint?

I have been adding sections like this to Old English entries, under a =Descendants= heading. Of course in that case it's really only English or Scots, but in the case of Latin there would be many languages. Such words are normally called derivatives, but in Wiktionary we use Derived Terms for related words in the same language, so it was necessary to distinguish. (It is more complicated and important in Romance languages, because French and Spanish have some words that have evolved from Latin, and others which have been borrowed from Latin later on. It is important to distinguish between these, but that implies yet another section...) Widsith 19:54, 4 May 2006 (UTC)

Given the possible options, I think it would be preferrable to have a separate section of =Cognates= and a section of =Derivates in other languages= in which the individual words were listed by language. This is certainly the case for Latin entries, which will have derivates in several languages as well as cognates. --EncycloPetey 08:53, 5 May 2006 (UTC)

How to hide sense numbers when there is only one sense

Some people have had strong feelings that there should be no #1 for entries which only have one sense. Now there is a way for these people to hide that number without changing the wiki code, and everybody else will see just what they always saw.

See Wiktionary:Customizing your monobook for details, in the Javascript section.

Anybody who is good at documentation, especially those who also already have custom JavaScript files, please improve the page. Specifically we need some kind of introduction telling people how to start such a page, and then telling them how to add fuctions.

Right now the position of the definition will be exactly the same with only the number invisible but basically still taking up its space—so it looks too far indented. CSS gurus might be able to tell us a way to get rid of this indent.

I've done some CSS experiments of my own and the best I have found is this:

.ns-0 ol.single-entry-list li { list-style-type: none }

.ns-0 ol.single-entry-list { margin-left: 0; padding-left: 1em }

This merely gives the definition indentation a value that looks kind of right for me, but I really want a solution which results in the definition beginning in the exact position the sense number would begin, and on all browsers. Can anybody tell me if this is possible? — Hippietrail 20:32, 6 May 2006 (UTC)

I expect the broken livery entry is related to this experiment. For me, it's missing the number "1" before its first definition. Granted, the entry's layout itself is wrong, but is the number "1" missing for other editors or just for me? Rodasmith 17:35, 9 May 2006 (UTC)

No, this is a customization you have to install in your own JS and CSS files, I haven't made it global. In this case the formatting is just wrong. I suggest placing an {{rfc}} on that page. — Hippietrail 17:52, 9 May 2006 (UTC)

Category tree

I posted the following question to Wiktionary talk:Categorization and am posting a short version of it here for visibility: Are all English language entries really supposed to get Category:English language, as recommended in Wiktionary:Categorization? Rodasmith 03:02, 4 May 2006 (UTC)

I think in an ideal world, yes. But in practice, it doesn't really happen, because we don't have template like the French Wiktionnaire, so we tend to get lazy and omit them. That's my theory anyway. --ex-admin part-time sockpuppetting quasi-vandal Wonderfool 11:22, 4 May 2006 (UTC)

In practice, if all Englush entries got that tag, the category would be useless, since it would contain more than a million entries (eventually). --EncycloPetey 11:26, 4 May 2006 (UTC)

Thanks. Wiktionary:Beer parlour archive/January-March 06#Category:English Adjective and WT:BP#Categories of the form <language>:<part of speech> agree that huge categories are undesirable. I'll update Wiktionary:Categorization accordingly. Rodasmith 17:35, 4 May 2006 (UTC)

Word Characteristics

(Copied over from Tea Room)

I am beginning a project intended to optimize the order in which the various characteristics of words are organized. This project requires a comprehensive list of such characteristics and their values. For instance: using the characteristic “Parts of Speech” the characteristic values would be noun, verb, adjective, adverb, etc. Although a good list of characteristics can be obtained from almost any dictionary entry I would prefer to develop an exhaustive and comprehensive list here. Any ideas as to the best way that this might be done?

Pce3@ij.net 18:19, 30 April 2006 (UTC)

This user is a member of the Association of Inclusionist Wikipedians The motto of the AIW is Salva veritate, which translates to, "with truth preserved." This motto reflects the inclusionist desire to change Wikipedia only when no knowledge would be lost as a result.

Association of Inclusionist Wikipedians

Characteristics also include: number of double letters (Mississippi has 3), number of capitalized letters (McDonald has 2), number of vowels (twyndyllyngs has none), type of symmetry if any, and value considered as a number in base 36. Davilla 19:13, 1 May 2006 (UTC)

By symmetry I assume you mean words like Abba. What do you mean by "type" of symmetry? Can you list the "types"? Also what do you mean by "value" in base 36? Thanks. -- Pce3@ij.net 19:29, 1 May 2006 (UTC)

Besides the palindromes, and it's too bad this one doesn't have an entry, words like "Pd" and "SWIMS" have rotational symmetry. Davilla 19:22, 4 May 2006 (UTC)

I think you might get more help and response over in the Beer Parlour, so I'm copying this section to there, and suggest the converdsation continues there, not here in the tea room, which is more about specific words, rather than methods.--Richardb 13:06, 4 May 2006 (UTC)

This is a little off-topic, but the motto of the AIW is actually Conservata veritate and not Salva veritate (which means "safe with truth"). --EncycloPetey 15:22, 6 May 2006 (UTC)

Main Page

Why are the <hr>'s missing/invisible on Main Page, especially in the "other languages" section? --Connel MacKenzie T C 19:52, 4 May 2006 (UTC)

Because of the recent Monobook.css customization of hr's being rendered invisible in main namespace. Creating a manual line doesn't work either (tested in MediaWiki:Noarticletext). —Vildricianus 20:11, 4 May 2006 (UTC)

Um, what recent customization? There were notes on how individual people could do it to their own personal monobook (if they were so inclined) but such a thing should not have made it into the site-wide version. I didn't see it there, when I looked, BTW. Has it already been rolled back? --Connel MacKenzie T C 20:16, 4 May 2006 (UTC)

OK, I found that directive (it looked like a comment, due to line-wrapping, earlier) and commented it out. Where is the previous conversation, somwhere here? --Connel MacKenzie T C 20:23, 4 May 2006 (UTC)

I don't know why you chose to ignore the topic already here above, ignore my talk page, ignore the global CSS's talk page, and ignore my specific request to comment here in the global CSS file. I was trying to actively work on this right now it was difficult to find what was going wrong since you didn't comment in any of the expected places. I filed a bug report yesterday on the subject of no CSS to distinguish the special Main page from normal default namespace pages. I have meanwhile added a CSS id to the main page as a workaround, and I have unfinished CSS code in my personal CSS file that was trying to get the HRs to be hidden only on "normal" default-namespace pages. I have to give it up now due to lost time and I have a bus to catch. Anybody with an interest in this and a knowledge of CSS please feel free to continue the work... — Hippietrail 20:37, 4 May 2006 (UTC)

Wikimedia Toolserver

I finally got my account at the Wikimedia Toolserver and it seems to work or at least partially work. I have a page there now with a very simple database access example.

Unfortunately it seems that just the meta data not the actual page data is there. If you click on an entry it just shows where the data is stored not the actual data. If I run it on my own box with the dump imported it shows the actual page data... But perhaps the data is somewhere else... --Patrik Stridvall 21:21, 4 May 2006 (UTC)

This, I think, is a fantastic start. --Connel MacKenzie T C 06:50, 5 May 2006 (UTC)

Lemme know if you get Kate's "markthrough" working. --Connel MacKenzie T C 06:53, 5 May 2006 (UTC)

Get what working? Anyway, I will work more on it during the weekend. I guess I can get the page data from the XML dump if everything else fails but that is just a reserve solution. In the meantime, does anybody has something that only needs the meta data? --Patrik Stridvall 08:19, 5 May 2006 (UTC)

Kate has a tool called "markthrough" for doing wiki-ish markup for toolserver html pages (tags the links at the bottom correctly, various other "required" cross-links and stuff.) I've had trouble setting it up, due to time constraints. --Connel MacKenzie T C 18:35, 6 May 2006 (UTC)

OK. I personally prefer PHP and since I do a lot of database stuff with dynamic formating I don't see much use for it. Especially since PHP can easily share headers and footers between files which seems to be one of the major advertized advantages. --Patrik Stridvall 21:04, 7 May 2006 (UTC)

---

I have written PHP code to parse the XML dump and find the headers and store it in a database on the toolserver. I have also done a few other updates. See for yourselves on my toolserver page.

Since I now have a base for parsing the XML dump I can now build a database on whatever we like. Any suggestions? Translations perhaps? --Patrik Stridvall 21:04, 7 May 2006 (UTC)

Wow, that was quick. It seemed to work on the first click-through I did, but now is just giving blank pages? Hrm, now working again. I'll look more - so far it looks like some fantastic stuff.

I remembered I had forgotten something a while after posting so I made a few more changes. Perhaps is was what caused the temporary failure. The machine running the MySQL server seems to be down right now so I can't check. --Patrik Stridvall 20:37, 8 May 2006 (UTC)

I guess the next "really useful" thing would be to have something that listens to irc://irc.wikimedia.org#en.wiktionary and creates a list (once daily) of pages updated that day, so that at any time we can simply get the delta pages from Wiktionary instead of the XML dump for any entry touched since the last dump. (Perhaps it should even exclude edits from the interwiki robot User:RobotGMwikt?)

There is a table that contains the recent changes that is replicated live so that is not a problem. I could exclude everything updated after the date of the dump from the pages to make it possible to "check off" fixed problems. That is planed but not done. Or I could download everything newer directly from here but that is more complicated. --Patrik Stridvall 20:37, 8 May 2006 (UTC)

--Connel MacKenzie T C 21:43, 7 May 2006 (UTC) (edited)

Boy do I feel stupid. I didn't realize I had read access to /home/strivall/public_html. I must say, I am very impressed by your style. I see now why you shun the markthrough thing. As a petty administrative note, you might want to tag everything as GPL (assuming that is your intent, or copyright P.S., or whatever) and the icon links (spelled out at meta: Toolserver#Using convention.) --Connel MacKenzie T C 22:38, 7 May 2006 (UTC)

I do similar things for a living so I guess I have learned something over the years. As for license, GPL is fine unless somebody has any better idea. I will fix the administrative stuff and publish the source code when it is more ready than it is now. In the mean time feel free to used any code under the GPL. --Patrik Stridvall 20:37, 8 May 2006 (UTC)

---

Patrik, do you know how often the XML dump (that your tools are based on) is refreshed? —Scs 01:12, 9 May 2006 (UTC)

From m:Data_dumps "dumps will be run approximately once a week". Since the last one is from 2006-05-03 a new one should available tomorrow. I have to download and run the parser again manually though. Note that not all pages uses the dump. Each page says whether it uses the dump or not. Everything except for the page data is live or almost live there might be a small replication delay. --Patrik Stridvall 16:57, 9 May 2006 (UTC)

Thanks! —Scs 04:04, 10 May 2006 (UTC)

That is quite a new development. When the XML dumps are running well, I think we've been able to rely on them about once a month. More often, there are minor problems amounting to more significant delay. I think the once-a-week thing refers to when the pass starts for small wikis (which we are not.) We'll see soon if we really do get more than one a month from now on, but I'm not doing anything more than crossing my fingers at this point. (Of note: the en.wikipedia dump pooched out again...not a good sign.) --Connel MacKenzie T C 15:08, 12 May 2006 (UTC)

It seems that you are right. Oh well, not much we can do but wait for the next. --Patrik Stridvall 20:00, 12 May 2006 (UTC)

New XML dump generated for en.wikt: last night... --Connel MacKenzie T C 16:24, 21 May 2006 (UTC) Something tells me, I should have downloaded the XML dump first, then posted this message.  :-) I've never seen download.wikimedia.org pushing less than 100KB/sec before. --Connel MacKenzie T C 16:41, 21 May 2006 (UTC)

And now Patrik's tools are seeing it! Hooray!

(Unfortunately the dump was from just before I figured out a sneaky way to track down and fix all the headers with apostrophes in them. And it looks like Patrik fixed his script so it doesn't choke on those any more, anyway. Thanks!) –Scs 16:48, 26 May 2006 (UTC)

Now that En.Wikipedia's XML dump finished, all the others seem to be running much faster. So, en.wiktionary now has a dump from 5/28. Maybe we'll get weekly(ish) dumps after all. Or maybe we just got luck on that one? --Connel MacKenzie T C 15:17, 31 May 2006 (UTC)

Dictionary.com and m-w.com

I see that we can't copy/paste entries from dictionary.com. Is there a copyright issue? I thought copyright laws don't apply to words. By the way, what about m-w.com? Can we copy/paste from there too? --68.102.193.78 08:29, 5 May 2006 (UTC)

Yes, it is. Aren't there any older English dictionaries in the public domain now?--Jusjih 11:01, 5 May 2006 (UTC)

Plenty are in the public domain - but few are available online. We often use the 1913 Oxford Dictionary. I've recently added a Dictionary of the Chinook Jargon from Gutenburg, and are still searching for a digital copy of the 1910 Black's Law Dictionary. bd2412 T 13:15, 5 May 2006 (UTC)

Aside from the potential legal issues, simply mirroring another dictionary is counter to the idea behind this project. We do not aim to simply be a dictionary.com mirror, but a secondary source like dictionary.com. - TheDaveRoss 14:13, 5 May 2006 (UTC)

Copyright doesn't apply to individual words, sure, and on that ground we have several wordlists from various sources. But what you'd be copying from a dictionary website is not the word, but a definition of it—which may or may not, depending on the style, be copyrightable, but would you really care to risk a lawsuit when you could write it yourself?—and possibly other information such as etymology and pronunciation.

Another decent PD source is Webster 1913. The problem with public-domain-by-age stuff though is its lack of descriptions of newer developments in the language (which can be fine for historical perspective and completeness, but can make a poor beginning for an entry). —Muke Tever 14:23, 5 May 2006 (UTC)

Good. Having one online dictionary in the public domain is much better than having none, so please provide any online sources so someone may use them freely with any needed updates.--Jusjih 15:34, 6 May 2006 (UTC)

Registering words

EDUCTIVITY - From the Latin educere, to lead out or out of. The dynamic between deduction (leading from, general to specific) and induction (leading in or into, specific to general). SImilar to the Hegelian dialectic of thesis (rationalism), antithesis (empiricism) and synthesis (eductivity) except that the process must be constant to create 'good,' either positive or normative. The stone tablets must be continually created, broken, recreated, etc.

Retrieved from "http://en.wiktionary.org/wiki/eductivity"

Is there a way this word can be registered? robert.h.yauger@verizon.net

-- asked by User talk:71.245.183.154

"Registered" how? If you mean in copyright, that's not possible; if you mean in trademark, you will want to check the laws of your country; if you mean to make it acceptable to this dictionary, include three verifiable quotations of other people using the word over the span of at least two calendar years (see WT:CFI); if you mean to make it acceptable to the English language, you can only do that by using it, and in ways that incite others to use it as well. —Muke Tever 14:30, 5 May 2006 (UTC)

Oops. I somehow missed this BP thread before beginning, but FYI, I'm using Appendix:List of protologisms/eductivity to develop a protologism mainenance tool. If anyone would reather I not use that submission, please say so. Otherwise, I'll continue and post a follow-up here when I'm finished. Rodasmith 04:42, 9 May 2006 (UTC)

Well, the idea was to do something with the "Sniglets" that were being submitted in 2003/2004. At that time, only a tiny minority here wanted them included on Wiktionary. Trimming/neutering them down to one line seemed acceptable to most. But your experiment has great promise; the Wiktionary namespace isn't seached, by default, right? This sort of page could serve as a holding spot for building citations. Primetime, E. Seguora, other vandals, sockpuppets and POV pushers would love that opportunity...but then so would some amateur linguists. I think you should limit the experiment to only a small number of entries until consensus emerges. --Connel MacKenzie T C 06:00, 9 May 2006 (UTC)

As it turns out, my end suggestion is does not require a maintenance tool. Instead, it amounts to managing each new protologism submission as follows:

1. move it to Appendix:List of protologisms/sampleProtologism
2. instead of listing its definition on Appendix:List of protologisms, add it to Category:Protologisms.

I'm not sure that is any better than the current process, so I won't be particularly hurt if the suggestion is shot down. Ready... aim.... Rodasmith 07:17, 9 May 2006 (UTC)

Fire. Sorry. Even with a huge disclaimer on the page, it's simply not something people here are interested in promoting. Any more than one line is granting way too much freedom. Davilla 21:16, 9 May 2006 (UTC)

substandard

The word liquification turns out to be incorrect (I, and 62,000 google hits, thought otherwise). If I make a page to say the correct word is liquefaction, does it belong in a category of incorrect words? I considered creating category:substandard but do we already have a category for such cases? Is substandard the best name for such a category? JillianE 16:12, 5 May 2006 (UTC)

Incorrect? Liquification tells me something else. —Vildricianus 16:16, 5 May 2006 (UTC)

Dictionary.com doesn't seem to agree.

Also, there are 62,000 googles for liquification but over 2 million for liquefaction (and google asks if I meant liquefaction). JillianE 16:22, 5 May 2006 (UTC)

If you make a page to say the correct word is liquefaction it would belong in a category of POV entries to be rewritten, unless you back that up with quotations from grammarians in a ==Usage note== section. (If you like, I could contribute a note in the ==etymology== section saying a better-justified spelling is liquefication, since the better-accepted form of the verb is liquefy; the -i- seems to come by analogy from liquid, which is from liqu-idus.) The existence of one word does not negate the existence of another of similar formation or meaning (cf. comic and comical, and the whole debate elsewhere on cacodemoniacal or whichever it was). —Muke Tever 12:46, 6 May 2006 (UTC)

Not quite the same – comic and comical (and all variants thereof) are both entirely valid formations within the established patterns of English suffixing. Liquification arose only through error. It is hardly POV to point that out, since liquification would not be acceptable in a business letter, job interview, etc etc, and users ought to know that. Widsith 07:58, 9 May 2006 (UTC)

Given that very few words are properly in -efaction (putrefaction is the only other relatively common one I can think of) it's no surprise that lique/ification be recreated on the analogy of verbs in -fy, which most frequently produce formations in -fication within the "established patterns of English suffixing." Modification and creation of words based on analogy are an ordinary linguistic phenomenon, and can easily be mainstream (such as spelling island with an s) or regional (color/colour with French -our or "restored" Latin -or) or disturbingly nonstandard (orifii as a plural of orifice on the model of other words ending in /əs/). Deciding to label liquification an 'error' has to be POV. —Muke Tever 23:28, 9 May 2006 (UTC)

That is UK/European POV, but the opposite seems to be true here in America. <insert pejorative comment about the US Congress' (Senate and House) language use here>. --Connel MacKenzie T C 17:06, 9 May 2006 (UTC)

Ah, OK – the Usage note will be a complicated one, evidently! Widsith 17:08, 9 May 2006 (UTC)

Maybe nonstandard would be a better word to describe this. JillianE 19:47, 10 May 2006 (UTC)

Probably. --Connel MacKenzie T C 14:58, 12 May 2006 (UTC)

Logo

Is is just me, or is the pronunciation depicted in our logo missing a syllable? Wouldn't the construction currently displayed be pronounced like Wik-tion-ry as opposed to Wik-tion-a-ry? bd2412 T 00:49, 6 May 2006 (UTC)

There is a section on the topic hidden in WT:FAQ.  :-) It is also discussed about a dozen times in the archives of this page, if you need an in-depth answer. --Connel MacKenzie T C 02:23, 6 May 2006 (UTC)

Ah - didn't know we had a FAQ! bd2412 T 15:55, 6 May 2006 (UTC)

Anagrams Category

Is there a category for words that are anagrams, and if so, is there a language-specific category? --Think Fast 01:05, 6 May 2006 (UTC)

Can't most words be anagrammed? How would such a category be subdivided? --Connel MacKenzie T C 02:25, 6 May 2006 (UTC)

I'm sorry. I should have been more specific. I meant words that can be anagrammed into other words that are actually words. (I guess that otherwise the only words that couldn't be anagrammed would be "I" and "a":) There's a page about anagrams at Wiktionary:Anagrams that gives a very small explanation of it.

As for how the category would be subdivided, I don't quite know what you mean. (I haven't been here very long.) But guessing I would say options would include by language, alphabetically, and by number of anagrams. --Think Fast 13:41, 6 May 2006 (UTC)

Well, that would still result in (one or more) gigantic category(ies), right? I'm not sure that people would find that helpful. Doing a crazy subnamespacing by the alphabetic first-sort doesn't work well either, e.g. Category:Anagrams:opts for opts, post, pots, spot, stop, tops. The resulting sub-caregories would generally be too small, and the pseudo-namespace talk pages would be in the wrong place.

I don't think categories is the right approach. Perhaps Wiktionary:List of anagrams or something like it? That could have a one line entry for opts. Pages could have *See [[Wiktionary:List of anangrams#opts|anagrams]]. in the ===See also=== section. Does this work well for everyone? --Connel MacKenzie T C 15:42, 6 May 2006 (UTC)

Correction: I meant Appendix:List of Anagrams. The Wiktionary namespace is not appropriate. --Connel MacKenzie T C 15:44, 6 May 2006 (UTC)

Would this mean that the ===Anagrams=== section would have to be removed and replace in the ===See also=== section? Also, I don't know if adding something like *See [[Wiktionary:List of anangrams#opts|anagrams]] would work because what if there were more than one anagram for a word? What would we do then? --Think Fast 00:03, 11 May 2006 (UTC)

No, I do not think the ===Anagrams=== heading would have to be removed. I think it would be greatly simplified, as each entry (opts, post, pots, spot, stop and tops) would have the same one line, perhaps more like * [[Appendix:List of anagrams-o#opts|Anagrams for {{PAGENAME}}]]. Note that I think a similar subdivision method (as used in Appendix:Names would keep the lists managable.) I'm not sure at all, what you mean by "more than one" though. --Connel MacKenzie T C 02:54, 11 May 2006 (UTC)

I mean something such as having opts, post, pots, spot, stop, and tops all for the same word. Now all are listed under the ===Anagrams=== category, but under the appendix idea, would all you see just be a line saying "Anagrams for {{PAGENAME}}" with a link to the appendix? --Think Fast 23:31, 11 May 2006 (UTC)

Yes, that was what I was saying. AFAIK, the anagrams were supposed to be sorted alphabetically, so all the words would point to the Appendix:List of anagrams-o#opts. In the appendix list, there would be "== opts ==" with the anagrams listed under them. In the individual main namespace entries, yes, all you'd see is the ===Anagrams=== heading plus one line saying "Anagrams for ...". This would have the benefit of reducing clutter in the main namespace, for a "trivia" item that is not widely adored by other contributors here, while still providing a maintainable way to enter them. --Connel MacKenzie T C 14:55, 12 May 2006 (UTC)

Now I see what you're saying. But why would an appendix be needed instead of listing the words in the article? The anagrams really don't take up all that much space... but then again, maybe it would be better to have an appendix. Is there a policy on things like this, or should we have a poll, or what? --Think Fast 23:28, 12 May 2006 (UTC)

WikiSaurus:new

Anyone care to have a stab at adding to this one. There a lot of subtly different meanings that need Thesaurus lists. It's a bit of a test of if WikiSaurus really is going to work for us, how we might need to refine it.--Richardb 15:17, 6 May 2006 (UTC)

Apostrophes versus quotation marks

I've noticed that the titles of some articles that contain apostrophes in their titles use the character U+2109 (’) to represent an apostrophe. While this character may be typographically correct in appearance, it is encoded in Unicode as the "right single quotation mark," where as the "typewriter" apostrophe (') or U+0027 is encoded merely as the "apostrophe." Thus, I believe it is incorrect to use the former character in titles as it is not really an apostrophe (in addition to not existing on a keyboard.) At any rate, it is not Unicode's job to dictate how a character is actually drawn: that is up to the user agent. The fact that a quotation mark "looks" more correct than an apostrophe is really an error on the part of the font or user agent and it is an erroneous substitute.

(Unicode also defines U+02BC as the "modifier letter apostrophe", which in many fonts looks different than the regular apostrophe. This character, however, is a meant for use as a diacritic and not as a regular apostrophe either.)

Addendum: it appears this issue has already been argued about a great deal, and dragging it on further would be of little benefit. Since, however, there appears to have been no formal resolution, it would seem prudent to use the U+0027 character, which appears to be the prevailing trend.

-- Ian Bollinger 04:43, 7 May 2006 (UTC)

Actually, in the most recent go-round (see Wiktionary:Beer parlour archive/January-March 06#Curly apostrophes), according to User:Hippietrail (who I have no reason to doubt), there is a resolution, and it agrees with yours: "All titles with apostrophes should use the typewriter apostrophe." —Scs 15:19, 7 May 2006 (UTC)

For those curious, see User talk:Connel MacKenzie/apostrophe. --Connel MacKenzie T C 06:40, 7 May 2006 (UTC)

User:Primetime

Due to the recent spate of increased Primetime vandalism here, I came across familiar looking edit patterns at w:J. At the time, I was verifying an unconfirmed sockpuppet's copyvio vandalism of our entry for j. As a result of looking at the history of w:J, and a cursory amount of additional observation on Wikipedia, I discussed the matter with several others. In the end, I followed a suggestion to list a notice on w:Wikipedia:Administrators'_noticeboard#Wiktionary_user. (Thanks again for the link - I probably never would have found WP:AN nor WP:ANI.) Thank you whoever fixed the link, from when it got changed (by Primetime?) on Wikipedia. I'd re-added the link w:WP:AN#User:Primetime there, with a note to keep it affixed. --Connel MacKenzie T C 01:49, 9 May 2006 (UTC)

I am still concerned that many entries created by User:Primetime still exist here. Systemic copyright violation was demonstrated, beyond any reasonable doubt. So why should any be retained? --Connel MacKenzie T C 09:48, 8 May 2006 (UTC)

These are probably also Primetime's: Special:Contributions/67.165.217.42. —Vildricianus | t | 10:11, 10 May 2006 (UTC)

This underscores the need for a CheckUser on enwikt; we know he's using open proxies, but we can't block them when he creates accounts (because only CheckUsers can see accounts' IPs.) --Rory096 09:37, 12 May 2006 (UTC)

Discussion here: Wiktionary:CheckUser, but nobody wants to have the power. I could do it, but as a new admin, I'm not sure I'm the right person. Kipmaster 09:46, 12 May 2006 (UTC)

Amgine and Hippietrail want to do it, but I had thought of you as well for the job, Kip. —Vildricianus | t | 10:21, 12 May 2006 (UTC)

Note the latest on Wikipedia: w:User:Jimbo Wales has blocked Primetime indefinitely. --Connel MacKenzie T C 01:37, 22 May 2006 (UTC)

WikiSaurus proposal

Would it be possible to implement a Wikisaurus: namespace in the same style as the Category: namespace? Equivalently, could we move Wikisaurus entries from the main space into the Category: space? For instance, consider Category:Wikisaurus:unhappy and Category:Wikisaurus:pathetic. If sad had templates referencing Wikisaurus, then it would be to these pages rather than any other pages. Because unhappy would also have a template reference, the page Category:Wikisaurus:unhappy would include "unhappy". It would also include any other word that had the template reference to "unhappy" in Wikisaurus. Because pathetic would also have a template reference, the page Category:Wikisaurus:pathetic would include "pathetic". To add a word to that list, one must add the Wikisaurus template to the word's entry, effectively claiming that all of what's listed on the WikiSaurus page are synonyms of a given sense. Davilla 18:05, 8 May 2006 (UTC)

I experimented some months ago with the concept at Category:Wikisaurus:Book. See the talk page for why I (and Richardb) consider the experiment a failure. --Connel MacKenzie T C 03:48, 9 May 2006 (UTC)

Blocking policy for spam?

Did we (the English Wiktionary) ever come up with a recommendation for block-duration for spammers? I'd like to see either an infinite block or a one year block for first offense, but that would be conditional on doing an ISP check though ARIN (or similar.) In the situation where it is an ISP, how long is appropriate? One month? Three months? 2 hours?

It is quite hard to tell if an ISP dynamic address is really dynamic or not. I know US cable companies (e.g. *.rr.com, *.comcast.net/com) and DSL (*.*bell.com, *.sbc.*, etc) tend to be semi-static, changing only once or twice a year. Dial up ISPs obviously give a different IP address with each connection.

Getting spam indicates a compromised/hax0r3d host - and as such indicates a significantly long block is warranted. Does anyone know of a reliable way of determining if an ISP connection is a dail up? I know that many ISPs use a DNS naming convention of "ppp-nnn-nnn-nnn-nnn.ISP.tld" for their (point to point protocol) dailup pools, but that hardly seems reliable.

--Connel MacKenzie T C 17:39, 9 May 2006 (UTC)

Vote for User:TheCheatBot format

Discussion moved to Wiktionary:Votes/bt-2006-05/User:TheCheatBot format.

Misspellings in Wiktionary definitions

There is a list of common misspellings here. Anyone who is looking for a little project might like to run a search (either within Wiktionary, or using Google with the domain set to en.wiktionary.com) for misspelled words in definitions in Wiktionary and correct them. For example, there are lots of "accidently"s in Wiktionary definitions that should be changed to "accidentally". (Note that there is an entry for accidently, an obsolete word, which is correct as it stands and should not be changed.) Unfortunately, the page doesn't always give the usual incorrect spelling, so some will have to be deduced.

There is a link at the bottom of the page that makes the list of words to check grow from 100 to 250 words.

(Incidentally, why does this page have two "+" tabs now?)

— Paul G 11:19, 11 May 2006 (UTC)

(Now that is a really good question! I've never understood why that tab sometimes appears and sometimes doesn't, but it's even more baffling that it's even possible for it to appear twice.... —Scs 14:39, 11 May 2006 (UTC))

("Guess": Because in MediaWiki:Monobook.js there is code to add this "+" tab specifically to Beer Parlour. At some later date, someone added the new magic word __NEWSECTIONLINK__ at the top, which I guess does the same thing, though I cannot be sure until I've saved this as none shows up in edit mode... (Yes, I'm removing it now for the sake of scientific inquiry :) Please replace at will. \Mike 20:13, 11 May 2006 (UTC))

Fun fun. That's my code from when I was first learning JavaScript and wiki customization. The same happens at the Tea room. I've commented out my code since it's slower than the new magic word. — Hippietrail 20:55, 11 May 2006 (UTC)

Perhaps a page could be set up somewhere that lists all of these and records dates next to them saying when that misspelling was last hunted down and eliminated. This would be very useful. — Paul G 11:23, 11 May 2006 (UTC)

Another thing of course is that most (but perhaps not all) of these should have entries in Wiktionary of the form "* Common misspelling of..." (see alot, for example). — Paul G 11:36, 11 May 2006 (UTC)

Isn't our list much more extensive? I've been running my list of typos for some time now - is there a better place for this list to go? --Connel MacKenzie T C 15:01, 11 May 2006 (UTC)

I'm sure you know Wikipedia has a list of misspellings, and it's pretty darn big. It might make sense to update theirs and modify it to your own needs. Seems to be one in the same.

Eventually there must be a solution so that words used in modern English, and only words used in modern English, show in blue. (The others would not be red of course, but neither blue.) Davilla 17:17, 11 May 2006 (UTC)

Um, wow. There is a lot more to your request than I realized the first time I glanced at it. "Modern" English being a sub-language or something? (I assume you don't mean delete obsolete or archaic spellings, but rather have the links appear in a different color or something, right?) I'm not sure how a Wikimedia extension would actually do it, offhand. --Connel MacKenzie T C 14:43, 12 May 2006 (UTC)

In fact possibly not just modern English, but common English, excluding words like therefor and assay, words that raise eyebrows when they're used. This all seems quite a ways off, but anyhow... There must be a point where the software actually looks up the word to see what color it is. Maybe the quality it's looking for isn't called "color", rather "existence" or something, but I would extend that to simply mean the desired color, or add another field to that effect. This would be the only way to do it efficiently. The question is how that field would be filled, how the color would be determined. The difference between blank pages, nonexistent pages, redirects, and real pages is pretty easy to ascertain. But this would require an additional flag, something that could distinguish between good English words and alot of others. It would take someone familiar with the software to determine the best way to do that. A special category is an idea, or maybe using [en:word] on the page just as [fr:word] and others are added for a different special meaning. Incidentally this is a distinction needed only for common English words on the English Wiktionary, only common French words on the French Wiktionary, etc. But it might also be smart to make the solution extensible--so long as it's globally within the Wikimedia: space rather than something where anyone could choose any color for their word. Davilla 16:09, 12 May 2006 (UTC)

:-) Category: Good-er, more betterer English? Seriously though, something like the "stub threshold" functionality (that Vild and I use to make regular entries appear as brown, and redirects appear as blue) shows that this concept is perhaps possible, by modifying the core Wikimedia software. That would, of course, reopen the prescriptivist/descriptivist debate, as to which terms belong in the magic category. Also, I think the developers are (justifiably) leery of touching those sections of code. --Connel MacKenzie T C 18:27, 12 May 2006 (UTC)

You are definitely the most futuristic among us, Davilla :-). I don't have a clue how this would get implemented, and moreover, which criteria would be used for it (what the heck is wrong with assay)? You see, I don't think it's really feasible right now. —Vildricianus | t | 18:04, 12 May 2006 (UTC)

Sounds kinda nice, but... It's not a word alone that is common or not. It is the usage. assay = "the qualitative or quantitative chemical analysis of something" is current, and moderately common, while assay as "trial, attempt, essay" is totally foreign to me. At this poiint I think the idea breaks down, until we have the propsed new version of Wiktionary that has meanings as a separate database item.--Richardb 03:09, 14 May 2006 (UTC)

This is one area where =Reference notes= come into their own. The ones in for alot are really useful. Widsith 17:47, 11 May 2006 (UTC)

Ah, but the page I referred to gives a list of misspellings, not of typos. "Teh" is a typo for "the", while "accomodation" is a misspelling of "accommodation". The difference is that someone typing "teh" knows that the word is spelled "the" (and, if writing with a pen, would write "the"), but someone writing "accomodation" with a pen is unaware that the correct spelling is "accommodation". A typo is a slip of the fingers that is corrected on a careful re-reading; a misspelling is ignorance of the correct spelling and will be overlooked on a re-reading.

If Connel's list of typos already does this job, then that's good. However, it would, as Davilla says, be worth while checking that the list includes the words on the website I am referring to. — Paul G 15:05, 12 May 2006 (UTC)

Could you please add whatever ones that are missing to Wiktionary:List of common misspellings / w:Wikipedia:List of common misspellings? --Connel MacKenzie T C 16:56, 12 May 2006 (UTC)

I spent some time building a proper, simple list from the yourdictionary.com article, so yeah, I can do that. —Scs 03:03, 13 May 2006 (UTC)

Okay, short answers now, longer answers later (because there's a lot more to do here):

1. Our list and Wikipedia's are nowhere near in synch.
2. As complete as the two lists are, there's a remarkable number of words on the two yourdictionary.com lists (misspelled.html and 150more.html) that are not on either of our lists. In fact, I count 105 of them (out of 250). A preliminary list is below.

Among other things, Wikipedia's list is broken up into 26 per-letter lists and a master ""machine format" list. I haven't investigated whether the former are built from the latter, or what.

Here's a preliminary list of the ones we're missing:

• a while
• accelerate
• accumulate
• acknowledge
• acquit
• axle
• barbecue
• bellwether
• broccoli
• camouflage
• cantaloupe
• carburetor
• chauvinism
• chili
• chocolaty
• coliseum
• collectible
• colonel
• column
• conscience
• conscientious
• coolly
• daiquiri
• deceive
• defendant
• defiant
• desiccate

• deterrence
• difference
• diorama
• disappoint
• discipline
• dissipate
• drunkenness
• dumbbell
• ecstasy
• especially
• exceed
• exercise
• exhilarate
• experience
• explanation
• fiery
• flabbergast
• flotation
• fourth
• fulfill
• genius
• gross
• handkerchief
• horrific
• ignorance
• immediate

• inadvertent
• ingenious
• inoculate
• irascible
• jewelry
• judgement
• kebab
• kernel
• lightning
• liquefy
• lose
• magically
• marshmallow
• memento
• mischief
• nauseous
• octopus
• onomatopoeia
• perseverance
• physical
• pigeon
• pistachio
• plenitude
• preferable
• presumptuous
• principal/principle

• publicly
• puerile
• putrefy
• questionnaire
• raspberry
• receive/receipt
• sacrilegious
• sandal
• savvy
• scissors
• sensible
• septuagenarian
• shish
• simile
• special
• supersede
• tableau
• tariff
• their/they're/there
• too/to/two
• tragedy
• twelfth
• ukulele
• vicious
• village
• you're/your

—Scs 05:57, 16 May 2006 (UTC)

Recent changes text

As my computer is... not doing so well right now, can somebody else maintain Special:Recentchanges? I can only get on like once a day, and just for short periods of time, so I don't really have time to do it right now. --Rory096 09:39, 12 May 2006 (UTC)

Pushing for the definitive WikiSaurus name and namespace

Discussion moved from Wiktionary:Votes/2006-05/WikiSaurus name and namespace.

proverb vs an aphorism vs an adage vs a maxim

proverb vs an aphorism vs an adage vs a maxim

I was going to categorise a saying clothes don't make the man as an aphorism. Then saw that there were synonyms too aphorism. And Widsith pointed out we already have Category:en:Proverbs. So what is the difference ? Can we categorise them all as proverbs ? Or should we distinguish betwen them ? (Widsith says its six of one and half a dozen of the other !) --Richardb 17:30, 12 May 2006 (UTC)

This bears a similarity to the abbreviation/acronym/initialism issue, which also has never been properly "solved." That is to say, all sub-categories are more reasonably listed as a combined list somehow, in addition to being listed in their more granular sub-category. On the other hand, a large combined list is often considered to be "too big," here. I think the approach I took with a/a/i categories is a reasonable and useful one, but I know that several disagree. Fresh ideas/viewpoints would help on both these issues, I think. --Connel MacKenzie T C 18:06, 12 May 2006 (UTC)

Customize italicized parenthesized terms

I'm just finalizing a template which allows each user to choose betwen:

1. (foo) — my favourite because it’s beautiful
2. (foo) — butt ugly
3. (foo:) — straight out of satan’s bottom

But to show how impartial I am, I'm making the default #3 since I see it everywhere. Please discuss here which one the majority prefer and if necessary vote on it.

The template is {{italbrac}} - I can change the name if you like. I've used it in the article media. — Hippietrail 21:58, 12 May 2006 (UTC)

• How does one use it in the three different ways? SemperBlotto 22:02, 12 May 2006 (UTC)

  Sorry - I knew I forgot something. See the documentation here: Wiktionary:Customizing your monobook — Hippietrail 22:07, 12 May 2006 (UTC)

• As an added bonus, I've added it to {{idiom}} to show how it can be used with other templates. This is designed to be a very simple single-function formatting template only. But it likes to play with other templates! — Hippietrail 22:18, 12 May 2006 (UTC)

• So, how do you turn off the idiotic parenthesis? --Connel MacKenzie T C 23:15, 12 May 2006 (UTC)

  That is to say, all parenthesis "()" in qualifiers are idiotic and improper. --Connel MacKenzie T C 23:17, 12 May 2006 (UTC)

• .ib-inner, .ib-outer { display: none !important } and depending on whether you want to show or hide the colon set .ib-colon to inline or none, but it seems you must always use !important. — Hippietrail 23:27, 12 May 2006 (UTC)

Now that is beautiful: THANK YOU. --Connel MacKenzie T C 05:16, 13 May 2006 (UTC)

Correct me if I'm wrong. #1 should be the default, and #3 on the example page (as it shows for me) isn't very common. The default style for synonyms is also different, using a colon after the parenthesis.

Perhaps the templates could be named for function, as per {context} below, rather than the current style of parenthesized italics or whatever it may be. Davilla 09:54, 14 May 2006 (UTC)

I also want #1 default but don't want to force my opinions or taste on everyone. I hit random a lot yesterday trying to find what was most common but it was very inconclusive. I also asked Connel to grep the SQL or XML dump for a scientific answer to which is most common, but he hasn't had the time yet. If anyone else can do it please see Connel's talk page for what I need - there are 8 possible variations - I don't know which are in use let alone most common. I can make #1 default but fear less people will notice and therefore less people will come here and comment/vote/opine. As for the colon outside for synonyms, would that be (foo): or (foo): ? — Hippietrail 23:30, 14 May 2006 (UTC)

Due to popular demand of 2 people I've made #1 the default. I guess now I'll hear the wrath of somebody who liked the other way. In any case keep communicating the ideas. P.S. You don't even have to refresh your caches! — Hippietrail 00:35, 15 May 2006 (UTC)

Hoorah. Thank you for seeing sense. There is precedent in print dictionaries for #1. I can't imagine what possessed you to sell your soul to Beelzebub and initially plump for #3 :) — Paul G 10:16, 16 May 2006 (UTC)

Gee, looking at this, this, this and this, I'm left wondering what pagan dictionary you are using.  :-)   The parenthesis are simply unacceptable, (especially) (when) (stacked) (ridiculously.) We should perform a robotic exorcism of these cacodaemoniacal constructs.  :-)   --Connel MacKenzie T C 07:34, 18 May 2006 (UTC)

I don’t have any idea what Hippietrail’s No. 3 is supposed to represent, but as a long-time professional typographer, I can assure you that, in U.S. English, at least, parentheses follow their base contents. That is, if, for example, you put parens around an italicized Latin term such as (hoc), all of it goes in italics. If there are mixed contents, the parens follow the base part: (the Latin is hoc); or (hoc is the Latin word); but (je ne parle pas le English). Usually the contents are not mixed, and parentheses always follow the contents. This goes not only for italics but also for bolding and for choice of typeface. If the contents are Times Roman, the parens are too. If the contents are mixed Times Roman and Arial, the parens follow the base part. If the base content is superscripted, subscripted, or formatted in any other way, it applies to the parentheses as well. This holds true not just for parentheses, but also for single and double quotes, and to colons. If a sentence or phrase ends in a colon, the colon receives the formatting treatment that was given to the base part of the sentence, regardless of how the word immediately before the colon was formatted. For example, "a list of auto parts:" or, "a list of auto parts:". These rules also hold for semicolons, commas, periods, question marks, and exclamation marks. This is why fontographers make italicized parentheses and punctuation that are actually italicized. Some symbols, such as bullets, do not do this, and therefore they are font-independent. —Stephen 18:11, 20 May 2006 (UTC)

Interesting analysis. Now I know why I've always favoured italicized parentheses and colon with these descriptors. Thanks, it's an improvement over all these ugly templates. Eclecticology 09:34, 2 June 2006 (UTC)

This code:
.ib-outer { display:none }
.ib-content { font-variant: small-caps; font-style:normal; }
is just fricking amazing! Absolutely! Perfidiously brilliant! Are we getting {{italbrac}} implemented everywhere? What are we waiting for? —Vildricianus 21:18, 20 May 2006 (UTC)

• In answer to Stephen, #3 is not mine at all, of the 8 possibilites when including variations on whether the colon is inside or outside the parentheses and whether or not it is italicized, all but one are actually used here on Wiktionary. The only one which is mine at all is #1 since that's what I use when I'm adding text. Also, I believe everything you say since you have the experience, but when looking at actual books I see both systems. Just today I saw #1 in a language-related book I was looking at here in Costa Rica. That's why I think giving people a choice is the best answer. It's true that customization requires editing CSS right now and that's too technical for the average user - but hopefully we can improve that too, possibly with interaction from MediaWiki or a developer.
• Secondly, I've removed the colon from this template as the colon is only used in certain situations so it seems. For those situations I have split off a 2nd template, {{italbrac-colon}}. It includes a colon both inside and outside the parenthese so a user will either always hide colons or display the one she wants to see. Outside makes more sense to me, but I'm not an expert. To manipulate the colon here is an example:

  .ib-outer .ib-colon { display: inline; font-style: italic }

— Hippietrail 23:06, 25 May 2006 (UTC)

• I'd like to announce that {{italbrac}} and {{italbrac-colon}} both now take up to 9 parameters and produce (this, kind, of, thing). The commas have a CSS class of .ib-comma for people that might want to make the parenthess and the commas and the contents all italics. Followup questions probably belong in the Grease pit. — Hippietrail 02:33, 29 May 2006 (UTC)

• I've simplified these templates and altered the way their CSS works so you might need to edit your CSS file if you customized it already. Please read the updated documentation here. — Hippietrail 20:22, 29 May 2006 (UTC)

Wiki machine translation?

This hit me today when I was trying to machine-translate some Japanese into English: Knowing some of each language, it would be easy for me to correct the atrocious output of the translator. If there was a way the translator could take my input and use it to guide future translations, translation quality would improve significantly. Like Wikipedia, these corrections could be peer-reviewed.

Anyone heard of such a project? —This unsigned comment was added by 69.181.40.145 (talk • contribs) 06:45, 13 May 2006.

I would guess any attempt at the like would build from WordNet, although I agree that a wiki would be more powerful. I find foreign languages fascinating, and I have my own ideas on how to put a wiki to work, toward a different goal. The difficulty has got to be the programming. Davilla 18:04, 13 May 2006 (UTC)

Machine translation between languages like English and Japanese are notoriously difficult because the two grammars are so very different. Most of the atrocious problems in that area would not be directly remedied by creating a wiki-style system of letting readers expand the translation vocabulary. Just figuring out what to use for the English sentence subject is challenging. Borrowing from Wikipedia:

• 僕は鰻だ
• 僕 ("I"/"manservant") + は (topic marker) + 鰻 ("eel") + だ (copula)
• "As for"+"me" + "an eel"+"is"
• "Regarding me, it's an eel."

In a cartoon with an eel speeking, it might translate as "I am an eel." In a restaurant, however, it translates as "I'd like an eel." So you see, machine translation from Japanese depends on context and would not clearly be assisted by wiki-enabling the word-to-word translation tables. Rod (A. Smith) 21:49, 15 May 2006 (UTC)

Indeed. I'm a professional translator myself, to get the disclosure out of the way.  :) Nonetheless, some of the more hilarious bits of non-English I've run across have been generated by deliberately abusing online machine translation engines. In one instance, translating "My dog has fleas" just from English to Japanese and back again, without going through any other language pairs, results in "there is a chisel in my dog." Wow. I mean, wow. I couldn't smoke enough to get to that point myself, but hey.

Looking into it, it looks like part of the problem stemmed from how the translation engine parsed the sentence -- nomi in Japanese is both "flea" and "chisel", depending on context and subtle grammatical cues. Going into Japanese, the engine decided on nomi ga aru ("flea/chisel" [subject] "exists (inanimate)". Since the verb chosen is only for inanimate objects, nomi here could only be "chisel".

But without the kind of living-breathing-human understanding, any translation based on a word-for-word engine model is doomed to fail -- languages are not so tidy. And without a deeper understanding of both source and target languages, even a human might be hard-put to figure out that "there is a chisel in my dog" was originally meant to convey "my dog has fleas" -- they'd only know that it sounds purty durn weird, and that something was probably wrong, but they wouldn't know how to fix it.

However, the basic idea behind what our anonymous GP poster describes is in fact the way that most machine translation trainers are going, i.e. building up the capabilities of the system based not on word pairs but rather on whole text pairs, with the MT-produced translations edited by knowledgeable humans and fed back into the system. Some of the fancier systems also go about using a statistical analysis of the paired texts to try to predict how to translate similar texts.

As one might imagine, these efforts at building up and correcting a machine translation system are extremely labor intensive, and as such these systems are not cheap. It's also worth pointing out that any such system is limited to what has been fed into it -- if your MT system is all about legal boilerplate, good luck getting it to produce sane medicalese.

The upshot is that humans remain your best bet for flexible spot-market translation needs. MT is great for churning out masses of documentation, particularly if the end result is only needed for informational or in-house purposes, but for a polished finished document you wouldn't be embarassed to post in public, you're still going to need a human at some point of the process -- either as the translator, or at the bare minimum as the editor.

As a side note, those interested in poking about might want to look at Lost in Translation, a funny project similar to the summer camp game of Telephone. Type in a sentence or two, and the website feeds that through several language pairs, showing you how the original changes along the way. "My dog has fleas." became, after seven manglings, "_ with the mine of the dog of the chisel _". I find the punctuation changes most puzzling. Even more interesting, perhaps, is how this process stabilizes past a certain point, where feeding the resultant gibberish in at the front gives you more or less the same gibberish at the end. Food for thought, at any rate. Cheers, Eiríkr Útlendi | Tala við mig 04:21, 16 May 2006 (UTC)

From your description of the way modern MT works, I would think that's possible within a wiki framework, except that the concept isn't transparent to the average person. Wikipedia is successful because everyone knows what an encyclopedia is and therefore the implicit goals of the project. Not everyone knows what an automated translation table of hand-coded text pairing mumbo jumbo database is. In other words, when knowledgeable minds come together to consider the engineering of such a project, the focus will have to be on minimizing the learning curve for your necessarily multilingual contributors. Davilla 17:36, 25 May 2006 (UTC)

categories - toward consensus?

Hi I have been looking at categories and I think there are way too many of them. My difficulty is that if I look for a word, (let us say a technical term I don’t understand) e.g. consanguinity, I would expect to find it in the category []Law]], but not necessarily in a category []Law of persons]], because I wouldn’t know that it related to the law of persons.

This whole discussion is surely based on a false premise. If you are looking for a word consanguinity, logically you would use GO and SEARCH to find the word, not categories. Right ? If you expect to find it in the category LAW, and it's not. Then guess what. You put in the category LAW. No revision of categories is called for at all. This is not Wikipedia.--Richardb 02:38, 14 May 2006 (UTC)

Not to speak for Andrew massyn, but I think the scenario he described is when a reader can't quite remember the word but will know it on sight. Rod (A. Smith) 17:24, 14 May 2006 (UTC)

Ta that's what I should have meant.Andrew massyn

A possible solution for the editor is to put it in []Category: Law]], []Category: Civil Law []Category: Law of Persons]], ]], []Category: Family Law]], []Category: Law of Inheritance]] []Category: Criminal Law]] []Category: Law of Marriage]] but in practice this is not happening. Further, because consanguinity relates to at least three branches of law, as well as the overarching categories, it becomes unwieldy and impossible to deal with.

A second possible solution is to get rid of as many sub-categories as possible. This is the view that I favour. If one is seeking a legal definition, surely one category is sufficient. As commonly pointed out, we are not an encyclopaedia. If one is to distinguish between []law of persons]] and []family law]], this distinction is at its most basic an encyclopaedic definition.

When discussing parts of speech, my view is that the category []English Nouns]] for example is useless. The standard when editing words it to put in the part of speech.

Parts of speech like []transitive verbs]] or (my personal worst) []uncountable nouns]], should be on the article page. Again, if a specialist is looking for the distinction between perfect participles and pluperfect participles, this is not the forum for it.

My thought is to have as few general categories as possible, and if necessary to link between the general categories. Thus for example, the category []Food and Drink]] is good. []Category: Chickens]] is not. Category []Poultry]] (which I created) is not. []Category: Italian Dishes]] is also not. I realize that certain words will get lost in certain categories, e.g. poulter would disappear from []Food and drink]], but could well find itself revived in a []Category: Work and Leasure]]

If there is general consensus, it would entail a lot of recatogorising and tidying up of disused categories, but my personal view is that it is worth it.

What is the community's view on the above? If the answer is in general yes then each category would have to be looked at individually and a decision made on each one. If no then that is the end of it. Andrew massyn 14:27, 13 May 2006 (UTC)

• I am probably unique in that I wouldn't mind if ALL categories were removed. Do we have any evidence that our users actually use them at all to find words (or even know that they exist)? I wouldn't be surprised if the Wiki went faster without them. SemperBlotto 14:33, 13 May 2006 (UTC)

I also tend to this point of view. Widsith 14:43, 13 May 2006 (UTC)

Agree as well. Ordering words by semantic field is something that belongs in a Thesaurus or Appendix. In the main namespace, "temporary" categories, like [<language>:<POS>] for non-English words are useful, though, and I know they're being used. Same goes for maintenance categories like TTBC or RFC of course. —Vildricianus | t | 15:01, 13 May 2006 (UTC)

• Just one point: don't forget that categories are very useful to people interested in languages using another writing. For example, how do you think that hieroglyphs can be found without categories? And this is true for other languages, too. Lmaltier 20:18, 13 May 2006 (UTC)

Agreed. Paul Willocx 20:23, 13 May 2006 (UTC)

Yes, ordering words by semantic field is something that belongs in a thesaurus or appendix, but from where should the thesaurus or appendix acquire the semantic information?

While many categories may be irrelevant to most editors, that does not make them useless. Categories are WikiMedia's way of associating meta-data with entries. It does not hurt anything for each term to appear in its appropriate positions under Category:All languages. There are potential uses for the categorization (e.g. automated thesaurus features, automated phrasebook organization, automated translation) even if any particular user never browses those categories directly in the dictionary portion of the project.

By fixing the problems with our current application of grammar categories, context categories, inflection templates, and context templates, we can simplify editing, gain consistency, and retain the useful category functionality:

• Current problems:

1. It is difficult to know where in Category:*Topics to look for any given word (e.g. "grand larceny").
2. When editing, it is difficult to know the right categories to apply.
3. Editors differ in the names and styles they use for context tags.

• Proposed solution, demonstrated at "grand larceny":

1. Use Category:Inflection templates (e.g. {{en-noun-reg-y}}) to assign grammar categories instead of hard-coding entries with categories like [[Category:English nouns]].
2. Instead of hard-coding things like [[Category:Criminal law]] in an entry, use {{context}}{{cattag}} on the definition line to assign Category:*Topics, e.g.:

   # {{cattag|US|criminal law}} [[larceny]] of [[property]] whose...

   1. (US, criminal law) larceny of property whose...

• Benefits of retaining specific categories:

1. Consistency: Using this system, editors need not concern themselves with how to format definition contexts or with what categories to use for a term, because the Category:Context templates and Category:Inflection templates will handle categorization and {{context}}{{cattag}} will handle formatting.
2. Wiktionary can retain the flexibility to be used as the database for other projects where the software must be able to read meta-data of entries (e.g. in a hypothetical WikiMedia Translator or Thesaurus).
3. Review of topic categories can reveal language-specific deficiencies in, e.g. Category:Criminal law.

Should we branch this conversation off into a new subpage of BP? Rod (A. Smith) 21:39, 13 May 2006 (UTC) (I withdraw my recommendation for {{context}}, as {{cattag}} has precedence.) Rod (A. Smith) 15:42, 19 May 2006 (UTC)

Rod. You could try creating a policy think tank page.--Richardb 02:33, 14 May 2006 (UTC)

Yes, that would be a good way to eliminate any further discussion, as it will remain hidden from everyone's view.  :-) --Connel MacKenzie T C 21:23, 14 May 2006 (UTC)

I know User:Eclecticology was very interested in how the categories were turning out. I also know he has had tremendous influence on implementing the current scheme. I vaguely recall him saying something about a one month wikibreak (although I can't find that reference now) so he should be back any day now. I do not think it would be reasonable to proceed with a large-scale re-engineering of our current category scheme in his absence. --Connel MacKenzie T C 00:49, 14 May 2006 (UTC)

Wow. If Connel is advocating patience, then we definitely must wait!

A "smiley"

Seriously, any contemplation of removing category information (ie:deleting knowledge) must be considered for at least three months before any such destructive action is taken.--Richardb 02:33, 14 May 2006 (UTC) I created a template {{rfcc}} for category page cleanup a while back. And I've just updated it by adding these words to the banner heading. A category page should/must include a description of what the category is for, and how it fits into any structure of categories and sub-categories.. My view is that we should pounce on any new categories that are created (but how to detect them ?) as quickly as possible, and ask the user who created them to document what the category is for. For a category without an explanation is often a waste of time indeed. I'd be happy if we could tackle/cleanup (by consensus, and the cleanup process) some of the categories which have very few entries and no explanation.--Richardb 02:47, 14 May 2006 (UTC)

Since this is the first time {{rfcc}} has been announced here, should we wait three months before using it then? --Connel MacKenzie T C 21:23, 14 May 2006 (UTC)

I agree with a lot of the above discussion, such as templates being the primary force by which categories are added, and the cleanup of categories tackling the sparsely and over-populated before any others.

I'm not up-to-date on which templates are used to show context. I always hard-code, which means categories aren't being added. Is there a way to add multiple, arbitrary contexts such as chemistry and physics, or logic and computer science, to a single definition? And are these contexts narrowly enough defined for our purposes? Davilla 09:48, 14 May 2006 (UTC)

My suggestion above (which I should move to a policy think tank) is to have a complete set of context tags, exactly corresponding to the tags that editors want to display on the definition line. Each of those context tags will have both display text (e.g. chemistry) and a set of categories (typically one per context, e.g. Category:Chemistry). The display formatting (i.e. the parentheses and italics) would be handled by {{context}}. It will then be easy to manage what contexts are in use at Wiktionary. Rod (A. Smith) 17:24, 14 May 2006 (UTC)

I don't think it is a good idea to limit the potential sub-category breakdowns while Wiktionary is still in its current embyonic state. Having a uniform way of adding them (such as {{cattag}}, {{cattag2}} or {{context}} has several benefits. --Connel MacKenzie T C 21:23, 14 May 2006 (UTC)

I absolutely can't stand the numbers added to e.g. see also templates. Isn't there a way to take an arbitrary number of arguments? Regardless, these need to be funnelled somehow so we don't end up with categories soccer, Soccer, football, Football, soccer (football), Soccer (football), Soccer (Football), and probably a few items under "foot ball". But before that can be tackled we need to know how subcategories will be handled. There are too many open questions at this point! Davilla 20:41, 15 May 2006 (UTC)

{{cattag}} and {{cattag2}} predate the ability to have parameter defaults in templates, IIRC. Perhaps {{cattag}} (category + tag) should be upgraded to our current standards. The lcfirst: and ucfirst: magic keywords also did not exist when these templates were created, but should be used now. --Connel MacKenzie T C 21:07, 15 May 2006 (UTC)

OK, {{cattag}} now takes up to nine (9) such tags. --Connel MacKenzie T C 21:14, 15 May 2006 (UTC)

Modified using template:foreach Davilla 02:17, 29 May 2006 (UTC)

• Did I hear somebody say they don't like categories altogether? Well if so, please see here for how to ignore the whole concept. — Hippietrail 04:55, 16 May 2006 (UTC)

I admit that in my efforts with categories I never got down to writing a description of what I was doing. It was basically hierarchical where everything could be traced back to Category:*Topics. The asterisk insures that it is listed first in the list of categories. Foreign words could be developed in an exactly parallel fashion. English categories should always begin with a capital letter; foreign language categories begin with a lower case language code. The value of this is in its effect on sorting.

There are some categories like "English nouns" that contain too much to be useful. I usually remove it when I'm editing an article, or I leave it in only temporarily if the word is not yet in any other category.

It's conceivable that a properly organized Wikisaurus could replace the categories, but until that idea is working correctly it would be unwise to start removing categories. Eclecticology 10:25, 2 June 2006 (UTC)

reflexive verbs

This is an issue which concerns certain languages which use reflexive pronouns. There are some (not many actually) entries for reflexive verbs, eg French se lever. But I think that's a bit silly, and that it would be better going under the lever page, on a def line having a (reflexive) marker instead of a (transitive) one. Is there any policy on including reflexive pronouns in the page titles? And what do others think? To me it seems a bit like having a page for kill oneself etc. in English. Widsith 11:23, 15 May 2006 (UTC)

• Well, the Italian entries (e.g. lavarsi) are useful bacause the conjugations are not always obvious - the pronoun shifts from in front to behind in different tenses / persons. SemperBlotto 11:31, 15 May 2006 (UTC)

Yes, I'm familiar with that for Spanish; but the changes are entirely regular and never alter the stem (don't know if it's the same in Italian) – also, that implies you'd also need entries for lavarmi etc etc - I think personally all of them (including lavarsi) should be redirects (of some kind). The forms are very obvious to anyone who knows the language even slightly, or at least that's the case with Spanish. In French of course the pronoun is always a separate word so there's even less call for it, IMO. Widsith 11:36, 15 May 2006 (UTC)

I agree with Widsith. Reflexivity, if you will, is just one possible option of the transitivity of verbs, at least in Spanish and French verbs. That is, some verbs are intransitive, some are transitive, some are reflexive, and some have multiple senses including some from each of those categories. So, by analogy with plural entries, the reflexive entries (at least for Spanish and French verbs) should redirect to the primary entries or should have a simple definition pointing to the verb's main entry (e.g. on "lavarse": "# {{reflexive of|lavar}}"). The main entry then shows the different senses, including intransitive, transitive, and reflexive. Rod (A. Smith) 15:26, 15 May 2006 (UTC)

I don't see the value of diverging so far from standard en.wiktionary practice. We have separate entries for each spelling. So something like lavarmi should never be just a redirect. But, as Rodasmith indicates, the wiktionary way, would be to have a short entry for it, indicating it is a form of lavar. This is especially helpful for those of us who speak English, but not Spanish.

I strongly agree with Widsith that "reflexive" should be a definition-specific qualifier, at the start of a definition line. I don't object to having an entry for French se lever. But it seems to make more sense if listed as a definition line of lever#French, under verb, qualified as {{reflexive}}. --Connel MacKenzie T C 16:00, 15 May 2006 (UTC)

I don't agree here; I support having these entries on separate pages (see zich herinneren). My reasoning here is that sometimes, it's possible that there is no non-reflexive variant (see zich gedragen vs. gedragen). Vildricianus 19:05, 15 May 2006 (UTC)

But even in that case, wouldn't it still be better to define the word just once, rather than at every variation of the reflexive? How have you singled out which form to use? The other pages aren't filled out, so I don't know what you have in mind. Davilla 20:48, 15 May 2006 (UTC)

• I think we should do just as we do with past and present participles. Sometimes they have a special sense as an adjective which warrants a full entry, when they don't they can have the mini entry or be a redirect. A case I can think of that coincides with a spelling in another language is ver → verse (in a way parallel to dar → dame). Print dictionaries always carry the reflexive senses in the same entry but after putting the reflexive spelling in the same font and style as the headword. There are a few words which have no non-reflexive sense and these are then the primary/only headword. — Hippietrail 04:31, 16 May 2006 (UTC)

• Except that we don't do redirects for English past or present participles. Short entries: OK. Redirects: not OK. --Connel MacKenzie T C 05:43, 16 May 2006 (UTC)

  Good. That's what I prefer anyway but I didn't notice when it became our official policy. Is it the same for alternative spellings now too? — Hippietrail 20:47, 23 May 2006 (UTC)

Also, in Italian (don't know about other languages) there are some verbs (addirsi "to be suitable", for instance) for which there is no "normal" form (I'll get round to it sometime). SemperBlotto 10:28, 16 May 2006 (UTC)

Changed Proposal for Policies and Guidelines to Semi-Offical Status

After giving notice in February, I have now upgraded Wiktionary:Proposal for Policies and Guidelines to Wiktionary:Policies and Guidelines - Policy, and changed the status to Semi-Official.

At this time, I will leave the redirect in place, and will slowly replace the important links.--Richardb 12:09, 16 May 2006 (UTC)

Urgent: experiment gone wrong??

I've got some strange bugs right now that weren't here this afternoon:

1. HTML displayed as text: This is a <a target="_blank" href="/wiki/Help:Minor edit" class='internal' title="Minor edit =typos, formatting etc (opens a new window)">minor edit</a>
2. Contents of edit box being reformatted - adding linebreaks.

I do have custom stuff in my js but it wasn't doing this before. The global js doesn't look changed. I'll doublecheck my js now but just in case somebody is doing js experiments somewhere, I'm reporting it here so it can be stopped soon. — Hippietrail 23:31, 17 May 2006 (UTC)

• 1. 2 seems to be a false alarm. It looks like it was some weird dormant side-effect of my own custom js. Still, if you do see anything odd, best report it here just in case. #1 is still current though... — Hippietrail 23:37, 17 May 2006 (UTC)

• Goofy. I'm seeing #1, too. Specifically, next to the "this is a minor edit" checkbox on the edit page. Somebody changed something, that's for sure! Anybody want to 'fess up? :-) —Scs 01:56, 18 May 2006 (UTC)

You all probably know this, but that's the text of MediaWiki:Minoredit. The MediaWiki server for some reason no longer believes that the HTML there is balanced and so it's escaping the HTML. No changes or deletions have recently occured on that resource or anything near it, though. Seems like a bug. Could an admin please try making a minor change to MediaWiki:Minoredit to see if that kicks the server into re-reading it? Rod (A. Smith) 03:13, 18 May 2006 (UTC)

Word of Day

Who's in charge of updating the word of the day? Is there a bot for that? JillianE 13:47, 18 May 2006 (UTC)

I think User:EncycloPetey has been most active populating them. But I know there have been several requests for additional volunteers to assist with adding new entries. --Connel MacKenzie T C 14:11, 18 May 2006 (UTC)

In case you were wondering how it changes at 00:00 UTC: that happens automatically. —Vildricianus 19:39, 20 May 2006 (UTC)

Wiktionary:Spelling Variants in Entry Names - Draft Policy

I've incorporated the suggested improvements. I think the policy is now ready to upgrade to "Semi-official" status. Which I will do in one month, unless the debate remains active at that time.--Richardb 11:03, 19 May 2006 (UTC)

I've changed its name to Wiktionary:Spelling variants in entry names. The convention is all lowercase, and policy status should not be reflected in the page title. —Vildricianus 19:37, 20 May 2006 (UTC)

any Hebrew scholars here?

The pages דניּאל and בּית שׁמשׁ don't have language headers. I don't know whether they're properly classified as "Biblical Hebrew" or just "Hebrew". —Scs 12:43, 20 May 2006 (UTC)

They are the same in both Biblical and Modern Hebrew, so I just put the ==Hebrew== heading. However, they should not be pointed, so I moved them to דניאל and בית שמש. —Stephen 17:33, 20 May 2006 (UTC)

I've been attacking a plethora of these just on the most basic formatting. Do all the entries that were spammed here from the "Strong's" concordances go under just ==Hebrew== then? --Connel MacKenzie T C 23:02, 20 May 2006 (UTC)

CheckUsers for en:wikt (revisited)

It's time to get it moving, right? Does anyone object to a vote for CheckUser status for any of the nominees here, or to a CheckUser at all on en:wikt? Now is the time! Please read m:CheckUser Policy and m:Help:CheckUser before considering. This would not be your average admin (or even bureaucrat) election, so it should go with even more consideration than at WT:A. Keep in mind: the thing here is not only confidentiality, but also technical ability on top of that. Nominees are also supposed to be aware of the Wikimedia Privacy policy. And lastly: as per m:CheckUser#Access, a Wikimedia project is supposed to have at least two CheckUsers, or none at all, to allow mutual checking. If no serious objections arise, I'll start three voting-style nominations at Wiktionary:CheckUser for the users who showed interest. —Vildricianus 21:01, 20 May 2006 (UTC)

possible music theory copyvios

I've come across a bunch of musical theory terms entered by User:Hyacinth on 2004-04-29. Examples: artificial grammar, metrical structure, time-span reduction, transposition, well-formedness rules. The formatting is poor and the definitions are fragmentary, and they appear to be copied verbatim out of some music theory books -- though at least these are cited. I've lightly edited a couple of them, but something more major is probably in order. Opinions? —Scs 02:00, 21 May 2006 (UTC)

When you say "appear to be copied verbatim" do you mean you found the publications online, or you have a copy of that book handy? (Sorry, but the word "appear" makes your statement slightly ambiguous.) --Connel MacKenzie T C 02:02, 22 May 2006 (UTC)

No, I don't have copies of the publications. But look at artificial grammar and the others; you'll see what I mean. —Scs 14:02, 22 May 2006 (UTC)

What does "appear to be copied verbatim" mean? If you read the record, dmh had given Hyacinth some pointers a couple of years back, to which the contributor in question commented that he had "copied [some of the] definitions almost verbatim". Davilla 00:27, 23 May 2006 (UTC)

I meant, the wording appeared to be more what a formal textbook would use than a random wiktionary contributor would use, and furthermore, the definitions are in many cases in quotes, as if to say, "I quoted this directly from the source I'm citing". And I did notice the contributor's comment, which only confirmed my suspicions. (Lastly, the quoted fragments aren't really in the form of dictionary definitions, either, and could use cleanup for that reason alone. I would have embarked on that, but in cases of systematic copyright violations, sometimes it's better to delete and start from scratch. Which is why I asked for opinions before proceeding.) —Scs 02:28, 23 May 2006 (UTC)

Warning: funky notice - Revamping Beer parlour

Brainstorming still proceeding on Wiktionary talk:Beer parlour. Please comment on any of the proposed solutions, or your 56k modem will die. —Vildricianus 21:48, 20 May 2006 (UTC)

Topic deferred for the time being - temporary solution found. —Vildricianus 18:46, 30 May 2006 (UTC)

Italics

Why are quotations here set all Italic? Isn't a seperate line and indentation enough? I mean, the Italics along with boldface for the entry word looks like something from a comic book. I've never seen it in a dictionary. We're already using Italics for the notes, and Italics are used for foreign words and words referred to as words. It makes them stand out. I changed it for realize, but someone reverted me. I'm going to change it back again.—Uulgjm 18:00, 21 May 2006 (UTC) Primetime (talk • contribs • global account info • deleted contribs • nuke • abuse filter log • page moves • block • block log • active blocks)

Mentioned sentences must be distinguished from used sentences to avoid confusion. Otherwise, it would appear that Wiktionary is making the claims of the quoted authors. Traditionally, quotation marks or italics make that distinction. Rod (A. Smith) 19:17, 21 May 2006 (UTC)

According to WT:ELE, your edit of realize was quite unhealthy. We don't work with submeanings here. As for the quotations in italics: you're correct, they should be in normal font style, whereas italics is reserved for example sentences only. —Vildricianus 19:34, 21 May 2006 (UTC)

The Webster's entry for "realize" that the entry was copied from merges half the meanings. So, I don't know why you guys don't use submeanings, but it makes it much easier for the reader, who doesn't have to hunt down a long list of nearly-identical definitions. I usually use double bars || à la Larousse and Espasa-Calpe house style. Merriam-Webster uses bolded letters (a.) and others use letters in parenthesis like this: (a) or even just numbers in parentheses like this: (1).—Uulgjm 19:50, 21 May 2006 (UTC) Primetime (talk • contribs • global account info • deleted contribs • nuke • abuse filter log • page moves • block • block log • active blocks)

We have experimented with submeanings (see deal for example), but they are not yet official policy. You might have a point that realize needs some attention, but ignoring the established style here just because you don't like it is not a good approach. Widsith 19:57, 21 May 2006 (UTC)

We don't, for the sake of translations, for one. The only acceptable format would be double ##, if we were ever going to use it. Personally, I don't believe in the idea of subsenses, but that's not relevant here. —Vildricianus 20:39, 21 May 2006 (UTC)

It would be kind of cool if the software recognized ## not as a new list but as a continuation, indented. Then you could have:

1. General meaning

2. Narrower meaning

3. Et cetera

Davilla 20:50, 23 May 2006 (UTC)

I apologize for not replying on your talk page, immediately after clicking [rollback]...I got tied up with other concerns. I'm glad to see you found an appropriate place to ask your questions, and have them answered (much as I would have.) --Connel MacKenzie T C 21:37, 21 May 2006 (UTC)

Language wikification in translation tables round 7

I feel kind of moronic bringing this up yet again, but, I feel even more moronic looking at these funky translation tables. You guys know how perfectionist I am :-). Now listen, let me sing another tune than last time: what if we settled on "not wikifying any darn language at all in the translation tables." Sounds tough, huh? I've come to believe that either one of both extremes (all or nothing at all) is still a way better solution than the current randomness. But promised, you won't hear me again on this one from now on. —Vildricianus 21:30, 21 May 2006 (UTC)

That would certainly be closer to a NPOV. It would also be much easier to parse (programmatically.) WT:ELE could then be unambiguous, therefore less confusing to newcomers. --Connel MacKenzie T C 21:36, 21 May 2006 (UTC)

Thank God, I thought I was the only one who wanted this. I agree! Widsith 17:01, 22 May 2006 (UTC)

• I think it's always useful to have unusual, rare, or exotic English words wikified to promote their lookup. Many language names fall into this category. Other issues such as parsing and worrying over why Esperanto or Yiddish is wikified in one table and not in another seem quite trifling and solvable. To me at least, wikifying hard words is good for the user, the other things are difficult in minor ways to editors, but if they're worried about them they can just ignore them and leave it up to other people. — Hippietrail 20:34, 23 May 2006 (UTC)

That's what I used to think as well, but I've gathered a number of opinions on it:

• It's not NPOV, unless we adopt some serious criteria for dewikification.
• It's inconsistent and promotes arbitrariness.
• It's very confusing for newcomers and has become one of the most FAQ.
• For the tech-minded: it makes Wiktionary harder for a bot to analyse.
• It's ugly and absolutely unprofessional.

Your arguments could also count for the option "wikify all languages," which is also better than current practice. Rules of thumb, however, depend on personal judgement and knowledge, and are therefore likely to differ widely among editors. That can be considered a bad thing, for the reasons given above, and it will only become less "trifling and solvable" as we grow bigger and bigger. PS: I even found a post in my talk page archives on it. —Vildricianus 10:26, 24 May 2006 (UTC)

Absolutely agree that we should be nice to readers and make "hard words" easy to explore, but I really, really don't like the disparity of having some languages linked and some not. It looks weird, it's hard to parse, and it makes it unnecessarily hard to document for new editors how it is they're supposed to compose language headings and translations. I wish there were some completely different way to provide the convenience link to the language name, one that didn't have this disparity problem at all. Barring that, maybe we should just throw in the towel and wikify them all... —scs 02:22, 8 June 2006 (UTC)

translations to be checked

What's the right way to handle translations to be checked? Tag them with {{ttbc}}? Keep them in a separate section (perhaps "Translations to be checked"), tagged with {{checktrans}}? Both?

I ask because currently there are a lot of uncertain translation that are not tagged in either way, but are just listed in a section labeled with some variation on "Translations to be checked", and I'm worrying that those will never be found, let alone checked or fixed. —Scs 21:56, 22 May 2006 (UTC)

Both. It should be like this:

=====Translations to be checked=====
{{checktrans}}
*{{ttbc|French}}: [[mot]]
*{{ttbc|German}}: [[Wort]]
etc.

—Vildricianus 22:02, 22 May 2006 (UTC)

Cool; that's what I had almost convinced myself of. Thanks for the confirmation. —Scs 23:11, 22 May 2006 (UTC)

If you are feeling lazy, you can put them in a separate section with only {{checktrans}} and my Javascript/cleanup lists will catch it on the next XML dump. It is best if you just do as Vild indicated above, though. Someone indicated there was some desire to depricate {{checktrans}} a while back, in deference to {{ttbc}}. Perhaps we should start removing {{checktrans}} from entries that are "properly" TTBC'ed? Or is it felt that the combination is still the best approach?

For translation sections that are still in the original 2003/2004 "one translation only" format, I'm marking them with {{rfc-trans}} as I find them. --Connel MacKenzie T C 23:24, 22 May 2006 (UTC)

The {{checktrans}} template should be retained because it contains useful information on how to check the translations and what to do when all the translations have been checked and tabulated. It also contains two categories. — Paul G 10:09, 23 May 2006 (UTC)

Wiktionary:Tutorial

Rather here than at RFC: somebody needs to go through it and clean it up a bit. A lot of things seem outdated or simply erroneous, and it seems that newcomers really use it. Any takers? —Vildricianus 21:59, 22 May 2006 (UTC)

True, I had a helpful newbie say that (s)he is reading through Wiktionary:Tutorial (Wiktionary links)#Linking dates, and (s)he wikified the dates, which I thought we didn't do. I'll have a go at tweaking the pages, but ideally someone who's been here longer than me should tidy it up (I'm still a relative newbie, Dangherous has been a regualr just over 5 months, and there's probs quite a bit I'm still unfamiliar about. --Dangherous 09:53, 24 May 2006 (UTC)

Images

Could I ask that people adding images to pages put them at the top (as the very first line of the entry)? Two pages that I have edited today include images that were lower on the page and overlapped the content, making it unreadable. The user shouldn't be required to change the size of their browser or the screen resolution in order to be able to see everything. (Indeed, this is not always possible - I have my flat screen and the browser set to their maximum respective resolutions, and the content was obscured.) — Paul G 10:12, 23 May 2006 (UTC)

• You mean like this [1]? Can you try it without the hard-coded image size, maybe that will work better. Kappa 11:55, 23 May 2006 (UTC)
  • {{wikipedia}} will often be on the first line, though. —Vildricianus 13:27, 23 May 2006 (UTC)

We don't have set rules on image position, because there are so many exceptions to each rule. I agree that the layout seems to work best with the image(s) opposite the TOC. I believe WT:ELE suggests placing an image near the definition it applies to, but I find that this does not often work very well. The most common mistake I see with images is forgetting the caption, with seems to break the "float=right" if they keyword "thumb" is also used. Hard-coding the thumbnail size is rarely the best approach. --Connel MacKenzie T C 14:14, 23 May 2006 (UTC)

The TOC is almost invariably much narrower than the page, ensuring that there is room for the image in most cases, so this is usually a good position. Putting it anywhere else, there is no guarantee that the content and the image will not overlap or obscure each other. The layout for light bulb seems to work well, as the text wraps before it reaches the image (at my resolution, anyway).

Look ugly to me. Chops into the horizontal rule, and anyways I usually scroll down immediatly, ignoring the TOC. It's almost impossible not to do it automatically after a while. Hmmm.... it's odd that we would require scrolling down on every page to get to the meat. Davilla 20:45, 23 May 2006 (UTC)

You can hide TOCs in your preferences. —Vildricianus 09:33, 24 May 2006 (UTC)

My "preference" is to see the page exactly as do 90% or more of visitors. Maybe the TOC should be collapsed by default? Davilla 17:16, 25 May 2006 (UTC)

{{wikipedia}} can go at the top, of course, but I think it is preferable to put it between the POS and the inflections, as this puts the link next to the word it refers to and usually does not introduce any extra whitespace. — Paul G 14:45, 23 May 2006 (UTC)

Yes, but I found multiple instances where that placement is not good, for example when the boxy templates are in place. —Vildricianus 17:04, 23 May 2006 (UTC)

I prefer to place the image in that sweet spot, between the POS and inflections, because of the edit links. The pedia box can go there alternatively, or otherwise, with both, I bump the latter down to somewhere below the translations. Davilla 20:45, 23 May 2006 (UTC)

I put the image on the line below the language header, which is a mix between top-placement and placement relevant to the entry (e.g. la:libellula). I think it looks more balanced than the placement under the POS header (e.g. la:canis) which can leave text spilling around it. It's also better for if there have to be multiple images (e.g. la:Venus). —Muke Tever 23:07, 24 May 2006 (UTC)

Why aren't Categories made more use of? - proposal

This is a proposal for a system that would make Wiktionary easier to use. I don't know if it's in the right place - if not, someone move it please.

Consider: If every translation/thesaurus reference was made as a categorisation, you'd automatically set up a much easier translation and thesaurus mechanism.

Fully explained:

Say you are writing an article about the french word Travailler. Under "translations" (or rather, just under it's meaning in english), instead of just writing its translation ("# work"), use a template-call ("{{t|work|fr}}"). Then template {{t}} would have the following contents:

# {{{1}}} [[Category:Translation: {{{1}}}|{{{2}}} {{PAGENAME}}]]
where {{{1}}} is the english translation of the word
      {{{2}}} is the language code of the foreign word

This would generate the same output (i.e. "# work") but would simultaneously categorise the french article as a translation of "work".

Then in the article on the english "to work", a simple link to the category Category:Translation: work ([[:Category:Translation: {{PAGENAME}}]]) will automatically draw you up a list of every translation in the Wiktionary.

This process would work equally well with WikiSaurus. --w:User:Alfakim

It does have the difficulty — at least for translations — that the category itself will not be usable: If someone is looking for a French word for something, say, they won't be able to find it, because it wont be labelled as French in the category listing (sort keys are not displayed, as your proposal seems to indicate). However it might be usable for thesaurus. —Muke Tever 22:55, 24 May 2006 (UTC)

Hint: WiktionaryZ :). --Celestianpower ^háblame 09:05, 25 May 2006 (UTC)

Yeah, I know about Z. It isn't much use though, as it won't let me put stuff in in my language :p And Z last I checked doesn't do translations as categories either, having the more redundant step of sharing all translations under every entry. —Muke Tever 00:26, 26 May 2006 (UTC)

This encounters the same problems as the use of categories for Wikisaurus (See above references under my #Wikisaurus proposal). However, I think it's right to think of the issue in this way. Would it be possible to someday make Wikisaurus multilingual? Depends on the success of WiktionaryZ. Davilla 17:12, 25 May 2006 (UTC)

redirects from caps to lowercase

I've been noticing a lot of redirects from the capitalized version of words to the uncapitalized where the uncapitalized entry doesn't exist. JillianE 16:26, 24 May 2006 (UTC)

Examples?

My first guess (BICBW) is that they're to entries that were deleted, but someone forgot to delete the redirect. —Scs 17:47, 24 May 2006 (UTC)

• Inflected forms were, for a very short time, entered as redirects, until that was deemed unacceptable. Then along came the case-conversion. Since that time, I've deleted many/most of those redirects, leaving the capitalization redirect for when the 'bot-uploaded inflected form is entered. Now that the latest vote has expired (with the clear knowledge of the most abusive objector,) this "problem" can finally be fixed. As soon as I clear up a few other things first, that is. --Connel MacKenzie T C 06:38, 25 May 2006 (UTC)

pronunciation of names/places

I noticed that, in wiktionary, the pronunciation of names of people or places, like Washington, is not labeled. I am wondering if it can be added. This could be very useful in many ways. For example, it would be polite to be able to pronounce someone else's name correctly. Of course it can be done by directly asking the person. But what if I am reading an article and would like to remeber the name of the author. I found that it becomes easier to remember a name if I can pronounce it. In academia, researchers are from all over the world and it would be of great help if their names can be pronounced properly.

I googled the web and found some websites related to this idea:

The first one is an online, automatic name pronunciation program developed at Carnegie Mellon University. But now it is not usable. the synthetic pronunciation probably is not good enough.

The second is a website about how to pronounce Finish names, which is similar to what I have in mind. But it goes further by providing recorded pronunciations.

Massachussett State has a webpage asking people to notate how to pronounce their hometown and Arizon State also has a website showing how to pronounce the town names of Arizona correctly.

By using Wiktionary, I believe a wider range of names and places can be incorporated. Since a person is authorative on how to pronounce his own names, everyone is encouraged to put his name in Wiktionary and notate his pronunciation in a proper way.

I am new to Wiktionary and would like to have your opinions.

This is definitely something Wiktionary can and does (in some cases) provide. If examples you have looked up here have been without pronunciation info, that is probably just because proper nouns have not received a huge amount of attention here. Also, the extent to which we include minor or obscure place-names is still open to debate. However, if you have specific requests in mind, you could add them to Wiktionary:Pronunciation_file_requests and you should get what you need. Widsith 19:18, 24 May 2006 (UTC)

Yes, there is definitely debate on the more obscure placenames, esp. their inclusion as specific places rather than under a generic placename label. Davilla 17:07, 25 May 2006 (UTC)

It sounds like you're interested in a batch process to accomplish this. The computerized weather channels have a good amount of hand-coded pronunciation information that they may be willing to share. Of course the format wouldn't be the same and requires processing, but you could be sure the pronunciation of place names matches what is used in the place itself. (This is the goal, right, to list "Houston" as /hjustn/, rather than /haustn/ as in New York's "Houston Street"?) I remember hearing that the automatically generated pronunciations had failed miserably at this. Davilla 17:05, 25 May 2006 (UTC)

new word posting

I have a suggestion for a new word, for a specific purpose, in the English language. As far as the distinction between a protologism or a neologism, I hope I'm getting those words right, I have not heard the word used before, googled it, and came up with 2 usages, both agreeinging with the meaning I propose.

I tried to put it in as a neologism, no luck with figuring how exactly to do that, and had the same luck with the progologism.

any suggestions? thanks p —This unsigned comment was added by 68.35.9.33 (talk • contribs) 2006-05-24 23:46:12.

Did you see Appendix:List of protologisms? That's the best place for such words. If you did try there, what problem did you experience? Rod (A. Smith) 23:58, 24 May 2006 (UTC)

Maybe time to rewrite Wiktionary:Neologisms? Davilla 17:23, 25 May 2006 (UTC)

Change Logo to SVG-Version

Hi there! Please change the logo in Template:wikibookspar, there is an vector version available: Image:Wikibooks-logo-en.svg. Regards, Schaengel89 09:45, 25 May 2006 (UTC)

I'm not sure why we'd want that. I thought all logos were supposed to be kept locally, for times when commons is experiencing a slowdown (all too frequently.) The template protection has been lowered to "semi-protected" though. It is not clear to me what the correct action here should be. --Connel MacKenzie T C 15:48, 25 May 2006 (UTC)

Also, since SVG support is not quite universal in browsers yet, I'd say that logos should remain GIF or JPEG for a bit longer. –Scs 18:08, 25 May 2006 (UTC)

Just a note, that the MediaWiki servers produce PNG thumbnails "on the fly" for SVG images. Users will only encounter the actual SVG if they click through and try and open the original file. Regards, commons:User:pfctdayelise 07:20, 28 May 2006 (UTC)

French Beer parlour

Does anyone happen to know what the equivalent of the Beer parlour is on Wiktionnaire, the French wiktionary? That's the place, not the translation (which apparently is "arrière-salle", meaning "back-room"), please. I'd like to post a question there. Thanks. — Paul G 11:43, 25 May 2006 (UTC)

This page has an interwiki link to Wiktionnaire:Wikidémie on the left-most column. --Connel MacKenzie T C 15:44, 25 May 2006 (UTC)

Great; thanks, Connel. — Paul G 10:30, 30 May 2006 (UTC)

Mind if I move this to WT:ID? I think newcomers would be encouraged to ask more questions, when they see a BC asking questions, too. --Connel MacKenzie T C 00:21, 31 May 2006 (UTC)

part-of-speech header for articles

Since there's one definite article in English and two indefinite ones, it would make more sense to me for the level-three header for all of them to be just "Article", not "Definite article" and "Indefinite article". Any objections to coalescing them in that way? (The point being, that if you think of part-of-speech as a category, a category with just one thing in it seems kind of useless.) –Scs 15:05, 25 May 2006 (UTC)

Not sure I care either way but kein and keine are German indefinite articles and der, die, das are German definite articles.JillianE 15:52, 25 May 2006 (UTC)

Ah, good point -- I always forget that the English Wiktionary isn't just English! Although I notice that der, die, and das are sitting under headers that just say "Article".

Looking at Patrik Stridvall's header tool, I see that as of 5/3 we had 40 articles, 49 definite articles, and 18 indefinite articles. –Scs 18:01, 25 May 2006 (UTC)

• Ec used to change these to "Adjective". I don't know if he changed his opinion or practice, but you might keep it in mind. As always, I advise people to check what print dictionaries do since they are made by trained proffesionals, we can learn from them. — Hippietrail 20:14, 25 May 2006 (UTC)

I think =Article= is fine, as long as you find somewhere else in the entry to say whether it's deifinite or indefinite. Widsith 06:40, 26 May 2006 (UTC)

Agree. There are different ways to look at parts of speech depending especially on the language, and there has been a move to keep these as simple as possible. Davilla 14:05, 28 May 2006 (UTC)

Discussion of multi-word lexical items on lexicographers' mailing list

This topic may be one to watch for many of our contributors and other interested parties. Please even join the list and take part. I'm subscribed but I can find a website that provides access here. Please don't miss this opportunity. We can all learn from trained lexicographers. — Hippietrail 21:45, 25 May 2006 (UTC)

The purpose of RFD

Moved from RFD; interesting discussion, broad target, shouldn't get lost amid the heaps of RFDs. —Vildricianus 22:47, 25 May 2006 (UTC)

I've broken these meta-comments off from the above discussion about vintage car. Davilla 19:17, 9 May 2006 (UTC)

• What do we have here? Hippietrail called for the deletion of a term he knew from the start would never be deleted. Why? <cough>POINT</cough>. I'm very sorry, but nominating something for deletion is just plain silly.

• I do understand HT's frustration regarding including phrases in this dictionary. But I still (as I did a year ago) disagree about 95%. While we have no strict policy, the Pawley list seems the most reasonable set of tests we've encountered so far. Certainly in a wiki, where ultimately we will have all those entries, it seem quite counter-productive to be fighting it. Especially when numerous people disagree completely...not just on the impractiacality of enforcement, but rather on the basic priciple he is trying to assert; that multi word nouns are not nouns. I maintain, as I did a year ago (and before then) the opposite. --Connel MacKenzie T C 06:52, 9 May 2006 (UTC)

• I was thinking about this all night and I think we have some basic problems on Wiktionary. Anybody should be able to dispute a term, sense, criteria for inclusion, policy, etymology, pronunciation, translation, etc, without a fight breaking out. I RFD'd this because that seems to be the way we dispute something here. Maybe I should've RFV'd it instead but to me at the time RFD made more sense and it's what I'm more used to. So it seems that RFD'ing an article is interpreted by some as an attack on the article and even an attack on other contributors. This is silly. I think we need a better way of disputing articles in such a way that we can all be adult about it. Perhaps RFV is that way, perhaps a new place to list articles under dispute, with a small banner on disputed pages. Isn't this what Wikipedia does? Further, I think it might make a lot of sense to carry out the disputes on the articles' talk pages rather than here (or RFV) - these pages can be instead lists of links with perhaps a line of text indicating the current status of each dispute. Disputes which involve more than one page might be better off here than in the talk pages.

  No, RfV would not be correct as it's clearly a common noun phrase. The problem is that there are several levels of these requests, and people take offense. Some material is uncertain and needs to be checked first. A lot of this turns out to be cruft, but there have been some embarrassing nominations. Clearly some material needs to be deleted immediately and is, although mistakes are made there too. If anyone confuses vintage car with either of those two cases, then of course they're going to be offended. The point of this discussion is to hammer out the rules, and to see where the line is drawn as far as consensus. It's perfectly acceptable, in my opinion, to bring this up for debate provided that the page isn't flooded, first of all, and that you really do believe it doesn't fit our current standards. As to the latter, this is one of the grayest areas I've seen in the few months I've been here, in this period of inclusionism as it would seem. Davilla 19:50, 9 May 2006 (UTC)

• Contrary to Connel's attempt at explaining my position, I am not at all against multi-word entries. Just take a look at my contributions. I am against misleading dictionary users. The thing is that there is nothing on our pages to tell the user why a word is included. Currently we include items by language and "part of speech", the latter field being slightly overextended. We have nothing to (consistently) say "idiom", "set phrase", conversational phrase, encyclopedic entry, translating dictionary entry, character from a computer game, etc. Because of this somebody will see "vintage car" and not "vintage motorcar", "pick up the phone" and not "pick up a phone", "fried egg" and not "fry an egg". It's impossible for the user to tell which phrases are a lexical part of the English language, and which are simply common phrases, words which have special senses when used in combination, terms with figurative senses sometimes only in some contexts, phrases which have semantics over and above their literal contents, etc. Since most dictionaries only include words, idioms, and some set phrases, that is what most dictionary users are used to - when they come across our other kinds of entries they are bound to assume they fall into one of those usual categories and that they are always basic components of the English language. If we cause anybody to think that we are misleading them. It is our duty to tell them what a phrase is and what it isn't. If we don't know we can say so, if we disagree amongst ourselves we can say that too - at least then the dictionary user will know it's not a cut and dry case and can think about it themselves or look it up in another source for more information.

• Here's how I think we need to move forward:
  1. Classify entries at a level other than only part-of-speech.

     Not unless they don't meet our CFI under the broadest standards. Right now I would consider only phrasebook entries to fall under this category. Davilla

     Other examples would be inflected terms such as plurals and past tenses, which I'm very much in favour of having, and common mispellings, which indeed are one class that is marked by a different format, though one I rather dislike. — Hippietrail 22:06, 9 May 2006 (UTC)

     Misspellings I could agree with. The inflected forms will be sorted out meticulously on their own. Recently we can add romanizations. Davilla 18:20, 25 May 2006 (UTC)

  2. Have a transparent and adult way of handling disputes.

     Up to this point I thought it was being handled pretty well. Davilla

     Perhaps you weren't around for tidal wave / tsunami or Egyptian pyramid. And I'm quite certain there were some big ones that I wasn't involved in as well. — Hippietrail 22:06, 9 May 2006 (UTC)

  3. Mark pages as disputed.

     Unnecessary IMO. But the original nomination could have been lighter, distinguishing tags that debate the idiomacy of a term rather than its correctness. Davilla

  4. Quit the attacks and emotional responses.
  5. Either ban original research fully like on Wikipedia, or have an open and transparent way to research terms without fighting like children.

     The CFI requires research, the wiki style necessitates that it open and transparent, and we will always fight like children. Davilla 19:50, 9 May 2006 (UTC)

Please comment and feel free to move this topic to a better place. — Hippietrail 18:36, 9 May 2006 (UTC)

If you are sincere about point #4, it would behoove you to follow your own advice (#2, #5.) I'd prefer it if you not resort to name-calling every time your points are criticized. --Connel MacKenzie T C 19:38, 9 May 2006 (UTC)

I would like to take this opportunity to apologize sincerely for and and all childishness, attacks, and other uncivil behaviour, wilful or thoughtless, against Connel, or anyone else. (One caveat is that I do not feel that adding terms I see as equally acceptable to the title term as being disruptive and so am do not apologize for that.) — Hippietrail 22:06, 9 May 2006 (UTC)

Please rephrase your last sentence. I don't understand what you mean. --Connel MacKenzie T C 19:20, 11 May 2006 (UTC)

The both of you I'm sure realize that the best way to stop fighting is to actually stop. If saying that isn't helpful enough then I'm content keeping out of this. Davilla 19:50, 9 May 2006 (UTC)

People who've only seen Connel and I interact in RFD might not be aware that we are actually friends and get along rather well other than when raging a bitter dispute about which each of us feels strongly yet opposed. — Hippietrail 22:06, 9 May 2006 (UTC)

Am I correct in my understanding: your objection is not to Wiktionary including multi-word terms, but rather your objection is labeling them as nouns? Is that your main objection, or am I still missing your point? --Connel MacKenzie T C 19:20, 11 May 2006 (UTC)

No my objection is for including the types of multi-word terms dictionaries generally include such as steering wheel and against mundande combinations the inclusion of which turn is into some sort of combinatorial dictionary. I really don't know if you just can't see this difference, of see it but don't care about it, or see it and don't want our users to see which word is which, etc. I am not the only one who feels that including skateboard wheel opens the door for motorcycle wheel, car wheel, and every other wheel designed for one or another vehicle or device, plus all the combinations involving their synonyms, as long as at least 3 people have got them into print over the space of at least one year. I don't see how this is helpful and I don't agree that the full OED leaves them out merely to save space. But what I really disagree with is downplaying the difference so that casual users see them presented here in exactly the same way with nothing to tell them whether they're an elemental lexical part of the English vocabulary or just a combination that people can use. — Hippietrail 22:05, 11 May 2006 (UTC)

I just can't see the difference. I believe that "traditional" dictionaries exclude appropriate combinations due to a historic lack of space in printed editions, not because they are not valid.

I implore you to find evidence to back up your belief then, or in the future when stating it, state also that it is your opinion. I plan after my travelling to write to the major dictionaries asking them about their policies. — Hippietrail 18:17, 18 May 2006 (UTC)

Your last sentence gives me pause. Are you suggesting the only thing here should be "elemental lexical part[s] of...English"? If so, I disagree. Past discussion indicate that I am not alone in that sentiment. But the last phrase of that last sentence shows a clearer misconception/difference of opinion. You say "just a combination that people can use" while I say "a combination that has specific meaning." I think that is the larger difference of opinion, between you and me.

Yes. I believe that is what are called listemes. Items of vocabulary which must be memorized as a list. It does appear that others share your sentiment but it is also apparent that others share my sentiment. On the "specific meaning" front, I still don't get it. "Old car" has specific meaning. How can a dictionary in 27 or so large volumes just leave out entries with specific meaning due to lack of space if their general meaning is not enough to define what they convey? — Hippietrail 18:17, 18 May 2006 (UTC)

I think any combination that does have a specific meaning can merit an entry. But more to the point, if someone has taken the time to create an entry, they obviously feel that such a thing is either distinct enough on its own, or woefully ambiguous when described by either component.

I think you need to rirorously define "specific meaning" as a concept we can include in our CFI. For instance what specific meaning does "pick up the phone" have which "pick up a phone" has? Would an entry for another sense of "pick up" go under "pick up the girl", and if not, why not?

On your 2nd point, the fact that we are all amateurs and make mistakes often leads us to take the time to create an entry. You yourself delete and vote to delete many of these - more than me it seems. Having well-defined methods to decide what goes in is a good thing, not a bad thing, and contributors should be made aware of them. — Hippietrail 18:17, 18 May 2006 (UTC)

To turn around, and nominate legitimate information that provides differentiation from the components for deletion is quite a different thing, than passively allowing entries to exist. Please note that I personally do not make a habit of entering compound terms.

To comingle a watered-down version in one or the other component term's definition is misleading and confusing to a general reader. Doing so is also inaccurate, when not added to each component term.

This is the strangest part for me, you really need to indicate what this new term "watered-down version" means. Is "skateboard wheel" a watered-down version of "wheel"? Why isn't "pick up the phone" a watered-down version of "pick up"? I believe including those is confusing and inaccurate. I cannot see any difference. — Hippietrail 18:17, 18 May 2006 (UTC)

So yes, I still "can't see the difference." To me, deleting terms because you "don't see how this is helpful" is enormously different from saying that they could be improved upon, especially when they do convey information that we don't have elsewhere (but probably should.) --Connel MacKenzie T C 16:59, 13 May 2006 (UTC)

I don't believe I've deleted very many articles at all. I have nominated a small number, and voted on a still fairly modest number. Besides RFD, which other process would you recommend? My recommendation is to not treat or encourage others to tread RFD as an attack but rather as a discussion to help us amateurs improve our lexicographical skills. Sorry I'm out of time. More answers to come... — Hippietrail 18:17, 18 May 2006 (UTC)

I think my view is generally similar to Connel's. I would generalise it as:

• We should only add items that are significantly helpful
• We should only remove items that are significantly unhelpful, eg because

they are badly wrong

they take us in a direction we feel is damaging

• We should hope that the no-mans-land between helpful and unhelpful is wide enough to cover most differences of opinion, but inevitably not all; that is what this and the RfV page are for.

To give a new (to me) example of a direction we feel is damaging I recently put in a sarcastic usage. Widsith took it out, on the basis that any word can be used sarcastically, and on reflection, I agree with him. Our entry for sarcasm has a link to the (rather poor) Wikipedia entry. In general, I agree it would be better to spend time improving the latter, so that people can work out for themselves what any word will mean when used sarcastically, rather than to add sarcastic senses to some of the more popular words.

If this discussion succeeds in crystalising (or at least approximating to) the edges of the no-mans-land re phrases to be included, it will have been worthwhile. --Enginear 14:45, 14 May 2006 (UTC)

• There are some points I disagree with and it's because I want a free online dictionary that contains just the kind of things dictionaries generally contain. I am certain there are many other people in the world, both current contributors and also people who've never heard of Wiktionary also want such a thing. I never expected it a few years ago, but now it is quite clear from my experience at Wiktionary that there is also quite a large class who wants something that embraces a lot more things than tradtional dictionaries do. Hopefully rather than forking or creating a new similar project we can work Wiktionary into a site that both camps will find useful.
• These are the things that would be different for a "traditional" Wiktionary from what is listed above.
  1. "significantly helpful" is too broad and fuzzy for a traditional dictionary. It wants only lexical items. The basic elements from which speech and text are made. This is something like the sum-of-parts argument but there it is also based on intuition such that "human being" is in most dictionaries. Many terms are so common and easy to understand that people might say "that's not really useful" but a traditional dictionary will want to include those too - and so does Wiktionary - so it's not a well-defined term.
• I believe strongly that there are many people who can benefit from a fee and open yet traditional dictionary so that hitting the random button or looking at a full index of words will only show the types of things that a traditional dictionary does. Such features will be hard to use for people not interested in video game characters or phrases easily understood from their parts.
• I think one solution might be to change from a 2-way system (delete vs keep) to a 3-way system (delete vs traditional entry vs expanded entry). I don't know the best names to give them. By using categories, templates, css, javascript, etc we can provide ways for users to see just what they want to see. Users who want to see all kinds of things not in even the biggest of dictionaries can see everything. Users who want something just like the OED or Websters but free and open can see just the traditional kinds of things. Stuff that is just rubbished can still be deleted outright. — Hippietrail 22:13, 25 May 2006 (UTC)

So what is this topic actually about? Does it question CFI or the procedures of RFD?

1. As for the latter, I agree that the current system is not waterproof. I sometimes wonder where to add a request: here, at RFV or at RFC. I don't know whether there is a need for another page where one can request community input without having to mention "deletion" or "verification". Some people already seem to understand that this page is not just for requesting an article's deletion, others do not. Wikipedia has things like Wikipedia:Current surveys, but of course their aims are entirely different from ours. I would mildly oppose moving general discussions about articles to their talk pages. It seems that the prevalent idea here on Wiktionary is that discussions should be concentrated on as few pages as possible, which is probably because of our small group of contributors.
2. How to decide what to include and what not? I wonder. Pretty basic question, but it seems it has been discussed ever since Wiktionary was set up. There are many possibilities, but it also seems people are afraid to move too far away from the current formula. Who is to decide whether or not to include vintage car? How will what we decide today reflect itself in the future? Who is this dictionary for anyway? Who will use it, how will they use it, and what will they expect when they hit "Go"? This was WT:CFI just a bit more than a year ago – how will it look in another year's time? As it is right now, the rules are as thin as paper, but as has been put above, it had perhaps better remain that way for Wiktionary to stay fun. —Vildricianus 20:20, 25 May 2006 (UTC)

• "What is this topic actually about? Does it question CFI or the procedures of RFD?"

  It's about both of those and more. It's about how we do things here, why we do them, how we discuss them, the problems we've had, the differences between how different groups deal with things, etc, etc. Basically it's about improving Wiktionary for everybody. We're getting bigger and we need to develop - which we've always done anyway. — Hippietrail 23:10, 25 May 2006 (UTC)

Creation of translation need to be checked

Do many people go around moving translations to need to be checked status, or is it some kind of bot? How often are translations moved to this status, and under what criteria. It seems to me like many perfectly good translations are moved, and isn't that simply counter-productive? Especially for languages with few users here. Ptalatas 23:39, 25 May 2006 (UTC)

By the way, I do check for these after each XML dump. Results are at User talk:Connel MacKenzie/checktrans. --Connel MacKenzie T C 04:23, 1 June 2006 (UTC)

I don't know about other editors, but there are a couple of situations I notice in which it's clear that the translations might be wrong and need to be re-checked.

For example, suppose a word used to have one definition. Then several translations were added. Then a second sense is added. Now, maybe, some of the old translations belong with the old sense and some belong with the new sense, and maybe some new translations are needed for the new sense, too. So the old translations are moved to "Translations to be checked" so that people who know the translated-to languages can come back and rework them in light of the new sense distinctions.

Or, suppose that a word has several senses, and there are several sets of translations all nicely separated for the several senses, except that the way the translations are tied to the senses is by number. Then, suppose that the senses have been added to and rearranged. It's quite likely that when senses are rearranged, the numbered translations don't all get renumbered properly to match. So, again, when it looks like this has happened, the best thing to do is to move all the translations to the "Translations to be checked" section, so that people who know the translated-to languages can come back and rework them using a better tagging scheme, such as little snippets ("glosses") describing in words which sense is being translated.

The problem, of course, is that no one person knows every language, so it often isn't obvious that the current state of some translations is "perfectly good". If you see some translations under "Translations to be checked" that are in a language that you know and that are obviously "perfectly good", please, take a moment and move them back! –Scs 00:42, 26 May 2006 (UTC)

Yeah, I'm going through the greek and norwegian ones now, but it will take some time. And I could be using that time to add new content. Or read for my exams. ;) But it is frustrating to know that if you translate something into a language with few users, then much of it will be bumped to need to be checked over time. Ptalatas 01:24, 26 May 2006 (UTC)

If you put your translations into translation sections with the sense identified, e.g. like the translation sections in "pump", other editors will know that you translated the specific sense and your translation will not likely be moved into {{ttbc}} (unless, of course, the translation just looks wrong). Rod (A. Smith) 02:07, 26 May 2006 (UTC)

Here's another case I just discovered. True story. Once upon a time, our ankle entry listed only a noun sense of the word. It had several translations -- eight of them, as of last August. But then, someone added a verb sense, but they stuck it between the noun sense and its translations -- so, all of a sudden, the translations seemed to be attached to the verb sense (which is evidently U.K. slang for "walk", so it's not going to have the same translations at all). Since then, eleven more translations have been added. Now, are those new translations for the noun or the verb? Probably for the noun, but I can't be sure. (Some of them I can recognize or guess, one of them is a blue link so I can check, but for the rest, who knows?)

I just moved the translations section back to where it belongs, but strictly speaking I should probably move at least the suspect new translations that have been added since August to the dread ttbc status.

(Rod's right, tagging translation sections with words is much better than numbers, but what this episode demonstrates is that, strictly speaking, you ought to tag the translations even when there's only one sense that doesn't need disambiguation -- because, later, it might, but sometimes by then it's too late.)

–Scs 06:53, 26 May 2006 (UTC)

Excellent idea. We should start doing that, ourselves, when we encounter single entries with translations. --Connel MacKenzie T C 07:53, 26 May 2006 (UTC)

I've practically always done this. Note also that the idea behind last March's overhaul of the TTBC system was partially to make tagging translations "to be checked" a less dreaded practice. Frustrating, certainly, but whereas other information is easy to check by native speakers, translations are a more complicated matter, and there's nothing worse than having one or two bad translations spoil an entire section. That doesn't mean one can be reckless in tagging everything that seems wrong as TTBC, on the contrary, a lot of trouble can be solved by checking page histories, interwiki links and sometimes Wikipedia and interwiki links over there. But one shouldn't shun {{ttbc}} just out of fear of undoing other people's work. Accuracy comes on the first place! However, in order to avoid that such things happen, use disambiguated translation tables and level 4 headers. —Vildricianus 13:31, 26 May 2006 (UTC)

The other thing to remember is that tagging a translation with {ttbc}, and/or moving it to a "Translations to be checked" section, doesn't really undo someone else's work. A reader needing that translation can still find it, and they can try to determine how accurate it might be, but at least they won't get the false impression that it's known to be accurate.

If we do this right, we can minimize the work on people checking and repairing translations, minimize the chance that a reader will be misled by a wrong translation, and maximize the chance that a reader can get some value out of an uncertain translation. –Scs 14:40, 26 May 2006 (UTC)

Does WT:ELE currently reflect this? I think it should be the default recommendation, if not already. --Connel MacKenzie T C 00:52, 31 May 2006 (UTC)

Ideally, here is how translation tables should be handled. At least, this is what I tend to do:

• When creating a new entry, add translation tables for each definition;
• Add a translation table even if there is only one definition (as other definitions might be added later); do this even when there is only one known definition of the entry, as another might well come along in the future;
• If a translations seems suspect in anyway, always move it to {{ttbc}}. There is never any harm in doing this, as Scs says, because the translation is still there, and someone will (eventually, we hope) come along and put it where it belongs.

What we don't really have at the moment is any mechanism for saying "I've checked this translation and it is definitely correct for this sense - I checked it from this dictionary/I am a native speaker and know what I am talking about" other than looking in the history. Contributors can add a <!--comment--> to the translation, of course, but there is nothing to stop translations being retagged {{ttbc}} multiple times just because someone doubts the translation is correct. — Paul G 10:52, 30 May 2006 (UTC)

I don't think so. How often does it happen? If a translation is in a disambiguated table, there's little chance it'll be ttbc'd again. The only reason for doing so, I think, is when the original definition gets split up. This is seldom necessary, though. We should continue to encourage people to use such disambiguated tables, as much as we make them use the correct ==headings== and other format. —Vildricianus 14:45, 30 May 2006 (UTC)

What I really don't like about the ttbc tags is the long list of categories that end up at the top of the page, drowning out the "normal" categories. To some extent I feel the urge and inspiration to create subpages in the form word/TTBC.

My opinion is that, partly for this reason, the per-sense subsections of a Translations section should not use headers. When I come across articles where the translations are headerized, I change them to bold. (The other reason for doing this is that the set of header names we use can be regarded as our "schema", and you don't want to put open-ended data into your schema in this way. The problem -- if you agree it's a problem -- becomes visible when you look at Patrik Stridvall's header list at http://tools.wikimedia.de/~stridvall/headers.php.)

Oh. Wait. You didn't say "headers", you said "categories". Never mind. (When you said "at the top of the page", I assumed you meant the table of contents. Are you using a skin that puts categories at the top? I thought they were always at the bottom.) –scs 13:48, 5 June 2006 (UTC)

I'll see how difficult it is to give a CSS class to just thos categories so people that don't like the clutter can ignore them. — Hippietrail 21:05, 4 June 2006 (UTC)

Actually it was quite easy. See WT:CUSTOM#Hide TTBC categories. — Hippietrail 21:49, 4 June 2006 (UTC)

Excellent. — Vildricianus 22:00, 4 June 2006 (UTC)

In general translations should be subject to verification and references as much as any other information. It is obviously impractical to do this on the translation tables. However, since each of these links to a separate page for each word those pages would likely be the best place for such references. Eclecticology 09:05, 3 June 2006 (UTC)

Then you'll first have to enable subpages in the main namespace (by fiddling with LocalSettings.php). Since we're already employing "pseudo-subpages" for /Citations, this may have to be done anyway. — Vildricianus 10:22, 3 June 2006 (UTC)

etymonline.com

Is there something special about this site? Is it public domain? A different number of people have added complete chunks of text from it here, as if it weren't copyvios. Am I missing something? —Vildricianus 16:03, 26 May 2006 (UTC)

They shouldn't do, it's all copyrighted as far as I know. Widsith 16:06, 26 May 2006 (UTC)

Redirect pinyin?

• Moved from WT:TR. Davilla 16:47, 26 May 2006 (UTC)

I'd like to start either redirecting Pinyin terms to the Chinese characters they represent (e.g. huā to 花, or making articles out of each Pinyin term indicating that each is, in fact, the Pinyin for that respective Chinese character. Does anyone have any thoughts as to which would be preferable, or why either would be a bad idea? My thinking is that a lot of "learn-Chinese-for-travel" type books use only Pinyin. bd2412 T 03:46, 23 May 2006 (UTC)

Some Pinyin transliterations will collide with terms from other languages, so "hard" redirect ("#REDIRECT") is not universally feasible. That suggests using a "soft" redirect (a definition line saying "# Pinyin transliteration of ..."), ideally via a template like {{pinyin of}} (ala {{plural of}}) for ease of management and to help with consistent wording and style. Rod (A. Smith) 04:12, 23 May 2006 (UTC)

Yep, sounds good. Widsith 07:18, 23 May 2006 (UTC)

There are usually going to be multiple characters with the same reading. I've gone ahead and made an entry for huā if anyone wants to take a look. Kappa 12:03, 23 May 2006 (UTC)

Yes, definitely a better option in light of the multiple characters that may be represented by one Pinyin word. I'll work on 'em! bd2412 T 13:33, 23 May 2006 (UTC)

I agree in principal, not because I think it should be possible to look up words phonetically (although I do, and actually bopomofo is just a step away), but because it's possible to run across the pinyin in an English text without having the Chinese equivalent printed. However, I'm not sure all of the issues have been worked out. Immediately it has been noticed that there are homophones in Chinese, so it's quite obvious a page is needed and not a redirect. But what about other romanizations? In fact there are at least two kinds of pinyin, so I'm not sure using "pinyin" is appropriate universally. How are different romanizations to be handled more generally? e.g. what if a wade romanization matches the pinyin romanization of a different word? Davilla 15:17, 24 May 2006 (UTC)

• Pinyin being the most popular, I intend to worry about that first... if we run into conflicting Pinyin and Wade transliterations in the future, we can lay them out like so:

==Chinese==

===Pinyin===

1. character 1: meaning
2. character 2: meaning
3. character 3: meaning

===Wade romanization===

1. character 1: meaning
2. character 2: meaning
3. character 3: meaning

... and so forth. Indeed, see bú. bd2412 T 16:22, 24 May 2006 (UTC)

That addresses one point. Maybe ===Wade-Giles=== is a better option. But what about the flavors of pinyin? I imagine it must be all right to let "Pinyin" mean Hanyu Pinyin. Is that the opinion of people here, or is the distinction simply being overlooked? Tongyong Pinyin is probably set to die since even in Taiwan it is not used consistently, nor has it replaced zhuyin (bopomofo) in the curriculum, as has Hanyu Pinyin in China, sadly. (Postal System Pinyin is no longer in use and never was generally applicable to the language.) Davilla 15:54, 25 May 2006 (UTC)

I'm happy to see how closely "bú#Chinese" resembles romaji entries (e.g. "bui#Japanese"). One slight deviation is that romaji entries repeat the "inflection line", if you will, after the "POS" heading. Perhaps it makes sense not to do so with Pinyin, since Chinese doesn't really have an equivalent of Japanese kana (the Japanese transliteration shown on the "inflection line" of romaji entries), but I want to point out the difference to gather people's opinions on the matter. Should all entries in all languages consistently repeat the headword after each "POS" heading even if the "POS" isn't really a part of speech and the headword has no actual inflections?

By the way, there is some contention as to whether romaji entries should have "===Romaji===" or "===Noun===" etc. for their POS heading. Hopefully any consensus achieved on Pinyin layout will reflected in romaji entry layout. Rod (A. Smith) 17:30, 24 May 2006 (UTC)

I have modified bú to reflect the style used for Japanese. However, I don't understand why you link the kana. I thought that was, for the most part, a pronunciation, especially as it's being used here. So wouldn't a page for the kana be equivalent to the romanization page?

I'm fine with leaving the headers as they are, rather than trying to classify the words by part of speech. In fact, I wonder to what extent even translations are needed. Davilla 15:54, 25 May 2006 (UTC)

Although kana forms of 漢語 (kango, i.e. Japanese words of Chinese origin) are "transliterations" of kanji, the reverse is true for 和語 (wago, i.e. Japanese words of ancient Japanese origin). That is, kanji for ancient Japanese words are actually "transliterations". In any event, several Japanese terms don't even have corresponding kanji (e.g. particles). All romaji, however, are transliterations of kana terms, so it is consistent and etymologically appropriate to have each romaji link to the kana entry. Rod (A. Smith) 20:15, 25 May 2006 (UTC)

Thank you for the information. It answers my question if in an indirect way. I will spell it all out for completeness. Your argument, the second half particularly, supports the inclusion of kana under the romaji header. A parallel argument in Mandarin supports the inclusion of zhuyin under the pinyin header, since zhuyin is the etymological and somewhat idiosyncratic Chinese pronunciation system reflected verbatim in the more modern pinyin. However, zhuyin is considered a pronunciation, mixed with Chinese characters only in rubi text, and therefore would not be instantiated under current policy. This is where Japanese differs. The linking to kana is supported by the necessity of those pages. Davilla 16:45, 26 May 2006 (UTC)

Case in point: on one of my cleanup lists was xianzai. As an English speaker, I haven't a clue what this page is trying to convey. It seems to be something pertaining to Chinese characters, but the state the entry is in now makes even that, something of a stretch. What would be helpful to me, as an English speaker (i.e. the intended audience of the English Wiktionary,) would be a listing of definitions for the term, perhaps with links to the Chinese characters themselves. Seeing what POS the term functions as (broken down in sections the same way English entries are, for consistency,) would be helpful as well. --Connel MacKenzie T C 03:11, 28 May 2006 (UTC)

The xianzai entry is without tone marks and should serve as a kind of index page for the 16 possible combinations of tone marks. Eclecticology 07:52, 3 June 2006 (UTC)

My understanding was that the POS headings were supposed to be POS when possible. That would mean a Romaji term would have an ===Adjective===, ===Noun=== and ===Verb=== heading, each with an "inflection line." Is my assumption regarding Japanese entries incorrect? --Connel MacKenzie T C 18:22, 25 May 2006 (UTC)

The problem with this approach is that the pages have to be syncronized. If a POS heading is added to the word, it has to be added to its romanizations as well. I wouldn't break off the parts of speech unless the new term gained meaning of its own, e.g. if ASAP came to be used as a verb. Davilla 19:02, 25 May 2006 (UTC)

I don't see how that is a problem. Yes, eventually, the corresponding entries will be corrected as well. But we edit one entry at a time... --Connel MacKenzie T C 08:07, 26 May 2006 (UTC)

The problem is that it creates a lot of needless maintenance. It's an issue of scale, of one set of tasks in comparison to the other. Davilla 16:52, 26 May 2006 (UTC)

The same could be said about English language entries (paticularly inflected forms) but that really does not match what we've been going, to date. Just as English entries are now benefitting from some automation, I can see these getting the same class of treatment, eventually. --Connel MacKenzie T C 15:16, 27 May 2006 (UTC)

Careful, you're starting to convince me. On the other hand Hippietrail, I believe, had advocated using e.g. ===Verb form=== which would circumvent issues of gernunds, past participles and such. You've never taken the noun and adjective uses very seriously.

Anyways, given that the header contains part-of-speech information, how would you mark the entry as being romaji, pinyin or what have you? Davilla 16:58, 27 May 2006 (UTC)

I'm going to make the bold proposition that we should either use part of speech headers or not list the definition, only a reference. The in-between is not acceptable. Davilla 16:50, 2 June 2006 (UTC)

I disagree somewhat. It does no harm to provide the definition even if there is no part of speech. Also, some individual Chinese characters can be used to represent terms with different parts of speech, and some operate as prefixes or suffixes, useful only in combination with other words, so really not any part of speech by themselves. However, I welcome any effort to categorize the definitions by part of speech where applicable. bd2412 T 17:08, 2 June 2006 (UTC)

Oh that's right, individual characters have general meaning. In that case I would argue that ===Symbol=== or something similar is the part of speech. However it's rather strange to apply that to the romanization, so maybe they could be handled differently, just like the individual Chinese characters themselves receive special treatment. In general though, if there's a definition there should be a part of speech, so if one goes the other must too. Davilla 07:59, 3 June 2006 (UTC)

Indeed, that is one of the challenges with representing multiple transliterations, not just for kanji/kana/romaji and hanzi/Pinyin/Wade-Giles, but also for regional spelling variations like "color/colour". Personally, I'd love to see these issues resolved ala "theatre"/"theater", but I'm not certain that solution is easy enough for all editors follow. Rod (A. Smith) 20:15, 25 May 2006 (UTC)

I think the approach used with color/colour is better than theater/ theatre for several reasons: 1) it uses the template namespace, 2) it has back-links, 3) it is much more flexible 4) only the common sections are shared. --Connel MacKenzie T C 08:07, 26 May 2006 (UTC)

If your reason 1 ("it uses the template namespace") is a benefit, that benefit is not obvious to me. Reason 2 is a good idea, so I added backlinks to "theater"/"theatre". I don't understand your reason 3 ("it is much more flexible"). Your reason 4 is confusing to me, because in "theater"/"theatre", only the common sections are shared.

Reason #1 is that there is inherent confusion when the main namespace is overloaded. Reasons #3/4 pertains to multiple sections in "theater"/"theatre" being shared, while in "color/colour" each shared section gets a separate shared template. I should have worded #4 more clearly. By having more specific shared sections, there is more flexibility for common sections diverging (as they should) while other sections remain common. To me, including more than one heading section in a common template is therefore likely to shoehorn data into a common section, that shouldn't be shared. With color/colour, the issue of translations being common is plain, but making any other section common would not be NPOV. I see the same issue for theater/theatre, by the way. But the practice of using shared sections too much seems dangerous, in that certain sections incorrectly commingled into a common section will then stagnate, rather than diverge correctly. --Connel MacKenzie T C 15:16, 27 May 2006 (UTC)

I think the "color"/"colour" approach is great. I just suggest to use the main namespace for entry-specific content. My motivations are (a) organizing content with the content's entry and (b) avoiding overpopulation of the template namespace. Consider managing the template namespace if every "-ize"/"-ise" entry has its own template, as well as every term of languages (like Japanese) that have multiple transliterations. Creating hundreds of thousands templates seems excessive. Rod (A. Smith) 22:46, 26 May 2006 (UTC)

I was thinking about this kind of thing a long time ago but didn't get around to experimenting with it fully. My idea was to request the devs to give us a new namespace "Shared:" which is specifically for these templates and no others. You can sort-of try it now but since it's only a pseudo-namespace now it will require [[:Shared:color-colour]] rather than [[Shared:color-colour]] if it were a real namespace. — Hippietrail 23:29, 26 May 2006 (UTC)

Wasn't that the technical intent of the template: namespace, to begin with though? I'm not clear on just what the distinction being suggested is. Would "shared:" be used for things like cacodaemonically's sections? Or would "shared:" be limited to cases where the content is shared between only two entries? --Connel MacKenzie T C 15:16, 27 May 2006 (UTC)

Template: would be for templates that do funky things and are included by diverse pages for diverse reasons. Shared: would be only for contents shared between articles with differing spellings or possibly also such as romanized article or regional synonyms in some cases - but mainly just for color/colour and center/centre. No tricky stuff would be allowed in Shared: — Hippietrail 19:37, 28 May 2006 (UTC)

• Oh I forgot to mention, I requested a relevant feature a few days ago and it's already here. When an article wikifies to itself it is wrapped in an HTML strong tag, but now the tag also has the CSS class "selflink". Using this feature we can have Shared Templates even for sections which might reference the article title - such as the Alternative spellings section. If all Shared templates have somthing like an HTML DIV with CSS class shared-template we can have a CSS rule .shared-template .selflink { display: none }. If the DIV is infeasible we can add some JavaScript that searches for them and removes them. Anyway this is all Grease pit talk. — Hippietrail 19:44, 28 May 2006 (UTC)

• • I'm sorry I didn't see this post sooner, I have already been experimenting with this idea. Please see the entries in Category:Beginning Chinese (Pinyin) for examples. A-cai 05:59, 3 June 2006 (UTC)

The items in that category are only redirects. They also do not account for the fact that any given pinyin can represent several different character combinations. I think that it's more helpful to have entries under pinyin without diacritics that could serve as a kind of index for the different possibilities. Also, I can't say that having "beginning" and "advanced" categories is very helpful. Putting things there requires a value judgement about any term. It is also excessive to classify something in both traditional and simplified Chinese when it only has one form to start with. Eclecticology 08:31, 3 June 2006 (UTC)

• • • In response to the above:

1. Not all of the terms are redirects. Most of the multisyllable words will only require a redirect (because there is much less overlap), whereas monosyllable words such as tā need a more complete treatment.
2. I agree that we should also have entries without diacritics. In cases where there are no overlapping meanings, you could do something like feiji (We'll ignore Fiji for the time being which is also feiji: Fěijì 斐濟, 斐济). Sometimes, there will be overlaps, even for multisyllable words. One example would be dajia: dàjiā (大家) dǎjià (打架).
3. With respect to the Beginning, Intermediate and Advanced Chinese categories: I base that on the 甲乙丙丁 categories as set forth by the HSK committee. Since 甲乙丙丁 categories are not particularly useful for beginning students, I decided to call 甲 beginning, 乙 and 丙 intermediate, and 丁 advanced. The total number of words on the HSK committee list is 8840. If a word falls outside that list, I do not attempt to classify it as beginning, intermediate or advanced.
4. Finally, while it may seem excessive to classify something as both traditional and simplified, many students of Chinese are only familiar with one of the two forms. Having the term in both lists allows the student to go to a single list and be confident that all words are included in the list, and that they are in the correct form for that list (either simplified or traditional). This also allows me to ensure that traditional and simplified forms both get an entry. If I see that one list has more than the other, I can find the missing word, and create a new entry. A-cai 20:21, 3 June 2006 (UTC)

Probably those that are redirects should be changed to simple links to the actual Chinese with a term like "Pinyin romanization of ..." Entries without diacritics (except perhaps for ü) may make the separate pages for pinyin with diacritcs unnecessary since they would contain all possible combinations. We want to make things easy for people to look up, and this is a significant challenge for people who have no background in Chinese at all. We're still far from doing this for the Chinese characters, but it is in our grasp for pinyin.

Whether the beginner/intermediate/advanced classifications are useful depends on our target audience. I don't think they will just be students. The Wikipedia article suggests 11 levels; perhaps something akin to the levels for Japanese kanji. Have I misunderstood something there? If so something like Category:zh:HSK level 4 could be more practical. It would only be used on the page for the Chinese character, not the pinyin page.

Eclecticology 07:37, 4 June 2006 (UTC)

Inserted response: The wikipedia article offers the adjectives: basic (甲), elementary (乙), intermediate (丙) and advanced (丁). These describe the difficulty level of any given word in the core list of 8840 words. Then there are 11 proficiency levels according to the score you receive on the test. There are a number of Chinese language books that contain the HSK committee list of words. I am using →ISBN.

A-cai 11:51, 4 June 2006 (UTC)

On the final point, to start with I have never felt the "Noun" is a worthwhile category for any language, including English. It's just too big. What would a person looking in that category be seeking?. If you must include all words as simplified or traditionasl even when they are written the same in both styles, why not just open a new category for characters that are common to both. Eclecticology 07:37, 4 June 2006 (UTC)

I understand your points. I appreciate the suggestions.

1. I would like to change the categories to Category:zh:HSK basic, Category:zh:HSK elementary, Category:zh:HSK intermediate and Category:zh:HSK advanced.
2. If you look at the Chinese language pages long enough, you'll probably notice a number of things that I have tried. I have liked the way some have turned out, and not others. The biggest problem is lack of participation from experts in the Chinese language. Without substantial participation, all I can do is to keep plodding along.
3. As for the Simplified/Traditional/Pinyin problem, I still maintain that a technical solution should be found such as the one that currently exists on the zh:wiktionary pages. Until that solution materializes, the current set-up is the best that I can offer. I understand your point about a third category (not traditional, but not simplified either), but I think that might further confuse things.

Here is a table to illustrate the crux of the CJKV problem:

English	to translate
Traditional Chinese, kyujitai	翻譯
Simplified Chinese	翻译
shinjitai	翻訳
Pinyin	fānyì
POJ	hoan-e̍k
Jyutping	faan1yik6
hiragana	ほんやく
katakana	ホンヤク
romaji	honyaku
Korean	번역
romanized Korean	beonyeok

All of the above should be accounted for in order to completely document this word. This is easier said than done. How do we include all of the above information without sacrificing readability. How do we cross-reference the info? Example sentences is another issue. If I create an example sentence for Mandarin, which character set do I use? If both, do I write the sentence twice (once in Simplified and once in Traditional)? Should the duplicate sentences be in the same entry, or should a new entry be created? The entry for 容易 demonstrates this problem. Wiktionary does not have a consistent policy for any of this which is one of the reasons we keep coming back to these kinds of discussions. This may be the very thing that is discouraging wider participation. A-cai 11:33, 4 June 2006 (UTC)

Personally, I would just as soon have individual articles on all characters, but a single article on each term composed of a specific combination of characters under the simplified Chinese heading with the traditional Chinese redirecting to it. However, it seems to have gotten started the other way, and I see no harm to having separate articles. It's not the same as the theatre/theater debate, tho, as there is no dispute over which set of characters is correct - it's more akin to a debate over whether things should be presented in a plain font or a fancy font. bd2412 T 23:03, 8 June 2006 (UTC)

Per some of the above discussion, I just want to point out that if you really want to see all possible Chinese characters that can be transliterated to Pinyin via a particular arrangement (with or without diacritics), you can look at the alphabetical lists under Wiktionary:Chinese Pinyin index. However, I believe it would make those pages too long to include meanings ascribed to the characters (as I have atempted to do so far in articles on the Pinyin). Should I be bothering to do this? The alternative is to require the user to click on each character individually to see what it means, with some Pinyin transliterations representing dozens of characters. bd2412 T 22:59, 8 June 2006 (UTC)

The Grease pit has been created

With all the exciting new development underway by Connel, myself, and lots of people whose names have sadly gone in one ear and out the other, I think it's high time to create a separate talk space where we can discuss ideas related to templates, javascript, CSS, customization generally, toolserver; and also generally discuss how to make Wiktionary better in both the short-term and the long-term. It's not pretty right now but please go over and sow some ideas and tidy it up. I think many of us have an idea of how to use such a place. Now over to the Grease pit. — Hippietrail 17:40, 27 May 2006 (UTC)

Can you clarify its purpose a bit?

• It is a place to discuss how to solve technical problems.
• Its purpose is specifically for discussing the future development of the English Wiktionary both as a dictionary and as a website.
• It is also a place to think in non-technical ways how to make the best free open online dictionary.

These statements range from specific to general. How do you see it? Technical stuff only or a broader idea? —Vildricianus 18:05, 27 May 2006 (UTC)

The name seems to signify that, if you don't want to get your hands dirty, you should stay away. Sounds like good advice to me! SemperBlotto 18:10, 27 May 2006 (UTC)

• I've tried to cover this a bit in the intro now. I think the Beer parlour is for politics and policy and the Grease pit is for engineers, to put it very basically. In the grease pit we can talk about how to lower your suspension or add a link the navigation bar, but we can also talk about what we'd do if we were in charge of Ferarri. In other words policy talk might belong there if it's very long range - thinking about how things could be, but talk about the finer points of current policy would be much better off right here in the Beer parlour. But it's all up in the air right now so feel free to start a topic in the Grease pit about what it should and shouldn't cover. — Hippietrail 18:45, 27 May 2006 (UTC)

• • Grease pit as in getting one's hands dirty, I suppose? I see we're giving up the "drinks" theme, unless "grease" is some beverage I've never heard of :) — Paul G 11:22, 30 May 2006 (UTC)
    • "Requests for deletion" isn't particularly following the "drinks" theme either, but it certainly gets a lot of discussion.  :-)   That said, I can't think of a drink name (nor a drinking establishment) that would convey the idea quite as well as "Grease pit" does. I suppose if the analogy was extended from legal drugs to illegal drugs, it could have been named "Crack house" or "Meth lab."  :-)   --Connel MacKenzie T C 01:07, 31 May 2006 (UTC)
    • The trouble is, engineers tend to be more interested in getting their hands dirty than in eating/drinking. As in a parody from before the days of pocket calculators or PCs, and when rubber-band powered model aircraft were still in vogue, (based on Albert Hammond's Free electric band) "Just give me bread and water, and a slide rule in my hand, and I'll make it work for ages with a great big rubber band". --Enginear 03:57, 1 June 2006 (UTC)

Standardizing inflection templates

In Category talk:Conjugation and declension templates/Inflection, conjugation, and declension template names, I have proposed that we standardize the names, purpose, and display style of three types of templates used in Wiktionary.

My interest in that topic is now renewed because of {{fr-infl-adj}} (used on "digital" and other entries). {{fr-infl-adj}} displays like a floating declension table (with the added property of showing pronunciation) but is named like {{en-infl-reg-other-e}} et al., which are used on the "inflection" line (immediately following the POS heading) to show the headword and its main inflections. Is there yet a preferred pattern for naming and display styles of the two types of templates?

Also, two sets of English inflection line templates (Group A, e.g. {{en-noun-reg}} and Group B, e.g. {{en-noun2}}) because editors have agreed to disagree about inflection line display style. CSS magic now lets everyone have his or her way just as it does with {{cattag}}. Would anyone object to standardizing the inflection template display in a way that allows each reader to choose his or her inflection line display style? (Should I move this to WT:GP?) Rod (A. Smith) 19:39, 27 May 2006 (UTC)

• I think a good place to start would be to come up with some standard CSS classes. We would need one SPAN or DIV (depending on whether it's inline or creates some kind of box or table) as a wrapper for the whole thing, and another SPAN for the actual inflected words. All templates should use the same classes so that people can say select italics for the body of the section and bold for the actual words - or however they like it.
• The next step would be to come up with a flexible template that uses whatever it takes to please all the camps and produce an inline version or a version in a box or table etc. That's a lot more work and the place to do it is over in the Grease pit. — Hippietrail 22:05, 27 May 2006 (UTC)

The above conversation continued at WT:GP#Standardized customizable inflection templates. The technical details are now worked out and I propose the following:

Standardized personalizable inflection templates

• Message type: Proposal
• History (for additional context): Wiktionary:Grease pit/Standardized personalizable inflection templates
• Purpose: To help standardize the names, purpose, and display style of $\approx {\frac {2.5}{3}}$ types of inflection templates used in Wiktionary.

Many "inflection templates" (or perhaps more accurately, "part of speech templates") display immediately after the level 3 (or 4) POS heading to show the headword in its dictionary form and some key inflections (or sometimes transliterations) of each main entry. Some have names like {{en-noun}} or like {{en-infl-reg-other-e}}. Some technological hurdles in the past (e.g. lack of some important MediaWiki ParserFunctions) denied us the option of doing everything easily in a single template. Also, CSS magic now allows personalization of display preferences for all logged-in editors (i.e. not just for monobook users).

I propose we use the new technology to standardize English inflection templates.

By default, the new templates show the inline format. If the new templates are approved here, people will be able to turn on table style templates for all the entries that use them by adding the following to Special:Mypage/monobook.css (or to elsewhere for other skins; contact me with any questions or requests for assistance):

.infl-inline {display:none}
.infl-table {display:inline}

The noun template is currently at {{en-infl-noun}} and I propose we move it to {{en-noun}}. Then, I can convert the existing entries with, e.g. "{{en-noun|cactus|cacti}}", to the new syntax, i.e. "{{en-noun|cacti}}". As a bonus, the syntax is even easier for regular nouns, e.g. "{{en-noun}}" adds -s and "{{en-noun|es}}" adds -es, but if you want, you can always just spell out the full plural form. See the complete documentation at Template talk:en-noun.

When the replacement of {{en-noun}} is complete, entries with other English noun templates (e.g. {{en-noun-reg}}, {{en-noun-reg-es-both}}, {en-noun-unc}}, ...) can be converted as well, so all English nouns can use {{en-noun}}.

Similarly, as explained in Template talk:en-verb, I propose moving {{en-infl-verb}} to {{en-verb}} and performing the same deprecation of other English verb templates. Perhaps the following observation belongs in a different section, but note that many languages have orders of magnitude more inflections than English. To show full conjugation and declension tables, the POS leader line (a.k.a. the "inflection line") often proves inadequate. In such cases, a separate "====Conjugations====" section is typically used with its own table-producing conjugation template and similarly for declensions. However, it the new universal templates do also supports some extra details, e.g. "<nowiki>{{en-verb| works | working | '''[[worked]]''' or, obsolete, '''[[wrought]]'''}}".

Now that I have proposed the new templates (and, more broadly, a pattern for cross-language inflection/part-of-speech templates), I see the following next steps:

1. Get community approval of the templates (specifically, {{en-infl-noun}} and {{en-infl-verb}}).
2. Move the new templates over top of the templates with simple names (i.e. {{en-noun}} and {{en-verb}}).
3. Get additional feedback and adjust new templates as required.
4. Migrate from and deprecate all the other English noun and English verb inflection templates.
5. Create similar {{en-adj}} and {{en-adv}} templates.
6. Create similar templates for other languages ({{.*-noun}}, {{.*-verb}}, {{.*-adj}}, etc.).

Please let me know if I can answer any questions. Rod (A. Smith) 03:02, 10 June 2006 (UTC)

I'm for. From an editor's point of view, especially if a novice, it's good to keep things simple, which means having to learn as few templates as possible. I like the concise naming convention. The standard of documentation is also good. Jonathan Webley 07:36, 10 June 2006 (UTC)

OK. This proposal has been here for nearly a week with no objections, so unless anyone objects in the meantime, I will move {{en-infl-noun}} to {{en-noun}} and {{en-infl-verb}} to {{en-verb}} in about a day from now. Rod (A. Smith) 19:43, 15 June 2006 (UTC)

Good luck, and thank you! — Vildricianus 19:45, 15 June 2006 (UTC)

I'd have come into this discussion sooner if I hadn't had such limited access for the past month (and coming few weeks). I applaud the attempt to do all this, and am eager to work with you on standardizing the Latin templates sometime soon (well, not the verbs yet). While I have the grammatical knowledge, I've held off for making any changes because I wasn't up on all the possible formatting and structuring issues, which seem to be on your mind. If you don't hear from me in a month or so, contact me directly, please. Also, there is a list of exisitng Latin templates in my Laboratorium, so that you can get a sense for the complexities of a language with numerous conjugational forms. --EncycloPetey 02:16, 16 June 2006 (UTC)

FYI, I am now moving Template:en-infl-noun to {{en-noun}} and Template:en-infl-verb to {{en-verb}}. May the following two links serve as the archive of the old templates:

• Deprecated Template:en-noun
• Deprecated Template:en-verb

Rod (A. Smith) 02:35, 17 June 2006 (UTC)

• Restored the older histories from before the moves. — Vildricianus 10:09, 17 June 2006 (UTC)

Wikipedia system of queueing articles from anons

Recently, I accidentally tried to add an article to Wikipedia when I wasn't logged on. It wouldn't let me. Instead the article can be put on a queue for checking. See w:Wikipedia:Articles for creation. What do you think are the pros and cons of this system? Would it work here? SemperBlotto 17:38, 28 May 2006 (UTC)

I thought this would come up sooner or later (sooner, actually). I'd really like to keep it as a last resort. Of course I know how much rubbish gets added, but we are not Wikipedia, in no way whatsoever. Pedia gets thousands and thousands of edits per day, and prior to the restriction of article creation for anons, thousands of new entries a day. That's hardly necessary for a one-million-article encyclopedia. But it's totally inappropriate, I think, to do the same for a dictionary with barely the basic English entries covered. I assume WP was at the time of the rule's institution drowning in bullshit new articles. I don't think we are. Let's try to keep it up, we've just had 9 more sysops this month. —Vildricianus 17:54, 28 May 2006 (UTC)

I don't think it will ever be appropriate for Wiktionary, or at least not for a long long time, because unlike Wikipedia articles, which are topics edited thousands of times as the page grows, Wiktionary entries are sparse, with the words defined very simply usually. -Davilla 59.112.52.124 19:21, 28 May 2006 (UTC)

Some are being too Autocratic

I have just restored a couple of entries - pussyjunk and veritaserum. Both were deleted in very autocratic style, simply because of the prejudices and autocratic nature of the administrator.

pussyjunk is clearly at least a protologism. That policy / process is tough enough, without arbitrary instant deletion by a bowdlerising adminisatror.

veritaserum is as valid as Jabberwocky. But, even if this doesn't count, there is a process which is to be followed, allowing time for people to collectively consider if a word is valid or not, or perhaps just needs cleanup. It is not for some autocratic administrataor to just decide Harry Potter is not real literature and to instantly delete words which only appear in Harry Potter.

I think we should perhaps start keeping a log of when people abuse their administrator rights, and those who become too autocratic should be on some sort of warning about losing their deletion rights.--Richardb 01:08, 29 May 2006 (UTC)

Well, I deleted pussyjunk and I stand by it. It is nonsense and only gets 9 Google hits – random strings of letters would get more. Widsith 09:33, 29 May 2006 (UTC)

It doesn't matter how many Google hits it gets. Even if it only gets 3 Google hits, that may be sufficient to attest it, in theory of course. What's important is the number of relevant Google hits, although even that doesn't factually prove anything either, especially in (a granted very tiny fraction of) cases in which it's an archaic word, a misspelled neologism, or something the like.

As for relevancy in this case, I have checked all the google hits for "pussy junk" and found none to be valid references. "Pussjunk" does not have many citable hits and appears to be protologistic:

[2] (definition rather than use)

[3] (no permanent cache)

[4] (no indication of meaning)

[5] I have to step away from this Chicago stuff for a day. Give my mind a break from it or something before I completely pussyjunk myself out of contention for either role!

[6] I already have a few things written down, but my favorite thus far is definitely during the stage when he is first being pussyjunked and has a desire to "extend his olive branch."

I would guess that these are not even independent, which is odd considering they don't support the same meaning. Davilla 17:44, 1 June 2006 (UTC)

Delete. —Stephen 18:34, 29 May 2006 (UTC)

I think it was right to delete pussyjunk, though I'm waiting to be convinced about veritaserum.

This is the junk that was deleted yesterday:

1. adding new content
2. bien sur
3. White Snot
4. pussyjunk
5. cabalidad
6. Hinge moment
7. Vitaut the Great
8. Kategoria:eston'ski (indeks)
9. eweqweqweqweqw
10. cybernetica
11. pitted tubesoulder
12. andier
13. Sylvie ilter
14. xpage
15. nr.
16. manasd?r
17. to give
18. disfrute
19. fulling
20. Snape Killed Dumbledore!

If this is a typical day, and each of these had to pass through rfd before deletion then the process would become swamped and overloaded. We elect responsible people as admins and they should be trusted to use their judgement. Jonathan Webley 10:15, 29 May 2006 (UTC)

I think we should also keep a log of when administrators revert other people who try to give a bit of consistency to our entries. —Vildricianus 11:17, 29 May 2006 (UTC)

• pussyjunk Re-deleted. Not on books.google.com, not even in www.urbandictionary.com! --Connel MacKenzie T C 03:55, 30 May 2006 (UTC)

  Since when did whether it appeared in an urban dictionary grant a word any credibility whatsoever? That's not the best argument. And Google books is a good source, but not the definitive one for certain. Davilla 17:44, 1 June 2006 (UTC)

Although it is not a policy anywhere, this is the rule I use: if I don't know a term, or suspect it of being "tosh" as SB so eloquently puts it, I onelook it. If Onelook has nothing, I google it. If in the first 9-10 pages of google I cannot find anything that looks like it is a decent citation or indication of usage in the sense/senses listed on the page, I will usually delete it, unless there are many hits, in which case I will RFD it.

Do you mean RfV-sense it? Davilla

If I can find any evidence that the term is used in a manner similar to what was indicated on the entry, I will RFD/RFV/format it depending on what I discover. If that is autocratic...sorry. - TheDaveRoss 05:51, 31 May 2006 (UTC)

• That policy sounds sensible enough. If nobody disagrees I will amend Wiktionary:Page deletion guidelines to that effect. Jonathan Webley 12:03, 31 May 2006 (UTC)

• Sounds perfectly reasonable to me, too, and is more or less what I'd do (though I have no delete button). –scs 12:06, 31 May 2006 (UTC) [P.S. to TheDaveRoss: I assume you meant "I will RFC/RFV/format it depending..."?]
• That also sums up my detoshification process. SemperBlotto 12:20, 31 May 2006 (UTC)

Transliterations

There has been a lot of confusion about transliteration, due mostly to the fact that there are several different systems in use for any given script. I’ve been saying for a while now that we should develop an official policy, at least in regard to major non-Roman language such as Russian, Korean, and Arabic.

For Korean, we have been pretty consistent about using the new w:Revised Romanization of Korean, which avoids all diacritics and most hyphens. For Chinese, the Pinyin system is well founded and already being followed. Japanese doesn’t present many problems, but there are a couple of important considerations.

In case everybody agrees that this is a good idea, I have included below a table showing the main systems in use for Russian. If we choose any one of these as official policy for Russian, it will mean a lot of work because up to now we have been using a lightly different system. I don’t know anything about bots, but perhaps somebody could create a bot to change existing Russian transliterations (which are very consistent) to the agreed-on system.

This if this can be made to work for Russian, we should consider a system for Arabic and for Greek. Of these systems, I don’t recommend the ALA-LC because of its reliance on diacritics and special digraphs. —Stephen 21:05, 29 May 2006 (UTC)

Transliteration table

Common systems for romanizing Russian

Cyrillic	Scholarly	ISO/R 9:1968	GOST	UN	ISO 9:1995	ALA-LC	BGN/PCGN
А а	a	a	a	a	a	a	a
Б б	b	b	b	b	b	b	b
В в	v	v	v	v	v	v	v
Г г	g	g	g	g	g	g	g
Д д	d	d	d	d	d	d	d
Е е	e	e	e	e	e	e	e, ye†
Ё ё	ë	ë	jo	ë	ë	ë	ë, yë†
Ж ж	ž	ž	zh	ž	ž	zh	zh
З з	z	z	z	z	z	z	z
И и	i	i	i	i	i	i	i
Й й	j	j	j	j	j	ĭ	y
К к	k	k	k	k	k	k	k
Л л	l	l	l	l	l	l	l
М м	m	m	m	m	m	m	m
Н н	n	n	n	n	n	n	n
О о	o	o	o	o	o	o	o
П п	p	p	p	p	p	p	p
Р р	r	r	r	r	r	r	r
С с	s	s	s	s	s	s	s
Т т	t	t	t	t	t	t	t
У у	u	u	u	u	u	u	u
Ф ф	f	f	f	f	f	f	f
Х х	x	ch	kh	h	h	kh	kh
Ц ц	c	c	c	c	c	t͡s	ts
Ч ч	č	č	ch	č	č	ch	ch
Ш ш	š	š	sh	š	š	sh	sh
Щ щ	šč	šč	shh	šč	ŝ	shch	shch
Ъ ъ	″	″	″	"	″	″*	”
Ы ы	y	y	y	y	y	y	y
Ь ь	′	′	′	'	′	′	’
Э э	è	ė	eh	è	è	ė	e
Ю ю	ju	ju	ju	ju	û	i͡u	yu
Я я	ja	ja	ja	ja	â	i͡a	ya
Pre-1917 letters
І і	i	i	–	ĭ	ì	ī	–
Ѳ ѳ	f	ḟ	–	ḟ	f̀	ḟ	–
Ѣ ѣ	ě	ě	–	ě	ě	i͡e	–
Ѵ ѵ	i	ẏ	–	ẏ	ỳ	ẏ	–
Pre-nineteenth century letters
Ѕ ѕ	–	–	–	–	–	–	–
Ѯ ѯ	–	–	–	–	–	–	–
Ѱ ѱ	–	–	–	–	–	–	–
Ѡ ѡ	–	–	–	–	–	–	–
Ѫ ѫ	–	–	–	–	ǎ	–	–
Ѧ ѧ	–	–	–	–	–	–	–
Ѭ ѭ	–	–	–	–	–	–	–
Ѩ ѩ	–	–	–	–	–	–	–

Notes

* ALA-LC: ъ is not romanized at the end of a word.

† BGN/PCGN: ye and yë are used to indicate iotation word-initially, and after a vowel, й, ъ, or ь.

Comments

This is a very nice transliteration table! I agree with Stephen. We do need some kind of a system for transliterations for the mentioned languages. We have many entries in those languages and many translations. Most of those entries and translations do not have consistent transliterations and some have none. I really like the table. I would go with either the "scholarly" or the "UN" one. --Dijan 05:04, 30 May 2006 (UTC)

Hippietrail proposed on Stephen's talk page to use CSS and template magic for them, so that users can choose for themselves which system they want to see. I'm not sure whether that would work; perhaps it needlessly complicates things for the average user. But then, I've seen many a good idea from him, so I'll trust him on this as well. —Vildricianus 10:04, 30 May 2006 (UTC)

Letting the user pick the transliteration would be brilliant. TheGrappler 19:55, 30 May 2006 (UTC)

The advantage of CSS (someone correct me if I'm wrong) would be that transliteration could be hidden completely for those of us who read Cyrillic...? Widsith 07:35, 31 May 2006 (UTC)

Certainly. —Vildricianus 15:24, 31 May 2006 (UTC)

Of course they should all be done... I mean that as far as the romanizations getting their own entries, they should all be included. As to which one to show following the funny script in the translation section, I don't know because the biggest factor is which ones are in use today. So that much I'm omitting from what I can determine above.

Scholarly, UN, and the old ISO seem to fall into one camp, with maybe Scholarly being the least ambiguous because it never uses h, whereas other systems might use h following s, c, z, or k, or in isolation. It gets a very weak vote from me. Would it be permissible to choose another romanization from the other camp, which would contrast with the first? ALA-LC's "reliance on diacritics and special digraphs" might even help distinguish it in that case. But as I said, it depends on what's most heavily used, also considering use per region, across languages, etc. Davilla 18:07, 31 May 2006 (UTC)

It's not really what is most used, it's rather the purpose which counts. If you want to be able to reconstruct the original spelling from the transliteration, you'll need the Scholarly, ISO/R 9:1968 or UN (also named the "international standards"), which use unique transliterations for each cyrillic letter. For that part, it's best to use the scholarly only - the other two are similar and slightly more ambiguous, so serve little purpose. If you want to render the Cyrillic more readable to people who can't read it (which I think is our purpose), the "Anglo-Saxon" transliterations are the best option, with BGN/PCGN being best suited for matter of simplicity. However, it also depends on viewpoint. As mentioned, the two rightmost columns are most used in the Anglo-Saxon world, so may serve en:wikt better, even though non-English speakers may be confused. As far as I know, but I'm not certain about that, the international standards (leftmost columns) are used elsewhere, and displaying this one may be equally well-served for en:wikt given its large number of non-English native speakers. There's my opinion; I'd recommend making it an option for the user to choose between "Scholarly" and "BGN/PCGN" - the others serve little purpose. —Vildricianus 21:00, 31 May 2006 (UTC)

Would you consider the attempt/intent to have both simultaneously? Davilla 15:58, 1 June 2006 (UTC)

I would like to express my support for the BGN/PCGN. It does avoid the use of diacritics, notably the haček. The one that it does retain, "ë" is a less significant problem since it's included in ISO 8859-1. At some point we might want page titles using the transliterations, and we would want to minimize sorting problems. The different places where a "y" is used appear to be mutually exclusive. Mt first impression is that the CSS solution only makes things more complicated without any real benefit. The fact that Russian is written in Cyrillics won't change. What we want out of transliteration is an easy way for a person to enter the written language using the Latin alphabet. It has nothing to do with pronunciation. Eclecticology 21:58, 2 June 2006 (UTC)

None of these systems have to do with pronunciation. While I think it's virtually impossible, or at least very difficult and complicated, to enter the language using Latin script, it's important at all times to know what is actually written in Cyrillic. Various spelling and grammatical rules depend on that, so it's indispendable. For that part, we need a system that transliterates Cyrillic in the most accurate and least ambiguous way, and that is certainly not BGN/PCGN. On the contrary, when using that system, it is impossible to reconstruct the original word without guessing. — Vildricianus 22:17, 2 June 2006 (UTC)

Page titles will be created for any of the romanizations, not just the ones that we agree to list alongside translations. I don't have a problem with diacritics except that it makes less sense to promote them when they aren't universally supported anyways.

Complicated or not, the CSS only puts the issue off until we agree on the default settings for the CSS. Davilla 08:09, 3 June 2006 (UTC)

I don't see where BGN/PCGN is any more ambiguous than the others. Do you have any examples of this ambiguity? The transliterated pages will not usually contain full scale entries, but often merely link to the Cyrillic page, or pages. We need to remember that the purpose of these transliterated pages is to make the language in question more accessible. Eclecticology 06:23, 4 June 2006 (UTC)

The most obvious ambiguity is the fact that е and э are both transcribed as e. So have a guess at how "ekspert" is originally written in cyrillic. Another one is that both й and ы are transcribed as y. How whall we transcribe новый? "novyy" ? я and ю are ya and yu. As a result, йа is the same as я. Of course the combination йа is quite rare in Russian, but someone who has to rely on transliterations is not likely to know that. Another one is ц = ts, but т and с are also t and s. Same problem. — Vildricianus 10:50, 4 June 2006 (UTC)

"Ekspert" would clearly begin with "Э" because "Е" would be transliterated as "Ye" in the initial position. See the footnote to the table. "Э" only rarely occurs in other than the initial position. I have no problem with "novyy". As for "йа", we need to remember that "й" is almost always preceded by a vowel to which it will assimilate. Your strongest case is probably with "ts". The most common use of "тс" is no doubt in the 3rd person of reflexive verbs, and this usage can be isolated. In any event we still need to keep in mind the purpose of these transliterated pages. Eclecticology 04:34, 5 June 2006 (UTC)

Right, that's an even better example. Also, if "ye" is used for initial е's, then there is the problem of Йемен. The problem with "novyy" is clearly the ambiguity. People relying on transliteration won't know which comes first, the ы or the й, or if there are two й's or two ы's. I'm not sure whether we should start creating transliterated pages (i.e. a page like novyy). I have serious doubts at how helpful they would be. — Vildricianus 10:54, 5 June 2006 (UTC)

Part translations

I was just editing ankle after reading the discussion above about translations and noted that the German was:

• German: (Fuß-) Knöchel

This is bad for a number of reasons. A user with little knowledge of German might interpret this meaning that "ankle" in German is one of the following, all of which are wrong:

• Fuß-Knöchel
• FußKnöchel

or even, in an extreme case:

• (Fuß-) Knöchel

In fact, the translations are "Knöchel" and "Fußknöchel".

Print dictionaries abbreviate translations in this way to save space and ink, but we really should not be doing the same, not simply because we don't need to, but because it can be misunderstood. The correct thing to do is to write all translations out in full to avoid ambiguity and allow them to be wikified. — Paul G 11:03, 30 May 2006 (UTC)

I quite agree. The Grappler

Request for Bot status: User:CommonsTicker

Discussion moved to Wiktionary:Votes/bt-2006-05/Request for Bot status: User:CommonsTicker.

Another gripe about translations...

Translations in languages in non-Latin scripts are transliterated after the translation. However, I notice that some people have mistaken these for pronunciations and have been adding pronunciations to their own translations. Some of these are in bizarre-looking pronunciation schemas that do not correspond to anything we use in Wiktionary (containing characters with all sorts of diacritics). I'm thinking in particular of the large number of Modern Greek translations (see, for example, carbon).

Several points:

• Transliterations are to be encouraged.
• (tangentially) Translations should be in a standardised form for the given language rather than ad hoc (see the Grease pit).
• The pronunciations belong in the foreign-language entry, not after the translation.
• These pronunciations should be given in standard pronunciation schemes (IPA and SAMPA), not the pronunciation scheme used by a given print dictionary. I would say the same goes for the Italian entries with pronunciations in (I'm assuming) Zingarelli's schema (sorry, SemperBlotto) {- nothing to do with me - my Zingarelli Minore hasn't got pronunciations} SemperBlotto 10:40, 31 May 2006 (UTC)

Sorry, I thought it was you... there are some pronunciations that use underscore s for /z/, for example... do you know where these come from? — Paul G 15:47, 31 May 2006 (UTC)

• (tangentially) If we accept particular translation schemas for particular languages, we must provide tables for these schemas somewhere or else they are completely useless.

  Maybe we can start by using any schemas that are already in place on the other language Wiktionaries. Does anyone know if these might already exist? Davilla 17:35, 31 May 2006 (UTC)

  The thing is, IPA should cover any language and so is sufficient. SAMPA (or X-SAMPA) will do for most languages too. If other wiktionaries are using other schemas, this could lead to a proliferation of systems here, one for each language, which could be difficult for the user to understand. IPA, on the other hand, is a one-size-fits-all package. — Paul G 13:11, 1 June 2006 (UTC)

  Actually, it isn't the way we use it – remember the whole /r/ versus /ɹ/ business. Widsith 13:14, 1 June 2006 (UTC)

  Hm, that's true; however, the point remains that IPA is able to represent the pronunciation of pretty much any language: in that sense, it is "one size fits all". — Paul G 09:46, 2 June 2006 (UTC)

Unfortunately the practice of adding pronunciations seems to be assumed to be standard and is pretty widespread... what can we do to clean this up and make sure things are done by the book? One thing of course is to contact those who have been adding pronunciations and ask them to stop and help clean up what they have done. — Paul G 09:18, 31 May 2006 (UTC)

Hear, hear. Widsith 09:34, 31 May 2006 (UTC)

Looks like User:81.208.74.180 was responsible for the Greek pronunciations. I have asked him/her to move them, change the pronunciation schema and replace them with transliterations. I don't want much, do I? :) I've also said that admins will be happy to help if need be. In any case, his/her contributions will give us a list of offending articles to work on if someone else wants to/has to do this. — Paul G 14:25, 31 May 2006 (UTC)

Only 1069 bad edits so far, from Special:Contributions/81.208.74.180. No responses on their talk page - an admission of guilt, of sorts. Would it be better to block this "contributor" and roll back all of his/her edits? --Connel MacKenzie T C 15:44, 31 May 2006 (UTC)

I think blocking would be a bit harsh... I'm sure he/she entered these in good faith. I think it would be more helpful to get him/her to help do the work needed to clean it up. Rolling back is not appropriate either as many pages have been subsequently edited by others. — Paul G 15:50, 31 May 2006 (UTC)

Has anyone tried striking up a conversation in Italian on User talk:81.208.74.180? --Connel MacKenzie T C 15:52, 31 May 2006 (UTC)

So we can finally see how well Jeff and Paul speak Italian :-) —Vildricianus 21:00, 31 May 2006 (UTC)

Per me, non è un problema, ma non capisco come sa Connel che l'utente parla italiano, almeno che l'indirizzo IP sia in Italia. (That is, "It's not a problem for me, but I don't understand how Connel knows that the user speaks Italian, unless the IP address is in Italy.") — Paul G 12:49, 1 June 2006 (UTC)

Magnifico! And yes, you can always use the IP lookup links at the bottom of each IP talk page (see User talk:81.208.74.180, the IP is indeed from Milan). —Vildricianus 13:48, 1 June 2006 (UTC)

Don't block, gag or whatever, even temporarily, even if it doesn't stop. It's a hundred times easier to delete, possibly move, esp. in a regular pattern like this, than the effort it took to add all of that useful content, albeit in the wrong place. Davilla 17:41, 31 May 2006 (UTC)

The user has made many helpful contributions. It will not be too difficult to add the following functionality to a cleanup 'bot:

For each Greek translation table entry: strip parenthesized roman text, generate transliteration of Greek text, move Greek text and accompanying transliteration into a template that wraps the transliteration into a span that users can hide.

How about preserving the pronunciation on the page of the Greek word, or at least in a table where this can be later accomplished? Davilla 16:36, 2 June 2006 (UTC)

Hmm, more challenging but still feasible, probably requiring bot-assisted cleanup so the editor can verify that the supposed translation really is one. (Additional conversation on the cleanup possibilities probably belongs in WT:GP.) Rod (A. Smith) 09:21, 4 June 2006 (UTC)

I'd still work with the user regarding the best style for subsequent entries, but since we can automate cleanup of the previous mistakes, I wouldn't insist that the user correct them manually. Rod (A. Smith) 16:30, 31 May 2006 (UTC)

Incidentally, I've updated WT:ELE with the points about translations I have made here and further up (add multiple translations in full; don't add pronunciations to translations). — Paul G 12:56, 1 June 2006 (UTC)

I have translated my posting on User:81.208.74.180's talk page into Italian, updating it to point out the discussion we are having here and saying that we are intending to make changes (rather than throwing all of the responsibility for these changes on the user). — Paul G 09:54, 4 June 2006 (UTC)

Spelling reform

I've noticed in the French Wiktionnaire a spelling reform, which I thought I would've been aware of, being a French geek and all. Apparently This "Rapport de 1990 sur les rectifications orthographiques" changed the way Francophones were allowed to spell. Which is nice. So anyway, loads more French words became "valid spellings", so stuff like naitre it seems is aceptable (which my teachers would always scold me for using), although I've always heard, used and been taught naître. How bizzare. As for English Wiktionary then, would we have places for words like naitre, saying sth like "variant of naître - the French Wiktionnaire uses the 1990 revised spellings, and they know better than us, so I'd reckon we should follow suit and used the revised spellings too. I think there was meant to be a question in here, but I forget what it is. --Newnoise (Shout louder) 18:35, 31 May 2006 (UTC)

Keeping "naitre" as a variation of "naître" should be just fine. The fact that France has adopted these spelling reforms does not mean that other French speaking countries have adopted them. Eclecticology 11:28, 2 June 2006 (UTC)

I agree with Eclecticology (although organizations from some other countries also officially approved this report). The French wiktionary preference for the revised spelling was a former policy, but I think that contributors now agree that the main criterion should be usage, and usage prefers, in most cases, the traditional spellings (most people are not even aware of the existence of this report). Old Wiktionnaire entries have not been updated accordingly. Lmaltier 17:11, 2 June 2006 (UTC)

The historic spellings have, well, historic value...espcially is someone is looking up a term from an older text. The older spellings can of course be tagged as archaic/obsolete/non-standard/whatever or a ===Usage notes=== section added, as appropriate. --Connel MacKenzie T C 15:01, 7 June 2006 (UTC)

This gets complicated in some languages. Dutch has undergone two major spelling reforms this century (and probably several smaller ones). The result of the first one simplified conjugations and genders, merging masculine and feminine into a single "gendered" (versus neuter), and to all but elimiinate the conjugational forms of nouns. The result is that there are many thousands of words (and word forms) that only exist in Dutch pre-20th century. Nevermind the spelling changes that were made in the two reforms. I have to keep three sets of Dutch dictionaries on hand at home in case I need to translate something from a period will idiosyncratic spelling forms. In other words, simply labelling a form as "archaic" or "obsolete" won't be enough in some languages to make it clear what's going on. I cna't think of a better approach, unfortunately. --EncycloPetey 02:00, 16 June 2006 (UTC)

Wrong: last century :-). I know, tempus fugit. There seems to be one each year by the way, always finding some trivial nonsense to change. As for the older forms, I'm sure it will take a long time ere they're going to be developed here. Few Dutch-speaking people still understand the inflected version of the language and need a dictionary too. — Vildricianus 09:31, 16 June 2006 (UTC)

Policy re Verification

Perhaps I am re-inventing the wheel. I want to re-open the debate about verification / inclusion on a policy level. Perhaps one of the clever chaps could move this to an appropriate forum and link discussions. There is much acrimonious debate over what should and should not be included and for me the discussion is too broad. I propose that we discuss one point comprehensively and reach consensus. Thereafter we discuss a further point and reach consensus etc. Each aspect of the colloquium should last for a period of two weeks. If consensus is reached, the summarized point will be put up on a semi-policy document. If not, the discussion will be removed from this page to a separate forum while the next point is discussed. I realize that two weeks is short, but we have all entered into the debate at one point or another, and this is an attempt to crystalise ideas and not to rehash old ground.

I should like people to be as concise as possible. In terms of formatting the debate, please use #* for your first point and make the point in bold. Thereafter use #: :for any sub-points and : for responses to a particular contribution. under that contribution.

Please remember that this relates to verification / inclusion. It could be used as a base for all entries, but I am considering the discussion particularly for purposes of verification procedure.

Please also let me know if you are not in favour of this type of discussion, as it would be pointless to continue if that is the case.

If you are in favour, please suggest topics to be discussed in this format. I do not want this to be my project only, and would prefer others to think clearly about topics that will improve the Wiktionary project and to prepare similar proposals. Andrew massyn 21:03, 31 May 2006 (UTC)

My proposal for the first point:

1. Citations.
   • Current policy (observed in the breach) is to have three citations per definition.

   Citations to be independent and spread over at least a year
   OR one citation from a well known work --Enginear 03:12, 1 June 2006 (UTC)

   If a word is put up for rfv or rfd, it is not for the person who submits the word to find the verification.

   Those who wish to defend the word,should put three appropriate citations on the rfv/rfd page and on the page in dispute. If the defender of the word cannot be bothered to do so, and merely waffels about what a great word it is, it will be assumed that citations are not readily available, and the word will be a candidate for deletion after the appropriate period, without further discussion.

   There is no point in ?trebling the length of rfv/rfd pages by copying the cites to them in full, particularly as the entry page is linked in the section title. A note that cites have been added (perhaps also noting, eg, 2 books & 1 blog, from 1980 - 2005) should suffice. --Enginear 03:12, 1 June 2006 (UTC)

   If it is a new word, with no appropriate citations, the defender of the word must say so, and provide cogent reasons why the word should be kept.

   The reasons should contain at a minimum,

   Where used and a quote. (1 citation)

   Confirmation of the spelling.

   Confirmation of meaning.

   • The citations should be in date order.

   If an earlier citation is found, it would be great to substitute the earliest citation.

   • The citations should illustrate the particular definition aptly.

   Because Wiktionary is not a paper dictionary, the citations can be somewhat longer than in a paper dictionary, which would add interest to the word.

   • The citations should be independent (Who wants to define independent?) --Enginear 03:12, 1 June 2006 (UTC)
   • (Depending on outcome of WT:GP#2-level_dictionary):

   Unless the earliest citation is over one year old, the definition will be tagged and marked as (Protologism)

   Unless the latest citation is less than 20 years old, the definition will be tagged and marked as (Archaic)

   These tags could probably be kept up to date by bots

   If all the cites are from technical sources (or sources relating to use only within a small community, or a particular region) and there is no non-citable evidence demonstrating likely wider usage, the definition will be tagged appropriately --Enginear 03:12, 1 June 2006 (UTC)

   • A written work is the preferred means of citation. (for purposes of this discussion, a dictionary is not a written work).

   While this is my practice too, I am not fully comfortable with it unless the text is available online -- it is obviously useful for people using wt to be able to look up the wider context of a quote, which they can do with an online book or a blog, but not with other books. Possibly therefore blogs, etc should rank between online books and offline books. --Enginear 03:12, 1 June 2006 (UTC)

   For a book work the citation should show in the following order and format:

   The first date of publication of the work. (in bold)

   The relevant quote with the word cited in bold.

   The author. (In italics)

   The name of the publication (In Italics)

   The publisher. (in Italics)

   The page number (in Italics).

   If applicable, a link to an online source for the publication.

   example:

   1976 “John grabbed his angora goat and ran for the hills.” William Spokeshave: The Trials of John and his Goat: Bloomsbury p.135.

   Wiktionary:Quotations#How to format a quotation explains that the format was changed from one similar to the above to the present standard, to accomodate the use of templates for frequently quoted works. --Enginear 03:12, 1 June 2006 (UTC)

   My policy has been to link to online sources, except when I read it on books.google -- any comments on this approach? --Enginear 03:12, 1 June 2006 (UTC)

   If the page becomes messy because of too many citations, they should be placed on the citations page with the appropriate link. I personally do not like this, and would prefer them on the talk page, but precedent is against me and it would not be sensible to change the policy now.

   This abuts, or even overlaps, discussion at WT:GP#2-level_dictionary (which could sensibly be renamed, since it has morphed). In my view (albeit as someone who likes cites to be immediately available adjacent to the defs they relate to) two cites usually look alright adjacent to each def. A minor change of formatting (eg greater indent) would probably mean three would look OK, ie not obscure the defs themselves. I shall be arguing for that. --Enginear 03:12, 1 June 2006 (UTC)

   If the citation is a newspaper or magazine, the citation should show in the following order and format:

   The date of publication of the newspaper or magazine in bold.

   The relevant quote with the word cited in bold.

   The newspaper / magazines name (in italics)

   If possible the publisher unless it is very well known. E.g. The Times of London The Times (of London) (owned by the New York firm, News Corporation, who are very proud of owning a paper published since 1785, and would not like its simple name qualified, any more than some, ahem, Londoners ;-) Enginear 03:12, 1 June 2006 (UTC)), Time Magazine, Popular Mechanics, The Washington Post. For purposes of this discussion, “The Angora Goat Breeder” is not a well known work. Please use your judgment here. :).

   The page number (in italics)

   If applicable a link to an online source.

   Example

   16 June 2005 “ Angora goat farmers suffered a setback when the price of angora wool tumbled” The Times of London. p6. wwwtimesof London.com.

   For academic papers

   The date of publication. (in bold)

   The relevant quote

   The Title.

   The writer of the article.

   The academic institution and department.

   Example

   July 2003 “The influence of angora goat farmers on medieval basket weaving cannot be underestimated. Indeed Smith opt cit states that angora farmers bought most of the baskets!” The history and development of medieval basket weaving in Delft. Victoria Crumb. PhD. Thesis University of Leyden (History).

   The following are not written works. Pamphlets and flyers.

   • The next preferred means of verification is a published dictionary.

   My view is that the community should prefer certain sources.

   Oxford, Webster’s & Chamber’s spring to mind immediately. For technical words, a technical dictionary would be appropriate.

   The citation should be as follows.

   The date of publication (in bold).

   The name of the dictionary in full.

   The publisher.

   The ISBN number.

   Certain dictionaries should not be used.

   Urbandictionary seems to rank in this category. If there are others, please amplify.

   Any self-editible dictionary on line should not be used.

   Self-editible dictionaries seem to be self-referent, or worse plagiarise shamelesly from each other, and are therefore not to be implicitly trusted.

   One dictionary citation is not sufficient for verification. It could be part of the three sources quoted.

   There should be at best one dictionary source per entry, but as stated above, the preferred source is a written publication.

   I suggest not more than one dic to count towards the 3 cites (or even go for 3 non-dic cites + one dic) --Enginear 03:12, 1 June 2006 (UTC)

   • In ranking order, a web-page is third.

   The web-page should be from a cached source.

   Agreed, and I've read that google caches all blogs, but how do we actually know what's cached? Does anyone know? --Enginear 03:12, 1 June 2006 (UTC)

   Any word with less than 20 hits from a search engine must be examined closely.

   This is an arbitary choice. My personal inclination is to make it less than 100 hits. This should exclude genuine spelling mistakes as opposed to spelling varieties.

   In my view, screening adequately to ensure that three cites relate aptly to the definition, and come from acceptable, independent sources, usually covers this (17 more are probably mirrors of Wikt, etc, and 80 are misspellings or relate to different defs) so it needn't be independently specified. --Enginear 03:12, 1 June 2006 (UTC)

   It would also screen dialectic use. See point below.

   Subject again to the outcome of WT:GP#2-level_dictionary I believe all attested dialects should be included (appropriately annotated) partly to increase usefulness to the majority of English speakers, who speak dialects, and partly because the etymology is fascinating (eg, I'm told that Ghanaian dialect for brother (pronounced brer) is totally separate from the Jamaican brere, even though many of the slaves shipped to Jamaica had been captured by Ghanaian tribes. One day, when I know more of linguistics, I may research it.)

1. I would even argue that ideolects may be valid if they belong to people who make public speeches, write books, etc. Present such people might be w:George W. Bush and w:John Prescott. People with only occasional word-related gaffes, eg correcting "potato" to "potatoe" are probably not eligible. A past master of gaffes was w:David Coleman, British sports commentator, after whom the [Private Eye: Colemanballs] column was named. Arguably, the criterion should still be 3 independent cites, presumably the original speech/text plus two other people knowingly quoting it in their own work. I do also think that words made up by authors, and which have a clear definition, should be added (and I don't understand claims that the Clockwork Orange words are undefined -- I am fairly sure there is a glossary of them at the back of my copy of the book (unfortunately packed away for a few months until I get my house extension built)). --Enginear 03:12, 1 June 2006 (UTC)

   Any editible page should not be used, except as a last resort.

   This will dispose of words which are used in tiny communities and are therefore so regional as not to be regarded as "English" but as a regional dialect.

   Because it is a last resort, such entries will be subject to harsher scrutiny.

   • In ranking order, spoken words rank fourth.

   Spoken words include words from movies and television.

   Unless a script is provided, verification of spellings meanings etc are difficult.

   Meaning is particularly difficult. Take for example, Mark Antony's speech in Julius Ceaser "For Brutus is an honourable man." Depending on the actor's intonation, Brutus could be either honourable or dishonourable. An actor interprets the scriptwriters words, and may give a spin to the speech that the scriptwriter never intended. Obviously in this case irony featured strongly, but it is not always that easy.

   As Widsith pointed out to me recently "Any word can be used ironically." I now agree with his viewpoint that we should only define the non-ironic use. But I think we could add a note to a particular quote (intended ironically). Also, in this case, we would be quoting the script, rather than a particular actor. Your point is valid when there is no script, eg an ad lib, and for that, one would have to hear it to be sure. --Enginear 03:12, 1 June 2006 (UTC)

The last two point links with the next topic to be discussed, namely "Regional English, Nonce words and Neoligisms.". however input here will assist me in developing the topic. Kindly provide input one way or another, including whether it is too detailed or not detailed enough; as I will then know whether to continue with this project or not. Many thanks to all. Andrew massyn 21:03, 31 May 2006 (UTC)

I think the level of detail so far is about right. --Enginear 03:12, 1 June 2006 (UTC)

Davilla's comments

I'm not going to respond individually to any of the ideas above because, although I agree with them for the most part, aside from a few quibbles, I do not consider the discussion to be properly approached, and it would be better to start over with a more solid foundation. On the first hand, you mix issues of formatting with this policy. Your treatment of preferred texts also jumbles other issues into it. For instance:

• You claim that dictionaries are not valid references. On the contrary! Although an entry for a particular word classifies under mention and does not meet the criteria for use, a word that is actually used in defining another word should definitely be included. Consider, for instance, if a printed slang dictionary claimed that a word was introduced as a protologism in a certain year, and became a neologism a few years later. I would definitely count that as an attestation of protologism!!! On the other hand, a peer reviewed journal that defines a term does NOT count as use if the term is not used thereafter, being defined only illustratively in a linguistics study, for instance. Yes, I understand your intent, and usually you'd be right, but I don't think the question is approached correctly.

One advantage of a wiki -- it only needs one of us to spot erroneous wording, and it can be corrected! I think we are agreed that the statement at WT:CFI#Conveying_meaning is appropriate. Whether the book is a dictionary is irrelevant (except to note that a reputable dictionary is a peer-reviewed work) --Enginear 06:01, 2 June 2006 (UTC)

• Meaning can be derived just as easily from a script as from a printed work. The question of indication of usage is an important one, but it can't be divided into print versus speech. Granted, irony is less common in writing because it can be misunderstood, but there are equally other ways to use a word without giving much indication of what it means, e.g. "I love my cat because she's so adorable" versus "A cat uses its long tail to balance itself." You see, indication of usage, supporting a definition worded one way versus another, is a separate problem. In my opinion you therefore rank spoken words too low, especially in modern media. Your example of "an honourable man" perfectly illustrates why recorded speech is in fact superior, since the printed script loses a layer of information. Web pages on the other hand are much less reliable. After all, if quotations from a blockbuster movie, lowly ranked in your scheme, occur on some schmo's webpage, would you then rank it more highly as a result? I've seen plenty of webpages that were flat wrong.

I feel cites have two equally important purposes:

• they allow us editors to prove (now and in the future) that the usage we claim in the def is valid
• they allow users (at times in the future) to see examples to improve their understanding of what the def means

For the first purpose, the cites must be expected to be available, archived, for some time, accessible to (say) at least two admins; for the second purpose, since it is often useful to read the context, the long term archive is still important, but it must now be readily available to all users, ie must be available online.

We don't necessarily need all cites to be available online, but I suggest at least one per def should be. Any highly successful TV programme is by [my] definition a "well known work". If the script or an audio file is available online, I would personally place it equivalent to a book, etc available online; otherwise, if available on video (or in a publicly-sold book of scripts) I would place it equivalent to a book, etc unavailable online. Obviously, if there is no written source generally available, it might require a letter to the scriptwriter, or similar, to confirm the spelling, but that is no more onerous than confirming the pronunciation of a written word. --Enginear 06:01, 2 June 2006 (UTC)

Dialects again are a different thread of thought, and the question isn't how to verify the word as how to verify the dialect. This and the other issues should be separated from an assessment of what goes into verifying a word. You've also exluded a lot of process, such as what happens when a failed word is resubmitted. I would offer a different criteria than the pure number of hits on a seach engine but it's a personal preference, and I've blasted you enough already. Anyways, it's not because of the content so much that I disagree with the above, as it is the reasoning. Davilla 09:58, 1 June 2006 (UTC)

Thanks for that input. In the opening paragraph, I said that I wanted to review verification in general, and proposed that individual topics be discussed under that heading.

The first discussion (which I had hoped was going to be non-contentious) was of citations only.

The next thread would be Regional English, nonce words and neologisms, again under the broad heading of verification. In this way, as a community, we can "nail" a topic and be done with it before moving to another.

Sorry, I read too much into what you had written, and took Enginear's comments to support that assumption. Davilla

I understood the intended focus, but in hindsight my answers strayed outside it -- sorry. --Enginear 06:01, 2 June 2006 (UTC)

Since formatting relates to citations and was therefore included.

Unless you're going to delete entries because the quotations are incorrectly formatted, the importance as far as formatting goes is how much is required for verification. A link to a search doesn't do anyone favors. Are external links to the correct pages sufficient by themselves? Are they helpful when other information is given?

Agreed. Unfortunately, I'm currently also mulling over some comments to give to a GP discussion, where I will argue that, with some changes to layout of quotes, a more readable page can be produced while still keping the cites adjacent to the relevant defs; so my initial response was to broaden the discussion rather than shut it down. I now agree with you, let's concentrate on what is required, and consider how it should look as a separate discussion when we have a better idea of what the whole entry will consist of. --Enginear 06:01, 2 June 2006 (UTC)

The ranking of dictionary citations and spoken words is again part of this discussion, as is the validity of dictionary definitions.

I totally agree, which is why I took space to argue you assessment of the rankings, perhaps confusingly so. Davilla 19:43, 1 June 2006 (UTC)

I agree that dialects are a different thread, which will hopefully be discussed in the next thread, and said as much in my closing paragraph.

If certain things are left out, I would be more than happy if they were included, either at the bottom of the general article or in the appropriate place in the article.

I therefore do not feel that our views are that far apart. Perhaps if you could re-look at the topic now that I have clarified, you will agree with me. If not, perhaps a short pithy series of points you would like discussed under the greater heading verification and the lesser heading citations, would give us all direction as to where we should be aiming this discussion. It is my belief that once the greater topic is cleared up, much acrimony would disapear and the difficulty with asspus type words will have a clear set of rules to provide verification. Regards Andrew massyn 15:54, 1 June 2006 (UTC)

The current breakdown of the CFI is this:

1. Clearly widespread use
   • Dictionaries could be used as references in this case, although these words are not often in contention. Words from any dictionary with stronger criteria than our own should be automatically admitted, and rejected only in special cases when they arise.

     This deals only with the use of cites for editors to verify usage, but not with the use by users to flesh out our definitions. While perhaps a low priority, we should add cites to words in widespread use too. Adults learning English as a foreign language will find them useful. --Enginear 06:01, 2 June 2006 (UTC)

     Usually well-crafted example sentences will suffice in this case. But you're right that the wording of a definition also has to be weighed at times. The full urban dictionary description of choad for instance was severely trimmed. This probably deserves a deal of treatment, and you're right I haven't given any. Davilla 16:12, 2 June 2006 (UTC)

2. Usage in a well-known work
   • This one's a little open to interpretation. For those funny nonce words especially, what does well-known mean?

     Well, someone's got to start: "A work which at least 10 million people (eg the majority of adults in at least one medium-sized English-speaking country) will have heard of and at least 100,000 will have personally read or heard." A strong indication of the latter can of course be gained from statistics of book sales or audience reach, which are, I believe, independently verified in most countries. --Enginear 06:01, 2 June 2006 (UTC)

3. Appearance in a refereed academic journal
   • This one is a bit too loosely restricted, and should eliminate e.g. the names of Java classes, ad-hoc definitions in mathematical proofs, etc.

     I agree, and would go further. In my view, one of our fundamental purposes is to confirm the meanings of words, and certainly the fundamental purpose of cites is to attest that the word was used in the way defined. So I believe that WT:CFI#Conveying_meaning should apply to individual defs of words in clearly widespread use, in well-known works, or in refereed academic journals, as well as the "other" category it currently applies to. Re "meaningless words" I would argue that even um and er convey the meaning I've just noticed that my brain is working slower than my mouth. It is arguable that, for the sake of confused readers trying to make sense of Jabberwocky we should include nonce words from well known works, but I sense the majority here believe that is the function of encyclopedias rather than dictionaries, and I am now ambivalent about it. --Enginear 06:01, 2 June 2006 (UTC)

4. Usage in permanently-recorded media, conveying meaning, in at least three independent instances spanning at least a year.
   • This is the meat of the matter. The others are for the most part pragmatics to make this practicable.

     We need to consider both the number of cites and the minimum time interval from first to last. I agree with the time interval. I am happy with three cites conveying meaning. I am prevaricating re whether two cites + "any" dictionary entry should be adequate. I think it should only be valid if the requirements for citation on that dictionary are similar to, or better than, ours. --Enginear 06:01, 2 June 2006 (UTC)

     We also need to bear in mind that we are all thinking about English words. At some point we need to specifically consider foreign words and, in particular, "dead" language words, eg OE or Latin. Since it is more difficult to find cites (and particularly online cites) should we allow a lower standard for them? --Enginear 06:01, 2 June 2006 (UTC)

(Note that this is an entirely separate issue from idiomacy or encyclopedic nature.)

Which we must be sure to discuss (perhaps under another heading) --Enginear 06:01, 2 June 2006 (UTC)

I would start with the last item instead, forming a definition of what we consider to be a word (giving nonce words special treatment), and then list ways to verify it, whether from a dictionary or citations or what have you.

As a designer, I see here the standard disagreement between those who like to approach a design "from the bottom up" as AM has started, and those who like to approach it "from the top down", as you propose. Many studies in many different fields have concluded that there is little difference in efficiency or in the quality of the finished product, the reason being that actually the process is always to some degree iterative. Those arguing the merits of a bottom-up approach often point out, as AM did, that it allows a start on non-contentious issues. However, while some people's minds are attuned to this method, others find it hard to concentrate on details when they haven't agreed fundamentals.

Okay, that's fair. Davilla

I therefore propose a method I have used for managing complex building designs:

• Start by looking at details at the bottom. Come up with solutions that seem about right, but do not cast them in stone. Park them, and move on up.
• Sometimes, changes at the next level may mean that bottom items will require review. Note that, but do not make the corrections yet, even though the method required may be clear. Continue up, repeating the process through as many levels as necessary.
• Arrive at the top. At this point, the "top down" people will perk up and give new life to the design, while the "bottom up" people will be very clear about what is likely to be practicable and what isn't. The result will usually be good, efficient and appropriate.
• Start working down again, making corrections at each level as required. With the experience already gained by discussion on the way up, this will usually be very quick, but some arguments will have to be rehearsed again for the benefit of "top down" people who couldn't visualise them properly without knowledge of the "top" item.
• Arrive at the bottom again, press "Go" and celebrate!

So in short, I am happy to support AM's proposed step by step process until we reach the fundamental issue of what we consider to be a word, leaving draft policies in place as we go. Then, moving down again, modifying the draft policies as required to fit the new requirements, until all items are in place and the policy can go live. I think this is a particularly valid way for a wiki to make policy decisions (certainly it has worked before for pretty disparate sets of designers with no clear heirarchy) since the ability for people to contribute either "top down" or "bottom up" according to their preference should enable a consensus to be reached quicker. --Enginear 06:01, 2 June 2006 (UTC)

Then go into citations. Permanent media is required, and the more professional the fewer demands are placed. For instance, an academic journal may not even have to convey meaning, whereas a personal blog or usenet post would be highly scrutinized.

I disagree. Certainly, there are some "privileges" for words from academic journals, eg (except for quoted speech, etc) they should be exempt from any allegations that they are (informal use only). But in general, no cite is useful for attesting usage according to a particular def unless it either conveys meaning or is defined in a dictionary which itself requires cites conveying meaning. (For an exception, see Talk:tonk.)

To take an example, I have just checked the title page of my NIV Bible. Surely, any words on a title page should be important cites? Well, No. The page ends with the following seven words: Hodder and Stoughton London Sydney Auckland Toronto. Perhaps the and is a useful cite, but only because it is a clear example of its use to join two words of near-equal status. Our familiarity with standard title page formatting would lead us to predict that L, S, A, T were locations where the publishers operated, and indeed that Hodder and Stoughton were parts of a publisher's name. But I do not see that any of the cites, except for and are worth having. --Enginear 06:01, 2 June 2006 (UTC)

Otherwise, the easier to verify the better. Webpages are ranked low because they are malleable, hence a cached version, not the easiest thing to find, may be required. Discussion forums are ineligible.

I would still welcome any advice on exactly what on the net is known to be cached. Are discussion forums perhaps excluded because they are not cached? Is that the difference between them and discussion groups which, according to WT:CFI#Attestation are "favored"? And how am I supposed to know the difference? --Enginear 06:01, 2 June 2006 (UTC)

Then go into the process. If Google hits don't turn up even a single relevant entry, this project and its mirrors aside, it's safe to speedily delete. If it turns up ONLY as definitions in other online dictionaries, then that counts as no attestation, so it's safe to speedy. If it turns up urban dictionary cruft and a bunch of questionable pages of material, it has to be placed through the verification process if not contested for other reasons. The number of hits is irrelevant. If there are two hundred Google hits and an admin goes through every one of them, and then through those of potential alternate spellings, it's safe to speedy delete. The question is just where you make the tradeoff between listing for deletion or completely checking first. A slang dictionary might not be suffienient to show widespread use, nor could it be used as a citation of the word in use, except for one printed dictionary in this above proposal, but regardless it would be legitimate grounds for giving the entry some leniency in the verification process. A discussion thread doesn't count as a citation, but it lends further credibility. I would say that only in the case that nothing legitimate is presented can the entry be deleted without being requested for deletion. Davilla 19:43, 1 June 2006 (UTC)

There are actually three points implied here:

• What should be the procedure for Speedy DELETE/RFD/RFC testing/voting?

Not actually discussed here, and neither have AM or I mentioned it. Perhaps we should have. However I suggest that the decision to delete will require consideration of more than verification, so is beyond the remit of this discussion. It would seem appropriate to consider moving on to that at the end of the process.

• What is the minimum verification requirement for a non-compliant entry to avoid the chance of speedy DELETE?

Since speedy DELETE is potentially wasteful, it seems reasonable to propose a minimum standard of citation which will avoid its use. However, it is soon clear that this is hard to generalise. For example, for an entry which was clearly extremely offensive, liable to promote mass violence, cf the "Images of Mohammed" furore which "resulted in over 130 deaths" [[7]], or even illegal, I suggest that the minimum to avoid speedy DELETE would be an entry in Webster's, the OED or Chambers. However for non-offensive safe, legal words, I would second your proposal, which I take to mean: if there are any google hits which the admin has not yet checked, or if there are any which show usage conveying the meaning in the definition, speedy DELETE should NOT be used. For words which are mildly offensive in between, eg possible libels, the admin can use judgement between the two extremes.

What does offensive have to do with it? This is the same crowd that railed when Webster's Third added ain't in 1961, that wouldn't accept fuck in a dictionary until 1965. A word's a word. Davilla 16:12, 2 June 2006 (UTC)

Yes, and the pen is mightier than the sword! But my bad choice of words -- I was obviously too tired, and have now modified them. I am strongly against censorship, but I also feel that no one person, particularly an amateur, should be allowed, on their own, to use a community enterprise to cause civil unrest, or use it in such a way that it is shut down by the courts, to the detriment of the rest of us, and indeed the rest of the world. There are (at least potentially) a very few "words" which should be debated in relative privacy, and made public after they are approved as good quality and in accordance with CFI, rather than being left in the public gaze during the debate. We have a growing number of users. The best defence against court action is to have an appropriate policy in place and to follow it. More importantly, it is also the best defence against "collateral damage" in the war against censorship, which we might regret for the rest of our lives. --Enginear 01:03, 3 June 2006 (UTC)

Two further occasions warranting speedy DELETE:

• At the end of the RFV/RFV-Sense month (see below) there are still no cites at all, and there have not been any positive comments (except perhaps by contributors with a reputation for unreliability).
• Further entries added by a contributor who has been asked to desist until RFV/RFD issues with an existing entry are resolved.

• What should be the procedure for RFV/RFV-Sense testing?

This should be an "output" of the process, but we have not specifically mentioned it. In my view, unless the discussions at Wiktionary:Grease_pit#2-level_dictionary result, via BP, in a change, the requirement should be that unless the entry complies with the standard of citation mentioned within one month, it should be RFDed. Additional time could be given if a cite had been disallowed within the last week or, discretionally, if an editor specifically requested an extension to allow further research.

I don't have any problem with automatically deleting a failed word provided there are no quotations or references at all, and no comments by known contributors on its behalf, the "I've heard this before" sort. I would consider an effective extension of the RfV process to be automatic in the case that consensus is not reached on the subsequent request for deletion. An editor could request as much; however the vote of one person does not determine the consensus. Davilla 16:25, 2 June 2006 (UTC)

In general, I agree. However, I suggest that positive comments should be acceptable "from all except known unreliable contributors" rather than only from "known contributors". To give an unknown the benefit of the doubt only means an RFD process rather than a speedy delete. I have to admit a personal interest here, as I discovered the RFV page at a time when I had only added one new entry and done minor edits on about six others, and noticed a queried word which I thought I'd heard, and which had already been listed for over a month. I left a note saying so, and that I would search for cites, but it might take a few days (16 days as it turned out) so please wait. It would have been very discouraging if I had returned to find the entry had gone. --Enginear 01:03, 3 June 2006 (UTC)

If the contributor of an entry which appears to be against CFI then starts adding more entries which appear dubious, he should be asked not to do so until the RFV/RFD process on the first one is completed, and warned that any entries he does make during that period may be speedy DELETEd on sight (to avoid wasting everybody's time by running through the RFV/RFD process for each one).

A possible outcome of discussions at Wiktionary:Grease_pit#2-level_dictionary may be to recommend to BP a change of policy to allow words/senses without adequate verification to remain, but be tagged (sense not verified), (protologism), etc as appropriate. We should bear this in mind as we proceed, in case we have any useful comments to make. However, I do not think it is likely to effect the process of verifying the "normal" dictionary. --Enginear 06:01, 2 June 2006 (UTC)

• The citation approach to verification is flawed because three citations are never enough to demonstrate meaning. Most dictionaries need at least a dozen citations for usage in a certain sense to be demonstrated. For example, the entry "magnetic resonance imaging" in Merriam-Webster's Collegiate Dictionary has 30 citations on file, and "greenmailer" has 19. Further, people verifying a sense on the Request for Verification page often grab quotations from publications in a single field from an online source. If you want to ascertain the meaning and popularity of a term, you will need to examine a broad range of media, from radio and television transcripts, to periodicals and books. You will also need to examine quotations from media designed for more than one audience. Printed dictionaries are, in general, the most reliable books in the world, so if I had the choice between verifying a word using a single citation from the Random House Unabridged Dictionary or three quotes from some books off Google Book Search, I would use the dictionary without any hesitation at all.--Dfd33 01:25, 3 June 2006 (UTC)

• I am wildly against the notion that new users/anon IPs should be respected for RFD discussions. The idea here, is that we regulars are working together to build a dictionary. Occasionally we get outside help. But the reality is, that the majority of new/unregistered users are simple vandals. It takes time to verify if certain users (e.g. User:Dfd33 who only posted here) are sockpuppet accounts of Primetime's or not. To give equal voice to anons/new/non users on the discussion pages is pointless. They can "easily" add references in whatever format they like, and someone will clean it up to our standards, but to have them enter the debate is pointless. How can they possibly know or understand the nuances of prior month's decisions? --Connel MacKenzie T C 21:19, 3 June 2006 (UTC)

Assume good faith, and don't bite the newbies. If the argument seems reasonable respect it on its own merits rather than on the basis of who's saying it. If it's from a genuine vandal, they soon make themselves obvious in the way they express themselves. Respecting anons doesn't mean we have to agree with everything they say. Eclecticology 07:57, 4 June 2006 (UTC)

Yes, I am not suggesting treatment as the equal of a known trustworthy regular, but merely that they are given a little time to research. Were I "clearing out" RFV, my response would be to leave the entry in place for a fortnight after the newbie had posted, to see if they came up with anything useful, perhaps with a note to that effect, as AM has tended to do. A more active response would be to move to RFD (rather than speedy DELETE) or to move it to the newbie's User Talk page. And obviously, if the argument reeks of bad faith, then continue with the speedy delete anyway. --Enginear 17:06, 4 June 2006 (UTC)

---

• This discussion is over 32KB. It needs to be moved, but where?Davilla 16:54, 2 June 2006 (UTC)

• A shift to WT talk:RFV might be appropriate. - TheDaveRoss 06:39, 5 June 2006 (UTC)

This dicussion has been moved to WT talk:RFV due to it's size and the long term importance of it's conclusions. Please continue this discussion there.

I don't think I've understood the purpose of the discussion, even still. Could someone restate the purpose and summarize about three main points, with deep-links to the relevant parts of the conversation, here please? Trying to peruse it, it was very unclear which parts were a reflection of current practice and which where proposed. --Connel MacKenzie T C 04:22, 7 June 2006 (UTC)

dueling vandals

This is pretty cute. I can just picture these two buddies, either sitting in their same dorm room, or (given that their IP's are pretty different) somewhere far apart, but chatting via IRC or AIM or whatever. Eric says to Chris, "Check this out, I just discovered this online dictionary that anybody can edit, go to http://en.wiktionary.org/wiki/dipshit to see. (Heh heh heh.)" And Chris goes there, and sees what Eric has done, and says, "Oh yeah? Two can play at this game -- whyn't you refresh the page, smart guy? (Hnh hnh hnh.)" So then, in retaliation, Eric goes back and... three guesses. Changes it back to his first insult? Changes it to some new and more creative insult? No, he changes it back to what it had been, before either of them got there, reverting both their vandalisms. Unprecedented. –scs 22:09, 31 May 2006 (UTC)

If only all vandals cleaned up after themselves... very cute though. Mostlyharmless 00:52, 1 June 2006 (UTC)

As long as this tactic remains "unprecedented" we don't have to do anything about it. Eclecticology 18:16, 2 June 2006 (UTC)