Wiktionary:Beer parlour

Definition from Wiktionary, the free dictionary
Jump to: navigation, search

Wiktionary > Discussion rooms > Beer parlour

Lautrec a corner in a dance hall 1892.jpg

Welcome, all, to the Beer Parlour! This is the place where many a historic decision has been made and where important discussions are being held daily. If you have a question about fundamental Wiktionary aspects—that is, about policies, proposals and other community-wide features—please place it at the bottom of the list (click on Start a new discussion), and it will be considered. Please keep in mind the rules of discussion: remain civil, don't make personal attacks, don't change other people's posts, and sign your comments with four tildes (~~~~), which produces your name with timestamp. Also keep in mind the purpose of this page. There are various other discussion rooms which may serve the idea behind your questions better. Please take a look to see which is most appropriate.

Sometimes discussion identifies an issue as an idea for policy development or rewriting. Such discussions may be taken out of the Beer parlour to a relevant page, or a brand new page may be created. Usually, the active policy pages will be listed in one of the sections below. See also the policy development page and the votes page.

Questions and answers will not remain on this page indefinitely, as it would very soon become too long to be editable. After a period of time with no further activity (usually a couple of weeks), information will be moved to the archives. We make a point to preserve all discussions that were started here in the archives. However, talk that is clearly not intended for this page may be moved and will not end up in the archives. Enjoy the Beer parlour!

Beer parlour archives edit


April 2015

International Journal of Lexicography[edit]

Hi, I'm not sure where to post my question. Is there someone who has access to the International Journal of Lexicography? I'm interested in an article on Dictionary illustrations because we have some recent discussions about it on Czech Wiktionary (they are strictly prohibited there and routinely deleted) and this article is supposed to provide good insight. However I don't want to spend $28 on it (I tried the DeepDyve free trial subscription but they have this journal only since 2004). Thanks to anyone for any help. --Auvajs (talk) 05:38, 2 April 2015 (UTC)

@Auvajs I have access. I've downloaded it and I'll be emailing you with the pdf shortly. —Μετάknowledgediscuss/deeds 06:12, 2 April 2015 (UTC)
Wow, that was so fast! Thanks very much! :) --Auvajs (talk) 06:19, 2 April 2015 (UTC)
Rádo se stalo. —Μετάknowledgediscuss/deeds 06:45, 2 April 2015 (UTC)
Images are really useful in dictionaries. I have an Italian language dictionary - sometimes I struggle to quite make out what the definition means, but then they have it in a page of pictures and I think "Oh! One of those!". SemperBlotto (talk) 07:06, 2 April 2015 (UTC)
@SemperBlotto: In case anyone didn't know: Wiktionary:Picture_dictionary. —Justin (koavf)TCM 07:15, 2 April 2015 (UTC)

Suggested modification to sign language syntax[edit]

In British Sign Language (BSL) there is a hand shape that is frequently used which can't be described using the current notation (usually called '10' http://www.signbsl.com/sign/10). I suggest adding ...i@... (for [i]nside or t[i]p) to Entry_names, Detailed description of phonemes used in sign entry names to fix this. ...i@... would be underneath ...p@... in the Detailed description of phonemes used in sign entry names for 'The thumb tip contacts the inside of a finger of the same hand'. Nathanael Farley (talk) 07:41, 2 April 2015 (UTC)

On etymology referencing[edit]

I recently added a recommendation on WT:ETYM that references for the reconstruction of proto-words should preferrably be centralized on their appendix pages. User:Dan Polansky reverted this with the comment:

I see no discussion supporting such a policy, and it is easy to verify that Wiktionary by and large does not reference etymologies so the putative policy contradicts long-term common practice

This was re-reverted as minor by User:Angr. Fair enough I guess, the page is a draft proposal after all. But I support having some discussion regardless.

There is a vote Reconstructions need references in preparation, but rather than editing that right away I'd like to sound the community for a few propositions — since, in addition to my comment on reference formatting it seems that we lack agreement on reference requirements in the first place as well.

Still, note that in principle these are separate questions. Wiktionary undeniably allows references, and my original comment applies to how they should be organized when present. But regardless, for starters, my thoughts on reference requirements:

  1. All etymological information should be verifiable. Which applies to several types of information, e.g.:
    • A given set of words being related to each other at all.
    • A given set of words being related in a specific fashion: usually, common descent or loaning in a specific direction.
    • Reconstructions (phonological, morphological and semantic) for proto-forms of words that are related by common descent.
  2. Wiktionary is a work in progress, and edits to etymology sections do not need to immediately have every possible detail sourced.
    • It would probably be a good idea to bring in a {{citation needed}} template and other similar ones for tagging information whose validity someone contests, or which someone thinks should just be cited more clearly. (Also, these two things probably need different inline tags.)
  3. Elementary synthesis of sources is allowed. E.g.:
    • Phonetic reconstruction: if we can source to Smorgle that *k in Proto-Foobar is reflected as Foo h, Bar k, and if we can similarly source to Zoop that the Foo word hu and the Bar word ku are related, at this point there is no problem in creating a Proto-Foobar entry *ku, even if we for the moment have no exact citation for this proto-form in the literature.
    • Phonetic reconstruction: if Smorgle gives a Proto-Foobar word *tata, Zoop gives a Steamy Foo reflex haha for this etymological set, and Shroobadoo has argued that Proto-Foobar *t should be reconstructed as *☕ whenever Steamy Foo has /h/, we can just fine reconstruct Proto-Foobar *☕a☕a rather than *tata, even if Shroobadoo never treated this particular word.
    • Etymological affiliation: if von Papperson states that word-initial *pr was forbidden in Proto-Foobar but evolved in early Bar; Böp states that in Swampy Foo there are loanwords such as prumf that have been acquired from Bar; and Zoop states that Swampy Foo pripi and Bar pripi are related, there is no problem in asserting that the former is probably a loan from the latter.

The third point might be the most contentious. Several further caveats may be required, e.g. all claims used as basis for synthesis of sources should probably represent mainstream scholarship. --Tropylium (talk) 07:44, 2 April 2015 (UTC)

I agree on all your points – a dictionary is more than definitions – these are methods that "keep an honest man honest" and separate fringe from scholarly interpretation of facts. Also, scholarly consensus changes and providing references or mentions places the etymology on a timeline for future contributors. BTW, User:Dan Polansky also doesn't like my documentation method of including content that is not an attestation of usage, and doesn't like me referring to Wiktionary:Citations and Wiktionary:References since they are not policies. You are not alone. —BoBoMisiu (talk) 13:32, 4 April 2015 (UTC)
  • Yes, "All etymological information should be verifiable" but that does not mean that the English Wiktionary should demand that parts of etymology are referenced using <ref> technique. I oppose such demand, and so does the overwhelming previous practice. --Dan Polansky (talk) 13:41, 4 April 2015 (UTC)
@Dan Polansky: I noticed your subtle moving the goalposts from a discussion about references in an entry into a discussion about a particular format of references (wrapping references in <ref>s). Referencing helps future contributors, shows quality and credibility of the content, demonstrates veracity, and is valid rationale to defend against accusations of plagiarism and copyright infringement. Transparency is a good. —BoBoMisiu (talk) 15:31, 4 April 2015 (UTC)
Moving the goalposts would be making the standard stricter to exclude what passed the earlier one. As to the point at hand: you do tend toward excess in citing. You don't need to nail down every single detail in a definition with a reference. Etymologies need to be referenced, yes- but not definitions. A descriptive dictionary defines terms the way people use them, not the way reference works specify is correct. If people use water beetle to refer to a cockroach, so do we- even though a cockroach isn't a beetle. Technical terms such as taxonomic names are somewhat of a special case, since correctness as a technical term is relevant. Still, the taxonomic literature is full of misapplied taxonomic names, and of changes in meaning due to splitting and lumping. In my area, most of the scrub oaks referred to as Quercus dumosa are really Quercus berberidifolia- for a long time no one paid attention to the difference. While true Q.dumosa only grows along the coast, there are all kinds of references in the literature in numerous disciplines to Q.dumosa being found/used, etc. far inland. Wiktionary isn't a journal of record, and citing details in the definitions as if we were is a bit deceptive and adds to clutter. That's not to say we shouldn't have links to other, more comprehensive sources, but only in moderation. This is a dictionary, so we try to keep things structured and streamlined for ease of use. Chuck Entz (talk) 17:12, 4 April 2015 (UTC)
@BoBoMisiu, Dan Polansky is not 'subtly moving the goalposts' as what he refers to was part of the original reverted addition. I think the way the server interprets <ref></ref> syntax is ugly, and I try to avoid it. Also, people over use it, they use it for citations instead of just writing out the citation next to the sense which is to be cited, which is the best way to do it. Renard Migrant (talk) 17:23, 4 April 2015 (UTC)
Also verifiable is not the same as verified. Verifiable means if you try to verify it, you can. That's what we want. If something's not contentious, don't add a reference for it, because we end up with references coming out of our ears and the actual definitions become hard to find even for experienced users. Renard Migrant (talk) 17:26, 4 April 2015 (UTC)
@Chuck Entz I agree with you, "If people use water beetle to refer to a cockroach, so do we- even though a cockroach isn't a beetle." Yet, having an entry that doesn't clearly distinguish for the user between what an authoritative sense and what is another just-as-real usage lacks something. As for "making the standard stricter to exclude what passed the earlier one", the three attestations of usage are unaffected, but it structures entries into the haves and the have not, i.e. those entries that are denied a connection to what is considered factual – that is a systemic problem that will not go away. As to ease of use, a collapsed section has all the content and yet provides a visually simple interface, which could be added by a bot, so that is not the same issue as ignoring what every school child is taught (to provide credit to your source and avoid plagiarism and copyright infringement).
@Renard Migrant I agree with you, "verifiable is not the same as verified", that is not the same thing as not giving credit to your source. The notion that excluding things so it looks pretty is just style over substance that can be solved by collapsed sections. —BoBoMisiu (talk) 20:31, 4 April 2015 (UTC)
Etymological dictionaries usually do not give credit to sources on a per-entry level. The idea that you need to credit your source of information on a per-entry level or else you have a copyright infringment is wrong. Copyright protects expression, not information; you can take someone else's information but you cannot take their expression - a particular sequence of words or sentences; if you take someone else's expression, you are liable to have copyright infringement and referencing does not make it much better. Nonetheless, I when I was entering etymologies from a public domain source, I nearly always stated my source in the edit summary; I saw many editors of etymologies not do even that much. --Dan Polansky (talk) 18:03, 4 April 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────@Dan Polansky "Etymological dictionaries usually do not give credit to sources on a per-entry level" because they are paper. Deciding what is or is not someones creative work or potentially discovery is beyond most contributors; transparency is not beyond most contributors. —BoBoMisiu (talk) 18:22, 4 April 2015 (UTC)

That's not just because they're paper, it's also because they have onymous authors who have reputations to consider and who can generally be trusted to do their research. We don't have that luxury. Because we're a wiki that anyone can edit, we have to show that our etymologies haven't been pulled out of our collective ass. —Aɴɢʀ (talk) 18:41, 4 April 2015 (UTC)
Bravo! —BoBoMisiu (talk) 18:47, 4 April 2015 (UTC)
I refuted the copyright infringement assertion, and none of the things added above counterargued that refutation. As for the other subject whether we want to use <ref> in order to show which sources were used, I object to making that a demand or the recommended practice. An editor was adding <ref> to etymologies of Czech entries, and while I did not like it, I did not revert it. But it is one thing to tolerate the use of <ref>, and an entirely different thing to pretend that the English Wiktionary has a policy that requires contributors of etymology to use <ref>; I oppose such a policy, and claim that the use of edit summaries to state sources should be enough; in fact, we have not been chastising editors who provided zero edit summaries and zero references using <ref>. --Dan Polansky (talk) 18:57, 4 April 2015 (UTC)
Nobody can copyright that the English word lemma comes from the Ancient Greek word λῆμμα (lêmma). Also you've confused excluding things with not including things. You're basically arguing that literally everything should be included in every entry, relevant or otherwise. That's nothing to do with style over substance, that's insanity over substance. Renard Migrant (talk) 19:06, 4 April 2015 (UTC)
@Dan Polansky where did you refute it?
@Renard Migrant I agree with you, but chains of assertions that are copied from sources are someone's work. —BoBoMisiu (talk) 19:17, 4 April 2015 (UTC)
Nothing at WT:ETYM requires contributors to use <ref> or to provide sources for their etymologies at all. Doing so is recommended whenever possible; it is not required. Etymologies without references are more likely to be removed as possible bullshit than ones with references, but it is neither the case that all unsourced etymologies are bullshit nor that all sourced etymologies aren't. —Aɴɢʀ (talk) 19:25, 4 April 2015 (UTC)
@Angr I was reminded WT:ETYM is only a draft, so I started to ignore it, maybe I should follow it. I think references add transparency. Like you wrote, that bullshit still needs to be removed whether it is referenced or not. I disagree with Dan Polansky that an edit summary is equivalent to a fully cited reference. I think Tropylium's "Wiktionary is a work in progress" is valid and I suggest forking w:Template:Citation needed span from wikipedia. That template wraps the particular questionable content in a visually distinct box, making it easy to see where contribution is requested and what is suspect. A "synthesis of sources" is a good idea as long as it references where each piece of information comes from. That way a synthesis is transparent. I also think forking w:Template:Citation/core and changing the R: templates into wrappers with consistent parameters is a good idea and a step away from willy-nilly flat references toward structured machine readable data, but that is a future discussion. —BoBoMisiu (talk) 20:31, 4 April 2015 (UTC)
I think you'll find that forking templates from Wikipedia is not exactly popular around here. The people who propose doing so usually don't understand the difference between Wikipedia, with its large editor population, extensive bureaucratic infrastructure, and loosely-formatted, single-entry structure vs. Wiktionary, with its small editor base, simple rules/procedures and rigidly-formatted multi-entry structure, which requires that everything be concise and to the point. As for hiding the References section: that would still leave lots of superscripts, most of which link to statements of the obvious. If you really want to be thorough, how about word-frequency statistics? Binary checksums? Diagramming of the sentence structures? Those can all be hidden away in boxes, but will all lead to reader resentment for wasting their time if they follow the references. It reminds me of pulling over in the middle of nowhere because of a light on the dashboard: it was time for an oil change based on the mileage. If you have too much pointless information, hidden or not, the important information gets lost in the clutter. Chuck Entz (talk) 22:49, 4 April 2015 (UTC)
Tags like [citation needed] do not have communication between editors as their only function. They also alert the reader to pay attention to the quality of the information, and can help editors easily tell where they left off work previously.
I loosely agree with Dan that a citation provided in an edit summary is good enough to retain the edit, i.e. grounds to not revert it, but if other editors want more explicit referencing, it's not a reason to prevent them from adding some. --Tropylium (talk) 23:09, 5 April 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────So a discussion about objective etymology referencing comes down to the subjective – a delicate aesthetic preference of looking at a pretty entry without seeing those brutish superscript numbers? That reminds me of the quote from Amadeus: "It's quality work. And there are simply too many notes, that's all."

@Chuck Entz the solution to your concern "that would still leave lots of superscripts" is to allow the user to choose through a user preference toggle.
References are not just for statements of the obvious. Your propositions about "word-frequency statistics? Binary checksums? Diagramming of the sentence structures?", are an unintentional red herring about potential uses of collapsed sections, they are about different propositions than the one presented by Tropylium which is about references. The revision as of 19:26, 1 April 2015 is:

Etymologies should be referenced if possible, ideally by footnotes within the “Etymology” section, secondarily just by listing references in the “References” section. The Reference templates are useful in this regard.
If a word descends from a common root with several words in related languages, and an appendix page exists for the reconstructed proto-form, references on details of the reconstruction are best placed on that page, rather than duplicated across the cognate entries.

For six weeks, I misunderstood: Etymologies should be referenced if possible, ideally by footnotes within the 'Etymology' section, secondarily just by listing references in the 'References' section.
I, for six weeks, created sub-sections within entry etymology sections. I would like it changed to:
Etymologies should be referencedinclude Wiktionary:References if possible(for policy, see Wiktionary:Entry layout explained#References), ideallypreferably by footnotes within the 'Etymology' section(see Help:Footnotes), secondarily just by listing referencesin theor simply adding the source to the entry 'References' section (for policy, see Wiktionary:Entry layout explained#References).

While Wiktionary:Entry layout explained is a policy, I would like to see a clear explanation about the actual status of Wiktionary:References is. Is Wiktionary:References a policy?

I think that the other paragraph would be more understandable as, If a wordterm descends from a common root with several wordsother terms in related languages, and an appendixa page exists for thethat reconstructed proto-formterm (for policy, see Wiktionary:Reconstructed terms), references on details ofabout the reconstruction are best placedpreferably located on that reconstructed term page, rather thanand not duplicated acrossin the cognate entries.BoBoMisiu (talk) 15:39, 5 April 2015 (UTC)

Ok, after that long tangent on <ref> tags that addresses approximately nothing about my initial post, this is more interesting. Your adjustment of "word" to "term" is obvious, and I've edited that and a couple other language adjustments in. (WT:ETYM is currently only a think tank; you don't need explicit community consensus to edit it, for simple copyediting at least.) Two other comments:
  • I am not convinced that reconstructed terms necessarily require formatting as separate entries, hence the more general expression "appendix".
  • For the same reason, I don't think WT:ELE should be the best place to refer to for reference policy. Appendices are not, necessarily, entries.
--Tropylium (talk) 22:28, 5 April 2015 (UTC)
@Tropylium the reason I point to WT:ELE is that it seems to be the only policy in a vague hierarchy of how-to pages. Some administrators seem to place little value on reasoning that refers to other than policy pages. I have experienced that, examples include Until the proposal gets past the draft stage and gets voted on, WT:ELE governs. (DCDuring), Using non-policies including Wiktionary:Citations and Wiktionary:References as an argument is rather unconvincing (Dan Polansky) —BoBoMisiu (talk) 00:15, 6 April 2015 (UTC)
You're correct, but this doesn't change the fact that WT:ELE only governs dictionary entries. It says nothing about how things that are not entries should be formatted. If you think this is a problem (I for one would agree; that's the general project that this entire thread is about), the solution should be to work on establishing further policy, not to attempt scavenging policy bits elsewhere that kind of apply if you squint right. (I.e. a non-policy that states "do things as if policy A was in effect here" remains a non-policy.) --Tropylium (talk) 22:42, 21 April 2015 (UTC)

Finding old deletion discussions, and related points[edit]

An attempt to create the entry "get behind" ([1]) leads to a page that says "You are recreating a page that was previously deleted" and then provides a log entry that reads "deleted page get behind (Failed RFD, RFDO; do not re-enter)".

1. How do I find the deletion reason/discussion? The link to "RFD" in the log entry just throws me into the current version of that page, which is useless long-term. Furthermore, the supposed RFD archive page ([2]) says that the archive is no longer active, but that "The current procedure is to archive the RFD discussion to the corresponding article's talk page". Er ... can anyone else spot the flaw in that procedure??

2. The explanation of "Failed RFD; do not re-enter" at [3] says "This term (in a particular language) failed WT:RFD. Do not re-enter it. You may re-enter a different term, especially in a different language." Suerly "Do not re-enter it" is too final? What if something previously rejected gains a valid meaning in the future? (I'm not suggesting this is the case for "get behind", but obviously it could happen.) Also "You may re-enter a different term, especially in a different language" is odd and pointless. 17:27, 2 April 2015 (UTC)

  • Subsequent to writing the above, I have discovered that the talk page http://en.wiktionary.org/wiki/Talk:get_behind exists even though the page "get behind" does not. I did not realise this was possible. Is this how it is generally supposed to work for deleted entries? This is unintuitive, and I propose to updated the documentation to explain it. However, what is the expected procedure for navigating to such a page? I found http://en.wiktionary.org/wiki/Talk:get_behind by first navigating to a known existing talk page and then changing the last part of the URL. Is this what users are expected to do, or is there a more friendly way?
You're right that we should have some message that the deletion debate is on the talk page, or should be eventually on the talk page. Attempts to create talk page archived by bot are underway. I completely agree that sometimes it's really hard to find deletion debates because of change in archive methods over the years, and sometimes debates are not archived anywhere. Renard Migrant (talk) 23:16, 2 April 2015 (UTC)
I made a couple of wording changes here and here. 23:40, 6 April 2015 (UTC)

Possibility of a "Sister projects" report in the Wikipedia Signpost[edit]

Hello, all I'm a volunteer at the Wikipedia Signpost, the Wikimedia movement's biggest internal newspaper. Almost all of our coverage focuses on Wikipedia, with occasional coverage of Commons, the Meta-Wiki, MediaWiki, Wikidata, the Wikimedia Labs; we have little to nothing to say about Wiktionary, Wikiquote, Wikibooks, Wikisource, Wikispecies, Wikinews, Wikiversity, or Wikivoyage. I'm interested in writing a special long-form "sister projects" report to try and address this shortfall. Is there anyone experienced in the Wikitionary project with whom I can speak with, perhaps over Skype, about the mission, organization, history, successes, troubles, and foibles of being a contributor to this project? If so, please drop me a line at my English Wikipedia talk page. Thanks! ResMar 21:04, 5 April 2015 (UTC)

No takers? :(. If not I will contact highly active editors individually a little later on. Resident Mario (talk) 04:14, 9 April 2015 (UTC)
There are probably not many active wikiversians :) --Auvajs (talk) 04:21, 9 April 2015 (UTC)
@Resident Mario Perhaps you might consider asking for them at Wikiversity instead? —Μετάknowledgediscuss/deeds 04:33, 9 April 2015 (UTC)
He is asking for representatives of all "sister projects" (including Wiktionary). I have responded on his WP talk page. bd2412 T 14:18, 9 April 2015 (UTC)
@Auvajs, Metaknowledge, BD2412 Apologies. This is a copy-paste error I made when I was sending out these messages do to not paying enough attention, I went back through my messages and had thought I fixed this error. As you can see I did that wrong, too. Mass messaging manually is a pain... Resident Mario (talk) 18:10, 9 April 2015 (UTC)

Creating a new RFVA section for 2015[edit]

I have archived a few RFV discussions at Wiktionary:Requests for verification archive/2015. I wonder why nobody bothered to archive from 2014? Hillcrest98 (talk) 14:47, 6 April 2015 (UTC)

We archive RFVs on talk pages now (e.g. Talk:azur). — Ungoliant (falai) 15:01, 6 April 2015 (UTC)
  • Read the top of WT:RFV. Only closed discussions can be archived. In case of doubt, check the common practice. I have emptied Wiktionary:Requests for verification archive/2015. --Dan Polansky (talk) 15:16, 6 April 2015 (UTC)
    • Typically a successful RfV will result in citations being placed on the questioned page, so there will not be any reason to RfV it again. bd2412 T 14:19, 9 April 2015 (UTC)

Entries for typos[edit]

Consider oredaceous; in hindsight it seems an obvious typo for predaceous, but not so obvious that one could deny its existence on first principles. It could well be an example of pretentious use of an obscure but defensible technical term. So, on encountering the term I checked in case

(1) it meant something that I should know but didn't or

(2) it was illegitimately intended to mean something that I knew, but could not assign a meaning to

(3) an error.

I did a bit of googling and concluded that

1) It was indeed a typo, but

2) That a few people had indeed adopted it in their published (not necessarily peer-reviewed) documents as (possibly) legitimately meaning something along the lines of:

"'Oredaceous' sounds like 'predaceous', Did you mean predaceous when searching for oredaceous? 1. (a) Living by or given to victimizing others for personal gain" as very reasonably appears in Dictiosaurus.com.

NOW THEREFORE I am not a frequent lexicographer, even in WK and have not yet fallen foul of typos here. Would it be correct or acceptable to create an entry for a completely redundant finger-trouble typo such as oredaceous, if only as a redirection to predaceous, or to put it into the predaceous entry as a common typo, or do we leave it to users to blunder and assume that WK doesn't have such hard words, so it must be a very special term of great value to impress readers? JonRichfield (talk) 16:00, 9 April 2015 (UTC)

It does fit the general principle of WT:CFI: "A term should be included if it's likely that someone would run across it and want to know what it means." I think that including "likely" is inappropriate there, because we do include very rare terms that the average person is very unlikely to ever come across. That would certainly include a rare typo, which would nonetheless have readers baffled. If a word is a typo, we can't necessarily expect the reader to know what the correct word is. At the same time, it would be a rather insane task to start documenting all attested typos.
I think the best we can do is to make more of an effort to get the search function improved so that it recognises typos better. Right now it does not give any results for "oredaceous" even though it's only one (!) character away from predaceous, an existing entry. The fact that the search does not catch this is clearly a failing on its part and definitely needs improving.
However, it's also possible in other cases that a word is a typo in one language but a legitimate spelling in another language. Our search will then happily send the user to the entry for that other language, but the user will not find an entry there for the language they are looking for. They might think that Wiktionary is incomplete. —CodeCat 16:11, 9 April 2015 (UTC)
It also says in that sentence 'term'. Is a typo a 'term'? Surely not. I say we exclude them all together. All words in all languages does not mean all strings of characters in all languages. Renard Migrant (talk) 17:05, 9 April 2015 (UTC)
You're looking at it from a principled point of view. But a dictionary exists for a purpose; our purpose is to help our readers find lexicographical information that they are looking for. People will be looking for typos, so we have to help them find what they need, too. Just saying "sucks for you that the writer of the text you are reading made a mistake, too bad" doesn't get anyone anywhere. —CodeCat 17:09, 9 April 2015 (UTC)
I am adding to entries about the words Sophy, Sofie, Sofee, Soffi, Sofi, Sophi, Sophia, Sophie, etc. After several weeks, I still don't know at what point those words, which regularly described at least two senses, stop being spelling mistakes (or if they were in the first place) in over four centuries of attested usage and become {{alternate spelling of|Sophy}} and {{alternate spelling of|Sufi}}, the two more common contemporary terms.
My point about oredaceous, which is a different type of case, is that a reader could also not know if the search term is a spelling mistake, but the wiktionary search results page provides a link to "try searching the site using Google" which provides alternative wiktionary entries for the reader. Which, in my opinion, is adequate for just typos. Nevertheless, character recognition software also provide erroneous results, for example, oredaceous instead of the correctly written predaceous that the search engine then uses, and the reader still needs to interpret what is being presented. —BoBoMisiu (talk) 18:50, 9 April 2015 (UTC)
I think the way to deal with typos is using the search engine to suggest similar entries based on spelling. Not having entries. That's dubious as you have to start making assumptions about what word is intended. Renard Migrant (talk) 19:01, 9 April 2015 (UTC)
  • Isn't this something that software even better than our search engine should do? I could imagine approximate searching for each language based on whether something was heard (using a descendant of soundex), read from a scanned print document, read from an a keyboarded document, read from a manuscript, all with the possibility of specifying date of the document and of any transformations and script and typeface. I really don't see that we are helping much with the paltry few errors we would have entered in a year or two if we were to go down this path. DCDuring TALK
  • Slightly off topic but on topic as per subject title: Now as before, I see zero added value for the user of the dictionary in our excluding attested high-frequency typos. Therefore, I oppose removal of high-frequency typos. Some people seem to distinguish misspellings from typos; for misspellings, we have a voted on policy in WT:CFI#Spellings. If misspelling is understood to include typo as a subclass or more specific case, our present policy excludes rare attested typos but not common, high-frequency attested typos. Let me remind all newbie readers that Wiktionary includes common misspellings as misspellings (declaring them as such) so as to not mislead the reader, e.g. in concieve. --Dan Polansky (talk) 19:13, 9 April 2015 (UTC)
I agree with Dan Polansky that misspelled words should not be excluded, and I agree with Renard Migrant that the search engine is the better way to provided suggestions, and I agree with DCDuring that, especially for terms like oredaceous, other software does a better job. The wiktionary search results page has the suggestion to contribute something that is not found in wiktionary. These are complementary processes. I don't think oredaceous is a misspelled word since I think it, oredaceous, does not involve people. I think it is a recognition software error that was scraped by other sites and will eventually correct itself, its ephemeral without usage outside the error and scrapings. —BoBoMisiu (talk) 20:09, 9 April 2015 (UTC)
With the prevalence of bad OCR in search engine databases, there are tons of scannos with "cl"="d", "1"="l"="!","o"="e"="a", "u"="n"="ii", etc., and web pages are stiff with transposed and/or missing letters, doubling of the wrong letters, etc. These are often amply attested, but utterly useless as entries.
I think the best solution would be a list of non-wikilinked examples of common typos and/or scannos for a term on the page for the term, but hidden. That way the page would show up in search results, but there would be little visual clutter or use of resources, and fewer clicks to get to the right pages.
I suppose we could put the list in a collapsible box, or we could wrap it in a template that would make it completely invisible, like the keywords you often find in html header sections. Chuck Entz (talk) 02:11, 10 April 2015 (UTC)
@Chuck Entz: Can you give an example of an attested, high-frequency scanno? To me, it seems like an unlikely occurrence. As for oredaceous, is it attested? Like, we don't count a scan showing a scanno as an attestation since what a human says about what they see in the scan prevails over what the scanning algorithm sees. As frequency ratio, "oredaceous" does not show in GNV at all, so is not a common typo/scanno by any stretch, and shall be excluded per WT:CFI#Spellings: oredaceous, predaceous at Google Ngram Viewer. --Dan Polansky (talk) 05:01, 10 April 2015 (UTC)
Sorry- I didn't think that all the way through. No, the durably-archived part doesn't include the OCR, so scannos generally aren't attested per CFI. Still, if someone uses the clipping tool in Google Books, they get the OCR, rather than the visible text, and there are sources such as Project Gutenberg and the Germanic Lexicon Project which have OCRed texts in various stages of proofreading. The lack of CFI-compliant attestation is all the more reason to avoid making entries, but the possibility that people will use them in searches is reason to have them present in some form. Chuck Entz (talk) 19:57, 10 April 2015 (UTC)

