Wiktionary:Beer parlour/2024/July

Parsing the principal parts in the headword lines of Latin verbs
Previous discussion:
 * [[Image:Wikt rei-artur3.svg|20px]] 

As a consequence of the change to Latin verb definitions initiated in the above-linked discussion, some editors raised the concern that some readers might be confused by the mismatch between the grammatical status of the verb form which serves as the Latin lemma (the first-person singular present active indicative) and the status quo novus of how Latin verbs are defined (with the English infinitive). Accordingly, the suggestion was made to parse the first principal part of Latin verbs (the other three principal parts had already been parsed since time immemorial). The code to institute this was added, but soon after removed again because “[it] wildly change[d] the visual outcome of what Latin verbs have always been and [had] not [been] changed with a valid vote”. Given that consensus for the addition is not yet apparent, I thought I'd try to reinvigorate the discussion here.

Since the occasion has presented itself, I would like to propose a reform to how Latin verbs are parsed. I shall use for my example the old grammarians' favourite,. Currently, Latin verbs are parsed thus: and restoring the parsing of the first principal part as it stood 14–17 November 2023 would result in: In both these schemes, however, the parsings are badly and inconsistently conceived. All the parsings are abbreviated; if they weren't, this is what we'd see: The first three principal parts (hereafter PPs) are all active, so why is only the third PP labelled as such? The first and third PPs are both first-person, singular, and indicative, so why is only the first PP labelled as such? This doesn't really make sense. Note that, for normal Latin verbs' principal parts, no person but the first person, no number but the singular number, and no voice but the active voice is ever mentioned. Only the tense (present or perfect) and the mood (indicative or infinitive) vary; accordingly, they are the important features to parse. If we restricted ourselves thereto, would look like this: Of course, the initial concern about the aforementioned mismatch remains in that scheme, so what I actually propose is: Thoughts? 0DF (talk) 03:14, 1 July 2024 (UTC)
 * amō (present infinitive amāre, perfect active amāvī, supine amātum); first conjugation
 * amō first-singular present indicative (present infinitive amāre, perfect active amāvī, supine amātum); first conjugation
 * amō first-person singular present active indicative (present active infinitive amāre, first-person singular perfect active indicative amāvī, accusative supine amātum); first conjugation
 * amō present indicative (present infinitive amāre, perfect indicative amāvī, supine amātum); first conjugation
 * amō ( amāre,  amāvī,  amātum); first conjugation
 * I agree that we can leave out "active" from all parts: I doubt anyone would expect unlabeled forms to be passive, so treating the active as an unmentioned default seems unproblematic. So I support replacing "perfect active" with "perfect indicative". I think it's not so obvious though that the citation form is first-person singular. While "first-person singular present indicative" is a bit long, possibly we could use "1sg present indicative" and "1sg perfect indicative" with a link explaining what the abbreviation 1sg means?--Urszag (talk) 03:35, 1 July 2024 (UTC)
 * I suggest using standard linguistic glosses throughout:
 * amō, ,  ,
 * With tooltips spelling everything out in plain English. Nicodene (talk) 09:56, 1 July 2024 (UTC)
 * This one reads the smoothest. Fay Freak (talk) 14:16, 1 July 2024 (UTC)
 * I don’t think this is a good idea. Tooltips don’t display on mobile devices, and the abbreviations are difficult for ordinary readers to understand. — Sgconlaw (talk) 16:17, 1 July 2024 (UTC)
 * We already do that for gender and number. Nicodene (talk) 21:05, 1 July 2024 (UTC)
 * Funny that I specifically considered mobile users and reached the opposite conclusion. It is advised either way to keep the lines short and avoid line breaks ergo as well vertical space. Our mobile presentation can look different, by including a question-mark toolbutton in place of relying on tooltips. And link to List of glossing abbreviations or something; we have not shied away from having an Appendix:Glossary, so  is inconsequential here, though Nicodene has not expressly thought it through. Fay Freak (talk) 23:15, 1 July 2024 (UTC)
 * My opinion may be a bit radical. Our headwords are already five times more verbose than normal paper dictionaries, because of course, we can afford it, but visual clutter is still a thing (i.e. scouting out the real information drowned in labels). Even as they currently stand I would make them shorter:
 * amō (perfect amāvī, supine amātum, infinitive amāre)
 * More thorough explainations can be held in a centralised appendix, which should somehow be accessible and reader-friendly. As a side note, I notice only now our Latin headwords have moved infinitives from the fourth place (as they're in all Latin dictionaries) to the first one, I don't see any obvious reason why we would be breaking such a secular practice in Latin lexicography. Catonif (talk) 11:24, 2 July 2024 (UTC)
 * I’d be happy with that. Plus perhaps a footnote/toolbutton/whatever with a message along the lines of:
 * “The four principal parts are as follows: first-person singular present active indicative (first-person singular perfect active indicative, accusative supine, present active infinitive).”
 * Nicodene (talk) 12:29, 2 July 2024 (UTC)
 * Seeing as the headword will never need to link to another page (since it's identical to the name of the page), I guess we could put a tooltip on the headword itself that when hovered on, explains that it is a first-person present indicative form--unless that would be too distracting. Like this:
 * (perfect amāvī, supine amātum, infinitive amāre)
 * --Urszag (talk) 13:56, 2 July 2024 (UTC)
 * I suppose that is enough. More complete information about the other three principal parts can always be found by just clicking on them. Nicodene (talk) 16:02, 2 July 2024 (UTC)
 * I support this--i.e., (1) having tooltips so that all the relevant information about the verb forms is presented, but (2) without cluttering the entry, and (3) moving the infinitive to the end to match the order used by other dictionaries. I would also support a solution that used straightforward abbreviations (e.g. "1st person sing."). I am concerned about the status quo, which has simply removed any indication of the lemma not being an infinitive form. Andrew Sheedy (talk) 18:48, 2 July 2024 (UTC)


 * Re reordering the principal parts, I was surprised to discover that 's An Elementary Latin Dictionary (amō) and 's ' (ămo) do indeed give the principal parts in the order present indicative, perfect indicative, supine, present infinitive. However, I'm not seeing universality here. 's Woordenboek Latijn/Nederlands (amō via Logeion) gives only the present indicative and present infinitive; Joaquim Affonso Gonçalves' Lexicon Magnum Latino-Sinicum (Amo) gives the first- and then second-person singular present active indicative, followed by the present active infinitive; whereas Lewis & Short's ' (ămo) gives them in the order present indicative, perfect indicative, supine, omitting the present infinitive altogether. Our order is that which prevails on Wikipedia and in and James Bradstreet Greenough's New Latin Grammar for Schools and Colleges (see § 1.26.1 thereof). Pace , I am not persuaded that we are in fact "breaking…a secular practice in Latin lexicography" by ordering verbs' principal parts as we do. 0DF (talk) 20:38, 2 July 2024 (UTC)
 * Aha! Well conducted research. Not trying to persuade you, legitimately thought that was a thing, mostly due to the Italian lexicographic tradition for Latin verbs we're taught in schools, which is actually first person singular indicative present, second person singular indicative present, perfect, supine, infinitive: all four Italian-Latin works I have access to work like that. I guess if it is not as rigid as I was taught we can go with whatever is most common in Anglophone literature, or really, we can keep the current system and eventually discuss this separately if we feel like we have to.
 * Anyways, I also agree with having a tooltip (even though there's always the mobile issue), maybe however just containing "first person singular"? Since indicative, present, and active is all what you'd expect anyways from a lemma, and the first-person status is also shared with the perfect. Catonif (talk) 22:10, 2 July 2024 (UTC)
 * Given that around 30-40% of our readers are using mobile devices (|bar|2-year|access~desktop*mobile-app*mobile-web|monthly source) I any further use of hover titles beyond what is already in place. Would definitely  removing the word "active" and re-adding the caption that labels the first principal part as the first-person singular present (indicative? not sure if we need to mention that). This, that and the other (talk) 23:54, 8 July 2024 (UTC)

Should minimum wage be in a PIE root category?
Sorry for a header so specific, what I mean to address is actually this general issue, but wasn't able to capture it in a concise enough title. It is something that has bugged me for quite some time already, but now that etymon started to be greatly employed and even deals with categorisation (not without disagreements, see GP § June 2024), it seems like this has become a very pressing issue. For the sake of an example, take Category:English terms derived from the Proto-Indo-European root *mey- (small). At the moment it contains mostly sensible entries and is an actually enjoyable and relatively useful category. Although notice entries such as minimum wage (where the question would be, does that need an etymology in the first place) and, most importantly, note that once we fully undergo proper automated concistency, this will contain thousands of entries containing the prefix mono- (e.g. monobrominated, monochromaticity, monotheistically), making the category overly cluttered and much harder to find non-obvious results in it.

My approach for this (automation aside, this is how I have always used root) is to only add to that category the terms that aren't themselves derivates (or derivable, tricky here) from other entries that are already in the category. Essentially the entry would contain only the basic terms by which all the other ones can be derived.

I can see how this can seem unappealing to those seeking for full module automation and steel-hard consistency accross all entries, although I hope many can agree that whoever chose to make root category a thing didn't do it for them to be an endless list of monotonousness.

Catonif (talk) 17:42, 1 July 2024 (UTC)
 * I don't see why an MWE like minimum wage needs an etymology. If an MWE were to have an etymology, it would seem useful to exclude it from etymology trees. This kind of thing is also a problem under Derived terms headers, where it would not surprise me to find minimum wage law. DCDuring (talk) 18:32, 1 July 2024 (UTC)
 * It was originally agreed that this template would not be deployed in multiword terms, not sure who's ignoring that. I don't see the problem with single-term entries being categorized. Vininn126 (talk) 19:21, 1 July 2024 (UTC)
 * Side note, but can we make an exception for that when a multiword term can't be broken down into its constituents? It would be really dumb to exclude, for instance. Theknightwho (talk) 20:19, 1 July 2024 (UTC)
 * I think that was mentioned in the thread, I can't remember. Vininn126 (talk) 20:25, 1 July 2024 (UTC)
 * The exceptions to the MWE exception do need to be respected. Do we have a category for such terms? If not, we could benefit from having one. DCDuring (talk) 21:19, 1 July 2024 (UTC)
 * I am aware of a few other multi-word entries that use root, namely Ku Klux Klan ("Ku Klux" being a split form of Ancient Greek κύκλος (kúklos)) and sgian dubh (borrowed together from Scottish Gaelic; neither word is used separately in English).
 * This discussion reminds me of a similar one from June about the etymon template. As for this discussion, I wondered the same thing, but I feel that the following rules of thumb are likely to prevent people from getting too riled up:
 * Only lemmas should be included, unless sufficiently distinct (such as inflected forms of be) or suppletive (such as people). Where something like datum versus data falls, I don't know.
 * Each one must be a single word or morpheme; this may include, I suppose, every word prefixed with insert prefix here (I won't go crazy with it, though). However, "unsplittable" terms such as the ones described above can be treated as one word.
 * WT:COALMINE scenarios... I'm not sure.
 * Descendant hubs should not use root or etymology trees, though using the etymon template is okay for passing information to other pages.
 * -B RAINULATOR 9 (TALK) 02:18, 2 July 2024 (UTC)
 * is:
 * English
 * A term
 * Derived from the Proto-Indo-European root (small).
 * So there is absolutely no justification for it to not be in a category called Category:English terms derived from the Proto-Indo-European root *mey- (small).
 * It seems like what you really want to do is to change the category itself. What you're describing (i.e. a category without thousands of words) might be more accurately dubbed Category:Common English words derived from the Proto-Indo-European root *mey- (small). I don't know how we could decide which terms are "common" enough to include. Also : the previous BP discussion was about etymology trees on multi-word entries, not the template itself. Ioaxxere (talk) 04:17, 2 July 2024 (UTC)
 * : It's also spelled with the letters "a","e","g","i","m","n","u", and "w", but a decision was made to not have "spelled with" categories for letters that are part of the normal orthography of a language. We absolutely should have single words and morphemes in all the applicable derivation categories, but derivational categories for all the parts of a multi-word expression is unnecessary overkill. Do we really want categories for function words like "a", "and", "of", "or", "the", etc. in phrase entries? Chuck Entz (talk) 05:46, 2 July 2024 (UTC)
 * I agree. That's why we don't have a category called Category:English terms spelled with A. My point is that if the category Category:English terms derived from the Proto-Indo-European root *mey- (small), as literally specified, is too large to be useful, then it should simply be deleted, rather than post hoc negotiating "well, actually, it's not all the English terms...". Ioaxxere (talk) 06:26, 2 July 2024 (UTC)
 * @User:Ioaxxere The principle that you seem to require us to follow is that once something is specified, the specification must remain unchanged, either for all time or perhaps until you decide otherwise. This would seem to mean that nothing should be specified unless it is perfectly specified for all time. Good luck with that. I've always thought that humans, both individually and in groups, were at their best when learning and adjusting their institutions accordingly.
 * To me making the simple adjustment of excluding MWEs by default from the listing in question and requiring exceptions to be made manually seems reasonable to cover the cases where the MWE has a non-trivial etymology. Occasionally the etymology of an MWE is relevant to an etymon tree. But usually it is not. For example, I don't understand why anyone finds adding a trivial etymology to a multi-part taxonomic name a good use of their time or of a user's attention, but some do. DCDuring (talk) 14:23, 2 July 2024 (UTC)
 * I think it's a fair point that these kinds of categories are doomed to be highly incomplete and arbitrary, especially if it's left up to manual placement of "root" templates. It's not so obvious that this is something that makes sense as a category (if we're just presenting a manually curated list with no pretensions at being comprehensive, wouldn't that almost be more appropriately presented in an appendix?). I definitely think it seems especially low value to include multi-word terms in these kinds of categories, and that isn't a very difficult exclusion criterion to apply (although the use of "term" instead of "word" in the category name doesn't help with making this criterion apparent). But the conversation has also brought up prefixed or derived single words, which is a much harder criterion to follow. (Incidentally, it seems like "mono-" probably doesn't come from *mey- after all, though that doesn't resolve the issue of if we want all the mono- words included in some category or another.)--Urszag (talk) 14:34, 2 July 2024 (UTC)
 * I agree with User:Urszag here. Ioaxxere (talk) 18:26, 2 July 2024 (UTC)
 * Well put. Vininn126 (talk) 18:35, 2 July 2024 (UTC)
 * Then I propose we simply change these categories to read "English words derived from the Proto-Indo-European root...". Andrew Sheedy (talk) 18:53, 2 July 2024 (UTC)
 * Agree with Urszag and Sheedy. But what about Klu Klux Klan and similar? DCDuring (talk) 19:35, 2 July 2024 (UTC)
 * @Andrew Sheedy That doesn't work, because we need an exception for terms with spaces that aren't decomposable in the given language. Theknightwho (talk) 21:03, 2 July 2024 (UTC)
 * I think a short-term way out of this mess would be to allow control over categorization: there should be parameters to tell the module that certain parts of the tree should not generate categories. There may be better names for the parameters I'm suggesting.
 * first the easy part:
 * Prevent addition of categories to the current entry only without affecting the drawing of the tree:
 * [language code or spec of node to be uncategorized]
 * So, if you don't want etymon to add the cat for Middle French to an English borrowing from modern French, you would just use frm, and it won't add Category:English terms derived from Middle French to the entry.
 * [language code or spec of the highest node to be uncategorized]
 * This tells it to show categories up to the node in question, but not those of any of its ancestors. If you don't think the ancestry of a minor morpheme in an Old English ancestor should be added to the categories for a Japanese calque of an English term, you would just put ang, or whatever the spec is for the Old English morpheme itself. If the node given is the current entry, no category at all would be added, so you could use [spec for "the" in the current entry name] to keep it from showing any categories for "the"
 * more complicated:
 * The same as above, but the parameters would control etymon in all the other entries that use the entry as a node in their trees. Thus, a parameter in an Old English entry could prevent a certain node in its tree from being used to add categories for any of its children, and another could tell all of its children not to look past a certain ancestral node in its tree when adding categories.
 * That's all I have time for right now, but at least it should give the basic idea Chuck Entz (talk) 15:14, 3 July 2024 (UTC)
 * : Those are interesting ideas. But I think it would be better to come up with some simple and consistent rules that the template can enforce rather than letting editors arbitrarily cut off whichever categories they like.

Ryukyuan kanji entries
I'm a bit concerned about the large number of unsourced kanji entries we have for the non-Okinawan Ryukyuan languages. I note that they were generally added to pages en masse by users who like(d) to bounce about between languages (e.g.  ), and most are completely unsourced. In some cases, they don't seem to make much sense, either: e.g., which I think has been inferred from JLect or from Nikolay Nevskiy’s Miyakoan dictionary, which gives "foː", but I can find no dictionary to verify the kanji spelling, and it seems implausible that we'd have a lone ー after the kanji, given that's not where the morpheme boundary is.

There are a handful of entries that that do provide a source for the kanji spelling, like, and although JLect isn't seen as very reliable by some contributors, it's better than nothing. However, I really think we should remove all of the unsourced entries, as they look strongly like inferences to me. Before I nominate them, though, I wanted to hear what others have to say first. @Eirikr @Fish bowl @Chuterix @Lattermint @Poketalker @Kwékwlos @Mellohi! @TongcyDai Theknightwho (talk) 19:41, 1 July 2024 (UTC)


 * Also pinging.
 * Recently, for some new Yonaguni entries I create that source the reference of the original word, I tend to put main headword at hiragana (used in Dunanmunui Jiten). The alternative kanji however, is entirely inferred from etymology/semantics; feel free to remove them if you don't like it. Chuterix (talk) 20:14, 1 July 2024 (UTC)
 * Most Ryukyuan languages, except for Shuri, have little to no literary tradition. Hiragana would be best suited, since the kanji is meant to signify a possible Japanese cognate but not all etymologies are correct. Kwékwlos (talk) 21:38, 1 July 2024 (UTC)
 * Agreed with Kwekwlos. We should move all Ryukyuan entries to hiragana. For Shuri, kanji should only be an alternative spelling. Chuterix (talk) 21:48, 1 July 2024 (UTC)
 * IFF kanji spellings are used in texts written in those respective languages, then great, we should include those somewhere (whether as main or alt-spelling entries, I currently have no strong opinions). ‑‑ Eiríkr Útlendi │Tala við mig 22:22, 1 July 2024 (UTC)


 * I've expressed similar concerns at Beer Parlour (March) but do not have the knowledge to comment further. —Fish bowl (talk) 22:01, 1 July 2024 (UTC)
 * My thoughts on this are still the same:
 * "We should lemmatize at what native speakers have used the most, absent a standard orthography, regardless of if it seems inconsistent or 'ad-hoc'. Defective or variant orthographies are not specific to Ryukyuan, and in other cases, we list the variants as alternative forms with the 'standard' or most-common form as the lemma. (Or in the case of two differently-pronounced words represented by the same orthography, we disambiguate in the etymology + pronunciation sections)"
 * "For Okinawan in particular, there are several works written in mixed script (Kanji & kana), and it looks to be the traditional orthography as well, so I wouldn't support a move to solely kana, and definitely not the Latin script. The same level of research should be done for the other languages as well; if they are more-written in the Latin script or katakana [or hiragana], then shifts can be made, but the research needs to be done first."
 * The same applies here. I would highly recommend doing a deep dive into what speakers use most often. And again, I would not support a move of Okinawan entries to hiragana. AG202 (talk) 17:19, 3 July 2024 (UTC)
 * @AG202 I completely agree with you re Okinawan; I had hoped I'd made it clear that it's not in the scope of this thread, as I'm aware it has its own literary tradition that is best handled in the same way we handle Japanese. Theknightwho (talk) 20:49, 4 July 2024 (UTC)

Category:English arbitrarily coined terms
Should we have a category for words that were completely "made up" like, , or ? Searching "arbitrary formation" on the OED reveals many more results. (accepting suggestions if anyone has better ideas for a name)


 * Personally . Ioaxxere (talk) 21:29, 2 July 2024 (UTC)


 * Wouldn’t this just be “Category:English nonce terms”? — Sgconlaw (talk) 04:06, 4 July 2024 (UTC)
 * : Checking the contents of that category I see that very few of them would fit into my proposed category. Ioaxxere (talk) 05:21, 4 July 2024 (UTC)
 * in your view, what is a “completely made up” term and how does it differ from a nonce term? — Sgconlaw (talk) 10:14, 4 July 2024 (UTC)
 * ex nihilo vs nonce. Vininn126 (talk) 10:18, 4 July 2024 (UTC)
 * seems to me that “completely made up” terms are also “terms invented for the occasion”, so the former could quite happily be included in “English nonce terms” without the need for an additional category. — Sgconlaw (talk) 10:23, 4 July 2024 (UTC)
 * No they are not. Nonce terms are "made for a single occasion". One could argue that normal affixation could also relate to nonce terms, wherein the speaker realizes it's not fully "lexicalized" the way other words are, and they are not restricted to new stems. Ex nihilo is a new stem, it may be nonce, it may catch on and become fully lexicalized. Vininn126 (talk) 10:25, 4 July 2024 (UTC)


 * ‘Arbitrary’ isn't all that descriptive.
 * I'd suggest ‘ex nihilo coinages’. Nicodene (talk) 05:03, 4 July 2024 (UTC)
 * : How about "English terms coined ex nihilo"? Ioaxxere (talk) 05:21, 4 July 2024 (UTC)
 * Sounds good to me. Nicodene (talk) 05:30, 4 July 2024 (UTC)
 * Related, what do if only a part is ex nihilo, as in pharmacology, it turns out, is often? → ipamorelin and its whole suffix. Fay Freak (talk) 05:31, 4 July 2024 (UTC)

RQ for Rollbacker (and Patroller)
I'm not sure what the bar for these rights are, but I would like to request these tools as I believe they would be helpful tools on those days I end up watching RC for vandalism (which has been happening more frequently as of late). I will not rollback anything other than obvious vandalism and my primary usage of patroller would be to simply review un-patrolled edits. — B ABR ・talk 08:34, 3 July 2024 (UTC)
 * I nominated you in WT:WL. — Fenakhay ( حيطي · مساهماتي ) 15:58, 3 July 2024 (UTC)
 * Approved. Vininn126 (talk) 08:48, 4 July 2024 (UTC)

Gender Only, or Gender + Number for Nouns in Translation Tables?
I've noticed that many noun entries in translation tables are annotated with gender only, with no indication of number, though there is no specific guidance or policy provided for this particular more in documentation related to translation tables.

Should number indeed be left out of translation table entries, perhaps unless the number of the translated noun differs from the number of the original noun? On the other hand, the argument for including number, along with gender, in translation tables, would be that it provides the most possible context for a reader who is more unfamiliar with the language in question.

If the consensus is that number should only be included if it differs from the number of the original English entry, I would suggest this policy be made explicit either in the translation table "add translation" forms themselves, or in Wiktionary:Translations.

Hermes Thrice Great (talk) 10:01, 3 July 2024 (UTC)
 * I wouldn't support a policy of routinely including number. The point as I see it of including gender is that (for many commonly used languages) gender is lexically specific and relatively arbitrary relative to the meaning and potentially also the form of the word. Number is usually non-arbitrary and semantically transparent. I would agree with a policy of including number only when it differs from English, as in "meubles (fr) m pl" at furniture.--Urszag (talk) 05:42, 6 July 2024 (UTC)
 * My impression is that by far the most common situation in noun translations tables is "English singular noun is translated into another language as Other-Language singular noun": I see no reason to indicate number in that case, since it's the 'default'. Whether to indicate it when the English and foreign-language numbers are plural (which is different from the default, but matches) is debatable. Obviously, it would be helpful to indicate where the English vs foreign-language numbers differ, as Urszag says. - -sche (discuss) 21:09, 7 July 2024 (UTC)

Full entries for alternative forms in Chinese
Right now, etymology 2 of soft redirects to, while under etymology 3 of  is a full entry containing the pronunciation of Min  in the different varieties of Min. I was wondering if a full entry for the Min word for "foot" at  is allowed, since 漢語方音字彙 lists the readings of  under the entry for  as. What are the rules regarding entries for alternative forms in Chinese?

As a side note, perhaps should be adopted as the main form for the Min word for "foot" instead of, which we currently use. is used only in Taiwan sources, and as far as I know, is used only for Hokkien. On the other hand, is used in Mainland China publications for all varieties of Min. RcAlex36 (talk) 12:40, 3 July 2024 (UTC)


 * I would argue that zh-see should only be used for orthographic variants that one would consider as representing the same underlying character, so things like traditional/simplified or ; those that involve intermediate steps which cannot simply be summarised as "orthographic variant" (e.g. modern, modern ings for the character pronunciation, romanisations, puns) would be a full entry and use alt form (or preferably a template that specifies the type of alt form). Often the latter type would require (or already have) its own set of attestation separate from the main entry, so it would be more convenient to have a definition line (as in the alt form) where quotes can be added to.
 * Some examples: and  redirecting to ;  redirecting to  will continue to use zh-see, while  for ;  for ;  or  for ;  for  will use alt form. – wpi (talk) 14:39, 3 July 2024 (UTC)
 * I agree with the general intuition from wpi. I also would like to add that should only be used when it can entirely replace a whole etymology section. Any proper subset of an etymology section, such as restrictions to certain pronunciations, definitions, and/or lects, should use  for sure. — justin(r)leung { (t...) 14:46, 3 July 2024 (UTC)

Is it ever necessary to use etymon in a redirect?
I'm referring to pages that look like this:

Here are the disadvantages:
 * Harder to keep follow an etymon chain as you have to check both the redirect and the redirect target to find an etymon call.
 * Worse performance, as the template has to search both the redirect and the redirect target for the parent.
 * A *lot* of corner cases. Say we have en on  and en on  . Should this be allowed? It has to be, because otherwise you can never add etymon on a page until verifying that the same ID isn't already used on any of its redirects, which is obviously inconvenient. But if we do that, now , when clicked, takes you to the wrong place!

Thus, unless there's a very good reason for this to be supported, I would like to remove all etymon uses from redirects.

Pinging who pushed for this to be supported. Ioaxxere (talk) 14:16, 3 July 2024 (UTC)


 * @Ioaxxere I didn't push for this to be supported - I just did the implementation, so that pre-existing attempts to do this weren't completely broken. Theknightwho (talk) 14:21, 3 July 2024 (UTC)
 * : I say "pushed" because you called it the "most sensible solution". But maybe I'm misinterpreting what you meant. Ioaxxere (talk) 16:03, 3 July 2024 (UTC)
 * I don't think this is optimal - I think allowing for alt forms in the title of the pointed-to page would be better. Vininn126 (talk) 14:29, 3 July 2024 (UTC)

categorizing modern English verbs as "class 4 strong verbs" etc
At Requests for cleanup, User:Mahagaja and I questioned whether it makes sense to be presenting modern English verbs as still having the class system they had back in PIE. Many verbs which were historically one class now behave like another class, or class distinctiveness has been lost, a lot has changed over the last few thousand years. I suggested that if anyone wants an etymology category, renaming the cats like "English verbs derived from PIE PGmc class X verbs" would make the intended(?) purpose and scope clearer, but alternatively it might make more sense to just not be categorizing this. What do you think? - -sche (discuss) 16:13, 3 July 2024 (UTC)


 * The strong verb class system only dates back to Proto-Germanic, not Proto-Indo-European, AFAIK. I would prefer not categorizing them at all, but if we do, then yes, "derived from Proto-Germanic class ## verbs" makes more sense than calling them class ## verbs synchronically. —Mahāgaja · talk 16:18, 3 July 2024 (UTC)
 * (That's its own issue, then, because the category descriptions are defining themselves in terms of the PIE conditions of the words, with no obvious reference to PGmc.) - -sche (discuss) 16:23, 3 July 2024 (UTC)
 * I think the category descriptions are supposed to be giving background information, not defining criteria (even if that's not clear from how they are written).--Urszag (talk) 17:01, 3 July 2024 (UTC)
 * IMO English verbs should not be categorized according to the Proto-Germanic strong verb system because most of the classes no longer have any coherence in modern English. (German is a different story. We still categorize modern German verbs according to this system because most of the classes have not lost their coherence in modern German.) Having this be an etymology category (reflecting what language? Middle English, Old English, Proto-West-Germanic, ...?) doesn't make a lot of sense IMO. Benwing2 (talk) 22:28, 3 July 2024 (UTC)
 * I think it makes sense if all the verbs in the category are irregular due to still behaving like they're a member of a particular class, but it's probably better to give them a different name, as "English class 4 strong verbs" implies this is a common/agreed upon way of classifying English verbs. Theknightwho (talk) 20:43, 4 July 2024 (UTC)
 * I read somewhere that someone tried to group English irregular verbs into classes and came up with 26 of them. Needless to say, there's no standard way of forming such classes; dictionaries just list the principal parts. Benwing2 (talk) 20:59, 4 July 2024 (UTC)

What defines "transitive"?
I am in the process of converting indtr to use +obj, but indtr seems to play fast and loose with the "transitive" label so I'd like to get a sense of what people think "transitive" means. In my book, a "transitive" verb takes a direct object, and a verb whose only object is taken through a preposition is not a transitive verb. However, indtr labels such usages as transitive with  or similar. (Note that indtr doesn't actually categorize such verbs in e.g. CAT:Portuguese transitive verbs due to the way it implements the labels; I'm not sure if that was intended, though.) My questions are: I should add that Italian generally follows the above rules, and it's useful to do so because all non-reflexive transitive verbs (according to the above definitions) take as an auxiliary, but intransitive verbs can take  or. I think Spanish does too, and Italian and especially Spanish make little use of indtr compared with Portuguese and French. Benwing2 (talk) 22:23, 3 July 2024 (UTC)
 * 1) Do we agree that a verb usage like  is intransitive, even though it's translated in English using a transitive verb? (IMO yes.)
 * 2) If so, should we label the verb using pt, thereby categorizing it into CAT:Portuguese intransitive verbs? (IMO yes.)
 * 3) What about verbs like  (which takes a dative object) in languages like Latin that have a case system? Should these be labeled as intransitive? (IMO yes. This is what Gaffiot does, for example.)
 * From what I figured when I specifically researched this question, in order to write government labels, transitivity depends on semantic properties and thus can be mediated through adpositions, so I am pleased to see that the author of the template indtr, which I have not known yet, due to generally editing other languages, understood it the same way. Many reference works dance around the mines when defining the concept, of course, particularly Wikipedia, whose manifold authors in one article have different understandings without realizing, giving false . The at least was and is pretty explicit about the optional restriction to only direct objects. Als transitiv werden … Verben bezeichnet, die kein (oder, je nach Definition, kein direktes) Objekt haben. in the introduction and then a whole section about “conceptual (or terminology) variants” Fay Freak (talk) 23:25, 3 July 2024 (UTC)
 * As a consequence, I disagree with your first conclusion.
 * Labels langname and langname seem to have the purpose of disambiguating English equivalents, so one would have to reject the idea that they should categorize at all, were one not to know that other editors use the labels with different focus. In other words, the labels are polysemous, contrary to what we, who we describe language, trapped in its linearity, use to intuit – one reason why I avoid langname and langname completely, preferring to specify government by, formerly and in its new version, and use unambiguous verbose glosses. Fay Freak (talk) 23:38, 3 July 2024 (UTC)
 * The simplest criterion and the one I think that is most commonly used by English speakers is that "transitive" means "takes a direct object", which excludes verbs that take prepositional phrases as their complements. I guess there could be unclear edge cases in some languages like the use in Spanish of "personal a" for animate patients of otherwise transitive verbs. The necessity of accusative case isn't entirely clear to me: I believe it is traditionally treated as diagnostic in Latin, but it seems like there might be a tradition in Polish of recognizing some verbs that take a genitive or instrumental complement as transitive if they can be passivized.--Urszag (talk) 03:03, 4 July 2024 (UTC)
 * There is a great deal of sloppiness in labeling English phrasal verb senses as transitive or intransitive. I think it derives from including full definitions that are arguable SoP in the phrasal-verb L2s. DCDuring (talk) 18:54, 4 July 2024 (UTC)
 * I'm opposed to calling any verb which takes a complement (be it a direct object - "verbes transitifs directs" in French - or a prepositional object - "verbes transitifs indirects") intransitive, though I agree it's not satisfactory to call them all transitive and leave it at that. Why not use "prepositional transitive" when needed? PUC – 18:20, 4 July 2024 (UTC)
 * @User:PUC I assume that your opposition does not extend to all languages. DCDuring (talk) 18:54, 4 July 2024 (UTC)
 * @PUC Concepts like "indirect transitive" appear to be Romance-specific. Benwing2 (talk) 19:01, 4 July 2024 (UTC)
 * And even then, not found in all Romance languages. So I think it's much better to just call them intransitive; the fact that there is a preposition that can (and often is not) attached is clear from the use of +obj. Benwing2 (talk) 19:02, 4 July 2024 (UTC)
 * To clarify, I have so far found the concept of "indirect transitive" only in the TLFi French dictionary and Michaelis Portuguese dictionary. It is not found in any other Portuguese dictionary, nor in any Spanish, Galician or Catalan dictionary that I have consulted. The Spanish, Galician or Catalan dictionaries label verbs as transitive only if they take a direct object; the Priberam and Infopedia Portuguese dictionaries are sloppy about the use of the labels "transitive" and "intransitive", sometimes calling verbs that only take a prepositional object "transitive" and sometimes "intransitive". The policy I'm following is that a verb that takes a prepositional object is transitive if and only if it also takes a transitive object; hence "to base (something in something else)" is transitive, but "to confide (in someone)" is intransitive. Benwing2 (talk) 19:42, 4 July 2024 (UTC)
 * I'm getting the impression we may need to adopt various definitions of transitive per-language. Vininn126 (talk) 19:02, 4 July 2024 (UTC)
 * In Polish grammars a requirement is generally that it can form the passive. Some verbs can take "accusative" arguments but cannot form the passive, and most scholars analyze the accusative argument as more of an adverbial. Vininn126 (talk) 18:22, 4 July 2024 (UTC)
 * @Vininn126 Are you referring to what are often called "cognate accusatives"? Benwing2 (talk) 19:04, 4 July 2024 (UTC)
 * @Benwing2 No, remember Talk:przejść? Vininn126 (talk) 19:10, 4 July 2024 (UTC)
 * @Vininn126 Hmm, can you give a sentence with one of these adverbial accusatives in them? I'm having a hard time understanding what's being referred to. Benwing2 (talk) 19:12, 4 July 2024 (UTC)
 * here's an article.
 * Basically people might create nonce formations like jezioro zostało obeszłe or something but they're highly non-grammatical, despite being able to say "Jaś obszedł jezioro". Vininn126 (talk) 19:13, 4 July 2024 (UTC)
 * I think I recall this happening in Russian, too, where some transitive verbs don't have a passive participle. Zaliznyak labels them (depending on the verb) as either missing the passive participle entirely or as having a "rare and awkward" passive participle (which in practice won't ever be encountered). There are also a very small number of intransitive verbs that do have a passive participle; I think these are verbs that for whatever reason use an object in some other case but sound transitive. It's also interesting to me that the article you linked mentions that Polish in general avoids the passive, unlike German; this is like Spanish and unlike English. Benwing2 (talk) 19:51, 4 July 2024 (UTC)

"Encyclopedic" as a deletion reason
(to be archived at Talk:Sticks Nix Hick Pix) I've forked this from that discussion because it concerns broader issues and was starting to take it over. Chuck Entz (talk) 17:56, 5 July 2024 (UTC)

You're about the only one who's actually given any substantive reasons. Inqil and Fay gave no reasons at all, Sgconlaw said "we don't have these" but didn't say way, and Fenakhay simply said "encyclopedic" without saying encyclopedic in what respect. When I talk of a "false dichotomy", what I mean is a false dichotomy between dictionary definition and encyclopedia entry. The idea that there is some bright, hard-and-fast line between dictionary definition and encyclopedia entry is fantasy. There are Wikipedia articles about parts of speech and Wiktionary entries about places and occasionally events too. Furthermore, the term "encyclopedic" has now become a catch-all excuse for deleting or revising almost anything. One frequent usage I've seen of "encyclopedic" is to claim that an entry is too detailed, but that's clearly NOT the case here. Purplebackpack89 16:25, 5 July 2024 (UTC)
 * Well it is true that many encyclopedic entries can be lexicographical and vice versa, however when we say that a term is encyclopedic, it means it is purely non-lexicographical and has zero rationale for inclusion— unlike those tons of encyclopedic entries we keep such as toponyms, anthroponyms, and any abbreviations. Inqilābī 17:16, 5 July 2024 (UTC)
 * a) If by encyclopedic you meant "non-lexicographical", you should have said "non-lexicographical" at the outset. And "non-lexicographical" isn't much better because it is also an amorphous idea. Purple</b><b style="color:#991C99">back</b><b style="color:#C3C">pack</b><b style="color:#FB0">89</b></b> 17:34, 5 July 2024 (UTC)
 * (After edit conflict) Just because there isn't a perfect bright line between the two concepts doesn't mean either is invalid. As I've explained to people in the past: an encyclopedia is about things: ideas, events, people, places and things. A dictionary is about the words, phrases, etc. used to refer to those as words, phrases, etc.
 * Yes, Wikipedia has articles about parts of speech- but Wiktionary doesn't (not in mainspace, anyway). Part of speech is information about the terms, that we give in the entries for them. This is illustrated by the fact that definitions for "verb" as a part of speech are under a "Noun" part of speech header, since the word "verb" is a noun.
 * Likewise, we don't have entries for things like, even though we have lots of entries for ethnic slurs.
 * There's overlap between an encyclopedia and a dictionary as far as definitions, because they have to be clear about what the terms refer to and thus give some of the same information that an encyclopedia article contains. There's also overlap in encyclopedia articles, because they often contain information about the names and terminology used for the article subjects. Still, overlap isn't identity.
 * Of course, whether something is encyclopedic or not is sometimes not clear- but that just means we need to discuss it. Also, a wiki is a community that decides things via consensus. All of the rules you cite were originally arrived at by consensus. Right or wrong, your opinions are just your personal opinions unless there is a consensus that agrees with them. Chuck Entz (talk) 18:57, 5 July 2024 (UTC)
 * I think you've actually acquiesced to the balance of what I've said.
 * And if there's a lack of clarity of the the term "encyclopedic" (and it's pretty clear there is!), we need to tighten the language. <b style="font-family:Verdana"><b style="color:#3A003A">Pur</b><b style="color:#800080">ple</b><b style="color:#991C99">back</b><b style="color:#C3C">pack</b><b style="color:#FB0">89</b></b> 20:14, 5 July 2024 (UTC)
 * I think this is a good opportunity to clarify "Criteria for inclusion", which currently states:

Care should be taken so that entries do not become encyclopedic in nature; if this happens, such content should be moved to Wikipedia, but the dictionary entry itself should be kept.

Wiktionary articles are about words, not about people or places. Articles about the specific places and people belong in Wikipedia.


 * The first sentence seems to be addressing that point that a definition (for example, for a scientific concept like ) should not become like a Wikipedia entry in length. Thus, the entry itself should remain but the encyclopedic information should be moved to Wikipedia (if it isn't already there).
 * The second sentence comes closer to addressing the general issue about when an entry is "encyclopedic" and so is not sufficiently lexical for inclusion in the dictionary, but it does not explain very much. It needs to be read in conjunction with "What Wiktionary is not", which states: "Wiktionary is not an encyclopedia, a genealogy database, or an atlas; that is, it is not an in-depth collection of factual information, or of data about places and people. Encyclopedic information should be placed in our sister project, Wikipedia." We should discuss whether this makes it clear enough to determine when a term is "encyclopedic" and so inherently unsuitable for the dictionary.
 * Following the discussion here, we should have a formal vote to amend to clarify the CFI. — Sgconlaw (talk) 18:12, 5 July 2024 (UTC)

The general idea of the RfD and now of this post is that the word "Encyclopedic" is thrown around way too casually as a catch-all for everything. The secondary concern is attempts to establish a bright line between encyclopedia entry and dictionary definition are folly. There's just too many similarities and too much of a gray area. Let's take a more specific look at the two clauses Sgconlaw references. I believe both are in need of some revision:
 * 1) The first one needs to use greater precision than the catch-all "Encyclopedic".  Instead of saying, "entries do not become encyclopedic in nature", perhaps a better phraseology might be, "entries and definitions do not become overly lengthy or detailed".
 * 2) Given my druthers, I'd dispense with the second, or reword it, because there are already many exceptions and need to be more.  There is a long list of places that are acceptable entries or definitions.  If a person or a fictional character becomes genericized, they are permitted a definition.  There are also nicknames for individual people or groups of people.

Furthermore, there may need to be guidance at RfD that simply staying "Encyclopedic" isn't a thorough enough rationale for deletion, and greater specificity is required. <b style="font-family:Verdana"><b style="color:#3A003A">Pur</b><b style="color:#800080">ple</b><b style="color:#991C99">back</b><b style="color:#C3C">pack</b><b style="color:#FB0">89</b></b> 18:32, 5 July 2024 (UTC)
 * If we do that, could we also legislate on bare "Keep" votes without rationale? PUC – 19:58, 5 July 2024 (UTC)
 * When someone says keep or delete without any further statement, it generally means the rationale is the same as that of the previous voters in the post. Inqilābī 20:37, 7 July 2024 (UTC)
 * Purple, may I suggest reading encyclopedia vs dictionary (on Wikipedia)? Just because you mentioned being unsure what type of content is encyclopedic material and what type of content is dictionary material. Hope that helps clear things up.
 * That being said, even putting aside it being encyclopedic material, it fails CFI as the term is SOP. The general expectation for multi-word terms is that the words put together have a different meaning than they do apart, but that doesn't seem to be the case here. The definition is literally just every word that makes up the term, hence it's SOP. And, while we do sometimes make exceptions to certain CFI policies, we do so when there is agreement that the terms would be helpful for translations; Such an exception wouldn't apply here, there isn't really any translation based usage for this term that I can think of. So, no hard feelings Purple, but this does not meet our CFI, even if you challenged the current definition of "encyclopedic". — B ABR ・talk 01:16, 6 July 2024 (UTC)
 * I think most of what you've said belongs at the RfD discussion as it focuses on the specific rather than the general. <b style="font-family:Verdana"><b style="color:#3A003A">Pur</b><b style="color:#800080">ple</b><b style="color:#991C99">back</b><b style="color:#C3C">pack</b><b style="color:#FB0">89</b></b> 14:16, 10 July 2024 (UTC)

Moratorium on editing other languages' etymology sections for the purpose of English etymology trees
I'd like to request a moratorium on the editing of other languages' etymology sections for the purpose of populating English etymology trees (outside of adding based on the already existing etymology). This has led to several conflicts and cleanups due to English editors wanting to display an etymology tree, haphazardly editing another language's etymology and causing misinformation to spread for other editors to clean up. It's been brought up to such users several times (primarily on Discord), but it looks like the problem has been continuing. As such, I'm bringing it to BP for a wider audience.

Whether it be the creation of problematic PIE reconstructions as detailed at, the editing of Spanish based on a misreading of an already faulty source for the tree at English , the creation of  for nonexistent Middle Irish entries as stated at , or the editing of Welsh entries for the purpose of the tree in English  by an editor with very little experience, it's been more clear to me that certain editors are more focused on the gamification aspect of trees rather than propagating pertinent and accurate information. See also:.

This was mainly sparked by the edit at because I don't even know where to begin to fix it, and it doesn't seem like  allows a derivation from a parent language with no attested term. I'm tired at this point of bringing this up on an individual basis to users and having to play cleanup, and had I known it would've exploded like this I would've voted oppose at the vote instead of abstain until this was made more clear. It's gotten out of hand. AG202 (talk) 00:49, 6 July 2024 (UTC)


 * 100%. The fact that etymon seems to be in large part used to add "cool" trees to terms like United States of America, pneumonoultramicroscopicsilicovolcanoconiosis and such makes it clear that too many people view this as a game. At the time this template was being created, I had a bad feeling about the design and usage and expressed my concerns; unfortunately these concerns appear to be borne out. Benwing2 (talk) 02:48, 6 July 2024 (UTC)
 * Being entirely fair, a lot of this seems to be the work of one editor (@Akaibu), but I agree with @AG202: I have removed etymon from, as the template call was essentially malformed by not even accounting for mutations, and I don't feel I'm in a position to correct it. While I'm all in favour of having etymology trees, I think we shouldn't be afraid to simply revert its addition to an entry if an editor is completely inexperienced with a given language, just as we would with any other part of an etymology section. There's no big rush here; the trees will get added over time, but it has to be done by editors who know what they're doing. Theknightwho (talk) 04:08, 6 July 2024 (UTC)
 * I really wish it were mostly just one user. And the reason I've brought it to light is because it's led to mini edit wars as with the revision history at þeir that only ended when I brought it to Discord to remind folks yet again to not edit languages they're not familiar with. And then I myself had to go find and revert all the tree additions. AG202 (talk) 04:15, 6 July 2024 (UTC)
 * I will add that I haven't taken a close look at the etymon syntax but from what I've seen it needs an overhaul. This implies we should not be adding it all over the place yet because all the uses will have to be fixed by bot. Benwing2 (talk) 04:43, 6 July 2024 (UTC)
 * Just for clarity's sake, after posting the above image, I was (inadvertently) pinged by @Akaibu on Discord in the English channel who stated:
 * >I really wish it were mostly just one user. ~ @AG202
 * continues to bitch and moan about something that was still a single user's doing
 * This is just highly inappropriate. They've since replied that it was a joke about "[themselves] myself being the cause of the problems" and "saying one deserves more credit for causing trouble", but I still do not find it appropriate. This adds to their other messages on Discord pushing back against simple asks to not edit languages that they're not knowledgeable about (on multiple instances), along with misunderstanding basic tenants about how this project works. For a user with under 500 edits (a large chunk related to this effort), I'm concerned about constructive editing for the future. AG202 (talk) 04:45, 6 July 2024 (UTC)
 * , and your statement that "certain editors are more focused on the gamification aspect of trees rather than propagating pertinent and accurate information" is spot on. PUC – 08:05, 6 July 2024 (UTC)
 * . I do feel that people just wanna use the new tool wherever, without checking the results.
 * (Also, should we gamify making good etymologies?) CitationsFreak (talk) 09:34, 6 July 2024 (UTC)
 * . Going to the first redlink or the first place we are sure is fine. It's better to be slow and sure than fast and wrong. It's better to make a request somewhere or discuss it at WT:ES than anything. Vininn126 (talk) 09:41, 6 July 2024 (UTC)
 * . --  02:06, 7 July 2024 (UTC)
 * . Theknightwho (talk) 02:23, 7 July 2024 (UTC)

Criteria for "...terms inherited from..." categories
Related to the discussion above about PIE root categories, what kinds of bounds do we want on the membership of categories like Category:Latin terms inherited from Proto-Italic? I noticed this now includes words like solstitium and tessellatus, presumably because of the etymology trees. While I don't see an issue with putting these in Category:Latin terms derived from Proto-Indo-European, I don't think compound words that were put together after the ancestor language should go in this kind of category, much less words like tessellatus where only the suffixes are inherited, and the base is a borrowing. For simplicity, I think it would be best not to have words categorized as "inherited" unless they are inherited from only one etymon in the relevant ancestor language. would you be able to clarify if this is intended behavior, or a bug? Urszag (talk) 01:29, 6 July 2024 (UTC)


 * the two entries you linked were using the template incorrectly which is what caused the unwanted categories to be added. I've gone ahead and fixed the entries. Ioaxxere (talk) 01:36, 6 July 2024 (UTC)
 * Thanks for fixing my mistake. I hadn't realized it was erroneous to use "from" for affixed words, although that makes sense given the analogy to Template:from.--Urszag (talk) 01:39, 6 July 2024 (UTC)
 * What would be the correct derivation keyword to use for univerbations or multi-word phrases such as (or, if they don't end up being forbidden, cases like United States of America, LASER etc, which are now in "English terms inherited from Proto-West Germanic", "English terms inherited from Middle English", etc.)? I noticed the same issue here ("ab ante" being wrongly placed in "Latin terms inherited from Proto-Italic"), but wasn't sure about the semantically correct way to fix it. Should they be equated to compounds and marked with "af" (despite not containing any affixes)? I don't quite see in what circumstances the current behavior of "from" with multi-word etymologies will be appropriate, so maybe it should trigger an error message?--Urszag (talk) 04:37, 6 July 2024 (UTC)
 * Yes, compounds are . Maybe the name is a little misleading but it's explained in the documentation. Both of the examples you listed were added by  who I hope can resolve the issue. Switching   and   still results in a valid etymology in this case (just not one that matches reality) so it's hard to automatically judge when someone has done it by accident. Ioaxxere (talk) 14:27, 6 July 2024 (UTC)
 * I don't understand yet what the hypothetically valid alternative etymology would be in cases like this. Are there any concrete examples of entries derived from more than one etymon in the same language where it would be correct to use "from" rather than "af"? Seeing an example would help me understand better why it's necessary to distinguish the two keywords and their behaviors in this context. (I tried to look at examples of Template:from, but it seems to be barely used judging from the "What links here" tool.) Would "from" be reserved for cases like "a word used to have multiple forms that then merged into one" (but wouldn't that be more of a case for "influence"?) or "a term/phrase was derived from modification of a preexisting phrase" (but wouldn't that call for syntax like "from|en>united states of America...", like at religion of piss)?--Urszag (talk) 15:04, 6 July 2024 (UTC)
 * Yes, you're correct. One example of  with more than one etymon would be  which might be written  . Ioaxxere (talk) 15:38, 6 July 2024 (UTC)
 * Thanks. While I think I understand this now, I think the way it currently works is unintuitive and is likely to lead to a lot of cases of "from" being used in contexts where it isn't appropriate according to these criteria, and where it will create categorization errors. Making it the default and describing it as "unspecified derivation type" doesn't help: "from" sounds a lot more generic than it really is, in contrast to "af" which sounds more specific than it really is. E.g. Reconstruction:Latin/ad vix was created with , where the absence of a keyword apparently makes it be treated as "from", which inaccurately puts this entry into Category:Latin terms inherited from Proto-Italic.


 * Also, even in cases like "cytotech", would it really be accurate to describe this term as "inherited from Middle English" in a hypothetical situation where "cytotechnologist" and "cytotechnician" are inherited from Middle English, but the shortened form arose only in Modern English?


 * If the plan is to keep the current behavior of "from" with regard to inheritance categories the same, what would you think of making "af" instead the default when there is more than one etymon, all of which are in the same language as the entry?--Urszag (talk) 12:37, 9 July 2024 (UTC)

merge "pronominal" into "reflexive"
We have two labels and  that are supposed to reflect a difference made in the linguistic tradition of certain Romance languages, whereby a "pronominal" verb is a reflexive verb whose meaning isn't obviously reflexive. Unfortunately in practice there's absolutely no consistency in how these labels are used, and it doesn't reflect anything in the actual syntax of the verbs, but only in an extremely subjective judgment as to whether a given sense has a sufficiently "reflexive" meaning to it. On top of this, the actual display of the labels doesn't do anything but muddy the waters: displays as reflexive while  displays as takes a reflexive verb. Furthermore, the label doesn't seem to be used outside certain Romance languages even though there are several other languages (e.g. Slavic languages) that have a similar concept of reflexive verbs that may or may not be semantically reflexive. Finally, whether a verb is semantically as well as syntactically reflexive should be obvious from the specified meaning of the verb, i.e. the label adds absolutely nothing of value to the entry beyond what  would do. So given all this I propose simply bot-replacing with. Benwing2 (talk) 02:44, 6 July 2024 (UTC)
 * I'm not sure about this. I agree the distinction doesn't seem particularly necessary in terms of usage label text. This blog post makes a four-way distinction between reflexive, reciprocal, idiomatic pronominal, and essentially pronominal verbs. The last category seems to be fairly small, and it is possible to characterize it relatively unambiguously in terms of these verbs normally not occurring without a reflexive pronoun (compare Latin deponent verbs, which can be identified by the absence of attested active-morphology forms in most parts of their paradigm). It looks like currently, we have separately named categories for Category:French pronominal verbs, Category:French reflexive verbs, Category:French reciprocal verbs, although the first contains only one verb. We seem to already treat these verbs differently by including the pronoun "se" in the entry name, at least in the case of se barrer and a number of verbs in Category:French reflexive verbs, such as se passionner, se casser, se pouvoir; what's our policy on this? We have essentially duplicated information about the reflexive sense at passionner and pouvoir but not at casser.--Urszag (talk) 04:58, 6 July 2024 (UTC)
 * @Urszag But this isn't at all how the label 'pronominal' is used here. It is used facultatively for reflexive senses of verbs (including those that are also used non-reflexively) that are idiomatic, that's all. Benwing2 (talk) 05:13, 6 July 2024 (UTC)
 * BTW the policy for Spanish and Portuguese is that verbs are lemmatized with the reflexive pronoun only if they don't occur non-reflexively. This is different from the practice with Italian, which strictly separates reflexive and non-reflexive verbs into different lemmas. Benwing2 (talk) 05:14, 6 July 2024 (UTC)
 * French appears to mostly follow the Spanish and Portuguese practice. Benwing2 (talk) 05:15, 6 July 2024 (UTC)
 * Yes, I see that the current usage of the labels doesn't follow this or any other clear distinction (there are even some cases like se la péter that have both labels), so a bot replacement seems like it wouldn't remove information. I don't oppose that, but it seems like an opportunity to consider the question of whether it is possible to make a non-subjective distinction between the concept of pronominal and reflexive verbs, and to what extent our entries should mark this or leave them undistinguished. Since labels are sometimes used to add words to categories, that made me think about the categorization of these verbs, but it seems like doesn't actually even place a verb in Category:French pronominal verbs. Is there any easy way to see which pages use a certain label? I just noticed that  is used not only in the lb template but also in other templates such as Template:indtr.--Urszag (talk) 05:35, 6 July 2024 (UTC)
 * @Urszag indtr underlyingly uses the label machinery to handle things like and other parameters preceded by a dot. You can see which pages use a given label by visiting Special:WhatLinksHere/Wiktionary:Tracking/labels/label/pronominal or a language-specific subcategory such as Special:WhatLinksHere/Wiktionary:Tracking/labels/label/pronominal/fr for French. Note that I'm in the process of converting all uses of indtr to a combination of lb and +obj, which is why I'm running into this issue. Benwing2 (talk) 05:41, 6 July 2024 (UTC)
 * @Urszag I am also finding various examples e.g. Portuguese dedicar where "pronominal" is used even with explicitly reflexive meanings. Benwing2 (talk) 03:13, 9 July 2024 (UTC)
 * merging. In my experience "reflexive" is simply the term used in English-based learning materials where Romance languages use "pronominal". You could distinguish between the different functions of these verbs that Urszag listed, but I imagine none of the editors adding labels to these verbs have those distinctions in mind. They are most likely just using the terminology of their native language. Ultimateria (talk) 08:10, 9 July 2024 (UTC)

where does Medieval Latin begin?
This came up in an WT:RFDO topic. I'd like to establish clearly where Medieval Latin begins, so we can determine whether categories like CAT:Proto-West Germanic terms borrowed from Medieval Latin are legitimate, or should be emptied by fixing the terms in it to refer to Late Latin, Vulgar Latin or some other variety. AFAIK Medieval Latin begins no earlier than 600 AD; anything prior is Late Latin. User:Theknightwho and User:Nicodene agree with me, but User:Victar claims that Medieval Latin begins in the 4th century AD with Christian writers such as Jerome. What's the consensus here? Benwing2 (talk) 04:44, 7 July 2024 (UTC)


 * ‘Late antiquity extends roughly from 200 to 600, and the grammarians active during this period are often known as the Late Latin grammarians [...] The early Middle Ages (600—800) was characterized by the need to study Latin as a foreign language [...]’ - Mantello & Rigg (1996), Medieval Latin: An introduction and bibliographical guide, page 288.
 * Nicodene (talk) 05:23, 7 July 2024 (UTC)
 * I would not expect it to be used of Latin earlier than 500 AD (or 476 if we use historical events as a marker). The Dictionary of Medieval Latin from British Sources apparently focuses on texts from between 540-1600.--Urszag (talk) 09:12, 7 July 2024 (UTC)
 * What Nicodene and Urszag said. From the Early Middle Ages; for me  is a marker, himself Late Latin. The 4th century even in Christian writers is clearly far from Medieval. It is bizarre to view as as Late Latin, though the so-called Church Fathers be all at fault for . This is the same fallacy as calling the Qurʔān Classical Arabic only because it is the basis of Classical Arabic. Fay Freak (talk) 09:40, 7 July 2024 (UTC)
 * I don't really have that much of a dog in this, but this is from xxi: "[M]edieval Latin, a rather generic designation for Latin of the third century AD and later. (The cutoff date between Latin and medieval Latin follows that of the Oxford Latin Dictionary)". Personally, I also find this early, but 7th century seem quite late. If one used the fall of the Roman Empire, that would be end of the 5th century, and the works of Boethius would be the start of the 6th century. -- 05:07, 8 July 2024 (UTC)
 * Quoting what @Nicodene said in response to this in the other thread: :::::: The Oxford Latin Dictionary set an approximate cut-off of 200 AD for the end of Classical Latin (the date I use as well), not the start of 'Medieval Latin'. I hate to say it, but the authors of the EIEC are simply mistaken. Benwing2 (talk) 05:11, 8 July 2024 (UTC)
 * Also, to repeat (and add to) what I said: if what Victar is claiming is true, it either leaves no room for Late Latin, or means that we have to start treating Late Latin as a period of Medieval Latin; neither of which make much sense to me. Theknightwho (talk) 05:27, 8 July 2024 (UTC)
 * TKW, "Victar is claiming is true"? These aren't my claims, and I was citing Urszag and Fay Freak. Please see their replies above. 14, going off of Weiss, claims Late Latin spans 3rd~4th c. to 5~6th c., leaving Medieval Latin to begin in the 5~6th century. That would allow for ML borrowings into 5th century Frankish/Proto-West Germanic, as well as Proto-Slavic. -- 05:34, 8 July 2024 (UTC)
 * I think that's pushing it. Benwing2 (talk) 05:54, 8 July 2024 (UTC)
 * And by that you mean to say you think de Vaan's/Weiss' dates are wrong? -- 05:56, 8 July 2024 (UTC)
 * If "Late Latin spans 3rd~4th c. to 5~6th c", then Medieval Latin should start 6th~7th century, not 5~6th century. It's pushing it to infer from Late Latin having a 5th-6th century ending date that Medieval Latin can start as early as c 425 AD. That seems exceedingly unlikely to me. Benwing2 (talk) 05:59, 8 July 2024 (UTC)
 * "then Medieval Latin should start 6th~7th century": No it wouldn't. See https://pasteboard.co/4tt1HXHqRvUq.png from the EDL. -- 06:03, 8 July 2024 (UTC)
 * I take c 5th/6th century to mean c 500 AD. You can't take it to mean a 200 year range and arbitrarily pick the earliest possible date as the beginning of Medieval Latin. Benwing2 (talk) 06:06, 8 July 2024 (UTC)
 * In any case, I think you'll have a hard time getting consensus on a date for Medieval Latin before 500 AD at the earliest, and you're kinda tilting at windmills trying to do so. Benwing2 (talk) 06:08, 8 July 2024 (UTC)
 * That shows Late Latin lasting into the 5th~6th c., as we've been been saying.
 * Also there really is no calling anything prior to 476 (at the earliest) 'medieval' in any sense. Nicodene (talk) 06:12, 8 July 2024 (UTC)
 * Nicodene, in Benwing's opening statement it is claiming the 7th century as the start of Medieval Latin. I am fine with a 5th~6th century start to ML, which still allows for some very late PWG and SL borrowings. -- 06:16, 8 July 2024 (UTC)
 * As I said, you're trying to impose an artificially early date on Medieval Latin so you can borrow from Medieval Latin into PWG. I don't buy it. PWG is < 500 AD, Medieval Latin is > 500 AD, hence no overlap. Benwing2 (talk) 06:25, 8 July 2024 (UTC)
 * And you keep trying to impose some finite date, when it's actually porously 5th~6th century. The end of PWG itself too is vague, and probably better also labeled 5th~6th century, as many scholars would call the 6th century still Frankish.
 * In the end, it really doesn't matter. If all those entries on CAT:Proto-Slavic terms derived from Medieval Latin and CAT:Proto-West Germanic terms borrowed from Medieval Latin where changed to Vulgar or Late Latin, it would be of little consequence. You came at me hot, though, and so I'm just giving my understanding of the scholarship on the issue. -- 07:33, 8 July 2024 (UTC)
 * Specialists generally place the cutoff in the sixth century AD (beginning, end, or somewhere in between) give or take a few decades. The cutoff is often tied to the death of a scholar, for instance Boethius or even more so Isidore of Seville. The latter lived to see the last gasps of the old Roman order. Nicodene (talk) 08:29, 8 July 2024 (UTC)
 * I have to agree that anything before 476 AD can't be considered medieval. Also, Wikipedia claims that  (c. 625) is Late Latin, so maybe the date should be pushed even later...? Ioaxxere (talk) 13:19, 8 July 2024 (UTC)
 * The endpoint of "Late Latin" can be put at various places: Wikipedia says some would put it as late as 900 CE. My viewpoint is that if we make use of the term "Medieval Latin", it is best to define it in terms of the same date range commonly recognized for the Medieval period/Middle Ages in historical periodization. While the start of the Middle Ages isn't entirely fixed by convention (The Catholic Encyclopedia suggests you could take 375, 476, or 609) our entry at Middle Ages and Wikipedia both describe it as starting at 500 CE. If we expect this definition of "Medieval" to be the most common prior expectation for our readers, I think it seems strange to cut off several centuries from the category bearing that name. Sure, the division is arbitrary since there is no sharp transition between Late Latin and Medieval writers, but the same applies to Classical and Late Latin, and Medieval and New Latin.--Urszag (talk) 14:08, 8 July 2024 (UTC)


 * This claim is for his generation. Isidore, over 60 when authoring his work, must have employed the Late Latin language he learnt when a bairn, like some of our seniors appear to relate to 20th-century English, and foreign languages, better than Generation Alpha slang. Idiolects aren’t all updated at the same time, so chronolects have intersections in reality. Fay Freak (talk) 14:13, 8 July 2024 (UTC)


 * To give a real-world example, is only attested in Medieval Latin, so the etymology on PWG  is gmw-pro, supported by plaaster. What should this be changed to in cases like this, Vulgar Latin? --  20:57, 8 July 2024 (UTC)
 * "Vulgar Latin" is a problematic term. I would lean towards saying it's not necessary to distinguish different kinds of Latin in the context of categories for borrowings into Proto-West-Germanic, and thus "Proto-West Germanic terms borrowed from Latin‎", "Proto-West Germanic terms borrowed from Medieval Latin", "Proto-West Germanic terms borrowed from Early Medieval Latin‎" and "Category:Proto-West Germanic terms borrowed from Vulgar Latin" might be better as just one category. In that case, it could simply use . If more context is desired, another format could be "from  via a clipped form  (attested in Medieval Latin)." --Urszag (talk) 21:27, 8 July 2024 (UTC)
 * needs a label for a conjectured chronolect, starred “Late Latin”. I commented four weeks ago about this missing functionality. Fay Freak (talk) 21:34, 8 July 2024 (UTC)
 * @Victar @Urszag I agree here with Fay Freak that if we actually believe this term existed in PWG, it needs to be derived from a hypothesized Late Latin term. I should add that the earliest cites listed in Du Cange and DMLBS are c. 1200 AD; not even Early Medieval Latin. @Fay Freak I saw your comment but didn't respond because I wasn't sure (and still am not sure) what you're asking for exactly. Can you give an example? Benwing2 (talk) 22:15, 8 July 2024 (UTC)
 * @Benwing2 I think Fay Freak was saying exactly the same thing as you, but as a FF-ism. Theknightwho (talk) 22:30, 8 July 2024 (UTC)
 * I think the thing is simple, but people are unsure how to fit it in. The claimed dialect or chronolect label can be based on conjecture rather than attestation, so merits a star, or something else, if the idea from my side to put it beside language names rather than word forms is erratic, though it is just a general icon for reconstruction and I wouldn’t know which other sign to invent. By the same reasoning a sense has to be marked as reconstructed when the term is attested in but a part of the distinct meanings. Fay Freak (talk) 22:32, 8 July 2024 (UTC)
 * Another example is PWG, where the etymology lists multiple stages of Latin:  Detailing the different forms of Latin helps to give a sense of chronology, which just using plain Latin doesn't afford. --  22:44, 8 July 2024 (UTC)
 * I suspect a lot of these terms are wanderwords that didn't exist at the PWG stage. For example, if there was really a PWG plăstr, wouldn't we expect OE plæster not #plaster? Benwing2 (talk) 22:48, 8 July 2024 (UTC)
 * exhibits p > pf, which points to it being borrowed before this change occurred, i.e. in Proto-West Germanic. What happens with a lot of Latin borrowings is that they get later reenforced by Latin individually and even later by Old French. -- 23:03, 8 July 2024 (UTC)
 * Not necessarily; the p -> pf change could have survived as a surface filter for hundreds of years after it first occurred. Benwing2 (talk) 23:45, 8 July 2024 (UTC)
 * I didn't realize you were a PWG editor. -- 00:44, 9 July 2024 (UTC)
 * Cut the sarcasm. You're not a Latin "editor" either. Benwing2 (talk) 01:42, 9 July 2024 (UTC)
 * No, however I am an editor who spends a large portion of their time focusing on Latin borrowings into West Germanic. OHG had no problem borrowing p from Latin, with examples like, from . -- 02:32, 9 July 2024 (UTC)
 * I know that, but IMO it doesn't prove that much. Spanish borrowed some words from Latin with ie reflecting short ĕ hundreds of years after the initial sound change /ɛ/ -> ie under stress; Italian borrowed some words from Latin with closed /o/ reflecting Latin ŭ late into the Medieval and Early Renaissance period, more than 1,000 years after the corresponding sound change took place. Russian still sometimes makes the substitution /h/ -> г /g/ in borrowings.
 * In any case we seem to have 5-1 consensus that PWG can't borrow from Medieval Latin. Benwing2 (talk) 03:23, 9 July 2024 (UTC)
 * "5-1 consensus"? Where do you see that? What's been discussed is the start date of Medieval Latin. If ML begins in 5th~6th century, 5th~6th century PWG can conceivably borrow from it. -- 03:42, 9 July 2024 (UTC)
 * I've sorted out some of the details of.
 * Not the first time I've encountered a late borrowing from Romance into Latin that happens to be spelt the same way as we'd spell the 'Vulgar Latin' reconstruction. An even later example is . Nicodene (talk) 03:15, 9 July 2024 (UTC)
 * Thanks for creating an entry for it. -- 03:23, 9 July 2024 (UTC)
 * , want to create an entry for, from ? -- 04:36, 9 July 2024 (UTC)
 * @Victar Done. Let me know if there are others like this. Nicodene (talk) 22:50, 9 July 2024 (UTC)

Is it necessary to draw a distinction between Late and Medieval Latin? What if we merge them as simply ‘Post-classical Latin’ or something? Since different sources can variously call the same etymon LL and ML, a merge might be helpful… Inqilābī 04:14, 9 July 2024 (UTC)


 * Yes. They represent notably different stages and dialects. Late Latin was still spoken natively, while Medieval Latin was learned as a foreign language and has a lot of weirdnesses in it by comparison. Benwing2 (talk) 04:46, 9 July 2024 (UTC)
 * The end period of natively spoken Latin overlaps with the early period of the use of Latin as a scholarly, learned Lingua Franca. Therefore, any switch-over date we pick is somewhat artificial and arbitrary. To make it easy, we should then use some century. It will not make a great deal of difference whether we let Medieval Latin “take over” per the 5th, 6th or 7th century. But perhaps we should allow the languages to overlap in time, depending on the evidence of use – whether it was a (possibly reconstructed) term used by the common people or a term used by a scholar or scribe. After all, Late Latin was not truly the ancestor of Medieval Latin in the sense in which Middle English is the ancestor of English. --Lambiam 22:42, 17 July 2024 (UTC)
 * There is a label "post-Classical" that I've used in the past (e.g. octoplus, athough an IP replaced it with the more specific ML. label). As a label, it would in theory cover all of Late Latin, Medieval Latin and New Latin, which is a pretty broad time range. I can see why we might want to include a few more divisions. I'm not entirely on board with conceptualizing the boundary between "Late Latin" and "Medieval Latin" as a real internal transition rather than a convenient yet more-or-less arbitrary convention of periodization: while some analyses consider the transition between native use and "learned as a foreign language" use of Latin to be significant and something that happened around the start of the "Medieval" era, there isn't consensus either on the nature of that transition or its date, so I don't think our dictionary should commit to the idea that this is an essential criterion dividing Late Latin from Medieval Latin. (I don't think the presence of these labels in itself requires that theoretical commitment, but I wanted to push back a bit against the viewpoint mentioned by Benwing.)--Urszag (talk) 12:55, 9 July 2024 (UTC)

Unchecked proliferation of pages generated due to using uder
I noticed many editors who aren’t well-aquainted with etymology templates are using uder. I would recommend displaying a default warning after someone uses this template to deter people from using it. Inqilābī 20:28, 7 July 2024 (UTC)


 * @Inqilābī Could you please give some context as to the kinds of pages you mean, and what the problem is? Theknightwho (talk) 20:34, 7 July 2024 (UTC)
 * Category:Undefined derivations by language. The previous template was etyl (which was the oldest etymology template and was non-specific in nature), later replaced by uder for smoother appearance. This template ought to be substituted with a legitimate etymology template such as der, inh, bor, lbor, etc. Using uder generates the aforesaid category and subcategories; even Wingerbot keeps generating these categories as part of its routine category creation. Inqilābī 20:49, 7 July 2024 (UTC)
 * @Inqilābī My understanding is that the template is supposed to be used if you're not fully sure of the derivation. Ideally every entry would be more specific, but that's not feasible. Theknightwho (talk) 20:53, 7 July 2024 (UTC)
 * I guess I would rather someone who doesn't know what the right template to use is, uses uder rather than just der, which lots of people are in the (unfortunate) habit of doing. Benwing2 (talk) 21:00, 7 July 2024 (UTC)
 * As someone who does etymology cleanups, der and uder are the same thing to me. Using a wrong template isn’t the only issue though; wrong etymons are another problem, commonly found in very old entries. Changing bor to the more precise lbor is another maintainence. Inqilābī 21:10, 7 July 2024 (UTC)
 * @Inqilābī Well, going forward shall we agree the following?
 * uder should be used when you're unsure of the exact derivation, so it categorises the entry into a maintenance category so that it can be replaced with a more specific template if appropriate, or otherwise der if it's not.
 * der should only be used when the derivation does not fit into one of the types of derivation covered by another template.
 * This seems like a useful distinction to me, at least. Theknightwho (talk) 21:16, 7 July 2024 (UTC)
 * @Theknightwho Yes, that was the original intention of these templates. Benwing2 (talk) 21:17, 7 July 2024 (UTC)
 * @Inqilābī Please don't do that. If you're not sure of whether to use inh or bor, leave it alone. Benwing2 (talk) 21:17, 7 July 2024 (UTC)
 * As someone who also does etmology cleanups, I would rather people be vague than wrong. With uder, people who know what they're doing can find these entries to fix them. It's already too easy for someone to just copypaste a derivation template from another language without changing the language codes. I find things like Bengali entries in Category:Pashto terms borrowed from Arabic, Bengali terms categorized as Assamese and vice versa. I even find entries for European languages in Category:Indonesian terms inherited from Malay. Then there are the etymologies where a term is borrowed from a neighboring language, which inherited it from another language, which borrowed it from yet another language- and the etymology uses bor for that last step, even though there was no direct contect between the first language and the last language. Of course, the people who make those errors would probably get the language codes wrong in uder if they even knew about it. My point is that unnecessary usage of uder is pretty minor compared to that kind of nonsense. Chuck Entz (talk) 22:26, 7 July 2024 (UTC)
 * I am pretty sure that is not the case. It’s only a cleanup template / category— and if unsure about the immediate etymon, using der is sufficient (but a rfe can be added alongside). It wasn’t created to exist permanently, and will be deprecated eventually. Inqilābī 21:02, 7 July 2024 (UTC)
 * I'm a little confused, because wouldn't that mean it could have been wholesale replaced by der without any loss of specificity? I thought the whole point was that it created the maintenance category because the editor suspects a more specific derivation may be possible, whereas der does not necessarily imply that, meaning it's still useful if people add it. Theknightwho (talk) 21:05, 7 July 2024 (UTC)
 * @Theknightwho That's right. der is supposed to used only when inh and bor don't apply. I don't agree with User:Inqilābī that der is OK if you're not sure of the correct template. Benwing2 (talk) 21:07, 7 July 2024 (UTC)
 * Firstly, I think having der is okay in cases where the etymology says ‘ultimately from’. Another editor could subsequently add to the etymology if more data is available. rfe can always be used, and editors can fix etymologies from that category page. Originally, uder was created to prevent someone who was converting etyl to der wholesale, and not out of the desire to make a category for to-be-fixed etymologies.
 * But if people want to change the purpose of this template, then I have no objections- I am just stating what I thought was a misuse of the template and categories. Inqilābī 21:21, 7 July 2024 (UTC)
 * @Inqilābī On a separate-but-related note, please don't change empty categories with auto cat to d, because if they stop being empty then they're still no longer part of the category tree, and it means someone else (read: an admin) has to actively undo your change, which is annoying. Empty categories get automatically categorised into Category:Empty categories, and are deleted routinely. However, these categories are maintenance ones that shouldn't be deleted anyway, since they will occasionally see new entries. Theknightwho (talk) 21:23, 7 July 2024 (UTC)
 * I agree with this; I just did a run deleting empty categories a couple of days ago. Benwing2 (talk) 21:25, 7 July 2024 (UTC)
 * Okay sorry, I didn’t know I wasn't supposed to do that with the uder categories, even though I have done this for a long time without anyone objecting. Inqilābī 21:32, 7 July 2024 (UTC)
 * @Inqilābī Yes, IMO der is OK in 'ultimately from' cases but from what you said above it sounded like you were doing exactly that wholesale conversion of uder to der, which is absolutely wrong. Benwing2 (talk) 21:23, 7 July 2024 (UTC)
 * Yeah, people don’t clearly understand what I say. This was funny because I am against indiscriminately using der, and I was the main reason this was halted after I started a BP discussion about the problem some years ago. Inqilābī 21:31, 7 July 2024 (UTC)
 * My apologies, when you said  and   are the same thing to me it sounded like you were using der indiscriminately. Benwing2 (talk) 21:35, 7 July 2024 (UTC)


 * Few considerations

Inqilābī 12:24, 8 July 2024 (UTC)
 * Future consideration: It seems like editors who use uder use it randomly (this includes copy and pasting from elsewhere) and not because they think it is to be used if they are uncertain about the specific etymology. Our default welcome message could also contain a link to a page listing the etymology templates with explanations about each of their purposes, which would help prevent a misuse of any of the templates by new editors. This in turn would rule out the necessity of any maintainance etymology template.
 * Immediate consideration: If empty pages aren’t regularly deleted then uder cleanup becomes difficult. I don’t want to click on every subcat to check which languages’ cleanups are complete. Hence I would suggest a bot deleting the empty pages periodically (from what I know this has not been done for the category in question), or actually allowing editors to tag the pages for deletion, or even creating a duplicate copy of the category which won’t contain empty subcats (I’m not sure if the last option is feasible). This makes life easier for people going across language entries to substitute this template with better etymology templates.


 * @Inqilābī Your second point confuses me: if you're monitoring them from Category:Undefined derivations by language, then you can already see which are empty. The next level up from that is Category:Entry maintenance subcategories by language, which is way too broad to be conducting routine entry maintenance from, since you generally want to pick a single area to focus on at any one time. Theknightwho (talk) 15:20, 8 July 2024 (UTC)
 * Do you mean those (x e) things beside the category names? Wow I never realized until just now that it indicated the number of entries contained. Sorry for wasting everyone’s time!- but also thank you for pointing it out. Inqilābī 15:31, 8 July 2024 (UTC)
 * @Inqilābī No worries. If it has subcategories, you can also click the little arrow to the left of the name to expand them. Theknightwho (talk) 15:33, 8 July 2024 (UTC)
 * I am aware of those arrows, but for some reason every single arrow in this category actually appears grey, and I’m unable to expand them. Inqilābī 15:38, 8 July 2024 (UTC)
 * @Inqilābī Yeah, it only shows subcategories - you can't use it to see pages, unfortunately. Theknightwho (talk) 15:39, 8 July 2024 (UTC)
 * , well I would still urge periodically deleting empty subcats of undefined derivations using your bot, given that limitless new subcats can be created by anyone, while I prefer it be a short list of cleanup category which I don’t have to scroll through to be able to spot the non-empty ones. Thanks for considering! Inqilābī 11:59, 9 July 2024 (UTC)

Voting to ratify the Wikimedia Movement Charter is ending soon
<section begin="announcement-content" />
 * You can find this message translated into additional languages on Meta-wiki. 

Hello everyone,

This is a kind reminder that the voting period to ratify the Wikimedia Movement Charter will be closed on July 9, 2024, at 23:59 UTC.

If you have not voted yet, please vote on SecurePoll.

On behalf of the Charter Electoral Commission,<section end="announcement-content" />

RamzyM (WMF) 03:46, 8 July 2024 (UTC)

etydate template
Originally, etydate displayed text inside square brackets and small text. However, this was removed later on while retaining the dot at the end of the text and the parameter. Now, the dot at the ending is not necessarily needed always and editors often use other wording in the same sentence after the template-generated text. So I think it should be consistent with other etymology-line templates like doublet, calque, etc. which generate text but no dot, also because it's easily much less a hassle to type a dot than. I'd like to know if people agree with or object to such a change. Svartava (talk) 12:15, 9 July 2024 (UTC)


 * I'd be in of this, as probably the biggest user of this template. All instances would need a bot update, but it would be much better imo. Similarly, I've considered removing "the" when a non-number was given, opting to manually have it, but maybe it's better to have it. Vininn126 (talk) 12:17, 9 July 2024 (UTC)
 * . (Adding the langcode as the first parameter might also be useful as it would help creating lists of terms in a given language by first attestation.) Einstein2 (talk) 12:34, 9 July 2024 (UTC)
 * There was also talk of having categorization for dates at some point, but no one was able to come up with a concrete system. Vininn126 (talk) 12:57, 9 July 2024 (UTC)
 * removing the default dot and removing the parameter in etydate because it's easily much less a hassle to type a dot.
 * Adding the langcode as the first parameter seems like a useful idea as well for creating lists of terms in a given language by first attestation. Kutchkutch (talk) 13:46, 9 July 2024 (UTC)
 * and I can do the bot changes. Benwing2 (talk) 18:39, 9 July 2024 (UTC)
 * — B ABR ・talk 19:06, 9 July 2024 (UTC)
 * - Leasnam (talk) 02:26, 10 July 2024 (UTC)


 * ✅; as of now, the cleaning up is in process. If you can run a bot job of adding . at the end of instances of etydate, here's a list of entries on which cleanup has not been done -- rest have been fixed. Thanks! Svartava (talk) 09:18, 11 July 2024 (UTC)
 * @Svartava Can you tell me exactly what steps you took and in what order? In the future it would be better not to do half-cleanups like this, particularly when making a change that isn't idempotent such as adding or removing a period, because it's difficult to figure out how to do the bot changes correctly. It would be better to let me do it completely. Benwing2 (talk) 02:00, 12 July 2024 (UTC)
 * @Benwing2: I removed all instances and added periods at the end of etydate's on some of the pages on which  wasn't used. I've created the list mentioned above for the entries on which cleanup is yet to be done so on those entries it's just adding periods after etydate since all those pages are among those pages which were not using . Svartava (talk) 02:51, 12 July 2024 (UTC)

Removing hiragana transliterations in Japanese
Hello, I propose that I run a bot task to remove the instances where we see hiragana used as part of the transliteration when linking to Japanese, e.g. →. This is because the hiragana doesn't add anything more than the romanization already offers; the transliteration doesn't help those who can't read Japanese writing anyway; and, in general, I think tr should be reserved for Latin writing, as people who only know English can at least always derive something from it. I believe we had (maybe not everyone) agreed that we should only use the romanization in this case for Japanese, but please let me know what you think.

What I would do: 1. Likely make a tracking category for entries that use non-Latin in Japanese translations in, as I believe the majority of uses of this are in translation sections; 2. Iterate over all translations, and for each one: 3. If the transliteration of the hiragana equals the romanization, simply remove the hiragana; else, save it for our review, in case there are any mismatches in transliteration out there.

If there's a more refined way to access any instances of the link module using non-Roman transliterations, that might also be a better substitute for step 1, but I don't know if that exists. Kiril kovachev (talk・contribs) 21:35, 9 July 2024 (UTC)


 * @Kiril kovachev Yes, I agree. I don't mind/quite like having hiragana displayed as rubytext (or we could even do Chinese-style and have it displayed after a slash), but having it in transliterations like this is generally pretty crap. Theknightwho (talk) 21:15, 10 July 2024 (UTC)
 * @Theknightwho Do you think we should do either of these ideas, instead of outright removing it? Kiril kovachev (talk・contribs) 21:44, 10 July 2024 (UTC)
 * @Kiril kovachev I think for now it's best to remove them, since any conversion to rubytext would need to be done manually, and a lot of them are quite sloppy.
 * We probably want to have a proper discussion about displaying multiple forms (i.e. rubytext), as it might make more sense to use the Chinese style in translation sections (where space is tight), as compared to other places. I'm still keen for us to display kana forms, though, since having to work backwards from transliterations is annoying. Theknightwho (talk) 21:57, 10 July 2024 (UTC)
 * @Theknightwho Alright, I'll focus on removing them now, then, if that's what we want. I'm asking because if we eventually wish to convert the translations to give kana inline anyway, getting rid of it now would just make it harder for us later, no? Kiril kovachev (talk・contribs) 22:13, 10 July 2024 (UTC)
 * @Kiril kovachev Hopefully it should be possible to automatically scrape kana in some cases, which should mitigate this. However, I don't think it's too much of a problem if we remove it now, since it would all need to be converted properly by hand anyway. Theknightwho (talk) 22:20, 10 July 2024 (UTC)
 * Okay, gotcha. I'll figure it out one of these days hopefully then. Kiril kovachev (talk・contribs) 22:23, 10 July 2024 (UTC)
 * Agreed also. Benwing2 (talk) 21:32, 10 July 2024 (UTC)
 * Agreed also. Benwing2 (talk) 21:32, 10 July 2024 (UTC)


 * simply deleting these hiragana readings. In (which is standard in the English Wiktionary), the long vowel in any intra-morpheme combination of an  kana +  or  is transcribed  without distinction,  and  are both transcribed, and  and  are both transcribed , so it is untrue that the hiragana adds nothing, since one can't in all cases infer the hiragana from the Romanisation (the converse is also true, since kana do not distinguish case, whereas the Latin script does). It is also very common for learners of Japanese to be proficient in kana but be unfamiliar with many kanji (I am just such a learner). I would propose converting these hiragana readings to furigana, but as Theknightwho already noted, the smaller text size and lack of space in translation tables militates against this. I'm not thrilled about slashed translations à la Chinese traditional/simplified spellings and would prefer the kana remain in parentheses alongside the rōmaji, but it would be a tolerable solution.
 * 0DF (talk) 22:54, 10 July 2024 (UTC)
 * @0DF Well, I've personally argued for having a 1-to-1 transliteration system in the past, but that doesn't seem to be overly popular, so for now you're right that it does add minor distinctions, which I chose to ignore because I didn't believe them to be overly significant. The reason is because you can just click on the link to see the kana if you wanted to see the original; after all, if you wanted to see the historical spelling, which is even more distant from the current pronunciation, you'd again have to do that too. The differences in kana and romaji don't affect the way a reader would pronounce the word, as far as I'm aware, which is in the first place why the romanization is identical for all those syllables.
 * But, I get that there is a difference, and that you won't be able to spell the word in kana correctly if all you have is the Hepburn. Fair enough. Maybe we can abstain from removing it for now.
 * I also have a few suggestions for what we can do with the kana, though, to keep it a bit smaller: as some dictionaries do, we can have the furigana given as a subscript on the kanji. Or as brackets after each kanji, but that's less readable IMO. Kiril kovachev (talk・contribs) 23:06, 10 July 2024 (UTC)
 * @0DF I completely disagree with this. You are arguing based on a small number of edge cases, which can easily be determined for those small numbers of people who care, by looking at the lemma page. Benwing2 (talk) 23:39, 10 July 2024 (UTC)
 * @Benwing2 Well, you could make the same argument for removing simplified Chinese, since - like kana - it can't be readily determined in only a quite small proportion of cases. Theknightwho (talk) 23:46, 10 July 2024 (UTC)
 * @Theknightwho But the difference is that simplified Chinese *IS* the normal way of writing these lexemes for 95%+ of native speakers, which doesn't apply to kana in the case of words normally written with kanji. Benwing2 (talk) 23:58, 10 July 2024 (UTC)
 * @Benwing2 It's trivial to find examples of words which are in free variation between the two. It's not safe to just assume the kana forms aren't used. Theknightwho (talk) 00:03, 11 July 2024 (UTC)
 * @Theknightwho I'm not sure why you are arguing. Did you change your mind about removing kana from transliterations or are you just playing devil's advocate? Benwing2 (talk) 00:08, 11 July 2024 (UTC)
 * @Benwing2 I think we should remove the ones given in manual transliterations, but I'm ultimately in favour of having kana displayed somehow. Theknightwho (talk) 00:12, 11 July 2024 (UTC)
 * @Theknightwho I see. Personally I think furigana is enough. Benwing2 (talk) 01:04, 11 July 2024 (UTC)
 * @Theknightwho I see. Personally I think furigana is enough. Benwing2 (talk) 01:04, 11 July 2024 (UTC)

U4C Special Election - Call for Candidates
<section begin="announcement-content" />
 * You can find this message translated into additional languages on Meta-wiki. 

Hello all,

A special election has been called to fill additional vacancies on the U4C. The call for candidates phase is open from now through July 19, 2024.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community members are invited to submit their applications in the special election for the U4C. For more information and the responsibilities of the U4C, please review the U4C Charter.

In this special election, according to chapter 2 of the U4C charter, there are 9 seats available on the U4C: four community-at-large seats and five regional seats to ensure the U4C represents the diversity of the movement. No more than two members of the U4C can be elected from the same home wiki. Therefore, candidates must not have English Wikipedia, German Wikipedia, or Italian Wikipedia as their home wiki.

Read more and submit your application on Meta-wiki.

In cooperation with the U4C,<section end="announcement-content" />

-- Keegan (WMF) (talk) 00:03, 10 July 2024 (UTC)

MediaWiki:Gadget-SpecialSearch
Should we get rid of this old gadget (currently on by default)? It creates three new buttons at Special:Search (Google, Bing, Yahoo) which are meant to let you search Wiktionary with an alternative search engine, although the gadget is not working properly at the moment. mentioned that the gadget might have been created at a point in time in which the built-in MediaWiki search was more "primitive". I think it is no longer necessary, but maybe some people would still like to be able to use it. Ioaxxere (talk) 04:21, 10 July 2024 (UTC)


 * I don't care either way but if other people don't want to keep & fix it then let's just get rid of it.
 * I will add, though, you are able to link to google using (e.g. Wiktionary), and if you type google: in the search bar you'll be redirected to google as well. So if the goal is to search something on wiktionary and pull results on google, I assume a fix is possible but I'm not sure how helpful that would be. OTOH if the goal is to pull up google results on Wiktionary, I 'm still not sure it would be helpful. Unless, it could count the total amount of results (since google removed that feature), but even that feels like a stretch. —  B ABR ・talk 04:35, 10 July 2024 (UTC)
 * I will add, though, you are able to link to google using (e.g. Wiktionary), and if you type google: in the search bar you'll be redirected to google as well. So if the goal is to search something on wiktionary and pull results on google, I assume a fix is possible but I'm not sure how helpful that would be. OTOH if the goal is to pull up google results on Wiktionary, I 'm still not sure it would be helpful. Unless, it could count the total amount of results (since google removed that feature), but even that feels like a stretch. —  B ABR ・talk 04:35, 10 July 2024 (UTC)

Looks like nobody cares that much. I'll take the gadget away and we'll see if anyone complains. This, that and the other (talk) 03:25, 19 July 2024 (UTC)
 * I don't care about the issue, but 9 days in Summer seems like a very short time to expose any issue to objections. DCDuring (talk) 11:39, 19 July 2024 (UTC)
 * someone can still voice an objection after it is removed. I don't think there's any harm in removing the gadget now, and think it's good way to see if the gadget being gone actually causes issues for anyone. Plus, FWIW, the gadget is not even functional right now and no one has voiced support for fixing it, so there's really no difference between it remaining installed or not. — B ABR ・talk 19:30, 19 July 2024 (UTC)

Mahagaja changing references to
This was brought up before (link?), but User:Mahagaja has a habit of going around changing the references section on pages from  to. Assuming this is out of a visual preference, they can simply edit their private common.css to accommodate their personal taste. If we, as a project, wanted this font size as the default, that change would have been made in the backend. -- 18:28, 10 July 2024 (UTC)


 * I don't remember anyone bringing this up before, but if we're not supposed to be allowed to do this, we shouldn't have size in reflist, or maybe we shouldn't have reflist at all. —Mahāgaja · talk 18:31, 10 July 2024 (UTC)
 * What a bizarre reason to remove a feature (one can also always use ), but I find it useful for notes on entries and references within discussions. Also reflist is the only way you can have a references inside a references list, is which helpful for notes. --  18:47, 10 July 2024 (UTC)
 * I wasn't actually advocating removing either reflist or size; I was pointing out the oddity of providing a template that has a certain function, and then complaining when users use it. —Mahāgaja · talk 08:39, 11 July 2024 (UTC)
 * And it has its uses here and there, but changing all instances in the references section is another thing entirely. Is this just for aesthetic reasons? You can add  to your common.css file which will accomplish the same. --  03:15, 12 July 2024 (UTC)
 * That would make them smaller only for me, not for everyone. There's a reason that books have for centuries been printing footnotes at the bottom of the page in a smaller font size than the regular text: you don't want less important information like references to be written as large as the more important information. The difference between main text and footnotes is clearer to the reader when there's a size difference. —Mahāgaja · talk 12:44, 13 July 2024 (UTC)
 * if your intention is to apply to all entries, this is a matter that should be discussed first. — Sgconlaw (talk) 13:36, 13 July 2024 (UTC)
 * Well, I never edit entries just to apply reflist, but if I'm editing, for some other reason, an entry that uses, I often change that too. Never in a billion years would it have occurred to me that anyone would be annoyed by that, but if they are, I'll stop changing it in existing entries. But I will keep using reflist in entries I create or entries I'm adding references to for the first time. —Mahāgaja · talk 14:06, 13 July 2024 (UTC)
 * but that's exactly what should be discussed. It makes certain entries look different from others—I'm not sure that's a good idea. — Sgconlaw (talk) 14:09, 13 July 2024 (UTC)
 * We're a wiki with hundreds of editors. It's inevitable that some entries look different from others, and that's never going to change. And you know how discussions of this type end up: lots of people express lots of different opinions, much more heat than light gets generated, eventually the conversation fizzles out without anything being resolved, and everyone goes back to doing things exactly the way they always have. —Mahāgaja · talk 14:20, 13 July 2024 (UTC)

Language of surnames
Someone has had a lot of fun adding tons of Polish surnames as English entries, rendering Category:English terms borrowed from Polish practically unusable in the process.

Five years after a failed vote (Wiktionary:Votes/pl-2019-11/CFI policy for foreign given names and surnames), couldn't we have another go at devising a policy about this? PUC – 18:52, 10 July 2024 (UTC)
 * The phenomenon of proper nouns "drowning out" regular words in categories is not unique to this situation. E.g. it's a little bit of work to spot the common nouns in Category:Latin feminine nouns in the second declension and Category:Latin masculine nouns in the first declension given all of the borrowed names in these categories. Does this mean it would be useful to have categories for these that exclude proper names? I once thought so, but I think I've seen some argument about how intersectional categories aren't necessary because there's supposed to be some way to generate them yourself—not that I remember how to do it. Since Category:English terms borrowed from Polish, Category:English proper nouns, and Category:English surnames all exist, in theory there's all the information needed to calculate the difference of these sets.--Urszag (talk) 19:23, 10 July 2024 (UTC)
 * @Urszag I don't know how easy it is to do set differences. Maybe @Chuck Entz or @DCDuring or someone else who knows the search system would know. But one way to deal with your specific issue is to categorize proper nouns differently from (common) nouns in the above categories.
 * @PUC I completely agree we need a criterion preventing people from arbitrarily adding surname X as term in language Y. I remember this happening various times, leading to mass RFD's that haven't been resolved consistently. In inflected languages like Russian and Polish it's useful to know how to decline certain foreign names, but not arbitrary ones; an appendix would be sufficient for that. Benwing2 (talk) 23:36, 10 July 2024 (UTC)
 * It's easy to do searches in the searchbox: 'incategory:"English terms borrowed from Polish" -incategory:"English proper nouns"' (There are 69; note the "-".). Using categories and templates (hastemplate:"template name") in combination is quick. Adding individual words or phrases to shorten the result is also quick. If you do these things, adding regex searches for very specific targetting (eg, rare typos) isn't much of a performance hit. See Help:CirrusSearch (at MediaWiki). DCDuring (talk) 01:54, 11 July 2024 (UTC)
 * We should make a subcat called "LangX proper nouns borrowed from LangY". CitationsFreak (talk) 06:11, 11 July 2024 (UTC)

Pintupi-Luritja
Currently, Pintupi-Luritja does not have a script code assigned (just ), meaning that the one translation we have at peace comes up in CAT:Pintupi-Luritja terms in nonstandard scripts. For Pitjantjatjara, we have a special encoding  at MediaWiki:Gadget-LanguagesAndScripts.css which uses the same special characters (in addition to Pintupi-Luritja and Pitjantjatjara both being classified as part of the Western Desert dialect cluster). I personally do not have the ability to do any of these things, because I lack the rights, but I propose that: Minor Pama-Nyungan languages are currently severely neglected and neither I nor anyone else can give them any attention in this state. Pinging who I discussed this with on the Discord. - saph 668 (user—talk—contribs) 20:56, 10 July 2024 (UTC)
 * 1) a (etymology-only? I don't know what the right handling is here) language code be created for the Western Desert (see Western Desert language for what would be included) cluster, or at least a family code,
 * 2)   be renamed to follow that code,
 * 3) and all Western Desert dialects be changed to use the special encoding.


 * I'm keen for us to not add more custom script codes, as these were essentially inherited from a time when we used different templates for every script. What we need to do is sort this out via CSS. For now, I've added the Latin script, so CAT:Pintupi-Luritja terms in nonstandard scripts is now empty. Theknightwho (talk) 22:02, 10 July 2024 (UTC)
 * What would sorting it out via CSS entail? - saph 668 (user—talk—contribs) 22:05, 10 July 2024 (UTC)
 * @Saph668 There should be a way to specify it based on what's in the =lang= tag, though @This, that and the other may know more. Theknightwho (talk) 22:21, 10 July 2024 (UTC)
 * I'll look into this again.
 * I do agree with what @Saph668 says about Pama-Nyungan languages. There doesn't appear to have been any attempt to group them into even the most obvious and uncontroversial subfamilies (Western Desert, Kulin, ...) This, that and the other (talk) 06:17, 12 July 2024 (UTC)
 * @Theknightwho see the last discussion at Beer_parlour/2024/January. The issue is specifically with page titles and would need some Lua coding to fix. This, that and the other (talk) 06:19, 12 July 2024 (UTC)
 * i thought the idea was that it needs a special font so that the underscores appear properly. see on the peace page, under "Translations to be checked", how Pintupi still appears with a normal font, but the closely related Pitjantjara language (which coincidentally is next to it alphabetically) uses a font that looks slightly more bunched together. I was only guessing, but my intuition told me that the reason we do this is because these languages are among the few that use letters with underscores as part of their alphabet, and that these might not render properly on some fonts, especially the ḻ. But I could be wrong. — Soap — 08:14, 11 July 2024 (UTC)

Are taxonomic names Latin or Translingual?
Following an RFV discussion, there has been some further discussion between me and on how we should treat taxonomic names. So I think it is best to take this discussion to BP. The questions that stand to be resolved are: According to on the linked RFV discussion, "other editors agree in the past, a taxonomic name by itself doesn't count as a usage of a word in the Latin language", but that isn't the same as a formal discussion, so here I am. Here are my concerns: Here are Ben Wing's concerns, to the best of my knowledge (I apologize if I have misrepresented him in any way and I am open to be corrected):
 * 1) For specific epithets that are only attested in taxonomic names and not in the Latin literature, should we categorize them as Latin or as Translingual?
 * 2) If we do categorize them as Translingual, how should we deal with their inflections?
 * abbotti is currently a Translingual adjective that has no gender specified, but lycioides is currently, even though they function identically in the context of being a specific epithet in Translingual. (This is because in Latin, abbotti is the genitive form of a noun, and lycioides is an adjective.)
 * We're kind of implying that Translingual is a gendered language...
 * actinocarpus is also currently a Translingual adjective, and it is gendered as, and the feminine and neuter forms are provided. Further, actinocarpa is currently marked as the "feminine" form of actinocarpus, whereas in Latin it would be instead "nominative feminine singular". He thinks that partially borrowing the inflectional structure from Latin is problematic, because "Translingual doesn't have any grammatical rules"; but then it also "seems wrong" to have to "make three lemmas for the masc/fem/neut varieties".
 * The whole taxonomic naming system is really "a restricted sort of Latin" and so they should be classified as Latin in the first place.

