Wiktionary:Beer parlour/2016/January

discussion rooms: Tea room • Etym. scr. • Info desk • Beer parlour • Grease pit ← December 2015 · January 2016 · February 2016 → · (current)

---

Happy New Year

Happy wiki-ing I hope that 2016 is a banner year for etymologies, appendices of personal names, and pushing forward creating the most comprehensive and accurate dictionary yet. —Justin (koavf)❤T☮C☺M☯ 15:35, 31 December 2015 (UTC)

Vote counter

Happy new year! I added a vote counter in Template:votes. Let me know if you would change anything or if there's any bug. --Daniel Carrero (talk) 09:15, 1 January 2016 (UTC)

(I'll update the documentation later, I need some sleep.) --Daniel Carrero (talk) 09:25, 1 January 2016 (UTC)

That's cool, but for past votes I think the result is more important. --Dixtosa (talk) 10:06, 1 January 2016 (UTC)

There's no way to get the decision automatically as a simple text (Passes, Fails, No consensus) just by parsing the page. For example, technically I could make the module look for uses of "Passes", "Fails", "No consensus" in the decision text but it would fail and get wrong results sometimes, especially in cases of votes with multiple options and complex results like "passes except for English".

Template:votes can be changed to let people add the vote result manually, but I oppose that. Showing the past votes with their results is already the job of WT:V#Recently ended votes, which shows more votes. If someone has the time to edit Template:votes to add a "Fails", they could as well be moving the vote to the actual list of recently ended votes. --Daniel Carrero (talk) 19:27, 1 January 2016 (UTC)

Note: Hover the mouse over the number of votes to see who voted. --Daniel Carrero (talk) 21:48, 1 January 2016 (UTC)

For me, "{{#ifeq|normal|past|}}" and whatnot is showing up dozens of times over at the top of the table. Andrew Sheedy (talk) 22:09, 1 January 2016 (UTC)

@Andrew Sheedy: Sorry, that appeared for a moment because I made a mistake. I already fixed that. --Daniel Carrero (talk) 22:11, 1 January 2016 (UTC)

Alright, thanks. I feel like it would be better if the table showed fewer votes; say, 10-15, rather than 22 like it does now. Also, why does each vote title begin with something like "pl-2015-12/"? I don't recall it doing so when the table was first implemented, and it looks kind of messy. That being said, I find it helpful to keep me up-to-date on recent votes, as I never remember to check them out otherwise. Andrew Sheedy (talk) 22:32, 1 January 2016 (UTC)

@Andrew Sheedy: The long list of votes is my fault, I created 18 of those. (82%) I feel it's better if the table shows all current votes rather than hiding some. If the table shown only 10-15 votes right now, some unstarted votes would be hidden from view but some active votes would be hidden too.

I removed the "pl-2015-12/" part now. Thanks for the last comment! --Daniel Carrero (talk) 22:49, 1 January 2016 (UTC)

Thanks, that makes it easier to read. Andrew Sheedy (talk) 23:02, 1 January 2016 (UTC)

I would like to install Extension:GetUserName to show if the current user already voted.

• (You already voted!)
• (You did not vote yet!)

--Daniel Carrero (talk) 22:24, 1 January 2016 (UTC)

Daniel, is it possible to allow people to manually insert the result of a vote? There's already an "edit this list" link. There are few enough votes that it wouldn't be too hard to insert the results, or at least a "passed/failed/other" or "passed/failed/partly passed" or whatever. Benwing2 (talk) 03:03, 2 January 2016 (UTC)

I oppose anything that requires further manual upkeep. —Μετάknowledge^{discuss/deeds} 03:21, 2 January 2016 (UTC)

It's not required. Benwing2 (talk) 03:30, 2 January 2016 (UTC)

@Benwing2, Dixtosa, Metaknowledge: I can change the template to add a "decision" parameter to all votes but it would require manual upkeep forever: Everytime a vote ends, someone would have to put the "Passes", "Fails", whatever in the vote box. I mean, if nobody types a decision, then it would just show nothing.

If enough people want that and are willing to update the box whenever needed... Why not, I suppose. --Daniel Carrero (talk) 03:36, 2 January 2016 (UTC)

I still oppose that. —Μετάknowledge^{discuss/deeds} 03:45, 2 January 2016 (UTC)

@Benwing2, Dixtosa, Metaknowledge: I added the decision1=, decision2= parameters per Benwing2 and Dixtosa, despite Metaknowledge's opposition. Does it look good? Myself, I said above that I opposed it, but now I abstain as to whether that parameter should be kept.

Currently, the vote box shows 2 "passed" results. --Daniel Carrero (talk) 03:52, 2 January 2016 (UTC)

Thanks, looks good. Benwing2 (talk) 03:58, 2 January 2016 (UTC)

Good. FYI: after the end date of a vote, if nobody has entered a decision yet, the shown decision is "decision?". --Daniel Carrero (talk) 04:05, 2 January 2016 (UTC)

Format of entries in the Reconstruction namespace

Now that we have the Reconstruction namespace, it would be really good to implement it. However, this is held up by a basic formatting decision that needs to be made: do we want "Reconstruction:Proto-Indo-European/albʰós" or "Reconstruction:albʰós#Proto-Indo-European"? I'd like it if we could make this decision in a quick poll rather than have a protracted formal vote. —Μετάknowledge^{discuss/deeds} 06:48, 2 January 2016 (UTC)

Support "Reconstruction:Proto-Indo-European/albʰós"

1. Support because this most closely matches our current format and avoids having reconstructed forms in multiple languages on a single page. —Μετάknowledge^{discuss/deeds} 06:48, 2 January 2016 (UTC)
2. Support for the same reasons —suzukaze (t・c) 06:59, 2 January 2016 (UTC)
3. Support since reconstructions do not have a well-defined spelling — they vary by author and source, and ours may also be subject to revision. Two reconstructions in unrelated proto-languages having "the same spelling" is usually not a meaningful relationship. --Tropylium (talk) 20:41, 2 January 2016 (UTC)
4. Support per above and because the other alternative would require restrictions in use of redirects. Currently we can have hard redirects for exact equivalents in other notational systems, such as *-an to *-ą for Proto-Germanic, or PIE *a and schwa to various clusters including laryngeals in our notation. Most of these no-brainer redirects don't apply to any other proto-language, and a lot would have to be made into soft redirects. Chuck Entz (talk) 23:02, 2 January 2016 (UTC)
5. Support because, as noted below, merging creates new problems. I also think this is a good first step towards a one-language-per-page format. —CodeCat 00:35, 3 January 2016 (UTC)

   What problems? Renard Migrant (talk) 12:31, 3 January 2016 (UTC)

   @Renard Migrant: Problems with existing and future redirects — see Angr's comment below. —Μετάknowledge^{discuss/deeds} 16:03, 3 January 2016 (UTC)

6. Support --Vahag (talk) 08:47, 3 January 2016 (UTC)
7. Support Wyang (talk) 01:24, 4 January 2016 (UTC)
8. Support Hillcrest98 (talk) 01:29, 4 January 2016 (UTC)
9. Support per Trop and Chuck. - -sche (discuss) 05:04, 4 January 2016 (UTC)
10. Support for many reasons I have given before. --WikiTiki89 15:59, 4 January 2016 (UTC)
11. Support per CodeCat, we should be looking at subpages in a big way. - TheDaveRoss 22:43, 5 January 2016 (UTC)
12. Support to make consensus clearer, but this does not mean I oppose the other option. —Aɴɢʀ (talk) 16:52, 8 January 2016 (UTC)
13. Support per CodeCat. —Pengo (talk) 22:27, 9 January 2016 (UTC)

Support "Reconstruction:albʰós#Proto-Indo-European"

1. Support because it matches the entry format. --Daniel Carrero (talk) 06:52, 2 January 2016 (UTC)
2. Support —JohnC5 09:48, 2 January 2016 (UTC)
3. Support -- don't have a super-strong opinion here but this feels more natural, and I remember early on finding it difficult to figure out where proto-language entries were in Wiktionary with the old (i.e. current) format, which is similar to the Reconstruction:Proto-Indo-European/albʰós format. — Benwing2 (talk) 17:38, 2 January 2016 (UTC)
4. Support. I like this one. Would anything actually need to be merged? Renard Migrant (talk) 18:12, 2 January 2016 (UTC)

   Yes, for example *-kʷe and *-kʷe, or *pénkʷe and *pénkʷe. Even more when redirects are taken into consideration (*kapros and *kapros → *kápros), and even more when plausible future redirects are taken into consideration (*oynos and plausible *oynos → *óynos). I would be very surprised if no proto-language other than PIE had a form spelled *ne. —Aɴɢʀ (talk) 22:19, 2 January 2016 (UTC)

   Proto-Algonquian has ne- (Proto-Algic has n-, contrast PIE n̥-). - -sche (discuss) 05:04, 4 January 2016 (UTC)

5. Support per Daniel Carrero and Benwing2. Easier to find IMO. —Aryamanarora ^{(मुझसे बात करो)} 01:17, 4 January 2016 (UTC)
6. Support --profesjonalizm • reply 13:17, 4 January 2016 (UTC)
7. Support Feels more natural to me. This matches our current mainspace format. A similar alternative would be to have the reconstructions directly in the mainspace and start with *, for which AFAIK the objections were rather weak. We absolutely should not be moving the normal mainspace to one entry per language, which I see CodeCat above say. Also, this format makes entries easier to find: there is going to be a shortcut for the namespace so the reader only types rec:albʰós, and there comes the entry; in fact, the reader only types rec:alb, and there appears a list of items that are completions of that; try typing ws:pers into the search box to see how this works for Wikisaurus. I acknowledge that there will probably be fewer redirects than for the alternative but I do not see anyone showing us how large the problem is; it is possibly relatively small. On a procedural note, if a plain majority prefers the Reconstruction:Proto-Indo-European/albʰós format, let's use it; it is the status quo anyway. --Dan Polansky (talk) 09:34, 9 January 2016 (UTC)

Comments etc.

• Either one is fine with me. —Aɴɢʀ (talk) 09:34, 2 January 2016 (UTC)

  Statement of support added above. —Aɴɢʀ (talk) 16:52, 8 January 2016 (UTC)

• It looks like we're going to have a lot of supporters of each form. Perhaps each supporter should note whether the other form is also acceptable to him/her or whether, on the contrary, he/she supports only the form indicated. That might help decide what the general consensus is.​—msh210℠ (talk) 22:40, 5 January 2016 (UTC)
• As I mentioned above, I prefer the combined form but I'd be OK with the separated form. BTW I don't see the merging issue as a big problem; I've done lots of more complicated transformations using bots. The only thing that might be tricky is converting hard redirects into soft redirects; however, I imagine most of this can be automated as well. Benwing2 (talk) 22:17, 8 January 2016 (UTC)

  @Benwing2, CodeCat: I think we have a pretty solid consensus that's emerged, and we really ought to make the transition now that we have the namespace. Would you mind doing the honours? The trick is to ensure that relevant templates and modules are updated as soon as the moves are done, so we don't leave anything broken. —Μετάknowledge^{discuss/deeds} 04:59, 9 January 2016 (UTC)

  I'm not completely convinced there is a consensus given the relative number of users going the other way, but if everyone else thinks there's a consensus I'm fine with it. I can help move pages although I may be a bit busy until around the 13th or 14th of this month. If you need it before then, maybe User:CodeCat can help? BTW, CodeCat or anyone, how can I get a list of all appendix-only languages that should be moved to the Reconstruction space? Benwing2 (talk) 07:30, 9 January 2016 (UTC)

  On a procedural note, to want to close such a major decision after mere 7 days of voting seems improper to me. I would see 14 days as the minimum, or even 4 weeks typical of votes. Also, the discussion is very weak; I see very little in way of argument or links to specific places where arguments and reasoning can be found. --Dan Polansky (talk) 09:39, 9 January 2016 (UTC)

Color-coded EL

FYI: I was curious to see how much of WT:EL was voted and how much was unvoted, so I created User:Daniel Carrero/Color-coded EL.

Turns out it's about 75% unvoted. --Daniel Carrero (talk) 08:36, 2 January 2016 (UTC)

Interesting. Could you select less saturated colors to enhance readability? I get a headache just thinking about the page as it is. DCDuring TALK 13:16, 2 January 2016 (UTC)

Absolutely. I won't do that right now because I'm on my cell phone, but if anyone wants to do a search/replace on that page, go ahead. Just look for background-color: red and background-color: green. --Daniel Carrero (talk) 14:02, 2 January 2016 (UTC)

 Done, but imperfectly. My color selections were not quite pale enough, IMO. DCDuring TALK 18:12, 2 January 2016 (UTC)

Perhaps we should also distinguish between parts that have a vote created for them, from parts that don't, instead of marking them all red. --WikiTiki89 16:02, 4 January 2016 (UTC)

This is nice, thanks Daniel. I updated one section that I recalled a vote for, I assume that is Ok? - TheDaveRoss 17:11, 4 January 2016 (UTC)

@DCDuring: That's great, thanks.

@TheDaveRoss: That's great, too, thanks.

@Wikitiki89: OK, I did as you suggested. --Daniel Carrero (talk) 00:20, 5 January 2016 (UTC)

If people prefer just the green/red format, the page can be converted back. But I wonder if we would be able to create votes for all the unvoted sections later, thus defeating the point of having the additional yellow (I mean, "khaki") color for unvoted sections that have votes created for them. Better yet if they all pass, then EL would finally be 100% voted and thus User:Daniel Carrero/Color-coded EL would be deleted, lest it become a completely green, thus useless, version of EL. --Daniel Carrero (talk) 06:18, 5 January 2016 (UTC)

Actually, all of ELE was voted in. (I'm only half kidding.)​—msh210℠ (talk) 16:43, 5 January 2016 (UTC)

LOL, true. That vote even has "Replacing the contents of Wiktionary:Entry layout explained by the contents of (another revision of the same policy).", sounds pretty serious. (I'm half kidding, too.) --Daniel Carrero (talk) 19:16, 5 January 2016 (UTC)

Or perhaps the replacement of the voted on contents with identical new contents negates the voting done for the original content? Maybe we don't actually have a CFI or ELE. (I never kid.) - TheDaveRoss 19:19, 5 January 2016 (UTC)

We don't? Good. I always wanted to make an entry for a8idsah09d8has9dh, but CFI was in the way! --Daniel Carrero (talk) 19:59, 5 January 2016 (UTC)

English possessives

My earlier posting on this: Wiktionary:Tea room/2011/April#English possessives.

A number of words indicate the possessive in English. These include have, of, -'s, their (my, et al.), and theirs (mine, et al.). For some of those words, we have a simple "marks the possessive" or similar sense, which is not very informative. For others of those words, we have specific senses — but those senses are not the same for two possessive words, though they may overlap.

What we need IMO is one central location for definitions of the possessive, and for all the possessive words to link thereto. I think this should be an appendix, say appendix:English possessives, and that all the possessive senses of these words (which is not always all the senses) should be referred to the appendix in lieu of the definition lines. A very rough draft toward such an appendix is at [[User:Msh210/English possessives]]; please feel free to edit it.

I would love to see what others think of this.​—msh210℠ (talk) 08:59, 5 January 2016 (UTC)

Seems like a good idea. Where would the links be? Under "See also" or something more likely to be clicked? DCDuring TALK 11:30, 5 January 2016 (UTC)

I'm thinking it would be a sense. For example, for my, we now have four senses ("Belonging to me", "Associated with me", "Related to me", "In my possession": those are not summaries but the entire definition lines). They'd be replaced by a single "{{n-g|Possessive of me, used before a noun phrase: see Appendix: English possessives}}" or some such. Likewise, for your we have four senses, of which the last two ("A determiner that conveys familiarity…" and "That; the specified") would remain in place but the first two ("Belonging to you; of you; related to you") would be replaced by something like above. Likewise, several of the subsenses of of could be replaced by something like "{{n-g|marking the possessive, see appendix…}}" and usexes.​—msh210℠ (talk) 15:13, 5 January 2016 (UTC)

Hmm. If I had to coin a slogan, it would be "case envy". Think about the last item in your list: "concatenation of noun phrases" (to which you've put ????). This is simply using a noun phrase to qualify another noun phrase, and there is essentially no limit to the nature of the relationship to which this refers, and any attempt at listing the "meanings" is doomed. (I really suggest you should remove this from the list.) The other terms (constructions) you have listed are very close to what might be "Genitive case", if we had a proper case system (or a system of unvarying particles, like Japanese の (no)), and trying to list the "meanings" of the genitive is obviously hopeless. After all, in many cases, it is a purely grammatical construct: if I say "I approach this question with an open mind", then want to nominalise this in a later reference, I say "My approach..." There is no more a "meaning" of "my" here than there is a "meaning" of "I" in the first sentence.

All that said, I think an appendix on possessives would be a Very Sensible Idea. It should show the pronoun table, rules for apostrophe-ess, including noting that this is not normal morphology, because you can say things like "The King of Persia's right elbow". It should also point out the way in which these can be seen as nominalisations of the verb "to have" (I learned about four foreign languages before I met one two which don't have one, and it is a very enlightening experience.) I hope this makes up for the negative tone of my first paragraph. Imaginatorium (talk) 15:57, 5 January 2016 (UTC)

Note that although concatenation of two nouns has several meanings, one of them is the possessive (at least according to w:English possessive); the same is true for of and have and even -'s, all of which have meanings other than the possessive.​—msh210℠ (talk) 16:35, 5 January 2016 (UTC)

What does "the possessive meaning" mean? (Serious question: I think it is semantically empty.) I can't actually see where it makes the claim about concatenated nouns "meaning" "possessive", but I'm sure one can find an example, for some values of "possessive meaning" at least. Imaginatorium (talk) 17:35, 5 January 2016 (UTC)

@Imaginatorium Re "possessive meaning": Good question. I guess when I think of possessive meaning, I think of meanings typically held by both -'s and his. But doubtless linguists have done some work in this area already and we don't need to reinvent the wheel. There's some stuff to read in the "Semantics" section of the WP article.   Re WP: It's in the "As determiners" section: "the system failure, using system as a noun adjunct rather than a possessive" (where "possessive" means with -'s morphology, not with possessive meaning).​—msh210℠ (talk) 18:39, 5 January 2016 (UTC)

Definitions at town and city names

See (deprecated template usage) Woodstock. In many town-name entries there are lists similar to this, I am wondering if it would be better to replace all of the specific towns with more generic definitions a la given and family names. I am thinking of something along the lines of "A town or city name in the US, Canada and England." Are the specific definition lines of value? It seems to be treading the line of encyclopedic, and Wikipedia's disambiguation pages do a better job I think. - TheDaveRoss 14:48, 8 January 2016 (UTC)

Plenty of dictionaries include these kinds of lists, and it appears Wiktionary is following tradition in this case. {{place}} could be useful in these cases though. Personally, I'm fine with generic definitions or lists. —Aryamanarora ^{(मुझसे बात करो)} 15:50, 8 January 2016 (UTC)

I agree that this is reduplication of WP content, and not helpful in a dictionary sort of way. Traditional dictionaries do often include geographical names, either in the body, or in an appendix, but then, they didn't have the option of a WPlink. In at least some cases there could be an etymological overview -- how this name spread (e.g. from England to the former colonies, sort of thing). Imaginatorium (talk) 04:49, 9 January 2016 (UTC)

See Talk:Paris. The definitions of Woodstock could be replaced by "Any of a number of cities and towns in the US, Canada and England", or subsenses could be listed under that definition,in a fold-up list preferably. @Lo Ximiendo is currently adding definitions of specific places, many of them useful, but a comprehensive list is not realistic for the most common place names.. --Makaokalani (talk) 12:16, 9 January 2016 (UTC)

To treat all of the Parises as if they were lexically equivalent is silly, as is making Woodstock, Troy, Amsterdam, Geneva, Birmingham, Rome, Utica, Syracuse, all in New York State; Moscow, ID; and London, ON equivalent to all the others. Often one, two, or a few of the places are distinguished in general or regional discourse and might merit inclusion on some lexical grounds. Our attributive-use standard for including proper nouns made lexical sense to me, but apparently not to others. We are stuck with voting on these things, one at a time, since the language of that standard was explicitly voted down without any comparably effective replacement. DCDuring TALK 13:59, 9 January 2016 (UTC)

Category:en:Rivers in Canada

@CodeCat I made Category:en:Rivers in Canada. Is there a way to enable this empty category into something else? Thank you in advance. --KoreanQuoter (talk) 04:23, 9 January 2016 (UTC)

-èd words

For most languages, we don't include the forms with macrons and stress markers where these are usually ignored in writing. So... where does this leave entries like wingèd, learnèd and cursèd? (If nothing else, we need to add pronunciations to these entries.) Smurrayinchester (talk) 17:33, 9 January 2016 (UTC)

I don't think these are 'usually ignored' just rare, obsolete forms that were used for a relatively short period. Renard Migrant (talk) 18:43, 9 January 2016 (UTC)

Well, some scholarly and pseudo-scholarly material still use them, e.g in some critical version of Shakespeare's texts. I say we keep 'em. —Μετάknowledge^{discuss/deeds} 18:46, 9 January 2016 (UTC)

But even then they're independent stress markers of poetical criticism and not part of the actual spelling of the word, are they not? Sounds comparable to the accents used in Russian text books for me. Korn [kʰʊ̃ːæ̯̃n] (talk) 20:26, 9 January 2016 (UTC)

True, but is it not worth keeping them in the dictionary in case someone wants to look one up to see what the stress marker means? (We should have pronunciation for these so that people can see the difference between them and the unnaccented word.) Andrew Sheedy (talk) 21:49, 9 January 2016 (UTC)

The entry for "winged" doesn't have a Pronunciation section, but if it did, it would surely just list the normal one. Then an entry (or at least a note) for the accented version should mention that this is not just a poetic spelling (it isn't, really!) but a spelling indicating a poetic pronunciation. Imaginatorium (talk) 06:52, 10 January 2016 (UTC)

Russian cognate

@ cognate, under the linguistics examples, it has:

"English mother is cognate with Greek μητέρα ‎(mētéra), German Mutter, Russian маmь ‎(matʹ) and Persian مادر ‎(madar)."

My focus is on the Russian term: it appears as маmь, although it is linked to мать. It doesn't have an alias in the arguments. Why is this, does anyone else see what my browser is rendering, or is it just me ? Leasnam (talk) 01:46, 10 January 2016 (UTC)

Please rephrase your question it doesn't make sense. (deprecated template usage) мать (matʹ) is linked as it should be. What alias do expect? Inflected forms? It's a lemma. Stresses? Not required for monosyllabic Russian words.--Anatoli T. ^{(обсудить}/^вклад) 04:30, 10 January 2016 (UTC)

I think he's just saying that it looks strange on his browser. I don't see that, but m is the Russian representation of т in an italic font, so possibly there's some weird font issue on your system? Benwing2 (talk) 05:14, 10 January 2016 (UTC)

Hi - Thank you, all ! Yes, it appears as an "m", but mousing over clearly shows the "t". oK, it's just me (and perhaps some others) then, not an issue of concern :) Leasnam (talk) 19:50, 10 January 2016 (UTC)

The question makes perfect sense: you are seeing a script lower-case Cyrillic 'T', which looks like 'm', instead of a "regular" lower-case Cyrillic 'T', which looks like a small-cap 'T'. I see the text in a sloped sans-serif font (the browser says the font is "DejaVu Sans Oblique"), so I see a sloped version of the normal мать. It would help if we knew what browser, OS, font selection etc etc you are using.

OS is old, Windows 7. Browser is Chrome. Leasnam (talk) 19:53, 10 January 2016 (UTC)

I think this sort of problem is worth considering very carefully. The problem is that (of course) stuff like HTML and CSS were conceived by clueless monolinguals (I mean clueless about anything not monolingual), so it is not easy to avoid unpredictable odd side-effects. Do we have any HTML/CSS gurus who could understand why I see a sloped font and @Leasnam sees an "italic" font, which looks like script? (I can't see anything in the CSS rules which the Firefox Inspector shows which would make it "sloped" or "italic".) Imaginatorium (talk) 06:49, 10 January 2016 (UTC)

Cyrillic т (t)'s cursive (and thus italic, too) form resembles an m. Observe:

• т
• т

Copy and paste "Russian маmь ‎(matʹ)""Russian мать ‎(matʹ)" into Notepad; there is no "alias".

—suzukaze (t・c) 06:57, 10 January 2016 (UTC)

That exactly demonstrates the problem: you cannot discuss this stuff by pasting in the problem text and saying "Look!" -- I see something quite different from what you see. In fact the Wikipedia double-quote trick does not generate italics (at least for me), but generates a sloped sans-serif font. The text you have presumably copied above, i.e. "маmь" is not Russian at all: it's a sequence of Cyrillic ма followed by Roman m followed by a Cyrillic ь. (I don't have "Notepad", and I don't know what you mean by "alias".) Imaginatorium (talk) 07:53, 10 January 2016 (UTC)

I wasn't replying to you, I'm sorry if it seemed that way D:

But clearing things up: 1. Leasnam mentioned an "alias". 2. my "Russian маmь ‎(matʹ)" was copy-and-pasted from Leasnam's message, which contains mixed Cyrillic/Latin rather than pure Cyrillic (maybe that was a bad idea) —suzukaze (t・c) 07:56, 10 January 2016 (UTC)

I've reformatted the example sentences because if you have running text in italics and then there's something that would normally be italicized, the thing to do is put it back in roman. —Aɴɢʀ (talk) 15:22, 10 January 2016 (UTC)

By "alias" I am referring to the display text (arg 3?), e.g. {{m|en|hello|HELLO}}, where "HELLO" acts as an alias (maybe that's not the correct term, sorry) Leasnam (talk) 19:58, 10 January 2016 (UTC)

I see it as мать now Leasnam (talk) 21:22, 10 January 2016 (UTC)

Just remember that Russian uppercase М and lowercase м look alike except for height (no rounded humps). Lowercase м does not look like т, and т cannot be a case of М; т is lowercase italic Т. —Stephen ^(Talk) 22:07, 10 January 2016 (UTC)

crimson in Template:table:colors

An anon (Special:Contributions/46.30.181.2) added crimson to Template:table:colors and language subtemplates.

As far as I'm concerned, I think I'd allow it, assuming it was all done correctly. (I'd just move crimson to someplace else in the order of colors) I have an inclusionist point of view concerning that template. I probably wouldn't mind having that table with 50, or maybe 300 colors, it could be made collapsible to save space.

Just my two cents. I'd understand if other people want to delete "crimson", since it's close enough to red. --Daniel Carrero (talk) 07:17, 10 January 2016 (UTC)

The problem with having 300 colours is that the swatches become quite meaningless. Everybody (almost!) can agree on a red, a yellow, and a green, but once you get into the silly territory and have to pick separate swatches for grey, "timberwolf", "silver birch", and "shiny new saucepan", they aren't helpful or meaningful any more. Equinox ◑ 14:00, 11 January 2016 (UTC)

I vote on removing the following: strongly: crimson, cream, azure; weakly: teal, indigo. — Ungoliant ^(falai) 14:24, 11 January 2016 (UTC)

• There shouldn't be more than 18 colors in that thing: the 16 HTML colors (red, maroon, yellow, olive, lime, green, cyan, teal, blue, navy, magenta, purple, white, silver, gray and black), then maybe indigo and orange, but anything beyond that's too much @Daniel Correro, if people want the full 300, there are appendices that list all of them, so there's no point in Template:table:colors duplicating that. Purplebackpack89 15:53, 11 January 2016 (UTC)

• Don't see why their being HTML colours matters. Surely brown is a much more basic and useful colour than "teal" or "maroon", which are basically blue and red. Equinox ◑ 19:04, 11 January 2016 (UTC)

  Setting aside the issue that teal and maroon are actually a long ways away from blue and red (at least HTML-wise), I have an alternate proposal: black, blue, brown, cyan, green, gray, magenta, orange, pink, purple, red, white and yellow. Purplebackpack89 19:53, 11 January 2016 (UTC)

  If we are going to use only basic colors, why magenta? The others seem fine. --Daniel Carrero (talk) 19:55, 11 January 2016 (UTC)

  Magenta (and cyan) give us the three secondary colors of light, while the rest are the colors you're most likely to find in a relatively small box of crayons, markers or colored pencils. Purplebackpack89 20:11, 11 January 2016 (UTC)

Adding a parameter or two to {{m}} and {{l}}

What do other people think of the idea of adding a parameter to {{m}} and {{l}} that would display the language name? At the moment, in etymology sections for example, if we want to write "compare (deprecated template usage) [etyl] German Mutter" we write compare {{etyl|de|-}} {{m|de|Mutter}}. Wouldn't it be nice to write compare {{m|de|Mutter|name=1}} instead? Not only is it fewer keystrokes, it ensures that the language named and the language tagged are the same, so there won't be any mistakes like compare {{etyl|fr|-}} {{m|de|Mutter}}, which do happen from time to time. For {{l}}, since it's more often used in lists, the language name could be preceded by a colon, as is the case in Descendants lists. For example muoter#Descendants could just list * {{l|de|Mutter|name=1}} instead of * German: {{l|de|Mutter}}. This would have the same two advantages: fewer keystrokes, elimination of the chance of a mismatch. Any thoughts/ideas for improvement? —Aɴɢʀ (talk) 15:49, 10 January 2016 (UTC)

• Support. Great idea; I wish I'd thought of this myself. —Μετάknowledge^{discuss/deeds} 15:54, 10 January 2016 (UTC)
• Support. This would relieve some of the pressure for misuse of {{inh}} and {{der}} in etymology sections, not to mention simplifying that {{etyl|xyz|-}} {{m|xyz|blah blah blah}} typing exercise. Chuck Entz (talk) 16:09, 10 January 2016 (UTC)
• Oppose, redundant to {{cog}}. —CodeCat 16:19, 10 January 2016 (UTC)
  • I was unaware of {{cog}}; however, {{cog}} still isn't right for things like Descendants lists. —Aɴɢʀ (talk) 16:48, 10 January 2016 (UTC)
    • I can only support it for descendant lists if we also change the format of translation tables accordingly. —CodeCat 16:51, 10 January 2016 (UTC)
      • As in * {{t|de|Mutter|f|name=1}} instead of * German: {{t|de|Mutter|f}}? I'm down with that. —Aɴɢʀ (talk) 19:28, 10 January 2016 (UTC)
        • It's clearly a good idea as it prevents mistakes where you don't know which is the mistake, the language name or the language code. The template's already expanding the language code into a language name, so doing it twice shouldn't pose a problem. Renard Migrant (talk) 16:27, 11 January 2016 (UTC)
• Support. Andrew Sheedy (talk) 23:12, 11 January 2016 (UTC)

• Oppose only because I think it would look nicer to have a separate template for that, something like {{name-l|de|Mutter}} and {{name-t|de|Mutter|f}} (maybe that's not the best naming scheme, but I definitely think that whatever it is should be added to the left of the l or t. --WikiTiki89 23:21, 11 January 2016 (UTC)
  • I would support this over the other option. Andrew Sheedy (talk) 02:32, 12 January 2016 (UTC)

Away until Thursday.

I will be away for a few days. Normally, I would ask that the dictionary be finished by the time I get back, but this time I am going to be far more modest, and will merely ask that you get all of the WT:RFD and WT:RFV discussions finished and cleaned up. Of course, this includes WT:RFDO. Cheers! bd2412 T 18:47, 10 January 2016 (UTC)

This joke never stops getting old. —Aɴɢʀ (talk) 21:20, 10 January 2016 (UTC)

Perhaps it never stopped to begin to stop being a joke? --WikiTiki89 02:39, 12 January 2016 (UTC)

• I'll work on it. I've appreciated your efforts to keep RFD clean. —Μετάknowledge^{discuss/deeds} 02:35, 12 January 2016 (UTC)

Let's make a WT:FUN competition in which the last person to edit Wiktionary and make it complete wins. --Daniel Carrero (talk) 23:11, 14 January 2016 (UTC)

I have an idea for a project: "A visual representation of the etymology of words using trees"

Hi everyone, I am new here. I am developing a project - "etytree" (click here) - to visualize the etymological tree of a word using an interactive tool. Basically I have built a graphical interactive web page using d3.js - a JavaScript library for manipulating documents based on data - where you search a word and then you visualize the etymological tree of the word (ancestors, cognates, on the same tree). Right now I have only developed a demo for 10 words and my next step will be to build an extractor of etymological relationships from Wiktionary. It won't be easy but definitely interesting.

A screenshot of the etymological tree of the English word 'butter' as produced by 'etytree'

I have some ideas on how to do it but I would like to get some feedback from people that are experts in the field / interested in the topic + I'm writing a grant proposal (click here) because I need funds.

Do you think this is the right place to describe my project and ask for feedback? Thanks! --Epantaleo

This is definitely a fascinating idea. Thanks for describing it. Not sure if this is the right place to ask for feedback, but if not, I'm not sure where is better. If you have specific questions about extracting the etymological links (which you are right won't be easy), you might ask at the Grease Pit. Benwing2 (talk) 09:33, 12 January 2016 (UTC)

This is really cool! UI could use some polishing (the ISO codes are a little small) but a great concept. —Aryamanarora ^{(मुझसे बात करो)} 23:01, 12 January 2016 (UTC)

Wiktionary:Word of the day/January 11

Could an admin please change the word of the day slightly, from "A snake" in sense 1 to "Any snake". The current formulation is confusing - there is still a snake called the "adder"; what has changed is calling other snakes "adders". Smurrayinchester (talk) 11:19, 11 January 2016 (UTC)

•  Done I also replaced the red links with blue, one to a synonym that we have and another to a WP link (via {{vern}}. DCDuring TALK 13:49, 11 January 2016 (UTC)

Filling the CFI donut hole

At present, it's possible for an abbreviation, a derivative or a slang term of/for certain terms to be included as an entry, but not for the term that is being abbreviated, derived or corrupted to itself have an entry. This "donut hole" seems nonsensical to me IMO, and we should expand CFI to fix it. Something along the lines of "Any word or phrase that has an abbreviation or derivative term derived from it that passes CFI will also pass CFI." IMO, no harm will be done to the project in allowing these additional entries. Will start a vote on it if others think filling this hole is a good idea. Purplebackpack89 15:33, 11 January 2016 (UTC)

I disagree; when the derived term is a word, include it, sure, but things that aren't words shouldn't get a free pass based on having a word derived from them. It's backwards thinking (as in literally, in the reverse order). Renard Migrant (talk) 16:25, 11 January 2016 (UTC)

At first blush I agree with Renard, but I might not be thinking of the same sorts of terms as you are so I would like some examples of types of entries. I am thinking of things like (deprecated template usage) FBI, which is best handled with a link to Wikipedia I think. - TheDaveRoss 16:38, 11 January 2016 (UTC)

I think we're talking about things like AFAICT, the existence of which should (in Purplebackpack's view) or should not (in Renard Migrant's view) automatically permit the existence of as far as I can tell. —Aɴɢʀ (talk) 18:57, 11 January 2016 (UTC)

I would not favor the automatic inclusion extending to proper nouns, eg, inclusion of FTC should not lead to automatic inclusion of Federal Trade Commission. I haven't really looked for more subtle faults in the proposal, though I expect there to be quite a few. DCDuring TALK 23:04, 11 January 2016 (UTC)

FBI (Federal Bureau of Investigation) is as good in terms of an example as AFAICT. Purplebackpack's of course free to clarify but I do think he means literally everything. Also I don't think the distinction is nonsensical, it has clear boundaries and a clear rationale. Renard Migrant (talk) 23:15, 11 January 2016 (UTC)

I do mean everything, in case of acronyms or other derived terms. When I created this, I think of acronyms of things that have never been created, were deleted, or (in the case of field goal percentage) were about one vote away from deletion. At present time, CFI as worded is too restrictive towards words like these. Yes, the result maybe creates some words of dubious value to the project, but better to have a CFI that's overly broad than one that's overly restrictive. There may be quite a few, but I don't think it's as many as DCDuring thinks...and remember, whenever one of them goes to RfV, you'd be RfVing for two, because if the derived word fails RfD or RfV (and thereby fails CfD), the root does to. Purplebackpack89 00:39, 12 January 2016 (UTC)

Strongly oppose. This would force us to include many unnecessary phrases, like as far as I can tell, rolling on the floor laughing, and fucked up beyond all recognition. Oh and rolling on the floor laughing my fucking ass off (too bad I couldn't find cites for ROFFLMFAO, or that would have been one word longer). Not to mention, this would get very messy if the etymology is unclear or disputed: Should we include all of laughing out loud, laughing online, and lots of laughs? Should we go as far as to include fornication under consent of the king and for unlawful carnal knowledge? --WikiTiki89 01:29, 12 January 2016 (UTC)

I dispute your claim that those are "unnecessary". As for "should we...", I personally think we should. Also, why do you guys insist on drawing from the longer and more absurd side of the spectrum, rather than accepting that those are the price to pay for a great many shorter, more important and less controversial words and phrases? Purplebackpack89 02:30, 12 January 2016 (UTC)

Care to give an example of a "shorter, more important and less controversial" word or phrase that would otherwise fail CFI? --WikiTiki89 02:32, 12 January 2016 (UTC)

What's so bad about having laugh out loud, or true shooting percentage? Or any number of other things that are slipping my mind at the moment. As I've said, you need to look at the big picture, not just random seven word entries that happen to pop into your head. Your argument boils down to "I don't think we should have those entries", even though there are no technical limitations preventing us from having them. And don't say, "more entries means more vandalism", because it doesn't...more editors means more vandalism. Purplebackpack89 05:38, 12 January 2016 (UTC)

Also, let me correct a misconception Wikitiki, Equinox and DCDuring routinely mention whenever expanding CFI comes up. Expanding CFI doesn't force any thing. It doesn't mean that people have to go out and create some random seven word entry. It doesn't even mean people will go out and create that entry. Purplebackpack89 05:42, 12 January 2016 (UTC)

If laugh out loud should be included (and perhaps it should, as some kind of interjection), it should be included on its own merit, and not simply due to the existence of LOL. My point is exactly that your suggestion would include everything that would not merit inclusion on its own. Anything useful that would be covered by your suggestion would be covered by other CFI criteria. And perhaps we should add more criteria to CFI, but these criteria should judge terms on their own and not based on other terms. --WikiTiki89 15:45, 12 January 2016 (UTC)

@Wikitiki89 You're ignoring the perceived problem this thread seeks to address: that some definitions we have (such as LOL) are dependent on other definitions (such as laugh out loud). Can I at least get you to concede that people who don't know what laugh out loud means won't be able to discern what LOL means either? Once you've conceded me that, any chance I can get you to concede that this problem is compounded by the fact that many acronyms, abbreviations and corruptions aren't defined except by the thing they are abbreviating? And maybe you'll acknowledge a that it isn't easy to figure out what laugh out loud means using only Wiktionary? (I doubt the majority of editors would think to look for laugh + out loud, laugh + out + loud doesn't really give you the proper definition and many wouldn't have the patience to look it up anyway). Purplebackpack89 17:53, 12 January 2016 (UTC)

I'm not going to concede anything. If LOL is inadequately defined, that's a problem only with the entry LOL. If laugh out loud is idiomatic and needs explaining, then the existence of LOL is still irrelevant. --WikiTiki89 18:20, 12 January 2016 (UTC)

So you believe it's somehow possible that you can know what LOL means even if you don't know what laugh out loud means? That doesn't seem to make any sense at all! If LOL stands for laugh out loud, and you don't know what laugh out loud means, you can't use the expression LOL properly. Also, if we had a definition for laugh out loud, we could just link to it and that would solve the problem of LOL's definition being inadequate. We have the functionality of linking entries to each other, might as well use it. Purplebackpack89 18:34, 12 January 2016 (UTC)

Let me rephrase. There are two possibilities:

1. laugh out loud is SOP, which means that defining it doesn't help anyone understand anything that they couldn't have understood from looking up its parts.
2. laugh out loud is not SOP, which means that your proposal is not necessary for it to have an entry.

In either case, I think defining LOL as "laugh out loud" is inadequate. --WikiTiki89 18:52, 12 January 2016 (UTC)

Setting SOP (which is bullshit, I might add; people have never proven that readers CAN actually make those connections) aside, if defining LOL as "laugh out loud" is inadequate, there are two ways to fix it:

1. Add more to the definition of LOL
2. Create the definition of laugh out loud and link to it.

I advocate the latter. Purplebackpack89 19:30, 12 January 2016 (UTC)

What I'm saying is that even if we had a research-paper length definition of laugh out loud, defining LOL as "laugh out loud" would still be inadequate. They are not the same thing. So yes, what I'm saying is we should add more to the definition of LOL. If SOP is "bullshit", then campaign against that. You still won't get much support, but at least you'd be being honest about what you want. Stop beating around the bush with these ridiculous proposals. --WikiTiki89 19:41, 12 January 2016 (UTC)

If I believe a proposal is a good idea, I'll make it. Equinox suggested I make this proposal after an RfD (or was it an RfV?) vote I made. I believe I've tried one-shot SOP dismantling already; that didn't work, so I'm settling for dismantling it piecemeal, starting with the most egregious examples. Purplebackpack89 05:14, 13 January 2016 (UTC)

The proof that human beings can make SoP "connections" is in the fact that people who learn a language can produce original sentences as well as individual words. Jesus H. Christ. Equinox ◑ 21:14, 12 January 2016 (UTC)

Equinox, that a) assumes that everybody who uses this dictionary has enough comprehension of English to get to the construction of proper sentences, b) two-word phrases are all constructed the exact same way sentences are, and c) a person would never voluntarily look up a two-, three- or four-word phrase unless it passed our CFI. I can't in good faith make any of those leaps, sorry. Purplebackpack89 05:14, 13 January 2016 (UTC)

Chances are that if someone is using an English dictionary, they know enough English to construct proper sentences, or at least understand what is proper and what isn't. I'm not perfectly fluent in French, but whenever I stumble across a French phrase with which I am not familiar, I am nearly always able to intuitively determine whether I should look up an individual word or the entire phrase. I think you underestimate people's intelligence, and I don't think you understand that understanding English is a prerequisite for using a dictionary written entirely in that language. Andrew Sheedy (talk) 05:47, 13 January 2016 (UTC)

"laugh out loud" being SOP, Purplebackpack89's reasoning could be used to argue the inclusion of any SOP construction, couldn't it? Suppose there's a person who does not understand properly the sentence "I see dead people" (which is SOP). That being SOP, he/she should look for I + see + dead + people. Suppose we are discussing whether we should have an entry I see dead people. The argument goes this way: if there's an abbreviation ISDP for it, keep that entry, otherwise delete that entry. --Daniel Carrero (talk) 08:16, 13 January 2016 (UTC)

• Oppose per Wikitiki. Our dictionary would be rendered a laughingstock were we to include these. This is not the right way to go about making CFI more inclusive. —Μετάknowledge^{discuss/deeds} 02:34, 12 January 2016 (UTC)

  We're a laughingstock as it is because people can't find the definitions of words we need, @Metaknowledge. As usual, people seem to ignore the fact that if a person can't find the definition that they are looking for, they leave Wiktionary, find it somewhere else, and probably continue using that somewhere else instead of Wiktionary. The whole "if we do this, we'll be a laughingstock" line of "argument" is completely fallacious. Purplebackpack89 05:35, 12 January 2016 (UTC)

  My experience is that people generally have an idea of what words can be expected to be contained in a dictionary, and they tend to find them in languages where we have good coverage. But why don't you amend your suggestion instead of baselessly calling criticisms of it fallacious? —Μετάknowledge^{discuss/deeds} 05:38, 12 January 2016 (UTC)

  @Metaknowledge The reason I'm critical of your "laughingstock" claim is you haven't said why we'd be a laughingstock. You seem to be implying that anything above the "general idea" (which, I might add, doesn't exist, at least not a single one that's anywhere near the same for everybody) is a waste of space, and if people discover we have entries above and beyond the "general idea", they will think it absurd for one reason or another. That idea has no basis in either provable fact or in common sense; the people most likely to look for/find the definitions I'm proposing to include are the people the least likely to find it absurd that we have them. Furthermore, there is no technical need to artificially constrain ourselves to the words we're expected to have. Maybe you meant something else when you said what you did, but as you've said nothing else, it's hard to believe otherwise.

  As for amending my proposal, a) I truly believe the project would be better if the proposal were adopted verbatim, and b) I don't really know in what direction I'd go to amend it to placate you, Wikitiki and others. Purplebackpack89 05:57, 12 January 2016 (UTC)

@Purplebackpack89 If the spectrum that would be included by your proposal includes terms that look like ones we wouldn't want, you need to come up with some wording that doesn't include them. A "proposal" that consists of a grand statement, some hand-waving, and hope for good outcomes obviously isn't going to satisfy those who are skeptical of the desirability of quantity increases at Wiktionary. A policy proposal needs a little bit more thought. DCDuring TALK 03:30, 12 January 2016 (UTC)

Well, we can spend the rest of this thread thinking and discussing. It doesn't have to be perfect on the first go. Purplebackpack89 05:32, 12 January 2016 (UTC)

@Purplebackpack89 Impulse control is one of the wonderful consequences of having a deliberative body to mull over questions of policy. DCDuring TALK 11:09, 12 January 2016 (UTC)

Oppose Your initial premise has a tantalising air of plausibility, but does not stand up to careful thought. Some abbreviations which require explanation refer to perfectly ordinary language which does not. Some words which require explanation have (typically variable) abbreviations used in context, which do not require explanation. Therefore the two inclusion decisions are somewhat independent. Of course, when considering any particular case, the existence of an abbreviation entry can be taken into account. And in the end I do not think you have given a single convincing example. Imaginatorium (talk) 08:55, 12 January 2016 (UTC)

I think on a usability level, this is not a user-friendly proposition. Changing creating an entry for laugh out loud in order to change [[laugh]] [[out loud]] to [[laugh out loud]] is not user friendly, because a user would be better off understanding what laugh and out loud mean. This won't help anyone understand more words and abbreviations. I should note, that not the intention of this proposal either, so I wouldn't expect it to. But I see no value in having entries allowed per WT:CFI that won't help anyone understand any words or phrases. Renard Migrant (talk) 18:32, 12 January 2016 (UTC)

I've never bought into your line of reasoning that we're somehow more user-friendly with fewer entries. The only thing that is user-friendly is having all the entries people would look for. If a person looks for laugh out loud, they should be able to find it; it's doubtful whether even looking for out loud would even cross their mind. And the entry for "laugh out loud" would help that person understand the phrase "laugh out loud". I'm sorry, but since you insisted on bringing user-friendliness into this, my belief is that perfect user-friendliness would call for a complete abolition of SOP and anything else restricting verifiable entries. That's not what I'm advocating in this proposal, but that's what would generate optimum user-friendliness. Furthermore, "helping people understand more words" isn't the same thing as user-friendliness. Purplebackpack89 05:07, 13 January 2016 (UTC)

Because users need to be able to speak English as opposed to learning phrases verbatim. If you learn "I have a cat" verbatim you won't know what "I have a dog" means because you don't know what any of the individual words mean. But if you learn the word I, have, a, cat and dog you'll know what "I have a cat" and "I have a dog" means. Are you genuinely saying it's just a numbers game? We should be based purely on the number of entries we have not what they are and what they contain? I mean, we could have picture of a tall man with a dog on his lap just purely because it's one more entry than we have now. Like I said, you're not claiming this is a user-friendly feature and I think you're right not to, as the aim of this proposal is not to make Wiktionary more user-friendly; it's to satisfy you personally. Renard Migrant (talk) 14:34, 13 January 2016 (UTC)

In many ways, being more user-friendly and satisfying me personally are one and the same, because making the project more user-friendly is one of my goals for the project. If you're thinking about user-friendliness, you need to think less about what people are learning and more about what people are looking for. I have a cat is not something that would be allowed by this proposal, but something like laugh out loud or anything else that's commonly acronymed is. A person who is searching for the definition of "laugh out loud" might not want to or think to to break it into its component parts, and even if he/she does want to or think to, giving them only one avenue isn't user-friendly. In essence, Renard, your line of reasoning forces people to look for certain things. To do so isn't user-friendly. Am I saying that user-friendliness is a numbers game? Yeah, pretty much. And I again say that what you're advocating isn't user-friendliness per se. Purplebackpack89 14:48, 13 January 2016 (UTC)

Don't be so sure about 'I have a cat'. Also, you don't have a monopoly on what constitutes user friendliness, on who users are, or on what their needs might be. The argument that something should be included merely because it might be of use to someone at some point is irrelevant, we also have a scope. We don't try to be Wikipedia, we don't try to be a stock price index, we don't try to be IMDB. We are trying to be a dictionary. The argument is that all of the phrases which you propose to include are not material for a dictionary. - TheDaveRoss 15:05, 13 January 2016 (UTC)

But, @DaveRoss I am entitled to my opinion of user-friendiless and inclusiveness, and I am entitled to advocate that policy reflects my point of view. Purplebackpack89 15:11, 13 January 2016 (UTC)

Oppose because of...everything written here. SOP and WT:CFI exist specifically so we don't have entries like laugh out loud. —Aryamanarora ^{(मुझसे बात करो)} 23:11, 12 January 2016 (UTC)

To continue with the metaphor, what's wrong with a donut with a hole in the middle? Renard Migrant (talk) 14:34, 13 January 2016 (UTC)

If there wasn't a hole in the donut, there'd be more donut. Purplebackpack89 14:48, 13 January 2016 (UTC)

Without a hole it wouldn't be a donut, and there would be fewer of the doughballs than there would have been donuts given the same amount of dough. DCDuring TALK 15:03, 13 January 2016 (UTC)

I believe the two are made separately. Purplebackpack89 15:11, 13 January 2016 (UTC)

• Withdrawn Purplebackpack89 15:11, 13 January 2016 (UTC)

Internationalisms in etymologies

In the modern world, many languages that came later than others into a particular academic field or the like borrowed many words from an international pool of terminology, rather than from any particular language. These are then often naturalized in a systematic way, which helps hide the direct source of the borrowing, if there even was one. The most prominent example of this are words with the suffix derived from Latin -tiō. Good examples are virtually all the words in the translation tables at radio, civilization, and physics. My question is, how should we handle the etymology sections of these terms? One thing we sometimes do is say "Ultimately from Latin/Greek X", but I find that insufficient. --WikiTiki89 20:03, 12 January 2016 (UTC)

I quite like "coined based on". Renard Migrant (talk) 22:37, 12 January 2016 (UTC)

Coined based on what? It's not the wording that's the problem, it's what do we link to? --WikiTiki89 23:19, 12 January 2016 (UTC)

You're going to have to rephrase it then, I don't understand. Renard Migrant (talk) 14:22, 13 January 2016 (UTC)

Ok, so give me a full example of the etymology section of, lets say, Turkish radyo, and I'll explain what I mean based on that. --WikiTiki89 17:53, 13 January 2016 (UTC)

In some cases, a little research will reveal which language the scientific word was first coined in. For example, homosexual was first coined in German, though most languages' words look as if they come from a New Latin homosexuālis. —Aɴɢʀ (talk) 16:02, 13 January 2016 (UTC)

Yes, but homosexual did not go directly from German to every other language. --WikiTiki89 17:53, 13 January 2016 (UTC)

I see what you're getting at. Many languages created their cognate terms for homosexual at a time that cognates had already established itself in many languages (German, English, New Latin, French, Russian, etc), and so the creation probably proceeded along the lines of "well, everyone else calls it this" rather than "German calls it this". It's probably still possible to decide which specific language it was borrowed from / coined based on in a lot of cases, but in those where it isn't, I'd say something like "Coined based on English homosexual, German homosexuell, French homosexuel, etc, as if from New Latin homosexualis". - -sche (discuss) 01:37, 15 January 2016 (UTC)

Yes, that's exactly what I'm talking about. The problem is, that's a lot to add. This is a very common situation in many languages and I was hoping we could get some kind of standard format for it. Also, the problem remains of which language to categorize it under. Perhaps we shouldn't categorize it under any language and create a new category for "Internationalisms". Also, should we link to the "New Latin" term? --WikiTiki89 03:08, 15 January 2016 (UTC)

Yeah, the drawback to what I suggested is that it's a lot to add and a lot that will get duplicated (potentially) across many entries. Perhaps we could say "From English foo and cognates thereof in other languages", potentially using a template to keep the wording the same across many entries, and then let foo#English list the other cognates. Or for words derived as if from something Latin, link to the Latin entry rather than the English entry. - -sche (discuss) 02:59, 16 January 2016 (UTC)

I often encounter this problem when adding Esperanto etymologies—Zamenhof and other important Esperantists seem to have coined a lot of words based on whatever word French, Italian, Spanish, English, German, and Russian (or some combination of those) have in common. When it's a case of simply taking a root shared by most major Romance languages, I use the phrase "common Romance", as in rompi and dento, but I think this is an Esperanto-specific solution, and it doesn't work for all cases. In other cases, I list a few of the languages, as in adjektivo (something like what -sche suggests above). It would be good to have a standard way to deal with this across languages. —Mr. Granger (talk • contribs) 23:46, 15 January 2016 (UTC)

Lojban uses {{jbo-etym}} and faces a similar situation. —Aryamanarora ^{(मुझसे बात करो)} 03:09, 16 January 2016 (UTC)

long enough to qualify

I think it’s time that DerekWinters be made an admin. It was suggested almost a year ago by WF, but some were against it at the time because he had not been around long enough, or because WF had proposed it. DerekWinters has made 6600 edits on Wiktionary and has been active here since 14 October 2012 (over three years). —Stephen ^(Talk) 20:15, 12 January 2016 (UTC)

I'm sure he's trustworthy and experienced enough, but the real questions are: Does he want to be an admin? And what will he contribute as an admin? --WikiTiki89 20:24, 12 January 2016 (UTC)

If he never uses any admin powers, he would still be an outstanding representative of our slogan, based solely on his Babel. The practical value of having admins who can communicate in such a range of languages and scripts seems important to me. DCDuring TALK 22:35, 12 January 2016 (UTC)

I didn't ask what could he contribute, but what will he contribute. Only he himself can answer that. @DerekWinters: I'll ask you directly: Do you want to be an admin? And what would you contribute as an admin, if you were made one? --WikiTiki89 22:58, 12 January 2016 (UTC)

I wouldn't mind being an admin, especially because I'll be able to speedy delete some of the mistakes I make. But I honestly don't know what I'd be able to contribute should I become one. I definitely can speak a few languages rather well, and it is quite the hobby of mine to master other writings systems, but several of them are often unused in day to day matters. I however do believe I have been useful in making transliteration modules and some declension and headline templates and I have been increasing the lemma-count of several underrepresented languages, but I'm not entirely sure that being an admin would allow me to do this significantly better. DerekWinters (talk) 03:40, 13 January 2016 (UTC)

One thing we definitely need is better patrolling of non-European-language edits in Recent changes. There are lots of cases where I may check for defacing of entries or insertion of out-of-place text, but I have no clue whether the non-English content is correct or is deliberately-planted offensive nonsense. There are a few admins who know the languages, but they don't always have the time. Even if you patrolled only a fraction of the edits, it would be an improvement. Chuck Entz (talk) 04:05, 13 January 2016 (UTC)

I would be able to help with that. DerekWinters (talk) 04:14, 13 January 2016 (UTC)

Should this be formally voted on, I'd support. Mainly because of this cool list that he gave me. —Aryamanarora ^{(मुझसे बात करो)} 23:03, 12 January 2016 (UTC)

• Stephen is being somewhat dishonest about why DerekWinters was not made into an admin when WF suggested it. The reason can be seen at Wiktionary:Votes/sy-2015-06/User:DerekWinters for admin, where I opposed because DerekWinters created entries that did not meet CFI more than once over a long period of time, and when he was told about this or pinged in RFVs of his protologisms, he did not once respond to the best of my knowledge. He continues to create entries in languages he doesn't speak, and he has not demonstrated that he even recognises the problem. You can see that he often ignores messages left to him about problems with his editing at User talk:DerekWinters. It doesn't matter how long someone has been active on Wiktionary: I still cannot support a candidate for sysophood whose edits cannot be trusted, and who admits himself he has little or no use for the tools. —Μετάknowledge^{discuss/deeds} 03:49, 13 January 2016 (UTC)

I admit that I had added some terms that did not meet the CFI simply because they were words I found to be beautiful. However, since then I have been ascertaining that any term I add to the project most definitely meets the CFI requirements. I do apologize for not having responded then for the RFVs. However I also do believe from what I've seen that many editors add terms in languages they do not speak. DerekWinters (talk) 04:14, 13 January 2016 (UTC)

The Quality of the Macedonian Entries on Wiktionary

I would like to point out to anyone who may find it of interest that many (I use the term "many" hyperbolically) users which are not fluent speakers of Macedonian are freely contributing to the Macedonian corpus on the English Wiktionary with little to no concern for making errors. So, they're basically polluting the body of Macedonian entries, not with minimal oversights such as failing to mark a literary word as such (of such oversights I am at times guilty myself), but with grave inaccuracies such as allowing blatantly wrong suffixes to be generated in the inflection tables, be it willingly or inadvertently. This saddens me greatly because I've invested so much effort into creating Macedonian entries, only for some B1-level speaker to taint them all by adding a -о vocative form to a feminine noun which actually has an -е vocative form. Indeed, it's not as though the errors of other users don't affect me whatsoever - most people consulting online dictionaries view those dictionaries as integral units, so if they detect an error in the Macedonian Wiktionary for which some non-fluent speaker of Macedonian is liable, they will deem the entire body of Macedonian entries unreliable, such that the reputation of all of my own entries will be marred - they will be reduced to collateral damage.

My entries aside, the mistakes made by unskilled and/or reckless users trying to enhance the set of Macedonian entries are naturally to the detriment of anyone trying to learn Macedonian from this project, yet if no one notices them by hazard, there is no systematic way in which they can be detected and subsequently resolved. I personally try to hunt down faulty Macedonian entries and correct anything that needs correction, but I am not always able to do this. First of all, I don't devote attention to Wiktionary regularly; second of all, I don't get a notification every time a Macedonian entry is created or modified. All I can do (as far as I am aware) is check the contribution history of users whom I have already observed making Macedonian contributions. Either way, it's not as though I'm a moderator of the Macedonian part of Wiktionary - I haven't assumed any official obligations. I'm just trying to direct the attention of other concerned parties to the fact that in the absence of a moderator and a strict system of regulations, the set of Macedonian entries is left at the mercy of whomever feels the whimsical desire to tamper with it. This is not so with the corpora of many other languages, e.g. French or Japanese - there are so many active users that speak those languages here that mistakes can't simply weave themselves into the project with absolutely no one taking heed of that. On the whole, I feel that something should be done about this issue, although I don't have any concrete proposals - the fact that there aren't enough users fluent in Macedonian here makes everything so infeasible. Martin123xyz (talk) 18:23, 13 January 2016 (UTC)

To begin with we could publish regular reports documenting all changes to Macedonian entries, including the person making the contribution. This will only be of use if there are people capable of reviewing those reports, but it might help you find things to look at when you do have time. - TheDaveRoss 18:28, 13 January 2016 (UTC)

I find this suggestion agreeable - indeed, I wouldn't be able to review those reports regularly (so I don't think its necessary for you to produce them too often, e.g. weekly - every two months would be better), but even if I manage to devote attention to them a year or two after their creation, they will not have been in vain. I will correct whatever needs correction belatedly, and that is certainly better than nothing. Either way, I hope that it will be possible for me to filter my own contributions out of those reports, so that I can focus on the ones by other users (though there will obviously be no contributions from me during the breaks I take, e.g. the one I've just started). Martin123xyz (talk) 10:32, 14 January 2016 (UTC)

@Martin123xyz I can try and work on this this weekend, if you could provide me a list of editors who you would like to whitelist that would be great. Also, would you like to "trust" any entry which is most recently edited by a trusted editor, or only edits which were made by those contributors? - TheDaveRoss 20:42, 21 January 2016 (UTC)

@Martin123xyz can you point to some entries that had incorrect content added by a non-speaker? — Ungoliant ^(falai) 18:56, 13 January 2016 (UTC)

I will present, albeit with reserve (since I do not particularly wish to defame anyone or cause them any other form of inconvenience), three different entries (there are many more I have in mind, but three are enough to serve as illustrative examples) created or modified by three different non-speakers (I judge that they are non-speakers by the information on their profile pages) - народ (narod) (which was marked as feminine, whereas it is masculine; even if this was a coding error, it was nonetheless alarming), дојде (dojde) (which was given a more regular but either way invented past tense ("дојдол" instead of "дошол"), and ниво (nivo) (whose correct plural form, "нивоа", entered by myself, was changed to "нива", as though it were a regular neuter noun in -o, rather than a French loanword with a final stress). I have now taken care of all these entries, such that no errors are observable in them, but one can review their histories to see what their earlier condition was like. Either way, I must mention that I don't require whatsoever that all users contributing to Macedonian without speaking the language fluently be prohibited from doing so - their work can indeed prove useful at times. Indeed, there are many entries created by non-speakers of Macedonian which are of decent quality. Furthermore, a non-speaker once corrected a mistake I had made myself out of inattention, by allowing plural forms to be generated for чаре (čare), which is actually singularia tantum. It's just that non-speakers appear to be unable to contribute in a favourable manner consistently. Martin123xyz (talk) 10:16, 14 January 2016 (UTC)

@Martin123xyz I just want to say, thanks for your work! I've noticed many of your contributions appearing on various pages (in particular, those with a Russian term that's spelled the same), and I definitely appreciate the effort. I know it can be difficult or lonely working on a language without many Wiktionary contributors; I ran into this issue when I was working on Arabic entries. Benwing2 (talk) 18:52, 14 January 2016 (UTC)

Thank you very much, Martin123xyz, for making a great contribution for the Macedonian entries. --KoreanQuoter (talk) 05:54, 15 January 2016 (UTC)

Thank you for the compliments (they're not exactly relevant to the topic I'd introduced, but it's nice to receive them :) ) - I'm glad that people consider my entries useful. I greatly enjoyed creating them (my frustration with Wiki code aside). Martin123xyz (talk) 08:58, 15 January 2016 (UTC)

What do you mean by "Macedonian Corpus"? I think you mean "the entries in Macedonian", wherease "Corpus" normally means something quite different from dictionary entries (i.e. "a corpus of text(s)"). I strongly suggest renaming this as "The Quality of the Macedonian entries", not because your title is "wrong", but because it could lead to confusion... Imaginatorium (talk) 08:05, 17 January 2016 (UTC)

Thank you for the correction - I have made appropriate modifications (as I saw fit). Martin123xyz (talk) 19:37, 18 January 2016 (UTC)

A conference about French Wiktionary at Wikimania ?

Hello, English-speaking wiktionarians!

We are three French-speaking wiktionarian with a strong will of going to the annual conference Wikimania. We want to share our experiences with others about different topics. Well, to make it short, you can directly go to this direct link to our draft. We have until Sunday to send it, so only few days, but any help is welcome, especialy regarding the language. As you are probably guessing reading my prose now, English is not my mother tongue. Plus, we want to know what do you want to hear from us and imply the community as much as possible. You can react here or there, as you prefer. Thanks a lot in advance! Noé (talk) 21:34, 13 January 2016 (UTC)

I have edited the text a little to make it sound more "nativelike". I hope I preserved all of the meaning. Good luck with your project. Currently, the various Wiktionaries have different markup schemes and different policies, so the scope for collaboration seems a bit limited... Equinox ◑ 23:31, 13 January 2016 (UTC)

Thanks Equinox and Koavf for proofreading! I think we are going in the same direction without having a proper understanding of our paths. I plan to translate in English our 2015 report to gather your comments on it. I think we need to start talking about other Wiktionary policies to see if it may be a good idea to adopt it. I don't want to have a supervision but to publish thought about our own projects and to discuss about others' votes and decisions. It's a lot of energy and we need bilingual people to help, but I think it had to be one of our goal in the future. Noé (talk) 13:34, 14 January 2016 (UTC)

SI prefixes

About the SI prefixes:

Y	Z	E	P	T	G	M	k	h	da
y	z	a	f	p	n	μ	m	c	d

Shouldn't they be named like normal prefix entries, that is, with a hyphen in the end?

Y-	Z-	E-	P-	T-	G-	M-	k-	h-	da-
y-	z-	a-	f-	p-	n-	μ-	m-	c-	d-

Some of these entries already exist, defined as prefixes in various languages. I find it amusing that μ- is defined as "Abbreviation of micro-." in English. Plus, a- has a Translingual section, but it is not defined as a SI prefix. --Daniel Carrero (talk) 23:35, 14 January 2016 (UTC)

I don't see how they are grammatically prefixes. Sticking abbreviations together is not morphology. Equinox ◑ 23:49, 14 January 2016 (UTC)

Daniel, it’s an interesting point, but we categorize them as symbols, not as prefixes. — TAKASUGI Shinji (talk) 01:06, 15 January 2016 (UTC)

EL: Language vote

Of all the five votes that are going to end in the next few days, please direct your attention specifically to Wiktionary:Votes/pl-2015-12/Language.

Reason: It has few votes: 1-0-2. Please vote on it, abstention is fine too, IMO. End date: January 20. Thanks. --Daniel Carrero (talk) 10:25, 15 January 2016 (UTC)

Entries for suffix-like words

Per a suggestion at Requests for Deletion under the current discussion of -mongering, it might be a good idea to keep entries for words that are likely to be searched for as suffixes (with a leading hyphen) as redirects to the unhyphenated entries. Several editors participating in the discussion either assumed that -monger and -mongering were suffixes, or felt that they could be considered suffixes when attached (suffixed) to the end of other words. Since the words are rarely encountered except in compounds, one might expect a large percentage of people looking for definitions, etymologies, or other words formed with them to search for them with a leading hyphen. The same must be true of many other words that may not technically be considered suffixes, but which are frequently placed at the end of compound words. However, these searches usually turn up no results, frustrating the user, and in at least some cases probably leading to the creation of entries that are subsequently nominated for deletion.

Therefore, my suggestion is that we convert entries such as these into redirects to the entries that cover the intended meaning. -house would redirect to house; -wall to wall, -monger and -mongering to monger and mongering (or both to monger), etc. That would solve the problem of people looking for them as suffixes and not getting any results at all. It wouldn't involve a great deal of work; the redirects could be created as needed or converted as they appear; and if any legitimate suffixes happen to exist with the same spelling, then a sense could be added with wording such as, "house used in a compound word" (just using "house" as an example; I know it won't have a corresponding suffix entry). P Aculeius (talk) 15:34, 15 January 2016 (UTC)

I would support soft redirects, but not hard redirects. --WikiTiki89 15:37, 15 January 2016 (UTC)

I'll also add that these should only be words that people would tend to look up as suffixes. --WikiTiki89 16:25, 15 January 2016 (UTC)

I support the idea, but I think it should be limited to words that have a relatively high percentage of usage as a compound element. In other words, I’d include -monger and -mongering but not -house and -wall.

My preference is for hard redirects, but if soft redirects are used they should use the correct POS instead of suffix. — Ungoliant ^(falai) 16:18, 15 January 2016 (UTC)

I support hard redirects. Definitions in the target entry should have an appropriate label if use in combination is not rare, ie, (usually/often/also in combination). DCDuring TALK 16:36, 15 January 2016 (UTC)

[ä]

What should I use to write [ä] (Open central unrounded vowel) in IPA for entries? For Hindi, I see many entries with [ɑ] and rarely [a], even though Hindi should be using [ä]. —Aryamanarora ^{(मुझसे बात करो)} 21:48, 15 January 2016 (UTC)

Personally, I'm for writing ⟨ä⟩ when applicable. Korn [kʰʊ̃ːæ̯̃n] (talk) 22:32, 15 January 2016 (UTC)

Same here, just wanted to know the conventions here. [ä] isn't in the official IPA guide and is commonly replaced with the other open vowels in transcription. —Aryamanarora ^{(मुझसे बात करो)} 22:59, 15 January 2016 (UTC)

It's part of IPA nonetheless. I think in the last discussion I had about that here, a few people were of the opinion that one should use ⟨a⟩ instead, because our poor users might otherwise be scared and confused by something as uncommon as ⟨ä⟩. But for me /ä/ is simply a cardinal vowel like all others. I think another practice is to use /ɑ/ when [ä] phonemically behaves like a backvowel in twofold systems like vowel harmonies or consonant palatalisations Korn [kʰʊ̃ːæ̯̃n] (talk) 12:56, 17 January 2016 (UTC)

I consider [a] sufficient for cases where a language does not have both [a] and [ä] as distinguishable allophones, but I do not oppose the more exact practice of using [ä] either.

On the other hand, sometimes I've seen people using [ɐ] for this purpose, which I find a poor idea: the symbol indicates specifically a near-open vowel, not a fully open one (and is usually only used in the transcription of languages that have both /a/ and /ɐ/).

In phonemic transcription it's recommendable practice to keep it simple, and thus e.g. use /a/ even for [ɑ] if there are no other open vowels, or /u/ even for [ɯ] or [ʊ] if there are no other close back vowels. But that might not be much of an issue around here. --Tropylium (talk) 11:48, 19 January 2016 (UTC)

For dictionary-writing purposes it's almost never necessary to use [ä]. The IPA vowel diacritics are great when you're discussing the fine details of phonetic realization, such as in a discussion of allophones in various contexts or when comparing the vowel systems of two distinct languages or dialects. But in a dictionary, what's important is the phonemes and maybe their most common, widespread allophones, and for that the IPA recommends using the typographically simplest symbol in the neighborhood. Although the cardinal vowel ɑ is defined as maximally back and maximally low, that doesn't mean that only a maximally back and maximally low vowel is correctly transcribed with ɑ. If a language has only one unrounded back low vowel, then ɑ is the correct symbol for it, even if (to judge from the vowel chart at Hindustani phonology) that vowel is closer to being central than being maximally back. Using ä for a language's only vowel in the low back unrounded range, or worse yet, for a language's only low vowel, is an example of false precision that we should avoid. —Aɴɢʀ (talk) 13:04, 19 January 2016 (UTC)

Yep, that chart is accurate. Thanks for the information everyone! I'm going to use /ɑ/ for Hindi since it's the only low vowel. —Aryamanarora ^{(मुझसे बात करो)} 18:58, 19 January 2016 (UTC)

Module errors on the vote box

Discussion moved to Wiktionary:Grease pit/2016/January#Module errors on the vote box.

Gadgets

Is twinkle not available on this wiki? Ipadguy (talk) 23:48, 16 January 2016 (UTC)

Categories like Category:French verbs with conjugation er

@Kc kennylau I think these should be named with a hyphen, e.g. Category:French verbs with conjugation -er. Also, when you create them you should probably create a catboiler to generate the content. Benwing2 (talk) 00:53, 17 January 2016 (UTC)

@Benwing2: First part done; second part no idea what to add yet. --kc_kennylau (talk) 09:18, 17 January 2016 (UTC)

@Kc kennylau Check out {{fr-verbconjcat}}. Benwing2 (talk) 12:16, 17 January 2016 (UTC)

@Benwing2: Thank you. --kc_kennylau (talk) 13:38, 17 January 2016 (UTC)

We already have Category:French first group verbs. Renard Migrant (talk) 15:19, 17 January 2016 (UTC)

These aren't quite the same thing, though. There are categories like Category:French verbs with conjugation -cer that don't have an equivalent. Benwing2 (talk) 20:51, 17 January 2016 (UTC)

Module:ugly hacks

(Firstly, I apologize for violating the intention of this module by mentioning it here, since this would be equivalent to advertising for that module, which is not the writer User:Kephir's attention.) Shortly after Kephir decided to discourage the use of that module, he used that module himself on Template:en-verb ([1]). My question is, what is the current (inofficial) policy towards the use (or the discouragement thereof) of this module? Should I refactor Template:en-verb (as well as all the other templates that use this module) so that it no longer uses this module? --kc_kennylau (talk) 09:17, 17 January 2016 (UTC)

Next votes

I would like these to be the next WT:EL votes to start. Please review them and see if they are OK.

• Wiktionary:Votes/pl-2015-12/Definitions (starts Jan 20)
• Wiktionary:Votes/pl-2015-12/References (starts Jan 23)
• Wiktionary:Votes/pl-2015-12/EL introduction (starts Jan 24)

Plus I created a poll. It was scheduled to start in 1 month and last for 3 months.

• Wiktionary:Votes/2016-01/(poll) Historical revisions

But I'm probably going to oppose the current proposal of this poll, even if I'm the creator! It's just that the issue has been brought up repeatedly before and IMO it's better worded as a new proposal but I'd prefer the status quo. Please edit/change it too if you'd like.

Cheers! --Daniel Carrero (talk) 10:45, 17 January 2016 (UTC)

Complete entry template

I'm playing with the idea to make a template which triggers a row of subtemplates which create an entire entry from scratch for Middle Low German. So the final entry would look like any other to the user, but for editors it would be thus:
----
{{gml-entry|1|2|3|4|5|6|7|8}}
----
Atm it's just a random fleeting idea, but I figured before I even playfully muse about it, I'd ask whether there would be any problems with such a template/form of entry. Korn [kʰʊ̃ːæ̯̃n] (talk) 21:35, 17 January 2016 (UTC)

It would probably be confusing to newbies. I'd suggest to use {{subst:}} when using it, like the templates {{ja-new}}, {{zh-new}}, {{ne-new}}, and some others do. —Aryamanarora ^{(मुझसे बात करो)} 02:44, 18 January 2016 (UTC)

2016 WMF Strategy consultation

Hello, all.

The Wikimedia Foundation (WMF) has launched a consultation to help create and prioritize WMF strategy beginning July 2016 and for the 12 to 24 months thereafter. This consultation will be open, on Meta, from 18 January to 26 February, after which the Foundation will also use these ideas to help inform its Annual Plan. (More on our timeline can be found on that Meta page.)

Your input is welcome (and greatly desired) at the Meta discussion, 2016 Strategy/Community consultation.

Apologies for English, where this is posted on a non-English project. We thought it was more important to get the consultation translated as much as possible, and good headway has been made there in some languages. There is still much to do, however! We created m:2016 Strategy/Translations to try to help coordinate what needs translation and what progress is being made. :)

If you have questions, please reach out to me on my talk page or on the strategy consultation's talk page or by email to mdennis@wikimedia.org.

I hope you'll join us! Maggie Dennis via MediaWiki message delivery (talk) 19:06, 18 January 2016 (UTC)

Poll: Restore deleted high-use templates

Usually, when a high-use template is nominated for deletion ({{term}}, {{l/en}}), @Dan Polansky argues that they should be kept to preserve page histories. (Wiktionary:Beer parlour/2015/November#About deleting l/en, l/la, l/de and others, Wiktionary:Requests for deletion/Others#Template:l/de, Wiktionary:Votes/2015-11/term → m; context → label; usex → ux#usex → ux, etc.)

I would like to know what people generally think about this.

This is a poll with no policy value. The full proposal of this poll:

• There should be some effort to restore templates that were once highly-used in the main namespace and were orphaned and/or deleted, to keep them usable for past revisions of the main namespace to be readable. This arguably includes: {{proto}}, some context templates ({{obsolete}}, {{colloquial}}, {{UK}}, {{transitive}}) {{Wikisaurus-link}}, {{SAMPA}}, {{l/en}} and others.

--Daniel Carrero (talk) 18:11, 19 January 2016 (UTC)

Support

1. Support I support this both for enhanced usability of entry histories and to make Special:WantedTemplates and Special:WantedPages more useful by eliminating some of the detritus there, though there are other, greater contributors to the problem. DCDuring TALK 18:33, 19 January 2016 (UTC)
2. Support Make revision histories legible. As for making sure deprecated templates are no longer used: we could use the AbuseFilter or some such tool to enforce deprecation on the technical level: it would be impossible to save a page that uses a deprecated template. In the oppose section, I see no reasoning that explains why this or a similar technical solution is not a good idea; all I see there is very vague and non-specific. --Dan Polansky (talk) 21:09, 22 January 2016 (UTC)

   If you want to keep old revisions legible, why not just lock all templates right now and prevent changes for all eternity? The preservation of templates alone cannot preserve legibility, as parameters or internal code may be changed, as Benwing described below. —suzukaze (t・c) 07:25, 23 January 2016 (UTC)

   @suzukaze: Your question does not seem to be serious. I want to keep revisions legible at an acceptable cost. Using a deprecation mechanisms instead of deleting templates is not only acceptable but also reasonable. By contrast, locking all templates for eternity is not acceptable. In some cases described by Benwing below, keeping templates deleted may be in order. Alternatively, the body of a deprecated template could be updated to be less dependent on other templates. Either way, an argument of the form "we cannot make page histories perfectly legible => let's give up on the legibility altogether" is a crass fallacy. In its form, it is identical to "we cannot prevent all environmental pollution => let's give up on limitting environmental polution". --Dan Polansky (talk) 07:57, 23 January 2016 (UTC)

   Let me be specific: if we delete template:l/en, we will make all the links that used it illegible. If, by contrast, we enter a plain wikilink to the template, which does not depend on any other templates, we will preserve the legibility of all the uses of the template. To prevent further use of the template, we may create a filter using AbuseFilter. Now, what are the specific disadvantages of keeping the template and deprecating it using AbuseFilter? I see none. The Benwing objections do not apply to this template and the deprecation change to it just presented. --Dan Polansky (talk) 08:03, 23 January 2016 (UTC)

3. Support High-use templates, at a minimum, should be either redirected or left as historical. Not doing so confuses the bajeebers out of editors. Purplebackpack89 21:40, 22 January 2016 (UTC)

Oppose

1. Oppose I'm not sure that restoring these templates is worth the trouble, especially all the (hundreds of?) context templates. Some people might potentially use the old templates if they are available, and it would require the additional work of converting them to the new templates. Example: Even after {{l/en}} was orphaned, it was not deleted, and it was added to tapaculo and pupunha. --Daniel Carrero (talk) 18:11, 19 January 2016 (UTC)

   @Daniel Carrero Is there a way to allow the templates to be used everywhere but current principal namespace, Appendix space, etc, or only in histories? DCDuring TALK 00:56, 20 January 2016 (UTC)

   As far as I can tell, no, templates have no way to check if they are being used in the current or a previous revision. I also did not find any extensions on mw: to that effect. --Daniel Carrero (talk) 01:51, 20 January 2016 (UTC)

2. Oppose. It's something Dan Polansky talks about, having older revisions readable because you end up with things like (deprecated template usage) . The cost for keeping them is however too high in my opinion; they need to be usable in the main namespace for it to work, and then they get used. And how many people actually look at old revisions? I look at the odd one usually in RFV debates trying to find who added a disputed definition, but I can live with things like (deprecated template usage) and Template:idiom being red links because I know what they refer to and they're not what I'm looking for. And I can bypass those problems by clicking on edit. In short, the disadvantages far outweigh the advantages, not least because very few people read old revisions of pages, and experienced editors won't be bothered by old red links. Renard Migrant (talk) 18:27, 19 January 2016 (UTC)

   You and other veterans may know, but this constitutes yet another barrier to strong participation by newcomers. DCDuring TALK 00:56, 20 January 2016 (UTC)

   Maybe I'm just smarter than most editors, but it didn't take me very long to figure out what was up with those red links, once I'd got to the stage where I was looking at enough previous revisions to notice them. I've only been editing half a year, and I think that's the least of our worries. Ensuring that the help pages are up to date, as Daniel Carreiro has been doing, is a far more useful task, as that is where I got confused when I first started. Andrew Sheedy (talk) 04:47, 23 January 2016 (UTC)

   @Renard: "the disadvantages": That's a plural. You've stated only one disadvantage: when the templates are usable, they get inadvertently used. We have AbuseFilter that we could "abuse" to block saving pages that contain a deprecated template. --Dan Polansky (talk) 21:14, 22 January 2016 (UTC)

3. Oppose, for the reasons listed above. I've never been bothered by red links in previous revisions of pages. Andrew Sheedy (talk) 18:43, 19 January 2016 (UTC)
4. Oppose, per above. —Aryamanarora ^{(मुझसे बात करो)} 18:47, 19 January 2016 (UTC)
5. Oppose. I wouldn’t mind having a grace period for an RFD-failed template before it’s deleted, so contributors can get used to the new template (especially occasional or antisocial contributors who don’t follow discussions). But I think that keeping them forever would do more harm than good. — Ungoliant ^(falai) 00:46, 20 January 2016 (UTC)
6. Oppose Progress is progress. Does anyone still make computer towers that accept 5¼ floppy disks? —suzukaze (t・c) 00:57, 20 January 2016 (UTC)
7. Oppose per Daniel, who has very gracefully pointed out that idiots like me adding {{l/en}} long after deprecation when I'm multitasking on Wiktionary is something that is bound to occur. —Μετάknowledge^{discuss/deeds} 00:58, 20 January 2016 (UTC)
8. Oppose. Way too complicated to do something like this. But I wonder if anyone has proposed a mediawiki feature where page revisions use the revision of any templates at the time the edit was made? DTLHS (talk) 01:30, 20 January 2016 (UTC)
9. Oppose per Daniel. An additional issue is that technically it can be complicated and messy to require such compatibility. This is especially the case if an existing template is changed to eliminate a particular parameter or change the parameters, and all uses fixed accordingly. For example, in {{ru-noun-table}}, which declines Russian nouns, it used to have a 4th parameter that specified a special "bare-stem" form. I fixed up the Lua code so this wasn't required, and corrected all the template uses to eliminate their use of this parameter, and then deleted the code that supported this old parameter and eventually reused the 4th parameter for a different use. If maintaining compatibility were mandated, I couldn't do this, and instead would have to keep the old useless code around forever to support the old use of the 4th parameter, and would have to specify the new use as a 5th parameter with an always-empty 4th parameter before it. Benwing2 (talk) 05:58, 20 January 2016 (UTC)
10. What Ungoliant said.​—msh210℠ (talk) 18:06, 21 January 2016 (UTC)
11. Oppose because we want to think about the people who look things up in a dictionary more than those who make it (more and more these days, I'm using it as a look-up dictionary rather than a make-it-up dictionary...that is progress BTW). Those who make the dictionary know their way around. If they are able to click on [History] and can see a red link there, they're probably at a pretty good stage in the development of Wiktionarying already and will probably be able to find the new-and-improved versions of these templates. Ce mot-ci (talk) 03:52, 23 January 2016 (UTC)
12. Oppose to much work and complications (and basically bad resource allocation) for something that isn't very important. If anything it should be done like DTLHS describes. Enosh (talk) 07:09, 23 January 2016 (UTC)

    @User:Enoshd: Please clarify how is creating an abuse filter to ensure deprecation "too much work and complication". I have no idea what you are talking about. --Dan Polansky (talk) 08:10, 23 January 2016 (UTC)

    Similar to what Benwing says above, you have to continue updating them when other things change while keeping them backwards compatible. This mostly applies for templates transcluding other templates, otherwise not so much. Enosh (talk) 09:03, 23 January 2016 (UTC)

    @User:Enoshd: What prevents us from changing deprecated templates in such a way that they largely do not depend on other templates and yet render something legible? For {{l/en}}, we can replace the template body with a plain wikilink to preserve legibility and be done. --Dan Polansky (talk) 09:23, 23 January 2016 (UTC)

Oodles of numbers

Anon user 126.31.253.142 (talk) has been adding lots of entries for numbers, like 1338, 912, and 43. Is this appropriate for Wiktionary? ‑‑ Eiríkr Útlendi │^{Tala við mig} 18:12, 19 January 2016 (UTC)

No, these aren't words or idioms in any language. Nor are they symbols (nothing wrong with 0, 1, 2, etc.) Renard Migrant (talk) 18:22, 19 January 2016 (UTC)

• I've just nuked this anon's contribs in their entirety -- with the exception of XCII and XCIII, all of their contributions are of Arabic-numeral numbers as linked above, and even for those two Roman-numeral entries, this anon is the only user to touch them.

(If this was in error, please let me know and feel free to undo.)

What about all the other number entries not created by this specific anon, like 313 or 51 or 32? ‑‑ Eiríkr Útlendi │^{Tala við mig} 00:17, 20 January 2016 (UTC)

I would probably delete all of them above "9". Their categorization is an inconsistent muddle and makes little sense to me. An alternative would be to agree on a consistent format and create them all (up to 2016?) by a bot. SemperBlotto (talk) 08:57, 20 January 2016 (UTC)

I don't mind for one that have other meanings like 69 but everything else should go. If you look at the original revision of 313 it should have been shot on sight, and 32 is just Wonderfool pissing around. Renard Migrant (talk) 18:21, 21 January 2016 (UTC)

• For entries like 33 that have a valid idiomatic sense, should we rip out the otherwise-useless and not-dictionary-material ==Translingual== sections? ‑‑ Eiríkr Útlendi │^{Tala við mig} 19:58, 21 January 2016 (UTC)

And what about confusingly formatted entries like the ==Translingual== section at xxx? My instinct is to rip that out too. ‑‑ Eiríkr Útlendi │^{Tala við mig} 20:00, 21 January 2016 (UTC)

I suppose I'd keep them a bit like we keep unidiomatic sense for idioms when the idioms meet CFI (see {{&lit}}). Renard Migrant (talk) 19:27, 22 January 2016 (UTC)

Proposal for Sorting Definitions

As anyone who regularly frequents Wiktonary knows, one of its most widespread problems is that of inconsistency in the ordering of definitions (and etymologies, pronunciations, parts of speech, etc.). I propose implementing something that could somewhat improve the situation and at the same time, satisfy people with conflicting opinions.

This would be a simple template that allowed the ranking of definitions in two different ways. It would look something like {{2|3}}, with the first parameter ranking it according to how common it is, and the second parameter ranking it according to when it entered the language. It would have no effect on the appearance of the page unless a user selected a setting to have definitions ranked either by age or by frequency. With this option available, I would suggest making it policy to order definitions according to their relationship with each other. (By default, entries would be displayed in the order displayed in the wikicode.)

Obviously, some definitions would be almost equally frequent (or infrequent), or might have roughly the same, not necessarily known, time of origin. The template would thus have to allow for multiple definitions to have the same ranking. The other parameter could be used as a secondary ranker, and perhaps the unmodified order of definitions could be used as a tertiary ranker (i.e. equally frequent definitions would be ranked by their age, and if some of them had an equal age, then they would be ranked according to how they were entered in wikicode).

The same thing could perhaps be applied to etymologies, pronunciations, etc. which also suffer from the same issues. I think it would be less important for these than for definitions, however.

This would introduce some problems, especially ones that label definitions as "by extension" from preceding definitions. I don't see this as a huge issue, as the templates would be entered manually, so editors would hopefully ensure that there were no such problems, and other editors would hopefully catch them over time, as they do any other mistakes and inconsistencies. I also don't think that label is particularly useful anyway.

This would be an ambitious change to make, and its implementation would no doubt be tedious, but I feel that it would pay off in a few years, if it is even possible to do. What think you all? Is this possible (and would anyone besides myself care enough to help implement it)? Hopefully the wall of text didn't scare anyone away. Andrew Sheedy (talk) 05:00, 20 January 2016 (UTC)

I like the idea. I wonder if the template thing is needed at all; maybe we can get consensus for commonness-based order rather than etymological order. — Ungoliant ^(falai) 13:51, 20 January 2016 (UTC)

Consensus has been sought many times, and there are people who are very dedicated to one approach or the other. As for implementation, this would require code, presumably in javascript, to rearrange the page. Page loads take far too long as it is, and this could make pages with lots of definitions really, really slow. I know that it would only be a problem for those that opt in to rearranging, but I'm skeptical that there would be enough use to justify the monumental investment of time and resources to make it happen. It could easily end up as a failed experiment like the alphagrams. Chuck Entz (talk) 14:33, 20 January 2016 (UTC)

How would this be made to work with subsenses (and subsubsenses)? DCDuring TALK 15:09, 20 January 2016 (UTC)

Good question. Maybe a modified template could be used? I'm afraid I'm not very skilled in the programming department, so I'm not too sure how one would make it work in those cases. Andrew Sheedy (talk) 18:39, 20 January 2016 (UTC)

As far as subsenses, this is not a technical issue but a logical one. If you can figure out how we want them to be sorted, dealing with them on the technical side shouldn't be too hard. As far as pageload times, most of the time is spent loading the JavaScript, not running it. It runs pretty fast. --WikiTiki89 19:21, 20 January 2016 (UTC)

In that case, I would think subsenses would be sorted in the same way as other definitions. If a user wanted to see definitions in order of age, the subsenses would still be displayed as such, and would be ordered related to other subsenses under the same main sense. They wouldn't be ordered in relation to other senses, at any rate. Andrew Sheedy (talk) 18:11, 21 January 2016 (UTC)

I must have faster Internet than you, Chuck Entz, because I find that even the longest pages load fairly quickly on Wiktionary. In fact, one of the main reasons I prefer Wiktionary to any other online dictionary is the speed at which pages load (Larousse and Dictionary.com have way too many ads), so if rearranging the definitions would significantly slow down page loads, then maybe it wouldn't be such a good idea, particularly since my proposal is aimed especially at definition-heavy pages. Andrew Sheedy (talk) 18:39, 20 January 2016 (UTC)

I think this is a terrific idea, and restating what I think Dixtosa was saying below: we ought to hold off on this and actually take the plunge re structuring data in such a way that we could migrate it into a relational database. The current suggestions involving templates and reordering pages via js and lua may well work, but only insofar as data is presented locally. The real conversation is about WikiData or some other model for backend structure. - TheDaveRoss 19:25, 20 January 2016 (UTC)

As far as I know, there's never been any consensus over what order to have definitions in. Most entries put common definitions first but a few put things in date of first appearance order, meaning that very rare meanings can come before very common ones, which I oppose. Renard Migrant (talk) 16:48, 21 January 2016 (UTC)

I think that the vast majority of entries actually have the definition lines in a more-or-less random order. The upshot of the suggestion here, and those like it, is that you as a reader could choose how you like your definitions provided and then all entries which had been tagged could be displayed to you in that manner. - TheDaveRoss 16:52, 21 January 2016 (UTC)

What I am proposing would allow users to view definitions sorted in three different ways (the default, according to age, and according to commonness), according to preference. Andrew Sheedy (talk) 18:11, 21 January 2016 (UTC)

Tagging this idea as part of {{hashtag|MediawikiHoldsWiktionaryBack}}. --Dixtosa (talk) 19:11, 20 January 2016 (UTC)

Detagged. This places the whole Beer parlour discussion page into a pointless category. Furthermore, if you don't like Mediawiki and the semi-formal approach, you can goto OmegaWiki and contribute there; good luck with that.--Dan Polansky (talk) 13:21, 23 January 2016 (UTC)

We have fewer than 2,600 pages that use {{defdate}}, not all of which have any English content, some of which use defdate not for definitions but for alternative forms etc. A large number of the pages with {{defdate}} have only one definition. Almost all of the PoS sections that have {{defdate}} do not have it for every definition.

I don't think we have any other usable data for time ordering. The basic source for such date is the OED. I don't know whether large-scale use is a copyright problem.

We have no source whatsoever to determine which definition represents the most frequent semantic content of current usage of the word. That is, we would have to do our own interpretation of corpus data to actually offer something that could claim to be reliable.

AFAICT, we have never mastered the relatively simple problem of technically determining whether a given spelling of a word had as lemma one or both of the capitalized or uncapitalized forms. Nor have we mastered folding all inflected forms into the count for the lemma form or separated participles from homonymic adjectives. And, of course we have never mustered the effort to do these things manually, except in principal namespace where it took much of the lifetime of the project to reach our current state of incompletion.

If we cannot get reliable information on frequency of usage of word-definitions, how could we execute the project proposed? What would motivate the manual effort required? How could the problem be solved technically, even over the course of the next decade? DCDuring TALK 19:23, 21 January 2016 (UTC)

Fair points. It's a pity we don't have the manpower to do the job. I think it could be done if people were motivated, but adding new definitions and words is probably higher priority. It would be nice if we could achieve consenus on the definition order, though, even if it required a compromise. We have some entries that are overwhelmingly confusing, and I think some consistency could help solve that.

I might just use {{defdate}} for French entries now that I know about it. It's not essential information, but the more it's used, the easier it'll be to rearrange definitions later. Andrew Sheedy (talk) 23:21, 22 January 2016 (UTC)

It is worthwhile to include the {{defdate}} information where available. I wish that it weren't so hard to get it. Especially difficult, even conceptually, are the more gradual and subtle transitions from creative innovation, through usage limited to special context, to full membership in the lexicon. It seems a bit like speciation in organisms, not the most encouraging of possible analogs. DCDuring TALK 00:21, 23 January 2016 (UTC)

Data about the relative frequency of different definitions of a word is even harder. The conceptual problems are severe: the relative frequency depends on the set of definitions a given dictionary uses and the wording of the definitions. More practical would be recording the frequency of collocations of a word, though that too has problems. At least it would make it more possible to better separate the frequency by PoS. DCDuring TALK 00:34, 23 January 2016 (UTC)

I think any ranking by frequency would have to be largely subjective, and based on personal experience. For more technical terms, this would be far more difficult to determine. Andrew Sheedy (talk) 03:20, 23 January 2016 (UTC)

Try comparing subjective experience with corpus evidence for a few polysemic words. Then assume that crowd-sourcing subjective experience improves things. Do you think the result is satisfactory? DCDuring TALK 13:13, 23 January 2016 (UTC)

{{inh}} vs. {{der}} again

The criteria for when to use one vs. the other aren't always clear. For example, I just fixed up Latin pluit to say it was "inherited" from PIE *plew-. This is true, except that pluit is thematic and the verb corresponding to *plew- might have been athematic *plewti instead of thematic *pleweti; if so, then technically it was "morphologically reformed" at a later point so it should maybe say it was "derived". But this seems a needless distinction to make in cases like this, and in many cases it isn't even known for sure if a particular verb was thematic or athematic in PIE since the athematic->thematic change was so common and repeated so often in so many languages. Or is the statement that it's inherited from a root rather than a particular verbal form enough to work around this issue? Benwing2 (talk) 05:45, 20 January 2016 (UTC)

*plew- is a root, and roots have no descendants, only derived terms. So it can't be inherited from it. —CodeCat 15:29, 20 January 2016 (UTC)

It is, however, inherited from the root present *pléw-, which is derived from *plew-. —JohnC5 15:38, 20 January 2016 (UTC)

We had separate entries for verb stems for a while, but I removed them again because they caused some problems and a few people had requested this long ago. One issue is that etymologies (ours or others') generally don't distinguish between the root and its stems, so knowing what goes where is hard. Another difficulty is that the PIE verb system was structured fundamentally differently from what the descendants have. PIE had different aspect stems, and these could be considered separate verbs in their own right. In the descendants, however, these were generally unified into one paradigm, and missing members were created anew while duplicates were trimmed. For example, every Germanic strong verb has a form that is descended from the PIE stative, but that doesn't mean that a stative form of that verb existed in PIE. Not all PIE verbs might have had an imperfective aspect stem either, but pretty much all descendants formed one at some point. Then there is the question of the athematic-thematic distinction, which was pretty much completely eliminated in many of the descendants (Slavic, Italic, Germanic). All in all, it's very difficult to say "PIE verb X has descendant verb Y as a descendant" when Y can actually be an amalgamation of several PIE verbs, including any that were only formed post-PIE. —CodeCat 16:02, 20 January 2016 (UTC)

I vaguely remember a discussion from which it followed that upholding this distinction was not even supported by consensus. But I am not sure. From what I can see, the distinction between {{inh}} and {{der}} was installed without discussion and consensus. I fear it is going to create a lot of pain down the road. --Dan Polansky (talk) 13:17, 23 January 2016 (UTC)

Fixing cite- and quote- templates

Recently, @Smuconlaw has changed the behavior of {{cite-book}} and {{cite-web}} (which previously behaved like/redirected to {{quote-book}} and {{quote-web}}) to actually be proper citation templates. While this is a good change, it gives us a big problem - the cite- templates were widely used to include quotations in entries, and suddenly the formatting here has become completely messed up (look at Citations:rest on one's laurels, Citations:macaroni and gravy or Citations:twelve-ounce curls). Would it be possible for someone with a bot or AWB to go through entries and convert "{{cite" to "{{quote" in the following specific circumstances:

1. Any usage in the Citations: space.
2. Any usage in the mainspace immediately preceded by "#*" (or "#* " - in fact, any usage of a cite-template preceded by an asterisk is probably an error)
3. Any usage under a ====Quotations==== header

That should fix the formatting issues messing up the references (although if anyone can see a potential for false positives, please point it out). Smurrayinchester (talk) 08:53, 20 January 2016 (UTC)

(And vice versa, any quote- templates that appear within <ref></ref> tags should be cite-, presumably) Smurrayinchester (talk) 08:53, 20 January 2016 (UTC)

I've spotted two problems with this idea. a) Some people call "cite-book" through the {{cite}} template. This wouldn't necessarily be unfixable, but we'd need to create an equivalent {{quote}} (currently a redirect to {{blockquote}}). b) There are a few citations pages where citation templates are used without a date= or year= field (eg Citations:Brown bounce), which causes problems if you try to convert citation quotes directly into quotation ones. Smurrayinchester (talk) 09:25, 20 January 2016 (UTC)

Yes, I realized there were going to be some transitional issues but figured the short-term pain was worth the long-term gain. If these could be fixed by bot that would be great. By the way, {{cite}} works (I updated it) but links to the citation, not the quotation, templates. Smuconlaw (talk) 10:15, 20 January 2016 (UTC)

How to mark long vowels in Germanic variants

I think this would apply to Middle Low German/Dutch/Frisian, and some forms of German. I'm making Middle Low German templates and Low German research traditionally has two different systems of marking long vowels. I'd like to have consistency amongst the languages, so I thought I'd informally ask which one to use.

• System one: Lengthened short vowels are marked by a macron: hö̂gede (heighth) vs. hȫgede (joy)
• System two: Lengthened short vowels are unmarked: hö̂gede (heighth) vs. högede (joy)
  

Lengthened vowels can only ever occur in open syllables, so system 1 is superfluous but explicit. Asking @CodeCat as DUM person especially. Korn [kʰʊ̃ːæ̯̃n] (talk) 13:50, 20 January 2016 (UTC)

Vowel length is not marked for Middle Dutch, as it can be (generally) deduced from the spelling. However, we do use macrons and circumflexes to distinguish between different long vowels that were spelled identically. See WT:ADUM for more. —CodeCat 15:31, 20 January 2016 (UTC)

Translations vote

Please vote on Wiktionary:Votes/pl-2015-12/Translations.

Reason: Only 5 people voted so far, and it's going to end in a few days.

• Current results: 3-2-0
• End date: January 27

The 2 opposers raised a good point concerning translation tables in Translingual sections, so I proposed to amend the vote based on that point. I believe this vote could pass, with that proposed modification. Just see the support vote by @Andrew Sheedy. Thanks. --Daniel Carrero (talk) 18:11, 22 January 2016 (UTC)

Wikidata & GLAM 'down under'

In February, I'm undertaking a three-week tour of Australia, giving talks about Wikidata, and Wikimedia's GLAM collaborations. Do join us if you can, and please invite your Wikimedia, OpenData, GLAM or OpenStreetMap contacts in Australia to come along. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:42, 22 January 2016 (UTC)

Deprecating term template

A vote to let bots replace all uses of {{term}} with {{m}} has passed.

I propose to deprecate {{term}} by adding an abuse filter to AbuseFilter extension that prevents saving of pages that contain the template. Thus, we can standardize on {{m}} while keeping the huge volume of page revisions that use {{term}} legible.

--Dan Polansky (talk) 08:24, 23 January 2016 (UTC)

I'm not opposed to this, but concerned this may establish a precedent preventing deletion of obsolete templates in the future. Let's emphasize that doing this doesn't establish such a precedent. Benwing2 (talk) 12:08, 23 January 2016 (UTC)

Definitions vote -- Rationale and changes

Vote:

• Wiktionary:Votes/pl-2015-12/Definitions

Rationale and changes:

• Removing "The definitions are the most fundamental piece of dictionary", it's a comment rather than a rule.
• Removing "[definitions] do not have their own header", no need to say what they don't have. Arguably, the POS header is their header.
• Expanding upon the idea that "Each definition may be treated as a sentence: beginning with a capital letter and ending with a full stop.", mentioning other type of definitions: "In language sections other than English, the definition generally consists of a simple translation into English, rather than a full definition."
• Mentioning: "Sometimes, they are grouped into subsenses."
• Writing out the actual formatting rules of Wiktionary:Votes/2006-12/form-of style and Wiktionary:Votes/2010-08/Italicizing use-with-mention, rather than just linking to them.
• Removing "The “definitions” of entries that are abbreviations should be the expanded forms of the abbreviations." Sometimes, the expanded abbreviation is in the etymology section, not in the definition.
• Removing "Where there is more than one expansion of the abbreviation, ideally these should be listed alphabetically to prevent the expanded forms being duplicated.", does not seem common practice.
• Compressing the explanation of where to link the expanded forms in a single paragraph; arguably, that information does not need its own subsection.
• In particular, replacing "Expanded forms that are encyclopedic entries should also be wikified and linked to the appropriate Wikipedia entry." by "Otherwise, if appropriate, link it to the appropriate Wikipedia article, if it exists." Arguably, existence in Wikipedia is a more objective criterion than whether an entry is "encyclopedic".
• Mentioning three abbreviation examples (PC, USA, SNAFU), together in the same line. The original text had two examples (PC and SNAFU) in separate lines.
• Removing bold formatting from "a definition which only applies in a restricted context"; arguably, it's unnecessary.
• Compressing the explanation of context labels in a single paragraph; arguably, that information does not need its own subsection. In particular, "Details in Wiktionary:Context labels." does not to be in a separate line.
• Adding an example of non-lemma definition, properly formatted: "plural of word".
• Removing three separate references to the same vote (Wiktionary:Votes/pl-2009-03/Context labels in ELE v2) in consecutive paragraphs.
• Reordering some of the ideas. Original order: introduction, form-of definitions, abbreviations, context labels. Proposed order: introduction, form-of definitions, context labels and abbreviations.
• Using {{lb}} rather than {{context}}, as approved at Wiktionary:Votes/2015-11/term → m; context → label; usex → ux.
• Replacing "wikify" by "link"; "wikified" by "linked".
• Mentioning the fact that some entries are romanizations linking back to the main entries. The requirement that each romanization entry have at least one definition line was voted at Wiktionary:Votes/pl-2013-03/Romanization and definition line.
• Making sure another WT:EL section is voted, a step in the direction of having WT:EL completely voted.

--Daniel Carrero (talk) 11:00, 23 January 2016 (UTC)

References vote -- Rationale and changes

Vote:

• Wiktionary:Votes/pl-2015-12/References

Rationale and changes:

• Adding the rule: "References are listed using bullet points".
• Adding 1 more usage example + the result of the usage examples.
• Formatting the usage examples with bullet points, showing actual usage.
• Removing "There is a need to balance respect for copyrights with definitions so inventive as to be inaccurate." For semantics, we go by attestation.
• Removing "The validity of the dictionary has a profound effect on its usefulness." It's a comment rather than a rule.
• Minor change of punctuation and word order.
• Making sure another WT:EL section is voted, a step in the direction of having the WT:EL completely voted.
• Disclaimer: The References section probably could be expanded with more information. This is proposed as an improvement to the current text, not as the "final" version of it.

--Daniel Carrero (talk) 11:06, 23 January 2016 (UTC)

EL introduction vote -- Rationale and changes

Vote:

• Wiktionary:Votes/pl-2015-12/EL introduction

Proposed introduction:
"This is a list of aspects that govern how an entry should be formatted. This includes what are allowed sections and what are the contents expected to be found in them. These rules reflect what editors think as best concerning the standard format of an entry."

Rationale and changes:

• Quickly states that WT:EL is and what it does, for those unacquainted with the policy.
• The first sentence was based on WT:NORM's "This is a list of aspects that govern how the wiki code behind an entry should be formatted."
• The second sentence is a generic, all-encompassing statement but it also suggests that we have some standards concerning specific allowable headers and contents.
• The third sentence was based on WT:NORM's "[...] they do make the pages conform more to a standard format reflecting what we think of as best for the wiki code."

--Daniel Carrero (talk) 11:21, 23 January 2016 (UTC)