Well, I hadn't intended to start so much reaction; my apologies. My own feelings are in tune with those such as CodeCa but I am not inclined to agitate for any major change of policy. At Finedictionary I found that they give lists of possible typos (apparently not necessarily known to have occurred) for their entries. Something along those lines had occurred to me, but I had rejected it as perhaps a bit over the top. Also I am not sure how well it would work in practice. It seems likely that such a feature would give nearly every entry such a long tail of "Containing..." entries that it might render the "Containing..." feature almost unusable. OTOH, I certainly would militate against creating headwords for every misspelling or typo. Bottom line... I probably must resign myself to the fact that noise happens and that sometimes one simply must be resigned to sacrifice an hour to guarding against accidents and illiterisms. Thanks everyone for your contributions. JonRichfield (talk) 12:14, 10 April 2015 (UTC)

  • I would oppose having entries for typos that are not actual instances of the writer mistakenly thinking this was the correct spelling of the word. bd2412 T 20:22, 10 April 2015 (UTC)
  • Same. Suggesting correct spellings is something for a search-engine heuristic, not something to be manually entered, IMO. We have enough work to do on improving the actual content. Equinox 21:29, 10 April 2015 (UTC)
    What about typos that are adopted as real spellings, like pwn for own, teh for the or kik for lol? —CodeCat 22:28, 10 April 2015 (UTC)
    They're words pure and simple, what in your opinion needs discussing? Renard Migrant (talk) 22:32, 10 April 2015 (UTC)
    Well, once they're adopted as real spellings, they are no longer typos, and become dictionary material. Equinox 22:40, 10 April 2015 (UTC)
    The difficulty would be in distinguishing these cases. For example, what if there are four attestations of one of these, but we can't tell which ones were intended (and thus meet CFI) and which were accidental? Depending on how we decide, it might meet CFI or it might not. —CodeCat 22:43, 10 April 2015 (UTC)

Stewards confirmation rules[edit]

Hello, I made a proposal on Meta to change the rules for the steward confirmations. Currently consensus to remove is required for a steward to lose his status, however I think it's fairer to the community if every steward needed the consensus to keep. As this is an issue that affects all WMF wikis, I'm sending this notification to let people know & be able to participate. Best regards, --MF-W 16:12, 10 April 2015 (UTC)

Excessive Footnoting in Etymologies[edit]

I'm posting this as separate from Tropylium's topic, above, because it's a separate issue and it would have overwhelmed the discussion there.

In the etymology for Sophy, User:BoBoMisiu has, by my count, 23 citations to 8 references in 8 places. This is nuts!