(Also pinging .)

--kc_kennylau (talk) 21:44, 10 July 2024 (UTC)


 * After some discussion with it has been brought to light that in the (pre-)modern scientific Latin literature, the species names are declined as normal as in Latin (see noctula where the species name Vespertilio murinus is declined in the ablative as Vespertilione murino). This has changed my opinions a bit, and I now think that it would be reasonable to categorize them under Latin. --kc_kennylau (talk) 22:43, 10 July 2024 (UTC)


 * When I address such things, I normally leave the L2 header alone, not because I don't have beliefs and preferences about them, but because there has been no codification, and not much interest in codifying, how such matters are addressed.
 * Specifically, Translingual does have simple rules about gender agreement, not unlike those of Latin, that are enforced by the Code authorities.
 * As to the inflection line for Translingual adjectives (ie, those we have not found in any vintage of Latin), almost all of which imitate Latin in form, it seems a good presumption that all three genders potentially occur, as all three genders are represented among genus names.
 * I would not be surprised to find that specific epithets that are homonyms of Latin adjectives are used with an apparent definition that differs in some way from the Latin.
 * The guardians of our Latin entries have not even allowed legal or medical Latin, or modern Latinate inscriptions or mottos (either on the grounds that they are SoP or that they are not properly formed, ie, not SoP) to sully the Latin categories. There is not even much enthusiasm (ie, citation effort) to include modern Church Latin, despite use in running text.
 * In principle, the same kind of problem can occur with genus names and perhaps names at other ranks. For example, ' is a synonym of Dicronorhina, ' of Euhagena,  is a genus of ray-finned fish. We treat such terms as both Translingual and Latin (also English), albeit with different definitions.
 * Finally, in the past century (or longer) many specific epithets have been derived from poorly documented languages that were spoken near where specimens where found. Often there is no Latinate ending grafted on, so the epithet is invariant, its PoS is not obvious, and it is treated as an adjective.
 * I have no proposal to make and wonder what, if anything, is now being proposed. DCDuring (talk) 22:47, 10 July 2024 (UTC)
 * Why not remove the genders? Then it can be Translingual and no assumption must be made.
 * On the other hand, I think specific epithets (or any part of the name) that are obviously construed as being Latin should be given a Latin section in addition to their Translingual section, where you can specify the declension. But if that's no good, then I also see no problem with simply saying that Translingual "can" be a gendered, and declined, language. It's not one language after all, it's any terms that aren't specific to one language, so if some of the vocabulary used translingually is declinable or gendered, is there really be a problem? Kiril kovachev (talk・contribs) 22:47, 10 July 2024 (UTC)
 * I tend to agree with DCDuring and Kiril here, with one exception. I don't think the occasional use of taxonomic names in Latin literature is sufficient reason to treat all these terms as Latin. We have special rules for Translingual taxonomic names and templates for specific epithets that denote the gender, which is essential imo and cannot be omitted - this is where I differ from Kiril.
 * The only thorny patch arises due to the fact that Latin is an LDL, so even a single attestation of a declined taxonomic name (like Vespertilione murino) in a Latin text would give us license to add a Latin entry for the genus and the specific epithet. Perhaps time to revisit the idea of treating post-1500 Latin as a WDL. (Although in this case it's a moot point, as and  both date back to classical Latin.) This, that and the other (talk) 23:14, 10 July 2024 (UTC)
 * I have been following the criterion that any term that has any use at all in Latin text passes RFV (in accordance with Latin's classification as a LDL). So I haven't attempted to convert any term to Translingual when there are concrete attestations like "Secretum in Vespertilione murino et V. noctula foetidum". This, that and the other, it sounds like you would be in favor of a stricter criterion? Whereas kc_kennylau, it sounds like you are saying that because some species names are attested like this, we should include a Latin entry for any species name, even if zero attestations can be found for that specific term in running Latin text? I'm not seeing a consensus yet.
 * Even though I wouldn't agree with the viewpoint that binomial nomenclature is a form of Latin, it is of course undeniable that this naming system follows some conventions that are derived from Latin grammar. One of these is agreement in gender (masculine, feminine, or neuter) for adjectival epithets. So I don't think it's adequate to simply have an entry for the form "actinocarpus" with no indication that its feminine form is "actinocarpa" and its neuter form is "actinocarpum". Nor does it make sense to have these as separate, disconnected entries. I don't see it as problematic to include this in a Translingual entry, as Translingual is not itself a language that can have or lack grammatical rules as a whole: different entries in Translingual may belong to their own subsystems of communication that follow their own particular rules.--Urszag (talk) 01:33, 11 July 2024 (UTC)

So, it seems like all the respondents so far would agree with (or at least accept) a policy like this: (For the second point, it should be mentioned that the official guidelines do specify that the specific epithets are gendered and need to agree with the gender of the genus, when they originate as a Latin adjective.)
 * 1) If a specific epithet is found in the Latin literature, then it is to be formatted as ==Latin==, with all the gender and inflection information included (e.g. noctula).
 * 2) Otherwise, it is to be formatted as ==Translingual==, where there are at most three forms (masculine, feminine, neuter), and no inflection (e.g. actinocarpus).

