I'm of the opinion that blocking should really be a last resort. I see too many editors too willing to block other users. We need all the editors we can get, and blocking users is really counterproductive in this respect.
One example: User:Stubborn Pen, who was blocked Jan 2016 by User:Metaknowledge for having an "unacceptable username" (???). This user had put in 5,000+ edits, most of which look fine to me, and had clearly became a regular contributor. I don't for the life of me see what's wrong with this user name, and even if something were wrong, this is hardly grounds for blocking -- instead, suggest to the user that they rename their user account (which doesn't seem to have been done, AFAICT). Benwing2 (talk) 02:56, 2 May 2017 (UTC)[reply]
Hmm, OK, I see from another message that this was an alias of Wonderfool, so maybe a block was reasonable, but people seem to tolerate Wonderfool, so who knows. Benwing2 (talk) 02:58, 2 May 2017 (UTC)[reply]
Firstly, we don't need "all the editors we can get". We need editors who contribute well. If an editor's edits are half constructive and half requiring cleaning or attention from others and they refuse to improve their quality after thorough explanations of the problems and warnings, then a block is the right thing to do for the project. Secondly, I understand the source of your confusion, but I don't appreciate this subject being brought up with a block that you did not even look into, but you used anyway to paint me as abusive. —Μετάknowledgediscuss/deeds03:24, 2 May 2017 (UTC)[reply]
Sorry, I missed his request to be blocked. Metaknowledge, I'm not trying to paint you or anyone as abusive, I'm just questioning whether we need to block as quickly as we do. In the short term, it might be pragmatically the right thing for the project, but in the long term, it might not be, because it fosters the impression that Wiktionary is intolerant of new editors. (Wiktionary's syntax is definitely not so easy to learn, and not so well documented, so it's already not very easy for new editors to get involved.) As for other examples, User:Wikitiki89 blocked User:D1gggg for edit warring, and I then unblocked him because the edit war in question wasn't really an edit war, just a revert. Now, granted, User:D1gggg is very annoying and makes edits that need cleaning up after, but IMO it's not clear that blocking is the right solution. In any case, D1gggg seems to have gone away on his own for the moment, which is probably a better outcome for such users. Similarly, it's not clear to me that User:Awesomemeeos should have been blocked for a year, although he was similarly annoying. Benwing2 (talk) 03:35, 2 May 2017 (UTC)[reply]
I didn't block Awesomemeeos for being annoying. I blocked him for two weeks for repeatedly adding incorrect information in languages he doesn't know after being warned, and upped it to a year for block evasion. Are you trying to say that when somebody gets around a block by editing as an IP or creating a new account, we should let them off lightly and encourage them to keep doing this? —Μετάknowledgediscuss/deeds03:41, 2 May 2017 (UTC)[reply]
No, but a year seems excessive to me. A year might as well be indefinite; I doubt you'll see Awesomemeeos back after a year. I would do something like double the block every time you need to block him anew, rather than jumping directly from 2 weeks to a year. Benwing2 (talk) 05:07, 2 May 2017 (UTC)[reply]
It's common to give an indefinite block for abusing multiple accounts, actually. Remember that the length of a block is about the offences a user has committed, not about the length of the last block they happened to get. —Μετάknowledgediscuss/deeds06:12, 2 May 2017 (UTC)[reply]
@Benwing2, I agree with you. For dealing with editors who are not admins, I have always preferred to protect a page for a few days rather than blocking the persistent editor. However, an odd thing usually happens when I protect the page instead of blocking the editor ... the editor becomes enraged that the page was locked. OTOH, if I leave the page unprotected, but block the editor for a week, then when he comes back he does not seem upset by it. It's the weirdest thing ... if I act unreasonably and block him, he doesn't mind. But if I act with restraint and treat him with respect, protecting the page instead of blocking him, he goes insane. In spite of this, I still prefer to protect a page if possible and not block a good editor.
The problem is, most people have certain talents, certain areas or subjects they're good at, and they're not so good at other things. Some are great at programming and writing applications and templates. Others are great at formatting a page or categorizing. Some are good at writing or translating or researching or citing. Some people are good at surgery, cooking, undertaking, or mechanics. On Wiktionary, there are a lot of different areas that require expertise and experience, and few if any editors are good at everything. One of the areas that most people suck at is policing the people: the regular editors, the occasional editors, the visitors, the jokers, the vandals. Some of us get upset with Awesomemeeos for adding information in languages that he does not know, yet we think nothing of it when an editor who is a great writer but who hasn't a clue when it comes down to policing the wetware, the human beings who work here or come to visit. Ideally, dealing with the people here should be left up to certain admins who have that talent. —Stephen(Talk)09:14, 2 May 2017 (UTC)[reply]
Well, I think it would be nice if people could recognize areas where they lack experience, knowledge, and talent. Everyone (except Awesomemeeos) seems to be able to recognize Awesomemeeos's weakness in languages that he does not know, yet it does not occur to anyone that they themselves may not have experience and wisdom when it comes to guiding human behavior, and what tools should be used when, and how to make reasoned and constructive decisions on severity and length of punishments. What we do on Wiktionary is like Donald Trump naming himself to the Supreme Court. We each know our strengths and talents, but, like Awesomemeeos, we don't know our weaknesses. I have no answers. —Stephen(Talk)11:18, 2 May 2017 (UTC)[reply]
Thanks for saying that Stephen; I think we could do a lot of work on establishing what it means to be an administrator here, and, as importantly, what it does not mean. The roles and responsibilities of various account flags are poorly defined. That is not the whole of the problem, but I think it might be a part of it. - TheDaveRoss14:58, 2 May 2017 (UTC)[reply]
As I recently said on my own talk page: "Maybe we need a lot of trusted people with reverting/patrolling rights, template editing rights, page deleting rights, but I don't think we need so many people with blocking and page protecting rights." --WikiTiki8915:14, 2 May 2017 (UTC)[reply]
In order to try to improve our retention of non-vandal newcomers, a few years ago I started using a new patrolling strategy based on three pillars:
no undoing or non-minor changing of the newcomer’s edits will go unexplained, even if it is obvious why it is being undone/changed;
if the newcomer adds new content, I will try to incorporate it into the entry. If an edit adds an unformatted entry or a definition in the middle of nowhere, I will try to fix the formatting rather than undoing;
express my gratitude to newcomers who make contributions that show a relatively big effort whenever possible. This means using the thanks feature for registered newcomers, and using “thanks, but […]” when undoing. Unfortunately there is no similarly simple way to thank IPs unless their contribution requires a follow-up edit.
Another thing I now avoid is giving someone the {{welcome}} template. I feel that that impersonal wall of text is more likely to scare than help. I think it’s better to send someone a message explaining what they are specifically doing wrong.
It’s not always possible to follow this strategy, but it is a long-time investment: I spend more time dealing with each individual edit than I would if I just freely smashed that good old revert button (leading to fewer edits being patrolled by me), but hopefully even a slight increase in retained editors will, after some years, increase the pool of users who are able to help with patrolling and building the dictionary. — Ungoliant(falai)13:28, 2 May 2017 (UTC)[reply]
I agree with you on this, especially {{welcome}}. The current template is just too long and one-size-fits-all, better to leave a short personal note directly addressing issues and options w.r.t. the areas/languages they've been contributing in. A link to a page with info similar to that in the current template could still easily be included in a post like that. — Kleio (t · c) 19:30, 2 May 2017 (UTC)[reply]
I agree as well. I've generally been following those three pillars, although I should try harder on the first one. If anyone notices me breaking those pillars, feel free to remind me, because I may not have realized it. --WikiTiki8919:37, 2 May 2017 (UTC)[reply]
@Ungoliant MMDCCLXIV And thank you for that. I made some pretty stupid edits when I started off here, and your patient handling of the situation made me feel a lot more welcome than if you had just reverted my edits with no explanation (and made me actually feel badly about it, rather than angry, so I was motivated to watch myself a bit more). The same goes for Μetaknowledge and Wikitiki89. You all did a good job not scaring me away. ;) Andrew Sheedy (talk) 21:07, 2 May 2017 (UTC)[reply]
As used in Pa and when using tabbed languages this box becomes intrusive - occupying up to 2/5 of my page width - leaving 2/5 for the rest of the entry (and 1/5 for the tabs). Two points:
Do we need these boxes?
If we must have them, they shouldn't be above the top language heading.
If you don't like the boxes, one possible solution would be using CSS to hide them just for you. We don't seem to have a CSS class for the whole character box right now, but it can be easily added.
I like them above the top language heading because the box is not something tied to a single language, but I'm OK with discussing it. It could be in the Translingual section.
Maybe you already know about what I'm going to say, but since asked anyway, the boxes are important because they provide images for people who don't have the fonts (Pa doesn't have an image because nobody added it yet), and also hexadecimal/decimal codes for typing/displaying them easily (the hexa links to Unicode.org, with lots of technical information about the character), and it automatic places the entry in the respective "block" category, and links them to the block appendix. It's a good navigation tool. I consider the previous/next links a nice touch, too. As a future project, I'd like the boxes to automatically include codepoints for encodings other than Unicode.
Maybe some characters are more important or more commonly used than others, but I think all characters with entries need boxes, yes, not just some characters which are more important. Case in point: if we didn't have the character box in the entry Pa, I think I would insist on adding an "Usage notes" section in the entry, explaining that the single-character "㎩" exists. --Daniel Carrero (talk) 05:31, 2 May 2017 (UTC)[reply]
Thanks for replying. Brief - not argumentative - replies :)
(1) "one possible solution would be using CSS …" - I've avoided using CSS and would like to continue. The problem with much tweaking of our appearance is that editors don't see what the casual punter sees. (OK I know I'm using the tabbed/gadget).
(2) "It could be in the 'Translingual' section." I think that this might be a good idea. As you suggest, it could be repeated in the 'English' section under 'Usage notes' or similar. I'm afraid that I already moved some (before raising the subject) to a position below the Transligual heading.
(3) "the boxes are important because they provide images for people who don't have the fonts". But surely only specialists would require these characters. I was a chemist and studied physics - Pa would be typed from the keyboard! But it is good to know these characters exist (I didn't). — Saltmarsh. 15:51, 2 May 2017 (UTC)[reply]
You're welcome. :)
Maybe we should have a poll/discussion/vote with the proposals: 1) always keep the character box above all language sections vs. 2) always keep the characters box in the first language section.
For context, it seems almost all entries have the box above all language sections because at least three people consistently added it this way in many entries: @Visviva (the creator of the original character box with lots of manual parameters), @Kephir (the creator of the Lua module that gets some of the info automatically) and myself (I believe I could add the box in all existing single-character entries that didn't have it yet, including thousands of Chinese characters).
Yes, "Pa" (comprised of two separate letters) would be typed from the keyboard! But that box is specifically about the single-character "㎩". The box is on the normal Wiktionary entry "Pa" (two characters) because it seems we don't need separate entries for different codepoints that present exactly the same characters. (㎩ redirects to Pa) Admittedly, I don't think anybody on Earth is greatly interested in typing "㎩" (single character). But maybe someone who doesn't have the right fonts to see it copies the symbol here to find the information. --Daniel Carrero (talk) 17:13, 2 May 2017 (UTC)[reply]
Do you mean that we shouldn't have character codepoint names, abbreviations and corrected names, Unicode hexadecimal codepoints starting with U+ (like: U+00C7), character entities formatted with &# ; (like: Ç), LaTeX inputs, lists of languages where a character is used, Unicode appendices and links from entries to appendices, character images, lists of different codepoints for basically the same character (!, ❕, ❗, ❢, etc.), lists of alternate codepoints, Unicode block categories, character compositions (Ç = C + ¸; 기 = ㄱ + ㅣ), Dubeolsik inputs, hieroglyph codes, previous/next Unicode characters, and links to Unicode.org and w:List of XML and HTML character entity references?
Or should we place that information elsewhere in the entries?
Besides, we should be a Unicode database. That would be great. But that's just what I proposed in a past discussion (link), and I know you opposed the idea. --Daniel Carrero (talk) 17:26, 2 May 2017 (UTC)[reply]
I think such information should go in an appendix at best, not in entries. Entries should be for lexicographical data. —CodeCat17:30, 2 May 2017 (UTC)[reply]
A character entry would be incomplete without it. Maybe not all dictionaries would have an entry for a letter, punctuation mark, diacritical mark or symbol but since we have them, let's say how it's composed (Á should link somehow both to A and ´), what are their codepoints, etc.
I've never seen a dictionary that gives Unicode codepoints for character entries. To see an example of what normal dictionaries have in entries for letters, see the Oxford Dictionaries' entry for the letter A, which is a fairly long and detailed entry with 26 senses/subsenses, but has absolutely none of the information supplied by these character boxes. That's the sort of information we should have in the main namespace for letters. --WikiTiki8917:40, 2 May 2017 (UTC)[reply]
It's fairly long and detailed, because it includes long things like lists of definitions for the article a and abbreviations, not to mention phrases like "from A to B". It barely says anything about just the letter. I'm all for having all that information, but we have definitions for symbols that Oxford doesn't have, like + and ´ (it does have & and %, but they are too short, they don't have the etymology or mostly anything). Most dictionaries were published before Unicode or other codepoints existed, and they don't have a great list of symbols. We are already a symbol database, as long as the symbols are attested. Feel free to try and change that (maybe by deleting a lot of symbols?) but that's the status quo. (as you know, my proposal in the previous discussion was to have unattested symbols too) --Daniel Carrero (talk) 17:54, 2 May 2017 (UTC)[reply]
@Daniel Carrero: Note that I'm only talking about the entry for the letter (not the article or abbreviations) which is A3 and only starts at the anchor link I provided. And this particular online dictionary is continually updated long after Unicode. And my point exactly is that it talks about the uses of the letter, and not how its encoded by computers. --WikiTiki8918:00, 2 May 2017 (UTC)[reply]
I take your points: this particular online dictionary is continually updated long after Unicode, and you are talking about only the letter, A3.
If we were allowed to copy the senses directly from Oxford, we would insert most of 3 into a "Noun" section rather than a "Letter" section. (I'm not saying this is right or wrong, this is just how our senses are currently formatted.) The letter section would still have the etymology, multiple pronunciations, place in the alphabet, usage notes concerning orthography, links to versions with accents when they exist, etc.
I still support having the character box, since we're a symbol database already. Maybe we should have a vote to see if there's consensus from other people? --Daniel Carrero (talk) 18:11, 2 May 2017 (UTC)[reply]
What section it's in doesn't matter so much, that's not the point I was trying to make. I'm only talking about which information we should have versus which information we don't need. You say "we're a symbol database already", but what I'm saying is that we shouldn't be. --WikiTiki8918:57, 2 May 2017 (UTC)[reply]
It goes without saying, but feel free to discuss/vote/talk to people about that. I'm not convinced that we shouldn't be a symbol database (especially because we're pretty awesome at being a symbol database), but presumably whatever we collectively decide is fine. --Daniel Carrero (talk) 19:06, 2 May 2017 (UTC)[reply]
So just curious, do we have the slightest shred of evidence that users come here looking for "Dubeolsik inputs"? Equinox◑17:32, 2 May 2017 (UTC)[reply]
I don't know, can we ask our Korean speakers here? Are there a lot of ways to type in Korean other than knowing Dubeolsik? Is having Dubeolsik here useful? I started to learn a little about Dubeolsik specifically because it was already there when I was editing the character box module. --Daniel Carrero (talk) 17:56, 2 May 2017 (UTC)[reply]
I go to Wikipedia for Unicode-related information. If you think about it, to get to the entry for a particular character, you already need to know its code point (or rather, the computer needs to). At that point, the entry is really just telling you the code point of the character you just typed in. There's lots of sites that do that job way better than Wiktionary, like say http://www.unicodemap.org/search.asp which does it for an entire string at once. —CodeCat18:13, 2 May 2017 (UTC)[reply]
I like that unicodemap.org does it for an entire string at once. But I wouldn't ask whether other websites already do a better job, I would ask if we can do a better job than them. Besides, Wiktionary is better than unicodemap.org in everything other than full string searches and presenting UCS-2 binaries. That website does not have any images for the characters, especially not any legally reusable images. And I didn't find any appendices listing all the characters there (with legally reusable images). It does not have lists of different codepoints for the same character. It does not have most of the things I listed above. Wiktionary is much better than that. --Daniel Carrero (talk) 18:23, 2 May 2017 (UTC)[reply]
Toasters can also toast bread better than Wiktionary. That's not an invitation for us to try to outdo a toaster. —CodeCat18:25, 2 May 2017 (UTC)[reply]
Toasters can toast bread better than Wiktionary, but Wiktionary is a better symbol database than unicodemap.org, except for full string searches and presenting UCS-2 binaries. --Daniel Carrero (talk) 18:27, 2 May 2017 (UTC)[reply]
Even if we are a better symbol database than unicodemap.org, that doesn't mean that we should be. Perhaps we should create a new Wikimedia project called Wikisymbols or something and you can go and make that the best symbol database around, but I don't think that belongs at Wiktionary. --WikiTiki8919:00, 2 May 2017 (UTC)[reply]
I don't know, maybe I could support having a separate Wikimedia project like "Wikicharacters" if other people want to create it. But I'd most certainly still think that it's good for Wiktionary to keep being a dictionary of characters, even if that separate database existed.
"Wikisymbols" looks like it could become something about pictographic associations. A project to list all the abstract "meanings" of pearls, dragons, the color red, the ocean and the stars and so on. I used to have a pretty thick "dictionary of symbols" that worked like this. --Daniel Carrero (talk) 19:18, 2 May 2017 (UTC)[reply]
Why? Wikipedia kicked out its dictionary-like entries into a separate project called Wiktionary. Now Wikipedia no longer needs dictionary-like entries. Same thing here with symbols. And I don't particularly care what this new project would be called. --WikiTiki8919:21, 2 May 2017 (UTC)[reply]
I gave a few reasons above for keeping symbol entries in Wiktionary. Anyway, if other people decide they want to move all our symbol entries to a new symbol project, and Wikimedia accepts it, I guess it shall be done. It just doesn't have my support. --Daniel Carrero (talk) 19:28, 2 May 2017 (UTC)[reply]
Wikipedia is more than an encyclopedia, and includes things that no other encyclopedia would ever include. Why shouldn't Wiktionary be much more than a dictionary? We already have synonyms and a thesaurus, which I reference regularly (I still have to supplement it with Thesaurus.com, etc., but it's getting there), as well as translations, non-lemma entries, and any number of things that normal dictionaries don't have, and which I find extremely useful. Why not include symbols as well, since they're so closely linked to language? Language boxes may present more than lexicographical information, but, among other things, they do help a person understand what they're reading if they can't see the symbol, and isn't that the point of a dictionary? Now, I don't feel too strongly about whether we should have symbols here or not, but I have used Wiktionary a number of times to figure out what certain characters were when my browser didn't support the fonts needed to see them, so I certainly don't think there's any harm in keeping them. Maybe the boxes could be made less obtrusive, though. Andrew Sheedy (talk) 20:19, 2 May 2017 (UTC)[reply]
I can understand having an image of the various shapes of the character and possibly a description. But why is the Unicode information, HTML encoding, and Dubeolsik input necessary here? --WikiTiki8920:24, 2 May 2017 (UTC)[reply]
I can see HTML coding maybe being useful to someone, and possibly Unicode as well (assuming that's what you use with the ALT key when typing characters that aren't on your keyboard, but I don't do that, so I wouldn't know...). I wouldn't object to those being removed, however, unless someone spoke up and said they actually use that information. Andrew Sheedy (talk) 20:50, 2 May 2017 (UTC)[reply]
Nevermind, the ALT key thing doesn't seem to have anything to do with Unicode, unless I'm doing it wrong. That being said, I wouldn't be opposed to adding that information as well, if someone found it useful. Andrew Sheedy (talk) 20:55, 2 May 2017 (UTC)[reply]
Well I'm not even saying that the information isn't useful, just that it's not dictionary material. There are other places where you can look up this kind of information. --WikiTiki8921:04, 2 May 2017 (UTC)[reply]
I guess what I mean is "useful to have on Wiktionary." It might be useful, but easier/more logical to look up elsewhere, in which case Wiktionary isn't the place for it. But if there are people who use Wiktionary to find that information, then I have absolutely no problem keeping it here. Andrew Sheedy (talk) 21:10, 2 May 2017 (UTC)[reply]
The main benefit of the boxes, AFAICT, is the images; the main harm is the amount of space they take up, which could be reduced. Perhaps the links to the "preceding" and "following" characters could be removed (I don't see what use they are), and the other things could be collapsed, and the width of the box could be reduced. The Unicode character names are sometimes potentially helpful (when descriptive), sometimes harmful (when they are wrong but Unicode insists on them for "stability"), and usually neither (neutral). In the specific entry that sparked this post, Pa, I think it's probably unhelpful and possibly misleading to give the Unicode info of a character that is not the one the viewer is viewing. - -sche(discuss)21:03, 2 May 2017 (UTC)[reply]
See ό, which has a "technical reasons" message in the character box. As was discussed before (link), I would support consistently adding short explanations in the character boxes like "This is the entry for Pa, this is the character box for ㎩." or whatever wording explains it best. See Wiktionary:Character variations for a tentative think-tank page concerning the character variations and their character boxes.
I personally find the character boxes useful. It allows me to see the Unicode name and number of the character, when the character is visually similar or almost identical to other symbols (see, for instance, ῾), or to see the character's canonical decomposition.
Regarding the proposal to move this information to an appendix: I like having the information readily available in the entry, but having it in an appendix would be okay as long as it's quick to navigate there. Any proposals for how to make that possible? A link near the "see also" links at the top of the entry? — Eru·tuon01:53, 3 May 2017 (UTC)[reply]
I oppose moving them to an appendices. I mean, are we talking about how many characters per appendix? Maybe each appendix would list lots of characters, or the appendix would have one character only, or somewhere in between? We already have Appendix:Unicode, listing lots of tables with character information. They are nice as navigation tools, but finding a single character there is a hassle. Single-character appendices, like maybe Appendix:∌ or Appendix:な would feel like unneeded duplication, since we'll still have the symbol entries. Linking the appendix at the top would be more trouble to find the desired information. Maybe not everyone would think of finding and clicking the link. --Daniel Carrero (talk) 04:16, 3 May 2017 (UTC)[reply]
@JohnC5, Chuck Entz, Metaknowledge, Vahagn Petrosyan: User:Djkcel continues to add spurious etymologies, habitually mis-formats entries, using plain text and incorrect template code, and doesn't know how to properly cite references. Users have repeatedly gotten on his case for it, but he just shrugs it off and deletes the comments from his talk page. At the very least, can we please remove his autopatrol status? --Victar (talk) 01:20, 3 May 2017 (UTC)[reply]
I've pointed out errors several times over the years, and they apologize for the specific error, but continue to add etymologies from sources that they don't understand. Here is me cleaning up a spectacularly bad Greek etymology added shortly after they removed Victar's request that they be more careful. They're trying very hard to be accurate, but they simply don't have the background.
You'll notice that the first Ancient Greek word they gave has no accent- that's because they just transliterated it from a Latin-script mention somewhere. The accent is phonemic in Ancient Greek, so you can't link to the right entry without it- not that you'd want to in this case, because our lemmas are at the first-person present indicative, not the infinitive. The second one is a first-person present indicative form, and it does have an accent- after an extra "ιζ" that doesn't belong there. After years of adding Greek terms to etymologies, they still don't know enough Ancient Greek to spot these obvious errors. They also included a Proto-Indo-European root without any explanation for the missing *k and *n ("ζ" from *d seems plausible, though). This isn't a one-off fluke, either- they simply don't know what they're doing, and it shows. Chuck Entz (talk) 04:19, 3 May 2017 (UTC)[reply]
Exactly. Djkcel simply wanders where he pleases and edits entries in languages he demonstrably has absolutely no knowledge in. He has clearly shown over the course of several years that he is unwilling and/or incapable of improving his edit quality. --Victar (talk) 04:58, 3 May 2017 (UTC)[reply]
I have been continuously frustrated by this user. I have no further commentary to add except that this is not the first appeal I have received to look over this user's etymologies for accuracy, which is a nigh insurmountable undertaking. I have no plan for remediation but would register the continual irritation of having to rewrite these minor untruths. —JohnC505:01, 3 May 2017 (UTC)[reply]
I too would like to register my irritation with the Djkcel, who apparently acts in good faith but in my opinion is harming the project. --Vahag (talk) 07:30, 3 May 2017 (UTC)[reply]
I figured there’d be a gathering of the gods about me at some point or another, but I at least appreciate the ability to partake in it. A few things:
I promise you that all the edits, good or bad, are in good faith. I have no malicious intent and I just want to help.
I sincerely do apologize for the issues in formatting and sourcing. I am making a conscious and daily effort to improve across the board. As someone mentioned further up on this page, Wiktionary’s syntax is difficult to master and its documentation has left some to be desired (e.g. I can’t find any entry on ‘’templunk”, or how to replace the word ‘unknown’ with ‘uncertain’ and keep it tagged as unknown. I had to find it through other edits); even when I think I’ve done it well, it’s apparently wrong. In the past I’ve been guilty of forsaking time spent formatting in favor of rapid editing, because I felt that the formatting got in the way of the true goal of expanding knowledge and discussion. This was a mistake, and I’m going to pay more careful attention to it in the future. Also, regarding sources, I’m going to consult direct ones. I’ve used ‘middle-man’ sources like Harper’s etymOnline, but, according to the editors/reverters on here, over 50% of his entire site is wrong. Also, you're right, my Greek sucks. I'll use Template:rfscript for words I'm not able to copy and paste.
While I acknowledge these learning curves and mistakes, I do think guys are being a little too harsh on me by saying I have no idea what I’m doing. With the 6000+ edits I’ve made I do like to think that I am choosing interesting stuff to work on, meticulously tracing word lineage and at least creating some unique dialogue/discussion. 95% of what’s said to me on here is criticism and I’m rarely thanked for any edits, so it is hurtful. I do want to be accepted for my contributions instead of being seen as a burden or some idiot who’s doing more harm than good.
I didn’t know deleting posts off of your talk page was frowned upon. User:Victar’s post was a request for more careful sourcing, something I processed, followed by a threat to remove me from the whitelist. I just didn’t want to see it anymore. I won’t delete posts again.
Finally, @Victar, I appreciate your recent turn of attention toward me and the quality of my edits. Since fsojic left, I haven’t had a primary scolder. Although, the things he said to me bordered on downright abusive and constantly violated Wiktionary’s rules of civility, while your discussion has been a little more constructive and concerned with the overall good of the project's quality. It’s helpful and it keeps me from going on autopilot.
Thank you all for the patience, advice, prodding, etc. over the years. For personal reasons, this has been an extremely difficult year for me, and I can’t lose wiktionary. I’m very passionate about exploring this site - for every 1 entry I edit I’m looking at 30 other pages out of sheer curiosity. Please realize that I’m going to make every effort to continue to improve, expand, stimulate, and quality-check the knowledge and discussion I contribute to this project. I hear you, and I'm with you. Djkcel (talk) 14:24, 3 May 2017 (UTC)[reply]
@Djkcel:, I can appreciate your intentions, but the problem is we've been dealing with the same issue over and over again since 2012 and we haven't seen much of any improvement. We don't need apologies, we need change and 6000+ edits means nothing if the majority are bad. I had asked you to be more mindful of sources, particularly for reconstructions, and the next day you went and did that same thing and then deleted my post from your talk page. That's not indicative of someone willing/capable of changing. We simply can't have you editing languages you don't have knowledge, i.e. Greek, etc, because doing so, as Vahagn says, is harming the project. --Victar (talk) 15:13, 3 May 2017 (UTC)[reply]
The Wikimedia Foundation Board of Trustees is the ultimate governing authority of the Wikimedia Foundation, a 501(c)(3) non-profit organization registered in the United States. The Wikimedia Foundation manages many diverse projects such as Wikipedia and Commons.
Is there any way to generate a list of redlinked uses of {{l}} and {{m}} for a certain language? It would be useful to add e.g. words that already have cognates listed in another language's entry. —Aryamanarora(मुझसे बात करो)22:57, 3 May 2017 (UTC)[reply]
That's an automatically generated category. I could generate a list for a specific language from specific templates if requested. DTLHS (talk) 23:23, 3 May 2017 (UTC)[reply]
Since yesterday evening, the extension that provides the interwikilinks is temporarily disabled, to solve a performance problem. We hope that the extension will be back during the present day, and we apologize for the inconvenience caused. Lea Lacroix (WMDE) (talk) 09:07, 4 May 2017 (UTC)[reply]
Update: we're still working on fixing the problems of the extension. To avoid you more inconvenience, we reactivated Cognate on "read-only" mode: that means that the interwikilinks are back, but if new pages are created, or some pages deleted, the links are not currently updated. Thanks again for your understanding, I'll keep you posted as soon as everything is running correctly again. Lea Lacroix (WMDE) (talk) 18:33, 4 May 2017 (UTC)[reply]
Update: Cognate is back :) If you spot some errors, links that are missing or should not be there, etc. please ping me.
Monthly suggested collective task is to take care of flowers. At first, some people aim to create a thesaurus in French Wiktionary and suggested this topic. Here, Wikisaurus:flower already exist but may be expand as well. Also, there is plenty pictures on Commons to illustrated entries, but quotations are quite hard to find and good sources are precious. The Category of flowers contains 233 entries but garden plants on Wikipedia already list 624 pages!
Let's celebrate spring and populate our virtual garden with some flowers!
Lexisession is a collaborative experiment without any guide nor direction. You're free to participate as you like and to suggest next month topic. If you do something this month, please report it here, to let people know you are involve in a way or another. I hope there will be some people interested by flowers Noé09:38, 4 May 2017 (UTC)[reply]
Hi. I propose removing "Adding nonsense/gibberish" as a block reason. If the nonsense is being added by way of troublemaking, then "Vandalism" already covers this. If not, or if we're not sure, then "Disruptive edits" would seem to cover it. Equinox◑18:57, 4 May 2017 (UTC)[reply]
Fine with me. To be fair, disruptive edits and abusing multiple accounts cover pretty much everything I ever block for. - TheDaveRoss19:19, 4 May 2017 (UTC)[reply]
I like it. I think it makes the vandal sound childish, whereas they might be pleased to be "disruptive" or have their actions labelled as "vandalism". That's pure speculation, of course. —Μετάknowledgediscuss/deeds19:47, 4 May 2017 (UTC)[reply]
Mmm. Just a thought. I suppose my reasoning could also support removing "Vandalism" etc. because they are a subset of "Disruptive edits". To me, "disruptive" is usually something that the editor thinks is good but that actually causes big trouble, like single-handedly trying to reorganise Serbo-Croatian. Equinox◑20:02, 4 May 2017 (UTC)[reply]
Oh, I would think "disruptive edits" were intentionally disruptive. I do think we have too many and redundant block reasons, and page deletion reasons. Maybe we can't merge all four of "adding nonsense/gibberish", "disruptive edits", "unacceptable conduct", and "vandalism", but some of them could be combined. How about combining as "Disruptive or unacceptable conduct", and (at the very least) "Adding nonsense/gibberish/vandalism"? And how often do we have to block for "unacceptable username"? And do we still have to block Open Proxies often enough that it needs to be a prewritten option in the list, or can we remove it? (Btw, on the subject of things vandals might be pleased by: being described as "intimidating"!) - -sche(discuss)20:17, 4 May 2017 (UTC)[reply]
I suspect vandals are ultimately pleased by causing disruption, regardless of the particular words that the "disruptee" community uses to describe it. But yeah it seems funny to me sometimes to use "intimidation" when I am basically reverting "John Smith is a dick" and he could be anyone anywhere. Equinox◑22:24, 4 May 2017 (UTC)[reply]
Support. People might add nonsense by means of not understanding the site or by error. The block reason should be the malign intention, which would make it vandalism. Korn [kʰũːɘ̃n] (talk) 22:22, 4 May 2017 (UTC)[reply]
Per Equinox's comment in the section below this, I've put a copy of the list of common block reasons at MediaWiki talk:Ipbreason-dropdown, where (I think) everyone can comment on each reason (maybe indented under each reason?) with what they use it for, whether they think it could be combined with something else, etc. - -sche(discuss)02:40, 8 May 2017 (UTC)[reply]
Related to the discussion above, I think there are too many preset page deletion reasons, which pushes useful page deletions down far enough that you have to scroll to find them, which is an admittedly minor annoyance. I don't think "bad redirect" and "residual from move" needed to be split and I suggest recombining them: "bad redirect or residual from move". And do we still delete transwikis often enough that it needs to be a preset delete reason? Related to the comments above about how "Vandalism" might be taken as a badge of honor, perhaps it could be folded into "incomprehensible, meaningless, or empty"? I would also suggest combining "not a citation; see Citations:hydrogen as an example" and "improper use of a talk or citations page". And I don't think we delete orphaned talk pages anymore (we put e.g. the entry's RFD on them), so I suggest removing that deletion reason and combining "orphaned documentation" with "unused template subpage". - -sche(discuss)20:31, 4 May 2017 (UTC)[reply]
I think a bunch of them could be merged into a catchall "Technical deletion" line (redirect, created in error, residual from move, transwiki, technical). - TheDaveRoss20:34, 4 May 2017 (UTC)[reply]
Okay. Can we create a temporary discussion page that lists all of the current deletion reasons, and have people comment under each one (possibly keep/delete, but preferably a proper comment with their understanding of what it means, and how they use it)? Then we could get a "big picture" of usage and probably collapse a few of them into others. Equinox◑22:23, 4 May 2017 (UTC)[reply]
Good idea. I've put a copy of the list of common deletion reasons at MediaWiki talk:Deletereason-dropdown, where (I think) everyone can comment on each reason (maybe indented under each reason?) with what they use it for, whether they think it could be combined with something else, etc. - -sche(discuss)02:41, 8 May 2017 (UTC)[reply]
I boldly combined the two "bad redirect" deletion lines and the "transwiki" line into an "unwanted redirect or transwiki" line. I also noticed there were two lines for in effect "deleted due to move/merge", which I combined. And I removed "orphaned talk page" as a delete reason. - -sche(discuss)02:58, 8 May 2017 (UTC)[reply]
The userpage of prolific Wiktionary contributor, Robert Ullmann--who passed in March 2011, and whose user page was agreed to have a link to his obituary back in September 2011--currently has a broken link.
The discussion with support for fixing his user page in the first place is here.
I did a quick google search and apparently valid links to his obit may still be found online. I suggest that the Wiktionary editor community come to consensus and agree to fix the (now broken) link on his user page. I would, of course, support that outcome and see his user page updated once more, after his death. N2e (talk) 00:33, 6 May 2017 (UTC)[reply]
There's no need for consensus, or even for a post in the Beer parlour. I've fixed the link, and in the future, you can just ask me or any other admin to do it. —Μετάknowledgediscuss/deeds03:13, 6 May 2017 (UTC)[reply]
Nothing, in my opinion. If someone is stupid enough to try to email him despite the big obituary notice on the top of the page and lack of a talk-page, that's their problem. —Μετάknowledgediscuss/deeds05:50, 6 May 2017 (UTC)[reply]
I am also not sure that we could change that setting. The developers could I suppose, but I agree with Meta that it is not a big deal. - TheDaveRoss12:58, 6 May 2017 (UTC)[reply]
THanks folks. I agree that I could have asked an admin; but I'm fairly inexperienced on Wiktionary as Wikipedia is my primary gig and I could not find an easy link to get me to an admin on Wiktionary. Sorry for the trouble. Cheers. N2e (talk) 02:27, 7 May 2017 (UTC)[reply]
There are a number of module errors in Cat:E after User:Metaknowledge changed the language code "xil" in the data modules to an etymology-only language. As I've said in the past, there doesn't seem to be any justification for having mainspace entries in this language: it has no direct attestation and extremely limited indirect attestation in Ancient Greek and Latin texts, so I'm not advocating keeping it as unrestricted. I do note, however, that there are a number of etymological references which cite Illyrian words, and not all of them are fringe sources. Aside from terms actually mentioned in Greek and Roman texts, these seem to be reconstructed by analyzing those terms and looking for possible Indo-European cognates to possible morphemes within them.
I would recommend Illyrian being marked as a reconstruction-only language, but our current practice seems to be to to reserve the Reconstruction namespace for terms derived via the comparative method from descendants. Although there's some speculation about the Albanian language itself and various substrata in other Balkan languages being descended from Illyrian, these don't really have any undisputed descendants. Any suggestions for how to resolve this without removing all Illyrian terms from our etymologies? Chuck Entz (talk) 05:08, 7 May 2017 (UTC)[reply]
Unfortunately, I think these are needful module errors (errors that should not have existed in the first place, and need to be cleaned up by hand). These entries should not be referencing Illyrian entries the way they are, especially those terrible Albanian etymologies. Reconstructions would be pretty unsupportable, but I'm not sure how (or if) hypothetical Illyrian terms should be mentioned. Unfortunately, I don't have the background or the resources to do a worthy job of fixing these; @JohnC5, Vahagn Petrosyan might be able to fix them. —Μετάknowledgediscuss/deeds05:16, 7 May 2017 (UTC)[reply]
Since Illyrian is not attested in inscriptions, I support disallowing it in the mainspace. The glosses and onomastics attested in Ancient Greek and Latin texts can be handled under Ancient Greek and Latin. But I don't see any problem in allowing Illyrian reconstructions, as long as they are sourced. --Vahag (talk) 16:58, 7 May 2017 (UTC)[reply]
A user (you know the one) has been simply removing the {{l}} template around Illyrian terms as a way to fix the error that it now gives, apparently not getting the hint. —CodeCat21:57, 7 May 2017 (UTC)[reply]
Yeah, this user is getting on my nerves. I would prefer to have Illyrian be a reconstructed language. As for Messapic and Phrygian, I can't decide whether I'm fine with this user using the Greek alphabet for the entries. Paleo-Phrygian and Messapic were in Greek-ish alphabet (ignoring Neo-Phrygian, which is in the Greek alphabet), but that is something that would need to be discussed. Honestly, I don't know what to do about this situation, since the user does cite real, if slightly misread, antiquated, or outdated, sources. —JohnC522:41, 7 May 2017 (UTC)[reply]
Sorry for not responding quicker to your pinging me on the user's talkpage; I wasn't sure what should be done with this language. Almost all of our "etymology languages" are attested varieties of other languages, or in a few cases, substrates where we're not even sure if they're one language, whereas this is a specific language which we know existed but haven't found direct attestations of. I like Vahag's idea of making it a type = "reconstructed", language. (Conversely, there are some "exceptional codes" for conlangs, for example Dothraki, which I wonder if we could move to "etymology languages".) - -sche(discuss)02:19, 8 May 2017 (UTC)[reply]
In case anyone missed it, the user has now added the entry Terittituniš from the language "Hayasan" with a great deal of non-dictionary information. —JohnC517:28, 8 May 2017 (UTC)[reply]
All these entries are still in CAT:E. It's kind of annoying, since it makes it somewhat hard to find the errors that relate to other things. What should be done about them? If there's no immediate solution, what about restoring Illyrian to Module:languages/data3/x and marking it as deprecated? — Eru·tuon17:07, 11 May 2017 (UTC)[reply]
Per the discussion above, I have restored Illyrian to a 'full code' (in Module:languages/data3/x rather than an etymology-only code), but as a "reconstructed" language. Out of curiosity, is this the first ISO-coded language that we've classified as "reconstructed"? It's a sort of counterpart to Proto-Norse (which is, unusually, a directly-attested proto-language). - -sche(discuss)19:17, 11 May 2017 (UTC)[reply]
Proto- is really just a name, and it has other names such as "Primitive Norse" (parallel to "Primitive Irish") as well. However, since it's the common ancestor of the Norse/North Germanic languages, it fits. —CodeCat19:23, 11 May 2017 (UTC)[reply]
I suggest that we develop and enforce a policy on the writing of PIE roots to avoid reduplication. My understanding is that at present the mainstream view and/or convention is that PIE did not contain /a/, that a minimal phonological scheme contains four vowel sounds /e/, /o/, /ē/, /ō/, and that roots previously written with /a/ should be written using one of the laryngials (/h₂/, usually) plus /e/. The evidence that /a/ is necessary for an explanation of derived forms, independently of /h₂/, does not have broad acceptance. There are other schemes, other conventions, and all of this remains a matter of dispute, but at the moment this dictionary uses a mixture of various schemes. *átta is included in our current PIE root list as distinct from *ph₂tḗr and it is not clear to me how this can be justified. Ordinary Person (talk) 10:41, 7 May 2017 (UTC)[reply]
Most of what you say makes sense, even if some of it is debatable (see WT:AINE, which covers most of it, though it allows for rare original a). The last sentence, though, is bizarre: ignoring the vowels and laryngeals, you still have tt equated with ptr, which is often analyzed as p + tr. Huh?. Chuck Entz (talk) 15:50, 7 May 2017 (UTC)[reply]
Inconsistent transcription is mostly backlog on cleaning up etymologies from before we had standards, or added by inexperienced editors. @Sobreira has been collecting some working lists on this, while I've imported a list of "standard roots" at User:Tropylium/Proto-Indo-European/Verbs.
Roots contained *a are not very popularly supported (it remains as a minority opinion), but allowing *a in isolated lemmas such as *átta or *ǵʰans would probably be less of a problem. (I suggested some time back writing a-coloring out even in derived complete words, so e.g. *h₂antíos and not *h₂entíos, but this went unsupported.) --Tropylium (talk) 17:09, 7 May 2017 (UTC)[reply]
Fair rejoinder, Chuck Entz, that was not a good example. I'm fairly new to Wiktionary, is there a clean-up project for this that I could join? Ordinary Person (talk) 02:28, 8 May 2017 (UTC)[reply]
OK, let's go over this as an example. The variation in writing any of these with or without a dash should be a trivial issue I hope, but the rest is indeed a mess:
*pelh₂- is a basic root, meaning roughly 'flat, flatness, flatten'.
The reconstruction is, however, wrong! We currently have the lemma for this root instead at *pleh₂- (compare the derivative *pleh₂k-, number 6 below).
*pele- is (one version of) the corresponding pre-laryngealist transcription.
*pla- appears to be the root in zero grade in pre-laryngealist transcription, corresponding to to modern *pl̥h₂-. (But we do not create separate root entries just for the zero grade.)
*plat- and *plÁt- are different pre-laryngealist transcriptions of the previous.
*pleh₂k- is another derived stem; this time a verb 'to flatten', I think. However, it is also a variant of a separate unrelated root *pleh₂g-, meaning '(to) beat'. (This covers Latin plaga, sense 1)
*plāk- is the previous in pre-laryngealist notation.
*plak- is the zero-grade of this stem in pre-laryngealist notation, corresponding to modern *pl̥h₂k-.
Ah, I see. There's also another issue with that etymology: *pl̥h₂t- could never possibly give *flaþ- directly, it would become *fulþ- or *fuld-. —CodeCat23:00, 8 May 2017 (UTC)[reply]
It's likely that in the post-PIE period, when laryngeals had already vocalised, that a was reanalysed as the zero-grade vowel of such formations. Consider for roots of CeH shape, that you'd have an alternation between ē/ā/ō, ō and a in early Germanic. It would not be surprising then if this pattern was also applied to roots of CReH shape, whose inherited ablaut was Rē/ā/ō, Rō, uR, which is rather irregular. Analogical pressure to treat a as the zero-grade of such "long vowel roots" would not be surprising. I think this could be the origin of *flaþô, and also some others such as *bladą. With *flaþô there's the additional question of why a zero grade had an accent, which was very rare in PIE. —CodeCat19:31, 11 May 2017 (UTC)[reply]
*pelh₂-/*pleh₂- (I didn't get it) with Alternate spelling *pele-, which would include *pla- as Alternate spelling for 0-grade *pl̥h₂-
Verb root *pleh₂k- (which AFAIU is actually *pleh₂ + k-) with Alternate spelling *plāk-, rooted from and to be included in 1, which would include *plak- as Alternate spelling for 0-grade *pl̥h₂k-.
Noun root *pl̥h₂t- (which AFAIU is actually *pl̥h₂ + t-; but why not *pleh₂t- from *pleh₂- + t? we do create entries only for E grade, innit?) with Alternate spellings *plat- and *plÁt-, rooted from and to be included in 1
*pl̥h₂tós or *pl̥h₂téh₂ to be created as origin for some nouns and rooted from 1 pointing to section 1.2 Noun root
all Alternate spellings redirected (as per WT:AINE; but do we include it like we include Alternative reconstructions?) and/or removed and changed from the respective Etym sections. Sobreira ►〓 (parlez)10:58, 15 May 2017 (UTC)[reply]
Anyone else think this namespace might be better named simply Thesaurus or Synonyms? I mean, we have Talk, Citations and User as namespaces, which are all generic terms. Wikisaurus might work as a project name, but seems strange as a namespace name. Equinox◑21:42, 7 May 2017 (UTC)[reply]
This can be done easily by using Thesaurus as an alias for Wikisaurus (or the opposite), as it is already done for WT -> Wiktionary (e.g. WT:BP). — Dakdada14:22, 9 May 2017 (UTC)[reply]
The pages house more than synonyms (for example, they include antonyms and coordinate terms), so maybe "Thesaurus" is a better name than "synonyms"; I'm not sure. The whole thing seems a bit redundant to the synonyms (etc) sections in entries. - -sche(discuss)04:27, 8 May 2017 (UTC)[reply]
I agree. I also think it seems somewhat redundant, but I'd rather see synonyms, antonyms, holonyms, etc. moved to Wikisaurus to declutter entries than get rid of Wikisaurus. Andrew Sheedy (talk) 04:32, 8 May 2017 (UTC)[reply]
Can you elaborate on this? I like the idea of using Mediawiki structures to store data, but I am not sure how this might actually be accomplished. One problem is that not all terms which are allowable in Wikisaurus are allowable in the main namespace. Beyond that, I am guessing the idea would be to create a category which is something along the lines of "Terms semantically related to X", and then have subcategories which are "Synonyms of X", "Antonyms of X", etc. Is that the kind of thing you are imagining? I have always thought that it would be much harder to maintain that sort of structure, but it might provide some interesting opportunities. - TheDaveRoss15:12, 8 May 2017 (UTC)[reply]
That's basically it. We would add a template like {{synonyms|xyz}}, where xyz is the canonical word that we've chosen to list synonyms under for a particular concept. Each page would then categorize into "Synonyms of xyz". We could use the categorytree extension to create expandable lists of synonyms in the way that {{prefixsee}} works. The downside like you said is if there are thesaurus entries that can't be mainspace entries. DTLHS (talk) 15:17, 8 May 2017 (UTC)[reply]
Color me intrigued. This and the current incarnation of Wikisaurus are not mutually exclusive, so perhaps we should apply this style to a couple of terms to see how it looks and what the drawbacks might be? It would certainly cut down on some redundant effort, and it would consolidate more information about a term to that term's entry. - TheDaveRoss17:57, 8 May 2017 (UTC)[reply]
This is already possible with {{syn}}, albeit that there's nothing particular about the order of terms listed in it, currently. —CodeCat17:59, 8 May 2017 (UTC)[reply]
It also lets you link to Wikisaurus pages: Synonym:Wikisaurus:good. It currently wraps the link in language/script tags, which is not ideal, but it doesn't break. —CodeCat18:02, 8 May 2017 (UTC)[reply]
While I don't dislike Wikinyms, I think it suffers from the same problems as Wikisaurus. I think I might like Wikinyms better than Wikisaurus though. - TheDaveRoss20:21, 8 May 2017 (UTC)[reply]
The word thesaurus have two meanings: one in a lexicographic context, for terms semantically related (Q179797), two in a documentation or database context, for information retrieval (Q17152639). I am not sure English Wiktionary and French Wiktionary agree on which one we want to develop in our projects. I think, for most of the contributors, both are quite similar, but the traditional objects and the purpose of each ones are very different. In a lexicographic one, we can offer much more content without defining referential descriptors. The other use is much more formal, with rigid categories. So, which one do you think Wikisaurus is? (as usual, sorry for my mistakes, as English is not my mother tongue, please correct any mistakes leading to misunderstanding) Noé13:33, 9 May 2017 (UTC)[reply]
@Equinox: Did you deliberately not include the status quo as an option or was it an oversite? And yes, please make sure that if this gets renamed that there are auto-redirects in the settings. There will be incoming links, users who haven't been here for awhile, etc. Honestly, moving something that has been named [X] for several years really needs to justify the effort and the potential for broken links, etc. —Justin (koavf)❤T☮C☺M☯22:27, 21 July 2017 (UTC)[reply]
So people who want the status quo would have no say in the replacement name that would be chosen if they lost? These would seem to be separate issues. A better format would be to have Part 1: Do you want to rename Wikisaurus? and Part 2: If it's decided to rename, what name would you prefer? Part 2 would basically be the same as the entire current vote. It would also make interpreting the result much easier: how would you interpret it if the total of those opposing everything was far less than the total of those voting for something, but greater than the vote for any one of them? Chuck Entz (talk) 23:36, 21 July 2017 (UTC)[reply]
Looks all right to me. Might need to add some tiresome provisions along the lines of "if you oppose changing it at all in section 1, but don't explicitly oppose the choices in section 2, it means blah blah blah..." Equinox◑23:10, 22 July 2017 (UTC)[reply]
Many entries include not only which dialect they belong to, but also the categories of the broader dialects to which those specific dialects belong, as well as the vague label "dialect". For example, scaurie is labelled "(Britain, dialect, Shetland)", so it is in CAT:British English, even though I take the label to mean it is not found pan-Britannically but rather just in Shetland, and it is also in CAT:English dialectal terms. But scattald is labelled "(Orkney and Shetland)", so it is only in categories for Orkney and Shetland English, and not CAT:British English nor CAT:English dialectal terms, which is inconsistent.
Do we want all terms which belong to any dialect to also go in CAT:English dialectal terms? If so, we could just have every dialectal label double-categorize into that category. Whereas, if not, a lot of entries need to be edited. Likewise, do we want terms from British (American, etc) sub-dialects to be double-categorized into the "big" dialect categories, or should such (manual) double-categorization be removed? - -sche(discuss)04:25, 8 May 2017 (UTC)[reply]
Optimally I think we would prefer to have zero words categorized directly under categories like CAT:English dialectal terms or CAT:Regional English, instead placing every such word under some more specific dialect category. (Additionally, I have no idea what the distinction these two categories is supposed to serve.) A lumpencategory "English dialectal terms" is no more useful than something like "lemmas in Slavic languages that lack cognates in other Slavic languages".
I have no immediate opinion on dialect group double categorization: it seems like just a particular dialect group's equivalent of the mother categories like CAT:English lemmas. On the other hand, "American English" and especially "British English" are more geographical groups than dialectological ones, which may be a point in favor of reserving them just for pan-Americanisms and pan-Britishisms. --Tropylium (talk) 10:46, 8 May 2017 (UTC)[reply]
Etymology summaries for intermediate sources[edit]
It is often the case that we can reliably trace a given word's etymology to a particular source language (e.g. a reconstructed intermediate proto-language, or an influental attested language such as Latin or Arabic), while the further etymology remains disputed or uncertain. We often give information on these less likely earlier stages anyway. However, if new information comes up, this may end up requiring much duplicated work in fixing mainspace entries. For an example, I recently added a new source for the etymology of Proto-Germanic*swerdą(“sword”). This however has several dozen descedants, many of which still refer to the older etymology.
I propose we create a template for printing a small lay summary of the etymology of a word in some given "chokepoint" language. The intended output would be something like:
{{etymsumm|en|gem-pro|*swerdą}} → "possibly from {{der|en|ine-pro|*seh₂w-||sharp}}"
For editor accessibility, i.e. not codewalling etymologies to be editable only by editors versed in data modules, I think the lay summary should be stored in some accessible format on its own subpage or the like: e.g. Reconstruction:Proto-Germanic/swerdą/summary. This could have simply the content possibly from {{der|XXX|ine-pro|*seh₂w||sharp}}. The {{etymsumm}} template would then do the actual data massaging, to substitute the appropriate language codes for "XXX" (or whatever other keyword we choose) — or other functions as desired. (For example, perhaps {{PIE root|XXX|feh₃}} could be auto-inserted whenever the summary contains {{der|XXX|ine-pro|*feh₃-}}.)
Thus, whenever new etymological information comes up, instead of having to emend dozens of descendant etymologies by hand every time, we could simply centrally emend the lay summary and end up with all affected entries automatically updated.
Admittedly there will not be much immediate benefit to this, since editing our current etymologies to actually use {{etymsumm}} and writing said summary entries would take manual work anyway… but in the long run this seems likely to be valuable.
I'd rather wait for a better solution to come along. I will say though that I think non-English lemmas should only point to its immediate parent in the etymology, if that parent already has an entry. That would drastically cut down on duplication, ex. Old Saxonswerd. --Victar (talk) 16:36, 8 May 2017 (UTC)[reply]
The issue of duplication and (non)synchronization is problematic even without chokepoints, so it may be better to solve it by putting the whole chain into Template:findetym or similar templates. However, even that may be unable to handle cases where there is a long list of possibilities after a chokepoint (see the etymology of the "group of people distinguished from others" sense of race, for an example), where an approach like you suggest would be good, except with the whole etymology (rather than a summary) put in the template.
An alternative idea for the second case is to centralize on "lemma" entries, so if e.g. Japanese borrowed English "race", the Japanese entry would just say "from English race, see there for more", and maybe the Italian entry would also say "uncertain, see English" (since this is the English wiki and English is privileged). Some (like Victar) might suggest moving the etymology to the Italian entry and having English say "see Italian", but that removes the (IMO desirable) categorization into "English terms derived from Lombardic" (though regarding the category name, maybe it would be good to have a set of categories saying more specifically "...possibly derived..." for cases of great uncertainty like this, or maybe not).
I definitely wouldn't support "lemmatizing etymologies", exactly because it's going to make it difficult to find X terms that have made it into a "non-etymology-lemma" language Y. Also we'd need to set up a whole damn hierarchy of languages for lemmatizing this or that. If we lemmatize English as primary, we still need some way to handle cases where no English reflex exists, and probably even in many cases in which it does. It would be absurd to refer, say, the Dravidian cognates for the Tamil source of mung to the English entry.
In cases like "race" though, the only reasonable etymology summary would probably still come out as "of disputed origin, see race for details". --Tropylium (talk) 18:07, 8 May 2017 (UTC)[reply]
I just remove cognates when they're already listed on one of the ancestors. Ideally, cognates would not need to be listed at all. —CodeCat18:18, 8 May 2017 (UTC)[reply]
From May 9, the Two Column Edit Conflict View will be available as a beta feature on all wikis. The Two Column Edit Conflict View is a new interface for the edit conflict resolution page. It highlights differences between the editor's and the conflicting changes to make it easy to copy and paste pieces of the text and resolve the conflict. The feature fulfils a request for a more user-friendly edit conflict resolution from the German Community’s Technical Wishlist. Everyone is invited to test the feature and we hope that it will serve you well!
That looks like a lovely feature, and I plan to enable it when it's available. (It doesn't yet appear in Preferences, even though it's May 9th already.) Thanks for letting us know. — Eru·tuon21:02, 9 May 2017 (UTC)[reply]
I have noticed that all the eponym categories, such as Category:Czech eponyms, include a description like "Czech terms derived from names of real or fictitious people." However, I think that only a noun can be an eponym (English Wikipedia says: "An eponym is a person, place, or thing for whom or for which something is named, or believed to be named.") and e. g. verbs derived from names of people are not eponyms. So I suggest to change the word terms for nouns in the description of the categories. --Jan Kameníček (talk) 15:44, 8 May 2017 (UTC)[reply]
Yes, I can see it now, but the definition is not accompanied by quotations attesting such broad understanding of the term eponym. I have also never heard it in connection with e. g. verbs.
I have just done a quick Google search and found some examples where the term eponym is used in connection with adjectives, but I am not sure how widely this is accepted. I cannot find any verb to be described as eponym. Is švejkovat an eponym? --Jan Kameníček (talk) 16:08, 8 May 2017 (UTC)[reply]
Well, "Bowdlerize is an eponym after Dr Thomas Bowdler", for example, to quote one of the many books at google books:bowdlerize eponym link updated which call that verb an eponym. And Dictionary.com agrees that an eponym is "a word based on or derived from a person's name". Whereas, several other dictionaries don't even recognize any words as eponyms, but only the people who give their names to things (our entry's sense 1). - -sche(discuss)16:50, 8 May 2017 (UTC)[reply]
As for "many books at Google books", the search that you have provided shows me just Wordcraft dictionary. Is it a source acceptable to attest the meaning in the entry eponym?
As for Dictionary.com, it does not say that bowdlerize is an eponym. It has got an entry eponym, but a dictionary entry is not acceptable to attest a meaning in our entry. --Jan Kameníček (talk) 17:21, 8 May 2017 (UTC)[reply]
There are more than enough books at the search I linked to (perhaps they are only visible in some countries? Google is picky about who it shows what; I can type up three if needed) which attest that the usual English meaning of eponym includes verbs, adjectives, etc. I only mentioned Dictionary.com since you appealed to Wikipedia's definition, which weakly implied that the term was restricted to nouns, whereas Dictionary.com affirms that it applies to any word. - -sche(discuss)17:25, 8 May 2017 (UTC)[reply]
Hm, that is quite possible that some search results are not visible in my location. Are there any publications suitable for our attestation purposes? --Jan Kameníček (talk) 17:29, 8 May 2017 (UTC)[reply]
Yes, I've typed up a few in the entry and its citations page. But also my link was off, which is probably w3hy it didn't work: it shouldn't have included the quotation marks, I'm sorry! - -sche(discuss)17:47, 8 May 2017 (UTC)[reply]
We are currently lacking a category for atmospheric phenomena, like sun dog, rainbow, heiligenschein, the newly-discovered Steve, and so on. So I'd like to create Category:en:Atmospheric phenomena for these. We also don't have a category for different weather phenomena, like the basic rain, snow, fog, and so on. I considered creating Category:en:Meteorological phenomena for these, but I'm actually not sure if these two categories are clearly delineated. I'm assuming that all meteorological phenomena are also atmospheric phenomena and so the former is a subcategory of the latter. But I can't really establish clearly whether something is "meteorological" or not, so that makes the categorisation difficult, and I can imagine others will have similar difficulties. So should we just put them all in the one "atmospheric" category, or create both? —CodeCat21:16, 8 May 2017 (UTC)[reply]
As for where to put Steve, I would just create the one "atmospheric" category; given the noted difficulty of deciding whether a term is 'atmospheric' or 'meteorological', I might only worry about splitting the category up if it ended up more than ~200 entries in it, by which point perhaps some other subdivisions might suggest themselves.
The "weather" category is topical, though, whereas I am proposing a set category. One for just the names of phenomena, leaving terms related to weather to another category. I like to keep these things separate so that the "related" terms don't muddle up the rest. —CodeCat21:37, 9 May 2017 (UTC)[reply]
I've now created Category:en:Atmospheric phenomena and managed to fill it up with quite a few entries pilfered from other categories. I also categorised "Clouds" under it, since all clouds are atmospheric phenomena and therefore form a subset. —CodeCat22:03, 9 May 2017 (UTC)[reply]
How am I supposed to order the languages when the language name is no longer present in the wikitext? —CodeCat13:47, 9 May 2017 (UTC)[reply]
I suppose you have to look back and forth between the preview and the wikitext, but that's annoying. Perhaps a module could do it, but that would make it difficult to put inherited words first. Or a bot. But again, I'm not sure if a bot would be smart enough. I see the disadvantage to using {{desc}}. — Eru·tuon19:13, 9 May 2017 (UTC)[reply]
This is probably a bad idea, but the template could be modified to use canonical names instead of codes. That would be inconsistent with all the other templates, though. — Eru·tuon19:15, 9 May 2017 (UTC)[reply]
I don't see any problem with having to refer to the preview. I'd rather that than typos and wrong language codes, which are common. --Victar (talk) 19:28, 9 May 2017 (UTC)[reply]
That is a distinct advantage, being able to automatically check that a canonical name and code are valid. And when one is listing a form in a subvariety of a language, there was, till now, no way to check the subvariety against Module:etymology languages/data to see that it exists. — Eru·tuon20:24, 9 May 2017 (UTC)[reply]
You don't see a problem, I do have a problem. What's going to be done about it? Or is your purpose to make it so tedious for me to edit descendants that I just won't bother anymore? —CodeCat21:38, 9 May 2017 (UTC)[reply]
We have two problems: no checking for validity of a canonical name when the language name is written out, the tediousness of alphabetizing when the language name is not written out. A solution that deals with both these problems would be best. — Eru·tuon22:07, 9 May 2017 (UTC)[reply]
I find having to figure out the order of all the language codes much more tedious and mentally heavy. —CodeCat22:43, 9 May 2017 (UTC)[reply]
I just don't see it being a problem if you use preview, but two possible solutions to {{desc}} and {{desctree}} are 1. add a comment automatically before each use, ex. <!--Old French-->, or 2. that when you save, it automatically hard-codes the prefix, → Old French: . I'm not sure if preview would work though, which kills the validity check benefit in preview. --Victar (talk) 23:01, 9 May 2017 (UTC)[reply]
@Victar: The difficulty with using a bot is that we typically put inherited languages first. There would have to be a way to signal to the bot either that those languages are supposed to be first (arbitrarily) or that they are inherited and therefore the bot can infer that they should be first. — Eru·tuon22:49, 10 May 2017 (UTC)[reply]
@Victar: I think the name you proposed initially, before your edit changing it, |alts=, would be better. Generally, it is preferred to have the default value of a boolean parameter be false, and to name the parameter accordingly. — Eru·tuon21:14, 9 May 2017 (UTC)[reply]
Sure, whichever is fine with me. Good idea though? As I've been converting descendant lists, I've come across times I could use it, instead of manually inputting alternatives. --Victar (talk) 21:18, 9 May 2017 (UTC)[reply]
I think {{desc}} should not be deployed widely until an easier solution to the problem of alphabetization is developed. Just think if we tried to do a similar thing for {{t}}: have it automatically generate the language name. That would be a nightmare for an editor to alphabetize by glancing back and forth between preview and wikitext, when there are as many translations as in the Translations section of water.
Admittedly, automatically alphabetizing a translations table would be easier, because everything in a translations table is alphabetized alike, rather than there being some languages that are put first.
But until a bot or JavaScript or Lua can alphabetize descendants lists, I don't think it's not a good idea to remove the written-out language names. Adds too much tedium to editors' work. — Eru·tuon20:02, 11 May 2017 (UTC)[reply]
If you mean mass conversions, sure, but I disagree that people shouldn't continue using it. If we ever want to change how we use {{desc}} in the future, we can always run a bot on entries that employ it. Also, again, I don't think the alphabetizing of entries a big deal at all. --Victar (talk) 20:30, 11 May 2017 (UTC)[reply]
Right, but it's a bit of an argument fallacy. What works one place, isn't going to work everywhere. Translation lists will always be huge, because you're comparing against all languages in the world. Descendant trees don't even come close to that. Also, because we nest descendant lists, we don't have to deal with one long list. It's simply not a good comparison. --Victar (talk) 20:50, 11 May 2017 (UTC)[reply]
I wasn't really intending it as a logical argument. A translation list has the similarity to descendant trees that I mentioned, but, as you mention, it has the difference of being much longer (when it is nearer to complete) and not being nested. The tedium of alphabetizing when only language codes are visible in the wikitext is proportional to the length of the list. The longer, the more difficult and, I suspect, the more likely editors will not want to deal with it. With an automatic tool for alphabetization, {{desc}} would be much easier to use (when handling words with a lot of descendants). — Eru·tuon21:36, 11 May 2017 (UTC)[reply]
Subdividing categories for parts of the body[edit]
Currently we have the very generic Category:Body, and Category:Anatomy which really shouldn't be used for parts of the body but more to terms used in the field of anatomy. I've been puzzling for a while about how to make these categories more specific and thus useful. My primary view on topical categories is that they should be anthropocentric and reflect everyday life, not necessarily scientific analyses. To that end, I think a primary distinction should be made between outward features of the body and inner features. This then leads to a distinction between Category:Internal organs and Category:External organs.
Not every feature on the outside (or inside) is an organ, though, such as the arms, legs, head, hair etc. A Category:Limbs couldn't possibly ever have many members, so that doesn't seem like a good idea, but I have no idea where else they might go. Perhaps a more general category for something like divisions of the body? It could then also include abdomen, head and foot. I don't know what such a category might be named.
Humans obviously have a lot of overlap with other animals, so it's hard to have a category tree that doesn't apply to other species as well. It certainly would not be desirable to have one set of categories for human anatomy only, and another set just for the parts in other animals that are not applicable to humans. A single category for all non-human body terms would probably become too unspecific to be useful. —CodeCat00:16, 10 May 2017 (UTC)[reply]
I am glad to inform you that the 25th issue of Wiktionary Actualités just came out!
As usual, it is a short page about French Wiktionary and lexicography in general. This time: a focus on a dictionary about regionalisms in French, a workpiece on rhymes and a review of a talk made about Wiktionary and ideology!
Sorry that it is not perfectly translated in English despite all our efforts. Please note that we do not received any money for this publication since the beginning! We are eager to receive feedback to know if we continue to translate it or if you imagine ways to improve it. Thank you Noé13:13, 10 May 2017 (UTC)[reply]
Policy for categorizing certain Vulgar or Late Latin terms[edit]
If a term is attested in something like the Appendix Probi, a third or fourth century Latin work listing common mistakes arising in the written Latin of the time, should it be counted as an actual attested (Late) Latin term, and hence not a reconstructed Vulgar Latin one, using the preceding asterisk (*)? Many seem to think that the terms in there were examples of Vulgar Latin, the spoken speech, creeping into Late Latin written forms as used by people who weren't educated in the use of the Classical version of the language. How, then, should these be handled? I ask because I've gotten to the descendants of Latin frigidus, which passed through a few intermediate forms before reaching the Romance forms (there's also the later learned borrowings, but that's a different story). For example, frigdus and fricdus seem to have been attested in this Appendix, and the form fridus was found on some Pompeian inscriptions, basically graffiti. Word dewd544 (talk) 20:36, 10 May 2017 (UTC)[reply]
Yep, they're attested, so you might as well refer to them when they fit the form you'd reconstruct anyway. Surprisingly enough, it seems that nobody's gone through and added all the words from the Appendix Probi to Wiktionary, but it should be done. —Μετάknowledgediscuss/deeds21:51, 10 May 2017 (UTC)[reply]
Improvements to get people to the main lemma faster[edit]
We use {{inflection of}} to point people to the lemma of which a term is an inflection, but if that lemma is itself an alternative form, then they have to click through a second time to get to the page with the actual definitions. Consider for example capitalises, which is a form of capitalise, itself an alternative spelling of capitalize. It can get worse too: Middle Dutchbeseekede is alternative spelling of the normalised spelling besekede, which in turn is an inflection of beseken, itself an alternative form lemmatised at beseiken. I'm wondering what we could do to speed this up and make it easier for people to get to the main lemma faster. —CodeCat21:13, 10 May 2017 (UTC)[reply]
We could add another parameter to say something like "verb form of capitalise (alternative form of capitalize)". DTLHS (talk) 00:23, 11 May 2017 (UTC)[reply]
Perhaps we should just add a parameter like "lemma" to display "(see x)" without additional text. That way, even beseekede could link straight to the lemma. - -sche(discuss)02:44, 11 May 2017 (UTC)[reply]
Another case: Middle Dutchvoer is an alternative spelling of voor, whose definitions are in turn at vore. There's no inflections involved this time. A case could be made that, as currently, voer should be simply be defined as an alternative form of vore directly. But this misses out on the fact that voor is in the normalised orthography for Middle Dutch whereas voer is not. There are, really, only two possible forms, vore and voor, both of which are in normalised orthography. Both in turn have further variations in spelling, such as voere for the former, and voer and voir for the latter. —CodeCat20:20, 11 May 2017 (UTC)[reply]
Yes, the issue is not uncommon, especially when something can be an inflected form of an {{altcaps}} of an {{altform}} of something. We should, however, consider the drawback that if "inflected forms of" or "alternative form of" allows also linking to a main entry and not just the nearest lemma-form, but then we decide (e.g. for reasons of commonness) that another entry should be the main entry, we have a lot of inflected forms of alt forms to forget to update and leave pointing to the wrong place. - -sche(discuss)07:18, 12 May 2017 (UTC)[reply]
What do you do when the "open" link for the translation boxes does not appear when you load a Wiktionary page? When it happened to me before I would clear the cache and it would go back to normal, but this time it's not working (on any browser). Any ideas? ---> Tooironic (talk) 04:44, 11 May 2017 (UTC)[reply]
For once I actually AGREE with Dan Polansky on something. This vote was totally unfair. It had an 8 majority vote for support, and was "failed" by an opposer. I demand some kind of explanation because Liliana sure didn't give one! PseudoSkull (talk) 12:42, 11 May 2017 (UTC)[reply]
I agree that Liliana probably shouldn't have been to the one to close it, but also agree that the vote did not pass. 8-5-3 is not a consensus as far as I am concerned. - TheDaveRoss12:53, 11 May 2017 (UTC)[reply]
You're missing the point. We pass votes with a supermajority ~70%; this only had 61% support of non-abstainers. You can always try running the vote again, and it might pass. I'd still support it. —Μετάknowledgediscuss/deeds05:50, 12 May 2017 (UTC)[reply]
Re: "We pass votes with a supermajority ~70%": Not true; many people support 2/3 and we now have multiple votes passed with less than 70%. --Dan Polansky (talk) 19:35, 12 May 2017 (UTC)[reply]
So it seems! I have become a soft, community-minded liberal in my old age I guess. I blame the 2017 election. Also, that is some impressive sleuth-work. - TheDaveRoss20:35, 12 May 2017 (UTC)[reply]
@PseudoSkull: Let me suggest that you put a late support to the vote if you in fact support its proposal. This you can do by indenting the support by :, and prefixing "support" with "late", or the like. Late support does not change the vote result, but helps informally track the evolving support/oppose situation which can serve as a motivation for a new vote. --Dan Polansky (talk) 19:38, 12 May 2017 (UTC)[reply]
Considering the previous vote is over 5 years old, I think that would be silly. Consensus can change in 5 years; it makes more sense to start a new vote than to cast a meaningless support in a long-stale vote. —Aɴɢʀ (talk) 20:33, 12 May 2017 (UTC)[reply]
I don't think it silly, and meaningless; it prevents starting a new vote or poll while it still enables some sort of tracking and collecting of input on a subject, in one convenient place. It certainly does not harm anything. --Dan Polansky (talk) 20:49, 12 May 2017 (UTC)[reply]
I once again suggest we merge Sauraseni (psu), Maharastri (pmh) and Ardhamagadhi (pka) Prakrits into one language. Most descriptive grammars ([2][3]) treat them as a whole, with several regional dialects. The differences in orthography are regular; see the incomplete User:Aryamanarora/Prakrit. After all, we treat Sanskrit as a language when it was spoken from Gandhar to Trivandrum, and even Classical Sanskrit ended up diverging into different dialects. Middle Indic is no different. —Aryamanarora(मुझसे बात करो)15:52, 11 May 2017 (UTC)[reply]
They may be grammatically homogeneous, but really the more relevant question for us should be, how homogeneous are they lexically? There are three angles that would be relevant:
plain old lexical divergence;
"orthographic divergence": even if differences are regular, if almost all words end up having different spellings, we'd have to add separate entries for all of them anyway, so merging them as a single language would not save us any work on that front. I notice your working list so far has seven word pairs with differing orthography, versus one identical pair.
attestation: how well recorded different Prakrits are, to begin with? IIUC there is quite a bit of variation.
@Tropylium: The three main Dramatic Prakrits (Sauraseni, Maharastri, [Ardha]Magadhi) are very well recorded ([4][5] Old plays and dramas, and the texts of the Jain religion), and the unusual Gandhari Prakrit is surprisingly well recorded ([6]). Lexical divergence is very little, as in the words retain their meanings, since Panini's standardized Classical Sanskrit was still in use with the Prakrits and Prakrit writers increasingly emulated Sanskrit styles of writing. The orthographic divergence is least among the three Dramatic Prakrits; really, it was a difference between, say, American and British English. They were even used in the same text together; certain characters would use certain Prakrits to reflect their socioeconomic status. ([7] source). It is harder to make a case for Gandhari and Elu Prakrit (the other two attested Prakrits) to be merged as well because they diverged significantly due to their geographic isolation. Gandhari even used the Kharoshthi script and borrowed Greek vocabulary from the Indo-Greeks of Alexander. —Aryamanarora(मुझसे बात करो)14:31, 12 May 2017 (UTC)[reply]
If a merger were to go forward (which I am opposed to), I would definitely say that Gandhari and Elu be separate due to their having many many more differences than the Dramatic Prakrits. DerekWinters (talk) 18:33, 12 May 2017 (UTC)[reply]
Delete or rename all Vulgar Latin reconstruction pages[edit]
Right now, we have a bunch of Latin reconstructions that are duplicates of actually attested terms. I am opposed to treating these as different terms from their attested Latin ancestors. The descendants should be placed on the attested Latin entry, not on a separate reconstruction page. For example, *cinque is exactly the same term as quinque; the former is merely an unattested form of the latter. Why would the descendants then be placed at this unattested form instead of a form that actually is attested? It's not our practice to place descendants on alternative forms anyway. Either these entries should all be merged into their attested counterparts, or an entirely separate reconstructed language should be created for them. My preference is towards the former, because Vulgar Latin/Proto-Romance is not sufficiently different from regular Latin to warrant a separate language. —CodeCat19:47, 11 May 2017 (UTC)[reply]
I agree that reconstructions of alternate forms should not be created, and examples like *cinque be deleted/merged, but we have a good number of reconstructed Latin terms that probably cannot be treated in this way, e.g. *baccinum or *matrastra: derivatives that have not been attested and which it would be counterproductive to merge with their root words. --Tropylium (talk) 11:44, 13 May 2017 (UTC)[reply]
I agree that reconstructed terms that are completely unattested are ok, but I do think they should be treated like any other Latin term in terms of inflection. —CodeCat12:15, 13 May 2017 (UTC)[reply]
Is this the right place to ask whether the second picture in the jam article violates any relevant Wiktionary policy? If it doesn't, i suggest we at least change the confusing caption A "London Traffic Jam" strawberry jam and peanut butter sandwich to A sandwich with strawberry jam and peanut butter. --Espoo (talk) 22:07, 11 May 2017 (UTC)[reply]
I imagine someone thought it was clever because it worked in two senses (or wordplay based on two senses) of jam, but I think it'd be better to have a jar of nonspecific jam, and separately a picture of a traffic jam. - -sche(discuss)14:48, 12 May 2017 (UTC)[reply]
This idea met with a lot of support, but it may turn out that we liked the old way better. Never fear, we can regard this as a testing period, and change it back later if there's consensus to do so. —Μετάknowledgediscuss/deeds19:12, 12 May 2017 (UTC)[reply]
Someone should update aWa to work on the new subpages, and probably just on all subpages of any of the request pages (I think there are some unresolved-request subpages of RFC or RFM it also doesn't work on). - -sche(discuss)19:20, 12 May 2017 (UTC)[reply]
It could have been split by creating just one new page. I already stated that that was my preference. I don't see a particular agreement for the contrary. —CodeCat19:25, 12 May 2017 (UTC)[reply]
Metaknowledge and Wikitiki89 supported doing it with two new pages, whereas you supported making one page the default. No one else expressed a preference as far as I can tell. For what it's worth, I prefer doing it with two new pages. —Granger (talk·contribs) 19:30, 12 May 2017 (UTC)[reply]
I like having the two separate pages, because it would be confusing figuring out which page to go to, if the topic (English or Non-English) were not included in the title. — Eru·tuon05:30, 13 May 2017 (UTC)[reply]
Poll: putting "nyms" directly under definition lines[edit]
CodeCat has been using templates like {{hypo}} to put various nyms directly under definition lines, as at maths. I support placing them there, but I'm not a fan of the clutter they are likely to create in entries with a lot of different nyms. I quite like Simple English Wiktionary's solution, which is to collapse them in the same way as quotations (see simple). I'd like to see whether there's some consensus for this, as well as finding out whether people support this alternate placement of nyms.
Unfortunately, I have no idea how to write whatever code is required to make the nyms collapsable, but I would greatly appreciate if someone else was willing to do it. I'm kind of hoping that either someone will be willing to alter the nym templates so they collapse the nyms, or that CodeCat will leave nyms formatted the standard way if people are opposed to having them directly under individual definitions.... Andrew Sheedy (talk) 00:09, 13 May 2017 (UTC)[reply]
I am supportive of this effort, but I would like to broaden it. I think it would be good if we reviewed the layout as a whole and came up with a new design which had a coherent user experience. This suggestion is a great first step, but our treatment of nyms should be aesthetically and functionally related to our treatment of everything else in the design. - [The]DaveRoss12:28, 16 May 2017 (UTC)[reply]
Support I recognize that for editors, putting nyms directly under senses offers both benefits (maybe it helps when re-ordering senses?) and drawbacks (it makes the edit window more cluttered when revising senses). For readers it's probably helpful, especially for terms with many senses. It would also avoid the perennial confusion many readers have regarding the glosses that are supplied to {{sense}} before antonyms — I am assuming that, like at present in entries that use {{synonyms}}, the nyms will be givne on lines starting with "Synonyms:", "Antonyms:", etc. And if nyms are put underneath senses, I would prefer they be hidden like quotations. - -sche(discuss)21:57, 13 May 2017 (UTC)[reply]
It's not hard to use as an editor, but it's hard on the user viewing the page. If you've ever had to go back and forth to find which sense goes with which synonym, like I have on many pages, then yes, it's hard. —CodeCat19:18, 13 May 2017 (UTC)[reply]
Also, I always find {{sense}} bugging when it's used next to antonyms (I understand the logic, but it's counterintuitive nonetheless): an example. Having the antonyms directly below the relevant sense removes all confusion. --Barytonesis (talk) 00:38, 28 May 2017 (UTC)[reply]
Oppose. The priority should be making definitions easy to skim. Even a collapsible text "Synonyms" makes it harder. Furthermore, for senses with multiple -nyms sections, there would have to be multiple collapsible items, like Synonyms, Antonyms, Hyponyms. When you consider that there would be also collapsible Quotations, so many items make for cluttered user interface. --Dan Polansky (talk) 22:18, 19 May 2017 (UTC)[reply]
oppose. Even the "hiding" options take up space(s). Think of the grotesquity of having a even a single line for each of synonyms, coordinate terms, hypernyms, and hyponyms, especially for polysemic terms. This seems like a horrible idea for English and Translingual at least, where polysemy and multiple semantic relations, respectively, abound. Allowing variation means that users shifting from L2s/tabs that take one approach to this to those that take another will have their comprehension slowed. DCDuring (talk) 10:56, 28 June 2017 (UTC)[reply]
Abstain I have voted for enough good-sounding things that turned out to be awful (hi COALMINE!) not to want to support unconditionally, but I don't know that I want them hidden either. I support having nyms under their individual senses but I don't think either of the support-options gives enough flexibility about how. Equinox◑03:27, 13 May 2017 (UTC)[reply]
"Unconditionally" may not be the best word, since I didn't quite mean it to be a "no matter what" kind of option, just a way of saying that it didn't matter if the nyms were hidden or not. I think I'll change the wording, since not many people have weighed in yet. Feel free to add another option if you wish. Andrew Sheedy (talk) 05:15, 13 May 2017 (UTC)[reply]
I think this is about hiding the nyms next to definitions, not the Synonyms, Antonyms, or other -nyms sections below the definitions. — Eru·tuon04:04, 13 May 2017 (UTC)[reply]
Because if they're under senses, they add extra information between definitions, making it harder to skim an entry for a sense you're looking for, as well as just adding clutter. Hiding the nyms keeps them tucked out of the way until you actually want to look at them (and if there were eventually entries with synonyms, antonyms, hyponyms, and hypernyms all in different lines under a single definition, it would likely look pretty messy). Andrew Sheedy (talk) 06:05, 13 May 2017 (UTC)[reply]
Oppose. That would be inconsistent. Either show them all, or hide them all. Do, or don't do, something with them all. Besides, what takes up more than one line often varies by screen size. --Daniel Carrero (talk) 00:06, 13 May 2017 (UTC)[reply]
And behaving differently in different circumstances often makes sense. Perhaps an e-mail client shows two separate panels (folders and messages) if the screen/window is big enough, but collapses it all into one space if the screen is very small, like a phone. Such decisions are common. Equinox◑00:42, 13 May 2017 (UTC)[reply]
It still looks like a bad idea to me. If sense #1 has many synonyms and sense #2 has few synonyms, then only the synonyms of #2 are shown, so at first glance it would look like #1 had no synonyms at all.
I would support doing this: show at most X synonyms for all senses, but if there are more than X synonyms, display a "show more" button. Like this:
Well, ya might be right, or not :) How do I arm-twist someone into making a demo page so we can decide without so much hypothesising? Equinox◑05:04, 13 May 2017 (UTC)[reply]
Just to note, I voted support because I believed this would be implemented by hiding every line but the first if the list became too long. That was the idea originally posted in the talk page discussion linked above. I'm opposed to hiding the nyms completely under any circumstance; if there are nyms, then at least some should be visible. —CodeCat21:06, 13 May 2017 (UTC)[reply]
Since the argument was made that the -nyms take up too much vertical space, this same argument can be used for usage examples as well. So I'm creating this poll to see how people feel about that. —CodeCat22:58, 12 May 2017 (UTC)[reply]
I imported the usexes from an out-of-copyright source. It is a pity to lose so much free information in a language so badly documented on the Internet. --Vahag (talk) 07:31, 14 May 2017 (UTC)[reply]
The ones that aren't SOP should be added as derived terms. The ones that are translations of one-word or idiomatic English terms should be added to the appropriate translation tables. For the ones that are SOP translations of SOP English phrases, I imagine we wouldn't usually be losing that much information. —Granger (talk·contribs) 12:34, 14 May 2017 (UTC)[reply]
Oppose. I assume ideally we should have 1 usage example per sense, maybe 2 usage examples per sense sometimes. If this is correct, maybe this doesn't take up a lot of space. Quotations absolutely need to be hidden because we can have more quotations per sense, with additional lines for title/author/year/etc information. Usage examples can appear normally, without needing to be hidden. That's my opinion. --Daniel Carrero (talk) 12:55, 13 May 2017 (UTC)[reply]
Abstain. Oddly enough, I don't really care either way about usage examples. I think it's because it's mainly links that look messy to me. — Andrew Sheedy (talk) 23:25, 12 May 2017 (UTC)[reply]
I desire to have rollbacking rights, but do not desire admin rights. The simple reason is I need something else to do around here, and rollbacking rights would be useful to me whenever I feel like looking through the RC all day and reverting vandals. I've been here for a few years now, and have a fairly decent case here, though a few people might disagree. I don't desire to rollback anything except for obvious and blatant vandalism (which seems to happen a lot around here). I've been reluctant to do the whole RC patrolling game simply because the undo process is slow sometimes, etc., you know how that is. It'd just feel good to be that person who took down some vandalism quickly and on sight. Sometimes, rollbacking is even good to revert my own edits quickly if I make some mistake and realize it directly afterwards. Will someone please give me the rollback rights? PseudoSkull (talk) 04:03, 13 May 2017 (UTC)[reply]
(In case you weren't aware, there is a rollback-ish gadget in preferences. It does not act instantaneously like the real thing though. —suzukaze (t・c) 04:27, 13 May 2017 (UTC))[reply]
@User:Metaknowledge Thanks. I don't think I'm ready to be an admin yet. I used to think I'd never want to be. I'd definitely fail an admin vote as of now, but someday it'd be nice to have the admin tools. There are a lot of people I've pissed off, including and not limited to User:Dan Polansky. I must clarify that, though it doesn't matter anyway, I do indeed feel bad for past mistakes. If I were to go back in time, I'd probably support his admin vote, because he mostly makes good contributions to the site and acts in a civil manner most of the time. I no longer hold any grudges against him, because I don't really know him, and we all get angry sometimes. Also, with the whole Danish inflection incident that was caused by me, I think that's another major turnoff to the other editors. But I feel like I'm learning as I go, and someday I see it as a possibility that I may get the admin tools. I kid with the occasional pranks like what once every 5 months(?), but I genuinely dream of this site one day becoming the most popular and useful dictionary in the world, and to know that I'm contributing to such a masterpiece is so amazing.
Anyway, anyway, I don't know about starting an admin vote yet. Would waiting 2 more years be reasonable? Or does User:Equinox or other people think I should just go ahead and give it a shot? PseudoSkull (talk) 04:58, 13 May 2017 (UTC)[reply]
Okay. Want some boring brutal honesty? Of course you do. I think people often go through an initial phase of wanting to be an admin ('cause it's like an elite club with brandy and cigars?? -- anyway it reminds me of people wanting operator status on IRC, back when anyone cared about IRC; or being a forum moderator, or whatever) and later they forget about that nonsense, and just do a ton of work, and when someone finally says "how come X has been doing all this stuff for 5 years and isn't an admin yet?" they kind of shrug, "well I'll do it anyway, but vote if you like, that's nice". Pseudoskull, you have been around a while, and okay I do disagree with some of your entries (Transformers came up recently!) but I am pretty sure I would trust you to revert vandalism etc. Frankly the fact that you just wrote a huge paragraph (yeah look who's talking), and deleted the "don't admin me" bit off your user page, suggests that you are quite keen to be an admin but trying to be all secret-like and hide it. This seems to place you in the first camp (wanting the brandy and cigars). Not judging. Just saying. P.S. I'm not allowed to hand out rollback or I'd just do it instead of writing this. Equinox◑05:10, 13 May 2017 (UTC)[reply]
@User:Equinox Well, it's true, I admit, that the title of admin itself is tempting. I did delete that bit off of my user page, because I changed my mind. I never really thought about it that much until recently. But you know, sometimes I come across a page that's obviously vandalism or has failed RFD/RFV and I'm thinking it'd be so much more useful if I could just delete it myself rather than speedying or something, if I was an admin that is. I've always considered adminship as a remote possibility, but never thought anyone would actually suggest it, which got me thinking. Then again, maybe I'm just not ready for it yet, and need more time to mature, which is what I fear. (And not that it has anything to do with this, but I write long paragraphs about a lot of things. lol)
On a different note, can someone even nominate themselves as admin? You know...if that's even allowed or if it's even my place to do that? I usually see other people nominating someone for adminship rather than them nominating themselves, but WT:ADMIN doesn't really seem to cover the steps. I imagine it is a courtesy to be nominated by someone else. PseudoSkull (talk) 05:53, 13 May 2017 (UTC)[reply]
Phrases with interchangeable pronouns (English at least for now)[edit]
I've been bothered by this for quite some time, and I think it's time we finally do something about it. We need some way on Wiktionary to show people how "oneself" is inflected in specific phrases and include entries for all of such combinations. For instance, I recently created express oneself. In my ideal scenario, we'd have entries for express myself, express yourself, express ourselves, etc.
Okay, so I'm not good with templates, but I have created a basic outline of my proposal here by changes to two example entries. See User:PseudoSkull/express oneself for example entries. The "Inflection" section will not be so primitive as in my example, with a bulleted list, but will instead be represented by some sort of template. This is where you can find most of the pronouns.
What I propose is that we list the main lemma's inflections "express oneself" separately (i.e. expresses oneself, expressing oneself, etc.), with the "Inflection" section or some similar section, like maybe "Usage notes", to link to all the common interchangings. Yes, the template will include those notes to establish that some of the forms are archaic, or some are considered nonstandard but are still somewhat common. Then, for all the links to "express myself", "express himself", etc., those will be separate entries. They will individually have definitions that tell what "form" of the "express oneself" term they are; for instance, "express myself" would be the "first person singular" form of "express oneself", according to the entry. The entry would treat the "express myself" form as a lemma in itself, though, sort of, like how French past participles are treated in their entries...sort of. Anyway, so express myself will still use Template:en-verb, to list off all of its conjugated forms (expresses myself, expressing myself, expressed myself), and those will have entries too.
MOTIVE: Now, I understand that in the past people have generally favored doing the "myself", "yourself" entries as redirects to the main entry, but if you've known me long enough, I don't believe in redirects, and am pretty big on the whole entry inclusionism thing. I believe that any term that technically is not a sum of its own parts and meets our attestation criteria should be included as an entry here. Also, the "oneself" forms are coincidentally a lot less common than the "myself" or "yourself" forms anyway.
QUESTIONS: In the case that this passes Wiktionary's legislation, I wonder if there's a way to semi-automatically create these entries, because it'd be a real pain in the butt to sit there manually creating all those myself, himself, themselves entries for thousands of phrases. I wonder if there's a bot that we could feed that could do a lot of this for us.
Also, as most non-lemma forms don't need individual attestation necessarily, well, how are we supposed to treat these "pseudo-lemmas" (i.e. express himself would be the lemma of expresses himself, but express himself is apparently an inflected form of express oneself)?
I do want to go as far as to start a vote on this, but I need some input first. How can we best implement the inclusion of myself, ourselves, yourself, etc. phrase entries? PseudoSkull (talk) 07:13, 13 May 2017 (UTC)[reply]
I don't think this is useful. This isn't lexical information but grammatical. Pronouns can be replaced by other pronouns, or by actual nouns ("talk to oneself" can also be "talk to Bob" etc.). Equinox◑21:53, 16 May 2017 (UTC)[reply]
I agree, although I don't think such pronouns can often be replaced with a wide variety of pronouns or nouns when it's a reflexive verb. You can't say "express him" or "express Bob", for example. Andrew Sheedy (talk) 22:04, 16 May 2017 (UTC)[reply]
Redirects would be much better than this suggestion. We need better entries more than we need additional entries, especially ones that add so little. DCDuring (talk) 22:02, 16 May 2017 (UTC)[reply]
It's a weird situation because it's a phrase in which both the verb is inflected and the reflexive pronoun changes its person and number to match the subject of the verb. I guess it's sort of inflection. I wouldn't object to having a table of the various grammatical combinations of verbal form and reflexive pronoun, and creating redirects, because it would help readers find the entries, but I don't know what I think about giving these things entries.
I'm not pleased with the free-form list in your sample entry. It should be structured somehow, like verb inflection tables. And it could contain a lot more forms: as of yet, it just has bare verb forms, no inflections (expresses, expressing, expressed). What is the rationale behind this? — Eru·tuon20:22, 17 May 2017 (UTC)[reply]
How should this be handled in other languages? Dutch has no impersonal possessive, the closest is impersonal "you". —CodeCat20:29, 17 May 2017 (UTC)[reply]
links from 'User contributions' section directly to user's actual post[edit]
Hi, when following a link from 'User contributions' it takes me to the top of the corresponding month's page, yet I'd like to go directly to my post. Thanks in advance. --Backinstadiums (talk) 16:59, 13 May 2017 (UTC)[reply]
@Backinstadiums: What do you mean by "month"? Are you talking about the dated revision links (with a full date on them), or about links to this or another discussion page? You can click on the arrow before the section name in the edit summary, if there is one, to go to the section header. — Eru·tuon17:04, 13 May 2017 (UTC)[reply]
@Backinstadiums: That would be nice, but there is no way to do that, at the moment. The arrow only works because there's a section heading with an id="section title" in the HTML source code. There is no id in your posts. — Eru·tuon17:16, 13 May 2017 (UTC)[reply]
There is an ugly and crude way to achieve that to some extent tho: from the contribution page we can get section name and timestamp that most certainly identify one post. The hardest part is bounding the post in HTML. In the simplest cases like we are having here it is possible to do that. I will try to make a small proof of concept script. --Dixtosa (talk) 18:05, 13 May 2017 (UTC)[reply]
@Dixtosa: I imported those scripts, but I'm not seeing anything. I go to a diff page for a discussion page comment, and the comment isn't highlighted. Not sure how to go to the comment either. — Eru·tuon16:47, 14 May 2017 (UTC)[reply]
1. It only works if you click the page title not the diff button. 2. It does not scroll to the post, but only highlights it (in the lamest color possible - lime). 3. some edits like this one have one minute difference between the edit timestamp and the signature time. On those edits it won't work (yet). --Dixtosa (talk) 18:58, 14 May 2017 (UTC)[reply]
@Dixtosa: Huh. I realized I wasn't clicking from the right page (it is meant for User contributions), but still I'm not seeing any highlighting when clicking on page titles for contributions that have added a timestamp. (I also checked to see that the revision date was the same as the timestamp in the signature: it was.) — Eru·tuon19:04, 14 May 2017 (UTC)[reply]
I wonder if some browser or operating system difference is causing it not to work on my machine. I'm using Chrome on Windows 10. — Eru·tuon19:10, 14 May 2017 (UTC)[reply]
1. Do you have your actual time zone set correctly in preferences? 2. Could you see if there are any js errors in your browser's console?--Dixtosa (talk) 19:57, 14 May 2017 (UTC)[reply]
1. Yes, my timezone is set. 2. I checked the console, and there were no errors, aside from some deprecated stuff in other scripts. But then I looked for your scripts in the list of "sources", and couldn't find them. So I must not have managed to load them correctly. Huh. — Eru·tuon20:05, 14 May 2017 (UTC)[reply]
Oops, they are shown in the HTML source code. Not sure why they don't show up in the list of "sources". — Eru·tuon20:08, 14 May 2017 (UTC)[reply]
Strangely not. That is my current date format. I turned off the "change dates to be relative to local time" gadget when I enabled your scripts. — Eru·tuon20:37, 14 May 2017 (UTC)[reply]
The script send a popup error now, saying the timestamp was not found. It has weirdly transformed the hour and minute for this edit, from 22:07 to 05:7. — Eru·tuon22:23, 14 May 2017 (UTC)[reply]
Yay!!! It works now!!! Awesome! Okay, the minute was not all that bizarre. But I don't know what happened with the hour. — Eru·tuon23:11, 14 May 2017 (UTC)[reply]
Hmm, okay. It doesn't really work to do that from the watchlist, since (in my display) there are multiple posts on the same page grouped together. — Eru·tuon19:30, 15 May 2017 (UTC)[reply]
@Dixtosa: Would it be possible to make this work for dated revision links from page histories? Also, can you make it so the CSS applied to the post can be customized? — Eru·tuon19:30, 15 May 2017 (UTC)[reply]
First of all, please use this script. My sandbox.js is for sandboxing purposes. Yes history pages could also have this implemented. The highlighted post is wrapped in div with the id equal to "SkipToPostJs-highlighted-post". Bear in mind you'd have to add " !important" to your styles.--Giorgi Eufshi (talk) 06:15, 16 May 2017 (UTC)[reply]
It does work but has a lot of assumptions: You should be using this format for dates: "20:16, 14 May 2017" and you should have your timezone set correctly. Dixtosa (talk) 07:52, 28 May 2017 (UTC)[reply]
@Backinstadiums, I have updated the script to handle all of the date formats. As for timezone see if it is correct here. P.S. It does not work for the posts that have more than 1 minute difference between
the signature time and the official timestamp for the edit and obviously it can not highlight modifications to a post. --Dixtosa (talk) 13:16, 28 May 2017 (UTC)[reply]
Perhaps such a distinction had meaning early in Wiktionary's history, but at this point I think we could survive with just one class for "draft policies". - -sche(discuss)01:09, 14 May 2017 (UTC)[reply]
Proposal: remove "; usually, the English translation is given, instead of a definition" from WT:EL - Translations[edit]
Proposal:
Remove "; usually, the English translation is given, instead of a definition" from WT:EL#Translations.
Current text:
"Translations should be given in English entries, and also in Translingual entries for taxonomic names. Entries for languages other than English and Translingual should not have Translations sections; usually, the English translation is given, instead of a definition. Any translation between two foreign languages is best handled on the Wiktionaries in those languages."
End result:
"Translations should be given in English entries, and also in Translingual entries for taxonomic names. Entries for languages other than English and Translingual should not have Translations sections. Any translation between two foreign languages is best handled on the Wiktionaries in those languages."
Procedural note:
This is a minor edit. It is not intended to change any regulations.
Rationale:
The text to be removed is at WT:EL#Translations, but it does not concern the "Translations" section. It concerns definitions/senses, which are the subject of WT:EL#Definitions.
Not every foreign language word has an English translation.
That rule about definitions/senses does not seem to cover non-gloss definitions, not to mention form-of entries.
This title is inaccurate. The great majority of these requests for attention are not in Proto-Indo-European entries. I suspect they have been placed in Etymology sections containing a PIE term, since I just placed one in bison. Perhaps the category name should be Requests for attention to Proto-Indo-European terms, though that sounds a little stilted. (The catfix should probably be removed too.) — Eru·tuon18:56, 14 May 2017 (UTC)[reply]
I don't really like that title either. It's hard to come up with a good name because the template is so general that we don't really know what it's being used for. — Eru·tuon21:18, 18 May 2017 (UTC)[reply]
I'm not a huge fan of that. All the other requests categories are nice descriptive phrases, so I was hoping the attention categories could be too. --Daniel Carrero (talk) 19:55, 19 May 2017 (UTC)[reply]
Replacement heading for External links in taxonomic name entries[edit]
I missed the vote and today was notified that "External link' is to be phased out.
"Further reading" does not well characterize the links to external databases, few of which contain much running text, which to me is what is conveyed by "Further reading". What are under the External links heading are links to databases, containing entries most commonly structured in ways not unlike our own in gross terms. Sometimes there are images as well. The databases often reflect hypernyms and hyponyms differing from or supplementing what we show. In accordance with a 2011 vote these links were to appear under "External links" instead of "See also".
I would like some thoughts about which of the remaining legal headings is satisfactory: "See also", "References", other, no heading at all. DCDuring (talk) 23:51, 14 May 2017 (UTC)[reply]
References is for, well, references in the entry. Like the <references /> tag. "See also" is for other entries within the same language that may be relevant to the user, not for links to other languages, and definitely not links outside Wiktionary. —CodeCat00:07, 15 May 2017 (UTC)[reply]
To summarize Dan C.'s argument: Because some of these links SOMETIMES have text, all entries using those databases as well as the numerous databases that have no such text, eg WikiCommons, MycoBank, ITIS, NCBI, should have "Further reading" headings. Seems like flawed reasoning to me. Not to mention the lack of a fact base. DCDuring (talk) 00:31, 15 May 2017 (UTC)[reply]
Your summary of my argument is wrong. In the discussion that Erutuon linked, I never said anything to this effect: "Because some of these links SOMETIMES have text, all entries using those databases as well as the numerous databases that have no such text, eg WikiCommons, MycoBank, ITIS, NCBI, should have 'Further reading' headings."
I just said that EOL, specifically does fit in a "Further reading" section. I even asked him: "If there are any other examples of websites without much readable text, I'd be happy to discuss about them."
I agree that Wikimedia Commons does NOT fit in a "Further reading" section. If the purpose is linking to a large list of images at Commons, maybe we should use the "Gallery" section that a few entries have. For example, ดังโงะ has a "Gallery" section with 4 images. It could have a link saying "For more images, see Commons." An empty "Gallery" section could have a link saying "For images, see Commons." (without the word "more") --Daniel Carrero (talk) 09:25, 15 May 2017 (UTC)[reply]
AFAICT four different headings could be required for many taxonomic entries and three for English entries for corresponding vernacular names. Any single heading of those available would be a procrustean bed for the common range of items that have appeared under "External links".
The vote evidently had an opinion base, not a fact base, as if it were some kind of adversarial proceeding, in which the only relevant facts are those brought to the discussion by adversaries. And if parties with some particular knowledge were not present, so much the worse for any situations they were familiar with.
"Further Readings" fits EOL (which SOMETIMES has running text, almost always taken from WP), Tree of Life, the Angiosperm Phylogeny site.
"Gallery" fits Wikicommons, but nothing else.
"References" fits most other external sites (but not WP, Wikispecies and Commons, which, as with all wikis AFAICT, we don't treat as valid, authoritative references).
This latter point should have come up, even without my participation in the discussion, as it relates to the use of the heading for any entry that puts the links to other MW projects under a heading.
The upshot is that virtually all taxonomic entries would need to have three headings: "Further readings" for WP, etc, "Gallery" for Wikicommons, and "References" for everything else. Wikispecies doesn't fit under any of the three headings, so perhaps we could draft "See also" into the mix. DCDuring (talk) 02:29, 16 May 2017 (UTC)[reply]
"Additional resources" might capture all of those. I think the sister project links should be done with the float boxes like Wikipedia, which would eliminate them from consideration here. - [The]DaveRoss12:46, 16 May 2017 (UTC)[reply]
Many have objected to the floating boxes. They are noxious for pages that have images or a right-hand table of contents, especially on long pages, such as those with multiple Etymology section or multiple languages. I place the sister project links next to the other "external links" for the convenience of contributors (often needed to finish the entry) and other users in selecting sources for additional information. DCDuring (talk) 15:14, 16 May 2017 (UTC)[reply]
When I see "Additional" in a bibliographic section of a book or article, it is usually for some kind of list that supplements a primary list. For example, it might include certain kinds of online resources whereas the bibliography is limited to books and article. I suppose we could try a vacuous header like "Sources" (of what? for the entry as it is or for its improvment?) or "Resources" sounds too inclusive to me. Would it include seeds, taxidermy supplies, books or online courses on taxonomy? DCDuring (talk) 15:29, 16 May 2017 (UTC)[reply]
Additional to Wiktionary. And what is permitted is up to us, if nothing fits the bill we can do something different. I also understand the objections with the boxes, it might be nice to merge them into a single box which can include links to all projects. We should also figure out a consistent ordering of images, project links and tables of contents. All of that could benefit from an overall design policy. - [The]DaveRoss15:37, 16 May 2017 (UTC)[reply]
In the meantime someone did the service of inserting "Further readings" into 6,222 Translingual entries. In virtually every case the heading is misleading for the reasons discussed.
Are we capable of having a good consensus universal design policy? Do we really need one? Given our inability to make a good consensus decision on the simple matter of a single heading, is it really best that we double down and go for something vastly more comprehensive? DCDuring (talk) 12:41, 18 May 2017 (UTC)[reply]
That is a mischaracterization, there was a consensus reached regarding this issue. You opposed it after the fact, but that is not an indictment of the process. I think we are able to make consensus decisions, and very often do. I also think we would benefit from having coherent design policy. Coming to a common understanding about what to collapse and where to place things on the page are both valuable. For instance, I think that we should do our best to ensure that the most relevant information is the most readily accessible information, e.g. you shouldn't have to scroll to get to definitions. I don't know if everyone agrees with that, but it is a discussion worth having. - [The]DaveRoss12:51, 18 May 2017 (UTC)[reply]
That the consensus should have been on a heading ("Further reading") that was unsuited to the nature of most the material included under "External links", eg, Wikicommons, Wikispecies, a dictionary portal, and other dictionaries, makes manifest that the process is insufficient. "Further" to what? I'd be shocked if anyone could produce evidence that (normal) dictionary users view their use of a dictionary as "reading". In fact "reading" is such an exceptional thing for dictionary use that the word was used to mark the distinctiveness of Reading the OED: One Man, One Year, 21,730 PagesAmmon Shea. The unsuitability of "reading" to characterize the items actually included has already been discussed above, with apologies for but not a successful defense of the consensus.
The consensus decision seems simply wrong. Its wrongness should be humbling. My vote wouldn't have changed the outcome, but no one sought my input either, nor did anyone analyze the nature of the material included under External links. The fact-free, but opinion- and anecdote-laden, nature of the discussion suggests that we can reach consensus, but that the thought processes are defective. IMO the defects of the process are probably attributable to the limited commitment of most contributors (including me) to matters outside their direct interests. Even when someone ventures into the larger matters, it is difficult for them to do all the fact-gathering that would be necessary to do a good job by, eg, not trampling on areas that have special requirements. The 6,222 instances of "External links" in Translingual (that have been "corrected" to "Further Readings") were made pursuant to an [Wiktionary:Votes/2011-07/External links earlier vote] declaring WP (presumably all languages), Commons, and Wikispecies to be "External links". That vote was also a consensus. Was that consensus incorrect? By what standard? Why should I expect this consensus to be any less changeable? DCDuring (talk) 00:32, 19 May 2017 (UTC)[reply]
Things change over time, this should not be surprising. Nor should it be surprising that, from time to time, the community reaches decisions with which you find fault. Both of these are expected outcomes of collaborative/wiki projects. Is "Further reading" the most precise heading for all types of information which are included under it? Probably not. Is it equally as imprecise as "External links" is in some cases? Probably so. - [The]DaveRoss00:53, 19 May 2017 (UTC)[reply]
I suppose that the best header for the items included formerly under External links is "References", not "Further reading." The important content for Wiktionary is the correspondence or lack thereof to the semantic relations and definitions included in the entry. The "reading" content is mostly incidental. Even if it were not, I can't see any good from having both "References" and "Further reading" in our already heading-heavy entries. I wish that footnoted references did not appear in a way so distinct from other references. I am sure that our technical mavens will resolve this sometime in this millennium, possibly even this decade.
The IP user 96.48.0.14 has been creating letter entries, among other things. Lately they have been working on A, adding a bunch of new language sections. They sometimes use the proper templates ({{head}}, {{Latn-def}}), but sometimes not. They also improperly capitalize the See also section as See Also.
I've corrected their edits, and posted on their talk page advising them to use these templates and to correct the capitalization, but they don't respond and don't seem to change their behavior. For instance, see the twelve edits they've just made today. They've used {{Latn-def}}, but created a bunch of POS sections without {{head}} and used the capitalization "See Also" consistently.
I don't want to ask for this person to be blocked as a vandal, since they're clearly trying to do useful work, but what can be done here? — Eru·tuon23:01, 15 May 2017 (UTC)[reply]
I am afraid that that is probably the best way to handle it at this point. They don't want to cooperate, and their contributions are sometimes problematic in and of themselves. —Μετάknowledgediscuss/deeds21:48, 18 May 2017 (UTC)[reply]
Hi everyone. I'm sure you've already noticed this in Tech News as it's been already mentioned twice, but I wanted to flag again that because of an upcoming change, there's some code that may need to be fixed on this wiki:
Markup that looks like code for language variants might need to be fixed. Tech News wrote about this last week. If -{ is used in transclusions or web addresses it has to be escaped appropriately. You can use -<nowiki/>{ for transclusions and %2D{ in web addresses. This is because of some code fixes to the preprocessor and affects all wikis. You can now see the full list of wikis with this problem and help fix them to avoid that things break later this month. You might find false positives. You can read more about what to fix.[8][9]
You can find the list of the pages you'll want to check in a table on mw.org. In most cases those are false positives, and you only really need to fix as explained on mw.org when the "defective" syntax is inside a template or a wikilink, basically. When you have completed the checks, please edit the Notes field of the table accordingly! If you have questions, please reach the team on the talk page. Hope this helps, and thanks for your attention and your help, --Elitre (WMF) (talk) 10:29, 16 May 2017 (UTC)[reply]
I have also mentioned this change today in an email to tech ambassadors. So far the table on mediawiki.org doesn't reflect any fixes on this wiki. I'll just add that fixes are of course possible also after the change happens, although it may be suboptimal, and that you may want to look into automated means of solving the problem (come ask how en:Wikipedia:AutoWikiBrowser was used on the big wikis, for example). Hope this helps. Elitre (WMF) (talk) 13:05, 22 May 2017 (UTC)[reply]
RevisionSlider will be available as a default feature for all users on all wikis from May 17. The RevisionSlider adds a slider view to the diff page so that you can easily move between revisions. The slider view is collapsed by default, and will load by clicking on it. It can also be turned off entirely in the user preferences. RevisionSlider has been a default feature on German, Arabic and Hebrew Wikipedia for 6 months and a beta feature on all wikis for 8 months. The feature fulfills a wish from the German Community’s Technical Wishlist. Thanks to everyone who tested RevisionSlider and gave valuable feedback to improve the feature! We hope that RevisionSlider will continue to serve you well in your work.
Using the script code for Nastaʿlīq rather than Arabic[edit]
I'm puzzled by the fact that languages that generally use Nastaliq script are coded as using variations of the Arab (Arabic), when they should use the code Aran (Nastaliq). For instance, Persian and Urdu text is marked with the classes fa-Arab and ur-Arab. Seems like this should be fa-Aran and ur-Aran. I'm not sure which other languages generally use Nastaliq, but they should use the code Aran rather than Arab too. Or was Arab used for a reason? — Eru·tuon19:57, 16 May 2017 (UTC)[reply]
Nastaʿlīq is a style not a script. Just because a script code exists, doesn't mean we should use it. If we just want to use a different font for a particular language, then script codes are not the way to do it. --WikiTiki8920:15, 16 May 2017 (UTC)[reply]
The Wikimedia movement strategy core team and working groups have completed reviewing the more than 1800 thematic statements we received from the first discussion. They have identified 5 themes that were consistent across all the conversations - each with their own set of sub-themes. These are not the final themes, just an initial working draft of the core concepts.
You are invited to join the online and offline discussions taking place on these 5 themes. This round of discussions will take place between now and June 12th. You can discuss as many as you like; we ask you to participate in the ones that are most (or least) important to you.
Here are the five themes, each has a page on Meta-Wiki with more information about the theme and how to participate in that theme's discussion:
((d)) template - entries marked for imminent deletion[edit]
Could/should we change this template to enforce a "reason" parameter? It isn't helpful when people tag pages for deletion with no reason given. Equinox◑22:52, 16 May 2017 (UTC)[reply]
I don't know that it should require a reason. It's often obvious, like if the page is a redirect left after a move, and typing {{d}} is quick. In cases where it's not obvious, I see people convert it to {{rfd}} or sometimes {{rfv}}. - -sche(discuss)23:19, 16 May 2017 (UTC)[reply]
If you're incapable of figuring out why it should be deleted, let someone else deal with it. (Or if it requires a specific skillset, like speaking Russian, ping someone who speaks Russian.) —Μετάknowledgediscuss/deeds01:47, 17 May 2017 (UTC)[reply]
As the category description says, "Proper nouns are generally not countable. This category contains those that are. They may be actually common nouns that have been miscategorized." First and last names are countable as a rule, however, so they swamp the otherwise-useful category, obscuring its other entries: a quick list check using AWB's list-comparer suggests that out of its 6,887 entries, 209 are not names, but they are needles in a haystack. I think it'd be useful to move names to a subcategory, perhaps by passing a name=1 parameter to {{en-proper noun}}. I am not sure what to call the subcategory; maybe "English countable names" or "English countable proper nouns (names)"? Or given and last names could go in different subcategories. It might also be useful to subcategorize place names. - -sche(discuss)16:52, 17 May 2017 (UTC)[reply]
To take one example: Hatfield is readily used in its plural Hatfields, as in "Let's invite the Hatfields over for dinner."/"Not the Mingo County Hatfields, I hope."/"No, just our local Hatfieds, the Harold Hatfields, Senior, Junior and Trey."/"Trey isn't a real Hatfield; he's adopted, you know."
What bothered me was the category description, the wrongness or poor wording of which seemed to me to have escaped your notice. Creating the new subcategory would be an opportunity to insert better information in the "category description". The facts seem to be that, 1., virtually any proper noun/proper name could be used in the plural, but that, 2., most usage of proper nouns is in the singular, 3., uncountable use is rare, and 4., there is not gross deviation from this pattern, excepting for certain toponyms, like Rockies/Rocky Mountains. I have come to believe that we have little justification for make assertions about the (un)countability of nouns other than perhaps to say whether it is countable or uncountable use is the more common. Even that presupposes that we have done some quantitative work to justify the assertion. DCDuring (talk) 12:22, 18 May 2017 (UTC)[reply]
If it is true that all names are countable, the categories of countable given names and countable surnames would be redundant with the existing given name and surname categories. Seems to me the simplest solution would be to put these existing name categories under countable proper nouns and remove all names from the countable proper nouns category. — Eru·tuon07:44, 18 May 2017 (UTC)[reply]
Good point about redundancy. One can find individual names where the plural is not used often enough to meet CFI (usually only if the name itself is not used often). Maybe someone would find it interesting to know which names' plurals do and don't meet our (arbitrary, in the scheme of things) criteria; we do have Category:English nouns with unattested plurals. But yes, as a rule, names pluralize. I wouldn't mind what you suggest. And/or we could just have name=1 prevent categorization into CAT:English countable proper nouns without adding any category. - -sche(discuss)08:43, 18 May 2017 (UTC)[reply]
Isn't the categorization into Category:English proper nouns sufficient? Topical subcategorization into given names, surnames, toponyms, fictional character names, company/brand names, etc seems much more potentially useful than the vacuous or misleading grammatical subcategorization by the relative prevalence of countable usage. DCDuring (talk) 12:22, 18 May 2017 (UTC)[reply]
A little proposal that I don't think will be controversial. Under the "List of headings" there's a block of code in a fixed-width font that lists possible headers. I propose adding links to each of those headers, pointing to the section on the page that describes those headers in more detail. —CodeCat17:09, 18 May 2017 (UTC)[reply]
I don't mind linking, but I don't like the fact that we have two lists of headings: the one in a fixed-width font, and the other one just below it. --Daniel Carrero (talk) 17:20, 18 May 2017 (UTC)[reply]
Vote: Simplifying CFI about constructed languages[edit]
On Wiktionary:Categorization, I changed some word and also solicited feedback on the talk page but I figured I would also post here. I have been informed that--following my intuition and the use of categories on many other projects--entries shouldn't be in a parent and its child categories simultaneously. There may be some rare exceptions but I certainly can't think of any. I changed the wording to reflect that generally you should use the most applicable and narrow category only and not put an entry in (e.g.) Category:English lemmas (edit: I knew better than that--but I'll let the example stand to show my haste and ignorance) andCategory:English nounsandCategory:English proper nouns or Category:en:CitiesandCategory:en:Cities in France, etc. Again, I don't think this is particularly controversial but I want clarification from the community because at least one other editor feels otherwise and I have solicited his feedback here. —Justin (koavf)❤T☮C☺M☯16:53, 19 May 2017 (UTC)[reply]
@Donnanz: How is this unique? This is the question that I keep on asking but you're not answering: How are counties any different than Category:Cities in the United States of America or Category:Rivers in the United States of America? On your talk, you explicitly said that, "A compromise would be to have categories for both country and states. But don't expect me to create the categories." Which I did and then populated and you undid to populate the parent category. You have been told on that talk page as well by a bureaucrat to not do this, I have confirmed that other admins said to not do this, and you've gone behind my back and undone my edits to re-populate the main category. I didn't want to make this a discussing about the two of us bickering but you're really forcing my hand here: please tell me why you think American counties are somehow distinct from all of the other topical categories. If you can't answer this question, then you will have to stop editing like this. I've tried to meet you half-way here by doing the work of making the 50 subcats and populating them from hundreds of edits. I've also additionally made Appendix:Counties of the United States of America so you can have a list of that really matters to you that much. Your editing makes no sense to me here. —Justin (koavf)❤T☮C☺M☯17:47, 19 May 2017 (UTC)[reply]
@Donnanz: Your reason for categorizing them all together was that you wanted to see a list of all of them at once. So I started one. You're still not answering the fundamental question and you've been told numerous times that this is not how the topical categories function. —Justin (koavf)❤T☮C☺M☯18:06, 19 May 2017 (UTC)[reply]
@Donnanz: So, you want county names to be in the "counties of the US" category and the "counties of a given state" category? Or am I misunderstanding? — Eru·tuon18:18, 19 May 2017 (UTC)[reply]
@Donnanz: No, Chuck Entz on your talk and Angr above have both said the same thing. See also, e.g. User:DTLHSwriting on my talk. All of them are admins or bureaucrats. Also, in practice, do you know of any other topical categories where entries are in both child and parent categories? Since you're refusing to give any examples or explain why this one is unique, what do you expect to happen? I tried to help you here by making the appendix--I don't know what more you want. —Justin (koavf)❤T☮C☺M☯18:20, 19 May 2017 (UTC)[reply]
My reasons for wanting entries to be only in leaf categories are purely practical. If we put into common use a template for topical categorization (such as {{C}}), we could easily make it automatically categorize up the category tree to a certain point (so that for example entries in Category:Crickets and grasshoppers are also in Category:Insects). Until we have this capability I believe categorizing only in the most specific category is reasonable. DTLHS (talk) 18:49, 19 May 2017 (UTC)[reply]
@Donnanz: Why would you think I would prefer that? Also, entries are supposed to be categorized. Can you please address the several questions directed to you above? —Justin (koavf)❤T☮C☺M☯18:40, 19 May 2017 (UTC)[reply]
So if you would rather see entries categorised, surely they can be categorised as the user sees fit, right? What you are doing in deleting the master category is satisfying your own view on the matter, which is flawed. DonnanZ (talk) 18:55, 19 May 2017 (UTC)[reply]
@Donnanz: "surely they can be categorised as the user sees fit, right?" No, since categories have to be exclusive: we can't have every conceivable scheme at one time. We can generate database reports or use bots that can create infinite trivial categories ("All towns in India with a 'x' in the name" or "All rivers which are also words in Estonian", etc.) "which is flawed" How is it flawed? No one else seems to think it's flawed and you are not explaining why is this category scheme unique? It's less than useless for you to even write this. You refuse to answer any direct and simple questions for yourself and are acting petulant. Why are you doing this? —Justin (koavf)❤T☮C☺M☯19:01, 19 May 2017 (UTC)[reply]
Then I will have no choice but not categorise entries, as you are still reverting my edits. That way my time isn't wasted. DonnanZ (talk) 19:05, 19 May 2017 (UTC)[reply]
Another solution: add only the "county in a given state" category. The "counties in the US" category can easily be added after that, if it is resolved it should be added, I would think. — Eru·tuon19:14, 19 May 2017 (UTC)[reply]
Umm. Okay, I will add my voice to begin constructing the requested consensus. I agree that entries should not be put in both the parent and child topic category. There are other ways to generate the list of US county names that you desire. — Eru·tuon18:46, 19 May 2017 (UTC)[reply]
@Donnanz: It's not me: it's the entire community and common sense and the usage of categories elsewhere. You know that what you are doing is inappropriate so I'm not going to continue playing this game with you. You're acting childish, so please just quit it. Make the entries with the categories by state and not the parent category but don't actually remove just Indiana as a state category: what could possibly be the reason for that? You're not answering any of these questions, you're not making sense, you're contradicting the community's wishes, and you're just being bullish. Grow up. —Justin (koavf)❤T☮C☺M☯19:46, 19 May 2017 (UTC)[reply]
@Donnanz: Come on. You're being childish in the above-linked diffs where you remove all "county in a given state" categories, or just one. It looks like retaliation for @Koavf's edits that you find to be overly controlling. But I agree @Koavf is being controlling. It would be best if both of you would refrain from removing any categories until this discussion has finished. Removing or adding the parent category can easily be done by bot, I would imagine. — Eru·tuon19:58, 19 May 2017 (UTC)[reply]
I removed one or two categories to prove a point, but I strongly object to the master category being removed before this discussion is resolved. That is childish, I'm throwing that comment back. DonnanZ (talk) 20:12, 19 May 2017 (UTC)[reply]
Childish or not, I don't normally indulge in edit warring, which is senseless and fruitless. I leave that to other users like Koavf. DonnanZ (talk) 21:31, 19 May 2017 (UTC)[reply]
@Donnanz: Honestly, man just get over it. Please just answer the above questions and maybe someone can agree with your proposal. As it stands, no one is agreeing with you and you refuse to justify your actions. —Justin (koavf)❤T☮C☺M☯21:33, 19 May 2017 (UTC)[reply]
@Erutuon: See here. Adding categories is trivially done and removing them is slightly harder. Do you suggest that this just stop for a few days altogether or should he continue making pages and then if consensus stands as it is, I remove them at that point? —Justin (koavf)❤T☮C☺M☯22:21, 19 May 2017 (UTC)[reply]
@Koavf: I would suggest that you and DonnanZ both continue adding whatever categories you would like to, and do not remove categories that the other person has added. — Adding categories is trivial? I would think removing them would be quite trivial too. @DTLHS could remove all "counties of the US" categories from entries containing a "counties in a given state" category quite easily with his bot, I would imagine. — Eru·tuon23:10, 19 May 2017 (UTC)[reply]
Actually there should be about 500 entries in the category by now, not 108, but no one can tell now. Of the 254 counties in Texas, only a fifth of them have entries, so there's a lot to be done yet, but due to Koavf's violent opposition the job may never be finished. DonnanZ (talk) 11:07, 20 May 2017 (UTC)[reply]
You have obviously forgotten that I explained my reasons on my talk page. I needn't repeat them here. I'm still going to create more entries despite the unsatisfactory situation you created all by yourself. I must be barmy. Don't bother pinging me again, it's bedtime. DonnanZ (talk) 23:14, 19 May 2017 (UTC)[reply]
@Donnanz: You did not. E.g. you said this is "unique"--how? You said that my understanding of categories is "flawed"--again, please enlighten me. You claimed on your talk that you just want a list o fall U.S. counties in one placed one for you and then you didn't like it. I have no problem giving 48/72 hours for more feedback but I'd be very surprised if anyone else thought that it was a good idea to use categories the way you suggest and several others have said that we shouldn't. —Justin (koavf)❤T☮C☺M☯23:18, 19 May 2017 (UTC)[reply]
That's a difficult question. I feel it is different from other categories, especially when some county names are shared by several states e.g. Washington County in 30 out of 48 states (and 1 parish), on the other hand many names occur in only one state. But I feel that a master category is useful for users, although city names can also be shared by more than one state too, maybe not to the same extent. You will also find that categories for cities don't exist in 22 out of 48 states, so entries for US cities can appear under a state heading as well as in Category:en:Cities and Category:en:Cities in the United States of America. Some so-called US cities are ridiculously small and some counties have very few people, but that's digressing. DonnanZ (talk) 10:10, 20 May 2017 (UTC)[reply]
In addition, Koavf didn't do the job properly when he first created the Indiana county category, and entries for other states with the same county name have been left in the state category, which was fine before, and not moved to a county category. At the moment I can't be bothered correcting them. Apathy rules. DonnanZ (talk) 13:35, 20 May 2017 (UTC)[reply]
@Donnanz: "Koavf didn't do the job properly... I can't be bothered." and "categories for cities don't exist in 22 out of 48 states". Well, Wiktionary isn't done yet. Things take time. "Entries for US cities can appear under a state heading as well as in Category:en:Cities and Category:en:Cities in the United States of America" They can but should they? The answer from everyone else is "no". The fact that there are county names shared across states is no different than cities, towns, villages, rivers, or any other geographic feature. "I feel that a master category is useful for users"--how is a category somehow better than the appendix which I started for your benefit? In what scenario would a category listing be superior? —Justin (koavf)❤T☮C☺M☯15:51, 20 May 2017 (UTC)[reply]
I am merely pointing out that there are US cities in Category:en:Cities. Am I allowed to mention that without being jumped on? And I am not going to be led on a noose to an appendix created by guess who. You must be joking, I didn't ask for the damned appendix. DonnanZ (talk) 16:20, 20 May 2017 (UTC)[reply]
@Donnanz: ...led by a noose? Honestly, you need to step back several steps and chill out. You said that you wanted a centralized listing of all of the counties and this is it. I'm asking what is the problem with the appendix? I didn't say that you explicitly asked for it, I'm asking how does this not meet what you wanted? —Justin (koavf)❤T☮C☺M☯17:09, 20 May 2017 (UTC)[reply]
The problem would not arise if too granular categories were not created. I for one would be happy if Category:en:Cities had no subcategories; we are a dictionary and not an encyclopedia and not an atlas. However, I am sure multiple people disagree with me. Maybe some more people would agree that Category:en:Cities in Kyoto (Prefecture) is too granular; I don't know. --Dan Polansky (talk) 19:34, 20 May 2017 (UTC)[reply]
I didn't think I would ever find myself agreeing with you. I would suggest standardising all such categories to "X in Y" which seems more natural to me. DonnanZ (talk) 20:52, 20 May 2017 (UTC)[reply]
@Donnanz: Are you talking to me? You would never agree with me about what...? For what it's worth, I think that "X in Y" is also more sensible as well, especially for a geographic category since a city will quite literally be in a state. —Justin (koavf)❤T☮C☺M☯21:12, 20 May 2017 (UTC)[reply]
I agree with Daniel though, Category:en:Cities is far too broad and covers the whole world. No, I'm not hoisting myself by my own petard, but suitable subcategories (and in some cases sub-subcategories} already exist for most countries. Maybe a lot of entries were categorised before subcategories were created. DonnanZ (talk) 23:52, 20 May 2017 (UTC)[reply]
@Koavf: I have made 4 trial additions to the appendix. Although it looks good, it has to be edited manually. I don't think etymology should be included as this usually appears in the main entry anyway, and makes editing unduly complex for multiple state entries such as Adams County. No tally of entries is provided, and the longer the appendix gets the more unwieldy it will be, and the more difficult it will become to insert new entries. The only way I can find into the appendix is by scrolling past all the subcategories in the parent category, the addition of the parent category to entries is a much easier and far more direct option. All I was basically looking for is the basic information that is provided in a category such as Category:en:Counties of Indiana and Category:en:Counties of the United States of America including a tally of the number of entries. I think I have given the appendix a fair trial, but I don't think it is a good substitute for replacing entries in the parent category. DonnanZ (talk) 09:17, 22 May 2017 (UTC)[reply]
@Donnanz: Well, I respect you trying it out and giving it a shot. It's unfortunate that it isn't a workable solution for you. Otherwise, category scanning tools or AWB may be a good fit for essentially generating a report of what you want to see. —Justin (koavf)❤T☮C☺M☯15:40, 22 May 2017 (UTC)[reply]
@Koavf: I think that with potentially up to 3000 entries (allowing for duplicates) in the appendix it would be unworkable, and take a helluva lot of editing. On the other hand Category:en:Counties of the United States of America manages itself, no editing is required apart from allocating the category. I notice in the intro to the appendix it is intended for former counties also, and some counties are still being renamed in the 21st century (Dade County is an example) so maybe the appendix can be kept for county names that are no longer used. Category:Traditional Scottish Counties (still incomplete) is an example of this. DonnanZ (talk) 19:54, 22 May 2017 (UTC)[reply]
@Donnanz: Appendices are definitely very flexible in what they allow, so a list of former U.S. county names would probably fly but would be redundant to an actual article at Wikipedia. (Edit:) But yes, you are correct, that generating the full list in the first place would be substantial editing. —Justin (koavf)❤T☮C☺M☯20:20, 22 May 2017 (UTC)[reply]
@Donnanz: I respect the fact that you gave the appendix namespace a good faith try and that it's not what you think meets you needs but no, we are not on the same page. I still think that parent topical categories need to be emptied into their children and the consensus above and on my talk is in favor of what I'm suggesting. There are scripts and tools which can generate the kind of lists you would like to see and so I think that's the only way you're going to be able to get a report of the kind that you would like. Thanks for talking this thru with me; I hope we can have constructive dialogue in the future but in this case, I think we have incompatible perspectives and I think that the community is on my side as it were. —Justin (koavf)❤T☮C☺M☯17:07, 24 May 2017 (UTC)[reply]
@Koavf: Actually, it's a little more complicated. @DTLHS said that the wikitext should only have the "counties in a given state" category, but the parent "counties in the US" category should also be added automatically (when the category-adding function is able to do that). So, you probably have consensus on not adding the parent category in addition to the children categories, but on having the parent category empty, there is disagreement. — Eru·tuon18:15, 24 May 2017 (UTC)[reply]
@Erutuon: Adding "Counties in Indiana" and "Counties in the USA" to the same entry is trivially easy. The point is that it's redundant and out of step with how the category structure works in general. I see that DTLHS is suggesting that this is a possibility but still I think my point remains that between solicited comments in this case, comments on similar cases, and general practice here and on other WMF wikis, there's a very broad and long-standing pattern of not putting an article in a parent and child category at the same time (without some clear reasoning and unusual circumstance). —Justin (koavf)❤T☮C☺M☯19:45, 24 May 2017 (UTC)[reply]
I don't think Koavf has the support of the whole community on this issue. When Dan Polansky states "I for one would be happy if Category:en:Cities had no subcategories" that is disagreement from a different angle, and a stance I can't support. I can see the value of entries in this case (US counties) in both parent category and subcategory. If the parent category can be added automatically that would be great, but I'm not averse to adding the parent category myself. So far I have resisted the temptation of adding both categories to brand new entries, but I won't rule it out. DonnanZ (talk) 20:33, 24 May 2017 (UTC)[reply]
In diff, text about sum of part numbers was added, apparently without a vote:
The consensus of the community is that numbers, numerals, and ordinals over 100 should not be included in the dictionary, unless the number, numeral, or ordinal in question has a separate idiomatic sense that meets the CFI.
Pursuant to "Any substantial or contested changes require a VOTE", this should be made via a vote: it is probably not contested but it is substantial in so far as it impacts policy. --Dan Polansky (talk) 08:41, 20 May 2017 (UTC)[reply]
lexicographic approach to code languages (C++, python, etc.) and mathematical logic[edit]
HI, I won't specify too much so that the gist of it can be understood. I'd like to know whether code langauges can follow the lexicographic principles applied to natural languages. I only know some basic regex, which nonetheless leads me to think it may be very similar. Similarly, mathematical logic is a formal language (a notion defined in linguistic terms in its entry. --Backinstadiums (talk) 18:37, 20 May 2017 (UTC)[reply]
Maybe it would help you to read about how programming languages are created. Usually someone will create a specification, which is a document that describes the language in a formal way. Someone will then implement the language according to this specification. Any ambiguities in this specification become undefined behavior for that language. You can compare this to the way dictionaries work, which is to describe the language as it is created by the people who use it. Some natural languages have language regulators that proscribe words that can officially enter the language, but they still don't create the vocabulary or grammar from scratch. DTLHS (talk) 20:05, 20 May 2017 (UTC)[reply]
Entries for terms in other languages should follow the standard format as closely as possible regardless of the language of the word. However, a translation into English should normally be given instead of a definition, including a gloss to indicate which meaning of the English translation is intended. Also, the translations section should be omitted.
Rationale:
This is obvious:
"Entries for terms in other languages should follow the standard format as closely as possible regardless of the language of the word."
This describes a universal rule concerning how to format definitions, but it seems to be controversial (we haven't agreed on that universal rule):
"However, a translation into English should normally be given instead of a definition, including a gloss to indicate which meaning of the English translation is intended. "
"Also, the translations section should be omitted."
Procedural note:
I don't know if this needs a vote. This is not intended to change any regulations. The text to be removed does nominally have some regulations, but they are not followed anyway per the reasons above.
I'd like to propose Sauraseni Apabhramsa and Gurjar Apabhramsa for codes. Maybe sap-inc and gup-inc, with the Apabhramsa standard being something like XXp-inc. @Aryamanarora If you have any other ones you want added, or even the Jain Prakrits. DerekWinters (talk) 02:30, 22 May 2017 (UTC)[reply]
Sounds good. @Atitarev can you add inc-sap and inc-gup. Both use Devanagari and are descendants of Sauraseni Prakrit (psu). Sauraseni Apabhramsa is the ancestor of Old Hindi (inc-ohi), and probably some more. And Gurjar Apabhramsa is the ancestor of Old Gujarati (inc-ogu) and Marwari (mwr). DerekWinters (talk) 17:45, 22 May 2017 (UTC)[reply]
Why, for example is "absolute of enfleurage" in both English 1-syllable words and English 3-syllable words, when both are obviously wrong? How many of these errors do we have? Will the error-maker be going through and fixing them? Equinox◑17:14, 22 May 2017 (UTC)[reply]
Well, I find it very obnoxious for someone to introduce a new technology (auto syllable bot) and know that it will "obviously" create errors, and allow it to do so anyway. Equinox◑17:23, 22 May 2017 (UTC)[reply]
The existing entry may be unconventionally formatted but it is not informationally wrong. Once the bot adds those categories, it is wrong. Therefore the bot is at fault. Equinox◑17:36, 22 May 2017 (UTC)[reply]
Actually, that's not a good name. It's misleading, since not all categories would be turned off. Any suggestions for a clearer parameter name? — Eru·tuon19:17, 22 May 2017 (UTC)[reply]
I personally would rather have multi-word terms categorized. (And technically, many supposed multi-word terms in English are actually single words syntactically, since they are compounds with some or all of the components separated by spaces.) However, since someone might want to find a list of all things spelled as words with a certain syllable count, perhaps there should be a category for terms with a certain syllable count and inside it a category for words with a certain syllable count. But misleadingly, the categories say word and not term, so perhaps, to be strictly correct, multi-word terms should be removed. — Eru·tuon22:43, 22 May 2017 (UTC)[reply]
I'd like to propose some changes to {{alter}}. Right now we can only add labels to the end of the alternative form lists by using a blank |4= and |5=, |6= etc., ex. {{alter|grc|παραγίνομαι||ion|post-Classical}} >> παραγίνομαι(paragínomai) — Ionic, post-Classical.
I find this confusing, non-standard, and limiting. I propose adding parameters |dN= (dialect) and |qN= (qualifier) parameters:
@Victar: So, the purpose of {{alter}} as it has been traditionally be conceived is that each instance of alter represents a separate set of alternative forms. So in Ancient Greek, you would have the Ionic forms on one line and the Doric forms on another. As such, I would be opposed to the first set of changes you have proposed. The second set could be fine. —JohnC500:42, 23 May 2017 (UTC)[reply]
@JohnC5: If people want to keep dialects on separate lines, they'd be still able to do so. The only change they would be using actually parameters over the unusual and confusing blank |4= system. When they're scraped and parsed by {{desc}} and {{desctree}}, they'll be placed in a single line though. --Victar (talk) 01:07, 23 May 2017 (UTC)[reply]
@Victar: So, you are saying that, yes, you want to remove the old parameter format, in which a blank parameter separates the terms from the labels? — Eru·tuon19:59, 28 May 2017 (UTC)[reply]
@Victar: Okay. Well, actually, your first post here said something about adding parameters, not about what to do with the old parameters, so I was unsure. But now it is clear. — Eru·tuon21:01, 28 May 2017 (UTC)[reply]
I think there must be a way to supply labels that apply to all the forms. There cannot just be numbered labels that apply to the numbered forms. It seems you are proposing the parameters |d= and |q= (with no number after them) for this purpose, and also that the labels be separated by commas in this parameter: |d=Doric, Boeotian. That will only work if there are no labels that contain commas. Then, for instance, what is currently coded as {{alter|grc|ᾱ̔μός|ᾱ̓μός||epi|dor|tra}}, from the entry ἡμέτερος(hēméteros), would be coded as {{alter|grc|ᾱ̔μός|ᾱ̓μός|d=epi, dor, tra}}. Is that correct? — Eru·tuon20:11, 28 May 2017 (UTC)[reply]
@Erutuon: Yes, as I exampled above, it would be as {{alter|grc|ᾱ̔μός|ᾱ̓μός|d=epi,dor,tra|q1=archaic}} for multiple parameters for ᾱ̔μός(hāmós)(archaic), ᾱ̔μός(hāmós)(Homeric Greek, Doric, Tragic), or perhaps Homeric Greek, Doric, Tragic: ᾱ̔μός(hāmós)(archaic), ᾱ̔μός(hāmós) if people use |d= as opposed to |dN=, keeping them on separate lines. --Victar (talk) 20:52, 28 May 2017 (UTC)[reply]
@Victar: Okay. Well, it's quite different to have individual labels in the same parameter separated by commas. That's not currently done in any labeling templates. But I don't know what I think about it yet. It would help if more people would comment. — Eru·tuon21:05, 28 May 2017 (UTC)[reply]
Isn't what what it used to be, with the previous |dial= parameter? I'd say it's even more unconventional using a blank |4= and |5=, |6=. --Victar (talk) 22:10, 28 May 2017 (UTC)[reply]
No, I think |dial= was just an alternative to |dial1= when there was only one dialect, and could only contain one label, not a list of labels separated by commas. — Eru·tuon22:31, 28 May 2017 (UTC)[reply]
Funds Dissemination Committee
The Funds Dissemination Committee (FDC) makes recommendations about how to allocate Wikimedia movement funds to eligible entities. There are five positions being filled. More information about this role can be found at the FDC elections page.
Funds Dissemination Committee Ombudsperson
The Funds Dissemination Committee Ombudsperson receives complaints and feedback about the FDC process, investigates complaints at the request of the Board of Trustees, and summarizes the investigations and feedback for the Board of Trustees on an annual basis. One position is being filled. More information about this role can be found at the FDC Ombudsperson elections page.
We will also be accepting questions to ask the candidates until May 28. You can submit your questions on Meta-Wiki. Once the questions submission period has ended on May 28, the Elections Committee will then collate the questions for the candidates to respond to.
The goal of this process is to fill the five community-selected seats on the Wikimedia Foundation Funds Dissemination Committee and the community-selected ombudsperson. The election results will be used by the Board itself to make the appointments.
The full schedule for the FDC elections is as follows. All dates are inclusive, that is, from the beginning of the first day (UTC) to the end of the last.
May 15 (00:00 UTC) – May 28 (23:59 UTC) – Nominations
May 15 – May 28 – Candidates questions submission period
May 29 – June 2 – Candidates answer questions
June 3 – June 11 – Voting period
June 12–14 – Vote checking
June 15 – Goal date for announcing election results
Please feel free to post a note about the election on your project's village pump. Any questions related to the election can be posted on the talk page on Meta-Wiki, or sent to the election committee's mailing list, board-electionswikimedia.org.
Alternative spellings for all parts of speech[edit]
Currently there's the entry eenich. Its format isn't exactly ideal; it's just repeating the same thing three times, just for three different parts of speech. It would be useful if this could be said just once, that eenich is an alternative spelling of ênich for all and any part of speech. For Chinese, we have entries like 妈(mā), which contain no POS information and just point to the traditional spelling. What's going on here is similar, ênich is a normalised spelling (following WT:ADUM) while eenich is an unnormalised spelling found in manuscripts. —CodeCat19:40, 24 May 2017 (UTC)[reply]
One problem with saying that something applies to "all" of something else is that it isn't future-proof, because the set of all things can grow. Maybe a new PoS will appear some day (not for Middle Dutch, admittedly) and won't take the alt spelling. Equinox◑19:51, 24 May 2017 (UTC)[reply]
It's as future-proof as the Chinese entries are. It will only ever change if Wiktionary changes its rules, whether to have Chinese entries at their simplified spelling, or to normalise Middle Dutch in any other way. With the rules as they are now, 妈(mā) will always be an alternative spelling of 媽／妈(mā), and eenich will always be an alternative spelling of enich. There are other old languages that use normalised spellings; Old Norse is a notable example. They could also benefit from a solution. —CodeCat19:56, 24 May 2017 (UTC)[reply]
Disable usexes and quotes for reconstructions[edit]
Our usual French IP vandal has been adding usage examples for Proto-Germanic terms on occasion. I don't think this is desirable. Can Module:usex be edited so that it throws an error whenever it's used in the Reconstruction: namespace? —CodeCat14:01, 25 May 2017 (UTC)[reply]
@CodeCat: Sounds like a good idea. I've added an error that shows up in two cases: if the language is reconstructed, and if the namespace is Reconstruction. — Eru·tuon18:33, 25 May 2017 (UTC)[reply]
As WF points out, the vote has ended and we will now begin removing the admin role from folks who have not used admin tools within the past five years.
Here is a list of the current admins who fall into that category:
An interesting case, Paul G has not used tools in five years, but he is also a 'crat. The vote was specific to admins, we ought to have another vote for 'crat and checkuser rights as well.
Paul G has been active on Facebook within the last few weeks. Somebody might like to ask him. (He is the Paul Giaccone with a beard) SemperBlotto (talk) 05:11, 26 May 2017 (UTC)[reply]
I don't see a need to seek him out on social media. If he wanted to retain his rights, he'd notice all the pings and the message on his talk-page for a start. —Μετάknowledgediscuss/deeds05:19, 26 May 2017 (UTC)[reply]
I don't think it is necessary, but I also think it would be nice to reach out to him, perhaps we will regain a good contributor in the process. - [The]DaveRoss12:11, 26 May 2017 (UTC)[reply]
rfv, rfd and rfc -- language categories populated[edit]
I added the language code where needed in all instances of {{rfv}}, {{rfd}} and {{rfc}} in entries, reconstruction and citation pages. I also made the langcode mandatory in these namespaces, or else the page will display a module error (but the langcode is not mandatory when you add one of these requests in a template, category, or appendix).
Now, you can use the 1st parameter instead of "lang=" in all these templates. In other words, you can type: {{rfv|en|write reason here}}. (You can still use "lang=" and type {{rfv|lang=en|write reason here}} but this is obviously longer. I removed the "lang=" from the rfv/rfd/rfc in all pages to discourage using that parameter.)
Feel free to discuss or propose changes to that system.
Reply to @-sche: Yes, but the requests categories are split by language. Now, I'm OK with discussing as to whether these categories are helpful (I think they are!), but I didn't add the langcodes just for the benefit of linking to the discussion pages. --Daniel Carrero (talk) 22:18, 26 May 2017 (UTC)[reply]
I too find this pointless. The addition of language codes was only for RFV, and only necessary for the splitting of the page. The categories you made are extra clutter. —Μετάknowledgediscuss/deeds21:07, 26 May 2017 (UTC)[reply]
My reply above was meant to address basically your comment, which seems misguided: "The categories you made are extra clutter." My point is, there were categories before so they can't be extra clutter. But of course we can delete the categories if people want (even though I think the categories are great and should be kept, but what do I know). Many entries already had language codes before I added the rest of language codes. If we were not meant to add the language codes, then the "language code missing" categories themselves (Category:Language code missing/rfd, Category:Language code missing/rfc and maybe Category:Language code missing/rfv) were pointless by definition. --Daniel Carrero (talk) 03:33, 28 May 2017 (UTC)[reply]
Apart from the need to add the langcode (which most if not all request templates have: {{rfi}}, {{rfe}}, {{rfp}}, etc.) is it a bad thing to know what exactly are the French or Chinese or Spanish entries nominated for deletion? The categories can be deleted if unwanted of course. --Daniel Carrero (talk) 21:13, 26 May 2017 (UTC)[reply]
I forgot to mention: before I did anything, when you added the langcode in these templates, the entries were categorized in "attention" categories. So, I didn't introduce the concept of per-language categorization of entries with requests. I just moved them from Category:English terms needing attention (old category, deleted by vote) to "Category:Requests for (request type) in English entries", which is clearer. When the entry didn't have the language code, it was sent to "language code missing" categories like Category:Language code missing/rfv. So I added the code everywhere, thereby cleaning up the cleanup categories. --Daniel Carrero (talk) 21:23, 26 May 2017 (UTC)[reply]
The worst part of this is that it's no longer possible to add something like {{rfc|This is a mess}}, regardless of the namespace. We should not make reporting problems more complicated than it is, and we shouldn't be changing an important part of the behavior of a basic template without discussion, especially since it's been this way for over a decade. I'm getting tired of this "I'mgoingtochangetheorderofparametersineverytemplateintheprojectunlesssomeonehasanobjectioninthenext30seconds. OK? Done" way of doing things. Chuck Entz (talk) 22:27, 26 May 2017 (UTC)[reply]
@Chuck Entz I'll remember that next time. Admittedly I never discussed before what we are discussing now. I apologize for that and take responsibility. (naturally, the recent vote about requests doesn't count -- it listed a lot of request categories but it didn't say anything about deletion/cleanup/verification)
Still, let's discuss this idea on its merits. Most of {{rfc}} requests are in the main namespace (530+ entries) as opposed to other namespaces (53 pages + categories). Most of the request templates (not to mention templates overall) already use 1= as language code. Arguably, having consistency makes thing less complicated, not more, because less often you have to remember the rules for each separate template. This assumes that we want the request templates to have similar results, including fully populated categories for entries of every language. (which should be automatic once Wiktionary:Votes/2015-12/Install Extension:Variables is implemented) --Daniel Carrero (talk) 23:46, 26 May 2017 (UTC)[reply]
No, it isn't a good illustration of that. rfc is exactly like rfv in entries (I'm talking about the design: they are two of the many request templates that allow a parameter for a language code and another for a reason). I fixed that category. --Daniel Carrero (talk) 03:52, 28 May 2017 (UTC)[reply]
rfc is used for a wide variety of problems that can't be assigned a language code: invalid or missing headers and headword templates, misplaced content, language sections in the wrong order, mislabeled or jumbled together, to name a few. It's also used in appendices, categories, templates and other namespaces. Yes, there's overlap, but they're not the same.
Of course you're talking about the design (if all you've got is a hammer, everything looks like a nail), but someone who's been using the same template for years isn't thinking about design, they're just going to be annoyed that they're getting a module error because someone redesigned some other templates and someone else wants to make everything a matched set. Every change comes with a cost, and you're not qualified to weigh that cost: coming up with ideas is fun, but having to adjust to changes that you didn't ask for usually isn't. For some reason, you often remind me of this scene from Jabberwocky... Chuck Entz (talk) 06:35, 28 May 2017 (UTC)[reply]
I'm sorry that adjusting to changes like this is (as you put it) not fun. I'll remember to discuss proposed changes in the future. The rfc/rfd/rfv changes can be undone if people want. (I realize I'm repeating myself.) The templates can be edited to use only "lang=" again as the language, even though that's longer and not exactly my personal preference. --Daniel Carrero (talk) 07:18, 28 May 2017 (UTC)[reply]
I think these new categories are useful. They allow editors to look for entries that need verification or cleanup, or are being deleted, in a language that they actually know something about, rather than having a bunch of entries of indeterminate language all jumbled together in the same category, some of which the editor will be able to help with and some that he or she will not. — Eru·tuon03:41, 28 May 2017 (UTC)[reply]
@Backinstadiums: There is only one form of shorthand in Unicode so the first step would be adding the individual characters like 𛰀 before adding any term written in the script. We had a similar discussion regarding Morse code as well. —Justin (koavf)❤T☮C☺M☯16:48, 26 May 2017 (UTC)[reply]
@Backinstadiums: Good question. Entries here need attestation and verification to show that they actually exist. What that means varies widely depending on the language, the term, etc. The guiding help page for this is Wiktionary:Criteria for inclusion which explains that individual characters are suitable for inclusion. I would find it unlikely that shorthand versions of words in standard scripts would be included, tho. —Justin (koavf)❤T☮C☺M☯17:46, 26 May 2017 (UTC)[reply]
@Backinstadiums, -sche: Altho individual words which have been shortened to one character would be a good addition. E.g. & and ⁊ which are individual characters representing and. I'm pretty ignorant of shorthand but I'm certain that some common words have been truncated to a single character. —Justin (koavf)❤T☮C☺M☯21:18, 26 May 2017 (UTC)[reply]
Until approximately February 2014 we had many entries for words beginning in "ab" which had the header "Shorthand". One example is the entry for able, which had the header until this edit. The contribution had been made by one User:Wikigregg. (See his contributions.) I don't know on what grounds the material was deleted. I thought the entries were a great example of an abortive effort. DCDuring (talk) 00:59, 27 May 2017 (UTC)[reply]
@DCDuring: We should 100% have transcodings of Latin characters into Braille, fingerspellings, Morse Code, Semaphore, and shorthand. Why not? It could be done by machine and is valuable. —Justin (koavf)❤T☮C☺M☯08:30, 27 May 2017 (UTC)[reply]
@Backinstadiums, Koavf For encoding, including the various transcription schemes under a heading in a table would work. But so would an appendix that had the characters or symbols. For decoding, the search engine would find the coded word on the right page, probably placing it at the top of the "failed-search page list. DCDuring (talk) 12:57, 27 May 2017 (UTC)[reply]
@DCDuring 100% agreed. A table like "{{subst:BASEPAGENAME}} in other endcodings" that generates Braille, fingerspelling, Morse Code, semaphore, and shorthand would be useful. Are there any other variations that you can think of to add? —Justin (koavf)❤T☮C☺M☯19:19, 27 May 2017 (UTC)[reply]
Too bad there's no convenient resource for discovering the possible intended meaning of a word whose meaning one doesn't know. If only someone would work on that.
I see. The programming language in use here for more-or-less real time applications is Lua. Automatic transliteration efforts have been undertaken with varying degrees of success and acceptance. I'm not the one to ask. DCDuring (talk) 18:05, 27 May 2017 (UTC)[reply]
The map of Oïl Languages in the French Wiktionary.Another map.
Without intending to bring out "the pitchforks" as you put it in another thread, let's think about how these languages of France, and the others which are one these maps and mentioned at Wiktionary talk:About Bourguignon, would best be grouped. We could add ~20 codes, one for each variety on the maps, but is that best, or should some be grouped?
Our treatment of mutually intelligible lects is highly inconsistent, almost as badly so as the ISO's/SIL's — except that while they tend to split African, Asian and Oceanic lects even with very high mutual intelligibility (though with some notable exceptions like Australian lects with sub-45% intelligibility which share a code) and to not split European languages (again with some exceptions, like the entirely mutually intelligible varieties of Serbo-Croatian, Norwegian, or Dutch Low Saxon), we have often done the opposite, merging Fula etc but having far more codes for e.g. Romance and Germanic lects than the ISO. Like Picard, Walloon, Norman, Burgundian, Gallo, but not many other oïl languages (yet) like the ones you name; Rhine Franconian, Pennsylvania German, and Volga German; Asturian and Leonese; Bavarian, Mocheno, and Gottsheerisch; Norwegian, Norwegian, and slightly-differently-spelled Norwegian; Luxembourgish and Transylvanian Saxon; etc.
Should we keep doing that, and grant codes to most of the lects on those maps? I'm not actually opposed to that... although my understanding is that Poitevin should perhaps be grouped with Saintongeais, either as "Poitevin-Saintongeais", or just "Poitevin" with "Saintongeais" listed as an alt/subsumed name.
Heh, I knew it wasn't going to be a simple request. =) You're right, the inconsistency is pretty atrocious. We probably need a panel to go through all the ones we have, removing some and adding others. I think we can agree though that these two are more than mere dialects of French. I'm in total agreement on Poitevin-Saintongeais, which is actually how it's done on the French Wiktionary. This page might also be a good guide. --Victar (talk) 21:20, 26 May 2017 (UTC)[reply]
Ha, I'm sorry for broadening the thread so much :-p by bringing up Fula, Bavarian, etc. Let's see if we can decide which oïl languages to include, though, so we don't keep adding them piecemeal. We have codes for
Walloon,
Picard,
Norman,
Gallo,
and Bourguignon(-Morvandiau).
We can add a code for Poitevin(-Saintongeais).
How different is Bourbonnais from Berrichon? Some references group them, some don't.
How do Bourbonnais and Berrichon compare to Orléanais and/or Tourangeau?
Can Angevin be considered part of Gallo, or does it need its own code? (Some references group them, some don't.) What about Mayennais and Sarthois (fr.WP considers them part of Angevin)?
Do Champenois, Lorrain, and Franc-Comtois all need codes?
No worries, might as well get them over with. I'm really inclined to go with the list the French Wiktionary team came up with. If some 11 French users agree to it, that's probably better than what you and I can determine on our own. They had a whole discussion on it and everything. --Victar (talk) 04:31, 27 May 2017 (UTC)[reply]
Well, I hope(d) other people might join this discussion, too! :p The French Wiktionary's list is a good starting point, although in general they tend to be very splittist (splitting e.g. Alsatian German from Alemannic German, Hoanya from Papora, etc). - -sche(discuss)04:48, 27 May 2017 (UTC)[reply]
I've added "roa-poi" for "Poitevin-Santongeais", a name which is long and unwieldy but is clear (and is also what fr.Wikt uses); the canonical name could be shortened to "Poitevin" if desired.
Hi! There is an ongoing project named Langues de France that works on this matter by contacting local groups of speakers, linguists and lexicographers on local languages (mainly Alsatian and Occitan at this point) and Wikimedia France chapter organized a dozen of workshops with speakers all over France. Let's summon @Lyokoï and @Xenophôn, they may help you better than me Noé14:39, 30 May 2017 (UTC)[reply]
Hi dear all ! I'm the autor of this page ! I will try to respond to your questions (and sorry for my bad english) :
and Bourguignon(-Morvandiau) : The part name Morvandiau is the most speaked dialect of Bourguignon language. It is located in the center of the Bourguignon language region. The speakers have a lot of political weight so they have to force the french government to add their dialect name to the language name (as if their dialect was a different language).
We can add a code for Poitevin(-Saintongeais). : Yes, Poitevin and Saintongeais are the two largest dialects of the same language Poitevin-Saintongeais. There is lots of sub-dialect (I have not yet listed) and the language don't have his own name, so linguists and policies have just to merge the tow names of dialect. You should to name the language Poitevin-Saintongeais.
How different is Bourbonnais from Berrichon? Some references group them, some don't. : Yeah it's a difficult part. But, Bourbonnais is an historical region with a big identity. I do the choice to separate it from Berrichon because if new people want to contribute to Wiktionnaire, he know that his language is named patois or maybe patois of bourbonnais. He will never give any link with the Berrichon language (or Berry region).
Can Angevin be considered part of Gallo, or does it need its own code? (Some references group them, some don't.) : the references who group Gallo and Angevin are old. Now, we make a difference (See Henriette Walter and Marie-Rose Simoni-Aurembou). It need its own code.
What about Mayennais and Sarthois (fr.WP considers them part of Angevin)? : Very complicated question. Some references group Mayennais and Sarthois in Manniot, some don't, some just say Parler centraux de l'ouest (West Central Languages). I choose like Bourbonnais. Even if there is not much left, there are still people who speak these languages, so I took the choice to collect them with the most likely name for a speaker.
Do Champenois, Lorrain, and Franc-Comtois all need codes? : Yes ! Really yes ! Franc-comtois allready have his code (it's fc in french wiktionary, but I do not know where it comes from), and Lorrain and Champenois are well known to linguists.
@Lyokoï, Victar OK, I have added codes for Angevin (roa-ang), Champenois (roa-cha), Lorrain (roa-lor), and Franc-Comtois (roa-fcm, intentionally not "(roa-)frc" because that's too close to Cajun French's code), Orléanais (roa-orl) and Tourangeau (roa-tou).
Regarding Bourbonnais and Berrichon, Mayennais and Sarthois, and Percheron : I wouldn't presume to know more about the languages of France than the French do, but I get the impression that fr.Wikt has assigned codes on the basis of whether the speakers would want separate labels (and fr.Wikt is the wiki the speakers would probably choose to add words to), whereas en.Wikt as a basic difference is more interested in how mutually intelligible or not the lects are, and perhaps especially in how many words are spelled the same. If Bourbonnais and Berrichon have a lot of overlap and we would have a lot of pages with identical Bourbonnais and Berrichon sections, it's probably best to have one code for "Bourbonnais-Berrichon"; whereas, if all the words are spelled differently in addition to the arguments above for keeping the separate, then maybe we might as well have separate codes, although again, it depends on how mutually intelligible they are.
What is to be done about Francilien/Francien? How different is it (supposedly) from French? On en.WP and fr.WP, I see not only that it seems very similar, but also that there is debate over whether the lect existed as such at all.
Natural regions of France, each have its own identity, and very often its language.
@-sche The big problem is that the oïl region is technically a big dialectal continuum. So most parts of the region are mutually intelligible, but with differencies as one moves away from the reference point. There is lots of isogloss, but little sheaf of them exist. Second problem, there are no or too few studies on the distinction of the different linguistic regions in oïl region. Personally, I did not find any exploitable to make a map simply. Not being able to rely on the pronunciation, we can find differences on vocabulary and syntax (But it's difficult for it), but ultimately it is especially on the traditions of division of regional identity that we have real viable information. Easily identifiable cutting units are natural regions (map), below there are the communes. If you search documentation and dictionaries of oïl languages, you have a lot of scales :
The municipalities : Le patois de (the patois of) <name of the commune>.
The valley/canton/land : Le patois de (the patois of) <name of the valley/canton/land>
The natural region : Le patois de (the patois of) <name of the natural region>
An assembly of natural régions : Le patois de (the patois of) <name of the natural region>, <name of the natural region>, <name of the natural region>, <name of the natural region>,... (I have a dictionnary with 5 natural regions in its title).
So, when you need to describe oïl languages you can't find purely linguistic informations, because of scales, because of history (regional langage in France are very badly considered by politicians since four centuries), because of disinterest of linguists, because of disinterest of speakers, and more. I try to be precise with each reference (dictionaries, lexicons, glossaries) by creating localization models. See trigeasse with Chef-Boutoune model. --Lyokoï (talk) 07:03, 31 May 2017 (UTC)[reply]
I've been looking at texts in and about Bourbonnais and Berrichon, and there seems to be much overlap, and as much variation within the dialects as between them. In Duchon's dictionary of Bourbonnais, the Berrichon forms are frequently identical to the Moulins forms. In keeping with en.Wikt's general efforts to not split up units (of mutually intelligible lects) into overly many codes, seen also in e.g. how the regional lects of Germany (Rhine Franconian, etc) have been handled, I have added a code for Bourbonnais-Berrichon (roa-bbn). - -sche(discuss)20:09, 5 June 2017 (UTC)[reply]
@-sche, Victar fr.Wikt don't have this "not split up units" rules (but I think he needed), but I understand this position. Split or not Berrichon-Bourbonnais make sense but with different argument. I am delighted to have been able to help you choose. --Lyokoï (talk) 07:58, 7 June 2017 (UTC)[reply]
Hah, Haspelmath's piece is remarkably contortionist. "You should never change a language's name! But if you do while writing a big book, we respect that. But you shouldn't have done it. But everyone should follow you in doing it." The claim that languages can't have two names in one langiage, and even the claim that cities can't, is amusing. Tell it to the people who speak Irish or Gaelic in Derry or Londonderry, to start with! - -sche(discuss)21:51, 9 June 2017 (UTC)[reply]
To be fair, his focus is only on canonical names for languages to be used in scholarly contexts, and he says up front that he's proposing a prescriptive standard. I also find his contortions amusing, though. Basically, he's saying: "These prescriptive, cut-and-dried rules are the only way you should do things, but abandon them if authorities on the languages decide otherwise." Chuck Entz (talk) 04:47, 10 June 2017 (UTC)[reply]
@Victar Less, at present the consensus is on a single domain although independantists are struggling for their variation to be considered separately. But it is a rather sensitive subject. On the Wiktionnaire, we followed the recommendations most represented: everything is in one language. Lyokoï (talk) 16:26, 14 June 2017 (UTC)[reply]
@Lyokoï: I'm sure you know as well as I, calling Gascon and Provencal one language, is like calling Norman and Waloon one in the same! It strikes me as very inconsistent. --Victar (talk) 17:15, 14 June 2017 (UTC)[reply]
@Victar: I'm not linguist. You touch my limit of this subject. You have right to do that, but the occitanists on fr:WT prefer to follow the consensus. I respect their choice. --Lyokoï (talk) 08:36, 15 June 2017 (UTC)[reply]
Victar, you wrote "It strikes me as very inconsistent." but yes, languages borders perceptions are inconsistent and vague. Frontiers of languages move with time and are very dependent of political authorities. We can't apply an easy pattern to every situations, as it was pure data, it is not. Sorry for that. Noé08:28, 22 June 2017 (UTC)[reply]
Much of the literature on this language speaks of it as a language, rather than as many languages, so I would leave it unsplit. See also my comments in the subsection below. - -sche(discuss)18:18, 22 June 2017 (UTC)[reply]
@-sche, Victar, Noé : This is wrong, Francprovençal is a dialectal continuum. We must be precise to the commune. Because of the variation, which is very random on the pronunciation and the vocabulary concerned, the most neutral position to describe Francoprovençal is to give the list of each village concerned by the form described, with differences in pronunciation if there are any.
And as a gift, know that a large part of the language has no orthographic standard... So for each described form, we need to say where we can find it, with which orthograph, and in what text. Without sources, francoprovençal words (like other regional French Language) has no value. --Lyokoï (talk) 09:31, 22 June 2017 (UTC)[reply]
@Lyokoï: You're obviously very opinionated on the subject, but the way it is listed is neither wrong nor lacking in value. There is no set standard in displaying Franco-Provençal entries and listing each town they are from, in many cases, is simply not an option due to the sources they're taken from.
My question though, as with French, is should each major branch of Franco-Provençal have a language code, ex. roa-sav for Savoyard? --Victar (talk) 11:57, 22 June 2017 (UTC)[reply]
This is one of a number of languages where every word needs to be tagged by dialect (as broadly or precisely as sources allow), but I would follow the ISO in leaving them all under one code, as one language; much of the literature speaks of a Franco-Provençal language with many dialects. If the ISO had granted a single code for "Oil language", rather than granting codes to some but not all of the major varieties, there would've been a case for doing the same thing with all the Oil languages, frankly! - -sche(discuss)18:14, 22 June 2017 (UTC)[reply]
If we left ourselves purely to the mercy of the ISO, we'd be pretty hamstrung! Thankfully we don't, and already diverge from them considerably. We do also create language codes for families, so if we want to say these are dialect families, I think it stands to reason to give them language codes. Thoughts? --Victar (talk) 19:18, 22 June 2017 (UTC)[reply]
How to attest a word on Wiktionary without even trying[edit]
If there are only 2 citations of a term from like 5 years ago or more, just go on Google Groups and start a new topic where you use the word; then it's attested.
In the long-term, if you want to make up a word, you can also just make a Google Groups topic now using the word, then make your friend do that same thing in 2 years just using it in a different sentence/context, and do that again in 2 more years. You've just made a Wiktionary-attestable word! Even if that word is complete nonsense; it doesn't matter. Still attested, as long as it can classify as a POS and is used in English sentences. Hmmm... PseudoSkull (talk) 03:21, 27 May 2017 (UTC)[reply]
For WT:LDLs you don't even need three citations. You just need to use a word on usenet or google groups, and then it's attested. The only way to prevent such "attestations" is to exclude usenet and google groups citations for attestng a word. Searching here for usenet or google groups or google group gives some terms which then might have to be deleted. (@Backinstadiums: Maybe see also WT:RFV.) -80.133.102.21516:14, 27 May 2017 (UTC)[reply]
@Erutuon Is it possible to create a CSS class that shows an error if the template is used on a live entry but not if it is seen in an old version of the page (similar the error message that appears in previews for invalid IPA characters). DTLHS (talk) 17:40, 27 May 2017 (UTC)[reply]
@DTLHS: If there's a class that only appears in one of the wrapping <div> tags on diffs or old versions, it would be possible to add a CSS rule that would make a certain class display only on current versions. I can't seem to find anything like that in the HTML source code, though.
I wonder if a class for diffs or old versions could be added somehow in the MediaWiki software. @TheDaveRoss?
Another idea would be to add a JavaScript function that hides the messages only on diffs or old versions. JavaScript has ways to get the last revision of a current page and the revision currently being viewed. If those are not identical, then we are in a diff or old version. Not sure what the fallback would be for users without JavaScript. — Eru·tuon18:01, 27 May 2017 (UTC)[reply]
Re diffs of old versions, I think it could be added to MW via a Phabricator request (not sure they would actually do it) but it could also be inserted via JS based on the page URL. It is beyond my JS experience to try and make that happen.
Re widely used historical templates, I am of the opinion that we should only ever deprecate such templates, rather than deleting or re-purposing. We can easily enough prevent them being added through abuse filters, but the number of historical revisions which are incomprehensible due to missing templates is frustrating. - [The]DaveRoss12:20, 28 May 2017 (UTC)[reply]
Added the hover text explaining that the template is deprecated.
Edited the documentation of the template to explain again the same thing.
I believe this is all exactly the same as I have done with {{infl}} before. Feel free to edit them further if necessary.
I support making the different color only appear on current revisions, but I don't know how to do that. The HTML "body" tag does not seem to have any different CSS classes when you are viewing an older revision. --Daniel Carrero (talk) 01:21, 30 May 2017 (UTC)[reply]
I've created User:Erutuon/scripts/oldRevisionClass.js, which adds the class old-revision to the <body> tag in all but the Special and Media namespaces when viewing an old revision. Really simple. Suggestions are welcome. There may be a better class name, for one.
He was using the English term vade mecum, which refers to something that can be taken with one. The Latin the term is derived from literally means the same as Spanish "va conmigo", which is what one would figuratively ask of a vade mecum. Chuck Entz (talk) 13:48, 30 May 2017 (UTC)[reply]
I know, I know what it is, my sister is a vet. I didn't get it because I was supposing Stephen was comparing the syntax and etymological evolution of VMC to Pocket + noun and for me they have nothing to do with each other. But I realise now that he is equating the meaning of attr. pocket to the VMC (~ portable, companion). Merci. Sobreira ►〓 (parlez)22:44, 30 May 2017 (UTC)[reply]
I just created this entry, and logically it seems to me it should be unshakable + -ty, along with the general rule that converts -able + -ty to -ability. However, this isn't how most such words are formatted, e.g. unflappability is given as un- + flappability, even though the latter word doesn't seem to exist. Do we need to mention the general rule, and if so how should it be mentioned? Benwing2 (talk) 20:03, 27 May 2017 (UTC)[reply]
In principle we could create an allomorph suffix like -ility, or segment it as based on -ability. The former is maybe kind of preferrable in that forms like unshake don't necessarily exist (this one does, but e.g. unflap doesn't). On the other hand, the latter has the benefit of being neatly segmentable; maybe we could turn it into a circumfix based directly on shake. --Tropylium (talk) 22:04, 27 May 2017 (UTC)[reply]
One possibility is to write {{affix|en|unshakable|alt1=unshak(able)|-ability}}, which produces unshak(able) + -ability. This is how I have formatted various etymologies in Russian, e.g. -ница(-nica) is the feminine of -ник(-nik), so under отли́чница(otlíčnica) I write e.g. {{affix|ru|отличник|alt1=отли́ч(ник)|-ница}}, which gives отли́ч(ник)(otlíč(nik)) + -ница(-nica). (On the other hand, under certain circumstances I don't do this and instead just note under the suffix that it transforms words it's added to in certain ways, e.g. -ный(-nyj) is added onto the non-reduced stem of a word (which may show up only in the genitive plural) and palatalizes certain preceding consonants; see the "Usage notes" section of -ный(-nyj). Benwing2 (talk) 22:11, 27 May 2017 (UTC)[reply]
This case seems to be much simpler than the putative general case. shakability, though it occurs in seismology, is very uncommon in other use. The semantics would seem to require that the etymology appear as unshakable + -ity. To me the more complicated renderings having to do with the transformation of able to ability don't belong in this entry, but rather in ability. Perhaps a "See ability (Etymology)" would suffice for the students of morphology among our users. DCDuring (talk) 15:33, 28 May 2017 (UTC)[reply]
I prefer the analysis {{affix|en|unshakable|alt1=unshak(able)|-ability}}, despite its clunkiness, because the word seems to me to be derived from unshakable, and {{affix|en|unshakable|5=-ty}} requires a weird transformation of the -able part and does not acknowledge the fact that the suffix -ability exists. — Eru·tuon17:47, 28 May 2017 (UTC)[reply]
In response to Angr, I don't think it's useful to break it down into all its parts, as it has structure in it: something like [[un- + shake + -able] + -ity]. Benwing2 (talk) 00:53, 29 May 2017 (UTC)[reply]
I'm not 100% sure this is the right place to ask, but here goes.
Should the PIE root template include roots for affixes which have lost their semantic value?
I'm thinking of Italian -mente(adverb-forming suffix), derived from Latin mente, ablative singular form of mēns(“mind”). ultimately derived from the PIE root *men-(“to think”): should a word suffixed with -mente be categorized as (also) derived from the root *men- even though it doesn't bear the original meaning of “thinking”? –– GianWiki (talk) 13:42, 30 May 2017 (UTC)[reply]
I sometimes see people change etymologies that were using {{prefix}}, {{suffix}} and {{confix}} to {{affix}}, even though it seems less accurate to me; why is that?
About your first question: it doesn't really matter, it's just that {{affix}} can automatically figure out what kind of affix something is by looking at where the hyphens are. —CodeCat23:32, 30 May 2017 (UTC)[reply]
Use "Cognate" to link between citation pages[edit]
This is a really minor thing that won't get a chance to be used much at the moment, but I wonder if it's possible to make the Cognate extension generate automatic interwikis between citations pages like these:
Thanks for your suggestion. Is Citations: a namespace? It seems a bit different. I'd like to know more about this.
Are the actual titles of the pages (excluding the Citations: prefix) always guaranteed to be the same as the word they are about? If yes, we can consider Cognate.
If it is a namespace, just as Wiktionary: Help: and the others, then it won't be linked by Cognate, but by the centralized links on Wikidata, which will be announced very soon :) If it is something else, then we have to think about a dedicated solution for these pages. Lea Lacroix (WMDE) (talk) 18:14, 31 May 2017 (UTC)[reply]
Why does the namespace make a difference? Cognate handles the main namespace just fine, but not any others? —CodeCat18:27, 31 May 2017 (UTC)[reply]
@Lea Lacroix (WMDE): Please see Citations:they for an example of the "Citations:" namespace. It contains uses of the word "they", usually cited from books and running text.
Any entry can potentially have a "Citations:" page.
I thought it might be a good idea to link the citations pages automatically when they have the same spelling, much like Cognate does for the main namespace.
Yes, the actual titles of the pages (excluding the Citations: prefix) are always guaranteed to be the same as the word they are about. --Daniel Carrero (talk) 18:30, 31 May 2017 (UTC)[reply]
Technically it is a custom namespace. On en.wikt {{ns:114}}, on pt.wikt {{ns:108}} with a localized canonical name not matching the English one as all canonical ones should do. Maybe it is a problem to do not have the same namespace number and same canonical name, either for Cognate or for Wikidata. --Vriullop (talk) 19:18, 31 May 2017 (UTC)[reply]
@Lea Lacroix (WMDE): You said "I'd like to know more about this.", so I'll talk about "lemmatizing" citations: the "lemma" is the main form, and "lemmatize" basically means treat and format as the main form.
The page Citations:lamaism currently has citations for "Lamaism", "Lamaist" and other related words. We may want to create redirects from Citations:Lamaism, Citations:Lamaist, etc. or we may still be able to create these separate citations pages on their own merits.
Hi, I've just come across the description "(accompanied by a hand gesture)", and I love the idea of adding this type of info. where relevant, yet more detailed, with images of even video accompanying it. By the way, what realm of linguistics studies it? --Backinstadiums (talk) 20:12, 31 May 2017 (UTC)[reply]
The hand gesture is optional, though. I'm sure I've used expressions like "yay big" even when talking on the phone. —Aɴɢʀ (talk) 07:56, 1 June 2017 (UTC)[reply]
Thanks for answering. Then adding "usually/normally" would improve the note. I do not know how to organize this, but it would really make a difference for Wiktionary to add that kind of additional info., such as body expressions (nodding, grimaces, etc.). To put it on record, on what page of the one's in Help:Contents should it be added? --Backinstadiums (talk) 09:53, 1 June 2017 (UTC)[reply]
@Equinox: Thanx. Creating a visual repository for wiktionary would undoubtedly add a great technical value. There're good academic papers about it, so I'd propose to create working group to research about it and create content. --Backinstadiums (talk) 13:20, 1 June 2017 (UTC)[reply]
Noé 09:38, 4 May 2017 (UTC)
Support —CodeCat 22:52, 12 May 2017 (UTC)
Oppose PseudoSkull (talk) 03:36, 13 May 2017 (UTC)
Abstain I have voted for enough good-sounding things that turned out to be awful (hi COALMINE!) not to want to support unconditionally, but I don't know that I want them hidden either. I support having nyms under their individual senses but I don't think either of the support-options gives enough flexibility about how. Equinox ◑ 03:27, 13 May 2017 (UTC)
Markup that looks like code for language variants might need to be fixed. Tech News wrote about this last week. If 
wikimedia.org.
Done" way of doing things. Chuck Entz (talk) 22:27, 26 May 2017 (UTC)
Noé 08:28, 22 June 2017 (UTC)