Wiktionary:Beer parlour/2015/April

discussion rooms: Tea room • Etym. scr. • Info desk • Beer parlour • Grease pit ← March 2015 · April 2015 · May 2015 → · (current)

---

International Journal of Lexicography

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. —Μετάknowledge^{discuss/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. —Μετάknowledge^{discuss/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)❤T☮C☺M☯ 07:15, 2 April 2015 (UTC)

Suggested modification to sign language syntax

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

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

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. 31.51.1.15 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? 31.51.1.15

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. 86.152.162.235 23:40, 6 April 2015 (UTC)

Possibility of a "Sister projects" report in the Wikipedia Signpost

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? —Μετάknowledge^{discuss/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

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

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 the Google Books 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

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

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

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

• There is no apparent consensus for including these additional languages which do not have an ISO 639-3 code: Ceqli, D'ni, Delason, Ekspreso, Europanto, Glos, Jakelimotu, Kyerepon, Latejami, Latino sine Flexione, Linga, Romanica, Sasxsek, Suoczil, Tceqli, Toki Pona.

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? —Μετάknowledge^{discuss/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. —Μετάknowledge^{discuss/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)❤T☮C☺M☯ 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

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. —Μετάknowledge^{discuss/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?

• I've decided to go ahead with the vote, which can be found at Wiktionary:Votes/pl-2015-05/Revise nominating criteria for whitelist and will begin May 26. Purplebackpack89 20:43, 19 May 2015 (UTC)

Detailed linguistic maps

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

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

I have created the code ccs-gzn-pro for the proto-language and ccs-gzn for the family. --Vahag (talk) 11:50, 7 June 2015 (UTC)

Finally! I've been waiting for this for ages. Thanks, tsavatanem. --Simboyd (talk) 12:07, 7 June 2015 (UTC)

No problem, genatsvale. --Vahag (talk) 12:45, 7 June 2015 (UTC)

Ruakh requesting de-bureaucrating.

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

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)

• It's retarded to have capitalization by default, but no dot by default. The default settings for parameters should be self-sufficient. Right now there are like gazillion alternative-form-of-s that are capitalized as if they are full sentences, but don't end with a dot. --Ivan Štambuk (talk) 14:49, 9 August 2015 (UTC)

  I agree. - -sche (discuss) 16:42, 9 August 2015 (UTC)

  Whatever we choose, it should be the same for all form-of templates. —CodeCat 17:00, 9 August 2015 (UTC)

Cross-referencing etymological root words to their descendants

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 (talk • contribs).

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

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

Greetings,

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) • Translate • Get help

"Adverbial forms" and cases of adverbs in Finnish

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. kaataa → kaatua), as well as the name-of-action noun (which is somewhat non-predictable: hypätä → hyppy, hypähtää → hypähdys, hypellä → hyppely, kaataa → kaato). 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

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

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)

@Tropylium: I agree. I find these categories extremely messy. --Per utramque cavernam (talk) 18:50, 31 December 2017 (UTC)

Why aren’t inactives desysopped?

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. —Μετάknowledge^{discuss/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)