In addition, I would like to propose the following points: <li> The Translingual genus names (e.g. Abroma) should be included in the gendered categories (e.g. Category:Translingual neuter nouns). (When was converted to use  by Special:Diff/59825365/72996213),   was specified because the original code did not categorise according to gender. I'm not sure if that was a deliberate decision, or they just forgot to categorize.) </li> <li>The various other relations between the various nouns and adjectives should be suffixes instead of inflections. For example, abdimii has the suffix -ii that forms specific epithets (even though it comes from the Latin genitive), and Acanthodii has the suffix -ii that forms classes (even though it comes from the Latin plural).</li> <li>We implicitly agree that these words are not Latin and thus do not have vowel length.</li> </ol>

A question remains to be resolved, that I have mentioned above: abbotti originates as a genitive, and lycioides originates as an adjective whose three genders are the same (also see Point 5). When they function as specific epithets, they behave the same in all regards. Should we treat them the same? i.e. should they either both be or both have no gender specified? (All three approaches have potential problems:
 * If abbotti has no gender specified and lycioides is, then it's inconsistent descriptively (as specific epithets). (I think this is the original intent of the official guideline, but the guideline itself kind of retains (reasonably so) some features of Latin.)
 * If abbotti becomes, the Latinists might not like this. (In my opinion this seems to be the best solution, and if the Latinists don't want to accept neo-Latin then I guess they also cannot decide how Translingual grammar works.)
 * If lycioides becomes no gender specified, then this is kind of inconsistent to our previous ruling that specific epithets agree in gender with the genus.)

--kc_kennylau (talk) 11:46, 11 July 2024 (UTC)


 * @Kc kennylau I agree with all those points! As for the final point, I principally want to say abbotti should have no gender, whereas lycioides have, but you make a good point that, in as much as they aren't Latin, those two ought to behave virtually the same, i.e. be usable after any gender of genus. I had prepared a long argument about why I would propose what I said originally, but now I think we would be best to label them the same, probably with all three genders; as, in both cases, we aren't labelling the inherent gender of the adjective, but what genders of genus it can agree with, which in both cases is all of them. I guess for two- or three-termination adjectives, if those are used in taxonomy, I don't know, they would have one or two genders at the "base" form and links to feminine/neuter versions? Kiril kovachev (talk・contribs) 13:29, 11 July 2024 (UTC)
 * (barbadensis and cervicornis would be examples. The latter might be a bit problematic.) --kc_kennylau (talk) 13:38, 11 July 2024 (UTC)

Yes. A combination of both. The two main taxonomic codes explicitly state that the names are in Latin and Latinized Ancient Greek, but only a very restricted subset. Basically, all taxonomic writing used to be in Latin, then most of the writing was replaced by the vernacualar except that a diagnosis describing a new name in Latin had to be provided, and finally that faded out, just leaving the names themselves. One could make the argument that taxonomic names really are Latin, but the extremely narrow context in which they're used doesn't allow for us to see verbs (except participles), prepositions, or accusative, dative, locative or vocative nominal/adjectival inflections

As for the names themselves: they all theoretically have gender, but above the rank of genus it's usually impossible to know what it is. The names of genera are nouns in the nominative singulat, but they have gender. Species, subspecies, varieties, etc. modify the name of the genus either as: or as:
 * 1) An adjective in the nominative that agrees with the generic name in gender and number
 * 2) A noun in the genitive that agrees in gender and number with the referent (so abbottii isn't an adjective)
 * 1) A noun in apposition that only agrees with itself.