The first two references cover everything that would be needed to verify the accuracy of the etymology (maybe a third to verify the statement that it's not related to Sufi), and there's no need to cite the same source multiple times in the same etymology. I really don't care what dictionary was used to supply the Persian spellings used to replace the transliterations in one of the sources, nor do I care where the glosses for those terms came from. The other references might be useful for an encyclopedia article, but in an etymology, they're just clutter.

I don't know whether they want to show off their erudition, or they're afraid they're going to get audited by the dictionary police, but, as far as I'm concerned, this referencing style adds nothing to the dictionary that's worth the massive clutter.

What does everyone else think? Chuck Entz (talk) 22:23, 10 April 2015 (UTC)

The etymology is constructed but I can't read Turkish or Arabic to complete it, or for that matter to decide what could be eliminated in the chain of assertions. Not all sources show the same thing. —BoBoMisiu (talk) 22:26, 10 April 2015 (UTC)
The word that comes to mind is dim. The same citations are repeated within words of each other. Just stick 'em at the bottom like everyone else does. You can read the whole entry without scrolling anyway. And not that many anyway, five links saying the same thing aren't better than one, unless the one is unreliable. How many of your links do you consider to be unreliable? Renard Migrant (talk) 22:31, 10 April 2015 (UTC)
So your suggestion is to leave out the Turkish? Or not show that the Turkish is found in one English language source? I consider all the sources reliable, yet I don't know how the Turkish fits in; I did the work and a future editor, who has insight into the Turkish and Arabic, will not have to repeat the research for each step in the chain of assertions. Both of your suggestions are to limit the content – my suggestion is to give the reader more control. Like I wrote above (diff), seeing reference numbers should be a user preference for those who prefer not to see those brutish superscript numbers, it is a simple style sheet solution. The references section, in my opinion, should be collapsed by default, as should the etymology section and pronunciation section. —BoBoMisiu (talk) 23:34, 10 April 2015 (UTC)
  • I generally agree with the above by Chuck Entz: clutter with little added value. To my dismay, I have now realized that I am to blame in part since it was me who started using the ref technique in Sophy in diff; I even said in the edit summary that "it would be better to have a reference per individual etyological claim". As far as I am concerned, the ref technique can be abandoned in Sophy, and the number of references to be placed at the end of the entry can be reduced to the minimum needed to cover the information presented. I am still of the opinion that providing references in edit summaries is a useful practice that provides tracing to them without cluttering the entry. I admit that the detailed style of referencing currently used in Sophy would be useful to source claims that really matter; I don't think etymology matters so much to be worth the clutter. --Dan Polansky (talk) 06:28, 11 April 2015 (UTC)
Why aren't any of you addressing the differences between the three things that are commonly seen as different:
  1. the the structure of a entry
  2. the content of an entry
  3. the presentation of an entry
The concept is "separating presentation from content and structure" (search on DuckDuckGo), you are all discussing how to solve an aesthetic preference, which is the presentation, by altering the content instead of the presentation. "Clutter" is a aspect of presentation and not an aspect of content or structure. Removing content is not a solution for a presentation preference; adding a user preference toggle (set by style="visibility:hidden" for the tag) to control the visibility of the superscript reference numbers is a solution for a presentation preference. I believe none of you have any information about the readers preferences about this other than your own opinions. The comment that "I don't think etymology matters so much to be worth the clutter" shows the misunderstanding caused by conflating issues of content, presentation, and structure.
As far as etymology, it is not a definition that a contributor crafts. It is usually based on expert, or at least informed, opinion which is someone's work and should fully cited. —BoBoMisiu (talk) 16:30, 11 April 2015 (UTC)
References in this context aren't content themselves, they're there to support the actual content. Most of your references are useless in this context, so the discussion about clutter is to show that the unnecessary references aren't harmless filler that can be ignored, but actually harmful to the entry. Yes, you could probably find ways to make it less conspicuous, but you haven't really justified their presence in the first place. As for your last point: an etymology actually is something the editor crafts. Yes, it's based on expert opinions, but you don't need to reference every part of crafting the definition. Like I said, the first two sources cover the task of verifying the etymology just fine. Details like providing glosses and converting transliterations to the actual terms in the original scripts aren't the kind of thing that you need to reference- editors who know the languages in question often do that without consulting any sources at all. Yes, it's a good idea to be sure you know what you're talking about, and that might require consulting various sources- but that's for your benefit, not for everyone who reads or edits the entry in the future. Also, an etymology isn't like an article, where a point that needs referencing is separated by paragraphs of text from other places where the same reference is used. If a source supports multiple parts of the etymology, you only need to have one reference to the source, which can go at the end of the etymology. It's only when a reference narrowly deals with only one part of the etymology that you would put the reference inline in the middle of the etymology. Chuck Entz (talk) 17:53, 11 April 2015 (UTC)
@Chuck Entz: References are content. They are part of providing the curated selection of details about the subject of the entry, as are the selections of quotes used to attest usage. References are a selection of further reading directly connected to other parts of content. Selected external links are content for the same reason. All these things provide a user with content – that contributors compile and curate – that is insightful. I use a giant late 1960s dictionary as my go-to reference because I believe it provides me with reliable information about things – not just words – that I want to know about. It is reliable because it was fact checked. I use OED online for the same reason. Wiktionary is different because the content contributors add into etymologies or usage notes without high quality sources does not reach the same standard. I have seen many poor etymologies that lack credibility, and – of course – lack references. While Chuck Entz believes references are not for everyone who reads or edits the entry in the future, I believe that anyone repurposing a fully referenced assertion does benefit by using reliable content and not spreading unvetted worthless bullshit like in the Chinese whispers game. I am not one of the editors who know the languages in question often do that without consulting any sources at all. I can reasonably assume that few contributors read Farsi, Turkish, or Arabic, providing a reference about something that uses a different script, that most readers cannot comprehend, demonstrates the reliability of the assertion. Including the original language term allows a reader to cut that term and paste into a search engine. The reliability of each assertion (just a few words) in a chain of assertions demonstrates the reliability of the chain. To say that I haven't really justified their presence in the first place is just assuming that a reader who visits wiktionary is the kind of reader who doesn't want to know more about the minutia of an etymology, and the kind of reader who doesn't want to know what is factually accurate through reliable references. I don't assume that. Please explain to me how those references are actually harmful to the entry, other than a personal aesthetic. —BoBoMisiu (talk) 13:13, 14 April 2015 (UTC)
I would shorten here the following points:
  1. No reference needs to be provided for the Italian and Spanish words; references for their origin should be located on their entries (although since they do not exist yet, I can understand for the time being leaving the referencing on the English entry). It's not obvious whether they need to be mentioned at all.
  2. It's unclear to me why is صفوی (ṣafawī) mentioned; the existence of this does not seem to be relevant to the etymology of the English term, which appears to be straight from ṣafī. (If there is some relevance — e.g. if Persian ṣafī is actually a back-formation from ṣafawi — this should be mentioned explicitly.)
  3. General sources, here the Century Dictionary, the OED, and perhaps Skeat's etymological dictionary, seem to provide nothing that the more specialized sources do not, and they could probably be safely cut away from the entry. References exist for the purposes of showing where a claim originates, not for showing who else has read the same source material.
--Tropylium (talk) 23:02, 21 April 2015 (UTC)

Trimming CFI slightly[edit]

I wanted to suggest a minor trim to WT:Criteria for Inclusion#Constructed languages, where it says:

That's true, but as it says above, any constructed language without consensus to be included is by default not included in the main namespace. There's no reason to list these in particular, and in fact the list is very arbitrary and the choice of mentioning these specific constructed languages makes it appear that we are giving them special weight or something. So it seems reasonable to delete that bullet point and thus make the section slightly simpler. Thoughts? —Μετάknowledgediscuss/deeds 01:05, 13 April 2015 (UTC)

I support that, but I would actually support a broader rule that disallows terms in languages that have not been passed between generations at least x times. That would exclude "new" conlangs. It's kind of like the "spanning at least a year" rule but for whole languages. —CodeCat 01:21, 13 April 2015 (UTC)
Maybe you misunderstood; I'm not proposing any change to policy, just a removal of redundancy in the CFI. —Μετάknowledgediscuss/deeds 02:01, 13 April 2015 (UTC)
@Metaknowledge: For what it's worth, listing the most common conlangs which are likely to be readded (such as Toki Pona) is probably helpful as it will provide documentation here saying that it's not accepted. Plenty of editors will see documentation here before checking an external list. —Justin (koavf)TCM 03:21, 13 April 2015 (UTC)
It would also exclude pidgins and creoles though. -- Liliana 23:21, 13 April 2015 (UTC)

Anybody should be allowed to nominate people for whitelist[edit]

At present, nominations for the whitelist are supposed to be only done by administrators. That seems:

  1. excessive (why should we need so many hoops to jump through with whitelist? It's harder to be whitelisted here than many other projects; to say nothing of the fact that many projects don't even bother with whitelisting)
  2. unfair (it grants too much power to sysops and not enough power to Joe users), andd
  3. time-consuming (it'd be so much easier for people to self-nom).

I am seriously considering starting a vote about this matter, but I thought I'd discuss it here first. Purplebackpack89 17:43, 13 April 2015 (UTC)

support. But with one little correction: not for anybody but for only autopatrolled users.Dixtosa (talk) 17:51, 13 April 2015 (UTC)
I think the logic behind having only admins nominate people is that admins are the only(?*) people affected by the whitelisting vs non-whitelisting of a user, since admins are the ones who have access to the "patrol" feature. (*Are there any edits Joe User could make if he were whitelisted that he couldn't make if he weren't whitelisted?) If we do expand the nomination franchise, I support the restriction that Dixtosa seems to be proposing, that nominations have to be made by a user who is already autopatrolled (this also prevents self-noms). - -sche (discuss) 18:16, 13 April 2015 (UTC)
@-sche What's so inherently bad about self-noms, though? I have major problems with restricting nominating people to the whitelist to people who are already on the whitelist. This is an open community and groups should be open to everybody, not selected only by people who are already in those groups. Plus, there's the issue that sysops or whitelisters have to actively be looking around for people to whitelist, rather than potential whitelist candidates coming to us. FWIW, I also think the claim that admins are the only people affected is a stretch, as it defines "affected" pretty narrowly. At the very least, "affected" should include non-admins who are on the whitelist. Purplebackpack89 18:35, 13 April 2015 (UTC)
I think you're under some misapprehension that whitelisting is a special right or privilege. It isn't. It's just a way we patrollers (who are almost exclusively admins) ease the load of checking every edit, and it really doesn't affect the editor in question. I suspect that this is just related to your issues with the establishment and your own personal lack of power against people you annoy. —Μετάknowledgediscuss/deeds 19:54, 13 April 2015 (UTC)
If whitelisting isn't a special right or privilege, why did another editor fight to try and take it away from me? And why are you assuming that I'm doing this solely because I don't like getting kicked around by bullying admins (like the guy who tried in vain to take away my whitelist rights)? And why hasn't anybody given a good reason on why self-nom should continue to be forbidden? Self-nom doesn't mean you automatically get it. Purplebackpack89 20:18, 13 April 2015 (UTC)
"If whitelisting isn't a special right or privilege, why did another editor fight to try and take it away from me?" One could equally ask, if whitelisting isn't a special right or privilege, why are you fighting over its rules? Equinox 22:25, 13 April 2015 (UTC)
I think you're confused, @Equinox. I'm the one suggesting it is a right or privilege. Metaknowledge is the one arguing that's a near-meaningless distinction. Purplebackpack89 22:37, 13 April 2015 (UTC)
I don't see a problem with anyone nominating editors for whitelisting, but approval for whitelisting has to be left to admins. In my experience, the people who need patrolling the most are the people who think their edits are perfect, in spite of massive evidence to the contrary. Usually such people are easily able to find others of similar temperament who are only too happy to support them. Please note that I'm not talking about you, but there are people who pop up from time to time, such as Gtroy/Luciferwildcat, Drago, and many, many others who would all have liked to have no one checking their edits so they wouldn't have people pointing out what they were doing wrong. Chuck Entz (talk) 01:26, 14 April 2015 (UTC)
Likewise, I don't have any problem with admins approving people for the whitelist, so long as anybody is allowed to nominate for it. Purplebackpack89 02:06, 14 April 2015 (UTC)
I have no objection to anyone nominating a user to be whitelisted but, really, why would they bother? It only affects the small subset of sysops who patrol Recent Changes. SemperBlotto (talk) 13:00, 14 April 2015 (UTC)
We don't really have any patrolers who aren't admins here. That's why it's on admins who can nominate and approve, as it only affects admins (since there are no other patrolers). I have no objection to changing that, I self-nominated on the Beer Parlour as a roll-backer and patroler, but nobody replied whatsoever. Renard Migrant (talk) 18:28, 14 April 2015 (UTC)
Hardly surprising. patroler / patroller?

Detailed linguistic maps[edit]

If they're of interest to anyone, I just stumbled onto this set of very detailed linguistic maps. - -sche (discuss) 21:28, 17 April 2015 (UTC)

A new language code needed[edit]

for Proto-Georgian-Zan. @Simboyd said the reason on my talk page. --Dixtosa (talk) 15:55, 18 April 2015 (UTC)

Ruakh requesting de-bureaucrating.[edit]

Given my activity level here, I don't think it makes sense for me to still be a bureaucrat — I'm never the first bureaucrat to respond to something, and nothing ever needs multiple bureaucrats — but I figured I should check in with the community before actually posting at [[m:Steward requests/Permissions]] to request that my access be removed, just so y'all don't feel blindsided or anything. (Note: SemperBlotto, Stephen G. Brown, and Hippietrail are all quite active at the moment, so I don't think I need to wait for a replacement to be appointed, or anything like that.) —RuakhTALK 03:29, 19 April 2015 (UTC)

@Ruakh: Trust once granted does not disappear with inactivity, I think. To the contrary, it is certain type of activity that leads to trust diminished or disappearing, such activity that would show trust was misplaced. It is only activity that can produce refuting instances against trust, not inactivity. I do not oppose or put obstacles to your self-nomination for de-bureaucrating; I merely present an alternative view that may lead you to reconsider. ---Dan Polansky (talk) 07:11, 19 April 2015 (UTC)
You still seem fairly active; doesn't look like a security risk; you might as well keep it. Equinox 04:39, 20 April 2015 (UTC)
Hmm. Well, OK. I guess it doesn't really matter one way or the other. —RuakhTALK 06:31, 21 April 2015 (UTC)
  • Weak oppose If we take away your tools, there's a pretty long list of other people who should lose tools, and not just for inactivity. Purplebackpack89 17:09, 20 April 2015 (UTC)

"Alt form of" caps[edit]

Did I dream it, or did "alternative form of..." use to begin with a capital A? Why was this changed? Equinox 04:39, 20 April 2015 (UTC)

It's a result of diff. You're not the first person to wonder why it was changed. I've undone the change. - -sche (discuss) 17:44, 20 April 2015 (UTC)
Thanks Equinox for this thread; thanks -sche for restoring the capital A; please keep it restored. --Dan Polansky (talk) 19:20, 20 April 2015 (UTC)
I actually preferred it with a small "a". You're never going to please everybody, no matter what you do. Donnanz (talk) 08:28, 21 April 2015 (UTC)
True enough. I don't mind either way, but I don't like arbitrary changes: they've ruined enough of my favourite Web sites already, usually because of idiot marketing departments, or a misguided idea that mobile phones are the primary target and computers are secondary. Get off my lawn. Equinox 02:09, 22 April 2015 (UTC)
There's been a lot of this going on. It's why I use nodot=1 and nocap=1 even in form of templates that don't have automatic dots or capital letters; because they're constantly being changed and the chance of such templates having an automatic dot, cap or both in the future is very, very high. Renard Migrant (talk) 08:42, 22 April 2015 (UTC)
nocap=1 is a useful tip. I have started using it. Donnanz (talk) 12:43, 26 April 2015 (UTC)
That came about after I requested it some time ago. It was because our form-of templates are horribly inconsistent. Should we have a vote to decide, once and for all, whether to start them with a capital or lowercase letter across the board? This, that and the other (talk) 08:46, 23 April 2015 (UTC)
I would support that, as it would be a non-foolish consistency. I would also support capitalizing the first word of definitions consistently throughout the project. bd2412 T 12:45, 23 April 2015 (UTC)
Me too.
@BD2412: Do you include definitions only in English, in Translingual, in all languages in your initial capitalization support? I do. DCDuring TALK 13:15, 23 April 2015 (UTC)
I would apply this only to (multi-word) English definitions. I view such a definition as a sentence answering the implied question, "what does foo mean". Translations are a bit different, since they ideally require only the single English word that corresponds to the foreign word, and we should avoid giving the impression that the word must be capitalized when written in English (unless, of course, it is a word that should be capitalized in English, like English or January). bd2412 T 13:21, 23 April 2015 (UTC)
What should be done for English terms that are just synonyms of another term? And what about non-English terms that require full definitions because there is no simple English equivalent? And what if a single entry contains a mix of different types, do we capitalise some definitions but not others? —CodeCat 13:29, 23 April 2015 (UTC)
If we decide to (continue to) capitalize English and non-English definitions and translations differently, we have the option of making the form-of templates use a capital+dot or not based on what lang= is set to (or we could make their display be language-independent). If we decide the templates should end with a dot, they should allow nodot=1 to suppress that dot in case additional information needs to be added manually after the template (see e.g. Karman street).
I capitalize English definitions, and don't capitalize non-English translations.
We could set up a vote with three sections, (1) English, (2) Translingual and (3) other languages, and have options under each like (a) always begin with an uppercase letter and end with a dot,* (b) never begin with an uppercase letter or end with a dot,* (c) begin with an uppercase letter and end with a dot if ___, otherwise do not. We could even have an option (d) make no formal rule. (*With exceptions for, pardon the tautology, exceptional circumstances, like it we for some unforeseen reason must begin a definition with "iPhone" or "isiZulu", or with "January" or "Chile", respectively.) - -sche (discuss) 21:27, 23 April 2015 (UTC)
I'd like everything in cap-dot format (as I call it). I have no strong feelings though. Renard Migrant (talk) 21:34, 23 April 2015 (UTC)
  • Alt form and any other high-profile template should be supported in both capital and lowercase forms, for ease of editing. Purplebackpack89 20:55, 24 April 2015 (UTC)
Yes, totally agree, though I think the question here is the flip-flopping on the default settings. These seem to change every few months. Perhaps even every few weeks. Renard Migrant (talk) 15:34, 26 April 2015 (UTC)

Cross-referencing etymological root words to their descendants[edit]

Has there been any past discussion or efforts to make root words consistently link to words which mention them in their etymology? —This unsigned comment was added by Technical-tiresias (talkcontribs).

Sounds like you're looking either for "What links here" or for the descendant/derivative lists. The latter are obviously works in progress, and I've no idea how well they're up to date.
I'd certainly endorse adding a clause in our etymology guidelines that when adding an etymology for a word, one should also check for a backlink at the parent word.
(Also, I'd love having a software framework that did this automatically, but that is probably beyond what can be reasonably done on Wiktionary.)
--Tropylium (talk) 23:15, 21 April 2015 (UTC)

Nominations are being accepted for 2015 Wikimedia Foundation elections[edit]

This is a message from the 2015 Wikimedia Foundation Elections Committee. Translations are available.

Wmf logo vert pms.svg


I am pleased to announce that nominations are now being accepted for the 2015 Wikimedia Foundation Elections. This year the Board and the FDC Staff are looking for a diverse set of candidates from regions and projects that are traditionally under-represented on the board and in the movement as well as candidates with experience in technology, product or finance. To this end they have published letters describing what they think is needed and, recognizing that those who know the community the best are the community themselves, the election committee is accepting nominations for community members you think should run and will reach out to those nominated to provide them with information about the job and the election process.

This year, elections are being held for the following roles:

Board of Trustees
The Board of Trustees is the decision-making body that is ultimately responsible for the long term sustainability of the Foundation, so we value wide input into its selection. There are three positions being filled. More information about this role can be found at the board elections page.

Funds Dissemination Committee (FDC)
The Funds Dissemination Committee (FDC) makes recommendations about how to allocate Wikimedia movement funds to eligible entities. There are five positions being filled. More information about this role can be found at the FDC elections page.

Funds Dissemination Committee (FDC) Ombud
The FDC Ombud receives complaints and feedback about the FDC process, investigates complaints at the request of the Board of Trustees, and summarizes the investigations and feedback for the Board of Trustees on an annual basis. One position is being filled. More information about this role can be found at the FDC Ombudsperson elections page.

The candidacy submission phase lasts from 00:00 UTC April 20 to 23:59 UTC May 5 for the Board and from 00:00 UTCApril 20 to 23:59 UTC April 30 for the FDC and FDC Ombudsperson. This year, we are accepting both self-nominations and nominations of others. More information on this election and the nomination process can be found on the 2015 Wikimedia elections page on Meta-Wiki.

Please feel free to post a note about the election on your project's village pump. Any questions related to the election can be posted on the talk page on Meta, or sent to the election committee's mailing list, board-elections -at- wikimedia.org

On behalf of the Elections Committee,
-Gregory Varnum (User:Varnent)
Coordinator, 2015 Wikimedia Foundation Elections Committee

Posted by the MediaWiki message delivery on behalf of the 2015 Wikimedia Foundation Elections Committee, 05:03, 21 April 2015 (UTC) • TranslateGet help

"Adverbial forms" and cases of adverbs in Finnish[edit]

Including these in declension tables seems like a bad idea. The entire point of declension tables is to provide those wordforms related to the lemma that are generally predictable; not to list non-productive derivational items.

Some more detailed examples of problems:

  • ulkona is in no way an essive. It shares the ending -na, yes, but in its older locative sense (same as kotona or siinä).
  • ulko- is a prefix, not a nominative, despite both consisting of the unmarked word root.
  • yhä is not productively linked to yksi at all, and would be best treated as a derivative.

I get the impression that many of these categories ("situative", "oppositive") are original research, sort of. Is anyone else particularly attacted to them, or shall I add them to my mental checklist of items to clean up at some point? --Tropylium (talk) 23:29, 21 April 2015 (UTC)

While I agree that these are not inflections, there is value in showing certain sets of derivations in a schematic way. So maybe a separate table would be preferable. —CodeCat 23:36, 21 April 2015 (UTC)
A tabulative approach is informative, sure enough, but aside from relocation to derivatives it would need consideration on what to include. By comparison for base verbs: we could consider listing some of the more common categories, such as — the following based on hypätä (to jump) — inchoative (hypähtää), frequentative (hypellä) habitual (hyppiä), and reflexive (none for this, but e.g. kaataakaatua), as well as the name-of-action noun (which is somewhat non-predictable: hypätähyppy, hypähtäähypähdys, hypellähyppely, kaataakaato). The stacking of these gets complicated fast though (kaatua → habitual/frequentative kaatuilla → causative kaatuiluttaa → frequentative kaatuilutella → name-of-action kaatuiluttelu → …) so here we can easily see that trying to shoehorn every derivative into a single table would not be feasible. --Tropylium (talk) 00:58, 22 April 2015 (UTC)
We wouldn't have to show derivatives of derivatives, only immediate ones. —CodeCat 01:37, 22 April 2015 (UTC)

Phrasebook entries to get their own namespace[edit]

Wiktionary:Requests for deletion#I'm pregnant has raised some interesting points. Perhaps to have a phrasebook, we should have a phrasebook namespace. That way you bypass WT:CFI and WT:ELE which are for the main namespace (albeit it doesn't explicitly say that). I also don't think they need to be searchable in the main namespace because they're not the sort of things people would search for. Renard Migrant (talk) 17:39, 27 April 2015 (UTC)

Support. I also think that reconstructions should have their own namespace. —CodeCat 17:52, 27 April 2015 (UTC)
Support both. And if it possible to make Special:Search search in a particular namespace along with the main one then we can include Phrasebook namespace by default.--Dixtosa (talk) 18:59, 27 April 2015 (UTC)
  • Oppose. This would create inconvenience for the user with no added value whatsoever; I find searching for I'm hungry perfectly natural, and it can be found by Google anyway. It is a solution in search for a problem. Category:English phrasebook has mere 345 entries; the mainspace is not overcrowded with phrasebook entries. --Dan Polansky (talk) 20:09, 27 April 2015 (UTC)
    Later: Let me also point out that we have other sentences than the phrasebook ones, including those in Category:English proverbs, which has 624 entries. Any creation of a separate namespace needs to be based on a deep, separate need, leading to a significant number of expected entries in that dedicated namespace. --Dan Polansky (talk) 20:16, 27 April 2015 (UTC)
  • I'm inclined to Oppose for the same reasons as Dan. I'd prefer adding something to CFI about what makes an acceptable phrasebook entry; the {{phrasebook}} tag is enough to distinguish phrasebook entries from other entries, implying "This entry may be intentionally SOP". —Aɴɢʀ (talk) 20:14, 27 April 2015 (UTC)
I don't like the phrasebook as currently implemented (it's arbitrary and disorganised) but I disagree: people probably would search for these phrases, and if we do categorise them, we'd probably do it with wiki categories and not by shifting them into another namespace. I would however at least like some kind of option for "expert users" to hide away the phrasebook stuff. Equinox 22:42, 27 April 2015 (UTC)

Categories for terms in a language derived from a particular PIE root[edit]

I've been thinking that it might be nice to have categories like this, such as Category:English terms derived from the Proto-Indo-European root *sed-, which would contain sit, seat, settle, sessile and many more. It would be very nice for people looking for cognates. I don't think there would be any opposition to this, and I was thinking of just implementing it on a small scale, but there are a few points that would need to be worked out first.

  1. Not all terms with their origin in PIE actually have a root. In particular, there are quite a few nouns for which the root is essentially unknown and uncreconstructable, like *wĺ̥kʷos. It would be possible to say that there is a root that just happens to exist only in this word. However, that doesn't tell us anything about the shape of the root; both *wlekʷ- and *welkʷ- are valid roots, and both become *wl̥kʷ- in zero grade. So there needs to be a way to account for such cases.
  2. We would need a new template for this, such as {{PIE root}}. We can't add it to any existing etymology templates, because for many terms we don't have any PIE etymology. For example, we don't show a PIE root for sitter, and I think it should stay that way. But we would still want it to appear in the aforementioned category. So the template to be created would have to only categorise, or maybe show a small box at most.

CodeCat 18:24, 27 April 2015 (UTC)

Shouldn't all English words derived from *sed- ideally be listed under Descendants at *sed-? —Aɴɢʀ (talk) 19:47, 27 April 2015 (UTC)
That would get rather crazy very quickly, when you consider all languages and all their derivatives. —CodeCat 20:03, 27 April 2015 (UTC)
Well, maybe so. Also, some words wouldn't be right on *sed- at all but somewhere else like *sitjaną. As for cases like sitter, they could have the category added directly without any template at all. —Aɴɢʀ (talk) 20:17, 27 April 2015 (UTC)
This sounds more like a project for the Appendix namespace than an especially useful or consistently enforceable categorization scheme. --Tropylium (talk) 23:46, 7 May 2015 (UTC)

Why aren’t inactives desysopped?[edit]

I’ve gotten the impression that administrators, after years of very little to no activity, get their special privileges subtracted. But there are several members of the personnel who haven’t touched the project in years, and their accounts are still administrative. Can somebody explain to me why these accounts are still administrative? Have we simply not gotten around to desysopping them? --Romanophile (talk) 04:51, 28 April 2015 (UTC)

There's no policy in place to provide for that. Perhaps there should be. —Μετάknowledgediscuss/deeds 05:17, 28 April 2015 (UTC)
We don't routine desysops inactive admins, we do it sporadically by vote. Since inactive admins don't hurt the project in any way, editors aren't very keen on it. Desysopsing them doesn't add anything positive to the project either. You'd be hard-pushed to get that policy through, for that reason. Renard Migrant (talk) 15:19, 29 April 2015 (UTC)
However, it's bad security policy to have unused elevated accounts, since it increases the site's surface area for an attacker. Equinox 15:30, 29 April 2015 (UTC)
The security issue is mostly a red herring; sysops don't have any permissions which can do lasting damage, and inactive sysops would be the least likely vectors (as they aren't likely to have their password phished or be subject to an XSS attack etc.). - TheDaveRoss 16:47, 29 April 2015 (UTC)
Also, people looking at Wiktionary:Administrators will think we have lots of active admins (far more than we actually have). They might also ask inactive admins to do something (revert vandalism etc) and be surprised when nothing happens. So I'm in favour of desysopping. SemperBlotto (talk) 15:35, 29 April 2015 (UTC)
What's your threshold for inactivity, Semper? Purplebackpack89 16:13, 29 April 2015 (UTC)
I generally agree that long-inactive sysops (a few years of no more than token activity) should lose the bit, at least until they come back and edit enough to show a need for it. bd2412 T 02:15, 30 April 2015 (UTC)

May 2015

Wikimedia Foundation Funds Dissemination Committee elections 2015[edit]

Wikimedia Foundation RGB logo with text.svg

This is a message from the 2015 Wikimedia Foundation Elections Committee. Translations are available.

Voting has begun for eligible voters in the 2015 elections for the Funds Dissemination Committee (FDC) and FDC Ombudsperson. Questions and discussion with the candidates for the Funds Dissemination Committee (FDC) and FDC Ombudsperson will continue during the voting. Nominations for the Board of Trustees will be accepted until 23:59 UTC May 5.

The Funds Dissemination Committee (FDC) makes recommendations about how to allocate Wikimedia movement funds to eligible entities. There are five positions on the committee being filled.

The FDC Ombudsperson receives complaints and feedback about the FDC process, investigates complaints at the request of the Board of Trustees, and summarizes the investigations and feedback for the Board of Trustees on an annual basis. One position is being filled.

The voting phase lasts from 00:00 UTC May 3 to 23:59 UTC May 10. Click here to vote. Questions and discussion with the candidates will continue during that time. Click here to ask the FDC candidates a question. Click here to ask the FDC Ombudsperson candidates a question. More information on the candidates and the elections can be found on the 2015 FDC election page, the 2015 FDC Ombudsperson election page, and the 2015 Board election page on Meta-Wiki.

On behalf of the Elections Committee,
-Gregory Varnum (User:Varnent)
Volunteer Coordinator, 2015 Wikimedia Foundation Elections Committee

Posted by the MediaWiki message delivery 03:45, 4 May 2015 (UTC) • TranslateGet help

What standards for Okinawan?[edit]

(Moved from the April page to the current page to ensure visibility.)

In the absence of any Wiktionary:About Okinawan page, I ask here.

What are the EN WT standards for Okinawan?

I was patrolling anon edits earlier and stumbled across うしぬちー (ushi nu chī, literally cow's milk). The basic content was fine, requiring some formatting and templatizing. The issues raised were twofold:

  • How should Okinawan be romanized?
The Wikipedia article itself is confusing, suggesting in a table that Okinawan is romanized using some IPA symbols, such as ʔ to mark glottals before bare vowels. The body of the text pretty consistently uses Hepburn. Comments on the Wikipedia Talk page suggest that most real-world examples of romanized Okinawan (i.e. not in upper academia) use Hepburn, same as for mainland Japanese.
I'd like to propose that we use modified Hepburn, same as for Japanese.
  • Where should Okinawan lemmata go?
I see some conflicting trends, where Okinawan entries might be filed under the hiragana spelling, or alternately under the kanji spelling. It seems that kanji are still used to write Okinawan, so it seems to me that the lemmata should go there, with the hiragana entries serving as soft redirects, again sames as for Japanese.

I've already reworked the うしぬちー entry to use our modified Hepburn romanization. If the lemma should be under the kanji spelling, we'll have to stubbify the うしぬちー entry and move the content to 牛ぬ乳 (and/or possibly 牛乳, depending on whether the is always written out explicitly).

I look forward to the community's thoughts on this. ‑‑ Eiríkr Útlendi │ Tala við mig 00:11, 8 May 2015 (UTC)

@Eirikr Your suggestions sound reasonable and I presume you know what you're talking about. Go for it. - -sche (discuss) 22:44, 25 May 2015 (UTC)


After the decease of User:Robert Ullmann someone has visited all the projects, where Ullmann's bot User:Interwicket had made contributions, proposing to remove the bot attribute from the Interwicket account. In many projects burocrats consented, so in the statistics this bot's contributions are ranked among the usual wiktionarians'. I think it should be reverted: Interwicket keeps being a bot even after its owner's death. --Al Silonov (talk) 10:17, 8 May 2015 (UTC)

I agree. I do think, however, that accounts and bots of deceased users should be permanently blocked so they can't be used if someone were to hack into them. —Aɴɢʀ (talk) 10:46, 8 May 2015 (UTC)
Sounds like a good idea. I will do that. —Stephen (Talk) 11:28, 8 May 2015 (UTC)

Cross-wiki Proverb redundancy[edit]

I find it problematic that we have three different Wikiprojects that contain somewhat overlapping (but largely uncoordinated) material on proverbs.

This is something of a mess. I believe that there should be some coordination to avoid duplication of effort, the potential presentation of conflicting translations or interpretations, and other inconsistencies in content arising or likely to arise between projects. I propose a cross-wiki task force to review the materials contained in these three projects and to enforce some sence of coordination and communication between them. In my view, this is exactly the kind of opportunity to harness the energies that are going into three different, redundant pages, and build one thoroughly vetted page in a single place.

My inclination, quite frankly, is to say that we should do away with the Wikipedia list and the Wiktionary appendix entirely, and host the entire thing on Wikiquote, with the appropriate cross-wiki soft redirects from the other sites, and with links to the Wiktionary definitions for individual pages on specific proverbs. I am cross-posting this on all three projects, but I believe that the discussion should be kept in one place, and should probably be the Wikipedia Village Pump discussion because that is the highest-traffic project. Cheers! bd2412 T 01:59, 9 May 2015 (UTC)

I think you're extremely unlikely to achieve consensus among the editors of three different projects to do anything but keep the status quo. I also think Wikiquote is worst place to host a collection of proverbs, since most proverbs aren't quotes. In the world of dead-tree reference works, if I wanted to find out what a proverb meant, I would turn neither to a book of quotations nor to an encyclopedia but to a dictionary, so I'd say Wiktionary is the place for them. But mostly I think it's tilting at windmills to try to get Wikipedians, Wiktionarians, and Wikiquotidians (or whatever they're called) to agree to a one-project solution. —Aɴɢʀ (talk) 08:27, 9 May 2015 (UTC)
I was hoping to keep the discussion in one place, but please note that I am not asking to get rid of Wiktionary entries on proverbs. The appendix of proverbs here is superflous. Also, in what way are proverbs not quotes? We have plenty of anonymous quotes, of unknown authorship and provenance, reported by their topic. bd2412 T 15:17, 9 May 2015 (UTC)
I knew you only meant the Appendix, not individual entries. Sorry for responding here rather than at WP. —Aɴɢʀ (talk) 17:23, 9 May 2015 (UTC)

Redundancy in RFDs[edit]

Even after several months of reading and observing, I am having problems with wiktionary logic and process.

I, as a several month user, looked at Help:Disputing a definition to learn about what processes exist in wiktionary. From there, I followed the link to {{rfd-redundant}}. There I found that I should add {{rfd-redundant}} and add it to Wiktionary:Requests for deletion (RFD). That process is for a reason other than that the term cannot be attested (which reasonably includes terms which can be attested but have not yet been attested).

Curiously, this is also the page for requests to restore entries that may have been wrongly deleted. This, in itself promotes a faulty feedback process because the signals, about potential problems in the process, loop and are buried within the process with the potential problems. There is no separation of failure reporting, no analysis, and no corrective action – this system fails the community. If the community is not informed about a faulty process, the community will not correct a defect.

I was under the impression, during several months of reading in the community portal and help, that the result (i.e. the modified entry) of an RFD process must still meet both formal guidelines: documented in actual usage and idiomatic. This is not the case in practice. The current process fails to output modified entries that meet both of those formal guidelines. Over the weekend I read and commented on RFDs (see my contributions for 9 May 2015). What I saw were discussions about entries but few discussions about actual usage.

Is having an RFD process that usually fails to produce an entry meeting WT:CFI good enough, or does it cause more harm by arbitrary removal of perceived redundancy in content added in WT:AGF? —BoBoMisiu (talk) 19:05, 11 May 2015 (UTC)

The mistake I see you make is that attested does not mean 'has citations on the entry or its citations page'. CFI, header attestation line 3 says "use in permanently recorded media, conveying meaning, in at least three independent instances spanning at least a year (different requirements apply for certain languages)." (no mention of copying the citations onto Wiktionary)
Therefore, the word oven is attested in English and meets CFI, even though there aren't any citations on that page, CFI-meeting citations do exist. I hope this answers your question which frankly, I don't understand. Renard Migrant (talk) 20:39, 11 May 2015 (UTC)
The RFD that bothers me the most is Wiktionary:Requests for deletion#GeoServer. @Sae1962:, the contributor who created the entry, wrote on his user page that he has expertise in computer science. Knowing that, I am confident that he saw clearly widespread use of the term with no need to add three usage attributions. @Liliana-60:, the user who added {{rfd}} did not see Sae1962's contribution as about something with clearly widespread use but only the Name of a specific software product. Obviously in WT:AGF but with a limited technical vocabulary, @Equinox, BD2412: voted for delete because they also though it is Not enormously famous outside the GIS sphere and Needs to meet WT:BRAND. I then saw this RFD and though It is insane to delete something so ubiquitous. There is an obvious cognitive bias between two groups of people. If I, instead of adding objective attested usage, just complained, about what I perceive as obvious and widespread, I could not convince anyone otherwise. Even after documenting the usage, I don't think they grasp those concepts. @Renard Migrant: if the usage was not added into this entry, this same situation could occur again with the same term and to the detriment of wiktionary get deleted. The RFD process does not output modified entries that are objectively improved. —BoBoMisiu (talk) 23:37, 11 May 2015 (UTC)
First of all, Sae1962 has a long, long history of creating entries for just about every random combination of words he runs into in his line of work. You can't see the list of his deleted entries, but it's extremely long, going back a number of years. Assuming good faith doesn't work here, because he really doesn't understand what he's doing wrong- he has no lexicographic common sense at all. Secondly, what makes you think that no one here knows anything about computers? Granted, BD2412 is an attorney, and there are a couple of others in other lines of work such as mathematicians and economists, but my impression is that computer professions are heavily over-represented here. Even I have a programming degree, though it's a very low-level one from eons ago (my Fortran class was one of the last to use punch cards). Chuck Entz (talk) 03:27, 12 May 2015 (UTC)
Entries need to be able to meet all criteria for inclusion, not just one. It's attested and idiomatic, not attested or idiomatic. Being in widespread use isn't an exemption from all the other criteria for inclusion. Or else we'd have green grass which is in very widespread use, but fails the idiomaticity criteria. Renard Migrant (talk) 15:37, 12 May 2015 (UTC)
Oh my, @Chuck Entz, Equinox, BD2412: I did not mean to be insulting; I am sorry for that; I should have used more words. I mean that we all have a limited vocabulary and cultural knowledge. Even an expert in something has a limited vocabulary and cultural knowledge outside that expertise. That cultural, or maybe institutional, knowledge is not knowledge in books but in people that use that vocabulary. Chuck Entz, I didn't think that no one here knows anything about computers. @Renard Migrant: claiming clearly widespread use is one-of-two current ways of attesting usage. The term has become genericized; and I think, because it is the eponym it is idiomatic, even though it would be excluded by parts of WT:BRAND. —BoBoMisiu (talk) 10:51, 13 May 2015 (UTC) modified 11:13, 13 May 2015 (UTC)
Deleted entries can be seen at X!'s Tools. Delete entries are shown at the statistics at the top of the report, and also in the list of new entries. The report shows Sae1962 created 10420 entries in the mainspace, of which 212 were removed. coding conventions is an example of an entry that the report shows as deleted, if you press "More". Nice tool. --Dan Polansky (talk) 15:47, 15 May 2015 (UTC)

Change to CFI (vote incoming)[edit]

This is a courteous heads up: I plan to add a vote for changing the CFI for terms consisting only of words of one type (e.g. compound nouns) and names to attestation only. I will give my rationale there. It will be the first vote I will put up, so if anyone wishes to give me advice on the way or has a reason why that vote so hyper über obviously pointless that it shouldn't even be put up for discussion, share it here. Otherwise I'm looking forward to your contributions on the vote page. _Korn (talk) 18:23, 12 May 2015 (UTC) ps: I'd be interested in hearing from the proponents of the idiomaticity criterion what detrimental effect they see in keeping words failing it. _Korn (talk) 18:33, 12 May 2015 (UTC)

Large amounts of drivel (= large amounts of drivel = large amounts of drivel). DCDuring TALK 21:07, 12 May 2015 (UTC)
If you mean single words won't de jure need to be idiomatic anymore, then good. It's a very silly loophole, albeit one nobody's successfully managed to use yet. Strictly speaking manlike doesn't meet CFI because the meaning's easily derived from the sum of its parts. Renard Migrant (talk) 21:17, 12 May 2015 (UTC)
I don't understand your idea. But idiomaticity or widespread use should not be criteria, the only criterion should be is this a word? (word may have to be interpreted differently for different languages). For phrases, it should be is it a term belonging to the vocabulary of the language? (even if used by specialists only). Dictionaries are not used only to understand what you read: Wiktionary may be used to learn words you've never read nor heard. Our objective is to describe the whole vocabulary of all languages. Lmaltier (talk) 21:36, 12 May 2015 (UTC)
I don't understand the idea, either. Are "compound nouns" those with spaces, hyphens, or neither? Will your change affect only English entries? (Obviously it would be silly to try to have every inflected or agglutinative form in e.g. Finnish or Hungarian.) Equinox 21:49, 12 May 2015 (UTC)
Per Equinox, can we get to the actual proposal, please? Very hard to make an informed comment on something that hasn't even been written yet. Renard Migrant (talk) 22:27, 12 May 2015 (UTC)

Actual proposal isn't fully phrased in my mind yet. The general idea is: 'Compound terms that only consist of words of one type, for example compound nouns that only consist of nouns (coal mine) and all names (personal, organisational), regardless of spelling (space/hyphen/one word), qualify for inclusion if they are attestable'. I'm not very educated about agglutinating languages. Please elaborate that point if you think it touches on this proposal. _Korn (talk) 09:20, 13 May 2015 (UTC)

So quarter midget race car would be in? And Wabash Cannonball Club Car and Wabash Cannonball club car? The first two are certanly attestable, probably the last as well. Have you done any thinking about this informed by some corpus research? DCDuring TALK 14:16, 13 May 2015 (UTC)
Yes, they would be in. Korn (talk) 14:45, 13 May 2015 (UTC)
Would comma-separated strings of adjectives and adverbs be in? (Would attestation that included and or or count or not?) Would the terms have to be constituents? Is standing start in "from a standing start" to be considered a noun-noun phrase (in), a verb-noun phrase (out), or an adjective-noun (out) phrase? Is red car a noun-noun phrase or an adjective-noun phrase? DCDuring TALK 15:16, 13 May 2015 (UTC)
My name Martin Gardner would qualify then, wouldn't it? Because it's attestable as the name of a writer of mathematical puzzles. Just so happens I have the same name. From your wording, this would 100% qualify because "all names (personal, organisational), regardless of spelling (space/hyphen/one word), qualify for inclusion if they are attestable". Why do you want things like that to qualify, though? Renard Migrant (talk) 16:23, 13 May 2015 (UTC)
What's a compound term? Does very quickly qualify as a compound term? Because it meets the other criterion of only being made up of one type of word (adverbs in this case). Also very happily, very angrily and so on. Renard Migrant (talk) 16:24, 13 May 2015 (UTC)
How would it affect, for example, the kingdom of Pisces (which I just added). It is figurative but is idiomatic under current WT:CFI? The threshold of the current Wiktionary:Idioms that survived RFD seems vague. —BoBoMisiu (talk) 13:05, 14 May 2015 (UTC)

Now that I understand, I think that nobody would support it. A language dictionary describes terms of the language, and it's very easy fo find examples meeting your criterion and that would be pointless here (Martin Gardner or very quickly are good examples: nobody would consider very quickly as a single term, Martin Gardner might be considered as a term, but any linguistic information about it relates either to Martin or to Gardner). Think more about your idea. But I feel that no criterion based on this kind of automatic rule would be acceptable. Lmaltier (talk) 18:26, 13 May 2015 (UTC)

I just wrote a more detailed text block, but a slip on the mouse deleted it. Instead of going into detail again, I'll just touch on some points: I was only thinking about compound nouns and company names. I kept the wording general just in case I'd remember other useful cases. Red car, off the top of my head: It's not a compound term when one part can be changed without destroying reference to the object or entity. Black pepper dyed red is red black pepper, not red pepper. Martin Gardner would be included but highlights a problem of my proposal. For personal names there either needs to be a criterion à la 'citations be without a context which explains who the name refers to' or they need to simply be excluded from the rule I propose. Standing start would be includable since participles can function as nouns. Lastly, abridged rationale: My proposal is mainly to make the rules less convoluted. Most exceptions to the idiomaticity criterion we have already deal with compound nouns and company names, we are already highly inconsistent when it comes to it. I am not thinking that all the terms this would make eligible are a boon for a dictionary. But No Paper, they don't hurt us either and someone might want to look them up. Korn (talk) 18:44, 13 May 2015 (UTC)
I don't really know why you'd want a vote on changes nobody's in favour of. Renard Migrant (talk) 21:22, 13 May 2015 (UTC)
We normally don't vote on things without having discussed them first. Since this is the first time this particular change is being discussed, it is too early to be creating a vote. And if the discussion reveals that no one supports this (as seems to be the case), then there is no point in going through the bureaucracy of voting. --WikiTiki89 21:32, 13 May 2015 (UTC)
The point of this post is exactly to have this discussion. How would it have to happen before a vote is alright? I also thought the extent of support was supposed to be found out about at the actual vote. I'm coming mostly from the RFD page where SOP terms are voted for keeping left and right, not always consistently when you look at different terms and sometimes in very blatant disregard of the CFI. Cf. go away as an interjection and themseaufwärts, which are really as SOP as you can possibly get. Furthermore WT:coalmine is semi-random in that the rule itself is clear, but the effects basically depend on whether people have randomly decided spell it with a space or without. The exemption itself is an acknowledgement of the shortcoming of the CFI as coal mine and coalmine are the same word. It only seems logical to me that either a word is dictionary-worthy or not, independently from spaces. By the restricted CFI as laid out now, I'm not in favour of keeping either coal mine or coalmine. By the aim of this project, I'm in favour of keeping both. Hence I move to remove the restriction. Or said more bluntly: Instead of having a rule garnished with a semi-random exemption, whose enforcement depends on who happens to walk by RFD and what mood they're in that week, why not just do away with the rule at least within a limited scope. Unlike DCDuring I don't fear the great drivel as much. Rather I have to point to No Paper again and express my faith that a term which somebody took time to enter might be one that somebody else might want to look up. And I ask again: What actual harm is the current criterion preventing? _Korn (talk) 23:38, 13 May 2015 (UTC)
ps.: You'll understand how in my youthful optimism I'm not equating five people being against it here with 'nobody is for it' and instead assume (possibly wrongly, we cannot know at this point) that since there is at least one person who is for it (myself), there might be others on this page who, despite not speaking up here, share my side of the issue. _Korn (talk) 23:44, 13 May 2015 (UTC)
I disagree with your criterion, not with your idea: yes, a term which somebody took time to enter might be one that somebody else might want to look up. But it should be a term. I think that my own idea (explained above) is consistent with yours. Lmaltier (talk) 05:49, 14 May 2015 (UTC)
@Korn: thank you for sharing your opinion. I am for this change. I agree that the rules are convoluted and are paralyzed by a lack of both enforceable notability standards (for proper nouns) and enforceable reliability of content standards.
I don't see a problem with having both coal mine and coalmine, one is just an alternative spelling of the other and there is {{alternative spelling of}} or {{alternative form of}} for that. Its a variation of the single-space or double-space after a period squabble that happened when word processing software replaced typewriters — things can have different forms and it really doesn't matter either way since the space is just a convention that gets documented as usage. I think the shortcomings are a general lack of objective standards and documentation, and an enculturation of rigid thinking that does not permit organic growth and change.
I think wiktionary should document terms or phrases the way that they are found in attributable usage. In my opinion, the current process for sum of parts culling is both harmful and hypocritical. The standard should not be "unattributed mimicry of another dictionary" but "documented attestation of actual usage". —BoBoMisiu (talk) 13:05, 14 May 2015 (UTC)
I don't think it matters whatsoever. As you say yourself, entries that fail CFI are getting kept on keep votes. I had a vote to make CFI trump voting, but it fails. It really is just voting, and it doesn't matter what changes to make to CFI as long as there's no rule saying you can't ignore it all together. Renard Migrant (talk) 16:05, 14 May 2015 (UTC)
@Renard Migrant: that is unfortunate, standards help every contributor and especially someone new, they also guide resolving disageements. Everything that gets contributed is at the mercy of the dictionary equivalent of a revolutionary council. My comment is general and not about what is happening now, in the past, or in the future. —BoBoMisiu (talk) 19:27, 14 May 2015 (UTC)
You can create a vote even while the discussion is ongoing, but that is suboptimal since this discussion shows there is going to be very little support. We don't want to include all English non-idiomatic noun-noun compounds, for example (computer buyer, computer seller, dictionary maker, discussion participant, etc.); I don't, and from what I have seen, most editors don't. --Dan Polansky (talk) 15:37, 15 May 2015 (UTC)
@Dan Polansky: I agree with you completely about the kind you provide examples of. They are obvious SOP and should not have entries. There also kinds that are not obviously SOP and become subjective choices of preference based on perceived usefulness. Its misleading to say that those are the consensus of the community when they are just the consensus of a couple people. There is no standard that everyone follows, just random changes take place, and any disagreement about the change is passive-aggressively ignored. —BoBoMisiu (talk) 17:05, 15 May 2015 (UTC)
Dan, you yourself argued to me to include all German non-idiomatic noun noun compounds like Computerkäufer, Computerverkäufer, Wörterbuchmacher, Diskussionsteilnehmer. That's racist. (Phrasing jocular, point serious. Please explain to me why it's fine in one language and bad in another.) _Korn (talk) 22:01, 17 May 2015 (UTC)
None of those words are noun-noun compounds; they may be nounnoun compounds, but that's different. As long as we're using jocular phrasing. That's egalitarian, to treat words without spaces uniformly.--Prosfilaes (talk) 06:02, 18 May 2015 (UTC)
Well, the question posed by me is why it's different. I think Dan was the one to fear the great flood of drivel (Ew.) and yet he argued to open up a nice drivel pool for drivel if it's just presented the right way. (Without space.) [Edit] scrolled up and it was During. Sorry, got confused by Talk:themseaufwärts discussion from my memory. _Korn (talk) 10:35, 18 May 2015 (UTC)
Because treating English and German differently would be racist, apparently.--Prosfilaes (talk) 13:42, 18 May 2015 (UTC)
Compounds such as Wörterbuchmacher are considered as words in German, and we accept all words. Lmaltier (talk) 11:29, 24 May 2015 (UTC)
  • Lemme step in here and say that I agree with Korn that CFI is overly restrictive and needs to either be formally reduced to a guideline, or additional criteria need to be added to allow more entries. In particular, the "lemmings" criteria (and I wish we wouldn't call it that, because that's such a negatively-charged term) needs to be adopted. Purplebackpack89 14:19, 18 May 2015 (UTC)

Acadian French[edit]

Given that we (correctly) don't consider Canadian French or Quebec French to be separate languages from European French, it's odd that the Canadian French dialect of Acadian French has its own code in Module:languages/datax. Perhaps it's a simple error by someone who forgot that etymology-only language codes belong in Module:etymology language/data. I would like to reclassify it as an etymology-only language, moving and changing its code (to fr-aca, which fits the usual naming scheme for etymology-only language codes) and updating the handful of entries which refer to it. Alternatively, we could downgrade it even further, to the level of Quebec French (which isn't even an etymology-only language, but just a regional context label.) - -sche (discuss) 20:23, 13 May 2015 (UTC)

I think that any variety of a language that is referenced frequently enough in etymologies can have an entry in Module:etymology language/data. So the only question is how often is Acadian French referenced in etymologies? And for that matter, how often is Quebec French referenced in etymologies? --WikiTiki89 20:31, 13 May 2015 (UTC)
I have downgraded Acadian French to an etymology-only language. Fewer than a dozen pages were affected. - -sche (discuss) 21:40, 18 May 2015 (UTC)

Officially downgrade WT:CFI from a policy to a guideline[edit]

I would urge the community as an administrative matter to downgrade Wiktionary:Criteria for inclusion from a policy to a guideline. Rationale, it's a de facto guideline as editors disregard it as much or as little as they see fit. Entries are kept or deleted according to a vote, not according to CFI. I call it an administrative issue because it's already not being implemented, so this just makes it official. Passing this vote (not yet drafted) is just an honesty matter. New editors otherwise may be misled into thinking we stick by CFI. Renard Migrant (talk) 19:37, 14 May 2015 (UTC)

I disagree with the proposal, but I think that if a vote is started on this, the only two options should be downgrade and enforce. You can't have your cake and eat it. —CodeCat 19:44, 14 May 2015 (UTC)
That sounds like a really good rationale for agreeing. What's your thinking? Renard Migrant (talk) 19:47, 14 May 2015 (UTC)
No need for that. We already had a vote on enforcement. It failed. Purplebackpack89 22:02, 14 May 2015 (UTC)
I smell "reverse psychology"! Equinox 19:45, 14 May 2015 (UTC)
If we downgrade it to a de jure guideline, then people will de facto completely ignore it. I much prefer it being a de jure policy and de facto guideline. --WikiTiki89 19:52, 14 May 2015 (UTC)
That's a very good point, actually. I hadn't thought of that. Renard Migrant (talk) 20:05, 14 May 2015 (UTC)
I disagree. That doesn't make much sense. The reason that people treat CFI as a guideline is that they disagree with portions of it, not some inexplicable desire to break the rules. Purplebackpack89 03:21, 15 May 2015 (UTC)
Entries are kept or deleted according to a vote, which itself is ideally in accordance with not according to CFI.
Just like you can't make a constitution a guideline just because there are opinion-based decision making happening (like courts) --Dixtosa (talk) 19:52, 14 May 2015 (UTC)
Well, exactly. The problem is not that editors disregard CFI as they see fit, the problem is that some terms are considered idiomatic by some people and SOP by others. When people vote "keep" on a term that some people consider SOP, that doesn't mean the keep-voters are ignoring CFI, it merely means the keep-voters feel the term does meet CFI while the delete-voters feel it doesn't. That's not the fault of CFI, that's the fault of Wiktionary's being a democracy instead of a dictatorship. —Aɴɢʀ (talk) 20:31, 14 May 2015 (UTC)
But it doesn't. Plenty of people vote keep or delete not based on CFI. Surely you don't dispute that. Renard Migrant (talk) 21:12, 14 May 2015 (UTC)
Yes, I do dispute that. Plenty of people vote keep or delete based on their interpretation of CFI rather than yours. That isn't the same thing. —Aɴɢʀ (talk) 21:51, 14 May 2015 (UTC)
Then the problem is the RFD process. Keep/delete votes are not enough; there must also be a consensus on the rationale for keeping or deleting. —CodeCat 22:02, 14 May 2015 (UTC)
  • I second Wikitiki89's point. The same principle is illustrated in this anecdote: where I was born, marijuana is illegal but the law regarding it is not enforced. This has the desired effect of discouraging it being smoked in public places and when it would be a nuisance. If the official stance were simply that smoking marijuana was discouraged, the government's recommendation would be ignored completely and people would smoke as much and wherever they want (not that I have a problem with that, but the government does). —Μετάknowledgediscuss/deeds 20:52, 14 May 2015 (UTC)
  • Support: I've been saying to this for months, especially after Renard's CFI-related vote failed some months ago (see also Wiktionary:Beer_parlour/2015/February#Wiktionary:Votes/2014-11/Entries which do not meet CFI to be deleted even if there is a consensus to keep: What does it mean?. To review, it's clear that a majority of participants on this project oppose some or all of CFI as written, and that CFI doesn't work particularly well in many situations. So demote it. Purplebackpack89 22:02, 14 May 2015 (UTC)
There need to be rules, otherwise anyone can add anything, like Urban Dictionary. Changing the rules is fine (by vote): having basically no rules, only ignorable "guidelines", is disaster, as conflicts can never be resolved. Equinox 22:28, 14 May 2015 (UTC)
I'm sorry, I don't buy into the argument that guidelines aren't rules. Also, if the majority of editors commenting on a particular entry want the rules ignored, why shouldn't it? Do the creators of CFI get indefinite veto power? (And remember, I'm not as opposed to UD as you are; people use it a lot more than this project, so they must be doing SOMETHING right. It's also not as no-rules as you would claim). Purplebackpack89 22:39, 14 May 2015 (UTC)
Guidelines guide, and only recommend; rules dictate, and determine what happens. Definitely not the same. People do not use UD to find out seriously what a word means: it has no etymologies and no pronunciations, and most of the words are made up for a short-lived joke; you cannot even tell which ones are real, since it doesn't tell you. Who "uses" UD seriously? Show evidence or do not reply. Equinox 22:42, 14 May 2015 (UTC)
Don't think you can tell me when to reply and when not to, Equinox. Regardless of whether I believe that rules "dictate", I don't believe that this is an area that should be "dictated", particularly "dictated" by something people don't really support anymore, at least in its entirety. As for your UD claim, you're coming way too close to making this project so serious that nobody will use it. You believe that there's some pervasive detriment in certain types of entries being kept. Guess what? There isn't! In most RfD cases, there's no harm in being more entries. Harm comes in RfV cases, because RfV is the venue we dispute whether or not the information in a particular area is factual. Purplebackpack89 00:05, 15 May 2015 (UTC)
  • I weakly oppose downgrading, and strongly oppose allowing editing CFI without a vote. WT:CFI now says (entered without a vote but as a result of a related vote): "In rare cases, a phrase that is arguably unidiomatic may be included by the consensus of the community, based on the determination of editors that inclusion of the term is likely to be useful to readers." This gives much of the flexibility that was required. Also, WikiTiki89 makes an interesting point, although I am not sure I entirely agree with it. --Dan Polansky (talk) 14:58, 15 May 2015 (UTC)
  • First off: We're all here for a common goal, so always tell yourself that the person not sharing your opinion is only stupid and not evil and hence probably doesn't deserve vitriol. As for the actual topic, I'm mostly with our coding cat. Either the rules are adamant or they're nothing. Since I recently proposed easing the CFI, I'm tempted by just effectively doing away with them by demotion, but this is the internet and 'democracy' equals mob rule or dictatorship of the loudest minority. We try our best to rein that in in the voting process, but I think the RFD is too random already (as I said above). My preferred solution would be the creation of a binding CFI everyone can get behind. If that isn't possible, RFD-deniers should at least have to name a reason for ignoring the rules. (Only applying to cases when a term does violate the CFI.) Should the CFI be done away with (guideline), then we must install alternate rules for deletion; because the CFI are not only here to prevent bad entries but also to prevent bad deletions, and I recently saw comments boiling down to 'I wish I could delete that term but the CFI won't let me'. We mustn't give up our safety-measures to whims. We, the usual suspects, might each consider ourselves helpful and reasonable, but anyone could waltz in. Always consider the things you propose imagining that WT is suddenly overrun by the worst possible people. _Korn (talk) 20:37, 15 May 2015 (UTC)
    • The problem with making them adamant is that it's abundantly clear to me that a majority of users disagrees with them as written. If they are to be adamant, they should be fixed, and they should be fixed BEFORE they become adamant. Also, I'm not buying into the claim that you and Wikitiki and others have made that "either the rules are adamant or they're nothing." There's room for interpretation. Purplebackpack89 21:44, 15 May 2015 (UTC)
Well, I thought I said that they should be fixed beforehand. And there shouldn't be room for interpretation. They should be absolutely unambiguous. Of course that makes it more difficult to cast them in a form everyone will feel perfectly comfortable with. But difficulty is a category different from need. _Korn (talk) 10:58, 16 May 2015 (UTC)
Dude, writing CFI that clear-cut is impossible. Besides, if we could do it, we wouldn't need RfD in the first place, because everything would be clear to everybody what's CFI and what isn't. Purplebackpack89 22:53, 16 May 2015 (UTC)
I want to believe. Also, at least our general CFI at the moment is pretty close to being clear cut. I think Dan Polansky recently pointed out that it doesn't specifically say whether "separate" refers to the spelling or the words, but other than that there's not much left to the imagination about what "attested" and "idiomatic" mean. In theory our RFD should be mostly occupied with providing idiomatic usages for terms of which the requester wasn't aware. _Korn (talk) 14:21, 17 May 2015 (UTC)
I think the first two lines are a bit of a car crash: "A term should be included if it's likely that someone would run across it and want to know what it means. This in turn leads to the somewhat more formal guideline of including a term if it is attested and idiomatic."
That does make it sounds like erm should be included if it's likely that someone would run across it and want to know what it means and the whole attested and idiomatic bits are guidelines and therefore not mandatory. There's also no exemption in CFI for single words being unidiomatic. I mean, paintlike would fail for a couple of reasons. It's not idiomatic (the meaning is easily derived from the sum of its parts, i.e. like paint) and it's not likely someone would run across it and want to know what it means. And attested and idiomatic are only guidelines anyway. Renard Migrant (talk) 14:53, 17 May 2015 (UTC)
  • Oppose, this is a silly and frivolous proposal. I would say that User:Angr has it exactly right: "When people vote "keep" on a term that some people consider SOP, that doesn't mean the keep-voters are ignoring CFI, it merely means the keep-voters feel the term does meet CFI". As User:Dan Polansky point out, there is also now a provision within CFI that says: "In rare cases, a phrase that is arguably unidiomatic may be included by the consensus of the community, based on the determination of editors that inclusion of the term is likely to be useful to readers". With over four million entries in the dictionary, the few dozen that we argue about represent an exceedingly rare proportion of entries. The obvious purpose of CFI is to keep people from making shit up, i.e. inventing a new word or phrase that has never actually been used and stuffing it into the dictionary, and to keep people from making directory-like entries of names with no unique lexicographical value like Enos T. Throop. RfV and RfD are highly successful in getting rid of such things, and our practices are in fact completely consistent with CFI, as policy, as currently written. bd2412 T 15:49, 17 May 2015 (UTC)
You can't possibly believe that "When people vote "keep" on a term that some people consider SOP, that doesn't mean the keep-voters are ignoring CFI, it merely means the keep-voters feel the term does meet CFI". It's clearly not the case. Currently going on on RFD WT:RFD#wall hanging many people are saying keep per the lemming principle. The lemming principle is not in CFI, it is not mentioned at all. Just search 'lemming' on WT:RFD for other examples. Or search for 'keep outside of CFI'. I don't see how anyone could actually believe what you've said given the obvious contradictory evidence. Renard Migrant (talk) 15:59, 17 May 2015 (UTC)
Then it is one of those aforementioned rare cases where it is nonetheless considered useful to the readers, as currently permitted by CFI. In any case, it has been pointed out in the discussion that there are things that could be called hangings that, when hung on a wall, would not be a "wall hanging". bd2412 T 16:09, 17 May 2015 (UTC)
So you wholly agree with him but you admit he's wrong. Glad you've cleared that up. Renard Migrant (talk) 16:10, 17 May 2015 (UTC)
That's not what I said at all. Why did you vote to keep snitch bitch? Why did you vote to keep sudden death? These are entries that at least one editor has asserted are SOP, so how can you disagree with that? bd2412 T 16:16, 17 May 2015 (UTC)
Relevance? Renard Migrant (talk) 16:32, 17 May 2015 (UTC)
I'm a bit baffled by as well, since, if my memory serves me right, there were the odd entries being kept despite being unanimously considered SOP. Or at least none of the voters expressed a different opinion, even when voting to keep it. Maybe, before discussing what to do with the CFI, we should start a debate on what the CFI are actually supposed to prevent? So far the three opinions seem to be: 1. Tons of low-value entries. 2. Made up things. 3. Bad deletions. _Korn (talk) 16:23, 17 May 2015 (UTC)
Wall hanging is a very good and current example where everyone seems to agree that it doesn't meet CFI, just about half of those want to keep it. Renard Migrant (talk) 16:31, 17 May 2015 (UTC)
Then you need to read both CFI and that discussion more carefully. For example, I stated in my rationale for keeping that uses exist where the phrase "does not seem particularly transparent"; ergo, it is idiomatic.I didn't think that I needed to spell that out. I see no editor saying, "this goes against CFI, but keep anyway", unlike your representation of the situation. In any case, you have also revived my interest in that particular discussion enough to get me to do some further searching, and to find that wallhanging is attested, and this entry therefore meets WT:COALMINE. Cheers! bd2412 T 19:03, 17 May 2015 (UTC)
go away, I'm pregnant. Is the 'lemmings' argument that we keep anything entered in other dictionaries?_Korn (talk) 21:51, 17 May 2015 (UTC)
With go away, yes, that is the "lemmings" principle that if other reputable dictionaries (i.e. not Urban Dictionary or others like it) tend to include a phrase, we should include it also. I'm pregnant is a "phrasebook" argument, which is that we should include certain phrases that are likely to be useful for translation purposes in an urgent situation. bd2412 T 22:03, 17 May 2015 (UTC)
Well, on first glance I rather dislike the lemmings principle then. Also, I'm with whoever proposed to move the phrasebook to an Appendix and further move to link to said appendix on the home page. A dictionary is not a phrasebook and I don't see anyone who was not specifically made aware that he has a phrasebook looking this up in one term rather than I (+ am) + pregnant. As it is now, passerbys probably aren't even aware that our phrasebook section exists. _Korn (talk) 10:40, 18 May 2015 (UTC)

neo- versions of capitalized words[edit]

We have neo-Nazi, Neo-Latin, neo-Luddite and Neo-Malthusian (as examples). Which is "correct" in these cases, neo- or Neo-? SemperBlotto (talk) 15:20, 15 May 2015 (UTC)

GNV is case sensitive. neo-Nazi, Neo-Nazi at Google Ngram Viewer gives an idea; similarly neo-Latin, Neo-Latin at Google Ngram Viewer, neo-Luddite, Neo-Luddite at Google Ngram Viewer and neo-Malthusian, Neo-Malthusian at Google Ngram Viewer. Based on this, neither is a malformation or wrong capitalization but there is an overall tendency toward lowercase "neo-". --Dan Polansky (talk) 15:25, 15 May 2015 (UTC)
Yes. That seems logical. The ngrams are probably skewed a bit in favour of capitalised forms as they will frequently be the first word of a sentence. I'll try to move them and replace uncapped redirects with alternative forms of. SemperBlotto (talk) 15:29, 15 May 2015 (UTC)
Go ahead. neo-Malthusian should be the main entry, and Neo-Malthusian should be an alternative case entry. --Dan Polansky (talk) 15:50, 15 May 2015 (UTC)
Yes, I'm going to finish off a batch of Italian neo-words then go through all the English terms I can find. SemperBlotto (talk) 15:53, 15 May 2015 (UTC)
I think we should decide on a case-by-case basis based on frequency data. --WikiTiki89 16:01, 15 May 2015 (UTC)
When both are clearly acceptable, instead of making checks every single time, which is either causing somebody work or will just be another rule ignored, we should just decide on one which is overall more common. I don't see any benefit in this level on detail. Of course I won't stop you from taking that sorting work on yourself, it just feels less neat and tidy to me. _Korn (talk) 20:02, 15 May 2015 (UTC)
We already do this for every other type of alternative form, so why make an exception here? If we chose neo- as the standard, but one particular word is attested 90% of the time with Neo-, you would still have its main entry be at neo-? --WikiTiki89 20:10, 15 May 2015 (UTC)
Yeah, I just prefer uniformity. Even when there is variation, it's still always the same prefix. But as said, I wouldn't stop you from putting that work onto yourself. _Korn (talk) 20:42, 15 May 2015 (UTC)
When I have time, I'll do a similar job on terms with and without hyphens - e.g. neosocialist & neo-socialist. SemperBlotto (talk) 07:53, 16 May 2015 (UTC)

Template:IPAchar and the lang= parameter[edit]

I'm now finding pages which use {{IPAchar}} with a lang= parameter. But this parameter isn't actually used at all by the template, it's completely ignored. Should it be removed from pages, or does someone know a possible use for it? —CodeCat 20:34, 15 May 2015 (UTC)

Do you still have a category for Dutch IPA entries that use invalid phonemes? If so, {{IPAchar|...|lang=nl}} could find things that need cleaning up. But otherwise, I can't think of a reason to have it. It's probably just there out of force of habit, since we add the language code in virtually every other template. —Aɴɢʀ (talk) 21:25, 15 May 2015 (UTC)
Should I leave it as it is then, with a no-op parameter in case we ever decide to use it? —CodeCat 22:08, 15 May 2015 (UTC)
I don't know what a no-op parameter is, but as long as it's doing no harm, leave it as it is. —Aɴɢʀ (talk) 06:02, 16 May 2015 (UTC)
@Angr no-op. --WikiTiki89 14:47, 18 May 2015 (UTC)

Iranian etyl stacking issues[edit]

I'm adding a couple of Bactrian words and this got me thinking about etymology stratification for Iranian languages.

It seems clear that Proto-Iranian and Proto-Indo-Iranian need to be distinguished, they're apart far enough. But would there be any point in creating competing full appendices for both — or, as I'm thinking, could we limit separate Proto-Iranian entries to words whose Indo-Iranian (or Indo-European) origin is not clear? If there is a Proto-Indo-Iranian entry for something (e.g. *ćata), we could continue to list also the Iranian descendants there, and for maintainability, we could redirect potential Proto-Iranian entries like *cata to these. Any opposition?

In addition to these though, we even also have Category:Terms derived from Old Iranian and Category:Terms derived from Middle Iranian. This is sort of nonsense: these are mere chronological eras, not languages. E.g. "Middle Iranian" is a catch-all term for when it is not known if a word originates in Middle Persian or Parthian or Sogdian or what. Treating these as etymology categories seems like a bad idea (would you even consider a Category:Terms derived from Medieval European languages?!), and putting the words here under Category:Terms derived from Iranian languages and outright explaining issues of dating in etymology sections ought to be the way to go. --Tropylium (talk) 23:30, 15 May 2015 (UTC)

I raised the same objection about "Middle Iranian" and such before, but was ignored. —CodeCat 00:05, 16 May 2015 (UTC)
We also seem to have categories for "Prakrit", in Category:Prakrit languages. —CodeCat 00:08, 16 May 2015 (UTC)
I looked thru everything we have under "Old Iranian", and about half of the time the label seems to be just a proxy for Proto-Iranian. I think I'll do a cleanup run of these later this weekend if I find the time. Middle Iranian might be a bit more work (and might require a slightly more detailed plan). ---Tropylium (talk) 01:38, 16 May 2015 (UTC)
I have changed my previous opinion about Category:Terms derived from Old Iranian and Category:Terms derived from Middle Iranian. I now think they should be replaced by Category:Terms derived from Iranian languages, but the display and Wikipedia linking of {{etyl|OIr.|xx}} and {{etyl|MIr.|xx}} as "Old Iranian" and "Middle Iranian" should be kept.
As for Proto-Iranian appendices, I oppose redirecting them to the Proto-Indo-Iranian page. Duplication can be avoided by using {{see desc}} in the Proto-Indo-Iranian page. --Vahag (talk) 10:17, 16 May 2015 (UTC)
{{etyl|OIr.|xx}} is the wrong syntax I think it should be {{etyl|ira-oir|xx}} because it needs to start with ira, like {{etyl|roa-oit}} for Old Italian starts with roa. Renard Migrant (talk) 11:08, 16 May 2015 (UTC)
This sounds contradictory; the point of {{etyl}} is exactly to link things under separate categories like Category:Terms derived from Old Iranian. I also believe w:Proto-Iranian (which is at least a page of its own) would be generally more beneficial to link than w:Old Iranian (which is merely a redirect to w:Iranian languages), esp. on pages like 𐭮𐭯𐭠𐭧𐭯𐭲𐭩 that refer only to a reconstruction.
As for protolang maintenance: would you also oppose listing Indic descendants on PII pages? If so, is there a point in having a separate reconstruction level that only accommodates references to two other reconstruction levels? (Cf. how we do not have any Proto-West Germanic entries.) If not, why do Iranian and Indic need different treatment? Currently we only seem to have four Proto-Iranian and two Proto-Indo-Iranian entries, so there's plenty of room for growth — and for maintanability to get out of sync. --Tropylium (talk) 00:17, 18 May 2015 (UTC)
Don't forget that there's more to a protolang entry than just the descendants list, thought that's certainly important. We shouldn't duplicate between parent and daughter protolang entries, but not every daughter protolang term can be reconstructed, and some that can may not be worth the bother, if there's only one or two descendants. We may want the descendants in either of the two places, but we should avoid having them in both, to avoid synchronization problems (there's also {{etymtree}}, but that has its own of set of tradeoffs). Chuck Entz (talk) 01:04, 18 May 2015 (UTC)
Intermediate protolang terms are always reconstructible, provided that the stage in general has been worked out. if we can track e.g. a word's development from an individual Germanic language back to PIE, or from an individual Finnic language back to Proto-Uralic, that already implies that we know what it looked like in Proto-Germanic or Proto-Finnic. The separation exists for the opposite case, where we have an e.g. Iranian-specific word and would not be able to claim that it existed at an older stage such as Proto-Indo-Iranian.
I am however not quite sure if the reconstruction of Proto-Iranian is in a good enough shape that we even could always create separate entries for it. I've seen wildly contrasting views on several matters, e.g. some claim the existence of fricatives *f *θ *x; some claim that, per some marginal languages, only aspirates *pʰ *tʰ *kʰ should be reconstructed; others yet claim retention of laryngeals, which seems to imply biphonemes *pH *tH *kH. (Tho this kind of matters might be better taken to Wiktionary talk:About Proto-Iranian.)
Anyway this ties back into the wider question of how to format protolang appendices. I continue to think that trying to enforce every page to cover only a "single term" in a "single language" is somewhat over-reductive, and it might be sometimes sensible to e.g. treat closely-separated subfamilies as subsections. In this case, say, Proto-Iranian and Proto-Indic entries as level-2 subsections of a Proto-Indo-Iranian entry, if it exists. --Tropylium (talk) 09:59, 18 May 2015 (UTC)
I do not oppose listing Indic descendants at the PII page. I think Proto-Iranian needs a different treatment, because it has many descendants and borrowings. Proto-Iranian pages can get pretty long, as in Appendix:Proto-Iranian/mauč- and Appendix:Proto-Iranian/baiwar-. Listing Indic descendants would make the pages even less usable. But this is not a fundamental problem that needs a policy. Depending on circumstances we could have everything on a PII page or use {{see desc}}, as appropriate. --Vahag (talk) 19:25, 20 May 2015 (UTC)
  • The problems with PII are manifold:
    • It's not yet properly reconstructed. I've read that Kümmel is writing a book on it but it doesn't seems to be released yet.
    • There are no dictionaries of it (yet). The reason for this is because Sanskrit serves as a perfectly proper replacement for Proto-Indo-Aryan (though with some differences, comparable to e.g. differences between OCS and Proto-Slavic), and for Proto-Iranian there are many old Iranian languages attested. There is no immediate "need" for PII since it's too easy to jump from Old Iranian and Sanskrit to PIE if there is a connection.
    • It's the oldest and most divergent existing IE branch containing many languages spanning some 4 millennia. The proper treatment of it would require extensive knowledge of various scripts and sound changes that basically no living person possesses. There is a huge amount of intra-branch borrowing and inspecting the literature just for that is a very daunting task.
    • Combining already present PIA and PI appendices into a PII page should be a piece of cake if we decide that. Currently there doesn't seem any need for that since there are too few entries. However, since the Proto-Iranian appendices demonstrate that the Iranian descendants lists (which should be in general smaller than Indo-Aryan descendants lists) can grow very large, it seems more proper to have them listed separately, and only combine them into a PII appendix for PII-specific treatment. This would be similar to treatment of Proto-Balto-Slavic terms (which have their own set of problems, but regardless Proto-Slavic descendants are not copied to PBSl. appendices when they are created, nor is that a proper place to list them). --Ivan Štambuk (talk) 00:24, 25 May 2015 (UTC)

Wikimedia Foundation Board of Trustees elections 2015[edit]

Wmf logo vert pms.svg

This is a message from the 2015 Wikimedia Foundation Elections Committee. Translations are available.

Voting has begun for eligible voters in the 2015 elections for the Wikimedia Foundation Board of Trustees. Questions and discussion with the candidates for the Board will continue during the voting.

The Wikimedia Foundation Board of Trustees is the ultimate governing authority of the Wikimedia Foundation, a 501(c)(3) non-profit organization registered in the United States. The Wikimedia Foundation manages many diverse projects such as Wikipedia and Commons.

The voting phase lasts from 00:00 UTC May 17 to 23:59 UTC May 31. Click here to vote. More information on the candidates and the elections can be found on the 2015 Board election page on Meta-Wiki.

On behalf of the Elections Committee,
-Gregory Varnum (User:Varnent)
Volunteer Coordinator, 2015 Wikimedia Foundation Elections Committee

Posted by the MediaWiki message delivery 17:20, 17 May 2015 (UTC) • TranslateGet help

Voting on normalization of entries[edit]

I was reading/skimming the whole of 2006 thread User talk:Connel MacKenzie/Normalization of articles these days. They're those formatting rules that we see everywhere, like whitespaces, headers, etc. I'd like to create votes for some of those to officialize them. Few are controversial, one or two are outdated but I suppose most would just pass with unanimity or something. Even if we apparently don't have any bot like User:AutoFormat these days (Do we?) to enforce/apply the rules, I think that's besides the point of officializing them. Thoughts? --Daniel 05:45, 19 May 2015 (UTC)

With one exception, at first glance I agree with each of those old proposals. DCDuring TALK 06:16, 19 May 2015 (UTC)
Leave out the part about glosses needing to be sentences and I'll wave them through. No benefit in translating Bier as 'Beer.' rather than beer and it would be bound to make some translations needlessly clunky. Also: The fuck is wikification? _Korn (talk) 10:23, 19 May 2015 (UTC)
What is the difference between making wikimarkup normalization official and adding these wikimarkup site conventions into WT:MOS? @Korn: wikification is creating linked terms and replacing HTML elements with wikimarkup and templates. —BoBoMisiu (talk) 12:26, 19 May 2015 (UTC) modified 13:11, 19 May 2015 (UTC)
Yeah, I was thinking of leaving out that point you mentioned. --Daniel 12:37, 19 May 2015 (UTC)
They need to be rewritten in much clearer language. Then I think they can just be added directly to WT:ELE (after seeing enough consensus in this discussion). There is no need for a vote. The one about glosses needing to be sentences is controversial and should be left out (and let's not start another debate here about it). --WikiTiki89 12:49, 19 May 2015 (UTC)
I think having all HTML auto-converted to UTF-8 is no problem. On a tangent, do entries contain UTF-16 values that may get bulldozed over into UTF-8? —BoBoMisiu (talk) 13:11, 19 May 2015 (UTC)
There should be an exception for non-printing characters, which should be allowed to use HTML syntax. --WikiTiki89 15:49, 19 May 2015 (UTC)

I created User:Daniel Carrero/Normalization of entries as an index of all points covered by User talk:Connel MacKenzie/Normalization of articles. Feel free to edit it. --Daniel 15:46, 19 May 2015 (UTC)

I thought there was some consensus that English definitions (and Translingual entries such as the taxonomic ones) were supposed to be formatted as if they were sentences. I think the consensus opposed such formatting for FL entries and Translingual ones such as those for CJKV characters. DCDuring TALK 16:38, 19 May 2015 (UTC)
Use whatever is most natural. If the definition is just one word, like "broom", then just leave it as that. Turning it into "A broom." is silly and pointless.
Also, I made some changes to the list, added some points. —CodeCat 17:06, 19 May 2015 (UTC)
@CodeCat: That seems to mean that there is not a complete consensus for the format of English definitions, so the normalization cannot include that. I nonetheless thought that there was some consensus on that point.
As to it being "pointless". Using the indefinite article is a marker of countability. As the use of labels is not nearly complete or accurate enough to allow normalization, we should enjoy any such marker that we find. DCDuring TALK 18:33, 19 May 2015 (UTC)
@Daniel Carrero: about User:Daniel Carrero/Normalization of entries#Others/Technical, not allowing {{#invoke:}} forces scripting into a single environment? Is that good? —BoBoMisiu (talk) 18:15, 19 May 2015 (UTC)
Lua scripts should always be wrapped in templates. So {{#invoke:}} should only be in the template namespace. Keep in mind that that this proposal only describes our entries, and so only applies to the main namespace and to reconstructions in the appendix namespace. --WikiTiki89 18:59, 19 May 2015 (UTC)

Should we create a single vote for the whole bunch minus the controversial ones? I was thinking of creating a handful of small votes, like maybe Wiktionary:Votes/2015-05/Categories and interwikis and Wiktionary:Votes/2015-05/Normalization of headers. --Daniel 14:24, 20 May 2015 (UTC)

I don't think we need an official vote at all. We can just remove all the controversial ones and have an informal vote right here in the BP. --WikiTiki89 14:33, 20 May 2015 (UTC)
I'm of the opinion that formal votes is better than informal votes/discussions alone. Most of these points are already informally widely accepted on the community anyway. Or maybe one could argue that the fact User:AutoFormat was ever given the bot flag through a 2007 vote with wide support, already formalized the normalization of entries to some extent. --Daniel 14:53, 20 May 2015 (UTC)
WT:ELE states at the top that "It should not be modified without discussion and consensus. Any substantial or contested changes require a VOTE." Our changes are not contested (once we remove the controversial ones), but I guess they are substantial. Anyway, I think that the reason WT:ELE is so out of date is specifically because we've been requiring votes in order to make substantial changes. --WikiTiki89 15:05, 20 May 2015 (UTC)
  • (after edit conflict) @Daniel Carrero, Wikitiki89: Do you have in mind running this on a bot? If not, do we have anyone able and willing to run and maintain such a bot? Should this be a guideline that any bot would need to follow as it inserted or revised entry content? If it is not mandatory for either bots or humans, it certainly would not need a vote. If we would like to actually get it implemented, then we need to consider whether a vote is useful. I, for one, think such a vote would be useful, even if the guidelines were only mandatory for bots. DCDuring TALK 14:59, 20 May 2015 (UTC)
    The idea is that these rules that are independent of how they are enforced. So running a formatting bot is a completely independent issue from these changes. Of course, any formatting bot would have to conform to the new rules. I personally do not plan on running this bot, but I cannot speak for anyone else. --WikiTiki89 15:05, 20 May 2015 (UTC)
    I also personally do not plan on running this on a bot. I propose that, if people support these rules, then it should be mandatory for bots and a guideline for people. If someone forgets to add a space after ---- between languages, it does not harm how people see the entry, but that's not generally how the code looks like. It could be a separate policy page, tentative name: Wiktionary:Normalization of entries (WT:NORM). --Daniel 16:37, 21 May 2015 (UTC)
    An alternative / addition to a bot could be a client-side script / extension which verifies the content before submitting it to Wiktionary. -- Jberkel (talk) 16:22, 25 May 2015 (UTC)

User:Daniel Carrero/Normalization of entries#Whitespace and characters says:

  1. All whitespace or non-printing characters other than space and newline must be encoded as HTML entities, such as &nbsp; or &ltr;.
  2. No other HTML entities allowed, these should be converted to UTF-8. &amp; -- > &

Is it accurate? I don't remember using nbsp in any entries myself, even though I do remember using it in templatized tables. Can I see one or more examples of entries with nbsp, ltr and the like? The search box seems unhelpful for that. --Daniel 17:31, 20 May 2015 (UTC)

See Aves#Hypernyms for many instances of &nbsp; There are numerous such examples in Translingual entries with Hypernyms sections and others in Translingual entries with Coordinate terms and Hyponyms headers.
You may have missed the questions I asked above. DCDuring TALK 20:01, 20 May 2015 (UTC)
BTW, I changed "must" to "may". I think this needs to be permitted, but not required. --WikiTiki89 20:25, 20 May 2015 (UTC)

I am creating a few pools for more controversial items.

Poll 1[edit]

Poll with no policy value. About this norm:
"All whitespace or non-printing characters other than space and newline must be encoded as HTML entities, such as &nbsp; or &ltr;. No other HTML entities allowed, these should be converted to UTF-8. &amp; -- > &"


  1. Symbol support vote.svg Support DCDuring TALK 16:24, 23 May 2015 (UTC)
  2. Symbol support vote.svg Support The reason I added that norm was to avoid invisible characters sneaking in and causing problems. We've had that problem before. By making it immediately obvious when such characters are present, they can presumably be noticed faster. —CodeCat 20:40, 23 May 2015 (UTC)


  1. Symbol oppose vote.svg Oppose On one hand, we sometimes need non-printing characters to appear literally. For example, in Persian orthography, the zero-width non-joiner (U+200C) is used to connect compounds and certain morphemes, such as کفش‌ها (kafš-hâ). It would be pretty silly to have to write this as {{m|fa|کفش&zwnj;ها}} instead of {{m|fa|کفش‌ها}}. On the other hand, this overlooks the fact that &amp; may be necessary to display what we want. I will oppose this unless it is significantly reworded to take these and other things into account. --WikiTiki89 15:31, 26 May 2015 (UTC)
  2. Symbol oppose vote.svg Oppose sometimes Help:Hidden text, i.e. <!-- annotation --> is the best way to annotate; reading poll 1 again, I think it would exclude this type of useful annotation. I support stripping duplicate spaces, tab → space, HTML character names → glyph, etc. This <!-- annotation --> is a habit for some programmers like myself. —BoBoMisiu (talk) 20:16, 29 May 2015 (UTC)
    This poll is about HTML-encoded characters; I don't think it is supposed to include HTML comments. --WikiTiki89 20:27, 29 May 2015 (UTC)


  1. Symbol abstain vote.svg Abstain I don't personally remember using nbsp and ltr outside templates and probably would prefer having a template for single uses like {{nbsp}}. But I see there are other people using nbsp and the like so I abstain. --Daniel 16:00, 23 May 2015 (UTC)
  2. Symbol abstain vote.svg Abstain I don't think it matters. I prefer to use the HTML character names (&thinsp;) because they are mnemonic and Unicode values are not. On wiktionary I usually just select a special character from the edit dropdown.BoBoMisiu (talk) 20:25, 23 May 2015 (UTC) modified 20:16, 29 May 2015 (UTC)
  3. Symbol abstain vote.svg Abstain I'm not sure whether U+1039 (MYANMAR SIGN VIRAMA) is considered a nonprinting character or not, but I definitely agree with Wikitiki that I'd rather write {{m|my|ဗုဒ္ဓ}} than {{m|my|ဗုဒ&#4153;ဓ}}. And when I do write the latter, the automatic transliteration breaks: {{m|my|ဗုဒ&#4153;ဓ}} renders as ဗုဒ္ဓ (bu.da.္dha.) instead of ဗုဒ္ဓ (buddha.). —Aɴɢʀ (talk) 21:44, 27 May 2015 (UTC)

Poll 2[edit]

Poll with no policy value. About this norm:
"Definition lines should begin with a capital letter and end with a period if they are sentences; they should begin with a lowercase letter and end without a period otherwise."


  • Symbol support vote.svg Support Sounds good enough, but I'd be interested in hearing alternate ideas or possible problems with that, if any. --Daniel 16:00, 23 May 2015 (UTC)
  1. Symbol support vote.svg Support for All English and Translingual definitions and full FL definitions (ie, don't care about FL one-word glosses) —This unsigned comment was added by DCDuring (talkcontribs).
  2. Symbol support vote.svg Support it currently has a patchwork of capitalization and I think it would be to much work to normalize. —BoBoMisiu (talk) 20:33, 23 May 2015 (UTC)


  1. Symbol oppose vote.svg Oppose I disagree that some definitions of English terms should start with a capital letter and some not; that is going to create poorly looking typography, and is a deviation from any lexicographical practice to be seen online, AFAIK. Furthermore, we have almost no definitions that are sentences; the phrasing probably wanted to distinguish a definition consisting of multiple words, often of the genus-differentia format, from a definition that uses a synonym. --Dan Polansky (talk) 16:57, 23 May 2015 (UTC)
  2. Symbol oppose vote.svg Oppose Very bad idea for a dictionary. If it could be confined to definitions only (and therefore only to English entries), and not to translations, and if the definition is long enough, it is usually (but not always) clear that the capitalization is only because it begins a sentence. But people will generalize and start capitalizing translations as well, and it will often be difficult or impossible to tell whether the capitalization is required in the orthography (as in a proper noun), or simply sentence case. I have used a few bilingual dictionaries that capitalized the start of each translation (e.g., January -> Janvier), and you cannot tell if it’s sentence case or required orthographically. Encyclopedias almost always use full sentences, and usually paragraphs, so initial caps are a requirement. In dictionaries, OTOH, it is frequently confusing and leads to mistakes and misunderstandings. Terrible idea for a dictionary. —Stephen (Talk) 18:17, 23 May 2015 (UTC)
    I would not recommend this for any FL definition that was not a full definition. Frankly, I don't much care how FL entries are formatted. DCDuring TALK
  3. Symbol oppose vote.svg Oppose Fragment definitions should probably still begin with a capital letter. Essentially in accord with Dan. Purplebackpack89 22:58, 23 May 2015 (UTC)
  4. Symbol oppose vote.svg Oppose --WikiTiki89 15:31, 26 May 2015 (UTC)
  5. Symbol oppose vote.svg Oppose - it doesn't matter. SemperBlotto (talk) 20:32, 27 May 2015 (UTC)
  6. Symbol oppose vote.svg OpposeUngoliant (falai) 15:02, 31 May 2015 (UTC)


  1. Symbol abstain vote.svg Abstain I somewhat support the suggestion, but I don't like the inconsistent typography that this creates. At the same time, I don't really know a sensible way to make it look nice either. The problem is that it looks silly to turn a single word into a sentence, but we can't avoid that some definitions are sentences, and we also have some consisting of multiple sentences. If we are going to have multiple sentences, we must use a full stop out of necessity. —CodeCat 20:44, 23 May 2015 (UTC)
    How does this proposal create typography more inconsistent than what we have now? DCDuring TALK 23:31, 23 May 2015 (UTC)
    It doesn't create it, but it doesn't really eliminate it either. —CodeCat 15:05, 25 May 2015 (UTC)
  2. Symbol abstain vote.svg Abstain Can someone point me to an example of a definition line that's a sentence? I don't think I've ever seen one. —Aɴɢʀ (talk) 16:34, 25 May 2015 (UTC)
  3. Symbol abstain vote.svg Abstain --Daniel 18:15, 26 May 2015 (UTC)

Poll 3[edit]

Poll with no policy value.
Proposal: Not having any module invocations ({{#invoke:) in the mainspace.
Rationale: Modules would always be wrapped up in templates.


  1. Symbol support vote.svg Support Sure, why not? --Daniel 16:00, 23 May 2015 (UTC)
  2. Symbol support vote.svg SupportBoBoMisiu (talk) 20:34, 23 May 2015 (UTC)
  3. Symbol support vote.svg Support It's the status quo anyway, this just formalises it. —CodeCat 20:45, 23 May 2015 (UTC)
  4. Symbol support vote.svg Support --WikiTiki89 15:31, 26 May 2015 (UTC)



  1. Symbol abstain vote.svg Abstain for now, pending convincing arguments. DCDuring TALK 16:28, 23 May 2015 (UTC)

Poll 4[edit]

Poll with no policy value.
Proposal: About whether these rules are mandatory or guidelines, proposed wording:
"These norms are mandatory for bots. When they do not make any difference to how a user sees the page, they can be treated as guidelines. When they do make a difference, such as the presence of ---- and non-linking of language names in translation sections, they are mandatory for everyone."


  1. Symbol support vote.svg Support --Daniel 16:00, 23 May 2015 (UTC)
  2. Symbol support vote.svg Support DCDuring TALK 16:29, 23 May 2015 (UTC)
  3. Symbol support vote.svg Support But we should treat it as a bad edit if someone turns good formatting in existing content into bad formatting. That is, you're allowed to correct the format, but not "un-correct" it. —CodeCat 20:47, 23 May 2015 (UTC)
  4. Symbol support vote.svg Support the more rules we enforce, the easier will be the transition to a structured / semantic version of Wiktionary -- Jberkel (talk) 16:18, 25 May 2015 (UTC)


  1. Symbol oppose vote.svg Oppose because, I think that the wording, "When they do not make any difference to how a user sees the page, they can be treated as guidelines", conflicts with mainspace module invocation wrap in Poll 3. I support the rest of proposal 4. —BoBoMisiu (talk) 20:44, 23 May 2015 (UTC)


  1. Symbol abstain vote.svg Abstain I would like to make them mandatory, but I know exceptional cases will show up and an annoying admin would try to enforce a rule that was broken for a legitimate reason. --WikiTiki89 15:31, 26 May 2015 (UTC)

why not make it mandatory always? Also, what does 'mandatory' imply? Like, we can legitimately yell at the user if they add an unformatted content? Dixtosa (talk) 07:18, 28 May 2015 (UTC)

Well, users are already blocked and their pages deleted if they add completely unformatted content, aren't they?
But for really minor things like most of what is being discussed here, like failing to put a space after # before definitions, I assume no one is going to yell at anybody. For this minor example, I suppose most of the time no one is going to notice even if someone makes an habit of creating many entries without the space. Yes, we could just make them mandatory always like you said. On a side note, I hope someone makes a bot for these things again eventually. --Daniel 07:47, 28 May 2015 (UTC)

Poll 5[edit]

Poll with no policy value.
Option 1: Having these rules as a separate page. Possible name: Wiktionary:Normalization of entries. Shortcut: WT:NORM.
Option 2: Ammending ELE with all the rules.

Support option 1

  1. Symbol support vote.svg Support --Daniel 16:00, 23 May 2015 (UTC)
    • I'd argue these can be kept separate as they are mostly just a list of minor details. I'd argue that WT:ELE is for new users, it explain things like what is a context label and what is a headword line. These rules are worded in a way that assumes people already know what we are talking about. --Daniel 16:00, 23 May 2015 (UTC)
  2. Symbol support vote.svg Support, to avoid complicating ELE further. DCDuring TALK 16:30, 23 May 2015 (UTC)
  3. Symbol support vote.svg Support but only for things that have no effect on the page appearance. —CodeCat 20:48, 23 May 2015 (UTC)

Support option 2

  1. Symbol support vote.svg Support for things that affect the appearance of the page, such as the ---- between sections. These are part of entry layout as much as anything else on that page is. —CodeCat 20:48, 23 May 2015 (UTC)
  2. Symbol support vote.svg Support No reason to have things in separate places. --WikiTiki89 15:31, 26 May 2015 (UTC)



  1. Symbol abstain vote.svg Abstain it should be a policy, its location does not matter. —BoBoMisiu (talk) 20:47, 23 May 2015 (UTC)

Poll 6[edit]

Poll with no policy value. About right-aligned content.
Option 1:
"One blank line before all headings, including between two headings, except for before the first language heading.
Right-aligned content such as {{wikipedia}} or images count as blank lines for this purpose."


# Something something something.

Option 2:
"One blank line before all headings, including between two headings, except for before the first language heading.
Right-aligned content such as {{wikipedia}} or images can be placed below a heading; after that, one blank line."



# Something something something.

Support option 1

Support option 2

  1. Symbol support vote.svg Support That's what I normally do. --Daniel 15:17, 25 May 2015 (UTC)
    This option may sometimes cause extra vertical space to appear in the page, though. —CodeCat 16:09, 25 May 2015 (UTC)
    The extra vertical space only appears if we use a broken template with extra newlines at the end of the code before <includeonly/>, I presume? five second rule has an image and feminism has an image+{{wikipedia}}, both of which using the option 2 rule, none of those has extra vertical spaces appearing on the page. --Daniel 16:15, 25 May 2015 (UTC)
  2. Symbol support vote.svg Support Easier to parse visually. Jberkel (talk) 16:25, 25 May 2015 (UTC)
  3. Symbol support vote.svg Support I hate option 1. --WikiTiki89 15:31, 26 May 2015 (UTC)
  4. Symbol support vote.svg Support--Dixtosa (talk) 20:17, 26 May 2015 (UTC)
  5. Symbol support vote.svg Support not terribly important, but it’s a tiny bit easier on the eyes. — Ungoliant (falai) 15:05, 31 May 2015 (UTC)



  1. Symbol abstain vote.svg Abstain This depends on the outcome of Poll 4, since the presence or absence of a blank line after such templates does not affect display. —Aɴɢʀ (talk) 16:36, 25 May 2015 (UTC)

Poll 7[edit]

Poll with no policy value. About this norm:
"For templates, newlines are allowed for clarity."




  1. Symbol abstain vote.svg Abstain --Daniel 16:04, 25 May 2015 (UTC)
    • I don't remember any specific templates that would require using newlines in the mainspace, maybe some conjugation tables?--Daniel 16:04, 25 May 2015 (UTC)
  2. Symbol abstain vote.svg Abstain I don't understand this and will wait for examples. --WikiTiki89 15:31, 26 May 2015 (UTC)
  3. Symbol abstain vote.svg Abstain per Wikitiki89. DCDuring TALK 22:54, 26 May 2015 (UTC)
  4. Symbol abstain vote.svg Abstain I don't know what this means. Is saying that, if adding a template into an entry, then a new line is the preferred location for that template? —BoBoMisiu (talk) 19:53, 29 May 2015 (UTC)

Poll 8[edit]

Poll with no policy value. These are alternatives to what was proposed in poll 2, concerning English sections.

Option 1:
"In English sections, senses should not be capitalized (i.e., they should begin with a lowercase letter unless the definition starts with a proper noun, for example) and they should end without a period."

  • English examples of kitten:
    1. young cat
    2. a young cat

Option 2:
"In English sections, senses should begin with a capital letter and end with a period."

  • English examples of kitten:
    1. Young cat.
    2. A young cat.

Option 3:
No rule for English sections, sometimes they have capitalization and periods, sometimes they don't.

  • No examples given this time, all the others could apply.

Additional example of inconsistent use of capitalization/periods:

  1. A metal support for logs in a fireplace.
  2. A hot dog.
  3. (poker slang) Underdog
  4. (slang, almost always in the plural) feet.
—Fragment of dog as of revision 32773331, minus quotes and usexes.

Support option 1

  1. Symbol support vote.svg Support --Daniel 18:17, 26 May 2015 (UTC)
    • If there's a possibility of standardizing capitalization/periods for English definitions, this one looks simpler than the alternatives and also seem to match the FL sections which normally aren't capitalized or end with a period. --Daniel 18:17, 26 May 2015 (UTC)
  2. Symbol support vote.svg Support I don't like the look of capitalization, which also requires cumbersome piped links ([[young|Young]] [[cat]]. vs. [[young]] [[cat]]) in many cases. I am also against the period at the end, because these are not "sentences". --WikiTiki89 18:48, 26 May 2015 (UTC)
  3. Symbol support vote.svg Support I’ve been using option 2 in order to avoid controversy, but I prefer not using capitalisation for the reasons Wikitiki mentioned. — Ungoliant (falai) 15:07, 31 May 2015 (UTC)

Support option 2

  1. Symbol support vote.svg Support This is, I think, how most definitions in English entries and in Translingual taxonomic entries are now. Proper use of articles and determiners eliminates most of the need for pipes. Pipes, capitalization and terminal periods could be inserted by a bot like Autoformat if we ever find someone able and willing to take responsibility for it. DCDuring TALK 22:56, 26 May 2015 (UTC)

Support option 3

  1. Symbol support vote.svg Support - whatever feels right, just do it SemperBlotto (talk) 20:35, 27 May 2015 (UTC)


  1. Symbol oppose vote.svg Oppose The more I think about this, I wonder if its just another way to beat down new contributors or revert their contributions. But, I agree with DCDuring, in poll 8, option 2, about use of articles and determiners and bots. I disagree with Wikitiki89 about sentences, I think some definitions need to be detailed and granular in a way that is best understood as one or more sentences. I think poll 8, option 1, could unintentionally promote creation of dumbed down definitions. I think poll 8, option 3, is like poll 2 which I support. —BoBoMisiu (talk) 19:44, 29 May 2015 (UTC)
    A sentence would be "This word means ..."; the "..." by itself is not a sentence no matter how much detail or granularity it contains. --WikiTiki89 19:48, 29 May 2015 (UTC)


Poll 9[edit]

Poll with no policy value. About this norm:
"POS sections may contain at most one headword line and one definition list. Thus, entries like this or this are not correct."


  1. Symbol support vote.svg Support How hard is it to just add another header before the headword line? --WikiTiki89 19:47, 27 May 2015 (UTC)
  2. Symbol support vote.svg Support. I hate the headerless form, it looks awful and adds no value. Renard Migrant (talk) 15:17, 31 May 2015 (UTC)
  3. Symbol support vote.svg Support. - -sche (discuss) 17:37, 31 May 2015 (UTC)


  1. Symbol oppose vote.svg OpposeUngoliant (falai) 15:12, 31 May 2015 (UTC)


  1. Symbol abstain vote.svg Abstain Inclined to vote support, is there any reason why we can't use {{context|plural x}} or additional POS sections in these two example entries? Pending convincing arguments. --Daniel 17:23, 27 May 2015 (UTC)
    Using {{context|plural x}} creates too much clutter and makes it very difficult for languages that have lots of things in the headword line. Adding an addition POS header is the preferred solution. --WikiTiki89 19:47, 27 May 2015 (UTC)

Poll 10[edit]

Poll with no policy value. About this norm:
Option 1:
"Floating boxes like {{wikipedia}} can appear on a line between POS header and headword line." Example:


From {{etyl|foo|bar}} {{term|something|lang=und}}.


# Something something something.

Option 2:
"Floating boxes like {{wikipedia}} should not appear on a line between POS header and headword line, they could be somewhere else where applicable." Examples:


From {{etyl|foo|bar}} {{term|something|lang=und}}.


# Something something something.

From {{etyl|foo|bar}} {{term|something|lang=und}}.


# Something something something.

Support option 1

  1. Symbol support vote.svg Support I would rather see {{wikipedia}} at the sense line that the wikipedia article is about so I don't have to scroll up or down. —BoBoMisiu (talk) 02:27, 29 May 2015 (UTC)
    I have demonstrated in WT:SANDBOX (permanent link]) why this physically won't work. If you put {{wikipedia}} on the same line, it breaks the formatting. If you put it on an otherwise blank line between definitions, it breaks the numbers and resets it back to 1. However you can still link to Wikipedia using {{w}}, you just can't use {{wikipedia}}. Renard Migrant (talk) 15:25, 31 May 2015 (UTC)
    @Renard Migrant: But it does work for {{pedia}} on that page. Probably we would want it to appear of the right hand side rather than immediately to the right of the definition, but someone with good CSS skills could probably make that happen optionally. DCDuring TALK 17:15, 31 May 2015 (UTC)
    @Renard Migrant: Mmmm, to bad. @DCDuring: its not good to hack the stylesheets, it has to be responsive design that will not be broken by future mediawiki changes. —BoBoMisiu (talk) 19:25, 31 May 2015 (UTC)

Support option 2

  1. Symbol support vote.svg Support I tend to put {{wikipedia}} below the language header as in the example, otherwise we have vertical blank space between the language section and the Wikipedia box. Granted, probably terms with multiple POS sections with separate Wikipedia articles could benefit with the alternate proposal, as long as there are not already separate Etymology sections to put the Wikipedia boxes in. --Daniel 17:23, 27 May 2015 (UTC)
  2. Symbol support vote.svg SupportUngoliant (falai) 15:14, 31 May 2015 (UTC)
  3. Symbol support vote.svg Support having Wikipedia under the language header directly, or if more than one link, use {{pedialite}} in the external link section. Renard Migrant (talk) 15:25, 31 May 2015 (UTC)


  1. Symbol support vote.svg Support I favor putting {{wikipedia}} as high up as possible as long as it is clear which meaning it is for. Usually this means under the language header, rarely under an Etymology header, but sometimes under a POS header. Thus, there should not be restrictions. --WikiTiki89 19:51, 27 May 2015 (UTC)


  1. Symbol abstain vote.svg Abstain I think that best practices we actually follow are more complicated than any of those expressed. The scope of the Wikipedia article linked could be at any of several levels, including even above any L2 header, as when the WP article is a disambiguation page referring to meanings for which we do not have any definition in English, but may have one in another language. At the other extreme the scope could be at the level of a noun (usually a particular definition of a noun) for which there may be no superior Etymology header, in which case option 1 may not give a satisfactory result. IOW, the ideal placement could be:
    1. above the first L2;
    2. immediately below the first L2;
    3. below an Etymology header (where there are multiple etymologies and no PoS is excluded from the WP article's coverage;
    4. immediately below a PoS header; or
    5. adjoining a specific definition in a longer series of definitions.
    We may have a default preference, but this does not seem to be implementable by bot. DCDuring TALK 16:05, 31 May 2015 (UTC)
    If we forego right-hand side placement in any but the simplest of cases (which are also the most numerous), some of the above can be handled by the use of External links, supplemented by bold explanatory headings begun with a semicolon. But I still doubt that there will not be exceptions which should not be overridden by bots. DCDuring TALK 16:11, 31 May 2015 (UTC)

Poll 11[edit]

Poll with no policy value. About tables.
Option 1
"All tables in the mainspace should be templatized. There should be no wikitables or HTML tables."
Option 2
"All tables in the mainspace should be either templates or wikitables. There should be no HTML tables."
Option 3
"Tables in the mainspace can freely be templates, wikitables or HTML tables."

Support option 1

  1. Symbol support vote.svg Support Seems to be the status quo, all inflection/conjugation/declension/pronouns/etc tables that I remember are wrappep up in templates. Correct me if I'm wrong. --Daniel 17:23, 27 May 2015 (UTC)
    Occasionally you'll encounter tables in the entries themselves, especially for one-off inflection patterns. --WikiTiki89 19:53, 27 May 2015 (UTC)
    Examples please. --Daniel 14:30, 29 May 2015 (UTC)
    Search a database dump for strings like "colspan" and you'll find hundreds of entries with non-templatized tables showing a variety of information, e.g. ふりがな, depth, integer, orange, anterior, unus, ezberlemek, andare, ястреб. Numerous of these (e.g. orange, anterior, ezberlemek, andare, ястреб) seem like they should be switched to use templates, but some (like depth) might be harder to templatize. - -sche (discuss) 16:13, 29 May 2015 (UTC)
    Then I suggest we modify this poll to cover only ad hoc tables like the one at depth (so, excluding inflection tables and the like).
    Also, if the ugliness of entries is a concern and the inspiration of this poll, then we first should find a new place for quotations and then we can discuss ad hoc tables, which I think are much more rare and less ugly.
    BTW, why does this poll implicitly prefer wikitables over HTML? Does anyone really think wikitables are nicer than html? --Dixtosa (talk) 16:33, 29 May 2015 (UTC)

Support option 2

  1. Symbol support vote.svg Support We should avoid wikitables in the mainspace, but not ban them altogether. --WikiTiki89 19:53, 27 May 2015 (UTC)
  2. Symbol support vote.svg Support I would like to see a policy that states that wikitables are allowed but templates are preferred and encouraged. —BoBoMisiu (talk) 02:22, 29 May 2015 (UTC)

Support option 3

  1. Symbol support vote.svg Support for now, in the absence of any discussion. —This unsigned comment was added by DCDuring (talkcontribs).



  1. Symbol abstain vote.svg Abstain I feel like we shoulda talked this out a little more before creating eleven polls. One or two, sure. Eleven? Nah! Purplebackpack89 20:24, 27 May 2015 (UTC)
    I see no harm in having this number of polls because there were multiple topics to be discussed. I even left some of those out of the vote for being controversial. --Daniel 07:52, 28 May 2015 (UTC)

Poll 12[edit]

Poll with no policy value.
Proposal: Not having any template invocations in the mainspace that:

  1. either are hosted in the user namespace directly
  2. or depend on the templates that are hosted in the user namespace.

As an example of the #2nd relation, {{User:CodeCat/list_helper}} is used by hundreds of list templates.


  1. Symbol support vote.svg Support --Dixtosa (talk) 14:01, 29 May 2015 (UTC)
  2. Symbol support vote.svg Support --Daniel 14:24, 29 May 2015 (UTC)
  3. Symbol support vote.svg Support with a limited-time exception for testing. DCDuring TALK 16:47, 29 May 2015 (UTC)
  4. Symbol support vote.svg Support In fact you could extend this to any sort of link to user namespace. --WikiTiki89 16:49, 29 May 2015 (UTC)
  5. Symbol support vote.svg Support Templates deployed in the mainspace should not rely on templates or module code in userspace. --Dan Polansky (talk) 10:23, 31 May 2015 (UTC)
  6. Symbol support vote.svg Support, except that it should be acceptable in short-term situations such as debugging, testing new functionality or when the template is still a prototype. — Ungoliant (falai) 15:18, 31 May 2015 (UTC)




  • Should we restrict invocations in the Appendix entries too that host reconstructed terms?
  • I think this poll should also include module invocations, which makes this and #Poll 3 almost identical. I am down with merging these two. --Dixtosa (talk) 12:19, 30 May 2015 (UTC)

Poll 13[edit]

Poll with no policy value.
This is an alternative to poll 4, which proposed making all the norms discussed here mandatory for bots but a guideline for humans except when it does make a difference to how the page is displayed to users.

It's not necessary to mention at the policy any distinction between bots and humans.

Assuming these norms pass a vote and become policy, then they would be mandatory like any rule we find on WT:CFI and WT:ELE. It's just that some norms make a difference like the non-linking of language names (which is already mentioned at ELE) and the ---- between language sections, so they are probably going to be reverted/fixed more readily if/when someone fails to follow these rules. On the other hand, minor things like forgetting the space after # perhaps would go unnoticed or people won't bother fixing them most of the time (or better yet, they would be automatically fixed by a bot when one comes up), but presumably having the space is still what we think as best for our entries.


  1. Symbol support vote.svg Support It's better this way in my opinion. --Daniel 17:55, 29 May 2015 (UTC)
  2. Symbol support vote.svg Support It is already part of our bot policy that bots can only make uncontroversial edits, which essentially makes guidelines like this a hard requirement for them. There is no need to repeat our bot policy on page unrelated to bots. --WikiTiki89 18:04, 29 May 2015 (UTC)


  1. Symbol oppose vote.svg Oppose Compelling bots to apply the rules will get us toward implementation quickly without getting in the way of human contributions to entries. To put our hopes in the reincarnation of Autoformat seems foolish. DCDuring TALK 18:00, 29 May 2015 (UTC)
  2. Symbol oppose vote.svg Oppose Humans should not be obliged to anxiously follow these detailed minor formatting rules. --Dan Polansky (talk) 10:26, 31 May 2015 (UTC)



For the topics being discussed here, I created a vote:
Wiktionary:Votes/pl-2015-05/Normalization of entries
--Daniel 07:54, 28 May 2015 (UTC)

Wiktionary:Votes/sy-2015-05/User:Kephir for de-sysop[edit]

Following continued abuse of the administrator privileges by this user, I have requested that he be de-sysopped. As with other de-sysop votes, the vote begins immediately and extends for two weeks. Purplebackpack89 14:11, 20 May 2015 (UTC)

Explicit images[edit]

Should not be allowed because they are:

  1. guess what? - explicit
  2. not safe for work
  3. not completely dictionaric
  4. not utterly necessary

I have removed an image from penis twice but @Prosfilaes was quick to revert me, asserting that looking up penis is the same as looking at a real image of penis, which is false obviously.

The link to wiki is enough. Generally, if someone ended up here rather than wiki it means they seek definitions not images.

I guess you do not want me to import whole (fe)male anatomy from commons, right? --Dixtosa (talk) 17:30, 20 May 2015 (UTC)

We have discussed this before. I am in favor of limiting explicit images to where they are necessary. I am even favor of collapsing them with a NSFW warning. Other editors seem to feel that this is censorship and that penises should be displayed on every entry. I think that that is an immature opinion. --WikiTiki89 17:34, 20 May 2015 (UTC)
  • Symbol support vote.svg Support collapsing them with a NSFW warning or something, I think it's better to remove the picture. In any event, I added a {{commons}} box to the entry. --Daniel 17:41, 20 May 2015 (UTC)
One of the legitimate issues that was brought up before was how we can decide what needs to be collapsed and what does not need to be. --WikiTiki89 17:49, 20 May 2015 (UTC)
That could be emergent rather than explicit, if contributors collapsed whatever they felt needed collapsing. That will lead to disagreement, which will lead to discussion, which will lead to best practices. Trying to define it from the outset would be nigh impossible, but finding out what the community does would be easy. - TheDaveRoss 17:53, 20 May 2015 (UTC)
I'm of the faction that doesn't see a difference between a penis and a house. Both images are equally useful or useless to their entries. Just collapse all images. That way nothing gets lost and maybe it even saves people with a slow connection some bandwidth usage. _Korn (talk) 17:55, 20 May 2015 (UTC)

Enforcing wrapping explicit images within a template is a must-do. No need to discuss that. (if I remember correctly English Wikipedia already does this so we can learn from them). As for removing them, censorship argument is just throwing the buzzword in hope to be plausible, which seems to have been effective :/. Oh those pity images of penises, how dare we censor them? No, seriously, censorship is about someone's rights being violated. Also, if censorship is bad, then niggerfaggot is racist both of them are bad. No?--Dixtosa (talk) 18:03, 20 May 2015 (UTC)

Please don't get polemic. _Korn (talk) 18:05, 20 May 2015 (UTC)
I don't see Wikipedia collapsing any explicit images at w:human penis, they show up just fine to me. About deciding what needs to be collapsed and what does not need to be: If anything needs to be collapsed, probably penis does. In the past I've added non-explicit images to foreplay, sexual intercourse, handbra and pornography, which I think look good and are informative enough. I don't know exactly if other people would want the same for penis, or that it can even be done in the first place, i.e. leaving only a non-explicit image if there is any, just for educative purposes. Educative purposes meaning, I don't know if this can be taken seriously or not: <sarcasm>We'd need in case a reader is not exactly aware of what a penis is or where it is located, which I'd argue a dictionary would help by defining it and an image (a drawing or something) could help to illustrate.</sarcasm> Also, I fear that Wiktionary might get blocked in schools or something. But so would be Wikipedia? I didn't seek any information about school-blocking so it could just as easily be a moot point. --Daniel 18:09, 20 May 2015 (UTC)
  • The image currently at penis is relevant and nonprurient. I see no reason to remove it or hide it, though if a drawing instead of a photograph would be acceptable (vulva has a drawing), I wouldn't object to that either. —Aɴɢʀ (talk) 19:05, 20 May 2015 (UTC)
  • Eh, I say we deal with them one at a time. What's explicit and what isn't is highly subjective. Purplebackpack89 19:25, 20 May 2015 (UTC)
  • People coming to an entry on penis should not be surprised to see a photograph of a penis. If the same picture were at kitten (or even at cock, Johnson, schlong, pecker, or dick) it would be more of a problem. That said, I have no strong objection to collapsing the image. bd2412 T 19:33, 20 May 2015 (UTC)
    • Why should they not be surprised? —CodeCat 19:34, 20 May 2015 (UTC)
      • Because they are looking up "penis" on a platform amenable to hosting images. We have many entries with images, and hopefully in time will have many more. bd2412 T 19:57, 20 May 2015 (UTC)
        • And you expect them to know what the word means? This is a dictionary, you know. —CodeCat 20:39, 20 May 2015 (UTC)
          • That makes me wonder about a dogmatic question: What's our target audience? We always assume to write for fluent speakers of English, right? _Korn (talk) 09:42, 21 May 2015 (UTC)
            • We assume that we are writing for people who speak English well enough to search for and find dictionary entries written in English. This may be a rudimentary level, but it's hard to imagine a person searching for penis who doesn't have the foggiest idea what it means. bd2412 T 15:49, 21 May 2015 (UTC)
              • And yet, we have a definition for it. We also have definitions for far more basic terms like the and sun. If we're going to assume that users know these words, why have definitions? —CodeCat 15:58, 21 May 2015 (UTC)
                • @BD2412 If I came across a term which is perhaps more obviously lewd (assuming that it was at least vaguely understood before search) such as Cleveland steamer should I expect there to be a picture or video on that page as well? I would very quickly stop using a dictionary which required me to view content which is generally considered to be graphic whether I wished to or not. I think that penis is too close to the bubble to be the primary example. - TheDaveRoss 19:25, 22 May 2015 (UTC)
                  • I think there's a very different issue with phrases like that because even a typically literate English speaker is not likely to know the meaning of a phrase that sounds innocuous by its components (there being nothing particularly lewd about Cleveland or steamer individually, nor for the sake of argument about donkey or punch, or hot or carl). We are perfectly capable of discerning what definitions should reasonably be expected to contain sexual content by the reader who speaks English well enough to use an English dictionary, and what words (or phrases) are likely to surprise readers who would not inherently expect them to contain sexual content. Compare, for example, our entry on anal sex. The reasonably literate reader will know that this is a sexual term, and should not be surprised to find images along the lines of those already contained at w:Anal sex. bd2412 T 19:39, 22 May 2015 (UTC)
                    • @BD2412 I think that is the crux of the matter, we are already making subjective decisions about such things. We don't need to make assumptions about what any particular user might or might not understand, we don't need to make assumptions about which terms they may or may not want to see an image for. Instead we can include the images and allow the user to make the decision for themselves as to whether they wish to view them. An added benefit here is they get to make the decision after they have had a chance to read the definition. This solution would also be likely to expand the range of "tolerable" images for many editors. - TheDaveRoss 18:16, 27 May 2015 (UTC)
I think the penis pic is relevant and useful. Equinox 20:35, 20 May 2015 (UTC)
That's the problem. It is relevant and useful, but is also "not safe for work" and many other places where we don't want to discourage Wiktionary from being used. --WikiTiki89 21:13, 20 May 2015 (UTC)
  • Is there any evidence that the present image makes the page "not safe for work", whatever that means? Does it apply only to some countries? --Dan Polansky (talk) 21:29, 20 May 2015 (UTC)
    I'm not sure what kind of jobs you work, but the Czech Republic is not that much of an outlier here that you can believably pretend not to know what we're talking about. --WikiTiki89 15:11, 21 May 2015 (UTC)
  • I am reasonably certain that my boss would be quite displeased if he were to look over my shoulder and see an image of genitalia, prurient or otherwise. I might also incur the displeasure of my coworkers, who might have reason to notify my boss.
I am certain enough of this that I do not wish to experimentally confirm the follow-on effects of viewing such images on my work computer.
By way of context, I work in a company in the electronics and entertainment industry, in a capacity for which pictures of genitalia are clearly not relevant to my work duties. ‑‑ Eiríkr Útlendi │ Tala við mig 22:59, 20 May 2015 (UTC)
Would looking up penis in Wiktionary be relevant to your work duties? bd2412 T 23:35, 20 May 2015 (UTC)
  • No, but as someone commonly handling Japanese, I or one of my colleagues might have occasion to look up ちんこ (chinko). (I happen to know this word and wouldn't look it up, in part to avoid any possible images.) In addition, there is the Special:Random link on the left-side toolbar, which could conceivably land someone on an entry with a problematic image. ‑‑ Eiríkr Útlendi │ Tala við mig 23:53, 20 May 2015 (UTC)
  • I am struggling to come up with a scenario where someone is at work, and is legitimately sitting there clicking the "Random entry" button on Wiktionary. bd2412 T 15:47, 21 May 2015 (UTC)
We should definitely have more explicit (specific, clear, or detailed) images on Wiktionary. Could we perhaps have a video of kittens - there must be some somewhere on the Internet. SemperBlotto (talk) 06:36, 21 May 2015 (UTC)
Very funny... --WikiTiki89 15:11, 21 May 2015 (UTC)
I was all for giving end users control over image display Wikimedia-wide, but that proposal generated a lot of heat and failed. As was pointed out, the Wikipedia article does have images that appear promptly on loading.
If your work is going to blow up over the appearance of a penis on a Wiktionary page about penises, then you might want to consider turning off images on Wikis altogether, given that there is no editorial control over where images of penises will show up.
What's explicit? I believe that Germans would find that picture on penis a lot more acceptable then the picture on swastika.
There are a number of dictionaries that use images to define words instead of more words, and few dictionaries that don't use images at all. (I don't honestly think there are many people who could need to look up penis who would find a definition in formal English useful in the least.) One of Wiktionary's advantages is that we aren't space-limited to what's absolutely necessary, that we can afford to illustrate every single article if we choose. So yes, I do think illustrating penis is absolutely dictionary-like, and in fact more useful as a definition then the definition itself.--Prosfilaes (talk) 16:08, 21 May 2015 (UTC)
Remember, this isn’t just about the entry for penis. It’s about general policy. Recently somebody thought that the entry ejaculation needed an illustration File:Ejaculation educational ani short reboot.webm. I removed it because of several reasons. First, I think the written definition is clear and that the graphic image added nothing of value. Second, a lot of people (especially older Americans) would find such an illustration extremely offensive. Third, for anyone who needs more information and content than we as a dictionary would naturally offer, Wikipedia is only a click away. Fourth, while there are some picture dictionaries around, such dictionaries usually confine themselves to more mundane and uncontroversial terms, and I would never expect a picture dictionary to have a photo image of a penis or ejaculation. If a picture dictionary were found to offer the word penis, I’m certain that the picture would only be a rough drawing, a sketch (but I would be very surprised if any picture dictionary had the word penis or ejaculation in it at all). And fifth, in my long experienced with dead tree American dictionaries and encyclopedias, it’s only the encyclopedias that have pictures of penises.
I think that if a definition is not sufficiently clear (as in the case of articles of clothing worn by other cultures: burqa, hijab, dashiki, sarong, sari), then illustrations are important. Many words simply are not very compatible with illustration (e.g., verbs such as go or consider). Most words are easily defined with words alone, and images are really not needed. And a lot of people feel that some words (such as many of those involved in sex acts or bodily functions) are offensive enough to see in print, and would be horrified to see photos or videos of them.
As I said, this isn’t just about the word penis. Opening this up to all sorts of images for any entry could turn some of the words we define into pornography. I don’t think we need these kinds of images, and a link to Wikipedia should be more than sufficient. —Stephen (Talk) 17:18, 21 May 2015 (UTC)
Further to my comment: I see that Wikitiki89 was so bothered by the image of ejaculation that he changed it from a visible image to a mere link. So be sure to click on File:Ejaculation educational ani short reboot.webm to see the image that actually appeared on ejaculation, and would reappear there if this becomes the new policy. —Stephen (Talk) 17:31, 21 May 2015 (UTC)
I think that we can take into account the propensity for words to have more than one meaning, and to have most common meanings. I would agree that the illustration in question is a bit much for ejaculation, in no small part because the word has a long history as having a non-sexual meaning equivalent to exclamation. Penis, on the other hand, overwhelmingly primarily means the sex organ. Words like penis, vagina, testicle, vulva, vas deferens, foreskin, clitoris, and so on, should not reasonably be expected to have any primary connotation other than the sex organ, and should be every bit as well illustrated as elbow, orangutan, or piano. bd2412 T 18:22, 21 May 2015 (UTC)
  • Points to note:
    1. There are multiple ways to land on any given entry page.
    2. Non-English entries may also have images.
    • Ergo, we cannot assume that the user landing on any given page knew what they were about to see when they clicked the link.
I am unsure why there seems to be such resistance to the idea of having collapsible divs for images. bd2412, in your replies to me, you appear to be voicing opposition. Can you (or anyone else) articulate why? ‑‑ Eiríkr Útlendi │ Tala við mig 20:45, 21 May 2015 (UTC)
I believe that we should strive to provide illustrations for things to the greatest degree reasonably possible, since illustrations can be highly informative, and our having them is a quality that sets us apart from both paper dictionaries (which tend to be sparsely illustrated, if at all) and from other online dictionaries. Even mirrors that scrape Wiktionary tend not to copy our images. I respect that we should not shock readers by, for example, including a picture of a penis at rod or cock or a picture of buttocks at bum. However, for terms for which the clear and overwhelmingly primary meaning is a part of the human anatomy, we should illustrate them accordingly, and should not place barriers of censorship to readers looking up these entries. bd2412 T 21:01, 21 May 2015 (UTC)
  • I agree with your sentiment that we should avoid censoring.
That said, I don't think that collapsible divs equate to censorship. The image is still there on the page, just not displayed until the user opts to display it.
I'm also concerned about the apparent assumption that a user already knows the meaning of a term before clicking through to the entry, and that the user should therefore not be surprised by any images in that entry. I don't think these are safe assumptions. ‑‑ Eiríkr Útlendi │Tala við mig 21:35, 21 May 2015 (UTC)
Someone could encounter a word spelled penis in a foreign language text and want to look it up to see what it means. This person might be a native English speaker and thus familiar with the word's meaning in English. Furthermore, this person might even suspect that this foreign word has the same meaning. But this person still might not want to see an image of a penis. I don't buy any argument that says that just because you know what a word means that you would be expecting to see an image of it. Can someone explain to me how collapsing the image of a penis would be detrimental to Wiktionary? --WikiTiki89 21:41, 21 May 2015 (UTC)
Even if the meaning is known why risk a new possible translation or derived term etc.?--Dixtosa (talk) 22:13, 21 May 2015 (UTC)
Why stop at penises, then? There are some cultures where other body parts are taboo, like the elbows, the feet, the top of the head. In some cultures the picture I just added to forehead would be bound to offend someone. Some people are bound to be offended by the picture at bikini. The pictures at steak and hot dog, or even at cocaine, may be more offensive or upsetting to some people than a picture of a penis. When we collapse an image we put ourselves in the business of deciding whether there is something broadly and inherently offensive about the image. I don't think we want to get into that business. bd2412 T 22:22, 21 May 2015 (UTC)
  • Why stop at penises, then?” I'm not sure why this is a problem. If someone finds an image objectionable, they can add a collapsible div around it. That also answers your concern in saying “I don't think we want to get into that business” -- this is an open wiki, so anyone can edit, so the "we" here is anybody: there is no onus on you or me to decide by fiat what is "acceptable". That can be an emergent and evolving judgment call that is left to the user / editor community. ‑‑ Eiríkr Útlendi │Tala við mig 01:11, 22 May 2015 (UTC)
  • Because that is a hugely POV way to solve the problem, and not how we handle objectionable words.--Prosfilaes (talk) 01:13, 22 May 2015 (UTC)
  • 1) This is about images, not words, so how we handle objectionable words isn't entirely relevant. 2) In this collapsible div proposal, nothing is removed. This is about on-page layout. I'm not sure how that's POV any more than providing different CSS for high contrast or larger font sizes. 3) We already make culture-based judgments in defining terms (proscribed, profane, derogatory, etc.). 4) Would you object to instead offering a user-configurable way for *all* images to be collapsed until the user clicks on them? This would moot any possibility of subjectivity regarding which images are affected. ‑‑ Eiríkr Útlendi │Tala við mig 01:23, 22 May 2015 (UTC)
  • There are some cultures where other body parts are taboo...BD2412, this is the ENGLISH Wiktionary. The Chinese, Russians, and the rest can manage their linguistic taboos however they like on their own wiktionaries. In fact, the Russian Wiktionary puts a warning banner at the top of pages that might be offensive to Russian readers. Here we only have to consider the cultural taboos of the English-speaking nations. —Stephen (Talk) 01:41, 22 May 2015 (UTC)
The "cultural taboos of the English-speaking nations" covers a lot of ground, and at least some members of most of the cultures of the world. How, exactly, are we supposed to decide what cultural taboos are widespread enough to require special treatment? bd2412 T 01:46, 22 May 2015 (UTC)
I disagree. What countries are you counting? I think we’re only talking about the U.S., Great Britain, New Zealand, Canada, South Africa, and Australia. As far as I know, we share the same linguistic taboos, with very few exceptions. The main difference is in degree. Countries such as India have their own wiktionaries and wikipedias for the various languages spoken there...we do not have to be concerned about their elbows. —Stephen (Talk) 01:57, 22 May 2015 (UTC)
Firstly, I would say that virtually every culture in the world is represented by communities living in the United States. Secondly, the fact that countries like India have various languages does not remove English from being among the languages spoken there. bd2412 T 02:47, 22 May 2015 (UTC)
First, our definition of pornography is amazingly broad; Wikipedia starts with "Pornography ... is the portrayal of sexual subject matter for the purpose of sexual arousal" and that last clause seems crucial to the meaning. Illustrating every page in the dictionary could not turn it into pornography. Nor, frankly, is anything we're likely to put up likely to be pornographic in practice.
I see that for all the concern about offensiveness, nobody has responded to the depiction of the swastika, despite that possibly being so offensive to be illegal in some countries. Nor did you respond to my point that a definition in formal English of penis is basically useless for any English speaker; either you know the word already, or you need it defined in other terms (wee-wee, ding-dong, cock) or you need an illustration.
And as for other words, bd2412 has some good ones; vas deferens and clitoris are in vital need of illustration; words are not sufficient there.--Prosfilaes (talk) 01:13, 22 May 2015 (UTC)

I am retreating to complete removal of them in favor of collapsible divs. These div's can be made hidden by css or a gadget. It seems this is how far we can get...--Dixtosa (talk) 22:13, 21 May 2015 (UTC)

  • Support selective collapsing with NSFW warning. I could imagine that we might want other warnings for some images. DCDuring TALK 23:37, 21 May 2015 (UTC)
I'm really late to this party but I oppose censorship. This does not mean that explicit images should always be used. They should just go by the same rules as non-explicit images. The one at penis first of all isn't explicit, it's just a picture of a human penis, and it doesn't interfere with any text or templates, so keep it. I say remove images when they add no value or interfere with text and/or templates. Definitions have to come before images. Renard Migrant (talk) 21:20, 22 May 2015 (UTC)
  • Within this thread, there appear to be two main ideas under discussion: removing possibly explicit images, and keeping the images but adding collapsible divs. Renard, would the addition of collapsible divs constitute “censorship” by your definition? (Honest question in search of clear understanding.) ‑‑ Eiríkr Útlendi │Tala við mig 22:15, 22 May 2015 (UTC)
I also proposed to collapse all images indiscriminately. _Korn (talk) 00:06, 23 May 2015 (UTC)
Are we going to collapse the image at pencil because some people might be taken aback to see a picture of a penis at penis? How are we going to inform the reader of the presence of the collapsed image on the page, without making it intrusive? Create new section header for ====Images====? bd2412 T 04:03, 23 May 2015 (UTC)
Why not? We're collapsing the image at penis because someone might be taken aback by a picture of a penis. (Yes, yes, I'm well aware that for many users a penis isn't a pencil. I pointed out above that I'm in the camp which sees no difference.) I think it's the best course for everybody's blood pressure, to treat all images equally to prevent discussions and animosity over the different levels of offendedness. _Korn (talk) 09:42, 23 May 2015 (UTC)
No putting in boxes would not constitute censorship IMO. Renard Migrant (talk) 11:35, 23 May 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────I think a collapsed image is also a safety feature. An image of a penis that is just a depiction of nudity is not obscene in my opinion; other images of a penis that depict more than nudity could be obscene in my opinion. So what do you do when someone edits the image source into an image hotlinking from a porn site. Can that happen? While the voting in both the open RFD and open RFV about pedophilia seem to think otherwise, various acts and depictions of pedophilia are criminal in the Western world. Even if the criminal sense of pedophilia is excluded by the wiktionary community from the entry, any depiction of pedophilia would still be criminal. I hope these penis discussions are not a slippery slope to one day promoting images of different kinds of pedophilia on wiktionary as depicting feelings of pedophilia. Some depictions even without nudity should categorically be excluded. —BoBoMisiu (talk) 15:44, 23 May 2015 (UTC)

According to Wikipedia, "[i]n logic and critical thinking, a slippery slope is a logical device, but it is usually known under its fallacious form, in which a person asserts that some event must inevitably follow from another without any rational argument or demonstrable mechanism for the inevitability of the event in question". This is an example of such a logical fallacy. bd2412 T 19:47, 23 May 2015 (UTC)
@BD2412: do you think my first premise is false? This is a discussion about all explicit images and not just a particular depiction of a penis. Yes/no? —BoBoMisiu (talk) 20:09, 23 May 2015 (UTC)
We are not going to include images that are broadly illegal, and we are not going to include images that are not germane to the term being defined. bd2412 T 20:49, 23 May 2015 (UTC)
I am not writing clearly again, sorry. I think the particular depiction found in the penis entry is not obscene but should be collapsed. Some depictions of penis are obscene and criminal, for example, depictions of penis which are pedophilia. In my opinion, any pedophilia depiction, in any entry, is unacceptable even if it is germane to term being defined and legal. Separately, some depictions (of an allegorical feeling of pedophilia for example) even without nudity should categorically be excluded because they are obscene regardless of open RFDs and open RFVs about the the criminal sense of pedophilia. In other words, I am saying any depictions (explicit and not explicit) of pedophilia are unconscionable for me – even if the criminal sense of pedophilia is excluded by the wiktionary community, even if the depiction is germane, even if the depiction is legal. —BoBoMisiu (talk) 22:28, 23 May 2015 (UTC)
With respect to pedophilia, then, it would not matter whether an image was collapsed or not, would it? You would agree, I think, that we should not have an image illustrating pedophilia even if all the images in the dictionary are collapsed, from pencil to penis? bd2412 T 00:01, 24 May 2015 (UTC)
As I said, any depictions (explicit and not explicit) of pedophilia are unconscionable for me even if the depictions are germane and legal, and I think the particular depiction found in the penis entry is not obscene but should be collapsed. —BoBoMisiu (talk) 00:48, 24 May 2015 (UTC)
  • Having an image of an actual human genitalia could affect rating of the entire wiktionary.org domain by parental control/web protection/government filter software. Just the other day Internet pornography was banned in Egypt by a court. Billions of people and potential ESL learners live in countries where Web is a carefully monitored platform. This can easily be solved by replacing the disputed image with the one of a drawn penis. Wikimedia projects are not a political platform for advocating free speech (which doesn't exist in most countries anyway). The priority must be given to spreading information. --Ivan Štambuk (talk) 23:50, 24 May 2015 (UTC)
By that token it seems we ought to remove mentions of Taiwan and Tibet, to stop us getting banned in China. Equinox 23:59, 24 May 2015 (UTC)
Mentions of Taiwan and Tibet are not banned in China. For disputed regions/countries both viewpoints can easily be balanced in definitions. For images the issue *is* black and white (it's a classification problem), so the lowest common denominator must be followed. --Ivan Štambuk (talk) 00:33, 25 May 2015 (UTC)
But nobody cares about swastika and South Korea (half of a nation that covers all of the Korean Peninsula; on this, North and South Korea agree). The lowest common denominator is not acceptable in any way; we are not blocking out all pictures of women on Wiktionary.--Prosfilaes (talk) 01:39, 25 May 2015 (UTC)
By "lowest common denominator" I meant this: a single page with an explicit image can ruin the rating of the entire website. The question is simply: is the website safe or not. That's how filters work. Not sure what you meant by "blocking out all picture of women", this only pertains to explicit images. The technology to filter individual images by their detected content is only available to Google and similar who have powerful datacenters that can analyze them on the fly. --Ivan Štambuk (talk) 22:08, 26 May 2015 (UTC)
If a single page with an explicit image ruins the rating of the entire website, then they should block us. That's what being a wiki implies, that we can't guarantee that our website is safe. You're being ethnocentric; An American newspaper removed Hillary Clinton from a photo because it's not appropriate to print photos of women.--Prosfilaes (talk) 23:01, 26 May 2015 (UTC)
A good illustration of a penis is just fine, IMO. Illustrations can have a lot of advantages over photos.--Prosfilaes (talk) 01:39, 25 May 2015 (UTC)
We are not the Chinese Wiktionary, we are the English Wiktionary. We are not here for China. If China wishes to ban us, it’s their loss, it does not affect us. We should not be concerned about how governments of countries whose main language is not English think of us. —Stephen (Talk) 15:08, 25 May 2015 (UTC)
We are here for anyone wanting to use us; right now, that's restricted to the people of Earth, but there's no need to restrict it further. If China bans us, it does affect our users and editors. And as a response to me, ban or no ban, illustrations can be clearer then photos, especially when there's a bunch of labels.--Prosfilaes (talk) 21:33, 25 May 2015 (UTC)
I have no strong objection to using an illustration rather than a photograph at penis; that said, however, the photo currently there is labelled, and there's no technical reason why we could not have both (see flower for example). bd2412 T 02:49, 26 May 2015 (UTC)
I completely agree with Ivan on this. We are here to provide definitions of words to as many people as we can, not to spread free speech propaganda (even if we all support free speech). --WikiTiki89 15:44, 26 May 2015 (UTC)
I too agree with Ivan. We are not losing only ESL learners (every language can have images, right?)
Hitting a user with an explicit image unexpectedly is so unthinkable. When I read the discussion I kinda get a feeling that general opinion about explicit images is actually not that they are gross to many. I personally use Wiktionary as a primary dictionary and if I were not a contributor and got welcomed with this kind of image even only once, I would switch to any other online dictionary.
The very similar problem was put in front of Google. Polluting the very first page of Google has been thought to be risky I guess. See for yourself: finger, hand, head and elbow all have images, while neither penis nor vagina have any.
The Taiwan and Swastika examples are poor parallels, because they do not depict anything gross.
BTW, we can't and shouldn't strive to attain ultimate fairness.--Dixtosa (talk) 17:05, 26 May 2015 (UTC)
This is a Wikimedia project, not a Google project; Google has no mission to educate readers; it is merely a for-profit service that provides search results as a way to get consumer eyes on the advertisements of its paying customers. Compare your Google results for "penis" with the Wikipedia pages for w:Penis and w:Human penis in particular. Also, feeling that a penis is "gross" is a subjective value judgment. There are plenty of people who would find the swastika to be more "gross" than the penis. I personally find the eggplant to be more "gross". bd2412 T 17:23, 26 May 2015 (UTC)
Heh, I feel like I've travelled back in time to the Victorian era, when body parts were disgusting. Equinox 17:24, 26 May 2015 (UTC)
@BD2412, This is a Wiktionary project, not a Wikipedia project. BTW, you missed the point. The point was that only conscious clicks should lead to gross stuff. For example, going to Google images is a conscious click.
What's your stance on the entry of ejaculation? I'll add the aforementioned video on both ejaculation and cum. Is that OK? --Dixtosa (talk) 18:01, 26 May 2015 (UTC)
Read up and you will see that I have already expressed my opinion in this thread about ejaculation. bd2412 T 18:04, 26 May 2015 (UTC)
I've read that. I am asking you again because your arguments are outdated - you talked expectations, which I think we have already been through: we can't assume anything about the user. --Dixtosa (talk) 18:16, 26 May 2015 (UTC)
Nonsense, we know a lot about the user. We know that the user has a computer and knows how to get on the Internet, and speaks English well enough to either search English Wiktionary for something, or to search Google (or a comparable search engine) and click on a result that takes them to an English Wiktionary page. We also know that our user has enough interest in the word they are looking up to bother looking it up (unless they are clicking for random pages, in which case I have little sympathy for their hitting the one-in-four-million chance of landing on a page that offends them). Based on this analysis, my response with respect to ejaculation still stands. bd2412 T 18:57, 26 May 2015 (UTC)
No. We know that the user owns a device, speaks any language as native, understands English (but not necessarily), seeks definitions (but not necessarily), looks up any term in any language. --Dixtosa (talk) 19:21, 26 May 2015 (UTC)
If they don't speak English well enough to have both the ability and the motivation to look up terms in an English dictionary, then they are outside our scope. bd2412 T 19:31, 26 May 2015 (UTC)
Someone might want to see synonyms only. This does not need English. But I understand that this is rare and this is why I put it in that way.
So, excluding the part where English is not assumed, you agree with me? Then which part of it makes you think the user knows the major context where it is used? --Dixtosa (talk) 19:56, 26 May 2015 (UTC)
For terms of sexual anatomy (penis, vagina, testicle, clitoris), there tends to only be one context. In fact, if you look down the page at penis, you will see that in virtually every language out of the 21 languages on the page, penis only means the male sex organ (the only exceptions that I can see are an Esperanto conjugation, and Latin, which has the sex organ among a few other meanings). bd2412 T 20:18, 26 May 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── You have lost me somewhere. What is the major context of ჩუკენო (č’ukeno)? You don't know, just like I do not know the context of cum. --Dixtosa (talk) 21:32, 26 May 2015 (UTC)

If I have lost you somewhere, then there is no point in continuing this line of discussion. I will say, however, that cum is Latin for "with", and has many other meanings in many other languages, so it is far easier to conceive of arriving at that page with no context for any one specific meaning. bd2412 T 22:12, 26 May 2015 (UTC)
I am so glad that a piece of anatomy shared by half of humanity is upsetting to you and the symbol of an organization that murdered 10 million people just because is not. Some people disagree. An American newspaper removed Hillary Clinton from a photo because it's not appropriate to print photos of women. Your standards of "gross" and "explicit" are not universal.
Taiwan was used as an example of something that could get us blocked. If we're not concerned about that, that changes a lot of the justification for doing this.--Prosfilaes (talk) 23:01, 26 May 2015 (UTC)
  • Another thing to keep in mind is that scientific terms for genitalia and parts thereof are also used as defining terms for a countless number of their vulgar and polite counterparts, most of which in every language have at least half a dozen figurative meanings and rank very high in frequency of usage. You could easily land on the page for penis if you're translating texts ranging from a poem, newspaper article or a youtube comment. Displaying an embedded Wiktionary definition for some of the upstream projects merely requires hovering a mouse over a word. Some (like GoldenDict) even auto-expand collapsible boxes. --Ivan Štambuk (talk) 22:25, 26 May 2015 (UTC)
    As an advocate in general of free-speech and of ostensive definition, which usually means images, I am loath to prohibit any class of images. In this case, however, I agree with Ivan. Providing the opponents of free speech a pretext for blocking Wiktionary that many parents and others would agree with seems counter to the free-speech cause as well as the purpose of Wiktionary. I had thought that hiding images by default would be sufficient, but I doubt that is true. I'd agree with limiting some pages to drawings or even just to links to WikiCommons. That even these could be used as a pretext to block Wiktionary is true, but I think fewer would agree that the pretext was legitimate for, say, labelled drawings and links. I could imagine some photos with labeled components being acceptable. I think there will have to be judgment applied, despite the laborious procedure for reaching a decision on this kind of thing. DCDuring TALK 22:48, 26 May 2015 (UTC)
If you're translating texts from a YouTube comment, you're exposing yourself to material that's much worse then any picture we could possibly use. Gross, offensive, and sometimes even more explicit. I don't think we can worry about some program that auto-expands collapsible boxes; if someone wants to shoot themselves in the foot, we can't stop them.--Prosfilaes (talk) 23:01, 26 May 2015 (UTC)
For the sake of opinion gathering, here's mine: I agree with the shooting in the foot thing. Also, there are 7 billion in 200 countries. If we try to please everyone, we'll end up cutting our own flesh sooner or later. While the topic of nudy pics might not be a slippery slope, the path of 'we must do everything in our might to prevent losing readers' certainly is one. Where would you draw the line for our appeasement of the men at the red buttons? Korn [kʰʊ̃ːæ̯̃n] (talk) 23:30, 26 May 2015 (UTC)
I'd be interested in which clothing-wearing cultures have mainstreams that favor pedophilia (pre-pubescent children) and sex education for pre-pubescent children. Parents that are liberal enough to normally permit children to have access to WP and Wiktionary are not necessarily supportive of having the children get their sex education from Mediawiki projects. (I wonder what they would say if they know about Wikicommons.) DCDuring TALK 23:41, 26 May 2015 (UTC)
Ah, yes Think of the children! What about the parents who would not want their children reading a dictionary that contains entries for fuck and cuntface and cockfucker? Shall we roll out the flamethrower to censer these potentially offensive words? bd2412 T 23:56, 26 May 2015 (UTC)
Paidaeia is most important function of most mammalian societies, so I think we could stand to give it some consideration.
I think the judgment we make is how legitimate-looking a pretext do we provide to authorities willing and able to block access to Wiktionary relative to the utility of the image. I'm sorry that the judgment I propose cannot be made on logical deduction from first principles, but few important judgments can be so made. DCDuring TALK 00:11, 27 May 2015 (UTC)
I think that any authority willing to block us for having an image of a penis on penis should block us for potentially having an image of a penis on dog. We're a wiki that lets anonymous users insert images from Wikimedia Commons, and has a bunch of links to Wikimedia Commons for users to find any number of offensive images.--Prosfilaes (talk) 00:29, 27 May 2015 (UTC)
Pedophilia and sex education for pre-pubescent children have nothing to do with each other; in fact, the latter is frequently designed to help protect children against sexual abuse. President Obama said sex education for kindergartners was a good thing; the New York Times published an op-ed from the chief health officer of Chicago Public Schools explaining that kindergartners should know what we're showing them, the names of the various external genitalia.
Quite honestly, who sends their pre-pubescent children to Wiktionary? Besides BD2412's concerns, look at dog--"See also: DOG and dög", a lengthy table of contents,
Alternative forms darg, dawg (dialectal); doggie, doggy (childish)
Pronunciation (Received Pronunciation) IPA(key): /dɒɡ/ (US) IPA(key): /dɔɡ/ (US, Canada, cot–caught merger) IPA(key): /dɑɡ/ Rhymes: -ɒɡ
Etymology From Middle English dogge, from Old English docga (“hound, powerful breed of dog”), a pet-form diminutive of Old English *docce (“muscle”) (found in compound fingerdocce (“finger-muscle”) with suffix -ga (compare frocga (“frog”), picga (“pig”)). Cognate with Scots dug (“dog”). The true origin is unknown, but one possibility is from Proto-Germanic *dukkǭ (“power, strength, muscle”), though this may just be confusion with dock. In the 16th century, it superseded Old English hund and was adopted by several continental European languages.[1]
and finally a definition
A mammal, Canis lupus familiaris, that has been domesticated for thousands of years, of highly variable appearance due to human breeding.  
which is stunningly helpful for any young child looking things up. I'm not sure we're not driving away adults; I certainly wouldn't send my second-grader here.--Prosfilaes (talk) 00:23, 27 May 2015 (UTC)
Paedophilia and sex education for the prepubescent have exactly one thing in common: prepubescent children, perceived threats to whom engender most ferocious responses from outraged parent-citizens and some authorities.
IMO, it's not a question of sending a child here, or even of the effect of a child seeing the images; it's a question of providing a pretext for blocking access to Wiktionary from a public library or a school, say a middle or high school (grades 5-12 in US), or at a place of work. DCDuring TALK 01:14, 27 May 2015 (UTC)
In my opinion, if you're going to object to penis having a picture of a penis, then us being a wiki editable by anonymous individuals who can add pictures of penis to any random page should be enough of a pretext. Maybe it would be different if we installed accepted revisions like de.WP and others do, but we haven't.--Prosfilaes (talk) 01:37, 27 May 2015 (UTC)
FWIW, on de.Wikt de:Hakenkreuz does not contain an image of a Nazi swastika, but de:Eichel does contain illustrations of all of its senses, namely "acorn" (the primary sense), "glans penis", and "clitoris". de:Taiwan ad de:Südkorea contain flags and maps. de:Mann and de:Frau contain a drawing of a naked man and woman, respectively. de:Anus contains a picture of an anus, but the picture is too zoomed in to be useful IMO (it doesn't help to clarify where the anus is). - -sche (discuss) 00:14, 27 May 2015 (UTC)
@BD2412 you are conflating this discussion. It is about images and not about potentially offensive words. Most people expect words in dictionaries and, in my opinion, most people do not expect explicit images in dictionaries. —BoBoMisiu (talk) 03:26, 27 May 2015 (UTC)
@DCDuring, Prosfilaes allowing a child to use wiktionary would be a poor choice for any parent – I will never recommend it because contributors impose their values through removal of senses with well attested usage (e.g. pedophilia) that they disagree with. A parent shouldn't trust it for that single example of intolerant censorship alone, in my opinion. —BoBoMisiu (talk) 03:26, 27 May 2015 (UTC)
@-sche and a caudal view of an anus conveys much less information than an illustration of the digestive system. —BoBoMisiu (talk) 03:26, 27 May 2015 (UTC)
@Korn, Ivan Štambuk, Dixtosa my sister blocked wiktionary at her firewall after I asked her to read the pedophilia discussions, the open pedophilia RFD, and the open pedophilia RFV over the weekend. She also blocks sites for explicit images that her kids might use. Knowledgable consumers act decisively to do what websites balk at doing. —BoBoMisiu (talk) 03:26, 27 May 2015 (UTC)
@Dixtosa, BD2412 people learn by clicking links to terms they want to understand especially if they have no idea what that term means until they land on the page. Those people are interested in the text – to learn from the text. —BoBoMisiu (talk) 03:26, 27 May 2015 (UTC)
@BoBoMisiu We can't entirely assume that any supervisor of children (a parent, teacher, librarian, or governmental authority) has perfect control of them. The use case that concerns me is not the case where a child is successfully prevented by some supervisor from using Wiktionary, but rather the one where they are not prevented until the supervisor gets wind of gratuitously inappropriate content and eliminates access to Wiktionary entirely for the supervised group.
We can make sure that the most likely entries for placing inappropriate content are patrolled and even put limits on editing them. We can use filters to draw attention to commons or external links and included image files. DCDuring TALK 04:47, 27 May 2015 (UTC)
As long as a totally natural, biological, evolved thing that I was born with, and had no choice over, is "gratuitously inappropriate content", I will support it until my dying breath. Seeing a picture of a dick won't kill a child. Equinox 01:16, 28 May 2015 (UTC)
I understand your position is staunchly held, albeit unreasoned. It also failed to note that my concern is not for the welfare of children of any age exposed to the images, but for the reaction of those who have or claim to have responsibility for them to any images that they deem inappropriate and which may cause them to place limits on access to Wiktionary. My concern is for the welfare of Wiktionary. DCDuring TALK 03:06, 28 May 2015 (UTC)
What about the people who will deem the image at bikini inappropriate, or the images at areola, gluteal cleft, lingerie, bra, and navel? Why would we give any more consideration to people objecting to images than to definitions? I would also note that I paged through my print copy of Webster's dictionary, and found that there was an image or two every few pages throughout the book. Images are useful in defining terms, and other dictionaries lack them precisely because they are on paper, or have inherited the traditions of paper dictionaries. I also have a "visual dictionary", which, in the anatomy section, provides illustrations of the penis and vagina. We are not breaking new ground here, we are just covering it more thoroughly. bd2412 T 03:45, 28 May 2015 (UTC)
People who want to censor things can use censorware. People who want to learn, understand, read, and study things can use this wiki. DCDuring, who obviously has some terror of the penis, is welcome to put it in a fucking collapsible box. Human beings will continue to be born with penes long after he has died. Hopefully, the shit we have spent years writing on Wiktionary will also continue to be used long after we have all died. Sorry. I wasn't consulted. Sorry about having a penis. Equinox 04:21, 28 May 2015 (UTC)
Again, we're a wiki with no protection against the edits of anonymous editors. Should someone feel that a photo on penis page is worth blocking us over, they should block us, because we can't guarantee that dog won't have worse.--Prosfilaes (talk) 14:22, 28 May 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I've read this whole, pretty inconclusive discussion, and have finally come to an opinion. I propose that we include all pertinent images, collapsed by default, with an easy tie-in for censorware so that it can block all images with one simple option. I think that this is the best compromise position. I am happy to justify my opinion to those who disagree. — I.S.M.E.T.A. 09:23, 28 May 2015 (UTC)

Yay, someone took my stance. I'd also like to mention that conservative Jews and Muslims are likely probably block us for having an image at woman. Dem slopes can be slippery. Korn [kʰʊ̃ːæ̯̃n] (talk) 10:09, 28 May 2015 (UTC)
@Korn: Yes, that Chassidic newspaper was an eye-opening example. It isn't just a theoretical difficulty that we face in deciding just which images will be used as blocking pretexts. Making it easy for a censor to block all images would probably appease most people concerned about the possibility of explicit (with whichever definition) images appearing (having blanket blockability also means that no one can sneak in an uncensored explicit image by vandalism onto the page for, say, apple). — I.S.M.E.T.A. 10:20, 28 May 2015 (UTC)
It is easy already to not show any picture with a little css (via a gadget): .thumb { display:none; }. It would also be really easy to have a show/hide button for all pictures. — Dakdada 13:07, 28 May 2015 (UTC)
I would suggest as a compromise that we default to showing images, and hide only those images that the community determines by consensus could reasonably be objectionable. I am willing to go along with the suggestion by Equinox above to "put it in a fucking collapsible box" if it's really that much of a problem. However, I certainly don't want to put readers to the task of finding and clicking a "show" button to see a serviceberry, an armadillo, or a baglamas. bd2412 T 13:54, 28 May 2015 (UTC)
I think this has been argued to death, but the simple truth is that Wikimedia projects aren't censored, and we can't be in the position of deciding what is an inappropriate image. After all, some Muslims would object to any depictions of deities or of anything that might be considered a deity, which is why there's lots of historical Muslim architecture with nothing but abstract ornamentation. If we want to hide things, we should hide everything, with an option in preferences to display everything, and a link on the collapse-box to an explanation of the policy. There's lots of content in Wiktionary that I dislike, but we can't be truly descriptive if we don't include it. Images are less critical to our mission, but we shouldn't be deciding about them based on our personal feelings (of course, we should avoid unnecessarily provocative content that doesn't serve the needs of the entry- but then, I've removed images added by a vandal obsessed with ceiling fans, too). Chuck Entz (talk) 14:07, 28 May 2015 (UTC)
I completely disagree that Wikimedia projects aren't censored, they are rigorously censored. There is a reason we don't have an image of Goatse on the page for shock site, and that Wikipedia doesn't have such an image on their page for Goatse. It would be very illustrative, but we have made the determination that it would not be of benefit to the project as a whole (even if we have done so tacitly. In my mind this isn't a question of censorship on the grounds of dictating our morality, it is a question about making the project the most useful to the most people. The project becomes useless to anyone who sees something objectionable to them and never returns, or to those who have the project blocked due to content which some blocking service finds objectionable. I don't want to change the policy about which images are included, I think we do a good job there; I do want to give the users more control over which images they see by default. - TheDaveRoss 14:55, 28 May 2015 (UTC)
@TheDaveRoss I agree with you and add that the wiktionary community excludes criminal senses of terms that some contributors find objectionable (e.g. that pedophilia is a crime). Also an explicit depiction is not just about nudity or a sexual subject – it is also about violence, for example beheading and other forms of murder. Every coworker I asked today said they block wiktionary completely at work for those kinds of depictions collapsed or not. Like I said before, an informed consumer will do what websites balk at doing and block the entire site because anything else is just too much work to filter. Once wiktionary gets added into proxy or firewall host files and such it will never be seen again on connecting device. —BoBoMisiu (talk) 16:50, 28 May 2015 (UTC)
@Darkdadaah: I agree re the show/hide button for images (something akin to the toggles for quotations, translations, derived terms, etc. currently in the sidebar?). Is that CSS trick auto-implementable by external censorware?
@BD2412: I think it has been demonstrated pretty conclusively that we are unlikely to be able to come to consensus on these issues. Moreover, I doubt that our little community is sufficiently diverse to antecipate the full array of images that have potential to cause offence.
@Chuck Entz: I completely agree with your statement "If we want to hide things, we should hide everything, with an option in preferences to display everything, and a link on the collapse-box to an explanation of the policy."
@TheDaveRoss: On top of collapsing all images by default, it would probably be a good idea to include in the captions for explicit images a template such as {{explicitimage}} which would mark that collapsed image with some kind of obvious warning message.
@BoBoMisiu: We're obviously not going to host illegal content. That is an irrelevant non-issue.
 — I.S.M.E.T.A. 17:14, 28 May 2015 (UTC)
@I'm so meta even this acronym, BD2412 The discussion is not about whether you host illegal content but whether you display explicit content – these are two different concepts. An image search shows that there certainly is even legal public domain content depicting violence and beheading. —BoBoMisiu (talk) 17:48, 28 May 2015 (UTC)
@BoBoMisiu: Please link to these offending examples. — I.S.M.E.T.A. 17:52, 28 May 2015 (UTC)
—This comment is out of chronological order: @BoBoMisiu:, regarding your contention that "pedophilia is a crime", please show me one jurisdiction that has a statute defining the word "pedophilia" as a crime, distinct from specific crimes like sexual assault and child endangerment. I searched and couldn't find any, so if I have missed one, please enlighten me. bd2412 T 18:35, 28 May 2015 (UTC)
—This comment is out of chronological order: @BD2412: No, that is not the way I see other terms being defined in wiktionary. They are descriptions of usage — they show the living language. I added many examples of usage in Citations:pedophilia. Which examples that I added showing a criminal sense do you want to discuss? —BoBoMisiu (talk) 20:00, 28 May 2015 (UTC)
—This comment is out of chronological order: @I'm so meta even this acronym: No, I'm not going to link to these offending examples, lets discuss the general concept (explicit images of violence, e.g. beheading) which is neither vague nor overgeneralized. —BoBoMisiu (talk) 20:00, 28 May 2015 (UTC)
  • I concede that we have no interest in any censorship except that in accord with the few remaining prejudices we regular contributors have. We are poor judges of what others may find offensive, are unwilling to allow the opinions of those others to influence us, and are incapable of finding footing on a slope of even the most slope and slip. DCDuring TALK 18:14, 28 May 2015 (UTC)
@I'm so meta even this acronym no, I'm not going to reduce a general idea to a specific example or deny the correlative. Policies are general ideas not special pleadings. Most people think beheading is violence and don't need a specific example. —BoBoMisiu (talk) 18:34, 28 May 2015 (UTC)
@DCDuring I know that most people will look at and react to an image first and then decide if they want to read text. The entries in wiktionary should be accurate and precise enough so the consumer understands meaning then they can judge for themselves. —BoBoMisiu (talk) 18:34, 28 May 2015 (UTC)
@BoBoMisiu: You wrote "An image search shows that there certainly is even legal public domain content depicting violence and beheading." There's no such thing at beheading, so where are these images? — I.S.M.E.T.A. 19:08, 28 May 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────@I'm so meta even this acronym: No, you are conflating two different things:

  • I first wrote: an explicit depiction is not just about nudity or a sexual subject – it is also about violence, for example beheading and other forms of murder. I did not write that such a depiction is found in the beheading entry.
  • Then I responded to your statement about not going to host illegal content – I pointed out that this discussion is not about whether you 'host illegal content' but whether you display explicit content – these are two different concepts. An image search shows that there certainly is even legal public domain content depicting violence and beheading. I should have used a term like Google image search to be clear. —BoBoMisiu (talk) 20:00, 28 May 2015 (UTC)
@BoBoMisiu: I misunderstood you; I thought you meant that such images were already being displayed in Wiktionary entries. — I.S.M.E.T.A. 09:50, 29 May 2015 (UTC)

At this point we are talking in circles, going off on tangents, and achieving nothing close to a consensus. I propose that this discussion either be closed, or that a properly formatted vote on a specific proposal (or set of options) be started at Wiktionary:Votes. bd2412 T 20:32, 28 May 2015 (UTC)

I agree that we will never reach a consensus if something is not changed. We have to structurize the flow of discussion somehow, because ideally there shouldn't be any unanswered arguments. I am thinking of breaking the problem down into subproblems so that we can locate the controversial matter. It is easier to argue if something is gross or not, rather than whether images should be collapsible. A vote is just useless at this point. --Dixtosa (talk) 20:50, 28 May 2015 (UTC)
What proposals shall we vote on? I suggest:
  1. hide all images by default, for example in collapsible boxes which users can choose to expand (i.e. users can opt out of having images be hidden)
  2. continue to show images by default, but provide users with an opt-in gadget that will hide all images
  3. hide images (or just photographs, allowing drawings?) of genitalia (and breasts and anuses?)
  4. do not include images (or just photographs, allowing drawings?) of genitalia (and breasts and anuses?) at all
  5. do not include any images at all
There are certainly other possibilities (e.g. hide all images of women to appease ultraconservative Jews and Muslims), but I don't think anyone here has seriously entertained them, so I haven't listed them. - -sche (discuss) 20:56, 28 May 2015 (UTC)

Straw polls[edit]

Several important points to take into account:

  1. A word can mean something that is not explicit in nature but the entry might still contain explicit content. E.g. cum which in Latin means "with".
  2. We can not completely evade subjectivity altogether anyways: we still have to decide/debate
    1. which entries deserve a picture (as mentioned in the discussion ejaculate might not be the best target for the corresponding video)
    2. which images are unnecessarily provocative and obscene.
  3. We should please the majority rather than ourselves being happy about the idea of having no censorship
  4. Wiktionary can have its rules.
  5. Images being collapsed might not be sufficient to avoid being blocked in a software-controlled machine/browser.
    NOTE: if we make collapsed images load dynamically then this will trick the software.
  6. Wiktionary is a dictionary and our sister projects exist for a reason. (like Commons and Wikipedia)
  7. Deciding which images to hide might be problematic. (if selective censorship wins)
  8. The detriment caused by explicit content is more devastating than that of caused by collapsing them.

All images should be shown[edit]

Any image that is relevant and useful (for the purpose of defining or identifying a term) should be displayed uncollapsed.

  1. Symbol support vote.svg Support. Of course, we can always further discuss which image is the most appropriate and most effective for such a purpose. bd2412 T 21:27, 28 May 2015 (UTC)
  2. Symbol support vote.svg Support weakly. Thus, no images collapsed by default. However, images should be chosen with taste. --Dan Polansky (talk) 09:29, 31 May 2015 (UTC)
  1. Symbol oppose vote.svg Oppose --WikiTiki89 21:04, 28 May 2015 (UTC)
  2. Symbol oppose vote.svg OpposeUngoliant (falai) 22:34, 28 May 2015 (UTC)
  3. Symbol oppose vote.svg Oppose —Stephen (Talk) 22:52, 28 May 2015 (UTC)
  4. Symbol oppose vote.svg Oppose I think this provides excessive protection for any image whatsoever and creates problems in many settings at home, at work, and in public spaces for adults. DCDuring TALK 23:44, 28 May 2015 (UTC)
  5. Symbol oppose vote.svg OpposeBoBoMisiu (talk) 02:30, 29 May 2015 (UTC)
  6. Symbol oppose vote.svg Oppose --Daniel 09:25, 29 May 2015 (UTC)
  7. Symbol oppose vote.svg Oppose, priority should go to words, not to images. Images should not be used in case where it would compromise the use of words. Renard Migrant (talk) 20:56, 29 May 2015 (UTC)
  8. Symbol oppose vote.svg Oppose per almost all the points above and priority should go to words. --Dixtosa (talk) 10:33, 30 May 2015 (UTC)

All images should be collapsed[edit]

All images, even though they are relevant and useful, should be collapsed regardless of content, so that viewers can choose what they would like to see.

  1. Symbol support vote.svg Support Prevents arguing amongst the editors and hence saves everyone time. No consensus is ever going to fit every individual user anyway. Korn [kʰʊ̃ːæ̯̃n] (talk) 22:04, 28 May 2015 (UTC)
  2. Symbol support vote.svg Support I think this also focuses attention on all that eloquent text in the entries to dazzle the consumer.
    Crawling bots will still see the various collapsed image file names in the source code and possibly follow to the image and analyze the content. All of this only affects the presentation of the page to a human viewer and not the content of the page. I don't think collapsed images will affect the page load time at all. I also don't think it will have any affect on filtering since those will see both the page title, image label, etc. contains a trigger string (e.g. penis or beheading) and will funnel for that alone. Collapsing the images only affects what a human viewer initially sees. —BoBoMisiu (talk) 02:38, 29 May 2015 (UTC) modified 16:19, 29 May 2015 (UTC)
  3. Symbol support vote.svg Support — This: 1) speeds up page-loading time; 2) per Korn, saves a lot of time on RFD-style arguing; 3) is likely to appease concerned censors; 4) allows an image-blocking tie-in; 5) conforms with current treatment of quotations, translations, etc.; and, 6) is, IMO, the only practicable response in the light of the demonstrated variety of causes for visual offence that exists. — I.S.M.E.T.A. 09:50, 29 May 2015 (UTC)
    (1) You mean rendering time? images will still be loaded. (2) We don't know yet. (5) Hm... kinda appealing argument.--Dixtosa (talk) 14:05, 29 May 2015 (UTC)
    @Dixtosa: Oh. I thought that the image would only be loaded at expansion; can such a thing be arranged? — I.S.M.E.T.A. 00:20, 30 May 2015 (UTC)
    I'm so meta even this acronym, yes. I'll try to make a proof of concept of this. --Dixtosa (talk) 10:33, 30 May 2015 (UTC)
    @Dixtosa: Great. Thank you. :-)  — I.S.M.E.T.A. 13:52, 30 May 2015 (UTC)
    I can't think of a solution that does not use js. this js and this template together can make this work though.
    But remember images are not generally large. For example, the image in my sandbox is ~10KB but the whole sandbox is ~300KB. The only benefit is that we trick parenting softwares and hopefully do not get blocked right away. BTW, I am not completely sure that parenting softwares and work proxies work like this but anyways this is the best we can do. --Dixtosa (talk) 15:11, 30 May 2015 (UTC)
    @Dixtosa: The reduction in loading time may not often be very great, but things like maps, which need to have a high resolution, present a greater loading burden; in those cases, the difference could well be noticeable. In any case, this Javascript trick should be used for whatever images we decide to collapse, if that's what we indeed decide. — I.S.M.E.T.A. 17:30, 30 May 2015 (UTC)
    @Dixtosa: This is a bad way to implement this because the <img> element already has a srcset attribute. In such cases, common practice is to use the src attribute only as a fallback for old browsers. Using js will break responsive features. It is not good web design to bypass responsive features of HTML5 and CSS such as responsive image sizes. Your way still has a <div> element containing a data-img-src attribute that is visible in the source code. —BoBoMisiu (talk) 19:31, 31 May 2015 (UTC)
    @BoBoMisiu, my solution consists of following steps: you first wrap an existing usage of a file in the template, which makes an empty div with the attribute data-img-src. Then js inserts a button into the div. Then after clicking it the whole div is replaced with the html that software would have produced if the file had not been wrapped. Note, that data-img-src does not and cannot contain the actual link.--Dixtosa (talk) 20:03, 1 June 2015 (UTC)
  1. Symbol oppose vote.svg Oppose --WikiTiki89 21:04, 28 May 2015 (UTC)
  2. Symbol oppose vote.svg Oppose There is no need to subject the reader to an extra step, particularly when the vast majority of images are completely non-controversial. bd2412 T 21:28, 28 May 2015 (UTC)
  3. Symbol oppose vote.svg Oppose --Dixtosa (talk) 21:59, 28 May 2015 (UTC)
  4. Symbol oppose vote.svg OpposeUngoliant (falai) 22:34, 28 May 2015 (UTC)
  5. Symbol oppose vote.svg Oppose —Stephen (Talk) 22:52, 28 May 2015 (UTC)
  6. Symbol oppose vote.svg Oppose Many attractive images increase the over-the-shoulder appeal of Wiktionary. DCDuring TALK 23:47, 28 May 2015 (UTC)
  7. Symbol oppose vote.svg Oppose Per BD and DC. In particular, I hate having to take an extra step and I predict that I would rather not see the image than taking the trouble to un-collapse it. --Daniel 09:27, 29 May 2015 (UTC)
  8. Symbol oppose vote.svg Oppose because sometimes images don't get in the way of wording and collapsing them is just plain unnecessary. Renard Migrant (talk) 20:57, 29 May 2015 (UTC)
  9. Symbol oppose vote.svg Oppose No need. Purplebackpack89 17:33, 30 May 2015 (UTC)
  10. Symbol oppose vote.svg Oppose per Daniel and Renard. - -sche (discuss) 17:53, 30 May 2015 (UTC)
  11. Symbol oppose vote.svg Oppose per bd2412. --Dan Polansky (talk) 09:29, 31 May 2015 (UTC)

Some images should be collapsed[edit]

Some images, even though they are relevant and useful, should be collapsed if their content is likely to be offend, disturb, embarrass, or inconvenience viewers, at least in certain environments, such as the workplace or around children.

  1. Symbol support vote.svg Support --WikiTiki89 21:04, 28 May 2015 (UTC)
  2. Symbol support vote.svg Support I would support the collapsing of images that relate to only one of several senses of a term, and that might shock someone looking for another sense. bd2412 T 21:33, 28 May 2015 (UTC)
  3. Symbol support vote.svg SupportUngoliant (falai) 22:34, 28 May 2015 (UTC)
    @Ungoliant MMDCCLXIV Did you mean "support"? —Stephen (Talk) 22:53, 28 May 2015 (UTC)
    Yes. Thanks. — Ungoliant (falai) 01:08, 29 May 2015 (UTC)
  4. Symbol support vote.svg Support —Stephen (Talk) 22:52, 28 May 2015 (UTC)
  5. Symbol support vote.svg Support --ContraVentum (talk) 23:03, 28 May 2015 (UTC)
  6. Symbol support vote.svg Support Not necessarily good enough for some images. DCDuring TALK 01:17, 29 May 2015 (UTC)
  1. Weak Symbol oppose vote.svg Oppose. Let us find images or graphics and drawings that do not create the need to collapse them in the first place. --Dan Polansky (talk) 09:29, 31 May 2015 (UTC)

Some images should be removed[edit]

Some images, even though they are relevant and useful, are so obscene, offensive, or disturbing that we do not want them to appear on Wiktionary at all.

  1. Symbol support vote.svg Support in very rare cases — Ungoliant (falai) 22:34, 28 May 2015 (UTC)
  2. Symbol support vote.svg I would remove images of someone defecating, copulating, etc. If American broadcast TV (free over the air) wouldn’t broadcast it, I don’t think we should have it here. —Stephen (Talk) 22:46, 28 May 2015 (UTC)
  3. Symbol support vote.svg Support I suppose that would mean voted in each case, which means many images offensive to some will be included. DCDuring TALK 23:49, 28 May 2015 (UTC)
  4. Symbol support vote.svg Support I never thought of wiktionary as a picture book. While depictions make a page look attractive, I would deemphasize all of them to have a page that encourages the consumer to read the text instead of looking at the depictions. I don't think images are a selling point. Separately, I don't even think wiktionary cultivates a perception that senses in entries are not censored (or as believe, as long as they don't contradict the personal beliefs of administrators). I have not read anything about a process for a contributor to challenge a perceived case of censorship. Even if one of the USPs is non-censorship it is not put into practice from my non-administrator perspective. —BoBoMisiu (talk) 02:39, 29 May 2015 (UTC) modified 23:47, 29 May 2015 (UTC)
  5. Symbol support vote.svg Support --Daniel 09:30, 29 May 2015 (UTC)
  6. Symbol support vote.svg Support per point#4--Dixtosa (talk) 10:33, 30 May 2015 (UTC)
  7. Symbol support vote.svg Support. Not each image that is borderline useful and relevant needs to be kept in a Wiktionary entry. However, the discussion needs to be had per specific image. To give an idea, most images from Commons:Category:Penile-vaginal intercourse (don't look if you are sensitive) should be kept away from Wiktionary sex and coitus entries, I think. I am a male, and my measure is how strong felt hormonal response the image produces in me. If the response is strong, I think an alternative image producing smaller response should be sought. The purpose is, at least, not to distract the reader from the core lexicographical content by triggering human subsystems that are quite distinct from those subsystems that most of the lexicographical material is intended to address. I don't intend to prevent people from getting response from seeing images; it's just that if they went to a dictionary to get these sorts of images, they chose the wrong place. --Dan Polansky (talk) 09:29, 31 May 2015 (UTC)
  1. Symbol oppose vote.svg Oppose --WikiTiki89 21:04, 28 May 2015 (UTC)
  2. Symbol oppose vote.svg Oppose I oppose this generally, but I do think that images that would shock the reader because they appear in an entry with many substantial meanings unrelated to the surprising context should be collapsed, or limited to pages with only that meaning. bd2412 T 21:31, 28 May 2015 (UTC)
  3. Symbol oppose vote.svg Oppose But only in the context of healthy human anatomy. Korn [kʰʊ̃ːæ̯̃n] (talk) 22:13, 28 May 2015 (UTC)
  4. Symbol oppose vote.svg Oppose but supporting that some images should be collapsed. The reader should have the freedom to choose. --ContraVentum (talk) 23:03, 28 May 2015 (UTC)
  5. Symbol oppose vote.svg Oppose, not censored. One of our USPs is non-censorship, let's not get rid of our USPs. Renard Migrant (talk) 21:00, 29 May 2015 (UTC)

Some images should be replaced with graphics[edit]

Drawings are a balanced way of adding helpful graphical content to a potentially touchy entry without being as explicit as photographies.

  1. Symbol support vote.svg Support —Stephen (Talk) 22:46, 28 May 2015 (UTC)
  2. Symbol support vote.svg Support Even medical-style photographs, such as those with explanatory keys, can be acceptable. DCDuring TALK 23:51, 28 May 2015 (UTC)
  3. Symbol support vote.svg SupportBoBoMisiu (talk) 02:42, 29 May 2015 (UTC)
  4. Symbol support vote.svg Support Great! --Daniel 09:31, 29 May 2015 (UTC)
  5. Symbol support vote.svg Support — This cuts the Gordian knot and should be done irrespective of what we decide re image-collapsing. — I.S.M.E.T.A. 09:50, 29 May 2015 (UTC)
  6. Symbol support vote.svg Support replacing some photos with graphics. I did this in bra recently (diff), before this discussion started. --Dan Polansky (talk) 09:29, 31 May 2015 (UTC)
  1. Symbol oppose vote.svg Oppose The question should be, in every case, what images are most helpful to the reader understanding the meaning of the term. Also, as with flower, there is no reason we can't have both photo and a graphic, if each provides different information. bd2412 T 23:07, 28 May 2015 (UTC)

Proposed six month interaction ban between User:Purplebackpack89 and User:Kephir.[edit]

I have had some success in the past dialing down conflicts by imposing interaction bans between the disputants (even where one of them was an admin). I therefore propose a six month interaction ban between User:Purplebackpack89 and User:Kephir. The conditions of the ban would be as follows:

  • No posting on the talk page of the other.
  • No reverting the other, nor making edits that effectively revert the other, nor taking any sort of editing (or administrative) action directed at the other.
  • No posting comments directed to the other or responding directly to the other in any discussion, in any forum anywhere in Wiktionary.
  • No posting comments about the other in any discussion, in any forum anywhere in Wiktionary. This includes encouraging other editors to engage in disputes with the other. That also includes complaining that so-and-so is violating the interaction ban. This also means no loaded questions like "is it a violation of the interaction ban to do this" while pointing at something the other is doing.
  • No contacting other editors/admins by e-mail or off-wiki to complain about the other.
  • Breach of the interaction ban will result in quickly escalating blocks. One day for the first offense; one week for the second; one month for the third.
  • You may independently participate in the same discussion of a proposal made in one of the community portals, in RfV, RfD, etc., but your comments there should be addressed to the issue at hand, never to the other (and no sneaking in ambiguous jabs like "some editors say..." with a comment directed to what the other has said; stick to the issue).
  • The interaction ban will be reviewed by the community six months after imposition.

Based on my experience with similar conflicts, I think that this should wrap up this headache. bd2412 T 18:12, 21 May 2015 (UTC)

Support. Excellent idea. —Stephen (Talk) 18:19, 21 May 2015 (UTC)
Support. --WikiTiki89 18:21, 21 May 2015 (UTC)
Support. ‑‑ Eiríkr Útlendi │ Tala við mig 20:46, 21 May 2015 (UTC)
Support. — I.S.M.E.T.A. 09:10, 23 May 2015 (UTC)
  • Support. —Aɴɢʀ (talk) 20:47, 21 May 2015 (UTC)
  • Support, though I don't think "No contacting other editors/admins by e-mail or off-wiki to complain about the other." is on all fours with the others. Off-wiki communication not visible to the other party would not inflame the other party to the conflict and might lead to education of the participating party. If the recipient of the communication didn't like to be a recipient email software can effectively filter out the emails. I don't think that off-wiki lobbying of newbies is highly likely. DCDuring TALK 23:26, 21 May 2015 (UTC)
    • My issue with the e-mail/off-wiki contact also derives from the experience of not having done that in the past, when it would have saved some annoyance. bd2412 T 02:55, 22 May 2015 (UTC)
      • I agree with DCDuring that that particular condition is problematic. It's kind of unenforcable (how would people know about personal e-mails or WebChat personal threads), it's pointless (how does off-wiki chatter harm the creation of entries?), and it's in general not needed. Purplebackpack89 10:22, 22 May 2015 (UTC)
        • I will gladly amend that to "No contacting User:BD2412 by e-mail or off-wiki to complain about the other". If other editors want to deal with such complaints, that's their business. bd2412 T 13:26, 22 May 2015 (UTC)
          • Rather than seeking such a privilege, why not just apply an email filter to the sender if they send you an email you don't like? DCDuring TALK 13:41, 22 May 2015 (UTC)
            • Meh, I have struck that line. bd2412 T 16:25, 22 May 2015 (UTC)

Technical question: That means if either of them genuinely makes a mistake that creates falsehood in an entry, the other one - should he see it - just have to bite it down and hope somebody else sees it to? _Korn (talk) 22:26, 21 May 2015 (UTC)

Yeah, pretty much. Purplebackpack89 22:45, 21 May 2015 (UTC)
Let's just assume that the rest of us will pick up that slack. bd2412 T 23:24, 21 May 2015 (UTC)
Oppose, controversially? As much as I respect BD's opinion (and I believe he's some kind of lawyer, so must have a clue about dispute resolution) I don't think this is a thing to be encouraged. At the end of the day, wikis are community-based projects and people have got to get along with each other in some way. I'm not perfect about this either, and sometimes get into squabbles, and not everybody loves me, but I don't think there should be these artificial barriers put up. People have gotta get along with people, to some extent. Equinox 23:38, 21 May 2015 (UTC)
  • Not really particularly excited about it. Look, Kephir's bullshit blocks have to stop, but do we really want to set a precedent that if one editor doesn't like another editor, he can claim anything the editor does is vandalism or harassment, and be rewarded with that editor not being allowed to interact with him? Purplebackpack89 23:46, 21 May 2015 (UTC)
    It sounds like you think you're not a contributor to there being a problem. bd2412 T 01:57, 22 May 2015 (UTC)
    Look, there were a great many legit concerns that I posted to Kephir's page. Like the time he went around refactoring everybody's signatures. Or the time he removed comments I made on another user's talk page. It's perfectly acceptable to be concerned about those things. Asking Kephir to stop those things was not disruptive, it wasn't vandalism, it was wrong of Kephir to claim it was, and there's no reason to stop them. And if you look at the number of times I've posted to Kephir's page in the last year or so; it's not very often: probably less than 30 times (perhaps a great deal less; it's hard to tell due to deleted contributions and talk-page threading), a number of which were me (rightfully so) being frustrated at Kephir's claim that other things I posted were tagged as vandalism. I refuse to believe that the principal problem here is anything but Kephir's bullshit blocks stemming from a belief that it is paramount that I leave the Wiktionary community, the execution of which has led to him bending or breaking rules to make it happen. The only things that need to be prevented are the bullshit blocks, the tagging of comments as vandalism and the removal of comments on third-party noticeboards; the first two of which are better achieved by removal of rights rather than this interaction ban. You're also somewhat ignoring the precedent this could set. To a certain extent, this amounts to editor A throwing a huge hissy fit about editor B, but still getting exactly what he wants (an interaction ban with editor B), and in effect the claim that things editor B did were as bad or worse as what editor A did. Purplebackpack89 09:02, 22 May 2015 (UTC)
    Just to clarify: can you confirm that, of all of your ten previous blocks, you had done nothing bad ever, and they were all mistakes by admins? Equinox 10:01, 22 May 2015 (UTC)
    For starters, that's a complete red herring, because this discussion should solely be confined to my interaction with Kephir. It's also ridiculous, as all editors (including you) have done "something bad"; just most of the time, the "something bad" isn't serious enough to warrant a block. It's also inaccurate, as I just checked my block log, and there were only seven. Of those, three occurred three or more years ago, and the remaining four were all undone within 24 hours (this counting Liliana's reduction of a block first to three days, and later in the day to a complete unblock). And, yes, I would consider the last three blocks "mistakes by admins": the two by Kephir and one last year by you. One should not be blocked for making non-vandalism comments on a user's talk page, nor should a blocking summary be a personal attack (as yours was) or contain the word "silliness". But I would again note that that is irrelevant to this discussion. Purplebackpack89 10:22, 22 May 2015 (UTC)

This has gone without comment for a week, and I believe the consensus is clear. Would an uninvolved admin please close this accordingly? Cheers! bd2412 T 19:08, 29 May 2015 (UTC)

Category:Spanish Spanish[edit]

You people don’t seem to be taking this issue seriously. Why shouldn’t this category be shrunken? Why don’t you care?

As already said, the verbal forms don’t add any value to this category. They just make it very tedious to crawl through. I want to find regionalisms that are lemma, I don’t give a toss about the thousands of verb forms that clog up this category. You can create a subcategory for them if you desire, or you can not. I don’t mind either way. Just please, for the love of hell, shrink this thing.

Am I the only one who feels this way? --Romanophile (talk) 14:21, 23 May 2015 (UTC)

Symbol support vote.svg Support shrinking the category. Though unfortunately the best name I can think of for a separate category for Spanish Spanish verb forms is Category:Spanish Spanish verb forms. --Daniel 14:37, 23 May 2015 (UTC)
Concerning the name, I would personally prefer seeing the category renamed to Category:European Spanish à la Category:European Portuguese. The same idea can apply to the new category. ‘Spanish Spanish’ sounds… ambiguous. --Romanophile (talk) 14:45, 23 May 2015 (UTC)
Great! It would be like Category:European Portuguese and Category:European Portuguese verb forms. --Daniel 15:02, 23 May 2015 (UTC)
Symbol support vote.svg Support The {{es-verb form of}} template should not categorize any of the regional parameters. I remember that Spanish verb forms didn't show up in regional categories previously. It seems that someone changed the template to call {{label}} without thinking about the consequences. Matthias Buchmeier (talk) 14:57, 23 May 2015 (UTC)
It seems that this has been changed in a recent edit of @Kephir. I'll go ahead and revert that. Matthias Buchmeier (talk) 15:09, 23 May 2015 (UTC)
I've now moved all the verb forms into Category:European Spanish verb forms. But the higher-level category is harder to move because it's filled by the context label "Spain". If I changed the category on that, there might be other languages that also use the label, and those would also be affected. We wouldn't want to end up with Category:European Basque or something like that. —CodeCat 00:56, 24 May 2015 (UTC)
Thanks for recategorizing the verb forms. As for the context label itself: I think it's fine for "Spain" to categorize things into "Spanish _" rather than "European _". At least, Category:Spanish Spanish is no stranger than Category:French French, Category:English English or the currently nonexistent but plausible Category:German German (for terms used in Germany proper as opposed to Switzerland, Austria, etc). - -sche (discuss) 01:15, 24 May 2015
We could also consider changing how we name the categories. For example, we could use "Spanish in Spain" instead. —CodeCat 01:36, 24 May 2015 (UTC)
That's a good idea. A placename-noun- rather than adjective-based naming scheme would be better in other cases, too. The Swiss categories are already named "Switzerland French" etc because "Swiss German" was deemed too ambiguous. And it would enable the DR Congo and R Congo to be distinguished — there aren't many Congolese French words that are limited to only one Congo, but if fr.Wikt is to be believed, there are a few. - -sche (discuss) 03:01, 24 May 2015 (UTC)
How would we name Category:European Spanish verb forms in this new scheme? Category:Spanish verb forms in Spain sounds a bit odd. —CodeCat 14:22, 24 May 2015 (UTC)
We could use "Spain Spanish" and so "Spain Spanish verb forms". That still sounds odd, but it's less odd. - -sche (discuss) 15:33, 24 May 2015 (UTC)
"Iberian Spanish"? SemperBlotto (talk) 15:35, 24 May 2015 (UTC)
I'm most familiar with the term Peninsular Spanish. — I.S.M.E.T.A. 16:00, 24 May 2015 (UTC)
I say stick with European. There aren't that many languages spoken in Spain and I don't think that Occitan, Galician, Catalon and Basque are really divided along such a political border or would use such a label rather than a dialectal name. Korn [kʰʊ̃ːæ̯̃n] (talk) 20:25, 26 May 2015 (UTC)
Well, I would call the variety of the language spoken in Spain "Spanish", and similarly "French" the language spoken in France (rather than Canada etc) and "English" the language spoken (and spelled) in England (rather than the US, OZ etc). I would only give the non-standard varieties different names (Swiss Italian, Canadian French, Australian English, Brazilian Portuguese) etc. SemperBlotto (talk) 07:12, 24 May 2015 (UTC)
Your usage of 'non-standard' there might offend some people. Brazilian Portuguese is the standard in Brazil, after all. Also: Do you really propose to call English English 'English' only? Because that'd be hella confusing. _Korn (talk) 09:56, 24 May 2015 (UTC)
Exactly. Renard Migrant (talk) 15:07, 24 May 2015 (UTC)
  • Isn't there a term called "Castilian" for this dialect? Shouldn't we perhaps consider renaming Spanish Spanish to Castilian Spanish? Purplebackpack89 20:08, 26 May 2015 (UTC)
    • The term Castilian is ambiguous; although it sometimes does main all varieties of Spanish spoken in Spain, it is often used to exclude the dialects of southern Spain (Andalusian, Canarian, etc.), and in Spanish itself, castellano is often a simple synonym of español and refers to the entire language in all countries (though I don't think the English word Castilian is used that way very often at all). —Aɴɢʀ (talk) 20:20, 26 May 2015 (UTC)
      • Not only that, but I'm fairly sure it is sometimes used to refer to all dialects of Spanish (including Latin American). --WikiTiki89 20:44, 26 May 2015 (UTC)
        • OK, just throw that out there. Seems as though you guys were looking for a word other than "Spanish" to use in that category; I thought "Castilian" might be that word. But, if there are multiple dialects of Spanish in Spain, perhaps it might be a good idea to further disambiguate words by region. Purplebackpack89 20:49, 26 May 2015 (UTC)

Amend CFI so that single words don't have to be idiomatic[edit]

Strictly speaking, though we don't enforce it, single words don't bypass the 'idiomatic' criterion of WT:CFI. Current example: helikoptercrash which if we looked at CFI verbatim is a straight-forward delete. What CFI says about idiomaticity is "An expression is idiomatic if its full meaning cannot be easily derived from the meaning of its separate components." Well we have the components helikopter and crash.

The proposal is to rewrite WT:CFI#General rule so that single words not having to be idiomatic is in the criteria rather than just a convention among editors (a good convention I should add). I can't imagine anyone disagreeing with me on the principle, though I can easily imagine people disagreeing over the drafting. I'm not proposing a draft amendment at this stage as I thought I'd give someone else first crack at it. Renard Migrant (talk) 14:09, 24 May 2015 (UTC)

I think that's too vague. A better criterium is to explicitly say that terms, in which it's not obvious to a non-speaker where to split the parts, should be included. That way we don't get hung up on what a word is. We should also consider the consequences for languages which routinely add many morphemes to words. Zulu, for example, inflects verbs for both subject and object. —CodeCat 14:19, 24 May 2015 (UTC)
I was thinking of leaving the definition of 'word' open to debate because I thought any narrow definition of 'word' would get voted down. It's not always about what the best solution is, but about what's the best solution that will pass a vote. Renard Migrant (talk) 14:27, 24 May 2015 (UTC)
So, should we delete both boathouse and houseboat? I think not. "All words in all languages" takes priority over CFI - it's our mission statement. SemperBlotto (talk) 14:41, 24 May 2015 (UTC)
Then maybe it's the mission statement that needs changing. It was written before all these problems were anticipated. —CodeCat 14:46, 24 May 2015 (UTC)
Please no. It's what sets us apart from any other dictionary, and is (in my view) our best feature. SemperBlotto (talk) 14:52, 24 May 2015 (UTC)
WT:CFI#General rule also describes 'attested' and 'idiomatic' as guidelines. Why not describe them as rules? Renard Migrant (talk) 15:07, 24 May 2015 (UTC)

'scuse me, but how's that different from what I wanted? And follow up question: Do English speakers really consider 'coalmine' to be one word but 'coal mine' to be two words? Isn't there some semantical feature which defines what a 'single word' is?_Korn (talk) 16:24, 24 May 2015 (UTC)

A lot of English speakers (and speakers of other languages, for that matter, but we'll stick to English here) haven't learned how to think about language beyond orthography, so they say things like, "Should it be home page, with a space between the two words; or homepage, all one word?" (boldface added). —Aɴɢʀ (talk) 16:29, 24 May 2015 (UTC)
Then it might help to look at how it's considered in languages that don't write spaces, such as Chinese. What is considered a word in Chinese? Also, speaking of that, I believe that in Japanese, many words have multiple pronunciations or "readings" of the characters. It's quite likely that a compound in Japanese uses only one of these pronunciations (someone who knows Japanese should confirm). That would mean, then, that if we omitted an entry for the compound on idiomaticity grounds, then users would not longer be able to figure out how to pronounce it. Other languages with non-phonemic orthography like English also have this problem. Is a record player a /ˈɹɛkɔɹd ˌpleɪəɹ/ or a /ɹɪˈkɔɹd ˌpleɪəɹ/? I think this is an important argument that there are more considerations than "can it be understood from its parts", but also whether other aspects of the compound can be predicted. —CodeCat 16:44, 24 May 2015 (UTC)
I wouldn't put it like that. Kanji can have different readings and these readings are words. Kanji are just glyphs. Sometimes kanji are applied to words because of the semantics of the characters (熟字訓), even though the characters have no readings on their own which fits the word in question, and vice versa, kanjis can be assigned to words on phonetic basis while the characters have no semantic connection to the word (当て字). So kanji can either represent a semantic concept, which is connected with several words, which in turn define the reading of the kanji, or kanji can represent a single word, which itself might have several alternative kanji spellings. The basis for our consideration should be the spoken language alone and everything else we should just treat as a graphical representation of the word our entry deals with. (By the way, we fail to list kana spellings as 'alternative spelling of'.) One of those representations we then choose as an anchor for users who want to look up the lemma. _Korn (talk) 19:10, 24 May 2015 (UTC)
Still, my question is, can someone tell how to pronounce a compound consisting of kanji, if they know all possible pronunciations of each kanji individually? —CodeCat 19:39, 24 May 2015 (UTC)
Short answer: No. But a compound of kanjis is not necessarily a compound of the words the kanjis represent individually. It's like Javascript. Having [var a = 1] and [var b = 2] doesn't automatically create [var ab = 12] or [var ab = 3]. They are completely independent, they just happen to use the same strings. Kanjis are like the strings of variables in that regard. _Korn (talk) 20:37, 24 May 2015 (UTC)

The 1st sentence of CFI states that Wiktionary is intended to include “all words in all languages”. Other criteria should be consistent with this basic principle. Lmaltier (talk) 17:42, 24 May 2015 (UTC)

Yes, but that's not so clear cut as there are multiple definitions of word. —Aɴɢʀ (talk) 18:03, 24 May 2015 (UTC)
I'm just repeating myself (but I don't think anyone's replied to it) but why not leave the definition of word for editors to discuss on a case-by-case basis on WT:RFD instead of putting it in CFI itself. Such an amendment is much less likely to be voted down, because all definitions of 'word' can be put forward in a debate without CFI backing up only one of them. Renard Migrant (talk) 21:00, 24 May 2015 (UTC)
"All words in all languages" is a very broad mandate; I would suggest that it inherently suggests a broad and inclusive definition of "word". bd2412 T 03:22, 25 May 2015 (UTC)

I don't have much of an opinion on how we handle German and Dutch words. I do oppose this strongly for English; accepting strings of characters delineated by spaces or punctuation is an incredibly convenient bright line for English, and it maps fairly well to what English speakers think of as words.--Prosfilaes (talk) 01:34, 25 May 2015 (UTC)

What do you oppose exactly? Your rationale makes it sounds like you support the original statement I made. Renard Migrant (talk) 21:02, 29 May 2015 (UTC)

ELE: explicitly ban nested subdefinitions/subsenses? Or allow in rare cases?[edit]

Currently we implicitly ban subdefinitions in ELE: Definitions:

“The definitions are the most fundamental piece of dictionary information but do not have their own header. They are simply added in one big block, line after line, each beginning with a number sign (#).”

The plain text states that this is a flat list.

There has been some discussion of this in the past, notably BP/2008/November#Indented subsenses?, and there are some important entries that currently use subsenses (head (current), lead (current)), as well as some more marginal uses: (marginal (current)). OTOH, other complex entries like set (current) simply have a long, flat list.

(Subsenses have also been suggested for inflected forms: BP/2013/July#German inflections again; and to help with translations, where different subsenses have different translations: BP/2012/April#Numbered translation glosses.)

Setting aside debate over whether we should have subsenses, current policy (and overwhelming practice) is to not have subsenses, and thus uses are inconsistent (hence jarring to readers, and unsupported by software). Thus should we:

  1. Explicitly ban them in ELE?
    1. …possibly with exceptions for very complex cases?
  2. Flatten existing usage?
    1. …excepting exceptions?

For the record, the sides appears to be:

Yay subsenses (nested)
  • Better organized, reflects reality of language – senses are related, and a flat list destroys this structure, and is unwieldy for long entries.
  • More readable – grouping 25 senses into 5 groups of 5 is more readable, and avoids the unevenness of “sense, very similar sense, very similar sense, completely different sense”.
  • Industry practice – professional dictionaries group senses.
  • Helps with translations – translations are often grouped by subsenses (perhaps they shouldn’t be, with several (glossed) subsenses corresponding to a single English sense?).
Nay subsenses (flat)
  • Complicated – harder to use for readers and tools.
  • Less readable – nesting adds complexity, parent senses are often abstract and unreadable.
  • Prone to abuse – easy to add unnecessary layers for minor shades of meaning. (Do we want “foo, fooish, foo-like” to become 3 subsenses??)
  • Largely unnecessary – some complex entries benefit from it, but most entries don’t: grouping 4 senses into 2 groups of 2 just adds overhead. Thus layout for complex entries is different from that for simple entries, adding inconsistency.

Personally I’ve a bias towards meta:Separatism, so I’d tend to prefer nested grouping, which could be flattened by tools for display (either make one entry for each leaf, or merge all leaves into the parent), but in practice this doesn’t currently exist, so flat for now seems prudent.

(This came up when I was working on pony, in the sense of “small unit of alcohol”, which has specific subsenses: 140 ml glass in Australia, 7 fl oz ≈ 210 ml bottle in the US.)

I’ve proposed wording to suggest grouping similar definitions but not nesting at ELE/Editable#Definitions (diff); what sayeth the parlour?

—Nils von Barth (nbarth) (talk) 21:25, 24 May 2015 (UTC)
It's worth it, especially for words with tons of senses, some of which are hyponymous (look at "set"). The abuse that I've seen, though, has been creating artificial group headers that aren't in themselves senses, like: "(senses relating to motion)". I find that too vague and ugly; but something like "To move in a specified manner", followed by the various subsenses, seems potentially helpful. Equinox 21:30, 24 May 2015 (UTC)
@Equinox: As you know, we are more or less forced by the wiki software to have a sense above every subsense. Other print and online dictionaries that have subsenses (and subsubsenses, even subsubsubsenses) do not face that constraint. If we could use a template and JS to suppress the vacuous hypernym, we would be able to duplicate a presentation that some editors (and other dictionaries) find worthwhile. DCDuring TALK 23:08, 24 May 2015 (UTC)
Symbol oppose vote.svg With the greatest of respect, Nils von Barth, I very strongly oppose such a ban. Subsensing should become more widespread, not less. — I.S.M.E.T.A. 21:34, 24 May 2015 (UTC)
I suspect this is going to need a vote, given previously expressed strong support and strong opposition, but we should hash out opinions and options here first.
(And n/p I.S., I don’t have strong opinions on this, but would like some discussion and policy, whichever way.)
—Nils von Barth (nbarth) (talk) 21:49, 24 May 2015 (UTC)
Symbol oppose vote.svg Oppose with the power of Old Spice Man. I refer you all once more to the entry be. How can that possibly become even less readable by indentions and proper grouping? _Korn (talk) 22:31, 24 May 2015 (UTC)
Symbol oppose vote.svg Oppose. IMO any entry with more than three definitions is a candidate for improved intelligibility using subsenses, though it is not vital unless there are more definitions. DCDuring TALK 22:56, 24 May 2015 (UTC)
Symbol oppose vote.svg I think subsenses are useful in many cases, and oppose banning them. I don't interpret the current ELE as banning them. Go contains a block of definitions, one after the other (line after line), each with a line that begins with a #. Some lines follow that # with another #, but that isn't prohibited, it's starting a definition line with * or 1. that's prohibited, by my ken. - -sche (discuss) 00:30, 25 May 2015 (UTC)
Symbol oppose vote.svg Oppose per the above. I agree with editors who say that we should have more of this, not less. bd2412 T 03:23, 25 May 2015 (UTC)
  • I know I'm beating against the grain here, but it's not something I'd ever avail myself of (either in a new entry or one that is being rewritten), nor is it a way I prefer to read dictionaries. I have to agree with the drawbacks posted by the OP, and I'd also note that, while many professional dictionaries subgroup, general-use dictionaries often do not. While I'd discourage the practice, not sure I'd forbid it, though. Purplebackpack89 05:35, 25 May 2015 (UTC)
Symbol oppose vote.svg Oppose As others have said, we want more of this, not less. --WikiTiki89 15:33, 26 May 2015 (UTC)
@Wikitiki89@BD2412 Maybe we want more rather than less, but can we at least agree that there are quite a few pages in which nesting is not necessary and perhaps even confusing or detrimental? For example, any entry with three or fewer definitions? Or an entry with more definitions than that, but definitions so distinct there's no logical way to group them? Purplebackpack89 19:12, 26 May 2015 (UTC)
If there is no logical way to group them, then obviously they are not subsenses. No one is advocating grouping unrelated senses. bd2412 T 19:19, 26 May 2015 (UTC)
I don't think there is anything that we can decide for the general case. Each entry is different and should be nested (or not nested) however best suits that particular entry. --WikiTiki89 19:30, 26 May 2015 (UTC)
I think we might be able to agree that the grouping should be for semantic reasons, not solely for, say, similarity of usage context, topic, or register. DCDuring TALK 23:04, 26 May 2015 (UTC)
Symbol oppose vote.svg Oppose. Sense nesting needs to be used more often, except in Ancient Greek entries where it is used a bit more often than necessary. — Ungoliant (falai) 22:39, 28 May 2015 (UTC)
Symbol oppose vote.svg Oppose. Sense nesting is a good idea to make definitions more readable. We should however clearly mark (maybe with a template) non-definition, mere header sense-lines. Otherwise machine readability will get worse. We should also amend ELE to explain how sense nesting is supposed to work. Matthias Buchmeier (talk) 09:19, 29 May 2015 (UTC)
Symbol abstain vote.svg Abstain Subsenses should be used only with great care. Sense groups that are not attested as a sense in its own right need to be clearly so marked. Let me note that while I see dictionary practice of sense grouping, I do not see the practice of treating the sense groups as definitions in their own right. There has been a lot of abuse of subsensing in the English Wiktionary, by multiple editors with almost no idea of how subsensing and hyponymy works. Because of all the abuse, I would be almost inclined to ban subsensing, but I do admit that it can be useful if done right. --Dan Polansky (talk) 10:37, 31 May 2015 (UTC)
Symbol abstain vote.svg Abstain First of all, wiktionary does not output semantically correct HTML definitions. It is fundamentally flawed page structure because the headline is an <h4> followed by an ordered list (<ol>) containing one list item (<li>) containing each sense. What looks weird to me is that it doesn't use the semantically correct <dl> element for definitions. I think wiktionary should using the correct elements and then see how to nest sense clusters in <dd> elements which can contain a <header> element. All these so called complex cases then become trivial. —BoBoMisiu (talk) 19:44, 31 May 2015 (UTC)

Transylvanian Saxon[edit]

How should we handle Transylvanian Saxon? Despite its name, it is not a variety of Saxon (sxu) but rather a variety of Moselle Franconian, like Luxembourgish (lb). It needs an etymology code at a minimum because it has loaned Romanian words quite separate from Standard German, but it could be considered a full language as distinct from Standard German as Luxembourgish. In practice, treating it as de would have the effect of excluding it by subjecting it to WT:WDL standards although durable-but-internet-accessible documentation of it is in fact limited. Here are some text samples:

  • T. Saxon: Wae kâum dier Duit? Hie brâch mech nider. // Mer wallen blewen wot mer sen, Gott healf äs (or: hälf as) enzt uch engden.
  • Luxembourgish: Wéi koum den Doud? Hien (?hat mech nidder gebrach?). // Mer wëllen bleiwen wat mer sinn, Gott hëllef eis elo an ëmmer.
  • Standard German: Wie kam der Tod? Er brach mich nieder. // Wir wollen blieben was wir sind, Gott hilf uns jetzt und immer.
  • English: How did Death come? He laid me low. // We want to remain what we are, God help us now and always.

- -sche (discuss) 21:17, 25 May 2015 (UTC)

Don't all German dialects have their own L2? I saw them for Alemannic and Bavarian. Korn [kʰʊ̃ːæ̯̃n] (talk) 22:08, 25 May 2015 (UTC)
ps.: If they don't, let them. German dialects (as opposed to regional variants and accents of standard German) are sufficiently individual to merit an L2, I think. They should be at least as far apart as Rigsdansk and Bokmål. Korn [kʰʊ̃ːæ̯̃n] (talk) 22:16, 25 May 2015 (UTC)
Bavarian and Alemannic have their own L2s because they aren't dialects of German, they're separate descendants of MHG if not OHG which are not mutually intelligible with modern German. But note that e.g. Walser, which is mutually intelligible with other Alemannic varieties, is accordingly handled under ==Alemannic==, and Gottscheerisch is currently handled under ==Bavarian==. I think Transylvanian Saxon is probably as distinct from German as e.g. Luxembourgish, and so merits its own L2, but not all High German lects do, especially because many of them exist in continua which it wouldn't make sense to give codes to every individual step of. (You may or may not be are of the controversy that surrounds whether or not en.Wikt should consider Bokmal and Nynorsk to be separate languages from Norwegian, and how it should handle dialectal Norwegian and Riksmal if there is no Norwegian language but only a Bokmal and a Nynorsk language.) - -sche (discuss) 22:41, 25 May 2015 (UTC)
Isn't "separate descendant from Middle High German with restricted mutual intelligibility" the very definition of a German dialect? Korn [kʰʊ̃ːæ̯̃n] (talk) 13:52, 26 May 2015 (UTC)
The way 'dialect' is usually defined, in my experience — sense 1 of [[dialect]] and the first sense w:Dialect describes, which seems to be the sense WT:CFI#Languages_to_include and most discussions centred on it use when saying only languages and not dialects are to be included — mutual intelligibility is a defining feature. You must be using sense 3, which I hadn't realized was an actual sense; my apologies. The question remains: is Transylvanian Saxon different enough from the other things it could be compared to (German, Luxembourgish, other Moselle Franconian) to merit its own L2? Seeing no opposition to the idea that it is, I've given it the code gmw-tsx. - -sche (discuss) 17:28, 26 May 2015 (UTC)
I'm very much talking about dialects sense 1. I'm also not at all convinced that mutual intelligibility is a requirement rather than a hint. How much one understands depends on one's own intelligence and education; and even comparably minor phonetical changes (/huːs/ > /hɔʊs/; /nd/ > /ng/) and even smaller changes in the syntax or lexicon can seriously disrupt understanding for an idiotic (as in only knowing one's own form) person already. Then again, this discussion is a bit moot since the international nomenclature of language variants is massively inconsistent and mainly based on political grounds. I maintain that Bavarian is a dialect of the same language as standard German since the differences aren't that huge, but it's still far enough apart to deserve an L2. The same is true for Thurungian, Swabian and Ripuarian. The group knwon as Alemannic is another thing altogether since parts of it to this day never even left their Old High German stage. Point being: Yeah, give it an L2. Korn [kʰʊ̃ːæ̯̃n] (talk) 18:40, 26 May 2015 (UTC)

Vietnamese entries on Han/Nôm characters pages[edit]

@Wyang, Atitarev In modern-day Vietnam, the Han script is practically dead. No one ever uses it in any practical way, not in any sort of normal writing. It's sad, but in fact, the Han script is used solely for the sake of decoration. It's not like in Korea, where Hanja is still used to some extent ("half-dead") to distinguish a few confusing words. Should we even include a "Vietnamese" entry on a Han character/word page? ばかFumikotalk 03:33, 26 May 2015 (UTC)

Wiktionary does cover historical usage as well as current usage — hence we have a whole category of English words that are dead and no longer used. If Vietnamese has been written with Han characters, and there are (old) Vietnamese documents written in Han characters that someone might be reading and trying to decipher, then it would seem that we should include Vietnamese sections on Han character pages. But those sections could have minimal content and serve simply to direct people to Latin-script entries. - -sche (discuss) 03:59, 26 May 2015 (UTC)
@-sche It sounds just fair to document Vietnamese obsolete, or even archaic, terms, too. I'm talking about the script. I think it's better to call the entries "Middle Vietnamese" or something, rather than "Vietnamese". ばかFumikotalk 10:50, 26 May 2015 (UTC)
If they are used and understood today, they're current, no matter how little and what for they are used, even for noodle decoration. Korn [kʰʊ̃ːæ̯̃n] (talk) 14:00, 26 May 2015 (UTC)
No they are not. If you're not a scholar majored in Han characters, they look just like a bunch of doodles. ばかFumikotalk 10:27, 27 May 2015 (UTC)
How long ago did the Vietnamese stop using Han characters? If they stopped using them around (or before) the same time that Middle Vietnamese is thought to have transitioned to Vietnamese, it would make sense to treat them as Middle Vietnamese. But Wikipedia suggests Latin script only displaced Chữ nôm in the 1900s, which sounds like obsolete (but not "Middle") Vietnamese. - -sche (discuss) 17:34, 26 May 2015 (UTC)
You got a point. Although things were quite complicated back in the 1900s, 'cause there were 3 different languages (Vietnamese, French and literary Chinese) and 4 different scripts (French Latin, Vietnamese Latin, Han and Nom), none of which were considered standard, and the Vietnamese alphabet were only accepted as the official script in 1945. I guess the Nom script can be called obsolete. ばかFumikotalk 10:27, 27 May 2015 (UTC)
@Fumiko Take: Perhaps "archaic" would be better, given that they still see some use. What do you think? — I.S.M.E.T.A. 11:00, 27 May 2015 (UTC)
That's a good idea, although "archaic" or "obsolete" are only labels and not to used in the entry names. ばかFumikotalk 11:03, 27 May 2015 (UTC)
@Fumiko Take: Do you mean in {{label}}s or something else? — I.S.M.E.T.A. 11:11, 27 May 2015 (UTC)
Yes I did. ばかFumikotalk 11:12, 27 May 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── @Fumiko Take: So every chữ Nôm entry would transclude {{label|vi|archaic}}, yes? — I.S.M.E.T.A. 11:16, 27 May 2015 (UTC)

Well, maybe "archaic form of" or "obsolete form of" would be better. ばかFumikotalk 11:19, 27 May 2015 (UTC)
@Fumiko Take: I see. Perhaps a dedicated template would be desirable in this case; something that generated "Chữ Nôm spelling of wởrd." and which autocategorised the entry. What do you say? — I.S.M.E.T.A. 11:28, 27 May 2015 (UTC)
We've already had the Han Tu form of template. The chu nom spelling of template would be redundant. ばかFumikotalk 11:31, 27 May 2015 (UTC)
@Fumiko Take: Sorry, what template is this? — I.S.M.E.T.A. 11:33, 27 May 2015 (UTC)
{{han tu form of}}. ばかFumikotalk 11:36, 27 May 2015 (UTC)
@Fumiko Take: I see. Why not just use that, then? — I.S.M.E.T.A. 11:46, 27 May 2015 (UTC)
Okay okay. I wasn't suggesting to re-label the entries. I was suggesting to rename them. We can put an end here. ばかFumikotalk 11:49, 27 May 2015 (UTC)
OK. — I.S.M.E.T.A. 12:08, 27 May 2015 (UTC)

Min Nan loanwords in Pe̍h-ōe-jī[edit]

Since it has been established that Min Nan must be written in either Han characters or in Pe̍h-ōe-jī, I propose the following method of transcribing the tones of loanwords presented in the MOE Dictionary of Frequently-Used Taiwan Minnan into POJ:

Tone Contour POJ
initial/medial final
11 ā à
33 a / â ā
35 a̋ * (none)
51 à á
55 á a
1 (entering) a̍k (none)
3 (entering) (none) ak
5 (entering) ak a̍k

* 9th tone, borrowed from Tâi-lô


  • a33 lu55 mih3 → a-lú-mih
  • ai55 sirh3 khu33 lin51 mu11 → ái-sirh khu-lìn-mù
  • sip11 pan55 na51 → si̍p-pán-ná
  • hang35 goo51 → ha̋ng-gó͘

Justinrleung (talk) 05:45, 27 May 2015 (UTC)

Wiktionary:Quotations and Wiktionary:Citations[edit]

According to Help:Citations, quotations, references the only difference between a citation and a quotation is the namespace. In WT:RFV we tend to call them citations no matter what namespace they're in. Isn't it a bit outdated to have two separate, long WT: pages for two things that are essentially the same thing? I'd've thought redirecting one to the other and explaining about the citations namespace would take hardly any time at all. Renard Migrant (talk) 17:43, 27 May 2015 (UTC)

  • Symbol support vote.svg Support Sure, that's what I always thought of these two, they should be merged eventually. I think I even brought it up at some point but I don't remember the details. --Daniel 17:55, 27 May 2015 (UTC)
My understanding is that Citations needn't have the translation and transliteration, while Quotations do, because they appear in the mainspace--Dixtosa (talk) 07:40, 28 May 2015 (UTC)
Whether these will be merged or not, I want quotations moved from between definitions as quotations tend to be large and include links and quickly get huge hotchpotch which makes recognizing actual defs difficult. Only some kind of link (using {{jump}} or something) should be left there I think. Who agrees?--Dixtosa (talk) 16:28, 28 May 2015 (UTC)
Remember we can write about differences in Wiktionary:Citations. It's not like we're going to redirect Wiktionary:Quotations to Wiktionary:Citations and not edit Wiktionary:Citations in any way. Renard Migrant (talk) 16:56, 28 May 2015 (UTC)
Yes, definitely merge these pages. - -sche (discuss) 17:29, 28 May 2015 (UTC)
I have somewhat boldly merged the pages. Along the way, I removed some redundant information and updated other information. - -sche (discuss) 18:08, 28 May 2015 (UTC)
@-sche: Thanks for doing the work. Your boldness is welcome. — I.S.M.E.T.A. 18:26, 28 May 2015 (UTC)
Though I would've merged the other way because we use the term 'citation' on WT:RFV and other WT: pages. I'm not going to dispute something that makes such little difference. Renard Migrant (talk) 21:30, 29 May 2015 (UTC)
It'd be easy enough to swap the content of the pages if anyone wants... :b - -sche (discuss) 21:37, 29 May 2015 (UTC)

June 2015

Good site?[edit]

Hello. Do you like Wiktionary? --Keyboard Masher (talk) 23:31, 2 June 2015 (UTC)