The genitive can be used for species named after someone or something, or it can be used to refer to some association with the referent, as in Sempervivum tectorum, which has historically been found growing on roofs, or parasitic species named after their host. The last case is the only way to determine the gender of a name above the rank of genus, since a species that parasitizes members of a taxonomic group would have a name that agrees in gender and number with the name of that group.

Thus a species in the genitive named after Mr. Smith would be smithi or smithii, one named after Ms. Smith would be smithae, after the Smith sisters would be smitharum and after Mr. Smith and at least one other Smith would be smithorum.

There's a lot more I could say, but I don't have time right now. Chuck Entz (talk) 15:07, 11 July 2024 (UTC)


 * Just wanted to add that the "noun in apposition" is the rule for things that are not Latin. For example: piranga, from Old Tupi is present in some scientific names (Issoca piranga, Pyrianoreina piranga) and remains the same regardless the genus is masculine, feminine or neuter. Some authors can still choose to latinize them, Aulonastus pirangus and Sternostoma pirangae do exist, but just piranga is still valid. Trooper57 (talk) 15:33, 11 July 2024 (UTC)
 * I understand that we are following Latin rules, and that the guidelines intend the names to be Latin; but that does not change the descriptive reality of how they are currently used in the scientific community (I would suppose that most biologists don't know Latin), nor should this impact our policy making decisions. This is also apparent in the fact that 31.1.2 of this document had to spell out the various genitive endings, just as you did for the Smiths. In Point 4 of my proposals, these endings (-i, -orum, -ae, -arum) would be classified as Translingual suffixes for the purpose of the English Wiktionary.
 * Also, after reading your reply, I'm not really sure what your opinion is, regarding this matter.
 * The apposition rule can also apply for Latin names, with an example given in the document being Cephenemyia phobifer , or Acrochordonichthys  ischnosoma .
 * --kc_kennylau (talk) 16:32, 11 July 2024 (UTC)
 * I didn't think to check it before now, but it seems that the essay Taxonomic names has covered some of the topics discussed here.--Urszag (talk) 21:42, 11 July 2024 (UTC)

I suppose there is some merit in making a distinction between noun and adjective for specific epithets even when there is no descriptive difference, in that it is a nice balance between the Latinists and pragmatism. If we do so, then abdimii can be a noun with no gender specified (specific epithets that are nouns in the Latinist sense do not need to agree in gender with the genus, so there is no need to specify the gender thereof). Would people agree with this approach? --kc_kennylau (talk) 22:39, 11 July 2024 (UTC)
 * I'd say it's as least as accurate (if not more so) to call them nouns as it is to call them adjectives, so I have no objection to that.--Urszag (talk) 22:45, 11 July 2024 (UTC)

(By the way, there are currently 586 entries using the template . --kc_kennylau (talk) 14:27, 12 July 2024 (UTC)

Automating taxonomic entries
I have recently made which can automate the reference section for genus entries and tested it on Felis and Autoserica. Basically, those reference sections usually contain a link to Wikipedia, a link to Wikispecies, and a link to the Commons category. This new template can automatically detect if each link exists, given the Wikidata ID.

I am wondering if we should add more links to templates, and more generally if more things about taxonomic entries can be automated.

For example, I think (which links to a Translingual entry) and  (which links to Wikispecies) can be unified.

--kc_kennylau (talk) 13:32, 12 July 2024 (UTC)
 * Reasons not to combine taxfmt and taxlink are:
 * Instances of taxonomic name within taxlink, but not taxfmt, are occasionally counted and used to create lists of taxonomic names "wanted" in principal namespace.
 * There is no reason for every instance of taxfmt to check for the existence of a Translingual L2 section.
 * The ease of converting one to the other as we add taxonomic-name entries.
 * Wikidata links are fine, where they exist. If there is no Wikidata link, then it is usually desirable to link to Species, WP, or Commons pages for taxa of a higher rank, which AFAICR wikidata does not do. What are also useful are some of the links to external databases, even though many of the external links do not have data not present in others.
 * BTW, I continue to believe that we do not need to have entries for 10,000,000 species, nor even just the 1,000,000+ described species. We need entries for those that are important for humans, often as evidenced by the existence of vernacular names that more-or-less correspond to species, genus, or higher-ranked taxon. DCDuring (talk) 19:18, 12 July 2024 (UTC)
 * @DCDuring On your point about the large number of potential entries, many of those won't pass CFI at the end of the day. If a name is used in one paper and then only ever mentioned in taxonomic databases, I don't think that passes, quite frankly. Theknightwho (talk) 16:18, 18 July 2024 (UTC)
 * We haven't decided that last point, about whether occurrence in a taxonomic database (or table in a print or electronic document, for that matter) was a use or a mention.
 * But your point would seem to argue against any simple automation of the creation of taxonomic entries and, I would argue, in favor of a system for directing new-entry creation efforts toward those names that had links thereto (ie, were "wanted") by other entries in principal namespace. There are a fair number of orphan or near-orphan taxonomic entries being created now. Some might be good candidates for RfV. DCDuring (talk) 17:23, 18 July 2024 (UTC)

Implementing auto-glossary
I propose creating pages using auto-glossary in appendix space add adding User:Ioaxxere/auto-glossary.js to the gadgets list. We should start by beta-testing a couple of pages and get user feedback. Also, if the gadget gets moved to MediaWiki space it would be ideal if I could be made an interface administrator so I could continue working on the gadget if need be and possibly help maintain our other gadgets as well. What do we think? (Pinging ). Ioaxxere (talk) 05:19, 13 July 2024 (UTC)


 * It seems nice to have. Vininn126 (talk) 09:54, 13 July 2024 (UTC)
 * I am fine with installing this. Also I'm the one who suggested to Ioaxxere to post about becoming an interface admin. Benwing2 (talk) 18:51, 13 July 2024 (UTC)
 * I support you for interface admin too. Kiril kovachev (talk・contribs) 19:53, 13 July 2024 (UTC)

User:Ioaxxere/PagePreviews.js
As the name suggests, this is a script to display a preview of an entry when hovering over a link. To try it out, add  into your common.js page. Please try it out! My goal is to create a preview gadget that's good enough to be on by default to match Wikipedia's page previews. Ioaxxere (talk) 05:48, 14 July 2024 (UTC)


 * Works great on mobile iOS – I tested it on both my iPhone and tablet. I really like how it skips straight to the definitions and remains in the single language that was linked. Just like its use on Wikipedia is to quickly preview an article without having to click it, this will be more convenient for readers who just want to find out the meaning of a word without having to leave the main entry one is viewing. Conversely, I do not really see any negatives here – The only point of discussion for me might be on what exactly is included in the preview, but I do prefer its current configuration for the added convenience. Easy support from me. LunaEatsTuna (talk) 21:16, 14 July 2024 (UTC)

dated/archaic/obsolete in the glossary as well Obsolete_and_archaic_terms
People seem to have a lot of confusion about these words. Some people seem to use "archaic" for obsolete words, or think that this is a sliding scale.

I propose we change the text in the proposed link to mention the same information as the glossary (i.e. archaic is for stylization) and also mention that this isn't really a scale of oldness, but rather markedness. Vininn126 (talk) 08:34, 14 July 2024 (UTC)
 * Do you have some example of the confusion? DCDuring (talk) 14:50, 14 July 2024 (UTC)
 * An exact edit, no. Although compare pośmiewać and the recent edit history. But it's been many a time the subject of discussion on Discord, maybe @PUC can chime in. Vininn126 (talk) 15:01, 14 July 2024 (UTC)
 * Discord doesn't count as either authority or evidence. DCDuring (talk) 16:30, 14 July 2024 (UTC)
 * @DCDuring No, but Vininn126's word that this has come up a lot on Discord means that this is an issue, and it's one I can attest to as well. People do get these confused - I've seen it myself. Theknightwho (talk) 17:10, 14 July 2024 (UTC)
 * Why always so dismissive of the idea? Did you ignore the other part of my comment or did you see "Discord" and think "DISCORD BAD"? Vininn126 (talk) 19:18, 14 July 2024 (UTC)
 * Why, yes, Discord IS bad, being a potential communication channel for cabals. DCDuring (talk) 21:05, 14 July 2024 (UTC)
 * It's being communicated here with official examples, so I fail to see the issue. Vininn126 (talk) 08:18, 15 July 2024 (UTC)
 * I am unable to assess the import of the labels in Polish. DCDuring (talk) 21:05, 14 July 2024 (UTC)
 * ‘Markedness’ felicitously puts into a single word the impressions I myself have formed through editing. My own thoughts, developing on the idea: ‘dated’ properly encompasses a rather small selection of terms, and ‘archaic’ evenmoreso. A large part of terms common in the past and rare in the present actually elicit no recognition of antiquity from the reader, being neither part of the vocabulary of conventional archaisms, nor a word whose decline is apparent from the recent past. These uses—and I call them that because, from my experience, they mostly encompass senses of polysemous words, and not entire words—are, in my opinion, best described with a neutral xx or xx.
 * I would also like to make a comment on the nature of ‘obsolete’, which our glossary defines as ‘no longer likely to be understood’. I have seen this given as justification to not apply this label, in cases where an obsolete term bears enough similarity to an existing one to be understood even today. (‘Dated’ labels for alternative forms from the seventeenth century!) I find a good rule of thumb in such cases is that a term like this is obsolete when a reader no longer recognises it as antique, but simply wrong, novel or unusual. ―⁠Biolongvistul (talk) 16:01, 14 July 2024 (UTC)
 * Any thoughts on how these labels should be applied (would be understood) for no-longer-widely-accepted taxonomic names. It isn't just aging taxonomists that might recognize such a term, but also users of older reference works, advocates of some less accepted taxonomic position, etc. DCDuring (talk) 16:36, 14 July 2024 (UTC)
 * ‘Historic’ maybe? ―⁠Biolongvistul (talk) 17:45, 14 July 2024 (UTC)
 * The history can be quite recent, as DNA analysis has led to many changes in name, not to mention placement (hypernyms) and circumscription (hyponyms). Current experts in the taxonomy of a family or order would know about many old names, but view them as not suitable for their use. True obsolescence takes a long time. I am not sure that dated captures much that is relevant, but those with more exposure to the taxonomic community discourse may know better. DCDuring (talk) 21:05, 14 July 2024 (UTC)
 * I think it's "dated" as soon as the scientific name changes, maybe "obsolete" as people stop using it. CitationsFreak (talk) 02:10, 16 July 2024 (UTC)
 * Markedness is already something we have to contend with, vis-a-vis colloquial, formal. Vininn126 (talk) 19:19, 14 July 2024 (UTC)


 * Yeah, I have confusion about them. I generally go for dated=no hits in 50 years, archaic=nothing in 100 years, obsolete=nothing in 200+ years, or if Webster 1913 marks it as archaic. Sometimes it might be on the cusp of different tags, in which case I randomly choose, by instinct. Any tag telling us "you shouldn't use this word today" is better than none, IMHO. Newfiles (talk) 21:45, 14 July 2024 (UTC)
 * That's not always indicative of how the words are truly marked. Vininn126 (talk) 08:18, 15 July 2024 (UTC)
 * "Dated" definitely doesn't mean "no hits in 50 years." I've never seen anyone interpret it that way before. Take a look at the page linked in the header for this topic. That should give you a better sense of what the consensus has been in the past. Andrew Sheedy (talk) 17:11, 15 July 2024 (UTC)

Ban the POS "prepositional phrase"
I am going through and eliminating the POS "prepositional phrase" from Russian lemmas. I propose we ban new lemmas with "prepositional phrase" as the POS. IMO, all lemmas tagged as "prepositional phrase" are better identified as either an adjective, adverb, preposition or interjection. "Prepositional phrase" tells you nothing about the syntactic function of the phrase. In Russian, at least, there is no consistency whatsoever in whether a given multiword phrase headed by a preposition is identified as a "prepositional phrase" or as an adjective, adverb, preposition or interjection. I think it comes down to the laziness of the editor. Existing cases of the POS "prepositional phrase" have to be grandfathered in, but we can prohibit new ones with an edit filter. The only potential issue I see is that some prepositional phrases can function either as an adjective or an adverb, and we currently don't have a concise way of putting multiple POS's in a single entry. This means every once in a while, a prepositional phrase will have to be converted into two entries, an adjective and an adverb (or maybe identify as one of them and use cat2 to categorize under the other, although that is less ideal). Benwing2 (talk) 03:01, 15 July 2024 (UTC)
 * It looks like this header was specifically allowed by a vote in 2010. I don't really agree with calling a prepositional phrase an adjective or adverb; I guess some might be lexicalized to the extent of becoming essentially single words, but we also have entries for idioms that really have to be considered phrases rather than words, such as of a lifetime, on the surface, at first glance, up a tree.--Urszag (talk) 03:15, 15 July 2024 (UTC)
 * @Urszag But you will find zillions of multiword adverbs here. There is no consistency whatsoever in whether multiword terms are characterized as "prepositional phrases" or "adverbs" etc. Why can't we call on the surface an adverb? It functions exactly like one syntactically. Benwing2 (talk) 03:21, 15 July 2024 (UTC)
 * It's not that phrases can't be categorized as adverbs (on Wiktionary). What I meant was that I could get behind avoiding the term "prepositional phrase" if it was inaccurate—for example, if the term it was applied to wasn't really a phrase. But in cases where it is a perfectly accurate description, I don't see why it should be avoided. It seems consistent enough to call all phrases with the form of a prepositional phrase "prepositional phrases"; if some are currently called "adverbs", they could be changed to match the others, rather than the reverse. "Adverb" is a pretty diverse and heterogeneous category, so a lot of things can potentially fit in it. I can't think of a specific test to differentiate "on the surface" from a lexical adverb, but maybe someone else knows of one.--Urszag (talk) 03:47, 15 July 2024 (UTC)
 * @Urszag We don't include "transitive verb" or "intransitive verb" as part of speech headers, even though those might be perfectly accurate. In many cases these are not phrases (since "phrase" doesn't apply to just anything with multiple words), and calling it a "prepositional phrase" obscures the actual function of the term, since it's too broad. Theknightwho (talk) 03:49, 15 July 2024 (UTC)
 * To me, the analogy with "transitive verb" and "intransitive verb" cuts the other way. We call verbs "verbs", and don't try to include extra information about how they grammatically function in the POS header. Likewise, I think we should call prepositional phrases "prepositional phrases", and not bother with trying to make the header tell the reader details about how they function grammatically in a sentence: that's what the definition, examples, and if necessary usage notes are for, not what the Part of Speech header is for.--Urszag (talk) 15:31, 15 July 2024 (UTC)
 * I completely agree. It feels like a crutch for people who don't like multiword terms. Theknightwho (talk) 03:48, 15 July 2024 (UTC)
 * I, too, find that the usage of this POS is generally not helpful. I've eliminated most of its use from Polish entries. Vininn126 (talk) 08:23, 15 July 2024 (UTC)


 * Keep the phrase "on the surface" contains a preposition, an article, and a noun. None of those are adverbs.  Furthermore, even if the POS is sometimes misused, that's not a reason to delete the ENTIRE POS <b style="font-family:Verdana"><b style="color:#3A003A">Pur</b><b style="color:#800080">ple</b><b style="color:#991C99">back</b><b style="color:#C3C">pack</b><b style="color:#FB0">89</b></b> 11:58, 15 July 2024 (UTC)
 * Not containing an adverb does not mean that the phrase itself isn't an adverb. That's a ridiculous statement. Vininn126 (talk) 12:08, 15 July 2024 (UTC)
 * Adverbs are, according to our own definition, words, not phrases. You're confusing functioning as an adverb with actually being one <b style="font-family:Verdana"><b style="color:#3A003A">Pur</b><b style="color:#800080">ple</b><b style="color:#991C99">back</b><b style="color:#C3C">pack</b><b style="color:#FB0">89</b></b> 15:18, 15 July 2024 (UTC)
 * Or, taken from Wikipedia: An adverb is a word or an expression. Just because our current entry is missing information doesn't make it right. The claim that adverbs have to be a single word is ridiculous. Vininn126 (talk) 15:21, 15 July 2024 (UTC)
 * Quoting opening comment: "The only potential issue I see is that some prepositional phrases can function either as an adjective or an adverb, and we currently don't have a concise way of putting multiple POS's in a single entry. This means every once in a while, a prepositional phrase will have to be converted into two entries, an adjective and an adverb (or maybe identify as one of them and use cat2 to categorize under the other, although that is less ideal)."
 * In English probably the majority of prepositional phrases can serve as both adjectives and adverbs. Do we have any facts to support the adverbial "Every once in a while". I believe it is just wrong, at least for English. If there are languages other than English for which there is some good reason to remove the "prepositional phrase" PoS, so be it.
 * I really don't understand the motivation for this kind of indiscriminate, complicating, revolutionary change. Is it fun? Does it indulge a homogenizing, controlling impulse? DCDuring (talk) 12:29, 15 July 2024 (UTC)
 * Because not all can be converted, and placing under one umbrella implies that these phrases all have the same syntactic behavior, which isn't true. Why must you always through accusations like this around? It's unbecoming, rude, and frankly I'm tired of it. This is a poor attitude to have. Vininn126 (talk) 12:37, 15 July 2024 (UTC)
 * My questions can be rephrased as "What is the "attitude" that warrants this kind of proposal?"
 * All categories are "umbrella classes", with a great deal of diversity of syntactic behavior. That each PP tends to modify sentences, phrases, adverbs, or adjectives with different frequencies might be a call for some kind of usage note, but I doubt that we will do the work to justify such a note, just as we haven't done the work to support even the broader claims on which this proposal is based. It does seem to be much easier to change things all at once in code than to engage in the one-definition-at-a-time effort to improve entry quality. DCDuring (talk) 13:27, 15 July 2024 (UTC)
 * What is or isn't a prepositional phrase is rather clear-cut. Unless it changed since I was in middle school English, all prepositional phrases start with a preposition and have some more words afterwards (usually articles and nouns). <b style="font-family:Verdana"><b style="color:#3A003A">Pur</b><b style="color:#800080">ple</b><b style="color:#991C99">back</b><b style="color:#C3C">pack</b><b style="color:#FB0">89</b></b> 15:21, 15 July 2024 (UTC)
 * That has nothing to do with what I said. DC's claim is that most prepositional phrases may need to be converted to both an adjective and an adverb, and my argument is that not all will be. By using prepositional phrase we are assuming that they all have the same syntactical behavior, when in reality, they do not. Vininn126 (talk) 15:23, 15 July 2024 (UTC)
 * The fact that they do not is the reason why we have to preserve prepositional phrase as an acceptable POS... <b style="font-family:Verdana"><b style="color:#3A003A">Pur</b><b style="color:#800080">ple</b><b style="color:#991C99">back</b><b style="color:#C3C">pack</b><b style="color:#FB0">89</b></b> 17:17, 15 July 2024 (UTC)
 * Huh? We need to know which ones act as both adverbs and adjectives, and which ones act as only adverbs, and which ones only as adjectives. If they always behaved as both, it would be predictable. Your logic makes no sense. Vininn126 (talk) 17:21, 15 July 2024 (UTC)
 * His logic does not make sense, but do we feel confident that users would accurately distinguish the prepositional phrases by adverbs and adjectives? Just two years ago we had to find the common fallacy of categorizing predicatively used adjectives as adverbs,, Talk:extrem. Sure we can do it, but I have not discerned the benefit of the eventual effort (only significant in English though, given the numbers in the category), instead of leaving the ambiguity, only that Benwing can apparently more parsimoniously conceptualize the parts of speech, since a rule or theory becomes less convincing with each exception. Fay Freak (talk) 20:26, 15 July 2024 (UTC)
 * Trusting users to accurately distinguish things should not always be a priority. We should remain faithful to the truth, regardless of how complicated it is. Vininn126 (talk) 20:28, 15 July 2024 (UTC)
 * I mean it is not wrong, and then can it be more wrong, or less correct or more vague if people prefer to employ the more general category “phrase”. “Prepositional phrase” could also be kept as a tracking category therefore. Fay Freak (talk) 20:34, 15 July 2024 (UTC)
 * FWIW, Wiktionary consistently misuses the word "phrase". am I under arrest is not a linguistic phrase but that's what we call it. Benwing2 (talk) 20:36, 15 July 2024 (UTC)
 * Is that relevant to this discussion? suggested that some of the terms currently labeled "prepositional phrase" are not phrases, but most of the terms in Category:English prepositional phrases seem to qualify. I've relabeled cases like at the bottom of as prepositions. By the way, I noticed Category:English phrasal prepositions seems to be a manually curated category, but couldn't it be implemented automatically as the intersection of Category:English prepositions and Category:English multiword terms?--Urszag (talk) 21:48, 15 July 2024 (UTC)
 * If you still have the problem with prepositional phrases that function as adjectives (but aren't adjectives) AND function as adverbs (but aren't adverbs), by deleting the prepositional phrase category, you're just replacing one problem with another problem. People are way too focused on trying to label prepositional phrases as adjectives or adverbs, but I don't think that that's an important or necessary distinction, certainly not important enough to delete a part of speech to implement. <b style="font-family:Verdana"><b style="color:#3A003A">Pur</b><b style="color:#800080">ple</b><b style="color:#991C99">back</b><b style="color:#C3C">pack</b><b style="color:#FB0">89</b></b> 22:08, 15 July 2024 (UTC)
 * @Purplebackpack89 But they are adjectives and/or adverbs, whereas "prepositional phrase" doesn't refer to an independent part of speech. All we're doing at the moment is makng it more difficult to tell which ones can be used as adjectives, which can be used as adverbs, and which can be both. Theknightwho (talk) 22:37, 15 July 2024 (UTC)
 * A preposition is an independent part of speech. Why wouldn't a prepositional phrase be as well?  I still say calling something that's preposition + article + noun an adjective or an adverb is inaccurate. <b style="font-family:Verdana"><b style="color:#3A003A">Pur</b><b style="color:#800080">ple</b><b style="color:#991C99">back</b><b style="color:#C3C">pack</b><b style="color:#FB0">89</b></b> 23:59, 15 July 2024 (UTC)
 * What on earth are you even talking about. I feel like you are discussing something completely differently. Basically the idea is to make prepositional phrases more like na bani. Vininn126 (talk) 08:09, 16 July 2024 (UTC)
 * From what I gather, Purple doesn't know linguistics well but thinks he does. Benwing2 (talk) 08:34, 16 July 2024 (UTC)
 * @DCDuring Do you find it fun caricaturing every opinion you disagree with? You continually pepper discussions with these kinds of passive-aggressive comments, and they are getting very tiresome. Theknightwho (talk) 21:50, 15 July 2024 (UTC)
 * How are they passive? DCDuring (talk) 22:10, 15 July 2024 (UTC)
 * You "pepper discussions with [...] aggressive comments"? CitationsFreak (talk) 01:11, 16 July 2024 (UTC)
 * No comment right now on the proposal to remove "Prepositional Phrase" but it's a bit funny to me how our current list (outside of "Prepositional Phrase" which had its own vote) was institutionalized by a vote consisting of only 7 editors in a 5-1-1 vote as seen at Votes/pl-2015-12/Part_of_speech. It was part of User:Daniel Carrero's in 2015 to rightfully update Wiktionary's policies as of that time, as explained in . It's been 9 years since then. Maybe it's time we do a full review of WT:EL, though I suspect it won't be a simple as it used to be. AG202 (talk) 23:30, 15 July 2024 (UTC)
 * Delete. If they are just multi-word adverbs/adjectives/other things, just call them what they are. (I also support seeing which phrases are really just other parts of speech disguised as phrases. I know that tail between one's legs is only a phrase due to editing conflicts over if it should be a noun or adverb. CitationsFreak (talk) 01:26, 16 July 2024 (UTC)
 * , let's remember that "prepositional phrase" is a common header now chiefly because Equinox merged thousands upon thousands of separate adverb/adjective sections under a unified "prepositional phrase" header back in the day. I've always disagreed with that, as it seemed to me we were erasing a useful distinction. Moreover it's not always possible to word a definition both adjectivally and adverbially. PUC – 17:54, 16 July 2024 (UTC)
 * Yes, I remember. I also believe that we would be foolish not to recognize that many of the PP entries would probably benefit from &lit as they often have SoP as well as entry-worthy definitions, however this gets resolved. DCDuring (talk) 21:24, 16 July 2024 (UTC)
 * eliminating this header. Part of speech headers exist to describe the syntactic function, not the form, of a term. We got rid of "acronym", "initialism", and "abbreviation" for this reason. Ultimateria (talk) 20:12, 16 July 2024 (UTC)
 * . Many of the Italian entries I create are prepositional phrases. Splitting these into separate POS headers for adjectives and adverbs would be both inconvenient and misleading for almost all such entries. Intuitively, it’s also more intuitive for me to categorize these entries as prepositional phrases rather than as adjectives/adverbs. Imetsia (talk (<span style="cursor:help;" title="I strongly prefer messages on my talk page instead of article talk pages, Wiktionary discussion pages, or edit summaries. More information on my talk page.">more ) ) 22:55, 17 July 2024 (UTC)
 * Could you provide an example where this would be detrimental? Vininn126 (talk) 22:57, 17 July 2024 (UTC)
 * Just looking through my recent contributions, entries like, , , and would be affected. In these cases, we'd have to split them up into adjective and adverb headers, which I find to be an unintuitive way to label these constructions. Imetsia (talk (<span style="cursor:help;" title="I strongly prefer messages on my talk page instead of article talk pages, Wiktionary discussion pages, or edit summaries. More information on my talk page.">more ) ) 23:12, 17 July 2024 (UTC)
 * I would classify most of these as adverbs, to be honest, in a syntactical sense. Vininn126 (talk) 23:13, 17 July 2024 (UTC)
 * I don't see how you could. I have the example "cena a luma di candela" ("candlelit dinner"), in which case "a luma di candela" is modifying a noun. I could come up with "gara a coppia" ("competition between pairs of contestants"), "musica a palla" ("loud music"), "vendita ticket a gonfie vele" ("smooth-sailing ticket sales"); in which case the constructions are always modifying nouns. Imetsia (talk (<span style="cursor:help;" title="I strongly prefer messages on my talk page instead of article talk pages, Wiktionary discussion pages, or edit summaries. More information on my talk page.">more ) ) 23:17, 17 July 2024 (UTC)
 * Taking a noun argument does not exclude it - often phrases built from a preposition + noun are adverbs anyway, asking the syntactic question "when", compare w nocy (at night). Vininn126 (talk) 23:19, 17 July 2024 (UTC)
 * Aren't these just adjectives? CitationsFreak (talk) 03:51, 20 July 2024 (UTC)
 * Honestly this sounds like "it's too much work for me to figure out whether it's an adjective or adverb so I'd rather just put something unhelpful and let the reader figure it out". Benwing2 (talk) 23:02, 17 July 2024 (UTC)
 * No, for almost all cases, the prepositional phrase can act as both an adjective and an adverb. It's not a matter of "figuring out whether it's an adjective or adverb". And I don't think readers have been confused by the prepositional phrase header. Imetsia (talk (<span style="cursor:help;" title="I strongly prefer messages on my talk page instead of article talk pages, Wiktionary discussion pages, or edit summaries. More information on my talk page.">more ) ) 23:13, 17 July 2024 (UTC)
 * I don't think it's always about what leaves the reader confused, but rather about what's factually more precise, since some PP can be adverbs, some adjectives, and some both. Vininn126 (talk) 23:15, 17 July 2024 (UTC)

Minor changes to CFI attestation section
At WT:RFVE, wrote a comment that drew my attention to some divergences between our current practice and the text of CFI. I want to propose two small changes to align the policy with practice.

Currently CFI does not actually say what a "citation" is. Experienced Wiktionary editors know that (at least for WDLs) a citation is a quotation - a snippet of (usually) running text that includes the word and is referenced to a particular durably archived work. But CFI somehow manages to avoid saying that. The word means different things to different people and non-lexicographers may be unfamiliar with the applicable sense. Case in point: to us, "citation" and "quotation" are interchangeable, but to a Wikipedian, "citation" is synonymous with "reference".
 * 1. What is a "citation"?

This can be cleared up by adding a sentence at the beginning of WT:CFI: <ins style=color:green> Citations, in the form of quotations, provide evidence that a term exists and provide examples of how it is used as part of a language.

For languages well documented on the Internet, three citations in which a term is used is the minimum number for inclusion in Wiktionary.

It is well understood by seasoned Wiktionarians that a mere listing of a word as a headword in a dictionary or glossary is a mention, not a use, and only relevant for the attestation of LDLs. But perhaps this is not so obvious to less experienced contributors. It wouldn't hurt for CFI to say this outright.
 * 2. Dictionary entries are not "uses"

To help clear up any confusion, I propose to alter the existing example in WT:CFI from "For example, an appearance in someone’s online dictionary is suggestive, but it does not show the word actually used to convey meaning." to: "For example, <ins style=color:green>the fact that a dictionary contains an entry for the word is suggestive, but it does not show the word actually used to convey meaning."

(I note for completeness that users have differing views on whether the appearance of a word as a gloss in a dictionary is a use or a mention. That's why I chose the wording carefully, specifically using the word "entry" instead of the general term "appearance" to avoid any possible confusion.)

These changes are small and, I suspect, uncontroversial, so I'm asking here to see if there is support or opposition instead of opening a formal vote. If it is felt that a vote is required I will start one. This, that and the other (talk) 10:35, 17 July 2024 (UTC)


 * These are indeed minor changes, in that they only codify "common understandings" rather than addressing significant issues raised by these questions. The fact that the rest of the universe defines a "citation" as any reference to authority for a given point, while on Wiktionary the word is "commonly understood" to refer only to particular usage examples, and to exclude all authority is a significant and frankly nonsensical situation.  To provide context, a common situation is that an editor will refer words that have no citations or attested usage in their entries to RFV because they're not mentioned in a particular dictionary, e.g. OED, or because the OED entry doesn't include a particular sense.  But if Webster's Third New International Dictionary gives the word and supports the definition for the entry—or for that matter any number of other authorities—then the concern raised hasn't been addressed because dictionary entries don't count as citations, even though the reason why the word or sense was brought to RFV was because of what wasn't included in another dictionary!
 * Worse, the entry is then vulnerable to deletion as an unattested word—despite literal attestation from strong authority—because we want a minimum of three usage examples. Which is a fine goal to show that a word is actually in use—but this standard is often difficult to satisfy in the case of archaic or technical terms, which may be contained, mentioned, or defined in every textbook and manual of a subject, but may be used without any definition whatever only in old and largely inaccessible works that can't be easily located on the internet.
 * The case that brought this to discussion was a technical term for "the fused distal end of the lower mandible" of a bird, which evidently was occasionally found in ornithological literature of the late nineteenth and early twentieth century, but which was described as "rare" in its dictionary entries. Although three examples of use besides in dictionaries and glossaries were eventually found by another editor, I made several attempts to locate it in use via Google and Google Books, searching for the term in combination with keywords such as "ornithology", "avian", "anatomy", "birds", and for ornithological texts that might use the word to describe bird mandibles—and I came up with exactly one, which did little more than define it and explain that it was a rare term used by at least one important authority, cited by last name and year only, but for which it recommended the use of a different word.
 * Of course, Wiktionary hosts countless entries and definitions that lack three attested uses, but which go unchallenged because they appear to be correct anyway, and there seems to be no rush to go out and find them. But once someone discovers that a particular dictionary doesn't include the word or sense, it's not enough to show that others do—you have to go beyond that and find three uses that don't define or discuss the word, or else the entry can be deleted.  To be clear, this is not an argument for allowing random rubbish on the internet, or "dictionary-only words", i.e. terms that have never been used for their intended purpose, but were simply invented as examples of words that someone thought should exist, like "hippopotomonstrosesquipedalian", or the fanciful collective plurals of animals that were never used before someone decided that a particular term would be amusing, and which are only ever used as examples of words.
 * Instead, it is an argument that when a word or sense can be cited to a strong authority—for instance a pre-internet dictionary not stuffed full of nonce words, or technical works that describe what something means and how or even whether it is or was in widespread use, and especially when multiple authorities can be cited, then it makes little sense to hold that it should then be marked as "unverified", or subject to deletion, due to a lack of sufficient attestation, even though it may have significantly more evidence of, and authority for both meaning and usage, than a significant proportion of other, unchallenged entries.
 * On Wikipedia, we have a number of tags that can be applied to articles, sections, or claims, to indicate that additional sources are needed or wanted, and that potentially-controversial material may be subject to deletion if it can't be verified. But on Wiktionary, even things that can easily be verified—and have been—are subject to deletion under the present CFI.  It seems to me that what's really needed is an adjustment to policy that recognizes that words or senses that can be found in and cited to authority have at least a minimal degree of attestation, and that while additional sources or examples may be wanted, the entry or sense does not need to be deleted solely due to the fact that no editor has succeeded in finding—or perhaps even attempted to go out and find those sources or examples.  If you can challenge an entry based on its inclusion or lack thereof in a dictionary, then the fact that it appears in one ought to be at least as relevant, otherwise there is a significant imbalance between inclusion and exclusion—one that seems to do a serious disservice to our readers.  P Aculeius (talk) 13:08, 17 July 2024 (UTC)
 * I responded to most of these points at WT:RFVE. I would only note here that what I'm proposing is nothing new; it is merely seeking to update the policy to reflect longstanding practice on this wiki. I'll let others respond but I don't think you'll see much support for your suggestions here. This, that and the other (talk) 14:44, 17 July 2024 (UTC)
 * Above, it is mentioned that the three cites rule is "difficult to satisfy in the case of archaic or technical terms, which may be contained, mentioned, or defined in every textbook and manual of a subject, but may be used without any definition whatever only in old and largely inaccessible works that can't be easily located on the internet." This is true for many modern minor geographical terms as well. There are geogrpahical terms with legitimately cited English Wikipedia entries (cited from non English materials) that can't meet Wiktionary's three cites. The three cites rule itself is preposterous absurdity and the emperor has no clothes. But despite this truth, it is indeed because of the three cites rule that I can make entries for many legitimate but rare words like Banmendian that do not appear in other dictionaries, and many Tingyong Pinyin words or similar minor location names. Geographyinitiative (talk) 16:43, 17 July 2024 (UTC)
 * @P Aculeius What you've said is all very well, but it would be a major policy change. What might make more sense is to change the word "citation" to "quotation" on the policy page, to avoid any confusion over what the word "citation" means. Theknightwho (talk) 21:55, 17 July 2024 (UTC)


 * Are you building a false dichotomy? I know how to balance inclusion and exclusion.
 * Given that our manpower is limited, we “send to RFV” terms for which, on a case-by-case basis, there are indications of them being hoaxical, protological, or corrupted. That is for the positive assumption, which editors arrive at differently, that they have not been used at any point in time or corner of the earth, as opposed to you being unable to find them while specifically searching.
 * For Geographyinitiative’s topographic terms you thereby have a litmus test that if you believe it had to be in a secret military map it is better left included. For living languages I have been content for a spelling to exist only conceptually: Requests for deletion/Non-English, Talk:5-DM-Banknote, after all it is the most used banknote in Europe. Inclusion may provide a picture more consistent with existing data. This is perhaps a wider implication of the “assume good faith” principle. But it is only me considering the general spirit, principles and purposes of the primary documents so much, while others outpope the Pope in their legalism; I would leave rixig as a term secured for some period and place in spite of only one quote and anything in general if our resources are convincingly specifically argued to suffer undercoverage: we need a flexibility clause for cases when one term points to more occurrences which we just don’t find, if a word has arisen organically in a community which presumably shared it rather than being an occasional literary creation. We know how to build a dictionary, if not for the CFI, indeed, wherewith we have been increasingly creative in order not to make the text work against its own goals. … Fay Freak (talk) 21:12, 17 July 2024 (UTC)

consensus on inclusion/exclusion of "someone" in multiword English verb lemmas
Hi. I'd like to get consensus on how to handle the placement of "someone", "something", "one" and "it" in multiword verb phrases. I already made a BP post about this last month, here: Beer parlour/2024/June. Most of the rules I proposed were well-received, but there was disagreement over whether and when to include the word "someone" etc. in verb phrases (except when it occurs as someone's, where it's generally mandatory). The statistics indicate that mostly it is excluded in the lemma: The upshot is that the vast majority don't contain someone or something.
 * 14,446 multiword English verb lemmas
 * 430 of them contain someone's
 * 297 of them contain someone
 * 4 of them contain somebody or somebody's (IMO we should always use someone in preference to somebody)
 * 53 of them contain something
 * 0 of them contains something's

Some people said that we should put "someone/something" in the lemma when it belongs in the middle, e.g. "see something through", because it's supposedly mandatory here. I note that this isn't actually the case; even expressions like this can have the object placed at the end if it's heavy, e.g. "I saw through all the projects that were assigned to me", whereas "I saw all the projects that were assigned to me through" is maybe possible but awkward to say the least. Furthermore, it's not generally the practice to include "someone" or "something" in the lemma, as exemplified by see through, which contains both the "see through it" and "see it through" senses.

What I do propose instead is to indicate the position of the object, especially when it goes before the preposition, in the headword but not the lemma. This would mean that under see through we'd have two separate entries with separate headwords, one for the meanings that are construed using "see through it" and another for the meanings that are construed using "see it through". This might be indicated something like this:

Verb

 * 1)  To perceive visually through something transparent.
 * 2)  To not be deceived by something that is false or misleading; to understand the hidden truth about someone or something.
 * 3)  To recognize someone's true motives or character.
 * 1)  To not be deceived by something that is false or misleading; to understand the hidden truth about someone or something.
 * 2)  To recognize someone's true motives or character.
 * 1)  To recognize someone's true motives or character.
 * 1)  To recognize someone's true motives or character.
 * 1)  To recognize someone's true motives or character.

Verb

 * 1)  To provide support or cooperation to (a person) throughout a period of time; to support someone through a difficult time.
 * 2)  To do something until it is finished; to continue working on (something) until it is finished.
 * 3)  To constitute ample supply for one for.
 * 1)  To do something until it is finished; to continue working on (something) until it is finished.
 * 2)  To constitute ample supply for one for.
 * 1)  To constitute ample supply for one for.
 * 1)  To constitute ample supply for one for.
 * 1)  To constitute ample supply for one for.
 * 1)  To constitute ample supply for one for.
 * 1)  To constitute ample supply for one for.

Here, the format of the argument to en-verb is provisional. The proposed syntax displays as see through something/someone (for the first entry) and see something/someone through (for the second entry). Maybe there's an even more efficient but still understandable syntax. For example, the Italian verb module has a large list of built-in verbs and I may do the same here; then you can just say see<@> through (sth/so) where means "consult the built-in verb list for see", so you don't have to duplicate the principal parts of see in each expression involving it if you don't want to.

Note also that I'm about to change things so that multiword verbs link each word separately by default in the listed inflections instead of linking the whole expression as a green link; it seems overkill to have non-lemma entries for the inflections of all these expressions. Benwing2 (talk) 06:06, 18 July 2024 (UTC)
 * Seems good. I note that one/one's (used to placehold for a reflexive pronoun) is omitted from the list of placeholders. But having placeholders (something, someone etc.) with the same orthography as the core terms of the expression makes the placeholders seem to be a required part of the expression. Some dictionaries use parentheses for such cases. Perhaps we could just not embolden the placeholders. (We could then use parentheses to orthographically distinguish optional from required terms and placeholders.)
 * I also wonder how we could detect whether we have usage examples that actually match the definitions when someone (a person) is common, as well as something (inanimate). I mention that because the first definition in see sth/so through explicitly includes "(a person)" whereas the usex has an inanimate object. If we are going to have "something" and "someone" used and distinguished in our definitions, as we should, then we should make sure our cites and usexes fit. If it can't be done automagically, then we need some human engineering to induce contributors to clean these things up. We need to make such cleanup a bright shiny object. The only way I've experienced is cleanup lists. Creating such lists would be an important task for magic. DCDuring (talk) 14:42, 18 July 2024 (UTC)
 * @DCDuring I agree with everything you say. I don't think it's possible to automatically determine whether a cite matches a usex and the header; this would have to be done manually, through cleanup lists as you suggest. Benwing2 (talk) 21:29, 18 July 2024 (UTC)
 * Do you have any ideas about how to generate useful cleanup lists? They don't have to be perfect in inclusion or selectivity. Actually, maybe all we need is to look at all the cases that have each of the placeholders in the headword and either of the standard indicators of usage examples: usex or *: . The numbers you've provided above are not vast. All one needs is sufficient Sitzfleisch. DCDuring (talk) 21:49, 18 July 2024 (UTC)


 * How would you handle cases like break up, where the noun can go on either side of the preposition in some cases? "I broke up the fight" and "I broke the fight up" are AFAICT synonymous, but I'm not sure that holds for all senses (does it work for sense 3, which I think of as break someone up)? Smurrayinchester (talk) 15:27, 18 July 2024 (UTC)
 * @Smurrayinchester Hmm, this is interesting. It seems there may be at least four separate cases to consider:
 * It is mandatory to place the noun or pronoun after the preposition, as in see through (it)/see through (the ruse).
 * It is mandatory to place a pronoun before the preposition, but nouns normally go after, as in break up (the monotony).
 * It is mandatory to place a pronoun before the preposition, but nouns can go before or after, as in break up (the class into groups) or break (the class) up (into groups).
 * It is mandatory to place a pronoun before the preposition, but nouns normally go before, as in break (the class) up (into fits of laughter) or see (the project) through.
 * If you look at the definition of break up in for the Farlex Dictionary of Idioms, they seem to distinguish these cases in that they identify case #4 using In this usage, a noun or pronoun is commonly used between "break" and "up." and case #3 using In this usage, a noun or pronoun can be used between "break" and "up.", while case #2 doesn't have any trailing verbiage. (Note although that by this criterion they put "break up into pieces" in case #4 instead of #3). Under see through in  for this same dictionary, they have three separate headers, "see (one) through", "see (something) through" and "see through (someone or something)".
 * A few things to add:
 * "someone" and "something" are pronouns, and accordingly they get placed before the preposition whenever possible, even in case #2 above; "break up something" sounds a bit strange to me unless you put a pause between "up" and "something".
 * Even in case #2 it's possible to put short nouns before the preposition, as in "break the monotony up", it's just not so natural.
 * In case #4, sufficiently heavy/long nouns have to be placed after the preposition, as in the example I gave above: "I saw through all the projects that were assigned to me".
 * Anyway, I'm not quite sure how to distinguish cases #2 - #4 above. It seems we have two choices: fit this into the header somehow or use labels or similar. My intuitive sense is that labels might be better, because otherwise there might be a lot of duplication of headers and because the labels can appropriately link to an appendix that explains the usage in more detail.
 * BTW I'm sure there have been oodles of papers written on this topic but I don't know of any good ones. Can anyone find a definitive explanation of the above phenomena? Benwing2 (talk) 21:28, 18 July 2024 (UTC)

Wikimedia Movement Charter ratification voting results
<section begin="announcement-content" />
 * You can find this message translated into additional languages on Meta-wiki. 

Hello everyone,

After carefully tallying both individual and affiliate votes, the Charter Electoral Commission is pleased to announce the final results of the Wikimedia Movement Charter voting.

As communicated by the Charter Electoral Commission, we reached the quorum for both Affiliate and individual votes by the time the vote closed on July 9, 23:59 UTC. We thank all 2,451 individuals and 129 Affiliate representatives who voted in the ratification process. Your votes and comments are invaluable for the future steps in Movement Strategy.

The final results of the Wikimedia Movement Charter ratification voting held between 25 June and 9 July 2024 are as follows:

Individual vote:

Out of 2,451 individuals who voted as of July 9 23:59 (UTC), 2,446 have been accepted as valid votes. Among these, 1,710 voted “yes”; 623 voted “no”; and 113 selected “–” (neutral). Because the neutral votes don’t count towards the total number of votes cast, 73.30% voted to approve the Charter (1710/2333), while 26.70% voted to reject the Charter (623/2333).

Affiliates vote:

Out of 129 Affiliates designated voters who voted as of July 9 23:59 (UTC), 129 votes are confirmed as valid votes. Among these, 93 voted “yes”; 18 voted “no”; and 18 selected “–” (neutral). Because the neutral votes don’t count towards the total number of votes cast, 83.78% voted to approve the Charter (93/111), while 16.22% voted to reject the Charter (18/111).

Board of Trustees of the Wikimedia Foundation:

The Wikimedia Foundation Board of Trustees voted not to ratify the proposed Charter during their special Board meeting on July 8, 2024. The Chair of the Wikimedia Foundation Board of Trustees, Nataliia Tymkiv, shared the result of the vote, the resolution, meeting minutes and proposed next steps.

With this, the Wikimedia Movement Charter in its current revision is not ratified.

We thank you for your participation in this important moment in our movement’s governance.

The Charter Electoral Commission,

Abhinav619, Borschts, Iwuala Lucy, Tochiprecious, Der-Wir-Ing<section end="announcement-content" />

MediaWiki message delivery (talk) 17:53, 18 July 2024 (UTC)


 * It's my understanding that the vote fell a bit short of the 2% quorum requirement as well. DCDuring (talk) 19:34, 19 July 2024 (UTC)

Deprecating MediaWiki:Gadget-Navigation popups
This gadget does not work correctly and has a replacement in the form of Page Previews (see ). If no one objects I will remove it from the gadgets list. Ioaxxere (talk) 04:03, 19 July 2024 (UTC)


 * As someone who uses Navigation popups, I notice the following differences: your popups do a better job of creating a preview of definitions for entries, but don't create previews for other pages, and lack the suite of other links that the 'Navigation popups' have in the "actions" dropdown, which I use to do things like get a preview of—or click through and go directly to—the edit history of the page upon hovering over the link (instead of having to click the link to go to the page, and then click the "history" tab and go that page, and then go back to my watchlist or the recent changes feed and do that for the next entry that catches my eye). I also like to use Navigation popups to preview diffs. So, I object to removing them (for now). The ideal solution IMO might be to incorporate the full functionality of the Navigation popups into your popups, but other (possibly easier?) solutions might be to make one or the other shift where it pops up so that they could just both be used. - -sche (discuss) 20:59, 19 July 2024 (UTC)
 * Unfortunately there's no way I can incorporate the full functionality of Navigation Popups into my gadget while still maintaining its minimalist aesthetic. Also, it seems like Navigation Popups has virtually no restrictions on what can be displayed, whereas I would like to ensure that the previewed content actually makes sense — so I won't try to match it on that front, either. But if there's something specific that I could add which would get you to switch, please let me know. Ioaxxere (talk) 05:35, 20 July 2024 (UTC)

Admin abuses
To admins: I opened a discussion on a problematic administrator at Wiktionary talk:Administrators. [ ˌiˑvã̠n̪ˑ ˈs̪kr̺ud͡ʒʔ ˌn̺ovã̠n̪ˑˈt̪ɔ̟t̪ːo ] (parla con me) 10:05, 19 July 2024 (UTC)

synonyms, antonyms ▲
Do you guys use these buttons to hide and show inline synonyms? I'm thinking of removing these (at least on mobile) as they create visual clutter for seemingly little benefit. I don't think we should even have so many nyms on a single definition that someone would want to collapse them. Ioaxxere (talk) 19:37, 19 July 2024 (UTC)


 * I strongly prefer having them hidden (which is what my preferences are set to) and I'd prefer having them hidden by default. I think there's more clutter added to entries by the -nyms themselves. I would be very opposed to removing the collapsibility feature. Andrew Sheedy (talk) 20:20, 19 July 2024 (UTC)


 * Collapsed by default would be fine. (Thus, set to collapse syn and ant and cot by default, just as hyper and hypo and mer and hol are already set to collapse by default.) The option to unhide should not be taken away, though. Its button could be as unobtrusive as anyone likes, so long as it exists. It is true that list length can sometimes be trimmed via the final list item being a Thesaurus entry, and that is always nice to do when we get a chance. But it is not always practical, and there should not be any banning of semantic relations links. Quercus solaris (talk) 22:08, 19 July 2024 (UTC)


 * I prefer them visible/expanded by default, because having them collapsed makes them hard to find even if you're an adept user actively looking for them, so it surely makes them unnoticeable for many people who would be interested in them but don't realize to look for them: there was a discussion semi-recently (which I can't relocate at the moment) about no longer collapsing coordinate terms, altform-inline, etc, because when they used to be collapsed, even I had gone to entries which I thought I added e.g. a coordinate term to, hadn't seen it (because it was collapsed and the 'expand' button was small and easily overlooked), hadn't found it when Ctrl-F-ing, and only noticed when I went to edit the wikitext of the page to add it that it was already there in the wikitext, just hidden from view. But since some people prefer having them collapsed, to me it seems most reasonable to let people individually opt in to collapsing content they don't want (vs relying on people to notice content is being hidden and specifically opt-out of it being hidden). I notice that on at least some mobile devices the buttons seem to be the same size and font/colour as the definitions; perhaps we could change that to make the buttons look like the distinct thing that they are, so the entry was less of an undifferentiated lump of clutter? In general our mobile interface seems suboptimal, e.g. it's nonobvious how to get to the page history, and I'm not sure if my phone screen is just too small for the little 'circles' to display that allow selecting individual revisions to compare, but they don't display for me on my phone, though I see them if I access the mobile version of the site from my computer. (In turn, our desktop interface is uncompact, with wasted whitespace; one idea there would be to make the "synonyms:", "antonyms:" etc text stand out in some way and then optionally put them all on one line, "synonyms: foo, antonyms: bar, coordinate terms: baz".) - -sche (discuss) 22:16, 19 July 2024 (UTC)


 * Agreed. That last idea would be A-OK in my opinion. A follow-up to my comment above. Wiktionary serves various user personas, and that's A-OK. Everyone from (1) people who barely even speak a language and don't want anything except (what Collins would call) a gem definition, to (2) people who can handle all of the semantic relations and would be well-served by having the option to see them, even if they are hidden by default (in service of the aforementioned users who either don't want or can't handle them). The knowledgeable users can simply unhide them if they choose to do so. The button to unhide could be unobtrusive but also should not be such a desperately hidden Easter egg that serendipitous discovery becomes unlikely. A nice balance can be struck. Quercus solaris (talk) 22:23, 19 July 2024 (UTC)

Applying ux
Could someone create a bot to automatically replace raw markup with ux in entries? This would have the benefit of allowing users to easily change the appearance of usage examples if desired as well as make it easier to extract structured data from Wiktionary. Maybe would be interested. Ioaxxere (talk) 23:13, 19 July 2024 (UTC)


 * You need to be careful of this and . Vininn126 (talk) 23:17, 19 July 2024 (UTC)